►
From YouTube: IETF114 DTN 20220726 1400
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
A
Yes,
I'll
take
that
as
a
scene
good
morning
ed.
How
are
you
today
better
good,
so
just
just
as
a
little
bit
of
background.
Ed
was
hoping
to
be
here
in
person,
but
due
to
the
vagaries
of
covert,
he
will
be
remote,
which
is
unfortunate
for
some
of
us
who
wanted
to
say
hello
to
him,
but
it
sounds
like
you're
better
well,
definitely
on
the
mend
by
the
center.
A
So
we
don't
have
a
great
number
of
people
in
the
room,
but
we
have
a
fair
amount
of
people
online,
which
is
great.
Am
I
close
enough
to
the
microphone
just
an.
A
Pretend
this
is
some
kind
of
like
community
disco,
wedding
thing:
okay,
I'm
not!
I
promise
not
to
sing,
so
I
think
we
should
start
because
we're
a
little
bit
late
already.
We've
got
a
few
people
in
the
room,
but
we've
got
quite
a
few
people,
dialed
in
which
is
great
to
see.
Just
as
can
I
make
these
slides
move
through
there
we
go,
so
I
will
start
the
session
by
just
talking
about
the
note
well
and
ed.
A
A
This
is
also
available
online
for
your
reference,
but
the
long
and
short
of
it
is
this
anything
you
say
at
the
microphone
or
within
the
chat.
Is
a
disclosure
so
be
very
careful
about
any
ipr
you
wish
to
discuss
because
you
are
disclosing
it
and
making
it
public
as
you
do
so.
The
fine
details,
I
am
not
a
lawyer-
are
carried
in
the
various
pcbs.
A
I
recommend,
if
you
are
uncertain,
to
read
this
carefully
and
ensure
that
you're
not
going
to
make
some
terrible
mistake
and
get
in
trouble
with
your
sponsors
lawyers
moving
on
meeting
tips,
so
most
of
you
have
already
managed
to
dial
in
remotely
so
which
is
great
to
see.
I
don't
know
how
you
get
to
see
this
if
you
are
struggling
to
get
in,
but
they
are
available
through
the
data
tracker.
So
I'm
assuming
those
people
are
struggling
to
get
in
can
find
the
information
on
how
to
get
in
in-person
participants.
A
Can
we
request
that
you
use
the
in-person
tool
it's
great
on
a
phone?
There
are
qr
codes,
liberally
scattered
around
the
room.
If
you
scan
that
it
will
take
you
straight
to
the
relevant
meeting
in
person
tool
which
allows
you
to
put
your
hand
up
and
join
the
queue
and
therefore
we
have
one
queue:
synchronized
between
remote
participants
and
in-person
participants,
which
is
great,
also
try
and
mute
your
microphone,
let's
try
and
avoid
the
embarrassing
feedback
and
all
that
kind
of
stuff
you
get
with
remote
participation.
A
But
after
two
and
a
half
years
of
covid,
I
think
we're
all
pretty
savvy
with
dialing
into
meetings.
A
Next
up
for
those
of
you
who
can
only
access
the
slides
and
can't
hear
me,
there's
not
much
point
be
saying
this,
but
the
agenda
is
visible
through
the
data
tracker.
That's
the
url
for
it
important
information
on
how
to
join
the
meet.
Echo
seems
a
little
bit
ironic
to
show
it
through
me
tako,
but
it's
there
and,
most
importantly,
if
you
are
struggling
with
meet
echo,
there
is
the
url
for
how
to
get
fixes
for
it.
A
A
If
you
are
struggling
with
video
or
audio
so
moving
on
our
agenda,
we
originally
asked
for
two
sessions
one
hour
and
followed
by
a
two
hour
session,
because
in
discussion
between
ed
and
myself
and
various
others,
it
was
felt
that
it
would
be
productive
to
have
a
more
of
a
working
meeting
to
talk
around
the
very
broad
topics
of
naming
and
addressing,
I
think,
between
many
of
the
participants
in
the
working
group,
we're
starting
to
condense
around
some
basic
ideas
around
naming
and
addressing.
We
don't
have
any
drafts
in
progress
on
this.
A
It
would
be
great
to
get
some
drafts
here,
but
before
somebody
really
puts
their
neck
out
and
starts
writing
an
extensive
draft,
I
think
there's
some
general
nervousness
about
understanding
the
full
scope
and
where
everyone
else
is
is
thinking.
So
the
idea
originally
was
we'd
have
a
one-hour
session
just
to
talk
through
the
status
of
the
documents
we've
got
and
then
a
two-hour
workshop.
Unfortunately,
we
were
unable
to
get
both
sessions,
so
we
are
compressing
it
into
one
session
today.
A
So
the
idea
is,
we
will
go
through
the
various
documents
and
some
questions
to
the
working
group
from
the
likes
of
keith,
scott
and
ccsds,
and
scott
burley
will
also
be
talking
through
his
thoughts
about
naming
and
addressing
and
what
he's
collated
from
his
conversations
with
interested
parties,
and
that
should
kick
into
the
namibian
addressing
workshop,
which
we
will
reserve
the
second
hour
of
the
session
for
minus
five
minutes
of
open
mic
at
the
end.
So
what's
next
okay,
so
we
always
need
a
minute
taker.
A
Adam's
put
his
hand
up
already
for
those
who
can't
see,
but
it
is
a
shared
note-taking
system.
It's
integrated
into
meteco,
it's
pretty
good.
Please
don't
just
rely
on
adam
to
do
all
the
typing,
because
that's
a
bit
unfair
and,
most
importantly,
when
you
state
your
name
at
the
microphone,
if
adam
has
missed
it
and
misspelled
your
name
or
has
misquoted
you
just
just
double
check.
He's
got
that
right,
because
people
talk
fast
and
people
get
excited,
hopefully
other
reference
mailing
lists.
A
B
No,
so
I
can,
I
just
want
to
make
sure
you
you
can
hear
me.
Okay,
my
volume
is
all
right.
B
No,
I
think
that's
a
good
intro,
I'm
sorry,
I
couldn't
be
there
in
person,
and
I
just
wanted
to
take
a
moment
and
and
talk
a
little
bit
about
the
ccsds
and
the
sis
dtn
working
group,
and
maybe
we
can
use
that
as
a
roll
into
our
first
set
of
presentations
and
and
discussion
topics
so
for
the
for
those
in
in
the
ietf
who
are
unaware.
B
The
ccscs
is
the
consultative
committee
for
space
data
systems
and
it
is
a
standards
organization,
a
peer
standards
organization
that
that
builds
standards
for
space
and
in
in
that
organization.
There
is
also
a
dtn
working
group
chaired
by
keith
scott,
who
is
here
today.
B
One
of
one
of
the
topics
of
conversation
in
areas
of
overlap
in
these
two
working
groups
is
how
much
of
the
dtn
ecosystem
and
the
dtn
architecture
is
shared
across
space
and
terrestrial
use
cases,
and
what
pieces
of
this
are
specific
to
space
constellations,
deep
space
and
near
space
exploration
versus
those
that
are
more
general
purpose
and,
as
you
can
imagine,
when
we
start
talking
about
in
pieces,
naming
and
addressing
quality
of
service,
resiliency
custody
transfer
and
so
on.
There
are
questions
relating
to.
B
B
To
that
end,
there
is
discussion
about
how
much
of
the
standards
are
done,
100
in
the
ietf
as
rfcs
versus
what
pieces
are
done
in
the
ccsds
as
as
books.
So
sorry
for
that,
every
primer-
maybe
that's
already
known,
but
maybe
not
everyone
online-
is
familiar
with
the
ccsds.
B
But
to
that
end,
ucsds
asked
if
they
could
come
to
this
meeting
and
spend
10
or
15
minutes
and
talk
through
some
of
the
areas
that
they
believe
exist
in
an
overlap
and
to
understand
from
a
working
group
perspective
here
in
the
ietf,
whether
we
agree
or
disagree
with
with
some
of
that.
B
So
without
his
introduction
I
would
invite
keith
scott
to
join
in
and
we
can
start
sharing
his
presentation,
slides
and
start
his
set
of
discussions.
A
Yes,
give
me
30
seconds
to
just
queue
up
the
next
set
of
slides
through
meet
echo.
It's
normally
right.
It
always
takes
me
a
moment
to
find
the
right,
slides.
C
Cool
so,
while
you're
doing
that
some
sort
of
status-
I'm
keith
scott-
I
do
you
know
I
chair
the
the
ccsds
cis
dtn
working
group,
the
as
ed
pointed
out,
you
know,
ccsds
is
the
standards
body
that
is
responsible
for
setting
standards
for
civilian
space
missions
and
interoperability
among
sort
of
a
suite
of
space
agencies,
both
both
national
and
and
multinational
there.
C
We
we
of
course,
are
very
interested
in
in
bundle
protocol
and
just
finished
submitting
a
ccsds
profile
of
bpv7
to
the
to
tomaso
to
cola,
who
is
the
the
space
internetworking
systems
area
director
in
ccsds
for
standardization,
the
the
the
protocol
profile
there
really
is
very,
very
much
grounded
in
bp
in
the
bpv7
rfc,
so
the
the
the
profile
within
ccsds
says.
C
You
know
you
should
you
should
implement
rfc
9171
and
then
here
are
some
here's.
Here's
some
clarifications
there.
You
know
a
couple
of
restrictions.
For
instance,
we
wanted
to
say
that
you
know
a
compliant
ccsds.
C
Implementation
didn't
necessarily
need
to
deal
with
bundles
larger
than
I
think
we
picked
like
10
meg
as
a
size
just
to
to
give
missions
sort
of
an
out
when
they're
doing
implementations
that
they,
you
know
they
don't
have
to
deal
with
things
that
are
that
are
too
large
for
them
to
to
handle
and
and
and
then
ccsds
always
wants
like
a
service
specification.
So
so
there's
a
service
specification.
The
ccsds
document.
C
In
addition
to
that,
we
defined
a
couple
of
convergence
layer
adapters
that
are
useful
for
space
missions,
so
in
particular
an
ltp
convergence
layer
adapter,
where
one
of
the
things
that
we
did
there
was
allowed
essentially
used
a
type
link.
C
You
know
a
type
value
pair
or
length
value
pair
to
allow
multiplexing
of
multiple
bundles
into
a
single
ltp
block,
and
that,
of
course
imposes
a
requirement
on
the
receiver
that
they're
able
to
parse
those
out,
but
essentially
a
seabor
unsigned
integer,
followed
by
a
bundle,
cbor
unsigned
integer,
followed
by
a
bundle
to
make
things
work
out.
There.
C
Ccsds
has
got
a
couple
of
missions
now
that
are
that
are
using
bp
they're
moving
out,
I
think
pace
is,
is
still
looking
at
a
version
that
is
based
on
bpv6,
and
they
did
that
partially
because
they're
interested
in
the
beefy,
the
bp
v6
custody,
transfer
and
reliability
mechanism,
which
is
one
of
the
things
I'd
like
to
talk
about,
but
in
general
the
you
know
there
may
be.
C
You
know
things
that
are
where
there
may
be
times
where
the
the
sort
of
the
needs
timelines
of
ccsds
and
ietf
diverge
and-
and
you
know
ed-
and
I
talk
regularly
so
you
know
we
sort
of
understand
where,
where
the
two
efforts
are
going,
but
there's
a
strong
desire
from
from
our
part-
and
I
think
for
meds
as
well
for
to
keep
the
two
efforts
in
line
as
much
as
as
makes
sense.
C
If,
if
that,
if
we
can
define
a
common
mechanism
that
can
be
used
by
sort
of
the
larger
community
within
the
ietf
as
well
as
ccsds,
I
think
that's
better
and
will
be
better
for
for
ccsds
in
the
long
run,
because
with
their
you
know,
their
their
end
goal
really
is
to
deploy
bundle
protocol
as
the
networking
layer
for
space
communications
and
then
hopefully
someday
to
go
off
and
buy
commercial
products
for
the
ground
that
that
deal
with
that
on
the
ground
side.
C
And
then
you
know
the
the
various
space
agencies
will
will
always
have
to
write
their
own
flight
implementations,
because
flight
software
is,
as
it
can,
can
tell
you
its
own
its
own
thing.
So
there
are
a
couple
of
areas
where,
as
I
said,
we've
we've
just
gotten
through
dealing
with
this
profile
of
bpv7.
C
C
What
we're
gonna
do
with
with
quality
of
service,
all
those
things
we
sort
of
we
we
did
not
try
to
add
on
and
tackle
those
in
addition
to
9171,
but
you
know
the
time
will
will
come
soon
and
is
and
sort
of
is
now
where
you
know.
We
need
to
turn
to
those
those
things,
because
those
are
the
next
set
of
things
that
that
we
need
as
well
as
you.
So
I
think
that
in
the
in
the
ietf
dtn
charter,
I
think
that
reliability
certainly
reliability.
C
If
I
hit
the
next
slide,
so
reliability
sort
of
at
the
at
the
bundle
level,
not
necessarily
a
series
of
reliable
convergence
layers,
the
you
know,
the
some
of
the
goals
for
especially
for
some
of
these
space
missions
is
absolutely
to
be
able
to
release
resources
as
soon
as
possible
and
the
while
a
series
of
reliable
convergence
layers
is
a
good
way
to
get
reliability.
C
There's
there
is
a
desire
for
something
that
is
a
little
bit
stronger
than
that.
That
is
actually
signaled
at
the
bundle
layer
for
dealing
with
cases
where
we
may
have
a
link
where
you
just
can't
get
a
reliable
convergence
later.
C
If
you've
got
a
unidirectional
link
and
there's
some
multi-access,
some
multiple
access
mechanisms
with
tdrs,
where
you've
got
unidirectional
links
there,
you
may
end
up
having
unidirectional
what
are
essentially
unidirectional
links
from
various
space
missions,
just
because
of
the
delays
and
your
inability
to
actually
turn
a
signal
around
to
get
it
back
out
in
in
time
to
sort
of
close
a
link
before
you
know.
You
want
that
ground
station
back
and
you
need
the
antenna
resource
on
earth
to
go.
Do
something
else.
C
So
the
you
know
by
the
the
the
vibe
custody
transfer
or
the
vibe
draft
with
custody
transfer
is,
is
a
way
of
providing
that
you
know
providing
the
reliability
mechanism
it's
signaled,
there's
esa,
has
the
european
space
agency
has
expressed
a
desire
for
a
capability
that
is,
is
more
akin
to
the
way
things
were
were
done
in
bpv6,
where
the
the
bundle
carry
the
the
bundle
sort
of
carried
with
it.
Natively
a
request
for
for
a
reliability
mechanism.
C
C
Signaling
mechanism
that
was
used
in
and
implemented
in,
ion
and
used
for
the
international
space
station
developed
developed
for
iss
esa
is
interested
in
using
something
like
that,
but
but
expanded
for
maybe
to
support
things
other
than
just
reliability
and
custody
transfer,
but,
but
also
some
of
these
accounting
mechanisms,
so
ways
that
you
can
send
signals
metadata
about
bundles
in
the
state
of
the
network
that
are
that
are
particularly
bid
efficient
there.
C
B
B
Well,
so
my
my
question,
so
there's
at
least
one
question
because
I
have
a
question
is
when
we
talk
about
when
we
talk
about
reliability.
When
we
talk
about
this
kind
of
custody
signaling,
then
it
seems
that
there
are
two
proposals
out
here
for
custody.
Signaling
right,
one
is:
is
there
a
custody,
signaling
mechanism
that
could
be
put
into
an
extension
block?
The
other
is,
is
custody,
an
artifact
of
an
underlying
convergence
layer
like
a
bb
convergence
layer
it.
B
The
my
question
for
the
working
group
is:
do
we
believe
that
that
those
are
two
options
that
exist
in
parallel
or
do
we
think
that
there
will
be
one
or
the
other?
Are
there
any
thoughts
on
on
that.
C
I
I
so
so
my
thought
is
you
always
have
you
always
have
the
option
of
reliable
convergence
layers,
so
it
almost
can't
be
one
or
the
other,
because
you're
always
going
to
have
the
the
question
is
really
do
you?
Do
you
think
that
you're
going
to
architect
your
network
in
such
a
way
that
you
always
know
that
you're
going
to
have
that
series
of
reliable
convergence
layers?
C
Well,
maybe
two
questions
first
is:
do
you
need
reliability
at
the?
Do
you
want
reliability
of
the
network
from
bundle
protocol
to
be
a
service?
That's
provided
and,
and
if
so,
do
you
think
that
you
will
always
be
able
to
architect
your
network
in
such
a
way
that
you
have
reliable
convergence
layers
along
the
entire
path
over.
A
So
can
I
just
jump
in
in
a
second,
I
joined
the
queue
from
my
perspective,
even
if
you
have
reliable
convergence
layers
across
the
entire
end-to-end
path.
A
I
still
think
there
has
to
be
some
signaling
somehow
at
the
bundle
protocol
level
to
say
I
need
you
to
use
those
reliable
convergence
layers
in
case
you
know,
an
individual
bpa
has
a
choice
between
a
reliable
and
an
unreliable
conversions
layer
at
a
certain
hop
along
that
that
path
as
the
as
the
bundle
transits.
So
I
think
it
has
to
be
explicit
in
some
way,
either
through
bibi
or
through
having
some
signaling
conceivably
both
if
there
is
interest
in
doing
both,
but
I
think
it
has
to
be
explicit.
A
It
can't
just
be
implied
that
oh,
I
have
built
my
network
entirely
out
of
reliable
convergence
layers.
Therefore,
everything
will
be
reliable
because
not
all
traffic
needs
to
be
reliable.
So
I
think
that
you
will
solve
one
specific
use
case,
but
at
the
ietf
I
think
we
need
to
consider
slightly
more
generic
solutions
for
some
of
these
things.
E
Yeah,
I
just
just
wanted
to
add
a
little
bit
more
to
that
and
when
we
talk
about
the
custody
signaling
at
the
bundle
level,
we're
saying
things
like
we've
actually
had
the
space
of
this
resource
to
store
it
and
that
the
bundle
is
completely
parsed
and
there
are
no
errors
or-
and
it's
acceptable,
you
can't
get
either
of
those
kinds
of
things.
E
With
a
reliable
convergence
layer,
the
convergence
layer
just
says
I
got
a
bunch
of
bits
and
they're
the
bits
that
were
sent,
but
it
doesn't
tell
you
that
I
was
able
to
actually
store
that
bundle
or
the
bundle
parsed
completely
without
errors
or
exceptions
of
any
type.
So
that's
the
kind
of
thing
in
the
space
community
we're
looking
for
that.
E
The
data
is
completely
intact,
not
being
able
to
store
it,
and
so
the
previous
node
can
now
release.
It
say
that
node
is
a
small
rover
that
wants
to
get
its
data
reliably
back
and
once
that
is,
the
resource
is
freed
on
the
rover.
It
can
go
about
doing
its
normal
thing.
You
know
capturing
more
science
data
or
doing
whatever.
So
that's
that's
one
of
the
underlying
rationales.
E
Where
we're
really
interested
in
getting
it
reliability
at
the
bundle
level-
and
I
agree
with
keith
in
that
all
these
are
options
you
know,
bundle
level,
reliability,
convergence,
layer,
reliability
are
things
that
we
should
allow
in
the
protocol.
A
Go
ahead,
scott,
just
for
notice,
I
lock
the
queue
here
because
I'm
trying
to
try
to
keep
this
is
a
really
useful
discussion
about
reliability,
but
I
don't
want
to
eat
the
entire
session
about
reliability,
and
my
with
my
chair
hat
on,
I
think
much
like
we're
going
to
tackle,
naming
and
addressing
in
a
slightly
workshopping
manner
here.
I
think
I'm
hearing
a
lot
of
opportunity
for
good
discussion
about
what
do
we
mean
by
reliability.
A
So
I
know
people
have
got
valid
points,
but
let's,
let's
just
cut
the
queue
at
this
point,
carry
on
scott
and
brian
just
join.
F
Right
just
very
briefly
to
go
to
your
point:
can
you
hear
me.
F
The
source
application
desires
to
be
used.
End-To-End
is
one
of
the
things
that
I
think
we
ought
to
consider
in
quality
of
service
when
we
get
to
the
quality
of
service
conversation.
F
I
think
that
signaling
is
a
useful
thing.
Quality
of
service
is
something
that
we
need
to
spend
some
time
on
anyway,
and-
and
I
agree
that
both
reliable
convergence
layers
and
and
and
reliability
within
some
sort
of
reliability
mechanism
within
final
protocol
using
some
sort
of
extension
block,
are,
are
worthwhile
things
to
discuss,
and
that's
all
I've
got
for
now.
G
B
Yeah
thanks
so
so
rick.
I
was
also
about
to
try
and
say:
let's
not
have
this
whole
conversation
here
in
real
time,
but
I
I
was
going
to
say
it
seems
like
there.
There
may
be
some
energy
towards
perhaps
an
extension
block
or
other
mechanism
to
signal
reliability
and
custody.
B
So
if
please
keep
that
in
the
back
of
your
mind
as
to
whether
that's
work,
that
the
ietf
should
be
handling
ccscs
should
be
handling
and
then
also
as
we
identify
custodians,
that's
going
to
take
us
back
into
some
of
the
naming
and
addressing
conversation
later
in
this
meeting.
So
please
remember
that
as
a
use
case.
A
Brilliant
good
summary:
okay
carry
on
scott!
Oh
sorry,
keith
yep,.
C
Okay,
accounting,
so
the
accounting
is
a
big
deal
in
in
these
space
missions.
They
very
much
want
to
know
you
know
where
all
of
their
resources
are
being
used.
If
there's
a
question
about
where
that
data
actually
is
sitting
right
now
they
are
for
for
the
space
missions,
the
the
difference
between
a
difference
between
them
and
the
ietf.
C
This
is
really
their
first
foray
into
networking.
They
space
missions
currently
are
are
very
much
run
as
I've
got
a
mission
operations
center.
I
have
a
link.
I
have
a
spacecraft,
there's
one
spacecraft.
It
is
the
thing
that
I
talk
to
so
so
they're
they're
quite
concerned
about
understanding.
C
You
know:
did
this
bundle
make
it
to
the
ground
station?
Did
it
make?
Did
it
get
radiated?
Did
you
know?
Did
various
things
happen
with
it?
So
you
know
so.
Some
of
these
questions
are
accounting
questions
you
know,
sort
of
along
the
lines
of
of
you
know
what
what
might
be
you
know,
internet
or
telephony,
even
accounting,
right
where,
where
are
my
resources
being
used
where's
my
data,
some
of
some
of
the
stuff?
That's
on
this
slide,
that's
in
accounting,
you
know
is,
is
really
seems
to
be
more.
C
I
is
more,
I
think,
network
management,
so
you
know
how
much
storage
is
there
at
a
node?
So
I
I
think
here
you
know
there.
There
are
sort
of
a
couple
of
things
going
on
one
one
is
you
know
this
desire
to
to
be
able
to
get
insight
into
where
you
know
where
bundles
are
have
they
made
it?
You
know
past
this
node,
what's
going
on
there,
which
will
become
more
and
and
more
important
as
we
get
into
sort
of
multinational
cooperative
networks
right,
you
know.
C
Think
of
you
know
we're
going
to
have
things
that
are
that
are
like
autonomous
systems
where
there
are
some
nodes
in
this
network
that
are
run
by
nasa
and
some
that
are
run
by
esa,
and
you
know,
as
we
all
know,
whenever
anything
goes
wrong.
The
first
thing
people
do
is
point
at
the
network
and
say:
oh,
your
network
isn't
working
right
and
so
having
the
the
accounting
mechanisms
to
be
able
to
to
say
where
things
are
is,
is
going
to
be
important
there.
C
One
question
that
I
have
is
whether
or
not
well
so
so,
so
that's
that
that's
one
one
bit
the
other.
The
other
sort
of
more
network
management
or
directly
network
management
bit
is
state
of
nodes.
C
Where
you,
you
may
be
asking
things
like,
you
know
how
much
storage
does
node
have
how
many
you
know
how
many
error
bundles
did
it
receive,
and
things
like
that.
I
think
I
I
think
that
a
lot
of
those
a
lot
of
those
are
probably
addressable
through
something
like
amp
and
and
having
the
right
information
in
some
adms
that
we
can
ask
for
the
a
big
question
that
I
have
is
whether
or
not
the
sort
of
the
the
first
of
those
the
the
the
the
sort
of
real-time
accounting
needs.
C
Things
that
you
might
get
from
from
the
bundle
status
reports
right.
So
you
know
we
have
this
bundle
status
report
mechanism.
C
The
part
of
the
reason
that
we
don't
really
want
to
use
that
operationally
is
it
introduces
the
the
potential
for
there
to
be
a
lot
of
overhead
in
the
network
and
and
you
would
have
you
might
need
to
carefully
craft
rules
saying
you
know
who
is
going
to
send
various
status
reports
when
and
even
if
you
do
that,
if
you're
traversing
a
chunk
of
like
the
terrestrial
internet,
then
you
where,
where
you're
not
in
control
of
those
bundle
nodes,
then
you
don't
get
to
say
whether
whether
or
not
they
will
actually
generate
the
status
reports
and
and
the
fear
there
is
not
maybe
not
so
much
that
they
that
they
won't
generate
them,
but
that
they
will
and
that
those
status
reports
then
go
back
to
you
know
some.
C
You
know
some
space
asset
and
and
chew
up
a
lot
of
very
expensive
and
scarce
resources
on
the
way
there.
So
a
a
question
that
I
have
is
you
know
if
you
look
at
this
slightly
differently,
I
I
wonder
if,
if
amp
and
the
network
management
capabilities
might
be
configurable
in
such
a
way
that
we
could
use
them
to
generate
some
sort
of
network
management,
if
we
define
the
adm
the
right
way,
some
sort
of
network
management
message
for
I
saw
a
bundle
that
looked
like
this.
That
went
through
me.
A
A
A
It
just
needs
to
exist,
it's
sensible,
so
I
would
suggest
that
the
the
dtn
management
stack
would
absolutely
be
able
to
collect
and
aggregate
these
statistics
and
and
generate
them
as
reports
using
what
was
called
ama,
amp,
etc.
A
So
I
there
has
to
be
a
clear
separation
between
we,
don't
just
use
status
reports
and
use
that
as
the
signaling
mechanism.
It's
got
to
be
done
through
that
common
management
infrastructure
which
tackles
the
issues
around
not
having
that
end-to-end
connectivity
at
all
times,
flooding
out
of
traffic,
intentional
transmission
of
when
that
data
is
important
but
I'll
I'll.
Let
ed
explain
that
in
much
more
detail.
B
Well,
so
exactly
right,
and
what
I
just
wanted
to
say
here
is
we.
We
did
have
some
of
the
dtn
network
management
stuff
on
on
charter
for
for
this
meeting,
but
given
that
we
were
two
hours
and
not
three
hours,
we
wanted
to
make
sure
that
naming
and
addressing
went
first
generally
in
itf
and
ccsds.
B
There
is
an
understanding
that
some
level
of
local
autonomy
is
needed
in
the
management
plan
to
do
exactly
the
kind
of
things
keith
that
that
you're
talking
about,
which
is
to
make
decisions
about
well
ultimately
to
make
decisions
about
self-configuration,
but
also
to
understand
when
you
need
to
do
reporting,
particularly
if
you
are
starting
to
queue
and
store
and
forward
reports
for
others.
While
you
don't
have
connectivity
the
area
where
this
may
be
overlapping
with
itf
and
ccsds
or
that's
the
overlap.
B
The
area
where
there
might
not
be
overlapping
with
the
ietf
and
ccsds
are
questions
about
the
on
the
wire
encoding
of
of
this
kind
of
autonomy
model,
and
so
there
are
questions
that
we
are
addressing
in
the
dtnma
document.
The
informational
rfc
around
this
related
to
whether
you
know
in
the
itf.
B
Do
we
do
we
use
something
like
coap
for
the
encoding
of
of
these
messages
and
do
we
use
sort
of
a
different
encoding
for
areas
that
that
don't
want
to
be
or
can't
be
running
co-app,
and
I
think
that's
going
to
be
sort
of
the
hot
topic
at
the
next
working
group
meeting
and
the
mailing
list
to
kind
of
catch
up
to
it.
B
D
A
Sorry
keith
I'll
add
one
last
point
I
can.
I
can
see
a
an
ops,
a
d
in
the
room,
so
there
is
a
liaison
between
this
working
group
and
the
larger
network
management
area
within
the
ietf
to
make
sure
that
we
are
fitting
in
with
best
practice
from
the
ietf
based
on
many
many
years
of
running,
managing
and
monitoring
networks.
So
we
have
access
to
that
that
wider
depth
of
knowledge
within
the
industry,
so
that
we
can
bring
across
best
practice
and
and
align
what
we're
trying
to
do.
A
We
try
and
avoid
the
mistakes
that
other
people
have
made
in
other
areas
and
not
just
invent
our
own
processes
that
miss
out
some
of
the
subtleties.
So
so
we
have
a,
I
think.
That's
the
one
advantage
of
the
ietf
is
that
that
we
have
access
to
this
depth
of
knowledge
in
a
broader
area.
H
Yeah
so
robertson,
cisco,
opposite
d.
So
yes,
that's
helpful
and
I
think
that's
the
right
sort
of
attitude
to
have
and
direction.
So
I
think
we
can
certainly
try
and
get
the
sort
of
cross-pollination
reviews
and
ideas
and
things
as
necessary
and
make
sure
that
everything's
sort
of
working
together
as
possible
and
reusing
bits
that
we
can,
I
know,
there's
some
different
requirements
here
in
terms
of
handling
things
and
things.
They
don't
just
work
the
same
way.
But
there
are
some
of
the
areas
of
that
which
probably
can
leverage
new
sensibly
brilliant.
C
That
is,
that
is
the
bulk
of
of
what
I
think.
We
really
need
to
talk
about
right
now.
There's
there's
a
couple
other
things
that
were
on
that
first
slide
relating
to
qos
and
priority
which
we're
going
to
talk
about
later.
The
only
other
item
that
was
there
was
one
thing
that
we
did
within
ccsds
and
and
sort
of
as
a
as
a
as
a
measure
of
expediency.
When
we
did
the
bpv7
profile,
we
also
defined
a
separate
udp
cl,
which
is
different
from
the
one.
C
That's
in
rfc
7122,
essentially
just
the
the
dirt
simplest
udpcl
that
one
could
come
up
with.
There's
no
notion
of
keep
alives,
it's
just
you
know
one
bundle,
one
udp,
I
I
think
that
for
for
the
for
the
cases
that
we
need,
you
know
that
that
will
that
will
serve
us
really.
C
C
A
I'll,
just
I'll
just
jump
in
again.
Sorry,
I
know
brian
sipos
is
looking
at
updating
the
udpcl
as
a
best
document,
I'm
interested
if
he
wants
to
to.
Let
us
know
how
he's
getting
on
with
that,
but
it's
it's
not
critical,
but
if
ccsds
has
a
specific
use
case
for
a
very
ultra
lightweight
cl
that
they
want
to
quickly
knock
up,
specify
and
standardize.
That's
absolutely
fine!
A
You
know
it's
the
nice
thing
about
having
this
this
kind
of,
and
it
isn't
a
formalized
api,
but
that
kind
of
separation
of
of
responsibility
between
the
bundle
processing
in
the.
How
do
I
move
these
bundles
between
point
a
and
point
b
at
the
equivalent
of
the
link
there?
That's
there's
no
problem
if
you
want
to
liaison
and
unify
onto
what
we're
working
on
and
give
us
input,
that's
also
fine.
So
I
don't
think
this
is
contentious.
D
I
C
C
For
the
for
those
links,
hey
I'd
like
to
thank
you
guys,
I
realize
that
I've
gone
way
over
time.
This
has
been
a
really
useful
discussion.
I
think
for
us
and
and
my
plan
is
gonna-
be
to
just
work
with
with
you
and
and
in
particular,
maybe
through
ed,
who
also
participates
in
the
ccsds
area
stuff
and
make
sure
that
we
move
forward
in
a
way
that
makes
sense
to
everybody
over.
A
Thank
you
very
much
keith.
I
I
think
that
was
really
useful.
It's
I
know
we
have
a
kind
of
unofficial
liaison
with
you
through
through
ed
and
various
people
who
participate.
In
both
events,
I
think
keeping
this
communication
open
between
us
and
honest
between
us,
I
think
is,
is
good
for
all
of
us
involved.
So
thank
you
very
much
for
for
speaking
today
and
let's
keep
working
together
and
making
it
all
just
better.
Okay,.
A
Great,
so
I'm
happily
sharing
slides,
which
means
I
can't
see
who's
up
next.
Has
somebody
got
access
to
ed?
What's
next
on
the
agenda,
because.
B
Certainly
so,
next
on
the
agenda,
we
have
brian
sipos
and
even
though
it's
listed
as
two
agenda
topics,
there's
a
single
consolidated
slide
deck
to
talk
about
three
things:
administrative
records,
the
the
cosi,
bpsac
security
context
and
then
some
thoughts
on
neighbor
messaging,
which
will
then
lead
us
into
scott,
which
will
then
lead
us
into
naming
and
addressing.
A
G
All
right
thanks,
all
of
these
topics
are
going
to
be
pretty
short.
I
want
to
skip
through
them
and
and
really
get
feedback.
That's
the
goal
for
for
presenting
this.
So
the
the
first
topic
and
all
of
these
things
have
roughly
been
presented
previously.
G
So
on
the
topic
of
the
administrative
record
types,
this
is
roughly
the
same
information
as
presented
at
the
last
ietf,
and
the
idea
is
that
there
was
a
little
bit
of
a
a
gap
left
from
rfc
in
any
171
that
that
there's
an
iana
table
of
administrative
record
types,
it
was
not
updated
for
bpv7,
and
the
point
of
this
draft
is
to
make
those
updates
so
that
it's
consistent
with
bp
v6
and
b
and
v7,
and
there
was
another
comment
to
explicitly
say
that
there's
no
change
to
the
registration
procedure,
which
is
a
reasonable
thing
to
state.
G
It's,
not
a
change.
So
it's
just
making
sure
that
the
reader's
aware
that
there
is
no
change
and
what
it
looks
like
it
boils
down
to
this
updated
set
of
viana
tables
and
the
kind
of
feedback
that's
wanted
is
first,
it
would
be
good
to
get
this
adopted.
So
this
is
a
request
for
a
call
for
adoption
and
also
a
request
for
assuming
it
is
adopted
that
there's
comments
more
comments
on
the
document
like.
Should
this
be
two
tables?
Should
this
be
one
table
more
editorial
things?
G
The
contents
of
this
are
what's
already
in
existence.
This
is
not
a
proposed
change
to
any
behavior.
This
is
just
reconciling
the
iana
tables
with
reality,
including
the
aggregate
custody
signal
allocation
that
was
made
by
ccsds,
but
never
actually
rolled
back
into
the
in
the
table.
So
just
making
sure
that
the
whoever
reads
the
table
understands
what
the
real
situation
is.
A
Thanks
brian
I'll
take
an
action
here,
so
this
is
rick
I'll.
Take
an
action
here
to
put
a
working
group
adoption
call
onto
the
list
after
this
after
this
session.
It
may
not
be
this
okay
and
we'll
just
get
it
in
get
some
review
on
it
and
get
it
through
because
by
the
sound
of
it
it's
not
contentious.
So
I'm
hoping
we
can
move
fast
on
this.
Thank
you.
G
And
it
is
necessary
for
future
changes
like
adding
new
administrative
types,
it'll
be
necessary
eventually
and
and
for
example,
reserving
the
experimental
range
just
isn't
there
right
now.
G
Like,
for
example,
the
the
acme
document
and
the
by
document
would
need
code
points
next
topic
again,
hopefully
short
the
cose
context,
so
this
was
presented
at
an
earlier
ietf
as
well,
and
the
idea
here
is
that
the
the
existing
rfcs
define
a
default
security
context
that
is
very
focused
on
symmetric,
keyed
algorithms.
G
It
does
exactly
what
it
needs
to
do
in
a
narrow
scope,
but
it
doesn't
handle
any
notion
of
asymmetric
heat,
algorithms
or,
more
broadly,
any
pki
integrated
security.
G
This
is
something
that
was
brought
up
by
the
ietf
sector
in
the
the
bpsec
review,
and
it
was
also
something
that
was
presupposed
by
existing
nasa
and
ioag
future
architectures
that
the
pki
is
what's
going
to
be
used
for
integrating
disparate
networks
and
right
now
there
isn't
a
mechanism
to
do
that.
G
So
this
proposal
is
is
saying
we
want
to
use
this
pre-existing
structure
and
and
algorithmic
processing,
which
is
cbor,
object,
signing
encryption,
cose
and
put
it
into
bpsec,
and
the
idea
here
is
then
that
we're
gonna
embed
cos
a
as
a
bpsex
security
context.
It
occupies
one
code
point
because
different
cose
messages
have
different
code
points
that
they
self-distinguish.
G
They
can
be
used
for
signing
that
can
be
used
for
encrypting
and
there's
some
additional
technical
details
in
here
for
deduplication
to
avoid
having
a
lot
of
duplicate
data
within
the
the
security
context.
Data
and
cose
itself
is
a
roughly
compressed
storage
of
the
security
data,
and
then
part
of
that
is
to
propose
for
this
interoperability
security
profile
that
includes
symmetric,
keyed,
algorithms
and
then
on
top
of
that
asymmetric
and
also
pki
facing
algorithms.
A
A
Right,
okay,
so
your
intention
is
to
send
out
a
new
update
to
to
reinvigorate
it
and
ask
for
working
group
adoption
is
that
the
plan.
G
Basically,
yes
yeah,
that
if
there's
any
comments
against
the
existing
behavior,
I'd
like
to
I'd
like
to
get
some
feedback,
but
also
know
that
it's
feedback
that
would
be
directed
towards
a
working
group
document.
A
Okay,
so
to
that
end,
given
it's
expired
and
you
don't
from
what
I
can
hear
you
don't
have
any
edits
in
order
to
put
out
a
new
version,
can
you
send
a
link
to
where
it
lives,
because
it's
difficult
to
find
it
through
the
data
tracker
as
a
cache.
H
A
Working
group
attendee
so
just
to
say
it's
here:
please
can
I
have
some
review
and
we'll
try
and
reinvigorate
it
and
get
it
adopted
from
that
point
or
whatever.
G
A
B
So
so
a
few
things
one
without
my
chair
hat
on.
I
just
wanted
to
say
that
I'm
I'm
personally
supportive
of
the
work
and
I
think
that
getting
some
additional
bp
sec
security
contacts
defined
is
a
great
way
of
starting
to
think
through
how
how
we
use
and
the
possibilities
for
the
bpsec
protocol
itself.
I
also
know
that
there
are
security
context
being
talked
about
as
being
standardized
in
ccsds.
B
My
with
my
chair,
head
on
my
question
is:
has
anyone
in
the
cosi
environment
reviewed
this
document
and
could
we
between
now
and
the
next
ietf?
If
they
haven't
been
able
to
review
it?
Could
we
get
a
quick
review
of
it?
Maybe
as
rick
suggested
after
a
minor
edit
to
resurrect
the
document
so
that
going
into
115?
B
We
know
that
we've
gotten
that
extra
review.
G
Sure
I.
A
Had
sorry
brian
ed,
I'm
gonna,
just
I
think
for
before
we
can
reach
out
to
the
kosair
group.
I
think
it's
probably
worth
us
adopting
it
first,
because
it
seems
a
bit
odd
to
us
to
coset
guys
to
have
a
look
at
something.
That's
an
individual
draft.
I
think
it
will
be
a
lower
priority
for
them,
but
I
think
we
can
move
fast,
but
I
think
it's
valid
to
get
early
review
on
this
view.
B
So
so
I
completely
agree-
and
I
personally
I'm
happy
with
adopting
this
document
as
a
working
group
document.
G
Okay
in
the
past,
I
had
brought
it
up.
I
believe,
on
the
jose
mailing
list
and
and
like
rick
had
said
just
as
an
individual
draft,
it
wasn't
very
much
of
a
focus
for
anybody
on
that
list.
G
So
those
two
topics
were
more
focused
and
more
concrete
requesting
of
of
adoption.
This
next
topic
is
more
speculative
and
more
asking
for
comments,
and
it's
a
bit
of
a
broader
topic.
So
the
the
general
topic
is
in
neighbor
messaging
and
more
specifically,
neighbor
discovery
in
support
of
one
of
the
working
group
charter
items
and
the
current
charter
has
neighbor
peer
discovery
as
a
milestone.
G
There's
an
existing
experimental
draft
from
the
irtf
called
ipnd
that
does
its
job
in
a
narrow
scope,
and
it
lacks
some
things
that
a
full
on
standard
track
protocol
would
have
like
extensibility
and
security,
and
what
this
proposal
is
pulling
together
is
to
be
able
to
say
we
want
to
not
have
to
reinvent
extensibility,
not
have
to
reinvent
security
and
reinvent
some
of
these
things.
So
the
idea
is
that
we
want
to
make
use
of
what's
already
present
in
the
in
the
bpa
and
bpsec.
G
So
the
idea
here
is
that
bpsec
already
provides
a
way
of
doing
message,
authentication
and
potentially
in
the
future.
Signing
and
bp
already
provides
things
like
lifetime
limitation,
hop
limitation
and
convergence
layers
already
provide
things
like
a
unicast
transfer
or
multicast
transfer,
and
so
the
idea
of
this
is
saying
that
there
is
this
new
thing
called
the
neighbor
message
and
it
is
a
bundle
with
a
specific
bundle
destination
and
it
has
a
certain
amount
of
security.
It
has
to
be
applied,
but
it's
not
proposing
new
mechanisms.
Just
mandating
uses
of
existing
mechanisms.
G
So
I'm
going
to
skip
through
a
little
bit
of
content
just
for
the
sake
of
getting
to
some
feedback
if
there
is
any.
But
the
idea
here
is
that
a
neighbor
is
a
one
hop
destination.
G
G
This
proposes
dtn
neighbor
as
a
non-specific
destination,
and
that
would
mean
that
the
bpa
knows
how
to
handle
this
endpoint
and
knows
how
to
process
it
in
ways
that
need
to
be
done
to
to
do
neighbor
messaging
and
then
the
idea
is
that
the
contents
of
the
the
payload
are
a
map
with
some
labels
defined
similar
to
existing
protocols
that
you
see,
bore
and
also
falls
in
line
with
the
way
manet
uses
its
own
packet
and
messaging
format,
and
this
would
say,
use
these
existing
bundle.
Lifetime.
G
A
Go
ahead,
ronald
so
we're
blessed
to
have
a
a
many
working
group
chair
here
to
to
to
offer
some
feedback.
J
Hello
ron
enfeld,
yes,
I'm
a
manager,
but
this
is
a
more
heads-off
comment.
J
So
if
I
understand
you
correctly,
then
you
have
to
use
always
there
always
has
to
be
a
udpcl
present
to
do
this.
G
So,
depending
on
the
use
case,
yes,
and
what
that
means
is
that
it's
described
a
little
bit
in
some
of
these
comments.
Let
me
see
if
I
can
find
it
here.
There
is
a
slide
that
talks
about
the
convergence
layers,
but
in
a
in
a
open
network
where
you
don't
know
anything
about
what's
happening,
you
would
need
to
use
something
like
multicast
udp
messaging,
to
be
able
to
send
a
message.
G
But
if
you're
operating
in
a
more
controlled
environment
say
where
you
have
specific
links
that
are
advertised
by
something
like
dlip,
then
what
you
can
then
do
is
you
can
say
well
when
a
link
comes
up
probe,
that
specific
peer.
G
And
it
would
be
a
network
configuration
to
be
able
to
to
set
things
up
in
a
way
that
you,
you
administratively
know
what
kind
of
convergence
layers
are
going
to
be
present
on
the
network,
but
in
a
general
network.
Yes,
you
would
need
to
use
udp
multicast,
but
in
a
controlled
network.
It
wouldn't
necessarily
be
that
way.
G
G
It
could
be.
The
idea
is
that
the
hello
message
would
would
cover
the
same
ground
as
ipnd,
that
that's
the
intent
is
that
it's
it's
ipnd,
plus
the
ability
to
do
integrity,
signing
and
some
other
aspects.
F
I
I
like
this
idea
a
lot,
the
convergence
layer
aspect
of
it-
I
I
think,
is
still
it
doesn't
seem
quite
right
in
my
mind.
What
I'm
thinking
is
that
these
conveying
these
messages
in
bundles
is
cool,
because
it
would
get
the
right
information
to
the
bundled
protocol
agent.
F
I
think
it
would
be
simpler
and
cleaner,
maybe
to
to
add
something
additional
here,
which
is
essentially
a
discovery,
convergence
layer,
adapter
that
has
any
number
of
of
of
different,
underlying
link
service
adapters
of
its
own,
so
that
bundle
protocol
doesn't
have
to
like
deal
with
a
million
different
things.
F
In
order
to
handle
these
things
and
I'm
thinking
here
of
of
ltp
as
a
as
a
model,
we
run
ltp
over
udp,
we
can
run
it
over
space
protocols
and
and
all
of
that
complexity
is
protocol,
shielded
from
all
of
that
stuff
by
the
standard
ltp
protocol
functionality.
I
think
we
had
a
a
neighbor
discovery-
convergence
layer,
adapter
that
that
shielded
bp
from
the
details
of
how
something
is
going
to
talk
to
it,
then
bp
could
stay
simpler.
F
The
convergence
layer
structure
for
the
network
would
be
simpler
and
then
and
the
link
service
adapters.
Underneath
this
neighbor
discovery,
convergence
layer
protocol
could
be
adapted
to
whatever
the
the
the
the
network
that
the
sub
network
that
that
one
that
the
node
lives
in
can
sustain.
So
I
would
like
to
propose
that
we
interpose
a
a
new
neighbor
discovery
convergence
layer
protocol
to
convey
these
messages.
A
Thanks
scott,
I
my
comment
is
I'm
I'm
afraid
I'm
going
to
disagree
with
you,
scott?
I
I
don't
think
this
needs
a
new
convergence
there
and
I
like
this.
I
think
what
I
think
is
the
most
elegant
part
of
this.
Apart
from
yeah,
we
need
a
standardized
way
of
passing
around
the
neighbor
messages
and
yes,
manet
has
done
a
lot
of
work
in
this
area
and
there's
a
wealth
of
experience.
We
can
look
at
there,
the
the
dtn
colon
tilde
neighbor.
A
I
think
that's
very
clever,
so
you've
you
can
formulate
a
bundle
and
address
it
to.
I
need
to
address
this
to
my
one,
hop
neighbors
and
then
leave
the
internal
implementation
of
the
bundle
processing
agent
to
say
I
know
how
to
resolve
that
name
to
whatever
convergence
layers,
I'm
running
and
whatever
those
convergence
layers
understand
by
how
to
get
things
to
a
one-hop
neighbor.
I
you
know.
Oh
I'm
running
d-lab
on
a
couple
of
these
physical
interfaces
and
I
know
I'm
going
to
run
a
I've
been
pre-configured
to
run
a
certain
cla.
I
Yeah
eric
klein
lyria-
I
forgive
my
ignorance
on
on
a
bunch
of
the
stuff,
but
I
was
thinking
along
the
lines
of
of
kind
of
what
you
were
saying
rick.
I
think
there
would
be
no
problem
to
just
like
request
a
link
local
multicast
address
that
represents
all
dtn
nodes,
and
then
you
can
put
it
in
a
udp
message
to
that.
I
You
know
if
you
have
a
if
you
have
unicast
destinations
that
you
know
like
you
already
have
a
cl
a
convergence
layer
attached,
then
you
can
send
the
message
as
if
it
were
unicasted.
If
you
want
to
do
a
multicast,
just
ask
for
a
multicast
link,
local
prefix
for
v4
and
v6
and
away
you
go.
A
Thanks
brian,
have
you
got
anything
wrong.
G
I
have
some
other
slides
that
I
can
skip
over
for
the
sake
of
the
details,
but
there
is
a
separation
between
I'll
just
mention:
the
separation
between
this
hello
message,
content,
which
mimics
the
kind
of
content
of
a
hello,
nhdp
kind
of
manet
message
that
just
says:
here's
who
I
am
here's
my
identities,
here's
some
cryptographic
binding
of
them.
G
Those
identities
here
are
the
cl's
that
I'm
actively
using
here
the
seals
I'm
listening
on,
I'm
here
like
the
the
idea,
is
that
this
is
more
extensible
content
and
there
can
be
again
an
interoperability
minimum
for
this
thing.
But
the
idea
is
that
definitely
it's
a
place
to
put
vendor
and
specialized
extensions
to
expose
whatever
needs
to
be
exposed
for
doing
handshaking.
B
And
I
I
just
wanted
to
call
attention
to
a
comment
that
that
ronald
had
put
into
the
chat,
which
is
that
nhdp,
is
about
two
hop
neighbors,
and
I
wanted
just
to
clarify
that
that
brian.
What
we're
talking
about
here
are
our
one
hop
neighbors,
your
your
immediate
neighbors,
and
that
we're
not
trying
to
establish
a
two-hop
neighborhood
in
a
dtn
which,
which
may
be
a
difficult
thing
to
do.
J
G
This
link
exists
as
a
standalone,
not
data,
tracker
document
it
it
has
missing
sections.
It's
not
complete.
This
was
put
together
as
a
kind
of
a
touchstone
of
is
this
worthwhile
without
spending
too
much
time
on
the
details
that
have
to
be
present,
for
it
to
be
a
full
document,
but.
A
So
so
my
question
is
this:
is
on
charter
at
the
moment?
Are
you
looking
for
collaborators
to,
because
I
I
noticed
this
would
be
your
third
id.
You
would
be
committing
to
get
ready.
I'm
looking
at
people
like
ronald
who
has
has
previously
expressed
a
real
interest
in
labor
discovery,
but
I
I
know
this
has
had
some
discussion
amongst
today,
and
I
know
people
have
talked
about
this
before.
Would
you
like
some
collaborators
to
help
make
this
move
forward.
A
Okay,
sorry
to
push
on
time,
but
go
ahead.
Ronald
you're
in
the
queue.
J
A
Okay,
is
that
it
wrong?
Are
you
happy
with
that.
G
A
I
know
you've
got
a
sort
of
rough
outline
for
for
some
topics
to
discuss
as
part
of
the
workshop,
which
I
think
we
may
naturally
slide
into
off
the
back
of
of
scott's
presentation,
but
just
to
reassure
you,
we
have
a
a
soft
agenda
for
the
for
the
second
hour,
but
we'll
start
with
scott
thanks.
Brian.
F
Okay,
oh
oh
I've.
How
do
I
advance
the
slides.
F
What
I
will
assert
here
is
a
couple
of
of
definitions
that
people
will
undoubtedly
take
issue
with
later
on.
I'm
gonna
assert
that
a
name
is
a
character
string
that
identifies
a
thing
of
some
sort,
then
distinguishing
it
from
other
things
of
the
same
type.
So
you
have
a
type
you
have
scientists
well
they're.
The
names
that
distinguish
different
scientists
might
be,
for
example,
max
plunk,
murray,
curry,
the
names
of
things
that
are
of
type
movie
you
might
have,
for
example,
citizen
kane,
the
godfather
location,
is
a
type
of
thing.
F
F
The
state
machine
that
is
driving
this
particular
display
is
it
resides
in
in
a
space
that
is
the
the
internet,
which
is
located
by
its
connectivity
to
other
state
machines
that
the
topology
of
the
network
an
address
is
the
name
of
a
location.
F
F
The
name
of
the
location
needs
to
be
unique
within
the
network
in
order
to
associate
it
with
a
node.
F
The
the
node
has
a
name,
and
that
name
also
needs
to
be
unique
among
nodes
in
order
for
messages
to
be
directed
to
that
node,
and
rather
rather
than
to
some
other
node
among
the
properties
of
a
node,
are
the
node's
name
and
its
address,
which
is
the
name
of
its
location
and
at
any
moment,
there's
an
association
between
the
name
of
a
node
and
the
address
of
the
node,
which
is
the
name
of
the
node's
location.
F
F
If
the
location
does
change,
then
then
the
association
between
the
name
of
the
node
and
the
name
of
the
location
of
the
node
has
to
be
recorded
somewhere,
and
you
have
to
revise
it
when
the
location
changes
in
order
for
data
to
be
sent
through
a
network
which
is
actually
what
we're
saying
there
is
it's
copied
from
one
node
in
the
network
to
another
node
in
the
network.
F
The
data
has
to
first
arrive
at
the
location
at
which
the
destination
node
resides
and
then
be
delivered
to
the
node
at
that
location,
and
we
do
that
by
forwarding
the
message
along
a
route
which
is
a
continuous
succession
of
of
connections
between
neighbors,
which
are
nodes
whose
locations
are
topologically
adjacent.
Their
locations
are
connected,
that's
what
being
a
neighbor
is
really
in
the
internet.
F
The
ip
network,
locations
of
nodes,
change,
don't
change
often,
and
the
propagation
of
information
about
those
changes
is
really
rapid.
So
the
source,
no
source
of
sending
data
to
some
destination,
node
its
knowledge
of
the
destination
node's
address,
can
be
used
to
direct
the
forwarding
of
the
packets
that
are
destined.
For
that
note,
because
the
the
the
source
node's
knowledge
of
the
address
of
the
destination
node
is
likely
to
be
correct.
F
F
You
don't
have
to
worry
about
it
happening
in
the
internet
in
d10,
that's
different
in
dtn,
the
vp
locations
of
nodes
may
change,
often,
and
in
particular
the
propagation
of
information
about
those
changes
may
be
really
slow,
so
the
source
node's
current
knowledge
of
the
address
of
the
destination
node
is
less
safely
used
to
direct
the
forwarding
bundles
destined
for
the
node.
The
forwarding
may
take
so
long
that
the
node
has
changed
location
before
the
packets
can
be
delivered.
F
This
is
where
we
get
the
idea
of
late
binding
and
in
the
the
the
problem
here
is
that
information
about
a
change
in
a
destination
node's
location
may
be
getting
propagated
through
the
network,
but
hasn't
made
it
all
the
way
to
the
source
node.
It
may
be
only
part
way
along
the
the
path
to
the
to
the
source
node.
F
Some
other
node
may
have
the
most
current
information,
and
so
for
this
reason,
what
we
do
in
dtn
forwarding
and
when
we're
forwarding
a
bundle,
is
we
use
the
destination
node's
name
to
look
up
its
address,
because
it
could
be
different
from
what
the
source
node
might
have
thought
it
was.
So
this
is
late,
binding.
F
So,
for
this
reason,
the
destination
that
we
encode
into
a
bundle
really
needs
to
indicate
that
the
destination
node's
name
rather
than
its
address,
the
name-
is
always
going
to
be
reliable.
It's
going
to
the
node's
not
going
to
change
its
name.
That's
its
identity,
the
destinations,
the
address
of
the
destination.
Node
may
not
be
reliable
at
the
time.
The
bundle
is
sent.
F
We
can
imagine
mitigating
this
constraint
a
little
bit
by
saying
suppose.
You've
got
like
large
areas
of
the
network
topology
that
nodes
may
move
around
within,
but
they
don't
really
change
from
one
region
to
another.
So,
for
example,
similar
to
I
live
in
los.
D
F
I
might
move
to
san
diego,
but
that's
all
california
or
it's
all
the
united
states,
so
the
if
you,
if
you
address,
if
you
add,
for
example,
the
the
name
of
this
large
region
like
uk,
to
the
destination
of
something
well
that
that
part
of
the
the
resolved
location
of
a
node
is
unlikely
to
change
very
much,
and
if
it
does
change
you
may
find
out
about
it.
F
You
know
soon
enough
to
be
able
to
correct
for
that,
so
that
would
limit
the
scope
of
the
location
lookout
the
late
binding
function
to
to
be
within
that
broad
region
and
that
that
could
simplify
some
things.
So
in
that
context,
supposing
we
have
that
kind
of
mechanism?
F
How
do
you
get
it
to
the
edge
of
the
the
destination
nodes
region?
How
do
you?
F
How
do
you
get
it
across
the
region,
boundaries
until
it
gets
to
the
region
within
which
you
know
the
decimation
node
resides
somewhere
and
the
the
region
concept
that
that
we've
been
working
with
in
iom
recently
is
suppose
they
have
got
multiple
regions.
Each
region
has
a
name.
F
If
region
has
a
location
same
as
a
node
has
our
location,
the
the
location
of
the
region
is
within
a
a
tree
of
regions,
you
can
think
of
it
as
a
network
of
regions
and
there
are
passageway
nodes
that
connect
the
nodes
of
of
one
region
to
the
nodes
of
of
adjacent
in
those
neighboring
regions
and,
and
those
are,
these
are
nodes
that
are
located
and
they
have
locations
within
both
of
the
the
the
two
neighboring
regions.
F
So
how
do
you
know
which
passenger
forward
bundle
two
in
order
to
get
it
to
its
destination?
Yeah
rick.
A
A
So
I'm
saying,
although
there
is
mobility
amongst
the
the
nodes
within
a
certain
space
within
my
topology,
it's
reasonably
localized,
so
I
can
make
a
a
a
rough
decision
to
say
it's
going
to
be
down
that
side
of
the
tree,
headed
over
into
that
region
and
you'll
find
it
over
there.
So
the
later
lookups
will
will,
with
more
accuracy,
find
it
so.
D
A
A
F
Can
we
come
back
to
that
question
in
a
little
bit?
Okay
right,
because
I
I
think
it's
something
I
want
to
dig
into
a
little
bit
more
so
that
I
understand
it
better,
because
I
don't
see
an
issue,
but
there
may
very
well
be
one.
A
K
Hey,
can
you
hear
me?
Yes,
okay,
so
can
you
go
back
a
couple
slides?
Let's
just
have
a
quick
question
about
something
that
you
said
about
the
regions.
F
Yeah,
how
far.
K
Back,
I
think
one
more.
K
Anyways,
I
don't
know
where
it
was,
but
my
question
is:
is
this
so
if,
at
some
point
science
one
of
the
slides
you
you
seem
to
imply
that
within
a
region
notes
don't
change
much
so
if
that
is
located.
F
K
F
Let
me
pick
up
we're
okay,
all
right,
so
so
so,
if
you,
if
you
have
this-
and
I
I
think
at
the
moment-
I'm
working
with
something
that
is
that
that
rip
is
identifying
as
as
a
subnetting
notion
of
of
of
regions,
so
one
one
way
to
make
that
work
is
to
have
management
of
the
region.
If
you
have
a
global
authority
that
manages
the
region
tree
and
announce
the
the
region
tree
topology
to
every
new
node
when
the
new
node
is,
is
instantiated
and
communicate.
F
There
is
a
the
the
downside
to
this
is
that
there
is
a
a
tree
management
and
synchronization
challenge
there,
which,
as
usual,
is
subject
to
the
usual
kinds
of
of
political
problems
and
is
exacerbated
by
the
latencies
and
propagation.
But
but
it's
a
familiar
sort
of
thing.
So
we
we
do
something
like
that
in
the
internet,
it's
just
slower,
uh-huh,.
B
F
Hi
scott,
can
you
hear
me
not
very
well,
I'm
just
going
to
turn
up
my
volume
a
little
bit.
L
Okay,
not
sure
which
mic
I'm
using
here.
I
got
a
couple
of
them,
but
my
question
is:
do
you
anticipate
regions
to
be
predefined
or
are
they
dynamic?
So
so,
okay
in
a
region
is
a
a
going
to
be
predefined
by
a
by
a
location.
F
The
the
notion
that
that
we've
been
working
with
is
because
it's
based
on
contact
graph
routing,
but
it's
extensible
to
other
kinds
of
routing
approaches,
but
but
in
the
contact
graph
routing
context,
a
region
would
be
coterminous
with
an
identical
as
a
in
it
one
for
one
with
with
a
single
contact
plan.
So
as
you
define
a
contact
plan
that
defines
the
region,
regions
are
strictly
topological,
they're,
not
geographical.
At
all.
L
F
I
ideally,
ideally
you
might
not
be
moving
into
a
different
region
until
you
got
to
your
final
destination
right.
That
is,
the
region
could
extend
all
the
way
from
here
to
jupiter.
The
region
is
not
geographical,
it's
topological,
it's
it's!
The
reason
is,
is
is
a
set
of
nodes
that
that
communicate
among
themselves.
According
to
the
contact.
L
F
So
picking
up
on
on
this
idea
here,
this
managed
regentry.
What
you
end
up
with
is
a
globally
managed
structure
that
you
can
use
to
compute
a
path
through
the
tree.
If
you
know
the
region
that
your
destination
node
is
in
and
each
node
forwards,
the
bundle
to
the
passageway
that
will
get
it
to
the
next
region
on
the
path
of
passageways,
a
second
option,
which
is
the
one
that
there's
been
some
research
on,
that
attempts
to
avoid
the
global
management
of
the
structure.
F
Is
to
base
it
all
on
a
discovery
protocol.
The
topology
of
the
region
tree
is
locally
discovered
and
revised
by
by
pairwise
agreements
between
regional
management
authorities,
so
the
the
complete
topology
of
the
tree.
It
never
needs
to
be
recorded
anywhere,
which
is
advantageous,
especially
if
you
have
like
a
a
large
number
of
regions.
Yeah
right.
A
Okay,
it's
slightly
with
my
chair
hat
on
we're
in
danger
of
slipping
into
into
rooting.
Routing
here
so,
and
I
know
we
have
to
be
quite
careful
to
dance
around
the
edge
of
it,
but
I'm
very
happy
for
us
to
talk
about
how
does
a
bundle
processing
agent
work
out
which
of
many
next
hops?
It
wishes
to
push
a
bundle
out
to,
I
think,
that's
entirely
in
scope,
and
that
depends
on
having
names
and
addresses
and
some
kind
of
concept
of
topology.
A
That's
fine
when
we
start
to
say
actually
the
way
we
name
an
address
implicitly
gives
rooting
information.
I
think
that
becomes
an
increasingly
contentious
subject
and
I'll.
Give
you
my
reasoning
for
the
same
that
you
scott
introduced
along
with
your
collaborators,
the
late
binding
concept
into
dtn,
and
it's
one
of
the
fundamentals
of
it,
which
is
you
can
make
an
accurate
decision
after
the
bundle
has
entered
the
network
in
order
to
get
it
somewhere.
K
A
D
A
F
Well,
which
is
why
my
next,
where
I'm
going
to
next,
I
think,
addresses
that
at
least
I
think
it
does,
which
is
that
this
discovery
mechanism,
where
the
the
the
topology
of
the
region
tree
is,
is
adjusted
locally
by
the
management
authorities
for
the
regions.
F
F
I
actually
prefer
this,
and
this
is
the
thing
that's
implemented
in
the
there's,
a
feature
branch
of
ion
that
has
got
this
built.
I
I
think
it's
a
better
way
to
go,
but
it
is
a
it's
a
less
familiar
model
as
I'll
get
to
in
a
second
and
and
on
that
basis
it
may
be
that
people
are
more
comfortable
with
a
sort
of
a
hybrid
approach
where
you
you,
you
have,
you
can
compute
a
route
through
a
known
topology
of
regions,
and
then
you
do
like
bind.
F
A
Yeah,
I
understand
the
difference
between
having
dynamic
discovery
of
of
of
the
the
path
through
the
network,
the
routing
the
path
through
your
tree
and
and
having
it
pre-placed,
and
that's
that's
a
valid
point,
but
I
still
to
me
I
think,
you're
describing
the
name
of
something
as
go
here.
Then
here
then
here
and
you'll
get
it
there.
F
So
the
the
the
the
the
advantage
here
of
of
going
with
this
automatically
evolving
tree
is
that
when
you
encode
the
destination,
if
it's
a
globally
managed
region
tree,
you
need
to
enclose
include
in
the
destination
the
name
of
the
region
that
the
node
resides
in,
so
that
you
can
give
this
computation.
F
F
They
would
affect
what
you
need
to
do
when
a
node
moves
from
one
region
to
another
and
the
globally
managed
tree
option.
You
need
to
change
the
destination
encoding
for
that
node
at
every
node
that
sources
bundles
destined
for
that
node.
So
it's
I
I
think,
that's
undesirable,
but
it's
it.
It
again
lines
up
with
a
a
with
a
more
familiar
model.
F
If
you
have
an
automatically
evolving
region
tree,
the
destination
coding
doesn't
change,
because
all
it
is
is
the
name
of
the
node.
But
in
that
case
you
have
to
like
rediscover
the
the
new
passageway
sequence
by
doing
some
other
mechanism
that
I
won't
go
into
here,
but
it's
basically
a
sort
of
a
probe
through
the
network
to
you
to
discover
the
right
sequence
of
passageways.
F
F
This
would
give
you
time
either
for
just
to
schedule
either
the
changes
in
destination
and
coding
and
all
the
nodes,
or
else
the
issuance
of
new
probe,
bundles
and
summing
up.
I
think
this
globally
managed
region
tree
is
a
familiar
model.
It
imposes
modest
additional
overhead
there's
some
additional
administrative
complexity,
not
my
favorite,
but
it's
you
know
in
fairness.
We
should.
We
should
consider
this.
I
prefer
the
automatically
evolving
regentry
blade
binding
all
the
way,
binding
all
the
way
down,
no
additional
overhead
in
data
traffic,
but
but
during
path,
discovery.
F
Of
course,
there's
there's.
You
have
to
get
the
information
discovered
in
all
the
appropriate
places
somehow,
and
so
there
needs
to
be
some
discovery
protocol
activity
to
make
that
happen.
I
think
that
can
be
depending
on
how
the
regions
are
managed.
I
think
that
can
be
modest,
but
that's
a
fair
topic
for
discussion
and
that's
the
end
of
my
slides.
A
A
A
Your
first
point
could
be
a
very
interesting
short-term
compromise
and
it's
more
of
an
open
question
to
the
working
group
or
whether
that
would
be
something
an
organization
like
ccsds
would
be
interested
in
where
there
would
be
a
new
node
eid
scheme
which
encapsulates
within
the
name
the
exact
pre-known
path
of
how
to
get
to
somewhere.
So
it
would
be
rick.bristol.uk.
A
My
personal
opinion
said
before
is:
I
think
that
goes
against
what
we're
trying
to
do
with
dtn,
but
I
can
see
that
appealing
particularly
to
the
space
community
for
a
a
specific
project
for
a
specific
mission
or
whatever.
They
know
everything
in
great
detail,
or
I
hope
they
do
so
it
might
be
entirely
viable
for
them
to
do
that.
F
I
I'm
two
two
things
before
we
take
the
questions.
I
I
agree
with
you.
I
think
the
the
the
second
is
the.
F
Is
superior
and
and
is
more,
more
dtn
like
the
the
difference
in
the
way
you
encode
the
destination,
whether
you
include
include
the
name
of
the
region
in
the
the
destination
encoding
in
the
bundle
is
why
I
think
this
question
belongs
in
the
discussion
of
naming
and
addressing
yeah.
You
have
to
drag
in
some
routing
ideas
to
to
make
the
point,
but
it
is
a
naming
and
addressing
question.
F
Do
we
do
we
stick
with
the
idea
of
naming
the
node
and
and
addressing
a
bundle
to
a
node
by
name
or
do
we
stretch
things
a
little
bit
and
and
include
a
gross
location
of
the
node,
the
destination
node
in
the
destination
encoding,
the
name
of
the
region
that
the
the
node
is
in?
I
I'm,
I
prefer
certainly
the
the
automatic
evolving
region
tree
and
and
just
using
the
destination
node's
name
as
the
destination
in
the
bundle.
B
So
so
I
scott
just
just
to
agree.
I
I
think
that
this
does
resolve
into
naming
and
addressing
the
the
question
that
that
I
have,
and
maybe
after
eric
comes
after
me,
we
can
get
into
this.
Is
the
discussion
is?
B
How
does
this
imply
format,
structure,
restrictions
on
the
names
and
my
my
comment
is
instead
of
saying
that
if
we
were
to
presuppose
that
destinations,
as
you
have
talked
about
them,
have
sort
of
a
region
and
and
some
additional
information
related
to
that
region,
do
we
consider
that
entire
destination
to
be
either
late,
binding
or
not
late,
binding
or
within
the
structure
of
a
destination?
B
Do
you
say
if
you
have
a
region
id
the
region?
Id
is
not
a
late
binding
concept
and
and
the
internal
in
internal
to
the
region,
piece
that
may
be
late
bound
and
and
because
we've
structured
the
destination
itself.
Do
we
treat
different
pieces
of
that
destination
differently
from
a
binding
perspective
is?
Is
that
what
we
would
need
to
do
to
make
something
like
this
work.
F
For
me,
the
the
key
question
is
whether
or
not
there's
any
topological
information
of
any
kind
in
the
encoding
of
the
destination.
If
there's
topological
information
in
there,
for
example,
the
name
of
the
region
that
the
node
resides
in
then
then
you've
you've
got
the
the
you
end
up
with
the
globally
managed
region.
Tree
kind
of
thing
I
mean
you
might
be
able
to
do
it
automatically,
but
there's
there's
no
advantage.
I
think
you
need
to
do
things
like
when
the
node
changes
regions.
F
You
need
to
tell
everybody
in
the
network
that
the
node
is
in
a
different
place
and
and
the
encoding
of
destinations
needs
to
change.
If
you
omit
all
topological
information
from
the
destination,
which
is
to
say
the
name
of
the
node,
the
identifying
unique
identifying
name
of
the
node
and
nothing
else,
then
you
avoid
all
that
there
is.
There
is
a
cost
to
that,
which
is
that.
F
Then
you
need
a
an
automatic
mechanism
for
for
for
discovering
the
paths
through
the
region
network
and
I
will
say
tree
because
I
am
convinced
that
the
tree
is
much
better
way
to
do
it.
But
but
if
you
can,
if
you
can
accomplish
that
automatic
management,
pairwise
management
of
the
connections
in
the
tree,
then
I
think
that
that
that
approaches
is
superior.
It's
it's.
F
It's
there's
less
thrashing
in
the
network
as
soon
as
you
admit,
of
any
topological
information
at
all
in
the
coding
of
the
destination
you
are,
you
are
no
longer
doing
complete
late
binding.
You
have
you
have
bound
right,
you
you,
you
early
bound
to
to
a
limited
extent.
You
have
early
bound
the
the
destination
of
of
the
node
you're.
Sending
to
does
that
answer.
Your
question.
B
Doesn't
I
do
want
to
jump
as
quickly
as
we
can
into
in
the
time
remaining
to
to
at
least
lay
out
some
of
the
topics?
My
point
is
exactly
what
you're
saying
is
that
if
we
go
this
route
there
is
a
that
would
be
the
the
requirement
to
to
have
that
early
binding
concept,
at
least
for
something
like
regions
and
the
topology.
But
let's,
let's
go
over
to
eric
sure.
B
I
The
interest
of
time
I'll
try
to
keep
myself
to
clarifying
questions
does
a
node
know
all
of
its
available
names
as
it
moves
from
region
to
region
or
does
it
never
change
names
I'm
having
a
hard
time
with
this
abstract
stuff,
but
there's
I'm
trying
to
build.
F
In
this
yeah
in
this
concept,
I
would
say
that
a
node
only
has
one
name,
and
it
always
has
one
name
and
that's
all
well,
let
me
say
that
again
it
might
have
it
might
have
ids.
It
might
have
node
ids
expressed
in
in
multiple
endpoint
id
schemes,
for
other
reasons,
for
for
implementation
reasons,
but
but
it's
it's
its
name
within
any
single
eid
scheme
should
never
change.
If
it
does
it's
a
different,
if
it's
a
different,
it's
a
different
note
at
that
point.
I
F
F
Yeah,
that's
that
that
would
be
an
interesting
way
to
do
it.
You
could
say
I'm
sending
this
node
to
node
abc
and
I'm
sending
it
to
its
identity
within
region,
so
and
so
whenever
it's
in
reading
so
and
so
it's
it's
available
it
it
it's,
it's
got
it's
it's
possible
for
it
to
be
delivered
there
and
and
if
it's
not
in
reason
so
and
so
then,
then,
when
I
send
it
there,
it's
not
going
to
get
there.
I
I'm.
F
I
M
I
was
just
going
to
make
the
comment
that
the
automatically
evolving
region
tree
cost
is
when
you
send
out
these
probes,
it's
going
to
take
a
while
to
determine
what
the
optimum
that
the
tree
topology
looks
like
in
the
subtrees
and
so
forth,
and
in
interplanetary
networking
situations
that
may
be
totally
intractable
if
it
takes
40
minutes,
one
way,
light
time
to
get
to
mars
and
40
minutes
back
to
find
out
which
relay
node.
You
need
to
talk
to
to
get
to
a
local
mars
region.
M
M
F
Yeah,
I
I
I
completely
agree
the,
and
you
know
I
I
think
the
the
way
that
this
thing
would
have
to
work
is
that
things
like
which
side
of
a
planet
you're
on
and
so
on,
would
would
not
be
region
scale
considerations.
Those
would
be
considerations
for
late
binding
within
the
region
that
that
a
region
would
be
something
that
that
a
node
would
not
casually
or
frequently
change.
That
is
you?
Don't
you
don't
casually
or
frequently
move
from?
You
know
the
united
states
to
portugal.
F
If
you,
if
you
did
it,
it
would
be
a
big
deal
and
there's
a
there's,
definitely
an
overhead
in
in
making
that
happen,
and
that
overhead
is
incurred.
Rarely
enough
that
you
can
tolerate
some
sub-optimal
network
performance,
while
it's
going
on
that's
the
idea.
A
So,
jordan,
I
would
consider
that
topic
to
absolutely
be
rooting
and
therefore
slightly
out
of
scope
for
this,
but
yeah
everything
you've
highlighted
are
absolutely
good
considerations
for
how
do
we
manage
and
maintain
the
forwarding
information
in
the
individual
bundle
processing
nodes
in
an
optimal
and
usable
way?
A
Scott,
my
you
and
I
have
talked
about
this
region
concept
before
several
times
and
I
think
what
yeah
I
have
disagreed
is.
A
By
that
I
mean
talk
about
how
you
get
a
bundle
to
a
direct
to
a
to
an
destination,
but
actually
to
be
a
way
of
subdividing
the
naming
space
so
that
you
don't
have
to
have
the
phone
book
of
everyone
in
order
to
map
a
name
to
who
the
next
hop
a
name
to
route
to
the
destination.
A
A
If
I,
if,
if
I
am
part
of
the
nasa
team
who
wishes
to
send
some
sort
of
information
to
the
esa
mars,
rover
too,
I
set
the
destination
of
the
bundle
to
mars
rover
two
dot
esa,
for
example-
and
I
don't
really
care
about
the
encoding
so
within
the
nasa
space
within
the
nasa
network,
the
individual
nodes
that
are
moving
that
bundle
around
may
not
know
where
on
earth
mars,
rover
2.
is
or
where
on
mars,
mars
rover
2..
There
we
go.
A
But
they,
but
they
do
know
how
to
get
something
to
someone
who
is
in
the
eastern
naming
region.
So
they
can
get
to
your
passageway.
What
I
call
a
gateway
traditionally
to
say.
Oh,
if
I
know,
if
I
get
it
to
this
node,
that
node
will
be
able
to
resolve
that
esa
name
to
something
it
might
be,
the
isa
nasa
gateway
and
there
might
be
a
peering
agreement
between
issa
and
nasa
to
say
here
are
some
gateways
that
have
a
name
in
both.
A
A
I
love
your
concept
of
regions,
but
I
would
like
to
divide
the
naming
space
and
not
the
routing
space
into
regions,
because
I
think
it's
just
requiring
a
top-down
name,
registrar
for
all
names
of
everything
everywhere,
and
I
think
it
gives
us
a
lot
more
flexibility
in
terms
of
peering
agreements
and
about
how
we
build
these
larger
interconnections
between
these
various
naming,
autonomous
autonomously
named
regions.
F
I
I
think
hierarchical
naming
structure
is
a
perfectly
reasonable
and
and
in
fact
well
my
preference
is
that
not
to
use
ascii
names
at
all,
but
rather
to
use
node
numbers
and
for
those
node
numbers
to
be
assigned
in
uniquely
identifying
but
to
be
assigned
within
ranges
that
that
are
associated
with
organizational
entities
so
that
the
the
number
so
that
the
organizational
entity
could
be
inferred
directly
from
the
destination
node
number.
F
And
then,
if
you,
if
you
have
some
a
routing
system
that
can
use
that
that
hint
to
improve
your
routing,
then
by
gosh,
go
ahead
and
do
it.
I
think,
for
I,
I
think
the
the
notion
of
of
reason,
as
it's
used
for
routing
is
separately
important,
because
you
wouldn't
necessarily
have
to
base
your
writing
decisions
on
knowledge
of
peering
agreements
between
organizational
entities
that
own
the
the
nodes.
F
I
I
see
nothing
wrong
with
with
with
enabling
that
kind
of
mechanism,
but
I
I
think
it's
more
general
if
we
don't
require
it
and
that's
that's
why
I
think
the
the
region
structure
is
a
topological
structure
rather
than
a
a
naming
mechanism.
I
think
that
the
naming
mechanism
ought
to
be
in
the
names
themselves,
but
I
don't
want
to
like
dominate
the
conversation
with
that.
I
I
think
stewart
has
maybe
other
ideas,
but
you've
got
a.
F
A
N
Go
ahead,
stu
card
here,
so
a
comment
request
and
a
question
first
to
comment:
thanks
scott
for
a
very
logical
shaping
of
the
discussion.
Your
first
few
slides,
I
think,
bring
a
lot
of
clarity
to
this.
Then
the
request.
N
I
I
hope
that
as
we
go
forward,
we
can
not
paint
ourselves
into
a
corner
that
precludes
essentially
an
arp
function,
that
maps
us
into
different
identifier,
spaces,
different
logical
location,
spaces
and
different
physical
location
spaces,
two
with
which
I'm
particularly
concerned
are
host
identity,
protocol
host
identity
tags,
especially
the
new,
hierarchical
host,
identity,
tags
and
high
frequency,
automatic
link,
establishment
addresses
ale
addresses
and
then
finally,
the
question:
do
your
regions
partition
a
space
or
can
they
overlap.
F
At
the
same
time,
a
node
can
be
can
be
a
member
of
multiple
regions.
Every
passageway
is
has
to
be.
It
has
to
be
a
member
of
multiple
regions,
the
if
you
could
take
that
that
concept
of
passageway,
that
is,
membership
in
multiple
regions,
which
is
what
would
would
enable
overlapping.
If
you
wanted
that
you
could
take
that
to
an
extreme
and
and
say
any
node
can
be
in
any.
F
Of
regions
and
therefore
you
you
can
you
know
route
in
some
interesting
and
optimized
ways?
I
think
that's
a
direction
to
be
avoided,
because-
and
here
again
this
is
going
to
my
firm
held
conviction
that
that
the
reason
is
ought
to
be
organized
in
a
tree.
It's
it
is
from
an
implementation
point
of
view,
I
think,
very
difficult
to
avoid
introducing
routing
loops.
If
you
have
the
regions
organized
in
any
structure
other
than
a
tree.
F
In
order
to
avoid
writing
loops,
I
think
you
need
way
more
information
about
the
no
the
reason
topology,
and
that
gets
you
back
to
the
all
the
same
problems
of
globally
managing
the
region
tree
that
I
think
it's
desirable
to
avoid.
If
it's
automatic,
then
then
the
the
tree
automatically
forms
itself.
If
you
limit
the
rules
by
which
things
connect
up,
if
it's,
if
it's
not
a
tree,
then
I
I
I
foresee
potentially
very
major
headaches
in
getting
the
the
topology
to
work
in
a
reliable
way.
A
So
I
closed
the
cube.
Thank
you
very
much
scott
for
that
answer,
zahed
go
for
it.
We
have
about
six
minutes
left
so
yeah.
O
I
so
yeah
you
had
your
transport
lady
and
I'm
actually
putting
my
head
on
so
so
yeah
I
mean
I
mean
we
started
the
discussion
about
riku,
saying
like
we
don't
have
a
document,
but
we
don't
want
to
commit
to
that.
O
We're
not
in
at
that
point
the
commit
to
write
documents,
but
thanks
to
scott
and
to
the
working
group
I
mean
this
was
a
really
good
discussion
and
I
think
there
is
a
certain
maturity
of
the
ideas
and
certain
pros
and
cons
that
I
think
when
now
it's
time
to
actually
write
it
down,
because
I
think
I
see
there
are
questions
like
how
the
name
could
be
or
the
schemes
could
give
how
the
reasons
could
be.
I
think
it's
very
good
to
have
the
discussion
when
things
are
documented,
so
this
is
not
only
the
presentation.
O
I
look
look
or
recognize.
I
look
I'll
have
a
document,
and
actually
I
can
read
and
see
like
what
could
make
more
sense
right.
So
I
strongly
recommend
the
working
to
come,
so
somebody-
maybe
maybe
scott
yes
to
actually
write
it
down,
and
then
we
can
have
further
discussion
on
that
one.
So
that's
my
idiot
on
and
and
then
my
understanding
of
the
reason
and
concept
of
like
overlapping
question
that
still
asks
like
it
can
have
overlapping
reason.
O
But
then
the
problem
is,
you
cannot
have
a
name
collision
and
you
have
to
avoid
that
and
that's
the
complexity
to
bring
in
if
you
overlap
so
so
yeah.
So
my
advice
to
this
working
group,
please
write
things
down
so
that
we
have
a
more
constructive
discussion
going
forward
and-
and
this
is
a
very
good
discussion-
we
have
three
ideas
here.
So
you're
well
covered.
F
I
I
it
has
taken
us.
I
think
this
long
to
get
to
the
point
of
of
being
able
to
articulate
these
ideas
at
this
level
at
this
puny
level.
So
I
I
agree.
I
think,
if,
if,
if
we're
interested
in
in
in
pursuing
this
direction,
then
then
I
certainly,
I
think
it's
a
good
time
to
start
on
a
on
a
draft,
and
I
would
be
happy
to
participate
in
writing
that
draft.
A
I
think
that's
a
great
starting
point.
I
take
zahed's
point
about.
Let's
have
some
text
which
gives
us
the
kernel
around
which
the
grain
of
sand
around
which
we
can
build
a
pearl.
It
might
take
us
a
while
to
get
there,
but
it
means
we
have
something
to
point
to,
because
I
was
looking
back
through
the
history
we
had
an
interim
on
naming
and
addressing
in
may
2021
where
a
lot
of
these
things
were
introduced,
but
we
have
many
slide
decks
talking
around
this,
but
I
think
zahed
makes
a
very
good
point
about.
A
Let's
just
try
and
get
some
text
there,
and
then
we
can
have
vigorous
and
practical
discussion
on
the
mailing
list
to
really
hone
it
down
to
something
brilliant.
Thank
you,
scott,
and
that
doesn't
necessarily
mean
scott.
You
have
to
do
it.
It
means
if
somebody
is
feeling
bold,
go
for
it
collate.
What's
out
there
or
put
your
own
ideas
and
put
it
in
text
and
that's
I.
There
is
no
problem
with
having
three
documents
that
take
different
approaches
that
that's
great.
We
can.
D
A
Can
we
can
proceed
in
that
way?
We
have
three
minutes
left
that
we.
D
A
Hint
to
ed
there
was
the
compressed
bundle-
header
registry
ayanna-
I'm
not
sure
if
you
wanted
to
mention
that
or
if
yeah
any
other
general
topics.
This
is
your
chance
to
jump
to
the
queue.
B
All
right,
so
so,
while
we're
waiting
I'll
unlock
the
queue,
so
while
we're
waiting
for
people
to
jump
into
the
queue
two
things
real,
quick,
one
observation
that
we
we
seem
to
have
no
problem
filling
in
two
hours
and
more
sessions,
hopefully,
will
be
available
to
us
at
1
15..
B
The
second
is
a
question:
should
we
try
and
have
an
interim
meeting
before
1
15.
to
try
and
pick
up
on
some
of
the
the
naming
and
addressing
workshop
that
we
weren't
able
to
get
to
today?
To
I
think
eric's
point
earlier.
There
is
a
real
question
as
to
how
are
nodes.
How
are
eids
used
not
just
used
from
a
routing
perspective?
How
are
they
used
from
a
security
perspective?
How
are
they
used
from
a
custody
perspective?
B
How
are
they
used
when
we
define
contact
plans
or
things
of
that
nature
very
concerned
about
the
idea
that
a
bundle
may
be
identified
using
one
dtn
scheme
and
then
at
a
waypoint
node
or
at
a
destination
security
policy
or
other
policy
may
be
using
a
different
eid
scheme
and
what
happens
in
those
cases?
I
think
that
this
is
going
to
push
us
to
creating
some
kind
of
structure
to
to
our
eid
scheme
names,
but
perhaps
not,
and
I
think
we
need
to
understand
how
do
we?
B
How
do
we
exist
with
multiple
names
for
for
the
same
nodes,
multiple
names
for
the
same
eids
and
what
is
that
practical
cascade
into
security,
routing
custody,
reliability,
quality
of
service
and
other
things,
and
I
think
until
we
really
get
a
handle
on
that,
we
should
not
be
going
too
deep
into
the
users
of
dtn
names
until
we
get
the
naming
itself
done.
So
I
I
would
recommend
that
we
have
an
interim
meeting
between
now
and
115.
A
Thanks
ed,
I
100
agree
with
you
and
as
co-chairs,
let's
just
get
that
arranged
and
and
if
public
proper
size
it
on
the
list
and
if
nobody
turns
up
that's
fine,
we
could
just
shut
the
queue.
So
I
I
think
fully
support
that
go
ahead.
Scott
keep
it
short
because
we're
over
running
and
they're
going
to
turn
our
mic
off
very
soon.
F
Right
very
briefly,
I
think
this
would
of
course,
be
very
controversial.
I
think
we
should
settle
on
one
eid
scheme.
It
should
be
no
numbers,
and
I
think
that
the
resolution
of
names
to
numbers
should
be
a
a
a
local
implementation
matter,
supported
by
the
capabilities
provided
by
the
the
networks
within
within
which
the
the
nodes
are
located,
and
I
will
I
see
I
see
glee
I
will
I
will.
I
don't
desist.
A
It's
it's
glee,
because
I
think
you
should
put
that
on
the
mailing
list,
because
it's
been
quiet,
I
think
an
enormous
amount
of
feedback
will
come
off
the
back
of
it.
We
will
all
be
positive,
but
I
think
it
will
be
vigorous
discussion
around
that
subject
and
I
look
forward
to
seeing
the
mailing
list
light
up
with
debate
on
that
subject.
A
Meanwhile,
thank
you
very
much,
everyone
for
your
attendance
in
strange
time
zones
and
in
person
it's
been
great
to
meet
some
of
you
after
two
and
a
half
years
in
person
again,
and
I
look
forward
to
seeing
you
at
our
interim
and
also
in
london
and
speak
to
you
on
the
mailing
list
as
well.
Thank
you
very
much
for
your
attendance.