[dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt

Thomas Narten <narten@us.ibm.com> Fri, 01 February 2002 17:12 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04290 for <dhcwg-archive@odin.ietf.org>; Fri, 1 Feb 2002 12:12:00 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27995 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 12:12:02 -0500 (EST)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25141; Fri, 1 Feb 2002 11:42:35 -0500 (EST)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25115 for <dhcwg@optimus.ietf.org>; Fri, 1 Feb 2002 11:42:33 -0500 (EST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02656 for <dhcwg@ietf.org>; Fri, 1 Feb 2002 11:42:28 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com []) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA83974 for <dhcwg@ietf.org>; Fri, 1 Feb 2002 10:37:55 -0600
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com []) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11GgTb204040 for <dhcwg@ietf.org>; Fri, 1 Feb 2002 11:42:29 -0500
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g11GgmT01529 for <dhcwg@ietf.org>; Fri, 1 Feb 2002 11:42:48 -0500
Message-Id: <200202011642.g11GgmT01529@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Fri, 01 Feb 2002 11:42:48 -0500
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

The authors have seen most of these already, but there is one question
in particular I think the WG should have a chance to comment on.

Once these issues are addressed, I expect the IESG will approve the
document in short order. (The next IESG telechat is next Thursday, so
it would be nice to have a new ID in place by then!)

1) General question. Does this document update RFC 2131? If so, the
introduction should have a sentence that says this explicitely.  More

> The applicability section seems to say that an encoding agent can
> use the Option Overload option and the concat at any time.
> Isn't this likely to cause interoperability problems until all DHCP decoding
> agents support the concat specification?
> It would seem more conservative to only allow concat for specific option
> codes (such as the classless route one and others that explicitly say they
> will use concat).

2) A minor complaint about the abstract:

     This draft specifies how DHCP options in a DHCP packet can be
     aggregated so that DHCP protocol agents can send options that are
     more than 255 bytes in length.

  I'd rather see "split and combined" (or similar) rather than "aggregated".
  The document also talks about using this feature in order to split
  options across packet fields, but that's not mentioned in the abstract.
  I'm not as worried about that.

  The technical summary in the draft announcement might actually be a
  much better abstract than what's there now. It is:

  This document specifies the processing rules for DHCP options that
  appear multiple times in the same message. The need to send multiple
  instances of the same option occurs when an option exceeds 255
  octets in size (the maximum size of a single option) or when an
  option needs to be broken up into smaller pieces in order that the
  pieces can be placed in the DHC packet in non-contiguous locations
  (e.g., within the "file" or "sname" field). When multiple instances
  of the same option appear in a packet, the contents of the option
  are concatenated together prior to processing.

3) Should the security considerations section refer to RFC 3118?

dhcwg mailing list