►
From YouTube: IETF-PANRG-20220601-1500
Description
PANRG meeting session at IETF
2022/06/01 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
My
co-chair
gen
will
not
be
joining
me
today
for
this,
because
the
the
timing
here
was
designed
to
be
decent
for
people
from
the
east
coast.
You
know
just
decent
for
people
from
the
east
coast
into
or
the
west
coast
of
the
us
into
europe
and
she's
in
sydney.
So
the
time
zones
are
kind
of
brutal
I'll
wait,
another
minute
or
so
for
people
to
come
in.
A
So
hello,
everyone
again
good
morning,
good
afternoon,
welcome
to
the
pathway,
networking
research
group-
I
am
brian
drammel.
One
of
your
two
co-chairs,
as
I
said,
jen,
will
not
make
it
today
due
to
fun
with
time
zones.
This
is
a
meeting
of
an
irtf
research
group
and
therefore
is
subject
to
the
irtf
notewell.
The
rtf
follows
the
ietf
intellectual
property
right
disclosure
rules.
If
you
are
not
familiar
with
them,
please
do
review
them
before
saying
anything
at
the
microphone
or
making
another
contribution
to
this
meeting.
A
A
Given
that
here
is
our
agenda
today,
we
basically
have
four
points
on
the
agenda
and
one
presentation.
I
expect
today
to
be
mainly
a
q,
a
slash
discussion
meeting.
There
will
be
a
we'll
start
off
with
an
overview
of
scion,
which
is
also
drawn
from
draft
to
copter
panerji
scion
overview
and
then
we're
going
to
have
a
bit
of
q,
a
in
general
discussion
sort
of
like
especially
focused
on
cyan
and
the
questions
raised
in
rfc
9217
and
then
a
bit
of
discussion
about
next
steps.
A
So
I've
like
very
liberally
put
time
in
the
agenda
for
those
two
like
35
30
minutes,
but
like
basically
we're
hoping
that
therapy
discussion
will
go
on
and
then
we'll
naturally
follow
the
next
steps.
Part
of
that.
Why
are
we
here?
What
is
the
purpose
of
this
meeting?
So
there
was
a
scion
side
meeting
at
ietf
113
in
vienna,
so
this
presented
zion.
It's
an
internet
architecture
that
addresses
many
of
the
research
questions
that
are
raised
in
the
research
group.
A
D
B
B
D
A
B
A
A
Be
able
to
share
the
pre-shared,
the
pre-uploaded
slides
as
well,
I
uploaded
the
slides,
but
I'm
not
showing
any
pre-shared
slides
in
there
are
no
slides
available.
If
you
go
into
settings,
you
can
probably
tell
it
to
convert
them
in
top
right
corner.
There
is
a
little
triangle:
settings
manage,
slides,
okay,
import,
this
deck
import.
I'm
sorry!
I
thought
that
that
was
already
done.
Okay,
now
you
can
or
here
well
just
to
save
some
time.
I
will
share
pre-loaded
slides
and
you.
C
A
B
B
B
B
We
will
briefly
describe
what
sign
is
about,
then
we,
I
want
to
tell
you
shortly
why
we
think
at
this
time
the
timing
drive
to
bring
science
to
the
ietf
and
to
maybe
start
this
standardization
process,
and
then,
of
course,
we
would
like
to
show
you
what
we
think
for
us
are
the
next
steps.
But
of
course,
this
in
the
end
depends
on
your
feedback
and
comments
during
this
meeting
on
the
draft
on
sign
in
general
and
also
on
sign
in
the
context
of
the
penalty
and
ietf.
B
B
We
are
all
the
three
of
us
are
affiliated
with
the
sign
association
and
design
association
is
currently
in
the
process
of
being
founded
or
launched.
This
is
a
non-profit
organization,
bridging
the
gap
between
academia
and
industry.
Another
purpose
is
to
promote
the
global
sign
adoption
and
also
to
maintain
and
expand
the
sign,
open
sort
code
base.
B
And
sign
itself
is
a
inter-domain
path,
aware
next
generation
architecture.
It
stands
for
the
word.
Science
stands
for
scalability
control
and
isolation
on
next
generation
networks.
It
offers
securability
and
availability
by
design
and
it
provides
root,
control
failure,
isolation,
multipath
rousing
between
hosts
and
trusts.
It
offers
trust
information
for
end-to-end
communication.
B
The
whole
science
project
started
back
in
2009
at
the
in
the
group
of
adrian
perrick,
in
the
context
of
studying
security
of
inter-domain
routing
protocols
and,
in
the
meantime,
assign
is
really
already
in
production
used
by
seven
service.
Internet
service
providers
and
five
more
service
providers
have
trial
deployments.
B
Just
what
what
we
want
to
intend
with
this
informational
internet
draft
is
offering
an
introduction
into
sign
and
the
motivation
to
develop
cyan,
and
it
is
really
only
providing
a
very
high
level
description
of
sign,
its
architectural
components
we
want
to.
We
want
it
to
serve
as
some
kind
of
reference
document.
B
So
at
this
moment,
this
draft
only
hopes
to
how
do
you
say
it
to
help
you
explain
what
sign
is
about
and
how
it
works
on
a
high
level
and
all
these
technical
discussions,
in-depth
technical
discussions
will
come
with
further
internet
drafts.
We
would
like
to
write
about
authentication
and
pki
infrastructure,
how
the
control
page
works
and
routing
about
sign
data
plane,
also
the
security
considerations
and
implications,
and
as
well
as
we
also
want
to
provide
a
more
much
more
detailed
analysis.
B
B
B
B
Then
there's
also
a
sign
data
plane,
and
this
is
in
charge
of
the
packet
forwarding.
So
in
the
data
plane,
the
path
segments
are
combined
into
paths
and
the
packets
contain
this
pass
information.
The
routers
then
forward
packets,
based
on
this
pass
information
and
design.
Routers
are
a
simple,
simple
routers
which
operate
statelessly.
B
I
shortly
also
want
to
show
you
what
a
scion
autonomous
system
in
itself
looks
like
so
this.
This
is
an
example
of
a
sine
autonomous
system,
and
then
the
sign
routers
are
at
the
borders
of
such
a
autonomous
system
and
their
function
is
to
pair
with
other
sign-enabled
networks
and
to
collect
customer
accesses
and
they
they
have
to
be
able
to
communicate
and
to
connect
and
link
with,
on
with
other
sign
based
networks
or
autonomous
systems.
B
So
this
shows
that
is
also
really
of
use
for
institutions
in
different
areas
or
or
companies.
Then
we
have
a
research
network
which
uses
science
to
connect
the
swiss
institutions
of
the
eth
domain.
It's
called
science,
and
then
there
is
the
scion
lab
research
touchpad,
where
we
test,
for
instance,
future
features
before
we.
They
are
really
getting
into
use.
B
It
is
also
demanded
by
early
adopters
because
they
want
to
have
a
standardized
product.
They
don't
want
to
have
something
which
is
going
to
change
again
and
again
and
of
course
standardization
will
facilitate
acceptance
of
science,
and
it
also
will
prevent
from
talking
past
one
another.
So
I
mean
it
will
it
will
prevent
from
that.
Two
parties
speak
of
sign,
but
do
mean
something
else,
and
it
will
ensure
interoperability.
B
Then
we
also,
there
is
a
rfc
5218
which
describes
what
it
needs
to
be
for
a
protocol
to
be
successful,
and
it
seems
that
we
already
fulfill
these
requirements
like
sign,
does
not
have
to
be
used
by
the
entire
internet.
To
you
know
to
be
to
work
it's
there
is
it
supports
incremental
deployability,
then
we
know
from
the
service
providers
and
also
the
the
users
who
already
use
sign
that
the
benefits
of
deployments
outweigh
the
costs.
B
B
And
the
other
thing
which
I
already
shortly
men
mentioned
it-
that
we
really
hope
that
we
can
provide
answers
to
questions
raised
in
this
rfc
9217
current
open
questions
in
pathware
networking
and,
of
course
we
cannot
answer
all
the
questions
yet,
but
we
think
we
can
really
our
experiences
with
scion
in
deployments.
Will
we
will
will
be
of
great
help
to
answer
these
questions
and
we
think
we
can
already
give
some
answers
regarding
the
question:
how
do
endpoints
get
access
to
trustworthy
past
properties?
B
B
We
maybe
in
the
end,
would
like
to
to
get
it
published
as
an
informational
rfc,
because
then
we
can
really
re
refer
to
it.
Like
I
already
said
it
is
our
intention
to
to
use
it
as
a
referential
document,
and
then
this.
We
also
hope
that
we
can
be
this
kick
off
further
ietf
work
and,
and
maybe
start
a
possible
standardization
process.
B
And
what
we
think
can
be
next
steps
from
our
point
of
view
is
then,
of
course,
first
address
the
comments
and
the
feedback
we
get
in
this
meeting
and
then
based
on
that
publish
a
new
version
of
the
internet
draft
before
the
next
ietf.
It
will
be
in
july
in
philadelphia
and
then
based
on
on
how
much
feedback
we
get
and
how
thorough
it
is.
B
B
A
B
A
F
Hi
there
thank
you
for
coming
and
and
talking
to
us
about
this.
I
had
two
questions.
One
was
you
you
mentioned
that
the
you
know
you
mentioned
that
you
have
you
all
have
looked
at
the
you
all
have
looked
at
the
successful
protocols.
Rc,
I
don't
know
if
you
all
have
looked
at
a
rfc
that
pan-rg
has
produced
came
out
relatively
recently
called
it's
rc-9049.
F
And
it's
talking
about
obstacles
to
deployment-
and
this
is
this-
this
is
the
the
sad
tale
of
woe
that
the
ietf
has
had
with
path
aware
protocols
and
basically,
it's
kind
of
a
list
of
what
not
to
do.
We've
done
a
couple
of
of
exercises
where
we've
looked
at
other
protocols,
just
you
know
to
see
well,
you
know,
are
we
know
where
we
know
where
at
least
some
of
the
land
mines
are,
or
is
this
protocol
stepping
on
any
of
them
so
that
going
through?
F
B
A
B
A
From
like
1949
and
9217,
as
well
as
sort
of
what
makes
us
official
protocol
from
these
three
rfcs,
which
were
basically
written
to
sort
of
like
give
guidance
in
this
space
from
you
know,
operational
wisdom
that
we've
we've
built
for
you
know
running
the
actual
internet.
Is
there
anything
that
might
feed
back
into
that
into
sort
of
like
future
iterations
of
of
scion
development
or
sort
of
like
future
things
that
you
would
do
in
terms
of
like
further
deployment
of
scion
beyond
it's
its
current
deployment?.
A
G
G
A
Yeah,
so
I
think
now
like
it's,
you
know
it's
been
a
while,
since
we've
all
been
on
airplanes,
I
think
now
the
hackathon
runs
the
week
before
philadelphia.
Do
you
have
a
look
at
the
at
the
like?
The
logistics
should
be
up.
You
know,
make
sure
you
show
up
on
time,
obviously,
because
it
used
to
be
just
the
weekend
before,
but
then
we
found
it
was
actually
kind
of
useful
to
run
it
for
longer.
A
G
I
I
did
have
a
question
for
you
and
didn't
as
well.
How
do
you
see
applications
using
this?
Do
you
expect
the
applications
to
kind
of
natively
who
control
this
architecture?
Are
you
looking
for,
like
proxies
and
gateways
to,
like
you
know,
stitch
them
together,
because
I
think
that's
the
hardest
part,
and
that
has
been
like
you
know,
for
this
multi-homing
and
all
these
like
brazilians
proposals
is
the
in-house
support.
So
what
are
your
thoughts
on
that.
G
G
Of
course,
we
have
libraries
that
can
support
zion,
we're
also
looking
at
pure
application
level
support,
so
that
the
whole
stack
can
be
directly
bundled
with
the
application,
and
we
have
an
auto
discovery
system
that
enables
the
system
to
detect
if
the
local
isp
offers
and
support
and
then
essentially
turn
on
this.
This
stack
and
allow
the
application
to
directly
use
it.
G
An
interesting
aspect
also
is
to
extend
the
happy
eyeballs
approach
I
see.
Tommy
is
also
online,
who
has
been
driving
this
and
essentially
adding
sign
is
a
third
is
a
third
option,
besides
ipv4
and
ipv6,
and
then
yet
another
thing
that
we've
looked
at
is
also
in
the
context
of
taps,
where
brian
and
also
tommy
have
been
very
active
in
that's
in
that
space
to
and
there's
also
has
been,
are
actually
things
insights
that
we
had
in
cyan.
G
A
A
a
presentation
from
a
master
student
who
had
done
a
taps,
a
scion
sort
of
taps,
bridge
implementation
and
sort
of
reported
back
to
the
working
group
on
on
you
know
reflections
on
taps
there.
I
don't
know
if
that
you
know
I.
I
know
how
a
lot
of
master
student
code
you
know
makes
it
into
reality
and
how
a
lot
of
it
doesn't.
So
I
don't
know
if
that's
still
maintained,
but
we
did.
We
did
find
that
useful
in
the
taps.
Working
group
as
well.
A
H
H
But
besides
that,
we
also
have
other
transitions
mechanisms
that
are
more
transparent
to
end
users,
and
they
are
also
very
briefly
mentioned
in
the
draft
at
the
moment.
We
just
didn't
want
to
make
it
too
to
have
it,
but
there's
there's
a
lot
of
things
going
on.
Let's
say
in
research,
I
was
just
wondering
how
much
it
would
be
helpful
to
add
more
on
that
in
the
draft
in
this
draft.
A
This
is
my
opinion
as
an
individual,
not
as
the
chair
and
then
I'll
and
then
I'll
say
something
as
the
chair
as
an
individual.
I
think
the
overview
should
probably
stay
an
overview,
and
but
the
you
know
the
other
ways
that
you're
looking
at
at
doing
transition
for
a
protocol
transition
like
this
should
be
their
own
documents.
A
Now
I'll
put
my
chair
hat
on
and
say,
as
a
you
know,
member
of
the
irst
and
the
chair
of
a
research
group.
When
I
hear
someone
talking
about
experimental
transition
methods
to
get
a
new
protocol
deployed,
my
ears
pick
up
and
I'm
like.
Oh,
this
is
exactly
the
type
of
thing
that
we
should
be
talking
about
in
pan
rg.
A
So
I
think
that
you
know
a
deep
exploration
of
those
would
make
excellent
sort
of
document
within
the
research
group
as
well
as
sort
of
like
the
overview
of
saying
here's
the
framework
for
things,
but
I
think
that,
like
digging
into
how
you
would
actually
run
a
transition
like
this
is,
is,
like
you
know,
bread
and
butter
for
for
for
pan
energy
sounds
good.
Thank
you
thanks
nicholas
so
maria
isn't
you.
J
Yes,
so
I
mean
talking
about
documents,
and
so
I
looked,
I
didn't
read
it
fully,
but
I
looked
at
the
document
and
it's
a
very
well
written
document,
but
it's
not
the
kind
of
thing
that
I
need
in
an
internet
drive.
What
I
really
need
in
the
internet
draft
is
protocol
bits
which
are
currently
not
there,
and
especially,
what
makes
this
discussion
very
hard.
J
Is
that,
like
you,
present
this
as
a
whole
system
and
we
try
usually
to
look
at
building
blocks,
and
what
I
see
here
is
that
you
at
least
have
three
different
parts
here
which
all
need
to
work
together,
which
one
one
is
the
kind
of
the
trust
system.
The
other
one
is
the
routing
protocol
and
the
third
one
is
a
data
plane
and
I'm
wondering
how
much
it
would
be
possible
to
separate
those
things
and
also
to
rely
maybe
on
existing
protocols
for
parts
of
that
like.
J
Why
is
the
current
key
system
not
suitable
for
saying,
or
would
there
be
a
way
to
take
the
q
and
key
system
or
trust
system
and
make
it
suitable
to
science
rather
than
developing
an
entirely
owned
system?
Right
and
the
same,
I
think,
is
true
for
the
data
plane.
There
is
a
lot
of
work
in
the
ietf
in
the
area
of
segment
routing
which
is
like
from
a
protocol
point
of
view,
probably
provides
the
same
thing
as
you
need.
G
J
G
J
E
G
B
J
A
J
G
G
I
think
it
can
play
very
well
together,
more
to
add
segment
routing
headers
to
also
obtain
intra-domain
guarantees,
whereas
zion
mostly
provides
the
inter
domain
guarantees
the
links
between
the
different
autonomous
systems,
so
combining
the
two
densan
has
the
the
cryptographic
aspects
to
protect
the
policies
of
of
the
paths.
The
entities
that
created
the
paths
would
then
play
nicely
together
with
the
more
trustworthy
environment
of
intradomain.
J
Two
act,
I
mean,
I
think
what
you
should
do
is
rather
than
saying-
and
I
mean
I'm
not
an
expert
in
segment
routing
and
there
are
many
opinions
in
that
space
and
so
on.
So
I'm
not
sure
if
I
give
you
the
best
advice,
but
I
think
what
you
should
do
is
rather
than
looking
at
segment
routing
or
any
other
itf
protocol
and
say
this
doesn't
fit
our
needs.
J
J
J
Your
system
is,
for
example,
easier
if
your
changes
are
smaller
right
and
the
chance
to
get
this
deployed
or
implemented
correctly
are
also
higher.
So
there's
like
a
lot
of
more
considerations
and,
at
the
end,
not
always
the
optimal
solution.
Whatever
you
would
see
in
your
research
as
the
best
solution
is
the
one
that
gets
standardized
for
various
reasons.
J
A
H
D
A
So
I
think
we're
already
kind
of
going
into
the
next
steps
discussion,
but
I
did
have
two
questions
from
the
from
the
chat
that
I
wanted
to
pose
before
we
before
we
continue
this,
so
I
will
put
myself
in
queue
before
spencer
eric
klein
asks.
Is
it
easy
for
developers
and
tinkerers
to
play
with
it
natively
you
know,
parentheses.
I
went
looking
for
an
ether
type
on
the
ayanna
page
and
I'm
assuming
that
that
trail's
off
into
I
I
didn't
find
one.
A
H
This
one
for
playing
around,
I
think
the
best
way
is
to
use
scion
lab,
which
is
our
research
and
development
network.
I
think
there
was
a
link
in
into
the
slide
at
the
website
scionlab.org
and
you
can
register
and
then
you
can
from
the
website.
You
can
already
download
all
the
sign
configuration
to
attach
your
own
device,
where
you
then
get
all
the
software
packages
to
run
scion
natively.
So
that
means
that
you
can
really
choose
the
paths
and
so
on.
H
A
A
A
A
You
know
the
question
that's
being
asked
in
the
the
presentation:
do
we
want
to
adopt
this
overview
as
a
research
group
draft?
I
think
I've
heard
one
very
good
idea
for
a
research
group
draft
looking
at
sort
of
like
the
experimentation
for
different
transition
mechanisms.
Right
like
we
talked
about
sort
of
like
the
user
space
udp
data
plane
encapsulation.
That
would
allow
you
to
just
compile
the
scion
stack
directly
into
an
application.
That
sounds
super
useful.
A
You
know
tunneling
approaches,
you
know
ways
to
transition
from
tunneling
to
native.
I
think
there's
been
a
lot
of
work
done
by
the
scion
folks
in
this
area.
That
would
be.
You
know,
super
useful
to
have
in
the
research
group
just
to
sort
of
generalize
that
knowledge,
if
nothing
else
that
could
lead
to.
My
second
point,
larger
scale,
experiments
with
scion
sort
of
within
the
auspices,
the
research
group.
It's
like
there's
the
scion
lab.
A
Is
there
some
sort
of
like
cooperation
or
venue
arrangement
with
the
research
group
where
we
could
sort
of
like
foster
large-scale
experimentation?
I
don't
know.
Is
there
you
know
a
way
that
this
work
could
be
a
conduit
for
parts
of
scion,
and
I
think
that
you
know
muria
raised
a
really
good
question.
You
know
parts
you
know,
let's
put
parts
in
bold
and
italic
here
of
scion
into
appropriate
ietf
working
groups,
but
like
I'm
just
the
chair,
I'm
just
here
to
use
meet
echo
poorly.
F
F
F
I'd
like
to
talk
about
a
couple
of
the
reasons,
so
one
of
the
things
that
is
worth
thinking
about
is
what's
the
level
of
maturity
of
the
different
pieces
that
make
up
scion
and
the
question
that
you
know
is
basically
how
you
know:
how
much
has
this
been
deployed?
How
much
has
this
been?
How
much
experience
do
we
have
with
it?
F
How
stable
has
it
been
where
it
doesn't
have
to
be
all
the
same
level
of
maturity
to
move
forward
right,
so
the
question
you're
really
asking
is:
what's
research
and
what's
engineering,
what's
research
that
we
don't
actually
know
how
to
do
yet
or
do
well
or
do
an
internet
scale?
Yet
in
what's
engineering
the
there
have
been
a
number
of.
F
Protocols
that
have
come
through
the
irtf
and
the
one
I'm
thinking
of
specifically
is
hip
where
there
was
a
hip
research
group
and
a
hip
working
group.
At
the
same
time
where
the
research
group
takes
the
hard
parts
which,
at
the
time
for
them
that
was
basically
finding
other
endpoints
that
are
speaking
hip
because
the
the
hits
are
not
hierarchical.
So
you
know
like
finding
the
other
people
that
was
harder
but
doing
the
da
you
know
basically
doing
the
protocol
itself
was
engineering.
F
What
protocols
are
you
extending
and
what
protocols
are
you
inventing
and
that
that
turned
out
to
be
a
kind
of
important
question
for
a
lot
of
proposals,
and
I
think
this
is
back
again
to
myria's
thing.
Basically
saying
you
know
if
you
say
well
we're
not
going
to
reuse
segment
routing,
at
least
that
you
know
that's
the
going
in
position
right
now,
so
explaining
why
scion
doesn't
reuse.
F
The
existing
protocols
would
could
be
really
important
for
the
other
protocols,
but
I
think
it
will
also
be
important
for
your
protocol,
because
you'll
almost
certainly
be
asked
that
repeatedly
so
having
a
good
answer
that
that
you
know
all
the
authors
agree
on
would
be
you
know,
and
it
was
written
down.
Someplace
would
be
great.
F
F
F
Ask
for
feedback
and
pan
rg
is
a
really
pretty
good
place
for
people
to
ask
for
feedback
about
how
things
move
forward.
It
has
a
lot
of
people
with
a
lot
of
experience
and
I'm
seeing
at
least
two
current
isg
area
directors
in
the
meet
echo
now.
So
you
know
this
is
actually
a
good
safe
place
to
have
those
discussions
before
you
get
to
submitting
a
bar
bob
off
request
and
writing
everything
down
for
what
will
kind
of
tend
to
be
an
up
down
vote.
F
F
F
They
may
not
be
able
to
be
separable,
and
you
know
they
would
have
to
go
forward
together.
Any
two
of
them
would
have
to
move
forward
together,
but
that
might
not
be
true,
so
you
might
be
able
to
move
some
stuff
forward
if
it's
useful
on
its
own.
Without
you
know,
without
waiting
for
the
hardest
parts
to
move
forward,
and
that
was
the
last
thing
I
was
going
to
say.
A
A
H
Yeah
and
regarding
that
feedback,
we
were
indeed
thinking
about
having
a
more
in
detail,
a
gap,
analysis
draft
really
trying
to
look
at
what
is
existing
and
and
what
scion
can
add
and
why
the
existing
cannot
be
reused.
So
I'm
I'm
thinking
loudly
that
this
might
be
a
a
way
to
to
clarify
this.
It's
just
that
in
within
this
draft.
A
A
Yeah
there's
another
thing
that
I've
heard
said
I
think
miriam
said
it
first
here
that
I
want
to
try
and
rephrase
sort
of
like
pick
out
also
from
miriam.
What
very
said
what
spencer
said
is:
there's
this
question
of
fate
sharing
and
separability,
and
I
think
it's
a
really
good
exercise,
possibly
in
that
gap,
analysis
draft
to
say:
okay,
what
happens
if
we
standardize
just
the
pki
and
we
use
the
current
pki
or
the
sign
on
pki
with
the
current
internet.
A
Ipv6
protocol
stack
segment
routing,
maybe
in
a
couple
of
places
and
bgp
right.
It's
like
we
just
changed
the
pki
and
what,
if
we
say?
Okay,
we
have
the
current
internet
pki,
the
current
rpki,
the
current
dns
security
model
and
the
current
sort
of
ipv4
ipv6
dual
stack,
but
we
add
the
path,
discovery
and
the
beaconing,
and
we
say:
okay,
well,
you
know
we'll
cheat
and
we'll
be
able
to
add
the
security
of
the
path
discovery.
A
What
does
that
look
like
or
then
you
say,
and
I
think
this
is
the
one
that
makes
the
least
sense,
but
it
might
be
worth
doing
for
completeness
what
happens
if
we
standardize
the
scion
data
plane,
but
with
bgpas
numbers
and
the
current
pki?
I
don't
think
that
one
makes
a
lot
of
sense
on
its
own,
but
and
that
actually
might
be
input
to
a
discussion
about
which
of
these
things,
do
you
standardize?
A
First
right
I
mean
which
of
these
things,
and
I
don't
have
a
real
good
feeling
about
of
the
pki
and
the
and
the
path,
discovery
and
path,
exposure
and
sort
of
that
the
new
routing
paradigm.
I
don't
have
a
really
good
feeling
of
which
of
those
is
most
indispensable
on
its
own,
and
I,
I
think,
a
gap
analysis
that
also
explored
these
things.
Separably
would
be
super
interesting
and
super
useful
right,
because
I
want
to
underscore
again
with
my
chair
hat
on
here.
A
There
was
ncp
to
tcp
ip
in
you
know
1980
whatever,
and
you
could.
You
know
say
that.
Maybe
that
was
that
level
of
wholesale
architecture
change,
but
I
don't
think
it's
even
that
big
we've
never
done
this
before.
This
is
an
example
of
trying
to
do
that.
There
are
generalizable
insights
that
can
come
out
of
trying
to
do
this
as
well,
and
I
I
think
those
are
you-
know:
100
percent
energy
material
with
that
tommy.
E
E
We
actually
have
some
deployment
experience
in
some
real
networks
that
are
using
this
and
we
think
yeah
this
well,
this
one
actually
works,
and
so
it's
like,
oh,
we
actually
have
a
positive
example
now,
so
I
think,
at
the
very
least
you
know,
learning
from
this
example
of
what
makes
this
work
and
the
other
ones
didn't.
Work
is
a
useful
thing
to
do,
and
you
know
personally
I'd
like
to
more
figure
out.
E
How
can
we
evolve
the
existing
protocols
as
much
as
possible
and
not
just
have
like
here's,
a
divergent
stack
that
you
need
to
switch
over
to
something?
That's,
not
the
normal
internet,
to
get
pathway
networking,
but
you
know
I
think
at
this
point
I
I
don't
know
if
we
can
answer
the
question
of
you
know,
can
we
do
that
correctly,
and
so
you
know
digging
in
to
answer
that
question
would
be
useful
and
essentially
look
at
all
of
the
different
properties
and
figure
out.
E
You
know
what
makes
what
what
do
you
think
makes
scion
different
from
the
previous
attempts
to
do
pathway
or
networking
that
didn't
work
and
start,
maybe
with
those
properties
as
like.
These
are
the
kind
of
the
fundamental
properties
that
are
going
to
make
this
work
and
then
once
we
have
those
properties
figure
out.
You
know:
okay,
here's
this
property.
Can
we
add
that
or
find
it
in
an
existing
internet
protocol?
E
We're
gonna?
Can
we
evolve
it,
or
do
we
actually
have
the
analysis
to
say
that
this
particular
piece
of
the
existing
internet
protocol
cannot
do
that
and
cannot
be
easily
evolved,
and
so
we
do
need
to
switch
that
piece
out
for
something,
but
you
know
start
with
the
principles
that
we
think
will
make
you
succeed
rather
than
just
just
pointing
out.
E
Where
are
those
properties
shared
in
existing
protocols?
Where
can
they
be
added
or
where
do
they
need
to
be
replaced?
I
think
that
would
help
a
lot
of
us
understand
what
pieces
we
need
to
take.
What
pieces
we
don't
and
maybe
will
make
it
easier
for
people
to
come
into
the
conversation
without
being
scared
by
a
big
new
architecture.
A
Okay,
yeah
sorry,
I
was
like
furiously
typing
notes
and
muted
myself
and
then
completely
forgot.
So
myria
brought
a
point
to
the
chat
that
I
actually
wanted
to
raise
up
to
the
like
to
the
room.
You
know
this
time
with
a
microphone
that
is
on
documenting
deployments,
eg
with
gateways
and
experiences
and
challenge
with
that
is
going
to
be
more
interesting
than
just
documenting
the
architecture,
and
I
I
I
would
underscore
that.
A
I
think
that,
like
we
have
seen
a
lot
within
panergy
we've
seen
a
lot
of
proposals,
some
complete
some
incomplete
about
parts
of
the
path
awareness
puzzle.
What
scion
has
that
none
of
those
other
ones
have
is
like
actual
deployment
experience,
and
I
think
that
all
of
us
can
learn
from
that
deployment
experience
so
something
that's
really
kind
of
an
implementation
report
of
like
you
know.
You
know
we
can
read
the
stuff
in
the
papers
of
what
worked
I'd
be
more
interested
in
the
stuff.
A
That's
not
publishable
elsewhere,
right
like
so,
it's
very,
very,
very
difficult
to
publish
negative
results.
What
did
scion
try
as
part
of
trying
to
get?
You
know
this
experimental
internet
architecture
to
the
point
of
deployment
that
didn't
work.
That
I
think
would
also
be
an
interesting
input
to
the
research
group.
F
B
A
Would
be
like
an
interventional
internet
draft
to
the
research
group?
Yes,
that
would
be
an
informational
internet
draft
of
the
research
group.
Basically
just
sort
of
like
a
an
implementation
report
here
are
things
that
we
tried
here
are
like
the
paths
that
we
found
were
not
useful,
and
then
it
would
be
super
interesting
within
the
rg
to
compare
those
to
sort
of
like
spencer's
draft.
Are
there
any
gaps
that
we
missed
in
spencer's.
D
Yeah,
so
I
think
this
is
this
is
a
really
interesting
discussion
and
we
we're
doing
the
the
thing
which
research
groups
do
a
lot
which
is
diving
into
the
you
know
where
the
interesting
research
areas
are,
and
I
think
that
you
know
that's
cool
right.
I
mean
that's.
What
we
want
from
my
point
of
view
of
a
research
group
is
to
figure
out.
What's
the
open
research
questions
here
I
mean
obviously
there's
the
bigger
question
of
scion
as
a
system
and
and
how
we
approach.
D
You
know
bringing
the
whole
thing
in
and
if
we
should
bring
the
whole
thing
in,
and
you
know
I
I
think
you
know
there's
obviously
a
bunch
of
interest
in
it,
there's
a
clearly
a
bunch
of
good
ideas
in
scion,
there's,
clearly
a
bunch
of
good
deployment
experience
in
it,
and
I
think
that's
something
which
bits
of
this.
You
know
that
this
group
has
been
missing
and
you
in
in
places.
D
A
I
It's
hard
to
yeah
yeah,
so
I
think
one
of
the
things
I
was
kind
of
thinking
like
it's
probably
is
my
engineering
brain
on
like
a
little
bit
right
like
so.
How
does
this
like
work
on
the
improbably
stuff
right
right
now,
we're
looking
at
like
one
reference,
implementation,
more
or
less
right,
like
everything
coming
out
of
eta,
it's
kind
of
like
at
a
basic
level
so
like
how
does
like
somebody
do
a
build,
an
interoperable
gateway
implementation
on
some
other
site
right.
I
I
think
that
or
something
that
needs
to
get
documented
and
also
another
thing
I
couldn't
figure
out
is
the
versioning
right.
Like
you
know,
everything
is
version,
zero,
zero.
So
what
happens
if
there's
like
version
zero
one
get
stepped
up,
and
how
do
they
talk
to
each
other
right,
especially
if
somebody
else
is
implementing
it?
I
think
I
thought
that
needs
to
get
into
a
draft
somehow
right
like
you're,
not
talking
about,
like
you
know,
more
implementation,
consideration
that
nails
like
kind
of
little
bit
dovetails
into
like
what
media
was
saying
as
well.
I
A
I
think
the
versioning
one
is
a
really
really
good
point,
because
we
have.
We
have
figured
out
so
many
ways
to
do
that
wrong
in
the
ietf
and
are
working.
There's
active
work
right
now
in
the
transport
area,
where
we're
we're
trying
something
that
might
be
right,
but
we
don't
know
yet
right
so
yeah.
I
think
that
does
like,
plus
one
just
a
rash
on
both
those
points.
H
A
Leaving
the
queue
open
for
other
people
on
next
steps,
and
then
I
will
take
my
read
from
the
chair
and
then
ask
colin
to
correct
me
as
the
irtf
chair,
but
if
there
I
think,
there's
a
lot
of
good
points
here.
I
will
we'll
work
a
little
bit
this
evening
and
tomorrow
to
get
the
minutes
together.
Oh
hello,
spencer.
Go
ahead.
F
Please
count
on
me,
so
I
think
the
the
my
understanding
of
what
we're
saying
is
that
most
of
the
feedback
is
how
to
move
this
forward,
not
trying
to
talk
ourselves
out
of
moving
things
forward,
and
I
think
I
think
that
that's
an
important
thing
for
us
to
take
away
if
it's
true
and
but
I
mean
this-
this
is
what
I'm.
This
is
what
I'm
hearing
if
other
people
are
hearing
other
things
that
might
be
useful
to
know.
A
A
There
are
questions
that
we
know
that
we
need
to
be
answered
in
order
to
to
make
that
determination
and
we
don't
have
the
answers
to
those
yet
right
like
so.
What
I'm
hearing
is
that
is
a
lot
of
people
pointing
at
this
gap,
analysis
document
and
say
I
want
the
gap
analysis
document,
but
recognizing
that
the
term
gap
analysis
for
that
document
is
is,
you
know,
was
not
that
accurate
when
we
started
talking
about
it
and
through
sort
of
the
amendments
that
have
been
made
in
this
discussion
is
is
completely
inaccurate.
A
At
this
point
yeah
I
see
that
I'm
actually
kind
of
making
the
point
that
miriam
made
in
the
chat.
If
you
can
honestly
identify
existing
components,
you
can
adopt
potentially
extended
reuse.
That
makes
it
starting
to
work
much
easier.
It's
not
about
the
gaps.
It's
about
like
the
parts
to
reuse
and
how
to
extend
them,
and
I
think,
there's
also
the
the
suggestion
of
like
what
does
it
look
like
if
we
split
this
apart
and
only
do
one.
I
think
that's
another
good
way
to
approach
that
question
spencer,.
F
F
The
the
the
one
thing
I
would
say
about
that
is:
there's
that's
an
ietf,
my
my
opinion.
That's
an
itf
step
that
that,
if
you
don't
have
that
before
you
go
to
the
ietf
with
something
you're
going
to
have
a
long
you're
going
to
have
a
bunch
of
long
conversations
with
people
who
are
going
to
be
asking
the
same
question
over
and
over
in
different
venues.
F
So
maybe
so
maybe
another
interesting
thing
to
do
is
to
say
how
you
know
how
much
of
the
what
is
separable
you
know
you
know,
mario
was
talking
about
like
three
lumps
how
many,
how
many
lumps
do
the
scion
people
think
there
are
or
should
be,
and
we
might
even
find
that
other
other
people
can
look
at
those
and
say
part
of
that
is
separable,
and
you
know
part
of
that
is
separable
from
everything
in
this
lump,
and
so
we
could.
We
could
look
at
that
separately
and
potentially
propose
it
separately.
F
A
So
I
think
there
is
actually
a
question
that
I
wanna
and
you
can
you
can.
You
know
see
that
I
was
trying
to
figure
out
how
to
use
the
show
of
hands
tool.
I
think
there
is
a
question
that
I
would
like
to
pose
to
people
in
this
room
right
now
about
this
sort
of
this
composition.
Decomposition
component,
I'm
not
sure
the
word
of
it
but
like
this
document
that
we
started
talking
about,
is
a
gap
analysis.
A
You
made
a
really
good
point
earlier
that
I
you
know,
I
think,
with
both
my
hats
on
agree
with
that.
Panergy
is
an
excellent
venue
to
get
the
kind
of
feedback
to
hone
that
analysis,
and
I
I
think
the
question
that
I
want
to
ask
then
is
do
the.
Does
the
research
group
believe
that
that
is
a
useful
thing
to
work
on
in
the
rg
and
a
useful
product
of
the
rg
and
yeah?
So,
oh
okay,
I
dismissed
it,
but
I
didn't
end
the
session.
So
I've
already
started
it.
A
B
A
Yeah,
I
would
suggest
start
thinking
about
it
and,
like
we
have
a
long
tradition
of
like
zero
zero
documents.
Being
you
know
very
much
works
in
progress,
and-
and
I
I
would
see
this
as
something
where
the
collaboration
would
continue
within
within
the
research
group.
So
it's
okay.
If
what
you
have
is
a
starting
point
with
you
know
to
do
scribbled
on
it
and
you
know
we
can.
We
can
discuss
from
there
in
philadelphia.
F
A
D
D
D
Maybe
it
will
be
a
bunch
of
discussions
and
then,
based
on
that
discussions,
we
we
refine
the
idea
of
how
the
work
should
be
approached
and
then
come
up
with
a
different
plan
for
sort
of
concrete
documents,
some
of
which
maybe
goes
to
the
ietf,
some
of
which
comes
into
this
research
group
or
whatever.
So
I
can
read
it
more
as
understanding
that
the
problem
space
rather
than
necessarily
writing
a
document
ready
for
publication.
A
No,
I
I
like
that
just
that
that
so
like
I
would
say,
then
the
the
I'll
go
with
what
colin
said
not
necessary
to
have
a
document
before
philadelphia.
Please
do
come
to
philadelphia
prepared
to
talk
about
those
questions,
because
I
think
we'll
we'll
definitely
put
some
time
on
the
agenda.
To
dig
into
that.
Does
that
does
that
sound,
reasonable,
slash
makes
sense
green
at
all.
A
B
F
A
Definitely,
you
know
bring
really,
you
know,
bring
people
ready
to
have
a
discussion,
whether
those
people
are
on
site
or
not,
is
less
important
because
there
will
be.
You
know,
it'll
be
a
hybrid
meeting,
definitely
yeah,
I'm
planning
on
attending
the
meeting,
I'm
planning
on
co-chairing
the
meeting,
I'm
not
currently
planning
on
being
in
philadelphia
as
a
case
in
point
so
yeah,
and
then,
if
there's
enough
there,
it
makes
sense
to
put
it
into
a
dock,
put
it
out
of
the
dock,
but
the
main
directive.
A
What
does
it
look
like
if
we
decompose
this?
What
are
the
the
implications?
If
we
do
just
one
thing,
what
are
the
existing
protocols
that
we
could
conceivably
adapt
or
evolve?
What
are
the
barriers
to
that?
I
think
you
might
find
in
some
cases
like
yeah.
This
is
not
perfect,
but
it's
it's
okay,
enough
that
if
it
gets
us
over
having
to
switch
the
entire
world
over
to
a
new
system
at
once,
it
reduces
you
know.
A
One
reduces
the
the
barriers
to
adoption
the
itf,
but
I
think,
what's
more
important
is
reducing
the
barriers
to
adoption
of
the
technology
right
like
so.
You
know
if
it's
easier
to
deploy
because
it's
like
hey,
it
looks
like
something
that
we
already
have
experience
with.
That
is
that's
a
huge
win
right.
A
J
Yeah,
I
think
I'm
not
saying
anything
new,
but
I
just
wanted
to
underline
this
point
that
a
draft
doesn't
have
to
be
like
a
final
paper
or
whatever
it's
just
like
writing
down
information
that
people
need
for
the
discussion.
So
it
can
be
useful
to
have
something
written
down
that
people
can
read
before
the
meeting
and
can
prepare,
but
it
doesn't
have
to
be
perfect
and
it
doesn't
have
to
be
complete
or
anything
like
that.
So
yeah.
D
A
A
A
What
are
the
possible
if
less
than
optimal
parts
of
the
current
internet
architecture
and
the
internet
protocol
stack
that
could
be
adapted
to
replace
the
missing
components
of
the
scion
system?
If
you
only
deployed
one
or
two
of
them,
I
think
you
know
that's
a
fair
amount
of
work
and
I
would
say
that
the
action
item
is
come
prepared
to
start
that
discussion
at
ietf
114..
A
I
also
heard
an
action
item
for
the
chairs
to
schedule
significant
time
for
this
discussion
at
panergy
in
ietf
114,
and
also
be
prepared
to
schedule
additional
interim
meetings,
because
you
know
I
I
do
want
to
have
some
time
on
the
agenda
for
call
for
open
topics
at
the
you
know.
At
the
ietf
meeting
but
like
interims
are
cheap
right
and
I
think
we
we
found
today.
A
This
was
a
very
productive
interim
and
I
think
that
we
can,
especially
if
we
like,
have
parts
of
this
discussion
sort
of
in
the
wider
audience.
Like
the
you
know
today,
there
were
like
34
people
peak
in
the
room.
There's
usually
like
I
mean
in
the
pandemic
times
there
were
80
to
90
coming
into
the
top
energy
in
person
well
pre-pandemic
times
the
and
I
think,
a
model
where
we
basically
are
sort
of
like
exposing.
A
What's
coming
out
of
that
discussion
there
and
then
like
continuing
it
in
interims,
could
work
quite
well,
so
we'll
figure
out
what
interim
schedule
makes
the
most
sense.
We
want
to
do
one
or
two
between
the
itfs,
but
I
think
that
we'll
we'll
do
nothing
in
terms
of
scheduling
an
interim
before
before
114
and
then
prepare
to
sort
of
like
continue.
The
discussion
between
philadelphia
and
london
does
that.
A
A
D
B
B
A
Yeah,
let's
like
leave
it
for
now.
I
think
that
you
know
we
can
take
discussion
points
on
the
list
or
any
feedback
for
updating
it
like
I.
I
think
it
actually
does
make
sense
as
a
a
draft
like
an
individual
draft
targeted
at
pan
rg
right
now,
like
with
you,
know
the
draft
decade
or
pan
rg,
it
shows
up
in
pan
rg's
document
list
as
a
targeted
document.
A
A
Okay.
So,
yes,
absolutely
I
will
hopefully,
tomorrow
possibly
monday,
send
out
minutes
for
the
meeting.
I
have
collections
of
of
notes
that
I
took
and
we'll
post
those
to
the
list
as
well
and
also
to
to
karen
nicola
and
all
you
know,
scion
folks,
you
know
it's
it's
not
that
we're
expecting
sort
of
like
a
fully
formed
presentation
and
idea
to
appear
at
the
philadelphia
meeting
if
there's
anything
that
you're
working
on
that
you
have
questions
on
or
need
or
want
feedback
on.
D
A
All
right,
thank
you,
additionally
to
all
of
the
participants.
This
was
a,
I
don't
wanna
say
a
surprisingly
productive
meeting.
I
I
but
I
I
will
say
I
think
we
got
farther
into
a
better
place
than
I
was
hoping
to
get
today.
So
thank
you
very
much
for
the
discussion.
I
think
we
got
like
a
really
good
sort
of
like
strong
signal
on
what
to
do
next
and
let's
get
to
work
thanks
a
lot
everyone-
and
I
will
see
you
in
not
philadelphia-
have
a
great
day.