►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20221004
Description
Gateway API GAMMA Bi-Weekly Meeting for 20221004
A
All
right,
hello,
everybody
Welcome
to
the
October
4th
meeting
of
the
gamma
Gateway
API
meeting.
This
is
a
community
meeting
with
an
open
Agenda.
So
please
you've
got
a
topic
added
to
our
to
our
agenda
and
I'll.
Please
paste
the
link
here
and
the
chat
for
everyone.
As
a
reminder,
this
meeting
is
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
to
be
nice
to
everybody.
A
So
with
that
in
mind,
I'm
going
to
start
sharing
my
screen
and
we
can
start
chatting
about
some
of
our
agenda
items.
I
came
with
also,
please
add
your
name,
the
attendees
list,
so
we
could
have
a
record
of
your
attendance
and
no,
you
know
who's
interested
and
just
you
know
know
who
to
reach
out
to
and
get
to
know
other
people
in
our
community
all
right.
So
the
agenda
is
currently
occupied
by
just
a
topics
I
I
put
on
here.
A
A
It
is
the
month
of
kubecon
North
America,
which
is
crazy,
slightly
scary,
but
I
am
excited
to
be
able
to
be
in
Detroit
and
maybe
maybe
all
in
person
I
think
we
did
this
a
couple
weeks
ago,
and
you
know,
plans
may
have
changed
or
firmed
up,
but
the
show
of
raise
hands
and
zoom
who's
gonna
be
there
at
in
Detroit.
Here
in
a
couple
of
weeks,.
A
A
I'll
be
busy
most
of
Tuesday
at
service
mesh
Khan,
but
looking
forward
to
seeing
people
during
the
rest
of
the
week
and
hopefully
I
can
trip
Summit,
yeah
I,
don't
know
if
anybody
else,
that's
something
they
wanted
to
to
add
about
that.
But
looking
forward
to
meeting
y'all
go
ahead
or
obviously
yeah.
C
So
just
a
small
note
here,
I
was
chatting
with
Shane
earlier
I.
Think
almost
everyone
on
this
call
is
probably,
if
they're
going
to
be
there,
it's
probably
going
to
be
at
service
mesh
con.
But
if
you're
not
Tuesday
is
the
time
I'm
just
planning
on
working
chatting
about
Gateway
API
gamma,
whatever
so
I'll
be
around.
If
you
want
to
chat,
I,
think
Shane
will
too
so
happy
to
have
a
very
informal
working
session
for
anyone
not
at
service
mesh.
Con
I'm.
C
A
C
A
A
Okay,
so
anything
else
on
the
kubecon
can
trip.
Summit
sounds
like
we're
going
to
be
looking
for
that
list
of
Gateway
API
talks
to
look
at
and
schedule
and
find
time
to
to
hang
out.
We
gotta
go,
get
search
con
go
find
Rob
because
he
will
be
doing
a
a
working
session
somewhere.
So
awesome,
nothing
else
on
that
move
on
to
the
next
topic:
HTTP
route
Gap,
so
Mike
has
done
some
awesome
work
and
typing
up
this,
this
Beast
of
a
gap
for
HTTP
routes.
A
You
know
all
the
work
of
this
group
that
we've
done
over
the
past
couple
of
months
in
in
this
Gap,
so
again,
hats
off
to
Mike
and
everybody
else,
who's
contributed
time
and
ideas
and
energy
to
getting
this
in
the
you
know
into
a
spot
where
we
can
create
a
PR
for
it.
As
you
can
see,
I've
got
some
some
notes.
Thongs
to
haven't
finished,
reviewing
it,
but
please
take
a
look
at
this
and
get
your
reviews
in
for
for
this
HP
route
Gap.
A
This
is
one
of
the
foundational
pieces
of
gamma
and
what
we're
trying
to
do
so
if
you've
got
you
know,
knits
or
anything
about
the
approach.
This
is
the
time
to
get
those
in
and
I
I
called
out
here
in
the
here
and
okay
awesome,
yeah
Max
already
already
read
my
mind:
there
is
a
follow-up
Gap
that
is
planned
to
fill
in
some
of
the
integration
pieces
around
HTTP
routes,
Mac
I,
know
you're
I
see
you
typing.
Do
you
want
to
add
some
more
flavor
to
that
description?
A
And
I've
got
a
hardy
plus
one
to
taking
care
of
that
now,
because
this
is
absolutely
is
the
time
and
then
John
is
working
on
something
for
Consumer
HTTP
routes
as
well.
So
work
streams
are
starting
to
to
separate
here,
which
is
an
encouraging
sign
if
you've
got
questions
reach
out
to
those
pushing
those
efforts
forward,
yeah
any
questions
or
comments
there.
A
I
also
don't
know
if
it's
on
to
stock
I
think
I
do
okay,
all
right,
Mike
is
working
on
access
and
yeah.
There's
already
some
good
stuff
here,
make
sure
to
take
a
look
at
this
as
well
later.
Also,
please
remember,
to
add
your
name
to
the
attendees
list.
I
see
more
than
four
people
here,
so
that's
it
go
ahead.
Rob,
sorry,
yeah.
C
No
worries
I
just
had
you
know,
I
I
think
there's
lots
to
discuss
and
I'm
in
a
similar
State
as
you
keep
of
I
have
a
few
comments
and
have
not
finished
my
my
review
yet
of
this
Gap.
But
it's
work
in
progress,
but
one
thing
that
I
think
was
a
recurring
theme
in
in
terms
of
comments
was
at
least
I
was
confused
around
stateful
set
and
how
that
connected
here.
So
maybe
just
some
conversation
here
would
be
helpful
and
filling
that
in
I
don't
know
who
who
would
have
more
context,
but.
D
Probably
nobody,
because
that
really
just
came
out
of
an
effort,
the
that
Nick
suggested
really
trying
to
clarify
and
be
explicit
about
what
services
would
or
what
types
of
source
would
be
support
for
backends
and
parent
refs.
So
that
was
my
attempt
to
kind
of
go
through
exhaustively
and
say
this
looks
good
that
doesn't
look
good.
D
C
B
My
bias
right
now
is
to
have
as
few
things
in
that
list
as
we
can
get
away
with
to
play
with
and
yeah
I
mean
a
much
more
serious
note.
There
is
my
understanding
is
that
the
experimental
track
exists
to
make
it
possible
to
quickly
iterate
and
change
our
minds
about
things
and
so
I
lean
strongly
towards.
Let's
be
very
specific,
let's
allow
a
minimal
set
in
let's
play
with
it,
and
then
let's
find
out
what
we
need,
that
it
doesn't
offer
and
figure
out
how
to
deal
with
that.
B
B
A
To
agree
with
that
as
well,
I
think
it's
probably
a
better,
not
experience.
I
feel
like
it's
more
helpful
for
us
to
to
leave
it
open
and
then
let
people
go
play
with
it,
and
then
we
can
say
here's
exactly
why
we
did
we
support
sticker
sets
like
this
because
of
ABC
implementation.
Did
this
and
found
this
so
I
agree
with
that
approach.
A
A
We
are
speeding
through
this
agenda.
Maybe
we'll
have
a
gamma
meeting
that
ends
early
ooh
I
haven't
been
a
part
of
one
of
those
before
we
should
do
that:
okay
yeah.
So
the
last
topic
that
I
had
was
on
authorization
policy
attachment
I
missed
the
last
game
of
meeting
because
of
conflict,
but
granting
through
the
meeting
notes
that
seem
to
kind
of
be
where
a
lot
of
folks
felt
like
and
make
the
most
sense
to
start
investing
effort.
E
About
authorization
policy,
but
before
authorization
usually
comes
Authentication
and
I,
think
that's
something
we
need
to
probably
discuss,
because
Gateway
API
also
had
a
discussion
with
that
completely
strangely
named
capabilities
for
backend
or
back-end
capabilities,
and
it's
been
a
major
pain
for
istio
and
we
made
the
same
mistake
basically
with
the
back
end
capabilities
of
attaching
it
to
service,
and
it
was
a
disaster
and
and
hopefully
will
not
repeat
the
same
mistake.
But
realistically
we
need
to.
E
If,
if
we
want
to
discuss
how
authorization,
we
probably
need
to
have
a
stance
about
how
we
are
going
to
identify,
you
know
what
is
identity
of
a
workload.
If
we
want
to
depend
on
spiffy
or
not
or
what
identity
you
want
to
support.
And
how
do
we
want
to?
Represents
the
PV
certificate
son
of
the
server?
Because
that's
really
what
what's,
the
other
proposal
needs
to
address
and
all
the
related
issues,
and
maybe
that
should
go
before
before
the
authorization.
A
Okay,
I
I
want
to
to
posit
this
I
was
hoping
someone
bring
it
up
but
and
say
we
have
the
trouble
of
having
to
but
I'll
I'll
bring
it
up
now.
I
want
to
talk
about
whether
or
not
this
is
into
what
whether
or
not
into
what
degree
this
should
be
in
gamma.
To
begin
with,
policy
attachment
is
essentially
an
interface
and
Gateway
API.
A
It's
essentially,
you
know
a
format
template
that
a
resource
needs
to
follow
and
you
can
write
your
own
resource
to
handle
whatever
kind
of
policies
your
implementation
wants
for
mesh.
This
is
you
know,
authorization
policy
like
being
able
to
say
service,
a
cannot
talk
to
service.
B
is
one
of
the
foundational
principles
of
mesh,
and
it
probably
makes
sense
to
create
some
patterns
around
doing
so.
But
I
worry,
as
you
know,
to
some
stuff
cost
and
talk
about
earlier.
A
We
start
talking
about
certificates
and
spiffy,
and
things
like
that.
How
much
of
that
is
implementation?
Specific
and
I
I
worry
that
we
end
up
coupling
too
closely
to
a
particular
implementation.
If
we
start
down
that
rabbit
hole
before
deciding,
you
know
where
that
line
might
be
between
implementation,
specific
and
API,
that
that
gamma
is
seeking
to
be
yeah.
Flynn
you've
got
your
hand
up,
don't
know
if
that
was
what
you
were,
where
you
were
going
or
not,
but
feel
free
to
defer
or
whatever
it.
B
Was
related,
I
guess
the
way
I
put
this
is
that
I
kind
of
feel
like
author
Z
is
in
some
respects
easier
to
Define
than
auth,
n
and
so
I'm.
You
know
there
are
ways
I'm
more
comfortable
with
talking
about
auth,
Z
and
explicitly
kind
of
setting
aside
the
other
end
part
for
now,
but
but
on
the
other
hand,
your
question
about
all
right,
so
how
much
of
this
should
really
be
in
the
spec
is
really
interesting
and
it
makes
me
kind
of
Wonder.
Okay.
B
B
I
guess
I
guess
one
other
thing
I'll
say
about
autism
versus
authan
is
that
there
are
ways
I
feel
like
authentication
starts
to
defining
authentication
starts
to
become
more
of
a
problem
when
you're
talking
about
multiple
measures,
rather
than
just
a
single
mesh,
as
opposed
to
you
know,
auth
Z.
It's
not
unreasonable
to
necessarily
have
that
be
an
issue
with
just
a
single
mesh
and
I
think
I
stomped
on
Louis,
so
Louis.
What
were
you
about
to
say.
F
F
F
F
C
B
C
B
E
B
F
I
might
I
think
we
might
struggle
a
bit
to
Define
the
walk,
and
why
of
doing
that
when
the
binding
right,
the
one
thing
you
have
to
be
very
careful
with
anything,
that's
authorization
related.
Is
you
don't
want
it
to
binding
to
context
to
be
ambiguous
right,
the
more
levels
of
indirection
there
are
between
it
and
the
context,
the
more
likely
it
is
that
you
have
a
security
problem.
F
A
A
So
this
is
a
space
where
SMI
I
think
has
some
some
background
here,
because
an
SMI,
your
authorization
policy,
your
traffic,
Target
references,
a
route
and
that
has
caused
us
some
some
grief
because
you're
not
binding
to
workloads,
you're
binding
to
to
routes
and
when
reasoning
about
your
mesh,
it's
it's
a
bit.
It's
complex
to
it's
not
intuitive,
to
think.
Okay.
This
operation
policy
is
referring
to
this
particular
route,
but
not
the
particular
workload,
and
it's
very,
very
strange.
A
B
I
think
that
ends
up
being
strange
because
again,
the
application
developer
is
going
to
be
thinking
in
terms
of
I.
Am
implementing
this
thing
to
serve
a
particular
request
and
it's
dangerous
for
this
request.
To
not
be
you
know
it's
dangerous
for
some
random
Bozo
to
be
able
to
make
this
kind
of
request
from
the
developer's
perspective.
I,
don't
think
they
care
very
much
about
the
boundaries
between
workloads,
I
think
they're,
going
to
be
thinking
of
the
request,
as
the
first
class
object.
F
F
F
So
there
are
yeah,
there
are
operations
right
that
exist,
that
Developers,
like
people,
Services,
call
other
services.
They
call
Operations
right
and
this
there's
routing
right
which
affects
traffic,
and
then
there
is
authorization
which
affects
access,
but
they
can
exist
along
different
dimensions
right.
So
there
are
many
cases
when
in
an
authorization
policy,
you
will
say:
if
the
operation
is
this,
do
this
right
deny
or
allow?
F
And
so
intersecting
an
authorization
policy
domain
with
an
a
traffic
management
domain,
causes
life
cycle
issues
or
confusion
issues,
and
so
what
we
have
seen
historically
is
yes,
you
would
like
operation
classification.
You
would
like
to
know
you
know
what
the
things
people
are
calling
and
how
to
identify
them
and
have
a
kind
of
consistent
ontology
for
it,
but
you
actually
put
the
policies
in
different
places
because
they
actually
have
different
management
life
cycles.
B
F
The
like
one
of
the-
and
this
is
not
a
solved
problem,
an
issue
by
any
means
or
actually
I-
think
in
yeah
to
take
on,
is
to
actually
look
at
classification
of
operations
as
a
feature
independent
of
authorization
and
possibly
even
put
that
in
the
routing
API
right,
but
it's
it
would
require.
Some
thought.
I,
certainly
don't
feel
like
I
have
a
fully
refined
position
on
it
either.
E
But
our
way
I
think
there
is
a
lot
of
private
for
authorization.
I
mean
all
servers,
use
authorization
and
I
mean
for
Gateway
information
policy
is
kind
of
the
and
I
completely
agree
with
you
that
binding
to
workloads
and
what
network
policy
is
doing.
It's
the
established
pattern,
but
I
think
gateways
should
not
in
this
working
group
but
separately.
F
Yeah
I
agree
in
gateways
like
we
have
like
protocol
specific,
like
mechanisms
for
granting
and
delighting
access
to
traffic
right,
like
you
know,
circuit
breaker,
like
things
for
you,
know,
server
503.
If
these
conditions
hold
right
that
are
pretty
tightly
coupled
to
the
protocol
and
those
things
that
will
evolve
as
part
of
rep
right,
because
they're
they're
very
protocol
specific.
A
A
F
Right
namespaced
names
right
right,
you
can
assume
some
like
you
know.
You
know
service
account
at
you
know.
Cluster
namespace.luster.local
right
is
kind
of
I.
Think
the
idiom
right
right
spiffy
codifies
that
in
a
particular
screen
format.
You
could
pick
one
of
those
and
it
doesn't
matter
too
much
you
treat
them
as
strings.
You
compare
them.
F
If
you
need,
you
just
make
sure
your
different
authentication
systems
don't
produce
strings
like
collide
right
now.
You
have
to
like
things,
get
more
complicated
with
authentication
because
you
may
be.
You
may
identify
more
than
one
principle
at
a
time
right.
You
could
actually
have
layer,
principles
and
other
fun
stuff,
like
that,
like
user
and
service
all
happening
at
the
same
time,
giving
you
two
principles,
so
it's
not
trivial.
B
You
know
not
all
of
that
needs
to
happen
at
the
level
of
the
mesh
either
right.
No,
no
I'm,
just
you
know
yeah.
So
it's
you
can
also
do
things
where
the
mesh
takes
care
of
knowing
for
certain
that
the
workload
that's
calling
you
is
entitled
to
do
that
and
then
some
other
level
of
software
is
determining
whether
the
user
that
is
making
the
request
is
authorized
right.
B
E
F
Well,
I
mean
we
may
not
need
to
have
a
stance
per
se.
If
all
we're
defining
is
a
pattern
for
integrating
an
authorization
policy
and
not
actually
specifying
one
I
think
the
only
the
countervailing
pressure
to
that
is
standardizing.
An
authorization
policy
for
at
least
a
common
set
of
things
you
know
is
that
viewed
as
a
common
good
by
the
community.
F
A
I
there's
definitely
stuff
we
could
like
guidelines.
We
can
come
up
with
around
what
to
what
to
bind
your
policy
to,
but
at
the
same
time,
I'm
also
to
to
your
point,
Louie
I'm
I'm,
conscious
of
not
of
trying
to
rush
the
standardization,
you
know,
istio
has
its
things.
Notification
policy
it
might
want
to
fix.
Smi
has
its,
you
know,
I'm
sure,
console
and
all
the
implementations
probably
have
things
I'd
like
to
try
to
improve
about
the
prospective
implementation.
A
Is
this
the
right
juncture
to
standardize
around
things
for
in
in
kubernetes,
I
I?
Don't
know,
I
I
could
think
of
our
arguments
either
way.
My
gut
feeling
says
standardizing
like
a
Resource
Network
policies,
probably
not
where
you
want
to
go
for
this
specifically,
because
at
that
point
you
probably
need
we
probably
need
to
rope
in
sick
off.
F
F
And
you've
got
to
be
careful
with
egress,
because
sometimes
egress
is
just
East-West
by
another
name.
I
think
we
agree.
We
want
workload
attachment
right
or
if
you
don't,
if
you're,
not
doing
workload,
attachment
and
you're
doing
service
attachment,
then
you
need
to
be
well
aware
of
the
risks
that
you
are
presenting
and
talk
about
how
you're
mitigating
them.
F
F
F
A
B
E
E
You
have
to
get
to
extend
them
to
support
service
accountants,
whatever
use
cases
or
what
do
something
similar
with
them.
Instead
of
I
would
say:
I
agree,
we
don't
have
consensus,
but
maybe
it's
not
become
a
problem
to
how
to
attach
to
routes,
because,
maybe
that's
something
is
at
the
Gateway
should
address.
E
Not
necessarily
I'm
saying
that
our
policy
and
network
policy
should
not
be
completely
different,
and
if
you
can
express
something
with
network
policy,
I
mean
you
know,
with
label.
X
Y
allowed
to
talk
with
double
a
y
z.
Why
not
I
mean
it's
probably
more
efficient
anyway,
and
it's
already
implemented,
and
we
just
need
some
extension
to
specify
you
know
if
service
account,
which
hopefully
will
be
addressed
in
other
policy
or
for
you
can
find
a
way
to
so.
Basically,
we
kick
in
and
do
our
authorization
if
it
cannot
be
expressed.
E
E
F
F
So
it's
a
perfectly
valid
example
of
a
policy,
and
if
it
implemented
policy
on
service
account,
it
would
be
even
better
a
customer.
You
is
the
suggestion
you're
making
a
little
bit
more
prescriptive,
that
whatever
authorization
policy
a
mesh
implements,
it
should
not
collide
with
the
properties
of
Network
policy.
That
seems
a
little
bit
difficult
right
because
you
may
want
to
reason
about
both
a
pod
label
and
an
L7
protocol
appropriate
at
the
same
time,.
E
E
If
you
don't
have
any
L7
attribute,
you
should
be
able
to
pick
either
of
them
and
and
use
them
the
same
way.
So
if,
if
you
express
just
allow
access
from
Port
A
on
the
labels
ABC
to
put
the
tables
so
forth,
you
should
be
able
to
pick
either
of
them
and
have
the
same
effect.
There's
no
difference
if
you
use
one
or
the
other,
takes
a
performance.
A
So
I
want
to
suggest
something.
We've
talked
about
a
lot
of
great
stuff
here
around
authorization
policy
I,
because
it
makes
sense
to
do
kind
of
what
some
of
us
did
before
gamma
even
started
is
compile
the
prior
art
and
take
a
look
at
existing
policies
that
exist
between
different
mesh
implementations,
throw
Network
policy
in
there
and
then
pull
out
those
properties
that
make
sense,
and
then
let
that
guide
our
patterns,
around
authorization
policy.
A
A
You
know:
we've
scoped
things
down
considerably
to
get
us
moving
in
a
direction
and
to
start
trying
things
out.
There
needs
to
be
a
point.
I.
Imagine
where
we
revisit
some
of
our
decisions
in
light
of
things
that
we
previously
considered
out
of
scope
like
multi-cluster
or
deployments
models,
or
things
like
that.
I
personally,
don't
feel
like
that
problem
is
now
I
think
we
want
to
get
people.
We
want
to
get
this
in
the
hands
of
people,
get
the
HTTP
route,
get
them.
A
Let's
get
implementations
experimenting,
so
that's
where
I
land
on
that,
but
if
you,
you
know,
think
that
that's
awful,
please,
no!
Your
message
cost
about
including
non-mesh
K8
off-seat
traffic.
I
worry
a
bit
with
that.
Just
because
kubernetes,
like
policy
in
the
kubernetes
domain,
is
kind
of
what
we're
aiming
for.
We
explicitly
excluded
non-kh
workloads
in
our
original
service,
mesh
and
Gateway
API
get
so
I
would
say:
let's
try
to
limit
that
scope
of
the
initial
survey
to
mesh
and
Network
policy
and
things
that
exist
there.
A
B
E
I
think
it's
important
for
mesh,
probably
not,
but
it's
good
to
know,
keto
is
going
to
be
doing
and
what?
Because
it's
private
I
mean
it's
supposed
to.
You
know
to
not
repeat
the
mistakes.
Try
to
follow
patterns,
try
to
see
if
they're,
not
necessarily
to
do
exactly
what
they
are
doing,
but
to
have
them
okay.
This
is
what
other
people
are
doing.
We
are
doing
something
different
because.
E
F
F
D
B
F
B
F
A
Yeah
Alpha
fields
in
related
to
this
conversation
like
I
I,
was
thinking.
Okay
in
the
realm
of
spiffy
spire,
plus
oppa
plus
gatekeeper,
where,
like
what's
relevant
here,
I
feel
like
spiffy.
Spire
is
more
of
trust,
don't
don't
pun
intended
the
trust
domain
that
gets
part
of
that
area
which
is
distinct
from
authorization
policy
and
it
feels
like
oppa
and
external.
All
specifically
is
in
that
conversation,
so
I
can
I
can
add
some
that
stuff
to
be
added.
F
E
E
A
Yeah
I
think
well,
yeah
I
think
some
form
of
external
auth
I
know
it
should
eventually
be
in
scope
and
I.
Think
that
how
much
that
we
specify
implementation
should
have
to
have
for
external
op.
That
feels
kind
of
excessive
specification.
But
it's
important
for
implementations
to
have
I,
don't
know.
I
I.
B
E
B
E
B
A
I
agree
with
I
agree
with
that.
Flynn
and
I
also
feel
like
that's
one
of
the
reasons
why
I'm
hesitant
to
try
to
spec
this
out,
because
when
you
talk
about
different
data
planes,
so
envoy's
got
one
xdov
kind
of
protocol,
but
then
nginx
or
any
other
kind
of
data
plane
that's
going
to
be
making.
These
calls
might
have
a
completely
different
protocol
and
that
feels
like
a
spot
where
the
Gateway
API
for
the
Ingress
use
case
has
been
very
particular
about
stopping
short
of
those
things
that
are
going
to
be
data
plane.
B
F
B
I
don't
know,
could
go
and
call
out
to
your
pet
external
thing
that
you
wrote
all
the
code
for
and
it's
proprietary
and
all
that
is
one
thing.
Of
course
they
could
do
that.
We
don't
get
to
say
anything
about
the
implementation
at
all.
Having
a
way
to
say
you
know
here
is
a
very
broad
protocol
that
you
could
use
to
talk
to
an
exos
server
does
provide
some
utility
now.
A
A
Yep
agreed
and
I've
I've
got
an
action
at
him
to
to
create
the
doc
for
that
I'll
share
it
really
really
soon
and
yeah.
We
can
start
collecting
things
like
we
did
earlier
for
services
and
and
such
so
yeah
great
great
conversation.
This
was
this
was
good
I'm
excited
to
see
what,
where
the
various
different
implementations
start
pointing
to
where
that's
always
a
fun
experience.
A
Okay,
yeah,
we
are
here
at
Tom,
appreciate
everybody
attending.
The
next
meeting
will
be
at
8
A.M,
8,
AM,
Eastern,
Time
Pacific
time.
My
brain
is
all
fried
and
that'll
be
next
week.
One
thing
that
I
just
thought
about
in
the
minute
that
I've
got
left
I
feel
like
it's
pretty
safe
to
say:
we're
gonna
be
canceling
this
meeting
for
for
coupon
week.