From owner-ipsec-policy@mail.vpnc.org Fri Mar 1 07:45:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18445 for ; Fri, 1 Mar 2002 07:45:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g21C3DM13501 for ipsec-policy-bks; Fri, 1 Mar 2002 04:03:13 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21C3Ci13497 for ; Fri, 1 Mar 2002 04:03:12 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13079; Fri, 1 Mar 2002 07:03:09 -0500 (EST) Message-Id: <200203011203.HAA13079@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-ipsecpib-04.txt Date: Fri, 01 Mar 2002 07:03:09 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Policy Working Group of the IETF. Title : IPSec Policy Information Base Author(s) : M. Li, D. Arneson, A. Doria, J. Jason, C. Wang, M. Stenberg Filename : draft-ietf-ipsp-ipsecpib-04.txt Pages : 92 Date : 28-Feb-02 This document specifies a set of policy rule classes (PRC) for configuring IPsec policy at IPsec-enabled devices (e.g., security gateways). Instances of these classes reside in a virtual information store called the IPsec Policy Information Base (PIB). The COPS protocol [5] with extensions for provisioning [6] is used to transmit this IPsec policy information to IPsec-enabled devices. The PRCs defined in this IPsec PIB are intended for use by the COPS-PR IPsec client type. These PRCs are in addition to any other PIBs that may be defined for the IPsec client type, as well as the PRCs defined in the Framework PIB [9]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsp-ipsecpib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsp-ipsecpib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-ipsecpib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-ipsecpib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Fri Mar 1 07:50:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18973 for ; Fri, 1 Mar 2002 07:50:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g21C3If13508 for ipsec-policy-bks; Fri, 1 Mar 2002 04:03:18 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21C3Ii13504 for ; Fri, 1 Mar 2002 04:03:18 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13103; Fri, 1 Mar 2002 07:03:14 -0500 (EST) Message-Id: <200203011203.HAA13103@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-config-policy-model-05.txt Date: Fri, 01 Mar 2002 07:03:14 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Policy Working Group of the IETF. Title : IPsec Configuration Policy Model Author(s) : J. Jason, L. Rafalow, E. Vyncke Filename : draft-ietf-ipsp-config-policy-model-05.txt Pages : 72 Date : 28-Feb-02 This document presents an object-oriented model of IPsec policy designed to: o facilitate agreement about the content and semantics of IPsec policy o enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec- enabled endpoints The schema described in this document models the IKE phase one parameters as described in [IKE] and the IKE phase two parameters for the IPsec Domain of Interpretation as described in [COMP, ESP, AH, DOI]. It is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) [PCIM]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsp-config-policy-model-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-config-policy-model-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134510.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Mon Mar 4 11:47:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01916 for ; Mon, 4 Mar 2002 11:47:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g24FtF126134 for ipsec-policy-bks; Mon, 4 Mar 2002 07:55:15 -0800 (PST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24FtC826119 for ; Mon, 4 Mar 2002 07:55:13 -0800 (PST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g24Fsu413184 for ; Mon, 4 Mar 2002 10:54:56 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g24FsrY15836 for ; Mon, 4 Mar 2002 10:54:54 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FYC2BC62; Mon, 4 Mar 2002 10:54:51 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDK89MRW; Mon, 4 Mar 2002 10:54:53 -0500 Message-ID: <3C83998A.6A9AB666@metasolv.com> Date: Mon, 04 Mar 2002 10:58:02 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: FilterList in IPSP context Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The IPSec Policy model uses "FilterList" and indicates that it is defined in "[CIMNETWORK]". On the other hand, the IPSec Policy model is based upon the core policy classes defined in PCIM and PCIMe. The later redefines the "FilterList" class with an additional restriction relative to the redefined "EntriesInFilterList" aggregation. See PCIMe Section 4.9.2 second paragraph and Section 5.21 second paragraph. Does the restriction defined by PCIMe apply in the context of IPSP submodel? Or does IPSP override the PCIMe "FilterList" semantics with the original CIMNETWORK ones? Regards, Mircea. From owner-ipsec-policy@mail.vpnc.org Mon Mar 4 12:49:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05721 for ; Mon, 4 Mar 2002 12:49:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g24H98l03690 for ipsec-policy-bks; Mon, 4 Mar 2002 09:09:08 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24H92803679 for ; Mon, 4 Mar 2002 09:09:02 -0800 (PST) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.us.ibm.com [9.37.3.208]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA11324; Mon, 4 Mar 2002 11:03:46 -0600 Received: from lrafalow (dyn9-27-16-214.raleigh.ibm.com [9.27.16.214]) by southrelay01.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g24H92m55974; Mon, 4 Mar 2002 12:09:02 -0500 Message-ID: <003b01c1c39f$42203d30$d6101b09@lrafalow> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: , Cc: References: <3C83998A.6A9AB666@metasolv.com> Subject: Re: FilterList in IPSP context Date: Mon, 4 Mar 2002 12:08:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Another good catch Mircea. If I remember correctly, our intent was to change CIM as well but I don't see a Change Request anywhere. For simplicity for now, we should make another edit to the IPsec Configuration Policy Model so that it points to PCIMe rather than CIM. Thanks, Lee ----- Original Message ----- From: "Mircea Pana" To: Sent: Monday, March 04, 2002 10:58 AM Subject: FilterList in IPSP context > > The IPSec Policy model uses "FilterList" and indicates that it is > defined in "[CIMNETWORK]". > On the other hand, the IPSec Policy model is based upon the core policy > classes defined in PCIM and PCIMe. The later redefines the "FilterList" > class with an additional restriction relative to the redefined > "EntriesInFilterList" aggregation. See PCIMe Section 4.9.2 second > paragraph and Section 5.21 second paragraph. > > Does the restriction defined by PCIMe apply in the context of IPSP > submodel? Or does IPSP override the PCIMe "FilterList" semantics with > the original CIMNETWORK ones? > > Regards, > Mircea. > From owner-ipsec-policy@mail.vpnc.org Tue Mar 5 03:46:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21150 for ; Tue, 5 Mar 2002 03:46:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g257ssP06967 for ipsec-policy-bks; Mon, 4 Mar 2002 23:54:54 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g257sr806960 for ; Mon, 4 Mar 2002 23:54:54 -0800 (PST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g257sj323429; Mon, 4 Mar 2002 23:54:45 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABY49333; Mon, 4 Mar 2002 23:54:22 -0800 (PST) From: "Andrea Westerinen" To: "Lee Rafalow" , , Cc: Subject: RE: FilterList in IPSP context Date: Mon, 4 Mar 2002 23:57:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <003b01c1c39f$42203d30$d6101b09@lrafalow> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Actually, the CR is on the docket for discussion on next week's Network call. It just adds a default value of 0 to the property in the aggregation. This CR is part of the realignment of the QoS work between DMTF and IETF. It will be released as part of CIM V2.7 Networks. In the end, documenting either PCIMe or CIM Networks will be the same :-). However, it will not be a mandatory value in CIM Networks - since it has no reason to exist if all that we do is AND together FilterEntryBases. Andrea -----Original Message----- From: Lee Rafalow [mailto:rafalow@watson.ibm.com] Sent: Monday, March 04, 2002 9:09 AM To: mpana@metasolv.com; ipsec-policy@vpnc.org Cc: wg-network@dmtf.org Subject: Re: FilterList in IPSP context Another good catch Mircea. If I remember correctly, our intent was to change CIM as well but I don't see a Change Request anywhere. For simplicity for now, we should make another edit to the IPsec Configuration Policy Model so that it points to PCIMe rather than CIM. Thanks, Lee ----- Original Message ----- From: "Mircea Pana" To: Sent: Monday, March 04, 2002 10:58 AM Subject: FilterList in IPSP context > > The IPSec Policy model uses "FilterList" and indicates that it is > defined in "[CIMNETWORK]". > On the other hand, the IPSec Policy model is based upon the core policy > classes defined in PCIM and PCIMe. The later redefines the "FilterList" > class with an additional restriction relative to the redefined > "EntriesInFilterList" aggregation. See PCIMe Section 4.9.2 second > paragraph and Section 5.21 second paragraph. > > Does the restriction defined by PCIMe apply in the context of IPSP > submodel? Or does IPSP override the PCIMe "FilterList" semantics with > the original CIMNETWORK ones? > > Regards, > Mircea. > From owner-ipsec-policy@mail.vpnc.org Tue Mar 12 17:14:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10114 for ; Tue, 12 Mar 2002 17:14:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2CLXu027089 for ipsec-policy-bks; Tue, 12 Mar 2002 13:33:56 -0800 (PST) Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CLXt427085 for ; Tue, 12 Mar 2002 13:33:55 -0800 (PST) Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16ktu6-0007MV-00 for ipsec-policy@vpnc.org; Tue, 12 Mar 2002 14:33:54 -0700 Received: from shell.xmission.com ([198.60.22.20] helo=xmission.xmission.com) by mail.xmission.com with esmtp (Exim 3.22 #1) id 16ktu5-0002Su-00 for ipsec-policy@vpnc.org; Tue, 12 Mar 2002 14:33:53 -0700 Received: from hilarie by xmission.xmission.com with local (Exim 3.16 #3) id 16ktu5-0001kj-00 for ipsec-policy@vpnc.org; Tue, 12 Mar 2002 14:33:53 -0700 From: "Hilarie Orman, Purple Streak Development" To: ipsec-policy@vpnc.org Subject: IPsec Policy Agenda items - send requests Message-Id: Date: Tue, 12 Mar 2002 14:33:53 -0700 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send requests for IPsec Policy agenda slots for Minneapolis to the chairs: Luis Sanchez, lsanchez@megisto.com, and Hilarie Orman, hilarie@xmission.com Hilarie From owner-ipsec-policy@mail.vpnc.org Fri Mar 15 04:29:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24366 for ; Fri, 15 Mar 2002 04:29:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2F8pOo28719 for ipsec-policy-bks; Fri, 15 Mar 2002 00:51:24 -0800 (PST) Received: from wanderer.hardakers.net (IDENT:lh63ccjAk2osFgxgWLJgAQxrgRCybCCb@adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2F8pC428692 for ; Fri, 15 Mar 2002 00:51:22 -0800 (PST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.6/8.11.6) id g2F2JHR23616; Thu, 14 Mar 2002 18:19:17 -0800 To: "Hilarie Orman, Purple Streak Development" Cc: ipsec-policy@vpnc.org, lsanchez@megisto.com Subject: Re: IPsec Policy Agenda items - send requests References: From: Wes Hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: Thu, 14 Mar 2002 18:19:15 -0800 In-Reply-To: ("Hilarie Orman, Purple Streak Development"'s message of "Tue, 12 Mar 2002 14:33:53 -0700") Message-ID: Lines: 16 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.5 (bamboo, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> On Tue, 12 Mar 2002 14:33:53 -0700, "Hilarie Orman, Purple Streak Development" said: Hilarie> Please send requests for IPsec Policy agenda slots for Hilarie> Minneapolis to the chairs: Luis Sanchez, Hilarie> lsanchez@megisto.com, and Hilarie Orman, hilarie@xmission.com I can give a 5 minute/no-slides (at most unless someone has questions) status update about the MIB. There isn't much to discuss so more time is not needed. However, I won't be arriving until possibly after the start of the meeting (my plane lands at 2:30) so you should probably schedule me late into the meeting. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Sun Mar 17 21:37:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16144 for ; Sun, 17 Mar 2002 21:37:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2I1bsj20525 for ipsec-policy-bks; Sun, 17 Mar 2002 17:37:54 -0800 (PST) Received: from wanderer.hardakers.net (IDENT:JBJr++dAP7HioWsQMoeWeC2ZybqAciTj@adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2I1bT420511 for ; Sun, 17 Mar 2002 17:37:53 -0800 (PST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.6/8.11.6) id g2I1bPu16546; Sun, 17 Mar 2002 17:37:25 -0800 To: ipsec-policy@vpnc.org Subject: PolicyTimePeriodCondition from PCIM in the data model From: Wes Hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: Sun, 17 Mar 2002 17:37:24 -0800 Message-ID: Lines: 27 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.5 (bamboo, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: RFC3060 says this about the PolicyTimePeriodCondition: In some cases a PDP may need to perform certain setup / cleanup actions when a policy rule becomes active / inactive. For example, sessions that were established while a policy rule was active might need to be taken down when the rule becomes inactive. In other cases, however, such sessions might be left up: in this case, the effect of deactivating the policy rule would just be to prevent the establishment of new sessions. Setup / cleanup behaviors on validity period transitions are not currently addressed by the PCIM, and must be specified in 'guideline' documents, or via subclasses of PolicyRule, PolicyTimePeriodCondition or other concrete subclasses of Policy. If such behaviors need to be under the control of the policy administrator, then a mechanism to allow this control must also be specified in the subclass. Specifically, it might be a good thing to explicitly define in the data model what happens to IPsec SAs when a policy ends due to time constraints. Right now that behavior seems to be undefined, according to the above since the IPSP derived data model itself doesn't specify what to do? -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Mon Mar 18 09:46:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06247 for ; Mon, 18 Mar 2002 09:46:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2IEDdd16085 for ipsec-policy-bks; Mon, 18 Mar 2002 06:13:39 -0800 (PST) Received: from roam.psg.com (exim@roam.psg.com.ietf53.cw.net [166.63.185.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IEDc416081 for ; Mon, 18 Mar 2002 06:13:38 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 4.00) id 16mxt8-0002PM-00; Mon, 18 Mar 2002 08:13:26 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs Message-Id: Date: Mon, 18 Mar 2002 08:13:26 -0600 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy From owner-ipsec-policy@mail.vpnc.org Mon Mar 18 14:15:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16033 for ; Mon, 18 Mar 2002 14:15:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IIXvA04674 for ipsec-policy-bks; Mon, 18 Mar 2002 10:33:57 -0800 (PST) Received: from mx03.gis.net (mx03.gis.net [208.218.130.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IIXt404665 for ; Mon, 18 Mar 2002 10:33:56 -0800 (PST) Received: from callisto.jdscons.com ([216.243.57.15]) by mx03.gis.net; Mon, 18 Mar 2002 13:33:50 -0500 (EST) From: Jon Saperia Reply-To: saperia@jdscons.com To: Randy Bush , rap@ops.ietf.org, diffserv@ietf.org Subject: Re: why i should like pibs Date: Mon, 18 Mar 2002 13:16:22 -0500 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: ipsec-policy@vpnc.org, snmpconf@snmpconf.com References: In-Reply-To: MIME-Version: 1.0 Message-Id: <02031813325100.00987@callisto.jdscons.com> Content-Transfer-Encoding: 8bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Mon, 18 Mar 2002, Randy Bush wrote: > > why would cops/pibs be significantly better (remember it has to replace > my current investment, so it can not be 'just as good') than snmp/mibs? > > randy Randy you may recall discussions on this topic several years ago and the internet drafts published by various parties about the merits of a COPS versus SNMP approach. I co-authored one of those now expired drafts with Juergen. Time and events have overtaken some of the material in the draft but here is a URL to a site that has a post script version of the original ID that discusses your questions. http://www.ibr.cs.tu-bs.de/vs/papers/policy-tr-00-02.ps.gz Since publication of those early drafts, SNMPCONF has incorportated some of the changes suggested and the COPS folks have made improvements in that approach as well. I suspect part of what you have to figure out in the context of your question is: Is there an advantage that remains with a PIB approach, and if there is one does it ofset the balance of the cost you point to. The data in the document may be helpful. Further a read of the current SNMPCONF documents on the WG web site may be helpful. Even though there is probably duplication is the mail lists, I have copied the SNMPCONF WG on this since it is relevant to the work that is taking place there. /jon ---- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com From owner-ipsec-policy@mail.vpnc.org Mon Mar 18 18:46:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25915 for ; Mon, 18 Mar 2002 18:46:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IN1ZB13462 for ipsec-policy-bks; Mon, 18 Mar 2002 15:01:35 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IN1X413458 for ; Mon, 18 Mar 2002 15:01:33 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id AAA159332; Tue, 19 Mar 2002 00:00:42 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2IN0fI125616; Tue, 19 Mar 2002 00:00:41 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26082 from ; Tue, 19 Mar 2002 00:00:38 +0100 Message-Id: <3C967184.41C12D4C@hursley.ibm.com> Date: Tue, 19 Mar 2002 00:00:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Yavatkar, Raj" Cc: "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: Re: [Diffserv] RE: why i should like pibs References: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let's try to stick to technical issues please, at least if you want to keep the diffserv list on this thread. The technical issue is: does COPS-PR have *significant* technical advantages over the existing alternatives, that would justify the added mechanisms and complexity? Brian "Yavatkar, Raj" wrote: > > Hi Walter: > > Thanks for a really nice summary. I continue to be amazed at how Randy is > applying a set of inconsistent standards to this work vs other work being > done. Rob Coltun put the current state of IETF well in his departing message > -- I was hoping that would wake up IESG to move away from such political > shenanigans to getting work done especially when vendors with products or > implementations are working towards standardization. > > Raj > > -----Original Message----- > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > Sent: Monday, March 18, 2002 11:45 AM > To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: [Diffserv] RE: why i should like pibs > > Randy, > > I have two responses. > > 1. Political: > Why are you asking? Why do you keep asking? And more importantly why, based > on your criteria, haven't you asked for every non-monitoring MIB, or for > various other works such as Policy Framework. I don't mind if we want to > have a substantive discussion around the evolution of configuration > management if you applied your own metrics consistently. If you believe that > none of these technologies meet's your requirements, then freeze them all. > At least then there will be some pressure on all the parties to converge to > a common approach. Personally, I believe your question is a waste of time > since the existing IETF process addresses your question when there is > sufficient implementation to transition standards from proposed standards to > draft standards. Certainly there have been lot's of standards that have > never made it past proposed for the very reasons you describe. > > 2. Technical: > Given your role, I would not expect you to use this PIB. The very argument > justifying DiffServ is the same one that Operators use to manage their > networks. Both share the goal of making the core of the network static and > stupid (minimal configuration). By recognizing that the core should be kept > as simple as possible, we also all understand that removing complexity from > the core only moves the complexity to some other location: the edge. If the > edge must configure bindings of QoS, Security, Access Control, Tunneling, > Usage Accounting, etc, this drives specific requirements that COPS-PR comes > closest to meeting. I could go into all the details here, but given that > this thread inevitably de-evolves to the usual suspects and the usual > posturing, I have serious doubts about the value of going into any more > details. > > regards, > > -Walter > > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Monday, March 18, 2002 9:13 AM > > To: rap@ops.ietf.org; diffserv@ietf.org > > Cc: ipsec-policy@vpnc.org > > Subject: why i should like pibs > > > > > > wearing my iesg hat but being just a stupid operator, i am trying to > > understand the pib/mib controversy. fyi, i currently use snmp heavily > > for monitoring devices on my network. i configure using > > large db-driven > > code and spew text-based cli to the devices. > > > > let's assume i want to take the leap to a binary, as opposed > > to textual, > > configuration language. i.e. for some reason(s) [which we will PLEASE > > NOT discuss here] i decide to move from pushing text-based cli configs > > out to pushing a binary format. > > > > hence, i would have to push my vendors to implement snmp/cops > > writes for > > all configuration aspects of all devices. this would be big cost for > > both me and for my vendors. > > > > why would cops/pibs be significantly better (remember it has > > to replace > > my current investment, so it can not be 'just as good') than > > snmp/mibs? > > > > randy From owner-ipsec-policy@mail.vpnc.org Tue Mar 19 04:58:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18642 for ; Tue, 19 Mar 2002 04:58:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2J9CSm18609 for ipsec-policy-bks; Tue, 19 Mar 2002 01:12:28 -0800 (PST) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2J9CR418603 for ; Tue, 19 Mar 2002 01:12:27 -0800 (PST) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id JAA18339 for ; Tue, 19 Mar 2002 09:12:22 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031901182932665 ; Tue, 19 Mar 2002 01:18:29 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 01:12:22 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DEC2@FMSMSX34> From: "Durham, David" To: Randy Bush , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: RE: why i should like pibs Date: Tue, 19 Mar 2002 01:12:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Industry Realities COPS-PR & its PIBs Address: Dynamic Edge vs. Static Core - * COPS exists to address the Dynamic Provisioning needs of the Network's Edge. - Access Control Requests (from a variety of signaled protocols) - Controlled allocation of network resources - Micro-flow to aggregate traffic characterization - QoS - Security - Tunneling - Usage feedback * Meanwhile the Network Core tends to be static and deal with traffic aggregates being mainly concerned with routing & moving packets as fast as possible with minimal overhead. ... And ... It's a Multi-protocol World, COPS-PR is the Integrator. It closes the loop by tying together diverse signaling and provisioning mechanisms. Access control/session initiation/QoS requests come in and dynamically allocating/provisioning device resources based on policy goes out. Finally policy usage feedback closes the loop. Qualitative: * Enables entirely new classes of dynamic and integrated services that would not be possible without it. * It can integrate resource allocation and control for pretty much every in-band + out-of-band signaling protocol AND pretty much any form of resource Provisioning (eg. DiffServ). * BIG and RELIABLE TRANSACTIONS with rollback, failover and synchronization built-in. * It just works. It pulls outsourcing and provisioning together in one nice state-driven solution. Stateful means it maintains the state of all sessions on a device at all times as well as the resources they consume. * Completely event driven. * Device capabilities reporting is integral to the PIBs. Everything the device can syntactically parse and semantically do is precisely yet generically reported to the PDP. * Implementations are easy... COPS-PR sends you all your data in one complete reliable transaction. SNMP can throw all your attributes into a blender, so your implementation needs to be able to unscramble what comes out the other side, loss and all. * Three levels of easily understandable security. * New and improved data model and definition language with a consistent theme of a data-flow throughout. Enables better and improved tools over SNMP to make the job of implementers and users even easier! * Solves the multi-manager problem, data instances cannot overlap managers in COPS-PR and, thus, managers cannot step on one-another's toes. * NO row-status, owner description strings, storage-types, etc. to deal with AT ALL... And good riddance. Quantitative: * It can do one RTT provisioning based on outsourced events = well within call-setup time = as fast as is possible between two remote systems. * Intrinsically 10x more efficient on the wire than SNMP (1/10th the data to xfer) for e.g. the ever common DiffServ IP-filter tables. Efficiency multiplies with the more attributes you have in a row. * Faster, better & more. Change 10000 DiffServ Filter+meter+action entries through a T1 line with a 10msec RTT for 48byte packets: SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds. COPS=((10000*8*(498/10))/1540000)=2.59 Seconds. Is 100x improvement sufficiently better? And the multiple goes up with the more data you xfer. ... adding bandwidth doesn't help, it's that dang RTT. -Dave > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, March 18, 2002 6:13 AM > To: rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: why i should like pibs > > wearing my iesg hat but being just a stupid operator, i am trying to > understand the pib/mib controversy. fyi, i currently use snmp heavily > for monitoring devices on my network. i configure using large db-driven > code and spew text-based cli to the devices. > > let's assume i want to take the leap to a binary, as opposed to textual, > configuration language. i.e. for some reason(s) [which we will PLEASE > NOT discuss here] i decide to move from pushing text-based cli configs > out to pushing a binary format. > > hence, i would have to push my vendors to implement snmp/cops writes for > all configuration aspects of all devices. this would be big cost for > both me and for my vendors. > > why would cops/pibs be significantly better (remember it has to replace > my current investment, so it can not be 'just as good') than snmp/mibs? > > randy From owner-ipsec-policy@mail.vpnc.org Tue Mar 19 06:21:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19495 for ; Tue, 19 Mar 2002 06:21:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2JAeFW28450 for ipsec-policy-bks; Tue, 19 Mar 2002 02:40:15 -0800 (PST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JAeD428440 for ; Tue, 19 Mar 2002 02:40:13 -0800 (PST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g2JAe4Uu020053; Tue, 19 Mar 2002 11:40:04 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2JAe4n10879; Tue, 19 Mar 2002 11:40:04 +0100 Date: Tue, 19 Mar 2002 11:40:04 +0100 Message-Id: <200203191040.g2JAe4n10879@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: david.durham@intel.com CC: randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org In-reply-to: <10C8636AE359D4119118009027AE99870DA5DEC2@FMSMSX34> (david.durham@intel.com) Subject: Re: why i should like pibs References: <10C8636AE359D4119118009027AE99870DA5DEC2@FMSMSX34> Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> Durham, David writes: Dave> * Faster, better & more. Very impressive. Dave> Change 10000 DiffServ Filter+meter+action Dave> entries through a T1 line with a 10msec RTT for 48byte packets: Dave> SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds. Dave> COPS=((10000*8*(498/10))/1540000)=2.59 Seconds. Is 100x Dave> improvement sufficiently better? And the multiple goes up with Dave> the more data you xfer. ... adding bandwidth doesn't help, it's Dave> that dang RTT. Even with SNMP over UDP, you can stream set requests as long as they are independent of each other (which I guess is true if you populate a DiffServ filter table). Since you did not take TCP acks into account, I would say the second term is in equation (1) is 0 if you are smart enough. With SNMP over TCP, the difference also boils down to the reduced OID overhead in COPS-PR, which is probably not that much an issue on the T1 link. Anyway, I agree with other folks that it is pointless to redo all the discussions of the past so I better stop this. From my perspective, the major technical contribution of COPS-PR over SNMP is: a) TCP transport for large transactions when the network is up and running. b) Reduced OID overhead and less degrees of freedom to achieve the same thing. c) Slightly improved data definition language - but nothing which gives us real reusable and extensible data structures. d) State sharing and one manager assumption. e) Some failover support built into the protoco. Items a) and b) are technically easy to support in SNMP. The real problem here is the "SNMP community process" which is in blocking mode for several years now for various non-technical reasons. Item c) contains some minor enhancements over SMIv2 but if people want a really improved data definition language, then the SMIng WG is the place to go (sure, I am biased on this ;-). Items d) and e) are more interesting to implement in an SNMP world since one of the fundamentals in SNMP is the multi-manager assumption. Sure, one can setup existing SNMP access control to allow only one manager and one can define notifications to signal state changes - but this is not hard wired into the protocol (and I guess it will never be). The same is true for failover handling - it is not part of the SNMP protocol but can be built around it. Perhaps one could do interesting things by actually running SNMP over SCTP, which is perhaps theoretically much better suited for management purposes than UDP and TCP... [Perhaps this is closer to the technical summary Randy asked for.] /js -- Juergen Schoenwaelder From owner-ipsec-policy@mail.vpnc.org Tue Mar 19 08:25:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21153 for ; Tue, 19 Mar 2002 08:25:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JCmXv07121 for ipsec-policy-bks; Tue, 19 Mar 2002 04:48:33 -0800 (PST) Received: from mx03.gis.net (mx03.gis.net [208.218.130.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JCmU407112 for ; Tue, 19 Mar 2002 04:48:31 -0800 (PST) Received: from callisto.jdscons.com ([216.243.57.15]) by mx03.gis.net; Tue, 19 Mar 2002 07:48:21 -0500 (EST) From: Jon Saperia Reply-To: saperia@jdscons.com To: Brian E Carpenter , "Yavatkar, Raj" , snmpconf@snmp.com Subject: Re: [Diffserv] RE: why i should like pibs Date: Tue, 19 Mar 2002 07:41:19 -0500 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org References: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> <3C967184.41C12D4C@hursley.ibm.com> In-Reply-To: <3C967184.41C12D4C@hursley.ibm.com> MIME-Version: 1.0 Message-Id: <02031907472202.01787@callisto.jdscons.com> Content-Transfer-Encoding: 8bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I am confused by this posting. In 1999 there was considerable debate on this subject and it went on for quite some time. I very much doubt that there will be new issues raised. The technical details are in the record and I just do not see what value there is in discussing them over again. Could you or Randy explain how the IESG has changed its position, if at all. At an OPS area open meeting about a year ago, I left with the impression that the ADs for O&M were going to support multiple approaches (at least for some time). Has this position changed? If so what is the decision the IESG and/or the DiffServ WG attempting to make? /jon On Mon, 18 Mar 2002, Brian E Carpenter wrote: > Let's try to stick to technical issues please, at least if > you want to keep the diffserv list on this thread. > > The technical issue is: does COPS-PR have *significant* technical > advantages over the existing alternatives, that would justify > the added mechanisms and complexity? > > Brian > > "Yavatkar, Raj" wrote: > > > > Hi Walter: > > > > Thanks for a really nice summary. I continue to be amazed at how Randy is > > applying a set of inconsistent standards to this work vs other work being > > done. Rob Coltun put the current state of IETF well in his departing message > > -- I was hoping that would wake up IESG to move away from such political > > shenanigans to getting work done especially when vendors with products or > > implementations are working towards standardization. > > > > Raj > > > > -----Original Message----- > > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > > Sent: Monday, March 18, 2002 11:45 AM > > To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org > > Cc: ipsec-policy@vpnc.org > > Subject: [Diffserv] RE: why i should like pibs > > > > Randy, > > > > I have two responses. > > > > 1. Political: > > Why are you asking? Why do you keep asking? And more importantly why, based > > on your criteria, haven't you asked for every non-monitoring MIB, or for > > various other works such as Policy Framework. I don't mind if we want to > > have a substantive discussion around the evolution of configuration > > management if you applied your own metrics consistently. If you believe that > > none of these technologies meet's your requirements, then freeze them all. > > At least then there will be some pressure on all the parties to converge to > > a common approach. Personally, I believe your question is a waste of time > > since the existing IETF process addresses your question when there is > > sufficient implementation to transition standards from proposed standards to > > draft standards. Certainly there have been lot's of standards that have > > never made it past proposed for the very reasons you describe. > > > > 2. Technical: > > Given your role, I would not expect you to use this PIB. The very argument > > justifying DiffServ is the same one that Operators use to manage their > > networks. Both share the goal of making the core of the network static and > > stupid (minimal configuration). By recognizing that the core should be kept > > as simple as possible, we also all understand that removing complexity from > > the core only moves the complexity to some other location: the edge. If the > > edge must configure bindings of QoS, Security, Access Control, Tunneling, > > Usage Accounting, etc, this drives specific requirements that COPS-PR comes > > closest to meeting. I could go into all the details here, but given that > > this thread inevitably de-evolves to the usual suspects and the usual > > posturing, I have serious doubts about the value of going into any more > > details. > > > > regards, > > > > -Walter > > > > > -----Original Message----- > > > From: Randy Bush [mailto:randy@psg.com] > > > Sent: Monday, March 18, 2002 9:13 AM > > > To: rap@ops.ietf.org; diffserv@ietf.org > > > Cc: ipsec-policy@vpnc.org > > > Subject: why i should like pibs > > > > > > > > > wearing my iesg hat but being just a stupid operator, i am trying to > > > understand the pib/mib controversy. fyi, i currently use snmp heavily > > > for monitoring devices on my network. i configure using > > > large db-driven > > > code and spew text-based cli to the devices. > > > > > > let's assume i want to take the leap to a binary, as opposed > > > to textual, > > > configuration language. i.e. for some reason(s) [which we will PLEASE > > > NOT discuss here] i decide to move from pushing text-based cli configs > > > out to pushing a binary format. > > > > > > hence, i would have to push my vendors to implement snmp/cops > > > writes for > > > all configuration aspects of all devices. this would be big cost for > > > both me and for my vendors. > > > > > > why would cops/pibs be significantly better (remember it has > > > to replace > > > my current investment, so it can not be 'just as good') than > > > snmp/mibs? > > > > > > randy > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- ---- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com From owner-ipsec-policy@mail.vpnc.org Tue Mar 19 09:46:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23157 for ; Tue, 19 Mar 2002 09:46:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JEAwR11205 for ipsec-policy-bks; Tue, 19 Mar 2002 06:10:58 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JEAr411195 for ; Tue, 19 Mar 2002 06:10:54 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id PAA74790; Tue, 19 Mar 2002 15:08:50 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2JE8lt27464; Tue, 19 Mar 2002 15:08:47 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66420 from ; Tue, 19 Mar 2002 15:08:37 +0100 Message-Id: <3C974652.D23D7C46@hursley.ibm.com> Date: Tue, 19 Mar 2002 15:08:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: saperia@jdscons.com Cc: "Yavatkar, Raj" , snmpconf@snmp.com, "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: Re: [Diffserv] RE: why i should like pibs References: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> <3C967184.41C12D4C@hursley.ibm.com> <02031907472202.01787@callisto.jdscons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The diffserv WG isn't taking any decision - we have completed our work on the diffserv PIB and submitted it to the IESG. As for the IESG's intentions, it is for them to reply. Brian Jon Saperia wrote: > > I am confused by this posting. In 1999 there was considerable debate on this > subject and it went on for quite some time. I very much doubt that there will > be new issues raised. The technical details are in the record and I just do not > see what value there is in discussing them over again. Could you or Randy > explain how the IESG has changed its position, if at all. At an OPS area open > meeting about a year ago, I left with the impression that the ADs for O&M were > going to support multiple approaches (at least for some time). Has this > position changed? If so what is the decision the IESG and/or the DiffServ WG > attempting to make? > > /jon > > On Mon, 18 Mar 2002, Brian E Carpenter wrote: > > Let's try to stick to technical issues please, at least if > > you want to keep the diffserv list on this thread. > > > > The technical issue is: does COPS-PR have *significant* technical > > advantages over the existing alternatives, that would justify > > the added mechanisms and complexity? > > > > Brian > > > > "Yavatkar, Raj" wrote: > > > > > > Hi Walter: > > > > > > Thanks for a really nice summary. I continue to be amazed at how Randy is > > > applying a set of inconsistent standards to this work vs other work being > > > done. Rob Coltun put the current state of IETF well in his departing message > > > -- I was hoping that would wake up IESG to move away from such political > > > shenanigans to getting work done especially when vendors with products or > > > implementations are working towards standardization. > > > > > > Raj > > > > > > -----Original Message----- > > > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > > > Sent: Monday, March 18, 2002 11:45 AM > > > To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org > > > Cc: ipsec-policy@vpnc.org > > > Subject: [Diffserv] RE: why i should like pibs > > > > > > Randy, > > > > > > I have two responses. > > > > > > 1. Political: > > > Why are you asking? Why do you keep asking? And more importantly why, based > > > on your criteria, haven't you asked for every non-monitoring MIB, or for > > > various other works such as Policy Framework. I don't mind if we want to > > > have a substantive discussion around the evolution of configuration > > > management if you applied your own metrics consistently. If you believe that > > > none of these technologies meet's your requirements, then freeze them all. > > > At least then there will be some pressure on all the parties to converge to > > > a common approach. Personally, I believe your question is a waste of time > > > since the existing IETF process addresses your question when there is > > > sufficient implementation to transition standards from proposed standards to > > > draft standards. Certainly there have been lot's of standards that have > > > never made it past proposed for the very reasons you describe. > > > > > > 2. Technical: > > > Given your role, I would not expect you to use this PIB. The very argument > > > justifying DiffServ is the same one that Operators use to manage their > > > networks. Both share the goal of making the core of the network static and > > > stupid (minimal configuration). By recognizing that the core should be kept > > > as simple as possible, we also all understand that removing complexity from > > > the core only moves the complexity to some other location: the edge. If the > > > edge must configure bindings of QoS, Security, Access Control, Tunneling, > > > Usage Accounting, etc, this drives specific requirements that COPS-PR comes > > > closest to meeting. I could go into all the details here, but given that > > > this thread inevitably de-evolves to the usual suspects and the usual > > > posturing, I have serious doubts about the value of going into any more > > > details. > > > > > > regards, > > > > > > -Walter > > > > > > > -----Original Message----- > > > > From: Randy Bush [mailto:randy@psg.com] > > > > Sent: Monday, March 18, 2002 9:13 AM > > > > To: rap@ops.ietf.org; diffserv@ietf.org > > > > Cc: ipsec-policy@vpnc.org > > > > Subject: why i should like pibs > > > > > > > > > > > > wearing my iesg hat but being just a stupid operator, i am trying to > > > > understand the pib/mib controversy. fyi, i currently use snmp heavily > > > > for monitoring devices on my network. i configure using > > > > large db-driven > > > > code and spew text-based cli to the devices. > > > > > > > > let's assume i want to take the leap to a binary, as opposed > > > > to textual, > > > > configuration language. i.e. for some reason(s) [which we will PLEASE > > > > NOT discuss here] i decide to move from pushing text-based cli configs > > > > out to pushing a binary format. > > > > > > > > hence, i would have to push my vendors to implement snmp/cops > > > > writes for > > > > all configuration aspects of all devices. this would be big cost for > > > > both me and for my vendors. > > > > > > > > why would cops/pibs be significantly better (remember it has > > > > to replace > > > > my current investment, so it can not be 'just as good') than > > > > snmp/mibs? > > > > > > > > randy > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > -- > ---- > Jon Saperia > > saperia@jdscons.com > Phone: 617-744-1079 > Fax: 617-249-0874 > http://www.jdscons.com From owner-ipsec-policy@mail.vpnc.org Tue Mar 19 23:58:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15297 for ; Tue, 19 Mar 2002 23:58:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2K41wJ12808 for ipsec-policy-bks; Tue, 19 Mar 2002 20:01:58 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2K41u412803 for ; Tue, 19 Mar 2002 20:01:56 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2K44JQ14715 for ; Tue, 19 Mar 2002 22:04:20 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Mar 2002 22:01:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Mar 2002 22:01:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: why i should like pibs Date: Tue, 19 Mar 2002 23:01:57 -0500 Message-ID: Thread-Topic: why i should like pibs Thread-Index: AcHOh8rWfbkohePWSTOxuHnRyLcUewBOSbHA From: To: , , Cc: X-OriginalArrivalTime: 20 Mar 2002 04:01:58.0753 (UTC) FILETIME=[FB76E510:01C1CFC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2K41u412805 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit David Durham's list is comprehensive enough. How much more does IESG need? Since as many indicated that it is probably pointless to re-open all the discussions, why can't we just move the Framework and Diffserv PIBs to ps and let the market decide the usefulness of PIBs instead of trying to decide for the market? Man Li -----Original Message----- From: ext Randy Bush [mailto:randy@psg.com] Sent: March 18, 2002 09:13 AM To: rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy From owner-ipsec-policy@mail.vpnc.org Wed Mar 20 13:29:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09409 for ; Wed, 20 Mar 2002 13:29:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KHqXK02628 for ipsec-policy-bks; Wed, 20 Mar 2002 09:52:33 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KHqW402623 for ; Wed, 20 Mar 2002 09:52:32 -0800 (PST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2KHqLM16504 for ; Wed, 20 Mar 2002 17:52:22 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2KHpQk28487 for ; Wed, 20 Mar 2002 17:51:26 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032009555915974 ; Wed, 20 Mar 2002 09:55:59 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 09:52:33 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> From: "Durham, David" To: Juergen Schoenwaelder Cc: randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: RE: why i should like pibs Date: Wed, 20 Mar 2002 09:52:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, I did some pings and found my 10ms RTT was unrealistic. 100ms is more like it. At 100ms RTT, things get much worse for the SNMP equation for the configuration example I described: SNMP=2026 Seconds (over half an hour!) COPS=2.59 Seconds Now we're talking 1000x faster... > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: Tuesday, March 19, 2002 2:40 AM > > Dave> Change 10000 DiffServ Filter+meter+action > Dave> entries through a T1 line with a 10msec RTT for 48byte packets: > Dave> SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds. > Dave> COPS=((10000*8*(498/10))/1540000)=2.59 Seconds. Is 100x > Dave> improvement sufficiently better? And the multiple goes up with > Dave> the more data you xfer. ... adding bandwidth doesn't help, it's > Dave> that dang RTT. > > Even with SNMP over UDP, you can stream set requests as long as they > are independent of each other (which I guess is true if you populate a > DiffServ filter table). Since you did not take TCP acks into account, > I would say the second term is in equation (1) is 0 if you are smart > enough. With SNMP over TCP, the difference also boils down to the > reduced OID overhead in COPS-PR, which is probably not that much an > issue on the T1 link. Anyway, I agree with other folks that it is > pointless to redo all the discussions of the past so I better stop > this. > [Dave] TCP ACKs piggyback on messages going the other way. TCP is quite efficient in that way. Actually, I think I was far too kind in my calculations. Just the other day an operator said SNMP implementations can take hours to update his big BGP tables. Clearly with SNMP, results will vary. While with COPS-PR, it's the TCP stack that matters, and that makes it a no-brainer for implementations. Remember also that COPS-PR presents a transactional model to the user, while SNMP simply provides a get/set interface, so it's not just an implementation issue; it's a presentation issue as well. [Dave] The SNMP example gets far worse when you have to consider the multiple manager problem. Now you will have to hold each of the 30000 row status variables until the transaction completes, and reset them thereafter. In such cases you also will have to constantly check that some other manager didn't come and munge your configuration. This quickly becomes an unmanageable situation, and I cannot write an equation that is long enough to adequately express that problem. > From my perspective, the major technical contribution of COPS-PR over > SNMP is: > > a) TCP transport for large transactions when the network is up and > running. > > b) Reduced OID overhead and less degrees of freedom to achieve the same > thing. > > c) Slightly improved data definition language - but nothing which gives > us real reusable and extensible data structures. > [Dave] I disagree. You certainly do get full reusability and extensible data structures. The reusability is both syntactic and semantic. > d) State sharing and one manager assumption. > [Dave] One manager for its set of instance data (so there is no danger of configuration corruption). The COPS-PR protocol supports 64000 managers per device. > e) Some failover support built into the protoco. > > Items a) and b) are technically easy to support in SNMP. The real > problem here is the "SNMP community process" which is in blocking mode > for several years now for various non-technical reasons. > [Dave] By the time you integrate all the COPS-PR features and advancements into SNMP, you still get COPS-PR, just 5 years too late. But, perhaps the best reason of all for COPS-PR and PIBs is that you don't have the "SNMP community process" that you just described. > Item c) contains some minor enhancements over SMIv2 but if people want > a really improved data definition language, then the SMIng WG is the > place to go (sure, I am biased on this ;-). > [Dave]Yes, go to the SMIng WG, that's where the good stuff is being done ;-) From owner-ipsec-policy@mail.vpnc.org Wed Mar 20 14:49:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12108 for ; Wed, 20 Mar 2002 14:49:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KJFH705663 for ipsec-policy-bks; Wed, 20 Mar 2002 11:15:17 -0800 (PST) Received: from mailhost2.unispherenetworks.com (mailhost2.unispherenetworks.com [65.194.140.138]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KJFG405659 for ; Wed, 20 Mar 2002 11:15:16 -0800 (PST) Received: by email2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <19PHH410>; Wed, 20 Mar 2002 08:53:31 -0500 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F04D3DFDA@email2.it.west.unispherenetworks.com> From: "Moisand, Jerome" To: "'Man.M.Li@nokia.com'" , randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: RE: why i should like pibs Date: Wed, 20 Mar 2002 08:53:30 -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: Sounds to be the wise approach... Can't agree more. Jerome Moisand Unisphere Networks -----Original Message----- From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] Sent: Tuesday, March 19, 2002 11:02 PM To: randy@psg.com; rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: RE: why i should like pibs David Durham's list is comprehensive enough. How much more does IESG need? Since as many indicated that it is probably pointless to re-open all the discussions, why can't we just move the Framework and Diffserv PIBs to ps and let the market decide the usefulness of PIBs instead of trying to decide for the market? Man Li -----Original Message----- From: ext Randy Bush [mailto:randy@psg.com] Sent: March 18, 2002 09:13 AM To: rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy ======================================= This email message is for the sole use of the intended recipient (s) and may contain confidential and privileged information, including without limitation, Confidential and/or Proprietary Information belonging to Unisphere Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. From owner-ipsec-policy@mail.vpnc.org Thu Mar 21 05:55:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08558 for ; Thu, 21 Mar 2002 05:55:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LAQo825865 for ipsec-policy-bks; Thu, 21 Mar 2002 02:26:50 -0800 (PST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LAQl425861 for ; Thu, 21 Mar 2002 02:26:48 -0800 (PST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g2LAQh7V031396; Thu, 21 Mar 2002 11:26:43 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2LAQg612161; Thu, 21 Mar 2002 11:26:42 +0100 Date: Thu, 21 Mar 2002 11:26:42 +0100 Message-Id: <200203211026.g2LAQg612161@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: david.durham@intel.com CC: randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org In-reply-to: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> (david.durham@intel.com) Subject: Re: why i should like pibs References: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [ Based on Dave Durhams comments, I will update my attempt to summarize the major technical contributions of COPS-PR over SNMP. I will do so on the only so that we can stop these cross posts. Below are just my hopefully final comments on Dave's numbers. ] >>>>> Durham, David writes: Dave> Actually, I did some pings and found my 10ms RTT was Dave> unrealistic. 100ms is more like it. At 100ms RTT, things get Dave> much worse for the SNMP equation for the configuration example I Dave> described: Dave> SNMP=2026 Seconds (over half an hour!) COPS=2.59 Seconds Dave> Now we're talking 1000x faster... I probably do not understand your equations. There is the actual transmission time Tx and the propagation delay Tp. We have n = number of filter entries m = size of a single filter entry s = "speed" of the link r = round trip time If I understand you correctly, you assume: Tx_s = (n * m) / s # SNMP n messages of size m Tx_c = (n * m/10) / s # COPS filters are 10 times smaller Obviously: Tx_c = 1/10 Tx_s You also seem to assume: Tp_s = (2 * n) * r # SNMP sequential one set a time Tp_c = 0 # COPS does not need a round trip In case this is your model (forgive me if I messed it up), I think it is an over-simplification and the numbers you get out of it do not impress me that much. (Did you ever calculate how big your TCP window must be to do your example in one^H^H^Hzero RTT?) Still I agree (and have ever done so in the past) with the qualitative statment "COPS-PR is faster due to larger transactions and the TCP transport in cases the network is running normally". Dave> Remember also that COPS-PR presents a transactional model to the Dave> user, while SNMP simply provides a get/set interface, so it's Dave> not just an implementation issue; it's a presentation issue as Dave> well. I never got that into my brain. An SNMP SET is a single transaction just as a COPS-PR DEC is a single transaction. The difference is just the message sizes you can use. /js -- Juergen Schoenwaelder From owner-ipsec-policy@mail.vpnc.org Thu Mar 21 12:51:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19683 for ; Thu, 21 Mar 2002 12:51:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2LHJLV20687 for ipsec-policy-bks; Thu, 21 Mar 2002 09:19:21 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LHJJ420683 for ; Thu, 21 Mar 2002 09:19:19 -0800 (PST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2LHJ7e21022 for ; Thu, 21 Mar 2002 17:19:08 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2LHIC813520 for ; Thu, 21 Mar 2002 17:18:12 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032109224803836 ; Thu, 21 Mar 2002 09:22:48 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 09:19:20 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C0451C172@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs Date: Thu, 21 Mar 2002 09:19:14 -0800 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: I would like to say that this question bothers me. The term *significant* is a highly subjective term that will be interpreted in different ways by different people. The *significant* attribute that might convince you, Randy, to make a purchase are probably a completely different set of *significant* attributes that would affect my (or someone else's) purchase. I think the key point is that the IESG has chartered the working groups. The COPS documents that are currently in front of the IESG are part of the charters of the WG's involved. The IESG accepted these charters with these documents as work items. And finally, the WG chairs were asked by the IESG to request from the community at large for a count of companies that are planning implementations of the protocol which resulted in a number of positive responses. There are obviously volunteers from the IETF community willing to do the work. I would like to see the IESG let the market decide whether the advantages of using COPS and COPS-PR for configuration make it a success or not. -Scott From owner-ipsec-policy@mail.vpnc.org Thu Mar 21 12:59:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20134 for ; Thu, 21 Mar 2002 12:59:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LHVWp22075 for ipsec-policy-bks; Thu, 21 Mar 2002 09:31:32 -0800 (PST) Received: from roam.psg.com (exim@roam.psg.com [166.63.190.213] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LHVV422068 for ; Thu, 21 Mar 2002 09:31:31 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 4.00) id 16o6PK-0000Uw-00; Thu, 21 Mar 2002 11:31:22 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kwok Ho Chan Cc: rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: Re: why i should like pibs References: <5.0.0.25.0.20020321114636.025e83f0@zbl6c002.corpeast.baynetworks.com> Message-Id: Date: Thu, 21 Mar 2002 11:31:22 -0600 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > There have been some informational responses with regard to the your > question. indeed. all sorts of information :-). (not to worry, i am quite thick skinned as well as thick headed) i am really trying to blank my mind to history etc., and take a raw look at these things. as i am an engineer not a marketeer, if i have to sell it to the iesg/iab, i need to believe it. and to believe it, i have to try to understand it. so the input is *very* much appreciated. apologies for asking that the input be in email. but it forces a record, and the openness keeps people somewhat honest. it also gives us an opportunity to practice working politely despite disagreements. it is hard to think deeply during ietf week. over the next three weeks, i have two 30+ hour plane rides and a bit of calm time, in which i hope to read and think calmly. thanks for your patience. randy From owner-ipsec-policy@mail.vpnc.org Thu Mar 21 16:48:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26582 for ; Thu, 21 Mar 2002 16:48:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LLDAO03305 for ipsec-policy-bks; Thu, 21 Mar 2002 13:13:10 -0800 (PST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LLD8403301 for ; Thu, 21 Mar 2002 13:13:08 -0800 (PST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2LLD4113327 for ; Thu, 21 Mar 2002 16:13:05 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 22:13:03 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: rap@ops.ietf.org Cc: diffserv@ietf.org, ipsec-policy@vpnc.org Subject: RE: why i should like pibs Date: Thu, 21 Mar 2002 22:13:01 +0100 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: All, Let me post to these lists a similar statement as I made in the RAP WG meeting at this 53rd IETF, so that everyone has the same info. Here we go. I would prefer to have andy reactions (if any) posted to just one mailing list (the RAP wg mailing list). When the WG completed WG Last Call and reached consensus on the FRAMEWORK PIB, the WG chairs asked me (the primary AD for the WG) to consider this document for Proposed Standard. Normally I then review and ask for IETF wide Last Call and if no valid objections are received, then I put the document on the IESG agenda for approval. My current evaluation however for this document at this time is as follows: - If we look at the NM related activities, then we can see that for SNMP/MIBs, the majority of work/time/effort is spent in the MIB development. It also touches on virtually all WGs. Same will be true for COPS-PR/PIBs if we start to put PIBs on the standareds track. This could be a VERY BIG thing. In SNMP, the real investment is in MIBs. This is true for MIB design (IETF), for vendor implementation effort, and for user deployment. If IETF working groups start to develop PIBs they would be faced with significant extra, and in many cases, redundant effort - We have accepted COPS and COPS-PR 2-3 years ago as PS. That was the start of a duplicate approach, which only provides marginal improvement in some areas, and possibly a negative effect in some other areas. - We have also accepted SPPI as a duplicate approach, again with only marginal improvement. It allows to define PIBs, most of which I think can also be done with MIBs or better/different MIB design. - Note that PIBs are basically intended for configuring network devices and services. - Two years back, the ADs and Diffserv WG chairs agreed to do a MIB and a PIB for standards track. And we agreed with the RAP WG to develop a set of base PIBs for standards track. - Meanwhile, we have seen: - Some key players withdrew from COPS and PIBs approach They claim there is no market, and with reduced budgets there is no place to just do multiple solutions to same address space. - In most cases, PIB development is done by different people than MIB development, if we're lucky they talk to each other. - WGs in general have very little interest in MIBs or in PIBs, let alone both. - Operators (ISPs) tell us they do not see much use for binary interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to configure their network devices/services. The reality is that they use (and expect to have to continue to use) ASCII based CLI-type interfaces (Maybe ASCII should read human readable) - We have started an effort to try and consolidate SMI and SPPI We may want to await the results before we invest in the standardization of PIBs. - The NM community in the IETF (lots of SNMP folk, but COPS, Policy WG and Operators are participating too) are trying to come up with some vision/framework to address Operator (ISP) concerns. Discussions is only in beginning stages and not any IETF sanctioned status yet. - IAB is planning a NM Architecture Workshop this summer (as announced at the IAB plenary on Wednesday March 20th) - We (the IETF/IESG) are to decide on the first IETF produced PIBs. If we approve them as standards track, then: - I suspect we will find a lot of duplicate work, i.e. MIBs and PIBs, to be designed, tested, handled-for-stds-track approval - Vendors and users may be faced with the big duplicate investment. They can opt to not do so, but of course the more PIBs we approve as stds track, the more the pressure will be put on them. - We are telling the market that we cannot decide and let them do it. Maybe this is OK. But not in my mind, I do not think we do the IETF community or the world a favor by approving this duplicate approach As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB (or any PIBs for that matter) on the standards track at this point in time. I strongly recommend to publish them as Informational for now. We can revisit this after we get some better architectural guidelines/help from the current actitivities that are taking place in informal gatherings and the upcoming IAB NM Workshop. I understand that this is sort of "breaking the contract" with the RAP WG on my part. But the situation has changed quite a bit from 2 years ago when we started down this path (agreed on the WG charter). Bert From owner-ipsec-policy@mail.vpnc.org Thu Mar 21 17:51:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28445 for ; Thu, 21 Mar 2002 17:51:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LMKNX06964 for ipsec-policy-bks; Thu, 21 Mar 2002 14:20:23 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LMKI406960 for ; Thu, 21 Mar 2002 14:20:18 -0800 (PST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2LMIxH00373 for ; Thu, 21 Mar 2002 22:19:00 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2LMJ6C26965 for ; Thu, 21 Mar 2002 22:19:06 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032114194032410 ; Thu, 21 Mar 2002 14:19:40 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 14:20:14 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DED4@FMSMSX34> From: "Durham, David" To: "Wijnen, Bert (Bert)" , rap@ops.ietf.org Cc: diffserv@ietf.org, ipsec-policy@vpnc.org Subject: RE: why i should like pibs Date: Thu, 21 Mar 2002 14:20:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Reaction (sorry): I must remind Bert that he did advocate moving the DiffServ MIB along on standards track despite it has demonstrated NO ADOPTION FOR CONFIGURATION. Whereas the DiffServ PIB has ALREADY demonstrated significant enough adoption to move to DRAFT STANDARD... And yet this door is now being shut. If it becomes a BIG THING, it means the industry has in fact decided! Why should one stand in the way and prevent this from happening? The simple reason is that PIBs are easier to write and easier to use, and that's why, despite the downfall of the Internet economy, they continue grow and to amaze with their resilience. Artificially cutting them off at the knees is simply not the IETF way. -Dave > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, March 21, 2002 1:13 PM > To: rap@ops.ietf.org > Cc: diffserv@ietf.org; ipsec-policy@vpnc.org > Subject: RE: why i should like pibs > > All, > > Let me post to these lists a similar statement as I made in the > RAP WG meeting at this 53rd IETF, so that everyone has the same > info. Here we go. I would prefer to have andy reactions (if any) > posted to just one mailing list (the RAP wg mailing list). > > When the WG completed WG Last Call and reached consensus on > the FRAMEWORK PIB, the WG chairs asked me (the primary AD > for the WG) to consider this document for Proposed Standard. > Normally I then review and ask for IETF wide Last Call and > if no valid objections are received, then I put the document > on the IESG agenda for approval. > > My current evaluation however for this document at this time > is as follows: > - If we look at the NM related activities, then we can see > that for SNMP/MIBs, the majority of work/time/effort is > spent in the MIB development. It also touches on virtually > all WGs. Same will be true for COPS-PR/PIBs if we start to > put PIBs on the standareds track. > This could be a VERY BIG thing. In SNMP, the real investment > is in MIBs. This is true for MIB design (IETF), for vendor > implementation effort, and for user deployment. If IETF > working groups start to develop PIBs they would be faced > with significant extra, and in many cases, redundant effort > - We have accepted COPS and COPS-PR 2-3 years ago as PS. > That was the start of a duplicate approach, which only > provides marginal improvement in some areas, and possibly > a negative effect in some other areas. > - We have also accepted SPPI as a duplicate approach, again > with only marginal improvement. It allows to define PIBs, > most of which I think can also be done with MIBs or > better/different MIB design. > - Note that PIBs are basically intended for configuring > network devices and services. > - Two years back, the ADs and Diffserv WG chairs agreed to do > a MIB and a PIB for standards track. And we agreed with the > RAP WG to develop a set of base PIBs for standards track. > - Meanwhile, we have seen: > - Some key players withdrew from COPS and PIBs approach > They claim there is no market, and with reduced budgets > there is no place to just do multiple solutions to same > address space. > - In most cases, PIB development is done by different people > than MIB development, if we're lucky they talk to each other. > - WGs in general have very little interest in MIBs or in PIBs, > let alone both. > - Operators (ISPs) tell us they do not see much use for binary > interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to > configure their network devices/services. The reality is that > they use (and expect to have to continue to use) ASCII based > CLI-type interfaces (Maybe ASCII should read human readable) > - We have started an effort to try and consolidate SMI and SPPI > We may want to await the results before we invest in the > standardization of PIBs. > - The NM community in the IETF (lots of SNMP folk, but COPS, > Policy WG and Operators are participating too) are trying to > come up with some vision/framework to address Operator (ISP) > concerns. Discussions is only in beginning stages and not any > IETF sanctioned status yet. > - IAB is planning a NM Architecture Workshop this summer (as > announced at the IAB plenary on Wednesday March 20th) > - We (the IETF/IESG) are to decide on the first IETF produced PIBs. > If we approve them as standards track, then: > - I suspect we will find a lot of duplicate work, i.e. MIBs and > PIBs, to be designed, tested, handled-for-stds-track approval > - Vendors and users may be faced with the big duplicate investment. > They can opt to not do so, but of course the more PIBs we approve > as stds track, the more the pressure will be put on them. > - We are telling the market that we cannot decide and let them do it. > Maybe this is OK. But not in my mind, I do not think we do the > IETF community or the world a favor by approving this duplicate > approach > > As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB > (or any PIBs for that matter) on the standards track at this point > in time. I strongly recommend to publish them as Informational for > now. We can revisit this after we get some better architectural > guidelines/help from the current actitivities that are taking > place in informal gatherings and the upcoming IAB NM Workshop. > > I understand that this is sort of "breaking the contract" with > the RAP WG on my part. But the situation has changed quite a bit > from 2 years ago when we started down this path (agreed on the WG > charter). > > Bert From owner-ipsec-policy@mail.vpnc.org Thu Mar 21 18:24:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29653 for ; Thu, 21 Mar 2002 18:24:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LMvtM08224 for ipsec-policy-bks; Thu, 21 Mar 2002 14:57:55 -0800 (PST) Received: from mailhost2.unispherenetworks.com (mailhost2.unispherenetworks.com [65.194.140.138]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LMvs408220 for ; Thu, 21 Mar 2002 14:57:54 -0800 (PST) Received: by email2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 17:57:51 -0500 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F04D3DFFF@email2.it.west.unispherenetworks.com> From: "Moisand, Jerome" To: rap@ops.ietf.org Cc: diffserv@ietf.org, ipsec-policy@vpnc.org Subject: RE: why i should like pibs --- AAARRRGH - ENOUGH! ;-) Date: Thu, 21 Mar 2002 17:57:41 -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: Ok, this must be the 100th e-mail on this discussion (or close ;-). May I suggest that we all take a few weeks to think about it and people with enough motivation will develop clean, structured and (hopefully) factual arguments one way or the other? Bert summary is very helpful by clearly characterizing the points of concerns. One may agree or not, but we know what to discuss. I'm afraid that the flurry of e-mails for the last few days and the format of some of the statements being made, clearly show we're all somehow over-reacting, knee-jerk-reacting, etc. So taking a bit more time to digest Bert summary, and develop structured responses (pros & cons & new points if any) should lead to a more fruitful discussion. Consequently, may I suggest that the status of these (much debated) I-Ds is kept open for a few more weeks or months? Maybe until the next IETF meeting? Is this a neutral (hence reasonable) enough approach? Jerome PS. In the mean time, I guess I know why "we should not like mibs and pibs"... The topic generates way too many e-mails... ok, just kidding! ;-) -----Original Message----- From: Durham, David [mailto:david.durham@intel.com] Sent: Thursday, March 21, 2002 5:20 PM To: Wijnen, Bert (Bert); rap@ops.ietf.org Cc: diffserv@ietf.org; ipsec-policy@vpnc.org Subject: RE: why i should like pibs Reaction (sorry): I must remind Bert that he did advocate moving the DiffServ MIB along on standards track despite it has demonstrated NO ADOPTION FOR CONFIGURATION. Whereas the DiffServ PIB has ALREADY demonstrated significant enough adoption to move to DRAFT STANDARD... And yet this door is now being shut. If it becomes a BIG THING, it means the industry has in fact decided! Why should one stand in the way and prevent this from happening? The simple reason is that PIBs are easier to write and easier to use, and that's why, despite the downfall of the Internet economy, they continue grow and to amaze with their resilience. Artificially cutting them off at the knees is simply not the IETF way. -Dave > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, March 21, 2002 1:13 PM > To: rap@ops.ietf.org > Cc: diffserv@ietf.org; ipsec-policy@vpnc.org > Subject: RE: why i should like pibs > > All, > > Let me post to these lists a similar statement as I made in the > RAP WG meeting at this 53rd IETF, so that everyone has the same > info. Here we go. I would prefer to have andy reactions (if any) > posted to just one mailing list (the RAP wg mailing list). > > When the WG completed WG Last Call and reached consensus on > the FRAMEWORK PIB, the WG chairs asked me (the primary AD > for the WG) to consider this document for Proposed Standard. > Normally I then review and ask for IETF wide Last Call and > if no valid objections are received, then I put the document > on the IESG agenda for approval. > > My current evaluation however for this document at this time > is as follows: > - If we look at the NM related activities, then we can see > that for SNMP/MIBs, the majority of work/time/effort is > spent in the MIB development. It also touches on virtually > all WGs. Same will be true for COPS-PR/PIBs if we start to > put PIBs on the standareds track. > This could be a VERY BIG thing. In SNMP, the real investment > is in MIBs. This is true for MIB design (IETF), for vendor > implementation effort, and for user deployment. If IETF > working groups start to develop PIBs they would be faced > with significant extra, and in many cases, redundant effort > - We have accepted COPS and COPS-PR 2-3 years ago as PS. > That was the start of a duplicate approach, which only > provides marginal improvement in some areas, and possibly > a negative effect in some other areas. > - We have also accepted SPPI as a duplicate approach, again > with only marginal improvement. It allows to define PIBs, > most of which I think can also be done with MIBs or > better/different MIB design. > - Note that PIBs are basically intended for configuring > network devices and services. > - Two years back, the ADs and Diffserv WG chairs agreed to do > a MIB and a PIB for standards track. And we agreed with the > RAP WG to develop a set of base PIBs for standards track. > - Meanwhile, we have seen: > - Some key players withdrew from COPS and PIBs approach > They claim there is no market, and with reduced budgets > there is no place to just do multiple solutions to same > address space. > - In most cases, PIB development is done by different people > than MIB development, if we're lucky they talk to each other. > - WGs in general have very little interest in MIBs or in PIBs, > let alone both. > - Operators (ISPs) tell us they do not see much use for binary > interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to > configure their network devices/services. The reality is that > they use (and expect to have to continue to use) ASCII based > CLI-type interfaces (Maybe ASCII should read human readable) > - We have started an effort to try and consolidate SMI and SPPI > We may want to await the results before we invest in the > standardization of PIBs. > - The NM community in the IETF (lots of SNMP folk, but COPS, > Policy WG and Operators are participating too) are trying to > come up with some vision/framework to address Operator (ISP) > concerns. Discussions is only in beginning stages and not any > IETF sanctioned status yet. > - IAB is planning a NM Architecture Workshop this summer (as > announced at the IAB plenary on Wednesday March 20th) > - We (the IETF/IESG) are to decide on the first IETF produced PIBs. > If we approve them as standards track, then: > - I suspect we will find a lot of duplicate work, i.e. MIBs and > PIBs, to be designed, tested, handled-for-stds-track approval > - Vendors and users may be faced with the big duplicate investment. > They can opt to not do so, but of course the more PIBs we approve > as stds track, the more the pressure will be put on them. > - We are telling the market that we cannot decide and let them do it. > Maybe this is OK. But not in my mind, I do not think we do the > IETF community or the world a favor by approving this duplicate > approach > > As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB > (or any PIBs for that matter) on the standards track at this point > in time. I strongly recommend to publish them as Informational for > now. We can revisit this after we get some better architectural > guidelines/help from the current actitivities that are taking > place in informal gatherings and the upcoming IAB NM Workshop. > > I understand that this is sort of "breaking the contract" with > the RAP WG on my part. But the situation has changed quite a bit > from 2 years ago when we started down this path (agreed on the WG > charter). > > Bert ======================================= This email message is for the sole use of the intended recipient (s) and may contain confidential and privileged information, including without limitation, Confidential and/or Proprietary Information belonging to Unisphere Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. From owner-ipsec-policy@mail.vpnc.org Thu Mar 21 18:43:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00197 for ; Thu, 21 Mar 2002 18:43:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2LNGEq08719 for ipsec-policy-bks; Thu, 21 Mar 2002 15:16:14 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LNGD408710 for ; Thu, 21 Mar 2002 15:16:13 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id AAA81232; Fri, 22 Mar 2002 00:15:33 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2LNFWF109790; Fri, 22 Mar 2002 00:15:32 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75304 from ; Fri, 22 Mar 2002 00:15:29 +0100 Message-Id: <3C9A697D.E7C80228@hursley.ibm.com> Date: Fri, 22 Mar 2002 00:15:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: Re: [Diffserv] RE: why i should like pibs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Wijnen, Bert (Bert)" wrote: ... > In most cases, PIB development is done by different people > than MIB development, if we're lucky they talk to each other. er, of the three authors of the diffserv MIB, two are also authors of the diffserv PIB, one of them being the active document editor. The PIB has been updated less frequently than the MIB, but it has been tracking it. > - WGs in general have very little interest in MIBs or in PIBs, > let alone both. But as you observed, diffserv was firmly requested by its ADs to develop a MIB and a PIB in parallel, and we did so, and it was a lot of work. Brian From owner-ipsec-policy@mail.vpnc.org Tue Mar 26 21:33:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03800 for ; Tue, 26 Mar 2002 21:33:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2R1ldS25701 for ipsec-policy-bks; Tue, 26 Mar 2002 17:47:39 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2R1lcm25695 for ; Tue, 26 Mar 2002 17:47:38 -0800 (PST) Received: from study ([24.128.201.164]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020327014723.UWXT1147.rwcrmhc52.attbi.com@study> for ; Wed, 27 Mar 2002 01:47:23 +0000 Message-ID: <001401c1d530$8d1b2f00$650a0a0a@ne.client2.attbi.com> From: "Walter Weiss" To: Subject: resend: why i should like pibs Date: Tue, 26 Mar 2002 20:41:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Courtesy resend. -Walter ----- Original Message ----- From: "Walter Weiss" To: ; "DiffServ2" ; <> Sent: Tuesday, March 26, 2002 4:50 PM Subject: Re: why i should like pibs > Bert, > > This is a thoughtful and rational justification to your position. If I may > paraphrase, your primary concerns are: > 1. That the level of interest in this new approach is currently low. > 2. That the value is low given the overlap with MIBs. > 3. That the incremental cost of developing PIBs for all areas in the IETF is > huge. > > Let's consider this from the operations perspective. First of all, the > pervasive perspective that there is only one operations organization is very > misleading. In fact, most providers have multiple operations organizations. > One organization may be responsible for a given backbone while other > organizations within the same provider are responsible for specific > businesses (some regulated and some not), and business models. In many > cases, there are even multiple backbone organizations. These organizations > all have different needs and some are grossly under-represented in our > discussions. In my opinion, this is primarily because many are interested in > service deployments/revenue generation and less interested in low level > transport issues. This perspective has been reinforced by a variety of > discussions I have had with several Tier 1 providers. Hence, a true > understanding of operational needs is far beyond our grasp because we don't > have a statistically significant sample or a true understanding of actual > operational models. Therefore, drawing conclusions about the value of COPS > or PIBS to operators is premature. That said, I would like commend both Bert > and Randy for the initiative they have shown in trying to better understand > operational environments and requirements. > > I would also like to consider this issue from a requirements perspective. In > my view, we can divide operational needs into four areas: Stats Collection, > Events, Static config and Dynamic config. > > Stats Collection has the following characteristics. It is non-real-time, it > consumes lots of bandwidth, and it is not transactional. They are more > suitable to a protocol like TCP that is sensative to congestion control, > which explains why stats are often sent with FTP rather than SNMP. > > Events are real time, small and infrequent messages and non-transactional. > They require guaranteed delivery irrespective of network congestion or loss. > This application is ideally suited to the capabilities of SNMP, which is why > it is so broadly deployed for this purpose. > > Static config is performed in the core of networks where network stability > is critical. This means infrequent changes and the changes that are made are > typically at the transport level (links, routes, route policies, and > filters). Static config messages require transactional and non-real time > messaging. The configurations are complicated. CLI is prefered over SNMP > because the language is simpler than attribute level pokes, because textual > is not significantly more overhead than binary and because the language > provides an abstraction. > > Dynamic config occurs and the edges and focuses exclusively on dynamic > service deployment. It requires frequent updates. In some cases frequent > means every time a user logs in, in other cases it means when a VPN is bound > to a new user, and in other cases every time a service is activated (a > telephone call is made). In this environment, which not adequately addressed > with current technologies, config changes must be performed quickly to > accommodate systems or users waiting for authorization (login, call setup > delay, etc.) Further, because the configurations are relatively complex, > they need large multi-packet messaging and transactional capabilities. > Finally, because most service changes are transitory (when the call > completes, the configs should be uninstalled), a mechanism that simplifies > this process is ideal. IMO, given the requirements, COPS-PR is the optimal > choice amongst the available alternatives. However, I do not believe it is a > suitable technology for the other three operational issues. > > Given the diverse requirements for each aspect of NM, I would suggest that > there is no silver bullet here. No single protocol, transport, or language > can viably meet all the requirements of every aspect of NM. > > I would also like to reconsider Bert's points. First, I would agree that the > level of interest in COPS-PR is relatively small. However, I would argue > that this is because Dynamic Config is only starting to become important as > mappings for QoS, Security, and Tunneling are coming to the forefront. > Second, I disagree that there is overlap with PIBs. While the DiffServ PIB > and MIB are nearly identical, this was done because it was assumed that they > were both addressing the config space that CLI is so clearly dominating. In > the absense of a common model for all config, I believe this was a mistake. > Given the unique applicability of COPS-PR, PIBs should be defined > specifically for this purpose and only this purpose. On Bert's third point, > I would argue that the investment in PIBs is far smaller than he suggests. > Given the specific scope of applicability, PIBs would not be appropriate for > most IETF activities involving failure events or static config (routing, > transport and applications). Hence, the number of PIBs is relatively small. > Further, I do not believe that any of the alternatives on the table can meet > these requirements to the extent that COPS-PR can. > > I would agree with Juergen that what we have today is a hodge-podge of > protocols and mechanisms for configuration management and little incentive > for changing the situation. As such, I see two alternatives: > 1. We can use COPS-PR and restrict it specifically to the area that it > addresses most effectively: dynamic config management (at the network edge). > 2. We can block progress on all config drafts/standards to motivate a > solution to Juergen's larger issue of concerted participation in a single > and uniform set of standards. > > We could also block the advancement of COPS-PR. However, that prevents us > from addressing the dynamic config space and does not advance an > alternative. It also does nothing about the overall progress in the O&M area > that Juergen alluded to. This was in essence the point I was trying to make > in my earlier message to Randy. > > regards, > > -Walter > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Thursday, March 21, 2002 4:13 PM > > To: rap@ops.ietf.org > > Cc: diffserv@ietf.org; ipsec-policy@vpnc.org > > Subject: RE: why i should like pibs > > > > > > All, > > > > Let me post to these lists a similar statement as I made in the > > RAP WG meeting at this 53rd IETF, so that everyone has the same > > info. Here we go. I would prefer to have andy reactions (if any) > > posted to just one mailing list (the RAP wg mailing list). > > > > When the WG completed WG Last Call and reached consensus on > > the FRAMEWORK PIB, the WG chairs asked me (the primary AD > > for the WG) to consider this document for Proposed Standard. > > Normally I then review and ask for IETF wide Last Call and > > if no valid objections are received, then I put the document > > on the IESG agenda for approval. > > > > My current evaluation however for this document at this time > > is as follows: > > - If we look at the NM related activities, then we can see > > that for SNMP/MIBs, the majority of work/time/effort is > > spent in the MIB development. It also touches on virtually > > all WGs. Same will be true for COPS-PR/PIBs if we start to > > put PIBs on the standareds track. > > This could be a VERY BIG thing. In SNMP, the real investment > > is in MIBs. This is true for MIB design (IETF), for vendor > > implementation effort, and for user deployment. If IETF > > working groups start to develop PIBs they would be faced > > with significant extra, and in many cases, redundant effort > > - We have accepted COPS and COPS-PR 2-3 years ago as PS. > > That was the start of a duplicate approach, which only > > provides marginal improvement in some areas, and possibly > > a negative effect in some other areas. > > - We have also accepted SPPI as a duplicate approach, again > > with only marginal improvement. It allows to define PIBs, > > most of which I think can also be done with MIBs or > > better/different MIB design. > > - Note that PIBs are basically intended for configuring > > network devices and services. > > - Two years back, the ADs and Diffserv WG chairs agreed to do > > a MIB and a PIB for standards track. And we agreed with the > > RAP WG to develop a set of base PIBs for standards track. > > - Meanwhile, we have seen: > > - Some key players withdrew from COPS and PIBs approach > > They claim there is no market, and with reduced budgets > > there is no place to just do multiple solutions to same > > address space. > > - In most cases, PIB development is done by different people > > than MIB development, if we're lucky they talk to each other. > > - WGs in general have very little interest in MIBs or in PIBs, > > let alone both. > > - Operators (ISPs) tell us they do not see much use for binary > > interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to > > configure their network devices/services. The reality is that > > they use (and expect to have to continue to use) ASCII based > > CLI-type interfaces (Maybe ASCII should read human readable) > > - We have started an effort to try and consolidate SMI and SPPI > > We may want to await the results before we invest in the > > standardization of PIBs. > > - The NM community in the IETF (lots of SNMP folk, but COPS, > > Policy WG and Operators are participating too) are trying to > > come up with some vision/framework to address Operator (ISP) > > concerns. Discussions is only in beginning stages and not any > > IETF sanctioned status yet. > > - IAB is planning a NM Architecture Workshop this summer (as > > announced at the IAB plenary on Wednesday March 20th) > > - We (the IETF/IESG) are to decide on the first IETF produced PIBs. > > If we approve them as standards track, then: > > - I suspect we will find a lot of duplicate work, i.e. MIBs and > > PIBs, to be designed, tested, handled-for-stds-track approval > > - Vendors and users may be faced with the big duplicate investment. > > They can opt to not do so, but of course the more PIBs we approve > > as stds track, the more the pressure will be put on them. > > - We are telling the market that we cannot decide and let them do it. > > Maybe this is OK. But not in my mind, I do not think we do the > > IETF community or the world a favor by approving this duplicate > > approach > > > > As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB > > (or any PIBs for that matter) on the standards track at this point > > in time. I strongly recommend to publish them as Informational for > > now. We can revisit this after we get some better architectural > > guidelines/help from the current actitivities that are taking > > place in informal gatherings and the upcoming IAB NM Workshop. > > > > I understand that this is sort of "breaking the contract" with > > the RAP WG on my part. But the situation has changed quite a bit > > from 2 years ago when we started down this path (agreed on the WG > > charter). > > > > Bert > > > From owner-ipsec-policy@mail.vpnc.org Wed Mar 27 19:13:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00409 for ; Wed, 27 Mar 2002 19:13:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2RNWCd13270 for ipsec-policy-bks; Wed, 27 Mar 2002 15:32:12 -0800 (PST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2RNWCm13266 for ; Wed, 27 Mar 2002 15:32:12 -0800 (PST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-237.cisco.com [10.82.240.237]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA27533; Wed, 27 Mar 2002 15:31:35 -0800 (PST) Message-Id: <4.3.2.7.2.20020327164457.019cd2a8@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Mar 2002 18:26:34 -0500 To: "Walter Weiss" From: John Schnizlein Subject: Re: [Diffserv] Re: why i should like pibs Cc: , "DiffServ2" , In-Reply-To: <007601c1d510$48304300$650a0a0a@ne.client2.attbi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems time again for me to summarize my concern about COPS-PR and PIBs. The intensity of feeling, apparent in the Plenary, that the ADs have done other than what we expect of them both motivates me to repeat what was ignored some time ago in Policy Framework interim meetings and makes me recall that the little boy who said what he saw in the Emperor's New Clothes" fared poorly. The fundamental problem with distributing policy to traffic-forwarding devices rather than translating policy into configurations under the constraints of the composition (topology) and capabilities of the devices in the path of the traffic remains. It is essentially wishful thinking that individual devices can determine the correct configuration of their local parameters without the domain-wide information. I have not been persuaded that the capability-exchange between the PEP and PDP solves this problem. There are hints of importance of the domain-wide context in DiffServ's per-domain behavior (PDB) specifications. It is even a mistake IMHO to invite network administrators to establish policies their networks cannot deliver. Although consensus was never reached on the architecture for policy networking, the insistence that policy be independent of the devices and topology that started there seems to persist under the surface of the COPS-PR development. My concerns about distributing un-interpreted policy appears to be shared by the network operators who shared their view with people soliciting "requirements for network configuration" when they say they do not want policy, or even configuration, distributed to devices until they know what it will do to the network. Response to particular points: At 04:50 PM 3/26/2002, Walter Weiss wrote: >... First of all, the pervasive perspective that there is only one >operations organization is very misleading. ... Therefore, drawing >conclusions about the value of COPS or PIBS to operators is premature. Good point. Standardizing without expected value is not the IETF way. >I would also like to consider this issue from a requirements perspective. In >my view, we can divide operational needs into four areas: Stats Collection, >Events, Static config and Dynamic config. This taxonomy of operational needs for network management is novel. Instead of the 5 FCAPS categories, it creates 4, with a new distinction in configuration that may or may not have value. It also seems that this Dynamic Config has a lot in common with what has been supported in RADIUS as user profiles. Why is this not better treated as a QoS case of authorization? >I would also like to reconsider Bert's points. First, I would agree that the >level of interest in COPS-PR is relatively small. However, I would argue >that this is because Dynamic Config is only starting to become important as >mappings for QoS, Security, and Tunneling are coming to the forefront. Maybe we should see if this new category of Dynamic Config really develops before standardizing it into existence. >Second, I disagree that there is overlap with PIBs. While the DiffServ PIB >and MIB are nearly identical, this was done because it was assumed that they >were both addressing the config space that CLI is so clearly dominating. In >the absense of a common model for all config, I believe this was a mistake. Don't follow this. You think any correspondence in the data models for the DiffServ application is a mistake without a "common model for all config"? Wouldn't incremental steps be more practical? >Given the unique applicability of COPS-PR, PIBs should be defined >specifically for this purpose and only this purpose. Which unique applicability of COPS-PR is this? The newly proposed Dynamic Config? >On Bert's third point, >I would argue that the investment in PIBs is far smaller than he suggests. >Given the specific scope of applicability, PIBs would not be appropriate for >most IETF activities involving failure events or static config (routing, >transport and applications). Hence, the number of PIBs is relatively small. >Further, I do not believe that any of the alternatives on the table can meet >these requirements to the extent that COPS-PR can. > >I would agree with Juergen that what we have today is a hodge-podge of >protocols and mechanisms for configuration management and little incentive >for changing the situation. As such, I see two alternatives: >1. We can use COPS-PR and restrict it specifically to the area that it >addresses most effectively: dynamic config management (at the network edge). >2. We can block progress on all config drafts/standards to motivate a >solution to Juergen's larger issue of concerted participation in a single >and uniform set of standards. No one has proposed to "block progress on all config drafts/standards" up until this point. Way back in the Configuration Management BOF in Washington, I thought Bert supported Experimental status as the best way to explore the new ideas proposed with COPS-PR and PIBs. >We could also block the advancement of COPS-PR. However, that prevents us >from addressing the dynamic config space and does not advance an >alternative. Bert's original suggestion of Experimental seems again the best way to encourage use of the new ideas in COPS-PR. I have never seen him (or Randy, for that matter) try to "block advancement". John