►
From YouTube: IETF111-MANET-20210729-2330
Description
MANET meeting session at IETF111
2021/07/29 2330
https://datatracker.ietf.org/meeting/111/proceedings/
A
Yep
welcome
everybody
to
the
monday
working
group
meeting.
A
A
A
B
Yeah
sure
I've
been
in
the
ietf
for
many
years
and
also
in
the
ieee.
I've
spent
quite
a
bit
of
time
in
802.1
and
lately
in
the
security
area
and
in
the
ietf.
I've
been
doing
some
work
in
debt
net
and
ipsec.
B
A
I
just
do
that.
It
asks
for
permission
to
use
my
microphone
again.
A
A
Oh
okay,
good,
so
we
go
through
some
through
some
document
status
and
then
the
bigger
part
of
this
session
is
devoted
to
a
future
work.
I
have
some
ideas
on
the
slide
and
things
that
we
could
work
on.
A
A
A
If
not,
then
I'll
do
the
same
thing
that
I
did
last
time
and
that
is
look
at
the
recording
and
make
the
minutes
from
there.
But
if
you
can
make
some
some
notes,
however,
sketchy
that
it's
already
helpful.
I
should
have
asked
in
the
melody
story
didn't
get
around
to
that
so
to
the
documents.
We
have
three
working
group
documents
that
have
been.
A
In
working
group
law
school
for
longer
than
I
care
to
remember,
I
think
it
was
our
previous
chair,
justin
dean,
who
actually
put
them
in
american
group
last
call,
but
now
they're
finally
completed
and
they
are
completed
because
at
least
one
person
generated
some
comments
on
these
drafts,
and
that
person
was
me.
Unfortunately,.
A
As
we
speak,
one
of
the
authors,
blue
burger,
is
producing
updates
of
these
of
these
internet
graphs
to
iron
out
the
last
niche
that
were
found
and,
as
was
already
indicated
by
overall
during
last
meeting.
The
next
step
for
these
documents
will
be
to
send
them
to
the
transport
area
directorate
for
some
some
early
review,
and
then
they
will
proceed
through
all
the
steps
that
come
after
the
working
group
has
as
well
called
these
these
documents,
so
they
should
be
finally
being
on
their
way
to
become
rrcs.
A
We
have
another
document
from
the
same
author
set,
which
was
somewhat
left
behind
for
for
no
good
reason.
Actually,
it
really
belongs
to
the
the
same
set
as
the
three
drafts
discussed
above
and.
A
A
D
All
right,
thank
you,
so
I
put
these
together
before
I
knew
what
the
before
I
saw
the
updated
agenda
so
I'll
defer
to
the
chairs.
If
they
want
me
to
go
at
a
different
rate
or
cover
different
material,
they've
seen
the
slide
deck,
so
I'm
gonna
do
something
odd.
The
chairs
should
feel
free
to
flip
to
the
next
slide
or
flip
to
whatever
slide.
They
would
like
me
to
talk
about
just
because
things
got
reorganized
a
little
bit.
D
So
take
me
where
you
want
me
to
talk.
D
Then
next,
so
I'm
talking
about
I'm
talking
through
several
documents,
we
heard
ronald
give
the
the
status
on
them.
Well,
my
name
is
on
the
slide
deck.
Each
of
these
documents
do
have
code
co-authors,
who
are
not
in
attendance
for
various
reasons.
As
ronald
said,
the
first
three
were
wrapping
up
right.
Wrapping
up
last
call
I've
been
a
little
slow
on
getting
the
updates
out.
I
wanted
them
last
week,
but
I
said
I
I
would
get
them
before
this
meeting
and
I
succeeded.
D
So
the
responses
are
there
and
I've
updated
the
documents.
I
I
push
the
publication
request
on
all
of
them.
One
of
them
requires
secretariat
processing,
send
off
a
request.
For
that.
You
know.
Document
numbers
are
cheap.
So
if
someone
doesn't
like
the
changes
or
wants
different
changes,
you
know
we'll
certainly
rev
the
documents
yeah
we've
been
through.
The
adoption
calls
on
the
ether,
credit
and
chairs
I've
heard
just
now
that
this
is
adopted.
Do
you
want
me
to
just
immediately
resubmit
with
draft
ietf.
D
I
didn't
see
when
I
didn't
notice
your
comments,
so
I
apologize
for
missing
that
actually,
a
couple
of
your
messages
got
filtered,
including
the
last
one
that
I
just
responded
to,
which
you
had
sent
privately,
and
I
just
I
found
the
one
of
them,
but
obviously
not
this
one
I'll
tell
you
that
I
did
make
changes
to
parallel
the
da
credit
extension.
So
if
it's
just
the
same
comments,
I've
already
made
that
you
did
on
va
credit.
D
I've
already
made
those,
even
though
I
didn't
see
those
comments
so
I'll,
take
a
look
and
do
an
update.
Do
you
want
me
to
do
the
update
first?
If
you
want
me,
I
can
either
publish
what
was
went
through
the
adoption
call
as
the
zero
zero
or
make
the
fixes
and
then
publish
that
as
zero
zero.
Your
call.
A
I
would
you
prefer,
I
would
prefer
you
to
make
the
fixes
first
and
then
issue
it
as
a
working
group
document
I'll
do
that.
Okay,.
D
I
I
just
noticed
this
filtering,
I
just
it
it
probably
I'm
sure
I
have
it.
I
will
reach
out
to
you
if
I
don't
and
otherwise
they're
in
the
archive
yep,
exactly
and
I'll
I'll
have
a
updated
rev
of
the
draft
burger
done
before
the
end
of
this
meeting,
how's
that
assuming
other.
D
Yeah,
okay,
questions
from
the
list
I
was
hoping
henning
would
be
here,
so
we
could
talk
through
them.
The
one
of
them
is:
why
have
extensions?
No
data
items?
Ronald?
I
think
you
covered
that.
Well,
we
had
a
long
history.
I
have
a
slide
on
it
if
we
want
to
recap
it
in
more
depth,
but
I
think
you
covered
that
well
and
why
use
tid
versus
lid?
D
D
I
don't
think
we
want
to
require
lid
all
the
time
just
to
use
these
new
extensions
and
on
list
I
mentioned
that
if
we
were
to
follow
through
with
henning's
proposal,
we
would
have
to
respin
that
rfc
and
you
know
basically
hit
reset
on
these
documents.
So
I
I
think,
even
if
we
accepted
lid,
it's
a
major
process
piece,
but
also
from
the
technical
standpoint.
I
disagree
that
it's
the
right
solution.
E
C
Ethric
hi
everybody.
I
agree
with
lou.
I
can
see
henning's
point
of.
Why
do
we
need
another
discriminator
that
we
have
to
handle
in
our
implementations?
C
But
from
my
perspective,
a
lid
is
a
very
specific
identifier
to
say
that
there
are
multiple
layer,
three
addressable
destinations
beyond
the
mac
address
you
are
using
currently
to
identify
and
a
tid
means
something
else
and
just
reusing
the
identifier
to
mean
two
different
things
I
think
gets
immediately
confusing
and
it
becomes
context
sensitive
and
then
how
do
I
perform
an
implementation
which
supports
multiple
tids
per
lid,
for
example?
So
I
I
yes
they're,
both
just
integer
identifiers,
but
let's
not
mash
them
together,
because
they're
the
same
data
type.
C
So,
by
force
by
forcing
someone
to
implement
lead
just
just
to
support
traffic
classification,
I
think
is
a
mistake.
C
A
So
he's
not
here
to
to
raise
the
point
with
the
again,
but
I
will
confirm
on
the
main
list
that
we
consider
this.
This
thing.
A
A
work
group
document
now-
and
I
think
we
can
work
in
group
last
call
it's
very
soon,
but
there
is
some
room
to
for
further
discussion
within
the
work
group.
It's
only
been
adopted
as
a
working
group
document.
It's
not
working
group
last
called
yet,
so
there
is
still
a
window
for
for
making
further
comments
for
this
one.
A
However,
I
would
like
to
send
it
running
after
the
other
documents
pretty
soon,
and
I
think
that
lou
will
only
be
happy
about
that.
D
So
lou
do
you
want
to
continue
future
presentation?
Your
call,
as
I
said
you,
you
were
driving
the
slide,
so
I
will
follow
you,
but
I
appreciate
it
and
of
course
my
comments
were
sent
to
the
list.
So
penny
wants
to
take
the
discussion
up
there.
We
can
take
it
up
further.
D
Okay
yeah.
I
think
you've
already
covered
these
items
I'll
just
point
out
that
there
is
a
somewhat
old
implementation
available
on
github
and
if
you
are
interested,
please
look
at
it.
I
think
actually
there's
room
for
someone
to
take
over
driving
that
just
because
I
know
that
there's
been
pull
requests
on
it
for
a
while,
not
sure
if
there's
anyone
in
the
group
who's
interested,
but
I
figured
I'd
put
out
that
public
service
announcement
so
say
that
again,
please.
I
missed
that.
D
I
shouldn't
have
give
go
back
two
slides.
D
I'm
just
mentioning
that
that
that
github
dela
implementation,
which
from
lincoln
labs,
has
had
pull
requests
against
it
for
a
little
while,
and
there
might
be
an
opportunity
for
someone
to
take
over
supporting
that
implementation
or
fork
it
into
another
repo
and-
and
you
know,
give
it
a
little
more
tlc
tender,
loving
care.
So
a
little
more
attention-
and
I
figured
I'd
mention
that,
because
you
know,
people
in
this
room
were
listening
to
this
recording
are
the
ones
who
are
likely
to
be
the
ones
to
take
it
on.
D
I
you
know,
I
don't
know
what
the
plans
are
from
the
group
that
put
that
out.
I'm
just
comment.
I
just
observed
that
there's
the
pull
requests
have
been
sitting
there
for
a
while.
C
So
yeah
some
of
the
pull
requests
actually
came
from
my
team.
So
what
we've
done
in
the
meantime
is
we
have
a
fork
of
that
also
on
github,
which
I
will
find
the
url
in
the
chat.
There's
it's
it's
a
clone
with
the
with
the
pull
requests
merged
together,
which
we've
been
using
extensively.
C
I
also
support
if
somebody
wants
to
take
it
on,
because
you
know
my
team
doesn't
have
the
the
bandwidth
to
do
this
at
the
moment.
It
would
be
great
if
this
was
adopted
by
the
community,
so
anyone
listening
who
wants
to
pull
all
this
together.
That's
great!
I'm
just
saying
this.
C
C
It
is
being
used
quite
heavily
by
several
people
in
a
large
european
consortium,
so
we,
you
know,
we
recommend
for
various
people,
so
it
is
getting
proper
use.
It's
it's
for
test
beds
and
interrupt
testing.
It's
it's
a
really
useful
tool,
and
it
would
be
a
pity
if
it
if
it
rusted
away.
C
D
D
Great,
this
is
the
history
on
how
things
got
broke
a
little
bit
upon
how
they
broke
got
broken
apart
and
when
this
actually
was
based
on
discussion
at
ietf,
101
and
102..
D
If
you
do
the
math
that's
a
long
time
ago,
and
basically,
we
started
out
with
one
document,
then
went
two
documents
and
then
ended
up
in
four
and
the
the
thought
is
that
we
can
take
a
building
block
approach
in
the
base
documents
and
then
the
negotiate
which
of
the
building
blocks
we're
using
and
how
we're
combining
them
using
this,
the
credit
extension
so
the
I'm
sorry
the
extension,
so
the
extensions
say
how
to
combine
the
base
data
items
or
the
base
objects
and-
and
it
allows
of
it,
allows
you
to
avoid
exactly
the
problem
that
I
can't
remember
around.
D
Either
you
brought
up
or
rick
brought
up
is
is
where
you
have
to
implement
part
of
a
specification
that
you
don't
really
care
about,
because
it's
it's
it's
derivative
and
you
know
that
was
the
reason
at
the
time
I
I'm
gonna,
give
rick
credit
for
being
this
strong
advocate
for
this.
It
may
not
have
been.
My
memory
may
be
foggy,
but
it
actually
resonates
with
me
and
I
think
it
is
a
good
approach.
D
Tell
me
what
you'd
like
me
to
talk
about.
Do
you
want
to
you
had
asked
something
privately
you
on
the
difference
between
what
is
it
tid
and
fidd?
Would
you
like
to
jump
right
there.
D
Okay,
so
you
know
the
we
have
two:
we
we
have
two
different
types
of
extensions
for
flow
control.
D
One
of
them
is
using
a
link
based
mechanism,
the
pause
extension,
that's
really
sort
of
like
exon
x
off,
and
it
is
it's
really
very
coarse,
because
you
can
either
pause
on
the
link
basis
or
on
a
priority
basis,
but
not
on
a
destination
basis
and
there's
certainly
some
channels
out
there,
where
you
might
want
to
pause
to
one
end
point,
but
not
the
other,
and
that's
what
we
get
with
the
credit
flow
control
and
now
the
credit
flow
control
also
is
a
method
of
it's
it's
sort
of
a
window-based
approach,
so,
rather
than
exxon
x
off
you,
you
can
get
credits
the
I
like
to
characterize
one
as
work,
conserving
and
one
not
as
work
conserving,
non-we're
conserving,
but
that
might
that's
a
little
course
in
that.
D
I
think
with
the
credit
extension,
you
can
actually
keep
the
link
a
little
busier
than
you
could
with
the
pause.
But
that
depends
a
little
bit
on
the
time
windows.
D
Thing
I
think
it's
pretty
funny
that
that
and
okay
back
too,
please.
D
All
right,
so
the
basic
operation
is
that
the
credit
windows
and
the
traffic
identifi
identification
pieces
are
given
in
the
session
the
the
difference.
You'll
notice,
there's
a
term
here
flow
identifier
and
traffic
class
identifier
and
the
difference
is
one-
is
about
the
treatment
and
really
about
cue
management
and
that's
the
flow
identifier
and
the
other
one
is
about
traffic
classification
and
that's
the
traffic
classification
identifier,
and
what
do
I
mean
by
classification
is:
is
what
fields
in
the
header
do
you
use
to
map
traffic
to
the
particular
queuing
treatment?
D
D
And
we
support
the
mapping
a
a
flow
to
a
particular
traffic
lasts.
So
for
you
to
do
classification,
okay,
next.
D
If
you
run
out
of
credits,
we
have
some
ability
to
request
credits
and
also
give
credits
and
this
reviews
the
messages
that
are
used
for
it.
I
copied
and
pasted
this
from
an
old
presentation
and
the
bottom
left
put.
It
actually
is
a
mistake.
I
didn't
update,
so
you
can
actually
see
when
this
slide
was
originally
presented
or.
E
A
For
the
nitty-gritty
details
see
the
documents:
okay,
I'm
going
to
switch
to
the
next
presentation.
If
you
don't
mind.
D
Not
at
all,
thank
you
for
the
time
and
comments
and
also
moving
this
forward.
Yeah.
A
Implicitly,
we
have
covered
item
three
on
the
agenda.
I
already
talked
about
that.
We
that
we
consider
this
the
the
ether
based
approach
as
a
working
group
document
now,
and
nobody
was
rushing
to
to
the
microphone
to
to
protest.
So
I'll
just
confirm
this
on
the
on
the
menu
list
and
we
we
perceived
as.
A
A
A
C
So
I
know
stan
and,
and
the
team's
original
idea
with
dlip
was
that
the
modem
should
give
the
router
information
that
the
router
understands
and
my
concern
with
these
three
extensions
is
they're,
really
telling
the
router
about
layer,
one
layer,
two
and
their
one
information
really
that
in
terms
that
maybe
don't
make
sense
at
layer
3.
C
now.
The
counter
argument
from
henning
has
always
been
yes,
but
you
could
be
doing
some
very
clever
calculation
within
your
router
or
some
ai.
That's
doing
some
predictive
stuff
or
all
kinds
of
exciting
modern
techniques.
So
just
getting
the
information
is
useful,
but
I
agree
that
it
re
I
I
would
prefer
to
see
slightly
more
condensed
information
or
perhaps
have
all
of
this
as
one
extension
and
say:
look:
here's
a
load
of
radio
layer,
channel
information
that
the
modem
can
can
hand
out.
A
Good,
maybe
you
can
say
something
like
that
on
the
main
list.
I
know
that
I'll
say
it
again
yeah.
I
know
that
you've
commented
three
months
ago
when
they
were
initially
submitted,
but
it
can't
hurt
to
to
repeat
that.
Actually,
I
think
the
radio
band
one
is
is
is
almost
ready
for
group
adoption.
A
I
can
see
a
use
for
that,
but
I
will
I
will
say
why,
on
the
mailing
list,
the
radio
quality
one
I
haven't
really
taken
a
long
hard
look
at
it,
provides
or
can
provide
several
kinds
of
information
signal
to
noise
ratio,
regular
signal,
strength
indicator
and
again
yeah
there.
I
share
some
of
the
ideas
that
rick
was
just
expressing
that
this
is
maybe
too
low
level
information
for
for
the
realtor,
but.
B
D
Lou,
do
you
have
a
comment?
I'm
gonna
say
something
similar
where
it
it's
just.
It
applies
to
all
of
these.
In
anticipation
of
this
discussion,
I
would
review
to
all
of
them
and
they
look
interesting,
but
none
of
them
have
you
call
it
on
this
first
one
motivation,
so
you
know
what
is
the
router
supposed
to
do
with
this
and
if
it
you
know,
take
it
and
pass
it
to
some
magic.
D
You
know
ai
thing.
You
know.
I
think
that
was
what
rick
said.
Sure
that's
fine,
but
it
should
say
it
and
I
think,
without
that
I
I'm
not
sure
it
makes
sense
to
adopt
these
now.
That
said,
I
think
these
are
really
interesting
and
I'd
like
to
learn
how
we
should
be
using
them.
A
Yeah,
so
maybe
it's
just
a
matter
of
providing
some
more
text
in
the
introduction
to
to
motivate
why
they
are
there.
And
I
remember
that
the
link
identifier.
A
A
Guess
let
me
see.
A
Okay,
this
is
hopefully
the
most
interactive
part
of.
A
This
session,
I'm
just
going
to
throw
out
some
ideas
and
if
you
think,
they're,
good
or
bad
or
you're,.
A
You're
interested
to
work
on
them,
I
would
like
to
hear
that
because
it
will
determine
where
we
go.
A
So
long
before
I
became
a
chair,
the
parts
in
green,
I
think,
are
covered.
We
have
done
almost
nothing
but
d
lab
work
in
the
last
few.
A
Years
after
the
recharger
multicast
seem
to
have
a
lot
of
interest,
and
I
will
quickly
go
to
an
old
presentation
by
justin
dean
in
a
minute.
A
A
Maintaining
also
v2
and
friends
and
extensions-
and
another
thing
I
noticed
is
that
we
have
a
couple
of
experimental
documents,
rfcs
that
may
or
may
not
become
standard
tracks
document.
At
some
time
I
know
henning
has
done
a
lot
of
work
on
the
directional
air
dimetric
he's
the
original
author
over
the
last
few
years.
A
I'm
not
I'm
not
seeing
at
the
moment,
but
yes,
please.
B
A
This
chair,
at
least,
still
has
to
wrap
his
head
around
the
problem,
because
I'm
not
that
deep
into
the
details
of
photos
rv2,
but
there
is
indeed
I
was
sort
of
present
when,
when
having
robert
discovered
this,
I
was
part
of
the
same
event
where
this
this
emerged
and
there
we
were
in
you
know:
ozar
versus
two
network,
restarting
routers
very
frequently,
and
sometimes
they
didn't
find
each
other
again
we're
no
longer
able
to
accept
each
other's
topology
control
messages,
and
this
had
to
do
with
receiving
realtors
thinking
that
advertised
neighbor
sequence,
numbers
were
were
still
so
the
messages
were
stale
and
just
therefore,
they
were
ignoring
them.
A
Now.
Having
us
has
made
a
description
of
the
problem
on
the
mailing
list.
A
And
what
was
very
nice
to
see
is
that
the
former
chair,
justin
dean
and
former.
A
Main
contributor,
or
one
of
the
main
contemporaries
to
ozark
v2,
christopher
dalov,
who
was
retired,
responded
and
have
this
discussion
have
been
discussing
with
henning.
What
would
be
the
best
approach
to
fix
this
and,
as
things
start
now,
and
as
far
as
I
understand,
there
is
a
some
idea
to
produce
an
informational
rfe
with
some
guidance
on
how
to
avoid
this
problem.
A
And
the
way
it
looks
now,
it
will
not
be
needed
to
actually
make
modifications
to
the
protocol,
but,
as
I
said,
the
discussion
is
ongoing
and
I
I'm
planning
to
dive
dive
deeper
into
this,
so
that
I
also
understand
exactly
what's
going
on.
But
at
the
moment
it's
between
henning
and
christopher,
mostly,
and
I'm
trying
to
to
understand
what
they're
saying.
A
But
I
think
it
would
be
great
because
christopher
even
offered
to
help
with
with
drafting
such
such
a
document,
and
I
think
that
would
be
very
good.
I
hope
that
answers
the.
C
A
So
where
do
we
stand
with
multicast
previously,
a
long
time
ago.
A
Simplified
multicast
forwarding
was
was
done
as
an
experimental
rfc
as
map
is
not
even
a
real
protocol.
It
describes
some
ways
to
do
smart
floating
by
doing
duplicate
packet
detection.
It
specifies
several
techniques
for
doing
duplicate,
packet
detection
and
then
in
the
appendices.
A
In
the
in
your
money,
environment
is
resubmitting
retransmitting
packets
to
flow
them
to
everyone,
but
just
a
selective
fuel.
And
then
you
can.
You
can
use
the
information
from
your
unicast
routing
protocol,
the
npr's
from
ozar
v2,
for
example,
to
reduce
the
rig.
A
Now,
as
I
said
after
the
recharger
in
2016.
A
I
got
this
approval
to
do
that,
and
part
of
that
is
also
an
even
older
document
on
elastic
elastic,
multicast
routing
protocol
that
was
written
and
presented
in
in
the
last
meeting
of
2013
by
brian
emerson,
a
colleague
of
justin,
and
that
says
that
you
can
do
more
intelligent
things
than
smart
flooding,
building
an
actual
multicast
3.
A
As
long
as
certain
sections
of
your
network
are
relatively
stable
and
the
idea
was
never
picked
up
by
by
the
working
group.
But
I
know
that
nrl
has
been
progressing
this
internally
and
in
fact,
if
you
look
at
nrl
smf
their
implementation
on
github,
then
you'll
see
that
there's
a
quite
a
bit
of
support
code.
For
that
already.
A
A
A
So
maybe
there's
some
interest
there
to
pick
that
up
and
the
interesting
thing
about
on
demand
multicast
rather
than
propositional,
is
that
it
actually
takes
a
group
membership
into
account
which,
as
a
map,
does
not
then
rick.
You
mentioned
beer
already
several
times
and
I've
still
haven't
been
able
to
wrap
my
head
around
that
and
determine
whether
that's
actually
a
viable.
C
Just
commenting
on
on
on
the
beer
comment
rick
taylor
here.
The
reason
I
raised
beer
is
beer
is
a
technique
that
has
very
much
developed
since
we've
been
talking
about
multicast
in
mayonnaise,
so
you've
got
comments
on
here.
Looking
back
at
things
from
2013
and
earlier
beer
has
arrived
since
then,
and
I
wonder
whether
there
hasn't
been
people
looking
at
it.
I
wonder
whether
you
could
flood
beer
membership
and
then
build
your
trees
on
top
of
it
or
or
something
I
I
I
haven't
got
cycles
to
look
at
it.
A
A
To
look
at
it
because
it's
interesting
to
me,
but
yeah,
there's
a
reason
why
why
multicast
is
different,
different
and
difficult
in
mobile
effort
networks,
bim,
sparse
mod
does
not
work.
We
know
so.
C
So
can
I
can,
I
add
my
comment
now
at
the
end
of
this
slide.
Of
course,
I'm
going
to
be
contentious
and
to
say
that
I
think
multicast
in
mayonnaise
is
being
addressed
at
the
link
layer
from
everything
I'm
seeing
happening
in
the
industry.
C
Give
me
your
multicast
traffic
and
we'll
sort
it
for
you,
and
so
I'm
wondering
whether
this
work
actually
still
has
a
home
in
the
ietf
or
whether
it's
it's
being
done
in
academia
and
being
handled
in
802.11
or
802.15
or
in
in
various
non
ieee
environments
and
and
the
link
layer
community
will
will
solve
this
for
their
own
specific
types
of
link.
There.
A
C
Yes,
I
I
agree,
I
agree,
but
I
think
you
would
then
be
bridging
multicast
capable
or
joining
multicast
capable
subnets
together,
at
least
where
something
like
saw,
specific
some
pin
variation
or
perhaps
going
back
to
my
previous
point,
beer.
Some
existing
multicast
technology
at
their
three
will
handle
it.
It's
an
interesting
piece.
I
I
don't
know.
A
D
I'm
going
to
maybe
disagree
with
rick
talk
to
him
about
maybe
on
the
next
slide
or
the
next
topic,
bringing
in
what's
happening
in
raw,
which
rick
shares
and
I'll
point
out
to
rick
that
there's
discussion
in
raw
about
a
ip
aware,
multicast
running
integrated
with
the
radios.
C
Okay,
I'll
respond.
Yes,
I
I'm
I'm
well
aware
that
that's
that's
happening
in
within
the
context
of
raw,
but
I
think
that's
happening
in
negotiation
with
the
capabilities
of
the
link
layer.
C
D
Yeah,
so
I
think
the
the
comment
which
belongs
on
the
next
topic
is,
there
may
be
work
coming
in
from
raw
or
some
protocol
work,
that's
being
defined
in
raw,
which
is
not
currently
charted
to
do
protocol
work.
That
may
end
up
here
at
some
point,
but
you
know
I
I
think
it's
still
sorting
its
way
out
there.
C
Yeah
we're
very
much
in
that
writing
architecture
documents
and
I
think
most
of
the
people
I
can
see
on
the
attendees
list
here
were
actually
in
raw
as
well,
which
was
great
but
yeah.
So
so
raw
is
very
much
doing
the
the
thing.
The
use
cases,
the
architecture,
the
the
technologies
piece,
and
it
would
be
great
to
bring
some
of
the
protocol
development
into
manet,
because
manet
has
the
wealth
of
experience
for
doing
it.
But
there's
still
big
open
questions
about
multicast,
but
I'll
cede
my
place
in
the
line.
A
Yeah-
and
I
just
noticed
a
comment
by
overall
in
the
mailbox
in.
A
Right
moving
on
just
to
finish,
this
slide
set.
A
We
have
this
this
work
item
about,
as
I
said,
outlining
challenges
and
best
practices
for
deploying
managing
networks.
A
A
But
please
contradict
me
if
I
got
it
wrong,
but
I
don't
think
that
that
anybody
will
come
forward
and
say
yes.
This
is
how
you
should
should
deploy
and
manage
your
mones
based
on
our
experience,
because
I
think
those
who
are
running
actual
real
life
manage.
G
I
just
want
to
say
that
I
agree
with
you.
I
think
we
ended
up
with
this
item
in
the
charter
as
some
sort
of
compromise
from
earlier
documents
that
didn't
say
how
you
would
manage
the
network
right
or
finding
I
don't
know
or
whatever
and
and
it
wasn't
clear
how
the
network
would
be
managed.
G
There
was
a
draft
that
I
ended
up
killing
because
it
was
all.
This
are
specific.
I
think
on
management,
and
we
wanted
was
a
more
general
one.
G
I
I
think
that,
as
we
recharter
depending
on
what
changes
we
put
in
the
charter,
maybe
we
can
just
silently
ignore
no
one
will
notice,
but
you
know
we
may
still
run
the
risk
that
we
want
to
that.
Someone
wants
to
put
something
in
here
and
we'll
have
to
explain
to
them.
You
know
why
normal
or
traditional
management,
that's
not
going
to
work
in
a
minute
right.
That's
apologies,
unstable,
especially,
and
so
the
same
goes
for
like
gang
models
and
things
like
that.
A
Yeah
well,
what
I've
been
thinking
about
and
rit
knows
this.
H
It
I
just
wanted
to
say
it's
from
what
I've
seen
it's,
it's
too
diverse,
of
a
problem
to
really
put
a
set
of
standards
or
best
practices
too.
You
have
many
different
protocols.
People
may
be
using,
so
that's
really
a
challenging
problem
to
do
in
this
in
this
environment.
So
I
think
you
know
I
agree
with
what's
being
said,
I'll
defer
to
right
now.
C
So
I
was
gonna
pretty
much
underline
what
you
just
said.
Ronald,
I
think
the
asynchronous
management
protocol
stack,
that's
being
developed
in
dtn
may
well
cover
the
many
management
use
cases
which
can't
be
covered
by
traditional
networking,
that's
handled
in
the
in
the
normal
ops
area
of
the
ietf.
C
So
I
think
you're
right
alvaro
that
the
manet
straddles
the
point
where
your
traditional
management
no
longer
functions,
but
I
think
at
that
point
dtn
have
a
a
fairly
mature
matures
the
wrong
word,
a
fairly
good
idea
of
how
to
manage
this,
that
that
is
being
standardized
and
we're
very
happy
to
share
the
work.
You
know
we've
got
enough
work
in
dtn.
Actually
we
spent
two
years
trying
to
find
another
home
for
this
work,
but
it's
stuck
in
dtn
at
the
moment.
G
Officials,
where
is
it
stuck
with
because
you
didn't
find
home
so
yeah,
I
remember
a
while
ago,
we're
talking
with
spencer
and
you
and
someone
else
about
maybe
moving
network
to
my
name
yeah.
So
is
that
exactly?
Is
it
charter
for
that?
Or
is
it
just
there
because
there's
no
other
place.
C
That
is,
it's
now
sat
with
the
ad,
so
I
think
we've
got
it
now
and
we're
happy
to
do
it
and
that's
that's-
has
the
consensus
of
the
working
group
that
they
wish
to
work
on
it
within
dtn
without
being
rude
to
this
community.
I
think
we
have
more
participants
in
the
dtn
working
group
than
we
do
in
manet.
So
I'm
I'm
happy
and
there's
a
lot
of
crossover.
So
I'm
I'm
happy
it's
getting
the
eyes
it
needs
and
I
think
that's
the
most
important
thing
really.
A
A
Young
was
not
so
popular
at
the
time
that,
for
instance,
all
of
our
v2
was
doing.
What's
done
so
there
are
mix
but
but
now
yeah
models.
Maybe
there
shouldn't
be.
I
don't
know.
A
Okay,
I
was
going
to
go
over
the
old
presentation
of
justin.
I
see
that
we
are
almost
out
of
time,
so
I
going
to
skip.
A
A
There
may
be
several
proprietary
money
solutions,
doing
multicast
and
probably
also
unicasted
at
layer
two,
but
somehow
you
need
to
connect
these
together
and
that's
also
something
that
we
can
work
on
and
serious.
Some
people
have
different
different
ideas
about
this,
having,
for
instance,
things
that
we
can
perfectly
do
this
without
also
our
version
2
and
I've
been
dabbling
with
my
own
protocol,
but.
A
A
A
A
A
A
And
with
that,
I
think
we're
we're
almost
out
of
time.
So,
thanks
for
your
attention
for
your
presentations
for
your
questions
and
probably
see
you
online
some
other
time
and
maybe
in
the
further
future
in
real
life,
I
hope.
B
So
thanks
just
checking
the
the
chat
window
to
see
if
there
was
anything
else.
D
Until
you
asked,
is
there
anything
else
in
there
that
I
put
here
the
updated
document
that
ronald
mentioned?
I
found
his
review
and
posted
the
update.
I
also
have
the
zero
zero
document
for
your
approval
whenever
you're
ready,
yup,
which
basically
basically
equals
exactly
the
last
the
last
version
of
the
one
I
just
uploaded.