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

[Alvaro Retana <[e-mail]>]

On August 10, 2022 at 6:56:29 AM, Ben Maddison wrote:

Ben:

Hi!


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

That works for me.  I'm just looking for completeness, even if there's
some redundancy.




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

IMO, documents are generally self-contained -- the normative language
should be interpreted in the context of each document.  For example,
if an optional extension to a protocol is being described, the
required or recommended behavior should be seen in the context of
using that extension.

In the case of this document, it describes a practice that operators
may decide to take on, or not.  If they do, then the requirements and
recommendations should apply in the context of using the mechanism.

All this is to say that I would rather you require (MUST) the behavior
-- in the context of "if you're implementing this BCP then these are
the things you MUST do".  Specifically, all the actions above are
required.

If operators don't chose to follow what this document recommends, it
doesn't matter whether SHOULD/MUST were used.



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

This is a decision that the WG should make.  I would expect the Chairs
to lead a discussion and reach a consensus, one way or the other.
[Disclaimer: this is not my WG, so I'll rely on the Responsible
AD/Chairs on the way forward.]

FWIW, given the relationship with rfc7115, I think it's more important
to make sure this document is also part of BCP 185 than to use the
Updates tag.


Thanks!

Alvaro.