Subject: [Last-Call] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10

From: Peter Van der Stok via Datatracker <[email-masked]>
Date: Thu, 15 Apr 2021 02:55:56 -0700

Reviewer: Peter Van der Stok
Review result: Ready with Nits

Review of draft-ietf-roll-aodv-rpl-10
Peter van der stok, 15 April 2021

In general, the document is well written. By looking regularly into RFC 6550, I
am rather sure that I could implement the protocol. The question remains how
this draft relates to RFC 6997. When the WG decides that this draft replaces
RFC 6997, then it would be good to copy some text from 6997 to this draft,
because RFC 6997 is more explicit about the use of RPL parameters as specified
in RFC 6550 and presents more explicit motivation.

Many thanks for this document

peter
_________________________________________________________
Some suggestions for the text follow here:
Page 14, lines 3 and 4;
OLD: ART Options and within
New: ART Options. Within
Page 14, line 9
distinguished -> generated
page 14 section 6.2.1
OLD: does not belong to the RREQ-Instance
NEW: has not joint the RREQ-Instance
Joining is used in Step 1, 2nd paragraph.
Question: what is the "best previous RREQ"?
Page 14, Step 1, 2nd paragraph
OLD: router's Rank would not exceed
NEW: router's Rank does not exceed
Page 15 end of Step 3;
Question: What is a "stale sequence number"?
Page 15, section 6.2.2
OLD:
If the OrigNode tries to reach multiple TargNodes in a single RREQ-Instance,
one of the TargNodes can be an intermediate router to the others, therefore it
MUST continue sending RREQ-DIO to reach other targets.

NEW:
If the OrigNode tries to reach multiple TargNodes in a single RREQ-Instance, it
MUST continue sending RREQ-DIO to reach other Targets because one of the
TargNodes can be an intermediate router to the others.

End Page 15
OLD: but have different
NEW: with different

OLD the intersection of these list
NEW the intersection all received lists

Page 16 line 8
OLD associated with the
NEW for a given

Page 17: the terms occupied RPLInstanceID, and second RPLInstancID are
difficult to parse. Maye be use received RPLInstanceID and shifted
RPLInstanceID? Further on you use original RPLInstanceID, is that a third one?

Question: what does "shifted into another integer" mean?
Question: who or what chooses the shift value, when is it set and into which
RREP-DIO field is the shifted value set?

Page 18 Step 2; Are multiple addresses possible in the ART option. I just
understood there is only one per RPLInstanceID (shifted or not).

Page 18 Step 3, As above
Stale sequence number?

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 15 Apr 2021 12:15:10 +0000

Thank you Peter for your review, I really appreciate it and will use it when balloting on the document.

Regards

-éric

-----Original Message-----
From: Iot-directorate <[email-masked]> on behalf of Peter Van der Stok via Datatracker <[email-masked]>
Reply-To: Peter Van der Stok <[email-masked]>
Date: Thursday, 15 April 2021 at 11:57
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Iot-directorate] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10

    peter

    NEW:

    End Page 15
    OLD: but have different
    NEW: with different

    Page 16 line 8
    OLD associated with the
    NEW for a given

    Page 18 Step 3, As above
    Stale sequence number?

    -- 
    Iot-directorate mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/iot-directorate

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 15 Apr 2021 18:57:21 +0000

On April 15, 2021 at 5:55:57 AM, Peter Van der Stok wrote:

Peter:

Hi!  I hope you're doing well!

> In general, the document is well written. By looking regularly into RFC 6550,
> I am rather sure that I could implement the protocol. The question remains
> how this draft relates to RFC 6997. When the WG decides that this draft
> replaces RFC 6997, then it would be good to copy some text from 6997 to this
> draft, because RFC 6997 is more explicit about the use of RPL parameters as
> specified in RFC 6550 and presents more explicit motivation.

As you know, the roll WG considered the question of replacing rfc6997
as part of my AD review [1].  At the time there didn't seem to be any
strong interest in doing so.  Do you think that has changed?

Thanks for the review!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 16 Apr 2021 08:48:04 +0200

Hi Alvaro,

Yes, I'm fine; I hope you are also in good health.

Since a year I am not following the undercurrents in the ROLL WG. I am 
unable to tell you what they think about replacing rfc6997 currently.
When I was chair, I was more concerned with the continuation of the 
document than eventual consequences for rfc6697.

However, I think that this is the right moment to reconsider the 
replacement question.
Having two aodv documents may be confusing for ROLL adopters.

BTW, I encouraged the creation and development of rfc6697 for the 
reasons mentioned in the document.
When replacement is considered, this motivation is needed in the new 
aodv draft.

Hope this explains a bit better my review remarks.

Greetings,

Peter
Alvaro Retana schreef op 2021-04-15 20:57:

> as part of my AD review [1 [1]].  At the time there didn't seem to be 
> any
> [1] 
> https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/

Links:
------
[1] 
https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/