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> Thu, 31 March 2016 16:33 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 E66C512D65D for <xrblock@ietfa.amsl.com>; Thu, 31 Mar 2016 09:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 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, T_KAM_HTML_FONT_INVALID=0.01] 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 ik9g08Azm5Vl for <xrblock@ietfa.amsl.com>; Thu, 31 Mar 2016 09:33:54 -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 E1BE012D1AD for <xrblock@ietf.org>; Thu, 31 Mar 2016 09:33:53 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 21217BB8923DD; Thu, 31 Mar 2016 16:33:49 +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 u2VGXpIv011560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2016 16:33:51 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2VGXc44007495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Mar 2016 18:33:50 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 31 Mar 2016 18:33:46 +0200
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: EXT Alan Clark <alan.d.clark@telchemy.com>, "xrblock@ietf.org" <xrblock@ietf.org>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Thread-Topic: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt
Thread-Index: AQHRi2kZ97Fffy0vMEaC7w2WQW03cp9zve1A
Date: Thu, 31 Mar 2016 16:33:46 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB770D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <56FD4CF8.1000206@telchemy.com>
In-Reply-To: <56FD4CF8.1000206@telchemy.com>
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_949EF20990823C4C85C18D59AA11AD8BADEB770DFR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/47R_Yp2QldWc5J0CwXmxfbrpFqc>
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: Thu, 31 Mar 2016 16:33:57 -0000

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