Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rp-06

[Di Ma <[e-mail]>]

Niclas,

Thanks for your review.

Please find our responses in-lines.

> 2020年3月24日 08:08，Niclas Comstedt via Datatracker <[e-mail]> 写道：
> 
> Reviewer: Niclas Comstedt
> Review result: Has Nits
> 
> 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?

It is a typo. The last sentence of section 1 should be “This document will be updated to reflect new or changed requirements as these RFCs are updated, or new, relevant RFCs are written.” RFC documents are updated or obsoleted as per new RFCs are published. So this document will be updated if the referenced RFCs are updated or obsoleted. 


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


Yes. We don’t use the capitalized keywords such as MUST because this will be an informational RFC. If the wording ‘must not’ could bring about confusion we are fine with using “required to” instead of “must” and “not allowed to” instead of “must not”.


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

The level of detail does vary in places. The variability is based on our perception of what an implementor needs to be reminded of with regard to different aspects of RPKI standards. I am leading a team that has implemented RPKI RP software, and the co-author Dr. Steve Kent led a team that developed the first RPKI RP software. He is also the author of several RPKI RFCs. Based on our collective experiences, we have chosen to place more emphasis on some areas vs. others, hence the variability you noted.


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

We have tried to be consistent in terms of referencing but, as we noted above, our experiences in developing the RPKI standards, and in developing software that implements the standards, motivates us to provide varying levels of detail in different parts of the document. This carries over to the references as well.

Di