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

From: "C. M. Heard" <[email-masked]>
Date: Mon, 7 Apr 2003 10:48:24 -0700 (PDT)

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 7 Apr 2003 14:06:37 -0700 (PDT)

[ [email-masked] included on the cc: list because this ]
[ message discusses IANA considerations in the draft. ]

On Mon, 7 Apr 2003, John Shriver wrote:
> 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.

If that is what is intended, then it needs to be clearly spelled out
in the IANA Considerations section.  In particular, it needs to be
stated that the IANA-maintained MIB module will replace portions of
the IANA ISAKMP Identifiers registry and the IANA IKE Attributes
registry (see http://www.iana.org/assignments/isakmp-registry and
http://www.iana.org/assignments/ipsec-registry respectively), and
detailed instructions on how to do this re-organization must be
provided.  The only statement to this effect that is now present is
in the second paragraph of the abstract:

   The MIB documented by this document will become a separate living
   document maintained by the IANA, and will be the document of record
   for these assignments.

and I mis-interpreted this.  I thought it was referring to the
fact that the IANA-maintained MIB module (and not the RFC-to-be)
would be definitive.

BTW, the reason I said "portions of" the registries is that the
following items in the IANA ISAKMP Identifiers registry don't
have any counterpart in the proposed MIB module:

 IPSEC Security Association Attribute Class
   SA Life Type
   Group Description
   Key Length
   Key Rounds
   ECN Tunnel
 IPSEC Labeled Domain Identifier

Likewise, the following attributes in the IANA IKE Attributes
registry don't have any counterpart in the proposed MIB module:

 Attribute Class
  Life Type
  Key Length
  Field Size
  Group Order

Some things would have to be added to the MIB module in order for it
to replace the existing registries outright.

> This is certainly what has happened with the ifType MIB,
> although that was MIB-centric.

Actually, it turns out that ifType values are listed both in the SMI
Numbers registry and in the IANAifType-MIB.  I believe, however,
that this postdates the existence of the IANAifType-MIB:  versions
of the now-discontinued "Assigned Numbers" RFC that preceded the
first version of the IANAifType-MIB in RFC 1573 did not list the
ifType assignments.  As far as I am aware, there was no IANA ifType
registry before RFC 1573.

> All programmers know that source-file synchronization is evil.

Yes, I agree with that.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 8 Apr 2003 13:07:18 -0700 (PDT)

John Shriver wrote:
> C. M. Heard wrote:
> John Shriver wrote:
> > > 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?
> > > 
[ ... ]
> > > 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.
> > 
> > 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.
[ ... ]
> We discussed the "standards fudge" issue of the non-enumerated values
> back [when this project was started], and people on the IPsec list
> weren't offended by the problem.  A common-sense standards bending
> didn't bother them.

The problem with bending the rules in this way is that it is
confounds expectations that people have (based on what is in
the standard) regarding what enumerated INTEGERs mean.  I put
this question to the other MIB Doctors and got these answers:

On Mon, 7 Apr 2003, Randy Presuhn wrote:
% What bothers me about this proposal is not so much the notion of
% extending enumerations without adjusting the documentation, but
% rather the semantic ambigiuities that will result due to the lack
% of coordination of the enumeration assignments.  For this kind of
% un-coordinated private use, OBJECT IDENTIFIERs are really the way
% to go.  Otherwise, one has no way of knowing whether agent A's 42
% means the same thing as agent (or manager) B's.

On Mon, 7 Apr 2003, Andy Bierman wrote:
% I agree with Randy.  If they are leaving enum values unspecified
% so vendors can assign their own value, then this is a misuse of
% enumerated INTEGER.  If enums are really the appropriate data type,
% and they know now that they want specific values defined, then
% all enum values should be listed and documented.

What the Randy's and Andy's comments are saying is that enumerated
INTEGERs are the wrong data type for this application not because of
an obscure technical violation of RFC 2578 but because this usage
violates the semantics that are expected of enumerated INTEGERs.  I
tend to agree with that, and that's why I have suggested subranged
Unsigned32 would be a more appropriate choice.

> I don't have time to dig the archives...

I looked in the ipsec archives back to 1998 and was not able to find
any discussion of this specific issue (it is entirely possible that
I missed something, in which case a pointer would be helpful). 

Thanks,

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 8 Apr 2003 16:00:56 -0700 (PDT)

On Tue, 8 Apr 2003, John Shriver wrote:
> A more straightforward description is that I tried to forge a compromise 
> between multiple design goals:
> 
> 1. Easy to [implement] on the product without pain.  (This is why I 
> export exactly what the protocol negotiated, no remapping to any other 
> space).

Subranged INTEGER/Integer32/Unsigned32 can accomplish this.

> 2. Easy to use, in that the normally used values are displayed as an 
> enumeration, even on commonly available free SNMP implementations.

Subranged INTEGER/Integer32/Unsigned32 cannot accomplish this.

> 3. Avoid the never reaches full standard problem by having the TC MIB 
> managed by the IANA.

Subranged INTEGER/Integer32/Unsigned32 can accomplish this.

> I will warn that the IPsec implementors in this working group are VERY 
> harsh about any MIB proposals that intrude deeply into performance. 
> There have been very contentious discussions.  They really aren't very 
> interested in SNMP in the first place, which is obvious by the very 
> minimal feedback all discussions of the MIBs have produced.  They won't 
> bend very far to implement a MIB.
> 
> An approach that doesn't meet goal 1 won't get implemented.

Fair enough.

> If strict RFC 2578 conformance is the only way that IPsec MIBs can be 
> published, I can assure you that goal 2 will be dropped in favor of goal 
> 1.  Having to map every sort of protocol number into a Object Identifier 
> (Andy's approach) is going to be quite unpopular, even if approved by 
> the working group, I doubt it would get the "implement it" vote.

Well, here is the advice from another MIB Doctor:

On Tue, 8 Apr 2003, David T. Perkins wrote:
% Sometimes it is not appropriate or worth the cost of putting things
% in a MIB module that work better as information that augments the
% MIB module. In this case, I would define the object type with
% data type "Unsigned32", and specify in the DESCRIPTION clause
% the semantics of the ranges. In the REFERENCE clause, I would
% put the information (and if available, a URL) so that some one
% could track down the current assignments.
% 
% That's my $.02 worth of advice.
% 
% PS Hint: See the definition of TC SnmpSecurityModel.

That is essentially what I suggested earlier.  If you care to look,
SnmpSecurityModel is defined in the SNMP-FRAMEWORK-MIB, which in
turn is part of RFC 3411 (ftp://ftp.isi.edu/in-notes/rfc3411.txt).
It's the model I had in mind.

I don't think that a shift to this approach would have much (if any)
impact on the MIB modules that use the TCs defined in
<draft-ietf-ipsec-doi-tc-mib-07.txt>.  It would comply with the SMI,
and it would avoid the need to supplement/change the IPsec-related
IANA registries.  And you could include the titles and URLs of those
registries in the relevant TC DESCRIPTION clauses.

As I said before, I don't have the power (nor do I wish) to force
you to do anything ... I only give advice.  But, that's my advice.

Thanks,

Mike

P.S.  I can certainly sympathize with your being unhappy at having
this suggestion arrive so late in the process ... your first I-D,
if I correctly understood what I saw in the IPsec mailing list
archives, appeared in February 1999.  I can only apologize and
say that you have a legitimate complaint about that.  -- cmh

---

From: John Shriver <[email-masked]>
Date: Mon, 07 Apr 2003 15:02:01 -0400

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

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.

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

> undesirable.  I think such edits should be discouraged.

So should private use numbers be discouraged.

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

> that have private use ranges of 61440-65535, 65001..65535, or

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

---

From: John Shriver <[email-masked]>
Date: Tue, 08 Apr 2003 16:56:18 -0400

> % means the same thing as agent (or manager) B's.

This applies EQUALLY to the ISAKMP/IKE protocol definitions. 
Implementation A's 64411 is indistinguishable from Implementation B's 
64411.  Even if they mean totally different things.  (Most are used in 
cases where Implementation A can tell if it is talking to one of it's 
own species.)

We are trying to design MIBs, and TCs, that can document the actual 
behavior of the protocol.  If the protocol is a bit screwy, that's life. 
  (Let's just say that ISAKMP/IKE does not comform to RFC 2578, at least 
in spirit.)

> % all enum values should be listed and documented.

The vendors are not assigning the numbers for the purpose of the MIB, as 
noted above, they are assigning it for the purpose of the protocol.  I 
would never have proposed this approach if these TCs were not VERY 
tightly coupled to the protocol.

(There was a place in the real MIBs that were once part of this effort 
where I did use Object Identifiers for cross referencing.  See 
saOakleyGroup in the long-expired draft-ietf-ipsec-ike-monitor-mib-02.txt.)

1. Easy to impelement on the product without pain.  (This is why I 
export exactly what the protocol negotiated, no remapping to any other 
space).

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 16 Apr 2003 13:01:35 -0700 (PDT)

[ authors of draft-ietf-ipsp-ipsec-conf-mib-06.txt bcc'd;  ]
[ please direct all discussion to [email-masked]  ]

Summary of the discussion so far:  I have pointed out to the WG that
all of the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC MIB
module in <draft-ietf-ipsec-doi-tc-mib-07.txt> (except for
IsakmpCertificateEncoding) are intended to represent data items that
have a certain range of values reserved for "private use amongst
cooperating systems."  Since values in these ranges are not subject
to standardization, there will be no enumerations for them.
However,  SMIv2 rules require (and MIB users/authors expect) that
objects defined with an enumerated INTEGER syntax will assume only
those values that are named in the enumeration list.  I have
therefore advised the WG (in my role as MIB reviewer) that the
SYNTAX value of all of the enumerated INTEGER TCs in the
IPSEC-ISAKMP-IKE-DOI-TC MIB module be changed to the appropriate
Unsigned32 subrange with the usages of the various ranges spelled
out in the DESCRIPTION clause (as is done now) and a pointer to the
IANA registry included.  This approach, which is the also used in
the SnmpSecurityModel TC from the SNMP-FRAMEWORK-MIB in RFC 3411,
has the added advantage of not imposing any extra workload on the
IANA to supplement or reorganize the existing IPsec and ISAKMP
registries.  The disadvantage of this approach is that applications
such as MIB browsers that don't have any built-in knowledge of the
underlying MIB objects can only display the integer value and not
the enumeration label, which makes the MIB modules harder to use.

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

I am aware of the following Internet Drafts that contain MIB modules
which use one or more of the TCs defined in IPSEC-ISAKMP-IKE-DOI-TC:

draft-ietf-ipsec-ike-monitor-mib-04.txt
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
draft-ietf-ipsec-monitor-mib-06.txt
draft-ietf-ipsp-ipsec-conf-mib-06.txt

Of these, it appears that only the last one would be affected by
the changes I intend to recommend.  It would be necessary to
change the object definition

ipspSaPreActActionType OBJECT-TYPE
    SYNTAX      IpsecDoiEncapsulationMode
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object specifies the encapsulation mode to use for the
         preconfigured SA: tunnel or transport mode."
    DEFVAL { tunnel }
    ::= { ipspSaPreconfiguredActionEntry 9 }

to

ipspSaPreActActionType OBJECT-TYPE
    SYNTAX      IpsecDoiEncapsulationMode
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object specifies the encapsulation mode to use for the
         preconfigured SA: tunnel or transport mode."
    DEFVAL { 1 } -- tunnel
    ::= { ipspSaPreconfiguredActionEntry 9 }

Regards,

Mike Heard

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Apr 2003 09:13:17 -0700

>>>>> On Wed, 16 Apr 2003 13:01:35 -0700 (PDT), "C. M. Heard" <[email-masked]> 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

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 17 Apr 2003 11:03:01 -0700 (PDT)

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

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.

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

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.

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

>    in the DESCRIPTION and REFERENCEs clauses or in SMIv2 "--"

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

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

> 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

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Apr 2003 23:05:41 -0700

>>>>> On Thu, 17 Apr 2003 11:03:01 -0700 (PDT), "C. M. Heard" <[email-masked]> said:

W> ii) Enabling automated parsing of the MIB so that automatic
W> translations can be used where possible by management
W> applications.  This, in my opinion, is the biggest win for using
W> an enumerated TC.

C> I can easily understand how this is useful in a MIB browser whose
C> understanding of the underlying data is limited to what it can parse
C> from the MIB module.

Many such browsers exist, yes.

C> I have more trouble understanding how it helps very much for a more
C> sophisticated application that has built-in knowledge of the
C> underlying MIB objects.  This is especially true, I should think,
C> of a configuration application, such as might be built on top of
C> the IPSEC-POLICY-MIB module.

There are both smart and generic tools, yes.  Smart tools will likely
display more information than the generic ones, as they will be
preprogrammed with additional information (eg, more humanly
understandable text to supplement or replace the enum labels).  They
will still benefit, however, from enum labels when the standard has
advanced faster than the installed software base.  Smart tools should
use better text when possible, enum labels when updated MIBs are
available but updated software is not, and finally generic numeric
values when all else fails.  This is true for both monitoring and for
configuration, IMHO.  (and specifically, don't forget that monitoring
and display of configuration data is also useful so just because a
variable is read-create or read-write doesn't mean you'll never do a
GET or GETNEXT on it).  Finally, generic tools will likely have only
labels to deal with and/or raw numbers.

...
C> idDerAsn1Dn(9),     -- the binary DER encoding of
C> -- ASN1 X.500
C> -- DistinguishedName
C> idDerAsn1Gn(10),    -- the binary DER encoding of
C> -- ASN1 X.500 GeneralName
...
C> I can easily believe that the enum label might appear in a drop-down
C> box or the like, and that would be nice.  But, it's clearly not
C> enough if you want to provide meaningful help text.
...

Everything you said in the deleted portions makes perfect sense.
Smart applications need more information to display better help text
for the user.  It must get this from comments, description clauses and
programmer knowledge.  I agree absolutely.  What I disagree with is
that smart tools will never need to be updated (or that they'll be
updated at the same time as the MIBs) and that we never need to worry
about generic tools.  I write both.  I'd prefer an enum list for both
sets of my tools.

C> The subranged Unsigned32 lacks the labels for the assignments, but
C> it at least has the proper range limits.  One could argue that this
C> is even more important to have than the enum labels.

This is a definite trade off here.  You can't have both an enum list
and a range list.  An over-site of SMIv2 that is a technical challenge
because parsers would actually break if we use both.  You could argue
that ranges are more important, but I'd argue against it.
Specifically, I'd put the ranges in the description clause (which even
generic tools can display for the end user) but use enums so those
pretty drop down lists can be auto-built when possible (and the smart
tools can use it as a double check).

W> B) The problem is that the IPsec protocols have various places where
W> an integer is used on-the-wire with a "range" of standardized
W> values that do not fall into the maximum allow within the coding
W> of the packet itself.

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

I think we said the same thing.  In different ways.

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

I still can't find a technical argument (and maybe I'm just missing
it) why it's a problem.  What will application will break if a agent
returns a value outside the assigned enum list?  None, since they all
have to deal with outside values now.  What agent will break when a
manager tries to set a value to an agent that it doesn't support?
None, since they must all deal with this anyway.  In fact, the
agent that receives a value outside the legal range of values will
already have to return the exact same error to the management app that
sent an illegal value in the first place.

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

Final question: You keep coming back to this.  Does this mean that
there is no use for TCs of enums?  IE, why do we have machine-readable
enums in the first place if if all applications must have built in
knowledge?  It seems your trying to make a point that applications
must have built-in MIB knowledge, in which case we never need
machine-readable enums in the first place?

C> The extra burden on IANA is a very real concern, and when I started
C> the review of this MIB module most of the comments I wrote were
C> related to changes that I thought would be necessary in order to
C> make that tractable.

If that is the reason you want to oppose the use of enums, then it
is a more understandable argument from my eyes at least.
Unfortunately, there is still functionality lost if this is the case.
Does it mean we should never create enums in MIBs when it is supposed
to match another standards document?  We should always use references
and no real values (in enums, description clauses or comments) in that
case?

I would argue that the administrative burden isn't as big a problem
either.  It's certainly going to be the case that the protocol
documents will be updated with new values first.  The MIB will never
have new enums inserted into it before the protocol is defined that
uses those new values.  Thus, the MIB should always be a direct mirror
of the protocol (a frequent case).  If the MIB fails to get updated at
the same time as the master standards document, there is no technical
problem that I can see.  In fact, it's just as if an Unsigned32 had
been used for those unknown values that were being returned/sent.

Now, the one administrative problem that I could see is that human
errors always seem to sneak in.  The worst of which would be a
reordering of the values in question.

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

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

Ok, good point.  How about:

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, while legal values on the wire may
fall between 0 and 255.  Values in the range 249-255 will not be
utilized within IETF standardization documents.

My whole goal here is to increase the usability of the MIB that tools
will read.  IMHO, enums are very useful and unless there is a
technical reason why it causes a serious problem to use them in cases
like this, I just don't get why we're removing functionality that is
beneficial to some applications for no technical, engineering gain.
Engineering involves making choices intelligently so things don't
break, while attempting to provide the maximum possible benefit at the
same time.  IMHO, the best gain here is from using enums and I (at
least) have yet to see a reason why things would break.

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 18 Apr 2003 04:44:04 -0700 (PDT)

On Thu, 17 Apr 2003, Wes Hardaker wrote:
> What I disagree with is that smart tools will never need to be
> updated (or that they'll be updated at the same time as the
> MIBs) and that we never need to worry about generic tools.  I
> write both.  I'd prefer an enum list for both sets of my tools.
> 

OK, this makes your position very clear (and I think it is in
agreement with the sentiments expressed by the module author).

> have to deal with outside values now.

Agreed.

> What agent will break when a manager tries to set a value to an
> agent that it doesn't support? None, since they must all deal
> with this anyway.

Agreed.

> In fact, the agent that receives a value outside the legal range
> of values will already have to return the exact same error to
> the management app that sent an illegal value in the first
> place.

Depending on what you mean by "the legal range of values" this can
be a problem.  If you mean "the values in the enum list that are
know to the agent" (which is the behaviour mandated by RFC 2578
Section 7.1.1) then this IS a problem because for the DOI TCs the
agent should ACCEPT any value that is within the range defined for
the underlying protocol data item if (a) it does not require special
knowledge on the part of the agent to process it or (b) it is in the
"private use" range and the agent knows what to do with it.  Note
that in the latter case in particular, the value is _valid_ even
though it does not appear in the enum list.  Now, one could code
around this problem, but that won't be conformant to RFC 2578
Section 7.1.1, which says that "only those named-numbers so
enumerated may be present as a value."

> machine-readable enums in the first place?

The issue isn't whether machine-readable enums are appropriate in
general, but whether they are appropriate for objects where some of
the valid values will never appear in the enum list.

> either.

You might not think so when you've seen the details that apply to
this case.  Unfortunately, I need to leave right now for an
out-of-town trip, and I will have to defer the details of that
discussion (and the other points in your e-mail) until next week.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Apr 2003 06:49:02 -0700

>>>>> On Fri, 18 Apr 2003 04:44:04 -0700 (PDT), "C. M. Heard" <[email-masked]> said:

Wes> In fact, the agent that receives a value outside the legal range
Wes> of values will already have to return the exact same error to
Wes> the management app that sent an illegal value in the first
Wes> place.

C> Depending on what you mean by "the legal range of values" this can
C> be a problem.  If you mean "the values in the enum list that are
C> know to the agent" (which is the behaviour mandated by RFC 2578
C> Section 7.1.1) then this IS a problem because for the DOI TCs the
C> agent should ACCEPT any value that is within the range defined for
C> the underlying protocol data item if (a) it does not require special
C> knowledge on the part of the agent to process it or (b) it is in the
C> "private use" range and the agent knows what to do with it.  Note
C> that in the latter case in particular, the value is _valid_ even
C> though it does not appear in the enum list.  Now, one could code
C> around this problem, but that won't be conformant to RFC 2578
C> Section 7.1.1, which says that "only those named-numbers so
C> enumerated may be present as a value."

Ok, then how about changing my suggestion to:

  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, while legal values on the
  wire may fall between 0 and 255.  Values in the range 249-255 will
  not be utilized within IETF standardization documents as they have
  been reserved by the IPsec DOI for private use by cooperating
  devices.  All use of deviations from the standardized list of
  enumerations, including those that fall in the 249-255 range, must
  be documented within the appropriate AGENT-CAPABILITIES statements.

This documents that values from 249-255 won't be standardized, are
intended for use by private organizations, and finally reminds the
agent implementers that these other accepted/used values must be
documented in the standard way in which all agents are supposed to
document their deviation from a standardized SMIv2 document.
-- 
Wes Hardaker
Network Associates Laboratories

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 22 Apr 2003 16:26:26 -0700 (PDT)

On Fri, 18 Apr 2003, C. M. Heard wrote:
> > On Thu, 17 Apr 2003, C. M. Heard wrote:
> > C> The extra burden on IANA is a very real concern, and when I
> > C> started the review of this MIB module most of the comments
> > C> I wrote were related to changes that I thought would be
> > C> necessary in order to make that tractable.
> > 
> > If that is the reason you want to oppose the use of enums, then
> > it is a more understandable argument from my eyes at least.
> > Unfortunately, there is still functionality lost if this is the
> > case.  Does it mean we should never create enums in MIBs when it
> > is supposed to match another standards document?  We should
> > always use references and no real values (in enums, description
> > clauses or comments) in that case?
> > 
> > I would argue that the administrative burden isn't as big a
> > problem either.
> 
> You might not think so when you've seen the details that apply
> to this case.  Unfortunately, [ ... ] I will have to defer the
> details of that discussion [ ... ] until next week.

Here is the promised discussion.  [email-masked] have been bcc:'d
and are invited to weigh in with their opinions.

The reason why I forsee a significant adminstrative burden if the
MIB module in <draft-ietf-ipsec-doi-tc-mib-07.txt> is turned over
to the IANA for maintenance is that the number assignments captured
by the enumerated INTEGER TCs in that module overlap those recorded
in two existing IANA registries, namely the IANA Internet Security
Association and Key Management Protocol (ISAKMP) Identifiers
registry (http://www.iana.org/assignments/isakmp-registry) and
the IANA Internet Key Exchange (IKE) Attributes registry
(http://www.iana.org/assignments/ipsec-registry).  The implication
is that the IANA would have to maintain the assignments in two
places, or else would have to reorganize those registries so that
the proposed MIB module was the registry of record for the
parameters it covers.  The draft proposes the latter course of
action, but it should be noted that the existing registries would
not be eliminated, because the proposed MIB module does not cover
all of the parameters and attributes recorded in the registries.

It might be useful to make a side-by-side comparison of which
parameters and attributes are covered both in the MIB module and
the existing IANA registries, which ones appear in a registry
file (or one of the IPsec RFCs) but not in the MIB module, and
which ones appear in the MIB module but not in the registry files.

The parameters and attributes from the IANA Internet Security
Association and Key Management Protocol (ISAKMP) Identifiers
registry (http://www.iana.org/assignments/isakmp-registry) that are
captured by some textual convention in the draft are as follows:

 Parameter/Attribute Name                Textual Convention

 IPSEC Situation Definition              IpsecDoiSituation
 IPSEC Security Protocol Identifiers     IpsecDoiSecProtocolId
 IPSEC ISAKMP Transform Identifiers      IpsecDoiTransformIdent
 IPSEC AH Transform Identifiers          IpsecDoiAhTransform
 IPSEC ESP Transform Identifiers         IpsecDoiEspTransform
 IPSEC IPCOMP Transform Identifiers      IpsecDoiIpcompTransform
 IPSEC Security Association Attributes
   Encapsulation Mode                    IpsecDoiEncapsulationMode
   Authentication Algorithm              IpsecDoiAuthAlgorithm
 IPSEC Identification Type               IpsecDoiIdentType
 IPSEC Notify Message Types              IkeNotifyMessageType

 Notes:
        (a) In the case of IkeNotifyMessageType, only those
 enumerated values within the DOI-specific ranges 8192-16383 and
 24576-32767 are recorded in the registry.  The IkeNotifyMessageType
 TC also includes the DOI-independent values that are defined in RFC
 2408 Section 3.14.1 (and captured by the IsakmpNotifyMessageType
 TC).  Since the DOI-specific enumerations associated with the
 IkeNotifyMessageType TC are defined in RFC 2407 rather than RFC
 2409, it seems that it is mis-named and should probably have been
 called IpsecDoiNotifyMessageType.
        (b) The registry specifies that values in the range
 8192-16383 are error codes allocated for "private use within a
 DOI".  This agrees with RFC 2407 but apparently disagrees with RFC
 2408, which states that values in this range are for private use
 (but also states that values in the private use range are expected
 to be DOI-specific values).  The registry (and RFC 2407) also
 specify that status codes in the range 32001-32767 are reserved
 for private use among consenting systems;  however, while RFC 2408
 does allocates status codes in the range 24576-32767 for
 DOI-specific use, it also allocates status codes in the range
 32768-40959 for private use.  This confusion needs to be fixed.

The parameters and attributes from the IANA Internet Security
Association and Key Management Protocol (ISAKMP) Identifiers
registry (http://www.iana.org/assignments/isakmp-registry) that are
NOT captured by any textual convention in the draft are as follows:

 IPSEC Security Association Attribute Class
   SA Life Type
   SA Life Duration
   Group Description
   Key Length
   Key Rounds
   Compression Dictionary Size
   Compression Private Algorithm
   ECN Tunnel
 IPSEC Labeled Domain Identifier

 Notes:
        (a) SA Life Duration, Compression Dictionary Size, and
 Compression Private Algorithm are such that management of values by
 the IANA is not required;  however, Compression Dictionary Size and
 Compression Private Algorithm are mentioned in the registry, and
 TCs to represent them might be useful (although they might best be
 located in a MIB module that is not maintained by the IANA).
        (b) There is a section in the IANA ISAKMP registry for Group
 Description attribute values but that attribute is not mentioned
 here since its values are identical with those for the IKE Group
 Description attribute, which are listed in the IANA IKE Attributes
 registry discussed below.

The attributes from the IANA Internet Key Exchange (IKE) Attributes
registry (http://www.iana.org/assignments/ipsec-registry) that are
captured by some textual convention in the draft are as follows:

 Attribute Name                          Textual Convention

 Encryption Algorithm                    IkeEncryptionAlgorithm
 Hash Algorithm                          IkeHashAlgorithm
 IPSEC Authentication Methods            IkeAuthMethod
 Group Description                       IkeGroupDescription
 Group Type                              IkeGroupType
 PRF                                     IkePrf
 Additional Exchanges (XCHG values)      IkeExchangeType

 Notes:
        (a) In the case of IkeExchangeType, only those enumerated
 values within the DOI-specific range 32-239 are recorded in the
 registry.  The IkeExchangeType TC also includes the DOI-independent
 values that are defined in RFC 2408 Section 3.1 (and captured by
 the IsakmpExchangeType TC).
        (b) No PRF values are currently registered, and IkePrf is
 a subranged Unsigned32 type, not an enumerated INTEGER type.
 Since Unsigned32 and INTEGER have different over-the-wire
 representations and Unsigned32 does not admit enumerations, the
 base type would need to be changed to INTEGER in order for future
 registered values to be represented as enumerations.

The attributes from the IANA Internet Key Exchange (IKE) Attributes
registry (http://www.iana.org/assignments/ipsec-registry) and/or
RFC 2409 that are NOT captured by any textual convention in the
draft are as follows:

 Attribute Class
  Group Prime/Irreducible Polynomial
  Group Generator One
  Group Generator Two
  Group Curve A
  Group Curve B
  Life Type
  Life Duration
  Key Length
  Field Size
  Group Order

 Note:  Group Prime/Irreducible Polynomial, Group Generator One,
 Group Generator Two, Group Curve A, Group Curve B, and Life
 Duration are such that management of values by the IANA is not
 required, and their values are not listed in the IKE Attributes
 registry;  however, they are defined in RFC 2409 and TCs to
 represent them might be useful (although they might best be
 located in a MIB module that is not maintained by the IANA).

Certain of the textual conventions in the proposed MIB module
capture parameters and attributes which are not recorded in either
of the above-mentioned IANA registries, but which are mentioned in
the IPsec RFCs and in a a registry update proposal (accessible
on-line at http://www.vpnc.org/iana-ipsec/current-propsal.txt)
that was recently discussed on the [email-masked] mailing
list.  Here is the list of the "missing in action" TCs and where
the corresponding parameter or attribute is mentioned:

 Textual Convention              Where param or attrib is mentioned

 IsakmpDOI                       RFC 2407 Section 4.1,
                                 RFC 2408 Appendix A
                                 (see proposal item #16)

 IsakmpCertificateEncoding       RFC 2408 Section 3.9
                                 (see proposal item #13)

 IsakmpExchangeType              RFC 2408 Section 3.1
                                 (see proposal item #12, but
                                 note that it includes both
                                 the DOI-independent stuff in
                                 RFC 2408 Section 3.1 and
                                 the the stuff discussed in
                                 RFC 2409 appendix A that
                                 is specific to IKE, and so
                                 corresponds more precisely
                                 to the IkeExchangeType TC)

 IsakmpNotifyMessageType         RFC 2408 Section 3.14.1
                                 (see proposal item #10, but
                                 note that it includes both
                                 the DOI-independent stuff in
                                 RFC 2408 Section 3.14.1 and
                                 the the stuff discussed in
                                 RFC 2407 Section 4.6.3 that
                                 is specific to the IPsec
                                 DOI, and so corresponds
                                 more precisely to the
                                 IkeNotifyMessageType TC)

I hope that this comparison serves to shed some light on the
amount of work that would be necessary if the MIB module in
<draft-ietf-ipsec-doi-tc-mib-07.txt> is turned over to the IANA for
maintenance.  If the IPsec-related registry files remain structured
as they are presently, there will be a need to update at least one
TC (and in some cases two TCs) when a new value is registered for
most IPsec parameters.  If the TCs in the MIB module become
authoritative and duplication is eliminated, then there will be a
lot of restructuring work needed.  In either case the administrative
burden is non-trivial, and I think that is a reason for concern.
None of this would be necessary if the base types of the TCs were
changed to subranged Unsigned32 (like IkePrf) with a pointer where
appropriate to the existing IANA registry.

So the question (leaving aside for the moment the questions of
legality under SMI rules) is whether the benefits of having the
enumeration labels are worth the administrative burden.  Remember
the burden will be borne not only by the IANA but also by document
authors who have to generate the instructions to add new things to
the registries.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 23 Apr 2003 00:11:11 -0700 (PDT)

> document their deviation from a standardized SMIv2 document.

There are a couple of problem with this proposal that I'd like to
point out.  For concreteness, note that the specific TC to which
this suggestion pertains is IpsecDoiSecProtocolId, whose definition
is as follows:

 IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION "These are the IPsec DOI values for the Protocol-Id
                 field in an ISAKMP Proposal Payload, and in all
                 Notification Payloads.

                 They are also used as the Protocol-ID In the
                 Notification Payload and the Delete Payload.

                 The values 249-255 are reserved for private use
                 amongst cooperating systems."
     REFERENCE   "RFC 2407 section 4.4.1"
     SYNTAX      INTEGER {
                     reserved(0),        -- reserved in DOI
                     protoIsakmp(1),     -- message protection
                                         -- required during Phase I
                                         -- of the IKE protocol
                     protoIpsecAh(2),    -- IP packet authentication
                                         -- via Authentication Header
                     protoIpsecEsp(3),   -- IP packet confidentiality
                                         -- via Encapsulating
                                         -- Security Payload
                     protoIpcomp(4)      -- IP payload compression
                 }

Presumably, the proposed text is intended to replace the third
paragraph of the DESCRIPTION clause of this TC.  (As an aside, note
that the proposed text should point to RFC 2407 section 6.3 rather
than 4.4.1 and that the REFERENCE clause should mention section 6.3
as well as 4.4.1).

Observe that it is not permissible to specify something like this

         SYNTAX  IpsecDoiSecProtocolId {
                     protoIsakmp(1),
                     protoIpsecAh(2),
                     protoIpsecEsp(3),
                     protoIpcomp(4),
                     protoIpsecCompanyProprietary(249)
                 }

in a VARIATION clause of an AGENT-CAPABILITIES statement.  That is
an illegal refinement, and at least some MIB compilers (SMICng is
one) will reject it.  The same is true, of course, of WRITE-SYNTAX.
So the only way to document deviations from the standardized list of
enumerations within an AGENT-CAPABILITIES statement is to do it in a
DESCRIPTION clause.  That can be done in a VARIATION description for
objects that have a MAX-ACCESS value greater than not-accessible,
but must be done in the AGENT-CAPABILITIES description for index
objects that have a MAX-ACCESS value of not-accessible because
VARIATION clauses are not allowed for such objects.  As it turns
out, all but one of the uses of this TC in the three MIB modules
that use it (and both of the uses in the IPSEC-POLICY-MIB) are in
the definitions of inaccessible index objects, so the state of
affairs is not a very satisfactory one.

Very similar limitations apply to MODULE-COMPLIANCE statements.

My conclusion is still that use of enumerated INTEGER in a manner
that is inconsistent with the semantics defined in the SMIv2 RFCs
is something to be avoided.  Yes, it can probably be made to work
over the wire, but it messes up the meaning not only of object
definitions, but also of compliance statements and capabilities
statements.  It is hard to predict how it will interact with tools
such as automated code generators for method routines or indexing
routines that expect standards-compliant behaviour.  In my opinion,
such practices have no place in standards-track MIB modules;
implementors have a right to expect standards-compliant behaviour.

Regards,

//cmh

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 24 Apr 2003 07:32:18 -0700

>>>>> On Wed, 23 Apr 2003 00:11:11 -0700 (PDT), "C. M. Heard" <[email-masked]> said:

C> Presumably, the proposed text is intended to replace the third
C> paragraph of the DESCRIPTION clause of this TC.

(yes, although it was an "example".  I was hoping it would be used as
a template for the rest of the TCs being discussed too).

C> Observe that it is not permissible to specify something like this

C> SYNTAX  IpsecDoiSecProtocolId {
C> protoIsakmp(1),
C> protoIpsecAh(2),
C> protoIpsecEsp(3),
C> protoIpcomp(4),
C> protoIpsecCompanyProprietary(249)
C> }

C> in a VARIATION clause of an AGENT-CAPABILITIES statement.  That is
C> an illegal refinement, and at least some MIB compilers (SMICng is
C> one) will reject it.

Sad, unfortunately.  Ok, if that is illegal than it'll have to be
described in a DESCRIPTION clause, as you mentioned.  (there are many
types of agent exceptions/changes that can only be documented in the
description clause).  It's likely the need to document these
exceptions will be rare, fortunately.

C> My conclusion is still that use of enumerated INTEGER in a manner
C> that is inconsistent with the semantics defined in the SMIv2 RFCs
C> is something to be avoided.

We'll likely just have to disagree when this discussion is over, I'm
sure.  I do understand your point of view, of course and I think you
understand mine so we're probably out of things to say :-/

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 24 Apr 2003 08:12:12 -0700 (PDT)

> understand mine so we're probably out of things to say :-/

I think that is a fair assessment, and it is time to move on.  I
shall attempt to get the MIB review comments written up not later
than next Monday, 28 April 2003.

//cmh

---

From: John Shriver <[email-masked]>
Date: Thu, 24 Apr 2003 13:35:54 -0400

>  called IpsecDoiNotifyMessageType.

While these numbers may be defined in RFC 2407, they are not generic 
ISAKMP numbers, they are specific to the use of IKE over ISAKMP.

The TC-MIB was sectioned in what was believed to be a rational way, 
based on the real layering of the protocols.  (The same applied to the 
MIBs that were developed along with it, one was pure IPsec, the next was 
ISAKMP, the next was IKE.)  The partitioning was not artifically 
"adjusted" to match odd partitioning of the protocols between the RFCs, 
and instead reflects the real layering.

Ironically, IKEv2 removes some of this layering.

As for the duplication of values between IsakmpNotifyMessageType and 
IkeNotifyMessageType, that is necessary because the SMI doesn't allow a 
syntax for an object that is the "union" of several enumerations or TC's.

>  32768-40959 for private use.  This confusion needs to be fixed.

Are you complaining about RFC 2407 and RFC 2408 being inconsistent and 
disagreeing?  This part of why IKEv2 is being documented in one 
document, to simplify ensuring internal consistency.

An ISAKMP DOI is apparently rather free to redefine what ISAKMP itself 
doesn't define.

I don't think that this issue is worth much concern, because ISAKMP will 
be irrelevant when IKEv2 is baked.

Interestingly, IKEv2 deprecates a group of these values, and defines a 
good dozen new ones.  (If someone wants to argue that the TC-MIB should 
be "collapsed" a bit in anticipation of IKEv2, that's not that bad an 
idea, although it would break other MIBs that depend on it.)

(IKEv2 was one of the reasons that I figured this MIB project was 
lingering, IKEv1 isn't going to reach Full Standard.)

>  IPSEC Labeled Domain Identifier

This is a possible argument for not making the TC-MIB the definitive 
reference on the IANA assignments.

Another approach would be to refactor the assignments, those that are in 
the TC-MIB move there, and the rest stay in the plain text files.

>  the IsakmpExchangeType TC).

Yes, I see that the supersetting/nesting of the TC's makes it awkward to 
use this TC-MIB as the definitive IANA reference for these values.

>  registered values to be represented as enumerations.

No problem changing this to INTEGER, since it's got enough precision to 
handle 0-65535.  On the other hand, if we're not doing enumerations 
(except in DESCRIPTION), it's moot, and the real protocol number is an 
"Unsigned16", which is more like Unsigned32 than it is like INTEGER.

>  located in a MIB module that is not maintained by the IANA).

Since there were no magic values, these group numbers were not TC'd. 
The IKE Monitoring MIB did have tables with them in them (OCTET STRING 
(SIZE (0..511)), however I think that some of the latest groups probably 
have generators larger than 511 bytes (or the next generation will).

> appropriate to the existing IANA registry.

Changing from enumerations to Unsigned32 does not solve the maintenance 
problem.  We still want to keep the descriptions up to date.  If we 
don't keep the descriptions up to date, we might as well not have a 
TC-MIB.  Cut & paste will do in that case...

> authors who have to generate the instructions to add new things to

On the other hand, the number of assignments has been small.  Most have 
been efforts to work around the limitations of ISAKMP/IKEv1.  With IKEv2 
being far more feature-rich (requirements based), I suspect that there 
will be even less change.

I can fully see either of two alternatives:

1. IANA refactors the IPsec registries to eliminate overlap with the 
TC-MIB, and the TC-MIB is authoritative on what it covers.

2. IANA maintains the TC-MIB separately, keeping it in sync with the 
registries.

I do not see the alternative of maintaining the TC-MIB under the RFC 
process as useful, since that will prevent anything using it as a 
normative reference from ever reaching Full Standard.

> Mike Heard

John Shriver

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 24 Apr 2003 15:11:30 -0700 (PDT)

On Thu, 24 Apr 2003, John Shriver wrote:
> The TC-MIB was sectioned in what was believed to be a rational
> way, based on the real layering of the protocols.  (The same
> applied to the MIBs that were developed along with it, one was
> pure IPsec, the next was ISAKMP, the next was IKE.)  The
> partitioning was not artifically "adjusted" to match odd
> partitioning of the protocols between the RFCs, and instead
> reflects the real layering.

OK, thanks for educating me on this point.  I assumed that the
DOI-specific message types pertained to the IPsec DOI of ISAKMP
(rather than IKE) partly because of the following words in the
DESCRIPTION clause of the IkeNotifyMessageType TC:

                   This textual convention is a merge of values
                   defined by ISAKMP with the additional values
                   defined in the IPsec DOI.

On this point I'll most certainly defer to those who actually know
what goes on in these protocols.

> As for the duplication of values between IsakmpNotifyMessageType
> and IkeNotifyMessageType, that is necessary because the SMI
> doesn't allow a syntax for an object that is the "union" of
> several enumerations or TC's.

That was understood.

> Are you complaining about RFC 2407 and RFC 2408 being
> inconsistent and disagreeing?

Yes :)

> This part of why IKEv2 is being documented in one 

OK.  Thanks for the education.

> An ISAKMP DOI is apparently rather free to redefine what ISAKMP
> itself doesn't define.
> 
> I don't think that this issue is worth much concern, because
> ISAKMP will be irrelevant when IKEv2 is baked.

What _is_ relevant is what to put in the TC DESCRIPTION clause with
respect to the use to which various ranges in the number space are
put.  I guess that at this point the "de-facto" standard is the
usage in RFC 2407, since the registry agrees with it.

> Interestingly, IKEv2 deprecates a group of these values, and
> defines a good dozen new ones.  (If someone wants to argue that
> the TC-MIB should be "collapsed" a bit in anticipation of IKEv2,
> that's not that bad an idea, although it would break other MIBs
> that depend on it.)

If the IPsec assigned number registries remain intact, it is
possible to write the MIB module in a way that is immune from such
changes. Details appear below.

> This is a possible argument for not making the TC-MIB the
> definitive reference on the IANA assignments.
> 
> Another approach would be to refactor the assignments, those
> that are in the TC-MIB move there, and the rest stay in the
> plain text files.

I agree that those two approaches could be made to work.

> use this TC-MIB as the definitive IANA reference for these values.

Right, because of the update-in-two-places problem.

[ ... remainder snipped ... ]

> Changing from enumerations to Unsigned32 does not solve the
> maintenance problem.  We still want to keep the descriptions up
> to date.  If we don't keep the descriptions up to date, we might
> as well not have a TC-MIB.  Cut & paste will do in that case...

I don't agree with that.  The SnmpSecurityModel TC in RFC 3411
(which is an Internet Standard) provides an alternate model that
avoids the maintenance problems.  An example modelled after it is
provided below.

> On the other hand, the number of assignments has been small.  Most
> have been efforts to work around the limitations of ISAKMP/IKEv1.  
> With IKEv2 being far more feature-rich (requirements based), I
> suspect that there will be even less change.
> 

Those alternatives can indeed be made to work.  Both impose some
extra administrative burden on the IANA.  #1 does so once up front,
#2 does so on an ongoing basis.

> I do not see the alternative of maintaining the TC-MIB under the
> RFC process as useful, since that will prevent anything using it
> as a normative reference from ever reaching Full Standard.

Again, I don't agree with that.  Using IpsecDoiSecProtocolId
as an example, here is how one could re-write the TCs in the
IPSEC-ISAKMP-IKE-DOI-TC module so as to avoid the need to
track updates to the registry.  This is modelled after the
SnmpSecurityModel TC in RFC 3411, but incorporates the
suggestion from Dave Perkins to include a pointer to the
registry where assignments can be found.  It also incorporates
the suggestion from Wes Hardaker to recommend that "private
use" values be documented in an AGENT-CAPABILITIES statement
if they are used.

IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Objects of this type represent IPsec DOI values
                for the IP Security Protocol Identifier (Protocol
                ID) field in an ISAKMP Proposal Payload, and in
                all Notification Payloads.  They may also represent
                values of the Protocol ID field in the Notification
                Payload and the Delete Payload.

                The value zero does not identify any particular
                security protocol.  It MAY be used in MIB objects
                to indicate that the security protocol is unknown
                or that none applies.  Any such use MUST be
                documented in the MIB object's DESCRIPTION clause.

                Values between 1 and 248, inclusive, are managed by
                the Internet Assigned Numbers Authority (IANA).
                Assigned values are recorded in the IPSEC Security
                Protocol Identifiers section of the IANA Internet
                Security Association and Key Management Protocol
                (ISAKMP) Identifiers registry (a URL for which is
                http://www.iana.org/assignments/isakmp-registry).

                The values 249-255 are reserved for private use
                amongst cooperating systems.  It is RECOMMENDED
                that implementations document the usage of such
                values in an AGENT-CAPABILITIES statement."
    REFERENCE   "RFC 2407 sections 4.4.1 and 6.2"
    SYNTAX      Unsigned32 (0..255)

Some wordsmithing may of course be necessary or desirable.

Changes (if any) as the MIB module advances on the standards track
could include updates to the STATUS clause (a TC might be deprecated
if it became obsolete, or if it was not used in defining objects
contained in two implementations), to the DESCRIPTION clause (e.g.,
if the URL of the registry changes -- one hopes not, those things
need to be stable), or the REFERENCE clause (if new documents are
issued).  But new number assignments would not have any effect, and
so would not hinder advancement on the standards track.

The disadvantage of this approach (as we all know by now) is the
loss of some machine readable information.  The advantages are that
it does not conflict with the formal requirements of the SMI and
that it does not impose any administrative burden on the IANA.

Does anyone else (other than John Shriver, Wes Hardaker, or
myself) care to express an opinion on these matters?

//cmh