►
From YouTube: IETF-DTN-20210527-2000
Description
DTN interim meeting
2021/05/27 2000
A
A
A
Excellent,
in
which
case
I
I
shall
go
through
the
the
slides
we've
got
for
starting
with
the
agenda.
So
most
importantly,
this
session
is
being
recorded
and
here
are
the
links
to
the
agenda,
the
participant
guide
for
those
who
haven't
participated
in
a
interim
meeting
or
an
ietf
meeting
at
all
the
there's.
A
So
as
this
is
the
ietf
meeting,
it
is
covered
under
the
note.
Well,
if
you
have
not
read
the
note
well
before
or
unfamiliar
with
it,
I
thoroughly
recommend
you
read
it.
It
has
important
information
to
state
about
ipr
disclosures,
which
is
obviously
a
concern
to
people.
If
you
are
familiar
with
the
note
well,
here
is
a
copy
of
it.
I
suggest
you
stay
abreast
of
any
changes,
I'm
not
aware
of
any
recent
changes,
but
there
it
is.
A
Please
make
sure
you
read
and
understand
the
the
content,
so
our
agenda
has
formatted
poorly
when
this
got
converted
into
a
pdf
for
which
I
can
only
apologize
yeah.
That's
that's
formatted
really
badly.
I'm
sorry
about
that.
So
I
will
be
ed
and
I
will
just
be
doing
a
bit
of
admin
at
the
beginning,
which
I'm
doing
at
the
moment.
A
Then
we
have
split
the
session
into
two
halves.
The
first
half
is
a
discussion
of
the
working
group
rechartering
and
hopefully
a
chance
to
workshop
through
some
of
the
proposed
text.
We
have
to
try
and
achieve
a
consensus
from
the
working
group
in
terms
of
some
text
we're
all
happy
with
which
outlines
the
topics
we
wish
to
work
on
in
the
next
iteration
of
this
working
group.
A
If
at
all-
and
so
we've
set
aside
an
hour
for
that
with
a
bit
of
introduction,
followed
by
some
collaborative
time,
it
may
take
less
than
an
hour,
I
don't
really
want
it
to
run
longer
than
an
hour.
So
we'll
probably
draw
a
hard
line
at
one
hour
after
that,
we've
dedicated
the
second
half
of
the
session
to
a
general
discussion
of
naming,
addressing
and
perhaps
a
bit
of
forwarding
it,
because
I
think
they're
all
related
personally,
where
marius
feldman
is
going
to
discuss
or
present
some
of
his
ideas.
A
I've
pre-read
his
slides
and,
I
think,
they're
really
nice
overview
of
some
thoughts
about
naming
and
addressing,
which
is
great.
I've
got
a
another
quarter
now
piece
after
that,
where
I'm
going
to
present
some
some
basic
frameworks
and
then,
as
has
dropped
off
the
bottom
of
the
screen,
and
I
can
only
apologize
for
that.
A
And
then,
of
course,
there
is
a
10-minute
standard,
any
other
business
open
mic
at
the
end
of
the
session,
which
we
hopefully
will
or
hopefully
won't
be
needed
for
any
other
business,
but
and
also
can
be
consumed
as
any
slack.
We
have
a
hard
cut
cut
off
for
two
hours
because,
frankly,
in
europe
it
gets
quite
late
and
also,
I
think,
meet
echo
turn
them
turn
us
off
after
two
hours.
A
There
may
be
five
minutes
of
extra
time,
but
we
could
do
some
meeting
bounds,
so
administrative
meet
echo
since
I
wrote
these
slides
actually
has
got
quite
good.
But
of
course
this
is
the
internet.
Things
do
occasionally
take
a
moment
to
get
from
your
button.
Click
to
the
server
in
some
part
of
the
cloud
somewhere
and
to
everyone
else.
So
just
be
a
little
bit
patient
when
you're
clicking
your
buttons
like
mad
adam,
is
our
secretary
and
he's
going
to
be
taking
minutes.
A
A
If
you
have
a
name
which
is
a
longer
than
three
letters,
it's
probably
worth
checking
that
that
adam
has
heard
it
clearly
or
you
know,
urls
for
the
mailing
list,
so
dtn
itf.org,
please
subscribe
to
the
mailing
list
if
you're
not
already
subscribed,
because
that
really
is
the
record
of
the
work
of
the
group
and
if
you
need
to
contact
the
chairs
about
anything,
administrative
or
just
general
questions
about
the
workings
of
the
dtn
working
group.
We
are
dtn
hyphen
chairs,
ietf.org.
A
A
B
B
So
as
as
hopefully
many
of
you
are
aware,
we
we
really
have
gotten
through
just
about
all
of
the
initial
work
items
and
all
of
the
significant
work
items
that
are
in
the
current
charter.
So,
in
order
for
us
to
proceed
with
really
a
large
backlog
of
information
and
ideas
and
new
challenges
to
tackle,
we
need
to
be
working
under
the
auspices
of
a
charter.
B
A
Sorry,
I
was
on
mute.
No,
I
think
I
think
that's
covered
it.
Actually,
yes,
one
thing
which
is
recently
when
it's
come
to
other
working
groups.
Rechartering
the
isg
has
pushed
back
quite
heavily
to
say
working
groups
should
try
and
generate
documents
of
value
so
that
that's
that
bullet
point
I
put
at
the
bottom,
which
is
you
know
the
itf's,
not
a
general
publication,
a
general
publisher.
A
If,
if
we're
going
to
spend
time
and
effort
within
a
working
group
and
getting
isg
review
and
the
rfc
editors
etc,
it
has
to
be
a
document
of
value.
That's
nothing
against
people
saying.
Oh
I've
got
a
personal
draft
about
this
really
cool
subject.
I
would
like
to
expose
you
all
to
it
that's
great,
but
we
have
to
make
sure
that
work,
items
and
things
we
commit
to
in
the
charter
have
value
other
working
groups.
A
When
rechartering
have
been
criticized
for
saying
we
will
write,
use
cases
documents,
we
will
write
requirements
documents
we
will
require
rights,
best
practices,
informational
stuff.
The
isg
would
like
to
see
some
focus
in
work.
That's
all!
I
don't
think
I
don't
think
we're
suffering
from
that,
but
I
I
just
wanted
to
underline
it.
B
So
so
I
will
not
read
the
current
charter.
I
know
that
we
we
have
it,
but
essentially
what
we
wanted
to
accomplish
in
that
charter
was
going
back
through
and
taking
some
of
the
work
out
of
the
irtf.
Applying
lessons
learned
to
those
critical
pieces.
The
transport
protocol
bundle
protocol
security
protocol
associated
with
it
convergence
layers
and
so
on.
We
have
done
that.
A
B
B
The
the
second
general
category
is
to
try
and
understand
and
capture
those
additional
protocols
and
best
practices
for
the
next
stage
of
deployment
of
dtn,
which
is
naming
addressing
forwarding
key
management
operation
management
to
include
network
management,
and
then
the
last
is
to
the
extent
that
in
our
current
work,
we
have
laid
out
infrastructure
that
can
be
populated
and
extended
by
security
context
by
additional
extension
blocks
by
additional
convergence
layers.
The
hard
work
in
many
of
those
was
defining
that
first
instance,
the
first
convergence
layer,
the
first
security
context.
B
A
B
A
We
were
suggesting
just
to
give
us
an
indication
of
whether
there
is
active
interest
in
doing
this
work
and
again
I
have
picked
one
document
when
there
are
many,
for
example,
I
know
asynchronous
management
has
actually
has
several
drafts
associated
with
it.
I
believe
the
bundle
and
bundle
encapsulation
has
several,
but
mostly
because
the
names
have
changed
around
and
things
like
that.
So
so
this
is
just
saying:
look,
there
is
a
document
that's
already.
Some
of
these
have
expired,
but
it's
been
within
the
last
18
months
that
these
things
have
expired.
A
These
aren't
2012
documents,
so
this
should
give
us
a
sort
of
snapshot
on
a
page
to
show
interest
in
doing
the
work.
My
apologies
to
scott
burley,
who
is
the
champion
of
custody
transfer.
I
couldn't
actually
find
a
recent
draft
explicitly
addressing
addressing
custody
transfer.
I
think
it's
alluded
to
in
the
extended
class
of
service
draft
along
with
quality
of
service.
I
think
the
two
get
sort
of
concatenated
in
one
draft
there,
but
what
I
find
interesting
from
this
is
the
gaps.
A
So
there
is
no
existing
draft
which
tackles
naming
addressing
and
forwarding,
and
that
is
interesting
because
we
propose
some
of
these
items
at
ietf
110.
The
last
ietf
meeting
and
there's
been
some
discussion
on
the
list
between
then
and
now,
and
everyone
seems
fairly
sure
that
naming
and
addressing
is
a
really
obvious
thing.
We
ought
to
be
working
on
and
nobody
has
suggested
anything
yet
read
into
that
what
you
like
new
extension
blocks.
A
A
Of
course,
yeah
yep
yep.
Of
course,
I'm
going
to
be
really
cheeky
because
martin
duke
is
in
the
audience,
and
he
is
unfortunately
our
current
a.d.
Oh
yeah,
mark
I
spot
you
in
the
queue
I'm
going
to
ask
martin
to
join
the
queue
if
he
doesn't
mind,
because
our
current
ads
ahead
unfortunately,
is
is
not
well
and
martin
is
covering
for
him,
and
I
want
to
ask
a
couple
of
questions
of
martin
but
go
ahead.
First
mark.
D
A
It-
and
I
will
I
I
as
a
shorthand,
I
sort
of
folded,
that
into
naming
and
addressing
because
a
service
identifier
is
a
sort
of
address,
and
so
on.
I
I
am
very
aware
that
you
have
previous
work
that
you're,
refreshing
and
continuing
so
yeah.
Absolutely
that's
an
example
of
something
which
you
know
you're
actively
engaged
in
and
doesn't
seem
contrary
to
the
to
the
general
direction
of
what
we're
proposing.
So
that's
brilliant
martin,
my
question
to
you
is
concerning
rechartering.
E
Desirable
making
its
decision,
if
I'm
here
as
a
surrogate
and
I
don't
have
a
ton
of
we
haven't-
had
a
chance
to
discuss
in
detail
what
you've
been
looking
for
here.
My
initial
reaction
to
this
is,
it
seems,
like
a
lot
yeah
there's
a
lot
of
documents
that
I
think
I
don't
that's.
I
mean
I
don't
have
a
great
feel
for
this
working
group,
but
it
seems
like
that,
could
really
defuse
the
energy
in
a
lot
of
ways,
and
you
know
the
maintenance
around.
A
E
E
If,
if
there's
a
lot
of
trouble
with
applying
things
or
alternatively,
if
it's
heavily
deployed
what
the
what
the
actual
operational
problems
out
there
are
that
are
they're
most
demanding,
because
I
know
all
this
stuff
taking
the
itf
documents
and
updating
them
is
a
great
idea,
but
are
they?
Is
there?
Are
the
real
world
problems
right
now
associated
with
that?
Or
is
it
or
is
it
kind
of
okay?
A
I
I
ed
has
a
lot
more
experience
with
real
world
implementations
than
me,
and
I
know
scott
burley
does
as
well,
so
I'm
gonna
defer
to
them
to
to
highlight
things,
but
I
do
take
your
point
and
ed
and
I
were
discussing
this
earlier.
This
is
a
big
list
compare
with
the
table
of
things.
People
are
working
on,
it's
great
that
there's
the
interest,
but
it
is
still
a
big
list
of
of
things
and
that
that
was
one
of
our
concerns
is.
B
B
And
what
we
found
is
that
many
people,
because
there
was
not
additional
remaining
technical
work
to
do
in
the
core
transport
and
security
protocols,
made
really
a
lot
of
progress
in
some
of
these
other
areas.
And
so
some
of
these
other
specifications
are
years
in
the
making
at
this
point
and
are
really
quite
mature.
And
so,
while
you
look
at
the
number
of
documents,
it
is
a
large
number
of
documents,
but
some
of
them
are
probably
70
to
80
percent
complete
because
the
working
group
did
have
that
extra
time.
B
While
these
other
documents
were
going
through
and
and
we
are
trying
to
be
respectful
of
the
fact
that
if
something
is
very
mature
and
has
already
been
discussed
in
the
working
group
and
and
is
in
that
sort
of,
you
know,
20
to
30
40
percent-
complete
20
30
percent
complete.
We
want
to
make
sure
that
that's
looked
at
as
well.
A
D
You
know
one
of
you
know
the
use
cases
were
about,
you
know
from
you
know,
experimental
to
real
deployment
and
standards,
and
some
of
the
use
cases
are
were
showing.
You
know
scale
right
more
than
you
know,
a
few
nodes
that
we
are
doing
at
the
moment
and
to
me
scale
mean
something
we
haven't
done
yet,
which
is
naming
addressing
and
forwarding
to
the
next
level
yeah
right.
I
think
this.
D
A
I
I
completely
agree
personally,
I
in
I'm,
going
to
turn
my
camera
off,
because
I'm
I'm
suffering
from
lag,
and
I
I
completely
agree
because
I've
got
in
the
second
half
of
this
meeting.
I
got
a
presentation
talking
about
naming
and
addressing
at
scale
and
with
the
ietf,
we're
all
about
interconnectivity
at
scale,
small
little
subnets
that
doesn't
need
the
ietf
and
that
doesn't
need
standardization,
I'm
not.
A
A
B
Are
there
specific
documents
that
you
feel
are
missing
from
that
and
when
I
say
documents
I
mean
topics
as
rick
mentioned
before
some
of
the
topics
have
multiple
personal
drafts
associated
with
them.
But
if
something
significant
is
missing
once
we
understand
whether
our
categories
are
correct
and
whether
the
existing
list
is
complete,
then
I
think
there's
a
separate
step
which
is
coming
back
and
and
trying
to
determine
whether
we
think
anything
that
is.
There
should
not
be
there
because
it
doesn't
match
this
draft
charter
so
so
rick.
A
Okay,
so
I
can
only
do
one
show
of
hands
at
once,
and
so
I
have
kicked
off
a
question
entitled.
Do
you
think
there
is
an
additional
category
of
work
items
that
we
have
missed.
Ray's
hand
means
yes,
so
I'll.
Just
give
that
a
moment
to
see
what
trickles,
through
adam
you're
in
the
queue?
Would
you
like
to
say
something
while
people
work
out
how
to
click
the
buttons.
G
A
A
A
So
I'm
just
having
a
quick
count
of
how
many
people
are
actually
online
and
thinking
of
calling
ed.
Would
you
like
to
try
and
summarize
your
second
question
in
the
show
of
hand
tools,
I
think
I'm
going
to
take
I'm
going
to
end
the
session
on
this
one
because
I'm
oh
a
couple
of
seconds,
I'm
going
to
click
end
session
soon.
So,
if
you're
keen
press
your
button
now.
B
H
B
A
How
do
you
forward
if
you
don't
know
who
your
neighbors
are
yeah,
but
then
everything
goes
into
naming
and
addressing
I.
I
am
very
wary
of
trying
to
do
routing
before
we've
worked
out
how
to
do
this.
The
simple
cases
first,
I
I
I'm
happy
to
be
argued
down,
but
I
just
get
the
feeling
that
if
we
were
to
say
we're
going
to
do
routing
in
this
recharger
cycle,
I
think
we
could
burn
three
years
on
probabilistic
forwarding
versus
contact
graph
versus
proactive
routing
from
inherited
from
man.
A
Oh
that's
an
ieee
example
really,
I
suppose
the
broadband
alliance
do
a
sort
of
accreditation
of
home
based
ip
equipment,
the
avnu
forum
to
accreditation
of
deterministic
networking,
so
the
ietf
helps
set
the
standard,
but
that
quality
assurance
test
and
accrediting
is
left
to
external
bodies,
but
that
doesn't
prevent
us
understanding
the
use
cases
that
those
bodies
need
or
or
anyone
trying
to
accredit
and
stand
or
and
quality
confirm
their
their
products.
In
terms
of
how
do
I
test
this.
A
A
I
H
B
Also
just
to
just
to
add
to
that
again,
if,
if
some
of
our
prioritization
is
based
on
what
is
needed
for
the
operation
of
these
networks
and
if
oscar
some
of
your
testing
is
the
operational
deployment
of
these
networks,
then
even
if
we
don't
have
a
first-class
testing
document,
that
experience
is
part
of
both
the
prioritization
and
development
of
the
other
standards.
We
would
produce.
A
J
A
A
A
D
B
E
Yeah,
so
my
other
advice
would
be
that
our
observation
would
be
that
that,
like
this,
so
as
you
said,
some
of
these
are
quite
mature,
like
we've
reached
something
like
consensus
and
it'll
be
fast
and
and
I'm
pretty
comfortable,
having
a
fairly
large
number
of
that
as
long
as
we
have
the
review
bandwidth
to
get
through
it
all
this
name
interesting
and
forwarding
thing.
I
agree
it's
important.
E
I
also
am
concerned
this
could
be
a
10-year
journey
and
and
like-
and
I
think
the
word
like
the
worst
outcome
in
this
charter-
is
that
you
know
we.
We
come
to
set
milestones,
that
solomon
are
six
seven
years
out
and
then
we're
kind
of
wandering
in
the
desert
for
an
extended
period
of
time
without
having
to
check
of
another
recharger.
E
So
I'm
again,
I'm
pretty
comfortable
with
a
large
number
of
kind
of
finite
time
milestones
that
are
driven
by
this
charter
that
are
put
in
there.
I
appreciate
rick's
effort
to
like
chop
up
the
like
this
big,
like
network
player
rattling
addressing
forwarding
thing
into
a
smaller
bit
so
that
we
don't
end
up.
You
know
having
a
milestone,
takes
10
years
to
deliver,
but
I'm
not
sure
given
the
lack
of
even
having
a
framework
on
how
to
do
this.
E
That
we've
found
the
right
building
block
here,
that's
kind
of
achievable
and
in
excess
in
a
reasonable
amount
of
time,
and
one
solution
may
be
to
to
not
have
available
in
this
area
and
just
like.
While
we
continue
to
finish
the
other
stuff,
let
people
noodle
on
it.
Another
thing
is
that
we
could
have
some
sort
of
you
know
working
group
document
that
that
writes
something
down
that
could
be
a
milestone.
E
A
Protocol
version
7
just
to
make
sense
we're
going
to
studiously
ignore
it
until
it
becomes
a
major
issue
so
yeah
I
I
agree,
sort
of
breaking
it
into
chunks
and
perhaps
going
against
my
previous
comment
about
you
know,
framework
documents
or
best
practices
or
informational
stuff,
perhaps
an
informational,
an
architecture
on
naming
and
addressing
which
introduces
some
concepts
that
could
be
used
elsewhere.
Maybe
the
maybe
a
way
to
make
progress.
A
E
Yeah
what
I
know
what
I
just
say
to
nobody:
oh
yeah,
so
I
don't
I
don't.
I
don't
want
my
comments
to
be
construed
as
we
should
work
on
this.
I
think
we
should
work
on
it.
Clearly
it
needs
a
lot
of
initial
work.
I
just
don't
want
to
set
up
the
expectation
that,
under
this
charter,
will
necessarily
solve
this
entire
problem.
B
B
K
K
B
I
completely
agree,
and-
and
what
I
was,
what
I
would
propose
is
to
project
these
items
and
then
make
sure
that
neighbor
discovery
and
service
identifiers
are
included
in
this
list
and
then
do
one
last
poll
to
say.
Do
we
think
that
there
are
things
here
that
we
think
should
be
removed
from
this
list,
separate
from
whether
we
think
things
are
are
low
effort
to
complete,
because
they're
very
mature.
A
Or
take
that
into
consideration
as
part
of
part
of
the
decision
I
mean
we
could
just
do
this
as
a
show
of
hands.
We've
got
a
quarter
of
an
hour
artificially
a
quarter
of
an
hour
because
we
can
eat
into
the
next
next
half
of
this.
If,
if
we
need
to
because
this
is
important,
do
we
want
to
go
through
these
one
by
one
and
do
a
show
of
hands
and
say
you
know,
do
you
think
this
should
stay
on
the
list.
A
A
B
So
my
question
to
that
is
so
one
a
a
comment.
I
I
agree
that
if
we
could
find
areas
where
ccsds
was
was
advancing
standards
that
that
we
could
in
iatf
point
to
that.
That
is
a
good
way
of
distributing
that
work.
Do
you
feel
that
the
the
standard,
the
mechanism
or
the
way
in
which
ltp
fragmentation
would
be
accomplished
would
be
significantly
different
if,
if
it
happened
in
the
in
ccsds,
without
some
of
those
other
parties,
as
part
of
the
discussion.
C
A
Yep
I
mean
there's,
there's
nothing
wrong
with
that
model.
I
mean
if,
if,
if
somebody
comes
forwards
or
a
group
of
people
coming
or
an
sdo
comes
in
and
says,
I've
got
a
very
mature
document
that
I'm
willing
to
work
hard
to
get
polished,
there's
not
miles
off
the
charter.
There's
not
a
problem
with
someone
working
on
it.
Okay,
so
that
was
my
comment
on
ltp.
Does
someone
want
to
step
forwards
and
vote?
It's
like
a
game
show
now
vote
to
work,
item
off.
C
H
C
A
convergence
there
protocol
that
is
essentially
bundled
protocol,
then
the
features
of
that
convergence
layer
protocol
ought
to
be
the
the
ones
that
involve
bundles
such
as
custody
transfer.
So
I
think
it's
the
one
place
for
it,
and
I
I
agree
that
having
a
separate
item
for
custody
transfer
should
come
off
the
list.
A
L
Hear
me
now:
yes,
great
yeah,
so
this
is
felix,
so
I
think
what
we
have
in
terms
of
custody
transfers
abundant
button
encapsulation
is
slightly
different.
What
we
used
to
have
in
bundle
protocol
version
six
so
for
custody
transfer
and
one
encapsulation.
I
basically
decide
when
I
send
my
bundle,
who
is
going
to
take
custody
of
that
yeah,
because
I
have
to
address
this
as
endpoint
for
the
encapsulated
bundle
with
the
mechanism
we
used
to
have
before.
L
Basically
any
node
along
the
way
could
say:
okay,
now
I'm
ready
to
take
custody
for
this
bundle
and
take
care
of
the
delivery
for
running
of
this
bundle.
So
I
think
we
might
still
need
a
similar
mechanism
like
this
you're
having
that
this.
This
is
also
something
which
could
be
addressed
in
ccsds
if
it's
not
of
general
interest.
A
Point
taken,
I
I
share
some
of
your
opinions
about
sort
of
predetermined
custody
transfer
where
you
you,
you
as
a
sender
you
select,
who
is
going
to
take
ownership
as
compared
to
sort
of
ad
hoc
custody
transfer
where
good
samaritan
nodes
along
the
path
say
I'll
hold
that,
for
you
there's
elements
of
trust
involved
and
so
on.
I
wonder
whether
that
we
should
possibly
say:
let's
defer
that
work
to
a
to
the
next
rechartering,
because
it,
I
think
it
needs
more
supporting
technology
that
we
haven't
got
yet.
L
A
B
B
I'm
trying
to
understand
whether,
if
ccsds
is
able
to
in
a
parallel
way
look
at
custody
acceptance
mechanisms,
whether
that
manifests
in
the
ietf,
as
as
as
the
update
to
bib
e,
as
opposed
to
its
own
custody
work
item.
So
I'm
still
trying
to
understand
whether
in
the
charter,
bundle
and
bundle,
encapsulation
is
the
most
recent
thing
to
speak
to
custody
transfer,
and
if
we
need
other
mechanisms,
they
can
come
later
in
a
different
recharge.
A
C
I
I
see
the
appeal
implementation
experience
has
has
not
been
encouraging,
so
I'm
I'm
not
a
fan
of
that.
But
if
we
need
to
discuss
it,
then
I
think
maybe
a
discussion
of
that
topic
could
happen
in
the
course
of
working
on
the
bundle
and
button
encapsulation,
slash,
custody
transfer
and
if
it
looks
like
there's
something
practical
that
needs
to
happen
there,
then
maybe
we
could
just
break
it
out
rather
than
have
a
separate
item
for
it.
Now.
K
I
wasn't
going
to
download
anything,
but
I
do
agree
with
you
and
scott
that
I
really
would
like
to
see.
Bundling
bundle
encapsulation
in
the
keep
list,
I'm
more
than
happy
to
volunteer
to
work
on
it
in
any
capacity
and
doing
it
in
a
way
that
does
not
include
custody
transfer
is
very
important
for
security,
but
we
could
potentially
have
some
material
that
reaches
into
that
as
well.
A
I
think
that's
a
pragmatic
approach.
I
I
I
like
that.
I
I
think
everyone's
roughly
in
favor
of
definitely
bundling
bundle
and
custody
transfer
seems
like
a
subject.
That's
that's
close
to
people's
hearts
and
there's
interest.
So
I'm
I'm
just
going
to
leave
those
on
the
stay
in
list.
Whether
custody
becomes
a
kind
of
stretch
goal
and
we
don't
get
too
caught
up
in
trying
to
deliver
it,
but
definitely
bundle
and
bundle.
A
So
I
know
brian
cpos
is
doing
great
work
on
aligning
the
cosy
security
context
because
we
are
building
dtns
around
the
seabor
encoding
and
cosy
is
the
and
carsten
is
on
the
call.
So
he
can
correct
me
when
I
get
this
completely
wrong.
The
correct
way
of
encapsulating
key
material
and
securing
seabor
encoded
objects.
A
So
it
makes
obvious
sense
to
have
some
sort
of
foot
over
into
the
into
the
cozy
way
of
doing
security
context,
which
fits
into
bp
sec.
But
I
wonder
whether
it's
worth
adding
a
saying
that
we're
going
to
work
on
yet
more
security
contexts
or
whether
that
should
be
something
that
national
government
organizations
or
other
sdos
can
go
and
define
for
their
own
purposes,
using
the
framework
we've
already
laid
out
in
dpsec.
A
J
No,
I'm
not
correcting
you.
Actually,
you
have
to
do
more
work,
because
cosi
gives
you
a
heap
of
lego
bricks
and,
and
that
that's
great
for
for
building
something,
but
you
still
have
to
do
the
building,
so
the
the
flows
that
that
you
want
to
use
who
actually
manages
what
and
signs
what
and-
and
what
does
that
mean
and
so
on
that
has
to
come
from
you
and
not
from
cozy.
C
C
A
I
I
I
agree
with
you
so
and
hence
I'm
suggesting
we
don't
put
a
line
in
the
chart
in
the
new
charter.
Saying
we're
gonna
do
one
because,
let's
not
commit
to
doing
one
and
that
doesn't
prevent
us
accepting
as
a
working
group
item,
something
as
you
describe
someone
turns
up
and
says:
I've
got
something
really
cool,
it's
really
popular.
It
works
really!
Well
great!
You
know
yeah,
I
think
that's
a
good
way
forward.
Ed.
Do
you
have
any
comment
on
that.
B
So
I
I
I
think
that
security
I
I
I
know
that
other
standards
organizations
are
looking
at
security
contacts.
I'm
sure
that
there
are
others
who
were
going
to
work
on
ones
with
the
idea
of
bringing
them
forward
later
you
know
is:
is
there
a
sort
of
a
concern
with
working
group?
You
know
focus
on
this.
B
Is
the
cosi
context,
one
of
those
things
that's
95
done
or
do
we
feel
that
when
it
gets
into
larger
review
it
could
turn
into
three
years
of
iteration
and
and
to
parsons
point
the
you
know
the
code
issue,
the
lego
bricks
and-
and
we
feel
that
as
a
community,
we've
reviewed
this
enough
to
understand
that
the
overarching
flows
are
understood
or
not
that
that
to
me
is
the
risk
of
adopting
it.
At
this
point.
M
A
Which
is
great
and
then
what
I
wanted
to
be
careful
to
say
was:
I'm
I'm
not
suggesting
that
what
you're
working
on
is
completely
out
of
scope,
because
I
know
you've
been
working
on
it
fairly
extensively,
and
I
I
have
an
understanding
that
it's
the
thing
about
a
context.
Is
it
tells
you
how
to
do
something
in
in
rough
handfuls,
and
I
know
some
of
more
details
which
is
fine.
A
A
Oh,
ask
it
it's
a
single
yes,
no
question:
do
you
want
another
15
minutes
discussion
on
charter
items
with
typos?
So
if
you
can
just
let
me
know
whether
you
want
to
continue
this
any
longer,
otherwise
we
can
switch
across
to
the
second
half
of
our
agenda,
which
is
marius.
Feldman
has
some
interesting
points
to
make
about
naming
and
addressing
as
a
topic,
I've
got
a
personal
proposal
about
just
trying
to
draw
out
a
framework
for
discussion
for
that
sort
of
thing.
A
And
then
I
think
we're
gonna
move
on
to
the
second
half
of
the
presentation.
If
that's,
okay,
I'm
sorry,
we
will
take
this
to
the
list.
The
chairs
will
amend
the
text
as
we've
currently
got,
possibly
even
just
enumerate
the
work
items
in
a
big
list,
and
then
we
can
all
have
an
enormous
argument
about
which
ones
stay
and
which
ones
go.
A
A
A
So
what
we'll
do
now
is
we'll
switch
over
to
the
second
half
of
the
session,
which
is
a
bit
more
of
a
a
general
discussion,
perhaps
a
bit
of
workshopping
a
bit
of
brainstorming
about
what
we
understand
as
naming
and
addressing,
and
what
we
consider
to
be
the
challenging
issues.
What
we
individually
personally
or
publicly
are
willing
to
say
is:
oh
no.
We
fixed
this.
I
have
the
perfect
idea.
A
That's
quite
a
bold
statement!
Good
luck!
If
you
want
to
come
out
with
that,
but
yeah
you
get
the
gist
of
it.
So
so,
first
off
marius
feldman's
done
a
really
nice
piece
on
his
view
of
where
we
ought
to
be
going
with
naomi
and
addressing
so.
I
will
find
that
marius
are
you
there
are
you?
Would
you
like
me
to
present
the
slides,
or
do
you
want
to
show
your
own
screen
I'll
control
it?
L
L
Perfect
so
yeah,
it's
always
a
bad
thing
after
somebody
else
has
said
that
you
prepared
a
very
good
presentation
to
then
give
the
presentation.
So,
let's
see,
if
it's
very
good
yeah,
I
would
like
to
to
share
some
some
thoughts,
some
that
we
had
regarding
naming
and
addressing
in
ddns,
and
we
call
that
presentation,
rhino-ish
sorts.
L
L
L
L
Protocol
stack
are
solved,
leveraging
rhino,
which
is
a
as
I
said,
recursive
approach,
so
where
the
core
idea
is
that
you
have
a
clearly
defined,
very
small
set
of
items
that
can
be
applied,
recursively
on
different
layers
and
could
be
adapted
to
different
needs
based
on
configuration,
so
just
to
give
a
very
short
insight
into
this
clean
structure.
You
see
an
image
here
on
that
slide,
where
we
have
well.
L
These
node
addresses
that
are
independent
from,
for
example,
then
concrete
interfaces
or
so
called
point
of
attachment
addresses
which
well
then
are
introduced
introduced
on
the
layer
on
below
that
that
layer.
So
why
am
I
mentioning
that?
Well,
what
you
can
see
here
directly
in
this
this
figure
is
that
the
terms
are
quite
clearly
defined.
So,
for
example,
you
have
this
term
of
a
route.
L
We
see
some
issues
as
I
will
discuss
in
a
second
by
the
way
these
things
we
are
doing
is.
They
are
currently
well
addressed
in
a
funded
project
that
is
operated
for
more
than
one
additional
year
now,
which
is
called
red
mars,
and
it
tries
to
transfer
different
things
from
the
reina
domain
to
the
dtn
domain.
So
it's
not
about
well
making
or
setting
up
a
rhino
network
based
on
on
dtn
fragments
or
something
like
this
or
the
other
way
around.
L
L
Additionally,
so-called
titles
are
within
the
the
rhina
proposal,
and
so
these
things
well
are
briefly
mentioned
on
that
slide
here,
so
that
the
well
name
as
you
may
be
aware
about
that-
I
guess
is
a
unobitus
lead
denoted
or
it
denotes
unrebiculously
some
object
and
it
makes
no
statement
first
of
all
about
well
some
topological
information
and
there
comes
then
a
differentiation
between
an
address
and
a
title
so
address
while
passes
topological
information
inside.
So
it's
a
topologically,
significant
name
and
title
well.
L
So
if
this
are,
for
example,
titles
or
addresses
so,
for
example,
well
during
discussions
in
the
community,
I'm
aware
about
the
aspects
that
erds
are
names,
but
are
they
maybe
also
titles?
Sometimes
are
they
well
only
addresses?
This
is
not
clearly
defined,
and
that
makes
it
really
difficult
to
well
discuss
about
when
naming
and
addressing
concepts.
L
So
our
idea
here
would
be
to
have
a,
for
example,
informational
or
rfc
setup,
where
we
try
to
give
some
explanations
and
try
to
to
fix
things
here
in,
in
the
sense
that
we
provide
clear
definitions
on
what
these
things
are
and
for
sure
it
may
be
the
case
also
that
yeah
eids
are
not
well
strictly
addresses,
always
or
strictly
titles
or
always,
or
they
may
be
something
in
between
or
case
dependent.
Sometimes
titles
sometimes
addresses,
but
I
think
also,
this
aspect
has
to
be
clearly
stated,
based
on
a
well-defined
vocabulary.
L
L
Well,
the
title
pointed
out,
and
it
has
a
very
well
generic
characteristic,
which
is
also
a
difficult
thing
to
do
to
achieve.
Actually
so
in
german
there's
a
saying
that
the
art
of
composing
is
to
leave
out
unnecessary,
unnecessary
notes,
the
components
is
vectors
and
there
you
go
in
german.
So
I
think
the
bundle
protocol
is
really
good
starting
point
and
it's
not
about
changing
anything
in
that
protocol
at
all.
L
But
it's
about
well
providing
clear
definition
for
things
and
well,
if
there's
not
a
one-to-one
mapping,
but
a
one-to-n
mapping
or
with
n
well
greater
than
one
it's
necessary,
also
to
state
that
explicitly
so
well.
This
is
the
first
point
that
we
wanted
to
make
here
so
while
having
such
a
informational
rc
and
on
the
other
hand,
I
would
like
to
briefly
sketch
a
scenario
to
discuss
well
further
proposal
that
we
would
like
to
to
make.
So,
as
I've
mentioned,
we
went
through
different
scenarios
that
we
we
made
up.
L
L
If
well,
you
have
all
the
topological
information
by
hand
and
distributing
that
information
is
a
difficult
part,
and
we
would
like
to
to
avoid
for
sure,
because
that's
not
not
possible
in
details
to
spread
well
all
details
to
all
notes
so,
for
example,
that
mass
rover
should,
in
our
opinion,
not
not
have
any
information
about
the
orbiting
satellites
because
it
just
doesn't
need
it.
So
it
just
needs
to
know
that
it
will
reach
the
host
on
the
other
side,
while
that
ground
station
that
is
located
on
mars.
L
So
the
details
behind
that
that
may
be
even
well
covered
by
by
own
dtn,
so
there
may
be
arms
and
also
disrupted
links
or
highlighted
ceilings,
and
so
on.
These
are
things
that
that
node
should
not
not
bother
with,
and
it
should
well
for,
should
be
able
to
limit
the
scope
of
of
the
type
of
information
it
receives.
So
we
introduce
different
layers
here
which
well
exactly
result
into
such
a
recursive
nature
of
well
replication
of
the
bundle
protocol.
L
So
there
we
are
again
in
some
sort
of
of
rhino
rhino
thinking,
and
the
idea
here
is
to
have
a
well
a
dti
n,
so
a
sort
of
internet
work
that
is
placed
on
top
of
well
different
dtn.
So
you
see
here
two
ddn's
which
are
in
this
light,
green
and
then
the
darker
green
arm
forms
another
dtn,
and
on
top
of
that
there
is
a
well
internetwork
that
is
also
well
in
the
enter
delay
torrent
network
and
these
two
layers.
L
They
should
not
be
mixed
up,
so
we
should
have
a
clear
separation
of
scopes
here
and
by
this
clear
separation
of
scopes.
We
should
also-
or
we
will
be-
we
make
it
possible
or
render
it
possible
to
reduce
on
the
topological
information
that
is
spread
on
these
layers.
So
that's
a
the
core
idea
here
in
the
end
doing
that
we
are
able
to
also
associate
different
roles
to
eids.
L
So
if
we
have
a
look
at
that
well
dti
and
layer,
for
example,
it's
the
case
that
the
eids
can
be
used
for
routing
on
that
layer.
So
they
are
the
input
for
the
routing
algorithm.
Also,
we
could
extract
well.
Our
node
ids,
for
example,
from
it
and
then
well,
do
the
routing,
on
the
other
hand,
the
erds
they
could
be
used
independently
from
that
layer
as
titles
on
that
below
the
application
layer.
L
So
just
for
the
well
end-to-end
naming
and
additionally,
we
have
passes
that
are
span
between
the
systems
arm
leveraging
as
well
eid.
So
the
pass
determination,
determination
on
the
lower
bundle
protocol
layer
that
is
sketched
here
is
also
done
based
on
these
ids,
which
means,
while
the
erds
are
used
with
reference
to
to
the
to
the
rhino
approach
in
well
different
roles.
So
they
are
used
as
titles
without
any
topological
significance.
They
are
used
as
input
input
to
the
routing
algorithm
and
they
are
used
as
point
of
attachment
addresses.
L
L
We
should
also
point
out
well
in
which
role
these
erds
come
up
in
the
end,
by
the
way,
the
things
that
we
have
just
seen.
So
this
scenario
as
well,
it
requires
bundle
and
bundle
encapsulation,
which
is,
I
think,
a
very
important
feature
for
for
the
bundle
protocol,
because
that
renders
it
also
possible
to
limit
the
scope
of
layers
and
that
renders
it
possibly
to
clearly
separate
layers,
which
also
means
to
separate
the
scope
of
topological
information
and
well,
then,
there's
another
proposal
that
we
make.
L
L
A
A
I
A
I
Okay,
one
one
question
marcus:
this
rhino
model
has
a
any
any
relation
or
to
the
object
or
oriented
handle
model
for
dna
dns
by
bob
khan.
I
don't
know
if
you
know
that
that
is
considering
the
instead
of
the
iraqira
hierarchical
model
as
the
dnss.
Nowadays,
it
considers
them
each
endpoint,
an
object
that
has
in
itself
all
the
capabilities,
all
the
information
about
the
object
that
is
called
and
to
allow
a
better
result.
L
I
Okay,
but
because
I,
when
I,
when
working
in
the
in
the
band
protocol
and
all
this,
I
was,
I
noticed
that
in
a
dynamic
network
that,
like
the
bundle
like
in
a
space
network,
the
the
model
of
the
object
was
more
easier.
Perhaps
for
deploying
a
new
nodes,
more
easy,
more
easier
and-
and
I
think
you
are
taking
the
same
approach
with
the
rhino
model
than
the
hierarchical
model.
A
Thanks
oscar,
I
put
myself
in
the
queue
because
I
wanted
to
say:
thank
you
maris,
you
have.
The
rhino
model
is
actually
the
model
I
believe
in
as
well,
and
I've
got
a
presentation
coming
up
afterwards
and
actually
you've
you've
written
about
four
of
my
slides
in
a
better
way
than
I
could
have
written
them.
A
So
I
I
may
almost
refer
back
to
some
of
your
slides
because
I'm
in
complete
agreement
with
you
building
on
the
great
work
by
john
day
to
say
we
have
to
be
the
difference
between
a
title
and
an
address
is
absolutely
critical
and
one
thing
without
spoiling
my
presentation,
I
think,
there's
an
alternative
to
bundling
bundle
encapsulation,
which
is
actually
to
use
label
switching
but
I'll,
introduce
that
coming
up
and
I'd
like
to
continue
that
conversation
in
a
bit.
But
I
thought
that
was
great.
Thank
you.
L
A
B
Yeah,
so
I
jumped
in
as
well
just
two
things
number
one,
a
very
good
presentation:
question
about
the
eids
when
you
mentioned
on
your
conclusion,
slide
that
eids
would
take
multiple
roles.
Do
you
envision
a
a
part
of
the
scheme
of
an
eid,
asserting
that
it
is
a
particular
role,
or
do
you
believe
that
there
would
be
some
schemes
that,
by
their
definition,
would
only
be
used
for
a
certain
role.
L
A
A
Okay,
I
shall
attempt
to
share
my
screen,
which
somehow
appears
to
be
harder
than
one
expects
right.
Can
you
see
that
yes,
excellent,
so
hello?
This
is
me
speaking
personally,
so
this
is
a
proposed
framework
for
naming
and
addressing
and
forwarding
so
where
marius
rather
elegantly
attacked
the
problem
from
a
sort
of
semantics
perspective,
particularly
pointing
at
john
day's
work
with
with
with
reiner.
A
I
also
really
like
john
day's
work
with
rainer
and
thanks
to
will
ivanovic
for
shouting
about
it
on
the
list
to
say,
go
back
and
read
this
again,
he
was
absolutely
spot
on
I'm
taking
more
of
a
functional
approach
where
I'm
I
am
an
engineer
at
heart,
so
I'm
taking
my
implementation
experience
on
some
dtn
stuff
and
also
trying
to
build
a
sort
of
a
logical,
functional
set
of
blocks
to
tackle
the
scope
of
what
we're
trying
to
do.
So.
Actually,
that's
in
my
introduction
slide.
A
So
part
of
what
I'm
trying
to
do
here
is
to
propose
a
framework
of
common
terms
and
common
understanding
of
basic
functions,
which
we
can
then
start
to
improve.
So
having
attempt
first,
I'm
going
to
attempt
to
propose
such
a
framework
based
on
my
reading
of
bundle,
protocol
version
7,
that's
not
because
it's
a
badly
written
document.
It's
because
I
I
take
several
attempts
to
read
everything.
A
Having
built
that
conceptual
model,
I'm
then
going
to
try
and
address
my
understanding
of
where
I
think
we
should
go
with
addressing
based
on
some
of
the
stairs
in
bundle.
Protocol
version
seven
and
you'll
be
pleased
to
hear
it's
actually
quite
similar
to
what
marius
has
just
presented,
and
I
haven't
worked
with
marius
on
this,
which
I
think
is
a
good
thing
in
terms
of
two
of
us.
What
do
they
call
it?
Emergent
evolution,
convergent
evolution
seems
to
show
that
it's
a
good
idea.
A
So
what
I'm
also
is
a
critical
point
at
the
bottom:
I'm
not
trying
to
standardize
an
implementation
of
a
bundle
processing
agent
here
at
all,
I'm
just
trying
to
build
a
a
a
conceptual
model
that
we
can
use
as
a
as
a
framework
for
discussion.
So
a
couple
of
quick
disclaimers.
This
is
my
personal
view.
I
do
not
have
my
chair
hat
on.
This
is
not
a
steer
from
the
chairs,
and
this
is
gives
you
no
insight
into
whatever
my
employer
might
be
doing
so
standard
corporate
disclaimer.
These
aren't
all
my
ideas.
A
This
is
based
on
several
years
of
discussion
with
many
people
on
this
call
at
the
moment
and
several
others
as
well-
and
this
is
just
my
distillation
of
all
these
all
those
conversations,
so
I'm
definitely
standing
on
the
shoulders
of
giants
here.
Equally,
I
may
not
have
fully
understood
what
an
earth
I'm
proposing.
So,
if
you
spot
something
that
is
just
broken,
please
run
to
the
mic
and
tell
me
I've
gone
wildly
wrong.
Equally,
I
may
be
stating
the
blindingly
obvious.
You
might
all
be
sat
there
going
well,
of
course,
rick
you're.
A
A
The
point
of
this
is
just
is
to
start
a
healthy
discussion
and
to
really
try
and
get
some
traction
and
some
progress
and
some
interest
in
this,
and
my
last
point
is:
I
make
really
ugly
slides,
I'm
really
sorry.
Maurices
were
very
pretty
minor
black
and
white.
So
I'll
start
off
very
quickly
and
of
course
these
slides
can
be
read
at
your
own
pace.
Endpoint
ids.
What
does
bundle
protocol
version?
A
A
A
Second
point:
endpoint
ids
may
have
zero
or
more
receivers,
so
they
can
be
used
for
multicast.
I
don't
know
what
zero
receivers
means.
Does
that
mean
black
hole
or
is
that
some
sort
of
is
there
an
endpoint
id
of
nowhere?
I
don't
know,
but
it's
an
interesting
concept
and
I
have
nothing
against
it
in
principle.
I
refer
to
that
as
the
endpoint's
multiplicity.
A
There's
some
subtleties
there,
I'm
leaning
on
some
of
the
information-centric
networking
concepts
and
not
particularly
well
either
I
apologize
so.
The
other
thing
bundle
protocol
version
7
tells
us
is
there's
these
things
called
node
ids,
which
are
a
specialization
of
an
endpoint
id
that
are
explicitly
unicast.
The
multiplicity
is
one
and
they
name
the
bundle,
processing
agent
application
itself,
so
they're
used
in
places
like
the
origin
of
this
bundle
is
this
bundle.
A
A
A
It's
just
a
comment
and
the
ipn
scheme
concatenates
the
id
of
the
node,
so
the
node
id
and
the
concept
of
a
service
number
I
and
I'm
assuming.
This
is
sort
of
referring
back
to
the
original
concept
of
ports.
Where
you
know
you've
got
ssh
on
port
22.,
so
service
number
22
is
ssh
on
probe
number,
seven
strange
concept,
but
there
you
go.
So
that's
the
idea
of
a
service
number
and
the
node
on
which
that
service
is
running,
but
I
think
the
last.
A
My
final
point
is
by
defining
two
naming
schemes:
bundle.
Protocol
version.
Seven
is
saying
really:
there's
no
requirement
for
there
to
be
a
universal
naming
scheme
or
some
global
hierarchy
that
must
be
used
by
everyone
in
order
to
inter-operate
at
scale.
So
there
isn't
a
central
set
of
dns
root
server
equivalents.
A
There
is
no
one
selling
you
top
level
domains
for
a
large
sum
of
money
or
maintaining
that
be
it
iona's
responsibility,
albeit
whatever
bundle
protocol
version
7,
makes
no
statements
about
that
being
required,
and
I
read
the
presence
of
two
schemers
with
different
pros
and
cons
about
them
as
a
steer
that
perhaps
it
isn't
a
requirement
and
I'm
sure
I'm
gonna.
I
can't
see
the
cube
by
the
way.
So
if
anyone
wants
to
raise
a
comment,
jump
to
the
queue-
and
please
interrupt
me-
I'm
expecting
scott
to
correct
me
on
a
couple
of
these
things.
A
So
the
other
thing
that
the
bundle
protocol
version
7
introduces,
of
course,
is
late
binding.
So
this
is
absolutely
critical
and
scott
can
explain
this
in
far
better
detail
than
me.
But
fundamentally,
the
destination
of
a
bundle
is
not
completely
resolved
at
the
point
of
by
the
sender
at
the
point
of
sending
it
should
be
reevaluated,
step
by
step
along
the
path
towards
the
destination,
using
whatever
kind
of
routing
algorithms
are
in
play.
C
Is
it
in
my
mind,
it's
very
fairly
simple
that
that
a
name
identifies
an
entity
that
is
going
to
be
sending
and
receiving
bundles,
and
an
address
identifies
a
location
in
the
topology
of
the
network
from
which
that
node
can
directly
read
a
bundle
like
it
is
in
as
if
it's
in
memory
right,
it's
like
the
the
location,
the
the
address
is
like
the
mailbox
and
you.
If
you're,
if
you
have
a
mailbox
and
mail
arrives,
you
just
open
the
mailbox
and
there
it
is
so
yeah.
H
C
We're
doing
with
dtn
routing
is
doing
what
he
can
to
get
the
bundle
into
the
mailbox
that
belongs
to
the
node
that
has
identified
a
node
or
set
of
nodes.
Actually,
that
is
identified
by
the
end
point
and
the
the
the
approximate
destinations
that
we
pass
through
as
we
go
through.
The
path
are
what
we
compute
step
by
step
in
doing
the
routing
and
I'll
I'll
stop
there.
A
G
F
A
Can
I
answer
some
of
that
at
the
very
end,
because
I
go
on
to
address
some
of
these
points
at
the
end.
Currently
we
have
one
whether
it's
required
or
not
is
it
is
a
maybe
an
administ
locally
administered
matter,
but
but
don't
let
me
spoil
my
surprise
anyway.
Sorry
stu,
can
I
come
back
to
that
later
on.
A
So
this
is
the
this
is
the
recursive
operation
that
marius
mentioned
in
the
arena
model,
which
takes
a
a
name
of
some
sort
or
a
title
and
resolves
it
to
some
local
address
or
some
address
to
be
used
for
the
next
step
in
processing
and
late
binding
says
this
must
be
done
at
every
step,
where
possible,
so
that
we
don't
resolve
the
complete
connection
graph
from
source
to
the
destination
endpoint
at
the
point
of
transmission.
This
is
the
the
crux
of
dtm
model.
Protocol
version.
A
Your
next
hop
may
be
at
the
layer
you're
operating,
which
I've
sort
of
said
in
the
next
paragraph,
which
implies
that
convergence
layers
have
a
different
concept
of
a
name
or
have
a
concept
of
a
name
within
a
different
scope
than
the
bundle
process
protocol
layer.
Please
see
marius's
previous
presentation.
He
goes
into
great
depth
on
this
and
says
it
much
better
than
me.
A
A
So
I'm
going
to
go.
Please
ignore
the
quality
of
my
graphics.
The
the
process
is
remarkably
simple
and
I
hope
we're
in
general
agreement
on
on
this,
because,
if
we're
not
I'm
happy
to
stop
at
this
point,
because
I
build
on
this
model
step,
one
remove
a
bundle
from
the
ingress
bundle
set.
According
to
some
dequeuing
policy,
I
haven't
said
q
on
purpose
because
there's
a
whole
queuing
strategy,
policing
function
that
goes
on
there,
that
is
out
of
scope
for
this
step.
Two
look
at
the
rules
in
the
forwarding
information
base.
A
A
I
know
that
service
I'll
just
give
it
to
it
forward,
put
it
in
the
output
queue
or
output
set,
because
I'm
ignoring
queuing
ready
to
go
somewhere.
So,
oh,
I
recognize
this
bundle.
I
recognize
the
endpoint
id
in
this
bundle,
and
I
know
that
if
I
give
it
to
that
convergence
layer
adapter,
it
will
go
out
correctly
to
the
right.
A
Endpoint,
wait
put
it
back
in
the
ingress
queue
because
I
know
I
currently
do
not
have
anything
to
do
with.
I
know
I
contact
graph
routing,
for
example.
I
know
I
cannot
get
deliver
that
bundle
now,
but
if
I
put
it
back
in
the
queue
my
q
dequeuing
strategy
may
give
it
back
to
me
in
an
hour's
time.
When
I
know
I
can
commit
it.
So
that's
that's
the
feedback
loop.
That's
the
delay.
Function.
A
A
The
forwarding
information
base
is
simply
a
set
of
rules.
I
am
not
going
to
go
into
detail
of
what
should
be
in
there.
That
is
an
implementation
issue.
We
just
understand
that
there
needs
to
be
one
and
also
the
the
function
which
populates
and
maintains
the
state
of
that
forwarding
information
basis
completely
out
of
scope
at
the
moment
and
will,
for
this
whole
conversation,
and
I
consider
that
to
be
rooting.
A
So,
in
conclusion,
for
the
simple
name
resolution
algorithm,
this
will
work
really
well
for
a
single
consistently
named
dtn
with
well-known
connectivity
that
is
known
up
front.
So
no
routing
protocol
required
no
real
dynamism
and
a
fixed
set
of
convergence
layer
adapters
that
are
also
using
exactly
the
same
endpoint
scheme
and
point
id
scheme
naming
scheme.
So
you
could
build
this
out
of
the
ipm
scheme
and
I
know
people
have
done
exactly
this
and
it
works.
It
works
brilliantly.
You
have
your
contact
graph
of
where
your
ipn
enumerated
nodes
exist.
A
A
If
you
want
to
get
some
sort
of
dynamism,
then
you
need
to
be
able
to
map,
and
this
goes
back
to
maris's
con
presentation.
You
need
to
be
able
to
map
endpoint
ids
that
are
named
within
a
scope
that
makes
sense
to
them.
So
this
is
what
he
was
referring
to
as
the
dtin
that
that
dtn
internetwork
of
names.
A
So
how
do
we
extend
this
very
simple
name
resolution
operation
to
include
that
translation?
Well,
that
can
be
quite
a
simple
rule,
but
the
output
of
that
translation
should
be
some
annotation
to
that
bundle
to
recursively
call
the
function
again
in
order
to
make
progress.
So
I'm
I
am
defining
a
recursive
operation
now
that
annotates,
the
one
of
the
extra
actions
is
to
annotate
the
bundle
and
then
to
operate
on
that
annotation.
A
The
next
time
the
bundle
is
processed,
so
this
solves
our
mapping
problem
and
it
also
allows
us
to
do
something
like
take
the
service
number
off
an
endpoint
id
and
map
that
to
the
pit
of
the
processors
can
handle
or
the
the
socket
file
descriptor
of
your
classic
posix
terms.
So
I'm
going
to
draw
it
again
having
added
the
extra
annotation
which
is
e,
so
the
only
change
to
the
previous
model
is
in
step.
Two.
A
We
examine
the
fib
using
the
as
inputs,
where
you
look
at
the
bundle
blocks
and
also
any
attached
metadata
that
may
exist
from
a
previous
processing
of
this
step.
So
this
gives
us
a
really
nice
simple
function
where
first
time
in
you
get
an
endpoint
id,
the
result
of
your
looking
up
in
the
fib
is
translate
the
name,
send
it
to
that
convergence
layer.
So
you
add
the
annotation,
you
put
it
back
in
the
bundle
set,
it's
picked
up
effectively
as
a
recursion.
A
It
therefore
examines
the
local
metadata
and
says
I
know
what
to
do
with
this
bundle.
I
must
hand
it
to
that
convergence
layer,
adapter,
okay,
you
would
never
write
your
code
to
do
this,
but
it's
a
conceptual
model
we
can
use
for
reasoning
and
we
can
start
to
draw
nice
primary,
color
diagrams
and
point
to
things
and
name
them.
That's
that's
my
underlying
point
here.
A
So
the
point
of
this
basic
annotated
model
is,
we
can
then
start
to
have
a
bit
more
dynamism
in
the
system,
so
this
model
with
local
annotations
is
enough
to
say
well
now
we
can
make
a
selection
between
convergence
layer
adapters
based
on
local
information.
So
this
is
where
neighbor
discovery
could
start
to
populate
information
in
the
fib.
A
So
a
convergence
layer
adapter
could
discover
using
some
neighbor
discovery
mechanism
that
one
of
its
neighbors
happens
to
host
an
endpoint
id
that
information
can
be
pushed
into
the
local
forwarding
information
base.
The
name
resolver
can
then
see
that
and
say
this
time
round.
I
shall
annotate
that
bundle
to
use
the
convergence
air
adapter
that
has
just
advertised
its
reachability
to
that
endpoint.
So
we
get
the
dynamism
in
here
and
we
also
get
that
nice
separation
between
title
and
address.
That
marius
was
pointing
to
next,
so
this
is
the
concept
of
heterogeneous
names.
A
So
I'm
introducing
a
term
here
of
a
naming
domain
and
a
naming
domain
is
the
set
of
all
bundle,
processing,
agents
and
services
that
share
a
consistent
naming
endpoint
scheme
and
assignment.
So
they
are,
for
example,
using
ipn,
and
I
have
an
excel
spread
spreadsheet
somewhere.
That
maps
the
name
of
my
node
in
some
color,
the
serial
number
of
the
manufacturer
to
the
ipn
that
I
have
assigned
to
it,
one
two,
three:
four:
five:
six:
seven,
that
would
be
a
local
administrative
naming
domain.
A
A
I
have
airbus
schema,
dtn,
endpoint,
ids
fred
has
boeing
dtn
endpoint
ids.
How
do
I
send
fred
doesn't
want
me
to
start
administrating
all
his
names-
that's
of
course
not,
and
vice
versa.
So
how
do
I
send
a
bundle
with
a
source
endpoint
id
that
is
at
airbus
to
a
destination
endpoint
id?
That
is
at
boeing,
and
please
don't
read
that
in
as
dns,
because
in
the
ip
world,
of
course,
that
would
go
out
dns
system
ip
and
through
what
we're
talking
about
is
late
bound
movement
of
bundles.
A
So
therefore
there
has
to
be
some
way
to
cross
naming
domains
and
those
obviously
the
way
to
solve
that
would
be
to
have
a
bundle,
processing
agent
that
understands
both
schemes
and
has
a
name
in
both
schemes,
therefore,
can
be
addressed
from
within
the
airbus
name
scheme.
I
know
there
is
airbus
gateway
pointing
towards
boeing,
so
I
send
bundles
to
it
and
it
goes
oh,
I
understand
boeing
endpoint
ids
and
I
also
have
a
name
in
boeing's
naming
domain.
A
So
therefore,
I
can
send
through
to
to
the
the
correct
endpoint
within
boeing's
naming
domain,
but
somehow
I've
got
to
do
that
translation,
so
the
annotation
we
introduced
as
local
metadata
should
probably
be
put
in
as
an
extension
block-
and
this
is
I've-
explained
poorly.
What
marius
explained
much
better,
which
is
an
extension
block
which
records
name
translation
along
with
the
block
as
it
traverses
the
network
from
source
to
destination,
and
I
suggest
that
should
be
implemented
as
a
stack.
A
There
are
arguments
for
it
to
be
a
list,
but
we're
all
familiar
with
the
a
stack
is
a
basic
building
block
of
any
sort
of
recursive
function,
the
ability
to
push
and
pop
name
mappings
effectively
as
you
transit
across
networks,
it
becomes
incredibly
powerful.
It
works
well
in
the
iep
world
with
things
like
mpls
and
lisp,
it's
a
well-known
technique
and
it
has
some
advantages.
A
I'll,
let
you
go
through
this
slide
in
some
more
detail,
because
I'm
conscious
of
time,
so
this
goes
into
a
bit
more
detail
about
push
and
pop
into
stack.
So
what
I'm
doing
now
is
I'm
proposing
that,
instead
of
just
adding
a
label
as
part
of
the
processing,
I'm
adding
an
extension
block
to
the
bundle
that
travels
across
the
network
with
the
bundle
payload,
because
it's
an
extension
block
by
pushing
and
popping
that
allows
a
local
redirection.
A
So
the
example
I
was
using
before
of
an
airbus
dtn
trying
to
talk
to
a
boeing
dtn
a
node
within
the
airbus
dtn,
receives
a
bundle
with
a
boeing
address.
It
has
no
idea
how
to
resolve
that,
because
it's
just
an
internal
node,
but
it
does
know
of
a
gateway.
Who
can
do
that
name:
translation,
because
it's
recorded
in
its
field.
Don't
ask
me
how
it
got
there.
It's
just
known.
A
Therefore,
it
pushes
an
address
name
resolution
extension
block.
It
pushes
an
item
into
there
to
say,
send
this
bundle
to
that
gateway,
because
I
believe
it
can
get
it
moving.
I
believe
it
will
improve
its
chance
of
delivery
because
I
believe
it
understands
how
to
get
things
to
a
boeing
address
so
effectively.
It's
doing
a
redirect.
It's
a
local
binding
that
is
forcing
the
bundle
to
move
in
the
direction
of
someone
who
knows
how
to
get
it
to
the
destination.
A
Even
though
the
bundle
processing
agent
doesn't
it's
a
default
gateway
in
other
terms,
but
you
can
push
and
pop
these
on
instead
of
tunneling,
I'm
I
will
let
you
read
this
in
your
own
spare
time.
This
is
basically
the
previous
diagram
with
push
and
pop
added
key
point
is
at
the
very
bottom
I
believe.
By
using
this
algorithm,
you
can
then
have
a
global
dtm.
A
Perhaps
I
should
say:
interplanetary
interstellar
dtn
made
of
multiple
heterogeneous
naming
domains
with
which
are
interconnected
without
a
central
authority.
So
airbus
can
decide
how
they're
going
to
talk
to
boeing
boeing
can
decide
how
they're
going
to
talk
to
nasa
and
airbus
can
decide
who
they
could,
whoever
they
want
to
go
and
talk
to,
and
nobody
has
to
arrange
with
anyone
else.
A
So
there
can
be
local
arrangements
that
build
transit
networks
and
if
we
get
rooting
right
it
will,
it
will
allow
us
to
do
some
failover
and
redundancy
in
the
path
and
all
sorts
of
exciting
things,
but
they're
so
far
out
of
scope.
But
I
think
there's
a
lot
of
power
in
saying
naming
should
be
a
local
consideration,
but,
however,
we
build
the
network.
We
must
have
facilities
which
allow
us
to
move
bundles
across
these
heterogeneously
named
networks,
and
I
will
stop
there
and
okay.
A
One
last
point:
ed
bahrain
previously
came
up
with
this
and
called
it
ticket
to
ride,
and
I
will
let
him
speak
at
much
more
length
about
this.
Other
quick
point:
I
don't
want
to
use
tunnels
for
this.
I
think
label
switching
is
a
more
elegant
solution
simply
because
I
tunnels
in
place.
You
don't
look
in
them.
A
It
applies
an
opaqueness
and
I
think
label
switching
would
allow
intermediate
nodes
to
look
at
the
path
of
of
the
path
that
the
bundle
has
traveled
and
perhaps
learn
some
better
information
about
available
routes
or
whatever,
because
they're
easier
to
inspect
this
label
popping
is
interesting.
I'm
going
to
have
to
take
the
rest
of
this
to
the
list,
because
we're
running
out
of
time
I'll
take
questions.
Scott
go
for
it.
C
Just
very
briefly,
I
think
the
the
stack
that
you're
talking
about
is
exactly
the
right
way
to
do
this.
I
think
it's
not
an
interoperability
concern.
I
don't
think
there's
any
need
to
move
the
items
on
that
stack
from
one
forwarding
point
to
the
next
through
the
network,
and
so
for
that
reason
I
don't
think
there's
a
need
for
for
a
an
extended
block.
That
does
it,
but
it's
a
this
conversation.
C
What
I
will
say
is
yes,
that
ion
has
been
doing
exactly
this
for
actually
many
years,
but
they're
doing
it
internally
in
the
implementation.
There's
an
internal
stack
of
of
of
of
of
destinations
that
one
can
push
onto
as
one
figures
out.
Oh,
if
I'm
gonna
send
it
to
this
thing,
I
have
to
just
send
it
this
way
and
and
that.
A
I'm
not
proposing
a
solution,
I'm
just
it's
a
terrible
feedback
there.
I
I'm
I'm
not
promoting
a
particular
use
of
a
particular
schema,
I'm
just
trying
to
leave
the
door,
but
sorry,
I'm
just
trying
to
push
back
against
the
idea
that
we
need
a
single
hierarchy
of
names
controlled
by
iona
or
verisign,
or
you
know,
as
as
we
have
in
the
public
internet
at
the
moment.
I
I'm
basically
saying
network
address.
A
G
Yeah,
I
love
the
idea
of
not
trying
to
build
the
one
ring
to
rule
them
all,
but
I
just
I
I
just
want
to
make
sure
that
we
are
still
going
to
have
a
registry
of
schemes
so
that
when
I
see
a
name,
I
know
what
the
heck
to
do
with
it,
and
I
won't
have
two.
You
know
competing
naming
schemes
that
look
just
alike
and
are
indistinguishable
but
need
to
be
handled
differently.
That's.
A
C
B
Briefly,
agree
as
well
that
that
that
this
kind
of
approach
is
is
useful
but
need
to
put
a
plug
in
for
security.
If,
if
we
are
going
to
be
carrying
and
pushing
a
lot
of
that
information,
we
also
need
to
be
making
sure
that
we
are
not
exposing
the
internals
of
one
network
to
another
network,
because
that
is
something
that's
not
going
to
survive
into
operational
deployment.
A
B
A
I
don't
have
the
answer.
This
is
I'm.
I
suppose
my
goal
for
this
is.
It
was,
was
twofold
to
produce
a
framework
on
which
we
could
agree
to
discuss
to
to
to
effectively
the
whiteboard
diagram.
We
can
all
stand
around
and
point
at
as
well
as
say
here
are
some
ideas
that
I
think
are
reasonably
coherent
and
seem
to
be
correct.
With
bpp7.
A
A
A
Thank
you
all,
particularly
those
of
you
in
bizarre
time
zones
for
for
making
it,
and
thank
you
all
for
turning
up.
It's
a
really
good
turnout
for
an
interim,
so
yeah
really
appreciate
it.
We
will
get
the
minutes
published
once
we
have
worked
out
how
to
get
them
out
of
markdown
and
onto
the
data
tracker
tool,
because
it
always
complains
that
it
doesn't
like
mark
down.
Despite
the
fact
it
says
it
does
go
on
ronnie.