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

Randy Bush <randy@psg.com> Fri, 08 April 2022 22:09 UTC

Return-Path: <randy@psg.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0183A18F9; Fri, 8 Apr 2022 15:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1S_-Ajb84cT; Fri, 8 Apr 2022 15:09:28 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C36E3A18F4; Fri, 8 Apr 2022 15:09:28 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.93) (envelope-from <randy@psg.com>) id 1ncwnE-000SbB-Ic; Fri, 08 Apr 2022 22:09:24 +0000
Date: Fri, 08 Apr 2022 15:09:23 -0700
Message-ID: <m2tub3i5ws.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Tim Bray <tbray@textuality.com>, art@ietf.org, draft-ietf-sidrops-rpki-has-no-identity.all@ietf.org, Last Call <last-call@ietf.org>, sidrops@ietf.org
In-Reply-To: <10652A23-5534-423B-B8AC-3320881CA38A@vigilsec.com>
References: <164936575713.6320.18195760378286197162@ietfa.amsl.com> <10652A23-5534-423B-B8AC-3320881CA38A@vigilsec.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-8859-7"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/08cvBSeSzJdXWJZsccObs4Gak-E>
Subject: Re: [art] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 08 Apr 2022 22:09:31 -0000

tim and russ:

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

as it passed wglc and is in ietf last call, is it not safe to presume
this is the case?  i confuse easily.  what am i missing here?

the last time chasing this woozle around the tree, i thought we made
pretty clear that, sad to say, history has shown it is indeed needed.

>> - In section 2, the title "The Bottom Line" doesn’t seem appropriate.
>> Could this be expressed a little less figuratively?
> 
> I am not really sure what section title works better.  How about:
> 
> 	The RPKI is for Authorization

how about "To Summarize?"

>> - 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.
> 
> How about we drop the end of the sentence?

the X.400 ref was dropped the other day per murray kucherawy's review.

>> - 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.)
> 
> I suggest that we merge the two paragraphs:
> 
>    PKI operations MUST NOT be performed with RPKI certificates other
>    than exactly as described, and for the purposes described, in
>    [RFC6480].  That is, RPKI-based credentials of INRs MUST NOT be
>    used to authenticate real-world documents or transactions without some
>    formal external authentication of the INR and the authority for the actually
>    anonymous INR holder to authenticate the particular document or
>    transaction.
> 
> Hopefully this make it clear that he second MUST NOT is talking about
> an example of the first one.

to quote a grandchild, whatever.

unless an AD requests otherwise, let's hold publishing a revision for a
while.

randy