[Int-dir] Fwd: int-dir last call review on draft-ietf-mboned-ieee802-mcast-problems-09

[神明達哉 <[e-mail]>]

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

---------- Forwarded message ---------
From: 神明達哉 <[e-mail]>
Date: Wed, Oct 9, 2019 at 11:37 AM
Subject: int-dir last call review on
draft-ietf-mboned-ieee802-mcast-problems-09
To: <[e-mail]>
Cc: <[e-mail]>, <
[e-mail]>, <[e-mail]>


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