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

 > -----Original Message-----
 > From: Acee Lindem (acee)  > Sent: Wednesday, April 19, 2017 9:32 PM
> 
 > Hi Alvaro,
 > 
 > I would vote for John’s suggested option b. 

+1

--Bruno

"ineligible" does not seem ambiguous

> 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
 > 
 > _______________________________________________
 > 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.