Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt
"C. M. Heard" <heard@pobox.com> Wed, 16 April 2003 22:06 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 SAA18784 for <ipsec-archive@lists.ietf.org>; Wed, 16 Apr 2003 18:06:02 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02339 Wed, 16 Apr 2003 15:57:39 -0400 (EDT)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Wed, 16 Apr 2003 13:01:35 -0700
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: IPsec WG <ipsec@lists.tislabs.com>
cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt
In-Reply-To: <Pine.LNX.4.10.10304081520310.22509-100000@shell4.bayarea.net>
Message-ID: <Pine.LNX.4.10.10304161156420.28021-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
[ authors of draft-ietf-ipsp-ipsec-conf-mib-06.txt bcc'd; ] [ please direct all discussion to ipsec@lists.tislabs.com ] Summary of the discussion so far: I have pointed out to the WG that all of the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC MIB module in <draft-ietf-ipsec-doi-tc-mib-07.txt> (except for IsakmpCertificateEncoding) are intended to represent data items that have a certain range of values reserved for "private use amongst cooperating systems." Since values in these ranges are not subject to standardization, there will be no enumerations for them. However, SMIv2 rules require (and MIB users/authors expect) that objects defined with an enumerated INTEGER syntax will assume only those values that are named in the enumeration list. I have therefore advised the WG (in my role as MIB reviewer) that the SYNTAX value of all of the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC MIB module be changed to the appropriate Unsigned32 subrange with the usages of the various ranges spelled out in the DESCRIPTION clause (as is done now) and a pointer to the IANA registry included. This approach, which is the also used in the SnmpSecurityModel TC from the SNMP-FRAMEWORK-MIB in RFC 3411, has the added advantage of not imposing any extra workload on the IANA to supplement or reorganize the existing IPsec and ISAKMP registries. The disadvantage of this approach is that applications such as MIB browsers that don't have any built-in knowledge of the underlying MIB objects can only display the integer value and not the enumeration label, which makes the MIB modules harder to use. This discussion has been dormant for about a week, and I do need to proceed with finalization of my MIB review comments for the ADs. So unless I hear some very convincing arguments to the contrary before Tuesday, 22 April 2003, my review comments will advise that all the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC have the SYNTAX value changed to the appropriate Unsigned32 subrange, and that the MIB module be maintained by the WG, not by IANA. I am aware of the following Internet Drafts that contain MIB modules which use one or more of the TCs defined in IPSEC-ISAKMP-IKE-DOI-TC: draft-ietf-ipsec-ike-monitor-mib-04.txt draft-ietf-ipsec-isakmp-di-mon-mib-05.txt draft-ietf-ipsec-monitor-mib-06.txt draft-ietf-ipsp-ipsec-conf-mib-06.txt Of these, it appears that only the last one would be affected by the changes I intend to recommend. It would be necessary to change the object definition ipspSaPreActActionType OBJECT-TYPE SYNTAX IpsecDoiEncapsulationMode MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the encapsulation mode to use for the preconfigured SA: tunnel or transport mode." DEFVAL { tunnel } ::= { ipspSaPreconfiguredActionEntry 9 } to ipspSaPreActActionType OBJECT-TYPE SYNTAX IpsecDoiEncapsulationMode MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the encapsulation mode to use for the preconfigured SA: tunnel or transport mode." DEFVAL { 1 } -- tunnel ::= { ipspSaPreconfiguredActionEntry 9 } Regards, Mike Heard
- Important question about draft-ietf-ipsec-doi-tc-… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- RE: Important question about draft-ietf-ipsec-doi… Wijnen, Bert (Bert)
- Re: Important question about draft-ietf-ipsec-doi… John Shriver
- Re: Important question about draft-ietf-ipsec-doi… John Shriver
- Re: Important question about draft-ietf-ipsec-doi… John Shriver
- RE: Important question about draft-ietf-ipsec-doi… Wijnen, Bert (Bert)
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… Wes Hardaker
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… Wes Hardaker
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… Wes Hardaker
- IANA administrative issues with draft-ietf-ipsec-… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: Important question about draft-ietf-ipsec-doi… Wes Hardaker
- Re: Important question about draft-ietf-ipsec-doi… C. M. Heard
- Re: IANA administrative issues with draft-ietf-ip… John Shriver
- Re: IANA administrative issues with draft-ietf-ip… C. M. Heard