Reviewer: Dale Worley Review result: Ready with Nits 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://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sidrops-roa-considerations-07 Reviewer: Dale R. Worley Review Date: 2023-02-19 IETF LC End Date: 2023-02-24 IESG Telechat date: [unknown] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: I recommend the following minor changes in wording to maximize the clarity of the exposition. 3. Problem Statement Currently, no guidance was offered in existing RFCs to recommend what kinds of ROA are issued: one per prefix, or one ROA for multiple routing announcements. The problem of fate-sharing was not discussed or addressed. The use of "Currently" with "was offered" is non-parallel. There are multiple possibilities for making this parallel; given that section 1 uses the formulation "Prior to this document, there was ...", the formulation "Prior to this document, no guidance was offered ..." seems best. But the Editor may have a better idea. 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. This is not as clear as is desirable, I think. The first two sentences seem to be about the problem of the issuer of the ROA forgetting to re-issue it before expiration of the previous ROA. The third sentence seems to propose that instead of issuing a single ROA, multiple ROAs could be issued. But the problems caused by the issuer forgetting to re-issue the ROAs appears to be the same. I think you want to emphasize that using a single ROA for multiple prefixes requires that updates for all the prefixes must be synchronized in time, which could lead to complications (as discussed in the next paragraph). Perhaps, As there is a single expiration time for the entire ROA, expiration will affect all prefixes in the ROA. Thus, any changes to the ROA for any of the prefixes must be synchronized with any changes to other prefixes, especially time-limitations on authorization for a prefix. -- ... if each change in asID or routes for a given prefix reflects changes to discrete ROA ... I think you want to say "is reflected in a change to a discrete ROA". The current wording suggests that changes in the ROA cause changes in the asID or route, but since this section discusses human intentions rather than implementation processing, that's backwards. 4. Recommendations ... 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. You probably want "NOT RECOMMENDED" and "SHOULD" here. [END] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
