[dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Tue, 03 August 2004 01:58 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21807; Mon, 2 Aug 2004 21:58:29 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroVq-0007Pv-OM; Mon, 02 Aug 2004 21:54:46 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroU0-0006ys-RE for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 21:52:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21645 for <dhcwg@ietf.org>; Mon, 2 Aug 2004 21:52:51 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BroWz-0000hi-87 for dhcwg@ietf.org; Mon, 02 Aug 2004 21:55:57 -0400
Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:5932:46d5:8557:40fa]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F17BE1525D; Tue, 3 Aug 2004 10:52:42 +0900 (JST)
Date: Tue, 03 Aug 2004 10:52:42 +0900
Message-ID: <y7vhdrl56ol.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: venaas@uninett.no, tjc@ecs.soton.ac.uk
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: dhcwg@ietf.org
Subject: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
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

Hoping it's not too late, here a couple of comments (or questions,
actually) on the draft.

1. I'm still not really sure what the client should do for information
   when a lifetime expires.

   For example, the draft says in Section 3.1 that

     If client has received a lifetime with this option, and contacts
     server to receive new or update any existing data prior to its
     expiration, it SHOULD also update data covered by this option.  If no
     new lifetime is received, it MUST behave as if no value was ever

  I don't understand the scenario.  Does this mean the following case?

  - The client sends an Information-request message, and gets a reply
    with a DNS server address (call it X) with lifetime of 1 hour.
  - 30 minutes later, the client happens to resend an
    Information-request message.  This time, it gets a response, but
    the response does not contain either DNS server address X or a new

  If this is an intended scenario, then what does "behave as if no
  value was ever provided"?  Does it mean the client MUST treat
  address X as if it had infinite lifetime?  Or does this mean the
  client MUST regard address X expired immediately?  Or something

  Also, I don't understand what the client should do with DNS server
  address X when the lifetime expires and the client does not get any
  reply for the try to update the information.  Should the client
  invalidate address X?  Can/should it continue to use it?

  Even if the client can update the information of address X with a
  new lifetime, how can we regard the period from the time when the
  previous lifetime expires and the time when the client gets the new
  information?  Should we temporarily invalidate the address during
  the update period?  Or Can we continue to use it?  Probably the
  latter makes sense when the client can update the information, but
  it does not really match my intuition of "expiration"...
2. the usage of the lifetime option for other exchanges than
   Info-req/Reply exchanges.

   I'm even not 100% sure if the lifetime can be used for the other
   types of exchanges.  Probably it can according to the draft, but
   then I'll have several questions on how to use it.

   For example, the draft says:

     Before making the request it MUST wait for a random amount of time
     between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].

  Is this also applies to the other cases even if INF_MAX_DELAY is a
  dedicated parameter for Info-req?  If so, is it really valid?

  Also, how does the client exactly react to the expiration event for
  the other cases?  For example, consider the following scenario:

  - the client performs Solicit->Advertise->Request->Reply exchanges,
    and gets an IPv6 address allocated, a DNS server address X, and an
    associated lifetime T.
  - before the timeout "T1" for the allocated address passes, lifetime
    T expires.  In this case, should the client restart the entire
    session from Solicit?  Or should the client send a renew message?
    If so, the renew message also tries to update the allocated
    address even if it's too early?  Or should the client even start
    Information-request/Reply exchanges just to update the DNS address

As an implementor, it's very hard to implement this option with
confidence just from this specification...

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.

dhcwg mailing list