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

Colin Perkins <> Mon, 01 February 2016 23:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E8CD41B38B5 for <>; Mon, 1 Feb 2016 15:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KJcN5v3skNS2 for <>; Mon, 1 Feb 2016 15:32:51 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 3D4C81B38B0 for <>; Mon, 1 Feb 2016 15:32:51 -0800 (PST)
Received: from [] (port=43247 helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1aQNxa-0003VT-7i; Mon, 01 Feb 2016 23:32:45 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC84A84D-4A6F-468D-9730-C53F3B108E3C"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 1 Feb 2016 23:32:07 +0000
Message-Id: <>
References: <> <> <>
To: "Huangyihong (Rachel)" <>
X-Mailer: Apple Mail (2.3112)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <>
Cc: xrblock <>
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Feb 2016 23:32:54 -0000


Some replies inline.

> On 28 Jan 2016, at 09:13, Huangyihong (Rachel) <> wrote:
> Hi Colin,
> Thank you for your comments. Please see inline.
> BR,
> Rachel
> From: xrblock [ <>] 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 < <>> wrote:
> This message starts a Working Group Last Call for the 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
> <>