►
From YouTube: IETF113-MANET-20220321-1200
Description
MANET meeting session at IETF113
2022/03/21 1200
https://datatracker.ietf.org/meeting/113/proceedings/
D
A
A
A
D
D
A
A
A
Here's
the
agenda
for
this
afternoon.
We
have
a
fairly
short
agenda.
We
may
have
me
go
through
it
before
the
hour
is
over.
However,
I
really
would
like
to
to
achieve
two
things
in
this
meeting
and
that's
sort
of
a
decision
to
be
confirmed
on
the
mailing
list,
of
course,
about
how
to
proceed
with
the
credit-based
flow
control
documents
that
have
been
under
a
transport
area.
Early
review,
and
specifically
there
has
been
a
suggestion
to
merge
two
of
these
documents.
A
A
A
A
B
A
A
A
A
If
we
merge
of
aware
with
traffic
classification-
and
we
also
diff
serve,
we
also
merge
ether
based
with
traffic
classification.
We
get
two
documents
with
roughly
60
70
percent
the
same
content,
and
that's
that's
strange,
I
think
so.
Then
we
would
have
to
look
at
the
traffic
classification,
how
we
could
possibly
rework
that
and
maybe
divide
that
up
into
two
separate
documents
and
then
merge
one
with
div
serverware
and
the
other
one
with
the
eta
based.
F
No,
no,
no,
I'm
actually
even
happier
that
you
did
it
because,
as
you
said,
it's
a
working
group
decision,
it's
not
an
author
decision,
so
we
have
these
old,
very
old
documents.
The
fourth
one
had
trailed
behind.
I
think
at
this
point
effectively
it
has
caught
up.
The
working
group
had
made
the
call
to
break
them
apart,
largely
because
then
you
from
a
conformance
standpoint,
you
would
issue
you
would
say
you
know.
F
As
a
as
a
user
you
could
say,
or
as
a
vendor,
you
could
say
we
can
form
with
this
rfc
and
it's
unambiguous,
which
parts
that
you
support.
There
was
some
concern
that
if
they
were
a
single
document,
it
would
imply
that
you
supported
everything,
and
that
was
the
you
know
from
my
view.
That
was
the
the
rationale
behind
the
split
up,
and
oh
I'm
really
talking
to
the
next
slide.
But
anyway
doesn't
matter.
No!
No!
It's
okay
go
back.
F
So
so,
that's
you
know,
that's
really
going
back
ancient
history
and
these
are
really
old
documents
that
have
really
been
slowed
down.
Based
on
you
know,
what's
going
on
in
the
working
group,
the
the
it
doesn't
seem
like
there's
much
technical,
open
issues
on
this.
The
documents
have
been
stable
a
very
long
time.
David
did
ask
for
a
clarification
that
that
ended
up
in
one
technical
change.
F
I
think
the
really
only
open
substantive
question
is
how
many
documents
from
my
view,
you
know
we
had
that
that
history
of
of
splitting
things
apart
and
that's
if
you
want
to
go
into
more
of
that,
there's
a
couple
more
slides
on
it.
You
know
that
those
changes
date
back
literally
10
ietfs,
maybe
12
ietfs
ago,
so
that
was
a
lot
ancient
history
sort
of
doesn't
matter
what
the
asian
history
is.
The
key
things
I
think
are
we
are
where
we
are
number
one
number
two.
F
F
I
think
we
should
merge
all
four
and
put
it
in
a
single
document,
and
I,
I
think
also
keeping
them
apart-
has
some
good
rationale
to
it,
I'll
flip
through
the
next
two
slides,
just
because
they're
really
old
and
they
have
been
presented
and
they
provide
some
additional
context
and
then
leave
it
to
the
room
to
discuss
next.
Please.
F
F
There's
there
has
been
some
cleanup
since
then,
but
nothing
too
substantive
next
and
then
at
102.
There
was
some
additional
discussion
about
making
about
this.
That
yielded
the
structure
we
have
now
and
it
was
to
make
it
clear
again
from
the
conformance
standpoint
what
you
were
supporting
from
a
implementer
standpoint.
I
don't
know
I
don't
care
if
it's
one
document
or
ten
documents
as
long
as
they're
linked
to
each
other,
and
these
these
have
appropriate
normative
references.
F
F
B
B
You
know,
given
this
discussion
I'll,
probably
if
there
are
more
than
one
progress
them
together
right,
so
we're
not
trying
to
review
things
in
the
asg
that
depend
on
something
that
happened
a
few
months
ago
or
something
like
that.
So
from
that
point
of
view
right,
it
will
end
up,
hopefully
being
that
we
publish
them
all
at
the
same
time.
So
from
the
point
of
view
of
our
c
publication,
it's
about
the
same
thing
right
I
have
heard
in
other
working
groups.
B
B
A
Yes-
and
we
had
the
same
discussion
one
year
ago
when
we
had
these
three
fire
related
drafts
from
henning
robert,
and
we
also
said
well
they're
fairly
short:
should
we
merge
them
or
should
we
should?
We
keep
them
separate
and
was
exactly
the
same
argumentation
that
if
you
keep
them
separate,
then
implementers
can
say
well,
I
support
this
one,
but
not
the
other
one,
so
that
that
is
valid.
B
B
Last
call,
you
know
everything
else
and
it's
just
going
to
delay
something
for
the
same
text
right
and
and
maybe
confusion
to
implementers
or
people
in
the
field.
So
sure
you
know
it's
nice
to
listen
to
the
to
the
reviewers.
But
you
know
this
doesn't
sound
like
a
technical
argument
right
that
he's
saying
that
something
is
wrong.
B
G
B
E
F
The
discussion
I
I
would
prefer
to
keep
them
separate
and
not
only
because
it's
less
work
for
me,
which
is
always
a
nice
thing,
but
we
can
take
the
versions
we
have
right
now
and
submit
them.
You
know
all
the
other
comments
have
been
addressed
and
the
documents
have
been
updated.
You
know
at
the
same
level
I
think
I
think
they're
ready
to
hit
submit
at
this
point.
It
would
be
good
to
get
david
to
confirm
that
his
other
comments
are
addressed
and
and
then
go.
F
F
We
shouldn't
wait
a
very
long
time
and
keep
in
mind
that
this
is
just
getting
into
the
isg
there's
still
ietf
last
call,
there's
still
the
formal
approvals
by
the
area.
Directors.
He'll
have
plenty
of
time
to
speak
up
if
he
disagrees
yeah
or
plenty
of
opportunity.
I
shouldn't
say
time,
unfortunately,
will
be
plenty
of
time,
but
I've
had
plenty
of
opportunity.
A
F
F
That's
not
the
same
as
asking
the
question
again.
I
don't
think
we
need
to
ask
the
question
again.
I
think
you
know
asking
david
if
he
has
any
comments.
I
think
that
you
know.
Does
this?
The
current
version
stress
all's
comments.
I
think
that's
good
alvaro
said
progressive
as
a
set.
I
think
that's
good,
but
you
know
we
don't
have
to
have
unless
someone
else
raises
this.
We've
asked
and
answered
this
so
many
times
in
the
working
group.
I'm
not
sure
it
helps
to
ask
again.
F
A
F
A
A
A
A
A
I
responded
this
morning,
so
the
discussion
is
is
going
which
is
good,
but
that
should
not
stop
this
draft
from
being
adopted
as
a
working
group
document
as
far
as
I'm
concerned,
because
that's
only
that's
not
the
end
of
the
process
and
not
the
end
of
discussion,
but
really
the
beginning
of
it.
It's
it's
nothing.
Working
group
last
call
don.
You
wanted
to
say
something.
D
Yeah,
I
just
had
a
question
of
why
it
was
it
was
just,
but
this
this
draft,
like
knitting,
has
three
drafts,
and
it
seems
to
me
that
the
frequency
mine
is
probably
related
to
the
quality
that
you
know
in
quality
aspects.
The
the
discussion
as
I've
been
reading.
It
seems
to
be
that
if
you're
doing
frequency
hopping,
it
might
have
some
other
effect
on
it,
but
you're
really
not
going
to
get
a
good
feel
for
what
the
actual
capability
of
frequency
hopping
is
other
than
it
can
do
it.
A
A
D
A
A
I
think
the
discussion
on
the
radio
band
thing
is
not
overwhelming,
so
this
is
a
another
encouragement
to
the
working
group
to
the
working
group,
members
to
state
their
opinions
or
ask
questions
or
provide
comments,
as
some
have
been
doing.
But
I
hope
there
are
more
people
out
there
that
can
chime
in
on
this.
A
A
A
B
B
B
You
know
wanting
to
to
do
this,
so
yes
on
one
hand,
I
think
that
you
know
things
are
moving.
You
know
it's
an
type
network,
so
it
sort
of
fits.
On
the
other
hand,
I
would
really
like
to
see
you
know
other
people
in
the
space
interested
right.
If
not,
I
don't
think
it
makes
sense
for
for
the
one
person
or
the
one
company
to
to
you
have
to
push
some
work
right,
even
if
others
might
want
help
right.
G
Yeah
go
ahead,
yeah
the
ambergram,
which
so
I
believe
this
you're
referring
the
presentation
that
was
done
this
morning
in
the
distributed
mobility
yeah,
and
I
want
to
make
that
comment
there.
So,
first
of
all,
if
that
would
be
discussed,
I
think
man.
It
would
be
a
much
better
working
group
for
that,
then,
then,
that
would
been
in
the
distributed
mobility
management
and
as
this
is
about
semantic
crowding-
and
there
is
some
interest
within
the
community
to
work
on
the
semantic
routing
by
this
I'm
referring
to
the
work
by
adrian
farrell
and
daniel
king.
B
Right
so
just
a
quick
clarification
alvaro
retina
future
way.
Again,
yes,
so
there
are
yeah.
This
is
a
big
system
right,
so
there
are
many
different
parts
in
there
and
that's
why
we've
been
talking
to
different
working
groups,
so
there's
all
the
the
mobility
and
handoff
management
stuff.
So
yeah.
That's
why
dmm
there's
a
bunch
of
routing
right
in
between
all
the
links?
B
B
I
think
that
that,
given
that
it's
a
big
problem,
it
probably
doesn't
fit
in
one
place,
and
even
if
we
do
one
thing
in
one
place,
for
example
routing
here
right,
I
think
the
forwarding
using
say
semantic
addresses
yeah,
it's
sort
of
independent.
Somehow
right,
we
can
still
do
forwarding
in
different
ways
or
we
can
do
them
with
the
semantic
thing
right.
So,
in
other
words,
I
don't
want
to
also
wait
for
other
working
groups
and
research
groups
to
figure
out
what
to
do
with
this
amazing
growing
stuff
before
doing
something.
A
G
G
Is
looking
for
some
real
use
cases
and
they're
coming
up
with
this
a
real
use
case
and
the
real
problem
that
industry
has
to
solve
is
trying
to
solve.
So
there's
reason
why
I'm
saying
joining
forces
by
bringing
a
real
use
case.
That
is
a
problem
today,
could
speed
up
with
the
work,
because
there
would
be
more
interest
by
the
larger
number
of
community.
Okay.
A
F
So
I
think
we've
had
satellite
presentations
in
multiple
working
groups
in
different
areas,
speaking
to
alvaro
as
a.d.
It
might
be
worthwhile
to
have
a
single
place,
at
least
the
route
for
the
routing
issues
to
be
housed
so
that
we
know
where
to
go
for
the
discussions
and
their
single
discussions
as
opposed
to
fragmented
discussions
and
whether
it's
semantic
routing
elements
show
up
or
not.
I
think
that's
you
know
a
more
detailed
comment
than
what
I'm
making
you
know.
F
That's
both
that's
secondary,
but
it
would
be
a
good
good
to
have
a
single
place
for
it.
Man
a
seems
to
be
a
great
candidate,
not
a
lot
of
activity
here
that
you
know
so,
there's
probably
space
for
it.
But
then
again
you
often
get
more
activity
in
a
new
working
group,
so
I
would
be
interested
in
hearing
from
alvaro
if
the
isg
has
been
talking
about
potentially
where
to
house
this
activity.
B
We
have
well
me
obviously,
but
others
noticed
that
there
have
been
representations.
The
other
places
so
just
to
be
clear.
I'm
going
to
hand
this
off
to
one
of
the
other
routing
ads
right,
since
I
have
an
obvious
conflict
on
talking,
especially
with
the
entities
because
of
dmm,
and
you
know
has
been
presented,
I
think
in
int
area
as
well
to
figure
out
you
know
what
do
we
do
with
this?
B
If
anything,
as
I
said
before,
one
of
my
concerns,
even
if
I'm
one
of
the
authors
there
is
that
I
think
it's
an
interesting
topic,
and
I
think
many
of
us
would
say
it's
an
interesting
topic.
Even
if
we
were
not
working
on
it,
I
would
again
like
to
see
more
actual
people
working
on
constellations
or
trying
to
provide
service
over
satellite
networks
to
you
know,
come
forward
and
be
interested
in
doing
some
of
the
work
you
know.
Otherwise
it
will.
B
A
B
B
B
B
Specific
proposals
for
use
cases-
maybe
this
is
the
first
one
right
again
trying
to
deconflict
myself
as
much
as
possible.
So
we've
been,
you
know,
looking
at
that
as
well.
You
know
if
there
is
a
specific
proposal
for
what
work
do.
Should
we
do,
then
you
know
it's
something
we
then
we
can
consider
you
know.
Do
we
charter
a
new
working
group?
Do
we
do
this?
B
Do
we
do
a
mainly
less
you
know,
whatever
the
the
options
are
again
if
you're
interested
towards
the
end
of
rtdwg
in
the
next
hour,
we're
gonna
have
a
discussion
on
that.
Hopefully
we
get
to
it
because
it's
in
the
last
couple
of
10
20
minutes,
so
we
might
run
out
of
time,
but
that's
some
of
what
we're
going
to
be
discussing.
Okay
there
as
well.
G
A
G
G
What
are
the
requirements
and
and
develop
the
right
solution
instead
of
just
going
from
one
angle
and
ended
up
being
a
one
specialized,
and
then
we
see
oh,
we
need
something
else,
and
then
we
end
up
another
version
of
solution
for
pretty
much
the
same
problem.
Hence
I
would
like
to
see
that
you
know
me
personally.
I
would
like
to
see
that
joint
work,
because
who
knows
what
different
errors
will
run
into
it
and
the
more
input
we
have.
I
think
we
can
then
develop
a
better
solution.