►
From YouTube: IETF92-DTN-20150326-1740
Description
DTN meeting session at IETF92
2015/03/26 1740
A
Let
me
see
if
this
goes
well.
We
we've
done
two
things
in
the
working
group,
since
we
chartered
one
is
identifying
a
list
of
work
items
which
is
on
your
left.
If
you
may
recall,
and
we
essentially
list
a
list
of
potential
work
items
and
then
something
that
could
be
done
later
and
you
know
later
or
never,
then
we
worked
on
the
use
cases
and
we
agreed
on
those
some
time
ago,
so
I'm
not
going
through
all
of
them
in
detail.
A
So
I'm
not
sure
I
will
be
able
to
play
between
those
two
all
the
time,
but
if
you,
if
we
need
then
we'll
do
so
so
I
did
the
first
version
of
it
and
then
so
that
I'm
not
looking
like
a
completely
stupid
between
in
front
of
people.
I
asked
clever
people
more
clever
than
me
to
review
it
and
we
came
in
to
this
this
afternoon,
and
so
this
is
far
from
being.
A
You
know
the
answer
of
the
my
songs,
but
just
a
proposal
to
discuss
ALP
to
discuss
within
the
working
group,
so
the
so
the
milestones
are
listed
there
with
the
potential
status,
such
as
standards
racks
or
in
Finnish,
informational
and
below
our
work
items
who
are
not
do
not
have
specific
deliverables
and
there's
a
remaining
topic
at
the
bottom
that
that
the
people
in
the
room
agreed
to.
Maybe
we
should
think
about
discussing
with
the
up
sorry
about
network
management
before
doing
converting
this
into
an
email
style.
D
D
C
A
B
C
A
C
D
C
D
A
A
E
Rick
Taylor,
Airbus
and
I
just
want
to
reiterate
one
of
the
topics
that
came
out
of
the
conversation
earlier
on,
which
was
an
a
general
intention
to
keep
the
documents
short
and
sweet
rather
than
trying
to
put
a
dressing
into
the
50-50
base
document.
The
sort
of
rough
consensus
we
had
enough
in
the
pre
meeting
was
short
sweet
documents
and
I'm,
hoping
that
the
working
group
kind
of
agrees
with
that
approach.
Rather
than
writing
monolithic
tones
yeah.
B
A
B
That
that
topic
is
actually
come
up
several
times
and
when
we
first
discussed
it
during
november,
it
was
this
is
something
that
people
are
interested
in,
but
as
soon
as
we
started
talking
about
how
we
would
do
it,
it
quickly
got
to
the
point
of
people
really
weren't
sure.
Yet
so
it
got
put
on
the
list
of
secondary
items.
B
One
way
of
looking
at
that
is
there
are
things
that
we
could
potentially
talk
to
the
dt
NRG
about
to
see
if
there's
interest
there
to
start
picking
up
this
stuff
with
the
idea
that
we
have
a
path
for
taking
work
out
of
the
RG
and
bring
it
into
the
IETF
for
Standardization.
If
there's
something
that
that
fits
in
there,
but
right
now,
I,
don't
think
that
the
dynamic
routing
within
a
dtn
is
something
that
we
really
would
bite
off
here.
That
didn't
seem
to
be
at
the
top
of
the
of
the
priority
list.
B
G
Down
the
the
bullet
on
convergence
layer,
adapter
requirements,
so
I
think
there's
a
there's
kind
of
two
different
scenarios:
where
d
TNS
considered
being
deployed
space
and
terrestrial
is
it
does
it
deserve
a
bigger
requirements,
discussion
about
when
you
get
into
trade-offs
between
large
bundles,
small
bundles
error
correction,
how
to
converge
on
you
know
a
boise
deal
environment
versus
a
long
distance.
I
delay:
how
do
you
make
those
trades
in
this
working
group
so.
B
F
F
Another
are
a
really
interesting
topic,
but
I
think
that
there
other
than
maybe
informational
and
and
as
examples
in
the
in
the
bundle
protocol
spec,
I
think
they
they
definitely
should
not
be
there
shouldn't-
be
any
normative
language
in
the
inbound
protocol.
Spec
that
says,
use
this
under
these
conditions,
I
think
the
there
will
be
deployment
or
operational
lure
that
will
emerge
from
operating
the
protocols
and
eventually
that
maybe
needs
to
be
standardized
somewhere,
but
I
think
it'd
be
way
premature
to
to
start
trying
to
dictate
to
people
use
this
convergence
their
protocol.
D
B
The
primary
thing
here
is
is
that
we
just
have
to
identify
the
milestones
and
the
milestones
are
an
agreement
between
the
work
group
and
the
ad.
So
one
once
we
have
a
a
rough
estimate
of
when
we
think
those
things
would
be
ready
to
move,
we
can
update
the
milestones.
Martin
can
beat
us
over
the
head
because
we're
way
too
optimistic,
we
can
then
start
working,
which
means,
if
people
have
ideas
of
ones,
they
want
to
take
responsibility,
for
we
can
start
writing
names
down
and
getting
those
things
getting
that
work
started.
E
D
A
D
B
C
D
B
Well,
let
me
let
me
answer
the
question
I
think
was
asked,
so
the
one
that's
listed
above
in
milestones
is
taking
what
was
done
in
in
the
RG
and
standardizing
it.
The
work
item
down
at
the
bottom,
which
doesn't
have
a
deliverable
right
now,
is
actually
looking
at
other
potential
options
for
doing
neighbor
discovery.
H
E
Rick
Taylor
again
one
thing:
these
milestones
and
work
items:
don't
that
there's
no
dependency
graph,
obviously
here
and
some
of
that
I
know
we're
trying
to
do
some
of
this
work
in
parallel
to
show
progress.
But
the
50
50
potential
base
is
quite
an
important
piece
of
work
and
so
I'm
not
sure
how
that
needs
to
be
recorded
if
it
does
need
to
be
recorded,
but
there
has
to
be
an
understanding
that
that
some
things
have
got
to
make
progress
faster
than
others,
I
just
felt
it.
What
you
said.
F
Scott
burly
again
and
actually
along
pretty
much
the
same
lines,
I
it
if
it
is
envisioned
that
will
have
a
document
for
the
addressing
architecture,
it's
possible
that
that
might
need
to
be
developed
before
the
RS
50
50
document
and,
in
any
case,
I'm
volunteering
to
work
on
that
one
as
well.
It's
very
important
to
me.
A
So
the
only
one
that
nobody
take
on
was
the
registry
of
service
and
it
fires,
which
I
already
have
a
dress.
That
was
with
pretty
advent,
so
I
could
take
this
one
any
other,
so
we
I
haven't,
earned
any
people
saying
wrong
or
anything
and
we've
earned
almost
two
editors
or
two
people
per
document
bury
my
son
at
least
to
be
interested
in
working
on
them.
So
it
looks
well
seems
to
me
that
we're
pretty
good
for
is.
B
D
E
Tyler
with
a
sort
of
question
for
the
for
the
room-
and
you
know
the
remote
participants
network
management,
the
intention
I
understood
it-
was
that
we
should
discuss
it
with
the
ops
area.
Are
people
happy
with
saying
we'll
discuss
that
with
the
ops
area
and
not
really
work
on
it
in
this
cycle?
I
know
personally,
I
am
because
it's
a
massive
topic,
but
it
equally
we
gotta
do
it
at
some
point.
I
just
want
to
see
how
the
room
feels
before
we
just
go
ahead,
because
it's
at
the
bottom
of
the
PowerPoint
yeah.
A
B
I
was
actually
going
to
elaborate
a
little
bit
on
our
conversation
that
on
first
blush
the
the
existing
IETF
model
network
management-
you
know,
IE,
SNMP
or
net
comp
yang-
doesn't
seem
to
be
quite
a
good
fitness.
But
in
order
to
really
make
that
point
clear,
one
of
the
things
that
we
had
talked
about
was
actually
having
a
discussion
with
in
the
ops
theory
to
make
sure
that
we
weren't
missing
something
obvious.
One
of
those
things
could
be
applied.
E
Do
we
need
a
document
saying
the
sort
of
a
position
paper
document
saying
look
that
work
management
for
dtn
is
a
tough
topic
that
we
can
then
take
to
the
ops
area
as
a
position
piece
or
can
that
just
be
done
in
corridors
I
don't
want
to
make
more
work,
but
I'm
wondering
whether
by
not
having
something
formal
in
the
pipeline
and
relying
on
chats
with
a
DS
and
that
kind
of
thing
whether
things
will
get
dropped.
If.
B
I'm
not
going
to
I'm
not
going
to
volunteer
anybody
do
this,
but
you
know
we
developed
the
use
cases
on
the
wiki.
I
would
have
no
problems
with
having
you
know.
Another
entry
on
the
wiki
that
talks
about
the
network
management
considerations
so
that
we
have
something
concrete
to
show
to
the
ops
area
is
saying
hey.
This
is
what
we're
looking
at
and
it
doesn't
look
like
SNMP
or
netcom
is
going
to
solve
that
for
us.
B
H
Ed
this
is
EDD
at
brain
APL.
There
there
have
been.
There
has
been
some
work
in
that
area
to
describe
desirable
properties,
requirements,
unique
constraints
and,
and
the
definition
of
network
management
at
levels
in
dpns,
so
with
working
with
anyone,
I'm
happy
to
pull
that
information
together,
put
some
information
that
we
already
have
up
on
the
wiki.
To
start
that
discussion,
I
do
think
we're
we're
reasonably
far
long
and
describing
these
what
we
think
the
desirable
properties
for
that
would
be
great.
G
B
Or
so
so,
I
can't
remember
if
it
was
in
our
meeting
or
some
actually
I
think
of
what
it
was.
Our
meeting
where
I
said
if
it
was
beyond
18
months,
I
was
going
to
like
pull
my
hair
out.
Okay,
what's
left
of
it,
so
I'm
actually
hoping
that
we
can
move
pretty
quickly,
I'll
leave
it
to
the
people
who
are
writing
the
documents
and
discussions
within
a
working
group
to
see
if
we
can
actually
hit
those
kinds
of
time
frames
but
and.
A
And
I
think
we
expect,
even
if,
at
the
end
there
is
a
graph
of
dependencies
dependencies
between
documents,
we
expect
to
work
them
in
parallel
and
to
converge
at
some
point
that
you
know
so
we
should
not
try
to
start
with
one
and
everybody
is
waiting
for
the
first
one
to
finish.
So,
even
if
we
know
they
are
dependencies,
we
can
work
in
parallel.
So
that
could
help
you
know
finishing
in
this
decade.
E
B
Alright,
so
with
you
know,
with
my
half
of
the
hat
on
I,
think
the
way
to
go
is
for
the
people
who
volunteered
to
start
thinking
about
you
know
within
the
next
week
or
two
how
long
they
think
it
would
take
to
write
such
a
document
and
maybe
just
consider
what
your
dependencies
would
actually
be.
And
in
that
way,
if
we
have
that
information
and
then
mark
and
I
can
take
a
cut
at
a
more
global
list
of
deadlines
that
we
can
put
into
milestones.
A
So
while
it
is
preparing
the
only
thing,
if
we
we
hear
there's
a
clear
consensus
and
agreement
on
those,
the
only
piece
remaining,
that
is,
we
need
kind
of
a
time
frame
for
the
different
documents
and
then
we
can
input
it
in
the
de
tracker.
So,
as
Brian
was
saying,
you
know
the
out,
the
editor
is
the
one
that
expressed
interest
as
soon
as
you,
you
know,
give
us
some
some
time
on
date
and
then
we'll
put
it
this
site,
the
the
very
last
you
know
things
that
we're
we
need.
H
H
So
a
somewhat
quite
simplified
picture
here,
which
illustrates
some
of
the
use
cases
that
were
motivating
to
our
example
was
how
do
we
work
at
a
variety
of
layers
to
secure
things
in
our
individual
model,
claves
between
them
understanding
that
security
may
be
different
between
enclaves
at
borders,
and
there
may
be
obviously
knows
where
we
don't
have
any
trust
model
whatsoever
originally
link
layer.
Security
was
how
we
did
this
at
the
application
layer.
H
Additionally
from
endpoint
services
that
cross
enclaves.
If
you
need
authentication
confidential
TN
to
n,
you
may
apply
those
services
somewhat
differently
in
your
network,
meaning
that
perhaps
authentication
or
maybe
just
integrity
within
your
Enclave,
perhaps
confidentiality
and
perhaps
additional
integrity
between
your
audience.
So
in
this
model
of
how
do
we
handle
this
at
the
bundle
liar,
so
we
came
up
with
a
set
of
desirable
properties.
I
think
I
said
desirable
properties.
The
network
management
comments
as
well.
It
is
a
favorite.
B
H
And
delay
and
cute
nature
bundles.
It
is
best
to
keep
the
security
services
with
the
bundle
itself
and
not
as
part
of
some
overarching,
encapsulating
or
supporting
aspect.
We
focus
on
the
services
of
authentication,
integrity
and
confidentiality
where
we
differentiate,
authentication
and
integrity.
By
saying
that
authentication
is
single,
hop
between
security,
aware
single
hops
in
the
in
the
bundle
network
and
integrity
is
an
end-to-end
service.
There
are
times
when
we
need
to
take
these
atomic
services
and
cascade
them
so
that
we
can
apply
them
multiple
times.
This.
H
Made
in
BSP
in
the
original
6257
mechanism,
for
that
was
a
little
too
recursive
and
you
could
get
into
quite
a
bit
of
complexity
as
you
cascaded
these
operations,
but
there
are
still
cases
where
you
may
want
to
apply
them
at
what
is
the
appropriate
way
forward,
reducing
complexity,
but
also
yielding
the
benefits
that
you
need.
And,
lastly,
we
wanted
to
understand
where
encapsulation
provided
services,
that's
it
simplifying
individuals,
security
files.
H
H
Implementations
by
a
couple
of
folks,
we
did
the
bsp
implementation
and
I
on
the
folks
from
LTS.
Did
an
initial
implementation
of
DTS
to
the
way
that
PSP
work
was.
It
uses
the
extension
block
mechanism
to
put
the
security
primitives
into
the
bundle
in
cells
that
security
is
carried
with
the
bundle
and
it
described
for
a
marble,
authentication,
block
or
blocks,
which
served
as
a
bundle,
hop
to
bundle,
hop,
basically,
oftentimes
a
sign
checks
up,
so
that
you
knew
who
the
sender
of
the
bundle
was.
H
You
had
an
integrity
and
confidentiality
form
the
payload
end
to
end,
and
you
had
something
called
extension
security
blocks
which
don't
in
some
way
with
somehow
applying
security
services
to
extension
blocks,
so
that
there
was
some
an
annuity
there.
These
services
of
authentication,
integrity
and
confidentiality
could
be
wrong
with
multiple
blocks.
H
As
we
implemented
this,
there
were
a
couple
of
observations.
One
was
there
is
a
concept
of
a
security
source,
the
security
destination
for
a
block,
and
the
idea
that
this
was
supporting
in
cascading
operations
was
that
at
some
point
in
the
routing
of
the
bundle
you
may
get
to
a
bundle
agent.
That
would
say
from
this
point
forward.
You
have
to
encrypt,
or
from
this
point
forward
you
have
to
apply
integrity,
and
when
you
get
to
another
piece
of
the
network,
you
can
remove
that.
H
The
good
part
of
that
was
that,
if
he
wanders
in
the
path,
the
likely
path,
or
at
least
the
entry
and
ingress
and
egress
points
of
a
bundle
through
some
sort
of
a
network
cloud,
you
could
apply
that
if
you
didn't,
or
if
the
bumble,
well-appointed
security
source
and
then
singing
a
different
path
to
the
destination,
without
actually
going
through
the
security
destination,
you
could
find
yourself
in
a
bind
where
you
are
unable
to
decrypt
or
integrity.
Sign.
H
Part
of
your
bundle
and
the
larger
observation
here
was
that
there
became
a
coupling
between
security
and
routing
in
this
case,
and
it
became
very,
very
difficult
to
implement
that
in
all
of
the
deployment
scenarios.
So,
starting
with
that,
we
looked
at
some
lessons
learned
off
of
the
implementations
of
bspa
and
we
came
up
with
five
recommendations.
One
was
basically
said
to
seek
to
decouple
the
routing
of
the
security
functions.
The
others
to
make
common
case
is
simple
and
efficient.
H
What
that
was
getting
to
was
making
sure
that,
as
we
had
cascading
operations,
as
we
understood
where
blocks
were
being
put,
that
we
were
able
to
create
what
we
consider
to
be
the
general
and
most
often
used
cases
of
integrity
and
confidentiality
very
quick
to
process
at
the
bundle
agents.
We
wanted
to
make
sure
that
all
of
the
block
types,
not
just
the
payload
block,
had
the
same
basic
security
services
applied
to
them
integrity
and
confidentiality
across
all
of
the
extension
blocks.
H
We
wanted
to
make
more
deterministic
statements
about
how
we
handled
fragmentation
and
in
the
bsp.
There
were
several
cases
where,
if
you
had
security
set
in
a
certain
way,
if
you
did
your
fragmentation
in
a
certain
way,
if
you
have
a
partial,
reassembly
or
full
reassembly
in
a
certain
way,
you
could
get
into
lots
of
trouble
and
there
were
many
many
discussions
and
examples
around
that.
And
finally,
looking
through
the
bsp
document
itself,
as
the
document
evolved,
we
saw
lots
of
different
kinds
of
information
being
put
together
in
a
very
large
document
Rick.
H
H
Perhaps
88
was
to
break
this
out
into
an
overall
security
model
for
dtn,
where
we
talked
about
protocols
separate
from
best
practices
separate
from
configuration
and
policy.
So
if
we
look
at
the
SP,
we
claim
that
a
streamlined
version
of
that,
whether
its
remains
called
the
streamlined,
ESP
or
something
else
could
be
brockport,
which
was
a
simpler
protocol
that
handled
the
desirable
properties.
H
We
were
for
these
models,
but
that
other
protocols
such
as
God's
bundle
and
bundle
encapsulation
and
others
that
we
have
not
completely
thought
of
yet
would
be
able
to
be
combined
in
a
series
of
best
practices
to
get
the
kind
of
security
results
that
we
need
and
then
policy
fee
mode.
Perhaps
fragmentation
strategies
and
required
Cypress
Cypress
weeds
could
be
again
a
third
type
of
document
in
the
BSP
there.
It
was
mandated
that
certain
cypress
weeds
had
to
be
supported
and
the
difficulty
with
that
is
across
the
entire
user
community.
H
Not
everyone
wants
to
use
symmetric
key,
not
everyone
wants
to
use
a
symmetric
key,
it's
really
hard
to
tell
people
that
they
have
to
support
sha-1
credibly
and
if
at
least
there
were
different,
specs
or
families
or
categories
or
groupings
of
cipher
Suites,
that's
something
that
can
be
taken
to
a
different
document
and
as
that
is
maintained
in
some
way
and
that
doesn't
affect
the
court
protocols
or
perhaps
the
best
practices.
So
if
we
look
at
the
first
part
of
this,
which
is
the
SP
SP
protocol,
we
have
an
initial
draft
out.
H
We
can
send
it
around.
We
decouple
the
security
of
the
routing
by
removing
the
security
source
of
security
destination,
with
the
only
exception
for
that
being
authentic
ation,
which
is
defined
as
being
the
next
cop.
You
know
that
if
you
were
doing
one
hop
security
authentication,
you
can
speak
intelligently
about
the
destination
because,
by
definition
it
is
where
you
were
sending
the
bundle
beyond
that
it
becomes
very
hard
to
understand
the
route.
Do
you
take
when
you
get
two
or
three
or
four
security
hops
away?
H
H
We
have
blocked
integrity,
blocks,
separate
from
payload
integrity
blogs
and
they
can
be
applied
with
the
same
rules
across
all
the
different
kinds
of
blocks,
treating
the
payload
as
an
extension
block.
In
this
case.
To
that
point,
we
then
a
deterministic
block,
processing
order
falls
out,
and
just
as
a
way
of
talking
about
this
in
spec,
we
introduce
some
terminology
called
the
security
operation,
which
is
a
service
followed
by
its
target.
A
target
is
an
extension
block
in
a
bubble
that
is
uniquely
named.
H
The
design
decision
that
we
made
to
make
this
streamlined
in
to
try
and
reduce
the
amount
of
recursive
cascading
operations
suppose
to
assert
that
only
one
unique
combination
of
service
and
target
is
allowed
in
a
bubble
at
once.
So
if
you
say
integrity,
payload
and
then
you
say,
confidentiality
payload,
we
are
not
allowed
to
then
do
another
integrity,
payload
and
another
confidentiality
payload
in
another
integrity
penguin.
H
We
treat
the
extension
blocks
the
same
as
the
kalos
I
dimension.
That
already
we
also
wanted
to
support
for
primary
block
integrity,
which
is
to
generate
a
mutable
version
of
the
primary
block,
sign
that
and
hold
the
signing
of
that
in
its
own
integrity
block,
and
that
came
about
for
some
of
our
user
community
discussions
of
something
that
was
both
desirable
and
possible
to
do
we're
getting
to
the
end
of
what's
viewable.
H
Here
we
talked
about
simplifying
the
rules
for
fragmentation
and
we
had
done
a
great
deal
of
effort
to
reduce
the
rules
around
whether
security
could
be
even
applied
to
fragments,
and
that
has
made
the
world
better.
Through
some
list
discussion.
We
found
some
additional
loopholes
to
close
around
fragmentation,
but
I
think
we're
well
in
a
way
to
addressing
some
of
those
issues.
H
So
what
is
there
to
do?
We
had
an
original
version
of
SP
SP
that
was
published
in
the
DTE
Energy.
We
made
a
zero
double
one
version.
We
have
received
a
few
small
comments
on
that.
We've
moved
it
over
as
a
draft
to
the
DTN
WG
and
comments
on
it
are
much
appreciated.
There
are
a
couple
of
things
than
we
know
we're
going
to
change
through
this
mechanism.
The
first
is
that
artsy
50-50
does
not
currently
have
a
mechanism
for
uniquely
identifying
an
extension
block
time.
H
As
an
extension
block
instance,
there
is
clearly
an
extension
block
type,
but
if
you
have
two
extension
blocks
of
the
same
type,
there
is
no
way
in
the
block
header
itself
to
say
that
this
is
one
of
that
type
of
this
is
instance
two.
So
what
we
have
done
now
is
we've
created
a
creative
solution
of
where
we
we
put
some
information
in
dictionary,
offsets
that
provides
a
unique
identifier,
and
that
is
certainly
functional.
H
But
but
clearly,
if
our
say
5050
biz
identifies
or
as
an
identification
to
extension
blocks,
we
would
adopt
that
mechanism
as
opposed
to
what
we're
going
right.
Now
there
was
disgusting
over
the
reality
that,
in
actual
networks,
the
next
bundle
protocol
top
may
not
be
security
away,
because
this
is
an
extension
service.
And
what
do
we
do
about
that?
And
we
talked
about
two
ways
to
handle
that
I
define
them
as
restrictive
and
permissive
authentication.
H
Restrictive
is
if
I
get
to
a
bundle
agent
and
the
bumble
agent
does
not
understand
security,
and
yet
there
is
security.
Stop,
especially
if
there's
a
vacation
in
the
bundle.
What
do
we
do
so
we
can
set
the
if
you
cannot
process
this
block
leg.
Do
you
drop
the
block,
or
do
you
drop
the
bomb?
You
need
to
do
one
of
those
two
things,
because
you
have
a
security
service
that
is
meant
to
be
hops.
Aha,
but
you've
not
gone
one
hump
you
bring
something
that
doesn't
understand
a
security
service.
As
a
matter
of
policy.
H
You
should
be
able
to
either
say
something
has
gone
terribly
wrong:
I,
don't
understand
the
security
topology
of
my
network
kill
the
whole
bundle
and
we
don't
want
it
to
proceed
anymore
because
it
cannot
pass
if
it
cannot
be
authenticated.
A
separate
policy
is
to
say:
well,
authentication
just
means
we
got
here
if
I
don't
care
about
security
that
well,
maybe
I
just
drop
the
block
and
continue
processing
it,
and
that
is
also
something
that
is
defensible
based
on
certain
network
deployments
and
certain
use
cases.
C
Have
a
question
come
fall,
so
this
is
in
little
ways
resembling
source,
routing,
source,
routing
or
strict
source.
Routing
and
I
can
imagine
another
option
being
don't
do
anything,
don't
drop
anything
in
particular
forward
it
along
the
path
will
get
debate.
What
the
semantics
then
about
authentication
for
one
hop,
really
means,
but
it
seems
like
that
would
be
a
useful
practical
case
that
would
come
up
from
time
to
time.
So.
H
H
H
The
order
in
which
you
apply
integrity
and
confidentiality
may
matter.
Are
you
allowed
to
integrity,
sign
something
that
has
already
been
encrypted
or
encrypt,
something
that
has
already
been
integrity
sign?
The
reason
why
that
comes
up
is
there
are
certain
cases.
If
we
go
back
to
the
initial
network
deployment
diagram
where
you
may,
typically,
if
you
want
both,
you
will
typically
apply,
and
you
will
typically
use
a
cipher
suite
that
gives
you
both
and
gives
you
an
integrity
as
additional
authenticated
data,
or
something
like
that.
H
If
we,
if
I
back
up
briefly
to
this,
we
have
the
initial
case
of
the
SP
SP.
There
is
an
initial
implementation.
That's
got
burly
root
for
SP,
SP
and
I
on,
so
that
we
could
generate
some
performance
data
in
a
variety
of
scenarios.
The
bundle
and
bundle
encapsulation
spec
has
also
been
written.
There
is
also
a
reference
implementation
of
that
in
the
aisle
aza
Tory.
H
We
are
early
on
in
this
work,
but
again,
if
this
is
a
security
model
that
we
adopted
the
working
group,
there
are
several
documents
that
we
would
need
to
bring
together
security
compatibility
profiles
and
cipher
suite
definitions
being
one
of
them,
the
other
being
general
policy
considerations,
which
is
what
are
whether
it
is
simple
whether
it
is
simply
the
configuration
of
SP
SP
or
whether
it
is
more
holistic.
How
do
you?
How
do
you
respond
to
a
variety
of
events
and
Aditi
in
a
security
cam,
and
this
is
an
eye
chart?
H
I
don't
expect
folks
to
read,
although
these
will,
of
course
be
positive.
What
do
you
do
when
less
security
than
is
required
is
received
in
a
while?
So
if
bundles
take
their
security
with
them?
If
you
as
a
bundle
protocol
agent,
that
is
security,
aware,
have
expectations
and
the
bundle
does
not
mean
that
what
do
you
do?
What
do
you
do
and
more
security
is
required?
H
What
do
you
do
in
terms
of
evaluating
security
and
transit
if
you
are
not
an
endpoint,
obviously
the
fragmentation
and
then
walking
fungal
severability,
which
goes
back
to
the
point
that
Kevin,
you
asked
the
question
which
is
when?
Is
it
appropriate
to
drop
the
block
versus
dropping
the
bubble
or
to
your
point
in
which
cases
is
the
best
just
to
leave
it
on
the
web?
H
How
do
you
make
sure
you
do
them
with
the
set
of
small
non
monolithic,
rfcs
working
together,
and
that
is
a
meta
document?
If
you
will
that
can
talk
about
how
to
achieve
these
services
with
what
we
have
again,
the
smaller
distributed
model
being
the
goal,
that's
what
I
have
so
where
we
are
right
now
is
we
have
vivvy,
we
have
sbsb,
we
have
initial
implementations
of
those.
We
know
there
are
some
areas
where
we
want
to
do
something
differently,
but
we
would
like.
We
would
request
folks
who
review
the
specs
and
provide
comment.
D
Sorry,
John
daddle,
Airbus
and
yeah,
pretty
draft
great
like
it
and
I
feel.
The
draft
would
benefit
from
some
explanation
at
the
beginning
as
to
why
this
is
better
than
the
BSP
I
might
be.
There
I
might
best
it,
but
it's
I
know
you
spent
several
slides
discussing
the
boys
and
where
falls
and
whatever
and
I
guess
we
can't
deprecated
vsp.
It's
not
not
an
ITF
thing
to
do
that
sort
of
thing,
but
is
it?
H
That's
a
very
interesting
question
and
very
interesting,
especially
since
I
don't
have
an
answer
for
it,
but
the
the
question
is
that
6257
is
an
experimental
RFC
out
of
the
RG.
What
what
does
that
mean
in
terms
of
writing
a
different
standard
to
accomplish
a
similar
result
in
the
WG?
It
is
listed
as
reference,
but
do
we
continue
to
call
this
a
streamlined
on
a
security
protocol?
Do
we
name
it?
Something
else.
Is
there
at
the
feeling
that
it
is
changing
or
supplanting
one
or
the
other
as
we
go
forward,
so
I
would.
C
B
B
So,
if
you're
going
to
do
security,
this
is
the
way
you
do
the
security
and
ignore,
what's
over
there,
I
don't
think
we
have
to
do
anything
with
the
with
the
security
spec
that
came
out
of
the
research
group.
We
just
as
a
working
group
say
from
a
you
know.
From
from
our
engineering
perspective,
this
is
the
way
we
want
to
do
it.
E
Rick
Taylor
a
bus,
I'm,
assuming
your
intention
is
to
keep
this
draft
going
through
a
few
more
iterations
as
it
tracks
the
50
50
base.
So
it
doesn't.
It
make
sense
that
bsp
is
for
50
50
v1,
and
this
can
pretty
much
be
the
security
protocol
for
50
50
base.
And
then
then
there
isn't
really
an
issue
there.
Now.
A
A
Well,
how
do
we
get?
Consistency
shows
that
we
first
have
to
have
the
milestone
then,
after
so
we
will,
we
will
be
I
will
be
hunting
all
the
document,
editors
volunteers,
to
get
some
some
time
frame
they
want,
and
then
we
can
start
this
any
other
comment
and
we're
three
minutes
left
for
the
meeting,
so
I
think
we're.