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

Ted Lemon <> Wed, 04 August 2004 04:04 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id AAA09057; Wed, 4 Aug 2004 00:04:58 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BsCzI-0006bm-Ft; Wed, 04 Aug 2004 00:02:48 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BsCu1-0005oR-0z for; Tue, 03 Aug 2004 23:57:21 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id XAA08392 for <>; Tue, 3 Aug 2004 23:57:18 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BsCxC-0008Lo-VX for; Wed, 04 Aug 2004 00:00:40 -0400
Received: from [] ( []) by (Postfix) with ESMTP id 62B061B2A7A; Tue, 3 Aug 2004 22:56:28 -0500 (CDT)
In-Reply-To: <001401c479be$e1045080$>
References: <001401c479be$e1045080$>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <>
Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by...
Date: Tue, 3 Aug 2004 20:57:16 -0700
To: "Bernie Volz" <>
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit

On Aug 3, 2004, at 6:03 PM, Bernie Volz wrote:
> I haven't checked and don't recall, but do you know whether existing 
> clients
> generally include it in the PRL today?

Some do, some don't.   There's special case in the ISC and Nominum DHCP 
servers to override the parameter request list in this case, and the 
code is there because of customer complaints, not because we just 
thought it might be useful.   :')

I think it's a lost cause trying to retrieve things with the FQDN 
option for DHCPv4.   I think we were careful in RFC3315 to specify the 
meaning of the ORO unambiguously, but it might still be nice to mention 
that the mere presence of the FQDN option in the message to the server 
does not override the ORO, and that if the client doesn't list the FQDN 
option in the ORO, it will not get one back from the server.

BTW, it's actually useful in the case of the FQDN option to _not_ 
include it in the ORO - most DHCP clients probably don't _care_ whether 
the server did the update.   They want to tell the server what they'd 
like done, but if the server doesn't do the update, nothing about the 
client's behavior is likely to change.

dhcwg mailing list