Subject: [MBONED] Suresh Krishnan's No Objection on draft-ietf-mboned-ieee802-mcast-problems-11: (with COMMENT)

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Wed, 08 Jan 2020 19:38:08 -0800

Suresh Krishnan has entered the following ballot position for
draft-ietf-mboned-ieee802-mcast-problems-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/

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