[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
So I guess you refer to this new text for TimeFilter TC:
"To be used for the index to a table. Allows an application
to download only those rows changed since a particular time.
A row is considered changed if the value of any object in the
row changes, if the row is created, or if any object in the
row is created or deleted. Note that deleted rows cannot be
detected or downloaded."
a column being "created" I can kind of see.
When a row is in notReady state, a column may not yet have been
instantiated, right?
I am indeed not sure what it means that a "column gets deleted".
I guess I ndeed to go read and stury.
Bert
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of David B Harrington
> Sent: Tuesday, February 01, 2005 14:27
> To: 'C. M. Heard'; 'Mreview (E-mail)'
> Subject: RE: 2nd draft of proposed "Last Call" version of
> draft-ietf-ops-m ib-review-guidelines
>
>
> 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.
> >
> >
> >
>
>
>