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

From: "C. M. Heard" <[email-masked]>
Date: Sat, 5 Apr 2003 11:56:03 -0800 (PST)

IPsec folks,

I've been commissioned to do the MIB doctor review for
<draft-ietf-ipsec-doi-tc-mib-07.txt> but before I spend a lot of
time discussing the details I'd like to ask a very basic (and I
think very important) question.

If I correctly understand what I have read, the main content of this
draft is a set of enumerated INTEGER TCs that represent the values
of fields in IPsec-related protocol messages.  However, in many of
these TCs (all, in fact, except for IsakmpCertificateEncoding) the
DESCRIPTION clause (or the underlying reference document) has a
statement to the effect that certain ranges of values are "reserved
for private use amongst cooperating systems."  Such values do not
presently appear as named numbers in the enumeration list, and my
understanding is that they will never appear in the enumeration list
since they are not subject to assignment by the IANA.

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.

I ask the WG to carefully consider whether an IANA-maintained MIB
module is really desirable in view of the above-described limitation
of enumerated INTEGER TCs.  It would be good to get an answer before
we spend a lot of time discussing detailed review comments.

Regards,

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 28 Apr 2003 13:13:00 -0700 (PDT)

IPsec folks,

This e-mail message contains the results of the MIB doctor review
for <draft-ietf-ipsec-doi-tc-mib-07.txt> that Bert Wijnen asked me
to do.  The review comments take into account the discussions that
have taken place on this list over the past three weeks.  The
authors of <draft-ietf-ipsec-flowmon-mib-tc-00.txt> are urged to
pay attention to these review comments, as many of them apply to
that draft too.

The main recommendations that I wish to make are (1) that the
enumerated INTEGER TCs in this draft have their SYNTAX values
changed to be a subrange of Unsigned32, and (2) that a pointer to
the IANA registry where the assigned values can be found be added
to the DESCRIPTION clause of applicable TCs, in lieu of having the
IANA maintain the content of the TCs themselves.  The reasons for
these recommendations (as discussed at length on the IPsec mailing
list over the last three weeks) are:  (1) the semantics of
enumerated INTEGER, as specified in RFC 2578 Section 7.1.1, do not
allow for objects of such a type to assume values other than those
explicitly enumerated, but objects defined using the TCs in this
draft are supposed to be able to assume private use values that
don't appear in the enumeration list;  and (2) the TCs in this draft
cover parameters that reside in existing registries, so if
maintenance of the MIB module in the draft is turned over to the
IANA then it will be necessary either to perform updates in multiple
places or else to restructure the IPsec registries.  Detailed
recommendations follow below.  Note that if these recommendations
(or equivalent changes) are implemented, then the MIB module in this
draft will be insulated from having to track changes in the IPsec
registries, and the document can be progressed along the standards
track like any other WG document.

The comments below follow the MIB review checklist from Appendix A
of <draft-ietf-ops-mib-review-guidelines-01.txt>.

1.) I-D Boilerplate -- OK

2.) Title, Abstract, and Discussion sections -- several changes
are suggested for these parts of the document.

Title:  RFC Editor policy (see Section 2.6 of
<draft-rfc-editor-rfc2223bis-04.txt>) states that acronyms in a
title should generally be expanded except when they are so
well-known that every member of the IETF should be expected to
recognize them immediately.  While IPsec probably qualifies, I don't
think that's true of DOI (at least, that one was not obvious to me).
So I suggest a revision along the following lines:

 IPsec Domain of Interpretation (DOI) Textual Conventions MIB

Abstract:  if the MIB module is restructured per the recommendations
then the abstract needs to be rewritten.  Something along the
following lines is suggested:

 This document defines textual conventions that represent parameters
 that appear in IPsec protocol messages.  In particular, it defines
 textual conventions for parameters that have value assignments in
 "magic number" spaces.

Discussion (Section 3):  in the fourth and following paragraphs
s/MIB/MIB module/, s/seperate/separate/, s/numberous/numerous/,
and wordsmith to reflect the changes recommended at the outset
of the review comments.  Here is the suggested text:

 This MIB module defines textual conventions for certain parameters
 in ISAKMP, the IPsec DOI, and IKE.

 These are defined in a separate MIB module for two reasons.

 o    There will be variables with a syntax corresponding to these
      textual conventions in numerous MIB modules that will be
      defined for the IPsec architecture.

 o    All of the parameters modelled by these textual conventions
      have value assignments in "magic number" spaces, and it is
      useful to have a single pointer to the registry entries or
      documents where the value assignments are recorded instead of
      having that information repeated in each object definition.

 One of the objectives for these textual conventions is to have the
 data representation for MIB objects defined with them be as close
 as possible to the on-the-wire representation of the ISAKMP/IKE
 protocol parameters that they represent.  Hence the SYNTAX value is
 a subrange of Unsigned32, rather than enumerated INTEGER or BITS.

Note:  here and elsewhere where words like "along the lines of" or
"along the following lines" appear it is intended that the document
editor shall wordsmith the suggested text as he or she sees fit.

3.) MIB Boilerplate -- the title of Section 2 needs to be changed to
"The Internet-Standard Management Framework" (as documented in
http://www.ops.ietf.org/mib-boilerplate.html) and the second
paragraph (i.e., the sentence at the end of page 2) needs to be
removed (it is a duplicate of the first sentence on page 3).

4.) IPR Notices -- OK, subject to one condition.  Section 5 contains
the required verbatim copies of the IPR notices specified in bullets
(A) and (B) of Section 10.4 of RFC 2026;  however, the WG must
affirm that bullet (D) is not needed because there are no IPR claims
known to the WG that are relevant to this document.

5.) References -- if the DESCRIPTION clause change recommendations
suggested in (11) below are accepted as is, then a normative
reference to RFC 2119 will need to be added.  Content is otherwise
OK, but the style differs from that used in recent RFCs.  Although
the RFC Editor can fix this, it might save some time if the document
author would do so instead.

6.) Security Considerations Section -- s/MIB/MIB module/, otherwise
it is OK.

7.) IANA Considerations Section -- should not be required if the
recommended changes are implemented, since the WG (and not the
IANA) will be maintaining the MIB module.

8.) Copyright notices -- OK

9.) MIB compilation -- OK.  No diagnostics were reported by the
smilint e-mail robot with default switches other than the expected
warnings for unreferenced TCs.  With the additional switch
"-i type-unref" to suppress these warnings no diagnostics were
reported at all:

 This is an automatically generated mail message in response to a
 mail message you (or someone else who used your address) sent to
 <[email-masked]>. If you want to learn more about this
 mail service, send a mail message with the "Subject: help" to
 <[email-masked]>.

 This command (smilint 0.4.2-pre1, as of Sat Mar 08 10:42:09 2003)
 has been processed to get the following results:
 smilint -m -s -l 6 -i namelength-32 -i type-unref IPSEC-ISAKMP-IKE-DOI-TC

 no errors found.

NOTE: this will have to be re-checked after the recommended changes
to the SYNTAX clauses and DESCRIPTION clauses are incorporated.

10.) Other issues -- if the DESCRIPTION clause change recommendations
suggested in (11) below are accepted as is, then a section defining
the use of the MUST, MAY, etc. keywords will need to be added (this
is in addition to adding a normative reference to RFC 2119, per (5)
above).  See section 2 of http://www.ietf.org/ID-nits.html

11.) Technical content -- here are the comments on the MIB module
itself.

(a) I suggest changing the following

   IMPORTS
   -- delete next line before release
      experimental,
      MODULE-IDENTITY, Unsigned32         FROM SNMPv2-SMI
   -- uncomment next line before release
   -- mib-2                               FROM RFC1213-MIB
      TEXTUAL-CONVENTION                  FROM SNMPv2-TC;

to

   IMPORTS
   -- RFC Ed.: delete next line & remove this note before publication
      experimental,
   -- RFC Ed.: uncomment next line & remove this note before publication
   -- mib-2,
      MODULE-IDENTITY, Unsigned32         FROM SNMPv2-SMI
      TEXTUAL-CONVENTION                  FROM SNMPv2-TC;

The purpose of this change is to import mib-2 from SNMPv2-SMI
rather than the by now out-of-date RFC1213-MIB and to make it
clear to the RFC editor which comment line are editor's
instructions that need to be removed when carried out.  Making
similar changes to all other ASN.1 comments that are editor's
instructions is likewise recommended.

(b) Please change the MODULE-IDENTITY descriptor from
ianaIPsecIsakmpIkeDoiTcMib to iPsecIsakmpIkeDoiTcMib (or
perhaps even better, to iPsecIsakmpIkeDoiTc -- that would
be in line with the naming conventions recommendeded by
Appendix E of <draft-ietf-ops-mib-review-guidelines-01.txt>).

(c) Please change the ORGANIZATION clause of the MODULE-IDENTITY
invocation to contain the official IPsec working group name and
please add the working group web page and mailing list info to
the CONTACT-INFO clause.  See section 4.5 of
<draft-ietf-ops-mib-review-guidelines-01.txt> for details.

(d) Please delete the second paragraph of the DESCRIPTION clause
of the MODULE-IDENTITY invocation, since it will no longer apply.

(e) The DESCRIPTION clause for IpsecDoiSituation should state that
the object is a 32-bit (not a four (4) octet) bit mask, since the
data type is Unsigned32 and not OCTET STRING (SIZE(4)), and it
should point to the appropriate IANA registry entry for the assigned
values instead of listing them.  Also, the REFERENCE clause should
point to RFC 2407 Section 6.1 (not 6.2).  Finally, the ASN.1 comment
at the end explaining why the data type is Unsigned32 rather than
BITS is no longer needed if the change to the last paragraph of
Section 3 recommended in (2) above is accepted.  A revised
definition along the following lines is suggested:

IpsecDoiSituation ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "x"
    STATUS      current
    DESCRIPTION "The IPsec DOI Situation is a 32-bit bitmask that
                provides information which can be used by a
                responder to make a policy determination about how
                to process an incoming Security Association request.

                Situation assignments for the low-order 30 bits are
                managed by the Internet Assigned Numbers Authority
                (IANA).  Assigned values are recorded in the IPSEC
                Situation Definition 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 upper two bits (0x80000000 and 0x40000000)
                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.2 and 6.1"
    SYNTAX      Unsigned32 (0..4294967295)

NOTE:  the IpsecDoiSituation TC is not used in any of the
four MIB modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB,
IKE-MON-MIB, and IPSEC-POLICY-MIB) that currently import TCs
from IPSEC-ISAKMP-IKE-DOI-TC.  Be aware that TCs which are not
used to define MIB objects that are included in two independent
implementations must be deprecated or obsoleted before the spec
containing them can advance beyond Proposed Standard.

(f) Per the general recommendations above, the SYNTAX value for
IpsecDoiSecProtocolId should be changed to Unsigned32 (0..255),
and the DESCRIPTION clause should point to the appropriate IANA
registry entry for the assigned values and should recommend that an
agent-caps statement document use of "private use" values.  Also,
the REFERENCE clause should point to RFC 2407 section 6.2 (in
addition to section 4.4.1).  A revised definition along the
following lines is suggested:

IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Managed objects of this type represent IPsec DOI
                values for the IP Security Protocol Identifier
                (Protocol ID) field in an ISAKMP Proposal Payload.
                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 usage 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).
                Assignments 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)

(g) The SYNTAX value for IpsecDoiTransformIdent should be changed to
Unsigned32 (0..255), and its DESCRIPTION clause should point to the
appropriate IANA registry entry for the assigned values and should
recommend that an agent-caps statement document use of the "private
use" values.  A revised definition along the lines of the one shown
in 11(f) is suggested.

(h) The SYNTAX value for IpsecDoiAhTransform should be changed to
Unsigned32 (0..255), and its DESCRIPTION clause should point to the
appropriate IANA registry entry for the assigned values and should
recommend that an agent-caps statement document use of the "private
use" values.  Also, the REFERENCE clause should point only to
RFC 2407 sections 4.4.3 and 6.4, which define the parameter and
its value assignment rules.  A revised definition along the lines
of the one shown in 11(f) is suggested.

(i) The SYNTAX value for IpsecDoiEspTransform should be changed to
Unsigned32 (0..255), and its DESCRIPTION clause should point to the
appropriate IANA registry entry for the assigned values and should
recommend that an agent-caps statement document use of the "private
use" values.  Also, the REFERENCE clause should point only to RFC
2407 sections 4.4.4 and 6.5, which define the parameter and its
value assignment rules.  A revised definition along the lines of the
one shown in 11(f) is suggested.

(j) It is suggested that the order of appearance of the definitions
of IpsecDoiAuthAlgorithm, IpsecDoiIpcompTransform, and
IpsecDoiEncapsulationMode be changed to IpsecDoiIpcompTransform,
IpsecDoiEncapsulationMode, and IpsecDoiAuthAlgorithm so that
all of the IpsecDoi-related stuff appears in the same order as its
counterparts in http://www.iana.org/assignments/isakmp-registry and
RFC 2407 (this will make it easier to audit the registries and the
specifications for mutual consistency).

(k) The SYNTAX value for IpsecDoiAuthAlgorithm should be changed to
Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the introductory text in the
DESCRIPTION clause should probably say just "Authentication
Algorithm" and not "ESP Authentication Algorithm", and the REFERENCE
clause should point only to RFC 2407 section 4.5 (which defines the
parameter).  A revised definition along the lines of the one shown
in 11(f) is suggested.

(l) The SYNTAX value for IpsecDoiIpcompTransform should be changed
to Unsigned32 (0..255), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the REFERENCE clause should point only
to RFC 2407 sections 4.4.5 and 6.6, which define the parameter and
its value assignment rules.  A revised definition along the lines of
the one shown in 11(f) is suggested (see also 11(z) below).

(m) The SYNTAX value for IpsecDoiEncapsulationMode should be changed
to Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, a REFERENCE clause which points to RFC
2407 section 4.5 should be added.  A revised definition along the
lines of the one shown in 11(f) is suggested.

(n) The SYNTAX value for IpsecDoiIdentType should be changed to
Unsigned32 (0..255), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the REFERENCE clause should point only
to RFC 2407 sections 4.6.2.1 and 6.9, which define the parameter and
its value assignment rules.  A revised definition along the lines of
the one shown in 11(f) is suggested.

(o) Although there are no private used values for IsakmpDOI, it is
still inappropriate to use an enumerated INTEGER type if values in
the range 2147483648..4294967295 need to be represented, as stated
in the DESCRIPTION clause and by RFC 2408 section 3.4.  One must
instead use a SYNTAX value of Unsigned32 (0..4294967295) and either
point to a registry entry where assigned values can be found or list
them in the DESCRIPTION clause.  Since this assigned values for this
parameter are not listed in any IANA registry the second option is
suggested.  Also, the REFERENCE clause should to RFC 2408 (not RFC
2048) and should probably mention sections 3.14 and 3.15 (in
addition to section 3.4) since the payloads documented in those
sections also contain a DOI value.  A revised definition along the
following lines is suggested:

IsakmpDOI ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Managed objects of this type represent Domain of
                Interpretation (DOI) values for the ISAKMP Protocol.
                They are 32-bit unsigned values used in the Domain
                of Interpretation field of the Security Association
                Payload, the Notification Payload, and the Delete
                Payload.  Currently assigned values are:

                isakmp(0)          generic ISAKMP SA in used for
                                   any protocol in Phase 2

                ipsecDOI(1)        the IPsec DOI as specified in
                                   RFC 2407

                At the present time there is no assigned number
                registry for ISAKMP DOI values.  A registry may
                be established and additional values may be
                assigned by the IANA at some future date."
    REFERENCE   "RFC 2408 sections 3.4, 3.14, and 3.15"
    SYNTAX      Unsigned32 (0..4294967295)

(p) Unlike all the other enumerated INTEGER TCs in this MIB module,
there are no private use values for IsakmpCertificateEncoding and
its value range is easily accomodated by the INTEGER data type, so
the only technical objection to the existing definition is that it
does not have an enumeration of corresponding to the value NONE = 0
that is listed in Section 3.9 of RFC 2408.  While this could be
easily remedied by adding none(0) to the enumeration list, there
would still remain the issue of how to keep the enumeration list
properly maintained.  It turns out, however,  that this TC is not
used in any of the four MIB modules IPSEC-SA-MON-MIB,
ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB, and IPSEC-POLICY-MIB that
import TCs from IPSEC-ISAKMP-IKE-DOI-TC.  So the recommended course
of action is to remove it from this MIB module and worry about the
issue when there is an actual need to do so.  An alternative course
of action would be to change the SYNTAX value to Unsigned32 (0..255)
and re-write the DESCRIPTION clause along the lines of 11(o) above.

(q) The SYNTAX value for IsakmpExchangeType should be changed to
Unsigned32 (0..31 | 240..255), and its DESCRIPTION clause should be
revised to specify that it represents only the values in the
DOI-independent or private-use ranges defined in RFC 2408 and to
recommend documenting use of the latter in an agent-caps statement.
A revised definition along the following lines is suggested:

IsakmpExchangeType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Managed objects of this type represent
                DOI-independent values of the Exchange
                Type field in the ISAKMP header.

                The value zero signifies an exchange type of NONE.
                It MAY be used in MIB objects to indicate that the
                exchange type is unknown or that none applies.  Any
                such usage MUST be documented in the MIB object's
                DESCRIPTION clause.

                Values between 1 and 31, inclusive, represent
                DOI-independent exchange types specified in
                RFC 2408 Section 3.1.   At the present time there
                is no assigned number registry for DOI-independent
                ISAKMP exchange type values.  A registry may be
                established and additional DOI-independent values
                may be assigned by the IANA at some future date.

                The values 240-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 2408 section 3.1"
    SYNTAX      Unsigned32 (0..31 | 240..255)

NOTE:  the IsakmpExchangeType TC is not used in any of
the four MIB modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB,
IKE-MON-MIB, and IPSEC-POLICY-MIB) that currently import TCs
from IPSEC-ISAKMP-IKE-DOI-TC.  Be aware that TCs which are not
used to define MIB objects that are included in two independent
implementations must be deprecated or obsoleted before the spec
containing them can advance beyond Proposed Standard.

(r) The SYNTAX value for IsakmpNotifyMessageType should be changed
to Unsigned32 (0..8191 | 16384..24575 | 32768..65535), and its
DESCRIPTION clause should be revised to specify that it represents
only the values in the DOI-independent or private-use ranges
defined in RFC 2408 and to recommend documenting use of the
latter in an agent-caps statement.  A revised definition along
the following lines is suggested:

IsakmpNotifyMessageType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Managed objects of this type represent
                DOI-independent values of the Notify Message
                Type field in the ISAKMP Notification Payload.

                This textual convention merges the types
                for error types (in the range 1-16383) and for
                status types (in the range 16384-65535).

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

                Values between 1 and 8191, inclusive, represent
                DOI-independent error message types specified in
                RFC 2408 Section 3.14.1.   At the present time there
                is no assigned number registry for DOI-independent
                ISAKMP error message type values.  A registry may
                be established and additional DOI-independent values
                may be assigned by the IANA at some future date.

                Values between 16384 and 24575, inclusive, represent
                DOI-independent status message types specified in
                RFC 2408 Section 3.14.1.   At the present time there
                is no assigned number registry for DOI-independent
                ISAKMP status message type values.  A registry may
                be established and additional DOI-independent values
                may be assigned by the IANA at some future date.

                Values in the range 32768-40959 are reserved for
                private use as status message types amongst
                cooperating systems.  It is RECOMMENDED that
                implementations document the usage of such
                values in an AGENT-CAPABILITIES statement.

                Values in the range 40960-65535 are reserved for
                future use."
    REFERENCE   "RFC 2408 section 3.14.1"
    SYNTAX      Unsigned32 (0..8191 | 16384..24575 | 32768..65535)

NOTE:  RFC 2408 Section 3.14.1 states that values in the range
8192..16383 are for private use, but also states that codes in
this range are expected to be DOI-specific.  Since RFC 2407
allocated DOI-specific error message codes from this range, the
DESCRIPTION clause above assumes that the range 8192..16383 is
DOI-specific and excludes that range from the allowed values.

(s) The SYNTAX value for IkeExchangeType should be changed to
Unsigned32 (0..255), and its DESCRIPTION clause should point to
the appropriate IANA registry entries for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the REFERENCE clause should point to
RFC 2408 sections 3.1 as well as RFC 2409 Appendix A.  A revised
definition along the following lines is suggested:

IkeExchangeType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Managed objects of this type represent values of
                the Exchange Type field in the ISAKMP header that
                pertain to IKE.

                The value zero signifies an exchange type of NONE.
                It MAY be used in MIB objects to indicate that the
                exchange type is unknown or that none applies.  Any
                such usage MUST be documented in the MIB object's
                DESCRIPTION clause.

                Values between 1 and 31, inclusive, represent
                DOI-independent exchange types specified in
                RFC 2408 Section 3.1.   At the present time there
                is no assigned number registry for DOI-independent
                ISAKMP exchange type values.  A registry may be
                established and additional DOI-independent values
                may be assigned by the IANA at some future date.

                Values between 32 and 239, inclusive, represent
                exchange types that pertain specifically to IKE.
                Assignments are recorded in the Additional
                Exchanges section of the IANA Internet Key Exchange
                (IKE) Attributes registry (a URL for which is
                http://www.iana.org/assignments/ipsec-registry).

                The values 240-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 2408 section 3.1 and RFC 2409 Appendix A"
    SYNTAX      Unsigned32 (0..255)

NOTE:  since the additional XCHG values for IKE are listed last
both in RFC 2409 Appendix A and  in the IKE Attributes registry
http://www.iana.org/assignments/ipsec-registry, it might be a
good idea to relocate this TC just after IkePrf (this will make
it easier to audit the registries and the MIB module for mutual
consistency).

(t) The SYNTAX value for IkeEncryptionAlgorithm should be changed to
Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the REFERENCE clause should point to
RFC 2409 Appendix A only, as this is the reference that defines the
parameter.  A revised definition along the following lines is
suggested:

IkeEncryptionAlgorithm ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Managed objects of this type represent values
                for encryption algorithms negotiated for the
                ISAKMP SA by IKE in Phase I.  These are values
                for SA Attribute type Encryption Algorithm (1).

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

                Values between 1 and 65000, inclusive, are managed
                by the Internet Assigned Numbers Authority (IANA).
                Assignments are recorded in the Encryption
                Algorithm section of the IANA Internet Key Exchange
                (IKE) Attributes registry (a URL for which is
                http://www.iana.org/assignments/ipsec-registry).

                Values 65001-65535 are for private use among
                mutually consenting parties.  It is RECOMMENDED
                that implementations document the usage of such
                values in an AGENT-CAPABILITIES statement."
    REFERENCE   "RFC 2409 appendix A"
    SYNTAX      Unsigned32 (0..65535)

(u) The SYNTAX value for IkeHashAlgorithm should be changed to
Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the REFERENCE clause should point to
RFC 2409 Appendix A only, as this is the reference that defines the
parameter.  A revised definition along the lines of the one shown
in 11(t) is suggested.

(v) The SYNTAX value for IkeAuthMethod should be changed to
Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the REFERENCE clause should point to
RFC 2409 Appendix A only, as this is the reference that defines the
parameter.  A revised definition along the lines of the one shown
in 11(t) is suggested.

(w) The SYNTAX value for IkeGroupDescription should be changed to
Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  Also, the REFERENCE clause should point to
RFC 2409 Appendix A only, as this is the reference that defines the
parameter.  A revised definition along the lines of the one shown
in 11(t) is suggested.

(x) The SYNTAX value for IkeGroupType should be changed to
Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entry for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  A revised definition along the lines of the
one shown in 11(t) is suggested.

NOTE:  the IkeGroupType TC is not used in any of the four MIB
modules (IPSEC-SA-MON-MIB, ISAKMP-DOI-IND-MON-MIB, IKE-MON-MIB,
and IPSEC-POLICY-MIB) that currently import TCs from
IPSEC-ISAKMP-IKE-DOI-TC.  Be aware that TCs which are not used
to define MIB objects that are included in two independent
implementations must be deprecated or obsoleted before the spec
containing them can advance beyond Proposed Standard.

(y) The DESCRIPTION clause  for IkePrf should point to the
appropriate IANA registry entry for the assigned values and should
recommend that an agent-caps statement document use of the "private
use" values.  A revised definition along the lines of the one shown
in 11(t) is suggested.

(z) The SYNTAX value for IkeNotifyMessageType should be changed to
Unsigned32 (0..65535), and its DESCRIPTION clause should point to
the appropriate IANA registry entries for the assigned values and
should recommend that an agent-caps statement document use of the
"private use" values.  A revised definition along the following
lines is suggested:

IsakmpNotifyMessageType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "Managed objects of this type represent values
                of the Notify Message Type field in the ISAKMP
                Notification Payload.

                This textual convention merges the types
                for error types (in the range 1-16383) and for
                status types (in the range 16384-65535).

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

                Values between 1 and 8191, inclusive, represent
                DOI-independent error message types specified in
                RFC 2408 Section 3.14.1.   At the present time there
                is no assigned number registry for DOI-independent
                ISAKMP error message type values.  A registry may
                be established and additional DOI-independent values
                may be assigned by the IANA at some future date.

                Values between 8192 and 16383, inclusive, represent
                DOI-specific error message types.  Assignments are
                recorded in the Notify Messages - Error Types
                subsection of the IPSEC Notify Message Types section
                of the IANA Internet Security Association and Key
                Management Protocol (ISAKMP) Identifiers registry
                (http://www.iana.org/assignments/isakmp-registry).

                Values between 16384 and 24575, inclusive, represent
                DOI-independent status message types specified in
                RFC 2408 Section 3.14.1.   At the present time there
                is no assigned number registry for DOI-independent
                ISAKMP status message type values.  A registry may
                be established and additional DOI-independent values
                may be assigned by the IANA at some future date.

                Values between 24576 and 32767, inclusive, represent
                DOI-specific status message types.  Assignments are
                recorded in the Notify Messages - Status Types
                subsection of the IPSEC Notify Message Types section
                of the IANA Internet Security Association and Key
                Management Protocol (ISAKMP) Identifiers registry
                (http://www.iana.org/assignments/isakmp-registry).

                Values in the range 32768-40959 are reserved for
                private use as status message types amongst
                cooperating systems.  It is RECOMMENDED that
                implementations document the usage of such
                values in an AGENT-CAPABILITIES statement.

                Values in the range 40960-65535 are reserved for
                future use."
    REFERENCE   "RFC 2408 section 3.14.1 and RFC 2407 sections 4.6.3
                and 6.10"
    SYNTAX      Unsigned32 (0..65535)

12.) The following minor editorial changes are requested:

(a) s/Attrbute/Attribute/ in all the IkeXyz TC DESCRIPTION clauses
where it appears.

(b) Please change phrases such as "when used in a MIB" to "when used
in a MIB module" throughout the document.

Note that if the change recommendations above are accepted, then
some minor changes will also have to be made to some of the modules
that import TCs from IPSEC-ISAKMP-IKE-DOI-TC.  Here are the modules
that are known to import from IPSEC-ISAKMP-IKE-DOI-TC:

Client Module           Internet Draft

IPSEC-SA-MON-MIB        <draft-ietf-ipsec-monitor-mib-06.txt>
ISAKMP-DOI-IND-MON-MIB  <draft-ietf-ipsec-isakmp-di-mon-mib-05.txt>
IKE-MON-MIB             <draft-ietf-ipsec-ike-monitor-mib-04.txt>
IPSEC-POLICY-MIB        <draft-ietf-ipsp-ipsec-conf-mib-06.txt>

The (minimum) required changes would be as follows:

IPSEC-SA-MON-MIB        none known

ISAKMP-DOI-IND-MON-MIB  none known

IKE-MON-MIB             The DESCRIPTION clauses of ikeSaTable
                        and ikeSaEntry refer to 'ipsecDOI(1)'.
                        The DESCRIPTION clause of ipsecSaInSuiteSpi
                        refers to 'protoIpcomp(4)'.  These clauses
                        should be edited to reflect the fact that
                        these enums will no longer exist.

IPSEC-POLICY-MIB        The DEFVAL clause of ipspSaPreActActionType
                        will need to be changed from '{ tunnel }'
                        to '{ 1 } -- tunnel', or else the object
                        needs to get a stand-alone definition
                        independent of a TC, as was done for
                        ipspIpsecActMode.  Also, the DESCRIPTION
                        clauses for ipspIpsecPropProtocolId and
                        ipspIpsecTranType refer to protoIsakmp(1).
                        These clauses should be edited to reflect
                        the fact that this enum will not exist.

Other changes might also be required (e.g., to comply with the
proposed requirement to document how the special value 0 is used).
The authors/editors of these MIB modules have been bcc:'d.

One last point:  it is acknowledged that the main recommendations in
this review are controversial.  Understand that all recommendations
are presented as advice to the OPS AD responsible for Network
Management (see http://www.ops.ietf.org/mib-doctors.html), and any
recommendation with which folks do not agree may be challenged.

Regards,

Mike Heard