►
From YouTube: IETF99-DTN-20170717-0930
Description
DTN meeting session at IETF99
2017/07/17 0930
https://datatracker.ietf.org/meeting/99/proceedings/
B
D
You
SEC
PCL,
we
put
previously
a
you
know
a
free
transfer
discussion
there,
but
we
found
that
in
anyway,
forgiveness
passed
in
the
first
application
by
step.
So
essentially
it's
definitely
remove
this.
Then
that
I
can
remember
this
during
the
first
invasion
by
staff
who
shoots
in
en
PMA
architecture
enough.
D
D
C
Eadie's
pointed
out
that
he
doesn't
have
new
slides
for
the
asynchronous
management
architecture
presentation.
He
basically
wants
to
cover
some
of
what
he
would
like
to
propose.
So
I,
don't
really
hasn't
done
any
new
slides
because
we've
done
all
the
slides
for
30
seconds
there,
so
we
should
be
very
short
pieces.
Most
of
us
are
familiar
with
what
in
for
voting
anyway.
So
it's
more
the
discussion
and.
E
C
Okay,
so
if
you
look
at
the
DTM
data
track,
though
you
can
see
that
we
have
a
set
a
milestone
for
Joe
charted
items
and
of
the
work
that
is
currently
actively
in
progress.
Apparently
we
were
going
to
finish
50-50
place
and
TCP
CLV
fall
by
December
2016.
Now,
obviously
that
hasn't
happened.
These
milestones
aren't
fixed
in
stone,
they're
aspirational,
but
obviously
we
are
slipping
on
this
and
the
face
the
ad
they
like
to
point
out
that
this
is
a
surprise
to
him.
C
For
some
reason,
the
main
point
of
this
slide
is
not
to
say:
oh,
my
god
were
slipping
on
this.
It's
it's
the
point
out
that
these
are
key
items
that
we're
still
working
on,
and
there
is
some
pressure
to
make
progress,
because
if
you
look
at
the
next
slide,
these
are
some
of
the
other
items
that
we
have
on
the
Charter
that
are
are
hanging
waiting
for
the
core
building
blocks
to
complete.
So
there
is
some
pressure
to
the
primary
authors
and
the
working
group
to
really
get
going
back
on
slide.
C
It's
the
Barbie.
We
have
a
wavy
main
projector
for
noticin
and
we
need
to
get
50/50
base
and
TCP
CLV
floor
done.
They
feel
in
lasts
more
once.
They've
dropped
out
of
last
wall
and
lighter
changes
at
the
working
group
and
the
main
author
team
have
wanted
to
make,
which
is
fine.
We
do
need
to
get
these
finished
so
that
less
of
a
demand
on
the
or
between
it's
more
of
a
demand
on
the
rest
of
the
work.
Really
please
have
a
look
at
these
documents.
Give
them
an
even
a
a
light
review.
C
I'm
looking
at
some
of
the
younger
guys
in
the
room
which
one
of
the
old
hands
and
say
have
read.
If
there's
stuff,
you
don't
understand,
if
you
could,
if
you
don't
see
why
it's
there,
please
ask
it
may
be
an
omission,
then
may
be
a
valid
reason
for
it.
But
a
good
bit
of
discussion
on
this
is
productive
at
this
stage,
and
then
we
can
put
it
back
up
the
RFC
view
and
really
get
these
moving.
The
other
two
items
at
the
bottom
of
slide
has
to
be.
C
Obviously,
stop
is
going
to
talk
about
the
sticking
out
of
trust
to
be
out
of
the
450
15
s
that
what
I
can
imagine
we'll
take
a
compare
amount
of
time
this
morning
and
the
other
thing
that
came
up
over
the
last
two
meetings
was
bundled
security
protocol
is
relevant.
In
this
context.
It
may
not
be
applicable
to
all
the
users
of
undal
protocol.
C
The
proposal
is
that
under
security
protocol
acts
other
than
the
B
team
set
into
the
name,
so
that
is
another
critical
early
delivery.
From
from
this
working
group,
though,
and
given
its
security
related,
that
needs
some
federal
review
if
there
needs
to
be
some
visible
comment
on
that
document,
I
know
it's
being
reviewed
in
other
places
from
the
IDF,
but
we
do
need
to
good
feedback
from
the
IDF
themselves.
Otherwise,
if
this
started
after
the
security
groups,
they'll
say,
okay,
you
say
it's
been
reviewed.
We
see
no
evidence
of
that.
C
C
These
are
the
next
items
charter
items
that
we
have
not
really
started.
Working
on,
I
know,
there's
various
within
the
room
who
have
opinions
and
some
ideas
and
labor
discovery
have
knocked
up
draft.
So
far
on
things
like
key
management,
have
you
managed
ETA,
Mises
and
I
know
it's
gonna
speak
about
an
architecture.
He's
had
pick
around
for
a
while,
there's
also
addressing
enough
in
a
wider
scope
howdy.
How
do
we
handle
multiple
addresses
for
multiple
DTN
domains?
Are
we
going
to
try
to
force
a
single
naming
scheme?
C
There's
a
pinging
circulating
on
this,
but
they
all
need
really
be
the
bits
finished.
We
need
the
basic
building
blocks
in
place
so
that
we
can
build
on
them.
So
yeah
they've
got
early
2017
dates,
it's
not
happening,
but
you
need
to
be
aware
that
these
are
milestones
that
you
have
to
deliver.
But
does
anyone
have
any
comment
about
the
fact
that
we
are
delayed.
F
F
Schiaparelli,
just
one
point
that
I
will
bring
up
now
and
not
emphasized
later
on,
which
is
that
bundles
and
Bunnell
encapsulation
and
VP
SEC
are
not
alternatives.
Bundle,
mone,
encapsulation
security
depends
on
VP
SEC
existing.
So
it's
it's
not
like
it.
It
it's
supplants
it
in
any
way.
Dp
SEC
is
required.
In
any
case,
it's.
F
All
right,
thank
you,
I'm
Scott,
Burley
I'm,
here
to
talk
about
a
couple
of
things:
the
latest
draft
of
the
beef
abyss
specification
and
and
as
as
part
of
that,
a
discussion
of
custody
transfer
and
and
a
way
that
we
might
separate
custody
transfer
from
from
the
bundle
protocol
itself.
So
next
slide.
I
think
this
is
the
the
only
slide
on
on
BP
is,
which
is
essentially
that
the
seventh
draft
of
the
specification
was
posted
in
middle
of
June.
F
F
In
running
down
good
references
and
anybody
who
is
able
to
do
that,
I
think
there
was
some
traffic
on
the
net
about
some
possible
references
and
I'm
happy
to
take
that
and
incorporate
that
into
the
spec
and
just
an
oversight.
I
stupidly
failed
to
move
the
CRC
to
the
end
of
the
canonical
block
header,
and
that
was
just
an
oversight
that
I.
H
F
Fix
that
also
I
think
there
were
a
couple
of
small
comments
that
came
in
on
on
the
email
list
in
the
last
couple
of
weeks
and
those
I'm
quite
happy
to
incorporate.
So
at
this
point,
I
believe
the
the
sevenths
are
after
the
BP
piss
Peck
is
reflects
everything
that
we
had
agreed
on.
In
addition
to
that,
it
reflects
what
I
think
is
a
was
a
tentative
agreement
to
extract
custody
transfer
from
the
bundle
protocol
spec
itself
and
and
define
it
in
a
separate
document.
F
There
are
a
couple
of
ways
that
we've
discussed
doing
that
one
is
retaining
custody
transfer,
as
as
an
extension
block
and
and
as
a
set
of
modifications
insertions
that
would
go
into
the
bundle
protocol
specification
itself
in
several
places
and
I
think
three
or
four
months
ago
we
posted
a
sample
draft
of
how
we
might
do
that
sometime
after
that
draft
went
out,
it
occurred
to
me.
Oh
I,
think
I've
got
a
better
way
of
doing
it.
I
think
we
could
do
it.
F
F
This
idea
went
out
in
a
draft
that
I
posted
under
my
own
name
rather
than
the
working
group
name,
because
it's
really
it's
just
me
thinking
out
loud
at
this
point
and
the
idea
is
move
custody,
transfer
out
of
bundle,
protocol
and
standardize
bundle
and
bundle,
encapsulation
and
and
make
custody,
transfer
a
feature
of
bundle
and
bundling
capsulation.
Since
the
idea
of
making
custody
transfer,
reliable
convergence
layer
protocol
entailed
encapsulating
in
bundles
anyway
and
it
dawned
on
me,
I
want
to
combine
the
two
things.
F
F
F
The
the
the
one
is
that
custody
transfer
reliability
relies
on
retransmitting
the
entire
bundle,
no
matter
how
big
it
is
rather
than
portions,
of
the
bundle
and
another
is
that
that
retransmission
is
driven
entirely
by
expiration
of
timeouts,
and
the
the
timeout
interval
is
something
that
is
I
will
argue
impossible
to
calculate
in
the
RFC
50/50
world
because
custody
transfer
it
no
node
is
required
to
take
custody
transfer.
So
you
don't
know
which
node
is
supposed
to
acknowledge
it.
F
So
you
have
no
idea
how
long
it'll
take
for
the
bundles
to
reach
that
node
and
come
back
again.
So
any
thing
that
you
do
in
in
in
in
custody
transfer
an
IRC
5050
in
terms
of
retransmission
is
is
by
definition
you
know
less
than
then
efficient
it'll.
Always
we
transmit
either
too
early
or
too
late,
because
you
can't
do
it
accurately.
I
think
that
for.
F
I've
been
saying
for
a
long
time,
just
use
reliable
convergence.
There
are
protocols
instead
and
I.
Think
that
is
still
the
case,
but
Keith
Scott
has
made
the
point
a
number
of
times
that
there
are
use
cases
where
nothing
but
custody
transfer
can
do
the
job
because
the
there
there
is
no
reliable
convergence
there
protocol
available
for
some
of
the
use
cases
he's
been
looking
at.
You
really
need
a
reliable
converters
there,
a
protocol
that
handles
transmission
over
inter
directional
and
possibly
disrupted
links
and
nothing
but
custody
transfer
does
that.
I
Have
a
semi
semantic
question?
Yes,
it
occurs
to
me
that
TCP
in
the
especially
when
you
look
at
the
end
to
end
model
of
the
internet,
secures
bytes
on
the
wire,
but
doesn't
do
anything
how
they
are
being
handled
at
the
receiver
side.
So
it's
a
reliable
transfer.
It's
not
a
reliable
pick
up,
storage
and
whatnot,
and
so
so
comparing
custody
transfer,
which
also
says
something
about
durability.
I
But
also-
and
so
it
also,
it
is
supposed
to
guarantee
us
that
you're
going
to
have
enough
space
ever
having
received
something
reliable
and
keep
it
so
I'm
not
worried
about
the
security
yeah
I
read
about
the
the
reliability
part
in
storage.
So
if
you
get
the
next
bundle
you
and
if
you
have
taken
custody,
you
can't
evict
it
and
drop
it
on
the
floor
because
you
have
taken
custody.
I
Where
is
just
the
fact
that
you
have
received
something
reliably
completely
and
so
on
still
would
allow
you
to
drop
it,
and
this
is
the
semantic
difference.
I'm
wondering
and
I
just
well
I'm,
not
saying
that
this
is
bad
to
combine
the
two
I'm
just
wondering
whether
this
is
happening
in
intentionally,
whether
we
should
spell
this
out
jail.
F
That
there
is
that
implication
and
and
I
think
we
should
confront
that
implication
and
and
and
and
make
sure
that
we
understand
the
what
what
would
evolve
from
that
I
mean
I,
think
we
need
to
be
aware
of
it.
Absolutely
right,
so
so
this
this
first
point
on
this
slide
is
again
thinking
in
terms
of
the
many
conversations
that
the
Keith
and
I
have
had
on
on
custody
transfer
and
how
he
has
use
cases
that
absolutely
need.
It
I
believe
that
this
formulation
preserves
that
capability.
F
That
is
the
idea
here
is
that
when
you,
what,
when
you've,
got
a
portion
of
the
into
NDT
and
network
path
that
cannot
be
traversed
successfully
by
any
any
of
the
reliable
convergence
layer,
protocols
that
we've
defined
so
far,
tcp,
CL
or
LTP
or
others
that
that
encapsulating
the
bundle
in
another
bundle
whose
destination
is
the
the
convergence
layer
next
hop
provides
that
capability.
It
enables
the
the
transmission
on
on
that
that
segment
of
the
path
to
be
unidirectional
in
in
each
direction,
to
follow
different
paths
and
and
for
the
the.
F
The
transmission
between
the
two
to
be
over
links
that
are
intermittently
connected
and
possibly
very
long
delay,
so
I
think.
That's
that
that's
the
number
one
advantage
I
see
is
that
the
the
advantages
of
custody
transfer
are
retained
in
context.
That
I
think
makes
sense
in
the
overall
DTN
architecture.
F
The
second
advantage
that
I
see
is
that
removal
of
custody
transfer
from
bundle
protocol
and
substantially
simplifies
bundle,
protocol
and
simplifies
implementations.
There
will
be
potentially
some
implementations
that
would
not
want
to
support
custom
transfer
and
and
or
might
might
want
to
not
support
it
initially,
but
add
it
later
on
and
I
think
this
structure
supports
those
those
kinds
of
implementation
efforts,
I'm
thinking
in
particular
of
hardware
implementations
or
firmware
implementations,
where
the
complexities
of
custody
transfer
might
be
difficult
to
support,
at
least
in
in
an
initial
round
of
FTA.
Is
that
sort
of
thing.
F
The
the
interface
I
think
is
is
quite
clean
here,
in
that
the
the
the
bundle
and
bundle
bundle
and
bundle
encapsulation
protocol
is
is
a
self-contained,
I
think
well
structured
specification
within
which
custody
transfer
operates,
but
without
relying
on
inserting
any
new
procedures
into
bundle
protocol
itself.
The
the
end
points
of
the
custody
transfer
are
our
functionally
convergence
layer
end
points,
even
though
they
happen
to
be
bundle.
Protocol
end
points.
It's
it's
tunneling.
F
An
advantage
I
think
that
is
less
obvious,
is
that
we've
been
thinking
about
bundling
bundle
encapsulation
for
a
long
time
as
a
mechanism
that
supports
an
additional
layer
of
security,
for,
in
particular,
security
against
protection
against
traffic
analysis,
and
that's
because
the
the
encapsulated
bundle
can
be
encrypted
as
the
payload
of
the
encapsulating
bundle
and
the
destination
of
the
encapsulating
bundle
can
be.
You
know
anything
at.
G
F
H
F
It
over
or
a
longer
time
and
had
been
in
lurking
in
custody
transfer
in
RFC.
Fifty
fifty
all
along
that
it
was
always
going
to
be
a
huge
problem
if
there
were
fragmentations
of
custodial
bundles
on
the
end
and
paths
we
had
no
way
of
dealing
with
it,
it
just
wasn't
even
considered
in
RFC.
Fifty
fifty
and
one
way
or
another
is
going
to
be
a
huge
problem.
F
Well,
this
makes
that
go
away,
because
if
there's
fragmentation
between
the
source
and
destination
of
the
convergence
layer
of
bundle
and
bundle
encapsulation
transmission,
that's
not
a
problem,
because
the
by
definition
the
the
bundle
has
to
be.
We
assembled
from
fragments
at
the
destination
and
no
matter
what
what
the
fragmentation
was.
F
F
F
Multi-Point
delivery
of
custody
transfer
is
undefined.
Well,
there's
good
reasons
for
that
right
because,
if
you,
if
you
go
with
the
the
original
RC
50/50
definition
of
custody
transfer,
if
there
were
multiple
possible
custodians,
custody,
acknowledgments
would
be
received
from
multiple
places
and
the
current
custodian
would
have
no
way
of
knowing
which
ones
are
sufficient
to
authorize
deletion
of
the
the
bundle
that
has
taken
custody
of
it.
The
there
there
might
be
multiple
possible
custodians
that
that
refuse.
There
might
be
multiple
possible.
F
Considering
this
that
receive
it
and
don't
say
anything
at
all,
and
the
the
current
custodian
has
no
way
of
knowing
anything
about
how
many
copies
it
needs
to
resend
in
in
this
formulation.
That
goes
away
entirely,
because
if
there's
a
multi
point
delivery,
then
each
of
those
points
each
of
those
neighbors
that
you
would
forward
the
bundle
to
can
be
a
custodian
you
you
send
it
custodial
e
over
over,
because
convergence
layer,
hop
that
happens
to
be
bundle.
F
Protocol
called
the
ib
e
and
and
each
one
of
those
transmissions
is
a
separate
custodial
transaction
and
and
is
booked
kept
because
individually
in
the
implementation.
So
suddenly
we
gain
the
ability
to
do
custody
transfer
through
a
multicast
tree,
because
each
of
the
branches
of
the
multicast
tree
is
its
own
custodial
transmission.
F
F
There
are
a
couple
of
disadvantages
that
that
I
think
we
all
need
to
be
aware
of
and
and
and
spend
some
time
talking
about.
One
is,
there
is
a
little
bit
of
extra
overhead
because
you
encapsulate
the
the
original
bundle
in
in
another
bundle,
and
that
means
that
there's
a
another
header
primary
block
and
extension
blocks,
but
onto
the
front
of
it,
I'm
very
sensitive
to
overhead.
We
care
about
that
a
lot
in
in
in
spaceflight
operations,
communications.
F
We
don't
have
an
awful
lot
of
spare
bandwidth,
but
even
even
given
that
I
would
say,
as
long
as
the
bundles
are
not
tiny,
the
the
additional
overhead
is
as
a
tolerable
cost.
I
think
the
advantages
are
compelling
enough
to
to
motivate
using
this
formulation.
Even
when
there's
a
concern
about
overhead
and
the
other
is
and
I'm
sure
this
is
I'm,
accompanied
in
discussion
there.
F
My
own
personal
expectation
is
that
in
realistic
operational
use
cases
you
pretty
much
always
know
who
you
want
the
next
custodian
to
be
I.
Think
in
all
of
the
the
use
cases
that
Keith
has
identified,
for
example,
the
the
next
custodian
is
known.
It
may
be
two
or
three
bundle
hops
away,
but
but
you
know
you
do
know
who
you
want
it
to
be?
If
you
genuinely
don't
know
who
you
want
to
take
custody,
then
again,
I
will
argue.
F
If
you
don't
know
who
you
want
to
take
custody,
then
you
have
no
way
of
knowing
when
to
be
transmitted
and-
and
in
that
case,
I
I
think
it's
I
think
I
would
argue
that
the
potential
impact
on
never
performance
is
I
would
say
not
acceptable,
but
that's
a
that.
That's
my
own
personal
opinion
on
it.
I
would
say
that
opportunistic
forwarding
is
not
necessarily
incompatible
with
this
formulation,
because
in
opportunistic
forwarding
I
will
I
will
propose
that
the
next
custodian
is
always
the
neighbor
right.
F
You
discover
a
neighbor
and
you
want
to
do
custody
transfer
out
to
the
destination
great.
The
next
custodian
is
the
neighbors
you've
just
just
discovered.
If
they
don't
want
to
take
custody,
then
it's
not
clear
that
you
want
to
send
them
a
copy
if
you,
if
you
want
to
send
them
a
copy,
any
way
you
can
and-
and
in
that
event
you
maybe
don't
want
to
turn
on
the
custodial.
Retransmission
switch
I.
F
The
advantage
of
being
able
to
do
somewhat
reliable,
custodial
retransmission
by
knowing
the
who,
the
next
custodian
is
and
knowing
the
round-trip
time
on
that
basis,
outweighs
the
advantages
of
being
able
to
operate
in
an
environment
where
the
next
custodian
is
unknown.
I
think
that's
the
end
of
my
slides
and.
D
D
D
D
Okay,
but
then,
if
it's
a
you
know
for
it
well,
but
you
said
summarizes:
they
only
have
really
one
pursuit
in
my
network,
but
if
I
want
to
use
many
because
I
mean
it's
a
very
unreliable
path
and
it
may
take
forever
between
whatever,
for
whatever
reasons
my
question
is,
how
does
so?
No
two
will
actually
D
capsulate
Andrea
encapsulate
right.
Yes,
so
how
does
node
one
tells
no
2?
No
3
is
the
next
one
or
it
doesn't
know
well.
F
It
can
be
argued
that
it
should
not
tell
node
2
that
right
because
right
because
its
source
routing-
and
maybe
that's
not
a
good
idea,
the
other
is
that
if
it
really
wants
that
to
happen
and
and
I
think
we
should
thank
Lord
wood
for
pointing
this
out
on
the
email
list.
You
can
do
that
right,
because
node
1
could
encapsulate
capsulate
the
original
bundle
in
a
bundle
that
isn't
in
it.
That
is
whose
destination
is
node
3
and
then
take
that
and
encapsulated.
F
F
J
John
that'll
thanks,
Scott,
really
interesting.
My
initial
reaction
of
oh,
you
want
to
psych
Casta
transfer
out
of
50
50
bits.
Great
put
it
in
bundling
bundle,
not
convinced,
but
you
make
some
interesting
arguments
there.
Do
you,
in
in
in
the
world
of
opportunistic
forwarding
I'm
keen
to
be
able
to
move
custody
in
more
than
one
direction?
Yes,.
F
F
F
F
Absolutely
does
yes
and
I
would
say
it.
Does
that
because
suppose
you're
sending
four
different
copies
right,
you
send
one
opportunistically
and
you
may
not
think
you
may
not
get
there
may
or
may
not,
so
you
so
you
hold
on
to
the
bundle
and
you're
going
to
send
it
again.
The
next
discovered
neighbor
on
each
of
those
transmissions
to
each
of
those
neighbors.
As
you
discover
them,
I
would
say
on
each
one.
F
You
would
do
a
custodial
bundle,
bundle,
encapsulation
transmission
to
that
to
that
custodial,
node
and,
and
that
node
itself
then
would
extract
the
encapsulated
bundle
from
the
encapsulating
bundle
and
could
determine
on
its
own
whether
the
next
hop
on
on
its
path
to
the
destination
needed
to
go
over
a
bundle
encapsulation
or
it
could
just
be
sent
over
some
other
reliable
convergence.
Their
protocol,
okay,.
J
Thank
you,
and
thus
last
one-
and
you
said
a
couple
of
minutes
ago
that
I
recently
had
this
in
my
head,
as
though
all
nodes
of
the
network
need
to
support
custody
transfer.
I
think
you
mentioned
a
couple
of
minutes
ago
that
you
could
send
more
than
one
bundle
hop
away
and
get
the
distant
mode
to
accept
custody.
Yes,
is
that
correct?
That's.
G
C
H
C
C
J
Hang
on
yeah
John
Darrell
as
JavaScript
adds
asking
a
question
at
brain
in
VP.
Second,
we
had
difficulty
with
security
destinations
because
it
presupposed
routing
information.
If
you
select
a
custodian
that
is
more
than
one
hopper
way,
will
we
run
into
the
same
problems
as
when
we
try
to
define
security
destinations?
Alright,.
F
That's
a
fair
question:
I
think
we
don't
the
reason
I!
Think
we
don't
is
that
because
we're
doing
this
is
because
at
the
convergence
layer,
the
the
the
route
from
the
the
current
custodian,
the
local
custodian
of
the
bundle
and
the
next
custodian
can
be
entirely
defined
by
the
routing
protocol
right,
the
the
the
the
route
that
it
if
you're
going
from
from
A
to
D
and
and
there
are
bundle
routes,
bundle
nodes
in
between
the
convergence
there.
F
F
F
The
the
the
convergence
layer
transmission
is
is
something
that
we
already
have
in
in
the
in
the
architecture.
I
think
it's
a
clean
separation
between
the
what
essentially
is
is
end
to
end
at
the
convergence
there
and
and
the
route
that
it
the
bundle
takes
to
get
from
one
end
to
the
other.
At
the
convergence
layer.
C
F
B
F
C
C
J
John
daddle
just
a
point
of
order
really
I
suppose
so,
as
you
mentioned
just
now,
I
think
somebody's
going
to
do,
but
gonna
want
to
do
bundling
model
anyway.
Personally,
I
think
this
is
worthy
of
working
group.
Adoption
anyway,
question
is:
does
it
have
to
be
absolutely
perfect
before
the
working
group
adopter
I
would
suggest
not.
C
K
B
B
C
K
Hi,
my
name
is
Ed
borane
I'll
be
presenting
the
BP
SEC
updates.
This
would
be
the
low
five
version
of
BP
sac
and
we
talked
about
the
O
four
version.
Last
time
we
received
a
couple
of
comments
in
the
meeting
and
then
I
received
a
few
comments
directly
since
the
meeting
some
got
rolled
in
to
the
O
five
and
some
didn't
and
I'll
address
the
ones
that
didn't
get
in
before
we
had
to
upload
the
latest
version
next
slide.
K
C
K
So
let
me
start
I
have
a
couple
of
slides
of
summary
and
then
the
updates
from
oh
five
and
then
the
outstanding
comments
and
then
addressing
the
cipher
suites.
So
if
we
go
to
the
next
slide,
the
next
slide
so
the
so.
This
summarizes
the
major
points
of
the
BP
SEC
approach.
The
first,
of
course,
is
the
motivation.
Why
do
we
feel
we
need
a
BP
SEC
protocol?
K
Bp
SEC
is
meant
to
be
an
in
bundle,
security
mechanism.
What
this
means
is
for
the
cases
where
different
blocks
inside
of
a
bundle
need
different
security
services,
and
this
is
to
try
and
recognize
the
fact
that
sometimes
not
all
blocks
are
put
in
a
bundle
by
a
single
source
or
when
they
are
put
into
a
bundle
by
a
single
source.
K
They
may
represent
different
kinds
of
information,
and
a
classic
example
is
a
case
where
a
user
would
want
a
payload
block
to
be
encrypted
but
may
want
other
extension
blocks
to
only
be
integrity
signed
so
that
others
along
a
path
could
look
at
them.
The
reason
we
bring,
we
point
that
out
is,
if
you
don't
want
in
bundle
security.
There
are
other
ways
of
trying
to
secure
BP.
Of
course,
users
can
protect
their
own
data
at
the
application
layer
and
give
cipher
text
or
payloads
that
have
already
been
capsulated
using
other
standards.
F
Just
a
comments,
copper,
Lee
and
I
wanted
to
add
an
additional
note
on
motivation,
which
is
protection
of
data
at
rest.
If
you're
doing
multi
hop
transmission
and
the
data
resides
in
in
in
the
bundle
MO
somewhere
along
the
end
and
path,
III
will
contend
that
it
needs
to
be
secured.
While
it's
sitting
on
that
node,
rather
than
only
while,
it's
in
transmission
between
nodes.
K
So
if
we
take
that
as
sort
of
some
of
the
driving
motivations
for
the
document,
the
next
thing
the
document
talks
about
are
what
are
the
design
decisions
around
BP
sac.
The
major
ones
that
came
out
was,
of
course,
that
different
blocks
in
a
bundle
can
and
should
have
different
security
that
the
processing
order
of
those
blocks
at
the
various
receivers
must
be
unambiguous
and
that
we
must
be
able
to
add
new
cipher
suites
at
future
dates
as
more
come
available.
Next
slide.
K
So
so,
then
the
the
spec
goes
into
what
does
it
actually
mean
to
have
security
inside
of
a
bundle
and
to
do
that?
We
use
extension
blocks
to
house
security
mechanisms
in
that
we
have
a
confidentiality
mechanism
and
an
integrity
mechanism.
We
decided
some
meetings
ago
not
to
have
a
separate
authentication
mechanism,
there's
a
fair
bit
of
treatment
in
that
in
the
document,
and
we've
also
made
it
a
topic
of
at
least
two
or
three
working
groups
in
the
past.
So
for
the
blocks
that
we
define,
we
have
a
block
format.
K
What
we
call
an
abstract
security
block,
which
was
a
concept
kept
from
from
the
original
BSP
and
and
that
abstract
security
block
is
recognizing
the
fact
that
all
of
all
of
the
two
security
blocks
that
we
use
in
this
back,
while
the
the
BI
be
for
block
integrity
block
and
the
BC
be
for
block
confidentiality
block,
have
a
fair
bit
in
common.
They
both
capture
the
list
of
targets
to
which
they
apply.
K
They
both
capture
sort
of
that
key
information,
is
part
of
cipher
suite
configuration
and
they
can
both
hold
extra
data
associated
with
the
results
of
applying
the
cipher
suites.
The
block
integrity
block
itself
holds
a
signature
or
signatures
across
the
set
of
targets
that
it
applies
to,
and
the
confidentiality
block
notes
that
its
targets
have
had
their
block.
K
Data
replaced
with
the
results
of
an
encrypting
cipher
suite
and
the
confidentiality
block
may
also
carry
any
additional
results,
such
as
additional
authenticated
text
that
that
is
beyond
just
the
cipher
text
that
would
be
produced
by
a
confidentiality,
encrypting,
cipher
suite.
So
then,
another
interesting
part
about
the
block
format
was.
We
did
come
back
and
make
an
optimization
several
working
groups
ago.
K
We
did
originally
have
a
concept
of
a
separate
CMS
block
in
BP
sack
through
through
significant
discussion
in
this
working
group
and
in
some
other
groups.
We
said
that
that
was
probably
not
something
that
we
were
going
to
pursue
in
the
core
BP
sac
document,
and
we
created
a
section.
That
said,
if
other
specifications
wanted
to
define
new
kinds
of
security
blocks,
there
were
certain
considerations
that
needed
to
be
put
in,
so
that
new
security
blocks
would
be
compatible
and
could
coexist
with
the
security
blocks
in
this
document.
K
Finally,
there
was
a
section
of
block
processing
rules.
Again,
determinism
is
important
here
there
were
many
cases
in
the
original
BSP
where
we
lost
Turman
ism,
and
we
wanted
to
make
sure
that
we
didn't
have
that
issue
again.
So
there
were
some
rules
there
in
terms
of
if
a
BCP
target
is
encrypted
than
integrity
on
that
target.
If
there's
integrity
on
that
target,
it
must
also
be
encrypted
bibs,
don't
target
B,
C,
B's
or
blocks
protected
by
BCPs
to
avoid
circular
dependencies.
K
If
you
do
those
kinds
of
things
than
at
a
receiver,
you
can
come
up
with
a
strict
processing
order
for
security
blocks
and
that's
something
that's
helpful
next
slide,
and
so
then,
as
we
finish
up
some
of
these,
we
we
come
back
and
say
that
we
really
don't
want
to
apply
security
directly
to
bundles,
whose
payloads
represent
fragments.
In
that
case,
we
would
recommend
some
kind
of
encapsulation
mechanism
such
as
bibby.
K
If
you
want
to
turn
that
fragment
into
a
non
fragment
block
by
encapsulating
it
implying
security
services
to
it
and
then
finally
nodes
themselves
determined
by
security
policy
if
they
are
the
destination,
as
we
mentioned
just
prior,
there
were
concerns.
If
a
source
node
tries
to
assert
a
security
destination,
because
that
starts
implying
routing
decisions
at
the
bpa
layer
itself,
it
is,
it
is
better
to
have.
The
individual
receivers
determine
whether
they
feel
that
they
are
the
security
destination
and
should
be
processing.
These
blocks.
K
K
So
in
general,
there
were
some
minor
editorial
cleanup
through
the
sections.
If
you
do
a
diff
between
a
4
and
a
5,
you
will
see
some
some
wordsmithing
and
some
correction
of
grammar.
The
major
updates
are
in
section
3.5,
the
block
representation.
We
did
add
something
that
was
missing,
which
is
to
really
just
explicitly
state.
You
can't
have
duplicate
targets
in
a
target
list
for
a
vib.
K
We
then
added
some
an
illustration
for
both
how
we
think
cipher,
suite
parameters
and
security
results
as
fields
would
be
represented
in
the
security
block,
one
of
the
things
that
we
and
then
we
referred
to
section
310,
which
we
talked
about
on
the
next
slide
in
terms
of
how
those
would
be
populated
next
slide,
please
so
on
the
when
section
310.
Originally,
we
had
put
into
the
BP
sac
document
the
list
of
the
list
of
common
security,
cipher
parameters
and
result
IDs,
and
one
of
the
comments
that
we
got
back
was
really
BP.
K
But
essentially
what
it
is
saying
is
that
a
bi,
b
or
b
c
b
block
must
have
something
in
it
and
as
part
of
the
block
format.
That
says
this
is
the
cipher
suite
that
we
are
using
and
then
the
parameters,
the
key
information,
the
result
IDs
that
are
associated
with
that
cipher
suite
the
identification
of
them.
How
they
are
see,
bore
encoded.
How
they
should
be
interpreted,
is
really
up
to
the
cipher
suite
definition
itself
and
isn't
something
that
we
would
put
as
a
registry
in
BP
sack
next
slide.
K
We
removed
the
conformance
section,
which
was
section
11
in
Oh.
For
the
the
only
text
of
the
conformance
section,
there
was
that
some
thought
should
be
given
to
authentication.
We
didn't
think
that
that
sentence
or
two
really
warranted
a
whole
section
in
the
document
for
the
IANA
considerations.
We
will
need
a
registry
for
cipher
suite
identifiers
and
we
do
need
to
allocate
block
types
for
bi,
b
and
b
c
b,
and
then
we
added
a
reference
for
Co
C
at
the
end
next
slide.
K
So
so
what
we
have
presented
in
terms
of
updates
were
the
requested.
The
observed
changes
from
the
last
working
group
and
from
some
review
that
did
not
get
to
the
list
and
I'm
encouraging
reviewers
to
post
to
the
list
after
fo
v
was
posted
for
this
working
group.
We
did
get
some
additional
comments,
which
I've
listed
here
and
I
think
that
author
will
also
be
posting
this
week
to
the
Tamilian
list.
To
start
the
discussion.
Not
none
of
the
issues
that
came
back
were
really
particularly
significant.
K
There
were,
there
was
some
discussion
that
says
even
the
reduced
discussion
in
310
about
how
cipher
suite
parameters
and
results
are
stored
would
be
too
much
and
couldn't
be
piece.
X
simply
say
that
the
the
block
in
that,
in
that
scenario,
is
really
opaque
and
then
it's
completely
up
to
the
cipher
suites
as
to
how
they
populate
it
and
and
is
the
concept
of
cipher
suite
parameters
versus
security
results
itself.
Presupposing
a
design
of
the
cipher
suite,
and
we
can
certainly
look
at
that.
K
There's
an
assertion
that
sign
in
a
crypt
implies
a
certain
level
of
security
strength,
essentially
that
an
attacker
cannot
successfully
modify
a
bundle
if
they
cannot
decrypt
the
bundle
and
that,
if
you
really
were
to
split
hairs,
there
are
some
people
who
would
come
back
and
say:
that's
really,
maybe
not
always
the
case
and
instead
maybe
the
appropriate
security.
Verbage
is
that
you
require
an
IND
CCA
encryption
scheme
and-
and
there
are
some
other
text
associated
with
that-
which
again
we
would
put
up
to
the
mailing
list.
K
One
of
the
things
that
was
brought
up
at
the
last
working
group
was
that
BP
SEC
could
go
forward
in
its
current
form,
but
would
require,
at
the
very
least,
an
interoperability,
cipher,
suite
and
so
I
have
posted
a
a
draft
cipher
suite
that
says
here
is
a
common
integrity
and
a
common
confidentiality
cipher
suite
that
should
be
used
for
BP
SEC
for
interoperability.
We
picked
something
that
was
relatively
simple,
not
certainly
as
simple
as
something
like
H
much
sha-1,
but
H
Mac,
sha-256
and
AES
GCM
128
are
both
common
cipher
suites
they're
well
known.
K
They
are
both
represented
in
cosy,
which
means
that
they
also
have
a
predefined
sort
of
representation
and
Seamore,
which
would
also
be
helpful,
since
these
will
be
busy
extension
blocks
and
VP
biz
is
going
into
Seaborg.
So
that
is
a
draft
and
we
probably
aren't
going
to
ask
for
that
to
go
into
last
call
right
now.
I
think
it
would
be
good
to
get
some
other
eyes
on
it,
but
probably
by
the
next
working
group
meeting
I
think
it
would
be
ready
to
go
next
slide.
K
So
to
sort
of
wrap
up,
we
really
haven't
seen
any
significant
concerns
expressed
so
far
in
BP
SEC,
certainly
moving
from
four
to
five
week.
We
did
address
the
issues
that
we
have
so
far.
The
largest
remaining
issue
seems
to
be
any
discussion
on
the
common
of
whether
BP
SEC
says
that
Cyprus
we
parameters
and
security
results
are
simply
opaque
and
to
be
determined
by
the
cipher
suite
or
whether
it
enforces
a
key-value
scheme
and
then
just
allows
the
cipher
suites
to
provide
enumerate
the
keys
and
provide
the
encoding
of
the
values.
K
I
think
we
can
probably
resolve
that
without
much
issue
and
then
I
think,
probably
by
the
next
working
group
meeting
the
interoperability
cipher
suites,
which
are
out
there
in
draft
form,
now,
would
also
be
ready
to
go
so
that
that
is
that
is
the
current
status
of
BP
sac.
So
at
this
point,
we're
really
not
aware
of
any
significant
issues
that
would
prevent
this
from
going
forward.
B
G
K
Yeah,
that
was
the
thought.
Certainly
there
are
cases
where
we
would
point
solely
to
existing
cipher
suites,
but
in
our
security
considerations
area
we
mentioned
that
the
nature
of
DT
ends,
particularly
things
such
as
security
at
rest,
would
likely
provide
constraints
or
recommendations
to
cipher
suite
parameters
specific
to
in
a
DTM,
and
that
would
probably
mean
defining
new
cipher
Suites.
Okay,.
G
C
G
They
absolutely
do
this
mr.
Dawkins
again
and
just
as
an
advertisement
for
this
pretty
much
all
the
review
teams
and
directorates
will
do
review
as
requested.
So
you
don't
even
have
to
know
you
don't
have
to
wait
till
you're
close
we're
transport
is
doing
a
review
for
a
six
load
document
that
the
working
group
is
considering
adopting,
but
they
want
to
know
what
they're
getting
into
so.
So
the
the
review
teams
are
really
becoming
a
lot
more
helpful
and
a
lot
less
of
a
source
of
late
surprises.
B
C
Just
to
cover
our
private
conversation
mark
raises
the
point
that
one
thing
that
the
cause
BP
SEC
to
drop
out
of
last
fall
like
a
stone
is
that
if
we
suddenly
make
a
change
to
DP
base,
be
a
50/50
base,
so
I'm
looking
at
Scott
and
given
the
50/50
basis
in
law,
school
and
the
working
group
believes
it's
pretty
stable.
Now
we're
fingers
crossed.
That's
not
gonna
wreck
the
process
of
abuse.
F
D
F
D
C
C
L
C
M
L
L
L
So
these
next
two
I
believe
slides
are
identical
to
last
presentation
and
are
just
included
for
background
information
that
the
motivations
and
drive
for
this
updated.
Tc
PCL
hasn't
changed
since
it
was
originally
proposed,
and
the
point
is
just
to
both
simplify
and
correct
what
was
already
a
proven
convergence
layer
in
TCP
CL
v3.
L
L
L
So
edits
since
the
last
keep
IETF
have
been
that
there
has
been
no
change
to
what's
been
written
regarding
the
transport
security
using
TLS,
and
it
is
clarified
that
GL
is
mandatory
to
implement
as
part
of
the
CL
before
but
optional
to
use
for
any
particular
session
and
it's
negotiated
per
session.
So
it's
a
combination
of
the
two
end
points
establish
a
session
of
whether
or
not
TLS
is
to
be
used,
as
I
mentioned
on
the
last
slide.
L
So
it's
likely-
and
this
is
the
last
in
the
deck.
So
all
of
the
comments
to
date,
at
least
I
believe,
have
been
incorporated
into
the
the
current
spec,
and
this
is
good
in
that
there
are
no,
as
far
as
I
know
open
issues,
but
there
is
not,
as
far
as
I've
read
a
lot
of
concurrence
in
the
current
state.
J
C
L
And
the
protocol
is
that
provides
a
way
to
enforce
the
policy
in
both
directions
from
an
endpoint.
So
an
endpoint
can
either
declare
in
the
contact
header
that
it
simply
does
not
support
TLS
and
don't
try
to
use
it
because
it's
not
going
to
work
but
contrary
to
that,
there's
also
the
case
where
an
endpoint
can
choose
to
say:
yes,
I
do
support
TLS
and
if
the
other
side
of
the
connection
doesn't,
then
the
connection
simply
refused
at
the
point
of
contact.
C
C
It's
in
last
call
at
the
moment,
okay,
so
this
document
is
in
last
call
I
suggest
that
perhaps
given
we've
got
some
queries
and
John
is
gonna,
suggest
some
text
sure
we
hold
this
in
the
last
call
for
a
little
bit
longer.
This
is
back
to
the
milestones
and
the
we
have
lots
of
things
lingering.
In
last
call
conversation
I
had
read
mark
earlier
about
the
number
of
documents
we
have
in
last
call.
C
C
The
concern
is
that
a
number
of
people
are
currently
or
just
about
to
disappear
on
vacation,
so
we're
tempted
for
those
documents
that
are
currently
in
last
call
to
suggest
a
sort
of
end
of
August
go
ahead,
so
that
gives
the
documents
that
are
currently
in
last
fall,
which
is
BP
BES,
BP
sec.
Oh
no,
sorry
Pisac
is
not
in
last
call
yet
tcp
CL.
This
is
your
chance
to
comment
through
those
final
reviews
and
then
we'll
get
those
buttons
pushed
and
get
it
moved
into.
The
review
queue
for
certain
start
in
September.
C
G
C
C
C
C
K
So
hello,
this
is
that
again,
I
wanted
to
talk
a
little
bit
about
the
asynchronous
management
architecture.
The
reason
the
slides
are
the
same
is
we
didn't
update
the
draft
from
the
O
5
version
that
was
here
at
the
last
working
group,
because
we
have
not
of
the
people
who
have
reviewed
this
document
to
date.
We've
got
no
additional
comments,
saying
that
there's
something
specific
we
wanted
to
change
through
the
working
group.
K
How
was
it
different
in
a
DTN,
and
the
answer
that
we
came
back
was
the
asynchronous
nature
of
this:
the
the
need
to
bake
into
a
network
management
solution,
some
level
of
automation
and
perhaps
some
level
of
autonomy
and
the
asynchronous
and
and
that
sort
of
captured
in
terms
of
how
did
you
manage
a
network
asynchronously?
Well,
you
need
automation
and
autonomy
to
do
that,
so
the
AMA
is
is
a
capture
of
what
we
think
it
means
to
manage
a
network
asynchronously.
K
The
question
from
last
time
from
last
working
group
was:
does
this
document
or
could
this
document
satisfy
the
need
for
a
set
of
network
management
requirements
for
DTM
or
what
would
need
to
be
added
to
this
document
to
make
it
satisfy
the
requirements
for
that?
So
with
that
context,
I
wanted
to
briefly
represent
the
materials
and
the
topics
that
are
covered
in
this
document
and
then
ask
the
question:
if
there
is
something
missing
from
the
materials
covered,
what
would
it
be,
and
could
we
adopt?
K
C
C
Be
happy
as
a
chair
to
move
on
to
that
I
might
refer
those
who
haven't
read
this
document.
It
is
actually
well
written
and
the
slide
pack
which
is
available
in
the
meeting
materials
is
a
good
slide
back.
So
can
I
suggest
those
who
aren't
familiar
with
this
catch
up
with
it,
and
probably
we
jump
ahead
to
a
conversation.
Two
people
have
opinions
about
this
in
class
management,
architecture,
Edie.
K
We
didn't
break
out
requirements
in
terms
of
shell
statements,
but
we
did
spend
a
fair
bit
of
time
explaining
desirable
properties
constraints,
why
we
need
asynchronous
mechanisms
and
what
those
mechanisms
should
look
like
and
what
features
they
need
to
provide
and
so
I
think
from
that
we
could
either
add
a
set
of
specific
requirements
and
assumptions
and
constraints
or
simply
say
that
they
are
inferred
in
this
document.
There
had
been
a
previous
out
of
the
IRT
f
network
management
requirements
document,
and
we
could
adopt
portions
of
of
that
table
of
contents.
K
The
difficulty
that
we
had
when
we
were
writing
that
up
in
the
context
of
the
IRT
F,
if
I
recall,
was
that
while
we
broke
out
different
architectures
and
different
scenarios
because
they
looked
different
from
a
physical
standpoint,
many
of
them
collapsed.
Similarly,
from
a
network
management
standpoint-
and
many
of
them
really
came
down
to
just
needing
that
kind
of
asynchronous
management
that
we're
talking
about
here.
So
in
terms
of
the
things
that
make
this
document
a
little
bit
different
from
the
network
management
requirements.
C
Okay,
I
mean
Rick
Taylor,
but
the
lunch
a
ton
personally
I
think
this
is
incredibly
useful
work.
This
is
useful
for
my
day,
job
and
also
I.
Think
it's
intellectually
interesting
to
look
at.
How
do
we
manage
disconnected
networks
and
it's
it's
an
interesting
problem
and
also
very
useful
to
solve
I
think
we
could
spend
an
awful
lot
of
time.
Wordsmithing
the
most
perfect
architecture
document,
but
I
think
that
might
be
a
waste
of
valuable
effort.
C
I
would
prefer
to
see
the
architectural
document
being
concise
to
the
point
and
fairly
general
as
an
informational
document
without
getting
too
caught
up
in
the
minutiae
and
I.
Think
it's
a
lot
of
it
is
there
already,
and
I
obviously
need
to
do
a
good
review
of
this
document,
rather
than
just
critiquing
it
at
the
mic,
but
I
personally
I
mean
I'm
supporting
it
on
this.
One
I
think
this
is
valuable
document
to
people.
Think
that,
from
my
perspective,
it
has
done
a
lot
of
work
on
this
already.
C
J
J
D
K
H
G
What
I
thought
that,
when
I
thought
that
text
meant
was
that
you
would
not
go
into
business
for
yourselves
and
like
say,
oh
we're,
gonna
replace
that
comp
or
you
know
something
like
that.
So
so
what
I
was
what
I
was
wondering
was
whether
you
would
could
be
a
would
be
able
to
do
like
an
applicability
statement
that
and
this
bit
of
proposed
standards.
G
C
C
The
point
of
this
document
is
to
say
here
is
a
heir
of
the
architectural
requirements
specifically
to
DTN,
but
they
have
applicability
outside
of
the
traditional
DTN
communities.
So
we've
got
some
interest
from
some
of
the
data
center,
guys
to
say
well,
actually
asynchronous
management
starts
to
become
useful
to
us
when
data
is
moving
so
fast
that
you
you,
you
can't
consider
it.
You
can't
do
stop
the
world
anymore,
because
you,
you
lose
millions
so.
G
C
Awesome
yeah
so
that
you
know
most
be
delay
becomes
relevant
again.
So
from
my
personal
perspective,
is
yes,
this
isn't
on
the
Charter
at
the
moment,
but
I
think
this
is
relevant
work,
whether
it
gets
done
in
this
working
group
or
whether
it
gets
done
elsewhere
or
bits
get
done
here
there
and
everywhere.
I
see
this
as
a
as
a
multidisciplinary
effort,
not
a
DTN
reinvents
management
for
them,
because
there's
not
enough
of
us
and
we'll
get
it
wrong.
G
And
that
you
don't
have
to
so
what
what
I'm,
like
I
say,
I,
what
the
working
group
to
decide
what
the
working
group
wants
to
work
on,
because
that's
what
working
groups
do
if
the
working
group
decided
they
wanted
to
head
off
on
that
direction
and
thought
it
was
the
right
thing
to
do.
I
would
be
supportive,
so
they
just
have
to
have
that
as
a
data
point
as
you're
having
the
conversations.
D
H
H
Noby
I
think
that
there
are
some
specific
parts
of
the
the
the
old
draft
didn't
network
management
requirements
that
maybe
should
be
that
would
be
be
merged
on
this
one
or
the
other
option
is
to
to
leave
this
work
as
a
new
draft
for
the
art
or
in
MRG
team.
So
you
know
I'm
think
about
the
Spence
I
chose
to
do
that.
So.
C
If
you're
willing
to
suggest
the
comments
on
the
on
the
mailing
list
is
the
best
place
to
start
I
mean
if
currently,
this
is
a
personal
draft.
If
we
accept
it
as
a
working
group
document,
then
I
think
it's
quite
legitimate
to
spend
some
time
saying.
Well
how
much
work
do
we
want
to
put
on
this?
Are
there
ideas,
as
you
say
that
we
can
bring
in
from
my
RTF
or
from
other
groups,
I
see
energy
or
or
whatever
and
say?
Well?
C
I,
don't
want
to
say:
oh,
let's
stick
some
more
things
on
the
working
groups
desk
and
waste
time
on
it,
but
get
your
ideas
on
the
list
see
whether
it
can
be
brought
in
if
okay
I'll
just
pull
it
back.
How
many
people
in
the
room
think
the
working
group
taking
this
document
on
is
a
waste
of
our
time
and
we
have
better
things
to
do
so.
I'm
asking
for
the
negative
who
doesn't
think
this
should
be
worked
on
in
the
working
group.
C
Okay
and
then
how
many
people
actively
support
this
and
are
happy
to
contribute
comments
and
reviews
and
good
ideas?
Okay,
so
that's
a
that's
a
pretty
good
for
this
group,
given
I
know
some
people
are
sitting
in
just
to
see
what
we're
doing
so.
Obviously
we'll
take
that
to
the
list
as
well,
just
to
confirm,
but
I
think
ed.
People
are
happy
because
you
can't
see
the
content
of
the
room
that
this
is
a
useful
piece
of
work
for
us
and
it
is
a
charter
item.
G
C
Spencer
I
know,
following
up
from
what
I
said
earlier:
Edie
and
I
have
been
talking
to
Benoit
and
some
of
the
things
the
net
mod
groups
have
been
doing
with
what
they
did
call
yang
push,
but
asynchronous
notifications
and
building
on
that
we're
not
talking
about
protocol
definition.
At
this
point
we're
told
this
document
is
about
describing
the
DTN
perspective
of
management.
D
D
We
would
ask
for,
and
that
would
kind
of
an
end,
August
timeframe
for
the
working
group
Lascaux
given
as
it's
more
than
just
you
know,
small
changes,
we're
actually
you
know
removing
custody
in
it.
Just
me
to
be
precautious,
so
we
would
love
to
get
people.
You
know
saying
if
you
agree
with
it,
then
just
not
be
silent
but
says
I
read
it
it's
fine,
you
know
go
forward.
We
would
like
to
get
those
kinds
of
emails
on
the
mailing
list.
D
C
The
BP
SEC
there
is
this
with
the
BP
SEC.
That's
the
second
document
of
the
interoperability
cipher
suites.
The
question
for
me
is
whether
I
like
this
is
a
question
to
the
rest.
Should
that
be
rolled
into
the
BP
SEC
document
as
a
section
to
say,
if
you're
using
BP
SEC
here
are
the
cipher
suites
that
the
IETF
suggest
you
use
or
should
that
live
outside
as
a
separate
document?
C
If
he
lives
outside
as
a
separate
document,
then
it
probably
needs
to
be
adopted
and
go
into
the
last
call
alongside
because
I
can't
see
putting
forwards
the
security
protocol
without
a
standard
set
of
Interop
cipher
suites
is
going
to
work
I.
My
personal
opinion
is
push
the
two
together,
but
I
think
we'll
take
that
to
the
list.
Sorry
Karen.
D
D
We
may
have
additional
comments,
so
let's
say
that
by
the
end
of
August,
we'll
will
essentially
close
and
then
you
know
push
forward
with
BP
best
to
to
the
is
G
and
AMA
the
architecture
document
we
would
ask
for.
We
can
group
the
option
you
know
in
the
next
days
a
week.
This
does
that
summary,
make
sense
to
people
or
yes,.
J
D
C
The
point
was
at
the
time
was
that
if
you
separate
the
cipher
Suites
from
the
core
document-
and
you
can
up
rev
for
the
recommended
Cyprus
sweets
without
having
to
touch
the
core
document,
I
think
that
was
the
idea
just
in
case
someone
suddenly
breaks,
sha-256
or
quantum
suddenly
works,
and
then
okay,
so
does
anyone
have
any
final
comment?
They
wanted
to
make
any
questions,
particularly
in
light
of
the
custody
transfer
split
out,
which
I
thought
was
going
to
be
a
much
bigger
debate
point
than
it
has
turned
out
to
be
any
other
business
basically.