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

[<[e-mail]>]

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" <[e-mail]> 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 <[e-mail]>
 > 
 > 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
 > [e-mail]
 > 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.