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

"Ben Campbell" <ben@nostrum.com> Wed, 11 November 2015 21:59 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3390E1B3AE7; Wed, 11 Nov 2015 13:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXmjpqTkbNsn; Wed, 11 Nov 2015 13:59:10 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6841B3AEC; Wed, 11 Nov 2015 13:59:09 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tABLx6K5003449 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Nov 2015 15:59:06 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: Colin Perkins <csp@csperkins.org>
Date: Wed, 11 Nov 2015 15:59:06 -0600
Message-ID: <C8C9C924-BAFA-4FB5-9BD5-15DE0EC06C42@nostrum.com>
In-Reply-To: <FC3911E7-66E5-414C-A460-9C7F0AEAA2B1@csperkins.org>
References: <0FBEEF14-CA50-4C3A-815F-303F19A060B5@nostrum.com> <FC3911E7-66E5-414C-A460-9C7F0AEAA2B1@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.3r5164)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/eVmXWsjR-opcRSEvwMoAb8GWeFk>
Cc: draft-ietf-avtcore-rtp-multi-stream-optimisation.all@ietf.org, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-multi-stream-optimisation-08
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 21:59:11 -0000

On 11 Nov 2015, at 9:18, Colin Perkins wrote:

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

Two alternatives come to mind. I suspect B is closer to the intent. (And 
I don't think there's a problem with a conditional MUST, as long as the 
conditions are clear and exhaustive.)

a: An endpoint SHOULD NOT create an RTCP reporting group that comprises
    only a single local SSRC (i.e., an RTCP reporting group where the
    reporting source is the only member of the group). One situation 
where and endpoint
    might choose to create a single-SSRC group is when it
    anticipates that the group might have additional SSRCs added to it 
in
    the future.

b: An endpoint MUST NOT create an RTCP reporting group that comprises
    only a single local SSRC (i.e., an RTCP reporting group where the
    reporting source is the only member of the group), unless it is
    anticipated that the group might have additional SSRCs added to it 
in
    the future.


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

Would there ever be situations where it would apply to a first-party 
(i.e., a party involved in the SDP exchange)?

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

Since the draft does talk about the offer/answer case, it seems 
appropriate to do so.

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

Okay, how about: "...have another reporting source, if one exists, 
report on the remote SSRCs the leaving SSRC reported on..."

[...]

>
>> - 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.”?

Even better :-)


[...]