Subject: [Sidrops] Alvaro Retana's Abstain on draft-ietf-sidrops-rp-06: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 10:39:15 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-sidrops-rp-06: Abstain

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

ABSTAIN

This document presents a nice summary, but I am ABSTAINing, and not standing in
the way of publication, because I don't think the contribution has enough
archival value and it could cause confusion.

  While the document tries to provide "a single reference point", it mostly
  points at other RFCs, which an implementer will have to consult anyway.
  IOW, this document seems to add to the list.

  No normative language is used, which is good from the point of view that
  this document doesn't define a specification, but in some places the text
  implies a requirement level, which may cause confusion -- again, the reader
  will have to consult the existing RFCs...

  The document itself recognizes the need to maintain it up to date: "This
  document will be update to reflect new or changed requirements as these
  RFCs are updated, or new RFCs are written." (s/be update/be updated)
  And the difficulty in doing so is evident in the fact that one of the
  referenced RFCs is already obsolete, but the text doesn't reflect that.

[Even though I'm ABSTAINing, I have a couple of comments.]

(1) This paragraph from §4.3 caught my eye...

   If there are valid objects in a publication point that are not
   present on a Manifest, [RFC6486] does not mandate specific RP
   behavior with respect to such objects.  However, most RP software
   ignores such objects and the authors of this document suggest this
   behavior be adopted uniformly.

...because in it the authors get away from pointing at the existing RFCs to
suggest a behavior.  That clearly should not be the job of this document.

(2) Nits:

s/RPKI make use/RPKI makes use

s/one of necessary/one of the necessary

s/RP is required perform/RP is required to perform

s/[RFC8208]and/[RFC8208] and

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Apr 2020 14:35:39 -0400

Alvaro,

> suggest a behavior.  That clearly should not be the job of this document.
You're right and we will delete the offending sentences. The WG has 
recently decided to try to adopt uniform procedures for dealing with the 
ambiguous areas in 6486 and this issue will be addressed there.
> s/[RFC8208]and/[RFC8208] and

We will make the edits you suggest.

Thanks for your review.

Steve