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

[Shota NAGAYAMA <[e-mail]>]

Hi Wojtek,

First, thank you for merging :)
I merged the sentences separated from PR #5 to PR #6.

I agree that either categories or classes is a better terminology than
generations. This document may be the only chance to start to use better
terminology. I think that we should still mention the word "generations" to
clarify the rephrase.
Latter pointings are also correct, I think.

Best,
Shota
------------------------------------------------
永山翔太 Shota Nagayama
[e-mail]
https://shota.io/
https://qitf.org/
https://r4d.mercari.com


On Wed, May 13, 2020 at 5:57 PM Wojciech Kozlowski <[e-mail]>
wrote:

> Hi all,
>
> Following a discussion with a colleague of mine who is more familiar than
> me on the literature on repeater generations here are some thoughts. This
> should answer the questions raised about 3G and store-and-forward.
>
> This is with regards to Shota's PR:
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6
>
> A lot of what I say can be read up further on in one of the articles I
> linked earlier, which is open access:
> https://www.nature.com/articles/srep20463.pdf
>
> First of all: the name "generations" is slightly confusing. It implies a
> definite temporal progression. In some sense there is a temporal
> progression as 2G and 3G have signifiant hardware requirements (number of
> qubits and gate quality) which are not possible at the moment. However, the
> authors of the linked paper above, say that these generations are merely
> *categories*, and which generation's architecture is best depends on your
> hardware parameters as summarised with the plots in Fig. 6 of the linked
> paper. The generations in some sense represent what hardware trade-off is
> being made.
>
> So the section on generations in the draft should definitely emphasize
> that this is not a temporal progression where 2G obsoletes 1G and 3G
> obsoletes 2G. Some might argue we should choose a better name, but I'd
> rather not reinvent terminology in this draft as it will make it difficult
> to understand the references and existing academic literature.
>
> Second: store-and-forward vs store-and-swap. A particular feature of 3G is
> that it enables what is called "one-way signalling" which means that we can
> send qubits hop-by-hop from source to destination. However, just because we
> can does not mean we have to. We can also simply use this one-way signaling
> to create entangled pairs as well. A problem with 3G though is that because
> "one-way signalling" can only tolerate up to 50% losses the repeater is
> more constrained and as was pointed out - rebuilding an infrastructure is
> not a sane solution.
>
> I suspect that even once 3G becomes possible we may want to stick to Bell
> pairs anyway. Though they may be created differently in 3G as they don't
> use heralding. Bell pairs have advantages that one-way signalling does not.
> Intuitively, it appears far better suited for traffic-engineering purposes
> because you can distribute entangled pairs before the user needs them. With
> one-way signaling, just like in classical networks you would only be able
> to engineer once it actually is flowing. The advantage of 3G though is that
> it will rely less on connection-oriented architectures which may be
> beneficial in some circumstances. Perhaps what we will see is entangled
> pairs in the core/backbone and one-way signalling when connecting to users.
>
> So another point we would need to make in the draft is that 3G =/=
> store-and-forward. It simply enables store-and-forward, but 3G can still be
> used for store-and-swap.
>
> Third: there are other engineering trade-offs to take into account in
> between the generations that may have to be reflected at the protocol
> level. 1G uses heralded entanglement generation and purification, both of
> which require two-way classical communication. 2G uses heralded
> entanglement generation, but error-correction instead of purification.
> Error-correction requires only one-way classical signalling. 3G uses
> error-correction to overcome losses as well as operational errors and no
> longer requires two-way classical signalling.
>
> This is a point worth making in the draft as it will translate into
> protocol design.
>
> What's next? If anybody has anything to add/correct me, ask questions,
> please go ahead. Once there is nothing more to add Shota and I will extract
> the conclusions and reflect them in the PR.
>
> Regards,
> Wojtek
>
> On Sun, 2020-05-03 at 13:27 +0900, Shota NAGAYAMA wrote:
>
> 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
> [e-mail]
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=hvo4RtMWFHwRl8UqmDpyhSXz5wVhDfmHOIkg9WhX67Q&e=>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=PivNY9mnrbRsBeFBto3cl7pNKq7iJJlRGqeBQN5Ip8c&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=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=5RtpHFHRPogNJ5xHCcdXBR0qL0Q4xpMzbiwFTHde8eM&e=>
>
>
> On Tue, Apr 28, 2020 at 11:00 PM Wojciech Kozlowski <
> [e-mail]> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nature.com_articles_srep20463&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=4JKywxFHCPgIvFZef4QSi5To3q-HHTLmZQXfsKYacuc&e=>
> (should be open access)
> - https://ieeexplore.ieee.org/abstract/document/7010905/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ieeexplore.ieee.org_abstract_document_7010905_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=p8vXtRSBi2vSBoXf7GDRh7KTMzkKliOjQ01Z_g0z1d4&e=>
>
> 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 <[e-mail]> *On Behalf Of *VAN DEN BOSSCHE
> Mathias
> *Sent:* Monday, April 27, 2020 10:34 AM
> *To:* [e-mail]
> *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:[e-mail] <[e-mail]>] *De la
> part de* Wojciech Kozlowski
> *Envoy**é :* lundi 27 avril 2020 14:20
> *À :* [e-mail]
> *Cc :* [e-mail]
> *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
>
> [e-mail]
>
> 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 <[e-mail]>
> 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
>
> [e-mail]
>
> 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 <[e-mail]>
> 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
>
> [e-mail]
>
> 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
>
> [e-mail]
>
> 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
> [e-mail]
> 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
>
> [e-mail]
>
> 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
> [e-mail]
> 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=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=HdHbxHeMvK3Hj8qOHkgo1KEpEAOlGmQ0Fv2Pmm5bnH8&e=>
>
>