RE: [dhcwg] dhcpv6-24: Elapsed Time option
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Thu, 09 May 2002 17:56 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 NAA02578 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 13:56:19 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13408 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 13:56:28 -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 NAA13256; Thu, 9 May 2002 13:55:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13186 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 13:54:59 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02491 for <dhcwg@ietf.org>; Thu, 9 May 2002 13:54:50 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g49Hswl14683 for <dhcwg@ietf.org>; Thu, 9 May 2002 12:54:58 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g49HswY23050 for <dhcwg@ietf.org>; Thu, 9 May 2002 12:54:58 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu May 09 12:54:57 2002 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <KRTWBFZS>; Thu, 9 May 2002 12:54:57 -0500
Message-ID: <66F66129A77AD411B76200508B65AC69B4D3E5@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Ted Lemon' <Ted.Lemon@nominum.com>
Cc: 'Thomas Narten' <narten@us.ibm.com>, dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option
Date: Thu, 09 May 2002 12:54:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F782.9C71FE10"
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
So, I'm confused as to where you want to go with this? If we want to be able to make this happen in the future, we have to have clear rules as to when the elapsed time starts for each transaction. We also likely have to make sure that the server sends the option back to the client such that the same value can be used in follow-on messages (really just in the Request(s) after an Advertise?). Another question is whether single server messages (such as Renew, Decline, Release) should even make use of this option? Also, we we do allow this option in the single server messages (those with a Server Identifier), what does mean for relays? - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, May 09, 2002 1:44 PM To: Bernie Volz (EUD) Cc: 'Thomas Narten'; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option > I also agree that having the relay base the forwarding on the elapsed time > is likely bad - but again, that was assumed to happen with DHCPv4!! I think it's useful to have the relay be able to do this, but I'm not convinced that it's actually going to get used. There are relays that allow you to configure a delayed relay parameter, but do we know of any that are actually used this way? I don't personally know of anybody who' s doing this. I suspect that this is something that's a good idea in theory, but not in practice, and because of that, I think it might be a better choice to simply leave it out of the spec. The only reason to even *consider* putting it in the spec is that if it doesn't go in now, it will never be possible to do it - if clients and servers don't do the right thing from the outset, there's no way to retrofit this capability later. I'm just really skeptical that we're ever going to need this, and furthermore I'm skeptical that something like this is going to get implemented correctly, when nothing will break immediately if either the server implementation or the client implementation is incorrect.
- [dhcwg] dhcpv6-24: Elapsed Time option Thomas Narten
- RE: [dhcwg] dhcpv6-24: Elapsed Time option Bernie Volz (EUD)
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon
- RE: [dhcwg] dhcpv6-24: Elapsed Time option Bernie Volz (EUD)
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon
- RE: [dhcwg] dhcpv6-24: Elapsed Time option Bernie Volz (EUD)
- RE: [dhcwg] dhcpv6-24: Elapsed Time option Bernie Volz (EUD)
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon
- RE: [dhcwg] dhcpv6-24: Elapsed Time option Bernie Volz (EUD)
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon
- Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon
- RE: [dhcwg] dhcpv6-24: Elapsed Time option Vijayabhaskar A K