Triggering DHCPv6 Reconfiguration from Relay Agents
RFC 6977
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Ted Lemon; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Barry Leiba; former steering group member) (was Discuss) No Objection
Version -07 has resolved my concerns, and thanks for addressing them.
(Benoît Claise; former steering group member) No Objection
Thanks for quickly addressing my comment in the new draft version. Regards, Benoit
(Brian Haberman; former steering group member) No Objection
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.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
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.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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.
(Richard Barnes; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
thanks for dealing with my discusses.
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
I agree with Sean's discuss.
(Stewart Bryant; former steering group member) No Objection