Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'

Colin Perkins <csp@csperkins.org> Fri, 28 August 2015 09:06 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384C21B3015 for <xrblock@ietfa.amsl.com>; Fri, 28 Aug 2015 02:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ATL6IF2saM1n for <xrblock@ietfa.amsl.com>; Fri, 28 Aug 2015 02:05:59 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201771B3036 for <xrblock@ietf.org>; Fri, 28 Aug 2015 02:05:59 -0700 (PDT)
Received: from [79.78.85.92] (port=57970 helo=[192.168.0.7]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1ZVFbX-0005Ab-OL; Fri, 28 Aug 2015 10:05:53 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB863E23CF@nkgeml501-mbs.china.huawei.com>
Date: Fri, 28 Aug 2015 10:05:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C26CEE4-400F-4ECE-8A8E-12D5EEC6C987@csperkins.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA5CAF9F10@AZ-FFEXMB04.global.avaya.com> <B299A3C4-8D59-4C8A-B040-9047D130B486@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB863E23CF@nkgeml501-mbs.china.huawei.com>
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/dwab3NPJU65LopwfkgjGVIQmImY>
Cc: xrblock <xrblock@ietf.org>
Subject: Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2015 09:06:01 -0000

Hi Rachel,

A brief follow-up below...

On 28 Aug 2015, at 03:38, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:
> Hi Colin,
> 
> Thank you for your careful review. Please see some of my replies inline.
> 
> BR,
> Rachel
> 
>> -----Original Message-----
>> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin Perkins
>> Sent: Thursday, August 27, 2015 10:36 PM
>> To: Romascanu, Dan (Dan)
>> Cc: xrblock
>> Subject: Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment
>> Metrics Reporting on Video Applications'
>> 
>> On 13 Aug 2015, at 13:41, Romascanu, Dan (Dan) <dromasca@avaya.com>
>> wrote:
>>> We start a Working Group Last Call for the document 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'. Please let us know if you believe that this document is ready to be submitted to the IESG for consideration as Proposed Standard. Please send your comments, questions and concerns to the WG mail list before September 4, 2015. If you have read the document and you did not find any problems your input is also welcome. If you are aware about any relevant IPR please take the appropriate actions as per RFC 3979.
>>> 
>>> The document is available at https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt.
>> 
>> I think this is generally in good shape, but some of the definitions at the start of
>> section 4 are unclear. Comments follow:
>> 
>> Section 1.1 uses "MUST" before the RFC 2119 terms have been defined.
> 
> [Rachel]: Right. I'll change it to lower-case.
> 
>> Section 4: the first paragraph of this section says twice that a video loss
>> concealment report block SHOULD be sent in the same packet as a
>> Measurement Information Block. It probably only needs to say this once.
> 
> [Rachel]: I'll keep the first one and delete the latter sentence.
> 
>> Section 4: the first paragraph, says that the video loss concealment report
>> block "SHOULD be sent in the same packet as a Measurement Information
>> Block", then says that the video loss concealment report "MUST be discarded"
>> if the measurement period, included in the Measurement Information Block is
>> not present. The later "MUST" seems to contradict the earlier "SHOULD"
>> strength requirement.
> 
> [Rachel]: The first "SHOULD" refers to the sender, while the latter "MUST" refers to the receivers. Maybe I should add some clarifications to this sentence?

No, that's not the problem I had. If you say "SHOULD sent with a measurement info block", that implies that there are some valid reasons why you might not send it with the measurement info. But, you then say "MUST discard if not sent with a measurement info block". If it has to be discarded if the measurement info block is not present, what are the reasons for sending it without the measurement info? Either the "SHOULD be sent" has to change to "MUST be sent", or the "MUST be discarded" has to be relaxed to explain how the reporting period is inferred if the measurement info is not present.

Colin



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