►
From YouTube: IETF111-MBONED-20210730-1900
Description
MBONED meeting session at IETF111
2021/07/30 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Just
about
time
to
begin
we'll
wait
a
couple
more
minutes
for
folks
to
join,
but
as
we
wait
while
we
wait,
we
need
a
note
taker
who
would
like
to
be
the
note
taker
and
normally
jake
is
our
notetaker,
but
he
is
the
star
of
the
show
and
we'll
be
doing
most
of
the
talking
today.
So
it's
probably
not
good
to
have
him
so
who
else
would
like
to
be
the
notetaker
today.
A
It's
it's
actually
fun
which
isn't
true,
but
it
is
necessary
and
don't
worry
about
if
your
note-taking
skills
are
weak,
we
do
fix
them
in
post-production.
A
B
A
C
A
The
good
news
today
is,
we
have
plenty
of
time,
but
I
can
assure
you
we
will
be
done
early,
so
that
is
the
the
best
promise
I
can
give.
A
Fortunately,
time
slots,
we've
discovered
the
hard
way
that
one
hour
is
not
enough.
Two
hours
is
kind
of
too
much
so
looking
forward
to
someday
having
90
minute
slots
again,
because
those
would
be
the
goldilocks
slots.
Okay,
I
think
I
think
we
can
get
started
welcome
to
mbondi
in
ietf
111..
A
I
know
you
have
many
other
choices
of
working
groups
to
join,
but
we
appreciate
you
joining
this
one.
Here's
the
notewell,
please
note
it
well.
It
looks
very
similar
in
fact
identical
to
all
the
others
that
you've
seen
this
week
and
we'll
see
the
rest
of
today.
A
The
usual
status
of
working
group
items
I'm
going
to
give
a
very
brief
multicast
deployment
update
and
as
for
some
interesting
projects
going
on,
and
while
it
looks
like
only
you
know,
there
are
a
few
people
on
there.
A
The
truth
is
jake
has
the
lion's
share
of
the
working
group
documents,
so
he
will
be
think
of
this
as
four
separate
slots,
if
not
more
so,
he's
going
to
cover
those
and
he'll
be
able
to
dive
into
detail
lots
of
exciting
work
going
on
there
and
he
can
hopefully
maybe
talk
about
some
of
the
work.
That's
been
kicked
off
at
w3c.
A
Okay,
so
moving
right
along
in
terms
of
active
working
group
documents,
the
long-awaited
multicast
problems
draft
that
had
been
sitting
in
ad
review
for
a
long
time
with
many
discusses
was
finally
cleared
mike
and
team
were
able
to.
They
were
able
to
send
out
revisions
to
that
a
couple
weeks
ago.
A
There
was
one
more
issue
that
was
addressed
and
that
has
been
sent
on
to
iesg
and
approved
for
publication.
So
I
believe
warren
is
one
of
the
authors
on
that.
I
don't
know
that
any
of
the
other
authors
are
here
but
congrats
on.
Finally
getting
through
the
gate
on
that
one.
I
think
that
had
been
sitting
about
a
year
in
in
a.d
review.
A
A
I
don't
know
if
m
nat
counts,
but
we're
in
tangentially
involving
that
one
and
the
telemetry
draft
mike
said
progress
is
being
made
and
he
expects
to
update
that
soon
as
well.
A
There
is
one
other
dock,
the
redundant
ingress,
failover
draft.
This
was
presented
in
ietf,
109
kind
of
looking
just
for
feedback
at
the
time.
They
did
not
request
adoption
at
the
time
according
to
sandy,
they
think
they're
getting
ready
to.
They
think
it's
just
about
ready
for
adoption.
A
She
may
be
asking
for
adoption,
or
she
may
wait
until
she
may
wait
until
ietf
1
12
to
present
it
and
then
ask
for
adoption
so
keep
an
eye
on
the
mailing
list.
For
that
and
that
is
it
close
this
deck
and
share
the
next
one
all
right.
So
next
up
is
a
deployment
update.
A
So
just
as
a
reminder,
one
of
our
charter
items
for
mbond
is
to
give
periodic
updates
on
what
is
going
on
in
the
world
of
multicast.
So
I
thought
it's
a
good
time
to
do
that.
A
Some
interesting
projects
going
on
they're,
very
early
stages,
so
just
wanted
to
share
with
folks
some
of
this
work.
A
A
new
project
called
off
net
sourcing
is
being
kicked
off
and
it's
being
developed
right
now,
they're
about
ready
to
post
some
prototype
code,
but
it's
still
it's
still
early,
not
ready
for
we're
pre-alpha,
but
hopefully
in
the
next
couple
weeks,
we'll
have
something:
that's
that's
prototypable
and
demo
able
and
that
it
essentially
allows
translates
it's
a
it's
a
tunnel.
A
It's
a
translation
box
that
would
sit
at
the
border
of
the
multicast,
enabled
net
part
of
the
internet,
the
mbone,
and
it
would
take
in
a
unicast
stream
and
spit
out
as
a
multicast
stream
and
I'll
talk
about
that
in
a
minute
a
little
bit.
A
What
that
would
look
like
also
in
ietf
110
in
the
beer
working
group,
the
some
folks
working
with
giant,
which
is
the
research
and
education
network
in
europe
presented
about
a
a
p4
network
that
they
have
deployed
and
they
recently
added
beer
to
the
routing
stack
and
the
p4
code
and
they
were
able
to
they
demonstrated
or
they
discussed
they
described
that
deployment
and
the
implementation.
I
encourage.
If
that
sounds
interesting,
please
check
out
the
proceedings.
Click
on
these
two
links.
A
You
can
see
the
slides
as
well
as
the
video
for
details
on
how
that
worked
subsequent
to
that,
after
seeing
that
we
reached
out
to
them
to
say
hey
if
you've
got
beer
running,
wouldn't
you
like
to
extend
your
reach
to
off
net
receivers
with
amt,
so
there's
an
investigation
afoot
we're
at
the
early
stages
of
that
as
well
to
add
amt
relays
to
that
deployment
so
that
the
content
that's
currently
being
delivered
by
beer
in
the
underlay
can
be
delivered
to
receivers
that
are
off
net
so
going
back
to
the
first,
the
first
thing,
the
first
project
so
right
now
today,
you
know
I've
presented
a
few
times
in
this
working
group
about
what
we've
called
at
times
multicast
to
the
grandma.
A
Basically,
it's
a
an
architecture
that
delivers
multicast
for
everybody
on
the
internet,
just
not
just
the
privileged
few
who
seem
to
be
connected
to
the
mbone.
A
But
you
know
the
first
step
that
we've
always
had
working
is
onnet
multicast,
which
is
you
have
native
sources
native
receivers
and
that
just
works.
The
way
multicast
has
always
worked.
That's
been
around
for
20
something
years
and
it
works
today.
The
the
m
bone
is
comprised
mostly
of
research
and
education
networks
like
giant
and
internet2
too,
so
that's
been
working
forever
more
recently,
the
last
few
years
we've
added
off
net
receiving,
which
is
you
can
deliver
native
multicast
sources
to
unicast
only
receivers
through
amt.
A
There
are
currently
four
amt
relays
deployed
across
the
internet
across
the
m
bone.
All
four
happen
to
be
at
internet
2
member
institutions
today-
and
you
can
see
this
and
enjoy
this
on
the
multicast
menu
I've
I've.
I
can
send
the
link
to
that,
but
I've
presented
on
that
in
the
past.
A
So
what's
new,
what's
being
worked
on
right
now,
the
effort
underway
is
to
add
off
net
sourcing,
which
is
imagine
you
have
a
let's
say,
a
cell
phone
with
video,
and
you
want
to
send
a
video
stream
in
via
unicast
to
a
translator
that
would
take
in
the
unicast
stream
spit
it
out
as
multicast,
and
then
it
can
be
delivered
to
on
net
receivers,
natively
or
off
net
receivers
via
amt.
A
So,
like
I
said,
we're
the
early
stages
of
that.
What
do
we
need?
Most
right
now
is
interesting
content.
All
network
innovation
is
driven
by
compelling
content,
we'd
love
to
believe
that
it
goes
the
other
way
around,
but
the
truth
is
content
drives.
The
network,
cool
content
comes
out
that
people
love
and
the
folks
in
networking
build
architectures
to
support
those
that
content
and
those
applications.
A
Hopefully
we'll
have
some
work
in
code
to
demo
by
ietf112,
and
if
anyone
has
interesting,
specifically
interesting
content
that
they
would
like
to
share.
Please
reach
out
to
me
or,
if
you'd
like
to
be
involved
in
either
of
these
two
projects.
Please,
please
let
me
know
questions.
B
Here,
oops
there
you
go
yeah,
so
the
there's
also
the
I
was
in.
I
think
there
were
some.
There
was
some
ongoing
work,
but
we've
also
discussed
on
this
topic
with
giant
and
a
bit
with
i2
the
notion
of
adding
the
offnet
ingest
for
generic
multicast
as
well.
B
This
is
the
way
that
that
you
know
we're
aiming
to
deliver
traffic,
the
content
that
we
hope
to
bring
up,
and
so
it
would
it
would
be
a
good.
B
That
that
is
still
tentative.
We
haven't
begun
work
on
any
of
that,
but
but
yeah
we're
aiming
to
deploy
the
the
prototype
ingest
platform
and
start
sending
a
bit
of
stuff
in
there.
A
Yes,
and
and
jake,
were
you
gonna
talk
a
little
bit
more
about
that
in
your
next
presentation,
the
the
off
net.
B
Actually,
I
thought
you
were
going
to
mention
that,
but
it's
it's
the
same.
It's
that
same
architecture,
okay,
I
could.
A
I
thought
right.
B
There's
one
more
slide
I
started
adding,
which
is
which
is
not
just
a
single
path
back
to
the
to
a
root
but
a
path
to
many
external
non-multicast
links.
I
have
not
put
that
slide
into
the
into
the
current
deck.
It's
possible
to
pull
it
up.
If
anybody
wants
to
see
that
one,
but
that's
the
that's,
the
take
I've
been
using
on
the
i2
and
ngi
discussions
so
yeah,
but
it's
it
is
the
same
architecture.
B
You
just
have
to
think
of
a
few
different
ingest
points
with
potentially
virtual
links
back
back
to
them
from
from
you
know,
edge
bottlenecks
of
the
path
of
some
sort.
It's
really
just
for
the
rpf,
so
that,
instead
of
propagating
your
join
to
a
to
some
location,
that
does
not
have
a
multicast
capable
next
hop
for
the
rpf.
B
A
Cool
all
right,
any
other
questions
about
these
two
projects
or
deployments
or
any
interest
in,
like
I
said,
if
anybody's
interested
shoot
me
an
email,
but
any
other
questions
about
it.
A
B
I
think
I
I
think
I
asked
for
30
minutes.
If
I
remember
it,
I'm
surprised
to
see
that
I
have
60.,
okay,
great
so
I'll,
be
talking
about
the
status
on
on
these
drafts
that
are
working
group
items
and
the,
and
also
the
status
of
our
ongoing
effort
to
sort
of
turn
this
into
a
a
generalized
multi-kit.
You
know
democratization
of
multicast.
I've
heard
a
few
people
call
it
so
as
compared
to
last
time.
B
I
I
put
a
few
slides
in
here
just
to
give
a
reminder
sort
of
overview
of
what
this
architecture
is,
because
I
felt
in
the
last
couple
of
meetings
like
I've,
skimmed
it
and
there.
I
believe
there
are
some
new
people
who
might
be
seeing
some
of
this
for
the
first
time
or
weren't
there
in
the
in
the
earlier
presentations
about
these
things.
So
it'll
it'll
be
brief
and
hand
wavy,
but
it's
the
it's
the
overview
that
that
can
be
that
can
accompany
how
these
things
work.
B
I'll
give
an
update
on
the
on
the
status
of
our
of
our
outreach
efforts
and
and
the
ongoing
development
work
on
this,
and
then
the
next
steps
and
document
status
so
first
off
to
give
a
reminder
overview
of
how
mnat
works.
What
you
have
is
is
a
situation
where,
for
whatever
reason,
you've
got
an
internal
part
of
the
network
that
cannot
handle.
B
Cannot
handle
general
external
addresses?
We
encountered
a
few
of
these
in
the
trials
we
were
running.
I
put
some
of
the
motivations
list
in
the
in
the
m,
not
draft,
and
this
was
more
common
than
it
than
we
had
originally
expected.
B
B
But
the
idea
is
that
from
the
client
app
it's
the
same,
you
you
express
an
intent
to
join
an
sg
and
something
on
the
path
and
this
in
the
original
slides.
You
can
see
that
this
can
be
embedded
in
the
app
itself
or
it
can
be.
It
can
be
a
an
upstream
device,
such
as
a
home
gateway,
but
it
will.
B
It
will
be
in
communication
with
an
mnat
service
that
runs
the
mnat
server,
and
this
will
provide
a
mapping
from
the
external
global
sg
into
an
internal
within
this
network,
locally
assigned
sg,
and
then
this
this
local
assignment
is
what
gets
propagated
through
the
actual
multicast
portion
of
the
network
and
then
at
an
ingress
point.
B
It
would
translate
back
also
by
talking
to
the
mnot
service,
it
will
translate
back
into
the
global
sg
to
subscribe
externally,
and
what
this
allows
is
this
this
will
inter-operate
and
now
allow
the
client
device
to,
for
example,
with
the
authentication
through
ambi.
It's
it's
tied
to
the
global
addressing
scheme.
B
So
it's
important
that
the
client
understands
that
it's
trying
to
join
this
global
address,
but
because
of
various
kinds
of
workarounds
on
the
transport
side,
including
you
know,
either
v4
and
v6
networks
or
v6
and
v4
networks,
as
well
as
the
some
of
the
kinds
of
hardware
things.
I
think
I
have
a
slide
that
mentions
some
of
the
things
we
encountered.
B
B
It's
got
a
few
bugs,
but
it
seems
to
be
doing
okay
more
or
less
and
we're
we're
working
it
out
and
figuring
out
how
we're
gonna
get
like
a
a
suite
of
products
that
would
support
this
that
are
available
for
the
for
the
isps
to
consume.
B
B
Dorms
is
the
sort
of
substrate
for
communicating
for
communicating
metadata
about
sgs
in
in
general,
that
can
be
published
by
the
sender
of
the
sg
and
then
ambi
and
see
back
are
both
extensions
to
dorms
and
they
they
allow
for,
for
consumers
of
various
different
kinds,
including
the
receivers
and
and
on
path
devices
that
need
to
process
the
traffic
in
some
way
to
go,
find
out
what
that
metadata
is
going
to
be,
and
it's
just
a
sort
of
globally
discoverable
through
dns
and
then
through
a
standardized
web
api.
B
You
know
how
you
get
that
metadata,
so
the
idea
is
that
you
know
source
one
and
source
two.
They
each
just
publish
a
srv
record
in
the
dns,
and
this
this
refers
to
a
specific
known,
dorm
server.
This
could
be
the
same
dorm
server
for
the
two
sources,
but
it
doesn't
have
to
be
the
same
dorm
server,
so
the
source
knows
about
the
dorm
server.
B
That
has
the
information
that
it
manages
and
anybody
who
needs
to
discover
this
information
finds
out
that
dns
response
follows
it
to
to
connect
to
the
to
this
rest
count
server,
which
is
using,
then
the
dorms
yang
model
inside
it
inside
that
yang
model.
B
It
also
has
the
right
urls
to
go
to
to
get
the
authentication
stream
so
that
you
can
authenticate
the
data
as
well,
and
so
you
can
use
this
information
about
the
bandwidth
that
the
stream
is
going
to
carry
to
decide
whether,
as
a
network,
you
would
like
to
ingest
and
forward
this
traffic
so
that
you
don't
go
signing
up
for
100,
gigabit
stream
when
you're
you
know
a
10,
megabit
sort
of
provider
so
that
you
don't
have
any
sort
of
bandwidth
constraints.
B
These
dorm
servers
is
it's
just
using
http,
as
kind
of
the
way
to
and
yang
as
the
way
to
describe
the
structure
of
the
data
and
and
deliver
it
to
anybody
who's
asking
for
it.
So
it's
all
read-only
from
the
from
the
sort
of
generalized
access
and
in
fact,
typically
going
through
a
cdn
least
in
in
my
deployment,
and
then
you
know
you're
making
decisions
about
what
to
do
with
that,
based
on
the
the
rest
of
the
draft.
That
explains
how
you
process
that
data.
B
And
what
ambi
is
actually
doing
for
the
authentication
is,
is
all
the
packets
that
are
being
sent
over
the
network
to
be
delivered
through
through
you
know,
whatever
your
multicast
forwarding
technology
is
are
also
getting
hashes
of
those
packets
that
are
sent
through
a
sort
of
live
stream
that
carry
that's
that's
secured
that
carries
the
the
authentic
and
cryptographic
proof
that
the
the
a
sender
in
control
of
this,
this
secured
stream
knows
what
packets
were
being
sent
and
that
the
contents
have
not
been
modified
in
root.
B
So
so,
if
you
get
a
packet
that
doesn't
have
the
right
hash
on
it,
that's
on
that.
That's
on
that
channel.
It
means
it
either
got
modified
or
has
been
spoofed,
and
you
should
reject
it,
not
not
try
to
process
it
in
the
application
and
probably
also
in
the
network.
And
then,
if
you
get
any
hashes
for
which
the
packet
never
came
through,
then
you
can
treat
that
as
a
loss
and
and
respond
appropriately.
B
And
then
the
so.
These
are
the
basis
of
what
we're
using
to
try
to
to
try
to
build
out
the
the
browser
support
and
the
outreach
that
we're
engaged
in
started
with
the
isps
they
being
the
key
sort
of
components
of
making
sure
this
will
all
do
anything.
B
We
we
started
trials
with
five
isps
where
we
set
the
whole
thing
up
with
the
ingest
platform
and
and
made
it
run
with
the
gear
in
their
labs.
The
different
isps
we
engaged
with
had
a
mix
of
fiber
cable
dsl.
B
We
had
them
use
a
wi-fi
router
that
was
one
of
their
their
wi-fi
devices.
We
talked
with
them
about
the
practicality
of
getting
the
wi-fi
deployed.
In
some
cases
they
don't
control
all
of
the
wi-fi
routers
in
their
in
their
customer
base,
but
but
it's
sort
of
increasingly
common
that
they
have
a
significant
footprint.
That's
that's
amenable
to.
B
B
But
the
ones
that
that
looked
into
this
found
that
in
general
they
they
believe
sometimes
after
conversations
with
their
vendors
but
found
in
general.
They
believe
that
they
can.
B
They
can
drive
updates
of
those
to
ensure
there
is
support
for
the
at
the
wi-fi
layer
and
we're
able
to
get
the
get
the
the
devices
that
they
use
for
their
ordinary
networks
to
do
the
multicast
propagation
again.
Sometimes
this
needed
some
discussions
with
their
vendors,
but
but
in
general
they
got
this
working.
However,
three
of
them
needed
to
use
mnat
one
of
them
was
for
ipv6.
B
This
actually
was
they
ran
it
in.
They
ran
it
through
their
production
network.
For
that
one,
there
was
a
sort
of
lab
deployment
of
the
ingest,
but
there
was
a
production
on
that
receiver
that
they
that
they
were
using
to
do
the
receiving
of
the
traffic.
B
B
South
of
the
wi-fi
router
to
do
the
egress,
and
so
that
will
that
tended
to
indicate
to
us
that
we
we
might
need
to
bake
something
into
applications
in
order
to
do
the
m,
not
egress,
side
lenny,
it
looks
like
you've
got
a
question
just
stop
here
and
take
it.
Yes.
Can.
A
You
can
you
elaborate
a
little
bit
on
the
the
the
ones
that
needed
nat
and
that
just
what
those
use.
B
This
was
a
so
we
had,
we
had
v4
content
running
and
there
was
a
v6
only
network.
Now
we
would
have
been
willing
to
stand
up
v6
content,
but
we
thought
this
was
an
interesting
use
case
and
they
had
some
other
requirements
too.
One
of
the
requirements
was
that
that
the
source
of
the
traffic
had
to
be
from
inside
their
network,
so
it
had
to
use
one
of
their
assigned
ips.
B
This
was
a
a
business
requirement
from
their
side,
so
this
was
not
going
to
be
possible
to
integrate
with
the
authentication
scheme
using
the
global
ips
unless
we
arranged
something
in
that
way,
we
wanted
to
be
able
to
use
the
same
sort
of
globally
authenticated
delivery,
and
so
we
thought
this
was.
This
would
be
a
good.
You
know
this
was
after
we
had
already
gotten
em,
not
working
for
for
two
other
cases,
and
so
it
was
a
sort
of
natural
fit
to
keep
to
keep
trying
it.
B
I
think
there
might
be
like
other
approaches
that
could
do
this.
That
could
do
this
differently,
but
but
what
we,
what
we
did
is
with
the
external
traffic
we
it
it
actually
had
to
all
come
from.
It
had
to
use
the
same
group
for
traffic
from
the
same
sources.
B
So
it
was
kind
of
a
funny
setup
where
what
we
had
was
like
eight
or
ten
different
source
ips
assigned
to
us,
and
they
were
all
mapped
through
the
mnat
server,
with
the
the
sort
of
per
you
know,
managed
by
that
network,
using
using
addresses
assigned
by
them
to
the
same
group
address,
and
then
the
the
receiver
would
still
join
according
to
the
the
globally
available
sgs
that
were
learned
by
the
application
and
using
the
same
traffic
as
other
people,
but
it
would
be
mapped
inside
the
network
into
this
sort
of
specialized
requirement
for
for
and
and
that
was
that
was
around
handling
their
rpf
constraints.
A
B
Correct,
no
s
local
g
local,
they
were
both.
They
were
both
remapped,
so
you,
you
could
stick
anything
into
the
into
the
assignment
pool
you
know,
but
but
in
in
fact,
for
this
it
was
a
a
local
group
assignment
also
so
there
I
can.
I
can
speak
to
another
case
we
encountered
as
well.
There
was
actually,
I
think
I
mentioned
it
here-
the
there
was
a
nokia
olt.
B
I
believe
that
the
way
they
did
the
track
the
traffic
segregation
was
was
through
through
the
mac
address,
so
it
was
done
at
layer
two,
so
this
was
assigned
into
different
vlans
and
the
different
vlans
one
of
one
of
them
was
running
their
tv
service
on
it
and
they
wanted
to
make
sure
that
it
wasn't
that
that
that
that
was
kept
separate
from
this,
this
sort
of
off
net
multicast
that
they
were
going
to
forward
through
right.
B
So,
but
the
the
way
that
those
vlans
were
were
assigned
from
the
constraints
in
the
vendor
that
they
had
came
came
from
from
the
layer,
2
mac
address
assignment,
but
the
layer
2
mac
address
assignment
uses
only
so
this
was
ipv4,
so
it
uses
only
the
bottom
23
bits
of
the
of
the
ethernet
mac
address,
which
comes
from
the
bottom
23
bits
of
the
ip
address
and
there's
no
way
in
general
for
the
232
space
that
we
could
be
using
anything
to
to
avoid
colliding
on
that
bottom
23
bits
with
their
internally
assigned
groups
that
they
were
using
for
their
tv
service.
B
So
so
this
meant
that
the
traffic,
when
it
collided,
would
get
assigned
into
the
wrong
vlan
and
would
get
sent
to
like
their.
You
know
their
their
set-top
box
instead
of
being
sent
to
the
subscriber
that
was
that
was
trying
to
receive
it,
and
so
mnat
was
was
a
an
effective
workaround
for
that,
because
they
could
ensure
that
the
that
the
group
spaces
in
the
assignment
pool
just
were
divergent,
and
so
they
could
always.
They
could
always
make
sure
that
they
were
assigned
to
the
right
vlan.
B
There's
one
other
case:
there
was
somebody
we
we
actually
started
to
look
down
this
path
for
calyx,
I'm
not
sure
if,
if
it
would
have
panned
out,
but
we
we
ended
up
just
just
setting
it
aside
and
saying
that
it
wasn't
going
to
work
for
them,
but
the
idea
was:
was
that
and
we've
actually
encountered
this
in
a
couple
other
instances
as
well?
B
B
What
they
have
instead
is
a
sort
of,
in
some
cases
it's
just
sort
of
over
over
a
quan
layer,
for
instance,
that
I'm
not
sure
if
I
pronounce
it
right.
It's
qam
that
that
is
used
in
cable
and
what
they've
got
is
just
a
static
assignment
of
multicast
group
address
to
to
a
specific
comp,
qualm
and
then
so
they've
got
the
sort
of
list
of
static
group
addresses
that
they
use
for
their
most
popular
tv
stations
and,
and
sometimes
what
they'll
say
is
well.
B
I
guess,
as
long
as
it's
under
the
the
rate
that
we
use
normally,
then
it
would
be
okay
for
us
to
take
our
our
few
least
popular
tv
stations
and
let
you
use
the
groups
that
are
assigned
to
those,
but
we
don't
want
to
reconfigure
the
network,
and
so
what
we'll
do
is,
and
so
for
this
case
mnat
actually
can
work.
Just
fine,
where
what
you
can
do
is
give
a
you
know.
The
the
pool
of
assignments
can
be
configured
to
whatever
those
static
groups.
B
Are
that
they've
that
they've
set
up
to
be
to
be
assigned
to
the
to
the
broadcast
transport
that
they're
sending
the
the
packets
over
and
then
and
then
it'll
get
cha
it'll
get
sent
through
without
having
to
reconfigure
all
their.
You
know
other
whatever
d,
slams
or
or
cmts's,
and
then
it
can
get.
You
know
unpacked
back
to
the
global
sg
back
on
the
back
south
of
the
of
that
access
layer,
so
that
that's
the
intended
operation
did
we
do
the
static
assignment,
I
think
the
well.
B
We
we
did
run
it
that
way.
I
think
it
was
because
what
we
did
in
practice
was
they
had
some
static
groups
that
they
configured
in
their
lab
setup
to
make
sure
that
that
would
be
okay,
but
but
I
think
that
one
was
a
a
little
bit
like
well.
B
We
think
this
will
map
to
the
same
thing,
so
it
was
perhaps
a
little
bit
less
realistic,
but
their
conclusion
is
that
they're
nonetheless
interested
in
investing
in
this,
if,
if
the
traffic's
actually
going
to
come,
and
if
other
people
invest
in
it
also,
hopefully
that
answers
your
question.
A
The
v6
case,
so
you
had
a
v6,
a
v4
source
and
you
need
to
get
it
to
a
v6
only
receiver.
So
you
essentially
translated.
B
It
so
it
was
actually
on
the
receiver
yeah.
They
only
had
v6
connectivity,
but
inside
it
can
yeah.
I
guess
I
guess
that's
the
case.
What
we
actually
did
was
we
ran
it
at
the
os
layer,
so
we
set
up
an
internal
interface
that
had
v4
connectivity
and
the
the
joins
were
routed
into
that
internal
interface,
and
then
that
interface
was
running
our
instance
of
the
m-nat
egress.
B
The
egress
was
talking
to
the
server
which
was
configured
with
the
assignment
pool
and
and
was
configured
with
the
upstream
being
the
actual.
They
just
had
the
the
one
upstream
interface
for
the
for
the
received
device,
and
so
on
that
external
interface
for
the
for
the
actual
receive
device
it
had
been
turned
into
a
v6
join,
and
so
the
only
thing
that
the
network
saw
was
the
b6
join,
except
just
right
inside
the
the
m-nat
server
and
the
egress
and
ingress.
A
B
B
I
was
actually
looking
for
a
good
way
to
to
ensure
that,
with
a,
I
think,
that's
in
my
latest
version
of
the
draft
update,
which
I'm
not
sure
it's
posted
yet,
but
I
was
looking
for
a
way
to
ensure
that,
if
you've
set
the
source
address
to
a
v4
address
that
the
that
only
the
only
v4
addresses
appear
in
the
group
address
and-
and
vice
versa
for
v6-
which
I
I
haven't
seen
a
good
there's
like
ways
to
put
constraints
into
the
yang
model.
B
So
I
was
digging
around
on
that
a
little
bit.
I
think
I
did
it
through
a
regex
that
I'm
not
super
confident
about,
but
I'll
be
looking
for.
You
know
for
some
feedback
on
that.
At
some
point,
I
think
I
think
it
might
have
just
been
like.
Does
it
contain
a
colon
which
ip6
addresses
do
and
ip4
addresses
not
so
much,
but
but
there
might
be
a
better
one
to
use.
B
Right
but
yeah
I
mean
the
point.
The
point
being
that
that's
mentioned
is
one
of
the
use
cases
in
the
mnet
draft.
You
know
it
doesn't
need
any
special
defining
exactly
because
all
you
do
is
you
map
it
into
whatever
the
locally
assigned
address
is,
and
so
as
long
as
you're
allowed
to
specify
a
v6
address,
as
as
your
local
address
and
a
v4
address
is
your
local
address,
it
can
be
anything.
B
So
that's
so
it's
not
explicitly
called
out,
except
as
a
as
one
of
the
use
cases
that's
supported,
but
yeah
great,
oh
and
we're.
B
We
are
actively
continuing
some
talks
with
some
after
these
trials
have
concluded
we're
we're
following
up
with
some
other
isps
that
have
also
expressed
interest
in
and
deciding
whether
it
makes
sense
for
them
we're
basically
trying
to
drum
up
as
most
as
much
interest
as
we
can
at
this
point
and
sort
of
see,
do
we
really
have
the
critical
mass
to
to
roll
this
out
and
have
confidence
that
we're
going
to
be
able
to
deliver?
You
know
substantial
traffic
this
way.
B
Likewise
our
content
customers
with
the
prototypes
that
we
put
together.
We
we
believe
that
there
will
likely
be
some
changes
required
for
the
content
customers
for
the
video
side.
We
think
that
that
it,
it
can
be
done
in
most
cases
by
just
using
a
different
player,
but
sometimes
they
have
restrictions
on
their
players
and
on
on
you
know
wanting
like.
Sometimes
there
will
be
custom
extensions
to
the
player
that
they're
using
or
something
along
these
lines.
B
So
we
want
to
make
sure
that
that
it's
going
to
be
a
player
thing
that
can
make
sense.
Also,
the
you
know
the
browser
work
hasn't
hasn't
really
been
pinned
down,
yet
it
might
be
that
we
can
get
that
we
can
get
it
fully
transparent
and
put
into
the
browser,
at
least
for
segment
transport
for
the
video
support,
but
that's
all
sort
of
still
in
development.
B
So
I
think
it's
still
a
bit
of
a
moving
target
to
get
commitments
on,
but
we're
also
talking
with
with
some
of
the
customers
that
do
large
file
delivery,
use
cases
like
video
games
and
os
updates
and
looking
into
whether,
whether
something
that
looks
kind
of
like
our
prototype
can
be
reasonably
integrated
with
their
with
their
downloaders.
B
We
do
think
that
this
would
require
some
updates
to
the
software
of
the
downloaders,
but
they
all
have
that
kind
of
auto
update
capability
in
order
to
do
this
sort
of
thing,
and
so
we're
we're
trying
to
nail
down
evaluations
on
whether
that's
going
to
be
whether
that's
going
to
be
viable
so
that
they've
been
working
with
our
prototype
a
bit
and
and
looking
at
its
behavior
and
and
whether
we
need
to
develop
a
different
kind
of
protocol
or
use.
B
Something
else
in
there
is
is
still
a
sort
of
ongoing
thing,
but
we're
trying
to
nail
down
the
the
expectation
both
that
we'll
be
able
to
deliver
traffic
if
we
have
traffic
and
that
we
we
will
in
fact
be
able
to
deliver
the
the
the
content
customers.
We
have
will
in
fact
be
able
to
do
this
because
it
takes
it
takes
all
three
right:
it
takes
the
network
and
the
customer
and
the
cdn
any
of
us
can
say
we
don't
think
this
content
should
be
multicasted
right
now
and
then
it
would
not
be
multicasted.
B
B
But
we
think
that
that
particularly
for
these
big
events
there's
enough
value
in
making
it
multicast
that
as
long
as
we
all
all
three
do
want
to
do
it
that
that
it's
looking
like.
Maybe
we
can
get
this
to
happen,
I'm
calling
this
cautious
optimism.
I
think
it.
None
of
this
is
really
a
done
deal,
but
but
everyone
we've
talked
to
is
still
saying
this.
This
this
looks
like
it
might
work.
I
don't
see
anything
wrong
with
it
and
boy.
Would
it
be
nice
to
not
have
these?
B
You
know
havoc
wreaking
sorts
of
traffic
events.
You
know
several
times
a
year
in
some
cases
a
few
times
in
a
month,
so
yeah
so
the
the
browser
implementation
in
the
early
part
of
this
year.
We
we
tried
to
to
submit
it
into
chromium.
B
We
you
know,
I
think,
during
the
last
ietf
I
said
there
are
some
process
roadblocks,
but
it's
not
just
process
roadblocks.
It's
really
like
more,
like
technical
objections,
and
this
initial
submission
was
rejected
for
inclusion
in
chromium
as
an
experiment.
B
B
The
the
sort
of
key
takeaway
here
is
that
this
would
be
a
new
kind
of
mixed
content
and
it
would
be
not
appropriate
from
from
the
sort
of
chromium
network
development
team's
point
of
view
to
include
this
as
a
as
a
sort
of
chromium-led
experiment,
so
we're
we're
trying
to
gather
the
consensus
of
the
of
the
web
community
and
the
ietf
community
and
come
up
with
with
sort
of
a
well-documented
set
of
security
considerations
that
goes
with
this
we've
written
a
mostly
kyle,
I
should
say,
has
written
this
draft
for
for
the
multicast
security
considerations
targeted
toward
delivering
multicast
for
web
traffic.
B
Web
traffic,
of
course,
has
a
lot
of
security.
Work,
that's
been
done,
and
that
has
been.
You
know
necessary
for
the
development
of
the
web
over
the
internet,
and
we
are
keen
to
not
break
any
of
that.
You
know
so
we're
trying
to
make
sure
that
we
that
we
get
all
these
pieces
in
place
to
to
get
that
to
happen.
To
that
end,
we've
we've
created
a
a
w3c
community
group.
I
think
I
sent
out
a
note
about
that
to
the
list.
B
Actually,
I
think
somebody
else
sent
it
out.
First,
I
think
it
was
probably
brett
and
thank
you
brett,
I'm
trying
to
get
all
caught
up
on
on
keeping
everybody
in
the
loop
who
should
be
in
the
loop,
but
but
that
group
started
last
month.
I
believe-
and
we
are
starting
our
regular
monthly
meetings
first
wednesday
of
every
month,
starting
next
week
on
the
on
the
4th
of
august.
B
B
B
There
also
were
some
considerations
raised
about
the
one
of
the
things
that
was
said
as
a
minimum
for
web
traffic
is,
is
encryption
which
we
don't
have
as
part
of
ambi,
so
we're
looking
for
the
right
solution
on
how
to
approach
that-
and
this
is
this-
is
one
of
the
key
questions
in
the
security
considerations
document
is
about
like
when
you
have
a
a
encrypted
session.
That's
one
to
many.
B
What
are
the
the
sort
of
constraints
on
the
kind
of
traffic
that
can
be
on
that
to
so
that
this
is?
This
can
be
a
safe
communication
and
what
is
the
threat
model
for
which
encryption
provides
some
level
of
protection?
B
We
think
there
is
perhaps
some
which
was
one
of
the
outcomes
of
the
of
the
netdead
thread
discussion,
there's
a
link
on
on
the
slide,
but
that
is-
and
that's
you
know
it
isn't
a
very
fine
point-
that
for
anyone
not
in
possession
of
the
decryption
key
it
is,
it
is
hidden
from
their
view
if
it
is
encrypted,
and
so
this
does
prevent
some
passive
on-path
sniffing
attacks
and
require
them
to
become
active
in
some
sense
to
obtain
a
key,
perhaps
without
authorization
or
perhaps
with
without
authorization,
to
use
it
in
the
way
that
they
were
that
they
would
need
to
use
it
for,
for
you
know,
providing
a
threat
model.
B
I
think
that
discussion
is
is
really
just
getting
started
and
there
is
some
risk
that
the
conclusion
would
be
that
there
should
be
no
ip
multicast
on
the
internet
according
to
a
security
perspective,
and
if
that's
the
kind
of
ietf
consensus
that
emerges
then
well,
we
can
close
this
group
down.
I
suspect,
but
I
don't
think
that's
really
what
it
should
be,
because
it
just
moves
the
security
problems
elsewhere
in
the
in
the
ecosystem.
B
In
there
there
was
a
there
was
a
side
meeting
yesterday
that
that
went
pretty
well
where
we
we
talked
about
some
of
these
ideas,
and
you
know
I
specifically
asked
if
anybody
thought
that
this
is
doomed
and
a
bad
idea
and
among
the
people
who
chose
to
join
that
side
meeting.
Nobody
thought
that
so
that
was
good,
but
I
think
that
there's
there's
still
some.
B
You
know
a
few
miles
to
cross
before
we
get
before.
We
really
have
ietf
consensus
that
that
this
is
going
to
be
possible
to
do
in
a
secure
way,
but
we're
trying
to
get
all
those
t's
crossed
and
eyes
dotted
as
we
as
we
move
this
forward.
So
we'll
see
how
that
discussion
goes
we're
trying
to
find
the
right
itf
venue
for
that
discussion.
Certainly,
I
encourage
people
to
join
the
w3c
multicast
group.
B
That's
a
multicast
community
group
and
discuss
and
and
raise
concerns
on
there
and
we'll
see
if
we
can
get
them
addressed
to
me.
These,
the
the
problems
that
have
been
raised
do
look
addressable
and
under
a
proper
consideration
of
the
threat
models.
I
think
we
can.
We
can
come
to
consensus,
there's
a
good
way
to
deliver
a
set
of
safe
traffic,
but
we
need
to
write
down
what
all
those
things
are
before
this
can
go
into
the
web
browser.
B
So
we
were
trying
to
do
that
in
the
meantime,
I'm
carrying
a
fork
of
chromium
and
anybody
who
wants
to
try
it
can
find
it
if
you
search
for
chromium.
I
hope
I
have
a
link
to
here,
but
I
can
send
it
if
I
need
to
and
I'll
follow
it,
but
it's
a
chromium
underscore
fork
under
the
grumpy
old,
troll
github
repo,
oh
yeah
there.
It
is
yes
right.
This
is
mostly
what
I
just
said
forgot.
I
had
another
slide
for
this.
B
So
oh,
there
is
one
one
other
point
here
this
one
of
the
big
options
for
for
doing
that.
Encryption
is
by
using
quick,
and
I
think
we
have
a
really
good
starting
point
there
in
the
in
the
already
currently
active
as
an
individual
draft.
The
draft
pardo
quick
http
emcast.
B
B
Sort
of
unicast
recovery
by
doing
range,
requests
of
known,
http
urls
for
any
missing
packets
that
can
be
detected
in
the
quickstream
there's
an
implementation
of
it,
and
so
this
is
our
sort
of
proposed
next
step
to
start
looking
at
this,
because
it
does
provide
for
encrypted
packets
using
using
the
symmetric
keys
that
are
part
of
the
quick
stream
and
then
we're
gonna
try
to
do
some
kind
of
an
integration
between
that
and
ambi
so
that
you
still
have
the
sort
of
hard
protection
for
for
the
authentication
and
the
the
the
kind
of
weaker
protection
for
encryption
that
you
get
out
of
out
of
sharing
the
decryption
keys.
B
But
there
is
no
need
under
ambi
to
share
any
sort
of
authentication
keys,
and
so
what
you
get
is
is
a
really
solid
authentication
protection
if
you
use
ambi
and
some
the
the
sort
of
hopefully
appropriate
degree
of
multicast
privacy
protection
through
and
confidentiality
protection
through,
that
you
can
get
through
the
use
of
shared
encryption.
Key
shared
decryption
keys,
at
least
in
a
multicast
stream.
B
So
so
yeah!
That's
our
that's
our
kind
of
next
project
that
we're
that
we're
going
to
be
trying
to
dig
into
and
make
sure
we
can
get
this
move
forward.
I
don't
exactly
know
how
long
it
will
take.
We
haven't
started
this
work
yet,
but
but
we
will
be
investigating
that
and
trying
to
make
sure
that
it
can
that
can
move
us
in
the
right
direction
and
actively
seeking
feedback
from
anyone
who
will
give
it
to
us.
B
But
if
you
want
to
try
it,
you
can
download
a
binary
from
here
that
will
run
on
on
debian
based
linuxes,
I
believe
and
and
please
do
participate
in
the
community
group.
If
you
can.
B
Yep
and
the
the
more
shielding
the
community
group
right
so
in
terms
of
our
ietf
docs,
I
did
some.
I
I
got
a
yang
doctor
review
from
from
rashad.
I
addressed
the
feedback
that
he
gave
in
the
dorms
and
see
back
drafts.
I
think
there's
some
similar
stuff,
that's
gonna,
go
into
ambi
and
actually
I'll
also
be
applying
some
of
the
concepts
in
mnat,
but
in
dorms
and
see
back
in
the
latest.
B
We
think
I
think
that
they're
that
they're
committed,
I
think
dorms-
might
be
ready
for
last
call.
I
don't
think
I
have
any
other
tbd's
in
there,
so
I
guess
I'd
like
to
start
the
dorm's
last
call.
B
I
was
thinking
about
it
and
I
think
it
makes
sense
to
do
the
dorms
last
call
ahead
of
trying
to
do
the
sea
back
in
ambi,
because
if
there
are
any
changes
that
end
up
needed
in
dorms,
then
it
may
impact
what
we
have
to
do
in
ambient
sea
back.
So
I'd
like
to
sort
of
get
dorms
pinned
down
and
then
and
then
have
that
ready
to
go.
B
There
were
some
substantial
updates
put
into
ambi,
there's
a
threat,
a
section
about
a
threat
model
and
made
the
the
manifest
scheme
more
extensible
with
the
tlv
space
it
looks
like
lenny
has
a
question.
A
Your
question
there
you
go
committing
them
together.
Can
you
hear
me
sorry
yeah
now
I
can
hear
you
at
one
point:
there
was
a
discussion
about
clustering,
the
documents
and
submitting
them
all
together
at
once.
Do
you
think
we
they
they
need
that
or
or
I
I
think.
B
B
Thoughts
on,
I
think
it
would
make
sense
to
put
them
in
a
cluster.
However,
I
don't
think
that
a
cluster
means
that
they
have
to
be
submitted
together.
If
I've
understood
it
correctly,
it
just
means
that
these
are
related
in
some
way
that
that
provides
value
in
in
keeping
them
linked
at
the
at
the
rfc,
editor
sort
of
level
and
right
now
in
dorms.
B
But
if
we
start
the
dorm's
last
call
send
it
to
the
iesg,
they
perhaps
approve
it
for
publication,
and
then
it
would
wait
in
the
rfc.
Editor's
queue
perhaps
perhaps
go
through
the
the
you
know.
B
I
guess
there's
the
off
48
sort
of
level
and
then
be
waiting
in
miss
ref
for
the
for
the
publication
of
the
of
the
cluster
documents,
because
there's
also,
even
though
I'd
like
to
have
the
the
spec
pin
down,
there's
not
much
value
in
publishing
it
as
an
rfc
until
there's
at
least
one
thing
that
extends
it.
B
So
you
know-
and
in
fact
both
of
these
are
going
to
be
necessary
before
if
ambi
is
the
way
we
do
the
authentication
before
it
can
go
in
the
browser,
although
there
might
be
some
value
in
doing
c
back
for
the
the
network.
Operators
even
before
ambi
is
done
so,
but.
A
Since
we
have
warren
on
our
a.d
warren,
do
you
have
any
guidance
advice
on
clustering?
Should
they
be
sent
together.
D
Or
not,
I
would
adjust,
I
would
suggest
getting
them
as
much
done
as
possible
and
they
can
just
sit
and
wait
in
the
rfc
editor
queue
and
miss
ref
state
until
other
things
happen.
That
way.
You
know,
there's
progress,
everybody
knows
what's
moving
along
and
you
don't
end
up
with
sort
of
making
many
tweaks
to
the
document
and
and
everything
waiting
on
everything
else.
B
No,
I
think,
I
think,
that's
good
feedback.
Thank
you
good
guidance,
so
yeah.
I
guess
in
that
sense
and
plus,
if
we
find
errata,
then
they
don't
have
to
you
know
they
don't
have.
They
can
still
be
done
if
it's
in
this
ref
is
that
right.
B
Great,
but
preferably
we
don't
need
any
errata
that
doesn't
always
work
out
so
anyway,
yeah
ambi
had
some
substantial
updates,
we'll
be
trying
to
fold
these
into
the
the
next
stage
of
the
implementation
work
we're
trying
to
to
start
doing
as
well
as
kind
of
get
that
discussion
rolling
on
the
security
considerations
and
getting
it
to
a
place.
We
can
seek
good
consensus
there
again.
B
We
haven't
fully
decided
whether
the
right
way
to
do
the
encryption
is
via
quick
or
via
some
kind
of
an
extension
to
amv.
That
adds
encryption
at
that
sort
of
layer,
I'm
leaning
toward
quick
if
we
can
get
it
to
to
work
right,
but
I
would,
I
would
still
take
ambi
as
a
extending
ambi,
in
some
sense,
to
provide
an
encryption
capability
either
as
a
separate
document
or
as
a
as
a
rev
on
the
current
document.
B
B
I
think
there's
there's
some
tbd's
fixed
in
c
back,
but
there's
still
some
remaining
work.
I
would
put
the
sort
of
how
to
handle
priority
properly
chief
among
them
anybody
who
wants
to
work
on
that.
Your
insight
would
be
welcome.
B
Mnat
has
a
few
pending
changes
that
have
not
been
submitted.
Yet
I
didn't,
I
didn't
get
the
latest
updates
in
and
then
you
know
some
bugs
in
the
implementation
that
I'll
be
trying
to
sort
out,
but
that
is
the
doc
status.
So
I
guess
the
main
action
I'm
looking
for
is
to
consider
the
the
last
call
of
dorms
at
the
stage.
A
Cool
so
I'll
make
it
a
plan
to
put
that
out
on
the
list.
If
you
don't
see
me
do
that
in
the
next
few
days.
That
means
I
forgot
so
feel
free
to
remind
me
and
we'll
send
out
a.
B
And
then,
actually
there
is
one
process
question
we
got
the
early
review
from
the
yang
doctor,
but
I
guess
there's
a
separate
last
call
review
from
the
yang
doctor,
I'm
not
sure
if
that's
relevant
or
and
which
comes
first,
the
working
group
last
caller.
The
link
yang
dr
last
call
review.
B
But
I
guess
I
should
confirm
with
rashad
that
the
current
edits
have
have
addressed
his
his
feedback
from
the
early
review
and
maybe
confirmed
that
that
there's
nothing
else,
he'd
like
to
see
different
and-
and
I
I'm
not
sure
if
I
should
do
that
before
the
last
call.
I
haven't
done
it
yet,
but
I.
A
Think
it
would
probably
be
a
good
night
that
that
seems
like
a
good
idea.
Just
you
know
he,
he
made
the
suggestions
and
he
would
for
the
review.
Maybe
you
know,
send
it
on
and
see
if
he
thumbs
up
on
those
and
then
you
know
at
the
same
time,
ask
you
know:
does
this
obviate
the
need
for
a
regular
review,
a
late
review,
or
is
this
good
enough
and
then
yeah?
Okay,
take
it
from.
B
There
sounds
good
to
me
all
right
so
I'll
do
that
and
then
ping
you
and
then
hopefully
we'll
be
ready
to
do
the
last
call
at
least
the
first
last
call
all
right.
I
think
that's
it.
B
E
Can
hear
you,
okay,
yeah
and
I
I
don't
have
a
question.
Actually
you
jake,
I
wanted
to
say,
kundos
to
all
the
work
that
you've
done
here.
I've
read
not
not
all
of
them,
as
I
said,
but
especially
the
ones
which
I
was
interested,
some
like
the
the
one
like
mnet
I
was.
E
I
was
really
pleasantly
surprised,
surprised
how
well
thought
through
that
is
and
yeah
if,
if
things
had
turned
out
a
little
bit
differently,
we
would
also
be
one
of
the
isps
to
use
that.
So
that's
definitely
something
where
I
can
see
a
good
use
of
implementation
for.
B
Great
thank
you.
I
appreciate
that
feedback
and
and
yeah.
That's
that's
good
to
hear.
I
I
think
there
are
still
some
improvements
to
make,
but
but
yeah
I
think
it's
I
think
it's
coming
along
and
I
was
I
also
have
been
pleasantly
surprised
with
like
how
well
mnat
has
worked
around
some
of
the
the
just
problems
in
practice
from
the
vendor
implementations
of
multicast,
that
you
know
that
the
isps
have
had
to
wrestle
with.
So
I
think
there
there
are
some
legs
there
that
that
might
be
useful,
yeah.
A
All
right:
well,
I
promised
we
would
be
done
early
and
we
are
so
go
enjoy
your
friday
afternoon,
at
least
until
the
next
working
group
and
thank
you
for
joining
and
hopefully
we'll
someday
have
another
we'll
meet
in
person
in
madrid.
But
I
don't
know
that
that's
going
to
happen,
but
if
not
we'll
do
this
online
again
and
look
forward
to
seeing
you
all
again,
then.
E
A
And
one
more
plug
stig
since
you're
you're
there
pim
working
group
is
coming
up
soon.
I
don't
know
if
it's
the
next
one
or
the
one
after
the
next,
but
I
think
it's
set.
It
might
be
in
three
hours,
but
the
day's
not
over,
don't
forget
pim.