►
From YouTube: IETF115-DTN-20221110-1300
Description
DTN meeting session at IETF115
2022/11/10 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
Well,
I
see
one
o'clock
on
my
on
my
screen,
so
I
think
we
should
probably
make
a
start
first
off
a
quick
audio
check.
Can
you
hear
me
successfully
I'm
going
to
take
my
mask
off
because
I'm
speaking
and
just
for
clarity
for
remote
participants,
I
hope
you
don't
mind
it.
A
Hello,
welcome
to
ietf,
115
dtn
working
group
meeting.
So
just
for
clarity.
This
session
is
being
recorded.
We're
doing
this
through
me,
Techo.
It
will
obviously
excitingly
all
be
on
YouTube
afterwards.
So
you
can
show
what
you
did
at
ietf
to
your
friends
and
colleagues
when
you
get
back
home
next
slide,
please!
A
A
Oh
okay,
good.
If
you
have
not,
you
need
to
read
the
note
well,
this
covers
IPR.
This
covers
your
participation
at
the
microphone
in
the
chat
and
within
the
meeting
in
general.
It
also
covers
your
basic
Behavior.
Heated
discussion
is
fantastic
abuse
and
bullying
is
not.
There
is
a
relevant
codes
of
conduct,
relevant
information
on
copyrights,
patents
participations
and
the
general
standards
process
all
documented
in
these
very
nicely
written
BCPS.
Please
follow
the
links
if
you
have
any
questions.
As
with
most
things,
you
have
been
told
about
these
things.
A
You
can
now
no
longer
claim
you
are
unaware
of
them,
but
we're
all
grown
ups,
and
we
will
assume
that
we're
going
to
behave
them
responsibly
anyway.
Next
slide,
please
so
tips,
because
we
have
a
still
have
a
large
number
of
remote
participants.
Thanks
to
the
tail
end
of
covid.
Please
make
sure
you
sign
in
to
meet
Echo
remotely,
obviously,
but
also
in
the
room.
So
we
can
operate
a
single
queue.
There's
a
really
nice
raised
hands
button.
You
can
click
to
join
the
queue.
A
So
please
use
that,
rather
than
just
standing
at
the
queue
remote
participants
try
to
avoid
some
feedback
by
keeping
your
audio
and
video
off
unless
you
are
actually
presenting
or
sharing.
If
you're
asking
a
question,
obviously
you
will
need
audio.
Video
is
optional,
strongly
recommend
a
headset
to
avoid
the
usual
audio
feedback
problems,
hopefully
after
two
and
a
bit
years
of
covert
we're
all
pretty
good
at
remote
meetings
over
video
conference.
But
problems
happen
next
slide,
please.
A
So
the
agenda
is
at
that
URL.
We
will
also
put
it
on
the
screen
in
a
second
the
meet
Echo
information
for
those,
obviously
who
are
not
remote
and
can't
see
this,
but
that
information
is
there
for
your
reference.
If
you
get
stuck
with
anything
during
the
meeting,
there's
a
URL
there
for
a
an
FAQ
which
should
hopefully
help
you
dig
out
of
that
hole.
Next
slide,
please
so
the
agenda.
We
are
doing
the
first
five
minutes
from
the
chairs.
A
Well,
currently
from
me,
then
we
have
a
35-minute
discussion
on
the
ipn
naming
scheme.
Update
from
myself,
then
Brian
C
plus
is
going
to
present
bpv7
administrative
records.
We're
going
to
do
the
Cozy
BP
SEC
security
context
records
again
with
Brian
we've,
given
him
20
minutes
to
do
both,
but
there's
two
topics
in
there
then
Sarah
heiner
is
finally
going
to
get
a
chance
because
she
got
bumped
from
the
114
agenda.
A
To
talk
about
the
dtn
management,
dtnma
architecture,
I
think
that's
double
architecture,
if
I
think
about
it,
which
is
all
about
managing
systems
across
delayed
and
disrupted
networks,
a
interesting
piece
and
then
Scott
Johnson
wants
to
give
a
demonstration,
which
is
always
fun,
and
we
have
real
confidence.
It's
all
going
to
work
remotely
from
from
wherever
he
is
in
the
US
about
IPv6
support
for
dtn,
so
I'm
actually
really
looking
forward
to
that
would
be
great.
A
As
usual,
we
will
have
a
little
bit
of
Open
Mic
at
the
end
for
any
other
business.
We
will
absorb
that.
If
any
of
these
discussions
get
heated,
I
would
much
rather
discuss
things
as
they
happen
within
reason,
rather
than
waiting
to
the
very
end
and
then
to
dominate
the
end
of
Scott's
demo
with
talking
about
ipn,
for
example,
so
we
may
absorb
that
15
minutes
we
may
have
to
be
quite
tight
on
time
if
discussions
run
on
next
slide.
A
Okay,
there
is
the
shared
markdown
based
notepad
in
Meet
Echo.
Although
we
have
a
secretary
here
Adam
who
furiously
takes
notes,
please
help
out.
Please
it's
a
collaborative
thing,
particularly
if
your
name
is
spelled
wrong
or
I
mean
Adam
types
fast,
but
occasionally
keystrokes
are
missed
or
if
you
don't
think
he
captured
your
point
correctly.
Please
add
to
it
it's
fine
equally
to
help
Adam.
If
you're
in
person,
can
you
state
your
name
at
the
mic
nice
and
clearly,
so
he
can
capture
that
as
well
as
usual.
This
is
an
ITF
working
group.
A
We
have
a
mailing
list
dtnitf.org.
Also,
if
you
need
to
contact
the
chairs
about
anything
administrative
subject
matter
stuff
should
really
go
to
the
normal
dtn
mailing
list.
It's
for
the
working
group,
but
if
you
have
an
admin
issue
or
want
to
suggest
something:
administrative,
there's,
The
dtn,
Hyphen
chairs,
mailing
list
which
will
go
to
Ed
and
myself,
and
also
our
ad
zahid,
who
I
believe
I
just
saw,
come
in
and
sat
at
the
back
of
the
room.
A
B
A
If
you
can
fit
them
into
the
two
10-minute
sections,
you've
got
I
I
have
no
problem.
Okay,
thank
you
yeah.
Can
you
submit
the
slides
to
be
updated
and
we'll
get
them
into
the
into
the
agenda
pack
quickly?
That's
fine!
Sorry!.
C
Thank
you
looks
like
sometimes
in
this
room,
the
wireless
you
know
kind
of
Disconnect,
at
least
on
my
side.
I,
don't
know
if
it's
an
agenda
at
them,
but
I
just
reposted,
a
draft
that
I
wrote
a
few
years
ago
about
service
registry
and
kind
of
a
application
framework.
C
D
Yeah
share
the
mic:
oh
that's,
it
is
Wireless.
So
no
completely
agree,
don't
have
anything
to
add
to
Rick's
excellent
introduction,
and
why
don't
we
start
with
our
first
presentation,
which
is
Rick.
A
Okay,
so
for
clarity,
I
am
most
definitely
taking
my
chair
hat
off
during
this
presentation,
because
this
is
my
draft
primarily
I'm,
the
primary
author
on
this,
and
so
I
will
be
representing
myself
and
not
acting
as
a
chair
of
dtn,
so
I
want
to
make
that
abundantly
clear
and
I
may
stand
here
for
the
whole
of
this
q.
A
as
well
to
indicate
I
am
not
sharing
this.
A
So,
as
many
of
you
are
probably
aware,
I
hope,
I
have
published
three
revisions
of
an
ipn
URI
schema
update
draft
that
recently,
after
the
last
call
not
last
call
the
working
group.
Adoption
call
was
successful
after
the
interim
we
held
between
114
and
115
is
now
being
republished
as
a
working
group
document.
So,
although
I
am
the
primary
author
on
this,
this
is
now
a
working
group
document
and
is
up
for
discussion
and
consensus
within
the
working
group.
A
A
A
There
is
explicit
encoding
instructions
for
how
to
take
this
general
purpose,
text-based
URI
and
turn
it
into
the
relevant
encoding
for
both
bundle.
Protocol
version,
6
and
bundle
protocol
version
7..
So,
although
we
are
talking
about
Uris,
there
are
specific
encodings
for
the
two
bundle
protocol
versions
that
are
in
active
use
at
the
moment,
but
I
will
just
refer
to
them
as
Uris.
The
discussion
May
touch
on
encoding,
but
the
format
is
the
key
point
so
as
defined
in
6260
and
91
and
71,
and
there
is
some
weakness
about
that
total
definition.
A
Now
the
uniqueness
constraint
is
really
important,
so
in
both
ppv6,
but
definitely
in
bpv7,
an
endpoint
identifier,
which
is
the
URI,
must
be
unique
for
interoperability.
If
you
have
a
set
of
connected
dtn
nodes,
making
a
single
dtn
Network,
you
cannot
have
duplicate,
endpoint,
IDs,
I.E,
sorry,
unicast,
endpoint
IDs,
you
can
have
multicast
ones.
Ipn
does
not
support
multicast.
So
in
the
ipn,
it's
all
about
unicast.
So
therefore
they
must
be
unique.
Otherwise
you
can't
deliver
the
same.
A
You
can't
address
the
same
bundles
as
to
two
things
with
the
same
name,
so
the
combination
of
node
number
and
service
number
must
be
unique
according
to
RFC
9171,
but
in
the
descriptions
in
6260
and
9171.
Node
number
is
also
implied
to
be
unique
following
the
general
pattern
of
IP
address
and
port
number.
So
there
is.
This
is
analogous,
but
not
identical.
A
So
I
I
have
in
going
through
and
trying
to
really
understand.
What's
going
on
with
ipn
I
have
read
quite
a
lot
of
stuff
and
I
have
some
perceived
problems
which
I
have
attempted
to
address
in
this
draft,
and
they
are
primarily,
there
is
only
one
Ayana
registry
for
node
numbers.
At
the
moment
it's
called
the
cbhe
registry,
which
stands
for
compressed
bundle,
headering
coding,
which
is
a
way
you
do
the
wire
format
for
bundle
protocol
version
six.
It
predates
bundle,
protocol
version
7
and
makes
no
reference
to
bundle,
protocol
version,
7.
and
compressed
bundle.
A
Header
encoding
isn't
used
for
bundle,
protocol
version
7.,
so
perhaps
cbhg
isn't
the
right
name
for
the
registry
and
renaming
it
is
requires
a
document
because
it's
good
best
practice
and
it's
what
Iona
requires
of
us,
not
a
great
issue.
Second
point:
there
are
some
minor
inconsistencies
between
6260
7116,
which
actually
is
the
draft
which
introduces
and
Mark
Blanche
is
one
of
the
authors
of
that
draft,
which
introduces
these
Ayana
Registries
and
makes
the
requests
and
backs
them
up.
But
it
doesn't
change
the
spec
much
more
from
60
to
60.
A
E
A
But
because
it's
described
in
three
different
documents,
there
are
some
inconsistencies.
There
is
some
implementation
knowledge
that
has
emerged.
There
are
way
people
have
interpreted
these
things
into
interoper
into
implemented
networks
where
they
slightly
deviating
behaviors.
For
example,
the
node
number
uniqueness
isn't
absolutely
explicit.
It's
just
kind
of
assumed,
and
really
we
should
have
nice
clean,
clear
specs
for
this
and,
from
my
perspective,
I,
don't
actually
care
what
that
spec
says
as
long.
A
A
So
the
third
perceived
problem
is
the
single
flat
numbering
space
for
all
log
numbers.
So
this
goes
back
to
the
bungle
protocol
version.
Six
days
where
there
were
node
numbers,
it
was
an
unsigned
two
to
the
64-bit
integer
space,
great
lots
of
room
in
there
due
to
the
way
that
the
wire
representation
in
bundle
protocol
version
six.
That
could
be
encoded
reasonably
effectively,
but
there
was
still
a
penalty
for
the
bigger
the
number.
The
more
bits
need
to
be
encoded
on
the
wire
and
with
seaboar.
That
is
definitely
the
case.
A
A
And
if
you
know
if
this
gets
allocated
aggressively,
you
could
end
up
forced
to
have
a
minimum
10
octet
encoding,
where,
if
you
could
just
use
a
low
number,
you
could
get
away
with
five
and
we're
talking
about
deep
space
and
constrained
devices
and
having
an
IR
and
a
registry
force
you
to
add
five
octets
to
your
Source,
your
destination
and
your
report
to
fields
in
your
bundle.
Protocol
header,
just
to
talk
to
between
two
devices
within
your
own
network
seems
unfair.
A
If
I'm,
honest
and
undesirable
and
equally
the
other
problem
is
in
that
original
cbhe
node
number
registration,
there
wasn't
actually
anywhere
for
saying:
do
you
know
what
these
really
convenient
short
numbers
like
one,
two,
three,
four
and
five?
You
know
you
build
one
of
these
things
in
your
lab
and
you
start
numbering
your
nodes,
one
two,
three
four
and
five,
because
you
know
they're
they're
easy
those
aren't
reserved
for
that
use.
They
are
actually
reserved
to
be
handed
out
to
someone.
A
A
So
the
first
one
is
to
clarify
the
usage
of
the
ipn
scheme,
URI
node
numbers
and
service
numbers
with
bundle,
protocol
version
7..
So
that's
collate.
All
the
information
we've
got
between
6260,
7116
and
9171.
Draw
it
all
together
and
say:
do
you
know
what
the
rational
superset
of
all
of
these
rules
or
the
rational
intersection
of
all
these
rules
is
not
as
reserved
for
the
administrative
endpoint
blah
blah
blah?
A
You
know,
there's
a
it's
a
pretty
short
summary
of
this
stuff
and
it
tries
to
tackle
the
uniqueness
constraint
and
I
will
go
into
these
in
a
bit
more
detail
in
a
second.
The
second
thing
is
to
say:
the
CVH
node
number
registry
is
a
misleading
name,
and
frankly,
it's
quite
difficult
to
look
up,
and
it's
not
very
clear
to
see
what
it
is
anymore.
So
let
us
rename
and
clone
that
repository
into
the
registry
into
two
Registries
one.
A
Note
numbers
and
bpv
seven
service
numbers
and
we'll
tidy
up
the
allocations
a
little
bit
to
put
in
a
bit
of
private
space
to
make
sure
that
we
understand
it
and
it's
and
it's
there
for
people
to
use,
including,
and
that's
the
third
Point,
reserving
load
number
low
numbers
in
that
range
for
private
use.
So
the
efficiently
encoded
obviously
used,
and
we
know
people
just
use
I've
built
a
dtn
network
where
I
called
my
nodes,
one
two
three
four
and
five,
because
why
not
that
now
becomes
official
unlicensed
Spectrum?
That's
fine!
A
I
can
do
that
and
I
understand
its
own
license.
Spectrum,
which
means
I
will
Clash.
If
I
am
not
careful,
so
don't
go
fly
this
where
I
expect
it
to
be
interoperable
with
other
people.
It's
just
putting
that
clarification
in
there
and
the
fourth
point
is
to
introduce
a
new
numbering
Authority,
let's
introduce
new
numbering
Authority
prefixes,
to
allow
flexibility
of
allocation
with
efficient
encoding.
So
this
is
to
address
the
problem
with
a
single
flat
number
range
to
say:
let's
divide
it
up
and
make
it
a
bit
more
hierarchical
and
I,
always
mispronounce.
A
That
word
such
that
we
can
allow
organizations
to
hand
out
numbers
in
a
controlled
way
that
are
efficiently
encodable
and
don't
need
to
constantly
batter
Ayana
for
registrations
or
allocate
great
chunks
out
of
a
single
number
range
and
still
maintain
interoperability
with
probably
more
efficient,
encoding,
I
say,
probably
because
you
can
still
do
dumb
things
and
end
up
with
inefficient
encoding.
But
it's
your
that
is
now
delegated
from
the
ietf
to
Regional
numbering
authorities,
who
can
make
their
own
decisions
about
whether
they
want
to
be
smart
or
dumb.
Look.
A
C
C
Then
you
know
there's
trade-offs
here,
because
you
know
private
use
is
typically
you
know
in
your
lab
or
whatever.
Therefore,
packet
size,
you
don't
matter
right
bundle,
size
or
you
know
whatever
in
space
or
you
know,
constraint,
networks.
Those,
as
you
said
those
you
know,
numbers
are
more
important
because
they're
smaller,
therefore
those
number
are
more
precious
to
be
used
in
production
constraint
networks
than
in
the
lab.
Therefore,
I'm,
essentially
at
the
opposite
of
the
spectrum
of
you
in
the
private
one
should
be.
You
know,
don't.
A
Care
I
completely
agree
with
that
sentiment
and
without
the
introduction
of
numbering
authorities
to
solve
the
encoding
problem
with
a
different
approach.
I
completely
agree,
I
I
will
add.
Ignoring
we
have
numbering
authorities
having
numbers
1
to
24
is
the
best
thing
to
have
because
we're
using
seaboor
and
that's
one
octet.
So
if
and
I'm
gonna
I'm
not
intending
to
make
it
a
political
Point
here,
but
if
Rose
Cosmos
and
NASA
both
apply
to
Ayana
for
numbers
1
to
24,
how
do
we
decide
that
I?
A
Comes
kind
of
a
can:
we
come
back
to
this
at
the
end
after
I've
brought
in
numbering
authorities,
because
I
think
it
sidesteps
it.
A
A
A
The
value
for
the
node
number
component
must
the
value
0
must
not
be
used,
except
as
part
of
the
the
magic
ipn,
not
DOT,
naught
So
within
bundle
protocol
version.
Seven.
There
is
this
concept
of
the
null
endpoint
identifier,
it's
nowhere,
dtn,
none
and
in
ipn.
That
is
the
magic
value,
not
DOT
naught,
so
you
can't
use
naught
for
anything
else.
It
just
makes
no
sense
it.
It
would
danger,
in
my
opinion,
so
you
can't
have
an
ipn
of
notebook.
2.
A
A
It's
greater
than
or
equal
to
two
to
the
64
for
the
node
number
must
not
be
used
because
you
can't
do
it
in
a
seaboard
type:
zero,
unsigned,
integer
encoding
that
will
change
the
wire
encoding
of
your
Seaboard
to
use
big
numbers.
We
don't
want
to
go
in
there.
The
current
encoding,
as
described
in
9171,
which
introduces
the
Seaboard
encoding
says
this
will
be
an
unsigned
integer.
They
have
a
natural
limit
of
2
to
the
64..
A
A
Processing
node
must
share
the
same
value
for
node
number
component
and
this
is
contentious
because
either
you
read
this
idea
of
note
number
dot
service
number
as
analogous
to
IP,
address
colon
port
number
and
think
well,
obviously,
I've
got
an
address
for
my
node
and
I
discriminate
on
the
service
on
my
node
and
therefore
my
nodes
have
to
be
unique.
Counter
argument
is
no
no,
no,
no
bundle.
Protocol
version
7
makes
it
absolutely
clear
that
the
URI
in
totality
is
the
unique
element.
A
That's
what
has
to
be
unique
or
you
can
have
a
service
called
ipn.
2.1
AIDS
can
have
a
service
called
ipn
2.2.
They
are
both
unique
and
it
doesn't
matter
that
the
node
number's,
two
personally
I,
don't
mind.
I.
Think
an
argument
can
be
made
for
both
yeah.
If
you
allowed
no
numbers
to
not
be
actually
the
number
of
a
node
and
we'll
just
call
them
last
part
or
second
last
part
and
stop
that
implied
inference
that
it's
something
to
do
with
the
number
of
the
node
and
then
for
the
uniqueness
constraints.
A
E
Yeah
clarifying
question:
if
I
think
what
you
just
described
doesn't
match
at
all.
How
I
read
bullet
point
three
here.
A
E
A
E
Well
so
saying
that
and
two
dot
star
has
to
be
on
a
single
node
is
different
from
everything
on
a
single
node
can
have
only
one
node
number.
E
A
E
A
A
Let's
say
you
can
only
have
one
node
number,
it's
your
node
number
and
therefore
it's
got
to
be
unique
for
your
node,
because
then
I
can
do
something
like
C
and
endpoint
of
2.7
and
I
know
where
2.1
is
so
I
can
send
it
to
2.1,
because
I
believe
it's
the
right
node,
even
if
it's
the
wrong
service,
so
you're
in
adding
routing
and
okay,
that's
still
technically
a
different
thing:
okay!
Yes,
it
is.
A
D
So,
just
sorry,
just
to
jump
in
from
from
a
Time
perspective,
I
I
think
we'll
have
this
conversation
reopened
again
in
a
few
slides.
So
can
we
pause
to
that?
We
did
have
one
question
from
the
chat
which
asked
there
is
a
must
in
this
third
bullet.
Do
we
foresee
an
enforcement
mechanism
for
any
of
these
uniqueness
constraints
so.
A
The
only
enforcement
mechanism-
I
think
we
can
say
is
here-
is
an
RFC
with
RFC
8176
language
in
it,
and
if
you
write
a
specification
to
say
your
satellite
system
will
comply
to
this
RFC,
then
it's
abundantly
clear.
Are
we
having
dtn
police
force,
who
go
out
and
check
your
implementation?
Of
course
we're
not.
A
If
people
want
to
do
interrupt
trials,
I
think
the
best
we
can
do
is
say
we
will
have
a
clear
specification
with
clear,
ietf
language
about
the
correct
Behavior
such
that
people
can
go
away
and
write
their
testing
regimes
and
their
QA
and
all
that
kind
of
stuff
I,
don't
think
we're
gonna.
We
don't
do
enforcement.
We
do
specification.
Okay,
okay,
thank
you.
Thank
you!
A
So,
for
service
numbers
there
was
some
confusion:
RC
6260
and
RFC
71
7116
both
said
the
service
number
for
the
administrative
endpoint
or
what
it
was
called
in
bpv6
days.
It
was
called
something
else,
but
it
was
fundamentally.
The
same
thing
must
be
zero.
In
bpv7
it
got
turned
into
a
May
I'm
suggesting
it
should
just
go
back
to
a
must.
I
don't
see
if
we
have
a
well-known
service
called
the
administrative
endpoint.
A
A
So
the
rename
really
simple
this
one
cbh
e
node
numbers
becomes
bpv6
node
numbers,
cbhc
service
numbers
becomes
bpv6,
URI
service
numbers,
no
alteration
to
policy
assignment,
nothing
cut
paste,
rename
in
fact,
I
think
it's
just
rename
next
slide,
clone
them
create
new
Registries
for
V7
tweak
them
slightly
call
them
the
bundle.
Protocol
version,
7
ipn
scheme
URI
null
Authority,
node
numbers
registry
and
I
will
come
back
to
what
null
Authority
means.
A
All
values
and
policies
are
copied
from
the
cbhg
node
numbers
registry,
except
I've,
made
the
low
numbers
private
use.
I
am
very
happy
to
have
that
discussion.
I
have
kept
the
very
top
numbers
as
experimental,
again,
probably
part
of
the
same
conversation.
Let's
have
it
on
the
list.
I
don't
mind.
There
are
pros
and
cons.
That's
fine!
A
There
was
a
weird
block
between
two
to
the
21
and
2
to
the
28,
which
was
reserved
for
private
and
experimental.
That's
all
part
of
that
same
conversation.
Let's
just
work
out
what
these
things
should
be.
Let's
make
sure
the
reservations
are
there.
This
is
our
opportunity
to
do
about
housekeeping
if
required,
okay.
But
the
key
point
is
by
putting
private
use
rather
than
private
or
experimental
we
are
saying
here
is
a
chunk
of
unlicensed
Spectrum,
which
you
clearly
understand.
A
If
it's
for
your
own
stuff
go
ahead
and
use
it,
if
you
use
it
in
the
wild,
you
probably
will
clash
with
other
people
if
they're
using
it
in
the
wild
you
do.
This
is
not
your
spectrum
to
use.
You
are
sharing
it,
so
we
could
develop
protocols
which
handle
this
and
live
in
this
kind
of
unlicensed
Spectrum
I,
don't
know
someone
else
can
do
that
work.
A
D
We
do
have
two
people
in
the
queue
starting
with
Alberto.
I
Thanks,
can
you
hear
me
well.
C
I
Thanks
Rick
forward
explanation
here,
a
couple
of
couple
of
comments
on
this
one,
the
first
one
is
a
question:
why
creating
a
second
registry?
Why
can
we
extend
the
existing
registry
to
say
it
is
a
bpe
CX,
plus
the
null
a
null
identifier,
a
normal
Authority
for
bpv7.
A
Purely
because
I
wanted
to
separate
and
reorganize
the
current
assignments
to
clarify
the
difference
between
private
use
and
experimental.
However,
that
I
think
that
is
a
very
valid
point
to
have
a
discussion
about
what
we
do
and
if
the
answer
is
there
is
no
change,
then
we
don't
make
the
change
that
that's
that's
fine.
I
Okay.
Okay.
Thank
you.
The
second
comment
is
about
the
the
use
of
the
term
unlicensed
Spectrum.
This
has
huge
implications
when
it
comes
to
you
know
you
build
Technologies
for
coexist.
I
In
this
case,
you
know,
I
tend
to
agree
with
Mark
that
you
know,
selecting
the
the
golden
identif
numbers
for
private
use
would
automatically
potentially
create
issues
that
you
know
women
don't
want
to
have
at
the
end
of
the
day.
I
A
Two
reasons
one
having
some
private
use
and
I
used
analyzen
spectrum
in
quotes
just
because
I
know
people
a
lot
of
people
come
from
an
RF
background,
but
it's
not
a
it's.
This
is
about
private
use,
allocation
of
numbers,
that's
the
correct
phrase
for
it.
I
went
for
low
numbers
because
I
happen
to
know.
Someone
is
currently
deployed
a
dtn
node
that
they
hope
will
be
interoperable
with
other
dtn
networks
that
they
hope
will
be
interoperable
with
other
people
and
they've
numbered
one
two,
three
four
five
and
they
didn't
ask
for
that.
A
So,
but
again
as
long
as
we
have
some
private
use,
space
and
people
understand
it's
the
free-for-all
space
and
whether
we
combine
that
with
the
experimental
or
split
it
and
there's
a
bit
of
nuance
in
the
way
Ayanna
does
its
allocations.
That
needs
to
just
be
checked,
and
it's
a
slightly
ietfe
about
it.
Then
it
doesn't
really
matter
where
it
is.
I
just
felt
that
moving
load
was
useful.
A
J
J
Just
a
really
small
question,
I
think
for
this
slide
and
the
other
one
that
mentioned
uniqueness
in
the
ipn
scheme
and
if
I
want
to
essentially
create
an
anycast
style
environment.
Where
do
I
go
in.
A
D
K
Yeah,
can
you
hear
me?
Okay,
yes,
okay.
K
My
remark
at
this
point
is
just
that
if
you
do
have
authorities,
it
seems
to
me
that
the
reserving
load
numbers
for
private
use
is
moved
because
the
authority
ought
to
be
able
to
use
the
low
numbers
itself
right
and
there's
no,
it's
responsible
itself
for
ensuring
there's
no
Clash
on
those
numbers.
Isn't
that
right.
A
I
agree
with
you
Scott
yeah,
which
is
my
answer
to
Mark
originally
about
having
them
as
low
numbers.
It
didn't
really
matter
because
it
kind
of
once
you've
got
authorities
in
place.
It
kind
of
negates
and
moves
around
that
a
little
bit.
Can
we
take
that
one
to
the
list
because
I
think
it's
an
interesting
topic
and
yes,
the
that's
another
aspect
is
if
we've
got
Authority
numbers,
do
we
really
care
about
this,
and
perhaps
we
should
just
leave
it
as
it
is?
It
is
exactly
yeah
yeah.
K
A
D
Anyone
else,
okay
next,
is
Mark
and
then,
in
the
interest
of
time,
I
will
lock
the
queue.
C
Yeah
I
was
going
to
say
you
know
it's
fine
if,
if
you
wanna
have
questions
at
the
end,
but
two
comments,
one
is
same
as
a
previous
speaker
and
that's
got
the
Alberto
I.
Think
I,
don't
see
the
reason
for
having
two
registries.
It.
C
A
C
The
other
point
is
I
would
like
to
be
to
learn
what
you
mean:
the
difference
between
private
use
and
experimental,
because
you
define
it
differently.
I
haven't
seen
you
know
usually
I
in
a
you
know:
Registries
private
user
experimental
is
the
same
range,
which
is
I,
don't
care
and
those
numbers
should
not
happen
in
production.
You
know
networks,
but.
A
I
was
entirely
with
you
on
this
and
then
I
went
and
read
the
very
detailed
RFC
about
how
to
write
a
registry
properly,
because
I
thought,
if
I'm
going
to
do
this
I
just
and
it
draws
them
out
and
explains
them
differently
and
claims
them
to
be
different
things.
However,
if
we
want
to
conflate
them
together
and
say
for
us,
it
doesn't
make
any
difference,
I'm
happy
to
do
that
as.
E
L
Stew,
card
critical,
Technologies,
so
two
points
the
first
one
I
think
this
might
be
a
restatement
of
something
that
somebody
else
said,
but
I
want
to
use
different
words
to
make
sure
I'm
clearing
it.
That
saying
uniqueness
means
that
every
node
number
must
point
to
one,
and
only
one
node
is
different
from
uniqueness,
meaning
that
every
node
has
one
and
only
one
node
number
so
I
hope
we
can
tease
that
out
in
the
text.
Secondly,
what's
a
node,
oh
this
craft,
a
computer,
a
core
on
a
computer,
a
virtual
machine.
G
There
is
a
point,
maybe
earlier
about
for
private
use.
Why
do
we
need
an
authority
authority
for
private
nodes
and
to
that
also
say
that
I
don't
know
if
it's
a
case
in
your
environment
but
stealth
mode
development,
where
somebody's
developing,
something
that
they
don't
want
to
share
or
something
else
having
the
ability
to
get
numbers
to
work
with
without
exposing
what
they're
doing
is
critical
for
those
sorts
of
operations,
so
so
push
back
on
any
arguments
against
it
because
again,
I
don't
know.
A
A
I
think
that's
absolutely
something
that
must
be
supported
when,
however,
the
final
text
comes
out.
Thank
you.
Next
slide,
I've
got
eight
seconds,
so
the
service
number's
registry,
just
like
I,
did
with
the
v61
I
cloned
it,
because
I
felt
that
it
might
be
worth
jiggling
it
about
to
make
the
boundaries
work
with
C
boring
coding.
Otherwise,
it's
pretty
much.
The
same
I
couldn't
find
any
current
specifications
for
active,
well-known
bpv7
services
that
needed
immediate
assignment.
A
They
could
be
wrong
if
you
work
for
an
agency
and
I'm
kind
of
addressing
ccsds
here
who
have
things
that
they
consider
well-known
services
that
are
something
that
should
be
globally
interoperable
and
registered
with
the
ietf,
rather
than
just
used
within
their
own
sort
of
work.
Speak
up.
Let's
get
these
ready
to
go
into
the
service
registry.
To
avoid
clashes.
Mark
blanche's
draft
on
service
members
there
again,
Mark
I
did
mention
it.
I
think
is
really
good.
It
was
a
really
timely
up
uplift
of
that
draft
and
republication
of
that
draft.
A
It
introduces
the
Ping
service
or
the
echo
Service
needs
a
well-known
service
number
just
for
General
op
stuff.
So
you
can
ping
a
node
see
if
it
is
actually
there
in
a
delay,
tolerant
manner,
it's
going
to
need
a
well-known
number.
It
doesn't
have
one
at
the
moment.
This
is
an
opportunity
to
tidy
up
again
private
use,
experimental
use,
interesting
debate.
Let's
take
it
to
the
list
that
kind
of
stuff
next
slide,
because
I
just
want
to
get
to
the
contentious
stuff.
Any
questions
so
far.
A
A
That's
the
current
state
of
play
next
slide.
Please
The
Proposal!
Let's
put
a
prefix
in
front
of
this.
So
let's
divide
the
space
from
a
flat
space
into
a
tree.
So
optionally,
you
can
put
an
extra
number
dot
in
front
of
your
node
number
to
say
this
node
number
was
assigned
by
this
numbering
Authority.
A
Why
not
to
stop
but
to
ask
serious
questions
about?
Why
is
Rick
registering
all
of
two
but
fundamentally
you're,
saying
I
can
encode
my
numbering
Authority
efficiently.
I
can
then,
as
a
numbering,
Authority
hand
out
all
those
precious
short
good
encodings.
You
know
the
one
octet
two
octet
encodings,
according
to
my
policies,
without
clashing
with
anyone
else
from
a
number
other
numbering
Authority
or
from
that
registry
of
the
null
Authority
I.E.
The
register
used
when
you
don't
have
a
numbering.
Authority
I
can
therefore
get
Global
uniqueness
when
I
need
it.
A
The
numbering,
the
naming
authorities
or
numbering
authorities
and
I
need
to
be
clear
about
getting
I've
called
it.
Two
different
things
stupidly,
I've
been
calling
them
numbering
authorities
in
the
draft
numbering
authorities
have
a
global
registry
in
Ayana,
so
you
that
maintains
the
interoperability
but
other
than
that
they
can
hand
out
their
own
numbers
and
I
have
added
a
registration
for
them
and
next
slide.
Please,
okay,
reason
for
it.
A
One
of
the
arguments
is
people
have
been
saying:
oh,
how
do
I
detect
these
things?
Oh
hold
on
you're,
changing
the
wiring
coding
for
these
things.
This
should
be
a
whole
new
URI
schema.
A
No
first
off,
you
can
detect
this
in
your
stream
parser
or
your
buffered
parser
one
octet
later
than
you
currently
detect
it.
So
in
the
wire
protocol,
when
you
receive
a
c-bar
encoded
URI,
the
first
octet
indicates
the
type
of
the
URI
type
number
two
is
ipn
following.
That
is
the
length
of
the
array
which
contains
the
integers
of
node
number
and
service
number.
Currently,
it
should
always
be
2,
because
that's
all
that's
defined
with
this
change
that
number,
maybe
three
or
four-
and
that
tells
you
how
many
more
you
need
to
read.
A
So
you
can
detect
these
just
as
simply,
but
one
architect
later,
I.
Consider
that
a
easy
first
compatibility,
they're
optional,
you
don't
need
them.
There's
a
registry
go,
do
what
you
always
did,
that's
fine!
That's
it
absolutely
fine
and
yes-
and
it
also
removes
contention
on
that
registry.
So
that's
a
no-brainer.
We
don't
have
everybody
fighting
for
that
single
numbering
range
for
their
assignments.
They
can
just
ask
for
a
number
or
look
at
the
numbering
authorities
that
have
registered
themselves
and
ring
their
closest
who's,
offering
the
best
prices.
D
The
queue
is
a
very
good
size
right
now
it
is
empty,
but
but
I
know
that
we
had
some
questions
prior.
D
K
Actually,
if,
if
you
want
to
go
ahead
and
ask
a
question
first,
that's
fine
with
me
I.
Can
why
don't
you
start
sure.
D
Okay
in
in
reference
to
the
the
understanding
that
different
nodes
cannot
have
the
same,
node
number
is
a
different
consideration
than
a
single
node
cannot
have
multiple
node
numbers.
Those
are
two
separate
constraints.
D
D
B
K
Okay,
well,
I
will
start
by
responding
to
your
question,
and
what
I
would
point
out
here
is
that
both
the
IPM
scheme
and
the
DTM
scheme
are
valid
and
are
defined
in
9171.
K
So
there
is
already
a
precedent
for
having
multiple,
unique
node
identifiers
for
a
single
node.
That
is
the
ipn.
Node
number
is
not.
The
only
is
not
necessarily
the
only
unique
identifier.
For
that
note
there
there
can
be
a
dtn
node
identifier
as
well,
and
so
the
possibility
of
aliases
in
that
sense
already
exists
and
it
stood
I
would
say
difficult
to
legislate
it
away.
K
K
I
just
want
to
point
out
that
that
there
are
their
existing
mechanisms
that
that
can
frustrate
that
sort
of
uniqueness.
If
we
want
to
and
and
those
are
difficult
to
go
to
damage
it,
it
I
definitely
agree
that
that
the
same
node
number
should
not
be
used
for
multiple
different
nodes
and
and
and
that
I
think
is
an
important
thing
to
document
in
the
specification.
I.
Would
also
point
out
that
node
actually
is
a
technical
term
that
is
defined
formally
in
RFC
9171.
K
The
other
thing
I
was
going
to
bring
up
at
this
point
is
if,
if
we
say
that
there
are
authorities
and
the
absence
of
the
encoding
of
an
authority
in
in
an
IPM
endpoint
ID
implies
a
null
of
authority,
I
would
suggest
that
that
null
Authority
think
think
of
it,
as
as
an
authority
that
that
is,
there's
nobody
managing
necessarily
or
or
that
there's
a
an
authority
number
zero
someplace
that
is
in
charge
of
it
and
not
even
have
a
node
number
registry
in
Ayanna,
since
node
numbers
are
going
to
be
assigned
by
authorities
anyway.
K
So
if,
if
you,
if
you
want
to
have
a
formal
central
location
for
for
assigning
those
node
numbers
where
there's
no
specified
Authority
I,
think
that's
a
the
easiest
way
to
do,
that
is
for
there
to
be
a
zero
Authority
whose
job
it
is
to
do
that.
And
then
everything
is
in
the
same
model
and
you
can
eliminate
Ayanna
having
to
be
responsible
for
handing
out
node
numbers.
A
So
Scott
can
I
reply
to
that,
one
of
course,
so
I
think
we
are
in
effect
creating
a
zero
naming
Authority
and
it's
called
Ayana
and
it's
maintaining
the
registry
of
things
we've
already
handed
out
to
people
so
that
they
don't
suddenly
lose
their
their
allocation.
A
A
K
K
D
Yeah
so
that,
just
certainly
by
having
that
the
the
existing
behavior
of
node.service
is
unchanged,
but
if
we
feel
any
differently
about
it,
I
would
say:
let's:
let's
take
that
particular
part
to
the
list.
K
And
then
the
other
thing,
of
course
I
was
certain
to
bring
up,
is
a
a
preference
for
limiting
the
size
of
authority
numbers
and
and
the
and
and
no
number
assigned
by
an
authority
to
32
bits
each
so
that
they
can
be
combined
into
a
64-bit
node
number
as
they
currently
are,
and
minimize
the
impact
on
existing
implementations
and
deployments
of
dtn.
That
use
the
IPM
scheme.
A
F
A
You
know
what
I
mean:
we've
gone
down
to
half
the
number
of
bits,
you're
allowed
now
that
that
that's
a
that's
a
real
change,
and
also
in
in
my
implementation,
I'm
using
AVX
512
bit
wide
multiplexing
instructions,
so
I
can
load
all
four
of
these
numbers
into
into
single
registers
and
do
high
performance
math
on
it
and
I
don't
want
to
lose
that
ability
so
and
that's
an
example
where
you,
what
works
for
one
implementation,
doesn't
work
so
much
for
the
other
and
kind
of
we're.
K
Know,
wouldn't
the
64-bit
combined
Authority
and
node
number
and
and
aggregated
work,
just
fine
in
your
environment
and
and
conversely,
128
or
192
bits
would
work
very,
very
badly
in
in
environments
that
are
much
more
constrained,
such
as
a
lot.
A
A
K
Can
do
that
I'm
confident
that
they
took
that
registration,
because
that
was
the
rules
for
our
allocations
and
I'm,
confident
that
they
don't
want
necessarily
numbers
that
are
bigger
than
32
bits.
K
That
that
are
much
smaller
than
that
and
I
think
that
that,
in
practice,
numbers
that
are
bigger
than
32
bits
are,
in
general,
not
being
used
all.
D
Right:
let's,
let's
stop
this
one
here
we
do
have
a
couple
of
other
people
in
the
queue
sky
is
that
you
repost
this
to
the
list
so
that
we
can
have
any
remaining
conversation
and
I.
Ask
that
as
we
go
forward,
we
we
get
a
chance
to
clear
this
queue
quickly,
so
that
folks,
like
Scott,
will
have
time
at
the
end
of
the
meeting.
I
Thanks
Ed
quickly,
just
to
give
my
opinion
on
the
uniqueness
of
the
node
number
I
agree
with
this
card
on
the
on
the
first
one,
which
is
I
I,
think
we
shouldn't
prevent
a
node
having
more
than
one
node
number
or
or
any
or
a
processing
unit
having
more
than
one
node
number
and
then
on
the
second
one
I'm,
not
sure
we
should
be
putting
imposing
that
limitation
when
we
think
about
the
potential
distributed
implementations
in
ground
to
you
know
to
have
you
know
something
closer
to
Edge
processing
that
my
that
might
require
you
know,
depending
on
the
implementation
that
might
require
to
you,
know
the
option
to
have.
I
You
know
that
the
same
node
number
in
different
processing
units
this
may
be
at
the
same
Processing
Unit,
but
you
know
I'm
curious
about
whether
that
limitation
would
impose
or
limit
any
of
these
implementations.
D
And
I'll
bear
to
my
request
same
as
Scott
is,
if
you
could
make
a
post
to
the
mailing
list
specific
to
that
topic,
and
we
could
capture
that
what
is
likely
to
be
very
good
discussion
around
that
there.
B
Brian
cpcpl,
just
mention
and
I'll
put
this
on
the
list
too.
That
IPv6
made
the
same
kind
of
clarifying
distinctions
between
the
node
and
what
they
call
the
interface
for
address
assignments
and
the
same
kind
of
thing
could
be
done
here
to
just
clarify
what
actually
has
the
number
assigned
and
what
is
The
Logical
aggregation.
A
Thank
you,
Brian.
That's
a
very
valid
point.
From
my
perspective.
We
should
be
identifying
nodes
and
not
interfaces
I'm
with
I'm,
with
John
Day
on
this
that
it's
it
was
a
mistake.
I
mean
I,
see
why
it
happened,
but
I
I
don't
think
we
should
do
that
with
dtn,
because
we
don't
have
host
names.
We
just
don't
have
them.
So
let's
get
that
right.
Okay,.
G
You
were
playing
Ayanna,
some
very
specific
work.
Have
you
done
asked
for
an
early
Ayanna
review
on
this
art
craft?
We.
A
Completely
understood
and
noted,
thank
you.
Felix.
F
F
I
don't
want
to
have
a
node
number,
which
is
failed
across
multiple
nodes,
because
if
I
would
like
to
place
my
routing
on
node
numbers,
it
will
not
work
anymore.
At
the
same
time,
I
don't
see
a
reason
why
a
a
single
node
should
have
multiple
node
numbers.
If
I
need
multiple
node
numbers,
I
can
just
make
multiple
nodes.
I
think
also.
The
argument
from
Scott
does
not
really
hold
here,
because
these
are
really
separate
naming
schemes
so
there's
no
danger
of
confusion,
for
example
regarding
the
service
numbers.
F
So
if
I
see
it
as
a
kind
of
R,
yes
I'm,
not
sure
if
I'm
talking
about
an
endpoint,
ID,
1.2
and
2.2,
whether
it's
actually
the
same
service
in
the
end,
although
that's
really
separated
the
same
is
for
me
are
similar
things
regarding
the
administrative
element,
it's
an
alias.
It
would
be
the
same.
It's
not
the
areas.
I
would
have
a
notice
to
administrative
elements,
so
I
think
unless
we've
identify
clear
use
case,
we
would
say
single,
node,
multiple
node
numbers.
F
We
should
not
try
to
go
that
way
because
it
will
really
create
in
my
mind
it
would
create
difficult
problems
and
I
guess
these
questions,
whether
this
note
this
service,
1.2
and
2.2
would
be
the
same.
Would
probably
the
outset
could
be
different
answers
in
the
room,
so
it's
just
confusing
for
me.
So
unless
we
have
a
very,
very
clear
reason,
we
should
not
do
that.
D
So
thank
you
for
the
comment
and
also
ask
that
you
reply
with
that,
because
the
the
best
part
of
capturing
this
is
the
traffic
in
the
mailing
list.
So.
A
My
final
response
to
Phoenix-
and
that
was
the
thing
I
remembered
that
I
yielded
on
I,
actually
think
one
of
the
beauties
of
ipn
is
its
Simplicity
I
mean
yes,
I
turned
around
earlier
and
said.
You
know.
No
any
cast
know
this.
No,
that
it's
it's
unicast,
it's
simple!
It's
got
basic
numbering
it's.
It
should
be
really
tight
and
Light,
and
that
should
could
be
a
very
good
reason
to
say.
A
D
Thank
you
Rick.
Next
we
have
Brian
sipos
Brian
I'm,
going
to
ask
instead
of
the
30
minutes
that
we
have
allocated
if
we
could
pull
this
down
into
20
or
so,
and
why
don't?
We
start
with
bpv7
administrative
record,
quick
conversation.
B
Sure,
yes,
so
I
didn't
prepare
slides
for
the
administrative
record
topic
only
because
the
document
itself
was
not
changed.
It
was
only
recently
adopted
by
the
working
group.
There
have
not
been
any
substantial
feedback
or
comments.
Yet
on
the
the
document
there
was
one
editorial
change
to
clarify
that
it
didn't
it
didn't
change
the
Ayana
registration
policy.
B
So
it's
just
clarifying
that
there
is
no
change
in
the
policy,
so
that
document
has
now
been
adopted
by
the
working
group
and
a
new
version
has
been
uploaded
for
the
working
group.
So
really
at
this
point
it's
just
soliciting
feedback
and
comments.
D
Well
may
I
may
I
then
ask
the
working
group
to
please
take
a
moment
and
and
read
this,
this
newly
adopted
draft.
It
is
short
and
please
provide
comments
on
it.
If
we
don't
get
comments
on
it
within
the
next,
you
know
few
months,
then
we
will
assume
it
is
ready
to
go
into
the
next
step
in
this
process.
B
And
I
will
mention
also
that
the
Acme
working
group
and
the
security
area
director
are,
depending
on
this
document,
to
progress
to
the
iesg.
For
the
other
work
to
continue.
D
So
with
that,
we
can
then
move
on
to
the
next
presentation,
which
are
the
Cosi
BP
SEC
security
contacts.
B
A
B
So
this
is
discussing
a
an
individual
draft
currently
that
I
would
like
to
eventually
bring
into
the
working
group
I've
prepared
previous
slides,
and
these
ones
are
very
similar,
so
I'm
just
going
to
go
through
quickly
as
background.
The
context
here
is
that
the
bundle
protocol
already
has
what
are
called
the
default
security
context.
B
There
is
a
need
for
pki
security,
and
this
is
just
something
that
also
falls
in
with
the
general
overall
best
practices
of
current
Internet
and
network
authentication
and
security,
and
we
don't
want
to
have
to
reinvent
the
wheel
for
how
to
do
either
pki
or
to
do
the
algorithms
that
rely
on
pki,
and
so
what
this
is
proposing
is
to
use
the
cosay
message,
encoding
and
algorithms
in
bpsec,
and
actually,
since
these
earlier
slides,
Jose
has
actually
Advanced
to
internet
standard.
It
was
draft
standard
previously.
B
So
the
high
level
goals
here
are:
we
don't
want
to
alter
any
of
the
BP
sex
structures.
We
don't
want
to
alter
any
of
the
existing
pki
infrastructure
that
already
exists,
and
we
want
to
reuse
as
much
as
possible,
both
the
tools
and
the
protocols,
and
the
other
thing
is
that
looking
into
the
future,
we
want
to
get
gains
that
others
are
making
in
the
domain
of
kosai.
So
kose
already
has
working
groups
for
using
more
experimental
things
like
compressed
pkx
certificates
and
post
Quantum
and
hybrid
cryptography.
B
Now
the
they're
I'm
not
going
to
go
into
all
the
details
about
the
the
current
Jose
context,
but
the
the
concept
is
that
it's
reusing,
existing
logical
structures
and
we're
using
existing
encoding
structures.
So
it's
very
little
new
for
this
context
and
the
key
thing
about
making
this
work
is
that
we
have
an
interoperability
profile
cos
a
is
more
of
a
container
for
security
information.
It
requires
a
profile
to
be
able
to
say
here's.
B
B
The
the
main
goal,
though,
still
is
to
get
bpsec
working
with
current
existing
pki
tools
and
systems.
So
that's
the
the
push
here
and
as
it's
written
as
it
currently
stands,
this
is
a
mechanism
that
is
usable
today.
You
could
actually
use
this
with
pre-existing
pki
and
the
existing
certificate
profile
that
was
established
in
9174.
B
And
that
is
the
end
of
my
presentation.
So
both
feedback
is
welcome
on
this
document,
as
well
as
if
it
seems
valuable
enough
to
have
it
adapted
to
the
working
group.
D
So
so
is
that
then,
a
request
to
the
working
group
to
consider
adoption.
D
We
have
one
person
in
the
queue
Stephen.
M
M
B
Sorry,
oh
no,
the
the
relationship
here
is
that
the
the
Acme
extension
that
is
already
in
that
working
group
that
is
intended
to
address.
Where
did
these
certificates
come
from?
How
does
an
authority
validate
these
identities?
This
document
is
saying:
how
do
we
use
the
certificates
in
bpsec?
Currently,
the
certificates
are
profiled
for
TLS
for
being
used
with
the
tcpcl,
but
this
is
saying
we
can
use
them
also
for
BP
SEC,
so
that
we
can
get
end-to-end
security,
whereas
tcpcl
is
single
hub.
M
Okay,
so
I
guess
the
comment
is
I.
Don't
think
it's
fully
figured
out
how
you
might
do
the
equivalent
as
to
what
let's
say:
let's
encrypt,
do
a
dns-based
domain
validation,
so
I
don't
know
that
there
exists
an
equivalent
to
that.
That's
useful
and
I
think
that
that's
probably.
M
Right
but
as
I
recall,
so
I
did
a
quick
review
of
that,
because
somebody
asked
me
and
if
I
recall
that
that
document
just
said,
oh
there's
a
problem
there
that
we
don't
really
know
how
to
solve,
but
maybe
I'm
mischaracterizing.
It.
M
A
B
M
Right
so
my
recollection
of
the
resolution
in
the
Acme
working
group
was
we
kind
of
notices
that
you
know
acknowledging
the
lack
of
existence
of
something
like
the
main
validation
was
where
that
actually
document
seemed
to
land
and
what
I'm
saying
is,
if
you
want
to
figure
out
something
better,
that's
probably
something
to
do
here,
because
it's
only
here
that
you
really
know
how
do
you
know?
How
could
you
meaningfully
have
some
clue
that
the
node
ID
corresponds
to
some
keeper?
M
D
G
I
have
a
bit
of
a
point
of
information
here
as
you're
moving
and
looking
at
pki.
The
international
civil
aviation
organization.
Ikao
has
plans
and
development
on
an
international
scale,
pki
they
have
a
CP
policy
and
the
rest
of
it.
The
whole
model
for
including
all
member
states
in
this
pki
all
179
signatures
to
the
Iko
treaty
and
many
of
the
organizations
like
NASA
and
so
forth,
will
end
up
being
part
of
this
for
their
Aviation
components.
G
So
I
recommend
that
you
look
at
this
particular
pki
and
how
you
can
potentially
leverage
it
and
the
policies
and
the
C
organizations
which
be
rolling
this
out
over
the
next
couple
years
to
be
able
to
to
leverage
and
take
advantage
instead
of
doing
yet
your
own
PK
and
all
the
tremendous
headaches
that
that
entails,
because
for
those
of
us
who've
lived
pki,
it
hurts.
It
hurts
a
lot.
B
D
B
So
this
short
topic
is
about
CLA
services,
and
the
short
background
is
that
there
were
some
earlier
discussion
on
the
mailing
list.
That
about
can
we
Define
a
generic
sort
of
abstract
definition
of
what
a
CLA
is
supposed
to
do
in
its
communication,
with
the
bundle
protocol
agent
and
currently,
the
lack
of
a
common
logical
interface
has
risks
in
that
implementations
are
free
to
completely
choose
how
a
BPA
and
a
CLA
interact
with
each
other.
B
This
means
that
it's
inevitably
going
to
result
in
in
different
terminology
in
the
CLA
implementations,
different
terminology
and
the
BP
implementations
different
configuration
between
the
two
and
potentially
a
lack
of,
inter
interoperability,
of
people's
understanding
and
configuration
of
things.
So
this
is
not
talking
about
on
the
wire
interoperability,
but
this
is
talking
about
when
I
say
I've
acknowledged
when
I
say,
A
BPA
has
acknowledged
reception.
What
does
that
really
mean
right
now?
There
isn't
really
a
clear
definition
of
that,
and
what
this
also
does
is.
B
It
makes
it
more
difficult
for
a
a
node
implementation
to
swap
out
a
BPA
from
a
CLA
from
an
administrative
element
right
now.
Those
those
three
layers
are
distinct
in
RFC
9171,
but
in
implementations,
it's
not
so
easy
to
swap
out.
Somebody
else
has
a
really
good,
CLA
and
I
want
to
use
it
with
my
BPA
if
they're
not
following
the
same
service
model,
they're
not
going
to
be
able
to
work
together
and
it
becomes
really
difficult,
so
I'm
going
to
skip
over
the
goals.
B
But
the
the
basic
thing
is
that
it's
it's
a
logical
definition.
It's
not
an
API!
It's
not
talking
about
changings
to
clas.
It's
not
talking
about
making
changes
to
to
any
of
the
existing
definitions.
It's
trying
to
come
up
with
a
a
harmonized
definition
of
what's
happening
in
the
same
way
that
when
we
talk
about
Network
traffic
versus
something
like
a
posix,
socket
interface,
it
gives
people
a
basis
of
how
to
think
about
things
and
helps
understanding
and
interoperability.
B
So
this
is
a
summary
of
the
current
service
listing
for
for
in
relation
to
the
current
udpcl
tcpcl,
ltp,
CL
and
Vibe,
and
and
the
goal
is
to
get
feedback
on
all
kinds
of
strange
clas
that
people
have
been
and
plan
on
using
and
how
it
fits
in.
With
this
model,.
A
Rick
Rick,
chair
hat
off
I,
think
this
is
great
Brian
I
think
this
is
missing.
I
I
would
love
to
give
you
a
better
review
and
I
will
go.
Look
it
out
when
I
get
a
spare
moment.
I
think
it
is
really
important.
Work
I
think
it
also
has
use
not
only
for
CLA
implementers
and
BPA
implementers
I
also
think
it
helps
guide
the
working
group
into
understanding
what
we're
doing
with
forwarding,
because
forwarding
fundamentally
is
selecting
clas
understanding.
A
What
a
CLA
can
do
clearly
will
help
us
clearly
understand
how
we
express
forwarding
and
how
we
get
on
top
of
naming
and
addressing,
because
there
is
still
some
confusion
amongst
all
of
us,
and
some
of
it
goes
back
to
the
confusion
about
what
a
CLA
does
doesn't
do
and
fundamentally
is
so
I
totally
support
getting
it
written
down.
So.
B
And
the
other
interesting
thing
on
that
same
topic
is
that
there
have
already
been
in
the
appendix
a
discrepancies
identified
with
the
TCP
and
the
ltpcls,
and
these
are
discrepancies
that
are
not
necessarily
things
that
are
wrong
or
incorrect
about
the
spec.
The
things
that
are
just
left
open-ended
that
implementers
are
free
to
do
what
they
will,
but
if
they
choose
different
options,
they
are
losing
some
aspects
of
interoperability.
B
B
Only
that
feedback
and
contributions
are
welcome.
This
is
not
being
requested
as
a
working
group.
Adoption
at
the
point,
but
getting
some
feedback
is
helpful.
Thanks
and.
D
Just
to
Echo
Rick,
this
is
tremendously
would
be
a
tremendously
nice
thing
to
have
and
a
request
that
that
you
also
started
thread
on
the
mailing
list
to
so
to
solicit
those
comments.
D
All
right,
the
next
presentation
is
Sarah
heiner,
who
is
going
to
be
giving
updates
on
the
dtn
management
architecture,
not
the
dtn
management
architecture,
architecture.
O
So
Sarah
heiner
presenting
the
dtn
management
architecture,
not
dtan,
m-a-a,
oh
okay,
sorry
I'll
do
my
best,
but
please
remind
me
if
you
aren't
hearing
me
well
so
I'm
going
to
be
talking
to
some
of
the
highlights
and
changes
that
we've
made
to
this
document.
O
But
there's
of
course,
not
enough
time
to
address
everything.
So
I
would
definitely
encourage
you
to
check
out
the
most
up-to-date
version,
which
I
think
is
version
three
which
is
posted
online,
but
we'll
talk
through
the
problem
space
and
then
get
into
some
of
the
highlights,
like
the
reference
model
and
autonomy
model.
O
So
as
a
quick
sort
of
Rapid
Fire
introduction
to
the
dtnma,
you
might
recognize
it
as
the
AMA,
which
was
the
asynchronous
management
architecture.
We've
renamed,
because
asynchronous
doesn't
capture
that
problem
space.
The
way
that
we'd
hoped
to
it
wasn't
the
the
right
term
to
be
describing
this
work.
So
for
now,
at
least
as
a
a
useful
placeholder,
we've
switched
asynchronous
out
for
dtn
dtn
based
management
architecture
and
the
three
main
components
of
the
dtnma
is
the
response
to
needing
to
support
asynchronous
Behavior.
O
So
acknowledging
that
you're
managed
and
managing
device
are
not
always
going
to
be
in
constant
communication,
we
need
an
autonomy
engine
to
enable
self-management
of
those
managed
devices
and
we
need
compact
encodings
that
are
provided
by
our
naming
structures
to
address
the
fact
that
we're
operating
in
a
constrained
environment
so
really
high
level
overview.
But
we'll
dig
into
these
pieces.
O
Foreign,
so
the
first
change
that
we
made
to
the
document
was
defining
the
problem
space
a
bit
better.
So
we
started
by
identifying
a
dtn
as
a
constrained
Network,
which
emphasizes
why
we
are
interested
in
Compact
encodings,
and
then
we
refined
that
definition
further
to
say
that
a
dtn
is
also
a
challenged
Network.
So
that
addresses
the
asynchronous
nature
of
the
communication
and
the
fact
that
we
have
to
deal
with
challenges
like
disruptions
and
delays,
which
makes
us
focus
on
autonomy
as
a
way
of
responding
to
some
of
that.
A
O
Apparently,
a
wonderful
point
that
I
just
made
so
after
we
Define
that
problem
space
a
bit
better.
We
took
a
look
at
the
existing
Network
management
work
to
see
what
could
inform
the
design
and
the
structure
of
the
dtnma
and
as
a
quick
review
of
some
of
that
research,
we
took
a
look
first
at
SNMP
and
netconf
and
said
that
that
well-structured
approach
was
good,
but
the
low
latency
sessions
that
we
need
to
support.
An
approach
like
that
are
not
something
that
we
can
guarantee
in
a
dtn.
O
We
move
to
looking
at
rest,
conf,
which
is
stateless,
but
it
still
requires
the
huge
use
of
https
and,
in
some
cases,
large
data
transfers
which
again,
we
can't
guarantee
and
then
core
comp
which
is
running
over
coapp.
That
provides
the
concise
encodings
that
we
were
looking
towards
because
they
use
seawor
for
encoding,
but
they
still
require
transfer
of
data
using
the
Yang
schema
and
don't
provide
the
autonomy
model
that
we
thought
we
were
looking
for
next
slide.
O
O
We
think
that
the
DT
anime
fits
into
the
intersection
of
these
three
circles,
these
three
priorities
for
this
network
management
approach,
and
we
acknowledge
that
there
is
existing
good
work
in
all
of
these
circles,
but
we
haven't
found
something
that
lies
at
that
intersection.
So
the
dtnma,
for
example,
prioritizes
autonomy.
There's
work
done
in
the
anima
group
here,
but
this
is
for
distributed
calculation
of
network
data
for
data
centers,
it's
not
experiencing
the
same
constraints
that
we
might
in
a
dtn.
O
Similarly,
there
is
support
for
asynchronous
Behavior
by
Russ
conf,
but
again
requires
running
over
https
using
core
comp
we're
getting
those
efficient
encodings,
but
there
is
no
autonomy
model,
that's
associated
with
that
work,
because
that
was
not
the
focus
so
work
in
all
of
these
three
distinct
areas.
But
how
do
we
find
a
solution
that
gives
us
all
three
autonomy?
Support
for
asynchronous
behavior
and
those
efficient
encodings.
O
So,
following
through
on
some
of
the
feedback
that
we
got
from
the
working
group,
one
of
the
changes
that
we
wanted
to
make
was
to
update
the
dtnma
reference
model.
So
on
your
left,
you'll
see
the
old
AMA
model
and
the
feedback
was
that
this
was
just
too
generic
in
describing
the
autonomy
that
we
needed.
So
we've
updated
the
DT
anime
model
to
show
the
use
of
an
autonomy
engine
and
how
that's
configured
with
policy
and
I
promise
that
this
figure
will
get
a
lot
larger.
As
we
dig
into
the
details
there.
O
O
So,
first
we
are
making
use
of
pre-shared
definitions,
while
I
can't
guarantee
that
the
managing
and
manage
device
are
always
going
to
have
a
connection.
We
need
to
take
advantage
of
the
times
where
they
can
have
those
brief
periods
of
connectivity.
So
in
that
moment
there
is
data
and
models
that
are
going
to
be
pre-shared
and
the
managing
and
managed
device
are
agreeing
on
data
definitions
so
that
they
can
continue
to
work
when
they
are
not
connected.
O
So
this
is
where
that
autonomy
piece
comes
in,
that
managed
device
is
often
going
to
be
disconnected,
and
it
needs
a
way
to
act
on
the
policy
sent
over
from
the
managing
device
to
tell
it
to
react
to
different
events
and
how
it
should
be
handling
those
different
events
and
then
the
third
piece
here
is
command-based
management.
So
a
command
and
control
interface
that
is
provided
for
that
managing
device
to
get
information
like
policy
over
to
the
managed
device.
O
Okay,
so
details
as
promised
so
we'll
start
at
the
bottom
of
this
diagram,
we're
operating
in
a
challenged
environment.
So
real-time
data
negotiation
is
not
always
guaranteed,
so
we
need
to
pre-share
information
between
the
managing
and
managed
device,
and
this
includes
information
that
supports
our
autonomy
model,
also
adms
or
the
application
data
models
which
are
standardized
data
sets
that
both
the
managing
and
managed
device
agree
on.
O
And
then
we'll
talk
first
through
the
managing
device
and
then
move
over
to
the
manage
device.
So
at
the
top
of
the
managing
device,
are
the
applications
and
services
which
are
the
source
for
policy
which
informs
autonomy.
So
these
applications
and
services
are
creating
policy
statements
and
they're
also
the
target
for
reports
which
are
coming
back
from
that
manage
device.
O
O
O
The
DT,
anime
manager
is
also
responsible
for
reporting,
that's
receiving,
reported
data
back
from
the
manage
device
and
then
Distributing
to
the
applications
and
services
that
need
it
and
then
administrative
configuration
so
keeping
track
of
things
like
agent
mappings
and
then,
if
we
move
over
to
the
manage
device,
we
also
have
applications
and
services
sitting
here,
and
these
are
being
monitored
by
the
agent,
which
also
sits
at
the
manage
device,
and
the
agent
is
using
a
control
interface
into
these
applications
and
services
to
collect
State
information
to
alter
the
configuration
of
these
applications
and
also
impact
their
behavior.
A
Thank
you,
Rick
chat
off
and
hack
off,
you've
got
applications
and
services
on
the
managed
device
and
I
think
I
understand
what
those
are,
but
you've
also
got
applications
and
services
on
the
managing
device.
Is
that
are
they
the
same
ones
and
there's
some
kind
of
mapping
or
do
you
have
managing
applications
and
services
that
are
talking
to
applications
and
services
that
are
being
managed?
A
I've
just
got
confused
because
it's
the
same
text
in
both
places
is,
are
you
doing?
Did
you?
Are
you
doing
digital
twins,
or
are
they
just
two
different
groups
of
apps
and
services?
Two
two
separate
groups.
Thank
you.
D
Thank
you
Rick
and
another
question.
N
Postgraduate
School
is
a
really
helpful
talk
to
kind
of
frame
a
lot
of
this,
the
interface
with
application
and
services
going
down
to
these
controls.
Could
you
speak
at
all
to
some
of
the
the
transport
control
of
that?
Is
there
a
verification
of
delivery?
That's
ever
done
because,
obviously,
on
dtn's
packet
loss,
things
not
actually
arriving
at
the
destination
is
a
huge
concern.
O
Sure
absolutely
and
can
I
talk
to
you.
O
O
But
I
think
that
something
that's
valuable
about
this
approach
here
is
that
that
underlying
transport
to
send
those
controls
I
think
that
that
is
still
flexible.
We're
not
tied
to
what
we've
chosen
at
this
point,
but.
N
Guess
it's
if
we
think
of
you
know
it's
like
TCP,
addressing
everything
delivering
that
has
a
historically
hard
time
on
these
networks,
where
the
cause
of
packet
loss
was
not
congestion,
and
just
you
know
this
being
the
working
group
that
might
have
better
ideas
of
optimization
for
addressing
that
in
a
tolerant,
Network.
So.
A
Can
I
can
I
just
talk
about
this
Rick,
chair
hat
on
I?
Think
the
answer
to
this
is
held
elsewhere,
because
what
we've
done
is
tried
to
separate
the
reference
model
for
architecture
from
the
protocol
specifications
and
the
recommendations
for
each
of
the
lines
which
actually
do
the
communication.
So
if
the
communication
between
the
managing
and
managed
device
that
was
running
over
dtn,
then
the
architecture-
oh
well,
ignoring
what
it
runs
over
the
architecture
will
say
you
will
need
some
reliability
or,
if
you
don't
have
sufficient
reliability.
Here
are
things
that
must
be
considered
Etc.
A
So
it's
it's
describing
a
framework
and
reference
model
and
I
know
somewhere
in
the
pipeline,
whether
it
exists
as
a
draft
or
just
in
people's
heads
at
the
moment.
Saying
and
here
would
be
an
implementation
on
top
of
dtn,
possibly
using
custody
transfer,
bundling
bundle
in
order
to
add
that
reliability
constraint
a
reliability
requirements
to
meet
the
requirement
from
this
reference
model.
So
it's
kind
of
where
we're
splitting
a
very
big
piece
of
work
into
the
bits
which
need
to
be
specified
and
standardized
and
stuff
which
implementers
can
go
away
and
find
Cool
Tech.
D
Okay
and
and
I
would
just
add
a
comment
to
Rick's
comment,
which
is
from
from
an
acknowledgment
perspective,
because
certainly
one
of
the
questions
is
when
policy
is
generated
on
a
managing
device
and
is
then
sent
in
some
way
to
a
managed
device.
What
is
the
acknowledgment
associated
with
that?
Some
of
that
is
considered
and
held
at
a
transport
layer?
Did
the
did
the
policy
actually
get
there
to
be
unwrapped?
Alternatively,
some
of
the
policy
in
an
open
loop
management
system
could
be
when
your
policy
has
been
received.
D
One
of
your
policy
actions
is
to
produce
and
publish
data
associated
with
this
new
update
to
the
system,
and
so
there
are
sort
of
a
couple
of
different
ways
in
which
a
managed
a
managing
device
could
get
information
back.
That's
something
it
had
sent
prior
had
been
received
either
because
there's
a
transport
acknowledgment
that
it
was
received
or
there's
new
Behavior
such
as
additional
reporting
that
comes
back
from
the
device,
and
then
you
know,
because
it
is
doing
this
new
Behavior,
it
must
have
received
its
new
policy.
O
Okay,
great
so
then,
next
slide
moving
to
the
dtnma
agent.
O
So
the
DT
anime
agent
is
interfacing
with
a
few
pieces
here,
so
monitoring
the
state
of
the
applications
and
services
that
it
knows
and
doing
that
without
a
regular
connection
to
the
managing
device.
O
O
It's
also
performing
data
Fusion,
so
creating
new
data
values
or
putting
together
reports
based
off
of
the
common
understanding
of
data
definitions
from
those
pre-shared
definitions
at
the
bottom
of
the
diagram
and
then
again
performing
some
administrative
configuration.
So
keeping
track
of
the
mapping
to
the
managing
devices,
for
example,
looks
like
so
I've
been
saying
autonomy
quite
a
bit,
but
now
we
get
the
chance
to
dig
into
the
autonomy
model
a
bit
better
and
the
autonomy
model
is
important
because
the
manager
and
the
agent
again
will
not
be
in
constant
communication.
O
So
how
does
the
agent
know
what
steps
to
take
based
off
of
the
data
that
it's
sampling?
So
if
we
start
at
the
top
of
this
diagram
here,
the
manager
is
sending
policy
Expressions
to
populate
a
rule
database,
that's
local,
to
the
agent.
So
these
rules
are
if
a
stimulus
event
occurs
then
respond
with
this
action,
and
those
rules
are
informing
the
agent
of
how
it
needs
to
be
reacting
and
the
next
slide
to
talk
to
the
bottom.
O
O
There
might
be
a
generation
of
a
report
to
get
data
then
back
to
the
manager,
which
is
in
charge
of
then
Distributing
that
further,
and
it
might
also
update
the
runtime
data
store,
which
is
local
to
that
dtnma
agent,
but
is
updated
as
well
by
the
manager
in
times
of
connectivity.
So
populating
information
beyond
the
standard
agreed
upon
data
definitions
that
are
a
part
of
the
adms
yeah
I.
Think
that
that's
my
last
slide.
So
if
there
are
questions.
A
I'm
gonna
jump
the
queue
because
I'm
set
in
the
chair.
Thank
you,
Sarah
I
think
this
is
really
good
work
and
I
know.
There's
many
other
people
involved
behind
the
scenes.
Getting
this
document
put
together.
I
think
this
goes
back
to
my
earlier
comment
about
framework
having
a
framework
where
we
can
talk
and
address
about
these
things
in
generalities,
without
getting
caught
up
in
a
binary
representations
and
wire
protocols
and
all
that
exciting
stuff
and
actually
understanding
what
we're
trying
to
achieve
and
and
that
very
simple,
but
effective
and
non-turing
complete
rules-based
system.
A
That's
very
clever,
stuff
and
yeah
can
I
request
to
the
working
group.
Please
review
this
stuff.
This
stuff
is
clever
and,
and
it
needs
a
lot
of
eyes
over
it
and
it's
an
enjoyable
read.
So
thank
you.
D
I
And
and
and
so
again
there
are
others
for
you
know
creating
analypt
in
this
document.
It
is,
it
is
a
great
read,
Echo
your
comments,
you
know,
I
encourage
every
single
Latin
need
to
to
read
the
document.
It's
it's
very
informative
and
you
know
put
a
clear
path
to
implementation.
I
have
a
few
questions,
I'll
be
sending
all
of
them
to
the
mailer
list,
but
I
think
some
of
these
are
interesting
to
the
audience.
The
first
one
is:
why
are
you
referring
directly
to
bpv7
only
in
the
documentation?
D
Well,
so
I
I
can
jump
in
on
that
just
for
a
moment
to
say
that
we
actually
have
users
of
potential
users
of
this
model
that
aren't
using
either
bpv6
or
bpv7
or
BP
at
all.
So
I
I,
don't
know
that
that
we
specify
or
require
bpv7
but
I
kind
of
jumped
ahead
Sarah.
If
you
had
an
answer
to
that,
oh.
O
I
Yeah,
okay,
yeah,
it's
not
mandated,
but
there
are,
you
know,
even
in
the
in
the
abstract.
It
goes
straight
to
bpv7,
and
you
know
every
time
bundled
protocol
is
mentioned.
It
goes
straight
to
VP,
since
I
was
curious
to
see
if
there
was,
you
know
any
specifics
there,
the
second,
the
second
one
is
more
a
comment.
You
know,
I
went
to
the
document,
the
you
know,
the
use
cases
are
fantastic.
I
I
Basically,
you
know
when
we
think
about
etn
networks
and
the
ground
components.
How
you
know
how
you
envision
the
architecture.
Could
you
know
coexist
with
other
management
implementations
or
how
you
know
DT
anime
would
run
on.
You
know,
scenarios
that
are
you
know,
a
segments
that
are
not
that
challenge.
O
Sure,
that's
a
great
point
that
you
know
we
want
to
develop
an
architecture
that
is
robust
enough,
that
we're
handling
the
the
challenges
like
I've
mentioned
with
a
dtn,
but
at
the
same
time
we
don't
want
to
be
so
focused
on
addressing
challenges
that
we
can't
take
advantage
of.
The
underlying
strengths
of
different
network
segments.
D
Go
ahead,
but
both
Rick
and
I
had
also
a
quick
follow-up
comment
to
that.
One
is
several.
Ietfs
ago
we
had
someone
present
whose
Master's
thesis
was
a
netconf
to
amp
Bridge
to
serve
that
kind
of
boundary
and
and
if
you
can
find
that
in
the
meeting
minutes
you
know
for
a
past
ITF,
please
look
for
it.
If
not
send
me
an
email
and
I
can
find
it
for
you.
A
My
quick
response
was
I'm
not
having
had
to
clarifying
question.
My
question
clarified
earlier
on
the
applications
and
services
on
the
managing
devices,
one
of
those
or
more
of
those
could
be
interoperable
Bridges
with
existing
Management
systems
and
that's
how
it
plugs
into
the
model.
So
so
you
could
you
could
view
those
as
Upstream
management
devices.
I
Okay,
awesome
and,
and
necessarily
is
one
thing
that
posted
me
a
little
bit
on
the
intermittent
use
case
and
there
is
a
sentence
that
says
that
the
you
know
in
case
of
disconnections,
the
agent
you
know,
may
store
those
reports
or
may
rely
on
the
underlying
transport
protocols.
Some
of
it
you
know,
I
was
a
bit
possible
because
I
think
the
whole
idea
was
to
rely
on.
I
You
know
bundled
protocol
type
of
networks,
but
then,
if
we're
imposing
storage
constraints
or
not
constraints,
but
if
we're
inclined
that
you
may
need
to
store
messages,
I'm
not
sure
how
this
would
you
know
would
help
the
whole
architecture.
I
O
I
so
so
the
concern
is
a
Reliance
on
a
store
and
forward
Network,
while
we're
also
making
the
claim
that
we
are
not
dependent
on
running
on
bpv7.
O
I
Your
what
is
you
know,
it
says
that
the
agent
May
store
the
message
or
their
reports.
Until
you
know
the
link
is
available
or
you
know
it
could
rely
on
the
transport
protocol.
So
I
think
that
you
know
that
that
post
I
mean
a
little
bit
because
the
whole
yeah
at
least
that
the
rest
of
the
document
tends
to
imply
that
you
know
things
like
a
store
and
forward.
Are
you
know.
D
All
right
noted,
my
only
comment
was
to
say
as
well
that
there
are
some
instances
of
perhaps
use
of
this
architecture
in
places
that
are
not
running
over
bundle,
six
or
seven,
but
but
certainly
a
bundle
is
there.
It
provides
the
service.
D
So
so,
thank
you
so
much
for
the
presentation,
excellent
presentation.
My
my
request
for
the
working
group
is
this
document
is
a
reef,
a
an
update
to
the
original
AMA
document
and
we
would
like
to
finish
it,
and
so,
if
you
have
not
had
a
chance
to
read
it,
please
do
please
provide
comments
back
to
the
working
group
mailing
list,
all
right
and
next
we
have
Scott
Johnson,
who
wants
to
provide
a
a
demo
of
IPv6
support
for
dtn
Scott.
H
I
think
I'm
going
to
go
ahead
and
share
my
screen.
If
that's
okay,
sure,
okay,
so
I'm
gonna
go
ahead
and
do
that.
H
Foreign
Loop,
okay
and
so
hi,
everyone,
I'm,
Scott,
Johnson
and
I'm,
presenting
live
from
inside
hurricane
Nicole.
As
you
can
see
here,
I
could
tell
you
about
myself
at
this
point,
but
I
I
would
rather
talk
about
ideas,
so
I'm
going
to
do
this,
the
Hawaiian
way
and
talk
story
a
little
bit
in
lieu
of
autobiographical
content.
H
The
title
of
my
talk
today
is
extending
the
reach
of
the
delay,
tolerant,
networking
into
IPv6
networks
or
the
ultimate
Nat
avoidance,
as
some
here
can
attest
from
bearing
direct
witness
or
their
own
personal
participation.
The
internet
was
conceptualized
and
designed
to
provide
end-to-end
connectivity
between
any
two
publicly
numbered
hosts
between
then
and
now.
Things
have
changed.
H
Address
scarcity
due
to
use
and
monetization
has
led
to
the
rise
of
that
Scourge
Nat
in
ipv4
Networks,
a
spot
check
pins
the
going
market
rate
for
IP
address
transfers
at
approximately
fifty
dollars
per
ipv4
address
between
isps.
Consequently,
retail
costs
of
the
consumers
has
risen.
A
premium
on
static
addresses
to
the
consumer.
Further
encourages
the
use
of
that
foul
Kluge
Nat
and
further
breaks
the
end-to-end
design
principle
but
hold.
There
is
a
way
to
restore
this
core
concept
into
the
evolving
growing
Network.
H
It
is
IPv6
and
it
holds
the
promise
of
addresses
of
Plenty
for
all,
just
as
it
has
for
a
couple
of
decades.
Now,
since
we
stood
up
the
three
ffe
six
bone
networks
and
put
the
protocol
through
its
paces
these
days,
over
80
percent
of
mobile
networks
are
numbered,
uniquely
only
with
ibv6.
H
According
to
your
recent
internet
Society
study,
these
Edge
clients
have
a
particularly
nasty
strain
of
nat,
called
DS
Lite
used
when
connecting
to
ipv4
only
hosts,
which
makes
an
ipv4
and
IPv6
tunnel
two
forward
and
added
packets
to
the
client
via
dynamically
allocated.
Rfc
1918
address
space,
so,
in
short,
we
have
IPv6
native
mobile
networks
check
off
of
our
list.
H
The
largest
reaching
eyes
isps
in
the
Aaron
region
are
now
widely
deploying
native
IPv6
service
to
the
client
devices
via
slack
or
dhcpv6,
at
the
C8
at
the
CPE,
from
speaking
with
colleagues
in
other
rir
regions,
similar
or
better
deployment
is
generally
the
case.
This
tends
to
restore
the
property
of
end-to-end
connectivity
network-wide,
eliminating
the
need
for
Nat
and
Nat
traversal
techniques
when
trying
to
use
the
internet
as
designed
allowing
universally
accessible
services
to
be
offered,
if
desired
by
client
devices
on
the
edge
of
the
network,
adding
to
the
tally.
H
Ipv6
native,
fixed
access
networks
check
by
adding
IPv6
functions
to
Applications
previously
only
capable
of
ipv4
operation.
The
reach
of
those
applications
increases
significantly
all
the
way
to
the
modern
terrestrial
Network
Edge.
This
presents
distinct
opportunity
for
the
dtn
community.
Ipv6
enablement
of
bpv
BP
based
applications
allows
scalable
protocol
stress,
testing
and
new
application
development
due
to
increased
use
case
scope
for
delayed,
tolerant
networking.
H
In
this
light,
I
have
endeavored
to
add
ipv
V6
support
to
the
open
source
branch
of
jpl's
implementation
of
bundle
protocol
and
the
associated
software
suite
ion.
Thus
far,
the
IPv6
enabled
UDP
LD
ltp
over
UDP
and
TCP
convergence
layer
adapters
have
been
completed
as
well
as
the
new
core
Library
functions,
which
they
call.
These
convergence
layer
adapters
have
been
tested
in
both
private
land
environments
and
in
Coast
to
Coast
tests
on
publicly
numbered
Networks
as
I
demonstrate.
H
These
three
modes
of
IPv6
operation,
running
on
a
single
node
concurrently
for
you
I,
would
ask
that
you
all
consider
which
other
protocols
that
are
implemented
in
ipv4,
capable
convergence
layer
adapters
are
most
desirable
to
be
ported
to
IPv6
operation
next,
and
so
what
you're
seeing
here
is
five
different
nodes
on
the
top
left.
The
larger
terminal
is
the
primary
node
that
I'm
going
to
be
running.
H
The
demonstration
from
the
remainder
of
the
nodes
will
be
receiving
bpings
and
responding
knock
on
wood,
because
it's
a
live
demonstration
I've
written
a
small
script
here
to
perform
various
functions.
To
keep
me
from
having
to
type
things.
H
So
here's
a
list
of
running
a
convergence
layer,
adapter
protocols
on
this
node.
You
can
see
we're
using
ltp,
UDP
and
TCP,
and
this
is
the
command
BP
admin
L
protocol
showing
this
now
we
need
to
press
only
the
any
key
to
continue
here.
We're
listing
all
bundle
protocol
index
on
the
Node
you
can
see.
We
have
an
ltp
node
that
is
numbered
with
basically
packets
allocation,
and
then
we
have
a
UTC
UDP
and
TCP
convergence
layer,
adapters
or
index.
H
Rather
that
are
listing
on
that
IP
address
here,
the
adducts
for
the
node.
We
have
a
loopback
on
ltp
and
then
two
remote
nodes
being
two
of
these
here
on
the
screen.
The
UDP
and
TCP
representations
there,
as
well
as
the
active
TCP
socket
at
the
bottom.
H
It's
worth
noting
that
the
top
left,
that's
being
now
in
the
top
right
terminal,
are
running
on
the
same
host
under
different
user
accounts.
H
Which
is
announcing
the
ipv4
and
IPv6
addresses
that
are
being
used
here.
Are
the
open
sockets
on
the
machine.
H
H
And
so
that
is
from
California
to
Florida
here
in
my
data
center,
which
is
underneath
the
hurricane,
this
is
locally
on
the
same
host
from
one
user
account
running
a
node
to
another
user
account
running
a
node,
and
this
is
over
ltp
by
UDP.
The
first
test
was
to
Via
UDP
only.
H
And
here
we
are
testing
UDP
ltp
over
UDP
Coast
to
Coast
from
California,
where
it's
basicallypackets.com
is
residing
to
my
data
center
here
in
Florida.
H
And
there
we
go,
and
so
once
more
or
two
or
tally,
IPv6
enabled
delay
tolerant
networking
check
this
greatly
broadens
the
terrestrial
reach
of
delay,
tolerant
networks
enabling
applications
using
BP
to
extend
to
the
true
Network
Edge
I'll
return
you
to
my
question.
What
I
enabled
convergence
layer
adapter
should
have
ipv
V6
functionality
added
next.
D
Well,
first,
thank
you
very
much
and
second
Rick.
A
Again,
thank
you
very
much.
Scott
I
I'm
going
to
answer
your
question.
I
think
they
all
should
I
I
think
we
build
conver
any
convergence
layer
that
runs
on
top
of
Ip
should
should
support
V4
and
V6
I
I
think
that's
a
no-brainer
I'm,
not
meaning
I,
think
you've
done
a
great
piece
of
work
there.
It's
great
to
see
ion
V6
native
I.
Think
it's
really
good,
but
the
answer
is:
if
we
support
IP,
we
support
V4
and
V6.
That's
that's
the
way
so
great
to
see
that
running.
Thank
you
very
much.
A
It's
always
nice
to
see
actual
gtns
happening
as
a
demo.
So
thank
you
and
enjoy
the
hurricane.
H
Thank
you
very
much
for
for
having
me,
and
you
know
these.
These
networks
that
I
operate
here
are
designed
to
withstand
these
hurricanes
through
many
years
of
trial
and
error.
That's
why
we
wound
up
deploying
our
own
autonomous
system
for
redundant
routing.
D
And
and
you
have
one
more
question
from
Kevin.
J
Hi,
it's
Kevin
Paul,
it's
really
for
everyone,
because
it's
it's
been
a
long
time
since
I've
put
my
nose
into
this
community.
So
back
in
the
day
when
we
were
sort
of
thinking
about
different
clas
and
and
dare
I
say
the
FIB
that
we
were
that
you
would
do
at
the
node,
the
the
vision
was
oh
well.
The
next
hop
could
be
email.
The
next
cop
could
be.
You
know,
person
on
a
bicycle
with
USB
key
or
one
of
my
more
favorites
is
write.
The
message
up
on
the
wall.
J
Somebody
comes
up
later
copies
it
down
and
it
goes
on
its
way.
You
know
this
IP
is
obviously
sort
of
in
the
ietf,
but
I'm
wondering
has
there
been
progress
or
work
in
any
of
those
more
kind
of
wild
ideas?
We
had
back
in
the
day,
so
Rick.
A
Chat
on,
as
far
as
I'm
aware,
that
is
still
absolutely
the
ambition
underwritten
by
the
statements:
convergence
layer,
adapter
that
clear
separation
between
the
act
of
creating
moving
generating
bundles
and
the
things
which
will
do
it.
So
we
keep
that
nice
layer,
separation,
I,
don't
believe
and
I
would
personally
strongly
push
back
against
anyone
saying
a
CLA
is
always
an
IP
based
service,
absolutely
not.
A
J
H
Could
I
can
answer
that,
actually
there
or
or
provide
an
answer
to
it?
There
is
a
member
of
the
ipn
Sig
here
with
us,
Sam
agrasic,
who
has
just
completed
his
first
running
code
for
a
uart
adapter,
so
that's
a
Serial
console
and
that
I
believe
he
is
using
to
connect
to
Laura
radios
for
long
range,
Wireless
terrestrial
connectivity.
But
he
can
speak
to
that
more.
A
It's
great
to
see.
You
know
a
patch,
TCP
or
UDP
running
over
over
serial
or
some
kind
of
chunking
that
that
moves
bundles
over
serial
great
great
example,
but
I
think
Kevin's,
aiming
at
a
much
higher
concept,
which
I
agree
with
him
of.
If
we
can
serialize
it
and
move
it.
That's
great.
K
D
All
right,
so
with
that
we
are
at
time
yes,
so
thank
you
all
very
much
again.
Please
continue
to
use
the
mailing
list
and
if
you
were
presenting
please
make
sure
to
post
additional
questions
and
requests
for
review
to
that
list.