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

["C. M. Heard" <heard@pobox.com>]

MIB Doctors --

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?

//cmh

---------- Forwarded message ----------
Date: Mon, 07 Apr 2003 15:02:01 -0400
From: John Shriver <jshriver+ietf@sockeye.com>
To: C. M. Heard <heard@pobox.com>
Cc: IPsec WG <ipsec@lists.tislabs.com>,
     "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

C. M. Heard wrote:
> On Sat, 5 Apr 2003, C. M. Heard wrote:
> % The WG needs to be aware that (according to RFC 2578 Section 7.1.1)
> % the only values allowed for objects defined with these enumerated
> % INTEGER TCs are the named numbers that are actually present in the
> % enumeration list.  Thus, managed objects defined with these TCs
> % cannot represent values in the ranges that are reserved for private
> % use amongst cooperating systems.  If it is intended that objects
> % defined using these TCs be able to represent arbitrary values of the
> % corresponding parameters, including the "private use" values, then a
> % SYNTAX value other than enumerated INTEGER will be required -- for
> % instance, Unsigned32 with a subrange, as is used in the definition
> % of IkePrf.  Of course, in that case there would be no need to have
> % the IANA maintain these TCs:  they could be defined once, in a
> % WG-maintained document, with the value list in a conventional
> % assigned number registry.
> 
> On Mon, 7 Apr 2003, John Shriver replied:
> 
>>Let me be sure that I understand your intent.  Because RFC 2578 Section
>>7.1.1 says that the only legal values of an enumeration are those in a
>>list, and there may be numbers in the list from the user-reserved space
>>that may not be in the list, we should abandon any effort to provide an
>>enumeration for any of these number spaces in any MIB for IPsec?
>>
>>Instead, they should all be range-limited INTEGERS[?]
> 
> 
> More probably, range-limited Unsigned32 (like IkePrf).  But yes, that's
> the idea, if the managed objects defined with these TCs are supposed to
> be able to represent all possible values of the corresponding parameter.
> 
> 
>>[A]nd there is no attempt at having software convert small
>>positive integers into strings that might make sense to a human,
>>and instead people have to look it up by hand?
> 
> 
> An enumerated INTEGER TC does not do quite that much.  All that can be
> done with the parseable information in such a TC is to build a table
> that converts the values in the enumeration list into the corresponding
> enumeration labels.  You don't get any of the descriptive text that is
> present in the ASN.1 comments.

As a user, I have found the enumeration labels much more useful than a 
raw number.  Few agents present the ASN.1 comments in a very accessible 
manner.  (Well, I never used any of the fancy $500,000 SNMP management 
systems.)

> 
> To be weighed against this benefit is the cost to the IANA of having to
> maintain both a conventional registry and a MIB module for the majority
> of the IPsec-related assigned numbers.  My past experience with stuff
> that requires two (or more) versions of the truth to be manually
> synchronized suggests to me that this cost will be rather high.  Note
> that some of the TCs (XyzExchangeType and XyzNotifyType) require
> synchronized updates in more than two places.

I would hope that the IANA would never try and keep two files 
synchronized.  As the I-D states, the itent was that the MIB would 
become THE definitive document.  This is certainly what has happened 
with the ifType MIB, although that was MIB-centric.

All programmers know that source-file synchronization is evil.

> 
> 
>>This strikes me as a disservice to the real customers, which are the
>>users of any IPsec MIBs.  (RFC 2578 is not a customer.)  The entire
>>purpose of this MIB was to eliminate those manual lookups.
> 
> 
> In retrospect, it might have been better if the SMI had adopted the
> ASN.1 rule that enumerations only specified distinguished values, and
> that the underlying type was allowed to have all INTEGER values (well,
> all in the range -2147483648..2147483647, since the SMI restricts
> INTEGER to that range).  But that wasn't what was decided, and the
> current rule is the one we have to live with.

I think that the current set of MIBs are not absolutely pure in 
adherence to the standards.

> 
> 
>>I was thinking that a customer using these MIBs who had a product using
>>a proprietary value would simply EDIT their copy of this MIB to include
>>the offending value.  There's no "do not edit under penalty of law" tag
>>on the MIB.
> 
> 
> Although not sanctioned by the SMI, a customer could indeed perform such
> edits.  However, they would have to be re-applied whenever the "official"
> version was updated with a new registered value, which is clearly
> undesirable.  I think such edits should be discouraged.

So should private use numbers be discouraged.

> 
> 
>>Rather than abandon the enumerations, I would instead propose to reserve
>>one value in each and every enumeration, which would represent all
>>values which are "undefined" within the enumeration.  The numeric value
>>of it would be 65536, which is out of the real protocol range for all
>>the numbers.
>>
>>Then MIB authors who need to reveal the user-reserved values can have a
>>second variable that reveals the raw INTEGER number.  (What fun!  But
>>I'm not writing that MIB.)
> 
> 
> That will work, since all of the items that have "private use" ranges
> don't include 65536 as a legitimate value.  Again, however, the question
> must be asked whether the automatic generation of integer-to-enum-label
> tables is worth the cost of using two objects to represent one value.

This was somewhat of a tongue-in-cheek suggestion.  I doubt that most 
MIB authors would go to the effort.  We'd just lose the information. 
(Or vendors would ignore the 65536, and put in the real value.)

> 
> 
>>Or, I can edit the MIB to give every enumeration a tag for every
>>reserved value.  Like on IpsecDoiSecProtocolId, add privateUse249(249),
>>privateUse250(250), privateUse251(251), etc.  But I can assure you that
>>many of the management agents out there would crash in flames if we do
>>that.  In my experience, they are exceptionally fragile...
> 
> 
> I agree that this would not be a good idea, especially for the ones
> that have private use ranges of 61440-65535, 65001..65535, or
> 32768..65535.
> 
> Frankly, I think that the benefits from the enum labels are not worth
> the costs in this application.  The costs include both the burden on
> the IANA of having to maintain synchronized registries and the need
> to have extra MIB objects to represent the "private use" values.  I
> think it would be better to use subranged Unsigned32 TCs in a
> WG-maintained MIB module, with the DESCRIPTION and REFERENCE clauses
> of those TCs pointing to the authoritative sources for the number
> assignments (namely the defining RFCs and the IANA registries).
> However, my role in this matter strictly advisory, and the decision
> is ultimately up to the IPsec WG (subject of course to IESG and IANA
> approval).

Well, I started this project 4 years ago because I thought that the 
enumeration values really would make IPsec MIBs easier to use.

We discussed the "standards fudge" issue of the non-enumerated values 
back then, and people on the IPsec list weren't offended by the problem. 
  A common-sense standards bending didn't bother them.  I don't have 
time to dig the archives...

> 
> Regards,
> 
> Mike Heard