Subject: Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07

From: David Hankins <[email-masked]>
Date: Tue, 1 Feb 2011 13:22:25 -0800

On Mon, Jan 31, 2011 at 11:28 PM, <[email-masked]>wrote:

>  * I still vote for clear language without taking care of the current
> implementations: since the aim is to convey one single option enclosing only
> one name; then the client and the sever behaviours should be provided
> accordingly (i.e., use of "must" instead of the "should").
>

Thank you, I will wait a bit and see how Ted responds before making any
changes.  For the moment we have what is hopefully a compromise between a
two-person consensus.

* I see your point about the multi-interface text. This is fair. I would
> just add a sentence like:
>
> "Means to bind a FQDN_NAME configuration to a given interface in a MIFed
> device are out of scope of this document."
>

I think that's appropriate, I'll integrate this.

-- 
David W. Hankins
SRE
Google, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Feb 2011 16:31:11 -0500

On Feb 1, 2011, at 4:22 PM, David Hankins wrote:
> Thank you, I will wait a bit and see how Ted responds before making any changes.  For the moment we have what is hopefully a compromise between a two-person consensus.

You specify "MUST" when you want the implementation to enforce the behavior.   We do not want implementations to have to support option-specific behavior.   Hence, we should not use MUST.

However, this is not to say that implementations receiving these options should be required to deal with erroneous results; it's simply that the server should be allowed to return extra data if it's configured to do so; the consumer of the data (not the DHCP client, which is merely a transport mechanism for the data) should be responsible for making sense of it, or rejecting it if the server was configured to send something bogus.