►
From YouTube: QIRG Interim Meeting, 2020-06-09
Description
QIRG Interim Meeting, 2020-06-09
A
A
B
A
A
D
A
C
A
A
A
A
Hey
okay,
so
let
me
start
by
a
recap
of
what
the
goals
of
this
between
R
and
so
is
getting
towards
the
end
of
work
on
the
architectural
principles
draft,
and
it's
been
going
on
for
some
time
and
the
last
section
that
he's
working
is
kind
of
what
not
that
all
the
introductory
material
has
wrapped
up,
and
there
is
kind
of
effectively
kind
of
that.
What
what
this
whole
draft
was
kind
of
going
towards
was
a
look
looking
forward,
a
section
which
is
more
about
what
based
on
what
kind
of
principles.
A
What
kind
of
goals
do
we
have
for
our
for
a
quantum
Internet?
And
so
and
that's
the
kind
of
goal
of
this
section.
It's
not
meant
to
be
particularly
long
or
it's
not
meant
to
be
particularly
opinionated,
not
meant
to
be,
particularly
as
a
kind
of
you
have
to
do.
You
must
do
things
this
way,
because
obviously,
practical
developments
will
generally
overrule
any
sort
of
idealistic
principle,
but
it's
kind
of
I
felt
it
was
kind
of
good
to
at
least
outline
kind
of
goals
and
principles,
because
these
things
will
kind
of
first
of
all
help.
A
People
also
understand
what
is
it
that
we're
building
and
also
because
this
is
particularly
an
area
which
will
benefit
heavily
from
insight
from
people
from
outside
of
the
quantum
current
quantum
Internet
community,
which
is
has
a
lot
of
physicists,
so
I
kind
of
pointed
out
in
the
email
that
I
sent
out.
That
I
particularly
would
like
contributions
I'd.
Why?
A
But,
if
you
think,
contributions,
people
who
have
seen
how
the
Internet
has
developed
and
the
history,
the
mistakes
that
have
been
made,
etc,
how
that
could
apply
to
the
quantum
Internet
so
having
assuming
the
knowledge
of
the
content
of
the
previous
parts
of
the
documents
to
how
that
confirmation
would
be,
it's
roughly
going
to
be
built
and
let's
go
over
the
section.
Six
of
architecture,
principles
which
is
split
into
two
sections.
A
Well,
I
stood
into
two
sections
that
may
be
up
for
debate,
one
which
is
goals
and
one
which
is
principles
which
comes
later,
the
idea
of
goals
being
not
so
much
rules
but
roughly
like
what
should
we
be
on
the
lookout
for
as
we
proceed
with
the
canto
Internet
I?
What
do
what
are
we
building
this
continent
towards?
A
And
the
principle
is
being
more
like
well
now
that
it's
just
right
over
than
the
continent
or
towards
what's
the
rough
set
of
good
kind
of
rules
of
thumb,
good
principles
we
should
stick
to
I've
linked
in
previous
emails
and
I
will
link,
maybe
in
a
follow-up
what
document.
So
that
kind
of
inspired
me
to
start
this
section.
A
But
let's
now
just
kind
of
go
through
this,
and
the
idea
of
Gaia
of
this
meeting
is
we'll
go
through
what's
currently
there
and
then
I
want
to
also
open
up
the
floor
to
others
to
kind
of
add
in
their
contributions.
And
we
say
what
do
they
would
like
to
see
in
the
goals?
What
would
they
like
to
see
in
principles
and
I'm,
not
practically
confining
that
I
don't
want
to
confine
the
debate
to
anything,
that's
already
there
and
very
open
to
additional
ideas.
So,
having
said
that,.
A
Let's
go
over
the
goals,
and
so
the
first
goal
that
I've
listed
is
and
the
way
I
want
to
discuss.
These
goals
is
I'm,
gonna
briefly
describe
them,
and
if
anybody
has
anything
to
say
stirs
I
know
to
add
something
to
remove
something
or
if
they
don't
think
it
should
be
a
goal.
Please,
let
me
know:
hey
I'm,
also
up
for
removing
things.
That's
also
up
for
discussion,
so
the
first
one
I
listed
is
to
support,
distributed
contem
applications
and
the
point.
A
Fundamentally,
a
lot
of
applications
do
not
necessarily
need
the
data
transmission
part
of
quantum,
for
example.
Quantum
key
distribution
does
not
need
to
actually
transmit
quantum
data,
but
merely
needs
that
stronger
than
classical
correlations
provided
by
an
entangled
pair
of
particles
and
that's
effectively.
What
this
part
is
saying
is
that,
because
of
this
difference,
we
need
to
develop
metrics
that
are
meaningful
to
these
kind
of
applications.
So,
for
example,
a
throughput
is
not
particularly
meaningful
alone.
A
How
many
entangled
pairs
per
seconds
do
we
achieve
if
we're
also
not
talking
about
the
fidelity
of
these
entangled
pairs,
because
the
fidelity
of
these
entangled
pairs
plus
throughput,
if
they're
not
open?
Even
if
you
have
a
large
throughput
but
low
fidelity
that
might
not,
let
may
actually
require
many
reattempt
s--
at
the
application
level,
which
is
undesirable
all
right,
so
that,
basically,
is
all
about
basically
saying
the
goal
of
a
quantum
number
is
slightly.
A
B
C
A
Okay,
hey
well,
that
was
a
pretty
sure
forward
and
the
next
one
is
basically
saying
the
same
thing,
but
also
saying
that,
currently
we
can't
really
do
much
with
our
early
stage.
Hardware
qkd
is
possible
with
non
quantum
repeater
based
technology
and
the
whole
point
is
kind
of
to
emphasize
that
we
want
an
architecture
that
can
support
applications
that
have
that
may
have
quite
heavy
hardware
than
research
requirements
and
we're
not
building
an
architecture
to
support
just
qkd
for
the
new
years
future.
A
Don't
just
think
about
what's
possible
today
and
was
the
current.
If
for
people
who
actually
look
at
current
hardware,
it
may
may
very
quickly
conclude
that
many
applications
are
simply
just
not
really
possible,
or
they
are
not
possible
over
very
long
distances.
We
should
not
confine
their
architecture
based
on
those
limitations,
and
this
is
a
kind
of
point
I'm,
not
sure
if
it's
worth
stating
or
if
it's
worth
adding
anything
to
this
is
the
kind
of
question
I
have
about
this
point.
Does
anybody
want
to
say
anything
about
it?
I.
C
A
Okay,
moving
on
supporting
harder
heterogeneity,
the
key
point
is
it's
kind
of
like
I
mean
in
classical
numbers,
there's
also
harder,
heterogeneity
I'm,
not
particularly
with
the
harder
that
really
goes
into
that
currently
Carter
heterogeneity,
ideally
I'm,
not
sure
how
much
you
should
actually
account
in
protocol
level.
I've
personally
found
that
you
do
actually
have
to
think
about
this
quite
a
bit
actually
at
the
protocol
level,
because,
for
example,
some
quantum
repeater
architectures,
for
example,
do
not
support
a
deterministic,
entanglement
swaps
and
then
tagamet
swaps,
with
only
a
certain
probability
and
that's
something.
A
For
example,
a
protocol
would
have
to
take
into
account-
and
it's
kind
of
hard
to
hide
in
the
hardware
and
then
there's
also.
The
idea
that
some
links
can
produce
entangled
pair
is
almost
deterministically
with
very
high
fidelity,
but
some
links
require
multiple
attempts
and
that
also
is
kind
of
a
bit
hard
to
sweep
under,
like
the
hardware
rug
and
that's
kind
of
what
I'm
saying
in
these
goals.
I
have
an
extra
tune.
Much
of
this
bunch,
so
I
don't
know
if
anybody
feels
like
there's
something
to
add
to
this
support
harder,
heterogeneity
point.
C
C
So
this
sentence
that
you
have
where
all
the,
where
all
the
nodes
have
essentially
the
same,
are
capable
of
executing
the
same
set
of
tasks
is
too
strong
and
you
might
have
different.
You
might
run
into
a
into
a
situation
where
different
nodes
are
fundamentally
capable
of
doing
different
things,
and
so
in
a
classical
word.
For
example,
some
nodes
can
do
v6
forwarding
and
some
cannot,
and
so
it's
essential
that
the
architecture
has
this
concepts
of
capability
discovery
or
capability
negotiation,
so
that
you
can
introduce
new
technologies
gradually
without
requiring
flag
day
upgrades.
A
Yeah
I
agree:
that's
that's
very
useful.
I'll
weaken
the
point
about
same
roughly
the
same
capabilities
and
I'll
basically
add.
The
point
would
be
to
avoid
things
like
flag
days
and
through
effectively
some
capability
discovery,
negotiation
mechanism
and
to
kind
of
support
and
to
achieve
the
boulevard
return.
Eighty,
so
the
goal
could
be
support,
harder-edged,
identity
and
I.
Guess
they'll
tie
in
with
a
principle
which
would
basically
say
way
to
support
some
kind
of
capability
discovery.
Negotiation
goal
would
be
effectively
to
avoid
lag
days.
F
F
Heterogeneity,
but
it's
also
heterogeneity
at
the
at
the
protocol
level,
in
particular
at
the
error
management
level,
as
we
potentially
progress
from
one
g2
to
G
to
3G
networks,
I
think
I
think
why
tech
and
I've
been
talking
about
that
one
since
last
fall
and
have
had
something
of
a
difference
of
opinion
on
that
one.
But
yes,
yes,
that.
A
F
H
Go
ahead.
Sorry,
this
is
steve
willis,
I'm
more
classical
internet
person
support
harder
heterogeneity.
Don't
we
also
have
qubit
heterogeneity?
Don't
we
have
CB
+
DV
technology
in
here
and
should
that
be
I
tried
to
figure
out
quickly
scanning
this,
whether
that
was
encompassed
in
this?
And
so,
though,
is
that
also
part
of
heterogeneity
experts?
H
A
A
F
Oh,
that's
a
yes!
That's!
That's
that's
a
legitimate
question
and
that's
again,
that's
a
that's.
A
big
ball
of
worms
on
the
CV
people.
Do
things
very
differently
at
both
the
physical
and
logical
levels.
It's
not
clear.
They
have
anything
that
corresponds
to
a
qubit,
and
so
it's
not
clear
that
it's
that
it's
actually
interoperable
with
repeaters.
Although
you
do
actually
see
you
see
references
to
systems
that
are
continuous
variable,
qkd
systems,
and
so
they
are
imposing
something
of
a
bit
like
regime
on
top
of
the
CB
I'm.
A
F
A
B
F
A
A
Guess
in
where
the
first
one
I
said
that
there
may
be
multiple
types
of
hardware
and
the
second
one
I
said,
I
guess:
I
also
included
a
concept
that
different
type
of
hardware
may
come
in
the
future,
with
better
capabilities.
I
think
number
four
encompasses.
Actually
there
is
some
interest
in
keeping
you
a
number
four
separate,
but
I'm,
not
sure
if
it's
strong
enough,
so
one
of
the
things
that's
important
about
protocols
is
that
they
operate
across
or
at
least
then
I
feel
as
important
about
the
protocols
we
took
incorrect
me.
A
It
actually
isn't
is
that
protocols
work
across
at
least
the
fundamental
protocols
work
across
a
range
of
orders
of
magnitudes,
so
they
were
so
that
they
operate
at
low
rates
just
as
well
as
they
are
these.
They
operate
at
low
rate,
but
they
can
also
operate
at
high
rates,
and
so
you
know
just
say,
take
IP
IP
can
run
your
network
at
home,
and
IP
can
also
run
on
the
networks
in
the
backbone
of
the
in
turn
and
I.
F
A
G
F
A
A
G
Lady
sure
I
was
thinking
about
is
early,
we
will
mention
in
the
quantum
internet
will
be
involved
in
different
stages.
So,
given
that
in
some
stage
there
could
be
quantum
network
number
one
which
only
supports
the
stage
number
one
capabilities,
another
quantum
network
number
two
supports
both
balanced
stage.
So,
if
it
could
happen,
say
there
are
different
quantum
networks
supporting
different
stages
or
two.
A
That's
a
good
point,
and
that's
probably
I
think
that's
something
that
rod
alluded
to
just
a
moment
ago
that
that
shouldn't
be
mentioned
in
the
protocol.
That
was
because
that,
as
we
evolved
networks
from
Frigidaire
second
generation
or
these,
if
they
coexist
that
they
have
slightly
different
error
management,
I
think
yes,
so
basically
what
you're
saying
is
I'm
gonna
go
back
to
wrought
upon
an
event
that
should
be
included,
probably
harder,
cutter,
Jannetty,
large
harbors
life
protocol
Jam
should
be
a
slightly
rephrase,
but
the
heterogeneity
in
some.
A
A
A
But
that
mention
anything
in
the
network.
All
that
it
says
is
that
the
network
doesn't
actually
have
to
provide
a
security
and
that
kind
of
security
guarantee
to
the
application.
Well,
the
same
time,
there
are
other
threats
to
the
network,
which
may
be
simply
that
well
that
the
two
end
nodes
just
never
received
their
entangled
pair
I'm,
not
actually
an
expert
at
all
on
this
section.
So
I
definitely
would
like
somebody
else
to
come
in.
A
For
knows
more,
especially,
you
know
that
Rodney's
here
and
they
just
released
a
paper
on
this
or
if
some
of
the
other
authors
of
that
paper
are
here,
could
actually
come
in
on
the
section
but
mister.
What
I'm
saying
is
patients
have
their
own
way
of
verifying
end-to-end
security,
but
the
network
should
also
take
care
of
ensuring
the
network
protocols
that
we
also
limit
a
disruption
at
the
protocol
level
and
I.
H
So
I
have
a
question
about
the
Steve
Willis
I
have
a
question
about
the
mid
paragraph
here,
which
is
is
difficult
at
the
network
level
in
a
way,
there's
there's
two
network
levels,
certainly
there's
the
clock,
there's
a
class
of
control
network
here,
which
has
it's
a
security
set
of
issues
and
then
there's
sort
of
the
quantum,
whatever
we're
calling
it
transport
or
whatever
level.
What
do
you
mean
by
network
level
here
in
this
paragraph
that.
A
And
so
what
I
meant
about
I
was
mostly
just
that
the
network
itself.
So
if
you
consider
yourself
just
a
user
that
that's
attached
to
the
network
and
what
I
meant
by
the
network
level,
I
effected
meant
that
that
network,
to
which
he
attached
he
it's
kind
of
just
he's.
Just
a
difficult
problem
and
I,
don't
think
it
should
be
guaranteed
by
the
network
themselves,
whose
application
themselves
have
protocols
and
capabilities
to
capturing
the
idea
that
perhaps
the
source
of
entangled
pairs
is
malicious.
B
It's
not
it's
not
really
in
deep
in
the
in
the
quantum
part
of
the
network,
it's
the
authentication
of
the
users
you
need
at
some
point.
You
will
need
to
make
sure
that
you
are
talking
with
the
right
person.
The
person
you
think
you
are
talking
with
the
network.
Probably
I
mean
the
infrastructure
that
that
provides
this.
The
quantum
network
capability
should
be
able
to
authenticate.
F
Well
part
of
what
a
big
chunk
of
what
we
addressed
in
that
paper
draft
is
operational
issues
around
routing
and
connection
setup
and
resource
management,
multiplexing
and
whatnot,
and
how
that
actor
on
the
network
could
potentially
significantly
describe
the
operation
of
the
network
itself.
But
this
is
a
this
is
a
relatively.
This
could
be
a
pretty
long
discussion,
so
so
my
suggestion
Wojtek,
is
that
we
put
this
on
the
agenda
for
for
July
and
get
either
Sato
or
show
good
app
to
talk
about.
It
shows
actually
been
pounding
pretty
heavily
on.
A
That's
a
very
good
point:
I'd
rather
not
Security's,
an
enormous
topic,
I
think
and
I'm.
Really
not
an
extra
side.
I
already
feel
super
comfortable
writing
about
security
in
this
jeff's
I
am
I'm
inclined
to
actually
just
agree
with
you
to
put
it
on
the
agenda
for
the
meeting
and
perhaps
even
have
a
set
of
separate
documents
for
security
and
over
here
just
in
the
basics.
So.
H
That's
what
I
was
sorry,
that's
what
I
was
gonna
suggest
in
the
in
the
way
the
existing
store
body
of
security
work
in
the
internet
in
the
IETF
RFC
is
a
separate
set
of
documents
and
in
it
because
it
is
a
complicated
set
of
document
the
complicated
set
concern.
There
are
multiple
control
paths,
you
know
paths
and
quantum
paths
and
entangling
paths,
I
think
it's
will
never
cover
it
in
a
paragraph
and
so
put
it
off
to
something
else.
It's
the
right
thing
and
having
it's
an
agenda
item,
my.
F
Suggestions
of
the
balance
of
the
document,
I
would
say
what
you
have.
There
is
long
relative
to
the
other
thing
since
then
get
back
notice,
employment
form.
Ok,
can
you
repeat:
yeah
Steve
or
anyone
else
hear
that
yeah
the
paper
that
I
just
posted
a
link
to
the
draft
on
we're
still
actually
revising
it.
We
actually
haven't
sent
it
off
to
the
a
journal
yet
so
if
anybody
wants
to
look
at
it
in
the
next
few
days
and
offer
comments,
we'd
love
to
have
them
we're
planning
to
get
it
off
to
the
journal.
H
A
F
A
F
Well,
wait
until
we
got
to
the
end
of
list,
but
I
suppose
I
could
go
ahead
and
bring
it
up
actually
playing
devil's
advocate
here
for
a
moment.
The
seven
points
that
you
have
listed
here
in
the
section
if
you
took
out
the
word
quantum
wood
to
describe
network
built
since
the
internet,
all
right
so
does.
F
How
much
does
this
set
of
points
actually
overall
and
it
bit
to
the
edge
of
the
graph
as
a
whole
by
the
way
we've
gotten
there
yet,
but
the
next
set
of
stuff
on
the
on
the
the
principles
of
the
internet,
I,
love,
I,
think
that's
great,
and
there
are
things
in
there
that
Lear
that
your,
even
though
I've
been
working
on
this
for
fifteen
years,
I
went
that's
really
nice
and
you're
nice
inside,
but
this
part
I'm
not
so
sure
if
it
offers.
If
dolphins
much
okay.
A
That's
a
very
good
point.
So,
let's
get
to
the
end
and
actually
try
and
answer
that
question
or
because
we
still
have
25
minutes
I'm,
let's
go
through
their
remaining
points,
let's
go
through
the
principles
and
if
we
have
time
we'll
return
to
this
question
as
first
thing
or
go
offline.
Well,
that's
a
good
question.
F
A
Fine
with
me,
and
that's
a
very
good
point:
I'm
just
wanna
go
through
the
remaining
points
that
many
two
goals
are
going
to
be
very
quick
and
actually
comes
back
to
exactly
what
Rodney
mentioned.
Is
these
two
points
are
basically
kind
of
about,
and
they
don't
even
say
quantum
I
think
other
than
well?
Actually,
no
actually
I
think.
Maybe
six
point
six
makes
something,
rather
than
per
point
being
anything
you
beyond
what
a
classical
that
we
would
have
as
a
goal
these
this
list
highlights.
A
Why
do
we
what's
different,
for
example,
in
this,
make
them
easy
to
manage
and
monitor
I
kind
of
highlighted
that
in
a
classical
number
you
can
actually
read
your
pack,
and
you
can
read
your
headers.
You
can
read
even
the
data
of
your
packet,
if
you
so
wish
in
a
quantum
network.
Your
qubit
is,
you
can't
read
it.
You
can't
know,
for
example,
a
key
quantity
in
quantum
Alex's
fidelity
or,
as
you
can
to
just
go
like
Oh.
A
What's
my
entangled
pair
fidelity,
you
can't
just
easily
read
that
it
requires
if
you
wanted
to
keep
track
of
fidelity
through
there
as
the
entangled
pair
grocery
other
network,
you
would
need
to
have
a
fairly
complex
and
time
common
tracking
mechanism
density,
matrix
tracking
mechanism
and
I
guess.
From
this
point
point
of
view,
I
think
these
goals
do
add
that
whilst
it's
not
surprising
that
they're,
basically
exactly
the
same
as
for
a
classical
network,
it's
important
to
keep
those
where
they
really
highlight
what's
different.
A
If
that
makes
sense,
so,
at
least
in
the
for
example,
four
point:
six
a
it
has
a
point
that
the
qubit
is
different
point.
Seven
actually
is
actually
just
a
repeat
of
actually
now
it's
not
going
to
repeat.
It
mentions,
there's
two
channels
now,
there's
a
quantum
in
a
classical
channel
and
that
may
provide
it
quite
various
challenges
in
ensuring
availability
and
resilience.
So,
for
example,
you
may
have
networks
that
have
one
optical
fiber
between
pairs
of
nodes,
which
is
shared
between
classical
and
quantum.
A
H
It
not
necessarily
connected
to
rods
point,
but
one
of
the
interesting
ways
to
think
about
goals
as
what
are
non
goals
here
and
that
you
know
it
does
them.
Are
there
no
double
negative,
no
non
goals,
or
are
there
explicit
non
goals
here,
just
to
throw
one
out
which
again
I
completely
agree
with
these
we're
not
supporting?
Let's
see,
is
not
part
of
this
document
or
you
know
heterogeneity
is
you
know,
cubic
cutter
Jena
tea
is
not
supported,
or
something
like
that.
Do
we
have
any
sort
of
big
tent
non-goal
items
in
this
section.
H
Good
question,
and
again
it's
just
a
canoe:
it's
just
a
it's
more
to
think
about
what
your
goals
are
by
contrasting
with
your
non
goals.
It's
not
I'm,
not
trying
to
explicitly
say
that.
But
it's
just
a
way
to
think
about
this,
and
you
know
just
we're
doing
something
different,
because
it's
quantum
and
we
can't
do
it-
classically
I'm
trying
to
come
up
with
something.
The
reason
why
is
I
there's
not
a
lot
of
non
goals
which
makes
this
kind
of
like
a
reasonable
generic
set
of
goals.
D
Which
is
interesting
about
like
six
is
that
it
talks
about
what's
different
and
some
of
the
problems
with
five,
that
it
takes
all
the
points
and
it
takes
a
while
to
get
to
highlighting
what's
different
with
the
quantum
security
and
how
that
affects
the
goals
helps
the
first
little
paragraphs
are
number
five,
quite
generic,
and
then
the
third
paragraph
starts
talking
about.
What's
different.
What
makes
it
what
makes
it
interesting
and
six,
but
six
is
much
clearer
about
highlighting
okay,
what
why
is
it
cooks
to
network
different
than
how
does
this
affect
the
goals.
A
Point
so
I
think.
Yes,
so
if
all
these
goals
are
carefully,
I
would
I'd
reread
all
these
goals
and
there
should
all
carefully,
especially
just
to
address
rods
point
we
shouldn't
be
stating
stuff,
that's
kind
of
known
from
classical
networks,
but
it's
worth
highlighting
goals
based
on.
Why
is
it
different
in
quantum
network.
I
Is
Shawn
for
normal
just
to
jump
in
there
I
think
it's
it's
useful
to
list
that
you
know
not
trying
to
be
any
different,
and
maybe
you
could
have
a
paragraph
at
the
beginning.
It
says
you
know
quantum
networks
you
know
want
to
ensure
the
same
things
as
classical,
and
here
are
the
ones
that
are
different
right.
I
I
think
you've
given
end
up
with
like
you're
damned
you
do
and
damned.
If
you
don't,
if
you
blow
the
section
away
people
going
to
ask
what
are
your
goals
right-
and
this
is
a
section
I
think-
is
also
targeted
not
of
the
people
that
are
deeply
involved.
It's
targeted
the
casual
observers
like
me
that
we're
showing
up
and
just
reading
the
document
right,
yeah.
A
So
point
is
to
say
this:
a
lot
of
these
goals
are
not
new,
but
here
we
and
it's
very
important-
that
at
every
point
it
really
focuses
on
the
difference,
rather
than
just
repeating
sentences
such
as
like
in
point.
Seven,
there
is
a
practical
and
usable
network
is
able
to
continue
an
OP
very
despite
losses
and
failures.
A
Bla
bla
bla,
which
is
something
you'd
want
to
say
about
any
network,
and
the
point
that
this
kind
of
point
should
be
like
point
six,
which
starts
that
the
fundamental
unit
of
quantum
information
is
a
qubit
which
cannot
be
actively
monitored
as
any
readout
irreversibly
destroys
its
contents.
So
I've
kind
of
this
section
is
rephrase
to
really
really
drive
these
differences
that
might
make
it
more
worthwhile.
D
B
D
A
J
It's
very
very
Potts.
You
cannot
tell
the
contents
of
cube
about
the
storing
it.
However,
you
can
keep
track
by
counting
of
where
two
differents
does
is.
The
two
ends
of
the
qubits
are
at
that's
adding
one
time,
and
that
is
going
to
maybe
more
interesting
for
monitoring
than
the
Africa
cubed
context.
Yes,.
A
That
is
very
much
correct,
so
it
actually
introduces
a
new
challenge
and
to
quantum
networking
because
wasn't
quite
it
was
some
classical
networks.
You
only
have
to
keep
track
of
where
a
single
packet
is,
as
it
goes
through
the
network,
and
here
at
any
time
you
have
to
monitor
the
location
of
two
qubits.
A
A
So
principles
versus
goals,
I
think
we've
already
touched
on
this,
and
the
goals
were
meant
to
be
more
like
what
are
we
striving
towards
and
the
principles
are
more
like
how
originally
I
had
more
points
here,
but
I've
removed
the
ones
which
I
felt
were
my
opinion
and
we're
not
sufficient
in
general,
because
I
think
it's
been
important.
That
there's
documented
tries
to
make
no
claim
on
what
is
the
right
architecture,
and
that
was
actually
quite
important
to
me.
A
So
basically,
well.
Similarly,
there's
fewer
points,
there's
only
four
and
they're
shorter
and
we'll
go
over
them
and
we'll
see
what
we
can
discuss
and
I
already
think.
I
know
what
the
first
comment
might
be
about
the
part
number
one,
which
is
part
number
one
I
say
that
the
bell
pairs,
the
entangled
pairs,
are
the
fundamental
building
block
the
as
we've
roller
discussed.
We
build
entanglement
by
creating
these
to
relink
pairs
and
then
extending
them.
A
Well,
there's
also
the
question,
and
that
often
comes
up
is
multi-part,
I'd,
entanglement
and
I
guess.
My
question
to
everybody
is
especially
those
who
understand
multi-party
entanglement.
Is
it
worth
mentioning
multi-part
at
entanglement
in
this
point,
or
is
it
okay
to
keep
the
principles
in
basically
saying
we're
building
everything
from
entangled
pairs
specifically
about
pairs.
E
F
B
A
A
F
That
Bell
pairs
alone
are
sufficient,
more
efficient
to
use
larger
states
they're
actually
produced
by
the
network.
We
know
that
applications
may
want
multi-party
states
and
they
can
either
build
those
by
using
Bell
pairs
or
they
can
ask
in
the
network
to
do
something
more
efficiently.
So
it's
partly
that
distinction
between
application
and
what
the
network
what's
minimum
functionality
that
the
network
has
to
promise.
H
B
You
know
just
one
point:
I
mean
if
you
want
to
meet
the
goal,
that
we
don't
support
application
and
especially
we
want
to
support
tomorrow,
distributed
Quantum
application.
We
have
to
make
sure
that
we
don't
write
something
that
is
too
restrictive,
okay
and
and
and
probably
that
that's
where
that's
one
reason
to
include
multi-part,
eight
or
at
least
to
use
a
word
that
could
be
understood
as
pairs
or
more
and
and
yes,
and
so
maybe
the
fundamental
building
block
instead
of
baton
being
bad
pairs
is
just
entanglement.
Quantum
correlation.
A
A
It's
as
Rodney
mentioned
it's.
This
is
actually
not
guaranteed.
It's
quite
possible
that
having
the
network
give
you
their
more
complex,
entangled
state
to
start
with.
Has
such
performance
gains
and
efficiency
gains
that
it
might
be
that
this
that
the
network
should
not
itself
be
confined
to
entangled
pairs,
so
I'm
gonna
go
with
what
Matthias
said
and
not
make
this
principle
restrictive,
but
make
sure
that
it
states
what
needs
to
be
stated.
A
But
the
point
is
that
you
don't
actually
it's
effectively
that
that's
kind
of
just
saying
that
that
pairs
are
kind
of
reusable
bound
to
this
fidelity
threshold.
So
it's
not
like
when
you
send
a
packet
with
particular
user
data.
Well,
how
does
that
user
data
and
has
to
reach
its
destination
with
this
particular
identifiers?
These
entangled
pairs
can
be
reused
and
it
kind
of
allows
for
certain
new
strategies
in
your
network.
So,
for
example,
you
if
you
know
that
you're
going
to
have
a
demand
for
a
particular
fidelity.
A
A
A
A
B
Because
you
might
understand
it,
I
mean
if
you
are
not
from
the
from
the
field.
You
might
understand
it
that
you
that
you
have
one
pair.
This
can
be
used
for
something
and
then
the
same
pair
can
be
used
for
us
for
something
else
after
having
been
used
for
this.
For
for
the
first
thing,
which
is
not
possible
to
cause,
but.
A
The
last
paramedic
stuff,
both
kind
of
together
one
states,
fidelity,
is
part
of
the
services.
Time
is
part
of
the
service.
Fidelity
is
part
of
the
service
kind
of
simply
states.
You
can't
just
say
I
want
10
entangled
pairs
per
second,
because
you
know
it's
kind
of
meaningless
to
say
that
unless
you
say,
I
want
to
turn
angle.
A
Pairs
per
second
I
have
at
least
fidelity,
0.7
or
I
want,
because
the
same
link
may
potentially
provide
you
with
higher
fidelity
pairs,
but
in
lower
through,
and
what,
if
your
link
cannot
simply
deliver
the
fidelity
such
as,
for
example,
maybe
zero-point.
You
need
a
fidelity
of
0.9
and
if
your
link
can
deliver
a
hundred
entangled
pairs,
but
it
can
never
deliver
them
at
0.9,
then
that
link
is
potentially
useless
to
you.
So
that's
kind
of
what
I
mean
fidelity
is
part
of
the
service
and
I
feel
it's
a
yes.
Okay,.
B
Because,
because
when
you
read
this
in
the
first
place,
you
understand
that
you're,
okay,
what
has
identified
a
key
performance
indicator
of
the
system?
That's
fine!
We
need
some.
But
what
is
specific
to
this
one
and
actually
what
I
understand
from
what
you
have
just
said.
Is
that
it's
specific,
because
there
is
a
threshold
in
which
it's
useless?
Yes,
but
it's
not
quantitative
according
to
table.
A
A
A
A
lot
of
these
limitations
are
going
to
be
with
us
for
a
long
time
and
they're,
essentially
that
we're
used
to
now
that,
for
example,
classical
memories
kind
of
drop
information,
not
because
they
expire
in
time,
but
because
you
know
we
don't
have
more
space
there's
in
quantum
and
we're
teachers
at
least
your
information
may
expire.
Simply
because
it's
become
useless,
it's
decreased
below
a
certain
the
fidelity
threshold.
A
A
A
Something
there's
a
very
brief
section,
there's
only
very
briefly
said
and
I
basically
saying
a
detailed
list
of
such
requirements
of
the
other
scope
of
the
MIMO
and
no
there's
a
really.
There
was
a
related
draft
that
specified
the
link
layer
service.
So
whilst
it
specified
a
link
layer
service,
a
lot
of
it
is
actually
designed
with
applications
in
mind.
So
it
may
be
worth
actually
reviving
that
draft
to
kind
of
address.
What
does
it
mean?
This
service
is,
and
that
makes
sense.
G
That
document
I
guess
that
services
is
like
the
it
is
an
ink
layer
and
I,
never
clear,
but
I
I
guess
somewhere
in
this
document
also
mentioned
the
service.
The
major
service
provided
apart
from
Internet,
is
a
entitlement
distribution
so
that
one
is
more
like
the
network
layer,
so
I
I,
guess
those
two
examples
just
to
show
the
service
could
be
given
layers.
I
was
thinking
if
we
can
describe
or
define
subtle
somewhere
and
then
now,
when
we
talk
about
the
design
principle,
and
then
we
tell
you
that
definition
more
clearly,
yes,.
A
H
Have
a
I
have
a
general
question
which
is
possibly
also
in
a
can
of
worms.
Is
this
in
fact
fidelity
being
part
of
the
service?
What's
the
relation
to
Videla,
T
and
error
correction
here
in
that,
do
we
r
is
error,
correction,
a
layer
above
this
particular
comment?
Infidelity
is
part
of
the
service,
or
is
it
or
do
we
have
error
correction
integrated
into
what
we
want
to
do
and
I'm
just
and
one
of
the
services
I.
Think
here
is
error.
Correction
that
is
support.
H
We
say
fidelity
is
part
of
the
service,
perhaps
bringing
out
that,
in
fact
being
able
to
support
a
variety
of
error,
correction
techniques
and
I-
just
don't
know
about
enough
about
error
correction
to
know
whether
this
works
but
I
I,
want
to
being
able
to
support
error
correction
is
important.
Yes,.
H
F
F
So
we
have
two
basic
approaches:
there's
angleman
purification,
which
is
basically
error,
detection
and
then,
if
you
have
substantially
better
systems
than
you
can,
then
you
can
put
in
error
correction,
and
so
there
are
two
separate
ways
of
achieving
that
goal
of
providing
fidelities
from
the
service,
but
yeah
I.
Think
calling
out
error
correction
explicitly
in
this
part
is
a
good
idea
in.
H
Particular,
for
example,
the
network,
the
IP
network
layer,
does
have
a
checksum,
so
it
will
detect
and
throw
away
errors,
but
it
means
that
in
fact
you
can
build
better
error
correction
protocols.
On
top
of
that,
and
it's
designed
to
support
that's
layer,
I
think
I.
Think
that
making
sure
that
a
goal
here
is
that
we
support
a
variety
of
error,
correction
protocols,
error
detection
and
error
correction.
So.
A
More
worms,
no,
but
that's
a
good
point.
It
should
be
mentioned
that
how
problem
mention
that
error
correction
is
a
way,
as
Ronnie
said,
the
way
to
achieve
mobility
right
so,
as
we
are
out
of
time
and
I'm
going
to
post
the
minutes
of
this
meeting
on
the
data
tracker
and
on
the
mailing
list,
and
we
have
a
few
discussion
points
to
continue
on
the
mailing
list.
But
what
I
will
do
basically
is
currently
take.
A
All
discussed
include
that
in
the
draft
address
also
a
bunch
of
other
cons
that
have
since
piled
into
the
draft
since
about
March
and
then
I
plan
to
actually
them
is
basically
ready
for
kind
of
to
start.
The
last
rams
are
reviewed
by
the
group
before
completing
it,
hopefully
maybe
by
July
IETF
meeting,
maybe
the
next
one,
and
but
there
doesn't
seem
to
be
much
work
to
do,
but
that's
basically
what
I'm
going
to
do
and
the
remaining
discussions
will
proceed
on
the
mailing
list
and
okay
thanks
a
lot.
A
A
F
I've
got
all
you
here.
Thank
you,
Thompson
J
I
should
chat
sometime
between,
while
and
and
the
July
IETF
on
the
yeah
organizational
stuff
for
that
yeah
I.
Don't
think
we
need
to
talk
anything
more
about
getting
a
request
in
for
it
to
the
TV
for
the
for
the
meeting
time.
If
you
want
to
go
ahead
and
commit
that
I've,
so
you
don't
have
any
time
requirements
no
just
submitted,
then
I
emailed
you
a
couple
of
other
constraints,
I'd
like
to
add
okay.
F
Thank
you,
James
Thomson
I
do
not
think
about
time,
because
I
actually
had
not
considered
what
time
is
this
actually
going
to
be
ringing?
Actually
it's
a
good
point,
because
I
guess
actually
I
don't
know
how
that's
going
to
conflict
with
our
end
of
semester
schedule,
but
you
know
it's
off
by
12
hours
or
something
anyway.
So.
F
D
F
F
Did
a
reasonable
hour
show
to
now
works
for
an
employer,
so
he
keeps
something
approximating
regular
hours,
he's
still
sort
of
you
know
a
24
hour
person
and
likewise
for
South
on
track
again,
we
should
probably
try
to
get
a
soft,
though
to
actually
talk
about
the
the
attacking
the
quantum
Internet
one.
With
the
meeting
there
was
some
interest
in
luck.