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

[Keith McCloghrie <kzm@cisco.com>]

I agree with the summary.  Here are a couple of additional points:

1. It's not clear to me whether write-able objects in an augmenting
table must be read-create if the base table has a RowStatus object.  At
first glance, one would think they must, but also consider the case of
read-write objects in a base table for which an augmenting table has a
Row Status object (or even objects in one augmenting table for which
another table, also augmenting the same base table, has a RowStatus).
[Note also that the difference between read-write and read-create is a
characteristic of the table, not of the object; in retrospect, I regret
the way that "read-create" is defined.]  I think it would be good for
compilers to be lenient on this issue.

2. draft-ietf-ops-mib-review-guidelines-03.txt has several places where
it uses the term "read-create table".  RFC 2578 also uses the term in
one place.  Neither document specifically defines the term, but it now
implies that a table without read-create objects is a read-create
table if it augments a read-create table, or if it is augmented by a
read-create table.  I don't believe there's any ambiguity at present,
but it is something for the editor to be aware of for the future.

Keith.

> To summarize this thread:
> 
> >>>>> On Fri, 7 Jan 2005, Keith McCloghrie wrote:
> kzm> Do you think that this [ text from Section 4.6.4 ] or some
> kzm> other text in draft-ietf-ops-mib-review-guidelines-03.txt
> kzm> should mention the situation of one table which AUGMENTS
> kzm> another table, in which only one of them should have a
> kzm> RowStatus, i.e., this is one circumstance where it's legitimate
> kzm> to get read-create objects in a table without a RowStatus.
> 
> >>>>> On Fri, 7 Jan 2005, Wijnen, Bert (Bert) wrote:
> Bert> In my view, when a base table T is AUGMENTED with table
> Bert> T1, then that means that when a row gets created in table
> Bert> T1, then automagically a row in table T must be created.
> Bert> 
> Bert> But I am not sure that the reverse is true, is it? The
> Bert> agent might not (yet) have implemented table T1.
> Bert> 
> Bert> Besides, we now have MIB modules that make it compliant to
> Bert> not support a createAndWait, and if the table is AUGMENTED
> Bert> with a large set of objects then the createAndGo may not
> Bert> work (packet size) ...
> Bert> 
> Bert> So I am not sure..... If the AUGMENTED table does not have
> Bert> a RowStatus, then what do we expect people to do to create
> Bert> an entry?
> Bert> 
> Bert> Other people had pointed out to me, that if the base row
> Bert> has a StorageType, then the AUGMENTED row does not need
> Bert> one, because it would inherit the StorageType of the base
> Bert> row. That I think makes sense.
> 
> I think that the following excerpt from RFC 2578, Section 7.8,
> settles both of these issues:
> 
>    Further, instances of subordinate columnar objects of a
>    conceptual row augmentation exist according to the same
>    semantics as instances of subordinate columnar objects of
>    the base conceptual row being augmented.  As such, note
>    that creation of a base conceptual row implies the
>    correspondent creation of any conceptual row augmentations.
> 
> In other words, an instance of a row in an augmenting table is
> REQUIRED to share fate with the corresponding instance of its base
> row.  Based on that, I propose to add the following paragraph just
> before the final paragraph in Section 4.6.4:
> 
>    Note that RFC 2578 Section 7.8 requires that the lifetime of an
>    instance of a conceptual row that AUGMENTS a base row must be
>    the same as the corresponding instance of the base row.  It
>    follows that there is no need for a RowStatus or StorageType
>    column in an augmenting row if one is already present in the
>    base row.
> 
> >>>>> On Sat, 8 Jan 2005, David T. Perkins wrote:
> David> More importantly is that if application A is created
> David> to access table T, such as to create and delete rows
> David> in T. Then adding support for augmentation table T1
> David> MUST NOT cause A to stop working or to work differently.
> David> This means that a MIB designer is quite constrained
> David> in the design of augmentation tables!
> David> 
> David> This should be obvious.
> David> 
> David> Note, I didn't find a restriction about StorageType.
> David> However, RowStatus requires specification of dependencies
> David> for modification and activation. An augmentation table
> David> MAY NOT change the dependencies.
> 
> I agree that this is obvious (it is a consequence of the rule
> against making sematic changes) and I don't think that we need
> additional text in the MIB review guidelines to cover it.
> 
> >>>>> On Fri, 7 Jan 2005, Randy Presuhn replied:
> Randy> I agree with the substance of Keith's comment.  However,
> Randy> it brought to my attention another issue...
> Randy>
> Randy> ...
> Randy> >   - If dynamic row creation and/or deletion by
> Randy> >     management applications is supported, then:
> Randy> >
> Randy> >      - There MUST be one columnar object with a
> Randy> >        SYNTAX value of RowStatus [RFC2579] and a
> Randy> >        MAX-ACCESS value of read-create.
> Randy> ...
> Randy>
> Randy> Given that dissatisfaction with the complexity RowStatus
> Randy> bubbles up from time to time, I think the MUST is slightly
> Randy> overkill. If a standards-track "RowStatusLite" ever
> Randy> emerges, the existence of the current text would require
> Randy> us to go back and modify the guidelines.  I certainly
> Randy> support uniformity and consistency in row creation; it
> Randy> makes life easier for both compiler and management
> Randy> application writers.  Nonetheless, the current text seems
> Randy> a tad too restrictive.
> 
> I agree with this too, and the proposed fix is just to change the
> MUST to a SHOULD (note that RFC 2578 uses a lower-case should).
> 
> If no objections are raised these fixes will appear in the next spin
> of the draft.
> 
> Mike
>