Re: [Idr] AD Review of draft-ietf-idr-ext-opt-param-09

[John Scudder <[e-mail]>]

Hi Alvaro,

> On Mar 22, 2021, at 5:15 PM, Alvaro Retana <[e-mail]> wrote:
...
> Can we at least take out "of any length"?  As you say, if someone else
> changes the size of the OPEN message, the enclosing PDU will still
> limit the size -- and it won't be "of any length".
> 
> BTW, now that I'm reading this again (and the next paragraph from
> -10), I think the second sentence above is not needed at all

Can you say more about why you think it’s not needed? Without it, I think it would be reasonable for an eager beaver to decide to treat an Extended Optional Parameter Length of (say) 16 as a hard error, because the spec says not to encode short lengths using the extended format. The authors thought it would be overly strict of an implementation to do that, which is why the text says what it does. Apparently the WG agrees with us, at least as far as we can tell by passing a WGLC. I think taking the text out would be a normative change. Furthermore, we might then want to ask ourselves: are we just deliberately underspecifying? Or do we need to say something in the errors section about this (new) error?

However I would be fine with dialing in “of any length” more tightly:

> (and how
> can "MUST be prepared" be enforced anyway?).
> 
> OLD>
>   In the event that the length of Optional Parameters in the BGP OPEN
>   message does not exceed 255, the encodings of the base BGP
>   specification [RFC4271] MUST be used without alteration.  However, an
>   implementation MUST be prepared to accept an OPEN message that uses
>   the encoding of this specification for Optional Parameters of any
>   length.

How about “(However, an implementation MUST accept an OPEN message that uses the encoding of this specification even if the length of Optional Parameters is 255 or less.)”

This gets rid of “be prepared” as well, which it sounds like you didn’t like.

—John