RE: Issue with MIB compilation requirement in "AD Review of I-Ds" (http://www.ietf.org/ID-nits.html)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Fine with me.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 17 december 2002 17:34
> To: Mreview (E-mail)
> Subject: RE: Issue with MIB compilation requirement in "AD Review of
> I-Ds" (http://www.ietf.org/ID-nits.html)
> 
> 
> On Tue, 17 Dec 2002, Wijnen, Bert (Bert) wrote:
> 
> > I like Juergen's text.
> > 
> > Other opinions?
> > 
> > Thanks,
> > Bert 
> 
> Here is what I came up with over the weekend for a revised version of
> Section 4.2 of the MIB authors and reviewer's guidelines document.
> Like all wordsmiths, I think it's even better that the suggestion
> from my learned colleagues, but I'm sure I'll be quickly disabused of
> that notion :-)
> 
> 
> 4.2.  Descriptors and Labels
> 
>    RFC 2578, Sections 3.1, 7.1.1, and 7.1.4, and RFC 2579, Section 3
>    recommend that descriptors associated with macro invocations and
>    labels associated with enumerated INTEGER and BITS values be no
>    longer than 32 characters, but require that they be no longer than
>    64 characters.
> 
>    Restricting descriptors and labels to 32 characters often conflicts
>    with the recommendation that they be mnemonic and (for descriptors)
>    with the requirement that they be unique (see RFC 2578, 
> Section 3.1,
>    and RFC 2579, Section 3).  It is the position of this document
>    (ratified by common practice) that the SMIv2 
> recommendation to limit
>    descriptors and labels to 32 characters SHOULD be set 
> aside in favor
>    of promoting uniqueness and clarity, and that automated 
> tools such as
>    MIB compilers SHOULD NOT generate warnings for violating it.
> 
>    Note that violations of the 64 character limit MUST NOT be ignored;
>    they MUST be treated as errors.
> 
> //cmh
> 
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> > > Sent: vrijdag 13 december 2002 14:56
> > > To: heard@pobox.com
> > > Cc: mreview@ops.ietf.org
> > > Subject: Re: Issue with MIB compilation requirement in 
> "AD Review of
> > > I-Ds" (http://www.ietf.org/ID-nits.html)
> > > 
> > > 
> > > 
> > > >>>>> C M Heard writes:
> > > 
> > > Mike> I agree with you, and this is what I wrote:
> > > 
> > > :   Restricting descriptors and labels to 32 characters 
> often conflicts
> > > :   with the recommendation that they be mnemonic and 
> (for descriptors)
> > > :   the requirement that they be unique (see RFC 2578, 
> Section 3.1).  The
> > > :   SMIv2 recommendation to limit names to 32 characters 
> SHOULD be set
> > > :   aside when it comes in conflict with these considerations.
> > > 
> > > What about this text:
> > > 
> > >     The SMIv2 recommends that descriptors and names are not longer
> > >     than 32 characters (RFC 2578 section 3.1 and RFC 2579 section
> > >     3). This recommendation often conflicts with the 
> recommendation
> > >     that names and descriptors be mnemonic and that they 
> be unique.
> > >     When it comes to a conflict between these 
> recommendations, it is
> > >     common practice that the 32 character limit is set 
> aside in favour
> > >     of uniqueness and clarity of names and descriptors. 
> This document
> > >     therefore suggests that the 32 character length 
> recommendation can
> > >     be safely ignored. This does of course not affect the 
> upper limit
> > >     of 64 characters for names and descriptors, which continues to
> > >     exist.
> > > 
> > > Not sure this is much better, probably just different. I 
> think it is
> > > important to refer to the same rule in RFC 2579 (that is what I
> > > added). I also wanted to express that it is safe to ignore this 32
> > > character rule in all cases (such as if it would have 
> never been part
> > > of SMIv2) while your text sounds a bit more like a conditional
> > > statement (and compilers usually have a hard time to judge what a 
> > > good mnemonic name is).
> > > 
> > > /js
> > > 
> > > -- 
> > > Juergen Schoenwaelder    
> > <http://www.informatik.uni-osnabrueck.de/schoenw/>
> 
>