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.

From my perspective as a member of the transport area review team, this document is On The Right Track, a form of "Has Issues".

# Issues

## Duplication

Quoting RFC 6550:

> For a multicast packet sourced from inside the DODAG, the packet is
> passed to the preferred parents, and if that fails, then to the
> alternates in the DODAG.  The packet is also copied to all the
> registered children, except for the one that passed the packet.
> Finally, if there is a listener in the external infrastructure, then
> the DODAG root has to further propagate the packet into the external
> infrastructure.

This algorithm (for storing mode only) seems to admit the duplication of packets (and consequent need to figure out how to de-dup) in a DAG via a node sending to its parent and the non-source children, and then from that parent to some of the same children via a different path. While I surmise that this has been beaten to death in the working group, I am surprised to see no mention of packet duplication considerations in this document. If this is adequately covered elsewhere in the ecosystem, a reference would be helpful. This is a core problem with multicast in domains with multiple paths.

## MLD vs ND

From the intro:

> In the case of a constrained node that already implements [RFC8505] for
> unicast reachability, it makes sense to extend to that support to subscribe the
> multicast addresses they listen to.

Does it? Or would it make sense to use the MLD wire image with unicast in a manner analogous to how ND has been adapted to unicast for low-power environments? I'm torn between two principles of engineering: least surprise and minimizing effort. There are good arguments for each.

## Anycast

Originally, anycast was merely an artifact of undefined behaviors in global routing technologies: since networks had no way of enforcing global address uniqueness and had to do *something* with a packet in the presence of two viable next hops (forward to one, forward to both, or drop/reject), some local choice needed to be made. It turned out to be useful: see RFC 1546 and RFC 4786.

That said, there exists a not-completely-resolved tension between anycast routing and address uniqueness enforced via mechanisms such as DAD. This document increases this tension further, within the class of low-power networks, by explicitly supporting multiple devices sharing an IP address on what appears to a 6LR-oblivious node to be a single link.

One thing I'd like articulated is the set of identified use cases for supporting this kind of addressing within low-power networks that are presumably geographically highly-constrained. Is this a solution in search of a problem?

I am not taking a position on whether or not anycast support is advisable, primarily because this is not my area of expertise and so I do not understand all the pros/cons involved, but I would like ADs of both TSV/WIT and INT to take a close look at this.

## Updating a lot of documents

I agree with some other comments I've read that this set of updates has the potential to create confusion in the ecosystem. It may be worth doing a -bis pass to the entire ecosystem at some point in the not-too-distant future.

# Nits and other minor comments

* Please add DAO ("destination address object") to the glossary. This is especially important because "D" in other similar abbreviations means "duplicate".

* The paragraph in 6550 describing storing vs. non-storing routing modes would provide useful context to readers not already steeped in the low-power/lossy ecosystem. While obviously an implementer needs to have internalized these foundational documents in their entirety, with care the documents can be made more easily consumable by others not engaged in implementation.