Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network
RFC 8114

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

(Terry Manderson) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2017-01-31 for -16)
No email
send info
- IPR: so we have a late IPR declaration that sys
RAND+royalty but yet the filing refers to the I-D
that preceded the application and there's a common
author/inventor. Sheesh. But the WG did consider it
and were ok going ahead from a look at the list.
(So there's no need to reply to my whining here:-)

- 6.3: Is RFC7739 worth a mention here?  Not sure

- section 9: I'd have thought that this solution
reduced the potential for a DoS compared to the
previous situation where multicast traffic is 
mapped to unicast? If so, worth a mention?

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Comment (2017-02-01 for -16)
No email
send info
- Please spell out DR at its first occurrence

- Not sure I understand what the intention of the following section is:
"6.4.  Host Built-in mB4 Function

   If the mB4 function is implemented in the host which is directly
   connected to an IPv6-only network, the host MUST implement the
   behaviors specified in Sections 6.1, 6.2, and 6.3.  The host MAY
   optimize the implementation to provide an Application Programming
   Interface (API) or kernel module to skip the IGMP-MLD Interworking
   Function.  Optimization considerations are out of scope of this
  Why is this mentioned? Does that has to be normative?

(Kathleen Moriarty) No Objection

Comment (2017-01-31 for -16)
No email
send info
I agree with Stephen that section 6.3 ought to mention RFC7739.  

If there's a reduction in the chance of a DoS from the previous method, I agree with Stephen that it should be mentioned.

Alvaro Retana No Objection