Re: [xrblock] Future of XRBLOCK

Bernard Aboba <bernard.aboba@gmail.com> Thu, 07 April 2016 21:12 UTC

Return-Path: <bernard.aboba@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 D3D1512D5A9 for <xrblock@ietfa.amsl.com>; Thu, 7 Apr 2016 14:12:38 -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 5tVshs_Pfl3g for <xrblock@ietfa.amsl.com>; Thu, 7 Apr 2016 14:12:35 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 66C2412D10C for <xrblock@ietf.org>; Thu, 7 Apr 2016 14:12:35 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id k1so115702107vkb.0 for <xrblock@ietf.org>; Thu, 07 Apr 2016 14:12:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lcmtfSAxWRijKchyUVfhiQPyYC71qpl8UHpwW+abn5g=; b=t60tZTvMDQqk54vp2pBn4PYUemXH+Qtk+luK1NzuazY8+kORHzg3t5rlHBXD2N54Fs 6LXUjyvwUMbVuUQwqpGgBMXdybaIIqv8vxFYUXDMUC+6uel3kAy7MySWeCQGhP/WlfHA u/I8+FjhTSiL/W4jdyL/4eGfmJtOl99+KYPMTu5MB6RkggZ6G4ZVuxwhFVWVV4Rj2iLf 1LOWukO27H2wbh+MUeqQx1+d6rKivhViZt3aJ9CZ0SZ6tTjbtdQlZkoltme+WqUPXmdy MIbmuzJED5bOLLHINTXrSLhgjYmV1iBKm2GcsHQD8dG7QzkUW58nzwFudfh+jftjyun8 d0Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lcmtfSAxWRijKchyUVfhiQPyYC71qpl8UHpwW+abn5g=; b=ExmNfzlAuxNSFXDcik7rfdj7+z0kyKYGRtyNh0TNR0dymtg7qCTUXA6BCVri4i83DU D0ohtgs+vClVHQwTcPBM55jSMEAp21JnkEDhp7zzjpuAgQfsJg6DOBA/baqB+jlYdshb slAuyBUmYDlayfSOq/mfscENORgW3na41r5NUn5iusxbMT4RBTqSYiH20fVlAKDUKI6J 9+KuxgQhV8NOCKEyMwa2ZfZAkRquqkRIVY9MabHM9DZkzJus2jroCQ+aBUjSJ43TjrYV 9gbIhdJQeY5LygJW3f16U9IMpNk6nRZ0XaMfILV1ObhEGk8Bl2KWgCwLpIB5KV3ty52X pn1A==
X-Gm-Message-State: AD7BkJIscMAuwT591XurN2UftZbcGnU+W7BA8ehJeapRMTKGsMrM8D4EyESyw2f53s1pFSkjoFtfYPDP0FtfxA==
X-Received: by 10.176.64.225 with SMTP id i88mr2454046uad.9.1460063554449; Thu, 07 Apr 2016 14:12:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.40 with HTTP; Thu, 7 Apr 2016 14:12:15 -0700 (PDT)
In-Reply-To: <5706C89B.2080202@telchemy.com>
References: <949EF20990823C4C85C18D59AA11AD8BADEBB23D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAOW+2dus5JSNEOoVAZfNFGiVBTf1zeV6e=rtY31mP+zJWctqZw@mail.gmail.com> <5706C89B.2080202@telchemy.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 7 Apr 2016 14:12:15 -0700
Message-ID: <CAOW+2duV0r=VGtNx1K55Tu-Eb5Zxk08oEK_DmkAyYwmSgkYghg@mail.gmail.com>
To: Alan Clark <alan.d.clark@telchemy.com>
Content-Type: multipart/alternative; boundary=94eb2c12370a835cab052feb8991
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/hbiAOOa5SqAA7n6G-ZIss9eKcpk>
Cc: "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] Future of XRBLOCK
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.17
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, 07 Apr 2016 21:12:39 -0000

Alan said:

" I don't think that XRBLOCK has had many IPR issues (2 ?) however rtcweb
would be much more rigorous in limiting the development of drafts that have
IPR disclosures "

[BA] The problem of late disclosure has grown in the IETF ART area.  So I
am concerned that this is an iceberg with much more under the surface than
we have seen so far - and so more forceful action is going to be needed to
prevent this from getting out of control.

"I think that the WebRTC statistics draft should be transferred to the
rtcweb WG, it makes no sense to have this done within XRBLOCK."

[BA] I agree.  We need IETF RTCWEB WG buyin for this draft and the best way
to get this would be to move it to RTCWEB. In particularly, RTCWEB is
likely to push back more strongly on IPR, and this "backpressure" will also
feedback into the XRBLOCK WG for as long as it remains active.

"The independent burst gap draft should be progressed and then the XRBLOCK
WG should be wound up.   I'd be more than happy to review any future
metrics reporting drafts within AVT, rtcweb or wherever they happen to be
developed."

[BA] I agree that the burst gap draft is potentially valuable and should be
progressed (assuming that there are no issues here as well). Overall, burst
loss related statistics are quite important (as is FEC effectiveness
metrics), since this could help allow the characteristics of the FEC to be
adjusted.





On Thu, Apr 7, 2016 at 1:52 PM, Alan Clark <alan.d.clark@telchemy.com>
wrote:

> Bernard, Keith
>
> I concur that the development of drafts that are intended for use within
> WebRTC should be done within the rtcweb WG in IETF.  I don't think that
> XRBLOCK has had many IPR issues (2 ?) however rtcweb would be much more
> rigorous in limiting the development of drafts that have IPR disclosures.
>
> I must admit to being somewhat disappointed with regard to the video loss
> concealment draft episode - firstly in the way in which irrelevant IPR was
> included in the draft, secondly in the way that the IPR was disclosed and
> thirdly in the resistance that was exhibited to the removal of the IPR
> disclosure.  Participants were suggesting that the WG should not even be
> discussing IPR issues, that having an IPR disclosure was not a problem as
> implementers could get opinions from their attorneys or from a court......
>
> I think that the WebRTC statistics draft should be transferred to the
> rtcweb WG, it makes no sense to have this done within XRBLOCK. The
> independent burst gap draft should be progressed and then the XRBLOCK WG
> should be wound up.   I'd be more than happy to review any future metrics
> reporting drafts within AVT, rtcweb or wherever they happen to be developed.
>
> Part of the motivation in setting up XRBLOCK was that there were a set of
> unfinished xrblock drafts that had been developed within AVT, these were
> sitting on the shelf and it made sense to dust them off and complete them.
> This has now been done, XRBLOCK's work is (almost) complete and the IETF
> has the very sensible practice of avoiding self-perpetuating WG's.
>
> Regards
>
> Alan Clark
>
>
>
> On 4/6/16 5:51 PM, Bernard Aboba wrote:
>
> I was sceptical when XRBLOCK was created and my concerns have only grown
> since.  With WebRTC gaining more and more prominence in realtime
> communications development in virtually every segment (e.g. Web, mobile,
> IoT), an important determinant of whether XRBLOCK WG drafts are widely
> implemented is whether they are suitable for inclusion in WebRTC
> implementations.  The IPR concerns we have seen in this WG bring with them
> the potential for XRBLOCK drafts and RFCs to be shunned by browser vendors
> - and thus to amount to little more than "vanity RFCs".
>
> This leads me to question the utility of having XRBLOCK remain as a
> separate WG, as opposed to having the work reviewed within a WG that is
> more widely attended by WebRTC implementers.
>
> On Wed, Apr 6, 2016 at 1:10 PM, Drage, Keith (Nokia - GB) <
> <keith.drage@nokia.com>keith.drage@nokia.com> wrote:
>
>> Following on from the discussion that has just occurred in the
>> face-to-face meeting.
>>
>> I would first note that one only really needs a WG to deal with new XR
>> block proposals if the required documentation status is standards track.
>> Perhaps it would be appropriate for people to rejustify why this needs to
>> be standards track rather than just first come first served or expert
>> review.
>>
>> Secondly, when both PAYLOAD and XRBLOCK were created, there was a view
>> that both these were somewhat special, in that they did not necessarily
>> need to meet, but did need to provide a forum for experts "to turn the
>> handle on the process" and produce something where the relevant experts had
>> looked at it; that in IETF speak is a WG rather than just a mailing list. I
>> do incline still to that.
>>
>> Maybe speaking with hindsight, but not sure that the meeting that has
>> just occurred was "value for money"; it could all have been done on the
>> mailing list.
>>
>> Keith
>>
>> _______________________________________________
>> xrblock mailing list
>> xrblock@ietf.org
>> https://www.ietf.org/mailman/listinfo/xrblock
>>
>
>
>
> _______________________________________________
> xrblock mailing listxrblock@ietf.orghttps://www.ietf.org/mailman/listinfo/xrblock
>
>
>