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

From: RFC Errata System <[email-masked]>
Date: Wed, 19 Apr 2017 10:37:11 -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=5000

--------------------------------------
Type: Technical
Reported by: John Scudder <[email-masked]>

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 19 Apr 2017 17:56:12 +0000

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

Section: 9.1.1

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

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

Notes
-----

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

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Apr 2017 11:23:42 +0100

> 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.
[...]
> b. s/MAY NOT/MUST NOT

this.

Nick

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Apr 2017 14:59:40 +0100

Sorry, but no!

OLD
   Others are discretionary and MAY
   or MAY NOT be sent in a particular UPDATE message.
NEW
   Others are discretionary and MAY
   be sent in a particular UPDATE message.
END

The use of MAY implies the not case.

"MAY or MUST NOT" is entirely ambiguous since "MUST NOT" means
never/forbidden/death-by-vampire so saying "or MUST NOT" is like saying "You
must never, ever, eat lithium disulfide, except when you do."

Adrian

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Nick Hilliard
> Sent: 20 April 2017 11:24
> To: Alvaro Retana (aretana)
> Cc: [email-masked]
> Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (5000)
> 
> > 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.
> [...]
> > b. s/MAY NOT/MUST NOT
> 
> this.
> 
> Nick
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Tony Li <[email-masked]>
Date: Thu, 20 Apr 2017 08:22:09 -0700

> b. s/MAY NOT/MUST NOT

Unequivocally.

Tony

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 20 Apr 2017 20:53:17 +0000

I agree.

If it's ineligible to be considered, it's a contradiction to consider it anyway.

"may" means to have permission to do something.
It is ok if you do that thing and ok if you do not.
"may not" means you do not have permission.
It is not ok to do it.

To me, the meaning is clear as it stands.
However, if "MUST NOT" is clearer to some, then let's make it clear.

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Thursday, April 20, 2017 8:22 AM
> To: Alvaro Retana (aretana) <[email-masked]>
> Cc: [email-masked]

---

From: t.petch <[email-masked]>
Date: Fri, 21 Apr 2017 18:44:19 +0100

----- Original Message -----
From: "Alvaro Retana (aretana)" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 19, 2017 6:56 PM

> 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.
> I will wait at least a week before proceeding.

Looking back, RFC1771 made no mention of ineligible routes as a result
of applying policy.

draft-ietf-idr-bgp4-18.txt has essentially the current wording but with
'may not' as lower case.

Jeff Haas then made a Last Call comment that magic words should be
capitalised and
draft-ietf-idr-bgp4-19.txt
dutifully capitalised 'MAY NOT'.  This is one of the items in
'IssuesList #2' identifying where capitalisation should or should not
happen.

Interesting, the AD review contains, a propos of 9.1.1
"So, AFAIK, the major implementations do not follow this step
(calculating the degree of preference, and then announcing). Instead,
implementations allow setting the LOCAL_PREF value locally, which is
taken into consideration during the best path selection, and is also
reannounced further."

My take was that the consensus of the WG was 'may not'  but then I
thought to look at RFC4276 which says

"3.38.  Phase 1: Calculation of Degree of Preference / Section 9.1.1
       [RFC4271]

   3.38.191.  Ineligible Degree of Preference

       Functionality/Description: The route MAY NOT serve as an input
       to the next phase of route selection

       RFC2119: MAY NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y"

If Alcatel, Cisco, Laurel and NextHop are all for it, who can be against
it?

Tom Petch

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Apr 2017 16:55:11 -0400

[...]
> b. s/MAY NOT/MUST NOT

b.  Because "THOU SHALT NOT" isn't appropriate 2119 at this time.

-- Jeff