From owner-rap@ops.ietf.org Mon Mar 3 18:08:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17142 for ; Mon, 3 Mar 2003 18:08:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pz2n-0001GR-00 for rap-data@psg.com; Mon, 03 Mar 2003 15:08:25 -0800 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by psg.com with esmtp (Exim 3.36 #1) id 18pz2h-0001G8-00; Mon, 03 Mar 2003 15:08:19 -0800 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h23N7GT15673; Mon, 3 Mar 2003 18:07:16 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F1NNAQHB; Mon, 3 Mar 2003 18:07:15 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.179]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FSJVX50S; Mon, 3 Mar 2003 18:07:14 -0500 Message-Id: <5.2.0.9.0.20030303175256.03124c00@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 18:03:34 -0500 To: "Wijnen, Bert (Bert)" From: Kwok Ho Chan Subject: RE: authors 48 hours: RFC 3318 NOW AVAILABLE Cc: "Hahn, Scott" , "Kwok-Ho Chan" , "Sahita, Ravi" , mfine@cisco.com, ah_smith@acm.org, "John Seligson" , mlstevens@rcn.com, kzm@cisco.com, franr@pfn.com, "Rap-wg (E-mail)" , Randy Bush In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501063253@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk My vote on this topic is to keep it as-is in Framework PIB (using Integer32 (-1 | 1..4094) ). The reasoning is as follows: 1. The -1 value does not gets into the data packet being forwarded by the network device, it is used in the management plane only. Using the -1 value will just be as good as using 4095 from that prospective. 2. The -1 value allow it to be more distinct from the normal legal on the wire IEEE value of 1 to 4094, hence it is cleaner to use -1. 3. The DSCP and IPv6 FlowLabel is already using the -1 or "OrAny" concepts, hence keeping it as -1 will be more beneficial. Thanks! -- Kwok Ho Chan -- At 06:03 PM 2/28/03 +0100, Wijnen, Bert (Bert) wrote: >W.r.t. The VLAN ID. > >I had proposed (to the bridgmib WG and mibs mailing list) a >set of TCs that would be inline with your use, as follows: > > VlanId ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "A 12-bit VLAN ID used in the VLAN Tag header." > SYNTAX Integer32 (1..4094) > REFERENCE "Draft Standard for Virtual Bridged Local Area > Networks, P802.1Q/D10, chapter 3.13 > " > > VlanIdOrAny ::= TEXTUAL CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. > The value of -1 is used to indicate a wildcard, > i.e. any value. > " > SYNTAX Integer32 (-1 | 1..4094) > > >The latter one, would have been inline with your use in > > frwk802FilterVlanId OBJECT-TYPE > SYNTAX Integer32 (-1 | 1..4094) > STATUS current > DESCRIPTION > "The VLAN ID (VID) that uniquely identifies a VLAN > within the device. This VLAN may be known or unknown > (i.e., traffic associated with this VID has not yet > been seen by the device) at the time this entry > is instantiated. > > Setting the frwk802FilterVlanId object to -1 indicates that > VLAN data should not be considered during traffic > classification." > ::= { frwk802FilterEntry 5 } > >But afte someone objected to a negative value for 'any, and >based on Andrew's input I believe, people are now discussing > > VlanIdOrAny ::= TEXTUAL CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. > The value of 4095 is not a vlaid VLAN ID and > is used to indicate a wildcard, i.e. any value. > " > SYNTAX INTEGER (1..4095) > >That would be conflicting with your definition, and I might later >ask you to deprecate your object and define a new one that >aligns with the generic VLAN ID as defined by the bridgemib WG. >Unfortunately, they are not sure yet, Bridgemib WG chair is >taking it to IEEE and they will discuss it in week of March 9th, >So it will take a while before we know for sure. > >So I am inclined to let you go with what you have, or to redefine >it as SYNTAX INTEGER (1..4095). >In the latter case, pls again do a quick pseudo WG Last Call >for the change. > > >Please let me know how you want to proceeed. >Bert From owner-rap@ops.ietf.org Fri Mar 7 19:20:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17965 for ; Fri, 7 Mar 2003 19:20:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rS5V-000OG4-00 for rap-data@psg.com; Fri, 07 Mar 2003 16:21:17 -0800 Received: from [2001:418:1::39] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18rS5T-000OFG-00 for rap@ops.ietf.org; Fri, 07 Mar 2003 16:21:15 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18rS5T-000L2g-00 for rap@ops.ietf.org; Fri, 07 Mar 2003 16:21:15 -0800 Message-Id: <200303072259.h27MxjZ20681@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3318 on Framework Policy Information Base Cc: rfc-editor@rfc-editor.org, rap@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Fri, 07 Mar 2003 14:59:44 -0800 X-Spam-Status: No, hits=2.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,RESENT_TO,SPAM_PHRASE_00_01, TO_MALFORMED version=2.43 X-Spam-Level: ** Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3318 Title: Framework Policy Information Base Author(s): R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie Status: Informational Date: March 2003 Mailbox: ravi.sahita@intel.com, scott.hahn@intel.com, khchan@nortelnetworks.com, kzm@cisco.com Pages: 70 Characters: 144530 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-rap-frameworkpib-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3318.txt This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning. 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 (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 (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 is a product of the Resource Access Protocol (RAP) Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030307145812.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3318 --OtherAccess Content-Type: Message/External-body; name="rfc3318.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030307145812.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue Mar 11 11:18:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25564 for ; Tue, 11 Mar 2003 11:18:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18smTD-000CIp-00 for rap-data@psg.com; Tue, 11 Mar 2003 08:19:15 -0800 Received: from relais-inet.francetelecom.com ([212.234.67.6] helo=relais-inet-03.francetelecom.fr) by psg.com with esmtp (Exim 3.36 #1) id 18smTA-000CGs-00 for rap@ops.ietf.org; Tue, 11 Mar 2003 08:19:12 -0800 Received: from [193.248.188.47] by relais-filtrant-03.francetelecom.fr with ESMTP for rap@ops.ietf.org; Tue, 11 Mar 2003 17:19:01 +0100 Received: from fedft02a.francetelecom.fr by relais-filtrant-03.francetelecom.fr with ESMTP for rap@ops.ietf.org; Tue, 11 Mar 2003 17:18:55 +0100 Received: from [193.249.139.219] by fedft02a.francetelecom.fr with ESMTP for rap@ops.ietf.org; Tue, 11 Mar 2003 17:18:54 +0100 Received: from igt2bg036 ([10.165.209.34]) by smtp7.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with SMTP id HBLENH00.6JP; Tue, 11 Mar 2003 17:18:53 +0100 Reply-To: "JACQUENET Christian FTLD/IAP" From: "JACQUENET Christian FTLD/IAP" To: "'Andy Bierman \(Cisco\)'" , "'Randy Bush'" Cc: Subject: A couple of comments about the Network Configuration BOF Date: Tue, 11 Mar 2003 17:11:44 +0100 Message-Id: <005b01c2e7e8$e9a4dd40$22d1a50a@buriapren.w2k.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_OUTLOOK version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, Having read the motivation for the above-mentioned BOF (http://www.ietf.org/ietf/03mar/netconf.txt), as well as its agenda, I must admit I'm quite surprised that only the XMLCONF draft is quoted as a "useful starting point", since most (if not all) the requirements mentioned in the introducing text are addressed by the COPS-PR protocol, which has been standardized as RFC 3084. Furthermore, there are several initiatives, both chartered and individual, such as (to name a few): http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-07.txt http://www.ietf.org/internet-drafts/draft-li-rap-mplspib-00.txt http://www.ietf.org/internet-drafts/draft-boucadair-ipte-acct-pib-01.txt http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-2547bis-pib-02.txt http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-pib-02.txt http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-04.txt ...which clearly show an interest (from both vendors and operators) for the use of the COPS-PR protocol in the Internet community. You might also consider some arguments that have been exchanged on the rap mailing list some time ago, including http://ops.ietf.org/lists/rap/rap.2002/msg00138.html, for the support of a PIB standardization effort together with the use of the COPS-PR protocol. Also, it might be worth not forgetting RFC 3139, possibly including http://www.ietf.org/internet-drafts/draft-jacquenet-tunman-reqts-02.txt as additional "starting points". Don't get me wrong: I'm definitely supporting this BOF initiative (and the freedom of choice in general), since it's been quite a long tradition in the IETF standardization process to let the community choose amongst several options for performing specific actions, such as intra-domain routing with protocols like RIP, OSPF and IS-IS, dyanmic address allocation schemes, with protocols like DHCP, IPCP, RADIUS-inferred IPCP, various encapsulation schemes including IP-in-IP and GRE, etc. I just want to point out the fact that this BOF may have possibly increased its chances of success by welcoming other pointers than the XMLCONF draft, as well as other presentations. Comments welcome. Cheers, Christian. _________________ ________ ______ ______ /_____________ /__ /_ _ / / / / / Christian "I'm a ZZ Fan" Jacquenet /_________/ / / / / / / / / /__/ France Telecom Long Distance ITP/CTO / / /___/__/___/_____/_/__/____ "'Been a while since I made her smile, /__/ /__________________________/_ And I know she's gonna dig my style." /_______________________________/ - Enjoy and get it on.