RE: [dhcwg] Client behavior with Parameter Request List
"Kevin A. Noll" <kevin.noll@perfectorder.com> Thu, 20 May 2004 01:31 UTC
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03945; Wed, 19 May 2004 21:31:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcJv-0004nY-Q6; Wed, 19 May 2004 21:26:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcFH-00038S-4Z for dhcwg@optimus.ietf.org; Wed, 19 May 2004 21:21:15 -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 VAA03575 for <dhcwg@ietf.org>; Wed, 19 May 2004 21:21:12 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQcFE-0001H5-Ad for dhcwg@ietf.org; Wed, 19 May 2004 21:21:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcEO-00019m-00 for dhcwg@ietf.org; Wed, 19 May 2004 21:20:21 -0400
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BQcDk-0000zH-00 for dhcwg@ietf.org; Wed, 19 May 2004 21:19:40 -0400
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HXZ00C01NBPTO@endeavor.poss.com> for dhcwg@ietf.org; Wed, 19 May 2004 21:19:05 -0400 (EDT)
Received: from kan1 (user188.net390.oh.sprint-hsd.net [65.40.75.188]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HXZ000I1NNSFZ@endeavor.poss.com>; Wed, 19 May 2004 21:19:05 -0400 (EDT)
Date: Wed, 19 May 2004 21:19:04 -0400
From: "Kevin A. Noll" <kevin.noll@perfectorder.com>
Subject: RE: [dhcwg] Client behavior with Parameter Request List
In-reply-to: <B59832E9-A9DF-11D8-9337-000A95D9C74C@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Cc: dhcwg@ietf.org
Message-id: <PPEKLDPHBHOIHMHKFGLLOEPCDAAA.kevin.noll@perfectorder.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
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
That makes sense. Thanks! Now, I wonder if any server implementations actually check this. --kan-- > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > Lemon > Sent: Wednesday, 19 May, 2004 5:59 PM > To: Kevin A. Noll > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Client behavior with Parameter Request List > > > 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 > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- AW: [dhcwg] Updated Draft "DHCP Discovery Extensi… Rentschler, Markus
- [dhcwg] DHCP server supports BOOTP client Shirley Ma
- RE: [dhcwg] DHCP server supports BOOTP client Kevin A. Noll
- Re: [dhcwg] DHCP server supports BOOTP client Ralph Droms
- [dhcwg] Client behavior with Parameter Request Li… Kevin A. Noll
- Re: [dhcwg] Client behavior with Parameter Reques… Ted Lemon
- RE: [dhcwg] Client behavior with Parameter Reques… Kevin A. Noll
- Re: [dhcwg] Client behavior with Parameter Reques… Ted Lemon
- RE: [dhcwg] Client behavior with Parameter Reques… Richard Barr Hibbs
- Re: [dhcwg] Client behavior with Parameter Reques… Ted Lemon
- [dhcwg] Parameter list from multiple servers? Kevin A. Noll
- RE: [dhcwg] Parameter list from multiple servers? Richard Barr Hibbs
- RE: [dhcwg] Parameter list from multiple servers? Kevin A. Noll