►
From YouTube: IETF100-DTN-20171116-0930
Description
DTN meeting session at IETF100
2017/11/16 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
D
C
C
E
E
E
Those
working
group
last
calls
were
done
some
time
ago
and
if
you
may
remember,
last
meeting
agreement
was
that,
given
that
we
have
substantive
changes
to
BP
this
essentially
removing
custody
transfer,
we
wanted
to
do
another
round
of
working
group
last
call
with
because
the
these
were
significant
changes
and
then
we
did.
We
ended
in
September
and
working
group
chairs
felt
that
we
didn't
get
enough
reviews
of
both
documents.
So
we
asked
on
the
meetings
where,
as
you
know,
more.
E
Pretty
good
than
significant
one,
so
we're
working
group
chairs
our
IP,
therefore
the
after
the
BP.
This
presentation
will
ask
the
questions
to
delay
to
here
and
which
is:
are
we
seeing
any
remaining
issues
before
sending
to
the?
Is
she
if
that
then
we'll
proceed
to
send
to
the?
Is
you
firmly
so
good
that
we
see
our
ad
in
the
room,
because
the
you
should
probably
expect
documents
sewn
in
your
q?
E
Thank
you,
CC
PCL.
There
is
no
presentation
at
this
time,
but
if
you
have
any
well
as
the
same
question,
if
you
have
any
remaining
issues
that
you
think
should
be
dealt
with
before
going
to
IOC,
please
do
so
VP
SEC
will,
after
the
presentation,
ask
the
question
about
if
it's
ready
for
a
working
group
last
call
so
that's
the
plan
and
so
prepare
your
answers
of
those
questions
and
again
that's
kind
of
our
plate.
E
Things
to
do
as
you
can
see,
we
have
more
to
do,
but
we,
as
we
agreed
at
the
beginning,
we
want
to
have
the
VP
Biss
as
the
base
for
everything
else
before
you
know
really
moving
into
the
other
topics,
so
I
think
we're
I'm,
not
sure
where
we're
on
target
for
time,
but
at
least
the
order
is
the
appropriate
order.
So
without
further
ado,
Scott
and
I
think
you
have
no
slides
right
for
different
reasons.
G
G
So
rather
than
put
some
slides,
I'll
just
speak
extemporaneously
for
about
30
seconds,
because
I
think
that's
about
all.
There
is
to
say
at
this
point
the
the
review
comments
that
came
in
on
the
mailing
list,
since
the
second
group
last
call
began,
I
think
have
been
very
helpful.
There
were
not
an
awful
lot
of
them,
but
in
particular
there
were
some
from
Lucas
I
think
caller
died,
I'm,
not
sure
guy's,
last
name
right
at
technical
universe.
G
Dresden,
who
is
my
understanding,
is
he's
doing
a
a
formal
definition
of
the
bundle
protocol
and
in
the
course
of
translating
the
spec
engine
into
a
formal
notation.
He
uncovered
a
number
of
places
where
there
were
ambiguities
in
in
the
language
which
I
thought
was
extremely
constructive.
The
there
small
changes
and
and
I
think
they
they
definitely
make
the
spec
a
little
bit
stronger.
G
At
this
point,
I
as
far
as
I
know,
there
are
no
major
outstanding
issues
with
the
specification
and
so
I
am
at
this
point
prepared
to
ask
the
if
we
can
proceed
with
that
that
first
milestone
and
and
move
the
specification
into
into
the
steering
group,
so
I
I
turn
it
back
to
the
chairs.
For
this
purpose.
H
G
G
It
seemed
to
me
the
simplest
thing
in
the
world
and
an
easy
and
I
think
fairly
elegant
approach
to
combine
the
two
into
a
single
document.
So
there's
a
an
internet
draft
out
there
for
been
about
there
for,
like
maybe
five
months
on
bundle
and
bundle
encapsulation
with
custody,
transfer,
a
reliable
or
an
optionally,
reliable
convergence.
There.
G
Protocol
I
haven't
heard
any
negative
comments
on
that
specification,
so
while
I
don't
but
certainly
not
not
ready
to
move
into
into
the
steering
group
I
think
it's
not
necessarily
inappropriate
to
suggest
that
that
specification
be
adopted
by
the
working
group
as
a
working
group
document
and
the
next
iteration
of
that
draft
via
a
working
group
draft.
So
I
would
propose
this
to
the
chairs
as
well.
H
Thanks
got
does
has
anyone
in
the
room
read
this
recently
and
equally
on
meet
echo
I?
Think
the
general
consensus
as
Scott
summed
up
is
this
is
half
of
a
well
a
portion
of
a
document
that
was
already
a
working
group
document
that
was
pulled
out
for
expediency,
so
I
from
my
personal
perspective,
rather
than
my
chair
perspective,
I
support
this
as
a
working
group
document
I
think
we
will
have
to
ask
for
the
formal
acceptance
on
the
list,
as
that's
the
official
manner
of
doing
things.
H
A
I
I
Know
the
name
in
there
okay,
so
my
name
is
Edie
borane
and
I
have
believed
the
next
two
presentations.
This
one
is
on
bondo
Protocol
security
or
BP,
sac
and
I
wanted
to
just
summarize
where
we
are
with
the
specification,
provide
a
few
updates,
respond
to
some
outstanding
comments
from
the
mailing
list
and
then
talk
a
little
bit
about
next
steps.
So
as
as
said
before
it
for
many
in
the
room
who
have
or
online
who
have
read
the
specification,
it
has
not
changed
in
an
appreciable
way
over
the
past
few
iterations.
I
The
motivation
for
the
document
has
stayed
the
same.
There
are
times
in
which
you
need
security
services
applied
inside
of
a
bundle.
There
are
times
when
you
do
not
need
security
services
provided
inside
of
the
bundle.
When
you
do
not
want
in
bundle
security,
then
there
are
other
mechanisms
for
securing
bundles
and
payloads
in
general,
but
when
you
need
security
inside
of
the
bundle
we
needed
something
new,
and
that
was
the
motivation
for
this
specification.
I
We
did
have
a
couple
of
design
decisions
that
came
forward.
Different
blocks
within
a
bundle
can
be
secured
in
different
ways.
We
wanted
to
make
sure
that
in
doing
that,
the
processing
order
remained
unambiguous
and
we
needed
to
make
sure
that
we
could
add
and
change
cipher
suite
definitions
going
forward
because
different
kinds
of
network
deployments
on
different
kinds
of
devices
needed
different
kinds
of
crypt
graphic
strength.
I
So
to
that
extent
the
overall
specification
defines
two
new
extension
blocks:
a
block
integrity
block
and
a
block
confidentiality
block,
which
can
then
be
applied
to
other
blocks
within
a
bundle,
and
it
provides
the
processing
order
to
to
manage
those.
And
then,
at
the
end
there
is
a
there
is
a
treatment
on
why
we
think
this
is
an
appropriate
way
of
securing
within
the
bundle
blocks
and-
and
that
was
added
as
a
request
from
the
working
group
review.
I
think
maybe
three
revisions
back
so
in
in
this
version.
There
were
no
substantive
updates.
I
Since
the
last
we
applied
some
comments
that
we
received
on
the
oh
five
version
of
the
document
we
reduced
the
occurrence
of
must
there
were
probably
seven
or
eight
times
and
which
must
was
capitalized
and
it
should
not
have
been.
We
corrected
a
very
small
number
of
misspellings
and
then
we
updated
the
security
analysis
section
in
two
ways.
The
first
was
we
clarified
a
point
relating
to
the
security
of
long
live
bundles.
I
But
it
was
something
we
wanted
to
address
in
the
analysis
and
then,
finally,
there
there
was
a
flawed
assumption
that
we
correct
the
assumption
to
say
that
there
are
certain
cases
in
which
certainly
signature
substitution
can
happen
even
in
the
presence
of
encrypting
signatures,
and
that,
if
you
needed
to
really
make
sure
that
you
were
guarding
against
signature
substitution,
there
was
a
particularly
loved
cryptographic,
strength
that
needed
to
be
applied
here.
All
of
this
again
is
is
not
normative
or
meaningful.
I
In
terms
of
the
specification
but
was
important
to
the
overall
security
analysis
of
of
the
protocol
at
the
end
of
the
specification,
so
there
really
are
only
a
couple
of
outstanding
comments
that
remain
I,
don't
sort
of
editorially
I,
don't
believe
that
any
of
them
are
fundamental
to
the
protocol
itself.
One
was
the
observation
that
the
specification
defines
a
key
value
format
for
cipher
suite
parameters
and
for
security
results.
I
The
actual
key
value
format
is
not
specified
in
the
BP
stack
document
other
than
how
it
is
captured
in
C
bore,
and
it
is
up
to
individual
cipher
suites
for
BP
SEC
to
define
the
keys
that
represent
those
particular
cipher
suite
parameters
and
the
results
themselves.
One
of
the
reviewers
of
the
document
had
made
the
observation
that
the
fact
that
we
would
presuppose
a
key
value
format
for
cipher
suite
parameters
and
for
results
could
be
perceived
as
levying
design
on
the
cipher
suites.
I
I
My
thought
was
that
I
disagreed
and
the,
but
having
said
that,
I
think
that
if
you
maintain
a
key
value
pairing,
certainly
a
cipher
suite
could
say:
I
have
a
single
key
and
my
single
key
is
my
opaque
block
that
I
would
like
to
deal
with,
in
which
case
there
is
nothing
preventing
a
cipher
suite
author
from
from
using
the
cipher,
Suites
and
BP
SEC
in
that
way.
So.
J
I
J
I
Another
comment
that
was
received
on
the
mailing
list
was
a
concern
as
to
whether
VP
SEC
could
be
talked
about
and
and
standardized
in
some
way.
If,
if
BP
biz
was
not
the
the
comments
associated
with,
that
was
essentially
to
disagree
for
a
couple
of
reasons,
one
being
that,
while
BP
SEC
is
a
set
of
extension
blocks,
the
BP
Sachs
standard
points
to
the
BP
biz
standard
in
terms
of
how
extension
blocks
such
as
the
BI
B
and
the
BC
B,
would
be
represented
and
serialized
and
and
handled
and
so
forth.
I
I
And
finally,
you
know
the
behavioural
changes
to
BP
biz
that
may
or
may
not
come
about
if
there
are
changes
to
BP
that
I'm
sorry,
the
behavioral
changes
to
BP
SEC
that
may
come
about
from
any
behavioral
changes
of
BP
biz
are
things
that
are
handled
as
a
matter
of
security
policy
and
perhaps
a
matter
of
Cypress
weight
identification.
We
really
haven't
identified
any
potential
behavioral
change
in
BP,
if
any,
that
would
change
the
behavior
of
the
BP
SEC
block
processing
itself.
I
Another
comment
was
simply
that
we
have
older
references
in
BP,
SEC
and
I.
Think
that's
something
we
could
fix
at
any
time
and
then.
Finally,
there
was
a
comment
from
I
think
two
meetings
ago,
which
was
in
order
for
BP
SEC
to
really
be
completed.
We
needed
to
define
a
set
of
interoperability,
cipher
suites,
at
least
one
for
integrity
and
one
for
confidentiality,
and
we
agree
with
that
comment,
but
the
decision
we
had
made
at
the
at
that
point
was
rather
than
embed
those
cipher
suites
into
the
BP
SEC
document
itself.
I
We
would
create
a
different
document.
That's
these
are
the
interoperability
cipher
suites
for
BP
sack
and
send
that
separately,
and
so
there
is
a
draft
for
that.
Brain
DT
MVP
second
drop
CS,
zero,
zero,
which
is,
which
is
a
draft,
and
it
talks
about
H,
Mac,
256
sha-256
for
integrity
and
AES
GCM
128
for
confidentiality,
although
we
can
certainly
change
those,
but
those
are
fairly
standard
and
well
understood.
J
Spencer
Dawkins,
so
not
as
a
expert
in
this
space,
but
just
offhand
I'm,
guessing
that
some
day
before
the
earth
falls
into
the
Sun,
we're
gonna
need
more
we're
going
to
be
additional
cipher
suites.
So
this
is
this
way
of
organizing
the
document
allows
people
to
change
what
we're
expecting
to
change
easily.
With
that
you
know,
and
if
somebody
says
oh,
it's
a
bigger
change
than
that
we
have
to
eat
open
up,
VP
sack,
then
we
would
know
yeah.
We
would
not.
H
J
B
K
K
B
J
H
J
E
You,
however,
I
think
we
shall
say:
there's
a
must
reference,
there's
a
dark
dependency
on
on
this
graph
right.
You
cannot
have
a
complete
implementation
if
you're
not
implementing
both
drafts
right,
because
we
want
to
have
at
least
one
cipher
suite,
which
is
interoperable
right.
So
my
point
is:
we
may
want
to
those
to
address
all
together
at
the
same
time
and
being
working
group
documents
so.
I
I
believe
rands
point,
although
we
should
check
the
minutes
was
that
if
they
happen
to
come
together
in
an
editor
queue,
that's
okay,
and
if
we
allow
this
one
to
go
forward
so
that
we
can
focus
our
efforts
on
the
next.
That
would
be
at
least
fine
with
him,
but
that's
obviously
up
to
the
working
group
to
decide.
What's
the
most
appropriate
thing
mark.
L
E
B
E
Get
to
get
the
Spencer,
are
you
you're
so
so
my
point
is
that
if
we
need
mandatory
cipher
right
for
that
technology
there
and
we
decided
that
it's
on
another
document.
Therefore
they
must
be.
You
know
strong
reference
between
the
two
must
implement
this
and
also
those
two
package
together
at
the
same
time
to
the
IG.
That's
my
point:
do
you
agree
or
not?
Yeah.
J
H
Returning
question
is
that
a
viable
option
to
say
to
the
ISD
know
we're
trying
to
paralyze
a
lot
of
this
work,
so
we're
we're
trying
to
get
VP
suckers
are
complicated
enough
documents
as
it
stands.
Yes,
we
have
a
compatibility
suite
and
we
know
this
needs
to
be
written,
but
it's
lagging
a
little
bit
behind.
Can
you
just
double-check
the
assumptions
with
a
draft
that
is
a
working
group
document
that
will
be
coming
to
the
iesg
fairly
soon?
Will
they
just
reject
that
out
of
hand.
J
You
know
we're
expecting
the
VP
SEC
draft
itself
to
require
the
kind
of
review
where
you're,
assuming
that
there
will
be
a
plausible
cipher
suite,
but
that's
not
moat,
that
that's
really
not,
which
what
it
is
is
not
really
relevant
to
the
review
of
that
document
and
that
you
want
to
start
the
community
review
of
that
document
early.
That
is,
that
fair.
E
B
I
So
so
I
will
I
would
just
sort
of
add
the
the
comments
there
that
you
know
I
certainly
do
from
my
point
of
view.
Both
of
them
seem,
like
you
know,
viable
paths
forward.
One
of
the
concerns
that
we
had
had
was
Jaco
Rick's
point.
The
BP
SEC
is
fairly
complicated
enough.
An
interoperability
cipher
suite
is
necessary
for
implementation,
because
if
you
don't
have
an
interoperability,
Cypress
suite,
how
do
you
show
interoperability?
I
However,
if
you
were
to
look
at
these
draft
documents,
I
don't
remember
exactly
but
I
think
the
interoperability
cipher
suite
is
maybe
three
pages.
The
the
amount
of
complexity
in
that
document
is
relatively
small
because
you
say
well
we're
going
to
use
this
cipher
suite
and
and
we're
going
to
point
to
cozy
for
the
for
the
keys
and
the
value
of
the
key
enumerations
and
so
on.
But
more
importantly,
a
question
becomes
the
the
breadth
of
review
that
we
are
hoping
to
get
from.
I
Vp
SEC
is
to
understand
symmetric,
key
and
asymmetric
key
different
CONOPS
different
network
deployments
and
so
on.
I
I
would
hope
that
the
presence
of
an
interoperability
cipher
suite
would
not
reduce
in
some
way
the
scope
and
the
diversity
of
the
review
that
we
would
hope
to
get
out
of
VP.
Second
yeah.
H
H
Again,
that's
a
question
to
the
working
group,
the
idea
being
that
we
have
security,
Directorate,
reviewing
VP
SEC
prior
to
it,
going
to
the
isg,
and
we
have
an
interoperability
draft
that
is
cipher
suite.
Sorry,
that
is
a
working
group
document.
Ready
to
line
up
at
that
point
was
that
in
slightest
bit
understandable
and
does
anyone
have
any
comments.
H
Okay,
Rick
again
I'll
break
it
down
into
some
questions.
Does
anyone
on
meet
echo
or
in
the
room
have
any
substantive
comments
or
reason
why
they
believe
that
BP
SEC
is
not
ready
for
working
group
last
call.
Obviously
we
will
be
asking
this
on
the
mailing
list
officially,
but
I
just
like
to
get
a
sense
of
the
room.
H
E
L
L
E
A
H
H
Think
the
general
consensus
of
the
working
group
is
that
it's
an
important
document
that
needs
to
get
to
working
group
last
call
and
sorry
needs
it's
already
in
working
group
last
call
and
it
needs
to
get
to
the
iesg
fairly
promptly,
because
the
because
the
intention
of
the
group
is
that
BP
base
BP
sec
and
tcp
CL
get
released
as
one
package
as
a
as
a
working
system
of
documents.
Thank
You
Spencer
as
a
working
cluster
of
documents
that
define
DTM
transport.
H
So
given
the
BP,
sick
and
BP
base
are
now
maturing
and
going
up,
the
pipeline
can
I
ask
people
to
have
a
good
look
at
TCP
CL
to
help
Brian
really
drill
it
down,
because
it's
there's
actually
a
lot
of
work
involved
in
doing
these
things.
Brian's
done
sterling
work
on
it,
but
I
think
he.
You
know
it's
a
working
group
document,
it's
not
just
Brian's
documents,
so
we've
got
to
help
out
as
well
and
thanks
for
all
of
you
who
have
been
doing
good
reviews.
So
next
up
ed
again.
H
M
A
M
G
A
I
And
we
started
to
look
at
other
areas
where
people
had
developed
autonomy
and
automation,
models
that
went
beyond
filtering
data,
but
but
also
looked
at
local
state
based
evaluation
and
the
the
engines
and
the
expression
mechanisms
for
putting
that
together.
In
that
in
around
2013
or
2014.
We
did
some
prototyping
of
a
system
and
some
demonstration
of
how
that
system
could
work,
particularly
how
it
could
work
in
in
highly
constrained
embedded
environments
and
particularly
in
areas
where
we
would
have
security
concerns
around
mobile
code
and
embedded
code.
I
I
And
then
we
have
put
together
a
data
model
associated
with
it,
which
is
captured
in
yang
with
JSON
examples
and
then
perhaps
at
one
point.
An
encoding
would
would
also
be
an
appropriate
and
helpful
thing
in
this
forum.
So
today
we're
hoping
to
talk
about
was
the
asynchronous
management
architecture
updates
and
the
application
data
modeling.
The
reason
why
we
wanted
to
talk
about
this
is
that
the
working
group
does
have
a
charter
to
discuss
network
management
requirements
and
a
question
that
we
have
brought
to
the
working
group.
I
So
the
the
AMA
overview
for
those
who
have
not
read
the
document,
it
has
been
largely
unchanged
in
the
past
several
revisions
from
oh
five,
two,
oh
six,
the
the
changes
that
were
made
were
as
follows.
Sorry
the
changes
are
made
were
as
follows:
is
that
we
have
fixed
a
few
misspellings
and-
and
we
provided
a
paragraph
that
clarified
our
stance
on
tabular
data
or
tables
as
a
data
structure
in
general,
the
AMA
defines
service
definitions
as
to
what
does
it
mean
to
manage
a
node
asynchronously?
I
It
is
not
simply
monitoring
data
to
get
information
back
to
an
operator.
We
we
accept
configuration
and
parameterised
control
and
administration
is
part
of
the
responsibility
of
a
network
management
protocol
in
this
area,
and
then
we
came
up
with
a
series
of
desirable
properties
that
we
felt
tuned
this
to
the
kinds
of
deployments
we
would
be
seeing
for
space
systems
for
very
embedded
devices
for
and
for
areas
where
you
have
resource
systems,
but
do
not
often
have
periods
of
connectivity
and
those
are
the
intelligent
push
of
information,
pull
models.
I
I
think
we
understand,
don't
work
well
in
this
space.
Minimizing
message.
Size
does
become
important,
both
from
a
CPU
and
RAM
margin
perspective,
and
also
from
making
better
utilization
of
bandwidth.
When
you
have
it
being
able
to
identify
data,
absolutely
and
also
create
customized
views
of
it
and
and
then,
of
course,
the
autonomous
operations
in
all
of
that,
we
propose
a
system
model
where
you
would
have
agents
and
managers
in
the
system.
I
We
try
and
reuse
as
much
network
management
terminology,
as
we
can,
of
course
in
describing
the
concepts
and-
and
we
look
at
pre,
shared
schemas,
which
are
you
know
for
where
necessary.
We
support.
Pre
shared
scheme
is
because
that
is
again
part
of
minimizing
the
overall
amount
of
information
and
providing
absolute
identification
of
data.
I
We
we
have
started
discussions
with
a
variety
of
folks
who
are
looking
at
writing
reference
implementations
of
this,
and
there
are
at
least
three
that
I
know
that
are
in
various
stages,
and
there
are
some
communities
that
are
looking
at
implementations
of
managers
and
graphical
interfaces,
and
then
there
are
some
communities
that
are
looking
at
agent
implementations
themselves
in
various
languages
and
for
various
code
bases
in
general.
That
is
the
those
are
the
highlights
of
the
of
the
architectural
model.
I
I
So
in
particular,
we
wanted
to
separate
the
data
specification
from
any
of
its
potential
encodings.
We
have
had
discussions.
Some
people
would
like
a
hand,
packed
binary,
encoding
or
a/c
boring
coding.
Others
would
like
an
xml
encoding.
It
became
very
clear
very
quickly
that
the
data
model,
in
order
to
be
exchangeable
and
interoperable
across
various
encodings
need
to
be
abstracted
up
a
layer,
and
so
we
have
done
that
in
this
particular
internet
draft,
which
is
right
now.
I
It
rolls
up
into
what
we
call
an
application
data
model
template,
which
is
something
that
we
provide
to
potential
users
so
that
they
can
put
their
data
model
together
in
a
in
a
generic
form.
And
then
here
would
be
an
example
of
a
a
filled
out,
JSON
example
to
that
template.
Assuming
that
there
aren't
any.
You
know
future
changes
to
that
schema.
I
So
that
is,
that
is
where
we
are
with
the
with
the
asynchronous
management
work
there
is.
There
are
two
drafts
that
are
out
in
particularly
the
AMA
has
been
out
for
for
some
time,
and
a
question
that
has
been
asked
both
on
the
mailing
list
and
in
previous
working
groups
is,
is
the
level
of
information
that
is
there
sufficient
and
useful
to
answering
our
network
management
questions
for
the
working
group.
H
I
think
it's
worth
pointing
out
the
world
also
ed
is
meeting
with
a
young
doctor
after
this
session
to
go
through
some
of
the
finer
details
on
some
of
the
yang-ming
coding,
because
me
personally,
without
my
chair
hat
on
I,
think
the
yang
in
coding
I
think
we're
missing
a
trick
here.
I
think
there's
some
clever
of
ways
to
do
this
yang,
so
we're
trying
to
reach
out
to
the
wider
IGF
community
to
get
some
some
better
understanding
of
what
is
quite
a
complicated
Beast
yang.
Actually,
it's
quite.
H
I
My
apologies,
so
I
am
asking
for
working
group
adoption
of
the
AMA
spec.
We
we
have
had
it
as
a
topic
of
conversation
for
several
working
groups.
I
know
that
it's
gotten
a
fair
bit
of
review
over
the
past
year
and
a
half
and
has
not
gone
through
any
substantive
changes
in
the
past
year
and
a
half
and
then,
if
anyone
would
like
to
participate
on,
the
ADM
I
would
like
eventually
for
the
ADM
document
to
also
be
adopted,
but
I
think
that
would
be
something
that
should
come
after
the
AMA
document.
I
think.
H
It's
worth
pointing
out
at
this
point
that
the
asynchronous
management
methodologies
that
EDD
is
proposing
here
is
is
I.
Don't
think
the
intention
would
be
that
this
would
be
the
one
true
way
of
managing
DTN
based
devices.
I
think
your
suggestion
and
correct
me
if
I'm
wrong
is
that
this
is
a
way
of
managing
devices
that
fits
a
certain
use
case
for
other
devices
and
systems
using
DTN.
You
may
want
to
use
a
more
connected
management
solution
or
whatever.
G
And-
and
it's
not
only
my
understanding
is
it's
not
only
the
only
single
one,
true
way
to
manage
a
Deloitte
or
networking.
It's
also
a
potential
way
to
manage
networks
other
than
really
tolerant
networks.
Is
that
correct
and
I
think
it's
an
important
point
for
people
to
be
aware
of
that?
There's
a
utility
here
beyond
the
DTN
working
group,
potentially
utility
beyond
the
DTM
working
group,
I.
H
I
If,
if
there
are
pre-existing
deployments
or
if
there
is
additional
back-channel
or
alternative
mechanisms
that
essentially
do
not
incur
the
constraints
of
that
AMA
is
trying
to
solve,
then
then,
certainly
there
are
other
options
beyond
AMA,
but
to
Scott's
point
when
we
have
talked
to
some
people
who
are
not
deploying
DTN
they've
come
back
and
looked
at
this
from
an
automation,
standpoint
and
said
really
as
a
matter
of
cost
and
understanding
putting
that
level
of
automation
into
these
devices.
That
does
not
involve
mobile
code.
I
That
does
not
involve
running
you
know
and
deploying
scripts,
and
that
does
not.
That
does
not
require
well
the
level
of
attention
that
other
solutions
that
they
are
trying
to
deploy
requires
has
been
motivating
for
them,
even
though
they
do
have
the
connectivity.
So
it's
it's
difficult
to
make
a
one-to-one
mapping
between
where
this
is
so
late.
But
the
long
comment
is
I'm
sure
there
are
other
ways
to
get
up
the
mountain
if
you
will,
but
the
the
AMA
I
believe
is
uniquely
suited
for
DTM
in.
H
So
nicely
following
from
that,
I
think
the
next
presentation
is
on
an
alternate
way
that
one
might
want
to
manage
things
over
DT
ends,
which
is
why
I
was
setting
up
to
say
that,
although
personally
I
think
this
is,
this
is
a
very
elegant
solution
to
automation.
I
believe
there
are
other
ways
to
manage
systems
that
are
using
DTM
as
a
transport.
So
thanks
that.
M
N
F
N
This
is,
this
is
an
impossible
graft
and
this
drop
is
about
a
use
case
of
DTN
and
we
applied
it
in
the
speech.
Networks
and
research
in
the
draft
is
implementation
of
the
teaching
and
it
is
quoted
by
or
by
the
national
portrait
in
China
and
in
the
in
the
project.
They
aim
to
build
integrated
space
and
the
terrestrial
network,
and
my
focus
is
on
is
on
the
business,
is
on
this
business
work
and
I
proposed
so
to
use
it
in
slower,
get
her
voted.
Her
transmission
and
the
STM
folder
control.
N
N
Interrupt
a
frequently
this
is
the
Kemper
is
comparison
comparison,
the
protocols
that
can
be
used
in
the
space
network,
as
we
can
see,
eta
is
designed
for
the
space
network,
but
it
is
still
in
the
experimental
stage.
However,
these
years
many
many
earrings
has
been
converted
about
using
the
TTA
interspace
network.
Scott
me
movies,
invented
by
NASA,
is
a
there
is.
Nothing
is
very
good.
J
N
N
The
past
years,
a
local
approach,
as
our
focus
focus
on
the
new.
The
new
architecture,
was
a
tightening
of
certain
networks.
For
example,
the
internist
is
come
scan
by
maybe
and
in
China.
We
also
have
many
mission
approaches
about
you,
sittin
architecture
and
so
yeah.
You
know,
project
is
proposed
to
here's,
the
sta
Innerspace
Network
fold
better,
can
show
and
the
pattern
management.
N
The
first
one
in
the
separated
can
show
pony
and
a
floating
plan
and
which
replace,
replace
the
controller
under
GGO
a
satellite
and
is
a
floating
devices
on
the
MU
and
the
new
satellites
and
sure
separate
to
separate
to
can
show
play
and
the
floating
plane.
We
here's
220
from
the
set
after
IOM
script,
and
that
is
a
very
used
iOS
quipped
of
the
control
plane,
a
controlling
and
the
way
us
the
island
script,
rotator
link
to
set
of
iOS
quipped
and
are
different.
So
we
I
mean
this
way.
N
N
D
N
Yes,
DSM
the
transmission,
a
packet
of
the
packet
can
be
divided
into
two
stages
and
first,
the
first
stage
is
that
the
back
of
the
packet
arrived
as
the
satellite
and
as
a
packet,
a
store
in
a
store
locally,
and
the
second
stage
has
is
that
if
there
is
a
variable
pass,
so
the
circuit
is
afforded
to
the
nest
of
the
hop
and
the
controller
world.
Hauser
Takeda
where
to
where
to
forward,
and
both
are
was
a
two-stage-
can
be
modeled
as
mm
when
I'm
on
one
kills.
N
And
open
flow
Network,
a
basic
human
theory,
we
make
some
modification
and
we
modify
modify
the
the
model
in
the
lastest
slide
to
the
model.
In
this
slide
in
we
make
some
equally
equivalent
transformation,
and
so
we
can
use
the
Jackson,
the
Jackass
another
in
the
quirian
theory
to
model
not
nodes,
and
then
we
make
another
experiment
to
to
verify
the
to
verify
the
Muto
and
we
baby
people
at
the
post
controller
are
Iowan
and
open
innovation
to
encounter
experiment,
and
we
events
a
model,
a
meth
lab
and
we
compare.
N
The
experimental
rates
out
ends
a
numerical
result
and
as
we
can
and
as
a
contrast
term
is
the
fire
serving
time.
I
would
say
is
the
file
serving
time.
It
is
that
it
eights
the
first
packet
Alfaro
a
rabbit,
a
second
satellite
to
to
the
last
the
last
peg.
So
that's
a
packet.
Our
file
leave
those
satellites,
and
this
time
is
called
fail.
Certain
time
they
could
be
comparators
certain
time.
Others
experiment
without
answer
and
the
numerals
out,
and
we
can
see
from
the
figure
that
the
numerical
results
and
the
experimental
results
are
very
closed.
N
N
N
We
we
have,
we
have
several
high-performance
servers
and
the
way
deploy
way
deploys
our
the
satellites
under
OpenStack
and
OpenStack
are
gradually
in
the
running
servers
and
we
employ
the
DTM
to
ACIP.
Tcp/Ip
protocol
transit
ran
solution
on
a
function
on
the
sj1
sj2
sts-3
is
a
4.8
away
and
in
the
SMC
isn't
mean
the
satellite
network
management
center
and
all
over
all
over
the
virtual
notes.
The
news
aims
at
rest
or
are
real
computers
and
is
our
the
music
in
the
interspace.
Our
version
are
what
she
knows.
N
So
it's
also
virtual
nodes,
and
that
means
our
physical
nodes
consist
out
as
a
whole
protocol
and
the
links
are
configured
by
naming
so
traffic
to
control
to
and
the
connected
connections
and
the
parameters
of
links
are
abstract
from
a
sticker
that
is
page
render
the
three
layer,
the
constellation
SDK
and
the
captor.
So
current
the
parameters
are
links
and
they
use
that
such
the
linux
traffic
and
so
to
to
to
simulate
that
the
links
as
similar
to
simulate
the
fact
the
parameters
are,
the
link.
N
And
this
the
machines
of
our
protocol
and
we
held
eight
high-performance
servers
and
the
28
computers
we
use
as
we
as
a
higher
site.
We
have
a
user
high-performance
servers
to
hold
so
what
role
the
Virtual
Set
revenues
and
they
use
the
28
computer
to
to
create
the
terrestrial
network
and
the
terrestrial
network
contains
a
small
data
center
and
more
power
under
mobile
network.
N
N
And
the
first,
the
youth
case
act.
Olicity,
the
atha
means
that
our
user
or
user
want
to
send
some
data
to
the
terrestrial
network,
and
first
is
the
link
is
that
the
transmission
link
is
the
link
one,
but
the
way
it
becomes
very
bad
and
the
Piccolo's
rate
increase.
So
the
controller
can
collect
this
information
and
sends
the
information
to
to
the
s
am
c
sm
c
ZN
then
make
a
new
floating
through
and
the
send
it
to
the
suitor
controller
in
the
convert.
N
N
Second,
the
second
is
kiss
is
the
residence
and
is
the
network
versus
which
residence
this
is.
It
help
story
about
101
host
ranchers
in
the
to
me,
one
I
want
to
stand
some
veto
me
too
me
too,
and
personally
swish
in
the
in
the
pants
boots
down
and
the
controller
in
the
12
to
network
class,
this
information
and
new
and
the
McNew
forwarding
rules
and
the
past
switch
to
another
another
pass
in
the
earth
through
networks
only
and
fortunately
another
switch
in
their
past
or
post
on
here
and
the
end.
N
This
situation
is
created
by
duress,
AMC
and
SMC
mixer
new
for
the
angels
to
to
steer
to
steer
the
teach
the
traffic
and
for
food
for
the
world.
Where
there
is
network
the
end
we
can
see
the
last.
We
can
see
that
the
red
line
is
a
pass
that
connected
her
trust.
Me
are
transmitted
aware
aware.
The
space
network
and
I
think
this
use
kiss
can
be
used
in
the
FRG
found
a
backhaul
network
service,
and
this
is
a
this
is
the
result
or
we
get
the
thicker.
F
F
F
N
N
F
N
F
C
N
For
now
there
it
is,
it
is
a
very
difficult
for
for
so
two
little
eyes.
They
are
because
they
are
very
the
distance-
it's
very
it's
very
long
and
that
later
can
can
very
hard
Toto
to
to
communicate
it's
a
very
hard
yeah,
but
this
the
working
they
work
in
this
draft
is
about
something
maybe
happen
in
the
future,
and
our
project
is
our
work
in
the
jobs
is
a
piece
down.
That's
our
project
and
our
project
is
someone
that
we
may
research
the
future.
The
future
technology
yeah.
F
H
I
just
a
truck:
this
might
not
be
the
right
forum
to
talk
about
Leo
to
geo
satellite
link
technology
instead
somewhere
about
the
the
DTM
transport
and
I.
If
I
think
I
understand
tell
Jim,
he
was
saying
that
this
is
a
prototype
implementation
to
test
the
use
of
DTN
for
the
management
rather
than
individual
satellite
technologies.
F
In
that
case,
I
have
a
slightly
more
relevant
follow-up
and
let
me
know
if
it
is
relevant
for
this
forum.
The
choice
of
using
a
Geo
asset
for
the
control
plane
is
interesting,
because
even
Meo
satellites
are
closer
to
the
earth
than
they
are
to
a
Geo
acid.
So
you
would
have
a
faster
connector
connection
to
a
ground
station
than
to
the
geo
satellite.
So.
H
I
I
It
is
one
of
the
reasons
why,
in
these
particular
instances,
many
organizations
don't
want
to
spend
the
money
to
try
and
make
them
and
make
them
reliable.
So
so,
when
we
talk
about
this,
are
you
changing
any
aspect
of
the
open
flow
or
the
Sdn
protocols
themselves,
or
are
you
only
tunneling
them
over
BP.
N
N
I
N
The
open
flow
just
adjust
the
worker
between
the
GAO
and
the
ami.
Also,
sir,
so
Canadian
data
also
contributor
are
not
stored
in
their
nose
adjust
the
package.
The
data
packets
are
stolen
on
the
nose
and
ER,
so
the
open
flow,
ignoring
the
adjuster,
can
choose
a
forwarding,
so
they
are
not
stored
in
there.
Yeah
you're
right.
N
Detra
are
not
restored
under
they
just
control
you
just
control
III
and
the
RTT
yet
about
it
here
between
the
Jo
and
the
MU
is
a
very
long,
but
in
our
experiment
it
it
was
okay,
it
is
okay
to
to
encapsulate
in
the
open
floor,
it's
a
movie
theater
in
in
the
payload
of
our
packet.
I
was
upon
a
packet
and
it
works
a
task.
It
has
worked.
Yeah.
K
N
Because
the
away
baby
uses
our
videos
DTM
in
there
in
the
home
in
your
home
in
the
network
and
the
way
junk
we
didn't
want,
a
vertical
transmission
in
the
network
in
the
u.s.
is
network
because
certain
notes
are
limited
in
their
being
in
processing
in
processing
capabilities,
so
the
whole
host
a
try
to
network
Arkansas
based
on
pigeon,
and
so
we
just
baby
of
only
and
we
believe
on.
We
don't.
We
don't
know
about
her,
a
better
control
in
the
satellite
network,
so
we
use
the
STL
means
and
I
need
Walker
Anders.
N
K
E
E
N
So
when
the
deter
translated
between
those
base,
interests
really
must
be
protocol
translation,
and
we
just
do
this-
we
just
we
just
gap
that
gangs
are
bound
to
the
payload
out
the
payload
of
their
of
their
TCP
packet
and
and
encapsulated
into
a
reputable
a
fondo
upon
a
packet
understand
to
another
and
and
a
zero.
Is
there
address
mapping
and
there
and
learning
the
other
way
Fernando.
The
IPM
IP
m113
is
is
an
app
tool
to
another
ipv6
or
ipv4
address,
and
then
there
weren't
so
transmission
occurs
so
that
the
condense
or
the
payload.
F
O
O
So
the
question
about
whether
we
need
a
two-phase
commit
or
whatever
is
really
a
choice
of
what
Sdn
protocol
is
used.
If
you
use
an
SDM
protocol
that
is
resilient
because
it's
got
an
acknowledgment,
then
then
the
network
will
not
get
out
of
phase
and
dgn
is
all
you
need.
If
you
use
a
an
SDN
protocol
that
makes
assumptions
like
it's
a
right
only
non
acknowledged
protocol,
then
yes,
you
will
get
synchronization
issues
so.
G
Schiaparelli
APL
two
things:
one
is
the
the
diagram
that
is
on
the
screen
right
now.
The
satellite
gateway
this
book
gate
weighing
between
a
tcp/ip
and
Bunnell
protocol
at
the
gets
allocated
way
clear
they
will
work.
I
would
propose
that
it
would
be
even
easier
to
to
run
bundle
protocol
underneath
the
application
data
from
the
ground
node
all
the
way
to
the
satellite
node
and
rather
than
gateway
and
just
have
this
satellite
gateway
instead
be
a
DTM
bundle
forward,
or
rather
than
an
address
matcher.
G
But
that's
a
we
don't
have
to
talk
about
that
right
now
and
I
just
think.
That's
a
cleaner,
easier
and
and
and
and
simpler
and
easier
to
manage
configuration
that
we
could
discuss.
The
other
thing
I
wanted
to
observe
is
that
I,
unfortunately,
don't
know
a
darn
thing
about
Sdn,
but
but
if
there's
a
if
there
is
an
issue
about.
G
Coordinating
Sdn
configuration
values
across
networks
so
that
everything
is
consistent.
Then
the
delay
tolerant
way
of
doing
that
would
be
to
encapsulate
the
Sdn
messages
in
I
think
in
in
time
tagged
messages
and
so
that
they
would
be
distributed
in
advance
of
the
time
that
they
need
to
become
effective
and
then
and
received
in
advance
and
and
held
pending
the
the
effect.
G
P
I
I
wonder
how
could
Gio's
ensure
the
control
of
the
envelopes
and
arrows?
Could
you
give
us
a
general
RTT
time
and
is
it
possible
that
the
whole
system
would
be
broken
when
gos
go
round
or
be
attacked
by
huge
amount
of
fake
forwarding
switches
and
since
the
number
of
gos
are
strictly
limited?
So
how
could
you
approach
the
security
issues
in
of
st
on
your
system?
Yeah.
N
You're
right
and
the
security
about
this
item
is
very
important.
Research
point
ie
our
attention
we
have
before
now
we
have,
we
have
three
cheese
at
right
and
aluminum
address.
The
bank
also
can
show
and,
for
example,
Oh
a
one
for
the
ones
Gio
is
attached,
or
at
the
police,
town
and
the
other.
The
other
satellite
will
take
our
ability
and
can
show
the
network
state
if
all
over
the
three,
if
all
over
the
3G,
also
transports
down
in
the
yeah.
N
N
P
J
P
G
G
Bt
SEC,
essentially
signatures
on
on
messages
and
and
for
all
the
forwarding
notes
that
that
can
pass
data
to
the
the
controller
to
require
that
the
the
Polaroids
of
our
of
the
messages
pass
integrity,
signature,
verification
before
they'll
get
forwarded
so
that
the
controller
is
shielded
from
inauthentic
traffic.
We
should
be
able
to
do
that
kind
of
thing
with
with
the
protocols
that
that
are
that
are
being
designed
and
that
have
been
prototyped
in
in
the
earlier
versions
of
the
DTM
DTN
stack.
B
H
M
B
Q
Q
So
the
motivation
for
this
particular
draft
is
on-demand.
Interactive
communications
cannot
be
assumed
in
the
DTN
model.
So
that's
one
reality.
The
other
one
is
today
for
key
management.
We
you
in,
for
example,
in
SSL.
We
have
certificates
and
for
revocation
we
have
online
certificate
status
protocol
and
these
require
interactions
near
real-time
interactions
and
so
that's
clearly
not
possible
in
the
DTN
communication
model.
So
we
need
DT
and
friendly
public
key
distribution
and
revocation
protocol
suite,
and
this
talk
is
about
that.
Q
Q
So
this
is
the
high
level
architecture
for
what
we
are
proposing
as
delayed
order
and
key
administration,
and
it's
actually
abstract.
So
the
there
are
three
entities,
key
owner
key
authority
and
key
user.
The
key
owner
is
the
person
or
the
entity
that
possesses
the
private
key
corresponding
to
the
public
key
that
needs
to
be
distributed.
Q
Q
So
we
we
see
the
key
authority
here
right,
so
the
key
Authority
in
the
abstract
flow
is
shown
as
a
single
block.
Now
that
is
a
requirement
for
delay-tolerant
key
administration,
that
there
should
be
no
single
point
of
failures
and
we
have
to
really
distribute
the
key
authority
to
multiple
entities
in
a
fail-safe
manner
and
how
we
do
that
is
this.
Q
So
that's
the
flow
over
from
this
slide
into
this
slide.
So
we
DTK
a
key
agents
and
a
bunch
of
these
DTK
icky
agents
act
as
the
key
authority
for
a
given
application
domain,
and
we
assume
that
all
the
DD
care
key
agents
are
are
connected
by
a
reliable
link
so
that
they
can
synchronize
the
authorities
in,
for
that
particular
entity
are
synchronized
within
each
other
and
the
communication
between
the
authorities
and
the
key
users
that
can
be
delay,
tolerant
and
the
communication
between
the
key
owner
and
authorities
that
can
also
be
delay
torrent.
Q
In
fact,
we
do
not
expect
any
real-time
communications
and
one
of
the
important
system
configuration
SPECT
here
is
the
public
key
of
all.
The
key
authorities
are
physically
configured
on
every
node.
That's
the
system
bootstrapping,
something
like
how
your
browsers
have
the
root
public
keys
in
them
when
they
are
installed.
So
this
is
something
like
that.
Q
So
coming
back
to
the
abstract
concept,
this
is
the
avoiding
the
single
point
of
trust
that
I
said
previously,
and
so
the
key
authority
role
is
distributed
amongst
multiple
key
agents
and-
and
we
will
talk
about
more
of
how
this
is
done-
how
it
is
distributed
and
how
it
is
made
failsafe.
We
are
going
to
talk
about
that,
so
we
will
now
concentrate
on
the
first
link
that
the
interaction
between
the
key
owner
and
the
key
Authority.
Q
We
call
that
the
node
key
registration-
and
this
is
a
protocol
where
the
key
owner
claims
a
particular
association
with
the
key
Authority
and
the
key
authority-
has
to
authenticate
it
and
see
if
that
association
is
acceptable
or
not,
and
we
in
the
draft
we
identify
two
such
company
modes
of
communication.
For
this
first
link.
One
is
an
out-of-band
bootstrapping.
This
could
be
a
USB,
a
link
so
they're
the
key
owner
which
will
have
to
create
a
USB,
give
it
to
an
authority.
Q
The
authority
will
physically
go
and
verify
and
if
it
is
valid,
accept
it.
That's
the
out-of-band
approach
and
that's
the
in
band
approach
also
possible
if
the
node
ID
was
issued
public
key
previously
or
previously,
the
key
Authority
accepted
a
node
ID
previously,
and
it
wants
to
get
a
new
public
key.
So
in
that
case,
the
in
Matt
in
band
is
okay,
so
both
are
allowed
in
the
draft.
Q
So
now
that
we
saw
how
the
key
owner
is
going
to
claim
a
particular
address,
key
association
with
the
key
authority,
the
next
phase
is
okay.
Now
the
key
Authority
has
accepted
the
tuple
as
authentic,
and
how
does
it
send
it
out?
So
it
has
to
send
a
list
of
authenticated
nor
a
it's
basically
bulking.
It's
a
bulk
sent,
so
it
have.
It
has
to
collect
all
the
authentications
from
key
owners
and
send
it
as
a
bulk.
Q
It
can't
send
one
if
it
wants
to,
but
if
the
Association
is
in
a
bulk
and
this
particular
communication,
we
we
assume
is
going
to
be
protected
by
the
bundle
integrity
block
of
DTN,
employing
the
key
authorities
private
key.
So
this
is
why
everybody
has
to
have
the
key
authorities
public
key
or
every
key
agents.
Public
key
must
be
available
with
everybody
in
the
system
and.
Q
Q
So
the
message
format
for
the
key
updates-
this
is
what
we
have
proposed
for
the
bulletin.
So
that's
the
list
of
key
authenticated,
node,
ID,
comma
key
tuples
and
the
bulletin
format
is
basically
there's
going
to
be
a
bulletin
hash.
So
this
will
be
formed
by
every
key
agent
that
belongs
to
the
aggregate
of
key
authority,
and
each
element
of
the
bulletin
will
have
a
key
information
mesh
message,
which
is
basically
a
node
ID,
effective
time
after
which
the
key
is
valid.
Q
B
H
Q
It
is
it
is,
it
is
like
we
will
see
that
we
have
to.
Eventually
we
are
not
going
to
send
this
bulletin
assets,
so
we
are
going
to
code
this
bulletin
and
send
so
this
bulletin
is
going
to
send
us
code
blocks
so
and
multiple
key
agents.
We
are
just
going
to
send
the
code
blocks
and
not
the
bulletin,
so
they
have
to
associate
the
various
code
blocks
and
and
the
key
hash
is
going
to
help
them
as
a
unique
pointer
from
multiple
people.
G
Schiaparelli
JK
I
was
just
to
interject.
Your
one
thing
that
may
not
have
been
clear
is
that,
before
the
the
list
of
authenticated,
node,
IDs
and
and
and
public
keys
is
issued,
that
that
bulletin
has
to
be
has
to
be
developed
as
a
consensus
among
all
of
the
agents
of
the
distributed
key
authority
and
that
so
that
that
single
bulletin
has
to
be
bit
for
bit
identical
as
distributed
by
each
of
the
agents
individually
and
the
bulletin.
Q
Q
Again,
as
Scott
said,
every
key
agent
must
use
the
same
bulletin
in
the
same
bit
order
and
that's
why
the
hash
ensures
that
the
bit
order
is
correct
between
all
of
them
and
so
q
q+
k,
racial
coding
is
done
at
the
authority
x
and
it's
it's
a
little
bit
more
than
a
racial
coding.
We
will
come
to
that
in
the
next
slide,
but
q
progress,
Q,
plus
K
ratio
coding
is
performed
and
what
is
sent
on
the
wire
is
actually
the
code
blocks.
Q
That's
figure
four
and
that's
a
bulletin
hash,
which
is
carried
over
from
the
bulletin
code
block
number,
which
is
assigned
for
that
particular
key
authority.
What
a
set
of
code
block
numbers
that
that
authority
is
allowed
to
transmit
and
the
code
blocks
themselves
now,
as
I
said
previously,
this
code,
these
code
blocks
the
security
for
this
is
over
the
bundle
integrity
block
so
there.
So
when
we
send
it,
that
is
a
natural
signature.
That's
present
in
the
bundle,
integrity
block
and
everybody
gets
a
signed
copy
of
this
code
block.
Q
So
we
are
not
dealing
with
that.
Vp
SEC
will
take
care
of
that,
and
just
this
is
a
fictitious
example
that
we
have
proposed
of
how
we
can
make
assign
a
particular
code
block
number
for
a
particular
key
agent
right
so
over
here.
It's
a
7
+
1
e
ratio
coding
that
we
assume
is
used,
and
we
assume
that
five
out
of
eight
key
authorities,
the
code
blocks
from
five
out
of
eight
key
authorities,
are
have
to
be
received
before
the
bulletin
is
reconstructed
minimally,
five
out
of
eight.
Q
Q
So,
for
example
over
here
we
have
eight
key
authorities:
ka
1,
2,
K
8,
and
because
we
have
a
7
plus
1
coding,
we
have
blocks
0
to
7
for
a
particular
block
and
what
what
we
do
is
we
assign
we
inform
like
it's
again.
This
is
a
system
level
configuration
that
every
user
is
told
that
these
are
the
like
ka
one
will
only
transmit
code
block
numbers,
0,
1,
&
2.
Q
If
any
other
code
block
is
received
by
K
from
K,
a
one
that
is
ignored.
So
this
is
a
system
spaz
configuration
system
security
configuration
that
is,
that
is
configured
manually
just
like
the
root
public
key
configuration
is
configured
manually
on
every
node,
so
we
have
K
1
2,
K
8
3
blocks
each
and
you
can
see
that
to
get
at
least
seven
blocks.
They
have
to
wait
for
messages
from
at
least
five
key
authorities,
for
example
K
1,
2,
3,
4
5.
Q
Q
Dtk
is
a
public
key
distribution
and
revocation
mechanism
for
BTN,
and
it
uses
bundle,
protocol,
Security's,
bodily
integrity
block
to
provide
non-repudiation
and
authentication,
and
it
uses
q
plus
key
racial
coding
to
distribute
trust
in
key
authorities,
and
it
is
configurable.
The
number
of
key
authorities
is
configurable
and
the
idea
of
a
key
Authority,
many
key
authorities
aggregating
into
a
mini
key
agents
aggregating
into
a
key
Authority,
is
to
realize
no
single
point
of
failure
requirement
for
GDK
and
the
details
are
in
Internet
traffic.
Thank
you.
H
B
H
Q
Know,
I
think
the
reason
it's
not
like
this
is
a
minimal
information
set.
So
here
we
so
that's
one
assumption
in
DTN
that
is
inherent
is
the
clocks
in
every
DT
and
node
is
synchronized.
That's
one
assumption
and
we
actually
carry
that
assumption
forward
by
saying.
Okay,
now
that
the
clocks
in
every
DT
and
node
is
synchronous
with
a
little
bit
of
drift,
maybe
a
few
seconds
rift
is
tolerable
and
then
the
key
effective
time
is
a
synchronization
at
future
point
in
time.
Q
H
Yeah
I
understand
the
fact
that
you
can
you
can
pin
when
this
halogen
hash
should
come
into
into
into
effect.
My
question
is:
if
a
node
has
been
a
key
user
note
has
been
out
for
a
long
time.
Away
from
the
system
comes
back,
receives
a
whole
batch
of
of
bulletin
hashes
right
all
right
and
doesn't
know
that
when
missies
were
sufficient.
B
I
H
H
Q
G
All
right,
if
you
know
that
that's
what
I
thought
the
question
was
going
to
be
I
had
an
answer
for
which
is
that
the
synchronization
of
time
across
the
nodes
is
done
necessarily
critical,
because
the
application
of
the
keys
by
effective
time
is
on
the
basis
of
the
bundle
creation
time,
and
so
it
doesn't,
even
if
the
even
if
your
clocks
are
wildly
off,
you
apply
the
public
key
that
that
matches
the
creation
time
of
the
bundle
to
which
the
public
key
is
being
applied.
But
I
understand,
that's
not
the
question.
G
B
G
If
what,
if
bundled
what,
if
I
pull
them,
gets
missed
all
together,
what
do
you
do
about
that
and
I
think
it's
a
really
good
thing
to
consider.
The
one
other
thing
I
wanted
to
mention
is:
it
might
not
have
been
clear
from
the
way
the
overlap
diagram
was
built,
I
mean
the
intent
of
that
overlap
is
is
to
ensure
that
not
only
is
there
no
single
point
of
failure,
there's
also
no
single
point
of
authority.
That
is
no
single
bundle.
Agent
is
allowed
to
say
here's
what
the
bulletin
is.
G
It
has
to
be
a
consensus,
and
that's
that's
why
only
a
subset
of
the
bulletin
can
be
issued
by
each
node,
and
not
only
can
there
be
no
single
point
of
failure
and
no
single
point
of
authority,
but
also
no
single
point
of
veto.
That
is
no
single
note
that
decides
to
issue
you
know
junk
information
can
sabotage
the
system.
I
Right
at
brain
APL,
when,
when
we
talked
about
the
thresholds
for
the
for
the
actions
except
a
key
revoke,
a
key
role
over
a
key,
is
there
a
concept
in
the
spec
of
being
able
to
have
different
thresholds
per
action?
So
the
question
would
be,
would
you
can?
Would
you
consider
a
time
in
which
the
the
the
number
of
key
authorities
necessary
to
add
a
key
is
different
than
the
number
of
key
authorities
necessary
to
revoke
a
key.
I
The
vulnerabilities
are
a
little
bit
different.
You
know
if
I
come
back
and
say:
I
have
a
higher
burden
of
proof
to
accept
a
key,
because
I
don't
want
to
use
a
key.
That
is
wrong.
Is
there
a
lesser
burden
of
proof
to
revoke
a
key,
because
if
a
key
is
revoked,
but
it's
going
to
take
me
a
certain
amount
of
time
before
I
see
enough
key
Authority
messages.
I
Q
I
Q
Yes,
so
that's
a
configuration
by
the
way,
so
the
T
out
of
n
is
a
configuration
for
the
operation,
so
they
could
actually
do
one
out
of
one,
in
which
case
it's
a
veto
if
they
say
one
out
of
two
one
out
of
three
so
that
we,
that
actually
so
we
provide
the
mechanism
to
have
a
liberal
policy.
But
the
policy
is
actually
a
configuration
detail
of
the
operation.
Okay,.
Q
Q
I
There
may
be
cases
there
may
be
network
deployments
where
I
need
five
I
need
five
or
six
key
authorities
to
agree
on
a
key
before
I.
Add
it,
but
if
any
three
revoke
that
I'm
going
to
revoke
that
may
be
a
function
of
the
dynamics
of
my
network
and
and
how
rapidly
I
need
to
revoke
a
key
versus
how
long
I'm
willing
to
wait
before
I
accept
the
key
got.
H
It
I
saw
a
Rick
Tyler,
just
jumping
the
queue
slightly
personally.
I
can
see
that
being
quite
difficult
with
this,
because
you
wouldn't
know
whether
the
bullet,
whether
you
were
allowed
to
accept
the
bullet,
in
with
your
queue
out
of
T,
continued
accepted,
The,
Bulletin,
so
I
think
it's
meta
information
I
agree
with
you
that
this
is
config
how
you
would
dynamically
alter
the
config,
maybe
another
whole
protocol
yeah.
H
B
G
I
a
concept
here
has
been
that
the
key
revocation
can
be
just
as
mischievous
as
as
false
key
distribution,
so
it
may
be.
A
different
level
of
scrutiny
applies,
but
but
that
that
in
itself
seems
dangerous
to
me.
But
if
you
needed
it,
then
I
think
it
would
have
to
be
a
separate.
The
way
this
is
designed,
it
would
have
to
be
a
separate
channel.
You
have
to
have
like
a
channel
for
P
distribution
and
a
separate
channel
with
a
different
set
of
configuration
parameters
for
revocations.
G
H
G
P
H
Q
H
D
B
H
B
E
D
H
E
Thank
you
Brian,
so
if
there's
any
other,
no
other
comments
would
like
to
summarize.
Were
you
know
next
steps
we
will
be
sending
the
BP
best
to
is
G
we're
waiting
for
the
write-up
of
the
document
shepherd
as
soon
as
it's
there
then
we're
sent
it
to
the
is
G
TCP
CL
will,
as
we
just
described,
discuss,
will
be
waiting
for
review
and
final
final
draft,
and
we
will
send
this
to
the
AIA
G
on
this
there's
a
big
change.
You
know
the
spec
which
we
are
aren't
seeing
at
the
moment.
E
We
will
ask
working
group
to
adopt
the
custody
transfer
draft
to
be
a
working
group
item.
The
last
working
group
for
a
working
group
adoption
for
the
Seifer
Interop
draft
will
ask
a
security,
Directorate
review
for
the
BP
SEC
we'll
do
a
working
group
last
call
on
BP,
SEC
and
we'll
ask
a
working
group
adoption
for
the
draft.
Dt
nama,
that's
kind
of
a
large
pile
of
things
so
expect
a
lot
of
emails
in
the
next
weeks
for
all
those
adoptions
requests
and
things
like
that.