Re: [dhcwg] Options in base doc for DHCPv6

Ted Lemon <mellon@nominum.com> Wed, 23 January 2002 18:46 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 NAA20233 for <dhcwg-archive@odin.ietf.org>; Wed, 23 Jan 2002 13:46:47 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10999 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 13:46:49 -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 NAA09430; Wed, 23 Jan 2002 13:14:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09403 for <dhcwg@optimus.ietf.org>; Wed, 23 Jan 2002 13:13:59 -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 NAA19057 for <dhcwg@ietf.org>; Wed, 23 Jan 2002 13:13:57 -0500 (EST)
Received: from green.bisbee.fugue.com (dhcp45.summer.secret-wg.org [193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NI9la24601; Wed, 23 Jan 2002 10:09:47 -0800 (PST)
Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NICm001796; Wed, 23 Jan 2002 19:12:48 +0100 (CET)
Date: Wed, 23 Jan 2002 19:12:48 +0100
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: rdroms@cisco.com, dhcwg@ietf.org
To: Vijay Bhaskar A K <vijayak@india.hp.com>
From: Ted Lemon <mellon@nominum.com>
In-Reply-To: <200201231759.XAA03676@dce.india.hp.com>
Message-Id: <CE7A0106-102C-11D6-AF3C-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

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.


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