IETF Logo Mail Archive

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

Robert Elz <kre@munnari.OZ.AU> Fri, 27 August 2004 06:59 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 CAA04327; Fri, 27 Aug 2004 02:59:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ad6-0002i6-8z; Fri, 27 Aug 2004 02:54:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0abj-0002QV-Up for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 02:53:08 -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 CAA03994 for <dhcwg@ietf.org>; Fri, 27 Aug 2004 02:53:05 -0400 (EDT)
Received: from 203-69-237-46.hinet-ip.hinet.net ([203.69.237.46] helo=delta.noi.kre.to) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0acn-0001zk-TB for dhcwg@ietf.org; Fri, 27 Aug 2004 02:54:15 -0400
Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7R6qn9O002427; Fri, 27 Aug 2004 13:52:52 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Stig Venaas <Stig.Venaas@uninett.no>
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt)
In-Reply-To: <20040827062321.GA15052@sverresborg.uninett.no>
References: <20040827062321.GA15052@sverresborg.uninett.no> <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> <29651.1093585502@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 27 Aug 2004 13:52:49 +0700
Message-ID: <77.1093589569@munnari.OZ.AU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: dhcwg@ietf.org
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

    Date:        Fri, 27 Aug 2004 08:23:21 +0200
    From:        Stig Venaas <Stig.Venaas@uninett.no>
    Message-ID:  <20040827062321.GA15052@sverresborg.uninett.no>

  | I'm not sure if the answer to these issues need to be described in
  | the draft since it's a more generic issue. OTOH this draft might be
  | the most obvious place we have for now.

Yes, it is a much bigger issue than just providing a mechanism for
specifying when a new info request should be attempted.

But it is when we specify that that the problem becomes obvious, and
we need to have a solution - until now (including in IPv4) we mostly
just pretended that none of this ever happened, and once learned, all
of this information was static forever (hence, DNS "servers" (back end
resolvers really) go in /etc/resolv.conf - that gets updated when the
info changes, but applications know nothing of that, and simply keep on
using the old information forever).

All this is something of a quagmire - but is something that needs to be
addressed, and ought to be addressed along with this new option (if not
necessarily in the same document).

kre


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

v2.23.0 | Report a Bug | By Email