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

[Alvaro Retana <[e-mail]>]

Adrian:

Hi!  Thanks for your work on this document.

I have some concerns about the text related to the motivation and the
DE guidance, along with some minor comments and nits.  Please see
in-line below.


Thanks!

Alvaro.



[Line numbers from idnits.]

...
12	Abstract

14	   RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS).  IANA
15	   created a registry consistent with that document called the "Border
16	   Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a
17	   number of sub-registries.  The allocation policy applied by IANA for
18	   those policies is "Specification Required" as defined in RFC 8126.

[minor] s/allocation policy applied by IANA for those
policies/allocation policy applied by IANA for those registries/g


...
66	1.  Introduction

68	   Border Gateway Protocol - Link State (BGP-LS) [RFC7752] requested
69	   IANA to create a registry consistent called the "Border Gateway
70	   Protocol - Link State (BGP-LS) Parameters Registry" with a number of
71	   sub-registries.  The allocation policy applied by IANA for those
72	   policies is "Specification Required" as defined in [RFC8126].

[nit] s/a registry consistent called/a registry called


74	   The "Specification Required" policy requires evaluation of any
75	   assignment request by a "Designated Expert" and guidelines for any
76	   such experts are given in section 5.1 of [RFC7752].  In addition,
77	   this policy requires "the values and their meanings must be
78	   documented in a permanent and readily available public specification,
79	   in sufficient detail so that interoperability between independent
80	   implementations is possible" [RFC8126].  Further, the intention
81	   behind "permanent and readily available" is that "a document can
82	   reasonably be expected to be findable and retrievable long after IANA
83	   assignment of the requested value" [RFC8126].

[nit] s/requires "the values/requires that "the values


85	   It is often considered that it is the responsibility of the
86	   Designated Expert to make a determination as to whether a
87	   specification meets the requirement to be permanent and readily
88	   publicly available.  A degree of contention arises in this case
89	   because Internet-Drafts are now permanently archived in the IETF&s
90	   tools archive, yet each such document is marked with a piece of
91	   boilerplate text as follows that brings doubt about its suitability
92	   as a permanent record:

[nit] s/IETF&s/IETF's


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


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

[nit] s/Gorup/Group

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


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


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


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


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

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.


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



145	3.  Security Considerations
...
149	   Note that the change to the expert review guidelines make the
150	   registry and the Designated Experts slightly more vulnerable to
151	   denial of service attacks through excessive and bogus requests for
152	   code points.  It is expected that the registry cannot be effectively
153	   attacked because the Designated Experts would, themselves, fall to
154	   any such attack first.  Designated Experts are expected to report to
155	   the IDR working group chairs and responsible Area Director if they
156	   believe an attack to be in progress, and should immediately halt all
157	   requests for allocation.  This may temporarily block all legitimate
158	   risks until mitigations have been put in place.

[nit] s/the change...make/the change...makes

[minor] s/block all legitimate risks/block all legitimate requests


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