Re: [xrblock] Future of XRBLOCK

Alan Clark <alan.d.clark@telchemy.com> Thu, 07 April 2016 20:52 UTC

Return-Path: <alan.d.clark@telchemy.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 E2C6612D6E6 for <xrblock@ietfa.amsl.com>; Thu, 7 Apr 2016 13:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Cyyk_4kNlop0 for <xrblock@ietfa.amsl.com>; Thu, 7 Apr 2016 13:52:46 -0700 (PDT)
Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E6212D608 for <xrblock@ietf.org>; Thu, 7 Apr 2016 13:52:45 -0700 (PDT)
X-SBRS: -4.0
X-HAT: Sender Group GREYLIST_RELAY_PORT587, Policy $GREYLIST_RELAY applied.
X-Hostname: omx04bay.sys.cbeyond.net
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AiBgAcyAZXPBjTYUxdgzdTfbpDAQ2BcxcBCYUiRAQCAoE9ORQBAQEBAQEBBgEBAQFCQIRCAQEEAQEBUxUBAgoBEAsYCRYIBwkDAgECARUSCgMRBgoDBgIBAYgjBQnCAgEBAQEGAQEBARgEimyKFQWYBJ0ajyQeAQGCRhmBZiAwiTkBAQE
X-IPAS-Result: A2AiBgAcyAZXPBjTYUxdgzdTfbpDAQ2BcxcBCYUiRAQCAoE9ORQBAQEBAQEBBgEBAQFCQIRCAQEEAQEBUxUBAgoBEAsYCRYIBwkDAgECARUSCgMRBgoDBgIBAYgjBQnCAgEBAQEGAQEBARgEimyKFQWYBJ0ajyQeAQGCRhmBZiAwiTkBAQE
X-IronPort-AV: E=Sophos;i="5.24,449,1454994000"; d="scan'208,217";a="177911859"
Received: from c-76-97-211-24.hsd1.ga.comcast.net (HELO Alans-MacBook-Pro.local) ([76.97.211.24]) by omx.cbeyond.com with ESMTP/TLS/DHE-RSA-AES128-SHA; 07 Apr 2016 16:52:45 -0400
To: Bernard Aboba <bernard.aboba@gmail.com>, "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
References: <949EF20990823C4C85C18D59AA11AD8BADEBB23D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAOW+2dus5JSNEOoVAZfNFGiVBTf1zeV6e=rtY31mP+zJWctqZw@mail.gmail.com>
From: Alan Clark <alan.d.clark@telchemy.com>
Message-ID: <5706C89B.2080202@telchemy.com>
Date: Thu, 7 Apr 2016 16:52:43 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAOW+2dus5JSNEOoVAZfNFGiVBTf1zeV6e=rtY31mP+zJWctqZw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040606080203090804040201"
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/TawvJ7QzRABgEND4n0wWPXt29uU>
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 20:52:48 -0000

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 <mailto: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 <mailto:xrblock@ietf.org>
>     https://www.ietf.org/mailman/listinfo/xrblock
>
>
>
>
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock