Reviewer: Carlos Pignataro Review result: Has Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://datatracker.ietf.org/group/rtgdir/about/ This I-D provides a useful clarification of consequences of using ROAs containing multiple IP prefixes, and provides recommendations to prevent those unwanted effects. This I-D usefully shows the problem and captures recommendations succinctly and effectively. I find this I-D useful, clear, and effectively written. A main small comment, on the important Section 4, Recommendations: 4. Recommendations Unless the CA has good reasons to the contrary, the issued ROA SHOULD contain a single IP prefix. Where announced prefixes align and would permit aggregation, but the aggregated one is not announced in Border Gateway Protoco (BGP), it is not recommended to aggregate multiple announced prefixes into one ROA by adjusting prefix length ([RFC9319] Section 5: Recommendations about Minimal ROAs and maxLength). Instead, each specific announced prefix should have its own ROA. This might have been discussed or brought up as it is quite contrasting, but any reason why "not recommended" and "should" in the second paragraph are lower case? This use seems normative, and my read pictured them uppercased. Nits: The Title and Abstract mention ROA but do not expand the abbreviation to "Route Origin Authorization", which needs expanding from https://www.rfc-editor.org/materials/abbrev.expansion.txt IDnits gets confused with the double square backets at: CAs should carefully coordinate ROA updates with resource certificate updates. This process may be automated if a single entity manages both the parent CA and the CA issuing the ROAs (scenario D in [[RFC8211] Section 3]). 3. Problem Statement As there is a single expiration time for the entire ROA, expiration will affect all prefixes in the ROA. If the ROA is not reissued in a timely manner, the whole set of IP prefixes will be affected. Had these prefixes been in separately issued ROAs, the validity interval would be unique to each ROA, and invalidity would only affected by re-issuance of the specific parent CA certificate which issued them. Grammo/Typo "*be* affected by" 4. Recommendations [...] Where announced prefixes align and would permit aggregation, but the aggregated one is not announced in Border Gateway Protoco (BGP), it Typo "Protoco" -> "Protocol" I hope these are clear and useful. Thanks! Carlos Pignataro. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
