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

Re-,

The change you asked for is as follows: 

==============
OLD:
   The DHCP server MUST NOT reply with the DHCP MPTCP Concentrator
   option unless the client has explicitly requested for it.

NEW:
   The DHCP server SHOULD NOT reply with the DHCP MPTCP Concentrator
   option unless the client has explicitly requested for it.
==============

Comments from the wg about this change is welcome. 

Cheers,
Med

> -----Message d'origine-----
> De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Simon Hobson
> Envoyé : jeudi 12 novembre 2015 15:24
> À : multipathtcp@ietf.org; dhcwg@ietf.org
> Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
> (MPTCP)
> 
> mohamed.boucadair@orange.com 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.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg