Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Monday, April 07, 2003 3:18 PM
> Subject: FW: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt
...
> Here is one I had not encountered before:  folks who want to define
> enumerated INTEGER objects that are allowed to assume values that
> are not in the enumeration list.  Technically this is not legal (cf.
> RFC 2578 Section 7.1.1).  Practically, it does not seem that it
> should cause much harm, since enumerated INTEGERS can be extended by
> having more enumerations added.  In view of this, is the rule
> against assuming values other than the ones specifically enumerated
> just another crummy little rule that should not be enforced?  This
> would amount to treating enumerated INTEGER like ASN.1 does (i.e.,
> the enumerations are just distinguished values, but in no way
> constrain what values may be assumed).
>
> Opinions?
...

What bothers me about this proposal is not so much the notion of extending
enumerations without adjusting the documentation, but rather the semantic
ambigiuities that will result due to the lack of coordination of the enumeration
assignments.   For this kind of un-coordinated private use, OBJECT IDENTIFIERs
are really the way to go.  Otherwise, one has no way of knowing whether agent
A's 42 means the same thing as agent (or manager) B's.

Randy