Skip to main content

Last Call Review of draft-ietf-6lo-multicast-registration-16

Request Review of draft-ietf-6lo-multicast-registration
Requested revision No specific revision (document currently at 19)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-03-05
Requested 2024-02-20
Authors Pascal Thubert
I-D last updated 2024-03-04
Completed reviews Intdir Telechat review of -18 by Dirk Von Hugo (diff)
Secdir Telechat review of -18 by Scott G. Kelly (diff)
Secdir Last Call review of -16 by Scott G. Kelly (diff)
Genart Last Call review of -16 by Dan Romascanu (diff)
Tsvart Last Call review of -16 by Kyle Rose (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-6lo-multicast-registration by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 16 (document currently at 19)
Result Ready w/issues
Completed 2024-03-04
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-6lo-multicast-registration-16
Reviewer: Dan Romascanu
Review Date: 2024-03-04
IETF LC End Date: 2024-03-05
IESG Telechat date: Not scheduled for a telechat


This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (RFC
4861, RFC 8505) to enable a listener to subscribe to an IPv6 anycast or
multicast address; the document updates RPL (RFC6550, RFC 6553) to add a new
Non-Storing Multicast Mode and a new support for anycast addresses in Storing
and Non-Storing Modes. This document extends RFC 9010 to enable the 6LR to
inject the anycast and multicast addresses in RPL.It also extends RFC 7400.

I am not an expert in this area. It took me quite an amount of time to deal in
the referenced, updated, extended and leveraged documents and I am sure I did
not grasp all the details. The specification is well written and solid, but I
have a major concern because of the large number of other specifications that
seem to be impacted. I would like to make sure that this complexity was taken
into account.

Major issues:

1. This specification updates 5 other RFCs, extends 2 RFCs and leverages
another 2 RFCs.This is quite unusual, and the updates are quite extensive. I am
concerned that for future implementers and operators, following the
specifications will also become difficult. Would not revising all or part of
the RFCs be a better way that would ease the implementations and deployments?

2. The deployment and backwards compatibility sections are quite good, but is
there a recommended strategy for updating existing deployments in the field?

Minor issues:

Nits/editorial comments: