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

[Paul Kyzivat <[e-mail]>]

On 5/21/16 4:20 PM, Daniel Burnett 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.

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