►
From YouTube: IETF113-DTN-20220322-1330
Description
DTN meeting session at IETF113
2022/03/22 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
So
I'm
conscious
that
it's
now
half.
B
A
Two
in
vienna
half
past
whatever
the
hour
is
wherever
you
are,
so
I
think
that's
probably
our
cue
to
kick
off
ed.
Are
you
alive
and
well
yeah
excellent,
so
welcome
everyone
welcome
to
the
ietf113dtn
working
group.
What
we
were
very
pleased
to
say
that
vinsurf
has
joined
us
to
say
a
few
words
about
the
operation
of
the
ipn
sig
and
his
opinions
on
state
of
play
of
dtm.
A
So
what
I'm
going
to
do
is
going
to
run
through
these
chair
slides,
pretty
promptly
because
vince
on
a
bit
of
a
timeline
and
then
we
can
get
straight
on
to
him
and
then
get
on
with
the
regular
working
group
business.
So
as
this
is
an
ietf
meeting,
you
should
be
aware
of
the
note
well.
This
meeting
operates
under
the
note.
Well,
if
you
have
not
attended
any
meetings
before
and
have
not
read
the
note
well,
I
strongly
recommend
you
go
away
and
do
it
in
your
own
time.
A
It
covers
ipr
behavior
the
fact
that
you
are
waving
your
rights
to
restrict
it
gives
us
the
rights
to
record
for
posterity.
The
any
comment
you
may
make
at
microphone
and
if
you
turn
on
your
camera,
etc,
the
bcps
which
cover
this
in
detail,
are
detailed
on
this
slide.
Please
reach
out
to
the
chairs
the
ad
or
anyone
else
within
an
all-time
idea.
A
It
can
point
you
at
the
actual
material,
because
this
is
the
first
fully
hybrid,
I
would
say
post
covid,
but
I
think
that
might
be
a
little
bit
ambitious
meeting.
There
is
an
in-person
participant
tool,
as
well
as
a
remote
participant
tool.
This
is
to
keep
meet
echo
operating
well
between
those
who
are
set
in
the
room,
and
those
of
us
like
myself,
dialed
in
if
you
we're
operating
a
single
mic
queue.
So
if
you
have
questions,
please
download
the
meet
echo
lite
onsite
tool
onto
your
phone.
A
I
think
it's
all
done
as
a
web
browser
and
that
should
allow
you
to
join
the
queue
correctly
and
we
can
manage
a
single
queue
without
hopefully
too
much
disruption.
It's
been
working
well
so
far,
so
yeah!
If
you
are
on
site,
please
keep
your
audio
and
video
off.
Otherwise
we
get
terrible
feedback
loops,
remote
participants,
it's
just
like
it's
been
for
the
last
two
years,
so
just
operate
the
meat
echo
website,
as
as
you
always
have
done
so
here,
is
a
little
bit
of
boilerplate.
A
Just
in
terms
of
the
main
agenda
for
our
atf-113
is
here
we'll
cover
the
working
group
agenda
in
a
minute
meet
echo
further
information
is
also
here,
the
irony
being
that
I'm
displaying
this
through
meet
echo.
So
if
you
can't
see
this,
how
do
you
see
the
url
but
hey
and
if
you
need
any
technical
assistance,
there's
a
dedicated
issues
page
if
you
are
stuck
in
the
room,
and
none
of
this
is
working.
A
A
This
is
the
admins
administrator
from
the
chairs,
a
quick
five
minutes
just
to
cover
where
we
are
and
what
we're
doing,
and
then
we've
got
vint
kindly
for
25
minutes
and
then
we're
kind
of
into
the
meat
of
new
charter
items
updates
on
existing
documents
and
ed,
and
I
both
have
a
couple
of
questions
to
put
to
the
working
group
which
we've
done
as
a
set
of
slides,
which
we'll
squeeze
in
at
the
end.
We've
got
quite
a
packed
schedule,
so
we've
only
got
five
minutes
for
open
mic.
A
A
Administrative,
so
there
is
an
integrated
note-taking
tool.
It
was
called
codemd,
but
I
believe
mitocho
have
moved
to
a
different
tool.
It's
markdown
based
it's
interactive.
Our
secretary
adam
is
currently
hopefully
logged
into
it.
I
haven't
checked:
please
help
him
get
the
minutes
correct,
particularly
around
your
name,
which
is
always
difficult
to
grab
off
the
mic
and
just
double
check.
If
you're
making
comments
that
it's
been
captured
correctly
and-
and
your
point
was-
was
correctly
documented
and
if
you're
just
feeling
generous,
please
help
us
out
keeping
those
minutes
an
accurate
record
for
for
posterity.
A
As
usual,
the
the
mailing
list
is
dtn
at
itf.org.
That's
where
the
main
business
of
the
working
group
happens
so
long
drawn
out
conversations.
We
will
point
at
the
list
and
please
subscribe,
monitor
and
contribute
on.
The
list
would
be
great
if
you
want
to
contact
the
chairs.
It's
dtm,
hyphen
chairs,
ietf.org,
that's
a
great
place
for
procedural
questions.
A
If
you
start
asking
us
technicalities,
we
will
probably
redirect
you
back
to
the
list
and
continue
the
conversation
there
in
public.
One
thing
I
did
want
to
add:
after
ietf112
was
we
did
discuss
our
recharge.
That
rechartering
has
happened.
I
recommend
people
to
look
at
the
new
charter
page
for
the
dtn
working
group.
It
is,
as
was
agreed
at
the
previous
itf
meeting.
We've
had
the
sign
off
from
the
iab
it's
fully
approved
and
we
can
move
ahead
with
the
topics
we
wanted
and
also
most
important.
A
We
have
four
rfcs,
so
the
last
four
six
years
of
hard
work,
updating
bundle,
protocol,
tcpcl,
bp,
sec
default
security
context
around
ppsec
are
now
a
nice
set
of
rfcs.
A
So
well
done
the
working
group
that
nicely
bookends
the
previous
epic
amount
of
work
we
put
in
and
allows
us
to
start
a
new
chapter
really
from
this
meeting
onwards.
Looking
at
the
next
steps
for
the
dtm
working
group-
and
I
think
that
loans,
unless
ed
has
anything
to
say,
do
you
want
to
jump
in.
C
D
And
so.
A
D
Just
two
things
I
want
to
say:
first,
please
scan
this
one
if
you
want
to
be
because
we
don't
have
a
physical
blue
sheet
this
time,
so
please
scan
this
one
so
that
you
are
in
the
enlisted.
So
if
you.
D
You
will
be
here,
but
you
will
not
have
that
in
that
in
the
list.
Please
do
that
and
second
one.
I
would
like
to
repeat
that.
Congratulations,
this
this
working
group.
It
has
been
nice
working
with
with
this
and
recharging,
went
really
well
and
thanks
to
the
chairs
and
thanks
to
the
authors,
to
the
48,
who
has
put
a
lot
of
effort
to
get
things
right
so
vent
after
you
thanks
ahead.
E
Sorry
about
that,
I'm
puzzled
because
his
work
just
fine
a
moment
ago-
and
I
don't
see
why.
What
is
it
that
I
need
to
do
to
get
it
to
show
the
full
screen.
E
E
Second,
congratulations
on
all
the
progress
that
you've
made
and
third,
we,
you
have
many
many
folks
around
the
world
who
are
very,
very
excited
about
the
work
you're
doing
the
work
you
will
do
with
under
the
new
charter
and
the
opportunity
to
demonstrate
for
many
others
of
the
efficacy
of
the
standardization
that
you've
already
accomplished.
E
E
The
special
interest
group
was
formed
in
1998
and
it
was
parallel
to
the
work
that
began
at
the
jet
propulsion
lab
and
has
now
expanded
to
a
wide
range
of
nasa
laboratories,
as
well
as
other
space
fairing
agencies
like
issa
and
jaxa
and
others.
So
the
effort
over
the
past.
What
now
almost
24
years
has
yielded
a
great
deal
of
output,
including
all
the
work
that
you've
done.
E
So
the
ipn
sig
group
is
as
a
small
board.
Yosuko
kaneko
is
the
chair
he's
also
a
senior
member
of
jaxa
scott
burleigh
is
the
vice
chair
and
has
recently
retired
from
the
jet
propulsion
lab,
but
is
still
extremely
active.
As
you
all
know,
in
dtn
matters
mike
snell
is
the
secretary
treasurer
and
has
served
the
ipm
sig
for
many
years.
E
I'm
just
a
member
of
the
board
oscar
garcia
who's
present
today
in
the
call
is
also
the
chair
of
our
projects,
working
group
and
extremely
active
in
implementing
both
the
dtn
protocols
and
also
applications
that
go
on
top
of
them,
as
is
alberto
montia
and
keith.
Scott
all
of
you
know,
is
extremely
active
at
mitre
and
then
the
ccsds
program
for
standardization
of
the
bundle
protocols
we
have
over
800
members,
scattered,
I
won't
say
exactly
uniformly,
but
not
not
too
uniformly
around
the
world,
which
is
very
satisfying.
E
There's
a
lot
of
interest
in
the
work
that
you're
doing
and
and
in
the
prospects
of
interplanetary
networking.
The
ipn
cig
has
created
a
number
of
working
groups
in
order
to
progress
its
efforts.
The
strategy
working
group
produced
a
report
in
2021
which
is
available
on
the
website,
and
it
looks
to
the
next
hundred
years
of
evolution
of
the
interplanetary
backbone
network.
There's
a
projects
working
group
led
by
oscar
garcia
and
it's
actively
implementing
and
testing
the
protocols
and
I'll
come
to
to
that
in
the
next
slide.
E
What
are
the
terms
and
conditions
for
operation,
one
of
their
multiple
parties
who
are
implementing
pieces
of
the
interplanetary
backbone?
What
are
the
rules
by
which
the
entire
operation
functions
and
as
we
ex
extend
our
human
operation
beyond
planet
earth?
Exactly
what
does
jurisdiction
look
like?
What
are
the
rules
of
the
game
for
for
operating
in
space?
So
this
is
still
more
or
less.
I'm
sorry,
I'm
being
distracted
by
the
fact
that
there
are
a
bunch
of
guys
hanging
on
the
side
of
the
building
cleaning.
E
My
window
there's
nothing
more
slightly.
You
know
weird
feeling
I'm
on
the
16th
floor
of
the
building,
and
there
are
people
who
are
watching
this
presentation.
E
There
is
a
library
which
is
accumulating
a
great
deal
of
information
about
interplanetary
networking,
and
I
urge
you
to
have
a
look
and
also
to
contribute
to
that.
Of
course,
all
the
work
of
the
dtm
working
group
will
show
up
in
the
library
there's
an
outreach
working
group
which
is
intended
to
draw
the
attention
of
the
general
public
to
the
work
that
you
do.
E
And
many
of
you
who
are
watching
the
return
to
the
moon
will
know
that
there
are
for-profit
companies
spacex
and
many
others
that
are
quite
interested
in
what
it
might
mean
to
operate
in
a
commercial
sense
off
earth,
ranging
from
mining
on
the
moon
to
manufacturing
in
zero
gravity
to
entertainment
and
travel.
E
Their
strategy
report
is
mentioned
in
the
last
line
here
of
this
slide,
and
I
draw
your
attention
to
it
because
it's
our
attempt
to
summarize
what
might
happen
over
the
past
over
the
next
100
years
or
so
here
are
our
intentions,
at
least
as
I
interpret
them
as
the
interplanetary
networking
special
interest
group.
E
One
thing,
that's,
I
believe,
pretty
clear
to
all
of
us-
is
that
there
will
be
multiple
parties
operating
pieces
of
the
interplanetary
backbone
in
the
same
way
that
there
are
many
parties
operating
pieces
of
the
terrestrial
internet,
and
so
we're
going
to
have
to
make
sure
that
a
multi-network
construct
actually
works
well,
that
the
independently
operated
but
cooperating
portions
of
the
interplanetary
backbone
can
actually
interwork
in
the
same
fashion
that
the
terrestrial
internet
has
has
demonstrated,
and
so
that's
a
very
important
issue
to
resolve
and
finally,
on
this
line
anyway.
E
We
also
need
to
make
sure
that
various
implementations
of
the
bundle
protocol
will
interwork
successfully.
So
that's
another
opportunity
for
us
to
demonstrate
the
quality
of
the
of
the
work
that
you've
done.
We
are
expecting
to
collaborate
with
a
wide
range
of
different
parties.
The
project
working
group
involves
about
20
or
30
people,
as
oscar
garcia
can
tell
you
who
are
all
working
on
various
and
sundry
demonstrations
of
the
of
the
technology.
E
The
you
nasa,
of
course,
has
a
dtn
working
group
and
they
are
parallel
to
the
work
that
you
do
and
they're
busy
implementing
the
protocols
and
testing
them
in
a
variety
of
environments,
including
the
international
space
station
and
looking
forward
to
the
return
to
the
moon.
Lunanet
at
nasa.
Moonlight
at
esa,
among
others,
are
programs
that
are
being
undertaken
by
the
space
agencies
in
the
return
to
the
moon
and,
of
course,
we
expect
the
dtn
protocols
to
be
a
part
of
all
of
that
at
utica
college.
E
There's
a
very
active
engagement
in
the
implementation
and
test
of
the
protocols,
as
well
as
el
modio,
who
is
also
present
at
this
meeting.
E
Who
has
a
testing
laboratory
and
I've
left
out
a
number
of
other
players,
and
I
apologize
if,
if
I
didn't
include
you
in
this
list,
I
just
want
to
make
sure
that
all
of
you
appreciate
that
there
is
significant
and
growing
interest
in
the
in
the
work
that
you've
already
accomplished
to
say
nothing
of
what
you're
going
to
do
in
this
newly
chartered
period.
E
I
mentioned
earlier
that
the
commercialization
of
space
and
the
departure
from
from
earth
creates
all
kinds
of
really
interesting
questions
about
the
governance
of
of
operation
in
space,
not
just
of
the
interplanetary
backbone
network,
but
all
the
other
ancillary
things
that
one
could
imagine
whether
it's
mining
on
the
moon
or
space
laboratories.
You
know
habitations
on
mars.
You
know,
as
we
look
further
out
into
the
future.
The
question
is:
how
is
that
all
going
to
work-
and
it's
not
obvious
now?
E
One
thing
that
I
can
tell
you
is
that,
in
the
artemis
return
to
the
moon
missions,
a
substantial
amount
of
work
on
governance
was
undertaken
in,
what's
called
the
artemis
accords,
which
are
adjunct
to
the
many
space
treaties
that
have
already
been
agreed
in
the
past.
The
artemis
accords
take
a
fairly
broad
look
at
what
it
will
be
like
to
function
in
on
the
moon
with
multiple
national
and
private
sector
entities
all
interacting
with
each
other.
Exactly
what
does
that
jurisdiction?
Look
like
how
will
disputes
be
resolved
if
there
are
any?
E
What
does
it
mean
to
own
private
property
on
the
moon?
How
do
we
fence
off
historical
sites
like
the
landing,
the
july
landing
in
1969
among
other
sites
and,
of
course,
extending
that
to
sites
on
mars
and
and
other
planets
and
and
moons
of
our
solar
system?
So
this
governance
framework
discussion
is
bound
to
get
off
into
a
variety
of
weeds
and
it
does
require
substantial
attention
in
order
to
make
sure
that
we
can
operate
in
space
in
a
in
a
friendly
and
cooperative
way.
E
And
finally,
this
is
the
last
slide
and
also
the
last
bullet
point.
We're
very
interested
in
drawing
public
attention
to
the
work
that
you're
doing
and
the
notion
of
an
interplanetary
backbone,
and
so
we're
looking
at.
If
you
remember
the
search
for
extraterrestrial
intelligence
seti
at
home,
allowed
people
to
download
an
app
that
would
take
in
radio
signal
received.
Digitized
radio
signals
to
look
for
irregularities.
E
We'd
like
to
do
is
build
an
ssi
solar
system
internet
at
home
to
allow
people
to
help
us
exercise
a
terrestrial
implementation
of
the
bungle
protocol
system.
In
order
to
test
its
ability
to
scale
up
and
to
manage
various
and
sundry,
you
know
failure
modes
to
identify
and
recover
from
them.
So
there
is
a
very
significant
agenda
that
the
ipn
sig
has
adopted,
and
I
hope
that
many
of
you
who
are
already
planning
on
standardization
work
will
join
us
in
implementation,
test
and
demonstration
as
well.
So
I'm
going
to
stop
there.
E
Let's
see
if
I
can
stop
sharing
my
slides
and
return
to
to
the
meeting,
and
thank
you
for
the
time
I
didn't
take
20
minutes
or
25
minutes,
and
I
think
that
that's
good,
because
you
have
so
much
work
to
do
that.
Giving
you
back.
B
E
C
So
if,
if
we
don't
have
someone
sort
of
coming
up
to
the
my
task
of
the
specific
questions,
the
one
I
would
have
is
I
I
look
at
the
audience
participation
here,
the
the
number
of
folks
we
have
which
is
higher
than
we
typically
have,
and
so
that
says
to
me
that
we
may
have
a
few
people
here
who
are
new
to
dtn
as
a
set
of
technologies
new
to
the
bundle
protocol,
as
as
as
the
mind
behind
the
initial
intention
for
standardizing
store
and
forward.
E
Well,
I'm
happy
to
do
that.
Many
of
you
will
perhaps
remember
that
in
1997,
a
pathfinder
robot
vehicle
was
landed
on
mars
successfully
after
20
years
of
failure.
The
previous
success
was
1976
with
the
two
viking
landers
and
then
nothing
worked
for
a
long
time.
So
there
was
great
celebration
that
we
finally
got
back
to
mars
with
a
successful
landing
the
following
spring.
E
So
we
said
well
can't
we
use
tcp.
It
works
okay
on
earth.
Why
wouldn't
it
work
on
mars
and
the
answer
is
well,
it
will
work
on
mars.
However,
we
started
doing
the
math
for
interplanetary
distances
and
discovered
very
quickly.
The
tcp
with
a
40-minute
round-trip
time
has
a
lot
of
trouble
with
flow
control,
so
we
decided
it
was
time
to
rethink
this
very
different
parametric
space.
E
Recent
protocols
needed
in
this
very
different
parametric
space
and
we
began
to
design
the
bundle
protocols
and,
as
all
of
you
know,
we've
been
through
now
seven
iterations
of
the
bungle
protocol
design.
Hopefully
this
one
will
be
stable
and
we
can
now
stick
with
implementing
and
reinforcing
and
standardizing
it,
but
you
can
tell
that
the
speed
of
light
is
simply
too
slow,
and
we
can
complain
to
mr
einstein
about
this,
but
nobody's
found
any
way
to
fix
that.
E
So
that's
what
led
to
the
work
that
you
are
now
presently
engaged
in
and
it's
it's
actually
been
a
lot
of
fun
to
be
forced
to
rethink
networking
protocols
in
a
different
context.
A
D
Hello,
I
hope
you
can
hear
me
right
yeah.
So,
first
of
all,
thank
thank
vin
for
being
here
with
us
and
sharing
this
really
exciting
ideas
and
agendas.
I
mean
this
this.
This
looks
really
cool,
so
I
think
I
have
two
questions
to
you
and
not
really
about
this
old
technology.
One
one
was
like
for
for
this
itf
working
group,
and
we
have
reached
our
day.
D
E
Oh,
oh,
oh
well.
Well,
first
of
all,
of
course,
we
want
you
to
continue
to
refine
the
protocols
and
take
and
to
take
into
account
that
not
only
do
we
have
to
deal
with
these
highly
variable
delays
and
disruption,
but
we
also
want
this
to
work
in
real
time.
So
if
for
cases
where
we
actually
have
low
latency,
I
would
like
to
be
able
to
do
streaming.
Video
like
we're
doing
right
this
moment,
I'd
like
to
be
able
to
build
applications
that
will
function
reliably
in
the
same
way
that
they
function
in
the
present
day.
E
Internet
is
just
that
the
architecture
has
to
include
the
entire
range
of
delay
and
disruption,
and
so
when
it,
when
we
have
low
latency,
everything
should
work
pretty
much
the
way
tcpip
does
but
yeah.
When
we
don't
have
low
latency,
it
has
to
work
in
the
way
that
we
intend
with
the
dtn.
So
that's
one
thing.
The
second
thing
I
think,
is
that
we'd
like
very
much
to
see
more
energy
put
into
applications
to
understand
what
it
means
to
build
a
delight,
tolerant
application.
E
And
finally,
I
mean
among
many
other
things
I
I'd
like
to
exercise
the
naming
and
addressing
structures
in
order
to
regularize
them
and
come
to
agreement
about
how
that
should
be
managed.
As
you
all
know,
we
have
in
the
internet,
the
iana,
the
internet,
design
numbers
authority
and
on
the
ccsds
side
we
have
senna
and
I'm
hoping
that
that
will
be
a
parallel
operation
that
we
can
rely
on
and,
finally
commercialization.
You
should
be
thinking.
E
D
Yeah
thanks
thanks
for
this,
I
think
from
your
what
your
expectation
from
this
working
was
like.
I
think
we're
already
dealing
couple
of
things,
the
addressing
thing,
the
maintenance
things
that
the
configuration
part
of
it.
I
think
this
this
is
great
and
the
real
time
thing
I
think
we
then
we
need
to
have
engage
a
bit
broader,
itf
community,
to
that
one
like
what,
because
we
already
have
some
established
protocols
for
those
kind
of
use
cases
and
bringing
the
boundary
protocol
and
the
same
kind
of
thing
might
be
a
bit
like.
D
We
need
to
think
a
bit
more
holistic
way
of
looking
at
it
and
see
like
how
this
fits
into
current
architecture.
But
I
think
the
point
you
made
like
getting
the
architecture,
this
electron
architecture
into
the
into
the
so-called
internal
way
of
doing
things,
it'd
be
a
nice
combination
to
look
on.
So
thanks
for
those
words
and
thanks
thanks
for
being
here.
E
Well,
thank
you
all
very
much.
I
do
need
to
go
off
to
another
meeting,
but
I
wish
you
well
and
the
rest
of
this
one
and
certainly
again
thank
you
for
all
the
work
that
you're
doing,
because
it's
enabled
us
to
be
active
in
promoting
the
interplanetary
backbone
work
that
your
efforts
support
so
I'll
bid.
You
adieu
safe
journey.
Thank.
A
E
A
Thanks
so
much
thanks,
so
just
as
I,
I
joined
the
cube
briefly
because
we,
I
have
a
presentation
at
the
very
end
of
of
the
agenda
for
this
meeting,
covering
two
of
the
points
been
raised
about
naming
and
addressing
and
some
of
some
early
steps
forwards,
which
would
allow
some
applicability
within
the
terrestrial
internet.
A
So
for
those
of
you
who
can
bear
it
now
that
vinta's
finished,
please
stay
until
the
end,
because
we're
going
to
cover
some
topics
there,
which,
which
should
open
things
and
in
the
rest
of
our
agenda,
is
equally
as
interesting,
but
a
big
thank
you
for
vint
in
retrospect
for
for
speaking,
so
ed,
I'm
going
to
hand
over
to
you
because
I
have
spoken
a
lot.
C
Oh,
no,
that
that's
totally
fine,
but
I
I
think
that
now,
in
the
interest
of
time,
we
should
go
into
our
agenda
items.
My
my
understanding
is
that
we
are
going
to
present
slides
for
our
presenters
and
manage
them
so
that
individual
presenters
don't
need
to
share
their
screen
and
otherwise
go
through
their
clients.
Is
that
correct.
A
So
the
latest
version
of
meet
echo
has
the
ability
to
share
slides
centrally
and
to
effectively
pass
the
next
slide.
Please
functionality
to
the
individual
presenter,
so
they'll
get
a
little
strip
appears
at
the
bottom
of
the
slide
deck
in
their
window
and
they
can
click
forwards
and
back
so
scott.
I
will
pass
the
slide
control
for
this
slide
deck,
and
you
should
see
within
your
meet
echo
that
you
now
have
a
little
strip
across
the
bottom
of.
F
How
elegant
can
you
hear
me.
F
Hi
all
right!
Well,
let's,
let's
start
then,
and
I'll
try
to
get
through
this
in
25
minutes.
I've
got
two
presentations
here.
One
on
bundle,
bundle
encapsulation,
one
on
quality
of
service,
which
are
a
couple
of
the
items
that
are
in
the
new
charter.
The
bundle
model
encapsulation
presentation
actually
is
a
very
little
change
from
the
one
I
gave
in
spring
of
2021.
F
This
is
to
refresh
everyone's
mind
on
what
this
is
about
and
and
to
introduce
it
to
anybody
who
missed
the
earlier
presentation
on
it.
I
think
this
is
a
an
important
technological
feature
for
for
deploying
a
useful
delay,
tolerant
networks
in
the
future.
So
I
I
think
it's
worth
spending
a
little
bit
of
time
on.
Is
this
gonna
work?
F
Okay,
good!
I'm
gonna
slide
two
all
right
the
overview
of
the
presentation,
I'll
give
a
short
history
of
vibe
and
talk
about
custody
signaling.
In
that
context,
the
current
vibe
design
and
possible
applications,
and
then
just
a
note
on
the
future
use
of
the
thing
you
know
short
history
vibe
actually
goes
back
to
2009..
F
Some
of
our
colleagues
at
mitre
corporation,
put
together
this
internet
draft
in
august
of
that
year,
and
the
idea
at
that
point
was
that
one
bundle
encapsulation
would
be
a
a
bundle
protocol
application.
Now.
The
basic
idea
of
five
is
that
you
use
one
protocol
to
send
bundles.
That
is
the
the
the
payload
of
a
bundle
is
another
bundle.
It's
tunneling
and
the
same
kinds
of
advantages
of
tumbling
in
in
the
internet,
applied
to
a
bundle
model
encapsulation
in
in
dtn.
F
The
specific
motivations
cited
in
in
in
that
original
draft
were
support
for
for
content.
Centric
networking
forwarding
cash
bundles
targeted,
custodial
retransmission
of
multicast
bundles,
which
was
an
open
problem
at
that
time,
and
security
in
particular
defense
against
traffic
analysis,
which
nothing
else
that
we
were
looking
at
at
the
time
would
provide.
F
F
Organization
that
is,
instead
of
being,
instead
of
looking
at
vibe
as
an
application
on
top
of
bundle
protocol.
I
think
it's
important
to
look
at
it
as
a
convergence
layer
protocol
underneath
on
the
protocol,
so
it
you
know,
still
have
bundles
and
bundles.
It's
a
question
of
where
you
you
stack
them
in
the
stack
and
and
in
particular
the
idea
at
that
time
was
we
were
trying
to
disentangle
routing
from
security.
F
In
particular,
there
were
a
couple
of
things
that
were
discovered
that
what
made
it
just,
not
work
that
is
custody
transfer,
as
in
funnel
protocol
version,
6
had
two
significant
problems.
One
was
that
the
retransmission
depended
on
accurate
estimation
of
round
trip
time
so
that
you
could
know
when
to
retransmit
and
the
general
case
that
was
not
possible
because
you
didn't
know
who
was
going
to
be
the
recipient
and
from
and
therefore
from
whom
you
should
expect
a
custody
signal.
F
So
you
had
no
way
of
knowing
when
to
expect
that
signal
and
when
to
determine
that
it
was
late.
Another
serious
problem
was
that
the
bundle
fragmentation
by
non-custodians,
which
is
perfectly
okay,
couldn't
be
prevented
and
it
would
defeat
custody
transfer
because
the
anything
that
took
custody
of
of
the
fragments
those
custody
signals
would
not
match
up
with
any
bundle
that
any
current
custodian
had
had
custody
of.
F
At
the
same
time,
though,
there
were
scenarios,
especially
scenarios
in
involving
unidirectional
links
where
some
sort
of
delay,
tolerant,
asymmetric
acknowledgement
system
is
going
to
be
needed
and
bundle
protocol
is
an
obvious
mechanism
for
delay,
tolerant,
asymmetric
acknowledgement.
So
why
not
use
it
for
custody
transfer?
So
the
the
concept
that
that
emerged
was
that
and
I'll?
I
will
put
this
as
a
as
a
proposition
that
bundle
protocol
transmission.
Reliability
is
something
that
needs
to
be
accomplished
between
neighboring
protocol
nodes.
F
It
needs
to
be
accomplished
at
the
convergence
layer
because
of
the
same
problems
that
custodial
re-transmission
ran
into
in
in
bbv6
in.
In
that
sense,
if
custody
transfer
is
gonna
happen
at
as
a
reliable
transmission
mechanism
that
it
needs
to
happen
at
the
convergence
layer,
so
you
should
use
bundle
protocol
as
a
as
a
convergence,
their
protocol
and,
of
course,
hang
on
blibe
is
already
doing
that.
F
So
why
not
just
add
custodial
re-transmission
as
a
a
feature
of
vibe,
so
that
vibe
would
do
two
things
independently,
or
or
concurrently
across
domain
security
with
sources
and
destinations
and
giving
us
a
defense
against
traffic
analysis
and
also
reliable
convergence
theory
transmission
over
asymmetric
path
separately.
From
all
of
this,
back
in
2012,
there
were
researchers
at
the
university
of
colorado
boulder
that
had
designed
a
more
bandwidth,
efficient
definition
of
bpv6
custom
transfer.
F
It
was
documented
in
an
internet
draft
that
actually
never
got
posted
sebastian,
kuzminski
and
andrew
jenkins
at
uc.
Boulder
were
the
developers
and
it
was
very
effective.
It
was
developed
as
a
as
a
prototype
and
implemented
as
an
option
in
the
interplanetary
overlay
network
implementation
of
dtm
and
and
has
been
in
use
in
in
operational
transmission
from
the
international
space
station.
For
about
five
years
now
and
and
very
well
received,
it's
been
highly
successful
in
operations.
F
The
user
community
likes
it
a
lot,
and
so,
if,
if
we,
if
we
take
this
aggregated
custodial
signaling
concept
and
use
that
as
as
the
implementation
of
of
the
custody
transfer
idea
in
a
bundle
of
bundle
encapsulation,
the
result
is
this
draft
that
was
posted
in
may
of
2018
and
has
been
sort
of
sitting
there
waiting
for
somebody
to
do
something
with
it.
F
F
The
expected
time
of
acknowledgment
for
that
bundle
and-
and
that's
important
for
for
signaling
to
the
recipient
when
to
wrap
up
the
advocate
custody
signal
and
send
it
back
so
so
that
it'll
arrive
in
time
to
to
turn
off
the
re-transmission
timers
for
the
bundles
that
are
being
acknowledged
and
then
the
encapsulated
bundle.
F
The
acknowledgement
itself
is
an
aggregate
structure
that
is
conveyed
in
a
new
administrative
record
that
is
sent.
You
know
in
a
bundle
that
responds
to
the
the
bundles
themselves
and
it
includes
a
custody
transfer
disposition
code
such
as
it's
a
reason
code
essentially
and
then
sequences
of
of
consecutive
transmission
ids
overseas
bundles.
F
If
the
acknowledgement
is
not
received
by
the
expected
time,
then
transmission
of
the
encapsulated
bundle
is
assumed
to
have
failed
and
the
encapsulated
bundle
is
re
queued
for
reform,
something
that
that
came
up
in
in
discussion
of
this
with
with
goddard
space
life
center.
Quite
recently
is
what,
if
one
or
both
of
the
participating
nodes
don't
have
accurate
clocks,
we
have
the
bundle
lifetime
mechanism
provided
for
for,
for
operations
of
you
know
at
the
bundle
protocol,
but
what
about
bundle
model
encapsulation?
F
Is
this
going
to
be
an
expected
time
of
acknowledgment?
How
is
that
going
to
be
expressed
so
that
that
needs
to
be
addressed
in
the
next
edition
of
of
this
internet
draft
some
some
mechanism
that
enables
the
sender
to
say:
here's
when
I
expect
an
acknowledgement
and
and
for
the
receiver
to
understand
that
and
and
use
that
as
a
trigger
for
sending
the
acknowledgement,
aggregated
signals
back.
F
Okay,
given
all
of
that
I'll,
very
briefly,
run
over
a
couple
of
the
applications
for
this
technology
and
then
move
on
to
the
next
presentation
and
maybe
take
questions
for
everything
at
the
end.
I
think
that
bundled
bundle
encapsulation
actually
is
kind
of.
If
you
set
your
mind
to
thinking
about
it,
there
are
a
a
a
number
of
weird
kinds
of
scenarios
that
vibe
might
be
helpful
for
here's,
the
the
one
that
the
the
nominal
mechanism
that
we
use
before,
which
is
custodial
reliability.
F
F
You
encapsulate
the
original
unencrypted
bundle
as
the
payload
of
of
a
protected
bundle,
an
armored
bundle
that
crosses
the
no
man's
land,
defense
against
traffic
analysis,
if
you,
even
if
the
the
original
bundle
is
safely
encrypted,
you
may
still
want
nobody
to
know
where
it's
going
to
where
it
ultimately
comes
from,
and
you
can
do
that
by
encapsulating
it
in
in
in
a
bundle
between
two
well-known
points
of
the
network
and
and
the
the
final
destination
is
not
revealed
until
the
bundle
reaches
a
safe
part
of
the
network,
but
that
sort
of
transientness
of
security
can
be
extended
to
entrantness
of
quality
of
service.
F
It
may
be
that
the
bundle
doesn't
need
any
particular
quality
of
service
mechanism
applied
to
it.
While
it's
in
local
subnets,
but
across
the
the
trunk
line
of
of
the
network,
it
it,
it
needs
some
sort
of
special
markings
so
that
it's
handled
in
a
responsible
way
and
the
that
sort
of
quality
of
service
marking
can
be
done
with
bundled
bottle.
Encapsulation
again,
the
the
transientness
of
of
vibe
is
helpful
for
things
like
critical
forwarding.
F
That
is
one
of
the
features
of
the
expanded,
extended
class
of
service
mechanism
developed
for
ebb.
Six
is
this
critical
bundle
idea
that
ensures
that
the
bundle
has
got
the
greatest
possible
chance
of
getting
to
its
destination?
F
Multicast,
in
the
same
way,
maybe
only
part
of
the
network
needs
to
care
about
multicasting
enough
in
in
a
way
to
ensure
that
that
the
bundle
reaches
its
destination
by
sending
forward
multiple
copies
source
path.
Routing
is
a
a
sort
of
bizarre,
but
actually
potentially
useful
thing
you
can
do
with
with
a
bundle
of
bundle,
encapsulation,
just
encapsulating,
multiple
layers
that
will
sort
of
guarantee
that
the
the
point-to-point
transmission
of
the
bundle
along
a
specific
sequence
of
forwarding
elements
and
combinations
of
these
things
certified
multicastle.
F
You
know
there
are
a
number
of
weird
things
that
that
that
you
can
do
with
unfunded
encapsulation
and
still
be
well
within
the
the
the
rules
and
the
guard
rails
of
a
responsible
bundle
transmission
all
right.
So,
let's
switch
over
to
the
other
presentation
and
I'll
try
to
knit
through
it
quickly.
F
I
I
can't
if
there
are
some
that
are
ready
right
away.
I
wanted
to
make
sure
to
get
through
everything
and
not
hold
everybody
up
so.
A
Okay,
I
have
one
very
quick
question
on
that:
sorry
on
about
slide,
12
or
something
you
said
something
about
one
or
both
parties,
not
having
clocks.
I
wanted
to
just
go
into
your.
Do
you
mean
they
both
don't
have
a
a
synchronized
wall
clock,
or
do
you
mean
they
both
can't
count
seconds
or
milliseconds.
F
They
they
imagine
one
or
both
of
well
actually
imagine
the
sender
in
particular
does
not
have
a
its
clock
is
zero.
It's
a
broken
claw
and
so
right,
and
so
it's
it's
identifying
bundles
strictly
on
the
basis
of
a
counter
and.
G
A
A
Thanks
yeah
yeah
joshua
you're
in
the
queue,
if
it's
a
quick
one,
go
for
it
or
we'll
hold
to
the
end.
H
We'll
see
if
this
unmuting
actually
works
correctly
or
not,
so
this
is
joshua
deaton
over
here
at
the
marshall
space
flight
center
and
just
a
quick
question
might
just
be
my
ignorance
from
being
new
to
this
particular
group
for
this
vibe.
Are
we
considering
specifically
tying
vibe
and
ct
together,
or
are
we
considering
it
more
as
bi
being
a
standard
and
ct
being
more
as
kind
of
like
an
extension
of
vibe.
A
So
I'm
going
to
step
in
as
chair
here.
I
don't
think
that
is
clear
in
the
charter.
They
are
down
as
two
related
but
possibly
separate
topics,
and
I
want
to
ask
that
question
as
well,
but
can
we
let
scott
get
to
the
end
of
his
presentation
and
pick
it
up
there
because
I
think
that's
quite
an
in-depth
series.
F
Okay,
let's
switch
to
the
other
and
I'll
this
one
is
much
shorter.
A
Okay,
do
you
should
be
able
to
change
deck
by
the
little
button
in
your
little
toolbar,
you
should
be
able
to
say
open
new
slide
deck
and
find
the
next
set.
A
That'd
be
great
okay,
so,
oh
I
have
to
tell
you
to
stop
slide
sharing.
I
then
share,
and
it
is
that
one
chef
give
you
the
control.
F
A
F
Excellent,
oh
and
the
little
bar
can
I
get
that
bar.
F
It
is,
I
got
it
got
it:
okay,
cool,
yep,
okay,
good,
okay.
The
next
is
a
quality
service
and,
in
addition
to
bundle
to
custody
transfer
being
removed
from
bono
protocol
in
the
bpp7.
F
Specification
quality
of
service
had
been
in
in
bpv6,
and
it
also
is
removed
from
bpd7.
So
here's
a
a
an
attempt
to
cover
the
quality
of
service
issue
for
bpv7
and
and
elicit
the
conversation
on
this
topic.
So
what
I
will
suggest
to
start
off
with
here
is
that
the
the
fundamental
job
of
the
bundle
protocol
agent
is
to
forward
bundles
to
topologically
adjacent
bp
nodes.
That's
basically
what
a
bpa
does.
F
It
needs
to
do
a
lot
of
other
things
in
order
to
do
that,
it
needs
to
compute
robson
various
other
things,
but
but
the
thing
that
it
mainly
does
is
forward
bundles
to
to
other
nodes
that
are
topologically
adjacent
to
it,
using
convergence,
their
protocols
to
do
that.
So
when,
when
multiple
bundles
are
queued
up
to
be
forwarded
to
a
given
topologically
adjacent
vp
node,
how
does
the
bpa
decide
which
one
to
forward
next
and
the
bp
specification
is
silent
on
this?
By
default?
F
The
queued
up,
bundles
are
just
forward
up
forwarded
in
in
queue
order
in
first
in
first
out
order,
quality
service
would
be
a
mechanism
for
would
be
an
alternative
algorithm
for
making
that
decision
on.
F
On
various
bases
and
among
the
considerations
here
are
how
urgent
is
this
bundle
which
one's
you
know
the
book
you
should
send
the
urgent
ones
before
others
and
and
assurance
that
is
a
guarantee,
is
that
if
some
an
application
has
has
negotiated
a
guarantee
that
it
gets
20
of
the
bandwidth
from
a
to
b,
then,
if
it's,
if
it's,
if
it's
time
for
it
to
get
some
some
some
of
that
bandwidth,
then
that
bundle
should
go
even
if
other
bundles
are
are
a
higher,
are
higher
priority
more
urgent.
F
So
a
quick
survey
of
quality
of
service
that
that
I
drew
mostly
from
from
wikipedia
the
the
zeroth
order
solution
for
for
quality
services
over
provision
right,
if,
if
you've
got
so
much
bandwidth,
that
every
bundle
that
you
present
to
be
forwarded
is
forwarded
immediately,
then
quality
services
move,
there's,
there's
no
queue,
so
the
next
bundle
that
goes
out
is
the
one
that
is
going
out
right
now.
F
You
can
over
provision
to
some
extent,
but
I
will
suggest
that
we'll
never
actually
be
so
over
provisioned
that
this
is
a
total
solution,
so
next
quality
service
in
the
internet.
I
am
very
very
far
from
being
an
expert
on
quality
service,
the
internet.
I
hope
I
will
not
screw
this
up
too
badly.
My
understanding
is
that
the
the
two
general
flavors
of
internet
qos
have
been
integrated
services
and
differentiated
services.
F
It
was
the
earliest
of
the
quality
of
service
mechanisms
developed
for
operation
on
the
internet
and
and
it
worked
fine,
but
it
doesn't
easily
scale
because
the
the
number
of
sender
receiver
pairs
that
you
need
to
support
can
increase
exponentially.
F
Also,
it's
it's
sort
of
not
a
a
good
choice
for
a
dtn,
because
it's
not
delay
tolerant
negotiation
in
general
is
not
a
delay
tolerant
mechanism,
so
diffserv
looks
like
a
closer
fit.
It's
somewhat
newer
in
the
internet,
although
been
around.
For
many
years,
there's
a
differentially
differentiated
services
code,
point
code,
a
value
that
is
asserted
in
the
packet
header,
a
six
bit
number
that
selects
per
hop
behavior
and
the
parameters
of
per
hop
behavior
are
things
like
priority
subject
to
admission
control
assurance
of
transmission?
F
That's
the
reservation
sort
of
mechanism
again,
provided
that
the
traffic
rate
that
was
negotiated
is
not
exceeded
and
also
likelihood
of
dropping
a
packet
when
the
link
is
congested.
Those
are
are
among
the
parameters
that
go
into
the
per
hop
behavior
options.
F
There
is
no
guarantee
that
a
given
router
will
exhibit
the
requested
behavior
for
a
given
packages.
That
is
there
isn't
anything
that
that
disqualifies
a
router
that
happens
not
to
conform
to
the
requested
services
and
that
that
the
penalty
for
that
non-conformance
is
really
outside
the
protocol.
It's
a
matter
of
business
and
then
the
the
last
part
of
this
survey
is
okay.
What
did
we
do?
In
version
six?
F
There
was
a
class
of
service
value
defined
in
rfc
5050,
based
on
the
the
idea
that
dtn
is
somewhat
like
mail,
and
so
the
postal
model
of
of
of
class
of
service
was
introduced.
Three
classes
of
of
service
bulk
standard,
which
is
like
first
class
mail
expedited,
which
is
like
express
mail.
F
The
processing
of
this
was
not
defined,
as
usually
understood
to
be
a
priority,
but
nothing
in
the
protocol
said
it
had
to
be,
and
it
was
frequently
observed
that
this
is
all
on
the
honor
system,
that
is,
it
doesn't
cost
anymore
to
mark
a
bundle,
that's
expedited
than
to
mark
it
as
bulk.
So
why
would
not
all
data
be
all
bundles
be
expedited?
Why
would
you
say?
Oh
my,
please
don't
send
my
my
bottle
slowly,
I
don't
care
you
probably
wouldn't
do
that.
F
So
the
the
there
was
limited
utility
to
to
the
class
of
service
as
defined
in
rfc
5050,
which
is
why
it
is
removed.
So
there
was
so
an
additional
internet
draft
that
extended
that
class
of
service
mechanism
prototyped
in
in
the
ion
implementation.
There
was
a
that
extended
class
of
service
included
an
ordinal
tag,
which
is
a
more
layers
of
of
prioritization
for
expedited,
bundles.
So
scott.
A
I'm
watching
I'm
watching
the
clock
you're
five
minutes
over
at
the
moment.
Can
you
can
you?
Can
you
accelerate
in
some
way.
F
Yeah
yeah
I
am
trying
to,
but
I've
got
a
little
bit
of
a
late
start.
Also
I
have
trouble
there.
There
are
service
selection,
flags,
best
effort,
reliable,
critical
and
and
a
numeric
label
a
data
label
that
is
undefined
and
but
likewise
that's
just
you
know,
anybody
can
say
anything
so
a
a
problem
with
mechanism
called
service
quality
of
service
mechanisms.
That
discussed
here
is
that
there's
an
assumption.
There's
no
head
of
line
blocking
that
his
course
quality
service
gets
a
chance
to
operate.
F
I
mean
fairly
frequently,
and
that's
that's
the
case
for
ip,
because
packets
are
very
small,
bundles
are
not
bundles
can
be
very
large,
so
head
of
line
blocking
is
very
possible
and
that
would
inhibit
the
operation
of
quality
of
service
mechanism.
F
We
still
need
something
I'm
suggesting
here,
that
what
we
might
do
is
is
add
a
bundle,
processing,
flag
for
quality
service
handling,
is
requested
and
and
and
only
allow
that
flag
to
be
turned
on
if
the
bundle
is
less
than
64k,
so
that
quality
service
makes
sense
and
then,
along
with
that,
say
that
all
bundles
with
quality
service
flags
set
to
one
get
handled
before,
and
it
bundles
for
the
set
to
zero
so
that
quality
service
wins
and
given
that
you
might
define
a
quality
service
extension
block
that
has
some
sort
of
type
of
service
request,
something
like
the
the
flags
and
ecos
and
or
a
numeric
data
label,
and
then
adam
and
I
and
a
registry
of
data
labels
and
the
the
corresponding
requested
per-hop
behaviors
in
future
rfcs
and
again
let
implementation
of
perhaps
behaviors
be
a
node
implement
administration
responsibility
with
no
guarantees
same
as
basically
deaf
serve.
F
That's
the
end
of
this
presentation.
So
any
questions
talk
about
now
in
the
remaining
12
seconds.
A
Thank
you,
scott.
Sorry,
to
rush
you,
though,
it's
we've
got
a
tight
schedule.
Thank
you
for
all
of
this.
I
think
it's
particularly
the
second
part
I
think
you're
you're
heading
definitely
in
the
right
direction.
As
far
as
I'm
concerned,
that's
me
speaking
personally,
not
my
chair
hat
on
going
back
to
your
first
presentation.
The
the
the
the
elephant
in
the
room
is.
A
Can
we
do
reliability
without
sorry,
custody
transfer
without
requiring
bundle
and
bundle,
encapsulation
and
and
the
answer.
F
F
F
My
argument
here
is
why
I
have
two
when
you
can
use
one
to
do
both
jobs,
but
I'm
certainly
open
to
talking
about
doing
a
different
way.
A
My
my
reason
for
not
combining
the
two
was
was
simply
thinking
in
terms
of
overhead.
If,
if,
if
the
custody
transfer
mechanism
uses
an
extension
block
or
or
some
administrative
record,
then
you're
not
having
to
encapsulate
an
entire
bundle
and
it's
you
know
bp
sec
information
or
what,
however,
you
know
these
bundles
can
get
quite
fat
if
you're
not
doing
a
full
encapsulation.
That
might
give
you
some
more
efficiency
on
the
wire.
Or
am
I
misunderstanding
that,
because
I
haven't
got
data.
F
If
you,
if
you,
if
you're
using
a
if
you're,
implementing
a
reliable
conversator
protocol,
every
every
reliable,
every
every
converge,
their
protocol
encapsulates
the
entire
bundle
right.
So
you
really
don't
get
away
from
the
capsule
in
something.
D
So
scott,
I
okay,
I
came
up
because
of
the
third
bullet
on
the
current
slide,
so
no
guarantees
as
dissolved.
So
basically
I
think
they,
if
you
look
into
the
if
you
would
like
to
learn
something
from
the
dip,
serve
that
it
actually
not.
D
It
didn't
get
deployed
that
much
or
it
if
it
get
deployed
it
didn't
used,
so
it
didn't
deliver
what
it
promised.
For
so
I
mean,
I
think,
if
you
really
would
like
to
get
the
reliability
really
get
together
differential
service
and
everything
we
might
actually
need
to
think
a
bit
more
before
we
kind
of
mimic
what
is
in
deep
serve
just
like
question
here
I
mean
it
all
depends
on
what
we
want,
but
but
deep
server
is
a
not
successful
one.
That's
what
I'm
saying.
F
Right,
I
I
I
I
if
I
came
across
as
as
advocating
that
we
implement
diffserv,
then
I
misspoke,
I
think
this
serve
is,
is
a
very
reasonable
example
of
the
kind
of
thing
we
want
to
do.
I
don't
think
it's
the
model
for
bundle
protocol.
D
A
This
is
both
all
three
of
these
subjects
are
really
important
and
and
on
charter,
and
we
need
to
continue
possibly
even
an
interim
on.
Some
of
these
topics
might
well
be
worth
it,
so
we
have
a
bit
of
time
to
drill
into
some
of
this,
but
we'll
take
that
to
the
list
to
see,
if
there's
an
appetite
for
that.
So
right,
I'm
going
to
retract
your
ability
to
show
slides,
and
thank
you
very
much
brian.
It's
you.
A
B
I
can
see
it
and
I
combined
all
my
slides
together,
so
I'm
just
going
to
go
through
them.
It's
the
rough
order
of
priority
here.
B
So
the
first
thing
to
talk
about
is
is
maybe
the
simplest,
which
is
the
administrative
record
type
registry,
and
what
this
represents
is
oops,
that
in
rfc
9171
there
was
an
explicit
table
of
record
types
and
bpv6
itself
did
not
define
a
pre-existing
record,
but
another
rfc
after
bpv6
defined
this
registry,
and
the
point
of
what
this
topic
is
doing
is
just
adding
bpv7
to
the
iana
registry
as
a
column
indicating
the
applicability
in
the
same
way
it
was
done
for
bundle,
processing,
flags,
block,
processing,
flags
and
block
types,
and
the
other
thing
that
recently
I
noticed
was
that
as
scott
just
mentioned,
the
ccsds
did
standardize
an
aggregate
custody
signal
and
that
code
point
was
never
actually
rolled
back
into
the
iana
registry.
B
So
I'll
talk
about
that
in
a
second.
But
all
this
is
doing.
Is
it's
just
the
bookkeeping
of
making
sure
that
the
registry
is
accurate
and
up
to
date
and
then,
as
a
side
effect
of
that
it
becomes
then
usable
for
bpv7
allocations,
so
vibe
and
an
allocation
needed
for
acme
to
do
node
id
validation
both
would
make
use
of
this
registry
and
the
registry
as
it
sent
before,
was
specification
required.
B
There's
no
plan
on
changing
that
and
because
it's
specification
required
then
on
the
next
slide
here
I'll
show
what
the
the
changes
would
look
like.
That
code
points.
One
two
and
four
were
already
pre-existing.
B
Four
actually
was
the
one
that
was
missing,
but
because
it's
documented
in
a
specification,
it
probably
does
belong
there
just
to
indicate
that
it
is
in
use
and
then
the
only
other
thing
this
document
does
is.
It
makes
a
reservation
for
high
value
code
points
which,
because
these
are
cbor
encoded,
eventually
mean
that
that
last
line
is
32-bit
values.
B
And
the
majority
of
the
specification
is
just
text
wrapping
around
the
iana
table
update
so
on
this
topic.
Then
this
is
still
an
individual
draft.
I'm
requesting
adoption
of
the
document
and
and
then
at
that
point
details
could
be
worked
out
about
exactly
what
the
text
says
and
what
the
tables
contain.
But
this
is
really
just
a
currently
a
placeholder,
for
there
needs
to
be
some
kind
of
a
record
of
administrative
record
type
allocations.
A
Okay,
just
saying
noted
your
request
for
working
group
adoption
we'll
do
the
the
relevant
administrative
here
on
the
list
and
and
just
put
it
out
there
see
if
anyone's
got
any
objection.
But
it's
a
very
sensible
stretch.
B
B
Okay,
thanks
try
to
take
care
of
that.
The
next
topic
is
a
cozy
context
for
bpsec.
This
was
discussed
at
earlier
ietf,
so
I'm
going
to
get
right
into
detail,
and
some
of
this
material
is
overlapping
with
previous
discussion.
But
the
idea
is
that
bp,
sec
has
a
default
security
context,
that's
intentionally
limited
in
scope.
It
does
the
job
that
it
needs
to
for
a
number
of
symmetric,
key
algorithms.
B
B
A
bp
stack
is
made
to
be
extensible,
but
the
default
security
context
are
just
limited
by
design
so
for
internet
facing
nodes
and
interpretation,
especially
for
things
that,
like
scott,
was
just
talking
about
security
gateways,
processing
and
unprotected
external
network.
Things
like
where
you
have
to
interoperate
retain
agencies,
that's
where
pki
is
really
the
current
standard
of
interoperation
and
one
way
to
get
pki
immediately
off.
B
The
shelf
is
using
cose,
the
seaboard
object,
signing
in
encryption,
and
it
is
almost
purpose
built
for
this
kind
of
one
directional
security
application
and,
on
the
next
slide
I'll
show
some
information
about
the
the
idea
here
is
that
this
is
falling
in
the
existing
bp
sec
paradigm.
It's
using
existing
parameters
and
result
allocations
everything
it's
very
nice
that
kosa
actually
does
fit
extremely
well
within
the
bpsec
framework.
B
That's
already
in
place
and
part
of
what
this
is
gonna
do
is
it's
it's
adding
more
even
more
extensibility
to
to
bp
bpsec
that,
in
a
even
in
a
tightly
constrained
environment,
there
are
abilities
to
use
pki
with
cos
a
that
are
already
in
practice
and
in
use
in
other
applications,
and
the
last
gain
is
really
that
the
cose,
as
an
active
working
group,
is
already
in
progress
of
standardizing
on
some
hybrid
public
key
encryption
and
post
quantum
cryptography
algorithms.
B
So
the
idea
here
is
that
one
context
would
be
given
for
both
bib
and
bcb
and
it's
the
type
identifiers
that
distinguish
the
different
uses,
and
this
is
how
kosa
already
operates,
that
there's
one
cose
structure
and
within
that
structure.
There's
a
differentiation
between
signing
mac,
behaviors
and
encryption.
Behaviors
and
cose
also
brings
with
it
the
ability
to
use
a
pki
environment
and
also
the
the
ability
to
transport
pki
secondary
information,
so
cos
a
itself
can
embed
things
like
x,
509
certificates
and
in
the
future
potential
other
certification
data.
B
Then
the
one
thing
that
cos
a
does
not
define
is
a
real
usage
profile.
Coset
is
fundamentally
a
container
for
security
data,
but
it
doesn't
give
you
a
tight
definition
of
what
belongs
in
a
coset
message,
and
so
part
of
this
document
is
defining.
How
do
you
put
a
cose
message
in
a
bp
sec
block
and
the
other
part
of
it
is
what
is
the
profile
with
which
the
cosa
is
supposed
to
be
used?
B
So
this
table
indicates
these
would
be
the
minimum
interoperability
requirements,
and
some
of
these
things
are
required.
The
symmetric
key
behavior
and
some
of
these
are
recommended
to
asymmetric
behavior.
Now
this
is
for
an
interoperability
profile.
This
doesn't
constrain
or
require
any
particular
network
to
use
any
of
these
algorithms
operationally.
This
is
just
saying
for
an
interoperability.
B
This
is
what
should
be
supported,
and
none
of
these
algorithms
would
be
surprising
to
anybody
who's
using
modern
pki
that
these
are
the
current.
I
would
say
state
of
the
art
of
of
current
pki
and
pki
over
x
509,
especially,
and
that
is
also
one
thing-
that
the
second
point
on
this
last
slide
is
that
the
main
benefit
here
to
a
network
operator
is
that
this
structure,
this
cose
messaging
behavior,
is
going
to
work.
B
This
is
purely
on
the
wire
how
to
get
that
information
embedded
into
a
bbsec
block,
so
this
document
hasn't
been
touched
in
a
while.
So
the
there's
a
at
least
one
known
change-
that's
needed
just
to
bring
this
security
context
into
alignment
with
the
rfc
9173.
B
B
There
are
some
secondary
questions
that
this
is
currently
not
a
working
group
document,
but
if
it
were
to
become
a
working
group
document,
then
we
would
need
to
deal
with
more
details
like
processing
requirements
beyond
bp,
sec
related
to
the
fact
that
when
you're
dealing
with
pki
environments,
there's
no
distinction
between
identifiers
and
identity,
that
is
authenticated
so
just
little
details
that
need
to
be
worked
out
for
interoperability
and
then
the
the
second
item
is,
is
really
about.
Are
there
additional
minimum
cose
header
contents?
B
So,
for
example,
s
mime
as
it
stands
right
now
does
have
a
minimum
that
is
more
heavyweight
than
what's
in
this
draft
document,
but
maybe
that's
not
really
necessary,
and
this
would
be
something
that
would
be
worth
taking
advantage
of
learning
from
the
s
mime
upkeep
working
group.
What
is
valuable
and
what's
not
valuable,
especially
in
a
large
environment
like
what
s
mime
has
to
support.
B
C
Right
just
to
jump
in
on
the
queue
with
my
chair
hat
off,
but
but
just
speaking
from
a
bp
sac
perspective,
I'm
a
I'm
a
fan
of
this
work.
I
think
that
the
you
know,
part
of
the
idea
behind
a
security
context
was
bpv7.
Networks
are
going
to
be
deployed
in
a
variety
of
different
ways,
and
the
security
context
is
the
mapping
of
the
block
level
fidelity.
C
That
bpsac
requires
to
the
underlying
environments
and
networks
where
we
will
be
running
bundles,
and
so,
if,
if
we
in
this
working
group
were
to
produce
a
context
that
tells
us
how
to
perform
this
block
level,
fidelity
in
a
pkix
environment
that
that
makes
a
lot
of
sense
to
me.
So
with
chairhead
off
a
big
fan
of
this
work
and-
and
it
would
be
nice
to
see
it
adopted.
B
Oh
and
and
it's
not
on
the
slide,
but
I
will
bring
up
that.
There
are
discussions
in
nasa
and
I
believe
in
in
ccsds
about
the
need
for
a
kind
of
a
interagency,
pki
type
type
of
thing.
Just
in
the
general
concept.
B
And
so
I
will
propose
that
this
is
adopted
by
the
working
group
and
whatever
needs
to
be
done
to
to
further
that
along.
A
B
You
want
to
move
on
yep.
The
next
topic
is
going
to
be
quite
short,
and
what
it
represents
is
the
idea
that
there
are
currently
applications
that
are
doing
processing
on
bpv6
and
b7
at
the
same
time,
in
the
sense
that
the
same
entity
is
is
processing.
Both
types
of
bundles
and
the
convergence
layers
are
currently
shared
in
these
entities
between
these
different
purposes
and
and
there's
not
a
well-defined
way
of
receiving
a
chunk
of
data
and
saying
this
is
a
ppv6
bundle.
B
This
is
a
bpv7
bundle
explicitly
and
so
in
in
v6
and
prior
the
version
has
a
specific
offset
v7,
because
it's
using
a
sebor
structure
and
because
it's
a
nested
structure,
it's
not
a
nested
offset
and
the
root
of
bringing
this
up
is
that
there
are
existing
tools
that
assume
that
a
bpv7
bundle
is
encoded
exactly
as
some
of
the
example
bundles
and
so
that,
if
the
example
has
the
version
at
offset
3
and
size
1
that
that
is
how
bundles
operate,
that
that
these
tools
will
break
when
they
are
given
bundles
that
are
still
conformant
to
bpv7.
B
But
don't
follow
the
same
assumptions
and
there's
also
separate
from
an
agent
that
is
processing
this
kind
of
data
there.
It
can
be
a
need
to
identify
a
byte
string
as
a
bundle
version
and
not
actually
have
to
process
the
full
bundle,
because
the
a
trivial
way
of
saying
how
do
you
differentiate
is
throw
this
chunk
of
data
at
a
v7
decoder
and
give
me
a
result
or
an
error,
throw
this
at
a
v6
decoder,
and
the
point
of
this
document
is
to
be
a
little
more
fine-grained
than
that.
B
There's
an
existing
document
that
defines
a
kind
of
a
trivial
mechanism
to
do
this.
But
again,
this
is
not
looking
at
it
from
maybe
an
operational
perspective
of
of
how
a
system
should
really
do
this.
So
there's
two
different
aspects
to
this
proposed
mechanism,
and
one
of
them
is
in
the
logical
sense.
How
do
you
distinguish
between
these
things?
So
the
good
news
is
that
the
two
encodings
actually
don't
have
any
collision
between
how
they
operate.
B
So
there's
an
unambiguous
way
of
of
doing
this
detection
and,
in
the
logical
sense,
the
general
purpose
algorithm
of
just
saying
treat
it
as
a
stream
of
sibor
content
and
do
a
certain
decoding
sequence
will
do
the
job.
So
that's
one
way
of
doing
it.
That
will
work.
In
any
case.
That's
the
the
general
purpose,
given
a
a
arbitrary
chunk
of
data
that
will
work.
B
That
method
will
work
but
part
of
what
would
be
what
could
be
beneficial
to
have
documented
are
some
optimized,
more
optimized
algorithms,
that
do
more
of
like
pattern
matching
type
behavior
and
if
you're,
in
a
network
where
you
know
that
bundles
are
going
to
be
produced
in
certain
ways
that
they're
always
going
to
use
deterministic
encoding
that
they're
always
going
to
to
have
certain
properties
to
them.
Then
we
can
do
things
in
a
more
optimized
way.
B
B
I'm
not
gonna
go
through
the
dock,
the
optimize
methods,
but
what
they
amount
to
is
doing
some
non-sebor
seaboard
decoding.
So
you
wouldn't
need
to
use
a
full-fledged
seaboard
decoder.
You
just
need
to
do
some
bit
operations
that
effectively
do
seaboard
decoding
and
then
the
optimize
two
method
is:
is
a
byte
string
pattern
matching
and
if
you're
in
a
if
you're
in
a
constrained
environment
and
a
fixed
encoding
environment,
you
can
use
pattern
matching
like
that.
B
So
this
is
not
yet
part
of
a
real
draft
document.
This
is
just
saying:
is
there
interest
in
this
kind
of
thing,
and
the
main
benefit
here
is:
is
interoperability?
The
the
point
is
just
to
make
sure
that
people
don't
create
tools
that
are
going
into
processing
a
received
chunk
of
data
that
are
going
to
fail
in
maybe
predictable
ways
that
we
can
try
and
avoid.
B
A
Brian,
I
think
really
interesting.
This
is
me
with
my
speaking
personally,
I
think,
a
a
short,
concise
informational
rfc
has
value
just
to
to
maintain
interoperability
that
isn't
that
half
the
purpose
of
the
itf,
so
there
is
v6
still
flying
literally
it's
worth
making
sure
this
decoder,
the
decoder
logic
is
consistent
and
that
we
can
point
implementers
at
best
practice.
I
think
there's
some
value
in
that.
I'm
watching
the
clock.
I'm
really
sorry
is
anyone
else
in
the
queue
with
comment
on
any
of
these
documents
go
ahead.
Joshua.
H
Hey
so
yeah,
this
is
joshua
deaton
over
here
at
marshall
space
flight
center.
In
regards
to
the
interoperability
for
v6
and
v7
stuff
for
our
implementation
of
dtnme
for
use
with
the
iss,
we
did
kind
of
follow
the
same
general
idea
since
we
were
starting
with
v6.
To
begin
with,
we
did
follow
the
path
of
verify
whether
v6
the
actual
encoding
for
saying
we're
using
v6
is
correct,
and
if
it's
not
then
check
if
it's
a
v7
bundle
and
if
both
fail,
it's
obviously
malformed
but
yeah.
H
This
is
definitely
something
that
at
least
we
think
there's
some
value
in
okay.
A
Great
joshua,
in
which
case
brian,
because
you're
now
over
time,
I'm
going
to
hand
swiftly
on
to
emery
about.
We
are
genuinely
going
to
have
to
have
two
sessions
next
time
we
never
seem
to
have
enough
time.
A
Let
me
share
emery's
slides
and
hand
over
sure,
so
emery,
you
should
see
a
little
sort
of
semi-transparent
overlay
to
allow
you
to
go
left
and
right.
How
long
have
we
given
you?
If
I
give
you
a
10
minute
countdown,
instead
of
your
15,
we
can
then
overrun
by
three
minutes,
as
we
do
with
everyone
else.
That's
okay!.
I
Okay,
cool!
Thank
you.
Yes,
I
see
the
slides.
I've
got
the
button
ready
to
roll,
and
I
will
make
it
make
it
short.
So,
first
off
just
to
kind
of
talk
about.
This
is
a
refresh
of
the
asynchronous
management
architecture.
This
falls
firmly
under
the
new
charter,
for
you
know
an
oam
architecture
and
solutions
to
meet
network
management.
I
So
just
want
to
talk
about
the
latest
updates
to
the
doc
and
ask
really
what
are
the
next
steps
to
move
this
forward,
since
this
is
the
informational
sort
of
motivation
for
why
we
need
the
network
financial
architecture
and
what
are
the
approaches
to
that?
So
with
that
said,
the
first
thing:
we've
renamed
it
to
dtn
management
architecture,
and
this
is
just
to
sort
of
be
more
in
alignment
with.
What
are
we
trying
to
solve
here
right?
So
the
new
document
is
posted
here.
I
It
maintains
basically
all
the
same
motivation,
design,
principles
and
concept
of
the
previous
document.
Just
a
little
bit
of
clarity
here
and
there,
the
main
focus
and
and
the
reason
for
the
renaming
is
this-
is
a
document
that
is
designed
to
address
challenged
networks,
I.e
the
delay,
tolerant
networks,
so
just
to
touch
on
some
of
the
things
that
kind
of
have
been
clarified
or
updated.
I
In
this
document
the
document
specifies
very
clearly
what
are
the
services
needed
by
a
dtn
management
architecture
and
one
of
the
desirable
properties
of
a
solution
that
meets
these
different
services.
So
I
called
out
a
few
here.
Most
of
these
were
the
same,
but
I
called
out
a
few
here
so
authorized
administration,
accounting
and
error,
control,
asynchronous
dynamic,
hydrological
architecture,
model
derived
and
hierarchically
organized
definition
of
information.
I
I
call
these
out
because
they
are
new
sections,
but
they
just
are
there
to
try
and
further
emphasize
you
know
the
scope
and
then
in
the
need
of
this
management
solution,
so
to
touch
on
a
few
of
those.
This
is
sort
of
triple
a.
I
mean
one
of
the
design
criteria.
You
see
this
across.
Almost
every
network
management
solution
is
the
need
to
authorize
those
controls
that
reporting
that
are
coming
into
the
network
management
solution,
because
this
has
to
be
built
on
top
of
dtn.
I
You
know
handshake
to
set
up
these
commands,
but
there
is
a
need
to
do
that
so
a
section-
and
there
was
verbiage
all
throughout
the
document
kind
of
talking
about
this
already,
but
I
think
it
deserved
a
section
that
really
described
that
need
up
front,
so
this
new
section
that
states
that
in
asynchronous
dynamic,
highly
logical
architecture,
so
this
really
speaks
to
the
need
to
operate
within
dtn
thinking
kind
of
in
the
back
of
the
vine.
How
does
a
bundle
protocol
work?
I
How
does
bp
sec
work
so
we're
trying
to
say
here
that
the
concept
of
this
topology
is
very
dynamic.
The
the
roles
assumed
within
the
network
can
evolve
over
time.
In
fact,
as
a
message
moves
from
a
you
know,
sender,
to
a
destination,
a
new
destination
may
assume
that
logical
role
right
so
so
we
still
need
to
deliver
that
too.
I
In
the
case
of
a
network
management,
a
manager,
but
that
manager
might
have
changed
in
addition,
there
might
be
multiple
managers,
either
coordinating
or
working
with
a
receiving
ports
to
a
single
agent.
So
we're
trying
to
call
that
out
up
front
and
say
that
there's
a
need
for
this
sort
of
logical
architecture.
I
I
You
know
that
we
talk
a
lot
about
autonomy
in
this
model,
which
autonomy
has
often
performed
in
other
in
other
working
groups
or
in
other
solutions,
as
a
very
much
sort
of
back
and
forth
interaction
between
those
managed
elements
and
and
the
managers
to
achieve
autonomy
in
a
dtn
management
solution.
I
We
very
much
need
a
model
driven
approach
and,
furthermore,
it
needs
to
support.
You
know
compression
and
there's
very
various
different
ways.
You
can
approach
compression,
so
a
hierarchy,
I
can't
speak
organized
model,
driven
approach
should
give
means
to
some
of
that,
and
I
think
a
lot
of
these
things
that
I'm
talking
about
feed
right
into
the
approach
of
amp
and
the
data
models
that
support
network
management
as
they've
been
being
implemented,
worked
and
discussed
this
working
group
for
some
time.
I
So
a
few
other
minor
updates
this
one
here
simply
just
walks
through
the
roles
and
responsibilities
of
an
agent
and
a
manager,
the
agent
being
the
thing
that
you're
going
to
manage,
whether
it
be
you
know,
the
applications
behind
the
space
vehicle,
the
protocols
that
are
managing
the
network
on
the
space
vehicle,
as
well
as
the
manager,
the
the
node
that
is
ultimately
sending
messages
to
those
agents
and
receiving
reports
from
those.
I
So
just
a
little
bit
of
clarity,
kind
of
walking
behind
exactly
what
is
the
role
and
the
responsibility
of
each
one
of
these
of
these
roles,
and
then,
lastly,
we
have
to
do
some
pictures
in
the
back.
I
think
to
stress
a
little
bit
that
this
is
indeed
a
solution
for
a
challenged,
challenged
network
management
solution.
I
So
first
picture
kind
of
said:
hey
look
agent
b
here
might
lose
connectivity
for
some
time,
even
though
it's
generating
reports
to
send
back
to
the
manager,
it
still
is
going
to
generate
those
reports
and
it
will
deliver
them
asynchronously
at
a
future
point
in
time.
So
it
just
calls
that
out
in
this
picture
here
the
next
picture,
there
is
a
statement
that
the
the
agent
should
try
and
compress
and
combine
messages
where
possible.
I
These
get
the
working
concert
to
one
another,
and
the
last
update
to
picture
here
is
showing
this
multiplex
management
between
fusion
between
potentially
two
managers
that
are
both
controlling
the
same
or
multiple
agents.
How
are
they
communicating
to
one
another?
How
are
they
fusing
data
and
passing
it,
and
this
goes
back
to
like,
I
said,
the
clarity
of
the
roles
of
those
logical
agent
and
manager.
So.
I
To
speak
to
specifically,
okay,
using
that
definition
of
the
the
responsibilities
of
each
it
tries
to
address
that.
So
my
questions
to
the
working
group,
first
and
foremost,
what
is
needed
to
finish
this
architecture?
What
is
missing
what's
wrong?
I
We
would
like
to
move
this
forward,
so
that's
the
the
open
question
right
and
then
what
are?
Are
there
any
accompanying
documents
that
need
to
go
with
this
one,
so
I'll
pause
for
a
brief
minute
before
I
give
my
second
section
and
ask
I
see
ed's
hand
up.
C
So
ed
with
my
chair
hat
off
is
is
to
make
an
observation
which
is
at
the
beginning
of
this.
We
mentioned
that
this
document
had
been
renamed
from
the
asynchronous
management
architecture
to
the
delay,
tolerant
network
management
architecture
and
one
of
the
observations
there
was
the
term
asynchronous
caused
some
confusion,
asynchronous
as
it
as
it
be,
as
we
use
it
in
in
very
challenged.
Networks
like
a
dtn
architecture
mean
that
the
transport
layer
is
asynchronous
that
you
may
have
unidirectional
links.
C
You
may
have
long
periods
of
time
without
being
able
to
communicate
end
to
end.
However,
another
use
of
asynchronous
means
not
holding
session
state
and
perhaps
just
using
rest
restful
interfaces
over
tcp.
C
So
one
of
the
one
of
the
things
that
has
to
be
done
in
this
management
architecture
is
to
really
differentiate
the
fact
that
asynchronous
is
asynchronous
all
the
way
down
to
the
transport
layer
requiring
that
level
of
autonomy
when
we
get
to
that
point
and
how
we
use
those
those
autonomy
models,
the
work
is
is
unique.
So
as
long
as
we
maintain
that
focus
of
asynchronicity
all
the
way
down
to
the
transport
layer
that
that
needs
to
be
there
so
with
that
I'll,
that
was
just
a
comment,
not
a
question.
H
Hey
so
this
could
be
something
that
I
may
have
just
missed,
because
it's
been
a
little
while,
since
I've
done
a
true
deep
dive
of
some
of
these
documents.
But
does
this
the
current
state
of
the
standard
cover
a
situation
for
handling
reports
that
have
not
been
able
to
be
sent
for
extended
periods
of
time
per
se
so,
like
obviously,
the
nominal
situation?
Is
that
even
if
there's
been
a
delay
and
you
weren't
able
to
send
it
right
away
that
it'll
still
try
and
send
the
next
opportunity
that
it
has.
I
So
I
others
might
have
comments
on
this,
but
I
think
the
standard
doesn't
have
an
answer
for
that
or
the
proposed
document
doesn't
have
an
answer
for
that.
However,
I
think
that
can
be
accomplished
a
little
bit
separately
so
that
the
concept
of
the
logical
data
model
that
describes
you
know
the
rules
associated
with
the
generation
or
or
frequency
of
reporting.
I
think
personal
preference
here
that
maybe
we
should
have
a
capability
to
apply
policy
to
those.
I
So,
in
the
case,
like
you
just
described,
maybe
there's
a
system
level
policy
which
would
be
supported
by
an
additional
data
model
that
says:
okay,
the
lifetime
of
this
delete
after
a
certain
time
or
when
storage
gets
above
this
threshold
deep
delete
things
that
are
there
older
after
this
time.
B
I
Is
sets
us
up
for,
like
I
said,
the
motivation
for
that
challenge.
Network
management
need
for
that.
Logical
data
model
leave
need
for
autonomous,
driven
but
deterministic
behavior,
which
we
can
then
add
what
you
just
described.
A
I'm
gonna
jump
in
at
this
point:
it's
rick
with
my
chair
hat
on
first
off,
because
I'm
watching
the
clock,
so
I
think
to
answer
the
question
on
the
screen
I
think
having
this
is
an
arc
and
also
to
answer
that
previous
question.
This
is
an
architectural
document,
and
so
I
think
it
should
be
able
to
proceed
without
any
accompanying
documents.
A
The
accompanying
documents
can
come
after
that's
commonly
how
how
one
does
architectural
documents
in
the
ietf,
so
I
politely
request
working
group
participants
to
go
away
and
re-read
this
document
it
has
changed
noticeably
and
from
my
reading
is
a
huge
improvement.
So
thank
you,
emery
and
the
rest
of
the
team.
Who've
worked
on
this.
A
Please
reread
please
review
and
let's
see
whether
we
can
really
make
some
progress
on
this
as
an
architectural
document
from
which
we
can
start
to
hang
off
the
accompanying
documents
and
address
questions
like
like
joshua's
and
get
into
the
depths
of
data
models
and
protocols
and
policies
and
all
this
kind
of
stuff.
Does
that
sound,
reasonable,
yeah
good?
So
I'm
conscious
that
sarah
got
bumped
out
from
iutf112
and
I
really
wanted
to
have
an
opportunity
to
present
what
she
tried
to
present
last
time.
So
if
there's
nobody
else,
thank
you
very
much.
I
Yep
roger
did
you
want
me
to
go
through
just
real
quick
and
let
me
do
this
real
quick.
There
is
some.
There
is
some
additional
information
to
the
slides.
There
is
a
new
document.
It's
right
now,
a
sort
of
personal
document
saying
we
need
to
have
a
method
to
name
resources
in
the
application
models.
I
So
my
question
I'll
kind
of
jump
forward
to
this,
and
I
think
this
needs
to
work.
My
question
here
is:
is
this
the
sort
of
thing
that
the
working
group
is
interested
in
and
then
you
know
what
are
the
next
steps
to
kind
of
move
that
forward?
So
we
can
take
that
offline,
so
we
can
just.
A
Chair
again
as
chair,
I
think
this
is
within
scope
of
the
the
working
group
charter.
I
think
you
should
push
this
out
as
a
personal
draft.
A
I
think
you
should
draw
attention
to
it
and
garner
interest
on
the
mailing
list
and
what
we're
going
to
have
to
have
two
sessions
at
the
next
ietf,
because
we
have
so
much
content
we'll
have
a
proper
dive
into
it
and
if
you
get
sufficient
review,
we
go
for
working
group,
adoption
et
cetera,
et
cetera,
but
let's
separate
the
track
of
that
kind
of
thing
from
the
progress
on
the
architecture.
Ed,
are
you
agreeing
or
disagreeing.
C
I
I
am
agreeing
this.
They
should
eventually
come
into
the
fold,
but
let's
go
on
to
sarah.
A
Yeah
perfect
thanks
very
much
emery.
I
will
stop
revoke
your
permission.
This
slide
thing
is
almost
very
clever.
Dude.
K
Yes,
okay,
cool
okay.
So
if,
if
you
all
remember
last
time
I
presented
about
the
asynchronous
network
management
system,
this
is
a
network
management
system.
We
are
creating
to
be
able
to
operate
the
the
dtm
protocols
beside
terrestrial
networks.
So
next
I
have
a
quick
overview
again.
These
you
probably
saw
these
slides
last
time,
so
the
the
goals
of
ams
are
to
enable
missions
to
be
able
to
use
the
disruption,
tolerant
networks,
help
people
use
amp
and
be
able
to
adopt
amp
and
also
serve
as
the
baseline
for
the
amp
specification.
K
K
So
here
quickly
is
what
our
layer,
one
decomposition,
looks
like
so
at
a
very
high
level
that
blue
pill
shape
in
the
center
is
a
mms.
We
want
to
enable
connections
to
other
machines
on
the
terrestrial
network,
as
well
as
connections
to
agents
in
the
the
space
networks
and
then
allow
mission
operators
to
have
some
default
visualizations
into
the
system,
as
well
as
be
able
to
do
some
command
and
control
from
or
through
a
ms.
K
The
the
ams
services
include.
You
know
normal
services
that
you'd
see
in
a
network
management
system
such
as
you
know,
data
management
and
service
and
storage,
health
and
status,
monitoring
et
cetera,
but
then
also
agent
command
and
control
through
amp,
and
we
are
also
aiming
for
a
ms
to
be
incredibly
containerized
and
modular,
so
orchestration
of
the
internal
amms
systems
and
then
also
ability
to
plug
in
your
own
systems
whenever,
whenever
it's
useful.
K
So,
for
example,
if
you
have
your
own
visualization
tool
that
you'd
like
to
bring
into
anms,
we
want
to
have
the
standard
interfaces
and
the
modular
system
to
allow
you
to
bring
that
in
instead
of
using
our
default
visualizations,
so
that,
hopefully,
was
a
review
of
what
I
went
over
last
time
and
now
the
news
is,
we
do
actually
have
our
first
spiral
of
amms
complete
and
are
ready
to
release
it
open
source,
I
would
say
within
a
month
or
so-
it's
just
going
through
the
review
process.
K
At
this
point,
I
do
have
it
running
in
the
background,
but
in
the
interest
of
time,
I'll
just
flip
through
these
pictures
we
have
of
it.
So
this
is
our
welcome
screen
along
the
top.
We
have
a
few
different
tabs
that
we
want
to
build
out
in
the
future.
In
our
current
version
of
amms.
We
have
built
out
this
monitor,
tab,
the
agents,
tab
and
the
messaging
tab
and
I'll
go
through
those
in
a
second.
The
network.
Tab
would
show
the
second
one
there
would
show
like
a
network.
K
Topology
alerts
would
be
alerts
from
agents
and
system
management
on
the
end
would
be
in
the
future
things
like
health
monitoring
of
ams
itself,
but
going
through
the
ones
that
we've
built
out
so
the
monitor
tab.
This
is
showing
grafana
plugins
for
various
variables
within
our
system.
So
on
the
top
left
you
can
see,
this
is
actually
pulling
variables
from
the
bp
agent
full
report
and
displaying
them
in
this
in
this
field.
K
The
one
we've
picked
for
this
one
specifically
is
num
and
cust,
which
is
the
number
of
bundles
in
custody
for
the
agent.
So
here
you
can
see,
we've
been
getting
reports
from
agent
from
an
agent
on
our
network
and
are
able
to
display
that
variable
for
for
users
of
the
system
below
that.
Actually,
in
the
middle,
you
can
see
all
the
reports
that
have
come
in
in
kind
of
their
raw
form
and
then
on.
The
top
right
is
the
message
group
per
minute,
which
is
really
just
a
message
rate.
K
So
how
many
you
know
reports
have
we
gotten
in
in
the
past
minute
right
now.
I
think
in
this
graphic,
there's
only
there's
only
one
agent
on
the
network,
but
we
have
run
this
with
two
and
you
know
you
can
see
the
difference
between
the
two
and
you
know:
compare
statistics
between
agents.
K
K
So
next
slide
is
oh
zooming
in
on
what
I
just
mentioned,
so
right,
number
of
bundles
in
custody
on
the
on
the
left
side
and
the
message
rate
on
the
on
the
right
hand
side.
K
But
here
we
have
the
agents
tab.
So
this
one
is
showing
the
agents
on
our
network,
and
this
is
where
we
can
actually
control
agents.
So
we
can
send
them
commands
and
we
can,
you
know,
receive
reports
from
them
as
well.
K
So
at
the
bottom
you
manage
agents
on
your
network
if
you
expand
that
this
is
what
it
looks
like
and
this
this
may
be
a
little
bit
small,
but
the
rather
cool
new
feature
that
we
added
recently
was
that
you
can
now
automatically
construct
time-based
rules
here
to
send
to
agents.
So
if
you
select,
you
know,
start
time
period
count
and
then
you
can
pick
a
report
to
ask
the
agent
to
push
back
to
to
your
management
server
on
the
period
specified.
K
Then
you
can.
You
can
start
populating
data
and
displaying
that
in
the
grafana
pages
that
I
showed
previously
so
right
now.
This
is
supported
for
the
reports
that
you
see
on
the
screen
there.
The
ltp
agent
enterpoint
report,
the
bpage
endpoint
report,
bp
agent,
full
report
and
amp
agent
full
report,
but
the
the
really
nice
thing
is.
This
allows
you
to
send
these
commands
without
having
to
get
to
construct
them
yourself.
You
don't
have
to
construct
cbore,
you
don't
have
to
construct
res
it
just
automatically.
K
Does
it
for
you,
so
just
an
example
of
some
user-friendly
options
coming
in
the
future.
The
less
user-friendly
way
of
doing
this.
You
can
see
below
that.
Actually,
you
can
send
raw
commands
so
that
other
text
box
at
the
bottom
there
is
you-
can
just
send
the
seaboard
command
to
the
agent
and
it'll
execute
that.
So,
if
you
just
wanted
a
single
report,
you
could
construct
that
command
and
and
send
it
and
receive
the
report
back
on
the.
K
So
I
believe
this
is
my
last
slide.
So
this
is
the
messaging
tab.
The
messaging
tab
right
now
will
help
you
construct
those
commands
if
you,
if
you
want
to
send,
send
one
of
your
own.
So
here,
if
you
input
a
string
re
then
it'll
parse
that
out
it'll
show
you
what
the
c
bar
is
for
that
string.
It'll
parse
it
out
into
json
on
the
there's
a
tab
there
that
will
also
construct
a
uml
diagram
of
what
it
looks
like,
and
it
can
do
the
same
for
seabor
as
well.
K
So
if
you
put
in
a
seabor
command,
it'll
parse
it
out
and
show
you
all
the
same
data
so
really
quickly.
That
is
what
a
ms
looks
like
right
now
in
a
nutshell.
We
are
really
excited
to
get
this
out
into
the
community
and
to
start
getting
feedback,
and
so
hopefully
it'll
be
there
soon
and
we'll
hear
from
all
of
you
have
any
questions.
A
Thank
you
very
much.
Sarah!
That's
really
cool!
It's
really
nice
to
see
this
stuff,
starting
to
run.
It's
really
nice
to
see
this
as
as
slightly
more
than
a
draft.
We
don't
normally
do
show
and
tells
at
the
itf,
but
this
was
very,
very
worthwhile.
It's
just
to
demonstrate
this
is
this
is
getting
beyond
the
concept
phase,
which
is
is
great.
So
thank
you.
Anyone
else
got
any
questions
on
this
at
the
moment.
I
know
people
were
asking
on
the
chat
about.
Oh
can
we
play
with
it?
A
What's
it
like
and
and
ed's
chimed
in
to
answer
some
of
that,
I'm
assuming
you
can
hear
me
because
I
keep
getting
a
pop-up
saying
your
audio
isn't
working
cool,
in
which
case
I
am
going
to
because
I'm
watching
the
clock,
I'm
going
to
grab
the
slides
and
I'm
going
to
jump
straight
on
to
my
presentation.
Thank
you
again.
Sarah.
A
I
have
a
very
quick.
He
says
in
advance,
I'm
going
to
turn
my
camera
on.
So
you
can
see
me
so.
I've
got
a
very
shortish
presentation,
asking
three
questions
about
endpoint
ids,
so
in
classic
form,
I'm
still
trying
to
chase
down
more
detail
and
drill
into
naming
and
addressing,
but
I'm
tackling
naming
first.
So
a
quick
review
and
I've
stolen
this
slide
from
the
a
similar
presentation
I
did
at
ietf112.
A
So
this
is
an
analysis
of
what
rfc
9171
tells
us
about
endpoint
ids.
So
the
critical
thing
is
they
are
a
pair,
so
that
is
the
schema
and
then
some
content,
which
is
defined
by
that
schema
and
9171,
defines
two
schemas.
The
ipn
schema
and
the
dtn
schema
an
important
other
consideration
and
I'm
not
going
to
go
into
it
in
too
much
depth
at
the
moment.
Because
of
time
is
there
is
a
multiplicity
associated
with
an
end
point,
so
you
can
have
the
the
null
endpoint,
which
is
is
nowhere.
A
A
In
fact,
I
I
may
even
have
some
answers
to
some
of
these
questions
question
one
if
the
dtn
schema
is
for
universal
use
and
the
reason
I
say
it's
for
universal
use
and
I'll
jump
back.
One
slide
because
I
missed
this
detail-
is
that
the
dtn
schema.
A
A
F
I
mean
to
interrupt
you,
please
go
ahead.
I
was
only
I'll
respond
to
the
slide
before
that
said
that
there's
no
queuing
of
multiplicity
in
these
things-
and
actually
there
is
the
ipm
schema-
is
specifically
always
singleton.
Endpoints.
A
Yes,
yeah,
I
I
think
I
draw
draw
that
out,
but
it's
it's
it's
kind
of
hit.
That
was
a
kind
of
a
passing
point
and
I
don't
actually
want
to
drill
into
multiplicity
too
much.
It
was
mostly
that
slide
was
stolen
from
a
previous
presentation
and
had
some
points
about
multiplicity,
but
that's
most
relevant
at
the
end,
but
point
taken
so
my
second
question
is
given
the
ipn
schema
is
restricted
and,
as
scott
pointed
out,
you
know
they're
unicast
only.
A
What
should
the
working
group
recommend
for
its
usage,
because
it
certainly
has
value?
It's
very
condensed.
It's
very
concise,
et
cetera.
So
I'm
going
to
try
and
address
that.
Oh
I'm
going
to
talk
around
that
question
and
the
third
question
which
both
ed
and
I
and
various
other
people
get
asked
is:
are
these
two
schemas,
the
only
two
schemers
out
there
and
groups
like
ccsds,
sana,
ipm
sig
are
asking
questions
such
as
well?
How
do
we
use
these
dtn
ids?
Who.
B
A
The
global
registry
for
these
things
can
we
set
up
our
own
global
registry.
What
should
we
do
about
problem
x,
problem
y
or
perceived
problem
z,
and
so
I
also
address
that
because
endpoint
ids
are
this
combination
of
schema
and
content,
and
we
have
only
currently
defined
two
schemas.
I
shall
answer
that
as
part
of
question
three.
So
question
number
one
external
use
of
the
dtn
schema
so,
as
I
said
before,
the
schema
is
registered
in
the
uri
schemes
registry,
which
implies
they
are
available
for
universal
user
agents.
A
A
Oh
sorry,
that's
the
next
slide,
so
you
resolve
into
the
name
in
the
demarks
according
to
the
rules
in
91
71,
and
you
then
transmit
that
uploaded
file
content
using
something
that
you
have
some
information
you
have
derived
from
that
name.
Resolution
9171
quite
correctly
doesn't
say
anything
more
about
that
because
it's
the
wrong
document
to
do
so.
A
So
I
propose
the
following,
and
this
is
contentious
and
I'm
very
happy
for
people
to
step
to
the
mic
and
shout,
but
I
might
ask
you
to
hold
for
a
second
when
a
dtn
url
is
accessed
externally,
for
example,
using
something
like
the
curl
tool.
If
someone
was
to
write
an
extension
to
curl,
then
the
uri
is
parsed
according
to
the
rules
in
9171
into
its
name
in
its
dmax,
and
this
is
the
contentious
bit.
The
name
component
is
then
resolved
using
global
using
dns.
A
A
Example
that
curl
command
takes
performs
the
following
operations:
it's
saying:
send
that
bundle,
protocol
version,
7
bundle
with
the
content
of
file1
as
payload
to
that
destination,
which
is
schema
type
1,
dtn.org
some
service
in
some
services,
the
dmx
part
using
a
tcp
lcr
the
tcpclv4
session,
I'm
going
to
make
that
acronym
shorter
to
the
agent
at
that
resolved
address.
Please
don't
ping
that
address,
I'm
not
entirely
sure
where
it
is.
Obviously
you'll
need
some
other
options
to
set
some
of
the
primary
block
headers.
A
A
A
C
Well,
what
I
would
suggest
is
that
this
is,
of
course
something
we
need
to
address.
Can
we
start
some
posts
on
the
mailing
list
and
perhaps
entertain
an
interim
meeting
to
jump
into
some
of
these
topics
in
more
detail.
A
Yes,
absolutely
I'm
quite
happy
to
take
that
to
the
list.
What
I'll
do
is
I'll
skip
very
quickly
over
the
second
slide
and
leave
it
on
the
third
joshua
thanks.
C
A
A
Yeah,
okay
ipn
scheme-
I
am
proposing
that
it
is
used
internally
for
autonomous
regions.
That's
got
introduced,
so
it's
effectively
a
like
a
landscaped
address
and
this
is
an
important
slide
for
the
ipn
sig
guys.
I
have
pointed
them
at
this
before.
If
you
wanted
to
find
your
only
id.
This
is
how
you
do
it
document.
It
request
a
new
bundle.
Protocol,
uri
type
scheme,
number
you're
there
you're
compliant,
so
that's
it
I'll.
Stop.
C
That's
fine,
why
don't
you
project
the
slide,
I'll,
ask
a
question
and
then
we'll
take
it
to
the
mailing
list,
which
I
think
is
appropriate
and
the
the
question
really.
The
fundamental
question
that
I
have
is
in
going
back
and
looking
at
rfc
4838,
which
was
published
in
april
of
2007,
based
on
and
seeing
some
of
the
work
in
dtn
rg.
We
laid
out
what
the
dtn
architecture
is.
I
well
I
didn't,
but
the
d10
architecture
was
laid
out
in
in
this
way.
C
My
question
to
the
working
group
is:
do
we
feel
that
our
implementation
experience
with
bpv6
changes
to
bpv7
and
some
of
the
work
that's
happening
now
with
network
management,
with
security,
with
quality
of
service,
with
custody,
transfer
and
so
on?
Is
it
time
to
refresh
this
document,
and
that
is
a
question
out
to
the
working
group
for
anyone
that
wants
to
simply
make
a
statement
here
about
it
or
take
opinions
as
to
whether
we
need
to
refresh
4838
to
the
mailing
list?
C
And
with
that,
we
are
at
the
two
hour
mark.
I
just
like
to
say
this
is
wonderful
to
have
the
first
dtm
working
group
meeting
after
having
our
first
four
rfcs
published,
there's
a
tremendous
amount
of
work.
As
you
can
see,
we
really
did
run
out
of
time
quite
quickly
and
we
should
start.
We
should
start
planning
an
interim
meeting
now
and
then
also
perhaps
have
additional
time
at
the
next
ietf
114,
which
perhaps
will
be
all
in
person.
A
But
I
also
add
thank
you
very
much
all
the
contributors.
Thank
you
very
much
for
attendees,
I'm
going
to
keep
talking
and
communicating
on
chat
until
meet
echo
shut
us
down
because
we're
so
compressed
ed
and
I
were
talking
offline.
I
think
we're
going
to
ask
for
two
sessions
next
time,
because
we
always
seem
to
run
out
of
time,
although
we
are
on
paper,
quite
a
small
group,
there's
a
huge
list
of
there's
a
huge
set
of
attendees
on
here,
a
lot
of
remote
participants,
and
I
think
we
have
more
work.
A
We
can
do
at
the
the
next
atf
as
well
as
in
between.
So
thank
you
very
much
for
your
attendance
and
your
good
questions.
A
B
A
I
I'm
I'm
still
typing
rapidly
in
the
chat,
but
I'm
going
to
close
my
mic.
Thank
you
very
much.
I
think
the
meeting
is
over.
J
I
will
be
grabbing
the
chat
window
at
the
very
last
second
and
throughout.
A
Good
plan
and
thank
you
very
much
adam.
I
had
a
a
chance
to
glance
at
the
at
the
minute,
since
they
were
going
past
great
stuff.
As
usual,
those
will
be
published
as
meeting
minutes
as
ever
and
as
usual,
the
itf
will
turn
this
into
a
a
youtube
video
much
to
my
embarrassment
at
some
later
dates.
So
you
can
listen
to
the
recording
as
well,
probably
focusing
on
the
on
the
great
presentation
by
vint,
so
yeah
brilliant.
Thank
you
all
very
much,
particularly
those
in
the
room.