Re: [Qirg] [Fwd: [Fwd: Re: draft-irtf-qirg-principles: goals and principles]]

Joey S <> Mon, 27 July 2020 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C6913A1B3A for <>; Mon, 27 Jul 2020 09:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Status: No, score=-2.02 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, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EYNlGn8PbsNX for <>; Mon, 27 Jul 2020 09:41:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7CF03A1B5D for <>; Mon, 27 Jul 2020 09:41:36 -0700 (PDT)
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1k06Bw-0004R5-ET for; Mon, 27 Jul 2020 18:41:34 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: 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=Hx0ANV9isCxgDXsTs6sOs9scHyY4I/4fczp5M5FbS5w=; b=XELvz1ZUr6VUz9o0vQNrww1gF M2Y46BjsQH1GZ11MUG2IjxlDRCHuepICnEaI934xepQBuFgopvzYQ5wNUAVQsbOJomeNG3YmegZ+z Z2Sxg+qHZNHV8M4JtoLqn7sRfbiNl/zBHnm7rTZpOkG6wGodEGsoI/LfX37TPOXB/82Bk=;
References: <> <> <> <> <>
From: Joey S <>
Message-ID: <>
Date: Mon, 27 Jul 2020 10:41:25 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gcqU1s3JmTdXffJpHobnNGIVZgPB9sPGM"
X-Virus-Scanned: by clamav at
X-Scan-Signature: fb094e2d055ef1a1cbbad8e57635461b
Archived-At: <>
Subject: Re: [Qirg] [Fwd: [Fwd: Re: draft-irtf-qirg-principles: goals and principles]]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2020 16:41:49 -0000

Dear QIRG,

In section 6.1. Goals of a quantum internet, in a similar way to this quote on point 2,
>>It should not be constrained due to considerations for early-stage hardware and applications

I think point 5.  Make them easy to monitor,
>>In order to manage, evaluate the performance of, or debug a network it is necessary to have the ability to monitor the network.
should/could include "while ensuring there'll be mechanisms in place to protect the confidentiality and integrity of the devices connected to it".

This would be so as not to repeat the limitations we currently deal with in, say, the DNS, which having been designed as an unencrypted point for control and administration, has suffered heavy exploitation and continues to be a source of debate on how to make it more secure now, decades after its design.

>>Furthermore, given one end of an entangled pair, it is impossible to tell where the other qubit is without any additional classical information.
Would there be a need for some type of metadata then? or duplicate qubits for monitoring purposes?

>>This implies that tracking entangled pairs necessitates some exchange of classical information.
Some definition on what classical information would need to be exchanged would also be good.

On point 6.  Ensure availability and resilience, and mostly out of curiosity, are there any projections/estimates on where will quantum networks be available? Will the implementation/deployment costs be too high so as to restrict its access/use to developed countries? or is it foreseeable that at some point all sectors of society could benefit from it?

Lastly, in section 8.  Security Considerations
>>Even though no user data enters a quantum network
Could I be pointed to references that explain this part please? Is user data confined to classical channels? Apologies if that's already somewhere in this draft and I missed it.

Thank you all,
Joey Salazar
Digital Sr. Programme Officer
6E9C 95E5 5BED 9413 5D08 55D5 0A40 4136 0DF0 1A91
On 12-Jul-20 3:26 PM, Wojciech Kozlowski wrote:
Dear QIRG,

I have updated the doc following the feedback received at the interim meeting. You can find the latest version here:" rel="nofollow">


On Tue, 2020-06-09 at 15:04 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

If you have any remarks as to the above, please let me know and I'll upload a revision.

My next step will be to include all the points raised in the meeting + some that were raised on the mailing list over the past few months (including Shota's generation PR).

I will write a separate e-mail about the discussion we agreed to take to the mailing list.


On Tue, 2020-06-09 at 11:56 +0000, Wojciech Kozlowski wrote:
5 miutes

On Tue, 2020-06-09 at 07:21 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

Reminder that this call is today at 12:00 UTC.

-------- Forwarded Message --------
From: Wojciech Kozlowski <>
Subject: [Qirg] [Fwd: Re: draft-irtf-qirg-principles: goals and principles]
Date: Wed, 03 Jun 2020 10:07:14 +0000

Dear QIRG,

Calender event: attached

The aim of this call is to step over section 6, review existing points, discuss, and suggest any additions. Experienced advice from people who helped build/witnessed/understand the current Internet architecture and its evolution would be very useful. This section is less about quantum, but more about how to correctly apply the lessons from the classical Internet to the Quantum Internet.

This is the last item that needs a discussion. Following this call I plan to include the feedback that's still waiting on my todo pile (including the generations pull request from Shota) and prepare a final version for top-down review by July.

6.1.  Goals of a quantum internet

   1.  Support distributed quantum applications
   2.  Support tomorrow's distributed quantum applications
   3.  Support hardware heterogeneity
   4.  Be flexible with regards to hardware capabilities and limitations
   5.  Ensure security at the network level
   6.  Make them easy to manage and monitor
   7.  Ensure availability and resilience

6.2.  The principles of a quantum internet

   1.  Bell Pairs are the fundamental building block
   2.  Bell Pairs are indistinguishable
   3.  Fidelity is part of the service
   4.  Time is part of the service


-------- Forwarded Message --------
From: Wojciech Kozlowski <>
Subject: Re: [Qirg] draft-irtf-qirg-principles: goals and principles
Date: Tue, 19 May 2020 15:03:57 +0000

I have scheduled a virtual meeting on June 9 at 12:00 UTC. Below are the call details and a calendar event is attached.

draft-irtf-qirg-principles: goals and principles
Hosted by Quantum Internet Research Group

Tuesday, Jun 9, 2020 5:00 am | 1 hour | (UTC-07:00) Pacific Time (US & Canada)
Meeting number: 617 400 539
Password: a37wSAQ2DDZ
Agenda: Review section 6 of draft and discuss possible additions

Join by video system
You can also dial and enter your meeting number.

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 617 400 539

On Fri, 2020-05-15 at 08:18 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

A bit of background on what I want to do here:

Sections 1-5 set the scene as to what quantum networks are, how they function, etc. Section 6 is about looking forward. Given that we know the building blocks, what do we actually want to build with them? What matters more, what matters less? What should one keep in mind when designing protocols?

As RFC 1958 shows this need does not need to be an extensive section, but it's a good place to think a bit how the challenges introduced in the first few sections translate into protocol design.

This section will definitely benefit from protocol design/implementation experience.


On Tue, 2020-05-12 at 17:42 +0000, Wojciech Kozlowski wrote:
Hi all,

Added two more dates for additional flexibility: June 9 and June 10 (same times). So the meeting options are now June 2, 3, 9, or 10.


On Tue, 2020-05-12 at 16:47 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

To make progress on the Architectural Principles draft one last item of work remains which is section 6: goals and principles. Most of the document is informative and more of a review in content. However, this section allows us to bring some innovative and fresh ideas to the table and it would be great if as the QIRG we could try and do that.

The section is already non-empty so what I'm looking for is to 
  • go over what's currently written and review it
  • discuss any further additions to both goals and principles

Anybody who has read and understood the contents of the draft so far should be able to contribute. Experts in network system design particularly welcome.

As this was meant to be a side meeting in Vancouver, to make progress I would like to organise a 1 hour long virtual meeting on either June 2 or June 3. If you would like to contribute, please fill out your availability using the link below by Monday May 18. For those for whom the time chosen might not be convenient, we will make sure the session is recorded.

Once this section is complete, the draft will go through some editorial updates + an update on 3 repeater generations currently also in the works. If possible, this might make the draft ready for the next stage by IETF 108.

Qirg mailing list" rel="nofollow"> 

Qirg mailing list" rel="nofollow"> 

Qirg mailing list" rel="nofollow"> 

Qirg mailing list" rel="nofollow"> 

Qirg mailing list" rel="nofollow"> 

Qirg mailing list" rel="nofollow"> 

Qirg mailing list" rel="nofollow"> 

Qirg mailing list" rel="nofollow"> 


Qirg mailing list" rel="nofollow">