►
From YouTube: IETF109-DTN-20201120-0500
Description
DTN meeting session at IETF109
2020/11/20 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
A
A
A
A
A
A
So,
just
to
kick
off
this
session
is
being
recorded
because
we're
on
meat
echo,
so
it's
all
being
recorded
as
usual
I'll
get
to
the
agenda
on
the
next
slide
standard
things
there's
a
participation
guide
given
this
is
the
friday
of
this
ietf
and
I'm
assuming
most
of
you
have
attended
other
sessions
already.
You
should
be
fairly
familiar
with
how
meat
echo
works
given
you're
listening
to
me,
it
assumes
mute.
Echo
is
working,
but
the
links
for
how
to
report
technical
issues
etc
are
also
on
this
slide.
A
But
a
quick
search
on
the
internet,
using
your
favorite
search
provider,
will
also
find
the
usual
ietf
assistance
pages
in
case
of
a
catastrophic
technical
breakdown,
although
how
using
the
internet
to
solve
an
internet
problem
helps
I'm
not
quite
sure
anyway,
so
this
being
an
itf
session,
it
is
covered
under
the
note.
Well,
I
hope
you
are
familiar
with
this.
If
not,
I
suggest
you
read
it
carefully.
A
This
is
dragged
on
for
a
long
time
and
we
really
do
have
to
get
these
things
finished.
There's
been
a
list
of
discusses.
I
know
the
authors
and
the
working
group
have
been
working
quite
hard
to
try
and
get
these
cleared
because
of
that
we
have
moved
the
tcpcl
updates
presentation
later
into
the
agenda.
This
is
to
give
benjamin
caduck
and
I'm
sorry
if
I
get
your
pronunciation
of
your
name
incorrect,
who
is
one
of
the
isg
reviewers.
A
It
gives
him
a
chance
to
attend,
and
actually
we
can
try
and
get
some
of
these
comments
addressed
at
the
mic,
because
doing
these
things
in
real
time
is
often
quicker
than
doing
them
over
email.
Obviously,
everything
will
always
be
confirmed
on
the
mailing
list,
because
that
is
a
record
of
decisions
made,
but
the
ability
to
have
conversations
at
the
mic
should
hopefully
help
us
clear
up
those
last
issues.
A
A
Everyone
involved
is
extremely
apologetic
because
we
wanted
to.
But
it's
it's
got
a
bit
complex.
That's
fine!
Okay,
a
little
bit
of
administrivia
meat
echo
can
struggle.
Apparently
there
was
a
denial
of
service
attack
on
it
yesterday
for
some
reason
on
the
jabber
part
of
it
all
video
conferencing
systems
have
their
problems.
A
A
There
are
a
number
of
just
reload
the
whole
site
buttons
at
the
bottom
right
hand
corner
of
your
screen,
and
that
really
helps
if
your
audio
breaks
up,
if
not
just
reload
your
whole
browser
page,
as
you
can
understand,
there's
a
lot
of
people
from
all
over
the
world
trying
to
use
this
system
it's
running
on
a
cloud
provider.
Occasionally
there
are
hiccups.
A
A
We
need
minutes
taken
the
interactive
sort
of
shared
the
equivalent
of
etherpad.
There's
a
system
called
kodi
md
that
is
built
into
meet
echo.
We
would
like
to
use
this
for
the
minutes.
Our
normal
excellent
minute
taker
ed
is
now,
of
course,
one
of
our
is
our
new
co-chair
with
me.
So
there
we
need
volunteers
to
work
on
keeping
the
minutes.
A
Please
don't
use
it
as
an
opportunity
to
stick
an
entire
essay
underlining
your
point
in
extreme
detail,
but
a
good
capture
of
of
what
is
happening
is,
of
course,
useful
and
the
mailing
lists
just
to
reiterate,
dtn
itf.org
and
also,
if
you
need
to
contact
the
chairs.
Unlike
my
previous
typo,
when
asking
for
agenda
items,
it
is
dtn
chairs
at
ietf.org,
not
itef.org,
although
if
anyone
wants
to
register
that
domain
and
forward
it
to
somewhere
useful,
I'm
sure
that
would
be
appreciated.
A
What
I
will
stick
in.
I
should
have
put
a
slide
in
for
this.
I
would
like
to
introduce
ed
brain.
A
lot
of
you
know.
Ed
he's
been
our
secretary
for
a
couple
of
years
now,
mark
blanchet
has
decided
to
step
down
as
a
dtn
chair
and
I'd
like
to
take
this
opportunity
to
thank
him
for
all
his
hard
work
over
from
the
inception
of
this
working
group.
All
the
way
through
to
this
current
session,
I
think
he's
done
the
working
group
proud
and
his
input
continues.
A
C
Well,
no,
thank
you
very
much
and
I
I
just
wanted
to
echo.
You
know
the
the
conversations
that
I'd
had
with
mark
over
the
years
about
dtn
and
understanding
its
use
in
a
variety
of
different
use.
Cases,
terrestrial
and
and
in
space
have
been
have
been
extremely
helpful
and
his
dedication
to
making
sure
that
that
this
work
continues
and
continues
in
a
way
that
makes
it
correct
and
implementable
and
operational
is,
is,
and
continues
to
be,
appreciated.
C
What
I,
what
I'd
like
to
say
otherwise,
is
thank
you
for
the
opportunity
to
come
in
and
help
chair
the
working
group,
something
certainly
that
we
are
passionate
about
and,
speaking
about
being
passionate
about
some
of
this
work.
We
we
have
been
passionately
pursuing
bp,
biz,
bp,
sac
and
tcp
clv4
for
really
quite
some
time
and
as
we
have
gone
through
several
iterations,
and
this
most
recent
being
the
comments
from
the
iesg
review.
C
We
have
gotten
to
be
very,
very,
very
close
to
finishing
the
outstanding
discusses
and
comments
associated
with
these
documents.
The
expectation
is
through
the
presentations
today,
we'll
be
able
to
understand
if
there
are
any
remaining
questions.
Something
that
is
important
is
even
when
the
documents
come
out
of
the
working
group
last
call.
But
then
we
look
at
discusses
and
comments.
A
A
Any
other
business
at
the
end
of
the
session
that
may
well
be
eaten
up
by
overruns,
have
no
objection
to
overrunning,
particularly
on
the
key
documents,
as
ed
said,
that
are
under
iasg
review
at
the
moment,
as
they
are
really
blocking
further
work
in
the
working
group.
So
so
we
need
to
get
these
things
sorted,
so
we'll
be
fairly
lenient
with
time
for
the
early
things,
but
so
I
can
only
apologize
to
some
people
who
have
late
agenda
items
at
the
end
of
the
agenda.
A
C
E
A
F
So
with
that
in
mind,
I
will
try
to
mention
the
further
updates
beyond.
What's
on
these
slides
as
we
go
through
them,
when
I
was
putting
this
together,
I
looked
back
through
the
last
four
or
five
months
of
emails
and
tried
to
compile
the
status
of
what
I
understand
to
be
the
remaining
open
questions
on
the
draft.
So
next
slide.
F
The
and
I
won't
go
through
this
extensive
email
trail
at
the
end
of
it.
We
I
believe,
settled
on
some
language
that
is,
in
the
first
two
paragraphs
of
section,
nine
of
the
specification
that
I
believe
addresses
everybody's
concerns
and
reflects
the
the
consensus
of
people
who
are
on
the
mailing
list.
Aside
from
mark
who
disagreed
with
this,
the
concept
entirely.
F
Everybody
else
is
okay,
with
there
being
some
element
of
mandate,
and
the
text
of
that
mandate
is
written
in
those
first
two
paragraphs
of
section
nine.
We
can
go
through
those
now,
but
I
would
propose
that
we
instead
press
through
the
rest
of
this
list
and
then
come
back
to
specific
questions
at
the
end.
If,
if
there
are
some.
F
A
Interrupting
here
sorry,
I
think
it
is
worth
at
the
end
of
this
just
reiterating
the
statement.
That's
in
the
current
the
latest
draft,
just
to
make
sure
that
everyone
has
that
understanding
of
mandatory
to
and
I'm
sorry
it's
early
for
me
mandatory
to
implement
sorry
mandatory
to
implement
optional
to
use
is
the
executive
summary.
F
Do
it
right
now,
okay,
so
the
first
two
paragraphs
of
section,
nine
bundle,
protocol
security
architecture
and
the
available
security
services
are
specified
in
an
accompanying
document.
The
bundle
security
protocol
specification
bpsec
whenever
bundled
protocol
security
services,
as
opposed
to
the
security
services
provided
by
overlying
application
protocols
or
underlying
convergence
layer
protocols
are
required.
Those
services
shall
be
provided
by
bpsec
rather
than
by
some
other
mechanism,
with
the
same
or
similar
scope.
That
is
when
security
is
is
required.
Bpsec
is
the
way
you
do
it.
F
A
second
paragraph,
a
bundle
protocol
agent,
which
sources
cryptographically,
verifies
and
or
accepts
a
bundle,
must
implement
support
for
bpsec
use
of
bpsec
for
a
particular
bundled
protocol
session
is
optional.
I
think
that
is
the
language
that
then
ran
atkinson
proposed,
and
I
that
everybody
agreed
to,
and
I'm
certainly
fine
with
it.
If
there
are
objections
to
it,
it
would
be
good
to
bring
those
out
on
the
mailing
list.
F
So,
let's
move
to
the
next
slide,
then
some
of
these
will
go
very
quickly
because
there
have
been
no
comments,
but
this
is
one
of
the
open
questions
that
that
we
do
need
to
resolve.
There
was
a
discuss
on
this
and
I
believe
from
the
last
email
exchange
with
magnus.
I
believe
we've
satisfactorily
resolved
this
question.
There
were
a
couple
of
sections
in
paragraphs
in
sections,
10.3
and
10.4
that
were
simply
removed
in
version
29
of
the
specification.
G
I
G
F
F
A
F
F
So
I'm
gonna
assume
that
that
language
is
okay
and
on
the
next
slide.
Similarly,
there
is
this
question
of
authorizing
protocol
agents
to
override
the
bundle
lifetimes
that
are
asserted
by
bp
applications,
and
the
idea
here
is
to
enable
a
mechanism
for
congestion
mitigation,
which
was
one
of
the
early
discuss
items
that
that
merger
brought
up
to
enable
congestion
mitigation
by
authorizing
bundle,
protocol
agents
to
essentially
delete
bundles
by
changing
the
bundle
lifetime
locally
and
and
by
using
a
an
overriding
bundle
lifetime.
F
For
this
purpose,
we
provide
a
a
little
bit
of
adjustability
to
it.
You
could
set
it
up
so
that
it
if
you're,
if
you're
running
short
on
space,
maybe
you
set
the
the
bundle
lifetime
for
the
purpose
of
your
own.
As
a
as
your
own
bundle
note,
is
your
own
possession
of
the
bundle
you
set
it
to
half
an
hour.
G
A
F
C
Scott,
this
is
ed.
I
had
a
question
about
that
when,
when
we,
when
we
use
this,
if
we
were
to
delete
a
bundle
by
advancing
or
or
changing
or
overriding
its
bundle
lifetime
and
a
reason
code
would
be
generated
as
an
administrative
record,
showing
that
the
bundle
had
been
deleted
for
this
purpose.
Would
the
reason
code
be
that
the
lifetime
was
expired
or
would
it
be
something
else.
F
I
F
Okay,
then,
let's
go
on
to
the
next
slide.
This
is
whether
or
not
the
language
in
41511
is
a
satisfactory
specification
of
the
dtn
scheme.
Endpoint
id
syntax.
That
enables
enables
a
bundle
protocol
agent
to
differentiate
between
a
dtm
scheme,
endpoint
that
is
singleton
and
one
that
is
that
has
multiple
or
potentially
has
multiple
members
in
the
endpoint
and
the
mechanism
proposed
to
that
is
for
the.
E
F
F
This
is
another
one
where
there
was
some
discussion
on
the
mailing
list
and
the
the
core
question
here
is-
and
this
has
come
up
in
a
number
of
of
contexts,
bona
protocol
time
values
such
as
creation,
time
lifetime
bundle.
Age
has
been
denominated
in
seconds,
and
there
is
has
there's
been
this-
this
objection
that,
oh,
no,
it
needs
to
be
in
milliseconds,
because
for
some
purposes
we
need
finer
grained
decision
making
on
on
the
basis
of
time.
F
F
A
A
F
A
Just
as
a
side
note
me,
techo
has
a
queue
if
you,
if
anyone
has
any
comment,
please
jump
to
the
queue
now,
rather
than
waiting
right
until
the
end
of
the
presentation.
I
think
it's
worth
because
some
of
these
questions
are
complex
and
there's
a
few
outstanding
questions.
So,
if
you're
hanging
back
to
ask
all
your
questions
in
a
big
rush,
I
have
no
objection
to
stepping
to
the
stepping
on
the
queue
now.
F
D
D
From
stu
on
the
dropping
thing
a
little
while
ago
that
I
added
to
the
to
the
cody
but
will
asked
a
question
right
before
you
said
something
about
the
queue
and
I
waited
for
him
to
hopefully
get
in
the
queue
he
didn't.
So
I
stepped
in
the
queue.
So
will,
if
you
don't
mind
I'll,
just
vocalize
your
question:
was
there
a
discussion
of
a
variable
denomination.
D
F
Primary
block,
immutability,
and
so
it
was-
was
not
gonna,
be
okay,
that
is
changing
from
seconds
to
milliseconds
on
route
from
the
source
to
destination.
That's
not
going
to
be
an
okay
option.
I
I
would
go
a
little
further
and
for
for
purposes
of
of
simplicity,
I
I
I
would
endorse
the
idea
that,
all
times
throughout.
F
A
D
I'm
just
stepping
in
again
I
know
because
I
know
stu
can
actually
talk.
He's
I
talked
to
him
earlier.
Does
he
want
to
step
up
and
go
to
the
mic
to
ask
his
questions
on
the
drops
of
the
bundles
because
he
did
ask
a
question
there?
I
don't
know
if
we
want
to
just
backtrack
back
to
that
real
fast
or,
if
sure,
that's
fine
stu.
Do
you
want
to
step
up
and
ask
that
question.
A
F
A
F
K
B
Yes,
I
do
believe
this
was
a
question
that
was
great
for
one
of
my
comments
and
the
intent
I
had
in
my
comment
was
more
along
the
lines
of.
Can
we
ensure
that,
if
that,
if
I
put
this
extension
in,
I
can
be
confident
that
the
other
end
will
understand
it,
so
that
would
be
the
sort
of
mandatory
to
implement,
but
not
mandatory,
to
include
in
every
bundle.
I
I
A
Rick
here
what
I
I
get,
I
get
confused
by
the
word
extension
because,
for
some
protocols,
extension
is
is
used
to
describe
a
mechanism
that
additional
functionality,
possibly
not
described
in
the
original
specification,
can
use
so
extending
a
protocol
to
add
features
that
you
might
require
for
your
enterprise
or
your
deployment
as
compared
to
where
I
think
we
use
the
word
extension
in
bpbs
to
mean
flexible
extra
blocks
that
are
optional
to
have
within
a
bundle.
And
I
wonder
whether.
F
A
That
terminology
confuses
people,
so
traditionally
an
extension
would
be
optional
to
implement.
I
you
you
implement
it.
If
you
support
the
extension
and
the
extension
would
be
specified
in
some
way,
whereas
a
bit
like
ip
header
fields,
they
are
mandatory
to
understand
and
for
and
defined
but
optional
to
use.
F
F
That
the
the
presence
or
absence
of
the
blocks
is
optional,
subject
to
some
constraints,
so
I
I
I'm
at
the
moment.
I
think
the
the
language
is
correct
about
the
presence
or
absence
of
the
blocks
if
we
want
to
add
some
language
that
says
that
these
extension
blocks
must
be
implemented,
that
that
is
the
ability
to
handle
these
particular
extension
blocks
is
mandatory.
I
think
that's
a
perfectly
reasonable
thing
to
add
to
the
to
the
start
of
4.3.
A
Yeah
on
the
on
the
chat
mark
blanche
correctly
points
out
that,
given
this
is
a
very
disconnected
network
protocol,
we
can't
have
a
negotiation
protocol
between
the
two
endpoints
to
negotiate
extensions
and
capabilities.
Therefore,
we
need
to
make
extensions
mandatory
to
implement,
but
that
could
create
an
issue
in
the
future,
as
new
extensions
could
then
require
implementations
to
become
non-conformant
in
some
way.
So
I
I
agree
with
him
on
this:
there's
there's
a
difference
between
future
extension
of
bp
bis.
A
To
add
capabilities
that
may
not
exist
in
existing
implementations,
which
is
different
from
here,
are
some
extra
blocks
that
may
appear
in
your
bundle,
but
you
must
be
able
to
handle
them
if
you
see
them-
and
I
I
think,
okay
action
for
the
working
group
on
this,
please
can
people
double
check
this
section
and
ensure
that
it
meets
your
understanding
of
what's
needed
here.
I'll
make
a
note
of
that
and
I'll
I'll
get
that
on
the
mailing
list.
D
D
F
I
I
think,
if,
if
we
wanted
to
do
that,
I
think
we
would
add
a
term
rather
than
replacing
the
term,
because
there
are,
it
sounds
like
there
are
what
we
are
currently
calling
extension
blocks
that
are
mandatory
and
mandatory
to
implement,
and
then
there
are
additional
extension
blocks
that
cannot
be
made
mandatory
to
implement
in
this
specification
because
nobody's
defined
them.
Yet.
F
So
well
I
I
I
would.
I
would
propose
that
we
don't
necessarily
have
to
do
that
if
we
don't
want
to
introduce
additional
terminology-
and
I
I
actually-
I
agree
with
adam-
that
introducing
additional
terminology
you
know
willy-nilly
is
is
often
a
bad
idea.
What
we
say
currently
is
extension
blocks
are
all
blocks
other
than
the
primary
payload
blocks,
which
is
very
clear.
G
A
Okay,
so
I'm
watching
the
clock
here,
ronald
in
the
chat,
makes
a
very
valid
point,
which
is
extension
block
is
a
well-known
term
in
this
dtn
in
the
dtn
itf
work.
So
those
were
inside
dtn
do
understand
what
an
extension
block
is,
but
I
think
for
fresh
readers
to
bp
bis.
We
need
to
make
sure
that
that
terminology
is
correctly
defined
and
the
rules
for
implementers
is
is
there
but
we'll
move
on?
F
A
H
F
A
A
A
D
A
D
During
that
little
conversation
we
just
had
there
because
I
got
involved
speaking.
I
did
miss
a
couple
bits
of
it.
If
you
can
cat,
if
people
can
capture
that
into
the
kodi,
that
would
be
wonderful,
because
I
did
miss
bits
and
pieces
of
that
because
I
was
speaking
and
it
was
hard
to
switch
back
and
forth
just
so.
Everyone
is
aware.
A
A
I
H
H
We
have
one
outstanding
discuss
item
that
is
teed
up
primarily
for
discussion
here
today
and
that's
regarding
mandatory
security
contexts,
and
at
this
point
we
believe
that
to
be
addressed
with
the
current
version
of
bp
sec,
which
is
version
24..
So
if
you
flip
over
to
the
next
slide,
is
that
yeah?
It
is
doing
it
yeah
perfect.
So
this
is
a
an
update
from
what
ed
presented
at
the
last
meeting
at
108.
H
I
captured
all
of
the
questions
that
questions
that
he
spoke
to
just
highlighting
some
of
the
updates
made
and
identifying
whether
or
not
there's
some
functional
changes
between
those
between
22
and
24,
so
the
bolded
items
there
are
the
ones
that
I'm
going
to
be
discussing
in
the
rest
of
the
slide
deck
the
items
that
are
not
bolded.
There
are
obviously
no
changes
at
all
no
changes
made
at
all,
so
we
left
those
alone
and
those
won't
be
discussed
here.
H
G
H
A
H
H
C
I
can
I
can
speak
to
that
also
for
a
moment
that
we,
we
were
getting
questions
related
to
the
idea
that
if
a
bundle
was
going
through
a
network
and
every
node
in
the
network
wanted
to
provide
its
own
signature
over
a
particular
security
target.
What
do
you
do
in
that
case?
If
you
have
many
many
dibs
all
pointing
to
the
same
security
target?
C
That's
not
allowed
in
dp
sac
and
the
reason
it's
not
allowed
in
vpsa
is
because
it
becomes
a
nightmare
for
verification
afterwards
and
and
should
not
be
allowed,
and
so
we
made
it
clear
here
that
if
there
is
some
I'll
use
the
term
madness
that
needs
to
be
done,
then
the
behavior
of
it
really
should
just
be
encapsulated
inside
of
a
single
security
context
where
they
allow
multiple
security
results
to
be
added
if
they
needed
to
to
that
single
bid.
That
would
exist
to
capture
those
results,
but
but
otherwise
one.
A
Ed,
adding
adding
a
following
comment
so
in
in
the
multi-signature
scenario
or
the
multiple
verification
scenario.
The
assumption
is
that,
in
the
definition
of
the
security
context,
that
does
this
operation,
the
the
verification
methods
and
all
the
problems
associated
with
it
will
of
course
be
solved
in
that
specification.
H
All
right,
so,
if
there's
nothing
further,
let's
go
to
the
next
slide.
Please
thank
you.
So
the
the
topic
here
for
discussion
was
somewhat.
Similarly
considering
whether
or
not
we
should
be
considering
signature
encryption
over
multiple
blocks
again
taking
the
same
path
here
and
making
no
functional
change
from
22
into
24,
and
instead
adding
language
to
recommend
implementation
through
a
custom
security
context.
H
A
I
think
actually,
one
of
one
of
the
legitimate
criticisms
of
some
of
the
early
bp
sec
drafts
was.
It
was
so
flexible
that
it
was
entirely
conceivable
to
tie
yourself
in
knots
and
from
an
implementer
perspective.
It
looks
like
a
such
a
tough
target
to
to
try
and
get
your
implementation
correct
because
of
such
options.
I'm
a
huge
fan
of
security
context.
I
think
they
solve
a
lot
of
this
problem.
H
Okay,
if
there's
nothing,
nothing
further,
next
next
slide
there,
okay!
So
this
this
topic
here
was
asking
you
know
proposing
that
we
add
bundle
protocol,
reason
codes
again,
because
there's
there's
new
reasons
that
a
bundle
might
or
a
a
node
might
discard
a
bundle.
So
within
bpsec24
there
are
five
new
reason,
codes
that
are
added
and
and
recommends
that
those
are
allo.
Those
reason
codes
be
allocated
within
the
existing
bundle
status
report
reason,
codes
registry.
H
So,
if
there's
nothing
further,
we'll
go
on
to
what
I
believe
is
the
last
slide
here
and
in
a
similar
vein,
there
should
be
set.
Should
bp
sec
be
reserving
some
security
context
per
parameter
and
result
ids
to
pro
promote
con
commonality
they're,
the
change
in
mvp
24
is
to
set
negative
values
as
reserved
for
local
and
on-site
specific
use
within
the
security
context,
identifier
registry,
so
again
this
the
only
change
here
is,
is
adding
those
negative
values
as
being
reserved.
C
A
C
M
A
A
A
H
H
So
you
know
it
adds
detail
to
the
security
context
that
already
exists.
So
that's
the
the
hmac
and
sha-2
bib,
as
well
as
the
aes
gcm,
bcb
security
context
and
as
a
a
reminder,
the
for
the
the
aes
gcm
bcb
that
provides
a
integrity
mechanism
as
well
as
a
encryption
and
decryption
mechanism,
and
so
in
in
each
of
the
security
contexts.
H
H
H
C
H
Thank
you.
So
here
this
is,
you
know
mostly
included
for
included
for
completeness.
This
is
obviously
a
copy
and
paste
from
the
document
itself
again
kind
of
talking
to
canonicalization
algorithms
so
for
the
integrity,
integrity,
protection,
security
context,
there's
a
canonicalization
algorithm
defined
that
appen
in
order
to
append
the
to
specify
how
the
canonical
forms
the
components
of
the
bundle
specified
by
the
scope
parameters
are
appended
and
formed
together
as
a
as
an
input
to
the
security
operation.
H
So
you
know
there's
a
well-defined
operation.
You
know
processing
flow
defined
there,
so
starting
with
an
empty
set
of
length,
zero,
there's
a
bunch,
essentially
a
series
of,
if
statements
and
depending
on
what
are
what
is
specified
as
the
the
input
scope
it
take.
First
of
all.
First,
it
will
take
the
canonical
form
of
the
primary
block,
append
that
to
the
to
the
ippt.
H
Next
up,
it
will
look
at
the
security
header
flag.
You
know,
let's
see
security,
header,
flags
and
and
various
flags
there,
let's
apologize
for
being
a
little
bit
lost
in
the
text
here,
but
essentially
it
you
know
go
through.
It
goes
through
again
looks
at
all
of
the
integrity
scope
parameters
specified
computes
the
canonicalized
form
of
each
of
those
and
sequentially
appends,
those
in
a
well-defined
order.
H
H
H
It's
some
language
there
right
from
the
right
from
the
document
as
well
to
specify
how
that's
how
that's
presented
as
an
input
there.
Likewise
for
decryption,
the
ciphertext
is,
is
formatted
in
a
similar
way,
well-defined
way
to
be
passed
into
that
that
processing
and
then
for
the
integrity
calculations
against
the
additional
authenticated
data
that
follows
essentially
just
as
previously
shown
in
the
in
the
integrity,
protection
mechanisms.
A
H
That
correct,
so
this
is
it's
definitely
you
know
from
my
perspective,
it
seems
to
be
you
know,
oriented
that
way
right.
So
that
way,
you
can
have
flexibility
in
terms
of
how
you
implement
the
processing,
how
you,
how
you
implement
your
formatting
in
such
a
way.
That
makes
sense
for
a
given
security
context
that
you
might
want
to
implement.
That
would
be
different
than
this
one.
So
by
not
putting
this
in
the
main,
you
know
bp
sec
again
we're
not
tying
the
bp
sec
to
have
a
specific
implementation.
C
So
rick
an
example
of
that
would
be
context
if
someone
really
wanted
to
do
this,
where
they
would
portion
out
and
and
encrypt
only
portions
of
of
the
target,
as
opposed
to
the
entire
thing
and
get
into
you
know,
encryption
ranges
and
blocking
off
the
plain
text,
and
that's
just
not
something
that
should
be
in
bp
sec.
It's
also
not
something
that
should
be
in
the
default
security
context.
Maybe
it
shouldn't
be
anywhere,
but
if
it
needs
to
be
somewhere,
it
would
be
in
its
own
document.
H
C
The
bp
sec
document
has
a
single
discuss
against
it
from
mira,
and
that
is
that
there
needs
to
be
an
approved
set
of
default
security
contacts
to
go
with
it.
So
this
document
and
the
security
context
dash
o2,
does
need
a
nice
review
before
it
goes
out.
It
is
in
working
group
last
call
if
you
have
not
read
it
or
read
the
new
version.
Please
this
week
take
some
time
and
go
through
it
and
provide
comments
on
the
mailing
list.
G
A
Absolutely
absolutely
we
have
a
quick
agenda
change
because
we
have
reshuffled
so
that
ben
could
could
get
involved
with
the
tcpcl
conversation
he
has
multiple
clashes
today.
He's
asked
that
we
bring
tcpcl
in
as
the
next
item
rather
than
the
cozy
context.
I
am
very
sorry
to
juggle
everyone
around,
but
we
really
need
ben
and
brian
to
talk
about
tcpcl
together,
so
I'm
going
to
shuffle
it
everything
around
once
more
brian.
Are
you
happy
to
present
now
I'm
really
hoping
you're,
not
getting
a
coffee
he's
there
right
I'll,
find
the
slides.
M
A
A
M
M
So
there
were
two
main
sources
of
changes
from
the
last
draft
and
there's
even
a
further
23
revision,
and
these
are
feedback
from
ben
caduc
and
and
feedback
from
martin
duke
and
the
good
news
is.
This
is
not
changing
the
the
structure
of
tcpcl,
not
changing
the
encodings
of
things
in
a
fundamental
way.
M
Interoperable
is
the
goal
here
and
also
usable
with
the
current
pki
x
tools
and
and
tooling
that's
available.
So
this
is
still.
There
are
a
few
issues
remaining
to
be
worked
out,
and
I
have
another
slide
later
on
that
I
I
can
talk
about,
but
it's
really
nailing
down
specifics
about
how
to
make
tcpcl
behave
in
a
way
that
is
in
agreement
with
best
current
practices
and
in
agreement
with
other
protocols
using
the
same
types
of
mechanisms
or
the
same
mechanisms.
M
There
are
some
terminology
changes
again
just
to
be
clear
about
when
an
ip
address
is
being
named
versus
a
dns
name,
and
this
is
again
pulling
tcpcl
closer
in
line
with
other
specs
covering
the
same
ground.
I
added
a
clarification
based
on
scott
burley's
comment
about
how
do
existing
implementations
handle.
If
I
ask
to
make
contact
with
node
a
and
they
respond,
I'm
node
b,
what
should
the
behavior
of
the
convergence
layer
be,
and
that
is
continue
on
with
a
warning?
M
Basically,
the
bundles
must
continue
to
flow
and
martin
duke's
feedback
did
lead
to
one
change
and
that's
the
addition
of
transfer
refuse
reason-
and
this
is
something
that
really
was
an
oversight
from
earlier-
that
when
it
comes
to
shutting
down
cleanly
shutting
down
a
tcpcl
session,
there's
a
period
of
time
when
you
can't
accept
new
transfers
because
you're
shutting
down
that's
the
whole
point
of
having
that
clean
termination
procedure.
So
one
of
these
refusal
reasons
is,
I
am
terminating.
M
M
So
if
you
can
go
to
the
next
slide,
so
that
covers
what's
in
22,
and
some
of
this
is
also
changes
in
23
focused
on
the
pki
aspects
of
things.
I
I
am
planning
on
doing
so
this
first
topic
of
how
to
define
the
use
of
can
tls
contact
header
flag
after
looking
at
what
ran
and
ben
have
been
have
been
discussing
on
the
mailing
list.
M
The
one
comment
that
came
in
from
I
believe
it
was
from
martin
about
a
supported
version
set.
This
is
something
that
hadn't
been
discussed
prior,
it's
not
something
that
had
been
present
in
the
previous
tcpcl.
The
concept
is
in
some
protocols.
You
can
say
I
don't
support
version
three,
but
I
do
support
version
four
and
two.
M
The
next
contact.
Please
use
one
of
those
versions,
the
current
spec.
The
way
it
operates
is
you
start
the
top
of
your
list
latest
revision
and
you
work
down.
So
there's
a
risk
that,
if
you're
talking
about
just
pure
open
network
anybody
talking
to
anybody
the
risk
is
it
takes
you
two
or
three
failed
connection
attempts
to
negotiate
a
shared
version.
M
I
don't
necessarily
see
a
problem
with
that.
It's
a
question
to
working
group.
If,
if
it
seems
like
it's
worth
adding
complexity
to
the
contact
header
right
now,
the
contact
letter
is
short
and
fixed
length,
and
this
would
just
add
a
little
bit
of
complexity
to
the
contact
header.
So
it's
I'm
not
sure
that
there's
much
value
in
this
for
the
use
cases
that
are
known
on
this.
M
A
M
G
A
A
M
A
M
A
Yeah,
I'm,
I
assume
we're
we're
optimizing
for
the
case
where,
where
both
ends
actually
know
the
versions
and
have
made
contacts
previously
and
have
some
idea
that
that
you
know
so
we
don't
the
version
mismatch.
I
don't
think
is
on
the
is
on
the
critical
path
for
these
things,
but
it
does
need
to
be
specified.
Okay,
yes-
and
it's
also-
I
mean
this-
it
could
be
kicked
down
to.
M
A
So
I
understand
that
they
sort
of
I.
I
have
no
idea
what
you're
talking
about
seems
to
be
a
fairly
valid
reason
code
or
possibly
just
killing
the
tcp
connection.
I
you
sent
me
something
which
looks
like
garbage
to
me,
which
is
different
from
you've
sent
me.
I
something
I
understand
as
a
tcpl
version,
3
header,
so
so
version
2
low
I
can
I
can.
I
can
implement
that
version,
two
high,
I'm
predicting
the
future,
but
let's
take
this
offline.
Okay,.
M
It's
not
gonna
be
changed,
at
least
in
the
near
term.
Here's
the
takeaway
here
the
last
topic
has
been
augmented
a
little
bit
from
some
feedback
from
ben.
The
question
was:
is
there
a
need
or
value
to
having
a
pki
extended
key
usage
allocated
for
in
somewhere,
another
dtn,
and
the
reason
for
this
is
currently
I
can
take
a
certificate
that
somebody
gave
me
issued
to
me
for
my
http
server
for
my
ldap
server
whatever,
and
I
can
repurpose
that
and
use
it
for
tcpcl
no
problem.
M
I
keep
my
host
name,
it's
the
same,
and
now
I'm
talking
tcpl
using
the
same
circ.
So
it's
a
question
of.
Is
this
a
desirable
behavior
and
the
the
following
question?
That's
not
on
this
slide
is,
and
I'm
I'm
going
to
be
doing
some
communicating
with
the
expert
on
the
oid
for
the
iana,
which
is
does
it
make
sense
to
have
two
different
levels
of
this?
G
M
The
way
the
protocols
make
use
of
this
kind
of
thing,
other
modern
protocols
is
to
say
if
the
certificate
does
have
an
eku,
it
must
be.
It
must
contain
this
value.
So
if
a
if
a
ca
just
says
you
are
a
valid
holder
of
this
name,
do
what
you
will,
then
that
will
be
accepted.
But
if
a
ca
says
you're
a
valid
holder,
this
name
and
it's
intended
to
be
used
for
ocsp.
M
M
The
way
that
it's
specified
or
the
way
that
it
is
or
will
be
specified
is
as
a
recommended
security
policy.
So
there's
the
requirements
are
if
the
security
policies
are
so
and
so
here's
how
you
act
and
then
there's
a
separate
statement
is
the
recommended.
Security
policy
is
x,
y
and
z,
so,
okay,
yeah.
A
B
Then
you
should
check
for
this
one,
but
we
don't
need
to
have
a
very
strong
requirement
that
if
you
have
a
certificate,
you
should
have
a
certificate
that
has
this
eka
value.
I
think
the
way
that
the
current
ecosystem
is
set
up.
It's
not
guaranteed
that
or
it's
not
necessarily
going
to
be
very
easy
to
get
a
certificate
that
has
this
particular
eku
value.
M
M
A
M
M
M
There
can
be
some
feedback
on
this,
for
if
this
makes
sense,
but
the
idea
is
that
the
structure
of
whether
it's
used
in
integrity
or
confidentiality
is
exactly
the
same.
What's
different
is
what
types
of
messages
will
be
embedded
in
the
results
so
having
one
context
or
having
two
contexts.
It
really
doesn't
structurally
change
what
is
being
represented
here,
but
the
idea
is
that
the
context
is
parameters
are
some
key
materials.
Public
key
materials
results
are
cosi,
messages,
an
integrity
result
either
has
a
mac
or
a
signature,
or
some
future
cosy
message.
M
That's
going
to
do
that.
Job
and
the
confidentiality
result
has
an
encrypt
message
in
it,
and
the
reason
for
cosi
itself
can
transport
public
keys
with
the
individual
results.
The
reason
for
having
them
in
security
parameters
is
that
if
I
choose
to
sign
every
single
block
in
my
bundle-
and
I
have
15
different
results-
I
don't
want
to
have
15
different
copies
of
my
public
key,
so
the
parameters
have
the
public
key
and
then
the
results
have
the
key
identifiers
that
reference
the
public
key.
M
So
it's
relatively
clean
in
that
structure
and
then
each
result
is
a
cosy
message,
and
this
is
dipping
toes
into
that
realm.
That
ed
had
mentioned
of
of
getting
into
a
little
bit
of
madness
of
of
structure.
Cosi
is
quite
vast
and
can
get
complex.
There
is
in
this
document,
if
you
flip
to
the
next
slide.
M
So
this
nails
it
down
at
least
to
a
realizable
and
implementable
set
of
things
that
you
can
do
and
also
restricts
that
you
can't
have
arbitrary
depth,
nested
messages,
all
kinds
of
complicated
stuff,
and
the
last
draft
also
has
examples
of
using
this
kind
of
stuff.
So
it
is
realizable
if
you
wanted
to
start
implementing
something
like
this.
The
good
news
is
that
the
cosi
ecosystem
is
is
present.
M
M
Then
this
is
similar
to
what
was
presented
for
those
interrelated
contexts
for
bp
sec
that
cosi
this
profile
requires
authenticated
encryption
with
additional
data.
It
requires
certain
structure
that
that
cosi
doesn't
mandate
about
all
this
context.
Data
that's
coming
out
of
the
bundle
that's
coming
out
of
the
primary
block
or
the
the
block
header
of
the
target
block.
M
The
one
last
statement
is
just
that:
kosi
natively
has
this
concept
of
a
protected
header
versus
unprotected
header.
What
gets
what
gets
secured,
what
gets
nailed
down
and
what's
not
what's
potentially
allowed
to
change,
and
this
carries
through
with
that
same
concept.
So
the
security
parameters
for
this
context
are
not
part
of
the
protected
data.
C
So
so
brian,
this
is
ed
a
couple
of
of
quick
things
number
one.
Thank
you
so
much
for
writing
this
up.
I
I
think
that,
having
more
than
one
security
context
and
showing
how
you
can
accomplish,
you
know
a
variety
of
things
with
the
security
context.
Concept
is
important.
It
also.
If
we
get
implementations
of
this
and
the
default,
we
can
start
doing
things
like
sizing
comparisons,
processing
comparisons,
how
easy
it
is
to
push
through
code
in
the
bpas.
C
The
last
is
there
is
a
draft
out
for
a
security
context
template,
and
it
might
be
a
good
to
look
at
how
you
formatted
this
document,
how
the
default
security
context
document
was
formed
to
see.
If,
if
we
can
then
work
together
on
what
would
be
a
good
template
to
to
give
to
other
authors
of
other
security
contexts
to
make
sure
that
the
information
is
presented
in
a
in
a
standard
digestible
way.
M
C
M
A
Okay,
thank
you,
brian
any
other,
any
further
questions
from
the
floor.
I'm
watching
the
clock
and
conscious
that
other
people
still
have
to
speak
thanks,
brian
right.
So
next
up
we
have,
I
believe,
fred
templin.
He
says
jumping
between
the
agenda
very
quickly.
No,
we
don't.
We
have
sarah
heiner
won
bp
sex
security
templates,
perfect.
N
N
So
we'll
start
with
the
discussion
of
security
policy
for
bpsac.
We
know
that
bpsec
enables
the
representation
of
a
security
operation
in
a
bundle
as
an
extension
block
and
there's
been
some
work
done
to
determine
what
the
life
cycle
of
an
extension
block
looks
like.
So,
you
may
have
seen
this
in
the
security
context
template
draft.
N
N
So
it's
not
enough
to
come
across
the
correct
cipher
suite
implementation
for
a
security
service.
We
also
need
the
policy
settings
to
be
correct
in
order
to
process
a
block
and
verify
the
security
service
that
it's
representing.
So
we
need
both
security
contacts
and
policy
in
order
to
derive
meaning
from
security
services.
N
Please
so
here
we're
moving
into
the
life
cycle
itself,
recall
that
bpsec
allows
both
a
security
operation
and
its
associated
security
context
to
be
represented
as
a
block
in
the
bundle.
So
that
means
that
we
can
establish
universal
policy
points
by
tracking
that
block
life
cycle,
which
is
what's
shown
here.
N
In
the
most
basic
case,
a
security
operation
would
encounter
four
events.
A
node
would
have
to
be
identified
as
the
security
source
for
that
operation.
It's
required
to
be
represented
in
the
bundle
it
would
then
move
to
being
successfully
represented
in
the
bundle
arrive
at
its
acceptor
and
then
be
subsequently
processed
and
removed
from
the
bundle.
A
A
Good
news,
fred,
so
a
little
point
of
order.
The
last
item
we
have
is
after
this
slide
is
a
demonstration
by
dave
from
apl
who
has
got
some
quite
fun
tools
for
playing
with
amp,
which
is
the
asynchronous
messaging
we're
gonna
run
along
on
this
session,
so
we'll
fix
we'll
get
dave
in
after
we
have
officially
finished
the
session.
So
just
our
intention
is
to
run
long.
A
O
O
O
Please
so
the
bp
convergence
layers
c,
such
as
ltp,
often
use
the
edp
transport
layer
to
break
bundles
into
segments
as
the
largest
atomic
block
of
data.
The
underlying
data
datalink
layers
must
deliver
it
as
a
single
unit,
and
it's
also
known
as
the
the
re-transmission
unit.
Each
loss
segment
must
be
retransmitted
in
its
entirety.
O
O
O
O
So
the
answer
is
that
some
operating
systems
support,
what's
known
as
the
send
multiple
message
system
call
or
send
mm
message,
and
that
allows
an
application
to
present
multiple
segments
to
the
kernel
in
a
single
system
call.
So,
for
example,
you
might
present
16
4k
byte
segments
instead
of
just
one
64
gigabyte
segment
and
that
enables
the
use
of
smaller
segments
without
increasing
the
number
of
system
calls.
It
provides
the
benefits
of
bursting
while
using
smaller
segment
size.
O
So
that
means
that
the
loss
unit
can
be
made
closer
to
the
re-transmission
unit,
so
that
loss
of
a
single
ip
packet
or
fragment
results
in
the
retransmission
of
far
less
data,
and
we
can
even
tune
the
amount
of
ip
fragmentation
allowed.
We
can
have
none
some
moral,
ip
fragmentation
or
lots
of
ip
fragmentation,
while
presenting
multiple
segments
in
a
single
system
called
produce.
A
burst
of
bursts
next
chart.
O
O
A
Thanks
fred,
I
was
on
mute.
Sorry,
that's
really
interesting.
I
I
have
one
quick
question
and
which
is
no
I'll.
Take
it
to
the
list
I'll
take
because
there's
purely
an
implementation
detail
to
do
with
linux
kernel
optimization,
but
so
that's
fine,
but
really
interesting
to
talk
about
the
re-transmission
and
packet
subdivision
that
that
hadn't
really
worked.
I
hadn't
hit
that
one.
That's
that's
really
interesting!
I'm
thank
you
for
that.
A
O
A
G
A
K
I've
talked
about
the
amp
me
tool,
which
is
a
prototype
experimental
tool
that
does
a
variety
of
things,
to
help
management
and
interfacing
with
network
manager.
So
I'm
going
to
show
off
a
couple
of
things
that
I
can
do.
It
also
is
a
prototype
of
showing
off
a
lot
of
things
that
we
could
do
with
the
ui
in
the
future,
with
many
stubbed
out
features,
so
the
main
functionality
of
it
is
taking
amp
messages
and
converting
them
between
various
formats,
so
over
here
I've
already
pasted
in
a
sample
uri
format.
K
K
K
K
So
well,
so
this
entire
interface
is
written
actually
in
javascript
right
now,
functionality
I
just
shown
was
running
entirely
in
the
browser,
but
it's
also
designed
so
it
can
run
in
node.js
via
the
command
line.
So
if
I
switch
over
here
and
scroll
up-
and
I
can
run
the
same
decommutation
in
the
browser
in
the
command
line.
I
K
K
K
K
K
I
gave
it
here
a
uri
format
of
a
control
and
it's
inserted
into
the
database
and
told
me
the
id
if
my
manager
was
actually
running
properly
right
now
it
would
parse
it
and
the
send
it
out
and
the
response
report
would
come
back
into
the
database
right
now.
My
connectivity
isn't
running
so
we
can't
see
the
report,
but
if
we
did,
there
is
also
a
show
script
here.
A
So
david,
as
I
understand
it,
this
is
effectively
a
a
a
prototype
of
functionality
that
that
one
would
have
in
a
networks
operations
center
for
managing
in,
in
the
loosest
sense,
a
series
of
devices
using
amp
for
for
management.
So
this
is
handling
and
decoding
the
messages
from
their
heavily
encoded
form
down
to
something
manageable
understanding.
The
reports
allowing
humans
to
understand
what
on
earth
is
going
on
and
and
see
the
traffic
flow,
as
well
as
the
the
data
itself,
is
that
right.
C
Forms
is
really
it's
really
interesting
work,
and
and
when
we
start
talking
about
the
concept,
what
does
it
mean
to
do
asynchronous
network
management?
You
know
the
the
ion
distribution
as
a
reference,
implementation
of
bundle,
protocol
and
dtn
protocols.
In
general,
you
can
use
amp
to
configure
and
run
ion
to
configure
security,
to
configure
ltp,
to
configure
ipn
and
naming
and
so
on
and
and
these
kinds
of
utilities
on
the
front
side.
C
A
Okay,
so
on
that
note,
I
think
we've
probably
got
to
call
it
then,
because
we
have
overrun.
Thank
you
very
much
all
the
presenters.
Thank
you
very
much,
all
the
attendees.
Whatever
your
time
zone,
I
appreciate
you
making
the
effort
yeah
so
we're
meeting
again
it's
a
virtual
interim
in
march
early
march.
I
think,
eighth,
ninth,
something
like
that.
We
haven't
got
dates
for
the
actual
dtn
session,
but
early
march
put
in
your
diary.
This
will
be
happening
again.
Please
look
at
the
drafts
that
are
in
iesg
review.
A
Please
keep
an
eye
on
the
discuss
resolutions
that
are
happening.
Please
get
feedback.
Please
provide
feedback
to
the
authors,
because
without
confirmation
from
the
working
group,
the
authors
aren't
100
sure
that
they
are
reflecting
the
opinions
of
the
working
group
and-
and
these
are
working
group
documents.
Otherwise
ed
do
you
want
to
add
any
final
words.
C
A
I
think
that,
oh
yes,
one
last
thing.
Obviously
we
now
have
a
secretary
slot
open.
I
will
put
a
message
on
the
mailing
list
about
this
as
well,
but
if
you'd
like
to
put
your
name
forwards
for
working
group
secretary,
we
would
be
very
interested
to
hear
from
you
otherwise
enjoy
the
rest
of
your
day
night,
whatever
it
is
wherever
you
are
and
thank
you
very
much,
I
think
that's
it.