RE: comment on draft-ietf-ops-mib-review-guidelines-03.txt (fwd)

["C. M. Heard" <heard@pobox.com>]

On Fri, 7 Jan 2005, Wijnen, Bert (Bert) wrote:
>[Randy Presuhn wrote:]
> > [...] BUT...
> > 
> > RFC 2579 requires the OBJECT-TYPE using the StorageType SYNTAX to
> >             specify the columnar objects which a permanent(4) row must
> >             at a minimum allow to be writable
> > 
> > This puts us in a bit of a documentation quandry, since when T is defined
> > it's not reasonable to fill in this bit of specification for T1, which
> > in all likelihood hasn't even been thought of.
> > 
> Same is true for RowStatus, where RFC2579 says:
> 
> 
>                 This textual convention may be used for a MIB table,
>                 irrespective of whether the values of that table's
>                 conceptual rows are able to be modified while it is
>                 active, or whether its conceptual rows must be taken
>                 out of service in order to be modified.  That is, it is
> -->             the responsibility of the DESCRIPTION clause of the
> -->             status column to specify whether the status column must
> -->             not be `active' in order for the value of some other
> -->             column of the same conceptual row to be modified.  If
>                 such a specification is made, affected columns may be
>                 changed by an SNMP set PDU if the RowStatus would not
>                 be equal to `active' either immediately before or after
>                 processing the PDU.  In other words, if the PDU also
>                 contained a varbind that would change the RowStatus
>                 value, the column in question may be changed if the
>                 RowStatus was not equal to `active' as the PDU was
>                 received, or if the varbind sets the status to a value
>                 other than 'active'.

One way to deal with the situation when the rules vary from one
column to another is to specify in each read-write column's
DESCRIPTION clause whether or not it can be modified when the status
is active(1) and to have status object's DESCRIPTION clause say that
each read-create column's DESCRIPTION clause states whether or not
that column may be modified while the status is active(1).

I routinely advise authors of this possibility when in the course of
a MIB review I have to remind them of this rule.  Historically, the
RMON-MIB did things this way when it introduced the EntryStatus TC.

Although I have not seen it done, I suppose that one could do a
similar thing when a StorageType column is present.

//cmh