[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comment on draft-ietf-ops-mib-review-guidelines-03.txt (fwd)
Inline
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of C. M. Heard
> Sent: Saturday, January 08, 2005 05:07
> To: Mreview (E-mail)
> Subject: RE: comment on draft-ietf-ops-mib-review-guidelines-03.txt
> (fwd)
>
>
> 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.
>
OK, sounds fine. So maybe we need to put in some text for such an approach.
> //cmh
>
>