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

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

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