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

Robert Elz <kre@munnari.OZ.AU> Thu, 02 September 2004 21:32 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA13520; Thu, 2 Sep 2004 17:32:46 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C2z0d-0004gl-Ej; Thu, 02 Sep 2004 17:20:43 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C2yun-0002Fw-2e for; Thu, 02 Sep 2004 17:14:41 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA12401 for <>; Thu, 2 Sep 2004 17:14:38 -0400 (EDT)
Received: from [] (helo=fuchsia.home) by with esmtp (Exim 4.33) id 1C2yx3-0000ZU-1T for; Thu, 02 Sep 2004 17:17:14 -0400
Received: from (delta.ex0.home []) by fuchsia.home with ESMTP id i82LDV0v020440; Fri, 3 Sep 2004 04:13:31 +0700 (ICT)
Received: from munnari.OZ.AU (localhost []) by (8.12.9/8.11.6) with ESMTP id i82LD7a1011954; Fri, 3 Sep 2004 04:13:11 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: JINMEI Tatuya / 神明達哉 <>
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 03 Sep 2004 04:13:07 +0700
Message-ID: <2221.1094159587@munnari.OZ.AU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc:, Stig Venaas <>, Ted Lemon <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

    Date:        Wed, 01 Sep 2004 23:52:32 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
    Message-ID:  <>

  | ...but I don't want to delay this important work due to my pedantic
  | ego.  If others still want to leave those points to other documents,
  | I'll obey that decision (but at least I want the "lifetime" document
  | to mention those a bit and to say that those are beyond the scope of
  | the doc).

There's no question of ego here.

The document is logically incomplete and meaningless if there's no
discussion (either in the document, or in a companion) of what happens
when a renewal attempt fails to achieve what was expected.

It is all obvious what to do when a "renewal" info request gets back the
same data as last time - even perhaps when it gives back that data, and
more.   It may even be fairly obvious (if not quite as obvious) what to
do if there's no reply at all (dead dhcp server, or node moved to a location
where there is no server).

Dealing with replacement data (conceptually anyway) isn't hard to understand
(in some cases it might be hard to implement) - ut dealing with getting an
answer with some data missing is quite a different thing - it clearly isn't
the same case as not getting an answer at all.

Once again, the relevance of this to this doc is just that this doc is
incomplete without that extra detail specified somewhere.   It is however
totally irrelevant what causes the new request to be made - whether it is
the expiration of one timer or another, or the detection of some kind of
"connected to a different link" signal, or even the (let's hope it is
defunct) proposal where the server sent out messages to clients telling
them to ignore previous timers and renew now.

Because of this, having the specification in a different (referenced,
and a normative ref at that) doc is an entirely reasonable thing to do.

But moving forward with this "explicitly demand refresh" doc without
any indication what should be done if it fails is simply not good enough.


dhcwg mailing list