►
From YouTube: IETF112-DTN-20211112-1200
Description
DTN meeting session at IETF112
2021/11/12 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Good
morning,
everyone
or
good
evening
or
good
day
or
good
whenever
it
is
welcome
to
ietf
112.
a
the
time,
is
12
o'clock
utc.
So
I
think
we're
probably
going
to
start.
No,
we
are
going
to
start
there's
no
probably
about
it.
I
hope
you
can
hear
me
can.
Can
somebody
say?
Yes,
if
you
can
yeah?
Thank
you
ed,
so
I'm
rick
who's
speaking
ed
is
the
other
person
who's
currently
streaming
video.
A
We
are
your
chairs,
and
this
is
the
dtn
working
group
meeting
at
ietf,
one
one
two
so
just
to
go
through
some
administrivia
to
start
with
this
session
is
being
recorded
by
opening
your
mic
or
turning
on
your
camera,
you
are
agreeing
to
agreeing
that
anything.
You
say
or
or
wave
will
be
recorded
in
as
in
the
public
domain
and
will
be
displayed
on
youtube
in
the
future.
A
So
for
reference
on
that,
there
is
the
I'll
come
to
that
on
the
note
well
in
a
second,
so
our
agenda
is
at
this
url,
but
I
will
present
it
as
well.
There
is
a
participant
guide
for
using
meet
echo.
I
know
we
are
all
mostly
familiar
with
this,
but
there
may
be
some
new
attendees
who
aren't
if
you
follow
that
url
there
is
a
good
explanation
on
how
to
use
meat
echo.
Obviously
this
is
a
bit
of
a
catch-22.
A
If
you
are
listening
or
hearing
me
now
that
implies.
You
have
managed
to
get
into
me
echo
in
some
way,
there's
also
a
way
to
report
technical
issues
if
you
have
any
so
this
is
the
standard
ietf
note
well,
this
covers
the
code
of
conduct,
the
rules
and
behaviors
the
basic
background
to
the
ietf
processes.
A
How
the
ietf
works,
how
the
working
group
works,
how
one
is
expected
to
behave?
What
happens
if
you
have
difficulty
with
the
behavior
of
other
people
or
you
behave
in
a
manner
that
is
not
seen
as
the
way
the
ietf
wishes
to
hold
their
proceedings?
There
is
also
important
information
in
bcp,
78
and
bcp
79
concerning
ipr
copyright
patents
and
how
you
participate
in
the
itf.
If
you
have
not
read
these
recently,
I
do
recommend
you
read
them,
including
the
privacy
policy.
Here's
a
short
summary:
the
chairs
can
help.
A
If
you
have
questions-
and
we
can
forward
your
questions
to
members
of
the
ombuds
team,
if
we
are
unable
to
help
or
you
feel
that
we
can't
so
the
agenda
for
today's
meeting,
we
are
currently
covering
the
10-minute
discussion
from
the
chairs
about
admin.
A
I
know
at
the
last
ietf
meeting
we
discussed
proposed
text.
The
working
group
came
up
with
some
proposed
text
since
then,
the
chairs,
our
ads
ahead
and
the
iesg
have
been
wrangling
over
various
use
of
various
terminology.
What
the
isg
would
like
to
see
as
compared
to
what
the
working
group
would
like
to
see
and
we've
got
a
report
from
the
chairs
on
how
that
progressed.
A
Then
we
will
have
a
couple
of
presentations
about
some
of
the
bpv7
type
stuff,
a
wireshark
desector
from
brian
some,
an
update
from
brian
on
the
cozy
security
context.
Work.
Scott
burley
then
has
an
interesting
presentation
about
scaling
dtm
out
to
bigger
networks.
A
I'll
have
a
comment
about
that
before
he
actually
starts,
but
having
had
a
sneak
preview
of
his
slides.
I
think
that's
interesting
he's
got
a
25-minute
slot
because
he
covers
a
lot
of
subjects.
A
We
then
have
asynchronous
management
architecture
update
from
emery,
which
will
be
relevant,
particularly
in
light
of
the
charter
updates
and
the
proposed
new
charter,
and
then
sarah
has
a
shortage
presentation,
I'm
afraid
she's
been
a
bit
squeezed
for
time
talking
about
network
management
in
challenged
environments
and
some
tooling
around
that
we
also
have
a
10
minute
section
for
any
other
business
in
open
mic.
So
I
think
we
would
prefer
to
have
discussion
about
individual
topics
squeezed
in
at
the
end
of
each
presentation.
A
But
if
there's
general
discussion
that
isn't
covered
by
any
of
the
presentations
that
10
minute
slot
is
the
perfect
time
for
that.
A
A
It's
got
really
good
in
my
opinion,
but
of
course,
if
we
have
lots
of
participants,
then
obviously
in
the
world
of
streaming,
video
things
can
get
a
bit
laggy,
particularly
if
you
have
a
long
latency
link,
please
be
patient
when
turning
on
your
mic
and
before
speaking,
because
there
is
a
round
trip
time,
it's
not
on
the
delay,
tolerance
scale,
but
it
still
can
be
tens
to
hundreds
of
milliseconds,
so
just
be
patient,
but
in
this
covid
era
I
think
we're
all
a
lot
more
experienced
with
video
conferencing
systems.
A
More
importantly,
is
the
minute
taking
so
cody
md
is
the
interactive
multi-person
markdown
based
editing
system
that
is
built
into
meet
echo?
I
believe
the
relevant
button
is
on
the
toolbar
on
the
top
right
of
meat
echo.
Please
help
contribute
to
the
note-taking.
I
know
adam.
Our
secretary
is
intending
to
take
notes
as
fast
as
he
can.
A
Please
help
him
out
if
somebody,
if
he
mistypes
somebody's
name
or
mistypes
your
point,
it's
worth
just
double
checking,
particularly
if
you
ask
a
question
or
respond
to
a
question
that
that's
been
captured
correctly
and
also
just
help
out
we're
trying
to
be
collaborative
about
this
also
important
information.
So
the
mailing
list,
dtn
ietf.org,
is
where
the
main
procedures
of
the
ietf
are
actually
handled.
So
that
is
the
canonical
reference
for
decision
making
and
the
really
good
place
for
discussion
on
subjects.
According
that
the
working
group
are
working
on.
A
If
you
wish
to
contact
the
chairs,
please
use
the
dtn
hyphen
chairs
at
iatf.org
and
that
will
get
to
ed
and
myself
and
it
also
gets
to
the
ad.
So
if
you've
got
administration,
questions
queries
about
working
group
process
topics,
that's
a
good
place.
If
it's
about
technicalities,
the
dtm
mailing
main
investors,
the
right
place
to
go,
we're
the
chairs,
not
the
de
facto
experts
in
this
field,
so
very
quickly
document
status.
A
So
many
of
you
are
probably
aware
that
there
have
been
the
big
four
documents
that
we
have
been
desperately
waiting
to
complete
as
part
of
the
current
charter
cycle.
They
being
bundled
protocol
version
7,
bp,
sec,
a
default
security
context
for
bp
sec
and
the
tcp
based
convergence
layer,
which
is
tcpcl
version,
4.
good
news.
They
are
all
at
the
rfc
editor
state.
That
means
the
rfc
edit
editorial
team
is
actively
working
on
the
documents
to
make
sure
the
language
is
accessible
for,
particularly
for
non-native
speakers.
A
This
is
an
important
part
of
the
rfc
editorial
team's
objective
and
also
to
make
sure
the
documents
are
internally
consistent
and
do
all
the
good
work
that
that
an
editor
does
and
they're
a
good
team.
So
they
expect
to
have
completed
that
work
in
the
next
two
weeks.
According
to
the
correspondence
the
chairs
have
had
with
them,
which
is
fantastic
news
at
that
point,
the
documents
will
reach
what's
called
auth,
48,
state
or
48.
For
those
who
don't
know
is
the
48
hours.
A
The
authors
have
to
respond
to
the
edits
that
the
editor
has
made
to
say.
Yes,
I
approve.
No,
I
don't
approve,
although
it's
called
all
48
states.
Sometimes
it
can
drag
on
a
little
bit,
particularly
when
authors
have
aren't
paying
attention
because
they
were
involved
at
the
beginning
and
not
at
the
end
of
a
document
etc.
The
good
news
is
the
all
the
authors
whose
names
are
on
those
four
documents
have
all
already
responded
to
the
chairs
to
say
yes,
I'm
here
the
email
address
is
valid
and
I
am
very
happy
to.
A
I
am
prepared
for
the
auth
48
state
and
to
reply
promptly
to
the
rfc
editor,
which
means
with
luck.
We
should
have
four
rfcs
before
the
end
of
the
year.
That's
what
we're
really
hoping
and
if
that
comes
to
pass,
that
would
be
a
fantastic
end
of
year
for
the
working
group
and
would
nicely
close
off
this
charter
cycle
with
four
rfcs,
and
I
think
we
should
all
be
very
pleased
to
see
that
happen.
A
So
I'm
going
to
hand
over
to
ed's
now
to
talk
about
the
working
group
charter
in
some
detail.
Well
I'll
cover
some
of
the
later
parts,
but
ed
do
take
over
and
shout
next,
when
you
want
me
to
change
the
slides.
B
Someone
someone
keeps
muting
me,
so
I
think
I
think
you
can
hear
me
now.
Okay,
so
yes,
now
now
that
we
have
that
hope
of
getting
four
rfcs
through
by
the
end
of
the
year.
The
next
obvious
question
is
what
next
we've
talked
about
that
significantly,
both
in
the
mailing
list
and
at
prior
dtm
working
group
meetings,
and
we
did
propose
an
initial
charter
and
that
initial
charter,
when
it
went
through
iesg
review,
came
back
with
some
excellent
comments
and
then
two
comments
that
were
blocking.
I
think
it's
important.
B
B
They
are
typically
have
you
thought
about
this,
or
will
you
be
sure
to
review
things
with
us,
and
that
was
the
nature
of
the
blocks
that
we
saw
for
this
for
our
proposed
charter
work
and
the
two
blocks
that
came
from
different
areas
were
from
the
ops
area
related
to
network
management
and
from
the
routing
area
related
to
anything
associated
with
routing
work,
and
even
though,
when
we
walk
through
our
charter
in
a
few
slides,
we
make
specific
statements
about
what
we
want
and
don't
want
to
do
relative
to
routing.
B
We
want
to
make
sure
that
we
are
always
working
with
the
the
appropriate
areas
and
working
groups.
The
important
part
of
this
is
that
rick
and
I
have
negotiated
this
from
a
charter
perspective.
We
have
not
significantly
changed
the
work
that
we
want
to
accomplish
in
this
charter,
but
we
have
been
able
to
explain
how
the
work
is
focused
on
challenge
networks.
B
The
blocks
have
been
removed,
the
charter
text
has
been
updated
and
this
will
go
into
the
telechat
for
december
12th
and
we
we
are
certainly
hopeful
and
expect
that
the
charter
would
then
be
approved
and
we
are
proceeding
as
if
this
will
be
our
charter
unless
zahed
says
something
different.
C
No,
I
am
just
I
turn
on
my
audio
and
video
just
to
confirm
the
yes.
That
has
been
the
case,
and
this
is
now
from
yesterday
on
the
external
review.
C
So
that's
the
next
phase
and
then
we'll
see
if
how
the
it
approves
or
not.
We
might
get
some
comments
that
we
need
to
handle
it,
but
yeah
we'll
see.
B
And
by
the
way,
all
of
the
comments
that
we
received,
blocking
or
not
were
were
very
good
comments
and,
and
we
did
incorporate
and
respond
to
all
of
them.
We
didn't
turn
away
any
of
them
or
say
that
we
disagreed
with
any
of
them,
and
that
has
been
the
nature
of
the
review
of
ietf
in
general.
The
technical
review
that
we've
gotten
through
all
of
this
work
is
is
just
terrific
and,
and
we
are
appreciative
of
it.
C
C
This
work
in
the
same
same
spirit
and
obviously
we
have
some
challenges
like
I
mean
we're
sitting
in
a
traps,
transport
area,
and
we
have
lots
of
things
to
do
on
the
ops
and
other
areas,
but
we
are
we're
very
used
to
with
this
environment
right.
So
that's
not
a
surprise
for
us.
So
let's
continue
doing
the
good
work
and
hopefully
the
recharger
will
complete
by
the
december
12th
until
this
year.
B
Absolutely
so
rick
if
we
go
to
the
next
slide.
If
we
were
to
take
a
step
back
and
look
at
the
kind
of
blocking
statements
that
were
on
that
charter,
they
they
really
came
down
to
a
common
concern,
and
that
is
that
dtn
delay
and
disruption.
Tolerant,
networking
touches
lots
of
topics
and
not
just
topics
that
are
restricted
in
an
ietf
sense
to
the
transport
area,
to
the
transport
area.
B
We
are
driven
by
the
fundamental
challenges
of
our
transport
layer
and
the
challenges
of
our
network
environment
in
which
we
have
to
exist.
And
therefore,
some
of
the
things
that
we
need
to
do
in
security
in
network
management
and
routing,
and
so
on,
will
also
be
driven
by
a
deep
understanding
of
our
transport,
which
is
a
little
bit
different
than
the
transport
that
others
have
for
the
bulk
of
the
work
in
these
other
working
groups.
And
so
you
know.
B
For
that
reason,
we
do
think
that
the
work
is
still
reasonable
to
perform
right
here,
because
this
is
the
community
that
understands
the
challenged
environments
in
which
we
would
be
operating.
However,
we
do
need
to
be
much
more
involved
with
soliciting
good
inputs,
technical
review
and
staying
in
touch
with
and
synchronized
with
all
of
the
work
that
is
going
on
in
the
other
area,
director
of
in
the
other
areas.
B
So
at
the
end
of
the
charter,
we
sort
of
addressed
this
overarching
concern
by
saying
that
we
will
coordinate
with
other
ietf
working
groups,
particularly,
we
call
out
security,
routing
operation
management
areas
and
we
make
sure
that
we're
going
to
get
early
peer
review.
B
While
we
are
developing
all
of
our
work,
as
opposed
to
waiting
until
last
calls
or
waiting
until
a
higher
level
of
you,
know,
ietf
wide
reviews
when
at
that
point
a
lot
of
the
the
day-to-day
technical
back
and
forth
has
already
been
done,
and
I
think
that
just
simply
making
sure
that
we
understand
that
and
we
communicate
that
to
the
other
areas
has
gone
a
long
way
in
making
sure
that
everyone
understands
that
we
are
trying
to
both
satisfy
the
unique
portions
of
the
environments
in
which
we
operate
while
recognizing
the
work
that's
going
on
by
others,
so
rick.
B
B
It
spent
a
little
bit
of
time,
looking
at
prior
work
associated
with
snmp
and
netconf,
and
the
network
assumptions
associated
with
that
proposed
some
autonomy
models
and
also
some
additional
ways
in
which
a
dtn
would
like
to
manage
sort
of
a
local
autonomy
and
how
all
of
that
would
work
in
a
very
challenged
and
disrupted
environment.
B
When
that
document
adopted
by
the
working
group
and
went
into
larger
last
call,
the
ops
area
came
back
and
they
felt
that
that
ama
did
not
really
address
recent
work
in
netmod
and
in
other
areas
to
talk
about
asynchronous
management
and
asynchronous
management
could
be
rest.
Comp,
asynchronous
management
could
be
yang.
Push
asynchronous
management
could
be
some
of
the
additional
things
coming
out
of
yang1.1,
simply
titling,
something
asynchronous
does
not
mean
appropriate
for
dtn
or
autonomous
or
able
to
operate
in
a
challenged
environment.
B
So
simply
titling
our
architecture
and
asynchronous
management
architecture
is,
is
not
really
focusing
on
the
unique
needs
of
a
challenged
environment,
and
certainly
the
operations
area
asked
for
clarification
on
what
what
we
meant
when
we
said
asynchronous
management.
So
to
that
end,
we
have
decided.
We
absolutely
need
to
clarify
that,
and
so
the
ama
document
will
be
reissued
to
be
called
something
like
the
delay,
tolerant
network
management
architecture
or
challenge
network
management,
architecture
or
something
similar,
so
that
we
understand
it's
not
just
asynchronous.
You
can
have
a
synchronous
that
doesn't
solve
dtn
problems,
for
example.
B
We're
going
to
make
sure
that,
as
we
update
that
architecture,
we
will
analyze
the
existing
asynchronous
work.
That's
coming
out
of
the
other
operations
area
and
to
make
sure
that
we
express
the
needs
of
a
challenged
environment
in
particular
to
ground
it
into
the
unique
characteristics
of
our
transport,
and
then
we're
going
to
use
this
document
as
well
as
both
a
chance
to
synchronize
with
the
other
areas
and
to
do
a
gap.
Analysis
of
those
existing
itf
management
protocols
against
the
needs
of
dtn.
B
But
that's
the
work
of
the
working
group
to
figure
out
as
we
get
through,
that
we're
going
to
then
go
through
another
round
of
technical
review
and
last
call
again
reaching
out
to
the
net
net
mod
community
in
the
ops
area
in
general,
and
this
will
be
the
first
of
many
interactions
where
we
get
that
that
cross
area
review
of
the
work
that
we
are
doing.
B
And
then,
and
then
so
the
then
the
last
part
is
just
well
what
about
the
rest
of
the
work
we
have
in
addition
to
the
ama,
we
have
application
data
models,
we
have
asynchronous
management
protocol
and
the
seaborne
codings
thereof.
So
once
we
have
the
architecture
complete
once
we
have
that
gap,
analysis
complete
once
we
have
incorporated
and
reviewed
what
that
looks
like
elsewhere
else.
Otherwise,
then
we
will
go
back
and
look
at
what
is
the
transport
of
management
information
between
devices?
B
Look
like
what
are
the
efficient
encodings
and
do
we
already
have
those
efficient
encodings
by
adopting
some
of
the
existing
standards?
How
do
we
express
the
need
for
deterministic
autonomous
operations?
We
do
have
some
ideas
as
how
all
of
that
will
fit
in
and
and
sort
of.
The
last
thing
that
I
wanted
to
make
sure
becomes
very
clear,
particularly
for
the
folks
who've
been
working
on
what
we've
termed
the
asynchronous
management
architecture
for
really
a
few
years
now.
B
None
of
this
stops
the
fundamental
work
or
the
problem
that
we're
trying
to
solve,
which
is
simply
that
managing
things
across
a
highly
a
delayed
or
highly
disrupted
network
is
a
difficult
problem
that
is
not
well
solved
yet,
and
we
do
have
unique
aspects
to
this.
We
may
reorganize
some
of
these
documents.
B
What's
going
to
happen,
is
we're
going
to
get
a
lot
of
very
good
technical
review
and
we
will
appreciate
it
and
at
the
end
of
that,
I
think
we're
going
to
have
a
much
better
technical
solution
that
integrates
much
better
with
tooling
across
the
ietf
and
frankly
becomes
an
awful
lot
easier
to
talk
to
with
other
network
management
experts,
because
then
they
can
start
seeing
in
terminology
and
in
architecture
and
structure,
things
that
make
sense
for
for
how
terrestrial
management
is
done
or
more
terrestrial
management
is
done.
B
A
I'll
turn
my
mic
on,
so
the
other
block
really
came
from
the
rooting
ads,
who
had
a
concern
that
very
similar
to
the
to
the
concern
that
the
ops
area
had
or
several
of
the
other
areas
had,
which
was
the
routing
area,
has
the
experts
in
routing
and
and
many
many
years
of
expertise
in
solving
and
understanding
the
multiple
different
problems
that
exist
within
routing?
And
although
there
was
a
good
understanding
that
dtn's
have
subtly
different
challenges
when
it
comes
to
routing,
they
really
do
want
to
be
involved
in
routing.
A
So,
as
we
discussed
at
itf
at
the
last
ietf
routing
is
explicitly
out
of
scope
for
the
next
charter
for
the
for
the
new
charter.
I'll
call
it,
and
the
reason
for
that
is
is
is
pretty
simple.
A
We
have
to
be
pragmatic
and
set
ourselves
achievable
goals
without
naming
an
addressing
framework,
a
concept
for
forwarding
and
neighbour
discovery
and
all
the
building
blocks
that
are
required
for
routing.
A
We
shouldn't
go
standardizing
routing
protocols,
because
we
will
have
to
immediately
update
them
or
discover
that
the
scaffolding
on
which
they
stand
is
completely
incorrect
or
incomplete.
I
I
think
it's
ill-advised
and
the
consensus
of
the
working
group.
As
of
the
last
ietf
was
yes,
we
will
not
tackle
rooting.
However,
the
chairs
did
feel
that
there
was.
It
was
worth
having
a
line
in
the
charter
to
explicitly
say
that,
because
routing
is
such
an
attractive
thing
to
look
at
rooting
in
dtns
is
is,
is
a
great
subject
and
is
required.
A
A
A
We
have
added
extra
text
to
make
sure
that,
alongside
the
statement
about
routing
is
out
of
scope,
but
also
to
say
that
when
routing
does
fall
into
scope,
it
will
be
done
hand
in
hand
with
the
routing
area.
Now.
This
may
be
the
case
that
in
two
or
three
years
time,
when
we
come
to
recharter
that
we
actually
say
well,
perhaps
there
should
be
a
dtn
routing
group
as
part
of
the
routing
area.
Perhaps
there
should
be
a
space-based
routing
group,
because
I
know
there's
a
lot
of
interest
about
leo
satellite
swarms.
A
Perhaps
you
know
a
working
group
which
looks
at
space
routing
problems
that
exists
within
the
routing
routing
area
might
be
a
good
idea.
This
is
the
future,
but
what
we
did
want
to
state
was.
We
are
not
ignoring
routing
when
we
discuss
routing
it's
that.
Quite
it's
really
that
simple,
and
by
explaining
that
and
making
that
clear
in
the
charter,
the
the
routing
80
was
absolutely
fine
to
lift
his
block.
A
The
other
comment
made
by
the
rooting
ad
was
the
mana
working
group,
which
is
the
mobile
ad
hoc
networking
working
group,
which
many
of
you
are
very
familiar
with,
which
lives
inside
the
routing
area.
They
have
a
working
group
charter
item
called
covering
management
for
mobile
ad
hoc
networks.
A
Now
they
have
currently
not
got
good
working
group
documents
on
management
and
also
have
looked
at
what
this
working
group
is
proposing
in
terms
of
ama,
which
we
should
no
longer
call
asynchronous
management,
but
looking
at
some
of
the
approaches
we're
taking
for
challenged
environment
management,
particularly
for
dtns-
and
they
are
very
interested
in
what
will
read
across
to
the
mani
challenges
from
the
dtn
challenges
and
whether
actually
they
could
lean
heavily
on
the
work.
A
That's
happening
in
this
group,
perhaps
extending
or
collaborating
to
make
sure
that
work
has
applicability
in
many
or
not.
So
to
that
end,
we
have
also
specified
that
we
will
liaise
with
the
money
working
group
as
we
work
on
some
of
the
management
issues
and
ed
is
presenting
in
the
money
working
group
session
three
today.
So
that's
three
and
a
half
hours
from
now
and
I
also
happen
to
know
a
number
of
the
participants
in
dtn
also
participate
in
manet,
because
there's
obvious
crossover
between
the
two
areas.
A
So
by
covering
those
two
points,
we
managed
to
lift
the
block.
We
satisfied
alvaro
the
routing
area
a.d,
who
performed
the
review
and
said
hold
on
I've,
got
issues.
We
satisfied
him
and
we
can
move
forwards.
A
What's
last
so
the
final
piece-
and
this
is
really
feedback
from
our
our
own
80s
ahead,
which
is
at
the
end
of
the
charter.
We
propose
some
milestones
and
these
are
the
same
milestones
we
discussed
at
the
last
ietf
meeting,
really
we
need
to
when
the
charter
is
approved.
We
need
to
insert
these
milestones
into
the
data
tracker.
To
say
this
is
what
we're
working
on
and
associated
with
every
milestone
is
a
date.
A
When
do
we
think
we
will
have
each
of
these
documents
ready
for
working
group
adoption?
We
can
then
try
and
predict
whether
they'll
be
ready
for
when
they'll
be
ready
for
iesg
review.
But
I
understand
that
is
quite
a
big
guesstimate,
but
we
do
need
to
associate
dates
with
these
milestones
so
that
ed
and
I,
as
chairs,
can
get
these
correctly
put
into
the
data
tracker.
This
is
it's
always
difficult
to
estimate
how
long
it
will
take
to
come
up
with
documents
and
particularly
when
the
content
is,
is
bleeding
edge.
A
However,
there
is
validity
in
having
these
dates,
because
it
gives
guidance
to
external,
sdos
and
other
organizations
who
are
watching
the
progress
of
this
working
group,
and
it
gives
them
some
idea
of
what
we
believe
we
will
achieve
the
time
scales
in
which
we
will
achieve
those.
So,
although
it
sounds
a
little
bit
like
we're,
making
work
for
ourselves
by
trying
to
guess
when
we're
going
to
do
these
things,
the
benefit
of
having
even
a
guess
of
a
date
we
would
like
to
achieve
by
date
is
better
than
having
no
date
at
all.
A
So
to
that
end,
when
people
present
on
some
of
these
subjects-
and
I
don't
actually
think
anyone
is
presenting
on
any
of
these
subjects-
sorry
I'll
take
that
back.
There
are
authors
who
have
personal
drafts
which
cover
some
of
these
documents
and
some
of
these
topics-
and
I
know
there
are
people
who
have
stepped
to
the
mic
in
previous
ietfs
to
say
I
am
really
interested
in
working
on
this.
A
I
am
really
looking
to
those
people
to
provide
information
on
the
mailing
list
to
say
yes,
I
want
to
do
it
or,
yes,
I
am
doing
it
and
I
think
I
can
have
this
document
ready
for
working
group.
Adoption
I.e.
Their
personal
thoughts
are
down
and
concrete,
and
now
we're
ready
for
the
working
group
to
decide
whether
to
work
on
it.
A
If
we
can
get
a
good
estimate
of
when
those
dates
are
in,
we
can
get
the
milestones
in
place
and
that
that
has
benefits,
as
I've
said
before
so
I
will,
the
chairs
will
be
taking
an
action
to
send
an
email
on
the
list
to
all
the
authors
of
all
the
current
specifications
that
are
personal
drafts.
Saying.
Can
you
guestimate
a
date
please,
and
then
we
can
get
that
working
if
someone
wants
to
take
anything
to
the
mic
and
and
stay
to
date
here
and
now.
That
would
be
great.
A
It
saves
a
round
trip
of
an
email,
but
we
do
need
those
dates.
That's
it
on
the
charter,
so
just
opening
the
line
to
questions,
etc.
I'm
quickly
jumping
back
to
meet
echo,
so
I
can
see
if
anyone's
got
any
comments
in
the
chat.
Does
anyone
have
any
comments,
so
I
just
thought
I
must
join
the
cube.
If
you
raised
a
question
in
the
chat
and
you
want
to
take
it
to
the
mic,
please
feel
free
go
ahead.
I've
decided,
I
think
you
were
first
or
was
it
a
headphone.
C
C
I
think
I
think
rick
and
ed
has
given
a
very
good
summary
what
happened
and
I
think
we're
all
now
all
our
like
how
things
are
working
now.
The
on
the
thing
that
I
just
want
to
mention-
and
I
mentioned
in
one
of
my
emails
saying
getting
advisors
from
other
areas-
is
not
out
of
it's
not
out
of
course
equation
so
to
say,
so.
We
can
still
work
on
it's
very
hard
to
get
somebody
to
commit
to
to
come,
but
we
can.
We
can
try
to
get
something.
C
I
think
I
personally
believe
like
having
an
advisor
from
other
other
areas
would
be
very
nice
but,
as
perhaps
we
all
know,
it's
very
hard
to
find
someone.
So
if
you
have
contacts-
and
you
know
somebody
that
who
can
help
us-
maybe
that
information
you
can
also
provide
here
or
in
the
mailing
list
or
to
the
charter
or
to
me
so
that
we
can
reach
out
to
them.
That's
all.
D
Thank
you
very
much
for
the
presentation
regarding
using
our
including
routing
routing
in
this
working
group.
I
actually
agree
that
it's
better
to
do
to
do
the
routing
and
routing
area,
but
in
the
same
time,
let's
say
for
this
working
group.
If
we
look
at
our
documents
after
it's
published
on
its
rfc,
if
the
routing
is
depending
on
our
documents
and
our
working
group,
you
know
it's
like
there
are
some
from
before
the
comments
are
dependent.
D
One
document
is
depending
on
other
document,
so
if
it's
an
independent
document
yeah,
it
goes
for
the
routing
working
groups
as
magnets
and
some.
But
let's
say
if
we
have
our
dtn
document,
which
is
rfc
and
it's
very
important
that
some
routing
protocol
is
depending
on
it.
Maybe
I
think
the
ide
may
give
us
option
that
we
do
it
in
our
working
group
or
we
can
join
with
another
working
group
here.
So
that
is
like.
There
is
some
kind
of
reason
why
we
use
it.
D
We
we
need
this
routing
in
this
area
and
this
working
group.
A
Okay,
completely
understood
really,
that
is
a
discussion
that
will
happen
after
the
current
after
the
next
charter
cycle.
So,
yes,
very
valid
point
I
can
think
of
some
counter
arguments,
but
that
should
be
left
for.
I
think
we've
got
two
years
before
we
have
to
have
that
argument.
Hopefully
by
then
we
will
have
thousands
of
working
group
participants
and
having
multiple
working
groups
becomes
a
logical
organizational
step.
If,
if
we,
you
know-
let's
talk
about
that
in
three
years,
but
thank
you
that
that
is
a
valid
point.
Go
ahead.
James.
E
Speaking
to
your
question
about
you
know:
when
do
we
hope
to
have
some
of
these
new
drafts
or
documents,
and
I'm
going
to
be
talking
to
you
all
later
about
the
asynchronous
management
architecture
or
whatever
we
want
to
call
it.
My
goal
would
be
to
try
and
get
something
forward
by
the
next
ietf
113..
E
A
A
G
This
is
my
first
time
in
this
working
group,
but
I
am
usually
working
in
routing
protocol.
This
is
why
I'm
doing
some
question
on
the
chat,
but
okay,
little
surprise
about
your
your
your
your
talk
about
that.
But
now
my
my
concern
is
because
some
working
groups
like
mannet
or
or
bubble,
for
instance,
they
are
very,
very
concentrating
in
a
special
situation.
F
G
Routing
problems
and
dtn
has
another
things.
This
is
just
that
and,
for
instance,
quality
of
service.
If
you
decouple
it
from
routing,
it
could
be
really
very,
very
tricky.
I
understand
that
there
are
a
lot
of
things
to
do
besides
routing-
and
this
is
why
you
you
are
trying
to
to
tackle
this
this
this
part.
Firstly,
but
what
just
to
to
express
this
point.
A
G
A
Let's
you
I
completely
agree,
it
would
be
great
to
get
onto
routing,
and
maybe
we
should
use
that
as
a
as
a
an
inspiration
to
tackle
all
the
topics.
We
need
to
do
first
as
quickly
as
possible,
so
we
can
get
on
to
the
exciting
thing
about
routing
and
let's
not
get
sidetracked
into
a
discussion
about
where
the
routing
routing
work
happens.
That's
that's
really
up
to
the
iesg.
I
think
we
have
people
who
are
interested
in
doing
it.
A
A
I
think
that's
the
end
of
that
and
we're
about
five
minutes
over
which
is
terrible
when
the
chairs
overrun.
So
next
up.
I
can't
see
the
agenda
anymore
because
I'm
showing
slides
who
have
we
got
first,
I
think
we
have
brian
cpos
with
administrative
record
types.
A
A
H
Okay,
so
this
is
going
to
be
a
short
presentation
and
what
this
is
about
is
that,
as
part
of
some
other
related
work
in
the
acme
working
group,
there's
a
need
to
define
a
new
administrative
record
type,
and
if
you
look
in
the
iana
registry
for
bundle,
administrative
record
types
they
exist,
but
only
for
bpv6,
and
there
were
a
bunch
of
tables
that,
as
part
of
bpbis,
they
were
expanded
upon
to
include
a
column
to
indicate
a
bundle,
protocol
version,
the
block
types
registry
and
flags
registry
and
some
others.
H
But
this
wasn't
done
with
the
administrative
record
types
registry
subregistry,
and
so
what
this
document
is
proposing
is
to
just
do
the
same
for
this
other
code.
Point
registry-
and
it
makes
a
couple
of
other
changes
that
I'll
talk
about
in
the
next
slide,
but
it
makes
an
explicit
reservation
and
it
also
makes
an
experimental
range
reservation
too,
and
the
the
experimental
range
isn't
necessarily
driven
by
anything
other
than
they're
the
large
values
that
correspond
also
with
the
experimental
reservation
that
was
made
in
bpv7.
H
For
the
other
registries.
There's
no
change
made
to
the
registration
procedure
here.
It's
purely
about
just
marking
this
as
bpp7,
and
the
reason
why
this
wasn't
treated
at
as
a
blocking
issue
for
bp
bis
bpv7
is
that
the
document
as
it
stands
is
self-contained
and
consistent
and
there's
not
a
problem
with
it.
It
just
has
an
explicit
table
of
these.
H
Are
the
administrative
record
types
and
that's
it
so
an
agent
isn't
told
that
it
really
should
use
an
iana
registry
instead
of
an
explicit
table
so
on
this
slide
is
what
the
changes
are
from
this
small
document,
and
this
really
is
the
meat
of
the
document-
is
to
make
these
changes
to
the
inner
sub-registries.
H
H
H
H
And
currently,
I'm
requesting
for
the
working
group
to
adopt
a
document,
and
the
reason
for
this
is
that,
as
of
yesterday
in
the
acme
working
group,
discussion
of
the
the
node
id
validation,
they
are
interested
in
progressing
that
document
into
the
editor
queue
before
the
end
of
the
year.
H
A
Okay,
thanks
brian,
I
was
gonna.
My
first
question
was:
are
you
asking
for
working
group
adoption
but
you've
answered
that?
I
think
that
seems
perfectly
reasonable
to
me.
So
we'll
do
a
call
on
the
mailing
list
for
working
group
adoption.
I
thoroughly
recommend
people
have
a
quick
read
of
this.
This
sounds
like
one
of
those
kind
of
scaffolding
documents
that
needs
to
exist,
so
I'm
really
hoping
it's
short
and
understandable.
A
A
H
A
A
And
which
one
was
in,
which
one
did
we
have?
Next?
I've
lost
the
agenda
again.
I
should
just
too
many
windows
open.
H
So
the
point
of
this
presentation
is
just
a
little
informational
and
a
little
public
service
announcement
about
some
work
that
was
started
under
the
tcpcl
updates
as
proof
of
concept
and
as
as
diagnostic
tool,
but
since
then
has
recently
transitioned
to
the
upstream
project.
H
So
this
started
out
as
tcpcl
expanded
to
bpv7,
more
generally
and
later
on
in
2019
to
bp
sec,
and
there
is
still
a
repository
for
doing
some
of
these
more
prototyping
things
like
the
acme
node
id
validation
and
the
cozy
context,
but
the
the
main
dissectors
for
updates
to
tcpcl
for
bpv7
and
bpsec
made
it
into
the
wireshark
main
branch.
H
Last
month
or
a
couple
months
ago,
they've
been
sitting
in
a
queue
for
a
while
new
protocols
get
a
little
more
rigor
in
their
review,
but
they
finally
got
approved,
and
so
this
is
good
news.
The
the
way
that
this
was
done
is
there
still
is
a
generic,
bundled
dissector,
which
in
the
past
was
for
versions
four
to
six
and
there's
some
the
version
introspection
that
was
added
so
that
that
dissector
can
can
detect
v7
with
the
seabor
encoding
and
do
its
own
separate
dissection.
H
So
the
bundle
dissectors
are
separate,
but
there
there's
introspection
to
be
able
to
do
the
same
kind
of
thing
that
was
happening
already
for
ipv4
versus
v6
and
and
other
version
introspection,
kind
of
work
and
one
of
the
good
things
about
the
architecture
of
how
this
is
done
is
that
wireshark
has
these
things
called
dissector
tables
that
let
you
delegate
across
protocols.
H
H
The
point
of
this
is
to
to
make
experimentation
easier
and
the
dissectors
for
for
tcpl,
and
the
bundle
include
defragmentation
logic.
That's
built
into
wireshark.
They
include
sequence,
analysis,
timing
and
things
like
that.
Hopefully,
to
make
it
easier
to
troubleshoot
these
things.
H
The
one
change
that
was
lost
from
the
original
tcpcl
was
the
ability
to
opportunistically
dissect
messages.
If
you
don't
have
a
contact
header,
because
that
is
the
contact
header
is
where
the
version
is
indicated
and
without
the
contact
header,
the
rest
of
the
tcp
stream.
You
can
get
segments
of,
but
there's
no
explicit
version
indication,
and
so
that
is
I'm
going
to
skip
to
the
next
slide.
H
That
is
something
that
that
could
be
potentially
added
in
in
the
future.
If
there's
enough
interest
in
doing
it
would
have
to
come
up
with
some
logic.
For
for
how
do
you
do
what's
the
word
heuristic
dissection
of?
Does
this
look
like
a
bp,
a
tcp
clv4
header?
Does
it
look
like
a
v3
header
and
so
on?
H
But
I
have
a
couple
examples
in
screenshots
here
and
these
examples
come
straight
out
of
unit
test
files
that
are
that
are
included
in
the
upstream
source
now
and
they're,
really
just
basic
proof
of
work
that
the
thing
is
doing
the
right
job,
but
you
can
see
here
in
the
tcpcl
dissection
that
you
can
see
the
the
different
messages
being
dissected
in
the
different
tcp
segments.
H
You
see
in
the
bottom
that
there's
some
sequence
analysis
of
telling
you
the
this
acknowledgement
message
is
acknowledging
the
segment
that's
in
frame
number
12,
and
it
took
four
milliseconds
to
to
receive
this
acknowledgement,
and
so
you
can
get
some
information
about
the
performance
of
of
the
underlying
network
here
and
hopefully
help
with
troubleshooting.
If
things
are
working
as
you
would
not
expect
on
a
real
network.
H
And
then,
on
the
next
slide,
the
bpv7
focus
of
the
bundle
framing
all
the
different
blocks
and
block
types,
there's
some
very
basic
sequence:
analysis
such
as
it.
It
extracts
the
bundle
identity
which
is
the
source,
eid
and
the
time
and
sequence
number
and
then
there's
some
simple
logic
about
retransmits,
and
this
is
all
in
the
form
of
how
wireshark
already
deals
with
all
of
this
stuff.
H
To
begin
with,
so
you
know,
re-transmits
are
not
something
new
for
bundle
protocol,
so
there's
a
bunch
of
ecosystem
of
ui
that
already
exists
for
dealing
with
these
things
and
we're
trying
to
squeeze
this
into
to
that
form.
H
But
you
can
see
that
each
of
those
canonical
blocks
of
the
different
types
use
different
sub
dissectors
in
in
those
dissector
tables,
so
adding
new
experimental
block
types
to
a
local
plugin
outside
of
the
wireshark
short.
So
you
don't
need
to
rebuild
all
of
wireshark
to
exercise.
The
plugin
is
pretty
straightforward.
H
And
then,
as
far
as
how
this
is
going
to
continue
on
in
the
future,
the
base
dissector
without
some
bug,
fixes
and
enhancements
that
were
made
afterwards
is
already
in
the
3
6
release
branch,
so
that
should
be
present
by
the
3
6
release
the
tcp
cl
dissector,
some
enhancements
to
the
bpv7
are
likely
to
be
in
the
3a
release,
but
that
branch
hasn't
been
created
yet.
But
this
is
just
a
rough
idea
of
when
to
look
for
these
things
and
one
a
couple
of
notes.
H
The
version
introspection
logic
right
now
is
a
little
bit
ad
hoc.
It's
not
really
based
on
on
any
documented
standard,
just
to
mention
that
there's
some
similar
logic
that
was
written
up
in
a
personal
draft.
If
there's
any
value
in
having
a
standard
way
of
doing
this
introspection
of
which
version
do
you
try?
First
try
to
look
for
first,
which,
which
one
takes
precedence?
What
is
a
failure
mode?
This
could
be
extracted
if
there's
any
desire
to
do
so.
H
Like
I
was
saying
earlier,
the
the
op,
the
tcpcl
opportunistic
message
dissection
could
be
added.
It's
a
similar
sort
of
thing
of
just
adding
some
logic
of
looking
at
a
looking
at
what
might
be
a
message.
Header
and
saying:
does
this
look
close
enough
to
a
v3
header?
Does
it
look
close
enough
to
a
v4
header,
and
the
last
point
I
want
to
make
is
that
now
that
the
main
dissectors
are
in
the
upstream
project
that
it's
up
to
the
wireshark
project
and
the
community
around
it
to
manage
these
things?
H
So
wireshark
has
a
public
issue
tracker
to
identify
defects
and
enhancements.
The
normal
merge
process
is
all
there
and,
as
of
a
recent
review,
I
actually
did
find
an
issue
with
the
bp
sec
dissector
in
in
some
circumstances,
and
wrote
up
an
issue
about
that.
A
Thanks
brian,
that's
that's
great,
I'm
in
the
queue.
So
a
little
personal
comment
actually
no
chair
comment.
If
you
wanted
to
write
up
an
opportunistic
message,
dissection
draft,
I
think
it
would
make
a
great
informational
document.
I
mean,
I
suppose
it's
not
standardizing
anything
outside
the
scope
of
the
udpcl
stuff,
but
a
little
informational
document
which
says
if
you
get
get
some
random
fragments
of
of
the
tcpcl
conversation.
In
order
to
determine
the
version,
then
you
might
want
to
follow
the
following
logical
steps.
A
I
mean,
if
you
want
to
write
it
down.
That's
the
kind
of
thing
that
that
is
in
the
next
charter,
as
a
kind
of
operational
experience,
thing
and
informational
would
be
the
right
way
to
go
if
you
want
to
do
the
work.
Otherwise,
this
is
great.
It's
I
kind
of
from
a
personal
opinion
having
your
protocol
in
wireshark
mainline
kind
of
means,
you're
now
a
grown-up,
proper
protocol,
because
why
not
so,
which
is
credit
to
the
workshop
for
their
for
their
penetration
of
their
their
tool,
but
yeah.
I
C
K
C
Big
long
process
of
having
informational
document,
but
if
we
have
a
lot
of
things
like
this,
that
we're
going
to
bundle
together
into
some
sort
of
document
information
document
that
that
could
be
a
good
thing.
So
this
is
an
proposal
like
these
are
options
we
have.
We
don't
need
to
decide
now,
but.
A
Yeah,
I
I
would
disagree
with
you
because
yeah
I
take
your
point
that
if
this
is
how
to
do
it
in
wireshark,
that's
not
appropriate,
but
I
can
see
an
informational
document
that
describes
a
reliable
way
to
detect
the
version
of
fragments
of
a
tcpcl
conversation
being
useful
for
people
implementing
firewall
filters.
A
This
kind
of
the
standard
traffic
policing
stuff,
as
well
as
tooling,
having
a
the
dtn
working
group
states
informationally
that
this
is
a
preferred
way
of
detecting
a
tcpcl
version
from
fragments.
I
see
that
as
a
generic
document,
but
let's
take
that
offline,
but.
C
Yeah
but
but
then
then
I
agree
with
you,
then
I
agree
with
it.
I
was
I
was
thinking
like
your
comment
was
more
towards
this
kind
of
tooling
and
thing,
but
if
we
have
this
kind
of
information
use
for
a
lot
of
other
things
and
kind
of
like
best
practices
that
we
are
describing.
So
that's
a
very
welcome
document.
I
would
say
mm-hmm.
A
H
Will
this
next
presentation
also
is
pretty
short,
and
it's
really
a
re-statement
of
some
earlier
work
that
was
presented
at
an
earlier
itf
related
to
cozy
security?
The
the
background
is
really
the
same
here.
I'll
restate
this
just
for
anybody
unfamiliar
that
the
bpsec
default
security
context
that
as
it
as
rick
and
ed
had
mentioned,
is
going
through.
The
editor's
cue
now
is
absolutely
usable
and
it
does
what
it
is
supposed
to
be
doing,
but
it
is
intentionally
limited
in
scope.
H
There
really
is
a
need
for
for
pki
integrated
security,
and
this
was
something
that
the
the
security
area
review
of
the
bb
sec
came
up
with
and
from
their
perspective.
Pkis
is
really
important
for
internet
facing
scalability
and
the
main
thing
is
we
don't
want
to
have
to
reinvent
the
wheel.
H
Bpsec
provides
a
great
framework
in
which
security
information
can
be
included
in
a
bundle
and
the
cozy
the
cbor
object.
Signing
encryption
already
has
a
syntax
and
it
really
fits
well
into
the
I'll,
say,
asynchronous
self-contained
type
of
environment
that
bundles
exist
in,
and
it
already
provides
a
wealth
of
extension
points
for
for
future
security
algorithms.
H
So
the
idea
here
is
that
this
is
not
proposing
to
alter
anything
that's
already
in
bpsec.
H
It
is
intended
on
handling
symmetric,
key
and
pki
algorithms
in
a
way
that
is
already
standard.
H
All
these
things
are
already
standardized
and
already
exist
out
of
the
cozy
working
group,
and
an
important
thing
here
is
that,
because
this
is
embedding
a
cozy
message
proper
by
using
this,
you
get
all
of
the
benefits
of
whatever
comes
out
of
the
future
of
the
cozy
working
group,
and
that
includes
more
optimized
algorithms
related
to
signatures,
potentially
they're
working
on
post
quantum
and
other
types
of
future
algorithms,
and
the
idea
is
to
to
take
that
benefit.
When
it
comes
down
the
line.
H
And
the
other
thing
is
that
this
is
not
just
about
the
on
the
wiring
coding,
but
this
is
also
about
library
and
tool.
Support
for
cozy.
There
already
are
a
number
of
libraries
and
a
number
of
languages
that
handle
cozy
and
it's
made
to
be
small.
It's
made
to
be
used
in
iot
tech
devices,
so
it's
not
done
in
a
way.
H
That's
burdensome
to
the
system,
a
little
bit
about
the
proposed
context
that
there's
one
code
point
currently
that
would
be
allocated
and
the
same
code
point
has
the
exact
same
semantics
between
bib
and
bcb,
in
that
the
security
result
is
a
cozy
message
and
then
there
are
logics
about
in
a
bib.
H
The
type
of
cozy
message
that
should
be
present
is
either
a
a
mac
or
a
signature
and
a
bcb.
It
should
be
an
encryption
message
and
then
there
are
some
parameter
types
defined
that
use
aad
scope
exactly
the
same
as
the
default
security
context,
and
this
could
be
even
simplified
to
say
just
do
what
the
default
security
context
does.
H
Cozy
allows
you
to
include
a
lot
of
details
in
each
message,
but
presumably,
if
I'm
a
security
source,
I'm
going
to
be
adding
in
multiple
signatures,
I
want
to
assign
several
different
blocks
at
the
same
time,
and
so
this
provides
a
mechanism
to
to
extract
out
duplicated
cozy,
headers
and
just
put
them
all
in
one
place,
and
then
the
the
bpsec
results
is
really
where
the
cozy
messages
end
up
going
into
and
and
one
of
the
things
that
you
can
get
out
of
the
box
off.
H
The
shelf
in
a
sense,
is
all
of
these
mechanisms
for
handling
public
keys
for
handling
x,
509
certificates.
H
A
lot
of
more
complex
activities
can
be
already
accommodated
in
this
kind
of
messaging,
and
so
the
the
the
message
tags
that
already
existing
that
are
already
in
use
by
libraries,
is
proposed
to
be
used
as
result
type
codes.
So
it's
not
inventing
new
registries
for
these
things,
and
the
idea
is
that
this
document
defines
a
I'll
show
it
on
the
next
slide.
H
I
believe,
but
a
minimal
set
of
interoperability
requirements
because
cosy
as
itself
is
a
is
a
framework
for
embedding
security
information,
and
the
idea
here
is
to
say,
I'm
going
to
skip
to
it
right
now
that
these
are
the
the
minimum
of
of
how
you
do
cozy
when
it's
embedded
in
bpsec.
H
So
there's
there's
a
set
of
symmetric
algorithms
and
then
the
the
main
benefit
of
this
context
beyond
the
existing
default
security
context
is
to
be
able
to
do
things
like
the
identified
key
wrap
to
be
able
to
use
off
the
shelf
elliptic
curve,
edwards
curve
rsa
signing
today.
There's
ongoing
work
in
the
cozy
working
group
to
add
other
variations
other
optimizations,
but
this
is
supposed
to
be
the
the
minimum
of.
If
you
want
to
do
p
kicks.
H
And
then
last
slide
is
just
to
say
that
this
exists
as
a
personal
draft.
Now
it
should
be
pretty
self-consistent,
but
this
is
just
offering
it
up
as
a
potential
adoption
to
be
able
to
get
the
benefit
of
pki
and
p
kicks
in
bp
sec
in
a
very
short
amount
of
time,
and
the
proposal
also
is
that
this
would
be
using
the
exact
same
certificate
profile,
the
exact
same
mechanisms
all
of
the
stuff-
that's
already
defined
for
tcpcl,
for
using
this
within
tls.
H
And
there
are
still
some
open
questions
about
technical
details,
but
those
if
it's
adopted
can
be
worked
out.
B
Hey
brian,
thank
you
very
much
and
then
just
me
and
the
queue
with
my
chair
hat
off.
I
just
wanted
to
say
I
I
love
this
work
when
we
were
building
bp
sec
and
the
concept
of
security
context
in
the
working
group,
it
was
clear
that
defining
frameworks
like
this
are:
are
you
know,
sort
of
part
and
parcel
of
how
contacts
are
likely
going
to
work
and
having
something
like
this
is
far
better
than
a
bpv7
user
saying?
B
Instead,
I
will
just
produce
cozy
encoded
work
as
payload
and
then
not
have
a
good
answer
for
that
for
individual
extension
blocks
as
well.
So
I
I
think
that
your
approach
here
is
correct.
I
think
that
it's
something
that's
needed
and
hopefully
that's
something
that
we
can
get
in
and
get
the
technical
review
on
and
work
any
additional
technical
things,
but
good
work.
Thank
you.
A
Yeah
same
rick
here
with
my
chair
hat
on
yeah
brian,
this
is
this
is
good
stuff
and
I'm
agreeing
with
everything
ed
just
said.
So
are
you
asking
for
working
group
adoption
because,
as
I
read
the
new
charter,
hopefully
official
new
charter,
this
is
in
scope.
This
is
enhancements
to
bp
sec.
So
my
question
is:
do
you
want
to
adopt?
But
do
you
want
to
ask
for
adoption
in
this
group
or
do
you
want
to
ask
for
adoption
in
cosi?
I
think
this
group,
but
I'm
interested
in
your
answer.
H
It
is
ready,
I
believe,
for
for
adoption.
It
would
be
a
dtn
document,
because
it's
it's
really.
It's
registering
things
in
the
dtn
ayana
section
and
for
the
dtn
purposes,
and
there
would
be
what
there
hasn't
been
yet
and
would
would
be.
Is
I
would
invite
members
from
cozy
working
group
to
look
at
this
and
say:
does
this
look
the
way
it
ought.
A
To
look
so
this
chimes
with
the
various
iesg
review
about
our
charter
about
liaising
with
other
working
groups,
and
this
is
a
classic
example
of
where
we
need
to
go
to
cosy
and
say
double
check
this,
and
so,
if
we
working
group
adopt
this
prior
to
last
call,
we
will
get
a
review
from
experts
in
cosi
to
make
sure
we're
doing
it
right
as
they
understand
it.
So
yeah
that
makes
sense.
So
we'll
do
a
working
group.
A
Adoption
call
on
the
list
and
as
part
of
that
adoption
call,
I
will
obviously
be
asking
you
for
a
date
for
when
you
think
it
it'll
how
long
it'll
take
to
turn
around.
But
but
there
we
go
so
thanks
brian,
I
think
that's
all
your
slot,
and
next
up
we
have
scott
who
is
discussing
what
was
originally
called
big
dtn,
but
is
now
called
the
scalability
issues
in
big
detains
hello.
Scott,
do
you
want
to
present
your
own
slides
or.
L
Okay,
all
right,
then,
let's
go
ahead
to
the
next
slide.
L
L
L
What
I'll
hypothesize
here
is
that
that
the
commercial
products
that
we're
looking
for
will
be
unlikely
to
emerge
until
there's,
potentially
a
large
market
for
dtm
products
and
and
that
in
turn,
I
think,
makes
it
necessary
to
to
demonstrate
that
it's
possible
for
a
dtn
based
network
to
grow
to
an
arbitrary
size
which
has
not
been
done
in
the
past.
L
We,
we
we
do
lots
of
demonstrations
using
small
networks
that
instantiate
particular
routing
or
or
forwarding
or
or
reliability
issues,
but
we
haven't
really
demonstrated
operation
of
very
large
network
that
would
make
commercial
product
development
attractive.
L
So
what
is
it
about?
Do
you
think
that
that
makes
it
difficult
to
make
it
large
and
there
isn't
really
anything
intrinsic
in
bundle,
protocol
or
bpsec
that
limits
the
size
of
a
dtm
based
network?
L
There
is
a
second
order
problem,
I
think,
which
is
that,
as
we've
experienced
in
deployment
experiments
and
and
demonstrations
over
the
past
few
years,
it's
you
can
you
can
readily
configure
dtn
implementations
to
support
a
very
wide
range
of
communication
scenarios,
but
that
configurability
there's
a
lot
of
knobs,
and
so
the
deployment
and
management
of
d10
nodes
is
somewhat
labor-intensive
and
that
that
sort
of
inhibits
the
anyone's
ability
to
operate
a
very
large
network
next
slide.
L
So
the
solution
that
is
proposed
in
this
presentation
is
that
we
can
solve
this
by
automating
some
of
the
routine
tasks
of
managing
the
network
in
in
in
two
ways
in
particular.
First,
the
the
forwarding
decisions,
the
management
of
forwarding
decisions.
How
do
you
do
that
across
a
network
comprising
thousands
or
millions
of
nodes,
as
opposed
to
forwarding
nodes
and
then
second
and-
and
I
think,
less
challenging-
is
how
do
you
automate
the
deployment
of
new
nodes
and
and
do
that
in
a
scalable
way?
L
The
the
the
two
approaches
discussed
in
this
presentation
are
to
address
these
these
these
two
general
kinds
of
problems,
first
of
all,
a
concept
of
regions
that
I'll
explain
in
a
moment
that
decompose
a
large
network
into
chunks
of
limited
forwarding,
scope
and,
and
therefore
limited
management
challenge
and
there's
a
a
mechanism
for
this
tentatively
called
inter-regional
forwarding
that
is
presented
here.
L
Second
is
something
that
I've
been
sort
of
wishing
for
for
a
long
time
our
auto
configuration
mechanisms
that
makes
it
very
straightforward
to
create
a
new,
a
new
dtn
node
without
having
to
go
through
a
large
network
management
and
configuration
effort,
and
this
v10
node,
auto
configuration
system
is
intended
to
demonstrate
the
best
possible
next
slide.
L
So
interregional
forwarding
the
the
reasoning
behind
this
design
is,
first
of
all,
assuming
that
that
the
light,
tolerant
routing
mechanisms
really
merge
over
time
that
enable
the
automation
of
forwarding
among
limited
numbers
of
gtn
nodes
and
the
contact
graph.
Writing
that
supports
g10,
that's
currently
running
on
the
international
space
station
is
a,
I
think,
an
existence.
Proof
of
that
that
there
are,
it
is
possible
to
to
develop
these
things
and
and
and
operate,
deploy
and
operate
them.
L
So,
given
that
assumption,
what
we're
doing
here
is
defining
the
term
region
to
be
a
set
of
nodes
that
is
encompassed
by
a
single
routing
regime
powered
by
one
of
these
mechanisms
and
and,
for
example,
the
set
of
all
nodes
that
are
cited
in
any
of
the
contacts
of
a
contact
plan.
It
would
be
a
cgr
based
region
regions.
If
you
look
at
them
a
little
bit
sideways,
look
a
little
bit
like
autonomous
systems.
L
You
can
use
them
not
only
as
domains
within
which
forwarding
is
is
coherent,
but
also
domain,
so
in
which
administration
is
located
or
or
security
is
standardized
next
slide.
L
Okay,
so,
given
that
concept,
how
do
you
forward
from
a
node
that
is
a
member
of
one
region
to
a
node?
That's
a
member
of
another
region
without
propagating
enormous
volumes
of
information
across
the
network,
and
the
interregional
forwarding
strategy
discussed
here
is
to
use
the
the
first
bundle,
that's
destined
for
a
given
remote
node
from
from
a
source
node
as
a
sort
of
probe
that
you
don't
really
know
necessarily
what
other
region
your
destination
node
is
in.
L
So
we
send
out
a
a
probe
bundle
that
essentially
finds
it,
and
there
are
positive
and
negative
feedback
messages
from
candidate
forwarding
points
that
propagate
back
to
the
source,
so
that,
once
the
the
feedback
has
been
received
back
to
the
source,
node
subsequent
bundles,
that
are
sent
to
that
same
destination,
node
can
go
much
more
efficiently,
just
through
a
single
path.
L
The
this
is
all
based
on
on
implementation
and
the
dnac
and
irf
currently
implemented
and
and
discussed
here
are
only
implemented
for
nodes
that
are
identified
by
endpoint
ids
in
the
ipn
uri
scheme,
nodes
that
are
identified
by
number
rather
than
by
string
the
same
principles
I
think
are
applicable
for
other
eid
schemes.
L
I
haven't
tried
to
do
anything
with
that
at
this
point
and
dnac
the
node
auto
configuration
is
all
based
on
things
that
are
implemented
only
in
the
ion
implementation
of
dtn.
Again,
this
is
something
that
could,
I
think,
readily
be.
The
concepts
could
readily
be
adapted
to
other
implementations,
the
dnac
and
irf
in
this
demonstration,
and
what
I'm
going
to
be
talking
about
are
built
on.
Some
underlying
capabilities
have
been
prototyped
in
the
ion
implementation
of
dtn.
L
For
some
time
now,
one
is
automatic
contact
plan,
synchronization
that
aligns
contacts
across
all
the
nodes
in
what
turns
out
to
be
a
region
all
the
nodes
that
are
cited
in
that
contact
plan.
L
That
in
turn
is
based
on
bundled
multicast,
which
in
turn
is
based
on
contact
graph,
routing
and
there's
also
a
reliance
on
the
delay,
tolerant,
key
administration
prototype
that
has
been
out
for
several
years
now,
which
in
turn
is
based
on
structures
called
trusted.
Collectives
that
are
sort
of.
L
L
Oh
right,
this
is
an
illustration,
and
these
slides
are
an
example
of
how
you
use
these
things.
What
the
the
way
they
operate.
It's
not
a
hypothetical
illustration.
This
is
actually
the
test
case
for
the
development
of
this
stuff.
That
now
works
quite
well
next
slide.
L
So
here
we
we
start
off
by
creating
node
number
21
in
in
the
root
region
of
the
network,
which
is
region
one.
So
here's
here's,
the
the
instantiation
of
node
21
in
the
usual
intensively,
managed
way,
which
we've
been
doing
for
a
long
time
in
the
ion
development
world
next
slide.
L
Once
you've
got
node
21.
Well,
you
can
run
dna
at
node
21
to
create
node,
22
automatically
and
next
slide.
Node
23
and
next
slide
node
24..
So
these
are
all
now
nodes
that
have
been
created
quite
easily
from
from
just
starting
one
node
in
in
the
root
region.
One
next
slide.
L
The
next
step
here
is
to
create
another
region
which
is
region
11,
and
you
create
a
region
automatically
and
implicitly,
by
transforming
a
node
from
from
what's
what's
called
a
a
terminal
node
that
lives
only
in
one
region
to
a
passageway
node
that
resides
concurrently
in
two
regions,
which
means
that
there
are
contacts
citing
that
node
in
the
both
in
the
contact
plan
for
in
this
case
region,
one
and
in
the
contact
plan
for
region
11..
L
L
We
can
then
move
nodes
from
one
region
to
another,
so
region
11
now
exists.
We
can
move
node
23
into
region
11.
You
can
move
node
24
into
region
12.
in
this
case.
What
we
do
here
for
the
purposes
of
the
illustrations.
We
add
connectivity
directly
between
22
and
and
24,
because
originally,
when
the
nodes
23
24
22
were
created,
they
only
had
connectivity
back
to
node
21..
Here
we
were
adding
connectivity
from
22
to
24
and
that
enables
us
next
slide
to
send
a
file
using
bundle.
L
Protocol
from
23
to
24.
now
23
doesn't
know
where
24
is
doesn't
know
how
to
reach
it.
But
it
does
know
that
24
is
not
in
region
11,
where
23
resides
because
23
through
contact
plan.
L
So
the
bundle
goes
to
21..
21
then
says
I
don't
know
where
24
is
either.
I
likewise
can
only
send
it
to
24
by
sending
to
all
the
passageways
out
of
reason,
one
I'm
not
going
to
set
it
to
myself.
So
the
remaining
passageway
out
of
region
1
is
22.
L
And
and
22
then
has
only
the
option
of
because
it
it
also
knows
that
that
24
is
not
in
week,
one.
It
knows
about
the
contact
plan
for
region
12
and
says
it.
It
then
can
go
ahead
and
forward
the
bundle
from
22
to
24
within
region
12,
using
the
intra
regional
forwarding
mechanism,
which
in
this
case
is
contact
graph,
routing
and
and,
as
that
happens,
node
22
sends
back
an
encouraging
feedback
message
back
to
the
node
from
the
passageway
from
which
it
received
the
the
bundle
originally
saying.
L
Node24
is
reachable
through
me
and
21
then
will
next
slide
send
the
that
that
forward,
that
that
encouraging
feedback
back
to
23.
so
the
next
time
23
wants
to
send
something
to
24.
L
It
knows
no
matter
how
many
passageways
there
are
out
of
region
11,
I'm
always
going
to
send
it
to
passageway
21,
because
that's
how
I
get
it
to
24.
next
slide.
L
So,
okay,
now
we
given
this
little
framework,
we
use
automatic
node
configuration,
create
a
brand
new
node
25,
who
that
is
native
to
region
11..
It
doesn't
get
moved
into
it,
it's
being
created
in
region
11
by
another
node
that
is
already
in
region
11,
which
is
21
next
slide.
L
We
move
25
to
to
be
a
passageway
into
on
yet
another
new
region
111,
and
we
we
create
region
111
by
transforming
25
into
a
passageway
between
11
and
11.
next
slide,
and
now
because
25
resides
in
111
as
well
as
in
11
it.
It
can
create
a
new
node
who
that
is
native
to
region,
111,
node,
27.
L
L
L
So
now
we
make
node
24
a
passageway
between
1
and
11.
We
move
it
back
so
that
it's
it's
back
in
one
in
reason,
one,
but
it's
also
still
in
region,
one
one
reason
eleven
and
we
restore
connectivity
between
21
and
24,
which
had
been
broken
when
we
moved
it
into
12.,
there's
still
no
connectivity
between
26
and
22,
which
means
that
when
26
wants
to
send
a
bundle
back
to
27
next
slide
it
it
has
to
send
that
bundle
to
there
are.
L
So
the
even
though
there
are
two
passageways
going
out,
only
one
of
those
will
end
up
being
the
selected
passageway,
because
it's
more
direct
and
that's
sending
it
to
24,
which
sends
it
directly
to
21,
rather
than
sending
it
to
24
in
order
to
get
it
to
22,
to
send
it
to
21.
next
slide.
So
this
th,
this
sequence
then
just
shows
that
happening.
24
sends
it
directly
to
21,
it
gets
to
25
and
and
then
27.
L
next
slide.
Okay,
so
now
we
remove
22,
which
was
a
passageway
between
1
and
12..
Now,
20
22
is
no
longer
a
passageway.
We
move
removed
from
from
region
12.
and
for
this
next
part
of
the
illustration
we
add
connectivity
between
23
and
25
directly.
So
now
there
are
two
ways
out
of
region:
11,
passageways,
21
and
25..
L
Once
again,
when
we
want
to
send
a
file
from
23
to
22,
23
sees
there
are
two
possible
ways
out.
He
doesn't
know
where
22
is
it
sends
it
to
21
and
also
did
25
next
slide
and
now
25
sends
back
discouraging
feedback,
saying
thanks
for
for
trying
me,
but
no
20,
node
22
is
not
reachable
through
me.
It
is
not
in
any
of
the
regions
that
I'm
in
it's
not
in
11.
It's
not
in
111..
L
21
does
not
say
that,
because
it
knows
the
22
is
in
region
1,
it
forwards
the
bundle
to
22,
and
it
also
would
send
encouraging
feedback
to
23..
So
the
next
time
23
sends
to
22.
It
won't
bother
to
send
it
to
25;
it
will
only
send
it
to
passageway
21.
next
slide.
L
L
L
Yeah,
that's
the
end
of
that.
Okay.
So
here's
a
hypothetical
use
case,
dnac
can
instantiate
a
new
node
in
about
a
second,
but
part
of
what
goes
on
with
with
dnac
is
optionally.
L
When,
when
d-dac
operates
it
it
creates
the
new
node
on
the
same
machine
as
the
parent
node,
and
then
it
optionally
migrates
it
to
another
machine
that
the
transplanting
the
new
node
to
a
new
destination
machine
can
take
a
little
time
because
we
use
ssh
and
scp
for
example,
and
so
taking
15
seconds
per
node
is
a
a
reasonable
guess
at
the
the
required
time
and
assuming
that
we
can
have
up
to
33
nodes
in
each
region.
All
right.
L
Let's
assume
that
we've
got
a
list
of
29
000
machines
who
want
to
include
in
our
network
that
would
occupy
879
regions.
The
first
region
is
populated
after
eight
minutes,
15
seconds
per
node,
32
more
nodes,
and
each
of
the
nodes
in
that
region
can
be
the
passageway
to
one
of
that
region's
subregions
next
slide,
which
is
the
last
slide.
L
Each
of
those
32
sub-regions
can
then
be
fully
populated
by
another
32
regions
in
each
one.
After
another,
eight
minutes,
and
so
each
of
those
1024
new
nodes
can
be
a
passageway
to
another
sub
region,
and
so
another
846
sub
regions
can
be
fully
populated
after
another
eight
minutes.
So
in
24
minutes
you
can
automatically
deploy
a
fully
interconnected,
dpsex
secured
daily,
tolerant
network
of
29
000
nodes,
and
in
this
particular
scenario,
every
node
in
the
network
would
be
no
more
than
five
forwarding
hops
from
any
other
node.
L
That's
the
end
of
the
slides,
and
I
see
two
people
in
the
queue
so
hi
rick.
I
guess.
K
A
Thanks
scott
yeah,
first
off
I'm
gonna
say
thank
you
very
much
for
that.
That's
really
interesting.
It
was
really
interesting
to
see
a
presentation
at
this
sort
of
scale
to
talk
about
all
these
outstanding
issues
that
we've
got
now
with
my
chair
hat
on.
I
need
to
remind
people
that,
of
course,
scott
has
touched
on
some
routing
here.
I
actually
have
quite
a
long
list
of
comments
which
hopefully
will
cover
some
of
the
other
things,
because
I'm
aware
a
little
bit
short
on
time.
A
This
is
a
classic
example
of
where
work
in
this
area
has
happened
in
other
parts
of
the
ietf
and
there's
a
wealth
of
experience.
We
can
bring
to
bear
from
those
other
groups
and
also
another
reason
why
we
need
to
tackle
some
of
the
earlier
building
blocks
before
we
get
onto
some
of
the
later
things.
So,
with
my
personal
opinion
on
I'm
just
going
to
go
through
a
couple
of
quick
things,
I
love
your
concept
of
regions.
I
know
you
and
I
have
talked
about
regions
offline
number
of
times
before
my
question
really.
A
L
Would
say,
actually
the
I
think
the
mandatory
part
is
that
that
routing
routing
forwarding
there
has
to
be
a
a
consistent
universal
forwarding
strategy
within
the
region.
L
Other
elements
of
of
commonality
may
be
folded
in
there
as
well,
but
the
the
required
thing
is
that
the
intra
regional
forwarding
has
to
be
consistent.
A
Yeah,
so
so
I
think
what
you
have
described
is
the
difference
between
an
interior
gateway
protocol
and
an
exterior
gateway
protocol
in
in
our
etf
terms.
So
so
it's
great
it
it's
brilliant.
When,
when
it's
convergent
evolution,
I
would
like
to
I'd
like
to
say
it's
yet
another
example
of
why
that
model
actually
works.
A
So
I'm
really
pleased
to
see
that
I'm
I'm
interested
to
see
how
this
works,
when
you
have
differently
named
regions,
so
you're
moving
between
endpoint
id
encodings,
so
rather
than
everything's
using
ipn,
you
can
say
well
everything's
using
some
sub
schema
of
dtm
and
something's,
using
an
icm
style
naming
and
something
else
is
using
in
ipm.
That
would
be
really
interesting.
The
auto
placement
really
worries
me
because
I
think
you're
conflating
the
deployment
of
a
node,
the
configuration
of
the
node
and
its
position
within
some
sort
of
hierarchical
routing
regional
thing.
A
A
A
A
The
third
thing
is:
is
the
opportunistic
forwarding
slash
routing,
because
a
bit
of
this
is
rooting?
I
I
really
putting
aside
the
naming
issue
which
which
I'm
really
keen
on
and
we'll
come
back
to.
When
I
have
some
spare
cycles,
the
reinforcing
feedback
you
describe.
There's
a
protocol
called
aodv,
which
has
come
out
of
the
manet
working
group,
which
does
exactly
this,
and
so
it
opportunistically
explores
routes
to
nodes
that
a
node
doesn't
know
about
handles.
The
loop
avoidance
understands
aging
of
the
information
and
all
of
that
kind
of
stuff.
A
L
I
I
specifically
wanted
not
to
not
to
be
in
conflict
with
the
existing
use
of
the
existing
terms.
So
I'm
happy
to
like
revise
that,
but
I
I
wanted
to
draw
in
which.
L
A
This
stage
I'm
really
interested
in
the
difference
between
a
passageway
and
a
gateway
then,
but
but
we
should
probably
take
that
offline,
because
I'm
talking
a
lot
and
other
people,
probably.
A
Okay,
fine,
my
final
statement
is:
you
need
to
look
at
protocol
independent
multicast
as
well,
because
that
is
multicast
tree
building.
There
seems
to
be
some
real
similarities
here.
That's
not,
and
none
of
those
comments
are
to
say
what
you
are
doing
is
is
is
nothing
but
good.
A
I
just
see
parallels
everywhere
with
more
mature
and
existing
technologies
that
we
can
that
that
you
can
steal
good
ideas
from
learn
from
and
perhaps
do
a
bit
of
gap,
analysis
to
work
out
what's
applicable
and
what's
not,
but
that's
enough
from
me
so
I'll
I'll
shut
up,
I
think
is
this
is
a
massive
christmas
mailing
list
conversation
I
see
coming,
which
I
look.
B
To
say
all
of
this
fits
well
within
the
the
the
charter
discussion
at
the
beginning,
which
is
we're
doing
a
lot
of
work
that
is
rooted
in
the
unique
nature
of
our
transport.
But
we
should
also
look
at
the
work,
that's
going
on
elsewhere
and
fill
the
gaps,
which
I
think
is
what
both
of
you
are
saying.
So
we'll
take
it
to
the
list.
A
Good
idea,
so
next
up,
I'm
flipping
rapidly
between
agendas
and
so
on.
Who
is
next
why
I
can
see
the
agenda
next
up?
We've
got
emery
talking
about
the
ama
and
the
next
steps,
so
I
shall
approve
emery's
screen
access
and
stop
sharing
my
own
did
that
work.
E
Excellent
go
ahead.
Emery,
hello,
I
don't
know
if
you
can
hear
me
and
see
me
and
see
a
screen
so
up
I'll
move
forward,
all
right
excellent.
So
I
was
going
to
talk
about
asynchronous
management
architecture.
You
know,
there's
there's
already
a
draft
out
there
we're
trying
to
rework
this.
I
admit
now.
Maybe
this
is
not
the
right
name,
but
that
is
just,
and
we
can
talk
about
even
through
through
this
conversation.
Ideally
here
is
to
talk
about
you
know.
E
Some
of
the
the
comments
back
is
what
makes
ama
or
dtn
network
management
unique
and
what
are
some
of
our
next
steps
as
we
go
forward.
So
one
of
the
first
things
kind
of
in
our
research
to
find
out
and
help
us
understand
why
this
may
be
unique
is
to
better
define
you
know
what
are
the?
E
What
are
the
use
cases
we're
trying
to
solve
this,
for,
in
particular,
one
of
the
things
we
found
recently
straight
from
rc
7228,
the
definition
of
a
challenged
network-
and
this
is
something
you
all
have
been
talking
about
from
my
understanding
for
some
time.
E
A
challenged
network
in
that
dtn
case
is
truly
those
that
have
the
the
incredibly
long
latencies
and,
in
fact,
latencies,
where
you
cannot
even
form
an
end-to-end
path
when,
when
a
message
will
be
sent
and
expected
to
be
received
at
a
later
point
in
time
when
the
transmitter
is
now
no
longer
sending.
So
I
think
that
is
a
very
unique
case
for
challenged
networks
with
that
said,
I
think
dtn
also
has
the
use
case
of
also
working
with
constrained
networks,
which
is
talked
about
quite
a
bit
in
rc
7228.
E
E
Going
to
sort
of
what
you
know,
a
lot
of
y'all
have
been
doing
in
this
working
group
they're
to
to
to
address
those
challenged
networks.
Y'all
been
developing
protocols.
You
know,
there's
rc's,
I
think
three
of
them
on
this
list
here
noted
earlier
are,
are
about
to
go
through
and
hopefully,
by
the
end
of
the
year,
actually
have
an
rfc
tag
on
them.
E
Let's
find
new
ways
to
address
dtm
management
such
as
bundling
such
as
bundle
and
bundle
or
sort
of
convergence
layers,
new
concepts,
dare
I
say
routing,
but
for
pushing
those
contact
plans
to
to
these
devices
so
kind
of
accepting
that
there
have
been
new
approaches
to
dtn
in
general,
maybe
there's
a
need
for
detainee
network
management,
so
the
current
draft
document
for
ama
outlines
some
of
the
services
that
are
needed
for
management
of
those
challenged
networks
and
some
of
the
desirable
properties
you
can
see
those
here.
E
I
want
to
call
out
a
couple
because
obviously
there's
the
simple
things
like
configuration
reporting
administration,
but
when
you
really
get
into
some
of
the
some
of
the
more
advanced
features
like
autonomous
parameterized
procedure,
calls
desirable
properties,
intelligent
push
of
information,
the
ability
to
sort
of
tell
a
node
when
it
needs
to
send
information
and
how
to
trigger
on
that.
That
kind
of
speaks
to
the
rules-based
execution
of
events.
You
know
that
you
aren't
going
to
be
able
to
talk
to
those
nodes,
synchronous,
synchronously.
E
You
know
that
you
may
not
talk
to
them
for
days
over
a
time,
but
you
want
them
to
queue
up
messages,
reporting
messages.
When
does
it
cue
those
up?
How
does
it
cue
those
up
and
then,
where
does
it
send
those
two?
So
some
some
of
these
are
the
the
very
important
features
that
are
needed
in
a
dtn
network
management
that
we
don't
think
it
exists
in
some
of
the
existing
protocols
and
I'm
going
to
talk
through
a
few
of
those
next
and
see
and
trying
to
see
what
might
be
different
between
those.
E
So
these
are
some
of
the
existing
protocols.
Maybe
there's
others
out
there
happy
to
talk
about
those
a
note
you
know
like
for
snmp
yang
core
comp,
which
is
in
the
work
same
thing
for
kind
of
autonomic
networking
in
the
works.
E
These
are
each
great
they've
got
a
lot
of
great
features,
in
fact,
some
of
the
features
I
think
we
want
to
bring
into
a
dta
network
management
solution,
but
as
they're
written
today
as
they're
used
today,
at
least,
I
think
they
don't
necessarily
meet
the
needs
for
that
challenged
network,
so
talk
through
a
few
of
them.
Snmp
we've
probably
seen
it
used
it
for
for
many
years.
E
It's
simple
right,
that's
in
the
name,
so
I
think
one
of
the
pieces
here
is.
It
is
purely
a
data
element
model
the
ability
to
pass
very
single
configuration
items
or
to
report
on
single,
maybe
failure
events
it
does
not
have
any
of
that
need
for
for
autonomy,
does
not
have
sort
of
rules-based
execution,
is
strictly
just
a
data
model
for
querying
and
receiving
individual
elements.
One
of
the
things
that
I
did
want
to
point
out
for
snmp
here
is
the
fact
that
they
organized
it
from
the
start.
E
Okay,
there
are,
you
know,
sort
of
the
the
standardized
spec
trees
and
then
they
define
each
one
of
those
up
under
that
very
clear
sort
of
this
is
a
spec
for
ospf
or
rip
or
whatever
it
might
be,
and
then
you
have
your
enterprise
spec
switches
for
all
of
your
vendors,
your
sisters,
cisco's,
junipers
and
so
forth,
because
that's
nicely
organized
you
can
you
can
reference
each
of
the
the
items
in
this
tree
very
easily,
which
is
something
that
I
think
is
needed
for
challenge
network
management
and
that's
some
of
the
future
work
the
next
one
here
this
is
gaining
popularity.
E
A
lot
in
in
the
recent
is
yang
and
as
well
as
the
protocols,
netconf
and
rest
comp
yang
is
a
full
featured.
Data
model
has
a
lot
of
capabilities
for
defining
a
very,
very
complex
data
structure
for
how
you
would
either
access
information
from
a
server
or
node.
That
is
being
managed,
as
well
as
how
you
can
configure
those
one
of
the
interesting
pieces
is
yang,
is
purely
a
data
model,
so
any
of
the
autonomous
behavior
that
you
need
to
build
into
yang
is
accomplished
via
the
netcomp
or
rest
comp
protocols.
E
Comp
itself
is
very
synchronous,
so
you
need
to
establish
that
session
to
a
yang
server.
Tell
it
what
you
want
to
configure,
tell
it
what
you
want
to
receive,
and
that
session
remains
connected,
the
entire
time
that
you're
trying
to
send
and
receive
those
commands.
So
I
think
that
one
immediately
kind
of
falls
off
the
the
table
for
a
challenge
network.
E
Rest
comp
changes
that
a
little
bit
so
it's
restful
is
definitely
designed
to
sort
of
send
commands
to
update
that
data
model
on
the
remote
server
or
send
commands
and
say
I
want
to
retrieve
information,
but
it
still
at
least,
is
currently
written,
highly
dependent
on
a
secure
sort
of
protocol
tls.
E
It
is
definitely-
and
it's
limited
to
the
yang
model
as
well
right,
so
so
I
mentioned
yang
as
being
a
data
model.
If
you
wanted
any
sort
of
back
and
forth
or
collect
a
large
data
set,
you
would
have
to
request
that
large
data
set,
which
then
the
the
message
on
the
wire
or
or
error,
is
pretty
verbose.
So
that's
kind
of
speaking
to
netconf
and
rest
comp.
E
There
are
updates,
or-
or
you
know,
new
new
protocols,
either
existing
or
in
the
works
which
are
trying
to
remove
some
of
that
synchronous
behavior.
E
So
this
is
some
of
the
now
kind
of
called
out
as
asynchronous
behavior
of
yang,
so
you've
got
both
subscription
to
yang
notifications
and
yang
push
very
nice,
because
you
can
subscribe
to
the
data
elements
of
the
yang
module,
but
again
because
it
is
only
a
data
model,
you,
you
are
limited
in
what
you
can
do,
so
you
can
subscribe
to
an
element
in
the
model
and
you
can
say
send
me
updates:
send
a
yang
push
update
when
that
model
changes
or
when
or
at
a
periodic
interval,
but
as
it's
defined
today.
E
E
You
would
not
necessarily
be
able
to
trigger
a
larger
set
of
of
a
report
or
sort
of
a
state
of
what's
happening
so
kind
of
differentiates.
Those
last
couple
things
to
talk
about
here,
so
there
is
an
entire
working
group.
It's
the
constrained
resources
working
group.
They
develop
a
protocol
under
that
called
constrained
application
protocol.
As
you
can
see
in
the
picture
here,
it
sort
of
fits
on
top
of
the
transport
layer
can
be
used
for
applications
or
anything
talking
to
these
constrained
devices.
E
You're
talking
about
like
sort
of
embedded,
iot,
low,
low
process
load
memory
sort
of
devices,
so
the
protocol
was
designed
to
be
very
concise,
which
is
something
we
kind
of
need
in
the
the
challenge
network
but
kind
of
going
further.
How
are
they
approaching
network
management?
Well,
they
are
developing.
I
think
it's
in
the
works
right
now.
A
new
protocol
called
core
conf,
which
is
going
to
use
that
yang
library
use
the
co-app
protocol
to
then
talk
to
devices
and
push.
E
You
know
data
updates
to
the
model
or
retrieve
elements
from
that
model.
So
a
few
comments
there,
you
know
again
you're
bound
to
yang
and
and
and
because
there's
a
lot
of
concern,
I
think
for
hey,
we're
start
to
expose
management
of
devices
over
the
network,
they're
trying
really
hard
to
push
security
features
into
the
core
comp
protocol.
E
I
think
that's
not
bad,
it's
great
for
the
use
case.
I
think,
for
you
know
some
of
the
challenged
network
use
cases,
especially
when
you
look
at
how
you
are
approaching
transport
by
a
bp
sec
bundle
security,
which
is
an
entire
protocol
to
to
put
security
into
the
transport
mechanisms
you
might
be
limited
to
then
have
an
extra
layer
of
security.
If
you
were
to
try
and
use
this
there's
also
the
sort
of
yang
item,
identifiers
or
sids.
E
This
is
how
they
can
concisely
encode
access
to
each
of
these
data
elements
inside
the
protocol,
which
is
a
nice
approach,
but
at
least
as
I
read
it
today,
there's
no
hierarchy.
There's
no
way
to
reference
kind
of
going
back
to
that
snmp
oid
structure,
there's
no
way
to
sort
of
reference.
These
are
rfc
spec
or
vendor
specs
and
then
sort
of
what
is
the
way
to
get
down
to
the
particular
data
element
without
directly
addressing
them
with
possibly
quite
large
ids.
E
So
it
makes
a
little
bit
different.
The
last
one
I
wanted
to
mention.
I
don't
think
anyone
has
talked
about
it
much,
but
because
we
call
out
that
autonomous
behavior
is
a
desirable
property
of
of
of
challenged
network
management.
I
think
it's
fair
to
at
least
acknowledge
some
of
the
work
that's
going
on
in
the
animal
working
group,
as
well
as
the
network
management,
research
group,
autonomic,
networking
and
intent
based
networking.
E
E
What
I
understand
is
there
there's
a
need
for
very
synchronous,
sort
of
communication
and
connectivity
between
these
nodes,
there's
also
a
need
for
supporting
infrastructure
like
dns
like
dhcp,
that
can
help
once
you
drop
the
node
and
it
and
it
talks
over
that
autonomous
control
plane.
It
knows
how
to
then
start
to
self-configure,
because
it
gets
a
little
bit
of
information
to
talk
to
these
particular
services
so
again
kind
of
going
back
to
what
is
that
challenge
network
use
case
very
different
from
this
one
as
well.
E
So
I
kind
of
mention
all
of
these
things.
I
think
there's
a
lot
that
we
can
learn
and
borrow
from
these
different
protocols,
but
why
I'm
talking
to
you
today
is
to
say:
do
we
think
any
of
these
are
applicable
to
challenged
networks?
Have
I
missed
anything?
Have
I
misunderstood
anything,
and
do
we
agree
that
there
is
sort
of
a
a
unique
need
to
challenged
network
management
today?
So
I
will
pause.
I
see
actually
rick
in
the
queue
speak
up.
Let
me
know.
A
First
off
emery.
Thank
you.
I
think
this
is
a
really
good
gap,
analysis
of
what's
out
there
in
the
ietf
at
the
moment,
which
is
particularly
relevant
as
as
really
that
is
what
the
ops
area
directors
asked
us
to
do.
So
if
we
can
try
and
capture
this
information
in
the
ama
document
as
well,
then
I
think
that
will
make
that
document
great.
A
My
second
point
is,
I
would
really
like
to
present
the
inverse
of
this
pres
or
you
to
present
or
someone
to
present
the
inverse
of
this
presentation
to
the
netmod
community
at
the
next
ietf.
So,
basically,
instead
of
presenting
to
us
to
say
this
is
what
everyone
else
is
doing
and
why
it's
difficult
present
to
them.
You
have
all
of
this,
and
this
is
why
it
doesn't
quite
work
for
us
help
us.
I
think
that
would
be
a
a
great
conversation
opener
with
them.
A
E
Roger
no,
I
I
completely
agree
I
mean
working
through.
This
has
been
actually
nice
because
it
actually
helps
us
understand.
You
know,
okay,
what
are
those
desirable
properties,
what
makes
it
unique
and
then
we
can
talk
about
those
more
clearly.
So
I
agree-
and
I'm
happy
to
do
that.
My
last
comments
here
right,
so
we
are
working
on
an
updated,
ama
spec.
We
we've
started
to
include
some
of
these
differentiators
in
the
one
that
was
published
right
before
itf-112.
E
I
think
there
is
a
little
bit
more
work.
That's
needed
to
really
emphasize
like
the
rule-based
autonomy,
clarify
that
need
for
hierarchical,
moderated
absolute
data
definitions
really
really
clarify
that
it's
independent
of
the
underlying
transports.
You
look
at
all
these
other
protocols
and
they
say
well,
it
must
use
udp
or
it
must
use
tls
and
so
forth.
I
think
that
is
something
different
for
challenge,
network
management
and
try
and
make
sense
of
this.
E
So
the
last
slide
next
steps
right,
just
like
you
said,
continue
to
work
with
these
other
itf
working
groups,
discuss
overlap,
discuss
what's
good
and
bad
from
each
and
then
we
start
to
look
into
the
the.
Maybe
more
interesting
things
right:
what
are
those
application?
Data
models,
asynchronous
management
models,
the
protocol
and
so
forth?
So
I'm
it
done.
B
No,
this
is
ed.
I
just
wanted
to
come
back
and
echo
what
rick
had
said.
This
is
an
excellent
you
know,
sort
of
updated
review
of
both
what
dtn
needs
for
management
and
how
it
fits
into
sort
of
these
emerging
other
ecosystems
in
the
ops
area
and
getting
a
presentation.
B
A
Thanks
very
much
emery,
so
I
think
next
up,
I
I
do
need
to
find
a
way
of
getting
the
agenda
on
the
same
page
as
everything
else.
I'm
trying
to
do.
We've
got
sarah
talking
about
another
part
of
the
management
piece.
Sarah,
are
you
okay,
presenting
your
own
slides
or
do
you
want
to
shout
next
at
me.
M
A
F
Okay,
thank
you
yes,
so
my
name
is
sarah
hubbell
and
I'm
presenting
the
asynchronous
network
management
system,
which
is
a
project
we
have
going
on
here
at
jhupl
again.
This
is
this
is
for
the
management
of
challenge
networks.
We
are
tracking
the
name,
change
and
and
we'll
make
changes
accordingly,
as
as
we
continue
our
work
next
slide.
F
So,
as
we
all
know,
managing
dtn
networks
is
important
in
the
anms
project.
We
are
incorporating
all
of
the
work
from
the
standards
community
into
a
tool
to
manage
challenge
networks.
The
tool
we're
developing
is
meant
to
show
that
we
can
build
a
console
using
dtm
standards
that
both
operators
will
understand
and
will
like
to
adopt
permissions.
F
F
In
short,
we
want
to
be
able
to
monitor
and
control
network
nodes
and
challenge
networks
interoperate
with
existing
network
management
tools
and
be
able
to
manage
implementations
of
bundle.
Protocol
agents
we're
initially
testing
with
ion
integration,
since
it
ships
with
a
reference
and
an
agent,
but
we
should
be
able
to
operate
with
any
bp
implementation
once
once.
Our
development
is
complete
next
slide.
F
F
So
this
is
getting
a
little
bit
more
into
how
we
are
breaking
up
a
ms
among
different
modules,
while
we
are
developing
it.
The
key
point
here
is
that
we
we
do
want
to
build
the
system
in
a
modular
fashion
in
order
to
allow
users
to
be
able
to
plug
their
own
solutions
into
ours
to
the
maximum
extent
possible.
F
So
this
slide
shows
a
notional
representation
of
our
layer
of
three
architecture,
the
so
the
central
processing
block
there
will
be
handling
all
of
the
automation
and
orchestrations
or
activities.
It
has
a
local
agent
there
running
to
to
do
things
like
state-based
rules,
time-based
rules
for
the
for
the
local
system.
F
We
have
a
data
access
layer
for
all
of
the
the
data
needed
to
orchestrate
this
system.
The
agent
clearinghouse
will
handle
everything
coming
in
from
agents
application
access
is
everything
coming
in
from
the
user
interface
and,
and
things
like
that
that
we
build
out
the
transcoding
piece
there
is,
is
a
little
bit
interesting,
so
that
one
will
handle
translating
between
any
different
representations
of
of
commands
to
to
agents.
F
So
obviously,
right
now
we're
we're
focusing
on
like
string
encodings
going
to
seabor,
but
we
do
want
to
make
that
one
plugable
as
well,
so
you
can
plug
in
your
own
codex
for
any
sort
of
agent
specific
encodings.
You
need
network
access,
handles
everything
talking
out
to
the
network
and
it's
kind
of
small
on
this
slide,
but
there's
three
diamonds,
three
purple
diamonds
at
the
bottom
right-
are
the
default
visualization
tools,
so
that
would
be
the
visualization
of
health
and
things
on
the
network
as
well
as
admin
and
agent
command
and
control
next
slide.
F
F
F
We
are
currently
in
the
first
spiral
of
development
and
plan
to
make
spiral
releases
open
source
as
they
are
completed
for
spiral,
one
we're
focusing
on
a
single
motivating
use
case
to
get
everything
just
up
and
running
so
at
the
end
of
the
spiral
we'd
like
users
to
be
able
to
configure,
am
a
agents
for
report
generation
and
receive
reports
back
and
display
them
in
our
visualization
tool
to
kickstart
development
we're
currently
using
existing
ion
agents,
and
a
lot
of
our
effort
is
actually
actually
focused
on
containerization
of
components
for
easy
deploy
and
integration.
F
I
think
my
last
slide
next
slide,
so
this
is
just
to
wrap
up
here's
a
depiction
of
our
logical
view
of
the
different
components
that
we're
building
out
and
the
functionality
and
each
the
yellow
boxes
are
the
ones
that
we
envision
working
on
during
this
part.
During
this
first
spiral,
everything
will
be
built
out
as
we
as
we
progress,
but
that
will
be
what
the
first
cut
looks
like.
N
And
sorry,
thanks
for
the
presentation
is
a
very,
very
interesting
topic.
You
you
mentioned
you
want.
You
basically
would
like
to
have
feedback.
What
specific
areas
we
are.
You
are
looking
feedback
for.
F
A
Good
plan,
thank
you
very
much.
Sarah,
I'm
keeping
an
eye
on
the
time
and
we
overrun
in
about
12
seconds,
but
thank
you
for
that.
So
it
should
be
open
mike
if
anyone
has
any
last
minute
comments
or
questions,
we'll
try
and
keep
the
session
going
for
a
little
bit
longer,
but
otherwise
thank
you
very
much
for
attending
for
those
who
have
to
shoot
off
to
another
meeting
or
an
emergency
meal
or
something
I'll
turn
my
video
on
for
some
of
you.
A
It
may
be
lunch
or
breakfast,
but
otherwise.
Thank
you
very
much
for
all
your
contributions,
some
very
much
on
charter,
some
very
much
looking
into
the
future,
and
that's
always
nice,
hopefully,
educational
and
interesting,
I'm
filling
time.
While
I
wait
for
somebody
to
jump
into
the
queue
adam,
do
you
have
anything
to
add
about
the
minutes?
Do
you
need
somebody
to
correct
any
information
that
you
missed,
or
are
we
looking?
Okay.
O
I
please
look
through
make
sure
I
didn't
miss
anything.
I
know
that
management
updates.
I
got
distracted
here,
so
I'm
gonna
go
back
and
watch
youtube
video
to
get.
A
A
Okay,
thank
you
very
much.
So,
as
usual,
the
minutes
will
be
coming
out
some
days
from
now,
because
we'll
need
to
just
recheck
on
the
youtube
and
just
liaise
between
the
chairs
and
adam,
just
to
make
sure
we've
got
everything
there,
but
otherwise
thank
you
very
much
to
our
presenters.
Thank
you
very
much
to
our
attendees.
A
We
will
be
having
a
meeting
at
the
next
ietf.
It
may
be
possible
to
have
in
person
there's
some
discussion
about
whether
it's
in
the
eu
or
the
us
covered
willing,
etc,
etc.
Either
way
we
will
be
meeting
virtually
or
in
person.
So
I
look
forward
to
speaking
to
you
before
then.
Meanwhile,
please
take
discussions
to
the
mailing
list.
There's
lots
of
interesting
things.
We
will
be
asking
for
the
working
group,
a
bigger
pardon,
we'll,
be
asking
for
the
working
group
adoption
of
the
two
documents
that
were
requested.
B
Yeah
just
two
things,
as
we
start
talking
now
about
milestones
associated
with
some
of
those
work
areas.
Please,
if
you
want
to
work
on
those
we're
gonna
put
a
call
to
the
mailing
list,
but
that
doesn't
mean
in
the
interim.
B
You
can't
jump
forward
on
the
mailing
list
and
say
I
would
like
to
work
on
this
and
we
could
start
proposing
and
having
those
milestone,
date,
discussions
and
then,
lastly,
just
for
for
ronnie
bull
in
in
the
chat,
he
did
post
a
link
to
another
project
in
the
ipn
sig
and
some
of
the
work
they're
doing
for
dtn
in
a
report
that's
coming
out,
and
we
should
also
be
cognizant
of
that
additional
work.
So
those
were
my
two
last
items.
A
Okay
yeah,
I
just
thought
one
last
thing:
a
couple
of
people
have
got
personal
drafts
on
topics
which
are
on
the
new
charter
if
they
want
to
just
reissue
them
to
sort
of
bring
them
back
to
life
in
the
document
tracker.
That
would
be
great,
even
if
you
just
change
the
name
and
resubmit
it
will
keep
it
alive
rather
than
it
disappearing
into
the
limbo
of
expired
personal
drafts.
A
But
otherwise,
thank
you
very
much
for
your
attendance
and
I
will
speak
to
you
next
time
in
person
or
virtual
or
whatever
thanks
very
much,
I'm
gonna.
I
don't
know
how
to
close
the
session.
I'm
just
gonna
quit
the
room
and
turn
my
camera
off.
Thanks,
guys
see
you
later
good,
seeing.