From owner-rap@ops.ietf.org Tue May 1 07:38:52 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23518 for ; Tue, 1 May 2001 07:38:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uYU2-000461-00 for rap-data@psg.com; Tue, 01 May 2001 04:38:22 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14uYU2-00045u-00 for rap@ops.ietf.org; Tue, 01 May 2001 04:38:22 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23446; Tue, 1 May 2001 07:38:20 -0400 (EDT) Message-Id: <200105011138.HAA23446@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-00.txt Date: Tue, 01 May 2001 07:38:20 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Session Authorization for RSVP Author(s) : L. Hamer, B. Kosinski, B. Gage Filename : draft-ietf-rap-rsvp-authsession-00.txt Pages : 15 Date : 30-Apr-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-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-rsvp-authsession-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-rsvp-authsession-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: <20010430144327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-authsession-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-authsession-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010430144327.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue May 1 07:38:53 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23517 for ; Tue, 1 May 2001 07:38:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uYTo-00045J-00 for rap-data@psg.com; Tue, 01 May 2001 04:38:08 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14uYTn-00044v-00 for rap@ops.ietf.org; Tue, 01 May 2001 04:38:07 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23398; Tue, 1 May 2001 07:38:05 -0400 (EDT) Message-Id: <200105011138.HAA23398@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-00.txt Date: Tue, 01 May 2001 07:38:05 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework for session set-up with media authorization Author(s) : L. Hamer, B. Gage Filename : draft-ietf-rap-session-auth-00.txt Pages : 23 Date : 30-Apr-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-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-session-auth-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-session-auth-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: <20010430144241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-session-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-session-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010430144241.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Wed May 2 07:01:21 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05378 for ; Wed, 2 May 2001 07:01:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uuLf-000HHj-00 for rap-data@psg.com; Wed, 02 May 2001 03:59:11 -0700 Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr) by psg.com with esmtp (Exim 3.16 #1) id 14uuLd-000HHD-00 for rap@ops.ietf.org; Wed, 02 May 2001 03:59:11 -0700 Received: from morgane.enst.fr (morgane.enst.fr [137.194.160.31]) by infres.enst.fr (Postfix) with ESMTP id 00613188D for ; Wed, 2 May 2001 12:59:02 +0200 (MET DST) Received: from morgane (localhost [127.0.0.1]) by morgane.enst.fr (8.9.3+Sun/8.9.3) with SMTP id MAA17287 for ; Wed, 2 May 2001 12:58:58 +0200 (MEST) Message-ID: <3AEFE871.3759@yahoo.com> Date: Wed, 02 May 2001 12:58:57 +0200 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: rap@ops.ietf.org Subject: name space Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have read the RFC 3084 about COPS-PR but I can't understand the world "name sapce" and this phrase in the section 2 (PIB) : "The PIB name space is common to both the PEP and the PDP and data instances within this space are unique within the scope of a given Client-Type and Request-State per TCP connection between a PEP and PDP" Could you please give me an concrete example to illustrate this idea. Thank you. Mai Trang From owner-rap@ops.ietf.org Fri May 4 20:37:27 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22840 for ; Fri, 4 May 2001 20:37:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vq3V-000JqS-00 for rap-data@psg.com; Fri, 04 May 2001 17:36:17 -0700 Received: from [63.109.116.89] (helo=longmail2.lboard.com) by psg.com with esmtp (Exim 3.16 #1) id 14vq3U-000Jnn-00 for rap@ops.ietf.org; Fri, 04 May 2001 17:36:16 -0700 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 20:35:57 -0400 Message-ID: From: Ed Ellesson To: "'rap@ops.ietf.org'" Cc: "'Scott Hahn'" , "'Mark Stevens'" , "'Wijnen, Bert (Bert)'" , "Joel M. Halpern" Subject: RAP WG Notice: Policy Terminology Draft, Extended WG Last Call Date: Fri, 4 May 2001 20:35:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk RAP WG: Our AD has asked us to inform your WG that this WG Last Call is going on in the Policy Framework WG. This is to give you a chance for review and comments, because the terminology is also meant to be used by your WG. Extended WG Last Call: This last call is hereby extended to end at CoB on Fri, May 18, 2001. The latest revision of the Terminology Draft is in the I-D repository. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Please also note that the title is changing to be more descriptive: Terminology for Policy-Based Management This revision reflects all known issues and comments. This note extends the current working group last call, to two weeks from today, and is intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. We are also strongly suggesting that the comments/discussion be done to/on the policy fw wg mailing list... so that we have one archive to check later if needed. If you are not already subscribed to the policy framework mailing list: General Discussion: policy@raleigh.ibm.com To Subscribe: policy-request@raleigh.ibm.com In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy Thank you, and we apologize if you receive more than one notice like this. Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework Working Group From owner-rap@ops.ietf.org Mon May 7 02:59:29 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04133 for ; Mon, 7 May 2001 02:59:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wey0-0008ot-00 for rap-data@psg.com; Sun, 06 May 2001 23:58:00 -0700 Received: from netrd.iii.org.tw ([140.92.61.55]) by psg.com with esmtp (Exim 3.16 #1) id 14wexx-0008iY-00 for rap@ops.ietf.org; Sun, 06 May 2001 23:57:58 -0700 Received: from yucheng (eDrink.netrd.iii.org.tw [140.92.61.172]) by netrd.iii.org.tw (8.9.0/8.9.0) with SMTP id OAA13663 for ; Mon, 7 May 2001 14:49:28 +0800 (CST) Message-ID: <005a01c0d6c2$7ec345e0$ac3d5c8c@netrd.iii.org.tw> From: =?big5?B?pr+ofLjb?= To: Subject: Usage of role combination. Date: Mon, 7 May 2001 14:53:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Excuse me, could anyone give an example of "role combination" ?? I'm so confused about it. Thanks a lot! --- Yu-cheng Chiang Network Communication Lab. Institute for Information Industry ,Taiwan From owner-rap@ops.ietf.org Mon May 7 10:30:57 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13025 for ; Mon, 7 May 2001 10:30:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wm1i-000K7a-00 for rap-data@psg.com; Mon, 07 May 2001 07:30:18 -0700 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14wm1h-000K75-00 for rap@ops.ietf.org; Mon, 07 May 2001 07:30:17 -0700 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GCY0040ZYWDDV@firewall.mcit.com> for rap@ops.ietf.org; Mon, 7 May 2001 14:29:02 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GCY00I01YVI7R@pmismtp04.wcomnet.com>; Mon, 07 May 2001 14:29:01 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GCY00H3VYUXLF@pmismtp04.wcomnet.com>; Mon, 07 May 2001 14:28:10 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Mon, 07 May 2001 14:28:09 +0000 Content-return: allowed Date: Mon, 07 May 2001 14:28:04 +0000 From: "Iliff, Tina" Subject: RE: Usage of role combination. To: "'???'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F580B@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_0k2fHQ3xiqv7lhIbyJILHw)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_0k2fHQ3xiqv7lhIbyJILHw) Content-type: text/plain; charset=iso-8859-1 Examples would be Audio+Video, FTP+TELNET, SMTP... Tina Iliff -----Original Message----- From: yucheng@netrd.iii.org.tw [mailto:yucheng@netrd.iii.org.tw] Sent: Monday, May 07, 2001 1:54 AM To: rap@ops.ietf.org Subject: Usage of role combination. Hi, Excuse me, could anyone give an example of "role combination" ?? I'm so confused about it. Thanks a lot! --- Yu-cheng Chiang Network Communication Lab. Institute for Information Industry ,Taiwan --Boundary_(ID_0k2fHQ3xiqv7lhIbyJILHw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Usage of role combination.

Examples would be Audio+Video, = FTP+TELNET, SMTP...
Tina Iliff


    -----Original = Message-----
    From:   = yucheng@netrd.iii.org.tw [mailto:yucheng@netrd.iii.org.tw= ]
    Sent:   Monday, May 07, 2001 1:54 AM
    To:     rap@ops.ietf.org
    Subject:       = Usage of role combination.

    Hi,

        Excuse me, could = anyone give an example of "role combination" ??
        I'm so confused = about it.  Thanks a lot!

    ---
    Yu-cheng Chiang
    Network Communication Lab.
    Institute for Information Industry = ,Taiwan

--Boundary_(ID_0k2fHQ3xiqv7lhIbyJILHw)-- From owner-rap@ops.ietf.org Tue May 8 09:18:46 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20818 for ; Tue, 8 May 2001 09:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14x7MY-00082H-00 for rap-data@psg.com; Tue, 08 May 2001 06:17:14 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.nortelnetworks.com) by psg.com with smtp (Exim 3.16 #1) id 14x7MX-00080k-00 for rap@ops.ietf.org; Tue, 08 May 2001 06:17:13 -0700 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id JAA07685; Tue, 8 May 2001 09:15:47 -0400 Message-Id: <200105081315.JAA07685@zcars0m9.nortelnetworks.com> Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 8 May 2001 09:15:28 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KHAN7R8D; Tue, 8 May 2001 09:15:29 -0400 Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9F3QYV; Tue, 8 May 2001 09:15:29 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 08 May 2001 09:14:16 -0400 To: Vitor Roque X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] API for COPS Cc: IETF DiffServ Mailing List , IETF Policy Mailing List , diffserv-interest , rap@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk Thank you for your interest in using COPS. Currently only the protocol aspects is been standardized. Of course that most implementations use an API, but this is not exposed since the environments in the PEPs have real-time requirements, and the PDPs' user access is mostly from a GUI and DataBase. Some vendors may sell a developer's kit for COPS, but I will let them respond to your E-Mail. I think this E-Mail thread doesn't belong in the DiffServ list. This is a topic belonging to the RAP working group E-Mail list. I have added rap to the CC list above. Please remove DiffServ from the CC list after this message, else Brian will send you a message. :) -- Kwok Ho Chan -- At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: >Dear Sirs, > >I'm a PhD student at University of Aveiro. I would like to know if there are >API's for COPS and where i can find it for testing. > >Thanks in advance >Best Regards >V.Roque > >--- >Vitor Manuel Gomes Roque > >Instituto Politecnico da Guarda Tel. +351.271 222 634 >Departamento de Informatica Fax. +351.271 220 150 >Av. Dr. Francisco Sa Carneiro, 50 >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt >Home Page: http://www.ipg.pt/user/estg/~vroque > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > From owner-rap@ops.ietf.org Tue May 8 13:52:34 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03262 for ; Tue, 8 May 2001 13:52:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xBd4-000EHa-00 for rap-data@psg.com; Tue, 08 May 2001 10:50:34 -0700 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14xBd4-000EHQ-00 for rap@ops.ietf.org; Tue, 08 May 2001 10:50:34 -0700 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id RAA27776; Tue, 8 May 2001 17:50:11 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 May 2001 17:50:05 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 10:50:03 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8900655DCF9@orsmsx35.jf.intel.com> From: "Hegde, Shriharsha" To: Vitor Roque Cc: IETF Policy Mailing List , rap@ops.ietf.org Subject: RE: API for COPS Date: Tue, 8 May 2001 10:49:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Client (PEP) side SDK is open sourced at http://www.intel.com/ial/cops -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Tuesday, May 08, 2001 6:14 AM To: Vitor Roque Cc: IETF DiffServ Mailing List; IETF Policy Mailing List; diffserv-interest; rap@ops.ietf.org Subject: Re: [Diffserv] API for COPS Thank you for your interest in using COPS. Currently only the protocol aspects is been standardized. Of course that most implementations use an API, but this is not exposed since the environments in the PEPs have real-time requirements, and the PDPs' user access is mostly from a GUI and DataBase. Some vendors may sell a developer's kit for COPS, but I will let them respond to your E-Mail. I think this E-Mail thread doesn't belong in the DiffServ list. This is a topic belonging to the RAP working group E-Mail list. I have added rap to the CC list above. Please remove DiffServ from the CC list after this message, else Brian will send you a message. :) -- Kwok Ho Chan -- At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: >Dear Sirs, > >I'm a PhD student at University of Aveiro. I would like to know if there are >API's for COPS and where i can find it for testing. > >Thanks in advance >Best Regards >V.Roque > >--- >Vitor Manuel Gomes Roque > >Instituto Politecnico da Guarda Tel. +351.271 222 634 >Departamento de Informatica Fax. +351.271 220 150 >Av. Dr. Francisco Sa Carneiro, 50 >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt >Home Page: http://www.ipg.pt/user/estg/~vroque > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > From owner-rap@ops.ietf.org Wed May 9 04:13:58 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01730 for ; Wed, 9 May 2001 04:13:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xP5E-0003Xv-00 for rap-data@psg.com; Wed, 09 May 2001 01:12:32 -0700 Received: from netrd.iii.org.tw ([140.92.61.55]) by psg.com with esmtp (Exim 3.16 #1) id 14xP5C-0003Xk-00 for rap@ops.ietf.org; Wed, 09 May 2001 01:12:31 -0700 Received: from yucheng (eDrink.netrd.iii.org.tw [140.92.61.172]) by netrd.iii.org.tw (8.9.0/8.9.0) with SMTP id QAA24271; Wed, 9 May 2001 16:03:30 +0800 (CST) Message-ID: <007801c0d85f$2b8b0e00$ac3d5c8c@netrd.iii.org.tw> From: =?big5?B?pr+ofLjb?= To: "Abdul Malick" Cc: References: <005a01c0d6c2$7ec345e0$ac3d5c8c@netrd.iii.org.tw> <005301c0d7e6$da4cf3a0$0b07080a@future.futsoft.com> Subject: Re: Usage of role combination. Date: Wed, 9 May 2001 16:08:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Thanks so much! I still have some problems. I don't know clear how to achieve the "Role" concept by framework-PIB tables. When PDP applying policies to PEP, does PDP only need to know its role-combination? Or PDP also needs to know "Interface Capabilities Set Name (IfCapSetName)" ? ----- Original Message ----- From: Abdul Malick To: ¦¿¨|¸Û Sent: Wednesday, May 09, 2001 1:46 AM Subject: Re: Usage of role combination. > Hello Yu-cheng > First i think you unserstand Role > Role is a means to associate a set of policies to the entities to be policy > managed in a device based on the charecteristics (role) of the entities. > > Take for example a Router that has 4 interfaces i1, i2, i3 and i4 > Here the entities managed are the interfaces. > Now you may have some policies that have to applied as per some > characteristics(Role) of an interface > > We can define the characteristics of the interfaces as follows (Eg) > i1 is an ethernet(Role) port + Incoming (Role) (Role Combination is > Ethernet + Incoming) > i2 is an ethernet(Role) port + Outgoing (Role) (Role Combination > is Ethernet + Outgoing) > i3 is a FR port(Role) > i4 is a ATM(Role) port > > Now we can define some policies P1, P2 , P3 , P4 and P5 > We can say that > P1and P2 are applicable for ethernet ports > P3 is appicable for FR ports > P4 for ATM ports > If you see when we enforce the policies, P1 and P2 are automatically > enforced on i1 and i2 and so on > The advantage is that we need not define P1 and P2 separately for i1 and i2 > > Extending this idea if P5 is for Incoming ethernet ports ( Role Combo = > Incoming + Ethernet) then it would be enforced on i1 only > > Hope this helps > > Regards > Malick > > > > > > ----- Original Message ----- > From: "¦¿¨|¸Û" > To: > Sent: Monday, May 07, 2001 12:23 PM > Subject: Usage of role combination. > > > > Hi, > > > > Excuse me, could anyone give an example of "role combination" ?? > > I'm so confused about it. Thanks a lot! > > > > --- > > Yu-cheng Chiang > > Network Communication Lab. > > Institute for Information Industry ,Taiwan > > > > > From owner-rap@ops.ietf.org Wed May 9 10:05:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07299 for ; Wed, 9 May 2001 10:05:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xUXS-0009NR-00 for rap-data@psg.com; Wed, 09 May 2001 07:02:02 -0700 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14xUXR-0009MJ-00 for rap@ops.ietf.org; Wed, 09 May 2001 07:02:01 -0700 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GD200G9YMWA9P@firewall.mcit.com> for rap@ops.ietf.org; Wed, 9 May 2001 14:00:10 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GD200901MW4KJ@pmismtp01.wcomnet.com>; Wed, 09 May 2001 14:00:10 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GD2007C7MVQJL@pmismtp01.wcomnet.com>; Wed, 09 May 2001 13:59:51 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 09 May 2001 13:59:50 +0000 Content-return: allowed Date: Wed, 09 May 2001 13:59:47 +0000 From: "Iliff, Tina" Subject: RE: Usage of role combination. To: "'???'" , Abdul Malick Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F5836@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_vUR8aRNsdz78xZSrW5YqHQ)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_vUR8aRNsdz78xZSrW5YqHQ) Content-type: text/plain; charset=ISO-8859-1 This is basically an implementation question because the drafts and the COPS-PR standard do not explicitly state "MUSTs". Tina Iliff -----Original Message----- From: yucheng@netrd.iii.org.tw [mailto:yucheng@netrd.iii.org.tw] Sent: Wednesday, May 09, 2001 3:08 AM To: Abdul Malick Cc: rap@ops.ietf.org Subject: Re: Usage of role combination. Thanks so much! I still have some problems. I don't know clear how to achieve the "Role" concept by framework-PIB tables. When PDP applying policies to PEP, does PDP only need to know its role-combination? Or PDP also needs to know "Interface Capabilities Set Name (IfCapSetName)" ? ----- Original Message ----- From: Abdul Malick To: ??? Sent: Wednesday, May 09, 2001 1:46 AM Subject: Re: Usage of role combination. > Hello Yu-cheng > First i think you unserstand Role > Role is a means to associate a set of policies to the entities to be policy > managed in a device based on the charecteristics (role) of the entities. > > Take for example a Router that has 4 interfaces i1, i2, i3 and i4 > Here the entities managed are the interfaces. > Now you may have some policies that have to applied as per some > characteristics(Role) of an interface > > We can define the characteristics of the interfaces as follows (Eg) > i1 is an ethernet(Role) port + Incoming (Role) (Role Combination is > Ethernet + Incoming) > i2 is an ethernet(Role) port + Outgoing (Role) (Role Combination > is Ethernet + Outgoing) > i3 is a FR port(Role) > i4 is a ATM(Role) port > > Now we can define some policies P1, P2 , P3 , P4 and P5 > We can say that > P1and P2 are applicable for ethernet ports > P3 is appicable for FR ports > P4 for ATM ports > If you see when we enforce the policies, P1 and P2 are automatically > enforced on i1 and i2 and so on > The advantage is that we need not define P1 and P2 separately for i1 and i2 > > Extending this idea if P5 is for Incoming ethernet ports ( Role Combo = > Incoming + Ethernet) then it would be enforced on i1 only > > Hope this helps > > Regards > Malick > > > > > > ----- Original Message ----- > From: "???" > To: > Sent: Monday, May 07, 2001 12:23 PM > Subject: Usage of role combination. > > > > Hi, > > > > Excuse me, could anyone give an example of "role combination" ?? > > I'm so confused about it. Thanks a lot! > > > > --- > > Yu-cheng Chiang > > Network Communication Lab. > > Institute for Information Industry ,Taiwan > > > > > --Boundary_(ID_vUR8aRNsdz78xZSrW5YqHQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: Usage of role combination.

This is basically an implementation = question because the drafts and the COPS-PR standard do not explicitly = state "MUSTs".

Tina Iliff

    -----Original = Message-----
    From:   = yucheng@netrd.iii.org.tw [mailto:yucheng@netrd.iii.org.tw= ]
    Sent:   Wednesday, May 09, 2001 3:08 AM
    To:     Abdul Malick
    Cc:     rap@ops.ietf.org
    Subject:       = Re: Usage of role = combination.

    Thanks so much!

    I still have some problems.
    I don't know clear how to achieve = the "Role" concept by framework-PIB
    tables.
    When PDP applying policies to PEP, = does PDP only need to know its
    role-combination?
    Or PDP also needs to know = "Interface Capabilities Set Name (IfCapSetName)" ?

    ----- Original Message -----
    From: Abdul Malick = <abdulmk@future.futsoft.com>
    To: ��� <yucheng@netrd.iii.org.tw>
    Sent: Wednesday, May 09, 2001 1:46 = AM
    Subject: Re: Usage of role = combination.


    > Hello Yu-cheng
    > First i think you unserstand = Role
    > Role is a means to associate a = set of policies to the entities to be
    policy
    > managed in a device based on = the charecteristics (role) of the entities.
    >
    > Take for example a Router that = has 4 interfaces i1, i2, i3 and i4
    > Here the entities managed are = the interfaces.
    > Now you may have some policies = that have to applied as per some
    > characteristics(Role) of an = interface
    >
    > We can define the = characteristics of the interfaces as follows (Eg)
    >        i1 is = an ethernet(Role) port + Incoming (Role)   (Role = Combination
    is
    > Ethernet + Incoming)
    >        i2 is = an ethernet(Role) port  + Outgoing (Role)    = (Role
    Combination
    > is Ethernet + Outgoing)
    >        i3 is a = FR port(Role)
    >        i4 is a = ATM(Role) port
    >
    > Now we can define some = policies P1, P2 , P3 , P4 and P5
    > We can say that
    >        &nb= sp; P1and P2  are applicable for ethernet ports
    >        &nb= sp; P3 is appicable for FR ports
    >        &nb= sp; P4 for ATM ports
    > If you see when we enforce the = policies, P1 and P2 are automatically
    > enforced on i1 and i2 and so = on
    > The advantage is that we need = not define P1 and P2 separately for i1 and
    i2
    >
    > Extending this idea if P5 is = for Incoming ethernet ports ( Role Combo =3D
    > Incoming + Ethernet) then it = would be enforced on i1 only
    >
    > Hope this helps
    >
    > Regards
    > Malick
    >
    >
    >
    >
    >
    > ----- Original Message = -----
    > From: "���" <yucheng@netrd.iii.org.tw>
    > To: = <rap@ops.ietf.org>
    > Sent: Monday, May 07, 2001 = 12:23 PM
    > Subject: Usage of role = combination.
    >
    >
    > > Hi,
    > >
    > >     = Excuse me, could anyone give an example of "role combination" = ??
    > >     = I'm so confused about it.  Thanks a lot!
    > >
    > > ---
    > > Yu-cheng Chiang
    > > Network Communication = Lab.
    > > Institute for Information = Industry ,Taiwan
    > >
    > >
    >

--Boundary_(ID_vUR8aRNsdz78xZSrW5YqHQ)-- From owner-rap@ops.ietf.org Fri May 11 07:14:06 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04011 for ; Fri, 11 May 2001 07:14:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14yAqa-000Lv8-00 for rap-data@psg.com; Fri, 11 May 2001 04:12:36 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14yAqZ-000Lv2-00 for rap@ops.ietf.org; Fri, 11 May 2001 04:12:35 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03739; Fri, 11 May 2001 07:12:27 -0400 (EDT) Message-Id: <200105111112.HAA03739@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-sppi-07.txt Date: Fri, 11 May 2001 07:12:27 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Structure of Policy Provisioning Information (SPPI) Author(s) : K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-sppi-07.txt Pages : 44 Date : 10-May-01 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in RFC 3084 [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-sppi-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-sppi-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010510095844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-sppi-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-sppi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010510095844.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri May 11 17:14:25 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20780 for ; Fri, 11 May 2001 17:14:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14yKEJ-0004xB-00 for rap-data@psg.com; Fri, 11 May 2001 14:13:43 -0700 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by psg.com with esmtp (Exim 3.16 #1) id 14yKEI-0004wN-00 for rap@ops.ietf.org; Fri, 11 May 2001 14:13:42 -0700 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GD60032MW9YJK@firewall.mcit.com> for rap@ops.ietf.org; Fri, 11 May 2001 21:13:11 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GD600E01W9QWL@pmismtp01.wcomnet.com> for rap@ops.ietf.org; Fri, 11 May 2001 21:13:10 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GD6007NXW9MK7@pmismtp01.wcomnet.com> for rap@ops.ietf.org; Fri, 11 May 2001 21:12:58 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 21:12:58 +0000 Content-return: allowed Date: Fri, 11 May 2001 21:12:56 +0000 From: "Iliff, Tina" Subject: Interest or Implementor's Discussion Mailing List? To: "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F585E@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_YD2qSJ0uEOu6QNj/QwJ/kQ)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_YD2qSJ0uEOu6QNj/QwJ/kQ) Content-type: text/plain; charset=ISO-8859-1 All, Does an RAP Interest or Implementor's Discussion Mailing List exist? Specifically, I am looking for a list on which to discuss COPS Usage for RSVP. Regards, Tina Iliff --Boundary_(ID_YD2qSJ0uEOu6QNj/QwJ/kQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interest or Implementor's Discussion Mailing List?

All,

Does an RAP Interest or Implementor's = Discussion Mailing List exist?  Specifically, I am looking for a = list on which to discuss COPS Usage for RSVP.

Regards,
Tina Iliff

--Boundary_(ID_YD2qSJ0uEOu6QNj/QwJ/kQ)-- From owner-rap@ops.ietf.org Tue May 15 07:40:27 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21700 for ; Tue, 15 May 2001 07:40:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zd9c-00059A-00 for rap-data@psg.com; Tue, 15 May 2001 04:38:16 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.16 #1) id 14zd9a-000590-00 for rap@ops.ietf.org; Tue, 15 May 2001 04:38:15 -0700 Received: from hdcvwall.wipsys.stph.net (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id RAA08283 for ; Tue, 15 May 2001 17:09:28 +0530 (IST) Received: from radhika ([192.168.34.36]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GDDKB100.L9F for ; Tue, 15 May 2001 17:07:49 +0530 Message-ID: <024201c0dd33$de9bffd0$2422a8c0@wipsys.stph.net> Reply-To: "N Radhika" From: "N Radhika" To: Subject: OID for frwkRolePib Date: Tue, 15 May 2001 17:10:41 +0530 Organization: Wipro Technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_023F_01C0DD61.F8312370" ------=_NextPart_000_023F_01C0DD61.F8312370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the OID for frwkRolePib..=20 ------=_NextPart_000_023F_01C0DD61.F8312370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the OID for frwkRolePib..
------=_NextPart_000_023F_01C0DD61.F8312370-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit ******************************************************************* Disclaimer : The information contained and transmitted in this e-mail is confidential information, and is intended only for the named recipient to which it is addressed. The content of this e-mail may not have been sent with the authority of the company. If the reader of this message is not the named recipient or a person responsible for delivering it to the named recipient, you are notified that the review, dissemination, distribution, transmission, printing or copying, forwarding, or any other use of this message or any part of it, including any attachments, is strictly prohibited. If you have received this communication in error, please delete the e-mail and destroy all record of this communication. Thank you for your assistance. ********************************************************************** --------------InterScan_NT_MIME_Boundary-- From owner-rap@ops.ietf.org Tue May 15 10:20:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28347 for ; Tue, 15 May 2001 10:20:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zfee-0008Xj-00 for rap-data@psg.com; Tue, 15 May 2001 07:18:28 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14zfed-0008XJ-00 for rap@ops.ietf.org; Tue, 15 May 2001 07:18:27 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GDD009F3RPJG1@firewall.mcit.com> for rap@ops.ietf.org; Tue, 15 May 2001 14:17:43 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GDD00K01RPE3B@dgismtp02.wcomnet.com>; Tue, 15 May 2001 14:17:43 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GDD00J3YRP5HO@dgismtp02.wcomnet.com>; Tue, 15 May 2001 14:17:29 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 14:17:28 +0000 Content-return: allowed Date: Tue, 15 May 2001 14:17:27 +0000 From: "Iliff, Tina" Subject: RE: OID for frwkRolePib To: "'N Radhika'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F586F@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_iY52kmKFg0G9MRY+rzaB8Q)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_iY52kmKFg0G9MRY+rzaB8Q) Content-type: text/plain; charset=iso-8859-1 Are you asking for the OID for the Framework PIB? Tina Iliff -----Original Message----- From: N Radhika [mailto:radhika.nacharaju@wipro.com] Sent: Tuesday, May 15, 2001 6:41 AM To: rap@ops.ietf.org Subject: OID for frwkRolePib What is the OID for frwkRolePib.. --Boundary_(ID_iY52kmKFg0G9MRY+rzaB8Q) Content-type: text/html; charset=iso-8859-1
Are you asking for the OID for the Framework PIB?
 

Tina Iliff

 
-----Original Message-----
From: N Radhika [mailto:radhika.nacharaju@wipro.com]
Sent: Tuesday, May 15, 2001 6:41 AM
To: rap@ops.ietf.org
Subject: OID for frwkRolePib

What is the OID for frwkRolePib..
--Boundary_(ID_iY52kmKFg0G9MRY+rzaB8Q)-- From owner-rap@ops.ietf.org Wed May 23 07:17:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00428 for ; Wed, 23 May 2001 07:17:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152WcX-0008OQ-00 for rap-data@psg.com; Wed, 23 May 2001 04:16:05 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 152WcV-0008OK-00 for rap@ops.ietf.org; Wed, 23 May 2001 04:16:04 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00337; Wed, 23 May 2001 07:15:46 -0400 (EDT) Message-Id: <200105231115.HAA00337@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-newidentity-02.txt Date: Wed, 23 May 2001 07:15:46 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Identity Representation for RSVP Author(s) : R. Hess, S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog Filename : draft-ietf-rap-rsvp-newidentity-02.txt Pages : 17 Date : 22-May-01 This document describes the representation of identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-newidentity-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-rsvp-newidentity-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-rsvp-newidentity-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: <20010522134801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-newidentity-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-newidentity-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010522134801.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Wed May 23 07:17:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00437 for ; Wed, 23 May 2001 07:17:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152Wcc-0008Ox-00 for rap-data@psg.com; Wed, 23 May 2001 04:16:10 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 152Wca-0008OT-00 for rap@ops.ietf.org; Wed, 23 May 2001 04:16:08 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00353; Wed, 23 May 2001 07:15:51 -0400 (EDT) Message-Id: <200105231115.HAA00353@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-signaled-priority-v2-01.txt Date: Wed, 23 May 2001 07:15:51 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Signaled Preemption Priority Policy Element Author(s) : S. Herzog Filename : draft-ietf-rap-signaled-priority-v2-01.txt Pages : 12 Date : 22-May-01 This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and [COPS]). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-signaled-priority-v2-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-signaled-priority-v2-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-signaled-priority-v2-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: <20010522134813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-signaled-priority-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-signaled-priority-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010522134813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu May 24 02:43:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07027 for ; Thu, 24 May 2001 02:43:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152opz-0005td-00 for rap-data@psg.com; Wed, 23 May 2001 23:43:11 -0700 Received: from rodin.krdl.org.sg ([192.122.139.27]) by psg.com with esmtp (Exim 3.16 #1) id 152opx-0005tW-00 for rap@ops.ietf.org; Wed, 23 May 2001 23:43:10 -0700 Received: from mailhost.krdl.org.sg (localhost [127.0.0.1]) by rodin.krdl.org.sg (8.11.1/8.11.1) with ESMTP id f4O6eJY17112 for ; Thu, 24 May 2001 14:40:19 +0800 (SGT) Received: from krdl.org.sg ([192.168.133.226]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with ESMTP id OAA15843 for ; Thu, 24 May 2001 14:42:12 +0800 (SGT) Message-ID: <3B0CAD86.841BFD8C@krdl.org.sg> Date: Thu, 24 May 2001 14:43:18 +0800 From: Appan X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Clarifications on error handling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have the following doubts in handling errors in COPS-PR(RFC 3084): 1. The object in report message is defined as follows: ::= <[] *()> ::= *() When can the PEP send more than one bindings? If yes, which PRID should be sent in ? If the PEP wants to specify the same , can this be done without repeating object for each ? 2. When the PEP gets a DEC message for installing/deleting PRIs, it does one more translation from role-combination to actual interface indices. If the installation/deletion fails for one of the multiple interfaces, is the whole DEC message considered failed? How can the PEP indicate to the PDP the error information in this case? Thank you, From owner-rap@ops.ietf.org Thu May 24 15:35:02 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19633 for ; Thu, 24 May 2001 15:35:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1530sU-0000mY-00 for rap-data@psg.com; Thu, 24 May 2001 12:34:34 -0700 Received: from [65.105.173.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1530sT-0000mS-00 for rap@ops.ietf.org; Thu, 24 May 2001 12:34:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 1530sS-0006Q0-00 for rap@ops.ietf.org; Thu, 24 May 2001 12:34:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 1530Ag-000PUG-00 for rap@ops.ietf.org; Thu, 24 May 2001 11:49:19 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18932; Thu, 24 May 2001 14:48:36 -0400 (EDT) Message-Id: <200105241848.OAA18932@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: rap@ops.ietf.org From: The IESG Subject: Protocol Action: Structure of Policy Provisioning Information (SPPI) to Proposed Standard Date: Thu, 24 May 2001 14:48:36 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'Structure of Policy Provisioning Information (SPPI)' as a Proposed Standard. This document is the product of the Resource Allocation Protocol Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. This document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset. Working Group Summary The working group has consensus on this document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen From owner-rap@ops.ietf.org Wed May 30 09:22:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09763 for ; Wed, 30 May 2001 09:22:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1555v6-000OuC-00 for rap-data@psg.com; Wed, 30 May 2001 06:21:52 -0700 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.16 #1) id 1555v6-000Ou5-00 for rap@ops.ietf.org; Wed, 30 May 2001 06:21:52 -0700 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 30 May 2001 14:23:13 +0100 Received: from s1000.orchestream.com ([192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id OAA11764 for ; Wed, 30 May 2001 14:16:59 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 14:17:48 +0100 Message-ID: From: "Da Silva, Pedro" To: rap@ops.ietf.org Subject: frwk pib 04 and diffserv pib 03 integration Date: Wed, 30 May 2001 14:17:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk In qosDataPathTable an entry is declared as: qosDataPathEntry OBJECT-TYPE SYNTAX QosDataPathEntry STATUS current DESCRIPTION "An entry in the data path table describes a single data path in this device." PIB-INDEX { qosDataPathPrid } UNIQUENESS { qosDataPathRoles, qosDataPathIfDirection } ::= { qosDataPathTable 1 } QosDataPathEntry ::= SEQUENCE { qosDataPathPrid InstanceId, qosDataPathIfName SnmpAdminString, qosDataPathRoles RoleCombination, qosDataPathIfDirection IfDirection, qosDataPathStart Prid } The UNIQUENESS clause implies that there can be no duplicates of roleCombo+direction entries. So one cannot have the following: Prid IfName Roles Direction Start 1 eth finance out 283 2 atm finance out 283 The same roleCombo+direction cannot be applied to more than one IfName. Isn't this in contradiction with the frwk pib? The frwkIfCapSetRoleComboTable allows a role to be associated with any number of IfNames. cheers, 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 Wed May 30 12:07:21 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16056 for ; Wed, 30 May 2001 12:07:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1558Ud-00018R-00 for rap-data@psg.com; Wed, 30 May 2001 09:06:43 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 1558Uc-000184-00 for rap@ops.ietf.org; Wed, 30 May 2001 09:06:42 -0700 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GE500EMQOO507@firewall.mcit.com> for rap@ops.ietf.org; Wed, 30 May 2001 16:04:53 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GE500D01OO2BK@pmismtp01.wcomnet.com>; Wed, 30 May 2001 16:04:53 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GE5009OSONTGM@pmismtp01.wcomnet.com>; Wed, 30 May 2001 16:04:41 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 16:04:41 +0000 Content-return: allowed Date: Wed, 30 May 2001 16:04:39 +0000 From: "Iliff, Tina" Subject: RE: frwk pib 04 and diffserv pib 03 integration To: "'Da Silva, Pedro'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F58F5@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk I agree. I would suggest adding qosDataPathIfName to the UNIQUENESS clause. It is possible to have a different START value associated with the same Roles but different IfName and Direction. --Tina Iliff -----Original Message----- From: Da Silva, Pedro [mailto:pdasilva@orchestream.com] Sent: Wednesday, May 30, 2001 8:18 AM To: rap@ops.ietf.org Subject: frwk pib 04 and diffserv pib 03 integration In qosDataPathTable an entry is declared as: qosDataPathEntry OBJECT-TYPE SYNTAX QosDataPathEntry STATUS current DESCRIPTION "An entry in the data path table describes a single data path in this device." PIB-INDEX { qosDataPathPrid } UNIQUENESS { qosDataPathRoles, qosDataPathIfDirection } ::= { qosDataPathTable 1 } QosDataPathEntry ::= SEQUENCE { qosDataPathPrid InstanceId, qosDataPathIfName SnmpAdminString, qosDataPathRoles RoleCombination, qosDataPathIfDirection IfDirection, qosDataPathStart Prid } The UNIQUENESS clause implies that there can be no duplicates of roleCombo+direction entries. So one cannot have the following: Prid IfName Roles Direction Start 1 eth finance out 283 2 atm finance out 283 The same roleCombo+direction cannot be applied to more than one IfName. Isn't this in contradiction with the frwk pib? The frwkIfCapSetRoleComboTable allows a role to be associated with any number of IfNames. cheers, 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 Wed May 30 12:25:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16706 for ; Wed, 30 May 2001 12:25:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1558nA-0001Qe-00 for rap-data@psg.com; Wed, 30 May 2001 09:25:52 -0700 Received: from mail2.orchestream.com ([195.153.64.126]) by psg.com with esmtp (Exim 3.16 #1) id 1558n9-0001QY-00 for rap@ops.ietf.org; Wed, 30 May 2001 09:25:52 -0700 Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 30 May 2001 17:27:13 +0100 Received: from s1000.orchestream.com ([192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id RAA20376 for ; Wed, 30 May 2001 17:21:04 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 17:21:54 +0100 Message-ID: From: "Da Silva, Pedro" To: rap@ops.ietf.org Subject: RE: frwk pib 04 and diffserv pib 03 integration Date: Wed, 30 May 2001 17:21:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk The problem with adding the IfName to the UNIQUENESS clause is that it leads to duplicate information in the table. Namely the relationship between roleCombo+direction and PathSart will be duplicated for each IfName that has the same roleCombo+direction, as shown in the example below. Pedro -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@wcom.com] Sent: Wednesday, May 30, 2001 5:05 PM I agree. I would suggest adding qosDataPathIfName to the UNIQUENESS clause. It is possible to have a different START value associated with the same Roles but different IfName and Direction. --Tina Iliff -----Original Message----- From: Da Silva, Pedro [mailto:pdasilva@orchestream.com] Sent: Wednesday, May 30, 2001 8:18 AM In qosDataPathTable an entry is declared as: qosDataPathEntry OBJECT-TYPE SYNTAX QosDataPathEntry STATUS current DESCRIPTION "An entry in the data path table describes a single data path in this device." PIB-INDEX { qosDataPathPrid } UNIQUENESS { qosDataPathRoles, qosDataPathIfDirection } ::= { qosDataPathTable 1 } QosDataPathEntry ::= SEQUENCE { qosDataPathPrid InstanceId, qosDataPathIfName SnmpAdminString, qosDataPathRoles RoleCombination, qosDataPathIfDirection IfDirection, qosDataPathStart Prid } The UNIQUENESS clause implies that there can be no duplicates of roleCombo+direction entries. So one cannot have the following: Prid IfName Roles Direction Start 1 eth finance out 283 2 atm finance out 283 The same roleCombo+direction cannot be applied to more than one IfName. Isn't this in contradiction with the frwk pib? The frwkIfCapSetRoleComboTable allows a role to be associated with any number of IfNames. cheers, 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 May 31 08:13:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21508 for ; Thu, 31 May 2001 08:13:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155RKN-0005hl-00 for rap-data@psg.com; Thu, 31 May 2001 05:13:23 -0700 Received: from p-mail1.rd.francetelecom.fr ([193.49.124.31] helo=p-mail1.cnet.fr) by psg.com with smtp (Exim 3.16 #1) id 155RKM-0005hU-00 for rap@ops.ietf.org; Thu, 31 May 2001 05:13:23 -0700 Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 14:08:45 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE23D@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "IPSEC-POLICY (E-mail)" , "RAP (E-mail)" Cc: NOISETTE Yoann FTRD/DMI/CAE , RABOT Wilfrid FTRD/DMI/CAE Subject: COPS-PR security general issues Date: Thu, 31 May 2001 14:08:24 +0200 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 We are currently working on the general theme of provisioning. We are considering COPS-PR with attention and would bring to the attention of RAP and IPSP experts the following remarks and questions with our apologizes if these issues have already been debated. In a general way, COPS-PR has been designed to provision configuration policies for various functional domains such as IPSec, L2TP, MPLS, AAA, Routing, TE .... Considering for instance, IPSec, AAA and L2TP, provisioning of those functions leads to exchange with the equipment sensitive information such as shared secrets (L2TP-Tunnel-password, users password, radius secret and so on). Within COPS there is an optional security mechanisms, which only guarantees the integrity of the COPS messages. There is no general mechanisms allowing to cipher some particular sensitive fields. Do these security issues shall conduct an implementer or an operator to systematically make use of IPSec to secure exchanges between a PEP and a PDP so that it becomes possible to provision sensitive security information without having to defined ciphered fields in the PIBs for which no generic mechanisms have currently been defined ? If IPSec is used to secure COPS-PR exchanges what would become the utility of the integrity mechanisms defined within COPS and more especially when used within COPS-PR ? Additionally, the IPSec PIB which is currently in its definition phase, allows to define IKE rules specifying pre-shared key as Ike proposal authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with presharedKey(1) as possible value]method but does not allow to provision those secrets. This means that the provisioning of those secrets shall be done by an other way and in that case advantages of COPS-PR in case of pre-shared authentication becomes greatly reduced since this shall be achieved by hand or using an other mechanism. In a same way if L2TP or AAA PIBs were to be defined how secrets (and more generally sensitive information) should be provisioned ? -In clear : not reasonable -Ciphered : there is no generic mechanisms -Protected by IPSec, SSL... : should work fine, but the RFC should precise that usage of a particular client type, defining sensitive information MUST make use of an external mechanisms in order to secure those sensitive information.. To conclude it seams that we can have the two possible approaches in order to allow the exchange of sensible security information between a PEP an a PDP : 1-systematicaly make use of an underlying security layer (IPSec for instance) to secure exchanges between PEP and PDP. In that case the COPS integrity mechanism is no more necessary. This approach implies that the PEP has to support a security communication layer which might not be the case in all situation. 2-defines a generic COPS ciphering mechanism which allows to protect some sensitive fields. Security is embedded in the COPS protocol and must be supported. If this issue was solved, could IPSP experts extend the PIB so that shared secret can be exchanged or is the reason for which it is not currently supported more fundamental ? Thanks in advance for your answers and comments. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@francetelecom.com From owner-rap@ops.ietf.org Thu May 31 13:07:02 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02275 for ; Thu, 31 May 2001 13:07:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155VuB-0009S5-00 for rap-data@psg.com; Thu, 31 May 2001 10:06:39 -0700 Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by psg.com with esmtp (Exim 3.16 #1) id 155VuA-0009Rd-00 for rap@ops.ietf.org; Thu, 31 May 2001 10:06:38 -0700 Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 3CA7EA88; Thu, 31 May 2001 10:05:56 -0700 (PDT) Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 2DDFCB90 for ; Thu, 31 May 2001 10:05:55 -0700 (PDT) Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 19:06:00 +0200 Message-ID: From: "Bouarich, Reda" To: rap@ops.ietf.org Subject: About Path-Resv vs reciever-sender Date: Thu, 31 May 2001 19:08:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hi everybody, Just a quick question to make things clear in my mind. Between a source and a client communication, the source (sender) send a Path message to the client (reciever) after a PDP acceptance then the reciever responds with a Resv command. I did not understand how the sender know that the reciever has requested a communication the first time since that sender is the first actor of the communication. I understand that the sender has to send Path message all the time to overcome the time out mechanism, but the first time, the reciever needs to contact the source to request something, no? Any help will be appreciated. Thanks a lot. Reda. From owner-rap@ops.ietf.org Thu May 31 18:48:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09695 for ; Thu, 31 May 2001 18:48:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155bEP-000F4p-00 for rap-data@psg.com; Thu, 31 May 2001 15:47:53 -0700 Received: from gremlin.ics.uci.edu ([128.195.1.70] ident=mmdf) by psg.com with smtp (Exim 3.16 #1) id 155bEO-000F4h-00 for rap@ops.ietf.org; Thu, 31 May 2001 15:47:52 -0700 Received: from godzilla.ics.uci.edu ( schakrav@godzilla.ics.uci.edu [128.195.1.58] ) by gremlin-relay.ics.uci.edu id aa02732 ; 31 May 2001 15:47 PDT Date: Thu, 31 May 2001 15:47:45 -0700 (PDT) From: Sanjeev Chakravarty To: "Bouarich, Reda" cc: rap@ops.ietf.org Subject: Re: About Path-Resv vs reciever-sender In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Reda, RSVP uses source based routing and yeah the drawback is that each router needs to maintain a soft-state for the flow. So periodically the sender(source) sends Path messages to to refresh the state and the receiver(destination) correspondingly sends the RESV messages. The sender may decide to adopt a different route becoz of congestion or other reasons and on receiving the Path message the reciever has to traverse exactly the same path that the Path message took but in the reverse direction. Sanjeev Chakravarty Corona Networks On Thu, 31 May 2001, Bouarich, Reda wrote: > Hi everybody, > Just a quick question to make things clear in my mind. Between a source and > a client communication, the source (sender) send a Path message to the > client (reciever) after a PDP acceptance then the reciever responds with a > Resv command. > I did not understand how the sender know that the reciever has requested a > communication the first time since that sender is the first actor of the > communication. I understand that the sender has to send Path message all the > time to overcome the time out mechanism, but the first time, the reciever > needs to contact the source to request something, no? > Any help will be appreciated. > Thanks a lot. > Reda. > >