RE: [dhcwg] Options in base doc for DHCPv6

Jim Bound <> Wed, 23 January 2002 04:53 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id XAA21943 for <>; Tue, 22 Jan 2002 23:53:49 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id XAA28670 for; Tue, 22 Jan 2002 23:53:54 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id XAA28455; Tue, 22 Jan 2002 23:40:46 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id XAA28423 for <>; Tue, 22 Jan 2002 23:40:43 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with SMTP id XAA21668 for <>; Tue, 22 Jan 2002 23:40:38 -0500 (EST)
Received: from localhost by; (5.65v3.2/ id AA13444; Tue, 22 Jan 2002 23:40:37 -0500
Date: Tue, 22 Jan 2002 23:40:37 -0500
From: Jim Bound <>
To: "Bernie Volz (EUD)" <>
Cc: Ralph Droms <>,
Subject: RE: [dhcwg] Options in base doc for DHCPv6
In-Reply-To: <66F66129A77AD411B76200508B65AC69BC7757@EAMBUNT705>
Message-Id: <>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>


Again DNS options are needed NOW for IPv6 deployment.  Specifically for
IPv6 DNS Stateless discovery.

That which is needed for IPv6 deployment is as important to any option we
have in the spec.

Implementors like VJ and others need these now the reason is we are so
late with DHC6 for the market we do not have the luxury to not include
basic options which which are required by the IPv6 market early adopters.

So I would argue this should affect our thinking on this discussion.
Right now boot server for diskess nodes is less important to the market
(our customer here) than configured tunnel option.  


On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote:

> Ralph:
> I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them.
> I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. 
> For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration.
> - Bernie
> -----Original Message-----
> From: Ralph Droms []
> Sent: Tuesday, January 22, 2002 2:56 PM
> To:
> Subject: [dhcwg] Options in base doc for DHCPv6
> 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

dhcwg mailing list