IETF Logo Mail Archive

Re: [dhcwg] Options in base doc for DHCPv6

Ted Lemon <mellon@nominum.com> Thu, 24 January 2002 23:16 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09370 for <dhcwg-archive@odin.ietf.org>; Thu, 24 Jan 2002 18:16:11 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01268 for dhcwg-archive@odin.ietf.org; Thu, 24 Jan 2002 18:16:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29221; Thu, 24 Jan 2002 17:35:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29178 for <dhcwg@ns.ietf.org>; Thu, 24 Jan 2002 17:35:05 -0500 (EST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08476 for <dhcwg@ietf.org>; Thu, 24 Jan 2002 17:35:00 -0500 (EST)
Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0OMW3a27958; Thu, 24 Jan 2002 14:32:04 -0800 (PST)
Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0OMYe700336; Thu, 24 Jan 2002 16:34:40 -0600 (CST)
Date: Thu, 24 Jan 2002 16:33:10 -0600
Subject: Re: [dhcwg] Options in base doc for DHCPv6
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v480)
Cc: dhcwg@ietf.org
To: Ralph Droms <rdroms@cisco.com>
From: Ted Lemon <mellon@nominum.com>
In-Reply-To: <4.3.2.7.2.20020124053656.037d2f50@funnel.cisco.com>
Message-Id: <588BA3C4-111A-11D6-A6AA-00039317663C@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.480)
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

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

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.


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

v2.23.0 | Report a Bug | By Email