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

Hello,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

I believe this draft is ready with (simple) issues.

1) section 3

You seem to use words starting with capitals when discussing
well-defined words. There is one definition which talks about a Subject:

"Plane of Interest: The spatial plane containing the most relevant
Subject matter."

You did not introduce a defined meaning for Subject though. The term is
also not mentioned in draft-ietf-clue-framework. Was that an ommission,
or should "subject matter" simply not be capitalised?

(Given the above definition, I don't really understand what the Plane of
Interest really is either way, but I don't mind; I'm not enough a media
person to care)

2) 11.5.1 / 11.5.2

I have doubts regarding the well-definedness of the (x,y,z) point tuple
to indicate <capturePoint> and the bounds of <CaptureArea>. Earlier on
in the document I read that this is meant to be relative to the room
that the equipment is physically located in.

Does CLUE define in which corner of the room the (0,0,0) reference point
lies, and which axis is where? (And if yes, how does it do that?)
Otherwise, misunderstandings between sender and receiver are bound to
happen. What about rooms without "simple" 90 degreees corners, like
octagonal rooms, or ones with round-shaped walls ("the oval office" :-) )?

There is also no unit of measurement attached to the numbers, AFAICT
(<scale> means something else, and is in a different part of the schema).

Looking at my monitor setup and X's way of defining orientation,
wouldn't something more simple like a "RightOf" or "LeftOf" position
convey enough information about the setup, and be more straightforward
to identify for recipients of the room setup data?

3) 11.16

If mobility is highly-dynamic (NIT: s/dinamic/dynamic/ !) then does this
imply that the capturePoint/captureArea is by definition
nonSpatiallyDefinable? Should this be noted explicitly in the document?

4) 11.18

The text and schema are contradictory: Text states the possible values
are: "table", "lectern", "individual", and "audience". But the enum also
lists "room".

What is the process to add new values to this enum? E.g. I can think of
a webcam showing some open space, like the Golden Waterfalls on Iceland.
That's a terrific *view*, but what's its <view>? ;-)

Will you re-spin new schemata for every enum change that may become
necessary over time?

5) 11.19

A part of presentations is often a screen sharing of sorts. Does this
enum lack something like "screensharing"?

6) I don't understand why you are diving into a further section
indentation level between 11.19 and 11.19.1. <presentation> is not a
parent of <embeddedText>, but rather of a <mediaCapture>? Isn't this
more like a 11.20 then?

7) same for <capturedPeople> - it should not be a 11.19.2 but (with my
previous comment) a 11.21.

8) 11.22 you write:

"   The XML Schema representation of the text capture type is currently
   lacking text-specific information, as it can be seen by looking at
   the definition below:"

What does "lack" mean here? Were you simply too lazy and omitted it despite
knowing better? Or is it simply the case that there are no known properties a
text-based media which aren't already covered by the generic mediaCaptureType
already? If the latter, maybe it's clearer to say just that.

9) 11.29.1.3

The text and schema are contradictory: Text states the possible values
are "presenter", "timekeeper", "attendee", "minute taker", "translator",
"chairman", "vice-chairman". While the XML has an additional "observer".

What is the process to add new values to this enum? E.g. I can think of
the role "operator" when some helpdesk person is called into a VC to fix
something. Will you re-spin new schemata for every such tiny change that
may become necessary over time?

10) Section 13

"It has been conceived only for data model testing purposes and, though it
resembles the body of an ADVERTISEMENT message, it is not actually used in the
CLUE protocol message definitions."

I read this as: only in use during a test phase, prior to RFC status? In
that case, should this be deleted prior to publication?

11) 16.2

The XML for the schema is NOT the entirety of section 4; the section has
a preface and an ending which are not part of the schema.

Also, it is not very good style to publish the schema exclusively inline
in an RFC. Page breaks, headers and footers get in the way of tools
wanting to consume the schema. E.g. I would have loved to run the schema
through a well-formed-ness checker, but was appalled by the cut&paste
work I would have needed to do to that end.
One way out is to publish the schema as a separate file on a stable
location, and to reference that location in the RFC. This can (and
should) be in addition to the inline definition in section 4.

12) 17.

Same goes for the example file.

That concludes my review.

Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's
key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment:

0x8A39DC66.asc

Description:

 application/pgp-keys

Attachment:

signature.asc

Description:

 OpenPGP digital signature