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

["Randy Presuhn" <randy_presuhn@mindspring.com>]

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