RT-Owner: amanda.baber
From: "Amanda Baber via RT" <iana-issues@iana.org>
In-Reply-To: <rt-5.0.3-1034089-1761848294-1261.1435575-37-0@icann.org>
References: <RT-Ticket-1435575@icann.org>
 <rt-5.0.3-1034089-1761848294-1261.1435575-37-0@icann.org>
Message-ID: <rt-5.0.3-1064555-1761867823-1712.1435575-37-0@icann.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Date: Thu, 30 Oct 2025 23:43:43 +0000
MIME-Version: 1.0
Message-ID-Hash: 3APWY3C64KZWMAF2GB6A7NBAGF7MJHPO
CC: draft-ietf-idr-rfc4360-bis.all@ietf.org, idr@ietf.org
Reply-To: iana-issues@iana.org
Subject: =?utf-8?q?=5BIdr=5D_=5BIANA_=231435575=5D_Early_review=3A_draft-ietf-idr-rfc?=
	=?utf-8?q?4360-bis-01_=28IETF_124=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/idr/wYGXRPHp47JYmal1oOetqUtIQbc>

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 [R=
FC9184])

This is problematic. If these registration procedures aren't separated, we =
could end up assigning values that people were using for experimental purpo=
ses. Can Experimental Use continue to have its own separate range?

2) RFC 4360 is a reference for =E2=80=9CEXTENDED COMMUNITIES=E2=80=9D in th=
e BGP Path Attributes registry at https://www.iana.org/assignments/bgp-para=
meters. Because this document is obsoleting that one, it needs to tell us w=
hether to replace that reference. (References are typically replaced.)

Alternatively, if it=E2=80=99s correct that both that reference and the oth=
er references to RFC 4360 at https://www.iana.org/assignments/bgp-extended-=
communities should be replaced, the section could simply state up front tha=
t all references to RFC 4360 in the IANA registries will be replaced with r=
eferences 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=E2=80=99t mention that it=E2=80=
=99s obsoleting RFC 7153, it=E2=80=99s not clear whether this document shou=
ld replace those references to RFC 7153 or be listed as an additional refer=
ence.

While it might make sense to state that the document is defining those assi=
gnments/registries, it shouldn=E2=80=99t imply that they haven=E2=80=99t be=
en 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 Ty=
pes registry and 0x40, 0x41, and 0x43 in the BGP Non-Transitive Extended Co=
mmunity Types registry, but those assignments currently refer to RFC 7153 r=
ather than RFC 4360. To address this, instead of stating that it=E2=80=99s =
assigning the values, the document should describe its status as a referenc=
e for those assignments.=20

Specifically, it should state that it should replace RFC 7153 as the refere=
nce or be listed as an additional reference (as you prefer) for those assig=
nments. (If it=E2=80=99s going to obsolete 7153 =E2=80=93 the document does=
n=E2=80=99t currently say that it=E2=80=99s obsoleting or updated 7153 =E2=
=80=93 it should replace the references.)

4) There might be an issue related to this paragraph, which is carried over=
 from RFC 4360: =E2=80=9CThe value allocated for a Regular Type MUST NOT be=
 reused as the value of the high-order octet when allocating an Extended Ty=
pe. The value of the high-order octet allocated for an Extended Type MUST N=
OT be reused when allocating a Regular Type.=E2=80=9D

The potential problem is that values can be assigned via the First Come Fir=
st Served registration procedure, but those values don=E2=80=99t receive an=
y kind of review by anyone outside of IANA, and IANA=E2=80=99s Operations t=
eam isn=E2=80=99t equipped to make this determination. Should the First Com=
e First Served procedure be changed to a lightweight Expert Review, with gu=
idance to the expert that they only need to check for this? Or do the range=
s of values made available in the registries' "Registration Procedure" fiel=
ds already guarantee that this won=E2=80=99t 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 "IA=
NA will replace all references to RFC 4360 in the IP Flow Information Expor=
t (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 perso=
n, you can find us next to the RFC Editor's table from Monday through Thurs=
day. You can also request another review at any time by contacting us at ia=
na@iana.org.

For more information about IANA Considerations section requirements, please=
 see

https://www.iana.org/help/protocol-registration

Best regards,

Amanda Baber
IANA