RE: [dhcwg] Options in base doc for DHCPv6

"Bernie Volz (EUD)" <> Wed, 23 January 2002 07:41 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id CAA03062 for <>; Wed, 23 Jan 2002 02:41:53 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id CAA13325 for; Wed, 23 Jan 2002 02:41:54 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id CAA12556; Wed, 23 Jan 2002 02:30:10 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id CAA12532 for <>; Wed, 23 Jan 2002 02:30:09 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id CAA02741 for <>; Wed, 23 Jan 2002 02:30:07 -0500 (EST)
Received: from ( []) by (8.11.3/8.11.3) with ESMTP id g0N7TcS25716 for <>; Wed, 23 Jan 2002 01:29:38 -0600 (CST)
Received: from ( []) by (8.11.3/8.11.3) with SMTP id g0N7Tc709667 for <>; Wed, 23 Jan 2002 01:29:38 -0600 (CST)
Received: FROM BY ; Wed Jan 23 01:29:37 2002 -0600
Received: by with Internet Mail Service (5.5.2653.19) id <ZQBK0YR6>; Wed, 23 Jan 2002 01:29:37 -0600
Message-ID: <66F66129A77AD411B76200508B65AC69B4CDEE@EAMBUNT705>
From: "Bernie Volz (EUD)" <>
To: 'Jim Bound' <>
Cc: Ralph Droms <>,
Subject: RE: [dhcwg] Options in base doc for DHCPv6
Date: Wed, 23 Jan 2002 01:29:36 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3DF.B5D4C820"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>


I am *NOT* saying these options aren't important. It is just to clearly specify which options should appear in which document. I think we should work very hard to get the additional drafts done for these options. It is just that we should say that if an option is strictly related to the operation of the DHCP protocol, it should be in the base specification. It is related only to data that configures a client, it can be documented in a separate specification.

- Bernie

-----Original Message-----
From: Jim Bound []
Sent: Tuesday, January 22, 2002 11:41 PM
To: Bernie Volz (EUD)
Cc: Ralph Droms;
Subject: RE: [dhcwg] Options in base doc for DHCPv6


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