Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 3 Jun 2016 07:49:01 -0700

I reviewed the changes, it looks good. I support this going forward.

Mark

From: clue [mailto:[email-masked]] On Behalf Of Daniel Burnett
Sent: Saturday, May 21, 2016 4:21 PM
To: [email-masked]
Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June

This message announces the start of a 2 week WGLC for 
draft-ietf-clue-rtp-mapping to review the updated draft. The last call will 
end at midnight on Saturday, 4 June 2016.

PLEASE REVIEW NOW.

-- Dan (for the Chairs)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Jun 2016 12:39:33 -0400

On 5/21/16 4:20 PM, Daniel Burnett wrote:
> draft-ietf-clue-rtp-mapping to review the updated draft. The last call
> will end at midnight on Saturday, 4 June 2016.
>
> PLEASE REVIEW NOW.

Its been a long time since I read this document all the way through, so 
I just did so.

Note that I am far from an RTP expert, so my qualifications for 
reviewing this document are limited. The following covers mostly stuff 
that doesn't require too much understanding of RTP.

All of the following seem to be to be "quick fix" things. Aside from 
these I think the document is ready to go.

* Section 4:

The 2nd to last paragraph begins with "isAlternately". Clearly the "is" 
needs to be removed.

* Section 4.1:

The sentence "[I-D.ietf-mmusic-sdp-bundle-negotiation] how to associate 
a received RTP stream with the m-line describing it." doesn't parse. It 
is missing a word. I think "specifies" should be inserted prior to "how 
to associate".

Then, in "The assumption in the work is that...", it isn't clear what 
"the work" refers to. Is it CLUE, or BUNDLE? I think it means CLUE. So 
perhaps change to "The assumption in CLUE is that...".

I'll also note that "[I-D.ietf-mmusic-sdp-bundle-negotiation]" is rather 
unwieldy to read. It would be helpful to change the references to 
something more concise, such as [BUNDLE]. (xml2rfc supports this.)

The following one-sentence paragraph:

    SDP Source attribute [RFC5576] mechanisms to describe specific
    attributes of RTP sources based on their SSRC.

isn't a complete sentence. I don't have a particular fix to suggest.

Then the sentence:

    The recommended support of the simulcast case is to use
    [I-D.ietf-mmusic-sdp-simulcast]

needs a period at the end.

* Section 4.2:

The intro to this section:

    This section lists, more briefly, the requirements a media
    architecture for Clue telepresence needs to achieve, summarizing the
    discussion of previous sections.

doesn't seem appropriate now that the work done. Also, I don't think it 
really summarizes discussion in prior sections. Perhaps something like 
the following would be better:

"This section lists the CLUE media requirements that guided the 
development of this RTP mapping document."

* Section 4.5:

    The recommendation is that CLUE endpoints using SSRC multiplexing
    MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation] and use the SDP
    mid attribute for mapping.

I read this as being a bit stronger than I think is intended. I think 
the intent is that all CLUE endpoints support BUNDLE (for 
interoperability), but that they need not offer it. And they only need 
to use mid when they are using BUNDLE. If they are not using BUNDLE then 
use of mid is optional.

* Section 5:

The statement "The solutions described in this document are believed to 
meet these requirements" seems a bit weak in a completed document. Any 
doubts as to whether the requirements have been met should have been 
raised and resolved now. So can we omit this?

Should all the requirements be listed in this section, with an 
explanation of how each is met?

* Section 9:

Shouldn't there be two things registered here? Both the RTP header 
extension and the RTCP SDES item.

* Nits:

There are a few outdated references.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Jun 2016 21:02:30 +0100

> On 21 May 2016, at 21:20, Daniel Burnett <[email-masked]> wrote:
> 
> This message announces the start of a 2 week WGLC for draft-ietf-clue-rtp-mapping to review the updated draft. The last call will end at midnight on Saturday, 4 June 2016.
> 
> PLEASE REVIEW NOW.

Apologies for the late review. I’ve read this draft, and have a number of comments, mostly from an RTP perspective:

Section 3, paragraph starting “In the Selective Forwarding Middlebox (SFM) [RFC7667] topology”: This paragraph seems inconsistent. It starts by saying “every original source is maintained with an independent RTP identity to every receiver, maintaining separate decoding state“, which suggests each source is passed through as an SSRC, but concludes “[t]he sender may turn the projected sources on and off at any time, depending on which sources it thinks are most relevant for the receiver; this is the primary reason why this topology must act as an RTP mixer”, which (if “the sender” actually means the middlebox) suggests the sources are projected as CSRCs on a stream generated by the middlebox (if “the sender” means the original sender, then I don’t understand the intent).

Section 3, bullet 1 (“The middlebox may either use”): in both cases, should this mandate that the middlebox generates RTCP for the streams it’s distributing?

Section 3, bullet 2 (“The middlebox terminates”): does this need to specify that the middlebox forwards/rewrites RTCP for each source distributed as a CSRC?

Section 4, 2nd paragraph, seems to confuse RTP sessions with signalling contexts. The RTP session is always distinguished by having a shared SSRC/CSRC space. This doesn’t change due to the signalling, although the signalling determines which RTP flows are visible at a particular participant, and hence share an SSRC space and form a single RTP session.

Section 4: what is meant by “session multiplexing” and “SSRC multiplexing”? I strongly suggest avoiding these terms, since they don’t have a clear definition. 

Section 4: what is a static SSRC? Should this be “an SSRC signalled using the a=ssrc: line [RFC 5576]”?

In general, I find Section 4 very difficult to follow, and am not sure I could implement it from the text. It might be easier to read if the review of related documents and requirements are moved to an appendix, and the main text simply gives a statement of what should be done.

Section 4.5: the requirement that endpoints “MUST support and use” BUNDLE and a=mid is vague. What is being bundled, and when? 

Section 4.5: what do middleboxes do? I’m surprised there is no requirement here. 

Section 5: as with section 4, this might be clearer if the requirements for the solution were separated from the discussion of what an implementation has to do.

Section 6: it’s not clear how CaptureId relates to mid, why both are needed, and how this relates to the mechanisms in section 4? I haven’t followed all the details of CLUE, so perhaps this just needs a reference to an appropriate definition/discussion in one of the other documents?

Colin

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 10 Jun 2016 09:27:18 +0300

Hi Paul,
Thanks, see inline
Roni

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, June 03, 2016 7:40 PM
> To: [email-masked]
> Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June
> 
> Its been a long time since I read this document all the way through, so I
just
> did so.
> 
> Note that I am far from an RTP expert, so my qualifications for reviewing
this
> document are limited. The following covers mostly stuff that doesn't
require
> too much understanding of RTP.
> 
> All of the following seem to be to be "quick fix" things. Aside from these
I
> think the document is ready to go.
> 
> * Section 4:
> 
[Roni Even] OK
> 
> * Section 4.1:
> 
> The sentence "[I-D.ietf-mmusic-sdp-bundle-negotiation] how to associate a
> received RTP stream with the m-line describing it." doesn't parse. It is
missing
> a word. I think "specifies" should be inserted prior to "how to
associate".
[Roni Even] OK

> Then, in "The assumption in the work is that...", it isn't clear what "the
work"
> refers to. Is it CLUE, or BUNDLE? I think it means CLUE. So perhaps change
> to "The assumption in CLUE is that...".
[Roni Even] The work is bundle in this case, changed it.
> unwieldy to read. It would be helpful to change the references to
something
> more concise, such as [BUNDLE]. (xml2rfc supports this.)
[Roni Even] This will change to the RFC number.
> isn't a complete sentence. I don't have a particular fix to suggest.
[Roni Even] Added provide mechanisms
> needs a period at the end.
[Roni Even] OK
> doesn't seem appropriate now that the work done. Also, I don't think it
really
> summarizes discussion in prior sections. Perhaps something like the
following
> would be better:
development
> of this RTP mapping document."
[Roni Even] OK
> I read this as being a bit stronger than I think is intended. I think the
intent is
> that all CLUE endpoints support BUNDLE (for interoperability), but that
they
> need not offer it. And they only need to use mid when they are using
> BUNDLE. If they are not using BUNDLE then use of mid is optional.
[Roni Even] I am not sure, what it says is that if when using SSRC
multiplexing it must be done using bundle
> raised and resolved now. So can we omit this?
[Roni Even] I remove "are believed to"
> 
> Should all the requirements be listed in this section, with an explanation
of
> how each is met?
[Roni Even] The section discuss the ones that were discussed and needed
clarifications
> extension and the RTCP SDES item.
[Roni Even] both are there.
> There are a few outdated references.
[Roni Even] Can be done later
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 11 Jun 2016 13:25:29 -0400

Roni,

I've trimmed this to the ones I wanted to follow up on.
All else is fine.

> [Roni Even] This will change to the RFC number.

OK, that didn't dawn on me.

> multiplexing it must be done using bundle

OK, I take it back. I haven't thought about this for awhile and was a 
little muddled.

> [Roni Even] both are there.

Sorry, I didn't look close enough and thought all that text was about 
the captureid.

I think it would be helpful to break these into two subsections so that 
it is very clear that there are two actions called for.

	Thanks,
	Paul