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

[Adrian Farrel <[e-mail]>]

Hello Alvaro,

I had to go back and read the document because I had completely forgotten what it says: it's been a while 😊

Thanks for the comments which I find sensible. I only have significant disagreement with the very last point.

Because of the timing (and not wanting you to have to invoke AD override on the locked I-D portal), I'll post a revision and we can fix it later if necessary.

Comments in line...

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

I believe the text captures the intent. That is, that the normal case is that a request should come from an I-D that has been adopted by IDR or is progressing as AD sponsored (this is #2 of 2.1), but there is a deliberate escape for that to allow *anything* so long as it gets review by the WG (this is #4 of 2.1). See more on this below.

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

[AF] Agree. Fixed.

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

[AF] I think I should debate that this is an instruction to the DE, not to the applicants. 
Just like the other 2119 language in the subsequent bullets.

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?

[AF] I believe that the WG wanted to allow an opening. I agree that there is no guidance given here to tell a DE when to vary this SHOULD. As one of the (current) DEs, I would apply good judgement, and I would use default to point 4 in any case, thus allowing the WG to shout.
So I think *this* SHOULD can remain, but maybe the one in point 4 needs to be tightened.

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?

[AF] Your question is completely reasonable. I see no reason not to compel the DEs on this.

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?

[AF] Yes, this is 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.

[AF] Per your question on point 2, I think these "SHOULD"s should be "MUST"s.

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?

[AF] Agree. I can see no reason to not review based on technical merits.

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

[AF] Right. The DEs cannot overrule IETF consensus. Stating whether or not they can seek to do something they can't do is without value.

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

[AF] I guess I'm not so confident of the perfection of a DE 😊
But given that the worst you can do is fire the DE for failing, we can make the change.

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

[AF] Consider the case where a non-WG document has been pointed to the WG and the WG maybe missed a point in its review. Compare this with a 5742 review of an Independent Stream conducted by the IESG. 

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

[AF] This is not about "overmarking"

[AF] Over what do the DEs coordinate with IANA?
They coordinate over marking the code points as deprecated.

[AF] A wide range of prepositions seem to be acceptable for use with the verb to coordinate. Coordinate on, coordinate about, coordinate over. Maybe "about" would be more easily received?

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

[AF] I think that this is supposed to refer only to a document in the IETF stream.

[AF] The persons who will discover this are the WG chairs and/or ADs. So they are clearly the first actors.

[AF] I agree that having the DEs only invoked by IANA is correct.

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

[AF] Nope, this is not early allocation. There is no expiry process. No need for renewing request. Etc. The whole point of this (from some people's perspective) is avoiding early allocation and simply going for allocation.

Best,
Adrian
[This bike shed intentionally left unpainted]