►
From YouTube: IETF105-DTN-20190726-1000
Description
DTN meeting session at IETF105
2019/07/26 1000
https://datatracker.ietf.org/meeting/105/proceedings/
B
A
A
This
is
the
no
well
as
an
IETF
session.
It
is
covered
under
the
note.
Well,
I
hope
you
have
all
read
this
before
I'll
leave
it
for
30
seconds.
Just
in
case
you
haven't.
It
is
the
standard
note.
Well,
so
our
proposed
agenda,
we
have
a
couple
of
the
critical
drafts
that
we've
been
working
on
for
the
last
years
are
now
in
ad
review
and
I.
A
One
of
the
comments
that
came
out
of
that
was
there
is
an
IPR
flag
raised
over
I,
think
bundle,
protocol
itself
or
just
sort
of
DTN
in
general
that
we
needed
to
make
make
the
IST
aware
of
and
I
think
that's
relevant
as
a
discussion.
Brief
and
I
understand
that
I
personally
am
NOT
a
lawyer.
I,
don't
know
if
we
have
lawyers
in
the
room,
but
this
is.
We
would
also
be
looking
for
guidance
from
the
ad
in
terms
of
what
we
can
and
cannot
say
is
there's
a
working
group
and
how
that
moves
forwards.
A
Ed
brain
and
one
of
his
guys,
andrew
Haberman,
will
be
talking
about
the
work
they've
been
doing
on
MP
and
where
that
is.
Although
that
is
not
a
charter
item
I
know
it's
something:
we've
been
circling
around
for
a
while
and
feeds
into
the
later
points,
which
is
once
BP
basin,
BP
SEC
and
at
least
one
convergence
layer
is
done,
is
off
into
the
is
G
and
hopefully
RF
seed.
A
Then
we
need
to
look
at
the
next
charter
items
on
our
current
charter
and
if
we
wish
to
adjust
update
uplift,
the
Charter
to
add
any
new
work
items
which
we've
been
itching
to
get
on
with
that
have
been
holding
for
the
the
primary
three
documents
so
and
I
know.
Scott
has
got
a
short
presentation
on
things
he
wants
to
discuss
that
can
turn
into
a
into
a
wider
discussion
and
that
flows
into
that
charter
milestones
and
updates.
A
So
we'll
talk
about
what
we've
got
as
part
of
that
discussion
and
see
if
we
can
get
some
rough
consensus
in
the
room
and
then
we'll
take
the
discussion
on
to
the
mailing
list
to
try
and
work
out
what
we
do
next
and
then,
of
course,
the
mandatory
any
other
business
and
from
Mike
so
administrivia
ed
brain
is
the
secretary
mark
and
I
have
introduced
ourselves.
There
is
a
jabber
room.
There
is
meet
echo
as
well
these
days
and
we
have
lots
of
people
on
meet
echo.
A
A
Did
this
is
the
slides,
okay,
I'm?
Sorry.
So,
as
I
just
said,
the
three
major
documents
we've
been
bashing,
our
heads
against,
but
no
that's
unfair-
that
we
have
been
working
hard
to
get
right
over
the
last
number
of
years
are
and
I'm
looking
around
the
room
for
anyone.
There's
a
couple
of
people
who
are
not
familiar
with
what
we've
been
doing
so
well.
I'll
go
slowly
the
bundle
protocol
base
document,
so
that
is
also
known
as
bundle
protocol
version
seven.
A
So
that
is
how
do
you
we
encapsulate
a
bundle,
one
of
the
rules
for
moving
it
around,
etc,
etc.
It's
a
meaty
document
because
it's
one
of
the
base
underpinnings
of
the
IETF
DTN
vision
of
how
you
do
this
based
on
work
in
other
standards,
bodies
and
organizations
to
associate
with
that,
because
we
use
a
layered
model.
Tcp
CL
is
what
CL
is.
What
we
call
a
convergence
layer,
which
is
the
analogy
in
an
IP
model,
would
be
your
convergence.
There
is
your
layer
to
where
your
bundle
protocol
is
your
layer
3.
A
So
a
convergence
layer
allows
you
to
move
bundles
across
a
single
logical
link.
So
that's
an
important
document
and
the
third
one
is
bundle
protocol
SEC,
VP
SEC,
which
is
how
do
you
enforce
integrity
and
privacy
and
security
around
these
things,
as
they
flow
around
your
extended
DT
and
network.
So
the
good
news
is
all
three
of
those
are
now
in
the
ad
evaluation
queue
they're.
Basically,
in
the
iesg
pipeline,
we've
had
feedback
from
our
ad
on
two
of
them.
I
think,
there's
one
more
we're
still
waiting
for
them.
C
B
A
So
the
other
half
of
the
slide
is
the
what
about
section.
So
we
have
a
couple
of
other
working
group
documents
that
are
I,
think
the
authors
believe
they're
pretty
much
done
so
there's
a
question
on
which
we
last
call
whether
the
working
group
is
happy
to
ask
all
those
and
they
are
primarily
the
bundle
protocol.
The
BP,
sac,
Interop
I
forget
what
SC
stands
for
it's
the
cipher
Suites
security
context.
So
it's
it's
a
default
set
of
cipher,
suites
and
best
practices
which
really
should
move
forwards
with
BP,
SEC
and
I.
A
B
A
Yeah,
mayor
culpa
or
new
culpa,
whatever
the
Latin
for
we
is
I'm
sort
of
mixing
my
Romance
languages
there,
no
stroke
or
/.
Thank
you
Scott.
So
we
will
pretty
minimal
TCP
CL,
which
is
a
as
simple
as
you
can
make
it
great
for
lab
environments.
Conversion
Slayer
should
be
last
called,
should
get
into
the
queue
very
promptly.
The
BP
SEC
interrupt
again
is
an
important
document
and
move
back
from
the
mic.
A
The
BP
SEC
interrupt
document
is
an
important
document
because
without
it
the
BP
SEC
document
describes
how
to
secure
your
bundles,
but
doesn't
give
any
advice
on
how
you
should
roll
out
a
reasonably
secure
set
of
cipher,
suites
and
behaviors.
So
really
we
have
to
press
the
last
call
button
on
that.
The
other
one
is
the
beat
the
beeping
I
never
closes
it,
bundling
bundle
encapsulation.
So
it's.
How
do
we
tunnel
it's
a
short
sweet
to
the
point
document?
It's
been
a
working
group
document.
It's
had
some
review.
A
A
So
I
will
probably
hold
off
and
I
know
I'll
cover
this
now,
so
these
are
some
of
the
milestones
that
are
still
remaining
in
the
current
Charter,
and
this
follows
on
from
the
same
topics
we
were
talking
about
in
Prague,
so
different
sorts
of
conversions
layer,
adapters,
addressing
architecture
I'm,
just
reading
the
slide
now
and
you
can
all
read
as
well.
So
these
are
a
list
of
some
items
that
are
on
the
current
Charter
that
need
to
be
visited.
Now
that
we've
got
the
basic
building
blocks
out
of
the
way
and
I
know
the
management.
A
The
management
piece
has
been
floating
around
for
a
while,
because
ed
and
his
team
have
been
doing
a
great
deal
of
what
I
personally
believe
his
good
work
on
asynchronous
management
designed
originally
for
the
DTN
use
case,
but
I
think
actually
has
applicability
outside
of
it.
So
that's
again
something
to
discuss.
I
know,
there's
been
presentations
in
the
past
on
key
management,
and
some
people
here
are
very
interested
in
getting
neighbor
discovery
formalized,
whether
that's
best
practices
or
real
protocols.
A
A
A
E
Well:
okay,
so
I'm
Scott,
Burley
I'm,
one
of
the
three
authors
of
the
beep
abyss
specification:
we've
gotten
Magnus's
evaluation
back
and
have
put
together
responses
to
the
points
in
the
evaluation.
This
is
like
30,
slides,
so
I,
don't
know
what
kind
of
the
time
budgeting
we
want
to
do
here.
We
can
go
through
all
of
this
or
we
can
leave
it
to
the
end.
I
see.
B
F
B
F
E
F
E
E
So
you
should
have
a
copy
and
I
will
I
meant
to
post
it
last
Sunday
never
got
around
to
it,
but
I
will
post
it
sometime
in
the
next
few
days
and
get
it
onto
the
outer
native
data
tracker
and-
and
he
also
suggests
that
the
IP
n
URI
scheme
which
is
registered
needs
is
registered
as
temporary
I
think
it
needs
to
be
moved
to
permanent
and
I
agree
with
that.
We
certainly
need
to
do
that.
A
Taylor
speaking
personally,
I
have
no
objection
to
a
DTN
URI
scheme
and
please
correct
me
if
I've
got
the
wrong
end
of
the
stick
here,
but
URI
schemes
and
that
kind
of
thing
really
as
I
understand
it
a
way
for
external
tooling
to
understand
that
the
protocol
they're
going
to
be
using
to
do
whatever
the
user
or
the
the
other
system
has
requested,
is
based
on
the
DTN
protocol
stack.
So
if
we
are
using
URIs
to
distinguish
endpoint
names
within
DTN
mm-hmm,
then
we
don't
need
to
use
a
the
the
global
public
URI
schema
registry.
A
Oh,
oh,
if
we
want
to
say
we
want
a
a
global
top-level
URI
scheme
so
that
Apple
can
put
it
in
Safari
and
ooh
computed
in
Chrome,
then
grabbing
two
of
them
and
saying
well,
it's
just
a
different
way
of
formatting
the
the
the
resource
part
of
your
URI.
But
it's
all
just
a
DT.
Any
kind
of
thing
seems
wasteful
and
confusing.
I
I
have
no
objection
to
just
GTM
but
having
IP
n
as
well,
which
kind
of
does
the
same
thing,
but
the
substring
format
is
different.
E
E
E
So
since
we
are
since
we
do
have
a
definition
of
the
ipn
scheme
in
a
registry
now
and
since
there
is
a
definition
of
the
DTN
scheme
in
section
2
dot
10.3
of
the
bpdus
draft,
which
is
certainly
subject
to
amendment,
we
haven't
settled
on
that
yet,
but
but
when
we
eventually
take
the
that
draft
forward,
it'll
it'll
that'll
be
standardised.
If
that's
sufficient,
that's
that's
fine
with
me.
I
I'm
I've.
No
feeling
either
way.
B
E
B
A
A
E
E
C
Yeah,
my
name
is
Justin
and
that's
it's
a
good
question
to
ask
yourself,
which
is
right
registry,
but
if
you're
gonna
use
these
society
formats
and
you
wear
ayat
cetera
I
think
the
right
thing
is
to
read:
keep
the
registration,
even
if
it's
primarily
now
than
in
DT
and
URI
understands,
is
for
node,
IDs
and
yeah.
It
might
not
be
that
it
doesn't
have
the
same
semantics,
that's
again
CP,
but
if
there
are
other
things
in
this
which
is
just
identifiers,
etc
in
in
these
schema.
So
it's
it's
big.
C
A
So
I
Rick
still
and
absolutely
and
I
agree
that
DTN
I'm
all
for
registering
DTM
as
a
top-level
URI,
I'm,
not
sure,
registering
IP
n
as
well
as
relevant,
because
an
IP
n
naming
schema
could
just
go
straight
under
the
DTN
co-run
and
then
you
say
oh
well.
Actually
this
is
an
IP
n
rather
than
a
textual,
but
it's
all
just
a
DTN
thing.
You
know
this
URI
says
this
resource
is
accessible
via
YC
URL
rather
than
your
I.
But
you
know
this
resources
is
located
via
the
DTN
protocol.
Yeah.
H
Eric
line,
I
was
gonna,
say,
I
have
very
limited
experience
so
far
with
the
registering
you
are
ends
fork
at
port
and
that
kind
of
thing,
underneath
the
ITF
space,
those
things
kind
of
seem
like
placeholders
and
descriptors
and,
like
you
know,
you
can
use
this
value
if
you
need
to
for
for
many
context,
right,
I
would
if
the
IP
n
is
also
the
T
scenes
already
registered,
so
certainly
no
harm
in
keeping
it
registered
for
making
it
permanent
right.
It's
not
going
to
be
used.
No
one
else
is
gonna,
recycle.
H
E
The
IP
and
scheme
is
is
used
exclusively
in
the
current
implementations
and
deployments
of
DTN.
So
just.
E
H
E
H
A
That's
when
we
had
a
child,
you
know
proposed
future
charter
item
about
naming
and
addressing
that's
to
go
into
that.
How
do
we
map
between
different
named
areas,
etc,
etcetera?
But
my
my
argument
stands
that
this
is
all
DTM
and
if
you
see
a
DTM
prefix,
then
you
say
well
what
comes
after
DT
and
:?
Oh
I
get
this
now
we're
into
the
DTN
naming
thing
and
whether
the
next
thing
is
an
IP
n
or
the
next
thing
is
it's
a
textual
string.
H
A
C
And
I
mean
a
Vicki,
that's
done
here
again,
I
I
mean
it
I.
Think
it's
actually.
Now
you
need
to
make
a
decision
about
this,
because
you
already
have
a
structure
for
how
you
include
different,
namespaces
and
map
that
you
use
to
this
numeric
namespace
and
all
these
things
in
the
protocol
so
yeah
it's
and
also
think
about
implications
of
actually
putting
IBM
under
detail.
You
were
eyes
so
I
think
you
need
to
think
this
through
I'll
retract.
My
objection.
Okay,
I,
wanted.
I
A
E
C
Yes,
I
think
you
have
so
and
but
I
definitely
want
people
to
review
your.
What
is
it
any
change?
Truly,
even
if
it's
after
4:00
DT,
no
didn't
really
have
a
structure
before
when
you
register
it
temporarily
for
the
DTN
uri,
I
mean
I
is
section
ten
point
three,
it's
is
it
it's
just
that
the
same
information
that
was
already
present
there
has
been
any
changes
section.
E
E
What
we're
doing
here
is
we're
saying
as
best
I
understand
it.
The
source
code
for
GT
n2
says
that
that
DTM
colon
slash,
slash,
DNS
name,
slash,
D
MOX
is
what
is
typically
used,
and
so
they
documents
that
that's
that's
all
that
is
happening
here.
Ok,
yeah,
ok,
good,
yeah,
ok,
I
I
would
propose
to
go
slide
to.
E
E
Is
expressing
that
the
time
representations
and
time
fields
in
the
bundle
protocol
as
UNIX
epoch
time
rather
than
UTC,
and
the
argument
for
that
being
that
UNIX
epoch
time
is,
is
continuous
without
the
the
discontinuities
introduced
by
leap
seconds,
and
so
that
makes
it
easier
to
do
arithmetic
on
on
time
intervals
and
so
forth,
because
you
just
subtract
the
times
rather
have
to
worry
about
whether
you
add
a
leap
second
or
not,
and
so
that's.
That
is
the
the
explanation
that
has
been
inserted
into
the
specification
now
and
is
that
ok,
I.
C
Mean
from
my
perspective,
it's
fun
I
mean
when
I
asked.
This
question
was
like
understanding
it
and
I'm
I.
Think
you
added
quite
a
lot
of
text,
explained
you
the
motivation,
etc
and
I.
Think
that
makes
it
clear
for
anyone
coming
off
to
whites
is
like
it
is,
and
quite
hopefully
make
sense
for
everyone.
So
yeah
I
had
no
intention
to
variety
working
group
consensus
here.
It
was
really
like.
Okay,
have
you
thought
about
all
this
and
the
answer
was
obviously
yes,
sir.
Okay.
E
A
C
E
That
sounds
good
slide.
Three
support
sign
right
so
in
I
added
some
text
in
41.6
that
that
points
out
to
the
implementer
that
these
these
numbers
may
go
beyond
three
two
bits
and
and
I'm
happy
to
add
some
necessary
normative
references,
I
didn't
know
which
ones
which
normative
references
you
thought
were
needed
there.
So
if
you
can
have
to
do
it
right
now,
if
you
can
send
me
that
offline,
that
would
be
great
next
slide.
E
Right,
so
this
is
something
going
back.
We've
talked
about
sort
of
quite
a
long
time.
If
you
don't
have
synchronize
clocks,
then
the
time
stamp
zero
goes
in
in
the
creation
time
for
all,
bundles
and
and
the
you
need
to
figure
out
the
time
to
live
and
an
expiration
time
out
a
bundle
from
the
on
the
basis
of
the
bundle
age
block
rather
than
the
current
time
versus
the
creation
time,
and
that
is
discussed
in
section
4.3.2.
So
I
added
a
forward
reference
to
four
three
two
in
Section
4.2.2,
two
to
address
this.
This
comment.
E
Maximum
hop
count,
upper
limit
and
yeah.
This
is
a
good
good
point.
It
can
can
it
be
like,
like
sixty
five
billion
hop
count
upper
limit,
and
this
is
this-
this
written
into
the
spec
as
something
that
is
beyond
the
scope,
because
we
have
no
idea
how
to
set
it.
We
could
put
a
number
in
there.
I,
don't
know
what
number
to
put
in
there
as
a
maximum
hop
count
as
a
as
a
maximum
acts
as
a
maximum
limit
I.
B
Not
blush,
it
is
individual
account
in
the
IP
world
is
actually
useful
for
detecting
loops
yeah.
So
in
some
ways
they've
been
a
large
number.
That
would
you
know
never
be.
We
were
not
be
useful
as
a
as
a
mechanism.
You're
right,
I
was
going
to
say
the
inverse,
which
is
a
maximum
number,
which
is
so
large
that
you
know
no
deployment
will
ever
reach.
That
will
be
actually
useful
for
detecting
a
loop
okay,
because
if
you
reach
that
number
I
mean
you're
in
trouble,
okay,
so
I
wouldn't
think
about
the
right
number.
A
My
consideration
here
is
that
is
this,
that
this
is
an
extension
block,
but
is
it
can
an
intermediate
node
replace
this
extension
block
to
the
point
where
it
says?
Okay,
so
say
we
go
for
255
and
someone
who,
from
a
position
of
authority,
says
I,
know
I've
got
this
to
a
safe
place
within
my
network.
I
will
now
start
forwarding
it
on
having
rewritten
that
block.
A
E
A
E
E
The
that
some
large
number
like
on
the
function
is
the
number
of
nodes
in
the
path
the
number
of
status
reports
could
be
sent
out
and,
and
so
I
added
in
5.1
a
note
that
that's
something
like
1,
plus
no
2,
plus
2
to
the
2
times
n
status
reports
2
times
n
minus
1
status.
Reports
could
go
out
so
that
that
comment
is
added
in
in
5.1
and
go
to
the
next
slide.
So.
E
E
See
if
oh
okay,
some
clarifying
text
in
5.3
that
that
says
well
what
the?
What
the
rationale
is
for
the
the
language
about
disavowing,
suppressing
the
notes:
membership
in
the
destination
endpoint
and
the
the
basic
idea
there
is
that
at
that
point,
in
the
specification,
you
are
dispatching
a
bundle.
You've.
E
E
And
yet
you
that's
not
the
end
of
the
story.
The
fact
that
you've
delivered
the
bundle
locally
does
not
mean
that
you
don't
additionally
go
ahead
and
forward
it,
because
it's
a
some
multi
point
delivery
bundle
and
for
that
purpose
of
forwarding
it,
the
local
node
is
disavowed
as
a
member
of
the
endpoint,
because
otherwise
you
get
into
an
infinite
loop
for
you
for
the
bundle,
the
the
Nova
for
the
bundle
to
itself
after
having
delivered
it
once
so.
Let's
there's
clarifying
text
added
25.3
to
explain
that.
E
Let's
see,
oh,
this
is
a
excellent
catch.
That
section
instead
of
saying
the
remaining
steps
of
section
five
are
skipped.
It
should
be
the
remaining
section.
Steps
of
section
5.4
are
skipped,
so
that's
changed
destiny,
okay,
end
point,
unintelligible
and
block
unintelligible
to
clarify
that
yeah.
It
does
mean
that
the
that
the
receiving
bundle
protocol
agent
can't
process
the
block
for
some
reason
either
that
it's
malformed
or
that
it's
corrupted
or
is
a
type
of
extension
block
that
the
implementation
doesn't
recognize.
A
E
Beyond
that,
we
really
want
to
not
constrain
implementations
of
of
bundle,
protocol
and
convergence,
their
adapters
anymore
than
we
have
to
in
this
particular
this
interface
between
the
convergence,
their
adapter
and
the
bundle
protocol
is,
it
doesn't
really
have
any
impact
on
operability,
it
has
to
do
with
implementation
and
so
I
think
it's
best
not
to
impose
any
further
constraints
on
this
interface
Magnus.
You
have
a
thought
on
this.
C
So,
no
not
today,
actually
I,
think
I
need
to
read.
I
mean
I,
understand
this.
This
is
very
different
for
different
conversions
later
and
how
you
that
they
are
things
like
UK.
If
you,
your
radio
transmitter,
has
a
certain
amount
of
families
that
are
regressing
bit
rated
capable
sending
out
the
data
and
TCP
is
gonna,
have
varying
depending
on
this
donations
and
right
and
all
these
things
so
yeah,
it's
I
might
come
back
to
this
after
I
read
the
covariance
layer
and
if
I
have
any
but.
K
E
That
makes
sense,
yeah
and
then
one
more
page
on
this
there's
a
of
okay
and
and
again
trying
to
avoid
over
over
constraining
and-
and
we
do
have
some
implementation
experience
that
that
indicates
that
we
seem
to
be
a-okay
here,
that
that
implementation
seem
to
be
able
to
function
well
enough
without
any
additional
guidance.
Next
slide.
Oh.
E
Yeah,
okay,
this
one
is
the
one
that
mark
objects
and
I
I
will
I
will
point
out
here
that
I
and
neutral
and
agnostic
on
this,
whether
the
bundle
security
protocol
implementation
in
in
in
any
bundle
protocol
implementation
is
required.
I'm
happy
either
way,
but
I
will
step
aside
and
then
but
mark
speak
mcvish.
B
Has
individual
one
of
the
use
cases
of
DTN
and
BP
is
in
space
where
DTN
is
essentially
the
network
protocol?
It
has,
you
know
a
layer
down
so
in
in
those
which
is,
you
know,
an
important
use
case
for
teaching.
B
In
this
context,
then
it
is
similar
to
IP
and
in
IP
we
tried.
Actually,
you
know
ipv6,
for
example,
to
force
IPSec
to
be
part
of
to
be
mandatory,
but
we
fail
and
if
you
look
at
the
actual
deployment
right
now,
security
services
are
actually
up
in
the
stack
most
yet
transfer.
Id,
TLS,
HTTP
level,
I
and
I
completely
agree
with
this,
because
when
you're
more
near
the
application
level,
then
the
application
could
actually,
you
know,
have
a
whole
company.
B
What
what
happens
in
security
when
it's
two
down
there's,
you
know
no
connection,
no
look
in
it,
then
the
application
doesn't
know
what
security
services
was
a
queer
actually
used
so,
and
that
is
an
EP
sake.
While
you
know
very
good
protocol
is
actually
pretty
heavy-duty
and
you
know
in
forcing
all
the
implementations
to
actually
have
BP
sake
is
way
too
much
for
me,
and
it
will
in
you
know
impaired.
B
You
know,
for
example,
more
IOT
or
embedded
devices
that
are
most
likely
to
be
in
space
too
so
I
mean
I,
think
we
should
think
of
security.
You
know
much
higher
in
the
stack
or
VP
sick
as
a
choice,
so
maybe
there's
some
wording
that
should
say
you
know
around.
You
know,
please
apply
a
security
at
some
level,
but
I'm
strongly
against
requiring
VP
sick
in
all
VP
implementations.
C
And
I
understand
that
argument.
I
think
this
goes
into.
You
part
the
choices
you
need
to
do
when
you
do
particularly
deployments,
because
I
mean
it
might
be
more
reasonable
for
the
reindeer
net
or
whatever
or
some
other
like
deployment
here
on
earth
or
to
actually
use
security,
because
you
have
much
easier.
C
E
We
are
I
believe
in
spaceflight
communication
of
spaceflight
mission.
Communications
were
increasingly
going
to
be
meeting
and
implementing
security
and
end-to-end
security
provided
by
BP
is
I.
Believe
is
going
to
be
a
good
thing
for
that.
At
the
same
time,
I
recognize
that
it
is
there's
there's
a
lot
that
goes
into
BP,
SEC
and
implementations
are
non-trivial.
There's
there's
a
lot
of
work
to
do
it
and
and
the
those
processing
overhead.
So
my
inclination
here
would
be
to
say
that
BP
SEC
in
in
any
bundle
protocol
specification,
is
strongly
recommended
as
opposed
to
required.
A
Rick
Tyler
speaking
personally,
I'm
actually
happy
with
the
the
blue
text.
I
understand
both
sides
of
this
argument.
So
the
inclusion
of
bundled
security
protocol
implementation
being
a
requirement
I.
If
you've
got
a
BPA,
you
should
implement
bundle
security
protocol.
That
doesn't
necessarily
mean
the
operator
is
going
to
turn
it
on,
but
it
does
mean
it's
available
you,
you
know
the
coders
out
there
ready
you
do
this.
This
is
this
is
important
because
there.
D
B
B
A
B
B
A
K
So
one
of
and
I
think
we
call
this
out
early
in
the
BP
stack
document.
There
are
multiple
ways
of
getting
security
for
your
application
data.
The
application
payload
could
be
ciphertext
or
sign
text
as
part
of
the
user
payload
to
begin
with.
Obviously,
there
can
be
security
at
other
layers
in
the
stack
in
particular
BP
SEC
is
meant
for
the
cases
where
you
want
to
secure
individual
blocks
and
a
bundle
separately,
or
you
want
to
provide
security
as
a
service
to
application
layers.
I
am
fine
with
strong
recommendation,
as
opposed
to
required.
I
I.
K
K
C
I
C
A
F
A
A
E
Converts
our
protocols
they
should
be
used.
Oh
also,
wouldn't
be
reasonable
to
recommend
using
an
encryption
and
Dean
at
the
converters
there
to
avoid
eavesdropping
on
the
part
that
it
and
and
prevent
traffic
analysis
by
third
parties,
and
that
is
a
reasonable
thing
to
recommend
and
that's
added
in
the
fourth
paragraph
of
section
9,
okay,
section
more
on
section
9
and
this
again
is
status
reports
and
do
we
do
we
need
mitigations
to
prevent
status
report,
bumble,
storms
and
next
slide.
E
I
think
is
the
continuation
of
this,
and,
and
so
what
I
did
for
this
is.
There
is
a
step
2
of
section.
5.4
says
that
the
bundle
protocol
can
can
essentially
drop
can
can
decline
to
forward
a
bundle
for
various
reasons
that
are
listed
in
the
table.
That
is
in
figure
4.
None
of
the
reason
codes
in
figure,
4
addressed
sort
of
arbitrarily,
and
this
this
bundle
is
too
much.
E
A
discussion
of
how
status
senator
of
a
status
report
should
set
the
lifetime
in
max
hops,
and
here
we
really
do
not
I
mean
really
lifetime
and
maximum
hops.
We,
these
are
still
research
topics,
just
exactly
how
you
set
these
things.
We
we
don't
know
and
I,
think
we
want
not
to
try
to
constrain
it
in
this
document.
I
think
it's
something
that
that
ought
to
emerge
in
the
course
of
operations
and
deployment
and
and
and
and
in
research,
so
I
would
prefer
that
we
not
say
anything
more
about
it
here.
E
E
H
E
E
H
E
E
Okay,
so
here
the
comment
is
that
there's
a
confusion
about
the
what
things
are
actually
called,
whether
they're
bundle,
block
types
or
bundle,
protocol,
block
types
and
bundle
block
types
is
the
right
name
for
them,
and
the
block
types
defined
in
BP
v7r
superset
of
the
block
types
defined
for
RFC
5050,
so
I
I
think
we
don't
need
a
new
registry
for
it.
I
think
it's
just
extending
the
existing
registry
and
I'm
happy
to
be
guided
by
somebody
else
on
this,
but
I
don't
think
we
want
to
do
a
new
registry
for
block
types.
A
Rick
speaking
personally
and
my
gut
reaction
is
as
a
developer.
Looking
at
implementing
vp7
like
oh
look
at
the
registries,
to
work
out
how
big
my
enumerations
are
and
things
like
that
and
if
there's
lots
of
bp6
these
types
that
aren't
relevant
in
bp7
mix
team
and
sure
how
much
aging
a
new
registry
costs
no
I.
Certainly.
A
Not
at
the
IETF,
because
I
think
one
of
the
later
questions
is
whether
we
obsolete
50/50
and
I
yeah
I'm,
hearing
rough
consensus
currently,
but
we'll
check
it
two
obsolete
5050
and
and
go
with
this
document.
If
another
SDO
wishes
to
continue
doing
its
in-house
changes
to
six
I
think
they
take
ownership
of
that
registry.
A
C
E
E
E
Know
this
is
a
this
is
a.
This
is
a
the
someone
is
a
new
registry
which
it
doesn't
pertain
to
our
see
5050
at
all,
so
there
isn't
anything
that
is,
that
is
being
superseded
by
the
addition
of
this
new
registry
and
the
new
registry
is
scheme
type
codes.
I
think
it
is
your
ice
team
scheme
type
codes
next
slide.
E
E
Because
it's
a
normative
reference
for
registration
procedures
should
that
be
normative,
so
I
put
that
in
the
normative
section,
but
it's
an
informative
RFC.
So
if
ID
NIST
is
okay
with
that,
then
I'm,
okay
with
it
but
I'm
and
I've
not
tried
yet
because
I
haven't
tried.
I'm
posting
the
RFC
posting
the
internet
draft
rather
I.
C
E
If
you
and
and
yet
you,
you
may
not
always
have
BP
SEC
bibs,
because
you
may
not
be
using
BP
SEC,
and
in
that
case
you
you
do
need
Circe's.
So
that's
the
the
rationale
for
for
making
them
optional
and
we
can
change
that
if
we
want
to
but
I
I
think
that's
I
think
it's
a
reasonable
policy
and
this
slide
is
there
some
more
on
this
yeah.
C
B
Would
it
be
possible
to
start,
for
example,
in
the
ground,
I
think
multiple
ups
in
the
ground,
then
when
it
goes
in
space,
you
actually
use
BP,
sick,
secure
that
part
and
then
some
other
path.
You
actually
you
know,
remove
BP,
sick
and
then
continue,
for
example,
in
the
spacecraft
yeah.
In
this
context,
the
source
node
doesn't
know
that
BP
SEC
would
that
actually
be
used
in
some
right.
That's
our.
E
B
B
C
Is
it
might
be,
that's
mucking
around
with
optional
COCs,
it's
actually
unnecessary
and
it's
like
you're,
not
removing
the
shackles
just
because
you
have
IPSec
aah.
For
example,
it's
like
it's
probably
easy
to
just
keep
the
Sierra
scene
and
and
it's
M
for
the
nodes
that
doesn't
validate
beeps.
It's
can
validate
CMS's
and
things
like
that.
So
I
I,
it's
probably
unnecessarily.
A
E
E
E
K
I
think
one
of
the
difficulties
about
deploying
VP
in
the
way
it
can
be
in
an
overlay
setting
is
that
it
depends
on
what
you're
overlaying.
So
there
are
cases
where
a
CRC
is
quite
useful
for
some
or
all
blocks
and
some
cases
where
it's
really
not
useful
and
the
difficulty
is
in
the
cases
where
it
is
not
useful.
It
can
be
very,
not
useful
and
that's
would
be
my
recommendation
for
keeping
them
optional.
A
Point
so
Rick
again
might
like,
from
my
personal
perspective,
going
back
to
the
other
question
was
I
think
a
CRC
has
or
some
integrity
check
on
the
primary
bundle.
Primary
primary
block
is
important
because
that
covers
a
lot
of
the
privacy.
You
know.
Is
this
going
the
right
kind
of
direction?
Well,
its
integrity?
More
than.
A
Integrity,
so
yes,
it's
immutable.
It's
immutable
right.
So
a
CRC
on
that
immutable
block
seems
to
make
a
lot
of
sense
from
my
perspective,
Biba
does
everything
of
CLC
will
do
and
some
yes
and
we
have
been
available
in
BP
SEC?
Yes,
so
and
that's
that's
where
it's
almost
as
though
the
CRC
is
VP
SEC
light,
but
written
in
this
document
and
mandatory.
C
But
okay,
but
I
mean
I
would
like
to
make
observations
here.
I
don't
have
a
strong
opinion.
I
think
what's
might
be
required.
Here
is
actually
the
use
of
crcs
or
not,
and
if
they
are
mandatory
to
use
in
certain
blocks,
that
should
be
deployments
something
the
deployment
case
should
define,
and
but
the
mandate
I
mean
it's
mandatory
to
be
able
to
I.
Think.
C
C
A
E
Think
it
needs
to
go
to
the
list.
I,
don't
think
we
have
a
clear
direction
if
I
were
a
variable
to
say
something
right
now
and
say:
here's
the
answer,
I
would
say:
CRC
is
mandatory
in
the
primary
block
and
not
an
optional
on
all
the
other
blocks
and
I
suspect.
That's
where
the
the
where
the
mailing
list
will
end
up,
but.
B
Please,
if
you
don't
agree,
we
should
we
must
have
a
CRC
on
the
primary
block.
C
Haberman
and
me
a
little
bit
of
conversation
yeah
and
you
have
a
shot
room
about
60
to
55
and
and
one
way
of
making
actually
this
document
cleaners
to
suck
in
the
registration
rules
for
those
registries
into
this
VP
document,
basing
a
copy
the
registration
rules
from
that
into
the
intersection
of
this
and
replace
so
we
can
obsolete
6255.
Also,
at
the
same
time,
oh
and.
E
A
A
E
And
and
but
what
what
I
have
the
the
reason
in
the
I
think
in
the
document
Shepard
right
up,
there's
a
section
that
is
there
anything
obsoleted
by
the
this
specification,
and
my
feeling
is
that
it's
not
because
RC
50-50
is
not
a
standard,
it's
a
experimental
RFC,
and
so
it's
not
actually
obsoleted,
because
it's
not
a
an
existing
standard.
But
I
don't
know
what
the
protocol
is
in
in
IETF
about
that
sort
of
thing.
So
if
it's
obsolete
its
obsoleted
yeah.
B
G
B
C
Something
that
actually
this
is
something
I
haven't
done.
This
is
reaching
across
the
streams,
because
this
is
going
from
the
ITF
stream
to
die
or
tiff
stream
and
actually
to
it,
consult
a
bit
about
about
that,
and
it's
probably
fine
but
I
mean
I.
I.
Do
see
a
point
about
this,
indicating
that
this
is
very
much
replacement
that
you
should
use
this
instead
and
for
that
and
the
iesg
is
actually
working
on
a
new
set
of
labels,
which
will
be
clearer.
G
C
H
H
C
A
G
E
E
So
I
I
think
I've
got
a
number
of
tweaks
to
make
to
draft
14.
Well
I'll
wait
for
the
the
the
minutes
before
I.
Do
that
and
then
I'll
I'll
modify
draft
14
according
to
what
we've
been
saying
here
and
maybe
some
comment
on
the
mailing
list
and
then
I'll,
post
draft
14
again
or
post
draft
14
for
the
first
time
and
I
think
I'm
done.
B
F
B
So
we
we
have
spent
obviously
more
time
in
dispersed,
but
co-chair
thinks
that
you
know,
given
that
they're
the
main
two
primary
documents
that
are
at
the
base
of
the
working
group.
We
should
spend
the
I
bandwidth
time
with
the
ad
to
actually
fix
to
move
forward.
I'm,
not
sure
we
will
be
able
to
do
the
whole
agenda,
but
if
not,
then
we'll
go
either
wait
until
next
IDF
meeting
or
do
an
interim.
That
could
be
the
right
thing
to
do
so.
K
Okay,
so
my
name
is
Ed
brain
I'm,
the
primary
author
on
the
VP
sach
security
standard,
and
we
just
got
comments
back
two
days
ago
for
the
standard,
and
so
we
were
able
to
go
through
them
and
give
some
recommendations
as
to
whether
we
needed
to
change
the
specification
or
whether
we
just
had
clarifying
text
or
explanation.
So
next
slide.
K
So
we
had
eleven
comments
received
based
on
those
11
comments.
We're
proposing
six
minor
changes
to
the
document.
Nothing
really
changes
from
our
perspective,
the
processing
associated
with
security
or
the
structure.
Most
of
it
is
clarifying
and
cleanup
of
the
text,
so
I
have
much
like
Scott
did
a
set
of
slides
that
go
through
piece
by
piece.
The
comments
received
and
my
proposal
is
at
the
end
of
each
one.
I'll
pause
just
for
a
moment.
K
If
there's
no
concern
or
significant
discussion,
we'll
assume
that
it
is
acceptable
and
then
move
on
to
the
next
item
so
going
forward
the
very
first
one
was:
we
talked
about
the
concept
of
security
context,
but
we
don't
actually
describe
a
specific
security
context.
It's
not
because
we
don't
have
them.
We
made
a
decision
in
the
working
group
that
we
wanted
to
publish
interoperability
security
context
as
a
separate
document,
and
that
second
document
exists.
It's
been
adopt
by
the
working
group
and
it
is
to
go
into
working
group
last
call
we
can
normatively.
K
K
The
the
second
is
in
looking
through
the
terminology
associated
with
BP
sack.
We
talked
about
a
security
source,
but
we
don't
and
we
give
that
a
name,
the
security
source
which
could
be
the
node.
That
applies
any
security
operation
into
a
bundle,
whether
that's
the
bundle,
source
or
Waypoint
node
somewhere
else,
but
we
don't
actually
define
the
pr2
that
security
source,
something
that
we
had
in
the
working
group
called
the
security
destination.
K
Originally
in
both
the
original
bundle,
security
protocol
out
of
the
IRT
F
and
the
very
early
versions
of
BP
SEC,
there
was
a
concept
of
a
security
destination.
The
difficulty
that
we
had
was
that
specifying
a
security
destination
as
an
endpoint
in
the
network
started
to
conflate
the
routing
function
and
the
security
function,
you
could
certainly
get
into
strange
cases
where
a
bundle
reaches
the
bundle
destination
first
before
it
reached
a
security
destination.
K
And
then
what
on
earth
do
you
do
and,
and
we
can
tunnel
to
ensure
that
there
are
particular
hops
that
or
waypoints
that
are
travel
in
one
direction
or
in
one
order
than
another?
But
in
terms
of
the
spec
itself,
we
do
not
mandate
a
security
destination.
So
from
a
terminology
perspective,
we
can
certainly
give
it
a
name
to
say
the
security
processing
node
or
the
security
processing
endpoint
associated
with
the
security
service
in
a
bundle.
K
K
Okay,
the
the
next
one.
This
is
a
somewhat
large
block
of
text,
and
it
says
what
is
the
interaction
between
the
bib,
which
provides
plaintext
integrity
and
the
BCB
which
provides
encryption
and
I
will
point
to
this.
The
last
a
few
sentences
here
which
say
if
we
have
blocks
that
are
end
and
in
nature.
To
my
understanding,
this
is
not
possible.
Any
Bibb
using
the
second
context,
can't
use
encrypted
payload
as
its
input.
K
What
this
means
is,
if
you
have
a
bundle
and
Magnus
correct
me
if
I'm
misinterpreting,
if
you
have
a
bundle
that
is
using
two
security
contacts
and
one
security
context,
is
there
to
encrypt
blocks
in
the
bundle
using
a
certain
cipher
suite
and
a
certain
key.
And
then
you
have
a
second
context,
which
is
meant
only
to
provide
an
integrity,
signature
or
signature
on
some
text,
some
of
which
is
unencrypted
and
some
of
which
is
encrypted.
K
You've
really
created
two
kinds
of
security
users
in
the
bundle,
those
that
have
the
keys
and
the
understanding
for
decrypting
the
data
and
those
that
have
the
key
is
an
understanding
of
how
to
verify
that
the
data
has
not
been
corrupted.
If
you
use
an
a
EAD
cipher
suite,
then
you
must
be
able
to
understand
the
encryption
key
to
be
able
to
verify
the
signature
of
the
encrypted
data
and
and
if
you
cannot
have
a
bi
B
that
targets
an
encrypted
data.
You
can
add
a
second
signature
using
this
mechanism.
K
The
recommendation
for
that-
and
we
talked
about
this
a
little
bit
in
section
7-
was
that
a
security
context
could
define
additional
security
results
that
would
be
captured
with
a
b
c
b.
So,
for
example,
if
you
had
a
security
context
that
provided
encryption,
it
would
create
it
would
replace
the
contents
of
the
target
block
with
ciphertext.
K
It
would
take
the
aad
generated
signature
associated
with
that
key
and
keep
it
as
a
security
result
in
the
bc
b,
and
there
is
no
constraint
on
having
additional
security
results
that
are
signatures
created
with
different
keys
that
could
be
created
as
part
of
a
security
context,
so
that
you
could
accomplish
essentially
that
same
result.
So
that
was
our
proposal.
K
C
My
name
is
Chris
I,
find
it
quite
feasible
to
maintain
the
rules.
I
wasn't
asked
wondering
how
this
would
be
done
and
I
think
one
of
the
C's
is
probably
is
this
and
if
you
could
point
to
the
encapsulation,
because
I
guess
that's
actually
the
lowest
overhead
of
doing
except
for
defining
you
and
you
may
canister-
contains
both
encryption
and
has
two
different
sets
of
keys.
So
I
I
mean
it
seemed
for
me.
C
K
C
A
Rick
Taylor
speaking
personally
I
found
in
my
reading
and
understanding
in
the
BP
site
documents.
There's
there's
an
analogy
to
IPSec,
where
you
can
either
operate
in
tunnel
mode,
where
you're
wrapping
your
bundle
and
putting
the
putting
the
integrity
stuff
on
the
outside
or
a
transport
mode
way
adapting
the
packet
on
the
way
through
it's
a
nice
complex.
K
Or
do
you
also
add
the
security
context
itself,
which
is
this
particular
kind
of
confidentiality
when
the
payload
is
one
service,
but
a
different
kind
of
confidentiality
using
a
different
cipher
suite
or
a
different
key
or
different
set
of
parameters
on
the
same
block
would
not
be
considered
duplicate.
'iv
again,
this
was
this
kind
of
thing
was
discussed
in
the
working
group
in
two
ways,
one
in
the
concept
of
multi
encryption
or
super
encryption,
the
other
in
terms
of
multi
key
encryption
or
multi
algorithm
encryption
again.
K
The
the
comments
coming
out
of
the
working
group
were
rather
than
to
accomplish
this
with
multiple
B
C
B's
and
then
have
the
discussion
of.
Is
it
correct
if
any
of
the
BC
B's
decode
using
any
set
of
keys,
or
particularly,
if
you
were
to
apply
this
separately
to
BI,
be
as
if
any
of
the
bibs
verify,
as
opposed
to
all
of
the
bibs
verify?
K
There
was
a
comment
in
terms
of
the
use
of
the
security
context,
flags
and
some
of
the
reserved
bits.
Importantly,
we
use
bits
one
four
and
five
and
reserved
bits
two
and
three,
and
that
seems
strange
to
reserved
bits
in
the
middle
of
a
set
of
flags.
This
was
done
partially
for
backwards.
Compatibility
with
existing
reference.
Implementations
from
earlier
versions
of
BP
sac
I
certainly
have
no
issue
with
pushing
bits
two
and
three,
but
putting
the
flags
that
exist
in
bits.
Four
and
five
into
bits.
K
Two
and
three
so
simply
bits,
0,
1,
2,
3
are
used
and
the
rest
are
undefined
or
perhaps
having
it
be
a
byte
field
and
putting
reserved
bits
associated
with
that
I.
Don't
know
if
there's
a
particular
opinion
as
to
whether
having
reserved
bits
in
the
middle
of
a
set
of
otherwise
utilized
bits
in
a
bit
field
is,
is
good
form
or
not.
K
The
the
another
question
was:
why
do
we
require
in
a
EAD
cipher
suite
again?
These
are
cipher
suites
that
generate
a
signature
on
these
data,
as
well
as
the
cipher
text.
The
short
answer
is
when
we
took
BP
sack
version
0
6,
where
it's
version
10
now
to
the
security
area
for
early
review.
One
of
and
really
the
strongest
comment
that
came
back
from
the
security
area
was
that
they
asked
that
the
cipher
suite
selections
be
mandated
to
be
a
EAD,
and
the
thought
behind
that
was.
K
It
would
be
good
to
have
a
strong
separation
with
the
idea
that
bibs
are
for
plaintext
and
BC.
B's
are
for
ciphertext
and
whether
a
signature
exists
or
not
can
can
occur
in
each
of
those
contexts,
but
associating
bib
with
open,
Tex
and
BC
B
with
ciphertext
would
be
the
real
separation
and
any
time
you
generate
ciphertext,
you
should
be
generating
a
signature
along
with
it.
K
Then
the
the
next
question
was
policy
guideline
for
blocks
that
have
been
removed
from
a
bundle
by
way
points
along
the
way,
and
this
is
absolutely
correct.
It
is
something
that
can
happen.
The
last
sentence
is
here:
I
know
that,
with
the
current
mechanism
such
a
bib
could
be
stripped.
However,
such
a
block
could
easily
be
required
in
a
security
policy
for
a
particular
deployment,
and
did
we
consider
it?
K
The
answer
is
yes,
and
this
was
a
matter
of
some
consideration
and
we
addressed
some
of
it
in
the
security
spec
itself
and
some
of
it
in
upcoming
documents.
So
if
we
go
to
the
next
slide,
one
of
the
things
that
has
been
discussed
is
whether
a
security
source
or
the
bundle
source
or
both
would
be
able
to
put
together,
manifests
locks
or
table
of
contents
blocks.
That
say
at
the
time
the
bundle
was
created
or
at
the
time
a
security
source
was
created.
K
These
are
the
blocks
that
must
exist
in
the
bundle
that
could
be
signed
by
the,
for
example,
the
bundle
source
and,
as
a
matter
of
policy
as
a
destination,
could
require
that
such
a
manifest
block
exists
and
if
a
manifest
block
does
not
exist,
then
the
contents
of
the
bundle
are
suspect
to
begin
with,
and
perhaps
the
bundle
is
not
processed
or
or
something
else.
The
the
issue
with
requiring
that
is.
There
are
certainly
many
other
ways
of
handling
that
same
set
of
expectations.
K
There
is
a
request
to
clarify
section
39
on
when
to
consolidate
bibs,
and
we
completely
agree
so
the
the
answer
here
was
finally
I
realized
that
you
could
actually
move
a
signature
from
one
bib
to
another.
This
could
be
made
clear
in
the
document.
We
can
certainly
make
that
clear
in
the
document,
and
that
was
the
correct
read
in
the
intent.
No
that's,
okay.
K
Speaking
of
unclear
in
section
310
parameters
and
result
identifications.
We
had
some
text
that
talked
about
non
normative
guidance
on
how
to
select
security
context,
identifiers
and,
and
the
short
answer
was
what
what
does
this
mean
and
how
do
we?
How
is
this
rimmel?
Is
this
guidance
for
someone
trying
to
select
these
identifiers?
K
The
history
of
this
text
was
that
before
we
had
security
context
identifiers,
we
were
saying
cipher,
suite
identifiers
and
Stephen
Farrow
in
one
of
the
working
groups
had
noted
that
there
were
existing
registries
of
cipher
suite
identifiers,
and
why
would
we
create
our
own
enumeration
of
common
cipher
suites,
when
many
other
folks
had
enumerated
cipher
suites,
and
would
that
cause
confusion?
The
the
since
that
time
we
came
to
the
understanding
that
we
aren't
enumerated.
K
Cipher
suites
for
a
new
minute,
yeah
enumerate
acuity
contexts
which
are
a
little
different
and
a
super
set
of,
and
we
should
be
able
to
enumerate
those.
However,
we
wish,
even
if
there
are
cipher
suite
enumerations,
which
are
a
different
thing
elsewhere
in
the
literature,
so
actually
proposed,
striking
all
of
this
text,
because
I
don't
think
it
applies
anymore.
K
How
is
a
security
destination
determined
so
many
places
in
the
the
BP
SEC
document?
We
say
things
such
as:
if
the
receiving
node
is
not
the
destination
of
the
bundle,
the
node
must
equip
the
BCP.
If
directed
to
do
so
as
a
matter
of
security
policy.
The
comment
that
comes
back
is
it
is
unclear
who
is
to
process
particular
security
blocks.
K
So
by
policy
a
waypoint
node
may
or
may
not
determine
that
it
should
verify
the
signature
within
a
bi
v,
bi
policy
that
you
determine
whether
it
believes
it
is
the
Decrypter
of
data
to
to
move
forward.
Certainly,
if
someone
makes
a
mistake
and
they
try
and
decrypt
data
and
throw
blocks
away
by
the
time
it
gets
to
the
bundled
destination,
the
bundle
would
be
considered
in
error
because
either
the
BCD
wouldn't
exist
or
the
Manifest
block
would
be
no
longer
valid
and
there
are
ways
that
this
can
result
in
difficulty.
K
But
all
of
that
difficulty
stems
from
a
waypoint
node
in
the
network
tried
to
malign
or
miss
you,
the
security
and
the
network
and,
of
course,
identifying
and
throwing
data
away
in
that
case
is
what
security
is
meant
to
do.
So
in
all
of
this,
our
understanding
is
that
policy
to
add
security,
services
and
policy
to
process
security
services
are
what
we
need
to
do
for
a
DTN,
as
was
mentioned
earlier,
if
there
is
a
specific
requirement
that
a
particular
node
always
processes
a
security
service.
K
A
G
I
I
G
Some
of
the
array
and
break
string
structures
with
just
looked
at
this
is
just
another
way
of
decreasing.
The
message
sides
message
size
because
the
the
headers,
the
Seaboard
headers
weren't
needed
to
encapsulate
the
data,
and
so
with
these
with
these
to
read,
updates,
we
were
able
to
reduce
the
Seabourn
message
size
by
about
25%.
G
Next
slide,
thank
you
so
for
the
string
encoding,
this
is
just
to
give
us
a
way
to
go
between
the
JSON
and
the
Seabourn
codings
and
allow
us
to
check
to
make
sure
everything
is,
is
being
processed
estimate
as
expected,
and
this
also
allows
us
to
send
commands
and
as
a
much
faster
pace,
because
it's
you
know
easier
to
enter
in
and
with
the
program
that
I've
been
developing,
we
could
that'll
translate
the
string
commands
to
see
Bor
it
can.
We
can
increase
the
speed
at
which
commands
are
created
and
sent
through
the
network.
G
Next
slide,
so
this
is
the
formal,
definite
definition
of
the
a
RI
scheme
for
the
a
a
our
eyes
and
one
of
the
one
of
the
changes
that
we've
made
is
within
the
namespace
with
the
issuer
and
the
tag
we've
changed
it
to
where
we
were
always
going
to
have
an
issuer.
Even
if
the
element
is
published
in
an
ADM.
G
This
is
just
a
brief
example
of
the
what
the
updated
string
string
form
looks
like
for
a
BP
source
report
with
the
the
new
the
ADM
issuer.
It
does
increase
the
length
of
the
report
slightly,
but
it
does
separate
every
all
of
the
different
parts
of
the
RI
out.
Much
better
makes
it
easier
to
parse
and
also
we've
got
the
we
have
the
full
version
and
the
shorthand
version
and
with
the
shorthand
version
we
would
like
to
be
able
to
parse
this
and
use
this
to
send
commands,
but
with
names
having
similar
names.
G
G
G
G
So
in
the
first
example,
we
can
represent
an
empty
t,
+
VC,
with
just
the
zero
zero
byte,
rather
than
having
to
use
two
or
three
bytes
to
represent
it
with
the
by
representing
it
as
an
empty
array
and
at
the
underneath.
Each
command.
I've
I've
broken
down
the
percent
difference
to
where
we're
averaging
around
a
twenty
five
percent
difference
in
message
size
between
the
new
and
old
command,
and
now
that
varies
a
little
based
on
the
command
size,
but
it
it
with
a
larger
command.
It'll,
obviously
be
a
bit
of
a
bigger
difference.
A
Personally,
if
I
understand
correctly
what
you've
done,
you've
removed
the
implicit
structure
by
so
you're,
not
using
the
Seaboard
encoding
to
say,
I
have
an
array,
an
array
of
three
elements.
Each
element
is
a
string
in
order
to
remove
the
tlvs,
so
you
are
presenting
the
entire
command
as
an
octet
string
or
an
octet
array.
Does
that
not
mean
you're,
adding
whitespace
sensitivity
to
these
things?
I
notice
in
this
slide
you've
got
spaces
between
the
square
bracket
etc.
G
G
And
she
does
see
on
the
sly.
So
if
you
go
to
the
next
one,
so
this
is,
this
is
just
a
logical
map
of
what
what
the
program
does
when
parsing
a
string
command.
So
we
start
with
just
the
input
and
what
it
does
is
it
generates.
It
looks
at
the
command
as
a
whole
first
and
generates
a
flag.
Byte,
you
know,
looks
to
see
if
it
has
parameters
and
it
checks
to
see
what
the
issuer
is,
and
this
is
where
the
always
having
an
issuer
helps.
We
can
check.
G
If,
if
it's
a
ADM
issued,
then
we
can
do
a
lookup
in
the
using
of
the
dictionaries
function.
I
have
in
the
bottom
right
hand
corner,
and
we
can
get
any
parameter
information
and
the
nickname
and
object
name,
information
and
begin
to
to
translate
into
C
bore,
but
the
what
happens.
Next
is
the
parameter
information
we
get
from
dictionaries
the
dictionary
function
and
the
parameters
are
sent
to
our
T
MVC
processor
and
using
the
parameter
information.
G
We
can
unpack
the
parameters
and
send
them
to
a
specific
processor
based
on
their
type
and
in
when
it
returns,
we'll
we'll
just
get
the
C
boring
coded
seaboard
translated
parameter,
and
then
we
can
concatenate
them
in
the
right
order
and
send
that
back
to
to
parse
the
beginning
function
to
put
back
into
the
command,
and
so
we
have.
We
have
functions
for
each
kind
of
parameter,
so
variables
are
eyes
expressions,
we
can
all
process
and
then
we
also
have
the
basic
data
structure
functions.
Those
are
on
the
right.
G
Those
are
just
used
for
your
your
very
basic
string
and
you
and
you
vast
parameters,
but
they
work
the
same
way
where
you
send
whatever
parameter
you
want
translated
and
you
get
the
Seabourn
coded
back,
a
version
of
that
back
and
with
dictionaries
in
the
bottom
right
I
mentioned
earlier,
but
that
just
contains
it's
a
file
that
contains
all
of
the
the
ADM
issued
control
and
every
time
you
do
a
lookup.
It
sends
back
any
any
information
we
have
on
that
control,
including
parameter
information,
parameter,
type,
nickname
and
object
name.
So.
G
A
A
Sorry
any
question
on
this
as
it
currently
stands,
so
the
question
from
the
chairs
to
the
group
based
on
Andrews
work
and
what
EDD
has
been
working
on
for
a
while.
Is
this
a
ma,
a
MP
network
management
piece-
and
this
is
a
question
for
Marcus,
so
I
know
Edie
and
I,
because
personally,
I
have
a
great
deal
of
interest
in
this.
A
Then
you
know
we're
going
quite
a
long
way
down
this
and
I
would
like
to
see
this
taken
on
in
DTN,
because
we
can't
find
a
better
home
for
it
is
that
kind
of
caused.
The
problem
for
the
ad,
because
we're
a
transport
working
group
and
another
ad
could
turn
round
to
Marcus
and
say:
why
are
you
doing
ops
in
transport.
C
C
B
Not
Masha
is
co-chair,
however,
I
think
it's
been
the
last
two
years
that
we've
been
shopping,
a
place,
yeah
and
I'm,
getting
concerned
that
you
know
with
you,
know
new
ops
a
days
and
you
were
starting
at
the
again
this
shopping,
so
I
I
think
we
have
shown
in
the
working
group.
There
are
people
actually
working
on
it
and
you
know
yeah.
C
B
A
So,
thank
you
very
much,
Andrew
good
presentation
and,
of
course,
that
that
feeds
into
this
longer
conversation.
So
the
last
thing
we've
got
time
for
really
is
to
Scott
to
just
discuss
what
he
thinks
the
working
group
should
be
looking
at
for
the
remaining
charter
items.
We
have
been
looking
to
recharter
or
refresh
our
Charter
in
some
way
and
I
think
we're
going
to
run
out
of
time.
But
if
Scott
and
blast
through
a
slide
show
quickly,
I.
E
B
Before
you
start,
coaches
are
currently
thinking
of
having
an
interim
meeting
between
before
the
next
ITF
to
actually
discuss
my
stones.we
charter.
You
know
the
next.
You
know
topics
to
be
working
on,
so
we
we'll
probably
advertise
this
in
the
next
weeks
for
scheduling
and
interrupt
an
interim
meeting
virtual
meeting,
obviously
by
WebEx
or
whatever.
E
E
Network
management
is
extremely
important
as
well,
and
I
don't
mean
this
list
to
be
exclusive.
These
are
just
my
own
personal
top
priorities,
so
my
number
one
top
priority
is
I
think
we
need
to
have
monthly
bundle,
encapsulation,
I,
think
I.
Think
it's
urgently
needed
for
two
to
structural
reasons.
One
is
that
that
we've
taken
custody
transfer
out
of
bundle
protocol.
We
need
to
retain
it,
and
this
is
the
place
to
retain
it.
We
need
to
reinstate
it
by
standardizing
bundle,
bundle
encapsulation
that
includes
aggregate
custody
signaling
as
as
one
of
its
features.
E
The
other
reason
is
really
related
to
what
ed
was
saying
earlier.
In
moving
from
the
original
bundle
security
of
protocol
specification
to
BB
SEC,
we
removed
the
notion
of
a
security
destination.
The
way
to
reinstate
that
capability
is
again
using
bundle,
bundle
encapsulation,
you
you,
you
can
use
VI,
be
e
to
direct
a
bundle
to
what
is
in
effect
a
security
destination
and
attach
whatever
security
you
need
to
it.
E
It
gives
us
a
way
of
temporarily
substituting
some
various
processing
parameters
that
make
it
make
traversal
of
a
portion
of
the
internet,
more
palatable
to
the
network
operator,
things
like
priority
and
time
to
live,
and
if
we
care
about
doing
source
path,
routing
at
some
point,
it's
a
simple
way
of
doing
source
path,
routing
as
well.
There
was
an
initial
draft
posted
in
January
that,
as
far
as
I
know,
doesn't
need
any
nobody's
brought
up
anything
that
needs
to
be
changed
in
it.
But,
of
course
it's
certainly
open
to
editing.
C
G
E
Okay,
okay,
great
okay,
number,
two
quality
of
service.
We
also
took
quality
service
out
of
RSC,
5050
and
I.
Think
speaking
from
my
own
perspective,
I
know
that
I've
got
customers
for
quality
service
that
want
to
be
able
to
specify
priority
on
bundles
I
I
think
we
are
agreed
that
this
is
something
that
can
easily
be
abused,
so
there
needs
to
be
some
reasonable
method
of
of
implementing
custody
of
quality
service
and
I
I'm
open
to
completely
open
to
discussion
on
this.
E
We
have,
if
we
care
about
it,
we
have
the
extended
class
of
service
block
defined
in
in
this
eCos
draft
from
from
a
couple
of
years
ago,
as
a
starting
point
if
we
want,
but
we
need
to
do
something
about
it
anyway.
So
I
would
propose
that
that
be
at
the
top
of
our
list
for
charter
changes
as
well
and
then
the
last
is
security
distribution.
We've
talked
about
this
a
little
bit.
E
It's
it's
not
a
charter
item,
yet
I
believe
it
ought
to
be
I'm
not
going
to
claim
that
we
have
a
final
answer
for
it.
We
have
a.
We
have
an
answer
that
has
an
implementation
that
we
can
talk
about,
but
whether
it's
that
answer
or
something
else
I
think
we
need
to
discuss
it
in
in
the
working
group
going
forward.
You
know
right
away,
so
that's
that's!
All
I've
got
thanks.
A
Anyone
want
to
leap
to
the
mic
and
suggest
any
other
random
things
they
want
to
do
otherwise.
I'm
gonna
suggest
mailing.
This
thread.
People
get
on
the
list,
suggest
things
they
want
to
do,
and
an
interim
meeting
is
not
mentioned,
probably
after
the
summer
vacation
period,
where,
hopefully,
we
can
sort
of
get
some
rough
consensus
on
what
we
want
to
do.
It's
in
scope,
that's
acceptable
to
the
80
and
make
sense
and
try
and
get
it
on
few.
B
E
L
B
It's
like
that's
the
case
for
alien
addressing
architecture.
Naming
routing
just
you
know
simple.
You
know:
topics
right,
neighbor,
discovery,
network
management,
we
discuss
key
management
and
called
the
of
service
kind
of
bad.
My
list
of
things
that
we
kind
of
discussed
before
so
food
of
thought
for
your
your
flight
back
to
own.
A
Otherwise,
standard
administrivia,
as
everyone
signed,
the
blue
sheets,
has
anyone
got
any
final
comments
debate
anything
otherwise
on
time,
I'm
gonna
wrap
it
up
and
say.
Thank
you
very
much
guys
and
I'm.
Sorry,
we
had
to
cut
short
some
of
the
presentations,
but
I
think
it
was
valuable.
So
thanks
seaman
Singapore
and
at
the
interim,
hopefully.