Last Call Review of draft-ietf-mboned-ieee802-mcast-problems-09
review-ietf-mboned-ieee802-mcast-problems-09-intdir-lc-jinmei-2019-10-09-00

Request Review of draft-ietf-mboned-ieee802-mcast-problems
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Internet Area Directorate (intdir)
Deadline 2019-10-14
Requested 2019-10-02
Requested by Éric Vyncke
Authors Charles Perkins, Mike McBride, Dorothy Stanley, Warren Kumari, Juan-Carlos Zúñiga
Draft last updated 2019-10-09
Completed reviews Tsvart Last Call review of -09 by Gorry Fairhurst (diff)
Intdir Last Call review of -09 by Tatuya Jinmei (diff)
Rtgdir Last Call review of -09 by Tal Mizrahi (diff)
Secdir Last Call review of -09 by Kyle Rose (diff)
Genart Last Call review of -09 by Pete Resnick (diff)
Genart Telechat review of -11 by Pete Resnick
Opsdir Telechat review of -11 by Dan Romascanu
Tsvart Telechat review of -11 by Gorry Fairhurst
Comments
I would appreciate your review of this document. It is not too long and covers many areas of the IETF.

Thank you for considering this request

-éric (INT AD)
Assignment Reviewer Tatuya Jinmei
State Completed
Review review-ietf-mboned-ieee802-mcast-problems-09-intdir-lc-jinmei-2019-10-09
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/nZkNYVpWpUGvns90pi5V4phUWA8
Reviewed rev. 09 (document currently at 11)
Review result Ready with Nits
Review completed: 2019-10-09

Review
review-ietf-mboned-ieee802-mcast-problems-09-intdir-lc-jinmei-2019-10-09

oops, looks like I forgot to include the int-dir list.  forwarding it.

---------- Forwarded message ---------
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Wed, Oct 9, 2019 at 11:37 AM
Subject: int-dir last call review on
draft-ietf-mboned-ieee802-mcast-problems-09
To: <jholland@akamai.com>
Cc: <draft-ietf-mboned-ieee802-mcast-problems@ietf.org>, <
jholland@akamai.com>, <mboned-chairs@ietf.org>


I am an assigned INT directorate reviewer for
draft-ietf-mboned-ieee802-mcast-problems-09.txt. These comments were
written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these
comments just like they would treat comments from any other IETF
contributors and resolve them along with any other Last Call comments
that have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/.

Based on my review, the document is ready to go to IETF Last Call and
therefore can be forwarded to the IESG.

I first have to note that my knowledge and expertise on the underlying
technical areas (especially those defined in IEEE) are quite limited.
So my review is more or less superficial anyway.

Overall I found the document well written and useful.  I didn't find
any obvious technical issues on topics I'm relatively familiar with.
I only some have minor comments as follows:

- Section 3.2.2
   IPv6 makes extensive use of multicast, including the following:
...
   o  Route Discovery
   o  Decentralized Address Assignment
   o  Geographic routing

  What specifically does "Route Discovery" mean?  If it means the
  default router discovery using RA, I suspect it's better to call it
  that way since "Route Discovery" may also sound like a generic
  routing protocol.  On the other hand, if it means something
  different from default router discovery, it'd be better to provide a
  reference to avoid confusion like mine.

  Similarly, it would be nice to provide references for "Decentralized
  Address Assignment" and "Geographic routing".

- Section 3.2.2

   Neighbors may be considered lost if several consecutive Neighbor
   Discovery packets fail.

  It's not clear what this sentence refers to.  If it means neighbor
  unreachability detection as described in Section 7.3 of RFC4861, I'm
  not sure how it's relevant to this document since the unreachability
  detection (normally) doesn't rely on multicast.  Maybe we can simply
  remove this sentence if it means the unicast based neighbor
  unreachability detection.

- Section 3.2.4

   With Neighbor Discovery for IPv6 [RFC2461], nodes accomplish address

  s/[RFC2461]/[RFC4861]/.  And, since this is the only reference to
  the old RFC, it should now be removed from the References section.

--
JINMEI, Tatuya