BGP Extended Community Registries Update
draft-ietf-idr-bgp-ext-com-registry-05

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.

Francesca

Thank you to Daniel Migault for the SECDIR review.

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.

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.