IPv6 Multicast Address Scopes
draft-ietf-6man-multicast-scopes-07
Yes
(Brian Haberman)
(Ted Lemon)
No Objection
(Alissa Cooper)
(Benoît Claise)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
Note: This ballot was opened for revision 05 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -05)
Unknown
Ted Lemon Former IESG member
Yes
Yes
(for -06)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2014-06-13)
Unknown
Thanks for addressing my Discuss
Alia Atlas Former IESG member
No Objection
No Objection
(2014-06-10 for -06)
Unknown
Agree with Adrian's discuss and Stephen's comments.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -06)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-06-03 for -05)
Unknown
1. Did you mean to change the text for scop=1 in the table, from "Interface-Local scope" to just "Interface"? I don't think so. 2. In Section 3 you say this: Section 5 gives the definition of scop 3 for IEEE 802.15.4 [IEEE802.15.4] networks. ...but then Section 4 immediately talks about Section 5 of RFC 4007. Just to make sure no one misunderstands, maybe Section 3 should say, "Section 5, below, gives...", yes? 3. I understand you're about to submit a revised I-D that clarifies this from the IANA Considerations: The registry will have a note associated with scope 3 listing all RFCs that define Realm-Local scoping rules that use scope 3. I await that update, and might comment further...
Benoît Claise Former IESG member
No Objection
No Objection
(for -06)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -06)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -06)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-06-07 for -06)
Unknown
I'm curious to see the response on Stephen's question. Also, the referenced security consideration sections don't talk about the global scope and any risk related to not having a boundary. Some text on that could be helpful or perhaps an explanation so I know why it is not needed would be helpful.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -06)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -06)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -06)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-06-09 for -06)
Unknown
Ah, the glories of getting a late start on telechat reading. I would have balloted Discuss on approximately Stephen's point, but it's already being robustly discussed among people who understand the details better than I do, and seems close to converging. :D
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-06-06 for -06)
Unknown
Pardon my multicast ignorance (I only used smcroute for the 1st time recently:-) but what happens if a router in the group supports two different technologies on different interfaces, each of which defines scop=3 to be something local(-ish) - do the packets get forwarded between technologies or not? If the answer to the above is "yes," then I think there's a security consideration to be stated here, which is that scop=3 does not mean that packets are limited to being seen by nodes running a specific technology but may go further via a router. That could be unexpected enough to be worth stating. If the answer is "no" then I think you need to change the draft to make that clearer, if you want people like me to understand that. Or maybe its just a dumb question:-)