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

[Wes Hardaker <hardaker@tislabs.com>]

>>>>> On Wed, 16 Apr 2003 13:01:35 -0700 (PDT), "C. M. Heard" <heard@pobox.com> said:

C> This discussion has been dormant for about a week, and I do need to
C> proceed with finalization of my MIB review comments for the ADs.  So
C> unless I hear some very convincing arguments to the contrary before
C> Tuesday, 22 April 2003, my review comments will advise that all the
C> enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC have the
C> SYNTAX value changed to the appropriate Unsigned32 subrange, and
C> that the MIB module be maintained by the WG, not by IANA.

Well, sorry for the delay (out of town) in input from me (I'm one of
the authors of the IPSEC-POLICY-MIB that will be affected by this in
the end).  In short, I certainly understand the problem.  However, I'm
not convinced we're going the right way with the decision.  So a quick
recap of common knowledge at this point:

A) enumerated TCs, like those in this MIB, are used for a few
   purposes:

   i)  standardizing and maintaining a standardized definition list.
   ii) Enabling automated parsing of the MIB so that automatic
       translations can be used where possible by management
       applications.  This, in my opinion, is the biggest win for using
       an enumerated TC.

B) The problem is that the IPsec protocols have various places where
   an integer is used on-the-wire with a "range" of standardized
   values that do not fall into the maximum allow within the coding of
   the packet itself.  The rest of the values fall into "enterprise"
   specific values and will not ever be assigned by a standards body
   (read: IANA).  We'll come back to this.

C) MIBs containing standardized TCs get updated frequently.
   Management applications MUST be able to handle values that fall
   outside of enum ranges already.  MIBs get updated to add new TCs
   all the time, and management applications must realize that the
   copy "they" have may not be up to date compared to the copy the
   agent is implementing.  A perfect example of this is the
   IANAifType-MIB, which defines the IANAifType TC that gets frequent
   updates (there were 4 REVISIONS statements in 2002).

The problem stems from the wording in the text of the of the
IPSEC-ISAKMP-IKE-DOI-TC mib that says certain ranges of the values are
"reserved" for private use.

So, there are three options:

1) Leave things as is.

2) The proposed switch to an Unsigned32 with descriptions/references
   in the DESCRIPTION and REFERENCEs clauses or in SMIv2 "--"
   comments.

3) Reword the "out of scope" statement so it's more friendly and less
   controversial.  This is my new thought and suggestion.

The problem with 1 is that no one likes the wording and it's generally
believed to be "illegal" by the MIB experts.  The problem with number
2 is that it decreases the benefit ("A ii" from above) when it comes
to actually using the TC in the first place.  Can anyone honestly name
a *technical* reason why a value that falls out of scope of a defined
enum list would cause a technical problem in a management application
or agent?  I'd argue that due to C above that in the end the
applications that implement this TC won't care either way.  Either way
they'll have to deal with unknown values.  That means that the only
real gain here by a Unsigned32 is for human reasons (and maybe the
administrative burden of maintaining two lists [eg, RFC2407 and the
RFC this will be published in] is a real problem, I don't know.  I
don't work for IANA and don't know the type of document tracking and
editing tools available to them).  The real loss is the automated
parsing of the enums by management applications that want to display
something other than "10" after Espv7 comes out and gets assigned to
the number 10 on the wire, eg.

So my suggestion is not to retype but to change the wording in the MIB
to make it more friendly to IANA and the IETF while still allowing for
enums to be used for all the values defined by the IETF.

Instead of:

     The values 249-255 are reserved for private use
     amongst cooperating systems.

I suggest something like:

     As described in RFC 2407 section 4.4.1, the range of values that
     will be assigned by IANA for use in this TEXTUAL-CONVENTION and
     the IPSEC DOI will fall between 0 and 248.  Values in the range
     249-255 will not be utilized within IETF standardization
     documents.

Any chance this would be a better technical and human middle ground?

-- 
Wes Hardaker
Network Associates Laboratories