Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures

Note: This ballot was opened for revision 12 and is now closed.

(Ben Campbell) (was Discuss) Yes

Comment (2017-01-19 for -12)
No email
send info
Thanks for addressing my DISCUSS point.  I'm leaving the other comments below for posterity; I think most of them have been resolved.


-3: The opening paragraph mentions "Point-to-Point, as well as Media-Mixing
   mixers, Media- Switching mixers, and Selective Forwarding Middleboxs." The section goes on to discuss the first two, but doesn't mention the last two.

-5, paragraph 4: "When the media provider
   switches the MC it sends within an MCC, it MUST send the captureID
   value for the MC just switched into the MCC."

Does MUST send mean MUST send both in the RTP header and as an RTCP SDES item, as in the previous sentence?

-5, paragraph 5:
It would be helpful to add a sentence or two clarifying the difference between an MCC that carries multiple MCs at the same time, and one that switch between MCs, but only carry one at a time.


- 1, 2nd paragraph: Please expand SSRC on first use.

-3, 2nd paragraph: Please expand SDES on first use.
-- "specified in CLUE use case [RFC7205]"
should that say "specified in the CLUE use case document [RFC7205]"?
-- "described using MCC."
missing article ("using an MCC."

-3, third paragraph: "If needed by CLUE
Missing article.

-4, 2nd paragraph: s/"slide video"/"side video"

-6, first paragraph: s/"made by"/"made up of"  ; or "comprises"

-9, 2nd paragraph: Please don't use 2119 to describe requirements from other documents, unless in a direct quote (in quotation marks.)

(Alissa Cooper) (was Discuss, Yes) Yes

Comment (2017-02-27)
No email
send info
Magnus' review comments have been addressed.

(Spencer Dawkins) Yes

(Jari Arkko) No Objection

Comment (2017-01-18 for -12)
No email
send info
Points from Vijay's Gen-ART review seem to not yet have been taken into account. They should, while they are editorial, they made sense at least to me.

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Benoît Claise) No Objection

(Stephen Farrell) No Objection

Comment (2017-01-17 for -12)
No email
send info
- abstract: expanding CLUE (or avoiding the acronym) in the
abstract would be better (some abstract readers won't have
heard of CLUE before).

- section 9: I think the paragraph about RFC6562 should be
reduced to the first sentence only. The rest, if it were
correct (and I'm not sure), ought be part of an update to
6562. That's not just process-crap - I would expect the
state of the art to change here and when it does then the
right place to deal with that will be in an update to 6562.
(And hey, it's been 5 years already since we did that, so
maybe it'd be timely if someone re-checked the state of the
art here?) This could have been, but is not a DISCUSS
ballot, on the basis that if we do update 6562 then we
could have that formally UPDATE this RFC, but requiring
that we remember to do that seems worse than just leaving
it to a putative 6562bis. (And again, could we find someone
to re-check 6562 and perhaps consider if a BCP on the topic
would be a worthwhile thing?)

- Section 9 says: "In multi-party communication scenarios
using RTP Middleboxes; this middleboxes are trusted to
preserve the sessions' security." That is just wrong. The
middleboxes may or may not be trusted (or even known to
exist) by the parties to the call. What you should be
saying is that those middleboxes are REQUIRED, by this
protocol/spec, to not weaken security. (And this one is not
a DISCUSS because the rest of the para mitigates the
horrible first sentence;-)

(Joel Jaeggli) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2017-01-17 for -12)
No email
send info
- I find the following sentence in the abstract rather confusing: „This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol.“ I would just start with the second sentence directly and potentially also mention that this doc defines a new RTP Header Extension for the mapping.
- There is still some redundancy in this document that could be removed for more clarity.

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection