RE: DateAndTime TC oversight in RFC 2579

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

- I think this amendment is GOOD
- I think it does require an IETF Last Call 

However, instead of:

    The special 8-octet value of '0000000000000000'H can be used
    to represent a NULL value.

Should it not rather be

    The special 8-octet value of '0000000000000000'H MAY be used
    to represent a NULL value.

Regards,

Dan


> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org]On Behalf Of Wijnen, Bert (Bert)
> Sent: 21 December, 2003 4:45 PM
> To: Mreview (E-mail)
> Cc: Keith McCloghrie (E-mail)
> Subject: DateAndTime TC oversight in RFC 2579
> 
> 
> 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
> > 
> 
>