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

Hi Simon,

(adding mptcp to the discussion)

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Simon Hobson
> Envoyé : mardi 10 novembre 2015 17:14
> À : dhcwg@ietf.org
> Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
> (MPTCP)
> 
> mohamed.boucadair@orange.com 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.

[Med] Agree on the use case. BTW, this is governed by the following: 

https://tools.ietf.org/html/rfc7227#section-19: 

"  For some options, such as the options required for the functioning of
   DHCPv6 itself, it doesn't make sense to require that they be
   explicitly requested using the Option Request Option.  In all other
   cases, it is prudent to assume that any new option must be present on
   the relevant option request list if the client desires to receive it."

and https://tools.ietf.org/html/rfc7227#section-21:  

"As a convenience to the reader, we
   mention here that the server will send option foo only if configured
   with specific values for foo and if the client requested it."

My initial comment was: if we allow the server to return an option a client didn't asked for, we need to add a sentence like this one in the client's behavior section:

"The DHCP client MUST be prepared to receive the DHCP MPTCP Concentrator
   Option even if it didn't include it in the request."

(I do personally think this adds extra complexity without any guarantee that a broken implementation will make use of an option it didn't asked for).

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

[Med] That's the point. Does it really matter to have a "SHOULD NOT" instead of "MUST NOT" if the standard behavior will be broken anyway?

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

[Med] Yes; that's implementation-specific. My point is not about "how" but that the sever should be able to do that using "some means". 

> 
> 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.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg