Skip to main content

Multicast Considerations over IEEE 802 Wireless Media
RFC 9119

Yes

Éric Vyncke

No Objection

(Adam Roach)
(Alexey Melnikov)
(Barry Leiba)
(Deborah Brungard)

Recuse


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

Éric Vyncke Yes

Alvaro Retana No Objection

Comment (2020-01-08 for -11)
I support Alissa's DISCUSS.

Documentation nit:  this document should be tagged in the Datatracker as also replacing draft-perkins-intarea-multicast-ieee802 [1].

[1] https://mailarchive.ietf.org/arch/msg/mboned/PdwqOiMseSmeJiLnCl8JgLAOlE0

Roman Danyliw (was Discuss) No Objection

Comment (2021-02-05 for -13)
Thank you for addressing my DISCUSS and COMMENT items.

Warren Kumari Recuse

Comment (2019-12-23 for -11)
I'm an author, and so am recusing myself from the ballot.

Thanks to Eric for being willing to be the responsible AD.

(Adam Roach; former steering group member) No Objection

No Objection (for -11)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -11)

                            

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2020-11-25 for -12)
Thanks for addressing my DISCUSS points. As a courtesy, please respond to the Gen-ART review.

(Barry Leiba; former steering group member) No Objection

No Objection (for -11)

                            

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2021-07-28)
Thanks for addressing my last comments!

(Deborah Brungard; former steering group member) No Objection

No Objection (for -11)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (2020-01-07 for -11)
Hi,

thank you. Interesting read. However, a bit like Alissa, I'm not sure what the IETF should do (in terms of protocol design/extension), if anything.
In fact, it seems that some solutions exist / have been standardized but are simply not yet implemented.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2020-01-07 for -11)
As TSV-ART reviewer, Gorry Fairhurst provided an extensive review of this doc in Last Call and a re-review of the current version just recently (Thanks!). There are still a large number of comments that have not been addressed and no response was provided from the authors so far. While many of his comments are mostly editorial, I believe that this doc could really benefit from addressing them. There are a couple of relevant references that Gorry provides in his review which I think should be cited by this document. Further as Gorry mentioned, there are congestion control schemes for multicast and also high-layer mechanism to make use of multicast support more reliable. This is not discussed at all. So I'm not even sure if the conclusion in section 8 is correct that multicast on 2-layer must be reliable. Given the number and details of problems listed, I find the discussion in section 8 way to high level anyway.

Also probably editorial: I find it a bit confusion that section 5.1. suddenly speak all about the IETF network while the rest of the doc seems more general. Is that on purpose or is that a left over from merging two docs?

I'm not raising any points on the Discuss-level as I believe most (TSV-ART) points are rather editorial (also some may touch technical points well), however, I also support the points raised by Alissa and the GEN-ART review and would really like to see them addressed before publication (ideally they would have been addressed before IESG evaluation...).

(Suresh Krishnan; former steering group member) No Objection

No Objection (2020-01-08 for -11)
* Section 3.1.4.

Is this really the case? I thought multicast was best effort. Can you add a reference to the relevant section of the 802.11* spec for this 

"Multicast traffic is delayed in a wireless network if any of the
  STAs in that network are power savers.  All STAs associated to the
  AP have to be awake at a known time to receive multicast traffic."

* Section 3.2.2.

-> What does PIM have to do with IPv6 to be listed here? It applies just as well to IPv4. Can you clarify?
-> What is "Geographic Routing"?

-> Please add a reference to RFC4941 for this IPv6 privacy addresses in this sentence

"IPv6 node will typically use multiple addresses, and may change them often for privacy reasons"

* Sections 3.2.3. and 3.2.4. 

For the "solicited-node addresses" I think a reference to RFC4291 Section 2.7.1. would be extremely useful since this term is not used widely known outside hardcore IPv6 circles. 

* Section 3.2.4.

-> The correct reference for IPv6 Neighbor Discovery should be RFC4861. RFC2461 has been obsolete for more than a decade now. Is there a specific reason you are referring to the older version of ND here while the rest of the document uses the right reference?

-> I think it might be better to separate out the ARP issues into a separate section instead of lumping into this one titled "Spurious ND"

* Section 8

"The IETF should determine guidelines by which it may be decided that multicast packets are to be sent wired..."

I had the same question as Benjamin and would like to see this clarified.