►
From YouTube: IETF112-MANET-20211112-1600
Description
MANET meeting session at IETF112
2021/11/12 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
There's
a
high
probability
that
you
have
seen
the
model
before
this
week,
but
it's
still
important
so
so
pay
attention
to
it
and
we've
been
asked-
and
you
probably
also
heard
this
to
to
especially
point
out
the
code
of
context
and
the
anti-harassment
rules.
Don't
do
you
want
to
say
something
about
those.
A
A
A
A
A
A
A
A
Then
there's
there's
one
remaining
draft
in
the
working
group,
which
is
really
belongs
to
the
same
group
of
credit
based
flow
control,
extensions,
but
one
that
uses
the
82.1
q
header
as
a
as
a
distinguishing
factor
for
for
flows
instead
of
dhcp,
like
in
a
da
credit
for
some
unclear
reason.
This
one
has
gotten
behind
the
other
ones.
A
A
A
A
They
should
also
be
a
visual,
but
we
were
already
trying
to
take
care
of
that
while
we
were
trying
to
address
ratham
6472,
so
rick
came
up
with
some
words.
Overall
came
with
up
with
some
words,
and
so
did
I,
but
we
never
completely
resolved
it,
but
I
think
we
should.
We
should
just
try
harder,
because
it
should
be
possible
to
have
some
ambiguous
effects
there.
Really.
A
D
E
Go
ahead
thanks
ronald,
so
I
was
going
to
put
my
name
forward.
I
have
some
time
in
the
next
two
weeks
to
work
on
that
errata.
Just
in
a
very
quick
summary,
the
text
as
it
currently
stands
is
half
wrong
and
half
misleading
when
talking
about
replying
to
a
dis
to
the
multicast
discovery
packet.
The
not
only
is
the
response
ip
address
incorrect,
but
also
there's
no
mention
of
what
to
do
with
the
udp
port.
E
The
fix
should
be
very
simple:
it's
just
a
matter
of
wordsmithing
and
we
should
be
able
to
close
off
all
three
of
those
errata.
One
of
them,
I
think,
might
be
a
duplicate,
but
we
should
be
able
to
fix
it.
I'll
put
my
name
forwards.
I've
got
some
time
starting
from
tuesday
next
week,
to
certainly
work
on
that.
So
I'll
I'll
make
that
commitment.
F
F
F
We
need
something
that
will
actually
show
up
as
the
actual
text.
So
now
in
the
tools,
you
can
go,
look
at
the
the
router
which
will
actually
show
up
in
the
document
when
you
see
it
right.
So
if
we
want
that,
you
know,
that's
perfect
I'll.
Just
keep
this
open
until
we
agree
on
on
text
that
again,
when
you
go
see,
it
it'll
show
the
new
text
instead
of
of
the
old
one.
A
E
In
the
queue,
oh
just
a
very
quick
comment
from
me.
Interestingly,
all
the
implementations,
I've
seen
actually
do
it
right,
so
the
intention
is
obviously
fairly
obvious
to
a
developer,
who
reads
it?
Who
who
says?
Oh
well,
you
know,
obviously
you
mean
me
to
reply
here,
but
obviously
the
wording
has
to
be
right,
but
the
good
news
is.
I
don't
think
this
is
going
to
break
loads
of
implementations
from
the
ones
I've
seen
anyway.
E
A
A
Instead
of
having
the
modem
provide
a
single
value
for
general
utilization
and
he
has
argued
that
there
is
benefit
of
having
the
raw
parameters
provided
to
the
router,
I'm
not
fully
convinced,
but
this
is
a
discussion
that
we
really
should
continue
on
the
mailing
list.
Then
I
I
should
have
done
that,
but
having
said
that,
it
shouldn't
be
only
my
opinion,
so
if
other
people
can
contribute
there,
that
would
be
would
be
highly
appreciated.
A
A
F
B
A
A
B
A
A
One
of
those
is
multicast
and
the
the
plan
to
produce
a
multicast
forwarding
information
base
and
rick
taylor
came
to
the
microphone.
I
said
yes
well,
there
are
a
lot
of
vendor-specific
proprietary,
multi-cut
solutions
in
manage
out
there,
and
maybe
there's
really
nothing
to
do
anymore
for
the
money
working
group.
A
C
G
Go
through
the
detail,
I
thought
you're
just
going
to
flip
to
the
next
slide,
so
on
the
routing
overlay.
I
think
there
might
be
some
interesting
overlap
with
the
raw
working
group,
because,
if
you
have,
I
mean
they're
they're
focused
on
the
deterministic
service,
but
they
have
to
solve
the
same
routing
overlay
where,
if
you
have
multiple
radio
networks
and
you
want
to
provide
deterministic
service
across
them,
I
think
you
have
to
start
first
solve
this
routing
overlay
problem.
G
Writing
up
something
about
that
or
yeah
there's
an
architecture
document
on
it.
The
I
think
the
architecture
document
has
a
lot
of
room
for
improvements.
There's
some
discussion
about
starting
up,
weekly
or
semi-weekly
calls
on
the
architecture.
So
if
I
stay
tuned
to
the
list
for
that
list,
the
raw
working
group
list
probably
good
to
join
in
there
into
that
discussion.
G
A
B
E
E
The
federation
of
heterogeneous
radio
networks
is
very
much
part
of
what
we're
trying
to
handle
in
raw
looking
at
the
from
a
deterministic
perspective,
but
I
think
there's
applicability
to
man
a
and
we
are
really
trying
to
increase
the
the
round
trip
time
in
terms
of
generating
the
documents
for
the
for
the
core
frameworks
and
architectures.
So
we're
trying
to
hold
some
some
semi-formal
interims
to
really
try
and
make
progress.
So
I
suggest
people
add
comments
to
the
raw
list
as
well.
H
Go
ahead,
please,
regarding
the
over
the
throating
of
relieving
role.
Usually
they
have
different
use
case
than
many.
So
it's
it's
interesting
to
check
to
see
if
it's
applicable
this
their
solution
to
our
our
scenario
is
the
same,
so
it
will
be
because
actually,
as
you
said,
in
heterogeneous
networking
or
in
the
disaster,
we
have
the
the
royal
nodes
and
also
the
many
moving
around
so
both
of
them
are
are
important.
To
have
this.
H
B
D
D
I
There
are
an
awful
lot
of
slides
in
this
particular
slide
deck.
This
was
a
larger
presentation.
What
I,
what
I
would
like
to
do
is
try
and
go
over
roughly
the
first
10
to
12
of
those
to
talk
about
the
problem
at
large
and
then
for
those
who
are
interested.
The
material
is
posted
in
in
terms
of
a
backup,
material
and
additional
information,
and
I,
of
course,
would
be
more
than
happy
to
talk
at
length
about
this
with
anyone
who
is
is
interested.
I
We
started
looking
at
this
problem
really
quite
a
long
time
ago
we
did
some
early
publication
and
and
research
associated
with
what
makes
managing
dtn's
different.
We
looked
at
just
generally.
What
are
the
components
of
a
management
architecture?
We
looked
at
whether
delays
versus
disruptions
were
the
driving
features.
I
We
tried
to
understand
what
sort
of
infrastructure
infrastructure
information
was
helpful
and
what
we
drove
to
was
the
the
concept
of
end-to-end
closed-loop
control
over
systems
in
a
delayed
and
disrupted
environment
is
not
going
to
get
us
what
we
need
and-
and
that
maybe
seems
like
an
obvious
observation
to
make
now.
But
at
the
time
there
was
a
lot
of
energy
going
into
trying
to
make
networks
not
be
disrupted
in
the
first
place
so
that
you
didn't
have
to
deal
with
that
problem.
I
If
we
accept
that
we
needed
more
open
loop
control
and
if
we
accepted
that
we
had
to
have
local
autonomy
and
sort
of
a
local
management
function
separate
from
a
remote
management
function,
then
it
changed
the
tech
transfer
opportunities
and
it
changed.
Where
we
looked
for
solutions.
So
then
we
started
looking
at
autonomous
fault
protection
schemes,
mobile
code
scripting.
We
looked
a
lot
at
spacecraft
because
they
were
dealing
with
this
problem
sooner
than
others,
and
we
originally
put
this
together
as
something
called
the
delay
tolerant
network
management
protocol.
I
It
was
a
product
of
the
research
group.
It
was
a
utility
also
being
looked
at
and
implemented
by
nasa
when
it
moved
into
the
dtm
working
group.
It
was
returned
asynchronous
management
to
refer
to
the
asynchronous
nature
of
of
the
transport,
not
necessarily
the
asynchronous
nature
of
the
the
management
applications
themselves.
I
When
we
started
looking
at
this
in
terms
of
synchronous
versus
asynchronous,
particularly
from
a
transport
perspective,
we
looked
at
some
of
the
obvious
things
at
the
time.
Simple
network
management
protocol
netconf
there
was
an
armand
mib
at
the
time,
and
those
are
things
that
we
know
are
pull
based
and
session
based
and
don't
work
in
the
kinds
of
transport
environments
where
we
would
otherwise,
you
know
see
bundle
protocol,
you
know,
bundle
protocol
version
six
at
the
time
in
version
seven
now
being
deployed.
I
But
the
observation
here
is
that-
and
this
is
the
work
being
undertaken
in
the
dtn
working
group-
is
that
there
are
new
capabilities
coming
out
of
the
ops
area.
Rest
comp,
updates
to
yang
yang
push
and
and
and
more,
and
these
have
added
a
kind
of
a
synchronous
operation
where
applications
can
agents
can
choose
to
more
intelligently
push
data,
but
it
still
doesn't
solve
for
us
the
fundamental
asynchronousness
of
the
underlying
transport
protocol
and
how
that
drives
us
to
more
autonomy
on
the
local
node
other
than
only
filtering
autonomy.
I
So
if
we
go
to
the
next
slide,
so
if
we,
if
we
zoom
all
the
way
back
and
say
what
does
this
look
like
in
a
very,
very
scaled
environment,
this
is
perhaps
an
extreme
manet,
where
we
would
say
that
we
could
have
ground
entry
points
separate
from
space
based
relay
separate
from
landers.
We
really
like
talking
about
these
particular
problems
using
these
kinds
of
examples,
partly
because
these
are
real
world
problems
or
perhaps
real
off-world
problems
that
we're
dealing
with
now.
I
So
with
that
and
using
spacecraft
as
the
as
the
sort
of
driving
example
and
understanding
that
we
wanted
to
look
more
into
autonomy
and
what
was
typically
a
fault
protection
autonomy.
We
we
did
exactly
that.
We
looked
at
spacecraft,
fault
management
systems,
they
tend
to
be
stimulus,
response
systems
focused
on
heritage,
implementations
and,
of
course,
because
of
the
resource-constrained
nature
of
the
compute
environment.
I
They
compress
that,
because
even
the
processing
capability
is
not
always
there,
so
spacecraft
are
not
looking
at
processing.
You
know
xml
or
large
amounts
of
xml
data
as
an
example
far
closer
to
iot
than
in
a
very
resourced
data
center.
And
ultimately,
we
tried
to
answer
the
question
if
we
put
these
two
worlds
together,
what
does
that
overlap
look
like,
and
is
that
a
new
management
capability
for
us?
So
if
we
then
go
to
the
next
slide?
I
The
first
was
to
take
that
original
delay,
tolerant
network
management,
protocol
dtnmp
and
break
it
as
renamed
asynchronous
management,
and
soon
to
be
renamed
again
in
the
dtn
working
group,
and
we
wanted
to
break
it
into
three
different
statements.
The
first
at
the
time
was
aspirational.
What
we
would
call
sort
of
a
manifesto
of
the
needs
of
a
very
challenged
environment
that
was
written
down
and
adopted
by
the
dtn
working
group
as
the
asynchronous
management
architecture,
and
there
is
a
reference
to
that.
I
The
ama-03,
that
is
a
working
group
item,
it
is
being
refreshed,
it
is
being
renamed.
I
believe,
the
delay
tolerant
network
management
architecture
to
really
focus
on
the
fact
that
we
can't
just
call
this
asynchronous
because
asynchronous
doesn't
capture
the
full
richness
of
needed
autonomy
and
functioning
in
these
allocronic
situat
environments,
where
things
just
don't
exist
in
the
network
all
at
once,
and
we
have
a
very
challenged
experience.
I
But
aspirationally.
There
needs
to
be
that
problem
statement
and
that
overall
architecture
separate
from
that
the
data
model
becomes
very,
very
important
because
the
data
model
between
a
local
agent
and
a
local
management
function
separate
from
the
relationship
between
a
local
management
function
and
a
remote
manager.
Perhaps
in
a
more
resourced
part
of
the
network,
we
need
to
have
a
better
and
more
reliable
way
of
talking
about
the
autonomy
and
the
expression
of
behavior
on
the
far
side
of
the
delay
and
the
far
side
of
the
disruption.
I
And
so
we,
we
term
that
the
asynchronous
management
architecture
management
model,
as
expressed
in
the
asynchronous
management
architecture,
application
data
model
or
adm
and
and
this
sort
of
advisory
model
allows
us
to
build,
managed
objects
and,
and
the
graphic
to
the
right
shows
what
a
few
of
those
are
externally
defined.
Data
literals
operators,
controls
like
remote
procedure,
calls
almost
and
table
data
and
custom
reports
and
variables
and
so
on
to
us
this
is
an
ecosystem
in
some
ways.
I
The
information
here
includes
some
things
that
we
don't
see
in
traditional
management
models
and
it
explicitly
prevents
or
excludes
other
things
that
we
sometimes
see
in
traditional
management
models,
and
this
was
sort
of
the
output
of
our
system
engineering
around.
What
we
think
is
important
in
this
space
and
then,
finally-
and
perhaps
even
most
simply,
there
was
the
to
be
able
to
encode
these
models
very,
very,
very
compactly,
using
seaboard,
but
also
structuring
the
messages
and
the
model
to
entice
a
more
compact
encoding.
I
So
in
the
amp,
the
asynchronous
management
protocol
we
could
using
the
dtn
ion
reference.
Implementation
say,
please
add
a
contact
into
a
contact
graph,
and
this
is
the
nature
of
the
contact
and
it
is
strongly
typed,
and
this
is
when
it
starts
and
tops,
and
data
rates
and
the
node
that
it
starts
from
in
the
node
that
it
goes
to
the
entire
command
to
accomplish
that
is
about
26,
bytes
and
so
being
able
to
get.
I
Those
very
very,
very
compressed
encodings
is
is
important
to
us
for
a
variety
of
reasons,
and-
and
one
of
those
of
course
is
from
an
atomic
transaction
nature.
You
want,
as
many
management
commands
and
controls
to
be
together
in
a
payload
at
once,
but
the
other
isn't
a
challenge.
Network
bandwidth
can
sometimes
be
at
a
premium,
and
you
don't
want
to
take
a
thousand
bytes
to
take
to
to
communicate
something
that
otherwise
you
could
send
in
26
bytes.
I
We
have
also
had
people
look
at
at
this
set
of
ama,
adm
and
amp
and
and
the
data
model
associated
with
it
and
want
to
run
it
between
micro
controllers
between
systems,
because
even
their
the
efficiency
and
the
the
smallness
of
the
data
sizes
are
motivating
as
well.
So
very
very
compact
is
important
to
us
as
well.
I
So
then,
if
we
go
just
one
more
at
currently,
there
are
some
internet
drafts.
There
are
personal
drafts
and
then
there
are
working
group
adopted
drafts
associated
with
some
of
this
for
the
protocols
that
are
of
interest
right
now
to
the
delay,
tolerant,
networking
working
group,
such
as
the
application
data
models,
think
the
moral
equivalent
of
yang
models
or
mibs
and
snmp.
I
We
have
those
for
an
ama
agent
itself.
We
have
it
for
the
bundle
protocol,
the
bona
protocol
security
protocol
ltp
for
ion
nasa's
reference
implementation
of
some
of
the
dtn
technologies,
and
then
we
are
also
working
to
to
define
additionally
other
encodings
and
to
bring
in
and
understand
how
we
interact
better.
With
yang,
we
looked
at
building
our
adms,
our
application
data
models
using
and
specifying
them
in
yang,
but
at
the
time
we
were
not
able
to
specify
quite
everything
we
needed
to
and
now
that
we
have
yang
1.1.
I
I
The
next
slide
just
has
a
couple
of
forward
link
references
and
then
I
was
going
to
stop
here.
There
are
a
couple
of
additional
slides
in
terms
of
what
we
think
are
important
as
part
of
that
overall
network
management
architecture,
but
in
the
interest
of
time
I
just
wanted
to
pause
and
see
if
there
were
any
questions
about
what
we've
covered
so
far.
I
If,
if
we
poke
a
little
more
into
what
we
think
are
important
architectural
components,
the
we
have
laid
things
out
in
our
initial
architecture
document
in
terms
of
service
definitions
and
desirable
properties
of
the
system.
From
a
service
definition
standpoint,
we
have
to
define
management
for
us
as
more
than
the
generation
and
communication
of
performance
monitoring
data.
The-
and
this
goes
back
to
the
observation
that
closed
loop
control
end
to
end
is
just
not
going
to
work
in
the
kind
of
environments
that
we
operate
in.
I
We
need
local
agents
to
be
able
to
change
their
own
configuration
as
as
we
respond
to
local
events
without
a
remote
manager
in
the
loop.
We
obviously
need
to
be
able
to
generate
reports,
but
we
want
to
be
able
to
generate
reports
either
as
a
function
of
time
or
a
function
of
local
state,
and
we
may
generate
reports
even
if
we're
not
sure
that
someone
is
listening.
I
You
know
reconstruct
what
happened
on
the
spacecraft
while
you
weren't
checking
in,
and
we
think
that
any
sort
of
network
management
system
needs
to
be
able
to
operate
in
that
way.
The
difference,
of
course,
is
that,
if
you
put
that
together
with
autonomous
parameterized
control,
you
don't
want
to
simply
generate
performance
report
data
and
cache
it
on
the
managed
node
until
it
could
be
sent
back
to
someone
at
a
future
time.
I
In
terms
of
what
you
would
implement
in
a
in
a
secure
or
operational,
or
otherwise,
you
know
far
away
system.
The
first
obviously,
is
that
the
intelligent
push
of
information
is
required.
Here
we
cannot
simply
ask
we
cannot
respond
to
pull
requests
from
information.
We
need
to
determine
what
we
need
on
the
platform
itself.
We
know
that
now
minimizing
message.
Size
is
very,
very
big
for
us,
and
I
mentioned
this
on
the
prior
slide.
I
When
we
talk
about
absolute
data,
identification
is
part
of
a
network
management
system
that
we
can
unambiguously
reference
data
and,
of
course,
we
can
do
that
in
all
of
our
network
management
systems.
However,
if
you
combine
absolute
data
identification
with
minimized
message
size,
then
the
construction
of
that
naming
scheme,
the
uris,
the
hierarchical
nature
of
the
naming,
trees,
the
ability
to
truncate
and
assign
nicknames
or
encodings
or
enumerations
of
of
portions
and
nodes
within
a
naming
tree.
I
I
That
kind
of
globular
naming
and
reasoning
about
things,
custom
data
identification
was
also
important
to
us
and
the
idea
that
you
need
it
in
the
context
of
a
mission
or
an
operational
deployment
to
be
able
to
build
custom
reports,
custom
variables,
custom,
other
bits
of
reporting,
rules,
time-based
rule,
state-based
rules,
and
you
need
to
be
able
to
name
those
as
well
and
those
don't
necessarily
have
to
be
globally
unique
if
they
exist
within,
like
a
particular
operator's
name
space
and
then.
Lastly,
of
course,
is
the
autonomous
operation.
I
I
As
long
as
that,
configuration
can
then
include
the
the
behaviors
that
need
to
be
autonomously
managed
until
the
next
time
you
get
an
opportunity
for
more
configuration
coming
back
next
slide
and
then
sort
of.
Lastly,
in
some
of
the
initial
prototyping
work
that
we
had
done,
the
application
data
model
to
this
autonomy
model
is
something
that
we
model
in
json.
We
have
also
modeled
to
the
extent
that
yang
at
the
time,
could
support
some
of
the
expressions
that
we
needed.
I
We
also
managed
or
modeled
these
in
json,
and
then,
if
we
go
one
more
slide,
this
becomes
the
autonomy
model
again
that
that
we
model
in
json
and
in
cbor
on
the
wire
and
or
past.
That
is
just
sort
of
an
example
of
what
that
encoding
might
look
like
in
in
json
for
the
bundle
protocol
and
it
it
sort
of
speaks
to
if
we
go
one
more
slide.
I
But
this
unsigned
integer
data
value
can
take
a
parameter
and
the
parameter
is
a
mask
of
the
kind
of
information
that
you
would
like.
And
so
this
idea,
there's
some
syntactic
sugar
built
into
our
model
to
allow
us
to
do
associative
lookups
almost
like
function
calls
with
the
with
generation
of
even
simple
data
types.
To
avoid
having
to
say
things
like
what
kind
of
information
do
you
have
or
how
would
you
map
that
information,
and
then
once
we
get
it
back,
then
making
a
second
call
to
down
select
within
that
set
of
information.
I
I
Encoding
separate
from
will
will
eventually
also
be
transport
encodings,
and
the
model
has
focused
on
trying
to
enable
very
deterministic
autonomy
without
requiring
building
scripting
languages
and
mobile
code,
because
sometimes
there
are
obviously
security
issues
around
deploying
that,
particularly
in
resource
constraint
systems
that
you
don't
check
up
on.
Quite
so
often.
So
if
anyone
is
more
interested
in
the
details
of
this
work,
I
would
be
happy
to
answer
questions
here
or
talk
to
people
offline
as
we
go.
A
People
need
to
know
that
I
only
asked
to
do
this
a
couple
of
days
ago
and
he
stepped
up
and
agreed
to
do
it.
So
a
big
thank
you,
and
I
think
that
this
is
this
could
be
relevant
to
to
manage.
Also
because
with
our
protocols
we
try
to
keep
the
network
connected,
but
some
somehow
the
laws
of
physics
get
in
the
way
sometimes,
and
if
the
distance
is
too
great
for
your
radio
range
or
or
there
are
obstacles
or
or
there's
jamming
or
whatever,
then
yeah
you
were.
C
I
I
There
are
times
when
our
processor
is
just
literally
turned
off
and
another
say
a
managing
processor
is
turned
off
and
then
turns
back
on
again
and
wouldn't
it
be
nice
to
be
able
to
have
these
communications-
and
you
know
that's
all
on
a
single
embedded
platform,
so
we're
not
quite
talking
about
delays
and
disruptions
in
that
particular
way.
But
the
other
is,
if
you
want
a
synchronous
behavior
without
requiring
tls
sessions,
for
example.
A
And
with
that,
I
think
we're
out
of
time.
There's
one
other
thing
that
I
forgot
to
mention
at
the
beginning
of
the
meeting.
Is
that
overall
made
me
aware
of
a
presentation
yesterday
that
I
missed
on
low
earth,
orbiting
satellites
and
the
potential
routing
problems
erotic
problems
that
they
may
have
in
those
networks,
and
unfortunately
I
did
not
have
the
time
to
work
through
the
the
draft
that
was
produced
there
and
presented,
but
I
I'm
going
to
be
in
contact.