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