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

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