[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue with MIB compilation requirement in "AD Review of I-Ds" (http://www.ietf.org/ID-nits.html)
At 09:23 PM 12/17/2002 +0100, Wijnen, Bert (Bert) wrote:
>Fine with me.
Here is another warning in smilint that I disagree with:
identifier 'foo' differs from 'Foo' only in case.
Please point out the rule in the SMI that says this is not allowed.
Smilint is hardwired to ignore this warning for
"fooEntry SEQUENCE of FooEntry", but not other instances.
I don't understand the point of this warning. SNMP toolkits
that I am familiar with generate code stubs based on the
fooEntry descriptor and maybe the fooObject descriptor,
but never a descriptor for a TC.
>Thanks,
>Bert
Andy
>> -----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/>
>>
>>