From owner-rap@ops.ietf.org Wed Aug 1 06:54: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 GAA26510 for ; Wed, 1 Aug 2001 06:54:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RteD-0009IV-00 for rap-data@psg.com; Wed, 01 Aug 2001 03:54:41 -0700 Received: from cms3.etri.re.kr ([129.254.16.13]) by psg.com with esmtp (Exim 3.31 #1) id 15RteB-0009IJ-00 for rap@ops.ietf.org; Wed, 01 Aug 2001 03:54:40 -0700 Received: from BJLEE (lbj63112.etri.re.kr [129.254.191.69]) by cms3.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBP5L4DN; Wed, 1 Aug 2001 19:53:05 +0900 Message-ID: <001301c11a78$37053390$9afeffcb@BJLEE> From: =?ks_c_5601-1987?B?wMy6tMHY?= To: , "Durham, David" References: <10C8636AE359D4119118009027AE99870DA5D9E0@FMSMSX34> Subject: Re: [Q] COPS Error Obj Date: Wed, 1 Aug 2001 19:53:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you for your kind reply. > > > > Sorry for Another Question. > > When sending CC message to PEP in that case, > > Integrity Obj should be included in it? > > [Dave] Yes it should be included (though not including it will acheive the > same result:-) ). But I don't think that it 'should' be included. Because the PEP trying to negotiate with PEP about security would not expect the Integrity Obj will be returned in the CC message. (Although he's trying that procedure twice, He probably think that he's currently do the opening procedure to PDP for the first time.) I think that RFC does not mention about this, is that right? And if you don't mind, I'd like to give you another question. What should PDP do when PEP sent another OPN message after PDP already received that OPN message? I know that PDP should send CC message to PEP, but I'm not sure which Error code should CC contain. :-( I think that RFC does not include Error code for the cases that Wrong Message sequence are followed. - - - Byung-Joon Lee, Network Architecture Team of ETRI lbj63112@etri.re.kr +82 42 860 1728 http://oopsla.snu.ac.kr/~bjlee > > > > > > ----- Original Message ----- > > From: "Durham, David" > > To: "'???'" ; > > Sent: Tuesday, July 31, 2001 10:38 AM > > Subject: RE: [Q] COPS Error Obj > > > > > > > Error #14 Authentication Failure would be appropriate here. > > > Cheers, > > > -Dave > > > > > > > -----Original Message----- > > > > From: lbj63112@etri.re.kr [mailto:lbj63112@etri.re.kr] > > > > Sent: Monday, July 30, 2001 6:23 PM > > > > To: rap@ops.ietf.org > > > > Subject: [Q] COPS Error Obj > > > > > > > > > > > > According to RFC 2748, the security and sequence number > > > > negotiation phase should be done only once. (page 29) > > > > If that statement is correct, then what Error Code the > > COPS Error Obj > > > > should contain when PEP tries to send another OPN message > > > > after negotiation is finished already, and PDP replies to > > that message > > > > with CC message? > > > > > > > > Thank you in advance, and sorry for this abrupt question. > > > > > > > > - - - > > > > Byung-Joon Lee, > > > > Network Architecture Team of ETRI > > > > lbj63112@etri.re.kr +82 42 860 1728 > > > > http://oopsla.snu.ac.kr/~bjlee > > > > > > > > > > > > > > > > > > > > From owner-rap@ops.ietf.org Thu Aug 2 00:58: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 AAA23843 for ; Thu, 2 Aug 2001 00:58:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SAW0-000E54-00 for rap-data@psg.com; Wed, 01 Aug 2001 21:55:20 -0700 Received: from cms3.etri.re.kr ([129.254.16.13]) by psg.com with esmtp (Exim 3.31 #1) id 15SAVz-000E43-00 for rap@ops.ietf.org; Wed, 01 Aug 2001 21:55:20 -0700 Received: from BJLEE (lbj63112.etri.re.kr [129.254.191.69]) by cms3.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBP5LVDJ; Thu, 2 Aug 2001 13:53:40 +0900 Message-ID: <000701c11b0f$2ba7a130$9afeffcb@BJLEE> From: =?ks_c_5601-1987?B?wMy6tMHY?= To: Subject: [Q] COPS Error Obj Location Date: Thu, 2 Aug 2001 13:54:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. According to RFC 2748, two possible locations that COPS Error Obj can be located are COPS CC message and DEC message. So, I think that two different error-handling actions are possible when PDP processes REQ message. But I know know in what situation the DEC with Error Obj should be used, and in what situation the CC with Error Obj should be used during the REQ processing. Is there any guideline or this is implementation-specific problem? Thank you in advance. - - - Byung-Joon Lee, Network Architecture Team of ETRI lbj63112@etri.re.kr +82 42 860 1728 http://oopsla.snu.ac.kr/~bjlee From owner-rap@ops.ietf.org Thu Aug 2 03:07: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 DAA13722 for ; Thu, 2 Aug 2001 03:07:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SCaC-000K97-00 for rap-data@psg.com; Thu, 02 Aug 2001 00:07:48 -0700 Received: from [47.129.242.157] (helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.31 #1) id 15SCaA-000K3f-00 for rap@ops.ietf.org; Thu, 02 Aug 2001 00:07:46 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7276q909309 for ; Thu, 2 Aug 2001 03:06:52 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 2 Aug 2001 03:07:10 -0400 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 P9F9RZTA; Thu, 2 Aug 2001 03:07:10 -0400 Received: from tweedy.NortelNetworks.com (TWEEDY [47.16.4.17]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5M7CX; Thu, 2 Aug 2001 03:07:06 -0400 Message-Id: <5.0.0.25.0.20010802030241.02384e20@zbl6c000.corpeast.baynetworks.com> X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 Aug 2001 03:04:20 -0400 To: Juergen Schoenwaelder From: "Kwok-Ho Chan" Subject: Re: INET-ADDRESS-MIB and Cc: rap@ops.ietf.org In-Reply-To: <200107311354.PAA17334@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk Juergen: Thanks for the update. I got your E-Mail concerning the DiffServ MIB as well. Will update this in the next release of the Framework and DiffServ PIBs. -- Kwok -- At 03:54 PM 7/31/01 +0200, Juergen Schoenwaelder wrote: >The latest revision of the INET-ADDRESS-MIB in > allows to share InetAddressType >values and it introduces some new TCs that you may want to use. In >particular, you may want to consider to change > > FrwkIpFilterEntry ::= SEQUENCE { > frwkIpFilterDstAddrType InetAddressType, > frwkIpFilterDstAddr InetAddress, > frwkIpFilterDstAddrMask Unsigned32, > frwkIpFilterSrcAddrType InetAddressType, > frwkIpFilterSrcAddr InetAddress, > frwkIpFilterSrcAddrMask Unsigned32, > frwkIpFilterDscp Integer32, > frwkIpFilterProtocol Integer32, > frwkIpFilterDstL4PortMin Unsigned32, > frwkIpFilterDstL4PortMax Unsigned32, > frwkIpFilterSrcL4PortMin Unsigned32, > frwkIpFilterSrcL4PortMax Unsigned32 > } > >to the following: > > FrwkIpFilterEntry ::= SEQUENCE { > frwkIpFilterAddrType InetAddressType, > frwkIpFilterDstAddr InetAddress, > frwkIpFilterDstAddrPrefix InetAddressPrefixLength, > frwkIpFilterSrcAddr InetAddress, > frwkIpFilterSrcAddrPrefix InetAddressPrefixLength, > frwkIpFilterDscp Integer32, > frwkIpFilterProtocol Unsigned32, > frwkIpFilterDstL4PortMin InetPortNumber, > frwkIpFilterDstL4PortMax InetPortNumber, > frwkIpFilterSrcL4PortMin InetPortNumber, > frwkIpFilterSrcL4PortMax InetPortNumber > } > >This brings the filter definition more or less inline with the >definition in the diffserv MIB. Note that there is also a TC for the >DSCP code point you can consider to use (although this creates an >additional dependency to the diffserv MIB). > >/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 Thu Aug 2 05:15:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17903 for ; Thu, 2 Aug 2001 05:15:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SDpA-000Mui-00 for rap-data@psg.com; Thu, 02 Aug 2001 01:27:20 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.31 #1) id 15SDp8-000Mon-00 for rap@ops.ietf.org; Thu, 02 Aug 2001 01:27:18 -0700 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.4/8.11.4) with SMTP id f728OtC27751 for ; Thu, 2 Aug 2001 13:54:55 +0530 (IST) Received: from kapoor ([192.168.143.50]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHFM1J00.5N0; Thu, 2 Aug 2001 13:54:55 +0530 Message-ID: <012701c11b2c$9ba09d30$328fa8c0@wipsys.stph.net> From: "Saurabh kapoor" To: Cc: "V V V Satya Naganna" , "Radhika" , "Attili Venkata Ravi Kishore" Subject: policy time period condition in diffserv PIB Date: Thu, 2 Aug 2001 13:54:54 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0124_01C11B5A.B501DF90" ------=_NextPart_000_0124_01C11B5A.B501DF90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 The draft-ietf-diffserv-pib-03.txt does not seem to contain policy time period condition as specified in PCIM. How can a PDP push a set of policies and mandate that the policies = should be active only during the Time Period as specified in the policies? ( For example certain set policies are to be active between 9:00 to = 6:00, how can this time information of the policy be fitted into the PIB = ?) Regards,=20 Saurabh Kapoor ------=_NextPart_000_0124_01C11B5A.B501DF90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
The draft-ietf-diffserv-pib-03.txt does = not seem to=20 contain policy time
period condition as specified in = PCIM.
How can a PDP push a set of policies = and mandate=20 that the policies should be active
only during the Time Period as=20 specified in the policies?
( For example certain set policies are = to be active=20 between 9:00 to 6:00, how can this time information of the policy be = fitted into=20 the PIB ?)
 
Regards,
Saurabh = Kapoor
------=_NextPart_000_0124_01C11B5A.B501DF90-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- From owner-rap@ops.ietf.org Thu Aug 2 05:52: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 FAA18971 for ; Thu, 2 Aug 2001 05:52:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SF9T-00015D-00 for rap-data@psg.com; Thu, 02 Aug 2001 02:52:23 -0700 Received: from rodin.krdl.org.sg ([192.122.139.27]) by psg.com with esmtp (Exim 3.31 #1) id 15SF9S-00014Q-00 for rap@ops.ietf.org; Thu, 02 Aug 2001 02:52:22 -0700 Received: from mailhost.krdl.org.sg (localhost [127.0.0.1]) by rodin.krdl.org.sg (8.11.1/8.11.1) with ESMTP id f729luU19585; Thu, 2 Aug 2001 17:47:56 +0800 (SGT) Received: from krdl.org.sg (localhost [127.0.0.1]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with ESMTP id RAA05835; Thu, 2 Aug 2001 17:50:50 +0800 (SGT) Message-ID: <3B6923E2.D1FE3B5@krdl.org.sg> Date: Thu, 02 Aug 2001 17:56:50 +0800 From: Ponnappan Appan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: Saurabh kapoor CC: rap@ops.ietf.org, V V V Satya Naganna , Radhika , Attili Venkata Ravi Kishore Subject: Re: policy time period condition in diffserv PIB References: <012701c11b2c$9ba09d30$328fa8c0@wipsys.stph.net> Content-Type: multipart/alternative; boundary="------------C12BD66FFA39CC4EB664331D" Sender: owner-rap@ops.ietf.org Precedence: bulk --------------C12BD66FFA39CC4EB664331D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The PDP takes care of scheduling the rules and NOT the PEP. The PDP can send an unsolicited COPS DEC message with 'install' when the scheduling period starts. Similarly it sends an unsolicited COPS DEC message with 'remove' when the period ends. Saurabh kapoor wrote: > Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy > time > period condition as specified in PCIM.How can a PDP push a set of > policies and mandate that the policies should be active > only during the Time Period as specified in the policies?( For example > certain set policies are to be active between 9:00 to 6:00, how can > this time information of the policy be fitted into the PIB > ?) Regards,Saurabh Kapoor --------------C12BD66FFA39CC4EB664331D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The PDP takes care of scheduling the rules and NOT the PEP.
The PDP can send an unsolicited COPS DEC message with 'install' when the scheduling
period starts. Similarly it sends an unsolicited COPS DEC message with 'remove' when
the period ends.

Saurabh kapoor wrote:

Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy time
period condition as specified in PCIM.How can a PDP push a set of policies and mandate that the policies should be active
only during the Time Period as specified in the policies?( For example certain set policies are to be active between 9:00 to 6:00, how can this time information of the policy be fitted into the PIB ?) Regards,Saurabh Kapoor
--------------C12BD66FFA39CC4EB664331D-- From owner-rap@ops.ietf.org Thu Aug 2 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 KAA29063 for ; Thu, 2 Aug 2001 10:32:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJUB-000BGw-00 for rap-data@psg.com; Thu, 02 Aug 2001 07:30:03 -0700 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.31 #1) id 15SJUA-000B9L-00 for rap@ops.ietf.org; Thu, 02 Aug 2001 07:30:02 -0700 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GHG009B91O28T@firewall.mcit.com> for rap@ops.ietf.org; Thu, 2 Aug 2001 14:02:26 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GHG00H011NRLH@dgismtp01.wcomnet.com>; Thu, 02 Aug 2001 14:02:26 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GHG00AQ31NK03@dgismtp01.wcomnet.com>; Thu, 02 Aug 2001 14:02:09 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 02 Aug 2001 14:02:08 +0000 Content-return: allowed Date: Thu, 02 Aug 2001 14:02:05 +0000 From: "Iliff, Tina" Subject: RE: policy time period condition in diffserv PIB To: "'Ponnappan Appan'" , Saurabh kapoor Cc: rap@ops.ietf.org, V V V Satya Naganna , Radhika , Attili Venkata Ravi Kishore Message-id: <492EB4A3F68CD411ABE800508B69362E3F5AE4@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_WYa5JrTQO+ZOetvSU8I6/Q)" 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_WYa5JrTQO+ZOetvSU8I6/Q) Content-type: text/plain; charset=ISO-8859-1 Another alternative would be for the PDP to install all policies with only one being active. Then, when the active context should change the PDP would send a Unsolicited DEC (with the Install command and the Handle of the correct "Time-of-day" request-state) and only one instance of the frwkPibIncarnation class with the Active attribute set to True. Tina Iliff -----Original Message----- From: Ponnappan Appan [mailto:appan@krdl.org.sg] Sent: Thursday, August 02, 2001 4:57 AM To: Saurabh kapoor Cc: rap@ops.ietf.org; V V V Satya Naganna; Radhika; Attili Venkata Ravi Kishore Subject: Re: policy time period condition in diffserv PIB The PDP takes care of scheduling the rules and NOT the PEP. The PDP can send an unsolicited COPS DEC message with 'install' when the scheduling period starts. Similarly it sends an unsolicited COPS DEC message with 'remove' when the period ends. Saurabh kapoor wrote: Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy time period condition as specified in PCIM.How can a PDP push a set of policies and mandate that the policies should be active only during the Time Period as specified in the policies?( For example certain set policies are to be active between 9:00 to 6:00, how can this time information of the policy be fitted into the PIB ?) Regards,Saurabh Kapoor --Boundary_(ID_WYa5JrTQO+ZOetvSU8I6/Q) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Another alternative would be for the PDP to install all = policies with only one being active.  = Then, when the active context should change the PDP would send a Unsolicited DEC = (with the Install command and the Handle of the correct “Time-of-day” = request-state) and only one instance of the frwkPibIncarnation class with the Active = attribute set to True.

 

=

Tina Iliff

 

=  

=

-----Original Message-----
From: Ponnappan Appan [mailto:appan@krdl.org.sg]
Sent: Thursday, August = 02, 2001 4:57 AM
To: Saurabh kapoor
Cc: rap@ops.ietf.org; V = V V Satya Naganna; Radhika; Attili Venkata Ravi Kishore
Subject: Re: policy time = period condition in diffserv PIB

 

The PDP takes care of scheduling the rules and NOT the PEP.
The PDP can send an unsolicited COPS DEC message with 'install' when = the scheduling
period starts. Similarly it sends an unsolicited = COPS DEC message with 'remove' when
the period ends.

Saurabh kapoor wrote: = =

Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy = time
period condition as specified in = PCIM.How can a PDP push a set of policies and mandate that the policies should be = active
only during the Time Period as specified = in the policies?( For example certain set policies are to be active between = 9:00 to 6:00, how can this time information of the policy be fitted into the = PIB ?) Regards,Saurabh Kapoor=

--Boundary_(ID_WYa5JrTQO+ZOetvSU8I6/Q)-- From owner-rap@ops.ietf.org Thu Aug 2 13:55: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 NAA09732 for ; Thu, 2 Aug 2001 13:55:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SMfW-000I4J-00 for rap-data@psg.com; Thu, 02 Aug 2001 10:53:58 -0700 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.31 #1) id 15SMfV-000I1g-00 for rap@ops.ietf.org; Thu, 02 Aug 2001 10:53:57 -0700 Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA13378 for ; Thu, 2 Aug 2001 17:51:26 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001080210504418828 ; Thu, 02 Aug 2001 10:50:44 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 10:51:23 -0700 Message-ID: <10C8636AE359D4119118009027AE99870DA5D9EA@FMSMSX34> From: "Durham, David" To: "'???'" , rap@ops.ietf.org Subject: RE: [Q] COPS Error Obj Location Date: Thu, 2 Aug 2001 10:51:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: lbj63112@etri.re.kr [mailto:lbj63112@etri.re.kr] > > Hi. > > According to RFC 2748, two possible locations that COPS Error Obj can > be located are COPS CC message and DEC message. > > So, I think that two different error-handling actions are > possible when > PDP processes REQ message. > > But I know know in what situation the DEC with Error Obj > should be used, > and in what situation the CC with Error Obj should be used > during the REQ > processing. [Dave] The only situation specified in the RFC to use the CC + Error during REQ processing is when there is an authentication failure (bad or missing integrity, when integrity is enabled)... And that should be your first processing step. *Really* malformed REQ messages (ie. even the COPS header is garbled) may also logically result in a CC + Error if they are so malformed the TCP stream becomes completely un-interpretable. But so will any COPS message with a bad COPS header, an implementation simply has no other recourse in this case. > > Is there any guideline or this is implementation-specific problem? [Dave] In both cases above, the error should be caught even before REQ processing begins, so it is safe to assume that all other errors specific to the REQ processing step will result in a DEC + Error. > > Thank you in advance. > > - - - > Byung-Joon Lee, > Network Architecture Team of ETRI > lbj63112@etri.re.kr +82 42 860 1728 > http://oopsla.snu.ac.kr/~bjlee > > > > From owner-rap@ops.ietf.org Thu Aug 2 22:10:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09758 for ; Thu, 2 Aug 2001 22:10:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SUPO-0004CA-00 for rap-data@psg.com; Thu, 02 Aug 2001 19:09:50 -0700 Received: from postoffice.sarnoff.com ([130.33.10.147]) by psg.com with esmtp (Exim 3.31 #1) id 15SUPN-00049u-00 for rap@ops.ietf.org; Thu, 02 Aug 2001 19:09:49 -0700 Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYFM00.FC1 for ; Thu, 2 Aug 2001 21:50:10 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C2B00.301; Fri, 27 Jul 2001 15:13:23 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA11281; Fri, 27 Jul 2001 14:44:33 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19700 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13168 for ; Fri, 27 Jul 2001 07:24:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07807; Fri, 27 Jul 2001 07:24:52 -0400 (EDT) Message-Id: <200107271124.HAA07807@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-rsvp-better-identity-01.txt Date: Fri, 27 Jul 2001 07:24:51 -0400 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 : Identity Representation for RSVP Author(s) : R. Hess et al. Filename : draft-ietf-rap-rsvp-better-identity-01.txt Pages : 20 Date : 26-Jul-01 This document describes the representation of identity information in POLICY_DATA objects [POL-EXT] for supporting policy based admission control in RSVP [RFC 2205]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-better-identity-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-rsvp-better-identity-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-rsvp-better-identity-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: <20010726171155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-better-identity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171155.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Aug 3 04:55: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 EAA09406 for ; Fri, 3 Aug 2001 04:55:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Saj7-000JTH-00 for rap-data@psg.com; Fri, 03 Aug 2001 01:54:37 -0700 Received: from postoffice.sarnoff.com ([130.33.10.147]) by psg.com with esmtp (Exim 3.31 #1) id 15Saj6-000JRW-00 for rap@ops.ietf.org; Fri, 03 Aug 2001 01:54:36 -0700 Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF2M00.6QB for ; Fri, 3 Aug 2001 03:49:34 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C2B00.301; Fri, 27 Jul 2001 15:13:23 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA11281; Fri, 27 Jul 2001 14:44:33 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19700 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13168 for ; Fri, 27 Jul 2001 07:24:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07807; Fri, 27 Jul 2001 07:24:52 -0400 (EDT) Message-Id: <200107271124.HAA07807@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-rsvp-better-identity-01.txt Date: Fri, 27 Jul 2001 07:24:51 -0400 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 : Identity Representation for RSVP Author(s) : R. Hess et al. Filename : draft-ietf-rap-rsvp-better-identity-01.txt Pages : 20 Date : 26-Jul-01 This document describes the representation of identity information in POLICY_DATA objects [POL-EXT] for supporting policy based admission control in RSVP [RFC 2205]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-better-identity-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-rsvp-better-identity-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-rsvp-better-identity-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: <20010726171155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-better-identity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171155.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Aug 3 05:13: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 FAA10342 for ; Fri, 3 Aug 2001 05:13:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sb0P-000KGu-00 for rap-data@psg.com; Fri, 03 Aug 2001 02:12:29 -0700 Received: from rodin.krdl.org.sg ([192.122.139.27]) by psg.com with esmtp (Exim 3.31 #1) id 15Sb0N-000KG1-00 for rap@ops.ietf.org; Fri, 03 Aug 2001 02:12:28 -0700 Received: from mailhost.krdl.org.sg (localhost [127.0.0.1]) by rodin.krdl.org.sg (8.11.1/8.11.1) with ESMTP id f7397vl14658; Fri, 3 Aug 2001 17:08:00 +0800 (SGT) Received: from krdl.org.sg (localhost [127.0.0.1]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with ESMTP id RAA09331; Fri, 3 Aug 2001 17:10:46 +0800 (SGT) Message-ID: <3B6A6BF7.24DB4CF9@krdl.org.sg> Date: Fri, 03 Aug 2001 17:16:40 +0800 From: Ponnappan Appan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Iliff, Tina" CC: Saurabh kapoor , rap@ops.ietf.org, V V V Satya Naganna , Radhika , Attili Venkata Ravi Kishore Subject: Re: policy time period condition in diffserv PIB References: <492EB4A3F68CD411ABE800508B69362E3F5AE4@RIPEXCH002.wcomnet.com> Content-Type: multipart/alternative; boundary="------------F2886A487D2AFD6A303D49DD" Sender: owner-rap@ops.ietf.org Precedence: bulk --------------F2886A487D2AFD6A303D49DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------F2886A487D2AFD6A303D49DD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I have some questions on your suggestion of using multiple request-state
feature in COPS-PR and pibIncarnationTable in framework PIB, for activating/de-activating policy rules:

1. In your solution, is there:
    a. one PIB instance for all the policy rules which are active all the time,
         corresponding to the client handle that is used when the PEP connects
         first time?
    b. one PIB instance for each distinct "time-of-day" class instance defined
         in the policy rules?

2. What does activate and de-activate mean for a PIB instance? This does
     not seem to be explained in framework PIB. It also says that there can
     be only one PIB instance active.

"Iliff, Tina" wrote:

Another alternative would be for the PDP to install all policies with only one being active.Then, when the active context should change the PDP would send a Unsolicited DEC (with the Install command and the Handle of the correct "Time-of-day" request-state) and only one instance of the frwkPibIncarnation class with the Active attribute set to True.

Tina Iliff

-----Original Message-----
From: Ponnappan Appan [mailto:appan@krdl.org.sg]
Sent: Thursday, August 02, 2001 4:57 AM
To: Saurabh kapoor
Cc: rap@ops.ietf.org; V V V Satya Naganna; Radhika; Attili Venkata Ravi Kishore
Subject: Re: policy time period condition in diffserv PIB

The PDP takes care of scheduling the rules and NOT the PEP.
The PDP can send an unsolicited COPS DEC message with 'install' when the scheduling
period starts. Similarly it sends an unsolicited COPS DEC message with 'remove' when
the period ends. 

Saurabh kapoor wrote: 

Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy time
period condition as specified in PCIM.How can a PDP push a set of policies and mandate that the policies should be active
only during the Time Period as specified in the policies?( For example certain set policies are to be active between 9:00 to 6:00, how can this time information of the policy be fitted into the PIB ?)Regards,Saurabh Kapoor

--------------F2886A487D2AFD6A303D49DD-- From owner-rap@ops.ietf.org Fri Aug 3 06:42: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 GAA12577 for ; Fri, 3 Aug 2001 06:42:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ScPf-000Nh1-00 for rap-data@psg.com; Fri, 03 Aug 2001 03:42:39 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.31 #1) id 15ScPd-000NgZ-00 for rap@ops.ietf.org; Fri, 03 Aug 2001 03:42:38 -0700 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.4/8.11.4) with SMTP id f73AgVC00807 for ; Fri, 3 Aug 2001 16:12:31 +0530 (IST) Received: from kapoor ([192.168.143.50]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHHN2T00.AEE; Fri, 3 Aug 2001 16:12:29 +0530 Message-ID: <010701c11c08$fd8a9b40$328fa8c0@wipsys.stph.net> From: "Saurabh kapoor" To: "Iliff Tina" , "Ponnappan Appan" Cc: "V V V Satya Naganna" , References: <492EB4A3F68CD411ABE800508B69362E3F5AE4@RIPEXCH002.wcomnet.com> <3B6A6BF7.24DB4CF9@krdl.org.sg> Subject: Re: policy time period condition in diffserv PIB Date: Fri, 3 Aug 2001 16:12:27 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0104_01C11C37.16D96710" ------=_NextPart_000_0104_01C11C37.16D96710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My understanding of the active and deactivate PIB instances is that the = [COPS-PR] supports multiple, disjoint, independent instances of the PIB = to represent multiple instances of configured policy. The motive is to = allow for the pre-provisioning of policy that can then be made active by = a single, short decision from the PDP. ( The PEP has to mandate only the = policies described in the active PIB instance ) =20 As stated by you, although many PIB instances may be configured on a = device only one of them can be active at any given time, the active one = being selected by the PDP. To facilitate this selection, the Framework = PIB supports an attribute to make a PIB instance the=20 active one and, similarly, to report the active PIB instance to the PDP = in a COPS request message. Setting the attribute = frwkPibIncarnationActive in the Incarnation Table to 'true' in one PIB = instance MUST ensure that the attribute is 'false' in all other = contexts.=20 Regarding the creation and deletion of these PIB instances: Each PIB = instance is identified by a context. A COPS context can be defined as = an independent COPS request state for a particular subject category = (client-type). Each of these states is identified by a unique client = handle in the COPS-PR Protocol. But the doubt I have is when does the PDP actually create two PIB = instance. Is it that if the PDP wants to have more PIB instances it = forces the PEP for sending another REQ ???=20 Saurabh Kapoor -------------------------------------------------------------------------= ------------- ----- Original Message -----=20 From: Ponnappan Appan=20 To: Iliff, Tina=20 Cc: Saurabh kapoor ; rap@ops.ietf.org ; V V V Satya Naganna ; Radhika ; = Attili Venkata Ravi Kishore=20 Sent: Friday, August 03, 2001 2:46 PM Subject: Re: policy time period condition in diffserv PIB Hi,=20 I have some questions on your suggestion of using multiple request-state = feature in COPS-PR and pibIncarnationTable in framework PIB, for = activating/de-activating policy rules:=20 1. In your solution, is there:=20 a. one PIB instance for all the policy rules which are active all = the time,=20 corresponding to the client handle that is used when the PEP = connects=20 first time?=20 b. one PIB instance for each distinct "time-of-day" class instance = defined=20 in the policy rules?=20 2. What does activate and de-activate mean for a PIB instance? This does = not seem to be explained in framework PIB. It also says that there = can=20 be only one PIB instance active.=20 "Iliff, Tina" wrote:=20 Another alternative would be for the PDP to install all policies with = only one being active.Then, when the active context should change the = PDP would send a Unsolicited DEC (with the Install command and the = Handle of the correct "Time-of-day" request-state) and only one instance = of the frwkPibIncarnation class with the Active attribute set to True. Tina Iliff=20 -----Original Message-----=20 From: Ponnappan Appan [mailto:appan@krdl.org.sg]=20 Sent: Thursday, August 02, 2001 4:57 AM=20 To: Saurabh kapoor=20 Cc: rap@ops.ietf.org; V V V Satya Naganna; Radhika; Attili Venkata = Ravi Kishore=20 Subject: Re: policy time period condition in diffserv PIB=20 The PDP takes care of scheduling the rules and NOT the PEP.=20 The PDP can send an unsolicited COPS DEC message with 'install' when = the scheduling=20 period starts. Similarly it sends an unsolicited COPS DEC message with = 'remove' when=20 the period ends. =20 Saurabh kapoor wrote: =20 Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy = time=20 period condition as specified in PCIM.How can a PDP push a set of = policies and mandate that the policies should be active=20 only during the Time Period as specified in the policies?( For example = certain set policies are to be active between 9:00 to 6:00, how can this = time information of the policy be fitted into the PIB ?)Regards,Saurabh = Kapoor ------=_NextPart_000_0104_01C11C37.16D96710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My understanding of the active and = deactivate PIB=20 instances is that the [COPS-PR] = supports=20 multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy.  = The motive is to allow = for the=20 pre-provisioning of policy that can then be made active by a single, short decision from the PDP. ( = The PEP=20 has to mandate only the policies described in the active PIB = instance=20 )
    
As = stated by you,=20 although many PIB instances may be configured on a device only one of them can be active at any given time, = the=20 active one being selected by the = PDP. =20 To facilitate this selection, the Framework=20 PIB supports an attribute to make a PIB instance = the 
active one and, similarly, to report the active = PIB instance=20 to the PDP in a COPS request=20 message. Setting the attribute=20 frwkPibIncarnationActive in the Incarnation Table=20 to 'true' in one PIB instance MUST=20 ensure that the attribute is 'false' in all other contexts.

Regarding the creation and deletion of these PIB instances: Each PIB instance is identified = by a=20 context.  A COPS context can be defined as an independent COPS = request=20 state for a particular = subject=20 category (client-type). Each of=20 these states is identified by a unique client handle in the COPS-PR Protocol.

But the doubt I have is = when=20 does the PDP actually create two PIB instance. Is it that if the = PDP wants=20 to have more PIB instances it forces the PEP for sending another REQ ??? =

Saurabh=20 Kapoor
---------------------------------------------------------------= -----------------------
----- Original Message -----=20
From: Ponnappan = Appan=20
Cc: Saurabh kapoor ; rap@ops.ietf.org ; V V V=20 Satya Naganna ; Radhika ; Attili Venkata=20 Ravi Kishore
Sent: Friday, August 03, 2001 2:46 PM
Subject: Re: policy time period condition in diffserv=20 PIB

Hi,=20

I have some questions on your suggestion of using multiple = request-state=20
feature in COPS-PR and pibIncarnationTable in framework PIB, for=20 activating/de-activating policy rules:=20

1. In your solution, is there:
    a. one=20 PIB instance for all the policy rules which are active all the = time,=20
         corresponding to = the client=20 handle that is used when the PEP connects=20
         first time?=20
    b. one PIB instance for each distinct = "time-of-day"=20 class instance defined =
         in=20 the policy rules?=20

2. What does activate and de-activate mean for a PIB instance? = This does=20
     not seem to be explained in framework PIB. = It also=20 says that there can
     be only one = PIB instance=20 active.=20

"Iliff, Tina" wrote:=20

Another = alternative would be for=20 the PDP to install all policies with only one being active.Then, when the active context = should change=20 the PDP would send a Unsolicited DEC (with the Install command and the = Handle=20 of the correct "Time-of-day" request-state) and only one instance of = the=20 frwkPibIncarnation class with the Active attribute set to=20 True.

Tina=20 Iliff=20

<= SPAN=20 class=3DEmailStyle16>

-----Original=20 Message-----
From: Ponnappan=20 Appan [mailto:appan@krdl.org.sg]=20
Sent: Thursday, August = 02, 2001 4:57=20 AM
To: = Saurabh=20 kapoor
Cc:=20 rap@ops.ietf.org; V V V Satya Naganna; Radhika; Attili Venkata Ravi=20 Kishore
Subject: Re:=20 policy time period condition in diffserv = PIB=20

The PDP takes care of scheduling the = rules and NOT=20 the PEP.
The PDP can send an unsolicited COPS = DEC message=20 with 'install' when the scheduling
period = starts.=20 Similarly it sends an unsolicited COPS DEC message with 'remove'=20 when
the period=20 ends. =20

Saurabh kapoor=20 wrote: =20

Hi,The=20 draft-ietf-diffserv-pib-03.txt does not seem to contain policy=20 time =
period condition as = specified in=20 PCIM.How can a PDP push a set of policies and mandate that the = policies should=20 be active=20
only during the = Time Period as=20 specified in the policies?( For example certain set policies are to be = active=20 between 9:00 to 6:00, how can this time information of the policy be = fitted=20 into the PIB ?)Regards,Saurabh=20 Kapoor

------=_NextPart_000_0104_01C11C37.16D96710-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- From owner-rap@ops.ietf.org Fri Aug 3 09:44:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15938 for ; Fri, 3 Aug 2001 09:44:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SfEn-0003mL-00 for rap-data@psg.com; Fri, 03 Aug 2001 06:43:37 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.31 #1) id 15SfEm-0003hi-00 for rap@ops.ietf.org; Fri, 03 Aug 2001 06:43:36 -0700 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GHH00340VAP0C@firewall.mcit.com> for rap@ops.ietf.org; Fri, 3 Aug 2001 13:40:01 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GHH00401VAA35@dgismtp04.wcomnet.com>; Fri, 03 Aug 2001 13:40:00 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GHH0034FVA0E1@dgismtp04.wcomnet.com>; Fri, 03 Aug 2001 13:39:37 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 03 Aug 2001 13:39:36 +0000 Content-return: allowed Date: Fri, 03 Aug 2001 13:39:33 +0000 From: "Iliff, Tina" Subject: RE: policy time period condition in diffserv PIB To: "'Saurabh kapoor'" , Ponnappan Appan Cc: V V V Satya Naganna , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F5AEB@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_leB6gg0cpmYsTZGAxO9rJQ)" 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_leB6gg0cpmYsTZGAxO9rJQ) Content-type: text/plain; charset=iso-8859-1 Saurabh, You are correct. Also, to answer your question: "But the doubt I have is when does the PDP actually create two PIB instance. Is it that if the PDP wants to have more PIB instances it forces the PEP for sending another REQ ???" -- Yes Tina Iliff -----Original Message----- From: Saurabh kapoor [mailto:saurabh.kapoor@wipro.com] Sent: Friday, August 03, 2001 5:42 AM To: Iliff, Tina; Ponnappan Appan Cc: V V V Satya Naganna; rap@ops.ietf.org Subject: Re: policy time period condition in diffserv PIB My understanding of the active and deactivate PIB instances is that the [COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy. The motive is to allow for the pre-provisioning of policy that can then be made active by a single, short decision from the PDP. ( The PEP has to mandate only the policies described in the active PIB instance ) As stated by you, although many PIB instances may be configured on a device only one of them can be active at any given time, the active one being selected by the PDP. To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance the active one and, similarly, to report the active PIB instance to the PDP in a COPS request message. Setting the attribute frwkPibIncarnationActive in the Incarnation Table to 'true' in one PIB instance MUST ensure that the attribute is 'false' in all other contexts. Regarding the creation and deletion of these PIB instances: Each PIB instance is identified by a context. A COPS context can be defined as an independent COPS request state for a particular subject category (client-type). Each of these states is identified by a unique client handle in the COPS-PR Protocol. But the doubt I have is when does the PDP actually create two PIB instance. Is it that if the PDP wants to have more PIB instances it forces the PEP for sending another REQ ??? Saurabh Kapoor ---------------------------------------------------------------------------- ---------- ----- Original Message ----- From: Ponnappan Appan To: Iliff, Tina Cc: Saurabh kapoor ; rap@ops.ietf.org ; V V V Satya Naganna ; Radhika ; Attili Venkata Ravi Kishore Sent: Friday, August 03, 2001 2:46 PM Subject: Re: policy time period condition in diffserv PIB Hi, I have some questions on your suggestion of using multiple request-state feature in COPS-PR and pibIncarnationTable in framework PIB, for activating/de-activating policy rules: 1. In your solution, is there: a. one PIB instance for all the policy rules which are active all the time, corresponding to the client handle that is used when the PEP connects first time? b. one PIB instance for each distinct "time-of-day" class instance defined in the policy rules? 2. What does activate and de-activate mean for a PIB instance? This does not seem to be explained in framework PIB. It also says that there can be only one PIB instance active. "Iliff, Tina" wrote: Another alternative would be for the PDP to install all policies with only one being active.Then, when the active context should change the PDP would send a Unsolicited DEC (with the Install command and the Handle of the correct "Time-of-day" request-state) and only one instance of the frwkPibIncarnation class with the Active attribute set to True. Tina Iliff -----Original Message----- From: Ponnappan Appan [ mailto:appan@krdl.org.sg ] Sent: Thursday, August 02, 2001 4:57 AM To: Saurabh kapoor Cc: rap@ops.ietf.org; V V V Satya Naganna; Radhika; Attili Venkata Ravi Kishore Subject: Re: policy time period condition in diffserv PIB The PDP takes care of scheduling the rules and NOT the PEP. The PDP can send an unsolicited COPS DEC message with 'install' when the scheduling period starts. Similarly it sends an unsolicited COPS DEC message with 'remove' when the period ends. Saurabh kapoor wrote: Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy time period condition as specified in PCIM.How can a PDP push a set of policies and mandate that the policies should be active only during the Time Period as specified in the policies?( For example certain set policies are to be active between 9:00 to 6:00, how can this time information of the policy be fitted into the PIB ?)Regards,Saurabh Kapoor --Boundary_(ID_leB6gg0cpmYsTZGAxO9rJQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Saurabh,

 

=

You are correct.  Also, to answer your question:  “But the doubt I have is when = does the PDP actually create two PIB instance. Is it that if the PDP wants = to have more PIB instances it forces the PEP for sending another REQ ???” = -- Yes = <= /p>

 

=

 

=

Tina Iliff

 

= =  

=

-----Original Message-----
From: Saurabh kapoor [mailto:saurabh.kapoor@wipro.com]
Sent: Friday, August 03, = 2001 5:42 AM
To: Iliff, Tina; = Ponnappan Appan
Cc: V V V Satya Naganna; rap@ops.ietf.org
Subject: Re: policy time = period condition in diffserv PIB

 

My understanding of the active and deactivate PIB instances is = that the [COPS-PR] supports multiple, disjoint, independent instances of = the PIB to represent multiple instances of = configured policy.  The motive is to allow for the pre-provisioning of = policy that can then be made active by a single, short decision from the PDP. ( The PEP has to mandate only the policies described in the active PIB instance )
    =

As stated by you, although many PIB instances may be = configured on a device only one of them can be active at any given time, the = active one being selected by the PDP.  To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance = the 
active = one and, similarly, to report the active PIB instance to the PDP in a COPS = request message. Setting the attribute frwkPibIncarnationActive in the Incarnation Table to 'true' in one PIB instance MUST ensure = that the attribute is 'false' in all other contexts.

Regarding the creation and deletion of these PIB instances: Each PIB instance is identified by a context.  A COPS context can be defined as an independent = COPS request state for a particular subject category (client-type). Each = of these states is identified by a unique client handle in the COPS-PR = Protocol.

But = the doubt I have is when does the PDP actually create two = PIB instance. Is it that if the PDP wants to have more PIB instances = it forces the PEP for sending another REQ ???

Saurabh Kapoor
------------------------------------------------------------------------= --------------=

----- Original Message -----=20

To: Iliff, Tina

Cc: Saurabh kapoor ; rap@ops.ietf.org ; V V V Satya Naganna ; Radhika ; Attili Venkata Ravi Kishore

Sent: Friday, = August 03, 2001 2:46 PM

Subject: Re: policy time period condition in diffserv PIB

 =

Hi, =

I have some questions on = your suggestion of using multiple request-state
feature in COPS-PR and pibIncarnationTable in framework PIB, for activating/de-activating policy rules: =

1. In your solution, is there: =
    a. one PIB instance for all the policy rules = which are active all the time,
         corresponding to the = client handle that is used when the PEP connects
         first time?
    b. one PIB instance for each distinct "time-of-day" class instance defined
         in the policy rules? = =

2. What does activate and = de-activate mean for a PIB instance? This does
     not seem to be explained in framework PIB. It = also says that there can
     be only one PIB instance active. = =

"Iliff, Tina" wrote: = =

<= !--[if gte mso 9]> Another alternative would be for the PDP to install = all policies with only one being active.Then, when the active context = should change the PDP would send a Unsolicited DEC (with the Install command and the = Handle of the correct "Time-of-day" request-state) and only one = instance of the frwkPibIncarnation class with the Active attribute set to = True.=

Tina Iliff

 =

-----Original Message-----
From: Ponnappan Appan [mailto:appan@krdl.org.sg]
Sent: Thursday, August 02, 2001 4:57 AM
To:= Saurabh kapoor
Cc:= rap@ops.ietf.org; V V V Satya Naganna; Radhika; Attili = Venkata Ravi Kishore
Subject: Re: policy time period condition in diffserv = PIB =

The PDP takes care of scheduling the rules and NOT the PEP.
The PDP can send an unsolicited COPS DEC message with 'install' when = the scheduling
period starts. Similarly it sends an unsolicited COPS DEC message with = 'remove' when
the period ends.  =

Saurabh kapoor wrote:  =

Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy = time
period condition as specified in = PCIM.How can a PDP push a set of policies and mandate that the policies should be = active
only during the Time Period as specified = in the policies?( For example certain set policies are to be active between = 9:00 to 6:00, how can this time information of the policy be fitted into the = PIB ?)Regards,Saurabh Kapoor=

--Boundary_(ID_leB6gg0cpmYsTZGAxO9rJQ)-- From owner-rap@ops.ietf.org Sun Aug 5 22:43:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29051 for ; Sun, 5 Aug 2001 22:43:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TaKO-000OIx-00 for rap-data@psg.com; Sun, 05 Aug 2001 19:41:12 -0700 Received: from rodin.krdl.org.sg ([192.122.139.27]) by psg.com with esmtp (Exim 3.31 #1) id 15TaKM-000OIr-00 for rap@ops.ietf.org; Sun, 05 Aug 2001 19:41:11 -0700 Received: from mailhost.krdl.org.sg (localhost [127.0.0.1]) by rodin.krdl.org.sg (8.11.1/8.11.1) with ESMTP id f762b0J17003; Mon, 6 Aug 2001 10:37:04 +0800 (SGT) Received: from krdl.org.sg (localhost [127.0.0.1]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with ESMTP id KAA11029; Mon, 6 Aug 2001 10:39:18 +0800 (SGT) Message-ID: <3B6E049C.B6C38111@krdl.org.sg> Date: Mon, 06 Aug 2001 10:44:44 +0800 From: Ponnappan Appan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Iliff, Tina" , "'Saurabh kapoor'" CC: V V V Satya Naganna , rap@ops.ietf.org Subject: Re: policy time period condition in diffserv PIB References: <492EB4A3F68CD411ABE800508B69362E3F5AEB@RIPEXCH002.wcomnet.com> Content-Type: multipart/alternative; boundary="------------058E6E3D4207ABFB8B3D08A1" Sender: owner-rap@ops.ietf.org Precedence: bulk --------------058E6E3D4207ABFB8B3D08A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I also read the COPS-PR RFC and the latest framework PIB draft. My main question is: Why only one PIB instance need to be active at a given time? Also, my assumption is that (it is not explicitly stated in COPS-PR RFC or framework PIB draft) deactivating a PIB instance results in deletion(locally in the PEP) of the traffic control(TC) instances corresponding to ALL the PRIs in the PIB instance that is being deactivated. Let us say we have two sets of policy rules - one set being valid all the time and another set being valid from 9AM to 5PM on all days. If we map first set to one PIB instance and the second set to another PIB instance, we would require both the PIB instances to be active between 9AM to 5PM on alll days, which is not allowed. Regards, "Iliff, Tina" wrote: > Saurabh, > > You are correct.Also, to answer your question:"But the doubt I have is > when does the PDP actually create two PIB instance. Is it that if the > PDP wants to have more PIB instances it forces the PEP for sending > another REQ ???" -- Yes > > Tina Iliff > --------------058E6E3D4207ABFB8B3D08A1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I also read the  COPS-PR RFC and the latest framework PIB draft. My main question is:
Why only one PIB instance need to be active at a given time? Also, my assumption is that
(it is not explicitly stated in COPS-PR RFC or framework PIB draft) deactivating a PIB
instance results in deletion(locally in the PEP) of the traffic control(TC) instances
corresponding to ALL the PRIs in the PIB instance that is being deactivated.

Let us say we have two sets of policy rules - one set being valid all the time and another
set being valid from 9AM to 5PM on all days. If we map first set to one PIB instance and the
second set to another PIB instance, we would require both the PIB instances to be active
between 9AM to 5PM on alll days, which is not allowed.

Regards,

"Iliff, Tina" wrote:

Saurabh,

You are correct.Also, to answer your question:"But the doubt I have is when does the PDP actually create two PIB instance. Is it that if the PDP wants to have more PIB instances it forces the PEP for sending another REQ ???" -- Yes

Tina Iliff

--------------058E6E3D4207ABFB8B3D08A1-- From owner-rap@ops.ietf.org Sun Aug 5 22:43:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29062 for ; Sun, 5 Aug 2001 22:43:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TaN8-000OMV-00 for rap-data@psg.com; Sun, 05 Aug 2001 19:44:02 -0700 Received: from cms3.etri.re.kr ([129.254.16.13]) by psg.com with esmtp (Exim 3.31 #1) id 15TaN7-000OLC-00 for rap@ops.ietf.org; Sun, 05 Aug 2001 19:44:02 -0700 Received: from BJLEE (lbj63112.etri.re.kr [129.254.191.69]) by cms3.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBP5L7MZ; Mon, 6 Aug 2001 11:42:17 +0900 Message-ID: <00e101c11e21$7f9638f0$9afeffcb@BJLEE> From: =?ks_c_5601-1987?B?wMy6tMHY?= To: "Durham, David" , References: <10C8636AE359D4119118009027AE99870DA5D9EA@FMSMSX34> Subject: Re: [Q] COPS Error Obj Location Date: Mon, 6 Aug 2001 11:42:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you for your kind reply. But I think there is one more case that the CC+Error should be replied during the COPS REQ message processing. When Client Handle is Missing in REQ, (Client Handle is not part of the COPS header), there is no way to include that obj in the DEC message. So, I Think that DEC+Error can only be sent after the existence checkup of the Client Handle obj in the REQ message. I think that This case is not the 'bad cops header' situation, and not the 'incorrect security information' situation. I'm not sure that I'm saying it again that you have already pointed out, but only wanted to make sure. Regards, > > -----Original Message----- > > From: lbj63112@etri.re.kr [mailto:lbj63112@etri.re.kr] > > > > Hi. > > > > According to RFC 2748, two possible locations that COPS Error Obj can > > be located are COPS CC message and DEC message. > > > > So, I think that two different error-handling actions are > > possible when > > PDP processes REQ message. > > > > But I know know in what situation the DEC with Error Obj > > should be used, > > and in what situation the CC with Error Obj should be used > > during the REQ > > processing. > > [Dave] The only situation specified in the RFC to use the CC + Error during > REQ processing is when there is an authentication failure (bad or missing > integrity, when integrity is enabled)... And that should be your first > processing step. *Really* malformed REQ messages (ie. even the COPS header > is garbled) may also logically result in a CC + Error if they are so > malformed the TCP stream becomes completely un-interpretable. But so will > any COPS message with a bad COPS header, an implementation simply has no > other recourse in this case. > > > > > Is there any guideline or this is implementation-specific problem? > > [Dave] In both cases above, the error should be caught even before REQ > processing begins, so it is safe to assume that all other errors specific > to the REQ processing step will result in a DEC + Error. > > > > Thank you in advance. > > > > - - - > > Byung-Joon Lee, > > Network Architecture Team of ETRI > > lbj63112@etri.re.kr +82 42 860 1728 > > http://oopsla.snu.ac.kr/~bjlee > > > > > > > > From owner-rap@ops.ietf.org Wed Aug 8 08:35:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11208 for ; Wed, 8 Aug 2001 08:35:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15USYF-000CRE-00 for rap-data@psg.com; Wed, 08 Aug 2001 05:35:07 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.31 #1) id 15USYF-000CQa-00 for rap@ops.ietf.org; Wed, 08 Aug 2001 05:35:07 -0700 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GHR001IK1LNUX@firewall.mcit.com> for rap@ops.ietf.org; Wed, 8 Aug 2001 12:34:36 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GHR003011LM7R@dgismtp04.wcomnet.com> for rap@ops.ietf.org; Wed, 08 Aug 2001 12:34:35 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GHR0014I1L8RF@dgismtp04.wcomnet.com> for rap@ops.ietf.org; Wed, 08 Aug 2001 12:34:21 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 08 Aug 2001 12:34:20 +0000 Content-return: allowed Date: Wed, 08 Aug 2001 12:34:17 +0000 From: "Rawlins, Diana" Subject: rap-frwk-pib Multi PIB Instances To: "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E647736@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_WUsV6wuw6IuF99L51gEKGw)" 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_WUsV6wuw6IuF99L51gEKGw) Content-type: text/plain; charset=iso-8859-1 In the Framework Policy Information Base, I think some changes to the wording would help to avoid some confusion about the configuration of multiple request state contexts. In Section 3.2 Multiple PIB Instances Add to the following paragraph: With the COPS-PR protocol, each of these states is identified by a unique client handle. The creation and deletion of these PIB instances is controlled by the PDP as described in [COPS-PR]. A PEP must open only a single "request-state" for configuration for a given subject-category (client type). Any additional "request-states" at the PEP must be initiated by the PDP. The following 3 sentences: Note that in the event that a PEP has an interface capability change such as a card hot swap, a subsequent request is issued to the PDP containing its revised capabilities. A request for re-configuration is issued for all request state contexts, both for the active context as well as any inactive contexts. This is to ensure that when an inactive context is activated its been pre-configured with policies compatible with the PEP current capabilities. In the same Section 3.2 Replace the following wording: To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance the active one and, similarly, to report the active PIB instance to the PDP in a COPS request message. With the following suggested wording: To facilitate this selection, the Framework PIB supports the attribute frwkPibIncarnationActive that denotes the PIB instance as being active. -Diana --Boundary_(ID_WUsV6wuw6IuF99L51gEKGw) Content-type: text/html; charset=iso-8859-1 rap-frwk-pib Multi PIB Instances

In the Framework Policy Information Base, I
think some changes to the wording would help
to avoid some confusion about the
configuration of multiple request state
contexts.
 
In Section 3.2 Multiple PIB Instances

Add to the following paragraph:

With the COPS-PR protocol, each of these
states is identified by a unique client handle.
The creation and deletion of these PIB instances
is controlled by the PDP as described in
[COPS-PR]. A PEP must open only a single
"request-state" for configuration for a given
subject-category (client type). Any additional
"request-states" at the PEP must be initiated
by the PDP.

The following 3 sentences:

Note that in the event that a PEP has an
interface capability change such as a card hot
swap, a subsequent request is issued to the
PDP containing its revised capabilities. A
request for re-configuration is issued for all
request state contexts, both for the active
context as well as any inactive contexts. This
 is to ensure that when an inactive context is
activated its been pre-configured with
policies compatible with the PEP current
capabilities.
   

In the same Section 3.2

Replace the following wording:

To facilitate this selection, the Framework
PIB supports an attribute to make a PIB
instance the active one and, similarly, to
report the active PIB instance to the PDP in a
COPS request message.

With the following suggested wording:

To facilitate this selection, the Framework PIB
supports the attribute frwkPibIncarnationActive
that denotes the PIB instance as being active.


-Diana   


--Boundary_(ID_WUsV6wuw6IuF99L51gEKGw)-- From owner-rap@ops.ietf.org Wed Aug 8 08:46:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11480 for ; Wed, 8 Aug 2001 08:46:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15USjT-000CrZ-00 for rap-data@psg.com; Wed, 08 Aug 2001 05:46:43 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.31 #1) id 15USjS-000CpV-00 for rap@ops.ietf.org; Wed, 08 Aug 2001 05:46:42 -0700 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GHR008CY24Q79@firewall.mcit.com> for rap@ops.ietf.org; Wed, 8 Aug 2001 12:46:02 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GHR0090124OT3@dgismtp04.wcomnet.com> for rap@ops.ietf.org; Wed, 08 Aug 2001 12:46:02 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GHR001N224HRD@dgismtp04.wcomnet.com> for rap@ops.ietf.org; Wed, 08 Aug 2001 12:45:54 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 08 Aug 2001 12:45:53 +0000 Content-return: allowed Date: Wed, 08 Aug 2001 12:45:51 +0000 From: "Rawlins, Diana" Subject: ifIndex rap-frameworkpib-05 To: "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E647738@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_cxN5jUF67li0HXyShihQ3g)" 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_cxN5jUF67li0HXyShihQ3g) Content-type: text/plain; charset=iso-8859-1 In the July 20, 2001 version of the Framework Policy Information Base Section 3.1 Roles states in paragraph three that the ifindex is opaque to the policy. But then in Section 5, Summary of the Framework PIB under the Device Capabilities Group, a PRC is added to bind the IfIndex to a RoleCombination. The RoleCombination attribute identifies some set of policies and an ifIndex attribute identifies an unique interface that enforces the policy set. These two sections are incompatible. (Excerpts are inserted below) I'm repeatedly hearing that both the configuration policies and the usage feedback policies need to configure and/or report information on a per "interface" basis. There are good reasons that the PDP DOES need to be aware of the ifIndices and manage policies accordingly. I propose removing the Section 3.1 paragraph declaring ifindex as being opaque and, in addition to the Role Combination and Interface Table, adding a PRC that parallels the MIB-II ifTable but without the counters. The policy feedback framework can incorporate the usage related counters into its PIB. The following excerpts are from 05 version " Section 3.1 Thus, roles provide a way to bind policy to interfaces without having to explicitly identify interfaces in a consistent manner across all network devices. (The SNMP experience with ifIndex has proved this to be a difficult task.) That is, roles provide a level of indirection to the application of a set of policies to specific interfaces. 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. We point out that, in the event that the administrator needs to have unique policy for each interface, this can be achieved by configuring each interface with a unique role. " But later in the same section under the Interface and Role Combination Table discussion "The Interface and Role Combination Table describes the association between specific interfaces with each role combination. It answers the questions of which interfaces have a specific role combination and what role combination a specific interface is a part of. The Interface and Role Combination Table entries each contains a two-tuple to accomplish this mapping. " "FrwkIfCapSetInterfaceEntry ::= SEQUENCE { frwkIfCapSetInterfacePrid InstanceId, frwkIfCapSetInterfaceIfIndex InterfaceIndex, frwkIfCapSetInterfaceRoles RoleCombination }" -Diana --Boundary_(ID_cxN5jUF67li0HXyShihQ3g) Content-type: text/html; charset=iso-8859-1 ifIndex rap-frameworkpib-05

In the July 20, 2001 version of the Framework
Policy Information Base Section 3.1 Roles
states in paragraph three that the ifindex
is opaque to the policy. But then in Section
5, Summary of the Framework PIB under the
Device Capabilities Group, a PRC is added to
bind the IfIndex to a RoleCombination. The
RoleCombination attribute identifies some
set of policies and an ifIndex attribute
identifies an unique interface that enforces
the policy set. These two sections are
incompatible. (Excerpts are inserted below)

I'm repeatedly hearing that both the
configuration policies and the usage
feedback policies need to configure and/or
report information on a per "interface"
basis. There are good reasons that the PDP
DOES need to be aware of the ifIndices and
manage policies accordingly.

I propose removing the Section 3.1 paragraph
declaring ifindex as being opaque and, in
addition to the Role Combination and
Interface Table, adding a PRC that parallels
the MIB-II ifTable but without the counters.
The policy feedback framework can
incorporate the usage related counters into
its PIB.

The following excerpts are from 05 version


" Section 3.1
Thus, roles provide a way to bind policy to
interfaces without having to explicitly
identify interfaces in a consistent manner
across all network devices.  (The SNMP
experience with ifIndex has proved this to
be a difficult task.)  That is, roles provide
a level of indirection to the application of a
set of policies to specific   interfaces.
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.
   
We point out that, in the event that the
administrator needs to have unique policy for
each interface, this can be achieved by
configuring each interface with a unique role. "

But later in the same section under the
Interface and Role Combination Table discussion
 
"The Interface and Role Combination Table
describes the association between specific
interfaces with each role combination. It
answers the questions of which interfaces 
have a specific role combination and what
role combination a specific interface is a
part of.  The Interface and Role Combination
Table entries each contains a
<ifIndex, Role Combo> two-tuple to
accomplish this mapping. "

"FrwkIfCapSetInterfaceEntry ::= SEQUENCE {
      frwkIfCapSetInterfacePrid     InstanceId,
      frwkIfCapSetInterfaceIfIndex  InterfaceIndex,
      frwkIfCapSetInterfaceRoles    RoleCombination
 }"



-Diana

--Boundary_(ID_cxN5jUF67li0HXyShihQ3g)-- From owner-rap@ops.ietf.org Thu Aug 9 03:29:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16516 for ; Thu, 9 Aug 2001 03:29:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UkF4-000EGL-00 for rap-data@psg.com; Thu, 09 Aug 2001 00:28:30 -0700 Received: from p-mail2.rd.francetelecom.com ([193.49.124.32] helo=p-mail2.cnet.fr) by psg.com with smtp (Exim 3.31 #1) id 15UkF1-000EDz-00 for rap@ops.ietf.org; Thu, 09 Aug 2001 00:28:27 -0700 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 09:27:51 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE2A6@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "'Rawlins, Diana'" , "'rap@ops.ietf.org'" Subject: RE: ifIndex rap-frameworkpib-05 Date: Thu, 9 Aug 2001 09:26:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C120A4.ACCBB040" ------_=_NextPart_001_01C120A4.ACCBB040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A set of additional remarks in addition of those of Diana. =20 If for instance, we consider the following equipment : [Interface A] : IfIndex =3D "1" - Role =3D "A+B", capability=3D"C1" [Interface B] : IfIndex =3D "2" - Role =3D "A+C", capability=3D"C2" [Interface C] : IfIndex =3D "3" - Role =3D "A+C", capability=3D"C2" [Interface D] : IfIndex =3D "4" - Role =3D "A+B+C", capability=3D"C3" =20 My understanding is that the following table will be populated by the = PEP and forwarded to the PDP as following (InstanceId have been omitted): [frwkIfCapSetTable] Name =3D "C1" - PRID =3D x Name =3D "C2" - PRID =3D y Name =3D "C3" - PRID =3D z where x,y,z are PRIDs which identify different capability instances and which are reported by the PEP, within the initial request. =20 [frwkIfCapSetRoleComboTable] Name =3D "C1" - Roles =3D "A+B" Name =3D "C2" - Roles =3D "A+C"=20 Name =3D "C3" - Roles =3D "A+B+C" =20 [frwkIfCapSetInterfaceTable] IfIndex =3D "1" - Role =3D "A+B" IfIndex =3D "2" - Role =3D "A+C" IfIndex =3D "3" - Role =3D "A+C" IfIndex =3D "4" - Role =3D "A+B+C" =20 QUESTION 1 In the above example, are these tables correctly populated ? =20 QUESTION 2 In the draft frwkIfCapSetTable, frwkIfCapSetRoleComboTable have the PIB-ACCESS clause set to : "install-notify" ??? Is it normal ??? = Shouldn't they be only "notify" ??? =20 QUESTION 3 The frwkIfCapSetInterfaceTable PIB-ACCESS clause is currently set to "install-notify". Is it to give the possibility for the PDP to modify = the role of a given interface using the InterfaceIndex value or should this = PRC also tagged "notify" ????? =20 If it is intentionally tagged "install-notify" how the system should = work in such a case ? 1-The PDP modify the role 2-It sends an unsolicited decision to the PEP 3-PEP sends a report 4-PEP issues a complete request (with the frwkIfCapSetRoleComboTable updated, since the PEP is the only entity which is able to know with interface has been assigned a given capability and a given role = combination) 5-the PDP computes a new set of policies 6-the PDP sends its decision 7-the PEP send a report =20 What will happen if the PDP changes the InterfaceIndex value or deletes = the instance ? Can the PDP force the role to be "null" ??? =20 QUESTION 4 A rule (IPSec rule for instance) shall now precise a tuple formed by to identify the set of interfaces on = which the attached policy will apply. Is that correct ? =20 What will happen if the client-type doesn't need to precise any = Capability ? is that allowed ? There would be no frwkIfCapSetEntry instances and the frwkIfCapSetRoleComboName would be ...... ? "null" or empty string ? =20 QUESTION 5 It doesn't seem it exits a mechanism for the PEP to send an updated = request (incremental request with remove and install PDU). Shall we consider that each time a new request needs to be issued, all PIB = framework instances shall be re-issued and the PDP shall delete all previous PIB framework instances ? =20 Thanks in advance for your comments and answers. -----Message d'origine----- De : Rawlins, Diana [mailto:Diana.Rawlins@wcom.com] Envoy=E9 : mercredi 8 ao=FBt 2001 14:46 =C0 : 'rap@ops.ietf.org' Objet : ifIndex rap-frameworkpib-05 In the July 20, 2001 version of the Framework=20 Policy Information Base Section 3.1 Roles=20 states in paragraph three that the ifindex=20 is opaque to the policy. But then in Section=20 5, Summary of the Framework PIB under the=20 Device Capabilities Group, a PRC is added to=20 bind the IfIndex to a RoleCombination. The=20 RoleCombination attribute identifies some=20 set of policies and an ifIndex attribute=20 identifies an unique interface that enforces=20 the policy set. These two sections are=20 incompatible. (Excerpts are inserted below)=20 I'm repeatedly hearing that both the=20 configuration policies and the usage=20 feedback policies need to configure and/or=20 report information on a per "interface"=20 basis. There are good reasons that the PDP=20 DOES need to be aware of the ifIndices and=20 manage policies accordingly.=20 I propose removing the Section 3.1 paragraph=20 declaring ifindex as being opaque and, in=20 addition to the Role Combination and=20 Interface Table, adding a PRC that parallels=20 the MIB-II ifTable but without the counters.=20 The policy feedback framework can=20 incorporate the usage related counters into=20 its PIB.=20 The following excerpts are from 05 version=20 " Section 3.1=20 Thus, roles provide a way to bind policy to=20 interfaces without having to explicitly=20 identify interfaces in a consistent manner=20 across all network devices. (The SNMP=20 experience with ifIndex has proved this to=20 be a difficult task.) That is, roles provide=20 a level of indirection to the application of a=20 set of policies to specific interfaces.=20 Furthermore, if the same policy is being applied=20 to several interfaces, that policy need be=20 pushed to the device only once, rather than once=20 per interface, as long as the interfaces are=20 configured with the same role combination.=20 =20 We point out that, in the event that the=20 administrator needs to have unique policy for=20 each interface, this can be achieved by=20 configuring each interface with a unique role. "=20 But later in the same section under the=20 Interface and Role Combination Table discussion=20 =20 "The Interface and Role Combination Table=20 describes the association between specific=20 interfaces with each role combination. It=20 answers the questions of which interfaces =20 have a specific role combination and what=20 role combination a specific interface is a=20 part of. The Interface and Role Combination=20 Table entries each contains a=20 two-tuple to=20 accomplish this mapping. "=20 "FrwkIfCapSetInterfaceEntry ::=3D SEQUENCE {=20 frwkIfCapSetInterfacePrid InstanceId,=20 frwkIfCapSetInterfaceIfIndex InterfaceIndex,=20 frwkIfCapSetInterfaceRoles RoleCombination=20 }"=20 -Diana=20 ------_=_NextPart_001_01C120A4.ACCBB040 Content-Type: text/html; charset="iso-8859-1" ifIndex rap-frameworkpib-05
A set of additional remarks in addition of those of Diana.
 
If for instance, we consider the following equipment :
[Interface A] : IfIndex = "1" - Role = "A+B", capability="C1"
[Interface B] : IfIndex = "2" - Role = "A+C", capability="C2"
[Interface C] : IfIndex = "3" - Role = "A+C", capability="C2"
[Interface D] : IfIndex = "4" - Role = "A+B+C", capability="C3"
 
My understanding is that the following table will be populated by the PEP and forwarded to the PDP as following (InstanceId have been omitted):
[frwkIfCapSetTable]
Name = "C1" - PRID = x
Name = "C2" - PRID = y
Name = "C3" - PRID = z
where x,y,z are PRIDs which identify different capability instances and which are reported by the PEP, within the initial request.
 
[frwkIfCapSetRoleComboTable]
Name = "C1" - Roles = "A+B"
Name = "C2" - Roles = "A+C"
Name = "C3" - Roles = "A+B+C"
 
[frwkIfCapSetInterfaceTable]
IfIndex = "1" - Role = "A+B"
IfIndex = "2" - Role = "A+C"
IfIndex = "3" - Role = "A+C"
IfIndex = "4" - Role = "A+B+C"
 
QUESTION 1
In the above example, are these tables correctly populated ?
 
QUESTION 2
In the draft frwkIfCapSetTable, frwkIfCapSetRoleComboTable have the PIB-ACCESS clause set to : "install-notify" ??? Is it normal ??? Shouldn't they be only "notify" ???
 
QUESTION 3
The frwkIfCapSetInterfaceTable PIB-ACCESS clause is currently set to "install-notify". Is it to give the possibility for the PDP to modify the role of a given interface using the InterfaceIndex value or should this PRC also tagged "notify" ?????
 
If it is intentionally tagged "install-notify" how the system should work in such a case ?
1-The PDP modify the role
2-It sends an unsolicited decision to the PEP
3-PEP sends a report
4-PEP issues a complete request (with the frwkIfCapSetRoleComboTable updated, since the PEP is the only entity which is able to know with interface has been assigned a given capability and a given role combination)
5-the PDP computes a new set of policies
6-the PDP sends its decision
7-the PEP send a report
 
What will happen if the PDP changes the InterfaceIndex value or deletes the instance ? Can the PDP force the role to be "null" ???
 
QUESTION 4
A rule (IPSec rule for instance) shall now precise a tuple formed by <a role combination, a fwrkIfCapSetName> to identify the set of interfaces on which the attached policy will apply. Is that correct ?
 
What will happen if the client-type doesn't need to precise any Capability ? is that allowed ? There would be no frwkIfCapSetEntry instances and the frwkIfCapSetRoleComboName would be ...... ? "null" or empty string ?
 
QUESTION 5
It doesn't seem it exits a mechanism for the PEP to send an updated request (incremental request with remove and install <PRID-EDP> PDU). Shall we consider that each time a new request needs to be issued, all PIB framework instances shall be re-issued and the PDP shall delete all previous PIB framework instances ?
 
Thanks in advance for your comments and answers.
-----Message d'origine-----
De : Rawlins, Diana [mailto:Diana.Rawlins@wcom.com]
Envoyé : mercredi 8 août 2001 14:46
À : 'rap@ops.ietf.org'
Objet : ifIndex rap-frameworkpib-05


In the July 20, 2001 version of the Framework
Policy Information Base Section 3.1 Roles
states in paragraph three that the ifindex
is opaque to the policy. But then in Section
5, Summary of the Framework PIB under the
Device Capabilities Group, a PRC is added to
bind the IfIndex to a RoleCombination. The
RoleCombination attribute identifies some
set of policies and an ifIndex attribute
identifies an unique interface that enforces
the policy set. These two sections are
incompatible. (Excerpts are inserted below)

I'm repeatedly hearing that both the
configuration policies and the usage
feedback policies need to configure and/or
report information on a per "interface"
basis. There are good reasons that the PDP
DOES need to be aware of the ifIndices and
manage policies accordingly.

I propose removing the Section 3.1 paragraph
declaring ifindex as being opaque and, in
addition to the Role Combination and
Interface Table, adding a PRC that parallels
the MIB-II ifTable but without the counters.
The policy feedback framework can
incorporate the usage related counters into
its PIB.

The following excerpts are from 05 version


" Section 3.1
Thus, roles provide a way to bind policy to
interfaces without having to explicitly
identify interfaces in a consistent manner
across all network devices.  (The SNMP
experience with ifIndex has proved this to
be a difficult task.)  That is, roles provide
a level of indirection to the application of a
set of policies to specific   interfaces.
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.
   
We point out that, in the event that the
administrator needs to have unique policy for
each interface, this can be achieved by
configuring each interface with a unique role. "

But later in the same section under the
Interface and Role Combination Table discussion
 
"The Interface and Role Combination Table
describes the association between specific
interfaces with each role combination. It
answers the questions of which interfaces 
have a specific role combination and what
role combination a specific interface is a
part of.  The Interface and Role Combination
Table entries each contains a
<ifIndex, Role Combo> two-tuple to
accomplish this mapping. "

"FrwkIfCapSetInterfaceEntry ::= SEQUENCE {
      frwkIfCapSetInterfacePrid     InstanceId,
      frwkIfCapSetInterfaceIfIndex  InterfaceIndex,
      frwkIfCapSetInterfaceRoles    RoleCombination
 }"



-Diana

------_=_NextPart_001_01C120A4.ACCBB040-- --------------InterScan_NT_MIME_Boundary-- From owner-rap@ops.ietf.org Thu Aug 9 03:32:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16546 for ; Thu, 9 Aug 2001 03:32:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UkJ3-000ESA-00 for rap-data@psg.com; Thu, 09 Aug 2001 00:32:37 -0700 Received: from p-mail2.rd.francetelecom.com ([193.49.124.32] helo=p-mail2.cnet.fr) by psg.com with smtp (Exim 3.31 #1) id 15UkJ2-000ERW-00 for rap@ops.ietf.org; Thu, 09 Aug 2001 00:32:36 -0700 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 09:32:02 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE2A7@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "'Rawlins, Diana'" , "'rap@ops.ietf.org'" Subject: RE: rap-frwk-pib Multi PIB Instances Date: Thu, 9 Aug 2001 09:31:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C120A5.44789390" ------_=_NextPart_001_01C120A5.44789390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Additional comment at the end of the original message . Pierrick -----Message d'origine----- De : Rawlins, Diana [mailto:Diana.Rawlins@wcom.com] Envoy=E9 : mercredi 8 ao=FBt 2001 14:34 =C0 : 'rap@ops.ietf.org' Objet : rap-frwk-pib Multi PIB Instances In the Framework Policy Information Base, I=20 think some changes to the wording would help=20 to avoid some confusion about the=20 configuration of multiple request state=20 contexts.=20 =20 In Section 3.2 Multiple PIB Instances=20 Add to the following paragraph:=20 With the COPS-PR protocol, each of these=20 states is identified by a unique client handle.=20 The creation and deletion of these PIB instances=20 is controlled by the PDP as described in=20 [COPS-PR]. A PEP must open only a single=20 "request-state" for configuration for a given=20 subject-category (client type). Any additional=20 "request-states" at the PEP must be initiated=20 by the PDP.=20 The following 3 sentences:=20 Note that in the event that a PEP has an=20 interface capability change such as a card hot=20 swap, a subsequent request is issued to the=20 PDP containing its revised capabilities. A=20 request for re-configuration is issued for all=20 request state contexts, both for the active=20 context as well as any inactive contexts. This=20 is to ensure that when an inactive context is=20 activated its been pre-configured with=20 policies compatible with the PEP current=20 capabilities.=20 =20 In the same Section 3.2=20 Replace the following wording:=20 To facilitate this selection, the Framework=20 PIB supports an attribute to make a PIB=20 instance the active one and, similarly, to=20 report the active PIB instance to the PDP in a=20 COPS request message.=20 With the following suggested wording:=20 To facilitate this selection, the Framework PIB=20 supports the attribute frwkPibIncarnationActive=20 that denotes the PIB instance as being active.=20 [Comment PMo >>] Concerning this later point the text (page 17) = indicates that the PEP is responsible for re-setting the attribute to ensure that = the fwrkPibIncarnationActive attribute is "false" in all other contexts. = What about the PDP behavior ? Shall it clear the fwrkPibIncarnationActive attribute of the previous active request-context before it sends its decision or shall it wait for the report to do it ? Or, when clearing = this attribute on the previous active context shall the PEP also issue an = updated request for that previous request context to update the PIB incarnation entry at PDP side ? -Diana =20 ------_=_NextPart_001_01C120A5.44789390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable rap-frwk-pib Multi PIB Instances
Additional comment at the end of the = original message=20 .
Pierrick
-----Message d'origine-----
De : Rawlins, = Diana=20 [mailto:Diana.Rawlins@wcom.com]
Envoy=E9 : mercredi 8 = ao=FBt 2001=20 14:34
=C0 : 'rap@ops.ietf.org'
Objet :=20 rap-frwk-pib Multi PIB Instances

In the Framework Policy Information = Base, I=20
think some changes to the = wording would=20 help
to avoid some confusion = about the=20
configuration of multiple = request state=20
contexts.
 
In = Section 3.2=20 Multiple PIB Instances

Add to the following paragraph: =

With the COPS-PR protocol, each of = these=20
states is identified by a unique = client=20 handle.
The creation and = deletion of these=20 PIB instances
is controlled by = the PDP as=20 described in
[COPS-PR]. A PEP = must open=20 only a single
"request-state" = for=20 configuration for a given
subject-category=20 (client type). Any additional
"request-states" at the PEP must be = initiated=20
by the PDP.

The following 3 sentences:

Note that in the event that a PEP has = an=20
interface capability change = such as a card=20 hot
swap, a subsequent request = is issued=20 to the
PDP containing its = revised=20 capabilities. A
request for=20 re-configuration is issued for all
request=20 state contexts, both for the active
context as well as any inactive contexts. = This=20
 is to ensure that when an = inactive context=20 is
activated its been = pre-configured with=20
policies compatible with the = PEP current=20
capabilities.
   

In the same Section 3.2

Replace the following wording: =

To facilitate this selection, the = Framework=20
PIB supports an attribute to = make a PIB=20
instance the active one and, = similarly,=20 to
report the active PIB = instance to the=20 PDP in a
COPS request = message.

With the following suggested = wording:

To facilitate this selection, the = Framework=20 PIB
supports the attribute=20 frwkPibIncarnationActive
that = denotes the=20 PIB instance as being active.

[Comment PMo=20 >>] Concerning this later point = the text (page 17)=20 indicates that the PEP is responsible for re-setting the = attribute to=20 ensure that the fwrkPibIncarnationActive attribute is "false" in all = other=20 contexts. What about the PDP behavior ? Shall it clear = the=20 fwrkPibIncarnationActive attribute of the previous active = request-context=20 before it sends its decision or shall it wait for the report to do it = ?  Or, when clearing this attribute on the previous active = context=20 shall the PEP also issue an updated request for=20 that previous request context to update the PIB = incarnation entry=20 at PDP side ?

-Diana   =20


------_=_NextPart_001_01C120A5.44789390-- --------------InterScan_NT_MIME_Boundary-- From owner-rap@ops.ietf.org Fri Aug 17 05:36:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22357 for ; Fri, 17 Aug 2001 05:36:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Xg1z-000Dpi-00 for rap-data@psg.com; Fri, 17 Aug 2001 02:35:07 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.31 #1) id 15Xg1y-000Dpc-00 for rap@ops.ietf.org; Fri, 17 Aug 2001 02:35:06 -0700 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.4/8.11.4) with SMTP id f7H9YtC25534 for ; Fri, 17 Aug 2001 15:04:55 +0530 (IST) Received: from kapoor ([192.168.143.50]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GI7HAB00.2QU; Fri, 17 Aug 2001 15:05:00 +0530 Message-ID: <00c501c126ff$e4415f50$328fa8c0@wipsys.stph.net> From: "Saurabh kapoor" To: "Ponnappan Appan" , "Iliff Tina" Cc: References: <492EB4A3F68CD411ABE800508B69362E3F5AEB@RIPEXCH002.wcomnet.com> <3B6E049C.B6C38111@krdl.org.sg> Subject: diffserv PIB mapping Date: Fri, 17 Aug 2001 15:05:02 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01C1272D.FDABA260" ------=_NextPart_000_00C2_01C1272D.FDABA260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ,=20 This is regarding diffserv implementation (through COPS PR ) =20 =3D=3D> I have a few doubts regarding the mapping of a few parameters of = qosInfoModel (draft-ietf-policy-qos-info-model-03) onto the diffservPIB (draft-ietf-diffserv-pib-04). 1) 'qpAdmissionScope' attribute of the qosPolicyAdmissionAction class.=20 'This property specifies whether the admission decision is done per flow = or per the entire class of flows. 2) 'qpFairness' attribute of the qosPolicyBanwidth Action class. 3) 'qpMaxDelay' attribute of the qosPolicyBanwidth Action class. 4) 'qpMaxJitter' attribute of the qosPolicyBanwidth Action class. =3D=3D> Another doubt is can we have multiple datapath tables for the = same combination of "interfaceType and Role" ? i.e., If there are two different policies P1 and P2 for the Interface = type "A1", role combination "A+B". For policy P1 , PDP constructs and sends a datapath table which consists = of interface type "A1", role combination "A+B"=20 For policy P2, PDP constructs and sends another datapath table which = consists of same interface type"A1", role combination "A+B". Thanks in advance ~ =20 Saurabh Kapoor -------------------------------------------------------------------------= ------------- ------=_NextPart_000_00C2_01C1272D.FDABA260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ,
This is regarding diffserv=20 implementation (through COPS PR )
 
=3D=3D> I have a few doubts = regarding the=20 mapping of a few parameters of qosInfoModel (draft-ietf-policy-qos-info-model-03)
 onto = the diffservPIB=20 (draft-ietf-diffserv-pib-04).
 
1) 'qpAdmissionScope' attribute of = the=20 qosPolicyAdmissionAction class.
'This property specifies whether the = admission=20 decision is done per flow or per the entire class of flows.
2) 'qpFairness' attribute of the=20 qosPolicyBanwidth Action class.
3) 'qpMaxDelay'=20 attribute of the qosPolicyBanwidth Action class.
4) 'qpMaxJitter' attribute of the=20 qosPolicyBanwidth Action class.
 
=3D=3D> Another doubt is can we have multiple datapath = tables for=20 the same combination of "interfaceType and Role" ?
i.e.,   If there are two = different=20 policies P1 and P2  for the Interface type "A1", role combination=20 "A+B".
 
For policy P1 , PDP constructs and = sends a=20 datapath table which consists of interface type "A1", role combination = "A+B"=20
For policy P2, PDP constructs and sends = another=20 datapath table which consists of same interface type"A1", role = combination=20 "A+B".
 
 
Thanks in advance ~ 
Saurabh=20 Kapoor
---------------------------------------------------------------= -----------------------
------=_NextPart_000_00C2_01C1272D.FDABA260-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- From owner-rap@ops.ietf.org Fri Aug 17 08:59:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27931 for ; Fri, 17 Aug 2001 08:59:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XjE8-000Iuq-00 for rap-data@psg.com; Fri, 17 Aug 2001 05:59:52 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.31 #1) id 15XjE7-000Iuh-00 for rap@ops.ietf.org; Fri, 17 Aug 2001 05:59:51 -0700 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.4/8.11.4) with SMTP id f7HCxbC02949 for ; Fri, 17 Aug 2001 18:29:37 +0530 (IST) Received: from kapoor ([192.168.143.50]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GI7QRJ00.RZH for ; Fri, 17 Aug 2001 18:29:43 +0530 Message-ID: <021201c1271c$7e1c0e60$328fa8c0@wipsys.stph.net> From: "Saurabh kapoor" To: Subject: user group information in frameworkpib Date: Fri, 17 Aug 2001 18:29:46 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_020F_01C1274A.974C55B0" ------=_NextPart_000_020F_01C1274A.974C55B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another doubt regarding the Framework PIB = (draft-ietf-rap-frameworkpib-05 )=20 =3D=3D> How to represent the user group information The frwrkIpFilterTable has the capability to represent the = frwrkIpFilterDstAddr & frwrkIpFilterDstAddrMask=20 But how do we utilize them or someother parameters in the PIB to encode = the usergroup information and send it to PEP ? Regards,=20 Saurabh Kapoor -------------------------------------------------------------------------= ------------- ------=_NextPart_000_020F_01C1274A.974C55B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another doubt regarding = the Framework=20 PIB (draft-ietf-rap-frameworkpib-05 )
=3D=3D> How to represent the user = group=20 information
The frwrkIpFilterTable has the = capability to=20 represent the frwrkIpFilterDstAddr & frwrkIpFilterDstAddrMask =
But how do we utilize them or someother = parameters=20 in the PIB to encode the usergroup information and send it to PEP=20 ?
 
Regards,
Saurabh=20 Kapoor
---------------------------------------------------------------= -----------------------
------=_NextPart_000_020F_01C1274A.974C55B0-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- From owner-rap@ops.ietf.org Fri Aug 17 09:31:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00483 for ; Fri, 17 Aug 2001 09:31:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XjjW-000JfY-00 for rap-data@psg.com; Fri, 17 Aug 2001 06:32:18 -0700 Received: from ahab.tic.siemens.ca ([64.26.131.130]) by psg.com with esmtp (Exim 3.31 #1) id 15XjjU-000Jf8-00 for rap@ops.ietf.org; Fri, 17 Aug 2001 06:32:16 -0700 Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f7HDT1Q19378 for ; Fri, 17 Aug 2001 09:29:01 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from (mailman [172.21.24.8]) by ahab via smap (V2.1) id xma019376; Fri, 17 Aug 01 09:28:43 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f7HDVPf21248 for ; Fri, 17 Aug 2001 09:31:25 -0400 (EDT) Received: from (ticsmtp1.innovation.siemens.ca [172.21.24.34]) by mailman via smap (V2.1) id xma020930; Fri, 17 Aug 01 09:30:03 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Aug 2001 09:29:44 -0400 Message-ID: From: Dean Goodwin To: "'rap@ops.ietf.org'" Subject: Meeting Minutes for rap session 1 - IETF 51 Date: Fri, 17 Aug 2001 09:29:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12720.AD9657B4" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12720.AD9657B4 Content-Type: text/plain; charset="iso-8859-1" I was unable to attend the first of the two "rap" sessions in London and was wondering if anyone knew where I could find the minutes from that session. Thanks in advance Dean ------_=_NextPart_001_01C12720.AD9657B4 Content-Type: text/html; charset="iso-8859-1" ifIndex rap-frameworkpib-05
I was unable to attend the first of the two "rap" sessions in London and was wondering if anyone knew where I could find the minutes from that session. 
 
Thanks in advance
 
Dean
 
------_=_NextPart_001_01C12720.AD9657B4-- From owner-rap@ops.ietf.org Fri Aug 17 09:54:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02031 for ; Fri, 17 Aug 2001 09:54:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Xk5M-000KEi-00 for rap-data@psg.com; Fri, 17 Aug 2001 06:54:52 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.31 #1) id 15Xk5L-000KDw-00 for rap@ops.ietf.org; Fri, 17 Aug 2001 06:54:51 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7HDrvp22335 for ; Fri, 17 Aug 2001 09:53:57 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 17 Aug 2001 09:54:06 -0400 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 Q5Y48MDL; Fri, 17 Aug 2001 09:54:06 -0400 Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5NCHX; Fri, 17 Aug 2001 09:54:05 -0400 Message-Id: <5.0.0.25.0.20010817094953.00a893b0@zbl6c000.corpeast.baynetworks.com> X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 17 Aug 2001 09:53:51 -0400 To: Dean Goodwin From: "Kwok-Ho Chan" Subject: Re: Meeting Minutes for rap session 1 - IETF 51 Cc: "'rap@ops.ietf.org'" , "Kwok-Ho Chan" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8251669==_.ALT" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk --=====================_8251669==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Dean: We (co-chair and acting co-chair) are getting the minutes and slides ready for the IETF Proceedings. I am getting these info on a FTP site for the WG before the Proceedings are published. This should be available in a couple of days. -- Kwok Ho Chan, acting RAP WG Co-Chair -- At 09:29 AM 8/17/01 -0400, Dean Goodwin wrote: >I was unable to attend the first of the two "rap" sessions in London and >was wondering if anyone knew where I could find the minutes from that session. > >Thanks in advance > >Dean > --=====================_8251669==_.ALT Content-Type: text/html; charset="us-ascii" Hi Dean:
We (co-chair and acting co-chair) are getting the minutes and slides
ready for the IETF Proceedings.  I am getting these info on a FTP site for
the WG before the Proceedings are published.  This should be available
in a couple of days.
-- Kwok Ho Chan, acting RAP WG Co-Chair --


At 09:29 AM 8/17/01 -0400, Dean Goodwin wrote:
I was unable to attend the first of the two "rap" sessions in London and was wondering if anyone knew where I could find the minutes from that session.
 
Thanks in advance
 
Dean
 
--=====================_8251669==_.ALT-- From owner-rap@ops.ietf.org Mon Aug 20 10:54:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22765 for ; Mon, 20 Aug 2001 10:54:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YqOn-000Llh-00 for rap-data@psg.com; Mon, 20 Aug 2001 07:51:29 -0700 Received: from motgate2.mot.com ([136.182.1.10]) by psg.com with esmtp (Exim 3.33 #1) id 15YqOn-000Llb-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 07:51:29 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA10921 for ; Mon, 20 Aug 2001 07:51:27 -0700 (MST)] Received: [from zgr01exm01.corp.mot.com (zgr01exm01.corp.mot.com [10.162.168.200]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA16931 for ; Mon, 20 Aug 2001 07:51:26 -0700 (MST)] Received: by zgr01exm01.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 17:51:24 +0300 Message-ID: <332B652C3E8ED411A4EA00B0D049C44C449ED4@zgr01exm01.corp.mot.com> From: Salkintzis Apostolis-Y1026C To: rap@ops.ietf.org Subject: COPS for UMTS Date: Mon, 20 Aug 2001 17:51:23 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12987.94EEB440" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12987.94EEB440 Content-Type: text/plain; charset="ISO-8859-1" Hi all, I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows? Thank you, Apostolis --- ------_=_NextPart_001_01C12987.94EEB440 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I was = looking for a COPS=20 client for UMTS and I'm wondering if there's currently a draft under = way. Anyone=20 knows?
 
Thank=20 you,
Apostolis<= /DIV>
---
<= /BODY> ------_=_NextPart_001_01C12987.94EEB440-- From owner-rap@ops.ietf.org Mon Aug 20 11:22:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23732 for ; Mon, 20 Aug 2001 11:22:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yqrl-000Mag-00 for rap-data@psg.com; Mon, 20 Aug 2001 08:21:25 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15Yqrf-000MaY-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 08:21:20 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KFKsp08557 for ; Mon, 20 Aug 2001 11:20:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 20 Aug 2001 11:20:53 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 11:20:53 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9CA5B686@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org Subject: RE: COPS for UMTS Date: Mon, 20 Aug 2001 11:20:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1298B.B3995D10" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1298B.B3995D10 Content-Type: text/plain; charset="iso-8859-1" Apostolis, There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific COPS client. cheers, Louis-Nicolas Hamer -----Original Message----- From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com] Sent: Monday, August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS Hi all, I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows? Thank you, Apostolis --- ------_=_NextPart_001_01C1298B.B3995D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Apostolis,
 
There is no COPS-UMTS draft effort in the = IETF. I don't=20 beleive the IETF should define a UMTS specific
COPS client.
 
 
cheers,

Louis-Nicolas=20 Hamer           &nb= sp;           &nb= sp;=20

 

-----Original Message-----
From: Salkintzis = Apostolis-Y1026C=20 [mailto:salki@motorola.com]
Sent: Monday, August 20, 2001 = 10:51=20 AM
To: rap@ops.ietf.org
Subject: COPS for=20 UMTS

Hi=20 all,
 
I was = looking for a=20 COPS client for UMTS and I'm wondering if there's currently a draft = under way.=20 Anyone knows?
 
Thank=20 you,
Apostolis<= /DIV>
---
<= /BLOCKQUOTE> ------_=_NextPart_001_01C1298B.B3995D10-- From owner-rap@ops.ietf.org Mon Aug 20 11:32:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24065 for ; Mon, 20 Aug 2001 11:32:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yr3R-000Myg-00 for rap-data@psg.com; Mon, 20 Aug 2001 08:33:29 -0700 Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr) by psg.com with esmtp (Exim 3.33 #1) id 15Yr3R-000MyY-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 08:33:29 -0700 Received: from ubu.enst.fr (ubu.enst.fr [137.194.160.50]) by infres.enst.fr (Postfix) with ESMTP id D7D2D18C4; Mon, 20 Aug 2001 17:33:27 +0200 (MEST) Received: from ubu (localhost [127.0.0.1]) by ubu.enst.fr (8.9.3+Sun/8.9.3) with SMTP id RAA00670; Mon, 20 Aug 2001 17:33:26 +0200 (MEST) Message-ID: <3B812DC6.61CE@yahoo.com> Date: Mon, 20 Aug 2001 17:33:26 +0200 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: Salkintzis Apostolis-Y1026C Cc: rap@ops.ietf.org, trnguyen@enst.fr Subject: Re: COPS for UMTS References: <332B652C3E8ED411A4EA00B0D049C44C449ED4@zgr01exm01.corp.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Apostolis, I have a draft about COPS-SLS but I don't know what do you mean about COPS client for UMST, what do you want to use COPS for ? Where is the COPS client in UMTS you are interested in (router, client UMTS....)? COPS-SLS client may be an end host, a gateway of a LAN or another domain. So an UMST terminal may be also a COPS-SLS client. If you want to use COPS to negotiate a level of service with a network, I hope that it's useful if we well define PIB classes for UMTS client. You can take a glance at http://www.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-00.txt and tell me if it may be applied in your case. Hope that helps, Mai Trang Salkintzis Apostolis-Y1026C wrote: > > Hi all, > > I was looking for a COPS client for UMTS and I'm wondering if there's > currently a draft under way. Anyone knows? > > Thank you, > Apostolis > --- -- --------------------------------------- NGUYEN Thi Mai Trang Ecole Nationale Superieure des Telecommunications Departement INFRES - Bureau C 234-4 46, rue Barrault - 75013 Paris Tel: (+33) (-0)1 45 81 74 61 - Fax : (+33) (-0)1 45 81 31 19 email : trnguyen@enst.fr --------------------------------------- From owner-rap@ops.ietf.org Mon Aug 20 14:16:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29163 for ; Mon, 20 Aug 2001 14:16:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Ytbh-0001ay-00 for rap-data@psg.com; Mon, 20 Aug 2001 11:17:01 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15Ytbg-0001ap-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 11:17:00 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KIGYp13025 for ; Mon, 20 Aug 2001 14:16:34 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 20 Aug 2001 14:16:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 14:16:41 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "Louis-Nicolas Hamer" , "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org Subject: RE: COPS for UMTS Date: Mon, 20 Aug 2001 14:16:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C129A4.41DAD3C0" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C129A4.41DAD3C0 Content-Type: text/plain I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type. - Muhammad Jaseemuddin > -----Original Message----- > From: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] > Sent: Monday, August 20, 2001 11:21 AM > To: 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org > Subject: RE: COPS for UMTS > > Apostolis, > > There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF > should define a UMTS specific > COPS client. > > > cheers, > > > Louis-Nicolas Hamer > > > > > -----Original Message----- > From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com] > Sent: Monday, August 20, 2001 10:51 AM > To: rap@ops.ietf.org > Subject: COPS for UMTS > > > Hi all, > > I was looking for a COPS client for UMTS and I'm wondering if > there's currently a draft under way. Anyone knows? > > Thank you, > Apostolis > --- > ------_=_NextPart_001_01C129A4.41DAD3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: COPS for UMTS

I concur with = Louis. The PDP context signaling is UMTS specific, its not an IETF = signaling protocol, hence IETF cannot standardize any such client = type.

- Muhammad = Jaseemuddin

    -----Original Message-----
    From:   Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]
    Sent:   Monday, August 20, 2001 11:21 AM
    To:     'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
    Subject:       = RE: COPS for UMTS

    Apostolis,
    =A0
    There is = no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should = define a UMTS specific
    COPS = client.
    =A0
    =A0
    cheers,

    Louis-Nicolas Hamer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0

    =A0

      -----Original Message-----
      From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com<= /U>]
      Sent: Monday, August 20, 2001 10:51 AM
      To: rap@ops.ietf.org
      Subject: COPS for UMTS
      Hi all,
      =A0
      I was looking for a = COPS client for UMTS and I'm wondering if there's currently a draft = under way. Anyone knows?
      =A0
      Thank you,
      Apostolis
      ---

------_=_NextPart_001_01C129A4.41DAD3C0-- From owner-rap@ops.ietf.org Mon Aug 20 15:04:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00219 for ; Mon, 20 Aug 2001 15:04:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YuKM-0002y2-00 for rap-data@psg.com; Mon, 20 Aug 2001 12:03:10 -0700 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 15YuKL-0002xw-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 12:03:09 -0700 Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7KJ32q19815 for ; Mon, 20 Aug 2001 15:03:02 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Aug 2001 20:02:56 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CCAE9@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Muhammad Jaseemuddin'" , Louis-Nicolas Hamer , "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org Subject: RE: COPS for UMTS Date: Mon, 20 Aug 2001 20:02:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C129AA.B7DA9820" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C129AA.B7DA9820 Content-Type: text/plain; charset="iso-8859-1" Is there anything from GTP or 3GPP specific passed over the COPS based interface? is the problem solved by this limited to UMTS, or driven by broader service requirements? Would it make sense to solve this problem once for all access technologies or are there technology dependent issues addressed by this? Is it a decision outsourcing problem or a provisioning problem? alessio -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: 20 August 2001 19:17 To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type. - Muhammad Jaseemuddin -----Original Message----- From: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] Sent: Monday, August 20, 2001 11:21 AM To: 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS Apostolis, There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific COPS client. cheers, Louis-Nicolas Hamer -----Original Message----- From: Salkintzis Apostolis-Y1026C [ mailto:salki@motorola.com ] Sent: Monday, August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS Hi all, I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows? Thank you, Apostolis --- ------_=_NextPart_001_01C129AA.B7DA9820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: COPS for UMTS
Is=20 there anything from GTP or 3GPP specific passed over the COPS based = interface?=20 is the problem solved by this
limited to UMTS, or driven by broader = service=20 requirements? Would it make sense to solve
this=20 problem once for all access technologies or are there technology = dependent=20 issues
addressed by this? Is it a decision = outsourcing problem=20 or a provisioning problem?
 
 
alessio
-----Original Message-----
From: Muhammad = Jaseemuddin=20 [mailto:jaseem@nortelnetworks.com]
Sent: 20 August 2001=20 19:17
To: Louis-Nicolas Hamer; 'Salkintzis = Apostolis-Y1026C';=20 rap@ops.ietf.org
Subject: RE: COPS for = UMTS

I concur with = Louis. The PDP=20 context signaling is UMTS specific, its not an IETF signaling = protocol, hence=20 IETF cannot standardize any such client type.

- Muhammad = Jaseemuddin=20

    -----Original Message----- =
    From:   Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]
    Sent:   Monday, August=20 20, 2001 11:21 AM
    To:     'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org =
    Subject:        = RE: COPS for UMTS

    Apostolis,=20
     
    There is no COPS-UMTS draft effort = in the IETF.=20 I don't beleive the IETF should define a UMTS specific =
    COPS = client.
     
      =
    cheers,

    Louis-Nicolas=20 Hamer           &nb= sp;           &nb= sp;

     

      -----Original = Message-----
      From: Salkintzis=20 Apostolis-Y1026C [mailto:salki@motorola.com<= /U>]
      Sent: Monday, = August 20, 2001=20 10:51 AM
      To: rap@ops.ietf.org
      Subject: COPS = for=20 UMTS


      Hi=20 all,
       
      I was looking for a COPS client for UMTS = and I'm=20 wondering if there's currently a draft under way. Anyone = knows?=20
       
      Thank you,
      Apostolis
      ---

------_=_NextPart_001_01C129AA.B7DA9820-- From owner-rap@ops.ietf.org Mon Aug 20 15:10:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00492 for ; Mon, 20 Aug 2001 15:10:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YuQs-0003Aq-00 for rap-data@psg.com; Mon, 20 Aug 2001 12:09:54 -0700 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 15YuQs-0003Aj-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 12:09:54 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7KJ9qh25833 for ; Mon, 20 Aug 2001 15:09:52 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Aug 2001 21:09:51 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D3DB118@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Muhammad Jaseemuddin , Louis-Nicolas Hamer , "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org Subject: RE: COPS for UMTS Date: Mon, 20 Aug 2001 21:09:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C129AB.AFA24BC0" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C129AB.AFA24BC0 Content-Type: text/plain; charset="iso-8859-1" So can someone explain to me what the COPS-UMTS-Client Type is that is being discussed in 3GPP ? May I assume they are aware that they must follow IANA guidelines to obtain assignments for such Client Types? Bert -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: maandag 20 augustus 2001 20:17 To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type. - Muhammad Jaseemuddin -----Original Message----- From: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] Sent: Monday, August 20, 2001 11:21 AM To: 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS Apostolis, There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific COPS client. cheers, Louis-Nicolas Hamer -----Original Message----- From: Salkintzis Apostolis-Y1026C [ mailto:salki@motorola.com ] Sent: Monday, August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS Hi all, I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows? Thank you, Apostolis --- ------_=_NextPart_001_01C129AB.AFA24BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: COPS for UMTS
So can=20 someone explain to me what the COPS-UMTS-Client Type is that is being=20
discussed in 3GPP ? May I assume they are = aware that=20 they must follow IANA
guidelines to obtain assignments for such = Client=20 Types?

Bert

-----Original Message-----
From: Muhammad = Jaseemuddin=20 [mailto:jaseem@nortelnetworks.com]
Sent: maandag 20 = augustus 2001=20 20:17
To: Louis-Nicolas Hamer; 'Salkintzis = Apostolis-Y1026C';=20 rap@ops.ietf.org
Subject: RE: COPS for = UMTS

I concur with = Louis. The PDP=20 context signaling is UMTS specific, its not an IETF signaling = protocol, hence=20 IETF cannot standardize any such client type.

- Muhammad = Jaseemuddin=20

    -----Original Message----- =
    From:   Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]
    Sent:   Monday, August=20 20, 2001 11:21 AM
    To:     'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org =
    Subject:        = RE: COPS for UMTS

    Apostolis,=20
     
    There is no COPS-UMTS draft effort = in the IETF.=20 I don't beleive the IETF should define a UMTS specific =
    COPS = client.
     
      =
    cheers,

    Louis-Nicolas=20 Hamer           &nb= sp;           &nb= sp;

     

      -----Original = Message-----
      From: Salkintzis=20 Apostolis-Y1026C [mailto:salki@motorola.com<= /U>]
      Sent: Monday, = August 20, 2001=20 10:51 AM
      To: rap@ops.ietf.org
      Subject: COPS = for=20 UMTS


      Hi=20 all,
       
      I was looking for a COPS client for UMTS = and I'm=20 wondering if there's currently a draft under way. Anyone = knows?=20
       
      Thank you,
      Apostolis
      ---

------_=_NextPart_001_01C129AB.AFA24BC0-- From owner-rap@ops.ietf.org Mon Aug 20 15:13:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00573 for ; Mon, 20 Aug 2001 15:13:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YuV0-0003K3-00 for rap-data@psg.com; Mon, 20 Aug 2001 12:14:10 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15YuUz-0003Jw-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 12:14:09 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KJDjp21631 for ; Mon, 20 Aug 2001 15:13:45 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 20 Aug 2001 15:13:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 15:13:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9CA5B694@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Casati, Alessio (Alessio)'" , "Muhammad Jaseemuddin" , "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org Subject: RE: COPS for UMTS Date: Mon, 20 Aug 2001 15:13:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C129AC.38A78160" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C129AC.38A78160 Content-Type: text/plain; charset="iso-8859-1" Alessio, All very good questions we will have to answer before we can move forward. See below for comments. Louis-Nicolas -----Original Message----- From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com] Sent: Monday, August 20, 2001 3:03 PM To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS Is there anything from GTP or 3GPP specific passed over the COPS based interface? [Louis-Nicolas Hamer] We must first identify the requirements. 3GPP CN3 WG will be tackling this soon. is the problem solved by this limited to UMTS, or driven by broader service requirements? Would it make sense to solve this problem once for all access technologies or are there technology dependent issues addressed by this? [Louis-Nicolas Hamer] I agree. I'd hate to have to define a new solution for every access technology. If we can come up with a broader solution, that would be great. But again, more detailed analysis is needed before we can make that call. Is it a decision outsourcing problem or a provisioning problem? [Louis-Nicolas Hamer] Outsourcing problem. alessio -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: 20 August 2001 19:17 To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type. - Muhammad Jaseemuddin -----Original Message----- From: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] Sent: Monday, August 20, 2001 11:21 AM To: 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS Apostolis, There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific COPS client. cheers, Louis-Nicolas Hamer -----Original Message----- From: Salkintzis Apostolis-Y1026C [ mailto:salki@motorola.com ] Sent: Monday, August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS Hi all, I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows? Thank you, Apostolis --- ------_=_NextPart_001_01C129AC.38A78160 Content-Type: text/html; charset="iso-8859-1" RE: COPS for UMTS
Alessio,
 
All very good questions we will have to answer before we can move forward.
See below for comments.
 

Louis-Nicolas 
 -----Original Message-----
From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com]
Sent: Monday, August 20, 2001 3:03 PM
To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS


Is there anything from GTP or 3GPP specific passed over the COPS based interface?
[Louis-Nicolas Hamer] We must first identify the requirements. 3GPP CN3 WG will be tackling this soon.
 
 is the problem solved by this
limited to UMTS, or driven by broader service requirements? Would it make sense to solve
this problem once for all access technologies or are there technology dependent issues
addressed by this?
[Louis-Nicolas Hamer] I agree. I'd hate to have to define a new solution for every access technology. If we can come up with a broader solution, that would be great. But again, more detailed analysis is needed before we can make that call.
 
  Is it a decision outsourcing problem or a provisioning problem?
[Louis-Nicolas Hamer] Outsourcing problem. 
 
 
alessio
-----Original Message-----
From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com]
Sent: 20 August 2001 19:17
To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS

I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type.

- Muhammad Jaseemuddin

    -----Original Message-----
    From:   Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]
    Sent:   Monday, August 20, 2001 11:21 AM
    To:     'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
    Subject:        RE: COPS for UMTS

    Apostolis,
     
    There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific
    COPS client.
     
     
    cheers,

    Louis-Nicolas Hamer                        

     

      -----Original Message-----
      From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com]
      Sent: Monday, August 20, 2001 10:51 AM
      To: rap@ops.ietf.org
      Subject: COPS for UMTS


      Hi all,
       
      I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows?
       
      Thank you,
      Apostolis
      ---

------_=_NextPart_001_01C129AC.38A78160-- From owner-rap@ops.ietf.org Mon Aug 20 15:23:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00863 for ; Mon, 20 Aug 2001 15:23:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yudo-0003bW-00 for rap-data@psg.com; Mon, 20 Aug 2001 12:23:16 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15Yudn-0003bQ-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 12:23:16 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KJMpp22921 for ; Mon, 20 Aug 2001 15:22:51 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 20 Aug 2001 15:22:57 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 15:22:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9CA5B695@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Wijnen, Bert (Bert)'" , "Muhammad Jaseemuddin" , "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org Subject: RE: COPS for UMTS Date: Mon, 20 Aug 2001 15:22:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C129AD.8480D040" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C129AD.8480D040 Content-Type: text/plain; charset="iso-8859-1" Bert, Please consult www.3gpp.org . The details are in specification TS23.207. Basically, 3GPP has decided to use COPS for the interface between the PEP located in the GGSN (edge router) and the PCF (PDP). That's why we came up with: " COPS for UTMS" for the time being. More work is to be done to clearly define the requirements before we can move forward. 3GPP is still in the early stages for this work...IANA is still a distant worry right now ;-) L-N -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Monday, August 20, 2001 3:10 PM To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS So can someone explain to me what the COPS-UMTS-Client Type is that is being discussed in 3GPP ? May I assume they are aware that they must follow IANA guidelines to obtain assignments for such Client Types? Bert -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: maandag 20 augustus 2001 20:17 To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type. - Muhammad Jaseemuddin -----Original Message----- From: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] Sent: Monday, August 20, 2001 11:21 AM To: 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS Apostolis, There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific COPS client. cheers, Louis-Nicolas Hamer -----Original Message----- From: Salkintzis Apostolis-Y1026C [ mailto:salki@motorola.com ] Sent: Monday, August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS Hi all, I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows? Thank you, Apostolis --- ------_=_NextPart_001_01C129AD.8480D040 Content-Type: text/html; charset="iso-8859-1" RE: COPS for UMTS
Bert,
 
Please consult www.3gpp.org. The details are in specification TS23.207. Basically, 3GPP has decided to use COPS for the interface
between the PEP located in the GGSN (edge router) and the PCF (PDP).
 
That's why we came up with: " COPS for UTMS" for the time being. More work is to be done to clearly define the requirements before
we can move forward. 3GPP is still in the early stages for this work...IANA is still a distant worry right now ;-)
 
L-N
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, August 20, 2001 3:10 PM
To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS

So can someone explain to me what the COPS-UMTS-Client Type is that is being
discussed in 3GPP ? May I assume they are aware that they must follow IANA
guidelines to obtain assignments for such Client Types?

Bert

-----Original Message-----
From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com]
Sent: maandag 20 augustus 2001 20:17
To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS

I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type.

- Muhammad Jaseemuddin

    -----Original Message-----
    From:   Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]
    Sent:   Monday, August 20, 2001 11:21 AM
    To:     'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
    Subject:        RE: COPS for UMTS

    Apostolis,
     
    There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific
    COPS client.
     
     
    cheers,

    Louis-Nicolas Hamer                        

     

      -----Original Message-----
      From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com]
      Sent: Monday, August 20, 2001 10:51 AM
      To: rap@ops.ietf.org
      Subject: COPS for UMTS


      Hi all,
       
      I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows?
       
      Thank you,
      Apostolis
      ---

------_=_NextPart_001_01C129AD.8480D040-- From owner-rap@ops.ietf.org Mon Aug 20 15:33:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01178 for ; Mon, 20 Aug 2001 15:33:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yuoj-0003yW-00 for rap-data@psg.com; Mon, 20 Aug 2001 12:34:33 -0700 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 15Yuoi-0003yQ-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 12:34:32 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7KJYVh06221 for ; Mon, 20 Aug 2001 15:34:31 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Aug 2001 21:34:25 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D3DB122@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Louis-Nicolas Hamer , Muhammad Jaseemuddin , "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org Subject: RE: COPS for UMTS Date: Mon, 20 Aug 2001 21:34:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C129AF.1DDCA6A0" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C129AF.1DDCA6A0 Content-Type: text/plain; charset="iso-8859-1" I have seen that document. From that, it is not clear to me if - Your are gonna do just COPS, which I think means no PIB - You are also gonna do COPS-PR, which I think means a PIB There is talk about using both RSVP and Diffserv for end-to-end QoS so when I see Diffserv, then I suspect COPS-PR, but that is not clear. Also... I thought that there was no final decision yet that COPS was going to be the interface... the doc has not yet been approved, has it? Sorry for not understanding the details of the process in 3GPP. Bert -----Original Message----- From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] Sent: maandag 20 augustus 2001 21:23 To: 'Wijnen, Bert (Bert)'; Muhammad Jaseemuddin; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS Bert, Please consult www.3gpp.org . The details are in specification TS23.207. Basically, 3GPP has decided to use COPS for the interface between the PEP located in the GGSN (edge router) and the PCF (PDP). That's why we came up with: " COPS for UTMS" for the time being. More work is to be done to clearly define the requirements before we can move forward. 3GPP is still in the early stages for this work...IANA is still a distant worry right now ;-) L-N -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Monday, August 20, 2001 3:10 PM To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS So can someone explain to me what the COPS-UMTS-Client Type is that is being discussed in 3GPP ? May I assume they are aware that they must follow IANA guidelines to obtain assignments for such Client Types? Bert -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: maandag 20 augustus 2001 20:17 To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type. - Muhammad Jaseemuddin -----Original Message----- From: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] Sent: Monday, August 20, 2001 11:21 AM To: 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS Apostolis, There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific COPS client. cheers, Louis-Nicolas Hamer -----Original Message----- From: Salkintzis Apostolis-Y1026C [ mailto:salki@motorola.com ] Sent: Monday, August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS Hi all, I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows? Thank you, Apostolis --- ------_=_NextPart_001_01C129AF.1DDCA6A0 Content-Type: text/html; charset="iso-8859-1" RE: COPS for UMTS
I have seen that document. From that, it is not clear to me if
- Your are gonna do just COPS, which I think means no PIB
- You are also gonna do COPS-PR, which I think means a PIB
 
There is talk about using both RSVP and Diffserv for end-to-end QoS
so when I see Diffserv, then I suspect COPS-PR, but that is not clear.
 
Also... I thought that there was no final decision yet that COPS was
going to be the interface... the doc has not yet been approved, has it?
Sorry for not understanding the details of the process in 3GPP.

Bert

-----Original Message-----
From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com]
Sent: maandag 20 augustus 2001 21:23
To: 'Wijnen, Bert (Bert)'; Muhammad Jaseemuddin; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS

Bert,
 
Please consult www.3gpp.org. The details are in specification TS23.207. Basically, 3GPP has decided to use COPS for the interface
between the PEP located in the GGSN (edge router) and the PCF (PDP).
 
That's why we came up with: " COPS for UTMS" for the time being. More work is to be done to clearly define the requirements before
we can move forward. 3GPP is still in the early stages for this work...IANA is still a distant worry right now ;-)
 
L-N
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, August 20, 2001 3:10 PM
To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS

So can someone explain to me what the COPS-UMTS-Client Type is that is being
discussed in 3GPP ? May I assume they are aware that they must follow IANA
guidelines to obtain assignments for such Client Types?

Bert

-----Original Message-----
From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com]
Sent: maandag 20 augustus 2001 20:17
To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS

I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type.

- Muhammad Jaseemuddin

    -----Original Message-----
    From:   Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]
    Sent:   Monday, August 20, 2001 11:21 AM
    To:     'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
    Subject:        RE: COPS for UMTS

    Apostolis,
     
    There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific
    COPS client.
     
     
    cheers,

    Louis-Nicolas Hamer                        

     

      -----Original Message-----
      From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com]
      Sent: Monday, August 20, 2001 10:51 AM
      To: rap@ops.ietf.org
      Subject: COPS for UMTS


      Hi all,
       
      I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows?
       
      Thank you,
      Apostolis
      ---

------_=_NextPart_001_01C129AF.1DDCA6A0-- From owner-rap@ops.ietf.org Mon Aug 20 15:40:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01352 for ; Mon, 20 Aug 2001 15:40:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yuuj-0004Bb-00 for rap-data@psg.com; Mon, 20 Aug 2001 12:40:45 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15Yuui-0004BG-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 12:40:44 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KJeKp25363 for ; Mon, 20 Aug 2001 15:40:20 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 20 Aug 2001 15:40:24 -0400 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 R21R7DN9; Mon, 20 Aug 2001 15:40:23 -0400 Received: from tweedy.NortelNetworks.com (dhcp229-108.engeast.baynetworks.com [192.32.229.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5NDBA; Mon, 20 Aug 2001 15:40:20 -0400 Message-Id: <5.0.0.25.0.20010820153601.02d11d10@zbl6c000.corpeast.baynetworks.com> X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 20 Aug 2001 15:39:58 -0400 To: "Louis-Nicolas Hamer" From: "Kwok-Ho Chan" Subject: RE: COPS for UMTS Cc: "'Wijnen, Bert (Bert)'" , "Muhammad Jaseemuddin" , "'Salkintzis Apostolis-Y1026C'" , rap@ops.ietf.org In-Reply-To: <9FBD322B7824D511B36900508BF93C9CA5B695@zcard031.ca.nortel. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23922228==_.ALT" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk --=====================_23922228==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Right, This discussion has been jumping into conclusions that we will be creating a UMTS COPS Client Type. That is not the intend at all. This mail thread was started that way, hence the title. We are looking into the requirements before defining solutions. -- Kwok -- At 03:22 PM 8/20/01 -0400, Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] wrote: >Bert, > >Please consult www.3gpp.org. The details are in >specification TS23.207. Basically, 3GPP has decided to use COPS for the >interface >between the PEP located in the GGSN (edge router) and the PCF (PDP). > >That's why we came up with: " COPS for UTMS" for the time being. More work >is to be done to clearly define the requirements before >we can move forward. 3GPP is still in the early stages for this >work...IANA is still a distant worry right now ;-) > >L-N >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Monday, August 20, 2001 3:10 PM >To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas >[WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org >Subject: RE: COPS for UMTS > >So can someone explain to me what the COPS-UMTS-Client Type is that is being >discussed in 3GPP ? May I assume they are aware that they must follow IANA >guidelines to obtain assignments for such Client Types? > >Bert >>-----Original Message----- >>From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] >>Sent: maandag 20 augustus 2001 20:17 >>To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org >>Subject: RE: COPS for UMTS >> >>I concur with Louis. The PDP context signaling is UMTS specific, its not >>an IETF signaling protocol, hence IETF cannot standardize any such client >>type. >>- Muhammad Jaseemuddin >>-----Original Message----- From: Hamer, Louis-Nicolas >>[WDLN2:AN22:EXCH] Sent: Monday, August 20, 2001 11:21 >>AM To: 'Salkintzis Apostolis-Y1026C'; >>rap@ops.ietf.org Subject: RE: COPS for UMTS >> >>Apostolis, There is no COPS-UMTS draft effort in the IETF. I don't >>beleive the IETF should define a UMTS specific COPS >>client. cheers, Louis-Nicolas Hamer >> >> >>-----Original Message----- From: Salkintzis Apostolis-Y1026C >>[mailto:salki@motorola.com] Sent: Monday, >>August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS >> >>Hi all, I was looking for a COPS client for UMTS and I'm wondering if >>there's currently a draft under way. Anyone knows? Thank >>you, Apostolis --- --=====================_23922228==_.ALT Content-Type: text/html; charset="us-ascii" Right, This discussion has been jumping into conclusions that we will be
creating a UMTS COPS Client Type.  That is not the intend at all.
This mail thread was started that way, hence the title.
We are looking into the requirements before defining solutions.
-- Kwok --


At 03:22 PM 8/20/01 -0400, Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] wrote:
Bert,
 
Please consult www.3gpp.org. The details are in specification TS23.207. Basically, 3GPP has decided to use COPS for the interface
between the PEP located in the GGSN (edge router) and the PCF (PDP).
 
That's why we came up with: " COPS for UTMS" for the time being. More work is to be done to clearly define the requirements before
we can move forward. 3GPP is still in the early stages for this work...IANA is still a distant worry right now ;-)
 
L-N
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, August 20, 2001 3:10 PM
To: Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS
So can someone explain to me what the COPS-UMTS-Client Type is that is being
discussed in 3GPP ? May I assume they are aware that they must follow IANA
guidelines to obtain assignments for such Client Types?

Bert
-----Original Message-----
From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com]
Sent: maandag 20 augustus 2001 20:17
To: Louis-Nicolas Hamer; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org
Subject: RE: COPS for UMTS
I concur with Louis. The PDP context signaling is UMTS specific, its not an IETF signaling protocol, hence IETF cannot standardize any such client type.
- Muhammad Jaseemuddin
    -----Original Message----- From:  Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] Sent:  Monday, August 20, 2001 11:21 AM To:    'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject:       RE: COPS for UMTS

    Apostolis,   There is no COPS-UMTS draft effort in the IETF. I don't beleive the IETF should define a UMTS specific COPS client.     cheers, Louis-Nicolas Hamer                       

     
      -----Original Message----- From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com] Sent: Monday, August 20, 2001 10:51 AM To: rap@ops.ietf.org Subject: COPS for UMTS

      Hi all,   I was looking for a COPS client for UMTS and I'm wondering if there's currently a draft under way. Anyone knows?   Thank you, Apostolis ---
--=====================_23922228==_.ALT-- From owner-rap@ops.ietf.org Mon Aug 20 18:59:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06596 for ; Mon, 20 Aug 2001 18:59:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yy06-000B2d-00 for rap-data@psg.com; Mon, 20 Aug 2001 15:58:30 -0700 Received: from [204.92.244.243] (helo=kanatamail.unispherenetworks.ca) by psg.com with esmtp (Exim 3.33 #1) id 15Yy05-000B2V-00 for rap@ops.ietf.org; Mon, 20 Aug 2001 15:58:29 -0700 Received: by kanatamail.kanata.unispherenetworks.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 18:58:28 -0400 Message-ID: <490717515EE6D41187A60003470D71361BB788@kanatamail.kanata.unispherenetworks.ca> From: "Bokaemper, Martin" To: rap@ops.ietf.org Subject: Incremental state updates from PEP -> PDP in COPS-PR ? Date: Mon, 20 Aug 2001 18:58:18 -0400 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! The subject line has the short version of the issue, here is the long one. Problem background: The PDP can create/update/delete named objects individually, for example send a single object instance or delete one. In other words it can change decision state incrementally. Problem: - The PEP does not seem to have the possibility of incremental updates to the request state: - a REQ in COPS-PR has to include all relevant information for the PDP. - a second REQ cannot delete specific named objects a previous REQ communicated to the PDP. => When changes occur, the whole request state has to be retransmitted in the REQ. - This is not scalable if the PEP's state is large and 'active' (changes frequently). That however seems to be the case in many applications envisioned for COPS-PR - including it's core diffserv application and the associated framework-pib: - frwkIfCapSetRoleComboTable If someone implements [from draft-ietf-rap-frameworkpib-05] > We point out that, in the event that the administrator > needs to have unique policy for each interface, this can > be achieved by configuring each interface with a unique role. this table will have one entry per interface. - frwkIfCapSetInterfaceEntry This table contains one entry per interface anyway. I assume every table with 'per-interface' information to be potentially 'large & active': Todays access routers support >10k interfaces and interface information may change as users connect or disconnect. To me this looks like a very serious issue as it already limits the base diffserv application - and also seems to be relevant for draft-jacquenet-ip-te-pib-00.txt and draft-ietf-rap-access-bind-00.txt. I see several potential changes to solve the issue but I'd like to make sure it is a real problem first - if this can already be done in a way that I just don't see, please let me know. Regards, Martin. [ From RFC 2748: The COPS Protocol ] [sect 3.2] This essentially means that the PEP SHOULD NOT issue more than one REQ (for a given handle) before it receives a corresponding DEC with the solicited message flag set. The PDP MUST always issue decisions for requests on a particular handle in the order they arrive and all requests MUST have a corresponding decision. [ From RFC 3084: COPS-PR ] [sect. 6] Any relevant changes to the PEP's internal state can be communicated to the PDP by the PEP sending an updated REQ message. The PEP is free to send such updated REQ messages at any time after a CAT message to communicate changes in its local state. [sect. 6] The PEP MUST acknowledge a DEC message and specify what action was taken by sending a RPT message with a "Success" or "Failure" Report- Type object with the Solicited Message Flag set in the COPS message header. From owner-rap@ops.ietf.org Wed Aug 22 13:03:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16718 for ; Wed, 22 Aug 2001 13:03:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZbOC-0008wL-00 for rap-data@psg.com; Wed, 22 Aug 2001 10:02:00 -0700 Received: from [64.223.136.42] (helo=postal.ellacoya.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZbOB-0008wE-00 for rap@ops.ietf.org; Wed, 22 Aug 2001 10:02:00 -0700 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.121.248]) by postal.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PS1T5NJD; Wed, 22 Aug 2001 13:01:57 -0400 Message-ID: <3B83E577.B41C3DF@ellacoya.com> Date: Wed, 22 Aug 2001 13:01:43 -0400 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: Working group last-call commences: COPS over TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Working Group last-call to commence on http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt Please review this draft in the next two weeks and submit comments to the mailing list. Working group last-call on this document will end September 5, 2001. From owner-rap@ops.ietf.org Wed Aug 22 14:07:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18811 for ; Wed, 22 Aug 2001 14:07:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZcQa-000CTs-00 for rap-data@psg.com; Wed, 22 Aug 2001 11:08:32 -0700 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZcQZ-000CTN-00 for rap@ops.ietf.org; Wed, 22 Aug 2001 11:08:31 -0700 Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA02110 for ; Wed, 22 Aug 2001 18:08:30 GMT Received: from fmsmsx18.intel.com ([132.233.233.232]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082211101506962 ; Wed, 22 Aug 2001 11:10:15 -0700 Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 11:08:29 -0700 Message-ID: <10C8636AE359D4119118009027AE99870DA5DA27@FMSMSX34> From: "Durham, David" To: "'Bokaemper, Martin'" , rap@ops.ietf.org Subject: RE: Incremental state updates from PEP -> PDP in COPS-PR ? Date: Wed, 22 Aug 2001 11:08:27 -0700 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 Martin, This issue has been raised a number of times. The general perception has been that the request state information for the PEP->PDP is relatively small compared to the configuration decision information from the PDP->PEP and changes less frequently. So basically, the operations were optimized for the latter (although the PIB ultimately decides whether the Request messages express incremental changes or replacements). It is also more difficult to for implementations to support incremental state updates in general, so the benefit of adding incremental support to Requests did not seem to outweigh the cost/complexity of doing so. Now, if these assumptions prove not to be true in some cases, there are a number of ways to deal with it. 1. Use Reports to convey the most dynamic information: Ie. Accounting information, ifindex up and down, etc. Reports do convey incremental updates in all PIBs. 2. Use multiple Requests with different handles, reducing the amount of info per Request. 3. Define Notify PIBs that explicitly handle delta changes (add,delete) via an additional attribute (eg. rowstatus) -Dave > -----Original Message----- > From: Bokaemper, Martin [mailto:MBokaemper@unispherenetworks.com] > Sent: Monday, August 20, 2001 3:58 PM > To: rap@ops.ietf.org > Subject: Incremental state updates from PEP -> PDP in COPS-PR ? > > > Hi! > > The subject line has the short version of the issue, here > is the long one. > > Problem background: > The PDP can create/update/delete named objects individually, > for example send a single object instance or delete one. > In other words it can change decision state incrementally. > > Problem: > - The PEP does not seem to have the possibility of > incremental updates to the request state: > - a REQ in COPS-PR has to include all relevant > information for the PDP. > - a second REQ cannot delete specific named objects a > previous REQ communicated to the PDP. > => When changes occur, the whole request state has to > be retransmitted in the REQ. > - This is not scalable if the PEP's state is large and > 'active' (changes frequently). > That however seems to be the case in many applications > envisioned for COPS-PR - including it's core diffserv > application and the associated framework-pib: > - frwkIfCapSetRoleComboTable > If someone implements [from draft-ietf-rap-frameworkpib-05] > > We point out that, in the event that the administrator > > needs to have unique policy for each interface, this can > > be achieved by configuring each interface with a unique role. > this table will have one entry per interface. > - frwkIfCapSetInterfaceEntry > This table contains one entry per interface anyway. > I assume every table with 'per-interface' information to > be potentially 'large & active': Todays access routers > support >10k interfaces and interface information > may change as users connect or disconnect. > > To me this looks like a very serious issue as it already > limits the base diffserv application - and also seems > to be relevant for draft-jacquenet-ip-te-pib-00.txt > and draft-ietf-rap-access-bind-00.txt. > > I see several potential changes to solve the issue but > I'd like to make sure it is a real problem first - if this > can already be done in a way that I just don't see, > please let me know. > > Regards, > Martin. > > [ From RFC 2748: The COPS Protocol ] > [sect 3.2] > This essentially means that the PEP SHOULD NOT issue more > than one REQ (for a given handle) before it receives a > corresponding > DEC with the solicited message flag set. The PDP MUST always issue > decisions for requests on a particular handle in the order they > arrive and all requests MUST have a corresponding decision. > > [ From RFC 3084: COPS-PR ] > [sect. 6] > Any relevant changes to the PEP's > internal state can be communicated to the PDP by the PEP sending an > updated REQ message. The PEP is free to send such updated REQ > messages at any time after a CAT message to communicate changes in > its local state. > [sect. 6] > The PEP MUST acknowledge a DEC message and specify what action was > taken by sending a RPT message with a "Success" or > "Failure" Report- > Type object with the Solicited Message Flag set in the COPS message > header. > > From owner-rap@ops.ietf.org Wed Aug 22 18:07:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25081 for ; Wed, 22 Aug 2001 18:07:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZgAP-000JYu-00 for rap-data@psg.com; Wed, 22 Aug 2001 15:08:05 -0700 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZgAO-000JYo-00 for rap@ops.ietf.org; Wed, 22 Aug 2001 15:08:04 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7MM6xA21432 for ; Wed, 22 Aug 2001 18:06:59 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Aug 2001 00:06:53 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D49FE19@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mark L. Stevens" , rap@ops.ietf.org Subject: RE: Working group last-call commences: COPS over TLS Date: Thu, 23 Aug 2001 00:06:51 +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 And the document is supposed togo for Informational, right? Bert > -----Original Message----- > From: Mark L. Stevens [mailto:mstevens@ellacoya.com] > Sent: woensdag 22 augustus 2001 19:02 > To: rap@ops.ietf.org > Subject: Working group last-call commences: COPS over TLS > > > Working Group last-call to commence on > http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt > > Please review this draft in the next two weeks and submit comments to > the mailing list. > > Working group last-call on this document will end September 5, 2001. > > > > From owner-rap@ops.ietf.org Thu Aug 23 10:51:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24678 for ; Thu, 23 Aug 2001 10:51:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Zvp1-000COi-00 for rap-data@psg.com; Thu, 23 Aug 2001 07:51:03 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15Zvov-000COD-00 for rap@ops.ietf.org; Thu, 23 Aug 2001 07:51:02 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7NEoSp25301 for ; Thu, 23 Aug 2001 10:50:29 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 23 Aug 2001 10:50:33 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 10:50:36 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9CA5B6B3@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Wijnen, Bert (Bert)'" Cc: "'rap@ops.ietf.org'" Subject: RE: COPS for UMTS Date: Thu, 23 Aug 2001 10:50:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12BE2.F83B8CA0" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12BE2.F83B8CA0 Content-Type: text/plain; charset="iso-8859-1" Bert, You are right, nothing is final in 3GPP until the document is officially published. But the current version of the document was approved in the main plenary meeting and COPS is accepted with no dissidents as the "chosen" protocol. Again, as for the details of the Go interface (based on COPS), I can't say much because it is still work in progress and nothing is defined yet. But I think the general agreement is that COPS-PR may be used for pre-provisioning of general policies and something else is needed on a per flow basis for admission control. Hope this clarifies, Louis-Nicolas Hamer -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Monday, August 20, 2001 3:34 PM To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS I have seen that document. From that, it is not clear to me if - Your are gonna do just COPS, which I think means no PIB - You are also gonna do COPS-PR, which I think means a PIB There is talk about using both RSVP and Diffserv for end-to-end QoS so when I see Diffserv, then I suspect COPS-PR, but that is not clear. Also... I thought that there was no final decision yet that COPS was going to be the interface... the doc has not yet been approved, has it? Sorry for not understanding the details of the process in 3GPP. Bert ------_=_NextPart_001_01C12BE2.F83B8CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: COPS for UMTS
Bert,
 
You are right, nothing is final in 3GPP = until the=20 document is officially published.
But the current version of the document was = approved in=20 the main plenary meeting
and COPS is accepted with no dissidents as = the "chosen"=20 protocol.
 
Again, as for the details of the Go = interface (based on=20 COPS), I can't say much because it is still work in = progress
and nothing is defined yet. =
 
But I think the general agreement is that = COPS-PR may=20 be used for pre-provisioning of general policies
and something else = is needed on a=20 per flow basis for admission control.
 
Hope this=20 clarifies,

Louis-Nicolas=20 Hamer           &nb= sp;           &nb= sp;=20

-----Original Message-----
From: Wijnen, Bert = (Bert)=20 [mailto:bwijnen@lucent.com]
Sent: Monday, August 20, 2001 = 3:34=20 PM
To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Jaseemuddin, = Muhammad=20 [WDLN2:AN33:EXCH]; 'Salkintzis Apostolis-Y1026C';=20 rap@ops.ietf.org
Subject: RE: COPS for = UMTS

I=20 have seen that document. From that, it is not clear to me if=20
-=20 Your are gonna do just COPS, which I think means no = PIB
-=20 You are also gonna do COPS-PR, which I think means a = PIB
 
There is talk about using both RSVP and = Diffserv for=20 end-to-end QoS
so=20 when I see Diffserv, then I suspect COPS-PR, but that is not=20 clear.
 
Also... I thought that there was no final = decision=20 yet that COPS was
going to be the interface... the doc has = not yet been=20 approved, has it?
Sorry for not understanding the details of = the=20 process in 3GPP.

Bert

------_=_NextPart_001_01C12BE2.F83B8CA0-- From owner-rap@ops.ietf.org Thu Aug 23 11:32:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25842 for ; Thu, 23 Aug 2001 11:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZwTI-000D7I-00 for rap-data@psg.com; Thu, 23 Aug 2001 08:32:40 -0700 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZwTH-000D7C-00 for rap@ops.ietf.org; Thu, 23 Aug 2001 08:32:39 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7NFWbv01072 for ; Thu, 23 Aug 2001 11:32:37 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Aug 2001 17:32:31 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D4A013A@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Louis-Nicolas Hamer Cc: "'rap@ops.ietf.org'" Subject: RE: COPS for UMTS Date: Thu, 23 Aug 2001 17:32:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12BE8.D13B0E40" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12BE8.D13B0E40 Content-Type: text/plain; charset="iso-8859-1" Thanks, that helps. Pls make sure the document(s) (specifically T23.207) then do also reference RFC3084. Probably it should also make clear that PIB work needs to be done in that case? Bert -----Original Message----- From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] Sent: donderdag 23 augustus 2001 16:51 To: 'Wijnen, Bert (Bert)' Cc: 'rap@ops.ietf.org' Subject: RE: COPS for UMTS Bert, You are right, nothing is final in 3GPP until the document is officially published. But the current version of the document was approved in the main plenary meeting and COPS is accepted with no dissidents as the "chosen" protocol. Again, as for the details of the Go interface (based on COPS), I can't say much because it is still work in progress and nothing is defined yet. But I think the general agreement is that COPS-PR may be used for pre-provisioning of general policies and something else is needed on a per flow basis for admission control. Hope this clarifies, Louis-Nicolas Hamer -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Monday, August 20, 2001 3:34 PM To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Jaseemuddin, Muhammad [WDLN2:AN33:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org Subject: RE: COPS for UMTS I have seen that document. From that, it is not clear to me if - Your are gonna do just COPS, which I think means no PIB - You are also gonna do COPS-PR, which I think means a PIB There is talk about using both RSVP and Diffserv for end-to-end QoS so when I see Diffserv, then I suspect COPS-PR, but that is not clear. Also... I thought that there was no final decision yet that COPS was going to be the interface... the doc has not yet been approved, has it? Sorry for not understanding the details of the process in 3GPP. Bert ------_=_NextPart_001_01C12BE8.D13B0E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: COPS for UMTS
Thanks, that helps.
Pls=20 make sure the document(s) (specifically T23.207) then do also reference = RFC3084.
Probably it should also make clear that PIB = work needs=20 to be done in that case?
 

Bert

-----Original Message-----
From: Louis-Nicolas = Hamer=20 [mailto:nhamer@nortelnetworks.com]
Sent: donderdag 23 = augustus 2001=20 16:51
To: 'Wijnen, Bert (Bert)'
Cc:=20 'rap@ops.ietf.org'
Subject: RE: COPS for = UMTS

Bert,
 
You are right, nothing is final in 3GPP = until the=20 document is officially published.
But the current version of the document = was approved=20 in the main plenary meeting
and COPS is accepted with no dissidents as = the=20 "chosen" protocol.
 
Again, as for the details of the Go = interface (based=20 on COPS), I can't say much because it is still work in=20 progress
and nothing is defined yet. =
 
But I think the general agreement is that = COPS-PR may=20 be used for pre-provisioning of general policies
and something = else is needed on=20 a per flow basis for admission control.
 
Hope this=20 clarifies,

Louis-Nicolas=20 Hamer           &nb= sp;           &nb= sp;=20

-----Original Message-----
From: Wijnen, Bert = (Bert)=20 [mailto:bwijnen@lucent.com]
Sent: Monday, August 20, 2001 = 3:34=20 PM
To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; = Jaseemuddin,=20 Muhammad [WDLN2:AN33:EXCH]; 'Salkintzis Apostolis-Y1026C';=20 rap@ops.ietf.org
Subject: RE: COPS for = UMTS

I=20 have seen that document. From that, it is not clear to me if=20
-=20 Your are gonna do just COPS, which I think means no = PIB
-=20 You are also gonna do COPS-PR, which I think means a = PIB
 
There is talk about using both RSVP and = Diffserv=20 for end-to-end QoS
so=20 when I see Diffserv, then I suspect COPS-PR, but that is not=20 clear.
 
Also... I thought that there was no = final decision=20 yet that COPS was
going to be the interface... the doc has = not yet=20 been approved, has it?
Sorry for not understanding the details = of the=20 process in 3GPP.

Bert =

------_=_NextPart_001_01C12BE8.D13B0E40-- From owner-rap@ops.ietf.org Thu Aug 23 17:52:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02492 for ; Thu, 23 Aug 2001 17:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15a2Mw-000IuU-00 for rap-data@psg.com; Thu, 23 Aug 2001 14:50:30 -0700 Received: from [203.61.155.116] (helo=newish7.ericsson.com.au) by psg.com with esmtp (Exim 3.33 #1) id 15a2Mv-000Itw-00 for rap@ops.ietf.org; Thu, 23 Aug 2001 14:50:29 -0700 Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id HAA12237; Fri, 24 Aug 2001 07:49:24 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id HAA07724; Fri, 24 Aug 2001 07:50:23 +1000 (EST) Received: from ericsson.com.au (mc2dh146.epa.ericsson.se [146.11.87.146]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R2S958CL; Fri, 24 Aug 2001 07:50:21 +1000 Message-ID: <3B85EA71.4070908@ericsson.com.au> Date: Fri, 24 Aug 2001 07:47:29 +0200 From: Brian Williams User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en-us MIME-Version: 1.0 To: Louis-Nicolas Hamer CC: "'Wijnen, Bert (Bert)'" , "'rap@ops.ietf.org'" Subject: Re: COPS for UMTS References: <9FBD322B7824D511B36900508BF93C9CA5B6B3@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Louis-Nicolas Hamer wrote: > Bert, > But I think the general agreement is that COPS-PR may be used for > pre-provisioning of general policies > > and something else is needed on a per flow basis for admission control. 3G.PP is only specifying COPS usage for an admission control function for service based control. It is not specifying COPS for any other provisioning, (vendors can use whatever provisioning tools they wish for IP services). /brian > > > > Hope this clarifies, > > *Louis-Nicolas Hamer* > > -----Original Message----- > *From:* Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > *Sent:* Monday, August 20, 2001 3:34 PM > *To:* Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Jaseemuddin, Muhammad > [WDLN2:AN33:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org > *Subject:* RE: COPS for UMTS > > I have seen that document. From that, it is not clear to me if > > - Your are gonna do just COPS, which I think means no PIB > > - You are also gonna do COPS-PR, which I think means a PIB > > > > There is talk about using both RSVP and Diffserv for end-to-end QoS > > so when I see Diffserv, then I suspect COPS-PR, but that is not clear. > > > > Also... I thought that there was no final decision yet that COPS was > > going to be the interface... the doc has not yet been approved, has it? > > Sorry for not understanding the details of the process in 3GPP. > > Bert > From owner-rap@ops.ietf.org Thu Aug 23 18:41:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03277 for ; Thu, 23 Aug 2001 18:41:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15a38x-000JZK-00 for rap-data@psg.com; Thu, 23 Aug 2001 15:40:07 -0700 Received: from [204.92.244.243] (helo=kanatamail.unispherenetworks.ca) by psg.com with esmtp (Exim 3.33 #1) id 15a38w-000JZD-00 for rap@ops.ietf.org; Thu, 23 Aug 2001 15:40:06 -0700 Received: by kanatamail.kanata.unispherenetworks.ca with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 18:40:05 -0400 Message-ID: <490717515EE6D41187A60003470D71361BB7A7@kanatamail.kanata.unispherenetworks.ca> From: "Bokaemper, Martin" To: "'Durham, David'" Cc: rap@ops.ietf.org Subject: RE: Incremental state updates from PEP -> PDP in COPS-PR ? Date: Thu, 23 Aug 2001 18:39:58 -0400 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 David! > [...] The general perception has been that the request > state information for the PEP->PDP is relatively small > compared to the configuration decision information from > the PDP->PEP and changes less frequently. [...] > > Now, if these assumptions prove not to be true in some cases, > there are a number of ways to deal with it. I definitely think that this issue needs to be addressed, since - as far as I can see - a significant number of cases violate that assumption, including the framework-pib for diffserv. > 1. Use Reports to convey the most dynamic information: > Ie. Accounting information, ifindex up and down, etc. > Reports do convey incremental updates in all PIBs. Accounting RPTs can create/update information but they can not delete a row. With this solution I would prefer to see two additional report-types 'install' and 'delete' corresponding to the DEC commands 'install' and 'delete'. > 2. Use multiple Requests with different handles, > reducing the amount of info per Request. [...] This is the way COPS-RSVP handles 'large active state'. My understanding of handles is, that they imply independent object spaces. How could objects be shared between different handles? Sharing common objects seems to be one of the main attractions of PIBs and COPS-PR and is an important part of the diffserv PIB. One of the solutions you mentioned IMHO needs to get into the framework-PIB - or would COPS-PR itself be more appropriate? Which option would be the best for this case? ciao, Martin. -- From owner-rap@ops.ietf.org Fri Aug 24 09:01:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04008 for ; Fri, 24 Aug 2001 09:01:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15aGah-0005Gz-00 for rap-data@psg.com; Fri, 24 Aug 2001 06:01:39 -0700 Received: from motgate.mot.com ([129.188.136.100]) by psg.com with esmtp (Exim 3.33 #1) id 15aGag-0005Gh-00 for rap@ops.ietf.org; Fri, 24 Aug 2001 06:01:38 -0700 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA00106 for ; Fri, 24 Aug 2001 06:01:37 -0700 (MST)] Received: [from zgr01exm01.corp.mot.com (zgr01exm01.corp.mot.com [10.162.168.200]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA22443 for ; Fri, 24 Aug 2001 06:01:36 -0700 (MST)] Received: by zgr01exm01.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 16:01:34 +0300 Message-ID: <332B652C3E8ED411A4EA00B0D049C44C5F9700@zgr01exm01.corp.mot.com> From: Salkintzis Apostolis-Y1026C To: "'Brian Williams'" , Louis-Nicolas Hamer Cc: "'rap@ops.ietf.org'" Subject: RE: COPS for UMTS Date: Fri, 24 Aug 2001 16:01:33 +0300 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 My understanding aligns with Brian's statement below. The Go interface, as specified in 23.207, is used for "service-based local policy and QoS inter-working". Nothing is mentioned about provisioning. In addition, 23.207 mentions that "Additional UMTS-specific information elements must be included in COPS messages to support the policy and QoS inter-working functions identified in Section 5.3.1. Consistent with the COPS framework, the Go interface is identified by a "client type" allocated for a UMTS COPS client (GGSN)." Therefore, it is implied that a new COPS client is expected to be used across Go interface. Regards, Apostolis --- -----Original Message----- From: Brian Williams [mailto:brian.williams@ericsson.com.au] Sent: Friday, August 24, 2001 8:47 AM To: Louis-Nicolas Hamer Cc: 'Wijnen, Bert (Bert)'; 'rap@ops.ietf.org' Subject: Re: COPS for UMTS Louis-Nicolas Hamer wrote: > Bert, > But I think the general agreement is that COPS-PR may be used for > pre-provisioning of general policies > > and something else is needed on a per flow basis for admission control. 3G.PP is only specifying COPS usage for an admission control function for service based control. It is not specifying COPS for any other provisioning, (vendors can use whatever provisioning tools they wish for IP services). /brian > > > > Hope this clarifies, > > *Louis-Nicolas Hamer* > > -----Original Message----- > *From:* Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > *Sent:* Monday, August 20, 2001 3:34 PM > *To:* Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Jaseemuddin, Muhammad > [WDLN2:AN33:EXCH]; 'Salkintzis Apostolis-Y1026C'; rap@ops.ietf.org > *Subject:* RE: COPS for UMTS > > I have seen that document. From that, it is not clear to me if > > - Your are gonna do just COPS, which I think means no PIB > > - You are also gonna do COPS-PR, which I think means a PIB > > > > There is talk about using both RSVP and Diffserv for end-to-end QoS > > so when I see Diffserv, then I suspect COPS-PR, but that is not clear. > > > > Also... I thought that there was no final decision yet that COPS was > > going to be the interface... the doc has not yet been approved, has it? > > Sorry for not understanding the details of the process in 3GPP. > > Bert > From owner-rap@ops.ietf.org Wed Aug 29 12:09:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02224 for ; Wed, 29 Aug 2001 12:09:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15c7u5-000K6p-00 for rap-data@psg.com; Wed, 29 Aug 2001 09:09:21 -0700 Received: from h144s128a249n47.user.nortelnetworks.com ([47.249.128.144] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15c7u4-000K6i-00 for rap@ops.ietf.org; Wed, 29 Aug 2001 09:09:21 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7TG78p05848 for ; Wed, 29 Aug 2001 12:07:08 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 29 Aug 2001 12:06:36 -0400 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 RSACFZXR; Wed, 29 Aug 2001 12:06:30 -0400 Received: from tweedy.NortelNetworks.com (dhcp229-108.engeast.baynetworks.com [192.32.229.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87RYZN; Wed, 29 Aug 2001 12:06:28 -0400 Message-Id: <5.0.0.25.0.20010829115636.02aa8b80@zbl6c000.corpeast.baynetworks.com> X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 29 Aug 2001 12:06:09 -0400 To: rap@ops.ietf.org From: "Kwok-Ho Chan" Subject: 51st IETF @ London RAP WG Minutes + Presentations Cc: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk Hi All: The RAP WG Meeting Minutes for the 51st IETF at London are available at the following FTP site: ftp://standards.nortelnetworks.com/rap/51st_IETF/IETF%20%2351%20RAP%20WG%20MINUTES.txt The 12 presentations are also available in: ftp://standards.nortelnetworks.com/rap/51st_IETF/ -- Kwok Ho Chan -- From owner-rap@ops.ietf.org Thu Aug 30 19:41:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00413 for ; Thu, 30 Aug 2001 19:41:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cbPf-0007Vg-00 for rap-data@psg.com; Thu, 30 Aug 2001 16:39:55 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15cbPe-0007VY-00 for rap@ops.ietf.org; Thu, 30 Aug 2001 16:39:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15cbPd-00010r-00 for rap@ops.ietf.org; Fri, 31 Aug 2001 07:39:53 +0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.33 #1) id 15cb4Z-0006qv-00 for rap@ops.ietf.org; Thu, 30 Aug 2001 16:18:07 -0700 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id f7UNI3Q25174; Thu, 30 Aug 2001 16:18:03 -0700 (PDT) Message-Id: <200108302318.f7UNI3Q25174@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3159 on SPPI Cc: rfc-ed@ISI.EDU, rap@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 30 Aug 2001 16:18:03 -0700 From: RFC Editor Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3159 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 Status: Standards Track Date: August 2001 Mailbox: kzm@cisco.com, mfine@cisco.com, jseligso@nortelnetworks.com, khchan@nortelnetworks.com, scott.hahn@intel.com, ravi.sahita@intel.com, andrew@allegronetworks.com, franr@pfn.com Pages: 40 Characters: 78621 Obsoletes/Updates/SeeAlso: None I-D Tag: draft-ietf-rap-sppi-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3159.txt This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. RFC 2748 defines the COPS protocol, and RFC 2749 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 RFC 3084. 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. This document is a product of the Resource Allocation Protocol Working Group of the 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: <010830161118.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3159 --OtherAccess Content-Type: Message/External-body; name="rfc3159.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010830161118.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Aug 31 09:28:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04577 for ; Fri, 31 Aug 2001 09:28:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15coM0-000NZy-00 for rap-data@psg.com; Fri, 31 Aug 2001 06:29:00 -0700 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.33 #1) id 15coLz-000NZs-00 for rap@ops.ietf.org; Fri, 31 Aug 2001 06:28:59 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7VDSwQ01696 for ; Fri, 31 Aug 2001 09:28:58 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 31 Aug 2001 15:28:52 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D5630C1@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: rap@ops.ietf.org Subject: RE: RFC 3159 on SPPI Date: Fri, 31 Aug 2001 15:28:50 +0200 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 Great, we finally have the SPPI approved. Special thanks to Ravi, who has been very responsive in a number of iterations we went through with IANA considerations and other smaller fixes. Bert