Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <rt-5.0.3-1064555-1761867823-1712.1435575-37-0@icann.org>
Date: Fri, 14 Nov 2025 14:17:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <124BBAA6-73B9-447F-B29B-BBA80034B21D@pfrc.org>
References: <RT-Ticket-1435575@icann.org>
 <rt-5.0.3-1034089-1761848294-1261.1435575-37-0@icann.org>
 <rt-5.0.3-1064555-1761867823-1712.1435575-37-0@icann.org>
To: iana-issues@iana.org
Message-ID-Hash: L67IA4IIO6G2ZWKFNZMR4JGF2YUUI6VJ
CC: draft-ietf-idr-rfc4360-bis.all@ietf.org, idr@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BIdr=5D_Re=3A_=5BIANA_=231435575=5D_Early_review=3A_draft-ietf-i?=
 =?utf-8?q?dr-rfc4360-bis-01_=28IETF_124=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/idr/cR6BDPkWMf2qV-flTQfDXZrEFHM>

Amanda,

Nat Kao has noted that we're addressing the helpful early review =
comments IANA has provided in various github issues.  This one addresses =
the FCFS procedures with regard to regular vs. extended types covered in =
https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/17. =20


> On Oct 30, 2025, at 7:43 PM, Amanda Baber via RT =
<iana-issues@iana.org> wrote:
> 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 Type. The value of the high-order octet allocated for an =
Extended Type MUST NOT be reused when allocating a Regular Type.=E2=80=9D
>=20
> The potential problem is that values can be assigned via the First =
Come First Served registration procedure, but those values don=E2=80=99t =
receive any kind of review by anyone outside of IANA, and IANA=E2=80=99s =
Operations team isn=E2=80=99t 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=E2=80=99t =
happen?
>=20

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-com=
munities.xhtml

Consider the examples of "QoS marking", "CoS capability" and others.

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.

-- Jeff