Last Call Review of draft-ietf-clue-protocol-17
review-ietf-clue-protocol-17-genart-lc-dupont-2018-10-18-00
| Request | Review of | draft-ietf-clue-protocol |
|---|---|---|
| Requested rev. | no specific revision (document currently at 19) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2018-10-17 | |
| Requested | 2018-10-03 | |
| Authors | Roberta Presta, Simon Romano | |
| Draft last updated | 2018-10-18 | |
| Completed reviews |
Genart Last Call review of -17 by Francis Dupont
(diff)
Secdir Last Call review of -17 by Aanchal Malhotra (diff) Opsdir Last Call review of -17 by Zitao Wang (diff) |
|
| Assignment | Reviewer | Francis Dupont |
| State | Completed | |
| Review | review-ietf-clue-protocol-17-genart-lc-dupont-2018-10-18 | |
| Reviewed rev. | 17 (document currently at 19) | |
| Review result | Ready | |
| Review completed: | 2018-10-18 |
Review
review-ietf-clue-protocol-17-genart-lc-dupont-2018-10-18
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-clue-protocol-17.txt Reviewer: Francis Dupont Review Date: 20181017 IETF LC End Date: 20181017 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I have a problem with the CLUE abbrev itself (which BTW is not in the RFC Editor abbrev list https://www.rfc-editor.org/materials/abbrev.expansion.txt): in theory the abbrev should be introduced at its first use in the Abstract and in the body (so 1 introduction) but this seems to be overkilling and not really solving the issue so I have a better proposal: ask the RFC Editor if it is not possible to add the CLUE abbrev in the list as a well known one. - Abstract page 1: you use SCTP over DTLS so a transport over another transport. At the first view it looks strange but in fact it should be the simplest solution to add security to SCTP so I have no concern about this. - 4 page 5 twice: version numbers are qualified as "single digit" which does not match the syntax 5 figure 1 page 8 nor examples: please remove these. - 5 page 8: the version number syntax. BTW it allows a minor version to begin by a 0 followed by other digits which perhaps is not what you want. - 5 page 8: same comment about examples: a priori 1.01 is legal and it is not clear if it is the same than 1.1 ? - 5 page 8 (before the previous one): procotol -> protocol - 5.1 page 11: IMHO in "<supportedVersion> is provided ..." it shoild be <supportedVersions>. - 5.4 page 13: I noted you use the UK spelling for the type name (Acknowledgement vs. Acknowledgment). - 5.7 page 17 figure 9 and 12.4.2 page 65: Please remove the final dot in " Low-level request error." - 11 page 60: defence -> defense (UK vs US English) - 12.4.1 page 64: estabilsh -> establish - 12.4.2 page 65: Conficting -> Conflicting Regards Francis.Dupont@fdupont.fr