The 'I' in RPKI Does Not Stand for Identity
draft-ietf-sidrops-rpki-has-no-identity-07

I also had a similar question as to the intended status, but based on Francesca's comment this issue has already seen plenty of discussion and consideration.

My only other comment is, Walla-Walla Walla-Walla Walla

Thank you to Kyle Rose for the SECDIR review.

** Section 2
   Given sufficient external, i.e. non-RPKI, verification of authority,
   the use of RPKI-based credentials seems superfluous.

Consider rephrasing this sentence to clarify the application of these credentials.  For example:

Given sufficient external verification of authority (through non-RPKI mechanisms), the use of RPKI-based credentials is superfluous for <explain the application>.

** Section 4.
   Attempts to use RPKI data to authenticate real-world documents or
   other artifacts requiring identity are invalid and misleading.

Recommend describing what is mean by “invalid”.  In the cryptographic operation sense, these signatures are “valid”.  They were just “misleading” in terms of the degree of authenticity they are providing.

Thank you for the work done in this much needed document.

Thanks to Chris Morrow for the shepherd's write-up even if a justification for the intended status would have been welcome (esp on this one).

Please find below some minor comments:

Abstract: you may want to rephrase "This document attempts to put that notion to rest." as it is not really clear to non-English speakers.

Section 1: suggest to introduce the acronym "BB&S" at first use.

Section 2: should the claim "as X.400 learned" be explained or a reference be added ?

Hope this helps

-éric

Thank you for the work on this document.

Many thanks to Tim Bray for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/SKUKjoE9bPh62XsVezoD5mPAkz4/, and to the authors for addressing Tim's comments.

For the record, I did have a question about proper track for this document, but the authors have confirmed that "Standard track" was discussed and agreed within the WG, although the document might have felt more like Informational to me.

Francesca

Thanks for this. The reference to Bill’s Bait & Sushi brought a tear to my eye. I do have a couple comments, hope they help.

1. Section 1 has 

                            The RPKI provides authorization to make
   assertions only regarding named IP address blocks, AS numbers, etc.

While the "etc" normally wouldn’t be concerning, in the context of this document I think it is a little bit problematic, because you're trying to be precise about what the RPKI can’t be used for, but “etc” is the opposite of precise, and invites the reader to use their imagination. Maybe replace with “and other INRs”?

2. Section 2 has 

   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.

First, this paragraph is followed by a near–duplicate after the page break, except that one starts with “i.e.“. Probably a cut and paste error or something like that.

Second, The paragraph contradicts itself. The first sentence has a nice clear MUST NOT. But the second sentence provides a “without some” escape hatch. The implication of the second sentence is that if some formal external authorization and authority exists, then the MUST NOT doesn’t apply, rather like a SHOULD NOT/MAY. I realize that in the following paragraph you say that it “seems superfluous” for someone to avail themselves of the implied MAY, but still… which is it? The conflicted nature of this paragraph makes me think you're trying to thread some needle which I can't perceive -- but it sure would be clearer if it stopped after the first sentence, or if the second sentence were cut off after the word "transactions" (so, delete starting from "without"). If you made either of those edits I guess the "seems superfluous" paragraph wouldn't be needed any more either.

My 2 Elbonian cents worth.

The IANA review of this document seems to not have concluded yet.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "invalid"; alternatives might be "not valid", "unenforceable", "not
   binding", "inoperative", "illegitimate", "incorrect", "improper",
   "unacceptable", "inapplicable", "revoked", "rescinded"

Thanks to Matt Joras for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/XxrooGApKU44C2d967vyx73Ydjw).

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 1852, nit:
> als may be userid/password (with two factor authentication one hopes), a har
>                                  ^^^^^^^^^^
When "two-factor" is used as a modifier, it is usually spelled with a hyphen.

Paragraph 1868, nit:
>  client browser certificates, etc. Hence schemes such as [I-D.ietf-sidrops-r
>                                    ^^^^^
A comma may be missing after the conjunctive/linking adverb "Hence".

BCP doesn't seem appropriate, but I wish there was a stronger document status we could give this.

In Section 2:

   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.

Is there a reference describing the X.400 lesson that could be included here?

   Registries such as the Regional Internet Registries (RIRs) provide
   INR to real-world identity mapping through whois and similar
   services.  They claim to be authoritative, at least for the INRs
   which they allocate.

I think "WHOIS" is properly (or at least traditionally) in all-caps.

Thanks for this useful document.  

As others ADs have noted, this document felt like it should be informational rather stds track, although I think that I get why you want to push this through as stds track.

If only we were allowed to use arbitrary CSS in the HTML version of the RFC then you have had the "does not" in the title in bold red flashing text. ;-)

Rob

Thanks for working of this document. It is regretful that we need to have this kind of documentation to clarify or warn people and I hope this works.

I have also struggled with the correct type of this document as some of other AD also did, specially after reading the shepherd's write-up which says "The document is merely text discussing the problem." There has been some discussion on the IESG mailing list and among the ADs, and Francesca confirmed referring to the authors that PS is what discussed and agreed. With that in mind I am casting "no objection" ballot.