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

[Ben Maddison <[e-mail]>]

Hi Murray,

Thanks for your comments. Feedback in-line...

On 08/09, Murray Kucherawy via Datatracker 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.

> It seems to me like RFC 8205 should also be normative rather than informative,
> but about that I'm less certain.

Beyond making the simplifying (and true) assumption that BGPsec is not
deployed in the wild for the purposes of the examples, RFC 8205 doesn't
feature here. More importantly, its deployment would not (in my view)
change the recommendations made. Thus, I think informative is the right
ref type.

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

> I'm not sure how or if the first two SHOULDs in Section 5 are related.  If they
> are related, are they not redundant?  If so, I suggest lower-casing the first
> one as the second one seems more direct.  Thanks for including some prose right
> below that describing when one might legitimately decide not to do what the
> SHOULD says.

They are certainly related, but not quite the same.

The intent is to say: "create minimal ROAs; doing so probably means
foregoing maxLength, but there exist cases where a ROA with maxLength
can be minimal"

The first sentence of the third paragraph is the canonical case where a
ROA can both include maxLength and be minimal.

Hope that clarifies?

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

> NITS
> ----
> 
> In Section 5.1:
> 
> OLD:
> 
>   Operational requirements may require that [...]
> 
> NEW:
> 
>   Operational requirements may stipulate that [...]

I don't like "stipulate" here. How about "necessitate"?

Cheers,

Ben