Subject: Re: [Dhcpv6bis] [dhcpv6bis] #71 (XML 3315): Bakeoff: Clients: T1/T2 = 0

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 10 Dec 2014 13:50:20 -0000

#71: Bakeoff: Clients: T1/T2 = 0

Comment (by [email-masked]):

 We also should add something like "When receiving T1 and T2 set to 0 the
 client MUST NOT initiate immediate renewal procedure.". It seems obvious,
 but there are broken clients that do that.

-- 
----------------------------+--------------------------------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  task            |      Status:  new
 Priority:  P4 minor        |   Milestone:  B moderate, apply after merge
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:
----------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/71#comment:3>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 10 Dec 2014 14:10:25 -0000

Changes (by [email-masked]):

 * owner:   => [email-masked]

-- 
----------------------------+--------------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  new
 Priority:  P4 minor        |   Milestone:  B moderate, apply after merge
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:
----------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/71#comment:4>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 23 Dec 2014 19:55:12 -0000

#71: Bakeoff & More: Clients: T1/T2 = 0

Comment (by [email-masked]):

 During WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09, Ted commented:

 I think [the following] is bad advice:

      If T1 or T2 had been set to 0 by the server (for an IA_NA) or there
      are no T1 or T2 times (for an IA_TA) in a previous Reply, the
      client may send a Renew or Rebind message, respectively, at the
      client's discretion.

 Can the client send a Renew or Rebind after zero seconds?   That would be
 at its discretion, but obviously bad.   I think the right advice is to say
 that the client should choose a renew and rebind interval that is
 consistent with the valid and preferred times of all the addresses and
 prefixes received: if there are addresses and/or prefixes with preferred
 times, then the renewal and rebind times should result in those addresses
 and/or prefixes being renewed well before the preferred lifetime expires;
 if there are addresses with preferred lifetimes of zero, but residual
 valid lifetimes, these should not be renewed.   That might be too
 complicated for this document, though--if you prefer, you could just say
 "at the client's discretion, but no sooner than X," but then we'd have to
 argue about what X should be.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/71#comment:5>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>