[Idr] Martin Duke's Discuss on draft-ietf-idr-bgp-ext-com-registry-03: (with DISCUSS)

Martin Duke via Datatracker <noreply@ietf.org> Fri, 19 November 2021 22:48 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D413A0474; Fri, 19 Nov 2021 14:48:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-bgp-ext-com-registry@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com, aretana.ietf@gmail.com, shares@ndzh.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.40.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <163736211767.4352.4769047562362958995@ietfa.amsl.com>
Date: Fri, 19 Nov 2021 14:48:38 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xaO9FYyezvMrV2Wa5JCiDiqHRW8>
Subject: [Idr] Martin Duke's Discuss on draft-ietf-idr-bgp-ext-com-registry-03: (with DISCUSS)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 22:48:38 -0000

Martin Duke has entered the following ballot position for
draft-ietf-idr-bgp-ext-com-registry-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I'm having trouble seeing how we got here; this registry architecture is hard
to understand, and past actions appear to violate RFC 3692.

1. RFC7153 designated 0x80-0x8f as experimental and then immediately defines
0x80 as the gateway to a further subregistry of FCFS/IETF review codepoints.
This does not appear to be "Reserved for Experimental Use" in the RFC 3692
sense, in that it is not meant to be used only by explicit experiments. (It's a
standards track document).

2. RFC8955 compounds it by taking another 2 (of 15 remaining!) experimental
codepoints in a standards-track document, for a similar purpose.

I agree with this draft's reclassification of the 3 codepoints, as it
recognizes reality that they are apparently no longer safe for RFC 3692
experiments. But I would also like to verify that this behavior will not
continue: future standards-track allocations, including those pointing to more
subtypes ("Part 4", etc), will draw from the FCFS range, not Experimental.

Furthermore, experiments (with a draft or not) that use one of these
experimental codepoints should be reassigned a FCFS codepoint if they move to
Standards track.