The Use of maxLength in the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidrops-rpkimaxlen-15

Thanks to Jean Mahoney for her ARTART review.

I agree with Alvaro's point about updating RFC 7115.  Also, should it become part of BCP 185 when published?  Also if you're extending what RFC 7115 says, shouldn't it be a normative reference?

It seems to me like RFC 8205 should also be normative rather than informative, but about that I'm less certain.

The last SHOULD in Section 1 seems a little out of place since it's just an introduction.  The real normative stuff is specified later in the document.

I'm not sure how or if the first two SHOULDs in Section 5 are related.  If they are related, are they not redundant?  If so, I suggest lower-casing the first one as the second one seems more direct.  Thanks for including some prose right below that describing when one might legitimately decide not to do what the SHOULD says.

In the last paragraph of Section 5, the triple SHOULD makes the whole paragraph feel mushy.  I would at least consider lower-casing the second one; it doesn't seem like wiggle room is appropriate there.

NITS
----

In Section 5.1:

OLD:

  Operational requirements may require that [...]

NEW:

  Operational requirements may stipulate that [...]

Thank you to Sean Turner for the SECDIR review.

** Section 5.

   In general, except in some special cases, operators SHOULD avoid
   using the maxLength attribute in their ROAs, since its inclusion will
   usually make the ROA non-minimal.

The clause “except in some special cases” seems unneeded as its implied by the use of the SHOULD (rather than a MUST).

(1) The running example makes the text clear -- but by being a minimal example (only a couple of prefixes are involved) it may oversimplify the potential operational complexity of maintaining a set of minimal ROAs.  

In particular, operators with short prefixes and many advertisements of both IPv4 and IPv6 may have a harder time keeping up with changes.  I would love to see some text around the challenges that applying the recommendations at scale may bring, which may also "result in a self-inflicted denial of service" (to use the description in §7).



(2) This text in §5 talks about the maintenance steps (review, replace, repeat):

   Operators that have existing ROAs published in the RPKI system SHOULD
   perform a review of such objects, especially where they make use of
   the maxLength attribute, to ensure that the set of included prefixes
   is "minimal" with respect to the current BGP origination and routing
   policies.  Published ROAs SHOULD be replaced as necessary.  Such an
   exercise SHOULD be repeated whenever the operator makes changes to
   either policy.

I assume that throughout the document "SHOULD" is used because, even though this is a BCP, the practice is only recommended.  That is not an issue for me, except for the last recommendation above: the "exercise SHOULD be repeated whenever the operator makes changes to either policy".  If the recommendations in this document are followed, a review of the system should be required, not just recommended.



(3) I find the Security Considerations misleading because none of the potential issues (even ones that could "result in a self-inflicted denial of service") are listed there.  I realize that previous versions had text that was moved elsewhere -- I won't insist on changing it back; this comment is here just for the record.



(4) "The recommendations complement and extend those in [RFC7115]."

It seems to me that this document should formally Update rfc7115 as there are related considerations mentioned there.  I checked the archive but couldn't find a related discussion.  Was an Update considered?



(5) [For the Responsible AD.]  I expect that this document will become part of BCP 185 (with rfc7115).  If so, please indicate that somewhere.

Clearing my discuss thanks to the change submitted in the latest revision.  My thanks to the authors for the quick response.

Hi,

I considered balloting this as a discuss (for a discussion), but this is outside my area of knowledge expertise.

Although the document indicates that the number of published ROAs should remain the same, since each ROA can list multiple prefixes, was any consideration to the potential increase in VRPs (if that is the right term) that this change will cause and whether this may negatively affect routers that are consuming the ROAs/VRPs?

Am I right in assuming that the number of valid ROAs that can be announced should effectively be bound by the number of BGP prefixes advertised for an AS and hence this shouldn't be a problem?

But other that the question above, I found this document to be very easy and pleasant to read.

Regards,
Rob