From idr-bounces@ietf.org Mon Feb 2 11:17:11 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE7128C145; Mon, 2 Feb 2009 11:17:11 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4F53A6885 for ; Mon, 2 Feb 2009 11:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLDXoQ8Du+ks for ; Mon, 2 Feb 2009 11:17:09 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 487913A68C5 for ; Mon, 2 Feb 2009 11:17:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,366,1231113600"; d="txt'?scan'208";a="132384648" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2009 19:16:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n12JGlms021732; Mon, 2 Feb 2009 11:16:47 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n12JGkWH000551; Mon, 2 Feb 2009 19:16:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 11:16:46 -0800 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 11:16:46 -0800 Message-ID: <4987469E.60207@cisco.com> Date: Mon, 02 Feb 2009 11:16:46 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Inter-Domain Routing List Content-Type: multipart/mixed; boundary="------------080100020702070307050000" X-OriginalArrivalTime: 02 Feb 2009 19:16:46.0205 (UTC) FILETIME=[CA31AAD0:01C9856A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10141; t=1233602210; x=1234466210; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20[Fwd=3A=20I-D=20Action=3Adraft-chen-rfc4893bis- 01.txt] |Sender:=20; bh=pfqwY5vsbEyRX6pQ/E5Qucszz0Z9Li8dk3mQukavxB8=; b=TGgzGfIGZmM67qwBk8EaCcREb3rRKecq3OpXDaN4LhxIebLcCypRBeQ0eu iZOPhveeH+T9nZf3FREN2copVjlh570gd0dXr/GMw4YB6PKmhUMXe8gCHC80 Vs8tbvFg6G; Authentication-Results: sj-dkim-2; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: quaizar.vohra@gmail.com Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-01.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --------------080100020702070307050000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, folks: The revised version includes the following changes from the -00.txt version: o The Error Handling section has been enhanced, with the error conditions for the new attributes spelled out. o Several "SHOULD NOT" are changed to "MUST NOT". The diff is attached. Thanks. -- Enke -------- Original Message -------- Subject: I-D Action:draft-chen-rfc4893bis-01.txt Date: Mon, 2 Feb 2009 11:00:01 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Support for Four-octet AS Number Space Author(s) : Q. Vohra, E. Chen Filename : draft-chen-rfc4893bis-01.txt Pages : 11 Date : 2009-02-02 Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------080100020702070307050000 Content-Type: Message/External-body; name="draft-chen-rfc4893bis-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chen-rfc4893bis-01.txt" Content-Type: text/plain Content-ID: <2009-02-02105814.I-D@ietf.org> --------------080100020702070307050000 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------080100020702070307050000 Content-Type: text/plain; name="diff-00-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff-00-01.txt" *** draft-chen-rfc4893bis-00.txt Fri Jan 23 16:09:47 2009 --- draft-chen-rfc4893bis-01.txt Mon Feb 2 09:34:53 2009 *************** *** 147,158 **** To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH ! attribute. A NEW BGP speaker SHOULD NOT send these path segment ! types in the AS4_PATH attribute of an UPDATE message. A NEW BGP ! speaker that receives these path segment types in the AS4_PATH ! attribute of an UPDATE message MUST discard these path segments, ! adjust the relevant attribute fields accordingly, and continue ! processing the UPDATE message. Similarly, this document defines a new aggregator attribute called AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR --- 147,153 ---- To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH ! attribute, and MUST NOT be carried in an UPDATE message. Similarly, this document defines a new aggregator attribute called AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR *************** *** 198,208 **** peer, and MUST assume that these attributes in the updates received from the peer encode Autonomous System numbers as 4-octet entities. ! The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried ! in the UPDATE messages between NEW BGP peers. A NEW BGP speaker that ! receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE ! message from a NEW BGP speaker SHOULD discard these path attributes ! and continue processing the UPDATE message. 4.2. Interaction Between NEW and OLD BGP Speakers --- 198,208 ---- peer, and MUST assume that these attributes in the updates received from the peer encode Autonomous System numbers as 4-octet entities. ! The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried ! in an UPDATE message between NEW BGP speakers. A NEW BGP speaker ! that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute ! in an UPDATE message from another NEW BGP speaker MUST discard the ! path attribute and continue processing the UPDATE message. 4.2. Interaction Between NEW and OLD BGP Speakers *************** *** 225,231 **** AS numbers. The NEW speaker MUST also send the AS path information in the AS4_PATH attribute (encoded with 4-octet AS numbers), except for the case where the entire AS path information is composed of 2- ! octet AS numbers only. In this case, the NEW speaker SHOULD NOT send the AS4_PATH attribute. In the AS_PATH attribute encoded with 2-octet AS numbers, non- --- 225,231 ---- AS numbers. The NEW speaker MUST also send the AS path information in the AS4_PATH attribute (encoded with 4-octet AS numbers), except for the case where the entire AS path information is composed of 2- ! octet AS numbers only. In this case, the NEW speaker MUST NOT send the AS4_PATH attribute. In the AS_PATH attribute encoded with 2-octet AS numbers, non- *************** *** 264,270 **** value of the AS4_AGGREGATOR attribute, and sets the AS number field in the existing AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that if the AS number is 2-octets only, then the ! AS4_AGGREGATOR attribute SHOULD NOT be sent. 4.2.3. Processing Received Updates --- 264,270 ---- value of the AS4_AGGREGATOR attribute, and sets the AS number field in the existing AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that if the AS number is 2-octets only, then the ! AS4_AGGREGATOR attribute MUST NOT be sent. 4.2.3. Processing Received Updates *************** *** 372,390 **** As specified in [RFC1997], when the high-order two-octets of the community attribute is neither 0x0000 nor 0xffff, these two octets encode the Autonomous System number. Quite clearly this would not ! work for BGP speakers that use 4-octets Autonomous System numbers. Such BGP speakers should use the Four-octet AS Specific Extended Communities [AS-EXT-COM] instead. 6. Error Handling ! When a NEW BGP speaker encounters an error (other than the invalid ! confederation path segment types described previously) in parsing the ! AS4_PATH attribute or the AS4_AGGREGATOR attribute of an UPDATE ! message, the speaker MUST discard the attribute in error, and ! continue processing the UPDATE message. The error SHOULD be logged ! locally for analysis. 7. Transition --- 369,441 ---- As specified in [RFC1997], when the high-order two-octets of the community attribute is neither 0x0000 nor 0xffff, these two octets encode the Autonomous System number. Quite clearly this would not ! work for a NEW BGP speaker with a non-mappable 4-octet AS number. Such BGP speakers should use the Four-octet AS Specific Extended Communities [AS-EXT-COM] instead. 6. Error Handling ! The AS4_PATH attribute in an UPDATE message is considered malformed ! under the following conditions: ! ! - the attribute type appears more than once in the UPDATE ! message, or ! ! - the attribute is not marked "optional and transitive", or ! ! - the attribute length is inconsistent with the "Total Path ! Attribute Length" in the UPDATE message, or ! ! - the path segment length in the attribute is either zero, or ! is inconsistent with the attribute length, or ! ! - the path segment type in the attribute is not one of the ! types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE ! and AS_CONFED_SET. ! ! A NEW BGP speaker that receives a malformed AS4_PATH attribute in an ! UPDATE message from an OLD BGP speaker MUST discard the attribute, ! and continue processing the UPDATE message. The error SHOULD be ! logged locally for analysis. ! ! In addition, the path segment types AS_CONFED_SEQUENCE and ! AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH ! attribute, and MUST NOT be carried in an UPDATE message. A NEW BGP ! speaker that receives these path segment types in the AS4_PATH ! attribute of an UPDATE message from an OLD BGP speaker MUST discard ! these path segments, adjust the relevant attribute fields ! accordingly, and continue processing the UPDATE message. ! ! The AS4_AGGREGATOR attribute in an UPDATE message is considered ! malformed under the following conditions: ! ! - the attribute type appears more than once in the UPDATE ! message, or ! ! - the attribute is not marked "optional and transitive", or ! ! - the attribute length is of a value other than 8, or ! ! - the AS number in the attribute is zero, or ! ! - the BGP Identifier in the attribute is zero. ! ! A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute ! in an UPDATE message from an OLD BGP speaker MUST discard the ! attribute, and continue processing the UPDATE message. The error ! SHOULD be logged locally for analysis. 7. Transition --------------080100020702070307050000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --------------080100020702070307050000-- From wwwrun@core3.amsl.com Tue Feb 3 14:19:07 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A5BA03A6C53; Tue, 3 Feb 2009 14:19:07 -0800 (PST) To: roque@juniper.net, danny@arbor.net, nsheth@juniper.net, raszuk@juniper.net, bgreene@juniper.net, jared@puck.nether.net From: IETF Secretariat Message-Id: <20090203221907.A5BA03A6C53@core3.amsl.com> Date: Tue, 3 Feb 2009 14:19:07 -0800 (PST) X-Mailman-Approved-At: Tue, 03 Feb 2009 14:20:49 -0800 Cc: idr@ietf.org, yakov@juniper.net, dward@cisco.com, rcallon@juniper.net, shares@ghs.com, ipr-announce@ietf.org Subject: [Idr] Posting of IPR Disclosure X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:19:07 -0000 Dear Pedro Roque Marques, Danny McPherson, Nischal Sheth, Robert Raszuk, Barry Greene, Jared Mauch: An IPR disclosure that pertains to your Internet-Draft entitled "Dissemination of flow specification rules" (draft-ietf-idr-flow-spec) was submitted to the IETF Secretariat on 2009-02-03 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Test Company 's Statement about IPR related to draft-ietf-idr-flow-spec-05." The IETF Secretariat From rjs@eng.gxn.net Wed Feb 4 03:34:19 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1573A6B7B for ; Wed, 4 Feb 2009 03:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMYNVnToGgSu for ; Wed, 4 Feb 2009 03:34:17 -0800 (PST) Received: from mx01.eng.pipex.net (mx01.eng.pipex.net [212.241.168.204]) by core3.amsl.com (Postfix) with ESMTP id 1A47728C201 for ; Wed, 4 Feb 2009 03:34:16 -0800 (PST) Received: from bronze.eng.gxn.net (bronze.eng.gxn.net [212.241.168.68]) by mx01.eng.pipex.net (8.13.8/8.11.2) with ESMTP id n14BXq0Z021077; Wed, 4 Feb 2009 11:33:52 GMT X-Envelope-From: rjs@eng.gxn.net Received: (from rjs@localhost) by bronze.eng.gxn.net (8.13.1/8.13.1) id n14BXoUr019849; Wed, 4 Feb 2009 11:33:50 GMT X-Authentication-Warning: bronze.eng.gxn.net: rjs set sender to rjs@eng.gxn.net using -f Date: Wed, 4 Feb 2009 11:33:50 +0000 From: Rob Shakir To: Enke Chen Message-ID: <20090204113349.GF2227@bronze.eng.gxn.net> References: <4987469E.60207@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4987469E.60207@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mx01.eng.pipex.net [212.241.168.204]); Wed, 04 Feb 2009 11:33:52 +0000 (GMT) Cc: idr@ietf.org, quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-01.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:34:19 -0000 Enke, Please see comments in-line to this diff. > *** draft-chen-rfc4893bis-00.txt Fri Jan 23 16:09:47 2009 > --- draft-chen-rfc4893bis-01.txt Mon Feb 2 09:34:53 2009 > *************** > *** 147,158 **** > To prevent the possible propagation of confederation path segments > outside of a confederation, the path segment types AS_CONFED_SEQUENCE > and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH > ! attribute. A NEW BGP speaker SHOULD NOT send these path segment > ! types in the AS4_PATH attribute of an UPDATE message. A NEW BGP > ! speaker that receives these path segment types in the AS4_PATH > ! attribute of an UPDATE message MUST discard these path segments, > ! adjust the relevant attribute fields accordingly, and continue > ! processing the UPDATE message. > > Similarly, this document defines a new aggregator attribute called > AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR > --- 147,153 ---- > To prevent the possible propagation of confederation path segments > outside of a confederation, the path segment types AS_CONFED_SEQUENCE > and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH > ! attribute, and MUST NOT be carried in an UPDATE message. > > Similarly, this document defines a new aggregator attribute called > AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR > *************** This change seems to be reasonable -- the fact that this behaviour has been observed does not mean that we should become permissive of errors in the implementation. > *** 198,208 **** > peer, and MUST assume that these attributes in the updates received > from the peer encode Autonomous System numbers as 4-octet entities. > > ! The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried > ! in the UPDATE messages between NEW BGP peers. A NEW BGP speaker that > ! receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE > ! message from a NEW BGP speaker SHOULD discard these path attributes > ! and continue processing the UPDATE message. > > > 4.2. Interaction Between NEW and OLD BGP Speakers > --- 198,208 ---- > peer, and MUST assume that these attributes in the updates received > from the peer encode Autonomous System numbers as 4-octet entities. > > ! The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried > ! in an UPDATE message between NEW BGP speakers. A NEW BGP speaker > ! that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute > ! in an UPDATE message from another NEW BGP speaker MUST discard the > ! path attribute and continue processing the UPDATE message. > > > 4.2. Interaction Between NEW and OLD BGP Speakers > *************** This approach is problematic in my opinion. RFC 4271 defines how to handle errors in UPDATE messages: rfc4271> 6.3. UPDATE Message Error Handling rfc4271> rfc4271> All errors detected while processing the UPDATE message MUST be rfc4271> indicated by sending the NOTIFICATION message with the Error Code rfc4271> UPDATE Message Error. The error subcode elaborates on the specific rfc4271> nature of the error. It then goes on to say: rfc4271> If an optional attribute is recognized, then the value of this rfc4271> attribute MUST be checked. If an error is detected, the attribute rfc4271> MUST be discarded, and the Error Subcode MUST be set to Optional rfc4271> Attribute Error. In the new wording of your draft, this would then allow us to receive AS4_PATH or AS4_AGGREGATOR from a neighbour which which we have negotiated 4-byte ASN capabilities (and hence is a NEW BGP speaker). In this case, I don't see a problem with sending NOTIFICATION and tearign down the session to this neighbour -- my reading of rfc4271 would actually seem to suggest we MUST do this. The approach that you have suggested appears overly reactionary -- there must have been some thinking that led to invalid AS4_PATHs being responded to with a NOTIFICATION, why now does there appear to have been a shift towards being permissive of invalid routing information from a BGP speaker? What made implementations of the original RFC dangerous was the fact that we punished an OLD speaker for passing us attributes that it did not validate or parse, given that a NEW speaker should validate this information, why should we accept it? > 6. Error Handling > One error handling approach after we have discarded this attribute is stating in this RFC that any AS_TRANS that is observed in AS_PATH is assumed to be our own AS, unless we are able to replace it with data from AS4_PATH. As someone commented to me off-list, loops are very destructive, and we should try to avoid them at almost any cost -- if we assume AS_TRANS is us , then we don't 'punish' prefixes that are propagated with invalid data to us, but we do take measures to ensure that we are not causing a loop. However, there are of course some problems with doing this -- which I'd like to open for discussion on this list. If we take into account that features such as 'as-override' and 'set as-path prepend last-as N', when an OLD speaker manipulates the AS_PATH, then the AS4_PATH attribute is not updated. When we handle these manipulated AS_PATHs no 4-byte AS will be available to 'patch' out the added AS_TRANS. This is suboptimal behaviour, as we'll discard this UPDATE as a loop. This reverses the behaviour we saw originally (punishing an OLD speaker for a NEW speaker's error), since we attach a penalty to a prefix propagated by a NEW speaker due to a manipulation that an OLD speaker has made. >From my interpretation of the RFCs, the precedent that has been set is that when a neighbour hands us invalid attributes, we will send a NOTIFICATION. The root of the problems with rfc4893 are that we implemented this behaviour to an OLD speaker that, from its perspective, was propagating completely valid attributes. I would appreciate some feedback on whether rfc4893 should introduce 'permissive' behaviour, where invalid attributes are discarded, and we attempt to workaround the lack of them -- or whether we should still penalise the invalid attribute by treating this UPDATE as WITHDRAW. Please let me know if I've made any errors in this analysis -- I'd like to try and ensure that we're taking the best way forward with this RFC, and don't react to an observed issue by becoming overly permissive of badly implemented BGP speakers. Many thanks in advance for your comments. Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From john@jlc.net Wed Feb 4 06:54:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6603A6937 for ; Wed, 4 Feb 2009 06:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfQ7Zaxxaxw9 for ; Wed, 4 Feb 2009 06:54:24 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 1C1183A6AEA for ; Wed, 4 Feb 2009 06:54:24 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8206533C54; Wed, 4 Feb 2009 09:54:03 -0500 (EST) Date: Wed, 4 Feb 2009 09:54:03 -0500 From: John Leslie To: Rob Shakir Message-ID: <20090204145403.GT52653@verdi> References: <4987469E.60207@cisco.com> <20090204113349.GF2227@bronze.eng.gxn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090204113349.GF2227@bronze.eng.gxn.net> User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-01.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 14:54:25 -0000 Rob Shakir wrote: > >> 6. Error Handling >>... > > One error handling approach after we have discarded this attribute is > stating in this RFC that any AS_TRANS that is observed in AS_PATH is > assumed to be our own AS, unless we are able to replace it with data > from AS4_PATH. This is actually two different cases: 1) we have an ASN > 65535, so this indeed might _be_ a loop; 2) we don't have an ASN > 65535, but we don't trust other ASs to perform this loop-prevention algorithm. For either of these, treating AS_TRANS as matching our ASN is the only sure loop-prevention method. > As someone commented to me off-list, loops are very destructive, and > we should try to avoid them at almost any cost -- If a routing loop actually happens, packets must travel the loop until TTL is exhausted. TTL, alas, is set to 255 fairly often... > if we assume AS_TRANS is us , then we don't 'punish' prefixes that are > propagated with invalid data to us, but we do take measures to ensure > that we are not causing a loop. I'm not sure we're keeping a clear distinction between routes actually used propagated to a NEW speaker from an OLD speaker and AS4 information which the OLD speaker was totally unaware of. (If we were keeping such a clear distinction, it's hard to believe we would continue to insist upon blindly substituting the latter for the former.) > However, there are of course some problems with doing this -- which I'd > like to open for discussion on this list. If we take into account that > features such as 'as-override' and 'set as-path prepend last-as N', > when an OLD speaker manipulates the AS_PATH, then the AS4_PATH attribute > is not updated. Obviously true... > When we handle these manipulated AS_PATHs no 4-byte AS will be available > to 'patch' out the added AS_TRANS. This is suboptimal behaviour, as > we'll discard this UPDATE as a loop. There is an unavoidable tradeoff between the possibilities of looping vs. unreachability. :^( > This reverses the behaviour we saw originally (punishing an OLD speaker > for a NEW speaker's error), since we attach a penalty to a prefix > propagated by a NEW speaker due to a manipulation that an OLD speaker > has made. IMHO, doing this is better, because the problem can be detected a single hop after the manipulation done by the OLD speaker (assuming it has at least one NEW peer). At some point, OLD speakers need to be discouraged from doing such manipulations. > From my interpretation of the RFCs, the precedent that has been set > is that when a neighbour hands us invalid attributes, we will send > a NOTIFICATION. This never was a good idea for transitive attributes that the neighbor has made no attempt to validate. > The root of the problems with rfc4893 are that we implemented this > behaviour to an OLD speaker that, from its perspective, was propagating > completely valid attributes. Or, more exactly, propagating as _required_ by the spec. > I would appreciate some feedback on whether rfc4893 should introduce > 'permissive' behaviour, where invalid attributes are discarded, and > we attempt to workaround the lack of them -- or whether we should > still penalise the invalid attribute by treating this UPDATE as > WITHDRAW. I see it as inherently dangerous to discard an attribute and assume we can "workaround" its absence without possibly creating a loop. But the balancing act remains... If we believe the risk of loops to be negligible, we could reasonably concentrate on the risk of unreachability. For myself, I'm afraid I don't consider the risk of loops as "negligible". > Please let me know if I've made any errors in this analysis -- I believe Rob's analysis is correct. > I'd like to try and ensure that we're taking the best way forward with > this RFC, and don't react to an observed issue by becoming overly > permissive of badly implemented BGP speakers. I wouldn't even call them "badly implemented". Our observed problem probably stems from pre-4893 implementations which were correct when coded. _My_ biggest worry is that we end up with a 4893bis which is amenable to differing implementations -- and I'm seriously worried that we're heading in that direction. Left to myself, I'd step back and design a transition scheme from scratch, considering the tradeoff between looping and unreachability, before publishing a quick-fix. YMMV, of course... -- John Leslie From paul@jakma.org Mon Feb 9 10:22:23 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043553A68FF for ; Mon, 9 Feb 2009 10:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdAT10wR9XZj for ; Mon, 9 Feb 2009 10:22:22 -0800 (PST) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id A069F3A689B for ; Mon, 9 Feb 2009 10:22:20 -0800 (PST) Received: from melandri.gla.jakma.org (melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n19ILk5I006070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 18:21:52 GMT Date: Mon, 9 Feb 2009 18:21:45 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Rob Shakir In-Reply-To: <20090204113349.GF2227@bronze.eng.gxn.net> Message-ID: References: <4987469E.60207@cisco.com> <20090204113349.GF2227@bronze.eng.gxn.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Mon, 09 Feb 2009 18:21:54 +0000 (GMT) Cc: idr@ietf.org, quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-01.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:22:23 -0000 On Wed, 4 Feb 2009, Rob Shakir wrote: > One error handling approach after we have discarded this attribute > is stating in this RFC that any AS_TRANS that is observed in > AS_PATH is assumed to be our own AS, unless we are able to replace > it with data from AS4_PATH. As someone commented to me off-list, > loops are very destructive, and we should try to avoid them at > almost any cost -- if we assume AS_TRANS is us , then we don't > 'punish' prefixes that are propagated with invalid data to us, but > we do take measures to ensure that we are not causing a loop. This was suggested already. However it seems there is no need for this as, on any cycle, there should be at least one OLD speaker that will see its own, non-AS_TRANS, ASN and stop the loop. (See, e.g., emails from John Scudder). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Kilroe hic erat! From yakov@juniper.net Wed Feb 11 01:41:47 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B6928C15A for ; Wed, 11 Feb 2009 01:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbFE+WaQW9TK for ; Wed, 11 Feb 2009 01:41:46 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 697753A67B4 for ; Wed, 11 Feb 2009 01:41:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSZKdXtEAq77pGmiLGVckd2s+RP3uULyf@postini.com; Wed, 11 Feb 2009 01:41:51 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Wed, 11 Feb 2009 01:38:53 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 01:38:53 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 01:38:53 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 01:38:52 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1B9ceM34282 for ; Wed, 11 Feb 2009 01:38:41 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200902110938.n1B9ceM34282@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28018.1234345036.1@juniper.net> Date: Wed, 11 Feb 2009 01:38:28 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 11 Feb 2009 09:38:52.0890 (UTC) FILETIME=[8D016BA0:01C98C2C] Subject: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 09:41:47 -0000 Folks, Given that the draft just recently went through WG and IETF LC, if folks have a concern, they should voice it asap. Yakov. ------- Forwarded Message Date: Tue, 10 Feb 2009 17:12:54 -0800 From: IETF Secretariat To: roque@juniper.net, danny@arbor.net, nsheth@juniper.net, raszuk@juniper .net, bgreene@juniper.net, jared@puck.nether.net cc: rcallon@juniper.net, dward@cisco.com, idr@ietf.org, shares@ghs.com, yakov@juniper.net, ipr-announce@ietf.org Subject: Posting of IPR Disclosure Dear Pedro Roque Marques, Danny McPherson, Nischal Sheth, Robert Raszuk, Barry Greene, Jared Mauch: An IPR disclosure that pertains to your Internet-Draft entitled "Dissemination of flow specification rules" (draft-ietf-idr-flow-spec) was submitted to the IETF Secretariat on 2009-02-09 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Juniper's Statement of IPR related to draft-ietf-idr-flow-spec-03." The IETF Secretariat ------- End of Forwarded Message From narten@us.ibm.com Thu Feb 12 05:58:57 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756C428C12E for ; Thu, 12 Feb 2009 05:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXzZy5smMXPR for ; Thu, 12 Feb 2009 05:58:56 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 6E43F28C11D for ; Thu, 12 Feb 2009 05:58:56 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1CDvqFG030508 for ; Thu, 12 Feb 2009 06:57:52 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1CDww98199256 for ; Thu, 12 Feb 2009 06:59:00 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1CDwwDY016855 for ; Thu, 12 Feb 2009 06:58:58 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-228-230.mts.ibm.com [9.65.228.230]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1CDwvr5016776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 06:58:58 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n1CDwu13007684; Thu, 12 Feb 2009 08:58:56 -0500 Message-Id: <200902121358.n1CDwu13007684@cichlid.raleigh.ibm.com> To: Yakov Rekhter In-reply-to: <200902110938.n1B9ceM34282@magenta.juniper.net> References: <200902110938.n1B9ceM34282@magenta.juniper.net> Comments: In-reply-to Yakov Rekhter message dated "Wed, 11 Feb 2009 01:38:28 -0800." Date: Thu, 12 Feb 2009 08:58:56 -0500 From: Thomas Narten Cc: idr@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 13:58:57 -0000 FWIW, I believe that this document cannot and should not be advanced unless the WG explicitly goes on record as stating that even with the recent IPR disclosure, they still want to publish as a PS. Silence cannot be interpreted as approval. Thomas From john@jlc.net Thu Feb 12 06:30:33 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8AF3A6AA9; Thu, 12 Feb 2009 06:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo4yCu+TA1pB; Thu, 12 Feb 2009 06:30:32 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 950783A69B2; Thu, 12 Feb 2009 06:30:32 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id BAEB233C55; Thu, 12 Feb 2009 09:30:37 -0500 (EST) Date: Thu, 12 Feb 2009 09:30:37 -0500 From: John Leslie To: Thomas Narten Message-ID: <20090212143037.GW52653@verdi> References: <200902110938.n1B9ceM34282@magenta.juniper.net> <200902121358.n1CDwu13007684@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902121358.n1CDwu13007684@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.4.1i Cc: Yakov Rekhter , iesg@ietf.org, idr@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:30:33 -0000 Thomas Narten wrote: > > FWIW, I believe that this document cannot and should not be advanced > unless the WG explicitly goes on record as stating that even with the > recent IPR disclosure, they still want to publish as a PS. I wouldn't demand quite that much, but I must urge the IESG not to approve it _today_. The IPR disclosure clearly indicates that royalties might me charged; and I am unable to find the patent application on the patent office site. > Silence cannot be interpreted as approval. I agree. We have typically been dominated by corporations that will not find RAND to be a problem, but there are at least two "free" implementations of BGP in use that would be unable to pay royalties. If the WG chooses to say that the benefit exceeds that expense, we need to say so clearly and publicly. -- John Leslie From jmh@joelhalpern.com Thu Feb 12 06:56:35 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C281128C1D6; Thu, 12 Feb 2009 06:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6q+5IhgdqOK; Thu, 12 Feb 2009 06:56:35 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 03FC13A6B86; Thu, 12 Feb 2009 06:56:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CC3F14302CE; Thu, 12 Feb 2009 06:56:40 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-247.clppva.btas.verizon.net [71.161.52.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 020254302CD; Thu, 12 Feb 2009 06:56:39 -0800 (PST) Message-ID: <499438A6.60508@joelhalpern.com> Date: Thu, 12 Feb 2009 09:56:38 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Leslie References: <200902110938.n1B9ceM34282@magenta.juniper.net> <200902121358.n1CDwu13007684@cichlid.raleigh.ibm.com> <20090212143037.GW52653@verdi> In-Reply-To: <20090212143037.GW52653@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, iesg@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:56:35 -0000 THE WG should probably look at this. But it is hard to know whether this is worse than typical. And it does not appear to be a matter of "expense." The terms Juniper states are: 1) If you sue them, they reserve the right to sue you over infringing this patent 2) If there is something patented that is not "necessary for compliance with the standard" then they reserve the right to assert / license / control that. Based on this, the question is not one of expense, but one of applicability. Point 1 is clearly not a a problem or cost for the free community, and is a widely accepted condition in the commercial community. We have accepted many standards track documents with defensive patent claims on them. Point 2 is where the applicability issue comes in. I have seen lawyers argue that as long as there is some context way of implementing the spec that can be implemented without the claim they are asserting, then the claim is not "necessary for compliance with the specification. In that case, the reservation is very dangerous. Conversely, it is fairly reasonable for a company to say that if you as a commercial implementor are doing something way beyond what the spec describes, and their patent describes that, then they can come after you. That is what the game is about. (I say "fairly reasonable" to stay out of the protracted argument about what corporate patent policies should be.) (Of course, this is even harder to evaluate relative to filed but not yet granted patents, which can change before granting.) Yours, Joel John Leslie wrote: > Thomas Narten wrote: >> FWIW, I believe that this document cannot and should not be advanced >> unless the WG explicitly goes on record as stating that even with the >> recent IPR disclosure, they still want to publish as a PS. > > I wouldn't demand quite that much, but I must urge the IESG not to > approve it _today_. > > The IPR disclosure clearly indicates that royalties might me charged; > and I am unable to find the patent application on the patent office site. > >> Silence cannot be interpreted as approval. > > I agree. We have typically been dominated by corporations that will > not find RAND to be a problem, but there are at least two "free" > implementations of BGP in use that would be unable to pay royalties. > > If the WG chooses to say that the benefit exceeds that expense, > we need to say so clearly and publicly. > > -- > John Leslie > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jari.arkko@piuha.net Thu Feb 12 07:12:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90E83A69E4 for ; Thu, 12 Feb 2009 07:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0zLjXghbCYe for ; Thu, 12 Feb 2009 07:12:01 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C85523A68A1 for ; Thu, 12 Feb 2009 07:12:00 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7C190198712; Thu, 12 Feb 2009 17:12:05 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1C3571986EF; Thu, 12 Feb 2009 17:12:05 +0200 (EET) Message-ID: <49943BF7.3030300@piuha.net> Date: Thu, 12 Feb 2009 17:10:47 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Yakov Rekhter References: <200902110938.n1B9ceM34282@magenta.juniper.net> In-Reply-To: <200902110938.n1B9ceM34282@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: idr@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:12:01 -0000 The normal process is that the WG considers all aspects, technical and IPR, and makes a decision that they want to proceed. From my personal perspective the license conditions appear quite reasonable, should be OK even from open source point of view. But there is one word that troubled me a bit. Can we get anyone from Juniper to clarify whether "standard adopted by IETF" implies a standards track RFC, and NOT only full Standard (which might never be reached)? But in any case, particularly since the IPR declarations came in so late, I think it would be best if the WG made an official decision (new WGLC) about this issue. I believe there are a few technical discusses from the IESG review today, so you could handle that in parallel. Jari From jgs@juniper.net Thu Feb 12 07:27:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7583A69E4; Thu, 12 Feb 2009 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YbA8St9ZA4B; Thu, 12 Feb 2009 07:27:07 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 475E63A699C; Thu, 12 Feb 2009 07:27:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSZQ/xIzT4n1RZj7wTA8gxAMlXrLdP9EM@postini.com; Thu, 12 Feb 2009 07:27:13 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Feb 2009 07:25:13 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 07:25:13 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 07:25:13 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 07:25:13 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1CFPBM45986; Thu, 12 Feb 2009 07:25:12 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <8EF050A7-86CC-4A38-B91B-EC517505A4DA@juniper.net> From: "John G. Scudder" To: John Leslie In-Reply-To: <20090212143037.GW52653@verdi> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 10:25:11 -0500 References: <200902110938.n1B9ceM34282@magenta.juniper.net> <200902121358.n1CDwu13007684@cichlid.raleigh.ibm.com> <20090212143037.GW52653@verdi> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Feb 2009 15:25:13.0094 (UTC) FILETIME=[1962AA60:01C98D26] Cc: Yakov Rekhter , iesg@ietf.org, idr@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:27:08 -0000 On Feb 12, 2009, at 9:30 AM, John Leslie wrote: > The IPR disclosure clearly indicates that royalties might me > charged; There was an IPR disclosure that did say that. It's been retracted (and apologized for, but I'll do so again here and now on behalf of my employer: sorry!). The correct and current disclosure is the usual royalty-free, non-assert version. See https://datatracker.ietf.org/ipr/1088/ and http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-idr-flow-spec-03.txt for corroboration. (I assume you were referring to the first, erroneous disclosure. If you're referring to the non-assert or "not necessary for compliance" clauses, you'll find those in most IPR disclosures that have ever been made to the IETF by any company. IMO you can't ask for better than that without simply insisting that the IETF eschew IPR-encumbered standards completely. But that ship sailed a long time ago and is completely impractical besides.) > and I am unable to find the patent application on the patent office > site. The issued patent can be found easily. As for the applications, I've never had much luck with searching for them either in this case or any other. Seems like a USPTO issue though, not an IETF issue. > I agree. We have typically been dominated by corporations that will > not find RAND to be a problem, but there are at least two "free" > implementations of BGP in use that would be unable to pay royalties. Again, please note that the correct disclosure is royalty-free (though with the usual non-assert caveat, which probably is even less likely than usual to be invoked with respect to an open-source implementation). --John From jgs@juniper.net Thu Feb 12 07:39:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE2A3A67F0 for ; Thu, 12 Feb 2009 07:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2h8nsKNMc64 for ; Thu, 12 Feb 2009 07:39:07 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 753963A67E4 for ; Thu, 12 Feb 2009 07:39:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSZRCnmQkRllaqs8YfBaBIuXqOpt29gv2@postini.com; Thu, 12 Feb 2009 07:39:13 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Feb 2009 07:36:27 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 07:36:27 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 07:36:27 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 07:36:26 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1CFaPM51200; Thu, 12 Feb 2009 07:36:25 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: Jari Arkko In-Reply-To: <49943BF7.3030300@piuha.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 10:36:25 -0500 References: <200902110938.n1B9ceM34282@magenta.juniper.net> <49943BF7.3030300@piuha.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Feb 2009 15:36:26.0565 (UTC) FILETIME=[AACE2F50:01C98D27] Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:39:08 -0000 On Feb 12, 2009, at 10:10 AM, Jari Arkko wrote: > Can we get anyone from Juniper to clarify whether "standard adopted > by IETF" implies a standards track RFC, and NOT only full Standard > (which might never be reached)? I'll request clarification from Juniper Legal and get back to you (or have someone do so). However, I can tell you that Juniper has no hidden agenda at all with respect to IPR disclosures, so I'll personally be quite shocked if the answer isn't "any standards track RFC". Note that the IPR disclosure lists a contact at Juniper Legal. Anyone with concerns is certainly welcome to use it, that's why it was published. Regards, --John From jari.arkko@piuha.net Thu Feb 12 07:49:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6993A6848 for ; Thu, 12 Feb 2009 07:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLUh1cZEbfDV for ; Thu, 12 Feb 2009 07:49:52 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [193.234.218.130]) by core3.amsl.com (Postfix) with ESMTP id 724F23A6827 for ; Thu, 12 Feb 2009 07:49:52 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 8CC7619876C; Thu, 12 Feb 2009 17:49:21 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 3E9E61986EF; Thu, 12 Feb 2009 17:49:21 +0200 (EET) Message-ID: <499444B3.1020306@piuha.net> Date: Thu, 12 Feb 2009 17:48:03 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "John G. Scudder" References: <200902110938.n1B9ceM34282@magenta.juniper.net> <49943BF7.3030300@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:49:53 -0000 John, > I'll request clarification from Juniper Legal and get back to you (or > have someone do so). Great - thanks. > However, I can tell you that Juniper has no hidden agenda at all with > respect to IPR disclosures, so I'll personally be quite shocked if the > answer isn't "any standards track RFC". Right, and didn't want to imply you had any either. I only raised because my company had in the past used the same terms, and gotten some people confused. Jari From jgs@juniper.net Thu Feb 12 09:03:14 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780D53A687C for ; Thu, 12 Feb 2009 09:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe5E2Wm3XL7w for ; Thu, 12 Feb 2009 09:03:13 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id B8C2F3A677D for ; Thu, 12 Feb 2009 09:03:13 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSZRWUetgp3Z7YPDDxgWjnx/JtrW4ldxm@postini.com; Thu, 12 Feb 2009 09:03:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Feb 2009 09:00:27 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 09:00:27 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 09:00:27 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 09:00:26 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1CH0NM90333; Thu, 12 Feb 2009 09:00:24 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: Jari Arkko In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 12:00:22 -0500 References: <200902110938.n1B9ceM34282@magenta.juniper.net> <49943BF7.3030300@piuha.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Feb 2009 17:00:26.0672 (UTC) FILETIME=[66F17B00:01C98D33] Cc: Yakov Rekhter , idr List Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:03:14 -0000 On Feb 12, 2009, at 10:36 AM, John G. Scudder wrote: > On Feb 12, 2009, at 10:10 AM, Jari Arkko wrote: >> Can we get anyone from Juniper to clarify whether "standard adopted >> by IETF" implies a standards track RFC, and NOT only full Standard >> (which might never be reached)? > > I'll request clarification from Juniper Legal and get back to you > (or have someone do so). However, I can tell you that Juniper has > no hidden agenda at all with respect to IPR disclosures, so I'll > personally be quite shocked if the answer isn't "any standards track > RFC". This is confirmed per Juniper Legal: we intended to include any standards track RFC. Regards, --John From jari.arkko@piuha.net Thu Feb 12 09:11:36 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3773A6983 for ; Thu, 12 Feb 2009 09:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOsLV8RzTmLW for ; Thu, 12 Feb 2009 09:11:35 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7AA123A685F for ; Thu, 12 Feb 2009 09:11:35 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 88CC819876F; Thu, 12 Feb 2009 19:11:39 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 3845A1986E4; Thu, 12 Feb 2009 19:11:39 +0200 (EET) Message-ID: <499457FD.8040800@piuha.net> Date: Thu, 12 Feb 2009 19:10:21 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "John G. Scudder" References: <200902110938.n1B9ceM34282@magenta.juniper.net> <49943BF7.3030300@piuha.net> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Yakov Rekhter , idr List Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:11:36 -0000 Great, thanks for the super fast response! So: I have no problem with the work going forward. Jari From jgs@juniper.net Thu Feb 12 09:52:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716C63A6917; Thu, 12 Feb 2009 09:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VmcnFdvk3dX; Thu, 12 Feb 2009 09:52:24 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 203093A6809; Thu, 12 Feb 2009 09:52:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSZRh3KtgTM2enz0+dO3Mq1ZVRRZTxCVs@postini.com; Thu, 12 Feb 2009 09:52:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 12 Feb 2009 09:49:39 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 09:49:39 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 09:49:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 09:49:38 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1CHnbM11552; Thu, 12 Feb 2009 09:49:37 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: "Joel M. Halpern" In-Reply-To: <499438A6.60508@joelhalpern.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 12:49:36 -0500 References: <200902110938.n1B9ceM34282@magenta.juniper.net> <200902121358.n1CDwu13007684@cichlid.raleigh.ibm.com> <20090212143037.GW52653@verdi> <499438A6.60508@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Feb 2009 17:49:38.0347 (UTC) FILETIME=[464757B0:01C98D3A] Cc: idr@ietf.org, John Leslie , iesg@ietf.org Subject: Re: [Idr] Posting of IPR Disclosure for draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:52:25 -0000 One further point: On Feb 12, 2009, at 9:56 AM, Joel M. Halpern wrote: > Point 2 is where the applicability issue comes in. I have seen > lawyers argue that as long as there is some context way of > implementing the spec that can be implemented without the claim they > are asserting, then the claim is not "necessary for compliance with > the specification. In that case, the reservation is very dangerous. My previous comment that Juniper has no hidden agenda with respect to IPR disclosures is the real answer to this. However, I'll also point out that even if a company *was* hatching the dastardly plan you describe above, they would seem awfully foolish to publish a notice that " is the owner of US Patent relating to the subject matter of ". If I were a judge (we can all thank our lucky stars I'm not) I would look askance if the company then tried to tell me that patent is *not* necessary for compliance with . ("Tell me, counselor -- what *did* you mean by 'relating to the subject matter of'"?) Regards, --John From yakov@juniper.net Sun Feb 15 11:21:32 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD673A6AFD for ; Sun, 15 Feb 2009 11:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Elef0WLAam8J for ; Sun, 15 Feb 2009 11:21:31 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id A4E633A6AFA for ; Sun, 15 Feb 2009 11:21:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSZhrRJCFFwtxksBuHwImE8t+1zgGm/ut@postini.com; Sun, 15 Feb 2009 11:21:41 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 15 Feb 2009 11:19:23 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Feb 2009 11:19:23 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Feb 2009 11:19:23 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Feb 2009 11:19:22 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1FJJMM55159 for ; Sun, 15 Feb 2009 11:19:22 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200902151919.n1FJJMM55159@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95060.1234725562.1@juniper.net> Date: Sun, 15 Feb 2009 11:19:22 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 15 Feb 2009 19:19:22.0767 (UTC) FILETIME=[4EE1E1F0:01C98FA2] Subject: [Idr] IETF 74 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 19:21:32 -0000 Folks, Its about time to start thinking about agenda items for the next IETF. Please forward any IDR agenda items you might have to Sue and myself. The deadline is March 15, 2009. And if you plan to make a presentation, please also keep in mind the rule "no Internet Draft - no time slot". Sue & Yakov. From yakov@juniper.net Tue Feb 17 16:32:19 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBFD53A69EC for ; Tue, 17 Feb 2009 16:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE42QT5znx5R for ; Tue, 17 Feb 2009 16:32:19 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 07C853A680E for ; Tue, 17 Feb 2009 16:32:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSZtXHiq+UwRL507XW7Kzj5P6UuvT7ZuD@postini.com; Tue, 17 Feb 2009 16:32:31 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 17 Feb 2009 16:28:04 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 16:28:04 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 16:28:04 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 16:28:04 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1I0S4M39842 for ; Tue, 17 Feb 2009 16:28:04 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200902180028.n1I0S4M39842@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20094.1234916884.1@juniper.net> Date: Tue, 17 Feb 2009 16:28:04 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 18 Feb 2009 00:28:04.0237 (UTC) FILETIME=[C35D6BD0:01C9915F] Subject: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:32:19 -0000 Folks, I'd like to explain a bit of the confusion surrounding the IPR disclosure issue. On 12/23/2008 Juniper disclosed IPR on the flow-spec draft (https://datatracker.ietf.org/ipr/1052/), but it contained an incorrect "terms" section. The disclosure was removed at Juniper's request and resubmitted on 02/09/2009 with the proper "terms" section. Unfortunately, Juniper's legal team released a number of IPR disclosures on or about 12/23/2008 and had to remove and correct all of them so, the sudden flurry of activity may have been worrying to some. You may have seen many corrected IPR disclosures on the IETF's IPR webpage (https://datatracker.ietf.org/ipr/about/) and more are to come. Juniper intended no harm or malice by these actions and Juniper is working to make certain that disclosures are made in a more timely manner. I hope this explanation helps you understand the recent IPR disclosure activity. Yakov. From yakov@juniper.net Tue Feb 17 16:33:38 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E57628C135 for ; Tue, 17 Feb 2009 16:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv0dLOxtCwlC for ; Tue, 17 Feb 2009 16:33:37 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id CCDC028C131 for ; Tue, 17 Feb 2009 16:33:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSZtXbd/8lBM9NbqR0W9O2i5kZnPjQOed@postini.com; Tue, 17 Feb 2009 16:33:49 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 17 Feb 2009 16:30:45 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 16:30:44 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 16:30:44 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 16:30:44 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1I0UiM41233 for ; Tue, 17 Feb 2009 16:30:44 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200902180030.n1I0UiM41233@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20332.1234917044.1@juniper.net> Date: Tue, 17 Feb 2009 16:30:44 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 18 Feb 2009 00:30:44.0110 (UTC) FILETIME=[22A81AE0:01C99160] Subject: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:33:38 -0000 Folks, Given the recent IPR disclosure (https://datatracker.ietf.org/ipr/1088) associated with the flow-spec draft (http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-05.txt ) we are going to re-WG-LC the document and rerun the publication process. The deadline for comments is 3/2/2009. Sue & Yakov. From root@core3.amsl.com Wed Feb 18 18:30:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A31043A6A06; Wed, 18 Feb 2009 18:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090219023001.A31043A6A06@core3.amsl.com> Date: Wed, 18 Feb 2009 18:30:01 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp4-mibv2-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 02:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version Author(s) : J. Haas Filename : draft-ietf-idr-bgp4-mibv2-09.txt Pages : 45 Date : 2009-02-18 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-idr-bgp4-mibv2-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-18182645.I-D@ietf.org> --NextPart-- From santiago@crfreenet.org Thu Feb 19 08:35:43 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9E33A6BD8 for ; Thu, 19 Feb 2009 08:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iihsJg0ZIWpH for ; Thu, 19 Feb 2009 08:35:41 -0800 (PST) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:18::1]) by core3.amsl.com (Postfix) with ESMTP id 2DBFA3A6BD7 for ; Thu, 19 Feb 2009 08:35:41 -0800 (PST) Received: from localhost (feanor.newtown.crfreenet.org [81.92.145.132]) by mail.crfreenet.org (Postfix) with ESMTP id DBD6310635 for ; Thu, 19 Feb 2009 17:35:50 +0100 (CET) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1LaBxS-0001UY-LJ for idr@ietf.org; Thu, 19 Feb 2009 17:41:06 +0100 Date: Thu, 19 Feb 2009 17:41:06 +0100 From: Ondrej Zajicek To: idr@ietf.org Message-ID: <20090219164106.GA4095@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 4.0 (Etch) User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Idr] Interpretation of multiprotocol extensions for IPv4 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 16:40:17 -0000 Hello We found that some widespread BGP-4 implementations (Cisco and Quagga) reject BGP session when the other side sends OPEN message that contains capability advertisement (RFC 3392) without multiprotocol extension capability (RFC 2858). When multiprotocol extension capability with IPv4 AFI is included, the session established and IPv4 prefixes are exchanged, but using traditional way (does not use MP_REACH_NLRI). That leads to question about interpretation of multiprotocol extension capability with IPv4 AFI (MEP_IPv4). I can imagine two possible interpretations: 1) MEP_IPv4 should be advertised iff router accepts IPv4 prefixes in MP_REACH_NLRI and MP_UNREACH_NLRI extended attributes. 2) MEP_IPv4 should be advertised when router accepts IPv4 prefixes in traditional NLRI. The first interpretation is IMHO what RFC 2858 currently says. If this is correct then Cisco and Quagga behavior is unreasonable. The second interpretation is consistent with Cisco and Quagga behavior and might be more useful (as it allows to specify that router does not accept traditional NLRI, for example IPv6 only router). What interpretation should be considered correct? -- Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From root@core3.amsl.com Sat Feb 21 20:30:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 40A7C3A6829; Sat, 21 Feb 2009 20:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090222043001.40A7C3A6829@core3.amsl.com> Date: Sat, 21 Feb 2009 20:30:01 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp4-mibv2-tc-mib-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 04:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : J. Haas Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-00.txt Pages : 6 Date : 2009-02-18 This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-idr-bgp4-mibv2-tc-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-21202739.I-D@ietf.org> --NextPart-- From jhaas@slice.pfrc.org Sat Feb 21 20:50:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641B53A68A1 for ; Sat, 21 Feb 2009 20:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT1sSi3hbYio for ; Sat, 21 Feb 2009 20:50:26 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id AC91C3A6878 for ; Sat, 21 Feb 2009 20:50:26 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id A4F58244052; Sun, 22 Feb 2009 04:50:42 +0000 (UTC) Date: Sat, 21 Feb 2009 23:50:42 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20090222045041.GA26110@slice> References: <20090222043001.40A7C3A6829@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090222043001.40A7C3A6829@core3.amsl.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Subject: [Idr] BGP MIBv2 updates X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 04:50:27 -0000 This draft, and the related draft-ietf-idr-bgp4-mibv2-09, address all open issues from IETF-73. In order to encourage implementation of these drafts, I'd like to request an early allocation from the mib-2 space for these MIBs. On Sat, Feb 21, 2009 at 08:30:01PM -0800, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > > Title : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) > Author(s) : J. Haas > Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-00.txt > Pages : 6 > Date : 2009-02-18 -- Jeff From jhaas@slice.pfrc.org Mon Feb 23 07:23:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D713A68E8 for ; Mon, 23 Feb 2009 07:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLqiMNf42BZ6 for ; Mon, 23 Feb 2009 07:23:52 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 8B3A23A6877 for ; Mon, 23 Feb 2009 07:23:52 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3F896244050; Mon, 23 Feb 2009 15:24:09 +0000 (UTC) Date: Mon, 23 Feb 2009 10:24:09 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20090223152409.GA9207@slice> References: <20090222043001.40A7C3A6829@core3.amsl.com> <20090222045041.GA26110@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090222045041.GA26110@slice> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Subject: Re: [Idr] BGP MIBv2 updates X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:23:53 -0000 I was requested to be a little more clear here. On Sat, Feb 21, 2009 at 11:50:42PM -0500, Jeffrey Haas wrote: > In order to encourage implementation of these drafts, I'd like to request an > early allocation from the mib-2 space for these MIBs. I'd like to request an early allocation from mib-2 for the following SNMP MODULE-IDENTITYs. bgp4V2, published in draft-ietf-idr-bgp4-mibv2-09. bgp4V2TC, published in draft-ietf-idr-bgp4-mibv2-tc-mib-00. From jhaas@slice.pfrc.org Mon Feb 23 07:28:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24493A68C2 for ; Mon, 23 Feb 2009 07:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aprMqCOa8nw6 for ; Mon, 23 Feb 2009 07:28:15 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 05E5D3A6877 for ; Mon, 23 Feb 2009 07:28:15 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0DDE7244050; Mon, 23 Feb 2009 15:28:31 +0000 (UTC) Date: Mon, 23 Feb 2009 10:28:31 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20090223152829.GB9207@slice> References: <20090222043001.40A7C3A6829@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090222043001.40A7C3A6829@core3.amsl.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Subject: [Idr] BGP TC MIB X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:28:15 -0000 On Sat, Feb 21, 2009 at 08:30:01PM -0800, Internet-Drafts@ietf.org wrote: > Title : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) This MIB defines the textual conventions meant to be generic to BGP related MIBs. At this point, it has textual conventions specifically for RFC 4760 style AFI and SAFI. The only enumerations in this currently are for ipv4/ipv6:unicast,multicast and mpls. These are the afi/safi sets likely to occur in the BGPv2 MIB. Given that these are meant to be general purpose textual conventions, I'd like to request feedback from BGP protocol implementors that use other AFI/SAFI entries: What else should be added here? -- Jeff From yakov@juniper.net Mon Feb 23 07:36:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0A328C12C for ; Mon, 23 Feb 2009 07:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAp22ZQ6U0DB for ; Mon, 23 Feb 2009 07:36:15 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 08D653A6AFD for ; Mon, 23 Feb 2009 07:36:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSaLCgV1ZvVVKABYkuD/K/aSYRn4HmOln@postini.com; Mon, 23 Feb 2009 07:36:33 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 23 Feb 2009 07:34:28 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 07:34:28 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 07:34:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 07:34:28 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n1NFYSM53254 for ; Mon, 23 Feb 2009 07:34:28 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200902231534.n1NFYSM53254@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59648.1235403268.1@juniper.net> Date: Mon, 23 Feb 2009 07:34:28 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 23 Feb 2009 15:34:28.0330 (UTC) FILETIME=[36E034A0:01C995CC] Subject: Re: [Idr] BGP MIBv2 updates X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:36:15 -0000 Folks, Please comment on the attached request. The deadline for comments is March 9, 2009. Yakov. ------- Forwarded Message Date: Mon, 23 Feb 2009 10:24:09 -0500 From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] BGP MIBv2 updates I was requested to be a little more clear here. On Sat, Feb 21, 2009 at 11:50:42PM -0500, Jeffrey Haas wrote: > In order to encourage implementation of these drafts, I'd like to request an > early allocation from the mib-2 space for these MIBs. I'd like to request an early allocation from mib-2 for the following SNMP MODULE-IDENTITYs. bgp4V2, published in draft-ietf-idr-bgp4-mibv2-09. bgp4V2TC, published in draft-ietf-idr-bgp4-mibv2-tc-mib-00. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From cfinss@dial.pipex.com Tue Feb 24 04:25:35 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088E83A682D for ; Tue, 24 Feb 2009 04:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMLFyZz68PGO for ; Tue, 24 Feb 2009 04:25:31 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id ECC623A6A21 for ; Tue, 24 Feb 2009 04:25:30 -0800 (PST) X-Trace: 78925207/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.158/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.158 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAOx1o0k+vBGe/2dsb2JhbACDQ0GKEMhWB4QKBg X-IronPort-AV: E=Sophos;i="4.38,259,1233532800"; d="scan'208";a="78925207" X-IP-Direction: IN Received: from 1cust158.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.158]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Feb 2009 12:25:47 +0000 Message-ID: <014b01c99672$7438fde0$0601a8c0@allison> From: "tom.petch" To: , "Yakov Rekhter" References: <200902231534.n1NFYSM53254@magenta.juniper.net> Date: Tue, 24 Feb 2009 12:24:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Idr] BGP MIBv2 updates X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 12:25:35 -0000 ----- Original Message ----- From: "Yakov Rekhter" To: Sent: Monday, February 23, 2009 4:34 PM Subject: Re: [Idr] BGP MIBv2 updates > Folks, > > Please comment on the attached request. The deadline for comments > is March 9, 2009. > I think that this is a sensible idea (and yes I understood it the first time:-). I take it that Yakov's e-mail is in pursuance to RFC4020 3.1 3). A question; RFC4181 discourages this approach, preferring experimental (which I think inappropriate here). Has the IESG approved early allocation for MIB Modules as per RFC4020 2 a)? This topic came up on another list recently and there was no mention of early allocation. I see no mention of approval on the IANA website. Tom Petch > Yakov. > ------- Forwarded Message > > Date: Mon, 23 Feb 2009 10:24:09 -0500 > From: Jeffrey Haas > To: idr@ietf.org > Subject: Re: [Idr] BGP MIBv2 updates > > I was requested to be a little more clear here. > > On Sat, Feb 21, 2009 at 11:50:42PM -0500, Jeffrey Haas wrote: > > In order to encourage implementation of these drafts, I'd like to request an > > early allocation from the mib-2 space for these MIBs. > > I'd like to request an early allocation from mib-2 for the following > SNMP MODULE-IDENTITYs. > > > bgp4V2, published in draft-ietf-idr-bgp4-mibv2-09. > bgp4V2TC, published in draft-ietf-idr-bgp4-mibv2-tc-mib-00. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jhaas@slice.pfrc.org Tue Feb 24 07:57:31 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004783A69BB for ; Tue, 24 Feb 2009 07:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZZE7hwWc1lq for ; Tue, 24 Feb 2009 07:57:30 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 5AC3F3A69A6 for ; Tue, 24 Feb 2009 07:57:30 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E6212244050; Tue, 24 Feb 2009 15:57:47 +0000 (UTC) Date: Tue, 24 Feb 2009 10:57:47 -0500 From: Jeffrey Haas To: "tom.petch" Message-ID: <20090224155747.GA23230@slice> References: <200902231534.n1NFYSM53254@magenta.juniper.net> <014b01c99672$7438fde0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014b01c99672$7438fde0$0601a8c0@allison> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Cc: idr@ietf.org Subject: Re: [Idr] BGP MIBv2 updates X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:57:31 -0000 On Tue, Feb 24, 2009 at 12:24:18PM +0100, tom.petch wrote: > A question; RFC4181 discourages this approach, preferring experimental (which I > think inappropriate here). The exact same RFC contains a clause which is one of the motives for not doing experimental. : Experience has shown that it is impractical to move objects from one : subtree to another once those objects have seen large-scale use in an : operational environment. Hence any object that is targeted for : deployment in an operational environment MUST NOT be registered under : the experimental subtree, irrespective of the standardization status : of that object. Unless I misunderstood our MIB doctor, I was encouraged to not request experimental allocation. -- Jeff From cfinss@dial.pipex.com Tue Feb 24 11:18:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1227B3A6B63 for ; Tue, 24 Feb 2009 11:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YheldxRAywMF for ; Tue, 24 Feb 2009 11:18:41 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 067A23A6920 for ; Tue, 24 Feb 2009 11:18:40 -0800 (PST) X-Trace: 79087997/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.174/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.174 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAC7Xo0k+vBGu/2dsb2JhbACDQ4pRyk4HhAoG X-IronPort-AV: E=Sophos;i="4.38,260,1233532800"; d="scan'208";a="79087997" X-IP-Direction: IN Received: from 1cust174.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.174]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Feb 2009 19:18:25 +0000 Message-ID: <006601c996ac$1a382c00$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Haas" References: <200902231534.n1NFYSM53254@magenta.juniper.net> <014b01c99672$7438fde0$0601a8c0@allison> <20090224155747.GA23230@slice> Date: Tue, 24 Feb 2009 19:16:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: idr Subject: Re: [Idr] BGP MIBv2 updates X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:18:42 -0000 ----- Original Message ----- From: "Jeffrey Haas" To: "tom.petch" Cc: Sent: Tuesday, February 24, 2009 4:57 PM Subject: Re: [Idr] BGP MIBv2 updates > On Tue, Feb 24, 2009 at 12:24:18PM +0100, tom.petch wrote: > > A question; RFC4181 discourages this approach, preferring experimental (which I > > think inappropriate here). > > The exact same RFC contains a clause which is one of the motives for not > doing experimental. > > : Experience has shown that it is impractical to move objects from one > : subtree to another once those objects have seen large-scale use in an > : operational environment. Hence any object that is targeted for > : deployment in an operational environment MUST NOT be registered under > : the experimental subtree, irrespective of the standardization status > : of that object. > > Unless I misunderstood our MIB doctor, I was encouraged to not request > experimental allocation. > Yes, I agree which then leaves - waiting until the RFC is approved - or getting IESG permission for early allocation. I presume this thread is part of the latter strategy but I am unclear how successful this is, like I see no mention on the IANA website of this being an IESG approved category (but that could just be me struggling to find anything on the IANA website:-( Tom Petch > > -- Jeff From wwwrun@core3.amsl.com Tue Feb 24 14:19:36 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CBD8D28C115; Tue, 24 Feb 2009 14:19:36 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090224221936.CBD8D28C115@core3.amsl.com> Date: Tue, 24 Feb 2009 14:19:36 -0800 (PST) Cc: yakov@juniper.net, shares@ghs.com, idr@ietf.org Subject: [Idr] WG Action: RECHARTER: Inter-Domain Routing (idr) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:19:36 -0000 The charter of the Inter-Domain Routing (idr) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Inter-Domain Routing (idr) -------------------------------------------------- Last Modified: 2009-02-12 Current Status: Active Working Group Chairs: Susan Hares [shares@ghs.com] Yakov Rekhter [yakov@juniper.net] Routing Area Director(s): Ross Callon [rcallon@juniper.net] David Ward [dward@cisco.com] Routing Area Advisor: David Ward [dward@cisco.com] Technical Advisor(s): Randall Atkinson [rja@extremenetworks.com] Sharon Chisholm [schishol@nortel.com] Mailing Lists: General Discussion: idr@ietf.org To Subscribe: idr-request@ietf.org In Body: subscribe idr-post Archive: http://www.ietf.org/mail-archive/web/idr/index.html Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC 1771] capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 and IP version 6. The working group will continue to work on improving the scalability of BGP. The current tasks of the WG are limited to: - Revise and clarify the base BGP4 document (RFC 1771). Note that RFC 1771 no longer documents existing practice and one goal of the update is document existing practice. Determine whether the document can be advanced as full Standard or needs to recycle at Proposed or Draft Standard. - Submit updated base BGP4 MIB to accompany the revised base BGP4 document. Once these tasks are finished (means WG consensus, WG Last Call, AD Review, IETF Last Call, and IESG approval for publication), work will progress on the following: - Review and Evaluate Existing RFCs on AS Confederations and Route Reflection. If changes are needed, create and advance revisions. - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement as Draft Standard. - Progress BGP Extended Communities along standards track. - Extend BGP to support a 4-byte AS number, develop plan for transitioning to usage of 4-byte AS numbers. Advance support for a 4-byte AS numbers along standards track. - Produce BGP MIB v2 that includes support for AS Confederations, Route Reflection, Communities, Multi-Protocol BGP, BGP Extended Communities, support for 4-byte AS numbers. - Progress along the IETF standards track a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. Currently defined in draft-ietf-idr-route-filter-03.txt. - Progress along standards track an Outbound Router Filter (ORF) type for BGP, that can be used to perform aspath based route filtering. The ORF-type will support aspath based route filtering as well as regular expression based matching for address groups. Currently defined in draft-ietf-idr-aspath-orf-00.txt. - Progress a BGP Graceful Restart mechanism along standards track. - Progress Subcodes for BGP Cease Notification Message along standards track. - Progress AS-wide Unique BGP Identifier for BGP-4 along standards track. - Progress Dynamic Capability for BGP-4 along standards track. - Progress Flow Specification rules along standards track. Tasks for this working group are limited to those listed above; new items to be added to the charter must be approved by the IESG. Goals and Milestones: Done Submit to BGP Capability Advertisement to the IESG Done Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done Submit BGP4 MIB to IESG as a Proposed Standard Done Submit BGP4 document to IESG as a Draft Standard Done Submit Extended Communities draft to IESG as a Proposed Standard Done Submit BGP Graceful Restart to IESG as a Proposed Standard Done Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done Submit 4-byte AS ID to IESG as a Proposed Standard Done Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2008 Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard Mar 2008 Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2008 Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2008 Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard From jhaas@slice.pfrc.org Tue Feb 24 16:27:19 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51C13A6B44 for ; Tue, 24 Feb 2009 16:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9cJeTvJKgzb for ; Tue, 24 Feb 2009 16:27:19 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id E79D63A6925 for ; Tue, 24 Feb 2009 16:27:18 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 38003244200; Wed, 25 Feb 2009 00:27:36 +0000 (UTC) Date: Tue, 24 Feb 2009 19:27:36 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20090225002735.GA27931@slice> References: <20090224221936.CBD8D28C115@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224221936.CBD8D28C115@core3.amsl.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Subject: Re: [Idr] WG Action: RECHARTER: Inter-Domain Routing (idr) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 00:27:19 -0000 Yakov and Sue, I would propose a modification to the IDR charter with respect to the BGP MIBv2 work item. On Tue, Feb 24, 2009 at 02:19:36PM -0800, IESG Secretary wrote: > - Produce BGP MIB v2 that includes support for AS Confederations, > Route Reflection, Communities, Multi-Protocol BGP, BGP Extended > Communities, support for 4-byte AS numbers. Per the IDR and OPS general session discussions at IETF-73, I believe this item needs to be modified: - Produce a BGP MIB v2 that includes support for AS Confederations, Multi-Protocol BGP and suppport for 4-byte AS numbers. Data structures for communities and extended communities, route reflection have proven problematic to represent in SMIv2 in an operationally useful fashion. The stance of the OPS group with respect to these less than useful opaque OCTET STRING representations has changed and it is no longer recommended that we try to fit these within a MIB. (That said, if we decide that such a representation is worthwhile, an extension MIB can be crafted in the future. I have ceased working on a draft that roughly covered such a representation for BGP communities.) I believe that the currently published BGP MIBv2 internet-drafts completes the work in the suggested update above. -- Jeff From jcucchiara@mindspring.com Wed Feb 25 05:45:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B546C28C19B for ; Wed, 25 Feb 2009 05:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ohrFT-vQOAx for ; Wed, 25 Feb 2009 05:45:01 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E169F28C13F for ; Wed, 25 Feb 2009 05:45:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RhunthbfppB3hVEPPYS6jJTLLMznmmZdOaE+2S8d63w5+N9WIe0c8rpRZzhDizTg; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.112.219] (helo=JoanPC) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LcK4e-0005td-TC; Wed, 25 Feb 2009 08:45:21 -0500 Message-ID: <015c01c9974f$4d407410$6401a8c0@JoanPC> From: "Joan Cucchiara" To: "Jeffrey Haas" , References: <20090222043001.40A7C3A6829@core3.amsl.com><20090222045041.GA26110@slice> <20090223152409.GA9207@slice> Date: Wed, 25 Feb 2009 08:45:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265490232586cda6d51d5a8b95323abe648d3122699149cfe979350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.112.219 Subject: Re: [Idr] BGP MIBv2 updates X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:45:01 -0000 Hi Jeff, Are the objects' names going to changed for the drafts which receive an early mib-2 subid allocation vs. the RFC versions? The reason that I'm asking is that not all the tools identify objects using their OIDs, many use the objects' names. If the objects' names remain the same between the draft MIB Modules and the RFC MIB Modules, then this could cause problems. Thanks, -Joan ----- Original Message ----- From: "Jeffrey Haas" To: Sent: Monday, February 23, 2009 10:24 AM Subject: Re: [Idr] BGP MIBv2 updates >I was requested to be a little more clear here. > > On Sat, Feb 21, 2009 at 11:50:42PM -0500, Jeffrey Haas wrote: >> In order to encourage implementation of these drafts, I'd like to request >> an >> early allocation from the mib-2 space for these MIBs. > > I'd like to request an early allocation from mib-2 for the following > SNMP MODULE-IDENTITYs. > > > bgp4V2, published in draft-ietf-idr-bgp4-mibv2-09. > bgp4V2TC, published in draft-ietf-idr-bgp4-mibv2-tc-mib-00. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rfc-editor@rfc-editor.org Wed Feb 25 15:31:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D3928C28C; Wed, 25 Feb 2009 15:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.738 X-Spam-Level: X-Spam-Status: No, score=-16.738 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abddnNa+Dk0W; Wed, 25 Feb 2009 15:31:52 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 5394828C280; Wed, 25 Feb 2009 15:31:52 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 0C387233EAA; Wed, 25 Feb 2009 15:31:18 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090225233118.0C387233EAA@bosco.isi.edu> Date: Wed, 25 Feb 2009 15:31:18 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 5492 on Capabilities Advertisement with BGP-4 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:31:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5492 Title: Capabilities Advertisement with BGP-4 Author: J. Scudder, R. Chandra Status: Standards Track Date: February 2009 Mailbox: jgs@juniper.net, rchandra@sonoasystems.com Pages: 7 Characters: 13581 Obsoletes: RFC3392 I-D Tag: draft-ietf-idr-rfc3392bis-05.txt URL: http://www.rfc-editor.org/rfc/rfc5492.txt This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. [STANDARDS TRACK] This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute