BGP Extended Community Registries Update

Summary: Has enough positions to pass.

Alvaro Retana Yes

Benjamin Kaduk No Objection

Comment (2021-11-27)
Section 2

Should we also ask IANA to update the entry for the Unassigned range
starting at 0x0c in the "BGP Transitive Extended Community Types"?  It
currently shows as "0x0c-0x7f  Unassigned", but 0x40-0x7f are not
controlled by this (transitive) registry, and are rather in the
non-transitive EC types registry.

Section 5.2

I would probably put RFC 8955 as normative now that we're Updating it,
but it's a pretty fine hair to split.

Erik Kline No Objection

Francesca Palombini No Objection

Comment (2021-11-29)
Thank you for the work on this document.

I agree with Ben that it would be good to write something about the "0x0c-0x7f	Unassigned" range: I would suggest to split that into the 0x0c-0x3f Unassigned and 0x40-0x7f Reserved (with a pointer to the BGP Non-Transitive Extended Community Types registry). And then, to be thorough, it would be good to do the same type of split in the BGP Non-Transitive Extended Community Types registry.

I understand this was not the meaning of this document (hence the non-blocking comment), but since we are fixing things, I believe this would be an improvement to the current registries.


John Scudder No Objection

Lars Eggert No Objection

Martin Duke (was Discuss) No Objection

Comment (2021-11-22 for -03)
Alvaro assures me that the plan is to follow what I described in my DISCUSS, so I am removing that DISCUSS.

Original text:
I'm having trouble seeing how we got here; this registry architecture is hard to understand, and past actions appear to violate RFC 3692.

1. RFC7153 designated 0x80-0x8f as experimental and then immediately defines 0x80 as the gateway to a further subregistry of FCFS/IETF review codepoints. This does not appear to be "Reserved for Experimental Use" in the RFC 3692 sense, in that it is not meant to be used only by explicit experiments. (It's a standards track document).

2. RFC8955 compounds it by taking another 2 (of 15 remaining!) experimental codepoints in a standards-track document, for a similar purpose.

I agree with this draft's reclassification of the 3 codepoints, as it recognizes reality that they are apparently no longer safe for RFC 3692 experiments. But I would also like to verify that this behavior will not continue: future standards-track allocations, including those pointing to more subtypes ("Part 4", etc), will draw from the FCFS range, not Experimental.

Furthermore, experiments (with a draft or not) that use one of these experimental codepoints should be reassigned a FCFS codepoint if they move to Standards track.

Martin Vigoureux (was Discuss) No Objection

Murray Kucherawy No Objection

Robert Wilton No Objection

Roman Danyliw No Objection

Comment (2021-11-28)
No email
send info
Thank you to Daniel Migault for the SECDIR review.

Zaheduzzaman Sarker No Objection

Éric Vyncke Abstain

Comment (2021-12-01)
Thank you for the work put into this document, which probably addresses incoherent decision made in the past. So, thank you Christoph and IDR WG for fixing it.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). 

Special thanks to Susan Hares for the shepherd's write-up including the section about the WG consensus.

While I am not aware of the history about the use of those "experimental" code points and while I am aware that changing the code points in running code is an impossible endeavour, I wonder how those code points were used in production networks (my guess) while keeping the status of 'experimental'. I.e., the code points 0x81 and 0x82 are noted as 'experimental' but RFC 8955 is standard track. I am balloting ABSTAIN as I miss the history.

***Bottom line for IANA/IESG: what can we learn from this apparent "mess" (I am afraid that my limited English vocabulary is unable to find a more positive word)?***



In "The primary use for those types and sub-type registries is non experimental" should a "now" be inserted before the "non" ?

I also wonder why "0x80-0x82 | First Come First Served" since this document confirms the allocation ? What am I missing here ?

Warren Kumari No Record