►
From YouTube: IETF110-MANET-20210312-1430
Description
MANET meeting session at IETF110
2021/03/12 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
D
A
D
A
A
A
A
A
A
A
A
G
H
H
H
H
H
You
know
there
was
even
a
discussion
of
whether
to
adopt
it
or
not,
and
we
said
yeah,
let's
wait,
one
meeting
we'll
adopt
at
the
next
meeting
and
instead,
two
years
later,
we
still
don't
have
that
one
adopted
and
yeah.
You
know.
Obviously
the
adoption
call
originally
was
started
by
stan,
and
you
know
we
had
that
history,
and
so
it's
a
little
understandable
why
things
have
slowed
down,
but
we
really
want
to
figure
out
where
we
go
next.
I
do
have
next
slide
please.
H
I
do
have
backup
slides
that
go
through
the
work
to
remind
the
working
group.
What
it
is,
if
we
want
to
do
that
I'll
defer
to
ronald
on
that,
but
the
the
the
short
answer
or
the
short
message
is:
what
do
we
do?
Do
we
stop
or
do
we
move
forward
and
it's
a
question
both
to
the
working
group
and
to
ronald.
A
H
C
Rick
you're
up
first
yeah.
I
fully
support
these,
I'm
all
in
favor
of
the
split
that's
happened
because
I
think
it
it
divides
the
documents
into
a
piece
on
flow
control,
a
piece
on
generic
handling
of
flows
to
a
destination.
So
splitting
the
concept
of
a
link
between
two
modems
within
the
network
into
the
flows,
because
there
are
software-defined
radios,
are
doing
smarter
and
smarter
things,
and
we
all
have
pretty
much
come
to
the
conclusion
that
the
flow-based
routing
is
is
the
future.
C
So
yeah,
I
think
the
merge
is
good.
I
I
want
to
say,
let's
adopt
the
802.1
priority
flag
document
as
well
it.
It
works
very
well
as
we
sort
of
touch
on
layer
2.
Otherwise,
the
ieee
will
come
up
with
their
own
tsn
based
thing,
which
won't
quite
work
with
our
models,
and
it's
not
a
big
e.
Let's
just
let's
just
do
it
and
I
promise
to
read
and
review
them
great.
I
C
I
I
had
it
in
mind
when
I
was
writing
the
link
id
so
the
concept
of
a
link
identifier
and
the
concept
of
a
queue.
Identifier
are
orthogonal,
but
they
won't
trample
on
top
of
each
other
as
well.
So
I'm
I'm
really
hoping
it
fits
together
because
both
of
those
extensions
were
discussed
and
developed
at
pretty
much
the
same
time.
We
just
happened
to
get
link
id
at
the
door.
First.
A
C
I
H
I
really
appreciate
that
comment
because
heading
privately
had
asked
me
about.
You
know
the
overlap
and
my
head
wasn't
quite
in
the
the
spec
at
the
time.
So
I
was
wavering
a
little
bit,
but
I
think
this
slide
really
shows.
The
difference
is,
is
that
in
in
this,
in
the
current
set
of
documents
and
by
the
way
the
ethernet
is
pretty
much
the
moral
equivalent
of
the
dscp,
the
diffserf
field,
but
in
this
one
it's
really
as
as
rick
said,
it's
about
cue
identification,
which
is
a
little
different
than
about
link
identification.
H
In
particular,
we
we
might
have
multiple
dscps
or
multiple
priority
bits
that
map
to
the
same
queue,
and
you
don't
want
to
have
multiple
links
there.
Although
we
did
talk
about
the
notion
at
some
point,
rick
you
and
I
had
talked
about
that.
There's
really
a
need
for
an
extension
that
takes
into
account
the
sharing
of
resources
of
contention,
but
we
don't
have
that
today,
and
this
is
this
is
doing
it
not
for
the
channel,
but
for
the
the
the
router
sorry
the
modem
cues.
E
I
I
had
the
feeling,
when
I
saw
link
id,
that
it
was
just
an
arbitrary
way
to
split
some
what's
behind
the
mac
address,
so
I
must
admit
I
have
not
worked
on
the
flow
control
very
much,
because
we
had
quite
a
lot
of
issues
implementing
some
kind
of
prototype
and
without
testing
this
with
real
radios
and
routers.
It's
quite
difficult
to
get
a
good
opinion
on
the
draw
on
the
drafts.
E
A
B
Waiting
to
commence
so
just
for
record,
that's
not
what
I
was
going
to
say
at
all.
What
I
was
going
to
say
is
that
I
was
going
to
suggest
that
as
long
as
we've
got
this
stuff
moving
again,
we
should
get
before
you
sign
for
publication.
We
should
get
the
tsv
directorate
to
take
a
look
at
this
as
well,
so
that
we,
you
know,
get
all
the
not
all
the
I's
and
cross
all
the
t's
before
publication.
A
C
H
A
E
Some
comment:
I
was
not
talking
specifically
about
signaling
in
the
user
traffic
just
that
we
tried
to
implement
on
the
router
side
some
mechanism
to
stop
a
flow
until
our
router
side
of
the
dealer
protocol
says
you
are
allowed
to
send
another
100
bytes
and
we
found
no
good
solution
for
this.
This
whole
signaling
is
the
easy
part.
E
I
think,
with
complex
flow,
to
integrate
this
into
a
router,
that
we
have
control
over
the
single
flows
and
can
say:
let's
not
transmit
this
kind,
this
flow,
but
the
other
flow
is
allowed
to
transport
some
data.
This
is
a
problem
where
we
didn't
find
a
good
solution
within
the
existing
stuff
like
linux,
and
if
you
easily
do
this,
then
all
the
signaling
is
meaningless,
because
we
cannot
apply
it
on
the
router
side.
I
C
Very
quickly,
might
I
suggest
those
topics
are
being
tackled
in
the
raw
working
group,
which
is
it's
still
rooting
area,
but
it's
looking
at
extending
the
deterministic
networking
model
to
wireless
links
and
it
may
a
deterministic
is-
is
a
very
soft
concept.
Initially
it's
about
hardbound
latency,
but
it
some
of
the
techniques
being
worked
on
there
may
well
apply
to
just
trying
to
increase
stability,
for
whatever
you
mean
by
stability.
H
So
I
just
to
respond
to
headings
point.
I
agree
with
ronald
that
it
is
implementation,
it's
not
part
of
standards.
That
said,
you
know
the
pppoe
implementations
that
have
been
out
there
solve
this
problem.
At
worst
case.
You
could
take
that
similar
approach.
You
really
don't
want
to
come
up
with.
I
mean
they
used,
I
think
a
custom
linux
driver.
You
could
certainly
do
that.
That's
have
you
looked
into
that.
E
Coming
with
thinking
about
writing
a
custom
flow
discipline
to
allow
some
stopping,
there
are
ways
to
slow
down
a
flow,
but
just
with
some
bits
per
second,
but
not
about
this
mechanism.
That
says:
stop
this
one
and
continue
it
later,
so
maybe
wrecking
mark
linux
kernel
code
might
be
the
only
way
to
do
it.
H
H
F
E
E
E
E
E
So
I
have
three
three
drafts
at
the
moment
that
could
be
adopted
or
the
radio
band
draft
is
in
revision
2,
but
the
changes
between
revision,
0,
1
and
2
were
minor.
So
there
has
not
been
a
lot
of
added.
They
have
no
added
real
content,
just
some
details
and
wording
change
band
based
on
external
and
internal
feedback
and
two
other
drafts
next
slide.
E
The
radio
band
draft
is
just
about
telling
what
radio
frequency
resources
the
radio
is
using.
So
you
can
use
this
for
getting
some
kind
of
spectral
efficiency
for
a
metric
value
or
maybe
just
check
it
back
against
a
list
of
frequencies
that
are
good
to
use,
or
maybe
some
that
you
know
that
are
not
that
good
to
use,
because
there
has
been
report
of
some
jamming
from
other
devices.
E
E
So
we
could
use
a
request,
link
characteristic
method
to
reconfigure,
to
request
the
radio
to
change
its
its
frequency,
its
bandwidth
or
things
like
this
for
a
specific
neighbor
of
all
the
whole
interfaces
during
the
time
which
might
be
interesting
for
cognitive,
radio,
next
slide:
yeah,
okay,
yeah,
sorry,
yeah,
so
channel
utilization,
just
reports
what
the
channel
has
been
doing
over
time
in
july,
what
yeah.
So
that
was
one
one
too
much,
so
it's
just
about
what
has
happened
with
some
timer
counters.
E
That
start
at
an
arbitrary
point
and
go
go
off
to
infinity.
So
you
can
say
what
is
happening.
How
much
of
the
radio
channel
is
free?
How
much
have
you
been
transmitting
stuff?
How
much
have
ever
been
transmitting
stuff?
It's
something
that,
for
example,
the
linux
wi-fi
system
reports
for
some
drivers.
E
Next
one,
this
one
is
the
newest
one.
This
this
graph
gives
you
a
gives
the
radio
a
way
to
report
a
little
bit
more
about
the
current
quality
of
the
signal,
so
signal
or
lssi
signal
to
noise
ratio
or
something
like
the
bit
error
rate,
most
likely
based
on
some
simple
error
rate
below
it.
This
can
give
the
router
a
much
better
view.
E
What's
going
on
on
the
channel
before
we
start
losing
frames
on
the
transport
layer,
because
some
everything
might
be
perfect
on
the
transport
layer,
but
we
might
have
one
neighbor
that
is
on
the
brink
of
breaking
down
on
giving
us
the
first
packet
loss
and
another
one
that
has
a
huge
signal-to-noise
radio
left.
So
this
might
be
a
way
to
get
routing
metrics
to
change
the
path
before
we
lose
frames
and
packets
next
slide.
E
So
what's
next,
I
have
some
quite
quite
a
few
metrics
left
from
the
mac
bay
mac
layer
of
the
radio.
These
are
mostly
statistics
because
we
can
see
some
of
the
statistics
at
the
router
layer,
but
it's
a
little
bit
more
difficult
on
layer,
2
and
some
of
the
statistics
like
necessary
transmission,
lost
frames
and
stuff
like
this
are
just
invisible
for
the
router.
So
it
would
be
good
if
we
could
report
these
statistics
to
the
radio.
E
I
already
used
something
like
this,
for
example,
for
my
dat
metric
to
discover
if
I
need
to
send
probing
traffic
over
a
link.
If
there
are,
if
the
radio
tells
me
there
has
been
unicast
traffic
on
this
link,
then
I
don't
need
to
send
probing
traffic.
So
this
is
quite
useful.
There's
also
a
few
one,
two
or
maybe
three
drafts.
I
see
in
terms
of
radio
capabilities.
E
Just
something
simple
like:
can
this
radio
transmit
or
receive
multicast
traffic?
You
can
use
this
for
automatically
reconfigure
a
routing
protocol
to
adapt
to
situations
like
an
lte
system
where
the
base
station
normally
cannot
send
a
bro
a
multicast,
but
it
can
listen
to
the
multicast
of
the
clients
because
they
just
send
everything
through
a
layer,
2
pipe
and
don't
care
about
multicast
or
unicast
ip
support.
I'm
not
sure
about
this.
Is
it
may
be
interesting
for
radio
to
steal
the
router,
I'm
a
layer,
2
radio,
but
I
don't
do
ipv6.
E
So
it
might
be
interesting
for
the
router
to
know
that
the
router
should
apply
some
kind
of
tunneling
to
get
through
this
node
and
don't
waste
a
lot
of
effort
in
trying
to
establish
ipv6
link,
in
worst
case
the
ip
version
6
traffic
might
just
disrupt
the
radio
or
crash
it.
I
hope
not
today,
but
could
happen.
E
The
last
thing
which
we
I
have
been
using
is
something
I
call
service
discovery
a
way
for
the
router
to
discover
what
kind
of
cert
additional
local
services
the
radio
provides
eg
a
voice
over
ip
endpoint,
where
I
can
connect
to
a
voice
communication
channel.
What
we've
been
doing
there
is
just
that
the
router
can
provide
an
ip
port
combination
for
the
local
dns
service
or
the
radio
and
then
just
use
dns
based
service
discovery.
I
don't
want
to
reinvent
the
wheel
with
service
discovery,
so
this
is
just
bootstrapping.
E
C
C
C
E
Yeah
sure,
okay,
why
not
earlier?
Because
most
of
these
metrics
have
been
there
for
quite
some
time,
just
easy.
We
had
implementation
troubles,
getting
something
more
complicated
done
than
very
simple
metrics
and
doing
something
useful
with
it.
It's
similar
to
the
flow
to
the
flow
control.
I
think,
if
there,
if
it's
the
before
control,
there's
a
generic
difficulty
to
do
this
in
most
operation
systems-
and
in
this
case
it
was
our
implementation
starting
to
show
problems
with
edge
cases,
so
we're
at
the
moment
doing
a
re-implementation
to
resolve
these.
A
Sort
of
a
look
ahead
of
what's
what's
still
coming,
what
you
can
still
expect,
but
but
concentrating
on
the
three
five
related
drafts
for
now.
What
does
the
group
feel
that
we
should
do?
There
are
short
or
very
short
drafts?
Maybe
they
are
not.
They
can
be
fleshed
out
a
little
bit
more,
but
but
ultimately
should
we
keep
them
separate
or
or
immerse
them
help
us.
C
C
Are
these
logically
the
same
thing?
So
I
can
say
I
support
extension,
number,
seven,
radio
link
characteristics
or
whatever
you
want
to
call,
and
so
I
would
use
that
as
the
as
the
guide
for
whether
these
are
all
the
same
documents
or
not,
because
really,
I
believe
you
want
one
document
per
extension
type.
E
At
the
moment
there
are
three
different
extensions
because
I
felt
they
are
not
that
much
connected.
It
depends
highly
on
what
kind
of
radio
we
are
talking
about.
In
theory,
a
lot
of
radios
could
provide
all
of
them
the
signal
strength,
but
might
be
a
little
bit
different,
but
something
like
bit
error
rate,
but
some
radius
just
say
we
don't
have
these
values,
and
so
I'm
not
sure
if
it's
a
good
idea
to
merge
them
into
a
single
extension
point.
E
C
So
my
my
corollary,
point
to
one
extension
would
be
remember.
Supporting
an
extension
doesn't
mean
you
have
to
support
every
data
type
specified
in
that
extension.
So
you
could,
by
supporting
the
radio
information,
you
must
support
some
sort
of
link
quality
indicator,
but
the
rest
of
these
things
just
me
supporting
an
extension
means.
Your
implementation
is
not
going
to
terminate
the
session
when
it
receives
this
tlv.
E
C
D
B
Hi,
I'm
mother,
ruthanna
rodini,
so
two
points
one
is:
please
identify
yourselves.
I
know
I
didn't
do
it
last
time,
but
you
know
it's
never
too
late,
especially
today,
because
we
have
a
record
number
of
people
in
the
room.
It's
not
just
the
six
of
us,
but
we
got
what
26
right
now
yeah
as
far
as
emerging
or
not.
You
know
that's
up
to
to
you
guys
it's.
You
know.
It
makes
my
life
easier
if
there's
less
documents,
but
that
is
not
the
objective
here
right.
B
The
objective
is
to
produce
the
documents
that
work
for
in
this
case
the
the
people
who
are
going
to
go
implementing
these
things
and
whatever
is
is
better
for
them,
whether
they
can
and
sending
just
said,
indicate
specific
support
for
specific
functionality
by
just
pointing
at
one
rc.
For
example,
you
know
that's
fine.
If
we
need
to
produce
three,
we
will
we'll
do
three.
They
seem
to
be.
You
know
small
anyway,
so
that's
not
not
a
big
issue
at
all.
A
C
C
C
So
this
is
a
bit
of
a
sorry
to
stan
and
bo
who
have
missed
the
chance
to
complain
loudly
that
their
protocol
is
a
bit
a
bit
scruffy
in
places.
So
next
slide,
please
so
it
really.
We
split
this
into
four
main
issues.
Issue
number
one
there's
a
lack
of
clarity
on
metrics
I-
and
I
imagine
others
as
well,
who
are
seen
as
d-lab
experts
by
industry.
I
spent
quite
a
lot
of
my
time
on
the
phone
or
in
meetings
with
implementers
expanding
the
text
about
metrics.
C
C
There
is
an
errata
that
I've
known
about
for
a
little
while
I
felt
a
bit
guilty
about
raising
a
narata
against
the
document
for
which
I
was
an
author
was
really
hoping.
Somebody
else
would
raise
it,
they
didn't
so
I
just
did
the
text
around
peer.
Discovery
is
nonsense
and
needs
to
be
fixed.
The
errata
is
raised
check
it
for
details,
and
the
fourth
point
is
something
I
will
really
hand
over
to
luke
who's
right
about
which
is.
There
are
some
issues
with
transaction
handling.
C
The
transaction
text
is
okay,
but
if
you
follow
it
to
the
letter,
you
end
up
hanging
up
sessions.
Quite
a
lot.
Sorry,
you
end
up
hanging
up
sessions
when
you
really
don't
need
to
it's
simply
a
timing
problem.
The
messages
that
arrive
are
benign.
They've
just
got
out
of
order,
stop
tearing
down
as
soon
as
you
spot
your
control
plane's
gone
wrong.
C
You
terminate
the
session
and
therefore,
in
most
implementations
you,
you
tear
out
any
of
the
decisions
you've
made
based
on
what
you've
learned
from
dlab
from
your
data
plane
and
then
you're
disrupting
your
data
plane.
So
we'll
go
into
that
in
a
lot
more
detail.
Next
slide,
please
so
clarity
of
metrics.
There
are
three.
H
H
E
C
C
Four,
please
so
just
talk
about
the
metrics
briefly,
three
key
metrics
are
problems,
so
these
are
the
core
metrics,
so
the
maximum
data
rate.
It's
just
not
clear
to
implementers
that
this
is
the
maximum
theoretical
data
rate
on
a
link
given
the
current
configuration,
so
the
classic
example
being
80
to
11..
If
you're
in
mode
b,
your
maximum
data
rate
is
11
megabits
per
second,
your
current
data
rate
is
whatever's
happening
due
to
environmental
effects
and
channel
congestion,
etc,
etc.
But
your
theoretical
maximum
is
11..
C
That's
just
not
clear
enough
in
the
text.
Equally,
relative
link
quality.
Nobody
really
knows
what
it
means.
There's
a
lot
of
hand
waving
in
the
text
saying:
oh,
it's
a
sort
of
general
measure
number
between
one
and
a
hundred
and
and
yeah
it's
not
good
enough,
and
and
really
we
need
to
tighten
that
up
and
resources.
Also,
it
went
in
as
a
good
idea,
but
it's
a
bit
half-baked.
C
E
C
C
I,
I
think,
you're
good.
I
mean
okay,
fine,
so
there
is
particularly
with
ipv6
multicast
groups.
There
is
not
a
one-to-one
mapping
between
mac
address
and
ip
address,
so
and-
and
it
is
not
clear
in
the
text
that
if,
if
you're,
particularly
with
ipv6
multicast
groups,
you
need
to
include
the
actual
ip
address
data
item
as
part
of
your
multicast
destination
messaging
description,
particularly
your
ups,
etc.
C
It
does
raise
questions
of
how
is
that
learnt
and
how
is
that
updated?
So
we
really
need
to
think
about
that,
and
also
we
gloss
over
the
whole
ipv4
broadcast.
All
the
f's
mac
addresses
link
their
broadcast
capability,
we
sort
of
hand
wave
it
away
and
say:
oh,
it's
multicast
of
some
sort
and
that
just
needs
tightening
go
ahead.
Lou.
H
I
I
guess
I
really
should
have
looked
at
the
this.
The
final
set
of
slides
so
first
of
all,
this
is
lou
the
to
be
fair.
Rick
did
the
slides
this
morning
and
we
were
iterating
while
I
was
sharing
a
session.
So
I
really
do
appreciate
rick
putting
putting
something
together
here
so
on.
The
question
may
require
the
more
to
do.
Igmp
stooping,
I
actually
fully
disagree.
H
The
rfc
8175
appendix
c3
c3
says
that
the
the
modem
should
the
router
should
be
doing
destination
announces
and
that
the
modem
should
be
listening
to
those.
So
I
don't
think
any
snooping
is
required.
I
don't
think
any
protocol
awareness
is
needed
by
the
modem.
I
think
the
rfc
is
unambiguous,
that
you
know
the
router
should
do
destination
announces
for
the
multicast
groups,
that's
interested
in
so
okay.
I
finally
disagree
I
mean,
and
with
that
there
should
be
snooping
or
beer
or
pim
or
norm
or
whatever
stuff
going
on.
H
I
think
the
normative
text
does
say
this
is
typically
the
exact
text
wording
and
this
is
from
memory.
So
it's
bad
to
say,
exact.
My
memory
of
the
text
is
that
it
says
in
the
normative
part
that
this
is
typically
used.
The
destination
amounts
announced
message
is
typically
used
to
support
multicast
addresses,
so
the
normative
part
says
multicast
the
example.
The
informative
part
gives
an
example
of
what
is
meant
by
the
normative
part,
so
I
think
it's
completely
unambiguous.
Now.
H
That
said,
I'm
perfectly
happy
to
to
have
an
informative
document
on
it
that
that
that
goes
through
it,
particularly
on
the
up
and
update
side.
I
think
it
is
ambiguous,
what
happens
there,
and
that
was
the
the
discussion
of
the
105
presentation
of
whether
or
not
the
unicast
endpoints
are
identified
in
the
up
and
update,
and
I
think
that
is
a
good
subject
of
an
informative,
informative
document,
so
our
net,
the
the
end
result
is
the
same
as
what
you
said,
which
is
we
needed.
C
Because
the
the
fourth
point
is
the
big
one.
So
next
one
is
this
one.
Sorry
this
is
the
big
one,
so
the
transaction
sequencing
there's
a
section
in
there
in
rfc
8175,
which
goes
into
reasonable
detail
about
the
request
response
transaction
model.
Basically,
when
you
send
a
request,
if
you
get
a
message
which
is
not
your
response
about
the
destination,
this
is
scoped
by
the
destination
on
which
the
request
applies.
C
C
Because
of
time,
if
you
don't
mind,
there
are
two
or
more
classes,
and
we've
spelled
out
about
five
cases
where
this
can
happen
legitimately,
simply
because
of
timing,
because
requests
and
responses
can
be
initiated
by
either
the
modem
or
the
router,
depending
on
the
type
of
message
being
sent
and
the
time
it
wants
to
send
it.
You
can
have
a
router
asking
to
update
a
link
using,
for
example,
a
link
characteristics
request,
while
the
modem
announces
that
the
link
has
changed,
and
so
you
get
a
destination
update.
C
C
The
other
case
is
when
say:
igmp
snooping
is
happening
on
the
modem.
The
modem
detects
a
multicast
group
in
action.
The
router
says:
hey,
I'm
doing.
I
want
to
do
multicast
and
I
care
about
this
group.
They
both
send
a
message
to
each
other.
At
the
same
time,
saying
we
want
to
talk
about
this
new
destination,
so
the
response
to
each
of
their
messages
is
actually
the
other
ends
announced
not
the
corresponding
response.
They
were
expecting
both
ends.
Hang
up.
C
That's
it's
a
bit
of
a
dumb
threading
problem,
but
it's
if
you
follow
the
spec,
you
hang
up
and
you
don't
need
to
next
slide.
Please,
okay!
These
are
not
quite
the
latest
slides,
but
it's
absolutely
fine.
We've
got
three
or
four
more
examples
of
these,
but
they
are
of
the
same
class.
So
don't
worry
about
it.
How
do
we
fix
this?
There
are
some
ideas
on
how
to
fix
it.
C
The
key
point
is
that
all
the
fixed
ideas
that
lou
and
I
have
talked
about-
and,
of
course
this
needs
to
be
a
discussion
for
the
working
group.
None
of
them
need
a
change
to
the
d-let
protocol
itself.
It
just
needs
advice
and
clarification
to
implement
us
to
say
in
the
following
circumstances.
When
you've
got
a
timing
issue,
you
can
do
this
quite
safely,
which
is
slightly
beyond
what
it
says
in
the
base
document.
C
So
if
you
get
an
up
about
a
message,
you're
announcing,
then
that's
fine.
Both
ends
decided
at
the
same
time,
if
you
get
an
update
that
sort
of
coincides
when
you're
trying
to
change
it,
yeah,
that's
fine!
So
really
we
have
to
discuss
how
we
clearly
express
what's
fine
and
what's
not
to
to
handle
this
situation
without
a
breaking
backwards,
compatibility
and
interoperability
or
b,
preventing
forcing
every
extension
to
extend
the
list
of
what's
good
and
what's
not
in
a
sort
of
end
by
n.
C
Matrix
combination
of
good
and
bad
it'll
need
a
little
bit
of
careful
contemplation
by
the
working
group
to
work
out
a
nice
way
of
doing
it,
but
I
think
it's
doable
next
slide.
Please
yeah,
okay,
so
very
quickly
proposed
next
steps.
We
address
the
errata,
that's
a
no-brainer
lou
and
I
both
are
of
the
opinion
that
an
update
to
81.75
is
the
way
to
go,
not
as
not
a
best
document.
C
People
are
implementing
81.75.
Let's
not
change
the
rfc
number
on
them
that
will
result
in
in
fragmentation
and
just
general
people
will
throw
their
hands
in
the
air
and
say
I'm
not
doing
this
delap
thing
anymore.
The
ietf
have
broken
it.
So
let's
do
an
update
which
is
compatible
functionally
with
81.75
and
gives
fixes
and
clarifications
to
to
what
we've
mentioned
here.
The
end,
I
think
that's
my
last
slide.
Lou.
Do
you
want
to
add
anything,
I've
missed.
A
A
Six
minutes
left,
which
brings
me
to
the
agenda
because
there
I
had
the
slide
prepared
and
then
I
was
going
to
start
the
discussion,
but
I
don't
think
we
have
time
for
that
now.
So
maybe
it's
just
better
to
take
that
to
the
list
and
get
some
reactions
on
this
last
presentation.
Now,
if
you,
if
you
agree
with
that.
E
I
totally
agree
with
the
idea
that
we
don't
need
a
bs
document,
because
most
people
working
with
vlab
are
pushing
metric
data
so
most
at
least
most
people
I
have
talked
with.
They
are
doing
basic
implementations,
and
these
don't
have
most
of
these
problems
because
they
don't
care
about
all
these
optional
messages
that
can
get
from
the
other
side.
The
basic
delay
that
a
lot
of
people
are
working
on
is
a
radio
pushing
matrix
to
the
router.
C
H
Sure
so
this
would
be
proposed
standard.
An
update,
technically
is
something
that
an
implementer
of
a
base
document
should
go,
go
read
when
they're
doing
an
implementation
and
yeah
that's
a
subtlety
that
some
people
may
not
understand,
but
it
we're
not.
It
does.
An
update
also
should
not
change
the
base
protocol
operation
or
I'm
sorry
based
protocol
formats
and
we're
not
doing
that.
We're
just
changing
sort
of
some
of
the
error
case,
handling
and
airpath
handling.
A
K
Yes,
you'll
hear
me
now,
yes,
nice,
welcome.
Thank
you
regarding
the
philip
protocol.
I've
been
before
participating
regarding
this,
usually
before
I
remember
that
they
either
we
wanted
to
do
the
messaging
as
a
special
packet
messaging
of
mannet
or
a
message
which
is
simple,
simpler
for
the
lift
itself.
So
as
the
the
protocol.
K
81
75,
the
message
is
a
delayed
message:
it's
not
a
man
message
format,
so
I
suggest
maybe
the
hinting
innings
the
draft
that
if
we
are
looking
at
frequency
and
the
bands
and
all
the
more
metrics
that
is
more
little
complete
or
important
for
the
router.
Maybe
we
need
it.
It's
better
to
have
a
message
format,
which
is
the
same
message,
form
of
the
manner
rooting
protocol
that
we
already
standardized
and-
and
I
think
henning
already
he
knows
about.