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

RE: MIB doctor review of draft-ietf-ipsec-doi-tc-mib-07.txt



Thanks Mike for your review.

People who answer and want me to see the response, pls copy
me personally, cause I am not on your IPsec mailing list.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@xxxxxxxxx]
> Sent: maandag 28 april 2003 22:13
> To: IPsec WG
> Cc: John Shriver; Barbara Fraser; Theodore Ts'o; Steven Bellovin; Russ
> Housley; Bert Wijnen
> Subject: MIB doctor review of draft-ietf-ipsec-doi-tc-mib-07.txt
> 
> 
> 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
>  <smilint@xxxxxxxxxxxxxxx>. If you want to learn more about this
>  mail service, send a mail message with the "Subject: help" to
>  <smilint@xxxxxxxxxxxxxxx>.
> 
>  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
>