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

From: RFC Errata System <[email-masked]>
Date: Wed, 19 Apr 2017 10:40:42 -0700 (PDT)

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 <[email-masked]>

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.

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 19 Apr 2017 18:00:39 +0000

[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" <[email-masked]> wrote:

Section: 5

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: <[email-masked]>
Date: Wed, 19 Apr 2017 18:45:34 +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].
 > 

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.
 > 
 > _______________________________________________
 > Idr mailing list
 > [email-masked]
 > 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.

---

From: <[email-masked]>
Date: Thu, 20 Apr 2017 07:24:33 +0000

> From: [email-masked]  > Sent: Wednesday, April 19, 2017 8:46 PM
> 
 > Alvaro, John, all
 > 

While the original text is about "well-known" attributes, which in BGP means mandatory to implement. i.e. the opposite of RFC 2119 "OPTIONAL" meaning.

--Bruno
 
 > 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).
 > 
 > ______________________________________________________________________
 > ___________________________________________________
 >

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 21 Apr 2017 10:33:45 -0400

> 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 mand…

In short: there is no good fit between the RFC 4271 concept of "discretionary" and any RFC 2119 keyword at all. Agreed. (Actually there is not even a good match between the RFC 4271 concept of "discretionary" and the plain-English definition of "discretionary", more's the pity.)

> Or: Others are discretionary and are not required to be sent in all UPDATE message

I would be OK with either of these options, or with simply truncating the sentence: "Others are discretionary." (It's clear from context that they aren't required to be sent with every update, the previous sentence being the "exception that proves the rule".)

Thanks for the feedback.

--John