Skip to main content

IPv6 Multicast Address Scopes
RFC 7346

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 steering group member) Yes

Yes (for -05)

                            

(Ted Lemon; former steering group member) Yes

Yes (for -06)

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2014-06-13)
Thanks for addressing my Discuss

(Alia Atlas; former steering group member) No Objection

No Objection (2014-06-10 for -06)
Agree with Adrian's discuss and Stephen's comments.

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2014-06-03 for -05)
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 steering group member) No Objection

No Objection (for -06)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -06)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -06)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2014-06-07 for -06)
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 steering group member) No Objection

No Objection (for -06)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -06)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (for -06)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (2014-06-09 for -06)
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 steering group member) No Objection

No Objection (2014-06-06 for -06)

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:-)