Subject: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 06:22:27 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-sidrops-rp-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this - I think that this document is useful.  One issue with the
IETF standard format is that it can be difficult to find which RFCs need to be
read to fully solve a particular problem, particularly considering that some of
those RFCs may be updated or obsoleted by other RFCs.  I agree with Warren's
comment that it would make a good living document, if IETF had such things.

In terms of reading the document, I noted that it uses quite a lot of acronyms
that I was not immediately familiar with and that are not defined in the
document.  Perhaps the document could be improved by having a short terminology
section?  The acronyms that didn't appear to be defined include CRL, INR, CA,
ROA.

4.2.1.  Manifest

   To determine whether a manifest is valid, the RP is required to
   perform manifest-specific checks in addition to those specified in
   [RFC6488].

I found the above paragraph as being unclear, in that I don't know what "those"
is referring to, and hence I suggest more clearly identifying “those” checks.

Finally, I agree with Alvaro's comment related to section 4.3:  This document
probably shouldn't be giving recommendations.  Perhaps better to just keep this
as "However, most RP software ignores such objects.", or combine it with the
previous sentence.

---

From: Di Ma <[email-masked]>
Date: Thu, 9 Apr 2020 22:38:09 +0800

Robert,

Thanks for your review.

Please find our response in lines.

> 2020年4月8日 21:22，Robert Wilton via Datatracker <[email-masked]> 写道：
> 

This document is intended for implementors or operators who have already read RFC 6480, which we mentioned in first paragraph of the Introduction. Thus we expect readers already know those acronyms and related concepts.

> is referring to, and hence I suggest more clearly identifying “those” checks.

In this context "those" refers to the generic signed object checks described in 6488. We will improve this sentence by stating that explicitly.

> as "However, most RP software ignores such objects.", or combine it with the

My co-author Steve has responded to Alvaro in terms of deleting the recommendations. 

Di