It is mandatory that all SNMPv2 entities acting in an agent role be able to generate the following PDU types: Response-PDU and SNMPv2- Trap-PDU; further, all such implementations must be able to receive the following PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.
It is mandatory that all SNMPv2 entities acting in a manager role be able to generate the following PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, and Response-PDU; further, all such implementations must be able to receive the following PDU types: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU;
In the elements of procedure below, any field of a PDU which is not referenced by the relevant procedure is ignored by the receiving SNMPv2 entity. However, all components of a PDU, including those whose values are ignored by the receiving SNMPv2 entity, must have valid ASN.1 syntax and encoding. For example, some PDUs (e.g., the GetRequest-PDU) are concerned only with the name of a variable and not its value. In this case, the value portion of the variable binding is ignored by the receiving SNMPv2 entity. The unSpecified value is defined for use as the value portion of such bindings.
On generating a management communication, the message "wrapper" to encapsulate the PDU is generated according to the "Elements of Procedure" of the administrative framework in use is followed. While the definition of "max-bindings" does impose an upper-bound on the number of variable bindings, in practice, the size of a message is limited only by constraints on the maximum message size -- it is not limited by the number of variable bindings.
On receiving a management communication, the "Elements of Procedure" of the administrative framework in use is followed, and if those procedures indicate that the operation contained within the message is to be performed locally, then those procedures also indicate the MIB view which is visible to the operation.