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

[Nat Kao <[e-mail]>]

Hi, Amanda.

These issues will be tracked by:
https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/14
https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/15
https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/16
https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/17
https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/18

Many Thanks!
Nat


On Fri, Oct 31, 2025 at 7:43 AM Amanda Baber via RT <[e-mail]>
wrote:

> Dear Authors (cc: idr WG),
>
> Before the IETF meeting, we check working group agendas for documents with
> IANA-related issues. We have notes about this document:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc4360-bis-01
>
> 1) The BGP Transitive Extended Community Types registry currently has
> these registration procedures:
>
> Range Registration Procedures Note
> 0x00-0x3f First Come First Served
> 0x80-0x82 First Come First Served see [RFC9184]
> 0x83-0x8f Reserved for Experimental Use see [RFC3692]
>
> This document consolidates the last two:
>
> 0x80-0x8F First Come First Served or Experimental Use (see [RFC3692] and
> [RFC9184])
>
> This is problematic. If these registration procedures aren't separated, we
> could end up assigning values that people were using for experimental
> purposes. Can Experimental Use continue to have its own separate range?
>
> 2) RFC 4360 is a reference for “EXTENDED COMMUNITIES” in the BGP Path
> Attributes registry at https://www.iana.org/assignments/bgp-parameters.
> Because this document is obsoleting that one, it needs to tell us whether
> to replace that reference. (References are typically replaced.)
>
> Alternatively, if it’s correct that both that reference and the other
> references to RFC 4360 at
> https://www.iana.org/assignments/bgp-extended-communities should be
> replaced, the section could simply state up front that all references to
> RFC 4360 in the IANA registries will be replaced with references to this
> document.
>
> 3) Other issues stem from the fact that this document states that IANA
> will make assignments or create registries that were actually made by RFC
> 7153, not RFC 4360. Because the document doesn’t mention that it’s
> obsoleting RFC 7153, it’s not clear whether this document should replace
> those references to RFC 7153 or be listed as an additional reference.
>
> While it might make sense to state that the document is defining those
> assignments/registries, it shouldn’t imply that they haven’t been created
> yet.
>
> The issues begin with the description above Table 2.The document says that
> it assigns 0x00, 0x01, and 0x03 in the BGP Transitive Extended Community
> Types registry and 0x40, 0x41, and 0x43 in the BGP Non-Transitive Extended
> Community Types registry, but those assignments currently refer to RFC 7153
> rather than RFC 4360. To address this, instead of stating that it’s
> assigning the values, the document should describe its status as a
> reference for those assignments.
>
> Specifically, it should state that it should replace RFC 7153 as the
> reference or be listed as an additional reference (as you prefer) for those
> assignments. (If it’s going to obsolete 7153 – the document doesn’t
> currently say that it’s obsoleting or updated 7153 – it should replace the
> references.)
>
> 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?
>
> 5) The IPFIX registries include multiple references to RFC 4360:
>
> https://www.iana.org/assignments/ipfix
>
> If it's correct to replace those references, please add a sentence like
> "IANA will replace all references to RFC 4360 in the IP Flow Information
> Export (IPFIX) Entities registry group at
> https://www.iana.org/assignments/ipfix with references to this document."
>
> If you have any questions, just let us know. If you'd like to talk in
> person, you can find us next to the RFC Editor's table from Monday through
> Thursday. You can also request another review at any time by contacting us
> at [e-mail].
>
> For more information about IANA Considerations section requirements,
> please see
>
> https://www.iana.org/help/protocol-registration
>
> Best regards,
>
> Amanda Baber
> IANA
>
>