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 and the bounds of . 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 ( 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 ? ;-) 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. is not a parent of , but rather of a ? Isn't this more like a 11.20 then? 7) same for - 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