Document: draft-ietf-sidrops-manifest-numbers Title: Resource Public Key Infrastructure (RPKI) Manifest Number Handling Reviewer: Barry Leiba Review result: Has Nits 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
