IETF Logo Mail Archive

Re: [dhcwg] DHCP_DECLINE question

Ted Lemon <Ted.Lemon@nominum.com> Thu, 07 March 2002 04:42 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 XAA00145 for <dhcwg-archive@odin.ietf.org>; Wed, 6 Mar 2002 23:42:52 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA12587 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 23:42:55 -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 XAA12498; Wed, 6 Mar 2002 23:41:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12469 for <dhcwg@optimus.ietf.org>; Wed, 6 Mar 2002 23:41:04 -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 XAA00057 for <dhcwg@ietf.org>; Wed, 6 Mar 2002 23:40:59 -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 g274acX27546; Wed, 6 Mar 2002 20:36:38 -0800 (PST)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g274f1F00618; Wed, 6 Mar 2002 22:41:01 -0600 (CST)
Date: Wed, 06 Mar 2002 22:41:01 -0600
Subject: Re: [dhcwg] DHCP_DECLINE question
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v481)
Cc: dhcwg@ietf.org
To: Ralph Droms <rdroms@cisco.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <4.3.2.7.2.20020306215321.0378c290@funnel.cisco.com>
Message-Id: <86CB2DF8-3185-11D6-8B5E-00039367340A@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
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

> In my opinion, a client is within the spec if it sends a DHCPRELEASE 
> immediately after receiving a DHCPACK (for whatever reason).  The 
> DHCPRELEASE will terminate the lease and make the address available for 
> reassignment without causing the server to mark the address as "not to be 
> assigned".

True.

> There is still the open question of whether we want to *recommend* this 
> behavior...

Right.   I'd say we shouldn't, because in all likelihood it's going to 
result in the client looping behavior about which Barr is concerned.    I 
think that we are trying to fix a nonexistant problem here, and the fix 
seems much worse than the problem, particularly since I've never observed 
the problem happening in real life.


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

v2.23.0 | Report a Bug | By Email