[Idr] [IANA #1436671] Re: Early review: draft-ietf-idr-rfc4360-bis-01 (IETF 124)

[Amanda Baber via RT <[e-mail]>]

Hi Jeff,

> > On Oct 30, 2025, at 7:43 PM, Amanda Baber via RT <iana-
> > [e-mail]> wrote:
> > 4) There might be an issue related to this paragraph, which is
> > carried over from RFC 4360: “The value allocated for a Regular Type
> > MUST NOT be reused as the value of the high-order octet when
> > allocating an Extended Type. The value of the high-order octet
> > allocated for an Extended Type MUST NOT be reused when allocating a
> > Regular Type.”
> >
> > The potential problem is that values can be assigned via the First
> > Come First Served registration procedure, but those values don’t
> > receive any kind of review by anyone outside of IANA, and IANA’s
> > Operations team isn’t equipped to make this determination. Should the
> > First Come First Served procedure be changed to a lightweight Expert
> > Review, with guidance to the expert that they only need to check for
> > this? Or do the ranges of values made available in the registries'
> > "Registration Procedure" fields already guarantee that this won’t
> > happen?
> >
> 
> In principle, we can likely craft instructions IANA can carry out with
> regard to this restriction.  Simply put, the "type" field, if defined
> as "regular" MUST NOT permit sub-type fields and therefore child
> registries.  As of this time, several such registrations are present
> in the extended community registry:
> 
> https://www.iana.org/assignments/bgp-extended-communities/bgp-
> extended-communities.xhtml
> 
> Consider the examples of "QoS marking", "CoS capability" and others.

OK, I wasn't sure what this paragraph was referring to, but now I see. It looks like with "QoS marking," we've assigned 0x04 in a registry that only allows assignments from the 0x00-0x3f, 0x80-0x82, and 0x90-0xbf ranges, and we've assigned 0x44 from a registry that only allows assignments from 0x40-0x7f and 0xd0-0xff. So RFC 7153 already guaranteed that there won't be any overlap when it set up the rules for the BGP Transitive Extended Community Types and BGP Non-Transitive Extended Community Types registries.

I wonder if it might not be confusing to say "The value allocated for a Regular Type MUST NOT be reused as the value of the high-order octet when allocating an Extended Type. The value of the high-order octet allocated for an Extended Type MUST NOT be reused when allocating a Regular Type" when the registries already don't allow this to happen.

> Is it IANA's recommendation to attempt to create additional guidance
> about this relationship or would it be IANA's preference for the
> "light weight review"? If the light weight review, is there current
> boilerplate normative text we should consider adding to the IANA
> considerations to cover this?  I note that IANA tends to run FCFS
> reservations for this registry by the IDR chairs anyway.

We actually just bring those to the IDR chairs when someone's asking for a non-sequential value (which probably does cover a large percentage of those requests). 

I think that if it is indeed that case that the registries don't allow IANA those overlapping assignments, we don't need any guidance, and it would in fact be better to make it clear that it won't happen than to warn against it. I initially thought I must've misunderstood the action it was warning against because I was looking for an action it would be possible to take. 

thanks,
Amanda