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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 23 Mar 2021 12:53:48 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-bgp-ls-registry-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document changes the registration policy to "Expert Review" which,
as even quoted in this document, "has no requirement for a formal
document".  Yet the specific guidance to the expert is written as if
there will always be a document: consider "[i]f the document is not
adopted by the IDR Working Group", "IANA will update [...] a reference
to the associated document", "[i]n the event that the document is", ...

Is there a requirement for a document or not?  (Alternately, what
happens if there is a request with no associated document?)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2

The order the sub-registries are listed in here does not match the order
used at
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml
.

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

   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?)

   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

I appreciate the new security considerations :)

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 23 Mar 2021 20:39:59 -0000

Hi Ben,

> there will always be a document

Yeah, that's right.

According to 8126

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.

That's what this document does. In other words, it takes Expert Review as the base, and then sets out the required documentation and review criteria.

> consider "[i]f the document is not

There is a requirement for a document. But what is a document?
This could be clearer 2.1. How about...

OLD
   1.  Application for a code point allocation may be made to the
       Designated Experts at any time.
NEW
   1.  Application for a code point allocation may be made to the
       Designated Experts at any time, and MUST be accompanied
       by technical documentation explaining the use of the code
       point.  Such documentation SHOULD be presented in the
       form of an Internet-Draft, but MAY arrive in any form that
       can be reviewed and exchanged amongst reviewers.
END

> https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml

Oh yes. I seem to have put them in alphabetic order.

Cheers,
Adrian

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Mar 2021 13:43:54 -0700

>        can be reviewed and exchanged amongst reviewers.

Excellent.  Thanks for the quick response; I will go clear this silly
discuss now so I don't have to worry about it anymore :)

Thanks,

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 23 Mar 2021 21:18:09 -0000

Hi,

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

> assume they would still go through the IDR review, etc.)

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

> Further consideration by whom, in what venue?  (When does the further

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.

> I'm asking for more work for ADs, of course!)

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

> I appreciate the new security considerations :)

It is our pleasure to serve.

Thanks,
Adrian

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Mar 2021 15:33:07 -0700

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

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

Thanks for confirming!

> 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 :)

> 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