[Qirg] arch I-D: pull request & comments

[Rodney Van Meter <[e-mail]>]

<chair hat off>
<individual contributor hat on>

Wojtek et al.,

A pull request for the architecture I-D awaits you at
https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/7
(I didn't generate the .txt from it, I figure it's generally better
for such generated files that are stored in git to be managed at one
node.)

I went through the I-D and made a number of small changes; I doubt
anything will need discussion but please check.  Almost all edits are
for clarity, spelling or grammar.  I modified the Muralidharan
reference to the right "generations" paper, and I added Sutor as a
reference for beginners.  (I really do think that's an excellent
beginner's book on quantum computing, with the dead-minimum
assumptions of background in CS, math and physics, as opposed to Mike
& Ike, which can be a steep climb.)

A number of things occured to me while reading, some of which we've
probably covered before:

1. My memory fails me -- in the section on network boundaries, we
previously had a discussion of how much to cover the different types
of logical networks (1G, 2G, 3G), didn't we?  What did we decide?
Personally, I think it's _critical_ in a document like this, intended
to be long-lived and set the direction for the network architecture,
to acknowledge that not only are there physical differences and
administrative boundaries, but there are important distinctions in how
errors will be managed, which affects the content and semantics of
messages that must cross those boundaries, as well -- both for
connection setup and real-time operation.

2. Assessment of fidelity is a statistical thing, requiring constant
monitoring and the sacrifice of generated Bell pairs for tomography or
other methods.  Should we clarify this?  At the moment, fidelity is
mentioned but where it comes from is not.

3. Mentions QKD as depending on Bell pairs, which is not exactly true for
BB84.  Also, E91 and BBM92 are probably worth citing as better
instances of entanglement-based QKD.

4. This (and some of the surrounding paragraphs) needs work:

           It turns out that as long as the underlying implementation
           corresponds to (or sufficiently approximates) theoretical models of
           quantum cryptography, quantum cryptographic protocols do not need
           the network to provide any guarantees about the authenticity,
           confidentiality, or integrity of the transmitted qubits or the
           generated entanglement. Instead, applications, such as QKD,
           establish such guarantees using the classical network in conjunction
           with he quantum one. This is much easier than demanding that the
           network deliver secure entanglement in the first place.
           <vspace blankLines="1" />

This could cite Satoh on quantum network security; AFAIK, our work on
the security of repeater network operation remains the world's only
work on the topic.  One or both of
https://arxiv.org/abs/1701.04587
https://arxiv.org/abs/2005.04617

5. We have discussed Bell pairs as the primary service provided by the
network, but it may be worth mentioning that multi-party states are
useful, and may be generated either by applications operating
end-to-end or by the network itself as a service.  There are a number
of uses of multi-party states documented in the literature, but only
Clement, Damian and Frederic Grosshans on how to create them, I
think.
https://link.aps.org/doi/10.1103/PhysRevA.100.052333

6. "shortest path" is undefined here.  Again, work of ours is
relevant: https://arxiv.org/abs/1206.5655

7. In discussion of rule-based operation, again, work of ours is
relevant: https://arxiv.org/abs/1904.08605
(I _know_ it sounds like I'm citing "cite me" a lot, but this _is_ the
field we have been working for over a decade to establish, and we've
covered a lot of ground in that time, and my students and postdocs
deserve some recognition for the work they have done that is, or
should be, influencing these documents and designs.)

8. The use of "control plane" and "data plane" here might differ a bit
from standard networking use.  "Control plane" usual refers to routing
and management traffic, path setup for MPLS, etc. but here it refers
to soft real-time messages that are part of the entangled state
creation process, essentially the equivalent of packet headers and
SYNs and ACKs in TCP/IP.  I'd argue that's closer to data plane than
control plane.

I don't think the document is close to ready for last call yet, but it
has made a lot of progress.  I think we can put serious discussion of
the document onto the agenda for July, with the hopes of publishing
soon after.

—Rod

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[e-mail]