[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 2nd draft of proposed "Last Call" version of draft-ietf-ops-mib-review-guidelines



On Tue, 1 Feb 2005, David B Harrington wrote:
> I am watching apparently-conflicting wordsmithing happen in two
> venues.
> 
> In the RMONMIB WG, in the TimeFilter TC, the definition of a changed
> row is being modified to include any row in which a column is created
> or deleted within the existing row. This obviously argues that the
> lifetime of the columns in tables do not share fate with the base row.

More precisely, the TimeFilter text accomodates situations where the
individual columns of a row do not all have the same lifetime.

> Using augments, I can add a column to a base row. If it is required
> here that columns and rows share fate, does that mean the new
> TimeFilter text is not consistent with the new guidelines?

I don't think so.  But let me hasten to point out that the "new
guidelines" do not mandate or require anything that was not already
present in RFC 2578.  What was being discussed was this text:

    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.

The first sentence just summarizes this part of RFC 2578 Section 7.8:

   Furthermore, 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.

The second sentence is just a consequence of the first.  That was
pointed out by Keith (and added to the guidelines because it was not
already stated explicitly in RFC 2578).  If the TimeFilter text is
inconsistent with the new paragraph in the guidelines doc, then it
is inconsistent with RFC 2578.

However, as I said above, I don't see a problem here.  What the
TimeFilter text does is to define what it means when it says that a
row is changed.  It does not mandate any particular policy on object
lifetime.

Mike