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

[Andy Bierman <abierman@cisco.com>]

At 04:00 PM 4/7/2003 -0700, Randy Presuhn wrote:
>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.

I agree with Randy.  If they are leaving enum values unspecified
so vendors can assign their own value, then this is a misuse of
enumerated INTEGER.  If enums are really the appropriate data type,
and they know now that they want specific values defined, then
all enum values should be listed and documented.


>Randy

Andy