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

From: Alissa Cooper <[email-masked]>
Date: Tue, 1 Mar 2016 09:09:41 -0800

Is there an estimate of when these comments will be addressed?

Thanks,
Alissa

> On Feb 23, 2016, at 2:31 PM, Alissa Cooper <[email-masked]> wrote:
> 
> 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.
> 
> 
> 
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 1 Mar 2016 18:21:29 +0100

Hello Alissa,

we’re working on them right now. We’ll send back our comments/modifications by the end of this week.

Thank you for your useful feedback, by the way!

Simon

> On 01/mar/2016, at 18:09, Alissa Cooper <[email-masked]> wrote:
> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 1 Mar 2016 09:54:00 -0800

Great, thanks.

> On Mar 1, 2016, at 9:21 AM, Simon Pietro Romano <[email-masked]> wrote:
> 
> Hello Alissa,
> 
>> On 01/mar/2016, at 18:09, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Feb 23, 2016, at 2:31 PM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>                                            e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 1 Mar 2016 20:52:39 +0200

Hi Alissa,
Thanks for the review, I will try to answer some of the comments and cut the rest for clarity
Roni

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Sent: Wednesday, February 24, 2016 12:32 AM
> To: CLUE
> Subject: [clue] AD review: draft-ietf-clue-data-model-schema-12
> 
> 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:
> 
> 
> = Section 11.2 =
> 
> 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?

[Roni Even] I think that the meaning was to allow the media types from the IANA registry http://www.iana.org/assignments/media-types/media-types.xhtml . The issue will be about the usage of other media types in the CLUE environment and not about the values themselves. Need to clarify

> Same comment as section 11.2.
[Roni Even] This one is more complicated, I think we need to have a normative language requiring a document that describes the policy for interoperability. On the other hand I think that the WG thought that it  should not be strict for an IETF document but can be specified by industry forums or any other means. This is an optional parameter and my view is that the policy will be handled by application level protocol (e.g. XCON)

> 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.”)
[Roni Even] I think we can take out the "current". Still there may be other values, we tried to list the commonly known ones.
> 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

[Roni Even] I think it is discussed in section 11.5

> precise.
[Roni Even] I think the second part of the section explains it.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 4 Mar 2016 11:49:11 -0800

Hi Roni,

> On Mar 1, 2016, at 10:52 AM, Roni Even <[email-masked]> wrote:
>> 
>> = Section 11.23 =
>> 

If the properties are limited to those discussed in 11.5 then the text in 11.23 should say that.

> [Roni Even] I think the second part of the section explains it.

I don’t think it does. A simultaneous set is defined as a set of captures that all have the same type. So why would you send a set without indicating the media type?

Alissa

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 7 Mar 2016 06:03:12 -0800

Hi Alissa and Roni,

> I don’t think it does. A simultaneous set is defined as a set of captures that all
> have the same type. So why would you send a set without indicating the
> media type?

There is some history to this. Originally, the simultaneous set was a sequence of media captures or scene views. Since both of those things already include a specific media type, there was no need to specify the type again in the simultaneous set itself. Then later we added ability to include an entire capture scene. Since a capture scene could contain multiple media types, it now becomes necessary to specify which media type applies to the simultaneous set. That is why we added the optional media type attribute.

Mark

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 7 Mar 2016 20:42:36 +0100

Hello Alissa,

thanks a lot for your review. Please find in-line my answers to your comments and observations.

> (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 care…

We tried to perform the consistency check. We found out that most “musts” hat to be normative (i.e., “MUST”) and replaced them accordingly. As to “optional” we are not actually using it with an RFC2119 meaning. Such a term is mostly used throughout the draft to indicate “optional” XML schema elements. We are hence inclined to leave them lowercase. What’s your feeling about this interpretation? The same holds for “mandatory”, by the way.

> (2) The definition of the simultaneous set type uses <mediaCaptureIDREF> while the definitions for content and capture ID list use <captureIDREF>.

Good catch. We replaced “captureIDREF” with “mediaCaptureIDREF"

> 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.

Done. We replaced “encID” with “encodingID”.

> (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 o…

We wanted to offer people enough flexibility as to define custom (and perhaps currently unforeseen) extensions to the schema, without losing compliance with the standard. We did this by leveraging  <xs:any> elemenrts and <xs:anyAttribute> attributes, which is a common approach with schemas, still matching the UPA (Unique Particle Attribution) Constraint. The "XML Schema extensibility” section was meant to illustrate the mentioned approach.

> (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 makin…

See my answer above to your comment number (3). What would you suggest to improve the way we deal with extensibility?

> = 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? 

The CLUE Framework doc does not actually include a definition of the "CLUE Participant”. It rather introduces the “CLUE Endpoint”, consisting of “...of one or more physical devices...and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent)”. What we needed in the data model doc was a definition as simple as “...a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol”. Such a definition does not match the “CLUE Endpoint” of the framework and cannot even be replaced by the RFC4353 definition. Indeed, in the most general case, a CLUE Participant might even not use SIP at all. That’s why we took a freedom to put this (and only this) new definition in the data model document.

> And why is it stated differently than how it’s stated in the protocol doc?

They are (or at least should be) indeed identical. I checked version -06 of the protocol and version -12 of the data model and found the following:

- Protocol:

CLUE Participant (CP):  An entity able to use the CLUE protocol within a telepresence session.  It can be an endpoint or an MCU able to use the CLUE protocol.

- Data Model:

This term is not imported from the framework terminology.  A CLUE Participant identifies a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol.

If we decide that such a definition can survive, we might proceed as follows: (i) introduce it in the protocol draft; (ii) point to it in the data model draft. What’s your feeling about that?

> 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…

I’m not sure I understand this point correctly. The idea here was to be as generic as possible. That’s why: (i) the basic media capture type is an abstract one; (ii) “concrete” definitions for audio, video and text capture types have been specified; (iii)  a 100% generic “otherCaptureType” type has been defined; (iv) the “mediaType” attribute has been generically defined as a string, with no particular template.

That’s why we assume that if one chooses to rely on a brand new media type and wants to interoperate with others, an (application-level) agreement is needed on how to interpret such information.

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

Yes.

> 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.”)

These are actually consistent, respectively, with section 7.1.1.7. (Presentation) and section 7.1.1.8. (View) of the framework document.

> Why is this a SHOULD rather than a MUST?

I believe we had identified some scenarios in which you might actually decide to "spatially define” a text capture; but these scenarios do not come to my mind right now. I’ll replace SHOULD with MUST, unless someone else finds a counter-example.

> 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.

What we wanted to state here is that a new media capture might require the definition of spatial properties. In such a case, the <spatialInformation> element would be present and would contain (at least) either the capture origin, or the capture area, or both. The list is not exhaustive, since, like all other pieces of information in the schema, further elements and attributes can be added if needed (extensibility).

> Why is the media type attribute optional?

If the simultaneous set contains references to media captures, than you don’t need to specify the media type, since it is a mandatory attribute for each (referenced) media capture. On the other hand, as the last part of the paragraph explains, if you only use capture scene identifiers, than you’ll necessarily need to indicate the media type associated with the media captures belonging to the set in question and which can be sent simultaneously.

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

Nothing meaningful, indeed :-). We meant something like "full-fledged”, “thoroughly specified”, or similar. What would you suggest here?

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

We tried to highlight the fact that authenticated access is strongly advisable, especially if you convey information about individuals (<personalInfo>) and/or scenes (<sceneInformation>). There might be more exceptions, depending on the level of criticality that is associated with the setup and configuration of a specific session. In principle, one might even decide that no protection at all is needed for a particular session; that’s why we did not make this a MUST.

> 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.

Agreed.

> (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).

XML ID elements are defined in W3C terms, which means that: (i) the value is unique within the XML document; (ii) each element has at most one single unique identifier. When we wanted to relax such a constraint, we defined the “iD” as a string.

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

Done.

> s/last ones/latter ones/

Done.

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

Done.

Thanks again for your feedback and comments!

Simon