Re: [Gen-art] Genart last call review of draft-ietf-6lo-multicast-registration-16

[Pascal Thubert <[e-mail]>]

Hello Dan

Le 04/03/2024 à 09:29, Dan Romascanu via Datatracker a écrit :
> 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. 
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-16#section-14.5>New 
RPL Mode of Operation 
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-16#name-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:
>
>