Last Call Review of draft-ietf-clue-data-model-schema-13
review-ietf-clue-data-model-schema-13-genart-lc-dupont-2016-05-23-00

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

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-clue-data-model-schema-14.txt
Reviewer: Francis Dupont
Review Date: 20160525
IETF LC End Date: 20160523
IESG Telechat date: 20160602

Summary: Ready with nits

Major issues: none

Minor issues: none

Nits/editorial comments:
 - I first had a concern about the CLUE abbrev (abbrevs which are not
  "well known" according to the RFC Editor's list requires expansion
   at their first use in the Abstract and in the body, i.e., likely
   the introduction) but in fact CLUE is not an abbrev but a nickname.
   I strongly suggest to this (i.e., it is not really an abbrev) in
   the introduction (1 page 4) with an explicit reference to the
   framework document where are details. BTW IMHO:
    * you can leave the CLUE name in the title and the abstract
    * this recommendation should apply to all CLUE documents
     (at the exception of the framework one of course)

 - ToC page 3 and 16.3 page 48: use " vs ' around application/clue_info+xml
  (for consistency)

 - 3 page 5: Scene.. -> Scene.

 - 3 page 5: E.g. -> E.g.,

 - 3 page 6: e.g. -> e.g.,

 - 4 page 7 (people): (Section 11.29). -> (Section 11.29)
  (for consistency)

 - 4 page 13 (multiple): sensitivyPattern* -> sensitivityPattern*

 - 11.16 page 28: highly-dinamic -> highly-dynamic

 - 11.27.3 page 39: simultanous -> simultaneous

 - 15 page 46: captures , capture -> captures, capture

 - 17 page 54 and 18 pages 61, 63 and 64 : Soundlevel -> SoundLevel

 - 30 page 70: AD -> Area Director

 - 31 pages 70 to 72: usually normative references are before informative
  references. I don't know if it is a strong requirement but if it is
  easy for you to swap 31.1 with 31.2 it will at least follow
  the "least astonishment" rule...

Note I didn't check the xml stuff itself (there are automatic tools
for this not-for-human task).

Regards

Francis.Dupont at fdupont.fr