Last Call Review of draft-ietf-sidrops-rp-06
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
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)