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
- [dhcwg] dhcpv6-24: Rapid Commit Thomas Narten
- RE: [dhcwg] dhcpv6-24: Rapid Commit Bernie Volz (EUD)
- Re: [dhcwg] dhcpv6-24: Rapid Commit Ted Lemon
- Re: [dhcwg] dhcpv6-24: Rapid Commit Thomas Narten
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Thomas Narten
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Ted Lemon
- Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt Thomas Narten
- Re: [dhcwg] Discussion on draft-ietf-dhc-failover… George C. Kaplan