Handling Unknown DHCPv6 Messages
RFC 7283
Yes
No Objection
Abstain
Recuse
Note: This ballot was opened for revision 05 and is now closed.
(Barry Leiba; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Brian Haberman; former steering group member) (was Discuss, Yes) No Objection
(Jari Arkko; former steering group member) No Objection
The document needs a revision to address suggested changes being made in the discussion that followed Suresh Krishnan's Gen-ART review.
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
Two very nitty/minor comments. Feel free to ignore them. Is it worth noting the potential for loops here? That'd need a server to also re-tx a received message to a relay (who'd send it back) or for the server to generate a new message (or even better two new messages:-) in response to receiving one from a relay. I doubt it'd happen so probably not worth a mention unless there's some DHCP specific behaviour that might trigger such a loop. (I know of none.) In a similar vein, is there any DHCP mechanism where a relay would send out the unknown message to two or more servers as some form of load balancing? If there were, then maybe it'd be worth just sending unknown message types to one server and not to all? If it went to all, and each server then "occasionally" pinged the relay to see if had been updated and each ping gets sent to all servers... Again probably not worth a mention since I don't see it being a bad loop, so just in case it rings a bell with you.
(Joel Jaeggli; former steering group member) (was Discuss) Abstain
was . Problem Statement When a relay agent receives a message, it decides to send the message either toward the server or toward the client. However, RFC 3315 does not explicitly describe how the relay agent can determine whether it should send a message toward the server or the client, although this is implied by the message definitions in RFC3315. Imho this is untrue. A relay agent receives two kinds of messages, messages it is configured to relay to a dhcpv6 server, e.g. because it is configured for a specific subnet, or because it is configured a relay for relays, replies or messages constructed with relay -replies contain the information necessary for them to be forwarded. 3315 section 20 The problem statement covers message routing however section 4. and later are not in fact about message routing but rather about that handling of unknown message types which seems orthogonal to the problem statement. in fact it would seem better if the problem statement reflected the problem the draft is trying to address.
(Ted Lemon; former steering group member) Recuse