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:42 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 23A981A90B9 for <xrblock@ietfa.amsl.com>; Fri, 28 Aug 2015 02:42:48 -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 cagz6ikEl3VE for <xrblock@ietfa.amsl.com>; Fri, 28 Aug 2015 02:42:46 -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 28D631A1A9B for <xrblock@ietf.org>; Fri, 28 Aug 2015 02:42:46 -0700 (PDT)
Received: from [79.78.85.92] (port=58221 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 1ZVGBE-0003mx-Jr; Fri, 28 Aug 2015 10:42:42 +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: <51E6A56BD6A85142B9D172C87FC3ABBB863E248C@nkgeml501-mbs.china.huawei.com>
Date: Fri, 28 Aug 2015 10:42:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <535EBE8C-3BBC-4483-886C-0181D131E9DE@csperkins.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA5CAF9F10@AZ-FFEXMB04.global.avaya.com> <B299A3C4-8D59-4C8A-B040-9047D130B486@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB863E23CF@nkgeml501-mbs.china.huawei.com> <0C26CEE4-400F-4ECE-8A8E-12D5EEC6C987@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB863E248C@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/4xHVxqkBHoAONoniQaEe3v1kePg>
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:42:48 -0000

Rachel,

Works for me.
Colin



On 28 Aug 2015, at 10:28, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:

> Hi Colin,
> 
> Your comment makes sense to me. I'll change it to "MUST" to keep it simple, since the metrics may not have so much meanings if reporting period is estimated when the measurement info is not present. What do you think?
> 
> BR,
> Rachel
> 
> 
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp@csperkins.org]
>> Sent: Friday, August 28, 2015 5:05 PM
>> To: Huangyihong (Rachel)
>> Cc: Romascanu, Dan (Dan); xrblock
>> Subject: Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment
>> Metrics Reporting on Video Applications'
>> 
>> 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/
>> 
>> 
>> 
> 



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