Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

[Adrian Farrel <[e-mail]>]

Hi Alvaro,

Thanks for this. As usual, nits are an embarrassment.

Inline for the detailed discussion.

A

> 94	      Internet-Drafts are draft documents valid for a maximum of six
> 95	      months and may be updated, replaced, or obsoleted by other
> 96	      documents at any time.  It is inappropriate to use Internet-Drafts
> 97	      as reference material or to cite them other than as "work in
> 98	      progress."
>
> [major] Related to the use of IDs to satisfy Specification Required.
>
> The general practice is to let the DEs decide if an ID is sufficient.
> Clear instructions go a long way.
>
> The motivation discussed on the list is focused only on speeding up
> allocations by eliminating the rfc7120-related part of the process.
>
> This document is not the best place to introduce a discussion about
> the boilerplate, or the interpretation of other documents.
>
> Please reword the motivation.
>
> [] I know the conversation about IDs, their boilerplate, and the
> Specification Required policy has come up several times, and that
> rfc8126 didn't include the best possible text.  I will bring this up
> to the IESG (again), but I suspect that the result will be to hold any
> potential changes until rfc8126bis (I think Michelle @ IANA mentioned
> that she was working on it).

I know that you had a conversation with IANA about it being up to the DEs to determine what is “permanent and readily available”…and that it could include I-Ds (if the DEs determined that was ok). 

The problem with this statement is that the DEs might take a view on the appropriateness of using an I-D for this purpose. 

Hence, this document makes it clear to the DE that they are expected to allow assignment resulting from an I-D. It removes that element of determination from the DE.

[In this case of these registries and their DEs, this is a good thing. I am one of the DEs for the registries and I (in general) do not consider that permanent assignment based on an I-D is a good thing. In fact, I think it is a bad idea. However, this document gives me clear instructions that for these registries I must not take that into account.

But, do we need the motivation in this document? Probably not.

I think we can safely just delete...
   It is often considered that it is the responsibility of the Designated
   Expert to make a determination as to whether a specification meets the
   requirement to be permanent and readily publicly available.  A degree
   of contention arises in this case because Internet-Drafts are now permanently
   archived in the IETF's tools archive, yet each such document is marked
   with a piece of boilerplate text as follows that brings doubt about its
   suitability as a permanent record:

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

> 129	2.1.  Guidance for Designated Experts
>
> 131	   Section 5.1 of [RFC7752] gives guidance to Designated Experts.  This
> 132	   section replaces that guidance.
>
> 134	   In all cases of review by the Designated Expert (DE) described here,
> 135	   the DE is expected to check the clarity of purpose and use of the
> 136	   requested code points.  Additionally, the DE must verify that any
> 137	   request for one of these code points has been made available for
> 138	   review and comment within the IETF: the DE will post the request to
> 139	   the IDR Working Gorup mailing list (or a successor mailing list
> 140	   designated by the IESG).  If the request comes from within the IETF,
> 141	   it should be documented in an Internet-Draft.  Lastly, the DE must
> 142	   ensure that any other request for a code point does not conflict with
> 143	   work that is active or already published within the IETF.
>
> [major] "the DE must verify that any request for one of these code
> points has been made available for review and comment within the IETF:
> the DE will post the request to the IDR..."
>
> The text in rfc7752 asks that "any specification produced in the IETF
> that requests one of these code points has been made available for
> review by the IDR..."   But the updated text talks about the
> *request*, not the *specification*, which is what I assume is what you
> want idr to see, and is in line with the original instructions.
> Right?

The text is as intended. This is indicative of the change from "Specification Required" (a specification must exist and so can be shown to the WG) to "Expert Review" (no specification is required, so when there is no specification, only the request can be shown).

No change to text.

> [major] On the same text...  What is the expectation when posting the
> specification to idr?  Can the DE move on once he/she sends a message
> to idr, or is there some feedback/discussion/confirmation expected?
> The text explicitly talks about being "available for review" -- what
> type of review is expected?

Was not setting any expectations on the DE here. They can do what they consider reasonable.
Personally, I would expect comments over one or two weeks and would accept any type of review (of the request).

No change to text proposed. We *could* codify this if someone has a proposal.

> [major] Related to possible WG feedback...  How much attention are the
> DEs expected to pay to the WGs review?  The Expert Review policy can
> clearly result in the allocation of codepoints to specifications that
> don't have IETF consensus/approval/favorable reviews...

I would expect DEs to listen to feedback, but make their own decision. If, for example, some feedback said, "Hey, this conflicts with the work we are doing in the WG," I would expect the DE to check this out. If some feedback said, "This will cause the Internet to crash," the DE is also expected to check it out. But, it is not a request for consensus, it is a request for review. 

Again, I am not proposing any text change for this.

> [major] "If the request comes from within the IETF..."  How is it
> determined that the request comes from "within the IETF"?  For
> example, the case where a draft is discussed/adopted in a WG, and the
> WG (not just the authors) decide to ask for an allocation seems like a
> case where the request comes from "within the IETF": the WG making the
> request is part of the IETF.  What are other cases?

Agree, this is ambiguous. Not trying to say, "The request comes from the IETF," but, "From within the IETF." That is, in any way from within the IETF process. I think that includes, on an IETF mailing list. 

It's more of an expression of the converse. "Requests that come direct to the DEs or IANA without first approaching the IETF."

Any suggestions of how to express this?

> [major] Do you really want all the sub-registries to use the same DE
> instructions?  An important difference between Expert Review and
> Specification Required is that the former is not covered by the early
> allocation process in rfc7120 -- which, I think is part of the
> objective.  The space in the registries is large (so there shouldn't
> be significant issues with unused codepoints), except for the "BGP-LS
> Protocol-IDs" one which only has 255 possible values; that is still
> pretty big for its purpose.  Just want to check everyone is ok with
> this.

This is my understanding of what IDR wanted. 

> An alternative would be to still use Expert Review, and to add
> rfc7370-like instructions.  In short: the DE would follow an Early
> Allocation process akin to rfc7120 (just for this sub-registry)...not
> only when assigning a value, but also if deallocation is needed.

So, no change proposed.

> [major] Why isn't rfc2119 language used in the DE instructions?  As
> written, the DEs, for example, can decide to not enforce the ID
> requirement for no good reason.

I don't think 2119 language is any more legally enforceable than regular English. There is "must" and "should" in these instructions, and my expectation is that a DE would use them in the correct meanings of the words. 

AFAIK, the purpose of 2119 is to clarify (or make bold) implementation behaviors for protocol specs.

> 160	   This change in allocation policy should not have any effect on the
> 161	   integrity of BGP-LS since there is no change to the review
> 162	   requirements for the work that underlies the request.
>
> [major] Yes, there is!!  Specification Required asks for a
> specification to be stable (discussion, adoption in a WG, etc.) before
> granting (early) allocation -- this document leaves that decision to
> the DEs and what they may consider to be "clear".

Hmmmm, no, I don't think so. The change is for code point assignment, not for protocol specification. 
This is, of course, the area of debate when reducing the requirements for code point assignment. IDR likes the idea of making code points readily available so as to reduce squatting, help avoid clashes, and make it clear what code points are being used for.

We could possibly reword this as...

   This change in allocation policy is not expected to not have any
   effect on the integrity of BGP-LS standards track specifications 
   since there is no change to the review requirements for the
   work that underlies the request if it is to become an RFC.

Would that help?

Cheers,
Adrian