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

Adrian Farrel <> Tue, 23 March 2021 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 136F43A172B; Tue, 23 Mar 2021 14:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 iwM0ZUQF23XR; Tue, 23 Mar 2021 14:33:27 -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 EFAEA3A172A; Tue, 23 Mar 2021 14:33:26 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 12NLXJKx015100; Tue, 23 Mar 2021 21:33:19 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 23F1122056; Tue, 23 Mar 2021 21:33:19 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 94C5922087; Tue, 23 Mar 2021 21:18:10 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 12NLI9cL013067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Mar 2021 21:18:09 GMT
From: Adrian Farrel <>
To: 'Benjamin Kaduk' <>, 'The IESG' <>
Cc:,,, 'Susan Hares' <>, 'Jie Dong' <>,
References: <>
In-Reply-To: <>
Date: Tue, 23 Mar 2021 21:18:09 -0000
Organization: Old Dog Consulting
Message-ID: <0c8b01d7202a$07145fd0$153d1f70$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEWD5smbCoZ9XEZo1dIX4MC0LAKBKwUMM0A
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--13.990-10.0-31-10
X-imss-scan-details: No--13.990-10.0-31-10
X-TMASE-Result: 10--13.990300-10.000000
X-TMASE-MatchedRID: H0/uSqZo4D7xIbpQ8BhdbDjNGpWCIvfTDvc/j9oMIgU+a5sWK4OlhxMG tPkUyFbdRaR5Ppd2BPXos7IkKKuHv/wo1xnELmsTGFMYlDUzwr11TaBc8Zmm5xLf1vz7ecPHrEi NJh+xJpmlJJRwFJayM2DpeoohJhgkB4uNgLBEIwL4AIbmhYnu0lx5UEiF/A71SX8n1Gj4wAGsZR v6MhtinP40QIurth1OKRv0QBIBWgfMRe4yR+9muITBkzbkEx2zrXkuON8pnlG+eQ1tlrjoEUSi2 ut9sl80omB8XSnNMRs25V+HJnVShMjCvySVCe+ukJi1wdeHFtpL9x4FCuBLUcHx9l2YYLoQQo9A Vz98w3+UFfKw7AkigAO9qPzTgueQ83gviLOxr+QZ9MKxHrUy4c1sM1MC2yq4ktRIj8BJ2MEIBaG Yxro0bTy2tST9CfwZTdYz/uL5OuhFvZzlKugJgNWvZ0LprH5qlFGUu7DBzhi5sMNEOrHDFGimIz b1qb1PV+oD9QHvfjCYZuYLVKl5KuYtNiqWgzAs+VmU9hhYfp06rAu5latQ2C99T+uJIleRaGnFt CHggYQ9rkouS7LK+UATX+VlevKkq1zirKOWNtaeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP 9j+C1SAHAopEd76v4Cbs2noV8GO2Z15DQazzEpgq0eS9mpZAaEwI1kAFxeTThMoW0iWRzA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Idr] Benjamin Kaduk'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: Tue, 23 Mar 2021 21:33:29 -0000


The Datatracker contains some more Comments from Ben, so here is an answer to them...

> Section 2.1
>   2.  The Designated Experts SHOULD only consider requests that arise
>       from I-Ds that have already been accepted as Working Group
>       documents or that are planned for progression as AD Sponsored
>       documents in the absence of a suitably chartered Working Group.
> Am I reading this correctly that the only provision for non-IETF
> documents to allocate codepoints is to violate the "SHOULD" here?  (I
> assume they would still go through the IDR review, etc.)

Yes and yes. The second is covered by bullet 4.

>   5.  The Designated Experts MUST then review the assignment requests
>       on their technical merit.  The Designated Experts MAY raise
>       issues related to the allocation request for further
>       consideration before the assignments are made.
> Further consideration by whom, in what venue?  (When does the further
> discussion terminate?)

This could be said better.


       The Designated Experts MAY raise
       issues related to the allocation request with the 
       authors and on the IDR (or successor) mailing list
       for further consideration before the assignments
       are made.

As to the other point, the IETF has always danced around what happens when a DE says "no" and indeed what power they have to say "no". There is even the question of whether a DE can override IETF consensus -- the general opinion is that they cannot. And, in fact, the general opinion is that DEs can't say "no" because they only advice the IANA. Of course, there are angels dancing on this pinhead.

I sort of agree that more advice to the DE would be good (cos I'm a DE for this registry), but I don't know about singling out this document to pioneer giving that sort of advice.

>   8.  In the event that the document is a Working Group document or is
>       AD Sponsored, and that document fails to progress to publication
>       as an RFC, the Working Group chairs or AD SHOULD contact IANA to
>       coordinate about marking the code points as deprecated.  A
>       deprecated code point is not marked as allocated for use and is
>       not available for allocation in a future document.  The WG chairs
>      may inform IANA that a deprecated code point can be completely
>      de-allocated (i.e., made available for new allocations) at any
> IIRC it is rather unusual for WG chairs to interact directly with IANA
> in an official role; we see DEs and ADs be named more often.  (Not that
> I'm asking for more work for ADs, of course!)

Section 3.1 bullet 5 of RFC 7120 is the model here.

> Section 3
> I appreciate the new security considerations :)

It is our pleasure to serve.