Re: [xrblock] Future of XRBLOCK

Alissa Cooper <alissa@cooperw.in> Fri, 08 April 2016 11:30 UTC

Return-Path: <alissa@cooperw.in>
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 3601E12D14F for <xrblock@ietfa.amsl.com>; Fri, 8 Apr 2016 04:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=Bx12PmNX; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Vxer3Ke+
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 lQ5F6FfgZ8YK for <xrblock@ietfa.amsl.com>; Fri, 8 Apr 2016 04:30:10 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EDD12D133 for <xrblock@ietf.org>; Fri, 8 Apr 2016 04:30:10 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 67C0B211FA for <xrblock@ietf.org>; Fri, 8 Apr 2016 07:30:09 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 08 Apr 2016 07:30:09 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Ky4hA NaWX8up/uH01s8coTnS+GA=; b=Bx12PmNXruXQ6a6cl/klFqFdxjkgQ/m4EPU1Q XXk5CiLO7qQDFJQ9x3/bHZXNFQSBcJkFPyEgFMSU34Aln29m66z4n9rXLgqkrgd8 jeL2cNVRD9y8sDcHTSWaTxCuIrY+E67bQP0QWW6uFm2g5uVEc6+yF+LNhfLhHKdn 9cru/0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Ky4hANaWX8up/uH01s8coTnS+GA=; b=Vxer3 Ke+O8zTy3ZY44Qat/hcqfXIpHOI30H2Qz6Oeitfs/NgQ7+d2AcwhRzLAK4dPqP4C nzorNNRHlQmbw09U7m9lIjD7KQgYqZKyCxg0YuwfU4uqlqcvaDabQBv3TOXX+2cu WlkuYbBb1dSNz91qFm/yuPFjgLNyMmUeQm6V/4=
X-Sasl-enc: NcgXjKXLLM+KuCF3fqKSC+Wooyujs8BF7RlHwbdNYEt0 1460115007
Received: from [10.24.67.89] (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 122C06800DB; Fri, 8 Apr 2016 07:30:04 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B9C22545-7DC2-4045-9F48-CA44E0937029"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEBC34E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Fri, 8 Apr 2016 08:30:01 -0300
Message-Id: <1A56EBC9-F73C-48AB-9795-9EF2788CE20F@cooperw.in>
References: <949EF20990823C4C85C18D59AA11AD8BADEBB23D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAOW+2dus5JSNEOoVAZfNFGiVBTf1zeV6e=rtY31mP+zJWctqZw@mail.gmail.com> <5706C89B.2080202@telchemy.com> <5968A666-9036-4798-B869-A3D0A37852DE@cooperw.in> <949EF20990823C4C85C18D59AA11AD8BADEBC34E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
To: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/i6NgE0z2WviL7PdPNFZOk4jBjOA>
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: Fri, 08 Apr 2016 11:30:12 -0000

> On Apr 7, 2016, at 6:11 PM, Drage, Keith (Nokia - GB) <keith.drage@nokia.com> wrote:
> 
> This is in publication request because the IPR declaration was made after publication request.

What do you mean by “this”? The webrtc metrics draft that my note below mentions does not have any IPR disclosures associated with it.

Alissa

>  
> At the moment all I have a verbal indication from the editor, made in the meeting, that something will happen.
>  
> I would rather see the formal IPR process completed, and then make my own assessment that the IPR situation is now satisfactory, rather than have the AD make that decision for me.
>  
> Regards
>  
> Keith
>  
> From: EXT Alissa Cooper [mailto:alissa@cooperw.in <mailto:alissa@cooperw.in>] 
> Sent: 07 April 2016 22:06
> To: Alan Clark
> Cc: Bernard Aboba; Drage, Keith (Nokia - GB); xrblock@ietf.org <mailto:xrblock@ietf.org>
> Subject: Re: [xrblock] Future of XRBLOCK
>  
>  
> On Apr 7, 2016, at 5:52 PM, Alan Clark <alan.d.clark@telchemy.com <mailto: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 document has already been through WGLC and appears to have consensus to have publication requested, so it is effectively already out of the WG.
> 
> 
> 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.
>  
> Sounds like folks are in agreement with what seemed to have consensus at the meeting — keep XRBLOCK open until its current documents are with the RFC Editor, find another group in ART (probably AVTEXT but TBC) and re-charter to have future xr block definitions to be in scope, then close XRBLOCK.
>  
> Alissa
> 
> 
> 
> 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 <https://www.ietf.org/mailman/listinfo/xrblock>
>  
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org <mailto:xrblock@ietf.org>
> https://www.ietf.org/mailman/listinfo/xrblock <https://www.ietf.org/mailman/listinfo/xrblock>
>  
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org <mailto:xrblock@ietf.org>
> https://www.ietf.org/mailman/listinfo/xrblock <https://www.ietf.org/mailman/listinfo/xrblock>