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

Adrian Farrel <> Tue, 16 March 2021 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A15F03A091B; Tue, 16 Mar 2021 12:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QmqRh3_njYgq; Tue, 16 Mar 2021 12:05:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C16A3A0905; Tue, 16 Mar 2021 12:05:56 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 12GJ5j6w011601; Tue, 16 Mar 2021 19:05:45 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id A32CD22044; Tue, 16 Mar 2021 19:05:45 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 8D0F022042; Tue, 16 Mar 2021 19:05:45 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 12GJ5iM5023177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Mar 2021 19:05:44 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Martin Duke'" <>, "'The IESG'" <>
Cc: <>, <>, <>, "'Susan Hares'" <>, "'Jie Dong'" <>, <>
References: <>
In-Reply-To: <>
Date: Tue, 16 Mar 2021 19:05:43 -0000
Organization: Old Dog Consulting
Message-ID: <028d01d71a97$5e13f8b0$1a3bea10$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGQfdWTFvVTeVgaKJjdOvdVI+/4+qsUMAYw
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No-2.462-10.0-31-10
X-imss-scan-details: No-2.462-10.0-31-10
X-TMASE-Result: 10-2.461600-10.000000
X-TMASE-MatchedRID: 9d2LtCNB3NLxIbpQ8BhdbI61Z+HJnvsOf6iC0fNopZl623gwrBldgEAQ 4W/owBG6wR8xcrVL5FTxHXxxAO/d2T4Pcn5OGAtGRTO9mhIXG42DwntrnEWhGadG+yyKuAArAGF yKacPKqJWOtipWOzsaPQxdAnGPI/SwLWaq3OxDLbyKt/vA0HdKLQ/y8fi37xL85b+xRMFjssWxL AX4AOTNz3yT4pJ5jBc+7rgA0QyMKwbAxBQtNeYrjKVTrGMDe/D7WUu3l5O6eDI9EDAP/dptowNs PHRB/HJm0m6bPXVGVkI7JlwYY+9RIZwTD28Ywl03mXA+JqzBaEp7CfTKkEjpYoij12xHbPunF4i dTSJ3rdzPnXHWXaxatD0jt+UigUc0B9cKNjgQaajGOtqnkAZC0+crEA4+nhZMZC3ZFuwuaoR8nj WRlXtt11Ms/I7TootkKR1BLYGf2Krd46AcF28XuDN5dBHl70NIVx4lWxn7mP18H7gy96lDKPFjJ EFr+ol4e8/DBwuXGd0HSe131POnqu+08oqCcwYBD8HheFR2YdCX7LllV+ZcrpRihth3CHPPA6ZJ /3RYXaKTglgGVmSe7RMjHa60VKjfD0/dJS2vKdDQBHhGrD69SHGID6En2xcsJ/jxlXnd3dp9xHu M9AfUiKeUbONtgeTe1ZwdZI0d1+gYtHdH9q8g1Zca9RSYo/b
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Idr] Martin Duke's Discuss on draft-ietf-idr-bgp-ls-registry-04: (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: Tue, 16 Mar 2021 19:05:59 -0000

Hi Martin,

Thanks for reading.

Speaking as the pen-holder for the document, but not guaranteeing to represent WG consensus on this point...

> I would like to understand the intent of this document a little better.
> RFC 8126 subtly implies that "Expert Review" is a little laxer than
> "specification required". But the guidance to experts in this draft seems to
> closely match "IETF Review" (sec 4.8 of 8126) except that it allows documents
> to get an allocation at an earlier stage in the process. The shepherd comment
> that "RFC Required" was an alternative proposal also indicates that the intent
> to become more, not less, strict. Indeed, the main change appears to be
> eliminating allocations to non-IETF-stream documents.
> So why not simply change the registry to "IETF Review" and allow provisional
> allocations? It would be much easier to use established mechanisms and standard
> definitions than rewriting them in this document. Is the SHOULD in Sec 2.1
> carrying a lot of weight here?

My understanding of IETF Review is that (absent early allocation) assignment cannot be made without publication of an IETF-consensus RFC. The WG wanted to enable assignments to be made sooner.

You are correct that early allocation would meet this requirement, however, the WG said that it found the early allocation procedure annoying because of the "maturity" requirement, and because of the need to renew assignments. The WG wanted to make a one-shot assignment.

You are also correct that the addition of the DE guidance strengthens Expert Review towards Specification Required, but it doesn't quite get there. A lot depends on whether an Internet-Draft is considered to be a stable reference. The working group was aware that opinions vary on this point and did not want to get into that debate. It seemed pragmatic to use Expert Review and set the exact requirements in the DE guidance.

And, before anyone asks 😉, yes, we could have included explanation text in the I-D saying why we have this approach. But, AFAICS, no other document has ever included explanation for the choice of assignment policy. Simply, this is the policy the WG would like to see applied to the registry.