Subject: Re: [dhcwg] [dhc] #7: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind

From: "dhc issue tracker" <[email-masked]>
Date: Wed, 10 Sep 2008 15:26:08 -0000

#7: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind
---------------------------------------+------------------------------------
 Reporter:  [email-masked]           |        Owner:     
     Type:  defect                     |       Status:  new
 Priority:  major                      |    Milestone:     
Component:  dhcpv6-reconfigure-rebind  |      Version:     
 Severity:  In WG Last Call            |   Resolution:     
 Keywords:                             |  
---------------------------------------+------------------------------------

Comment(by [email-masked]):

 Bernie Volz (9/10/08)

 I support this document moving forward.

 There are some MINOR nits:

 In Abstract:

   This document updates RFC 3315 to allow the Rebind message type to
   appear in the Reconfigure Message option of a Reconfigure message,
   which allows DHCPv6 servers to instruct clients to perform a Rebind
   operation as well as a Renew operation.  The document also clarifies
   how a DHCPv6 client responds to a received Reconfigure message.

 It might have been clearer to have said that this extends the
 Reconfigure to allow a Rebind. The "perform a Rebind operation as well
 as a Renew operation" is a bit odd as it might be taken to mean both
 ("as well as").

 In Section 4, Server Behavior

   The server MUST include a Reconfigure Message option (as defined in
   Section 3 to select whether the client responds with a Renew message,
   a Rebind message or an Information-Request message.

 The parenthesis is never closed. I believe it should be "(as defined in
 Section 3)"?

 Section 4.1, Client Behavior

   part of a client-initiated configuration exchange.  See sections
   18.1.3, 18.1.4 and 18.1.5 of RFC 3315for details.  If the client does
                                        ^ space missing (RFC editor
 would fix)

 And, in this same paragraph:

   The client uses the same variables and retransmission algorithm as it
   does with Renew, Rebind or Information-request messages generated as
   part of a client-initiated configuration exchange.  See sections
   18.1.3, 18.1.4 and 18.1.5 of RFC 3315for details.  If the client does
   not receive a response from the server by the end of the
   retransmission process, the client ignores and discards the
   Reconfigure message.

 So, for a Reconfigure with Renew, does this imply that the client would
 NOT then send a Rebind (as the Renew retransmission runs until the t2
 timer starts)? This is original text. And perhaps the "Reconfigure" at
 the t2 time really doesn't matter (as the client should be sending
 Rebinds then anyway).

 This does raise another issue that probably is implicit - if the client
 is doing Renews when it receives a Reconfigure (for Rebind), it
 transitions to Rebind immediately. If the client is doing Renews when it
 receives a Reconfigure (for Renew), should it do anything differently?
 (One can also ask if the client is already Renewing and receives a
 Reconfigure w/Renew whether it does anything differently.)

 Sorry to raise these issues - they probably are pretty obvious as to
 what the client should do.

 - Bernie

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dhc/trac/ticket/7#comment:1>
dhc <http://tools.ietf.org/wg/dhc/>

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "dhc issue tracker" <[email-masked]>
Date: Wed, 10 Sep 2008 16:10:24 -0000

Description changed by [email-masked]:

Old description:

> The WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind will end at
> 1700PDT on 9/29/2008.

New description:

 The WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind will end at
 1700PDT on 9/29/2008.

 The discussion thread for this WG last call is at [http://www.ietf.org
 /mail-archive/web/dhcwg/current/msg08857.html www.ietf.org/mail-
 archive/web/dhcwg/current/msg08857.html]

--

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/dhc/trac/ticket/7#comment:2>
dhc <http://tools.ietf.org/wg/dhc/>