Re: [xrblock] AD Evaluation of draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-06

Ben Campbell <ben@nostrum.com> Thu, 12 October 2017 21:56 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C7A132941; Thu, 12 Oct 2017 14:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eLPAcMB76YSs; Thu, 12 Oct 2017 14:56:17 -0700 (PDT)
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 219771321A0; Thu, 12 Oct 2017 14:56:17 -0700 (PDT)
Received: from [10.0.1.75] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9CLu8T8048458 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Oct 2017 16:56:09 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.75]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Ben Campbell <ben@nostrum.com>
X-Mailer: iPad Mail (15A421)
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C59E3ED@nkgeml513-mbx.china.huawei.com>
Date: Thu, 12 Oct 2017 16:56:08 -0500
Cc: Varun Singh <varun@callstats.io>, "draft-ietf-xrblock-rtcweb-rtcp-xr-metrics.all@ietf.org" <draft-ietf-xrblock-rtcweb-rtcp-xr-metrics.all@ietf.org>, xrblock <xrblock@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F77A95BC-3638-4CFC-8455-CCB1BA61B217@nostrum.com>
References: <99303AB6-D5EE-44EC-B515-DCB7966DADA6@nostrum.com> <CACHXSv7E+NhU_dvd63k57RfrVOAPoSFuOK8+-bRwsJTAcZ_ixQ@mail.gmail.com> <51E6A56BD6A85142B9D172C87FC3ABBB9C59E3ED@nkgeml513-mbx.china.huawei.com>
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/xrblock/6m74J69VYu725z03fdTGCXjXPu8>
Subject: Re: [xrblock] AD Evaluation of draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-06
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 12 Oct 2017 21:56:19 -0000


> On Oct 10, 2017, at 12:56 AM, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:
> 
> Hi
> 
> Please see inline.
> 
> BR,
> Rachel
> 
>> -----Original Message-----
>> From: Varun Singh [mailto:varun@callstats.io]
>> Sent: Sunday, October 08, 2017 9:11 PM
>> To: Ben Campbell
>> Cc: draft-ietf-xrblock-rtcweb-rtcp-xr-metrics.all@ietf.org; xrblock
>> Subject: Re: [xrblock] AD Evaluation of
>> draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-06
>> 
>> Hi Ben,
>> 
>> See inline.
>> 
>>> On Tue, Oct 3, 2017 at 12:28 AM, Ben Campbell <ben@nostrum.com> wrote:
>>> Hi,
>>> 
>>> This is my AD Evaluation of draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-06. I
>> would like to resolve at least the substantive comments prior to IETF LC.
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> —————————
>>> 
>>> Substantive:
>>> 
>>> - General: If I understand correctly, this document lists and describes XR
>> metrics that a WebRTC application might choose to negotiate and expose via
>> the WebRTC API. It does not define any new XR metrics. That brings up two
>> questions:
>>> 
>>> 1) Why is this specific to WebRTC? For the most parts, all the arguments here
>> would apply to any sort of RTP endpoint.
>>> 
>> 
>> This draft was created initially as an input to RTCWEB and later as an input to
>> WebRTC Statistics API. Hence the use of WebRTC in the title and the
>> introduction. We could add to the introduction: "In general, the metrics listed in
>> this document can be exposed by any real-time communications endpoint." Or
>> something along those lines
>> 
>> 
>>> 2) Why is this standards track? This sort of material is typically informational,
>> or occasionally a BCP. There are a small number of 2119 keywords, but I’m not
>> sure they are needed or appropriate. (Specifics below.) My initial instinct is that
>> this should be informational.
>>> 
>> 
>> The reason until recently (perhaps still exist) is that this was an input from the
>> IETF to W3C, I am not sure if there was an official liaison statements sent to
>> them? nonetheless, the W3C Statistics API document needed a specification
>> needed (a specification in any standards body would suffice) for metrics to be
>> accepted into the W3C document.
>> 
>> In practice, it helped that I was the co-author of both the IETF and W3C
>> document and hence was able to make the case for the metrics in W3C.
>> 
>>> - General: This needs an IANA considerations section, even if it just contains
>> the statement to the effect of “This document makes no requests for IANA”.
>>> 
>>> - 1, last paragraph: “ The document also creates a registry containing
>> identifiers from the metrics reported in the RTCP Sender, Receiver, and
>> Extended Reports.”
>> 
>> This should be removed. Thanks for pointing this out.
>> 
>>> 
>>> It doesn’t actually do that. I understand from the shepherd’s report that
>> this was intentionally removed.
>>> 
>>> — “All identifiers proposed in this document are RECOMMENDED to be
>>> implemented by an endpoint.  An endpoint MAY choose not to expose an
>>> identifier if it does not implement the corresponding RTCP Report. “
>>> 
>>> Does the “RECOMMENDED” apply to all endpoints or just WebRTC
>>> endpoints? If the latter, doesn’t that requirement belong (or need to
>>> update) some requirement from an RTCWEB (maybe rtp-usage) document, or
>>> even the API itself? (I suspect that this draft does not have standing
>>> to state this normatively.) What is meant by “MAY choose not to
>>> expose”. Is that talking about via the WebRTC API? If so, isn’t that
>>> up to the API definition? (That is, it shouldn’t be normative here.)
>>> 
>> 
>> It should be applicable to any endpoint, although it is pertinent or timely for the
>> WebRTC endpoint to expose these.
>> The purpose of the statement was to highlight that if the middlebox/endpoint
>> sends RTCP XRs then it should expose the data available via the API.
>> 
>> I am open to changing to a non-normative lower case guidance if that would be
>> more suitable, although if this document is making recommendations to the
>> W3C document -- wouldn't we keep the uppercase?
>> 
>> co-authors, what do you think?
> 
> [Rachel]: The sentences are meant for WebRTC endpoints, but surely, it is applicable to any endpoints. RTP-usage document just describes RTCP SR and RR, and leaves RTCP XR undiscussed. That's also part of the reason why we have this draft. So I think it's better to keep the uppercase. But maybe some modification of the sentences should be made to make it clear that this is making recommendations to webRTC applications. How about
> "
> WebRTC endpoints are RECOMMENDED to implement all the metrics proposed in this document. An endpoint MAY choose not to expose an identifier if it does not implement the corresponding RTCP Report.
> "

My concern is that it can be problematic to add normative requirements to things that already exist without updating those things. Otherwise, implementors may not learn about the new requirements. That is, they may not realize they need to even read this document. 

Would it make sense to ask for a reference to this from rtp-usage?

Ben.