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

[Ben Maddison <[e-mail]>]

Hi Murray,

On 08/12, Murray S. Kucherawy wrote:
> 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.

Agreed. This was changed in the previous revision.

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

Ack. I tend to agree that having that pointer is helpful, but I'll await
Warren's guidance.

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

I take your point. I'll take a stab at this tonight.

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

Yes, Alvaro made essentially the same point - hence the update in the
last revision.

Thanks again for your input.

Cheers,

Ben