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

[Ben Maddison <[e-mail]>]

Hi Alvaro,

On 08/10, Alvaro Retana wrote:
> 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.

Ack. Will be included in -13.

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

Thanks for the explanation. Makes sense to me.

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

Ack. Will update in -13.

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

Agreed RE: BCP 185.

I'll await comments from the rest of the WG before touching updates.

Cheers,

Ben