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

Ben Campbell <ben@nostrum.com> Mon, 02 October 2017 21:28 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0AA551348D8; Mon, 2 Oct 2017 14:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j8uFEPEEYmw1; Mon, 2 Oct 2017 14:28:13 -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 413F21348D6; Mon, 2 Oct 2017 14:28:10 -0700 (PDT)
Received: from [] (cpe-66-25-7-22.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v92LS879000827 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 Oct 2017 16:28:09 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [] claimed to be []
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_0AA2513A-9F3C-499D-9657-61A48E9A88B4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <99303AB6-D5EE-44EC-B515-DCB7966DADA6@nostrum.com>
Date: Mon, 2 Oct 2017 16:28:07 -0500
To: draft-ietf-xrblock-rtcweb-rtcp-xr-metrics.all@ietf.org, xrblock@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xrblock/pKAGOeHlo_v6vbQXKlZuCDpFQ8E>
Subject: [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: Mon, 02 Oct 2017 21:28:15 -0000


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.




- 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.

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.

- 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.”

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.)

-2: If this document keeps the normative keywords, please use the updated boilerplate from RFC 8174. (I note that there are at least some uncapitalized “may”s that do not seem normative.)

- 5.2.2, last paragraph: “The following metrics can also be considered…”
Be considered by whom? Implementors? API designers?

- 6, first paragraph: “In practice the application MUST be able to query the statistic identifiers on both an incoming (remote) and outgoing (local) media stream.”
What does the MUST requirement apply to? The WebRTC API? This seems more like a statement of fact that “ the application needs to be able…”

-8: "Therefore encryption procedures, such as the ones suggested for a Secure RTCP (SRTCP), need to be used.”
The text should describe the reasons encryption is needed. Also, is this a new normative requirement, or a restatement of an existing requirement?


-1, paragraph 1:" If sufficient information (metrics or statistics) are provided to the applications, it can attempt to improve the media quality. “

s / “are provided” / “is provided”
s / applications / application

-3, 2nd paragraph: It would help to clarify that the references to section 5 and 6 are to this document, not RFC 3611.

— 3rd paragraph: "At the moment…”
Please clarify that is at the time of writing (not reading)

-5, 2nd paragraph: “ Application impact metrics mainly collect the information in the viewpoint of application … “
s / in / from
Also, please expand “FEC” on first mention.

- 5.1.1, first paragraph: “ Duplicate packets may be a result of network delays, which causes the sender to retransmit the original packets.”
s/ :delays, which” / “delays that”

— last paragraph: "For those RTCWEB services with jitter buffer…”

- 5.1.2, first paragraph:
First sentence is a comma splice.
 — “some transitory nature of the impairments”
Should this say “the transitory nature of some impairments”?
— “ Distributed burst provides a higher subjective quality”
“Burst distribution …”?
— Last paragraph: “ Hence, if WebRTC application”
Missing article (or should application be plural?)

- 5.2.1, title: Should “Discard” be “Discarded”?

-7: Please clarify that this is at the time of this writing.