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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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

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

  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
  else?

  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
    information?

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.
					[e-mail]

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg