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

Ted Lemon <mellon@nominum.com> Tue, 03 August 2004 17:12 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22652; Tue, 3 Aug 2004 13:12:04 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2j9-00054w-5t; Tue, 03 Aug 2004 13:05:27 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2U6-0002kL-Ig for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:49:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20649 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 12:49:52 -0400 (EDT)
Received: from toccata.fugue.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2XA-0004Zw-Qj for dhcwg@ietf.org; Tue, 03 Aug 2004 12:53:07 -0400
Received: from [] (opene-130-129-130-32.ietf60.ietf.org []) by toccata.fugue.com (Postfix) with ESMTP id 7B1571B225B for <dhcwg@ietf.org>; Tue, 3 Aug 2004 11:49:03 -0500 (CDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Transfer-Encoding: 7bit
Message-Id: <7C7FE7F6-E565-11D8-982E-000A95D9C74C@nominum.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
To: dhcwg@ietf.org
From: Ted Lemon <mellon@nominum.com>
Date: Tue, 03 Aug 2004 08:55:05 -0700
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Comment on a couple of option drafts that have gone by...
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

I've noticed that a couple of drafts have gone by that require the 
client to send an option to the server so that the server will know 
what to send back to the client.   In each of these cases, this seems 
like a reasonable way to solve the problem.

However, I would like to point out one problem with this, and request 
that the authors of these drafts (I'm thinking specifically of the 
haopt and tep drafts) add some text to talk about what the client 
should send in the parameter request list.

Currently the FQDN option protocol specification requires the server to 
send back an FQDN option even if the client sends a parameter request 
list and doesn't include the FQDN option code in that list.   Please 
specify in your drafts that the DHCP server must not send the reply 
option unless either no parameter request list is sent, or unless the 
option code for the option appears in the parameter request list.   
Suggested text:

The DHCP server MUST NOT send the Foo option if the client sends a 
Parameter Request List option and the code for the Foo option does not 
appear in the parameter request list, EVEN IF the Foo-request option 
appears in the client's list of options.

The reason for making this request is that we have to have special case 
code in the DHCP server to make sure the FQDN option gets sent even if 
not requested, and this adds needless complexity.   If you add text 
like what I've suggested above, you are not placing this requirement on 
the server - the server can just process the option normally when 
constructing the reply.

dhcwg mailing list