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

"Ben Campbell" <ben@nostrum.com> Wed, 11 November 2015 21:46 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 0DC1C1A8A0B; Wed, 11 Nov 2015 13:46:01 -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 uWGBbtFSmhXh; Wed, 11 Nov 2015 13:46:00 -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 0748B1A890C; Wed, 11 Nov 2015 13:45:59 -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 tABLjt1v001538 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Nov 2015 15:45:55 -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:45:55 -0600
Message-ID: <B4A328E6-B151-40D3-860F-798C39D9D85B@nostrum.com>
In-Reply-To: <3BCEAADB-B64E-43C9-918E-5D87781F7CB9@csperkins.org>
References: <C22EBF77-96B4-4594-BBAE-0E7865B4E7C3@nostrum.com> <3BCEAADB-B64E-43C9-918E-5D87781F7CB9@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/1D0TiwiJ92Av5hysQgPNbkv615w>
Cc: draft-ietf-avtcore-rtp-multi-stream.all@ietf.org, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-multi-stream-09
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:46:01 -0000

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

> Hi,
>
> Thanks for the review, some responses line. Since this has gone to 
> IETF last call, I assume these should be treated as last call 
> comments, and an update submitted after the last call period ends.

That is my preference. You can treat these as last call comments.

>
> Colin
>
>
>
>> On 9 Nov 2015, at 21:29, Ben Campbell <ben@nostrum.com> wrote:
>>
>> Hi,
>>
>> Here is my AD evaluation of draft-ietf-avtcore-rtp-multi-stream-09:
>>
>> Thanks!
>>
>> Ben.
>>
>>
>> Substantive Comments:
>> =====================
>>
>> - 3.3, last paragraph: "The endpoint MUST keep its total media 
>> sending rate within
>> this share."
>>
>> Does that need to be a 2119 "MUST"? Does it create a new normative 
>> requirement, or restate an existing requirement?
>
> (4, 2nd paragraph) It’s restating an existing requirement, so could 
> perhaps be changed to “needs to”?

That works for me.

>
>> - 5: " ... the specification MUST be interpreted as each SSRC 
>> counting as a separate participant ..."
>>
>> Does that really need to be a 2119 MUST? If so, please consider 
>> avoiding a word so open to interpretation as “interpreted".
>
> This does need to be an RFC 2119 “MUST”. Maybe “for correct 
> operation in cases where endpoints have multiple SSRC values, 
> implementations MUST treat each SSRC as a separate participant in the 
> RTP session” would be clearer?

Yes, thanks.

>
>> - 5.2, Note: "... based on an TCP initial window of 4 packets, not 
>> the larger TCP initial windows..."
>>
>> I assume this means that you borrowed the window size from tcp, not 
>> that this mechanism actually uses or requires tcp, right? “Based on 
>> TCP” is a bit confusing.
>
> Right. Could change to “The above is chosen to match the TCP initial 
> window…”?

WFM.

[...]