►
From YouTube: IETF111-DTN-20210726-1900
Description
DTN meeting session at IETF111
2021/07/26 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
So
I
make
it
well
it's
on
time,
my
time,
what
is
it
12
o'clock
pacific
time
so
shall
we
get
started?
So
yes
welcome
to
ietf
111.
This
is
the
first
session
on
the
monday
morning,
well
monday
lunchtime,
so
yeah.
If
it's
going
to
go
wrong,
it's
going
to
go
wrong
today.
A
So
this
is
the
dtn
working
group.
Normally,
if
this
is
an
in-person
meeting,
I
would
say
something
like
if
you're
in
the
wrong
room.
You
want
to
be
down
the
hall
for
wherever,
but
I'm
assuming
you've
all
dialed
in
intentionally.
So
yeah
welcome
to
111
working
group.
So
a
couple
of
admin
things
to
go
through
first
off
ed-
and
I
are
your
co-chairs.
A
Hopefully
you
can
see
our
video
at
the
moment.
The
agenda
I'll
actually
put
on
screen
in
a
second
important
things
to
note
are
the
participant
guide.
There
is
a
url
there
for
you
if
these,
so
all
these
slides
are
available
on
the
data
tracker,
so
you
can
get
to
the
dtn
working
group
data
tracker
you'll
find
this
all
this
information
and
the
slides
for
the
other
presentation
are
there
as
well,
including
the
links
to
the
meat,
eco
participation
guide
and
how
to
report
issues.
A
If
you
have
any
general
purpose
issues
with
the
ietf
meeting
in
general,
this
is
the
notewell.
Hopefully
those
of
you
who
have
attended
previous
ietf
meetings
will
be
familiar
with
the
notewell.
This
covers
privacy,
ipr
and
all
the
usual
things
that
an
organization
needs
to
have
in
place
to
protect
yourself
itself
and
others.
Please
make
sure
you
read
and
understand
this.
A
If
you
haven't
read
a
note
well
before
there's
obviously
some
references
to
the
in-depth
information
behind
what
is
covered
in
the
note
well-
and
I
strongly
suggest
you
read
these
things
if
you
haven't
before
so
our
agenda
for
today's
meeting,
we
have
a
reasonably
light
agenda,
but
it's
filled
up
at
the
last
minute,
so
I
think
we
will
cover
all
two
hours
so
we'll
start
off
well,
the
administrator
from
the
chairs
is
sort
of
ongoing
as
we
speak,
we've
given
ourselves
10
minutes,
but
it
may
not
take
that
long
and
then
we're
going
to
go
straight
into
continuing
the
discussion
that
took
up
the
first
half
of
our
virtual
interim,
which
occurred
eight
weeks
ago.
A
I
think
where
we
were
discussing
the
rechartering
of
the
working
group
and
I'll.
Let
ed
cover
that
in
some
depth,
which
I
think
is
straight
on
to
the
yes,
okay,
so
some
final
bits
of
administration
meat
echo
can
struggle.
Sometimes
it's
got
really
good.
Recently
we
keep
saying
this
on
our
slides,
which
is
a
bit
unfair
on
poor
meat
eco,
because
it's
it's
pretty
good.
We
need
minutes
taken
please
adam.
A
Our
group
secretary
is
attempting
to
take
some
minutes,
but
there
is
the
kodi
md
minute
taking
facility
built
into
meet
echo.
This
is
a
collaborative
editing
tool,
so
please
help
out.
I
happen
to
know
adam
is
somewhere
in
north
dakota
at
the
moment
and
has
fairly
dodgy
connectivity.
A
So
if
you
spot
him
missing
something,
please
feel
free
to
edit
yourself.
Equally
names
are
a
classic
because
people
always
say
their
own
names
quite
quickly,
expecting
everybody
to
know
how
to
spell
it
and
they
often
get
typed
up
wildly
incorrectly.
So
if
you
spot
your
own
name
being
mistyped,
please
just
correct
it
as
soon
as
you
see
it.
That
would
be
great.
A
The
other
thing
is
the
mailing
list.
I'm
assuming
you
are
familiar
with
the
mailing
lists,
if
not
dtn
ietf.org,
and
if
you
wish
to
contact
the
chairs
about
anything
dtn
hyphen
chairs
at
ietf.org,
the
main
business
of
the
ietf
working
groups
happens
on
the
mailing
list.
So
please
subscribe
if
you're
not
already
subscribed
and
if
you
have
frequently
for
those
who've
not
attended
meetings
like
this
before.
A
If
a
discussion
is
starting
to
consume
our
time,
we
will
use
that
inevitable
phrase
of
let's
take
this
to
the
mailing
list.
The
mailing
list
is
the
perfect
place
to
really
chew
over
long,
complicated
things
and
have
a
good
discussion
where
people
can
take
their
time,
read
an
email
ingest
it
and
then
reply
at
length
and
that's
where
the
main
work
of
the
working
group
really
happens.
A
B
B
As
as
we
all
remember,
the
initial
set
of
work
was
to
take
the
bulk
of
the
information
coming
out
of
the
dtr
dtnrg
out
of
the
irtf
and
give
it
that
refresh,
because
it
had
been
out
at
that
point
for
probably
eight
to
ten
years.
We've
done
that
you
know
we,
bp,
v7
bpsec
bpsac
default
security
context
and
the
tcp
clv4
convergence
layer
have
now
all
made
it
their
way
through
the
various
levels
of
review.
B
B
Then
that
is
exactly
how
we've
laid
things
out
things
that
we
see
as
revisions
coming
out
of
the
dtnrg
seem
like
they
might
be.
B
Perhaps
perhaps
aspirationally
work
less
working
group
intensive,
because
it
is
adapting
prior
work
prior
algorithms
and
and
bringing
it
sort
of
up
to
speed
with
what
has
tracked
over
the
work
we
have
done
in
the
past
several
years,
extensions
to
new
work,
defining
new
extension
blocks,
defining
new
security
context,
perhaps
defining
new
convergence
layers
is
also
seen
as
somewhat
less
working
group
intensive,
because
we're
not
starting
from
scratch.
B
We
do
have
definitions
and
examples
of
what
all
of
these
sort
of
smaller
contributions
should
look
like
from
a
working
group
perspective
and
then
the
brand
new
algorithms
that
come
up
really
truly
extensions
to
new
capabilities.
We
think
is
going
to
be
the
bulk
of
the
working
group
tasking
if
we
just
look
at
the
overall
effort
now
that
that's
our
best
guess
we'll
we'll
see
how
that
goes
when
we
actually
get
into
working
group
reviews
and
ad
reviews
and
iesg
reviews.
But
that
is
how
we've
interpreted
these
initial
categories.
B
So
then,
if
we
go
to
the
next
slide,
we
took
a
lot
of
the
discussions
from
the
mailing
list
and
from
the
interim
working
group,
and
we
started
categorizing
those
work
items
in
these
different
ways
coming
out
of
the
irtf
dtnrg
revisions.
There
was
a
question
as
to
who
is
going
to
update
and
standardize
ltp.
B
We
originally
had
this
in
our
working
group
since
the
interim
meeting.
I
believe
that
ccsds
might
also
be
adopting
standardizing
ltp,
and
I
think
one
of
the
things
that
we
should
make
determination
on
is
whether
we
want
to
be
working
on
that
in
parallel
with
ccsds
or
whether
we
remove
this
from
our
charter,
because
another
organization
ccsds
would
be
standardizing
it
and
honestly
may
prefer
and
be
more
of
a
user
of
ltp
than
than
some
of
the
community
here.
B
We
removed
that
from
bundle
protocol
version
6
as
part
of
standardizing
bundle,
protocol
version
7
and
now
we
do
need
to
go
back
and
understand
how
we
maintain
that
that
sense
of
custody
transfer,
which
is,
of
course,
something
that
was
bookmarked
out
of
the
information
coming
out
of
the
ritf
and
why
we
we
list
it
under
that
category,
the
extensions
to
existing
work.
We
have
a
a
very
well
thought
out
and
far
along
cosi,
bpsec
security
context,
which
is
an
example
of
another
security
context.
B
We
have
some
discussion
on
bundle
and
bundle
encapsulation,
which
is
defining
another
convergence
layer.
We
have
some
extension
blocks
like
a
quality
of
service
indication
for
bundles,
which
would
be
an
extension
block,
and
we
have
already
some
some
initial
definitions
of
extension
blocks
and
then
we
do
have
that
completion
of
service
identifiers
from
our
original
charter
next
slide
and,
I
believe,
last
slide
and
then.
Finally,
what
are
the
truly
new
things
that
we're
trying
to
tackle?
B
And
these
are
where
we
think
the
the
bulk
of
the
the
working
group
work
is
going
to
be
as
we
try
and
make
those
decisions
and
designs.
The
first
is
the
asynchronous
management
of
delay,
tolerant
devices,
networks
or
applications.
The
second
is
a
naming
and
addressing
architecture.
B
The
problem,
understanding
the
problem,
space
and
understanding
the
the
pieces
that
we
need,
as
we
make
incremental
progress,
and
so
a
naming
and
addressing
architecture
is
our
first
step
along
that
very
long
path
and
then
finally,
really
understanding
some
of
the
architecture
of
naming
and
addressing
can
then
start
to
inform
neighbor
discovery,
which
is,
we
think,
the
other
and
third
sort
of
large
new
piece
of
work
for
the
working
group
that
set
defines
what
we
believe
are
the
working
group
items
rationalized
and
justified
by
the
categories.
B
So
that's
what
we
took
out
of
the
interim
meeting
and
the
discussions
we
had
seen
so
far
on
the
mailing
list,
I'd
like
to
pause
here,
rick,
if
there's
anything
you'd
like
to
add
or
otherwise,
if
there's
anyone
that
anyone
like
to
add
by
coming
up
to
the
mic.
A
One
thing
which
was
a
discussion
which
happened
on
the
mailing
list
today
around
alternative
methods
of
reliability
as
a
lightweight
alternative
to
custody
transfer.
So
my
off
the
cuff
thought
was
whether
the
if
I
jump
back
two
slides
the
oh
there
we
go
so
we
have
under
the
irtf
dtnrg
revisions.
Custody
transfer
for
reliable
bundle,
delivery.
A
The
question
is
whether
actually
given
there's
some
interest
in
other
ways
of
of
implementing
reliable
bundle,
delivery
by
perhaps
updating
some
of
the
notification
messages
or
extending
some
of
the
the
notification
messages
instead
of
a
full
custody
transfer
protocol
or,
however,
you
wish
to
describe
it
whether
that
that
more
generic
work
item
is
worth
having.
A
Rather
than
saying,
we
will
work
on
custody
transfer,
that's
not
to
exclude
custody
transfer,
but
it's
whether
that
point
should
be
more
generic
or
not
that
arrived
today,
I
haven't
really
had
a
chance
to
chew
it
over,
and
I
I'm
interested
in
what
other
people
think
of
it
and
scott
is
in
he's,
got
in
the
queue
go
ahead.
Scott.
C
Yeah,
it's
good,
okay,
okay,
good
just
two
thoughts
on
this
one
is
that
the
the
the
term
custody
transform
the
concept
of
custody
transfer,
I
believe,
actually
originated
at
jpl
about
a
zillion
years
ago,
a
guy
named
ed
greenberg
came
up
with
it.
While
we
were
looking
at
doing
ccsds
file
delivery
protocol
and
the
the
the
concept
of
of
custody
transfer
is
a
little
bit
is
a
distinct.
C
Okay,
all
right,
so
the
concept
of
custody
transfer.
C
Originally,
the
idea
was
as
you're
as
the
as
the
data
is
making
its
way
through
the
network
at
each
forwarding
point
that
forwarder
says
to
the
thing
before
it:
I've
got
this
you
you
can
let
it
go
I'll,
take
care
of
getting
it
from
here
and
and
and
that
you
know
continues
end
to
end
the
custody.
Transfer.
Implementation
in
bpv6
was
a
way
to
do
that,
but
using
reliable
convergence
layer
protocols
between
nodes
is
likewise
a
way
to
do
that.
C
So
I
think
that
the
custody
transfer
as
designed
in
in
bpv6
was
problematic
and
for
for
a
number
of
reasons,
and
and
we
removed
it
from
bpv6,
an
adaptation
of
that.
I
is
in
the
what's
being
proposed,
as
bundle
bundle
encapsulation,
and
I
I
think
separate
from
that
and
and
not
in
conflict
with
it
is
this
idea
of
felix's
for
status
reporting.
C
So
what
what
I
would
just
suggest
here
is
that
custody
transfer
as
a
as
a
work
item
in
terms
of
developing
a
new
protocol.
I
I
would
urge
us
like
not
to
do
that.
I
would
or
just
to
think
about
it
in
terms
of
of
the
concept
of
custody
transfer
and
what
the
best
way
to
accomplish
it
would
be.
C
Actually,
I
I
the
because
felix's
concept
is
not
actually
about
reliability,
it's
because
it
leaves
the
question
of
re-transmission
up
to
the
to
the
sender.
It's
it's!
Okay,
yeah!
It's
it's
more
more
in
the
way
of,
I
would
say
more
broadly,
it's
about
signaling.
A
C
A
C
Okay,
I
I
think
we
made
the
right
decision
in
removing
it
from
bpv6
and
essentially
migrating
it
into
bundle
and
bundle.
Encapsulation.
B
Yeah-
and
this
is
that
the-
I
think
that's
a
key
point
here-
which
is
it's
not
completely
removed
from
the
ecosystem,
some
of
that
retransmit
responsibility
can
be
delegated
into
bibi.
C
And
and
other
reliable
convergence
layer
protocols
such
as
tcpl
v4,
essentially
accomplish
the
same
thing
as
custody
transfer.
That
is,
they.
A
I
would
disagree
there,
scott,
because
a
reliable
convergence
layer
will
guarantee,
within
some
constraints,
a
delivery
of
a
bundle
along
one
hop
across
one
hop.
A
But
if
you
are
an
end-to-end,
if
you're,
if
you're
an
end
system
trying
to
to
understand
whether
the
bundle
you
are
sending
to
some
far
away
end
point
across
multiple
hops,
without
knowledge
of
the
convergence
layers
used
between
you
and
the
final
destinations,
but
you
still
care
about
whether
you
can
stop
re-transmitting
or
should
re-transmit
or
discard
the
bundle
from
your
local
store,
because
somebody
along
the
way
is
going
to
guarantee
it's
it's
re-transmission
or
that
that
multi-hop
path
problem
can't
just
be
solved
with
convergence
layers.
I
I've.
C
Actually,
just
every
I
agree
with
that,
but
I
think
that
multi-hop
problem
is
a
mission
creep
for
custody
transfer.
I
think
it's
a
bridge
to
r
for
custody
transfer
for
a
number
of
reasons,
one
of
which
is,
if
you
don't
know,
who's
gonna,
take
custody
of
who's
supposed
to
respond.
C
How
can
you
know
how
to
set
your
retransmission
timer
to
know
that
you're,
just
not
gonna,
go
off
too
early
or
too
late?
Okay
right
so
there
is.
There
is
a
there's,
a
concern
there
and
I
think
that
concern
needs
to
be
addressed.
You
know
what
what's
the
actual
requirement
and
and
and
what's
the
best
way
to
do
it-
I
I
would
not
propose
to
revisit
bpv6
company
transfer
to
accomplish
that.
A
A
The
idea
that
there
is
interest
in
working
on
reliability
signaling
for
bundle
delivery,
but
remove
the
words
custody
transfer,
because
they're
they're
loaded
with
the
bpv6
context
is
that
I
think
that's
perfect.
Yes,
exactly.
E
Thank
you,
so
one
one
detail
some
some
time
ago,
in
an
exchange
with
scott,
I
also
talked
about
the
concept
of
constantly
transfer
servers
that
good
in
case
of
excessive
load
of
the
of
the
transmission
of
the
bundles
could
keep
a
storage
of
the
of
the
bundles
to
be
retransmitted
to
to
the
intermediate
or
final
endpoints.
E
Well
that
kept
in
a
in
a
discussion
that
we
didn't
follow
up.
But
I
think
it's
an
important
point
that
in
some
in
some
occasions
like
systems
that
we
work
on
could
be
very
useful.
A
Oh,
I
I
think
we're
all
agreed
that
that
that
use
case
is
something
that
that
dtn
really
ought
to
be
addressing.
But
I
I
think
scott's
point
and
I
I
agree
with
him.
This
is
rick
with
his
chair
hat
off
that
bundle,
protocol
version,
six
custody
transfer
had
known
problems
and
taking
a
step
back
and
looking
at
what
are
we
trying
to
solve
here
and
what
mechanisms
do
we
now
have
in
place
with
bpv7
that
we
can
use
to
deliver
it
such
as
bundle
and
model
encapsulation?
A
There
may
be
a
label
switching
option
here,
depending
on
pros
and
cons
for
security.
There
may
be
just
some
very
lightweight
notification,
changes
that
need
to
be
changed
or
need
to
be
added.
So
I
think
the
general
topic
I'm
hearing
an
interest
in.
Does
anyone
want
to
jump
to
the
mic
and
say
no?
This
is
this
is
nonsense.
We
shouldn't
be
wasting
time
on
this
or
no,
we
don't
have
the
bandwidth
or
interest
to
work
on
this.
Just
I
want
to
hear
a
counter
a
counter
voice.
If
there
is
one.
F
G
B
Actually,
no
one
of
the
things
that
came
up
was
since
we
originally
put
this
in.
I
believe
that
the
ccsds
has
said
that
they
want
to
also
standardize
ltp.
So
after
rick
asked
the
question
about
custody
transfer
and
reliable
signaling,
I
was
going
to
ask
the
question
as
to
whether
we
should
remove
ltp
from
our
charter,
because
it
is
already
in
the
ccsds
charter.
A
F
Can
I
can
I
respond
very
quickly,
of
course,
we're
seeing
we're
seeing
applications
for
ltp,
also
in
the
terrestrial
domain,
not
necessarily
just
the
space
domain
and
the
reason
we
see.
That
is
because
we
see
ltp
as
being
a
viable
protocol
for
disrupted
environments
where
latency
isn't
so
much.
The
main
problem
is
as
much
as
disruption.
A
Okay.
Okay,
so
I
happen
to
know
you
were
one
of
the
people.
You've
got
a
personal
draft
on
ltp
updates,
or
did
it
morph
into
a
udp
cl
sorry,
I
need
to
actually
go
back
to
the
data
tracker
and
look
at
this.
Are
you
would
you
the
ltp
fragmentation
personal
draft
you
put
in?
Are
you
would
you
be
happy
to
continue
working
on
that?
Do
you
think
that
that
has
relevance
and
interest
to
us.
F
I
I
believe
so
yes,
but
within
the
within
the
context
of
ltp,
it's
looking
at
ways
you
can
do
fragmentation
in
such
ways
to
produce
the
best
performance.
Given
the
you
know,
the
amount
of
data
that's
presented
to
the
to
the
ltp
stack.
A
F
A
B
I
think
we
do,
but
my
my
question
back
is
how
much
of
this
is
the
work
that
we
would
do
in
this
working
group
for
an
ltp
convergence
layer
versus
the
work
of
standardizing
ltp
as
a
protocol.
A
Well,
perhaps
that
might
be
the
the
the
way
to
what's
the
expression
to
to
to
split
the
problem
in
two
there's:
a
nice
expression,
I've
forgotten,
where
we
sort
of
pass
ltp
to
ccsds
and
say
go
for
it
work
on
fragmentation
for
it
or
whatever,
and
we
will
standardize
how
to
make
a
bp
v7
convergence
layer
using
ltp
as
a
as
an
underlying
protocol
fred,
you
still
have
the
mic.
So
if
you
have
a
comment.
A
C
Okay,
I
like
that
idea,
a
lot
and
the
certainly
the
the
adaptation
of
using
ltp
to
support
bundle.
Protocol
in
a
convergence
layer
is
something
that
belongs
in
in
in
in
this
working
group.
It's
certainly
fine
for
for
this
working
group
to
undertake
ltp
standardization
as
well,
but
but
I
think
it
makes
it
more
complicated
because
of
the
need
to
reconcile
that
with
what
ccsds
is
doing.
C
So
I
would
propose
that
that
the
the
ltp
protocol
specification
itself
would
be
left
as
a
as
a
ccs
js
work
item.
I
I'm
pretty
sure
boeing
is
able
to
participate
in
ccsds
meetings,
so
I
I
would,
I
would
suggest,
sort
of
doing
it
that
way.
A
Okay,
that
sounds
reasonable
and
again,
if
anyone
has
any
major
objections
on
that
one
or
any
further
comment,
I'm
tempted
to
say
take
it
to
the
list,
because
I'm
watching
the
clock
does
anyone
have
any
comments
they
want
to
take
to
the
mic
about
any
of
the
other
proposed
things
on
the
charter
that
which
are
pretty
similar
to
the
the
outcomes
of
the
virtual
interim.
A
One
of
my
two
takeaways
from
the
virtual
interim,
particularly
on
this
slide,
was
to
add
neighbor
discovery,
and
we
there
was
a
comment
made
about
service
identifiers,
which
I
know
mark
blanche
was
really
keen
to
to
find
the
time
to
work
on
we've
sort
of
mashed
that
into
naming
and
addressing,
because
not
only
are
you
naming
and
addressing
endpoints
you're,
also
naming
and
addressing
the
services
that
are
at
those
end
points
or
our
services,
just
a
sort
of
a
subset
of
endpoints
within
the
the
taxonomy,
so
that
doesn't
mean
we
have
excluded
service
identifiers,
we've
just
sort
of
merged
it
all
into
what
on
earth
is
a
name.
A
What
is
the
location?
What
is
what
is
an
address,
therefore
etc,
but
does
anyone
have
a
pet
project
that
has
occurred
to
them
between
the
virtual
interim
and
now
that
they
would
desperately
like
to
lobby
us
to
include
the
reason
I'm
saying
this
is
that
when
we
recharter
and
and
state
these
work
items,
these
really
are
the
focus
for
the
working
group,
so
people
contributing
individual
drafts
on
other
topics.
A
They
are
unlikely
to
be
adopted
into
the
working
group
if
they're
not
really
work
items,
so
we
are
making
the
commitment
to
work
on
these
things
at
the
expense
of
other
things.
I
can't
see
the
queue
I'm
looking
at
slides
any
takers.
A
B
No
rick
quite
well,
it
is,
is
just
to
reinforce
the
idea
that,
as
we
adopt
drafts
within
the
working
group,
it
is
to
adopt
those
drafts
for
things
that
map
to
the
work
items
in
this
group
charter.
I
I
did
just
want
to
point
out
that
some
of
the
things
that
are
here
being
included
in
the
working
group
charter
had
existed
only
as
personal
drafts
prior
and
have
matured
quite
a
bit
over
the
past
few
years.
A
Rather
embarrassingly,
we
have
missed
an
item
off
this
list,
which
was
key
management,
so
I
know
fred
and
scott
both
had
a
personal
draft
they
put
in
ief
100
so
some
years
ago
now
on
distributed
key
management,
scott
fred.
Are
you
going
to
find
cycles
to
work
on
this?
Do
you
think
it's
something
we're
ready
to
tackle
yet,
or
are
you
happy
to
let
it
pass
for
a
bit.
C
This
this
is
scott.
I'm
I'm
very
invested
in
that
so
yeah.
I
will
find
some
time
to
work
on
it.
If
the
working
group
chooses
to
take
it
up.
A
C
A
A
This
is
you
and
I've
been
through
these
slides
and
this
this
charter
text
about
17
times
over
the
last
six
weeks,
and
I
can't
believe
we
missed
it
anyway.
There
we
go
right,
so
bang
on
time.
I
think
we're
on
to
our
next
agenda
item,
which,
obviously
I'm
showing
a
slide.
So
I
can't
what's
what's
next
on
the
agenda
ed,
I
can't
see
my
screen's
full
of
meet
echo
and
other
people's
slides.
B
Next
on
the
agenda
is
just
a
10-minute
overview
of
where
we
are
with
the
default
security
context,
update
rick
if
you're
already
set
up
for
screen
sharing.
Do
you
mind
sharing
the
screen.
A
Don't
mind
at
all:
I've
got
all
the
tabs
open.
Let
me
just
find
out
which
one
it
is
asynchronous
management,
architectures
updates
in
the
default
security
context.
Yep
yep,
perfect.
Your
your
title
says
something
completely
different,
dad
which
is
good,
which
is
what
has
confused
me.
A
B
So
if,
if
we
recall,
we
were
putting
together
a
package
of
documents
for
the
standardization
of
bp
version
7.,
we
realized
that
we
needed
bp
version
7
and
a
convergence
layer
and
also
a
security
protocol
associated
with
it,
and
that
three
tuple
was
needed
to
go
forward
through
isg
review.
In
the
course
of
that
review.
We
also
were
requested
required
to
provide
a
set
of
default
security
contacts
associated
with
bpsac,
to
provide
some
initial
education
and
description
on
how
we
thought
the
security
context
concept
would
work.
B
B
In
mid-may
of
this
year,
we
received
some
80
comments
associated
with
updating
things
such
as
scope,
flags
and
clarifying
how
we
would
be
handling
authentication
tags
using
the
aes
and
gcm.
B
We
then,
just
a
few
weeks
later
generated
a
dash
08
draft
in
early
june,
that
was
submitted
to
iesg
review
and
we
received
several
comments
back
again
and
then
we
produced
a
dash,
09
and
then
shortly
thereafter,
8-10,
which
at
that
point
captured
all
of
the
discusses
associated
with
the
default
security
context.
B
Where
we
are
right
now
coming
out
of
iesg
review
is
we
have
two
yeses
10,
no
objections
and
and
two
no
record
of
opinion,
so
that
is
enough
ballot
positions
to
pass,
and
I
just
yesterday
put
forward
a
dash
11,
which
incorporated
the
last
bit
of
non-required
editorial
comments
for
the
default
security
context.
At
this
point,
the
claim
is
that
dash
11
is
now
ready
to
go
forward.
B
We
made
a
decision
that
we
did
not
think
that
the
changes
that
were
made
to
this
document
were
of
significant
technical
change,
normative
change
to
require
another
working
group.
Last
call.
The
vast
vast
majority
of
changes
were
editorial
in
nature
to
include
adding
cddl
definitions
and
adding
test
vectors
and
so
on
to
just
help
implementers.
B
B
We
wanted
to
make
sure
that
we
were
using
the
correct
and
most
up-to-date
references
for
some
of
the
cipher
suites,
there's
a
preference
that
ietf
a
minor
preference
that
itf
cite
ietf
documents
if
they
cover
the
same
material,
so
we
updated
those
and
then
we
we
helped
point
back
into
bpv7
and
bpsac
in
the
citations
just
to
help
a
reader
unfamiliar
with
the
overall
ecosystem
know
where
to
look.
If
they
wanted
more
information
next
slide,
then
there
were
a
couple
of
normative
changes
that
were
made
and
and
and
three
of
them
essentially.
B
The
first
is
that
in
the
default
security
context,
you
know
concept.
B
We
allow
the
ability
for
either
the
the
message
authentication
code,
the
mac
that's
generated
with
the
hmac
sha
security
context
or
the
authentication
tag
generated
with
the
ciphertext
and
additional
authenticated
data
to
be
to
specify
whether
you
cryptographically
bind
those
activities
with
other
elements
of
a
bundle.
So,
for
example,
you
could
include
a
primary
block
with
the
plain
text
over
which
you
calculate
an
integrity
signature
or
you
could
include
the
primary
block
with
other
additional
authenticated
data
when
you
generate
an
authentication
tag
in
aes
gcm.
B
Similarly,
we
allowed
optionally
to
include
the
various
elements
of
the
target
block
header,
as
opposed
to
simply
the
target
block
type
specific
data
and
the
same
for
the
security
block
header
as
well.
B
In
all
of
that,
the
comment
that
came
back
from
the
security
area
review-
and
they
are
correct-
is
that,
in
order
for
this
to
be
more
secure,
we
needed
to
actually
include
the
value
of
the
flags
in
the
in
the
plain
text
or
in
the
authentication
data
itself,
and
there
were
certainly
reasons
for
that
that
were
compelling,
and
so
now
that
set
of
data
includes
the
two
bytes,
the
16
bits
associated
with
those
flags.
B
To
say
this
is
how
we
will
be
encrypting
keys
when
we
carry
encrypted
session
keys
and
then
the
last
is
there
was
a
request
and-
and
we
saw
that
it
was
a
reasonable
request-
that
the
authentication
tag,
certain
cipher
suites
in
asgcm
will
produce
ciphertext
and
authentication
tags
as
separate
elements
in
the
api,
and
the
question
became
some
conventions
require,
or
prefer
to
place
the
authentication
tag,
either
prepend
or
prepend
it
to
the
cipher
text
and
and
have
that
combination
of
ciphertext
and
authentication
tag
replace
the
targe.
The
target
blocks
block
type
specific
data
field.
B
What
we
determined
was
that
the
to
to
make
various
reviewers
so
happy
with
this,
the
authentication
tag
security
result
is
made
optional
if
the
security
result
is
present
in
the
bcb
for
that
target,
then
that
security
result
holds
the
authentication
tag.
If,
however,
that
that
security
result
is
not
present
in
the
bcb,
then
the
security,
the
authentication
tag
is
is,
is
merged
together
with
the
ciphertext
as
part
of
the
group
of
information
that
has
replaced
the
block
type
specific
data
in
the
target
block.
B
B
And
then
there
were
a
fair
number
of
informative
changes.
The
the
sense
coming
from
many
of
the
reviewers
is
that,
as
as
a
definition
as
a
specification
for
how
to
provide
and
populate
bcb
and
bib
security
blocks,
there
should
be
a
fair
bit
of
guidance
and
almost
educational
material
in
this
document
to
make
sure
that
we
do
not
receive
naive
implementations.
B
So
we
certainly
clarified
things
about
not
being
able
to
use
the
same
keys
across
different
security
contexts.
Even
when
you
were
doing
key
encryption,
we
added
some
examples
of
of
how
to
remove
the
bp
c-boring
codings
when
generating
canonical
forms.
There
were
really
quite
a
bit
of
clarifying
text
around
handling
the
authentication
tag,
as
we
just
spoke
about
and
then
an
awful
lot
of
guidance
pointing
to
nist
documents
and
other
documents.
B
B
Whether
or
not
implementation
should
have
constant
time
comparisons
when
verifying
integrity,
looking
over
the
upper
bound
and
the
number
of
distinct
encryptions
and
or
that
and
the
number
of
aes
blocks
that
should
be
covered
by
a
particular
key
before
that
key
is
not
used
anymore.
B
21
pages,
it
is
almost,
it
almost
doubled
the
size
of
this
document,
and
it
is
full
of
examples
of
security,
block
processing
of
bibs
and
bcb's
individually
and
together
with
various
targets
in
sample
bundles,
to
help
educate
on
on
how
this
all
comes
together
and
then.
Lastly,
brian
sipos
was
kind
enough
to
provide
an
example,
cddl
definition
for
the
ippt
and
the
aad
structures,
which
are
really
the
only
structures
that
are
uniquely
identified
in
this
document.
B
Obviously,
the
main
security
block
document
or
the
main
security
block
structure
is
defined
in
the
bpsec
document
itself
and
having
that
cddl,
we
thought
was
just
a
nice
bit
of
clarifying
text.
So
in
all
of
that,
there
were
a
few
editorial
changes,
a
very
large
amount
of
informational
changes
and
very
specific
and
targeted
normative
changes.
And
from
that
we
think
that
the
security
contacts
are
good
to
go
out
through
ad
review
and
then
out
into
the
editor's
queue.
B
H
So
thanks
for
doing
a
very
good
work,
I
promise
to
look
go
through
all
the
changes
during
this
week
and
hopefully,
after
this
week,
we'll
go
ahead.
A
B
There
is
currently
not.
I
would
actually
say
that
I
I
think
that
there
will
eventually
be
a
version
of
cddo
that
allows
for
unadorned
seabor
sequences,
and
I
would
I
would
rather
publish
at
some
point
a
more
normative
cddl
across
bpv7
bpsac
and
some
of
the
security
contexts.
At
a
time
when
we
have
better
representations
of
those
unadorned
sequences
to
save
some
space.
We
are
using
seabor
sequences
right
now
in
bp
sec
that
that
just
aren't
modeled
very
well
in
cddl.
A
A
B
Sir,
so
the
last
thing
I'll
say
on
that
is,
it
was
a
tremendous
amount
of
work.
Getting
these
documents
done
alex
white
and
sarah
heiner
helped
me
with
that
as
well.
So,
as
you
read
through
those
21
pages
of
test,
vectors
understand
that
that
sarah
was
one
of
the
people
that
was
going
through
all
of
that
and
making
sure
it
was
done
well
and
done
correctly.
So
don't.
Thank
me
thanks.
Sarah
and
alex.
A
So,
thank
you,
in
which
case
I'll
stop
showing
this
sarah.
Are
you
there?
Sarah?
Would
you
like
to
present
your
own
slides?
Does
that
help.
I
Is
it
possible
for
you
to
share
them?
I'm
just.
A
A
I
So
hi
everyone,
my
name,
is
sarah
heiner
and
I
work
at
the
johns
hopkins
applied
physics
lab
where
my
focus
is
gtn
security
and
I've
spoken
to
you
in
the
past
about
the
need
for
security
policy
for
bp
sec
and
today
I
want
to
take
that
topic
a
bit
further
and
present
a
potential
architecture
for
that
security
policy.
I
So
I've
added
a
couple
discussion
points
to
this
presentation,
which
I
think
we
will
take
offline
to
the
mailing
list,
but
feel
free
to
jump
in
at
any
point.
If
you
have
questions
or
comments
for
me,
so
as
we've
gotten
bpsec
out
the
door,
I
think
that
one
of
the
next
steps
here
is
developing
security
policy
to
start
building
that
user
base
for
bpsac.
I
I
So
with
that
quick
motivation,
I'm
going
to
try
to
cover
several
pieces
of
the
proposed
security
policy
architecture,
starting
with
design
principles
for
that
architecture
and
then
moving
into
a
data
model
that
we
developed
at
apl
for
the
policy
and
then
move
into
supporting
details
for
that
data
model.
I
We
know
that
security
policy
has
to
support
both
syntactic
and
semantic
interoperability,
so
we
need
the
ability
to
represent
security
policy
in
the
bundle
in
a
way
that
can
be
understood
by
all
nodes
that
are
processing
that
bundle,
but
we
also
need
to
implement
consistent
and
deterministic
behavior
as
a
result
of
the
application
of
policy.
I
I
So
we'll
begin
our
discussion
of
the
policy
architecture
with
this
data
model,
so
you'll
see
through
the
middle
of
this
slide,
that
there
are
five
major
components
that
are
interacting
to
implement
policy,
so
I'll
go
into
detail
for
each
of
these
components,
but
first
we'll
talk
through
how
they
are
interacting
so
reading
from
left
to
right.
A
bundle
is
first
matched
to
security
policy
rules
and
those
rules
are
identifying
the
security
processing
role
for
the
bpa,
so
that's
either
a
security
source,
verifier
or
acceptor,
and
then
also
describes
the
required
security
operation.
I
I
The
specification
criteria
provide
details
on
the
security
operation
that
has
to
be
applied
for
that
rule.
So
that's
defining
information
like
the
security
service,
security
context
and
any
parameters
needed
to
establish
that
context
and
then,
finally,
the
event
criteria
in
that
security
policy
rule
is
what
allows
us
to
associate
the
rule
with
an
event
set
which
is
defining
the
events
that
processing
actions
have
been
configured
for
next
slide.
Please.
I
So
this
is
quite
an
eye
chart,
so
some
of
the
statements
that
I'm
going
to
make
here-
you
just
have
to
take
my
word
for,
but
we
use
the
events
in
the
security
operation
life
cycle
as
the
processing
points
for
policy
and
across
the
top
of
this
life
cycle,
I
would
say
you
can
see
but
again
take
my
word
for
it.
The
life
cycle
is
driven
by
the
processing
role
of
the
bpa,
and
our
claim
is
that
this
life
cycle
is
finite
and
unchanging.
I
It's
capturing
all
the
success
and
failure,
events
that
could
occur
during
security
processing
with
failure
events,
including
the
identification
of
a
missing
misconfigured
or
corrupted
security
operation.
I
I
So,
as
promised,
some
discussion
points
to
sort
of
force
me
to
take
a
breath
here
and
solicit
comments.
I've
included
two
questions
about
the
completeness
of
the
security
operation.
Events,
which
might
be
great
points
to
take
offline
if
you're
interested
first
being
are
the
security
failures
that
I
have
listed
captured
sufficiently.
I
So
is
there
a
security
failure
that
does
not
fall
into
the
category
of
a
security
operation
being
classified
as
missing,
misconfigured
or
corrupted,
and
then,
on
the
other
hand,
are
there
events
in
the
successful
path
that
need
to
be
included
right
now?
The
way
that
we
identify
success
events
is
the
identification
of
two
different
events
at
the
processing
node.
I
So
there
is
the
identification
of
the
bpa
role,
so
those
would
be
events,
one
source
for
security
operation,
four
verifier
and
nine
acceptor
for
security
operation
and
then
a
second
event
occurs
to
show
the
success
at
that
node.
So
the
security
operation
is
added
at
the
source.
That's
number
two
in
this
list,
the
security
operation
is
verified
or
it's
processed
at
its
acceptor.
I
So
the
question
here
is:
is
that
level
of
granularity
in
those
events
sufficient
to
identify
to
identify
the
role
and
then
acknowledge
the
fact
that
the
security
processing
has
been
successful
at
that
node?
I
E
Your
processing
is
based
on
the
bundle
and
the
origin
destination,
it
is
a
correct
misconfigure
and
all
that
and
not
what
the
content
of
the
bundle
specifically,
for
example,
if
I
am
transferring
some
kind
of
instruction
and
xml
or
whatever
inside
the
bundle
bundle
inside
the
protocol,
you
are,
you
are
working
on
the
bundle
and
the
outside
of
the
bundle
to
save
that
way.
I
So
there
is
some
processing
of
the
the
bundle
contents.
The
representation
of
the
security
operation
within
the
bundle
would
be
the
security
block.
So
we
get
as
far
as
identifying
that
security
block
is
missing
or
its
intended
security
target
block
is
missing.
I
To
say
that
it's
misconfigured,
we
could
have
a
parameter
that
was
specified
incorrectly,
whether
it's
traveling
within
the
bundle
or
if
it's
specified
by
policy
at
the
processing
node.
So
there
are
there's
an
inspection
of
the
bundle
contents
that
contributes
to
the
life
cycle,
but
I
agree.
E
That
so,
the
bundle
could
have
some
kind
of
checksum
or
something
like
that.
That
would
be
identified.
Let
me
let
me
ask
you
about
my
concern.
Specifically:
I've
been
working
in
medical
records
for
many
years
and
and
been
working.
I
have
more
than
one
million
analysis.
A
clinical
test
transmitted.
E
One
of
the
of
the
situations
is
that
the
all
the
all
this
structure
of
of
a
clinical
test
should
be
complete
and
untrustful,
and
you
can
trust
that
in
the
other
end,
for
example,
in
the
case
of
a
space
medical
record
in
the
space
by
a
doctor,
that
is
it
on
earth,
or
so
your
points
are
very
very
interesting
for
me.
That's
why
I
am
asking
so
what?
What
is
the
level
of.
A
E
E
A
No
problem
carry
on
sir
okay.
I
Great,
so
if
there
are
other
comments
having
to
do
with
the
the
completeness
of
the
life
cycle
feel
free
to
take
it
to
the
mailing
list,
and
I
would
love
to
hear
any
other
comments
that
anyone
has
but
moving
on
to
the
next
slide,
so
I've
just
presented
13
different
events.
I
Obviously
there
are
many
configuration
options
for
security
policy
so
to
simplify
that
configuration
and
to
give
it
the
strength
of
supporting
some
sort
of
default
security
policy
configurations.
Our
security
policy
architecture
includes
the
concept
of
an
event
set
which
can
hold
multiple
security
operation
events
and
the
processing
actions
that
are
associated.
I
I
So
the
final
component
of
this
data
model
is
processing
actions
which
are
used
to
perform
the
actual
response
to
those
security
operation
events.
So
we
can
classify
processing
actions
as
falling
under
one
of
three
categories:
block
manipulation,
bundle,
manipulation
and
data
generation,
and
these
processing
actions
are
required
optional
or
prohibited
for
different
security
events.
I
This
is
another
chart
that
might
be
a
bit
difficult
to
parse,
but
what
I
want
to
call
out
here
is
the
abundance
of
optional
processing
actions.
So,
in
the
left
most
column,
the
13
security
operation.
Events
are
enumerated
down
the
side
and
the
processing
actions
are
in
the
row
across
the
top,
and
these
blank
boxes
show
a
prohibited
processing
action.
I
A
Sorry,
it
was
a
very
quick
clarifying
question.
You
said
on
the
previous
slide
and
because
I
have
control,
I
can
jump
back,
bundle,
manipulation
and
block
manipulation.
Can
you
just
clarify
what
you
mean
by
that
as
a
manipulation
of
the
processing
of
a
discard?
The
bundle
discard
ignore
the
block
or
actually
editing
the
bundle
in
flight.
As
sorry
question.
I
Yes,
so
perfect
question:
if
you
go
forward,
I
guess
two
slides.
I
Okay,
perfect,
so,
just
beyond
that
that
large
chart
are
the
definition
of
bundle,
manipulation,
processing
actions.
So
when
we
are
applying
a
bundle,
manipulation
processing
action,
we
are
either
modifying
bundle,
transmission
or
the
contents
of
the
bundle
itself
so
for
bundle
transmission.
I
I
I
I
So,
with
block
manipulation
actions,
we
are
changing
the
contents
or
the
processing
of
blocks
themselves,
so
we
can
do
that
by
modifying
or
temporarily
overriding
the
block,
processing
control
flags
which
can
impact
block
replication
status,
reporting
and
the
preservation
of
bundle
of
the
bundle
or
the
lock
that
we
are
changing
that
for
so
currently
we're
supporting
the
ability
to
override
the
security
target
blocks,
block
processing
control
flags
or
the
security
block,
representing
that
security
operation.
I
I
So
this
architecture
was
a
lot
to
ask
you
to
wrap
your
head
around
in
20
minutes.
So
I
want
to
highlight
the
initial
implementation
of
this
proposed
architecture
in
ion
apl,
added
this
initial
implementation
to
the
ion
402
release,
so
I'd
encourage
anyone
who's
interested
in
getting
a
feel
for
this
security
policy
architecture
to
download
the
latest
version
of
ion
to
give
that
a
try
and
then
on.
The
next
slide
is
additional
information
on
security
policy.
So
again,
look
at
that
implementation
in
ion.
I
There
is
a
youtube
video
showing
a
sample
configuration
of
security
policy
using
the
second
bin
tool
in
ion,
we've
included
a
user's
manual
and
then
we've
put
out
several
papers
and
talks
on
sec
policy.
So
if
it
is
something
that
you
are
interested
in,
getting
more
information
on
I'd
be
happy
to
send
any
of
that.
Your
way.
A
I
shall
pause
a
second
for
my
audio
to
kick
in.
Thank
you,
sarah.
This
is
fascinating
and,
yes,
you
did
answer
my
questions
earlier.
So
thank
you.
I
have
a
question
about
whether
the
policy
is
in
band
or
out
of
band.
A
I
We
we've
taken
a
look
at
taking
a
hybrid
approach
to
security
policy,
so
allowing
some
of
that
information
to
reside
locally
at
the
node
include
some
of
the
policy
information
as
parameters
for
the
security
block,
and
I
think
that
ultimately
taking
a
hybrid
approach
there
and
allowing
at
least
some
of
that
security
policy
configuration
to
travel
with
the
bundle
will
be
the
approach
that
we
need
to
take
here.
Supporting
somewhat
of
a
hybrid.
I
I
I
do
think
that
this
interacts
well
with
you
know
the
all
of
the
the
network
management
work
that
is
going
on,
and
I
think
that
some
of
the
metrics
that
this
security
policy
architecture
poses
tracking
would
be
useful
outside
of
just
the
realm
of
security.
So
I
definitely
agree
that
there
are
other
directions
that
we
can
take
this
hopefully.
A
Thank
you,
I'm
I'm
watching
the
time
oscar
I
see
you're
in
the
queue
can
I
ask
you
to
be
prompt
because.
E
We
were
chatting
with
that
about
interfacing
this
model,
with
the
testing
plan
that
we
we
have
been
developing
at
ipn6,
so
very
interesting.
Sarah.
Thank
you
very
much.
I
A
B
So
sarah,
that
was
tremendous.
Thank
you
so
much
my
my
my
final
question
on
this
is:
how
do
we
see
this
information
coming
forth
in
the
context
of
the
working
group?
Certainly
we
have
enumerated
actions
enumerated
policies,
enumerated
sort
of
structures
and
approaches
here.
Do
we
see
this
as
a
an
informational
rfc?
Do
we
see
this
as
a
normative
rfc?
B
Do
we
think
that
it
can
be
generalized
enough
that
it
is
the
foundation
for
implementations
that
can
be
separate
and
have
their
own
take
on
these?
I
would
just
ask
rick
for
you
or
just
the
working
group
in
general.
What
do
we
think
about
the
the
future
of
this
work
in
the
working
group.
A
A
So
if,
if
there
is
a
a
proposed
configuration
of
policy
mechanism
or
or
format
or
way,
this
is
transported
around
the
network?
Sort
of
why
I
was
asking
about
the
in-band
use
case
or
the
hybrid
solution
is
great,
then.
Yes,
I
can
see
that
being
something
that
the
ietf
could
standardize
the
counter
the
alternative
is
to
say
an
informational,
architectural
document,
a
bpsec
security
policy
architecture.
A
That's
we're
still
discussing
charter
items
and
have
we
got
feature
creep
but
yeah.
If
people
are
working
on
this
and
want
to
bring
it
to
the
ietf,
we
we
shouldn't
be
the
ones
to
say,
go
away
so.
C
You
just
say
that
I
have
the
the
same
feeling
that
if
there
were
an
element
of
this
that
re
required
a
specification
of
protocol
that
needed
to
be
tested
in
between
the
interoperable
implementations,
then
there's
then
doing
a
a
protocol.
Specification
would
be
a
straightforward
way
to
to
to
to
to
capture
this,
but
absent
that
I
I
think
an
informational
rfc
does
sound
like
the
best
idea
to
me.
A
Yeah,
I
did
so.
The
the
ietf
does
standardize
best
practice
documents
and
if
it
is
the
considered
opinion
of
the
working
group
that
this
sort
of
security
policy
framework
could
be
considered
best
practice
when
deploying
security
in
dtns,
then
that
would
be
something
that
we
would
obviously
would
be
in
scope
for
the
working
group.
A
So
anyway,
I'm
watching
the
clock
can
we
take
this
discussion
to
the
list.
B
I
promise
I'll
be
quiet
eventually
that
if
some
of
the
value
of
this
work
is
that
it's
standard
it
enumerates
in,
like
an
iana
registry,
you
know
certain
actions
and
policies
and
so
on.
Is
it
possible
to
have
an
informational
rfc
that
specifies
ayanna
registry
items,
because
I
think
that
would
be
sort
of
the
perfect
combination
for
this,
because
what's
standardizable
is
defining
these
particular
events
in
ways
that
everyone
can
agree
on
how
they
are
referenced?.
A
A
So
if
the
security
policy
mapped
to
an
adm,
then
the
document
describing
the
security
policy,
the
security
policy
events
and
registering
those
relevant
adm,
uri's
urns,
that
that
is
a
that
is
a
document
that
that
is
on
charter
and
appears
to
standardize
and
define
something.
A
No,
never
I'm
not
brilliant.
Don't
call
me
that
right.
Thank
you
very
much.
Sarah!
This
is
brilliant
and
I'm
trying
to
find
the
agenda
yeah.
Thank
you
very
much
for
that,
so
straight
on
to
asynchronous
management
architecture
as
as,
if
as
if
it
was
planned,
so
I
will
stop
sharing
that.
G
I
can
do
that.
It's
not
asking
me
which
screen
I
want
to
share
by
chance.
Do
y'all
see
anything.
We
see
you
hi
I've
clicked
the
screen
share.
Request
thing.
I
don't
know
if
someone
has
to.
G
There
we
go
try
that
do
you
want
to
share
your
screen?
Yes,
even
ask
which
screen
excellent
almost
like
zoom,
all
right,
we'll
switch
this
over
all
right.
You
should
have
a
full
screen
now
and
it
looks
good
yes
all
right,
so
howdy
y'all,
my
name
is
emory
annis
or
james.
G
If
you
want
to
be
boring,
I
suppose,
and
I'm
going
to
talk
to
you
a
little
bit
about
first,
the
asynchronous
network
management
architecture,
sort
of
what
is
that
vision
where
we
are
how
things
are
going
and
then
talk
to
you
a
little
bit
later
about
some
of
the
naming
that
y'all
were
just
teeing
up.
So
thank
you
for
that
one.
So
so.
A
Emery
before
you
get
too
carried
away,
we've
eaten
a
little
bit
into
your
time.
Well,
I
will
blame
sarah,
but
actually
it's
our
fault.
So
can
I
ask
you
to
be
prompt
simply
because
we're
we're
losing
time
anyway.
G
I'll
shut
up,
then
absolutely
can
be
done.
So
I
guess
one
of
the
first
things
I
kind
of
mentioned
here
is:
you
know,
look
this
concept
of
asynchronous
management
architecture,
the
the
different
pieces
that
we're
using,
including
adms
and
the
accent
coverage
management
protocol,
these
things
that
are
they're
actually
in
work
today,
they're
showing
up
in
both
commercial
industries
they're,
showing
up
in
both
sort
of
open
source
and
sort
of
playgrounds
between
different
universities
and
so
forth.
G
So
what
we're
really
trying
to
do
here
is
push
this
through
the
next
step.
Let's
get
the
different
components
standardized
and
then
let's
ask
the
community
all
of
us
is
it
correct?
Are
there
missing
pieces
and
so
forth?
So
with
that
said
just
to
kind
of
remind
everybody
if
you
aren't
familiar
what
what
is
the
asynchronous
management
architecture,
the
idea
being
that
for
delay,
tolerant
networks
right,
I
don't
have
necessarily
nodes
that
are
online,
which,
with
what
I
can
send,
commands
to
and
pull
information
from
right.
G
So
what
we're
really
trying
to
do
here
is
look
at
the
concept
of
can
I
pass
controls
to
my
agents,
the
things
that
I'm
trying
to
manage
on
the
network
from
the
managers
and
then
can
I
wait
asynchronously
for
them
to
send
me
reports
or
send
me
data
back.
So
that's
sort
of
the
high
level
view
of
what
is
the
asynchronous
management
architecture.
G
You
know
one
of
the
key
pieces
to
this
architecture.
Is
these
asynchronous
or
excuse
me
the
application
data
models?
This
is
what
sort
of
defines
the
controls,
the
reports
and
any
associated
parameters
or
information
that
are
going
to
and
from
the
managers
so
kind
of
where
we
are
today.
I
think
back
in
april
2021,
so
this
year
the
the
current
draft
form
of
the
asynchronous
management
architecture
went
through
the
working
group.
Last
call,
I
received
some
comments,
one
of
the
the
biggest
comments
on
that
was
hey.
G
It's
kind
of
written
today
as
a
network
management,
informational
spec,
but
could
it
be
for
more?
Could
it
do
you
know
applications
or
systems
themselves?
I
think
that's
very
true,
and
I
think
we
need
to
you
know,
ask
ourselves:
how
do
we
rewrite
the
document
or
what
modifications
do
we
need
to
make
to
allow
it
to
do
that?
My
my
opinion
on
this
is
definitely
that
you
know
amc
am
ama
should
be
generic.
Your
adms,
should,
you
know,
define
the
applications
or
the
things
that
you
want
to
manage.
G
Kind
of
like
you
were
talking
about
for
security
and
policy
and
amp.
The
the
protocol
should
define
the
functionality
between
those
agents
and
the
managers
and
expected
behavior
so
kind
of
a
very
high
level.
This
is
where
this
started
right.
I
think
it
was
a
very
space-centric
delay,
tolerant
networking
use
case,
but
we
have
come
a
long
way
and
I
kind
of
proposed
a
sort
of
you
know.
G
Straw
man
use
case
here
like
could
we
use
this
asynchronous
management
architecture
to
actually
manage
something
like
iot
in
a
smart
city
right
where
you
might
have
a
vehicle
that
needs
to
travel
around
and
send
commands
to
nodes
as
it
gets
within
proximity
to
those
nodes?
It
wants
to
collect
data
and
then
bring
that
back
and
sync
to
maybe
a
masternode
somewhere,
so
very
dtn
like
if
you
will
and
and
you've
kind
of
think
of
all
the
things
you
can
start
to
manage.
G
That
goes
well
beyond
the
network
right,
the
actual
applications
themselves,
the
systems,
the
system
behavior,
the
information
that
you
want
to
put
on
the
wire
the
security
parameters
for
those
so
very
much.
You
know
we
should
think
about
extending
ama
today
to
these
various
use
cases.
G
So
I
think
you
know
sort
of
my
my
my
my
ending
slide
for
talking
about
ama
is
you
know
these
are
some
of
the
things
that
I
think
we
need
to
do
as
we.
We
kind
of
push
this
coming
out
of
the
working
group.
Last
call.
Let's
make
sure
that
we
clarify
the
bounds
of
network
management.
There's
lots
of
talk
in
ama
today
about
autonomy.
So
let's
scope
that
function
of
alternating.
What
does
it
mean?
What
are
the?
What
are
sort
of
the
bounds
of
autonomy?
G
Going
back
to
that
particular
use
case
and
there's
there's
been
also
conversation
about
sort
of
consensus
or
federated
control
right,
which
requires
things
like
actor
to
actor
or
manager.
To
manage
your
communication,
I
think
we
should
talk
about
how
to
define
those
components
you
know.
Does
an
agent
actually
need
to
be
managed?
G
A
Been
pretty
quickly,
this
sounds
a
little
bit
to
me,
like
you
want
to
reopen
the
ama
document.
Take
it
out
of
working
group
last
call
and
revisit
it
to
say
this
is
more
than
network
management.
This
is,
as
is
in
the
title,
asynchronous
management
architecture.
It's
about
managing
things,
not
necessarily
performing
network
management.
B
Just
add
so
I
think
that
was
the
the
one
comment
that
came
out
from
the
mailing
list
in
in
reference
to
the
working
group.
B
Last
call
is
that
the
the
vast
majority
of
the
ama
document,
as
it
exists
now,
does
not
focus
on
network
management,
but
generally
application
management
with
the
idea
that
the
application
being
managed
is
an
application
responsible
for
configuring
and
controlling
the
network,
and
that,
if
there
are
a
couple
of
places
where
you
simply
remove
the
word
network,
then
that
that
is
a
relatively
small
change,
at
least
to
the
structure
of
the
ama
and
isn't
more
of
a
larger
change
to
the
structure
in
the
data
model.
A
Understood:
okay,
I'm
going
to
preempt
that
what
I
think
the
head's
question's
going
to
be-
and
the
answer
is
yes,
we
have
been
around
all
the
net
mod
and
netconf
and
future
network
nmrg
within
the
itf
trying
to
attract
them
with
this
work,
and
we
have
failed
to
garner
any
interest,
so
it
is
still
resident
in
dtn,
because
this
is
the
working
group
where
we
care
about
disruption
and
delay
in
transmission
and
an
end-to-end
round
trip
in
order
to
take
actions
on
your
devices
is
is
not
something
we
expect
to
exist,
but
otherwise
go
ahead.
H
It
seems
like
you
were
brilliant,
like
gazing
my
mind,
so
I
have
very
I
mean
you
just
said
what
I
wanted
to
say,
and
but
I
wanted
to
add
that
whenever
well,
I
kind
of
thought
like
if
you
want
to
look
into
more
application
aspects
of
application,
configuration
management
and
other
things
and
you're
going
to
be
on
go
beyond
this
dtn
network.
I
mean,
then
this
has
to
go
through
a
couple
of
more
things
right,
so
I
mean
that's.
That's
one
thing
that
we
should.
H
We
should
be
thinking
here
like
I
would
say.
H
Yeah,
so
my
my
thinking
is
like
well:
if
it
is
going
beyond
dtn,
then
definitely
we
need
to
think
about
where
visit
the
routes
again
and
ping
other
people,
because
if
you
go,
I
would
if
you
want
to
address
the
iot
use
cases
and
think
to
do
rg.
I
get
some
comments
from
them
or
something
like
that.
So
if
you
really
want
to
do
that,
this
has
to
go
a
couple
of
places
again.
B
So
well
agreed,
I
I
think,
when
we
say
outside
of
dtn
the
the
question
there
is,
what
we
mean
is
trying
to
understand
how
applications
are
behaving
across
a
dtn
and
that
still
seems
to
be
sort
of
a
very
niche
focus
and,
and
the
the
thought
was
that
other
areas
would
provide
review,
as
requested
similar
to
the
security
review
for
a
security
protocol
internal
to
dtn.
B
H
That
I
can
understand,
but
if
you
in
this
document,
try
to
open
up
this
more
general
asynchronous
management
for
iot
say
like.
If
you
want
to
address
the
iot
network
and
you
define
iot,
I
mean
the
definition
of
you
can
can
vary
right.
So
I
mean
then
we
need
to
really
cross
check
like
whether
we
are
doing
the
same
thing.
Is
there
any
other
solution
that
can
fit
here
or
we
are
providing
something
else
if
it
is
dtn?
H
I
completely
agree
with
your
comment
said
like
this
is
about
a
network
is
quite
different
from
others
and
has
a
value
of
its
own.
So
that's
what
my
I'm,
I'm
just
pointing
here.
I'm
pretty
sure
you
guys
are
well
out
of
what's
going
on
on
other
places.
Yes,.
A
So
I'll
go
back
to
my
original
question
about
working
group
last
call:
do
you
believe
emery
that
you
can
address
the
the
overuse
of
the
word
network
that
was
picked
up
on
the
list
and
and
to
make
it
a
little
bit
more
generic
and
and
clarify
a
couple
of
these
points?
A
G
I
am
I'm
here,
I'm
I'm
ready
to
help.
No,
I
think
it's
actually
very
close.
I
think
there's
just
a
final
read
to
make
sure
you
know.
Some
of
these
things
are
clear
with
regards
to
the
scope
of
what
it
should
manage.
I
think
that
is
a
very
simple
change.
I
think,
with
regards
to
the
sort
of
informational
ama,
something
like
is
it
clear
the
scope
of
how
a
manager
and
a
manager
should
talk
to
one
another.
G
A
You
do
your
revisions
and
we
will
reopen
the
last
call
and
we'll
make
it
nice
and
long
so
that
people
can
have
give
it
a
good
chew
over
just
to
make
sure
that
they
agree
that
you
haven't
made
enormous
normative
changes
to
the
to
the.
I
know
it's
an
inform,
informational,
our
informational
documents,
so
so
there's
not
really
normative
text,
but
we'll
ch,
we'll
let
other
people
double
check
that
you
haven't
radically
rewritten
it
at
the
last
minute
of
last
call
so
yeah.
No
thank
you
for
offering
to
do
the
work.
A
I
I
don't
mean
to
to
to
be
strict
about
this,
but
we
have
to
be
a
little
bit
careful
about
process,
but
thank
you
for
volunteering
to
to
get
this
through,
because
this
is
last
of
our
previous,
our
current
charter
items
that
we
need
to
get
done
so
conscious
of
time.
G
Possibly
let
me
see
this
is
the
one
right
here.
A
G
Urns
was
what
I
have
yep
naming
of
a
secret
center
models,
okay,
which
is
exactly
arai,
uris,
ari,
so
kind
of
kind
of
to
set
the
set
the
set
stage
for
this
one
up
front,
you've
heard
about
policy.
You
heard
me
just
talk
about
ama
and
so
forth.
G
You
heard
me
say
that
these
are
being
operationalized
one
of
the
key
pieces,
one
of
the
critical
pieces
to
really
you
know
making
this
work
in
that
operational
context,
is
the
ability
to
address
those
objects
in
the
network
being
able
to
address,
and
you
know
the
parameters
within
the
network
being
able
to
sort
of
have
an
idea
for
how,
like
I
just
mentioned,
there's
many
different
adms
that
might
apply
to
each
to
each
agent.
G
So
it's
very
important
that
we
have
a
way,
a
scheme
that
I
can
use
to
address
those
different
pieces.
So
talk
about
that
these
slides
are
a
bit
long,
so
I'm
going
to
roll
through
a
few
of
these
pretty
quick.
Then
we
can
kind
of
get
to
the
discussion
at
the
end
can
always
talk
offline
for
either
stuff
in
here
or
just
in
general.
How
should
we
do
this
so
kind
of
as
a
high
level?
Some
of
the
things
we
didn't
mention
so
far?
G
G
How
do
I
manage
a
sensor
versus
a
network
versus
you
know
a
the
actual,
maybe
structure
of
vp
v7
or
something
like
that:
the
actual
sort
of
encode,
not
the
encoding,
the
the
format
and
the
different
objects
and
object
types
within
that
and
there's
actually
the
sort
of
amp
encoding
today.
What's
interesting,
is
the
naming
and
addressing
for
these
different
objects
is
actually
defined
in
two
of
these
three
today.
G
G
One
of
the
things
that
I
wanted
to
say
here
is
kind
of
setting
the
stage
for
why.
This
is
why
this
is
definitely
important.
If
you
look
at
some
of
these
agents,
so
here's
spacecraft,
maybe
even
ground
stations,
are
agents,
they're,
gonna,
sort
of
subscribe
to
multiple
adms
each
right,
so
no
single
adm
is
gonna,
be
applied
to
a
single
agent,
there's,
probably
many,
depending
on
the
complexity
of
that
agent.
G
Some
of
the
content
of
the
adm,
as
defined
today,
so
there's
very
specific,
set
object
types,
so
you
know
your
literals
operators
controls
the
variables
formed
from
those
macros
reports
and
your
different
rules
that
you
want
to
apply
to
it
kind
of
coming
back
to
the
concept
of
dtn
one
of
the
big
pieces
here
is,
I
can't
you
know,
send
long
strings
of
data
right.
I
should
be
able
to
reference
very
clearly
a
piece
within
the
adm
and
the
most.
You
know
the
shortest
way
possible
to
to
reference
that.
G
I
want
to
change
this
variable
on
this
particular
agent,
so
I
need
a
way
to
name
that
and
address
it
so
kind
of
speaking
up
front.
It's
actually
stated
in
the
specs.
You
know
every
object
needs
to
be
uniquely
identifiable
and
by
the
way
we
recommend
that
you
use
the
ari,
which
is
actually
kind
of
a
formation
following
the
uri
schema
to
name
those
and
the
ari
is
written
in
the
spec
today
says
it's
composed
of
three
themes:
namespaces
objects,
names
and
parameters,
namespaces
the
most
formal
one
being
moderated
namespaces.
G
This
is
essentially
following
your
adms,
so
the
the
content
that
says
manage
this
bp
agent
manage
the
security
on
this
bp
agent,
a
very
structured
standardized,
set
of
content,
being
your
moderated
atms,
but
there's
others
right.
So
there's
informal.
This
might
be
your
vendor
or
mission
specific
configuration
right.
How
would
I
reference
those
as
part
of
my
dtn
environment
as
well
as
anonymous
namespaces
for
your
moderated
namespaces?
I
kind
of
took
a
snapshot
of
a
few
of
the
objects
within
the
current
adm
agent
draft.
G
That's
out
there,
you
can
see
here's
a
that
ari
formatted
with
those
three
things:
your
name
space,
your
object
name
and
your
parameter
here
in
the
metadata
of
that
adm.
It
explains:
okay,
here's
your
name
space.
So
this
is
what
that
would
look
like
here
is
a
you
know,
edd
on
that.
So
now
I
could
look
at
the
object
and
the
name
and
here's
a
control
which
is
parameterized
with,
in
fact
additional
ari,
so
a
set
of
aris.
G
So
this
kind
of
speaks
to
the
challenge
and
why
we
need
to
to
very
clearly
name
those
right.
So,
instead
of
so,
I
need
a
way
to
reference
those,
so
I
can
pass
those
in
and
even
further
one
step
further.
G
They
don't
say
how
it
should
be
done,
but
they
say
that
it
should
be
done
that
we
should
actually
have
a
registry
for
each
of
these.
So
I
think
the
question
for
this
conversation
is
all
right.
I
think
we
should
have
pulled
a
new.
We
should
create
a
new
rfc
for
these.
We
need
to
represent
both
the
namespaces
as
well
as
the
nicknames
for
each
of
these,
and
maybe
it
looks
like
something
like
this.
Maybe
you've
got
kind
of
going
back
to
that
picture
of
words
backwards.
G
Coming
back
to
that
picture
of
that
structure
of
my
name
spaces
and
so
forth,
maybe
I
have
this
top
a
being
an
iana
namespace.
Maybe
I
have
this
top
b
being
a
sauna
namespace
that
captures
those
different
adms
or
that
captures
maybe
even
the
dynamic
registration
of
vendor
specific
information
so
to
open
the
florida
discussion.
G
Here's
some
of
the
you
know,
question
is
moderation
of
namespaces
and
nicknames
possible
kind
of
as
described
the
need
is
this
possible
and
then,
if
it's
possible,
what's
the
approach
to
that
right?
How
do
we
handle
those
anonymous
and
informal
name
spaces?
G
How
do
I
manage
things
that
aren't
even
content
on
the
network,
but
maybe
are
aspects
of
a
protocol
like
the
pdus
and
bpv7
or
so
forth,
and
then
how
do
I
manage
that
dynamic
piece?
So
I
went
as
fast
as
I
possibly
could
and
probably
confused
everyone,
but
that
was
my
last
slide.
I
open
it
to
the
floor.
Questions
comments.
A
B
Emery,
so
I'll
jump
in
and
ask
sort
of
the
simple
question
of
if
we
wanted
to
register
a
uri
schema
is,
is
the
idea
then
that
we
would
produce
a
small
draft
that
says
this
is
how
the
newman
would
go
to
prove
that
and
then
put
a
schema
against
it.
A
Registering
registering
a
schema
is
reasonably
simple:
we
are
the
ietf
we
can.
We
can
write
a
specification
and
present
it
to
iana
and
and
that
that
should
be
fairly
simple.
Personally,
I
think
a
document
which
just
describes
a
uri
format
without
describing
its
use
seems
strange.
So
perhaps
the
adm
specification
should
include
section
three
uri
with
an
ayana
consideration
section
saying
we
wish
to
register
this
uri.
This
is
the
specification
that
describes
its
format
and
its
use.
A
A
Yeah,
I'm
I'm
watching
the
clock
oscar
you're
eating
into
your
own
presentation
time.
So,
yes,
this
is
an
interesting
discussion
to
take
to
take
to
the
list.
I
will
need
to
do
some
background
reading
on
uris
and
urns
again,
and
also
look
at
how
the
yang
netmod
netconf
guys
also
approach
this
problem,
because
they
they
have
names
for
the
various
parts
of
yang
data
models
that
are
uniquely
identifiable,
and
I
need
to
read
up
on
that
because
there
may
be
some
answers
in
there,
but
thank
you
very
much
emery.
A
That
again
was
was
deep
content
so
running
slowly
out
of
time.
Next
up
we
have
the
ipn
sig
pilot
working
group
who
wish
to
just
update
us
on
what
they
have
been
doing
in
terms
of
compliance
testing
and
other
things
go
ahead.
A
A
E
Better
okay,
well,
my
name
is
oscar
garcia.
I
am
the
group
of
the
ipsc
field
approaches
working
group.
Let
me
see
if
I
can
make
this
somewhat
bigger
well,
where
we've
been
working
with
the
the
working
group
in
several
topics
during
this
time.
The
last
time
that
you
were
updated
was
we
by
alberto
montiglia,
so
we
are
going
to
move
forward
in
several
several
topics
that
will
be
worked.
E
E
Let's
see
if
this
works
well,
we
have
been
working
in
several
issues
in
the
in
the
last
times
and
we
have
been
working
now
in
a
dtn
testing
plan.
E
The
background
of
that
we
started
on
september
last
september,
24
in
conversation
with
peter
surf
and
scott
about
testing
dtn,
and
we
developed
some
testing
and
the
designer
model
to
determining
endpoints
in
an
earth
environment
untested
by
the
transfer
between
cloud
servers
with
the
ion
software
with
the
utility
speaking
of
the
vehicle.
E
On
november
27
last
year
we
made
the
first
dtn
communication
between
cloud
servers
in
between
amazon
web
services
and
google
cloud
by
dr
larissa
suzuki
myself
and
with
the
help
of
victor
surf,
and
we
launched
the
pilot
working
group
last
this
year
on
february
1st
and
we
wrote
we
started-
writing
the
dtmp
cloud.
E
Connectivity,
testing
and
network
relay
rare
reliability
and
stability
plan
with
contributions
of
mint
surf
alberto
montear,
scott
burley,
like
jogerson,
some
classic
and
branny
bull
well
in
several
countries
around
the
world
in
february
last
february,
we
developed
by
the
part
of
this
group
is
fashion
corporation.
The
ttm
work
on
where
network
management
with
that
allow
the
processing
of
a
contact
branch
generator
now
automatically
we
make
testing
with
contact
routine
and
dx
is
not
implementation.
E
We
also
in
our
group,
the
group
of
sweden
that
is
working
in
the
arctic,
make
interoperability
test
between
nomad,
laura
dtm.
E
They
developed
an
app
that
works
in
mobile
and
it
is
also
connected
to
ion
etm
and
with
raspberry
p,
connecting
remotely
from
the
arctic
to
our
network.
So
this
was
developed
by
somographic
and
this
group
that
is
working
following
reindeers
in
the
in
the
middle
of
the
of
the
arctic.
E
Testing
was
made
with
a
satellite
that
the
is
the
ops
sat
that
was
controlled
by
dtn,
with
interoperability
with
ion
and
the
implementation
of
the
t3t
and
dtm
implementation,
and
this
connection
allowed
to
connect
between
earth
and
space
and
also
process
images
connecting
with
the
artificial
intelligence
software
of
google
by
dr
larissa
suzuki
alberto
matilla
and
the
group
of
d3tm
and
also
was
supported
by
scott
burleigh.
E
So
we
have
been
working
quite
a
lot
in
the
last
month
in
the
last
months,
and
now
we
are
also
launching
the
global
dtm
testing
plan,
with
the
motto
of
we
are
launching
in
this
meeting
with
the
motto
of
testy
interplanetary
internet
at
home.
Before
you
go
to
space.
E
What
what
was
the
idea
of
this
that
we
could
develop
a
software
that
was
of
easy
usage
by
personal
network
technical
that
could
be
installed
in
even
in
cloud
servers
or
personal
computers
that
allow
the
global
participation
and
awareness
about
dtm,
and
that
was
it
need
to
be
easy
to
configure
and
use
that
could
be
multi-point.
E
That
could
allow
a
interrupt
interoperability
and
compatibility
testing.
That
could
be
that
good
process
automatically
that
had
low
law,
power
and
connectivity
requirements
and
could
be
adaptable
to
different
implementations.
E
There's
a
windows
version
also
planned.
We
specifically
ronnie
bull,
modified
the
source,
ironfull
tools
in
nc
code.
We
generate
the
profit
processing
and
ph
php
and
mysql,
with
all
mariadb
and
reporting
and
graphics,
daily
and
monthly,
with
open
source
tools.
E
E
Where
the
development
team
has
been
myself
oscar,
garcia,
I've
been
35
years,
developing
and
deploying
application
dc
programming
was
developed
by
ronnie
bull,
who
has
been
for
30
years.
Working
is
a
phd
in
computer
science.
World
batch
programming.
You
can
see
there.
The
group
has
been
testing
facundo,
novika
and
danila.
E
The
development
time
was
supported
by
digital
health
information
network
and
utica
college.
It's
around
2
000
lines
of
coding.
It's
going
to
be
with
a
creative
common
license
in
the
end
user
products.
E
We
plan
to
distribute
this
with
the
ipnc
global
participation
that,
as
you
can
see,
is
700
plus
78,
something
members
around
the
world
in
in.
In
all
the
continents,.
E
This
is
a
concept
model
that
we
developed,
that
is
connecting
with
several
environments
in
different
in
different
areas
and
generating
from
our
central
server
or
servers,
because
we
are
setting
more
than
one
reports
and
information
about
bundles
lost,
well,
everything
every
information
that
could
be
generated
from
this,
the
implementation.
E
I
will
show
you
some
screens
about
this,
there's
a
back
office
system
that
we
have
developed
to
manage
all
all
this
system
we
also
developed.
This
is
the
the
the
client
menu
that
the
user
has
in
each
computer.
The
idea
was
that
for
an
end
user,
it
was
quite
complicated
to
test.
Is
this
kind
of
standard
bundles
that
what
we
they
we
basically
do?
Sending
and
receiving
bundles.
E
In
most
computers,
as
you
saw
before,
the
configuration
is
quite
simple.
You
set
up
all
all
the
different.
They
are
not
not
so
much,
not
so
much
parameters
that
need
to
be
updated,
and
then
the
system
starts.
Working
here
is
a
screen
of
the
working
system,
where
the
one
server
is
connected
to
all
the
other
servers
in
the
network
and
sending
our
receiving
bundles.
E
All
the
results
are
stored
in
very
simple
files
in
each
computer
and
then
upload
it
to
a
central
server
and
from
this
uploading
we
generate
the
information
and
all
this
process
can
be
set
up
in
the
in
the
in
the
crown
tab.
So
automatically
the
the
system
starts
working.
For
example,
our
servers
are
working
now,
all
the
time
you
start
them,
or
and
they'll
start
starting
the
information
processing
between
them
and
send
the
information.
E
Processing
each
one
of
the
participants
receive
an
email.
E
The
the
processing
is
produced
three
times
a
day
and
you
see
how
much,
how
many
bundles
have
been
received,
lost
and
all
that,
and
there
are
rapper
options
in
our
central
servers
that
you
can
see
what
what
server
received
or
lost
bundles,
for
example.
E
Here
are
some
examples
of
of
processing
and
reports
and
graphics
that
we
can
generate
for
this
information,
and
there
is
a
particular
structure
that.
J
I'll
be
pretty
brief
for
the
sake
of
time,
since
I
know
we're
getting
short
here,
so
what
I've
developed
at
utica
college,
with
the
help
of
students
and
going
forward,
I'm
really
going
to
try
to
get
more
student
interaction.
In
with
this,
we
have
a
node,
that's
connected
to
the
ipn
sig
pwg
network
here
called
helios,
which
is
these
are
all
ubuntu
20.04
systems.
J
This
is
acting
as
our
gateway
node
into
our
internal
network
here,
which
you
can
see,
has
a
basic
switch,
and
then
we
have
a
server
up
on
top
that's
acting
as
just
data
storage
for
all
of
the
nodes
that
are
in
that
internal
network,
you
can
look.
We
have
a
hpc
e-main
cluster
that
we're
standing
up
here
right
now.
The
first
node
here
is
running
ion
and
it's
connected
as
node
42
on
the
ipn.
Oh
go
back
to
the
thing
on
the
previous
slide
oscar.
J
If
you
could
please
yep,
and
then
we
have
the
multiple
nodes
on
the
other
end
that
are
all
e-main
servers
connected
into
cluster
now,
what
I've
done
is
all
these
servers
can
actually
be
on
the
physical
node
network,
so
their
nodes
internally,
that
we
run
up
in
emain,
are
all
virtualized
on
a
virtualized
network
that
I
can
bridge
in
or
not
to
the
internal
network.
So
next
slide,
please.
J
Again,
these
are
six
servers,
we're
doing
right
now,
ubuntu
2904,
one
of
them
is
acting
as
that
endpoint
server,
the
other
one
is
acting
as
shared
msns
storage.
We're
also
going
to
start
doing
some
network
and
systems
monitoring
where
we
can
actually
look
at
things
like
overhead
and
contact
roth
routing.
We
can
look
at
overhead
on
how
large
the
network's
growing
and
seeing
what
kind
of
statistics
we
can
gather
from
that
from
the
logs
next
slide.
Please.
J
So
each
email
cluster
node,
currently
we've
tested
is,
is
capable
of
launching
up
to
200
virtual
nodes,
and
you
can
see
in
that
chart
there.
Before
we
had
four
emails
listed
together,
we
could
go
higher
than
that.
It
really
didn't
push
the
load
average
much
on
those
systems
just
running
up
the
nodes,
as
is
with
ion
on
them
running.
If
we
were
to
actually
add
more
load
to
each
individual
node.
J
That
would
you
know,
cause
that
node
count
to
go
either
down
or
up
depending
on
what
the
load
is
on
each
individual
node.
These
servers
aren't
anything
great.
They
only
got
about
32
gigs
of
memory,
running
xeon
processors,
I'm
looking
to
upgrade
in
the
future.
J
J
If
you
will
inside
gatewaying
out
to
the
ipn
virtual
email,
nodes
can
be
arranged
in
clusters
and
regions,
and
I
know
scott
berlay
was
looking
at
some
of
this
to
start
testing
things
like
bundle
and
bundle
protocol
and
other
contact
graph,
routing
solutions,
and
there
was
a
few
other
bullets
there.
You
could
look
at
later
on
if
oscar
provides
a
slide
for
sake
of
time,
so
everything
else
here
we're
dealing
with
an
automated
framework
in
email,
called
the
python
etc.
J
It's
python3
based
allows
us
to
automate
node
configuration
setup
and
topology
doesn't
have
to
be
run
as
root.
Can
these
scripts
can
be
kicked
off
as
pseudo
with
pseudo
privileges,
so
we
can
actually
allow
registered
users
on
this
network
and
be
able
to
deploy
their
own
dtn
implementations
and
see
where
they
can
go
with
testing
on
it.
Automated
configure
startup
shutdown
of
applications
on
the
nodes
so
say
I
want
to
start
up.
100
knows
I
want
to
have
ion
running
and
each
node
is
going
to
have
some
sort
of
different
configuration
plus.
J
Maybe
I
have
some
other
processes
going
on
there
like
image,
processing
and
sending
all
that
stuff
can
be
configured
at
startup
with
the
ectce
framework,
and
then
we
can
also
automate
the
data
collection
process
at
the
end.
So
I
will
hand
it
back
over
to
oscar
to
finish
up.
There's
no
questions
on
that.
E
Finally,
the
idea
and
it's
operational
and
finish
mostly
finished
now,
the
the
they
didn't
dtm
test
implant
is
a
complete
system
with
registration
form
that
downloaded
the
software.
There
is
an
installation
manual,
a
user
manual
super
formal,
super
personal.
E
E
Finally,
of
course,
unlike
in
every
development,
there
is
a
to-do
list.
We
need
to
make
translation
of
the
end
user
to
different
languages,
incorporate
ddt
and
implementation.
E
We
have
been
working
with
basically
in
this
stage
of
the
software
with
dtm
with
ion,
I'm
sorry,
but
we
are
planning
to
set
up
a
d3tn
and
there
is
also
the
laura
dtm
and
several
others
that
are
around
admiral
testing
functionality,
because
we
now
we
are
sending
bundles
back
and
forth
and
not
much
more,
but
we
want
to
send
messages
and
generate
also
whether
the
statistic
like
delivery,
completion
amount
of
data
sent
the
statistics.
E
You
know
this
is
endless
once
you
start
doing
this
kind
of
obtaining
this
kind
of
information.
Well,
finally,
I
in
the
ipnc,
not
in
our
group
destructor
strategy
working
group,
launched
the
report
about
solar
system
internet.
E
I
was
also
chatting
with
scott
that
is
in
this
meeting
and
I
suggest
by
by
his
idea
as
well
that
this
can
be
a
topic
for
another
meeting.
That
escort,
and
perhaps
other
members
of
our
group
can
make
a
presentation,
a
more
detailed
presentation
about
this.
E
E
You
can
do
that
with
your
server
or
your
personal
computer
at
home.
That's
the
idea
that
we
are
moving
forward
in
this
dtnf
dtm
project.
Well,
finally,.
K
A
Oscar
and
and
really
interesting
to
hear
what
you
guys
are
doing
and
it
sounds
like
things.
People
might
well
be
interested
in,
so
we
have
three
minutes
remaining
for
what
we
had
on
the
agenda
as
general
q.
A
so.
If
there's
anything
anyone
wishes
to
bring
to
the
mic
comments,
things
we've
missed,
it
looks
like
brian
has
jumped
to
his
feet.
Brian
go
ahead.
L
Okay,
I
have
a
really
quick
status
update
on
the
acme
validation
document.
It
only
this.
G
L
Week
has
passed
through
the
ad
review
and
two
major
points
that
came
up
that
I'll
get
into
on
the
working
group.
Mailing
list
in
detail
are
related
to
uri
naming
of
the
dtn
scheme
and
the
issue
with
the
administrative
record
type
identifiers
and
the
iana
registry
that
is
probably
gonna
have
to
be
worked
out
in
detail.
L
The
exact
way
to
handle
it.
The
ad
is
not
really
comfortable
with
an
experimental
document,
updating
a
standards
track
document.
A
That's
that
fair
enough
yeah,
do
you
want
to
raise
it
on
the
list
and
we'll
we'll
try
and
chew
it
over
yeah.
G
A
We're
we're
so
short
on
time
with
it.
The
agenda
always
looks
empty
and
then
suddenly
we
find
we're
running
out
of
time.
The
other
thing
I
will
quickly
raise
with
my
personal
hat
on
I've,
noticed
in
the
next
session
today
there's
a
group
called
webpack
who
are
looking
at
bundling
http
requests
together
and
sending
them
to
a
server.
So
I
suggest
people
poke
their
nose
in
it's
session
two
today,
so
in
half
an
hour's
time,
I
have
only
just
spotted
them.
A
I
don't
know
what
they're
doing,
but
they
might
be
looking
for
a
transport
protocol
that
understands
how
to
move
bundles
around
so
that
could
be
of
interest
ed.
Do
you
have
anything
you
wish
to
add,
because
I
think
we're
pretty
much
done.
B
A
Yes,
thank
you
very
much,
I
think,
really
really
interesting
topics
from
all
sorts
of
people.
Let's
get
this
chartered
done
ed
and
I
will
work
with
as
ahead
to
just
get
it
signed
off
and
sealed,
and
then
we
can
charge
ahead
with
it
and
thank
you
all
for
attending.
Well,
I
had
one
of
the
great
thoughts,
but
it
obviously
wasn't
that
relevant
yeah.
Thank
you
very
much.
I
think
I
think
we're
done
so
I'll
see
you
at
the
next
one
I'll
speak
to
you
on
the
list.