Re: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt

Alissa Cooper <alissa@cooperw.in> Fri, 01 April 2016 15:44 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 2D21212D69D for <xrblock@ietfa.amsl.com>; Fri, 1 Apr 2016 08:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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=wNIZUekc; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=qYhiyKul
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 RoYE7mBXrLs1 for <xrblock@ietfa.amsl.com>; Fri, 1 Apr 2016 08:43:57 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1309D12D6A3 for <xrblock@ietf.org>; Fri, 1 Apr 2016 08:43:57 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7644E20C83 for <xrblock@ietf.org>; Fri, 1 Apr 2016 11:43:56 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 01 Apr 2016 11:43:56 -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=0fSfi O641bgAvzHQZ1rr2G8Kkig=; b=wNIZUekcvJAlT1xKEQHhuYtQWLhKggbv84qBm y9PBO+7kLV5YHNd59eJIFBIlZP1Qrmh/PjYg2dL5AWl4Wop3V0wi8uEjSXbC3go+ RWnkXktREzKSivlaI9UgK1t6klIMyWzEMBIFvT67oDBQWXn5PxaHm5F9NlpSS5Ag LE9ur8=
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=0fSfiO641bgAvzHQZ1rr2G8Kkig=; b=qYhiy KulqlyX7UKtJB/xuLGR797jNiH5gIOF6dl5swYTTir2Zf4DVSCPkTSwH36QOfb3x Yg/sDDUCRDSzzrQOTXlytwLFo0ONSuw3TDlvAUs/EHrD+8ZHhVre0Woq03OS624w Av9WtEqChQPGBht94D6QTDJYhC8X5lMiM6bDkM=
X-Sasl-enc: nD145Hs/sb8WiThENxhGOnQ4fsww2DDSDWGvoHm3NTgB 1459525435
Received: from sjc-alcoop-88113.cisco.com (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 6CD3D68016B; Fri, 1 Apr 2016 11:43:55 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9D7BF85-4CDA-4B6C-85B9-2731F5CE2405"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB7B25@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Fri, 1 Apr 2016 08:43:54 -0700
Message-Id: <BD949BF2-45AA-4241-BD9B-E740C0F46BAF@cooperw.in>
References: <56FD4CF8.1000206@telchemy.com> <949EF20990823C4C85C18D59AA11AD8BADEB770D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <72D59AC1-5CA6-41AE-ADE4-6181E58F733C@cooperw.in> <949EF20990823C4C85C18D59AA11AD8BADEB7B25@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/ZhEstUqboYzWzNsm5Q1WErD356s>
Cc: "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt
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, 01 Apr 2016 15:44:00 -0000

> On Mar 31, 2016, at 5:31 PM, Drage, Keith (Nokia - GB) <keith.drage@nokia.com> wrote:
> 
> I’m not sure I understand the relevance of section 7, which is apparently about failure to disclose.
>  
> As the author, despite working for the same company, states she knew nothing about the IPR, section 7 does not come into effect. It is certainly perfectly reasonable this is the case.
>  
> My understanding is that we are more in the area covered by the first paragraph of section 8 (although I agree this is not quite the case).

Yep, sorry, meant section 8. 
Alissa

>  
> Anyway, I am not seeking that the working group evaluate or validate the IPR, I merely want the discloser to be asked whether they consider their declaration is still required based on the new version. If they claim it is (either by response or timeout), and the declaration is still in the current form, then my position is unchanged.
>  
> Regards
>  
> Keith
>  
> From: EXT Alissa Cooper [mailto:alissa@cooperw.in] 
> Sent: 31 March 2016 23:36
> To: Drage, Keith (Nokia - GB)
> Cc: EXT Alan Clark; xrblock@ietf.org; Romascanu, Dan (Dan)
> Subject: Re: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt
>  
> RFC 3669 is useful, but just wanted to point out BCP 79 Sec. 7 which I take to be the prevailing guidance on these matters. 
>  
> In this particular case it seems more like what the WG was discussing was applicability, not validity. And in any event there was not an attempt to reach consensus about either applicability or validity, which is the key bit from BCP 79 in this case I think.
>  
> Alissa
>  
> On Mar 31, 2016, at 9:33 AM, Drage, Keith (Nokia - GB) <keith.drage@nokia.com <mailto:keith.drage@nokia.com>> wrote:
>  
> I agree.
>  
> I also think this is a two step process, and the next step is to ask the IPR claimant whether they believe their declaration is still applicable. Their response can be either to withdraw it, modify it or keep it, and we can come back to the discussion at that point.
>  
> I believe this is consistent with RFC 3669.
>  
> Keith
>  
> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of EXT Alan Clark
> Sent: 31 March 2016 17:15
> To: xrblock@ietf.org <mailto:xrblock@ietf.org>; Romascanu, Dan (Dan)
> Subject: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt
>  
> Dan,
> 
> It is good that the WG has found a way forward with the video-lc draft. Bearing in mind the difficulty in getting a response from the company that made the patent disclosure, I think that the WG should not progress the draft until the IPR disclosure is actually withdrawn. 
> 
> There were a number of statements made within the XRBLOCK WG during the last months about what the IETF and the WG could and could not do with regard to patent disclosures, and some XRBLOCK participants were presenting the view that we should not even discuss whether or how a patent may apply to a draft. The IETF IPR WG appear to have considered this and if we look at the guidelines for WG's provided in RFC 3669:
> 
> "The IETF as a whole, and a working group as a whole, takes no stance on the validity of any IPR claim.  It would be inappropriate for a working group chair to declare that consensus had been reached that, for example, a company's patent was invalid.  Individual participants will need to use whatever legal advice resources they have access to in order to form their own individual opinions.  Discussions about the validity of IPR may take place under the auspices of the working group, in particular about relative risks of technology choices.  Individual participants may take these discussions into account.  The working group as a body may not take a stance on validity, but it may make choices based on perceived risk."
> 
> So - this essentially states that the IETF and the WG should not take a position on the validity of a patent however that individuals may form opinions on the validity of patents, WG may discuss these opinions and they may affect the choices made by the WG.  As a WG we have followed the letter and spirit of the IETF guidelines in considering the applicability of the disclosed patent to the draft.
> 
> I asked to be removed as an author from this draft as text that was inserted into the draft by another author caused the draft to be subject to a patent disclosure by that author's company, however the IPR was not disclosed at the time and the inserted text was non-essential and not directly relevant to the purpose of the document. 
> The inserted example text described a specific video loss concealment algorithm, claimed in a patent, whereas the draft only defines metrics for reporting the proportion of video that was loss concealed, duration of frame freezes and similar measurements. The patent described a specific algorithm for video loss concealment and contained no text or claims that related to metrics or performance measurement.  If the patent was required in order to implement the draft then the removal of the offending text would change the operation of the protocol or the value of the metrics reported, whereas the removal of the text will in fact make no difference at all. 
> 
> So - hopefully Huawei withdraw their IPR disclosure and the draft moves forward to become an RFC.
> 
> Best Regards
> 
> Alan Clark
> 
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org <mailto:xrblock@ietf.org>
> https://www.ietf.org/mailman/listinfo/xrblock <https://www.ietf.org/mailman/listinfo/xrblock>