Re: [Idr] [Technical Errata Reported] RFC4271 (5000)
"Acee Lindem (acee)" <acee@cisco.com> Wed, 19 April 2017 19:32 UTC
Return-Path: <acee@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531C8128C83 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 12:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3OqSoKhfBOC for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 12:32:21 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFED1293DA for <idr@ietf.org>; Wed, 19 Apr 2017 12:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6188; q=dns/txt; s=iport; t=1492630339; x=1493839939; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=UPpJ2EuCMx3FYzUOxInh2dioBJJspsF1iqif5wI6EiE=; b=D6dQ13SBMzjP5gjdBmQb9RFmKjll3sXSye1B3NwtLTPobQ1Ned64MyHt EuXxHx19gjNCTuV8+1P2UJenAJCmPeO31gIBmmtjQ8rQjSBJnv9M/qG/C j0G91G8y5vutPXFN0vaOt/KlnNYiFjTlzjljtcGG4TyQgO931XADlxGjA 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AdAQDHuvdY/4UNJK1CGhkBAQEBAQEBAQEBAQcBAQEBAYNUYYELB4NgihWnRYIPIQuFeByDaj8YAQIBAQEBAQEBayiFFgYBASEROh0BCBoCJgIEJQsVEgQBEooZDjGqGYImiyMBAQEBAQEBAwEBAQEBAQEhgQuHJYIPgQqBPIFcgT+DBoJfBYkzEYgOi10BiXaJBYIAhTGKG5QQAR84FXBjFRoqhGYMEIFjdQETh0qBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.37,222,1488844800"; d="scan'208";a="234965814"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2017 19:32:18 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3JJWIE6027958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <idr@ietf.org>; Wed, 19 Apr 2017 19:32:18 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 15:32:17 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 19 Apr 2017 15:32:17 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (5000)
Thread-Index: AQHSuUOnFLbpf9gM10yNeUjw7zuw+Q==
Date: Wed, 19 Apr 2017 19:32:17 +0000
Message-ID: <D51D32F9.A965E%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F45ADCFD237AB04D9243F392AC4FF039@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0mXbZNznT1way7NkyAl-QubaBH8>
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (5000)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 19:32:25 -0000
Hi Alvaro, I would vote for John’s suggested option b. As John stated, this disambiguates the statement in the context of RFC 2119’s definition of “MAY”. From an implementation standpoint, I would see any other interpretation as a bug. Thanks, Acee On 4/19/17, 1:56 PM, "Idr on behalf of Alvaro Retana (aretana)" <idr-bounces@ietf.org on behalf of aretana@cisco.com> wrote: >[Cutting the distribution a little.] > >[John: thanks for filing this report.] > >idr WG: > >As you know, changes to rfc4271 should be handled with care. And this >case is no exception. > >Even if “MAY NOT” is not an rfc2119 keyword as “MAY”, “MUST NOT”, and >others are, it doesn’t give me a great feeling to change it for one that >is – among other things because the meaning of “MAY” and “MUST” is so >different. Of course, making me feel good is not the purpose of rfc2119… >;-) > >Having said that, it is important that rfc4271 faithfully represent what >the WG intended. In this case, even though John didn’t say it >explicitly, I would agree with him in considering that implementers may >have already interpreted the text with the intent to not use the routes >further. > >I would like to get input from the WG as to the best way to handle this >report. I would specially like to hear from implementers, but all input >is welcome. > >The options are: > >a. s/MAY NOT/may not >b. s/MAY NOT/MUST NOT >c. Rejecting the report. >d. Something else… > >I will wait at least a week before proceeding. > >Thanks! > >Alvaro. > > > >On 4/19/17, 1:37 PM, "RFC Errata System" <rfc-editor@rfc-editor.org> >wrote: > >The following errata report has been submitted for RFC4271, >"A Border Gateway Protocol 4 (BGP-4)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=5000 > >-------------------------------------- >Type: Technical >Reported by: John Scudder <jgs@juniper.net> > >Section: 9.1.1 > >Original Text >------------- > If the route is learned from an external peer, then the local BGP > speaker computes the degree of preference based on preconfigured > policy information. If the return value indicates the route is > ineligible, the route MAY NOT serve as an input to the next phase > of route selection; otherwise, the return value MUST be used as > the LOCAL_PREF value in any IBGP readvertisement. > > >Corrected Text >-------------- > If the route is learned from an external peer, then the local BGP > speaker computes the degree of preference based on preconfigured > policy information. If the return value indicates the route is > ineligible, the route MUST NOT serve as an input to the next phase > of route selection; otherwise, the return value MUST be used as > the LOCAL_PREF value in any IBGP readvertisement. > > >Notes >----- >The original text uses "MAY NOT" capitalized as if it were an RFC 2119 >keyword. However, RFC 2119 does not have any defined meaning for "MAY >NOT". If a reader were to interpret this text as suggesting it is >optional -- meaning, in effect, "the route MAY serve as an input to the >next phase of route selection" -- that would be wrong and potentially >problematic. > >The minimal correction would be to use lower-case "may not", which makes >the proper meaning reasonably clear. However, the English construct "may >not" is notoriously ambiguous, therefore the proposed correction is "MUST >NOT". > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC4271 (draft-ietf-idr-bgp4-26) >-------------------------------------- >Title : A Border Gateway Protocol 4 (BGP-4) >Publication Date : January 2006 >Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. >Category : DRAFT STANDARD >Source : Inter-Domain Routing >Area : Routing >Stream : IETF >Verifying Party : IESG > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… Alvaro Retana (aretana)
- [Idr] [Technical Errata Reported] RFC4271 (5000) RFC Errata System
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… Acee Lindem (acee)
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… bruno.decraene
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… Nick Hilliard
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… Adrian Farrel
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… Tony Li
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… Jakob Heitz (jheitz)
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… t.petch
- Re: [Idr] [Technical Errata Reported] RFC4271 (50… Jeffrey Haas