Telechat Review of draft-ietf-roll-aodv-rpl-10
review-ietf-roll-aodv-rpl-10-iotdir-telechat-van-der-stok-2021-04-15-00
| Request | Review of | draft-ietf-roll-aodv-rpl |
|---|---|---|
| Requested revision | No specific revision (document currently at 18) | |
| Type | Telechat Review | |
| Team | Internet of Things Directorate (iotdir) | |
| Deadline | 2021-04-20 | |
| Requested | 2021-04-08 | |
| Requested by | Éric Vyncke | |
| Authors | Charles E. Perkins , S.V.R Anand , Satish Anamalamudi , Bing (Remy) Liu | |
| I-D last updated | 2021-04-15 | |
| Completed reviews |
Secdir Last Call review of -09
by Tero Kivinen
(diff)
Genart Last Call review of -10 by Meral Shirazipour (diff) Secdir Telechat review of -10 by Tero Kivinen (diff) Iotdir Telechat review of -10 by Peter Van der Stok (diff) Rtgdir Last Call review of -16 by Tony Przygienda (diff) |
|
| Comments |
As ROLL is really targeting constrained networks, please have a IoT review of this document before Tuesday 20th of April. Thank you -éric |
|
| Assignment | Reviewer | Peter Van der Stok |
| State | Completed | |
| Request | Telechat review on draft-ietf-roll-aodv-rpl by Internet of Things Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/iot-directorate/f2GUlTDX4ppY1GKjQFqS8930ZYI | |
| Reviewed revision | 10 (document currently at 18) | |
| Result | Ready w/nits | |
| Completed | 2021-04-15 |
review-ietf-roll-aodv-rpl-10-iotdir-telechat-van-der-stok-2021-04-15-00
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?