Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-rpkimaxlen-12: (with COMMENT)

[Ben Maddison <[e-mail]>]

Hi Alvaro,

Thanks for the review. Some responses to your comments below...

On 08/08, Alvaro Retana via Datatracker wrote:
[..]
> (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).

I doubt that such an operator would fail to see that their situation is
more operationally complex than the example.

Perhaps something along the lines of:

    The recommendations made in section 5 are likely to be more onerous
    for operators utilising large IP address space allocations from
    which many more-specific advertisements are made in BGP. Operators
    of such networks are encouraged to seek opportunities to automate
    the required procedures in order to minimise manual operational
    burden.

Even the above seems a bit tautological to me! Thoughts?

> (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.

Correct. MUST feels weird in an Ops BCP. Maybe that's just me.

> 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.

I think they should either all be MUST or all be SHOULD. Changing only
the last sentence would mean performing a review initially is
operational, but performing subsequent reviews is required, which I
think is poor advice.

I generally think MUST is odd in this kind of doc, but I'm happy to
accept guidance on this.

> (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.

Ack. The whole document is really an enumeration of security
considerations, and reiterating every conclusion in that section for the
sake of form did not seem to be productive.

> (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?

To the best of my recollection, no.

I'm inclined to agree that this should probably update 7115. Given that
the original author of that document has indicated he is, at best,
lukewarm about this draft, I'd appreciate some guidance on the etiquette
here?

Cheers,

Ben