An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model
draft-ietf-clue-data-model-schema-17
Yes
(Alissa Cooper)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 14 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -14)
Unknown
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2016-08-15)
Unknown
Thank you for addressing my DISCUSS.
Alia Atlas Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -14)
Unknown
Ben Campbell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-06-01 for -15)
Unknown
Substantive: I cleared my discuss on 11.2. My original point was as follows: "I would like to discuss whether it's a good idea to allow arbitrary values for mediaType, beyond those types registered in IANA. The text seem to encourage proprietary values. Did the working group consider requiring IANA registration of some sort for new values?" I cleared because discussion showed that the working group thought about this, and made a conscious choice. I think it might still be helpful to add a sentence or two about the motivation for this particular balance between customization and interoperation. For example, do people expect new media-type values to be rare? Are there any concerns about value-collisions? -11.10 - I have a similar question for <policy> as for mediaType. I didn't put it in the discuss because I think <policy> will have an overall smaller impact on interoperability. But I's still like to see discussion about why arbitrary values do not create an interop problem. - 15, 2nd and 3rd paragraph: Would it be reasonable to promote the SHOULD to a MUST when privacy sensitive or individually identifiable information is carried? Editorial and Nits: - The shepherd mentions a hope for an xml review during IESG processing. has that occurred? (If so, an update to the shepherd write up would be helpful.) -1, third paragraph, first sentence - I don't understand what the sentence means. -3, "CLUE Participant" - It seems a bit odd to repeat all the framework definitions here, but not repeat the one definition from the protocol doc. - 4, last sentence : "As a general remark, please notice that optional elements that don’t define what their absence means are intended to be associated with undefined properties." I'm not sure what that means. Can you elaborate? -11, first paragraph : "The features that are common to all media types appear within the media capture type, that has been designed as an abstract complex type." s/that/which -11.6: "...no <spatialInformation> MUST be provided." Consider promoting the negation into the 2119 keyword. E.g., "... <spatialInformation> MUST NOT be provided." - 11.7: "A multiple content capture is made by different captures" Should "made by" be "made up of"? -- "MAY show in its XML data model representation the <content> element." Hard to parse. Consider " ... MAY show the <content> element in its XML data model representation." -- "It is composed by a list of media capture identifiers" What is the antecedent of "It"? - 11.6: s/highly-dinamic/highly-dynamic - 13: "It has been conceived only for data model testing purposes..." What is the antecedent for "It"? - 15, 2nd paragraph: "Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints." should "accessed" be "accessible"? (As it stands, it seems to depend on good behavior of endpoints, which I assume is not the intent.) -- "There might be more exceptions... More than what? - Normative References: It seems a bit odd to see these second (although I don't know if there is an actual "rule" about that.) Also, the shepherd write up said that there were only informative references. I assume these were added after the fact. It would be very helpful if shepherds would update the write ups when things are overtaken by events.
Benoît Claise Former IESG member
No Objection
No Objection
(2016-06-02 for -15)
Unknown
Good discussion between Stefan Winter (OPS DIR) and Simon Pietro Romano. The outcome should be integrated in the next draft version.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -15)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -15)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2016-06-08 for -16)
Unknown
Thank you for addressing my prior discuss comments.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -14)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -14)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-06-01 for -15)
Unknown
The bit below used be a discuss. The discussion indicated that there isn't really a serious intent to support RBAC nor selective field confidentiality so I've cleared. There may be no change needed here, but I want to check. This draft defines no security mechanisms and doens't say how to interoperably use any security mechanisms. For example, I don't understand how one might (interoperably) do RBAC or other "advanced" security mechanisms that are promised in other CLUE documents. [1] Even worse, I don't get how one could e.g. use XMLENC to encrypt parts of the schema here, as that'd (I think) almost certainty have to have been considered in the design of this schema, but there's no evidence of that. That seems to end up meaning that the only security mechanisms that one can use with CLUE and for which one can currently achieve interop are transport security mechanisms. That all seems to conflict with text in the security consideration of the CLUE protocol draft. So my question to discuss is: other than transport security, what interoperable security mechanisms are expected to be defined in CLUE, and where might I find descriptions of those? - section 25 says: "Indeed, authenticated access is strongly advisable, especially if you convey information about individuals (<personalInfo>)..." I don't get the logic there - it seems incorrect actually. Personal data usually implies a need for confidentiality and not authenticated access - what was meant here? Are you using the term authenticated access to mean more that it does? (to this reader:-)
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -15)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -15)
Unknown