Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries
draft-ietf-idr-bgp-ls-registry-06

I would like to be able to thank the author for writing and progressing this document. And as it happens, I am. So, thanks.

I support Lars's DISCUSS of everyone else's non-DISCUSS points.  I also came here to type something about why we didn't just follow the provisional/permanent model that so many other registries seem to use (URI schemes, for example, comes to mind).

Clearing discuss based on text in the editor's copy.

%%% original DISCUSS section follows %%%

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

%%% original COMMENT section follows %%%

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

Section 2.1, paragraph 4, comment:
>    In all cases of review by the Designated Expert (DE) described here,
>    the DE is expected to check the clarity of purpose and use of the
>    requested code points.  The following points apply to the registries
>    discussed in this document:
>

The process outlined in the rest of this section seems to define rules that are
basically equivalent to doing an RFC7120 "early allocation" for these
registries. Why is that existing process not sufficient?

Upon further reflection, my concerns below don't meet the DISCUSS criteria. Reclassifying:

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?

Hello Adrian, WG,

I'm not always sure what are the appropriate DISCUSS criteria for a process document. I hesitated and in the end chose NoObj. I'd nevertheless really appreciate if we could discuss theses points.

The Document allows for an Expert to consider a request which doesn't arise from a WG document (or an AD sponsored one) and does so by using SHOULD in the following:
   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.
and confirms that in:
   4.  If the document is not adopted by the IDR Working Group (or its
       successor), 
I am perfectly fine with that.
However, would it be fair to expect from the Expert that he/she communicates to the list (as part of step 4) the "valid reasons" and "full implications" of agreeing to consider this particular request?

Also, it isn't clear to me whether an Expert can refuse an allocation to be made and what would be the criteria for supporting such decision.
I do read
   5.  The Designated Experts MUST then review the assignment requests
       on their technical merit.
This could potentially result in a refusal, but I'm not sure in fact, but if it allows for a refusal then that's very vague.
There is of course point 6. but that's given. 
Another way (not completely equivalent) of saying this is that I get the impression that except in obvious cases (e.g., 6), all requests will be granted. Is that the case?


Thank you
-m

Hi,

Thank you for this document.

My first observation on this document is that it does not really explain why this change is being made.  I think that it would be helpful  for readers if the introduction briefly explained why the allocation policy is being changed.

However, I have the same concern that Martin raised, i.e., this uses an IANA "Expert Review" classification where the instructions to follow are broadly "IETF Review" or "Standards Action", and I don't understand why one of those classifications isn't being used instead.

Section 4.11 of RFC8216 explains that the use of well-known policies aids community experience and wide understanding, and that the policies are in increasing order of strictness.  But the use of "Expert Review" does not match what I would naturally expect that IANA policy to mean.

Regards,
Rob