Rebind Capability in DHCPv6 Reconfigure Messages
RFC 6644
Yes
No Objection
Recuse
Note: This ballot was opened for revision 09 and is now closed.
(Barry Leiba; former steering group member) Yes
(Brian Haberman; former steering group member) Yes
(Jari Arkko; 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
have a few comments that either reperesent my failure to grasp what
you are doing, or would make useful improvements to the document.
---
I would prefer that Section 3 did not include the format of the
Reconfigure Message option. Rather than "update" the option with a
full replacement, isn't it enough to say that msg-type may now
additionally take the value 6 to indicate Rebind?
---
Section 4
The server MUST include a Reconfigure Message option (as defined in
Section 3) to select whether the client responds with a Renew
message, a Rebind message or an Information-Request message.
Include in what?
---
Section 4 is headed "Server Behavior"
The Reconfigure message causes the client to initiate a Renew/Reply,
a Rebind/Reply message exchange or an Information-request/Reply
message exchange.
Seems to be describing the client behavior. At least give a forward
pointer to Section 5.
---
Section 4
The server interprets the receipt of a Renew, a
Rebind or an Information-request message (whichever was specified in
the original Reconfigure message) from the client as satisfying the
Reconfigure message request.
Presumably, only if threceived message matches the msg-tpe in the
Reconfigure Message option? What if there is a mismatch? can the
mismatch be caused by a race?
---
Section 5
How is a legacy client going to handle a Reconfigure Message option
with msg-type set to Rebind? Presumably it is going to run some 3315
logic to drop or nack the message as "msg-type unknown, unexpected,
or unsupported".
I believe you should mention this as it impacts on server behavior.
(Benoît Claise; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
The introduction motivates some of these changes with a use case of a network administrator who is preparing to shut down a dhcpv6 server causing clients to move to a different server. Is it possible (if so, how easy would it be) to misconfigure the servers involved to cause them to enter a rebind war with each other? If this is something a client might experience, is there guidance to give the client implementations on how to react when it happens?
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Please consider the editorial suggestions in the Gen-ART Review by Francis Dupont on 7-Apr-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07344.html
(Sean Turner; former steering group member) No Objection
1) I support Stephen's discuss. 2) s4: I was having some issues tracking exactly which paragraphs in 19.1-19.3 were being updated/replaced. Could you do the old/new so we knew which paragraphs were being replaced. Ex (assuming I got this bit right): 4.1 Updates to Section 19.1 OLD: A server sends a Reconfigure message to cause a client to initiate immediately a Renew/Reply or Information-request/Reply message exchange with the server. NEW: The server MUST include a Reconfigure Message option (as defined in Section 3) to select whether the client responds with a Renew message, a Rebind message or an Information-Request message. 3) s5: If the text replaces the text in s19.4 of RFC 3315 could you just say that? r/This section updates specific text in/This section replaces
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- 1st sentence of abstract seems odd, v. hard to read anyway and that's not so good usually. How does the "Reconfigure Message" extend "the Reconfigure Message"? (That's how I read it anyway)
(Wesley Eddy; former steering group member) No Objection
(Ralph Droms; former steering group member) Recuse