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

["C. M. Heard" <heard@pobox.com>]

On Sat, 8 Jan 2005, Wijnen, Bert (Bert) wrote:
>[C. M. Heard wrote:]
> > One way to deal with the situation when the rules vary from one
> > column to another is to specify in each read-write column's
> > DESCRIPTION clause whether or not it can be modified when the status
> > is active(1) and to have status object's DESCRIPTION clause say that
> > each read-create column's DESCRIPTION clause states whether or not
> > that column may be modified while the status is active(1).
> > 
> > I routinely advise authors of this possibility when in the course of
> > a MIB review I have to remind them of this rule.  Historically, the
> > RMON-MIB did things this way when it introduced the EntryStatus TC.
> > 
> > Although I have not seen it done, I suppose that one could do a
> > similar thing when a StorageType column is present.
> > 
> OK, sounds fine. So maybe we need to put in some text for such an
> approach.

It turns out that we already have such text.  Section 4.6.4 of the -03
draft said:

   - For conceptual rows that include a status column:
     [ ... ]
     - The DESCRIPTION clause of the status column MUST specify whether
       or not it is possible to modify other columns in the same
       conceptual row when the status value is active(1).  Note that in
       many cases it will be possible to modify some writeable columns
       when the row is active but not others.  In such cases the
       DESCRIPTION clause for each writeable column SHOULD state whether
       or not that column can be modified when the row is active, and
       the DESCRIPTION clause for the status column SHOULD state that
       modifiability of other columns when the status value is active(1)
       is specified in the DESCRIPTION clauses for those columns (rather
       than listing the modifiable columns individually).

and this is unchanged in the 04Pre1 version.

On Sat, 8 Jan 2005, David T. Perkins wrote:
> Note, I didn't find a restriction about StorageType.

The StorageType DESCRIPTION clause says:

       Every usage of this textual convention is required to
       specify the columnar objects which a permanent(4) row must
       at a minimum allow to be writable.

and the review guidelines re-iterate this in Section 4.6.4:

   - For conceptual rows that include a StorageType column:

     - The DESCRIPTION clause of the StorageType column MUST specify
       which read-write or read-create columnar objects in permanent(4)
       rows an agent must, at a minimum, allow to be writable.

On Fri, 7 Jan 2005, Randy Presuhn wrote:
> 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...
> 
> 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.

Note that the requirement in question is a MINIMUM requirement. That
is, the StorageType DESCRIPTION clause can require that an agent
allow certain specific read-write or read-create columns in a
permanent row to be changed.  An agent is permitted but not required
to allow other read-write or read-create columns to be changed. When
new columns are added to T, whether directly or via an augmenting
table T1, it is up to the agent implementor whether they are allowed
to be changed in permanent rows. The StorageType DESCRIPTION clause
does not need to be changed. In fact, it MUST NOT be changed to add
any of the new columns new columns to the "minimum changeble" list
for permanent rows, since that would change the semantics in an
incompatible way.

So I don't think that there is a problem here.

Mike