[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DateAndTime TC oversight in RFC 2579
Mike,
Can you clarify why the proposed change would contradict RFC 2578?
IMO, it looks like
a. it does not cause interoperability problems over the wire - as the MIBs that do not care about the default value need not use the clarification, and the other already do it, as proved by the list forwarded by Bert
b. The change may be implemented using an editorial procedure allowed by RFC 2578:
'(8) Clarifications and additional information may be included in the
DESCRIPTION clause.'
Thanks and Regards,
Dan
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org]On Behalf Of C. M. Heard
> Sent: 21 December, 2003 9:42 PM
> To: Mreview (E-mail)
> Cc: Keith McCloghrie (E-mail)
> Subject: Re: DateAndTime TC oversight in RFC 2579
>
>
> Howdy,
>
> To put the answers in the form Bert requested:
>
> - BAD: I think that it is a BAD idea to make the proposed
> amendment, particularly as an erratum to RFC 2578;
>
> - DOES: I think that such an amendment DOES require IETF last call.
>
> Here is the reasoning.
>
> I think I have to agree with Dave Perkins that if one or more
> distingished non-date values are added to the DateAndTime TC then
> the TC DESCRIPTION clause must also be modified to require that if
> an object can return any of those distinguished values then the
> object definition must specify the conditions under which that
> happens. Since the original TC definition has no distinguished
> values the default, if no behaviour is specified has to be that the
> object does not ever return distinguished values. That would
> preserves backward compatibility with existing definitions object
> using the TC as defined in RFC 2578.
>
> However, once we get this far, I think we have to face the fact that
> that this clearly is not just a correction of a typo, and on that
> basis I would say that it is not appropriate to fix the oversight in
> the definition by having the RFC Editor list it as an erratum. It
> would, I think, be more appropriate to publish a short RFC that
> updates RFC 2578, and put it to IETF Last Call. This RFC would have
> to point out that it would NOT be legal to revise the DESCRIPTION
> clause of an object with a SYMTAX value of a DateAndTime to allow
> for distinguished values if it did not do so originally, because
> that would constitute a semantic change that is banned by RFC 2578
> Section 10.
>
> Better still, in my opinion, would be to publish a new TC such as
> DateAndTimeOrNull, and when revising a MIB modules that uses
> DateAndTime where DateAndTImeOrNull is more appropriate, update the
> affected object definitions. This would be more consistent with our
> practices elsewhere (cf. InterfaceIndex vs. InterfaceIndexOrZero).
>
> Mike
>
> On Sun, 21 Dec 2003, David T. Perkins wrote:
> > HI,
> >
> > The term "NULL value" is sooo ambiguous. I get recently read
> > the specs for another schema language where they decided not
> > to use that term. In SQL "NULL value" means a "missing value".
> > In the schema definition (and I can not remember, but maybe
> > someone else can), they made a destinction between sitiuation
> > of "not available" and "not supported". So, on the below,
> > and certainly in MIB modules that I have written, I try
> > to remove the cost of writing code for agents and
> > management applications. And, thus, where it is appropriate,
> > I try to have values that mean "not available" or
> > "not supported". In the below, I'm not sure whether
> > a value of '0000000000000000'h or "" (a zero length string)
> > is the best choice. However, I do believe that such
> > a distingushed value is needed. And the TC should
> > say that the DESCRIPTION clause must indicate under
> > what conditions that such a value will be returned.
> >
> > On Sun, 21 Dec 2003, Wijnen, Bert (Bert) wrote:
> > > The issue of using a defval for DateAndTime of all zeroes
> (8 octets).
> > > comes up again in the ROHC MIB draft-ietf-rohc-mib-rtp-08.txt
> > > which just finished IETF Last Call. I am just going to let it
> > > pass.
> > >
> > > But...
> > >
> > > If we think that that DEFVAL is valid (and we behave that
> way by passing
> > > documents that use it), then I think we should propose
> some text for an
> > > ERRATA statement for RFC-Editor.
> > >
> > > It could be as simple as something aka:
> > >
> > > The DESCRIPTION clause of the DateAndTime TC needs an
> > > additional paragraph:
> > >
> > > The special 8-octet value of '0000000000000000'H can be used
> > > to represent a NULL value.
> > >
> > > If the SMIv2 authors/editors and the MIB Doctors agree with this,
> > > then I am willing to move ahead. If people believe that
> text should
> > > be modified, pls let me know.
> > >
> > > Not sure if it would need an IETF Last Call, cause
> although we may
> > > agree that it is an "oversight", it is not clearly just a typo.
> > > I kind of would say it does NOT need an IETF Last Call.
> > > The following RFCs already use the '0000000000000000'H value
> > > for the DateAndTimeTC
> > > RFC 2561 - TN3270E-MIB
> > > RFC 2562 - TN3270E-RT-MIB
> > > RFC 2564 - APPLICATION-MIB
> > > RFC 2591 - DISMAN-SCHEDULE-MIB
> > > RFC 2594 - WWW-MIB
> > > RFC 2758 - SLAPM-MIB
> > > RFC 2925 - DISMAN-PING-MIB
> > > RFC 3165 - DISMAN-SCRIPT-MIB
> > > possibly in some newer RFCs too.
> > >
> > > Pls send in your comments:
> > >
> > > - I think this emendment is GOOD/BAD (pls choose GOOD or BAD)
> > > - I think it does/does-not require an IETF Last Call
> > > (pls choose does or does-not)
> > >
> > > Thanks,
> > > Bert
> > >
> > > > -----Original Message-----
> > > > From: C. M. Heard [mailto:heard@pobox.com]
> > > > Sent: maandag 8 september 2003 22:23
> > > > To: mibs@ops.ietf.org
> > > > Subject: Is this an oversight in RFC 2579?
> > > >
> > > >
> > > > [ The attached message has been forwarded from the entity ]
> > > > [ MIB list, as it is a question of general interest. --cmh ]
> > > >
> > > > -----Original Message-----
> > > > From: Juergen Schoenwaelder
> [mailto:j.schoenwaelder@iu-bremen.de]
> > > > Sent: maandag 8 september 2003 17:10
> > > > To: C. M. Heard
> > > > Cc: entmib@ietf.org
> > > > Subject: Re: [Entmib] entity mib support for tcif
> > > >
> > > >
> > > >
> > > > On Sun, Sep 07, 2003 at 01:24:57PM -0700, C. M. Heard wrote:
> > > > >
> > > > > >>>>> On Sun, 7 Sep 2003, Wijnen, Bert (Bert) replied:
> > > > > Bert> Or..., the DESCRIPTION clause could say that
> all zeroes for
> > > > > Bert> the DateAndTime would mean
> > > > > Bert> "manufacture date unknown or nor supported"
> > > > > Bert>
> > > > > Bert> Just thinking aloud here.
> > > > >
> > > > > It seems to me that this would conflict with the DateAndTime
> > > > > DESCRIPTION clause in RFC 2579.
> > > >
> > > > While true, it is existing practice in other MIB modules to use
> > > > '0000000000000000'H as a NULL value and I personally
> consider not
> > > > allowing this special value an oversight in the SMIv2 revision.
> > > >
> > > > /js
> >
> > Regards,
> > /david t. perkins
> >
> >
>
>
>