Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-08

Hi Colin,
Thanks for the review, see inline
Roni

> -----Original Message-----
> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: Friday, October 07, 2016 8:07 PM
> To: Paul Kyzivat
> Cc: CLUE
> Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-08
> 
> > On 23 Sep 2016, at 16:00, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> >
> > This is another WGLC for draft-ietf-clue-rtp-mapping-08.
> > It will end two weeks from today - Friday Oct 7, 2016.
> >
> > I'm calling this because substantial changes were made to the document as
> a result of conversations at the Berlin meeting, and subsequent discussion as
> raised questions.
> >
> > Please comment one way or another so that we can gauge the level of
> scrutiny that this version has received. If you haven't already, review the
> discussion that has already taken place on -08 to motivate your review.
> 
> I’ve read this version of the draft, and appreciate the updates made in light
> of my earlier feedback. However, I do still have some comments:
> 
> - Section 3: rather than try to explain the topologies, it might be clearer to
> just list them with reference to RFC 7667, stating that they can be used, and
> only explain any CLUE-specifics.
[Roni Even] The section does not explain just provide short description with some text on CLUE, I will delete the last sentence on the media switching mixer and add some text on CLUE. As for SFM we felt that we need some text since the RFC7667 was not clear enough.
> 
> - Section 4: “using, the SDP description" - the comma is incorrect, and makes
> it look like something is missing. Should it just be removed?
[Roni Even] yes, thanks
> 
> - Section 4: “...placing them into RTP sessions using, the SDP description.
> For example, main and slides video sources are separated into separate RTP
> sessions based on the content attribute [RFC4796]" - this is incorrect. The
> streams are placed into separate sessions by running them on different
> transport layer flows, so they have disjoint SSRC-space. Attributes in the
> sessions description, such as RFC 4796, identify those separate RTP sessions;
> they don't separate them into different RTP sessions. (The rest of the
> paragraph is okay)
[Roni Even] You are right, this is not an example it is more of a way to describe what is in the stream as further information. Will fix it.
BTW: I went back and saw that this text and the "using, the SDP" were there even on the individual draft https://tools.ietf.org/html/draft-even-clue-rtp-mapping-03#section-4 
> 
> - Section 4, 3rd paragraph: the terms “session multiplexing" and "SSRC
> multiplexing" are ill defined, and I strongly suggest they are not used. I think
> you want to say that CLUE supports sending each RTP stream in a separate
> RTP session, and also sending several RTP streams within a single RTP session
> using the SDP BUNDLE extension, rather than it supports “session
> multiplexing and SSRC multiplexing”.
[Roni Even] OK, will change the text as you suggested
> 
> - Section 4.1: Same comment about “SSRC multiplexing” as above.
> 
> - Section 4.1: The first paragraph confuses me. It gives an overview “for
> information only” that “can be used” — but is very unclear on what I need to
> implement for interoperability. It lists drafts that “provide mechanisms” or
> “provide the means” but gives no guidance on what to implement.
[Roni Even] I am not sure here, the usage is specified in the clue signaling document and I also think that the paragraph about RFC6236 (image attribute) is not correct. I will also consult with Jonathan about the need for this section.
> 
> - Section 5.1: Please align terminology with RFC 3550 - it’s an “SDES Item”
> not an SDES message.
> 
[Roni Even] OK

> - Section 5.1: “This SDES message MAY be sent in a compound RTCP packet
> based on the application need” - surely this needs to be “MUST be sent in a
> compound RTCP packet unless support for Reduced-size RTCP has been
> negotiated as specified in RFC 5506”.
[Roni Even] OK
> 
> - Section 5: what’s the syntax of the CaptureId (whether sent in RTCP SDES or
> hdr ext)?
[Roni Even] It is the CLUE me4dia capture as stated in 5.1
> 
> - Section 9 gives security considerations for a large number of RTP
> extensions. These are all reasonable. However, this draft doesn’t mandate
> that these extensions are used, so I don’t understand why they’re discussed
> here.
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue