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

From: Colin Perkins <[email-masked]>
Date: Fri, 7 Oct 2016 18:06:51 +0100

> On 23 Sep 2016, at 16:00, Paul Kyzivat <[email-masked]> 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.

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Oct 2016 16:07:31 -0400

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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 12 Oct 2016 13:00:33 +0000

I reviewed the document, the changes from -07 to -08 are ok with me.

I sent a separate email for the topic "Updated clarification for rtp-mapping
ClientID". I think this discussion about my proposed clarification still
needs to be resolved. I haven't heard from Roni or Jonathan yet about this
latest proposal.

There is a minor problem in the formatting of the packet format diagrams in
sections 5.1 and 5.2. The bit numbers don't line up right at the top of the
diagrams. And the vertical bars separating fields are off by a space or two.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, September 23, 2016 11:01 AM
> To: CLUE <[email-masked]>
> Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-08
> 
> 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.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Oct 2016 15:22:12 -0400

The WGLC has ended. By now I *think* Roni should be back from vacation. 
There were some substantial comments. I request that the authors sort 
out what they want to do about those. I think we will need another revision.

	Thanks,
	Paul

On 9/23/16 11:00 AM, Paul Kyzivat wrote:
> the discussion that has already taken place on -08 to motivate your review.
>
>     Thanks,
>     Paul
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 21 Oct 2016 10:52:41 +0300

Hi Colin,
Thanks for the review, see inline
Roni

> From: clue [mailto:[email-masked]] 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
> 
> > 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.
> >
> 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: 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”
[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
[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/
> 
> 
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Oct 2016 15:31:35 +0100

Hi Roni,

Thanks for the response - some comments inline.
Colin

> On 21 Oct 2016, at 08:52, Roni Even <[email-masked]> wrote:
> 
> Hi Colin,
> [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.

It shouldn’t try to describe the topologies, though, since that’s the intent of RFC 7667. This draft should just say what topologies are used, and list anything CLUE-specific about the use of those topologies. 

> As for SFM we felt that we need some text since the RFC7667 was not clear enough.

In a CLUE-specific way, or generally? If the latter, it belongs in another draft.

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

Thanks.

> [Roni Even] OK, will change the text as you suggested

Thanks.

> [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 Jo…

Okay.

> [Roni Even] It is the CLUE me4dia capture as stated in 5.1

But Section 5.1 doesn’t give the syntax of the CaptureId.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 21 Oct 2016 18:17:06 +0000

>From Colin and Roni's discussion:

> >> - Section 5: what’s the syntax of the CaptureId (whether sent in RTCP
> SDES or
> >> hdr ext)?

Should it say something like the CaptureId is a string in UTF-8 format? I think that is what the data model says, regarding the XML representation.

Mark

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 21 Oct 2016 18:24:22 +0000

On Oct 21, 2016, at 2:17 PM, Duckworth, Mark <[email-masked]<mailto:[email-masked]>> wrote:

In my next revision I’ve added text

   This CaptureID is a variable-length UTF-8 string corresponding either to a CaptureID negotiated in the CLUE protocol, or the single character "-".

I’ve also added a reference to the data model schema document, where it’s defined.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Oct 2016 11:55:14 +0100

> On 21 Oct 2016, at 19:24, Jonathan Lennox <[email-masked]> wrote:
> 
> 
>> On Oct 21, 2016, at 2:17 PM, Duckworth, Mark <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Makes sense.

-- 
Colin Perkins
https://csperkins.org/