Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962)

From: Job Snijders <[email-masked]>
Date: Thu, 9 Mar 2017 18:03:45 +0100

On Thu, Mar 09, 2017 at 07:21:56AM -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC8092, "BGP Large
> Communities Attribute".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=8092&eid=4962
> 
> --------------------------------------
> Type: Editorial
> 
> Section: 3
> 
> Original Text
> -------------
>    Duplicate BGP Large Community values MUST NOT be transmitted. A
>    receiving speaker MUST silently remove redundant BGP Large
>    Community values from a BGP Large Community attribute.
> 
> Corrected Text
> --------------
>    Duplicate BGP Large Community values MUST NOT be transmitted. A
>    receiving speaker MUST silently remove redundant BGP Large
>    Community values from a BGP Large Communities attribute.

I suggest to reject this errata. The name of the BGP Path Attribute is
singular, namely "LARGE_COMMUNITY" (see IANA's "Border Gateway Protocol
(BGP) Parameters" registry for "BGP Path Attributes")

There somewhat is a lack of semantic precision on when to use
"community" and when to use "communities", but there is no other
commonly accepted jargon for what we're talking about in IETF creole
language. In this sense RFC 8092 was aligned with RFC 1997. Sorry for
the confusion, but we didn't see a way around it.

If you are an implementer, feel free to reach out to me off list, I'd be
happy to help clarify, confirm your understanding of the specification
and perhaps help with interop testing.

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 9 Mar 2017 20:20:55 +0000

I agree.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
> Sent: Thursday, March 09, 2017 9:04 AM
> To: RFC Errata System <[email-masked]>; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962)
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 9 Mar 2017 22:02:46 +0000

[Took the RFC Editor off.]

Job:

Hi!

I think this repot is correct, trivial, but correct.

The name of the code assigned by IANA is in fact singular (LARGE_COMMUNITY), but the error below is the name of the attribute (not the code point) in the document.  

Note that the attribute is named “BGP Large Communities Attribute” in Section 3 (not “BGP Large Community attribute”).  In fact, the phrase “BGP Large Communities Attribute” is used throughout the text (13 times!), except for the instance below (and a 2 more in Section 7).

So…I’ll mark this report as “Hold for Document Update”, which means that if this RFC is ever updated it should correct the name of the attribute.

Thanks!

Alvaro.

On 3/9/17, 12:03 PM, "Job Snijders" <[email-masked]> wrote:

---

From: RFC Errata System <[email-masked]>
Date: Thu, 9 Mar 2017 07:21:56 -0800 (PST)

The following errata report has been submitted for RFC8092,
"BGP Large Communities Attribute".

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <[email-masked]>

Section: 3

Original Text
-------------
   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove redundant BGP Large Community
   values from a BGP Large Community attribute.

Corrected Text
--------------
   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove redundant BGP Large Community
   values from a BGP Large Communities attribute.

Notes
-----
Typo

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. 

--------------------------------------
RFC8092 (draft-ietf-idr-large-community-12)
--------------------------------------
Title               : BGP Large Communities Attribute
Publication Date    : February 2017
Author(s)           : J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard
Category            : PROPOSED STANDARD
Source              : Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Ignas Bagdonas <[email-masked]>
Date: Thu, 9 Mar 2017 22:35:16 +0000

Hi there,

If the intention of the errata is to address the handling of duplicated 
large community attributes (i.e., multiple type 32 attributes present in 
UPDATE message) then it does not seem to be right. RFC7606 does not 
allow to have more than one meaningful attribute of the same type in a 
single UPDATE message, therefore the literal interpretation of "BGP 
Large Communities" attribute does not apply as only the first such 
attribute gets interpreted and all subsequent ones get ignored. RFC8092 
has both singular and plural form of term "large community" values used 
in different contexts, referring to either a single 12 octet large 
community value or to a whole large communities attribute.

Ignas

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 10 Mar 2017 14:04:25 -0500

That's neither the intent (AFAICT) or the effect (for sure) of the erratum. The sole change proposed is to change "Community" to "Communities" in one instance of the name of the attribute, which as Alvaro points out just harmonizes the text with 13 other occurrences in the RFC.

I'm not so sure I agree with Alvaro that the case for the change is open-and-shut -- although he's right there are various other occurrences, there are also two other occurrences of the singular "Community" in the security section. If we're actually going to pick this nit, shouldn't the erratum cover all of them? Although in one case, changing to the plural would make the text exceedingly awkward.

I for one would support letting sleeping dogs lie, but whatever.

--John

> On Mar 9, 2017, at 5:35 PM, Ignas Bagdonas <[email-masked]> wrote:
> 
> Hi there,
> 
> If the intention of the errata is to address the handling of duplicated large community attributes (i.e., multiple type 32 attributes present in UPDATE message) then it does not seem to be right. RFC7606 does not allow to have more than one meaningful attribute of the same type in a single UPDATE message, therefore the literal interpretation of "BGP Large Communities" attribute does not apply as only the first such attribute gets interpreted and all subsequent ones get ignored. RFC8092 has both singular and plural form of term "large community" values used in different contexts, referring to either a single 12 octet large community value or to a whole large communities attribute.
> 
> 
> Ignas
> 
>

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Mar 2017 20:36:41 +0000

John G. Scudder wrote:
> I'm not so sure I agree with Alvaro that the case for the change is
> open-and-shut -- although he's right there are various other
> occurrences, there are also two other occurrences of the singular
> "Community" in the security section. If we're actually going to pick
> this nit, shouldn't the erratum cover all of them? Although in one
> case, changing to the plural would make the text exceedingly
> awkward.

"Community" vs "communities" was discussed at length during the
authorship process, and the term "language torture" was used in relation
to this specific point.  The root problem is that 1997 conflated the two
terms and we're left with an ambiguity about which term means what.

> I for one would support letting sleeping dogs lie, but whatever.

Please let's do this; the meaning is clear.  If there is a future
revision, it can be changed.

Nick