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

Ted Lemon <Ted.Lemon@nominum.com> Thu, 09 May 2002 17:48 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 NAA02359 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 13:48:57 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13007 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 13:49:05 -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 NAA12675; Thu, 9 May 2002 13:43:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12648 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 13:43:35 -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 NAA02210 for <dhcwg@ietf.org>; Thu, 9 May 2002 13:43:26 -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 g49HgVS13530; Thu, 9 May 2002 10:42:31 -0700 (PDT)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49HhW602086; Thu, 9 May 2002 12:43:32 -0500 (CDT)
Date: Thu, 09 May 2002 12:43:32 -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: 'Thomas Narten' <narten@us.ibm.com>, dhcwg@ietf.org
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3E1@EAMBUNT705>
Message-Id: <47CC76B8-6374-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

> 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 mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg