RE: [dhcwg] Options in base doc for DHCPv6

Ralph Droms <> Fri, 25 January 2002 16:42 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA06898 for <>; Fri, 25 Jan 2002 11:42:08 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id LAA25657 for; Fri, 25 Jan 2002 11:42:10 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id LAA24348; Fri, 25 Jan 2002 11:27:28 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id LAA24326 for <>; Fri, 25 Jan 2002 11:27:26 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA06528 for <>; Fri, 25 Jan 2002 11:27:20 -0500 (EST)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA24772 for <>; Fri, 25 Jan 2002 11:26:52 -0500 (EST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 25 Jan 2002 11:27:15 -0500
From: Ralph Droms <>
Subject: RE: [dhcwg] Options in base doc for DHCPv6
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

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

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
>dhcwg mailing list

dhcwg mailing list