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.
