Re: [Qirg] Pull request for 'new challenges' subsection 'The first quantum networks may not be "routing and forwarding" networks.'

Shota NAGAYAMA <shota.nagayama@mercari.com> Sun, 03 May 2020 04:28 UTC

Return-Path: <shota.nagayama@mercari.com>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D693A1424 for <qirg@ietfa.amsl.com>; Sat, 2 May 2020 21:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mercari.com
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 U3V7aXDBpXuY for <qirg@ietfa.amsl.com>; Sat, 2 May 2020 21:28:09 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CDF3A1423 for <qirg@irtf.org>; Sat, 2 May 2020 21:28:09 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id w7so7298777ybq.0 for <qirg@irtf.org>; Sat, 02 May 2020 21:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mercari.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UWku79pMSEY09366bNi/LsLPVRgmgnhJ12EPFSV8168=; b=NMpA72sVgX+fkjK7Sr6Jrxc7Ni6wrwRqNhvi6WZasjnm5Hayfi55rkft4PmzDPhDXI WjnxJ5j0hLF7fy81SJpsjW15XvqYHyhRB3csNUvo95iLaAyYyMkRWrMqFr1aiSeI2wcc L/FjsGHbvbfyYg6N72GZt5NIiWYLHs4BoEGvhYI2ed9vR1HcuFkTO97Gnb9XI5691qEn KJ6nk08oc5FKuUj6qGtAjLVzhtvNOCTiKwoXWRFTzRjjV83hC9aLKM9Y70OnBGYlWbhc DGjW46vilA8T06cUIx8ZEjcBv29Uw/n2ALL8e7cO7GMOU/dGHsT5s2G5glU+YzYL+Yds 9X3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UWku79pMSEY09366bNi/LsLPVRgmgnhJ12EPFSV8168=; b=NhryVDNY8xdyMXSB+BozfM7ONN/dVA173ye6VlLvJMIcVsJ+iq3Cf3uDXA6SwItJFu XlqYVCpFFhyd3AyLgoJO8NOd02/nnWPySJ/l27WcQv4QWvQ+6RBZuSDeFEKHdlRdeeto E4IhzsZOvSGym2icO2yjSfU2kHdyDXg40vCKlWRfaSyCktArRYL9Zjk4PKOAOeUo+aJL eJx2X7sHjoiojumtr/b3Dn5mCenLBFKWMVjKoJhX1cYuL1zIPiNPXMair+/tlPSWDkHZ zhDpvS73JePV/dK5jf0B0BtYHNDhO8L3F5GCWlOisMzXlDzuOa0LP28Fr49er7sSFwdK fs9w==
X-Gm-Message-State: AGi0PuZNGtOu8dkSN9QfRIfXnCv8yxE0VEDhvSAThYZX7Ooi1r20DrZY 8BEA65RclhNZshyrJxOKzEvprhlKc3shLPSYxddK/evkQEI=
X-Google-Smtp-Source: APiQypJ3rPSSda8dpZ5pKDaaf9NrrOtuFHFngH+EG3Jv252Ecv+/kGNnCbflYacNR862F1M5AOqT+JqqMGpZLJWFKeY=
X-Received: by 2002:a25:6991:: with SMTP id e139mr19092857ybc.385.1588480087847; Sat, 02 May 2020 21:28:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAG_2Tb88O=CdGfUnf1+yrwQfUdR=pM8rYKB4Z9FW_yfPpL-iTQ@mail.gmail.com> <ca6fe3bc4f529e46dd3d93b46e40550148c11cb9.camel@tudelft.nl> <CAG_2Tb_Lnp3xdQzgi6CR3yxOnkSRk30pGPAATn1g2eo1e5sXHA@mail.gmail.com> <5c12aa32971397ff95dd881853738dd9efdca016.camel@tudelft.nl> <CAG_2Tb_CRrskKSk6NiLpQdy0Kbc51cjQ40=1F57baDsP5R4USw@mail.gmail.com> <c4ccf966b6613280b75afb82f933ecf239904772.camel@tudelft.nl> <393311e1644c4a32b1d80d0af8970630@thalesaleniaspace.com> <MN2PR11MB3936A5B9406E06186C92FC60C1AF0@MN2PR11MB3936.namprd11.prod.outlook.com> <650d6e197303ee7ae290fe9fdd0483b3fdd9590b.camel@tudelft.nl>
In-Reply-To: <650d6e197303ee7ae290fe9fdd0483b3fdd9590b.camel@tudelft.nl>
From: Shota NAGAYAMA <shota.nagayama@mercari.com>
Date: Sun, 3 May 2020 13:27:57 +0900
Message-ID: <CAG_2Tb_Kk5N=70Sa0gWmHCMFw3nBZr4ZYoNMeqmgf6ZaCys=jA@mail.gmail.com>
To: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
Cc: "qirg@irtf.org" <qirg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000005e956105a4b6d721"
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/6OFZLD6y9-Z_vfyGaPFKfOMkRGA>
Subject: Re: [Qirg] Pull request for 'new challenges' subsection 'The first quantum networks may not be "routing and forwarding" networks.'
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2020 04:28:12 -0000

I have the same understanding; the progression 1G->2G->3G is about reducing
latency. The problem caused by this latency is not only decoherence but the
occupation of the memory qubits. The next Bell pair generation cannot start
during this latency. This will hit the performance.

Wojtek, I separate the pull request and merged your proposed changes to my
PR. Please see it.

------------------------------------------------
永山翔太 Shota Nagayama
shota.nagayama@mercari.com
https://shota.io/
https://qitf.org/
https://r4d.mercari.com


On Tue, Apr 28, 2020 at 11:00 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
wrote:

> Fair point Mathias.
>
> I'm still thinking about how best to include the generations into the
> draft. Most practical work is focused on what some call the first
> generation and the draft itself is heavily inspired by this particular
> generation.
>
> Subsequent generations describe the new possibilities as our technological
> capabilities increase. I'm not exactly clear if a new generation fully
> obsoletes the previous one, because whilst they improve upon the previous
> generation in certain aspects they also come with higher requirements in
> other areas.
>
> I'm pretty sure there is quite a bit of interest in including generations
> in this draft - at least a mention on what they are even though the focus
> is on the first. I think this point merits some discussion so I wills start
> off by leaving two articles that I usually refer to on this subject:
>
> - https://www.nature.com/articles/srep20463 (should be open access)
> - https://ieeexplore.ieee.org/abstract/document/7010905/
>
> The second article isn't open access and I can't find an arXiv version.
> I'm not the author so I'm not sure how okay it is to just share the pdf on
> a public mailing list as much as I'd like to do just that. I'd rather avoid
> the same trouble Sci-Hub got into. If somebody who knows copyright law
> knows how to correctly distribute such articles, please let me know.
>
> To answer your question Mathias, I tried phrasing that 3G enables rather
> than warrants direct transmission though I have some reading up to do since
> I don't really spend much time thinking about anything other than 1G. It
> may be, that as you say, that an infrastructure we deploy puts certain
> constraints on how the technology develops which is sort of the reason why
> I don't spend much time thinking about what will be when 3G becomes
> possible.
>
> Ultimately, my impression is that the progression 1G->2G->3G is more about
> reducing classical communication that causes latency. As Scott said, we can
> send Megabytes of data if that helps, but latency is usually the focus in
> this progression.
>
> Thanks,
> Wojtek
>
>
> On Mon, 2020-04-27 at 15:18 +0000, Scott Fluhrer (sfluhrer) wrote:
>
> I would like to point out that there are certainly classical networks that
> use “circuit switching”, that is, setting up a long term network path
> between two end points, and then using that path to allow the two end
> points to communicate.  Examples of this would be both MPLS and OTN.
>
>
>
> On the other hand, we shouldn’t feel constrained to do what classical
> networks do.  For one, the relative costs for a Quantum Network would be,
> at times, radically different than the corresponding costs for a classical
> one.  For a Quantum Network, control traffic (that is, the traffic used to
> manage the flow through the network) can be done using classical bits, and
> so are almost free in comparision to the data traffic bits (which are
> qubits); if we could reduce by one the number of qubits that need to be
> exchanged, at the cost of exchanging a megabyte of classical control
> traffic, it would make sense for us (but would make absolutely no sense in
> the classical case).
>
>
>
> Hence, while it makes sense to use classical protocols as a source of
> ideas (they thought about it a lot, and so perhaps we can reuse some of
> what they came up with), we need to remember that the things they optimized
> for are not always the things we need to optimize for…
>
>
>
> *From:* Qirg <qirg-bounces@irtf.org> *On Behalf Of *VAN DEN BOSSCHE
> Mathias
> *Sent:* Monday, April 27, 2020 10:34 AM
> *To:* qirg@irtf.org
> *Subject:* Re: [Qirg] Pull request for 'new challenges' subsection 'The
> first quantum networks may not be "routing and forwarding" networks.'
>
>
>
> Hi all,
>
>
>
> Looking at the discussion on github, I am a bit puzzled at this idea of
> store-and-forward.  Actually, it deserves a motivation.
>
> As we put it in the early generations, QIN establish an end-to-end
> entanglement link, and when it is ready, use it to send qbits directly end
> to end.
>
> In a telephone network, it is like pulling a new copper or a new fiber
> anytime you want to make a call.
>
>
>
> Later generations are proposed that tend to look more like classical
> networks (store-and-forward, i.e. routing, transport, etc).
>
> It is clear that doing this will require progress in the nodes. But is it
> worth the pain? Of course in classical networks, pulling a new line is
> awfully costly.
>
> Would it be so with entanglement ? Do we have to let us drive by analogy
> with classical networks? Aren’t there more options for
>
> next generations (e.g. quantum broadcast with multipartite entanglement,
> etc)?
>
>
>
> Just to get some light
>
>
>
> Mathias
>
>
>
>
>
>
>
> [@@ THALES ALENIA SPACE INTERNAL @@]
>
>
>
> *De :* Qirg [mailto:qirg-bounces@irtf.org <qirg-bounces@irtf.org>] *De la
> part de* Wojciech Kozlowski
> *Envoy**é :* lundi 27 avril 2020 14:20
> *À :* shota.nagayama@mercari.com
> *Cc :* qirg@irtf.org
> *Objet :* Re: [Qirg] Pull request for 'new challenges' subsection 'The
> first quantum networks may not be "routing and forwarding" networks.'
>
>
>
> Hi Shota,
>
>
>
> Thanks for the update! I've just reviewed it:
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/5#pullrequestreview-400873270
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_5-23pullrequestreview-2D400873270&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=0t7Khb_IckCCk62CLYBL3K6GC1lJFnJi-SxvcdXy0ps&s=td4j-NUySEg_1AMWyxCg-xLep1ki_8m7xCxi-XeeOV8&e=>
>
>
>
> Summary of my comments (follow the link for details):
>
>
>
> I would like to spend some more time on the generation section though. I
> need to think more about what this section should contribute to the
> document. There is nothing wrong with what you wrote, I'd just rather not
> include it until I'm clear on what its contents should be and then I'll
> come back to your contribution.
>
> However, the text about directionality, once you have a look at my
> proposed changes, can already be included. Since the generation section is
> currently in the same PR, if you would like your contributions merged
> sooner, please submit the section about generations as a separate PR, and I
> will merge the rest.
>
>
>
> Thanks,
>
> Wojtek
>
>
>
> On Sat, 2020-04-18 at 08:35 +0900, Shota NAGAYAMA wrote:
>
> Hi Wojtek,
>
>
>
> I've updated the pull request.
>
> I meant to clarify that routing would be the same, however, it might have
> been confusing. I have left out routing; just store-and-forward and
> store-and-swap are compared. And I added a section about generations.
> Please see other points on the pull request page and the document.
>
>
>
> --Shota
>
> ------------------------------------------------
>
> 永山翔太 Shota Nagayama
>
> shota.nagayama@mercari.com
>
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=W1Dk7HRbhwba24hJPb0j3cNNRjQX3Qhi-qYejXhGGdY&e=>
>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=QjsA76ECOj4SzbwZP1_NVqZbEi18Eaq7kx1Ty8PbVvg&e=>
>
> https://r4d.mercari.com
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__r4d.mercari.com&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=SA7SzipWOrNiFcQfsdO72wJheFD3TpWHiYjuW9gVXB4&e=>
>
>
>
>
>
> On Fri, Apr 3, 2020 at 6:32 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
> wrote:
>
> Hi Shota,
>
>
>
> Thanks for your contribution!
>
>
>
> I've reviewed your update. My detailed review comments are on the GitHub
> repo:
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/5#pullrequestreview-387089034
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_5-23pullrequestreview-2D387089034&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=epUqRQwb6LPd2qi2Qipww5ec3JG1D74NvadCBq7WQNQ&e=>
>
>
>
> In summary:
>
>
>
> Overall, I think your contribution makes a very important point that will
> be very useful for people coming from a classical background. My comments
> are mostly about clarifying what you meant. With further clarifications,
> your contribution can be merged.
>
>
>
> I am also not sure about this "routing and forwarding" and "routing and
> swapping" terminology. Is it common? I know of "store-and-forward" and
> perhaps we can say "store-and-swap" which highlights the need for memory
> (some proposals do not need a memory, not sure if they will be practical
> any time soon though). Also "store-and-swap" suggests we can keep things in
> memory for a long time which is not the case. I think this would be a good
> point to discuss. I would definitely suggest leaving routing completely out
> of this section as it is not actually discussed at all.
>
>
>
> Wojtek
>
>
>
> On Tue, 2020-03-31 at 14:02 +0900, Shota NAGAYAMA wrote:
>
> Hi Wojtek,
>
>
>
> How are things going? I'm looking forward to your review.
>
>
>
> BTW, it's very nice that now you are a co-chair of the group :)
>
>
>
> Thanks,
>
> Shota
>
> ------------------------------------------------
>
> 永山翔太 Shota Nagayama
>
> shota.nagayama@mercari.com
>
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=e7e0ouv4Yq7s8KyDdBBHKM7RF-nKr_0iLOZsRcyKMxk&e=>
>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=y3h0gz6GnUT9x1OpbKkqX_2CMG3DZ5pMnFpmwIExaTI&e=>
>
> https://r4d.mercari.com
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__r4d.mercari.com&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=7AWoJwX6ypg-cUFHSwdyQaxiRB4mWAUdlwWH0CMNmyg&e=>
>
>
>
>
>
> On Mon, Mar 9, 2020 at 5:53 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
> wrote:
>
> Hi Shota,
>
>
>
> Thanks for your contribution. I haven't had time to look at it yet so I
> won't include it in the draft I upload today. I will try to review it
> before Vancouver though so at least the work can still go on.
>
>
>
> Thanks,
>
> Wojtek
>
>
>
> On Fri, 2020-03-06 at 01:51 +0900, Shota NAGAYAMA wrote:
>
> Hi,
>
>
>
> I finally made a pull request for 'The first quantum networks may not be
> "routing and forwarding" networks.' subsection in the new challenges
> section. This subsection tells what is caused by the fact that Bell pairs
> are undirected network resources. Please find it.
>
>
>
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/5
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_5&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=-sTHDClmClG4EIhCAKj9azqNfPLpgPb_e0cEi-3bmys&e=>
>
>
>
> ------------------------------------------------
>
> 永山翔太 Shota Nagayama
>
> shota.nagayama@mercari.com
>
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=Qx2Pi5RpW5eFvMfMQc_CwyafjSl8U7c1ZtiUXV8imDo&e=>
>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=n0L3EMEwnxHvv2LAuLvgxvvKDoaCjL9PRCiPtFfUTV8&e=>
>
> https://r4d.mercari.com
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__r4d.mercari.com&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=fOR-fYIq-0jJJzCMkbmHPjRgDX9VvP5tEEGb7S39W4M&e=>
>
> _______________________________________________
>
> Qirg mailing list
>
> Qirg@irtf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=AsjKClF3rnjkQc4PUebFFsqBP_YQrh5cNjyCqvalD68&e=
>
>
>
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=xwTVo7VAuf97wRriYn1xNDrsJRtkD5tIx94Wcce68ps&e=>
>
> _______________________________________________
>
> Qirg mailing list
>
> Qirg@irtf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=0t7Khb_IckCCk62CLYBL3K6GC1lJFnJi-SxvcdXy0ps&s=Qh9EQs0OUnn6Nw3voV0VAFmol43Sv3zKY00Q5qBGaFA&e=
>
>
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg
>