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 rev. | no specific revision (document currently at 40) | |
| 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 | |
| Draft 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ć |
|
| Assignment | Reviewer | Henning Rogge |
| State | Completed | |
| Review | review-ietf-roll-useofrplinfo-25-rtgdir-lc-rogge-2019-04-17 | |
| Reviewed rev. | 25 (document currently at 40) | |
| Review result | Has Issues | |
| Review completed: | 2019-04-17 |
Review
review-ietf-roll-useofrplinfo-25-rtgdir-lc-rogge-2019-04-17
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