Subject: [dhcwg] Options in base doc for DHCPv6

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Jan 2002 14:55:41 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Tue, 22 Jan 2002 15:26:13 -0500

I think that this proposal makes a great deal of sense. I do think that the 
boot-file and tftp server address(es) options need to be added to the core 
list: they really are 'core' to the boot process.

-- Mark

---

From: Jim Bound <[email-masked]>
Date: Tue, 22 Jan 2002 19:40:03 -0500 (EST)

We require the IPv6 options for IPv6 Transition now.

/jim

---

From: Jitesh N Verma <[email-masked]>
Date: Wed, 23 Jan 2002 11:55:34 +0530 (IST)

Hi List,
	I strongly agree with Mark. Booting mechanism belongs to DHCP domain.

Regards,
Jitesh

-- 
-----------------------------------------------------------------------

    ~                                                             ~
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
^ Jitesh N. Verma                     Tel. 91-80-225 1554 Ext. 1424   ^
^ HEWLETT PACKARD                     Fax. 91-80-220 0196             ^
^ INDIA SOFTWARE OPERATIONS         Email. [email-masked]        ^
^ 29, CUNNINGHAM ROAD               Pager. 9624-263608                ^
^ BANGALORE 560 052        __      Telnet. 847-1424                   ^
^                         / /                                         ^
^                        / /___ _____                                 ^
^                       / __  // __  /                                ^
^                      / / / // /_/ /                                 ^
^                     /_/ /_// ____/                                  ^
^                           / /                                       ^
^                          /_/                                        ^
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 23 Jan 2002 09:20:24 +0100

I totally agree with this. Escpecially the point of slowing down the 
acceptance process is worth to mention. A lot of IPv6 networks are in the 
deployment process or will be deployed in the near future and DHCPv6 is 
needed for this deployment, i.e. there should be a standard.

Martin

--On Dienstag, Januar 22, 2002 14:55:41 -0500 Ralph Droms 
<[email-masked]> wrote:

> 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:
>

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories      [email-masked]
IPv4: http://www.ccrle.nec.de             IPv6: http://www.ipv6.ccrle.nec.de

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jan 2002 11:57:09 -0500

I propose we move Domain Search Option and Domain Name Server Option out of 
the base DHCPv6 spec, as well...

- Ralph

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Wed, 23 Jan 2002 23:29:51 +0530 (IST)

>    down the acceptance process

The basic use of DHCPv6 is not only allocating IP addresses but also for
giving other configuration parameters also.  Most of the OS are IPv6fied
and almost all the applications are IPv6 enabled.  The hosts need DHCPv6
to provide  options  for  getting the info about the  servers  providing
various  services  available  to them.  This will  make the host work as
fullfledged  IPv6fied  node.  If your  concern is about delay in getting
the PS, i worry that, it will take another year to get all those options
in the  options  draft  and  making  it PS.  I feel  that we can add the
options  in the base  spec  which  are  already  requested  to be added,
because we really  need them.  I dont agree that  review of the  options
will take much time, since including the options  doesn't  involve major
design  change and most of the  options are already  known in DHCPv4 and
most of the options follow the similar pattern.

-- 
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
______Ph:_2051424________
____Telnet:_847_1424_____
___Pager:_9624_371137____

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2002 19:12:48 +0100

Even a small delay in finishing the draft is unacceptable.   If it would 
take a long time to get consensus on an option draft, it would take at 
least as long to get the same consensus for the same language in the DHCPv6 
draft.   There is no chance at all that carelessly sticking additional 
option definitions into the DHCPv6 draft will speed the finalization of 
such options, and there is no chance that doing so would not slow the 
DHCPv6 draft.   I say this based on a fair number of years of experience 
with this process.

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Thu, 24 Jan 2002 00:21:51 +0530 (IST)

I  dont  agree.  DNS  is  a  very  critical  application.  Most  of  the
applications  work with names rather than IP  addresses.  The host badly
needs this for resolving  names.  Moreover,  this option is occurring in
last 3-4  versions  of the  draft.  Still  now, we didn't  get any mails
saying  that the  format is wrong.  It means  that, it is  reviewed  and
accepted  by the WG.  Why do you  want  to  move  out a more  stabilised
option which is very much required?

---

From: Jim Bound <[email-masked]>
Date: Wed, 23 Jan 2002 13:53:11 -0500 (EST)

Martin,

Exactly why we need these options now.  IPv6 is being deployed.
It will take at least 3 IETF meetings to get a specific options draft
after dhc6.  We cannot wait.  Also these options will not hold up the
processs.  They are pretty basic. 

/jim

---

From: John Schnizlein <[email-masked]>
Date: Wed, 23 Jan 2002 13:55:42 -0500

At 11:57 AM 1/23/2002, Ralph Droms wrote:
>I propose we move Domain Search Option and 
>Domain Name Server Option out of the base DHCPv6 spec, as well...

I think you just threw the baby out with the bath water.
How is the host supposed to find a Domain Name Server?
Without DNS lookups, how can the host find SVR records?

The security issues with Domain Search justify putting it off,
but we should keep DNS in the base spec.

John

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2002 21:18:48 +0100

> option which is very much required?
I have to agree here.   I don't see any reason to remove options about 
which there is no controversy from the DHCPv6 draft.   I think it's fine to 
say "no more," but not to start taking them all out.

---

From: Richard Barr Hibbs <[email-masked]>
Date: Wed, 23 Jan 2002 15:29:48 -0800

> -----Original Message-----
> From: Ted Lemon
> Sent: Wednesday, January 23, 2002 12:19
>
> I don't see any reason to remove options about which there is no
> controversy from the DHCPv6 draft.   I think it's fine to
...exactly.  Is it possible to construct a simple test by which to judge an
option as appropriate for inclusion in the base document?  For example:

(1) is it required for implementation or deployment of a crucial service
(for example, DNS or SLP)

(2) is it essential to implement mandatory or highly desirable functionality
(such as authentication or security)?

(3) is it necessary to support transition from IPv4 to IPv6?

(4) is it currently widely deployed with DHCPv4?

(5) has the option been stably defined for DHCPv6 for at least several draft
revisions?

---

From: Jitesh N Verma <[email-masked]>
Date: Thu, 24 Jan 2002 10:51:31 +0530 (IST)

Hi List,
I am strongly in favour of including DNS option in base draft. The way we are
proceeding on DHCPv6 base draft, I am sure that the separate option draft will
also take quite sometime to become PS/RFC. In such a situation, implementation
of DHCPv6 without DNS option will be meaningless. DNS option is immediate
requirement for IPv6 deployment, since most of the applications use DNS. 
	In one sentence: DHCPv6 is LAME without DNS option.

Cheers,
Jitesh

    ~                                                             ~

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2002 10:40:34 +0100

--On Mittwoch, Januar 23, 2002 21:18:48 +0100 Ted Lemon 
<[email-masked]> wrote:
[...]
> which there is no controversy from the DHCPv6 draft.   I think it's fine
> to say "no more," but not to start taking them all out.

Ok, is is good to say "keep the already include options and no more". 
Escpecially the people who have already implemented the included options 
would be happy about this and these options looking rather useful for the 
first dhcpv6 deployment.

Martin

Martin Stiemerling

---

From: Ralph Droms <[email-masked]>
Date: Thu, 24 Jan 2002 05:59:21 -0500

The primary reasons to put existing options in parallel drafts are to 
simplify the base spec doc and to minimize the delay in getting the base 
spec to Proposed Standard.  By retaining only those options required for 
the operation of the protoocol, we minimize the chance that any one option 
will hold up the progress of the entire draft.

Moving some options into parallel drafts will not *incrementally* delay the 
progress of those options.  If there is some problem with a specific 
option, retaining that option in the base spec will not move it through the 
process any faster.  Rather, that problem will slow down the entire base 
spec, rather than just the one option.

Remember that accepting DHCPv6 as a standard is not up to us.  It doesn't 
matter how many times we've reviewed an option and whether we think it's 
OK.  The IESG makes the decision - and I'm trying to avoid the scenario in 
which the entire spec is held up because we have to discuss and rewrite an 
option that the IESG has found a problem with.

So, I don't see how moving existing options to parallel docs will 
*incrementally* slow down the acceptance of those options.  I do see that 
one option might delay the acceptance of the entire base spec.  Retaining 
just those options referenced in the base spec doesn't cost anything and 
gives some additional insurance against delaying the progress of the base spec.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Thu, 24 Jan 2002 08:41:44 -0500 (EST)

I love Barr's list (well maybe not love) {---)

/jim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Jan 2002 16:33:10 -0600

> gives some additional insurance against delaying the progress of the base 

This assumes that there is no additional cost for forking a draft, which I 
do not think is true.   I do not think that the DNS server and domain name 
options have much chance of delaying the draft, so I don't see any win from 
taking them out.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Jan 2002 11:27:15 -0500

Let me reiterate - just because *we* don't see any controversy in the 
current set of options doesn't mean the IESG won't have questions about one 
or more of them.  And, Ted is right - we can back options out at a later 
date if there's a problem.  Personally, I'd rather give the IESG as small 
as possible a target when the draft gets to them...

So, Barr, you proposed a list of questions to ask about options (which is 
included below).  We need to come to closure - I'd like to have that 
closure by this afternoon so we can finish the draft over the weekend - 
who's willing to volunteer a straw-person list of options for the DHCPv6 draft?

- Ralph