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

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

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.