►
From YouTube: IETF110-PANRG-20210311-1430
Description
PANRG meeting session at IETF110
2021/03/11 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
You
you
are
indeed
sending
video
if
you
mean
to
send
video,
that's
cool,
but
generally
we
keep
this
off
issues
until
all
right.
B
B
This
is
a
note
well,
which
I
guess
most
of
us
most
of
you
have
seen
already,
but
you,
if
you
have
not,
please
take
a
look
and
by
the
way
the
agenda
should
have
links
to
all
the
slides.
So
you
can
click
on
those
links
instead
of
looking
in
my
shared
screen,
because
I
think
it
might
be
too
small,
so
yeah
brian
kindly
agreed
to
keep
an
eye
on
the
chat.
B
I'll
and
jabber
room
should
be
bridged
there.
So
we
should
be
good
here.
So
here
is
our
agenda.
I
think
we'll
start
with
some
research
group
business
when
brian
and
spencer
will
give
us
some
updates
on
the
drafts
which
we
are
still
trying
to
publish
and
then
we'll
talk
about
past
properties
and
then
we'll
talk
a
bit
about
security
and
trust
relationships,
and
they
have
a
few
drops
of
interest
here.
So
any
last
minute
agenda
bashing.
Any
suggestions
did
I
miss.
A
A
So,
since
the
last
time
we
met
those
of
you
have
been
following,
the
list
have
seen
that
we
put
out
a
refw,
sent
the
document
up
to
the
irsg
for
review
and
put
out
a
revision
to
address
some
of
the
comments
that
we
got
during
that
review.
One
of
the
so
after
that
came
in
we
got
a
a
a
good
question
from
adrian
farrell,
which
started
some
conversation
on
the
list
about
okay.
A
Well,
we
have
this
kind
of
fuzzy
idea
about
what
you
know
path
of
where
networking
is,
but
we
haven't
really
defined
path
and
we'd,
already
kind
of
had
this
problem
a
little
bit
with
the
questions
draft,
which
we
will
speak
about
shortly
and
how
we
should
you
know,
fix
that.
You
know
sort
of
like
the
priority
inversion
with
respect
to.
How
can
you
talk
about
what
pathway
we're
networking
is?
If
you
don't
know
what
a
path
is.
I'd
actually
like
to
take
the
rest
of
this.
A
I'm
gonna
be
sort
of
quick
here,
so
we
can
start
early
and
take
the
rest
of
this
to
the
conversation
after
the
path
properties
draft.
So
with
no
hats
on
other
than
the
editor
of
this
document,
I
would
say
the
inversion
is
okay,
because
questions
is
supposed
to
be
questions
right
like
and
what
is
a
path?
A
That's
a
perfectly
reasonable
question,
however,
if
we
think
that
there's
sort
of
like
a
a
a
semantic
issue
with
trying
to
define
the
questions
without
defining
the
terminology
for
those
questions,
I
think
the
right
place
to
address
that
is
in
the
discussion
on
the
path
properties
draft.
A
So
that's
where
we
are
in
questions.
I'd
like
to
have
a
little
bit
of
that
conversation
today.
Take
it
to
the
list.
Take
the
outcome
of
that
conversation
turn
it
into
a
an
updated
version
of
the
questions
draft
to
send
out
for
sort
of
another
round
of
discussion,
and
then
we
can
get
it
published.
A
So
if
anyone
has
any
particular
questions
or
points
to
make
about
that
plan,
we
should
discuss
that
now.
Otherwise
I'd
say
we
follow
that
plan
and
use
sort
of
the
remainder
of
my
time
after
the
path
properties
discussion
to
discuss
sort
of
like
next
steps
with
the
what
is
a
path
question.
C
Yeah,
thank
you.
Thank
you
jen.
So
I'm
I'm
doing
the
yeah
just
about
that
fast
doing
the
update
on
what,
where
path,
where
pan,
not
what
not
to
do,
has
been
since
it
left
the
research
group
next
slide.
Please,
we've
actually
been
kind
of
busy
we've
gotten
comments,
and
these
have
been
not.
C
Most
of
these
have
been
non-blocking
comments,
like
especially
the
ones
from
the
isg
and
things
like
that
on
that
where
we
did
dash
17
and
all
of
this
stuff
has
been
on
the
mailing
list
previously,
but
the
ecn
stuff
is
just
was
just
submitted
this
past
monday.
C
I
posted
texts
previously,
but
but
it's
good
for
it's
good
for
the
research
group
to
see
what
I'm
actually
saying
so
next
slide.
Please.
C
So
martin
said
why
not
ecn
during
the
ietf
isg
conflict
review,
and
you
know
the
the
easy
answer
was
nobody
contributed
a
section
on
ecn,
but
that
seemed
kind
of
lame.
C
We
aren't
actually
covering
everything,
but
we
wanted
to
cover
all
the
lessons
and
after
I
talked
with
brian
a
bit
ecn
did
actually
have
lessons
learned
that
weren't
covered
elsewhere,
so
I
wrote
a
section
on
ecn
and
updated
the
lessons
learned
in
the
draft,
and
I
want
to
do
a
shout
out
to
sally
floyd's,
ecn
page,
which
was
still
active
and
very
helpful.
So
I,
like,
I
say,
submitted
dash
18
on
monday
with
the
text
that
I
had
said
to
the
melee
list
previously
and
next
slide.
Please
so.
C
Yeah,
so
so
what
was?
What
was
different
about
acn
was
that
these
guys
did
a
lot
so
much
right.
The
lessons
from
our
doc,
which
hadn't
been
written
yet
thinking
about
incremental
deployment
and
impact
on
router,
throughput
and
trust
issues
between
the
node
and
the
network,
but
they
didn't
anticipate
that
routers
would
flat
out
crash
when
you
said
non-zero
ecm
bits
so-
and
this
was
actually
a
want
to
do
a
shout
out
to
dave
thaler
and
his
team
at
microsoft.
C
They
did
a
presentation
which
is
reference
to
the
draft
about
this,
and
basically
said
you
know
like
this-
is
one
of
the
more
duh
comments
I've
seen
at
itf.
They
said
if
you
crash
the
router,
you
can't
recover
that
at
the
tcp
layer,
so
they
turn
they.
Ship
vista
with
ecn
turned
off,
because
the
router
that
was
crashing
was
a
popular
model
from
a
popular
router
vendor
and
once
you've
turned
it
off.
C
You
really
don't
have
much
incentive
to
turn
it
back
on
and
that
log
jam
can
persist
for
a
decade
or
two
people
are
starting
to
turn
the
ecn
back
on
now,
but
I
mean
this
is
from
you
know
like
10
or
15
years
later,
so
the
the
lesson
learned
that
I
took
away
from
that
experience
was
sometimes
you
get
one
chance
to
get
it
right
next
slide.
Please.
C
C
A
So
yeah
as
an
individual,
I
I
have
looked
at
this
text.
I
I
think
it's
good,
I
would
say
I
would
make
like
a
tiny
little
knit
here
is
like.
Is
there
a
better
way
to
describe
dcm
lesson
than
one
chance
it?
Well
I
mean
it
wasn't
one
chance
we're
doing
it
again.
It's
possibly
one
chance.
Every
two
decades.
A
Right
like
so
there
are,
there
might
be
something
to
say
about
sort
of
like
equipment
replacement
cycles
like
if
you
have
to.
If
you
have
to
forklift
hardware,
it's
gonna
slow,
you
down,
but
that's
like
a
minor,
would
be
a
minor
point
to
make
there.
I
think
the
one
chance
is
a
good
characterization
of
it
but
yeah.
I
think
this
is
a
good
plan
forward
again
with
my
without
my
hat
on.
C
D
How
many
buttons
can
I
press
at
once?
Well,
does
that
work?
Now?
Yes,
oh
except
it
says
arrow
video
closed,
which
is
really
cool.
However,
you
don't
need
to
see
me
so
it's
great
spencer
I'd
have
an
opportunity
to
say
I
haven't
read
your
text,
but
I
still
have
an
opinion.
D
Okay,
but
but
it's
the
same
as
as
brian's
we
re.
I
think
we
need
to
be
really
careful
to
say
it's
one
chance
per
equipment
lifetime
and
really
call
that
out,
because
otherwise
it
sounds
like
you're
talking
about
a
dead
experiment,
because
if
we
talked
about
st
st2
we
would
say
no
it's
gone
forever,
whereas
for
this
it's
not
really
gone
forever
and
the
bug
came
because
somebody
read
the
toss
bite
from
a
speck
which
was
10
years
old
when
they
did
their
device,
so
they
they
were
from
a
previous
generation.
D
They
put
the
bug
in
theirs.
It
lasted
for
a
generation,
yeah
there's
something
about
generations
here,
and
I
will
read
it
and
give
you
some
proper
comments.
No
problem.
F
Okay,
I'm
here
yeah,
so
thanks
spencer,
for
taking
my
late
comments,
I
I
wouldn't
disagree
at
all
with
a
character
with
the
like
accuracy
of
the
one
chance
and
one
chance
per
equipment
cycle
or
whatever
it
is
that
people
want
to
put
here.
I
could
my
complaint
is
a
little
more
meta
than
that,
and
then
I
I
don't
understand
how
this
is
actionable
to
protocol
designers.
F
I
mean:
does
this
just
increase
their
stress
level,
because
if
they
screw
up
like
they're
doomed
or
is
there
something
you
can
actually
do,
and
I
I
think
we
talked
about
this
a
little
bit
on
the
thread,
and
you
know
I
wasn't
there.
So
I
can't
comment
if
there's
something
they
could
have
done
to
avoid
this
router
crashing
problem,
and
I
think
the
immediate
feedback
I
got
last
time
I
checked
was
that
no
there
was
nothing
they
could
have
done.
C
If
I
was
going
to
try
to
wordsmith
this
on
the
call
on
the
teleconference,
which
I
would
not
recommend,
I
would,
I
would
probably
be
thinking
in
terms
of
something
like
a
broadening.
You
know,
you
know
basically
think
outside
the
box
on
the
tests
that
you
run,
because
you
know
they
test.
They
tested
this
stuff,
just
obviously
not
with
that
router,
and
so
things
got
awkward
when
that
router
was
in
the
path.
C
G
It
is
colin,
yes,
can
you
hear
me?
I
can
hear
you
yes,
so
thank
you
for
doing
the
update
on
the
the
point
of
view
of
sort
of
release
cycles,
and
so
on
I
mean
I
think,
the
comments
about
once
per
equipment
life
cycle
makes
sense.
I'm
wondering
if
there's
something
which
can
be
something
that
can
be
said
about
structured
approaches
to
testing,
because
certainly
when
people
came
to
to
trying
to
deploy
ecn
again
for
the
second
time.
G
My
impression
is
that,
and
I
guess
it
was
apple
that
were
pushing
it.
They
they
followed
quite
a
careful
approach
to
to
to
pushing
out
this
in
an
incremental
way
in
small
numbers
of
devices,
whilst
also
working
with
the
operators
to
to
address
problems,
and
this
may
be
lessons
that
can
be
learned
from
that.
C
I
I
think
that
I
think
that
I
think
that's
a
good.
I
think
that's
a
good,
I
think
that's
a
really
helpful
observation,
just
just
the
thing
where
even
being
able
to
roll
operating
system
revisions,
you
know
which,
which
happens.
C
You
know
like
every
quarter
of
these
days
on
a
lot
of
hosts,
rather
than
every
equipment
cycle
on
a
lot
of
hosts
when
when
ecm
was
deployed
the
first
time,
but
I
think
that's,
I
think,
that's
a.
I
think,
that's
very
a
very
helpful
suggestion
to
think
about
what
what's
changed
since
we,
you
know,
since
evcn
always
tried
to
was
attempted
to
be
deployed
the
first
time.
Thank
you,
colin.
G
Thank
you,
and
just
in
in
terms
of
the
comments
you
know
for
final
final
approval
and
so
on.
As
soon
as
the
research
group's
happy,
I'm
sure
I
will
be
happy.
C
C
A
Think
we're
gonna
close
the
line
after
jake
now,
so
I
love
talking
about
ecn
as
much
as
the
next
person,
but
we
do
have
to
get
to
the
rest
of
the.
H
To
martin's
comment,
I
think
there
is
something
that's
actually
actionable
that
we
could
include
here,
which
is
and-
and
you
know
I
agree
with
a
lot
of
things-
about
doing
it
incrementally
and
and
working
with
operators
and
making
sure
that
we
can
measure
as
we
go
and
those
are
all
good
things,
but
at
the
end
of
the
day,
having
a
at
least
where
possible,
having
a
fallback
strategy
or
some
way
to
ensure
that
the
end
user
pain
is
mitigated
in
the
event
of
a
problem
likely
in
this,
and
many
other
cases
ends
up
being
the
key
to
whether
we
end
up
turning
something
off
versus
being
able
to
keep
it
on.
H
While
things
are
being
fixed
and
so
had
we
now
that
we
know
that
there
were
a
lot
of
problems,
we
have
all
sorts
of
interesting
strategies
and
heuristics
that
we
can
use
to
say
this
looks
like
a
place
where
somebody
blows
up
when
we
use
ecn,
but
you
know
pick
anything
that
we're
doing,
which
is
part
of
why
we
have
this
document
and-
and
we
can
do
things
to
try
to
either
detect
in
the
moment
or
or
remotely
disable.
H
It
or
or
handle
that
that
sort
of
a
situation,
and
so
it's
great
to
measure
it's
great
to
be
able
to
coordinate
with
people.
But
fundamentally,
if
we
measure-
and
we
discover
that,
there's
a
big
problem-
we
still
end
up
in
the
same
bad
bad
place.
So
if,
if
we
measure
and
we
detect
that,
there's
a
problem
and
we
are
able
to
prevent
that
problem
from
causing
users
lots
of
pain,
then
we
can
end
up
in
a
much
better
place.
H
So
that
might
be
an
actionable
thing
that
we
could
put
as
other
than
a
don't
screw
up.
Your
protocol
is
like
kind
of
hard,
but
you
know
think
about
the
failure,
mode
and
design
a
way
to
remove
the
user
pain
from
that
failure.
Mode
might
allow
things
to
be
much
more
deployable
cool.
Thank
you.
So
much.
I
Hello
hi
chris
hi
kareem
yeah
hi.
I
just
want
to
echo
some
of
the
comments
that
we
heard
one
is
you
know
I
like
what
eric
just
said
in
terms
of
not
just
tests
but
have
a
plan
b
have
a
fallback
plan,
but
I
I
actually
want
to
come.
Go
back
to
colin's
comment
and
and
your
response
to
it,
which
I
liked,
which
is
the
generation.
I
You
know
that
whole
thing
that
someone
said
you
know
is
this:
to
increase.
Stress
generations
are
reducing
the
length
of
a
generation,
because
you
know,
if
you
have
microcode
you
can
you
can
fix
things
a
lot
quicker.
If,
if
people
are
updating
os's
quicker,
then
you
can
fix
things
quicker.
So
the
fact
that
it's
a
generation
doesn't
mean
it's
a
you
know:
it's
not
10
years
anymore.
It's
not.
I
You
know
that
long,
so
not
to
take
anything
away
from
what
you're
saying
here
that
we
should
be
careful
and
in
many
cases
it
is
one
chance.
The
problem,
the
main
thing
with
the
one
chance
is
not
the
generation
as
much
as
the
the
taste
left
in
your
mouth.
If
something
goes
strong
and
so
your
reluctance
to
retry
it,
and
so
we
really
have
to-
and
that's
why
I
appreciate
eric's
comment,
because
if
you
reduce
the
bad
taste
from
an
experiment
that
goes
wrong,
then
people
will
be
more
likely
to
retry
it.
I
J
Jake
yeah
hi
spencer,
thanks
the
there's
one
I
I
agree.
The
protocol
designers
did
a
good
job,
but
there's
one
thing
I
really
think
would
have
been
better,
which
is
if
ect1
was
nect,
so
they
went
ahead
and
defined
it
with
that
and
and
gave
it
a
meaning
without
without
making
it
different
than
the
one
that's
there,
and
this
has
caused
trouble.
That's
still
unfolding
today.
J
J
C
Cool,
thank
you
jake,
so
I
can
I
I
have
some
comments
now.
If
people
have
other
comments,
you
have
two
weeks
not
counting
this
week
to
send
them
in
and
then
I
will
submit
that
copy
the
research
group
and
let
colin
do
the
right
thing
if
that
works,
for
people
and
and
thank
you
all
for
your
input
next.
B
L
L
So
we
have
published
two
revisions
and
one
was
basically
just
addressing
some
minor
feedback
points,
and
now
the
most
recent
revision
sort
of
speaks
more
generally
to
the
purpose
of
this
draft,
because
there
was
a
lot
of
discussion
on
terminology
in
both
the
questions
and
the
what
not
to
do
draft
during
the
sort
of
way
to
publication,
and
so
we
were
thinking
that,
yes,
we
need
a
generic
terminology,
I
mean
we
know
that
that's
what
the
path
properties
draft
is
for,
and
our
hope
is
that
this
terminology
in
a
draft
can
be
useful
for
pan
rg
to
use
in
the
other
draft
and
to
discuss
path,
awareness
and
pathway,
networking
in
general
and
then
the
the.
L
What
not
to
do
draft
right
has
a
lot
of
specific
terminology,
so
we
were
thinking.
Okay,
we
have
a
generic
terminology,
and
now
a
specific
technology
would
consider
specific
path
elements.
So
right
we
define
a
sort
of
an
abstract
or
a
general
path
element,
but
then
a
specific
terminology
would
say:
okay,
we
are
talking
about
ip
routers
and
have
their
own
definition
of
path
element,
and
then
they
would
sort
of
make
their
own
definition
of
a
path
and
define
what
path
properties
they
consider
and
also
what
they
can
do
about
their
path
right.
L
So
we
hope
that
our
terminology
is
already
sort
of
generic
enough
to
cover
those
relevant
concepts
and
to
be
potentially
applicable
to
path
aware
technologies
that
we
talk
about
in
panagio,
which
includes
past
present
and
future
technologies,
but
yeah.
I
wanted
to
know
if
people
think
that
our
terminology
is
already
there
or
if
there's
anything,
that
you
are
still
missing,
and
that
is
my
first
question
and
then
I
have
one
more
slide.
L
So,
in
addition
to
that
generic
terminology
that
the
path
properties
draft
provides,
it
also
has
a
use
cases
section
and
an
example
section,
and
so
here
we
thought
okay,
so
we
have
a
definition
of
paths
and
path,
awareness
and
now
it
would
be
good
to
have
some
motivation
of
why
somebody
would
even
care
about
path
properties,
and
that
is
part
of
why
the
use
cases
section
exists
right.
So
we
would.
L
We
have
three
use
cases,
a
path,
selection,
protocol
selection
and
service
invocation,
and
we
think
all
those
use
cases
are
generic
as
well,
but
then
a
specific
technology
again
would
sort
of
have
their
own
flavor
of
path.
Selection
right
it
can
consider
different
path
elements.
Maybe
it
selects
between
different
routers
that
it
knows
about.
L
Maybe
it
selects
between
different
networks
that
it
knows
about,
and
and
then
this
principle,
this
use
case
of
path,
selection
would
sort
of
apply
to
specific,
different
terminologies
and
it's
useful
to
explain
the
general
concept,
and
so
that
is
the
use
cases
section,
and
then
we
also
have
examples
of
path
properties,
and
here
again
we
have
okay.
This
time,
I
guess
the
examples
are
rather
specific.
L
A
Hi
teresa,
how
you
doing
you'll
know
no
hat.
This
is
the
chair
hat
it's
over
here,
so
I
I
as
a
non-exhaustive
list.
I
like
this
as
a
starting
point.
It's
it's
up
sets
the
use
cases
up
into
pretty
broad
categories.
The
one
nit
that
I
would
have
is
that
we
should
probably
be
pretty
clear
that
service
invocation
in
this
case
refers
to
service,
as
defined
in
sort
of
like
the
service
function,
chaining
context
and
not
with
respect
to
sort
of
like
endpoint
services.
A
A
That's
going
to
steer
to
a
different
back
end
based
on
the
the
properties,
the
path
on
the
other
side,
and
that
would
be
a
different
kind
of
service
indication
and
the
kind
of
service
indication
that
you
mean
and
the
kind
of
service
invocation
that
you
mean
is
actually
more
important
for
the
the
the
pan
rg
context.
So
it'd
be
a
little
bit
more
yeah.
A
That's
the
problem
with
this
whole
document
is
that
every
word
we
want
to
use
is
already
is
already
contextually
overloaded
back
to
the
the
previous
question,
I
think
that
this
is
actually
a
good
split
as
well,
by
basically
saying
we're
going
to
try
and
build
the
abstract,
the
abstract
framework,
the
abstract
meta
terminology
as
a
a
way
to
build
the
the
concrete
terminology
on
on
top
of
it.
I
think
this
is
a
a
good
approach,
so
yay
to
all
of
the
changes
up
to
zero.
A
Two
from
me.
L
L
J
Jake
yeah
hi
theresa,
I
just
wanted
to
say
I've
been
meaning
to
write
an
email.
I
will
get
it
out,
there's
a
a
couple
of
examples
that
I
think
are
relevant
to
this
question.
It's
actually
I
I
had
tried
to
do
it
as
a
follow-up
to
michael
wellesle's
request
to
talk
about
sort
of
discovery
of
on-path
stuff.
I
think
there's
a
few
things
that
I've
been
looking
at
that
are
there
in
a
relevant
direction
here.
That
actually
brian's
comment
made
me
think,
I'm
not
quite
sure.
J
If
I'm
talking
about
the
same
thing
that
you're
talking
about,
but
I
I
will
send
that
email,
I
will
get
it
out.
So
look
for
that
within
the
next
couple
of
weeks.
L
Thank
you
and
yeah.
I
also
appreciate
comments
via
email
and
or
we
also
have
a
github.
Maybe
we
should
talk
about
making
it
an
appointed
github.
B
A
I
just
want
to
jump
back
in
the
queue
really
quickly
to
go
back
to
the
questions.
Question
right
like
so
there's
a
there
is
a
a
standing
question
as
to
whether
we
want
questions
to
have
a
normative
forward
reference
to
path
properties
for
the
definition
of
a
path
or
whether
we
want
to
try
and
leave
it
open.
A
A
Does
it
make
sense
in
your
mind,
as
the
editor
of
this
document,
to
maybe
take
all
three
of
these
documents
and
push
them
out
together,
or
should
I,
as
the
editor
of
questions,
try
to
cut
like
you
know,
go
back
to
sort
of
like
the
abbreviated
super
abstract
version
of
path
so
that
we
can
get
them
out
the
door
and
put
them
in,
like
you
know,
a
a
directed
acyclic
graph
of
references.
So
I'd
like
to
get
your
opinion
on
that.
L
Okay,
so
my
initial
reaction
is
that
the
path
properties
draft
answers
the
first
question
from
the
questions
draft.
So
it's
it
feels
kind
of
silly
to
have
a
reference
to
the
answer
draft
as
a
normative
reference,
and
I'm
not
sure
that
it's
actually
needed
to
have
this
kind
of
clear,
rigorous
definition.
I
mean,
I
don't
think
it's
necessary
to
have
the
first
question
already
answered
in
order
to
publish
the
questions
draft.
A
Okay
cool,
so
I
will
take
that
in
an
in
answer
to
adrian
farrell's
email,
which
I'm
now
noticing
was
like
almost
a
month
ago,
so
I
gotta
get
on
that,
but
I
will
take
that
to
the
list.
Thank
you
very
much.
Okay,.
B
C
Yeah,
I
just
wanted
to
say
real
real
quickly
for
the
working
for
the
research
group
that
we
ended
up.
I
we
ended
up
yeah.
I
I
have
a
informative
pointer
to
the
to
the
terminology
draft,
but
I
do
not.
Most
of
the
most
of
the
contributions
were
done
with
a
range
of
definitions
of
what
people
thought.
Path-Aware
networking
was,
or
whatever
it
was.
They
were
doing
at
the
time.
So
that
question
is
not
active
for
that.
C
That
question
is
not
active
for
what
not
to
do
it's
only
only
for
the
research
questions
draft.
Thank
you.
N
K
Hello
hi,
any
anybody
can
hear
me.
B
N
Me
I
have
any
trouble
with.
N
Hello,
everyone-
this
is
john
from
china
mobile,
and
this
draft
is
about
the
required
pass
properties
for
applying
password
networking
in
integrated
space,
racial
networks,
and
maybe
it
can
be
seen
as
an
input
for
teresa
and
hope
it
can
bring
you
some
inspirations.
And
yes,
if
you
go
to
the
next
slide,
please
for
this
slide.
N
It
is
about
the
relationship
between
the
istn
and
the
space
and
the
path
of
world
networking,
and
basically
I
just
list
some
characteristics
of
istn
and
pan,
and
we
can
see
whether
these
characteristics
match
well
and
for
the
first
bullet.
It
is
about
the
limited
resources
and
because
of
the
source
of
the
light
is
the
solar
panel.
N
So
the
power
of
the
satellite
is
always
limited,
and
so
does
the
computing
resources
and
storage
resources,
but
by
taking
advantage
of
the
pa,
and
we
can
leave
the
complicated
calculations,
all
the
selections,
all
these
functions
to
the
endpoint
and
make
the
network
node
as
simple
as
possible
and
for
the
second
and
third
bullet
is
about
the
cross,
administrative,
administrative
domain
and
class
layer,
because
it
is
quite
possible
that
the
isdn
is
a
is
a
clause.
N
The
main
is
creative
domain
and
clause
layers,
while
the
pan
is
very
suitable
for
those
kind
of
networks
and
for
the
first
first
bullet.
It
is
about
the
multipasses
characteristics.
N
Since
both
space
passes
and
terrestrial
passes
can
be
used
to
transmit
traffic
and
appearance
can
just
take
advantage
of
these
features,
so
it
seems
like
the
password
networking
is
suitable
for
istn
and
may
help
to
cope
with
some
challenges
of
the
istn.
And
then,
if
you
go
to
the
next
slide,
we
can
see
take
a
look
about
the
use
cases
and
the
challenges.
N
Yes,
this
is
a
very
brave
picture
about
the
use
cases
and
in
our
understanding,
with
the
development
of
the
space
technologies
and
the
satellite
capabilities
will
be
stronger
and
therefore
the
satellite
can
be
integrated
into
terrestrial
networks
as
a
router
or
as
a
server
and
can
be
seen
as
part
of
the
access
networks
or
car
networks
or
even
a
data
networks.
N
Then
the
use
cases
will
be
more
complicated
than
we
starts.
So
there
are
many
challenges
we
need
to
be
take
care
of.
For
example,
you
need
to
adapt
to
the
time
variant
topologies
due
to
the
mobility
of
satellites,
you
need
to
adapt
to
limited
resources,
as
I
explained
before,
and
you
need
to
adapt
to
virus
link
characteristics,
especially
this.
N
The
space
links
which
may
have
unpredictable
link
failure
and,
moreover,
all
these
links
maybe
well
use
totally
different
protocols,
so
it
seems
like
so
many
things
need
to
be
done
to
handle
these
challenges
and
when
it
comes
to
the
pan,
it
will
have
some
additional
requirements
on
the
path
properties
and
if
you
go
to
the
next
slide,
please.
N
Yes,
here
I
list,
I
list
the
requirements
on
path
properties
in
istn
and,
as
you
can
see,
we
believe
that
the
path
properties
can
have
two
granularities
and
for
the
course
granular
it
may
contain
the
path
properties
and
for
the
fan,
granular
properties.
It
contains
the
node
properties
and
link
properties,
and
some
additional
post
properties
are
dedicated
in
space
networks.
N
Well,
maybe
others
are
common
properties
in
both
terrestrial
networks
and
space
networks,
and
I
due
to
I
because
I
I
only
have
five
minutes,
so
I
won't
go
through
all
those
properties,
but
if
you
have
some
interesting
and-
and
you
can
maybe
find
it
in
a
draft-
and
if
you
go
to
the
next
slide,
please.
N
Yes,
it
is
just
a
brief
summary:
the
integrated
space
racial
networks
can
take
advantage
of
the
pan
and
thereby
can
be
seen
as
a
typical
use
cases
and
when
the
pan
is
applied
into
the
istn,
the
additional
pass
properties
may
have
may
be
required
and
thanks
for
listening,
my
humble
view
and
hope
it
will
be
helpful
and
any
suggestions
are
welcomed.
B
B
B
B
P
Thank
you
jim.
I
guess
you
hear
me
well,
I
think
so.
P
B
P
All
right,
thank
you
very
much
all
right,
so
I'm
juan
garcia
pardo.
I
want
to
have
a.
P
There
we
go
so
yeah,
since
this
is
going
to
be
a
very
short
presentation
on
drk,
so
the
dynamically
recreatable
key
infrastructure,
so
I'm
going
to
try
to
keep
it
in
10
minutes.
So
the
idea,
if
jen,
if
you
can
go
to
the
index,
so
let
me
quickly
just
yeah
yeah,
sorry,
yeah
yeah,
fine!
Thank
you!
P
So
I'm
just
going
to
choose
an
example
very
early,
so
I
think
it
will
be
understood
what
later
or
what
what
drk
can
be
used
for
in
the
context
of
source
authentication
and
later
on,
because
we
want
to
introduce
epic
as
a
path
verification
system
later
on
also
into
the
pan
rg.
We
thought,
let's
give
a.
Let's
give
it
a
spin
first
into
the
r
key,
which
is
like
the
basis
for
epic
all
right.
P
So
the
after
the
the
example,
I'm
just
gonna
talk
the
minimal
about
the
key
hierarchy
in
the
arche
and
then
some
details
about
the
derivation
and
exchange.
So
if
you
go
to
the
next
slide,
please
so
what
is
the
art
key?
P
The
id
is
just
the
practical
for
establishing
an
exchange,
symmetric,
photography,
keys
that
can
be
used
for
authentication
and
any
autonomous
system
that
wants
to
opt-in
to
the
drk
protocol.
They
will
have
at
least
one
key
server.
This
is
just
an
entity
that
understands
the
drk
protocol,
so
vrt
was
designed
with
scale
in
mind
to
scale
with
the
internet,
and
since
we
we
cannot
keep
state
for
every
possible
entity
that
would
like
to
be
authenticated
into
the
internet.
P
The
er
key
doesn't
rely
to
keep
in
state
for
that
much
or
for
that
many
entities.
So
there
is
this
key
tree
that
will
that
we'll
see
later
into
how
that's
used
to
derive
the
next
keys
and
so
on,
the
configuration
granularity
is
up
to
the
autonomous
system
level.
So
once
we
see
the
x,
the
key
exchange
we'll
understand
that
some
key
servers
can
deny
requests
to
whole
autonomous
system
entities
over
there.
Next
slide,
please
all
right.
P
So
I
have
to
introduce
these
key
levels
already,
because
otherwise
the
example
will
not
be
understood.
There
are
three
levels:
key
levels
levels
here,
one
and
two.
The
level
series
also
called
the
secret
value.
There
is
just
a
key
that
is
originated
into
one
yes
and
the
owner
of
that
key
and
is
always
kept
in
secret
inside
that
key
server.
That
is
the
key
used
to
derive
the
level
one
keys.
Those
are
the
as2aes
keys
that
could
have
logged
the
protocol.
P
In
this
context.
Protocol
is
just
the
purpose
of
that
key,
so,
for
instance,
to
authenticate
dns
request
packets.
Let's
say
this
is
just
a
string,
a
string
of
bytes
and
then
the
level
two
key
is
derived
using
the
level.
One
key
we'll
see
the
details
in
the
variation
very
quickly
and
then
is
that's
the
actual
key
that
is
used
to
tag
the
packet,
so
you
can
do
the
maximum
on
those
packets,
so
every
key
has
a
validity
period
that
is
inherited
from
the
previous
level
and
the
level
zero
is.
P
The
first
is
the
actual
level
that
establishes
the
validity,
and
then
every
entity
that
is
part
of
the
communication
will
derive
that
key
in
either
one
one
of
two
ways,
so
the
owners
of
the
key
can
derive
it
in
nanoseconds
and
any
other
entity
which
is
not
the
owner
of
the
key
s
will
have
to
obtain
the
key
via
their
key
sir,
and
they
will
see
how
that
actually
works
also
very
quickly.
Next
slide,
please.
P
So
this
is
just
the
just
a
picture
to
to
remind
that.
The
level
zero
key
never
leaves
the
key
server
and
we're
seeing
the
same
time
the
same
the
same
key.
P
So
this
is
the
little
zero
one
and
two
keys
for
the
same
key
and
then
the
level
one
key
leaves
in
both
key
servers,
because
that
is
the
one
that
is
exchanged
the
level
two
key
is
the
actual
key
that
is
used
to
authenticate
next
slide
this
so
as
an
example,
we're
going
to
have
a
dns
server
that
wants
to
authenticate
every
packet
that
receives
from
end
host
squaring
it,
and
then
this
this
server
is
going
to
be
trusted
by
the
key
server
for
certain
protocols.
P
Certain
users,
I
just
called
it
dns
it
could
have
been
dns
source
authenticated.
Whatever
is
this
a
string
that
we
have
agreed
upon
and
then,
if
you
go
to
the
next
slide,
we'll
see
the
sequence
of
events
that
are
listed
over
there
this
yesterday
very
quickly,
so
we
have
yeah,
we
have
just
the
sequence
on
as
a
blue.
On
the
left
side,
we
have
the
dns
server.
P
That
is
our
guide
that
actually
requests
to
get
the
level
one
key
to
the
key
server,
because
the
key
server
has
configuration
saying
that
that
end
host
in
particular
is
authorized
to
get
that
key.
They
return
that
key
to
it,
then,
on
the
right
hand,
side
we
see
green
the
end
host
at
p.
That
makes
that
wants
actually
to
communicate
with
the
dns
server
and
then
for
that
they
need
to
get
the
level
two
key
to
talk
to
that
end
host
in
particular,
so
they
will,
they
will
ask
their
key
server.
P
Please
give
me
that
level
two
key
for
me,
because
they
actually
cannot
get
it
and
then
the
key
server
checks
if
they
have
the
level
one
key
for
that
other
as
they
do
in
this
case.
We'll
have
another
example
where
they
don't,
but
this
one
they
do
and
they
they
can
quickly
derive
the
level
two
key
which
is
returned
to
the
end
host,
then
that
end
host
from
that
moment
on
can
start
using
that
level.
P
Two
key
using
symmetric,
photography
or
just
computing-
the
mac,
for
instance,
to
start
creating
tags
for
their
packets,
which
arrive
at
the
dns
server,
and
they
know
that
that
packet
came
from
the
asb
and
host
whatever
in
the
host.
This
is,
and
so
they
can
quickly
derive
the
level
2
key
on
the
fly
and
they
can
validate
that
attack.
We'll
see
concrete
examples,
maybe
later,
if
there
is
time
next
slide,
please
I'm
sorry.
P
I
have
to
rush
a
bit
because
otherwise
all
right,
so
this
is
just
a
recap
for
for
later,
for
the
for
the
record,
what
we
just
stopped.
I
don't
think
that
we
have
to
go
through
everything
the
that
we
just
said
it's
just
that
the
key
points
here
is
the
level
two
key
is
the
important
key:
that's
the
key
that
is
used
to
actually
authenticate
the
packets.
P
The
protocol
can
be
locked
already
in
level
zero,
but
if
it's
not
locked
in
level
two,
it
has
to
be
locked
in
level
one
or
level
two.
So
there
is
always
a
protocol
locked
at
the
very
end
at
the
very
last,
the
very
least,
sorry
at
level.
Two
next
slide,
please
all
right!
So
again,
let's
just
look
at
the
last
paragraph,
so
the
key,
the
key,
not
the
key,
the
important
part
is,
is
that
the
level
two
key
has
to
be
obtained
by
both
parts
of
the
communication.
P
So
there
is
a
fast
side
which
is
the
owner
of
the
key
that
can
derive
that
level
two
key
very
quickly,
and
they
don't
need
to
do
anything
special.
They
just
need
to
know
which
is
who
is
the
other,
the
other
guy
in
the
communication,
while
the
slow
side,
which
is
not
the
owner
of
the
key,
they
cannot
derive
it
very
quickly.
P
So
the
communication,
so
the
packet
flow,
it
can
go
both
ways
from
hp
or
b2a,
but
this
low
side
will
have
to
get
the
level
2
key
beforehand
or
if
they
receive
a
packet
that
they
don't
have
it,
they
have
to
kill
that
packet
to
be
source
authenticated
later.
This
is
symmetry.
Well,
it's
kind
of
important.
Isn't
it
all
right?
P
So
if
we
go
to
next
slide
and
then
I
will
just
conclude
with
the
with
the
key
derivation
all
right,
so
the
the
key
derivation,
the
two
key
derivation
functions
or
flares,
the
first
one
is
to
derive
the
level
0
key,
that's
the
slow
one,
but
since
we
only
do
it
once
per
valid
per
period,
the
key
period
or
key
validity
period,
that's
not
so
important.
P
We're
using
the
password-based
key
derivation
function,
2
with
a
thousand
iterations
of
sha
256,
and
that
is
only
that's
done
only
once
again
and
done
only
in
the
key
server
of
database
and
then
the
level
one
and
level
two
keys
are
using
a
much
faster.
Pseudorandom
function
is
aes
sc
mac.
This
the
details
are
explained
later
also
in
the
in
the
slides
and
the
paper
zone.
P
P
The
last
point
is
just
the
clarification,
the
nomenclature,
which
sometimes
could
be
difficult
to
read,
so
that
key
proto
x2y
means
that
there
is
a
dr
key,
which
is
locking
the
protocol
proto
and
has
a
fast
side
or
owner
of
the
key
x,
and
the
other
side
is
y
and
x
and
y
can
be
a
yeses
or
n
hosts,
depending
on
whether
we
are
talking
about
the
level
one
or
level
two
keys.
If
we
go
to
the
next
slide,.
P
Yeah
the
level
one
keys,
so
the
as2as
keys
are
the
ones
that
are
propagated
to
the
to
the
other
key
servers
and
we'll
see
an
example
of
the
of
the
propagation
of
the
exchange.
P
So
since
the
communication
has
to
be
designed
and
encrypted
in
the
case
of,
for
instance,
scion
design
architecture
we're
using
the
control
plane
tki
in
the
current
id
internet,
we
could
use
rpki.
For
instance,
this
there's
configuration
the
key
servers
that
could
deny,
as
we
had
said
before,
up
to
the
to
the
aes
granularity
level
level.
One
key
requests,
and
that
could
also
happen
for
level
two
key
request
within
the
is.
P
If
there
is
the
possibility
of
locking
this,
we
have
set
the
protocol
or
reading
the
secret
value
that
that
allows
the
fast
side
not
to
not
to
have
prefetch
the
level
one
key
for
the
other
side
as
well,
all
right.
So
just
if
we
can
go
to
the
next
slide,
please.
P
This
is
just
my
last
slide
all
right,
so
we
have
in
the
middle
in
blue,
the
asa,
which
is
the
key
server
that
that
wants
to
propagate
or
the
key
that
wants
to
be
transmitted
to
the
other
key
servers.
So
we
have.
The
first
thing
is
in
the
key
server
b
wants
to
prefetch
that
level.
One
key
makes
a
request,
a
key
server,
a
checks
it
and
then
returns.
P
The
key
of
course,
no
problem
and
then
later
on,
the
an
end
host
in
the
asa
wants
to
obtain
the
level
two
key,
as
we
have
seen
in
the
dns
server
example.
And
then
in
this
case
the
key
server
doesn't
have
the
l1
key,
which
is
requested
to
the
key
server
at
a
but
the
permission
to
the
as
is
not
granted,
and
that
key
server
c
is
just
answering.
There
was
a
denial
of
that
key
and
the
indian
host
doesn't
get
done
all
right.
P
So
if
we
have,
if
we
go
to
the
last
question,
sorry
last
last
live
or
questions.
Also.
If
anyone
is
interested
in
this
presentation,
the
next
slides
we
have
references
and
backup
slides
because
yeah.
Thank
you.
B
Yeah,
thank
you
very
much
quan,
I'm
just
afraid,
because
you
are
running
over
time
and
we'd
like
to
have
two
more
presentations.
I
suggest
yes,
so
we
bring
the
discussion
to
the
mailing
list
thanks
a
lot
spencer,
I'm
getting
your
slice
in
a.
B
M
B
Okay,
my
computer
okay,
here
we
are.
C
Okay
cool,
so
my
my
computer
just
did
something,
but
it
stopped
now.
It
looks
like
so.
This
is
what
we
have
in
the
table,
one
in
the
what
not
to
do
dash
18
draft
and
we're
basically
saying
how
you
know
what
do
we?
What
do
we
do
with
the
different
lessons
that
we've
learned
and
two
of
them
were
not
now,
which
are
this
characteristic,
tends
to
turn
up
a
minefield
full
of
dragons
with
the
rest
of
that
caveat
one
is
imports,
trusting
intermediate
nodes
and
one
is
intermediate
nodes.
C
Please
not
now,
I'm
trying
to
figure
out
if
not
now
is
actually
not
ever
so.
One
of
the
things
that
other
people
have
observed,
hi
adrian
penergy,
has
been
focused
a
lot
on
indian
transport
and
the
conversations
I've
had
about
that-
and
this
is
a
quote
from
an
isg
off-site-
was
if
we
could
send
packets
with
no
source
and
destination
addresses.
C
We
would
but
I
observe
that
there
are
network
elements
and
hosts
that
trust
each
other
in
addition
to
network
elements
and
hosts
that
don't
which
is
true
of
pretty
much
all
the
elements
and
hosts
in
the
iot
ops
puff
that
happened
earlier
this
week,
and
I
I
I
wanted
to
call
out
elliott
lear's
presentation
there
as
something
that
was
really
really
clear
on
helping
me
understand
that
and
that
I
have
observed
people
that
want
to
exploit
trust,
and
I
mean
that
in
a
good
way.
C
It's
like
starting
with
the
next
presentation,
next
slide,
please
so
my
questions-
and
this
is
going
to
be
for
discussion
on
the
mailing
list
or
for
an
interim
which
is
starting
to
look
like
a
better
and
better
idea.
As
we
talk
is
the
my
is
trust
always
going
to
be
a
mindful
field
full
of
dragons.
If
that's
true,
we
should
write
that
down
and
say
and
basically
tell
path,
aware
networking
designers
don't
go
there
if
we
think
it
could
be
usable.
C
Sometimes
we
should
write
that
down
too
and
think
about
what
are
the
prerequisites
for
path.
Aware,
trust
I
mean
between
the
the
host
and
the
first
hop
nodes
is
an
obvious
case
between,
inter
immediate
nodes
is
an
obvious
case.
Even
between
networks
is
horrifying,
but
I
mean
people,
people
try
to
do
these
things,
and
my
question
is
you
know
next
question
is:
how
do
we
avoid
tripping
over
the
lessons
that
we've
learned?
If
trust
is
usable,
what
else
needs
to
be
true
in
order
to
achieve
deployment?
C
This
is
getting
into
a
meta
question
about.
Are
we
ready
to
start
on
a
penargy
what
to
do
draft
which
people
have
been
asking
for
for
for
a
while
and
next
slide?
Please.
C
For
example,
in
some
of
the
ones
that
I'm
looking
at
right
now,
I'm
especially
interested
in
these.
In
these
lessons
learned,
and
especially
the
one
that
is
invariant,
which
is
basically
saying
we're,
you
know
this
is
always
going
to
be
true
and
you
need
to
have
a
really
good
story
for
the
impact
on
operational
practices,
but
that's
not
to
say
that
the
other
lessons
learned
are
not
interesting,
but
it
seems
you
know.
C
It
seems
obvious
to
me
that
the
lessons
learned
are
useful
for
us
to
be
looking
at
different
proposals
both
here
and
as
the
isg
said
in
the
iatf.
That's
my
last
slide.
I
think.
C
So
under
the
mailing
list,
right.
B
I
am
afraid,
yes,
I
I
know
it's
good.
I
would
love
to
hear
the
discussions
but
looks
like
we
made
a
mistake
by
scheduling
just
one
hour,
brian,
in
the
queue
okay.
A
A
suggestion
that
we
actually
try
and
do
an
interim
before
111,
which
I
think
is
probably
not
a
bad
idea
and
I'm
wondering
if
we
want
to
just
use
the
next
minute
to
have
a
quick
intro
to
the
next
talk.
Take
this
discussion
to
the
mailing
list
and
pick
it
up
in
a
couple
of
months.
In
an
interim.
B
Okay,
I
am
getting
the
next
presentation
ready
just
a
second
okay,
sorry,
I
am
not
very
effective
and
230.
I
am
verification
in
the.
Q
Q
The
first
one
is
that
if,
for
anyone
get
some
information
from
the
network,
can
it
pass
the
information
and
the
second
one
is
if
the
an
opponent
has
some
some
suggestion
to
the
network,
can
the
intermediate
know
the
cluster
discussion
or
plus
that
it
is
from
ready
the
other?
Q
This
is
a
to
the
problem
next
speech.
Please.
Q
Normally,
we
cannot
assume
that
we
can
trust
each
other,
because
we
found
the
reason
is
that
the
independent
work
work
can
support
this
layer,
4
connections
and
the
network
only
supported
to
this
layer.
3
x4
is
a
hardware,
a
replacement
relationship
between
them
because
they
work
in
the
different
network
layers.
Q
Next
page,
please,
and
in
our
of
the
visions
we
find
that
the
gateway
of
the
endpoint
is
able
to
maintain
a
connection,
state
and
transfer
relationship
for
each
user,
such
as
this
png.
It
means
a
broadband
network
of
g3,
and
we
also
found
that
the
ingress
ee,
perhaps
is
a
main
node
to
select
a
path
for
the
flow.
Q
So
we
think
that
if
we
we
cannot
make
every
intermediary
order
trusted,
perhaps
we
can
make
this
png
and
the
intermediate
ingress
in
this
ingress
e
trusted
next
speed.
Please.
Q
Okay,
so
we
have
a
initial
solution
for
this
from
the
inverse
pe
to
the
client.
We
can
make
this
ingress
pe
insert
insert
some
technique
later
for
the
message
and
from
the
client
to
the
ingress
pe,
perhaps
linguistic
announcement
of
every
translator,
so
we
like
this
indeed
make
us
later
instead,
so
oh,
we
can
put
this
traffic
into
a
set
between
this
png
or
this
inverse
p
is
our
potential
solution.
B
A
Yeah,
let's
take
take
all
of
that
to
the
list
and
one
of
the
we'll
reach
out
sort
of
like
the
next
week
or
the
following
week
on
starting
to
schedule.
An
interim
we'd
want
to
do
that
between
now
in
san
francisco,
which
is
sort
of
the
end
of
july,
so
we'd
probably
be
looking
at,
like
late
may,
mid
to
late
may,.
L
A
But
we'll
find
something
that
works
in
the
time
zone
that
works
for
the
participants
as
well.
I
know
this
was
super
late
for
jen
and
super
early
for
everybody
on
the
west
coast,
the
u.s
so
we'll
try
and
find
a
a
different
slot
for
that
as
well.
So
thank
you
all
for
for
your
attention
and
thank
you
to
the
presenters,
especially
for
going
fast,
and
we
will
see
you
on
the
list
and
at
the
interim.