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

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

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.

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.

> 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 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.

> 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.

> 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).

Regards,

Mike Heard