🚀 go-pugleaf

| The following article was relayed from Mr. William Stallings on Compuserve.
| Please send private responses to him at "72500.3562@compuserve.com".

>My questions are:
>1) Have I overlooked an RFC which specifies when
>to return readOnly errors?
>2) if not, why is readOnly a valid value for ErrorStatus?

The definition of the SetRequest PDU in RFC 1157 includes the
following rule:

If, for any object named in the variable-bindings field, the
object is not available for set operations in the relevant MIB
view, then the receiving entity sends to the originator of the
received message the GetResponse-PDU of identical form,
except that the value of the error-status field is noSuchName,
and the value of the error-index field is the index of said object
name component in the received message.

        This rule is interpreted to mean the following:

        1.      If a set operation is attempted for an object that is 
not in
the MIB view of the manager, return noSuchName.
        2.      If a set operation is attempted for an object that is in the
MIB view of the manager but is read-only, return
noSuchName.

        One can use the line of reasoning that an object that is read-
only is not in the MIB view of a manager for purposes of set
operations. There are two things "wrong" with this rule. First,
information is lost; when a manager receives noSuchName in
response to a set, the manager must also do a get operation to
determine if the error code refers to a missing object or a read-only
object. Second, since the readOnly error code exists, it is clearly
confusing not to use it in the obvious circumstances.
        The solution to this mystery is that the use of readOnly was
omitted in RFC 1157 due to a clerical error. The only occurrence of
readOnly in RFC 1157 is in the ASN.1 PDU definitions. Therefore, to
be compliant with the standard, one must not use this error code.
        The further history of readOnly is worth mentioning. Secure
SNMP, which is a security enhancement to SNMP makes use of an
access-control table in addition to the ACCESS clause in the OBJECT-
TYPE macro. The access-control table enables an agent to specify
which protocol operations are allowed to a given manager in a given
context. If the access-control table dictates that only get and get-next
operations are allowed, and an agent receives a set PDU, then the
resulting GetResponse includes an error-status of readOnly. This is
true even if the ACCESS clause for the requested object has the value
read-write; the access-control entry for the entire MIB view takes
precedence over the ACCESS property of the individual object. This
policy makes some sense, since for the purposes of this access, all of
the objects in the MIB view are only available via read-type
operations (get, get-next). Nevertheless, it is somewhat misleading,
especially since the readOnly code is not used in the original SNMP.
Moreover, it gets worse. If for some strange reason, the access-
control table dictates that only set operations are allowed (a sort of
"write-only" access policy), and an attempt is made to perform a get
or a get-next, then the resulting GetResponse includes an error-status
of readOnly! The rationale for all of this is that the desired
functionality of secure SNMP could be achieved without changing the
ASN.1 definition of the SNMP PDUs.
        Finally, there is the Simple Network Management Protocol
version 2 (SNMPv2). In this specification, there are two new error
codes: notWritable, which means what readOnly should have meant
in RFC 1157 but didn't, and authorizationError, which means what
RFC 1351 said readOnly meant.
        Got that?

Bill Stallings

(72500.3562@compuserve.com)