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

Benjamin Kaduk <> Tue, 23 March 2021 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAB533A1870; Tue, 23 Mar 2021 15:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QCQKiC9dNAsX; Tue, 23 Mar 2021 15:33:20 -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 A7B093A1878; Tue, 23 Mar 2021 15:33:20 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 12NMX7sV005609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Mar 2021 18:33:12 -0400
Date: Tue, 23 Mar 2021 15:33:07 -0700
From: Benjamin Kaduk <>
To: Adrian Farrel <>
Cc: 'The IESG' <>,,,, 'Susan Hares' <>, 'Jie Dong' <>,
Message-ID: <>
References: <> <0c8b01d7202a$07145fd0$153d1f70$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0c8b01d7202a$07145fd0$153d1f70$>
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 22:33:24 -0000

On Tue, Mar 23, 2021 at 09:18:09PM +0000, Adrian Farrel wrote:
> Hi,
> The Datatracker contains some more Comments from Ben, so here is an answer to them...

Hmm, troublesome that the datatracker has been eating comments; thank you
for noticing and digging them up to respond to.

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

Thanks for confirming!

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

Fair enough.  I'm happy to get the "whom" and "venue" questions answered
and put the halting problem in a parenthetical for good reason :)

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

Thanks for the reminder.
It's not a direct analogue, but I'm also not objecting to anything.


> > Section 3
> >
> > I appreciate the new security considerations :)
> It is our pleasure to serve.
> Thanks,
> Adrian