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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

In;ine

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of Randy Presuhn
> Sent: Friday, January 07, 2005 23:13
> To: mreview@ops.ietf.org
> Subject: Re: comment on draft-ietf-ops-mib-review-guidelines-03.txt
> (fwd)
> 
> 
> Hi -
> 
> I think you're in agreement.  Using Bert's notation,
> T1 AUGMENTS T
> T MUST/SHOULD have RowStatus,
> T MAY have StorageType
> T1 will not have RowStatus (since the rows exists 1:1 with those in T)
> I think the "inheritance" argument about StorageType is 
> reasonable, 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'.

Bert
> Randy
> 
> > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > To: "C. M. Heard" <heard@pobox.com>; <mreview@ops.ietf.org>
> > Cc: "Keith McCloghrie (E-mail)" <kzm@cisco.com>
> > Sent: Friday, January 07, 2005 1:45 PM
> > Subject: RE: comment on 
> draft-ietf-ops-mib-review-guidelines-03.txt (fwd)
> >
> 
> > Mmmm... good question.
> >
> > In my view, when a base table T is AUGMENTED with tanle T1, 
> then that means
> > that when a row gets created in table T1, then 
> automagically a row in
> > table T must be created.
> >
> > But I am not sure that the reverse is true, is it? The 
> agent might not (yet)
> > have implemented table T1.
> >
> > Besides, we now have MIB modules that make it compliant to 
> not support
> > a createAndWait, and if the table is AUGMENTED with a large 
> set of objects
> > then the createAndGo may not work (packet size) ...
> >
> > So I am not sure..... If the AUGEMENTED table does not have 
> a RowStatus,
> > then what do we expect people to do to create an entry?
> >
> > Other people had pointed out to me, that if the base row 
> has a StorageType, then
> > the AUGMENTED row does not need one, because it would 
> inherit the StorageType
> > of the base row. That I think makes sense.
> >
> > Bert
> >
> > > -----Original Message-----
> > > From: owner-mreview@ops.ietf.org 
[mailto:owner-mreview@ops.ietf.org]On
> > Behalf Of C. M. Heard
> > Sent: Friday, January 07, 2005 21:42
> > To: mreview@ops.ietf.org
> > Subject: comment on draft-ietf-ops-mib-review-guidelines-03.txt (fwd)
> >
> >
> > All,
> >
> > Here is a timely suggestion from Keith McCloghrie.  Comments from
> > other MIB doctors please.
> >
> > //cmh
> >
> > ---------- Forwarded message ----------
> > Date: Fri, 7 Jan 2005 10:30:45 -0800 (PST)
> > From: Keith McCloghrie <kzm@cisco.com>
> > To: heard@pobox.com
> > Cc: bwijnen@lucent.com, Keith McCloghrie <kzm@cisco.com>
> > Subject: comment on draft-ietf-ops-mib-review-guidelines-03.txt
> >
> > Hi,
> >
> > Do you think that this text:
> >
> >   - If dynamic row creation and/or deletion by management applications
> >     is supported, then:
> >
> >      - There MUST be one columnar object with a SYNTAX value of
> >        RowStatus [RFC2579] and a MAX-ACCESS value of
> > read-create.  This
> >        object is called the status column for the conceptual row.  All
> >        other columnar objects MUST have a MAX-ACCESS value of read-
> >        create, read-only, accessible-for-notify, or not-accessible;  a
> >        MAX-ACCESS value of read-write is not allowed.
> >
> > or some other text in draft-ietf-ops-mib-review-guidelines-03.txt
> > should mention the situation of one table which AUGMENTS
> > another table,
> > in which only one of them should have a RowStatus, i.e., this is one
> > circumstance where it's legitimate to get read-create objects in a
> > table without a RowStatus.
> >
> > Keith.
> >
> >
>