Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

[Simon Hobson <[e-mail]>]

[e-mail] wrote:

> The proposed text was to explicitly show to Simon the complexity induced by the request to handle broken implementations.

Which IMO you failed to do.

If a client receives an option that it doesn't know what to do with - it is already required to ignore it. As Bernie points out, you do not need to specify that as that's already "standard requirement" for all options.
You also don't need to specify that the client must request it - that too is standard requirement.

The suggestion was simply that you change one instance of "must not" to "should not".
In the ideal world, no client would ever want an option but not request it - "should not" is sufficient instruction for a normal server, serving a normal client, with nothing broken, to not send the option if not requested.

But in the non-ideal world, sometimes the admin needs to override the strictly correct operation so as to deal with something that isn't completely ideal. Stating "must not" precludes the admin from working around a problem, and technically means an implementation must prevent him from trying*. In the real world there are broken things we can't fix - only work around the broken bits.

You don't need to specify any mechanism for that, you don't even need to reference the possibility - just don't prohibit it. So the sole change required is to change "must" to "should" in one place.

* If the server "must not" send an option the client didn't ask for, then strictly speaking, an implementation "must not" have a means for the admin to override that parameter list.