Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-multi-stream-optimisation-08

[Colin Perkins <[e-mail]>]

> On 9 Nov 2015, at 21:48, Ben Campbell <[e-mail]> wrote:
> 
> Hi,
> 
> Here is my AD Evaluation of draft-ietf-avtcore-rtp-multi-stream-optimisation-08:
> 
> Ben.
> 
> -----------
> 
> Substantive Comments:
> =====================
> 
> -3.1, 4th paragraph:
> 
> Is “SHOULD NOT…unless” the actual intent? That means you shouldn’t do it unless that condition occurs, or you have some other good reason and understand the consequences. (as compared to “MUST NOT … unless")

It’s trying to say don’t create a reporting group with only a single local SSRC, unless you expect to add more SSRCs to it later. Suggestions for better phrasing welcome.

> -4.2, 1st paragraph:
> 
> Does this refer to third-party observers? (That is, observers not involved in the signaling of support for rtcp-rgrp?

That’s the most likely example, yes.

> -7.2, reference to RFC3264:
> 
> Should this be a normative reference? I’m not sure 3.6 will make much sense without it.

It’s normative if you use SDP offer/answer, but not for declarative SDP. Happy to move it to a normative reference.

> Editorial Comments:
> ===================
> 
> -3.1, 5th paragraph:
> 
> Option "A" is hard to parse. I suggest:
> 
> “... if another reporting source exists,  have it report on the remote SSRCs that the departing source reported ..."

Okay, although I’m not sure it scans so clearly.

> - 3.2.1, 2nd paragraph:
> 
> Consider active voice for the first sentence, i.e. "This document defines..."
> 
> - 3.2.2, 1st paragraph:
> 
> Consider active voice for the first sentence, i.e. “This document defines..."

Fine.

> - 3.6, 2nd to last paragraph: "... neither agents SHALL use..."
> 
> Please restate as SHALL NOT/MUST NOT.

Is it sufficient to change this to “If the answerer does not wish to use RTCP Reporting Groups, it MUST NOT include the “a=rtcp-rgrp” in the answer.”?

> -4.1, last paragraph: "approximately 8.9"
> 
> That's a rather precise approximation :-)

We like precision :-)

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