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