[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comment on draft-ietf-ops-mib-review-guidelines-03.txt (fwd)
I think the point about DEFVALs is good, and not obvious.
It would be good to provide an explicit guideline on this point.
dbh
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Monday, January 10, 2005 6:32 AM
> To: David T. Perkins; Randy Presuhn
> Cc: mreview@ops.ietf.org
> Subject: 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.
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>