Re: Check enumerations

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Please remember, it's not just enums, but any reference
including the descriptors for objects and notifications.

As a first heuristic, you could scan DESCRIPTION clauses
as Juergen points out below. This would require the
pattern of <enum-name>(<enum-value>). Note that in 
the RFC, there were some places where this was
done. However, there were other places where
no "(<enum-value)" was specified. Thus, it would
be difficult to catch misspellings.

Please don't even thing about not specifying enum names
in DESCRIPTION clauses. In all MIB modules that I write,
each enum value is described in the DESCRIPTION clause.
Please note that many years ago my proposal for extending
the syntax of specifying enum values so that the
descriptions would be a parsable clauses was shot down.
We are living with the consequences of that decision.

I believe the best solution to this problem is a much
less painfull mechanism of gathering and publishing
errata (and making it known that an errata system
exists!). 


On Tue, 17 Jan 2006, Juergen Schoenwaelder wrote:
> On Tue, Jan 17, 2006 at 03:54:42PM +0100, Tom Petch wrote:
> 
> > RFC4327 just got published with a mixture of false(1), false(2),
> > true(1) and true(2) in the initial text and in DESCRIPTION clauses.
> 
> Looks like we need an errata which points out the problem and says
> that the SYNTAX clause is always right and takes precedence over
> DESCRIPTION clauses and examples.
> 
> > Any way any of the tools could catch that, for this or for other
> > enumerations?
> 
> Let me see what you are looking for. You want a check were a defined
> named number such as 'foo(42)' which appears literally in the text of
> related description, reference, compliance, ... clauses in the form
> 'foo(X)' where X is a number not identical to 42 causes a warning.
> 
> This does not sound very complicated to implement and I can't think of
> cases where this might trigger false positives.
> 
> One could in addition warn about cases where something like bar(42)
> shows up - but this might have more likely false positives since
> bar(42) might actually refer to a named number defined by some other
> TC.
> 
> /js

Regards,
/david t. perkins