This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This document describes a mechanism for efficient neighbor discovery across links sharing a common IPv6 prefix, i.e., a multi-link subnet. I see no specifically transport-related issues in this draft, but I note a few nits as well as unaddressed issues raised by RFC 4903. Potential issues: The draft addresses ND, DAD, and to some extent link-scoped multicast and broadcast (sections 2.3 and 2.4 of 4903), but does not address either the IP Model (section 2.1) or hop limit issue (2.2). For the first, does the presumption that a multi-link subnet exists as a recognized and supportable network configuration require update of RFC 4291, which AFAICT is still authoritative for the statement that: "Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link." For the second, since I'm assuming something called a "router" will in fact decrement the hop limit when forwarding a packet (I couldn't find the answer in a brief perusal of the references that seemed relevant), for completeness it might be helpful to mention something about how multicast traffic e.g. with hop limit 1 will not successfully transit to hosts in the same subnet but on a different link. In general, making clear that the issues raised in 4903 are systematically addressed with respect to the unique requirements of 6lo traffic would be useful to the reader. Nit: This text is confusing: Either respond using NA messages as a proxy or bridge as a unicast frame the IPv6 ND messages (multicast DAD and Address Lookup, and unicast NUD) received for the Registered Address over the Backbone. In particular, I'm struggling with what the second option here is. Is it that a 6BBR could bridge incoming ND messages to other links? Is it an option in lieu of the first, or are NA messages always to be proxied and all other messages to be bridged? Nit: Please use a single form to specify a multi-link subnet: I see "MultiLink" and "Multi-Link" used in different places.