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

Alvaro Retana <> Mon, 22 November 2021 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BAD53A0BFB; Mon, 22 Nov 2021 07:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IdYrxfIERgQu; Mon, 22 Nov 2021 07:17:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B15653A0BB7; Mon, 22 Nov 2021 07:17:26 -0800 (PST)
Received: by with SMTP id t5so78846707edd.0; Mon, 22 Nov 2021 07:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=BDuu0gNFcfb862aF9Zy8GgZwV8dZAKg6tPn00Vod+9Q=; b=oPYQAl/qD5T2bip1ctlepFfE6QTlOeo9o5uOejuJiGFm0CxecvglXEMxc5fj99eMAV ACfFOwZHcgvEFl8Q04X6LGf04JMS5+nWQYy9lD960ZTSEUUilG2yNBIzler7Mqq9P7zM KvtF34NzjkzP4TpJZrzlgtvFDLAKWdhOb6o8rZ54gIyOrPCYNsrMZw/Li+sqzR7eloNV 6oreKPo3jTZ1Wy/Mgs9EX9KWXi9Y+E972dOJX4bLbFqEqgj80a2i5a9gLtAqWHX1T+cs TgOXjtT8e72GheO+l701fdAkTwYU8zPsE0DtJhy5apEnT8Rzool7K2zygNYZBz7a73lY vdGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=BDuu0gNFcfb862aF9Zy8GgZwV8dZAKg6tPn00Vod+9Q=; b=XFv1pDQA23Kpg+ArSswfWuiUcmFUUgzbPsgxrogaudsHxCSsCejwPU8bk3frqcGyLU EwfzBjlCEa6lFSp0Ez+Lo7LsSWVw4Y3xp4eFiMQJ4FcpAX4YaxLcX5YD9fFD8bpcyF6l cj4Ty74uHetLiEKIo9R0DN+YdK0oc/onSpNpG0g5fhZtuP0LQQeGYBeXtXWHVUeqNkx8 FR7jGG7See6vr6HfaV9ZrOwgUBuOISXYml0KTAEJkLQjj6txunMKOSdafB4sr+gzqcSg MZ0IUt2NO/SvoYeTLwnQPgx3TXDvXejONBq1nAd+1J9EkLkxbjWEcW+NB1hI3TnAYiEM 5nlQ==
X-Gm-Message-State: AOAM531VMRoVDKKqzwAA4VtwhqXIS2t74eZTWuQ7Rn5JW42kDVey9f68 pYJ4iEO9WV/1rrMzFB2EBvDoa4HJEpkLrV1M14eR5swI
X-Google-Smtp-Source: ABdhPJw10/I+ZUDk4HdRojP8Cb4v/jboQZ+rKBGk0VU+30fWJNd3i6KUpdCgUydirHDPe1ulffJttYhNedwWT+/H95Q=
X-Received: by 2002:a17:906:4c95:: with SMTP id q21mr41970145eju.485.1637594243085; Mon, 22 Nov 2021 07:17:23 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 22 Nov 2021 07:17:22 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Mon, 22 Nov 2021 07:17:22 -0800
Message-ID: <>
To: Martin Duke via Datatracker <>, The IESG <>, Martin Duke <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idr] Martin Duke's Discuss on draft-ietf-idr-bgp-ext-com-registry-03: (with DISCUSS)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Nov 2021 15:17:31 -0000

On November 19, 2021 at 5:48:38 PM, Martin Duke wrote:



> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.

That is the intent.  The allocation process has been followed for
other BGP-related registries, and I'm sure the WG will continue to do

We can't unfortunately go back and correct how the assignments were
made to rfc5575 (which seems to have been the origin of this whole
issue) -- so we are (finally!) cleaning it up.