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
- [art] Artart telechat review of draft-ietf-sidrop… Tim Bray via Datatracker
- Re: [art] Artart telechat review of draft-ietf-si… Russ Housley
- Re: [art] Artart telechat review of draft-ietf-si… Randy Bush
- Re: [art] Artart telechat review of draft-ietf-si… Francesca Palombini
- Re: [art] Artart telechat review of draft-ietf-si… Randy Bush
- Re: [art] Artart telechat review of draft-ietf-si… Russ Housley
- Re: [art] Artart telechat review of draft-ietf-si… Randy Bush
- Re: [art] Artart telechat review of draft-ietf-si… Francesca Palombini