Skip to main content

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