From owner-rap@ops.ietf.org Thu Mar 1 07:22:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01199 for ; Thu, 1 Mar 2001 07:22:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YS5m-000PC1-00 for rap-data@psg.com; Thu, 01 Mar 2001 04:21:58 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14YS5l-000PBv-00 for rap@ops.ietf.org; Thu, 01 Mar 2001 04:21:57 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01083; Thu, 1 Mar 2001 07:21:55 -0500 (EST) Message-Id: <200103011221.HAA01083@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-cops-tls-00.txt Date: Thu, 01 Mar 2001 07:21:55 -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 : COPS Over TLS Author(s) : J. Walker, A. Kulkarni Filename : draft-ietf-rap-cops-tls-00.txt Pages : 7 Date : 28-Feb-01 This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt 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-cops-tls-00.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-cops-tls-00.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: <20010228150401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228150401.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Mar 1 08:32:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03114 for ; Thu, 1 Mar 2001 08:32:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YTBc-000165-00 for rap-data@psg.com; Thu, 01 Mar 2001 05:32:04 -0800 Received: from menelao.polito.it ([130.192.3.30]) by psg.com with smtp (Exim 3.16 #1) id 14YTBb-00015z-00 for rap@ops.ietf.org; Thu, 01 Mar 2001 05:32:03 -0800 Received: (qmail 25525 invoked from network); 1 Mar 2001 13:32:00 -0000 Received: from bagigio.polito.it (HELO polito.it) (130.192.31.16) by menelao.polito.it with SMTP; 1 Mar 2001 13:32:00 -0000 Message-ID: <3A9E4E1B.3AC37029@polito.it> Date: Thu, 01 Mar 2001 14:26:51 +0100 From: Riccardo Scandariato Reply-To: riccardo@athena.polito.it Organization: Politecnico di Torino (http://www.polito.it) X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,it MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Question about COPS-PR model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If I well understood COPS and COPS-PR, the first bases on a "bottom-up" model where events arrive from the network (e.g. a RSVP req.), while the second bases on a "top-down" model where events arrive from a control system (e.g. a user interacting with a Web interface, or net-admin operations). The question is: how can I arrange a scenario where events arrive from both the control system and the network (e.g. a user dialing in an access router)? FOR EXAMPLE, let us think to an hypothetical "Security Client-Type". Let us suppose a router that must forward incoming traffic to many outgoing tunnels. The router is placed at the border of a network cloud and traffic arrives from statically attached sites. In my opinion, this is a typical COPS-PR scenario: - first I assign different labels (i.e. Roles) to incoming interfaces (i.e. the attachment points) - second, the router install a request-state (after having opened a COPS session) - third PDP asynchronously pushes the right PRIs (creation of outgoing tunnels, forwarding rules relative to existent roles). But what about a user that dials in the router? In this case user traffic must be directed to the correct tunnel on per-user basis. I guess the PEP should ask the PDP for a decision (which in turn can interrogate e.g. a radius server). How can I manage this issue in COPS-PR? Can the PEP install a new request state? I would like WG opinion on this point. Regards, Riccardo Scandariato From owner-rap@ops.ietf.org Thu Mar 1 16:17:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23559 for ; Thu, 1 Mar 2001 16:17:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YaPd-000E36-00 for rap-data@psg.com; Thu, 01 Mar 2001 13:15:01 -0800 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.ca.nortel.com) by psg.com with esmtp (Exim 3.16 #1) id 14YaPb-000E1J-00 for rap@ops.ietf.org; Thu, 01 Mar 2001 13:15:00 -0800 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 1 Mar 2001 16:08:42 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDBXKTCF; Thu, 1 Mar 2001 16:08:41 -0500 Received: from tweedy (dhcp223-145.engeast.baynetworks.com [192.32.223.145]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id FT3AATJJ; Thu, 1 Mar 2001 16:08:39 -0500 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 01 Mar 2001 16:05:40 -0500 To: "Rawlins, Diana" X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: 'Subject-Categories' Discussion, was RE: I-D ACTION:draft-ietf-rap-sppi-05.txt Cc: rap@ops.ietf.org, "Kwok-Ho Chan" In-Reply-To: <492EB4A3F68CD411ABE800508B69362E31A45C@RIPEXCH002.wcomnet. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Message-Id: Sender: owner-rap@ops.ietf.org Precedence: bulk Diana: Hopefully the following reply will help. Please let me know if more clarification is needed. You pointed out a good issue which the co-author assumed to be handled by IANA. An IANA Consideration section will be added to the DiffServ PIB draft (and other PIB drafts in the future) to describe how this assignment is done. Please provide comments or better ways of doing this. Thanks! -- Kwok -- At 06:46 PM 2/26/01 +0000, Rawlins, Diana wrote: >I have a couple of questions/comments which are focused on >Section 7.1 "Mapping of the SUBJECT-CATEGORIES clause." > >What is the value of the COPS Header Client Type for a client >connection of SUBJECT-CATEGORY QOS? Will this be the equal to >the CATEGORY ID value of the DiffServ PIB? Yes, this is indicated by the SUBJECT-CATEGORIES at the top of the DiffServ PIB module. Currently the value is TBD. We envision this will be an IANA assigned number space. > >How are additional technology specific PIBs added to a client >type applications? Are they assigned the same CATEGORY ID? How >would an Accounting Usage PIB for the DiffServ be added to the >DiffServ QoS Client Type application? I think the Accounting PRCs specific to DiffServ should use the same SUBJECT-CATEGORY as the one used for the DiffServ PIB (QoS). But the PRC name/number space need to be coordinated with other PIB modules using QoS Subject-Category. > >What is the Category ID for SUBJECT-CATEGORIES QoS? Where is >the category to client type mapping defined? Will it be called >out in the individual PIB drafts? (Not finding that type of >information in the current DiffServ PIB 02.) > >Quoting more from 7.1, "The namespace for these named numbers >is global and therefore the labels should be assigned >consistently across PIB modules. At present time, no more >than one named-number enumeration should be specified." > >What organization is managing the global name space for the >CATEGORY IDS? Where does one go to set this up or find out >the mappings? Current thinking is this gets assigned by IANA, but any suggestions are welcomed. > >Thanks, >Diana > > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Friday, February 23, 2001 5:45 AM >Cc: rap@ops.ietf.org >Subject: I-D ACTION:draft-ietf-rap-sppi-05.txt > > >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 : Structure of Policy Provisioning Information >(SPPI) > Author(s) : K. McCloghrie, M. Fine, J. Seligson, > K. Chan, S. Hahn, R. Sahita, A. Smith, > F. Reichmeyer > Filename : draft-ietf-rap-sppi-05.txt > Pages : 42 > Date : 22-Feb-01 > >RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] >describes how the COPS protocol is used to provide for the outsourcing >of policy decisions for RSVP. Another usage of the COPS protocol, for >the provisioning of policy, is introduced in [COPS-PR]. In this >provisioning model, the policy information is viewed as a collection of >Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing >in a virtual information store, termed the Policy Information Base >(PIB). Collections of related Provisioning Classes are defined in a PIB >module. PIB modules are written using an adapted subset of SNMP's >Structure of Management Information (SMI) [SMI, TC, CONF]. It is the >purpose of this document, the Structure of Policy Provisioning >Information (SPPI), to define that adapted subset > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt > >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-sppi-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-rap-sppi-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > From owner-rap@ops.ietf.org Thu Mar 1 17:12:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25968 for ; Thu, 1 Mar 2001 17:12:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YbID-000Fxn-00 for rap-data@psg.com; Thu, 01 Mar 2001 14:11:25 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14YbIC-000FxO-00 for rap@ops.ietf.org; Thu, 01 Mar 2001 14:11:24 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G9J00M5BHK8R9@firewall.mcit.com> for rap@ops.ietf.org; Thu, 1 Mar 2001 22:09:44 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9J00I01HK2A5@pmismtp02.wcomnet.com>; Thu, 01 Mar 2001 22:09:44 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9J00H1CHJURA@pmismtp02.wcomnet.com>; Thu, 01 Mar 2001 22:09:30 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 01 Mar 2001 22:09:30 +0000 Content-return: allowed Date: Thu, 01 Mar 2001 22:09:28 +0000 From: "Rawlins, Diana" Subject: RE: 'Subject-Categories' Discussion, was RE: I-D ACTION:draft-iet f-rap-sppi-05.txt To: "'Kwok-Ho Chan'" Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A4B6@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Kwok, The clarification helped! I look forward to learning the COPS client type and SUBJECT CATEGORY ID for the QoS PIB in the future DiffServ PIB draft. Thanks! Diana -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Thursday, March 01, 2001 3:06 PM To: Rawlins, Diana Cc: rap@ops.ietf.org; Kwok-Ho Chan Subject: 'Subject-Categories' Discussion, was RE: I-D ACTION:draft-ietf-rap-sppi-05.txt Diana: Hopefully the following reply will help. Please let me know if more clarification is needed. You pointed out a good issue which the co-author assumed to be handled by IANA. An IANA Consideration section will be added to the DiffServ PIB draft (and other PIB drafts in the future) to describe how this assignment is done. Please provide comments or better ways of doing this. Thanks! -- Kwok -- At 06:46 PM 2/26/01 +0000, Rawlins, Diana wrote: >I have a couple of questions/comments which are focused on >Section 7.1 "Mapping of the SUBJECT-CATEGORIES clause." > >What is the value of the COPS Header Client Type for a client >connection of SUBJECT-CATEGORY QOS? Will this be the equal to >the CATEGORY ID value of the DiffServ PIB? Yes, this is indicated by the SUBJECT-CATEGORIES at the top of the DiffServ PIB module. Currently the value is TBD. We envision this will be an IANA assigned number space. > >How are additional technology specific PIBs added to a client >type applications? Are they assigned the same CATEGORY ID? How >would an Accounting Usage PIB for the DiffServ be added to the >DiffServ QoS Client Type application? I think the Accounting PRCs specific to DiffServ should use the same SUBJECT-CATEGORY as the one used for the DiffServ PIB (QoS). But the PRC name/number space need to be coordinated with other PIB modules using QoS Subject-Category. > >What is the Category ID for SUBJECT-CATEGORIES QoS? Where is >the category to client type mapping defined? Will it be called >out in the individual PIB drafts? (Not finding that type of >information in the current DiffServ PIB 02.) > >Quoting more from 7.1, "The namespace for these named numbers >is global and therefore the labels should be assigned >consistently across PIB modules. At present time, no more >than one named-number enumeration should be specified." > >What organization is managing the global name space for the >CATEGORY IDS? Where does one go to set this up or find out >the mappings? Current thinking is this gets assigned by IANA, but any suggestions are welcomed. > >Thanks, >Diana > > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Friday, February 23, 2001 5:45 AM >Cc: rap@ops.ietf.org >Subject: I-D ACTION:draft-ietf-rap-sppi-05.txt > > >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 : Structure of Policy Provisioning Information >(SPPI) > Author(s) : K. McCloghrie, M. Fine, J. Seligson, > K. Chan, S. Hahn, R. Sahita, A. Smith, > F. Reichmeyer > Filename : draft-ietf-rap-sppi-05.txt > Pages : 42 > Date : 22-Feb-01 > >RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] >describes how the COPS protocol is used to provide for the outsourcing >of policy decisions for RSVP. Another usage of the COPS protocol, for >the provisioning of policy, is introduced in [COPS-PR]. In this >provisioning model, the policy information is viewed as a collection of >Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing >in a virtual information store, termed the Policy Information Base >(PIB). Collections of related Provisioning Classes are defined in a PIB >module. PIB modules are written using an adapted subset of SNMP's >Structure of Management Information (SMI) [SMI, TC, CONF]. It is the >purpose of this document, the Structure of Policy Provisioning >Information (SPPI), to define that adapted subset > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt > >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-sppi-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-rap-sppi-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > From owner-rap@ops.ietf.org Thu Mar 1 19:51:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00035 for ; Thu, 1 Mar 2001 19:51:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YdlL-000M6j-00 for rap-data@psg.com; Thu, 01 Mar 2001 16:49:39 -0800 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by psg.com with esmtp (Exim 3.16 #1) id 14YdlK-000M4j-00 for rap@ops.ietf.org; Thu, 01 Mar 2001 16:49:38 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0G9J00B3BOXT9E@firewall.mcit.com> for rap@ops.ietf.org; Fri, 2 Mar 2001 00:49:05 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9J00001OXSXB@pmismtp02.wcomnet.com>; Fri, 02 Mar 2001 00:49:05 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9J00ICLOXGQX@pmismtp02.wcomnet.com>; Fri, 02 Mar 2001 00:48:52 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Fri, 02 Mar 2001 00:48:52 +0000 Content-return: allowed Date: Fri, 02 Mar 2001 00:48:50 +0000 From: "Rawlins, Diana" Subject: RE: Question about COPS-PR model To: "'riccardo@athena.polito.it'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A4BD@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Riccardo, Please see below for my thoughts on the PPP (or whatever dial up) service. -Diana -----Original Message----- From: Riccardo Scandariato [mailto:riccardo.scandariato@polito.it] Sent: Thursday, March 01, 2001 7:27 AM To: rap@ops.ietf.org Subject: Question about COPS-PR model If I well understood COPS and COPS-PR, the first bases on a "bottom-up" model where events arrive from the network (e.g. a RSVP req.), while the second bases on a "top-down" model where events arrive from a control system (e.g. a user interacting with a Web interface, or net-admin operations). The question is: how can I arrange a scenario where events arrive from both the control system and the network (e.g. a user dialing in an access router)? FOR EXAMPLE, let us think to an hypothetical "Security Client-Type". Let us suppose a router that must forward incoming traffic to many outgoing tunnels. The router is placed at the border of a network cloud and traffic arrives from statically attached sites. In my opinion, this is a typical COPS-PR scenario: - first I assign different labels (i.e. Roles) to incoming interfaces (i.e. the attachment points) - second, the router install a request-state (after having opened a COPS session) - third PDP asynchronously pushes the right PRIs (creation of outgoing tunnels, forwarding rules relative to existent roles). But what about a user that dials in the router? In this case user traffic must be directed to the correct tunnel on per-user basis. I guess the PEP should ask the PDP for a decision (which in turn can interrogate e.g. a radius server). How can I manage this issue in COPS-PR? Can the PEP install a new request state? >>>djr The router detects an event "dial in". It outsources a REQ to PDP and the PDP goes off to the radius server and then returns a DEC to the PEP about the correct tunnel. This scenario is a new client type with specific signaled clientSI objects defined. Another approach to avoid the outsoarcing is to develop a model, say, "dial in" model. Develop a PIB that based on the model's semantics that can be pushed to the PEP with COPS-PR. Just some thoughts. I would like WG opinion on this point. Regards, Riccardo Scandariato From owner-rap@ops.ietf.org Thu Mar 1 21:11:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01550 for ; Thu, 1 Mar 2001 21:11:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Yf18-000OdO-00 for rap-data@psg.com; Thu, 01 Mar 2001 18:10:02 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14Yf17-000OdB-00 for rap@ops.ietf.org; Thu, 01 Mar 2001 18:10:01 -0800 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id CAA29431 for ; Fri, 2 Mar 2001 02:10:00 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 02 Mar 2001 02:10:00 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Mar 2001 18:09:59 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E8904E959C@orsmsx35.jf.intel.com> From: "Hegde, Shriharsha" To: rap@ops.ietf.org Subject: FW: I-D ACTION:draft-hegde-load-balancing-pib-00.txt Date: Thu, 1 Mar 2001 18:09:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A2BD.E15A8B20" 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_000_01C0A2BD.E15A8B20 Content-Type: text/plain; charset="iso-8859-1" Hi, This internet draft is a PIB for configuring/managing a load balancer using COPS-PR protocol. Though this is not a work item of RAP WG, there is substantial interest in using COPS-PR and PIB approach to configure/manage various networking devices and hope to get feedback from interested folks. regards, harsha -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 28, 2001 3:57 AM Subject: I-D ACTION:draft-hegde-load-balancing-pib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Load Balancing Policy Information Base Author(s) : H. Hegde, B. Stone Filename : draft-hegde-load-balancing-pib-00.txt Pages : 17 Date : 27-Feb-01 This document specifies a set of provisioning classes (PRC) for configuring load balancing at load balancing devices. Instances of these classes reside in a virtual information store called Load Balancing Policy Information Base (PIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hegde-load-balancing-pib-00.txt 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-hegde-load-balancing-pib-00.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-hegde-load-balancing-pib-00.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_000_01C0A2BD.E15A8B20 Content-Type: message/rfc822 To: Subject: Date: Thu, 1 Mar 2001 18:09:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0A2BD.E15A8B20" ------_=_NextPart_002_01C0A2BD.E15A8B20 Content-Type: text/plain ------_=_NextPart_002_01C0A2BD.E15A8B20 Content-Type: application/octet-stream; name="ATT35283" Content-Disposition: attachment; filename="ATT35283" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227123658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hegde-load-balancing-pib-00.txt ------_=_NextPart_002_01C0A2BD.E15A8B20 Content-Type: message/external-body; site="internet-drafts"; dir="draft-hegde-load-balancing-pib-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0A2BD.E15A8B20-- ------_=_NextPart_000_01C0A2BD.E15A8B20-- From owner-rap@ops.ietf.org Mon Mar 5 05:24:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09952 for ; Mon, 5 Mar 2001 05:24:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Zs9H-0005vY-00 for rap-data@psg.com; Mon, 05 Mar 2001 02:23:27 -0800 Received: from p-mail2.rd.francetelecom.fr ([193.49.124.32] helo=p-mail2.cnet.fr) by psg.com with smtp (Exim 3.16 #1) id 14Zs9G-0005tv-00 for rap@ops.ietf.org; Mon, 05 Mar 2001 02:23:27 -0800 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Mar 2001 11:20:19 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82ED5A4C@lat3721.rd.francetelecom.fr> From: JACQUENET Christian FTRD/DMI/CAE To: "'Andrew Smith (co-chair rap)'" , "'Mark Stevens (co-chair rap)'" Cc: "'rap@ops.ietf.org'" Subject: draft-jacquenet-ip-te-cops-01.txt Date: Mon, 5 Mar 2001 11:17:54 +0100 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 Dear all, FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A COPS client-type for IP traffic engineering Author(s) : C. Jacquenet Filename : draft-jacquenet-ip-te-cops-01.txt Pages : 14 Date : 01-Mar-01 This draft specifies a COPS (Common Open Policy Service, [2])client- type designed for the enforcement of IP Traffic Engineering (IP TE) policies within IP networks. The usage of this IP TE COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes (COPS-PR, [3]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt Depending on the current rap agenda for the Minneapolis meeting, would it be possible to get allocated a 10-minute slot for a presentation of this draft? Comments on this spec are warmly welcome. Cheers, Christian. From owner-rap@ops.ietf.org Tue Mar 6 05:49:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06459 for ; Tue, 6 Mar 2001 05:49:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aF0R-000PTB-00 for rap-data@psg.com; Tue, 06 Mar 2001 02:47:51 -0800 Received: from mel.alcatel.fr ([212.208.74.132]) by psg.com with esmtp (Exim 3.16 #1) id 14aF0Q-000PSx-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 02:47:50 -0800 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id LAA18964; Tue, 6 Mar 2001 11:43:24 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA14043; Tue, 6 Mar 2001 11:42:21 +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 LAA16055; Tue, 6 Mar 2001 11:47:33 +0100 (MET) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id LAA12084; Tue, 6 Mar 2001 11:47:37 +0100 (MET) Message-ID: <010e01c0a62a$a1df0a00$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: "JACQUENET Christian FTRD/DMI/CAE" Cc: References: <91A311FF6A85D3118DDF0060080C3D82ED5A4C@lat3721.rd.francetelecom.fr> Subject: Re: draft-jacquenet-ip-te-cops-01.txt Date: Tue, 6 Mar 2001 11:45:59 +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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, Why do you use a new client type for provisioning purposes instead of the already existing COPS-PR one ? What prevent you from using the normal provisioning scheme ? I'm sure you have any good reason but I can't get it, I'm not a routing/TE expert ! Thanx Yacine ----- Original Message ----- From: "JACQUENET Christian FTRD/DMI/CAE" To: "'Andrew Smith (co-chair rap)'" ; "'Mark Stevens (co-chair rap)'" Cc: Sent: Monday, March 05, 2001 11:17 AM Subject: draft-jacquenet-ip-te-cops-01.txt > Dear all, > > FYI: A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A COPS client-type for IP traffic engineering > Author(s) : C. Jacquenet > Filename : draft-jacquenet-ip-te-cops-01.txt > Pages : 14 > Date : 01-Mar-01 > > This draft specifies a COPS (Common Open Policy Service, [2])client- > type designed for the enforcement of IP Traffic Engineering (IP TE) > policies within IP networks. The usage of this IP TE COPS client-type > is based upon the activation of the COPS protocol for policy > provisioning purposes (COPS-PR, [3]). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt > > Depending on the current rap agenda for the Minneapolis meeting, would it be > possible to get allocated a 10-minute slot for a presentation of this draft? > > Comments on this spec are warmly welcome. > > Cheers, > > Christian. > > > From owner-rap@ops.ietf.org Tue Mar 6 06:53:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08239 for ; Tue, 6 Mar 2001 06:53:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aG06-0001Gs-00 for rap-data@psg.com; Tue, 06 Mar 2001 03:51:34 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14aG04-0001Gi-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 03:51:33 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07960; Tue, 6 Mar 2001 06:51:30 -0500 (EST) Message-Id: <200103061151.GAA07960@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-04.txt Date: Tue, 06 Mar 2001 06:51:30 -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-04.txt Pages : 43 Date : 05-Mar-01 [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-04.txt 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-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-frameworkpib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010305132149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-frameworkpib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-frameworkpib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132149.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue Mar 6 07:49:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09801 for ; Tue, 6 Mar 2001 07:49:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aGti-0002xF-00 for rap-data@psg.com; Tue, 06 Mar 2001 04:49:02 -0800 Received: from p-mail2.rd.francetelecom.fr ([193.49.124.32] helo=p-mail2.cnet.fr) by psg.com with smtp (Exim 3.16 #1) id 14aGth-0002vm-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 04:49:01 -0800 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Mar 2001 13:48:10 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82ED5A61@lat3721.rd.francetelecom.fr> From: JACQUENET Christian FTRD/DMI/CAE To: "'Yacine El Mghazli'" Cc: rap@ops.ietf.org Subject: RE: draft-jacquenet-ip-te-cops-01.txt Date: Tue, 6 Mar 2001 13:45:50 +0100 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA09801 Yacine, I'm not sure I understand your question, but, according to section 1 of draft-ietf-rap-pr-05.txt: "In order to support a model that includes multiple PDPs controlling non-overlapping areas of policy on a single PEP, the client-type specified by the PEP to the PDP is unique for the area of policy being managed. A single client-type for a given area of policy (eg. QoS) will be used for all PIBs that exist in that area. The client should treat all the COPS-PR client-types it supports as non-overlapping and independent namespaces where instances MUST NOT be shared." From this standpoint, draft-jacquenet-ip-te-cops-01.txt considers the case of enforcing an IP TE policy (i.e. a specific area of policy, among QoS, security, routing, etc.), thus yielding the need for the definition of a specific client-type that should be treated by a PEP, amongst all the COPS-PR client-types that are currently or will be defined. Did I answer your question? Thank you for your comment. Cheers, Christian. -----Message d'origine----- De : Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Envoyé : mardi 6 mars 2001 11:46 À : JACQUENET Christian FTRD/DMI/CAE Cc : rap@ops.ietf.org Objet : Re: draft-jacquenet-ip-te-cops-01.txt Christian, Why do you use a new client type for provisioning purposes instead of the already existing COPS-PR one ? What prevent you from using the normal provisioning scheme ? I'm sure you have any good reason but I can't get it, I'm not a routing/TE expert ! Thanx Yacine ----- Original Message ----- From: "JACQUENET Christian FTRD/DMI/CAE" To: "'Andrew Smith (co-chair rap)'" ; "'Mark Stevens (co-chair rap)'" Cc: Sent: Monday, March 05, 2001 11:17 AM Subject: draft-jacquenet-ip-te-cops-01.txt > Dear all, > > FYI: A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A COPS client-type for IP traffic engineering > Author(s) : C. Jacquenet > Filename : draft-jacquenet-ip-te-cops-01.txt > Pages : 14 > Date : 01-Mar-01 > > This draft specifies a COPS (Common Open Policy Service, [2])client- > type designed for the enforcement of IP Traffic Engineering (IP TE) > policies within IP networks. The usage of this IP TE COPS client-type > is based upon the activation of the COPS protocol for policy > provisioning purposes (COPS-PR, [3]). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt > > Depending on the current rap agenda for the Minneapolis meeting, would it be > possible to get allocated a 10-minute slot for a presentation of this draft? > > Comments on this spec are warmly welcome. > > Cheers, > > Christian. > > > From owner-rap@ops.ietf.org Tue Mar 6 09:35:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13041 for ; Tue, 6 Mar 2001 09:35:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aIYK-00061S-00 for rap-data@psg.com; Tue, 06 Mar 2001 06:35:04 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14aIYJ-0005zg-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 06:35:03 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G9S00BD65SYCO@firewall.mcit.com> for rap@ops.ietf.org; Tue, 6 Mar 2001 14:34:10 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9S00G015SVV4@pmismtp02.wcomnet.com>; Tue, 06 Mar 2001 14:34:10 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9S00G3L5SJAF@pmismtp02.wcomnet.com>; Tue, 06 Mar 2001 14:33:55 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Tue, 06 Mar 2001 14:33:55 +0000 Content-return: allowed Date: Tue, 06 Mar 2001 14:33:52 +0000 From: "Iliff, Tina" Subject: RE: draft-jacquenet-ip-te-cops-01.txt To: "'JACQUENET Christian FTRD/DMI/CAE'" , "'Yacine El Mghazli'" Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B6A6@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA13041 Yes, the distinct client-type will allow a PEP to have multiple connections open with a PDP in order to receive various types of policy simultaneously. This allows the PEP to "specify" exactly what it is after instead of just blindly sending a REQ and obtaining only QoS policy. The PEP may have connections open with multiple PDPs; however, these connections may not be of the same client-type. Tina Iliff -----Original Message----- From: JACQUENET Christian FTRD/DMI/CAE [mailto:christian.jacquenet@rd.francetelecom.fr] Sent: Tuesday, March 06, 2001 6:46 AM To: 'Yacine El Mghazli' Cc: rap@ops.ietf.org Subject: RE: draft-jacquenet-ip-te-cops-01.txt Yacine, I'm not sure I understand your question, but, according to section 1 of draft-ietf-rap-pr-05.txt: "In order to support a model that includes multiple PDPs controlling non-overlapping areas of policy on a single PEP, the client-type specified by the PEP to the PDP is unique for the area of policy being managed. A single client-type for a given area of policy (eg. QoS) will be used for all PIBs that exist in that area. The client should treat all the COPS-PR client-types it supports as non-overlapping and independent namespaces where instances MUST NOT be shared." From this standpoint, draft-jacquenet-ip-te-cops-01.txt considers the case of enforcing an IP TE policy (i.e. a specific area of policy, among QoS, security, routing, etc.), thus yielding the need for the definition of a specific client-type that should be treated by a PEP, amongst all the COPS-PR client-types that are currently or will be defined. Did I answer your question? Thank you for your comment. Cheers, Christian. -----Message d'origine----- De : Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Envoyé : mardi 6 mars 2001 11:46 À : JACQUENET Christian FTRD/DMI/CAE Cc : rap@ops.ietf.org Objet : Re: draft-jacquenet-ip-te-cops-01.txt Christian, Why do you use a new client type for provisioning purposes instead of the already existing COPS-PR one ? What prevent you from using the normal provisioning scheme ? I'm sure you have any good reason but I can't get it, I'm not a routing/TE expert ! Thanx Yacine ----- Original Message ----- From: "JACQUENET Christian FTRD/DMI/CAE" To: "'Andrew Smith (co-chair rap)'" ; "'Mark Stevens (co-chair rap)'" Cc: Sent: Monday, March 05, 2001 11:17 AM Subject: draft-jacquenet-ip-te-cops-01.txt > Dear all, > > FYI: A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A COPS client-type for IP traffic engineering > Author(s) : C. Jacquenet > Filename : draft-jacquenet-ip-te-cops-01.txt > Pages : 14 > Date : 01-Mar-01 > > This draft specifies a COPS (Common Open Policy Service, [2])client- > type designed for the enforcement of IP Traffic Engineering (IP TE) > policies within IP networks. The usage of this IP TE COPS client-type > is based upon the activation of the COPS protocol for policy > provisioning purposes (COPS-PR, [3]). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt > > Depending on the current rap agenda for the Minneapolis meeting, would it be > possible to get allocated a 10-minute slot for a presentation of this draft? > > Comments on this spec are warmly welcome. > > Cheers, > > Christian. > > > From owner-rap@ops.ietf.org Tue Mar 6 10:57:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15524 for ; Tue, 6 Mar 2001 10:57:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aJph-0008aX-00 for rap-data@psg.com; Tue, 06 Mar 2001 07:57:05 -0800 Received: from mel.alcatel.fr ([212.208.74.132]) by psg.com with esmtp (Exim 3.16 #1) id 14aJpf-0008aR-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 07:57:04 -0800 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id QAA03415; Tue, 6 Mar 2001 16:52:36 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA17171; Tue, 6 Mar 2001 16:51:35 +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 QAA02165; Tue, 6 Mar 2001 16:56:41 +0100 (MET) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id QAA13044; Tue, 6 Mar 2001 16:56:43 +0100 (MET) Message-ID: <021901c0a655$cf853b20$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: "Iliff, Tina" , "'JACQUENET Christian FTRD/DMI/CAE'" Cc: References: <492EB4A3F68CD411ABE800508B69362E14B6A6@RIPEXCH002.wcomnet.com> Subject: Re: draft-jacquenet-ip-te-cops-01.txt Date: Tue, 6 Mar 2001 16:55:02 +0100 Organization: Alcatel R&I MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Thank you for your explanations & sorry for having misunderstood the draft. But I am still wondering about a point : If there are as many client-types as policy areas, what is the handle function in the provisioning model ? I tought it was used this way (to specify areas) in a unique COPS-PR session, but it's not the case since there is a COPS client type per provisioning area. Yacine ----- Original Message ----- From: "Iliff, Tina" To: "'JACQUENET Christian FTRD/DMI/CAE'" ; "'Yacine El Mghazli'" Cc: Sent: Tuesday, March 06, 2001 3:33 PM Subject: RE: draft-jacquenet-ip-te-cops-01.txt > Yes, the distinct client-type will allow a PEP to have multiple connections > open with a PDP in order to receive various types of policy simultaneously. > This allows the PEP to "specify" exactly what it is after instead of just > blindly sending a REQ and obtaining only QoS policy. > The PEP may have connections open with multiple PDPs; however, these > connections may not be of the same client-type. > > Tina Iliff > > > -----Original Message----- > From: JACQUENET Christian FTRD/DMI/CAE > [mailto:christian.jacquenet@rd.francetelecom.fr] > Sent: Tuesday, March 06, 2001 6:46 AM > To: 'Yacine El Mghazli' > Cc: rap@ops.ietf.org > Subject: RE: draft-jacquenet-ip-te-cops-01.txt > > > Yacine, > > I'm not sure I understand your question, but, according to section 1 of > draft-ietf-rap-pr-05.txt: > > "In order to support a model that includes multiple PDPs > controlling non-overlapping areas of policy on a single PEP, the > client-type specified by the PEP to the PDP is unique for the area > of policy being managed. A single client-type for a given area of > policy (eg. QoS) will be used for all PIBs that exist in that > area. The client should treat all the COPS-PR client-types it > supports as non-overlapping and independent namespaces where > instances MUST NOT be shared." > > >From this standpoint, draft-jacquenet-ip-te-cops-01.txt considers the case > of enforcing an IP TE policy (i.e. a specific area of policy, among QoS, > security, routing, etc.), thus yielding the need for the definition of a > specific client-type that should be treated by a PEP, amongst all the > COPS-PR client-types that are currently or will be defined. > > Did I answer your question? > > Thank you for your comment. > > Cheers, > > Christian. > > > > -----Message d'origine----- > De : Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] > Envoyé : mardi 6 mars 2001 11:46 > À : JACQUENET Christian FTRD/DMI/CAE > Cc : rap@ops.ietf.org > Objet : Re: draft-jacquenet-ip-te-cops-01.txt > > > Christian, > > Why do you use a new client type for provisioning purposes instead of the > already existing COPS-PR one ? > What prevent you from using the normal provisioning scheme ? I'm sure you > have any good reason but I can't get it, I'm not a routing/TE expert ! > Thanx > Yacine > > ----- Original Message ----- > From: "JACQUENET Christian FTRD/DMI/CAE" > > To: "'Andrew Smith (co-chair rap)'" ; "'Mark Stevens > (co-chair rap)'" > Cc: > Sent: Monday, March 05, 2001 11:17 AM > Subject: draft-jacquenet-ip-te-cops-01.txt > > > > Dear all, > > > > FYI: A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : A COPS client-type for IP traffic engineering > > Author(s) : C. Jacquenet > > Filename : draft-jacquenet-ip-te-cops-01.txt > > Pages : 14 > > Date : 01-Mar-01 > > > > This draft specifies a COPS (Common Open Policy Service, [2])client- > > type designed for the enforcement of IP Traffic Engineering (IP TE) > > policies within IP networks. The usage of this IP TE COPS client-type > > is based upon the activation of the COPS protocol for policy > > provisioning purposes (COPS-PR, [3]). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt > > > > Depending on the current rap agenda for the Minneapolis meeting, would it > be > > possible to get allocated a 10-minute slot for a presentation of this > draft? > > > > Comments on this spec are warmly welcome. > > > > Cheers, > > > > Christian. > > > > > > From owner-rap@ops.ietf.org Tue Mar 6 11:09:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15812 for ; Tue, 6 Mar 2001 11:09:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aK1V-0008zv-00 for rap-data@psg.com; Tue, 06 Mar 2001 08:09:17 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14aK1U-0008zP-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 08:09:16 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G9S00DK1A0WC9@firewall.mcit.com> for rap@ops.ietf.org; Tue, 6 Mar 2001 16:05:20 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9S00L019ZVBN@pmismtp02.wcomnet.com>; Tue, 06 Mar 2001 16:05:19 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9S00L0I9ZN94@pmismtp02.wcomnet.com>; Tue, 06 Mar 2001 16:04:35 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Tue, 06 Mar 2001 16:04:35 +0000 Content-return: allowed Date: Tue, 06 Mar 2001 16:04:33 +0000 From: "Iliff, Tina" Subject: RE: draft-jacquenet-ip-te-cops-01.txt To: "'Yacine El Mghazli'" , "'JACQUENET Christian FTRD/DMI/CAE'" Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B6A7@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15812 Yacine, Handles are unique per Client-Type; i.e. one Client-Type "may" use the same Handle as another Client-Type for the same Role Combination or whatever Interface name specification is chosen. In this case, the Handle can identify the Interface and the Client-Type identifies the policy area. Tina Iliff -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Tuesday, March 06, 2001 9:55 AM To: Iliff, Tina; 'JACQUENET Christian FTRD/DMI/CAE' Cc: rap@ops.ietf.org Subject: Re: draft-jacquenet-ip-te-cops-01.txt Thank you for your explanations & sorry for having misunderstood the draft. But I am still wondering about a point : If there are as many client-types as policy areas, what is the handle function in the provisioning model ? I tought it was used this way (to specify areas) in a unique COPS-PR session, but it's not the case since there is a COPS client type per provisioning area. Yacine ----- Original Message ----- From: "Iliff, Tina" To: "'JACQUENET Christian FTRD/DMI/CAE'" ; "'Yacine El Mghazli'" Cc: Sent: Tuesday, March 06, 2001 3:33 PM Subject: RE: draft-jacquenet-ip-te-cops-01.txt > Yes, the distinct client-type will allow a PEP to have multiple connections > open with a PDP in order to receive various types of policy simultaneously. > This allows the PEP to "specify" exactly what it is after instead of just > blindly sending a REQ and obtaining only QoS policy. > The PEP may have connections open with multiple PDPs; however, these > connections may not be of the same client-type. > > Tina Iliff > > > -----Original Message----- > From: JACQUENET Christian FTRD/DMI/CAE > [mailto:christian.jacquenet@rd.francetelecom.fr] > Sent: Tuesday, March 06, 2001 6:46 AM > To: 'Yacine El Mghazli' > Cc: rap@ops.ietf.org > Subject: RE: draft-jacquenet-ip-te-cops-01.txt > > > Yacine, > > I'm not sure I understand your question, but, according to section 1 of > draft-ietf-rap-pr-05.txt: > > "In order to support a model that includes multiple PDPs > controlling non-overlapping areas of policy on a single PEP, the > client-type specified by the PEP to the PDP is unique for the area > of policy being managed. A single client-type for a given area of > policy (eg. QoS) will be used for all PIBs that exist in that > area. The client should treat all the COPS-PR client-types it > supports as non-overlapping and independent namespaces where > instances MUST NOT be shared." > > >From this standpoint, draft-jacquenet-ip-te-cops-01.txt considers the case > of enforcing an IP TE policy (i.e. a specific area of policy, among QoS, > security, routing, etc.), thus yielding the need for the definition of a > specific client-type that should be treated by a PEP, amongst all the > COPS-PR client-types that are currently or will be defined. > > Did I answer your question? > > Thank you for your comment. > > Cheers, > > Christian. > > > > -----Message d'origine----- > De : Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] > Envoyé : mardi 6 mars 2001 11:46 > À : JACQUENET Christian FTRD/DMI/CAE > Cc : rap@ops.ietf.org > Objet : Re: draft-jacquenet-ip-te-cops-01.txt > > > Christian, > > Why do you use a new client type for provisioning purposes instead of the > already existing COPS-PR one ? > What prevent you from using the normal provisioning scheme ? I'm sure you > have any good reason but I can't get it, I'm not a routing/TE expert ! > Thanx > Yacine > > ----- Original Message ----- > From: "JACQUENET Christian FTRD/DMI/CAE" > > To: "'Andrew Smith (co-chair rap)'" ; "'Mark Stevens > (co-chair rap)'" > Cc: > Sent: Monday, March 05, 2001 11:17 AM > Subject: draft-jacquenet-ip-te-cops-01.txt > > > > Dear all, > > > > FYI: A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : A COPS client-type for IP traffic engineering > > Author(s) : C. Jacquenet > > Filename : draft-jacquenet-ip-te-cops-01.txt > > Pages : 14 > > Date : 01-Mar-01 > > > > This draft specifies a COPS (Common Open Policy Service, [2])client- > > type designed for the enforcement of IP Traffic Engineering (IP TE) > > policies within IP networks. The usage of this IP TE COPS client-type > > is based upon the activation of the COPS protocol for policy > > provisioning purposes (COPS-PR, [3]). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt > > > > Depending on the current rap agenda for the Minneapolis meeting, would it > be > > possible to get allocated a 10-minute slot for a presentation of this > draft? > > > > Comments on this spec are warmly welcome. > > > > Cheers, > > > > Christian. > > > > > > From owner-rap@ops.ietf.org Tue Mar 6 18:41:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03592 for ; Tue, 6 Mar 2001 18:41:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aR4M-000Ojl-00 for rap-data@psg.com; Tue, 06 Mar 2001 15:40:42 -0800 Received: from femail3.rdc1.on.home.com ([24.2.9.90]) by psg.com with esmtp (Exim 3.16 #1) id 14aR4L-000OjD-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 15:40:42 -0800 Received: from crete ([24.112.129.233]) by femail3.rdc1.on.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010306234002.QOOY6398.femail3.rdc1.on.home.com@crete> for ; Tue, 6 Mar 2001 15:40:02 -0800 Message-ID: <008501c0a696$d20c71b0$e9817018@crete> From: "Andreas Polyrakis" To: Subject: SPPI PIB-ACCESS clause Date: Tue, 6 Mar 2001 18:40:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I need some clarifications about the PIB-ACCESS clause: I understand that "notify" and "install-notify" PRCs are sent to the PDP through REQ messages, and "report-only" through RPT messages. But what triggers an unsolicited RPT message (apart from a failure RPT, or an RPT that reports changes to the hardware - I talk about RPTs that report normal usage, such as accounting RPTs, mentioned in COPS-PR draft)? Can the PDP ask for an RPT for a specific PRC? the SPPI draft also mentions: 'PRCs having the "install" and/or "notify" characteristics may also be included in reports generated by the PEP'. How can this happen? Does this imply that the PDP has a mechanism to query the PIB and ask for a specific PRI? Thanks, Andreas From owner-rap@ops.ietf.org Tue Mar 6 20:56:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06695 for ; Tue, 6 Mar 2001 20:56:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aTAv-0003MS-00 for rap-data@psg.com; Tue, 06 Mar 2001 17:55:37 -0800 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by psg.com with esmtp (Exim 3.16 #1) id 14aTAt-0003Ly-00 for rap@ops.ietf.org; Tue, 06 Mar 2001 17:55:35 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0G9T00E1O06TO0@firewall.mcit.com> for rap@ops.ietf.org; Wed, 7 Mar 2001 01:30:29 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9T00H0106PCJ@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 01:30:28 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9T00F5C06NNX@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 01:30:23 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Wed, 07 Mar 2001 01:30:23 +0000 Content-return: allowed Date: Wed, 07 Mar 2001 01:30:22 +0000 From: "Rawlins, Diana" Subject: RE: SPPI PIB-ACCESS clause To: "'Andreas Polyrakis'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A500@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-7 Sender: owner-rap@ops.ietf.org Precedence: bulk Andreas, The accounting type RPTs framework is described in http://search.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-00.txt An unsolicited accounting type report is issued based on a deterministic interval specified in the policy. Accounting reports can also be triggered by the PDP issuing an unsolicited decision with the resume policy set with the attribute "send reports." FYI. A new version of the draft has been submitted but is not yet posted on the IETF site. For COPS-PR reports that are not of type accounting, my understanding is that the report clientSI may contain PRI's associated with specific error / warnings conditions. -Diana -----Original Message----- From: Andreas Polyrakis [mailto:apolyr@cs.toronto.edu] Sent: Tuesday, March 06, 2001 5:40 PM To: rap@ops.ietf.org Subject: SPPI PIB-ACCESS clause Hello, I need some clarifications about the PIB-ACCESS clause: I understand that "notify" and "install-notify" PRCs are sent to the PDP through REQ messages, and "report-only" through RPT messages. But what triggers an unsolicited RPT message (apart from a failure RPT, or an RPT that reports changes to the hardware - I talk about RPTs that report normal usage, such as accounting RPTs, mentioned in COPS-PR draft)? Can the PDP ask for an RPT for a specific PRC? the SPPI draft also mentions: 'PRCs having the "install" and/or "notify" characteristics may also be included in reports generated by the PEP'. How can this happen? Does this imply that the PDP has a mechanism to query the PIB and ask for a specific PRI? Thanks, Andreas From owner-rap@ops.ietf.org Wed Mar 7 05:25:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28944 for ; Wed, 7 Mar 2001 05:25:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ab7k-000L7U-00 for rap-data@psg.com; Wed, 07 Mar 2001 02:24:52 -0800 Received: from p-mail2.rd.francetelecom.fr ([193.49.124.32] helo=p-mail2.cnet.fr) by psg.com with smtp (Exim 3.16 #1) id 14ab7j-000L64-00 for rap@ops.ietf.org; Wed, 07 Mar 2001 02:24:51 -0800 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Mar 2001 11:24:04 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82F3DF4B@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: rap@ops.ietf.org Subject: Framework PIB questions Date: Wed, 7 Mar 2001 11:24:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28944 Hi, Getting recently a new look at the framework PIB, I have some questions about it : 1) beside the case of synchronisation, when does the PEP send its role combinations, or, should I ask, how many times ? draft-ietf-rap-frameworkpib-04.txt states that >>"The PEP reports all its role combinations to the PDP in the initial COPS request (REQ) message ..." How must we understand "initial" ? It it for the first request for a given Handle (leading the PEP to send its role combos for every Request State) or the first request within the context of a given Client-Type (leading the PEP to send its roles once within the context of a given Client-Open...)... or ?? My first understanding was the PEP sends its roles once per Request-State context as there is a PIB instance per context. However, I am wondering why it should proceed so, as once the PDP has the device description (roles, limitations...), it can use it for all following Request-States. Or is there a good reason for sending the roles each time (leading however to generating more traffic) ? I'm a bit confused... 2) in the given example about roles (§3.1.1), it is assumed that roles can be changed by the system administrator. I understand this is done directly on the device embedding the PEP. What are the other means to change the roles ? Can it be done remotely ? Using COPS ? (this implies that changes can be applied on a per-interface basis leading each interface to have a specific role combination equivalent to the SNMP ifIndex). 3) assuming I have two Request-States (A and B) for a given CT, I have two non-overlapping PIB instances, one for each RS. draft-ietf-rap-frameworkpib-04.txt says that >> § 5.1 "PIB Incarnation Table >> "This table contains exactly one row (corresponding to one PRI) per context." >> >> § 6 "-- PIB Incarnation Table >> frwkPibIncarnationTable OBJECT-TYPE >> SYNTAX SEQUENCE OF FrwkPibIncarnationEntry >> PIB-ACCESS install-notify >> STATUS current >> DESCRIPTION >> "This class contains a single provisioning instance per installed context... " Does "per context" refers to a COPS context (i.e. a Request-State) meaning that each incarnation table has one entry for each Request-State opened for the given CT ? In my example, this would mean the incarnation table contained in the PIB associated with Request-State A contains informations about Request-State A and Request-State B... I don't think this approach is right, could someone confirm this ? I'd rather see one incarnation table per PIB instance, containing the informations for the RS to which this PIB instance is attached... Thanks for your help. Yoann yoann.noisette@francetelecom.com From owner-rap@ops.ietf.org Wed Mar 7 06:16:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29438 for ; Wed, 7 Mar 2001 06:16:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14abuk-000Mjr-00 for rap-data@psg.com; Wed, 07 Mar 2001 03:15:30 -0800 Received: from menelao.polito.it ([130.192.3.30]) by psg.com with smtp (Exim 3.16 #1) id 14abuj-000Mjj-00 for rap@ops.ietf.org; Wed, 07 Mar 2001 03:15:29 -0800 Received: (qmail 11836 invoked from network); 7 Mar 2001 11:15:22 -0000 Received: from bagigio.polito.it (HELO polito.it) (130.192.31.16) by menelao.polito.it with SMTP; 7 Mar 2001 11:15:22 -0000 Message-ID: <3AA6174C.723ABA55@polito.it> Date: Wed, 07 Mar 2001 12:11:08 +0100 From: Riccardo Scandariato Reply-To: riccardo@athena.polito.it Organization: Politecnico di Torino (http://www.polito.it) X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,it MIME-Version: 1.0 To: IETF RAP WG Subject: DRQ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please, I have a couple of questions: 1) Can PDP force the PEP to delete a request state? If yes, how? > [RFC 2748] > > 3.4 Delete Request State (DRQ) PEP -> PDP > > When sent from the PEP this message indicates to the remote PDP that > the state identified by the client handle is no longer > available/relevant. 2) "When" (in above quote) means that also PDP can send this message? If yes, why? Thanks for help, cheers riccardo From owner-rap@ops.ietf.org Wed Mar 7 11:02:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08838 for ; Wed, 7 Mar 2001 11:02:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14agMt-0006BT-00 for rap-data@psg.com; Wed, 07 Mar 2001 08:00:51 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14agMs-0006B6-00 for rap@ops.ietf.org; Wed, 07 Mar 2001 08:00:51 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G9U002KU4EDL2@firewall.mcit.com> for rap@ops.ietf.org; Wed, 7 Mar 2001 15:59:01 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9U001014E7UL@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 15:59:01 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9U00MNO4DUB8@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 15:58:43 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Wed, 07 Mar 2001 15:58:42 +0000 Content-return: allowed Date: Wed, 07 Mar 2001 15:58:41 +0000 From: "Iliff, Tina" Subject: RE: DRQ To: "'riccardo@athena.polito.it'" , IETF RAP WG Message-id: <492EB4A3F68CD411ABE800508B69362E14B6B3@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Riccardo, My responses to your questions are embedded below preceded by tli>> Tina Iliff -----Original Message----- From: Riccardo Scandariato [mailto:riccardo.scandariato@polito.it] Sent: Wednesday, March 07, 2001 5:11 AM To: IETF RAP WG Subject: DRQ Please, I have a couple of questions: 1) Can PDP force the PEP to delete a request state? If yes, how? tli>> Yes, the PDP can request that the PEP deletes a request state. This is done using a DEC message (Command-Code=Remove and Request-State Flag set). Please reference RFC2748, Section 3.2 Decision (DEC) PDP->PEP, 4th paragraph. > [RFC 2748] > > 3.4 Delete Request State (DRQ) PEP -> PDP > > When sent from the PEP this message indicates to the remote PDP that > the state identified by the client handle is no longer > available/relevant. 2) "When" (in above quote) means that also PDP can send this message? If yes, why? tli>> The PDP may want to remove a request state, say for instance, if it had requested a new request state from the PEP and the PEP returned the error "MaxRequestStatesOpen". This is just an example. Thanks for help, cheers riccardo From owner-rap@ops.ietf.org Wed Mar 7 11:13:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09198 for ; Wed, 7 Mar 2001 11:13:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14agYq-0006aO-00 for rap-data@psg.com; Wed, 07 Mar 2001 08:13:12 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14agYp-0006Ym-00 for rap@ops.ietf.org; Wed, 07 Mar 2001 08:13:11 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G9U0012F4ZUDE@firewall.mcit.com> for rap@ops.ietf.org; Wed, 7 Mar 2001 16:11:54 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9U008014ZIQ6@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 16:11:54 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9U006IR4ZDXZ@pmismtp02.wcomnet.com>; Wed, 07 Mar 2001 16:11:37 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Wed, 07 Mar 2001 16:11:37 +0000 Content-return: allowed Date: Wed, 07 Mar 2001 16:11:36 +0000 From: "Iliff, Tina" Subject: RE: Framework PIB questions To: "'NOISETTE Yoann FTRD/DMI/CAE'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B6B4@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-7 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09198 Yoann, My answers are embedded below preceded by tli>> Tina Iliff -----Original Message----- From: NOISETTE Yoann FTRD/DMI/CAE [mailto:yoann.noisette@rd.francetelecom.fr] Sent: Wednesday, March 07, 2001 4:24 AM To: rap@ops.ietf.org Subject: Framework PIB questions Hi, Getting recently a new look at the framework PIB, I have some questions about it : 1) beside the case of synchronisation, when does the PEP send its role combinations, or, should I ask, how many times ? tli>> Each time a PEP sends a REQ it will include the Role Combination in order to identify the interface for which the configuratio request applies draft-ietf-rap-frameworkpib-04.txt states that >>"The PEP reports all its role combinations to the PDP in the initial COPS request (REQ) message ..." How must we understand "initial" ? It it for the first request for a given Handle (leading the PEP to send its role combos for every Request State) or the first request within the context of a given Client-Type (leading the PEP to send its roles once within the context of a given Client-Open...)... or ?? tili>> Initial implies the first Request which the PEP sends after an OPN (i.e. first REQ per Client-Type) My first understanding was the PEP sends its roles once per Request-State context as there is a PIB instance per context. However, I am wondering why it should proceed so, as once the PDP has the device description (roles, limitations...), it can use it for all following Request-States. Or is there a good reason for sending the roles each time (leading however to generating more traffic) ? I'm a bit confused... tli>> You do have a good point...once the PDP has received the Role Combination once then it may correlate the Role Combination to a Handle and just use the Handle when it receives further re-requests 2) in the given example about roles (§3.1.1), it is assumed that roles can be changed by the system administrator. I understand this is done directly on the device embedding the PEP. What are the other means to change the roles ? Can it be done remotely ? Using COPS ? (this implies that changes can be applied on a per-interface basis leading each interface to have a specific role combination equivalent to the SNMP ifIndex). 3) assuming I have two Request-States (A and B) for a given CT, I have two non-overlapping PIB instances, one for each RS. draft-ietf-rap-frameworkpib-04.txt says that >> § 5.1 "PIB Incarnation Table >> "This table contains exactly one row (corresponding to one PRI) per context." >> >> § 6 "-- PIB Incarnation Table >> frwkPibIncarnationTable OBJECT-TYPE >> SYNTAX SEQUENCE OF FrwkPibIncarnationEntry >> PIB-ACCESS install-notify >> STATUS current >> DESCRIPTION >> "This class contains a single provisioning instance per installed context... " Does "per context" refers to a COPS context (i.e. a Request-State) meaning that each incarnation table has one entry for each Request-State opened for the given CT ? In my example, this would mean the incarnation table contained in the PIB associated with Request-State A contains informations about Request-State A and Request-State B... I don't think this approach is right, could someone confirm this ? I'd rather see one incarnation table per PIB instance, containing the informations for the RS to which this PIB instance is attached... tli>> Yes, this table will contain an entry for each Request-State Thanks for your help. Yoann yoann.noisette@francetelecom.com From owner-rap@ops.ietf.org Thu Mar 8 12:53:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05974 for ; Thu, 8 Mar 2001 12:53:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14b4Yw-000PV2-00 for rap-data@psg.com; Thu, 08 Mar 2001 09:50:54 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14b4Yw-000PSC-00 for rap@ops.ietf.org; Thu, 08 Mar 2001 09:50:54 -0800 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.122.11]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GRBJ45A2; Thu, 8 Mar 2001 12:40:21 -0500 Message-ID: <3AA7C667.288C99E3@ellacoya.com> Date: Thu, 08 Mar 2001 12:50:31 -0500 X-Sybari-Trust: dc62635f 050014de 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: RAP WG Agenda for the 50th IETF Meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We are currenty setting the agenda for the next RAP working group meeting. Please forward requests to me as soon as possible. I will publish agenda for the next meeting on or before March 14th, 2001. Thank you. From owner-rap@ops.ietf.org Thu Mar 8 20:09:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19264 for ; Thu, 8 Mar 2001 20:09:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bBNv-000CRN-00 for rap-data@psg.com; Thu, 08 Mar 2001 17:07:59 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14bBNv-000CQx-00 for rap@ops.ietf.org; Thu, 08 Mar 2001 17:07:59 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G9W003NJOGF1J@firewall.mcit.com> for rap@ops.ietf.org; Fri, 9 Mar 2001 01:07:27 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9W00B01OGCN6@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 01:07:27 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9W00MI2OG7O1@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 01:07:20 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Fri, 09 Mar 2001 01:07:19 +0000 Content-return: allowed Date: Fri, 09 Mar 2001 01:07:17 +0000 From: "Rawlins, Diana" Subject: RE: draft-jacquenet-ip-te-cops-01.txt To: "'Yacine El Mghazli'" , "Iliff, Tina" , "'JACQUENET Christian FTRD/DMI/CAE'" Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A536@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA19264 Yacine, The Client Type and Handle uniquely identify a request state at a give PEP. In the outsourcing model such as COPS-RSVP a request state exists for each signaled reservation. In the provisioning model the request state is associated with an interface or aspect of the PEP device. There can be multiple interfaces/aspects that each have a request state. -Diana -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Tuesday, March 06, 2001 9:55 AM To: Iliff, Tina; 'JACQUENET Christian FTRD/DMI/CAE' Cc: rap@ops.ietf.org Subject: Re: draft-jacquenet-ip-te-cops-01.txt Thank you for your explanations & sorry for having misunderstood the draft. But I am still wondering about a point : If there are as many client-types as policy areas, what is the handle function in the provisioning model ? I tought it was used this way (to specify areas) in a unique COPS-PR session, but it's not the case since there is a COPS client type per provisioning area. Yacine ----- Original Message ----- From: "Iliff, Tina" To: "'JACQUENET Christian FTRD/DMI/CAE'" ; "'Yacine El Mghazli'" Cc: Sent: Tuesday, March 06, 2001 3:33 PM Subject: RE: draft-jacquenet-ip-te-cops-01.txt > Yes, the distinct client-type will allow a PEP to have multiple connections > open with a PDP in order to receive various types of policy simultaneously. > This allows the PEP to "specify" exactly what it is after instead of just > blindly sending a REQ and obtaining only QoS policy. > The PEP may have connections open with multiple PDPs; however, these > connections may not be of the same client-type. > > Tina Iliff > > > -----Original Message----- > From: JACQUENET Christian FTRD/DMI/CAE > [mailto:christian.jacquenet@rd.francetelecom.fr] > Sent: Tuesday, March 06, 2001 6:46 AM > To: 'Yacine El Mghazli' > Cc: rap@ops.ietf.org > Subject: RE: draft-jacquenet-ip-te-cops-01.txt > > > Yacine, > > I'm not sure I understand your question, but, according to section 1 of > draft-ietf-rap-pr-05.txt: > > "In order to support a model that includes multiple PDPs > controlling non-overlapping areas of policy on a single PEP, the > client-type specified by the PEP to the PDP is unique for the area > of policy being managed. A single client-type for a given area of > policy (eg. QoS) will be used for all PIBs that exist in that > area. The client should treat all the COPS-PR client-types it > supports as non-overlapping and independent namespaces where > instances MUST NOT be shared." > > >From this standpoint, draft-jacquenet-ip-te-cops-01.txt considers the case > of enforcing an IP TE policy (i.e. a specific area of policy, among QoS, > security, routing, etc.), thus yielding the need for the definition of a > specific client-type that should be treated by a PEP, amongst all the > COPS-PR client-types that are currently or will be defined. > > Did I answer your question? > > Thank you for your comment. > > Cheers, > > Christian. > > > > -----Message d'origine----- > De : Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] > Envoyé : mardi 6 mars 2001 11:46 > À : JACQUENET Christian FTRD/DMI/CAE > Cc : rap@ops.ietf.org > Objet : Re: draft-jacquenet-ip-te-cops-01.txt > > > Christian, > > Why do you use a new client type for provisioning purposes instead of the > already existing COPS-PR one ? > What prevent you from using the normal provisioning scheme ? I'm sure you > have any good reason but I can't get it, I'm not a routing/TE expert ! > Thanx > Yacine > > ----- Original Message ----- > From: "JACQUENET Christian FTRD/DMI/CAE" > > To: "'Andrew Smith (co-chair rap)'" ; "'Mark Stevens > (co-chair rap)'" > Cc: > Sent: Monday, March 05, 2001 11:17 AM > Subject: draft-jacquenet-ip-te-cops-01.txt > > > > Dear all, > > > > FYI: A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : A COPS client-type for IP traffic engineering > > Author(s) : C. Jacquenet > > Filename : draft-jacquenet-ip-te-cops-01.txt > > Pages : 14 > > Date : 01-Mar-01 > > > > This draft specifies a COPS (Common Open Policy Service, [2])client- > > type designed for the enforcement of IP Traffic Engineering (IP TE) > > policies within IP networks. The usage of this IP TE COPS client-type > > is based upon the activation of the COPS protocol for policy > > provisioning purposes (COPS-PR, [3]). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt > > > > Depending on the current rap agenda for the Minneapolis meeting, would it > be > > possible to get allocated a 10-minute slot for a presentation of this > draft? > > > > Comments on this spec are warmly welcome. > > > > Cheers, > > > > Christian. > > > > > > From owner-rap@ops.ietf.org Fri Mar 9 05:07:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10513 for ; Fri, 9 Mar 2001 05:07:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bJmk-0001Ns-00 for rap-data@psg.com; Fri, 09 Mar 2001 02:06:10 -0800 Received: from mel.alcatel.fr ([212.208.74.132]) by psg.com with esmtp (Exim 3.16 #1) id 14bJmj-0001Nl-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 02:06:09 -0800 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id LAA05631; Fri, 9 Mar 2001 11:01:16 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA05903; Fri, 9 Mar 2001 11:00: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 LAA24678; Fri, 9 Mar 2001 11:05:47 +0100 (MET) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id LAA15405; Fri, 9 Mar 2001 11:05:51 +0100 (MET) Message-ID: <004801c0a880$4b03e2c0$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: "Rawlins, Diana" , "Iliff, Tina" Cc: References: <492EB4A3F68CD411ABE800508B69362E31A536@RIPEXCH002.wcomnet.com> Subject: Re: draft-jacquenet-ip-te-cops-01.txt Date: Fri, 9 Mar 2001 11:04:12 +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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Diana, Tina, Where in the PR-05 draft is it explained that handles are linked to interfaces/roles ? Be sure I trust you but I'd like to read the spec in order to understand properly COPS-PR. If so, what about the start attribute in the Diffserv DataPath Element (QoS area for example)? What is its function ? Yacine From owner-rap@ops.ietf.org Fri Mar 9 07:40:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11920 for ; Fri, 9 Mar 2001 07:40:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bM92-0005SS-00 for rap-data@psg.com; Fri, 09 Mar 2001 04:37:20 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14bM91-0005Ry-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 04:37:19 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11823; Fri, 9 Mar 2001 07:37:17 -0500 (EST) Message-Id: <200103091237.HAA11823@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-acct-fr-pib-01.txt Date: Fri, 09 Mar 2001 07:37:16 -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 of COPS-PR Policy Information Base for Accounting Usage Author(s) : D. Rawlins, A. Kulkarni, K. Chan, D. Dutt Filename : draft-ietf-rap-acct-fr-pib-01.txt Pages : 14 Date : 08-Mar-01 Currently there are no policy classes defined for the PEP to convey provisioned policy usage feedback to the PDP. The purpose of this document is to define the accounting framework PIB that specifies the policy classes common for COPS accounting type reports. The basic operation and objects for reporting usage information are defined in [COPS]. A specific clientSI accounting type object named REPORT is defined in [COPS-PR]. This document further describes operational behavior that is implied in [COPS] and [COPS-PR.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-01.txt 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-acct-fr-pib-01.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-acct-fr-pib-01.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: <20010308111136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-acct-fr-pib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-acct-fr-pib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308111136.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Mar 9 09:11:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14220 for ; Fri, 9 Mar 2001 09:11:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bNbX-0007UU-00 for rap-data@psg.com; Fri, 09 Mar 2001 06:10:51 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14bNbW-0007Tb-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 06:10:51 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G9X001ILOOAY2@firewall.mcit.com> for rap@ops.ietf.org; Fri, 9 Mar 2001 14:09:46 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9X00101OO0B7@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 14:09:46 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9X00KOQONW6T@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 14:09:33 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Fri, 09 Mar 2001 14:09:32 +0000 Content-return: allowed Date: Fri, 09 Mar 2001 14:09:31 +0000 From: "Iliff, Tina" Subject: RE: draft-jacquenet-ip-te-cops-01.txt To: "'Yacine El Mghazli'" , "Rawlins, Diana" Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B6C9@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Yacine, The PR-05 draft does not explicitly state the relationship between Request State Handle and Role Combination or Interface; however, it implicitly does with the following excerpts: 3.1. Request (REQ) PEP -> PDP Different request states are used to isolate similarly named configuration information into non-overlapping contexts (or logically isolated namespaces). and 6. Common Operation Each request state represents an independent and logically non-overlapping namespace, identified by the Client Handle, on which transactions (a.k.a. configuration [Page 27] installations, deletions, updates) may be performed. Other existing Request States will be unaffected by the new request state as they are independent (thus, no instances of configuration data within one Request State can be affected by DECs for another Request State as identified by the Client Handle). The Diffserv-PIB-03 draft does not explicitly state the relationship between Handle and Role Combination either. Authors: Are we correct in inferring from the above PR-05 draft excerpts that only one Interface Type/Role Combination will be configured per Request-State? The function of the Start attribute in the qosDataPath table in the diffserv-pib-03 draft is to indicate per Interface Type/Role Combination/Direction where DiffServ processing should begin for packets traversing the interface (i.e. what datapath functional element will first process the packet). Tina Iliff -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Friday, March 09, 2001 4:04 AM To: Rawlins, Diana; Iliff, Tina Cc: rap@ops.ietf.org Subject: Re: draft-jacquenet-ip-te-cops-01.txt Diana, Tina, Where in the PR-05 draft is it explained that handles are linked to interfaces/roles ? Be sure I trust you but I'd like to read the spec in order to understand properly COPS-PR. If so, what about the start attribute in the Diffserv DataPath Element (QoS area for example)? What is its function ? Yacine From owner-rap@ops.ietf.org Fri Mar 9 09:49:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15420 for ; Fri, 9 Mar 2001 09:49:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bOBr-0008IE-00 for rap-data@psg.com; Fri, 09 Mar 2001 06:48:23 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.16 #1) id 14bOBq-0008H7-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 06:48:23 -0800 Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 204CCAA29; Fri, 9 Mar 2001 09:47:52 -0500 (EST) Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 105839E45 for ; Fri, 9 Mar 2001 09:47:48 -0500 (EST) Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id <1VSV8LXA>; Fri, 9 Mar 2001 15:47:10 +0100 Message-ID: From: "Bouarich, Reda" To: "'rap@ops.ietf.org'" Subject: ldap vs RSVP Date: Fri, 9 Mar 2001 15:47:00 +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 Hello all, Is there any drafts that specifies a modelling for RSVP data in an LDAP directory? cheers, reda. From owner-rap@ops.ietf.org Fri Mar 9 10:00:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15840 for ; Fri, 9 Mar 2001 10:00:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bOMw-0008ZA-00 for rap-data@psg.com; Fri, 09 Mar 2001 06:59:50 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14bOMv-0008Y5-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 06:59:49 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G9X00DEQQVMH5@firewall.mcit.com> for rap@ops.ietf.org; Fri, 9 Mar 2001 14:57:22 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9X00301QVI34@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 14:57:22 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9X000HQQV873@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 14:57:08 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Fri, 09 Mar 2001 14:57:07 +0000 Content-return: allowed Date: Fri, 09 Mar 2001 14:57:06 +0000 From: "Iliff, Tina" Subject: RE: ldap vs RSVP To: "'Bouarich, Reda'" , "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E14B6CE@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Reda, I do not know of any. However, there is a draft which proposes a PIB structure for RSVP Policy Control information. You will find the draft at the following URL: http://www.ietf.org/internet-drafts/draft-rawlins-rsvppcc-pib-01.txt Tina Iliff -----Original Message----- From: Bouarich, Reda [mailto:Reda.Bouarich@Compaq.com] Sent: Friday, March 09, 2001 8:47 AM To: 'rap@ops.ietf.org' Subject: ldap vs RSVP Hello all, Is there any drafts that specifies a modelling for RSVP data in an LDAP directory? cheers, reda. From owner-rap@ops.ietf.org Fri Mar 9 10:27:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17240 for ; Fri, 9 Mar 2001 10:27:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bOlx-000980-00 for rap-data@psg.com; Fri, 09 Mar 2001 07:25:41 -0800 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by psg.com with esmtp (Exim 3.16 #1) id 14bOlw-00097t-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 07:25:40 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29FPKg28295 for ; Fri, 9 Mar 2001 09:25:30 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Mar 2001 09:25:18 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 9 Mar 2001 09:25:18 -0600 Message-ID: From: Pedro.Soria-Rodriguez@nokia.com To: rap@ops.ietf.org Subject: Re: COPS SSQ/SSC Date: Fri, 9 Mar 2001 09:25:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk (this is an old thread, I know; I just joined the list and am interested in this) To recap: 1. The PDP sends a set of policies P to the PEP. 2. The connection is lost. 3. At this point, the PEP does have a valid set "P". Then, when the PEP gets a _new_ connection to the PDP, is there a way for the PDP to know exactly what policies are already in the PEP? Since the PEP does have valid policies, there is no need to download those policies "P" again. But the PDP has to know somehow that the set "P" is indeed in the PEP already. The RFC2748 says: ................................................................... 3.5 Synchronize State Request (SSQ) PDP -> PEP [...] The client performs state synchronization by re-issuing request queries of the specified client-type for the existing state in the PEP. When synchronization is complete, the PEP MUST issue a synchronize state complete message to the PDP. .................................................................... It doesn't talk about the case that the PEP has valid policies. Does this mean that even in this case, everything must be downloaded again? Thanks, -- Pedro Soria-Rodriguez > Re: COPS SSQ/SSC > To: Tina.Iliff@WCOM.Com (Iliff Tina) > Subject: Re: COPS SSQ/SSC > From: Keith McCloghrie > Date: Tue, 24 Oct 2000 12:49:57 -0700 (PDT) > Cc: rap@ops.ietf.org ('rap@ops.ietf.org'), Richard.Sunlin@WCOM.Com ("Sunlin, Richard (c)") > Delivery-date: Tue, 24 Oct 2000 22:59:53 +0300 > Envelope-to: archive@lists.atm.tut.fi > In-Reply-To: <492EB4A3F68CD411ABE800508B69362E015922@RIPEXCH002.wcomnet.com> from "Iliff, Tina" at Oct 24, 2000 02:51:42 PM > Sender: owner-rap@ops.ietf.org > > A better solution is for the PDP to have a set of policies, M, that it > uses for misconfigured interfaces. So, when the PDP receives the > unknown interface-type/role combination from the PEP, then a) the PDP > sends the M set of policies to the PEP, so that the PEP can configure > the relevant interfaces, and b) the PDP can inform the administrator > such that the misconfiguration (either of the PDP or PEP) can be fixed. > > Keith. From owner-rap@ops.ietf.org Fri Mar 9 10:39:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17965 for ; Fri, 9 Mar 2001 10:39:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bOxo-0009MT-00 for rap-data@psg.com; Fri, 09 Mar 2001 07:37:56 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14bOxn-0009MJ-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 07:37:55 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G9X00IBYSP7M4@firewall.mcit.com> for rap@ops.ietf.org; Fri, 9 Mar 2001 15:36:43 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9X00001SON41@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 15:36:43 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9X00MBQSODEH@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 15:36:13 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Fri, 09 Mar 2001 15:36:13 +0000 Content-return: allowed Date: Fri, 09 Mar 2001 15:36:11 +0000 From: "Iliff, Tina" Subject: RE: COPS SSQ/SSC To: "'Pedro.Soria-Rodriguez@nokia.com'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B6D0@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Pedro, My responses to your questions are embedded within your e-mail preceded by tli>> Tina Iliff -----Original Message----- From: Pedro.Soria-Rodriguez@nokia.com [mailto:Pedro.Soria-Rodriguez@nokia.com] Sent: Friday, March 09, 2001 9:25 AM To: rap@ops.ietf.org Subject: Re: COPS SSQ/SSC (this is an old thread, I know; I just joined the list and am interested in this) To recap: 1. The PDP sends a set of policies P to the PEP. 2. The connection is lost. 3. At this point, the PEP does have a valid set "P". Then, when the PEP gets a _new_ connection to the PDP, is there a way for the PDP to know exactly what policies are already in the PEP? tli>> The PDP can determine which set of policies the PEP has cached by looking at the frwkPibIncarnation instance which the PEP includes in the REQ NamedClientSI object. Since the PEP does have valid policies, there is no need to download those policies "P" again. But the PDP has to know somehow that the set "P" is indeed in the PEP already. The RFC2748 says: ................................................................... 3.5 Synchronize State Request (SSQ) PDP -> PEP [...] The client performs state synchronization by re-issuing request queries of the specified client-type for the existing state in the PEP. When synchronization is complete, the PEP MUST issue a synchronize state complete message to the PDP. .................................................................... It doesn't talk about the case that the PEP has valid policies. Does this mean that even in this case, everything must be downloaded again? tli>> No, it is not necessary to push the policy set again as long as the PDP is confident that the PEP has the correct policy. Thanks, -- Pedro Soria-Rodriguez > Re: COPS SSQ/SSC > To: Tina.Iliff@WCOM.Com (Iliff Tina) > Subject: Re: COPS SSQ/SSC > From: Keith McCloghrie > Date: Tue, 24 Oct 2000 12:49:57 -0700 (PDT) > Cc: rap@ops.ietf.org ('rap@ops.ietf.org'), Richard.Sunlin@WCOM.Com ("Sunlin, Richard (c)") > Delivery-date: Tue, 24 Oct 2000 22:59:53 +0300 > Envelope-to: archive@lists.atm.tut.fi > In-Reply-To: <492EB4A3F68CD411ABE800508B69362E015922@RIPEXCH002.wcomnet.com> from "Iliff, Tina" at Oct 24, 2000 02:51:42 PM > Sender: owner-rap@ops.ietf.org > > A better solution is for the PDP to have a set of policies, M, that it > uses for misconfigured interfaces. So, when the PDP receives the > unknown interface-type/role combination from the PEP, then a) the PDP > sends the M set of policies to the PEP, so that the PEP can configure > the relevant interfaces, and b) the PDP can inform the administrator > such that the misconfiguration (either of the PDP or PEP) can be fixed. > > Keith. From owner-rap@ops.ietf.org Fri Mar 9 10:48:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18526 for ; Fri, 9 Mar 2001 10:48:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bP6c-0009Wq-00 for rap-data@psg.com; Fri, 09 Mar 2001 07:47:02 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14bP6b-0009WE-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 07:47:02 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G9X00IE9T3Z24@firewall.mcit.com> for rap@ops.ietf.org; Fri, 9 Mar 2001 15:45:36 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9X00501T3Y6V@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 15:45:35 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9X003ABT3L1H@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 15:45:21 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Fri, 09 Mar 2001 15:45:20 +0000 Content-return: allowed Date: Fri, 09 Mar 2001 15:45:19 +0000 From: "Rawlins, Diana" Subject: RE: draft-jacquenet-ip-te-cops-01.txt To: "'Yacine El Mghazli'" , "Iliff, Tina" Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A540@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Yacine, My understanding is that handles are associated with a request /policy state. -Diana -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Friday, March 09, 2001 4:04 AM To: Rawlins, Diana; Iliff, Tina Cc: rap@ops.ietf.org Subject: Re: draft-jacquenet-ip-te-cops-01.txt Diana, Tina, Where in the PR-05 draft is it explained that handles are linked to interfaces/roles ? Be sure I trust you but I'd like to read the spec in order to understand properly COPS-PR. If so, what about the start attribute in the Diffserv DataPath Element (QoS area for example)? What is its function ? Yacine From owner-rap@ops.ietf.org Fri Mar 9 11:30:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20767 for ; Fri, 9 Mar 2001 11:30:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bPl7-000AJO-00 for rap-data@psg.com; Fri, 09 Mar 2001 08:28:53 -0800 Received: from 64-48-118-19.customer.algx.net ([64.48.118.19] helo=cube5.cplane.com) by psg.com with esmtp (Exim 3.16 #1) id 14bPl6-000AJE-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 08:28:52 -0800 Received: from localhost (rajiv@localhost) by cube5.cplane.com (8.9.3/8.9.3) with ESMTP id IAA01329; Fri, 9 Mar 2001 08:28:31 -0800 X-Authentication-Warning: cube5.cplane.com: rajiv owned process doing -bs Date: Fri, 9 Mar 2001 08:28:31 -0800 (PST) From: Rajiv Dighe To: "Iliff, Tina" cc: "'Yacine El Mghazli'" , "Rawlins, Diana" , rap@ops.ietf.org Subject: RE: draft-jacquenet-ip-te-cops-01.txt In-Reply-To: <492EB4A3F68CD411ABE800508B69362E14B6C9@RIPEXCH002.wcomnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk On Fri, 9 Mar 2001, Iliff, Tina wrote: > > Authors: Are we correct in inferring from the above PR-05 draft excerpts > that only one Interface Type/Role Combination will be configured per > Request-State? > Tina, It has been my understanding that each Client handle referes to a single request state. so if the request included 5 Interface Type/Role Combinations, then all of them will be configured using same client handle. PEP can send only one request ordinarily( emphasis here is on "ordinarily". naturally if client deletes previous request state for some reason or if it has to send new request because of configuration change, then it will do so ). Given that, it is fair to assume that PEP will inform PDP about all the Interface Types/Role Combinations in single request message using same client handle. Multiple request states can be opened only if PDP instructs PEP to do so using apropriate flag in DEC message. Offcourse, I tend to forget / misunderstand RFCs & drafts with rather alarming regularity. so more knowledgable folks on the list will no doubt correct me whereever I have missed point of this whole conversation ;) Regards, --Rajiv From owner-rap@ops.ietf.org Fri Mar 9 11:37:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21223 for ; Fri, 9 Mar 2001 11:37:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bPsT-000AR8-00 for rap-data@psg.com; Fri, 09 Mar 2001 08:36:29 -0800 Received: from p-mail2.rd.francetelecom.fr ([193.49.124.32] helo=p-mail2.cnet.fr) by psg.com with smtp (Exim 3.16 #1) id 14bPsS-000AQa-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 08:36:29 -0800 Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 17:32:48 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82F3DF5F@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: "'Rawlins, Diana'" , "'Yacine El Mghazli'" , "Iliff, Tina" Cc: rap@ops.ietf.org Subject: RE: draft-jacquenet-ip-te-cops-01.txt Date: Fri, 9 Mar 2001 17:32:46 +0100 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA21223 Diana, IMHO handles are effectively designed to refer to Request-States. One handle identifies one and only one given Request-State for a given Client-Type, and then the policy (PIB instance) defined within the context of this Request-State. See COPS-PR5 §3.1 "The Client Handle associated with the REQ message originated by a provisioning client MUST be unique for that client. The Client Handle is used to identify a specific request state." Moreover, I disagree when you say "In the provisioning model the request state is associated with an interface or aspect of the PEP device." , you should rather say "interface type" (as suggested by Tina), this "type" being defined by the role combination associated to the interfaces. But still I don't think a Request-State is associated to only one interface type. (Please see below for further explanations). Tina, Quote from Framework PIB draft version 4 § 3.1 "Provisioning classes have an attribute called a RoleCombination which is a lexicographically ordered set of roles. Instances of a given provisioning class are applied to an interface if and only if the set of roles in the role combination matches the set of the roles of the interface." And later on : "Furthermore, if the same policy is being applied to several interfaces, that policy need be pushed to the device only once, rather than once per interface, as long as the interfaces are configured with the same role combination." Therefore instead of telling "Interface Type/Role Combination will be configured per Request-State", I'd rather say "per Provisioning class"... Please correct me if I'm wrong... Finally, does anyone knows any answer to this : In the Framework PIB document, in the given example about roles (§3.1.1), it is assumed that roles can be changed by the system administrator. I understand this is done directly on the device embedding the PEP. What are the other means to change the roles ? Can it be done remotely ? Using COPS ? (this implies that changes can be applied on a per-interface basis leading each interface to have a specific role combination equivalent to the SNMP ifIndex). Thanks. Yoann -----Message d'origine----- De : Rawlins, Diana [mailto:Diana.Rawlins@wcom.com] Envoyé : vendredi 9 mars 2001 16:45 À : 'Yacine El Mghazli'; Iliff, Tina Cc : rap@ops.ietf.org Objet : RE: draft-jacquenet-ip-te-cops-01.txt Yacine, My understanding is that handles are associated with a request /policy state. -Diana -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Friday, March 09, 2001 4:04 AM To: Rawlins, Diana; Iliff, Tina Cc: rap@ops.ietf.org Subject: Re: draft-jacquenet-ip-te-cops-01.txt Diana, Tina, Where in the PR-05 draft is it explained that handles are linked to interfaces/roles ? Be sure I trust you but I'd like to read the spec in order to understand properly COPS-PR. If so, what about the start attribute in the Diffserv DataPath Element (QoS area for example)? What is its function ? Yacine From owner-rap@ops.ietf.org Fri Mar 9 11:55:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22215 for ; Fri, 9 Mar 2001 11:55:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bQ9E-000AhX-00 for rap-data@psg.com; Fri, 09 Mar 2001 08:53:48 -0800 Received: from 64-48-118-19.customer.algx.net ([64.48.118.19] helo=cube5.cplane.com) by psg.com with esmtp (Exim 3.16 #1) id 14bQ9E-000AhR-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 08:53:48 -0800 Received: from localhost (rajiv@localhost) by cube5.cplane.com (8.9.3/8.9.3) with ESMTP id IAA01368; Fri, 9 Mar 2001 08:53:39 -0800 X-Authentication-Warning: cube5.cplane.com: rajiv owned process doing -bs Date: Fri, 9 Mar 2001 08:53:39 -0800 (PST) From: Rajiv Dighe To: NOISETTE Yoann FTRD/DMI/CAE cc: "'Rawlins, Diana'" , "'Yacine El Mghazli'" , "Iliff, Tina" , rap@ops.ietf.org Subject: RE: draft-jacquenet-ip-te-cops-01.txt In-Reply-To: <91A311FF6A85D3118DDF0060080C3D82F3DF5F@lat3721.rd.francetelecom.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id LAA22215 On Fri, 9 Mar 2001, NOISETTE Yoann FTRD/DMI/CAE wrote: > > Finally, does anyone knows any answer to this : > > In the Framework PIB document, in the given example about roles (§3.1.1), it > is assumed that roles can be changed by the system administrator. I > understand this is done directly on the device embedding the PEP. What are > the other means to change the > roles ? Can it be done remotely ? Using COPS ? (this implies that changes > can be applied on a per-interface basis leading each interface to have a > specific role combination equivalent to the SNMP ifIndex). > > Thanks. > > Yoann Yoann, AFAIK in theory COPS *does not* provide any way to do this. In Reality, this will be purely implementation dependant. device manufacturer may choose to expose that functionality purely via hardwired console, thru telnet or even web or corba interface. Regards, --Rajiv From owner-rap@ops.ietf.org Fri Mar 9 12:24:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24169 for ; Fri, 9 Mar 2001 12:24:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bQcJ-000BD2-00 for rap-data@psg.com; Fri, 09 Mar 2001 09:23:51 -0800 Received: from [151.88.109.26] (helo=ciaoweb.it) by psg.com with esmtp (Exim 3.16 #1) id 14bQcI-000BCf-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 09:23:50 -0800 Received: from mail pickup service by ciaoweb.it with Microsoft SMTPSVC; Fri, 9 Mar 2001 18:22:01 +0100 Received: from dns.ciaoweb.net ([151.88.109.1]) by ciaoweb.it with Microsoft SMTPSVC(5.5.1877.447.44); Fri, 9 Mar 2001 11:19:15 +0100 Received: by dns.ciaoweb.net; (8.8.8/1.3/10May95) id LAA26238; Fri, 9 Mar 2001 11:19:15 +0100 (MET) Received: from psg.com by dns.ciaoweb.net (smtpxd); id XA08318 Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bJmk-0001Ns-00 for rap-data@psg.com; Fri, 09 Mar 2001 02:06:10 -0800 Received: from mel.alcatel.fr ([212.208.74.132]) by psg.com with esmtp (Exim 3.16 #1) id 14bJmj-0001Nl-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 02:06:09 -0800 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id LAA05631; Fri, 9 Mar 2001 11:01:16 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA05903; Fri, 9 Mar 2001 11:00: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 LAA24678; Fri, 9 Mar 2001 11:05:47 +0100 (MET) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id LAA15405; Fri, 9 Mar 2001 11:05:51 +0100 (MET) Message-ID: <004801c0a880$4b03e2c0$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: "Rawlins" Cc: References: <492EB4A3F68CD411ABE800508B69362E31A536@RIPEXCH002.wcomnet.com> Subject: Re: draft-jacquenet-ip-te-cops-01.txt Date: Fri, 9 Mar 2001 11:04:12 +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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Diana, Tina, Where in the PR-05 draft is it explained that handles are linked to interfaces/roles ? Be sure I trust you but I'd like to read the spec in order to understand properly COPS-PR. If so, what about the start attribute in the Diffserv DataPath Element (QoS area for example)? What is its function ? Yacine From owner-rap@ops.ietf.org Fri Mar 9 12:40:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25284 for ; Fri, 9 Mar 2001 12:40:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14bQpH-000BQE-00 for rap-data@psg.com; Fri, 09 Mar 2001 09:37:15 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14bQpG-000BPi-00 for rap@ops.ietf.org; Fri, 09 Mar 2001 09:37:14 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G9X002OMY7HZX@firewall.mcit.com> for rap@ops.ietf.org; Fri, 9 Mar 2001 17:35:41 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G9X00G01Y7FJS@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 17:35:41 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G9X00BT7Y7151@pmismtp02.wcomnet.com>; Fri, 09 Mar 2001 17:35:25 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Fri, 09 Mar 2001 17:35:25 +0000 Content-return: allowed Date: Fri, 09 Mar 2001 17:35:21 +0000 From: "Rawlins, Diana" Subject: RE: draft-jacquenet-ip-te-cops-01.txt To: "'NOISETTE Yoann FTRD/DMI/CAE'" , "'Yacine El Mghazli'" , "Iliff, Tina" Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E31A547@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA25284 Interface type sounds good! Thanks, Diana -----Original Message----- From: NOISETTE Yoann FTRD/DMI/CAE [mailto:yoann.noisette@rd.francetelecom.fr] Sent: Friday, March 09, 2001 10:33 AM To: Rawlins, Diana; 'Yacine El Mghazli'; Iliff, Tina Cc: rap@ops.ietf.org Subject: RE: draft-jacquenet-ip-te-cops-01.txt Diana, IMHO handles are effectively designed to refer to Request-States. One handle identifies one and only one given Request-State for a given Client-Type, and then the policy (PIB instance) defined within the context of this Request-State. See COPS-PR5 §3.1 "The Client Handle associated with the REQ message originated by a provisioning client MUST be unique for that client. The Client Handle is used to identify a specific request state." Moreover, I disagree when you say "In the provisioning model the request state is associated with an interface or aspect of the PEP device." , you should rather say "interface type" (as suggested by Tina), this "type" being defined by the role combination associated to the interfaces. But still I don't think a Request-State is associated to only one interface type. (Please see below for further explanations). Tina, Quote from Framework PIB draft version 4 § 3.1 "Provisioning classes have an attribute called a RoleCombination which is a lexicographically ordered set of roles. Instances of a given provisioning class are applied to an interface if and only if the set of roles in the role combination matches the set of the roles of the interface." And later on : "Furthermore, if the same policy is being applied to several interfaces, that policy need be pushed to the device only once, rather than once per interface, as long as the interfaces are configured with the same role combination." Therefore instead of telling "Interface Type/Role Combination will be configured per Request-State", I'd rather say "per Provisioning class"... Please correct me if I'm wrong... Finally, does anyone knows any answer to this : In the Framework PIB document, in the given example about roles (§3.1.1), it is assumed that roles can be changed by the system administrator. I understand this is done directly on the device embedding the PEP. What are the other means to change the roles ? Can it be done remotely ? Using COPS ? (this implies that changes can be applied on a per-interface basis leading each interface to have a specific role combination equivalent to the SNMP ifIndex). Thanks. Yoann -----Message d'origine----- De : Rawlins, Diana [mailto:Diana.Rawlins@wcom.com] Envoyé : vendredi 9 mars 2001 16:45 À : 'Yacine El Mghazli'; Iliff, Tina Cc : rap@ops.ietf.org Objet : RE: draft-jacquenet-ip-te-cops-01.txt Yacine, My understanding is that handles are associated with a request /policy state. -Diana -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Friday, March 09, 2001 4:04 AM To: Rawlins, Diana; Iliff, Tina Cc: rap@ops.ietf.org Subject: Re: draft-jacquenet-ip-te-cops-01.txt Diana, Tina, Where in the PR-05 draft is it explained that handles are linked to interfaces/roles ? Be sure I trust you but I'd like to read the spec in order to understand properly COPS-PR. If so, what about the start attribute in the Diffserv DataPath Element (QoS area for example)? What is its function ? Yacine From owner-rap@ops.ietf.org Mon Mar 12 01:41:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24437 for ; Mon, 12 Mar 2001 01:41:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cLxW-000552-00 for rap-data@psg.com; Sun, 11 Mar 2001 22:37:34 -0800 Received: from mail2.registeredsite.com ([64.224.9.11]) by psg.com with esmtp (Exim 3.16 #1) id 14cLxV-00054w-00 for rap@ops.ietf.org; Sun, 11 Mar 2001 22:37:33 -0800 Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217]) by mail2.registeredsite.com (8.11.1/8.11.1) with ESMTP id f2C6bVc10562 for ; Mon, 12 Mar 2001 01:37:31 -0500 Date: Mon, 12 Mar 2001 01:37:28 -0500 Message-Id: <200103120137.AA2057240846@mail.cominsights.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "sridhar" Reply-To: X-Sender: To: Subject: assistance please!!! X-Mailer: Sender: owner-rap@ops.ietf.org Precedence: bulk hi all, here are few questions related to cops for rsvp for which i am feeling very much difficult to understand or come to conclusion. 2.5 Synchronization Behavior [...] A PEP that caches state from a previous exchange with a disconnected PDP MUST communicate this fact to any PDP with which it is able to later reconnect. This is accomplished by including the address and TCP port of the last PDP for which the PEP is still caching state in the Client-Open message. Q>. In what form will PEP store the state of REQ and what are its contents? _______________________________________________________________________ 2.5 Synchronization Behavior [..] Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued) by sending a Synchronize State message. Q>. When connection is re-established, is only Requests processed in absence of PDP should be reissued OR all previous REQ's ? Q>. While reissuing the requests, in case new request is to be processed wheather it is done after sending SSC or it can be done between? __________________________________________________________________________________ 3.3 Report State (RPT) PEP -> PDP [..] The Report State may also be used to provide periodic updates of client specific information for accounting and state monitoring purposes depending on the type of the client. In such cases the accounting report type should be specified utilizing the appropriate client specific information object. Q>. What exactly do mean by Accounting? When is Accounting RPT message triggered? How does PDP make use of Accounting RPT .. thanks for help!! with warm regards bamsi From owner-rap@ops.ietf.org Mon Mar 12 11:21:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13115 for ; Mon, 12 Mar 2001 11:21:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cV3Q-000EXG-00 for rap-data@psg.com; Mon, 12 Mar 2001 08:20:16 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14cV3O-000EWv-00 for rap@ops.ietf.org; Mon, 12 Mar 2001 08:20:14 -0800 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.122.11]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GRBJVBN5; Mon, 12 Mar 2001 11:09:25 -0500 Message-ID: <3AACF718.CC6C0175@ellacoya.com> Date: Mon, 12 Mar 2001 11:19:37 -0500 X-Sybari-Trust: 85a76b20 050014de 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: RAP Working Group Re-chartering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of the items that we will discuss in the upcoming RAP working group meeting is the new charter. Below is a draft of the new charter. Please come to the RAP working group prepared to discuss this new charter. Discussion on this mailing list is also encouraged. A full agenda for the meeting will be available shortly. -Mark Stevens Description of Working Group: Recent works in the IETF have led to the development and standardization of enhanced network services such as QoS and traffic engineering. The complexity of these services and the variations in the capabilities of the devices implementing these services provide a challenge to anyone trying to configure services within medium- and large-scale networks. The working group will define general-purpose objects that facilitate the manipulation of policies and provisioned objects available through COPS and COPS-PR. Where appropriate, these will include frameworks clarifying the applicability of COPS objects and the best practices for the definition of additional objects defined in other working groups. In particular, the group will address the following work items: - A framework for defining the usage of COPS for carrying accounting information: The working group will produce a standards track document defining the usage of COPS for carrying accounting information between a PDP and PEPs [ACCTFRWK]. - A standards track document describing an accounting PIB to be used to carry policy usage feedback from the PEP to the PDP [ACCTPIB]. - A standards track defining object syntax for carrying policy provisioning information ("Object Syntax"): The working group will produce standards track RFCs that specify the syntax of objects and their contents for carrying policy information. The working group will specifically focus on the syntax of objects needed for carrying information related to QoS policy provisioning [SPPI] [FRWKPIB]. - A standards track document describing a modular architecture for a COPS based Management Framework. The document will address the COPS message processing, security and access control and may specify examples of how the framework may be implemented. [COPSFRWK] The working group will continue to document changes to COPS objects needed to support any extensions to RSVP and extensions to RVSP directly related to policy control. Specifically the working group will pursue: - A version of draft-ietf-rap-rsvp-newidentity that addresses security shortcomings with the current document [NEWIDENTITY]. - A standards track document defining new ErrorValues for the RSVP Policy Error Object [RSVPERRVAL]. - A standards track document defining the framework and mechanism for authorizing of RSVP sessions [SESSIONAUTH]. - A standards track document defining an RSVP Local Policy Control Criteria PIB [RSVPPIB]. Documents produced by the working group must fully address all the security aspects of this type of protocol. In particular, theft and denial of service threats must be minimized. Milestones and Goals Done Submit I-D framework document for policy control for RSVP to IESG for publication as a Proposed Standard Done Submit I-D defining any necessary extensions to RSVP to support policy control to IESG for publication as a Proposed Standard Done Submit I-D defining a standard protocol for the exchange of policy information between RSVP-capable network nodes and policy servers to IESG for publication as a Proposed Standard Done Submit Initial draft of document that specifies COPS usage for policy provisioning transactions Done Working Group last call on revised version of COPS Usage document incorporating mailing list discussions Done Submit COPS Usage document to IESG for publication as an Proposed Standard Done Submit object syntax transport protocol I-D Done Submit object syntax transport protocol (SPPI) to IESG for consideration as a RFC Dec 00 Submit I-D defining framework of COPS-PR PIB for accounting usage Mar 01 Submit Update draft ACCTPIB Apr 01 Submit FRWKPIB to IESG for consideration as a Proposed Standard Apr 01 Submit First draft RSVPPIB Apr 01 Submit First draft RSVPERRVAL Apr 01 Submit First draft SESSIONAUTH Jul 01 Submit First draft COPSFRWK Jul 01 Submit First draft of ACCTFRWK Jul 01 Submit First draft NEWIDENTITY Jul 01 Submit Update draft RSVPPIB Jul 01 Submit Update draft RSVPERRVAL Jul 01 Submit Update draft SESSIONAUTH Sep 01 Submit Update draft NEWIDENTITY Jul 01 Submit Update draft ACCTFRWK Jul 01 Submit Update draft COPSFRWK Jan 02 ACCTFRWK Draft to to AD/IESG for consideration as Proposed Standard Jan 02 ACCTPIB Draft to to AD/IESG for consideration as Proposed Standard Jan 02 NEWIDENTITY Draft to to AD/IESG for consideration as Proposed Standard Jan 02 RSVPPIB Draft to to AD/IESG for consideration as Proposed Standard Jan 02 RSVPERRVAL Draft to to AD/IESG for consideration as Proposed Standard Jan 02 SESSIONAUTH Draft to to AD/IESG for consideration as Proposed Standard Jan 02 COPSFRWK Draft to to AD/IESG for consideration as Proposed Standard From owner-rap@ops.ietf.org Mon Mar 12 13:29:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16267 for ; Mon, 12 Mar 2001 13:29:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cX2T-000Gis-00 for rap-data@psg.com; Mon, 12 Mar 2001 10:27:25 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14cX2R-000Gia-00 for rap@ops.ietf.org; Mon, 12 Mar 2001 10:27:23 -0800 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id SAA19996; Mon, 12 Mar 2001 18:27:07 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 12 Mar 2001 18:27:07 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Mar 2001 10:27:06 -0800 Message-ID: From: "Kulkarni, Amol" To: "'bamsidhar@cominsights.com'" , rap@ops.ietf.org Subject: RE: assistance please!!! Date: Mon, 12 Mar 2001 10:27:01 -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 Bamsi, Please see my answers below. -----Original Message----- From: sridhar [mailto:bamsidhar@cominsights.com] Sent: Sunday, March 11, 2001 10:37 PM To: rap@ops.ietf.org Subject: assistance please!!! hi all, here are few questions related to cops for rsvp for which i am feeling very much difficult to understand or come to conclusion. 2.5 Synchronization Behavior [...] A PEP that caches state from a previous exchange with a disconnected PDP MUST communicate this fact to any PDP with which it is able to later reconnect. This is accomplished by including the address and TCP port of the last PDP for which the PEP is still caching state in the Client-Open message. Q>. In what form will PEP store the state of REQ and what are its contents? Amol- It is up to the PEP to store the REQ information internally in any way it chooses, as long as it is in the required message format when the REQ is sent to the PDP. _______________________________________________________________________ 2.5 Synchronization Behavior [..] Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued) by sending a Synchronize State message. Q>. When connection is re-established, is only Requests processed in absence of PDP should be reissued OR all previous REQ's ? Amol- When the connection is re-established, the PDP may issue a Synchronise State Request. The PEP should then send all open requests. If any requests were deleted while there was no connection, the PEP should send explicit Delete Requests. Q>. While reissuing the requests, in case new request is to be processed wheather it is done after sending SSC or it can be done between? Amol- I think the PEP should not issue new requests until after sending an SCC. This would allow the PDP to get an accurate picture of the current resource usage at the PEP before making a decision. ____________________________________________________________________________ ______ 3.3 Report State (RPT) PEP -> PDP [..] The Report State may also be used to provide periodic updates of client specific information for accounting and state monitoring purposes depending on the type of the client. In such cases the accounting report type should be specified utilizing the appropriate client specific information object. Q>. What exactly do mean by Accounting? When is Accounting RPT message triggered? How does PDP make use of Accounting RPT .. Amol- Accounting in this case means reporting how a particular flow uses the resources allocated to it. It could be used for billing purposes etc. I am not aware of any formal accounting guidelines for the outsourcing model of COPS. There is, however, an accounting draft for the provisioning model. The Accounting RPT is triggerred at periodic intervals as specified by the PDP. The intervals may vary for different reports, but the frequency must not exceed that specified by the min accounting interval that the PDP specifies during connection establishment. The accounting draft is available here: http://www.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-01.txt There is also a draft for an RSVP PIB, which contains some accounting classes. You might be able to get more information out of it. The draft is available here: http://search.ietf.org/internet-drafts/draft-rawlins-rsvppcc-pib-01.txt. Please see the pccAllocatedUsageTable and the pccSessionStatsUsageTable. Amol thanks for help!! with warm regards bamsi From owner-rap@ops.ietf.org Tue Mar 13 10:51:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22222 for ; Tue, 13 Mar 2001 10:51:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cr4a-0007dN-00 for rap-data@psg.com; Tue, 13 Mar 2001 07:50:56 -0800 Received: from enst.enst.fr ([137.194.2.16]) by psg.com with esmtp (Exim 3.16 #1) id 14cr4Z-0007dH-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 07:50:55 -0800 Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by enst.enst.fr (Postfix) with ESMTP id AFD201C8DE for ; Tue, 13 Mar 2001 16:50:52 +0100 (MET) Received: from marius.enst.fr (marius.enst.fr [137.194.160.85]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id QAA23781 for ; Tue, 13 Mar 2001 16:50:51 +0100 (MET) Received: from marius (localhost [127.0.0.1]) by marius.enst.fr (8.9.3+Sun/8.9.3) with SMTP id QAA24955 for ; Tue, 13 Mar 2001 16:50:50 +0100 (MET) Message-ID: <3AAE41D9.13CD@yahoo.com> Date: Tue, 13 Mar 2001 16:50:49 +0100 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: rap@ops.ietf.org Subject: tbd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Excuse-me for a silly question. I think that it is very simple but I don'nt know. In each PIB, there is always the word "tbd". What does it means? Is it an acronym ? Thanks a lot. Mai Trang From owner-rap@ops.ietf.org Tue Mar 13 11:02:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22345 for ; Tue, 13 Mar 2001 11:02:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14crFK-0007n4-00 for rap-data@psg.com; Tue, 13 Mar 2001 08:02:02 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14crFJ-0007mP-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 08:02:02 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GA500N3X8DQ3X@firewall.mcit.com> for rap@ops.ietf.org; Tue, 13 Mar 2001 15:58:38 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GA500I018DJ4U@pmismtp02.wcomnet.com>; Tue, 13 Mar 2001 15:58:37 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GA500I168DA23@pmismtp02.wcomnet.com>; Tue, 13 Mar 2001 15:58:22 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Tue, 13 Mar 2001 15:58:22 +0000 Content-return: allowed Date: Tue, 13 Mar 2001 15:58:20 +0000 From: "Iliff, Tina" Subject: RE: tbd To: "'Nguyen Thi Mai Trang'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B6DE@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Mai Trang, It means "To Be Determined". For example, the Object Identifiers (OIDs) for the PIB, Groups and Tables will be assigned at a later date. Tina Iliff -----Original Message----- From: Nguyen Thi Mai Trang [mailto:maitrangqos@yahoo.com] Sent: Tuesday, March 13, 2001 9:51 AM To: rap@ops.ietf.org Subject: tbd Hello, Excuse-me for a silly question. I think that it is very simple but I don'nt know. In each PIB, there is always the word "tbd". What does it means? Is it an acronym ? Thanks a lot. Mai Trang From owner-rap@ops.ietf.org Tue Mar 13 11:28:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22997 for ; Tue, 13 Mar 2001 11:28:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14crfD-0008Bx-00 for rap-data@psg.com; Tue, 13 Mar 2001 08:28:47 -0800 Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14crfC-0008Bn-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 08:28:46 -0800 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA10797; Tue, 13 Mar 2001 17:28:44 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA28375; Tue, 13 Mar 2001 17:28:44 +0100 Date: Tue, 13 Mar 2001 17:28:44 +0100 Message-Id: <200103131628.RAA28375@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mstevens@ellacoya.com CC: rap@ops.ietf.org In-reply-to: <3AACF718.CC6C0175@ellacoya.com> (mstevens@ellacoya.com) Subject: Re: RAP Working Group Re-chartering References: <3AACF718.CC6C0175@ellacoya.com> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Mark L Stevens writes: Mark> - A standards track defining object syntax for carrying policy Mark> provisioning information ("Object Syntax"): The working group Mark> will produce standards track RFCs that specify the syntax of Mark> objects and their contents for carrying policy information. The Mark> working group will specifically focus on the syntax of objects Mark> needed for carrying information related to QoS policy Mark> provisioning [SPPI] [FRWKPIB]. Can someone please explain what this means? Is it about defining PIBs? Is it about defining another SPPI language? Is it about both? Or is it something completely different? What do you mean with "object syntax"? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-rap@ops.ietf.org Tue Mar 13 11:44:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23258 for ; Tue, 13 Mar 2001 11:44:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cruW-0008Sb-00 for rap-data@psg.com; Tue, 13 Mar 2001 08:44:36 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14cruV-0008S7-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 08:44:35 -0800 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.122.11]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GRBJV1VQ; Tue, 13 Mar 2001 11:33:43 -0500 Message-ID: <3AAE4E50.AB04B1C6@ellacoya.com> Date: Tue, 13 Mar 2001 11:44:00 -0500 X-Sybari-Trust: 270c062f 050014de 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: rap@ops.ietf.org Subject: Re: RAP Working Group Re-chartering References: <3AACF718.CC6C0175@ellacoya.com> <200103131628.RAA28375@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This charter element merely refers to the drafts at http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-05.txt and http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-04.txt it is not a new charter item. It is repeated from the previous charter indicating that we intend to complete the work started under the auspices of the original charter. As for the term object syntax, it is a term used to describe the format of the expressions used to describe the structure and organization of data. :-) -Mark Juergen Schoenwaelder wrote: > >>>>> Mark L Stevens writes: > > Mark> - A standards track defining object syntax for carrying policy > Mark> provisioning information ("Object Syntax"): The working group > Mark> will produce standards track RFCs that specify the syntax of > Mark> objects and their contents for carrying policy information. The > Mark> working group will specifically focus on the syntax of objects > Mark> needed for carrying information related to QoS policy > Mark> provisioning [SPPI] [FRWKPIB]. > > Can someone please explain what this means? Is it about defining PIBs? > Is it about defining another SPPI language? Is it about both? Or is it > something completely different? What do you mean with "object syntax"? > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-rap@ops.ietf.org Tue Mar 13 11:50:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23375 for ; Tue, 13 Mar 2001 11:50:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cs0F-0008bn-00 for rap-data@psg.com; Tue, 13 Mar 2001 08:50:31 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14cs0E-0008be-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 08:50:30 -0800 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id QAA24074; Tue, 13 Mar 2001 16:50:06 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 13 Mar 2001 16:50:05 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 08:50:03 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E8905730EF@orsmsx35.jf.intel.com> From: "Hahn, Scott" To: "'Juergen Schoenwaelder'" , mstevens@ellacoya.com Cc: rap@ops.ietf.org Subject: RE: RAP Working Group Re-chartering Date: Tue, 13 Mar 2001 08:49:56 -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 Juergen, I think you are reading more into this than there is. This paragraph refers to the ongoing SPPI and Framework PIB. The SPPI is at the hands of the IESG. The framework PIB went through WG last call, but resulted in a few minor changes and I believe will do another last call. These were left in the charter because the work is still going on. It is *not* another SPPI. -Scott > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: Tuesday, March 13, 2001 8:29 AM > To: mstevens@ellacoya.com > Cc: rap@ops.ietf.org > Subject: Re: RAP Working Group Re-chartering > > > > >>>>> Mark L Stevens writes: > > Mark> - A standards track defining object syntax for carrying policy > Mark> provisioning information ("Object Syntax"): The working group > Mark> will produce standards track RFCs that specify the syntax of > Mark> objects and their contents for carrying policy information. The > Mark> working group will specifically focus on the syntax of objects > Mark> needed for carrying information related to QoS policy > Mark> provisioning [SPPI] [FRWKPIB]. > > Can someone please explain what this means? Is it about defining PIBs? > Is it about defining another SPPI language? Is it about both? Or is it > something completely different? What do you mean with "object syntax"? > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 > Braunschweig, Germany > Fax: +49 531 391 5936 > > > > From owner-rap@ops.ietf.org Tue Mar 13 13:51:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26086 for ; Tue, 13 Mar 2001 13:50:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cts8-000AuM-00 for rap-data@psg.com; Tue, 13 Mar 2001 10:50:16 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14cts7-000AuF-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 10:50:15 -0800 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id SAA11836; Tue, 13 Mar 2001 18:50:12 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 13 Mar 2001 18:50:11 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 10:50:09 -0800 Message-ID: From: "Kulkarni, Amol" To: "'Mark L. Stevens'" , rap@ops.ietf.org Subject: RE: RAP Working Group Re-chartering Date: Tue, 13 Mar 2001 10:49:57 -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 Mark, I don't see any mention of the 'COPS over TLS' draft in the new charter. It has been submitted as a WG item for the upcoming IETF. I think it solves an important security problem which the integrity object doesn't address. It would be a useful document to have in the working group. Thanks, Amol -----Original Message----- From: Mark L. Stevens [mailto:mstevens@ellacoya.com] Sent: Monday, March 12, 2001 8:20 AM To: rap@ops.ietf.org Subject: RAP Working Group Re-chartering One of the items that we will discuss in the upcoming RAP working group meeting is the new charter. Below is a draft of the new charter. Please come to the RAP working group prepared to discuss this new charter. Discussion on this mailing list is also encouraged. A full agenda for the meeting will be available shortly. -Mark Stevens Description of Working Group: Recent works in the IETF have led to the development and standardization of enhanced network services such as QoS and traffic engineering. The complexity of these services and the variations in the capabilities of the devices implementing these services provide a challenge to anyone trying to configure services within medium- and large-scale networks. The working group will define general-purpose objects that facilitate the manipulation of policies and provisioned objects available through COPS and COPS-PR. Where appropriate, these will include frameworks clarifying the applicability of COPS objects and the best practices for the definition of additional objects defined in other working groups. In particular, the group will address the following work items: - A framework for defining the usage of COPS for carrying accounting information: The working group will produce a standards track document defining the usage of COPS for carrying accounting information between a PDP and PEPs [ACCTFRWK]. - A standards track document describing an accounting PIB to be used to carry policy usage feedback from the PEP to the PDP [ACCTPIB]. - A standards track defining object syntax for carrying policy provisioning information ("Object Syntax"): The working group will produce standards track RFCs that specify the syntax of objects and their contents for carrying policy information. The working group will specifically focus on the syntax of objects needed for carrying information related to QoS policy provisioning [SPPI] [FRWKPIB]. - A standards track document describing a modular architecture for a COPS based Management Framework. The document will address the COPS message processing, security and access control and may specify examples of how the framework may be implemented. [COPSFRWK] The working group will continue to document changes to COPS objects needed to support any extensions to RSVP and extensions to RVSP directly related to policy control. Specifically the working group will pursue: - A version of draft-ietf-rap-rsvp-newidentity that addresses security shortcomings with the current document [NEWIDENTITY]. - A standards track document defining new ErrorValues for the RSVP Policy Error Object [RSVPERRVAL]. - A standards track document defining the framework and mechanism for authorizing of RSVP sessions [SESSIONAUTH]. - A standards track document defining an RSVP Local Policy Control Criteria PIB [RSVPPIB]. Documents produced by the working group must fully address all the security aspects of this type of protocol. In particular, theft and denial of service threats must be minimized. Milestones and Goals Done Submit I-D framework document for policy control for RSVP to IESG for publication as a Proposed Standard Done Submit I-D defining any necessary extensions to RSVP to support policy control to IESG for publication as a Proposed Standard Done Submit I-D defining a standard protocol for the exchange of policy information between RSVP-capable network nodes and policy servers to IESG for publication as a Proposed Standard Done Submit Initial draft of document that specifies COPS usage for policy provisioning transactions Done Working Group last call on revised version of COPS Usage document incorporating mailing list discussions Done Submit COPS Usage document to IESG for publication as an Proposed Standard Done Submit object syntax transport protocol I-D Done Submit object syntax transport protocol (SPPI) to IESG for consideration as a RFC Dec 00 Submit I-D defining framework of COPS-PR PIB for accounting usage Mar 01 Submit Update draft ACCTPIB Apr 01 Submit FRWKPIB to IESG for consideration as a Proposed Standard Apr 01 Submit First draft RSVPPIB Apr 01 Submit First draft RSVPERRVAL Apr 01 Submit First draft SESSIONAUTH Jul 01 Submit First draft COPSFRWK Jul 01 Submit First draft of ACCTFRWK Jul 01 Submit First draft NEWIDENTITY Jul 01 Submit Update draft RSVPPIB Jul 01 Submit Update draft RSVPERRVAL Jul 01 Submit Update draft SESSIONAUTH Sep 01 Submit Update draft NEWIDENTITY Jul 01 Submit Update draft ACCTFRWK Jul 01 Submit Update draft COPSFRWK Jan 02 ACCTFRWK Draft to to AD/IESG for consideration as Proposed Standard Jan 02 ACCTPIB Draft to to AD/IESG for consideration as Proposed Standard Jan 02 NEWIDENTITY Draft to to AD/IESG for consideration as Proposed Standard Jan 02 RSVPPIB Draft to to AD/IESG for consideration as Proposed Standard Jan 02 RSVPERRVAL Draft to to AD/IESG for consideration as Proposed Standard Jan 02 SESSIONAUTH Draft to to AD/IESG for consideration as Proposed Standard Jan 02 COPSFRWK Draft to to AD/IESG for consideration as Proposed Standard From owner-rap@ops.ietf.org Tue Mar 13 14:44:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27063 for ; Tue, 13 Mar 2001 14:44:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cuit-000Bow-00 for rap-data@psg.com; Tue, 13 Mar 2001 11:44:47 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14cuip-000BoU-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 11:44:44 -0800 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.122.11]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GRBJVFL2; Tue, 13 Mar 2001 14:33:51 -0500 Message-ID: <3AAE7888.7E60640E@ellacoya.com> Date: Tue, 13 Mar 2001 14:44:09 -0500 X-Sybari-Trust: 11b828a9 050014de 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kulkarni, Amol" CC: rap@ops.ietf.org Subject: Re: RAP Working Group Re-chartering References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You are right, it is not explicitly called out, but one could consider it as coming under the charter item shown below: - A standards track document describing a modular architecture for a COPS based Management Framework. The document will address the COPS message processing, security and access control and may specify examples of how the framework may be implemented. [COPSFRWK] Let's be sure to address the idea of explicitly mentioning COPS over TLS in the charter during the working group meeting next week. Please bring it up during the charter discussion. Of course, we can always initiate the discussion here and now on the mailing list. -Mark "Kulkarni, Amol" wrote: > Hi Mark, > > I don't see any mention of the 'COPS over TLS' draft in the new charter. It > has been submitted as a WG item for the upcoming IETF. > > I think it solves an important security problem which the integrity object > doesn't address. It would be a useful document to have in the working group. > > Thanks, > Amol > > -----Original Message----- > From: Mark L. Stevens [mailto:mstevens@ellacoya.com] > Sent: Monday, March 12, 2001 8:20 AM > To: rap@ops.ietf.org > Subject: RAP Working Group Re-chartering > > One of the items that we will discuss in the upcoming > RAP working group meeting is the new charter. > > Below is a draft of the new charter. > > Please come to the RAP working group prepared to discuss > this new charter. > > Discussion on this mailing list is also encouraged. > > A full agenda for the meeting will be available shortly. > > -Mark Stevens > > Description of Working Group: > > Recent works in the IETF have led to the development and > standardization of enhanced network services such as QoS and traffic > engineering. The complexity of these services and the variations in > the capabilities of the devices implementing these services provide a > challenge to anyone trying to configure services within medium- and > large-scale networks. > > The working group will define general-purpose objects that facilitate > the manipulation of policies and provisioned objects available through > COPS and COPS-PR. Where appropriate, these will include frameworks > clarifying the applicability of COPS objects and the best practices > for the definition of additional objects defined in other working > groups. > > In particular, the group will address the following work items: > > - A framework for defining the usage of COPS for carrying accounting > information: The working group will produce a standards track > document defining the usage of COPS for carrying accounting > information between a PDP and PEPs [ACCTFRWK]. > > - A standards track document describing an accounting PIB to be used > to carry policy usage feedback from the PEP to the PDP [ACCTPIB]. > > - A standards track defining object syntax for carrying policy > provisioning information ("Object Syntax"): The working group will > produce standards track RFCs that specify the syntax of objects > and their contents for carrying policy information. The working > group will specifically focus on the syntax of objects needed for > carrying information related to QoS policy provisioning [SPPI] > [FRWKPIB]. > > - A standards track document describing a modular architecture for a > COPS based Management Framework. The document will address > the COPS message processing, security and access control and may > specify examples of how the framework may be implemented. > [COPSFRWK] > > The working group will continue to document changes to COPS objects > needed to support any extensions to RSVP and extensions to RVSP > directly related to policy control. Specifically the working group > will pursue: > - A version of draft-ietf-rap-rsvp-newidentity that addresses > security shortcomings with the current document > [NEWIDENTITY]. > - A standards track document defining new ErrorValues for the > RSVP Policy Error Object [RSVPERRVAL]. > - A standards track document defining the framework and > mechanism for authorizing of RSVP sessions [SESSIONAUTH]. > - A standards track document defining an RSVP Local Policy > Control Criteria PIB [RSVPPIB]. > > Documents produced by the working group must fully address all the > security aspects of this type of protocol. In particular, theft and > denial of service threats must be minimized. > > Milestones and Goals > > Done Submit I-D framework document for policy control for RSVP to IESG > for publication as a Proposed Standard > > Done Submit I-D defining any necessary extensions to RSVP to support > policy control to IESG for publication as a Proposed Standard > > Done Submit I-D defining a standard protocol for the exchange of > policy information between RSVP-capable network nodes and policy > servers to IESG for publication as a Proposed Standard > > Done Submit Initial draft of document that specifies COPS usage for > policy provisioning transactions > > Done Working Group last call on revised version of COPS Usage document > incorporating mailing list discussions > > Done Submit COPS Usage document to IESG for publication as an > Proposed Standard > > Done Submit object syntax transport protocol I-D > > Done Submit object syntax transport protocol (SPPI) to IESG for > consideration as a RFC > > Dec 00 Submit I-D defining framework of COPS-PR PIB for > accounting usage > Mar 01 Submit Update draft ACCTPIB > > Apr 01 Submit FRWKPIB to IESG for consideration as a > Proposed Standard > > Apr 01 Submit First draft RSVPPIB > > Apr 01 Submit First draft RSVPERRVAL > > Apr 01 Submit First draft SESSIONAUTH > > Jul 01 Submit First draft COPSFRWK > > Jul 01 Submit First draft of ACCTFRWK > > Jul 01 Submit First draft NEWIDENTITY > > Jul 01 Submit Update draft RSVPPIB > > Jul 01 Submit Update draft RSVPERRVAL > > Jul 01 Submit Update draft SESSIONAUTH > > Sep 01 Submit Update draft NEWIDENTITY > > Jul 01 Submit Update draft ACCTFRWK > > Jul 01 Submit Update draft COPSFRWK > > Jan 02 ACCTFRWK Draft to to AD/IESG for consideration as > Proposed Standard > > Jan 02 ACCTPIB Draft to to AD/IESG for consideration as > Proposed Standard > > Jan 02 NEWIDENTITY Draft to to AD/IESG for consideration as > Proposed Standard > > Jan 02 RSVPPIB Draft to to AD/IESG for consideration as > Proposed Standard > > Jan 02 RSVPERRVAL Draft to to AD/IESG for consideration as > Proposed Standard > > Jan 02 SESSIONAUTH Draft to to AD/IESG for consideration as > Proposed Standard > > Jan 02 COPSFRWK Draft to to AD/IESG for consideration as > Proposed Standard From owner-rap@ops.ietf.org Tue Mar 13 19:04:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00544 for ; Tue, 13 Mar 2001 19:04:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cymB-000GVC-00 for rap-data@psg.com; Tue, 13 Mar 2001 16:04:27 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14cymA-000GV6-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 16:04:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14cymA-000AJP-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 16:04:26 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "sridhar" Reply-To: To: "Kulkarni, Amol" CC: Subject: help me out !!! X-Sender: X-Mailer: Sender: owner-rap@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 13 Mar 2001 16:04:27 -0800 hi all, these r few questions for which i need help.i am looking forward for a positive response with warm regards BAMSI ====================================================================== 2.4 Decision Object (Decision) DECISION FLAGS The only decision flag that applies to RSVP: Trigger Error If this flag is set, RSVP should schedule a PathErr, in response to a Path message, or a ResvErr (in response of a Resv message). Q) when pdp should set error as trigger error?explanation with example would be better? Q) what is the flag code value for this? [Page 5] The PEP may also have the capability to make a local policy decision via its Local Policy Decision Point (LPDP) [WRK], 3.5 PEP Caching COPS Decisions If the connection can not be reestablished with the PDP or a backup PDP after the timeout period, the PEP is expected to purge all its cached decisions. Without applicable cached decision, the PEP must either reject the flow or resort to its LPDP (if available) for decisions. Q) what type of decisions can LPDP make? Q) all the process decisions r to be cached in LPDP also? Q) Is LPDP has all the policy info or can access the polices stored in policy repository? Q) can backup pdp decisions r final or else it has to again send it to primary pdp for final approval when connection is re-established with primary pdp? 3.3 RSVP's Capacity Admission Control: Commit and Delete In RSVP, the admission of a new reservation requires both an administrative approval (policy control) and capacity admission control. After being approved by both, and after the reservation was successfully installed, the PEP notifies the remote PDP by sending a report message specifying the Commit type. Q) where is the reservation installed? Q)who takes care of installing these Reservation? From owner-rap@ops.ietf.org Tue Mar 13 21:22:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01781 for ; Tue, 13 Mar 2001 21:22:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14d0vp-000Jrw-00 for rap-data@psg.com; Tue, 13 Mar 2001 18:22:33 -0800 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.16 #1) id 14d0vp-000Jro-00 for rap@ops.ietf.org; Tue, 13 Mar 2001 18:22:33 -0800 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA04120 for ; Tue, 13 Mar 2001 21:22:32 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA04087 for ; Tue, 13 Mar 2001 21:22:31 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Mar 2001 03:22:30 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B9A28E2@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: rap Cc: Randy Bush Subject: New co-chair for RAP WG Date: Wed, 14 Mar 2001 03:22:27 +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 Andrew has informed us that he won't have enough time to do a good job as WG chair. I have found Scott Hahn to be willing to volunteer as the new co-chair. Let me say a THANK YOU to Andrew for the good work he did as WG chair in the past. Hopefully he will finf time to at least keep an eye on what the WG is doing and commenting when needed. So the current co-chairs are: Mark Stevens Scott Hahn. As you have noticed, Scott, Mark and the ADs have had a few discussions on a re-charter of the WG. The proposal that was posted a few days ago is what we came up with. After the IETF in Minneapolis I will send it to IESG/IAB for approval. Bert > ---------- > From: Hahn, Scott[SMTP:scott.hahn@intel.com] > Sent: Tuesday, March 13, 2001 5:49 PM > To: 'Juergen Schoenwaelder'; mstevens@ellacoya.com > Cc: rap@ops.ietf.org > Subject: RE: RAP Working Group Re-chartering > > Juergen, > I think you are reading more into this than there is. This paragraph > refers > to the ongoing SPPI and Framework PIB. The SPPI is at the hands of the > IESG. > The framework PIB went through WG last call, but resulted in a few minor > changes and I believe will do another last call. These were left in the > charter because the work is still going on. It is *not* another SPPI. > -Scott > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > > Sent: Tuesday, March 13, 2001 8:29 AM > > To: mstevens@ellacoya.com > > Cc: rap@ops.ietf.org > > Subject: Re: RAP Working Group Re-chartering > > > > > > > > >>>>> Mark L Stevens writes: > > > > Mark> - A standards track defining object syntax for carrying policy > > Mark> provisioning information ("Object Syntax"): The working group > > Mark> will produce standards track RFCs that specify the syntax of > > Mark> objects and their contents for carrying policy information. The > > Mark> working group will specifically focus on the syntax of objects > > Mark> needed for carrying information related to QoS policy > > Mark> provisioning [SPPI] [FRWKPIB]. > > > > Can someone please explain what this means? Is it about defining PIBs? > > Is it about defining another SPPI language? Is it about both? Or is it > > something completely different? What do you mean with "object syntax"? > > > > /js > > > > -- > > Juergen Schoenwaelder Technical University Braunschweig > > Dept. Operating Systems & Computer Networks > > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 > > Braunschweig, Germany > > Fax: +49 531 391 5936 > > > > > > > > > > From owner-rap@ops.ietf.org Wed Mar 14 04:22:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21170 for ; Wed, 14 Mar 2001 04:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14d7TI-0005nS-00 for rap-data@psg.com; Wed, 14 Mar 2001 01:21:32 -0800 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by psg.com with esmtp (Exim 3.16 #1) id 14d7TG-0005nI-00 for rap@ops.ietf.org; Wed, 14 Mar 2001 01:21:31 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 14 Mar 2001 14:58:32 +0530 Received: from divyak (divyak.future.futsoft.com [10.0.40.8]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f2EEtwP13450; Wed, 14 Mar 2001 20:25:59 +0530 Reply-To: From: "divyak" To: , "'Kulkarni, Amol'" Cc: Subject: RE: help me out !!! Date: Wed, 14 Mar 2001 14:50:20 +0530 Message-Id: <001c01c0ac67$fea355a0$0828000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit hiiii...... I may like to add some more doubts to this mail. Ref :RFC 2748 2.3 If a PEP is in communication with a backup PDP and the primary PDP becomes available, the backup PDP is responsible for redirecting the PEP back to the primary PDP (via a message containing a object identifying the primary PDP to use for each affected client-type). Q1: After redirecitng to another backup PDP , why should that PDP redirect the PEP to the primary PDP when it comes up?And how does the backup PDP know when the primary PDP comes up? Q2: Can the back up PDP take decisions independent of primary PDP? If so, why should it inform the decisions to the primary PDP ? Regards Divya. -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of sridhar Sent: Wednesday, 14 March 2001 5:34 AM To: Kulkarni, Amol Cc: rap@ops.ietf.org Subject: help me out !!! hi all, these r few questions for which i need help.i am looking forward for a positive response with warm regards BAMSI ====================================================================== 2.4 Decision Object (Decision) DECISION FLAGS The only decision flag that applies to RSVP: Trigger Error If this flag is set, RSVP should schedule a PathErr, in response to a Path message, or a ResvErr (in response of a Resv message). Q) when pdp should set error as trigger error?explanation with example would be better? Q) what is the flag code value for this? [Page 5] The PEP may also have the capability to make a local policy decision via its Local Policy Decision Point (LPDP) [WRK], 3.5 PEP Caching COPS Decisions If the connection can not be reestablished with the PDP or a backup PDP after the timeout period, the PEP is expected to purge all its cached decisions. Without applicable cached decision, the PEP must either reject the flow or resort to its LPDP (if available) for decisions. Q) what type of decisions can LPDP make? Q) all the process decisions r to be cached in LPDP also? Q) Is LPDP has all the policy info or can access the polices stored in policy repository? Q) can backup pdp decisions r final or else it has to again send it to primary pdp for final approval when connection is re-established with primary pdp? 3.3 RSVP's Capacity Admission Control: Commit and Delete In RSVP, the admission of a new reservation requires both an administrative approval (policy control) and capacity admission control. After being approved by both, and after the reservation was successfully installed, the PEP notifies the remote PDP by sending a report message specifying the Commit type. Q) where is the reservation installed? Q)who takes care of installing these Reservation? From owner-rap@ops.ietf.org Wed Mar 14 05:48:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21868 for ; Wed, 14 Mar 2001 05:48:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14d8oz-0007Hq-00 for rap-data@psg.com; Wed, 14 Mar 2001 02:48:01 -0800 Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14d8ow-0007Hd-00 for rap@ops.ietf.org; Wed, 14 Mar 2001 02:47:59 -0800 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id LAA15157; Wed, 14 Mar 2001 11:47:55 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA01126; Wed, 14 Mar 2001 11:47:55 +0100 Date: Wed, 14 Mar 2001 11:47:55 +0100 Message-Id: <200103141047.LAA01126@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: scott.hahn@intel.com CC: mstevens@ellacoya.com, rap@ops.ietf.org In-reply-to: <4148FEAAD879D311AC5700A0C969E8905730EF@orsmsx35.jf.intel.com> (scott.hahn@intel.com) Subject: Re: RAP Working Group Re-chartering References: <4148FEAAD879D311AC5700A0C969E8905730EF@orsmsx35.jf.intel.com> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Hahn, Scott writes: Scott> Juergen, I think you are reading more into this than there Scott> is. This paragraph refers to the ongoing SPPI and Framework Scott> PIB. The SPPI is at the hands of the IESG. The framework PIB Scott> went through WG last call, but resulted in a few minor changes Scott> and I believe will do another last call. These were left in the Scott> charter because the work is still going on. It is *not* another Scott> SPPI. OK, I now understand what the text was trying to say. Perhaps the charter text on this point could be simplified as follows: - Complete work on standards track documents for (a) the data definition language for COPS-PR [SPPI] and (b) the set of core data definitions for QoS policy provisioning [FRWKPIB]. This text would have been much clearer to me. /js From owner-rap@ops.ietf.org Wed Mar 14 14:14:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01693 for ; Wed, 14 Mar 2001 14:14:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dGf2-000DpF-00 for rap-data@psg.com; Wed, 14 Mar 2001 11:10:16 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14dGf1-000Dny-00 for rap@ops.ietf.org; Wed, 14 Mar 2001 11:10:15 -0800 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.122.11]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GRBJV2XN; Wed, 14 Mar 2001 13:59:20 -0500 Message-ID: <3AAFC1F1.18D25ED4@ellacoya.com> Date: Wed, 14 Mar 2001 14:09:38 -0500 X-Sybari-Trust: 7559674b 050014de 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: agenda@ietf.org, rap@ops.ietf.org Subject: RAP Working Group Agenda for 50th IETF Meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Resource Allocation Protocol WG (rap) Tuesday, March 20 at 1300-1400 Wednesday, March 21 at 1300-1500 ================================ CHAIRS: Mark Stevens Scott Hahn AGENDA: Tuesday, March 20 ================= Minutes Takers & Blue Sheets Agenda Bashing Brief Review of Milestones and Status Louis-Nicolas Hamer http://www.ietf.org/internet-drafts/draft-hamer-rap-session-auth-00.txt Kwok-Ho Chan http://www.ietf.org/internet-drafts/draft-hkg-rap-rsvp-authsession-00.txt Amol Kulkarni , -Framework of COPS-PR PIB for Accounting Usage Lei Yao Diana Rawlins -RSVP Policy Control PIB Wednesday, March 21 =================== Mark Stevens, Scott Hahn, et alii Charter Discussion/Work Planning etc. From owner-rap@ops.ietf.org Wed Mar 14 16:53:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05254 for ; Wed, 14 Mar 2001 16:53:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dJBf-000FO1-00 for rap-data@psg.com; Wed, 14 Mar 2001 13:52:07 -0800 Received: from femail2.rdc1.on.home.com ([24.2.9.89]) by psg.com with esmtp (Exim 3.16 #1) id 14dJBe-000FNm-00 for rap@ops.ietf.org; Wed, 14 Mar 2001 13:52:06 -0800 Received: from crete ([24.112.129.233]) by femail2.rdc1.on.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010314215149.WNR15836.femail2.rdc1.on.home.com@crete> for ; Wed, 14 Mar 2001 13:51:49 -0800 Message-ID: <004f01c0acd0$f6b3fde0$e9817018@crete> From: "Andreas Polyrakis" To: Subject: the 'Extends' clause Date: Wed, 14 Mar 2001 16:51:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, one simple question on the SPPI: Suppose that there is a class A, which is extended by two classes B and C. It there a way to denote that instances of A MUST be extended by either an instance of B or an instance of C? So that that for each PRI in A, either a PRIs in B or in C exist? thanks in advance, Andreas From owner-rap@ops.ietf.org Wed Mar 14 17:19:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05633 for ; Wed, 14 Mar 2001 17:19:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dJaz-000Fbv-00 for rap-data@psg.com; Wed, 14 Mar 2001 14:18:17 -0800 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.16 #1) id 14dJay-000Fbl-00 for rap@ops.ietf.org; Wed, 14 Mar 2001 14:18:16 -0800 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id WAA15427; Wed, 14 Mar 2001 22:17:21 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 14 Mar 2001 22:17:09 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 14:17:03 -0800 Message-ID: <75F7304BB41CD411B06600A0C98414FC015B7089@ORSMSX54> From: "Sahita, Ravi" To: "'Andreas Polyrakis'" , rap@ops.ietf.org Subject: RE: the 'Extends' clause Date: Wed, 14 Mar 2001 14:14:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-rap@ops.ietf.org Precedence: bulk Andreas, What you are specifying here, is using class A as an abstract class which cannot be instantiated by itself. You can't specify this by using the EXTENDS clause, but you could force this relationship at the implementation level, i.e an instance of A cannot be received/sent if an instance of B OR C with the same instance id is not received/sent. Ravi -----Original Message----- From: Andreas Polyrakis [mailto:apolyr@cs.toronto.edu] Sent: Wednesday, March 14, 2001 1:52 PM To: rap@ops.ietf.org Subject: the 'Extends' clause Hi, one simple question on the SPPI: Suppose that there is a class A, which is extended by two classes B and C. It there a way to denote that instances of A MUST be extended by either an instance of B or an instance of C? So that that for each PRI in A, either a PRIs in B or in C exist? thanks in advance, Andreas From owner-rap@ops.ietf.org Wed Mar 14 17:32:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05765 for ; Wed, 14 Mar 2001 17:32:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dJn6-000Fkn-00 for rap-data@psg.com; Wed, 14 Mar 2001 14:30:48 -0800 Received: from femail2.rdc1.on.home.com ([24.2.9.89]) by psg.com with esmtp (Exim 3.16 #1) id 14dJn5-000Fkh-00 for rap@ops.ietf.org; Wed, 14 Mar 2001 14:30:48 -0800 Received: from crete ([24.112.129.233]) by femail2.rdc1.on.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010314223034.CFYW15836.femail2.rdc1.on.home.com@crete>; Wed, 14 Mar 2001 14:30:34 -0800 Message-ID: <007001c0acd6$60ce3740$e9817018@crete> From: "Andreas Polyrakis" To: "Sahita, Ravi" , References: <75F7304BB41CD411B06600A0C98414FC015B7089@ORSMSX54> Subject: Re: the 'Extends' clause Date: Wed, 14 Mar 2001 17:30:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So, if I got it right, you suggest that I should use EXTENDS to define the PIB, but apart from it, I must also specify in the PIB draft that PRIs of class A cannot be installed without also installing a PRI either in B or C... thank you very much for your prompt answer! Andreas > Andreas, > > What you are specifying here, is using class A as an abstract class which > cannot > be instantiated by itself. You can't specify this by using the EXTENDS > clause, but you could force this relationship at the implementation level, > i.e an > instance of A cannot be received/sent if an instance of B OR C with the same > instance id is not received/sent. > > thanks in advance, > Andreas From owner-rap@ops.ietf.org Wed Mar 14 19:56:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07273 for ; Wed, 14 Mar 2001 19:56:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dM2M-000HqW-00 for rap-data@psg.com; Wed, 14 Mar 2001 16:54:42 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14dM28-000HqG-00 for rap@ops.ietf.org; Wed, 14 Mar 2001 16:54:28 -0800 Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with ESMTP id AAA05439; Thu, 15 Mar 2001 00:54:04 GMT Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G9PSC1A9; Wed, 14 Mar 2001 16:54:03 -0800 Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 15 Mar 2001 00:14:13 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 16:13:22 -0800 Message-ID: <75F7304BB41CD411B06600A0C98414FC015B7089@ORSMSX54> From: "Sahita, Ravi" To: "'Andreas Polyrakis'" , rap@ops.ietf.org Subject: RE: the 'Extends' clause Date: Wed, 14 Mar 2001 14:14:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-rap@ops.ietf.org Precedence: bulk Andreas, What you are specifying here, is using class A as an abstract class which cannot be instantiated by itself. You can't specify this by using the EXTENDS clause, but you could force this relationship at the implementation level, i.e an instance of A cannot be received/sent if an instance of B OR C with the same instance id is not received/sent. Ravi -----Original Message----- From: Andreas Polyrakis [mailto:apolyr@cs.toronto.edu] Sent: Wednesday, March 14, 2001 1:52 PM To: rap@ops.ietf.org Subject: the 'Extends' clause Hi, one simple question on the SPPI: Suppose that there is a class A, which is extended by two classes B and C. It there a way to denote that instances of A MUST be extended by either an instance of B or an instance of C? So that that for each PRI in A, either a PRIs in B or in C exist? thanks in advance, Andreas From owner-rap@ops.ietf.org Thu Mar 15 10:40:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01425 for ; Thu, 15 Mar 2001 10:40:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dZqs-000996-00 for rap-data@psg.com; Thu, 15 Mar 2001 07:39:46 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14dZqr-00097j-00 for rap@ops.ietf.org; Thu, 15 Mar 2001 07:39:46 -0800 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.122.11]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GRBJVLDA; Thu, 15 Mar 2001 10:28:46 -0500 Message-ID: <3AB0E217.EA2B5920@ellacoya.com> Date: Thu, 15 Mar 2001 10:39:03 -0500 X-Sybari-Trust: 2246dabd 050014de 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Revised RAP Working Group Agenda for 50th IETF Meeting References: <3AAFC1F1.18D25ED4@ellacoya.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here is a revised agenda for the upcoming RAP working group meeting. Resource Allocation Protocol WG (rap) Tuesday, March 20 at 1300-1400 Wednesday, March 21 at 1300-1500 ================================ CHAIRS: Mark Stevens Scott Hahn AGENDA: Tuesday, March 20 ================= Minutes Takers & Blue Sheets Agenda Bashing Brief Review of Milestones and Status Louis-Nicolas Hamer http://www.ietf.org/internet-drafts/draft-hamer-rap-session-auth-00.txt Kwok-Ho Chan http://www.ietf.org/internet-drafts/draft-hkg-rap-rsvp-authsession-00.txt Amol Kulkarni , -Framework of COPS-PR PIB for Accounting Usage Lei Yao Diana Rawlins -RSVP Policy Control PIB Wednesday, March 21 =================== Christian Jacquenet will lead discussion of a COPS client-type designed or the enforcement of IP Traffic Engineering (IP TE) policies within IP networks. The usage of this IP TE COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes. http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-01.txt Mark Stevens, Scott Hahn, et alii Charter Discussion/Work Planning etc. From owner-rap@ops.ietf.org Thu Mar 15 13:55:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05424 for ; Thu, 15 Mar 2001 13:55:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dcrC-000BTV-00 for rap-data@psg.com; Thu, 15 Mar 2001 10:52:18 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14dcrB-000BTC-00 for rap@ops.ietf.org; Thu, 15 Mar 2001 10:52:17 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GA900MH95Q6GD@firewall.mcit.com> for rap@ops.ietf.org; Thu, 15 Mar 2001 18:51:42 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GA9005015PS3Y@pmismtp02.wcomnet.com>; Thu, 15 Mar 2001 18:51:42 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GA9003BB5PQI9@pmismtp02.wcomnet.com>; Thu, 15 Mar 2001 18:51:26 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 15 Mar 2001 18:51:26 +0000 Content-return: allowed Date: Thu, 15 Mar 2001 18:51:22 +0000 From: "Iliff, Tina" Subject: COPS-PR 05 question: Policy Updates To: "'rap@ops.ietf.org'" , "'diffserv-interest@external.cisco.com'" , "'diffserv@ietf.org'" Cc: "Ngo, Dai (c)" , "Chastain, Jean" Message-id: <492EB4A3F68CD411ABE800508B69362E14B6F7@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk All, I have a question pertaining to the PDP providing policy updates (specifically QoS/Diffserv PIB) to the PEP. Please let me know if this question belongs on another mailing list. Anyhow, can a PDP only send data from one or two tables in a DEC without also providing Interface Name and Role Combination data? In other words, would the PEP look at pointer values to determine what policy set this subset updates? Regards, Tina Iliff From owner-rap@ops.ietf.org Fri Mar 16 14:45:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09355 for ; Fri, 16 Mar 2001 14:45:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14e07Y-0007m4-00 for rap-data@psg.com; Fri, 16 Mar 2001 11:42:44 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14e07X-0007k5-00 for rap@ops.ietf.org; Fri, 16 Mar 2001 11:42:44 -0800 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GAB0058O2NO4B@firewall.mcit.com> for rap@ops.ietf.org; Fri, 16 Mar 2001 19:40:36 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GAB001012NJAJ@pmismtp02.wcomnet.com> for rap@ops.ietf.org; Fri, 16 Mar 2001 19:40:36 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GAB000AC2NA6J@pmismtp02.wcomnet.com> for rap@ops.ietf.org; Fri, 16 Mar 2001 19:40:22 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Fri, 16 Mar 2001 19:40:21 +0000 Content-return: allowed Date: Fri, 16 Mar 2001 19:40:20 +0000 From: "Iliff, Tina" Subject: FW: COPS-PR 05 question: Policy Updates To: "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F55EB@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Clarification...I am referring to an Unsolicited DEC when I say Policy Update Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Thursday, March 15, 2001 12:51 PM To: 'rap@ops.ietf.org'; 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org' Cc: Ngo, Dai (c); Chastain, Jean Subject: COPS-PR 05 question: Policy Updates All, I have a question pertaining to the PDP providing policy updates (specifically QoS/Diffserv PIB) to the PEP. Please let me know if this question belongs on another mailing list. Anyhow, can a PDP only send data from one or two tables in a DEC without also providing Interface Name and Role Combination data? In other words, would the PEP look at pointer values to determine what policy set this subset updates? Regards, Tina Iliff From owner-rap@ops.ietf.org Fri Mar 16 19:04:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15654 for ; Fri, 16 Mar 2001 19:04:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14e4CH-000DQ8-00 for rap-data@psg.com; Fri, 16 Mar 2001 16:03:53 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14e4CH-000DQ1-00 for rap@ops.ietf.org; Fri, 16 Mar 2001 16:03:53 -0800 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA24122; Sat, 17 Mar 2001 00:03:51 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 17 Mar 2001 00:03:51 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 16:03:49 -0800 Message-ID: <75F7304BB41CD411B06600A0C98414FC015B70A9@ORSMSX54> From: "Sahita, Ravi" To: "'Iliff, Tina'" , "'rap@ops.ietf.org'" , "'diffserv-interest@external.cisco.com'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] COPS-PR 05 question: Policy Updates Date: Fri, 16 Mar 2001 16:03:47 -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 Tina, I think that the PEP should be able to process the policy updates if the PDP makes sure that the references to the PRC instances in this changed subset of the PIB are still valid. Ravi -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, March 15, 2001 10:51 AM To: 'rap@ops.ietf.org'; 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org' Cc: Ngo, Dai (c); Chastain, Jean Subject: [Diffserv] COPS-PR 05 question: Policy Updates All, I have a question pertaining to the PDP providing policy updates (specifically QoS/Diffserv PIB) to the PEP. Please let me know if this question belongs on another mailing list. Anyhow, can a PDP only send data from one or two tables in a DEC without also providing Interface Name and Role Combination data? In other words, would the PEP look at pointer values to determine what policy set this subset updates? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml From owner-rap@ops.ietf.org Mon Mar 19 13:00:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16926 for ; Mon, 19 Mar 2001 13:00:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14f3wb-0002cu-00 for rap-data@psg.com; Mon, 19 Mar 2001 09:59:49 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14f3wa-0002cX-00 for rap@ops.ietf.org; Mon, 19 Mar 2001 09:59:49 -0800 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GAG00EIXHXQ4U@firewall.mcit.com> for rap@ops.ietf.org; Mon, 19 Mar 2001 17:58:38 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GAG00C01HXEKI@pmismtp04.wcomnet.com>; Mon, 19 Mar 2001 17:58:38 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GAG006NMHXCPM@pmismtp04.wcomnet.com>; Mon, 19 Mar 2001 17:58:24 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Mar 2001 17:58:24 +0000 Content-return: allowed Date: Mon, 19 Mar 2001 17:58:22 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] COPS-PR 05 question: Policy Updates To: "'Sahita, Ravi'" , "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F55F4@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_g57hw50P2bilKPtUWX9TWQ)" 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. --Boundary_(ID_g57hw50P2bilKPtUWX9TWQ) Content-type: text/plain; charset=ISO-8859-1 Ravi, Thanks. However, can one of the drat authors provide me with a more definitive answer as well as point me to the words in the draft which state the proper handling? Regards, Tina Iliff -----Original Message----- From: Sahita, Ravi [mailto:ravi.sahita@intel.com] Sent: Friday, March 16, 2001 6:04 PM To: Iliff, Tina; 'rap@ops.ietf.org'; 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org' Subject: RE: [Diffserv] COPS-PR 05 question: Policy Updates Tina, I think that the PEP should be able to process the policy updates if the PDP makes sure that the references to the PRC instances in this changed subset of the PIB are still valid. Ravi -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, March 15, 2001 10:51 AM To: 'rap@ops.ietf.org'; 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org' Cc: Ngo, Dai (c); Chastain, Jean Subject: [Diffserv] COPS-PR 05 question: Policy Updates All, I have a question pertaining to the PDP providing policy updates (specifically QoS/Diffserv PIB) to the PEP. Please let me know if this question belongs on another mailing list. Anyhow, can a PDP only send data from one or two tables in a DEC without also providing Interface Name and Role Combination data? In other words, would the PEP look at pointer values to determine what policy set this subset updates? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_g57hw50P2bilKPtUWX9TWQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] COPS-PR 05 question: Policy Updates

Ravi,

Thanks.  However, can one of the = drat authors provide me with a more definitive answer as well as point = me to the words in the draft which state the proper = handling?

Regards,
Tina Iliff


      -----Original = Message-----
      From:   Sahita, Ravi [mailto:ravi.sahita@intel.com]<= /FONT>
      Sent:   Friday, March 16, 2001 6:04 PM
      To:     Iliff, Tina; 'rap@ops.ietf.org'; = 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org'
      Subject:       = RE: [Diffserv] COPS-PR 05 = question:  Policy Updates

      Tina,

      I think that the PEP should be able to = process the policy
      updates if the PDP makes sure that = the references to the PRC
      instances in this changed subset of = the PIB are still valid.

      Ravi

      -----Original Message-----
      From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
      Sent: Thursday, March 15, 2001 10:51 = AM
      To: 'rap@ops.ietf.org'; = 'diffserv-interest@external.cisco.com';
      'diffserv@ietf.org'
      Cc: Ngo, Dai (c); Chastain, = Jean
      Subject: [Diffserv] COPS-PR 05 = question: Policy Updates


      All,

      I have a question pertaining to the = PDP providing policy updates
      (specifically QoS/Diffserv PIB) to = the PEP.  Please let me know if this
      question belongs on another mailing = list.  Anyhow, can a PDP only send data
      from one or two tables in a DEC = without also providing Interface Name and
      Role Combination data?  In other = words, would the PEP look at pointer values
      to determine what policy set this = subset updates?

      Regards,

      Tina Iliff

      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive:
      http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.h
      tml

--Boundary_(ID_g57hw50P2bilKPtUWX9TWQ)-- From owner-rap@ops.ietf.org Tue Mar 20 14:54:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21217 for ; Tue, 20 Mar 2001 14:54:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fSAj-000M5G-00 for rap-data@psg.com; Tue, 20 Mar 2001 11:52:01 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14fSAh-000M4b-00 for rap@ops.ietf.org; Tue, 20 Mar 2001 11:52:00 -0800 Received: from ellacoya.com (mstevens.ellacoya.com [10.99.10.114]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HF6VARHL; Tue, 20 Mar 2001 14:40:50 -0500 Message-ID: <3AB7B463.664EED74@ellacoya.com> Date: Tue, 20 Mar 2001 14:49:55 -0500 X-Sybari-Trust: 6379fcd5 050014de 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: For Discussion at the RAP WG Meeting on Wedneday March 21, 2001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is the current draft of the working group charter. We would like to discuss this charter at tomorrow's session. We will focus the discussion on making sure that we have people willing to contribute to each work item on the charter. ---begin charter draft--- Description of Working Group: Recent works in the IETF have led to the development and standardization of enhanced network services such as QoS and traffic engineering. The complexity of these services and the variations in the capabilities of the devices implementing these services provide a challenge to anyone trying to configure services within medium- and large-scale networks. The working group will define general-purpose objects that facilitate the manipulation of policies and provisioned objects available through COPS and COPS-PR. Where appropriate, these will include frameworks clarifying the applicability of COPS objects and the best practices for the definition of additional objects defined in other working groups. In particular, the group will address the following work items: - A framework for defining the usage of COPS for carrying accounting information: The working group will produce a standards track document defining the usage of COPS for carrying accounting information between a PDP and PEPs [ACCTFRWK]. - A standards track document describing an accounting PIB to be used to carry policy usage feedback from the PEP to the PDP [ACCTPIB]. - Complete work on standards track documents for (a) the data definition language for COPS-PR [SPPI] and (b) the set of core data definitions for QoS policy provisioning [FRWKPIB]. - A standards track document describing a modular architecture for a COPS based Management Framework. The document will address the COPS message processing, security and access control and may specify examples of how the framework may be implemented. [COPSFRWK] The working group will continue to document changes to COPS objects needed to support any extensions to RSVP and extensions to RVSP directly related to policy control. Specifically the working group will pursue: - A version of draft-ietf-rap-rsvp-newidentity that addresses security shortcomings with the current document [NEWIDENTITY]. - A standards track document defining new ErrorValues for the RSVP Policy Error Object [RSVPERRVAL]. - A standards track document defining the framework and mechanism for authorizing of RSVP sessions [SESSIONAUTH]. - A standards track document defining an RSVP Local Policy Control Criteria PIB [RSVPPIB]. Documents produced by the working group must fully address all the security aspects of this type of protocol. In particular, theft and denial of service threats must be minimized. Milestones and Goals Done Submit I-D framework document for policy control for RSVP to IESG for publication as a Proposed Standard Done Submit I-D defining any necessary extensions to RSVP to support policy control to IESG for publication as a Proposed Standard Done Submit I-D defining a standard protocol for the exchange of policy information between RSVP-capable network nodes and policy servers to IESG for publication as a Proposed Standard Done Submit Initial draft of document that specifies COPS usage for policy provisioning transactions Done Working Group last call on revised version of COPS Usage document incorporating mailing list discussions Done Submit COPS Usage document to IESG for publication as an Proposed Standard Done Submit object syntax transport protocol I-D Done Submit object syntax transport protocol (SPPI) to IESG for consideration as a RFC Dec 00 Submit I-D defining framework of COPS-PR PIB for accounting usage Mar 01 Submit Update draft ACCTPIB Apr 01 Submit FRWKPIB to IESG for consideration as a Proposed Standard Apr 01 Submit First draft RSVPPIB Apr 01 Submit First draft RSVPERRVAL Apr 01 Submit First draft SESSIONAUTH Jul 01 Submit First draft COPSFRWK Jul 01 Submit First draft of ACCTFRWK Jul 01 Submit First draft NEWIDENTITY Jul 01 Submit Update draft RSVPPIB Jul 01 Submit Update draft RSVPERRVAL Jul 01 Submit Update draft SESSIONAUTH Sep 01 Submit Update draft NEWIDENTITY Jul 01 Submit Update draft ACCTFRWK Jul 01 Submit Update draft COPSFRWK Jan 02 ACCTFRWK Draft to to AD/IESG for consideration as Proposed Standard Jan 02 ACCTPIB Draft to to AD/IESG for consideration as Proposed Standard Jan 02 NEWIDENTITY Draft to to AD/IESG for consideration as Proposed Standard Jan 02 RSVPPIB Draft to to AD/IESG for consideration as Proposed Standard Jan 02 RSVPERRVAL Draft to to AD/IESG for consideration as Proposed Standard Jan 02 SESSIONAUTH Draft to to AD/IESG for consideration as Proposed Standard Jan 02 COPSFRWK Draft to to AD/IESG for consideration as Proposed Standard From owner-rap@ops.ietf.org Wed Mar 21 21:23:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01627 for ; Wed, 21 Mar 2001 21:23:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fujz-0001Fe-00 for rap-data@psg.com; Wed, 21 Mar 2001 18:22:19 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14fujy-0001FX-00 for rap@ops.ietf.org; Wed, 21 Mar 2001 18:22:18 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14fujz-0004JR-00 for rap@ops.ietf.org; Wed, 21 Mar 2001 20:22:19 -0600 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart From: RFC Editor To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, rap@ops.ietf.org Subject: RFC 3084 on COPS-PR Sender: owner-rap@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 21 Mar 2001 18:22:19 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3084 Title: COPS Usage for Policy Provisioning (COPS-PR) Author(s): K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith Status: Standards Track Date: March 2001 Mailbox: khchan@nortelnetworks.com, david.durham@intel.com, sgai@cisco.com, Herzog@iphighway.com, kzm@cisco.com, franr@pfn.com, jseligso@nortelnetworks.com, raj.yavatkar@intel.com, andrew@allegronetworks.com Pages: 34 Characters: 79341 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rap-pr-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3084.txt This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned (QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The protocol extensions described in this document do not make any assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data. This document is a product of the Resource Allocation Protocol Working Group of IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010321161713.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3084 --OtherAccess Content-Type: Message/External-body; name="rfc3084.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010321161713.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Mon Mar 26 12:41:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12973 for ; Mon, 26 Mar 2001 12:41:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hay6-000OGQ-00 for rap-data@psg.com; Mon, 26 Mar 2001 09:39:50 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14hay5-000OG4-00 for rap@ops.ietf.org; Mon, 26 Mar 2001 09:39:49 -0800 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GAT000KWFP70A@firewall.mcit.com> for rap@ops.ietf.org; Mon, 26 Mar 2001 17:39:07 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GAT00201FP6U1@pmismtp01.wcomnet.com>; Mon, 26 Mar 2001 17:39:07 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GAT0025XFOR2A@pmismtp01.wcomnet.com>; Mon, 26 Mar 2001 17:38:52 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Mar 2001 17:38:51 +0000 Content-return: allowed Date: Mon, 26 Mar 2001 17:38:44 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] COPS-PR 05 question: Policy Updates To: "'Sahita, Ravi'" , "'rap@ops.ietf.org'" Cc: "Ngo, Dai (c)" , "Chastain, Jean" , "Sunlin, Richard (c)" Message-id: <492EB4A3F68CD411ABE800508B69362E3F564F@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_zi+tCehlxhBy1rGxvHt8cw)" 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. --Boundary_(ID_zi+tCehlxhBy1rGxvHt8cw) Content-type: text/plain; charset=iso-8859-1 Ravi, Thank you. However, lets take the following scenario, for example: A+B role combo includes PRC (qosPolicyPib.2.7) instanceId 10 C+D role combo also includes PRC (qosPolicyPib.2.7) instanceId 10 A policy update due to an external event has occurred. The policy updated includes an instance of qosPolicyPib.2.3 which references (qosPolicyPib.2.7) instanceId 10. Now, the administrator does not want the policy for role combo A+B to include this qosClfrElement. In this case, is it necessary for the PDP to provide the PEP with any RoleCombo/IfName/IfDirection information for the update? Regards, Tina Iliff -----Original Message----- From: Sahita, Ravi [mailto:ravi.sahita@intel.com] Sent: Friday, March 16, 2001 6:04 PM To: Iliff, Tina; 'rap@ops.ietf.org'; 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org' Subject: RE: [Diffserv] COPS-PR 05 question: Policy Updates Tina, I think that the PEP should be able to process the policy updates if the PDP makes sure that the references to the PRC instances in this changed subset of the PIB are still valid. Ravi -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, March 15, 2001 10:51 AM To: 'rap@ops.ietf.org'; 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org' Cc: Ngo, Dai (c); Chastain, Jean Subject: [Diffserv] COPS-PR 05 question: Policy Updates All, I have a question pertaining to the PDP providing policy updates (specifically QoS/Diffserv PIB) to the PEP. Please let me know if this question belongs on another mailing list. Anyhow, can a PDP only send data from one or two tables in a DEC without also providing Interface Name and Role Combination data? In other words, would the PEP look at pointer values to determine what policy set this subset updates? Regards, Tina Iliff _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_zi+tCehlxhBy1rGxvHt8cw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] COPS-PR 05 question: Policy Updates

Ravi,

Thank you.  However, lets take = the following scenario, for example:
A+B role combo includes PRC = (qosPolicyPib.2.7) instanceId 10
C+D role combo also includes = PRC (qosPolicyPib.2.7) instanceId 10

A policy update due to an external = event has occurred.  The policy updated includes an instance of = qosPolicyPib.2.3 which references (qosPolicyPib.2.7) instanceId 10.  Now, the administrator does not want the policy = for role combo A+B to include this qosClfrElement.  In this case, = is it necessary for the PDP to provide the PEP with any = RoleCombo/IfName/IfDirection information for the update?

Regards,
Tina Iliff


      -----Original = Message-----
      From:   Sahita, Ravi [mailto:ravi.sahita@intel.com]<= /FONT>
      Sent:   Friday, March 16, 2001 6:04 PM
      To:     Iliff, Tina; 'rap@ops.ietf.org'; = 'diffserv-interest@external.cisco.com'; 'diffserv@ietf.org'
      Subject:       = RE: [Diffserv] COPS-PR 05 = question:  Policy Updates

      Tina,

      I think that the PEP should be able to = process the policy
      updates if the PDP makes sure that = the references to the PRC
      instances in this changed subset of = the PIB are still valid.

      Ravi

      -----Original Message-----
      From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
      Sent: Thursday, March 15, 2001 10:51 = AM
      To: 'rap@ops.ietf.org'; = 'diffserv-interest@external.cisco.com';
      'diffserv@ietf.org'
      Cc: Ngo, Dai (c); Chastain, = Jean
      Subject: [Diffserv] COPS-PR 05 = question: Policy Updates


      All,

      I have a question pertaining to the = PDP providing policy updates
      (specifically QoS/Diffserv PIB) to = the PEP.  Please let me know if this
      question belongs on another mailing = list.  Anyhow, can a PDP only send data
      from one or two tables in a DEC = without also providing Interface Name and
      Role Combination data?  In other = words, would the PEP look at pointer values
      to determine what policy set this = subset updates?

      Regards,

      Tina Iliff

      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive:
      http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.h
      tml

--Boundary_(ID_zi+tCehlxhBy1rGxvHt8cw)-- From owner-rap@ops.ietf.org Mon Mar 26 14:25:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14664 for ; Mon, 26 Mar 2001 14:25:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hcak-0001Nc-00 for rap-data@psg.com; Mon, 26 Mar 2001 11:23:50 -0800 Received: from alemail1.lucent.com ([192.11.221.161] helo=alemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.16 #1) id 14hcaj-0001NT-00 for rap@ops.ietf.org; Mon, 26 Mar 2001 11:23:49 -0800 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA20558 for ; Mon, 26 Mar 2001 14:23:48 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA20500 for ; Mon, 26 Mar 2001 14:23:47 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 21:23:46 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0BC9A579@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: rap Subject: FW: RFC 3084 on COPS-PR Date: Mon, 26 Mar 2001 21:23:38 +0200 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 Good work by the authors and the WG. SPPI and Framework PIB are next Bert > ---------- > From: RFC Editor[SMTP:rfc-ed@ISI.EDU] > Sent: Thursday, March 22, 2001 4:22 AM > Cc: rfc-ed@ISI.EDU; rap@ops.ietf.org > Subject: RFC 3084 on COPS-PR > > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3084 > > Title: COPS Usage for Policy Provisioning (COPS-PR) > Author(s): K. Chan, J. Seligson, D. Durham, S. Gai, > K. McCloghrie, S. Herzog, F. Reichmeyer, > R. Yavatkar, A. Smith > Status: Standards Track > Date: March 2001 > Mailbox: khchan@nortelnetworks.com, david.durham@intel.com, > sgai@cisco.com, Herzog@iphighway.com, > kzm@cisco.com, franr@pfn.com, > jseligso@nortelnetworks.com, > raj.yavatkar@intel.com, andrew@allegronetworks.com > > Pages: 34 > Characters: 79341 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-rap-pr-05.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3084.txt > > > This document describes the use of the Common Open Policy Service > (COPS) protocol for support of policy provisioning (COPS-PR). This > specification is independent of the type of policy being provisioned > (QoS, Security, etc.) but focuses on the mechanisms and conventions > used to communicate provisioned information between PDPs and PEPs. > The protocol extensions described in this document do not make any > assumptions about the policy data model being communicated, but > describe the message formats and objects that carry the modeled policy > data. > > This document is a product of the Resource Allocation Protocol Working > Group of IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > From owner-rap@ops.ietf.org Thu Mar 29 06:11:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07092 for ; Thu, 29 Mar 2001 06:11:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iaIg-000Ivy-00 for rap-data@psg.com; Thu, 29 Mar 2001 03:09:10 -0800 Received: from mail5.registeredsite.com ([64.224.9.14]) by psg.com with esmtp (Exim 3.16 #1) id 14iaIf-000IvF-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 03:09:09 -0800 Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217]) by mail5.registeredsite.com (8.11.1/8.11.1) with ESMTP id f2TB98H15581 for ; Thu, 29 Mar 2001 06:09:08 -0500 Date: Thu, 29 Mar 2001 06:09:05 -0500 Message-Id: <200103290609.AA500760864@mail.cominsights.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "vijains" Reply-To: To: Subject: COPS-PR X-Mailer: Sender: owner-rap@ops.ietf.org Precedence: bulk Respected Sir/Madam, I have not received any response for my previous mail.So, i am resending the same:- Q1.What are the Client-Types for COPS-PR and what are their values? Q2.If an SDK is developed for COPS-PR, what should the user of the SDK specify as a EPD object? Q3.As a PIB may be referencing other modules or objects in other MIB or PIB, how should the encoder take care of it? Please lat me know. From owner-rap@ops.ietf.org Thu Mar 29 08:24:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13558 for ; Thu, 29 Mar 2001 08:24:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14icNL-000LWg-00 for rap-data@psg.com; Thu, 29 Mar 2001 05:22:07 -0800 Received: from 64-48-118-19.customer.algx.net ([64.48.118.19] helo=cplane.com) by psg.com with smtp (Exim 3.16 #1) id 14icNK-000LWY-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 05:22:06 -0800 Received: (qmail 27040 invoked from network); 29 Mar 2001 13:13:48 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 29 Mar 2001 13:13:48 -0000 Received: (qmail 23563 invoked from network); 29 Mar 2001 13:22:03 -0000 Received: from unknown (HELO bombay.cplane.com) (unknown) by unknown with SMTP; 29 Mar 2001 13:22:03 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Rajiv Dighe Reply-To: rajiv@cplane.com Organization: CPlane Inc. To: "vijains" , Subject: Re: COPS-PR Date: Thu, 29 Mar 2001 08:14:41 -0500 X-Mailer: KMail [version 1.2] References: <200103290609.AA500760864@mail.cominsights.com> In-Reply-To: <200103290609.AA500760864@mail.cominsights.com> MIME-Version: 1.0 Message-Id: <01032908144101.05365@bombay.cplane.com> Content-Transfer-Encoding: 8bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Q1 is easy to answer. COPS-PR uses 02 as client-type. there is only one client type for cops-pr that I know of. Q2 & Q3 are implementation details & This mailing list may be wrong place to ask/answer those questions. If you can clarify your questions a bit by dropping me a private e-mail, I may be able to help. --Rajiv On Thursday 29 March 2001 06:09, vijains wrote: > Respected Sir/Madam, > I have not received any response for my previous mail.So, i am > resending the same:- > > Q1.What are the Client-Types for COPS-PR and what are their values? > > Q2.If an SDK is developed for COPS-PR, what should the user of the SDK > specify as a EPD object? > > Q3.As a PIB may be referencing other modules or objects in other MIB or > PIB, how should the encoder take care of it? > > > Please lat me know. From owner-rap@ops.ietf.org Thu Mar 29 10:12:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17450 for ; Thu, 29 Mar 2001 10:12:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ie5B-000NtP-00 for rap-data@psg.com; Thu, 29 Mar 2001 07:11:29 -0800 Received: from web13205.mail.yahoo.com ([216.136.174.190]) by psg.com with smtp (Exim 3.16 #1) id 14ie5A-000NtI-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 07:11:28 -0800 Message-ID: <20010329151124.31536.qmail@web13205.mail.yahoo.com> Received: from [193.243.161.92] by web13205.mail.yahoo.com; Thu, 29 Mar 2001 07:11:24 PST Date: Thu, 29 Mar 2001 07:11:24 -0800 (PST) From: Marc briand Subject: COPS-RSVP To: rap@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rap@ops.ietf.org Precedence: bulk Dear all, I am using the Intel COPS SDK extension for RSVP and I didn'y get some things. It seems that the commands RESV and PATH can be used to set a rsvp action (PEP --REQ--> PDP), but what is the difference between the Command PATH and RESV? And between PATH and PATHERR And between RESV and RESVERR Excuse me since these questions could seem basic but it has a lot of importance here! I look forward to hearing from you all. Thanks in advance marc. __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text From owner-rap@ops.ietf.org Thu Mar 29 10:32:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18649 for ; Thu, 29 Mar 2001 10:32:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ieNw-000OIF-00 for rap-data@psg.com; Thu, 29 Mar 2001 07:30:52 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14ieNv-000OI8-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 07:30:51 -0800 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GAY00I09TQUB6@firewall.mcit.com> for rap@ops.ietf.org; Thu, 29 Mar 2001 15:30:30 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GAY00801TQUTP@pmismtp01.wcomnet.com>; Thu, 29 Mar 2001 15:30:30 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GAY00808TQBJC@pmismtp01.wcomnet.com>; Thu, 29 Mar 2001 15:30:11 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Mar 2001 15:30:11 +0000 Content-return: allowed Date: Thu, 29 Mar 2001 15:30:09 +0000 From: "Iliff, Tina" Subject: RE: COPS-RSVP To: "'Marc briand'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F5675@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_m/MEofAKCQavabHUCc+QUA)" 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. --Boundary_(ID_m/MEofAKCQavabHUCc+QUA) Content-type: text/plain; charset=iso-8859-1 Marc, Please reference RFC 2749 and RFC 2205 Tina Iliff -----Original Message----- From: Marc briand [mailto:marc_briand@yahoo.com] Sent: Thursday, March 29, 2001 9:11 AM To: rap@ops.ietf.org Subject: COPS-RSVP Dear all, I am using the Intel COPS SDK extension for RSVP and I didn'y get some things. It seems that the commands RESV and PATH can be used to set a rsvp action (PEP --REQ--> PDP), but what is the difference between the Command PATH and RESV? And between PATH and PATHERR And between RESV and RESVERR Excuse me since these questions could seem basic but it has a lot of importance here! I look forward to hearing from you all. Thanks in advance marc. __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text --Boundary_(ID_m/MEofAKCQavabHUCc+QUA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: COPS-RSVP

Marc,

Please reference RFC 2749 and RFC = 2205
Tina Iliff


      -----Original = Message-----
      From:   Marc briand [mailto:marc_briand@yahoo.com]<= /FONT>
      Sent:   Thursday, March 29, 2001 9:11 AM
      To:     rap@ops.ietf.org
      Subject:       = COPS-RSVP

      Dear all,
      I am using the Intel COPS SDK = extension for RSVP and I
      didn'y get some things.
      It seems that the commands RESV and = PATH can be used
      to set a rsvp action (PEP --REQ--> = PDP), but what is
      the difference between the Command = PATH and RESV?
      And between PATH and PATHERR
      And between RESV and RESVERR

      Excuse me since these questions could = seem basic but
      it has a lot of importance = here!

      I look forward to hearing from you = all.

      Thanks in advance

      marc.



      __________________________________________________=
      Do You Yahoo!?
      Get email at your own domain with = Yahoo! Mail.
      http://personal.mail.yahoo.com/?.refer=3Dtext

--Boundary_(ID_m/MEofAKCQavabHUCc+QUA)-- From owner-rap@ops.ietf.org Thu Mar 29 10:55:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20192 for ; Thu, 29 Mar 2001 10:55:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ieke-000OpU-00 for rap-data@psg.com; Thu, 29 Mar 2001 07:54:20 -0800 Received: from [212.110.43.2] (helo=ns.collegioeinaudi.it) by psg.com with esmtp (Exim 3.16 #1) id 14iekY-000Ooz-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 07:54:18 -0800 Received: from ns.bobbio.private (ns.bobbio.private [192.168.1.1]) by ns.collegioeinaudi.it (8.9.3/8.9.3) with SMTP id RAA05083 for ; Thu, 29 Mar 2001 17:51:20 +0200 Received: from mordicchio (unverified [192.168.1.222]) by ns.bobbio.private (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 29 Mar 2001 18:02:37 +0100 Message-ID: <005701c0b868$995b9740$0202a8c0@mordicchio> From: "Vito Pinto" To: , References: <200103290609.AA500760864@mail.cominsights.com> <01032908144101.05365@bombay.cplane.com> Subject: Re: COPS-PR Date: Thu, 29 Mar 2001 17:50:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA20192 ----- Original Message ----- From: "Rajiv Dighe" To: "vijains" ; Sent: Thursday, March 29, 2001 3:14 PM Subject: Re: COPS-PR > Q1 is easy to answer. COPS-PR uses 02 as client-type. there is only one > client type for cops-pr that I know of. I have a doubt about this: reading the entire COPS-PR RFC and especially the "IANA Consideration" section we find that: 9. IANA Considerations COPS for Policy Provisioning follows the same IANA considerations for COPS objects as the base COPS protocol [COPS]. COPS-PR has defined one additional Decision Flag value of 0x02, extending the COPS base protocol only by this one value. No new COPS Client- Types are defined by this document. The last sentence explicitly says that no new Client-type are defined, so: Q1: what document specifies the client-type value of 2 ? Q2: if not specified, what Client-type COPS-PR clients have to use? Regards Vito Pinto From owner-rap@ops.ietf.org Thu Mar 29 11:27:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22182 for ; Thu, 29 Mar 2001 11:27:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ifEs-000PXu-00 for rap-data@psg.com; Thu, 29 Mar 2001 08:25:34 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14ifEr-000PWd-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 08:25:33 -0800 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GAY00J99W6UY6@firewall.mcit.com> for rap@ops.ietf.org; Thu, 29 Mar 2001 16:23:19 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GAY00801W6Q45@dgismtp02.wcomnet.com>; Thu, 29 Mar 2001 16:23:18 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GAY006CUW6DA0@dgismtp02.wcomnet.com>; Thu, 29 Mar 2001 16:23:01 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Mar 2001 16:23:00 +0000 Content-return: allowed Date: Thu, 29 Mar 2001 16:22:57 +0000 From: "Iliff, Tina" Subject: RE: COPS-PR To: "'Vito Pinto'" , rajiv@cplane.com, rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F5677@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_hl0IBIJ83ikKYwreLdobbw)" 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. --Boundary_(ID_hl0IBIJ83ikKYwreLdobbw) Content-type: text/plain; charset=ISO-8859-1 Vito, Please reference the diffserv-pib-03 draft, specifically Section 9. Subect Category Considerations The numbering space used for the DiffServ PIB, as indicated by the SUBJECT-CATEGORIES clause, will be assigned by the Internet Assigned Numbers Authority (IANA). Notice the numbering space used by SUBJECT- CATEGORIES maps to the Client Type numbering space in [COPS-PR]. This relationship is detailed in section 7.1 of [SPPI]. Due to the fact that Client Type value of 1 has already been used by [COPS-RSVP], the numbering space for SUBJECT-CATEGORIES will need to start with the value of 2. COPS-PR can support multiple COPS Client-Type values. The Client-Type specified for QoS is 2. Regards, Tina Iliff -----Original Message----- From: Vito Pinto [mailto:vito_pinto@netgroup-serv.polito.it] Sent: Thursday, March 29, 2001 9:51 AM To: rajiv@cplane.com; rap@ops.ietf.org Subject: Re: COPS-PR ----- Original Message ----- From: "Rajiv Dighe" To: "vijains" ; Sent: Thursday, March 29, 2001 3:14 PM Subject: Re: COPS-PR > Q1 is easy to answer. COPS-PR uses 02 as client-type. there is only one > client type for cops-pr that I know of. I have a doubt about this: reading the entire COPS-PR RFC and especially the "IANA Consideration" section we find that: 9. IANA Considerations COPS for Policy Provisioning follows the same IANA considerations for COPS objects as the base COPS protocol [COPS]. COPS-PR has defined one additional Decision Flag value of 0x02, extending the COPS base protocol only by this one value. No new COPS Client- Types are defined by this document. The last sentence explicitly says that no new Client-type are defined, so: Q1: what document specifies the client-type value of 2 ? Q2: if not specified, what Client-type COPS-PR clients have to use? Regards Vito Pinto --Boundary_(ID_hl0IBIJ83ikKYwreLdobbw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: COPS-PR

Vito,

Please reference the diffserv-pib-03 = draft, specifically Section 9.

Subect Category = Considerations

The numbering space used for the = DiffServ PIB, as indicated by the
SUBJECT-CATEGORIES clause, will = be assigned by the Internet Assigned
Numbers Authority (IANA).  = Notice the numbering space used by SUBJECT-
CATEGORIES maps to the Client = Type numbering space in [COPS-PR].  This
relationship is detailed in = section 7.1 of [SPPI].  Due to the fact that
Client Type value of 1 has = already been used by [COPS-RSVP], the
numbering space for = SUBJECT-CATEGORIES will need to start with the value
of 2.

COPS-PR can support multiple COPS = Client-Type values.  The Client-Type specified for QoS is = 2.

Regards,

Tina Iliff


      -----Original = Message-----
      From:   Vito Pinto [mailto:vito_pinto@net= group-serv.polito.it]
      Sent:   Thursday, March 29, 2001 9:51 AM
      To:     rajiv@cplane.com; rap@ops.ietf.org
      Subject:       = Re: COPS-PR


      ----- Original Message -----
      From: "Rajiv Dighe" = <rajiv@cplane.com>
      To: "vijains" = <vijains@mail.cominsights.com>; <rap@ops.ietf.org>
      Sent: Thursday, March 29, 2001 3:14 = PM
      Subject: Re: COPS-PR


      > Q1 is easy to answer. COPS-PR = uses 02 as client-type. there is only one
      > client type for cops-pr that I = know of.

      I have a doubt about this: reading the = entire COPS-PR RFC and especially
      the "IANA Consideration" = section we find that:


      9. IANA Considerations

         COPS for Policy = Provisioning follows the same IANA considerations for
         COPS objects as the base = COPS protocol [COPS].  COPS-PR has defined
         one additional Decision = Flag value of 0x02, extending the COPS base
         protocol only by this = one value.  No new COPS Client- Types are
         defined by this = document.

      The last sentence explicitly says that = no new Client-type are defined, so:
      Q1: what document specifies the = client-type value of 2 ?
      Q2: if not specified, what = Client-type COPS-PR clients have to use?

      Regards
      Vito Pinto

--Boundary_(ID_hl0IBIJ83ikKYwreLdobbw)-- From owner-rap@ops.ietf.org Thu Mar 29 11:31:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22425 for ; Thu, 29 Mar 2001 11:31:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ifJ0-000Pe8-00 for rap-data@psg.com; Thu, 29 Mar 2001 08:29:50 -0800 Received: from 64-48-118-19.customer.algx.net ([64.48.118.19] helo=cplane.com) by psg.com with smtp (Exim 3.16 #1) id 14ifIy-000Pe2-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 08:29:48 -0800 Received: (qmail 27614 invoked from network); 29 Mar 2001 16:21:31 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 29 Mar 2001 16:21:31 -0000 Received: (qmail 20110 invoked from network); 29 Mar 2001 16:29:48 -0000 Received: from unknown (HELO bombay.cplane.com) (unknown) by unknown with SMTP; 29 Mar 2001 16:29:48 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Rajiv Dighe Reply-To: rajiv@cplane.com Organization: CPlane Inc. To: "Vito Pinto" , Subject: Re: COPS-PR Date: Thu, 29 Mar 2001 11:22:24 -0500 X-Mailer: KMail [version 1.2] References: <200103290609.AA500760864@mail.cominsights.com> <01032908144101.05365@bombay.cplane.com> <005701c0b868$995b9740$0202a8c0@mordicchio> In-Reply-To: <005701c0b868$995b9740$0202a8c0@mordicchio> MIME-Version: 1.0 Message-Id: <01032911222405.05365@bombay.cplane.com> Content-Transfer-Encoding: 8bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I guess I haven't read drafts in a long time...have I? :) This is what SPPI mentions about client types --------------------------------- 7. Mapping of the MODULE-IDENTITY macro 7.1. Mapping of the SUBJECT-CATEGORIES clause The SUBJECT-CATEGORIES clause, which must be present, identifies one or more categories of provisioning data for which this PIB module defines provisioning information. For use with the COPS-PR protocol, the individual subject categories are mapped to COPS Client Types [COPS-PR]. ----------------------------------------------------- This implies that it is infact PIB module that identifies client-type to be used. client type needed can be either 'all' or list of one or more named-number enumerations where number is greater than zero. So Framework PIB has SUBJECT-CATEGORY of 'all' & diffserv PIB has SUBJECT-CATEGORY that is as of now not determined. Last I heard however everyone was supposed to use same client type as the one used in older COPS-DS ( 02 ). Atleast that's what the client type used in Last interoperability tests was. So I guess we should be asking this question in diffserv mailing list & not here. --Rajiv On Thursday 29 March 2001 10:50, Vito Pinto wrote: > ----- Original Message ----- > From: "Rajiv Dighe" > To: "vijains" ; > Sent: Thursday, March 29, 2001 3:14 PM > Subject: Re: COPS-PR > > > Q1 is easy to answer. COPS-PR uses 02 as client-type. there is only one > > client type for cops-pr that I know of. > > I have a doubt about this: reading the entire COPS-PR RFC and especially > the "IANA Consideration" section we find that: > > > 9. IANA Considerations > > COPS for Policy Provisioning follows the same IANA considerations for > COPS objects as the base COPS protocol [COPS]. COPS-PR has defined > one additional Decision Flag value of 0x02, extending the COPS base > protocol only by this one value. No new COPS Client- Types are > defined by this document. > > The last sentence explicitly says that no new Client-type are defined, so: > Q1: what document specifies the client-type value of 2 ? > Q2: if not specified, what Client-type COPS-PR clients have to use? > > Regards > Vito Pinto From owner-rap@ops.ietf.org Thu Mar 29 12:35:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26831 for ; Thu, 29 Mar 2001 12:35:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14igId-00011K-00 for rap-data@psg.com; Thu, 29 Mar 2001 09:33:31 -0800 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.16 #1) id 14igId-00010H-00 for rap@ops.ietf.org; Thu, 29 Mar 2001 09:33:31 -0800 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id RAA22648; Thu, 29 Mar 2001 17:32:31 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 29 Mar 2001 17:32:27 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Mar 2001 09:32:26 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E8900688757C@orsmsx35.jf.intel.com> From: "Hahn, Scott" To: "Iliff, Tina" , "'Vito Pinto'" , rajiv@cplane.com, rap@ops.ietf.org Subject: RE: COPS-PR Date: Thu, 29 Mar 2001 09:32:18 -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 This is correct, COPS-PR does not have a client type. Instead the client types are defined to represent non overlapping areas of policy (e.g. QoS) and each PIB specifies which area that PIB applies to in it's SUBJECT CATEGORY. Since a PEP can only have one PDP for a given client type, this allows the PEP to support multiple managers that manage different areas. -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, March 29, 2001 8:23 AM To: 'Vito Pinto'; rajiv@cplane.com; rap@ops.ietf.org Subject: RE: COPS-PR Vito, Please reference the diffserv-pib-03 draft, specifically Section 9. Subect Category Considerations The numbering space used for the DiffServ PIB, as indicated by the SUBJECT-CATEGORIES clause, will be assigned by the Internet Assigned Numbers Authority (IANA). Notice the numbering space used by SUBJECT- CATEGORIES maps to the Client Type numbering space in [COPS-PR]. This relationship is detailed in section 7.1 of [SPPI]. Due to the fact that Client Type value of 1 has already been used by [COPS-RSVP], the numbering space for SUBJECT-CATEGORIES will need to start with the value of 2. COPS-PR can support multiple COPS Client-Type values. The Client-Type specified for QoS is 2. Regards, Tina Iliff -----Original Message----- From: Vito Pinto [mailto:vito_pinto@netgroup-serv.polito.it] Sent: Thursday, March 29, 2001 9:51 AM To: rajiv@cplane.com; rap@ops.ietf.org Subject: Re: COPS-PR ----- Original Message ----- From: "Rajiv Dighe" To: "vijains" ; Sent: Thursday, March 29, 2001 3:14 PM Subject: Re: COPS-PR > Q1 is easy to answer. COPS-PR uses 02 as client-type. there is only one > client type for cops-pr that I know of. I have a doubt about this: reading the entire COPS-PR RFC and especially the "IANA Consideration" section we find that: 9. IANA Considerations COPS for Policy Provisioning follows the same IANA considerations for COPS objects as the base COPS protocol [COPS]. COPS-PR has defined one additional Decision Flag value of 0x02, extending the COPS base protocol only by this one value. No new COPS Client- Types are defined by this document. The last sentence explicitly says that no new Client-type are defined, so: Q1: what document specifies the client-type value of 2 ? Q2: if not specified, what Client-type COPS-PR clients have to use? Regards Vito Pinto From owner-rap@ops.ietf.org Fri Mar 30 06:51:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08547 for ; Fri, 30 Mar 2001 06:51:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ixLw-000NSf-00 for rap-data@psg.com; Fri, 30 Mar 2001 03:46:04 -0800 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.16 #1) id 14ixLr-000NST-00 for rap@ops.ietf.org; Fri, 30 Mar 2001 03:46:01 -0800 Received: from hdcvwall.wipsys.stph.net (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id RAA02325 for ; Fri, 30 Mar 2001 17:17:45 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GB0E3I00.780 for ; Fri, 30 Mar 2001 17:17:42 +0530 Message-ID: <3AC47096.8B69A733@wipro.com> Date: Fri, 30 Mar 2001 17:10:06 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF RAP WG Subject: turnaround time Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, How may seconds is the sensible turnaround time for a COPS-RSVP client between generation of REQ and receiving corresponding DEC. (Assuming COPS-RSVP Client and COPS-RSVP server are on different machines but at same location). regards Krishna