[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
> 
>