►
From YouTube: SIG Network Gateway API meeting for 20230327
Description
SIG Network Gateway API meeting for 20230327
A
All
right
welcome
to
the
Gateway
API
meeting.
It
is
March
27,
at
least
in
North
America,
thanks
to
everyone
for
making
it
today
at
just
a
quick
reminder
that
this
is
a
kubernetes
community
meeting.
So
we
follow
the
same
guidelines
that
everyone
else
does
in
kubernetes,
which
really
is
just
be
nice
to
each
other
and
follow
our
code
of
conduct
thanks
so
much
again
for
everyone
being
here,
this
is
an
open
Agenda.
So
if
you
have
something
you'd
like
to
discuss,
please
add
it
to
the
agenda
at
any
point.
A
If
you
cannot
find
this
agenda,
please
add
something
in
chat
or
otherwise
and
we'll
make
sure
to
link
it
to
you
also,
a
quick
reminder,
if
you
don't
mind,
we've
been
trying
to
track
attendance.
So
if
you
can
add
your
name
to
this
list,
it
helps
us
understand
what
times
work
best
for
everyone.
We've
been
trying
to
experiment
with
other
times,
I
think
we'll
have
another
more
Europe
friendly
time
coming
up
sometime
soon
to
be
determined,
and
it
helps
us
understand
what
times
work
best
for
the
majority
of
people
yeah.
A
Okay.
So
with
that,
let's
get
into
the
agenda.
The
first
thing
this
is
from
Nick
Shane
and
myself
is
just
we
have
been
trying
for
a
while
to
figure
out
what
our
path
to
GA
looks
like
and
I
think
we
need
to
be
very
intentional
about
prioritizing
things
that
are
on
that
path
to
ga,
so
this
doc
outlines
a
path
for
us
to
do
that.
A
A
It's
centralized
conformance,
reporting,
automatic,
automated
vulnerability
scanning
and
a
migration
to
the
production
kubernetes
registry-
some
of
you
may
have
not
have
noticed,
but
we're
still
using
staging
images
which
works
for
now,
but
we
do
need
to
move
over
to
production
sometime
soon,
so
we
have
I
think
that's
really
the
main
release
blockers
we
have
in
the
1.0
Milestone,
but
you
know
this
project
has
been
around
for
a
while.
It's
widely
used
it's
used
in
production.
A
You
know
lots
of
companies
are
Building
Products
off
of
this,
and
it's
really,
you
know
not
even
accurate
anymore.
To
call
this.
You
know
non-ga,
you
know
we.
We
have
people
that
are
relying
on
this
in
production
and
we
need
to
make
the
OSS
project
catch
up
to
that
state.
A
So
what
we're
like?
What
we're
left
with
is
this
this
world,
where
we
have
a
limited
set
of
capabilities,
and
everyone
wants
to
get
everything
possible
in
and
there's
there's
only
so
much
time
and
every
new
feature.
We
consider
there's
a
significant
amount
of
work
that
goes
to
the
proposers
maintainers
implementers
and
everyone
everywhere
in
between,
and
we
need
to
be
cognizant
that,
although
all
these
features
are
are
very
good
and
something
like
that,
we
absolutely
want
to
get
into
the
API
at
some
point.
We
cannot
in
indefinitely
delay
GA.
A
So
we
need
to
make
sure
that
we
are
prioritizing
all
our
efforts
to
get
to
GA
and
then
fitting
in
features
as
as
there
is
time
so
yeah
that
that
means
that
we're
soon
going
to
be
trying
to
lock
in
the
content
that
we
ship
with
GA
and
putting
most
of
our
priority
on
those
issues
until
we
can
upgrade
to
ga
you
know
every
new
enhancement
proposal
out
there
does
include
some
value,
but
we
just
we
need
to
get
to
V
1.0
that
that's
you
know
high
level
goals
here.
A
Just
we
need
to
ship
1.0
I.
Think
all
of
us
want
to
ship
1.0
in
the
next
few
months,
certainly
before
kubecon
in
Chicago,
ideally
well
before
kubecon
in
Chicago.
So
this
is
not
meant
to
be
a
a
long-term
thing.
It's
just.
This
is
the
very
top
priority
of
Gateway
API
over
the
next
few
months,
so
we've
proposed
some
changes
to
help
get
us
to
1.0,
and
these
are
just
experiments.
A
A
For
after
070
is
released,
then
time
to
implement
those
enhancements
and
then
finally,
an
API
review
process
like
we're
familiar
with
and
release,
so
the
enhancement
review
this
this
for
people
who
have
worked
on
Upstream
kubernetes.
A
This
is
similar,
though
much
more
lightweight,
where
we're
trying
to
understand
which
enhancements
we're
targeting
and
what
we're
expecting
to
change
in
a
release
cycle,
and
then,
once
that
cutoff
is
complete,
we
know
the
scope
of
our
release
and
we're
doing
everything
we
can
to
implement
those
changes
and
if,
if
a
feature
just
does
not
make
it
in
the
cut
we'll,
we
may
need
to
roll
some
things
back,
but
again
the
focus
will
be
on
timely
releases
and
getting
to
1.0
as
quickly
as
we
recently
can.
A
Next
up
enhancement,
prioritization.
Well,
actually
let
me
I've
talked
for
a
long
time
before
I
go
any
further.
Are
there
any
questions
or
comments
about
any
part
of
this?
So
far,.
D
C
A
Yeah
you're
right
this-
that
is
something
that
I
am
very
very
invested
in
delivering,
but
I
have
missed
deadlines
many
many
times.
So
it
is
a
goal.
It
is
not
a
commitment,
yeah,
good,
good
point.
The
next
thing
on
this
list
is
enhancement.
Prioritization
I,
the
the
very
top
priorities
are
going
to
be,
basically
anything
that
gets
between
us
and
releasing
ga.
A
So
that
includes
you
know
anything
that
when
we
go
to
Sig
Network,
API
review,
anything
that
say
Tim
or
Cal,
or
someone
at
that,
Sig
Network
level
considers
a
blocker
between
us
and
G8.
That's
going
to
be
a
top
priority,
anything
that
helps
improve
conformance
testing
and
coverage
for
existing
features,
taking
features
that
we
already
have
and
trying
to
get
them
up
to
standard
Channel,
clarifying
ambiguities
and
existing
features
and
then
finally,
existing
proposals
that
are
awfully
close
and
have
a
clear
path
to
experimental.
A
Those
will
be
prioritized
as
well,
but
really
what
is
going
to
be
less
prioritized
at
this
point,
and
really
only
if
there's
time
are
the
features
that
are
not
well
defined
today
and
are
not
critical
between
this
and
GA.
That
does
not
mean
that
we
don't
want
them
in
the
API.
It's
just
that
we
have
to.
You
know
ruthlessly
prioritize
what
we
can,
what
we
can
accomplish
in
the
next
few
months
and
then
finally,
you
know
spreading
the
load.
A
You
know
a
big
part
of
this
is
that
there
is
a
finite
amount
of
maintainers
reviewers
approvers
Etc.
One
of
the
things
that
we're
trying
to
be
very
intentional
about
is
spreading
this
load.
We
I
appreciate
everyone
who's
volunteered.
Last
week
we
added
some
new
reviewers
for
conformance
tests.
Thank
you
to
everyone
who
volunteered
on
that
I
know.
That's
going
to
be
really
helpful
and
I
know
that
more
and
more
will
come
as
time
goes
on.
If
you're
interested
in
helping
us
get
to
GA,
definitely
don't
hesitate
to
reach
out.
A
We
can
always
use
more
help.
Yeah
with
that
yeah
I
think,
there's
a
question
and
Nick
you
volunteered
to
answer
it.
E
Yeah
so
grant
Grand
Austin
the
chat.
What
happens
after
GI
is
the
core
IPR
locked
in
and
do
we
have
to
wait
for
the
2.0
for
core
API
changes?
No
is
the
short
answer.
E
The
longer
more
interesting
answer
is
that
We've
designed
this
API
such
that
there
are
a
series
of
compatible
changes,
so
we
are
allowed
to
add
fields
and
may
there's
a
series
of
sort
of
other
changes
as
sort
of
defined
by
that
by
a
kubernetes
Upstream
that
are
non-breaking
added
API
changes
once
the
apis
go
V1,
then
then
we
will
be
able
to
do
continue
to
make
those
changes,
so
we
can
add
Fields,
but
what
the
V1
guarantee
means
is
that
is
that
practically
the
the
if
you,
after
we
have
released
for
V1.
E
If
you
write
something
with
the
V1
at
that
point,
then
that
will
always
continue
to
work.
You
know
there
might
be
additional
additional
optional
fields
that
we
add
or
something
like
that,
but
they
won't,
but
but
there
will
be
no
new
required
fields
or
behavior
changes
or
anything
like
that.
So
you
know
the
V1
guarantee.
Is
it's
stable?
You
know
you,
you
don't
need
to
worry
about
the
the
types
I
was
changing
in
in
an
incompatible
or
breaking
way.
E
E
Yeah
thanks
that
was
a
good
explanation
and
Michaela.
Does
the
V1
guarantee
apply
to
status
conditions?
Yes,
it
will
that's
one
of
the
other
reasons.
You
know
why
we
have
been
trying
to
tidy
up
all
the
status
stuff.
Is
that
you
know
once
the
once
we
hit
V1
that
that
status
flow
is
going
to
be
set,
we
won't
be
able
to
change
the
status
conditions
and
stuff
as
well.
C
E
E
You
know
it's
already
pretty
hard
to
keep
up
with
everything
that
everyone
is
talking
about
and
if
we
want
to
be
able
to
get
to
GA
we're
gonna
have
to
sort
of
yeah.
We
have
to
be
able
to
say,
like
we
need
to
focus
on
the
ga
stuff.
E
E
It
was
really
satisfying
to
be
working
on
something
that
people
are
happy
to
use
but
but
like
if
we
want
to
get
to
GA
we're
not
going
to
be
able
to
spend
give
a
lot
of
like
newer
stuff,
the
bandwidth
that
it
deserves,
and
so
what
I
think
one
of
the
things
that
Rob
has
call
that
if
you,
if
you
scroll
down
a
little
bit
more
Rob
Rob,
calls
out
at
the
bottom
so
yeah,
the
the
last
two
things
are,
the
gamma
is
going
to
continue
sort
of
rolling.
E
It
counts
under
the
already
on
the
on
track
to
experimental
rules
that
Rob
mentioned,
but
for
things
that
don't
that's
that
other
gaps
year,
section
that
are
already
in
progress,
you
know
there's.
So
there
are
some
things
where
we
may
need
to
say:
look
I'm,
sorry,
this
one's
too
big
and
is
not
required
for
GA.
So
it's
going
to
have
to
wait.
That
doesn't
mean
that
you
have
to
stop
developing
on
it.
E
The
part
of
the
point
of
what
we've
done
with
Gateway
API
is
that
there
are
a
few
ways
that
that
implementations,
I
would
love
to
see
implementations.
Do
implementation
specific
things
that
you
then
want
to
bring
bring
back
and
say:
hey,
we
did
this
in
our
implementation
and
here's
how
it
went.
That's
a
hundred
percent
fine!
E
You
know
for
things
particularly
once
we've
once
I
finally
managed
to
get
the
policy
attachment
changes
in
if
people
want
to
start,
you
know
experimenting
more
with
implementation,
specific
policies
that
would
be
really
useful
feedback
for
us
to
be
able
to
make
more
core
policies
as
well,
you
know
or
sorry
extended-
is
actually
more
correct
but
yeah
to
make
policies
that
are
included
in
the
standard
set
of
Gateway
API
resources.
E
You
know,
but
in
order
to
do
that,
we
need
to
know
what
works
and
what
doesn't
and
the
only
way
we're
going
to
do.
That
is
by
people
actually
trying
this
out
and
seeing
what
happens.
E
You
know
so
yeah,
and
there
are
a
few
other
extension
points
like
filters
and
things
like
that,
where
I
would
be
very
happy
to
see
people
do
their
own
filters
and
then
bring
them
back
post
GA
to
say
this
is
what
this
is,
what
we
tried-
and
this
is
how
it
worked
yeah
that
doesn't
mean
you
can
have
to
stop
developing
on
that
stuff.
It
just
means
that
we,
as
the
the
maintainers
and
approvers
won't
be
able
like
and
probably
won't
be
able
to
do
a
lot
of
work
on
that
stuff.
A
Yeah
well
said:
I
think
I
think
that's
a
really
good
summary.
Definitely
don't
hesitate
if
anyone
else
has
questions,
don't
hesitate
to
to
reach
out
to
in
chat
or
on
slack
wherever
this
is
really
just
meant
to
you
know,
help
us
get
to
GA
I
know.
Probably
everyone
on
this
call
would
really
benefit
from
the
API
formally
being
designated
as
GA.
So
all
the
products
we're
building
on
top
can
be
on
top
of
a
ga
API
instead
of
a
beta
one.
A
So
yeah,
that's
I,
think
we're
all
really
excited
about
that,
and
hopefully
we're
just
a
few
months
away
and
also
just
to
to
you
know
restate
what
Nick
already
said:
I
I
don't
want
this
to
affect
gamma
in
any
way.
You
know,
gamma
is
on
a
good
track
and
it
should
continue.
It's
still
a
priority.
It's
you
know
very
much
still
in
line
with
this
yeah
all
right.
Well,
thanks
everyone!
That's
that's
it
for
that.
One
I
think
I'll
keep
on
moving.
We've
got
lots
on
the
agenda.
A
Next
up
very
related.
You
may
have
noticed.
I
I
moved
around
some
agenda
items
a
little
bit.
I
think
we
may
be
doing
this
a
little
bit
more,
but
just
again
trying
to
keep
items
that
are
between
us
and
GA
at
the
top
of
the
agenda
and
then
items
that
may
not
be
quite
as
GA
important
a
little
bit
further
down.
So
it
looks
like
there's
one
hand,
so
Shane
go
ahead.
C
Yeah
I
was
just
gonna,
add
and
I
meant
to
add
this
at
the
end
of
the
last
section
that
for
anybody,
who's
looking
at
the
Milestone
V1
or
the
road
to
GA
project
board,
don't
consider
those
right
now
a
perfect
depiction
of
what
we
actually
expect
to
be
NGA.
We
are
still
doing
the
reduce
part
of
the
map
reduce
on
the
issues
there.
So
just
keep
in
mind
that
that
will
be
it
flux.
A
little
bit.
A
Yeah
good
point:
we
you
know,
thanks
in
large
part
to
Shane,
we
have
been
trying
to
do
more
project
management,
so
there's
a
v1.0
milestone,
project
board,
more
things
that
these
are
still
in
Flight,
but
we
are
very
much
trying
to
work
to
provide
a
a
clear
road
map.
If
you
have
an
issue
that
you
feel
like
should
be
a
ga
blocker,
please
make
sure
that
we're
aware
of
it
and
yeah.
We
want
to
make
sure
that
GA
blockers
are
very
clearly
highlighted,
even
in
in
that
doc.
A
There's
a
link
up
here
to
release
blocking
issues
in
the
v
1.0
Milestone.
So
we
have
a
release,
blocker
label
that
we're
applying
to
issues
and
if
they
happen
to
be
in
the
1.0
milestone.
These
are
the
things
that
we
consider
most
critical
between
us
and
1.0.
A
F
A
If
you
filter
for
release
Blocker,
we
have
seven.
Actually
some
of
these
shouldn't
be
in
here.
Well,
we'll
get.
Oh,
it
doesn't
include
the
Milestone
anymore.
We
will
get
there,
there's
only
one
that
is
in
the
vo70
Milestone.
Thank
you.
Okay,
I'll
figure
out
GitHub
one
of
these
days.
C
A
There's
only
one,
so
you
just
have
to
believe
me:
okay,
there
we
go
so
this
is
in.
Unfortunately,
we
have
a
PR
raised
today
to
address
this
one,
but
again
only
one
thing
currently
labeled
as
a
release.
Blocker
4070,
so
we
are
You
know
despite
many
more
things
being
in
the
nice
to
have
category
for
this
Milestone
they
may
just
get
dropped
if
we,
if
we
run
out
of
time
so
first
up,
let
me
run
through
the
major
themes
that
we
are.
G
G
D
Interrupt
yeah
I.
G
G
So
I've
had
some
issues
with
the
ready
first
programmed
status
on
Gateway
and
trying
to
implement
this
and
we've
kind
of
gone
in
a
lot
of
circles
on
the
Eastview
side
of
like
what
what
these
things
should
mean.
So
I
just
wanted
to
bring
it
up
here.
The
issue
that
we
see
is
that,
like
the
idea.
G
These
three
states
accepted,
which
means
like
this,
is
like
kind
of
cursory
level
correct
program,
which
means
we
send
some
config
to
the
proxy
and
then
ready,
which
means
it
is
a
100
guaranteed
that
no
eventual
consistency.
That
thing
is
ready,
I,
think
in
when
you
say
it
like
that,
it
makes
a
lot
of
sense,
but
when
you
get
down
to
it,
I
think
it
makes
a
bit
less
sense.
The
issue
I
have
is
that
ready
on
a
Gateway
I,
don't
think
provides
much
value.
G
Gateway
is
not
useful
without
its
policies,
most
particularly
the
routes
right.
A
Gateway
with
no
routes
does
nothing,
and
so
there's
no
like
as
an
implementation.
You
can't
say:
hey
here's,
my
route,
config
wait
for
the
gateway
to
be
ready
and
now
I
can
start
sending
traffic,
so
a
ready
condition
on
a
route.
I
think
may
make
sense
right.
G
You
apply
your
route
and
then
you
wait
for
it
to
be
ready,
and
then
you
send
your
traffic,
but
at
the
Gateway
it
seems
confusing
and
I
worry
that
by
having
a
ready
condition,
which
is
I,
think
what
users
will
most
likely
look
at
as
kind
of
their
Baseline,
because
it's
a
very
obvious
name
like
you
see
ready.
That's
what
you
wait
for
for
pods
for
deployments
for
services
whatever,
but
you're
very
used
to
looking
for
that.
That
can't
be
implemented
by
most
implementations,
because
most
implementations
are
eventually
consistent
and.
G
G
Just
kind
of
in
the
collection
of
pain
there,
so
my
proposal
I,
said:
remove
it
open
to
suggestions
on
Alternatives.
We
could
potentially
move
the
ready
condition
to
Route.
We
could
be
more
clear
about
what
it
means
open
to
ideas,
but
I
I
at
least
think
we
need
to
do
do
something
and
provide
some
some
value
here.
G
A
E
So
I
think
it's
fair
to
say
that
the
that
actually,
one
of
the
reasons
that
we
moved
ready
to
Extended
is
that,
as
John
said,
it's
very
it's
actually
very
difficult
to
implement
it
in
a
lot
of
implications,
certainly
in
certainly
in
Envoy,
it
is
almost
impossible
to
implement
because
the
because
of
the
way
XDS
Works
in
Envoy
the
you
most
of
the
way
that
people
do
it
is
you
sort
of
have
some
intermediate
model
and
that
model
generates
XDS
config
and
the
XDS
config
ends
up
in
Hawaii,
but
very
few
people
I,
don't
know
of
any.
E
Have
the
full
like
Loop
backwards
to
be
able
to
say
this
config
arrived
at
Envoy
and
it's
associated
with
this
kubernetes
resource
a
lot
of
the
time
which
kubernetes
resource
generates,
which
config
gets
lost
in
the
model,
and
so
it's
literally
impossible,
unless
you
specifically
build
your
entire
data
model
to
be
able
to
say
this
change
that
got
applied
to
end
Envoy
applies
to
this
specific.
You
know
it
came
from
this
HTTP
route,
and
so
that's
why
that's
why
we
wanted
to
add
programs,
because
programs
is
then
programmed
means.
E
We
sent
this
config
to
the
data
plane
right,
it'll
be
ready
soon.
You
know
that's
what
programmed
means
you
know
the
config
is
a
hunt
is
is
definitely
valid.
Everything
is
good
and
we've
sent
it
to
the
to
the
data
plane.
E
Not
you
know
the
data
plane
has
finished
programming,
that's
the
distinction
between
programmed
and
ready
is
programmed.
Is
we've
sent
the
config
to
the
data
plane
ready?
Is
we're
100
certain
that
everything
about
the
data
plane
is
finished
and
the
conf
and
the
config
is
ready
and
running,
and
you
can
pass
traffic
right
now
as
soon
as
you
see
this,
and
so
it's
a
much
much
much
stronger
guarantee,
that's
actually
extremely
difficult
to
win
bordering
on
impossible
to
implement
for
at
least
for
Envoy
based
style
points.
C
No,
that's,
okay,
we're
covering
some
of
what
I
wanted
to
say.
I
think
I
appreciate
John
that
you're
like
raising
this,
especially
since
you've
gone
and
tried
to
do
it
just
so
we're
clear
the
the
problem
is
kind
of
because
okay,
so
it's
extended
so
like
assuming
it
didn't
exist.
It
kind
of
sounds
like
you
could
work
with
it,
not
existing
like
with
everything
else
that.
C
G
The
thing
that's
confusing
I
think
is
that
people
don't
understand
what
it
means,
even
in
the
chat,
I
think,
there's
people,
misunderstanding
it
and
I
think
a
user
like
basically
I,
went
and
said.
Okay,
you
still
can't
properly
sport
ready,
because
it's
very,
very,
very
hard
and
so
I
removed
it.
And
then
we
have
like
our
docs
writers
and
users
and
stuff
like
we
suddenly
got
10
different
people
were
messaging
to
be
like
what
the
hell
it's
never
ready.
I'm
like
well
technically
the
spec
says
that
ready
means
this.
You
actually
want.
C
E
C
I
agree
with
the
general
sentiment
that
it
is
still,
despite
all
of
our
efforts,
a
little
bit
problematic
to
have
a
ready,
I,
don't
know
what
we
should
do
about
it
yet,
but
I
will
be
I'm
just
getting
back
from
a
couple
days.
Vacation
and
I
have
like
almost
100
notifications.
I
will
get
to
this
myself
and
start
reviewing
this
probably
tomorrow.
So
yeah.
E
So
I
think
the
I
don't
want
to
type
too
long,
because
John
you've
got
to
duck
off
about
I,
really
appreciate
you
raising
it
as
well.
Yeah
I
sort
of
only
responded
very
briefly
on
that
issue,
because
I
was
sort
of
still
thinking
about
it.
The
the
I
think
right
now
we
have
programmed
as
the
sort
of
the
this
is
implementable
and
you
can
watch
for
programs,
but
I
agree
that
having
both
programmed
and
ready
is
confusing.
E
G
No
thanks
just
real
quick
before
I
hop
off
I
just
want
to
say
thanks
thanks
for
having
me
cut
and
also
I
think
as
we're
talking
about
going
GA
when
we
have
this
field,
that's
very
wonky
and
that
I
don't
think
anyone
has
implemented.
That
feels
like
something
that
doesn't
make.
The
cut
for
GA
I'd
be
worried
about
G
Ang,
a
field
that
has
no
implementations.
G
Had
to
drop
but
one
last
thing,
and
my
next
thing
on
the
agenda
was
just
like
a
PR
to
get
people
to
look
at
it.
So
I
didn't
have
anything
to
talk
about
there.
It's
just
I,
don't
know
if
some
people
may
find
it
controversial,
so
I
stuck
it
on
the
agenda
and
with
that
I
will
drop
thanks.
Everyone
see
you
all
next
week.
A
Cool
good
good
discussion,
we'll
come
back
to
John's
next
item
soon,
but
I
think
that's
a
good
reminder
if
you
have
an
opinion
on
the
ready
condition.
Please
add
your
opinion
comment
whatever
on
that
issue.
It
is.
It
is
a
good
discussion
and
exactly
the
kind
of
discussions
we
should
be
having
before
we
think
about
GA
is:
are
there
things
in
the
API
that
don't
make
sense
that
we
should
not
graduate
to
ga
yeah
good
thoughts?
A
Okay
with
that
I
know
we're
we're
limited
on
time.
Here,
we've
got
plenty
more
to
get
through
so
I'm
going
to
go
back
to
where
we
were
first
off
in
the
070
Milestone.
Is
this
one
the
path
redirects
and
rewrites
I
believe
this
meets
all
the
graduation
criteria?
We
have
a
couple
LG
TMS
on
this.
Maybe
just
one
more
would
be
helpful.
A
Just
want
to
make
sure
we
have
as
many
approvals
as
possible
anytime,
we're
graduating
to
feature,
but
once
we
have
that
I'll
remove
the
hold
and
we
can
get
this
one
in
will
you
request
next
cool
the
next
one
is
very,
very
similar,
but
it
kind
of
just
flew
under
the
radar
I
completely
missed
this
and
apparently
made
a
typo
as
I
missed
it.
Sorry,
everyone
I
actually
had
request
header
modifier
the
first
time
around,
but
response
header
modifier
was
added,
which
is
nearly
identical.
A
It
is
identical
to
request
header
modifier,
just
obviously
modifies
response
headers.
Instead,
it's
been
around
long
enough.
It's
implemented
by
at
least
four
implementations.
Today
we
have
conformance
tests,
I
think
it
meets
all
the
graduation
criteria.
A
I
see
no
reason
not
to
try
and
include
this
in
070
as
well.
I
have
not
made
a
PR
for
it
because
it
will
conflict
almost
entirely
with
this
one.
So
once
this
gets
in,
we
can
worry
about
graduating
the
next
one
and
then
the
final
one.
That
I
think
is
a
big
big
deal.
That's
going
into
070.
Is
this
policy
attachment
Gap
from
Nick
that
this
is
just
a
massive
PR
I
I
have
spent
ages
trying
to
read
it
through
all
from
top
to
bottom,
and
it's
it's
well
written.
A
There's
a
ton
here,
I
encourage
everyone.
If
you
have
some
time
to
to
give
it
another
read
I
think
this
is,
in
my
opinion,
merging
in
the
next
couple
of
days.
I
I
think
it's
that
close.
So
if,
if
you
have
any
last
thoughts
or
comments
on
it,
get
them
in
soon
or
else
this,
this
is
going
to
merge.
A
Nick
you
you,
since
this
is
your
PR.
Do
you
have
anything
else
to
say
on
this
one.
E
No
I
think
I
think
that
this
should
make
it
a
lot
make
it
a
lot
easier
understand
what
policy
attachment
is
all
about
and
how
it
can
work
sort
of
the
root.
The
the
root
cause
here
was
Keith's
a
great
discussion
about
how
policy
technology
is
really
complex.
E
Part
of
the
point
of
this
is
to
more
fully
spec
out
exactly
what
policy
attachment
means
and
what
it
does
and
how
you
can
use
it,
and
I'm
and
I
mean
I
started
the
effort
to
work
on
timeout
policy
as
an
example
that,
if
it's
kind
of
stalled
because
I've
actually
been
really
busy
we're
trying
to
get
this
one
in
so
once
this
is
in
then
I
anticipate.
Circling
back
to
a
timeout
policy
to
try
and
have
a
standard.
E
Well,
not
standard
is
an
overloaded
word,
but
yeah
like
a
an
included
policy
in
the
in
our
cids
to
sort
of
illustrate
how
the
how
the
flow
can
work
so
yeah
yeah,
as
Rob
said,
you
know,
I'm,
really,
sorry
that
it's
like
plus
900
lines
you
know
of
like
pretty
heavy
text
but
yeah.
If
you
are
interested
in
it,
I
really
recommend
having
a
read
through
it.
E
B
A
Any
any
comments
on
this
one
I
just
have
to
say
thank
you,
Shane
Nick,
because
there's
there's
so
much
in
here,
yeah,
okay,
yeah,
huge
improvements
there,
the
the
next
thing
I
wanted
it.
This
I
feel
like
is
a
bit
of
a
stretch,
but
one
of
the
things
that
has
met
all
the
criteria,
with
the
exception
of
conformance
tests,
is
grpc
Route.
We
have
all
the
you
know,
all
the
implementations
we
expected
and
and
more,
but
we
just
need
conformance
tests.
D
A
I
think
this
is
the
pr
for
that.
Yes,
Richard
today
created
a
PR
that
adds
conformance
tests
and
it's
not
just
conformance
tests.
It's
actually
a
new
base
image
as
well,
so
there's
more
complicated
than
just
new
conformance
tests,
but
I
would
encourage
you
know
the
people
that
do
have
implementations
that
support
grpc
route.
If
you're
able
to
take
a
look
at
this
and
see
if
it
matches
your
expectations
and
your
implementation
of
the
API
that'd
be
really
helpful,
this
is
really
cutting
it
close,
but
I
would
love
to
see
it.
A
You
know
squeak
in
to
the
070
release,
but
to
do
that,
we
really
need
to
make
sure
these
conformance
tests
are
well
reviewed
and
that
we
have
a
few
different.
You
know
a
few
different
implementations
that
have
signed
off
and
said
this.
These
conformance
tests
make
sense
to
them.
C
Yeah
and
just
to
be
clear
that
doesn't
mean
you
have
to
be
marked
as
a
reviewer.
If
you
were
implementing
grpc
route
at
all,
we
would
love
to
have
you
help
review.
A
Yes,
yes,
that
is
thank
you.
I
I
know
all
this
process,
the
the
kubernetes
organization
and
and
how
we
review
PRS
and
what
what
not
is
not
obvious,
but
please
on
any
PR.
You
are
very
welcome
to
review.
Don't
don't
feel
like
you
need
to
be
explicitly
mentioned.
Sometimes
I
will
CC
a
couple
reviewers
that
I'm
thinking
could
be
helpful.
That
is
not
meant
to
be.
You
know
everyone
that
I
think
should
ever
review
it.
A
It's
just
you
know
these
people
in
particular
I
love
to
see
your
perspective,
but
please
anybody
out
there
the
more
feedback
we
can
get
the
better
it
is
so
you
know
in
this
case
there's
a
couple
Auto
assigned
reviewers,
but
we
really
want
as
many
people
as
possible,
yeah
good
point
Candace.
You
had
something
in
chat
still
trying
to
rewrite
the
get
for
TLS
data
plane.
A
I
I
know
that
this
is
something
that
is
is
very
important.
I
feel
like
we're
so
close
to
070,
I
I
can't
imagine
getting
a
new
cap
and
a
new
Gap
in
in
time
for
that,
but
that
does
not
mean
that
it
would
not
be
a
priority.
I,
just
I
don't
think
that
it's
possible
to
fit
into
070.
At
this
point,
I,
don't
know
I'll
defer
to
someone
else
here.
E
Yeah
I
think
I
think
that
sounds.
That
sounds
about
right
to
me,
but
I
think
it
is
also
important
to
note
that
that
timeline
that
Rob
mentions
does
not
preclude
us
doing
another
release
between
070
and
1.0
and
I.
Think
it's
pretty
likely
that
we
will
try
and
get
another
release
in
before
between
070
and
1.0,
probably
in
080..
D
E
Yeah
so
I
think
that
would
that
might
be
the
where
to
go.
There.
A
Yeah
yeah
well
said
yeah
this
this
is,
you
know.
Our
priority
is,
is
everything
that
is
you
know
between
us
and
GA?
I
would
not
be
surprised,
though
I
I
cannot
predict,
but
I
would
not
be
surprised
that
one
of
the
the
blockers
that
comes
back
from
the
the
Sig
Network
API
review
is
that
we
really
need
to
have.
You
know
TLS
to
back
in
solved
or
something
like
that.
I.
E
Mean
I
I
consider
it
I
considered
a
ga
blocker
anyway
like
like
we
need
we.
We
need
to
have
that
that
support
available,
so
I
could
use
a
jna
blocker.
You
know
we
need
to
have
something
done
before
GA,
but
I
just
I
think
we
are
out
of
time
for
us.
So
you
know,
particularly
because
we
would
like
to
have
070
out.
You
know
pre-qcon
and.
I
D
I
didn't
see
it
on
any
of
the
lists,
but
I
thought
I
had
seen
it
on
the
list
in
the
past.
So
that's
why
I
was
asking
about
it,
so
it
will
be
on
the
list
as
a
blocker
for
GA.
Where
does
it
depend
on
how
I.
A
Yeah
I
mean
it
I
think
both
you
know,
I
think
we
really
want
to
see
this
in
GA,
but
but
frankly,
it
just
means
that
we
need
to
heavily
prioritize
it
and
you
know
maybe
not
de-prioritized,
but
but
make
sure
that
that
this
is
is
one
of
the
top
things
that
we
are
pushing
forward.
A
I
know
I,
know
we're
all
invested
in
it
and
at
some
point
we
just
need
to
decide
on
a
solution
that
works
in
most
cases,
yeah
yeah,
but
I
I
I,
would
agree.
I
think
it's
it's
a
very
critical
issue.
C
I
yeah
I
think
the
the
main
answer,
the
thing
that
can
just
you're,
probably
looking
for
is,
we
will
be
getting
back
to
triaging
it
like
making
sure
that
we
finally
make
a
decision
for
you
on
like
exactly
where
we're
going
to
put
it,
and
we
will
keep
you
in
the
loop
on
that
we're
just
not
100
certain
right.
This
moment
that
has
to
do
with
the
kind
of
the
the
reduce
stuff
that
we're
still
doing
with
our
backlog
of
issues,
trying
to
make
sure
that
we
have
a
really
solid
GA
planned.
A
So
David
you're
you're,
asking
about
you,
mentioned
that
users
can't
specify
Upstream
backend
protocol
to
clarify
is.
Is
that
something?
That
is?
How
is
that
different
from
App
protocol
and
service.
I
There
were
I,
think
I
think
Evan
Anderson
made
a
PR
to
like
Contour
about
the
specifying
app
protocol
and
I.
Think
that
was
closed.
E
Think
I
think
it
turns
out
that
app
protocol
is
a
little
trickier
than
you
would
think
to
to
do
that
yeah!
It's
not
as
well
specified
as
you
would
like
I
think
yes,
yeah.
A
I
A
Yeah,
yeah
and-
and
you
know,
I
think
what
John's
saying
in
chat
is-
is
similar
to
kind
of
the
the
tough
decisions
that
we're
going
to
have
to
be
making
between
now
and
GA
is
what
is
what
is
new
functionality
and
what
is
truly
a
ga
blocker,
because,
most
anything
that's
additive
can
be
added
post.
Ga
we
just
have
to
you
know
what
what
is
truly
useful
as
GA
as
it
exists
today.
A
A
There
Keith
you're
right
there
is
a
cap
for
app
protocol.
This
is
actually
being
worked
on
by
lior
who's
been
helping
with
some
Gateway
API
things
too.
That
introduced
a
couple
standard
names
in
in
kubernetes
API
definitions
that
are
not
part
of
the
Ina
standard
service
names
that
were
previously
allowed.
So
it's
gradually
moving
forward,
but
I
feel
like
the
the
next
step
is
probably
going
to
be
that
something
like
a
list
is
required,
I'm,
not
sure
yet,
but
app
protocol
as
it
is,
is
it
needs
help.
A
But
that
may
be
something
that
can
you
know
move
forward
in
parallel,
yeah.
E
I
mean
the
practicalities
of
interacting
with
the
ga
Upstream
Resource,
as
we've
said
on
a
few
occasions,
are
that
adding
new
things
there
takes
a
long
time
far
longer
than
we
would
want
to
wait?
So,
yes,
I
I,
agree
that
it
seems
likely
that
some
form
of
meta
resources
will
probably
be
the
way
to
go
for
Gateway,
for
both
of
the
for
both
the
TLs
and
the
and
the
other
ones.
E
In
any
other
things
that
we
need
to
do
basically
all
the
stuff
that
we
talked
about
when
we're
talking
about
back-end
properties
and
the
problem
with
back-end
properties.
Was
we
tried
to
collapse
too
many
many
resources
into
one
and
I
mean
oh
I
am
worried
that
we
may
end
up
with
the
other
problem,
the
other
side
of
that
problem,
where
we
have
too
many
meta
resources.
E
You
know,
but
like
I'm,
hoping
that
we
can
keep
this
in
mind
and
thread.
The
needle
and
you
know,
arrive
at
some
reasonable,
yeah,
some
reasonable
middle
ground
that
is
actually
implementable
and,
more
importantly,
not
confusing
across
all
the
different
use
cases
that
people
might
want
to
put
it
to
I.
Think
the
other
problem
with
back-end
properties
was
I
had
a
lot
of
interaction
with
what
people
expect
out
of
gamma
and
and
things
like
that,
and
that
was
where
the
sum
of
the
sticking
points
came
up.
So
yeah.
E
A
Yep
yep
this
is
okay,
so
the
very
last
thing
I
had
in
here
was
another
thing
that
I
would
consider
a
release
blocker
for
070
I,
don't
think
I've
labeled
it
as
such,
but
we
need
to
have
conformance
tests,
handle
the
updated
or
redirect
requirements.
A
This
PR
attempts
to
do
that.
I
haven't
had
a
chance
to
look
at
it
in
detail.
But
again,
if
you
have
some
review
bandwidth,
I
would
do
everything
you
can
to
to
take
a
look
at
these
two
sets
of
PRS
that
are
related
to
conformance
tests
in
the
070
Milestone,
because
we
desperately
need
to
get
these
in
if
we
want
to
get
070
out
yeah.
A
Okay,
with
that,
let's,
let's
keep
on
moving
because
yeah
we
are
running
out
of
time.
Keith
I
think
you
said
you
could
provide
a
bit
of
context
on
John's
PR
here,
I.
H
D
F
H
Right
cool
so
yeah,
so
this
is
a
initial
PR
for
some
infrastructure,
slash
conformance
test
for
gamma
stuff.
The
actual
code
changes
to
the
conformance
test,
Suite
spec
Suite
code
is
not
too
much.
The
big
thing
that
I
believe
John
wanted
to
call
out
here
is
that
we
will
be
this
PR
deploys
the
istio
testing
app
container
for
for
writing
these
tests.
H
This
is
because
that
container
can
has
a
lot
of
utilities
for
essentially
saying
what
kinds
of
requests
you
want
to
be
sent
into
what
Target
the
current
kind
of
basic
implementation
for
this
as
a
first
pass,
is
just
using
coopsy
till
exec,
but
the
echo
test
server
that
istio
has
also
has
capabilities
to
to
send
requests
based
on
grpc
endpoints
that
you
send
to
that
container.
So
it's
got
a
lot
of
flexibility
here.
H
The
yeah,
the
the
question
here
is
about
how
how
far
to
go
using
this
using
this
image,
I
I
took
a
stab
at
implementing
something
similar
to
this
a
while
back
and
quickly
descended
too
deep
into
the
Rabbit
Hole
of
integrating
all
the
echo
tests.
Functionality
John
has
a
pretty
I.
Think
a
pretty
good.
You
know
measured
approach
here.
H
That's
that's
fairly
basic
and
I
think
it's
probably
non-controversial,
but
if
folks
have
any
concerns
on
using
istio
test
container
the
test
image
here
in
Gateway
API
tests,
you
know
let
that
be
known,
I
think
in
the
past
we've
discussed
potentially
moving
those
that
image
into
a
a
kind
of
a
wow.
H
That's
what
we're
looking
for,
like
a
third
party
or
external
repo,
or
even
extracting
out
the
istio
test,
Suite
or
a
test
framework
to
be
a
bit
more,
a
bit
more
lightweight
and
generic,
so
that
it
can
be
better
integrated
into
the
gateway
API
repo.
H
H
Do
you
want
this
split
world
to
do?
You
want
to
move
everything
to
the
existing
back
end
rebase,
everything
of
the
Echo
app
so
like
How
Deeply?
Do
you
want
to
integrate
the
Echo
app
into
Gateway
API
tests
there
again,
if
you
have
strong
opinions
on
port
forwarding,
which
is
more
complex,
but
a
very
a
lot
more
performance
for
security,
till
exec
bring
that
here,
John
says
via
the
chat
he
personally
like
to
keep
most
of
the
issue
stuff,
not
engaged
Gateway
API,
but
use
the
image
from
istio.
H
It
can
be
mirrored
somewhere
else.
So
yeah
that
is
kind
of
the
summary
foreign.
A
Yeah,
this
is
awesome
thanks,
Keith
and
John
for
the
updates
here,
I
I,
it's
exciting
to
see
just
the
the
initial
foundations
here
of
conformance
tests
for
gamma
I
would
say
you
know,
I
think,
as
as
both
of
you
kind
of
pointed
out,
that
this
is
overlapping
with
the
grpc
conformance
test
PR,
which
also
would
add
another
base
damage.
A
It
feels
like
there's,
maybe
a
future
where
we
can
use
a
single
base
image
for
all
the
things.
Even
if
that
base
image
is
pretty
heavy
weight
we'll
see,
but
it
definitely
seems
like
we're
going
to
need
to
find
a
way
to
include
conformance
based
images
inside
the
core
in
inside
Gateway
API
repository
so
far,
we've
avoided
that
Ingress
controller
conformance
repo
holds
our
current
edoe
base
image
for
Echo
server
yeah
we're
gonna
have
to
bring
images
into
here,
I
think,
and
we
can
figure
out
the
specifics
later.
E
Actually,
no
sorry,
it's
just
I
had
to
dial
in
from
my
phone,
because
and
so
I'm
navigating
the
risks
of
using
zoom
on
your
phone.
Nice.
B
F
So
I
think
I'd
be
open
to
using
you
know
a
different
base
image
for
geography,
conformance
testing,
it's
just
sort
of
the
devil's
in
the
details.
I'd
want
to
take
a
look
at
it
to
make
sure
that
it
supports
everything.
I
I
think
we
need.
H
It
John
Barber
put
a
point
in
the
chat:
I
I'm.
Not
maybe
I
misunderstood
you
Rob,
but
do
you?
Are
you
saying
you
think
that
there's
a
need
for
us
to
build
the
images
from
the
Gateway,
API
or
repo
in
my
mind,
I
think
we
could
probably
mirror
from
somewhere
or
build
images
elsewhere
rather
than
clog
the
repo
with
image
building
specifics,
but
I
just
want
to
clarify
kind
of
what
you
were
saying
earlier.
A
I
I'm
not
sure
where
it
belongs,
but
I
think
the
I
think.
The
thing
that
we
need
is
for
our
conformance
images
to
be
owned
by
the
Gateway
API
project.
That's
yeah!
It
may
not
need
to
be
in
the
exact
same
repo,
but
it
seems
like
it
would
be
most
efficient
if
they
were
owned.
B
A
Having
spent
very
little
time
thinking
of
it,
it
feels
weird
to
introduce
a
a
dependency
on
a
specific
implementation.
E
Yeah,
so
I
I
think
people
have
written
things
that
that
do
that
do
what
we
need
them
to
do.
I
think
that
Rob's.
One
is
fair,
though,
that
you
know
that
we
need
to
ensure
that
that
the
conformant,
the
images
we
are
using
for
testing
performance
are
sort
of
congruent
with
what
we
need
them
to
do,
and
so
that
means
probably
you
know.
Probably
we
will
need
to
include
those
images
in
the
in
the
release:
bundle
like
Adobe
versioned
in
the
same
way
or
something
like
that.
E
So,
regardless
of
how
we,
how
we
end
up
making
that
mechanically
work,
like
you
know,
version
1.0.0
of
Gateway
Pia
should
include
both
the
the
cids,
the
def,
like
the
spec
itself,
and
the
testing
tools
that
are
used
to
run
the
con
performance,
whether
those
be
the
admission
server
or
any
other
tools,
and
so,
if
they
are
under,
if
they're
having
the
code
live
somewhere
under
kubernetes
sigs
and
be
owned
by
Gateway
API,
some
project
will
make
processed
easier.
A
Yeah
I
I
think
that's
a
good
summary
of
my
point
and
also
Shane
you're,
completely
correct.
We
are
nearly
out
of
time.
So
let
me
move
on
from
this.
One
I
encourage
everyone
to
comment
on
this,
as
you
have
time,
but
yeah
thank
you
to
everyone.
Who's
worked
on
that
we
we
do
not
have
to
have
time
for
all
the
things
left
on
the
agenda.
A
Sorry,
everyone,
the
next
on
the
list,
is
the
address
scope,
one
which
I
think
we'll
only
be
able
to
cover
at
a
high
level
but
Dave
and
John
and
Nick
you're
all
involved
in
this
one.
I,
don't
know
who
wants
to
talk.
E
The
point
I
was
making
here
is
that
Con
in
its
current
design,
1651
has
has
addressed,
addresses,
be
scoped
at
the
individual
address
level,
John's
sort
of
initial
proposal
for
the
infrastructure,
stanza
proposers,
including
an
address
scope
there
I
think
the
biggest
difference
and
the
most
important
difference
there
is
that
that
means
the
the
two
approaches
are
that
gateways
can
have
multiple
multiple
addresses
with
multiple
scopes
or
gateways
only
have
a
single
scope,
and
you
can
have
multiple
addresses
within
that
same
scope,
which
would
imply
that
having
a
multiple
Scopes,
you
know
if
you
want
to
have
a
public
address
and
an
internal
address,
then
that
is
two
gateways
rather
than
one
Gateway
and
so
I
just
wanted
to
say.
E
I
think
that
is
a
pretty
important
distinction
that
we
need
to
decide
very
soon
for
one
year
that
I
feel
like
that.
That
exact
you
know
laying
out
what
we
want
to
decide
there
and
why
we
want
to
decide.
It
is
the
thing
that,
in
my
mind,
blocks
good
blocks
further
movement
on
1651,
which
I
think
which
to
be
clear,
we
need
to
do
something
about
the
dress
scope,
it's
a
real
problem
that
needs
to
be
solved.
E
You
know,
and
we
need
to
do
something
about
like
something
like
the
infrastructure
thing.
That
I
think
will
be
useful
in
a
lot
of
things.
I
would
really
like
to
unjam
the
sort
of
a
log
pile
we've
got
here
with
three
or
four
gets.
E
I
Yeah
I
think
I
don't
want
to
speak
for
John,
but
I
think
in
his
Gap.
He
said,
like
whatever
the
resolution
of
the
scope,
discussion
and
fixing
D1
like
I.
Don't
think
I,
don't
think
John
your
opinionated
about
that
I
like
having
the
multiple
scopes
on
Gateway.
I
Just
because,
like
it
kind
of
gives
you
then
like
submit
a
service
external
IP,
potentially
you
can
have
you
can
let
the
Gateway
infra
default
the
default,
addresses
and
Scopes
that
it
supports.
If
you
know
what
I
mean
like,
for
example,
service.
Also,
if
you
do
like
a
cluster
IP
and
a
public
IP
on
the
same
Gateway
and
you
know,
it'll
hit
the
same
Target
and
likewise
you
could
introduce
some
other
vendor
specific
scope.
I
There,
yeah
yeah
I,
would
encourage
people
to
read
1651,
because
I
try
to
answer
questions
like
what,
if
there's
conflicts,
then
I
would
say
then
like
then
you
would.
The
Gateway
wouldn't
be
accepted
if
there's
conflicts
with
the
class
and
things
like
that,
so
yeah.
E
I
mean
I
I.
Think
the
fundamental
decision
that
we
need
to
make
is,
can
a
Gateway
have
more
than
one
address
go
for
me,
I
feel
like
it
will
be
cleaner.
If
we
say
scope
is
like,
please
define
that
at
blur
Gateway
level,
and
if
you
want
two
Scopes,
you
have
two
gateways.
Http
routes
can
be
parented
by
more
than
one
Gateway,
so
yeah
you
can
still
have
the
same
routes
attached
to
two
gateways,
Each
of
which
have
separate
Scopes
I
am
worried
about.
E
If
we
have
one
Gateway,
possibly
having
multiple
Scopes,
then
we're
kind
of
like
it
that
feels
to
Magic.
That's
the
thing.
I'm
really
wary
of
from
service
is
having
things
be
too.
Magic
can
lead
to
weirdness
that
just
feels.
E
Prescription
so
I'll
put
a
comment
to
that
effect
on
our
1651
later
today.
E
We
should
talk
on
the
issues.
We
should
try
and
hit.
Sorry,
it's
yeah
Alex
is
one
about
policy
attachments
because
I
think
Alex.
Does
he.
A
Yeah
I
see
I,
see
Alex
on
the
list,
so
let's
try
and
squeeze
this
one
in
and
I
think
that'll
be
the
last
one
for
the
call
Alex.
Maybe
you
can
provide
a
bit
of
context
here.
B
Yeah,
so
so
yeah
we've
been
doing
this
as
part
of
quadrant
for
a
while
or
trying
to
do
this.
So
thanks
for
the
latest
state
of
policy
attachment
because
it
clears
many,
let's.
F
B
Darker
areas
of
the
spec
for
us,
and
so
us
Squadron,
and
we're
not
providing
a
complete
game
for
implementation
right
now,
we're
rely
on
istio
to
make
our
things
work
and
that's
both
for
rate
limiting
and
authentication
authorization,
but
so,
in
the
context
of
rate
limiting
we
have
a
rate
limit
policy
until
now
effectively
implemented
direct
before
it
was
a
thing
say:
we
ignored
the
hierarchical
part
because
yeah
that's
still
work
in
progress,
but
so
we
would
be
more
than
willing
to
put
some
effort
into
making
proposal
for
rate
limiting
as
part
of
Gateway
API,
but
not
as
filters
as
such,
but
Levering
policy
attachment
and
I
guess
like
it
was
mentioned
by
someone
to
actually
put
it
on
the
agenda.
B
If
we
have
time
for
this
still
I
don't
know,
but
so
that's
more
or
less
the
context
in
which
I
put
that
there.
Otherwise
I'll
stop
putting
things
down
in
a
dock
and
have
people
go
wild
at
it.
E
Yeah
I
think
that's
definitely
the
way
to
go
is
the
dock
is
the
way
to
go,
had
a
very,
very
high
level.
E
I
think
I
feel,
like
rate
living
could
be
done
with
either
a
filter,
a
policy
or
both,
possibly
a
combination
of
a
filter
and
a
policy
I've
tried
to
allow
for
that
in
the
new
version
of
the
Pirates,
due
to
Alex
to
have
a
read
through
the
new
policy,
the
positive
attachment
update
and
see
if
yeah
anything's
resonated
with
you
there
and
and
definitely
start
that
dog,
and
we
just
start
talking
about
it
like
we
said
I,
don't
think
rate
limiting
is
not
going
to
be
like
a
blocker
for
GA,
so
the
review
bandwidth
for
it
will
come
behind
the
other
stuff,
but,
like
I,
said
earlier,
I,
don't
think
that
that
means
we
should
stop.
E
It
just
means
yeah
that
we'll
need
to
talk
about
it
more
Candace.
We
absolutely
can
revisit
a
dress
code
next
week.
In
fact,
I
think
that
discussion
will
probably
be
ongoing
throughout
the
week
on
the
issues
as
well.
So
hopefully
we
should
have
a
better
summary
next
week.
A
Yeah
I
agree
with
everything.
I
know
we're
we're
at
time,
so
I
just
would
say,
as
closing
words
here
rate
limit
feels
like
it
belongs
in
the
API
somewhere,
whether
it's
a
policy
or
a
filter,
I,
don't
know
yet
I
would
love
to
see
someone
take
it
up
and
and
run
with
it.
I
do
want
to
set
expectations,
though,
like
like
Nick
said
it,
it's
likely
not
something
that
is
going
to
be
considered
a
ga
blocker.
So,
although
you
know
we
I
I
would
encourage
work
to
happen
here.
A
It's
not
going
to
get
the
same
level
of
review,
you
know,
and
it
will
probably
be
a
slower
review
process
and
than
than
other
features
that
might
be
GA
blocking
yeah
all
right.
Well,
thanks.
Everyone
well
I
said
we
didn't
get
to
sorry,
for
that.
Definitely
encourage
everyone
to
take
some
time
to
read
through
the
linked
issues
that
we
didn't
make
it
to
and
we'll
take
these
and
bring
them
up
to
the
agenda
for
next
time.