SNMP getBulkRequest with multiple OIDs - Which is returned response OIDs order?

Question

I am sending SNMP getBulkRequest, using proprietary SNMP Browser based on some 3rd party libraries like agent++, snmp++, etc, with multiple OIDs, e.g.
.1.3.6.1.2.1.1.1
.1.3.6.1.2.1.1.5
.1.3.6.1.2.1.1.6
.1.3.6.1.2.1.1.4

Is it guaranteed that returned set (if OIDs with such prefixes exists) will be returned exactly in the same order?

e.g.
.1.3.6.1.2.1.1.1.0
.1.3.6.1.2.1.1.5.0
.1.3.6.1.2.1.1.6.0
.1.3.6.1.2.1.1.4.0

---

Any answers, links on documentation, hints related to this question are welcome.

---

UPDATE: Non-Repeaters = 0, MaxRepetitions >= 1

Answer 1

Assuming the agent is implemented correctly, then yes, though it might be a little clearer to say the full returned set of the response PDU is comprised of individual result sets for each OID in the request, and those individual result sets are returned in the same order as they were given in the request. Each individual result set behaves like zero or more (depending on the values of the non-repeaters and max-repetitions fields) get-next requests.

If your non-repeaters is N, then the first N OIDs in the response will correspond with the first N OIDs in the request, each behaving like a single get-next request (returning the next greater OID or endOfMibView exception if there are none). The rest of the OIDs in the request are subject to max-repetitions.

If your max-repetitions is M, then each of the remaining OIDs in the request behaves like 0..M get-next requests (returning up to M next greater OIDs from the request OID; if there aren't M greater, then there will be some lesser number followed by an endOfMibView exception, before the resulting OIDs from the next OID in the request).

[This also means if non-repeaters and max-repetitions are both 0, the result is an empty set; or if max-repetitions is 0 and non-repeaters is less than the number of OIDs in the request, then nothing will be returned for those request OIDs in excess of non-repeaters.]

If at any point in processing as above the agent can't add any more results to the response without exceeding its message size limits, then processing stops and the agent will return the partial results obtained thus far.

Reference: RFC 3416 section 4.2.3