From owner-rap@ops.ietf.org Fri Nov 2 08:08:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01919 for ; Fri, 2 Nov 2001 08:08:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15zdym-000C7O-00 for rap-data@psg.com; Fri, 02 Nov 2001 05:03:24 -0800 Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr) by psg.com with esmtp (Exim 3.33 #1) id 15zdyl-000C7H-00 for rap@ops.ietf.org; Fri, 02 Nov 2001 05:03:23 -0800 Received: from yahoo.com (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id BEBA8189D for ; Fri, 2 Nov 2001 14:03:21 +0100 (MET) Message-ID: <3BE29B0B.20F7EFC5@yahoo.com> Date: Fri, 02 Nov 2001 14:09:31 +0100 From: Nguyen Thi Mai Trang Organization: ENST - INFRES X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: extended PIB class Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I would like to know if a PIB class can be extended from a class of another PIB? Thank you very much, Mai Trang ---------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr From owner-rap@ops.ietf.org Fri Nov 2 10:44: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 KAA08246 for ; Fri, 2 Nov 2001 10:44:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15zgQj-000FQj-00 for rap-data@psg.com; Fri, 02 Nov 2001 07:40:25 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by psg.com with esmtp (Exim 3.33 #1) id 15zgQj-000FQa-00 for rap@ops.ietf.org; Fri, 02 Nov 2001 07:40:25 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fA2FdiS18779 for ; Fri, 2 Nov 2001 10:39:44 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Fri, 2 Nov 2001 10:39:07 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 40YK3X53; Fri, 2 Nov 2001 10:38:28 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FBM5N; Fri, 2 Nov 2001 10:38:28 -0500 Message-Id: <5.0.0.25.0.20011102103236.02a3d630@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 02 Nov 2001 10:37:24 -0500 To: Nguyen Thi Mai Trang From: "Kwok-Ho Chan" Subject: Re: extended PIB class Cc: rap@ops.ietf.org In-Reply-To: <3BE29B0B.20F7EFC5@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk Yes, you need to indicate the source of the base class in the IMPORT clause. -- Kwok Ho Chan, Nortel, ATI -- At 02:09 PM 11/2/01 +0100, Nguyen Thi Mai Trang wrote: >Hello, > >I would like to know if a PIB class can be extended from a class of >another PIB? > >Thank you very much, >Mai Trang >---------------------------------------------------- >Nguyen Thi Mai Trang >Ecole Nationale Superieure des Telecommunications >Dept. INFRES - Bur. C234-4 >46 Rue Barrault - 75013 Paris >Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 >email : trnguyen@enst.fr From owner-rap@ops.ietf.org Mon Nov 12 11:56:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11087 for ; Mon, 12 Nov 2001 11:56:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163KLt-0007QP-00 for rap-data@psg.com; Mon, 12 Nov 2001 08:54:29 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by psg.com with esmtp (Exim 3.33 #1) id 163KLs-0007QJ-00 for rap@ops.ietf.org; Mon, 12 Nov 2001 08:54:28 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fACGrmS29520 for ; Mon, 12 Nov 2001 11:53:48 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 12 Nov 2001 11:54:06 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WNFR5211; Mon, 12 Nov 2001 11:53:17 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FBYHS; Mon, 12 Nov 2001 11:53:15 -0500 Message-Id: <5.0.0.25.0.20011112115106.040e41b0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 12 Nov 2001 11:52:11 -0500 To: rap@ops.ietf.org From: "Kwok-Ho Chan" Subject: Fwd: [Diffserv] WG Last Call for draft-ietf-diffserv-pib-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk FYI >Date: Mon, 12 Nov 2001 17:24:19 +0100 >From: Brian E Carpenter >Organization: IBM >X-Mailer: Mozilla 4.76 [en] (Win98; U) >X-Accept-Language: en,fr >To: Diff Serv >Subject: [Diffserv] WG Last Call for draft-ietf-diffserv-pib-05.txt >Sender: diffserv-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: Diffserv Discussion List >X-BeenThere: diffserv@ietf.org >X-SMTP-HELO: optimus.ietf.org >X-SMTP-MAIL-FROM: diffserv-admin@ietf.org >X-SMTP-RCPT-TO: >ksundell@nortelnetworks.com,kris@nortelnetworks.com,khchan@nortelnetworks.com,jykchan@nortelnetworks.com,jseligso@nortelnetworks.com,jnorman@nortelnetworks.com,jaseem@nortelnetworks.com,helbakou@nortelnetworks.com,frankerm@nortelnetworks.com,fiffi@nortelnetworks.com,elwynd@nortelnetworks.com,dturcanu@nortelnetworks.com,dnorton@nortelnetworks.com,dbarbara@nortelnetworks.com,biswaroo@nortelnetworks.com,babiarz@nortelnetworks.com,abel@nortelnetworks.com >X-SMTP-PEER-INFO: ietf.org [132.151.1.19] >X-Orig: > >It is proposed to forward draft-ietf-diffserv-pib-05.txt >to the IESG for publication as a Proposed Standard. > >Any final working group comments should be sent >to this list by November 26, 2001. > >Regards > Brian Carpenter > Kathie Nichols > diffserv WG co-chairs > > >-------- Original Message -------- >Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt >Date: Mon, 12 Nov 2001 07:03:18 -0500 >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >To: IETF-Announce: ; >CC: diffserv@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Differentiated Services Working Group of >the IETF. > > Title : Differentiated Services Quality of Service Policy > Information Base > Author(s) : M. Fine, K. McCloghrie et al. > Filename : draft-ietf-diffserv-pib-05.txt > Pages : 95 > Date : 09-Nov-01 > >[SPPI] describes a structure for specifying policy information that >can then be transmitted to a network device for the purpose of >configuring policy at that device. The model underlying this >structure is one of well-defined policy rule classes and instances >of these classes residing in a virtual information store called the >Policy Information Base (PIB). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt > >Content-Type: text/plain >Content-ID: <20011109134428.I-D@ietf.org> From owner-rap@ops.ietf.org Wed Nov 14 11:38:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02191 for ; Wed, 14 Nov 2001 11:38:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1642z4-000D7p-00 for rap-data@psg.com; Wed, 14 Nov 2001 08:33:54 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by psg.com with esmtp (Exim 3.33 #1) id 1642z3-000D7j-00 for rap@ops.ietf.org; Wed, 14 Nov 2001 08:33:53 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAEGXCS05288 for ; Wed, 14 Nov 2001 11:33:12 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Wed, 14 Nov 2001 11:33:35 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WNFSBKQN; Wed, 14 Nov 2001 11:32:44 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FB6T6; Wed, 14 Nov 2001 11:32:42 -0500 Message-Id: <5.0.0.25.0.20011114112635.02b3adb0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 14 Nov 2001 11:31:37 -0500 To: rap@ops.ietf.org From: "Kwok-Ho Chan" Subject: draft-ietf-rap-frameworkpib-06.txt submitted 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 The Framework PIB has been submitted to IETF. Prior to IETF Announcement of its availability, it can be retrieved at: ftp://standards.nortelnetworks.com/rap/52nd_IETF/draft-ietf-rap-frameworkpib-06.txt Happy reading and please post any comments on the RAP mailing list. -- Kwok -- From owner-rap@ops.ietf.org Wed Nov 14 11:48:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03019 for ; Wed, 14 Nov 2001 11:47:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16439C-000Ddk-00 for rap-data@psg.com; Wed, 14 Nov 2001 08:44:22 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by psg.com with esmtp (Exim 3.33 #1) id 16439B-000Dd3-00 for rap@ops.ietf.org; Wed, 14 Nov 2001 08:44:21 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAEGhcS06749 for ; Wed, 14 Nov 2001 11:43:38 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 14 Nov 2001 11:43:56 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WNFSBLZX; Wed, 14 Nov 2001 11:43:04 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FB646; Wed, 14 Nov 2001 11:43:03 -0500 Message-Id: <5.0.0.25.0.20011114112725.024418c0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 14 Nov 2001 11:41:58 -0500 To: rap@ops.ietf.org From: "Kwok-Ho Chan" Subject: draft-hamer-rap-cops-umts-go-00.txt submitted 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 A new draft for using COPS-PR for UMTS has been submitted to IETF. Prior to IETF Announcement of its availability, it can be retrieved at: ftp://standards.nortelnetworks.com/rap/52nd_IETF/draft-hamer-rap-cops-umts-go-00.txt Happy reading and please send any comments to the authors and on the RAP list as appropriate. -- Kwok -- From owner-rap@ops.ietf.org Thu Nov 15 07:08:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18845 for ; Thu, 15 Nov 2001 07:08:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164LIT-000FR0-00 for rap-data@psg.com; Thu, 15 Nov 2001 04:07:09 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 164LIS-000FQt-00 for rap@ops.ietf.org; Thu, 15 Nov 2001 04:07:08 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18812; Thu, 15 Nov 2001 07:07:05 -0500 (EST) Message-Id: <200111151207.HAA18812@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-frameworkpib-06.txt Date: Thu, 15 Nov 2001 07:07:05 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework Policy Information Base Author(s) : M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-frameworkpib-06.txt Pages : 59 Date : 14-Nov-01 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined provisioning classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-frameworkpib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-frameworkpib-06.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: <20011114151202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-frameworkpib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-frameworkpib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011114151202.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Nov 15 10:10:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27060 for ; Thu, 15 Nov 2001 10:10:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164O5c-000NKr-00 for rap-data@psg.com; Thu, 15 Nov 2001 07:06:04 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 164O5b-000NKj-00 for rap@ops.ietf.org; Thu, 15 Nov 2001 07:06:04 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 15 Nov 2001 15:08:16 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id OAA17288 for ; Thu, 15 Nov 2001 14:59:20 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 15:00:29 -0000 Message-ID: From: "Da Silva, Pedro" To: rap@ops.ietf.org Subject: frameworkpib-06 comments Date: Thu, 15 Nov 2001 15:00:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk The scope of the document is to 'define a set of PRCs and textual conventions that are common to all clients...'. Having a table that determines a target via the ifIndex limits the applicability of the framework pib across client types. Shouldn't the frwkIfRoleComboTable table be more generic? The frwk PIB could define PRCs that constitute a base on which each client type is able to specify its particular target, be it an IfIndex+direction on a router or slotX on a toaster. Pedro -- This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated. From owner-rap@ops.ietf.org Thu Nov 15 12:08:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04547 for ; Thu, 15 Nov 2001 12:08:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164Psf-0002XL-00 for rap-data@psg.com; Thu, 15 Nov 2001 09:00:49 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 164Psd-0002XD-00 for rap@ops.ietf.org; Thu, 15 Nov 2001 09:00:48 -0800 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id RAA03473 for ; Thu, 15 Nov 2001 17:00:46 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111509000020651 ; Thu, 15 Nov 2001 09:00:00 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 09:01:04 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3CEA1D28@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org Cc: "Bert Wijnen (Bert) (E-mail)" , "Mark L. Stevens", "'Keith McCloghrie'" , "Hahn, Scott" , "'khchan@nortelnetworks.com'", "'jseligso@nortelnetworks.com'", "'franr@pfn.com'" , "'Andrew Smith'" , "Sahita, Ravi", michael@finefolks.org Subject: WG Last Call for draft-ietf-rap-frameworkpib-06.txt Date: Thu, 15 Nov 2001 09:00:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Working Group last-call to commence on http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.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 November 30, 2001. Regards Scott Hahn Mark Stevens RAP WG co-chairs Note: This version of Framework PIB (06) is developed with and referenced by DiffServ PIB-05 draft currently in last call in the diffserv WG. From owner-rap@ops.ietf.org Thu Nov 15 19:11:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28966 for ; Thu, 15 Nov 2001 19:10:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164WSN-000BRq-00 for rap-data@psg.com; Thu, 15 Nov 2001 16:02:07 -0800 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 164WSM-000BRk-00 for rap@ops.ietf.org; Thu, 15 Nov 2001 16:02:06 -0800 Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id AAA05752 for ; Fri, 16 Nov 2001 00:02:05 GMT Received: from fmsmsx27.fm.intel.com ([132.233.42.27]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111516013906801 ; Thu, 15 Nov 2001 16:01:39 -0800 Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 16:03:09 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F157A68@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Da Silva, Pedro'" , rap@ops.ietf.org Subject: RE: frameworkpib-06 comments Date: Thu, 15 Nov 2001 16:01:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Pedro, The frwkIfRoleCombo table is only used to associate ifIndices on network devices with role-combinations. The actual policy targetting table would be in a domain-specific PIB (for example the qosDataPathTable in the diffserv PIB). Note that in a hypothetical toaster PIB you can always define your own targetting table that contains SlotX, role-combination, and you would'nt use the ifRoleComboTable since in that case you would'nt need that association. Ravi > -----Original Message----- > From: Da Silva, Pedro [mailto:pdasilva@orchestream.com] > Sent: Thursday, November 15, 2001 7:00 AM > To: rap@ops.ietf.org > Subject: frameworkpib-06 comments > > > The scope of the document is to 'define a set of PRCs and textual > conventions that are common to all clients...'. Having a table that > determines a target via the ifIndex limits the applicability of the > framework pib across client types. > > Shouldn't the frwkIfRoleComboTable table be more generic? > The frwk PIB could > define PRCs that constitute a base on which each client type > is able to > specify its particular target, be it an IfIndex+direction on > a router or > slotX on a toaster. > > Pedro > > > > > -- > This communication contains confidential information > intended solely for the use of the individual/s and/or > entity or entities to whom it was intended to be addressed. > If you are not the intended recipient, be aware that any > disclosure, copying, distribution, or use of the contents of > this transmission is prohibited. If you have received this > communication in error, please contact the sender > immediately, delete this communication from your system, and > do not disclose its contents to any third party, or use its > contents. Any opinions expressed are solely those of the > author and do not necessarily represent those of Orchestream > Ltd or its group of companies unless otherwise specifically stated. > From owner-rap@ops.ietf.org Fri Nov 16 06:57:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26747 for ; Fri, 16 Nov 2001 06:57:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164hbB-000PeQ-00 for rap-data@psg.com; Fri, 16 Nov 2001 03:55:57 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 164hbA-000PeK-00 for rap@ops.ietf.org; Fri, 16 Nov 2001 03:55:56 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26543; Fri, 16 Nov 2001 06:55:53 -0500 (EST) Message-Id: <200111161155.GAA26543@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-hamer-rap-cops-umts-go-00.txt Date: Fri, 16 Nov 2001 06:55:53 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : COPS-PR for outsourcing in UMTS: UMTS Go PIB Author(s) : L. Hamer et al. Filename : draft-hamer-rap-cops-umts-go-00.txt Pages : 28 Date : 15-Nov-01 This document describes usage directives for supporting COPS outsourcing policy services in the UMTS environment. Through the use of the UMTS Go PIB, defined in this document, COPS-PR is used for outsourcing over the Go interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamer-rap-cops-umts-go-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hamer-rap-cops-umts-go-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hamer-rap-cops-umts-go-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011115154021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hamer-rap-cops-umts-go-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hamer-rap-cops-umts-go-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011115154021.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Nov 16 06:59: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 GAA27220 for ; Fri, 16 Nov 2001 06:59:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164heM-000PiH-00 for rap-data@psg.com; Fri, 16 Nov 2001 03:59:14 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 164heL-000PiB-00 for rap@ops.ietf.org; Fri, 16 Nov 2001 03:59:13 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27198; Fri, 16 Nov 2001 06:59:10 -0500 (EST) Message-Id: <200111161159.GAA27198@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-frameworkpib-06.txt Date: Fri, 16 Nov 2001 06:59:10 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework Policy Information Base Author(s) : M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-frameworkpib-06.txt Pages : 59 Date : 14-Nov-01 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined provisioning classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-frameworkpib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-frameworkpib-06.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: <20011114151202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-frameworkpib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-frameworkpib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011114151202.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Nov 16 09:54:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03912 for ; Fri, 16 Nov 2001 09:54:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164kHu-0003pg-00 for rap-data@psg.com; Fri, 16 Nov 2001 06:48:14 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 164kHt-0003pX-00 for rap@ops.ietf.org; Fri, 16 Nov 2001 06:48:13 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 16 Nov 2001 14:50:27 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id OAA11885 for ; Fri, 16 Nov 2001 14:41:28 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Nov 2001 14:42:39 -0000 Message-ID: From: "Da Silva, Pedro" To: "'rap@ops.ietf.org'" Subject: RE: frameworkpib-06 comments [sic] Date: Fri, 16 Nov 2001 14:42:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk The frwkIfRoleCombo table is actually used to associate indices with role-combos and caps name. But that's beside the point. You're saying that for devices (e.g. Junipers which use names to identify its interfaces) that do not use IfIndices then one would not use this table to configure them. This is an argument against having such a table at framework level. I'm saying this PIB is supposed to be the common ground. I'm proposing that the frwkIfRoleCombo table have an index but not in the sense of a MIB IfIndex (as the doc says in pg 3 'The SNMP experience with ifIndex has proved this to be a difficult task'). Why not a Prid to a generic target? Then in the domain-specific PIB you define a table that determines what those prids actually represent. So at framework level: FrwkTargetRoleComboEntry ::= SEQUENCE { frwkTargetRoleComboPrid InstanceId, frwkTargetRoleComboTarget Prid, frwkTargetRoleComboRoles RoleCombination, frwkTargetRoleComboCapSetName SnmpAdminString } frwkTargetRoleComboTarget OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "The complete PRC OID and instance identifier specifying the target PRC instance." In the domain specific pib, for instance DiffServ PIB, strictly following the Informal model: qosTargetTable OBJECT-TYPE SYNTAX SEQUENCE OF QosTargetEntry PIB-ACCESS notify STATUS current DESCRIPTION "This table specifies targets on the device" qosTargetEntry OBJECT-TYPE SYNTAX QosTargetEntry STATUS current DESCRIPTION "An instance of this class describes a target on the device." QosTargetEntry ::= SEQUENCE { qosTargetPrid InstanceId, qosTargetName Unsigned32, qosTargetDirection IfDirection } qosTargetPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies a instance of the class." qosTargetName OBJECT-TYPE SYNTAX SnmpAdminString STATUS current DESCRIPTION "The name or label for the physical interface (e.g. 'FastEthernet3/0')." qosTargetDirection OBJECT-TYPE SYNTAX IfDirection STATUS current DESCRIPTION "Specifies the target direction" The focus here is on the framework pib, so the qosTargetTable is a rough example. Pedro -----Original Message----- From: Sahita, Ravi [mailto:ravi.sahita@intel.com] Sent: Friday, November 16, 2001 12:02 AM To: 'Da Silva, Pedro'; rap@ops.ietf.org Subject: RE: frameworkpib-06 comments Pedro, The frwkIfRoleCombo table is only used to associate ifIndices on network devices with role-combinations. The actual policy targetting table would be in a domain-specific PIB (for example the qosDataPathTable in the diffserv PIB). Note that in a hypothetical toaster PIB you can always define your own targetting table that contains SlotX, role-combination, and you would'nt use the ifRoleComboTable since in that case you would'nt need that association. Ravi > -----Original Message----- > From: Da Silva, Pedro [mailto:pdasilva@orchestream.com] > Sent: Thursday, November 15, 2001 7:00 AM > To: rap@ops.ietf.org > Subject: frameworkpib-06 comments > > > The scope of the document is to 'define a set of PRCs and textual > conventions that are common to all clients...'. Having a table that > determines a target via the ifIndex limits the applicability of the > framework pib across client types. > > Shouldn't the frwkIfRoleComboTable table be more generic? > The frwk PIB could > define PRCs that constitute a base on which each client type > is able to > specify its particular target, be it an IfIndex+direction on > a router or > slotX on a toaster. > > Pedro > > > > > -- > This communication contains confidential information > intended solely for the use of the individual/s and/or > entity or entities to whom it was intended to be addressed. > If you are not the intended recipient, be aware that any > disclosure, copying, distribution, or use of the contents of > this transmission is prohibited. If you have received this > communication in error, please contact the sender > immediately, delete this communication from your system, and > do not disclose its contents to any third party, or use its > contents. Any opinions expressed are solely those of the > author and do not necessarily represent those of Orchestream > Ltd or its group of companies unless otherwise specifically stated. > From owner-rap@ops.ietf.org Mon Nov 19 08:33: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 IAA27698 for ; Mon, 19 Nov 2001 08:33:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 165oXY-000BFC-00 for rap-data@psg.com; Mon, 19 Nov 2001 05:32:48 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 165oXX-000BF5-00 for rap@ops.ietf.org; Mon, 19 Nov 2001 05:32:47 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27489; Mon, 19 Nov 2001 08:32:44 -0500 (EST) Message-Id: <200111191332.IAA27489@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-rsvppcc-pib-00.txt Date: Mon, 19 Nov 2001 08:32:44 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : RSVP Policy Control Criteria PIB Author(s) : D. Rawlins et al. Filename : draft-ietf-rap-rsvppcc-pib-00.txt Pages : 32 Date : 16-Nov-01 This draft describes the use of COPS-PR for support of a PDP provisioning a PEP with RSVP policy control criteria and defines a RSVP policy control criteria PIB for this purpose. The RSVPCC-PIB described in the document is provided for definition of policies that are currently defined by the outsourcing model [2749]. It is designed to be scalable and flexible as well as extensible for accommodating future policy criteria A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvppcc-pib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-rsvppcc-pib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-rsvppcc-pib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart 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: <20011116142710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvppcc-pib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvppcc-pib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142710.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Wed Nov 21 08:38:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13860 for ; Wed, 21 Nov 2001 08:38:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166XWT-000NIl-00 for rap-data@psg.com; Wed, 21 Nov 2001 05:34:41 -0800 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.33 #1) id 166XWR-000NIf-00 for rap@ops.ietf.org; Wed, 21 Nov 2001 05:34:40 -0800 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id fALDY6w06033 for ; Wed, 21 Nov 2001 19:04:06 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GN5KDI00.852 for ; Wed, 21 Nov 2001 19:04:30 +0530 Message-ID: <3BFB81E0.6D18ED77@wipro.com> Date: Wed, 21 Nov 2001 15:58:48 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: IETF RAP WG Subject: PIB Incarnation Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d8406512-de52-11d5-84a5-0000e2293f7c" Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-d8406512-de52-11d5-84a5-0000e2293f7c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is a query with reference to ID on framework PIB. From the document, I could not understand how PDP & PEP exchange PIB incarnation table details. Specifically, What can be the name of "frwkPibIncarnationName" attribute. Is it the responsibility of PDP to fill this attribute? For your reference, structure of FrwkPibIncarnationEntry is given below. FrwkPibIncarnationEntry ::= SEQUENCE { frwkPibIncarnationPrid InstanceId, frwkPibIncarnationName SnmpAdminString, frwkPibIncarnationId OCTET STRING, frwkPibIncarnationLongevity Unsigned32, frwkPibIncarnationTtl Unsigned32, frwkPibIncarnationActive TruthValue } Thanks & Regards Krishna ------=_NextPartTM-000-d8406512-de52-11d5-84a5-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com ------=_NextPartTM-000-d8406512-de52-11d5-84a5-0000e2293f7c-- From owner-rap@ops.ietf.org Wed Nov 21 09:51: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 JAA17746 for ; Wed, 21 Nov 2001 09:51:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166YiQ-0000EH-00 for rap-data@psg.com; Wed, 21 Nov 2001 06:51:06 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 166YiP-0000Dx-00 for rap@ops.ietf.org; Wed, 21 Nov 2001 06:51:06 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 21 Nov 2001 14:53:21 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id KAA20510 for ; Wed, 21 Nov 2001 10:53:09 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 14:45:29 -0000 Message-ID: From: "Da Silva, Pedro" To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Date: Wed, 21 Nov 2001 14:45:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Krishna, The frwkPibIncarnationName identifies the PDP that provided the PIB instance refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or 'Manager X' and/or an ip address or whatever, in your system, *uniquely* identifies each PDP. It is the responsibility of the PDP to populate the entry, it's effectively part of the decision. IHTH, Pedro -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: Wednesday, November 21, 2001 10:29 AM To: IETF RAP WG Subject: PIB Incarnation Hi, This is a query with reference to ID on framework PIB. From the document, I could not understand how PDP & PEP exchange PIB incarnation table details. Specifically, What can be the name of "frwkPibIncarnationName" attribute. Is it the responsibility of PDP to fill this attribute? For your reference, structure of FrwkPibIncarnationEntry is given below. FrwkPibIncarnationEntry ::= SEQUENCE { frwkPibIncarnationPrid InstanceId, frwkPibIncarnationName SnmpAdminString, frwkPibIncarnationId OCTET STRING, frwkPibIncarnationLongevity Unsigned32, frwkPibIncarnationTtl Unsigned32, frwkPibIncarnationActive TruthValue } Thanks & Regards Krishna From owner-rap@ops.ietf.org Wed Nov 21 14:25: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 OAA01149 for ; Wed, 21 Nov 2001 14:25:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166cym-000A2g-00 for rap-data@psg.com; Wed, 21 Nov 2001 11:24:16 -0800 Received: from [204.92.244.243] (helo=kanatamail.unispherenetworks.ca) by psg.com with esmtp (Exim 3.33 #1) id 166cym-000A2T-00 for rap@ops.ietf.org; Wed, 21 Nov 2001 11:24:16 -0800 Received: by kanatamail.kanata.unispherenetworks.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 14:24:15 -0500 Message-ID: <490717515EE6D41187A60003470D71361BB989@kanatamail.kanata.unispherenetworks.ca> From: "Bokaemper, Martin" To: "'rap@ops.ietf.org'" Subject: frameworkpib-06 - frwkErrorPrc / Instance Date: Wed, 21 Nov 2001 14:24:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hello! I'm extremely happy with the new mechanisms in the frameworkpib - incremental request state updates, multiple active contexts, references between context - great! I have one small question regarding the FrwkErrorEntry Prc: Why is the instance causing the error reported in two sepeparate fields: frwkErrorPrc PrcIdentifier, frwkErrorInstance InstanceId Unless there is a benefit to the split, I would suggest to replace these two fields with one: frwkErrorInstance Prid Martin. -- From owner-rap@ops.ietf.org Wed Nov 21 16:05:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05888 for ; Wed, 21 Nov 2001 16:05:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166eXy-000FTO-00 for rap-data@psg.com; Wed, 21 Nov 2001 13:04:42 -0800 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.33 #1) id 166eXw-000FTC-00 for rap@ops.ietf.org; Wed, 21 Nov 2001 13:04:40 -0800 Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id VAA15119 for ; Wed, 21 Nov 2001 21:04:36 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001112113055106309 ; Wed, 21 Nov 2001 13:05:51 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 13:04:35 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F01D02527@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Bokaemper, Martin'" , "'rap@ops.ietf.org'" Subject: RE: frameworkpib-06 - frwkErrorPrc / Instance Date: Wed, 21 Nov 2001 13:04:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk This was done so that the frwkError PRC could be used to specify error conditions that apply not only to PRC instances but to PRCs also. (for example COPS-PR error code unknownPrc(9)) Ravi > -----Original Message----- > From: Bokaemper, Martin [mailto:MBokaemper@unispherenetworks.com] > Sent: Wednesday, November 21, 2001 11:24 AM > To: 'rap@ops.ietf.org' > Subject: frameworkpib-06 - frwkErrorPrc / Instance > > > Hello! > > I'm extremely happy with the new mechanisms in the > frameworkpib - incremental request state updates, > multiple active contexts, references between context - > great! > > I have one small question regarding the FrwkErrorEntry > Prc: Why is the instance causing the error reported in > two sepeparate fields: > frwkErrorPrc PrcIdentifier, > frwkErrorInstance InstanceId > Unless there is a benefit to the split, I would suggest > to replace these two fields with one: > frwkErrorInstance Prid > > Martin. > -- > From owner-rap@ops.ietf.org Wed Nov 21 17:06:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10540 for ; Wed, 21 Nov 2001 17:06:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166fU7-000IQO-00 for rap-data@psg.com; Wed, 21 Nov 2001 14:04:47 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by psg.com with esmtp (Exim 3.33 #1) id 166fU6-000IQE-00 for rap@ops.ietf.org; Wed, 21 Nov 2001 14:04:46 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fALM40S15886 for ; Wed, 21 Nov 2001 17:04:00 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 21 Nov 2001 17:04:33 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X2KN1TML; Wed, 21 Nov 2001 17:03:34 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XHZ5TZ5A; Wed, 21 Nov 2001 17:03:34 -0500 Message-Id: <5.0.0.25.0.20011121165404.02808d20@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 21 Nov 2001 17:02:08 -0500 To: rap@ops.ietf.org From: "Kwok-Ho Chan" Subject: New Usage Feedback Drafts Availability 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 New version of the Usage Feedback Framework and Framework PIB drafts have been submitted to Internet-Drafts@ietf.org by Amol Kulkarni. They are available for your reading at: ftp://standards.nortelnetworks.com/rap/52nd_IETF/draft-ietf-rap-feedback-frwk-01.txt and ftp://standards.nortelnetworks.com/rap/52nd_IETF/draft-ietf-rap-feedback-fr-pib-01.txt prior to their availability in the IETF repository. Happy reading and Happy (US)Thanksgiving! -- Kwok Ho Chan -- From owner-rap@ops.ietf.org Wed Nov 21 23:07:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20938 for ; Wed, 21 Nov 2001 23:07:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166l5e-0009yk-00 for rap-data@psg.com; Wed, 21 Nov 2001 20:03:54 -0800 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by psg.com with esmtp (Exim 3.33 #1) id 166l5d-0009yU-00 for rap@ops.ietf.org; Wed, 21 Nov 2001 20:03:53 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 22 Nov 2001 09:46:24 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.4.8.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id fAM43AB01859; Thu, 22 Nov 2001 09:33:11 +0530 From: "Abdul Malick" To: "Da Silva, Pedro" , "IETF RAP WG" Subject: RE: PIB Incarnation [sic] Date: Thu, 22 Nov 2001 09:30:10 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Pedro, But can multiple PDPs manage a PEP at the same time? Also to make a particular incarnation active, i think the PDP only has to make the decision. In this case how is the activation of incarnations co-ordinated among different PDPs given the fact that only one incarnation can be active at the same time. Regards, Malick -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Da Silva, Pedro Sent: Wednesday, 21 November 2001 8:15 PM To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Krishna, The frwkPibIncarnationName identifies the PDP that provided the PIB instance refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or 'Manager X' and/or an ip address or whatever, in your system, *uniquely* identifies each PDP. It is the responsibility of the PDP to populate the entry, it's effectively part of the decision. IHTH, Pedro -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: Wednesday, November 21, 2001 10:29 AM To: IETF RAP WG Subject: PIB Incarnation Hi, This is a query with reference to ID on framework PIB. >From the document, I could not understand how PDP & PEP exchange PIB incarnation table details. Specifically, What can be the name of "frwkPibIncarnationName" attribute. Is it the responsibility of PDP to fill this attribute? For your reference, structure of FrwkPibIncarnationEntry is given below. FrwkPibIncarnationEntry ::= SEQUENCE frwkPibIncarnationPrid InstanceId, frwkPibIncarnationName SnmpAdminString, frwkPibIncarnationId OCTET STRING, frwkPibIncarnationLongevity Unsigned32, frwkPibIncarnationTtl Unsigned32, frwkPibIncarnationActive TruthValue } Thanks & Regards Krishna From owner-rap@ops.ietf.org Thu Nov 22 01:37: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 BAA26987 for ; Thu, 22 Nov 2001 01:37:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166nTH-000HKC-00 for rap-data@psg.com; Wed, 21 Nov 2001 22:36:27 -0800 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.33 #1) id 166nTF-000HJm-00 for rap@ops.ietf.org; Wed, 21 Nov 2001 22:36:26 -0800 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id fAM6Zqw23520 for ; Thu, 22 Nov 2001 12:05:52 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GN6VOE00.QID; Thu, 22 Nov 2001 12:06:15 +0530 Message-ID: <3BFC7158.A4818DC2@wipro.com> Date: Thu, 22 Nov 2001 09:00:32 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: "Da Silva Pedro" CC: Abdul Malick , rap@ops.ietf.org Subject: Re: PIB Incarnation [sic] References: Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-25dc44f5-de94-11d5-84a5-0000e2293f7c" Sender: owner-rap@ops.ietf.org Precedence: bulk ------=_NextPartTM-000-25dc44f5-de94-11d5-84a5-0000e2293f7c Content-Type: multipart/alternative; boundary="------------9266380FA775D703C48222BC" --------------9266380FA775D703C48222BC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pedro, It is now clear for me that it is PDP's responsibility to set frwkPibIncarnationName. This will work well incase of single PDP. But, how can PEP get managed by multiple PDP's and still maintain uniqueness of frwkPibIncarnationName + frwkPibIncarnationId. To summarize: 1. Is there an assumption that, multiple PDPs must belong to a single administrative domain? In such case there is no conflict in maintaining unique PDP names. 2. Is it true that, At any point of time a PEP gets managed by one and only one PDP (For a specific client type)(Even if multiple PDPs are under single administrative domain). Thanks Krishna "Da Silva, Pedro" wrote: > Krishna, > > The frwkPibIncarnationName identifies the PDP that provided the PIB instance > refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or > 'Manager X' and/or an ip address or whatever, in your system, *uniquely* > identifies each PDP. > It is the responsibility of the PDP to populate the entry, it's effectively > part of the decision. > > IHTH, > Pedro > > -----Original Message----- > From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] > Sent: Wednesday, November 21, 2001 10:29 AM > To: IETF RAP WG > Subject: PIB Incarnation > > Hi, > This is a query with reference to ID on framework PIB. > >From the document, I could not understand how PDP & PEP > exchange PIB incarnation table details. > > Specifically, What can be the name of "frwkPibIncarnationName" > attribute. Is it the responsibility of PDP to fill this > attribute? > > For your reference, structure of FrwkPibIncarnationEntry > is given below. > > FrwkPibIncarnationEntry ::= SEQUENCE { > frwkPibIncarnationPrid InstanceId, > frwkPibIncarnationName SnmpAdminString, > frwkPibIncarnationId OCTET STRING, > frwkPibIncarnationLongevity Unsigned32, > frwkPibIncarnationTtl Unsigned32, > frwkPibIncarnationActive TruthValue > } > > Thanks & Regards > Krishna --------------9266380FA775D703C48222BC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pedro,
        It is now clear for me that it is PDP's responsibility
to set frwkPibIncarnationName. This will work well incase of
single PDP. But, how can PEP get managed by multiple PDP's and
still maintain uniqueness of frwkPibIncarnationName + frwkPibIncarnationId.

To summarize:
1. Is there an assumption that, multiple PDPs must belong to a single
administrative domain?
In such case there is no conflict in maintaining unique PDP names.
 
2. Is it true that, At any point of time a PEP gets managed by one and only
   one PDP (For a specific client type)(Even if multiple PDPs are under
   single administrative domain).

Thanks
Krishna

"Da Silva, Pedro" wrote:

Krishna,

The frwkPibIncarnationName identifies the PDP that provided the PIB instance
refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or
'Manager X' and/or an ip address or whatever, in your system, *uniquely*
identifies each PDP.
It is the responsibility of the PDP to populate the entry, it's effectively
part of the decision.

IHTH,
Pedro

-----Original Message-----
From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com]
Sent: Wednesday, November 21, 2001 10:29 AM
To: IETF RAP WG
Subject: PIB Incarnation

Hi,
   This is a query with reference to ID on framework PIB.
>From the document, I could not understand how PDP & PEP
exchange PIB incarnation table details.

Specifically, What can be the name of "frwkPibIncarnationName"
attribute. Is it the responsibility of PDP to fill this
attribute?

For your reference, structure of  FrwkPibIncarnationEntry
is given below.

  FrwkPibIncarnationEntry ::= SEQUENCE {
           frwkPibIncarnationPrid                InstanceId,
           frwkPibIncarnationName                SnmpAdminString,
           frwkPibIncarnationId                  OCTET STRING,
           frwkPibIncarnationLongevity           Unsigned32,
           frwkPibIncarnationTtl                 Unsigned32,
           frwkPibIncarnationActive              TruthValue
   }

Thanks & Regards
Krishna


 
  --------------9266380FA775D703C48222BC-- ------=_NextPartTM-000-25dc44f5-de94-11d5-84a5-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com ------=_NextPartTM-000-25dc44f5-de94-11d5-84a5-0000e2293f7c-- From owner-rap@ops.ietf.org Thu Nov 22 06:56:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13292 for ; Thu, 22 Nov 2001 06:56:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166sRd-0006sZ-00 for rap-data@psg.com; Thu, 22 Nov 2001 03:55:05 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 166sRc-0006sN-00 for rap@ops.ietf.org; Thu, 22 Nov 2001 03:55:04 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 22 Nov 2001 11:57:20 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id HAA09958 for ; Thu, 22 Nov 2001 07:57:05 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 11:49:27 -0000 Message-ID: From: "Da Silva, Pedro" To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Date: Thu, 22 Nov 2001 11:49:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Multiple PDPs may manage a PEP but not concurrently. The PEP can only make requests to one and only one PDP at a given time. There is also the scenario where the PEP has a local PDP. In this case, you may actually have two entities concurrently providing decisions to the PEP. Note that the PEP must relay all local decisions to the remote PDP, as it is *the authoritative source* of decisions (LPDPDecision). cheers, Pedro -----Original Message----- From: Abdul Malick [mailto:abdulmk@future.futsoft.com] Sent: Thursday, November 22, 2001 4:00 AM To: Da Silva, Pedro; IETF RAP WG Subject: RE: PIB Incarnation [sic] Hello Pedro, But can multiple PDPs manage a PEP at the same time? Also to make a particular incarnation active, i think the PDP only has to make the decision. In this case how is the activation of incarnations co-ordinated among different PDPs given the fact that only one incarnation can be active at the same time. Regards, Malick -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Da Silva, Pedro Sent: Wednesday, 21 November 2001 8:15 PM To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Krishna, The frwkPibIncarnationName identifies the PDP that provided the PIB instance refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or 'Manager X' and/or an ip address or whatever, in your system, *uniquely* identifies each PDP. It is the responsibility of the PDP to populate the entry, it's effectively part of the decision. IHTH, Pedro -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: Wednesday, November 21, 2001 10:29 AM To: IETF RAP WG Subject: PIB Incarnation Hi, This is a query with reference to ID on framework PIB. >From the document, I could not understand how PDP & PEP exchange PIB incarnation table details. Specifically, What can be the name of "frwkPibIncarnationName" attribute. Is it the responsibility of PDP to fill this attribute? For your reference, structure of FrwkPibIncarnationEntry is given below. FrwkPibIncarnationEntry ::= SEQUENCE frwkPibIncarnationPrid InstanceId, frwkPibIncarnationName SnmpAdminString, frwkPibIncarnationId OCTET STRING, frwkPibIncarnationLongevity Unsigned32, frwkPibIncarnationTtl Unsigned32, frwkPibIncarnationActive TruthValue } Thanks & Regards Krishna From owner-rap@ops.ietf.org Thu Nov 22 07:49:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13854 for ; Thu, 22 Nov 2001 07:49:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166tFZ-00094H-00 for rap-data@psg.com; Thu, 22 Nov 2001 04:46:41 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 166tFX-000949-00 for rap@ops.ietf.org; Thu, 22 Nov 2001 04:46:40 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 22 Nov 2001 12:48:54 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id IAA21812 for ; Thu, 22 Nov 2001 08:48:39 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 12:41:01 -0000 Message-ID: From: "Da Silva, Pedro" To: rap@ops.ietf.org Subject: RE: PIB Incarnation [sic] Date: Thu, 22 Nov 2001 12:40:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17352.EE7F09A0" 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_01C17352.EE7F09A0 Content-Type: text/plain; charset="iso-8859-1" 1. A PDP must be within the administrative domain of a PEP in order to *directly* manage that PEP. The assumption is that under an administrative domain the PDPs administer, in a coordinated fashion, a common and consistent set of policies. If policies come from outside a given domain, then there will most likely have to be some form of policy negotiation between inter-domain PDPs. 2.Yes. Good point, I forgot to mention that it's per client type in my previous message to Abdul. AFAIK, Pedro -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: Thursday, November 22, 2001 3:31 AM To: Da Silva Pedro Cc: Abdul Malick; rap@ops.ietf.org Subject: Re: PIB Incarnation [sic] Hi Pedro, It is now clear for me that it is PDP's responsibility to set frwkPibIncarnationName. This will work well incase of single PDP. But, how can PEP get managed by multiple PDP's and still maintain uniqueness of frwkPibIncarnationName + frwkPibIncarnationId. To summarize: 1. Is there an assumption that, multiple PDPs must belong to a single administrative domain? In such case there is no conflict in maintaining unique PDP names. 2. Is it true that, At any point of time a PEP gets managed by one and only one PDP (For a specific client type)(Even if multiple PDPs are under single administrative domain). Thanks Krishna "Da Silva, Pedro" wrote: Krishna, The frwkPibIncarnationName identifies the PDP that provided the PIB instance refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or 'Manager X' and/or an ip address or whatever, in your system, *uniquely* identifies each PDP. It is the responsibility of the PDP to populate the entry, it's effectively part of the decision. IHTH, Pedro -----Original Message----- From: Krishna Prasad Akkineni [ mailto:krishna.akkineni@wipro.com ] Sent: Wednesday, November 21, 2001 10:29 AM To: IETF RAP WG Subject: PIB Incarnation Hi, This is a query with reference to ID on framework PIB. >From the document, I could not understand how PDP & PEP exchange PIB incarnation table details. Specifically, What can be the name of "frwkPibIncarnationName" attribute. Is it the responsibility of PDP to fill this attribute? For your reference, structure of FrwkPibIncarnationEntry is given below. FrwkPibIncarnationEntry ::= SEQUENCE { frwkPibIncarnationPrid InstanceId, frwkPibIncarnationName SnmpAdminString, frwkPibIncarnationId OCTET STRING, frwkPibIncarnationLongevity Unsigned32, frwkPibIncarnationTtl Unsigned32, frwkPibIncarnationActive TruthValue } Thanks & Regards Krishna ------_=_NextPart_001_01C17352.EE7F09A0 Content-Type: text/html; charset="iso-8859-1"
1. A PDP must be within the administrative domain of a PEP in order to *directly* manage that PEP. The assumption is that under an administrative domain the PDPs administer, in a coordinated fashion, a common and consistent set of policies. If policies come from outside a given domain, then there will most likely have to be some form of policy negotiation between inter-domain PDPs.
 
2.Yes. Good point, I forgot to mention that it's per client type in my previous message to Abdul.
 
AFAIK,
Pedro
-----Original Message-----
From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com]
Sent: Thursday, November 22, 2001 3:31 AM
To: Da Silva Pedro
Cc: Abdul Malick; rap@ops.ietf.org
Subject: Re: PIB Incarnation [sic]

Hi Pedro,
        It is now clear for me that it is PDP's responsibility
to set frwkPibIncarnationName. This will work well incase of
single PDP. But, how can PEP get managed by multiple PDP's and
still maintain uniqueness of frwkPibIncarnationName + frwkPibIncarnationId.

To summarize:
1. Is there an assumption that, multiple PDPs must belong to a single
administrative domain?
In such case there is no conflict in maintaining unique PDP names.
 
2. Is it true that, At any point of time a PEP gets managed by one and only
   one PDP (For a specific client type)(Even if multiple PDPs are under
   single administrative domain).

Thanks
Krishna

"Da Silva, Pedro" wrote:

Krishna,

The frwkPibIncarnationName identifies the PDP that provided the PIB instance
refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or
'Manager X' and/or an ip address or whatever, in your system, *uniquely*
identifies each PDP.
It is the responsibility of the PDP to populate the entry, it's effectively
part of the decision.

IHTH,
Pedro

-----Original Message-----
From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com]
Sent: Wednesday, November 21, 2001 10:29 AM
To: IETF RAP WG
Subject: PIB Incarnation

Hi,
   This is a query with reference to ID on framework PIB.
>From the document, I could not understand how PDP & PEP
exchange PIB incarnation table details.

Specifically, What can be the name of "frwkPibIncarnationName"
attribute. Is it the responsibility of PDP to fill this
attribute?

For your reference, structure of  FrwkPibIncarnationEntry
is given below.

  FrwkPibIncarnationEntry ::= SEQUENCE {
           frwkPibIncarnationPrid                InstanceId,
           frwkPibIncarnationName                SnmpAdminString,
           frwkPibIncarnationId                  OCTET STRING,
           frwkPibIncarnationLongevity           Unsigned32,
           frwkPibIncarnationTtl                 Unsigned32,
           frwkPibIncarnationActive              TruthValue
   }

Thanks & Regards
Krishna


 
 
------_=_NextPart_001_01C17352.EE7F09A0-- From owner-rap@ops.ietf.org Thu Nov 22 07:51:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13895 for ; Thu, 22 Nov 2001 07:51:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166tH9-00095Y-00 for rap-data@psg.com; Thu, 22 Nov 2001 04:48:19 -0800 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by psg.com with esmtp (Exim 3.33 #1) id 166tH8-00095I-00 for rap@ops.ietf.org; Thu, 22 Nov 2001 04:48:18 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 22 Nov 2001 18:30:11 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.4.8.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id fAMCkwB07810; Thu, 22 Nov 2001 18:16:58 +0530 From: "Abdul Malick" To: "Da Silva, Pedro" , "IETF RAP WG" Subject: RE: PIB Incarnation [sic] Date: Thu, 22 Nov 2001 18:13:58 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is it then right to say that a PDP can manage more than one Incarnation and when a PEP contact a PDP for provisioning the PDP can set the required incarnation (among those it manages) as active and automatically the incarnations created by other PDPs as well as other incarnations created by this PDP will become inactive. Malick -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Da Silva, Pedro Sent: Thursday, 22 November 2001 5:19 PM To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Multiple PDPs may manage a PEP but not concurrently. The PEP can only make requests to one and only one PDP at a given time. There is also the scenario where the PEP has a local PDP. In this case, you may actually have two entities concurrently providing decisions to the PEP. Note that the PEP must relay all local decisions to the remote PDP, as it is *the authoritative source* of decisions (LPDPDecision). cheers, Pedro -----Original Message----- From: Abdul Malick [mailto:abdulmk@future.futsoft.com] Sent: Thursday, November 22, 2001 4:00 AM To: Da Silva, Pedro; IETF RAP WG Subject: RE: PIB Incarnation [sic] Hello Pedro, But can multiple PDPs manage a PEP at the same time? Also to make a particular incarnation active, i think the PDP only has to make the decision. In this case how is the activation of incarnations co-ordinated among different PDPs given the fact that only one incarnation can be active at the same time. Regards, Malick -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Da Silva, Pedro Sent: Wednesday, 21 November 2001 8:15 PM To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Krishna, The frwkPibIncarnationName identifies the PDP that provided the PIB instance refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or 'Manager X' and/or an ip address or whatever, in your system, *uniquely* identifies each PDP. It is the responsibility of the PDP to populate the entry, it's effectively part of the decision. IHTH, Pedro -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: Wednesday, November 21, 2001 10:29 AM To: IETF RAP WG Subject: PIB Incarnation Hi, This is a query with reference to ID on framework PIB. >From the document, I could not understand how PDP & PEP exchange PIB incarnation table details. Specifically, What can be the name of "frwkPibIncarnationName" attribute. Is it the responsibility of PDP to fill this attribute? For your reference, structure of FrwkPibIncarnationEntry is given below. FrwkPibIncarnationEntry ::= SEQUENCE frwkPibIncarnationPrid InstanceId, frwkPibIncarnationName SnmpAdminString, frwkPibIncarnationId OCTET STRING, frwkPibIncarnationLongevity Unsigned32, frwkPibIncarnationTtl Unsigned32, frwkPibIncarnationActive TruthValue } Thanks & Regards Krishna From owner-rap@ops.ietf.org Thu Nov 22 07:56:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14000 for ; Thu, 22 Nov 2001 07:56:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166tMt-0009Gl-00 for rap-data@psg.com; Thu, 22 Nov 2001 04:54:15 -0800 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.33 #1) id 166tMs-0009Gd-00 for rap@ops.ietf.org; Thu, 22 Nov 2001 04:54:14 -0800 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id fAMCrew07004 for ; Thu, 22 Nov 2001 18:23:40 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GN7D6500.KWP; Thu, 22 Nov 2001 18:24:05 +0530 Message-ID: <3BFCC9E7.31E173C@wipro.com> Date: Thu, 22 Nov 2001 15:18:24 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: "Da Silva Pedro" CC: IETF RAP WG Subject: Re: PIB Incarnation [sic] References: Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b254ae33-df1e-11d5-84a5-0000e2293f7c" Sender: owner-rap@ops.ietf.org Precedence: bulk ------=_NextPartTM-000-b254ae33-df1e-11d5-84a5-0000e2293f7c Content-Type: multipart/alternative; boundary="------------8BBE8259BBB0417BDC0A7888" --------------8BBE8259BBB0417BDC0A7888 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Pedro. Your explanation enhanced my understanding of PIB incarnation Table usage. cheers Krishna "Da Silva, Pedro" wrote: > Multiple PDPs may manage a PEP but not concurrently. The PEP can only make > requests to one and only one PDP at a given time. > There is also the scenario where the PEP has a local PDP. In this case, you > may actually have two entities concurrently providing decisions to the PEP. > Note that the PEP must relay all local decisions to the remote PDP, as it is > *the authoritative source* of decisions (LPDPDecision). > > cheers, > Pedro > > -----Original Message----- > From: Abdul Malick [mailto:abdulmk@future.futsoft.com] > Sent: Thursday, November 22, 2001 4:00 AM > To: Da Silva, Pedro; IETF RAP WG > Subject: RE: PIB Incarnation [sic] > > Hello Pedro, > > But can multiple PDPs manage a PEP at the same time? > Also to make a particular incarnation active, i think the PDP only has to > make the decision. In this case how is the activation of incarnations > co-ordinated among different PDPs given the fact that only one incarnation > can be active at the same time. > > Regards, > Malick > > -----Original Message----- > From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of > Da Silva, Pedro > Sent: Wednesday, 21 November 2001 8:15 PM > To: IETF RAP WG > Subject: RE: PIB Incarnation [sic] > > Krishna, > > The frwkPibIncarnationName identifies the PDP that provided the PIB instance > refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or > 'Manager X' and/or an ip address or whatever, in your system, *uniquely* > identifies each PDP. > It is the responsibility of the PDP to populate the entry, it's effectively > part of the decision. > > IHTH, > Pedro > > -----Original Message----- > From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] > Sent: Wednesday, November 21, 2001 10:29 AM > To: IETF RAP WG > Subject: PIB Incarnation > > Hi, > This is a query with reference to ID on framework PIB. > >From the document, I could not understand how PDP & PEP > exchange PIB incarnation table details. > > Specifically, What can be the name of "frwkPibIncarnationName" > attribute. Is it the responsibility of PDP to fill this > attribute? > > For your reference, structure of FrwkPibIncarnationEntry > is given below. > > FrwkPibIncarnationEntry ::= SEQUENCE > > frwkPibIncarnationPrid InstanceId, > frwkPibIncarnationName SnmpAdminString, > frwkPibIncarnationId OCTET STRING, > frwkPibIncarnationLongevity Unsigned32, > frwkPibIncarnationTtl Unsigned32, > frwkPibIncarnationActive TruthValue > } > > Thanks & Regards > Krishna --------------8BBE8259BBB0417BDC0A7888 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Pedro. Your explanation enhanced my
understanding of PIB incarnation Table usage.
cheers
Krishna

"Da Silva, Pedro" wrote:

Multiple PDPs may manage a PEP but not concurrently. The PEP can only make
requests to one and only one PDP at a given time.
There is also the scenario where the PEP has a local PDP. In this case, you
may actually have two entities concurrently providing decisions to the PEP.
Note that the PEP must relay all local decisions to the remote PDP, as it is
*the authoritative source* of decisions (LPDPDecision).

cheers,
Pedro

-----Original Message-----
From: Abdul Malick [mailto:abdulmk@future.futsoft.com]
Sent: Thursday, November 22, 2001 4:00 AM
To: Da Silva, Pedro; IETF RAP WG
Subject: RE: PIB Incarnation [sic]

Hello Pedro,

But can multiple PDPs manage a PEP at the same time?
Also to make a particular incarnation active, i think the PDP only has to
make the decision. In this case how is the activation of incarnations
co-ordinated among different PDPs given the fact that only one incarnation
can be active at the same time.

Regards,
Malick

-----Original Message-----
From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of
Da Silva, Pedro
Sent: Wednesday, 21 November 2001 8:15 PM
To: IETF RAP WG
Subject: RE: PIB Incarnation [sic]

Krishna,

The frwkPibIncarnationName identifies the PDP that provided the PIB instance
refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or
'Manager X' and/or an ip address or whatever, in your system, *uniquely*
identifies each PDP.
It is the responsibility of the PDP to populate the entry, it's effectively
part of the decision.

IHTH,
Pedro

-----Original Message-----
From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com]
Sent: Wednesday, November 21, 2001 10:29 AM
To: IETF RAP WG
Subject: PIB Incarnation

Hi,
   This is a query with reference to ID on framework PIB.
>From the document, I could not understand how PDP & PEP
exchange PIB incarnation table details.

Specifically, What can be the name of "frwkPibIncarnationName"
attribute. Is it the responsibility of PDP to fill this
attribute?

For your reference, structure of  FrwkPibIncarnationEntry
is given below.

  FrwkPibIncarnationEntry ::= SEQUENCE

           frwkPibIncarnationPrid                InstanceId,
           frwkPibIncarnationName                SnmpAdminString,
           frwkPibIncarnationId                  OCTET STRING,
           frwkPibIncarnationLongevity           Unsigned32,
           frwkPibIncarnationTtl                 Unsigned32,
           frwkPibIncarnationActive              TruthValue
   }

Thanks & Regards
Krishna


 
 
  --------------8BBE8259BBB0417BDC0A7888-- ------=_NextPartTM-000-b254ae33-df1e-11d5-84a5-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com ------=_NextPartTM-000-b254ae33-df1e-11d5-84a5-0000e2293f7c-- From owner-rap@ops.ietf.org Thu Nov 22 08:03:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14114 for ; Thu, 22 Nov 2001 08:03:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166tTG-0009cG-00 for rap-data@psg.com; Thu, 22 Nov 2001 05:00:50 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 166tTF-0009c8-00 for rap@ops.ietf.org; Thu, 22 Nov 2001 05:00:50 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 22 Nov 2001 13:03:05 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id JAA25083 for ; Thu, 22 Nov 2001 09:02:50 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 12:55:12 -0000 Message-ID: From: "Da Silva, Pedro" To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Date: Thu, 22 Nov 2001 12:55:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Please note my previous message on administrative domains, in response to Krishna. I should add that the PEP is responsible for ensuring that there is only one active pib instance, per client type. Pedro -----Original Message----- From: Abdul Malick [mailto:abdulmk@future.futsoft.com] Sent: Thursday, November 22, 2001 12:44 PM To: Da Silva, Pedro; IETF RAP WG Subject: RE: PIB Incarnation [sic] Is it then right to say that a PDP can manage more than one Incarnation and when a PEP contact a PDP for provisioning the PDP can set the required incarnation (among those it manages) as active and automatically the incarnations created by other PDPs as well as other incarnations created by this PDP will become inactive. Malick -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Da Silva, Pedro Sent: Thursday, 22 November 2001 5:19 PM To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Multiple PDPs may manage a PEP but not concurrently. The PEP can only make requests to one and only one PDP at a given time. There is also the scenario where the PEP has a local PDP. In this case, you may actually have two entities concurrently providing decisions to the PEP. Note that the PEP must relay all local decisions to the remote PDP, as it is *the authoritative source* of decisions (LPDPDecision). cheers, Pedro -----Original Message----- From: Abdul Malick [mailto:abdulmk@future.futsoft.com] Sent: Thursday, November 22, 2001 4:00 AM To: Da Silva, Pedro; IETF RAP WG Subject: RE: PIB Incarnation [sic] Hello Pedro, But can multiple PDPs manage a PEP at the same time? Also to make a particular incarnation active, i think the PDP only has to make the decision. In this case how is the activation of incarnations co-ordinated among different PDPs given the fact that only one incarnation can be active at the same time. Regards, Malick -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Da Silva, Pedro Sent: Wednesday, 21 November 2001 8:15 PM To: IETF RAP WG Subject: RE: PIB Incarnation [sic] Krishna, The frwkPibIncarnationName identifies the PDP that provided the PIB instance refered to by the frwkPibIncarnationId. It can be say 'Primary Manager', or 'Manager X' and/or an ip address or whatever, in your system, *uniquely* identifies each PDP. It is the responsibility of the PDP to populate the entry, it's effectively part of the decision. IHTH, Pedro -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: Wednesday, November 21, 2001 10:29 AM To: IETF RAP WG Subject: PIB Incarnation Hi, This is a query with reference to ID on framework PIB. >From the document, I could not understand how PDP & PEP exchange PIB incarnation table details. Specifically, What can be the name of "frwkPibIncarnationName" attribute. Is it the responsibility of PDP to fill this attribute? For your reference, structure of FrwkPibIncarnationEntry is given below. FrwkPibIncarnationEntry ::= SEQUENCE frwkPibIncarnationPrid InstanceId, frwkPibIncarnationName SnmpAdminString, frwkPibIncarnationId OCTET STRING, frwkPibIncarnationLongevity Unsigned32, frwkPibIncarnationTtl Unsigned32, frwkPibIncarnationActive TruthValue } Thanks & Regards Krishna From owner-rap@ops.ietf.org Fri Nov 23 06:30:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16747 for ; Fri, 23 Nov 2001 06:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 167EVl-0006A5-00 for rap-data@psg.com; Fri, 23 Nov 2001 03:28:49 -0800 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.33 #1) id 167EVk-00069y-00 for rap@ops.ietf.org; Fri, 23 Nov 2001 03:28:48 -0800 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 23 Nov 2001 11:31:04 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id HAA31294 for ; Fri, 23 Nov 2001 07:30:45 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Nov 2001 11:23:10 -0000 Message-ID: From: "Da Silva, Pedro" To: "'rap@ops.ietf.org'" Subject: frwkIfRoleComboTable [sic] Date: Fri, 23 Nov 2001 11:23:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk A given interface may have capabilities that cross more than one capability set. For instance, in DiffServ it is common for an iface to have different capabilities in each direction and these may be represented in distinct capability sets. How can this be captured in the frwkIfRoleComboTable? TIA, Pedro From owner-rap@ops.ietf.org Mon Nov 26 14:05: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 OAA21889 for ; Mon, 26 Nov 2001 14:05:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 168R31-000Byq-00 for rap-data@psg.com; Mon, 26 Nov 2001 11:04:07 -0800 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by psg.com with esmtp (Exim 3.33 #1) id 168R30-000Byj-00 for rap@ops.ietf.org; Mon, 26 Nov 2001 11:04:06 -0800 Received: from 209-6-245-153.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com ([209.6.245.153] helo=rcn.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.33 #10) id 168R2z-0007T0-00 for rap@ops.ietf.org; Mon, 26 Nov 2001 14:04:05 -0500 Message-ID: <3C0291A1.54F9DB47@rcn.com> Date: Mon, 26 Nov 2001 14:01:53 -0500 From: "Mark L. Stevens" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Agenda Items Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The RAP working group will have one 1-hour session during the upcoming IETF meeting in Salt Lake City. We will be posting the agenda shortly, but would like to solicit the working group mailing list for any additional discussion items at this time. If you have an issues that needs to be discussed in the next meeting, please email me at your earliest convenience. -Mark Stevens (rap wg co-chair) From owner-rap@ops.ietf.org Wed Nov 28 05:59:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29150 for ; Wed, 28 Nov 2001 05:59:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1692NY-000I4v-00 for rap-data@psg.com; Wed, 28 Nov 2001 02:55:48 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 1692NX-000I4p-00 for rap@ops.ietf.org; Wed, 28 Nov 2001 02:55:47 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28447; Wed, 28 Nov 2001 05:55:42 -0500 (EST) Message-Id: <200111281055.FAA28447@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-nguyen-rap-cops-sls-01.txt Date: Wed, 28 Nov 2001 05:55:41 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : COPS Usage for SLS negotiation (COPS-SLS) Author(s) : T. Nguyen et al. Filename : draft-nguyen-rap-cops-sls-01.txt Pages : 20 Date : 27-Nov-01 This document describes the use of the Common Open Policy Service (COPS) protocol for supporting Service Level Specification (SLS) negotiation. The [SLS-FRW-TEQ] document has presented the need of a Service Level Specification (SLS). Different works [SLS-TEQ], [SLS- AQU], [SLS-INTER] have defined some SLSs for CPE-PE interface and inter-domain QoS negotiation. The COPS protocol [COPS] has been defined by the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be used in this memo to communicate SLS information from the client to the network provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nguyen-rap-cops-sls-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-nguyen-rap-cops-sls-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: <20011127134659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nguyen-rap-cops-sls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-nguyen-rap-cops-sls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127134659.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Nov 29 12:35: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 MAA24519 for ; Thu, 29 Nov 2001 12:35:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 169V4U-00049K-00 for rap-data@psg.com; Thu, 29 Nov 2001 09:34:02 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 169V4S-00048c-00 for rap@ops.ietf.org; Thu, 29 Nov 2001 09:34:01 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21303; Thu, 29 Nov 2001 06:11:52 -0500 (EST) Message-Id: <200111291111.GAA21303@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-authsession-01.txt Date: Thu, 29 Nov 2001 06:11:52 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Session Authorization for RSVP Author(s) : L. Hamer, B. Kosinski, M. Broda, B. Gage, H. Shieh Filename : draft-ietf-rap-rsvp-authsession-01.txt Pages : 15 Date : 28-Nov-01 This document describes the representation of session authorization information in the POLICY_DATA object [POL-EXT] for supporting policy-based per-session authorization and admission control in RSVP. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into the RSVP PATH message to facilitate proper and secure reservation of those resources within the network. We describe the encoding of media authorization information as RSVP policy elements and provide details relating to operations, processing rules and error scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-rsvp-authsession-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-authsession-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: <20011128145001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-authsession-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-authsession-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128145001.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Nov 29 12:35:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24531 for ; Thu, 29 Nov 2001 12:35:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 169V4T-00049D-00 for rap-data@psg.com; Thu, 29 Nov 2001 09:34:01 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 169V4R-00048c-01 for rap@ops.ietf.org; Thu, 29 Nov 2001 09:34:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21272; Thu, 29 Nov 2001 06:11:47 -0500 (EST) Message-Id: <200111291111.GAA21272@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-session-auth-02.txt Date: Thu, 29 Nov 2001 06:11:46 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework for session set-up with media authorization Author(s) : L. Hamer, B. Gage, H. Shieh Filename : draft-ietf-rap-session-auth-02.txt Pages : 25 Date : 28-Nov-01 Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-session-auth-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-session-auth-02.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-session-auth-02.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: <20011128144948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-session-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-session-auth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128144948.I-D@ietf.org> --OtherAccess-- --NextPart--