Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)

Tim Chown <tjc@ecs.soton.ac.uk> Mon, 23 August 2004 16:29 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21099; Mon, 23 Aug 2004 12:29:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzH5r-0000qA-VE; Mon, 23 Aug 2004 11:50:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGoV-0006Nj-03 for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 11:32:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16653 for <dhcwg@ietf.org>; Mon, 23 Aug 2004 11:32:43 -0400 (EDT)
Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzGoj-0007SK-QY for dhcwg@ietf.org; Mon, 23 Aug 2004 11:33:07 -0400
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i7NFWhgg017036 for <dhcwg@ietf.org>; Mon, 23 Aug 2004 16:32:43 +0100 (BST)
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA17281 for <dhcwg@ietf.org>; Mon, 23 Aug 2004 16:32:41 +0100 (BST)
Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i7NFWe901156 for dhcwg@ietf.org; Mon, 23 Aug 2004 16:32:40 +0100
Date: Mon, 23 Aug 2004 16:32:40 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: dhcwg@ietf.org
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)
Message-ID: <20040823153240.GM31902@login.ecs.soton.ac.uk>
Mail-Followup-To: dhcwg@ietf.org
References: <y7vhdrl56ol.wl@ocean.jinmei.org> <20040803033357.GA20506@sverresborg.uninett.no> <y7veklyqkbx.wl@ocean.jinmei.org> <A9C62C40-F510-11D8-AE27-000A95D9C74C@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <A9C62C40-F510-11D8-AE27-000A95D9C74C@nominum.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

On Mon, Aug 23, 2004 at 10:28:12AM -0400, Ted Lemon wrote:
> 
> So I think that we'd really be better off, as you suggest, renaming 
> this the update timer.   If there's some other configuration mechanism 
> to which we should fall back, I think we need another mechanism for 
> deciding when to fall back to it, and that should probably be specified 
> in the draft that describes the fallback mechanism.

The original idea for the "timer", as documented in the stateless-renumbering
draft, was a "hint" for nodes to re-request information such that if there
was a renumbering event, or a change in DNS, NTP, etc servers, the 
(stateless) node could learn of them.   Without any timer, the node has
no standard mechanisms for this (it could do so on receipt of a new prefix
in an RA, but that doesn't cover new DNS servers being added).

So I think "update timer" may be better.

Is there any case for different behaviour for stateful and stateless
nodes (i.e. based on the method the node's address was obtained from)?

Tim

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