►
From YouTube: IETF105-PIM-20190725-1330
Description
PIM meeting session at IETF105
2019/07/25 1330
https://datatracker.ietf.org/meeting/105/proceedings/
A
Yeah,
alright,
everyone
welcome
to
PIM.
Mike
could
not
be
here
today,
he's
helping
out
remotely.
Are
you
there
mark
Mike,
hello,
yep
yeah,
so
I'll
try
to
share
this,
but
Mike
will
jump
in
when
when
they
can
and
he'll
also
your
presentation
later,
so
this
is
our
yeah
actually
before
we
start,
we
need
a
minute
taker
and
one
willing
to
take
minutes.
You
don't
have
to
take
like
detailed
minutes
just
like
what
decisions
are
made
and
how
many
people
are
voting
for.
What,
when
we
have
to
do
any
worse
thing,.
A
Okay,
I
have
to
try
okay,
great
okay.
Thank
you.
I'll
try
to
take
notes,
while
you
are
with
something
so
okay,
thank
you,
that's
great
all
right!
Then
it
can
get
started.
So
this
is
the
note
well
that
you
should
all
have
seen
before,
and
we
did
if
you
haven't
also
send
out
the
pass
of
the
blue
sheets
here.
A
A
All
right,
let's
get
started
done
so
first
of
the
agenda,
is
Greg
I'm,
sorry
to
multi-point
BFD,
don't
wait!
Sorry
I
need
to
go
through
the
working
group
status
first,
then
they
will
start
on
the
presentations
all
right.
Let's
do
this,
so
we
have
a
lot
of
yang
models.
The
progress
is
a
little
bit
slow.
I
should
say
people
have
done
a
great
job
on
the
drafts,
with
your
little
slow
at
getting
them
published.
A
A
So
that's
the
PIM
draft
on
the
IGMP
MLB
Draft.
You
also
have
two
more
drafts
MSTP
and
our
MP
Emily
snipping
I
was
trying
to
get
them
published.
It
took
some
time
to
get
everyone
to
respond,
whether
they're
sending
IPR
and
stuff
like
that.
But
now
I
got
all
the
responses
on
either
so
IPR
anything
so
I'll
try
to
request
publishing
in
a
week
or
two.
A
Then
we
have
some
other
drafts.
We
have
dr
log
balancing
publication
was
requested
for
that
alvaro
or
ID
reviewed
that
and
had
a
good
amount
of
comments.
So
as
some
of
the
one
of
the
offers
I
will
try
to
address
the
comments
and
I
think
they're
just
minor
things,
but
if
there's
anything
bigger,
we'll
take
it
to
the
to
the
mailing
list
so
that
you
all
get
a
chance
to
see
what's
going
on.
And
if
you
agree
with
the
changes
that
are
being
considered.
A
There's
a
Java
before
prefix
or
ipv6
next
hop
that
has
been
stuck
forever
as
one
of
the
offers.
That's
mainly
my
fault.
Try
to
get
back
to
that.
This
is
a
dr
improvement
draft.
We
it
passed
working
group
last
call,
but
last
meeting
we
agreed
that
it
should
have
a
little
bit
of
text
explaining
why
this
is
different
from
the
other,
dr
draft,
that
we
have
been
discussing
in
the
working
group.
A
A
A
One
last
slide:
we
haven't
talked
about
this
in
a
little
while
apart,
maybe
bring
it
up
again
now,
so
we
talked
a
little
bit
a
couple
of
meetings
ago
about
implementation
requirements
and
how
different
working
groups
have
different
requirements,
and
we
haven't
really
had
any
requirements
of
all
in
this
working
group
and
yeah.
We
talked
about
this
a
little
bit,
and
at
least
my
feeling
is
that
we
are
fairly
happy
about
that.
A
A
D
D
D
Do
multiplex
give
these
sessions
based
on
its
local
discriminator
value,
which
is
in
packet
placed
in
a
euro
discriminator
field
in
point-to-multipoint
BMD.
If
this
session
or
the
state
machine
has
changed
and
it
immediately
progresses,
actually
it
starts
from
the
Upstate
from
the
point
of
view
of
the
head
end
and
head
and
periodically
transmits
PFD
control
packets
with
the
euro
discriminator
field
of
zero,
so
multi-point
tails
cannot
different.
The
multiplex
different
DVD
sessions
are
based
on
your
discriminator
field.
D
D
That
gr
must
include
beef
DTO
v
in
its
team,
hello
message
and
the
TV
must
be
included
after
they
are
addressed.
Govt
and
BTR
is
recommended.
So
basically
recommended
is
identical
to
shoot,
to
include
b
FD
t
le
in
PM
holo-message
and,
if
included,
if
to
be
included,
then
it
must
follow
after
BTR
address
tod.
F
F
D
F
G
F
Okay,
so
again,
it
is
not
completely
clear
to
everyone
what
updates
means,
and
in
general,
what
most
people
use
it
for
is
for
an
actual
formal
update
to
the
updated
RFC.
So
what
it
usually
means
is
that,
if
I'm
updating
the
pinyin
specification,
I'm
actually
saying
this
should
be
there
with
the
intent
that,
if
I'm
implementing
that
they
spin
the
specification
I
have
to
do
this
again.
This
optional,
then
that
probably
shouldn't
be
there
yeah.
F
Go
into
the
story
of
ICS
process,
it's
not
clear,
and
so
there's
been
some
discussion
in
the
eighties.
You
have
lists
that
I'm
sure
all
of
you
have
enjoyed
about
what
this
updates
really
means.
There
is
a
new
proposal
that
we
are
putting
together.
That
probably
will
be
a
draft
release
next
week.
There
actually
is
going
to
get
rid
of
updates
so
that
it's
actually
clear
and
so
there's
going
to
be
a
new
tag
that
says
I
think
the
name
is
something
like
immense
or
something
like
that,
where
it
actually
means
this
is
a
change.
F
F
F
So
that's
how
you
do
it
something
optional,
you're,
extending
the
protocol
you're,
adding
something
new
or
whatever,
and
so
we
it
is
useful
to
be
able
to
tie
those
two
together
right
so
that,
if
you're
doing
the
base
expect,
maybe
you
want
to
see
what
other
things
are
extensions,
so
you
can
do
that
and
then
there's
a
third
one
which
I
think
it's
going
to
be
called
something
like
see
also
or
something
so
that
you're
saying
well.
This
is
not
an
extension.
F
F
F
Then
you
would
do
that
for
the
other
normal
cases
of
your
change
in
the
registries,
for
example,
you
define
some
registries,
you
not
actually
changing
the
protocol,
but
you
just
find
some
registers
registries
through
a
in
it
and
now
you're
changing
those
registries,
not
assigning
a
new
clones,
but
now
you're,
saying
instead
of
using
specification
required
I
now
want
to
use
ATF
review
or
whatever
then
there's
a
change.
It's
not
change
to
the
protocol,
but
it
change
to
the
I.
A
A
Honoring,
it
is
a
working
group
draft.
Yes,
I
have
a
more
important
technical
comment.
Oh
so
you
are
saying
on
this
slide
here
right
that
the
deed
that
be
F,
DT
L.
We
must
come
after
the
other,
yes
and
I
would
say
in
general.
Today
we
don't
have
any
requirements
on
ordering
for
hello
options
and
I
think
many
implementations
just
kind
of
parse,
all
of
them.
First
mm-hmm.
H
D
A
Then
I
have
one
more
comment,
though
there
are
implementations
today
using
EFT,
regular
point-to-point
BFD
with
him
mmm-hmm,
for
you
know
quickly
find
out
that
the
dr
has
gone
away.
So
I
feel,
like
you
know
what
is
in
this
draft
is
useful,
also
in
the
pennant
of
the
dr
increment
draft,
so
I
think
at
least
my
opinion
is
that
it
will
be
good
to
allow
people
to
use
this
hello
option
also
with
regardless.
So
dr
improvement.
A
D
A
D
Yes
and
that's,
I
think
that
we'll
probably
have
this
discussion
later
during
the
meeting,
because
I
read
their
other
draft
and
I
have
couple
questions
about
it,
so
how
to
work
and
because
their
procedure
is
a
little
bit
different
from
the
procedure
and
then
the
question
is
since
there
is
no
explicit
advertisement
of
dr
address
and
v
dr
address.
So
if
how
it
will
be
interpreted,
BF
d
TLV,
I
need
to
might
be
discuss
it
with
offers
of
that
other
draft.
So
at.
D
B
A
D
A
A
E
I
Colossal,
no
everyone,
my
name
is
Hong
ji
I
am
from
erikson.
Now
let
me
introduce,
let
me
introduce
some
updates
about
the
IGMP
Amardeep
rousey
yamato.
I
I
Just
update
one,
we
obtains
a
constraint
to
make
sure
the
upstream
interface
for
our
MV
MLD
policy
should
not
be
configured
pimp
in
the
old
version.
We
have
already
higher
this
constraint,
but
it
has
some
limitation
in
this.
In
the
current
version,
we
have
solved
this
limitation
with
the
not
function
in
the
as
pass
and
they
true,
we
have
added
the
fever.
Fisher
I
gem
he
foxy
to
make
the
implementation
more
flexible.
I
I
I
I
There
is
still
some
s
all
comments.
Mahima
is
the
author
of
the
RC
is
1
&
4,
hey
thinks
that
the
IGMP
prossimo
do
for
the
pic.
Take
a
call
me
into
a
gmpm
early
interworking
function
in
RFC
is
1
1
for
FC
8
1
for
provide
a
solution
for
the
ipv4
multicast
service
to
the
ipv4
multicast
clients
through
the
ipv6
multicast
networks,
this
new
function
it
combines
the
EMP
policy
function
and
the
address
synthesizing
operations.
I
A
Yeah
so
I
guess
I
have
a
comment
on
the
80
114
support.
I,
don't
have
a
strong
feeling
either
way,
but
I'm
not
sure
how
many
implementations
there
are
all
that
and
I
guess
the
yang
mellows
most
attractive,
or
should
they
address
the
things
that
that
most
implementations
have
implemented
right
but
but
yeah
I?
Guess,
there's
yeah
we're
just
talking
about
that
adoption
now.
So
we
have
time
to
discuss
that
further.
Okay,
okay,
so
I
think
okay.
G
Well,
I
mean
yeah.
If
somebody
like
Mohammed
has
opinions
about
the
adoption,
if
it's
inclusive
of
theta
or
not
I
would
say
you
know
if
there
is
a
proposal,
how
it
should
be
done.
That
makes
it
clear
that
if
you
don't
implement
that
function,
there
is
no
problem
to
express
that
in
the
model
and
it
would
otherwise
work.
I
think
it
could
well
be
in
scope
right.
A
It'll
be
good
to
know
more
understand
better
about
this
involved.
Yeah,
so
I
think
we
we
Morris
agree.
Yeah
I
think
they
agreed
last
meeting
last
ITF
meeting
to
do
an
adoption
call
I'm,
not
sure
about
that,
but
I
think
we
did
that,
but
they
never
actually
did
the
adoption
call
sorry
about
that
are
people.
Finally,
the
stealing
another
adoption
call
on
the
list.
A
So
I
know
not
that
many
people
read
the
yang
model
drafts
unfortunately,
but
can
I
see
how
many
people
have
read
this
draft
yeah?
It's
just
a
couple
of
people
at
least
one
of
them
is
one
of
the
authors
but
yeah.
Unless
people
have
any
strong
feelings,
either
way
against
or
in
in
the
favored
adoption.
I
think
well,
I'll.
Just
do
an
adoption
call
on
the
list
and
see
what
people
think
we
have
at
least
support
from
five
different
vendors.
It
seems
so
that's
pretty
good.
J
So
the
draft
had
been
presented
in
multiple
ideas
before
so
so
in
a
nutshell,
the
draft
speaks
about
how
to
pack
null
registers
in
a
single
message
whenever
possible.
So
there
are
a
couple
of
additions
were
done
before
in
the
prog
ietf,
but
after
that
there's
demo
additions.
So
we
are
looking
like
I
said
ready
for
last
group
call.
A
Yeah,
so
how
many
people
read
this
draft?
It
hasn't
changed
in
and
I'm
on,
ITF
so
can
I
see
if
you
read
this
draft
before
the
previous
ITF.
For
since
that
one
person,
two
people
read
it
three
people,
okay,.
A
A
A
J
Yeah,
so
this
traffic
box
talks
about
how
to
distribute
the
user
configured
SSN
ranges
in
an
l2
Network,
so
this
is
necessary
because
not
have
consistent,
as
is
some
operation,
so
the
starchy,
v2
or
v3
joins
for
the
elements
need
to
be
discarded
by
the
routers
and
the
switches.
So
if
it
doesn't
discard
those
groups
starts
cooperating
in
veto
compatible
mode.
So
what
happens
is
if
you
get
a
leave
for
those
groups
and
the
router
may
send
a
v2
query
to
the
horse,
so
the
SSM
hosts.
J
So
the
SLM
host
will
think
that
the
router
is
operating
in
a
v2
mode
and
it
will
downgrade
itself
to
the
way
to
operation.
So
the
SSM
hosts
will
fail
in
will
fail,
so
they
no
longer
send
the
viiiage
joins.
So
the
draft
proposes
to
distribute
the
SSM
ranges
in
a
film
hello
option
so
that
the
l2
switches
can
learn
about
this
user
configured,
SSM
ranges
and
draft
the
reports
for
the
v2
groups.
J
K
Jennifer
is
this
assuming
that
the
SSM
range
that
has
been
configured
for
something
other
than
230
2/8
yeah.
K
J
Don't
know
I
bought
that
like
so
there
are
most
of
the
users
use
the
232
range,
but
there
are.
There
is
a
possibility
of
customers
using
to
that
user
configured
range
or
the
network
when
you
can
specify
in
the
host
stack
as
well.
So
they
want
to
use
this
as
a
sim
range,
so
I've
seen
few
customers
using
it
and
I've
seen
one
of
the
customer
running
into
this
problem,
where
the
esses
impose
were
stopped
working
after
it.
L
Needs
spin
for
Deutsche
Telekom
Lenny
to
your
question:
there's
actually
a
good
reason
for
using
a
different
range
than
in
SSM
32
range,
which
is
due
to
a
strange
behavior
in
the
linux
kernel.
So
if
you
have
a
device
on
your
home
network
which
sends
out
an
IP
version,
2
message
and
govern
IGMP
version,
3
s
sm
device
also
on
there
it
for
its
specs,
sometimes
to
IGMP
version
3
with
a
SM.
L
G
Tell
us
Eckert
I
think
that
there
is
a
good
reason
why
we
have
administrative
scope,
multicast
and
company
video
announcement,
where
the
boss
tells
all
the
secrets
only
to
the
employees
right
so
I
don't
want
to
have
SM
not
be
able
to
do
that.
I
know.
I
know
we
should
all
stop
using
ipv4
completely
and
go
to
v6
where
the
problem
solved,
because
we
have
all
the
administrative
scopes,
but
for
the
few
billions
of
us
left
that
you
know
operate
on
before
addresses.
At
least
this
has
been
given
out.
G
You
know
to
39.2
32
as
a
recommendation
to
configure
forever.
I
I've
seen
a
lot
of
networks
that
just
have
also
their
to
only
that
don't
even
have
layer,
3
large
switch
networks
right
three
tiers
broadband
aggregation
networks.
You
may
not
even
have
a
pin
router,
so
I
strongly
suggest
to
figure
out.
If
you
cannot
also
do
that
as
an
IP
extension
yeah.
So.
J
A
Some
I'm
a
quaver
all
the
drafts,
speaking
as
an
offer
I
believe
our
people
doing
SSM
inside
239
because
they
want
to
do
sculpt
as
a
semi
that
it
it's
not
leaking
outside
their
domain,
which
is
yeah
pretty
much.
What
Tyler
said
I
wonder
a
bit
if
it
would
be
useful
in
maybe
I'm
buddy
I
know
to
have
some
draft
or
like
operational
issues
to
the
SSM.
Deploying
SSM
and
pleased
is
this
I
know,
but
at
least
is
this.
A
This
fallback
is
one
of
those
issues
and
one
problem
are
seen
is
in
the
our
GPS
back.
It
says
you
should
fall
back
to
star
G,
but
then
you
have
the
s
of
this
SSM
draft.
That
says
you
should
must
not
or
should
not
fall
back,
but
if
we
are
implemented
idmp
draft
and
not
sort
of
the
SSM
draft,
you
might
claim
your
compliance.
This.
G
G
This
can
all
be
in
one
document:
yeah
take
off
load
from
the
ITF,
just
have
a
single
document.
That
also
has
a
paragraph
on
the
operational
reason
why
we
need
this
right,
so
I
think
we've
often
enough
run
into
you,
know,
legacy
receivers
that
are
just
sending
the
group
address
and
then,
basically,
all
the
SSM
receivers
are
screwed
right.
G
A
A
Yeah
I
would
say.
Please
read
the
draft.
Please
comment
on
on
the
list.
If
you
have
any
questions
and
it's
one
of
the
offers
yeah,
we
offer
to
also
try
to
start
a
thread
on
a
mailing
list
and
get
some
input
and
hopefully
by
next
ITF.
Several
people
will
be
familiar
with
this
and
we
can
see
how
to
proceed.
J
C
Okay,
so
this
draft
is
something
that
how
you
and
I
put
together
to
specify
requirements
of
on
path
telemetry
for
multicast
traffic.
There
are
a
few
telemetry
solutions
out
there,
such
as
I
am
and
PBT
that
are
being
worked
on
in
the
AI
ppm
working
group,
and
we
see
that
there's
a
seems
to
be
a
lacking
of
support
for
multicast
to
traffic
in
that
kind
of
an
environment.
So
we
put
this
together.
We
are
presenting
it
here,
just
kind
of
to
socialize
it
and
next
ITF.
C
We
will
likely
ask
for
time,
which
is
limited
in
the
AI
ppm
working
group,
but
being
that
this
group
is
multicast
of
experts-
and
maybe
you
have
already
thought
about
this-
that
maybe
you
have
some
solutions-
I
know,
Greg,
mirskiy
and
others
are
involved
in
AI
ppm
work.
So
maybe
maybe
this
is
something
that's
been
discussed
and
also
part
of
the
background.
C
D
D
Its
RFC
8321
to
beer,
because
alternate
marking
method
can
be
not
on,
can
use,
be
not
only
important
to
point
packet
to
us
and
delay
measurement,
but
in
point-to-multipoint
the
author's
working
on
multiple
draft,
basically,
which
is
the
to
impede
scenario
in
Peter
Peter
to
MP,
2
MP,
but
RFC
8321
is
applicable
and
we
have
a
document
in
here
which
explains
how
it's
used
and
what
what
it
gives.
So
we
can
definitely
look
at
more
generic
scenario,
how
it
can
be
done
in
general,
multicast,
okay,.
C
C
Okay,
yes,
so
the
current
on
path,
telemetry
techniques-
do
have
some
flaws,
at
least
for
multicast
with
I.
Am
every
packet
carries
the
entire
trace
data,
so
there's
a
lot
of
data
redundancy
and
with
PBT
post
card
based
trees,
there's
no
branch
identifiers.
So
it's
you
can't
correlate
the
postcards
and
so
we're
trying
to
produce
a
solution
that
addresses
these.
These
issues
great.
D
D
What
hybrid
two-step
does
is
it
uses
the
trigger
to
do
measurement
and
then
measurement
packets
are
transported
as
a
follow-up
packet
collecting
measurements
because
they
share
the
same
encapsulation
as
the
packet
that
triggered
the
measurement,
so
that
might
be
interesting,
I
haven't
actually
I,
I,
admit,
I,
haven't
thought
about
using
this
method
and
what
it
will
result
for
the
multicast,
but
it
will
be
very
interesting
to
discuss
that
too.
Thank
you.
Okay,
hybrid
two-step,
okay,.
C
C
And
then
so,
there's
a
per
section
postcard
example
as
well
and
and
another
proposed
solution-
is
that
a
section
is
the
path
between
two
adjacent
branch
nodes
or
between
a
branch
node
and
it's
leaf.
Node
and
then
a
postcard
is
sent
at
each
sections
and
node,
and
that
postcard
contains
data
for
the
entire
section,
and
they
these
postcards
for
a
packet
can
be
stitched
together
and
there's
no
need
to
I
get
modify
any
IOM
header
format.
C
We
just
need
to
refresh
the
header
at
each
section
head
and
send
that
information
up
to
a
telemetry
collector,
so
these
are
again
details
that
can
be
hashed
out
more
in
the
I
ppm
working
group.
If
you
go
to
the
next
slide,
the
last
slide.
Yes,
so
this
is
really
the
only
thing
that
we're
asking
is
just
to
review.
This
you're
welcome
to
contribute.
I
already
know
one
grade
that
we're
gonna
reach
out
to
discuss
this
further
and
we're
not
going
to
be
asking
anything
of
PIM,
and
this
will
not
be
a
document.
A
So
yeah
yeah
I
read
this
myself
by
the
way,
and
so
the
main
reason
for
the
postcards
is
basically
so
you
don't
need
to
send
any
additional
data
in
the
data
packet
downstream
right
right,
yeah.
C
A
A
B
M
M
Packet
campus
in
the
two
it's
directly
collected,
the
labor
and
the
packet
won't
go
back
to
the
router
itself,
so
in
this
Ringo
Oh
topology
are
force
in
their
packet
to
r3,
and
the
target
are
true:
it
can
issue
a
that.
Are
three
won't
go
back
to
our
four,
so
Marika's
can
also
use
this
feature.
It
is
described
in
the
FC,
74
31
and
then
Yoli
cast
had
advanced
the
LFA
to
remote
Arif
way.
M
M
Cannot
ensure
the
Kannada
issue
as
a
loop
free,
for
example,
our
file
send
a
packet
to
r4
and
the
target
are
two:
then
the
packet
will
go
back
to
our
file.
So
in
this
example,
the
RFA
algorithm
will
have
to
calculate
remote
point
R
3,
so
our
5
send
it
to
R
3
and
the
target
are
true.
Then
it
will
not
want
to
go
loop.
M
M
M
But
the
problem
is
that
sorry,
I
missed
some
background
in
the
in
the
MOF
are
there
is
a
pin
vector
attribute,
concur
in
the
explicit
point
that
a
pin
joint
can
can
go
through.
So
in
this
example,
are
six
can
add
that
attribute
of
r4
and
r3
and
tend
to
establish
the
backup
path.
But
here
the
the
problem
is
that
when
even
between
r4
and
r3,
there
are
four.
M
So
the
solution
way
proposes
is
that
we
add
a
team
actor
actor
appointed
out
there
interface
from
individual
to
in
the
fist
to,
and
then
they
are
for
get
this
vector
and
can
no,
no
that
it
don't
need
to
send
the
team
joy
across.
The
short
short
is
the
pass,
but
through
the
vector
carrying
in
the
packet.
M
M
We
propose
a
lil
pimp,
vector
attribute
to
the
AF
F.
It
will
be
0
repeat
or
your
indicates.
The
last
joint
attribute
the
value
it's
the
unicast
address
of
that
direct
directly
collected
labor
and
the
type
the
type
tells
that
tells
the
rotor
not
to
use
the
normal
RPF
RPF
interface,
but
use
their
in
the
face.
M
A
Have
one
comment
so
for
this
extension
you
specify
your
own
interface
address
and
the
neighbors
address
to
uniquely
think
uniquely
identify
this
segment
right.
There
is
an
existing
RFC
for
route,
an
interface
identifier,
pin
hello
option
that
can
be
used
to
also
uniquely
identify
an
interface
on
a
router.
So
wonder
if
maybe
that
could
be
helpful
so
hard
to
explain
here,
but
basically
the
way
that
hello
option
works
is
that
a
router
can
announce
say
a
new
pack
address
or
something
plus
also
a
unique
ID
for
each
of
its
interfaces.
A
So
for
a
given
router
on
each
of
your
interfaces
very
soon
up
in
hello,
we
will
announce
the
different
identifiers,
but
yeah
I,
don't
know
if
it
helps
or
not,
but
at
least
that
suggests
just
thinking
about
it.
I
can
send
you
an
email
with
the
RFC
number
issue.
A
thank
you.
Thank
you.
Okay,
any
other
comments.
N
N
A
B
E
Yeah
so
busy
to
set
some
background,
so
the
idea
is
Stig
and
sent
an
email
to
the
list.
I
guess
a
few
months
ago
saying
that
the
working
group
wants
to
move
IGMP,
v3
and
MLD
v2
to
fill
standards
and
looking
for
some
volunteers.
They
can
all
help
with
this
work.
So
the
idea
is
before
we
can
do
that.
We
need
to
follow
the
IETF
process
and
two
big
things
we
have
to
try
to
do.
One
is
to
determine
what
features
and
heiresses
are
not
widely
used.
E
Okay
and
then
also
to
figure
if
there
are
any
kind
of
interrupt
issues
that
arisen
from
these
two
protocols
and
there
is-
and
these
the
the
answer
to
these
questions
will
kind
of
inform
how
the
working
group
what
the
working
group
does
going
forward.
So
how
should
we
answer
these
questions?
Well,
there
was
a
similar
process
character
for
sparse
mode,
half
a
while
back.
So
the
suggestion
from
the
chairs
was
to
use
that
approach,
which
is
basically
to
do
a
survey
of
the
community.
E
So
sorry,
vendors
and
operators
and
ask
them
questions
to
help
us
try
to
answer
this
to
bake
questions.
So
there's
a
team
assembled
and
the
authors
are
Cannella,
so
at
this
time
we've
been
kinda
having
regular
meetings,
I
guess
already
a
few
months
and
we've
created
a
draft
of
the
survey
which
is
listed
there,
and
so
that's
like
in
the
background.
E
So
the
survey
like
I
was
seen
is
gonna,
be
targeted,
our
operators
and
vendors,
and
also
because
IGMP
because
of
iterative
protocol
yourself
to
maybe
try
to
get
some
post
implementers
to
can
help
answer.
The
questions
like
I
said
the
questions
are
in
the
draft
would
be
really
good
to
have
a
look
at
that
to
have
some
kind
of
feedback
from
you
guys
and
then
the
results
will
be
kept
confidential,
so
we'll
just
do
exact
same
process
like
was
done
for
pen,
sparse
mode,
okay,
so
next
steps,
please
review
the
questions.
E
I've
said
that
thought
type
and
also
carbs
is
one
kind
of
open
issue
that
we've
not
quite
resolved,
and
it's
what
to
do
about
features?
Okay,
so
should
we
all,
should
we
the
less
features
at
all
or
should
we
list
features
only
in
the
RFC's?
Okay,
because
the
idea
is
there
are.
If
you
ask
people
tell
me
some
IGMP
v3
features
that
you
use.
They
may
actually
see
some
features,
I
know
in
RFC,
so
I
should
we
can
resolve
that.
So
that's
maybe
one
thing
that
we're
kind
of
looking
for
some
input
about.
E
K
So
our
GMP,
an
emerald
RGB
v3
and
M
LDV
to
have
lots
of
stuff
in
them
and
a
lot
of
stuff
that
nobody
ever
did
it
never
never
implemented
or
use
lightweight.
Igmp
v3
in
MLD
v2
was
a
spec
that
was
written
kind
of
as
a
response
to
that.
What?
If
what
if
we
discover
that
lightweight
IGMP
and
MLD
is
more
accurate,
is
a
more
accurate
state
of
deployment?
E
G
Eckert
CSI,
the
initials
when
we
started
out
there
were
questions
and
I
haven't
been
able
to
catch
up
with
the
latest
date
of
this
for
the
last
two
a
month
and
I'm
kind
of
thinking
that
you
know
at
some
point
in
time.
My
function
of
is
something
ripe
enough
or
not
is
also.
There
is
a
time
factor,
II
said
somewhat
hamon
to
say:
go
forward,
minutes
distributed,
but
I'll
certainly
do
another
run
through
it
yeah.
G
There
was
also
when,
when
we
started
this
one
of
the
interesting
question
and
that's
why
there
was
specifically
the
question
there
about
execute
note,
you
know
membership
reports
of
anybody
using
them,
even
at
the
risk
that
a
good
population
will
ask
our
what
what
is
this,
which
typically
would
mean
no
so
exactly
to
figure
out
if
we
could
reduce
ourselves
to
the
lightweight
model
as
the
future
standard,
at
least
from
the
requirements
perspective
right.
So
I
think
there
is
this
other
round
that
we
need
to
do
which
is.
G
K
K
G
Yes,
I
I
know
a
lot
of
people
won't
understand
it,
but
what's
what's
the
best
question,
how
we
can
come
to
the
conclusion
that
I
think
you
and
I
want
so
please
review
the
question
say
that
let's
get
it
out
that
it
has
all
the
important
things
you
think
need
to
be
in
there
and
cutting
down
the
software
afterwards,
that's
after
we
get
the
feedback.
That's
all.
K
G
A
Just
joking
yeah,
so
the
way
I
see
it
is,
you
know
the
the
RFC
might
have
multiple
features
exclude
mode
is
just
one
of
them
and
there
might
be
many
small
details
like
fallback,
unique
house
messages
or
other
things,
and
every
every
one
of
those
different
things.
You
should
ideally
get
some
input,
people
are
using
them
or
not,
and
then
it
can
decide
later
and
based
on
what
we
get.
Can
this
be
removed
from
the
spec
with
I
should
say,
and
so,
but
right
now
it's
just
about
asking
the
right
questions.
Yeah,
hi.
F
F
F
E
E
F
Means
work
for
the
work,
but
on
one
hand,
on
the
other
hand,
maybe-
and
this
is
just
a
maybe
what
the
team
needs
to
consider
is
whether
the
specification
is
actually
complete
or
if
there
are
other
features,
need
to
go
in
there.
Now,
if
you
decide
that,
if
we
get
to,
if
we
even
get
to
the
point,
we're
ready
to
balance
the
internet
standard
versus
adding
functionality
right.
A
F
A
G
Well,
my
thought
process
was
framing
the
initial
questions,
so
reverse
engineering:
what
is
the
output
for
the
progression
of
the
standards
that
we
can
do
right
so
and
that's
when?
Basically,
your
points
came
in
in
the
first
round
of
review
right?
What
is
the
input
that
we
need
to
elevate,
ijen,
pv3
to
a
full
standard
or
IGMP
v3
light?
What
questions
do
we
need
to
distinguish?
Which
of
the
two
could
be
elevated
to
that
right?
And
so
all
the
stuff
like?
G
What
would
the
other
cool
stuff
to
make
people
more
happy
would
be
certainly
on
a
on
a
degree
lower,
because
it
wouldn't
help
us
to
elevate
to
a
fuller.
It's
something
else,
the
nitrogen
pv-1
that
we
have
so
that's
still
kind
of
the
most
limited
scope,
and
you
know
if
we
manage
after
ten
years
to
have
one
questionnaire
out.
Maybe
we
have
in
one
or
two
years,
another
questionnaire
out
for
pool
additional
stuff,
but
and
maybe
we
should
track
it
right
now.
Right
I
mean.
A
So
so
I
think
you
want
to
send
out
this
survey
fairly
soon.
So
it's
a
big
creative
people
can
review
the
questions
and-
and
we
cut
it's
a
lot
of
work
to
get
this
survey
out
to
people
and
get
their
responses.
So
we
should
make
sure
that
they
ask
the
right
questions
before
we
do
it,
but
they
also
want
to
move
on
with
this
and.
G
G
The
key
question
to
the
community
here
in
the
room
and
the
mailing
list
is
whom,
whom
else
could
we
send
it
out?
Alright
I
think
we
have
a
couple
of
usual
suspect,
like
you
know
it
in
a
to
mailing
list
in
the
u.s.
some
many
news,
people
no
equivalent
in
the
research
base
in
Europe,
maybe
accelerators
people
that
work
with
a
lot
of
customers.
A
So,
basically,
well
we'll
have
I'm
not
sure
exactly
how
we
plan
to
do
it
if
it
will
be
like
a
PDF
or
some
document
or
a
URL
somewhere,
but
we
want
to
help
I
mean
yeah
want
everyone
to
contribute
to
distributing.
This
is
hard
to
reach
out
to
all
the
customers
and
the
prices,
and
so
on
so
yeah
basically
wants.
G
What
you
were
just
mentioning
in
terms
of
having
it
on
a
web
page?
Obviously,
you
know,
allows
people
to
go
back
later
on
and
you
know
potential
we
can
have
an
update
or
a
status
report
or
something
right.
They,
whoever
kind
of
gets
involved
in
the
process,
has
a
more
direct
point
to
go
to
and
so
that
what
even,
if
you
haven't
done
it
in
PIM,
it
might
be
good
idea
to
basically
point
to
a
URL,
yeah
I.
E
N
Get
them
you
know
to
enter
in
standard
and
as
far
as
I
know
us
Jeffrey.
As
far
as
I
remember,
we
created
a
survey
monkey
or
something
like
that
survey
and
then
Center
the
link,
obviously
due
to
the
participant
so
and
then
somebody
was
responsible
for
collecting
the
data
and
then
anonymizing
it
and
so
forth.
So
I
think
that
was
the
option.
We
used
right.
A
That's
my
understanding,
but
yeah
great
if
you
can
actually
discuss
with
Rishabh
and
jeffrey
here
and
buddy,
and
what
you're
asking
from
you
guys
now,
I
would
say,
is
this
reviewed
our
questions
and
if
they,
if
you
have
any
questions
to
add,
if
you
find
some
questions
confusing
or
that
they
could
be
improved
or
whatever
we
need
all
input,
we
can
get
to
make
them
that
the
best
possible
and
then
I
think
hopefully
sometime
before
the
next
ITF.
We
want
to
send
this
out
and
we
would,
unlike
you
all,
to
help
us
distribute
this
yeah.