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

[Simon Hobson <[e-mail]>]

[e-mail] wrote:

> But, in addition to updating the client's behavior so that it must be prepared to receive the option even if it didn't requested for it

I think the specific use case was that the client is expecting it, but just doesn't ask for it. I'm no expert user, but I have come across stuff where a vendor has built server and client, and makes the two work together - but not in a standards compliant way. Since in some cases the vendor has zero interest in working with anything but an "all mine and nothing else" network environment, they may have no interest in fixing a client that is broken according to the standards, but which is working with their server which is also non-standards compliant in a way that makes the pair work together.

> ... the server must support a logic to decide which clients should be supplied with the mptcp option.

Typically that would be done by the admin, classifying the clients by some means, and then overriding the requested parameter list. This is certainly possible with the ISC server.

I can't remember what it was for (it was a good few years ago with a different hat on), but I know I've had to provide an option list override for a problematic client in the past - it was most likely a done by adding it to a "host" declaration with the ISC server.

> Although I understand the arguments you raised, I'm not convinced the text should be relaxed. 

As Niall points out, it prohibits an admin faced with a broken client from working around the issue.