On 10 Mar 2022, at 10:17 am, Tim Bray via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tim Bray > Review result: On the Right Track > > ... > [It is also possibly the case that those better acquainted with RPKI will > instantly understand what the problem is and why the language herein will help > deal with it, in which case feel free to ignore most of my comments. ] > These are interesting review comments Tim. I’m not an author of this draft, but the points you make resonate with me. The draft appears to be a verbose restatement of Section 2.1 RFC6480. That original text is short enough to reproduce here: "An important property of this PKI is that certificates do not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be "descriptive". That is, the resource PKI is intended to provide authorization, but not authentication.” (There is also an even shorter exposition in RFC6487 (not references by this draft) which states in section 4.5: “Subject names are not intended to be descriptive of the identity of subject.” If the point of this draft is “go read RFC6480” then why do we need a meta-RFC to tell the reader to read another RFC? If the point of the draft is that “people are doing bad practices with this tech because they have not read the RFCs on this topic” then I find it difficult to comprehend why publishing yet another RFC would fix the underlying issue. If they didn't read the primary source RFCs then why should they read this one? Alternatively, if this draft is making a novel point that is not adequately covered in existing RFCs then the draft manages to hide that aspect so well that it is completely lost on me. So I clearly don't understand what track this draft is supposed to be on, right wrong. I clearly just don't understand the nature of the problem that publishing this draft as an RFC would solve. Geoff -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
