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

[Alvaro Retana <[e-mail]>]

Adrian:

Hi!  Thanks for working through my first set of comments with the WG!


I realize that a significant part of the updated text in §2.1 comes
from rfc7370 -- I still have questions/concerns about the lack of
specificity [*].  Please see in-line.

Part of this work's motivation is to remove the requirement for a
"permanent and readily available public specification".  The guidance
in §2.1 mainly focuses on IETF-related documents (considering
adoption, for example). Still, it leaves the door open for requests
related to other documents (not I-Ds) to also be considered (in #2 and
#4).  Is that the intent?  If so, is there any requirement placed on
that documentation?  [Also, some of the guidance may need to be
reworded based on the answer.]

Note that the questions  I am asking (including the ones above) are
because I believe the guidance can be a lot more specific, including
potential exception cases (see my comments below about using SHOULD),
not necessarily because I disagree with the recommendations.


Thanks!!

Alvaro.


[*] Which of course would extend to rfc7370, but that is a different discussion.


[Line numbers from idnits.]


...
123	2.1.  Guidance for Designated Experts

125	   Section 5.1 of [RFC7752] gives guidance to Designated Experts.  This
126	   section replaces that guidance.

128	   In all cases of review by the Designated Expert (DE) described here,
129	   the DE is expected to check the clarity of purpose and use of the
130	   requested code points.  The following points apply to the registries
131	   discussed in this document:

133	   1.  Application for a codepoint allocation MAY be made to the
134	       Designated Experts at any time.

[nit] Most of the document uses "code point".  Please choose one and
be consistent.


[major] s/MAY/may

This is just a statement of fact; applicants are not subject to this
document, so we can't tell them what they can or cannot do.  You may
want to rephrase so the action falls on the DE: "DEs MAY consider
applications at any time."


136	   2.  The Designated Experts SHOULD only consider requests that arise
137	       from I-Ds that have already been accepted as Working Group
138	       documents or that are planned for progression as AD Sponsored
139	       documents in the absence of a suitably chartered Working Group.

[major] "SHOULD only consider...Working Group documents or...AD
Sponsored"  When is it ok for the DEs to consider other types of
documents?  For example, documents that are not in the IETF stream, or
even not in I-D format?  IOW, why is this action not a requirement?


141	   3.  In the case of Working Group documents, the Designated Experts
142	       SHOULD check with the Working Group chairs that there is
143	       consensus within the Working Group to make the allocation at this
144	       time.  In the case of AD Sponsored documents, the Designated
145	       Experts SHOULD check with the AD for approval to make the
146	       allocation at this time.

[major] "Designated Experts SHOULD check"  When is it ok for the DEs
to not check for consensus/approval?  IOW, why is this action not a
requirement?


148	   4.  If the document is not adopted by the IDR Working Group (or its
149	       successor), the Designated Expert SHOULD notify the IDR mailing
150	       list (or its successor) of the request and allow two weeks for
151	       any response.  Any comments received SHOULD be considered by the
152	       Designated Expert as part of the subsequent step.

[major] Points 2-3 assume IETF track documents.  Point 4 is not
explicit as to the origin of the document, but it looks like the door
is open to consider documents that are not intended to be part of the
IETF process.  Is that the correct interpretation?


[major] "SHOULD notify the IDR mailing list"  When is it ok to not
notify idr?  IOW, why is this not a requirement?  Given that most of
the work will be related to idr, not requiring this action seems to
conflict with the MUST in #6 below.


154	   5.  The Designated Experts SHOULD then review the assignment requests
155	       on their technical merit.  The Designated Experts SHOULD NOT seek
156	       to overrule IETF consensus, but they MAY raise issues for further
157	       consideration before the assignments are made.

[major] "SHOULD then review the assignment requests on their technical
merit"  It is not completely clear whether this recommendation applies
to the review or to the fact that it is done on technical merits.  In
either case, when would the DEs not do either?  IOW, why is this
action not required?


[major] "SHOULD NOT seek to overrule IETF consensus"  But they can?!?
The action (seek) is weak.  Perhaps better wording would be something
like this:

   The Designated Experts MAY raise issues related to the allocation
   request for further consideration before the assignments are made.


159	   6.  The Designated Expert MUST attempt to ensure that any request for
160	       a code point does not conflict with work that is active or
161	       already published within the IETF.

[major] s/MUST attempt to ensure/MUST ensure

[major] What is the intent of this point?  Clearly the request for a
specific codepoint value can't conflict.  What other types of
conflicts can exist?  Are you referring to similar/competing solutions
or something else?  If the work has already been adopted by the WG,
shouldn't the WG decide if a conflict exists (or at least should have
noticed one)?  Should this action be required (which I guess could
result in denial of the request), or is recommended ok?


163	   7.  Once the Designated Experts have granted approval, IANA will
164	       update the registry by marking the allocated codepoints with a
165	       reference to the associated document.

167	   8.  In the event that the document fails to progress to RFC, the
168	       Working Group chairs or AD SHOULD contact the Designated Expert
169	       to coordinate with IANA over marking the code points as
170	       deprecated.  A deprecated code point is not marked as allocated
171	       for use and is not available for allocation in a future document.
172	       The WG chairs may inform IANA that a deprecated code point can be
173	       completely de-allocated (i.e., made available for new
174	       allocations) at any time after it has been deprecated if there is
175	       a shortage of unallocated code points in the registry.

[minor - nit] "over marking"   I had to look this up to make sure
using this use us correct, but I don't think it is [1].  In any case,
simply "marking" should be enough.

[1] https://www.lexico.com/en/definition/overmarking


[major] "the Working Group chairs or AD SHOULD contact the Designated
Expert to coordinate with IANA"  The allocation process is to contact
IANA, who then engages the DEs for review.  Why wouldn't the
deprecation process be the same: contact IANA and have them engage the
DEs?   The end result should be the same, and it won't create an
exception (wrt rfc7120).

[minor] Note that if the WG Chair/AD and not the DE contacts IANA,
then this process is equivalent to the process in rfc7120, and this
point can be replaced with:

   In the event that the document fails to progress to RFC, the Expiry
   and deallocation process defined in [RFC7120] MUST be followed for
   the relevant codepoints.

[End of Review]