[art] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05

Tim Bray via Datatracker <noreply@ietf.org> Thu, 07 April 2022 21:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1233A178E; Thu, 7 Apr 2022 14:09:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Tim Bray via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-sidrops-rpki-has-no-identity.all@ietf.org, last-call@ietf.org, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164936575713.6320.18195760378286197162@ietfa.amsl.com>
Reply-To: Tim Bray <tbray@textuality.com>
Date: Thu, 07 Apr 2022 14:09:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/SKUKjoE9bPh62XsVezoD5mPAkz4>
Subject: [art] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2022 21:09:17 -0000

Reviewer: Tim Bray
Review result: Ready with Issues

I have reviewed draft-ietf-sidrops-rpki-has-no-identity-05.

It seems obvious that the WG needs to develop consensus whether or not a
document such as this, which essentially says "REALLY don't do what this other
RFC says not to", is a useful and appropriate tool. If no such consensus exists
we can stop reviewing revisions and save time.

If we assume that the document is useful and appropriate…

- In section 2, the title "The Bottom Line" doesn’t seem appropriate.  Could
this be expressed a little less figuratively?

- In section 2, the phrase "If it tried to do so, aside from the liability, it
would end in a world of complexity with no proof of termination, as X.400
learned." leaves me blank. If we assume that this is likely to make sense to
others likely to read this, disregard this.

- In section 2, the two MUST assertions in successive paragraphs are a little
puzzling. Is the second a proper subset of the first (looks like it to me)?  If
so, does it need to exist? Maybe it's trying to be an example, in which case it
should say "e.g." instead of "i.e."  If it's really an "i.e.", i.e. a
restatement of the first MUST, then why does the first MUST need to exist? 
Also, I found the second MUST hard to understand (reminder: not an expert in
this domain, feel free to disregard.)

And, since this is the second time I've been asked, I do have a philosophical
unease about this document.  Whenever there is a key-pair, there is an identity
in play: The entity which can arrange for documents to be signed with the
private key. Which in this particular case, means the entity which has at some
point in time could generate ROAs.  This draft implies that there could never
in any conceivable world be a useful result of having confidence that some
document was signed by whoever it is that at that point in time could generate
ROAs for some INR out there. Not the “owner”, not the “controller”, just
whoever it is does the ROAs. How can you know that that could never be useful? 
In general, when a protocol element or online resource can be used to do
something, and someone comes around saying “but you shouldn’t want to do that
thing”, I get nervous.