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

"Drage, Keith (Nokia - GB)" <keith.drage@nokia.com> Fri, 01 April 2016 00:31 UTC

Return-Path: <keith.drage@nokia.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 9769112D925 for <xrblock@ietfa.amsl.com>; Thu, 31 Mar 2016 17:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 XohcsmJm_PrR for <xrblock@ietfa.amsl.com>; Thu, 31 Mar 2016 17:31:08 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6B512D91B for <xrblock@ietf.org>; Thu, 31 Mar 2016 17:31:07 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 6B8EA4F93E3F0; Fri, 1 Apr 2016 00:31:01 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u310V5Mk011915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2016 00:31:05 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u310V3Fe012680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Apr 2016 02:31:04 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 1 Apr 2016 02:31:04 +0200
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: EXT Alissa Cooper <alissa@cooperw.in>
Thread-Topic: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt
Thread-Index: AQHRi2kZ97Fffy0vMEaC7w2WQW03cp9zve1AgABFF4CAADvD0A==
Date: Fri, 1 Apr 2016 00:31:04 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB7B25@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <56FD4CF8.1000206@telchemy.com> <949EF20990823C4C85C18D59AA11AD8BADEB770D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <72D59AC1-5CA6-41AE-ADE4-6181E58F733C@cooperw.in>
In-Reply-To: <72D59AC1-5CA6-41AE-ADE4-6181E58F733C@cooperw.in>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADEB7B25FR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/8Sya02wVeHEvcikP33-Mt-4iEfE>
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 00:31:11 -0000

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).

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] 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