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

[Benjamin Kaduk <[e-mail]>]

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.

-Ben

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