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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

More importantly is that if application A is created
to access table T, such as to create and delete rows
in T. Then adding support for augmentation table T1
MUST NOT cause A to stop working or to work differently.
This means that a MIB designer is quite constrained 
in the design of augmentation tables!

This should be obvious.

Note, I didn't find a restriction about StorageType.
However, RowStatus requires specification of dependencies
for modification and activation. An augmentation table
MAY NOT change the dependencies.

Regards,
/david t. perkins

On Fri, 7 Jan 2005, Randy Presuhn wrote:

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