Skip to main content

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