[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, 17 Apr 2003, Wes Hardaker wrote:
> 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.

I can easily understand how this is useful in a MIB browser whose
understanding of the underlying data is limited to what it can parse
from the MIB module.  I have more trouble understanding how it helps
very much for a more sophisticated application that has built-in
knowledge of the underlying MIB objects.  This is especially true, I
should think, of a configuration application, such as might be built
on top of the IPSEC-POLICY-MIB module.

To be more specific, let's consider the IpsecDoiIdentType TC, which
is used in some of the read-create objects in IPSEC-POLICY-MIB.
The underlying data item in the protocol allows for IANA-assigned
values in the range 1..248 (0 is reserved) and sets aside values in
the range 249..255 for private use between consenting parties.
Now, two of the enumerations are these:

                       idDerAsn1Dn(9),     -- the binary DER encoding of
                                           -- ASN1 X.500
                                           -- DistinguishedName
                       idDerAsn1Gn(10),    -- the binary DER encoding of
                                           -- ASN1 X.500 GeneralName

I can easily believe that the enum label might appear in a drop-down
box or the like, and that would be nice.  But, it's clearly not
enough if you want to provide meaningful help text.  for that it
would be necessary to capture the stuff in the ASN.1 comments or
something like it.  And presumably you also want to allow users to
set values by number, both in the IANA-assigned range (e.g., for new
assignments that are not yet known to the software) and in the
private use range (to accomodate customer protocols that might use
such values), but you want to limit the range to valid values
(1..255 or maybe 0..255).  For this your management application
needs more knowledge than can be obtained from the parseable
information in an enumerated INTEGER TC.  That has to be built in.
The subranged Unsigned32 lacks the labels for the assignments, but
it at least has the proper range limits.  One could argue that this
is even more important to have than the enum labels.

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

I'm not sure what you mean by this.  The range of "standardized"
values is always a subset of that can be coded in the packet.

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

This certainly is true.  Both monitor apps and configuration apps
have to accomodate this.  The difference for something like
IANAifType is that it conforms to SMI requirements and user
expectations for enumerated INTEGERs , while something like
IpsecDoiIdentType does not.

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

That's not a problem in the DESCRIPTION clauses;  they are actually
correct in doing this because it properly reflects the underlying
protocol specification.

The problem, rather, is that the enumerated INTEGER SYNTAX is not
(according to SMI rules and user expectations) consistent with such
a description.

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

There should be no commentary listing assigned values, but rather
the there should be a pointer to the IANA registry (one version of
the truth, please).

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

Agreed.

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

I think I've at least partly answered the arguments about the loss
of functionality (i.e. that it's not as much as it appears to be
for applications that have built-in MIB knowledge).

The extra burden on IANA is a very real concern, and when I started
the review of this MIB module most of the comments I wrote were
related to changes that I thought would be necessary in order to
make that tractable.  One either needs to reorganize the IPsec
registries so that this MIB module is the one version of the truth
for the stuff it covers (problematic because it does not cover
everything), or else one needs to update stuff in two places
(undesirable for the obvious reasons).

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

I think this would be a step backwards because it suggests that the
managed objects won't contain values in the range 249-255, which is
not the intent.  The managed objects are supposed to contain a
snapshot of what goes in an on-the-wire message, and the DESCRIPTION
clause and SYNTAX value should make that fact as clear as they
possibly can.

//cmh