Re: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Wed, 24 February 2016 01:31 UTC

Return-Path: <rachel.huang@huawei.com>
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 053F41B3995 for <xrblock@ietfa.amsl.com>; Tue, 23 Feb 2016 17:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 BnDSla5GCKG0 for <xrblock@ietfa.amsl.com>; Tue, 23 Feb 2016 17:31:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D051B39A0 for <xrblock@ietf.org>; Tue, 23 Feb 2016 17:31:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJB56389; Wed, 24 Feb 2016 01:31:42 +0000 (GMT)
Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 24 Feb 2016 01:31:40 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 24 Feb 2016 01:31:39 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Wed, 24 Feb 2016 09:31:34 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Colin Perkins <csp@csperkins.org>
Thread-Topic: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics
Thread-Index: AQHRUzuKeZGHUY+TtEiuIz/VLstENZ8LsZ2AgATmV9CABsz/gIAjOiCw
Date: Wed, 24 Feb 2016 01:31:33 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E862CB@nkgeml513-mbx.china.huawei.com>
References: <C13E5AD5-87FE-4E59-BC2A-CD3C4404BB48@ntt-at.com> <36FCAFB0-AEB8-4230-BA95-2BCB0338D3B6@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB86E80FB7@nkgeml513-mbx.china.huawei.com> <303BACA8-2A89-42C6-8275-D86F11ACAD09@csperkins.org>
In-Reply-To: <303BACA8-2A89-42C6-8275-D86F11ACAD09@csperkins.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.191]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86E862CBnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56CD07FE.00A8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 05dc902cdf5937bf66ee64ecc64fc331
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/LUfT_JhQgzZoyBQzXPqUeErcm9s>
Cc: xrblock <xrblock@ietf.org>
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics
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: Wed, 24 Feb 2016 01:31:56 -0000

Hi Colin,

I agree with you.   We’ll take into account and bring a new version to address them.

BR,
Rachel

From: Colin Perkins [mailto:csp@csperkins.org]
Sent: Tuesday, February 02, 2016 7:32 AM
To: Huangyihong (Rachel)
Cc: Shida Schubert; xrblock
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics

Hi,

Some replies inline.
Colin


On 28 Jan 2016, at 09:13, Huangyihong (Rachel) <rachel.huang@huawei.com<mailto:rachel.huang@huawei.com>> wrote:

Hi Colin,

Thank you for your comments. Please see inline.

BR,
Rachel

From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin Perkins
Sent: Monday, January 25, 2016 8:51 PM
To: Shida Schubert
Cc: xrblock
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics

On 20 Jan 2016, at 04:31, Shida Schubert <shida@ntt-at.com<mailto:shida@ntt-at.com>> wrote:

This message starts a Working Group Last Call for the draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02.txt.

http://tools.ietf.org/id/draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02.txt

Even if you have no questions, comments or concern, if you have read the draft and agree that it’s ready for submission to IESG as a Standard Track, please send a message to the list indicating this.

Obviously if you have any issues or questions please submit it to the list, if you are highlighting issues suggestions to fix the issues is always helpful.

I have two comments:

1)  The draft uses RFC 2119 terms in lower case in a number of places. I think it would be clearer if these were changed to upper case where the intent is to use normative language, and rephrased to use alternative terms otherwise.

[Rachel]: Okay. I agree. Some “should” and “should not” can be changed to upper case. But not each type of metrics has the RFC2119 terms. I’m wondering if it’s okay to have some of them to use  normative language while others not?

[CSP]: Yes, that’s certainly okay. I’m not suggesting that all of these become normative statement. Rather, to avoid confusion, you should change those that are supposed to be normative RFC 2119 terms to upper case, and change those that are not supposed to be normative RFC 2119 terms to use different wording.


2)  The draft has a reasonable list of candidate metrics, but does not make a clear recommendation which metrics ought to be implemented. Is the intent that a WebRTC end-point implementor picks an arbitrary subset of these, or that all the metrics are implemented? If a subset is to be implemented, which subset? What are the most important to implement? Adding some further normative language would probably help clarify.

[Rachel]: I think these metrics are all considered optional, and could be picked by implementations based on their own requirements, for example, some of them may need to accurately distinguish loss and discard to evaluate the transport performance, some of them may require to evaluate the performance after concealment…

[CSP]: That’s fine, but if all metrics are OPTIONAL, then the draft needs to say that explicitly. At present, it lists the metrics, but I didn’t find any normative statement about which are to be implemented.


That said, I have no objection to sending this draft to the IESG for publication. It suggests a reasonable set of metrics, and is well enough written.

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