Hello, I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Review: I believe this document is "Ready with comments". Nits and comments below. 5.1. Fields of a PDU The PDU fields are using slightly confusing nomenclature: An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element. -> Max Length An 8-bit unsigned integer denoting the shortest prefix allowed for the Prefix element. -> Prefix Length If the longest is called max, shouldn't the shortest be called min, rather than "prefix"? Also note "by" vs. "for". 5.11. Error Report s/PDUS/PDUs/ 6. Timers If Expire is < Refresh and/or Retry, then the implementation would be forced to go against the SHOULD. Does it make sense to require Expire to be > max { Refresh, Retry } ? 7. Version Negotiation All the combinations of versions will lead to a successful negotation. There is just one thing which is implicit (and one could argue "goes without saying), but why not make it explicit: "Routers MUST always start the negotiation with the highest version they support otherwise configured otherwise." The text as it currently stands does not mandate that, and a router which *supports* 0 and 1 could choose to start a version 0 conversation, leading to a successful version 0 connection. If that is not desirable by the protocol designers, they should make sure that this degree of freedom is taken away. 8.1 and 8.2: "See Section 6 for details on the required polling frequency." Just language: section 6 does not specify a signle required frequency. It specifies a minimum interval (SHOULD for Refresh/Retry) and a maximum interval (MUST for Expire), and the exact frequency is free to choose by the implementation: The actual frequency lies in a band between 0 and Expire (if clients choose to ignore the SHOULDs) or Refresh/Retry and Expire (if they do not). A text like: "See Section 6 for details on the lower and upper bounds for the polling frequency." would be more explicit. 9. Transport / Authentication So there is a (comparatively old-ish) protocol which would be a good mandatory-to-implement transport. But then this RFC doesn't make it so because it is not available on all platforms? The sentence: "It is expected that, when the TCP Authentication Option (TCP-AO) [RFC5925 ] is available on all platforms deployed by operators, it will become the mandatory-to-implement transport." unnecessarily creates a chicken-and-egg situation. Considering that there is already a version 0 which can be used by older routers not doing RFC5925, why not establish RFC5925 requirements as the baselines *right now in this RFC*? If version 0 is not good enough and router vendors want the features of version 1, they can update their code for TCP-AO transport along with the code updates they have to do anyway to implement this RFC here. 9.2. TLS "Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS." The preceding text makes clear that DNS identification is done by the client (router), so it sure needs to implement that. However the server identifies clients by their subjectAltName:iPAddr (NOT the DNS name). So, the server doesn't have to implement this, right? It only needs to be able to present a certificate with that property inside, but that's not called "implementation". 10. "See Section 6 for details on what to do when the client is not able to refresh from a particular cache." Section 6 defines timing parameters and has no info on what to do if things don't work. You may want to reference some other text? (But actually the text in the exact section 10 here talks about that very topic?) 11. This section contains advice on how caches should talk to RPKI. The scope of the rest of the document is about routers talking to caches. And this section in particular is about deployment scenarios between routers and caches. IOW, the last two paragraphs look they they should in some other RPKI deployment considerations document? 12. Error code 8: "The received PDU has a Protocol Version field that differs from the protocol version negotiated in Section 7 ." The router did not negotiate anything in section 7. It negotiated the protocol version during its connection setup. It was probably following the rules that this RFC gives in section 7, but the sentence still sounds weird if written like that. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66