Re: [Qirg] New Version Notification for draft-wang-qirg-quantum-internet-use-cases-00.txt

Joseph Touch <touch@strayalpha.com> Wed, 04 March 2020 15:02 UTC

Return-Path: <touch@strayalpha.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 9B2393A106C for <qirg@ietfa.amsl.com>; Wed, 4 Mar 2020 07:02:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.308
X-Spam-Level:
X-Spam-Status: No, score=-1.308 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_NEUTRAL=0.779, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 lVv7R3ViyYz4 for <qirg@ietfa.amsl.com>; Wed, 4 Mar 2020 07:02:33 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DACF3A105F for <qirg@irtf.org>; Wed, 4 Mar 2020 07:02:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=D9lm34jVwi7RRHpPKeufhH680h4l0dnPFem29mjMToc=; b=27gYM6w3MRsnsu90wFYyqmdjm SwnsZAcWeA2PxyJunvPoYkHbrKoIHmBBwGG6ffg7QyFsVmxumx9esVsj7gYxOd3lODmqaEJN9uotD asHhFoADzs33A8uKR1tAfFkKMqZlq3G69Du6hlRoVv4dx10EzULe31Eyy0qoQlioo4iUJYLRs8Q1E 0J7SiDy/kLXJs8swP8CxhDCJH98SPeI9HnllHc8YbUhKZbeZIi/8h87nQl0o4urZhpzQlxKvD3Tdw sugOVTt7xvfnUTNZ6ffLjh1DiwmzrDYAMFvPlzLPa73PUJkC8dzElzUVHWQyKGrjN5+FWCAp/9X+F aaBrKSVwg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:54346 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1j9VXL-002EOm-Vg; Wed, 04 Mar 2020 10:02:22 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_2C9F09EE-2F34-4F36-93E0-659F7188BC12"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <BFC157BD-1B50-417B-8CC5-7BCE1BB666AE@sfc.wide.ad.jp>
Date: Wed, 04 Mar 2020 07:02:14 -0800
Cc: Chonggang Wang <Chonggang.Wang@InterDigital.com>, Rodney Van Meter <rdv@sfc.wide.ad.jp>, Wojciech Kozlowski <W.Kozlowski@tudelft.nl>, "qirg@irtf.org" <qirg@irtf.org>
Message-Id: <863A2A0B-303E-491B-87A9-38A9E13D50CA@strayalpha.com>
References: <157913981596.22724.9800545284588992439.idtracker@ietfa.amsl.com> <BN8PR10MB3507E28FA2F1FB1E4812A78DF8360@BN8PR10MB3507.namprd10.prod.outlook.com><9521b1df55fcc060b0d9649e446ca6d7e1370074.camel@tudelft.nl> <BN8PR10MB3507B61E638718CAA926BB1BF8320@BN8PR10MB3507.namprd10.prod.outlook.com> <DM5PR10MB154575E5684C1F3771B03213F80A0@DM5PR10MB1545.namprd10.prod.outlook.com> <0d71101e489ea5293cb9d8b85bf76064a53bc21b.camel@tudelft.nl> <f528f1d57cd5c764855cdfd19ff337a367ddcf75.camel@tudelft.nl> <DM6PR10MB3225EBC945BE917AEF4E5F3AF8190@DM6PR10MB3225.namprd10.prod.outlook.com><582E25F2-0A90-4B5D-8C4C-6EC2BFB37438@sfc.wide.ad.jp> <DM6PR10MB322551A51B2962D571023F87F8ED0@DM6PR10MB3225.namprd10.prod.outlook.com> <DM6PR10MB32252DE88988B5010C00C302F8E40@DM6PR10MB3225.namprd10.prod.outlook.com> <BFC157BD-1B50-417B-8CC5-7BCE1BB666AE@sfc.wide.ad.jp>
To: Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/6l57SaMAblK8b5nzLYnigCt395M>
Subject: Re: [Qirg] New Version Notification for draft-wang-qirg-quantum-internet-use-cases-00.txt
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: Wed, 04 Mar 2020 15:02:38 -0000

Hi, Rod (et al.),

AFAICT, sensing is measuring a property other than that of the transmitter. 

Measuring properties of a transmitter is (IMO) communication. In that way, time sync is comm, not sensing.

(The only difference between QKD and comm to me is how errors are recovered; in comms they’re directly corrected where in QKD the “correction” is to restart)

Note: that perspective explains why quantum computing isn’t also sensing. It also is consistent with the existing continuum between computing and communication. 

I.e., why is crypto in this list vs. being a special case of communications?

Joe

> On Mar 4, 2020, at 3:43 AM, Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org> wrote:
> 
> Hi Chonggang,
> 
> I’ll take a look when I can. At a glance, the document seems to be evolving quite well.
> 
> Re: sensor networks, personally I classify QKD as sitting on the boundary between crypto and sensor: what it’s really doing is using quantum effects to sense the presence or absence of an eavesdropper in the channel while making shared, random, classical bits, which then can be used as crypto keys.  Clock sync is a good sensor app (actually, it might be better called “cybernetic uses” or something, but I’ve always lumped them together and called them “sensors”, as in real-world sensing).
> 
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies
> Keio University, Japan
> rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>
> 
> 
> 
>> On Mar 4, 2020, at 3:51, Chonggang Wang <Chonggang.Wang@InterDigital.com <mailto:Chonggang.Wang@InterDigital.com>> wrote:
>> 
>> Hi Rodney,
>>  
>> We have incorporated your comments into v04, which was just uploaded. Please let us know if your comments have been addressed and/or if you have any new ones.
>>  
>> https://www.ietf.org/id/draft-wang-qirg-quantum-internet-use-cases-04.txt <https://www.ietf.org/id/draft-wang-qirg-quantum-internet-use-cases-04.txt>
>>  
>> Thanks,
>> Chonggang
>>  
>> From: Chonggang Wang 
>> Sent: Tuesday, February 25, 2020 10:50 AM
>> To: Rodney Van Meter <rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>>
>> Cc: Wojciech Kozlowski <W.Kozlowski@tudelft.nl <mailto:W.Kozlowski@tudelft.nl>>; qirg@irtf.org <mailto:qirg@irtf.org>
>> Subject: RE: [Qirg] New Version Notification for draft-wang-qirg-quantum-internet-use-cases-00.txt
>>  
>> Hi Rodney,
>>  
>> Thank you for your comments from QIRG the chair’s and an individual’s perspective. I embedded some responses below and will discuss with my coauthors for a revision.
>>  
>> Best regards,
>> Chonggang 
>>  
>> From: Rodney Van Meter <rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>> 
>> Sent: Thursday, February 20, 2020 6:45 PM
>> To: Chonggang Wang <Chonggang.Wang@InterDigital.com <mailto:Chonggang.Wang@InterDigital.com>>
>> Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>>; Wojciech Kozlowski <W.Kozlowski@tudelft.nl <mailto:W.Kozlowski@tudelft.nl>>; qirg@irtf.org <mailto:qirg@irtf.org>
>> Subject: Re: [Qirg] New Version Notification for draft-wang-qirg-quantum-internet-use-cases-00.txt
>>  
>> Hi Chonggang,
>>  
>> I’ve been passively following the work here. As RG chair, I think this is important, and I’m happy you’re working on it and getting good feedback from others. I’ve only skimmed the I-D, not read it in detail so far, though.  Loking forward to talking about it in real time, if not in person, at Vancouver.
>> [CW: Thank you for the support. We will continue to improve this use case document based on all comments from you and the QIRG team]
>>  
>> <chair hat off>
>> On the content…
>>  
>> Re: position verification, my understanding is that it has been proven *impossible* in the quantum realm, which is a *very* interesting result:
>> @Article{buhrman14:_posit_based_quant_crypt,
>>   author =            {Harry Buhrman and Nishanth Chandran and Serge Fehr
>>                   and Ran Gelles and Vipul Goyal and Rafail Ostrovsky
>>                   and Christian Schaffner},
>>   title = {Position-based Quantum Cryptography: Impossibility
>>                   and Constructions},
>>   journal = {SIAM Journal on Computing},
>>   year = 2014,
>>   volume =          43,
>>   number =         1,
>>   pages =             {150--178},
>>   month =            feb,
>>   comment = {Prior to this, Chandran had shown that position-based
>>                   classical position-based cryptography (Defined in
>>                   this paper as, "The goal of position-based
>>                   cryptography is to use the geographical position of
>>                   a party as its only 'credential'.") is impossible, but
>>                   the quantum version was an open question.  That is,
>>                   a group of colluders can fool a classical position
>>                   verification scheme, but could a group of quantum
>>                   colluders fool a quantum verifier?  Turns out, the
>>                   answer is "yes" if the colluders have access to
>>                   pre-prepared entanglement, and so, sadly, even
>>                   quantum position-based crypto appears not to be
>>                   useful.  Interesting set of references.}
>> }
>> [CW: Thank you for bringing this good reference. We will double check the feasibility of “position verification” and may remove it from the use case set. ]
>>  
>> Trying not to say “you should cite me!”, and I don’t think I have time to contribute as an author to I’m happy to stay as an outside observer, but I’ve spent a lot of time working on apps for a Quantum Internet, and given a bunch of talks on it.  Overall, I divide uses of quantum networks up into three areas:
>>  
>> * crypto functions: QKD, byzantine agreement, etc. Check out Ben-Or and Hassidim, and (ahem) Taherkhani & Van Meter. We were hoping QBA would make a good second app for QI, after basic QKD, but it’s harder than we thought — one-part-in-a-million error rates, couple of hundred qubits, etc. as resources.
>> * sensor (& reference frame) functions: clock sync — there are at least three or four proposals for this; also position reference frames, etc. An important one here is Gottesman’s interferometry.  Note that I put QKD on the border between cerypto & sensor, since its function is to act as detection of a physical eavesdropper.
>> * distributed computing: Broadbent, Kashefi, Fitsimons, Barz and their blind computation is one of *the* best reasons to build a QI — but it has *tremendous* resource requirements in its current form.  Finding lower-resource uses for blind QC is a great research area, IMO.
>> [CW: Thank you for the valuable comment. Currently, the use case document covers the 1st and 3rd area at some degree although we were thinking to write something on sensor functions. We will try to organize use cases according to those three areas you mentioned above, in next version of the use case document.]
>>  
>> Rodney Van Meter
>> Professor, Faculty of Environment and Information Studies
>> Keio University, Japan
>> rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>
>>  
>>  
>>  
>> 
>> On Feb 11, 2020, at 2:28, Chonggang Wang <Chonggang.Wang@InterDigital.com <mailto:Chonggang.Wang@InterDigital.com>> wrote:
>>  
>> Hi Wojtek,
>>  
>> Thank you for your feedback and detailed inline remarks. We will look at and incorporate them into v03.
>>  
>> I agree with you that a discussion in a F2F meeting (either Vancouver or Madrid) will be very helpful.
>>  
>> Thanks,
>> Chonggang
>>  
>> From: Wojciech Kozlowski <W.Kozlowski@tudelft.nl <mailto:W.Kozlowski@tudelft.nl>> 
>> Sent: Monday, February 10, 2020 11:42 AM
>> To: qirg@irtf.org <mailto:qirg@irtf.org>; Chonggang Wang <Chonggang.Wang@InterDigital.com <mailto:Chonggang.Wang@InterDigital.com>>
>> Subject: Re: [Qirg] FW: New Version Notification for draft-wang-qirg-quantum-internet-use-cases-00.txt
>>  
>> Forgot to actually attach document
>>  
>> On Mon, 2020-02-10 at 17:41 +0100, Wojciech Kozlowski wrote:
>> HI Chonggang,
>>  
>> Thanks for including my feedback. I have now read your draft in more detail. I attach a version with some in-line remarks (search for >>>) about the first few sections - they are all minor.
>>  
>> In general I think there's lots to discuss about the classification and the use cases in the later sections, but perhaps such a discussion would be good for an actual meeting? I'm still not sure if QIRG will be meeting in Vancouver (Rodney?), but whichever IETF will be next might be worth adding to the agenda.
>>  
>> Thanks,
>> Wojtek
>>  
>> On Tue, 2020-01-28 at 15:50 +0000, Chonggang Wang wrote:
>> Hi Wojceich,
>>  
>> Thank you again for your good comments on the use case document. We have revised the document according to all comments from you and a few other people. The v01 was just uploaded and can be accessed from the following link.
>> https://tools.ietf.org/html/draft-wang-qirg-quantum-internet-use-cases-01 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Dqirg-2Dquantum-2Dinternet-2Duse-2Dcases-2D01&d=DwMFAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=8Ul7lqKxYXuSiZKDc4OC4pCtVgjWDs557p5GfzN9FsM&s=Yl6ZZJgXjO0-KzW0QsZbF_2rwCY5rEtT1F0uUEAlxTE&e=>
>>  
>> Answers to your comments/questions are also provided below. Would you please review v01 and our answers and let us know if your comments have been addressed? If you have any new comment, we will be happy to address it and improve the document furthermore. 
>>  
>> 1. "You separate applications into control and data plane applications. However, it's not clear to me what exactly separates the two groups. Could you expand on that?"
>> [CW] - We rewrote and expanded section 4 to further clarify the concepts.
>>  
>> 2. "And one other important point about the end-node definition.   You write in your end-node definition that that it must be a quantum computer.  That is not the case. An end-node without full fault-tolerant capabilities, a quantum memory, or even a universal gate set is still useful. For QKD you don't even need to store the qubits at the end-nodes (prepare-and-measure stage in Wehner's Quantum Internet paper). Perhaps this is what you had in mind when you wrote quantum computer, but it is important to make it clear that end-nodes don't have to be as capable as quantum routers/repeaters. "
>> [CW] - Agreed and we clarified the end-node definition to reflect your points.
>>  
>> 3. "You also write that classical connectivity in the end-node is optional. I can't think of any application that would not need classical connectivity as well to coordinate with the application's remote. In general, I would say that all quantum network connected nodes also have classical connectivity."
>> [CW] - Agreed and we clarified the end-node definition to reflect your point.
>>  
>> 4. "Quantum Key Distribution(QKD);Components and Internal Interfaces :https://www.etsi.org/deliver/etsi_gr/QKD/001_099/003/02.01.01_60/gr_QKD003v020101p.pdf <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.etsi.org_deliver_etsi-5Fgr_QKD_001-5F099_003_02.01.01-5F60_gr-5FQKD003v020101p.pdf&d=DwMFAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=8Ul7lqKxYXuSiZKDc4OC4pCtVgjWDs557p5GfzN9FsM&s=f8UqUDuYVJ81YCc6F6tyCugOS2LfOJgBQnrBUaSobdM&e=>  NOTE: Entanglement-based schemes where entangled states are prepared externally to Alice and Bob are not normally considered "prepare-and-measure". Schemes where entanglement is generated within Alice can still be considered "prepare-and-measure". Send-and-return schemes can still be "prepare-and-measure" if the information content from which keys will be derived is prepared within Alice before being sent to Bob for measurement."
>> [CW] - The last paragraph of section 5.1 was revised to reflect your points.
>>  
>> 5. “A series of loopholes have been identified due to the imperfections of measurement devices. There are several solutions to take into account these attacks such as for example measurement-device-independent quantum key distribution https://arxiv.org/abs/1912.09642 <https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1912.09642&d=DwMFAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=8Ul7lqKxYXuSiZKDc4OC4pCtVgjWDs557p5GfzN9FsM&s=dnmk-npspZBud2lZcwBM_VQlzWsb1VT_Rz1JsPzSVvk&e=>  This operational solutions can work differently than the steps of BB84 protocol.”
>> [CW] - The last paragraph of 5.1 was revised to reflect your points.
>>  
>> 6. “It would be necessary to be able to extract the requirements on the networks. For this use case you consider that the targeted step is "prepared and measured" (https://pure.tudelft.nl/portal/files/47533107/qim_final_V7_FINAL.pdf <https://pure.tudelft.nl/portal/files/47533107/qim_final_V7_FINAL.pdf> ) ? And thus no need  entanglement distribution for long distance  ? The need for this use case is to have QKD Network base on trusted relays to take in account long distance communications?”
>> [CW] - The need for this use case is not only about trusted replays, but also entanglement distribution for long distance. In other words, our aim for having this use case is  to explain and show there are a variety of QKD protocols which may operate differently, and we need to consider as many as requirements from most of them, if not all. As such, we revised the last sentence in section 5.1 as follows:
>>               “As a result, the Quantum Internet in Figure 1 in order to support secure communication setup especially in large-scale deployment may contain quantum  channels, quantum repeaters/routers [I-D.irtf-qirg-principles], entanglement and entanglement distribution [I-D. van-meter-qirg-quantum-connection-setup-01], and/or trusted QKD relays.”
>>  
>>  
>> -----Original Message-----
>> From: Chonggang Wang 
>> Sent: Monday, January 20, 2020 3:56 PM
>> To: Wojciech Kozlowski <W.Kozlowski@tudelft.nl <mailto:W.Kozlowski@tudelft.nl>>; qirg@irtf.org <mailto:qirg@irtf.org>
>> Subject: RE: [Qirg] FW: New Version Notification for draft-wang-qirg-quantum-internet-use-cases-00.txt
>>  
>> Hi Wojciech,
>>  
>> Thank you for your feedback and good questions on our use case draft.
>>  
>> We will look into your questions and answer them in the mailing list and on a fast update of the draft.
>>  
>> Best regards,
>> Chonggang
>>  
>> -----Original Message-----
>> From: Qirg <qirg-bounces@irtf.org <mailto:qirg-bounces@irtf.org>> On Behalf Of Wojciech Kozlowski
>> Sent: Monday, January 20, 2020 11:44 AM
>> To: qirg@irtf.org <mailto:qirg@irtf.org>
>> Subject: Re: [Qirg] FW: New Version Notification for draft-wang-qirg-quantum-internet-use-cases-00.txt
>>  
>> Hi,
>>  
>> Great work on starting with a use case draft! It will definitely be useful.
>>  
>> I'm still going through the text so I can't provide a full commentary/feedback, but I do already have one question:
>>  
>> You separate applications into control and data plane applications. However, it's not clear to me what exactly separates the two groups. Could you expand on that?
>>  
>> And one other important point about the end-node definition.
>>  
>> You write in your end-node definition that that it must be a quantum computer.
>> That is not the case. An end-node without full fault-tolerant capabilities, a quantum memory, or even a universal gate set is still useful. For QKD you don't even need to store the qubits at the end-nodes (prepare-and-measure stage in Wehner's Quantum Internet paper). Perhaps this is what you had in mind when you wrote quantum computer, but it is important to make it clear that end-nodes don't have to be as capable as quantum routers/repeaters.
>>  
>> You also write that classical connectivity in the end-node is optional. I can't think of any application that would not need classical connectivity as well to coordinate with the application's remote. In general, I would say that all quantum network connected nodes also have classical connectivity.
>>  
>> Other than that, I'm still slowly going through the draft.
>>  
>> Wojtek
>>  
>> On Thu, 2020-01-16 at 14:33 +0000, Chonggang Wang wrote:
>> > Dear All,
>> > 
>> > We were thinking a use case document would be beneficial for QIRG. As
>> > such, we just prepared and uploaded a document on quantum internet use cases.
>> > 
>> > Your feedback and/or any interest in co-developing this document is welcomed.
>> > 
>> > Best regards,
>> > CG
>> > 
>> > -----Original Message-----
>> > From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>> > Sent: Wednesday, January 15, 2020 8:57 PM
>> > To: Chonggang Wang <Chonggang.Wang@InterDigital.com <mailto:Chonggang.Wang@InterDigital.com>>; Chonggang Wang <
>> > Chonggang.Wang@InterDigital.com <mailto:Chonggang.Wang@InterDigital.com>>; Akbar Rahman
>> > <rahmansakbar@yahoo.com <mailto:rahmansakbar@yahoo.com>>
>> > Subject: New Version Notification for
>> > draft-wang-qirg-quantum-internet-use-
>> > cases-00.txt
>> > 
>> > 
>> > A new version of I-D,
>> > draft-wang-qirg-quantum-internet-use-cases-00.txt
>> > has been successfully submitted by Akbar Rahman and posted to the IETF
>> > repository.
>> > 
>> > Name:draft-wang-qirg-quantum-internet-use-cases
>> > Revision:00
>> > Title:Applications and Use Cases for the Quantum Internet Document
>> > date:2020-01-15 Group:Individual Submission
>> > Pages:14
>> > URL:            
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_inte <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_inte>
>> > rnet-2Ddrafts_draft-2Dwang-2Dqirg-2Dquantum-2Dinternet-2Duse-2Dcases-2
>> > D00.txt&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k
>> > 8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy
>> > 0rzAssyFXySKEI&s=PMzmzur07rBP5gr4m8p4JB85MZMdmkT_WANusdrgIeY&e=
>> >  
>> > Status:         
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker..ietf>.
>> > org_doc_draft-2Dwang-2Dqirg-2Dquantum-2Dinternet-2Duse-2Dcases_&d=DwIC
>> > Ag&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWU
>> > ARpslGfYlRaP7D3dVZXHUEVc&m=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy0rzAssyFXySKEI
>> > &s=oE_6J9C-NK3Sg0X7tc15r37wija6fVyTtkTweA8H32I&e=
>> >  
>> > Htmlized:       
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht>
>> > ml_draft-2Dwang-2Dqirg-2Dquantum-2Dinternet-2Duse-2Dcases-2D00&d=DwICA
>> > g&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUA
>> > RpslGfYlRaP7D3dVZXHUEVc&m=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy0rzAssyFXySKEI&
>> > s=RUyxLSfDa9jkZJYQm-NwM55Qktzvkeez-xfrDiLI-LQ&e=
>> >  
>> > Htmlized:       
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker..ietf>.
>> > org_doc_html_draft-2Dwang-2Dqirg-2Dquantum-2Dinternet-2Duse-2Dcases&d=
>> > DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC
>> > 7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy0rzAssyFXy
>> > SKEI&s=hz2EZoCivsq91uNRPLpqD2ypMzVutblGbCGcNqKaY0s&e=
>> >  
>> > 
>> > 
>> > Abstract:
>> >    The Quantum Internet has the potential to improve Internet protocol
>> >    and application functionality by incorporating quantum information
>> >    technology into the infrastructure of the overall Internet.  In this
>> >    document, we provide an overview of some applications expected to be
>> >    used on the Quantum Internet, and then categorize them using the
>> >    standard telecommunications classification of control plane versus
>> >    data plane functionality.  We then provide detailed use cases for
>> >    selected applications which can help steer the development of the
>> >    requisite Quantum Internet functionality.
>> > 
>> > 
>> > 
>> > 
>> > Please note that it may take a couple of minutes from the time of
>> > submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> > 
>> > The IETF Secretariat
>> > 
>> > [Banner]
>> > 
>> > 
>> > [Banner]<
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__idcc.me_2ZVMLEv&d <https://urldefense.proofpoint.com/v2/url?u=https-3A__idcc.me_2ZVMLEv&d>
>> > =DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCju
>> > C7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy0rzAssyFX
>> > ySKEI&s=m5U3d47laqzfhiupIF0tuDwrDhJtosQdWAh3uvK3jls&e=
>> >  >
>> > ABI White Paper<
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__idcc.me_2ZVMLEv&d <https://urldefense.proofpoint.com/v2/url?u=https-3A__idcc.me_2ZVMLEv&d>
>> > =DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCju
>> > C7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy0rzAssyFX
>> > ySKEI&s=m5U3d47laqzfhiupIF0tuDwrDhJtosQdWAh3uvK3jls&e=
>> >  >
>> > This e-mail is intended only for the use of the individual or entity
>> > to which it is addressed, and may contain information that is
>> > privileged, confidential and/or otherwise protected from disclosure to
>> > anyone other than its intended recipient. Unintended transmission
>> > shall not constitute waiver of any privilege or confidentiality
>> > obligation. If you received this communication in error, please do not
>> > review, copy or distribute it, notify me immediately by email, and
>> > delete the original message and any attachments. Unless expressly
>> > stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>> > _______________________________________________
>> > Qirg mailing list
>> > Qirg@irtf.org <mailto: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=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy0rzAssyFXySKEI&s=nhxvSfcS-vT6ceZUnfRHsesl_Y73nfFC4qQadCS-nu4&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hwXW-AMJfMiAk-XdtOdqxqwr2uDYy0rzAssyFXySKEI&s=nhxvSfcS-vT6ceZUnfRHsesl_Y73nfFC4qQadCS-nu4&e=>
>> >  
>> _______________________________________________
>> Qirg mailing list
>> Qirg@irtf.org <mailto: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=DwMFAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=8Ul7lqKxYXuSiZKDc4OC4pCtVgjWDs557p5GfzN9FsM&s=cyCgu8AyFHjHCsse0yIulD_-i6-Y2g2Pme95aPNeYJQ&e=>
>>  
>> 
>> 
>> 
>>  <https://urldefense.proofpoint.com/v2/url?u=https-3A__idcc.me_2ZVMLEv&d=DwMFAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=8Ul7lqKxYXuSiZKDc4OC4pCtVgjWDs557p5GfzN9FsM&s=UKRL50t45cbbn8qlcg41u78fR0-vf1zWsyzJssm5eM0&e=>
>> ABI White Paper <https://urldefense.proofpoint.com/v2/url?u=https-3A__idcc.me_2ZVMLEv&d=DwMFAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=8Ul7lqKxYXuSiZKDc4OC4pCtVgjWDs557p5GfzN9FsM&s=UKRL50t45cbbn8qlcg41u78fR0-vf1zWsyzJssm5eM0&e=>
>> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>>  
>>  
>> 
>> 
>>  <https://www.interdigital.com/features/mwc-2020> 
>> Mobile World Congress 2020 <https://www.interdigital.com/features/mwc-2020>
>> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>> _______________________________________________
>> Qirg mailing list
>> Qirg@irtf.org <mailto:Qirg@irtf.org>
>> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>
>>  
>>  
>> 
>>  <https://www.interdigital.com/white_papers/streaming-media-report-> 
>> 
>> ABI - Streaming Media Report <https://www.interdigital.com/white_papers/streaming-media-report->
>> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg