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