Skip to main content

Last Call Review of draft-ietf-roll-useofrplinfo-25
review-ietf-roll-useofrplinfo-25-rtgdir-lc-rogge-2019-04-17-00

Request Review of draft-ietf-roll-useofrplinfo
Requested revision No specific revision (document currently at 44)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2019-04-11
Requested 2019-03-21
Requested by Alvaro Retana
Authors Ines Robles , Michael Richardson , Pascal Thubert
I-D last updated 2019-04-17
Completed reviews Rtgdir Last Call review of -25 by Henning Rogge (diff)
Secdir Last Call review of -25 by Daniel Migault (diff)
Tsvart Last Call review of -25 by Colin Perkins (diff)
Genart Last Call review of -25 by Russ Housley (diff)
Iotdir Telechat review of -40 by Mališa Vučinić (diff)
Iotdir Last Call review of -42 by Mališa Vučinić (diff)
Rtgdir Last Call review of -42 by Henning Rogge (diff)
Assignment Reviewer Henning Rogge
State Completed
Request Last Call review on draft-ietf-roll-useofrplinfo by Routing Area Directorate Assigned
Reviewed revision 25 (document currently at 44)
Result Has issues
Completed 2019-04-17
review-ietf-roll-useofrplinfo-25-rtgdir-lc-rogge-2019-04-17-00
Hi,

I was asked by the IETF to do a Routing-Directorate review of
draft-ietf-roll-useofrplinfo. Please note that I do NOT follow
the ROLL WG.

Overall I think the draft tries too hard to condense information
into one document. It often uses non-intuitive abbreviations (e.g.
"RPL-aware-Leaf" as "RaF" or "target" as "tgt") and I just don't
know if this is the common way to do it in ROLL or just an unlucky
accident.

A lot of tables are literally overloaded with information to the
point where the document generator splits apart words, making the
table unreadable (see table 4,6,7,8,11,21 among others).

Other table entries are just not easy to interpret. Table 7
(as an example) has the options "no, "must" and "yes" for a column
which raises the question what is the difference between "must"
and "yes".

I am not sure what advice to give for the draft, if this (as the
abstract states) is the analysis for the basis of header compression
design I am worried that the design decisions will be hard to understand.

Henning Rogge