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

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Fri, 01 April 2016 03:55 UTC

Return-Path: <rachel.huang@huawei.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 B6ECA12D1AC for <xrblock@ietfa.amsl.com>; Thu, 31 Mar 2016 20:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 x_OGpPGUYUVA for <xrblock@ietfa.amsl.com>; Thu, 31 Mar 2016 20:55:16 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECEC12D14D for <xrblock@ietf.org>; Thu, 31 Mar 2016 20:55:14 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml708-cah.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXP68631; Thu, 31 Mar 2016 22:55:13 -0500 (CDT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 1 Apr 2016 04:55:11 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 1 Apr 2016 11:55:06 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>, 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: AQHRi2h/vLP+WznvMEaysOu84Hza6Z9zOUMAgABlLYCAACAuAIAAvnSQ
Date: Fri, 1 Apr 2016 03:55:05 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E9D19B@nkgeml513-mbx.china.huawei.com>
References: <56FD4CF8.1000206@telchemy.com> <949EF20990823C4C85C18D59AA11AD8BADEB770D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <72D59AC1-5CA6-41AE-ADE4-6181E58F733C@cooperw.in> <949EF20990823C4C85C18D59AA11AD8BADEB7B25@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB7B25@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.46.71.176]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9D19Bnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.56FDF122.001C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c6df089b06a444d71941b5f8064b4ada
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/9atxz7CJFqbAl2avPFO6rmEvd4s>
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 03:55:18 -0000

Hi Keith, Alan, and Alissa,

I’m told that our IPR department is confirmed to withdraw this disclosure, which means I think they agree that it will not be applicable to the draft anymore. The withdraw may take a few days. I don’t know. But I’m also okay to wait to proceed this work until the IPR is withdrawn.

BR,
Rachel

发件人: xrblock [mailto:xrblock-bounces@ietf.org] 代表 Drage, Keith (Nokia - GB)
发送时间: 2016年4月1日 8:31
收件人: EXT Alissa Cooper
抄送: xrblock@ietf.org
主题: Re: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt

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<mailto: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