Handling Unknown DHCPv6 Messages
draft-ietf-dhc-dhcpv6-unknown-msg-08

Note: This ballot was opened for revision 05 and is now closed.

Barry Leiba Yes

(Jari Arkko) No Objection

Comment (2014-03-25 for -06)
No email
send info
The document needs a revision to address suggested changes being made in the discussion that followed Suresh Krishnan's Gen-ART review.

(Alia Atlas) No Objection

(Richard Barnes) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-03-22 for -06)
No email
send info
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.

(Brian Haberman) (was Discuss, Yes) No Objection

(Kathleen Moriarty) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Joel Jaeggli) (was Discuss) Abstain

Comment (2014-03-26 for -07)
No email
send info
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) Recuse