Hello Dan
Reviewer: Dan Romascanu Review result: Ready with Issues 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 <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. 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 Summary: 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.
I'd say that being an author of the other specs helps in that regards. The impact is spreading as you say but it does not change the classical behavior of these specs.
It was actually a requirement from Wi-Sun to have that deep
intricacy so we avoid adding or changing too much code.The
alternate was to implement a separate protocol like IGMP and the
constrained devices and comms would not allow that.
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?
I guess we could have split the RFC but that approach had other
major disadvantages for the overall consistency of the solution.
And the amount of reviews at IESG. The best guarantee we have is
continuity of the design team that we effectively have here.
2. The deployment and backwards compatibility sections are quite good, but is there a recommended strategy for updating existing deployments in the field?
This specification introduces a new MoP (14.5. New RPL Mode of Operation) . This means that you cannot update a live network. You have to create a new instance with MoP 5 and migrate nodes to that instance by allowing them to join it. MoPs a re tradictional RPL since RFC 6550, meaning that the behavior is already known outside of this specification.
many thanks Dan!
Pascal
Minor issues: Nits/editorial comments:
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
