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

Alvaro Retana via Datatracker <noreply@ietf.org> Tue, 07 April 2020 17:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 307543A0ACF; Tue, 7 Apr 2020 10:39:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman <nathalie@ripe.net>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.124.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <158628115517.31038.16065105204924712745@ietfa.amsl.com>
Date: Tue, 07 Apr 2020 10:39:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yoA-XCvoRoyN8KeWOK6hJWsVHAw>
Subject: [Sidrops] Alvaro Retana's Abstain on draft-ietf-sidrops-rp-06: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2020 17:39:15 -0000

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:



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