From owner-rap@ops.ietf.org Wed Jan 2 07:48:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03114 for ; Wed, 2 Jan 2002 07:48:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Lkmi-000FRW-00 for rap-data@psg.com; Wed, 02 Jan 2002 04:46:20 -0800 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.33 #1) id 16Lkmh-000FRQ-00 for rap@ops.ietf.org; Wed, 02 Jan 2002 04:46:19 -0800 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g02CjYw09874 for ; Wed, 2 Jan 2002 18:15:35 +0530 (IST) Received: from kapoor ([192.168.143.131]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GPBA4Y00.KQ1; Wed, 2 Jan 2002 18:16:10 +0530 Message-ID: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net> From: "Saurabh kapoor" To: Cc: "Nampelli Sreenivasu " , "Attili Venkata Ravi Kishore" , "V V V Satya Naganna" , "Krishna Prasad Akkineni" References: <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1> Subject: Re: draft-ietf-rap-frameworkpib-06 Date: Wed, 2 Jan 2002 18:21:33 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-7a5d322d-ff5f-11d5-84a5-0000e2293f7c" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2436.0001 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2436.0001 Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-7a5d322d-ff5f-11d5-84a5-0000e2293f7c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The qosAssuredRateAbs parameter of the qosAssuredRate table specifies the minimum absolute rate, in kbps that a downstream scheduler element should allocate to the queue. This attributes value is coupled to that of qosAssuredRateRel : changes to one will affect the value of other. They are related to each other by the equation : RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000 My question is how does the PDP get the value of 'ifSpeed'? Does the PEP specify the value? If yes, then in which PIb is the value found ? Regards, Saurabh Kapoor ---------------------------------------------------------------------------- ---------- ------=_NextPartTM-000-7a5d322d-ff5f-11d5-84a5-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com ------=_NextPartTM-000-7a5d322d-ff5f-11d5-84a5-0000e2293f7c-- From owner-rap@ops.ietf.org Thu Jan 3 14:46:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09552 for ; Thu, 3 Jan 2002 14:46:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MDn6-000L59-00 for rap-data@psg.com; Thu, 03 Jan 2002 11:44:40 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 16MDn5-000L52-00 for rap@ops.ietf.org; Thu, 03 Jan 2002 11:44:39 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03Jiao15708 for ; Thu, 3 Jan 2002 14:44:36 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03JiZU15965 for ; Thu, 3 Jan 2002 14:44:35 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Z2XFT71T; Thu, 3 Jan 2002 14:42:55 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CFLQ1Z2X; Thu, 3 Jan 2002 14:42:53 -0500 Message-Id: <5.0.0.25.0.20020103143530.02481720@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 03 Jan 2002 14:44:27 -0500 To: rap@ops.ietf.org From: Kwok Ho Chan Subject: UMTS PIB 3GPP reference doc links Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_19328366==_.ALT" Sender: owner-rap@ops.ietf.org Precedence: bulk --=====================_19328366==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed There was a request for info on 3GPP documents used by http://www.ietf.org/internet-drafts/draft-hamer-rap-cops-umts-go-00.txt For convenience, their links are: ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23002-540.zip ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23207-510.zip ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23228-520.zip ftp://ftp.3gpp.org/Spec/Latest_drafts/29207-020.zip These links are also provided in the Reference section of the draft. -- Kwok -- --=====================_19328366==_.ALT Content-Type: text/html; charset="us-ascii" There was a request for info on 3GPP documents used by
http://www.ietf.org/internet-drafts/draft-hamer-rap-cops-umts-go-00.txt

For convenience, their links are:
ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23002-540.zip
ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23207-510.zip
ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23228-520.zip
ftp://ftp.3gpp.org/Spec/Latest_drafts/29207-020.zip

These links are also provided in the Reference section of the draft.
-- Kwok --


--=====================_19328366==_.ALT-- From owner-rap@ops.ietf.org Fri Jan 4 05:08:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00060 for ; Fri, 4 Jan 2002 05:08:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MRGH-000ETu-00 for rap-data@psg.com; Fri, 04 Jan 2002 02:07:41 -0800 Received: from mel.alcatel.fr ([212.208.74.132]) by psg.com with esmtp (Exim 3.33 #1) id 16MRGG-000ETn-00 for rap@ops.ietf.org; Fri, 04 Jan 2002 02:07:40 -0800 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET) with ESMTP id g04A7cVc021776 for ; Fri, 4 Jan 2002 11:07:38 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA24297 for ; Fri, 4 Jan 2002 11:06:26 +0100 (MET) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id LAA09564 for ; Fri, 4 Jan 2002 11:06:52 +0100 (MET) Received: from athos.dinsunnet (athos [188.9.12.98]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id LAA13705 for ; Fri, 4 Jan 2002 11:06:53 +0100 (MET) Received: from p50669 by athos.dinsunnet (8.9.1b+Sun/SMI-SVR4) id LAA26795; Fri, 4 Jan 2002 11:07:48 +0100 (MET) Message-ID: <00a401c19507$5f36a150$caf609bc@p50669> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: References: <5.0.0.25.0.20020103143530.02481720@zbl6c002.corpeast.baynetworks.com> Subject: what about the SLC minutes ? Date: Fri, 4 Jan 2002 11:05:43 +0100 Organization: Alcatel R&I 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit thanx -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Marcoussis, France Tel +33 1 6963 4187 Fax +33 1 6963 1169 yacine.el_mghazli@alcatel.fr ---------------------------------------------------------------------- From owner-rap@ops.ietf.org Fri Jan 4 11:44:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08157 for ; Fri, 4 Jan 2002 11:44:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MXRR-000Nwo-00 for rap-data@psg.com; Fri, 04 Jan 2002 08:43:37 -0800 Received: from [192.55.52.18] (helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16MXRQ-000Nwb-00 for rap@ops.ietf.org; Fri, 04 Jan 2002 08:43:36 -0800 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.28 2002/01/02 21:40:45 root Exp $) with ESMTP id g04GhKM08707 for ; Fri, 4 Jan 2002 16:43:20 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.11 2001/11/09 23:28:01 root Exp $) with SMTP id g04GhOv22679 for ; Fri, 4 Jan 2002 16:43:24 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002010408430505312 ; Fri, 04 Jan 2002 08:43:05 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 08:43:34 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F01D02677@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Chapman, Ken'" Cc: "'rap@ops.ietf.org'" Subject: RE: draft-ietf-rap-frameworkpib-06 Date: Fri, 4 Jan 2002 08:43:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Yes, thanks for the correction, this will be updated in the updated document. Ravi -----Original Message----- From: Chapman, Ken [mailto:KChapman@unispherenetworks.com] Sent: Monday, December 31, 2001 1:03 PM To: 'rap@ops.ietf.org' Subject: draft-ietf-rap-frameworkpib-06 Hi, I am new to this list, so I apologize if this has already been reported. In the FRAMEWORK-TC-PIB (section 3), the Role and RoleCombination TEXTUAL-CONVENTIONs are defined using SnmpAdminString, which is also a TEXTUAL-CONVENTION (imported from SNMP-FRAMEWORK-MIB. This is not allowed in SPPI (RFC3159): "11.1.2. Mapping of the SYNTAX clause The SYNTAX clause, which must be present, defines abstract data structure corresponding to the textual convention. The data structure must be one of the following: a base type (see the SYNTAX clause of an OBJECT-TYPE macro), or the BITS construct. Note that this means that the SYNTAX clause of a Textual Convention can not refer to a previously defined Textual Convention." Happy New Year, Ken ++++++++++++++++++++++++++++++++++++++++++++++ Ken Chapman Unisphere Networks, Inc. M/S 2380 Tel: +1 978 589 0288 10 Technology Park Drive Fax: +1 978 589 0800 Westford, MA 01886 Email: KChapman@UnisphereNetworks.com ++++++++++++++++++++++++++++++++++++++++++++++ From owner-rap@ops.ietf.org Fri Jan 4 11:51:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08314 for ; Fri, 4 Jan 2002 11:51:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MXVl-000O5E-00 for rap-data@psg.com; Fri, 04 Jan 2002 08:48:05 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16MXVk-000O57-00 for rap@ops.ietf.org; Fri, 04 Jan 2002 08:48:04 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id QAA21978 for ; Fri, 4 Jan 2002 16:48:03 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002010408495319058 ; Fri, 04 Jan 2002 08:49:53 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 08:48:02 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F01D02678@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Muralidhar S'" , "'rap@ops.ietf.org'" Subject: RE: COPS Request State Date: Fri, 4 Jan 2002 08:48:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Murali, You are correct, the entire request state for a PEP consists of its incarnation, prc support info, component limitations, capability sets and ifRoleCombo assignments. when required, the PEP needs to send these for all the request handles that exist on the PEP. Ravi -----Original Message----- From: Muralidhar S [mailto:mdhara@WSSPL.com] Sent: Thursday, December 27, 2001 8:28 PM To: 'rap@ops.ietf.org' Subject: RE: COPS Request State Hi, Client Handle anyway will be part of the COPS-PR REQ message. I think as part of the Request State, PEP needs to send some more details. Section 2.3.1 from "draft-ietf-rap-frameworkpib-06.txt" is mentioned below. "2.3.1 Full Request State When the PEP wants to send the entire request state to the PDP (for example, in response to a Synchronize State Request from the PDP), the PEP MUST send the incarnation instance with the frwkPibIncarnationFullState attribute set to TRUE. " But we are not clear as what "the entire request state" is made of? Will it contain updated Role-Combination/Capabilities/Limitations etc? Regards murali > -----Original Message----- > From: ??? [mailto:bjlee@etri.re.kr] > Sent: 2001. December 28. 5:47 > To: Muralidhar S > Subject: Re: COPS Request State > > > I Think that all the request state means the set of > all the client-handle that PEP has. > > regards, > > ----- Original Message ----- > From: "Muralidhar S" > To: > Sent: Thursday, December 27, 2001 2:27 PM > Subject: COPS Request State > > > > All, > > > > We are working on a SDK for PDP and PEP development. As > part of this, we > > have > > some questions on the cops request state. As part of the > SSQ message from > > PDP, PEP > > sends "all the Request State" for that particular client > handle. Can someone > > let me know > > what does it means when we say "all the Request State"? > Does PEP needs to > > send > > all the Policy Decisions ( PRID, EPD ) that PDP has installed? > > > > Thanks > > murali > > ______________________ > > WebSpectrum Software Pvt. Ltd, > > Jayanagar, Bangalore - 560082 > > www.wsspl.com > > ______________________ > > > > > From owner-rap@ops.ietf.org Fri Jan 18 10:23:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14431 for ; Fri, 18 Jan 2002 10:23:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RalQ-000B8Q-00 for rap-data@psg.com; Fri, 18 Jan 2002 07:17:08 -0800 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 16RalP-000B8K-00 for rap@ops.ietf.org; Fri, 18 Jan 2002 07:17:07 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0IFH2s24336 for ; Fri, 18 Jan 2002 10:17:02 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Jan 2002 16:17:01 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E55A62D@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'rap@ops.ietf.org'" Cc: Randy Bush Subject: Charter questions Date: Fri, 18 Jan 2002 16:17:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Dear RAP WG, Various people are asking me what the RAP WG is doing and if it is staying with in its (intended) WG charter. The questions are of the type of: - draft-ietf-rap-frameworkpib-06 the thought of yet another accounting protocol does raise serious questions. - draft-ietf-rap-access-bind-00.txt, which *is* in fact a whole new AAA protocol, under the guise of a COPS extension. - it looks to me like COPS is being proposed as a AAA protocol for network access -- including 802.11, Dialup, and even Mobile IP, as well as SIP and possibly a few other things. That pretty much covers the scope of AAA usage. As you can imagine, these type of comments come from the AAA side of the house. Now... in the RAP WG charter, I do read: For the work on the [FEEDBACKFWRK] and [FEEDBACKPIB], the WG will work with other WGs (like AAA WG) to prevent duplication and overlapping solutions. So what kind of action has the WG taken or WILL the WG take in order to make sure that we do not overlap or compete in this space? Thanks, Bert Wijnen (explicitly speaking as AD) From owner-rap@ops.ietf.org Fri Jan 18 19:09:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01349 for ; Fri, 18 Jan 2002 19:09:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RixC-000Lwl-00 for rap-data@psg.com; Fri, 18 Jan 2002 16:01:50 -0800 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16RixB-000Lwc-00 for rap@ops.ietf.org; Fri, 18 Jan 2002 16:01:49 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id AAA27264 for ; Sat, 19 Jan 2002 00:01:48 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011816035616424 ; Fri, 18 Jan 2002 16:03:56 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 16:01:48 -0800 Message-ID: From: "Kulkarni, Amol" To: "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'" Cc: "'Randy Bush'" Subject: RE: Charter questions Date: Fri, 18 Jan 2002 16:01:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Bert, I assume you meant draft-ietf-rap-feedback-fr-pib-01 when you wrote draft-ietf-rap-frameworkpib-06. The [FEEDBACKFWRK] and [FEEDBACKPIB] DO NOT define a new accounting protocol. They are simply a tool for providing feedback on provisioned policy usage so that future policies may be 'tweaked' for better performance. As such they fall within the purview of COPS-PR and PIBS; and just clarify certain points regarding feedback which are ALREADY PRESENT in COPS-PR. Also, there is an extra link on the RAP page which points to an old draft. The latest drafts can be found here: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-01.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-01.txt Thanks, Amol -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, January 18, 2002 7:17 AM To: 'rap@ops.ietf.org' Cc: Randy Bush Subject: Charter questions Dear RAP WG, Various people are asking me what the RAP WG is doing and if it is staying with in its (intended) WG charter. The questions are of the type of: - draft-ietf-rap-frameworkpib-06 the thought of yet another accounting protocol does raise serious questions. - draft-ietf-rap-access-bind-00.txt, which *is* in fact a whole new AAA protocol, under the guise of a COPS extension. - it looks to me like COPS is being proposed as a AAA protocol for network access -- including 802.11, Dialup, and even Mobile IP, as well as SIP and possibly a few other things. That pretty much covers the scope of AAA usage. As you can imagine, these type of comments come from the AAA side of the house. Now... in the RAP WG charter, I do read: For the work on the [FEEDBACKFWRK] and [FEEDBACKPIB], the WG will work with other WGs (like AAA WG) to prevent duplication and overlapping solutions. So what kind of action has the WG taken or WILL the WG take in order to make sure that we do not overlap or compete in this space? Thanks, Bert Wijnen (explicitly speaking as AD) From owner-rap@ops.ietf.org Fri Jan 18 19:20:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01593 for ; Fri, 18 Jan 2002 19:20:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RjCY-000MGr-00 for rap-data@psg.com; Fri, 18 Jan 2002 16:17:42 -0800 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 16RjCX-000MGk-00 for rap@ops.ietf.org; Fri, 18 Jan 2002 16:17:41 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0J0Hd009595 for ; Fri, 18 Jan 2002 19:17:39 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 19 Jan 2002 01:17:38 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E55A6F1@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Kulkarni, Amol" , "'rap@ops.ietf.org'" Cc: "'Randy Bush'" Subject: RE: Charter questions Date: Sat, 19 Jan 2002 01:17:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Appology. I meant draft-ietf-rap-acct-fr-pib-01.txt instead of draft-ietf-rap-frameworkpib-06 Cut and paste error. That framework-pib doc was one that I had in my ciut and paste buffer too.... Guess why? Bert > -----Original Message----- > From: Kulkarni, Amol [mailto:amol.kulkarni@intel.com] > Sent: Saturday, January 19, 2002 1:02 AM > To: 'Wijnen, Bert (Bert)'; 'rap@ops.ietf.org' > Cc: 'Randy Bush' > Subject: RE: Charter questions > > > > Bert, > > I assume you meant draft-ietf-rap-feedback-fr-pib-01 when you wrote > draft-ietf-rap-frameworkpib-06. > > The [FEEDBACKFWRK] and [FEEDBACKPIB] DO NOT define a new accounting > protocol. They are simply a tool for providing feedback on provisioned > policy usage so that future policies may be 'tweaked' for better > performance. As such they fall within the purview of COPS-PR > and PIBS; and > just clarify certain points regarding feedback which are > ALREADY PRESENT in > COPS-PR. > > Also, there is an extra link on the RAP page which points to > an old draft. > The latest drafts can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr wk-01.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-01.txt Thanks, Amol -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, January 18, 2002 7:17 AM To: 'rap@ops.ietf.org' Cc: Randy Bush Subject: Charter questions Dear RAP WG, Various people are asking me what the RAP WG is doing and if it is staying with in its (intended) WG charter. The questions are of the type of: - draft-ietf-rap-frameworkpib-06 the thought of yet another accounting protocol does raise serious questions. - draft-ietf-rap-access-bind-00.txt, which *is* in fact a whole new AAA protocol, under the guise of a COPS extension. - it looks to me like COPS is being proposed as a AAA protocol for network access -- including 802.11, Dialup, and even Mobile IP, as well as SIP and possibly a few other things. That pretty much covers the scope of AAA usage. As you can imagine, these type of comments come from the AAA side of the house. Now... in the RAP WG charter, I do read: For the work on the [FEEDBACKFWRK] and [FEEDBACKPIB], the WG will work with other WGs (like AAA WG) to prevent duplication and overlapping solutions. So what kind of action has the WG taken or WILL the WG take in order to make sure that we do not overlap or compete in this space? Thanks, Bert Wijnen (explicitly speaking as AD) From owner-rap@ops.ietf.org Sat Jan 19 17:19:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23491 for ; Sat, 19 Jan 2002 17:19:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16S3jk-000NtE-00 for rap-data@psg.com; Sat, 19 Jan 2002 14:13:20 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16S3jj-000Nt6-00 for rap@ops.ietf.org; Sat, 19 Jan 2002 14:13:19 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id WAA02638 for ; Sat, 19 Jan 2002 22:13:17 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011914152708562 ; Sat, 19 Jan 2002 14:15:27 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 19 Jan 2002 14:13:17 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DD29@FMSMSX34> From: "Durham, David" To: "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'" Cc: "'Randy Bush'" Subject: RE: Charter questions Date: Sat, 19 Jan 2002 14:13:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Bert, I took another look at the access-bind PIB and I disagree with your assertion. The whole point of that work is about binding all those diverse signaling protocols so they may work together AND the required device resources may be properly allocated in a coordinated fashion. That certainly seems a good thing to do and within the charter of a resource allocation protocol. I hardly see how a network can work without giving some semblance as to how these many diverse signaling mechanisms (RSVP, RSVP-TE, SIP, etc.) can work together given limited and already partially provisioned network resources. Their approach in the Access-Bind PIB seems to me to be an elegant way to deal with this complex problem. -Dave > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, January 18, 2002 4:18 PM > To: Kulkarni, Amol; 'rap@ops.ietf.org' > Cc: 'Randy Bush' > Subject: RE: Charter questions > > Appology. I meant draft-ietf-rap-acct-fr-pib-01.txt > instead of draft-ietf-rap-frameworkpib-06 > > Cut and paste error. That framework-pib doc was one that > I had in my ciut and paste buffer too.... Guess why? > > Bert > > > -----Original Message----- > > From: Kulkarni, Amol [mailto:amol.kulkarni@intel.com] > > Sent: Saturday, January 19, 2002 1:02 AM > > To: 'Wijnen, Bert (Bert)'; 'rap@ops.ietf.org' > > Cc: 'Randy Bush' > > Subject: RE: Charter questions > > > > > > > > Bert, > > > > I assume you meant draft-ietf-rap-feedback-fr-pib-01 when you wrote > > draft-ietf-rap-frameworkpib-06. > > > > The [FEEDBACKFWRK] and [FEEDBACKPIB] DO NOT define a new accounting > > protocol. They are simply a tool for providing feedback on provisioned > > policy usage so that future policies may be 'tweaked' for better > > performance. As such they fall within the purview of COPS-PR > > and PIBS; and > > just clarify certain points regarding feedback which are > > ALREADY PRESENT in > > COPS-PR. > > > > Also, there is an extra link on the RAP page which points to > > an old draft. > > The latest drafts can be found here: > > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr > wk-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-01.txt > > Thanks, > Amol > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, January 18, 2002 7:17 AM > To: 'rap@ops.ietf.org' > Cc: Randy Bush > Subject: Charter questions > > Dear RAP WG, > > Various people are asking me what the RAP WG is doing and > if it is staying with in its (intended) WG charter. > > The questions are of the type of: > > - draft-ietf-rap-frameworkpib-06 > the thought of yet another accounting protocol does > raise serious questions. > > - draft-ietf-rap-access-bind-00.txt, > which *is* in fact a whole new AAA protocol, > under the guise of a COPS extension. > > - it looks to me like COPS is being proposed as a AAA > protocol for network access -- including 802.11, > Dialup, and even Mobile IP, as well as SIP and possibly > a few other things. That pretty much covers the scope > of AAA usage. > > As you can imagine, these type of comments come from the > AAA side of the house. > > Now... in the RAP WG charter, I do read: > > For the work on the [FEEDBACKFWRK] and [FEEDBACKPIB], > the WG will work with other WGs (like AAA WG) to prevent > duplication and overlapping solutions. > > So what kind of action has the WG taken or WILL the WG take > in order to make sure that we do not overlap or compete > in this space? > > Thanks, > Bert Wijnen > (explicitly speaking as AD) From owner-rap@ops.ietf.org Sun Jan 20 06:58:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09327 for ; Sun, 20 Jan 2002 06:58:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16SGaL-0008wF-00 for rap-data@psg.com; Sun, 20 Jan 2002 03:56:29 -0800 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 16SGaH-0008w7-00 for rap@ops.ietf.org; Sun, 20 Jan 2002 03:56:29 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0KBuMd00673 for ; Sun, 20 Jan 2002 06:56:23 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 20 Jan 2002 12:56:21 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E55A761@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Durham, David" , "'rap@ops.ietf.org'" Cc: "'Randy Bush'" , Bernard Aboba , "'David Mitton'" Subject: RE: Charter questions Date: Sun, 20 Jan 2002 12:56:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk I have added the two AAA WG chairs. Bernard/David, do you want the type of discussion on the AAA mailing list as I suggest below, or would you rather direct some of the AAA paritipants to the RAP WG mailing list? Dave Durham writes: > Hi Bert, > > I took another look at the access-bind PIB and I disagree with your > assertion. > Pls.. read my posting again. I did not make any assertion yet. I reported what type of questions were/are coming my way. and I do notice that we have an explicit statement in teh charter that tells us to interact with AAA WG about these types of matters. So I was asking: So what kind of action has the WG taken or WILL the WG take in order to make sure that we do not overlap or compete in this space? And so it seems that you do not agree with the allegations that seem implicit in the questions that are getting to me. And so it seems that there is a NEED to interact with the AAA WG to see where both WGs stand and how they understand each others work. So a way to start a discussion with the AAA WG chairs, or on the AAA WG list and use the following text as a way to start discussion as to the matter of overlap/conflict of work. > The whole point of that work is about binding all those > diverse signaling protocols so they may work together AND > the required device resources may be properly allocated in > a coordinated fashion. That certainly seems a good thing to > do and within the charter of a resource allocation protocol. > > I hardly see how a network can work without giving some > semblance as to how these many diverse signaling mechanisms > (RSVP, RSVP-TE, SIP, etc.) can work together given limited > and already partially provisioned network resources. > Their approach in the Access-Bind PIB seems to me to be an > elegant way to deal with this complex problem. > > -Dave > Bert From owner-rap@ops.ietf.org Sun Jan 20 12:23:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13666 for ; Sun, 20 Jan 2002 12:23:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16SLfe-000Cz3-00 for rap-data@psg.com; Sun, 20 Jan 2002 09:22:18 -0800 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com) by psg.com with esmtp (Exim 3.33 #1) id 16SLfe-000Cyw-00; Sun, 20 Jan 2002 09:22:18 -0800 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id MAA01430; Sun, 20 Jan 2002 12:31:21 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma001428; Sun, 20 Jan 02 12:30:24 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jan 2002 12:20:35 -0500 Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA07E7@corp-exc3.ctron.com> From: "Harrington, David" To: "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" Cc: "'Randy Bush'" , Bernard Aboba , "'David Mitton'" Subject: RE: Charter questions Date: Sun, 20 Jan 2002 12:20:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A1D6.C2552DC0" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A1D6.C2552DC0 Content-Type: text/plain Hi, I was going to just sit on the sidelines on this issue, but one of buttons has just been pushed. I am an SNMP bigot, and I strongly resent that COPS has repeatedly encroached on the functionality that is the purpose of SNMP, while the IESG repeatedly prevented the SNMP community from doing anything other than security, which COPS wasn't required to address. I have felt that COPS has been trying to sell itself as the solution for everything, and that the WG has continually expanded into new areas that really required a stretch of the charter. As part of their sales strategy they have repeatedly attacked SNMP. Obviously, I am not a great lover of how many members of the RAP WG have behaved. However, I find it interesting to have the AAA WG raise issues about COPS moving into areas that might overlap with the charter of other WGs. I find it particularly galling to have it suggested that RAP has not worked to integrate with other WGs, and implicitly indicating that AAA has been so willing. I used to attend and contribute to the AAA WG effort until it became extremely clear that AAA had absolutely no interest (see the footnote) in developing an architecture that could allow for the integration of AAA and COPS and SNMP. Both the COPS community and the SNMP communities presented possible alternatives for accounting, pointed out the importance of trying to better integrate the data models of the various protocols, and requested that the architecture allow for the use of other protocols to provide certain types of functionality. The AAA WG decided to develop an architecture that explicitly excluded the possibility of using any other protocol to provide accounting capability, did little to integrate the data models, and does not allow users to determine which protocol or protocols to use to gather accounting information. AAA insisted on reinventing the wheel, overlapping the work already being done by other WGs. So while I agree that the RAP WG seems to continually push the limits of the charter rather than concentrating on their core deliverables, I feel it is unfair to ignore their efforts to integrate with the work of other WGs, especially the AAA WG. dbh footnote: The AAA WG actually was a bit more open-minded than this appears. A significant minority believed that work should be done to integrate with other protocols, or at least the scope of possible integration should be studied further. However, they were boxed in by the actions of their area director, Randy Bush, when he took over the control of a meeting from the chairs, and forced a vote on a question that was phrased in a highly prejudicial way, to adopt an approach that precluded such integration. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Sunday, January 20, 2002 6:56 AM > To: Durham, David; 'rap@ops.ietf.org' > Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' > Subject: RE: Charter questions > > > I have added the two AAA WG chairs. > Bernard/David, do you want the type of discussion on the > AAA mailing list as I suggest below, or would you rather > direct some of the AAA paritipants to the RAP WG mailing > list? > > Dave Durham writes: > > Hi Bert, > > > > I took another look at the access-bind PIB and I disagree with your > > assertion. > > > Pls.. read my posting again. I did not make any assertion yet. > I reported what type of questions were/are coming my way. > and I do notice that we have an explicit statement in teh charter > that tells us to interact with AAA WG about these types of matters. > > So I was asking: > > So what kind of action has the WG taken or WILL the WG take > in order to make sure that we do not overlap or compete > in this space? > > And so it seems that you do not agree with the allegations that > seem implicit in the questions that are getting to me. And so > it seems that there is a NEED to interact with the AAA WG to > see where both WGs stand and how they understand each others > work. > > So a way to start a discussion with the AAA WG chairs, or > on the AAA WG list and use the following text as a way to start > discussion as to the matter of overlap/conflict of work. > > > The whole point of that work is about binding all those > > diverse signaling protocols so they may work together AND > > the required device resources may be properly allocated in > > a coordinated fashion. That certainly seems a good thing to > > do and within the charter of a resource allocation protocol. > > > > I hardly see how a network can work without giving some > > semblance as to how these many diverse signaling mechanisms > > (RSVP, RSVP-TE, SIP, etc.) can work together given limited > > and already partially provisioned network resources. > > Their approach in the Access-Bind PIB seems to me to be an > > elegant way to deal with this complex problem. > > > > -Dave > > > Bert > ------_=_NextPart_001_01C1A1D6.C2552DC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Charter questions

Hi,

I was going to just sit on the sidelines on this = issue, but one of buttons has just been pushed.

I am an SNMP bigot, and I strongly resent that COPS = has repeatedly encroached on the functionality that is the purpose of = SNMP, while the IESG repeatedly prevented the SNMP community from doing = anything other than security, which COPS wasn't required to address. I = have felt that COPS has been trying to sell itself as the solution for = everything, and that the WG has continually expanded into new areas = that really required a stretch of the charter. As part of their sales = strategy they have repeatedly attacked SNMP. Obviously, I am not a = great lover of how many members of the RAP WG have behaved.

However, I find it interesting to have the AAA WG = raise issues about COPS moving into areas that might overlap with the = charter of other WGs. I find it particularly galling to have it = suggested that RAP has not worked to integrate with other WGs, and = implicitly indicating that AAA has been so willing.

I used to attend and contribute to the AAA WG effort = until it became extremely clear that AAA had absolutely no interest = (see the footnote) in developing an architecture that could allow for = the integration of AAA and COPS and SNMP. Both the COPS community and = the SNMP communities presented possible alternatives for accounting, = pointed out the importance of trying to better integrate the data = models of the various protocols, and requested that the architecture = allow for the use of other protocols to provide certain types of = functionality. The AAA WG decided to develop an architecture that = explicitly excluded the possibility of using any other protocol to = provide accounting capability, did little to integrate the data models, = and does not allow users to determine which protocol or protocols to = use to gather accounting information. AAA insisted on reinventing the = wheel, overlapping the work already being done by other WGs.

So while I agree that the RAP WG seems to continually = push the limits of the charter rather than concentrating on their core = deliverables, I feel it is unfair to ignore their efforts to integrate = with the work of other WGs, especially the AAA WG.

dbh

footnote: The AAA WG actually was a bit more = open-minded than this appears. A significant minority believed that = work should be done to integrate with other protocols, or at least the = scope of possible integration should be studied further. However, they = were boxed in by the actions of their area director, Randy Bush, when = he took over the control of a meeting from the chairs, and forced a = vote on a question that was phrased in a highly prejudicial way, to = adopt an approach that precluded such integration.


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Sunday, January 20, 2002 6:56 AM
> To: Durham, David; 'rap@ops.ietf.org'
> Cc: 'Randy Bush'; Bernard Aboba; 'David = Mitton'
> Subject: RE: Charter questions
>
>
> I have added the two AAA WG chairs.
> Bernard/David, do you want the type of = discussion on the
> AAA mailing list as I suggest below, or would = you rather
> direct some of the AAA paritipants to the RAP = WG mailing
> list?
>
> Dave Durham writes:
> > Hi Bert,
> >
> > I took another look at the access-bind PIB = and I disagree with your
> > assertion.
> >
> Pls.. read my posting again. I did not make any = assertion yet.
> I reported what type of questions were/are = coming my way.
> and I do notice that we have an explicit = statement in teh charter
> that tells us to interact with AAA WG about = these types of matters.
>
> So I was asking:
>
>  So what kind of action has the WG taken = or WILL the WG take
>  in order to make sure that we do not = overlap or compete
>  in this space?
>
> And so it seems that you do not agree with the = allegations that
> seem implicit in the questions that are getting = to me. And so
> it seems that there is a NEED to interact with = the AAA WG to
> see where both WGs stand and how they = understand each others
> work.
>
> So a way to start a discussion with the AAA WG = chairs, or    
> on the AAA WG list and use the following text = as a way to start
> discussion as to the matter of overlap/conflict = of work.
>
> > The whole point of that work is about = binding all those
> > diverse signaling protocols so they may = work together AND
> > the required device resources may be = properly allocated in
> > a coordinated fashion. That certainly = seems a good thing to
> > do and within the charter of a resource = allocation protocol.
> >
> > I hardly see how a network can work = without giving some
> > semblance as to how these many diverse = signaling mechanisms
> > (RSVP, RSVP-TE, SIP, etc.) can work = together given limited
> > and already partially provisioned network = resources.
> > Their approach in the Access-Bind PIB = seems to me to be an
> > elegant way to deal with this complex = problem.
> >
> > -Dave
> >
> Bert
>

------_=_NextPart_001_01C1A1D6.C2552DC0-- From owner-rap@ops.ietf.org Mon Jan 21 00:46:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22910 for ; Mon, 21 Jan 2002 00:46:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16SXF3-000Pz6-00 for rap-data@psg.com; Sun, 20 Jan 2002 21:43:37 -0800 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16SXF2-000Pyz-00 for rap@ops.ietf.org; Sun, 20 Jan 2002 21:43:37 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id FAA06488 for ; Mon, 21 Jan 2002 05:43:35 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012021454714933 for ; Sun, 20 Jan 2002 21:45:47 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jan 2002 21:43:35 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C0275EF44@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: "'rap@ops.ietf.org'" Subject: Response Request: COPS PIBs standardization due-diligence feedba ck Date: Sun, 20 Jan 2002 21:43:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Subject: Response Request: COPS PIBs standardization due-diligence feedback Greetings, Just a note to let you know the first of the COPS-PR PIBs are about to reach IETF RFC standards-track status. Before the IESG (The IETF's Internet Engineering Steering Group) makes their decision on how to proceed with PIB standardization, they are collecting feedback about who in the industry is interested in the COPS-PR PIBs. We would like to make sure your input will be considered as part of this due-diligence process. This can be done by sending Brian Carpenter , chair of the DiffServ WG, an email saying that you are interested in the COPS standards and COPS-PR PIBs (e.g. the Framework, DiffServ, IPSec, Access Control, or Accounting PIB). Thanks very much, -Scott Hahn RAP WG co-chair - From owner-rap@ops.ietf.org Mon Jan 21 16:59:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26358 for ; Mon, 21 Jan 2002 16:59:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16SmRp-000Hx7-00 for rap-data@psg.com; Mon, 21 Jan 2002 13:57:49 -0800 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by psg.com with esmtp (Exim 3.33 #1) id 16SmRo-000Hx0-00; Mon, 21 Jan 2002 13:57:48 -0800 Received: from 209-6-245-153.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com ([209.6.245.153] helo=rcn.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.33 #10) id 16SmRm-0001Rw-00; Mon, 21 Jan 2002 16:57:46 -0500 Message-ID: <3C4C8E21.B407EF80@rcn.com> Date: Mon, 21 Jan 2002 16:54:42 -0500 From: "Mark L. Stevens" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Harrington, David" CC: "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , Bernard Aboba , "'David Mitton'" Subject: Re: Charter questions References: <0BF8B32B723ED5119E0B0002A551748B01FA07E7@corp-exc3.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I do not see the encroachment David Harrington perceives. Instead, I see the RAP working group filling an unaddressed need. Historically, many people thought that COPS was a replacement to SNMP and with good reason. There were shortcomings, but that is not the real issue. The combination of SNMP and CLI are reasonable for static configuration management. The emphasis is on stability, but the IETF and the networking industry has steadily moved toward a network model consisting of a static core and a dynamic edge. We want the core of the network to be ultimately stable. The easiest way to accomplish stability is to configure the devices in the core and then leave them alone and many existing methods are sufficient to the task. At the same time we have the desire to provide and manage additional network services. A static network provides little opportunity of offer dynamic network services. So, edge devices are targeted as the prime location for introducing dynamism. The risk of any resulting instability affects fewer users when services are delivered and provisioned at edge devices. The definition of services remains somewhat static, but the usage of services is dynamic. There is nothing to keep us from using one set of tools to define services and another to manage and operate those services. COPS and the Access Bind framework addresses the problem of managing services a dynamic edge device. The Access Bind framework will enable applications to relate services to user or subscribers in real-time and without direct service provider involvement. The last thing you want to do when you begin offering special network services is to have to manually reconfigure your network devices. You want your subscribers and applications to accomplish this task. Services won't pay if the service provider or carrier has to get directly involved in the changes adds and deletes. Other existing approaches do not readily provide mechanisms to do so. Remember, the premise is to integrate QoS semantics and other service level behaviors at the edge in real-time and by service-level behavior I include RSVP and Diffserv as service-level behaviors. We tried to integrate COPS and SNMP and the AAA work using a common data model expressing users, policies, etc. A common data model may have obviated the need to take this approach, but the common data model approach did not progress to the point necessary to accomplish this goal and using COPS is the next best alternative. As David Harrington points out the most vocal AAA people argued that they were only making the RADIUS attribute space larger and not addressing the authorization problem space or service-level network behaviors. The result was to extend the RADIUS attribute space with a focus on identifying the session rather than dealing with the provisioning of services in real time. Considering the complexity of correlating service level behaviors with subscribers within edge devices, the trivial piece is defining the session. What is needed is service management. Extending COPS to provide for authorization is a trivial extension and uses existing protocols. As for pushing the limits of the charter, the RAP working group went through the process of re-chartering the working group last summer and the working group continues to work within its charter. "Harrington, David" wrote: > > > Hi, > > I was going to just sit on the sidelines on this issue, but one of > buttons has just been pushed. > > I am an SNMP bigot, and I strongly resent that COPS has repeatedly > encroached on the functionality that is the purpose of SNMP, while the > IESG repeatedly prevented the SNMP community from doing anything other > than security, which COPS wasn't required to address. I have felt that > COPS has been trying to sell itself as the solution for everything, > and that the WG has continually expanded into new areas that really > required a stretch of the charter. As part of their sales strategy > they have repeatedly attacked SNMP. Obviously, I am not a great lover > of how many members of the RAP WG have behaved. > > However, I find it interesting to have the AAA WG raise issues about > COPS moving into areas that might overlap with the charter of other > WGs. I find it particularly galling to have it suggested that RAP has > not worked to integrate with other WGs, and implicitly indicating that > AAA has been so willing. > > I used to attend and contribute to the AAA WG effort until it became > extremely clear that AAA had absolutely no interest (see the footnote) > in developing an architecture that could allow for the integration of > AAA and COPS and SNMP. Both the COPS community and the SNMP > communities presented possible alternatives for accounting, pointed > out the importance of trying to better integrate the data models of > the various protocols, and requested that the architecture allow for > the use of other protocols to provide certain types of functionality. > The AAA WG decided to develop an architecture that explicitly excluded > the possibility of using any other protocol to provide accounting > capability, did little to integrate the data models, and does not > allow users to determine which protocol or protocols to use to gather > accounting information. AAA insisted on reinventing the wheel, > overlapping the work already being done by other WGs. > > So while I agree that the RAP WG seems to continually push the limits > of the charter rather than concentrating on their core deliverables, I > feel it is unfair to ignore their efforts to integrate with the work > of other WGs, especially the AAA WG. > > dbh > > footnote: The AAA WG actually was a bit more open-minded than this > appears. A significant minority believed that work should be done to > integrate with other protocols, or at least the scope of possible > integration should be studied further. However, they were boxed in by > the actions of their area director, Randy Bush, when he took over the > control of a meeting from the chairs, and forced a vote on a question > that was phrased in a highly prejudicial way, to adopt an approach > that precluded such integration. > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Sunday, January 20, 2002 6:56 AM > > To: Durham, David; 'rap@ops.ietf.org' > > Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' > > Subject: RE: Charter questions > > > > > > I have added the two AAA WG chairs. > > Bernard/David, do you want the type of discussion on the > > AAA mailing list as I suggest below, or would you rather > > direct some of the AAA paritipants to the RAP WG mailing > > list? > > > > Dave Durham writes: > > > Hi Bert, > > > > > > I took another look at the access-bind PIB and I disagree with > your > > > assertion. > > > > > Pls.. read my posting again. I did not make any assertion yet. > > I reported what type of questions were/are coming my way. > > and I do notice that we have an explicit statement in teh charter > > that tells us to interact with AAA WG about these types of matters. > > > > So I was asking: > > > > So what kind of action has the WG taken or WILL the WG take > > in order to make sure that we do not overlap or compete > > in this space? > > > > And so it seems that you do not agree with the allegations that > > seem implicit in the questions that are getting to me. And so > > it seems that there is a NEED to interact with the AAA WG to > > see where both WGs stand and how they understand each others > > work. > > > > So a way to start a discussion with the AAA WG chairs, or > > on the AAA WG list and use the following text as a way to start > > discussion as to the matter of overlap/conflict of work. > > > > > The whole point of that work is about binding all those > > > diverse signaling protocols so they may work together AND > > > the required device resources may be properly allocated in > > > a coordinated fashion. That certainly seems a good thing to > > > do and within the charter of a resource allocation protocol. > > > > > > I hardly see how a network can work without giving some > > > semblance as to how these many diverse signaling mechanisms > > > (RSVP, RSVP-TE, SIP, etc.) can work together given limited > > > and already partially provisioned network resources. > > > Their approach in the Access-Bind PIB seems to me to be an > > > elegant way to deal with this complex problem. > > > > > > -Dave > > > > > Bert > > From owner-rap@ops.ietf.org Mon Jan 21 20:16:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29455 for ; Mon, 21 Jan 2002 20:16:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16SpXD-000MD8-00 for rap-data@psg.com; Mon, 21 Jan 2002 17:15:35 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 16SpXC-000MD0-00; Mon, 21 Jan 2002 17:15:34 -0800 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 g0M1Eud29600; Mon, 21 Jan 2002 20:14:56 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0M1EqL22200; Mon, 21 Jan 2002 20:14:52 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CFL6RT8S; Mon, 21 Jan 2002 20:14:51 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDSJ2HBH; Mon, 21 Jan 2002 20:14:50 -0500 Message-Id: <5.0.0.25.0.20020121191444.029497f0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 21 Jan 2002 20:14:14 -0500 To: "Harrington, David" From: Kwok Ho Chan Subject: RE: Charter questions Cc: "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , Bernard Aboba , "'David Mitton'" In-Reply-To: <0BF8B32B723ED5119E0B0002A551748B01FA07E7@corp-exc3.ctron.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_31622236==_.ALT" Sender: owner-rap@ops.ietf.org Precedence: bulk --=====================_31622236==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dave and all: Please see comments inline. I hope to help clarify the situation. How about put the differences and politics aside and do our best building a better Internet. IMHO, use some of the goals and spirit of what created the IETF many years ago. -- Kwok Ho Chan -- At 12:20 PM 1/20/02 -0500, Harrington, David wrote: >Hi, > >I was going to just sit on the sidelines on this issue, but one of buttons >has just been pushed. > >I am an SNMP bigot, and I strongly resent that COPS has repeatedly >encroached on the functionality that is the purpose of SNMP, while the >IESG repeatedly prevented the SNMP community from doing anything other >than security, which COPS wasn't required to address. I have felt that >COPS has been trying to sell itself as the solution for everything, and >that the WG has continually expanded into new areas that really required a >stretch of the charter. As part of their sales strategy they have >repeatedly attacked SNMP. Obviously, I am not a great lover of how many >members of the RAP WG have behaved. I and other members of the RAP Community have tried to complement SNMP/MIB. For example, the DiffServ MIB was developed with SNMPConf in mind. The DiffServ MIB can be used at the part of the network where more static configuration make sense, and DIffServ PIB can be used where Policy Control is required. Having the 2 data object definitions evolve closely so we really is giving the different implementations a choice depending on technology applicability at the different parts of the network. Notice the similar data object definitions allow for common APIs when implementing the MIB and PIB so common coding can be done. I am not sure how much more corporation is required before we can be viewed as a friend and not an enemy. I still remember that we had the 8+ hour meeting back at the previous Washington DC IETF Meeting where we discussed what are some of the values and good features we see in COPS/PIB and provided what we think the industry wants in terms of Policy Control and how it may be valuable at the edge of the network. The RAP Community have been very open in terms of the technical design of COPS/PIB and don't mind if there is technology transfer into the SNMP/MIB designs. Working toward a better Internet. The RAP Community never set out to compete with any other technology. We are just trying to provide solution for the need of Policy Control of Resource Allocation. The exact goal of the RAP WG. We never try to overlap any of the work in RAP with any other WG. We are just trying to provide solution for Policy Control. The Usage Feedback Framework PIB is used to indicate how the Policy Control have affected the resource used and provide a direct feedback in relation to the Policy. COPS is used to control valuable resources, a feedback is required in all control systems I know of. And the Report Message Type in COPS has been there from the very beginning. COPS is a transactional protocol with deterministic results. Usage Feedback Framework PIB simply supports this feature of COPS to solve real world problem in relation to Policy Control Resource Allocation. I don't see any overlap of Usage Feedback Framework PIB with AAA at the COPS and PIB level. >However, I find it interesting to have the AAA WG raise issues about COPS >moving into areas that might overlap with the charter of other WGs. I find >it particularly galling to have it suggested that RAP has not worked to >integrate with other WGs, and implicitly indicating that AAA has been so >willing. > >I used to attend and contribute to the AAA WG effort until it became >extremely clear that AAA had absolutely no interest (see the footnote) in >developing an architecture that could allow for the integration of AAA and >COPS and SNMP. Both the COPS community and the SNMP communities presented >possible alternatives for accounting, pointed out the importance of trying >to better integrate the data models of the various protocols, and >requested that the architecture allow for the use of other protocols to >provide certain types of functionality. The AAA WG decided to develop an >architecture that explicitly excluded the possibility of using any other >protocol to provide accounting capability, did little to integrate the >data models, and does not allow users to determine which protocol or >protocols to use to gather accounting information. AAA insisted on >reinventing the wheel, overlapping the work already being done by other WGs. > >So while I agree that the RAP WG seems to continually push the limits of >the charter rather than concentrating on their core deliverables, I feel >it is unfair to ignore their efforts to integrate with the work of other >WGs, especially the AAA WG. > >dbh > >footnote: The AAA WG actually was a bit more open-minded than this >appears. A significant minority believed that work should be done to >integrate with other protocols, or at least the scope of possible >integration should be studied further. However, they were boxed in by the >actions of their area director, Randy Bush, when he took over the control >of a meeting from the chairs, and forced a vote on a question that was >phrased in a highly prejudicial way, to adopt an approach that precluded >such integration. > > > -----Original Message----- > > From: Wijnen, Bert (Bert) > [mailto:bwijnen@lucent.com] > > Sent: Sunday, January 20, 2002 6:56 AM > > To: Durham, David; 'rap@ops.ietf.org' > > Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' > > Subject: RE: Charter questions > > > > > > I have added the two AAA WG chairs. > > Bernard/David, do you want the type of discussion on the > > AAA mailing list as I suggest below, or would you rather > > direct some of the AAA paritipants to the RAP WG mailing > > list? > > > > Dave Durham writes: > > > Hi Bert, > > > > > > I took another look at the access-bind PIB and I disagree with your > > > assertion. > > > > > Pls.. read my posting again. I did not make any assertion yet. > > I reported what type of questions were/are coming my way. > > and I do notice that we have an explicit statement in teh charter > > that tells us to interact with AAA WG about these types of matters. > > > > So I was asking: > > > > So what kind of action has the WG taken or WILL the WG take > > in order to make sure that we do not overlap or compete > > in this space? > > > > And so it seems that you do not agree with the allegations that > > seem implicit in the questions that are getting to me. And so > > it seems that there is a NEED to interact with the AAA WG to > > see where both WGs stand and how they understand each others > > work. > > > > So a way to start a discussion with the AAA WG chairs, or > > on the AAA WG list and use the following text as a way to start > > discussion as to the matter of overlap/conflict of work. > > > > > The whole point of that work is about binding all those > > > diverse signaling protocols so they may work together AND > > > the required device resources may be properly allocated in > > > a coordinated fashion. That certainly seems a good thing to > > > do and within the charter of a resource allocation protocol. > > > > > > I hardly see how a network can work without giving some > > > semblance as to how these many diverse signaling mechanisms > > > (RSVP, RSVP-TE, SIP, etc.) can work together given limited > > > and already partially provisioned network resources. > > > Their approach in the Access-Bind PIB seems to me to be an > > > elegant way to deal with this complex problem. > > > > > > -Dave > > > > > Bert > > --=====================_31622236==_.ALT Content-Type: text/html; charset="us-ascii" Dave and all:
Please see comments inline.
I hope to help clarify the situation.
How about put the differences and politics aside and do our best
building a better Internet.  IMHO, use some of the goals and spirit
of what created the IETF many years ago.
-- Kwok Ho Chan --


At 12:20 PM 1/20/02 -0500, Harrington, David wrote:

Hi,

I was going to just sit on the sidelines on this issue, but one of buttons has just been pushed.

I am an SNMP bigot, and I strongly resent that COPS has repeatedly encroached on the functionality that is the purpose of SNMP, while the IESG repeatedly prevented the SNMP community from doing anything other than security, which COPS wasn't required to address. I have felt that COPS has been trying to sell itself as the solution for everything, and that the WG has continually expanded into new areas that really required a stretch of the charter. As part of their sales strategy they have repeatedly attacked SNMP. Obviously, I am not a great lover of how many members of the RAP WG have behaved.

I and other members of the RAP Community have tried to complement SNMP/MIB.
For example, the DiffServ MIB was developed with SNMPConf in mind.
The DiffServ MIB can be used at the part of the network where more static configuration
make sense, and DIffServ PIB can be used where Policy Control is required.
Having the 2 data object definitions evolve closely so we really is giving the
different implementations a choice depending on technology applicability at the different
parts of the network.  Notice the similar data object definitions allow for common
APIs when implementing the MIB and PIB so common coding can be done.
I am not sure how much more corporation is required before we can be viewed as
a friend and not an enemy.

I still remember that we had the 8+ hour meeting back at the previous Washington DC
IETF Meeting where we discussed what are some of the values and good features we
see in COPS/PIB and provided what we think the industry wants in terms of Policy
Control and how it may be valuable at the edge of the network.
The RAP Community have been very open in terms of the technical design of
COPS/PIB and don't mind if there is technology transfer into the SNMP/MIB
designs.  Working toward a better Internet.

The RAP Community never set out to compete with any other technology.   We are just
trying to provide solution for the need of Policy Control of Resource Allocation.
The exact goal of the RAP WG.
We never try to overlap any of the work in RAP with any other WG.
We are just trying to provide solution for Policy Control.

The Usage Feedback Framework PIB is used to indicate how the Policy Control have affected
the resource used and provide a direct feedback in relation to the Policy.
COPS is used to control valuable resources, a feedback is required in all control systems
I know of.  And the Report Message Type in COPS has been there from the very beginning.
COPS is a transactional protocol with deterministic results.   Usage Feedback Framework PIB
simply supports this feature of COPS to solve real world problem in relation to Policy
Control Resource Allocation.
I don't see any overlap of Usage Feedback Framework PIB with AAA at the COPS and PIB level.


However, I find it interesting to have the AAA WG raise issues about COPS moving into areas that might overlap with the charter of other WGs. I find it particularly galling to have it suggested that RAP has not worked to integrate with other WGs, and implicitly indicating that AAA has been so willing.

I used to attend and contribute to the AAA WG effort until it became extremely clear that AAA had absolutely no interest (see the footnote) in developing an architecture that could allow for the integration of AAA and COPS and SNMP. Both the COPS community and the SNMP communities presented possible alternatives for accounting, pointed out the importance of trying to better integrate the data models of the various protocols, and requested that the architecture allow for the use of other protocols to provide certain types of functionality. The AAA WG decided to develop an architecture that explicitly excluded the possibility of using any other protocol to provide accounting capability, did little to integrate the data models, and does not allow users to determine which protocol or protocols to use to gather accounting information. AAA insisted on reinventing the wheel, overlapping the work already being done by other WGs.

So while I agree that the RAP WG seems to continually push the limits of the charter rather than concentrating on their core deliverables, I feel it is unfair to ignore their efforts to integrate with the work of other WGs, especially the AAA WG.

dbh

footnote: The AAA WG actually was a bit more open-minded than this appears. A significant minority believed that work should be done to integrate with other protocols, or at least the scope of possible integration should be studied further. However, they were boxed in by the actions of their area director, Randy Bush, when he took over the control of a meeting from the chairs, and forced a vote on a question that was phrased in a highly prejudicial way, to adopt an approach that precluded such integration.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Sunday, January 20, 2002 6:56 AM
> To: Durham, David; 'rap@ops.ietf.org'
> Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton'
> Subject: RE: Charter questions
>
>
> I have added the two AAA WG chairs.
> Bernard/David, do you want the type of discussion on the
> AAA mailing list as I suggest below, or would you rather
> direct some of the AAA paritipants to the RAP WG mailing
> list?
>
> Dave Durham writes:
> > Hi Bert,
> >
> > I took another look at the access-bind PIB and I disagree with your
> > assertion.
> >
> Pls.. read my posting again. I did not make any assertion yet.
> I reported what type of questions were/are coming my way.
> and I do notice that we have an explicit statement in teh charter
> that tells us to interact with AAA WG about these types of matters.
>
> So I was asking:
>
>  So what kind of action has the WG taken or WILL the WG take
>  in order to make sure that we do not overlap or compete
>  in this space?
>
> And so it seems that you do not agree with the allegations that
> seem implicit in the questions that are getting to me. And so
> it seems that there is a NEED to interact with the AAA WG to
> see where both WGs stand and how they understand each others
> work.
>
> So a way to start a discussion with the AAA WG chairs, or    
> on the AAA WG list and use the following text as a way to start
> discussion as to the matter of overlap/conflict of work.
>
> > The whole point of that work is about binding all those
> > diverse signaling protocols so they may work together AND
> > the required device resources may be properly allocated in
> > a coordinated fashion. That certainly seems a good thing to
> > do and within the charter of a resource allocation protocol.
> >
> > I hardly see how a network can work without giving some
> > semblance as to how these many diverse signaling mechanisms
> > (RSVP, RSVP-TE, SIP, etc.) can work together given limited
> > and already partially provisioned network resources.
> > Their approach in the Access-Bind PIB seems to me to be an
> > elegant way to deal with this complex problem.
> >
> > -Dave
> >
> Bert
>
--=====================_31622236==_.ALT-- From owner-rap@ops.ietf.org Tue Jan 22 12:03:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00515 for ; Tue, 22 Jan 2002 12:03:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T4Fi-000CQf-00 for rap-data@psg.com; Tue, 22 Jan 2002 08:58:30 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16T4Fh-000CQZ-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 08:58:29 -0800 Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id QAA07199 for ; Tue, 22 Jan 2002 16:58:28 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012208573717602 ; Tue, 22 Jan 2002 08:57:37 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 08:58:27 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C0275F293@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org Cc: brian@hursley.ibm.com Subject: RE: Response Request: COPS PIBs standardization due-diligence fe edback Date: Tue, 22 Jan 2002 08:58:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Bert has asked me to make a clarification. Brian Carpenter is collecting data for those who are implementing or possibly planning on implementing COPS-PR and the Diffserv PIB. If you are planning on implementing COPS or COPS-PR and any PIBs, but not the Diffserv PIB, then please forward the mail to our AD, Bert Wijnen , and myself. Thanks again. From owner-rap@ops.ietf.org Tue Jan 22 12:48:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02097 for ; Tue, 22 Jan 2002 12:48:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T4zF-000DMh-00 for rap-data@psg.com; Tue, 22 Jan 2002 09:45:33 -0800 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16T4zE-000DMY-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 09:45:32 -0800 Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id RAA10207 for ; Tue, 22 Jan 2002 17:45:30 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012209462605333 ; Tue, 22 Jan 2002 09:46:26 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 09:45:29 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DD3F@FMSMSX34> From: "Durham, David" To: "'Wijnen, Bert (Bert)'" , "Durham, David", "'rap@ops.ietf.org'" Cc: "'Randy Bush'" , Bernard Aboba , "'David Mitton'" Subject: RE: Charter questions Date: Tue, 22 Jan 2002 09:45:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Bert, I think if you check the archive, there have been a number of presentations to the AAA WG on the subject of the Bind PIB. Likewise some of the authors would appear to be AAA people. So clearly the AAA WG should be aware of this work. As I recall (from being in the AAA audience when one of these presentations were given) the work in question was determined to be outside the scope of that WG... That being a generalized multi-protocol and multi-provisioning (eg. DiffServ) mechanism for allocating network resources. It is, however, very much in the scope of a resource allocation protocol WG... And so RAP is where it ended up. Also, on an unrelated note, I have made several ID contributions and presentations to the AAA WG. I worked to encourage AAA to adopt data modeling practices and bring their output in line with SNMP/SMIng and the other many protocol/data model combos out there. Such would allow all these many diverse technologies to work together at the data model level, and bring some level of coherency to the O&M area. Juergen gave some presentations and submitted an ID exactly to this end. This too was determined to be out-of-scope and unrealistic from their time-line perspective. -Dave > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Sunday, January 20, 2002 3:56 AM > To: Durham, David; 'rap@ops.ietf.org' > Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' > Subject: RE: Charter questions > > > I have added the two AAA WG chairs. > Bernard/David, do you want the type of discussion on the > AAA mailing list as I suggest below, or would you rather > direct some of the AAA paritipants to the RAP WG mailing > list? > > Dave Durham writes: > > Hi Bert, > > > > I took another look at the access-bind PIB and I disagree with your > > assertion. > > > Pls.. read my posting again. I did not make any assertion yet. > I reported what type of questions were/are coming my way. > and I do notice that we have an explicit statement in teh charter > that tells us to interact with AAA WG about these types of matters. > > So I was asking: > > So what kind of action has the WG taken or WILL the WG take > in order to make sure that we do not overlap or compete > in this space? > > And so it seems that you do not agree with the allegations that > seem implicit in the questions that are getting to me. And so > it seems that there is a NEED to interact with the AAA WG to > see where both WGs stand and how they understand each others > work. > > So a way to start a discussion with the AAA WG chairs, or > on the AAA WG list and use the following text as a way to start > discussion as to the matter of overlap/conflict of work. > > > The whole point of that work is about binding all those > > diverse signaling protocols so they may work together AND > > the required device resources may be properly allocated in > > a coordinated fashion. That certainly seems a good thing to > > do and within the charter of a resource allocation protocol. > > > > I hardly see how a network can work without giving some > > semblance as to how these many diverse signaling mechanisms > > (RSVP, RSVP-TE, SIP, etc.) can work together given limited > > and already partially provisioned network resources. > > Their approach in the Access-Bind PIB seems to me to be an > > elegant way to deal with this complex problem. > > > > -Dave > > > Bert > From owner-rap@ops.ietf.org Tue Jan 22 14:54:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08120 for ; Tue, 22 Jan 2002 14:54:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T6xV-000Fmp-00 for rap-data@psg.com; Tue, 22 Jan 2002 11:51:53 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16T6xU-000FmI-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 11:51:52 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id TAA26941 for ; Tue, 22 Jan 2002 19:51:51 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012211540515412 ; Tue, 22 Jan 2002 11:54:05 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 11:51:51 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DD44@FMSMSX34> From: "Durham, David" To: "'Kwok Ho Chan'" , "Harrington, David" Cc: "'Wijnen, Bert (Bert)'" , "Durham, David", "'rap@ops.ietf.org'" , "'Randy Bush'" , Bernard Aboba , "'David Mitton'" Subject: RE: Charter questions Date: Tue, 22 Jan 2002 11:51:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A37E.3AF64770" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A37E.3AF64770 Content-Type: text/plain; charset="ISO-8859-1" David H, I must take offense at one of your comments. I'm one COPS person who has devoted a great deal of my personal time to help the SNMP community. My record is Chair of SMIng (wanna guess how much time this requires?), NIM, as well as contributing at several of the SNMPConf Interims. I've also helped with the DiffServ MIB among others from time to time. What more does a guy have to do? -Dave -----Original Message----- From: Kwok Ho Chan [mailto:khchan@NortelNetworks.com] Sent: Monday, January 21, 2002 5:14 PM To: Harrington, David Cc: 'Wijnen, Bert (Bert)'; Durham, David; 'rap@ops.ietf.org'; 'Randy Bush'; Bernard Aboba; 'David Mitton' Subject: RE: Charter questions Dave and all: Please see comments inline. I hope to help clarify the situation. How about put the differences and politics aside and do our best building a better Internet. IMHO, use some of the goals and spirit of what created the IETF many years ago. -- Kwok Ho Chan -- At 12:20 PM 1/20/02 -0500, Harrington, David wrote: Hi, I was going to just sit on the sidelines on this issue, but one of buttons has just been pushed. I am an SNMP bigot, and I strongly resent that COPS has repeatedly encroached on the functionality that is the purpose of SNMP, while the IESG repeatedly prevented the SNMP community from doing anything other than security, which COPS wasn't required to address. I have felt that COPS has been trying to sell itself as the solution for everything, and that the WG has continually expanded into new areas that really required a stretch of the charter. As part of their sales strategy they have repeatedly attacked SNMP. Obviously, I am not a great lover of how many members of the RAP WG have behaved. I and other members of the RAP Community have tried to complement SNMP/MIB. For example, the DiffServ MIB was developed with SNMPConf in mind. The DiffServ MIB can be used at the part of the network where more static configuration make sense, and DIffServ PIB can be used where Policy Control is required. Having the 2 data object definitions evolve closely so we really is giving the different implementations a choice depending on technology applicability at the different parts of the network. Notice the similar data object definitions allow for common APIs when implementing the MIB and PIB so common coding can be done. I am not sure how much more corporation is required before we can be viewed as a friend and not an enemy. I still remember that we had the 8+ hour meeting back at the previous Washington DC IETF Meeting where we discussed what are some of the values and good features we see in COPS/PIB and provided what we think the industry wants in terms of Policy Control and how it may be valuable at the edge of the network. The RAP Community have been very open in terms of the technical design of COPS/PIB and don't mind if there is technology transfer into the SNMP/MIB designs. Working toward a better Internet. The RAP Community never set out to compete with any other technology. We are just trying to provide solution for the need of Policy Control of Resource Allocation. The exact goal of the RAP WG. We never try to overlap any of the work in RAP with any other WG. We are just trying to provide solution for Policy Control. The Usage Feedback Framework PIB is used to indicate how the Policy Control have affected the resource used and provide a direct feedback in relation to the Policy. COPS is used to control valuable resources, a feedback is required in all control systems I know of. And the Report Message Type in COPS has been there from the very beginning. COPS is a transactional protocol with deterministic results. Usage Feedback Framework PIB simply supports this feature of COPS to solve real world problem in relation to Policy Control Resource Allocation. I don't see any overlap of Usage Feedback Framework PIB with AAA at the COPS and PIB level. However, I find it interesting to have the AAA WG raise issues about COPS moving into areas that might overlap with the charter of other WGs. I find it particularly galling to have it suggested that RAP has not worked to integrate with other WGs, and implicitly indicating that AAA has been so willing. I used to attend and contribute to the AAA WG effort until it became extremely clear that AAA had absolutely no interest (see the footnote) in developing an architecture that could allow for the integration of AAA and COPS and SNMP. Both the COPS community and the SNMP communities presented possible alternatives for accounting, pointed out the importance of trying to better integrate the data models of the various protocols, and requested that the architecture allow for the use of other protocols to provide certain types of functionality. The AAA WG decided to develop an architecture that explicitly excluded the possibility of using any other protocol to provide accounting capability, did little to integrate the data models, and does not allow users to determine which protocol or protocols to use to gather accounting information. AAA insisted on reinventing the wheel, overlapping the work already being done by other WGs. So while I agree that the RAP WG seems to continually push the limits of the charter rather than concentrating on their core deliverables, I feel it is unfair to ignore their efforts to integrate with the work of other WGs, especially the AAA WG. dbh footnote: The AAA WG actually was a bit more open-minded than this appears. A significant minority believed that work should be done to integrate with other protocols, or at least the scope of possible integration should be studied further. However, they were boxed in by the actions of their area director, Randy Bush, when he took over the control of a meeting from the chairs, and forced a vote on a question that was phrased in a highly prejudicial way, to adopt an approach that precluded such integration. > -----Original Message----- > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] > Sent: Sunday, January 20, 2002 6:56 AM > To: Durham, David; 'rap@ops.ietf.org' > Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' > Subject: RE: Charter questions > > > I have added the two AAA WG chairs. > Bernard/David, do you want the type of discussion on the > AAA mailing list as I suggest below, or would you rather > direct some of the AAA paritipants to the RAP WG mailing > list? > > Dave Durham writes: > > Hi Bert, > > > > I took another look at the access-bind PIB and I disagree with your > > assertion. > > > Pls.. read my posting again. I did not make any assertion yet. > I reported what type of questions were/are coming my way. > and I do notice that we have an explicit statement in teh charter > that tells us to interact with AAA WG about these types of matters. > > So I was asking: > > So what kind of action has the WG taken or WILL the WG take > in order to make sure that we do not overlap or compete > in this space? > > And so it seems that you do not agree with the allegations that > seem implicit in the questions that are getting to me. And so > it seems that there is a NEED to interact with the AAA WG to > see where both WGs stand and how they understand each others > work. > > So a way to start a discussion with the AAA WG chairs, or > on the AAA WG list and use the following text as a way to start > discussion as to the matter of overlap/conflict of work. > > > The whole point of that work is about binding all those > > diverse signaling protocols so they may work together AND > > the required device resources may be properly allocated in > > a coordinated fashion. That certainly seems a good thing to > > do and within the charter of a resource allocation protocol. > > > > I hardly see how a network can work without giving some > > semblance as to how these many diverse signaling mechanisms > > (RSVP, RSVP-TE, SIP, etc.) can work together given limited > > and already partially provisioned network resources. > > Their approach in the Access-Bind PIB seems to me to be an > > elegant way to deal with this complex problem. > > > > -Dave > > > Bert > ------_=_NextPart_001_01C1A37E.3AF64770 Content-Type: text/html; charset="ISO-8859-1"
David H,
 
I must take offense at one of your comments. I'm one COPS person who has devoted a great deal of my personal time to help the SNMP community. My record is Chair of SMIng (wanna guess how much time this requires?), NIM, as well as contributing at several of the SNMPConf Interims. I've also helped with the DiffServ MIB among others from time to time.
 
What more does a guy have to do?
-Dave
-----Original Message-----
From: Kwok Ho Chan [mailto:khchan@NortelNetworks.com]
Sent: Monday, January 21, 2002 5:14 PM
To: Harrington, David
Cc: 'Wijnen, Bert (Bert)'; Durham, David; 'rap@ops.ietf.org'; 'Randy Bush'; Bernard Aboba; 'David Mitton'
Subject: RE: Charter questions

Dave and all:
Please see comments inline.
I hope to help clarify the situation.
How about put the differences and politics aside and do our best
building a better Internet.  IMHO, use some of the goals and spirit
of what created the IETF many years ago.
-- Kwok Ho Chan --


At 12:20 PM 1/20/02 -0500, Harrington, David wrote:

Hi,

I was going to just sit on the sidelines on this issue, but one of buttons has just been pushed.

I am an SNMP bigot, and I strongly resent that COPS has repeatedly encroached on the functionality that is the purpose of SNMP, while the IESG repeatedly prevented the SNMP community from doing anything other than security, which COPS wasn't required to address. I have felt that COPS has been trying to sell itself as the solution for everything, and that the WG has continually expanded into new areas that really required a stretch of the charter. As part of their sales strategy they have repeatedly attacked SNMP. Obviously, I am not a great lover of how many members of the RAP WG have behaved.

I and other members of the RAP Community have tried to complement SNMP/MIB.
For example, the DiffServ MIB was developed with SNMPConf in mind.
The DiffServ MIB can be used at the part of the network where more static configuration
make sense, and DIffServ PIB can be used where Policy Control is required.
Having the 2 data object definitions evolve closely so we really is giving the
different implementations a choice depending on technology applicability at the different
parts of the network.  Notice the similar data object definitions allow for common
APIs when implementing the MIB and PIB so common coding can be done.
I am not sure how much more corporation is required before we can be viewed as
a friend and not an enemy.

I still remember that we had the 8+ hour meeting back at the previous Washington DC
IETF Meeting where we discussed what are some of the values and good features we
see in COPS/PIB and provided what we think the industry wants in terms of Policy
Control and how it may be valuable at the edge of the network.
The RAP Community have been very open in terms of the technical design of
COPS/PIB and don't mind if there is technology transfer into the SNMP/MIB
designs.  Working toward a better Internet.

The RAP Community never set out to compete with any other technology.   We are just
trying to provide solution for the need of Policy Control of Resource Allocation.
The exact goal of the RAP WG.
We never try to overlap any of the work in RAP with any other WG.
We are just trying to provide solution for Policy Control.

The Usage Feedback Framework PIB is used to indicate how the Policy Control have affected
the resource used and provide a direct feedback in relation to the Policy.
COPS is used to control valuable resources, a feedback is required in all control systems
I know of.  And the Report Message Type in COPS has been there from the very beginning.
COPS is a transactional protocol with deterministic results.   Usage Feedback Framework PIB
simply supports this feature of COPS to solve real world problem in relation to Policy
Control Resource Allocation.
I don't see any overlap of Usage Feedback Framework PIB with AAA at the COPS and PIB level.


However, I find it interesting to have the AAA WG raise issues about COPS moving into areas that might overlap with the charter of other WGs. I find it particularly galling to have it suggested that RAP has not worked to integrate with other WGs, and implicitly indicating that AAA has been so willing.

I used to attend and contribute to the AAA WG effort until it became extremely clear that AAA had absolutely no interest (see the footnote) in developing an architecture that could allow for the integration of AAA and COPS and SNMP. Both the COPS community and the SNMP communities presented possible alternatives for accounting, pointed out the importance of trying to better integrate the data models of the various protocols, and requested that the architecture allow for the use of other protocols to provide certain types of functionality. The AAA WG decided to develop an architecture that explicitly excluded the possibility of using any other protocol to provide accounting capability, did little to integrate the data models, and does not allow users to determine which protocol or protocols to use to gather accounting information. AAA insisted on reinventing the wheel, overlapping the work already being done by other WGs.

So while I agree that the RAP WG seems to continually push the limits of the charter rather than concentrating on their core deliverables, I feel it is unfair to ignore their efforts to integrate with the work of other WGs, especially the AAA WG.

dbh

footnote: The AAA WG actually was a bit more open-minded than this appears. A significant minority believed that work should be done to integrate with other protocols, or at least the scope of possible integration should be studied further. However, they were boxed in by the actions of their area director, Randy Bush, when he took over the control of a meeting from the chairs, and forced a vote on a question that was phrased in a highly prejudicial way, to adopt an approach that precluded such integration.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Sunday, January 20, 2002 6:56 AM
> To: Durham, David; 'rap@ops.ietf.org'
> Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton'
> Subject: RE: Charter questions
>
>
> I have added the two AAA WG chairs.
> Bernard/David, do you want the type of discussion on the
> AAA mailing list as I suggest below, or would you rather
> direct some of the AAA paritipants to the RAP WG mailing
> list?
>
> Dave Durham writes:
> > Hi Bert,
> >
> > I took another look at the access-bind PIB and I disagree with your
> > assertion.
> >
> Pls.. read my posting again. I did not make any assertion yet.
> I reported what type of questions were/are coming my way.
> and I do notice that we have an explicit statement in teh charter
> that tells us to interact with AAA WG about these types of matters.
>
> So I was asking:
>
>  So what kind of action has the WG taken or WILL the WG take
>  in order to make sure that we do not overlap or compete
>  in this space?
>
> And so it seems that you do not agree with the allegations that
> seem implicit in the questions that are getting to me. And so
> it seems that there is a NEED to interact with the AAA WG to
> see where both WGs stand and how they understand each others
> work.
>
> So a way to start a discussion with the AAA WG chairs, or    
> on the AAA WG list and use the following text as a way to start
> discussion as to the matter of overlap/conflict of work.
>
> > The whole point of that work is about binding all those
> > diverse signaling protocols so they may work together AND
> > the required device resources may be properly allocated in
> > a coordinated fashion. That certainly seems a good thing to
> > do and within the charter of a resource allocation protocol.
> >
> > I hardly see how a network can work without giving some
> > semblance as to how these many diverse signaling mechanisms
> > (RSVP, RSVP-TE, SIP, etc.) can work together given limited
> > and already partially provisioned network resources.
> > Their approach in the Access-Bind PIB seems to me to be an
> > elegant way to deal with this complex problem.
> >
> > -Dave
> >
> Bert
>
------_=_NextPart_001_01C1A37E.3AF64770-- From owner-rap@ops.ietf.org Tue Jan 22 15:40:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09554 for ; Tue, 22 Jan 2002 15:40:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T7fk-000GfW-00 for rap-data@psg.com; Tue, 22 Jan 2002 12:37:36 -0800 Received: from [64.223.136.41] (helo=hqmail01.ellacoya.com) by psg.com with esmtp (Exim 3.33 #1) id 16T7fj-000Ges-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 12:37:35 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 15:35:50 -0500 Message-ID: From: "Weiss, Walter" To: "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" Cc: "'Randy Bush'" , Bernard Aboba , "'David Mitton'" Subject: RE: Charter questions Date: Tue, 22 Jan 2002 15:35:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A384.60CA3640" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A384.60CA3640 Content-Type: text/plain; charset="iso-8859-1" I have a great deal of respect for Dave H. and therefore I have to take his opinions seriously. Dave H. has suggested that folks with a COPS bias have a habit of encroaching on other spaces. I believe he is half right. COPS was clearly floundering after RSVP lost its momentum and during that period, I believe there were those who had a solution looking for a problem (quite reminiscent to DIAMETER's early days :-) The advent of COPS-PR in my view was an encroachment, but it was also a wakeup call to the larger NM community. While I was not in favor of COPS-PR early on because it represented yet another data model, I could see how it addressed some deficiencies with existing NM alternatives. That said, all of this was overshadowed by Randy's observation that NM solutions (including COPS) were not aligned with consumer requirements. On to AAA and a history lesson. There are a large number of people who tried to bring AAA into the larger NM fold. There were those who suggested that AAA could use other protocols to satisfy current needs. There were those that indicated that a common data model was necessary to allow multiple protocols to work cooperatively. Then there were those (I was particularly involved in this one) that suggested that minimally, AAA should define structured attributes so that DIAMETER could support attributes and objects so that the protocol could reuse structures defined in data definition languages like SMI and SPPI. In the end, the DIAMETER proponents rebuffed all these suggestions. At this point in time two interesting things happened. First, the AAA Architecture folks, who were very interested in authorization issues realized that COPS and COPS-PR were much more aligned to support authorization than DIAMETER. Second, I had a discussion with Randy, Bernard, and David Mitton, that ultimately lead to the creation of the Access Bind PIB. In this discussion, I argued that a flat attribute space as defined by DIAMETER could never be used to support service authorization because defining something like QoS semantics required not only a large number of attributes but also specific relationships between attributes. The simple example that comes to mind is a classifier, which is in effect a field expression consisting of ANDs, ORs, and wildcards. The consensus was that DIAMETER is a simple RPC mechanism, where each attribute is a parameter. As such, DIAMETER's applicability is limited to the number of procedures (command/attribute list pairs) that one is willing to standardize. If we were to take the QoS structures already defined and flatten them so that they could be expressed in DIAMETER (and FORTRAN ;-), minimally this would require the standardization of at least a square of the number of structures defined to date (and that does not include all the security, tunneling, etc. structures that would also be applicable). In this discussion I suggested the following: Since DIAMETER was not capable of supporting complex relationships between users and related QoS/Security/Tunneling behaviors, I and others wanted to address this with another protocol. No one had a problem with that. Most of the authors of Access Bind are active in AAA as well. In fact the majority of the authors and the primary drivers for the PIB also participate in the AAA Architecture group. They certainly don't qualify as COPS bigots and they are active in both the RAP and AAA WGs. I, for one, have spoken to both Bernard and David Mitton about what we are doing with Access Bind and encouraged them to come to RAP and AAAArch meetings to see what we are doing. Given this, it would be hard to argue that the AAA folks are unaware of our activities. Also, let's be clear on what the requirements for the Access Bind PIB were: 1. Leverage existing QoS definition semantics to construct user specific QoS policies. 2. Because of the dynamic nature of both users (particularly in a mobile environment) and services, minimize the cost of setting up policies for a new (authenticated) user. In this particular case, both the authentication and the policy configuration can be set up in two messages (depending on the authentication protocol). 3. Feedback/statistics on a per policy basis, rather than per session. 4. COPS was designed to outsource questions that the switch could not address locally. The Access Bind PIB takes advantage of this strength by defining a PIB that outsources a new user request and provides QoS policies to the switch as a response. This work is not only useful because of the problems it addresses but also because it harmonizes COPS and COPS-PR, which were previously perceived as separate protocols. One more point. When this work was chartered, it was clearly argued that the justification of the work was to avoid using multiple protocols for one specific problem: Managing per user services on the network edge. We don't want to use one protocol for authentication, another protocol for policy, another protocol for statistics, etc. This approach could only works if the data models for all three protocols are normalized and even then each protocol adds complexity in its own right. As I said, the industry has not removed complexity by making core routing simple. It has moved the complexity to the edge and there is no standard other than Access Bind and no protocol other than COPS that addresses this movement of complexity. regards, -Walter -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: Sunday, January 20, 2002 12:20 PM To: 'Wijnen, Bert (Bert)'; Durham, David; 'rap@ops.ietf.org' Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' Subject: RE: Charter questions Hi, I was going to just sit on the sidelines on this issue, but one of buttons has just been pushed. I am an SNMP bigot, and I strongly resent that COPS has repeatedly encroached on the functionality that is the purpose of SNMP, while the IESG repeatedly prevented the SNMP community from doing anything other than security, which COPS wasn't required to address. I have felt that COPS has been trying to sell itself as the solution for everything, and that the WG has continually expanded into new areas that really required a stretch of the charter. As part of their sales strategy they have repeatedly attacked SNMP. Obviously, I am not a great lover of how many members of the RAP WG have behaved. However, I find it interesting to have the AAA WG raise issues about COPS moving into areas that might overlap with the charter of other WGs. I find it particularly galling to have it suggested that RAP has not worked to integrate with other WGs, and implicitly indicating that AAA has been so willing. I used to attend and contribute to the AAA WG effort until it became extremely clear that AAA had absolutely no interest (see the footnote) in developing an architecture that could allow for the integration of AAA and COPS and SNMP. Both the COPS community and the SNMP communities presented possible alternatives for accounting, pointed out the importance of trying to better integrate the data models of the various protocols, and requested that the architecture allow for the use of other protocols to provide certain types of functionality. The AAA WG decided to develop an architecture that explicitly excluded the possibility of using any other protocol to provide accounting capability, did little to integrate the data models, and does not allow users to determine which protocol or protocols to use to gather accounting information. AAA insisted on reinventing the wheel, overlapping the work already being done by other WGs. So while I agree that the RAP WG seems to continually push the limits of the charter rather than concentrating on their core deliverables, I feel it is unfair to ignore their efforts to integrate with the work of other WGs, especially the AAA WG. dbh footnote: The AAA WG actually was a bit more open-minded than this appears. A significant minority believed that work should be done to integrate with other protocols, or at least the scope of possible integration should be studied further. However, they were boxed in by the actions of their area director, Randy Bush, when he took over the control of a meeting from the chairs, and forced a vote on a question that was phrased in a highly prejudicial way, to adopt an approach that precluded such integration. > -----Original Message----- > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] > Sent: Sunday, January 20, 2002 6:56 AM > To: Durham, David; 'rap@ops.ietf.org' > Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' > Subject: RE: Charter questions > > > I have added the two AAA WG chairs. > Bernard/David, do you want the type of discussion on the > AAA mailing list as I suggest below, or would you rather > direct some of the AAA paritipants to the RAP WG mailing > list? > > Dave Durham writes: > > Hi Bert, > > > > I took another look at the access-bind PIB and I disagree with your > > assertion. > > > Pls.. read my posting again. I did not make any assertion yet. > I reported what type of questions were/are coming my way. > and I do notice that we have an explicit statement in teh charter > that tells us to interact with AAA WG about these types of matters. > > So I was asking: > > So what kind of action has the WG taken or WILL the WG take > in order to make sure that we do not overlap or compete > in this space? > > And so it seems that you do not agree with the allegations that > seem implicit in the questions that are getting to me. And so > it seems that there is a NEED to interact with the AAA WG to > see where both WGs stand and how they understand each others > work. > > So a way to start a discussion with the AAA WG chairs, or > on the AAA WG list and use the following text as a way to start > discussion as to the matter of overlap/conflict of work. > > > The whole point of that work is about binding all those > > diverse signaling protocols so they may work together AND > > the required device resources may be properly allocated in > > a coordinated fashion. That certainly seems a good thing to > > do and within the charter of a resource allocation protocol. > > > > I hardly see how a network can work without giving some > > semblance as to how these many diverse signaling mechanisms > > (RSVP, RSVP-TE, SIP, etc.) can work together given limited > > and already partially provisioned network resources. > > Their approach in the Access-Bind PIB seems to me to be an > > elegant way to deal with this complex problem. > > > > -Dave > > > Bert > ------_=_NextPart_001_01C1A384.60CA3640 Content-Type: text/html; charset="iso-8859-1" RE: Charter questions
I have a great deal of respect for Dave H. and therefore I have to take his opinions seriously. Dave H. has suggested that folks with a COPS bias have a habit of encroaching on other spaces. I believe he is half right. COPS was clearly floundering after RSVP lost its momentum and during that period, I believe there were those who had a solution looking for a problem (quite reminiscent to DIAMETER's early days :-)  The advent of COPS-PR in my view was an encroachment, but it was also a wakeup call to the larger NM community. While I was not in favor of COPS-PR early on because it represented yet another data model, I could see how it addressed some deficiencies with existing NM alternatives. That said, all of this was overshadowed by Randy's observation that NM solutions (including COPS) were not aligned with consumer requirements.
 
On to AAA and a history lesson. There are a large number of people who tried to bring AAA into the larger NM fold. There were those who suggested that AAA could use other protocols to satisfy current needs. There were those that indicated that a common data model was necessary to allow multiple protocols to work cooperatively. Then there were those (I was particularly involved in this one) that suggested that minimally, AAA should define structured attributes so that DIAMETER could support attributes and objects so that the protocol could reuse structures defined in data definition languages like SMI and SPPI. In the end, the DIAMETER proponents rebuffed all these suggestions.
 
At this point in time two interesting things happened. First, the AAA Architecture folks, who were very interested in authorization issues realized that COPS and COPS-PR were much more aligned to support authorization than DIAMETER. Second, I had a discussion with Randy, Bernard, and David Mitton, that ultimately lead to the creation of the Access Bind PIB. In this discussion, I argued that a flat attribute space as defined by DIAMETER could never be used to support service authorization because defining something like QoS semantics required not only a large number of attributes but also specific relationships between attributes. The simple example that comes to mind is a classifier, which is in effect a field expression consisting of ANDs, ORs, and wildcards. The consensus was that DIAMETER is a simple RPC mechanism, where each attribute is a parameter. As such, DIAMETER's applicability is limited to the number of procedures (command/attribute list pairs) that one is willing to standardize. If we were to take the QoS structures already defined and flatten them so that they could be expressed in DIAMETER (and FORTRAN ;-), minimally this would require the standardization of at least a square of the number of structures defined to date (and that does not include all the security, tunneling, etc. structures that would also be applicable). In this discussion I suggested the following: Since DIAMETER was not capable of supporting complex relationships between users and related QoS/Security/Tunneling behaviors, I and others wanted to address this with another protocol. No one had a problem with that.
 
Most of the authors of Access Bind are active in AAA as well. In fact the majority of the authors and the primary drivers for the PIB also participate in the AAA Architecture group. They certainly don't qualify as COPS bigots and they are active in both the RAP and AAA WGs. I, for one, have spoken to both Bernard and David Mitton about what we are doing with Access Bind and encouraged them to come to RAP and AAAArch meetings to see what we are doing. Given this, it would be hard to argue that the AAA folks are unaware of our activities.
 
Also, let's be clear on what the requirements for the Access Bind PIB were:
1. Leverage existing QoS definition semantics to construct user specific QoS policies.
2. Because of the dynamic nature of both users (particularly in a mobile environment) and services, minimize the cost of setting up policies for a new (authenticated) user. In this particular case, both the authentication and the policy configuration can be set up in two messages (depending on the authentication protocol).
3. Feedback/statistics on a per policy basis, rather than per session.
4. COPS was designed to outsource questions that the switch could not address locally. The Access Bind PIB takes advantage of this strength by defining a PIB that outsources a new user request and provides QoS policies to the switch as a response. This work is not only useful because of the problems it addresses but also because it harmonizes COPS and COPS-PR, which were previously perceived as separate protocols.
 
One more point. When this work was chartered, it was clearly argued that the justification of the work was to avoid using multiple protocols for one specific problem: Managing per user services on the network edge. We don't want to use one protocol for authentication, another protocol for policy, another protocol for statistics, etc. This approach could only works if the data models for all three protocols are normalized and even then each protocol adds complexity in its own right. As I said, the industry has not removed complexity by making core routing simple. It has moved the complexity to the edge and there is no standard other than Access Bind and no protocol other than COPS that addresses this movement of complexity.
 
regards,
 
-Walter
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: Sunday, January 20, 2002 12:20 PM
To: 'Wijnen, Bert (Bert)'; Durham, David; 'rap@ops.ietf.org'
Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton'
Subject: RE: Charter questions

Hi,

I was going to just sit on the sidelines on this issue, but one of buttons has just been pushed.

I am an SNMP bigot, and I strongly resent that COPS has repeatedly encroached on the functionality that is the purpose of SNMP, while the IESG repeatedly prevented the SNMP community from doing anything other than security, which COPS wasn't required to address. I have felt that COPS has been trying to sell itself as the solution for everything, and that the WG has continually expanded into new areas that really required a stretch of the charter. As part of their sales strategy they have repeatedly attacked SNMP. Obviously, I am not a great lover of how many members of the RAP WG have behaved.

However, I find it interesting to have the AAA WG raise issues about COPS moving into areas that might overlap with the charter of other WGs. I find it particularly galling to have it suggested that RAP has not worked to integrate with other WGs, and implicitly indicating that AAA has been so willing.

I used to attend and contribute to the AAA WG effort until it became extremely clear that AAA had absolutely no interest (see the footnote) in developing an architecture that could allow for the integration of AAA and COPS and SNMP. Both the COPS community and the SNMP communities presented possible alternatives for accounting, pointed out the importance of trying to better integrate the data models of the various protocols, and requested that the architecture allow for the use of other protocols to provide certain types of functionality. The AAA WG decided to develop an architecture that explicitly excluded the possibility of using any other protocol to provide accounting capability, did little to integrate the data models, and does not allow users to determine which protocol or protocols to use to gather accounting information. AAA insisted on reinventing the wheel, overlapping the work already being done by other WGs.

So while I agree that the RAP WG seems to continually push the limits of the charter rather than concentrating on their core deliverables, I feel it is unfair to ignore their efforts to integrate with the work of other WGs, especially the AAA WG.

dbh

footnote: The AAA WG actually was a bit more open-minded than this appears. A significant minority believed that work should be done to integrate with other protocols, or at least the scope of possible integration should be studied further. However, they were boxed in by the actions of their area director, Randy Bush, when he took over the control of a meeting from the chairs, and forced a vote on a question that was phrased in a highly prejudicial way, to adopt an approach that precluded such integration.


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Sunday, January 20, 2002 6:56 AM
> To: Durham, David; 'rap@ops.ietf.org'
> Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton'
> Subject: RE: Charter questions
>
>
> I have added the two AAA WG chairs.
> Bernard/David, do you want the type of discussion on the
> AAA mailing list as I suggest below, or would you rather
> direct some of the AAA paritipants to the RAP WG mailing
> list?
>
> Dave Durham writes:
> > Hi Bert,
> >
> > I took another look at the access-bind PIB and I disagree with your
> > assertion.
> >
> Pls.. read my posting again. I did not make any assertion yet.
> I reported what type of questions were/are coming my way.
> and I do notice that we have an explicit statement in teh charter
> that tells us to interact with AAA WG about these types of matters.
>
> So I was asking:
>
>  So what kind of action has the WG taken or WILL the WG take
>  in order to make sure that we do not overlap or compete
>  in this space?
>
> And so it seems that you do not agree with the allegations that
> seem implicit in the questions that are getting to me. And so
> it seems that there is a NEED to interact with the AAA WG to
> see where both WGs stand and how they understand each others
> work.
>
> So a way to start a discussion with the AAA WG chairs, or    
> on the AAA WG list and use the following text as a way to start
> discussion as to the matter of overlap/conflict of work.
>
> > The whole point of that work is about binding all those
> > diverse signaling protocols so they may work together AND
> > the required device resources may be properly allocated in
> > a coordinated fashion. That certainly seems a good thing to
> > do and within the charter of a resource allocation protocol.
> >
> > I hardly see how a network can work without giving some
> > semblance as to how these many diverse signaling mechanisms
> > (RSVP, RSVP-TE, SIP, etc.) can work together given limited
> > and already partially provisioned network resources.
> > Their approach in the Access-Bind PIB seems to me to be an
> > elegant way to deal with this complex problem.
> >
> > -Dave
> >
> Bert
>

------_=_NextPart_001_01C1A384.60CA3640-- From owner-rap@ops.ietf.org Tue Jan 22 16:42:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11730 for ; Tue, 22 Jan 2002 16:42:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T8dl-000I05-00 for rap-data@psg.com; Tue, 22 Jan 2002 13:39:37 -0800 Received: from dhcp317.ripemtg.ripe.net ([193.0.5.61] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16T8dk-000Hzy-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 13:39:36 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16T8dj-0002bM-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 22:39:35 +0100 In-Reply-To: <10C8636AE359D4119118009027AE99870DA5DD44@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 22 Jan 2002 12:01:12 -0800 (PST) From: Bernard Aboba To: "Durham, David" cc: "'Kwok Ho Chan'" , "Harrington, David" , "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Sender: owner-rap@ops.ietf.org Precedence: bulk > Both the COPS community and the SNMP communities presented > possible alternatives for accounting, pointed out the importance of trying > to better integrate the data models of the various protocols, and requested > that the architecture allow for the use of other protocols to provide > certain types of functionality. I think you're referring to the "solicitation for protocol submissions". The solicitation was for protocols satisfying all the requirements, and so the evaluation team made an overall recommendation, not a separate one for accounting and authentication. > The AAA WG decided to develop an > architecture that explicitly excluded the possibility of using any other > protocol to provide accounting capability Not sure what you're referring to. While Diameter does support all elements of AAA in a single protocol, use of other accounting methods is not prohibited. Today there are quite a few networks that use RADIUS for authentication and authorization and SNMP for accounting, and SNMP is today the most widely used accounting protocol. I don't expect that to change. > models, and does not allow users to determine which protocol or protocols to > use to gather accounting information. AAA insisted on reinventing the wheel, > overlapping the work already being done by other WGs. The accounting requirements for AAA are documented in RFC 2975 and 2989. As noted in those documents, no existing protocol satisfied all the accounting requirements for network access. The particular gap was in the area of inter-domain, highly reliable and secure accounting. So while it's fair to say that much of the functionality in Diameter is non-unique, there are elements that are new. > However, they were boxed in by the actions of their area director In terms of constraints, the biggest one has been the deadlines set by the 3G folks. This has made it difficult for the WG to take on major areas of functionality that weren't absolutely required to solve the immediate problem. Data modelling was one of the areas of functionality that was put off -- though not necessarily eliminated. As has been pointed out on the mailing list, there is no issue with putting modelled information within a Diameter AVP. So Diameter can carry XML, ASN.1 or any other flavor that is needed. Since accounting servers typically only write the data to disk anyway, presumably the encoding is only relevant to the backend systems that need to interpret it. From owner-rap@ops.ietf.org Tue Jan 22 16:43:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11746 for ; Tue, 22 Jan 2002 16:43:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T8fF-000I2L-00 for rap-data@psg.com; Tue, 22 Jan 2002 13:41:09 -0800 Received: from dhcp317.ripemtg.ripe.net ([193.0.5.61] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16T8fE-000I2F-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 13:41:09 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16T8fE-0002be-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 22:41:08 +0100 In-Reply-To: <10C8636AE359D4119118009027AE99870DA5DD3F@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 22 Jan 2002 12:21:07 -0800 (PST) From: Bernard Aboba To: "Durham, David" cc: "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Sender: owner-rap@ops.ietf.org Precedence: bulk > I think if you check the archive, there have been a number of presentations > to the AAA WG on the subject of the Bind PIB. I have checked the IETF AAA WG proceedings. There was a presentation from the AAARCH folks on data modelling, but none on the Bind PIB, as far as I can tell. Can you provide more information on the meetings at which this presentation was made? > Likewise some of the authors would appear to be AAA people. Ah... the people involved were from AAARCH IRTF WG, *not* the AAA WG. Was the Bind PIB perhaps presented in AAARCH? > So clearly the AAA WG should be aware of this work. I think you mean AAARCH IRTG WG, not AAA WG, right? > As I recall (from being in the AAA audience when one of these > presentations were given) the work in question was determined to be outside > the scope of that WG... Check the proceedings again. No such decision was made -- the WG did decide not to *mandate* support for data modelling, but left open including optional data modelling support, and encouraged further refinement of the SMIng proposals. > Juergen gave some > presentations and submitted an ID exactly to this end. This too was > determined to be out-of-scope and unrealistic from their time-line > perspective. It wasn't determined to be out of scope -- the WG just decided not to mandate support for it. From owner-rap@ops.ietf.org Tue Jan 22 16:49:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11975 for ; Tue, 22 Jan 2002 16:49:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T8lB-000IBK-00 for rap-data@psg.com; Tue, 22 Jan 2002 13:47:17 -0800 Received: from dhcp317.ripemtg.ripe.net ([193.0.5.61] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16T8lB-000IBE-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 13:47:17 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16T8lA-0002cn-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 22:47:16 +0100 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 22 Jan 2002 12:53:21 -0800 (PST) From: Bernard Aboba To: "Weiss, Walter" cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Sender: owner-rap@ops.ietf.org Precedence: bulk > In this discussion I suggested > the following: Since DIAMETER was not capable of supporting complex > relationships between users and related QoS/Security/Tunneling behaviors, I > and others wanted to address this with another protocol. No one had a > problem with that. Diameter now does have some functionality for provisioning of tunnels and QoS behavior on a per-user basis. Has anyone in RAP reviewed the QoS AVP functionality? > Given this, it would be hard to argue that the AAA folks are unaware > of our activities. We certainly did talk with you about the issues you describe, and you have fairly characterized the discussion. Note however, that those discussions did not cross over into discussions of alternatives for network access authentication. > Also, let's be clear on what the requirements for the Access Bind PIB were: > 1. Leverage existing QoS definition semantics to construct user specific QoS > policies. Diameter currently has an AVP that does this. > 2. Because of the dynamic nature of both users (particularly in a mobile > environment) and services, minimize the cost of setting up policies for a > new (authenticated) user. In this particular case, both the authentication > and the policy configuration can be set up in two messages (depending on the > authentication protocol). Are we talking about handling network access authentication and authorization, including EAP as part of this? > 3. Feedback/statistics on a per policy basis, rather than per session. Diameter does not do this. >handling all the policies... for the network edge. Presumably this also includes authentication and authorization for network access? From owner-rap@ops.ietf.org Tue Jan 22 17:38:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13476 for ; Tue, 22 Jan 2002 17:38:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T9W4-000JEx-00 for rap-data@psg.com; Tue, 22 Jan 2002 14:35:44 -0800 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16T9W3-000JEq-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 14:35:43 -0800 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.28 2002/01/02 21:40:45 root Exp $) with ESMTP id g0MMZCK11127 for ; Tue, 22 Jan 2002 22:35:12 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.11 2001/11/09 23:28:01 root Exp $) with SMTP id g0MMZG322640 for ; Tue, 22 Jan 2002 22:35:16 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012214351032120 ; Tue, 22 Jan 2002 14:35:11 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 14:35:40 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DD47@FMSMSX34> From: "Durham, David" To: "'Bernard Aboba'" Cc: "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'", "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Date: Tue, 22 Jan 2002 14:35:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > > > I think if you check the archive, there have been a number > of presentations > > to the AAA WG on the subject of the Bind PIB. > > I have checked the IETF AAA WG proceedings. There was a > presentation from > the AAARCH folks on data modelling, but none on the Bind PIB, > as far as I > can tell. Can you provide more information on the meetings at > which this > presentation was made? > [Dave] Yes, modeling was the one I recall. You are correct that this is not the Bind PIB. However, the Bind PIB makes use of data modeling to achieve its multi-protocol integration of resource allocation. > > Likewise some of the authors would appear to be AAA people. > > Ah... the people involved were from AAARCH IRTF WG, *not* the > AAA WG. Was > the Bind PIB perhaps presented in AAARCH? > > > So clearly the AAA WG should be aware of this work. > > I think you mean AAARCH IRTG WG, not AAA WG, right? > [Dave] Perhaps. Are these people somehow scorned by the AAA WG? Seems to me there is participation in both. > > As I recall (from being in the AAA audience when one of these > > presentations were given) the work in question was > determined to be outside > > the scope of that WG... > > Check the proceedings again. No such decision was made -- the WG > did decide not to *mandate* support for data modelling, but left open > including optional data modelling support, and encouraged further > refinement of the SMIng proposals. > [Dave] The AAA WG choice to go with a flat AVP model precludes a data model approach. These are two very different/contrary methodologies, and the WG is currently proceeding with the former. > > Juergen gave some > > presentations and submitted an ID exactly to this end. This too was > > determined to be out-of-scope and unrealistic from their time-line > > perspective. > > It wasn't determined to be out of scope -- the WG just decided not to > mandate support for it. > [Dave] I do not understand how to interpret this statement. From owner-rap@ops.ietf.org Tue Jan 22 17:57:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13910 for ; Tue, 22 Jan 2002 17:57:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T9o8-000JeG-00 for rap-data@psg.com; Tue, 22 Jan 2002 14:54:24 -0800 Received: from [64.223.136.41] (helo=hqmail01.ellacoya.com) by psg.com with esmtp (Exim 3.33 #1) id 16T9o7-000JeA-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 14:54:23 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 17:53:09 -0500 Message-ID: From: "Weiss, Walter" To: "'Bernard Aboba'" Cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Date: Tue, 22 Jan 2002 17:53:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Bernard, Thanks for the reply. Comments inline. regards, -Walter > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, January 22, 2002 3:53 PM > To: Weiss, Walter > Cc: 'Harrington, David'; 'Wijnen, Bert (Bert)'; Durham, David; > 'rap@ops.ietf.org'; 'Randy Bush'; 'David Mitton' > Subject: RE: Charter questions > > > > In this discussion I suggested > > the following: Since DIAMETER was not capable of supporting complex > > relationships between users and related > QoS/Security/Tunneling behaviors, I > > and others wanted to address this with another protocol. No > one had a > > problem with that. > > Diameter now does have some functionality for provisioning of > tunnels and QoS behavior on a per-user basis. Has anyone in RAP > reviewed the QoS AVP functionality? I was not aware of the QoS or tunneling AVPs. Nor do I believe that RAP is the right group for addressing QoS AVP issues. However, having looked at them quickly, I would have a set of issues that would prevent me from feasibly implementing the proposal. Many stem from the my interpretation that the entire QoS policy is captured in a single 'value'. If anything it reinforces my previous concerns about the approach AAA is taking to addressing these issues: No problem, here's a new AVP. > > > Given this, it would be hard to argue that the AAA folks are unaware > > of our activities. > > We certainly did talk with you about the issues you describe, > and you have > fairly characterized the discussion. Note however, that those > discussions > did not cross over into discussions of alternatives for network access > authentication. > I tend to remember themes rather than words, so you may be correct. On the other hand, I thought that we specifically discussed the need to tie "users" to complex policies within a single protocol. It certainly makes sense to consolidate authentication and provisioning in order to minimize setup latencies (something that multiple protocols operating in parallel would have difficulty accomplishing). > > Also, let's be clear on what the requirements for the > Access Bind PIB were: > > 1. Leverage existing QoS definition semantics to construct > user specific QoS > > policies. > > Diameter currently has an AVP that does this. My reading is that DIAMETER has 'a' QoS semantic. Frankly, my experience would suggest that DIAMETER has trouble leveraging any prior work other than RADIUS. > > > 2. Because of the dynamic nature of both users > (particularly in a mobile > > environment) and services, minimize the cost of setting up > policies for a > > new (authenticated) user. In this particular case, both the > authentication > > and the policy configuration can be set up in two messages > (depending on the > > authentication protocol). > > Are we talking about handling network access authentication and > authorization, including EAP as part of this? NOPE. EAP requires an extra pair of messages for challenge negotiation. > > > 3. Feedback/statistics on a per policy basis, rather than > per session. > > Diameter does not do this. > > >handling all the policies... for the network edge. > > Presumably this also includes authentication and > authorization for network > access? > Network Access is implicit. In fact, there are models that are discussed in the draft that allow limited Network Access policies (specifically to HTTP based authentication servers) prior to full Network Access and user specific policy assignments. From owner-rap@ops.ietf.org Tue Jan 22 17:57:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13922 for ; Tue, 22 Jan 2002 17:57:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T9om-000Jfv-00 for rap-data@psg.com; Tue, 22 Jan 2002 14:55:04 -0800 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16T9nx-000Je5-00 for rap@ops.ietf.org; Tue, 22 Jan 2002 14:55:03 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id WAA24544 for ; Tue, 22 Jan 2002 22:54:11 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012214562423645 ; Tue, 22 Jan 2002 14:56:24 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 14:54:09 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DD4B@FMSMSX34> From: "Durham, David" To: "'Bernard Aboba'" , "Weiss, Walter" Cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'", "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Date: Tue, 22 Jan 2002 14:54:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > > > In this discussion I suggested > > the following: Since DIAMETER was not capable of supporting complex > > relationships between users and related > QoS/Security/Tunneling behaviors, I > > and others wanted to address this with another protocol. No > one had a > > problem with that. > > Diameter now does have some functionality for provisioning of > tunnels and > QoS behavior on a per-user basis. Has anyone in RAP reviewed > the QoS AVP > functionality? > [Dave] I have. It goes way back. This is essentially another resource reservation protocol akin to RSVP. It is not doing what the Bind PIB does. That is, an integrated model for allocating resources that can work with the gamut of signaling protocols such as RSVP, SIP, (The DIAMETER QOS protocol?), etc. integrated with the DiffServ model for provisioned resources as exposed by the DiffServ MIB and PIB. Also, I was unaware that the AAA WG was expanding its role to define additional QoS signaling protocols? I thought Mobile IP and NASReq were the target areas. From owner-rap@ops.ietf.org Tue Jan 22 18:04:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14059 for ; Tue, 22 Jan 2002 18:04:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T9vW-000JqA-00 for rap-data@psg.com; Tue, 22 Jan 2002 15:02:02 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.33 #1) id 16T9vV-000Jq4-00; Tue, 22 Jan 2002 15:02:01 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA06749; Tue, 22 Jan 2002 14:45:50 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 22 Jan 2002 14:45:50 -0800 (PST) From: Bernard Aboba To: "Durham, David" cc: "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions In-Reply-To: <10C8636AE359D4119118009027AE99870DA5DD47@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk > [Dave] Perhaps. Are these people somehow scorned by the AAA WG? Seems to me > there is participation in both. The charters of AAARCH IRTF WG and AAA WG are very different, as are the work items. Quite a few people go to both. But making a proposal to one group does not automatically guarantee consideration by the other. Although they both meet at IETF, the same people go to both, and both publish RFCs, one is an IRTF WG and the other is an IETF WG. > > It wasn't determined to be out of scope -- the WG just decided not to > > mandate support for it. > > > [Dave] I do not understand how to interpret this statement. Juergen was encouraged to further develop the proposal, for inclusion as an optional element. It was also discussed how alternate encodings might be used for AVPs such as the QoS AVP. From owner-rap@ops.ietf.org Tue Jan 22 18:09:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14115 for ; Tue, 22 Jan 2002 18:09:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TA0t-000JzF-00 for rap-data@psg.com; Tue, 22 Jan 2002 15:07:35 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.33 #1) id 16TA0s-000Jz8-00; Tue, 22 Jan 2002 15:07:34 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA06756; Tue, 22 Jan 2002 14:51:14 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 22 Jan 2002 14:51:14 -0800 (PST) From: Bernard Aboba To: "Durham, David" cc: "Weiss, Walter" , "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions In-Reply-To: <10C8636AE359D4119118009027AE99870DA5DD4B@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk > Also, I was unaware that the AAA WG was expanding its role to define > additional QoS signaling protocols? I thought Mobile IP and NASReq were the > target areas. I don't think that Diameter is functioning as a signalling protocol here, is it? Last time I looked, the QoS AVP was somewhat akin to the Filter attribute, and had no dynamic capabilities. The justification for putting this in was based on some of the requirements in RFC 2989. From owner-rap@ops.ietf.org Tue Jan 22 19:58:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15932 for ; Tue, 22 Jan 2002 19:58:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TBcY-000M7h-00 for rap-data@psg.com; Tue, 22 Jan 2002 16:50:34 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.33 #1) id 16TBcX-000M7b-00; Tue, 22 Jan 2002 16:50:33 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA06850; Tue, 22 Jan 2002 16:34:19 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 22 Jan 2002 16:34:19 -0800 (PST) From: Bernard Aboba To: "Weiss, Walter" cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk > I would have a set of issues that would prevent me from > feasibly implementing the proposal. Many stem from the my interpretation > that the entire QoS policy is captured in a single 'value'. If anything it > reinforces my previous concerns about the approach AAA is taking to > addressing these issues: No problem, here's a new AVP. Yup, that pretty much summarizes the mind-set ;) I'd suggest if you think that the AVP is broken or not very useful even for the limited set of scenarios it's trying to address, that an issue should be filed on this. > My reading is that DIAMETER has 'a' QoS semantic. Frankly, my experience > would suggest that DIAMETER has trouble leveraging any prior work other than > RADIUS. I think it's accurate to say that the goals for the QoS AVP were not very lofty. I'm not sure that this is a problem per se, since COPS has much more sophisticated capabilities in this regard. > NOPE. EAP requires an extra pair of messages for challenge negotiation. But COPS now does support EAP authentication as well, correct? > Network Access is implicit. In fact, there are models that are discussed in > the draft that allow limited Network Access policies (specifically to HTTP > based authentication servers) prior to full Network Access and user specific > policy assignments. How many of the other RFC 2989 requirements does the COPS/AAA functionality satisfy? Souds like you've essentially got functionality equivalent to Diameter NASREQ, and Accounting. Can it do Mobile IP too? Protection of AVPs end-to-end a la CMS-Sec? From owner-rap@ops.ietf.org Wed Jan 23 11:25:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14886 for ; Wed, 23 Jan 2002 11:25:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TQ9I-000FXl-00 for rap-data@psg.com; Wed, 23 Jan 2002 08:21:20 -0800 Received: from [64.223.136.41] (helo=hqmail01.ellacoya.com) by psg.com with esmtp (Exim 3.33 #1) id 16TQ9H-000FXd-00 for rap@ops.ietf.org; Wed, 23 Jan 2002 08:21:20 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 11:20:03 -0500 Message-ID: From: "Weiss, Walter" To: "'Bernard Aboba'" Cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Date: Wed, 23 Jan 2002 11:20:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > > I would have a set of issues that would prevent me from > > feasibly implementing the proposal. Many stem from the my > interpretation > > that the entire QoS policy is captured in a single 'value'. > If anything it > > reinforces my previous concerns about the approach AAA is taking to > > addressing these issues: No problem, here's a new AVP. > > Yup, that pretty much summarizes the mind-set ;) > > I'd suggest if you think that the AVP is broken or not very > useful even > for the limited set of scenarios it's trying to address, that > an issue should be filed on this. > In my opinion, this goes to the heart of the issue. Rather than the COPS and SNMP folks giving up on AAA, our collective experience has been that AAA folks have chosen not to work with the COPS and SNMP folks. The IntServ, RAP and DiffServ Groups have collectively spent at least 5 years to figure out how to support and manage QoS. Similarly, MPLS, PPP, and L2TP have spent years developing tunneling semantics. These folks have become the subject matter experts and the IETF has always taken the approach that the subject matter experts are the best folks to define the appropriate management semantics for the technology. Your comment and the fundamental standards philosophy in AAA inverts this tenant by asking all these subject matter experts to come to the AAA WG. Personally, I don't have a problem with this model per se, although it does create some scaling issues. However, this is not the way we do things today. Further, there is plenty of evidence to suggest that many folks have made substantial efforts to help the AAA group meet its objectives within the larger IETF model for developing management standards. And this is the fundamental difference between the Access Bind work and the AAA work. > > NOPE. EAP requires an extra pair of messages for challenge > negotiation. > > But COPS now does support EAP authentication as well, correct? > The protocol uses CMS and TLS for authentication. The PIB was specified to support EAP. However, in the 00 version, provided generic EAP encapsulation request and response objects. > > Network Access is implicit. In fact, there are models that > are discussed in > > the draft that allow limited Network Access policies > (specifically to HTTP > > based authentication servers) prior to full Network Access > and user specific > > policy assignments. > > How many of the other RFC 2989 requirements does the COPS/AAA > functionality satisfy? Souds like you've essentially got functionality > equivalent to Diameter NASREQ, and Accounting. Can it do Mobile IP > too? Protection of AVPs end-to-end a la CMS-Sec? > To be honest, I stopped tracking DIAMETER issues at 150, and we never went back to see how well the various requirements are supported by this work. I suppose someone may be interested in investigating it though. As to the security question, the COPS protocol supports both CMS and TLS, which provides protection both at the protocol and the object levels. From owner-rap@ops.ietf.org Wed Jan 23 11:33:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15224 for ; Wed, 23 Jan 2002 11:33:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TQIk-000FnQ-00 for rap-data@psg.com; Wed, 23 Jan 2002 08:31:06 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.33 #1) id 16TQIi-000Fmm-00; Wed, 23 Jan 2002 08:31:04 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA07906; Wed, 23 Jan 2002 08:14:44 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 23 Jan 2002 08:14:44 -0800 (PST) From: Bernard Aboba To: "Weiss, Walter" cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk > > How many of the other RFC 2989 requirements does the COPS/AAA > > functionality satisfy? Souds like you've essentially got functionality > > equivalent to Diameter NASREQ, and Accounting. Can it do Mobile IP > > too? Protection of AVPs end-to-end a la CMS-Sec? > > > To be honest, I stopped tracking DIAMETER issues at 150, and we never went > back to see how well the various requirements are supported by this work. I > suppose someone may be interested in investigating it though. As to the > security question, the COPS protocol supports both CMS and TLS, which > provides protection both at the protocol and the object levels. Well, it certainly sounds like you believe that you have developed a completely RFC 2989 compliant AAA protocol. At the least, I'd suggest that this compliance be documented for all the AAA applications that you've chosen to support. From owner-rap@ops.ietf.org Wed Jan 23 11:42:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15706 for ; Wed, 23 Jan 2002 11:42:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TQRD-000Fz9-00 for rap-data@psg.com; Wed, 23 Jan 2002 08:39:51 -0800 Received: from [64.223.136.41] (helo=hqmail01.ellacoya.com) by psg.com with esmtp (Exim 3.33 #1) id 16TQRC-000Fz3-00 for rap@ops.ietf.org; Wed, 23 Jan 2002 08:39:50 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 11:38:38 -0500 Message-ID: From: "Weiss, Walter" To: "'Bernard Aboba'" Cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'" , "Durham, David" , "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Date: Wed, 23 Jan 2002 11:38:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > Well, it certainly sounds like you believe that you have developed a > completely RFC 2989 compliant AAA protocol. At the least, I'd > suggest that > this compliance be documented for all the AAA applications that you've > chosen to support. > As I said, I don't know if we are 2989 compliant and I don't know which AAA applications are supported. The goal of the effort was to define a mechanism for binding existing QoS policy semantics to authenticated or unauthenticated users and to leverage the Feedback work to get per policy statistics. If the RAP WG or the ADs think it is important to perform a 2989 analysis, we can certainly include it in the next version. regards, -Walter From owner-rap@ops.ietf.org Wed Jan 23 12:54:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18335 for ; Wed, 23 Jan 2002 12:54:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TRXp-000Hdg-00 for rap-data@psg.com; Wed, 23 Jan 2002 09:50:45 -0800 Received: from jffdns01.or.intel.com ([134.134.248.3] helo=ganymede.or.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16TRWX-000Hb6-00 for rap@ops.ietf.org; Wed, 23 Jan 2002 09:50:44 -0800 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.48 2001/12/13 16:27:50 root Exp $) with SMTP id RAA06054 for ; Wed, 23 Jan 2002 17:49:24 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012309534827091 ; Wed, 23 Jan 2002 09:53:48 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 09:49:23 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DD51@FMSMSX34> From: "Durham, David" To: "'Weiss, Walter'" , "'Bernard Aboba'" Cc: "'Harrington, David'" , "'Wijnen, Bert (Bert)'", "'rap@ops.ietf.org'" , "'Randy Bush'" , "'David Mitton'" Subject: RE: Charter questions Date: Wed, 23 Jan 2002 09:49:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Seems the Bind PIB fulfills the requirements and architecture defined in RFC 2753, as it should. -Dave > -----Original Message----- > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > > > Well, it certainly sounds like you believe that you have developed a > > completely RFC 2989 compliant AAA protocol. At the least, I'd > > suggest that > > this compliance be documented for all the AAA applications > that you've > > chosen to support. > > > As I said, I don't know if we are 2989 compliant and I don't > know which AAA > applications are supported. The goal of the effort was to > define a mechanism > for binding existing QoS policy semantics to authenticated or > unauthenticated users and to leverage the Feedback work to > get per policy > statistics. If the RAP WG or the ADs think it is important to > perform a 2989 > analysis, we can certainly include it in the next version. > > regards, > > -Walter > From owner-rap@ops.ietf.org Thu Jan 24 04:36:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18310 for ; Thu, 24 Jan 2002 04:36:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TgFf-000Ccs-00 for rap-data@psg.com; Thu, 24 Jan 2002 01:32:59 -0800 Received: from mail01g.rapidsite.net ([207.158.192.232]) by psg.com with smtp (Exim 3.33 #1) id 16TgFd-000Ccl-00 for rap@ops.ietf.org; Thu, 24 Jan 2002 01:32:58 -0800 Received: from www.wsspl.com (209.238.114.7) by mail01g.rapidsite.net (RS ver 1.0.62s) with SMTP id 017197 for ; Thu, 24 Jan 2002 04:31:43 -0500 (EST) Received: from 134.15.15.26 [134.15.15.26] by paroksha.wsspl.com (1.61/SMTPD) at Thu, 24 Jan 02 15:04:08 India Received: by medha.wsspl.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 15:01:35 +0530 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F046872@medha.wsspl.com> X-Envelope-From: mdhara@WSSPL.com From: Muralidhar S To: "RapWG (E-mail)" Subject: Question on Encoding Framework Filters Date: Thu, 24 Jan 2002 15:01:35 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Gateway: --->> pop@GIFT - POP3/SMTP Gateway 5.5 for Exchange <<--- X-Loop-Detect: 1 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi, We have some questions regarding the encoding of extend classes defined in the Framework Pib. In draft-ietf-rap-frameworkpib-06.txt, "frwkIpFilterEntry" extends "frwkBaseFilterEntry". What method should PDP use to create an instance of "frwkIpFilterEntry"? 1) Treat "frwkIpFilterEntry" and "frwkBaseFilterEntry" as a single object and create single PRI. In this case PDP will download a single PRI for the filter. OR 2) First create "frwkBaseFilterEntry" and then create "frwkIpFilterEntry". In this case PDP will download 2 PRI for a single filter, one PRID and EPD for "frwkBaseFilterEntry" followed by PRID and EPD for "frwkIpFilterEntry" with PRID for "frwkIpFilterEntry" having the InstanceId same as base entry? murali ________________________ WebSpectrum Software Pvt. Ltd, http://www.wsspl.com ________________________ From owner-rap@ops.ietf.org Thu Jan 24 05:02:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18754 for ; Thu, 24 Jan 2002 05:02:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Tgfl-000DDR-00 for rap-data@psg.com; Thu, 24 Jan 2002 01:59:57 -0800 Received: from rumba.cefriel.it ([131.175.53.6]) by psg.com with esmtp (Exim 3.33 #1) id 16Tgfk-000DDL-00 for rap@ops.ietf.org; Thu, 24 Jan 2002 01:59:56 -0800 Received: by rumba.cefriel.it with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 11:00:31 +0100 Message-ID: <7B6D8AAF768F194EB3090A0325C8520206AB0C@rumba.cefriel.it> From: Marco De Bernardi To: "'rap@ops.ietf.org'" Subject: Question on simulation model Date: Thu, 24 Jan 2002 11:00:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hi to everybody, I'm studying COPS-PR for my master thesis. Where could I find a simulation model of COPS-PR? Or a analitical model? debernar@cefriel.it Thanks. From owner-rap@ops.ietf.org Thu Jan 24 05:11:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18897 for ; Thu, 24 Jan 2002 05:11:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Tgom-000DQr-00 for rap-data@psg.com; Thu, 24 Jan 2002 02:09:16 -0800 Received: from cs.bu.edu ([128.197.10.2]) by psg.com with esmtp (Exim 3.33 #1) id 16Tgol-000DQe-00 for rap@ops.ietf.org; Thu, 24 Jan 2002 02:09:15 -0800 Received: from csa.bu.edu (dhiman@csa [128.197.12.3]) by cs.bu.edu (8.10.1/8.10.1) with ESMTP id g0OA9DF28111; Thu, 24 Jan 2002 05:09:13 -0500 (EST) Received: (from dhiman@localhost) by csa.bu.edu (8.10.1/8.10.1) id g0OA99l22008; Thu, 24 Jan 2002 05:09:09 -0500 (EST) Date: Thu, 24 Jan 2002 05:09:09 -0500 From: Dhiman Barman To: Marco De Bernardi Cc: rap@ops.ietf.org Subject: Re: Question on simulation model Message-ID: <20020124050909.A21971@cs.bu.edu> Reply-To: dhiman@cs.bu.edu References: <7B6D8AAF768F194EB3090A0325C8520206AB0C@rumba.cefriel.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7B6D8AAF768F194EB3090A0325C8520206AB0C@rumba.cefriel.it>; from debernar@cefriel.it on Thu, Jan 24, 2002 at 11:00:29AM +0100 Sender: owner-rap@ops.ietf.org Precedence: bulk Check out Telia Labs COPS-PR implementation. Some did work on that. -Dhiman Marco De Bernardi claims the following: > Hi to everybody, > > I'm studying COPS-PR for my master thesis. Where could I find a simulation > model of COPS-PR? Or a analitical model? > > debernar@cefriel.it > Thanks. > -- Lieberman's Law: Everybody lies, but it doesn't matter since nobody listens. From owner-rap@ops.ietf.org Thu Jan 24 10:20:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23515 for ; Thu, 24 Jan 2002 10:20:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TlbT-000KJI-00 for rap-data@psg.com; Thu, 24 Jan 2002 07:15:51 -0800 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16TlbS-000KJB-00 for rap@ops.ietf.org; Thu, 24 Jan 2002 07:15:50 -0800 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.28 2002/01/02 21:40:45 root Exp $) with ESMTP id g0OFFIb20460 for ; Thu, 24 Jan 2002 15:15:18 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.11 2001/11/09 23:28:01 root Exp $) with SMTP id g0OFFNi15196 for ; Thu, 24 Jan 2002 15:15:23 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012407151906066 ; Thu, 24 Jan 2002 07:15:19 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 07:15:48 -0800 Message-ID: From: "Bell, Carol A" To: "'Muralidhar S'" , "RapWG (E-mail)" Subject: RE: Question on Encoding Framework Filters Date: Thu, 24 Jan 2002 07:15:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Murali, Method 2 is correct. --Carol -----Original Message----- From: Muralidhar S [mailto:mdhara@WSSPL.com] Sent: Thursday, January 24, 2002 1:32 AM To: RapWG (E-mail) Subject: Question on Encoding Framework Filters Hi, We have some questions regarding the encoding of extend classes defined in the Framework Pib. In draft-ietf-rap-frameworkpib-06.txt, "frwkIpFilterEntry" extends "frwkBaseFilterEntry". What method should PDP use to create an instance of "frwkIpFilterEntry"? 1) Treat "frwkIpFilterEntry" and "frwkBaseFilterEntry" as a single object and create single PRI. In this case PDP will download a single PRI for the filter. OR 2) First create "frwkBaseFilterEntry" and then create "frwkIpFilterEntry". In this case PDP will download 2 PRI for a single filter, one PRID and EPD for "frwkBaseFilterEntry" followed by PRID and EPD for "frwkIpFilterEntry" with PRID for "frwkIpFilterEntry" having the InstanceId same as base entry? murali ________________________ WebSpectrum Software Pvt. Ltd, http://www.wsspl.com ________________________ From owner-rap@ops.ietf.org Thu Jan 24 17:07:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07671 for ; Thu, 24 Jan 2002 17:07:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Trwm-0005Jy-00 for rap-data@psg.com; Thu, 24 Jan 2002 14:02:16 -0800 Received: from dhcp64-134-81-107.hat.dca.wayport.net ([64.134.81.107] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16Trwl-0005Jq-00 for rap@ops.ietf.org; Thu, 24 Jan 2002 14:02:15 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Trwk-0009oN-00 for rap@ops.ietf.org; Thu, 24 Jan 2002 17:02:14 -0500 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F046874@medha.wsspl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Muralidhar S To: "'Marco De Bernardi'" , "'rap@ops.ietf.org'" Subject: RE: Question on simulation model Date: Thu, 24 Jan 2002 16:13:22 +0530 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi, Check out intel site for "COPS Client SDK". They have a COPS-PR simulator which looks to be a useful tool to start with. murali ___________________________ WebSpectrum Software Pvt. Ltd, http://www.wsspl.com ___________________________ > -----Original Message----- > From: Marco De Bernardi [mailto:debernar@cefriel.it] > Sent: 2002. January 24. 15:30 > To: 'rap@ops.ietf.org' > Subject: Question on simulation model > > > Hi to everybody, > > I'm studying COPS-PR for my master thesis. Where could I find > a simulation > model of COPS-PR? Or a analitical model? > > debernar@cefriel.it > Thanks. > > > From owner-rap@ops.ietf.org Fri Jan 25 12:03:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07561 for ; Fri, 25 Jan 2002 12:03:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16U9jK-0002xU-00 for rap-data@psg.com; Fri, 25 Jan 2002 09:01:34 -0800 Received: from p-mail2.rd.francetelecom.com ([193.49.124.32]) by psg.com with smtp (Exim 3.33 #1) id 16U9jJ-0002xN-00 for rap@ops.ietf.org; Fri, 25 Jan 2002 09:01:33 -0800 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 17:04:20 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE34E@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "IPSEC-POLICY (E-mail)" , "RAP (E-mail)" Subject: COPS-PR and IPSec PIB implementation Date: Fri, 25 Jan 2002 17:04:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-74498d10-1169-11d6-b1e4-00508b69ab48" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-74498d10-1169-11d6-b1e4-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A5B9.F2B6BEC0" ------_=_NextPart_001_01C1A5B9.F2B6BEC0 Content-Type: text/plain; charset="iso-8859-1" Hi, We've implemented a COPS-PR prototype architecture (COPS-PR, PDP, PEP Proxies Server, in Java) for the dynamic provisioning of an IPSec-based IP VPN service offering, based on version 05 of the Framework PIB and on version 03 of the IPSec PIB drafts, respectively. We're therefore interested if any equipment vendor representative who has subscribed to this mailing list has the same kind of implementation experience (or intends to do so), and if he/she would like to share some information with us. If so, please contact me directly, and my apologies for any disturbance this message may have caused. Cheers, Pierrick. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@rd.francetelecom.com ------_=_NextPart_001_01C1A5B9.F2B6BEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable COPS-PR and IPSec PIB implementation

Hi,

We've implemented a COPS-PR = prototype architecture (COPS-PR, PDP, PEP Proxies Server, in Java) for = the dynamic provisioning of an IPSec-based IP VPN service offering, = based on version 05 of the Framework PIB and on version 03 of the IPSec = PIB drafts, respectively.

We're therefore interested if = any equipment vendor representative who has subscribed to this mailing = list has the same kind of implementation experience (or intends to do = so), and if he/she would like to share some information with = us.

If so, please contact me = directly, and my apologies for any disturbance this message may have = caused.

Cheers,

Pierrick.

Pierrick = Morand
france = telecom R&D/DMI/SIR/IPI
Tel   = : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
Email = :pierrick.morand@rd.francetelecom.com


------_=_NextPart_001_01C1A5B9.F2B6BEC0-- ------=_NextPartTM-000-74498d10-1169-11d6-b1e4-00508b69ab48-- From owner-rap@ops.ietf.org Mon Jan 28 14:11:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06180 for ; Mon, 28 Jan 2002 14:11:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VH9b-000Ed7-00 for rap-data@psg.com; Mon, 28 Jan 2002 11:09:19 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.33 #1) id 16VH9a-000Ed0-00 for rap@ops.ietf.org; Mon, 28 Jan 2002 11:09:18 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0SJAwQ10160 for ; Mon, 28 Jan 2002 13:10:59 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 28 Jan 2002 13:09:13 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 13:08:11 -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: A question about SPPI Date: Mon, 28 Jan 2002 14:08:11 -0500 Message-ID: Thread-Topic: A question about SPPI Thread-Index: AcGoLqo3Laf6mjiFRBW2exaXGoBchQ== From: To: X-OriginalArrivalTime: 28 Jan 2002 19:08:12.0053 (UTC) FILETIME=[2168CC50:01C1A82F] Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA06180 In a PIB table, some attributes can be optional. Should the UNIQUENESS clause exclude optional attributes? In other words, can a UNIQUENESS clause contain any optional attributes? Man Li From owner-rap@ops.ietf.org Tue Jan 29 03:02:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27799 for ; Tue, 29 Jan 2002 03:02:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VTC8-0005HX-00 for rap-data@psg.com; Tue, 29 Jan 2002 00:00:44 -0800 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.33 #1) id 16VTC6-0005HQ-00 for rap@ops.ietf.org; Tue, 29 Jan 2002 00:00:43 -0800 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g0T7xqw28880 for ; Tue, 29 Jan 2002 13:29:52 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GQOWWW00.A9V; Tue, 29 Jan 2002 13:30:32 +0530 Message-ID: <3C5656B5.56492A90@wipro.com> Date: Tue, 29 Jan 2002 13:30:53 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: rap@ops.ietf.org CC: scott.hahn@intel.com Subject: [Fwd: Re: Response Request: COPS PIBs standardization due-diligence feedback] Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-25f8e75f-146e-11d6-84a5-0000e2293f7c" Sender: owner-rap@ops.ietf.org Precedence: bulk ------=_NextPartTM-000-25f8e75f-146e-11d6-84a5-0000e2293f7c Content-Type: multipart/alternative; boundary="------------C1481AAE7449DD7F2CC4EFC9" --------------C1481AAE7449DD7F2CC4EFC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi, I would like to construct a policy for which the condition attribute is a range of IP addresses. e.g., 192.168.143.100 to 192.168.143.157. How can we represent this in PIB. Regards Krishna Prasad.A > > > -----Original Message----- > From: Kulkarni, Amol [mailto:amol.kulkarni@INTEL.COM] > Sent: Monday, January 21, 2002 10:30 PM > To: COPS-SDK@echo.jf.INTEL.COM > Subject: FW: Response Request: COPS PIBs standardization due-diligence > > fe edback > > Dear subscribers, > > The COPS-PR PIB standardization process is at a crucial stage. It is > important for the IESG to receive feedback from people interested in > these > PIBs. > > In case your work involves COPS/COPS-PR and PIBs, please send your > feedback > as mentioned below. > > Thanks, > Amol > > -----Original Message----- > From: Hahn, Scott [mailto:scott.hahn@intel.com] > Sent: Sunday, January 20, 2002 9:44 PM > To: 'rap@ops.ietf.org' > Subject: Response Request: COPS PIBs standardization due-diligence > feedba ck > > Subject: Response Request: COPS PIBs standardization due-diligence > feedback > > Greetings, > > Just a note to let you know the first of the COPS-PR PIBs are about to > reach > IETF RFC standards-track status. Before the IESG (The IETF's Internet > Engineering Steering Group) makes their decision on how to proceed > with PIB > standardization, they are collecting feedback about who in the > industry is > interested in the COPS-PR PIBs. > > We would like to make sure your input will be considered as part of > this > due-diligence process. This can be done by sending Brian Carpenter > , chair of the DiffServ WG, an email saying > that you > are interested in the COPS standards and COPS-PR PIBs (e.g. the > Framework, > DiffServ, IPSec, Access Control, or Accounting PIB). > > Thanks very much, > -Scott Hahn > RAP WG co-chair --------------C1481AAE7449DD7F2CC4EFC9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 
Hi,
    I would like to construct a policy for which the condition attribute is a range of IP addresses.
e.g., 192.168.143.100 to 192.168.143.157. How can we represent this in PIB.
Regards
Krishna Prasad.A
 
 

-----Original Message-----
From: Kulkarni, Amol [mailto:amol.kulkarni@INTEL.COM]
Sent: Monday, January 21, 2002 10:30 PM
To: COPS-SDK@echo.jf.INTEL.COM
Subject: FW: Response Request: COPS PIBs standardization due-diligence
fe edback

Dear subscribers,

The COPS-PR PIB standardization process is at a crucial stage. It is
important for the IESG to receive feedback from people interested in these
PIBs.

In case your work involves COPS/COPS-PR and PIBs, please send your feedback
as mentioned below.

Thanks,
Amol

-----Original Message-----
From: Hahn, Scott [mailto:scott.hahn@intel.com]
Sent: Sunday, January 20, 2002 9:44 PM
To: 'rap@ops.ietf.org'
Subject: Response Request: COPS PIBs standardization due-diligence feedba ck

Subject: Response  Request: COPS PIBs standardization due-diligence feedback

Greetings,

Just a note to let you know the first of the COPS-PR PIBs are about to reach
IETF RFC standards-track status. Before the IESG (The IETF's Internet
Engineering Steering Group) makes their decision on how to proceed with PIB
standardization, they are collecting feedback about who in the industry is
interested in the COPS-PR PIBs.

We would like to make sure your input will be considered as part of this
due-diligence process. This can be done by sending Brian Carpenter
<brian@hursley.ibm.com>, chair of the DiffServ WG, an email saying that you
are interested in the COPS standards and COPS-PR PIBs (e.g. the Framework,
DiffServ, IPSec, Access Control, or Accounting PIB).

Thanks very much,
        -Scott Hahn
        RAP WG co-chair


  --------------C1481AAE7449DD7F2CC4EFC9-- ------=_NextPartTM-000-25f8e75f-146e-11d6-84a5-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com ------=_NextPartTM-000-25f8e75f-146e-11d6-84a5-0000e2293f7c-- From owner-rap@ops.ietf.org Wed Jan 30 07:03:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15687 for ; Wed, 30 Jan 2002 07:03:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VtRX-000Ijb-00 for rap-data@psg.com; Wed, 30 Jan 2002 04:02:23 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 16VtRW-000IjV-00 for rap@ops.ietf.org; Wed, 30 Jan 2002 04:02:22 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15596; Wed, 30 Jan 2002 07:02:19 -0500 (EST) Message-Id: <200201301202.HAA15596@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-frameworkpib-07.txt Date: Wed, 30 Jan 2002 07:02:19 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework Policy Information Base Author(s) : M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-frameworkpib-07.txt Pages : 60 Date : 29-Jan-02 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined provisioning classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-07.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-rap-frameworkpib-07.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-rap-frameworkpib-07.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: <20020129135929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-frameworkpib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-frameworkpib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020129135929.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Wed Jan 30 18:51:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04956 for ; Wed, 30 Jan 2002 18:51:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W4Um-0002dG-00 for rap-data@psg.com; Wed, 30 Jan 2002 15:50:28 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16W4Ul-0002d8-00 for rap@ops.ietf.org; Wed, 30 Jan 2002 15:50:27 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id XAA15637 for ; Wed, 30 Jan 2002 23:50:25 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002013015524928870 ; Wed, 30 Jan 2002 15:52:49 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 15:50:25 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F01D027C2@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Man.M.Li@nokia.com'" , rap@ops.ietf.org Subject: RE: A question about SPPI Date: Wed, 30 Jan 2002 15:50:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Man Li, The UNIQUENESS clause itself is optional. The SPPI does not put any constraints on which attributes can be specified in this clause other than - 1. The attribute named in the PIB-INDEX clause may not be present in the UNIQUENESS clause. 2. An attribute may not appear more than once in a UNIQUENESS clause. So, yes, the UNIQUNESS clause can contain optional attributes as long as it follows the rules above. Hope that helps, Ravi -----Original Message----- From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] Sent: Monday, January 28, 2002 11:08 AM To: rap@ops.ietf.org Subject: A question about SPPI In a PIB table, some attributes can be optional. Should the UNIQUENESS clause exclude optional attributes? In other words, can a UNIQUENESS clause contain any optional attributes? Man Li From owner-rap@ops.ietf.org Thu Jan 31 04:55:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22771 for ; Thu, 31 Jan 2002 04:55:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WDtl-000GUR-00 for rap-data@psg.com; Thu, 31 Jan 2002 01:52:53 -0800 Received: from mail01g.rapidsite.net ([207.158.192.232]) by psg.com with smtp (Exim 3.33 #1) id 16WDtj-000GUL-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 01:52:52 -0800 Received: from www.wsspl.com (209.238.114.7) by mail01g.rapidsite.net (RS ver 1.0.62s) with SMTP id 04242 for ; Thu, 31 Jan 2002 04:52:32 -0500 (EST) Received: from 134.15.15.26 [134.15.15.26] by paroksha.wsspl.com (1.61/SMTPD) at Thu, 31 Jan 02 15:27:39 India Received: by medha.wsspl.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 15:27:48 +0530 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F0468A4@medha.wsspl.com> X-Envelope-From: mdhara@WSSPL.com From: Muralidhar S To: "RapWG (E-mail)" Subject: BER encoding SEQUENCE OF in PIB Date: Thu, 31 Jan 2002 15:27:48 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Gateway: --->> pop@GIFT - POP3/SMTP Gateway 5.5 for Exchange <<--- X-Loop-Detect: 1 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi, When BER encoding the PRI, do we need to encode the table ("SEQUENCE OF") or encode only the Table entry( "SEQUENCE" ) tag? murali _______________________________ WebSpectrum Software Pvt. Ltd, http://www.wsspl.com _______________________________ From owner-rap@ops.ietf.org Thu Jan 31 05:12:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22983 for ; Thu, 31 Jan 2002 05:12:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WECW-000GpO-00 for rap-data@psg.com; Thu, 31 Jan 2002 02:12:16 -0800 Received: from mail01g.rapidsite.net ([207.158.192.232]) by psg.com with smtp (Exim 3.33 #1) id 16WECV-000GpI-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 02:12:15 -0800 Received: from www.wsspl.com (209.238.114.7) by mail01g.rapidsite.net (RS ver 1.0.62s) with SMTP id 06558; Thu, 31 Jan 2002 05:11:59 -0500 (EST) Received: from 134.15.15.26 [134.15.15.26] by paroksha.wsspl.com (1.61/SMTPD) at Thu, 31 Jan 02 15:46:44 India Received: by medha.wsspl.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 15:46:53 +0530 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F0468A5@medha.wsspl.com> X-Envelope-From: mdhara@WSSPL.com From: Muralidhar S To: "RapWG (E-mail)" , "'krishna.akkineni@wipro.com'" Subject: RE: Response Request: COPS PIBs standardization due-diligence f eedback Date: Thu, 31 Jan 2002 15:46:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Gateway: --->> pop@GIFT - POP3/SMTP Gateway 5.5 for Exchange <<--- X-Loop-Detect: 1 Sender: owner-rap@ops.ietf.org Precedence: bulk Krishna Prasad, The "FrwkIpFilterEntry" in "draft-ietf-rap-frameworkpib-06.txt" defines an attribute "frwkIpFilterSrcPrefixLength". There is one for destination address also. Can we make use of this to define the range of IpAddress??. Regards murali -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: 2002. January 29. 13:31 To: rap@ops.ietf.org Cc: scott.hahn@intel.com Subject: [Fwd: Re: Response Request: COPS PIBs standardization due-diligence feedback] Hi, I would like to construct a policy for which the condition attribute is a range of IP addresses. e.g., 192.168.143.100 to 192.168.143.157. How can we represent this in PIB. Regards Krishna Prasad.A From owner-rap@ops.ietf.org Thu Jan 31 06:15:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23529 for ; Thu, 31 Jan 2002 06:15:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WFAg-000HrT-00 for rap-data@psg.com; Thu, 31 Jan 2002 03:14:26 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 16WFAf-000HrM-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 03:14:25 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 31 Jan 2002 11:17:08 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id HAA17105 for ; Thu, 31 Jan 2002 07:12:01 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 11:08:12 -0000 Message-ID: From: "Da Silva, Pedro" To: rap@ops.ietf.org Subject: RE: A question about SPPI Date: Thu, 31 Jan 2002 11:08:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Man, Ravi, The uniqueness clause also states that "The specified set of attributes provide a necessary and sufficient set of values by which to identify an instance of this PRC". As such does an optional attribute constitute a necessary one for UNIQUENESS clauses? Also, considering the case where a UNIQUENESS clause's set is composed of optional attributes only, does that constitute a sufficient set by which to identify an instance of the PRC? cheers, Pedro -----Original Message----- From: Sahita, Ravi [mailto:ravi.sahita@intel.com] Sent: Wednesday, January 30, 2002 11:50 PM To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org Subject: RE: A question about SPPI Man Li, The UNIQUENESS clause itself is optional. The SPPI does not put any constraints on which attributes can be specified in this clause other than - 1. The attribute named in the PIB-INDEX clause may not be present in the UNIQUENESS clause. 2. An attribute may not appear more than once in a UNIQUENESS clause. So, yes, the UNIQUNESS clause can contain optional attributes as long as it follows the rules above. Hope that helps, Ravi -----Original Message----- From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] Sent: Monday, January 28, 2002 11:08 AM To: rap@ops.ietf.org Subject: A question about SPPI In a PIB table, some attributes can be optional. Should the UNIQUENESS clause exclude optional attributes? In other words, can a UNIQUENESS clause contain any optional attributes? Man Li From owner-rap@ops.ietf.org Thu Jan 31 09:41:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27918 for ; Thu, 31 Jan 2002 09:41:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WIMy-000LIG-00 for rap-data@psg.com; Thu, 31 Jan 2002 06:39:20 -0800 Received: from mel.alcatel.fr ([212.208.74.132]) by psg.com with esmtp (Exim 3.33 #1) id 16WIMx-000LI9-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 06:39:19 -0800 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET) with ESMTP id g0VEdIDX014609 for ; Thu, 31 Jan 2002 15:39:18 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA04769 for ; Thu, 31 Jan 2002 15:37:34 +0100 (MET) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA18514 for ; Thu, 31 Jan 2002 15:38:29 +0100 (MET) Received: from athos.dinsunnet (athos [188.9.12.98]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA22806 for ; Thu, 31 Jan 2002 15:38:30 +0100 (MET) Received: from p50669 by athos.dinsunnet (8.9.1b+Sun/SMI-SVR4) id PAA26846; Thu, 31 Jan 2002 15:39:40 +0100 (MET) Message-ID: <00d001c1aa64$d6b08a30$caf609bc@p50669> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: References: Subject: Outsourcing and Provisioning common model Date: Thu, 31 Jan 2002 15:37:41 +0100 Organization: Alcatel R&I 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi everybody, At the last IETF meeting, Shai Herzog launched a discussion about a COPS common model merging both outsourcing and provisioning modes. The fact was that some recent drafts use COPS-PR to OUTSOURCE information towards the PDP (umts, access-bind, sls...) and the goal was to identify where the 2 modes meets and to agree on a common model. This discussion was supposed to take place on the mailing list, but... doesnt come ! Speaking as a co-author of the cops-sls draft, I'm wondering about this common model and, after all, about the future of such practises. thanks, yacine -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Next Generation Router & Cross-Connect - NGRX Marcoussis, France Tel +33 1 6963 4187 Fax +33 1 6963 1169 yacine.el_mghazli@alcatel.fr ---------------------------------------------------------------------- ----- Original Message ----- From: "Da Silva, Pedro" To: Sent: Thursday, January 31, 2002 12:08 PM Subject: RE: A question about SPPI > Man, Ravi, > > The uniqueness clause also states that "The specified set of attributes > provide a necessary and sufficient set of values by which to identify an > instance of this PRC". > As such does an optional attribute constitute a necessary one for UNIQUENESS > clauses? > Also, considering the case where a UNIQUENESS clause's set is composed of > optional attributes only, does that constitute a sufficient set by which to > identify an instance of the PRC? > > cheers, > Pedro > > > > -----Original Message----- > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > Sent: Wednesday, January 30, 2002 11:50 PM > To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org > Subject: RE: A question about SPPI > > > Man Li, > > The UNIQUENESS clause itself is optional. The SPPI does > not put any constraints on which attributes can be specified > in this clause other than - > 1. The attribute named in the PIB-INDEX clause may not be > present in the UNIQUENESS clause. > 2. An attribute may not appear more than once in a UNIQUENESS > clause. > > So, yes, the UNIQUNESS clause can contain optional attributes > as long as it follows the rules above. > > Hope that helps, > Ravi > > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > Sent: Monday, January 28, 2002 11:08 AM > To: rap@ops.ietf.org > Subject: A question about SPPI > > > In a PIB table, some attributes can be optional. Should the UNIQUENESS > clause exclude optional attributes? In other words, can a UNIQUENESS clause > contain any optional attributes? > > Man Li > From owner-rap@ops.ietf.org Thu Jan 31 10:19:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29209 for ; Thu, 31 Jan 2002 10:19:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WJ02-000M6H-00 for rap-data@psg.com; Thu, 31 Jan 2002 07:19:42 -0800 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16WJ01-000M6A-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 07:19:41 -0800 Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id PAA16736 for ; Thu, 31 Jan 2002 15:19:40 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002013107203205313 ; Thu, 31 Jan 2002 07:20:32 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 07:19:40 -0800 Message-ID: From: "Bell, Carol A" To: "'Muralidhar S'" , "RapWG (E-mail)" Subject: RE: BER encoding SEQUENCE OF in PIB Date: Thu, 31 Jan 2002 07:19:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Murali, The PRI attributes are encoded in the order defined in the PIB, each with the ASN.1 tag corresponding to the attribute type. A SEQUENCE or SEQUENCE_OF tag is not used. Check out the example in section 4.3 of the COPS-PR specification. --Carol B. -----Original Message----- From: Muralidhar S [mailto:mdhara@WSSPL.com] Sent: Thursday, January 31, 2002 1:58 AM To: RapWG (E-mail) Subject: BER encoding SEQUENCE OF in PIB Hi, When BER encoding the PRI, do we need to encode the table ("SEQUENCE OF") or encode only the Table entry( "SEQUENCE" ) tag? murali _______________________________ WebSpectrum Software Pvt. Ltd, http://www.wsspl.com _______________________________ From owner-rap@ops.ietf.org Thu Jan 31 10:29:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29595 for ; Thu, 31 Jan 2002 10:29:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WJ90-000MH0-00 for rap-data@psg.com; Thu, 31 Jan 2002 07:28:58 -0800 Received: from infres.enst.fr ([137.194.160.3]) by psg.com with esmtp (Exim 3.33 #1) id 16WJ8y-000MGt-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 07:28:57 -0800 Received: from yahoo.com (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id E70C51985 for ; Thu, 31 Jan 2002 16:28:55 +0100 (MET) Message-ID: <3C5964CB.460F1717@yahoo.com> Date: Thu, 31 Jan 2002 16:37:47 +0100 From: Nguyen Thi Mai Trang Organization: ENST - INFRES X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Re: Outsourcing and Provisioning common model References: <00d001c1aa64$d6b08a30$caf609bc@p50669> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi everybody, I'm also interested in this presentation at 52th IETF. This mode take advantage of both the dynamicity of Outsourcing mode and the flexibility of using PIB of Configuration mode. I had a question about "What type of ClientSI (Signaled ClientSI or Named ClientSI) we can use in the unifed mode?" that was supposed to discussed in the mailling list. I would like to know in COPS-UMTS, which type of ClientSI object is intended to be used? In my opinon, and also in COPS-SLS, I used Signaled ClientSI because the objective of the information in the clientSI object is signalling in despite of their form of PIB. I preferes the terminology "Using PIB in Outsourcing mode" to "Using COPS-PR in Outsourcing mode" because, for me, COPS-PR is already the provisioning mode. "Using Provisioning mode in Outsourcing mode" sounds not logic :-) What do you think about it? Thanks, Mai Trang Yacine El Mghazli wrote: > Hi everybody, > > At the last IETF meeting, Shai Herzog launched a discussion about a COPS > common model merging both outsourcing and provisioning modes. The fact was > that some recent drafts use COPS-PR to OUTSOURCE information towards the PDP > (umts, access-bind, sls...) and the goal was to identify where the 2 modes > meets and to agree on a common model. > > This discussion was supposed to take place on the mailing list, but... > doesnt come ! > > Speaking as a co-author of the cops-sls draft, I'm wondering about this > common model and, after all, about the future of such practises. > > thanks, > yacine > > -- Yacine El Mghazli > ---------------------------------------------------------------------- > Alcatel R&I > Next Generation Router & Cross-Connect - NGRX > Marcoussis, France > Tel +33 1 6963 4187 > Fax +33 1 6963 1169 > yacine.el_mghazli@alcatel.fr > ---------------------------------------------------------------------- > > ----- Original Message ----- > From: "Da Silva, Pedro" > To: > Sent: Thursday, January 31, 2002 12:08 PM > Subject: RE: A question about SPPI > > > Man, Ravi, > > > > The uniqueness clause also states that "The specified set of attributes > > provide a necessary and sufficient set of values by which to identify an > > instance of this PRC". > > As such does an optional attribute constitute a necessary one for > UNIQUENESS > > clauses? > > Also, considering the case where a UNIQUENESS clause's set is composed of > > optional attributes only, does that constitute a sufficient set by which > to > > identify an instance of the PRC? > > > > cheers, > > Pedro > > > > > > > > -----Original Message----- > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > > Sent: Wednesday, January 30, 2002 11:50 PM > > To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org > > Subject: RE: A question about SPPI > > > > > > Man Li, > > > > The UNIQUENESS clause itself is optional. The SPPI does > > not put any constraints on which attributes can be specified > > in this clause other than - > > 1. The attribute named in the PIB-INDEX clause may not be > > present in the UNIQUENESS clause. > > 2. An attribute may not appear more than once in a UNIQUENESS > > clause. > > > > So, yes, the UNIQUNESS clause can contain optional attributes > > as long as it follows the rules above. > > > > Hope that helps, > > Ravi > > > > -----Original Message----- > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > Sent: Monday, January 28, 2002 11:08 AM > > To: rap@ops.ietf.org > > Subject: A question about SPPI > > > > > > In a PIB table, some attributes can be optional. Should the UNIQUENESS > > clause exclude optional attributes? In other words, can a UNIQUENESS > clause > > contain any optional attributes? > > > > Man Li > > -- ---------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr From owner-rap@ops.ietf.org Thu Jan 31 14:39:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09518 for ; Thu, 31 Jan 2002 14:39:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WN1v-0002tP-00 for rap-data@psg.com; Thu, 31 Jan 2002 11:37:55 -0800 Received: from jffdns02.or.intel.com ([134.134.248.4] helo=hebe.or.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 16WN1u-0002tJ-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 11:37:54 -0800 Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id TAA17780 for ; Thu, 31 Jan 2002 19:37:54 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002013111423331284 ; Thu, 31 Jan 2002 11:42:33 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id <1BLHVKRM>; Thu, 31 Jan 2002 11:37:53 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F01D027CD@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Da Silva, Pedro'" , rap@ops.ietf.org Subject: RE: A question about SPPI Date: Thu, 31 Jan 2002 08:46:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Pedro, The notion of optional attributes is specific to the PIB PRC usage, and depending on that may or may not warrant inclusion of these attributes in the UNIQUENESS clause. If you have the case where a PRCs UNIQUENESS clause is composed of optional attributes only, that set may not give you a sufficient set to identify an instance uniquely, in which case the UNIQUENESS clause should be empty. Cheers, Ravi -----Original Message----- From: Da Silva, Pedro [mailto:pdasilva@orchestream.com] Sent: Thursday, January 31, 2002 3:08 AM To: rap@ops.ietf.org Subject: RE: A question about SPPI Man, Ravi, The uniqueness clause also states that "The specified set of attributes provide a necessary and sufficient set of values by which to identify an instance of this PRC". As such does an optional attribute constitute a necessary one for UNIQUENESS clauses? Also, considering the case where a UNIQUENESS clause's set is composed of optional attributes only, does that constitute a sufficient set by which to identify an instance of the PRC? cheers, Pedro -----Original Message----- From: Sahita, Ravi [mailto:ravi.sahita@intel.com] Sent: Wednesday, January 30, 2002 11:50 PM To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org Subject: RE: A question about SPPI Man Li, The UNIQUENESS clause itself is optional. The SPPI does not put any constraints on which attributes can be specified in this clause other than - 1. The attribute named in the PIB-INDEX clause may not be present in the UNIQUENESS clause. 2. An attribute may not appear more than once in a UNIQUENESS clause. So, yes, the UNIQUNESS clause can contain optional attributes as long as it follows the rules above. Hope that helps, Ravi -----Original Message----- From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] Sent: Monday, January 28, 2002 11:08 AM To: rap@ops.ietf.org Subject: A question about SPPI In a PIB table, some attributes can be optional. Should the UNIQUENESS clause exclude optional attributes? In other words, can a UNIQUENESS clause contain any optional attributes? Man Li From owner-rap@ops.ietf.org Thu Jan 31 17:10:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14065 for ; Thu, 31 Jan 2002 17:10:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WPOa-0006Uv-00 for rap-data@psg.com; Thu, 31 Jan 2002 14:09:28 -0800 Received: from [64.223.136.41] (helo=hqmail01.ellacoya.com) by psg.com with esmtp (Exim 3.33 #1) id 16WPOZ-0006Up-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 14:09:27 -0800 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2653.19) id <1BPVYKPN>; Thu, 31 Jan 2002 17:07:54 -0500 Message-ID: From: "Weiss, Walter" To: "'Nguyen Thi Mai Trang'" , rap@ops.ietf.org Subject: RE: Outsourcing and Provisioning common model Date: Thu, 31 Jan 2002 17:07:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk The notion of converging the Outsourcing and Provisioning model was first raised in the context of the Access Bind PIB. The reason was that Access Bind is in effect designed to configure/provision the criteria for signalling (outsourcing) a request to the PDP. It was explicitly designed to allow a PEP to be provisioned with both the criteria for initiating an outsource request (in our case the detection of a new session) and to also provision the PEP with the pieces of information that should be passed with the request (port, headers, etc.) The reason why normalization of Outsourcing and Provisioning was raised was because we realized that this PIB could also be used to provision a PEP to detect and notify the PDP when RSVP PATH/RESV messages were detected. What was even more interesting was that by using this PIB for RSVP outsouring, we could provide far more than just a YES or NO answer to the PEP. We could in fact use the DS and Framework PIBs to explicitly specify the QoS semantics for the reservation. Since very few switches in fact support WFQ on a per reservation basis, this allows the PDP to use the PIB Capabilities semantics to assign the optimal router components to meet the reservation requirements. As such the arguement for normalization is to take the best of both COPS and COPS-PR, and merge them together. The question is how much should this normalization depend explicitly on the Access Bind PIB? At the meeting, I believe Shai argued that he would like to see some of these concepts moved from the Access Bind PIB to the Framework PIB. regards, -Walter > -----Original Message----- > From: Nguyen Thi Mai Trang [mailto:maitrangqos@yahoo.com] > Sent: Thursday, January 31, 2002 10:38 AM > To: rap@ops.ietf.org > Subject: Re: Outsourcing and Provisioning common model > > > > Hi everybody, > > I'm also interested in this presentation at 52th IETF. This > mode take advantage > of both the dynamicity of Outsourcing mode and the > flexibility of using PIB of > Configuration mode. I had a question about "What type of > ClientSI (Signaled > ClientSI or Named ClientSI) we can use in the unifed mode?" > that was supposed to > discussed in the mailling list. > > I would like to know in COPS-UMTS, which type of ClientSI > object is intended to > be used? > > In my opinon, and also in COPS-SLS, I used Signaled ClientSI > because the > objective of the information in the clientSI object is > signalling in despite of > their form of PIB. I preferes the terminology "Using PIB in > Outsourcing mode" to > "Using COPS-PR in Outsourcing mode" because, for me, COPS-PR > is already the > provisioning mode. "Using Provisioning mode in Outsourcing > mode" sounds not > logic :-) > > What do you think about it? > Thanks, > Mai Trang > > Yacine El Mghazli wrote: > > > Hi everybody, > > > > At the last IETF meeting, Shai Herzog launched a discussion > about a COPS > > common model merging both outsourcing and provisioning > modes. The fact was > > that some recent drafts use COPS-PR to OUTSOURCE > information towards the PDP > > (umts, access-bind, sls...) and the goal was to identify > where the 2 modes > > meets and to agree on a common model. > > > > This discussion was supposed to take place on the mailing > list, but... > > doesnt come ! > > > > Speaking as a co-author of the cops-sls draft, I'm > wondering about this > > common model and, after all, about the future of such practises. > > > > thanks, > > yacine > > > > -- Yacine El Mghazli > > > ---------------------------------------------------------------------- > > Alcatel R&I > > Next Generation Router & Cross-Connect - NGRX > > Marcoussis, France > > Tel +33 1 6963 4187 > > Fax +33 1 6963 1169 > > yacine.el_mghazli@alcatel.fr > > > ---------------------------------------------------------------------- > > > > ----- Original Message ----- > > From: "Da Silva, Pedro" > > To: > > Sent: Thursday, January 31, 2002 12:08 PM > > Subject: RE: A question about SPPI > > > > > Man, Ravi, > > > > > > The uniqueness clause also states that "The specified set > of attributes > > > provide a necessary and sufficient set of values by which > to identify an > > > instance of this PRC". > > > As such does an optional attribute constitute a necessary one for > > UNIQUENESS > > > clauses? > > > Also, considering the case where a UNIQUENESS clause's > set is composed of > > > optional attributes only, does that constitute a > sufficient set by which > > to > > > identify an instance of the PRC? > > > > > > cheers, > > > Pedro > > > > > > > > > > > > -----Original Message----- > > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > > > Sent: Wednesday, January 30, 2002 11:50 PM > > > To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org > > > Subject: RE: A question about SPPI > > > > > > > > > Man Li, > > > > > > The UNIQUENESS clause itself is optional. The SPPI does > > > not put any constraints on which attributes can be specified > > > in this clause other than - > > > 1. The attribute named in the PIB-INDEX clause may not be > > > present in the UNIQUENESS clause. > > > 2. An attribute may not appear more than once in a UNIQUENESS > > > clause. > > > > > > So, yes, the UNIQUNESS clause can contain optional attributes > > > as long as it follows the rules above. > > > > > > Hope that helps, > > > Ravi > > > > > > -----Original Message----- > > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > > Sent: Monday, January 28, 2002 11:08 AM > > > To: rap@ops.ietf.org > > > Subject: A question about SPPI > > > > > > > > > In a PIB table, some attributes can be optional. Should > the UNIQUENESS > > > clause exclude optional attributes? In other words, can a > UNIQUENESS > > clause > > > contain any optional attributes? > > > > > > Man Li > > > > > -- > ---------------------------------------------------- > Nguyen Thi Mai Trang > Ecole Nationale Superieure des Telecommunications > Dept. INFRES - Bur. C234-4 > 46 Rue Barrault - 75013 Paris > Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 > email : trnguyen@enst.fr > > > From owner-rap@ops.ietf.org Thu Jan 31 18:03:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15121 for ; Thu, 31 Jan 2002 18:03:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WQEk-00084e-00 for rap-data@psg.com; Thu, 31 Jan 2002 15:03:22 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 16WQEj-00084Y-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 15:03:21 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VN3I516802; Thu, 31 Jan 2002 18:03:18 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VN3Gb09284; Thu, 31 Jan 2002 18:03:16 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8Z2W9A5; Thu, 31 Jan 2002 18:03:14 -0500 Received: from tweedy.NortelNetworks.com (artpt5r2.us.nortel.com [47.140.52.153]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DR4GJW0D; Thu, 31 Jan 2002 18:03:13 -0500 Message-Id: <5.0.0.25.0.20020131174306.02098050@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 31 Jan 2002 18:02:38 -0500 To: Nguyen Thi Mai Trang From: Kwok Ho Chan Subject: Re: Outsourcing and Provisioning common model Cc: rap@ops.ietf.org, khchan@NortelNetworks.com In-Reply-To: <3C5964CB.460F1717@yahoo.com> References: <00d001c1aa64$d6b08a30$caf609bc@p50669> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rap@ops.ietf.org Precedence: bulk In the UMTS Go PIB, we are using the Provisioning Mode. We pick this because we are thinking of a spectrum of dynamic-ness of provisioning. For example, the aggregated provisioning using the DiffServ PIB more toward the core of the network can be more static. While the per user service policy more toward the edge of the network can be more dynamic. Equipment vendors may not want to control and dictate how static/dynamic the provisioning have to be, the providers who create the services using the equipment should have flexibility on determining the degree of dynamic-ness required to create the service that fits the market the provider is in. Notice a continuous spectrum of dynamic-ness of provisioning provide a more flexible model that can be easily fitted to the service one wants to create using Policy Control. IMHO, I think this is better than a binary choice of Outsourcing/Provisioning. I have invited Shai to be a co-author of the COPS Architecture draft that I started writing to put all these together. Shai have accepted the invitation and we will be working on this shortly with couple of other co-authors. So I think this discussion on the list is good to start this process. Please provide further comments and other points of view. -- Kwok -- At 04:37 PM 1/31/02 +0100, Nguyen Thi Mai Trang wrote: >Hi everybody, > >I'm also interested in this presentation at 52th IETF. This mode take >advantage >of both the dynamicity of Outsourcing mode and the flexibility of using PIB of >Configuration mode. I had a question about "What type of ClientSI (Signaled >ClientSI or Named ClientSI) we can use in the unifed mode?" that was >supposed to >discussed in the mailling list. > >I would like to know in COPS-UMTS, which type of ClientSI object is >intended to >be used? > >In my opinon, and also in COPS-SLS, I used Signaled ClientSI because the >objective of the information in the clientSI object is signalling in >despite of >their form of PIB. I preferes the terminology "Using PIB in Outsourcing >mode" to >"Using COPS-PR in Outsourcing mode" because, for me, COPS-PR is already the >provisioning mode. "Using Provisioning mode in Outsourcing mode" sounds not >logic :-) > >What do you think about it? >Thanks, >Mai Trang > >Yacine El Mghazli wrote: > > > Hi everybody, > > > > At the last IETF meeting, Shai Herzog launched a discussion about a COPS > > common model merging both outsourcing and provisioning modes. The fact was > > that some recent drafts use COPS-PR to OUTSOURCE information towards > the PDP > > (umts, access-bind, sls...) and the goal was to identify where the 2 modes > > meets and to agree on a common model. > > > > This discussion was supposed to take place on the mailing list, but... > > doesnt come ! > > > > Speaking as a co-author of the cops-sls draft, I'm wondering about this > > common model and, after all, about the future of such practises. > > > > thanks, > > yacine > > > > -- Yacine El Mghazli > > ---------------------------------------------------------------------- > > Alcatel R&I > > Next Generation Router & Cross-Connect - NGRX > > Marcoussis, France > > Tel +33 1 6963 4187 > > Fax +33 1 6963 1169 > > yacine.el_mghazli@alcatel.fr > > ---------------------------------------------------------------------- > > > > ----- Original Message ----- > > From: "Da Silva, Pedro" > > To: > > Sent: Thursday, January 31, 2002 12:08 PM > > Subject: RE: A question about SPPI > > > > > Man, Ravi, > > > > > > The uniqueness clause also states that "The specified set of attributes > > > provide a necessary and sufficient set of values by which to identify an > > > instance of this PRC". > > > As such does an optional attribute constitute a necessary one for > > UNIQUENESS > > > clauses? > > > Also, considering the case where a UNIQUENESS clause's set is composed of > > > optional attributes only, does that constitute a sufficient set by which > > to > > > identify an instance of the PRC? > > > > > > cheers, > > > Pedro > > > > > > > > > > > > -----Original Message----- > > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > > > Sent: Wednesday, January 30, 2002 11:50 PM > > > To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org > > > Subject: RE: A question about SPPI > > > > > > > > > Man Li, > > > > > > The UNIQUENESS clause itself is optional. The SPPI does > > > not put any constraints on which attributes can be specified > > > in this clause other than - > > > 1. The attribute named in the PIB-INDEX clause may not be > > > present in the UNIQUENESS clause. > > > 2. An attribute may not appear more than once in a UNIQUENESS > > > clause. > > > > > > So, yes, the UNIQUNESS clause can contain optional attributes > > > as long as it follows the rules above. > > > > > > Hope that helps, > > > Ravi > > > > > > -----Original Message----- > > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > > Sent: Monday, January 28, 2002 11:08 AM > > > To: rap@ops.ietf.org > > > Subject: A question about SPPI > > > > > > > > > In a PIB table, some attributes can be optional. Should the UNIQUENESS > > > clause exclude optional attributes? In other words, can a UNIQUENESS > > clause > > > contain any optional attributes? > > > > > > Man Li > > > > >-- >---------------------------------------------------- >Nguyen Thi Mai Trang >Ecole Nationale Superieure des Telecommunications >Dept. INFRES - Bur. C234-4 >46 Rue Barrault - 75013 Paris >Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 >email : trnguyen@enst.fr From owner-rap@ops.ietf.org Thu Jan 31 18:10:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15244 for ; Thu, 31 Jan 2002 18:10:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WQLh-0008Hb-00 for rap-data@psg.com; Thu, 31 Jan 2002 15:10:33 -0800 Received: from [65.194.140.138] (helo=mailhost2.unispherenetworks.com) by psg.com with esmtp (Exim 3.33 #1) id 16WQLg-0008HU-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 15:10:32 -0800 Received: by mailhost2.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 18:10:31 -0500 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F04D3DC7F@mailhost2.unispherenetworks.com> From: "Moisand, Jerome" To: "'Yacine El Mghazli'" , rap@ops.ietf.org Subject: RE: Outsourcing and Provisioning common model Date: Thu, 31 Jan 2002 18:10:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Yes, agreed, Shai speech sounded right to the point to me, and it would be real nice to hear the COPS experts discuss this "common" model. 1. I'm afraid that COPS-PR will always stay controversial if it's viewed as a pure provisioning play. (please don't flame me! have mercy! ;-) 2. The outsourcing model tends to generate quite a load of traffic by having to manage each handle (and related policy objects) fully independently. Would be nice to be able to *reference* (and often share) pre-defined profiles. 3. It always made me uncomfortable to see outsourcing discussions being centered on RSVP sessions. There are many other types of sessions where outsourced dynamic decision (at session establishment, during its "life", or at deletion) could be very useful. Think RSVP but also PPP, EAP, DHCP, IGMP, IPSec associations, all sorts of tunnels, LSPs, etc. Also possibly routing protocols adjacencies, etc. Anything which is signaling-oriented. As well as various objects configured in a more static way in nature (e.g. SNMP or the dreaded CLI ;-), but still requiring dynamic policing in a transaction-oriented way. Now when you think to a merged model, where various things intended to be shared can be provisioned in advance or 'just in time' via COPS-PR via a "coarse-grain" handle, and referenced by decisions made on more dynamic and fine-grain objects (handles in the outsourced model), then the whole picture is becoming WAY more attractive. At least for me... I suspect that technically speaking, we are actually close to such 'merged' behavior, notably with the new framework PIB, simply it seems to never be discussed or illustrated in tutorial/educational/examples material. So putting all these thoughts together, yes, would be nice to see this thread of discussion more active... and possibly captured in the updated policy management framework/umbrella document that the WG recently initiated. Jerome -----Original Message----- From: Yacine El Mghazli [mailto:yacine.elmghazli@ms.alcatel.fr] Sent: Thursday, January 31, 2002 9:38 AM To: rap@ops.ietf.org Subject: Outsourcing and Provisioning common model Hi everybody, At the last IETF meeting, Shai Herzog launched a discussion about a COPS common model merging both outsourcing and provisioning modes. The fact was that some recent drafts use COPS-PR to OUTSOURCE information towards the PDP (umts, access-bind, sls...) and the goal was to identify where the 2 modes meets and to agree on a common model. This discussion was supposed to take place on the mailing list, but... doesnt come ! Speaking as a co-author of the cops-sls draft, I'm wondering about this common model and, after all, about the future of such practises. thanks, yacine -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Next Generation Router & Cross-Connect - NGRX Marcoussis, France Tel +33 1 6963 4187 Fax +33 1 6963 1169 yacine.el_mghazli@alcatel.fr ---------------------------------------------------------------------- ----- Original Message ----- From: "Da Silva, Pedro" To: Sent: Thursday, January 31, 2002 12:08 PM Subject: RE: A question about SPPI > Man, Ravi, > > The uniqueness clause also states that "The specified set of attributes > provide a necessary and sufficient set of values by which to identify an > instance of this PRC". > As such does an optional attribute constitute a necessary one for UNIQUENESS > clauses? > Also, considering the case where a UNIQUENESS clause's set is composed of > optional attributes only, does that constitute a sufficient set by which to > identify an instance of the PRC? > > cheers, > Pedro > > > > -----Original Message----- > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > Sent: Wednesday, January 30, 2002 11:50 PM > To: 'Man.M.Li@nokia.com'; rap@ops.ietf.org > Subject: RE: A question about SPPI > > > Man Li, > > The UNIQUENESS clause itself is optional. The SPPI does > not put any constraints on which attributes can be specified > in this clause other than - > 1. The attribute named in the PIB-INDEX clause may not be > present in the UNIQUENESS clause. > 2. An attribute may not appear more than once in a UNIQUENESS > clause. > > So, yes, the UNIQUNESS clause can contain optional attributes > as long as it follows the rules above. > > Hope that helps, > Ravi > > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > Sent: Monday, January 28, 2002 11:08 AM > To: rap@ops.ietf.org > Subject: A question about SPPI > > > In a PIB table, some attributes can be optional. Should the UNIQUENESS > clause exclude optional attributes? In other words, can a UNIQUENESS clause > contain any optional attributes? > > Man Li > From owner-rap@ops.ietf.org Thu Jan 31 20:37:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17150 for ; Thu, 31 Jan 2002 20:37:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WSdH-000Cd1-00 for rap-data@psg.com; Thu, 31 Jan 2002 17:36:51 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.33 #1) id 16WSdC-000Cct-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 17:36:50 -0800 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g111cSQ04888 for ; Thu, 31 Jan 2002 19:38:28 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 31 Jan 2002 19:36:45 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 19:36:44 -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: Outsourcing and Provisioning common model Date: Thu, 31 Jan 2002 20:36:43 -0500 Message-ID: Thread-Topic: Outsourcing and Provisioning common model Thread-Index: AcGqrS7Fow+JukSyRtGq3FCTPKCodAACCZ2g From: To: , , X-OriginalArrivalTime: 01 Feb 2002 01:36:45.0005 (UTC) FILETIME=[E84037D0:01C1AAC0] Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA17150 Hi, If I understand it correctly, 3GPP would like to use COPS-PR for the GO interface and they have a tight schedule for their next release. If we keep on changing the COPS protocols, is it possible that people who are friendly with COPS will pick up an alternative solution (SNMP or even Radius) simply for stability reasons. By the time we come up with a perfect COPS solution, many have already stood behind other protocols. This applies not only to folks in 3GPP but also to those who are interested in using COPS for policy management. Timing may be everything for gaining market recognition. Without market share, what is a perfect solution good for? Man From owner-rap@ops.ietf.org Thu Jan 31 23:23:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21192 for ; Thu, 31 Jan 2002 23:23:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WVDa-000Jna-00 for rap-data@psg.com; Thu, 31 Jan 2002 20:22:30 -0800 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.33 #1) id 16WVDY-000JnT-00 for rap@ops.ietf.org; Thu, 31 Jan 2002 20:22:29 -0800 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g114Ldw05079 for ; Fri, 1 Feb 2002 09:51:39 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GQU6T400.RFX; Fri, 1 Feb 2002 09:52:19 +0530 Message-ID: <3C5A1812.CBBC0621@wipro.com> Date: Fri, 01 Feb 2002 09:52:42 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: Muralidhar S CC: "RapWG (E-mail)" Subject: Re: Response Request: COPS PIBs standardization due-diligence feedback References: <30BFDEA66FF4D41191EB00D0B765BC6F0468A5@medha.wsspl.com> Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b4d63dd3-1684-11d6-84a5-0000e2293f7c" Sender: owner-rap@ops.ietf.org Precedence: bulk ------=_NextPartTM-000-b4d63dd3-1684-11d6-84a5-0000e2293f7c Content-Type: multipart/alternative; boundary="------------E8089F0645FA436D9BF8AB1B" --------------E8089F0645FA436D9BF8AB1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This frwkIpFilterSrcPrefixLength got added from draft-ietf-rap-frameworkpib-06.txt. It looks like IP range representation can be made using this. But I do not know how exactly? Could any one please explain more about frwkIpFilterSrcPrefixLength Regards kp Muralidhar S wrote: > Krishna Prasad, > > The "FrwkIpFilterEntry" in "draft-ietf-rap-frameworkpib-06.txt" defines an > attribute > "frwkIpFilterSrcPrefixLength". There is one for destination address also. > Can we make > use of this to define the range of IpAddress??. > > Regards > murali > > -----Original Message----- > From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] > Sent: 2002. January 29. 13:31 > To: rap@ops.ietf.org > Cc: scott.hahn@intel.com > Subject: [Fwd: Re: Response Request: COPS PIBs standardization due-diligence > feedback] > > Hi, > I would like to construct a policy for which the condition attribute is > a range of IP addresses. > e.g., 192.168.143.100 to 192.168.143.157. How can we represent this in PIB. > Regards > Krishna Prasad.A > --------------E8089F0645FA436D9BF8AB1B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
    This frwkIpFilterSrcPrefixLength got added from  draft-ietf-rap-frameworkpib-06.txt.
It looks like IP range representation can be made using this. But I do not know how exactly?
Could any one please explain more about frwkIpFilterSrcPrefixLength
Regards
kp
 

Muralidhar S wrote:

Krishna Prasad,

The  "FrwkIpFilterEntry" in  "draft-ietf-rap-frameworkpib-06.txt" defines an
attribute
"frwkIpFilterSrcPrefixLength". There is one for destination address also.
Can we make
use of this to define the range of IpAddress??.

Regards
murali

-----Original Message-----
From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com]
Sent: 2002. January 29. 13:31
To: rap@ops.ietf.org
Cc: scott.hahn@intel.com
Subject: [Fwd: Re: Response Request: COPS PIBs standardization due-diligence
feedback]

Hi,
    I would like to construct a policy for which the condition attribute is
a range of IP addresses.
e.g., 192.168.143.100 to 192.168.143.157. How can we represent this in PIB.
Regards
Krishna Prasad.A
 


 
  --------------E8089F0645FA436D9BF8AB1B-- ------=_NextPartTM-000-b4d63dd3-1684-11d6-84a5-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-b4d63dd3-1684-11d6-84a5-0000e2293f7c--