[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)



[ cc list trimmed down ]

On Thu, 12 Dec 2002, Juergen Schoenwaelder wrote:
> >>>>> C M Heard writes:
> 
> Mike> It would be better if we could get the mailer service to at
> Mike> least omit the namelength-32 warnings, which IMHO are just
> Mike> annoying noise.  Thus, it would be nice if the default assumed
> Mike> by the mailer service could be "smilint -l 9 -s -i
> Mike> namelength-32".
> 
> If there would be a document which says that the underlying SMIv2 rule
> is considered to be not important anymore, then I am happy to just
> remove this warning from smilint. (I am myself annoyed by it so I
> usually turn it off anyway. In fact, the -i option was added some time
> ago specifically to handle this case...)

There is something to this effect in Section 2.4 of the draft mib author's
& reviewer's guidelines.

> In other words, rather than spending time to write down how to tweak
> specific tools to not carefully check what is written down in the
> SMIv2 specs, I would prefer a sentence which says that there is
> consensus that this rule serves no purpose and then tools will just
> get changed.

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.

In all the cases in my experience where this issue has arisen the
MIB authors have used long descriptors for exactly the right reasons
(uniqueness and clarity), so I turn the namelength-32 check off as a
matter of routine anymore.  If you think that stronger language would
is warranted, that's OK with me (but it would be nice to get an explicit
proposal for new text).

Thanks,

Mike