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

[Ballot discuss]
Many thanks for all the updates from -11 to -14; the preponderance are
good and improve the document.

I especially appreciate the change in section 9 to claim only that the
use of IPsec is specified, rather than mandated, by the referenced
document.  Unfortunately, the reference document was changed as well,
from RFC 4601 to RFC 7761, but RFC 7761 calls out as one of the changes
from RFC 4601 that "authentication using IPsec" was removed.  So the
current claim in the -14, that "[RFC7761] [...] specifies the use of
IPsec to ensure authentication of the link-local messages in [PIM-SM]"
is not correct, though for a different reason than what I noted in my
ballot position on the -11.  It may be most expedient to just restore
the reference to the obsolete document, though of course there are other
possibilities.

[Ballot comment]
Section 3.2.1

  o  ARP [RFC5424]

RFC 5424 is "The Syslog Protocol"; while RFC 5494 is only hamming
distance one away and relates to ARP, it seems that the original RFC 826
might actually be a better reference.

Section 8

I'm still a little confused by the first point -- it seems to be
suggesting that some types of multicast traffic might only be sent if
sending over a wired interface and just dropped for wireless interfaces,
which both introduces a layering violation and causes wireless to be a
"second-class citizen".  Presumably there is some more subtlety than
that, but I'm missing it.

[Ballot comment]
* 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.

[Ballot discuss]
Section 9 says that "[RFC4601], for instance, mandates the use of IPsec
to ensure authentication of the link-local messages in the Protocol
Independent Multicast - Sparse Mode (PIM-SM) routing protocol" but I
could not find where such use of IPsec was mandated.  (I do recognize
that a similar statement appears almost verbatim in RFC 5796, but RFC
5796 seems focused on extending PIM-SM to support ESP in additon to the
AH usage that was the main focus of the RFC 4601 descriptions, and does
not help clarify the RFC 4601 requirements for me.)  The closest I found
was in Section 6.3.1 of RFC 4601: "The network administrator defines an
SA and SPI that are to be used to authenticate all link-local PIM
protocol messages (Hello, Join/Prune, and Assert) on each link in a PIM
domain" but I do not think that applies to all usage of PIM-SM.  Am I
missing something obvious?

[Ballot comment]
To what extent would it be wrong to use the common "BUM" abbreviation
("Broadcast/Unknown-Unicast/Multicast" to discuss the classes of traffic
discussed in this hdocument?  That is, we say "multicast" a lot but in
several places the discussion suggests that broadcast is treated
similarly, and it would be nice to have a uniform treatment for the
cases where broadcast and multicast are effectively equivalent, so that
it's easier to call out when there is an actual distinction between the
handling for the two.  (I guess that the "unknown unicast" case doesn't
really apply at the MAC layer...)

I have very little background on IEEE radio technologies, or radio
technologies in general; my apologies in advance for the many questions
I ask that betray my ignorance.  I understand that I'm not exactly the
target audience for this document and that it's not going to be
appropriate to add clarifying text at all locations where I ask for help
understanding the content.

Abstract

  This document describes the problems of known limitations with
  wireless (primarily 802.11) Layer-2 multicast.  Also described are

nit: this doesn't flow very well; maybe just "describes the known limitations
of wireless" would suffice?

Section 1

  send duplicate data to each recipient.  With broadcast traffic, data
  is sent to every device regardless of their interest in the data.

nit: maybe "expressed interest"?  I expect there are some
infrastructure-type broadcast traffic that is of interest to all
participants in many IP networks.

  problem.  Wi-Fi traffic classes may help.  This document is intended
  to help make the determination about what problems should be solved
  by the IETF and what problems should be solved by the IEEE (see
  Section 8).

Do we need formal IEEE buy-in before making this kind of statement?

  rates, no acknowledgements, and low data rate.  It also explains some
  enhancements that have been designed at the IETF and IEEE 802.11 to
  ameliorate the effects of multicast traffic.  Recommendations are

I suggest clarifying whether this is "ameliorate the effects of
multicast traffic on other users of the spectrum" or "ameliorate the
effects of the radio medium on multicast traffic".

Section 2

I agree with the TSV-art reviewer that a more precise definition of what
the "packet error rate" is measuring would be useful.

Section 3.1.1

  traffic.  Since multicast makes point-to-multipoint communications,
  multiple acknowledgements would be needed to guarantee reception at
  all recipients.  Since there are no ACKs for multicast packets, it is

nit: there seems to be an implicit "but that would be highly inefficient
and is not done" between "multiple acks would be needed" and "there are
no acks".

Section 3.1.2

  Multicast over wired differs from multicast over wireless because
  transmission over wired links often occurs at a fixed rate.  Wi-Fi,
  on the other hand, has a transmission rate that varies depending upon
  the STA's proximity to the AP.  The throughput of video flows, and
  the capacity of the broader Wi-Fi network, will change and will
  impact the ability for QoS solutions to effectively reserve bandwidth
  and provide admission control.

nit: rhetorically, this sentence doesn't say when/why the throughput
will change, but rather treats it as a spontaneous and independent
event.

  For wireless stations associated with an Access Point, the power

nit: I assume "associated with" refers to the current radio traffic, and
not some administrative or organizational grouping, as a naive reader
might expect using the default meaning of "associated"; some additional
lead-in might be helpful.

  In fact, backward compatibility and multi-stream implementations mean
  that the maximum unicast rates are currently up to a few Gbps, so
  there can be more than 3 orders of magnitude difference in the
  transmission rate between multicast / broadcast versus optimal
  unicast forwarding.  Some techiques employed to increase spectral

nit: I think "backward compatibility" is only applicable to the 3 orders
of magnitude difference in tx rate, and is not applicable to the maximum
unicast rates being a few Gbps.

Section 3.1.3

  communications and degrade the overall capacity.  Furthermore,
  transmission at higher power, as is required to reach all multicast
  STAs associated to the AP, proportionately increases the area of
  interference.

nit: it's most precise when talking about interference to say what
interferes with what else; in this case it would be (IIUC) the area in
which multicast traffic causes interference with other consumers of the
radio spectrum.

Section 3.1.4

  One of the characteristics of multicast transmission is that every
  station has to be configured to wake up to receive the multicast,
  even though the received packet may ultimately be discarded.  This

This seems like something of a non sequitur -- the text would work if we
were discussing broadcast traffic, but for multicast aren't the intended
recipients known?

  o  Both unicast and multicast traffic can be delayed by power-saving
      mechanisms.

Just to check my understanding: this is "works poorly" just because of
the additional latency?  (Is this effect more pronounced for multicast
than for unicast?)

  o  A unicast packet is delayed until an STA wakes up and requests it.
      Unicast traffic may also be delayed to improve power save,
      efficiency and increase probability of aggregation.
  o  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.

These kind-of feel like sub-bullets of the previous point.

Section 3.2.1

  o  ARP
  o  DHCP
  o  mDNS [RFC6762]
  o  uPnP [RFC6970]

  After initial configuration, ARP (described in more detail later) and
  DHCP occur much less commonly, but service discovery can occur at any
  time.  Some widely-deployed service discovery protocols (e.g., for
  finding a printer) utilize mDNS (i.e., multicast).  It's often the

nit: doesn't uPnP also fall under the "service discovery protocol"
mantle?  It's a little weird rhetorically to only mention the one but
not the other, and leaves the uninformed reader wondering what the story
is about uPnP.

  first service that operators drop.  Even if multicast snooping is

nit: rhetorically, this is missing some causality for "first of what".

Section 3.2.3

On the whole this section is hard for me to follow.  I make a couple
specific points, but a broader rewrite may be in order.

  Multicast Listener Discovery (MLD) [RFC4541] is used to identify
  members of a multicast group that are connected to the ports of a
  switch.  Forwarding multicast frames into a Wi-Fi-enabled area can
  use such switch support for hardware forwarding state information.

Er, what switch support -- where did we previously discuss this?

  However, since IPv6 makes heavy use of multicast, each STA with an
  IPv6 address will require state on the switch for several and
  possibly many multicast solicited-node addresses.  Multicast

Am I supposed to know what a "solicited-node address" is based on the
references already provided?

Section 4.1

Is there an actual specification for Proxy ARP that can be referenced in
addition to the powerpoint deck?  I note that the toplevel Section 4
describes this content as "has been specified", which would seem to
exclude speculative proposals.

  The AP knows the MAC address and IP address for all associated STAs.
  In this way, the AP acts as the central "manager" for all the 802.11
  STAs in its basic service set (BSS).  Proxy ARP is easy to implement
  at the AP, and offers the following advantages:

Does it make sense to lead in this passage with "In Proxy Arp,"?

Section 4.3

I'm not sure how accessible this content will be to readers that do not
already have some background knowledge on wifi operation -- there are
some logical connections between sentences that are left fairly
implicit.

Section 5.1

        Some routers (often those based on Linux) implement a "negative
        ARP cache" daemon.  Simply put, if the router does not see a
        reply to an ARP it can be configured to cache this information
        for some interval.  Unfortunately, the core routers in use
        often do not support this.  When a host connects to a network
        and gets an IP address, it will ARP for its default gateway
        (the router).  The router will update its cache with the IP to
        host MAC mapping learned from the request (passive ARP
        learning).

nit: the transition between first three and last two sentences seems a
bit lacking.

  Firewall unused space

        The distribution of users on wireless networks / subnets
        changes from one IETF meeting to the next (e.g SSIDs are
        renamed, some SSIDs lose favor, etc).  This makes utilization
        for particular SSIDs difficult to predict ahead of time, but
        usage can be monitored as attendees use the different networks.

nit: I don't think the reference to the IETF meeting network adds any
value here; the operational practice can be equally well described
without such reference.

  NAT

        The broadcasts are overwhelmingly being caused by outside
        scanning / backscatter traffic.  To NAT the entire (or a large
        portion) of the attendee networks would eliminate NAT
        translation entries for unused addresses, and so the router
        would never ARP for them.  However, there are many reasons to
        avoid using NAT in such a blanket fashion.

"attendee networks" seems to be another (implicit) reference to IETF
meeting networks; I suggest rewording.

  Stateful firewalls

        Another obvious solution would be to put a stateful firewall
        between the wireless network and the Internet.  This firewall
        would block incoming traffic not associated with an outbound
        request.  But this conflicts with the need and desire of the
        IETF and other organizations to have the network as open as
        possible and to honor the end-to-end principle.  An attendee on
        the meeting network should be an Internet host, and should be
        able to receive unsolicited requests.  Unfortunately, keeping

Again, a focus on the (IETF) meeting network that is not justified by
the scope presented in the Abstract and Introduction.

Section 5.2

Is there more that could be said about how this constraining is to be
done?  Are there well-known techniques to "segment off" (pun intended)
small areas of service-discovery traffic within a larger multicast
domain, that fall short of just blocking mDNS entirely?

(Also, why is this section indented at the level of the sub-topics of
the previous section, instead of normal section-level indentation?)

Section 7

  Future protocol documents utilizing multicast signaling should be
  carefully scrutinized if the protocol is likely to be used over
  wireless media.

It's not entirely clear that this advice is going to make it to the
authors of such future protocol documents, given the current intended
status of this document.  I might consider rephrasing in terms of the
potential consequences if such future protocols do not take into account
the considerations for wireless media, though that would of course make
the statement fit less well into a section entitled "Recommendations".

  Proxy methods should be encouraged to conserve network bandwidth and
  power utilization by low-power devices.  The device can use a unicast

nit: I think this should be something like "The use of proxy methods
should be encouraged"; right now the text has to be parsed as having
"proxy methods" as the subject that is getting encouraged to conserve
resources.  Alternately, just add a comma.

  Multicast signaling for wireless devices should be done in a way
  compatible with low duty-cycle operation.

Is there any further guidance to give on how this is to be done?  Do any
previous sections of this document offer specific advice that is
relevant to this point?

Section 8

  The IETF should determine guidelines by which it may be decided that
  multicast packets are to be sent wired.  For example, 802.1ak works
  on ethernet and Wi-Fi.  802.1ak has been pulled into 802.1Q as of
  802.1Q-2011.  If a generic solution is not found, guidelines for
  multicast over Wi-Fi should be established.

I don't understand how these sentences are related to each other.  The
first one seems to be suggesting that the IETF should be telling
protocols that use IP multicast that those protocols need to
differentiate their behavior based on the physical layer in use, which
seems (AFAIK) antithetical to the idea of the Internet Protocol.  The
second and third sentences seem to be making statements about particular
IEEE technologies, I guess saying that they are available for both wired
and wireless use, but doesn't tell me much about what features the IETF
might be using from those technologies or why I should care about them.
The last sentence talks of a "generic solution", but I don't know what
problem it's supposed to be a solution for and how it relates to the
previously mentioned technologies.

  There is no need to support 2^24 groups to get solicited node
  multicast working: it is possible to simply select a number of
  trailing bits that make sense for a given network size to limit the
  number of unwanted deliveries to reasonable levels.  IEEE 802.1,

What are "trailing bits"?

  issues.  In reality, Wi-Fi provides a broadcast service, not a
  multicast service.  On the physical medium, all frames are broadcast
  except in very unusual cases in which special beamforming
  transmitters are used.  Unicast offers the advantage of being much

This observation seems like it would be very useful to have much earlier
in the document.

Section 9

It might be worth mentioning the common issue with security protocols
for multicast or group communications where there's a tradeoff between
(expensive) per-message asymmetric cryptography and (cheap) symmetric
cryptography where the shared group key allows any group member to
impersonate the expected sender.

We also discuss several mechanisms for improving efficiency that in
effect involve a proxy acting on behalf of wireless stations (whether in
the AP or a separate entity); such proxy methods in general have
security considerations that require the proxy to be trusted to not
misbehave.

Similarly, when using mechanisms that convert multicast traffic to
unicast traffic for traversing radio links, the AP (or other entity) is
forced to explicitly track which subscribers care about what multicast
traffic.  This is generally a reasonable tradeoff, but does result in
another entity that is tracking what entities subscribe to which
multicast traffic.  While such information is already (by necessity)
tracked elsewhere, this does present an expansion of the attack surface
for that potentially privacy-sensitive information.

There are probably some privacy considerations worth mentioning for the
"backbone router" model discussed in Section 4.2.

  Multicast is made more secure in a variety of ways.  [RFC4601], for

Would it be accurate to rephrase this more like "There are a variety of
security mechanisms defined for multicast control- and data-plane
traffic"?  The current formulation feels confusing to me on two axes:
whether it describes current or future specifications, and the nature of
security improvements provided.  (Actually, are the listed mechanisms
only really applicable to control-plane traffic but not data-plane?)

[Ballot discuss]
** Section 9.  Section 7 appears to recommend using an ARP sponge per Section 5.1.  Please provide some general caution about ARP poisoning/false advertising that could undermine (DoS) this approach (that is being deployed to save battery power).

[Ballot comment]
I support Alissa’s DISCUSS.  My related comments on Section 5.1 are:

-- Section 5.1  Firewall unused space.  Per “… The distribution of users on wireless networks/subnets changes from one IETF meeting to the next …”, this text seems unnecessary and it strikes me as odd to base guidance on a single network.

-- Section 5.1. NAT.  Per “To NAT the entire … attendee networks”, what is the “attendee network” in this context?

-- Section 5.1.  Stateful firewalls.  Per “But this conflicts with the need and desire of the IETF and other organizations to have the network as open as possible and to honor the end-to-end principle.  An attendee on the meeting network should be an Internet host …”, this text appears to be written about the IETF meeting network. Honoring the end-to-end principle and network nodes between Internet hosts is not universal architecture for all organizations.  Recommend rewording or removing these two sentences.

** Section 5. This section states that it is describing optimizations to address the issue discussion in Section 3.  It would be clearer if this section notes which items from Section 3 are addressed.

** Section 5.1. Per “… and sometimes the daemons just seem to stop” seems to be an implementation issue, not a reflection on the technique or associated architecture.  If this is the case, I recommend removing this text.

** Section 7. This section would be clearer if the explicitly activities in Section 4 and 5 being recommended were referenced.

** Section 9.  The first paragraph makes references to RFC4601 and RFC5796 which is helpful -- thanks.  I wasn’t sure what this meant in the context of this document which discusses multicast over wireless. This guidance doesn’t appear to be wireless specific.  Assuming you meant that “all the usual multicast security guidance applies whether you are using wireless or not”, please include clarifying text of the rough form (edit as required):

OLD: Multicast is made more secure in a variety of ways.

NEW: Multicast deployed on wired or wireless networks as discussed in this document can be made more secure in a variety of ways.

** Editorial Nits:
-- Section 3.1.2.  Typo. s/techiques/techniques/

-- Section 3.2.1.  Typo.  s/utlize/utilize/

-- Section 4.7. s/AP has do the/AP has to do the/

-- Section 5.1. Typo. s/listen for ARP requests/listens for ARP requests/

-- Section 5.1. Typo. s/to an machine/to a machine/

-- IdNits reports:
  -- Obsolete informational reference (is this intentional?): RFC 2461
    (Obsoleted by RFC 4861)
  -- Obsolete informational reference (is this intentional?): RFC 4601
    (Obsoleted by RFC 7761)

[Ballot comment]
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...).

[Ballot comment]
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.

[Ballot discuss]
Section 8: Are there plans for the IETF community to develop the guidelines mentioned? I'm wary of publishing an RFC that says the IETF should do something if there are in fact no plans for the IETF to do the thing. RFCs are not necessarily good motivators.

Overall this is an interesting document, but it seems to be written in an overly casual way and assumes readers have a lot of context that is not included in the document itself. The Gen-ART review pointed out a number of bits of text that left this impression. It was posted in October and never responded to. I've picked out some bits of the review and added a few more of my own -- collectively addressing these would get the document into publishable shape for a wider audience I think.

General:  (1) On first use, please add citations for all the protocols mentioned in the document, as well as a few words to describe what each protocol does. For IETF readers, this will help them understand the implications of various 802 specifications without having to go look them up right away. (2) The IETF meeting network may be interesting as an example to contemplate, but to make this document broadly valuable it would be better to generalize the problem descriptions than to focus on the IETF meeting network.

Section 3.1.4 seems a little thin to this non-expert. It is certainly true that "every station has to be configured to wake up to receive the multicast", but it seems like only a poorly designed protocol would create the situation where "the received packet may ultimately be discarded" on any kind of regular basis. If there are a class of packets that the receiver will ultimately discard, that sounds like they should be on a separate multicast address, or the sender should be determining if the packet will be discarded before sending it. Perhaps what this section is driving at is that multicast protocols are often designed without taking power-saving considerations into account, but then *that's* what this section should probably talk about. As it is, it sounds like the old joke about saying to the doctor, "My arm hurts when I do this" and the doctor replying, "The stop doing that".

In section 3.2.1, the last paragraph is missing a bunch of information:
"It's often the first service that operators drop": What is "it"?
"Multicast snooping" is not defined.
In what scenario are devices "registering"?

Section 5.1: "...and sometimes the daemons just seem to stop, requiring a restart of the daemon and causing disruption." What a strange thing to say. Does this simply mean "and the current implementations are buggy"?

Also section 5.1: "The distribution of users on wireless networks / subnets changes from one IETF meeting to the next". This document doesn't seem to be about the IETF meeting network. This sentence seems inappropriately specific. The "NAT" and "Stateful firewalls" sections are also overly specific to the IETF meeting network. Generalizing would help.

Section 8: The first paragraph has too little useful comment. There is no reference for 802.1ak, the reference to 802.1Q is inline instead of in the references section, and the content of neither of these standards is explained in this document. The paragraph doesn't really lay out what the topic of discussion is, at least for someone like myself who is not versed in the topic.

Note added 'Note that this document is in the OPS area but as Warren Kumari is an author, Éric Vyncke (INT AD but also having worked on a similar document years ago) is the responsible AD.'

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mboned-ieee802-mcast-problems-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-10-14):

From: The IESG
To: IETF-Announce
CC: jholland@akamai.com, mboned-chairs@ietf.org, draft-ietf-mboned-ieee802-mcast-problems@ietf.org, mboned@ietf.org, evyncke@cisco.com, Jake Holland
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multicast Considerations over IEEE 802 Wireless Media) to Informational RFC


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document: - 'Multicast Considerations over IEEE 802
Wireless Media'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Well-known issues with multicast have prevented the deployment of
  multicast in 802.11 and other local-area wireless environments.  This
  document offers guidance on known limitations and problems with
  wireless Layer-2 multicast.  Also described are certain multicast
  enhancement features that have been specified by the IETF and by IEEE
  802 for wireless media, as well as some operational choices that can
  be taken to improve the performance of the network.  Finally, some
  recommendations are provided about the usage and combination of these
  features and operational choices.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/ballot/


No IPR declarations have been submitted directly on this I-D.

Dear authors,

I have reviewed this useful document and I have some comments/suggestions that I would love to see addressed before issuing the IETF-wide Last Call.

1. Abstract: it is unclear whether it is layer-2 or layer-3 multicast or both.
2. Section 3.2.2: why not using “mDNS” as in section 3.2.1 rather than “Service Discovery”. We could also argue that DAD & address resolution are part of NDP. Adding a reference to NDP would also be welcome.
3. Section 3.2.3: please note that some switch vendors do not support MLD for link-scope multicast because this would be too many states...
4. Section 3.2.4 is only about IPv4 ARP but the same exists for IPv6, isn’t? And should be documented.
5. Section 4: I would prefer to order the sub-section from the ones that are specified and implemented to the ones that are research only
6. Section 4.6.3 uses the uppercase “RECOMMENDED” which is not applicable for an informational document.
7. Section 4.6.4 should the AMT solution be scoped to ‘non-local multicast’ ?
8. Section 5.1 appears to focus only on IPv4, the equivalent for IPv6 is pretty required
9. Section 5.1. will attract a DISCUSS during IESG evaluation, I have hard time to read NAT as a mitigation technique... this part should rather be a ‘block inbound connection’ (and then say often collocated with NAT).
10. Section 7 “This section will provide some recommendations” setting high expectations but then only 3 paragraphs (that are correct but I would like to see more) esp as “recommendations” appears in the abstract

I would also love to see a section for protocol designers as most of the optimizations described are really around Wi-Fi implementations (as written above about section 7).

Also missing in the lack of reliability is a description of the DAD issue, i.e., relying on negative signaling == no reply means it is OK. Of course, this does not fly over un-realiable network.

It also appears that this document has sections authored by different authors and therefore suffers somehow from an inconsistent way of writing or even some repetition (such as section 4.5 that repeats what NDP does). It is quite common for such documents and it would be nice if all authors re-read the whole document to improve this aspects. It does not change the content value but the readability of it. And as a side note, a couple of documents of mine also suffer from the same issue :-(

Also, some nits:
1. Section 3.1.2: “Gb/s” should be the usual “Gbps”
2. You may also refer to the more specific draft-thubert-6man-ipv6-over-wireless ?

Again, this is a really important and useful document that will benefit from a revised I-D

Regards

-éric

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Informational

Why is this the proper type of RFC?

  Matches the description in RFC 2026, section 4.2.  It's explaining
  a set of issues and providing pointers to mitigations.

Is this type of RFC indicated in the title
page header?

  Yes.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document details known operational issues with IP multicast
  use on 802.11 (Wi-Fi) networks, and provides guidance on existing
  deployment strategies and mitigations.

Working Group Summary:

  There was WG consensus to publish this doc.

  Lenny (as chair) wanted more WG feedback explicitly supporting the
  advancement of this doc after WGLC, but noted that the doc has
  received extensive feedback over the last few years.
  https://mailarchive.ietf.org/arch/msg/mboned/ts4W0_viXV-7OX0LKjAKjn_KGa0

  Two independent drafts addressing the same problem space were
  originally submitted by different sets of authors:
    draft-mcbride-mboned-wifi-mcast-problem-statement
    draft-perkins-intarea-multicast-ieee802

  WG consensus during these early stages was to merge the drafts,
  resulting in this doc.

  The doc had consistently low controversy and high support.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  Joel Jaeggli made a significant early review of both docs that
  resulted in many changes:
  https://mailarchive.ietf.org/arch/msg/mboned/04NLYfKGX86YzbpHt6FPKQf_1Xs

  Jake Holland and Bill Atwood each did reasonably thorough reviews
  on later versions of the doc, after merging.

  Several others provided a number of mostly-minor technical comments
  that were incorporated (list in Acknowledgements section).

Personnel:

  Document shepherd: Jake Holland
  Responsible AD: Erik Vyncke

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  Document was reviewed on-list by doc shepherd, comments were
  addressed.  Ready for publication, with a note that there are
  informative references to I-Ds.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  This doc covers IEEE technology as it relates to IP, and thus relies
  on expertise from IEEE experts, as well as multicast operational
  experience.

  Some of the authors are participants in IEEE and a key goal of this
  doc is sharing their operational experience and technical expertise.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The doc has several unusual references that probably should be
  checked with the RFC editor for best practices with unusual
  references.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  Yes.

  Dorothy: (mboned 21 May 2019 22:37 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/-EwzEsem0mDjX_qCmXWHWNgxAck
  Warren: (mboned 22 April 2019 19:01 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/o9kB-yINVqSn8SlYJlhS_kiEvcQ
  Mike: (mboned 24 April 2019 22:29 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/L89ld2Q5yy8YA-O3d-ZWCWpp9JI
  Charlie: (mboned 22 April 2019 19:22 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/ywuze7gfUdp-igRhcHM5OFQsagU
  Juan: sent an email off-list on 2019-07-29 stating:
    "I'm not aware of any IPR related to
    draft-ietf-mboned-ieee802-mcast-problems."
  The email was sent to Jake Holland, Charlie Perkins, and
    draft-ietf-mboned-ieee802-mcast-problems@ietf.org

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  Reasonably solid.  All wg members who could be convinced to read
  it seem to think it's a good idea, and seem to understand and
  agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Several nits found during reviews.  A few outstanding that should
  be fixed in the -08 draft, but are probably non-blocking:
  https://mailarchive.ietf.org/arch/msg/mboned/1Jl64Yv5g7KTpdbKzd6DMtdqeAw

  One more:
  - The acknowledgements section is not formatted as a complete sentence.
 

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  (n/a? I don't think there were any such requirements--not sure how
  to check exhaustively...)

(13) Have all references within this document been identified as either
normative or informative?

  Yes.  (All references are identified as informative.)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any existing
RFCs?

  No.

Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

  (n/a)

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  Full contents:
  "This document does not request any IANA actions."

  This is consistent with the body of the document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  (n/a)

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  (n/a)

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Informational

Why is this the proper type of RFC?

  Matches the description in RFC 2026, section 4.2.  It's explaining
  a set of issues and providing pointers to mitigations.

Is this type of RFC indicated in the title
page header?

  Yes.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document details known operational issues with IP multicast
  use on 802.11 (Wi-Fi) networks, and provides guidance on existing
  deployment strategies and mitigations.

Working Group Summary:

  There was WG consensus to publish this doc.

  Lenny (as chair) wanted more WG feedback explicitly supporting the
  advancement of this doc after WGLC, but noted that the doc has
  received extensive feedback over the last few years.
  https://mailarchive.ietf.org/arch/msg/mboned/ts4W0_viXV-7OX0LKjAKjn_KGa0

  Two independent drafts addressing the same problem space were
  originally submitted by different sets of authors:
    draft-mcbride-mboned-wifi-mcast-problem-statement
    draft-perkins-intarea-multicast-ieee802

  WG consensus during these early stages was to merge the drafts,
  resulting in this doc.

  The doc had consistently low controversy and high support.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  Joel Jaeggli made a significant early review of both docs that
  resulted in many changes:
  https://mailarchive.ietf.org/arch/msg/mboned/04NLYfKGX86YzbpHt6FPKQf_1Xs

  Jake Holland and Bill Atwood each did reasonably thorough reviews
  on later versions of the doc, after merging.

  Several others provided a number of mostly-minor technical comments
  that were incorporated (list in Acknowledgements section).

Personnel:

  Document shepherd: Jake Holland
  Responsible AD: Erik Vyncke

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  Document was reviewed on-list by doc shepherd, comments were
  addressed.  Ready for publication, with a note that there are
  informative references to I-Ds.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  This doc covers IEEE technology as it relates to IP, and thus relies
  on expertise from IEEE experts, as well as multicast operational
  experience.

  Some of the authors are participants in IEEE and a key goal of this
  doc is sharing their operational experience and technical expertise.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The doc has several unusual references that probably should be
  checked with the RFC editor for best practices with unusual
  references.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  Yes.

  Dorothy: (mboned 21 May 2019 22:37 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/-EwzEsem0mDjX_qCmXWHWNgxAck
  Warren: (mboned 22 April 2019 19:01 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/o9kB-yINVqSn8SlYJlhS_kiEvcQ
  Mike: (mboned 24 April 2019 22:29 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/L89ld2Q5yy8YA-O3d-ZWCWpp9JI
  Charlie: (mboned 22 April 2019 19:22 UTC)
  -https://mailarchive.ietf.org/arch/msg/mboned/ywuze7gfUdp-igRhcHM5OFQsagU
  Juan: sent an email off-list on 2019-07-29 stating:
    "I'm not aware of any IPR related to
    draft-ietf-mboned-ieee802-mcast-problems."
  The email was sent to Jake Holland, Charlie Perkins, and
    draft-ietf-mboned-ieee802-mcast-problems@ietf.org

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  Reasonably solid.  All wg members who could be convinced to read
  it seem to think it's a good idea, and seem to understand and
  agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Several nits found during reviews.  A few outstanding that should
  be fixed in the -08 draft, but are probably non-blocking:
  https://mailarchive.ietf.org/arch/msg/mboned/1Jl64Yv5g7KTpdbKzd6DMtdqeAw

  One more:
  - The acknowledgements section is not formatted as a complete sentence.
 

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  (n/a? I don't think there were any such requirements--not sure how
  to check exhaustively...)

(13) Have all references within this document been identified as either
normative or informative?

  Yes.  (All references are identified as informative.)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any existing
RFCs?

  No.

Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

  (n/a)

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  Full contents:
  "This document does not request any IANA actions."

  This is consistent with the body of the document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  (n/a)

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  (n/a)