Subject: Re: [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks

From: Wojciech Kozlowski <[email-masked]>
Date: Thu, 10 Oct 2019 13:22:07 +0000

Some comments in-line.

On Thu, 2019-10-03 at 06:48 +0200, Patrick Gelard wrote:

Dear all,

I just read this article of synthesis "Towards Large-Scale Quantum Networks" ( https://arxiv.org/pdf/1909.08396.pdf )  and it seemto be a good complement to sections 1 - 4 to know about, in order to approach the discussions.

>>There is no quantum equivalent of a payload-carrying packet. The basic unit is entanglement in the form of entangled qubits.

What I understand :

I seem that distributed quantum application need to processing distributed of register of entangled qubits ( e.g https://arxiv.org/abs/quant-ph/0403146 ). Thus, one goal of the quantum network is to distributed entangled qubits to the application that requested  it. This is the network layer of the quantum network that is the counterpart of the network packet layer of classical network.

[WK] If what you mean is that the quantum network layer service equivalent is to provide entangled pairs between any two end-point in the (inter)network then yes, I agree. If you mean that an entangled pair is a direct equivalent of a network packet, I disagree. Qubits, and thus entangled pairs, do not directly carry their own headers like a network packet.

Distributed quantum network need a end to end transport network to build a graph of distributed of register of entangled qubits. it is the teleportation service that acts as the transport layer.

[WK] The transport layer (or the network layers in general) are not touched upon in the draft. Teleportation could be a transport layer that behaves similarly to the classical TCP service where the retransmission equivalent are the multiple attempts to generate end-to-end entanglement. However, applications may actually prefer direct access to the entangled pair, just like UDP provides direct access to the IP datagram service, because it want to perform other operations than teleportation.

This is a good discussion point. If people think it's a good point to include in the draft, please say so. I'd have a preference to not mention layers in the draft since that implies specific protocols whose discussion is not part of the draft.

Thus, it seems to me that it is important to know beforehand the quantum communication requirements of quantum applications in order to be able to decline "Architectural Principles for a Quantum Internet".

Yes, adding application requirements is a good point. It may be worth adding a rough idea of the axes along which applications may structure their requirements (e.g. latency, throughput, fidelity, teleportation/no-teleportation), but without going into detailed use cases since that would itself be a fairly large discussion.

/Patrick

Le 01/10/2019 à 14:59, Gelard Patrick a écrit :
Hi,

My comments in bleu [PG]

Thanks
/Patrick

De : Qirg <[email-masked]><mailto:[email-masked]> De la part de Wojciech Kozlowski
Envoyé : mardi 1 octobre 2019 13:35
À : [email-masked]<mailto:[email-masked]>
Objet : [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks

Dear QIRG,

For the first item of discussion for the "Architectural Principles for a Quantum Internet" draft we will start with the topic that generated the most discussion on the call namely:

The relation between classical and quantum networks.

Within this I also want to cover two related issues:

  *   the definition and relation of two coexisting data planes
  *   what do we have instead of a packet in a quantum network

Datatracker version: https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
GitHub version: https://github.com/Wojtek242/draft-irtf-qirg-principles

Here, I will propose a bullet point outline for the contents of a new section. This new section will replace/expand the existing section 5.1 "Model of a quantum network" (therefore, it assumes the reader has read sections 1-4). Please use this opportunity to make sure that everything is covered in these bullet points, because if it isn't, you can assume it won't make it into the final version. Feel free to add your own points below!

What feedback am I looking for:

  *   is the abstract model of the network clear from the description below?
  *   if something is not clear and you think it deserves more attention, please make a note of it by replying to the mailing list.
  *   there was mention of referring to the time and spatial relations between the data planes. I'm not sure that's covered below so I could use some help with this. Even phrasing the problem as a series of more specific questions would be useful.
  *   I vaguely mention mention naming below and this was a point raised below. One possibility is to reuse classical naming mechanisms since a quantum network will coexist with a classical network. This may be sufficient.
  *   there was also a question of drawing analogies to the physical layer in a classical network - is this covered sufficiently below or should more information be added or clarified?
  *   If you have something to add, please just add it to the list below.
  *   If you have questions that are not directly related to the content below, please start a new e-mail thread.

Important dates for this discussion:

  *   2019-10-01: discussion opened on QIRG mailing list.
  *   2019-10-08: please try to send any comments you have by this day to allow for some discussion and reactions before the next call.
  *   2019-10-14: the next call to discuss the draft - aim will be to consolidate discussions on the topic below. If there is rough consensus I will then work on writing up the discussion and adding it to the draft. Otherwise, we will proceed on the mailing list.

Proposed new content for section 5.1:

  1.  Challenges
     *   Goal of this section is to give the reader a good abstract model of what a quantum network looks like. Amongst other things it must answer the question "why can we not just build a quantum network in the same way we built classical networks".
[PG] Internet is not a network. It is a network of network.  So by similarity should not we talk about an interconnected network of quantum networks in which all parties can perform quantum information processing and quantum computing tasks ? The promise of this “quantum internet” is the ability to perform quantum information processing tasks, such as quantum teleportation , quantum key distribution, quantum clock synchronization , distributed quantum computation , and distributed quantum metrology and sensing , on a global scale !

     *   There is no quantum equivalent of a payload-carrying packet. The basic unit is entanglement in the form of entangled qubits. Entanglement is a generic resource distributed to end-nodes which is consumed by applications. Teleportation, the mechanism for transporting quantum data, is one such application.
[PG] Entanglement is a generic resource distributed to end-nodes which is request and consumed by applications.

     *   Entanglement is a phenomenon in which two or more qubits exist in a physically distributed state. This property exists at the physical level and requires that the location and state of its constituent qubits be known. This is in contrast to classical signals at the physical layer which proceed statelessly from sender to receiver.
     *   Entangled qubits do not carry control information. Therefore, a quantum router must manage two data planes in parallel, a classical one, which carries the control information, and a quantum one, which carries entangled qubits. It must also be able to correlate the classical control information with the appropriate entangled pairs.
[PG] Is it really up to the quantum router to manage the control plan of the classic network used ? This is very well managed by the classical network. I would tend to say the opposite. Update  exiting classical control plane  (MPLS-TE, SDN/Openflow, Netconf, MP-BGP, …) to manage quantum  network.

     *   Setting up end-to-end entanglement necessarily requires temporary state in the intermediate nodes beyond forwarding tables. At the very least all qubits will need some local metadata associated with them to allow routers to correlate them with the relevant control information.
     *   Creating a longer end-to-end pair is a spatially parallelisable operation unlike packet forwarding. The generation of entangled pairs on each individual link can happen in parallel (perhaps even as a background process) and the entanglement swaps can also be done independently of each other. What is important is that at the end of the day, the control plane can unambiguously identify which qubits in the network are paired up in an entangled pair state. This implies that the forwarding mechanisms may be very different.
  1.  Abstract model of the network
     *   In a quantum network will consist of quantum channels which serve to generate entanglement on individual links and classical channels which are used to transmit control information (in the conventional way - as packets).
[PG] The quantum channel can be integrated/hybrid with optical classical.

     *   Not all routers will have both - some devices may only have a classical data plane. Some devices may only have a quantum data plane (in this case the entanglement generation and swapping will be fully automated).
     *   Decision making nodes necessarily have both data planes.
     *   It is beyond the scope of this draft to propose concrete mechanisms for correlating control information with qubits. However, it is worth outlining some possibilities. For example, an entangled pair can have metadata associated with it, such as the time it was generated at. If time is discretised into time bins and only one such pair at most is generated in each time bin this can be used to uniquely identify a particular entangled qubit. This is the mechanism used in the recently proposed link layer protocol.
     *   Because a classical network is part of a quantum network, we can use several basic mechanisms from classical networks, such as: routing protocols (for distributing topology information - actual routing decisions will be more involved), IP addresses and ports for naming, GMPLS was also mentioned which may be relevant in some situations. I think Rodney did some work in this area in the past - perhaps something could be added here.
[PG] There are different kind of networks LAN, MAN or WAN.

Thanks,
Wojtek

_______________________________________________

Qirg mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/qirg

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>      Garanti sans virus. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

---

From: Marcello Caleffi <[email-masked]>
Date: Thu, 10 Oct 2019 15:40:33 +0200

> Il giorno 10 ott 2019, alle ore 15:22, Wojciech Kozlowski <[email-masked]> ha scritto:
> 
> Some comments in-line.
> 

Indeed, some of this axes (and the difficulty to combine them in a quantum routing metric) are explored within a draft for a RFC we’re working on here in Naples.

We would be happy to share the draft to have a feedback from all of you, if you think it can help the discussion.

Marcello

>>> De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
>>> À : [email-masked]
>>> 	• the definition and relation of two coexisting data planes
>>> 	• what do we have instead of a packet in a quantum network
>>>  
>>> 	• is the abstract model of the network clear from the description below?
>>> 	• if something is not clear and you think it deserves more attention, please make a note of it by replying to the mailing list.
>>> 	• there was mention of referring to the time and spatial relations between the data planes. I'm not sure that's covered below so I could use some help with this. Even phrasing the problem as a series of more specific questions would be useful.
>>> 	• I vaguely mention mention naming below and this was a point raised below. One possibility is to reuse classical naming mechanisms since a quantum network will coexist with a classical network. This may be sufficient.
>>> 	• there was also a question of drawing analogies to the physical layer in a classical network - is this covered sufficiently below or should more information be added or clarified?
>>> 	• If you have something to add, please just add it to the list below.
>>> 	• If you have questions that are not directly related to the content below, please start a new e-mail thread.
>>>  
>>> 	• 2019-10-01: discussion opened on QIRG mailing list.
>>> 	• 2019-10-08: please try to send any comments you have by this day to allow for some discussion and reactions before the next call.
>>> 	• 2019-10-14: the next call to discuss the draft - aim will be to consolidate discussions on the topic below. If there is rough consensus I will then work on writing up the discussion and adding it to the draft. Otherwise, we will proceed on the mailing list.
>>>  
>>> 	• Challenges 
>>> 		• Goal of this section is to give the reader a good abstract model of what a quantum network looks like. Amongst other things it must answer the question "why can we not just build a quantum network in the same way we built classical networks".
>>> 		• There is no quantum equivalent of a payload-carrying packet. The basic unit is entanglement in the form of entangled qubits. Entanglement is a generic resource distributed to end-nodes which is consumed by applications. Teleportation, the mechanism for transporting quantum data, is one such application.
>>> 		• Entanglement is a phenomenon in which two or more qubits exist in a physically distributed state. This property exists at the physical level and requires that the location and state of its constituent qubits be known. This is in contrast to classical signals at the physical layer which proceed statelessly from sender to receiver.
>>> 		• Entangled qubits do not carry control information. Therefore, a quantum router must manage two data planes in parallel, a classical one, which carries the control information, and a quantum one, which carries entangled qubits. It must also be able to correlate the classical control information with the appropriate entangled pairs.
>>> 		• Setting up end-to-end entanglement necessarily requires temporary state in the intermediate nodes beyond forwarding tables. At the very least all qubits will need some local metadata associated with them to allow routers to correlate them with the relevant control information.
>>> 		• Creating a longer end-to-end pair is a spatially parallelisable operation unlike packet forwarding. The generation of entangled pairs on each individual link can happen in parallel (perhaps even as a background process) and the entanglement swaps can also be done independently of each other. What is important is that at the end of the day, the control plane can unambiguously identify which qubits in the network are paired up in an entangled pair state. This implies that the forwarding mechanisms may be very different.
>>> 	• Abstract model of the network 
>>> 		• In a quantum network will consist of quantum channels which serve to generate entanglement on individual links and classical channels which are used to transmit control information (in the conventional way - as packets).
>>> 		• Not all routers will have both - some devices may only have a classical data plane. Some devices may only have a quantum data plane (in this case the entanglement generation and swapping will be fully automated).
>>> 		• Decision making nodes necessarily have both data planes.
>>> 		• It is beyond the scope of this draft to propose concrete mechanisms for correlating control information with qubits. However, it is worth outlining some possibilities. For example, an entangled pair can have metadata associated with it, such as the time it was generated at. If time is discretised into time bins and only one such pair at most is generated in each time bin this can be used to uniquely identify a particular entangled qubit. This is the mechanism used in the recently proposed link layer protocol.
>>> 		• Because a classical network is part of a quantum network, we can use several basic mechanisms from classical networks, such as: routing protocols (for distributing topology information - actual routing decisions will be more involved), IP addresses and ports for naming, GMPLS was also mentioned which may be relevant in some situations. I think Rodney did some work in this area in the past - perhaps something could be added here.
>>> [email-masked]
>> 	Garanti sans virus. www.avast.com
> [email-masked]

---

From: Gelard Patrick <[email-masked]>
Date: Thu, 10 Oct 2019 16:02:32 +0000

Hi,

Idem for the debate

Thanks
/Patrick

De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
Envoyé : jeudi 10 octobre 2019 15:22
À : [email-masked]
Objet : Re: [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks

Some comments in-line.

Dear all,

What I understand :

[WK] If what you mean is that the quantum network layer service equivalent is to provide entangled pairs between any two end-point in the (inter)network then yes, I agree. If you mean that an entangled pair is a direct equivalent of a network packet, I disagree. Qubits, and thus entangled pairs, do not directly carry their own headers like a network packet.
[PG] “If what you mean is that the quantum network layer service equivalent is to provide entangled pairs between any two end-point in the (inter)network” yes.

[PG] The transport layer is part of the end-to-end communication principles of the traditional Internet.
About teleportation. If the need of the application is to exchange qubits, the other possibility is only to transfer the qubit directly (prepare and measure), isn’t it ?
The quantum application could also need to do a measurement on the entangled pair (direct access), but it is not the same requirement as qubit transfer, isn’t it ?

/Patrick

My comments in bleu [PG]

Thanks
/Patrick

Dear QIRG,

  1.  Challenges

Thanks,
Wojtek

Qirg mailing list

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Garanti sans virus. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 10 Oct 2019 17:03:09 +0000

In my opinion, from a control standpoint, a Quantum Network looks fairly similar to an MPLS (or other circuit switched) network.

In both cases, when you "establish" a connection, someone selects a path through the network between the two endpoints, and informs each node on the path about which neighbors are involved with this path.

Now, obviously the details about what the nodes do with this information are different; however the action of setting up the path (at least at this high level) looks similar.  Lower level subproblems that also look similar:
	- Bandwidth management; how do we make sure that a particular link is not oversubscribed?
	- Fault recovery; how do we reestablish the path on a link or node failure?

My suggestion would be to talk to some MPLS experts (which I am not), and find out a) what solutions do MPLS networks implement on the control plane, and b) what assumptions do those protocols make (with an eye to discovering how the requirements on an MPLS network differ from a Quantum Network...

> -----Original Message-----
> From: Qirg <[email-masked]> On Behalf Of Marcello Caleffi
> Sent: Thursday, October 10, 2019 9:41 AM
> To: Wojciech Kozlowski <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks
> 
> 
> 
> >> I just read this article of synthesis "Towards Large-Scale Quantum
> Networks" ( https://arxiv.org/pdf/1909.08396.pdf )  and it seemto be a good
> complement to sections 1 - 4 to know about, in order to approach the
> discussions.
> >>
> >> >>There is no quantum equivalent of a payload-carrying packet. The basic
> unit is entanglement in the form of entangled qubits.
> >>
> >> What I understand :
> >>
> >> I seem that distributed quantum application need to processing
> distributed of register of entangled qubits ( e.g https://arxiv.org/abs/quant-
> ph/0403146 ). Thus, one goal of the quantum network is to distributed
> entangled qubits to the application that requested  it. This is the network
> layer of the quantum network that is the counterpart of the network packet
> layer of classical network.
> >>
> >
> > [WK] If what you mean is that the quantum network layer service
> equivalent is to provide entangled pairs between any two end-point in the
> (inter)network then yes, I agree. If you mean that an entangled pair is a
> direct equivalent of a network packet, I disagree. Qubits, and thus entangled
> pairs, do not directly carry their own headers like a network packet.
> >
> >>
> >>
> >> Distributed quantum network need a end to end transport network to
> build a graph of distributed of register of entangled qubits. it is the
> teleportation service that acts as the transport layer.
> >>
> >
> > [WK] The transport layer (or the network layers in general) are not touched
> upon in the draft. Teleportation could be a transport layer that behaves
> similarly to the classical TCP service where the retransmission equivalent are
> the multiple attempts to generate end-to-end entanglement. However,
> applications may actually prefer direct access to the entangled pair, just like
> UDP provides direct access to the IP datagram service, because it want to
> perform other operations than teleportation.
> >
> > This is a good discussion point. If people think it's a good point to include in
> the draft, please say so. I'd have a preference to not mention layers in the
> draft since that implies specific protocols whose discussion is not part of the
> draft.
> >
> >> Thus, it seems to me that it is important to know beforehand the
> quantum communication requirements of quantum applications in order to
> be able to decline "Architectural Principles for a Quantum Internet".
> >>
> >
> > Yes, adding application requirements is a good point. It may be worth
> adding a rough idea of the axes along which applications may structure their
> requirements (e.g. latency, throughput, fidelity, teleportation/no-
> teleportation), but without going into detailed use cases since that would
> itself be a fairly large discussion.
> >
> 
> Indeed, some of this axes (and the difficulty to combine them in a quantum
> routing metric) are explored within a draft for a RFC we’re working on here in
> Naples.
> 
> >>> Envoyé : mardi 1 octobre 2019 13:35 À : [email-masked] Objet : [Qirg]
> >>> draft-irtf-qirg-principles: Relation to Classical Networks
> >>>
> >>> Dear QIRG,
> >>>
> >>> For the first item of discussion for the "Architectural Principles for a
> Quantum Internet" draft we will start with the topic that generated the most
> discussion on the call namely:
> >>>
> >>> Datatracker version:
> >>> https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
> >>> GitHub version:
> >>> https://github.com/Wojtek242/draft-irtf-qirg-principles
> >>>
> >>> Here, I will propose a bullet point outline for the contents of a new
> section. This new section will replace/expand the existing section 5.1 "Model
> of a quantum network" (therefore, it assumes the reader has read sections
> 1-4). Please use this opportunity to make sure that everything is covered in
> these bullet points, because if it isn't, you can assume it won't make it into
> the final version. Feel free to add your own points below!
> >>>
> >>> 	• if something is not clear and you think it deserves more attention,
> please make a note of it by replying to the mailing list.
> >>> 	• there was mention of referring to the time and spatial relations
> between the data planes. I'm not sure that's covered below so I could use
> some help with this. Even phrasing the problem as a series of more specific
> questions would be useful.
> >>> 	• I vaguely mention mention naming below and this was a point
> raised below. One possibility is to reuse classical naming mechanisms since a
> quantum network will coexist with a classical network. This may be sufficient.
> >>> 	• there was also a question of drawing analogies to the physical layer
> in a classical network - is this covered sufficiently below or should more
> information be added or clarified?
> >>> 	• 2019-10-08: please try to send any comments you have by this day
> to allow for some discussion and reactions before the next call.
> >>> 	• 2019-10-14: the next call to discuss the draft - aim will be to
> consolidate discussions on the topic below. If there is rough consensus I will
> then work on writing up the discussion and adding it to the draft. Otherwise,
> we will proceed on the mailing list.
> >>>
> >>> 		• Goal of this section is to give the reader a good abstract
> model of what a quantum network looks like. Amongst other things it must
> answer the question "why can we not just build a quantum network in the
> same way we built classical networks".
> >>> [PG] Internet is not a network. It is a network of network.  So by
> similarity should not we talk about an interconnected network of quantum
> networks in which all parties can perform quantum information processing
> and quantum computing tasks ? The promise of this “quantum internet” is
> the ability to perform quantum information processing tasks, such as
> quantum teleportation , quantum key distribution, quantum clock
> synchronization , distributed quantum computation , and distributed
> quantum metrology and sensing , on a global scale !
> >>> 		• There is no quantum equivalent of a payload-carrying
> packet. The basic unit is entanglement in the form of entangled qubits.
> Entanglement is a generic resource distributed to end-nodes which is
> consumed by applications. Teleportation, the mechanism for transporting
> quantum data, is one such application.
> >>> 		• Entanglement is a phenomenon in which two or more
> qubits exist in a physically distributed state. This property exists at the
> physical level and requires that the location and state of its constituent qubits
> be known. This is in contrast to classical signals at the physical layer which
> proceed statelessly from sender to receiver.
> >>> 		• Entangled qubits do not carry control information.
> Therefore, a quantum router must manage two data planes in parallel, a
> classical one, which carries the control information, and a quantum one,
> which carries entangled qubits. It must also be able to correlate the classical
> control information with the appropriate entangled pairs.
> >>> [PG] Is it really up to the quantum router to manage the control plan of
> the classic network used ? This is very well managed by the classical network.
> I would tend to say the opposite. Update  exiting classical control plane
> (MPLS-TE, SDN/Openflow, Netconf, MP-BGP, …) to manage quantum
> network.
> >>> 		• Setting up end-to-end entanglement necessarily requires
> temporary state in the intermediate nodes beyond forwarding tables. At the
> very least all qubits will need some local metadata associated with them to
> allow routers to correlate them with the relevant control information.
> >>> 		• Creating a longer end-to-end pair is a spatially parallelisable
> operation unlike packet forwarding. The generation of entangled pairs on
> each individual link can happen in parallel (perhaps even as a background
> process) and the entanglement swaps can also be done independently of
> each other. What is important is that at the end of the day, the control plane
> can unambiguously identify which qubits in the network are paired up in an
> entangled pair state. This implies that the forwarding mechanisms may be
> very different.
> >>> 		• In a quantum network will consist of quantum channels
> which serve to generate entanglement on individual links and classical
> channels which are used to transmit control information (in the conventional
> way - as packets).
> >>> 		• Not all routers will have both - some devices may only have
> a classical data plane. Some devices may only have a quantum data plane (in
> this case the entanglement generation and swapping will be fully
> automated).
> >>> 		• It is beyond the scope of this draft to propose concrete
> mechanisms for correlating control information with qubits. However, it is
> worth outlining some possibilities. For example, an entangled pair can have
> metadata associated with it, such as the time it was generated at. If time is
> discretised into time bins and only one such pair at most is generated in each
> time bin this can be used to uniquely identify a particular entangled qubit.
> This is the mechanism used in the recently proposed link layer protocol.
> >>> 		• Because a classical network is part of a quantum network,
> we can use several basic mechanisms from classical networks, such as:
> routing protocols (for distributing topology information - actual routing
> decisions will be more involved), IP addresses and ports for naming, GMPLS
> was also mentioned which may be relevant in some situations. I think
> Rodney did some work in this area in the past - perhaps something could be
> added here.

---

From: Wojciech Kozlowski <[email-masked]>
Date: Fri, 11 Oct 2019 14:35:45 +0000

> > > quantum communication requirements of quantum applications in
> > > order to be able to decline "Architectural Principles for a
> > > Quantum Internet".
> > > 
> > 
> > Yes, adding application requirements is a good point. It may be
> > worth adding a rough idea of the axes along which applications may
> > structure their requirements (e.g. latency, throughput, fidelity,
> > teleportation/no-teleportation), but without going into detailed
> > use cases since that would itself be a fairly large discussion.
> > 
> 
> Indeed, some of this axes (and the difficulty to combine them in a
> quantum routing metric) are explored within a draft for a RFC we’re
> working on here in Naples.
> 
> We would be happy to share the draft to have a feedback from all of
> you, if you think it can help the discussion.
> 
> Marcello

If you'd like you could also provide a brief high-level summary about
these "axes" that could be discussed for inclusion in this draft. Brief
enough that it could give the reader an idea of the challenges involved
and nature of requirements, but wouldn't have to cover as much ground
as what you're working on right now.

If the consensus would be that it'd be good to include in this draft, I
(or you via GitHub) would edit it in and add you (and any other
contributors) as authors. Since there is already mention of fidelity as
part of the service in the draft I think this could complement/replace
that part of the discussion.