RE: MIB doctor review of draft-ietf-ipsec-doi-tc-mib-07.txt
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Tue, 29 April 2003 15:24 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27585 for <ipsec-archive@lists.ietf.org>; Tue, 29 Apr 2003 11:24:38 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04371 Tue, 29 Apr 2003 08:21:20 -0400 (EDT)
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C0D20@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "C. M. Heard" <heard@pobox.com>, IPsec WG <ipsec@lists.tislabs.com>
Cc: John Shriver <jshriver+ietf@sockeye.com>, Barbara Fraser <byfraser@cisco.com>, Theodore Ts'o <tytso@mit.edu>, Steven Bellovin <smb@research.att.com>, Russ Housley <housley@vigilsec.com>, Bert Wijnen <bwijnen@lucent.com>
Subject: RE: MIB doctor review of draft-ietf-ipsec-doi-tc-mib-07.txt
Date: Tue, 29 Apr 2003 05:54:38 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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 >
- RE: MIB doctor review of draft-ietf-ipsec-doi-tc-… Wijnen, Bert (Bert)