Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Lars Eggert <> Wed, 24 March 2021 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEE2E3A0976; Wed, 24 Mar 2021 13:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AHOku3By4lx1; Wed, 24 Mar 2021 13:56:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00FBD3A0975; Wed, 24 Mar 2021 13:56:32 -0700 (PDT)
Received: from [IPv6:2a00:ac00:4000:400:9507:e9f6:f26d:fc6a] (unknown [IPv6:2a00:ac00:4000:400:9507:e9f6:f26d:fc6a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 59F2B60030E; Wed, 24 Mar 2021 22:56:21 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1616619381; bh=drzx0od8hPI7UVEdn3MwqCPhz8T+mbwvZONrJxZN9+g=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=LeN6MQ4N6uPS5iUCO84VAT1t0Ca7ODq2XS5Tebvx+QHfY9zIJOohqz8h/X5JYOkLA LL80WgscREdBeZ3htIuBRNy5orKibkah+hf6AK2nOH3k0yXANvyNuocpoYdTGz0NS+ 8PLIHR9ZStuPWd0DO3fx/YgxzISS1IHCx7zn4TSY=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_AD6426C1-8502-4339-90EE-AD743191419B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 24 Mar 2021 22:56:20 +0200
In-Reply-To: <0dea01d720e5$57d670f0$078352d0$>
Cc: The IESG <>,, Jie Dong <>,, Alvaro Retana <>,, Susan Hares <>
References: <> <0dea01d720e5$57d670f0$078352d0$>
X-Mailer: Apple Mail (2.3654.
X-MailScanner-ID: 59F2B60030E.A1F1D
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)
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: Wed, 24 Mar 2021 20:56:39 -0000


On 2021-3-24, at 21:39, Adrian Farrel <> wrote:
>> I'm putting in a "discuss" DISCUSS that I expect to clear during the
>> call. Several other ADs raised issues that deserve discussion. While they may
>> not fall under the "discuss criteria", they also don't fall under the "discuss
>> non-criteria" and I want to make sure we spent some time on discussing them.
> That's perfectly reasonable.
> I wish there was a way for the IESG to table something for discussion without using the "Discuss a document" hook which makes the authors (and the watchers) feel that *they* should be part of the discussion. But, anyway, it seems that there is something here that the IESG needs to discuss, so "whatever works."

I wish so, too, but we're limited by the current toolchain here, as you know. I guess I could have put an explicit "non-ADs ignore this" into the text above...

>> Section 2.1, paragraph 4, comment:
>>>   In all cases of review by the Designated Expert (DE) described here,
>>>   the DE is expected to check the clarity of purpose and use of the
>>>   requested code points.  The following points apply to the registries
>>>   discussed in this document:
>> The process outlined in the rest of this section seems to define rules that are
>> basically equivalent to doing an RFC7120 "early allocation" for these
>> registries. Why is that existing process not sufficient?
> It achieves a similar end with some slight variations. I can't speak for the WG as to why they preferred this approach, but:
> - 7120 requires a stable WG I-D. Thus:
>   - an early WG I-D doesn't qualify

RFC7120 requires:

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

It seems one would want this sort of stability here, too?

>   - a non-WG I-D doesn't qualify

It's not clear to me that RFC7120 requires this. Also, this document says "SHOULD only consider requests that arise from I-Ds that have already been accepted as Working Group documents..." which is a similar limitation.

>   - a non-IETF document doesn't qualify

RFC7120 also applies to "Specification Required" registries for which no IETF document is needed.

> - 7120 allocations have to be renewed
>   - this is extra effort
>   - only one renewal is allowed unless the IESG is invoked "under rare circumstances"
>   - the code point "expires" if someone forgets to renew

Fair point. But this document defines a mechanism whereby chairs and the ADs are tasked to remember to make IANA deprecate the codepoints when a document isn't published (or I guess published with incompatible changes to the revision for which the allocation was made). That seems to suffer from similar drawbacks.