[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@pobox.com]
> 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@ibr.cs.tu-bs.de>. If you want to learn more about this
> mail service, send a mail message with the "Subject: help" to
> <smilint@ibr.cs.tu-bs.de>.
>
> 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
>