From owner-rap@ops.ietf.org Mon Jun 3 07:41:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08657 for ; Mon, 3 Jun 2002 07:41:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EqBR-000O51-00 for rap-data@psg.com; Mon, 03 Jun 2002 04:39:33 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17EqBK-000O4c-00 for rap@ops.ietf.org; Mon, 03 Jun 2002 04:39:27 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08532; Mon, 3 Jun 2002 07:38:57 -0400 (EDT) Message-Id: <200206031138.HAA08532@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-08.txt Date: Mon, 03 Jun 2002 07:38:57 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 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-08.txt Pages : 66 Date : 31-May-02 Structure of Policy Provisioning Information (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 (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the Common Open Policy Service (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each. This document defines a set of PRCs and textual conventions that are common to all clients that provision policy using COPS for Provisioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-08.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-08.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-08.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: <20020531131736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-frameworkpib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-frameworkpib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020531131736.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue Jun 4 03:23:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20350 for ; Tue, 4 Jun 2002 03:23:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17F8eI-000GQn-00 for rap-data@psg.com; Tue, 04 Jun 2002 00:22:34 -0700 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.36 #1) id 17F8eF-000GQb-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 00:22:31 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g547Mvn22783 for ; Tue, 4 Jun 2002 07:22:57 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g547QGA03884 for ; Tue, 4 Jun 2002 07:26:16 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060400273504742 ; Tue, 04 Jun 2002 00:27:35 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 00:22:30 -0700 Message-ID: <59885C5E3098D511AD690002A5072D3C062BD968@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org Cc: "Mark L. Stevens (E-mail)" , "Bert Wijnen (Bert) (E-mail)" Subject: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call Date: Tue, 4 Jun 2002 00:22:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk The Framework PIB has been updated following IESG comments and some very intensive work by several people. The new I-D is at: http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-08.txt There are a number of changes since the version that passed WG Last Call and our AD has asked for an additional last call. Since the IESG is expediting the review of this draft to meet a 3GPP deadline, it is important to get any comments from the WG ASAP. Comments need to be received in the next day or so. I'm sorry about the short notice, but we really want to help 3GPP meet their deadlines. Please review this document and send any comments to the list as soon as possible (i.e. now). Scott Hahn RAP WG co-chair From owner-rap@ops.ietf.org Tue Jun 4 03:37:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20503 for ; Tue, 4 Jun 2002 03:37:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17F8t7-000H9s-00 for rap-data@psg.com; Tue, 04 Jun 2002 00:37:53 -0700 Received: from ierw.net.avaya.com ([198.152.13.101]) by psg.com with esmtp (Exim 3.36 #1) id 17F8t3-000H9c-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 00:37:49 -0700 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03334 for ; Tue, 4 Jun 2002 03:36:04 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03316 for ; Tue, 4 Jun 2002 03:36:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call Date: Tue, 4 Jun 2002 10:35:13 +0300 Message-ID: Thread-Topic: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call Thread-Index: AcILmNvdmep1E9qQQK2QXfG8GigCegAAUVhA From: "Romascanu, Dan (Dan)" To: "Hahn, Scott" , Cc: "Mark L. Stevens (E-mail)" , "Bert Wijnen (Bert) (E-mail)" X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20503 At the request of Bert Wijnen, I have looked on some aspects related tot he way the 802 filters and markers are implemented. I sent a set of comments to the editors on 5/13, and they have been partially acknowledged by Ravi Sahita. However, I do not see any of the changes that I suggested implemented in this latest release. Here are my comments again. - The current scheme allows only for exact matching for VlanId. This does not allow for any range or wildcarding operations. Did you consider defining a VlanIdMask object, similar to the one defined for SA and DA? - What is the reason to use SYNTAX of BITS for frwk802FilterUserPriority? There is nothing terribly wrong with this, it just seems inconsistent with the way frwk802FilterVlanId, and the marker objects are defined. - There is no filter for packet length (or should I look for it some place else?) - 802 marker table - is not stripping the tag (making the packets untagged) a possible marker action? You cannot do it today with the marker table Thanks, Dan > -----Original Message----- > From: Hahn, Scott [mailto:scott.hahn@intel.com] > Sent: Tuesday, June 04, 2002 10:22 AM > To: rap@ops.ietf.org > Cc: Mark L. Stevens (E-mail); Bert Wijnen (Bert) (E-mail) > Subject: Urgent: draft-ietf-rap-frameworkpib-08.txt - > additional last call > > > > The Framework PIB has been updated following IESG comments and some > very intensive work by several people. The new I-D is at: > > http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-08.txt > > There are a number of changes since the version that passed > WG Last Call and > our AD has asked for an additional last call. Since the IESG > is expediting > the review of this draft to meet a 3GPP deadline, it is > important to get any > comments from the WG ASAP. Comments need to be received in > the next day or > so. > > I'm sorry about the short notice, but we really want to help > 3GPP meet their > deadlines. > > Please review this document and send any comments to the list > as soon as > possible (i.e. now). > > > Scott Hahn > RAP WG co-chair > > From owner-rap@ops.ietf.org Tue Jun 4 05:11:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21688 for ; Tue, 4 Jun 2002 05:11:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FAKQ-000LSw-00 for rap-data@psg.com; Tue, 04 Jun 2002 02:10:10 -0700 Received: from ish7.ericsson.com.au ([203.61.155.111]) by psg.com with esmtp (Exim 3.36 #1) id 17FAKL-000LSI-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 02:10:05 -0700 Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g5498Ag03708; Tue, 4 Jun 2002 19:08:10 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id g5499o422576; Tue, 4 Jun 2002 19:09:51 +1000 (EST) Received: from ericsson.com.au (EF5S700K6Q8F69N [150.236.87.20]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L6D26SYB; Tue, 4 Jun 2002 19:09:48 +1000 Message-ID: <3CFC83CB.4000204@ericsson.com.au> Date: Tue, 04 Jun 2002 19:09:31 +1000 From: Brian Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hahn, Scott" CC: rap@ops.ietf.org, "Mark L. Stevens (E-mail)" , "Bert Wijnen (Bert) (E-mail)" , David Boswarthick Subject: Re: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call References: <59885C5E3098D511AD690002A5072D3C062BD968@orsmsx111.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi All. I feel I should point out that there should no longer be any time pressures on this draft from the 3gpp perspective. The framework PIB is no longer listed as a dependency to the 3gpp development. This was finally determined at the last CN3 meeting in may after continued development of the 3gpp Go PIB. Therefore, 3gpp timelines should not be used as a reason to rush through a review of the PIB. I cannot unfortunately give a url to the updated work plan which was edited online at the meeting. I shall have to pass this on to David (CN3 secretary responsible for the CN3 updates to the work plan) to provide confirmation/updated work plan details if anyone feels it necessary. /brian Hahn, Scott wrote: >The Framework PIB has been updated following IESG comments and some >very intensive work by several people. The new I-D is at: > >http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-08.txt > >There are a number of changes since the version that passed WG Last Call and >our AD has asked for an additional last call. Since the IESG is expediting >the review of this draft to meet a 3GPP deadline, it is important to get any >comments from the WG ASAP. Comments need to be received in the next day or >so. > >I'm sorry about the short notice, but we really want to help 3GPP meet their >deadlines. > >Please review this document and send any comments to the list as soon as >possible (i.e. now). > > > Scott Hahn > RAP WG co-chair > > > From owner-rap@ops.ietf.org Tue Jun 4 08:39:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25908 for ; Tue, 4 Jun 2002 08:39:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FDYR-0005kZ-00 for rap-data@psg.com; Tue, 04 Jun 2002 05:36:51 -0700 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by psg.com with esmtp (Exim 3.36 #1) id 17FDYL-0005kK-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 05:36:45 -0700 Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GX600M01LP6SD@firewall.wcom.com> for rap@ops.ietf.org; Tue, 4 Jun 2002 12:36:42 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GX600M08LP5QM@firewall.wcom.com>; Tue, 04 Jun 2002 12:36:42 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GX600E01LOXJ3@pmismtp01.wcomnet.com>; Tue, 04 Jun 2002 12:36:41 +0000 (GMT) Received: from dgmexch09.wcomnet.com ([166.38.58.240]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GX600D8WLOT9T@pmismtp01.wcomnet.com>; Tue, 04 Jun 2002 12:36:29 +0000 (GMT) Received: by DGMEXCH09.wcomnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 04 Jun 2002 12:36:29 +0000 Content-return: allowed Date: Tue, 04 Jun 2002 12:36:22 +0000 From: "Rawlins, Diana" Subject: RE: Using FEEDBACK features To: "'Yacine El Mghazli'" , "Kulkarni, Amol" , rap@ops.ietf.org Message-id: <6EFD2D8565069542A1029F2D17B5462504C4E2@ripexch001.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Yacine, The usage table provides the semantics as well as the structure. I don't think a generic framework table "counts" should be used for BGP/MPLS VPN specific usage and DiffServ policing packets dropped usage. I think we should stay away from overloading the semantics. The addition of the label and routes counts to a BGP/MPLS PIB sounds ok to me. -Diana -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@alcatel.fr] Sent: Tuesday, June 04, 2002 4:19 AM To: Rawlins, Diana; Kulkarni, Amol; rap@ops.ietf.org Subject: Using FEEDBACK features hi Diana, Amol and all, I'm currently updating the BGP/MPLS VPN PIB (draft-yacine-ppvpn-2547bis-pib-00) with feedback features, according to the feeback frwk and using feedback frwk PIB. I wish the PEP to monitor a number of routes and a number of labels. hence, I define 2 usage tables: - the label usage table, which records a number of labels, - the route usage table, which records a number of routes. isn't it a bit heavy to define TWO tables in order to monitor TWO counters, especially if both use the same 'Counter32' type ? can't we imagine a single usage table, inwhich the attribute is a generic counter ? the linkage table will then define the nature of the counter (what is counted...) for each PRI of this single counter usage class. if yes, why dont defining such a generic usage table (the simpliest one !) in the feedback frwk PIB ? there is the same problem for the different threshold tables... EXAMPLE: ------------------------------------------------------------------------ -- -- Generic Counter Usage class -- frwkFeedbackCounterUsageTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkFeedbackCounterUsageEntry PIB-ACCESS report-only STATUS current DESCRIPTION "This class defines the counter usage attribute that the PEP is to monitor for VRFs." ::= { frwkFeedbackUsageClasses XX } frwkFeedbackCounterUsageEntry OBJECT-TYPE SYNTAX FrwkFeedbackCounterUsageEntry STATUS current DESCRIPTION "Defines the attributes the PEP is to monitor, record and report." PIB-INDEX { frwkFeedbackCounterUsagePrid } UNIQUENESS { frwkFeedbackCounterUsageLinkRefId } ::= { frwkFeedbackCounterUsageTable 1 } frwkFeedbackCounterUsageEntry ::= SEQUENCE { frwkFeedbackCounterUsagePrid InstanceId, frwkFeedbackCounterUsageLinkRefId ReferenceId, frwkFeedbackCounterUsageCount Counter32 } frwkFeedbackCounterUsagePrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class." ::= { frwkFeedbackCounterUsageEntry 1 } frwkFeedbackCounterUsageLinkRefId OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES { frwkFeedBackLinkEntry } STATUS current DESCRIPTION "The ReferenceId of the Linkage Policy instance used to base this usage policy instance upon." ::= { frwkFeedbackCounterUsageEntry 2 } frwkFeedbackCounterUsageCount OBJECT-TYPE SYNTAX Counter32 STATUS current DESCRIPTION "The count hold by the associated selection class during the reporting interval." ::= { frwkFeedbackCounterUsageEntry 3 } -- -- Generic Threshold class -- frwkFeedbackThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkFeedbackThresholdEntry PIB-ACCESS install STATUS current DESCRIPTION "This class defines the threshold attributes corresponding to usage attributes specified in the frwkFeedbackCounterUsageTable class." ::= { frwkFeedbackUsageClasses YY } frwkFeedbackThresholdEntry OBJECT-TYPE SYNTAX frwkFeedbackThresholdEntry STATUS current DESCRIPTION "Defines the attributes to hold thershold values." PIB-INDEX { frwkFeedbackThresholdPrid } ::= { frwkFeedbackThresholdTable 1 } frwkFeedbackThresholdEntry ::= SEQUENCE { frwkFeedbackThresholdPrid InstanceId, frwkFeedbackThresholdThresh Unsigned32 } frwkFeedbackThresholdPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class." ::= { frwkFeedbackThresholdEntry 1 } frwkFeedbackThresholdLinkRefId OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The threshold that must be exceeded to trigger a report in the next reporting interval." ::= { frwkFeedbackThresholdEntry 2 } ---------------------------------------------------------------------- thanks, yacine From owner-rap@ops.ietf.org Tue Jun 4 10:57:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01536 for ; Tue, 4 Jun 2002 10:57:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FFkX-000Dgx-00 for rap-data@psg.com; Tue, 04 Jun 2002 07:57:29 -0700 Received: from cnri-2-115.cnri.reston.va.us ([132.151.2.115] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17FFkT-000DgQ-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 07:57:25 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17FFkR-00025O-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 07:57:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-reply-to: From: "Andrew Smith" To: "Romascanu, Dan \(Dan\)" , Cc: "Mark L. Stevens \(E-mail\)" , "Bert Wijnen \(Bert\) \(E-mail\)" , "Hahn, Scott" Subject: RE: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call Date: Tue, 4 Jun 2002 07:43:11 -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Dan, 1. A mask on VLANID: this would be appropriate if there were some sort of internal structure to the numbers but there is none. A range might be useful. (A mask is appropriate for MAC addresses since there is a well-known internal structure to these although a range is probably less so). 2. I don't see any reason to favour BITS or INTEGER for user_priority - maybe BITS since there is some (approximate) substructure in the number space to handle switches implementing fewer than 8 traffic classes (see 802.1p mapping tables). 3. Length filter - I guess that might be useful but it's not a L2-specific thing is it? 4. Stripping of VLAN tags is a job for VLAN PIBs, not QoS/marking PIBs - it's a packet format thing, not a QoS thing. There's only one special case, that of priority-tagged frames that do not indicate a VLANID (i.e. 000) but, even there, the 802.1Q standard does not specify any mode where a bridge should strip the tag just for this special case (you have to configure, on a per-VLAN basis, whether a port should forward tagged or untagged). You could argue that some implementations allow you to do this but it's not specified anywhere in a standard. Hope these comments help (I missed your comments first time around). Andrew -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 04, 2002 12:35 AM To: Hahn, Scott; rap@ops.ietf.org Cc: Mark L. Stevens (E-mail); Bert Wijnen (Bert) (E-mail) Subject: RE: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call At the request of Bert Wijnen, I have looked on some aspects related tot he way the 802 filters and markers are implemented. I sent a set of comments to the editors on 5/13, and they have been partially acknowledged by Ravi Sahita. However, I do not see any of the changes that I suggested implemented in this latest release. Here are my comments again. - The current scheme allows only for exact matching for VlanId. This does not allow for any range or wildcarding operations. Did you consider defining a VlanIdMask object, similar to the one defined for SA and DA? - What is the reason to use SYNTAX of BITS for frwk802FilterUserPriority? There is nothing terribly wrong with this, it just seems inconsistent with the way frwk802FilterVlanId, and the marker objects are defined. - There is no filter for packet length (or should I look for it some place else?) - 802 marker table - is not stripping the tag (making the packets untagged) a possible marker action? You cannot do it today with the marker table Thanks, Dan > -----Original Message----- > From: Hahn, Scott [mailto:scott.hahn@intel.com] > Sent: Tuesday, June 04, 2002 10:22 AM > To: rap@ops.ietf.org > Cc: Mark L. Stevens (E-mail); Bert Wijnen (Bert) (E-mail) > Subject: Urgent: draft-ietf-rap-frameworkpib-08.txt - > additional last call > > > > The Framework PIB has been updated following IESG comments and some > very intensive work by several people. The new I-D is at: > > http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-08.txt > > There are a number of changes since the version that passed > WG Last Call and > our AD has asked for an additional last call. Since the IESG > is expediting > the review of this draft to meet a 3GPP deadline, it is > important to get any > comments from the WG ASAP. Comments need to be received in > the next day or > so. > > I'm sorry about the short notice, but we really want to help > 3GPP meet their > deadlines. > > Please review this document and send any comments to the list > as soon as > possible (i.e. now). > > > Scott Hahn > RAP WG co-chair > > From owner-rap@ops.ietf.org Tue Jun 4 11:14:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02303 for ; Tue, 4 Jun 2002 11:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FG1b-000Eeq-00 for rap-data@psg.com; Tue, 04 Jun 2002 08:15:07 -0700 Received: from ierw.net.avaya.com ([198.152.13.101]) by psg.com with esmtp (Exim 3.36 #1) id 17FG1X-000EeM-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 08:15:03 -0700 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13282 for ; Tue, 4 Jun 2002 11:13:17 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13255 for ; Tue, 4 Jun 2002 11:13:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call Date: Tue, 4 Jun 2002 18:12:27 +0300 Message-ID: Thread-Topic: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call Thread-Index: AcIL1bc2blmmr0MxTXeYyD1hqb7M8wAAJ4uQ From: "Romascanu, Dan (Dan)" To: "Andrew Smith" , Cc: "Mark L. Stevens (E-mail)" , "Bert Wijnen (Bert) (E-mail)" , "Hahn, Scott" X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02303 Hi Andy, > > 1. A mask on VLANID: this would be appropriate if there were > some sort of > internal structure to the numbers but there is none. A range might be > useful. (A mask is appropriate for MAC addresses since there > is a well-known > internal structure to these although a range is probably less so). I agree that range is better than mask. However, I am aware that it might be more difficult to implement. I have actually seen proprietary implementations that do use masks, and if they were available customers may do design VLAN structures to accommodate them. Having nothing in place but individual VLANIDs seems restrictive. > 2. I don't see any reason to favour BITS or INTEGER for > user_priority - > maybe BITS since there is some (approximate) substructure in > the number > space to handle switches implementing fewer than 8 traffic > classes (see > 802.1p mapping tables). As I said, this was not a strong objection. > 3. Length filter - I guess that might be useful but it's not > a L2-specific > thing is it? Depends 'what Ethernet'. General case it may not be a layer 2 specific issue, that's why I was asking if I need to look some place else. I guess the answer is that there is no such place, and you seem to agree this may be a miss. > 4. Stripping of VLAN tags is a job for VLAN PIBs, not > QoS/marking PIBs - > it's a packet format thing, not a QoS thing. There's only one > special case, > that of priority-tagged frames that do not indicate a VLANID > (i.e. 000) but, > even there, the 802.1Q standard does not specify any mode > where a bridge > should strip the tag just for this special case (you have to > configure, on a > per-VLAN basis, whether a port should forward tagged or > untagged). You could > argue that some implementations allow you to do this but it's > not specified > anywhere in a standard. I was thinking exactly on the context of a hybrid port (interface) - if the filter includes a VLANID, you can configure exactly this type of policy through the marker without the need to configure individually on each port per-VLAN basis. > > Hope these comments help (I missed your comments first time around). > > Andrew Thanks, Dan > > -----Original Message----- > From: owner-rap@ops.ietf.org > From owner-rap@ops.ietf.org Tue Jun 4 11:48:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03323 for ; Tue, 4 Jun 2002 11:48:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FGY9-000GdY-00 for rap-data@psg.com; Tue, 04 Jun 2002 08:48:45 -0700 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 3.36 #1) id 17FGY3-000GdH-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 08:48:39 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g54FmVA10716; Tue, 4 Jun 2002 11:48:31 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KWNA9V3H; Tue, 4 Jun 2002 11:48:29 -0400 Received: from tweedy.NortelNetworks.com (tweedy.engeast.baynetworks.com [192.32.229.230]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KZ3DGPRM; Tue, 4 Jun 2002 11:48:29 -0400 Message-Id: <5.0.0.25.0.20020604114206.036b58c0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 04 Jun 2002 11:45:06 -0400 To: Brian Williams From: Kwok Ho Chan Subject: Re: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call Cc: "Hahn, Scott" , rap@ops.ietf.org, "Mark L. Stevens (E-mail)" , "Bert Wijnen (Bert) (E-mail)" , David Boswarthick In-Reply-To: <3CFC83CB.4000204@ericsson.com.au> References: <59885C5E3098D511AD690002A5072D3C062BD968@orsmsx111.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi All: Time pressure on this draft from the 3GPP perspective still holds. The framework PIB is still listed as a possible dependency to the 3GPP development. As indicated by Stephen Hayes. Also the 3GPP Go PIB is not totally completed at the last CN3 meeting in May. There will be additional contributions to the 3GPP Go PIB in the next meeting at Helsinki to complete the 3GPP Go PIB. These contributions will add in the needed dependencies on the Framework PIB. -- Kwok -- At 07:09 PM 6/4/02 +1000, Brian Williams wrote: > Hi All. >I feel I should point out that there should no longer be any time >pressures on this draft from the 3gpp perspective. The framework PIB is >no longer listed as a dependency to the 3gpp development. This was >finally determined at the last CN3 meeting in may after continued >development of the 3gpp Go PIB. Therefore, 3gpp timelines should not be >used as a reason to rush through a review of the PIB. > >I cannot unfortunately give a url to the updated work plan which was >edited online at the meeting. I shall have to pass this on to David (CN3 >secretary responsible for the CN3 updates to the work plan) to provide >confirmation/updated work plan details if anyone feels it necessary. >/brian > >Hahn, Scott wrote: > > >The Framework PIB has been updated following IESG comments and some > >very intensive work by several people. The new I-D is at: > > > >http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-08.txt > > > >There are a number of changes since the version that passed WG Last Call and > >our AD has asked for an additional last call. Since the IESG is expediting > >the review of this draft to meet a 3GPP deadline, it is important to get any > >comments from the WG ASAP. Comments need to be received in the next day or > >so. > > > >I'm sorry about the short notice, but we really want to help 3GPP meet their > >deadlines. > > > >Please review this document and send any comments to the list as soon as > >possible (i.e. now). > > > > > > Scott Hahn > > RAP WG co-chair > > > > > > From owner-rap@ops.ietf.org Tue Jun 4 17:38:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16624 for ; Tue, 4 Jun 2002 17:38:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FLzE-000CyR-00 for rap-data@psg.com; Tue, 04 Jun 2002 14:37:04 -0700 Received: from ish7.ericsson.com.au ([203.61.155.111]) by psg.com with esmtp (Exim 3.36 #1) id 17FLz5-000Cxw-00 for rap@ops.ietf.org; Tue, 04 Jun 2002 14:36:56 -0700 Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g54LZ0g26997; Wed, 5 Jun 2002 07:35:00 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id g54Lab411411; Wed, 5 Jun 2002 07:36:38 +1000 (EST) Received: from ericsson.com.au (dhcp-239-96.epa.ericsson.se [146.11.239.96]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L6D265N6; Wed, 5 Jun 2002 07:36:37 +1000 Message-ID: <3CFD32DE.8020102@ericsson.com.au> Date: Wed, 05 Jun 2002 07:36:30 +1000 From: Brian Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kwok Ho Chan CC: "Hahn, Scott" , rap@ops.ietf.org, "Mark L. Stevens (E-mail)" , "Bert Wijnen (Bert) (E-mail)" , David Boswarthick , "Stephen Hayes (EUS)" Subject: Re: Urgent: draft-ietf-rap-frameworkpib-08.txt - additional last call References: <59885C5E3098D511AD690002A5072D3C062BD968@orsmsx111.jf.intel.com> <5.0.0.25.0.20020604114206.036b58c0@zbl6c002.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. comments inline. /brian Kwok Ho Chan wrote: > Hi All: > Time pressure on this draft from the 3GPP perspective still holds. > The framework PIB is still listed as a possible dependency to the 3GPP > development. As indicated by Stephen Hayes. I repeat that to my recollection, the dependency to the framework PIB (along with 2 other drafts) was removed from the work plan during the online editing. This updated document will be presented at the next CN plenary meeting. I have added Stephen Hayes as a receiver to this email. Stephen, can you please confirm the status of the dependency to the framework PIB from the work plan changes at the last CN3 meeting. > Also the 3GPP Go PIB is not totally completed at the last CN3 meeting > in May. > There will be additional contributions to the 3GPP Go PIB in the next > meeting > at Helsinki to complete the 3GPP Go PIB. These contributions will add > in the > needed dependencies on the Framework PIB. Future contributions are not an agreed part of the specification, and are subject to the usual approval process. Hence, they may not be included. Until that meeting introduces these dependencies, my current understanding is that there are none to the framework PIB from 3gpp CN3. > -- Kwok -- > > > At 07:09 PM 6/4/02 +1000, Brian Williams wrote: > >> Hi All. >> I feel I should point out that there should no longer be any time >> pressures on this draft from the 3gpp perspective. The framework PIB is >> no longer listed as a dependency to the 3gpp development. This was >> finally determined at the last CN3 meeting in may after continued >> development of the 3gpp Go PIB. Therefore, 3gpp timelines should not be >> used as a reason to rush through a review of the PIB. >> >> I cannot unfortunately give a url to the updated work plan which was >> edited online at the meeting. I shall have to pass this on to David (CN3 >> secretary responsible for the CN3 updates to the work plan) to provide >> confirmation/updated work plan details if anyone feels it necessary. >> /brian >> >> Hahn, Scott wrote: >> >> >The Framework PIB has been updated following IESG comments and some >> >very intensive work by several people. The new I-D is at: >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-08.txt >> > >> >There are a number of changes since the version that passed WG Last >> Call and >> >our AD has asked for an additional last call. Since the IESG is >> expediting >> >the review of this draft to meet a 3GPP deadline, it is important to >> get any >> >comments from the WG ASAP. Comments need to be received in the next >> day or >> >so. >> > >> >I'm sorry about the short notice, but we really want to help 3GPP >> meet their >> >deadlines. >> > >> >Please review this document and send any comments to the list as >> soon as >> >possible (i.e. now). >> > >> > >> > Scott Hahn >> > RAP WG co-chair >> > >> > >> > > > From owner-rap@ops.ietf.org Wed Jun 5 08:52:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28306 for ; Wed, 5 Jun 2002 08:52:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FaDh-000GNZ-00 for rap-data@psg.com; Wed, 05 Jun 2002 05:48:57 -0700 Received: from cnri-2-119.cnri.reston.va.us ([132.151.2.119] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17FaDd-000GNF-00 for rap@ops.ietf.org; Wed, 05 Jun 2002 05:48:53 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17FaDc-00039J-00; Wed, 05 Jun 2002 05:48:52 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: iesg Cc: rap@ops.ietf.org, ops-chairs@ietf.org, sub-chairs@ietf.org Subject: bert errors Message-Id: Date: Wed, 05 Jun 2002 05:48:52 -0700 X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bert's laptop fried yesterday. no promises for immediate fix. randy From owner-rap@ops.ietf.org Mon Jun 10 07:12:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27996 for ; Mon, 10 Jun 2002 07:12:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HN3Z-000PSS-00 for rap-data@psg.com; Mon, 10 Jun 2002 04:09:53 -0700 Received: from david.siemens.de ([192.35.17.14]) by psg.com with esmtp (Exim 3.36 #1) id 17HN3V-000PSH-00 for rap@ops.ietf.org; Mon, 10 Jun 2002 04:09:49 -0700 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g5AB9l426969 for ; Mon, 10 Jun 2002 13:09:47 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g5AB9lZ18435 for ; Mon, 10 Jun 2002 13:09:47 +0200 (MEST) From: "Hannes Tschofenig" To: Subject: Questions regarding Session & Media Authorization Date: Mon, 10 Jun 2002 13:14:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit hi it was interesting to read your document about session and media authorization drafts. the idea of linking different protocols that somehow depend on each other (sip & rsvp) with regard to the authorization phase seems to be very useful. however by reading your documents some comments/questions came into my mind: in [framework] you describe three models: Coupled Model, Associated Model and the Non-Associated Model from your description it was not clear to me whether in one of the models crypgraphic processing (related to the token) needs to be done by the first-hop router (Edge Router). i assume that no cryptographic verification takes place at the edge router. in [auth] you describe different means to protect the information inside the token. the means for protection seem to be strongly related to rsvp which is not obvious to me. the choice for including non-cryptographic protection (ascii and unicode credentials) are difficult to understand since you pass the token to the end-host and mention in [framework] that the end-host is not trustworthy. hence i would suggest to remove these credentials since they provide no use. the use of kerberos might be difficult in practice since the entity issuing the token needs to know the who is going to verify it (appart from the message size ~ 500bytes for the kerberos token). the verification steps of the kerberos ticket as explained in 5.3 of [auth] seem to be wrong: the verifying entity receives the session ticket and decrypts it to retrieve the session key. this key is then used to verify the keyed message digest with either HMAC-SHA1 or HMAC-MD5 (or digital signature as you call it). the usage of pk-based credentials also seems to be adopted from rsvp. the fact that pk-based credentials are not really used is not really promising. additionally there are concerns related to the size of the token in case of pk-based credentials and the digital signature. in section 8 of [auth] you state that pk-based credentials have an advantage of good scalability but it infrastructure support. since there are only a few entities creating the token and only a few entities verifying the token scalability does is no scalablity problem. in [framework] you describe the Non-Associated Model whereby no trust-relationship exists between the policy servers (RCD and SCD policy servers). why should someone rely on the policy decision of a policy server which is not trusted. if there is a trust relationship between them why not to establish a session key to verify the token or to exchange the required information? my main question is: why is it necessary to include so much information into the token (qos parameters, credentials etc. - e.g. section 3.3.8 of [auth]) although this information could easily be exchanged between the policy servers. all they need is only a "pointer"/identifier to the stored information. section 6. "The Associated Model <>" in [framework] shows such an interaction between the two types of policy servers. hence in such a case the token is much smaller since it only has to contain the necessary information, the protection of the token is simplified by only using a keyed message digest. finally bandwidth is preserved (consider that each session creates a token which has to be sent to the end-host and back). additionally you should include a short statement about what prevents a user from reusing an old token. what do you think? ciao hannes [auth] "Session Authorization for RSVP", [framework] "Framework for session set-up with media authorization", From owner-rap@ops.ietf.org Mon Jun 10 11:40:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09305 for ; Mon, 10 Jun 2002 11:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HRFr-0005Uz-00 for rap-data@psg.com; Mon, 10 Jun 2002 08:38:51 -0700 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.ca.nortel.com) by psg.com with esmtp (Exim 3.36 #1) id 17HRFl-0005Un-00 for rap@ops.ietf.org; Mon, 10 Jun 2002 08:38:45 -0700 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AFcfg22594; Mon, 10 Jun 2002 11:38:41 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 11:38:40 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387A2F@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Hannes Tschofenig'" , rap@ops.ietf.org Subject: RE: Questions regarding Session & Media Authorization Date: Mon, 10 Jun 2002 11:38:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21094.E421E128" X-Spam-Status: No, hits=0.2 required=5.0 tests=MIME_NULL_BLOCK,MAILTO_LINK version=2.20 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_01C21094.E421E128 Content-Type: text/plain; charset="iso-8859-1" Hi, Thanks for your comments. In fact, the draft just went under an IESG review. They expressed similar comments. We are now in the process of clarifying a few points in the draft and should publish a revision shortly. We hope that the clarifications will answer your comments. L-N > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: Monday, June 10, 2002 7:14 AM > To: rap@ops.ietf.org > Subject: Questions regarding Session & Media Authorization > > > hi > > it was interesting to read your document about session and media > authorization drafts. the idea of linking different protocols > that somehow > depend on each other (sip & rsvp) with regard to the > authorization phase > seems to be very useful. however by reading your documents some > comments/questions came into my mind: > > in [framework] you describe three models: Coupled Model, > Associated Model > and the Non-Associated Model > from your description it was not clear to me whether in one > of the models > crypgraphic processing (related to the token) needs to be done by the > first-hop router (Edge Router). i assume that no > cryptographic verification > takes place at the edge router. > > in [auth] you describe different means to protect the > information inside the > token. the means for protection seem to be strongly related > to rsvp which is > not obvious to me. the choice for including non-cryptographic > protection > (ascii and unicode credentials) are difficult to understand > since you pass > the token to the end-host and mention in [framework] that the > end-host is > not trustworthy. hence i would suggest to remove these > credentials since > they provide no use. the use of kerberos might be difficult > in practice > since the entity issuing the token needs to know the who is > going to verify > it (appart from the message size ~ 500bytes for the kerberos > token). the > verification steps of the kerberos ticket as explained in 5.3 > of [auth] seem > to be wrong: the verifying entity receives the session ticket > and decrypts > it to retrieve the session key. this key is then used to > verify the keyed > message digest with either HMAC-SHA1 or HMAC-MD5 (or digital > signature as > you call it). > > the usage of pk-based credentials also seems to be adopted > from rsvp. the > fact that pk-based credentials are not really used is not > really promising. > additionally there are concerns related to the size of the > token in case of > pk-based credentials and the digital signature. in section 8 > of [auth] you > state that pk-based credentials have an advantage of good > scalability but it > infrastructure support. since there are only a few entities > creating the > token and only a few entities verifying the token scalability > does is no > scalablity problem. > > in [framework] you describe the Non-Associated Model whereby no > trust-relationship exists between the policy servers (RCD and > SCD policy > servers). why should someone rely on the policy decision of a > policy server > which is not trusted. if there is a trust relationship > between them why not > to establish a session key to verify the token or to exchange > the required > information? > > my main question is: why is it necessary to include so much > information into > the token (qos parameters, credentials etc. - e.g. section > 3.3.8 of [auth]) > although this information could easily be exchanged between the policy > servers. all they need is only a "pointer"/identifier to the stored > information. section 6. "The Associated Model < Policy Servers>>" > in [framework] shows such an interaction between the two > types of policy > servers. hence in such a case the token is much smaller since > it only has to > contain the necessary information, the protection of the > token is simplified > by only using a keyed message digest. finally bandwidth is preserved > (consider that each session creates a token which has to be > sent to the > end-host and back). > > additionally you should include a short statement about what > prevents a user > from reusing an old token. > > what do you think? > > ciao > hannes > > [auth] "Session Authorization for RSVP", > > [framework] "Framework for session set-up with media authorization", > > > > > ------_=_NextPart_001_01C21094.E421E128 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Questions regarding Session & Media = Authorization

Hi,

Thanks for your comments. In fact, the draft just = went under an IESG review. They
expressed similar comments. We are now in the = process of clarifying a few points
in the draft and should publish a revision = shortly.

We hope that the clarifications will answer your = comments.

L-N



> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofen= ig@mchp.siemens.de]
> Sent: Monday, June 10, 2002 7:14 AM
> To: rap@ops.ietf.org
> Subject: Questions regarding Session & = Media Authorization
>
>
> hi
>
> it was interesting to read your document about = session and media
> authorization drafts. the idea of linking = different protocols
> that somehow
> depend on each other (sip & rsvp) with = regard to the
> authorization phase
> seems to be very useful. however by reading = your documents some
> comments/questions came into my mind:
>
> in [framework] you describe three models: = Coupled Model,
> Associated Model
> and the Non-Associated Model
> from your description it was not clear to me = whether in one
> of the models
> crypgraphic processing (related to the token) = needs to be done by the
> first-hop router (Edge Router). i assume that = no
> cryptographic verification
> takes place at the edge router.
>
> in [auth] you describe different means to = protect the
> information inside the
> token. the means for protection seem to be = strongly related
> to rsvp which is
> not obvious to me. the choice for including = non-cryptographic
> protection
> (ascii and unicode credentials) are difficult = to understand
> since you pass
> the token to the end-host and mention in = [framework] that the
> end-host is
> not trustworthy. hence i would suggest to = remove these
> credentials since
> they provide no use. the use of kerberos might = be difficult
> in practice
> since the entity issuing the token needs to = know the who is
> going to verify
> it (appart from the message size ~ 500bytes for = the kerberos
> token). the
> verification steps of the kerberos ticket as = explained in 5.3
> of [auth] seem
> to be wrong: the verifying entity receives the = session ticket
> and decrypts
> it to retrieve the session key. this key is = then used to
> verify the keyed
> message digest with either HMAC-SHA1 or = HMAC-MD5 (or digital
> signature as
> you call it).
>
> the usage of pk-based credentials also seems to = be adopted
> from rsvp. the
> fact that pk-based credentials are not really = used is not
> really promising.
> additionally there are concerns related to the = size of the
> token in case of
> pk-based credentials and the digital signature. = in section 8
> of [auth] you
> state that pk-based credentials have an = advantage of good
> scalability but it
> infrastructure support. since there are only a = few entities
> creating the
> token and only a few entities verifying the = token scalability
> does is no
> scalablity problem.
>
> in [framework] you describe the Non-Associated = Model whereby no
> trust-relationship exists between the policy = servers (RCD and
> SCD policy
> servers). why should someone rely on the policy = decision of a
> policy server
> which is not trusted. if there is a trust = relationship
> between them why not
> to establish a session key to verify the token = or to exchange
> the required
> information?
>
> my main question is: why is it necessary to = include so much
> information into
> the token (qos parameters, credentials etc. - = e.g. section
> 3.3.8 of [auth])
> although this information could easily be = exchanged between the policy
> servers. all they need is only a = "pointer"/identifier to the stored
> information. section 6. "The Associated = Model <<using Two
> Policy Servers>>"
> in [framework] shows such an interaction = between the two
> types of policy
> servers. hence in such a case the token is much = smaller since
> it only has to
> contain the necessary information, the = protection of the
> token is simplified
> by only using a keyed message digest. finally = bandwidth is preserved
> (consider that each session creates a token = which has to be
> sent to the
> end-host and back).
>
> additionally you should include a short = statement about what
> prevents a user
> from reusing an old token.
>
> what do you think?
>
> ciao
> hannes
>
> = [auth]        "Session = Authorization for RSVP",
> = <draft-ietf-rap-rsvp-authsession-02.txt>
> [framework] "Framework for session set-up = with media authorization",
> = <draft-ietf-rap-session-auth-03.txt>
>
>
>
>

------_=_NextPart_001_01C21094.E421E128-- From owner-rap@ops.ietf.org Tue Jun 11 07:10:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18206 for ; Tue, 11 Jun 2002 07:10:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HjVL-0009dx-00 for rap-data@psg.com; Tue, 11 Jun 2002 04:08:03 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17HjVI-0009dm-00 for rap@ops.ietf.org; Tue, 11 Jun 2002 04:08:00 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18075; Tue, 11 Jun 2002 07:07:25 -0400 (EDT) Message-Id: <200206111107.HAA18075@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-09.txt Date: Tue, 11 Jun 2002 07:07:24 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 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, R. Sahita, S. Hahn, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-frameworkpib-09.txt Pages : 66 Date : 10-Jun-02 Structure of Policy Provisioning Information (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 (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the Common Open Policy Service (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each. This document defines a set of PRCs and textual conventions that are common to all clients that provision policy using COPS for Provisioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-09.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-09.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-09.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: <20020610143257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-frameworkpib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-frameworkpib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143257.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue Jun 11 13:03:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03140 for ; Tue, 11 Jun 2002 13:03:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hp1P-000J4S-00 for rap-data@psg.com; Tue, 11 Jun 2002 10:01:31 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17Hp1J-000J4B-00 for rap@ops.ietf.org; Tue, 11 Jun 2002 10:01:25 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02928; Tue, 11 Jun 2002 13:00:49 -0400 (EDT) Message-Id: <200206111700.NAA02928@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , rap@ops.ietf.org From: The IESG Subject: Document Action: Framework Policy Information Base to Informational Date: Tue, 11 Jun 2002 13:00:48 -0400 X-Spam-Status: No, hits=3.0 required=5.0 tests=SUBJ_HAS_SPACES,TO_MALFORMED version=2.20 X-Spam-Level: *** Sender: owner-rap@ops.ietf.org Precedence: bulk The IESG has approved publication of the following two Internet-Drafts as Informational RFCs: o Framework Policy Information Base o Differentiated Services Quality of Service Policy Information Base These documents are the product of the Resource Access Protocol (RAP) and Differentiated Services (DIFFSERV) Working Groups respectively. The IESG contact persons are Bert Wijnen and Randy Bush. The Working Groups had requested for standards track, but there is not IESG consensus enough to support publication of these documents on the standards track at this time thus we will publish them as Informational RFCs. The IAB just held a workshop on network management and the report on that workshop is being developed. If the results of the workshop and subsequent discussion changes the consensus in the IESG we will then issue a last-call to republish the documents as standards track RFCs. From owner-rap@ops.ietf.org Mon Jun 17 16:34:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19080 for ; Mon, 17 Jun 2002 16:34:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K3Af-000Hj5-00 for rap-data@psg.com; Mon, 17 Jun 2002 13:32:17 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17K3Ac-000Hiu-00 for rap@psg.com; Mon, 17 Jun 2002 13:32:14 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17K3Aa-00094n-00 for rap@psg.com; Mon, 17 Jun 2002 13:32:13 -0700 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F5ABE4A@medha.wsspl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Wilson To: "'rap@ops.ietf.org'" Subject: COPS-PR Report message clarification Date: Mon, 17 Jun 2002 16:37:06 +0530 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi, Can somebody give an explanation for the following...? May look like and old one, but still need to get a clear solotion. In a COPS-PR report message, why do we need to have [0-*] multiplicity for Client SI object, since there can be only one report type at a time. [Ref: rfc 3084] Also, can someone give a illustration for the above object being used in COPS-PR Report message. for example, a detailed error report. Regards Wilson http://www.wsspl.com From owner-rap@ops.ietf.org Tue Jun 25 07:58:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01395 for ; Tue, 25 Jun 2002 07:58:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MovY-0006hb-00 for rap-data@psg.com; Tue, 25 Jun 2002 04:56:08 -0700 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail2.alcatel.fr) by psg.com with esmtp (Exim 3.36 #1) id 17MovN-0006hL-00 for rap@ops.ietf.org; Tue, 25 Jun 2002 04:55:57 -0700 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id g5PBrvqI011776; Tue, 25 Jun 2002 13:53:57 +0200 Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id NAA20136; Tue, 25 Jun 2002 13:54:35 +0200 (MET DST) Received: from athos.dinsunnet (athos [188.9.12.98]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id NAA24259; Tue, 25 Jun 2002 13:54:35 +0200 (MET DST) Received: from alcatel.fr by athos.dinsunnet (8.9.1b+Sun/SMI-SVR4) id NAA29387; Tue, 25 Jun 2002 13:57:24 +0200 (MET DST) Message-ID: <3D185A3F.1070807@alcatel.fr> Date: Tue, 25 Jun 2002 13:55:43 +0200 From: Yacine El Mghazli Organization: Alcate R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: "rap@ops.ietf.org" CC: abierman@cisco.com Subject: [Fwd: I-D ACTION:draft-bierman-nm-observations-00.txt] References: <3D173D8D.6F23B0E6@alcatel.fr> Content-Type: multipart/mixed; boundary="------------060705020104020909090409" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=2.5 required=5.0 tests=EXCUSE_6,DOUBLE_CAPSWORD,COPYRIGHT_CLAIMED,PORN_3 version=2.30 X-Spam-Level: ** Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------060705020104020909090409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, FYI... yacine > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Network Management Observations > Author(s) : A. Bierman > Filename : draft-bierman-nm-observations-00.txt > Pages : 16 > Date : 21-Jun-02 > > This memo contains observations on the progress of standards based > network management efforts within the IETF. In particular, it describes > technical and process oriented deficiencies which have delayed the > creation and adoption of standards for network device configuration, and > offers recommendations for correcting these deficiencies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bierman-nm-observations-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-bierman-nm-observations-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-bierman-nm-observations-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. > --------------060705020104020909090409 Content-Type: text/plain; name="draft-bierman-nm-observations-00.txt" Content-Disposition: inline; filename="draft-bierman-nm-observations-00.txt" Content-Transfer-Encoding: 7bit Internet Draft Andy Bierman Cisco Systems, Inc. 21 June 2002 Network Management Observations Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the SMIng WG mailing list . 1. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. 2. Abstract This memo contains observations on the progress of standards based network management efforts within the IETF. In particular, it describes Internet Draft Network Management Observations June 21, 2002 technical and process oriented deficiencies which have delayed the creation and adoption of standards for network device configuration, and offers recommendations for correcting these deficiencies. 3. Table of Contents 1 Copyright Notice ................................................ 1 2 Abstract ........................................................ 1 3 Table of Contents ............................................... 2 4 Overview ........................................................ 2 5 Observations .................................................... 3 5.1 Why CLI is So Successful ...................................... 3 5.1.1 Importance of ASCII ......................................... 4 5.1.2 Affects of Console Management ............................... 4 5.1.3 Command Oriented Transaction Model .......................... 5 5.1.4 Scripting Tools ............................................. 5 5.2 Why SNMP Isn't Working For Configuration ...................... 6 5.2.1 SNMP Set Isn't Simple ....................................... 6 5.2.2 Management Data Definitions ................................. 7 5.2.3 Transport Protocol .......................................... 7 5.3 How We Can Improve the NM Standards Process ................... 8 5.3.1 Increase Customer Input ..................................... 8 5.3.2 Recognize The Diverse Customer Base ......................... 9 5.3.3 Speedup the Standards Process ............................... 9 5.3.4 Reduce Uncoordinated Standards Efforts ...................... 10 5.3.5 Increase Configuration Standards Awareness .................. 11 5.4 Recommended Strategic Technology Initiatives .................. 11 5.4.1 New Version of the SMI ...................................... 11 5.4.2 Management Protocol Enhancements ............................ 11 5.4.3 Network Wide Management ..................................... 13 5.4.4 More High Level Management Features ......................... 13 6 Acknowledgements ................................................ 14 7 Normative References ............................................ 14 8 Security Considerations ......................................... 15 9 Author's Address ................................................ 15 10 Full Copyright Statement ....................................... 16 4. Overview There has been a great deal of progress in the last 14 years in the area of standards based network monitoring. The Simple Network Management Protocol (SNMP) has matured and been widely deployed for this purpose. A significant number of managed objects have been added to the Management Information Base (MIB) over time as well. Expires December 21, 2002 [Page 2] Internet Draft Network Management Observations June 21, 2002 However, there has not been significant advancement in the development of standard management technologies for network device configuration over the same time period. Instead, network devices are predominately configured via a proprietary command line interface (CLI). There are several factors contributing to this situation, not all of them technical issues. It is not possible to identify a single problem area responsible for this lack of progress, and therefore not possible to identify a simple fix to the problem. It is also not useful to rank the importance or damage caused by specific problems. This memo contains observations on the positive and negative aspects of the standards based technology and processes developed within the IETF for network management, and offers some recommendations for improvement in this area. It focuses on CLI and SNMP technology, since this represents the vast majority of the deployed solutions for configuration management of network devices. It also focuses on network device configuration, since this is the most crucial aspect of network management that is poorly addressed by standards based solutions. 5. Observations There are several contributing factors preventing the advancement of standards based configuration. These observations are divided into four sections: 1) Why CLI is so successful 2) Why SNMP isn't working for configuration 3) How we can improve the NM standards process 4) Recommended strategic technology initiatives 5.1. Why CLI is So Successful The most prevalent technology used for the configuration of network devices is the proprietary CLI. The most obvious reason for this fact is "Because it's there". Operators need a consistent API that will always be available, which is located in the device, and which exists from the very first release of a feature. CLI has maintained its top position, even though it is proprietary. It is used as a human interface and a programming interface, even though as an API it is relatively unstable. There is no consistent data model, no coherent change control process, no well structured documentation, no consistent error codes. It lacks all of the features that a supposedly successful API (such as SNMP) offers, yet it is still the most widely Expires December 21, 2002 [Page 3] Internet Draft Network Management Observations June 21, 2002 used approach by operators. Obviously, the positive attributes must outweigh the deficiencies. So what is CLI doing right? Some of the reasons include: - ASCII encoding - similar to unix shell - session oriented (over TCP) - always available, especially out-of-band - relatively easy for vendors to implement - command-oriented, high-level transaction model 5.1.1. Importance of ASCII The ASCII encoding of CLI commands is significant. CLI commands can be collected together and maintained in a simple text file. This provides a self-documenting, concise representation of the desired state of the networking device. This file (or portions of it) can be easily edited, emailed, searched, compared to other configuration files, cut-and- pasted, and transferred to and from the CLI parser. An operator can perform all these functions with mature, easy-to-use, cheap (or even free), widely available software tools. This is important, especially since there is a natural tendency in the operator community avoid learning new tools, buying expensive tools, trusting 'closed format' tools, and relying on external management devices which will not be available if the inband communication to the managed device fails. 5.1.2. Affects of Console Management During initial device configuration and during network outages, an operator needs to examine device state and change device configuration via an out-of-band connection. This important task requires significant training and an advanced skill set. Traditionally, operators connect a dumb terminal directly to the console port and interact with the device via a human friendly CLI. Because the training costs involved in maintaining network devices are significant, it is undesirable to train operators to use different toolsets for inband and out-of-band management. There is also a desire to limit reliance on complex tools beyond the simple ASCII processing software and hardware traditionally used to manage a device via the console port. The comfort level with CLI, which is oriented for human interaction, is impacted by the type of customer. The need for scalable and automated tools for management increases as the tolerance for service disruption Expires December 21, 2002 [Page 4] Internet Draft Network Management Observations June 21, 2002 risk decreases, and as the number of managed devices increases. 5.1.3. Command Oriented Transaction Model The CLI uses a command oriented transaction model, as opposed to the data oriented transaction model used by SNMP, and operators seem to prefer this higher level abstraction. A CLI parser acts upon one command at a time, and each command must be complete. One downside is that there is no proper distinction between a 'create' command and an 'edit' command, so the notion of a complete command varies in relation to the current state of the managed device. For 'create' commands, all mandatory parameters must be present or the command will fail. However, the same command may also be used to edit existing state, in which case only the parameters present will be changed (as expected). Vendors like this simple transaction model because there are relatively few corner cases to support, no complicated rollback to support, and no dribble-in input which creates temporary intermediate state to maintain. While the command line represents the lowest level transaction, a higher layer abstraction is also used by operators. It is recognized that one or more commands are required to complete the state change for an arbitrary feature. This ordered list of commands can be called a 'configlet'. One or more configlets make up a configuration file, and the configuration file represents the entire desired configuration state of the managed device. Usually, the configuration file contains a section for each network interface on the device. This transaction model and file structure is generally supported by all vendors, even though the command syntax varies for each vendor. 5.1.4. Scripting Tools There is widespread use of scripting tools, which interact with the CLI interface, for the purpose of automating configuration management tasks. The problem with this approach is the inherent instability of the CLI interface, which is designed for humans. Change control for proprietary CLIs is not as rigorous as the change control applied to MIB definitions (either proprietary or standard). There is also no expectation of reusability of such scripts across vendors, or sometimes even different products from the same vendor. There are significant advantages to scripting tools however. Once an operator learns a particular scripting toolset, such as Perl or Expect, there are few additional training costs beyond the knowledge of specific CLI dialects, which the network operator must know anyway in order to manage the device from the console. Even when a script breaks due to Expires December 21, 2002 [Page 5] Internet Draft Network Management Observations June 21, 2002 instability of the CLI from one version to the next, it is often a trivial matter to repair the script. Also, these scripts operate on the same commands whether inband or console port access is used, so they can be utilized even when the device cannot be reached inband. It is desirable to somehow apply the rigorous change control found in MIBs, as well as the common semantics offered by MIBs, to the scripting tool environment. Other common features, such as consistent error codes, consistent CLI parser behavior, and a core set of common parser commands would also greatly improve the usefulness of scripting tools. 5.2. Why SNMP Isn't Working For Configuration Although SNMP is being used for configuration for some features and platforms, it is not widely used for general configuration of network devices. Even still, it is the most widely used technology except proprietary CLI for this task. There are a number of factors why SNMP has not replaced CLI as the primary technology for configuration. It has been said that the reason SNMP is not used for configuration is that it lacks security. Although this is a valid concern, it turns out that security is one of several pre-requisites for widespread adoption. It may not even be the most important reason. It should be noted that until recently, CLI used telnet as an application protocol, and passwords were passed in cleartext, just as community strings are passed in all versions of SNMP except SNMPv3. Perhaps if SNMPv3 had been completed before the widespread adoption of SSH, its use would be more widespread, but that did not happen. 5.2.1. SNMP Set Isn't Simple Contrary to the name, development and maintenance of SNMP agent and application technology is not simple, compared to CLI. The primary reason is that the protocol state machine for Set operations is much more complicated than for CLI. The protocol allows for arbitrarily complex transactions, in which multiple partial and unrelated rows may be passed to the agent, and the agent is expected to complete these transactions (as best it can) in an all-or-none fashion, and as if simultaneously. Instead of the command as the basic transaction unit, a single parameter to a command is the basic transaction unit. This unwarranted complex state machine is much more difficult to design and test than comparable CLI code accomplishing the same task. To make matters worse, there is no distinction in the protocol between create, edit, and delete operations. Instead these protocol operations Expires December 21, 2002 [Page 6] Internet Draft Network Management Observations June 21, 2002 are encoded as data, represented by a RowStatus MIB object in each row of a configurable table. There are other reasons SNMP application development is more complicated than CLI scripting tools, such as a lack of high-level elements of procedure for configuration. MIBs do not consistently specify the creation order and other high level operational requirements to complete a given functional task. CLI documentation tends to be much more task oriented, and devices are expected to support a specific procedure to complete a given task. 5.2.2. Management Data Definitions The Structure of Management Information (SMI) used within the IETF for MIB definitions is partly responsible for the high cost of SNMP development. The only mechanism for data reuse in the SMI is the refinement of base types (textual conventions). The data structure definition capability is limited to simple arrays of scalar data types. The expression of complex data structures is accomplished by creating associated arrays of scalar objects, connected by common index components. This practice leads to data structures which are difficult to read and difficult to implement. This is especially harmful for configuration, because the additional complexity of multiple writable tables causes creation order dependencies. 5.2.3. Transport Protocol SNMP messages are transported over UDP, which has traditionally limited the maximum message size to an unreasonably small number. This has impacted MIB and application design. The 'createAndWait' RowStatus state exists primarily to cope with this limitation, allowing configuration creation operations to be split across two or more transactions. MIBs are also designed with this size constraint in mind. Individual objects are sometimes arbitrary sized so a single instance will always fit in a 484 octet payload. UDP does not guarantee that packets will be delivered in order, or that only one copy of of the packet will be delivered. This adds unwarranted complexity to the design of MIBs, applications, and agents. Application design is also more complicated because retrieval of large (high-level) objects, such as an entire routing table, is achieved with several GetNext or GetBulk transactions. It is costly and inefficient to handle fragmentation and reassembly in the application layer. If Expires December 21, 2002 [Page 7] Internet Draft Network Management Observations June 21, 2002 large messages were supported (over TCP), then application design would be simplified. New solutions oriented protocol operations to handle retrieval of dynamic tables, such as a copy-then-transfer operation, would also simplify application design. There is a cost to be realized in the agent for this simplicity in the application, but the cost is worth the potential benefits. 5.3. How We Can Improve the NM Standards Process There are several steps that can be taken to improve the effectiveness of network management standards. 5.3.1. Increase Customer Input For a variety of reasons, the standards development process for network management has failed in recent years to adequately solicit and respond to the needs of customers, which include the engineers who develop networking products and the operators who use those products. Software developers have complained that SNMP agents are too costly to develop and maintain, relative to CLI technology. Application developers have complained that a lack of a consistent data model and clear elements of procedure make it difficult to write common code that works for multiple platforms. Network operators have simply stopped paying attention to SNMP standards for configuration, and few enable SNMP writes in their network. The result is that SNMP based software tools for configuration are not widely available, nor are they widely deployed by network operators. Over the years, operators continued to use proprietary CLI based tools, and SNMP standards writers proceeded to create technology without much input from these customers. Other standards efforts (besides SNMP) exist in this space, but nothing that even approaches the deployment level of SNMP based tools for network configuration. It is possible that other standards for network management could be more successful than SNMP, but none have succeeded so far. It is therefore most important that SNMP standards writers make a serious effort to get the network operators involved in the standards process, and be willing to re-think assumptions about product requirements formulated in the absence of customer input. Expires December 21, 2002 [Page 8] Internet Draft Network Management Observations June 21, 2002 5.3.2. Recognize The Diverse Customer Base There is a tendency to characterize the needs of network operators as if they were a single like-minded group, with a single set of priorities and requirements. This is far from the truth. Network operators can roughly be divided into two groups, consisting of Enterprise and Service Provider customers. However, these classifications are less and less useful as enterprise networks get larger and service providers offer more application oriented services. It may be more useful to classify members of this diverse group with a continuum related the their tolerance for risk. At one extreme are large Internet backbone operators who tend to utilize a relatively homogeneous set of products, and are very concerned about even the smallest network device outage, since a single device affects a large number of end users. At the other extreme are small or medium size enterprise operators, who tend to utilize a relatively heterogeneous set of products and are less concerned about the outage of a single device, since a single device affects a relatively small number of users. Another way customers can be differentiated is by the number of managed devices controlled within a single administrative domain, which affects their need for scalable management solutions. At one extreme there are backbone operators managing a relatively small number of core routers, and at the other extreme are broadband service providers managing thousands of similar devices, such as cable modems. The impact of this diversity is that there are significant differences in their configuration requirements, and it not optimal (or possible) to satisfy these requirements with a single one-size-fits-all solution. We should not expect that all management features will be utilized by all operators. 5.3.3. Speedup the Standards Process The process by which standard network management interfaces are created is non-optimal. There has been a great reluctance to create mechanisms for configuration (such as writable MIB objects). There are two main reasons for this phenomenon: Standards are hard It is often very time consuming to get a working group to agree on the management model and then the manageable knobs that should exist for a given technology. Such efforts are often neglected Expires December 21, 2002 [Page 9] Internet Draft Network Management Observations June 21, 2002 altogether or deferred for a future release. Delays in development of standards mean that proprietary solutions will be created by vendors in the interim. Once a vendor (or customer) application developer has created tools which utilize this interim proprietary solution, there is little incentive to devote additional resources to replace the proprietary mechanisms with standard mechanisms later. This tends to defer the creation and deployment of the standard mechanisms forever. Low expectations for standard solutions There is often little to no customer expectation that a standard management interface be created for a given technology. There is the perception that development of such an interface will delay products, and such development can be omitted or done later. However, delays in standard mechanisms often mean they will not be deployed (see above). 5.3.4. Reduce Uncoordinated Standards Efforts One reason for the difficulty in creating management applications is the lack of a overall coordinated effort across working groups. This is partly due to the lack of reusability features in the SMI, and lack of a coherent data model, but it is also due to a lack of a mindset that stresses and enforces reusable definitions. This attitude can be partially attributed to an understandable reluctance to complicate or expand a working group's specific charter to include more generalized solutions. It is also related to the reluctance of a working group to place documents on the standards track that contain normative references to other documents outside the direct control of the working group. There are also no efficient mechanisms available to allow working groups to investigate and track documents in other working groups. It is difficult for individuals to follow the large number of Internet Drafts produced each year. There is no centralized authority that actively attempts to coordinate efforts which are related, or rigorously require working groups to leverage outside work. In addition to technical improvements to increase reusability, the IETF needs to improve the standards process to better facilitate development of reusable management interfaces. Tools which allow people to easily determine the MIB modules exist that are relevant to a particular subject (e.g., a MIB module navigation tool) are needed. Expires December 21, 2002 [Page 10] Internet Draft Network Management Observations June 21, 2002 5.3.5. Increase Configuration Standards Awareness The most important change that can occur is for individual working groups to create configuration management interfaces (e.g., writable MIB objects) as early in the standards process as possible. This will require increased effort and dedication, but the end result will be an increase in the quantity and quality of management applications. 5.4. Recommended Strategic Technology Initiatives The following technology initiatives are suggested to improve the quality of IETF standards for network configuration. They hopefully build on the strengths of CLI and SNMP-based network management. 5.4.1. New Version of the SMI The SMING working group is actively attempting to improve the capability, readability, and reusability of the SMI by introducing hierarchical object naming and aggregate object definitions. For many years, the IETF has attempted to define MIBs in a manner that did not suggest any particular implementation strategy. This resulted in data definitions that are too abstract, which do not correspond well to the data structures actually present in any implementations. This practice should end, and common data structure constructs, such as arrays, structures, and unions should be introduced into MIBs. Nesting of aggregate data structures is also important to increase the usefulness of MIBs. It also also important that high level elements of procedure are carefully considered and explained in MIB documents. If possible, a single mandatory high-level procedure should be documented for each configurable feature. Agent implementations should not be prevented from supporting additional high-level procedures. (E.g, a mandatory procedure may call for a create-and-go type of operation, but this does not prevent an implementation from supporting a create-and-wait type of operation as well.) 5.4.2. Management Protocol Enhancements A new management protocol is needed, which leverages as many features of SNMP as possible, while providing new capabilities. The following new features should be included: Expires December 21, 2002 [Page 11] Internet Draft Network Management Observations June 21, 2002 TCP for the Transport Protocol A session-oriented transaction model and large message sizes can be more easily supported if UDP is replaced with TCP as the transport protocol. Transfer of Aggregate Objects There is a need to move large aggregate objects in addition to the individual MIB objects that SNMP can manipulate, such as the aggregate data structures that will be possible with the new SMI improvements. SubTree Oriented Bulk Retrieval The current GetBulk protocol operation is not optimized for the retrieval of a particular MIB sub-tree. New operations to retrieve the specified (GetSubTree) or the lexinext subtree (GetNextSubTree) are needed to allow an application to more easier transfer a large group of MIB objects. These special operations are also needed in a TCP environment, in which data is streamed back to the application, instead of waiting for a new 'start' condition after every packet. XML Encoding The new protocol should utilize XML encoded messages, rather than ASN.1/BER encoded messages. XML can be easily parsed by humans and machines. XML tool support for a number of disciplines is growing rapidly, while ASN.1/BER is not used in any application except SNMP. Replace RowStatus with Protocol Operations The RowStatus mechanism should be replaced with explicit protocol operations for create, edit, and delete. This can simplify agent and application implementations. There is also a growing consensus that RowStatus is too complicated. It is common for agent developers to support a minimum set of RowStatus enumerations (e.g., createAndGo and delete). As aggregate data objects are introduced into the SMI, use of RowStatus for configuration will get even more complicated. Error handling code may benefit from distinct create and edit operations. PDU Chaining It would be beneficial to create complex protocol operations from two or more simple operations, which can be thought of as 'PDU chaining' or 'chunk' operations. This would allow for a transaction model similar to that used in a CLI. Instead of requiring a series of packets, or requiring the agent to process a large number of varbinds at once, configuration operations can be treated as an Expires December 21, 2002 [Page 12] Internet Draft Network Management Observations June 21, 2002 ordered sequence of distinct, but related commands. Rollback and corner case logic would be easier to design if the transaction model was enhanced in this manner. PDU Chaining Options for All-or-none, Stop-on-error Complex operations such as 'delete, then recreate' could be constructed in a single packet, using chained PDUs with certain options. An all-or-none option would require the agent to validate all chained protocol operations before performing any of them (this is a best-effort, not foolproof validation). Another option to stop (or continue) on any chained protocol operation error would also be useful to emulate CLI transaction behavior. Query Transaction A protocol operation which provides an SQL SELECT type of operation is needed. Simple GetNext or GetBulk operations require that all possible search criteria are accounted for, and all criteria must be present in INDEX components. More complex search criteria (e.g., return ifInOctets and ifOutOctets for all interfaces that have ifOperStatus=='up(1)' and ifType=='fastEther(62)') are needed to provide faster retrieval, especially for managed devices that contain a large number of interfaces or other common monitored attributes. 5.4.3. Network Wide Management Tools are needed which allow an operator to manage groups of devices as a single logical entity or manage a network wide service in a single operation, instead of a series of steps on multiple forwarding devices. There may be some standards work needed to facilitate this type of technology, but an important first step is to reduce the complexity and diversity of the management operations for an arbitrary device or service. Concurrently, steps should be taken immediately to identify the requirements for network-wide management, so support for such operations can be built into the standard mechanisms used to manage a single device. 5.4.4. More High Level Management Features Additional high level features that will make network management easier include: Expires December 21, 2002 [Page 13] Internet Draft Network Management Observations June 21, 2002 Configuration Templates The primary motivation for introducing template capabilities in some fashion is the same for configuration management as it is for software development -- information hiding, controlled reusability, and tiered access control to specific parameters. Additional capabilities, such as the ability to upload, download, and modify templates may be needed to support this feature. Wildcard Operations Wildcarding allows a single set of commands to be applied to multiple instances (e.g., rows) in a single high-level protocol operation. This reduces the bandwidth required, and allows configuration to be applied without explicitly specifying every instance that needs to be affected. Additional error codes may be needed to support this feature. Named Configurations Many network devices support the ability to save and restore more than a single configuration file. At a minimum, it is common to differentiate between the running configuration and the configuration that will be loaded on the next reboot. The SNMP management framework should support this common feature. It is not clear what protocol enhancements are needed for this support. Better Integration With CLI Security Better integration with CLI oriented access control and authentication technology is needed. Operators are reluctant to deploy SNMP Security because it requires separate security administration. This reluctance would be reduced if investments in existing tools and technology for CLI security could be leveraged. 6. Acknowledgements Some comments in this memo have been previously articulated by various people in various forums, such as IETF meetings, and the dilbert- vision@snmp.com mailing list. 7. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, Harvard University, October, 1996. Expires December 21, 2002 [Page 14] Internet Draft Network Management Observations June 21, 2002 8. Security Considerations This memo discusses current network management trends and does not introduce any new security threats. 9. Author's Address Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-3711 Email: abierman@cisco.com Expires December 21, 2002 [Page 15] Internet Draft Network Management Observations June 21, 2002 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires December 21, 2002 [Page 16] --------------060705020104020909090409-- From owner-rap@ops.ietf.org Tue Jun 25 09:40:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05346 for ; Tue, 25 Jun 2002 09:40:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MqXF-0008h3-00 for rap-data@psg.com; Tue, 25 Jun 2002 06:39:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17MqXA-0008gW-00 for rap@ops.ietf.org; Tue, 25 Jun 2002 06:39:04 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17MqX9-0009d3-00 for rap@ops.ietf.org; Tue, 25 Jun 2002 06:39:03 -0700 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F5ABE5E@medha.wsspl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Wilson To: "'rap@ops.ietf.org'" Cc: "'kzm@cisco.com'" Subject: FW: COPS-PR Report message clarification Date: Tue, 25 Jun 2002 12:32:57 +0530 X-Spam-Status: No, hits=-2.0 required=5.0 tests=X_NOT_PRESENT,FROM_NAME_NO_SPACES version=2.30 Sender: owner-rap@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > Hi, > Can somebody give an explanation for the following...? > May look like and old one, but still need to get a clear solotion. In a > COPS-PR report message, why do we need to have [0-*] multiplicity for > Client SI object, since there can be only one report type at a time. > [Ref: rfc 3084] > > Also, can someone give a illustration for the above object being used in > COPS-PR Report message. for example, a detailed error report. > > Regards > Wilson > http://www.wsspl.com