RE: [dhcwg] Client behavior with Parameter Request List
"Richard Barr Hibbs" <rbhibbs@pacbell.net> Thu, 20 May 2004 17:32 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04652; Thu, 20 May 2004 13:32:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrD7-0008PP-Fi; Thu, 20 May 2004 13:20:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQr6Z-0006Ym-Eg for dhcwg@optimus.ietf.org; Thu, 20 May 2004 13:13: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 NAA03128 for <dhcwg@ietf.org>; Thu, 20 May 2004 13:13:13 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQr6X-0007iw-GQ for dhcwg@ietf.org; Thu, 20 May 2004 13:13:13 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQr5S-0007aK-00 for dhcwg@ietf.org; Thu, 20 May 2004 13:12:07 -0400
Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BQr4b-0007UX-00 for dhcwg@ietf.org; Thu, 20 May 2004 13:11:14 -0400
Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@63.193.193.52 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 20 May 2004 16:37:30 -0000
Reply-To: rbhibbs@pacbell.net
From: Richard Barr Hibbs <rbhibbs@pacbell.net>
To: Dhcwg <dhcwg@ietf.org>
Subject: RE: [dhcwg] Client behavior with Parameter Request List
Date: Thu, 20 May 2004 09:47:19 -0700
Message-ID: <EJEFKKCLDBINLKODAFMDAEOJDEAA.rbhibbs@pacbell.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <B59832E9-A9DF-11D8-9337-000A95D9C74C@nominum.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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
> -----Original Message----- > From: Ted Lemon > > 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. > > > > 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. > Ted-- while I agree that servers should be "liberal in what they accept, strict in what they send," this is a good example of the questions that arise [and must be settled by agreements outside the text of RFCs] when the protocol behavior is not tightly specified. One shouldn't have to mandate absolutely every behavior in an RFC, but I think your summary of the point would make an excellent correction for RFC2131bis.... "A client MUST send a consistent Parameter Request List if it expects the DHCP server to provide consistent responses to DHCPDISCOVER and DHCPREQUEST messages. If a client does not send a consistent Parameter Request List, the server MAY choose to resolve any conflicts according to [local] implementation policy, which is not specified by this memo." --Barr _______________________________________________ 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