Framework for Telepresence Multi-Streams
draft-ietf-clue-framework-25

[Ballot comment]
As reviewed by Eric Vyncke in his OPS-DIR review (mainly for documentation purposes):
This rather long I-D is quite clear and easy to understand with multiple examples. I found nothing in this framework document which could cause operational issues.

The CLUE devices are able to detect other CLUE-enabled devices which is of course good for migration/interoperation.

Unrelated to this specific ID (so feel free to ignore) but more on the other documents (data model & protocol): the protocol extensions are briefly mentioned in this framework document section 11, but, can the WG take special care in versioning the CLUE protocol (as proposed in the current protocol I-D) as well as allowing extension of the finite set of values for some information? For exemple, the "view" (section 7.1.1.8) has only a limited set of values and there appears to have no way to extend it, is there an intent to open a  IANA registry for those values? Probably not as the IANA considerations are 'none'. Does CLUE WG (or another) have the intent to develop a YANG model? It does not appear in the CLUE WG charter.

As a small nit, I would suggest to move the long section 12 (informative examples) as an appendix.

[Ballot comment]

Thanks for a pretty comprehensive description. These sound like
fun systems on which to work.

Pity there are so many IPR declarations with not great terms and
for something that to me at least doesn't appear to require
invention (just construction of existing bits) but I guess that's
the world we live in and the WG were ok with that.

- 7.1.1.3 - I wondered if the "MUST be co-planar" requirement
could cause issues (bugs) if receivers don't check for that. Are
receivers expected to verify that on receipt or is the MUST only
for senders?

- 7.1.1.10: privacy issues abound, but section 15 only refers to
the communications security aspect. I think you ought recommend
that implementations SHOULD minimise the information sent, and
SHOULD give users control over what is sent. You might want to
note the utility of sending the same subset of information for
regular repeated calls but I'm not sure what clue protocol might
know that calls are repeats or if there's a better way to manage
re-use of privacy settings for users.

- The secdir review [1] noted some issues that may be worth
considering for later WG documents. I'd encourage folks to try
get in touch with the reviewer when doing later work as that
might avoid some late-surprises. (That is not a threat btw, just
encouragement to try take advantage of a reviewer who likes to
consider more than just what's in front of him today:-)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06244.html

[Ballot comment]
I remember the first couple of years of CLUE. This was worth writing.

I'm a Yes, but did have some editorial suggestions and questions.

In Section 1. Introduction,

  Current telepresence systems, though based on open standards such
  as RTP [RFC3550] and SIP [RFC3261], cannot easily interoperate with
  each other. 

this text hasn't changed since the 00 individual draft from 2012. Is it still true for "current" telepresence systems?
 
In this text:

  If the physical space does not
  have a well-defined front and back, the provider chooses any
  direction for X and Y consistent with right-handed coordinates.
 
is there any reference/pointer you could provide to a definition of "consistent with right-handed coordinates"? If everyone understands that but me, please ignore this comment ...

Is "line of capture" a meaningful concept on its own? Or is it only meaningful as "point on line of capture"?

I wonder if it would be less confusing if you always called "volume of capture" "3-D volume of capture". I was consistently assuming "volume" was an audio thing, when I saw "volume of capture" with no qualifier. You define it as "3 dimentional volume of capture", but then drop that qualifier in subsequent use.

Is Person Type just a string for presentation? If so, that's fine, but the framework defines 8 types in some detail, and notes that this list isn't exhaustive and that custom person types can be defined, so I wonder if there's any expectation that CLUE will do anything specific, based on Person Type.

PIP isn't expanded until its 5th use (if I'm reading correctly). I'm guessing that PiPs is the plural of PiP, but that's a guess, and I wouldn't mind a word or two of explanation about that. "Tiled" is probably a term of art, so maybe it doesn't need an explanation, but it's not clear whether "tiled" and "PiP" are the same thing or not (which would be a good thing to include in an explanation, if you add one).

[Ballot comment]
I have some minor comments. These should be easy to resolve, and I don't think any are show-stoppers.

=== Subtantive ===

- Section 3, MCU definition.
Does this need a normative reference to 4353? I'm not sure the definition can be understood as written without reading it.

- 4, paragraph (5):
The 2119 "OPTIONAL" is vague about what it applies to. Use of companion protocols? Consider stating this descriptively.

-4, last paragraph:
I don't think the 2119 "REQUIRED" is needed or appropriate here. It doesn't seem to add anything, and might be interpreted to not  allow  local policy decisions, etc.

-5, paragraph 5:
The paragraph describes what Media Capture means, but never really defines what "Encoding" means. (And the definition of "Encoding" in the terminology section is somewhat circular.)


- 5, 3rd paragraph after Fig 2:
Isn't setting up media transmission a primary effect?

-6, third bullet:
It seems kind of odd to use a  MUST for this,  given that the criteria of professionally installed is somewhat vague. I think a non-normative recommendation would make more sense.

- 7.1.1.7, "Note"
Where are these keywords expected to be defined? This seems like an unfinished section--is it an open to do item?

- 7.1.1.8
Why is this limited (with a MUST) to these defined values? This list assumes traditional usages. It seems like a more open list would allow for  innovative usage. For example, a game court, an outdoor space, etc.

- 7.1.1.9:
This section seems to need a normative reference to 5646.

- 7.1.1.10: Are LOGO, PHOTO, or SOUND the only kinds of large content that can be carried here?

-7.1.1.11: Is the list of person types exhaustive?

-7.1.1.12: How is priority interpreted? Larger number is higher priority? Is it strictly a matter of ordering, or does 2N represent twice the priority of N?

-8, paragraph after Table 5: "Simultaneous Transmission Sets MUST allow all
  the media Captures in any particular Capture Scene View..."

This seems to reverse the causality. Since the simultaneous transmission set is based on physical limits, shouldn't it say that any particular CSV MUST respect the limitations in the simultaneous transmission sets? (Same for Global View).

- 15, 2nd paragraph:
I think this requires 5239 to be a normative reference.

-15, paragaph 4: "DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by other means..."
Is "secured by other means" intended to be the sole exception? If so, then this might should say MUST ... unless". As defined in 2119, a SHOULD would allow an implementation to skip the protection for other reasons, if the implementer was aware of the implications, etc...
Also, should the references to 7201 and 7202 be normative?

=== Editorial ===

- Figure 2:
By SDP Media Session you mean an RTP session as described by the basic SDP right? That is not an SDP session per se.

-5, third paragraph from end:
Please avoid 2119 keywords inside parenthetical phrases. Also, it's redundant to say implementations of a protocol MUST follow the protocol :-)

I'd like to keep this on 12/4 if possible as it's already been delayed somewhat during AD eval. Let's see how the balloting goes and if Joel wants to defer later in the week we can do that but if it has enough ballots to go forward I'd like to process it this week.

can we move this to 12/17, the opps dir review and my reading of it probably won't clomplete by then, and it has no ballot yet.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-clue-framework-24.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

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, draft-ietf-clue-framework@ietf.org, alcoop@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Framework for Telepresence Multi-Streams) to Proposed Standard


The IESG has received a request from the ControLling mUltiple streams for
tElepresence WG (clue) to consider the following document:
- 'Framework for Telepresence Multi-Streams'
  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 2015-11-26. 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 defines a framework for a protocol to enable devices
  in a telepresence conference to interoperate.  The protocol enables
  communication of information about multiple media streams so a
  sending system and receiving system can make reasonable decisions
  about transmitting, selecting and rendering the media streams.
  This protocol is used in addition to SIP signaling and SDP
  negotiation for setting up a telepresence session.




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

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


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2244/
  https://datatracker.ietf.org/ipr/2347/
  https://datatracker.ietf.org/ipr/2255/
  https://datatracker.ietf.org/ipr/2264/
  https://datatracker.ietf.org/ipr/2265/
  https://datatracker.ietf.org/ipr/2269/
  https://datatracker.ietf.org/ipr/2270/

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 defines a framework for a protocol to enable devices in a telepresence conference to interoperate. 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 defines a framework for a protocol to enable devices in a telepresence conference to interoperate.  The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session.
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?
The actual protocol using the attributes defined in the network is almost done, it is aligned with this document and there is an implementation of the protocol. There are no specific reviews that need to be mentioned.

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

(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.
No need

(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 IPRs https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-clue-framework  from Polycom, Huawei and Ericsson. The WG is aware and there are no concerns.

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

No issues
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
No need for formal review
(13) Have all references within this document been identified as either normative or informative?
Yes
(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?
There are normative references to CLUE WG documents that are almost ready and that had good reviews in the WG.
(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).
No IANA action

(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 IANA action
(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.
No need