Re: [Idr] [Technical Errata Reported] RFC4271 (5001)

<bruno.decraene@orange.com> Wed, 19 April 2017 18:45 UTC

Return-Path: <bruno.decraene@orange.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 CA3A2129C1B for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 11:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NSs2ese9dE94 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 11:45:42 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55176129C08 for <idr@ietf.org>; Wed, 19 Apr 2017 11:45:37 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id B4F0620450; Wed, 19 Apr 2017 20:45:35 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 8A7B91A0059; Wed, 19 Apr 2017 20:45:35 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 20:45:35 +0200
From: <bruno.decraene@orange.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "John G. Scudder" <jgs@juniper.net>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Technical Errata Reported] RFC4271 (5001)
Thread-Index: AQHSuTQcHT9js/KsJUeWRsw9RvAV8aHNDA4A///0uKA=
Date: Wed, 19 Apr 2017 18:45:34 +0000
Message-ID: <17818_1492627535_58F7B04F_17818_5514_1_53C29892C857584299CBF5D05346208A31CBDD15@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <20170419174042.7AA36B814E4@rfc-editor.org> <DCAC4E8F-A609-4DCB-BADB-23434A6F0EAC@cisco.com>
In-Reply-To: <DCAC4E8F-A609-4DCB-BADB-23434A6F0EAC@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jDF2XMX9d3Yp2VLXV8uyKRyUOMo>
Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (5001)
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 18:45:50 -0000

Alvaro, John, all

I may have one comment. Please see inline. 


> From Alvaro Retana (aretana)  > Sent: Wednesday, April 19, 2017 8:01 PM
> 
 > [Cut the distribution.]
 > 
 > idr WG:
 > 
 > I think this report is a lot clearer than the other one John filed (#5000), so I am going to
 > mark this one as “Hold for Document Update” [1].
 > 
 > Just because this report is related to the use of “MAY NOT” I will wait until we resolve the
 > other one just in case.
 > 
 > Thanks!
 > 
 > Alvaro.
 > 
 > [1] https://www.ietf.org/iesg/statement/errata-processing.html
 > 
 > 
 > 
 > On 4/19/17, 1:40 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=5001
 > 
 > --------------------------------------
 > Type: Technical
 > Reported by: John Scudder <jgs@juniper.net>
 > 
 > Section: 5
 > 
 > Original Text
 > -------------
 >    BGP implementations MUST recognize all well-known attributes.  Some
 >    of these attributes are mandatory and MUST be included in every
 >    UPDATE message that contains NLRI.  Others are discretionary and MAY
 >    or MAY NOT be sent in a particular UPDATE message.
 > 
 > 
 > Corrected Text
 > --------------
 >    BGP implementations MUST recognize all well-known attributes.  Some
 >    of these attributes are mandatory and MUST be included in every
 >    UPDATE message that contains NLRI.  Others are discretionary and
 >    sending them in a particular UPDATE message is OPTIONAL.

IMHO, OPTIONAL may not be what was intended.
As per RFC 2119 " the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item."
 
Here, I think that the original intention was to say that the attribute MAY be sent if appropriate and MAY be omitted if appropriate. IOW, it is _not_ REQUIRED to always send it.

As an example, quickly parsing RFC 4171, it does not seem to indicate whether the LOCAL_PREF attribute is mandatory or discretionary. But given that it is well-known, as per §5, it can only be mandatory or discretionary. Given that it usually does not appear in EBGP session, I would argue that it is not mandatory, hence discretionary. But I don't think that we could say that sending the attribute LOCAL_PREF is OPTIONAL given that RFC 4271 mandates its use in IBGP (plus not sending it on some IBGP sessions would create forwarding loops).

I may propose the follow text: Others are discretionary and may or may not be sent in a particular UPDATE message
Or: Others are discretionary and are not required to be sent in all UPDATE message

--Bruno

 > 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". In context, it is unlikely the
 > reader would be at risk of misinterpreting the text, but nonetheless it's a misuse of RFC
 > 2119 terminology and difficult to parse if reading closely.
 > 
 > (The replacement text was suggested by Eric Rosen; thanks.)
 > 
 > 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.