Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt

From: Christian Groves <[email-masked]>
Date: Wed, 2 Nov 2016 02:31:55 +1100

Hello Paul,

+1

Regards, Christian

On 29/10/2016 8:03 AM, Duckworth, Mark wrote:
> Okay, for the record, the changes in the -09 version still look good to me.
> Mark
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email-masked]]
>> Sent: Friday, October 28, 2016 1:51 PM
>> To: [email-masked]
>> Cc: Colin Perkins <[email-masked]>; Christian Groves
>> <[email-masked]>; Duckworth, Mark
>> <[email-masked]>
>> Subject: WGLC for draft-ietf-clue-rtp-mapping-09.txt
>>
>> This announced the start of another WGLC on the rtp-mapping document,
>> this time draft-ietf-clue-rtp-mapping-09.txt.
>>
>> This will be a short one - one week. It will end Friday, November 4.
>>
>> I especially want to hear from the people who had issues with -08: Mark
>> Duckworth, Christian Groves, and Colin Perkins. But not just them.
>> Please, everyone who worked on CLUE please respond. This will impact the
>> level of support for the document that I can report in the shepherd
> writeup.
>> See below for more on why I'm calling for wglc *again*.
>>
>> 	Thanks,
>> 	Paul
>>
>> On 10/28/16 1:03 PM, Colin Perkins wrote:
>>>> On 28 Oct 2016, at 17:58, Paul Kyzivat <[email-masked]> wrote:
>>>>
>>>> On 10/28/16 10:56 AM, Colin Perkins wrote:
>>>>> And as I said before, you need to wait for confirmation from that who
>> commented that the changes address their concerns.
>>>> I checked the email discussion history. After -08 the non-author people
>> who commented were me, Mark, and Christian.
>>>> Since -09 Mark has confirmed that he is satisfied with it. I am also
> satisfied.
>> So if we hear from Christian then I think we will be good in this regard.
> (I
>> presume the authors are ok with this.)
>>> I also sent extensive comments on -08 on 7 October, and have yet to have
>> chance to review whether they were addressed in -09.
>>> Why this rush to publish, without giving the working group chance to
>> review? You should be issuing a new working group last call, since there
> were
>> substantive technical comments on the last version.
>>
>> My impression is that people are tired of this and want it over. And
>> there seem to be only a small set of participants at this time.
>>
>> But, since you have asked, I'm hereby doing so.
>>
>> 	Thanks,
>> 	Paul
>>
>>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Nov 2016 20:09:54 +0000

Paul,

I’m sorry, but I still don’t think this draft is ready for publication. I have the following comments:

- Section 2: The draft says that the RFC 2119 keywords “indicate requirement levels for compliant RTP implementations”. This is incorrect. They might indicate requirements for “compliant CLUE implementations”, or perhaps for “RTP processing in compliant CLUE implementations”, but they cannot apply to RTP implementations in general.

- Section 3, 4th and 5th paragraphs: The attempts to briefly summarise the detailed descriptions from RFC 7667 confuse more than they help. Since there is nothing CLUE specific here, these paragraphs can be removed. The first paragraph of Section 3 says that these topologies can be used with CLUE, which is all that’s needed. 

- Section 4, 2nd paragraph, says “can send each media source in a separate RTP session identified by the content attribute”, but the content attribute does not identify the RTP session, it identifies the role of that RTP session in the CLUE context. It should perhaps say something like “…in a separate RTP session, with a content attribute [RFC4796] identifying the CLUE Capture Encoding represented by that RTP session”?

- Section 4, 2nd paragraph: “Demultipexing at the media receiver is straightforward if the multiplexing point is at the UDP transport level, where each RTP stream uses a separate RTP session” — it’s not clear what is being demultiplexed, since RTP streams don’t use RTP sessions. Is the intent to say something like “Demultiplexing is straightforward because each media capture is sent as a single RTP stream, with each RTP stream being sent in a separate RTP session, on a distinct UDP 5-tuple”?

- Section 4, 2nd paragraph: “the mapping does not change even if the RTP session is switched using same or different SSRC” – what does this mean? An RTP session doesn’t have an SSRC; it contains RTP streams that are identified by SSRC. Accordingly, it doesn’t make sense to talk about RTP sessions being switched by SSRC.

- Section 4, 3rd paragraph: “CLUE endpoints that support sending of several RTP streams in a single or multiple RTP sessions MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation]” – I don’t understand why BUNDLE would be used with multiple RTP sessions? 

- Section 4, 3rd paragraph: This is hard to follow in general, and I suggest trying to reword it. Maybe: “Each Capture Encoding MUST be sent as a separate RTP stream. CLUE endpoints MUST support sending each such RTP stream in a separate RTP session signalled by an SDP m= line. They MAY also support sending all the RTP streams in a single RTP session, using the mechanism described in [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m= lines.”

- Section 5, 1st paragraph: I suggest changing “mapping from the MCC RTP stream to the constituent MC” to “mapping from the SSRC of the RTP stream conveying a particular MCC to…” to make the layering clear.

- Section 5, 2nd paragraph: Similarly, I suggest changing “associates the SSRC of the MCC stream with the captureID” to “associates the SSRC of the RTP stream conveying a particular MCC with…”.

- Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the RTP Header, it’s sent in an RTP Header Extension. Similarly, the CaptureID is not sent in an “RTCP SDES message”, it’s sent in an “RTCP CaptureID SDES item”. 

- Section 5, 4th paragraph: “giving source information for these CSRC values” is not quite correct. It would be clearer written “giving source information for the SSRC values sent as contributing sources (CSRCs)”.

- Section 5, 5th paragraph: “interprets this as meaning any previous captureID value in this RTP header no longer applies” would be more correct if written “interprets this as meaning that any previous CaptureID value associated with this SSRC no longer applies”. 

- Section 5.1, last paragraph: “SDES message” -> “SDES item”. Also, SDES items are not “sent in a compound RTCP packet”, they’re “sent in an SDES packet within a compound RTCP packet”. 

- Section 5.1, last paragraph: Need to explain what happens if Reduced-size RTCP has been negotiated, possibly by adding “, in which case it can be sent as an SDES packet in a non-compound RTCP packet” to the end of the paragraph.

- Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be “urn:ietf:params:rtp-hdrext:sdes:CaptureID” not “urn:ietf:params:rtp-hdrext:sdes:CaptureID”. 

- Section 5.2: The packet diagrams don’t match those in RFC 7941. I suggest that the copy here be removed.

Colin

> On 28 Oct 2016, at 18:50, Paul Kyzivat <[email-masked]> wrote:
> 
> This announced the start of another WGLC on the rtp-mapping document, this time draft-ietf-clue-rtp-mapping-09.txt.
> 
> I especially want to hear from the people who had issues with -08: Mark Duckworth, Christian Groves, and Colin Perkins. But not just them. Please, everyone who worked on CLUE please respond. This will impact the level of support for the document that I can report in the shepherd writeup.
> 
>>>> And as I said before, you need to wait for confirmation from that who commented that the changes address their concerns.
>>> 
>>> I checked the email discussion history. After -08 the non-author people who commented were me, Mark, and Christian.
>>> 
>>> Since -09 Mark has confirmed that he is satisfied with it. I am also satisfied. So if we hear from Christian then I think we will be good in this regard. (I presume the authors are ok with this.)
>> 
>> I also sent extensive comments on -08 on 7 October, and have yet to have chance to review whether they were addressed in -09.
>> 
>> Why this rush to publish, without giving the working group chance to review? You should be issuing a new working group last call, since there were substantive technical comments on the last version.
> 
> My impression is that people are tired of this and want it over. And there seem to be only a small set of participants at this time.
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Nov 2016 20:12:34 +0000

> On 2 Nov 2016, at 20:09, Colin Perkins <[email-masked]> wrote:
> 
> Paul,
> 

This should, of course, read ‘not “urn:ietf:params:rtp-hdrext:CaptureID”’.

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

---

From: "Roni Even" <[email-masked]>
Date: Wed, 2 Nov 2016 23:47:13 +0200

Colin,
Thanks for the review
Inline
Roni

> From: clue [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Wednesday, November 02, 2016 10:13 PM
> To: Paul Kyzivat
> Cc: CLUE
> Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt
> 
> 
> > I'm sorry, but I still don't think this draft is ready for publication.
I have the
> following comments:
> >
> > - Section 2: The draft says that the RFC 2119 keywords "indicate
> requirement levels for compliant RTP implementations". This is incorrect.
> They might indicate requirements for "compliant CLUE implementations", or
> perhaps for "RTP processing in compliant CLUE implementations", but they
> cannot apply to RTP implementations in general.
[Roni Even] OK
> >
> > - Section 3, 4th and 5th paragraphs: The attempts to briefly summarise
the
> detailed descriptions from RFC 7667 confuse more than they help. Since
> there is nothing CLUE specific here, these paragraphs can be removed. The
> first paragraph of Section 3 says that these topologies can be used with
> CLUE, which is all that's needed.
[Roni Even] I can delete these paragraphs, I assume that you suggest they
are not needed since they do not have any CLUE specific content. 
> >
> > - Section 4, 2nd paragraph, says "can send each media source in a
separate
> RTP session identified by the content attribute", but the content
attribute
> does not identify the RTP session, it identifies the role of that RTP
session in
> the CLUE context. It should perhaps say something like ".in a separate RTP
> session, with a content attribute [RFC4796] identifying the CLUE Capture
> Encoding represented by that RTP session"?
[Roni Even] OK
> >
> > - Section 4, 2nd paragraph: "Demultipexing at the media receiver is
> straightforward if the multiplexing point is at the UDP transport level,
where
> each RTP stream uses a separate RTP session" - it's not clear what is
being
> demultiplexed, since RTP streams don't use RTP sessions. Is the intent to
say
> something like "Demultiplexing is straightforward because each media
> capture is sent as a single RTP stream, with each RTP stream being sent in
a
> separate RTP session, on a distinct UDP 5-tuple"?
[Roni Even] OK
> >
> > - Section 4, 2nd paragraph: "the mapping does not change even if the RTP
> session is switched using same or different SSRC" - what does this mean?
An
> RTP session doesn't have an SSRC; it contains RTP streams that are
identified
> by SSRC. Accordingly, it doesn't make sense to talk about RTP sessions
being
> switched by SSRC.
[Roni Even] OK will change the language
> >
> > - Section 4, 3rd paragraph: "CLUE endpoints that support sending of
> several RTP streams in a single or multiple RTP sessions MUST support [I-
> D.ietf-mmusic-sdp-bundle-negotiation]" - I don't understand why BUNDLE
> would be used with multiple RTP sessions?
[Roni Even] there can be for example two RTP sessions each of them is using
bundle to multiplex multiple RTP streams
> >
> > - Section 4, 3rd paragraph: This is hard to follow in general, and I
suggest
> trying to reword it. Maybe: "Each Capture Encoding MUST be sent as a
> separate RTP stream. CLUE endpoints MUST support sending each such RTP
> stream in a separate RTP session signalled by an SDP m= line. They MAY
also
> support sending all the RTP streams in a single RTP session, using the
> mechanism described in [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate
> RTP streams to SDP m= lines."
[Roni Even] OK but also see my previous response about a single RTP session
> >
> > - Section 5, 1st paragraph: I suggest changing "mapping from the MCC RTP
> stream to the constituent MC" to "mapping from the SSRC of the RTP stream
> conveying a particular MCC to." to make the layering clear.
[Roni Even] OK
> >
> > - Section 5, 2nd paragraph: Similarly, I suggest changing "associates
the
> SSRC of the MCC stream with the captureID" to "associates the SSRC of the
> RTP stream conveying a particular MCC with.".
[Roni Even] OK
> >
> > - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the
RTP
> Header, it's sent in an RTP Header Extension. Similarly, the CaptureID is
not
> sent in an "RTCP SDES message", it's sent in an "RTCP CaptureID SDES
item".
[Roni Even] OK
> >
> > - Section 5, 4th paragraph: "giving source information for these CSRC
> values" is not quite correct. It would be clearer written "giving source
> information for the SSRC values sent as contributing sources (CSRCs)".
[Roni Even] OK
> >
> > - Section 5, 5th paragraph: "interprets this as meaning any previous
> captureID value in this RTP header no longer applies" would be more
correct
> if written "interprets this as meaning that any previous CaptureID value
> associated with this SSRC no longer applies".
[Roni Even] OK
> >
> > - Section 5.1, last paragraph: "SDES message" -> "SDES item". Also, SDES
> items are not "sent in a compound RTCP packet", they're "sent in an SDES
> packet within a compound RTCP packet".
[Roni Even] OK
> >
> > - Section 5.1, last paragraph: Need to explain what happens if
Reduced-size
> RTCP has been negotiated, possibly by adding ", in which case it can be
sent
> as an SDES packet in a non-compound RTCP packet" to the end of the
> paragraph.
[Roni Even] OK
> >
> > - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be
> "urn:ietf:params:rtp-hdrext:sdes:CaptureID" not "urn:ietf:params:rtp-
> hdrext:sdes:CaptureID".
[Roni Even]OK
> 
> This should, of course, read 'not "urn:ietf:params:rtp-hdrext:CaptureID"'.
> 
> > - Section 5.2: The packet diagrams don't match those in RFC 7941. I
> suggest that the copy here be removed.
[Roni Even] OK can remove the diagrams since anyhow it is missing text which
is in RFC5285 and RFC7941
> Duckworth, Christian Groves, and Colin Perkins. But not just them. Please,
> everyone who worked on CLUE please respond. This will impact the level of
> support for the document that I can report in the shepherd writeup.
> >>
> satisfied. So if we hear from Christian then I think we will be good in
this
> regard. (I presume the authors are ok with this.)
> >>>
> >>> I also sent extensive comments on -08 on 7 October, and have yet to
> have chance to review whether they were addressed in -09.
> >>>
were
> >> My impression is that people are tired of this and want it over. And
there
> seem to be only a small set of participants at this time.
> >>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Nov 2016 22:27:11 +0000

Hi Roni,

[inline]

> On 2 Nov 2016, at 21:47, Roni Even <[email-masked]> wrote:
> 
> Colin,
> Thanks for the review
> Inline
> Roni
> 
>>> I’m sorry, but I still don't think this draft is ready for publication. I have the following comments:
>>> 
>>> - Section 2: The draft says that the RFC 2119 keywords “indicate requirement levels for compliant RTP implementations". This is incorrect. They might indicate requirements for “compliant CLUE implementations”, or perhaps for "RTP processing in compliant CLUE implementations", but they cannot apply to RTP implementations in general.
> [Roni Even] OK
>>> 

Yes.

>>> - Section 4, 2nd paragraph, says “can send each media source in a separate RTP session identified by the content attribute”, but the content attribute does not identify the RTP session, it identifies the role of that RTP session in the CLUE context. It should perhaps say something like “.in a separate RTP session, with a content attribute [RFC4796] identifying the CLUE Capture Encoding represented by that RTP session”?
> [Roni Even] OK
>>> 
>>> - Section 4, 2nd paragraph: “Demultipexing at the media receiver is straightforward if the multiplexing point is at the UDP transport level, where each RTP stream uses a separate RTP session” - it’s not clear what is being demultiplexed, since RTP streams don’t use RTP sessions. Is the intent to say something like “Demultiplexing is straightforward because each media capture is sent as a single RTP stream, with each RTP stream being sent in a separate RTP session, on a distinct UDP 5-tuple”?
> [Roni Even] OK
>>> 
>>> - Section 4, 2nd paragraph: “the mapping does not change even if the RTP session is switched using same or different SSRC” - what does this mean? An RTP session doesn’t have an SSRC; it contains RTP streams that are identified by SSRC. Accordingly, it doesn’t make sense to talk about RTP sessions being switched by SSRC.
>>> - Section 4, 3rd paragraph: “CLUE endpoints that support sending of several RTP streams in a single or multiple RTP sessions MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation]” - I don't understand why BUNDLE would be used with multiple RTP sessions?

Okay, but that’s not clear from the text.

> [Roni Even] OK but also see my previous response about a single RTP session

Could maybe change “MAY also support sending all the RTP streams in a single RTP session” to “…sending some or all of the RTP streams…”?

>>> - Section 5, 1st paragraph: I suggest changing “mapping from the MCC RTP stream to the constituent MC” to "mapping from the SSRC of the RTP stream conveying a particular MCC to." to make the layering clear.
> [Roni Even] OK
>>> 
>>> - Section 5, 2nd paragraph: Similarly, I suggest changing “associates the SSRC of the MCC stream with the captureID” to “associates the SSRC of the RTP stream conveying a particular MCC with.".
> [Roni Even] OK
>>> 
>>> - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the RTP Header, it’s sent in an RTP Header Extension. Similarly, the CaptureID is not sent in an “RTCP SDES message”, it's sent in an "RTCP CaptureID SDES item".
> [Roni Even] OK
>>> 
>>> - Section 5, 4th paragraph: “giving source information for these CSRC values" is not quite correct. It would be clearer written “giving source information for the SSRC values sent as contributing sources (CSRCs)".
> [Roni Even] OK
>>> 
>>> - Section 5.1, last paragraph: "SDES message" -> "SDES item". Also, SDES items are not “sent in a compound RTCP packet”, they're "sent in an SDES packet within a compound RTCP packet".
> [Roni Even] OK
>>> 
>>> - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be “urn:ietf:params:rtp-hdrext:sdes:CaptureID” not "urn:ietf:params:rtp- hdrext:CaptureID".
> [Roni Even]OK
>> 

Thanks,
Colin

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Nov 2016 18:59:07 -0400

> I’m sorry, but I still don’t think this draft is ready for publication. I have the following comments:

OK, this is WGLC, and these are WGLC comments.

Lets hear what the authors have to say on them.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 Nov 2016 14:38:24 -0400

Today is the end of the WGLC on this document. If you haven't commented 
yet and want to, speak now or forget it.

The only comments requiring attention have come in have been from Colin. 
It looks like these can be addressed easily. Does anyone think we need 
yet another WGLC after these have been addressed?

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 4 Nov 2016 19:07:30 +0000

I also agree with Colin's suggestions for clarifying section 5.
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Wednesday, November 02, 2016 5:47 PM
> To: 'Colin Perkins' <[email-masked]>; 'Paul Kyzivat'
> <[email-masked]>
> Cc: 'CLUE' <[email-masked]>

 ... snip...