Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc

Alissa Cooper <alissa@cooperw.in> Sat, 12 March 2016 23:00 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 A9B6D12D89A for <xrblock@ietfa.amsl.com>; Sat, 12 Mar 2016 15:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level:
X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-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=fUdM+D4j; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=HXITizgD
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 BMadNoJSydbz for <xrblock@ietfa.amsl.com>; Sat, 12 Mar 2016 15:00:19 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4713312D70F for <xrblock@ietf.org>; Sat, 12 Mar 2016 15:00:19 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AA43820612 for <xrblock@ietf.org>; Sat, 12 Mar 2016 18:00:18 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 12 Mar 2016 18:00:18 -0500
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=dD1Hl U1Ddm07b/M2dZfE8W6wEOQ=; b=fUdM+D4jIcNA1KKl0bINMGTdcepkNCjRbFzbo QOetJnt/BzFpVceGw/6pEvKAe7CO3F6d924KgFnuJ6pPHd+yU/cDFShreCsLJxSL 8cBj/q13WDsdMFlDKvYqnEW6hnVe/VITMlkxU8mrICjx7Q08ZYMDPEmbFZV5wiR6 QstkKY=
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=dD1HlU1Ddm07b/M2dZfE8W6wEOQ=; b=HXITi zgDOLZO9+a60H7evP5bAYkBpLVlgfs7CbRG3Lg+veznv+GqNNYqFP81cUNZ1Q/Xg Advrxwr4nldcHzLpGXjw9SLi78IThsgcEdtub3N2kul1/9yMe4gY4wWkZQ9G3oIU gOAlpvzDNAOylfSyyrQAAEq2eplzQRD6BYIYSs=
X-Sasl-enc: li4xYwM5b+QGXpdzNPHg53cU9tw0LzmpuirdzOp1jZ5o 1457823608
Received: from [10.24.74.170] (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 861B6680226; Sat, 12 Mar 2016 18:00:04 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_339EB164-2A65-41C8-A6CF-A28495D9DB71"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <16c001d17cae$315f2dd0$941d8970$@gmail.com>
Date: Sat, 12 Mar 2016 23:59:56 +0100
Message-Id: <20B07C3C-F812-4792-8728-467379DAC96B@cooperw.in>
References: <9904FB1B0159DA42B0B887B7FA8119CA6BEC8D0F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEDD449@AZ-FFEXMB04.global.avaya.com> <568C223A.6050009@telchemy.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEDE582@AZ-FFEXMB04.global.avaya.com> <568D3F00.7060609@telchemy.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E78FCC@nkgeml513-mbx.china.huawei.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E81284@nkgeml513-mbx.china.huawei.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEFD273@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF0C7DF@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF83F5B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF83FA4@AZ-FFEXMB04.global.avaya.com> <56E04F94.8070504@telchemy.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8F022@nkgeml513-mbs.china.huawei.com> <56E17FD5.6010803@telchemy.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8F428@nkgeml513-mbs.china.huawei.com> <56E2A83F.6090306@telchemy.com> <65A1FC92-2E4C-496C-B71C-90CB06288280@co operw.in> <16c001d17cae$315f2dd0$941d8970$@gmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/Mmvt1EdwuGEo_v-hapf3gfZojRA>
Cc: xrblock@ietf.org
Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
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: Sat, 12 Mar 2016 23:00:23 -0000

Hi Roni,

The consensus call issued by Dan was not about IPR validity. It was about whether the WG wants to proceed with the document.

I think it’s reasonable, when responding to the question he asked, for people to give their reasons for responding one way or the other, and those may include statements about belief in the validity or applicability of the patent at issue. But I agree with you that debating those opinions on the list is not productive.

There is more time before the consensus call ends, so it would be useful to hear more opinions IMO if people have them.

Alissa


> On Mar 12, 2016, at 11:26 PM, Roni Even <ron.even.tlv@gmail.com> wrote:
> 
> Hi Alissa,
> I think that the discussion that is going on is on the validity of the IPR, I am not sure that the IETF mailing list is the place to discuss IPR validity and I do not think that the IETF can call consensus on IPR validity which is the topic that is being discussed
> Roni
>  
> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Alissa Cooper
> Sent: Saturday, March 12, 2016 11:37 PM
> To: Alan Clark
> Cc: xrblock@ietf.org
> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>  
> Just confirming — there is indeed a process to withdraw a disclosure. We just used it in one of my other WGs.
>  
> Alissa
>  
>> On Mar 11, 2016, at 12:13 PM, Alan Clark <alan.d.clark@telchemy.com <mailto:alan.d.clark@telchemy.com>> wrote:
>>  
>> Rachel
>> 
>> On your comment that there is no procedure for a disclosure to be withdrawn, RFC3979 Section 6.1.1 states that 
>> 
>> "An IPR discloser is requested to withdraw a previous disclosure if a revised Contribution negates the previous IPR disclosure, or to amend a previous disclosure if a revised Contribution substantially alters the previous disclosure."
>> 
>> which means that the IETF patent policy does permit a disclosure to be withdrawn.
>> 
>> Also - the IPR disclosure database shows for disclosure 2633 (and others) - "This IPR disclosure was removed at the request of the submitter."
>> 
>> So there is a procedure for withdrawing a disclosure, you simply need to ask the IETF to do it.
>> 
>> Best Regards
>> 
>> Alan
>> 
>> On 3/11/16 1:14 AM, Huangyihong (Rachel) wrote:
>>> Hi Alan,
>>>  
>>> Inline please.
>>>  
>>> BR,
>>> Rachel
>>>  
>>> From: Alan Clark [mailto:alan.d.clark@telchemy.com <mailto:alan.d.clark@telchemy.com>] 
>>> Sent: Thursday, March 10, 2016 10:08 PM
>>> To: Huangyihong (Rachel); xrblock@ietf.org <mailto:xrblock@ietf.org>
>>> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>  
>>> Hi Rachel
>>> 
>>> According to your logic, as the MOS score reported using RFC3611 or RFC6035 would be affected by the choice of voice codec on a call then an implementer of these protocols should obtain a license to every voice codec patent, which is obviously not the case. The question is - does the implementer have to implement what is described in the patent and claimed in the patent claims, and in the case of concealment metrics the implementer does not need to implement a concealment algorithm in order to report the metrics.
>>> 
>>> 
>>> 
>>> [Rachel]: I may be wrong. But I learned that they have optional and mandatory in patent hearings. In this case, I assume it does not require a mandatory implementation for the patent, but still a patent claim could be made.
>>> 
>>> On the disclosure itself:-
>>> (i) a reciprocity condition is not weak. Say that I have a fundamental patent related to SDN technology and would like to assert this against companies that infringe it then a reciprocity condition could affect my ability to enforce my patent.
>>> 
>>> [Rachel]: But it depends on the patent litigation to think if it affects or not, right?
>>> 
>>> 
>>> (ii) it is unrealistic to say "it's no problem a judge could figure it out". Patent litigation is very expensive and by the time a case gets in front of a judge then the lawyers' bill can be in the US$ millions.
>>> 
>>> 
>>> My view is that if we don't push back (at least at the WG level) on patent disclosures that are not relevant to the draft then we would encourage frivolous disclosure and adversely impact the adoption of IETF RFCs and Standards.
>>> 
>>> 
>>> 
>>> [Rachel]: I’m told that there’s no procedure for a patent disclosure to withdrawn. 
>>> The WG certainly does have the option of deciding not to proceed with a draft if there has been a patent disclosure against that draft, and I think that we should invoke that option.
>>> 
>>> 
>>> 
>>> 
>>> Regards
>>> 
>>> Alan
>>> 
>>> 
>>> 
>>> On 3/10/16 3:00 AM, Huangyihong (Rachel) wrote:
>>>> Hi,
>>>>  
>>>> I cannot say the absolute irrelevance between the draft and the patent. Cleary, a choosing of concealment algorithm may affect the values contained in the protocol. And I think my colleagues make the IPR disclosure based on the following IETF IPR policy RFC3979
>>>> “
>>>>    Any individual participating in an IETF discussion who reasonably and
>>>>    personally knows of IPR meeting the conditions of Section 6.6 which
>>>>    the individual believes Covers or may ultimately Cover a Contribution
>>>>    made by another person, or which such IETF participant reasonably and
>>>>    personally knows his or her employer or sponsor may assert against
>>>>    Implementing Technologies based on such Contribution, must make a
>>>>    disclosure in accordance with this Section 6.
>>>> ”
>>>>  
>>>> And I checked the disclosure, which says
>>>> “
>>>> If any claim of any patent owned or controlled by Huawei or its Affiliates is essential on a technical ground to the standard adopted by IETF, Huawei on behalf of itself and its Affiliates hereby covenant not to assert any such claim against any party for making, using, selling, offering for sale or importing a product that implements the corresponding part of the standard. However, nothing herein shall preclude Huawei or any of its Affiliates from asserting the above mentioned patent claims against any party that asserts directly or indirectly a patent it owns or controls against Huawei and/or its Affiliates, or against any products of Huawei or its Affiliates either alone or in combination with other products.
>>>> FRAND royalty-bearing licenses will be available to anyone who prefers that option.
>>>> ”
>>>> I think it’s a quite weak declaration which does not license any patent claim to any friendly implementations. Instead, it’s only workable when companies want to use some patents against Huawei, plus it will also depend on if the judge decides the disclosure is workable or not. In such a case,  I don’t think implementers need to worry about this.
>>>>  
>>>> This work is technically reasonable and valuable, thus my position is to continue progressing it.
>>>>  
>>>> BR,
>>>> Rachel
>>>>  
>>>> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of Alan Clark
>>>> Sent: Thursday, March 10, 2016 12:30 AM
>>>> To: xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>  
>>>> Dan
>>>> 
>>>> I reviewed (again) the patent cited by Huawei in this disclosure and was not able to find any claims or descriptions related to metrics and reporting - only details of a video loss concealment algorithm, and the draft identifies only a reporting protocol and not a video codec; I will caveat this by saying that I've reviewed the English translation of the Chinese patent. 
>>>> 
>>>> While IETF patent policy does not require companies to defend their disclosures and does state that the IETF does not take a position on whether a patent does or does not apply to a draft/RFC I think it sets a bad precedent if a WG does not take objection to disclosures that appear to be irrelevant. Saying "are you sure about this?" to the disclosing company does not mean that the WG is making any statement on infringement, but does IMHO represent a reasonable degree of due diligence on behalf of the WG. If we don't push back on disclosing companies when we feel that the disclosure is based on an invalid understanding of the draft then we are doing a disservice to implementers and making the IPR situation more complex and messy than it already is.
>>>> 
>>>> My position is that we should not proceed with this document, based on the information we have at this time.
>>>> 
>>>> Regards
>>>> 
>>>> Alan Clark
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 3/8/16 7:41 AM, Romascanu, Dan (Dan) wrote:
>>>>> ALL WG participants – please answer this question before March 22, 2016.
>>>>>  
>>>>> Thanks and Regards,
>>>>>  
>>>>> Dan
>>>>>  
>>>>>  
>>>>> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of Romascanu, Dan (Dan)
>>>>> Sent: Tuesday, March 08, 2016 2:27 PM
>>>>> To: xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>  
>>>>> Hi,
>>>>>  
>>>>> We did not receive any answer to the request for further information.
>>>>>  
>>>>> At this point in time, we ask the working group to express their opinion about what to do with  draft-ietf-xrblock-rtcp-xr-video-lc.
>>>>>  
>>>>> We have two options:
>>>>>  
>>>>> 1.       Continue as planned with the approval and publication process
>>>>> 2.       Not proceed with this document.
>>>>>  
>>>>> All WG participants – please express you preference for option #1 or option #2.
>>>>>  
>>>>> Thanks and Regards,
>>>>>  
>>>>> Dan
>>>>>  
>>>>>  
>>>>> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of Romascanu, Dan (Dan)
>>>>> Sent: Sunday, February 07, 2016 11:29 AM
>>>>> To: Huangyihong (Rachel); Alan Clark; xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>  
>>>>> Hi,
>>>>>  
>>>>> There was one answer to this mail (from Alan) expressing preference for option #1. Let us go with it.
>>>>>  
>>>>> Rachel, it would be good if you can send your colleagues a reminder.
>>>>>  
>>>>> Thanks and Regards,
>>>>>  
>>>>> Dan
>>>>>  
>>>>>  
>>>>> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of Romascanu, Dan (Dan)
>>>>> Sent: Friday, January 29, 2016 8:34 AM
>>>>> To: Huangyihong (Rachel); Alan Clark; xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>  
>>>>> Thanks, Rachel, for the information and for the efforts to clarify the issue with the legal affairs department at your company.
>>>>>  
>>>>> We have a few more options about what to do next.
>>>>>  
>>>>> 1.  Wait a few more weeks for an answer with further information – I suggest no later than February 29, 2016
>>>>> 2. Proceed with the draft given the information available
>>>>> 3. Not proceed with the draft
>>>>>  
>>>>> All WG members – please express your preference.
>>>>>  
>>>>> Thanks and Regards,
>>>>>  
>>>>> Dan
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> From: Huangyihong (Rachel) [mailto:rachel.huang@huawei.com <mailto:rachel.huang@huawei.com>] 
>>>>> Sent: Friday, January 29, 2016 5:42 AM
>>>>> To: Huangyihong (Rachel); Alan Clark; Romascanu, Dan (Dan); xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>> Subject: RE: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>  
>>>>> Dear all,
>>>>>  
>>>>> Sorry for so late response to the mailing list.
>>>>>  
>>>>> I have forwarded this IPR issue to our legal affairs department responsible for this IPR disclosure. However, I didn’t get any information for now. And I’m not sure if they have any that could be shared within the mailing list or not (We all know that IETF policy doesn’t require the company to analysis and verify the applying, which is what the legal team or even court  should do when meeting some legal problems).
>>>>>  
>>>>> Meanwhile, I can’t do any clarification for them in public since we’re totally different departments. It will against our company’s law. …So it’s not within my control. Hope WG could understand that.
>>>>>  
>>>>> BR,
>>>>> Rachel
>>>>>  
>>>>> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of Huangyihong (Rachel)
>>>>> Sent: Friday, January 08, 2016 11:26 AM
>>>>> To: Alan Clark; Romascanu, Dan (Dan); xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>  
>>>>> Hi all,
>>>>>  
>>>>> Sorry for the late response. I’m in a business trip these two weeks with sporadic email access. So I may not respond timely.
>>>>> This IPR is from another department so I’m not quite familiar with it. I’ll invite the colleague who’s the IPR holder or responsible for the IPR disclosure to clarify in the mailing list. Hope we can find some way to solve this issue.
>>>>>  
>>>>> BR,
>>>>> Rachel
>>>>>  
>>>>> 发 件人: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] 代 表 Alan Clark
>>>>> 发 送时间: 2016年1月7日 0:21
>>>>> 收件人: Romascanu, Dan (Dan); xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>> 主题: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>  
>>>>> Hi Dan
>>>>> 
>>>>> Within the IETF patent policy there is no requirement that I'm aware of that requires a disclosing company to prove that the patent they reference does in fact apply to the draft/RFC, which means that companies could make disclosure statements that don't actually apply to the referenced draft/RFC. In many larger companies the IPR/legal team may be distant from the engineering team and I've seen cases in which allegations of infringement were made based on a text match rather than a technical analysis. If, as WG members, we feel that a disclosure may be inappropriate based on a technical understanding of the draft/RFC and the patent then IMHO we should be willing to politely point this out - if the disclosing company wants to keep the disclosure anyway then we have to leave it to individual implementers to obtain their own legal advice; my view is that as WG members and authors we should try and keep the IPR situation as clear as possible.
>>>>> 
>>>>> I've encountered exactly this situation - my company develops software that analyzes voice/ audio/ video stream performance and as part of this we model the performance of a wide range of voice/ audio and video codecs. We have been contacted numerous times by companies that have codec IPR and who see that we analyze streams encoded with the G.xyz codec - we then have to explain that we don't actually implement the codec, only a parametric model.
>>>>> 
>>>>> So - my position is that we should ask Rachel, as an author and a representative of the disclosing company, to request that Huawei verify that their disclosure does, in their opinion, apply. 
>>>>> 
>>>>> Regards
>>>>> 
>>>>> Alan
>>>>>  
>>>>> 
>>>>> On 1/6/16 9:40 AM, Romascanu, Dan (Dan) wrote:
>>>>>> Hi Alan,
>>>>>>  
>>>>>> The statement that was posted a few weeks back explicitly refers to this I-D – see https://datatracker.ietf.org/ipr/2725/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_2725_&d=BQMFbw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=kiLRy3Dy18TaCdFTLegz5r3LuHhd2B0eMVVxbhrJLt0&s=LLsGFzAZgTvcoyP_BY4A2BWWgGVV9e9ZAj16tjytCho&e=>. Of course, anybody can comment within the rules, but the fact that the disclosing company considers the IPR related to this I-D is public information.  
>>>>>>  
>>>>>> What is your position as WG participant and as co-author of the document? What should the WG do?
>>>>>>  
>>>>>> Thanks and Regards,
>>>>>>  
>>>>>> Dan
>>>>>>  
>>>>>>  
>>>>>>  
>>>>>> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of Alan Clark
>>>>>> Sent: Tuesday, January 05, 2016 10:06 PM
>>>>>> To: xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>>> Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>>  
>>>>>> I reviewed the patent that the disclosure related to - this appears to describe a method for video coding that uses loss concealment and not a method of reporting the effectiveness of loss concealment. It is of course the responsibility of the IPR holder to verify that their patent does in fact apply to the Draft/RFC to which their disclosure statement applies.  I suggest that the WG chairs ask the participants from the disclosing company to check to see if this disclosure is in fact relevant to the draft.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> Alan
>>>>>> 
>>>>>> On 1/5/16 7:34 AM, Romascanu, Dan (Dan) wrote:
>>>>>>> Hi,
>>>>>>>  
>>>>>>> There were no responses to this query. Please express your opinions on the mail list whether we should continue as planned with the approval for this I-D.
>>>>>>>  
>>>>>>> Possible options (other may apply):
>>>>>>>  
>>>>>>> 1.       Continue as planned
>>>>>>> 2.       Do not continue
>>>>>>> 3.       Continue, but first do …
>>>>>>>  
>>>>>>> Thanks and Regards,
>>>>>>>  
>>>>>>> Dan
>>>>>>>  
>>>>>>>  
>>>>>>> From: xrblock [mailto:xrblock-bounces@ietf.org <mailto:xrblock-bounces@ietf.org>] On Behalf Of Romascanu, Dan (Dan)
>>>>>>> Sent: Wednesday, December 16, 2015 12:55 PM
>>>>>>> To: xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>>>> Subject: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
>>>>>>>  
>>>>>>> Hi, 
>>>>>>>  
>>>>>>> As you may have seen an IPR disclosure that pertains to draft-ietf-xrblock-rtcp-xr-video-lc was submitted recently. The announcement on the XRBLOCK mail list with  more information can be read at http://www.ietf.org/mail-archive/web/xrblock/current/msg01914.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_mail-2Darchive_web_xrblock_current_msg01914.html&d=BQMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=JT0PNFMVTwcCOwfJFWR9rPXwWO3aXrz-8hcAnDMibu4&s=Y212mtSrLAN6yGGEigFnx-qwjZv_a0r5MpWucZswumg&e=>.  
>>>>>>>  
>>>>>>> This I-D was on the agenda of the IESG telechat this Thursday 12/17. Our AD decided to defer this I-D to the next telechat scheduled for January 7, 2016 and asked us to confirm on the mail list that the WG still plans to proceed with the I-D. 
>>>>>>>  
>>>>>>> Taking into account this new information – do the participants in the WG want to proceed with the approval of this Internet-Draft? Please state your opinions on the WG mail list until Monday January 4, 2016. 
>>>>>>>  
>>>>>>> Thanks and Regards,
>>>>>>>  
>>>>>>> Dan
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> xrblock mailing list
>>>>>>> xrblock@ietf.org <mailto:xrblock@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/xrblock <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_xrblock&d=BQMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=QnXfHHtrCWuOTN6ltI1OQl5JKpT1vIEt5lm6yyUl-K0&s=ZDjj6FP8ei9wzWsi7L54u3cKecOhJxcBl4LP8yojwBQ&e=> 
>>>>>  
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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>