[Gen-art] review of draft-ietf-clue-data-model-schema-14.txt

Francis Dupont <Francis.Dupont@fdupont.fr> Mon, 30 May 2016 13:21 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 025B012D540; Mon, 30 May 2016 06:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wdGpcw88zDCU; Mon, 30 May 2016 06:21:26 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A5F12D18D; Mon, 30 May 2016 06:21:25 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u4UD9opN029703; Mon, 30 May 2016 15:09:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201605301309.u4UD9opN029703@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: gen-art@ietf.org
Date: Mon, 30 May 2016 15:09:50 +0200
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/FCcpZBR7gw6EJ9xiT2MDwfZSEzM>
Cc: draft-ietf-clue-data-model-schema.all@ietf.org
Subject: [Gen-art] review of draft-ietf-clue-data-model-schema-14.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2016 13:21:29 -0000

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


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).