Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast
RFC 4604
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Margaret Cullen; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
The reference to [IANA-ALLOCATION] should probably be to http://www.iana.org/assignments/multicast-addresses ; I dunno if the RFC 3553 namespace is usable in this context.
(David Kessens; former steering group member) No Objection
From Pekka Savola, ops directorate: Was OK when I last took a look at it prior to being shipped to the IESG.
(Harald Alvestrand; former steering group member) No Objection
Reviewed by Spencer Dawkins, Gen-ART Review copied below. This specification, taken on its own, is mostly ready for publication as a proposed standard. I could implement the protocol from the specification, and it's reasonably clear what's going on. My only question is (echoing Margaret's question in the ID Tracker), "why was this specification not written as updates to RFC 3376 and MLDv2, especially since MLDv2 wasn't an RFC yet?" Call me sensitive, but we have an entire working group figuring out what TCP really is beneath all the independent specifications that change TCP behavior as specified in RFC 793. Do we want to go here again? MLDv2 has been published as RFC 3810 (in June), so the reference needs to be updated. I guess I'm also curious about why hosts SHOULD log errors, but routers MAY log errors. I'm guessing that the idea was that the hosts are the ones causing the problems, so they should work harder to make sure someone notices logged errors, but this seems like a throwback to a simpler time - we can't get people to stop clicking on .pif files, or .scr files, or .zip files, so shouldn't we try harder to make sure network operators know there's a problem? But I thought SHOULD was "in most cases, MUST, but this doesn't make sense in all cases", and am trying to figure out what the corner cases might be.
(Jon Peterson; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
Please create a subsection in section 1 that references RFC 2119 and defines the use of the MODIFICATION tag.
(Scott Hollenbeck; former steering group member) No Objection
Section 6 typo: s/and Pekka Savola and/and Pekka Savola/
(Steven Bellovin; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Thomas Narten; former steering group member) No Objection