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

[Andy Bierman <abierman@cisco.com>]

At 08:33 AM 12/17/2002 -0800, C. M. Heard wrote:
>On Tue, 17 Dec 2002, Wijnen, Bert (Bert) wrote:
>
>> I like Juergen's text.
>> 
>> Other opinions?

I like either Juergen's or Mike's text.  They convey the same
message.  I have been following this advice in Cisco MIB reviews
for a long time now -- I don't ignore the 32 char limit, but it's
not as important as having meaningful descriptors.

One thing not mentioned so far is descriptor consistency.
I like to see the same words abbreviated the same way.
IMO, a big reason MIB descriptors are so user-unfriendly
is that they are abbreviated in almost random ways.

>> 
>> Thanks,
>> Bert 

Andy



>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/>