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

Thomas Narten <narten@us.ibm.com> Thu, 09 May 2002 13:35 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 JAA20822 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 09:35:50 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26541 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 09:35:58 -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 JAA26440; Thu, 9 May 2002 09:34: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 JAA26415 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 09:34:45 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20707 for <dhcwg@ietf.org>; Thu, 9 May 2002 09:34:36 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DXQs05732; Thu, 9 May 2002 09:33:26 -0400
Message-Id: <200205091333.g49DXQs05732@cichlid.adsl.duke.edu>
To: Ted Lemon <Ted.Lemon@nominum.com>
cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option
In-Reply-To: Message from Ted Lemon <Ted.Lemon@nominum.com> of "Wed, 08 May 2002 11:12:45 CDT." <6E94CA24-629E-11D6-A5AB-00039367340A@nominum.com>
Date: Thu, 09 May 2002 09:33:26 -0400
From: Thomas Narten <narten@us.ibm.com>
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

Ted Lemon <Ted.Lemon@nominum.com> writes:

> > I understand this to be a holdover from DHC. But if the goal is to
> > provide backup servers info on when they should respond, the
> > retransmission count might be more useful than the elapsed time.

> It's true that a count would serve the functional purpose, but the 
> retransmission time is easy to generate, serves the same purpose, and 
> provides additional information.   So why use the less functional 
> retransmission count?

Would there be any value in including both?

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.

Thomas

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