►
From YouTube: 2022-06-01 Monthly Multicast W3C Community Group Meeting
Description
Notes here: https://docs.google.com/document/d/1eFGd6EU3Uv2Vnqdq2QxlCOhcGKdxwdfIJbMUF3KlVGo/edit
Meeting series here: https://github.com/w3c/multicast-cg/tree/main/meetings
A
A
A
So,
just
a
a
brief
update
that
we
had
we've
continued
working
on
the
quick
multicast
implementation
and
the
corresponding
changes
to
the
spec
we've
we've
been
refining
that
some
with
some
of
the
pieces
we've
been
noticing
max,
has
done
really
great
work.
There
we've
got
a
bunch
of
a
bunch
of
code,
that's
in
progress,
I
don't
think
anything.
A
You
know
still
no
promises
on
that,
but
I
think
we're
on
a
reasonable
pace
to
have
some
hopes
of
hitting
that
we
may
or
may
not
in
fact
get
there.
We
noticed
a
new
problem
with
web
transport.
I
wrote
about
that
briefly
in
the
in
the
email.
I
think
there
is
a
workaround,
so
it's
not
like
a
show
stopper,
but
it's
sort
of
inefficient
and
it's
extra
inefficient
I'll,
probably
add
a
section
to
the
to
the
to
the
spec
under
operational
considerations
about
it.
A
So
it's
so
the
the
problem
is
that
when
someone
connect
when
the
client
connects
and
issues
a
request
for
a
web
transport
url
and
gets
back
the
200
response,
then
the
current
specification
for
web
transport
and
for
the
h3
datagrams
they're,
both
kind
of
the
same
is,
is
that
the
id
of
the
stream
of
the
client
initiated
bidirectional
stream
that
the
quick
session
uses
to
open
to
make.
That
request
is
then
used
later
as
the
session
id.
So
the
problem
here
is
that
many
different
clients
have
many
different.
A
A
Now,
when
we're
sending
stream
data
in
channels,
the
stream
data
has
to
be
identical
for
every
stream
sent
in
a
multicast
channel
at
every
offset,
so
the
workaround
we
would
be
forced
to
adopt
if
web
transport
doesn't
provide
an
extension
or
a
change
or
if
we
can't
convince
some
kind
of-
and
we
can
make
this
proposal,
but
but
the
we
can
there's
a
few
ways
to
fix
it.
One
is
to
allow
a
server
provided
id
as
the
session
id.
A
A
It
is
possible
to
send
that
data
on
the
unicast
connection
send
the
rest
of
the
data
in
the
stream,
but
because
these
ids
actually
can
have
different
sizes,
then
then
all
the
stream
data
would
be
at
a
different
offset,
which
would
be
which
would
require.
Then
the
there's
four
possible
different
sizes.
It
can
be
a
one
byte
id
a
two
by
idea,
four
by
id
or
an
eight
byte
id,
because
of
the
way
they
do.
The
variable
integer
encoding
in
quick
in
the
limit.
A
I
don't
know
how
that's
going
to
go,
but
I
think
the
plan
there
is
we'll
do
one
more
rev
of
the
of
the
current
spec
and
then
we
will
send
it
out
to
the
msec
list
and
probably
to
web
transport,
maybe
with
a
sort
of
header
trying
to
describe
that
issue
so
that
we
can
get
some
web
transport
focus
on
that.
Specifically.
A
A
A
All
right,
I
I
think
I'll,
probably
probably
get
that
while
I'm
adding
the
operational
considerations
section
and
we'll
we'll
put
it
as
a
maybe
in
the
spec.
If
we
need
to
change
the
you
know,
there's
a
few
different
ways
to
to
do
the
web
transport
update
so
we'll
try
and
figure
out
the
best
one
and
propose
one
that
the
web
transport
people
will
be
happy
with.
A
I,
I
expect
it'll
probably
end
up
being
an
optional
extension,
so
that
existing
implementations
don't
have
to
change
that
will
be
signaled
during
the
during
the
transport
properties,
negotiation
and
then
a
different
frame
type
that
we
use.
If
the
client
supports
it
to
to
use
a
server
provided
session
id
value
for
those
for
those
web
transport
frame
types,
probably
the
same
for
for
h3
datagrams
as
well-
and
I
don't
know
we
might
have
to
make
more
drafts
for
that.
A
A
B
I
guess
the
only
thing
would
be
that
the
frames
now
mostly
work,
so
the
channel
object
is
created
and
so
on
and
if
it
gets
the
joint
frame
and
join
so
we
get
the
frame
it
leaves
and
so
on.
So
I
guess
the
the
biggest
obstacle
left
is
to
actually
like
input
the
frames
received
over
the
multicast
channel
into
the
into
the
actual
flow
of
of
the
quick
implementation.
A
A
Even
before
traveling
starts
to
get
in
the
way
so
yeah,
I
I
think
I'm
pretty
happy
with
our
progress
so
far,
but
there's
still
a
bunch
of
work
to
do
all
right
all
right.
If
we've
got
nothing
else,
then
we
should
have
plenty
of
time
for
eric
and
chris
to
talk
a
little
bit
about
what
they're
doing.
I
might.
I
might
have
a
few
questions,
but
I
wanted
to
hear
you
know
kind
of
what's
the
what's
the
plans.
C
Sure
yeah
thanks,
so
I'm
eric
just
and
with
me,
chris
dawson
we're
the
co-founders
of
vevo,
and
we
started
that
almost
three
years
ago
and
chris
and
I
started
working
together
in
1999
at
real
networks
worked
on
various
multicast
projects.
You
know,
since
then
we
started
a
company
in
2003
that
was
an
open
source,
webcast
appliance
that
injected
lectures
into
internet2
multicast
from
the
san
diego
supercomputer
center
to
other
mbondi
schools
and
and
so
then
recently
we
started
this
company
and
we
started
building
this
sort
of
multicast
receiver.
A
C
C
Yeah-
and
so
you
know,
worked
in
various,
you
know
capacities
together
in
a
part
and
then
came
back
together
almost
three
years
ago
to
start
vivo
and
we
wanted
to
build
some
multicast
solutions,
and
the
first
thing
we
built
was
this
way
of
reaching
the
browser
with
multicast
video,
using
this,
this
kind
of
way
of
relaying
multicast
as
hls
via
an
agent
and
put
that
in
a
repository
and
then
our
first
customer
didn't
want
it.
They
wanted
an
app,
they
wanted
actual
sort
of
standalone,
multicast
media
player.
C
So
then
we
pivoted
and
started
building
that
instead,
and
so
we
have
a
commercial
player
server
solution
that
we
sold
folks,
but
recently
you
know
watching
jake
and
the
team
you
know,
working
with
google
on
multicast
and
chrome
said
well.
Why
don't?
We
just
take
this
project
and
the
old
stuff
that
we
built.
You
know
almost
three
years
ago,
two
years
ago
and
and
just
put
it
up
in
a
github
repository
and
maybe
that'll
be
useful
for
the
team.
C
So
what
we
have
now,
I
just
could
quickly
show
you
a
diagram,
show
you
the
repository,
do
a
demo
and
then
open
the
questions
myself
and
chris.
You
know
regarding
it
and
what
we
think
some
of
the
big
issues
are
and
gaps,
and
maybe
what
could
be
promising
about
it.
But
the
goal
is
to
receive
multicast
video
and
play
it
out
in
a
browser.
C
Yeah
I'll
share
the
diagram
to
explain
so
here.
Does
everyone
see
my
desktop?
So
this
is
the
diagram,
so
the
user's
desktop
has
a
browser,
has
a
little
node
js
server
wrapper
using
express,
I
think
chris
will
know
and
then
ffmpeg,
and
so
the
the
browser
makes
a
request.
You
know
over
https
to
some
website
that
has,
for
example,
the
video.js
player
as
html
and
javascript,
and
then
the
video
tag
points
to
another
resource
which
is
on
localhost
http.
C
You
know
127.001,
slash
live.m3u8,
so
that's
coming
from
this
node
express
server
and
what
it
does
is.
It
holds
open
that
request
and
then
it
executes
a
local
copy
of
ffmpeg
with
command
to
join.
You
know
a
multicast
source,
so
it
joins
the
multicast
source
and
ffmpeg
starts
generating
hls.
You
know
ts
files
and
then
the
node.js
server
responds
to
the
request
with
the
playlist
and
starts
responding
with
subsequent
https
requests
for
the
the
hls
chunk
files,
and
we
have
the
video
that
was
multicast
in
the
browser.
A
A
C
C
C
A
E
B
A
C
And
you
know,
as
it
turns
out,
this
implementation
has
been
sort
of
copied
by
various
folks
in
various
capacities.
So
you
know
various
other
enterprise.
Video
companies
have
the
same
exact
implementation
for
their
local
on-premises
enterprise
multicast
receiving.
But
then
I
also
know
of
some
networks
that
are
using
this
in
set-top
boxes,
so
they
receive
multicast.
And
then
this
sort
of
process
runs
in
a
set-top
box.
Think
of
it
like
an
hls
gateway
for
a
multicast.
A
C
C
C
C
B
C
A
C
Definitely
a
good
idea.
I
mean
right
now
we're
just
sort
of
doing
asm
on
both
sides
for
a
lot
of
the
stuff.
We
do,
but
there's
definitely
an
interest
in
ssm.
For
that
I
don't
I
don't
know
what
the
capability
is
of
a
ffmpeg
to
you
know,
specify
this
the
source,
but
that's
where
you
know
better
segmenter
or
receiver,
whether
it's
ts,
dock
or
a
custom,
you
know
join,
which,
with
ssm,
is
needed.
So.
C
A
C
A
C
A
right
of
gotchas,
though
I
mean
you,
the
search
question
is
good
one.
You
know,
I
think
you
know
just
this
whole
architecture
you
know
to
me,
is
you
know,
I
think
it's
interesting
to
put
it
out,
there's
open
source
and
then,
if
companies
want
to
engage,
you
know
we
can
help,
but
I
I'm
not
sure
if
this
is
the
right
end
game.
You
know,
I
think
I
think
the
work
you're
doing
is
better.
You
know
our
client
has
a
chromium
engine.
C
So
putting
your
chromium
fork
in
our
client
is
interesting,
but
yeah
they
do
have
an
agent
running
on
the
browser
or
running
on
the
desktop.
You
know
it's
a
web
server,
so
you
know
you
have
to
convince
people
to
run.
You
know
an
open
web
server
and-
and
I
think
that
the
chrome
is
going
to
get
even
less
permissive.
I
predict
that
chrome
is
not
going
to
allow
you
know
local
hosts,
not
allow.
C
A
I
guess
the
other
way
I've
seen
this
discussed
is
like
each.
You
know
you
get
some
kind
of
office
setup
where
there's
you
know,
people
who
are
essentially
on
the
same
wi-fi
would
be
getting
unicast
from
from
a
server
where
you're
running
the
the
proxy,
and
then
you
know
other
other
campuses.
Other
buildings,
maybe
other
rooms
would
be
doing,
would
also
so
the
end
client
would
be.
You
know
you
still
might
have
multicast
to
kind
of
take
the
load
off
of
your.
C
C
D
C
A
A
I
guess
I
certainly
want
to
leave
space
for
other
people
to
ask
questions
too,
but
the
one
other
thing
I
was
wondering
really
is:
maybe
I'll
I'll
come
back
to
it,
it's
it
and
just
to
let
you
chew
on
it
ahead
of
time.
It's
really
about
like
how
big
a
difference
would
it
make
for
browser
support
of
multicast
and
what
kind
of
restrictions
would
there
be
on
the
deployment
side
if
they're,
if
you
had,
if
you
had
that
capability.
C
C
F
I
have
a
question:
if
you
can
hear
me
all
right,
yep,
I
think
in
the
entire
multicast
community.
One
of
the
problems
we
face
is
getting
people
to
understand
the
efficiencies
that
can
be
gained.
Do
you
guys,
as
in
your
enterprise
space,
have
customers
with
real
success
stories
that
could
talk
about
the
efficiencies
of
this
implementation?
The
bandwidth
savings,
the
success
stories.
C
I
think
so
yeah
I
mean
I
like
to
focus
on
financial
services,
insurance
type
organizations
because
they
often
have
some
legacy
equipment.
We
have
one
financial
services
regulator,
that's
still
using
igmp
v2
and
we
initially
had
to
deploy
on
red
hat
six
anyway,
but
so
there's
always
challenges
you
know
with
that
environment.
But
then
the
benefits
are
that
they
haven't.
C
You
know
fully
adopted
sd-wan
and
sassy,
so
as
companies
as
they
pitch
to
companies,
if
they
say
oh
we're
already
deploying
sd-wan
and
sassy,
then
it
becomes
pretty
hard
to
sell
to
them.
But
we
still
have
customers
that
have
you
know
traditional
mpls
circuits,
some
of
them
very
small,
for
example,
one
customer,
I
think
it's
a
verizon
circuit
between
hartford
and
charlotte,
and
they
give
us
two
megabits.
So
there's
not
much.
You
can
do
with
two
megabits
except
multicast
in
that
scenario.
C
So
if
you
want
to
reach
those
employees
in
charlotte
with
a
live
video
and
if
there's
50
or
100
of
them,
you've
got
a
2
megabit
pipe,
then
just
pretty
much
we're
pretty
much
the
only
game
in
town,
I
would
say
another:
one
is
a
hospital
network
and
the
other
definitely
very,
very
nervous
about
that.
And
so
you
know
to
answer
your
question.
I
mean
these
are
folks
who
want
a
very
deterministic
allocation
of
bandwidth.
C
They
want
to
say
you
know
it's
going
to
be
two
megabits
and
and
the
other
solutions
out
there
are
very
bursty.
So
you
know
a
peer-to-peer
solution
takes
is
a
very
bursty
setup.
So
setting
up
a
peer-to-peer
connection
often
results
in.
You
know
kind
of
a
little
storm
once
it
kind
of
settles
in
and
once
the
peers
start
peering.
Well,
so
that's
an
indeterministic,
you
know
how
do
you
manage
that
that
surge,
you
know
initially
and
then
deploying
caching
hardware.
C
We
replaced
one
customer
had
a
whole
bunch
of
riverbed
appliances
and
they
were
very
expensive
to
maintain
and
by
switching
to
multicast
they
were
able
to
save
a
lot
of
money
and
reduce
their
hardware.
Footprint
so
yeah
we
have
some
folks
that
challenges
getting
them
to
actually
speak
publicly,
but
I'm
sure
the
trick
would
be
yeah
say
I
think
if
we
can
invite
them,
maybe
the
forums
like
this.
F
We
can
circle
back
and
you
know
I
think
we
all
have
an
interest
in
making
multicast
succeed,
but
part
of
the
difficulty
is
making
people
understand
the
efficiencies
and
why
the
difficulty
of
implementing
it
is
worth
it.
We
can
reduce
that
difficulty,
then
it's
just
making
people
understand
the
efficiencies
so
yeah.
C
I
agree,
you
know,
there's
changes
that
could
be
helpful.
For
us.
I
mean
the
industry,
my
industry,
this
sort
of
enterprise
streaming
video
and
an
industry
used
to
be
very
tolerant
of
30
60
seconds
of
latency
small
video
images
as
the
norm
for
corporate
communications.
But
now
people
expect
low
latency,
high
quality,
zoom
or
webex
or
microsoft
teams,
so
so
their
their
expectation,
level
of
terms
of
what
the
experience
is
like
is
has
changed
and
so
applying
old-school
streaming.
C
C
A
secure
access,
security,
endpoint
and
it
just
means
it's
kind
of
that
and
sd-wan
combined.
Are
you
know
this
idea,
along
with
zero
trust
that
if
you
move
all
your
services
to
the
cloud,
then
why
do
you
need
a
network?
Why
do
you
need
an
mpls?
Why
do
you
need
a
firewall?
Why
do
you
need
a
data
center?
Every
computer
just
creates
its
own
https
connection.
To
you
know
a
cloud
firewall
and
a
set
of
cloud
services
and
just
kind
of
like
vpn
for
everybody
and
but.
A
But
they
still
need
capacity
right
like
it's.
It's
a
cheaper
capacity,
as
I
understand
it
right
because
it's
it's
their
regular
internet
connection,
but
you
still
have
I
mean
so
the
the
cost
comparison
and
please
correct
me
if
I'm
wrong.
I
don't
really
know
this
very
well,
but
it's
like
what
40x
or
something
like
you
can
get
a
400
megabit
uplink
for
about
what
you'd
be
paying
for
a
10
meg
mpls
setup
is
that
I
don't
know.
I
would
love
to
know
that
right
yeah.
I
would
love.
C
C
A
C
A
C
Seem
to
have
more
and
they
seem
to
be
a
lot
cheaper.
It's
you
know
it's
commodity
internet,
so
part
of
the
sd-wan
pitch
is
to
do
bonding.
So
you
have
these
devices
that'll
bond
comcast,
plus
your
att,
5g,
plus,
maybe
another
verizon
5g.
And
then,
if
one
of
those
you
know
less
reliable
networks
goes
down
it'll
route,
the
data
across
some
of
the
other
channels,
so
they're.
A
C
Yeah
and
then
you
know,
I
ask
you
know
what
about
you
know:
phones
and
video
conferencing
devices
or
video
conferencing,
bandwidth
or
those
sorts
of
things,
and
there's
changes
there,
where
you're
buying
devices
that
register
on
the
internet.
So
if
you're
an
enterprise
you
ship,
someone
a
device,
you
know
a
polycom
device
or
some
kind
of
zoom
phone
or
webex
device,
and
it
attaches
you
join
your
home
wi-fi
and
it
then
sends
the
mac
address
to
this
central
server.
Where
it
says.
C
So
the
audio
video
elements
you
know
are
getting
registered
directly
on
the
internet
with
their
own
kind
of
secure
connections
and
again
not
on
a
private
mpls
network,
where
you'd
be
really
worried
about
and
controlling
things
like
jitter
and
stuff
they're,
allowing
people
to
just
sort
of
register
directly
on
the
internet
with
these
devices
and
this
they're,
and
that
medic
that
reduces
a
lot
of
yeah
well
reduces
some
bandwidth
but
yeah
you're.
Right
at
the
end
of
the
day,
all
these
devices
and
laptops
and
are
going
out
through
some
sort
of
limited.
C
You
know
internet
capacity
in
the
office,
and
that's
where
we,
you
know
we
still
have
to
work
on
this
and
could
definitely
use
some
help.
But
you
know
I
like
the
idea
of
creating
these
little
islands
of
multicast.
So
put
you
know
one
of
these
set-top
boxes
or
a
nook
in
in
an
office
like
atlanta.
Have
it
use
amt,
pull
back?
You
know
the
multicast
over
a
tunnel
into
the
local
office.
E
C
And
they
can
sort
of
have
a
rule
that
says
clients
can
join
this
local
multicast.
Meanwhile,
their
their
unicast
data
is
going
through
a
vpn
or
tried.
You
know
secure
connection,
so
kind
of
split,
not
really
split
tunneling,
but
basically
allowing
I
mean
if
a
client
uses
the
vpn
to
access
the
internet
and
that
same
client
can
join
a
multicast
without
needing
the
vpn
locally.
A
C
So
yeah
this
is
where
we
get
away
with
it
by
having
you
know
private
domains
and
remember
security,
so
so
far,
they're
not
they're
so
far,
they're
happy
with
that
so
yeah,
it's
definitely
different
from
the
cdn
model.
Where
people
be
more
concerned
about,
you
know
a
shared
ownership
of
content
going
across
the
same
network
model.
Luckily,
in
our
case,
we're
sort
of
within
a
owned
internal
network.
C
C
We've
you
know:
we've
had
collisions
when
we
screw
up
our
port
allocations
and
such
but
and
those
get
ugly.
But
then
you
know
we
quickly
realized
that
we're
doing
something
completely
wrong,
but
you
know
I
but
your
first
one
I
mean
I
am
very
interested
in
creating
you
know
more
of
a
multicast,
transit
or
sort
of
backbone
solution,
especially
in
the
zoom
use
case.
Where
you
know,
potentially
it
could
be
a
lot
of
universities
or
schools
wanting
to
to
to
do
this
with
zoom.
C
So
in
that
case
you
know
in
the
transit
side
or
backbone
side,
we'd
be
wanting
to
introduce
the
things
that
you're
talking
about
in
terms
of
integrity
and
things
that
you
know
prevent
people
from
necessarily
learning
about.
What's
all
happening
there,
so
that
would
be
a
multi-domain
multi-user
shared
network.
C
C
A
F
A
C
A
A
A
Even
though
they
went
to
https,
you
can
99
identify
what
someone's
watching
by
the
you
know
the
amount
of
packets
and
size
of
the
packets
they
get
just
by
fingerprinting
the
the
stuff.
I
think
there
are
some
mitigations
for
that,
but
they're
expensive,
because
you
have
to
like
make
everything,
look,
identical
and
so
like
it's
whatever
is
the
biggest
and
slowest
thing
everything
has
to
look
exactly
like
that,
which
can
like
triple
the
size
of
of
many
of
your
smaller
things.
A
C
A
A
Okay,
I'm
talking
about
the
ip
packets,
because
the
ts,
the
ts
chunks
that
are
within
the
ip
packet
payloads
are
already
encrypted.
So
those
look
random,
but
but
the
exact
packet
composition
and
the
the
timing
of
the
packets
and
these
kinds
of
things
are
can
be
used
to
fingerprint
the
data
or
the
content
that
someone's
watching
and
that
can
be
used
to
figure
out.
And
then
coupling
that
with
the
receive
ip
is
one
of
the
attack
factors
that
people
have
been
researching
for
the
mass
surveillance
kind
of
attack
surface.
A
C
A
C
C
A
A
You
know,
people
can
just
use
it
according
to
the
license,
and
that's
that's
great.
The
the
one
we're
working
on
now,
we
hope
has
has
a
spec
with
a
better
future
in
terms
of
and
easier
usage.
I
think
like
from
the
application
side,
it
should
be
possible
to
make
it
transparent,
so
you
don't
know
or
care
whether
you're
using
multicast
at
the
browser
layer.
A
It
was
a
first
try
you
know,
but
the
feedback
we
got
was
that
this
needs
to
have
encryption
baked
into
it
better.
In
order
for
this
to
be
a
candidate
for
for
adoption
by
w3c-
and
it
you
know
it
was,
it
was
not
super
supportive
feedback.
It
was
more
like
you
haven't
thought
about
this
problem.
Great
well
enough,
yet
go
go!
Think
some
more.
A
So
that's
what
we're
trying
to
do
with
the
quick
version
and
we've
put
together
the
the
security
considerations
document,
and
we
think
that
the
quick
that
the
quick
base
specification
matches
with
those
security
considerations,
and
so
we
think
it's
we
think
it's
on
a
better
path,
but
we
it's
not
like
at
this
stage.
There's
there's
adoption
of
it
or
really
great
support
of
it.
Either.
A
You
know
that
vision
is
probably
not
this
year
and
probably
not
next
year,
but
we're
gonna.
You
know
we.
By
that
time
we
should
have
a
better
view
of
you
know
whether
it's
got
any
legs.
Whether
people
would
be
willing
to
take
this
or
whether
there's
really
any
problems
with
it.
Nobody
has
raised
problems
yet,
except
you
know,
I
mean
there's
the
one
I
mentioned
with
web
transport
that
has
a
workaround.
A
And
maybe
we
can
maybe
we
can
get
it
further.
The
you
know
one
actual
review.
We
got
of
the
multicast
security
considerations
document
raised
actually
the
same
point
as
the
one
thing
that
we
hadn't
considered.
We
added
that
as
an
issue
to
the
to
the
security
considerations
document
and
it's
it's
actually
about
tying
the
content.
That's
delivered
over
multicast
to
an
initial
server
generated
request
for
the
web
for
web
traffic.
A
B
B
A
Yeah,
I
think
I
think
I
would
like
to
do
at
least
one
more
update,
remove
like
the
path
response,
and
I
think
you
made
a
good
point
about
the
until
packet
number.
You
know
there's
a
few
fine
tunings
I'd
like
to
get
because
I
think
we've
had
a
few
iterations
and
tightened
up
the
spec
a
bit
since
the
since
the
first
draft,
so
yeah,
let's
just
get
all
those
in
there
and
maybe
I'll
see
if
we
can
do
it
by
end
of
next
week.
A
I
think
I'd
like
to
have
that,
but
send
it
out
to
msac
and-
and
yes,
this
list
as
well.
That's
a
good
point,
probably
some
more
to
we.
We
probably
should
send
it
to
like
quick
and
web
transport,
but
I
might
want
to
get
one
more
round
of
review
before
we
before
we
wait
into
that.
We
certainly
will
need
to
talk
to
them
and
need
to
send
them
something
I'd
like
to
have
as
little
confusion
as
possible
before
making
it
too
wide.
But
I
think
we're
getting
close
to
that.
A
A
D
A
A
Planning
something
I
actually
I
got
tentative,
maybe
approval,
but
it
sort
of
depends
on
what
I
think
there's
a
a
bit
of
a
chicken
and
egg
problem
there
for
me-
and
I
I
doubt
that
we'll
have
the
the
attendance
from
this
group
to
really
run
a
meeting
for
this
group
there.
That
would
be
more
productive
than
our
than
our
online
meetings.
A
A
Yeah
12
to
16.,
okay.
So
what
I'll
it'll
it'll
start
to
get
a
little
bit
tight
then?
But
what
I'm
going
to
try
and
do
is
get
some
signals
during
ietf
about
where
things
stand
with
some
of
the
people
that
go
to
both
and
then
get
approval
based
on
that
or
not
based
on
what
I,
what
I
would
need
to
present
at
tpac
are.
D
Yeah,
I
I
think
the
difficulty
is
allocating
time
because
we're
being
like
w3c
groups,
are
being
asked
kind
of
right
now
about
how
much
kind
of
in-person
meeting
time
they
want.
So
I
think
if
we
want
to
yeah,
if
we
want
to
run
something,
it's
probably
worth
getting
getting
a
request
in
fairly
soon.
For
me,.
A
D
A
A
Good,
then,
I
will
rely
on
that
flexibility
and
make
that
decision
before
the
august
meeting
before
the
august
meeting
of
this
group,
but
after
the
after,
at
least
after
ietf
has
started,
so
I
have
some
some
early
discussions
under
the
belt
there
yeah.
Thank
you
good
good
question,
okay,
and
with
that
we
are
a
minute
over
and
thanks
everyone
for
coming,
really
appreciate
it.
Thanks
eric
and
chris
for
your
update
on
this,
I
think
it's
really
interesting
work.