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

[Paul Kyzivat <[e-mail]>]

Thanks Colin,

This whole subject is outside my area of expertise, so I'm depending on 
others to sort this out. I'd like to hear from the authors. I believe 
Roni is on vacation until this weekend. (I scheduled the end of WGLC 
with that in mind.) Hopefully we will hear from him by Monday.

I'm not sure where to go from here. I hope we won't need yet another 
WGLC, but that might turn out to be the case depending on the amount of 
work done after this.

	Thanks,
	Paul

On 10/7/16 1:06 PM, Colin Perkins wrote:
>> On 23 Sep 2016, at 16:00, Paul Kyzivat <[e-mail]> 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.
>
> - Section 4: “using, the SDP description" - the comma is incorrect, and makes it look like something is missing. Should it just be removed?
>
> - 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)
>
> - 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”.
>
> - 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.
>
> - Section 5.1: Please align terminology with RFC 3550 - it’s an “SDES Item” not an SDES message.
>
> - 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”.
>
> - Section 5: what’s the syntax of the CaptureId (whether sent in RTCP SDES or hdr ext)?
>
> - 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.
>
>
>