►
From YouTube: IETF108 DTN 20200727 1100
Description
DTN session at IETF108
2020/07/27 1100
A
A
A
D
A
A
A
A
Oh
no,
I'm
being
an
idiot,
I
need
to
actually
use
the
screen.
I'm
sharing.
Okay,
so
hello,
everybody
welcome
to
ietf
108
virtual
dtn
session,
so
I'll
just
kick
off
with
the
agenda.
This
is
just
some
links
to
what
we've
got
for
today's
meeting,
so
the
agenda
url
is
there
also
I've
included
the
participation
guide
for
those
who
are
struggling
with
meet
echo,
how
to
contribute,
etc,
etc.
A
There
is
a
reporting
issues
page,
and
hopefully
you
can
follow
that
link
and
someone
can
assist
you.
Meanwhile.
I
wish
this
would
actually
go
in
pages.
Here
is
the
note
well,
as
ever,
I'm
assuming
that
has
come
through
in
the
meat
echo?
Yes,
it
has
good
sorry
I'm
having
to
switch
between
tabs
as
I
work
out
what
I'm
doing.
A
This
has
not
changed
to
the
best
of
my
knowledge,
but
in
case
it
has,
I
do
suggest
you
read
it
it's
the
standard.
Itf
note
well,
the
short
executive
summary
is
this
is
a
public
meeting.
Anything
you
say
is
assumed
to
be
released
as
into
the
public,
so
be
very
careful.
If
you
are
discussing
ipr
that
you
wish
to
reserve,
I
don't
speak
because
you
are
disclosing
it.
A
A
A
So
we
are
all
as
a
working
group
waiting
for
resolution
to
the
discuss
raised
by
a
couple
of
the
iasg
reviewers,
in
particular
benjamin
kaduk.
If
I've
pronounced
that
correctly-
and
I
know
the
authors
have
actually
worked
hard
to
try
and
address
a
lot
of
these
discusses,
there
have
been
up
reps
to
the
documents
and
one
thing
in
the
discussion
between
the
chairs
and
the
ad
was
given.
There
have
been
some
changes
that
may
or
may
not
be.
A
You
know
reasonably
impactful
to
the
document.
We
felt
it
was
relevant
to
gets
a
statement
from
each
of
the
primary
authors
of
each
of
these
documents.
Just
to
say
this
is
how
we've
addressed
the
discusses,
and
this
was
the
change
we
made
just
to
make
sure
that
we
have
working
group
consensus
on
the
changes.
A
A
But
really
this
is
a
case
for
the
working
group
just
to
check
that
they
are
happy
with
the
changes
that
the
authors
are
making
to
these
documents.
In
order
to
address
the
discusses
on
the
counter
side
of
that,
I
think
with
my
chair
hat
on,
I
need
to
poke
rad
magnus
and
say
I
know
you're
pursuing
the
iesg
reviewers
to
try
and
get
them
to
clear
their
discusses
or
do
another
pass.
Can
you
please
put
more
pressure
on
them?
We
need
to
get
some
of
these
addressed
they've
been
open
since
february.
A
B
A
I
think
it
may
be
ben
as
well,
but
yeah,
it's
just
a
polite
request
and
we'll
pursue
this
after
itf-108
when
everyone,
hopefully
is
full
of
excitement
about
getting
all
the
ietf
stuff
they've
committed
to
doing
this
week
done
so
we
can
poke
benjamin
at
that
point
and
say
come
on
clear
it
address
it,
raise
some
more
comments
or
whatever
so
going
back
to
the
agenda.
Second
part
is
a
little
bit
of
new
business.
So
actually
do
I
haven't
just
written
these
slides.
A
A
A
A
Can
somebody
or
many
people,
and
why
is
it
saying,
offline
dtn?
Sorry,
I'm
staring
at
what
I'm
trying
to
do.
Can
somebody
please
have
a
go
at
trying
to
get
some
minutes
taken,
because
I
we
need
a
minute
taker,
so
volunteer,
please
or
just
open
the
kodi,
md
and
start
typing
and
final
point
is:
when
speaking,
can
you
please
remember
to
state
your
name
just
as
an
in-person
meeting,
because
there
is
an
audio
only
recording
being
made
of
this
and
not
everyone
is
familiar
with
everybody's
voice?
A
A
So,
as
I
said
before,
we're
the
original
three
documents
are
under
iesg
review,
we're
waiting
for
feedback
from
the
reviewers,
and
we
need
to
make
sure
there's
working
group
consensus
on
the
changes
and
the
following
point
from
that
is
the
bpsec
interrupt.
Interrupt
document
is
still
in
working
group.
Last
call
now
that's
partially
the
chair's
fault
for
not
either
resolving
the
working
group
last
call
consensus
or
not
clicking
the
button,
but
I
also
have
a
reservation
that
I
know
bp.
A
Sec
had
several
discusses
raised
against
it
about
interoperability,
and
I
just
want
to
make
sure
that
the
interoperability
document
hasn't
been
changed
or
doesn't
need
to
change
in
order
to
resolve
the
bp
sec.
Iesg
discusses,
I'm
sure
ed
bahrain
has
the
answer
to
that
and
if
the
answer,
depending
on
the
answer,
we'll
get
that
last
call
sorted
that
should
that
document
should
be
ready
as
far
as
I'm
aware-
and
it
may
simply
be
a
failing
of
the
chairs
to
have
pressed
the
correct
button.
A
C
Oh
okay,
so
ed
brain
apl.
I
have
a
slide
in
my
presentation
that
talks
about
the
interoperability
suites
and
we
did
do
an
update
to
it,
based
on
the
comments
coming
out
of
the
isg
review
and
we
think
that
it
matches
what
the
isg
review
was
asking
for.
But
we
would
like
the
working
group
to
take
a
look
at
it.
One
more
time.
A
A
A
A
This
is
designed
to
and
I'll
let
him
speak
in
more
depth,
but,
as
I
understand
it,
this
is
his
proposal
for
a
bit
of
boilerplate
to
ensure
that
further
security
context
documents
actually
do
capture
all
the
bits
and
pieces
that
bpsec
requires.
Following
on
from
that,
brian
sipos
has
got
a
cozy
security
context.
He
wishes
to
discuss,
which
sounds
great,
so
that
is
the
cozy
for
those
not
in
the
loop
is
the
seabor
security,
encapsulation
recommendations
and
I'm
sure
brian
will
get
into
more
detail
and
also
and
I'll.
A
Let
him
cover
what
the
the
I'm
not
100
sure
what
acme
stands
for,
but
again
brian
is
going
to
talk
about
node
id
validation
to
do
with.
I
think
it's
tns
and
x509,
but
I
wish
to
be
corrected
and
as
a
follow-on
piece
brian
also
has
some
has
a
proposal
to
do
with
dtn
neighbor
discovery,
so
that's
being
slotted
in
at
the
end
of
the
agenda
as
usual.
A
The
new
stuff
is
useful
and
I've
sort
of
prioritized
them
if
we
run
out
of
time
to
the
neighbor
discovery
proposal,
I'm
very
sorry,
brian
we'll
have
to
move
it
forwards,
but
I
think
we
have
time
for
it
and
we're
going
to
try
and
leave
some
time
at
the
end
for
an
open
mic.
If
anyone
else
wants
to
raise
anything
else,
so
I
realize
I've
been
waffling
for
a
bit.
Does
anyone
wish
to
bash
that
agenda?
A
A
D
E
D
D
D
D
A
B
D
D
I've
got,
I
think,
11
slides
here.
The
summary
is
this:
that
the
bps
specification
has
been
reviews
reviewed,
there's
been
a
lot
of
email
exchange
with
the
area
directors
on
discusses
and
comments.
There's
a
draft
that
was
posted
a
few
months
ago
draft
run
five
that
I
think,
reflects
the
points
of
agreement.
D
D
There
are
several
slides
several
issues
remaining
that
I
think
require
consensus
decision
by
the
d10
working
group.
I
think
all
of
the
other
issues
have
been
discussed
on
the
mailing
list
and
I
don't
propose
to
review
all
of
them
because
they,
they
all
seemed
to
me
to
be
things
that
were
that
did
not
require
working
group
revision.
They
were
editorial
in
nature.
The
ones
that
I
think
are
technical
in
nature
are
these,
and
so
we
can
review
them
and
if
we
can
reach
consensus
in
real
time,
that's
great.
D
The
first
one
is
the
one
that
magnus
commented
on
kind
of
extensively
in
one
of
the
recent
emails,
which
is
about
the
registration
policy
for
the
bundle
and
block
processing
control
flags,
whether
that
the
registration
policy
should
be
standards,
action
or
or
was
it,
be
changed
back
to
being
standards,
action
or
not?
The
blue
text
here
this
is
the
convention.
I'm
following
in
these
slides.
D
A
So
my
thought
is
that
I'd
like
a
very
if
somebody
wants
to
get
to
the
mic
line
now
and
make
a
comment,
I
would
be
very
happy
to
hear
it.
I
have
a
mild
concern
that
the
working
group
list
is
quiet
and
that
the
clock
is
ticking
and
we're
taking
a
lot
of
time
to
reach
some
consensus.
So
I'm
much,
I
think
we
have
the
active
participants
here
now.
Well
done
everyone
who's
in
horrible
time
zones
for
this
meeting,
and
I'm
I'm
really
interested
if
anyone
has
a
strong
opinion.
A
D
A
A
We
had
a
long
email
conversation
on
the
mailing
list
where
the
irtf,
I
can't
remember
his
exact
position,
but
then
he
was
the
irtf
ad
equivalent
was
quite
happy
to
yield
control
of
the
iona
registration
for
specification
required.
So
I
I
don't
think
this
is
a
an
issue
and
I
I
think
we
should
take
this
one
to
the
list
just
and
say
I'll,
make
a
note
to
ask
on
the
list
that
I
point
to,
I
think,
is
where
we
were
with
consensus.
Does
anyone
have
any
objection
on
this?
D
Okay,
it's
good
yeah.
This
is
a
discuss
from
alex's
review
and
this
is,
I
don't
have
any
response
here.
This
is
just
a
is
the
tcp
convergence
layer
protocol,
tcpcl
version
4
mandatory
to
implement
for
vbp
node
and,
of
course
we
can
say
it's
mandatory
to
implement
in
the
specification
that
in
itself
doesn't
cause
anything
to
happen,
but
we
can
say
that
it's
that
it's
required
and
make
sure
that
people
know
about
it.
D
I
I
think,
that's
a
valid
argument,
particularly
if
you're
running
bp
over
the
internet,
if
you're
not
running
vp
over
the
internet
and
in
fact
you
will
not
be
running
over
the
internet
much
of
the
time,
because
it's
running
on
space
protocols,
then
then
it
seems
a
little
draconian
to
require
the
tcp
convergence
layer
protocol
be
a
part
of
the
implementation
of
a
bp
node.
That
is
that,
is,
you
know,
running
on
a
spacecraft
on
its
way
to
jupiter.
D
B
Yeah,
yes,
I
think
it's,
you
can
definitely
preface
it
with
saying
it's
must
if
it's
on
a
internet
protocol
or
something
like
that,
that's
either
of
the
versions
and
and
make
that
thing
that
at
least
have
a
starting
point
for
controlled
convergence
layer.
But
that's,
I
think,
that's
nothing
stronger
than
that
then,
and
I
mean
alex
this-
is
that's
just
not
binding.
I
think
he
was.
B
D
A
A
G
D
I,
I
think,
that's
an
excellent
point.
I
think
here
the
the
I
think
the
the
objection
that
would
be
raised
would
be
okay
in
that
case,
what
do
you
do
to
to
initiate
retransmission
of
lost
data,
and
I
I
think
the
answer
is
that
we
do
that
with
various
convergence
layer
mechanisms
and-
and
one
of
those
that
that
has
that
will
be
standardized
is
tcp
but
others
are
possible,
and
I
think
that
would
be
a
good
resolution
to
this,
but
I
leave
it
to
the
working
group.
B
Well,
I
was
just
we're
gonna
say
that
I
mean,
I
think,
reasonable
text
for
scoping
the
interoperability
requirement,
and
I
think
that's
I
mean
we
know
that
tsb,
conversely,
is
both
the
blueprint
and,
in
certain
cases
it's
a
very
good
fallback
basics
for
as
long
as
you
can
fulfill
it,
and
that
sounds
like
what
you're
going
here
with.
So
I'm
happy.
D
A
D
D
That
seems
to
be
a
possibly
damaging
bundle
and
do
it
in
a
way
that
is
conforming
to
the
rest
of
the
specification
and
what
that
would
be
is
overriding
the
bundle
lifetime
so
that
the
bundle
simply
expires
and
goes
away
in
the
in
the
normal
and
well-documented
fashion.
That
seems
to
me
to
be
a
a
relatively
unobtrusive
and
straightforward
way
to
deal
with
bundles
that
that
need
to
be
removed
from
the
system.
D
For
a
number
of
reasons,
one
would
be
it's
that
there's
a
storm
of
status
reports.
Another
would
be
that
the
node
that
has
the
bundle
simply
is
running
out
of
buffer
space
and
needs
to
do
some
triage
to
get
rid
of
bundles
that
already
exist
and
can't
do
it,
because
the
bundle
lifetimes
are
too
long.
I
I
I
think
it's
of
course,
like
anything
else,
it's
it's!
D
It's
power
that
would
need
to
be
used
judiciously,
but
I
I
think,
providing
that
the
authorization
to
to
wield
that
sort
of
power
in
a
node
doing
so
formally
is
is
better
than
letting
people
make
that
sort
of
thing
up
on
their
own
surreptitiously.
So
I'm
I
I
like
this
way
of
going
forward.
I
think
we
it's
it's
it's
a
significant
technical
thing
that
requires
the
agreement
of
the
working
group.
I
think.
D
And
that's
that's
why
I
say
in
the
text
here
I
say
override
and
it's
better
a
better
way
of
saying
it
than
revised.
I
definitely
would
not
propose
to
change
the
lifetime
in
the
bundle
in
the
primary
block.
I
would
okay,
I
would
propose
only
to
say
that.
Oh
I
I
know
that
the
request
about
the
lifetime
is
so-and-so,
but,
as
I
process
it
here
on
my
node,
that
lifetime
is
going
to
be
this
okay,
yeah.
A
C
D
D
Bundle
of
I
don't
know
excise
or
something
it's
bundle
surplus.
Something
like
that.
I
can't
remember
what
the
text
is:
okay,
but
actually,
but
let
me
restate,
though,
if
we
did
it
this
way,
the
reason
for
deletion
of
the
bundle
would
be
lifetime
expired,
which
is
already
documented,
and
that
in
fact
might
make
that
that
additional
contraindication
reason
code
unnecessary.
A
D
One,
the
bpsec
extensions
we
we,
this
is
benjamin's,
discuss,
we've
been
over
a
couple
of
times.
Under
what
circumstances
is
bp
sec,
mandatory,
implement
and
magnus
had
an
assessment
for
this
one
saying
that
the
perfect
protective
profile
protection
profile
needs
to
be
normative
reference,
and
we
also
don't
have
automatic
key
exchange.
F
A
I
believe,
as
on
the
second
point,
from
magnus's
assessment
again
with
my
chair
hat
on,
I
don't
believe
automatic
end-to-end
key
exchange
fits
with
the
model
of
dtn.
I
think
we're
happy
to
put
it
on
the
working
group's
to-do
list.
It
might
require
recharging
and
that's
a
discussion
between
the
chairs
and
the
ad
etc,
longer
term
so
and
given
we
did
the
early
sec
ad,
the
early
sec
review
and
they
were
happy
with
it
at
the
time.
I
don't
think
we
should
open
the
can
of
worms
about
automatic
key
exchange.
D
A
B
Yes,
no,
but
it's
I
I
mean
my
assessment
here
is
only
saying
that
this
is.
There
is
an
rfc
in
igf
that
says
that
for
modern
new
security
solutions,
etc,
automatic
heat
change
is
required,
and
I'm
just
saying
that
to
my
understanding,
the
securities
is
not
going
to
be
stick
on
that
requirement
towards
you
at
this
point
in
time
and
and
that
with
expectation
that
the
working
group
will
eventually
get
around
to
providing
a
solution
for
this
in
the
future.
A
Absolutely
and
yeah,
I
I
take
your
point
and
I
would
I
would
like
to
suggest
back
to
you
and
also
to
the
sec
guys
that
this
is
a
tough
problem
in
dtn
and
we
can't
just
say
I'll.
Just
do
a
key
exchange
it'll
be
fine,
because
we
don't
actually
know
how
to
move
the
keys.
We
have
some
interesting
work,
but
we'd
like
to
do
it
properly.
That's
anyway.
Let's
move
on.
D
Okay,
next,
this
is
a
discuss
two
from
benjamin.
How
do
we
tell
whether
an
endpoint
is
singleton
or
not?
In
the
ipm
scheme,
we've
revised
the
definition
of
the
ipn
scheme
to
say
that
all
the
ipn
scheme
endpoints
are
singleton.
We
have
don't
say
that
about
the
d10
scheme.
Endpoints,
do
we
need
some
definition
of
the
syntax
and
semantics
of
the
dtn
scheme?
That
indicates
whether
or
not
the
an
endpoint
is
a
singleton.
A
A
Yes,
I'm
happy
for
you
to
do
that.
Can
you
raise
it
as
a
when
you
have
put
some
proposed
text
together?
Can
I
ask
you
raise
that
as
a
as
a
question
on
the
list
to
say
this
bit
of
text
specifically,
I
have
put
in
because
I
think
it
addresses
this
just
to
kick
off
that
discussion.
To
give
us
a
focused
thread
for
that
discussion
is
that
okay,
scott
yep.
D
Okay,
number:
six:
this
should
be
easy.
Can
we
right
now
the
the
spec
says
there
are
up
to
256
scheme
types
that
are
for
which
we
have
codes
for
for
bp?
Is
there
any
reason
to
limit
that,
and
I
think
the
answer
is
no
real
good
reason
to
limit
it,
and-
and
we
can
just
say
that
everything
above
255
is-
is
open
for
private
usage
as
magnus.
A
A
Uri
uri
scheme
codes
that
proliferate
and
become
de
facto
standards,
just
because
a
major
manufacturer
has
started
shipping,
their
own
special
scheme
and
it
never
gets
standardized
within
the
itf.
So
my
argument
would
be
is
if
you
could
force
the
numbers
to
start
at
three
biting
coding
in
cbor,
so
there
is
actually
a
penalty
for
using
the
private
experimental
space
and
that
we
sort
of
nudge
people
towards
saying
hey,
bring
it
to
the
ietf.
Get
it
standardized,
get
it
peer
reviewed
would
be
better.
That
would
be
my
suggestion.
A
D
So
we
just
keep
that
in
the
note
and
I'll
I'll
mark
that
into
the
spec
and
see
if
there's
any
objection.
That
sounds
great.
Let's
go
forward,
okay,
we're
close
to
the
end.
The
last
two
are
just
comments
that
we're
not
discussing.
One
of
benjamin's
comments
was:
what's
the
the
the?
Why
is
bundle
age
in
microseconds
when,
when
bundled
lifetime
is
in
seconds,
they
should
be
in
the
same
denomination?
D
I
think
that's
right
and
in
fact
I've
had
people
in
nasa
say:
oh,
you
know
for
some
tracing
we're
like
we're
doing.
We
would
like
the
the
time
tags
for
status
reports
to
be
in
milliseconds,
so
I
I
my
preference,
I
guess
would
be
that
all
of
these
time,
magnitudes
be
expressed
in
the
same
units
seconds
milliseconds,
microseconds
nanoseconds,
my
preference
is
for
seconds
actually,
but
I
think
milliseconds
is
is
not
too
bad.
D
H
H
A
G
E
A
Thanks
brian
I'm
rick
speaking
personally,
I'm
for
seconds
as
well.
If
you
want
to
do
timing
of
the
processing
of
the
pipeline
within
your
bundle
processing
agent
itself,
that's
fine
go!
Do
nanosecond
timing,
that's
fine!
But
yeah!
I'm
I'm
in
a
rough
agreement
with
everyone
else.
It's
seconds
we're
delay,
tolerant
if
you're
in
milliseconds
micros,
if
you're
in
microseconds,
you
may
as
well
push
ip
packets.
D
A
So
ronald,
are
you
suggesting
that
in
a
disrupted
network,
when
you
have
connectivity,
it
can
be
very
fast
and
therefore
a
higher
resolution
timer
is
useful
or
that
that's
correct.
That
makes
sense.
So
you
is
this
a
counter
proposal,
or
should
we,
if
ronald,
doesn't
jump
to
the
mic
there
we
go
go
ahead,
run.
F
A
D
Okay,
what
what
I,
what
I
will
do
is
in
the
next
edition.
I
will
make
all
of
the
denominations
the
same.
I
will
I
will
guess
tentatively
that
we're
going
to
end
up
with
everything
being
in
milliseconds,
because
I
think
that
there
is
some
some
value
in
being
able
to
attract
that
level
of
of
precision,
and
we
can
go
back
to
seconds
if,
if
there's
consensus,
to
do
that.
A
D
Okay,
sure
thanks
absolutely
last
one
are:
are
the
previous
node
bundle
age
and
hop
count
extensions
mandatory
to
implement
at
the
moment
I
think
they're?
We
don't
say
that
that
support
these
is
mandatory
in
any
protocol
agent,
but
but
benjamin's
perception
is
that
they
feel
like
key
components
of
the
protocol.
D
B
D
B
A
F
A
D
B
A
Okay
noted
I
I
think
that
might
be
an
action
for
the
chairs
as
well
to
I'll
put
something
in
my
calendar
so
once
a
week
I'll,
send
him
an
email
to
say
how
are
you
doing
anyway?
Jumping
back
to
me,
I
will
grab
the
screen.
I
want
to
share
my
screen
back
to
the
agenda.
So
next
up.
Can
you
see
that
I
know
because
I'm
not
sharing
it,
how
do
I
sh
share?
A
Yes,
I
wish
to
share
my
screen.
I
seem
to
be
unable
to
share
my
screen
anyway,
doesn't
matter.
Thank
you
very
much,
scott.
I'm
going
to
bin
you
out
from
the
presentation
at
the
moment.
Next
we
have
ed
on
your
bp
sec
updates.
So
ed,
would
you
attempt
to
you
should
be
able
to
take
control?
Does
that
seem
to
be
working
for
you,
ed.
C
Okay,
so
I
will
at
bahrain
apl.
I
wanted
to
give
a
brief
update
on
the
the
current
status
of
bp
sec.
The
summary
link
points
to
where
we
are
in
terms
of
iesg
reviews.
Generally
speaking,
we
had
one.
Yes,
several,
no
objections
and
we
did
have
a
few
discusses.
I
I'm
not
going
to
go
through
each
discuss
and
each
comment
because
I
think,
at
the
end
of
the
day
there
were
something
like
10
or
11,
discusses
and
maybe
80
comments.
C
A
C
C
Many
of
them
are
based
on
the
capabilities
and
the
operating
conditions
of
the
underlying
network.
I
I
don't
think
that
bp
sec
as
a
specification,
should
be
specifying
or
mandating
a
specific
key
management.
Protocol.
Bpsec
is
a
container
for
carrying
cryptographic
material
and
that's
it.
So
I
don't
think
that
there
should
be
any
change
here,
but
I
wanted
to
bring
that
to
the
working
group.
C
I
believe
we
address
that
in
the
comments
which
is
that
it
you
can
run
into
difficulties
associated
with
now
I
have
multiple
signatures
on
a
target
which
one
do
I
believe,
and
that
certainly
pushes
a
complexity
into
individual
nodes
to
say,
if
I
have
many
signatures,
and
is
it
one
that
needs
to
pass,
is
it
three
or
four
it
is?
It
is
complicated
and-
and
we
think
that
the
existing
bibs
and
bcbs
and
bpsec
don't
need
to
be
updated.
For
this
case.
C
I
I
I
do,
and
I
do
in
in
in
two
ways.
Certainly
one
is
to
define
a
security
context
which
allows
multiple
results
that
even
could
be
added
along
the
way
if
that
was
a
desired
behavior,
but
the
other
is
and
there's
another
slide
on
this.
Coming
up
that
you,
you
can
define
additional
security
blocks.
Bpsec
provides
the
the
conditions
under
which
that
is
possible.
The
bib
and
the
bcb
are
really
meant
to
be
a
a
one-to-one
mapping
for
these
individual
cases.
A
Okay,
understood
so
yeah
that
answers
my
question
it's
possible,
but
it
needs
to
exist
externally.
From
I
mean
it
can
it
can
inherit
some
of
the
behaviors
and
commonality
with
with
bpsec
as
it
stands,
and
it's
not
excluded,
but
it
can
be
done
separately.
Okay,
I
I'm
happy
with
that
question
to
the
floor.
A
C
Okay,
the
the
next
question
that
came
up.
This
was
a
comment
as
well
from
the
security
area
director,
which
was:
do
you
consider
a
security
encryption
over
multiple
blocks?
So
would
you
define
an
integrity
block
that
has
a
signal,
a
single
signature
that
is
calculated
over
two
three
or
four
extension
blocks
or
over
the
entire
bundle
itself?
A
Okay,
so
this
is
this
is
in
some
ways
similar,
sorry
rick
again,
some
way
similar
to
the
previous
answer,
which
is,
we
are
bpsec
talks
about
one-to-one
integrity
and
signature
one-to-one
blocks.
It
occurs
to
me
that
the
bundle
and
bundle
encapsulation
is
again
another
way
of
adding
integrity
across
an
entire
payload.
C
I
agreed
and
stuart
just
put
together
or
added
a
a
comment
which
said:
please
make
sure
that
we
do
not
preclude
multiple
signatures
and
just
to
speak
to
that
for
a
moment
on
question
number
three,
the
the
issue
is
right.
Now
the
bp
sec
says
that
the
same
security
operation
cannot
be
done
more
than
once
in
a
bundle.
I
think
that's.
C
The
sticking
point
is
to
not
have
two
three
or
four
bibs
that
are
independent
added
by
different
nodes,
that
target
the
same
security
target,
and-
and
so
you
know
that
right
now
is
not
allowed
in
bpsac,
and
the
question
is:
is
that
something
that
we
do
want
to
allow
in
bpsac?
But
I
can
add
that
when
I
post
the
question
to
the
mailing
list,
I.
A
Suggest
you
take
that
to
the
mailing
list
and
we
can
have
a
deep
discussion
over
impact
on
complexity
of
implementation
as
part
of
there's
always
a
balancing
act
between,
particularly
when
it
comes
to
security
technology,
which
is
hard
to
get
right.
The
balancing
act
between
complexity
of
implementation
and
whether
people
actually
bother
to
do
it
so
features
versus
complexity.
C
I'll
completely
agree,
the
the
fifth
question
is:
where
should
we
put
bundle
protocol
reason
codes?
One
thing
that
came
out
of
our
analysis
was:
if
you
choose
to
remove
a
bundle
from
the
network
based
on
a
security
related
reason,
then
you
may
want
to
add
security
related
reason,
codes
and
a
question
that
came
up
is:
where
is
the
right
place
to
represent
those
security
related
reason
codes?
C
C
It
had
more
security
than
was
expected
or
it
had
a
security
service
that
failed,
such
as
failed
integrity
or
it
had
conflicting
services
where
the
security
blocks
in
a
bundle
violated
bpsac
rules.
Alternatively,
it
could
go
into
a
security
context,
template
that
defines
the
reasons
that
should
be
adopted
by
all
security
contacts.
D
I
just
wanted
to
strongly
advocate
that
that
these
new
reason
codes
wherever
they
do
end
up,
not
be
things
you
would
put
into
the
bp
bis
the
the
the
main
funnel
protocol
specification,
where
there's
no
way
we're
going
to
be
able
to
anticipate
all
of
these,
my
preference
would
be
to
add
them
in
the
documents
for
the
security
contexts
that
that
caused
those
reason
codes
to
be
raised,
but
I'm
I'm
I'm.
I
don't
feel
strongly
about
that.
A
Good
point
so,
rick
speaking
personally,
I
agree
with
scott
that
the
if
there
are
a
bunch
of
a
set
of
generic
security
related
reason
codes
that
apply
no
matter
what
the
security
context,
then
I
think
they
should
be
defined
in
bp
sec,
so
that
might
be
generic
security
failures
such
as
you
have
here,
a
missing
security
service.
One
is
required,
but
is
not
there,
etc,
etc.
A
I
think
specific
security
context
related
reason.
Codes
should
probably
go
in
the
security
context,
defining
document,
and
I
think
this
actually
comes
all
the
way
back
to
the
iana
reason
code
registry
discussion.
That
applies
to
bpbis.
So
once
we
get
that
squared
away
properly
so
expert
review,
then
these
can
all
just
start
allocating
off
each
other
and
iona
should
be
able
to
pick
this
up
during
or
48
or
at
whatever
point
in
this.
They
actually
put
these
things
together.
A
C
And
then
we're
almost
to
the
end
question
number
six
there
there
was
a
question
as
to
whether
security
context
parameters
should
be
encoded
as
a
seabor
map.
Instead
of
an
array.
The
the
the
discussion
is
here
on
the
on
the
slide.
My
recommendation
is
even
if
there
isn't
an
efficiency
there
and
I'm
not
convinced
that
there
is
it's
not
a
very
large
efficiency,
and
I
think
we
should
keep
it
as
is,
but
wanted
to
check
with
the
working
group.
A
A
D
A
Yeah
understood
that
that
efficiency
is
important
in
these
places.
I'm
I
it's
someone
with
a
lot
of
seabor
experience.
I
I
know
brian's
been
looking
at
this
quite
heavily
recently.
I
would
be
surprised
if
a
an
integer
indexed
map
of
values
is
any
more
or
less
efficient
than
an
array
of
index,
comma
value,
tuples
and
brian
as
if
by
magic,
wishes
to
speak.
E
A
A
Okay,
okay,
I
was
playing
devil's
advocate,
so
I
I
suggest
you
propose
what
you're
doing,
which
is
no
change
and
answer
benjamin
and
we'll
prod
him
to
see
if
he
can
lift
his
discuss
on
this
one
again.
If
anyone
has
any
serious
thoughts
about
this,
please
jump
on
the
mailing
list
and
send
a
strongly
worded
email
saying
that
we've
got
this
wrong.
Okay,
so
I'm
looking
at
the
time
ed
do
you
have
much
else?
Yes,.
C
Two
more,
the
the
other
is,
should
should
bpsec
force
integrity
of
non-block
type
specific
data.
This
is,
is
it
required
that
a
bib
or
a
bcb
sign
their
security,
id
security
parameters,
and
so
on?
The
recommendation
is
this
is
a
really
good
idea
and
it
should
be
done,
but
bp
sec
itself
should
not
mandate
it.
Although
we
can
add
non-marketed
text
to
explain
why
it
is
a
good
idea.
A
C
I
agree
yeah
and
then
the
last
is:
should
bp
sec
reserve
some
common
security
context
parameter
and
result
ids
in
in
bp
sec.
Currently
it
says
that
the
definition
of
that
mapping,
key
value
of
security
results
and
key
value
mapping
of
parameter
ids
is
solely
in
the
auspices
of
the
security
context
itself.
C
So
security
context,
one
parameter
one
could
be
different
than
security
context,
two
parameter
one
and
the
question
was:
is
there
value
in
reserving
a
couple
of
ids
at
the
front
that
would
be
common
for
all
security
contexts
or
not
such
that?
You
could
say.
For
example,
id
0
to
15
must
be
interpreted
the
same
for
all
security
contexts
in
vp
sec,
but
once
you
get
to
16
and
greater,
it
would
be
based
on
whatever
the
specific
context
is.
C
So
the
ones
that
have
come
up
in
the
past
are
things
like
init,
initialization,
vectors
or
values,
or
things
like
that,
and
I
could
probably
come
up
with
exactly
three
and
whether
it
is
a
great
efficiency
to
prevent
that
from
being
stated
over
and
over
again
in
individual
security
context.
I
don't
feel
strongly
about
this.
A
A
Thank
you
very
much
ed,
so
I'm
going
to
move
very
quickly
on
to
brian
if
you
can
try
and
work
out
how
to
magic.
Oh
sorry,
someone
brian's
in
the
queue
I'm
just
checking.
Somebody
raised
a
question
yeah,
so
magnus
raised
the
point
that
the
last
couple
of
comments
were
actually
comments,
not
discusses.
A
A
E
The
last
draft
changes
were
based
on
iesg
and
80
feedback.
Section
3
text
was
added
to
give
some
backgrounds
and
explanations
of
of
pki
environments
and
ca
policy
and
session
keeping
policy.
These
are
really
just
rationales
for
why
the
actual
requirements
are
the
way
they
are,
and
they
don't
have
any
changes
to
the
actual
protocol
itself.
E
I
added
a
completely
separate
draft
for
that.
That'll
be
discussed
a
bit
later
about
how
does
the
ca
actually
validate
that
I
own
a
node
id
that
I
claim
to
own
for
the
sake
of
pki,
and
there
have
been
no
further
comments
after
this,
as
was
mentioned
earlier,
I
think
prodding
the
sec
ad
or
the
isg
security
area.
Folks
is
the
last
thing
that
needs
to
happen.
E
E
C
A
A
So
I
had
to
reload
the
screen
because
I
lose
the
I
lose
the
graphics
executive
summary
of
what
I've
been
talking
to
myself
about
tcpcl,
I
think,
is
in
a
really
good
state.
Can
we
take
this
final
page
discussion
to
the
list
because
I
think
this
will
take
longer
than
we've
got
and
it's
going
to
eat
into
the
next
discussion
time.
Wise.
A
Can
people
please
re-read
the
latest
version,
because,
although
nothing
normative
has
changed,
some
text
has
changed
and
just
to
make
sure
that
we're
all
happy
with
it,
although
I
think
we
trust
brian
and
he's
done
a
really
nice
job.
Thank
you.
That's
all.
I
was
going
to
say
all
right,
thanks
brian
I'm
pushing
forwards
with
the
time
on
this
one.
Sorry,
yes,
absolutely
and
you
get
another
chance
in
a
minute
anyway.
So
ed
do
you
want
to
jump
in
with
yours?
Please.
C
And
this
is
the
interoperability
security
context,
so
the
essentially
there
there
have
been
no
changes
to
the
version,
one
which
is
has
been
up
and
we
updated
it.
I
think
in
in
february
or
march-
and
this
was
in
response
to
requests
out
of
the
iesg
review,
that
we
put
together
an
interoperability
security
context,
the
the
bib,
the
we've
named
it
bib.
I
off.
C
C
A
A
I
wonder
whether
it's
surplus,
I
know
these
are
meant
to
be
the
interop
security
contexts,
but
is
there
a
would
there
be
another
hmac
256
sha256
security
context?
That
was
not
the
iop
one?
It
just
seems
a
bit
surplus.
I
wonder
whether
you
can
just
specify
this.
This
is
the
interoperability
context
and
use
these
two,
so
people
could
say
well,
I'm
actually
just
going
to
use
that
anyway.
It
works
perfectly
well
for
me
in
my
security
domain,.
C
So
I
don't
feel
strongly
about
it.
The
only
thing
I
would
say
is
that
if
we,
if
we
were
to
remove
the
iop
and
and
have
it
just
be
those
that
could
also
be
used
for
deployment,
we
we
might
want
to
go
and
update
it
to
our
other
security
recommendations,
such
as
talking
about
you
know,
securing
other
information
in
the
bib
in
the
bcb.
C
A
B
So,
jumping
in
here
I
I
I
share-
I
mean
my
understanding
of
the
goal
of
an
intro
ability
is
to
have
one.
I
think.
Oh,
this
is
expected
to
work,
that
you
have
the
keys
to
say
and
and
can
parameterize
the
context,
but
that's
and
for
exactly
most
of
the
parameters
should
be
even
etcetera
and
it
should
be
possible.
So,
basically,
you
have
to
be
keys
to
match
to
the
claim
source
identity
so
that
you
could
decrypt
it.
A
A
A
C
C
What
we
presented
here
in
just
one
or
two
slides
is
this
might
be
a
place
for
more
specific
guidelines
for
writing
security
context,
specific
policy,
canonicalization
considerations,
usage
and
error
handling,
perhaps
even
a
common
template
for
a
table
of
contents
and
things
that
must
be
addressed
and
then,
whether
or
not
you
have
common
parameters,
result
types
or
reason,
codes
and
and
as
an
example
of
the
kind
of
normative
or
at
least
good
good
practice.
Information
that
could
be
in
there
is.
If
we
were
to
look
through.
C
You
know
the
life
cycle
of
a
security
operation,
regardless
of
what
security
context
you're
using
your
security
blocks
in
a
bundle
will
go
through
this
life
cycle.
You
know
and
make
sure
that
that
is
defined
someplace,
that
you
can
say
your
security
context
must
consider
each
of
these
possibilities
and
and
whether
or
not
there's
value
in
putting
together
things
like
security
reason,
codes
generic
if
they're,
not
in
vpsac,
and
then
notable
events
coming
out
of
such
a
security
operations,
life
cycle.
A
I
will
reiterate
that
please
look
at
this.
This
is
an
interesting
concept.
It
affects
the
workload
of
the
working
group.
I
mean
it
involves
creating
an
informational
document
which
we
haven't
done
for
a
while,
but
it
may
have
some
benefits
again
for
expediency.
Let's
make
this
a
list
discussion.
If
people
don't
mind
ed,
can
I
ask
you
to
kick
that
off
with
a
a
little
summary
of.
I
think
this
is
a
good
idea,
because
dot
dot.
A
E
I
think
so.
The
motivation
for
this
context
was
really
just
putting
my
money
where
my
mouth
was
in
terms
of
what
I
had
just
said
about
the
intro
ability
context
that
had
been
proposed,
that
it's
not
bad,
but
it
is
lightweight,
and
the
point
of
proposing
a
cosy
context
is
that
kosi
is
a
a
quite
broad
definition
of
how
to
do
a
lot
of
different
types
of
security
in
a
standard
way
and
also
in
a
way
that
is
made
by
definition,
to
be
done
in
a
constrained
environment.
E
E
Now
this
is
not
supposed
to
be
something
that
is
going
to
be
across
the
board
general
use.
I
I
don't
know
that
this
necessarily
represents
a
kind
of
a
minimum
to
implement,
but
the
intent
here
is
that
it
is
sort
of
internet
applicable
security
that
already
exists.
There
are
libraries
there
are
troubleshooting
tools
to
deal
with
with
cosy
messages
and
the
the
security
contexts
that
are
defined
here
are
done
in
a
way
again
to
fit
into
the
bpsec
model.
C
Ahead
there
we
go
so
so
two
things
ed
bahrain,
apl,
the
the
first
is
I
I
was
able
to
read
this
very
very
briefly.
Yesterday,
I
think
it's,
I
think
it's
a
great
idea
and-
and
my
first
question
is
well
if,
if
this
has
more
information
in
it
and
koci,
is
you
know
a
standard
in
this
way?
Is
this
a
a
better
default
use
on
the
internet
security
context
as
opposed
to
building
one
separately?
C
If
we
want
a
default
security
context
for
use
on
the
internet,
which
I
believe
is
what
the
ads
were
asking
for,
should
we
say
we'll
adopt,
cosy
and
wrap
it
as
a
security
context,
and
that
should
be
the
internet
default.
Or
would
you
with
the
working
group
still
like
me
to
put
a
different
one
together
for
that.
A
E
Yeah
that
sounds
great
and-
and
the
point
here
also
is
that
if,
if
there's
a
network
or
an
operator
that
does
care
about
these
things,
then
absolutely
they
should
define
their
security
context
as
they
need
to,
and
this
is
made
more
for
an
operator
that
doesn't
necessarily
care.
They
just
want
to
use
what's
available.
A
Which
is
a
very
important
use
case
should
be
remembered.
It's
it's
very
easy
for
those
of
us
in
the
aeronautical
industry,
or
you
know
very
dedicated
industries
like
that
to
say
that's
fine,
we
we
have
customers
who
define
us,
but
their
security
specifications,
but
dtn
as
we
keep
telling
ourselves
and
others
has
applicability
beyond
big
industry
and
has
applicability
in
the
internet
as
a
whole,
particularly
with
iot
devices
and
hence
building
on
cozy.
I
can
see
personally
as
an
important
thing
to
be
able
to
do
and
just
say,
use
this.
A
A
Let
you
choose
one
and
give
you
five
minutes,
but
I'm
gonna
ask
one
last
question:
when
booking
dtn
meetings
the
chairs
have
to
select
how
long
they
want
and
how
many
sessions
they
want
and
for
the
last
couple
of
years
we
have
said
one
two
hour
session
is
enough:
question
to
the
list
would
a
longer
session
help
in
future.
Do
people
have
things
they'd
like
to
say,
but
feel
that
there's
not
time.
I'm
really
pleased
that
this
is
a
big
session
and
there's
lots
of
people
and
scott
is
keep
it
quick
scott.
D
A
E
So
my
questions
to
the
working
group
are
really
a
matter
of.
I
know
this
is
a
charter
item,
but
is
it
worth
at
this
point
dealing
with
this
kind
of
thing
at
a
bundle
level
and
doing
all
the
things
that
have
to
happen
in
a
draft
to
be
able
to
solidify
some
of
these
concepts
to
be
able
to
have
a
general
purpose?
Dtn
neighbor
discovery
protocol
and
one
way
of
transporting
a
dtn
neighbor
discovery
is
over
something
like
a
udp
broadcaster
multicast.
E
A
Down,
okay,
so
rick,
jumping
in
with
my
chair
hat
on
to
start
with.
Yes,
I
believe
this
and
somebody's
raised
a
comment.
I
bet
just
check
right.
Okay,
so
ronald
hasn't
raised
a
very
good
point.
Ronald
do
you
want
to
jump
to
the
microphone
line
in
a
second,
so
neighbor
discovery
and
neighborhood
discovery
are
both
items
that
should
be
on
the
charter.
I
need
to
quickly
check
the
charter
myself.
If
they're
not,
they
should
be.
I've
lost
the
charter,
I'm
useless
at
times.
A
A
A
E
Okay,
I
I
was
just
gonna
reiterate
what
was
just
said
about
as
much
as
possible.
You
know
these
these
recent
mene
rfcs
have
have
been.
I
believe,
after
some
of
these
other
drafts
have
occurred.
So
synthesizing
algorithms
that
are
well
defined
out
of
the
manet
with
encodings
of
bp
bis
could
go
a
long
way
to
not
not
reinventing
things.
A
So
that
reminds
me
of
one
last
thing
with
my
chair
hat
on
and
knowing
that
ronald
is
the
chair
of
manet
manny.
At
the
moment.
Correct
me,
if
I'm
wrong
ronald
is
looking
for,
has
a
load
of
work
that
has
been
done
historically
and
is
looking
for
more
participation
and
given
that
both
given
that
ronald
is
active
in
dtm
as
well
as
in
manet
and
I'm
active
in
mana
as
well
as
dtn.
A
We
see
that
there's
quite
a
lot
of
crossover.
One
of
the
discussions
to
be
had
is
about
the
management,
so
I
have
had
discussions
with
ed
and
I've
had
discussions
with
ronald
about
whether
the
ama
amp
work
might
whether
the
man,
a
working
group,
actually
has
enough
cycles
at
the
moment
to
pick
up
some
of
that
and
that's
a
question
for
the
working
group
about
whether
they
want
to
cling
on
to
ama
or
whether
they
want
to
help
sorry,
not
not
the
architecture.
A
But
the
protocol
work
whether
they're
happy
to
help
get
that
work
done
in
many.
Whether
they'd
like
to
continue
to
see
that
work
done
in
dtn
and
equally
neighbor
discovery
is
something
where
we
can
go
to
manet
and
say:
please
help
us
and
and
hopefully
we
can
help
them
in
return.
That's
just
my
passing
comment.
A
So
I'm
also
conscious
that
it's
13
39
in
the
uk,
12
39
utc,
and
we
finish
at
12
40.,
so
I'm
going
to
open
the
mic
for
one
minute.
If
anyone
has
anything
they
want
to
add
otherwise,
I
do
apologize
for
the
poor
timing
of
this.
I
will
book
some
a
book
along
a
session
for
the
next
one
and
thank
you
very
much
for
all
the
participants.
A
B
A
Even
though
I
muted
myself
for
five
minutes
otherwise,
thank
you
very
much
everyone
I
think
go
ahead,
brian,
oh
no!
I
just
haven't
muted
you.
Thank
you
very
much
everyone.
I
think.
That's
the
end
of
the
session.
I
will
close
it
down
in
some
way.
Thank
you
very
much
for
your
attendance
and
yeah
ietf109,
probably
virtual.
If
it's
not
I'll,
see
you
in
bangkok
and
hopefully
this
time
next
year
we
can
actually
meet
in
person,
but
mailing
list.
A
Please
use
the
mailing
list
because
it's
not
only
a
good
way
to
have
a
conversation,
because
you
can
think
about
what
you're
saying
it's
also
a
record
of
that
conversation
for
when
someone
comes
back
in
ten
years
and
says
why
did
they
do
it
that
way?
So
please
use
the
mailing
list.
Okay,
thank
you
very
much
guys
I'm
going
to
shut
this
down
and
I
will
see
you
next
as
everyone's
off
to
barbell.
Apparently.