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

Alan Clark <alan.d.clark@telchemy.com> Fri, 11 March 2016 11:20 UTC

Return-Path: <alan.d.clark@telchemy.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 E81AC12D666 for <xrblock@ietfa.amsl.com>; Fri, 11 Mar 2016 03:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Odno0CsNZZBy for <xrblock@ietfa.amsl.com>; Fri, 11 Mar 2016 03:20:48 -0800 (PST)
Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E0012D50C for <xrblock@ietf.org>; Fri, 11 Mar 2016 03:20:47 -0800 (PST)
X-SBRS: -4.0
X-HAT: Sender Group GREYLIST_RELAY_PORT587, Policy $GREYLIST_RELAY applied.
X-Hostname: omx02bay.sys.cbeyond.net
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2A7AwC4qeJWPBjTYUxeKAECgkdMUm26KwENgWoDFwEIgj2CaEQDAQEBAoEnORQBAQEBAQEBBgEBAQFBQIRBAQEBBAEBARcBCAopGAoRCQIRAgIBAQEJDAoBAQYDAgIJAwIBAgEVEgoDCQgGAQwGAgEBBYgbBQmQb50Xjx8BAQEBAQEBAQEBAQEBAQEBAQEBAQEViVx+hAoQAgEoDh0JgkGBOgWOKoRWhEOFbYJyhwFLg32DJoUwjnEeAQGCDjcZFIFSHi4BAQGKTgEBAQ
X-IPAS-Result: A2A7AwC4qeJWPBjTYUxeKAECgkdMUm26KwENgWoDFwEIgj2CaEQDAQEBAoEnORQBAQEBAQEBBgEBAQFBQIRBAQEBBAEBARcBCAopGAoRCQIRAgIBAQEJDAoBAQYDAgIJAwIBAgEVEgoDCQgGAQwGAgEBBYgbBQmQb50Xjx8BAQEBAQEBAQEBAQEBAQEBAQEBAQEViVx+hAoQAgEoDh0JgkGBOgWOKoRWhEOFbYJyhwFLg32DJoUwjnEeAQGCDjcZFIFSHi4BAQGKTgEBAQ
X-IronPort-AV: E=Sophos;i="5.24,320,1454994000"; d="scan'208,217";a="213939020"
Received: from c-76-97-211-24.hsd1.ga.comcast.net (HELO Alans-MacBook-Pro.local) ([76.97.211.24]) by omx.cbeyond.com with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 Mar 2016 06:20:28 -0500
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>, "xrblock@ietf.org" <xrblock@ietf.org>
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>
From: Alan Clark <alan.d.clark@telchemy.com>
Message-ID: <56E2A9F9.3060209@telchemy.com>
Date: Fri, 11 Mar 2016 06:20:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E8F428@nkgeml513-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------080205020003090503060203"
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/Nv-tt1Wd1HEuQJltmUgpGE2F_CI>
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: Fri, 11 Mar 2016 11:20:52 -0000

Hi Rachel

On your comments related to patent hearings and litigation - this is not 
the amicable, collegiate process that you seem to think. From personal 
experience (including numerous court appearances in patent cases, many 
depositions (including one mammoth 8 hour session), and many behind the 
scenes negotiations) I can assure you that patent litigation is a 
hostile and expensive process and it is much better to avoid placing 
implementers in this situation.  The only good aspect to patent 
litigation is the job security it provides to attorneys :-)

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]
> *Sent:* Thursday, March 10, 2016 10:08 PM
> *To:* Huangyihong (Rachel); 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
>
>        personallyknows of IPR meeting the conditions of Section 6.6 which
>
>        the individual believes Covers or may ultimately Covera
>     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] *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] *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] *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] *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]
>         *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] *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] *代 表
>         *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] *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] *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
>