Re: DateAndTime TC oversight in RFC 2579

["David T. Perkins" <dperkins@dsperkins.com>]

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