Handling Unknown DHCPv6 Messages
draft-ietf-dhc-dhcpv6-unknown-msg-08
Yes
(Barry Leiba)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Kathleen Moriarty)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
Abstain
Recuse
(Ted Lemon)
Note: This ballot was opened for revision 05 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -06)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -06)
Unknown
Brian Haberman Former IESG member
(was Discuss, Yes)
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2014-03-25 for -06)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -06)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -07)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-03-22 for -06)
Unknown
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 IESG member
(was Discuss)
Abstain
Abstain
(2014-03-26 for -07)
Unknown
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 IESG member
Recuse
Recuse
(for -05)
Unknown