RE: [dhcwg] Options in base doc for DHCPv6

Hi:

I fully support Ralph in this. I want to make sure we can get the base draft through as that will likely take some time for the IESG to digest and we don't want a small issue to hold up this main work.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, January 24, 2002 5:59 AM
To: dhcwg@ietf.org
Subject: RE: [dhcwg] Options in base doc for DHCPv6

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

At 03:29 PM 1/23/2002 -0800, Richard Barr Hibbs wrote:

> > -----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
> > say "no more," but not to start taking them all out.
> >
>...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?
>
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg