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

Note: This ballot was opened for revision 05 and is now closed.

(Ted Lemon) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

Benoit Claise No Objection

Comment (2013-05-16)
Thanks for quickly addressing my comment in the new draft version.

Regards, Benoit

Spencer Dawkins No Objection

(Adrian Farrel) No Objection

Comment (2013-05-06 for -06)
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.

(Stephen Farrell) No Objection

Comment (2013-05-14 for -06)
I agree with Sean's discuss.

(Brian Haberman) No Objection

Comment (2013-05-13 for -06)
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.

(Joel Jaeggli) No Objection

Comment (2013-05-05 for -05)
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.

(Barry Leiba) (was Discuss) No Objection

Comment (2013-05-15)
Version -07 has resolved my concerns, and thanks for addressing them.

(Pete Resnick) No Objection

Comment (2013-05-12 for -06)
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.

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2013-05-21)
thanks for dealing with my discusses.