Connected: An Internet Encyclopedia
4.2.5. The SetRequest-PDU
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1905
Up:
4. Protocol Specification
Up:
4.2. PDU Processing
Prev: 4.2.4. The Response-PDU
Next: 4.2.6. The SNMPv2-Trap-PDU
4.2.5. The SetRequest-PDU
4.2.5. The SetRequest-PDU
A SetRequest-PDU is generated and transmitted at the request of a
SNMPv2 application.
Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
determines the size of a message encapsulating a Response-PDU having
the same values in its request-id and variable-bindings fields as the
received SetRequest-PDU, and the largest possible sizes of the
error-status and error-index fields. If the determined message size
is greater than either a local constraint or the maximum message size
of the originator, then an alternate Response-PDU is generated,
transmitted to the originator of the SetRequest-PDU, and processing
of the SetRequest-PDU terminates immediately thereafter. This
alternate Response-PDU is formatted with the same values in its
request-id field as the received SetRequest-PDU, with the value of
its error-status field set to `tooBig', the value of its error-index
field set to zero, and an empty variable-bindings field. This
alternate Response-PDU is then encapsulated into a message. If the
size of the resultant message is less than or equal to both a local
constraint and the maximum message size of the originator, it is
transmitted to the originator of the SetRequest-PDU. Otherwise, the
snmpSilentDrops [9] counter is incremented and the resultant message
is discarded. Regardless, processing of the SetRequest-PDU
terminates.
Otherwise, the receiving SNMPv2 entity processes each variable
binding in the variable-binding list to produce a Response-PDU. All
fields of the Response-PDU have the same values as the corresponding
fields of the received request except as indicated below.
The variable bindings are conceptually processed as a two phase
operation. In the first phase, each variable binding is validated;
if all validations are successful, then each variable is altered in
the second phase. Of course, implementors are at liberty to
implement either the first, or second, or both, of these conceptual
phases as multiple implementation phases. Indeed, such multiple
implementation phases may be necessary in some cases to ensure
consistency.
The following validations are performed in the first phase on each
variable binding until they are all successful, or until one fails:
- If the variable binding's name specifies an existing or non-
existent variable to which this request is/would be denied access
because it is/would not be in the appropriate MIB view, then the
value of the Response-PDU's error-status field is set to
`noAccess', and the value of its error-index field is set to the
index of the failed variable binding.
- Otherwise, if there are no variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, and which are
able to be created or modified no matter what new value is
specified, then the value of the Response-PDU's error-status field
is set to `notWritable', and the value of its error-index field is
set to the index of the failed variable binding.
- Otherwise, if the variable binding's value field specifies,
according to the ASN.1 language, a type which is inconsistent with
that required for all variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, then the value of
the Response-PDU's error-status field is set to `wrongType', and
the value of its error-index field is set to the index of the
failed variable binding.
- Otherwise, if the variable binding's value field specifies,
according to the ASN.1 language, a length which is inconsistent
with that required for all variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, then the value of
the Response-PDU's error-status field is set to `wrongLength', and
the value of its error-index field is set to the index of the
failed variable binding.
- Otherwise, if the variable binding's value field contains an ASN.1
encoding which is inconsistent with that field's ASN.1 tag, then
the value of the Response-PDU's error-status field is set to
`wrongEncoding', and the value of its error-index field is set to
the index of the failed variable binding. (Note that not all
implementation strategies will generate this error.)
- Otherwise, if the variable binding's value field specifies a value
which could under no circumstances be assigned to the variable,
then the value of the Response-PDU's error-status field is set to
`wrongValue', and the value of its error-index field is set to the
index of the failed variable binding.
- Otherwise, if the variable binding's name specifies a variable
which does not exist and could not ever be created (even though
some variables sharing the same OBJECT IDENTIFIER prefix might
under some circumstances be able to be created), then the value of
the Response-PDU's error-status field is set to `noCreation', and
the value of its error-index field is set to the index of the
failed variable binding.
- Otherwise, if the variable binding's name specifies a variable
which does not exist but can not be created under the present
circumstances (even though it could be created under other
circumstances), then the value of the Response-PDU's error-status
field is set to `inconsistentName', and the value of its error-
index field is set to the index of the failed variable binding.
- Otherwise, if the variable binding's name specifies a variable
which exists but can not be modified no matter what new value is
specified, then the value of the Response-PDU's error-status field
is set to `notWritable', and the value of its error-index field is
set to the index of the failed variable binding.
- Otherwise, if the variable binding's value field specifies a value
that could under other circumstances be held by the variable, but
is presently inconsistent or otherwise unable to be assigned to the
variable, then the value of the Response-PDU's error-status field
is set to `inconsistentValue', and the value of its error-index
field is set to the index of the failed variable binding.
- When, during the above steps, the assignment of the value specified
by the variable binding's value field to the specified variable
requires the allocation of a resource which is presently
unavailable, then the value of the Response-PDU's error-status
field is set to `resourceUnavailable', and the value of its error-
index field is set to the index of the failed variable binding.
- If the processing of the variable binding fails for a reason other
than listed above, then the value of the Response-PDU's error-
status field is set to `genErr', and the value of its error-index
field is set to the index of the failed variable binding.
- Otherwise, the validation of the variable binding succeeds.
At the end of the first phase, if the validation of all variable
bindings succeeded, then the value of the Response-PDU's error-status
field is set to `noError' and the value of its error-index field is
zero, and processing continues as follows.
For each variable binding in the request, the named variable is
created if necessary, and the specified value is assigned to it.
Each of these variable assignments occurs as if simultaneously with
respect to all other assignments specified in the same request.
However, if the same variable is named more than once in a single
request, with different associated values, then the actual assignment
made to that variable is implementation-specific.
If any of these assignments fail (even after all the previous
validations), then all other assignments are undone, and the
Response-PDU is modified to have the value of its error-status field
set to `commitFailed', and the value of its error-index field set to
the index of the failed variable binding.
If and only if it is not possible to undo all the assignments, then
the Response-PDU is modified to have the value of its error-status
field set to `undoFailed', and the value of its error-index field is
set to zero. Note that implementations are strongly encouraged to
take all possible measures to avoid use of either `commitFailed' or
`undoFailed' - these two error-status codes are not to be taken as
license to take the easy way out in an implementation.
Finally, the generated Response-PDU is encapsulated into a message,
and transmitted to the originator of the SetRequest-PDU.
Next: 4.2.6. The SNMPv2-Trap-PDU
Connected: An Internet Encyclopedia
4.2.5. The SetRequest-PDU