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

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Aug 10, 2022 at 4:37 AM Ben Maddison <[e-mail]> wrote:

> > 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?
>
> See my earlier response/question to Alvaro on this point. Guidance
> welcome.
>

I appreciate that the author of RFC 7115 doesn't support this work, but
presumably that feedback has been part of the consensus process, and the
consensus is to proceed with publication.  And if this document extends
what RFC 7115 says, I contend that it has to be a normative reference
because you can't understand this document without also understanding RFC
7115.

I'll leave it to the responsible AD to resolve the "Updates" question.  It
seems to me that this qualifies under the notion that people reading RFC
7115 really should at least be aware that this work also exists (in the
sense that "Updates" creates a forward pointer to this), but that AD will
have better context around that question.


> > 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.
>
> That is the only place where that particular recommendation is made.
>
> We could move it into its own section, at the cost of making an already
> long-ish document even longer?
>

Another point I'll defer to the responsible AD, but it seems odd to me to
have normative text in an Introduction which is, almost by definition, not
a place for normative text.  It's introduction, painting the picture for
why this work is being done, with the actual work following.


> [...]
>
> Hope that clarifies?
>

Fair enough.


> > 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.
>
> As per my response to Alvaro, I think either 3 x SHOULD or 3 x MUST are
> the only correct options here. Using MUST in an ops BCP seems like
> over-reaching to me, but this can be changed if you think it's
> appropriate?
>

It looks like you've gone with all MUSTs, which I think solves my concern,
but just for the sake of discussion:

I don't think  MUST is over-reaching.  You're effectively saying "If you
are compliant with this BCP, then you have to do this."

The triple-should gives an operator quite a bit of latitude.  The way I
read it in -12, I as an operator could not do any of the things in there
and still be able to say I'm compliant with the BCP.  My question was
basically challenging the idea that you really intended to allow that.

-MSK