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]