[Roll] draft-ietf-roll-dis-modifications-02 early Rtgdir review

[Rakesh Gandhi via Datatracker <[e-mail]>]

Document: draft-ietf-roll-dis-modifications
Title: RPL DIS Modifications and Applications
Reviewer: Rakesh Gandhi
Review result: Has Nits

Hi authors,

I have been selected as the Routing Directorate reviewer for this draft.
This review is intended to help the authors, working group, and Routing ADs
improve the document.

Document: draft-ietf-roll-dis-modifications-02
Reviewer: Rakesh Gandhi
Review Date: June 4, 2026
Intended Status: Standards Track
Disclaimer: I do not have expertise on this topic

Thanks for working on this; the motivation for making DIS-based solicitation
more selective in RPL networks makes sense to me.

My main feedback is about clarity rather than the direction of the work itself.

As I read the draft, it seems to do more than introduce optional refinements to
DIS behavior. In a few places, it also appears to refine or change behavior
currently specified in RFC 6550, and if this is correct, I think the document
would benefit from making that relationship a bit more apparent for both
reviewers and implementers.

Specifically:
* In RFC 6550 Section 6.2.3, DIS is described as carrying Pad1, PadN, and
Solicited Information, while draft Section 4 adds additional DIS usage,
including: - Section 4.1: Metric Container in DIS, - Section 4.2: Response
Spreading, - Section 4.3: DIO Option Request. * In RFC 6550 Section 8.3,
multicast DIS leads to Trickle-related DIO transmission behavior, whereas draft
Section 3 and draft Section 5 seem to allow N=1 to request an explicit one-shot
DIO without resetting Trickle. * Also in RFC 6550 Section 8.3, a DIO sent in
response to unicast DIS includes the DODAG Configuration option, while draft
Section 3, draft Section 4.3, and the summary in draft Section 5 appear to
allow more selective returned options when R=1.

I think Section 1.1 could perhaps more clearly preview that the document is
refining behavior specified in RFC 6550 Sections 6.2.1, 6.2.3, and 8.3.

A few possible clarifications that might help:
* In Section 5, since Table 2 is effectively the behavioural summary, this
might be a good place to explicitly note which rows are unchanged from RFC 6550
Section 8.3 and which rows are modified by this document. * A short
interoperability/backward-compatibility/operational considerations section
might also be helpful, especially for mixed deployments.

We may want to consider whether an "Updates: RFC 6550" relationship would be
appropriate, given the apparent effect on RFC 6550 Sections 6.2.1, 6.2.3, and
8.3.

Again, I think this is useful work. My main suggestion is simply to make the
changes to RFC 6550 more apparent in the document.

Thanks,
Rakesh

References
•       Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-roll-dis-modifications-02 •   
   RFC 6550: https://www.rfc-editor.org/rfc/rfc6550.html