Document: draft-ietf-sidrops-8210bis Title: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Reviewer: Peter Yee Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-sidrops-8210bis-25 (one revision behind) Reviewer: Peter Yee Review Date: 2026-07-20 IETF LC End Date: IESG Telechat date: Not scheduled for a telechat Summary: This draft is a revision of the RPKI-Router protocol. While I reviewed -25, the diff between that and -26 doesn’t appear to be major. I may have some small duplications of changes already made in -26. The document has some minor issues and a healthy helping of nits. [Ready with Issues] Major issues: None Minor issues: Page 6, section 4, 3rd paragraph, 2nd sentence: What happens if the connection to a cache goes away, and it is possibly the last cache keeping a VRP in effect? Page 7, 2nd paragraph: How was the value of “an hour” chosen and is it appropriate? It seems somewhat arbitrary to drop in here without explanation. Page 21, 2nd paragraph, last sentence, “the union of multiple ASPA records”: This would seem to contradict section 5.1 of -aspa-profile. Even if one assumes that there could be multiple, differing ASPA objects for a particular CAS, simply taking the union of those objects might not be desirable if the CAS were trying to remove a PAS by creating a newer object that didn't contain a PAS found in a previous object. Nits/editorial comments: Page 3, section 1, 3rd paragraph: I don’t think this paragraph adds much beyond what’s already in the table of contents. It could be dropped without much lost. Page 4, section 1.2 name: change “RFC8210” to “RFC 8210”. The spaceless form is only used in references. Page 4, section 1.2, 3rd bullet item: change “affect” to “effect”. Page 4, section 1.2, 5th bullet item: change “64k” to “64 KB”, which is, I presume, the desired quantity and unit. Page 4, section 2, Global RPKI definition: I take it this set of servers is what's meant by Global RPKI? How about rewording to "The Global RPKI is the distributed set of servers at the IANA, Regional Internet Registries (RIRs), National Internet Registries (NIRs), and ISPs in which the authoritative data of the RPKI are published." That's still a passive sentence and leaves out the who does the publishing part. I’m not convinced I have this right either. But the current definition is just a statement that does not tie itself directly to the term being defined. Page 4, section 2, CA definition: This is not a great definition of a CA unless its definition is merely that of an authoritative data publisher. Does it do nothing else? Page 5, Serial Number definition, 1st sentence: if serial number wraps, then it can hardly be defined as strictly increasing. Perhaps change “which” to “until it”? Page 5, Serial Number definition, 6th sentence: “commensurate” deals with sameness of extent (or size, duration, etc.), so I don't find it well suited in this use or anywhere else in the document. How about changing "is not commensurate" to "has no correspondence". I’ll raise this separately in several other places. Page 5, Session ID definition, 1st sentence: it’s not clear how this binding is accomplished. Page 5, Session ID definition, last sentence: change the semicolon to a comma. Change “are commensurate” to “correspond”. Page 5, Payload definition, 1st sentence: consider changing “mechanisms” to “messages”. Page 5, Payload definition, 2nd sentence: The use of IPvX is potentially ambiguous. While I'm able to intuit this to read IPv4/IPv6, it may not be clear to all readers what is meant here. Consider https://ieeexplore.ieee.org/abstract/document/11473012, for example. Or https://www.linkedin.com/pulse/ipvx-our-future-alexey-shkittin-6xmhf/. It might be better to write IPv4/IPv6. Insert “and” before “ASPA”. Page 6, section 4, 3rd paragraph, last sentence: change “withdraw” to “withdrawal”. Page 7, 4th paragraph: change “two many” to “too many”. Page 7, section 5.1, 1st paragraph: insert “may” before “contain” since not all PDUs contain all of the data elements. Page 7, section 5.1, Serial Number definition: it would be good to define what a cache epoch is or give a reference. Page 8, Session ID definition, 1st paragraph, 2nd sentence: append a comma after “i.e.”. Append a comma after “data)”. For the word “bind” in the sentence, I take this to mean that it is the combination of session ID and sequence number that is the unique identifier for any particular cache state. I’m not sure that’s a binding. Page 8, Session ID definition, 1st paragraph, 3rd sentence: change “is commensurate” to “corresponds”. Page 8, Session ID definition, 2nd paragraph, 3rd sentence: append a comma after “other’s”. Page 8, Session ID definition, 3rd paragraph, 2nd sentence: change “are not commensurate” to “do not correspond to each other”. Page 8, Session ID, 3rd paragraph, 3rd sentence: change “are commensurate” to “correspond”. Page 8, Session ID, 4th paragraph, 3rd sentence: an explanation of what constitutes “enough” would be helpful. Change “solve” to “resolve”. Page 9, 2nd full paragraph, 1st sentence: append “or” after “pseudorandom value” and delete the comma there. Delete “, et cetera”. Page 9, Flags definition, 1st paragraph, 2nd sentence: change “withdraw” to “withdrawal”. Page 9, Flags definition, 3rd paragraph: change “existant” to “existent”. Page 11, Figure: All figures should be labeled with “Figure #” and a name of some sort. It makes it easier to reference a particular figure. The use of “=” is inconsistent in the figure (and in all other figures). Length is given with an equals sign, but Protocol Version and PDU Type are not. It’s not a major problem, just slightly inconsistent. Page 11, 2nd paragraph after figure: change “are commensurate” to “correspond”. Page 12, 1st paragraph after figure: change “which” to “that” to satisfy some picky grammarians who prefer which for independent clauses and that for dependent clauses. Page 15, 2nd paragraph: change “to to” to “to”. Page 18, 1st paragraph after the figure: delete “they payload of”. Or change “they” to “the”, but I still prefer the deletion. Page 18, 3rd paragraph after the figure, 2nd sentence: the tuple should include the low-order bit of the flags (and specifically that it set to 1), otherwise a withdrawal of a previously announced Router Key could result in sending a Duplicate Announcement Received error. Page 20, 2nd paragraph: Merge this paragraph with the 2nd paragraph following the figure on page 19. That might include deleting the first sentence of this paragraph. Page 20, 3rd paragraph, 2nd sentence: In the truncation case, how was 4 chosen and what is the receiver supposed to do with the truncated PDU? Page 20, 2nd paragraph after the figure: I was under the impression that the Customer ASN was simply the ASN that had stated its list of Provider ASNs in an ASPA object. I don't understand this text in the context of draft-ietf-sidrops-aspa-profile. Page 20, 4th paragraph, 2nd sentence: append a comma after “Provider Autonomous System Number”. Change the “or” to “otherwise”. Change “Error PDU” to “Error Report PDU”. Change “code” to “Error Code”. Change “is” to “MUST be”. Page 20, 4th paragraph, 3rd sentence: append a comma after “AS 0”. Change “or” to “otherwise”. Change “Error PDU” to “Error Report PDU”. Change “code” to “Error Code”. Change “is” to “MUST be”. Page 23, section 7, 1st paragraph, 1st sentence: change “a RPKI” to “an RPKI” unless RPKI is read as rip-key or some such. Should “RPKI-Router” be “RPKI-Rtr”? Page 23, section 7, 2nd paragraph, change “Error Report” to “Error Report PDU”. Page 23, section 7, 3rd paragraph: change “Protocol Version Q,” to “Protocol Version Q;”. Change the following “the” to “The”. Append “then” after “is”. Page 23, section 7, 4th paragraph, 1st sentence: change “the the” to “the”. Change “verion” to “version”. Change “Error Report” to “Error Report PDU”. Section 23, section 7, 4th paragraph, 2nd sentence: Delete the semicolon after Report. Then change “Error Report” to “Error Report PDU”. Page 23, section 7, 7th paragraph: append “with Error Code 4 (“Unsupported Protocol Version”)” after “Error Report PDU”. Page 24, 1st (partial) paragraph, 1st full sentence: change “has” to “had”. Page 24, 3rd full paragraph, 3rd sentence: append a comma after “etc.”. Change “they” to “it”. Page 24, 4th full paragraph: change “Error Report with” to “Error Report PDU”. Change “error code” to “Error Code”. Page 25, 1st paragraph, 2nd sentence: change “are commensurate” to “correspond”. Page 25, section 8.2, 1st paragraph after the figure, 3rd sentence: what’s the derivation “one per minute”? Should that be mentioned? Page 27, both figures at the top of the page: elide “PDU” after “Error Report” to match other such usage. Page 27, section 9, 1st paragraph: append a comma after “persistent”. Page 28, 1st paragraph: append a comma after “e.g.”. Change “Error PDU” to “Error Report PDU”. Append “with Error Code” after that. Consider appending (“Transport Error”) after “10”. Change both lower case “should” occurrences to “SHOULD”. Page 28, 5th bullet item, 2nd sentence: regarding “Conformance”: RFC 9325 (part of BCP 195) has lots of SHOULD NOTs. Would those suffice? Perhaps a more detailed explanation of what level of conformance is desired would be helpful. Page 31, 9th paragraph, regarding “SHOULD attempt”: what happens if the router fails to do so. Motivate the “SHOULD” either positively or negatively. Page 37, 1st paragraph, 1st sentence: bracket the “e.g.” in commas. Page 37, 2nd paragraph, 2nd sentence: delete the comma after “transient”. Page 37, section 11.4, 2nd paragraph, 1st sentence: change “Ordering Error PDU” to “Error Report PDU with Error Code 11 (“Ordering Error”)”. Page 39, section 13, 1st paragraph: I would not describe this protocol as a security protocol. I might describe TLS or CMS as a security protocol. I would describe RPKI-Rtr as mainly a PDU transport and definition document with the data being conveyed having operational and security relevance. Page 40, Transport Security, 2nd paragraph, 2nd sentence: change “monkey in the middle” to “monkey-in-the-middle”. Change the semicolon into a comma. Page 40, Transport Security, 3rd paragraph, 1st sentence: append a comma after “So”. Change “are” to “is”. Page 40, Transport Security, 4th paragraph, 1st sentence: delete “very”. Page 40, Transport Security, 5th paragraph, 1st sentence: append a comma after “i.e.”. Page 40, Transport Security, 6th paragraph, 1st sentence: change “spoofing/corruption” to “spoofing and corruption”. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
