[Idr] Re: [IANA #1435575] Early review: draft-ietf-idr-rfc4360-bis-01 (IETF 124)
Jeffrey Haas <jhaas@pfrc.org> Fri, 14 November 2025 19:18 UTC
Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2C0C689B3D97; Fri, 14 Nov 2025 11:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOLRjvc27kvp; Fri, 14 Nov 2025 11:18:06 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by mail2.ietf.org (Postfix) with ESMTP id 1A50189B3D7D; Fri, 14 Nov 2025 11:18:00 -0800 (PST)
Received: from smtpclient.apple (99-188-202-8.lightspeed.livnmi.sbcglobal.net [99.188.202.8]) by slice.pfrc.org (Postfix) with ESMTPSA id DA7C91E24F; Fri, 14 Nov 2025 14:17:58 -0500 (EST)
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
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: L67IA4IIO6G2ZWKFNZMR4JGF2YUUI6VJ
X-Message-ID-Hash: L67IA4IIO6G2ZWKFNZMR4JGF2YUUI6VJ
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-idr-rfc4360-bis.all@ietf.org, idr@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: [IANA #1435575] Early review: draft-ietf-idr-rfc4360-bis-01 (IETF 124)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cR6BDPkWMf2qV-flTQfDXZrEFHM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>
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. > 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: “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. 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
- [Idr] [IANA #1435575] Early review: draft-ietf-id… Amanda Baber via RT
- [Idr] Re: [IANA #1435575] Early review: draft-iet… Nat Kao
- [Idr] Re: [IANA #1435575] Early review: draft-iet… Jeffrey Haas
- [Idr] [IANA #1436671] Re: Early review: draft-iet… Amanda Baber via RT
- [Idr] Re: [IANA #1436671] Early review: draft-iet… Jeffrey Haas