From owner-ipsec-policy@mail.vpnc.org Wed Apr 2 09:54:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11191 for ; Wed, 2 Apr 2003 09:54:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EMUJM005501 for ; Wed, 2 Apr 2003 06:22:30 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32EMUvk005500 for ipsec-policy-bks; Wed, 2 Apr 2003 06:22:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EMTJM005489 for ; Wed, 2 Apr 2003 06:22:29 -0800 (PST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32EMNi03617 for ; Wed, 2 Apr 2003 09:22:24 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <1HXAVA1X>; Wed, 2 Apr 2003 09:07:46 -0500 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3702578055@nj7460exch010u.ho.lucent.com> From: "Choudhary, Abdur R (Rahim)" To: "'ipsec-policy@vpnc.org'" Subject: 56th minutes Date: Wed, 2 Apr 2003 09:07:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do we have the meeting minutes for the 56th SF meeting, even if in a non-finalized form? From owner-ipsec-policy@mail.vpnc.org Wed Apr 2 19:39:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19041 for ; Wed, 2 Apr 2003 19:39:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h330I8JM012199 for ; Wed, 2 Apr 2003 16:18:08 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h330I7CO012198 for ipsec-policy-bks; Wed, 2 Apr 2003 16:18:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h330I6JM012193 for ; Wed, 2 Apr 2003 16:18:06 -0800 (PST) Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged)) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h330I3Kq025838; Wed, 2 Apr 2003 17:18:03 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h330Hw327750; Wed, 2 Apr 2003 17:17:58 -0700 Date: Wed, 2 Apr 2003 17:17:58 -0700 Message-Id: <200304030017.h330Hw327750@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: arc@lucent.com Cc: ipsec-policy@vpnc.org In-reply-to: Yourmessage <61B49BC6DA0DDE40957FB499E1835E3702578055@nj7460exch010u.ho.lucent.com> Subject: Re: 56th minutes Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The minutes exist, but I don't have them at hand. We will get them posted soon, but will also accept comments in advance of the minutes draft. I.e., if you were there and want to contribute partial notes, it would be helpful. Hilarie From owner-ipsec-policy@mail.vpnc.org Sat Apr 5 17:01:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15679 for ; Sat, 5 Apr 2003 17:01:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35LNZJM003825 for ; Sat, 5 Apr 2003 13:23:35 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35LNZqP003824 for ipsec-policy-bks; Sat, 5 Apr 2003 13:23:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35LNYJM003818 for ; Sat, 5 Apr 2003 13:23:34 -0800 (PST) Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged)) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h35LOOKq012842 for ; Sat, 5 Apr 2003 14:24:24 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h35LN4d09608; Sat, 5 Apr 2003 14:23:04 -0700 Date: Sat, 5 Apr 2003 14:23:04 -0700 Message-Id: <200304052123.h35LN4d09608@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec-policy@vpnc.org Subject: FW: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is relevant to both IPSP and IPSec. Hilarie ---Forwarded Message Follows--- To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt IPsec folks, I've been commissioned to do the MIB doctor review for but before I spend a lot of time discussing the details I'd like to ask a very basic (and I think very important) question. If I correctly understand what I have read, the main content of this draft is a set of enumerated INTEGER TCs that represent the values of fields in IPsec-related protocol messages. However, in many of these TCs (all, in fact, except for IsakmpCertificateEncoding) the DESCRIPTION clause (or the underlying reference document) has a statement to the effect that certain ranges of values are "reserved for private use amongst cooperating systems." Such values do not presently appear as named numbers in the enumeration list, and my understanding is that they will never appear in the enumeration list since they are not subject to assignment by the IANA. The WG needs to be aware that (according to RFC 2578 Section 7.1.1) the only values allowed for objects defined with these enumerated INTEGER TCs are the named numbers that are actually present in the enumeration list. Thus, managed objects defined with these TCs cannot represent values in the ranges that are reserved for private use amongst cooperating systems. If it is intended that objects defined using these TCs be able to represent arbitrary values of the corresponding parameters, including the "private use" values, then a SYNTAX value other than enumerated INTEGER will be required -- for instance, Unsigned32 with a subrange, as is used in the definition of IkePrf. Of course, in that case there would be no need to have the IANA maintain these TCs: they could be defined once, in a WG-maintained document, with the value list in a conventional assigned number registry. I ask the WG to carefully consider whether an IANA-maintained MIB module is really desirable in view of the above-described limitation of enumerated INTEGER TCs. It would be good to get an answer before we spend a lot of time discussing detailed review comments. Regards, Mike Heard From subs-reminder@vpnc.org Mon Apr 7 17:54:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07019 for ; Mon, 7 Apr 2003 17:54:05 -0400 (EDT) From: subs-reminder@vpnc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37LuZJM019793 for ; Mon, 7 Apr 2003 14:56:35 -0700 (PDT) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37LuYln019792; Mon, 7 Apr 2003 14:56:34 -0700 (PDT) Date: Mon, 7 Apr 2003 14:56:34 -0700 (PDT) Message-Id: <200304072156.h37LuYln019792@above.proper.com> To: ipsp-archive@ietf.org Subject: [[166156036]] Subscription to ipsec-policy for ipsp-archive@lists.ietf.org Greetings. This message is a periodic reminder that ipsp-archive@lists.ietf.org is subscribed to the ipsec-policy mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ipsec-policy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ipsec-policy-request@vpnc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ipsp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ipsec-policy@mail.vpnc.org Tue Apr 8 18:39:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06865 for ; Tue, 8 Apr 2003 18:39:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38MEnJM020693 for ; Tue, 8 Apr 2003 15:14:49 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38MEnhq020692 for ipsec-policy-bks; Tue, 8 Apr 2003 15:14:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38MEmJM020685 for ; Tue, 8 Apr 2003 15:14:48 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h38MGXKq024419 for ; Tue, 8 Apr 2003 16:16:34 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h38MEKZ30735; Tue, 8 Apr 2003 16:14:20 -0600 Date: Tue, 8 Apr 2003 16:14:20 -0600 Message-Id: <200304082214.h38MEKZ30735@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec-policy@vpnc.org Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ---Forwarded Message Follows--- Date: Tue, 8 Apr 2003 13:07:18 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt In-Reply-To: <3E91CB29.4030706@sockeye.com> Message-ID: John Shriver wrote: > C. M. Heard wrote: > John Shriver wrote: > > > Let me be sure that I understand your intent. Because RFC 2578 > > > Section 7.1.1 says that the only legal values of an enumeration > > > are those in a list, and there may be numbers in the list from > > > the user-reserved space that may not be in the list, we should > > > abandon any effort to provide an enumeration for any of these > > > number spaces in any MIB for IPsec? > > > > > > Instead, they should all be range-limited INTEGERS[?] [ ... ] > > > This strikes me as a disservice to the real customers, which are > > > the users of any IPsec MIBs. (RFC 2578 is not a customer.) The > > > entire purpose of this MIB was to eliminate those manual lookups. > > > > In retrospect, it might have been better if the SMI had adopted the > > ASN.1 rule that enumerations only specified distinguished values, > > and that the underlying type was allowed to have all INTEGER values > > (well, all in the range -2147483648..2147483647, since the SMI > > restricts INTEGER to that range). But that wasn't what was decided, > > and the current rule is the one we have to live with. [ ... ] > We discussed the "standards fudge" issue of the non-enumerated values > back [when this project was started], and people on the IPsec list > weren't offended by the problem. A common-sense standards bending > didn't bother them. The problem with bending the rules in this way is that it is confounds expectations that people have (based on what is in the standard) regarding what enumerated INTEGERs mean. I put this question to the other MIB Doctors and got these answers: On Mon, 7 Apr 2003, Randy Presuhn wrote: % What bothers me about this proposal is not so much the notion of % extending enumerations without adjusting the documentation, but % rather the semantic ambigiuities that will result due to the lack % of coordination of the enumeration assignments. For this kind of % un-coordinated private use, OBJECT IDENTIFIERs are really the way % to go. Otherwise, one has no way of knowing whether agent A's 42 % means the same thing as agent (or manager) B's. On Mon, 7 Apr 2003, Andy Bierman wrote: % I agree with Randy. If they are leaving enum values unspecified % so vendors can assign their own value, then this is a misuse of % enumerated INTEGER. If enums are really the appropriate data type, % and they know now that they want specific values defined, then % all enum values should be listed and documented. What the Randy's and Andy's comments are saying is that enumerated INTEGERs are the wrong data type for this application not because of an obscure technical violation of RFC 2578 but because this usage violates the semantics that are expected of enumerated INTEGERs. I tend to agree with that, and that's why I have suggested subranged Unsigned32 would be a more appropriate choice. > I don't have time to dig the archives... I looked in the ipsec archives back to 1998 and was not able to find any discussion of this specific issue (it is entirely possible that I missed something, in which case a pointer would be helpful). Thanks, Mike Heard From owner-ipsec-policy@mail.vpnc.org Thu Apr 10 02:46:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09599 for ; Thu, 10 Apr 2003 02:46:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A6E1JM021868 for ; Wed, 9 Apr 2003 23:14:01 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A6E1Q4021867 for ipsec-policy-bks; Wed, 9 Apr 2003 23:14:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A6DxJM021856 for ; Wed, 9 Apr 2003 23:14:00 -0700 (PDT) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3A6GBKq019322 for ; Thu, 10 Apr 2003 00:16:11 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3A6DPN21609; Thu, 10 Apr 2003 00:13:25 -0600 Date: Thu, 10 Apr 2003 00:13:25 -0600 Message-Id: <200304100613.h3A6DPN21609@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec-policy@vpnc.org Subject: Draft minutes, IPSP at 56th IETF Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [sorry these have been so late; augmentation and corrections are urged, as are copies of presentations; send them to me and lsanchez@xapiens.com. Hilarie] Working group: IPSP There were no comments during the traditional minute reserved for agenda bashing. WG Status. - Hilarie Orman summarized the document status: Sent to Security ADs on 2002/8/27. - IPsec Policy Requirements (informational) - IPsec Configuration Policy Model - IPsec Policy Information Base (informational) The IESG reviewed documents and provided feedback on the first two. The authors discussed the commetns with the AD's, made changes, and resubmitted the drafts. The drafts are marked in the ID tracker with dependencies, and thus, the PIB will not be reviewed until the Configuration Policy Model has been resubmitted. The chairs believe that this has been done and that the AD should take action. The MIB draft received extensive discussion and is dependent on the IPSec DOI MIB which only recently was submitted to the IESG; discussion with the IPSec chairs revealed that IPSec intends to advance all of its MIB documents simultaneously and expects quick approval. We will proceed with the IPSP MIB document on that assumption. Other charter items for the WG has received some interest, but there has not been enough momentum to produce results. These items are the protocol for discovering security pathways (gateway sequences with compatible policies) and the API for reading/writing IPSec policy in an running system, much like PF_KEY. We need volunteers to work on these items. 2) Eric Vyncke, IPsec Policy Configuration Model. The name of this document has changed to: IPsec Policy Configuration Information Model. Some changes in latest draft were due to new features in DMTF specification. There are some conflicts with newer DMTF direction vs IPsec direction. There have been problems keeping in contact with the DMTF work; our liason to the DMTF has abandoned his role. 3) Man Li, PIB document Has been sent to IESG and review is pending (see above). 4) Wes Hardarker, IPSP - IPsec Policy MIB. This has received feedback from ADs, but isn't in IESG last-call. - multiple vendors planning implementations - switch to SNMP model of encoding some integer types, and various rules. 5) Bill Sommerfield reports no progress on PF_POLICY. Seeking volunteers. 6) Luis Sanchez, SPP presentation (same as 1998); seeking volunteers. 7) Working group charter discussion. From owner-ipsec-policy@mail.vpnc.org Wed Apr 16 18:13:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19543 for ; Wed, 16 Apr 2003 18:13:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLmxt2077908 for ; Wed, 16 Apr 2003 14:48:59 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLmxkB077907 for ipsec-policy-bks; Wed, 16 Apr 2003 14:48:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLmut2077899 for ; Wed, 16 Apr 2003 14:48:58 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.5/8.12.5) with ESMTP id h3GLr1Kq024786; Wed, 16 Apr 2003 15:53:02 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3GLoM729328; Wed, 16 Apr 2003 15:50:22 -0600 Date: Wed, 16 Apr 2003 15:50:22 -0600 Message-Id: <200304162150.h3GLoM729328@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec-policy@vpnc.org Cc: andreaw@cisco.com Subject: FW: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Has this got any impact on the policy config doc? We need a response on this issue. Hilarie ---Forwarded Message Follows--- From: "C. M. Heard" To: IPsec WG cc: "Wijnen, Bert (Bert)" Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt [ 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 (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 From owner-ipsec-policy@mail.vpnc.org Wed Apr 16 21:57:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23877 for ; Wed, 16 Apr 2003 21:57:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1BYt2083352 for ; Wed, 16 Apr 2003 18:11:34 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H1BYpB083351 for ipsec-policy-bks; Wed, 16 Apr 2003 18:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1BXt2083345 for ; Wed, 16 Apr 2003 18:11:33 -0700 (PDT) (envelope-from jamie.jason@intel.com) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3H17jw11508 for ; Thu, 17 Apr 2003 01:07:45 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3GNNY520231 for ; Wed, 16 Apr 2003 23:23:34 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003041616270528384 ; Wed, 16 Apr 2003 16:27:05 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Apr 2003 16:29:36 -0700 Message-ID: From: "Jason, Jamie" To: "The Purple Streak, Hilarie Orman" , ipsec-policy@vpnc.org Cc: andreaw@cisco.com Subject: RE: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.t xt Date: Wed, 16 Apr 2003 16:29:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There should be no impact on the configuration policy model document. Jamie > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Wednesday, April 16, 2003 2:50 PM > To: ipsec-policy@vpnc.org > Cc: andreaw@cisco.com > Subject: FW: Re: Important question about > draft-ietf-ipsec-doi-tc-mib-07.txt > > > > Has this got any impact on the policy config doc? We need a > response on this issue. > > Hilarie > > ---Forwarded Message Follows--- > From: "C. M. Heard" > To: IPsec WG > cc: "Wijnen, Bert (Bert)" > Subject: Re: Important question about > draft-ietf-ipsec-doi-tc-mib-07.txt > > [ 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 > (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 >