Re: [dhcwg] Client behavior with Parameter Request List

Ted Lemon <Ted.Lemon@nominum.com> Wed, 19 May 2004 22:23 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24907; Wed, 19 May 2004 18:23:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZIC-0003Sr-B2; Wed, 19 May 2004 18:12:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZ6s-0004NC-EZ for dhcwg@optimus.ietf.org; Wed, 19 May 2004 18:00:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22798 for <dhcwg@ietf.org>; Wed, 19 May 2004 18:00:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQZ6p-0000Id-Kg for dhcwg@ietf.org; Wed, 19 May 2004 18:00:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQZ5t-0000BN-00 for dhcwg@ietf.org; Wed, 19 May 2004 17:59:22 -0400
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BQZ5P-00003V-00 for dhcwg@ietf.org; Wed, 19 May 2004 17:58:51 -0400
Received: from [128.177.194.120] (dhcp-120.engr.nominum.com [128.177.194.120]) by toccata.fugue.com (Postfix) with ESMTP id 386D21B2482; Wed, 19 May 2004 16:45:18 -0500 (CDT)
In-Reply-To: <PPEKLDPHBHOIHMHKFGLLMEOLDAAA.kevin.noll@perfectorder.com>
References: <PPEKLDPHBHOIHMHKFGLLMEOLDAAA.kevin.noll@perfectorder.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <B59832E9-A9DF-11D8-9337-000A95D9C74C@nominum.com>
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
From: Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] Client behavior with Parameter Request List
Date: Wed, 19 May 2004 14:58:49 -0700
To: "Kevin A. Noll" <kevin.noll@perfectorder.com>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
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>
Content-Transfer-Encoding: 7bit

On May 18, 2004, at 8:05 PM, Kevin A. Noll wrote:

> I can't find any statement as to what should happen if the client
> *does not* include the list. Clearly it would be a protocol violation
> and therefore a broken client if it didn't, but what should the
> server do about it? I assume it should drop the message.
>
> Taking this to a different level of discussion - I question the
> purpose of making this requirement. I can understand why you
> would want to require options like "Client Identifier" to always
> be sent, I'm not sure why the parameter request list must always
> be included.

The intent was that the client must do this if it expects to get a 
consistent response from the DHCP server.   Of course you should not 
drop the packet if it doesn't follow this.   The point is that you 
don't have to bend over backwards to be consistent if the client 
violates this restriction.


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