IETF Logo Mail Archive

Re: [dhcwg] dhcpv6-24: Elapsed Time option

Ted Lemon <Ted.Lemon@nominum.com> Thu, 09 May 2002 16:50 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 MAA29315 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 12:50:54 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08647 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 12:50:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08308; Thu, 9 May 2002 12:45:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08284 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 12:45:45 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29046 for <dhcwg@ietf.org>; Thu, 9 May 2002 12:45:36 -0400 (EDT)
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 g49GhNS13344; Thu, 9 May 2002 09:43:23 -0700 (PDT)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49GiO600681; Thu, 9 May 2002 11:44:24 -0500 (CDT)
Date: Thu, 09 May 2002 11:44:24 -0500
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v481)
Cc: dhcwg@ietf.org
To: Thomas Narten <narten@us.ibm.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <200205091333.g49DXQs05732@cichlid.adsl.duke.edu>
Message-Id: <04D88EC0-636C-11D6-A5AB-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

> The problem with just including the time is that servers need to guess
> whether a client has been waiting "too long". Or, is it the case that
> when the client  sends out its initial Solicit, the value MUST be
> zero? If so, it might be good to specify this. If this were the case,
> I agree that including the time is probably sufficient.

Ah, I see the problem now.   Yes, we should make this explicit.   As to the 
practical matter of "how long is too long," we address this in DHCPv4 by 
letting the server administrator decide.   AFAIK, this solution has proven 
satisfactory - I haven't heard any complaints about it.


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

v2.29.0 | Report a Bug | By Email | System Status