[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>
>