Telechat Review of draft-ietf-sidrops-manifest-numbers-07
review-ietf-sidrops-manifest-numbers-07-secdir-telechat-leiba-2025-08-08-00

This is well written and clear; thanks for that.  I have some minor comments.

A small point: The abstract seems more detailed than is necessary for an
abstract.  I would shorten it and allow the introduction, which the abstract
currently repeats, to stand as the more detailed version.  But if you like it
as it is, please just ignore this suggestion.

SUGGESTION
   The Resource Public Key Infrastructure (RPKI) makes use of signed
   objects called manifests, each of which includes a "manifest number”.
   This document updates RFC9286 by specifying issuer and RP behaviour
   when a manifest number reaches the largest possible value, a situation
   not considered in RFC9286.
END

It’s not obvious that Section 2 makes the updates to 9286 until one reads the
first sentence of Section 3.  I have two suggestions, either of which should
make it clearer:

1. Change the title of Section 2 to something like “Manifest Number Handling:
Update to RFC 9286”.

2. Add a one-sentence paragraph to the beginning of Section 2 that says
something like, “This Section updates [RFC9286] for the handling of manifest
numbers.”

The last sentence of Section 2 says, with regard to RFC 8488, “The approach set
out in the current document is different from that approach.”  It’s not clear
to me whether “the current document” means “this document” (I think that’s what
you mean) or RFC 9286.  I suggest replacing that phrase with one or the other
to make it explicit.

Question for the Security Considerations:  Is it possible for an attacker to
force a “largest value” situation and take advantage of that to falsify a
route?  If the situation can only be created internally by the CA, that in
itself is worth mentioning, to make that robustness clear.