Subject: [clue] AD review: draft-ietf-clue-data-model-schema-12

From: Alissa Cooper <[email-masked]>
Date: Tue, 23 Feb 2016 23:31:41 +0100

I have reviewed this document in preparation for IETF last call. I have some substantive comments and questions that need to be resolved before going to last call, along with some nits that should be resolved as well.

Substantive comments:

= General =

(1) The use of normative language appears inconsistent in the document. There are normative uses of MUST and also non-normative uses of “must,” “optional,” and “mandatory.” I would recommend a careful pass through to establish consistency.

(2) The definition of the simultaneous set type uses <mediaCaptureIDREF> while the definitions for content and capture ID list use <captureIDREF>. Same goes for encoding ID, which is sometimes called “encID” and sometimes called “encodingID.” If the difference in name is not meaningful, the same names should be reused throughout.

(3) I think the explanation of each of the extensibility points in the document needs to be clearer. Some of the elements are extensible when I wouldn’t have expected them to be, and the document often doesn’t explain why the model’s extensibility is being specified as it is. For example, it’s not clear to me why the content type or the capture scene type are extensible, and there’s no explanation provided. For other types I can intuit why they are extensible, but it would help to make it explicit. 

(4) Furthermore, this data model seems to err way on the side of extensibility, leaving me to wonder just how much it will really facilitate interoperability. I think the trade-offs the WG is making here need to be thoroughly justified in the text. 

= Section 3 =

CLUE consists of a small number of tightly coordinated specs. Why is this spec not using the definition of "CLUE Participant” from the Framework doc? What was the point of defining it the way it’s defined in the framework doc if it can’t be used in the schema? And why is it stated differently than how it’s stated in the protocol doc?

= Section 11.2 =

"Common values are "audio", "video",
   "text".  Other values can be provided.  It is assumed that
   implementations agree on the interpretation of those other values.”

This seems like an interop problem waiting to happen, since there is no registry specified for these values. Why not create one so that independent implementers can at least know what other values may be supported by other implementations?

= Section 11.10 =

(1)
"It indicates the criteria applied to build the
   multiple content capture using the media captures referenced in
   <contentCaptureIDs>.”

<contentCaptureIDs> is not defined anywhere. Did you mean <captureIDREFs>?

(2)
Same comment as section 11.2.

= Section 11.18 and 11.19 =

The text says “The current possible values are …” — is there a plan to add more values? (I note this is different from the personType definition, which doesn’t say “current.”)

= Section 11.22 =

Why is this a SHOULD rather than a MUST?

= Section 11.23 =

"When defining new media capture types that are going to be described
   by means of the <otherMediaCapture> element, spatial properties of
   such new media capture types SHOULD be defined (e.g., whether or not
   they are spatially definable, whether or not they should be
   associated with an area of capture, etc.).”

Are there other spatial properties that should be defined besides the two that are listed? If this is going to be a normative requirement, the list should be precise.

= Section 11.27.2 =

Why is the media type attribute optional?

= Section 15 =

(1) What does “full-optional” mean?

(2) "Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints.” The exception cases to this recommendation should be described.

= Section 29 =

The references are not split between normative and informative. It seems to me that only RFC 3550, RFC 3688, RFC 4353, and RFC 7667 should be informative references. The rest should be normative.

Nits:

= General =

(1) For the ID elements, I think it would help to specify the scope within which the IDs are expected to be unique (e.g., within the advertisement, or more narrowly).

= Section 11.1 =

s/(e.g., simultaneous sets, capture encodings, and others)/(e.g., simultaneous sets, capture encodings, and others via <captureIDREF>)

= Section 11.7 =

s/last ones/latter ones/

= Section 11.29.1.2 =

I think this section should point to Appendix A in the ecrit document.