[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 2nd draft of proposed "Last Call" version of draft-ietf-ops-m ib-review-guidelines
I am OK with you submitting.
I also agree that the corner case that Keith brought up seems
(to me at least) a very exceptional corner case that (as far
as I remember) we have not yet encountered and that I suspect
we won't easily encounter either (knock on wood).
Bert
> -----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 07:59
> 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.
>
>