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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux