Multicast Considerations over IEEE 802 Wireless Media
draft-ietf-mboned-ieee802-mcast-problems-15

Thank you for addressing my DISCUSS and COMMENT items.

Thanks for addressing my DISCUSS points. As a courtesy, please respond to the Gen-ART review.

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

Thanks for addressing my last comments!

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.

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

* 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.