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

Ted Lemon <mellon@nominum.com> Mon, 23 August 2004 15:19 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 LAA15803; Mon, 23 Aug 2004 11:19:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGCT-0001Lm-A6; Mon, 23 Aug 2004 10:53:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFoS-0005OZ-Du for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 10:28:44 -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 KAA11865 for <dhcwg@ietf.org>; Mon, 23 Aug 2004 10:28:37 -0400 (EDT)
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFoe-00068E-Jj for dhcwg@ietf.org; Mon, 23 Aug 2004 10:28:59 -0400
Received: from [10.0.1.19] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 417251B205C for <dhcwg@ietf.org>; Mon, 23 Aug 2004 09:28:19 -0500 (CDT)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <y7veklyqkbx.wl@ocean.jinmei.org>
References: <y7vhdrl56ol.wl@ocean.jinmei.org> <20040803033357.GA20506@sverresborg.uninett.no> <y7veklyqkbx.wl@ocean.jinmei.org>
Content-Type: text/plain; charset=ISO-2022-JP; format=flowed
Message-Id: <A9C62C40-F510-11D8-AE27-000A95D9C74C@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@nominum.com>
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)
Date: Mon, 23 Aug 2004 10:28:12 -0400
To: dhcwg@ietf.org
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

On Aug 23, 2004, at 5:23 AM, JINMEI Tatuya / 神明達哉 wrote:
> - even if the clients cannot get a response by the expiration, it
>   should continue sending Information-requests.  However, it can also
>   invalidate the expired information in some way, e.g., by preferring
>   a "last resort" default or by using other means of configuration.

Can you think of a real-world scenario where this would be the right 
thing to do?   I can't come up with one.   For example, if we wanted to 
fall back to some sort of link-local protocol, this wouldn't help us, 
because it would take too long.   I think that in just about any 
scenario where you'd think to benefit by switching to some other 
configuration scheme, the switch would happen much too late, using this 
mechanism, to be of any benefit.

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.


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