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

    Date:        Wed, 01 Sep 2004 23:52:32 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
		 <jinmei@isl.rdc.toshiba.co.jp>
    Message-ID:  <y7vy8ju59e7.wl@ocean.jinmei.org>

  | ...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.

kre

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