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

Tim: many thanks for this review. Randy, Russ: thanks for taking Tim’s comments into account. Very minor – I personally would vote for “The RPKI is for Authorization” to “To Summarize”, since that gives a better hint of the section content.

I balloted DISCUSS on the document because I have a question about the chosen track for the document, but I expect to remove the block after a short discussion about it.

Francesca

From: art <art-bounces@ietf.org> on behalf of Randy Bush <randy@psg.com>
Date: Saturday, 9 April 2022 at 00:10
To: Russ Housley <housley@vigilsec.com>
Cc: art@ietf.org <art@ietf.org>rg>, sidrops@ietf.org <sidrops@ietf.org>rg>, draft-ietf-sidrops-rpki-has-no-identity.all@ietf.org <draft-ietf-sidrops-rpki-has-no-identity.all@ietf.org>rg>, Tim Bray <tbray@textuality.com>om>, Last Call <last-call@ietf.org>
Subject: Re: [art] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05
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 mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art