An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model
draft-ietf-clue-data-model-schema-17

[Ballot discuss]
Thank you for updating the document. However one of the changes looks incorrect to me:

You incorrectly using RFC 2119 as a reference for language tags instead of RFC 5646. The following changes will address my concern:

In 11.3 replace:

OLD:
  Such an attribute is compliant with [RFC2119].

NEW:
  Such an attribute is compliant with the Language-Tag ABNF production from [RFC5646].

In 11.5 replace:

OLD:
  Each such element has to be compliant with [RFC2119].

NEW:
  Each such element has to be compliant with the Language-Tag ABNF production from [RFC5646].

[Ballot discuss]
Thank you for updating the document. However one of the changes looks incorrect to me:

You incorrectly using RFC 2119 as a reference for language tags instead of RFC 5646.
In 11.13: you need to have a Normative Reference to the language tag document here (RFC 5646) when you describe the "lang" attribute.

[Ballot comment]

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

[Ballot discuss]

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?

[Ballot comment]

- section 25 says: "Indeed, authenticated access is
strongly advisable, especially if you convey information
about individuals ()..." 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:-)

[Ballot comment]
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  as for mediaType. I didn't put it in the discuss because I think  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  MUST be provided."

Consider promoting the negation into the 2119 keyword. E.g., "...  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  element."
 
Hard to parse. Consider " ... MAY show the  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.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
This document will be a standard track RFC, the document provides an XML schema file for the definition of CLUE data model types. The type is indicated in the title page

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
This document provides an XML schema file for the definition of CLUE data model types defined in the CLUE framework document.
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
The document was discussed in the meeting, in conferences calls and on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
There is an existing implementation of the data model.
The chairs asked for an XML review but could not get one so far. It will be good to have one during the IESG processing.
XML review done see https://mailarchive.ietf.org/arch/msg/clue/1WeFBrIo17CLL_t_6anoHAHMwqg

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Roni Even is the Document Shepherd.
The responsible AD is Alissa Cooper.
(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document shepherd reviewed the document in previous and current versions and found it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document had good reviews before and during the WGLC.  The comments during the WGLC were addressed and we had a second short WGLC just before sending the document to publication.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
There is a need for XML directorate review.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.  If not, explain why?
Yes. The authors confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
There are none.
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
The WG understand the document and agree with it.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
There are a couple of long lines, can be fixed later  - RFC editor
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Need an XML review.
(13) Have all references within this document been identified as either normative or informative?
There are only informative references.
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No
(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are none
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
The IANA considerations are consistent with the document. The IANA registries are specified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No  new IANA registries.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
I reviewed the XML schema.

[Ballot discuss]
- 11.2: 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?

[Ballot comment]
Substantive:

-11.10 - I have a similar question for  as for mediaType. I didn't put it in the discuss because I think  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  MUST be provided."

Consider promoting the negation into the 2119 keyword. E.g., "...  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  element."
 
Hard to parse. Consider " ... MAY show the  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.

[Ballot discuss]
This is generally a well written document, but I have a couple of very small points that need to be fixed:

Abstract: I have no CLUE what you are talking about. Abstracts should be self contained, i.e. being understandable on its own. The Introduction section has more relevant text which you might want to copy here.

In 11.13: you need to have a Normative Reference to the language tag document here (RFC 5646) when you describe the "lang" attribute.

[Ballot comment]
In 11.24.1: A reference to xCard would be good to have here.

In 16.30:

MIME type name typo on the Subject line.

"Application that use this media type: none ?"

I don't think this is correct. Please provide some examples of applications that would be using this media type. If no applications are going to be using this media type, there is no need to register it ;-).

[Ballot discuss]
The document looks good, I just have a couple of items on the security considerations to discuss as they are not mentioned and I'm not sure if they have a good reason to be excluded.

1. Session encryption to prevent active (tampering) or passive (information gathering for example) attacks.  Integrity protection and authentication are mentioned, but without looking through a few documents, I don't know if that means encryption or some hash value comparisons or something else.

2. Schema drafts tend to cover the need for well-formed schemas as part of the security considerations.  Can you add something in about that (not much is required, but it's good for implementers to know this is important)?  You can see two recent examples for guidance:
YANG - https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
IODEF - https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ron.even.tlv@gmail.com, clue@ietf.org, clue-chairs@ietf.org, alissa@cooperw.in, draft-ietf-clue-data-model-schema@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An XML Schema for the CLUE data model) to Proposed Standard


The IESG has received a request from the ControLling mUltiple streams for
tElepresence WG (clue) to consider the following document:
- 'An XML Schema for the CLUE data model'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-05-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides an XML schema file for the definition of CLUE
  data model types.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
This document will be a standard track RFC, the document provides an XML schema file for the definition of CLUE data model types. The type is indicated in the title page

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
This document provides an XML schema file for the definition of CLUE data model types defined in the CLUE framework document.
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
The document was discussed in the meeting, in conferences calls and on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
There is an existing implementation of the data model.
The chairs asked for an XML review but could not get one so far. It will be good to have one during the IESG processing.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Roni Even is the Document Shepherd.
The responsible AD is Alissa Cooper.
(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document shepherd reviewed the document in previous and current versions and found it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document had good reviews before and during the WGLC.  The comments during the WGLC were addressed and we had a second short WGLC just before sending the document to publication.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
There is a need for XML directorate review.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.  If not, explain why?
Yes. The authors confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
There are none.
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
The WG understand the document and agree with it.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
There are a couple of long lines, can be fixed later  - RFC editor
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Need an XML review.
(13) Have all references within this document been identified as either normative or informative?
There are only informative references.
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No
(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are none
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
The IANA considerations are consistent with the document. The IANA registries are specified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No  new IANA registries.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
I reviewed the XML schema.