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

["David B Harrington" <ietfdbh@comcast.net>]

Hi,

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.

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 am not an advocate for either position; I just notice the apparent
contradiction and thought I should point it out.

David Harrington
dbharrington@comcast.net



> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Tuesday, February 01, 2005 1:59 AM
> To: Mreview (E-mail)
> Subject: RE: 2nd draft of proposed "Last Call" version of 
> draft-ietf-ops-m ib-review-guidelines
> 
> On Mon, 31 Jan 2005, Wijnen, Bert (Bert) wrote:
> > On page 23, we now have:
> > 
> >    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.
> > 
> > Does that mean it is not allowed to have s RowStatus or
StorageType?
> > I think such is allowed, NO? And if so, we may want to make that
> > clear so that nobody interprets this incorrectly.
> 
> Well, one possibility might be to rephrase thusly:
> 
>      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
>      a RowStatus or StorageType column in an augmenting row 
> is OPTIONAL
>      if such a column is already present in the base row.
> 
> However, I don't like that, and here's why.  Given that an
> augmenting row is required to "share fate" with its base row, it
> seems to me that for it to have its own RowStatus or StorageType
> column just creates a redundant object.  I don't see what good that
> could come of that, and I do see potential harm.  So I don't think
> we want to put in language that would encourage people to do that.  
> If anything, I would think that we might want to say that people
> SHOULD NOT do that.
> 
> If we agree that a RowStatus or StorageType column in an augmenting
> row is not necessary when such a column is already in the base row,
> but we don't agree whether having such is a MAY or a SHOULD NOT,
> perhaps the best thing to do is to leave the text as is.  At any
> rate that is what I suggest.
> 
> > Further we list on page 34:
> >    TDomain                     OBJECT IDENTIFIER
> >    TAddress                    OCTET STRING (SIZE (1..255))
> > and on page 35:
> >    TransportDomain             OBJECT IDENTIFIER
> >    TransportAddressType        enumerated INTEGER
> >    TransportAddress            OCTET STRING (SIZE (0..255))
> > 
> > And I wonder if we would want to RECOMMEND/advise that in new MIB
> > module people use the latter 3 instead of the first 2.
> 
> In my nroff source I added this note under the list if TCs in RFC
> 2579:
> 
>    Note 3.  TDomain and TAddress SHOULD NOT be used in new MIB
>             modules.  The TransportDomain, TransportAddressType, and
>             TransportAddress TCs (defined in TRANSPORT-ADDRESS-MIB
>             [RFC3419]) SHOULD be used instead.
> 
> Note that this paraphrases what is already said in RFC 3419.
> 
> > I am checking with GenArea AD if we can actually reference
RFC3907/8
> > in an I-D that goes to IETF Last Call while those RFCs do not yet 
> > exist in final/published form.
> 
> I have gathered from the messages that you forwarded to me that we
> are OK on that score.
> 
> > Other then the above, I think this doc is ready to be posted
> > and then I can issue a 4 week IETF Last Call for publication as
BCP.
> 
> If you are OK with leaving the text on p. 23 as is, then I am ready
> to submit.
> 
> Mike
> 
> P.S.  I don't intend to do anything about the alleged corner case
> that Keith brought up earlier today because I just don't see an
> issue there.
> 
> 
>