Subject: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind

From: Stig Venaas <[email-masked]>
Date: Tue, 20 Feb 2007 16:36:20 +0100

This message announces a wg last call on "Rebind Capability in DHCPv6
Reconfigure Messages" <draft-ietf-dhc-dhcpv6-reconfigure-rebind-01.txt>

The last call will conclude at 1700EST on Tue, 2007-03-06.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

As defined in DHCPv6 (RFC 3315), the reconfigure message msg-type can
only be renew or information-request. 
draft-ietf-dhc-dhcpv6-reconfigure-rebind expands the allowed values of
the msg-type field of the reconfigure message to allow the server to
indicate that the client is to attempt to perform a Rebind; since Rebind
messages are multicast, this avoids the necessity of the client 
contacting a particular server.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-01.txt

Stig

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 22 Feb 2007 15:28:13 +0900

>>>>> On Tue, 20 Feb 2007 16:36:20 +0100, 
>>>>> Stig Venaas <[email-masked]> said:

> acceptance during the WG last call, the document will not be advanced

I see the need for this extension and basically support the idea of
the draft; however, I don't think this particular version is ready to
ship.

I have the following concerns on the current version:

- this version does not specify how the client reacts to a Reconfigure
  message specifying Rebind.  it also does not clarify what the client
  should do if it receives a Reconfigure message specifying Renew but
  the server identifier is different from the one for the 'latest'
  server for the client.  I think we should clarify these points.

- similarly, this version does not specify when a server should
  specify Renew in a Reconfigure message and when it should specify
  Rebind.  I believe we should also clarify this point.

- the use of term "multicast" in this document is confusing or is not
  really correct.  I first thought it means that the message is sent
  to an IPv6 multicast destination address (which should be
  ff02::1:2), but then I found this interpretation does not make sence
  in the context of the text.  Next I thought "multicast" means that 
  the DHCPv6 message is (or can be) sent without a Server Identifier
  option, which makes much more sense to me, but then I think the text
  should not use the confusing term of "multicast".

  Besides, the use of "multicast" is not really correct in either
  interpretation.  If it means ff02::1:2, this is not always true
  because a Renew message can be unicasted based on agreement between
  the client and the server.  If it means the lack of Server
  Identifier option, this is also not really true because the
  specification does not prohibit an Information-request message from
  having a Server Identifier option.

Related to the last point, it was diffucult for me to understand the
following paragraph:

   In a network with multiple DHCPv6 servers, the Reconfigure message
   may not be sent by the same server as the one from which the client
   last obtained configuration and/or addressing information.  If the
   Reconfigure message commands the client to perform a Renew, [2] does
   not specify to which server the client should send the Renew.  This
   difficulty is avoided if the server commands the client to perform an
   Information-Request, since such messages are multicast.  However,
   Information-Request messages do not cause addressing configuration to
   be returned.
(section 1, 2nd para)

Part of the source of the difficulty is the unclear meaning of
"multicast".  Also, it was not really clear for me what "such
messages" exactly specify: does this mean Information-request, or
Information-request and Renew?  It was also unclear to me what "this
difficulty" exactly means.  Finally, I didn't understand what the last
sentence actually tries to convey (I could speculate, but I could not
be sure).  I think this paragraph needs a full revision, clarifying
these points.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Tue, 27 Feb 2007 14:55:06 +0100

> I have the following concerns on the current version:

I agree, I also believe that some of the text is too vague. It is a
bit underspecified. It could also be explained better under what
circumstances this is needed and how it would be used.

Stig