Re: [xrblock] AD Evaluation of draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-06
Dan Romascanu <dromasca@gmail.com> Thu, 02 November 2017 12:15 UTC
Return-Path: <dromasca@gmail.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 58EBB13B138; Thu, 2 Nov 2017 05:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 m4DBcbm9ejCo; Thu, 2 Nov 2017 05:15:05 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 3318F13F632; Thu, 2 Nov 2017 05:15:04 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id o187so5999955qke.7; Thu, 02 Nov 2017 05:15:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GnujLEx56IEGRFsbtq8jIB0HSmiIuwUaTHqPADS+LBo=; b=k9xr4zvJ9/N8lB3ybmrev8eN4vqkIGcw4LtKu4x2xa89DumNWpE5hF9kaP/iIEfffa rF8EuQucN+wLy/TFG4VV8nD8d0vBQmX9bZk1MrT2I40Jp8WUIh67Zq4LDjg+Kwy7GjMX WkWcRJtP3JO3J1E+s+NlwjxrRzMVl2ep3bz4SGHHG25e/s2Jt5u34lH2YGJjeimaH7+v KQiiREmsTmYYft6eqlFE+rymERcy5nPBDLmmvERqRZaYGIqB/I0zBgBZfqU/ylZQipem 42ATls7k/S7fLjyJEnf7M5diwtiXX4zymEBLDA3a0qfeZnJwvS9HuZcxHHDJhkHsFXZI JqhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GnujLEx56IEGRFsbtq8jIB0HSmiIuwUaTHqPADS+LBo=; b=t1sBmZiTMdoCnEPuRzxl0BfYtqWlhTQLMzZmZOn46s5zlyHk1WIkzcD8/JdLj61JrQ k219RCgMj0hq2fLa9eMCj/0Du2EVI0p35Dy55y6KTDh7IQs9Do7zYn/jOYA+wOEoCEG0 EB2MTqIp5mnlrRBOopk6HaYBqlqCY+APZ5bibJF/y8pVtAIiVDpD1HXJK8P31rNgPnRP Q4ZF4RdIDOyf/Hcp/aLmGmg6wZbS+qmZLlKD3SUtOGtKV1KHa3ICCqGE3VBeOd2G2mcS MIOXBvai8jyfZdiViM4e5jECwoLF6IuTB5dKnVGjxv+qTnyOFnOG1uHLwpXo82AsvZHS RebQ==
X-Gm-Message-State: AMCzsaUKIWUwMOX3pl3rg5Ptse9570oTS8g2MIC0VEBHnmQo+ZajYZYa 2Yh8ZVPXZGyV/Ezb99UfXoLqKyIX6sIGypdXKZ8=
X-Google-Smtp-Source: ABhQp+QHlp241VY6+JLmJ2a7TXcNfUD+N1mQQURBGk++mMGpfi1yZzmDoM3eHtWdTXRQjG7PQeBWlG3rTuBytkeQGo4=
X-Received: by 10.55.133.65 with SMTP id h62mr4485738qkd.130.1509624903291; Thu, 02 Nov 2017 05:15:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.71 with HTTP; Thu, 2 Nov 2017 05:15:02 -0700 (PDT)
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD82AA98@DGGEMM506-MBS.china.huawei.com>
References: <99303AB6-D5EE-44EC-B515-DCB7966DADA6@nostrum.com> <CACHXSv7E+NhU_dvd63k57RfrVOAPoSFuOK8+-bRwsJTAcZ_ixQ@mail.gmail.com> <17BE8BAC-64E3-4A11-B3F0-C54E3D05244E@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB9C5F8DEE@nkgeml513-mbs.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD82AA98@DGGEMM506-MBS.china.huawei.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 02 Nov 2017 08:15:02 -0400
Message-ID: <CAFgnS4XDBJT6i82wQpC7_i41eQKQgGdpkhpGkhMVtXWKnHFzDg@mail.gmail.com>
To: Roni Even <roni.even@huawei.com>
Cc: "Huangyihong (Rachel)" <rachel.huang@huawei.com>, Ben Campbell <ben@nostrum.com>, 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-Type: multipart/alternative; boundary="94eb2c07d4241ad772055cfef0dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xrblock/iQ9PrqhkmzpUhcMicPsDAPCwUs0>
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, 02 Nov 2017 12:15:08 -0000
I agree. Regards, Dan On Thu, Nov 2, 2017 at 7:25 AM, Roni Even <roni.even@huawei.com> wrote: > Hi > Just to clarify, the individual draft started as an Informational draft > and just before becoming a WG draft it was changed to standard track. We > see no WG decision for this and as Rachel said, Informational is OK > Roni > > > -----Original Message----- > > From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Huangyihong > > (Rachel) > > Sent: יום ה 02 נובמבר 2017 12:01 > > To: Ben Campbell; Varun Singh > > 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, > > > > After discussion among the co-authors, we reached the consensus to make > it > > informational. W3C stats API still refers to it, but in an informational > way. > > We'll submit a new version to address your comments. > > > > BR, > > Rachel > > > > > -----Original Message----- > > > From: Ben Campbell [mailto:ben@nostrum.com] > > > Sent: Friday, October 13, 2017 5:52 AM > > > To: Varun Singh > > > 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 > > > > > > > > > > > On Oct 8, 2017, at 8:11 AM, Varun Singh <varun@callstats.io> wrote: > > > > > > > > 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. > > > > > > To make sure I understand:That API document will reference this one? > > > Do they require that specification to be standards track? > > > > > > Was there discussion in xrblock about standards track verses BCP? > > > > > > > > > > > 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. > > > > > > Is that case already made? That is, does the need for a published RFC > > > still exist? > > > > > > > > > > >> - 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? > > > > > > In general, 2119 keywords are better used when we are talking about > > > interoperability issues in a protocol. I suggest switching to lower > > > case unless there’s some reason to believe the W3C won’t pay attention > > > unless it’s in all-caps. (I don’t think that’s usually the case.) > > > > > > > > > > > co-authors, what do you think? > > > > > > > >> -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.) > > > >> > > > > > > > > depending on the above, we should fix these to uppercase. > > > > > > > >> - 5.2.2, last paragraph: “The following metrics can also be > considered…” > > > >> Be considered by whom? Implementors? API designers? > > > >> > > > > > > > > Both. > > > > > > > >> - 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…” > > > >> > > > > > > > > correct, "needs to" is better. > > > > > > > >> -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? > > > >> > > > > > > > > I believe it is restatement alluding to the guidance in the > > > > corresponding RTCP XRs. > > > > > > > >> Editorial: > > > >> > > > >> -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…” > > > >> s/buffer/buffers > > > >> > > > >> - 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. > > > >> > > > > > > > > Thanks for your feedback and suggestions, we will fix these. > > > > > > > > Regards, > > > > Varun > > > > > > > > > > > > -- > > > > Founder, CEO, callstats.io > > > > http://www.callstats.io > > > > > > > > Interested in networking, media quality, and diagnostics. > > > > We are hiring!: www.callstats.io/jobs/ > > > > _______________________________________________ > > xrblock mailing list > > xrblock@ietf.org > > https://www.ietf.org/mailman/listinfo/xrblock >
- [xrblock] AD Evaluation of draft-ietf-xrblock-rtc… Ben Campbell
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Varun Singh
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Huangyihong (Rachel)
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Ben Campbell
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Ben Campbell
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Huangyihong (Rachel)
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Roni Even
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Dan Romascanu
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Ben Campbell
- Re: [xrblock] AD Evaluation of draft-ietf-xrblock… Varun Singh