Re: [dhcwg] Comment on a couple of option drafts that have gone by...

Ted Lemon <Ted.Lemon@nominum.com> Tue, 03 August 2004 22:37 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18680; Tue, 3 Aug 2004 18:37:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7rs-0004GU-Fq; Tue, 03 Aug 2004 18:34:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7jR-0003YA-Fw for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:26:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18101 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 18:26:03 -0400 (EDT)
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7ma-0002j2-DA for dhcwg@ietf.org; Tue, 03 Aug 2004 18:29:21 -0400
Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id 44AC11B2A2E; Tue, 3 Aug 2004 17:25:15 -0500 (CDT)
In-Reply-To: <0I1W003M40D71R@ms3.samsung.com>
References: <0I1W003M40D71R@ms3.samsung.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <18347D18-E59C-11D8-8860-000A95D9C74C@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by...
Date: Tue, 3 Aug 2004 15:25:59 -0700
To: soohong.park@samsung.com
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: "dhcwg@ietf.org " <dhcwg@ietf.org>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

On Aug 3, 2004, at 1:17 PM, PARK SOO HONG wrote:
> Isn't it enough to satisfy your concern ?

No, my concern is not related to what you're talking about.   My 
concern is actually unrelated to the work you are doing - I'm just 
asking you to add some text to try to get client implements to be 
consistent in what they do with the parameter request list.   It's not 
your fault that this is (IMHO) necessary - the problem is that the 
parameter request list option is poorly specified, and I'd like 
implementors of this option to implement to the more stringent 
interpretation of the specification, rather than the more lax 
implementation.

In order to get client implementors to do this, I am asking you to add 
some text which will (I hope) cause client implementors to assume that 
the DHCP server will behave in a certain way.   If they believe that a 
DHCP server will very likely not send a tep option if the client 
doesn't request it in the parameter request list, then they will 
request it in the parameter request list.   If they do not believe 
this, then they may send a parameter request list but omit the tep 
option code from the list, thinking it is not necessary to include it.

I don't actually care if server implementors follow the requirements 
I'm asking you to add - I just care that client implementors have 
reason to think that servers might follow these requirements.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg