►
From YouTube: IETF115-MANET-20221110-1530
Description
MANET meeting session at IETF115
2022/11/10 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
A
But
it's
one
of
the
questions
on
the
on
the
shepherd
write-up
template
and
then
I
understand
that
there's
a
new
thing
that
drafts
in
the
rooting
area
routing
area
also
have
to
go
through
a
routing
area,
review,
early
review
and
a
question
to
our
ads.
If
that
also
applies
to
these
drafts
that
have
been
around
for
some
time,
I'm
not
against
it,
but.
B
Yes,
of
course,
it
applies
to
everything.
Okay,
so
we've
been
just
so
that
everyone
knows
where
this
is
coming
from.
We've
been
talking
to
our
chairs
about
how
to
improve
the
overall
quality
of
the
documents,
and
so
we've
asked
everyone
all
the
chairs
and
all
the
working
groups
to
do
a
routing
director
of
review
before
requesting
publication.
You
can
do
that
at
working
group
last
call
or
around
that
you
know.
B
The
important
thing
is
that
there's
one
before
and
the
other
thing
that
we
asked
already
is
obviously
not
for
these
ones
that
have
been
around
for
a
long
time
but
early
assignment
of
Shepherds,
so
that
you
know
we
have
someone
sort
of
following
the
document
and
looking
at
the
issues
and
whatever
before.
As
the
document
advances
thanks.
A
C
A
So
one
thing
that
has
almost
been
discussed
to
death
in
the
working
group
is
better
or
not
to
merge
some
of
these
documents,
and
this
was
last
discussed
in
the
March
meeting
in
Vienna,
and
the
working
group
decided.
No,
even
though
the
the
transport
area
reviewer
made
a
strong
suggestion
that
we
we
should
merge,
several
of
them
or
two
of
them
with
the
working
group's
decision
was
not
to
do
it,
and
he
said
it's
fine
record.
This
decision
in
the
shepherd's
write-up,
which
I
will
do.
A
A
D
E
E
C
C
C
C
Now,
if
you
want
to
reduce
the
number
of
documents
you
can
put
this
in
one.
If
you
want
to
reduce
the
number
of
documents
we
can
rearrange.
So
the
top
two
are
together,
that's
easy,
but
if
we
think
about
why
we
have
different
documents,
it
was
flow
control
and
traffic
classification
or
two
fundamental
building
blocks.
So
we
had
those
in
two
different
documents
and
then
we
wanted
to
allow
for
conformance
based
on
rnrfc.
C
So
those
are
the
reason
we
have
two
different
bottom
documents
is
so
that
if
you
quoted
an
RFC,
you
knew
what
you
were
getting
so
the
tops
were
building
block.
The
bottom
were
conformance.
We
can
do
this
in
one
document.
We
can
do
it
in
four.
We
can
do
it
six.
We
can
do
it
in
three.
Let's
just
decide
move
on.
E
Because
I
had
conflated
the
diffserv
traffic
classification
and
the
flow
credits
all
as
one
thing,
and
that
was
a
mistake,
so
I
retract,
my
previous
statement.
There
is
and
always
have
been
use
cases
where
being
able
to
describe
a
flow,
but
not
necessarily
because
you
can
want
to
do
crediting
with
it
is
a
useful
property
having
standard
ways
of
describing
common
flow
types,
and
you
use
the
example
of
a
five
Tuple,
six
double
or
something
as
a
flow
type
that
you
might
want
to.
E
C
C
A
C
C
C
A
A
Some
of
them
were
addressed,
although,
but
there
was
no
real
expression
of
support
or
or
non-support
of
these
trusts.
What
I
propose
to
do
and
what
Dom
already
suggested
back
in
March
is
to
do
a
adoption
call
for
each
of
these
three
individual
adopting
calls
quickly
and
then
I
I
do
hope
to
to
get
some
replies
and
keep
in
mind
that
these
are
only
adoption
calls
it's
only
for
the
working
group
to
say
we
find
this
interesting
and
we
start
working
on
them.
A
A
These
are
only
a
few
of
my
takeaways
if
other
people
have
come
away
from
that
meeting
with
different
conclusions
or
so
then
feel
free
to
to
go
to
the
mic
and
and
say
something
about
that.
There
seemed
to
be
some
confusion
about
the
packet
detection
by
the
the
non-money
participants,
who
thought
that
we
were
just.
A
Throwing
away
a
package
even
if
they
were
genuine,
generally
identical
packets
from
from
the
same
Source.
This
is
not
the
case.
There's
always
something
around
these
packets
that
is
used
as
a
Criterion
for
detection
and
the
experimental
SMF
RC
6621
in
section
6
describes
how
it
works
so,
for
instance,
for
IPv6
you
can
use
a
an
extension
header
to
distinguish
package
from
each
other
and
only
if
it's
a
duplicate
that
is
the
result
of
the
same
packet
arriving.
At
the
same
note
again
after
being
retransmitted
several
times.
Perhaps
then
it's
discarded.
A
One
Parker
has
begun
work
on
a
document
on
use
cases
and
and
GAP
analysis
and
the
sort
of
problem
statement
around
the
use
of
beer
over
layer,
2
multicast,
it's
it's
in
a
very
early
stage.
He
did
not
want
to
present
as
yet
but
go
read
it
and
a
comment.
If
you
can
I
haven't
really
asked
him
whether
he
wanted
the
discussion
to
take
place
on
the
Monet
list
or
on
the
BLS,
but
I
will,
and
he
is
in
the
in
the
session
at
this
moment
remotely.
A
Another
point
that
was
made
by
Lou
and
Rick
I
think
is
that,
with
respect
to
North
Coast,
we
should
look
further
than
the
minute
alone,
but
also
take
into
consideration
the
money
in
its
is
in
this
environment,
with
possible
one
or
multiple
gateways
to
the
outside
world
to
infrastructure-based
Networks
and
see
how
we
can
handle
that
and
I
think.
That's
that's
a
fair
point
and
It's
relatively
easy.
A
I
think
if
you
have
only
one
Gateway,
but
if
you
have
multiple
gateways,
there's
always
the
risk
that
multicast
packets
that
leave
your
money
through
one
Gateway
come
back
via
another
Gateway
and
that's
something
that
you
would
want
to
prevent.
So
these
are
techniques
that
we
could
potentially
work
on
under
the
flag
of
a
new
Charter.
B
So
right,
of
course,
I
was
right.
I
was
just
saying
because-
and
you
had
that
last
item
there-
that
maybe
there
might
be
a
charter
item
for
this
working
group
now
that
interaction,
of
course,
with
the
rest
of
the
world
yeah,
you
know
it's
sort
of
obvious
in
a
ripple
Network
or
a
bevel
Network
or
whatever.
So
there
might
be
some
common
things
there
can
I
give
you
guys
the
action
to
go
check
with
the
other
chairs
and
see.
A
A
F
F
So
in
this
presentation,
I
want
to
cover
some
of
the
highlights
of
the
DT
anime
I'm,
definitely
not
going
to
try
to
cover
the
entire
document,
but
it
is
posted
online
version.
Three
is
the
most
up-to-date.
If
you
want
to
look
at
that,
but
we'll
be
talking
through
the
problem
space
and
some
considerations
that
we
had
from
existing
Network
management
protocols
and
then
talk
through
the
reference
and
autonomy
model.
F
Well,
we
decided
that
asynchronous
was
not
the
right
word
to
describe
the
problem
space
that
we
were
working
in
so
for
now,
sticking
with
the
DT
anime
instead
and
at
a
really
high
level
summary.
The
dtnma
is
looking
to
address
three
key
points,
so
this
management
architecture
has
to
work
in
a
scenario
where
a
managed
and
managing
device
are
not
always
connected.
They're
dealing
with
asynchronous
behavior.
F
So
one
of
the
first
sections
that
we
added
to
this
document
was
in
an
effort
to
Define
our
problem
space
better.
So
we
acknowledge
that
a
dtn
can
be
considered
a
constrained
Network,
which
is
why
we
need
to
make
sure
that
the
encodings
that
we
are
using
are
efficient
and
a
GTM
is
also
a
challenge
Network.
So
experiencing
issues
like
disruptions
and
delays,
which
is
where
the
focus
on
autonomy
and
handling
asynchronous
Behavior
comes
from
looks
like
after
we
established
that
problem
space.
F
Please
so
I
tried
to
put
a
visualization
of
those
points
into
this
slide
and
obviously
that's
a
lot
of
information
to
distill
into
three
circles.
So
don't
take
this
as
a
complete
representation
of
the
problem
space,
but
trying
to
figure
out
a
way
to
show
how
the
DT
anime
fits
into
these
three
different
areas
that
are
a
priority
for
that
management
architecture.
F
F
So
one
of
the
first
major
updates
that
we
made
to
the
document
was
to
address
the
dtnma
reference
model
on
the
left.
You'll
see
our
original
AMA
model,
but
it
was
very
generic
in
describing
the
autonomy
that
we
required
for
this
network
management
approach
and
because
that's
one
of
the
focuses
of
the
dtnma,
it
was
important
to
update
the
model
and
show
how
we're
taking
advantage
of
the
use
of
an
autonomy
engine
at
the
manage
device
and
policy
which
is
created
and
passed
over
by
the
managing
device
to
inform
autonomy
next
slide.
F
Please,
and
we
will
get
into
these
figures
a
little
bit
larger
after
the
slide.
So
we
will
slow
down
and
talk
to
those
details
soon,
but
in
the
reference
model
there
are
three
main
points
that
I
want
to
address
because
they're
all
important
in
enabling
device
self-management,
which
is
something
that
we
need
if
we
can't
count
on
a
connection
between
the
managing
and
manage
device.
F
First
is
the
use
of
pre-shared
definitions.
So,
in
the
moments
where
these
devices
are
connected,
we
want
to
take
advantage
of
that
and
make
sure
that
we
are
sharing
the
data
and
models
that
are
needed
so
that
there's
an
agreed
upon
definition
of
the
data
that
is
being
pulled.
That
is
reacted
to
and
what
those
reactions
should
look
like.
F
Second,
is
the
notion
of
self-management,
which
is
happening
for
the
agent
which
is
residing
on
that
manage
device.
So
again,
an
acknowledgment
that
that
managed
device
is
often
disconnected,
and
we
need
some
sort
of
local
autonomy
to
react
to
the
occurrence
of
events.
But
we
need
those
reactions
to
be
consistent
and
based
off
of
information.
F
So
now
getting
into
the
details
of
this
reference
model
we're
going
to
start
at
the
bottom,
which
are
the
pre-shared
definitions.
So
again,
this
is
occurring
in
a
challenged
environment.
The
real-time
data
negotiation
that
you
would
need
to
maintain
large
data
stores
is
not
a
guarantee.
So
instead
we
are
taking
advantage
of
when
the
managing
and
manage
device
can
speak
to
each
other
to
update
an
autonomy
model
adms
which
are
application,
data
models.
F
And
then
speaking
to
the
managing
device,
we'll
start
at
the
top
with
the
applications
and
services
that
live
on
the
managing
device.
These
are
the
source
for
policy
statements
and
they're.
Also,
the
target
of
the
managed
devices
reports,
information
that
is
coming
back
and
those
applications
and
services
may
have
an
operator
in
the
loop,
but
they
also
may
not
slide.
F
F
F
F
And
then,
finally,
getting
into
the
actual
agent
residing
on
the
manage
device,
so
the
agent
is
responsible
for
carrying
out
monitoring
and
control,
and
the
compelling
piece
of
that
is,
it
needs
to
do
that
without
a
regular
connection
back
to
the
managing
device.
So
the
agent
itself
is
able
to
determine
what
state
it
needs
to
pull
and
when
and
part
of
that
is
driven
by
the
internal
autonomy
model.
F
F
F
The
autonomy
engine
might
also
instruct
the
agent
to
instead
generate
a
report
and
send
that
back
to
the
manager,
and
it
can
also
influence
the
runtime
data
store,
which
can
be
updated
as
well
by
the
dtnma
manager
with
additional
data
definitions
when
connectivity
is
established
so
with
that
I
know
that
I
ran
through
all
of
that
really
quickly.
So
if
there
are
any
clarifying
questions.
C
Thank
you
all
right,
luberger
I'm,
just
trying
to
understand
the
relationship
between
what
you
presented
and
what
you
had
earlier,
and
you
talked
about
Co-op
or
Cody,
whatever
you
want
to
call
it
work
off,
rescoff
anima,
and
then
he
went
into
this
and
then
you
so
rescoff
and
and
corkov
are
ways
to
transport
Yang
models,
basically
to
encode
and
transport.
Ea
models
is
what
you're
talking
about.
Here
is
an
alternate
way
to
encode
and
transport
Yang
models
or
something
completely
different.
C
F
I
agree
that
we
should
be
looking
at:
what
can
we
pull
from?
What
is
existing,
that
we
can
incorporate
something
that
we're
looking
at
in
representing
this
data?
Is
we
want
it
to
be
hierarchical
in
nature?
We
want
to
make
sure
that
we're
considering
the
efficiency
of
the
encoding
to
make
sure
that
we're
not
creating
something,
that's
so
large
that
it
doesn't
have
a
chance
of
making
it
to
that
managed
device.
Okay,.
C
C
It
is
not
about
transport,
it's
about
modeling
the
information
and
then
you
can
encode
it
as
appropriate
using
the
most
efficient
again
core
conf
or
the
least
efficient,
whichever
one
you
think
is
I
personally,
don't
like
XML,
but
that's
my
bias,
so
it
just
it'd
be
good
to
leverage
that
other
work
and
add
to
it
by
adding
encoding
and
transport
as
necessary,
and
maybe
you
don't
even
need
a
new
encoding.
Maybe
you
only
need
new
transport.
A
G
The
word
Loosely
that
that
we
have
added
with
what
we
call
part
of
our
syntactic
sugar
to
help
reduce
you
know
round
trips
that,
even
though
Yang
is
separate
from
an
underlying
transport,
although
at
the
time
you
know
it
was
created,
it
was
you
know,
kind
of
focused
on
on
netconf.
There
are
some
things
that
you
can
represent
by
adding
additional
parameters
or
additional
metadata.
A
That
was
first
I
was
aware
that
this
was
coming,
and
then
this
is
also
reached
the
overall,
and
he
said
something
like
now
now
the
cat
is
out
of
the
back.
Let's
let's
discuss
this
and
then,
let's
also
think
about
the
retartering,
so
I
started
thinking
about
what
what
we,
what
we
could
do.
I
looked
at
the
current
Charter.
A
A
A
B
So
just
some
general
comments,
one
is
that
I
think
the
working
group
was
actually
mature
in
some
cases.
So
what
I
would
like
to
see
is,
for
example,
it
says
they're
always
hard
to
be
to
maintenance.
You
know
similar
statements
for
dlap,
so
instead
of
listing
the
10
next
extensions
or
the
three
Nexus
stations
that
we're
going
to
have,
you
know
leave
it
up
to
the
left,
maintenance
and
extension
period.
That's
it
right
that
way.
We
don't
need
to
be
recharging
every
three
months
or
anything
like
that.
B
Also,
our
dlab,
you
know
the
the
sort
of
thought
about
Babel
for
me
is
that
you
know
it's
a
shame
that
if
the
working
group
closes-
and
there
are
enhancements
to
the
protocol,
I
see
Julius
on
the
on
the
line
there
that
there
might
be
not
not
a
place
to
work
on
it
by
default.
In
the
routing
area,
rcwg
takes
everything
that
doesn't
have
a
home
right
yeah,
but
in
this
case,
I
feel
that
there's
probably
better
expertise
or
closer
expertise
to
Babel.
B
I,
honestly,
don't
know
how
many
of
you
participated
in
the
Bible
working
group,
but
you
know
ideally
and
again,
I
see
Julius
Santo
Q
there.
You
know
they
would
come
here
too
right,
especially
if
there
is
something
else
that
needs
to
be
worked
so
that
way,
we
give
it
a
home
right.
So
not
necessarily,
you
know
the
same
as
with
osrv2
kind
of
listening.
There
battle
maintenance,
type
thing
and-
and
the
other
comment
that
I
have
is
the
tnma
I
I
really
don't
want
to
see
a
dtnma
for
money.
B
What
I
want
to
see
is
what's
the
charter
of
the
TN
working
group,
which
is
dtnma
where
they
work
with
us,
or
in
other
words
we
work
with
them
right.
So
the
wording
there
should
be.
Yes,
we're
going
to
work
on
maintenance
and
we're
going
to
leverage
and
collaborate
with
the
dtn
working
group
on
their
dtma
framework
or
whatever
the
you
copy,
the
whatever
the
the
10
turtle
races.
B
B
B
A
D
H
H
Okay,
so
I,
my
feeling
is
that
we're
pretty
done
with
Babel
the
plan
with
Babel
was
to
close
the
to
standardized
Babel
and
a
few
important
extensions
and
to
close
the
working
group.
Three
years
ago,
we
ended
up
doing
a
lot
of
fun
stuff
over
the
last
three
years
that
that
was
unplanned
and
I
think
it
is
time
to
close
the
working
group.
Now
all
the
Registries
in
Bible
or
specifications
required.
So
we
don't
strictly
need
a
working
group
if
we
want
to
do
any
further
extensions
to
Babel.
H
However,
there
is
a
feeling-
and
Donald
will
correct
me
if
I'm
wrong,
that
it
might
be
more
convenient
in
some
places.
If
there
were
a
working
group
where
we
could
publish
Babel
future
Bible
work-
and
many
is
a
friendly
group
with
people
who
have
all
the
right
competence
to
judge
to
review
the
Bible
drafts,
and
that
is
why
I
would
like
the
charter
to
add
something
like
Babel
maintenance,
so
that
we
can
have
a
place
to
publish
draft
and
rfcs
in
the
future.
E
B
No
I
haven't
answered
that,
so
you
guys
remember
last
time
we
recharger
this
thing.
Charlie
asked
me
to
a
the
sponsor
lwb2,
so
I
started
reviewing
I'm
still
waiting
for
updates,
and
so
basically
Charlie
hasn't
had
time
to
work
on
it.
It's
still
in
my
queue
that
doesn't
mean
that
I'll
keep
it
like
you
forever
I'm
I'm
about
to
just
give
up,
because
we've
been
working
on
it
for
three
or
four
years
and
we're
still
not
done.
A
I
I
Yeah
this
is
Donnelly's.
Like
again
I
just
say
there
is
one
document
I'm
about
to
request
publication
for
in
Babel,
and
there
is
an
expired
draft
that
a
number
of
people
in
battle
would
like
to
see
published,
but
it
doesn't
really
matter
whether
the
Bible
organ
group
exists
as
a
separate
working
group
for
any
of
us.
So
I
think
I'd
welcome
having
a
novel
maintenance
item
in
the
vanity
Charter
and.