►
From YouTube: IETF94-MBONED-20151105-1740.webm
Description
MBONED meeting session at IETF94
2015/11/05 1740
A
C
B
C
C
B
You
this
up,
that's
it
we're
the
last
one
fair
enough
well,
thank
you.
B
C
C
C
C
B
B
Don't
say
that
until
someone
helps
volunteers
Mike.
Thank
you
appreciate
that.
Yes,
I
knew
it.
It
wouldn't
give
Mike
a
big
round
of
applause
for
a
nice
time.
Stepping
up
no
well
well
noted
there
great
so
the
agenda.
Today
we
got
some
status
items
pretty
simple
list.
We
actually
have
well,
we
got
three
things
in
the
agenda,
but
one
slide
deck
has
not
showed
up
yet
and
I,
don't
even
know
if
they're
present
so.
D
B
Slide:
okay,
email
me:
the
slides,
I'll
move
you
off
to
the
bottom
of
the
agenda,
we'll
take
it
from
there
yeah
any
other
agenda
items
missing
or
need
abusing
or
modified
in
some
way.
Alright.
So
that
means
I
will
take
you
got
them
both.
Look
at
that.
You
know
back
to
back
here
right
all
right,
personal,
be
up
we'll
start
with
the
internet'
appearing
and
then
the
discovery,
which
is
the
new
draft
right.
Okay,.
B
B
We
have
no
one
in
the
room
has
read
the
current
draft.
So
that's
going
to
be
really
hard
to
take
a
request
for
for
last
call
in
the
room
here.
We
can
take
it
to
the
list,
but
my
experience
tells
me
that
I'm
not
gonna,
hear
response
from
you
guys
and
that's
tough.
I'm
wondering
why
we're
here.
You
hear
me
bad
cop
thing
once
again
right
so
I
think
ops
is
needed
here.
B
B
We
have
the
peering
bcp,
which
actually
Lenny
requested
some
ops
input
from
outside,
mostly
I,
think
was
the
internet
to
community
and
we
got
some
really
good
feedback
from
them.
1.2
about
well
I'll
talk
about
when
you,
but
I
think
that
was
some
good
operational
feedback,
so
makes
me
kind
of
wonder
where
our
ops
folks
right
they're,
not
in
this
group,
but
when
we
asked
for
it
outside,
we
got
some
good
community
there.
B
B
Right,
yeah,
good,
that's
a
solid
point.
All
right,
then,
we
have
like
stuff
which
we
need
to
discuss.
Whether
we
adopt
here
that
was
this
presented
in
pim
was
not
presented
in
him.
It
was
referenced
in
pin
the
need
for
charges
of
him,
okay,
so,
but
it
should
live
here
if
we
do
anything,
alright,
so
who's
read
the
current
Wi-Fi
multicast
problem
statement,
draft
hey
all
right
all
right,
excellent
and
of
those
who
thinks
this
is
something
that
group
should
take
on
and
I
see
unanimous
from
those
who've
read
it.
B
F
C
Stick,
yes,
so
I
think
you
know
you're
talking
about
like
our
chili
protocol
and
stuff,
so
there
might
be
things
that
has
to
be
done
in
a
cheaply,
but
it's
very
important
I
think
that
we
can
document
all
the
issues
and
stuff,
and
so
they
can
go
to
a
boolean
perfect.
You
look
at
this.
Something
needs
to
be
done.
Then.
Okay,.
B
C
C
E
B
Was
probably
a
university
ops
writer?
He
might
have
been
cord
internet
too,
but
I'm,
not
certain.
So
the
Internet
to
community
has
got
an
internal
tcast
working
group
has
been
involved
quite
a
bit
and
they
had
quite
a
bit
of
peering
from
the
customers.
You
know
connectors
across
the
course,
so
it's
a
good
example
case.
Alright,.
E
So
I'd
like
to
present
the
comments
and
the
response
is
that
doorless
also
helped
us
construct
so
the
person
that
was
deemed
our
garden
and
his
first
general
comment.
This
would
have
been
great
10-15
years
ago.
Why
now?
Well
our
response?
We
are
seeing
significant
increase
in
video
delivery
distribution.
Your
CD
ends
as
well
as
industry,
have
a
acquisitions.
In
speaking
with
my
company
had
on
AT&T
we
just
acquired
direct
TV.
We
are
going
to
have
a
significant
increase
of
video
based
on
their
tallest,
pointed
out.
E
There's
going
to
be
also
be
a
reduction
of
IPTV
head
ends.
We
use
across
multiple
regional
networks
more
into
the
main.
Multicast
is
going
to
be
needed,
like
I
said
we're
going
to
have
a
lot
of
increase
in
on
that
off
net
over
the
top
video
distribution,
rapid
increase
in
the
role
of
multicast,
so
delivery
across
service
providers,
source
content
providers,
third
party
channels,
and
it's
challenging
to
have
a
good
compromise-
that
being
too
little
too
much.
Hopefully
this
will
be
just
right.
So
that's
our
first
response
next
slide,
please!
E
E
A
gap
if
needed
that
can
be
pursued
as
a
separate
you
work
in
thoughtless
pointed
it
out
may
be
compatible,
is
not
the
right
word.
What
we're
focusing
on
here
is
a
subset
of
best
available
ietf
preferred
standardized
protocol
options.
If
we
want
to
go
beyond
that,
it
could
be
a
much
larger
double
again.
Another
comment
on
section:
one
emt
only
applies
to
three
out
of
the
five
use
cases.
I
think
we
mentioned
that
it
applies
to
all
five.
That's
not
true.
We
will
change
that.
That
was
a
common
x-lite,
please
section
three
dot.
E
One
request
force
to
re.
Add
text
to
the
guideline
see
for
policy
to
allow
certain
groups
only
from
administrative
domain
to
we
agree
to
that
will
make
the
change
and
he
wants
to
add
another
guideline
when
you
want
to
ensure
proper
filtering
between
networks
and
he
supplied
text
to
us
for
that.
So
we
will
take
care
of
that
section.
43
was
the
most
telling
comment.
Is
the
IETF
dictating
how
to
operate
one's
network?
My
initial
answer
was
hell.
No,
but
I
can't
put
that
down
answers.
Absolutely
not.
This
is
a
vcp.
It's
a
guideline.
E
It's
not
an
RFC,
it's
not
prescriptive.
It's
not
normative.
It's
simply
a
way
for
two
operators
they
wish
to
communicate
and
how
to
set
this
up.
This
is
how
we
this
is
the
guideline
as
to
how
to
do
it.
That's
it
Thanks,
like
please
section
5,
wanted
to
add
a
description
for
looking
glass,
tile
method
for
faster
resolution
or
supply
text
against
text
was
supplied.
We
agreed
me
accepted
that
next
slide.
Please
section
6
wanted
to
add
text
to
invoke
vcd
38,
which
was
quite
published
a
long
time
ago.
E
Something
like
each
multicast
fear
must
employ
bcp,
38
style
filtering
to
ensure
they
are
not
sourcing,
content
or
control
that
should
not
be
legitimately
sourced.
Turner
supplied
the
answer.
Ecp
30,
it
was
not
written
with
multicast
knowledge,
so
it
may
be
dangerous
fix
that
explicitly
refer
to
it
again.
We
basically
are
leaving
it
at
that
I
think
we
did
supply
text
back
to
them
before
you.
You
said
he
didn't
trip
was
ok
that
we
don't
have
to
address
it
next
slide.
E
E
E
E
Several
meetings,
the
same
comment
has
been
made
by
Lenny
over
and
over
again,
we
push
back
strongly.
We
believe
these
sections
are
necessary
for
a
complete
bcp
again.
The
target
audience
is
service
providers,
content,
source
providers,
third
party
distributors.
If
we
wish
to
join
together
with
others,
we
need
to
have
some
kind
of
a
standard
document,
even
though
it's
a
set
of
guidelines,
whatever
needs
to
be
done,
it
has
to
be
there
in
some
form
and
basically
that's
it.
B
So
I
believe,
I'm
still
the
authors
list
right.
Yes,
okay,
so
I'll
speak
as
an
author,
I
think
what
we
have
here
is
fairly
unique
in
comparison,
what
we
have
in
unicast
world
and
unicast
world,
it's
all
the
network
operators
they're.
Looking
at
routes,
peering
points
policies,
they're
done
what
happens
with
multicast
is
inherently
integrated
with
the
content
owners
of
some
kind.
B
E
Okay
next
slide,
please
so
that
what
I
did
was
we
tried
to
go
through
sections
4
to
6
to
see
what
it
is,
that's
causing
so
much
ease.
First
of
all,
we
did
remove
previous
section
for
dot
4
on
supplements.
It's
taken
out
then
what's
left
is
in
terms
of
pages.
You
see
here
section
four
or
five
and
six
I
did
make
a
mistake
in
for
da
to
it's
not
six
pages.
It's
for
that's
the
routing
aspects.
E
B
When
we're
talking
about
network
PCP,
its
network,
PCP,
I,
think
content
logging
doesn't
have
to
be
in
the
network,
it
could
be
at
the
application
side
and
billing
the
same
way
to
think
we're
going
to
be
having
those
billing
points
on
a
per
flow
basis.
Granularity
granularly
defined
at
each
pairing
point.
It's
a
lot
of
overhead
to
put
on
a
bcp
I,
and
most
of
that
is
bilateral
behind
closed
doors.
So
I,
don't
think,
there's
really
a
bcp
on
that
which
is
okay,.
B
C
E
Okay,
let's
look
at
the
next
slide.
I'll
tell
you
what
logging
all
right
all
right.
So
then
we
looked
at
some
of
the
possibly
related
stuff
that
we
could
have
looked
at
to
try
and
reference
all
right
in
the
CDN
I
working
group
they've
got
a
logging
interface
bath.
That's
working
on
specifically
the
interface
between
to
CDM
is
upstream
and
downstream
they're
interconnected
at
the
exchanging
value
information,
it's
49
pages
in
length
and
growing
in
our
document.
It's
less
than
one
page
again.
E
All
that
we're
trying
to
do
is
minimize
as
much
information
as
possible,
but
just
keeping
it
there
again.
In
our
experience,
this
is
the
kind
of
stuff
that
other
operators
will
look
for
sure.
So
again,
we
don't
think
it's
too
much
if
you,
if
we
agree
to
find
some
X
to
delete,
that's
okay,
but
we
delete
it.
Eats
people.
E
Okay,
next
slide,
section
5!
Actually
we
didn't
even
have
it
in
our
original
of
that
comment
from
Dallas
IETF
92
that
we
do
need
a
section
on
troubleshooting,
and
so
we
started
adding
some
text
on
that
and
the
nail
guardar
said
you
need
some
more
text.
He
provided
some
additional
text,
which
is
about
six
or
eight
lines
of
text,
so
we
that
we
plan
on
adding
that
as
well.
E
The
size
we
keep
pushing
back
if
there
are
appropriate
references
that
we
can
find
that
we
can
start
deleting
text
and
simply
referring
great.
If
not,
you
know,
it's
not
a
whole
heck
of
a
lot.
Then
I
think
we're
just
two
more
slides.
It's
like
some
specific
comments
from
Lenny
y
es
m.
Why
not
yss
my
naughty
am
that
you
also
mentioned
something
like
an
artless
protocols.
Well,
the
current
mode
of
operations
that
most
operators
are
in
the
in
dodging
today's
SSM.
B
E
C
C
E
Let
me
suggest
that
maybe
mtng
refuse
cases
may
not
even
apply,
and
there
we
disagree
strongly
yeah.
We
have
set
up
multicast
across
our
own
internal
domains
with
empty
tunnels
across
it's
very
applicable
to
us,
our
backbones,
connecting
to
the
new
access
networks
as
we
acquire
them.
You
know
the
peering
points
are
not
the
need
of
multicast
enable
we
need
them
again
as
push
out
to
more
and
more
CDM
type
operators.
We're
gonna
need
some
cases.
E
We
employed
GRE
tunnel
torrance,
provided
some
text
on
the
duplicity
where
GRE
and
EMT
kit
could
be
deployed
simultaneously.
Hopefully,
by
this
the
use
of
this
document
you
such
duplicity
may
be
avoided
again
in
10
days
in
tenders
to
have
a
complete
set
of
description,
regardless
of
the
size.
You
can
minimize
the
size,
but
this
is
necessary.
So
that's
any
questions.
I
think.
C
That
comment
from
it
was
a
little
bit
more
specific
about
actually
helping
to
simplify.
You
know,
platform
and
design
considerations
for
moving,
because,
obviously
we
start
Lenny's
right.
We
started
designing
amt
from
the
client
into
the
network,
so
the
hops
inside
the
network
with
AMT
is
basically
a
thing
that
for
many
people
it
may
not
be
clear
why
it's
beneficial
and
the
reason
why
it's
beneficial
is
because
you
need
to
do
otherwise.
Two
types
of
you
know
forwarding
planes
in
hardware
performance
wise
with
access
control,
with
all
the
monitoring
right
arm
with
a
ninja
re.
C
B
C
B
A
C
B
B
C
E
So
this
is
a
fact
that
we
are
proposing
it's
and
actually
an
outcome
from
bcp
there.
If
you
were
to
use
an
amt,
how
would
you
find
the
most
optimal
amt
relay
in
order
to
maximize
or
amt
experience?
Next
slide
scope
is
to
develop
an
RFC,
find
an
optimal
MTV
lay.
Yet
the
dns
based
procedure
network
is
an
SSM
five
multi
network
environment,
an
activity
between
networks
via
may
not
be
multicast
naval
to
requirements.
E
The
mtv
lay
determined
by
this
procedure
must
have
multicast
conductivity
to
the
source,
and
you
want
to
maximize
the
multicast
portion
of
the
portion
of
the
path
minimize,
the
unique
ask
for
shin
of
the
bath.
The
optimality
policies
or
rules
should
be
flexible.
It
could
be
based
on
distance
based
on
load
or
some
combination
thereof.
B
E
Fair
enough,
all
right
so
next
slide,
the
procedures
got
two
requirements.
Each
Network
has
one
or
more
amt
relay
but
multicast
connected
to
the
source
and
that
wishes
to
serve
content
from
that
source
must
have
an
emt
dns
server.
That's
authority
for
that
source
of
made.
All
such
dns
servers
must
be
reachable
by
the
same
in
cast
address
and
the
entries
in
those
amt.
E
Dns
servers
must
nap
to
the
amt
dealings
in
their
own
networks,
and
we've
got
some
notes
of
the
bottom,
which
verify
some
of
this
is
so
see
the
end
users,
the
empty
gateway,
generates
a
DNS
query
of
the
forms.
Emt
dad
rivers,
s
that
in
a
dress,
our
bot
and
basically,
that's
that's-
how
the
draft
defines
it
go
into
the
next
slide
it
just.
It
goes
through
as
a
self
set
of
illustrative
examples
on
how
that's
going
to
happen.
E
The
intv
lays
a
mtv
late.
1A
and
1b
their
boats
multicast
can't
connect
it
to
the
source.
That's
a
requirement
and
the
question
is
which
we
lay
would
be
empty
gateway
down
at
the
bottom
of
the
end
user,
which
one
would
it
connecting
so
it
comes
starts
to
be
in
a
squaring
of
the
form:
NP
z,
Y,
X
1,
in
a
darpa
that
goes
to
the
local
DNS.
Is
this
network
0x
live
local.
E
To
put
the
domain,
however,
it
recognizes
of
ARPA,
so
it
sends
the
query
through
the
archive
ens
to
get
that
get
the
address
for
emt
dot,
c
@
y
x.
1
next
slide
the
authority.
The
dns
server
is
aware
of
the
dns
server
in
network
one.
It
will
then
redirect
the
local
query
to
that
authority.
The
dns
server
in
network
1x,
like
the
vns
11,
authoritative,
recognizes
that
it
has
an
emt
type
query,
so
it
will
redirect
the
query
to
the
amt
dns
en
esta
one
and
next
slide.
E
B
E
E
B
B
B
Okay
of
those
of
us.
You
and
I
have
read
the
draft.
Let
me
step
back
who
understands
this
problem
space
in
some
way,
even
though
haven't
read
the
draft
okay,
there
we
go,
and-
and
do
you
think
this
is
a
solution
we
need
to
articulate
in
the
type
of
work
that
we
should
be
addressing
here
in
the
group
all
right.
So
now
those
of
you
who
have
had
the
hands
of
a
second
time
around
up.
B
E
B
C
C
B
Get
it
Lenny
didn't
get
it
we
requested.
Last
week
we
were
requested
several
times
this
week.
I
got
no
response
from
anyone,
so
if
you
had
sent
it
in
the
past,
I'm
sorry
I
missed
it,
but
you
should
at
least
responded
when
I
asked
for
agenda
items
and
articulated
specifically
this
slide
deck
was
missing.
D
C
B
F
A
Just
an
observation
to
help
clarify
the
rationale
for
that,
as
opposed
to
doing
it.
Someplace
that's
pre-existing
is
the
I
Triple
E
is
sort
of
spinning
up
an
effort
that
is
associated
with
looking
at
this
problem
as
well,
and
so
the
idea
is
to
corral
the
relevant
people
who
need
to
look
at
this.
It
sort
with
respect
to
designing
link
layers
because,
among
other
things,
they're
actually
the
thinking
about
this
with
respective
future
work
and
not
just
existing
802
at
11
at
80
to
250
enough
for
etc
work.
A
Yeah
and
also
sort
of
containing
it
to
this
sort
of
problems
based
that
it's
in
as
opposed
to
solving
all
multicasts
other
problems
or
or
worse,
exposing
all
of
the
other
wireless
problems
to
this
community.
So.
C
Yeah,
so
from
from
my
perspective,
telepsychic,
the
funny
part
seems
to
be
that
the
people,
mostly
outside
this
room
here
complaining
about
the
non
support
for
multicast,
primarily
don't
seem
to
care
about
the
use
case
of
actually
having
real
multicast
data
traffic,
but
primarily
when
multicast
is
used
for
signaling.
So
we've
basically
got
this
wonderful.
C
You
know
two
sides
that
aren't
moving
one
is
ipv6,
which
you
know
was
used,
is
using
a
lot
more
multicast,
because
by
the
time
they
designed
it
all
the
networks
where
multicast
was
free,
cheap,
easy
bit,
and
so
they
used
a
lot
of
it.
And
then
the
you
know,
wireless
networks,
where
they
don't
have
haven't
seen
a
lot
of
real
need
for
a
lot
of
bandwidth
streaming
and
so
know
that
now
the
question
is:
who
moves
first,
to
improve.
F
F
B
F
F
So
there's
three
issues:
there's
probably
many
others
that
we
identify
in
the
draft
with
the
problem
of
multicast
being
used
in
a
Wi-Fi
environment,
there's
low
bandwidth.
You
know
the
further
away,
get
away
from
the
access
point:
the
less
bandwidth
and
reliability.
You
have
there's
increased
increased
congestion
in
a
Wi-Fi
environment,
there's
no
acknowledgments
for
multicast.
When
this
implementation
was
created,
it
was
optimized
for
unicast
multicast,
with
seemingly
an
afterthought
in
this
Wi-Fi
environment.
So
we're
left
with
what
we
have
is
going
to
say
it
or
no.
A
Jolie
egli
yeah,
there's
also
a
time
domain
problem.
That
is,
that
involves
the
fact
that
modern
systems
use
things
like
beamforming,
actually
direct
signals
at
specific
clients
or
use
multiple
antennas
that
are
the
result
of
which
is
that
they
actually
have
substantially
higher
bit
rates
when
communicating
with
a
single
device,
irrespective
of
what
the
actual
symbol
rate
is
than
they
do,
if
they're
communicating
with
multiple
devices
so
that
sort
of
derives
some
of
the
solution
space
and
in
terms
of
like
the
architecture
of
either
present
or
future
radio
systems.
A
F
Points
I'll
try
to
remember
that
for
the
notes,
I
may
not
I'll
ping.
You
so
Herman
presented
in
pen
potential
solution
for
this
acknowledgments
of
multicast
packets
he's
got
an
idea
that
may
or
may
not
be
adopted
within
PIM,
but
anyway
this
so
that
there
are
some
options,
and
it's
not
just
us
that
have
thought
about
this,
but
were
the
first
ones
as
far
as
I
know,
within
the
idea
that
are
putting
together.
The
problem
statement
in
in
a
draft
form
next
slide.
F
F
If
you
have
experience
in
this
field
or
colleagues
that
have
experience
in
this
bill,
please
let
us
know-
and
we
can
add
that
to
the
draft,
so
we
can
at
least
look
like
we're
intelligent
when
we
start
presenting
these
kind
of
things
to
die
Tripoli
next,
so
this
is
I
think
my
last
slide.
So
these
are
just
some
comments
that
were
made
from
many
many
emails.
F
Some
of
the
comments
were
see
no
state
requirements
more.
As
you
know,
if
we
are
going
to
propose
to
I
Triple,
E
or
whoever
requirements,
we
should
be
clearly
setting
those
in
this
draft,
maybe
add
a
class
of
service
specification
to
multicast
packets.
One
of
the
comments
was:
is
the
multicast
unicast.
F
Conversion
that
some
vendors
do
to
make
this
work
successfully.
None
of
it
is
standard.
It's
all
done
in
their
own
individual
way,
which
is
true,
ietf
has
to
decide
if
it
really
wants
to
design
IP
over
802
11,
which
goes
beyond
what
we
do
here.
But
it's
a
good
question.
We
need
to
decide
how
good
at
performance
is
necessary
in
this
l2
environment
for
multicast
rate,
with
this
high
bit
error
rate
that
occurs
in
a
Wi-Fi
environment.
F
You
know
what
really
should
be
the
acceptable
packet
loss
rate
and
some
of
the
comments
were
you
know:
multicast
packets
should
be
delivered
with
less
than
1%
packet
loss
and
it
should
be
delivered
with
within
200
to
500
milliseconds,
for
instance.
Duplicate
address
detection
requires
an
answer
within
11
within
one
second,
and
as
somebody
mentioned,
I
think
it
was
joel
that
the
solution
space
has
been
explored
in
the
context
of
802
dot
15.
So
we
should
probably
look
to
them
to
see
what
they've
done
and
maybe
extend
that
wireless
lans.
F
So
there's
a
lot
of
things
that
were
intending
to
add
to
the
draft
Greg's
already
pulled
the
room,
so
there
does
seem
to
be
some
interest
in
adopting
this
working
group.
This
drafting
the
work
group,
my
recommendation-
would
be
do
so
quickly,
so
we
can
put
a
stake
in
the
ground
saying
yes,
multi,
embo
India's,
aware
of
this.
We
see
this
as
an
issue
were
staying
the
requirements
and
we
will
disseminate
that
to
the
other
people
that
will
be
interested
in
that
and.
B
A
A
A
No,
I
think
it
happened
because
of
the
I
Triple
E,
which
is
where
the
mailing
list
thing
came
from:
okay,
so
I,
don't
I
I
think
it's
actually
fine
to
adopt
this
and
work
on
it
here.
I
just
think
that
there
are
other
people.
We
need
to
share
this
with
well.
A
B
I
guess
I
need
some
ad
guidance
to
this
clear.
This
is
a
larger
area
of
work
within
the
ATF
and
our
interaction
with
daya
Tripoli.
It
seems
like
operationally.
This
is
where
that
problem
space,
the
problems
that
could
be
defined,
but
if
there's
a
bigger
audience
of
participants
that
should
be
involved
here,
yeah.
B
B
F
F
B
D
Okay,
so
thank
you,
I
am
getting
more
I
will
do
the
presentation
on
the
elf,
a
virtual
that
have
some
trouble
with
the
plane,
I
think
so
it
is
about
the
address
acquisition
for
multicast
contents.
So
the
idea
of
the
draft
is
to
solve
the
issue
when
you
have
a
different
IP
version
between
the
source
of
the
multicast
and
the
receiver.
So
the
draft
is
presenting
three
great
three
different
ways
to
solve
this
issue.
One
is
called
reactive,
one
thing
that
you
receive
in
information
and
the
receiver
is
able
to
detect.
D
That
is
not
supporting
the
same
version,
IP
version,
so
you
will
use
a
kind
of
mapping
function
as
a
second
one.
Is
the
dynamic
one
saying
that
the
provider
network
will
modify
the
IP
version
if
required,
so
it
will
be
aware
of
the
version
supported
by
the
receiver
and
will
adapt
the
information.
According
to
this
information
and
the
last
one,
is
a
kind
of
admin,
asst
and
instructive
one.
So
as
a
receiver
detect
that
the
IP
version
is
not
the
right
one,
it
will
require
the
specific
specific
information
or
you
are
providing.
You
are
provisioning.
D
The
receiver,
with
both
type
of
information
and
the
receiver,
will
will
select
the
right
one.
So
next
slide,
please
so
from
the
version
of
5
to
the
version
06.
The
only
modification
is
removing
everything
ready
to
transition
scenario
or
milky
trance
enero,
saying
that
it
is
applicable
on
to
any
type
of
a
multicast
scenario.
So
this
is
your
new
modification.
B
D
B
B
Who
has
read
the
draft
in
its
current
form,
write
the
authors
and
myself
alright,
so
this
make
really
tough
to
get
honest
feedback
to
the
list
on
whether
it's
ready
for
last
call-
and
let
me
just
make
a
suggestion
to
those
of
you
who
also
have
active
drafts,
that
the
reading
of
others,
work
and
involving
in
participating
is,
is
as
important
as
them
doing
for
you.
So
just
something
to
consider.
E
B
D
Judge
nudge
yeah,
actually
the
draftees
simple
few
pages,
and
so
it
is
for
information.
So
I
think
you
just
need
not
even
five
minutes
to
read
it
and
to
see
if
it
is
a
complete.
From
your
point
of
view,
it
is
not
yet.
I
think
that
the
next
version
will
be
because
we
will
update
the
conclusion
section,
but
based
on
that
I
think,
okay,.
D
D
A
B
Right,
we
have
awesome
minutes
being
taken
by
hour
minute
taker
there.
Thank
you,
Mike
I'm,
pointing
around
your
quote.
You
happen
to
be
like
right
off
your
right
ear,
so
I
would
have
missed
you
right,
but
you
would
have
heard
it
whizzed
by
okay,
anything
else.
Any
agenda
items
any
flagrant
bashing
before
we
go
off
and
find
food
and
fun.
B
That's
it
blue
sheets,
who
has
not
signed
a
blue
sheet
hop
on
up
and
do
it
pick
the
one
with
a
functional
pen,
I,
don't
know
which
one
that
would
be,
but
we
did
note
that
one
was
dead
all
right.
Thank
you
for
your
time.
Thank
you
for
participation,
and
you
have
been
all
been
given
to
do's,
which
is
read
the
drafts
and
respond
to
the
list,
and
thank
you.