Re: Call for Consensus (CfC): Publish webrtc-stats as updated Candidate Recommendation

We reviewed the CR bugs and came with a smaller set of issues that are
important to us, we are down to 4. We should have this done in a
couple of weeks.


On Thu, Jul 18, 2019 at 4:22 PM Henrik Boström <hbos@google.com> wrote:
>
> We know what we need to do and it's just a matter of doing it, it's a matter of days if it's being worked on. The problem is finding the time to work on it.
>
> On Tue, Jul 16, 2019 at 8:16 PM Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>>
>> If it is a matter of weeks, I would agree. But if it requires review and discussion at TPAC (and subsequent editing) so that it is more like 3+ months then maybe not.
>>
>> Henrik - what do you think?
>>
>> On Jul 16, 2019, at 11:12 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
>>
>> I’m not heavily involved in this anymore. But to me it looks like moving the (per-layer) stats to the correct place, and decide & write up what to do with those meaningless to aggregate should be a matter of weeks. Perhaps it would be better to do that before issuing a new CR (since the move would anyway happen soon-ish I presume, and then a CR issued now would be obsolete even though being relatively fresh). My 5 cents.
>>
>>
>>
>> From: Harald Alvestrand <harald@alvestrand.no>
>> Date: Tuesday, 16 July 2019 at 20:00
>> To: Henrik Boström <hbos@google.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>
>> Cc: Stefan LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
>> Subject: Re: Call for Consensus (CfC): Publish webrtc-stats as updated Candidate Recommendation
>>
>>
>>
>> When we (the chairs) discussed issuing a renewed CR, it was explicitly clear that this is not stable enough for PR yet.
>>
>> We'll likely be issuing another CR before asking for PR.
>>
>>
>>
>> When we discussed the per-layer stats, I felt that there was value in having the (current) aggregated stats, and augumenting them with
>>
>> per-outbound-rtp stats; the exception is those that are really meaningless to aggregate, such as framerate and width/height; those either need to be deprecated (moved to the obsolete section) at the per-sender level or need to be declared as "identical to the highest level sent".
>>
>>
>>
>> On 7/16/19 6:08 PM, Henrik Boström wrote:
>>
>> OK, thanks for the clarification. The current state of the spec is in a better state than the currently published version though.
>>
>>
>>
>> On Tue, Jul 16, 2019 at 5:35 PM Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>>
>> Henrik said:
>>
>>
>>
>> "several metrics are in the wrong place, i.e. to adequately support simulcast some of them need to be moved around so that they can be expressed on a per-layer (per outbound-rtp) rather than per-sender (track) basis."
>>
>>
>>
>> [BA] Candidate Recommendation is supposed to denote "ready for implementation". If we have metrics in the wrong place, wouldn't it be better to move them around now so that when we put out the CR, we can then say "this is how you support stats for simulcast" and move forward on implementation?
>>
>>
>>
>> Stefan said:
>>
>>
>>
>> "But should the “CR blocker” labels be changed to “PR blocker”? "
>>
>>
>>
>> [BA]  The metric move issue above does indeed seem like a "CR blocker".   If there's nothing else that would preclude an implementation push, perhaps we can just remove the "CR blocker" label on other issues that aren't critical for issuing a CR.
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> From: Henrik Boström <hbos@google.com>
>> Sent: Tuesday, July 16, 2019 1:31 AM
>> To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
>> Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>; Harald Alvestrand <harald@alvestrand.no>; public-webrtc@w3.org <public-webrtc@w3.org>
>> Subject: Re: Call for Consensus (CfC): Publish webrtc-stats as updated Candidate Recommendation
>>
>>
>>
>> I don't know the formal differences between CR and PR. But in my mind, the stats are in a really good shape - the desired metrics for a WebRTC 1.0 implementation are there, and some - but several metrics are in the wrong place, i.e. to adequately support simulcast some of them need to be moved around so that they can be expressed on a per-layer (per outbound-rtp) rather than per-sender (track) basis.
>>
>>
>>
>> On Tue, Jul 16, 2019 at 10:17 AM Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
>>
>> I do too. But should the “CR blocker” labels be changed to “PR blocker”? The current label seems to serve no purpose if we spin a new CR without resolving the issues.
>>
>>
>>
>> From: Henrik Boström <hbos@google.com>
>> Date: Monday, 15 July 2019 at 13:24
>> To: Bernard Aboba <Bernard.Aboba@microsoft.com>
>> Cc: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
>> Subject: Re: Call for Consensus (CfC): Publish webrtc-stats as updated Candidate Recommendation
>> Resent-From: "public-webrtc@w3.org" <public-webrtc@w3.org>
>> Resent-Date: Monday, 15 July 2019 at 13:23
>>
>>
>>
>> I support publishing the current webrtc-stats as CR
>>
>>
>>
>>
>>
>> On Fri, Jul 12, 2019 at 8:29 PM Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>>
>> The respec errors in Webrtc-Stats are now fixed:
>>
>> https://w3c.github.io/webrtc-stats/
>>
>> ________________________________
>>
>> From: Bernard Aboba <Bernard.Aboba@microsoft.com>
>> Sent: Thursday, July 11, 2019 8:09 AM
>> To: Harald Alvestrand <harald@alvestrand.no>; public-webrtc@w3.org <public-webrtc@w3.org>
>> Subject: Re: Call for Consensus (CfC): Publish webrtc-stats as updated Candidate Recommendation
>>
>>
>>
>> The Editor's draft shows 11 respec errors, and the Issues list shows 8 unresolved Issues with the "CR blocker" label.
>>
>>
>>
>> So perhaps a little more work is needed before a CR can be published.
>>
>> ________________________________
>>
>> From: Harald Alvestrand <harald@alvestrand.no>
>> Sent: Wednesday, July 10, 2019 7:52 AM
>> To: public-webrtc@w3.org <public-webrtc@w3.org>
>> Subject: Call for Consensus (CfC): Publish webrtc-stats as updated Candidate Recommendation
>>
>>
>>
>> Our present webrtc-stats, published as https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fwebrtc-stats%2F&amp;data=02%7C01%7CBernard.Aboba%40microsoft.com%7C0d5b18e330f34e01f29c08d705467791%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983672521933649&amp;sdata=efffKD9Wp7Rd0D9Vyxvb5jAHeY0xiwBINk1xxdE6WQY%3D&amp;reserved=0, is almost exactly 1 year old.
>>
>> The spec has evolved significantly over the course of a year; having this old version
>> around just confuses things.
>>
>> The spec is still evolving, and needs some tidying, but the chairs feel that it is better to emit this one
>> as Candidate Recommendation now than to wait for stability to increase. Thus:
>>
>> This is a Call for Consensus to push the editors' draft,
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebrtc-stats%2F&amp;data=02%7C01%7CBernard.Aboba%40microsoft.com%7C0d5b18e330f34e01f29c08d705467791%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983672521933649&amp;sdata=fcxkyzDASKpqrkZMrozRSh8HxSLy34wVW8z3BSSO6xk%3D&amp;reserved=0, out as a new version of our
>> Candidate Recommendation.
>>
>> The CfC will last for one week, and end on Wednesday, July 17, at 16:00 UTC
>>
>> In response, please state one of the following:
>>
>> - I support publishing the current webrtc-stats as CR
>>
>> - I object to publishing the current webrtc-stats as CR, due to
>> issues filed in open bug <#number>.
>>
>> Harald, for the chairs
>>
>> --
>> Surveillance is pervasive. Go Dark.
>>
>>
>>
>> --
>>
>> Surveillance is pervasive. Go Dark.



-- 
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/

Received on Wednesday, 24 July 2019 14:13:11 UTC