oops, looks like I forgot to include the int-dir list. forwarding it. ---------- Forwarded message --------- From: 神明達哉 Date: Wed, Oct 9, 2019 at 11:37 AM Subject: int-dir last call review on draft-ietf-mboned-ieee802-mcast-problems-09 To: Cc: , < jholland@akamai.com>, 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