Last Call Review of draft-ietf-sidrops-rp-06
review-ietf-sidrops-rp-06-opsdir-lc-comstedt-2020-03-23-00

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. Document
editors and WG chairs should treat these comments just like any other last call
comments.

I don't have any strong concerns or objections on it, and somewhat limited
experience with parts of it.  Which is partly why my first reaction is
wondering about the value of this draft in its current form.  I can see the
value of a checklist, given the same reasons that are outlined in the intro.
But reading this I'm not sure this is the most effective way to achieve that.
So with that background here are my comments and questions:

- The value of this is only relevant if its updated. I did notice the last
sentence of section one (btw, should be “This document will be updated”, not
‘update’) but given the importance in a document of this type I would like to
understand how this will be ensured?

- Should this follow normal practices and when it relaying specific standard’s
guideline it should capitalize those? E.g. 4.2.4 why would it not be
“Additionally, the certificate MUST contain an AS Identifier Delegation” and so
on? I realize this is an informational, doesn’t specify the usual terms section
in the beginning and the essence of RFC8174, but here it seems you would want
the normal defined meaning no?

- How was the “detail level” of this document determined? It seems at times,
probably partly because I’m not that familiar with many parts of this, that its
quite circular or pointing to a RFC section that immediately points elsewhere.
At times this has to do more with the docs it references (e.g. 2.5 and it's
reference to 6461 with its section 5 vs. 3) but still seems like a key question
for the usefulness of this document.

- Inconsistent referencing, sometimes to the specific section (or even
paragraph in a section) while other times to a large section covering more than
the point (e.g. 4.2.1 Manifest, “Specific checks for a Manifest are described
in Section 4” seems like it's specifically calling for 4.4 of RFC6486)

/nco