►
From YouTube: IETF105-MANET-20190723-1710
Description
MANET meeting session at IETF105
2019/07/23 1710
https://datatracker.ietf.org/meeting/105/proceedings/
A
While
we're
thinking
about
all
this
and
still
not
quite
time,
to
get
started
yet
we're
gonna
mean
well,
it
is
it's
right
on
time.
We're
gonna
need
note,
takers
and
jabber
scribes.
So
who
would
like
to
to
volunteer?
We
only
have
a
small
group
to
to
choose
from
I
didn't
either
and
that's
why
I'm
having
trouble
downloading
these
or
uploading.
These
slide
sets
okay,
Oh.
B
C
A
A
A
A
A
A
B
Rick
take
a
quick
question:
I
know
with
the
credit
windowing
and
the
the
credit
extension
stuff.
There
was
some
debate
about
the
authorship
because
there
was
the
original
drafts
about
credit
windowing
that
were
part
of
deal
app,
then
got
removed
from
deal
app
and
the
diff
server.
Where
credit
when
doing
sort
of
brought
the
ideas
back.
Is
that
all
being
resolved?
Because
I
thought
there
was
some
question
that
will
got
fixed
I.
A
Ok!
So
that's
where
we're
at
on
the
document
status.
The
other
thing
that
I
again
I
profusely
apologized
for
I,
don't
have
slide
set.
For
is
the
note?
Well
the
please
note
that
this
meeting
is
covered
by
AI
ETFs
note
well,
so
take
that
into
consideration,
as
you
make
comments
at
the
mic
or
comments
over
jabber
than
it
is.
This
is
covered
by
the
denote
well
and
I.
Having
said
that,
I
think,
once
we're
ready,
I
think.
C
E
F
A
D
E
A
G
G
G
I
felt
a
little
more
comfortable
with
them
and
then
David
did
and
at
but
I
said
since
I've
I'm,
the
one
who
shows
up
here
that
I
would
ask
the
RFC
81-75
authors
what
they
thought,
but
we
also
didn't
want
to
bias
the
answer.
So
we
didn't
give
our
answers.
The
cool
thing
is,
we
came
up.
They
came
up
with
exactly
the
same
answers
that
we
came
up
with,
so
that
was
really
nice.
If
it
was
different,
would
have
been
okay
too.
G
I
do
think.
David
had
the
point
that
if
you
do
a
strict
reading
of
the
document,
it
doesn't
support
necessarily
everything
that
we
have
here
and
so
some
he
thinks
it's
important
to
get
the
clarification.
I
think
the
first
two
questions
are
they're,
not
100%,
clear,
but
I.
Think
the
intent
is
there.
So
I
think
we
could
do
that
with
an
errata.
The
last
one
is
definitely
not
clear:
I,
don't
I
think
is
beyond
the
intent
of
the
document,
but
it
also
turns
out
not
to
take
any
change
in
the
protocol
formats
to
support
it.
G
B
To
Kiev
errata
in
RFC
81-75
someone,
his
name
eludes
me
pointed
out
that
there
is
another
inconsistency
in
81-75.
There
are
two
sections
which
contradict
each
other.
I
suggested
he
raised
an
errata.
He
never
did
to
be
honest,
I'd
spotted
that
as
well
post-publication.
So
there
is
at
least
one
other
potential.
Well,
it
is
an
errata
I'll
raise
it
I,
see.
G
So
you
know
the
the
if
we're
gonna,
throw
it
together
document
that
gives
clarifications
to
the
document
as
well
as
how
to
cover
all
of
these
cases
might
as
well
do
that
in
one
so
a
lot
of
a
fourth
one
there.
So
this
is
really
the
overview
slide.
Now,
there's
a
bunch
of
detail.
The
next
slide.
Actually,
everything
in
the
micro
font
the
act
is
italicized
is
excerpts
from
the
RFC,
so
it's
just
taken
from
81-75
and
the
there
are
a
couple
of
things
that
I
think
are
really
interesting.
G
Here
there
is,
there
are
some
behaviors
that
are
pretty
clearly
defined.
So
that's
great.
So
that's
the
easy
part,
but
there's
some
things
that
you
have
to
go
and
interpret
like,
for
instance,
that
where
do
you
carry
a
multicast
address?
Well,
it
does
say
it's
a
logical
destination,
and
so
it
should
can
be
treated
as
a
destination
generally.
That
means
a
Mac
and
Mac
end
point
a
Mac
dead
station.
Well,
what
about
the
IP
addresses?
The
IP
addresses
are
carried
in
the
ipv4
and
ipv6
yeah,
but
we
know
B's.
G
B
Agree,
you
can
infer,
but
it's
not
stated.
Yes,
a
Rick
Taylor
again
it's
important,
and
this
is
why
the
deal
at
the
lead
draft
exists.
Is
that
fundamentally
didn't
RFC
81-75
deal
it
talks
about
a
destination
is
defined
by
its
lair
to
MAC
address
so
yeah.
You
can
have
traditional
broadcast
Macs
and
you
can
use
and
like
it
eludes
me,
what
specification
it
is.
The
encoding
of
multicast
addresses
with
the
multicast
Mac.
Oh
you,
I
yeah,.
D
G
G
G
Think
that
part
actually
would
qualify
as
an
errata,
as
we
really
meant
this,
and
you
can
read
it
that
way,
and
it
would
be
good
if
you
just
add
the
word
multicast
I,
don't
think,
there's
a
that
I,
don't
think
it's
a
major
change
and
that's
certainly
how
the
implementation,
that's
that
we're
referring
to
expects
it
to
be
used.
This
multicast,
even
David,
who
had
the
issue
saying
things
are
a
little
not
as
best
as
specific
as
they
should
be.
What
didn't
have
that
issue.
G
G
G
We're
gonna
have
to
do
something
anyway,
so
I
should
stop
my
proposal.
In
the
end,
when
I
get
there
is
I
was
trying
to
work
up
to
it,
so
I
should
just
skip
there
is
that
we
do
a
small
document
that
clarifies
all
these
points
and
one
and
it's
one
document,
I,
wouldn't
do
it
as
abyss.
I,
don't
think
it's
enough
of
a
whole
revision
of
the
protocol.
I,
don't
think
we
have
enough
experience
to
do
that.
Yet
I
would
do
it
as
a
small
document.
That's
lists
that
as
an
update
to
81-75
yeah.
A
G
Way,
we're
we're
gonna
end
up
in
the
same
point.
Is
we're
gonna?
Have
this
other
document
so
I?
Don't
think
we
to
spend
a
lot
of
time
on
it
and
you
know
having
if
we're
gonna
have.
That
document
might
as
well
put
everything
in
there
to
clarify
the
whole
situation,
because
then
people
don't
have
to
notice
how
many
places
they
go.
Look.
G
They
just
look
at
one
additional
place
and
we
do
an
update,
so
it
updates
so
that
any
175
Cisco
will
read
here
if
you're
going
to
implement
it
and
you're
done
and
it's
one
document
so
point
number
two
by
the
way
is,
would
be
I,
don't
know
an
errata
or
not
sorry,
I
guess
I
shouldn't
say
that
again,
the
point
number
two
is
really
fun.
So
it
says
a
modem
needs
to
expect.
Multicast
addresses
are
in
a
destination
up
request,
guess
what
there
isn't
a
destination
up
request
right.
G
So
I
do
have
a
comment
later
that
says:
oh,
we
interpret
this
to
mean
be
announced,
and
that
was
like
some
name
change
that
just
didn't
get
cleaned
up,
I'll
point
out
that
this
is
an
informational
text.
So
it's
not
really
that,
but
it's
not
a
problematic
except
you
have
to
infer
a
little
bit
of
what
goes
on.
B
G
G
G
G
So
anyway,
how
do
we
do
joins?
That's
the
most
basic
thing.
Destination
analysis
is
what
everyone
agrees
on.
We
read
that
that
was
the
intent
of
the
document
that
the
multicast
Mac
is
the
Mac
based
on
the
RFC.
You
were
just
talking
about
that
I.
Neither
of
us
remember
the
name,
but
in
the
number
excuse
me
that
says
if
you
have
an
IP
multicast
address,
how
you
map
it
into
a
multicast
MAC
address,
so
that's
that
MAC
address.
G
We
do
believe
you
want
to
have
a
multicast
address
list
because
there's
a
code
there's
the
way
that
mapping
works.
You
see
you
can
have
multiple
monthly
IP
multicast
addresses
map
into
the
singleton.
So
we
think
that's
a
list
and
by
the
way,
when
you
update
the
list,
I
put
the
comment
on
other
slides.
I've
missed
it
on
this
one.
This
is
a
list
that
is
a
complete
list
of
all
the
groups.
G
So
let's
say
you
had
group
a
and
B
that
map
to
the
same
MAC
address
and
you
join
with
a
and
you
now
want
to
add
B.
You
would
have
to
send
an
announced
with
a
and
B.
Now
let's
say
you
want
to
remove
a
you,
have
to
send
it
announce
with
just
B,
so
it's
sort
of
like
these
old
soft
state
protocols
and
that
you
had
well
and
I
JPS
off
this
state.
So
you
know
sort
of
makes
sense,
but
so
that's
that's
the
full
list
and
the
router
will
send
it's
complete
understanding.
F
I
G
B
Taylor
again,
I
don't
know
because
I
haven't
got
Dean
up
in
front
of
me
at
the
moment.
If
you
sent
an
announced
with
a
multicast
Mac
and
a
single
multicast
IP
address
and
then
sent
another
announced
with
the
same
multicast
Mac
and
a
different
multicast
single
address,
whether
the
modem
should
assume.
That
is
just
an
addition,
because
you
haven't
retracted
the
previous
idea.
B
G
G
Is
great
you
know,
I
did
the
slides
quickly
and
obviously
I
blew
that
so
I
mean
it
doesn't
change
the
slide
to
change
the
narrative.
Sorry
blue,
my
narrative,
slides
perfect,
just
like
just
like
the
RFC
right
anyway,
so
yeah.
So
that's
the
nice
thing
about
writing
a
new
document
is
we're
gonna,
be
very
methodical
about
it
and
make
sure
we
get
it
right
and
make
sure
all
the
details
are
there.
So
this
is
highlighting
that
we
need
that
I
think
you're
right
that
there
is
the
drop
already
in.
B
G
G
G
B
B
G
G
G
G
The
destination
up
is
identified
as
having
a
destination
address,
which
we
know
it's
this
case.
A
logical
one
is
what
the
spec
uses,
but
in
our
case
it's
the
multicast
Mac
and
then
there's
a
list
of
associated
IP
addresses,
it
doesn't
explicitly
say
multicast,
but
we
think
it
goes
there.
We
all
agree
that
that
was
the
intent
so
that
that's
pretty
clear
CJ.
J
G
Also
falls
out
of
intended
semantics
and
the
last
thing
we
have
is
the
station
down
and
here's
the
comment,
which
is
that's
only
when
the
final
listener
leaves.
So
that's
when
there's
no
one
out
there
on
the
far
side
and
again
this
is.
We
think
that
this
was
the
intent
reading
it
before
I
even
asked
the
question
of
the
authors.
We
thought
this
was
the
intent.
G
Okay,
so
that's,
but
this
one's
also
pretty
straightforward,
the
next
one's
more
interesting.
How
do
you
know
what
endpoints
are
reachable
because
you
sort
of
want
to
know
that
in
this
type
of
network?
It's
because
since
you're
on
an
RF
channel,
someone
might
be
move
so
distant
that
they
are
not
going
to
get
the
packet,
and
you
can't
assume
it's
like
broadcast
needy.
G
It's
you
can't
assume
it's
like
a
LAN
where,
just
because
one
person
is
joined,
everyone's
going
to
be
able
to
hear
you
and
which
is
part
of
a
basic
design
principle
and
IGMP,
any
version
we
need
would
probably
need
this
information.
How
do
we
do
it?
Well,
as
we
saw
before,
there's
the
IP
address
list
that
was
unqualified
in
both
of
the
up
as
an
update
and
I
added
the
qualification
that
it's
multicast.
G
It
doesn't
say
that
it's
just
this
list,
so
there's
no
reason
why
that
list
can't
be
first
ulti
cast
and
then
unicast
IP,
addresses
and
I.
Think
yeah,
Stan,
I
thought
you're
gonna
call
it
a
hack,
but
I
might
have
responded
this
as
pretty
hacky
or
you
might
have
responded.
This
is
pretty
high.
One
of
us
said
it
feels
a
little
hacky.
The
nice
thing
is
you
don't
have
to
change.
The
syntax
I
do
believe
is
a
change
in
semantics
and
an
unintended
one.
I.
G
Okay,
I'll
go
with
that,
it's
an
alligator,
you
know
you
know,
and
it
is
a
win
that
you
don't
have
to
go
change
your
encodings.
You
know,
but
I
do
think.
It's
a
change
in
code
and
I
actually
view
that
this
is
the
motive
everything
we've
talked
about.
This
is
the
most
significant
change,
even
though
it's
not
an
exchange
student
coding
on
the
wire
and
it's
such
a
change,
I
think
it
would
need
to
be
documented
and
go
through
the
normal
process.
I
It's
to
card
again,
I'm,
assuming
that
those
two
bullets
they're
on
destination
dump
and
destination
update,
are
intended
to
be
conceptually
clear,
as
opposed
to
intended
to
say
yeah.
This
is
what
the
parameter
list
is
really
going
to
look
like,
because
a
multicast
IP
address
is
distinguishable
from
a
unicast
IP
address,
so
there's
really
only
one
parameter
there,
which
is
an
IP
address
list,
correct
and
in
fact
that's
what's
in
the.
G
A
Just
want
to
make
a
comment
there,
and
this
is
staying
again.
If
we
do
that,
we
just
need
to
be
careful
of
the
destination.
Up
would
be
would
be
focused
on
one
multicast
IP
address
at
a
time
and
the
listeners
for
that
multicast
IP
address
otherwise
you're
going
to
introduce
some.
You
could
introduce
some
ordering
issues
inside
the
TLB
list
that
we
wanted
to
stay
away
from
III.
G
Know,
I
actually
don't
see
what
you're
talking
about
there
because
wait
as
the
as
the
previous
comment
said.
Sue
said
that
it
we
can
readily
identify
IP
multicast
from
unicast
and
there's
to
me,
there's
no
reason
why
you
can't
have
n
multicast
addresses
and
n
unicast
addresses
and
there
could
be
any
order
now.
There's
one
point
there:
subtlety
there
is
is
if
you
wanted
to
say
that
the
groups
had
different
sets
of
listeners
correct.
That
would
be
the
that
would
be
easy.
Do.
G
G
G
J
B
B
D
G
G
So
so
you
know
you're
a
router
right,
so
you
have
IGMP
de
host
and
you
may
have
IGMP
on
your
cell
net,
but
you're
running
PIM
or
bgp
stuff
or
other
magic
stuff
between
your
routers
right,
okay,
so
you're
just
trying
to
do
this
for
the
de
lip
subnet,
it's
exactly
for
the
deal
up.
Subnet
and
some
routing
protocols
need
to
know
what
the
listeners
are.
I
It's
two
again
and
it's
probably
foolish
for
someone
who
is
ill
prepared
as
me
to
be
speaking
as
much
as
I
am,
but
that's
awesome.
Thank
you.
Can
I
infer
from
what
you
said
a
few
minutes
ago
that
the
destination
up
and
destination
update
messages
may
propagate
to
different
groups
of
listeners,
depending
upon
which
multicast
group
we
are
talking
about
because,
okay.
G
G
They
avoid
I,
don't
know
what
happens
there,
but
though
that
information
propagates
it
now
property
across
the
air,
and
it
goes
to
other
radios
or
other
Moto's
next,
which
then
want
to
tell
they're
attached
routers
that
there's
a
possible
destination
that
they
can
send
to
there's
a
possible
Mac
destination.
That's
out
there
that
they
can
send
to,
and
that's
them
through
this
mechanism,
and
it
tells
you
which
MAC
addresses
and
which
IP
multicast
groups
are
available.
G
That's
what
this
is
doing,
but
it
doesn't
tell
you
those
endpoints.
It
just
says
these
groups
are
out
there
now,
let's
say
were
the
four
of
us
are
on
our
network
and
everyone
is
subscribed
to
this
one
group.
These
two
guys
are
the
first
two
guys
are
closer
to
me
left
and
right.
If
I
send
they're
gonna
hear
me,
but
you're
too
far
away.
You're,
not
gonna,
hear
me:
how
do
I,
how
do
how
does
my
I,
as
a
sending
router,
know
that
how
do
I
know
that?
G
G
So
I'm,
assuming
that
this
is
operating
inside
a
single
routing
domain,
a
single
control
domain
and
routing
protocols,
you
tend
to
push
around
the
information
of
you
know
at
least
who
your
next
hops
are.
Maybe
not
everyone
in
the
network
and
that's
what
that's
just
what
we're
doing
here
so
in
terms
of
privacy
I,
don't
think
the
privacy
is
any
different
than
the
routing
protocol
and
any
other
domain
in
terms
of
scalability.
G
This
is
has
different
scalability
properties
than
you
would
have
on
a
traditional
land,
but
I
think
the
problem
is,
is
you're
not
on
a
traditional
land,
and
so
your
protocols
are
designed
to
operate
on
artificial
land
and
make
assumptions
you're
they're
gonna
assume
that
there's
delivery
in
the
case
that
there's
not,
and
so
your
since
you're
dealing
with
this
I'll,
see
medium.
You
have
to
accommodate
it
and
that's
what
this
is
all
about.
This.
A
A
A
G
A
I
wouldn't
know,
I
was
just
gonna
say
that
that
seems
to
me
like
the
it's,
a
problem
that
has
to
be
solved
that
you,
the
sender
it's
kind
of
like
the
classic,
hidden
terminal
problem
right.
It's
not
your
problem
to
solve
it's
mine
and
Rick's
to
realize
that
students
back
there
and
he
can't
hear
so.
We've
got
to
propagate
forward.
G
K
B
For
the
benefit
of
microphone,
Rick
I
was
just
clarifying
to
Stu
that
the
privacy
issue
we're
kind
of
sidestepping
by
saying
deal.
It
talks
about
single
there,
two
domains,
so
it's
all
about
just
one
small
land.
This
information
isn't
propagating
out
over
some
extended
network
and
that
allows
us
to
kind
of
sidestep
those
previous
issues
he
raised.
G
G
Don't
know
what
Rick
was
saying
here
so
I,
don't
think
the
I
think
the
the
main
my
main
takeaway
from
here,
whether
it
was
Rick's
point
or
not,
is
is
that
when
you
say
multicast,
we
really
want
to
make
sure
we
include
broadcast
in
there
too
and
I
think
it's
a
couple
of
the
valid
point
and
I
completely
agree.
I,
don't
know
if
there
was
any
other
points
you
wanted
to
make
on
the
slide.
F
G
This
is
something
that's
come
up
a
couple
of
times,
I'm,
throwing
it
in
here
to
foster
discussion.
It
is
not
my
discussion,
so
I
don't
want
to
lead
it.
In
fact,
from
my
standpoint,
I'm
not
sure
I
care
about
this,
but
then
again
I
can
see
that
there
are
uses
of
him
and
you
know
I'm
a
dense
mode
fan
so
I'm,
not
a
sparse
mode
fan.
That's,
but
that's
why
I
said
I,
don't
care
about
it.
It's
not
that
I
don't
care
about
multicast,
but
I.
A
Know
this
is
Stan
again
I
mean.
Let
me
give
you
an
example
of,
at
least
in
my
case
where
this
started
and
that's
in
some
satellite
systems.
You
have
the
notion
of
what's
called
a
Network
Controller
node
for
the
satellite.
So
at
later
you
have
a
really
important
box
there
and
we
started
with
the
notion
the
really
vague
notion
of
try
to
communicate
the
fact
that,
from
a
layer
two
perspective,
this
modem
is
somehow
special.
A
It
has
capabilities
that
don't
necessarily
exist
elsewhere
in
the
network
for
the
network
controller,
it's
it's
pretty
obvious.
It's
you're
guaranteed.
They
have
in
a
satellite
network
anyway,
you're
guaranteed
to
have
connectivity
to
all
the
downstream
points,
and
then
we
kind
of
started
monkeying
around
with
different
use
cases
from
that
kind
of
flowed
from
that.
So
I
don't
know
that
this
is
actually
coalesced
as
an
idea,
but
it's
it's
one
that
we've
been
talking
about.
It's.
G
A
G
A
G
So
to
me
this
this
becomes
a
anyone.
Remember,
Ian
and
I
I
met
a
grouting
par
right.
This
is
like
par
where
you
could.
The
the
higher
level
could
inject
some
information
into
the
lower
level,
routing
protocol
or
lower
level
and
basically
provide
a
distribution
and
discovery
function,
so
you
could
advertise
some
bits
in
and
then
everyone
else
is
out.
There
learns
about
those
bits
without
you
exchanging
any
other
information,
so
I
mean.
B
Because
you
could
just
do
this,
okay,
so
one
of
my
use
cases
was
there
are
a
number
of
routing
protocols
and
data
dissemination
protocols
and
so
on
out
there,
which
you
have
a
leader
in
order
to
maintain
consensus
on
that
data.
So
you
have
a
leadership
election
and
you
go
read
the
papers
on
this
thing
and
it's
great
and
they
say
pick
the
node
at
the
lowest
node
ID
great
he'll,
be
the
he'll,
be
that
the
the
leader
today
when
he
finds
to
go
to
the
next
guy.
B
The
problem
is,
if
you're
running
on
some
of
these
mesh
radio
systems
or
a
hub
and
spokes
icon
system,
the
guy
with
the
lowest
node
ID
might
be
in
a
tunnel
and
clever
hidden
terminal
stuff
is
keeping
that
layer
going.
So
this
is
an
ability
for
the
modem
to
report
back
to
the
radio
to
say:
I
am
NOT
a
good
guy
to
be
elected
the
leader,
because
I'm
fighting
really
hard
to
even
stay
connected.
Please
don't
make
me
the
broadcast
point.
B
You
know
when
you're,
not
a
unicast
overlay
stuff
and
the
we
went
on
from
that
to
say
the
Reuter
being
able
to
suggest
to
the
modem
that
he
was
thinking
about
becoming
one
of
these
leaders
and
for
the
modem
to
be
able
to
say
no
I,
don't
think
that's
a
good
idea!
That's
the
item.
That
was
the
concept
we
were
playing
around
with
is
so
that
the
modem
can
say
in
the
view
you
have
at
layer
3.
That
seems
like
a
good
idea,
but
where
I
am
down
at
there
1
there
that's
a
bad
idea.
B
B
G
B
It's
because
it's
it's
a
yeah,
it's
I
have
good
bandwidth.
I
have
good
latency,
that's
fine,
because
the
climatic
environment
is
great,
we're
in
a
nice
clear,
sunny
day
and
we're
all
to
see
each
other,
which
was
we're
on
a
flat
plane.
It's
particularly
some
of
the
more
complex
meshing,
radio
systems,
they're
already
building
trees.
They
have
the
idea
of
you
know,
they're
doing
their
internal
tree
building
to
keep
the
RF
system
running.
B
A
A
A
G
All
right,
I
realize
we're
so
short,
so
I
think
the
outcome
from
this
the
takeaway
is.
We
should
work
on
the
document
on
the
four
topics.
This
one
is
as
if
as
a
separate
thing
that
Rick
and
Stan
will
run
run
with
and
I
think
at
least
Rick
wants
to
participate
in.
This
multiple
casts
clarifications
document
plan.
J
Romain
felt
I
work
for
Tino,
the
Netherlands
I
appreciate
being
given
the
time,
and
especially
now
that
we
are
in
the
middle
of
an
interesting
discussion
that
we
may
want
to
continue
at
some
other
time,
but
on
the
other.
On
the
other
end,
this
discussion
is
about
d-lab
and
it's
in
my
feelings,
training
more
and
farther
and
farther
away.
What
is
it
originally?
J
But
not
all
the
notes
within
M&A
have
to
have
this
extra
radio
modem
whatever
so
a
subset
has
this
and
that
can
be
used
to
form
some
kind
of
coalition
or
some
kind
of
Federation
of
monies,
and
then
they
need
to
be
able
to
exchange
routing
information
with
each
other.
If
a
note
from
one
money
is
ever
going
to
speak
to
a
note
in
another
money,
so
you
could
think
of
a
large-scale
disaster
recovery
operation
with
several
parties
involved
and
that's
the
usual
euphemism
I'm,
not
going
to
say
any
more
about
that
next.
H
G
Pascal
butchers
name
zone
said,
is
trying
to
get
at
with
the
whole
raw
and
pas
activity.
There
was
a
Boff
on
it
last
meeting.
He
didn't
give
his
boss
material
in
on
time.
So
it's
a
site
meeting
on
Thursday
morning
at
8:30
and
what
he's
talking
about
is,
is
he?
But
he
really
has
focused
on
that
net
over
wireless,
but
I
think
he
really
wants
this
yeah.
What
you're
talking
about
there?
Okay,
so
there's.
B
J
J
J
Typically,
in
the
wired
world
you
use
BGP
and
to
connect
autonomous
systems
and
the
autonomous
systems
are
running
a
GPS,
but
that's
not
very
suited.
There's
there's
ample
literature
about
how
PGP
is
not
going
to
work
in
a
managed
situation,
so
we
need
something
new
and
again
in
literature.
This
has
been
explored
to
some
extent,
but
there
are
no
usable
implementations
at
the
moment
and
most
of
the
papers
are
very
sketchy
about
how
to
exactly
do
it.
These
are
a
few
references.
B
J
B
B
K
B
B
J
B
B
The
cynic
in
me
would
say
that
if,
if
there's
a
non
working
group
forming
both
full
of
great
ideas
meeting
on
Thursday
morning-
and
they
have
sufficient
momentum
to
work
on
it-
and
it's
similar
to
this,
then
rather
than
forming
a
new
working
group-
isn't
that
a
bunch
of
active
participants
and
some
strong
ideas
that
could
reach
out
or
an
existing
working
group
and
bring
it
all
here.
Otherwise
we're
just
the
dealer
working
group.
Sorry.
G
C
G
Think
they're
I
think
their
ideas
are
very
interesting
and
they're
still
in
and
they're
still
in
development.
Their
mayor
very
much
focused
on
the
use
case,
which
is
a
little
different.
It's
not
general
teachability
days
traffic.
It's
it's
service
based
I,
do
think,
there's
a
role
for
you
up
in
there
and
there
may
be
a
role
for
bringing
these
things
together.
I
would
suggest
showing
up
there
and
hearing
what
they
have
to
say
and
telling
them
where
they
should
go
if
they're
confused
and
if
it
ends
up
here.
G
So
there's
a
lot
of
things.
I,
don't
think
this
is
a
decision
that
is
now
because
there
that
you
know
they're
gonna
have
a
bond
from
Singapore,
so
that'll
be
a
discussion
after
Singapore.
Now,
if
you
show
up,
you
can
understand,
maybe
help
form
their
ideas
a
little
bit
better
and
align
them
to
your
interests.
So
I
do
think
it's
worth
showing
up
there,
we'll
just
even
if
you're,
just
learning
and
definitely
the
AV.