Triggering DHCPv6 Reconfiguration from Relay Agents
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
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
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
thanks for dealing with my discusses.