[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 David T. Perkins
> Sent: Sunday, January 09, 2005 04:33
> To: Randy Presuhn
> Cc: mreview@ops.ietf.org
> Subject: Re: comment on draft-ietf-ops-mib-review-guidelines-03.txt
> (fwd)
>
>
> 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.
>
I guess you are right that it should be obvious.
However, I suspect I never took it that restricted when reviewing new
MIB modules. It restricts it very very seriously. For example, all
the columns in the augemented table should have DEFVALs to allow the row
to become active based on DEFVALs. mmmm... I need to go check some
(already approved) MIB modules I think.
> Note, I didn't find a restriction about StorageType.
Right. But what I was trying to indicate is that (in my view) the
persistency of the base table and the AUGMENTing table should be exactly
the same. So there seems no need to have a separate StorageType for the
AUGMENTing table... and if it does have one, then the two values SHOULD
(MUST even) be the same, no?
> However, RowStatus requires specification of dependencies
> for modification and activation. An augmentation table
> MAY NOT change the dependencies.
>
And so (as I say above), that means that the AUGMENTing table must provide
DEFVALs that will allow the table to go active, right?
Bert
> 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.
> > > >
> > > >
> > >
> >
> >
> >
>
>