Last Call Review of draft-ietf-clue-protocol-17
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
Reviewer: Francis Dupont
Review Date: 20181017
IETF LC End Date: 20181017
IESG Telechat date: unknown
Major issues: None
Minor issues: None
I have a problem with the CLUE abbrev itself (which BTW is not in the
RFC Editor abbrev list
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
- 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
- 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
- 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