Triggering DHCPv6 Reconfiguration from Relay Agents
draft-ietf-dhc-triggered-reconfigure-07

I have no objection to the publication of this document, but I do see a few issues that I would strongly suggest you resolve before handing the text to the RFC Editor.

---

Section 4 could probably be renamed since, I assume, this is no longer
a proposal, but a real protocol solution. Changes to the text as well.

---

In 6.4 I think the term "reject" is mis-applied because there is no 
rejection involved.

---

Section 6.5 does not clearly explain how to build a rejection 
Reconfigure-Reply message despite that section 9 says it does.

You should add a statement about how a rejection is conveyed and which
status code to use.

---

Section 6.6

   Depending on the status code enclosed in a received RECONFIGURE-REPLY
   message, the relay may decide to terminate the request or try a
   different corrected Reconfigure-Request.

Undoubtedly true, but which codes get which treatment?

---

Please decide whether the names of the new messages are in upper case
or not.

Version -07 has resolved my concerns, and thanks for addressing them.

Thanks for quickly addressing my comment in the new draft version.

Regards, Benoit

I have no problems with the publication of this document, but I do have some non-blocking comments...

1. Section 6 : The first sentence in 6.2.1 ("Clients MUST silently discard any received RECONFIGURE-REQUEST message") is useless.  A client implementation won't know about this protocol that works between relays and servers.

2. Section 6.3 : I see "The relay agent MAY supply the updated configuration in the RSOO" and wonder why this is a MAY. If the updated configuration is not included, what is the DHCP server to do? The discussion in Section 6.5 does not seem to cover the situation from the server's perspective.

minor nit:

section 4

  If the relay has no client  to reconfigured, it stops sending Reconfigure-Request messages.
-
  If the relay has no client to be reconfigured, it stops sending Reconfigure-Request messages.

or

  If the relay has no client to reconfigure, it stops sending Reconfigure-Request messages.

6.4/6.5: "MUST be configurable"? Aside from this being completely unverifiable, I don't see any justification for such a requirement in this document.

6.5: "the server MAY use its content", "The server MAY use the content". Lowercase the MAYs. Better yet, use "might" or "can". These aren't protocol options.

thanks for dealing with my discusses.

I agree with Sean's discuss.