[dhcwg] comments on draft-daniel-dhc-dhcpv4-tep-conf

Ted Lemon <mellon@nominum.com> Tue, 03 August 2004 15:55 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16913; Tue, 3 Aug 2004 11:55:13 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1T0-0000ke-9M; Tue, 03 Aug 2004 11:44:42 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1OV-0000I8-0T for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 11:40:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16177 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 11:40:00 -0400 (EDT)
Received: from toccata.fugue.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs1RZ-0003HT-TE for dhcwg@ietf.org; Tue, 03 Aug 2004 11:43:15 -0400
Received: from [] (opene-130-129-130-32.ietf60.ietf.org []) by toccata.fugue.com (Postfix) with ESMTP id 841EC1B221E for <dhcwg@ietf.org>; Tue, 3 Aug 2004 10:39:15 -0500 (CDT)
Mime-Version: 1.0 (Apple Message framework v618)
To: dhcwg@ietf.org
Message-Id: <60325F40-E563-11D8-982E-000A95D9C74C@nominum.com>
Content-Type: multipart/mixed; boundary="Apple-Mail-2--576234703"
From: Ted Lemon <mellon@nominum.com>
Date: Tue, 03 Aug 2004 08:39:58 -0700
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Subject: [dhcwg] comments on draft-daniel-dhc-dhcpv4-tep-conf
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

This draft breaks a couple of existing assumptions about DHCP.   First, 
it requires that the option be send only in a DHCPACK message in 
response to a DHCPREQUEST message.   Normally the DHCPOFFER message 
contains the same options as the DHCPACK message.   So I would strongly 
suggest that this restriction be relaxed to allow the DHCPOFFER to 
contain this option.

Secondly, the draft allows multiple copies to appear.   This 
contradicts the Encoding Long Options RFC (sorry, can't remember the 
number off the top of my head), which would create a huge headache for 
DHCP server and client implementations.   So please change the option 
so that there can be only one of them, and that if multiple values need 
to be sent, that is encoded within the option.

Also, there is quite a bit of information in this document that goes 
beyond describing the format of the option.   It looks like you're 
defining a new protocol.   If you are not defining a new protocol, it 
would be better to refer to the document that defines the protocol, and 
remove the words from this document that describe that protocol in 
detail.   If you are defining a new protocol here, this draft probably 
needs to be reviewed by the working group responsible for that area as 
well as by the DHC working group.  (sorry if this has already been 

I've enclosed a couple of diffs for some minor editorial suggestions.
dhcwg mailing list