►
From YouTube: IETF106-DTN-20191121-1330
Description
DTN meeting session at IETF106
2019/11/21 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
A
I'm
Rick
Taylor
first
off
as
this
is
an
IETF
meeting
it.
This
meeting
is
held
under
the
no
well.
You
should
have
all
read:
I'm
no
12
before
if
you're
not
familiar
I
recommend
you
have
a
look
on
the
internet
and
read
it
thoroughly
that
much
more
adieu,
I'll
move
on
a
bit
of
admin.
First
off.
Let
me
try
and
make
this
do
something
sensible.
There
we
go
so
we
need
a
note-taker.
Would
anyone
like
to
volunteer
to
make
some
notes?
A
There
is
an
etherpad
URL,
so
you
can
dynamically
take
notes
and
other
people
could
take
notes.
I
know
edge
normally
takes
some
notes,
but
he
is
speaking
so
if
somebody
else
can
jump
onto
etherpad
while
EDD
is
speaking
and
try
and
capture
any
of
the
comments
that
are
made
at
the
mic
or
anything
like
that,
that
would
be
greatly
appreciated.
Also,
can
somebody
please
monitor
jabber
for
us,
we
need
to
jabber
scribe.
Although
we
have
meet
echo
a
meet,
echo
is
very
good.
A
It
would
be
great
if
somebody
is
watching
the
jabber
Channel
any
volunteers,
please
thank
you
very
much
and
the
other
little
bits
of
admin
are
obviously
please
state
your
native
name
at
the
microphone,
because
we
have
remote,
attendees
and
presenters.
There's
a
pink
cross
up
here,
so
you
are
stood
in
the
right
place
for
the
audiovisual
recording,
which
all
eventually
ends
up
on
YouTube
and
the
remote
attendees
can
also
see
you.
A
So
we
have
some
apologies,
which
is,
as
you
can
tell
it's
just
me
at
the
table
here
mark
launched
a
senses,
apologies
and
Magnus
Westerlund
is
also
remote.
He
can't
make
it
in
person
so
he's
our
ad,
but
I'm
sure
he
can
jump
in
across
meat
echo
and
tell
me
where
I'm
going
wrong.
So,
first
off
the
agenda,
we
have
a
reasonably
light
agenda
for
this
working
group.
Meeting.
I
will
briefly
run
through
some
of
the
document
status.
A
We,
as
some
of
you
know,
oh
the
other
apology
is
I,
have
very
nasty
cough,
so
occasionally
I
may
splatter.
We
have
three
key
documents
that
are
all
in
the
eye.
Let
me
get
this
right.
They
are
all
currently
going
through
the
area
reviews,
so
we
have
had
some
reviews
from
the
Janerio
sec
area
for
the
various
documents.
A
These
of
course
came
back
with
comments,
as
they
always
do,
and
so
I
will
cover
some
of
the
status
of
some
of
those
documents
and
two
of
the
authors
of
two
of
those
three
documents
are
here
and
they're
going
to
say
a
few
words
about
the
comments
that
were
raised
and
how
they're
being
addressed.
There
may
be
some
open
questions
for
the
working
group,
which
we
have
plenty
of
time
to
discuss
and,
of
course,
that
discussion
would
be
taken
to
the
list
as
well.
A
I'm
I
have
the
feeling
they're
not
too
contentious,
but
I'll
come
on
to
that
and
Scott
said
he
wanted
to
say
a
few
words
about
bundling
bundle
encapsulation.
If
he
had
time
and
some
notes,
I
Scott
has
no
slides.
If
we
have
time
in
there's
interest,
can
you
do
something
freeform,
that's
very
kind,
and
then
we
have
an
open
mic
at
the
end.
So,
prior
to
this
meeting,
the
chairs
put
a
call-out
on
the
mailing
list
to
say:
does
anyone
have
anything
interesting?
They
wanted
to
present.
A
There
was
a
resounding
silence,
but
that
doesn't
prevent
somebody
who
was
too
shy,
or
it
was
too
early
to
put
something
on
the
mailing
list.
If
they
have
something
interesting,
please
bring
it
to
the
microphone.
We
have
time
to
discuss
these
things.
So,
okay,
does
anyone
want
to
bash
this
agenda?
Do
you
want
to
add
any
items,
and
we
missed
something
important.
A
Okay,
so
going
through
the
document
status
for
those
of
you
who
are
not
entirely
up
to
speed
with
what
we're
doing
in
the
working
group
at
the
moment,
there
are
three
critical
documents
that
are
the
foundation
of
the
DTN
protocol
stack
for
the
IETF
work,
one
of
which
is
the
update
to
the
bundle
protocol
BP
bists.
So
the
status
of
this
is
the
genic
review
has
come
in.
There
were
questions
over
the
definition
of
time
and
we
are
still
waiting
for
the
ops
area
review
and
the
secondary
review
to
come
back
in
I'll.
A
The
first
defined
protocol
for
doing
this
moving
is
based
on
TCP
and
hence
the
TCP
convergence
layer,
and
this
is
the
version
four.
So
this
is
updating
the
work
that
was
done
in
the
IRT
F,
now
doing
it
in
the
IETF.
So
this
will
be
a
standard
tracked
document
and
again
we're
going
through
the
review
phase.
With
it,
ops,
dir
came
back
and
said:
it's
fine
there's
some
typos
can
you
fix
sec
dir
came
back
with
a
couple
of
queries
about
because
we're
running
over
TCP.
A
A
So
how
is
certificate
handling
managed
for
that
TLS
connection
between
peers
and
also
because,
because
DTN
can
be
a
DTN
subnet
effectively,
so
a
an
administrative
area
could
be
running
in
a
controlled
environment
such
as
International,
Space
Station,
where
your
traffic
isn't
travelling
across
the
public,
internet
and
you're,
pretty
sure
about
which
devices
are
connected
to
the
network,
mostly
because
you
put
them
there
the
option
to
say
look:
I
don't
need
TLS.
I
am
an
embedded
device
without
the
power
to
do.
Tls
can
I
not
please,
as.
A
Means
there's
a
flag
in
the
initial
handshake
in
TCP
CL,
which
says:
look
I
can't
do
it.
Please
don't
demand
that
I
can
and
if
you
are
happy
with
that,
we
can
proceed
so
obviously,
as
security,
a
DS
came
back
and
said.
Well,
that's
is
that
a
downgrade
attack?
How
can
that
be
exploited?
Have
you
considered
this
and
Brian
C
posish?
The
primary
author
has
answered
these
two.
A
What
he
believes
is
to
his
satisfaction,
we're
waiting
for
comments
to
come
back
from
the
sec,
a
DS
to
see
if
they're
happy
with
that
and
brian
says
he
has
a
new
version
of
the
draft
which
captures
his
comments.
Sorts
out,
the
myths
and
I
believe
he
is
waiting
for
the
general
to
review
to
return
before
he
actually
pushes
out
another
document,
and
the
third
document
is
so.
We
know
how
to
define
a
bundle
and
we
have
an
example
of
how
to
move
a
bundle,
the
missing
pieces.
A
How
do
we
secure
this
bundle
not
only
for
integrity
but
also
for
encryption
and
that's
covered
by
the
BP
SEC
document,
which
again
is
in
the
review
phase?
So
it
is
currently
marked
as
on
hold
because
it
has
a
normative
reference
to
beat
this
BP
Biss
is
waiting
because
I
Anna
raised
some
questions
about
the
reuse
of
registries,
from
the
IEEE
RTF
documents
now
being
taken
on
by
IETF
documents
and
I.
Will
let
Scott
try
and
get
into
a
bit
more
detail
about
this,
although
it's
quite
a
hazy
area.
A
Otherwise
Janet
came
back
and
said
there
were
some
typos
and
some
small
knits,
not
a
great
problem,
and
we
are
waiting
for
the
SEC
Arya
review.
So
BP
SEC
is
a
it's
a
security
document.
It
lots
of
deep
security
aspects
to
it
and
I
I
have
no
evidence
of
this,
but
I
believe
the
SEC
will
take
a
little
bit
of
time
to
make
sure
it's
correct.
They
have
done
an
early
review
on
it
before
so.
We're
hoping,
there's
gonna
be
no
showstoppers,
but
I.
Think
Eddie's,
gonna
say
a
few
things
about
that
as
well.
A
Some
of
you
are
are
aware
that
we
held
a
virtual
interim
between
Montreal
and
today,
18th
of
September.
To
be
precise.
The
purpose
of
the
virtual
interim
was
to
make
sure
that
those
3
key
documents
that
really
are
blocking
they
have
to
be
done
by
the
working
group
to
give
us
a
foundation
on
which
to
build
everything
else.
So
it's
critical
that
these
really
do
get
through
onto
the
standards
track
as
fast
as
possible.
So
it
was
a
discussion
about
how
do
we
the
progress
of
those
documents
and
we'll
go
over
that
again?
A
There
was
a
big
debate
for
those
who
aren't
aware.
Bep
abyss
is
an
update
of
a
document
that
was
originally
worked
on
in
the
IRT
F,
not
the
IETF.
So
there
is
some
politics
and
admin
around,
although
this
is
bundle,
protocol
version
7
and
obviously
we
would
like
to
say
use
version
7,
not
the
previous
version
6,
because
it
is
better
TM
version.
6
is
owned
by
a
different
standards
body.
So
how
do
we
indicate
to
readers
of
bundle,
protocol
version
6
that
they
should
go
and
look
at
version
7
and
the
conclusion?
A
That's
the
virtual
interim
was
that
we
should
work
out.
The
chairs
should
go
away
and
discuss
with
the
80s
and
the
IRT
F
people
involved
in
order
to
just
make
this
happen
so,
rather
than
leaving
both
documents
in
existence,
try
and
work
out
the
best
way
to
mark
RFC,
5050,
so
bundle
protocol
version
six
as
obsolete
ie.
A
If
you're
starting
a
new
implementation,
don't
use
this
use
the
new
one
that's
coming,
and
the
other
thing
that
was
discussed
in
the
virtual
interim
was
given.
We've
got
these
three
critical
documents,
almost
complete
and
they're.
You
know
they're
going
through
the
iesg
review
phase
and
they're
heading
for
the
RFC
editors.
What
do
we
do
next
in
this
group?
So
I
know
over
the
last
a
couple
of
meetings
people
have
have
said
they
have
ideas.
A
We
still
have
a
couple
of
charter
items,
and
so,
as
part
of
that
virtual
interim,
we
started
to
draw
up
a
list
of
some
stuff.
People
would
like
to
work
on
or
like
to
see
done
and
that
was
published
out
on
the
mailing
list
and
there
was
some
good
feedback
and
discussion
about
it.
The
ad
magnus
had
some
concerns,
which
was
that
the
list
was
too
ambitious
and
too
big,
and
was
there
enough
energy
in
the
working
group
to
get
this
done
in
a
reasonable
amount
of
time?
So
that's
the
list.
A
A
A
A
We
were
avoiding
the
word
simple,
but
a
really
simple,
TCP
implementation
that
might
be
able
to
avoid
some
of
the
complexities
that
was
holding
up
the
working
on
the
TCP
CL
draft,
and
so
he
wrote
that
up
and
submitted
it,
and
it
was
accepted
as
a
working
group
document.
However,
now
that
TCP
CL
is
has
left
the
working
group
and
is
now
in
the
IHG
pipeline,
do
we
still
need
to
bother
to
work
on
a
minimal,
less
capable
subset
of
that
functionality,
or
are
we
just
making
work
for
ourselves
so
I'm?
B
It's
more
of
a
and
it's
more
of
an
administrative
workload.
Then
then,
then,
a
compositional
workload,
if
the
TCP
CL
specification
is,
is
making
sort
of
progress
that
it
is
then
I
certainly
am
NOT
a
great
champion
of
pushing
head
with
MTC
PCL
if
it's
not
needed
so
I'm
happy
to
let
that
fall
by
the
wayside.
A
Obviously,
I
will
take
that
question
to
the
list,
but
I
am
interested
just
quick
show
of
hands
in
the
room.
How
many
people
have
read:
TCP,
CL
or
MTC,
PCL
Scott?
You
wrote
it
both
of
them,
no
only
one
of
them.
Okay,
so
only
a
couple
of
people,
so
this
might
be
a
better
topic
for
the
mailing
list.
So.
A
B
B
B
Read
this
review
and
he
had
some
responses
of
his
own,
and
it
was
his
feeling
that
there
were
some
of
these
points
that
actually
needed
to
be
discussed
in
the
working
group
and
I
will
call
those
out
as
I
go
through
the
ones
that
I
think
are
are
none
our
really
sort
of
open
to
some
question
RC
50/50.
This
is
sort
of
a
big
one,
but
I
think
that
what
happened
in
on
the
mailing
list,
since
the
interim
meeting
was
it
was
decided
that
it
was
not
our
job
to
obsolete,
RC
50/50.
B
So
this
document,
that's
not
obsolete,
RSC
50/50
Stewart's
question
was
it's
not
clear
what
the
statuses
RFC
is
with
regard
to
our
C
50/50,
if
it
modifies
the
status
of
50/50
s
and
we
need
to
say
so
and
so
in
the
interest
of
not
pretending
that
into
50/50
doesn't
exist
at
all.
I
proposed
to
add
this
sentence
to
the
introduction
and
the
abstract
to
make
that
clear.
Just
to
say
that-
and
this
is
this-
is
a
distillation
of
what
came
out
on
the
mailing
list
that
I
RTF
is
advised.
B
This
document
is
an
update
of
RSA.
50/50
reflects
lessons
learned,
does
not
obsolete
RC,
50/50,
probably
can't
so
anyone
reading
this
document
should
be
aware
that
we
believe
it's
an
improvement
over
our
FC
5050,
but
our
5050
50
is
not
obsoleted.
If
you
want
to
use
it,
then
at
least
for
the
time
being.
Of
course,
you're
welcome
to
hold
on
Scott
Magnus
is
coming
in
with
a
question.
Oh
yes,.
C
B
A
Magnus
so
Rick
here
yeah
from
my
understanding
of
the
results
of
the
virtual
interim
and
the
and
the
poll
put
onto
the
mailing
lists,
the
consensus
of
the
working
group
was
to
recommend
to
the
IRT
F
that
they
did
obsolete
it.
So,
although
we
can't
prompt
salute
it,
we
would
strongly
recommend,
as
best
we
can,
that
they
do
so,
and
the
IRT
F
chair
at
the
time
or
I
remember
who
he
was
he's
calling.
Yes.
A
C
In
some
sense,
we
actually
put
in
put
in
place
a
process
for
this
case
to
actually
have
ITF
obsoletes
iot
of
documents
in
some
sense,
so
so
that
process
has
inside
it
has
been
created.
Due
to
the
discussion
we
had
before
also
saying
when
we
but
yeah
I
mean
you
know
the
working
group
consensus
supposed
to
not
Erica
obsolete
it,
but
there
it's
for
the
future.
C
D
D
C
Thing
is
that
we
worked
on
the
process
back
besides
say
of
doing
that
jobs.
Basically
in
the
future.
If
you
put
an
IRT
assess
an
abstract
document,
assess
obsoletes
an
IRT
F
experimental,
we
now
know
what
to
do
with
it.
That
question
will
then,
in
the
approval
stage,
go
to
IR
to
the
IRF
share
and
if
they
agree
on
obsoleting
IRS
documents,
that's
what's
gonna
happen.
So
Magnus.
C
E
What
would
happen
because,
like
I
understood
just
right
now
that
the
that
you
expect
that
the
IRT
F
is
obsoleting,
this
document
right?
So
they
would
need
to
write
another
RFC
that
obsolete
this
RC,
which
seems
like
a
little
bit
an
overhead
right.
So
if
you
want
to
have
this
document
obsolete
it,
you
should
do
it
now.
E
A
B
C
A
process
standpoint
that's
what's
what's
you
know,
however,
my
interpretation
of
the
consensus
call
in
some
sense
was
that
it
wasn't
clear
capped
at
the
absolution
should
occur
at
the
same.
At
the
exact
moment,
this
gets
published
this
New
York
C,
which
is
what
will
happen
if
you
put
in
that
absolutes
and
the
IRT
F
share
with
Moses
for
asking
hours.
He
agrees
on
doing
it.
A
E
A
F
B
Going
back
to
phase
a
that's
fine,
well,
so
I
will
revise
this
obsolete.
We
which
it
said
six
months
ago,
if
we
do
that.
Does
that
also
obsolete
the
other
RFC's
that
we're
supporting
RFC
fifty
fifty
and
I'm
thinking
there
specifically
of
the
RFC's
for
for
the
Ayana
registries
that
RFC
fifty-fifty,
but
references
in
a
way
it's
actually
easier.
If
it
does
because
then
we
can
go
back
in
and
and
and
set
up
new
registries
for
RFC
50
of
our
for
for
bpp,
seven
and
and
avoid
trying
to
merge
with
the
existing
registries.
B
C
B
C
Which,
which
will
defines
the
registry
with
the
updates
to
the
registration
rules,
that
these
documents
specify
so
I
think
we
covered
and
and
I
don't
want
to
go
back
on
that
decision.
Also,
that
seems
to
be
that
from
the
main
list
that
we
have
the
young
registry
between
the
different
versions,
which
is
what's
now
setup
so
with
the
updates.
C
B
E
B
B
That
was
easy,
CRC's
Stuart
remark
that
surprised
that
we're
using
CRC's
in
this
document,
given
especially
given
the
the
harsh
environment
and
so
what
I've
done,
is
I've
added
in
4.1.1.
A
note
saying
that
if
you
want
more
robust
protection,
then
use
a
a
bundle,
integrity
block,
a
block
integrity
block,
rather
as
defined
in
BP
SEC,
the
the
expectation
being
that,
in
some
environments,
crcs
are
fine.
In
some.
You
do
need
a
stronger
protection
of
of
the
blocks.
B
B
B
In
my
view,
this
is
the
the
third
sentence
and
in
the
ex
extract
that
I've
got
here
from
what
Stuart
said.
Is
that
all
you
need
to
say
is
that
you
need
a
monotonically
increasing
system
and
our
software
convenience.
It
shows
the
latter.
So
what
I've
done
is
I
took
for
table
1.6,
which
is
about
DT
and
time
and
just
took
out
almost
everything
and
said
a
t10
time
is
an
unsigned
integer.
B
A
B
A
C
Mean
they
are
the
same
so
but
I
think
it's
I
mean
this.
Your
I,
don't
think
you
should
use
2119
language
there
at
all.
You
I
mean
this
protocol
uses
a
particular
representation
of
this
value
and
and
that's
I
think
you
have
state
that
this
is
represented
as
as
a
C
Brown
side,
because
it's
it's
not
you
defining
how
it's
being
represented,
and
you
don't
need
to
make
that
a
must
shall
or
whatever
it's
it's
not
debate
about.
You
just
declare
that
this
is
defined.
Well
only
thing
how
it's
presented
is.
B
Is
that
a
general
comment
applying
to
all
of
the
remarks
on
representations
through
the
document,
because
we,
we
essentially
say
this
sort
of
thing
for
for
all
parts
of
the
bundle
right,
because
everything
is
supposed
to
be
in
in
C
bar
format
and
and
what
we
say
is
specifically
this
thing:
people
in
C
bar
format.
Isn't
this
C
bar
format,
yeah.
C
C
It's
it's
I
mean
it's
not
necessarily,
and
maybe
so
I
actually.
That
was
so
that
this
is
a
very
minor
point.
I
think
it's
not
like
people
I
mean
having
it
as
chalice
is
not
a
I
think
it
slightly
will
be
use
of
it,
but
that's
actually
not
I'm
a
little
bit
worried
about
that.
This
what's
written
here
is
not
easily
decodable
for
an
implementer
either
I'm.
B
B
A
C
B
C
A
C
C
A
Because
I
was
just
having
a
quick
look
through
the
back
a
log
of
messages
about
this,
and
there
is
a
reference
to
a
seaboard
raft
about
time,
stamping
where
they
appear
to
have
some
good
text
exactly
covering
this
talking
about
an
interval
of
seconds
since
1970,
and
they
covered
the
leap.
Second
thing
and
it
might
be
I
think
was
actually
reference
from
Caston.
It
might
be
a
good
bit
of
reference
material
to
agree
around
possibly.
B
B
F
B
Okay,
there
are
in
after
which
section
where
there's
a
mention
of
some
anticipated
extension
blocks
and
Stewart's
comment
was
that
these
should
be
handled
through
an
iron,
a
registry
and
the
block
numbers
13,
14
and
15,
and
they
shouldn't
be
in
the
text
until
they're
standard.
So
all
of
those
have
been
removed.
B
There's
some
comments
on
securities,
our
definition
of
the
bundle
and
bundle
protocol
and
well
I've
done
there
as
I've
added
a
note
in
Security
section
saying
that
it's
a
current
research
topic
there
there
isn't
it.
It
is
a
work
in
progress
and
there
is
an
internet
draft.
We
could
refer
to
it
here
or
just
says
the
current
research
topic,
whatever,
whichever
makes
sense.
A
A
E
A
B
All
right
and
spirit
other
comment
on
security
was
that
there's
material
in
the
security
section
that
seems
to
be
defining
protocol,
there's
actually
a
lot
of
shouse
language
in
there,
and
he
points
out
to
be
better
to
define
that
in
the
body
of
the
text
or
point
to
a
definition
or
another
document
which
is
B
P
SEC.
So
what
I've
done
is
remove
all
the
text
in
the
security
section
that
has
any
of
this
normative
sort
of
language
in
it.
E
D
C
Yeah
so
I
think,
what's
he
really
referring
is
that
he
thinks
it's
unclear,
which
particular
registry,
because
I
mean-
and
especially
in
this
case
we
have
the
registries
that
grouped
together
in
that
general,
upon
the
protocol
versus
on
the
protocol.
It's
actually
well
I!
Guess
it's
the
group
now,
but
I
think
we
just
need
to
be
clear
on
which
particular
registry.
C
B
C
Yeah
I
mean
I
think
it
was
like
in
some
cases
to
what
bundle
protocol
when
he
was
missing
in
some
of
these
cases,
so
that
it
wasn't
clear
that
this
was
the
bundle
protocol,
particular
registry,
so
just
check
that
you
go
to
Layana
registry
page
check
that
you
have
the
full
registry
name,
identifier,
so
to
say
the
string.
That's
actually
on
the
eye
on
a
web
page
for
each
registry
that
that's
actually
written
exactly
in
the
draft.
Okay.
C
B
H
B
B
B
B
C
Mean
in
the
straightest
tables,
where
comments
you
use
like
the
what
I
put
in
the
shed,
which
is
square
bracket
RFC,
to
be
defined
as
shortened
together.
It
comes
RFC
to
be
D
and
square
brackets,
and
you
put
that
in
the
reference
part
of
the
tables
so
and
then
during
the
this
publication
process,
I
notice
in
the
arts,
the
editor
will
change
that
to
the
RFC
number
assigned.
Okay,.
B
Okay
and
then
with
the
third
part
of
the
INR
considerations,
comments
were
that
how
come
there
are
references
to
our
state
5050,
and
does
this
indicate
that
our
C
50
is
expected
to
remain
in
our
current
protocol?
How
do
we
do
that
and
I
and
I'm
here
again,
I'm
I'm
uncertain
what
we
do
about
this.
If
we're
going
to
have
an
eye
on
a
section
that
comprises
a
merger
of.
A
Scot,
the
Rick
Taylor
again
I'm
slightly
confused
about
the
context
of
this,
was
the
question
around
the
fact
that
you
have
tables
of
new
entry
suggestions
for
Ayana
in
the
document
which
have
the
previous
values
reused
by
RFC
50
50
in
them.
That's
right
so
from
my
non
chair
opinion.
If
I
was
writing
that
I
would
not
include
values
that
weren't
defined
by
the
document
to
your
writing.
So
you
say,
dear
Ayane,
please
add
these
values
and
update
existing
if
required,
the
following
values
and
let
Ayane
maintain
the
registry.
You
just
defined
the
Deaf
okay.
G
C
C
C
This
is
how
the
table
will
look
at
the
point
of
registering
this
new
updates
to
the
registries
and
going
forward.
Of
course,
you
can
add
to
it.
Individual
video
saying,
as
you
say,
WIC
adds
the
following
entry
in
the
table
and
that's
gonna
be
hanged
by
Anna,
but
at
this
point
we
actually
defining
a
snapshot
of
a
reorganization
of
the
table.
A
C
Yeah,
you
just
need
to
add
where
you
have
fifty
fifty
and
in
cases
like
those
based
on
like,
if
you
take
the
bundle
formats
registry
or
saying
which
different
I
mean
there,
you
have
to
have
those
interests.
You
know
this
is
both
56
and
seven
and
of
course
this
is
included
order
the
RFC
to
be
and
the
50:54
that's
my
opinion
list.
So.
B
B
And
the
processing
control
Flags
Stuart
said
that
these
are
critical
enough,
that
there
should
be
a
more
demanding
criterion
for
updating
them,
such
as
standards,
action,
so
I
said
fine,
so
I
changed
the
registration
policy
request,
as
shown
here.
The
registration
policy
has
changed
to
standards,
action
and
because
there's
a
limited
number
of
bits
available
that
should
only
be
granted
for
stannis
tract
RFC,
approved
by
a
iesg.
B
J
A
B
A
B
B
Is
there
there's
a
there's,
CB
VL
at
the
end
of
the
document?
What's
the
license
position
for
that
and
I'm,
quoting
from
Magnus's
email
here
that
it's
it's
not
code,
it's
it's
format,
description
comparable
to
a
B
and
F,
so
I
don't
proposed
it
to
change
anything
there,
and
then
there
was
more
on
namespaces
there,
several
places
where
Stewart
asked
what
where's
the
namespace,
but
something
in
space
and
I
we've
been
through
this
just
a
few
minutes
ago.
So
I
think
the
resolution
here
is
it's
it's
fine.
B
B
A
C
E
C
C
A
Rick
speaking
personally
now
I've
worked
out
what
on
earth
we're
talking
about
sorry
for
being
slow,
no
I,
don't
think
so
I
as
me,
speaking
personally,
not
as
chair
I.
Don't
particularly
like
this
eight
bit
field
anyway,
but
I
know
the
reality
is
IP
n
exists
and
the
DTN
text-based
schema
exists
as
well.
So
we
need
to
have
a
selector
yeah.
Let's
and
there.
B
A
E
A
C
Yes,
okay,
good
I
think
at
least
is
because
I
mean
what's
like
255
would
be
used.
If
we
ever
run
out
of
space
at
this
table,
you
would
use
255
sucess,
oh
by
the
way
you
need
to
go.
Look
at
something
else.
He
actually
understand
this.
Okay
and
and
I.
Don't
think
this
never
will
occur
in
this
because.
A
D
Start
here
so
I
used
to
see
a
lot
of
rfcs
with
you
know,
reserved
for
future
standards,
action
and
point
taken
that
we
may
not
be
fond
of
the
existence
of
this
field
in
the
first
place,
but
we'd
be
even
less
fond
if
people
start
using
it
and
and
filling
vast
regions
of
the
of
the
8-bit
space
with
with
different
things.
So
it
might
not
be
unreasonable
to
you
know:
reserve
half
the
space
for
standards
action
and
only
leave
half
the
space
open
for
people
to
do
whatever
crazy
things.
They're.
Thinking
of
doing.
A
C
To
begin
with,
then,
you
have
a
need
use
that
your
iced
tea
mean
inbounder
protocol
and
that's
and
then
you
need
a
document
that
defines
how
you
do
that
and
that's
I
think
a
reasonable
bar,
and
it's
basically
for
expert
also
check
that
cells.
This
is
a
reasonable
request
to
add
it.
I
think
it.
We
don't
need
to
put
the
board
at
high
and
split
I
mean
I,
wouldn't
expect
an
issue
with
this.
C
B
So
we
leave
that
alone,
good,
there's
a
reference
to
the
DTN
research
group
website
in
the
for
additional
information
section.
They
thought
that
was
a
bad
idea,
so
I've
removed
that
reference
and-
and
he
objected
to
the
word
contraindicated,
which
is
actually
goes
back
to
RC
50/50,
but
as
points
out
some
some
of
us
may
be
less
familiar
with
this
word
than
others
and.
A
B
B
A
From
my
perspective,
these
topics
are
to
be
picked
up
by
the
RFC
editor
and
they
will
quiz
you
about
this
and
other
things
you
didn't
realize:
okay,
they
they
they
didn't
pick
it
up
for
our
1650.
Well,
perhaps
we'll
get
a
different
editor
this
time
or
you
know,
I
I'm,
not
sure
it's
worth
spending
time
working
on
the
English
language.
At
this
point,
it's
a
perfectly
valid
I.
A
C
B
A
H
Sex
so
hello,
my
name
is
ed
brain.
You
may
need
to
be
close
to
microphone.
This
look
great
and
I
work
at
Johns,
Hopkins,
Applied,
Physics,
lab
and
I
wanted
to
just
go
over
some
updates
to
VP
SEC.
So
the
version
of
BT
sac
that
went
in
for
review
was
VP
SEC
version
12.
We
made
some
responses
to
those
reviews
which
was
BP
section
13.
H
None
of
the
changes
or
comments
were
significant,
certainly
nothing
that
changed
the
processing
or
the
data
structures
associated
with
the
protocol.
So
it's
used
up
a
little
extra
time.
While
we
have
the
working
group
together.
I
wanted
to
also
talk
about
some
of
the
interoperability
work
that
we
are
doing,
and
some
policy
rules
associated
with
to
see.
If
the
working
group
had
any
comments
on
on
those
before
before
the
internet
drafts
associated
with
them
would
come
up
on
the
list.
So
for
BP
SEC
12,
the
the
general
review
came
back
with
ready
with
nits.
H
There
were
some
very,
very
minor
comments
associated
with
making
sure
that
we
had
spelled
out
acronyms
before
they
were
used,
or
there
was
an
extra
space
in
between
two
words
and
we
fix
all
of
those
without
any
fuss.
We
did
not
get
sector
review
comments
back,
I
believe
that
they
were
initially
requested
to
be
do
about
a
week
ago
on
November
14th,
but
we
don't
have
an
update
on
that.
So
if
anyone
does
have
an
update
on
that
or
if
there's
a
way
that
we
could
appropriately
ask
for
an
update
that
would
be
appreciated.
H
The
BP
sec
document
had
called
out
block
types
two
and
three
for
the
integrity
block
in
the
confidentiality
block.
We
won't
do
that
because
RFC
5050
block
type
registries
in
v6
had
already
defined
two
and
three,
and
we
don't
want
that
kind
of
collision,
so
these
will
be
moved
most
likely
to
eleven
and
twelve
instead
of
two
and
three,
it
really
doesn't
make
a
difference.
H
From
our
point
of
view,
it's
still
all
in
codes
within
one
byte,
so
it
would
have
really
practically
no
impact
on
on
VP
sack
or
the
size
of
the
blocks
and
in
VP
sack
version.
Thirteen
I
updated
those
to
be
eleven
and
twelve
I
will
probably
have
to
publish
a
fourteen
which
I'm
going
to
wait
on
for
SEC
sector
review
when
I
won't
even
put
eleven
and
twelve
and
I.
Think
the
right
thing
to
do
is
to
say,
as
assigned
by
iana
or
whatever
the
appropriate
text
is.
A
H
And
and
really
as
long
as
it's
less
than
I,
think
22
or
so,
which
is
what
what
you
can
pack
into
a
seaboard
mic
without
going
into
two
bytes.
That
would
be
our
preference
so,
but
to
respond
to
the
to
the
comments
that
we
gotten
to
date,
we
put
out
a
VP
613.
We
made
all
of
the
minor
changes,
we
corrected
the
gen
our
nets
and
we
cleaned
up
some
other
terminology.
H
In
particular,
there
was
some
leftover
terminology
that
talked
about
key
parameters
as
opposed
to
just
parameters,
and
there
really
isn't
a
sense
of
parameters
and
key
parameters.
They
are
all
just
parameters,
so
we
cleaned
that
language
up
actually
walking
through
the
description.
The
text-based
description,
of
example
blocks
in
an
example
bundle.
The
text
did
not
match
the
figure,
which
was
surprising
when
I
went
through
and
did
a
final
read-through.
So
we
made
a
few
minor
Corrections
to
make
sure
that
the
text
matched
the
figure.
H
The
figure
was
correct
and
then
really
because
we
had
made
a
terminology
change
from
security
from
cipher
suite
to
security
context.
We
made
sure
that
we
had
used
the
proper
terminology
security
context
everywhere.
If
that
was
needed
in
the
document,
so
these
were
all
clean
up
things:
nothing
that
changed
the
standard,
the
data
structures
or
its
processing.
H
H
Technical
change
to
the
document
is,
but
mostly
clarifying
text,
some
of
which
was
responding
to
the
comments
that
we
got
from
BP
SEC,
6
sector
review,
so
I
think
that
we're
good
there
we're
not
expecting
any
significant
problems
or
changes
or
showstoppers
coming
back,
and
we
do
have
the
same
reviewer
as
the
person
who
reviewed
this
seven
versions
ago.
So
I
think
we'll
be
ok,
we'll
update
the
Ino
section
as
we
need
to.
H
We
will
make
sure
the
only
other
thing
that
has
come
up
is
the
BP
SEC
document
makes
a
reference
to
something
called
PID
reference
as
we
use
it
in
the
document.
It
just
means
the
reference
to
the
security
source,
a
ID.
However,
someone
noted
that
in
BP
v6
terminology,
ID
reference
has
a
specific
meaning,
which
is
a
pointer
into
a
dictionary
in
a
primary
block
in
BP
version
6,
and
so
that
is
something
we
should
not
use.
H
So
we
introduced
the
concept
of
a
security
context
separate
from
a
cipher
suite,
because
a
cipher
suite
is
a
suite
of
tools
that
you
would
use
to
apply.
Different
security
constructs
into
the
bundle
to
generate
Saltz
to
generate
ciphertext
from
plain
text.
However,
a
cipher
suite
assumes
a
set
of
configurations,
and
one
of
the
things
that
we
would
typically
see
such
as
in
IPSec,
is
a
security
Association.
A
security
Association
would
be
some
predefined
or
pre-configured
set
of
configurations
that
could
be
shared
and
to
end.
H
That's
not
necessarily
one-to-one
a
reasonable
thing
to
expect
in
a
delay,
tolerant,
Network.
However,
the
concept
that
there
is
a
security
context
around
a
cipher
suite,
which
is
the
cipher
suite,
plus
the
configuration
or
understanding
of
configuration
associated
with
how
to
use
and
apply
that
cipher
suite,
is
a
useful
concept
and
if
we
just
use
the
term
cipher
suite,
it
doesn't
imply
cipher
suite,
plus
that
additional
contextual
information
so
to
make
sure
that
there
was
not
a
confusion
of
those
terms.
We
decided
not
to
say
cipher
suite.
H
We
decided
to
say
security
context
in
that
to
then
give
an
example
of
how
this
would
be
used.
We
define
some
interoperability
security
context
and
there
is
one
called
interoperable
Interop
SC
zero
zero,
which
is
a
working
group
document
and
presumably
would
would
go
forward
or
once
we
make
sure
there
are
no
changes
in
BP
SEC
and
we
have
then
started
looking
past
the
initial
draft
security
context
into
what
other
ones
might
be
useful
to
have,
and
so
here
are
three
examples
of
current
thinking
on
security
context,
concepts
that
are
out
there.
H
The
first
is:
is
there
value
either
in
the
existing
interoperability
security
context
or
in
a
new
one,
to
add
a
self
signing
bib,
and
for
those
of
you
who
are
familiar
with
the
context
of
a
bib,
a
bib
is
a
security
block
that
is
added
to
a
bundle
and
the
block
type
specific
data
in
the
bib
has,
among
other
things,
a
a
result.
A
signed
integrity
signature
over
the
target
block
that
it
is
targeting
and
is
there
a
value
at
having
a
separate
signature
result
in
the
bib?
H
H
So
it
could
be,
but
again
if
this
were
a
security
context,
if
the
security
context
has
a
superset
of
the
cipher
suites
used,
it
would
say
if
you
are
using
a
security
context.
The
security
context
would
say
here
are
the
cipher
suites
that
we
would
be
using
and
we
would
use
these
particular
cipher
suites
to
generate
target
signatures
and
self
signatures
and
handle
them
in
this
way?
If
you
then
were
to
chain,
if
you
were
to
use
a
different
cipher
suite
with
a
different
context,
it
would
be
a
different
security
context,
not
this
one.
H
B
Schiaparelli
again
so
that
I
I
think
that
wasn't
exactly
my
question,
I
think
you
you
asked:
what
would
it
be
valuable
to
have
a
self
signing,
bib
and-
and
my
question
was:
do
you
need
it?
Do
you
need
self
signature
on
a
bib?
If
the
cipher
suite
did
you
happen
to
be
using,
is
based
on
asymmetric
encryption
or
do
you
only
need
self
signature
on
a
bib
if
you've
got
symmetric
keys.
H
H
Would
you
also
want
to
include
things
like
the
block
processing
flags
of
the
bib
in
the
integrity,
signature
and
I
think
that
deciding
whether
you
want
to
protect
changes
to
the
bib
block
itself
is
different
from
whether
you're
using
symmetric
or
asymmetric
key
to
generate
some
of
the
contents
of
the
bib
block.
So
I
thought
that's
I
I,
don't
know
that
I'm
understanding
that
question.
H
So,
if
I
create
a
if
I
create
a
security
bib,
it
will
have
security
results
in
it,
but
it
will
have
a
lot
of
other
material
in
it
and
I
don't
want
an
attacker,
for
example,
to
twiddle
some
bits
in
the
bib
in
a
parameter
field
or
somewhere
else
that
that
never
touched
a
cipher
suite
symmetric
key
or
a
symmetric
key.
Okay.
A
A
You
could
use
a
cipher
suite,
that's
self,
protecting
in
some
way,
probably
probably
key
pair,
but
that
other
metadata
isn't
isn't
covered
under
that
protection.
And
therefore
your
question
is
what,
if
you
could
put
a
bib
on
that
and
then
you
put
an
endless
recursive
loop
of
self
signing
each
other.
So.
H
A
A
B
B
I
guess
in
my
mind,
the
the
endless
recursive
loop
that
you're
talking
about
is
is
the
issue
and
maybe
not
maybe
incorrectly,
but
but
why
would
the
self
signature
itself
will
not
be
susceptible
to
being
fiddled
with
so
that
it
no
longer
works?
There's
probably
a
reason
for
that,
but
I
don't
know
what
it
is
well.
A
Is
the
impact
any
different
if
whether
you
I
take
your
point
that
earlier
in
the
path
of
transit
of
that
bundle,
an
intermediate
node
may
say,
hey
the
integrity
signatures
have
been
tampered
with.
Mmm-Hmm
drop.
Is
that
I
suppose?
The
point
is
that
you
could
do
that
check
earlier
in
the
path
or
could
you
not
I
suppose
with
the
security
context
where
an
intermediate
node
could
not
work
out
where
the
tamper
has
occurred?
I
I'm,
trying
to
work
through
the
use
case.
B
H
H
A
little
heavyweight
yeah,
the
third
is
to
say
of
the
data
that
is
not
integrity
protected
in
the
bib.
Add
an
integrity
signature
to
it,
which
does
not
force
you
into
infinite
recursion.
It
simply
says
you
can
you
can
construct
an
integrity
signature
over
the
data
that
is
not
signed
and
carry
that
signature,
I'm.
A
H
Other
is
a
single
target.
Multiple
result,
something
else
that
came
back
was
it
would
be
nice
to
have
a
security
context.
That
would
say
here's
a
cipher
suite.
You
don't
need
to
necessarily
have
a
single
signature
with
a
single
key
over
the
target
data.
What
we
could
do
is
provide
multiple
parameters
for
the
security
context
and
you
would
generate
multiple
results
and
the
security
context.
Documentation
would
then
come
back
and
say
if
any
of
these
verify.
E
H
Then
the
block
has
verified
and
it
would
be
okay
or
some
quorum
of
them
verify,
and
that
might
be
a
way
of
saying
if
I
don't
know
all
of
the
recipients
and
I
don't
have
a
single
multicast,
a
ID
key,
then
I
can
I
can
carry
multiple
signatures
and
we
think
that
that's
a
reasonable
thing
to
do
as
opposed
to
having
multiple
bid
blocks
or
multiple
individual
entries.
You
could
capture
it
in
a
single
security
context
and
that
would
be
a
little
less
bytes
on
the
wire
Rick.
A
Again,
I
can
see
some
as
far
as
I've
understood
it
I
think
I
can
see
some
value
in
that
you
to
handle
the
case
of
expired
certificates.
So
you
could
multi
sign
with
out-of-date
information
that
at
least
the
person
that
the
other
one
knows
they
can
unpack
it
and
know
it's
out
of
date
because
one
of
the
targets
validated
the
integrity,
but
they
knew
they
were
using
an
old
key
or
something.
H
A
H
So
that
is
good,
that's
good
feedback,
I'll,
take
it
from
the
notes
and
then
the
last
was
for
for
even
just
the
interoperability
security
context
that
we
have
right
now.
The
integrity
block
only
captures
integrity
over
the
data
portion
of
its
target.
So
if
it
is,
if
it's
looking
at
target
block
b1,
it
will
look
at
B
ones,
block
type
specific
data
fields
and
generate
a
signature
over
that.
However,
there's
an
entire
block
header
separate
from
the
data.
H
There
is
no
reason
why
you
could
not
take
the
entire
block
or
large
pieces
of
the
block,
canonicalize
it
and
generate
the
integrity
signature
over
more
than
just
the
block
type
data
fields,
and
there
are
three
things
at
least
that
could
be
done
there.
One
is,
we
could
leave
it
as
is,
and
only
generate
the
integrity
signature
over
the
block
type
specific
data.
The
other
is
generate
a
signal
signature
over
the
entire
extension
block,
or
at
least
a
superset
of
just
the
block
type
specific
data
which
would
which
could
be
done
or
the
third
is.
H
You
generate
two
signatures,
which
seems
like
a
lot
of
work,
one
over
the
block,
type,
specific
data
and
one
separately
over
the
block
extension
data
and
have
rules
as
to
whether
both
are
required
or
one
is
a
nice
to
have
in
case
someone
changes,
a
block,
processing,
flag.
I
know
if
there
were
any
opinions
about
that.
H
And
then
the
last
one
is
the
sim,
the
same
question
reimagined
for
a
confidentiality
block,
which
is
again
the
ECB
will
replace
the
block
type
specific
data
of
its
target
with
ciphertext,
and
it
will
generate
a
signature
over
that
ciphertext.
Is
there
then
value
in
having
a
separate
plaintext
signature
over
the
the
non
block
type,
specific
data
fields
of
its
target,
the
block
type
ID,
the
the
block
number,
the
block,
processing
flags
things
like
that,
then.
A
H
I
believe
BP
biz
has
a
canonicalization
algorithm
for
extension
blocks
that
that
this
could
be
used.
I
believe
that's
the
case.
I
no
longer
believe
that
that
is
the
case,
but
but
one
could,
however,
a
security
context,
and
this
is
something
that
the
BP
SEC
document
describes.
A
security
context
is
able
to
define
a
canonicalization
algorithm
to
be
used.
If
one
does
not
so
so
those
were
some
ideas.
As
we
start,
we
will
start
putting
forward
some
security
context.
H
A
Rick
we've
been
round
this
before
and
I
believe
that
the
the
the
C
but
there's
this
there
was
a
working
group
working
on
C
Burrell
signatures
and
certificate
and
key
material
who
works
through
all
the
canonicalization
of
C
bore
serialization
rules.
But
I'm
I
will
need
to
look
through
my
notes
and
try
and
remember
what
nerve
I'm
talking
about.
But.
H
H
The
malicious
node
could
drop
the
b
ib
signature
change
the
target
block.
If
the
destination
doesn't
know
that
a
big
should
have
been
there,
it
would
not
think
to
check
the
integrity
of
the
target
block
and
would
pick
it
up
and
use
it,
and
so
something
has
to
exist
at
destinations.
That
say
this
is
what
you
are
expected
to
have
in
a
bundle
and
when
you
generate
bundles.
This
is
what
you
should
put
in
based
on
those
specifications
and
that's
an
out-of-band
mechanism
and
it's
covered
in
the
vp
SEC
security.
H
Consideration
document
and
policy
cannot
document
security,
considerations,
section
and
policy
consideration.
Section
we've
started
looking
through
what
that
could
look
like.
It
is
largely
informed
by
the
ion
implementation,
which
is
thought
through
some
of
this,
in
what
they
call
the
ion
second
min
tool
and
and
the
processing
rules.
The
security
processing
rules
in
in
looking
at
this
we've
defined
three
different
roles
that
a
BPA
from
a
protocol
agent
may
have
a
bundle.
H
Protocol
agent
could,
in
some
cases,
act
as
a
security
source,
which
is
an
agent
that
adds
security
blocks
into
a
bundle,
either
a
bundle.
It
is
creating
or
a
bundle
that
it
is
modifying
before
retransmitting
or
forwarding
a
security
way
point,
which
is
cases
where
a
bundle
agent
would
verify
a
security
service
like
integrity
before
forwarding
a
bundle,
and
the
last
is
when
the
bundle
agent
is
itself
the
destination
of
a
security
service.
H
A
H
H
The
the
use
of
the
term
source
Waypoint
and
destination
and
the
connotation
of
those
terms
with
routing-
and
there
is
no
expectation
that
there
is
any
routing
or
path
computation
for
expectation
with
that
when
we
say
security,
source
security,
Waypoint
and
security
destination,
we
we
mean
literally
the
source,
the
Eid,
that
is
the
source
of
a
security
block.
The
Eid
that
is
processing
a
security
block
that
is
not
the
destination,
should
be
the
end.
H
Receiver
of
that
and
a
security
destination
is
not
the
bundle
destination
and
is
not
a
part
of
a
path
and
a
route.
A
security
destination
is
a
BPA
that
say:
I
am
the
end
consumer
of
that
security.
Block
I
will
process
it,
remove
it
from
the
bundle
and
then
separately,
perhaps
deliver
that
bundle
or
forward
to
someone
else.
Okay,.
B
H
B
H
H
E
H
Is
no
expectation
associated
with
routing
when
you
add
a
security
service
into
a
bundle,
for
example,
if
you
say
I
am
going
to
encrypt
a
target
block
there
is.
There
is
not
necessarily
anything
in
that
block
that
says
only
some
future
other
block
in
the
or
other
node
in
the
network
can
decrypt
this.
You,
you
encrypt
the
block
and
you
send
it
along
its
way.
What
who
decrypts
it
later
is
a
function
of
this
kind
of
policy
implementation
that
is
out-of-band
with
BP
sack.
H
If
you
are
the
bundle
destination
and
you
receive
an
encrypted
block,
you
will
try
and
decrypt
it.
You
may
not
succeed.
You
may
not
have
the
security
context,
you
may
not
have
the
cryptographic
material
to
do
the
decryption
and
you
may
wind
up
at
the
bundled
destination
receiving
an
encrypted
block
that
you
don't
know
how
to
process
now
that,
but
that
is
a
network
configuration
error,
not
an
issue
per
se
with
the
security
specification
I.
B
B
H
Being
the
the
I
agree
and
I'm
open
to
other
terms,
the
the
the
insight
into
this
is
the
originator
of
the
bundle
does
not
determine
who
the
destination
is.
It
is
incumbent
upon
the
receiver
of
the
bundle
to
self
identify
as
the
destination,
and
and
from
that
perspective
there
is.
There
is
not
intent
from
the
sender
side,
it
is
a
self
identification
on
the
receiver
side,
but.
B
D
H
H
So,
as
we
have
laid
out
the
roles,
we
would
say
that
verification,
but
not
changing,
would
be,
would
be
the
role
of
the
Waypoint
and
that,
if
you
were
to
re-encrypt
re-encrypt
to
me,
means
decrypt
from
in
existing
and
then
re
encrypt
with
a
different
security
context,
in
which
case
that
node
would
not
no
longer
be
a
waypoint.
It
would
be
both
a
security
accept
or
and
a
security
source.
D
A
E
H
The
internet
drafts
when
we
talk
about
these
different
roles
and
we'll
keep
security
source.
What
would
they
look
like,
and
so
part
of
this
process
is
to
put
together
the
at
least
the
data
model
or
the
language
associated
with
how
these
rules
would
be
specified
and
for
security
source?
There
are
two
pieces
to
it.
One
is:
how
do
you
identify
that
a
security
service
is
necessary,
and
then
how
do
you
represent?
Which
security
service
that
actually
is
borrowing
from
ion?
H
We
don't
call
out,
in
particular
integrity
versus
confidentiality,
because
that's
captured
in
the
security
context,
ID
and
then
the
security
source
would
be
which
EW
you
want
to
represent.
This
BPA,
as
we
know
with
with
BP
a
particular
physical
node,
can
have
multiple
a
IDs
registered
with
it,
and
so
you
would,
you
would
perhaps
want
to
configure,
when
you
add
a
security
block
into
the
bundle,
and
you
want
to
represent
that
security
source,
a
ID
in
the
security
block.
H
Then,
if
you
are
either
a
security,
verifier
or
security
except
door,
then
you
would
have
a
slightly
different
that
rolls
off
the
tongue.
Thank
you.
You
would
have
a
different
set
of
information.
The
identification
would
still
be
the
same
if
you
are
receiving
a
bundle
from
this
source
bundle
source
to
this
bundle
destination,
and
it
has
this
block
type
in
it.
H
Obviously,
if
you
were
in
networks
or
cases
where
you
can't
make
that
assumption,
you
can
find
ways
of
putting
that
data
into
the
security
block
itself
and
then.
Lastly,
regarding
on
whether
you
are
a
verifier
or
an
acceptor,
you
would
say
what
are
the
processing
actions
that
I
might
want
to
take
based
on
how
the
verification
or
the
acceptance
of
that
security
source
would
go,
and
this
would
give
you
fine-grained
control
by
block
type
and
by
security
context
of
how
you
handle
certain
behaviors.
H
A
A
H
So
the
point
is
I'm
not
saying
these
are
the
correct
action
points,
but
the
idea
is
that
from
a
formatting
perspective,
this
is
likely
the
set
of
information,
and
then
you
could
see
a
series
of
rules
or
rows
in
a
database
that
you
could
walk
through,
saying,
I've,
gotten
a
bundle
in
it's
from
this
source
to
this
destination
within
wildcards,
like
I,
got
a
bundle
from
IP
n
1
dot,
something
it's
going
somewhere.
It
has
a
payload
in
it.
I
should
expect
that
this
would
have
a
security
block
over
that
payload
using
ID
7.
H
A
Rick
with
my
chair
hat
on
yes,
I
can
see
there's
two
parts
to
this
yeah.
It's
a
there's,
a
lot
of
implementation,
detail
here,
but
I
evaluate
for
that
implementation
to
ensure
that
we've
covered
all
the
corner
cases
in
BP.
Second,
we've
got
the
the
power
to
do
this
sort
of
thing,
so
I,
obviously
I
really
like
the
work.
I
think
it's
really
clever,
but
yeah.
It's
it's
filtering
access,
control,
list,
stuff
and
it's
a
good
demonstration
of
what
we
can
do
with
with
BP
sake.
H
A
B
Sure,
and
really
all
I
would
want
to
do-
is
encourage
people
to
to
take
a
look
at
the
latest
internet
draft
for
bundled
model.
Encapsulation
I'll
probably
be
posting
another
one,
because
the
window
is
closed
right
now,
but
as
soon
as
the
window
reopens
I've
got
another
draft
ready
to
post
the
the
reason,
bundle,
bundle,
encapsulation
I,
think
is
important
for
a
couple
of
reasons.
One
is
there
are
some
security
features
that
you
can
get
from
bundle
and
bundle
encapsulation
that
are
difficult
to
get
any
other
ways,
such
as
protection
from
traffic
analysis.
B
Another,
though,
is
that
the
bundle
bundle
encapsulation
specification
includes
the
custody
transfer
mechanism
that
was
in
RFC
5050
and
actually
extends
and
updates
that
to
to
implement
a
an
aggregate
custody.
Signaling
system
that
has
been
in
ion
for
several
years,
developed
by
guys
at
University
of
Colorado,
to
bring
the
overhead
of
custody
transfer
down.
I
think
that's
a
a
useful
mechanism
and
I.
B
A
Thanks
thanks,
so
we
have
20
minutes
left
of
the
session
and,
following
on
from
the
is
that
full
screen
following
on
from
the
interim,
the
list
of
proposed
new
charter
items,
as
was
circulated
on
the
mailing
list,
is
this
so
Magnus
at
the
time
raised
concern
that
this
is
a
very
long
list
and
I
know
there
are
drafts,
so
you
can
see
that
there's,
March
or
D
have
an
active.
A
recent
draft
and
those
parts
with
an
X
have
a
draft
from
the
IRT
FD
Tian
research
group.
A
So
some
of
this
stuff
does
have
some
documentation
already.
But
the
critical
question
is
before
we
update
the
Charter
for
the
working
group,
so
DTN
working
group
phase
two.
We
need
to
make
sure
that
the
items
that
go
on
the
Charter
are
achievable,
so
I'm
looking
at
the
people
in
the
room
here,
only
our
ad
is
on
meet
EKKO
but
I'm
assuming
or
hoping
there
are
a
couple
of
other
people
on
Jabba
and
there
are
other
people
who
are
willing
to
step
in
and
help
put
some
of
this
together.
A
H
A
So
Rick
speaking
personally
I,
the
top
half
of
that
list,
so
bundle
protocol
additional
blocks,
that's
bundle
and
bundle
is
working.
Progress
manifests
block,
I,
know
that
Scott
and
Ed
are
both
very
keen
to
see
that
work
being
done.
As
ed
said,
asynchronous
management
is
very
much
underway.
The
bottom
half
of
this
list
is
actually
something
I
think
is
as
important,
but
has
less
interest
or
less
input
from
from
the
regulars
so
to
speak.
A
So
neighbor
discovery
outside
of
very
fixed
deterministic
delay,
tolerant
networks,
some
sort
of
neighbor
discovery
starts
to
be
relevant
when
you're,
looking
at
ad
hoc
style,
DT
ends,
which
is
obviously
for
non-space
communities,
main
driver
for
DT
ends.
You've
got
to
be
able
to
discover
potential
forwarding
opportunities
potential
adjacencies.
How
is
this
done
at
the
bundle
processing
where
we
know
how
to
do
this
with
link
technologies?
But
how
do
we
bridge
that
link
to
bundle
protocol
gap
and
there's
lots
of
room
for
ideas.
A
Experimentation
suggestions
and
all
welcome
also
naming
an
addressing
that's
people
outside
of
this
room,
assume
that
there's
a
naming
scheme
there
is,
but
it's
fairly
simple,
I'm
trying
not
to
be
rude
about
it,
but
it's
it's
it's.
It
works
for
small
systems.
If
we
want
to
try
do
we
want
to
try
and
build
a
global
heterogeneous
DTN
network,
because
if
we
do,
we
need
a
proper
global
addressing
we
need
to
solve
the
global,
addressing
problem.
Let
me
put
it
that
way,
so
that
might
pique
some
people's
interest.
A
Marble
SAE
is
very
keen
on
a
registry
of
service
identifier,
I'm,
really
hoping
he
drives
that
work
personally.
I
have
a
partially
written
HTTP,
CL
I,
just
don't
have
the
time
to
finish
it.
I'm
looking
for
co-authors
I'm.
Looking
for
anyone
to
just
help
me
get
the
words
out.
I
have
an
SMTP
implementation,
it's
partially
broken.
It
would
be
nice
to
write
up
what
I'm
doing
it's,
not
brilliant
I
need
help
or
I'm
happy
to
just
give
it
to
somebody
else
to
work
on
this.
It's
about
collaboration
and
we
need
input.
Okay,
that's
me.
B
Scarper
Lee
I'm,
of
course,
very
committed
to
doing
bundle,
bundle,
encapsulation,
I'm,
certainly
interested
in
the
naming
and
addressing
I,
definitely
want
to
be
part
of
that
conversation.
Neighbor
discovery,
there's
a
informational,
experimental
RFC
that
is
implemented
and
and
works.
I
think
it's
a
good
prototype
for
us
to
be
working
from
in
ion.
A
So
go
ahead,
stir
if
you
so
one
of
the
questions
put
to
us
by
our
ad
was
given
the
amount
of
effort
involved
in
the
size
of
this
list.
What
what
does
the
working
group
want
to
prioritize?
We
have
to
put
up.
We
have
to
prioritize
these
things.
So
does
anyone
have
any
strong
opinions
about
which
are
the
key
next
pieces
to
do
still.
D
Carry
here,
I
guess
I
will
speak
before
prioritizing
because
I
get
more
things
to
prioritize,
so
the
whole
naming
an
addressing
area.
That's
an
area
in
which,
within
my
severe
bandwidth
constraints,
I,
would
be
interested
in
contributing
we've
had
some
thoughts
at
our
shop
about
mapping
between
DTN,
endpoint,
IDs
and
other
identifiers
spaces
you
will
probably
grown
would
not
be
surprised
when
I
mention
host
identities
and
those
of
you
who
are
familiar
with
high-frequency
radio
communications
and
the
AL
e
standard
automatic
link
establishment
as
al
identifiers,
which
I
think
are
sometimes
relevant
here.
D
Another
area
where
again
within
limited
bandwidth
I,
would
be
interested
in
working
on
the
norm:
convergence
layer
when
it
comes
to
SMTP
there's
some
work
that
our
shop
did
way
back
in
2001,
where
because
the
bundle
protocol
didn't
exist,
yet
we
gave
a
different
answer
to
the
question
of.
Is
this
just
SMTP?
In
our
case
the
answer
was
yes
and
we
bundled
all
sorts
of
things
inside
of
SMTP
and
I
think
it
would
be
great
to
be
able
to
put
a
real
bundle
now
that
we
have
a
bundle
protocol
inside
SMTP
and
vice
versa.
D
Sometimes
you
want
to
transport
a
bundle
across
SMTP.
Sometimes
you
want
to
transport
SMTP
across
a
DTN
with
model
protocol.
The
folks
over
in
the
network
coding,
Research
Group,
are
interested
in
supporting
DTN
with
network
coding.
They
are
pretty
bandwidth
limited
as
well,
and
finally,
I
think
the
the
ICN
application
somewhere
should
be
on
this
radar
and
and
the
the
profit
draft.
The
profit
extension
draft
I
think
is
pretty
neat,
so
I'm
just
throwing
more
things
on
the
list
before
we
start
ranking
them.
So.
A
A
Occasionally
we
get
drafts
coming
in
from
far
eastern
universities
and
academic
institutions
talking
about
DTN
work,
talking
about
crossovers
with
ICN,
and
it's
interesting,
interesting
things
and
there's
not
a
lot
of
communication
with
the
working
group.
They
just
submit
a
personal
draft
and
that's
the
last
we
hear
I
would
really
like
these
people
to
come
and
talk
to
us
just
put
up
put
a
message
on
the
mailing
list
to
say:
hi
I
have
submitted
this
individual
draft
because
there
is
a
lot
of
interest
with
people
who
read
these.
A
We
read
these
things
and
say:
hey,
that's
really
good.
Let's
move
it
on
I
are
the
authors
of
this
these
drafts?
Do
they
want
them
to
become
working
group
documents
to
do
they?
My
question,
I
suppose
is:
is
this
a
way
of
publishing
a
paper
to
achieve
part
of
their
degree,
which
is
not
quite
what
it's
for,
but
that's,
okay,
but
the
work
is
good
and
when
the
work
is
good,
let's
work
on
it
in
the
working
group
and
and
let's
go
make
this
a
standard.
A
J
And
I'm
Whittaker
critical
technologies
I
want
to
just
dovetail
on
that
point.
Maybe
at
some
point
somebody
I'm,
not
volunteering
myself,
but
reach
back
out
on
some
of
those
drafts
that
were
really
highlights.
They
we
saw
reach
back
and
say:
hey
we've
been
looking
back
through.
This
was
really
interesting.
J
Is
there
anything
else
going
on
because
then
maybe
they
continued
working
on
it
just
to
put
up
into
Stu's
point
I
generally
try
to
relieve
the
stress
and
take
load
off
of
him
for
his
work,
so
we're
both
constrained
and
I
share
a
lot
of
what
he's
interested
in
as
well,
but
I'm
also
interested
in
just
reviewing.
If
you
have
something
throw
me
an
email,
I'll
review
it
I'll
read
it
I'll,
try
to
give
you
some
sort
of
feedback,
so
the
best
place
to
review.
A
A
Okay,
Rick
speaking
personally,
I
agree
with
you,
Stu
I,
think
naming
and
addressing
is
the
elephant
in
the
room,
as
they
say
it's
the
one
thing
we
all
pretend
works,
but
when
you
start
to
look
at
it,
it's
not
actually
there
yet
I
will
also
add
ie.
We
have
some
of
the
asynchronous
management
is
already
on
the
Charter
as
an
architecture.
I
know
that
ed
and
his
team
are
working
hard
on
this
and
doing
good
work
and
I.
Think
it's
really
important.
So
my
plus
one
is
for
the
asynchronous
management
so.