Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures
draft-ietf-clue-rtp-mapping-14
Yes
(Spencer Dawkins)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Joel Jaeggli)
(Kathleen Moriarty)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 12 and is now closed.
Alissa Cooper Former IESG member
(was Discuss, Yes)
Yes
Yes
(2017-02-27)
Unknown
Magnus' review comments have been addressed.
Ben Campbell Former IESG member
(was Discuss)
Yes
Yes
(2017-01-19 for -12)
Unknown
Thanks for addressing my DISCUSS point. I'm leaving the other comments below for posterity; I think most of them have been resolved. Substantive: -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. Editorial: - 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 endpoint," 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.)
Spencer Dawkins Former IESG member
Yes
Yes
(for -12)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -12)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -12)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -12)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -12)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -12)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2017-01-18 for -12)
Unknown
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.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -12)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -12)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-01-17 for -12)
Unknown
- 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.
Stephen Farrell Former IESG member
No Objection
No Objection
(2017-01-17 for -12)
Unknown
- 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;-)
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -12)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -12)
Unknown