[dhcwg] Options in base doc for DHCPv6

Ralph Droms <rdroms@cisco.com> Tue, 22 January 2002 20:03 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08481 for <dhcwg-archive@odin.ietf.org>; Tue, 22 Jan 2002 15:03:45 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09347 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 15:03:48 -0500 (EST)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08685; Tue, 22 Jan 2002 14:55:57 -0500 (EST)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08650 for <dhcwg@ns.ietf.org>; Tue, 22 Jan 2002 14:55:47 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08143 for <dhcwg@ietf.org>; Tue, 22 Jan 2002 14:55:43 -0500 (EST)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com []) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01054 for <dhcwg@ietf.org>; Tue, 22 Jan 2002 14:55:14 -0500 (EST)
Message-Id: <>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 22 Jan 2002 14:55:41 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [dhcwg] Options in base doc for DHCPv6
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

We've recently experienced a proliferation of proposed and defined options 
for DHCPv6.  Initially, the WG agreed to publish all options that were 
defined at the time the base spec was completed in the same doc.  I'm 
having second thoughts about that decision.  Here's what I'm thinking:

* The new options are adding more weight to
   an already hefty document
* Keeping all the options in one doc make
   updating any one option more complicated
* Reviewing all of these options will slow
   down the acceptance process

I propose that we put a moratorium on adding any new options to 
draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of 
draft-ietf-dhc-dhcpv6-22.txt into individual drafts.  The definition of 
"essential" is open to discussion; here's a first pass at a list of the 
options to retain in draft-ietf-dhc-dhcpv6-22.txt:

* DHCP unique identifier option
* Identity association option
* IA Address option
* Requested Temporary Addresses (RTA) Option
* Option request option
* Preference option
* Elapsed Time
* Client message option
* Server message option
* Authentication option
* Server unicast option
* Domain Search Option
* Domain Name Server Option
* Status Code Option

- Ralph

dhcwg mailing list