Summary: Needs 3 more YES or NO OBJECTION positions to pass.
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.
Thank you to Daniel Migault for the SECDIR review.