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

[John Shriver <jshriver+ietf@sockeye.com>]

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