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

"Bernie Volz" <volz@cisco.com> Wed, 04 August 2004 01:13 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 VAA28576; Tue, 3 Aug 2004 21:13:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAFE-0000MP-UA; Tue, 03 Aug 2004 21:07:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsADd-00005E-Bx for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 21:05:25 -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 VAA28063 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 21:05:23 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAGn-0005Uy-Qy for dhcwg@ietf.org; Tue, 03 Aug 2004 21:08:43 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2004 21:09:39 -0400
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7412CRW010506; Tue, 3 Aug 2004 21:02:12 -0400 (EDT)
Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO97662; Tue, 3 Aug 2004 21:02:11 -0400 (EDT)
From: "Bernie Volz" <volz@cisco.com>
To: "'Ted Lemon'" <mellon@nominum.com>, <dhcwg@ietf.org>
Subject: RE: [dhcwg] Comment on a couple of option drafts that have gone by...
Date: Tue, 3 Aug 2004 21:03:39 -0400
Organization: Cisco
Message-ID: <001401c479be$e1045080$c3838182@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <7C7FE7F6-E565-11D8-982E-000A95D9C74C@nominum.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Ted:

I can add this to the FQDN drafts (PRL for DHCPv4 and ORO for DHCPv6), but
it seems odd to do this for options that are designed to be bi-directional.
Yet, as Kim did request that I make it clear that a server can send the
option to a client even if the client doesn't supply it, it seems reasonable
that a client could request it in the PRL or ORO (without sending it). And,
if we allow that, including it in the PRL or ORO even if the option is
included by the client is OK.

I haven't checked and don't recall, but do you know whether existing clients
generally include it in the PRL today?

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, August 03, 2004 11:55 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Comment on a couple of option drafts that 
> have gone by...
> 
> 
> 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
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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