►
From YouTube: Gateway API GAMMA Meeting for 20230131
Description
Gateway API GAMMA Meeting for 20230131
A
All
right
welcome
everybody
to
the
January
31st
Gateway
API
gamma
meeting.
A
Of
last
week's
meeting,
mostly
we
and,
of
course
the
recordings
should
be
available
on
the
YouTube
channel
if
you
wish
to
catch
up
on
the
full
content
yeah.
So
we
mostly
spend
a
lot
of
time
talking
about
API
review
needs
for
the
Gateway
API
zero,
seven,
zero
release.
We
do
not
have
a
specific
date
for
that.
A
Yet
I
know
that
Rob
was
proposing
something
in
like
the
one
to
two
months
range
from
now,
so
that
is
kind
of
like
a
like
rough
goal
to
keep
in
mind,
and
this
will
be
the
first
gateway
API
release
in
which
gamma
will
go
through,
like
the
actual
formal
API
review
process
in
the
060
release.
Again,
I
had
an
informational,
only
kind
of
like
a
light
review,
but
yeah.
A
We
should
definitely
expect
feedback
and
potential
changes
from
sync
Network
reviewers
as
part
of
this
review
and
yeah
so
kind
of
before
we
get
to
that
and
are
able
to
submit
for
that.
We
have
a
handful
of
issues
that
we
already
know
that
we
want
to
kind
of
wrap
up
and
play
up
Loose
Ends,
we're
tracking
them
in
this
milestone.
A
And
we
removed
one
that
was
related
to
policy
attachment
and
we
closed
out
to
with
one
of
the
PRS
that
we
finally
got
approval
and
I
I
guess
I
finally
got
around
to
you
know
a
final
lgtm
on
so
yeah
that
John's
PR
merged
and
that
closed
out
a
few
of
these.
So
we
have
really
two
things
left
to
kind
of
clarify
is
we're
on
conformance.
C
A
We
want
to
develop
a
test
plan
for
that
and
there
was
a
link
to
a
similar
test
plan
that
Sig
multi-cluster
had
written
up
for
some
of
their
intentions,
moving
forward
with
conformance
tests,
so
we
don't
necessarily
have
to
have
a
full
Suite
of
tests
and
a
framework
written,
but
we
should
at
least
have
a
documented
plan
of
how
we
intend
to
proceed
with
that.
A
So
that
is
one
goal,
and
the
other
one
is
just
clarifying
how
gateways
shoulder
should
not
interact
with
gamma
routing
configuration,
there's
a
pending
Gap
for
that
that
I
authored
a
few
months
ago,
and
we
should
probably
revisit-
and
it
probably
ends
up
being
a
like
thing.
That
does
not
need
to
be
a
full
Gap.
It
should
just
be
like
a
one
paragraph
PR
to
the
existing
Gap,
so
that
was
one
of
the
other
topics.
A
Is
we're
trying
to
just
really
consolidate
the
bulk
of
the
gamma
proposal
into
the
existing
Gap
1426,
rather
than
trying
any
substantial
new
page
on
the
website
or
spreading
it
across
several
gaps,
or
anything
like
that,
just
to
make
it
easier
for
API
reviewers.
A
And
oh,
so
this
is
a
link
to
the
closing
mesh
Services
through
gateways.
That's
we've
got
the
we'll,
probably
need
to
revisit
and.
A
This
is
just
another
thing
we
discussed
last
week
was
the
Gateway
API
TLS
use
cases
doc,
something
that
started
in
the
regular
Gateway
or
the
main
gateway
API
meeting
focused
on
TLS
root
and
other
like
re-encrypt
or
upgrade
type
use
cases.
A
It
may
be
worth
folks
taking
a
look
at
from
the
perspective
of
mesh,
even
if
it's
just
to
explicitly
State
what
we
do
and
don't
want
to
do
to
make
sure
that
I
know.
We've
captured
prior
discussions
around
trying
to
keep
like
mtls
from
service
to
service
outside
of
the
gamma
spec,
to
allow
room
for
things
like
wire,
Garden,
implementations
or
just
reducing
the
amount
of
user
facing
configuration,
that's
actually
necessary,
that's
something
that
could
easily
be
just
a
stated
expectation
without
exposing
it
to
end.
Users
need
to
configure.
D
A
Think
the
one
that
is
like
related,
that's,
like
gamma
relevant
for
PLS
use
cases,
is
like
the
application
like
direct
access
to
an
application
like
outside
of
mesh
use
cases.
There
was
there
was
something
like
that.
I
forget.
What's
in
the
stock
or
not
I
know
it's
something
that
John
has
brought
on
previously,
but
but
not
the
like
mesh
service
to
my
service
case
yeah.
B
A
That
is
most
of
what
was
spent
last
time
discussing
and.
B
A
So
this
was
a
very
significant
long-load.
Pr
I'd
have
jumped
a
lot
of
work
into
it
and
we
had
really
helpful
thoughtful
feedback
from
several
different
implementations.
I
really
appreciated
the
comments
from
Linker
D
folks,
metallion
Flynn,
and
as
well
as
Michael
Beaumont
from
Kuma,
who
kind
of
like
weighed
in
on
this
so
yeah
that
it's
a
substantial
expansion
of
the
Emma
scope
to
do
a
few
things,
including
adding
support
for
Consumer
defined
routes.
A
It
also
kind
of
relaxes
and
removes
some
of
the
restrictions
that
I
originally
had
in
the
initial
Gap.
So
it
allows
multiple
routes
targeting
the
same
service
parent
ref.
So
that
allows
you
to
split
configuration
and
then
have
those
routes
follow.
The
standard
merging
rules
that
already
exist
are
already
well
defined
in
Gateway
API,
and
it
also
allows
Crossing,
straights
backend
graphs,
explicitly
stating
that
that
should
be
handled
and
secured
through
like
mesh
office.
Sorry
I
was
I
was
like
I
had
like
the
console.
A
Specific
won't
turn
in
my
mind,
but
like
mess
off
the
functionality
rather
than
using
something
like
reference
correct.
A
This
also
had
a
smaller
PR
merch
into
it,
also
discards
into
the
same
time,
despite
the
closed
label
here
it
merged
into
the
other
one
and
is
now
included
in
the
full
get
so
this
expands,
let's
go
to
include
non-hdp
types
so
allowing
TCP
root,
prbc
root,
Etc
and
as
part
of
the
gamma
specs.
Let's
go
foreign
so.
A
That's
a
lot
I'll
pause
here.
What
what
questions
comments
or
other
things
do
folks
have
at
this
point,
I'll
stop
talking
for
a
minute.
E
I've
got
a
couple
of
thoughts,
so
one
have
to
see
those
PR's
get
merged
in
I.
Think
that
you've
been
to
the
point
where
the
original
design
is
is,
is
now
implementable
for
for
a
couple
different
implementations.
So
that's
I'm,
awesome,
I'm,
pretty
happy
with
when
it
comes
to
kind
of
remaining
work
and
my
cat
that
pulled
up
on
the
on
the
mall
storm
Milestone
born.
We
have
only
have
three
outstanding
items.
E
E
The
conformance
one
I'm
not
sure
that
that
that's
in
scope
for
like
the
implementable
bar
and
maybe
I'm
just
I,
misunderstood
something
from
our
previous
conversations
here,
but
my
understanding
is
that
we
needed
a
testing
plan,
but
not
necessarily
the
testing
framework.
So
maybe
the
scope
of
the
of
the
issue
might
need
to
be
worded,
but
we
have
to
be
reworded
but
like
when
I
read,
support,
testing
message,
implementations,
I'm
thinking,
I
can
bring
those
actual
like
framework
for
performance
tests.
E
Mega
discover
needs
to
be
used
to
be
like
dropped
down
or
another
issues
to
be
creative,
I'm
curious.
Other
other
stops
here.
A
Okay,
I
think
we're
on
the
same
page
in
terms
of
like
what
we
expect
to
deliver,
but
it
probably
is
useful
to
make
that
more
explicit
either
in
this
issue
or
removing
this
issue
from
the
Milestone
I
have
another
one
I.
A
To
kind
of
double
check
with
chain
on,
if
that
is
acceptable
for
API
review,
to
just
have
a
conformance
testing
documented
plan,
rather
than
the
full
framework
in
place.
B
B
F
I'm
pretty
hungry,
to
get
something
into
Kuma
in
case
that
cfp
goes
through
so.
F
I
have
a
cfp
with
somebody
from
Google
to
do
like
a
tandem,
istio
and
Kuma
doing
like
a
Gateway
API
from
Ingress
all
the
way
through
to
mesh
so
like.
We
would
show
HTTP
route
for
Ingress
and
then
HB
right.
D
F
But
even
without
that,
I
still
think
it's
reasonable
to
say.
Conformance
tests
are
in
place
we're
going
to
kind
of
call
that
the
the
next
the
next
flag
in
the
hill.
D
Yeah
Mike,
can
you
flip
back
to
the
the
issues
page?
There
you've
been
doing
a
ton
of
writing
on
this
stuff.
Do
you
want
to
assign
the
first
one
to
me,
I'll
trade,
that
one
for
yeah.
B
B
A
Now
that
it's
in
beta,
but
we
yeah,
if
we
still
want
to
propose
yeah,
we.
A
Online
about
this
I
would
definitely
appreciate.
D
Yeah
on
the
conformance
thing,
one
of
the
I
I'm
sure
I've
said
this
before,
but
I,
don't
remember
how
recently
one
of
the
things
that
has
long
been
a
little
frustrating
for
me
about
conformance
on
the
Ingress
side
of
the
Gateway
API
is
the
sense
that
it
was
written
for
cluster
providers
and
can
be
difficult
to
be
conformant.
If
you
don't
do
the
full
Dynamic
infrastructure
thing
and
it
would
be
really
really
nice
to
have
that
be
not
such
a
constraint
in
gamma.
D
So
can.
B
D
So,
and
and
I'll
rely
on
Shane
to
keep
me
honest
here
if
I'm
disparaging
the
Gateway
API
in
any
particular
way.
D
If
you
look
at
the
gate,
if
you
look
at
the
Gateway
API
and
you
look
at
the
conformance
tests,
they
have
a
strong
expectation
that
the
moment
you
create
a
Gateway
resource,
then
a
bunch
of
things
come
into
being
in
the
cluster
itself
and
as
such,
it
can
be
rather
difficult
to
be
conformant
with
Gateway
API.
If
you
want
to
use
a
model
where
somebody
you
know
a
developer,
for
example,
installs
an
Ingress
controller
and
then
creates
a
Gateway
resource
to
configure
it.
D
The
assumption
is
that
creating
the
Gateway
resource
effectively
installs
the
Ingress
controller.
This
is
a
frustrating
thing
in
some
cases,
for
example
with
Envoy
Gateway.
It
ends
up
introducing
a
fair
amount
of
complication
into
some
of
these
things.
It
would
be
really
nice
for
gamma
if
we
could
be
conformant
while
at
the
same
time
supporting
the
use
case
fully
supporting
the
use
case
where
your
four-person
startup
has
somebody
who
just
installs
Linker
D
and
then
throws
a
bunch
of
gamma
resources
at
it
to
configure
it.
G
Yeah
I
know
I
I
completely
agree
with
you,
just
just
going
to
suggest
that
it
means
about
this
week.
If
it's,
if
it's,
if
you
cannot
deploy
this
application,
Gateway,
whatever
resources
you
need
and
that
runs
and
tests,
then
I
suspect
it's
a
bugging.
The
is
a
test
written
to
fix
it
like
completely
activities
that
should
be
possible.
D
It's
it's
a
little
unclear
and
this
may
be
something
where
you
know.
Maybe
I
don't
know
Shane.
Maybe
you've
got
a
bunch
of
historical
light
to
share
share
here
right
it
yeah.
It
I
want
to
avoid
being
in
that
situation.
If
it
is
the
case
that
that's
an
error
in
interpretation
of
Gateway
API,
then
that
would
be
really
cool
to
know.
F
B
F
Idea,
yeah
yeah:
the
idea
that
you
have
to
provision
something
to
kind
of
fulfill.
Your
gateway
is
definitely
the
the
lean
of
the
Gateway
API.
However,
there
has
the
problem.
Let
me
collect
my
thoughts
for
a
second
there's.
Two
implementations
I'm
keenly
aware
of
they're,
not
the
only
implementations
but
contour
and
Kong
both
have
a
con
well
previously
conformant
I'm,
actually
not
sure
I
haven't
seen.
F
I
haven't
worked
on
that
team
in
a
bit,
so
I'm,
not
sure
of
the
exact,
like
conformance
level
today,
but
in
zero
five
one
where
conformant
Gateway
API
implementations,
that
allowed
was
called
a
static
mode,
which
is
an
existing
Gateway
or
a
Gateway
that
is
otherwise
provisioned
than
being
reflected
by
a
Gateway
resource.
That
does
happen.
It's
not
a
super
well
documented
or
trotted
path,
so
you're
right,
because
it's
not
well
documented
or
trodden
path,
there's
a
a
lien
towards
the
opposite,
but
it
is
something
that
is
done.
Conformally.
D
F
Saying
that
you
know
I
I
started
a
document
some
time
ago
for
this
exact
purpose,
because
I
was
working
on
implementing
at
the
time.
I
did
work
on
the
team
that
worked
on
that
particular
implementation
and
implemented
the
static
mode,
and
we
couldn't
really
agree
on
how
to
how
to
prescribe
what
people
should
do,
because
once
you're
in
that
mode,
it's
kind
of
really
up
to
like
with
when
you're
provisioning
a
Gateway.
F
It
gets
a
little
bit
more
simpler
to
tell
you
like
some
of
the
the
best
practices,
but
for
everybody's
implementation,
where
it's
like
the
Gateway
is
just
already
existing
or
otherwise
you
know
provisioned.
It
was
really
hard
to
come
to
agreement
on.
What
do
you
tell
somebody
how
to
implement
that
the
answer
kind
of
turned
out
to
be
just
make
it
conformant?
However,
you
do
that.
So
that's
why
it
kind
of
sucks
right
now,
yeah.
C
Yeah
I
was
going
to
say
like
if
you
look
at
like
the
cloud
providers
like
they
clearly
do
this,
because
you
can
set
addresses
on
the
Gateway,
but
it's
still
hard
to
do
that
in
the
conformance
test,
because
you'd
have
to
go
set
like
you
have
to
go
provision
like
I,
don't
know
10
different
things
and
then
go
set.
C
10
different
addresses
on
each
of
the
gateways
so
like
some
other
people
mentioned
like
istio,
also
supports
that,
like
using
the
same
address
field
but
I
think
there's
kind
of
two
two
things
that
come
out
of
this
to
me
is
one.
Maybe
the
conformance
test
should
have
an
easier
way
to
configure
those
types
of
things
yeah.
C
But
the
other
thing
as
well
is
it
sounds
like
we
all
have
methods
of
doing
it.
Kind
of
statically,
I.
C
Like
the
cloud
provider
was
obvious
right,
you
provide
a
pointer
to
your
IP
address
or
name
or
whatever,
it's
less
obvious
in
cluster
I
think
so
we
should
maybe
sync
up
and
make
sure
we're
all
doing
it
the
same
way
so
that
we
have
some
consistency.
Yeah.
F
Just
to
be
clear,
lots
of
people
are
doing
this
I
just
said
contouring
con,
because
I
know
the
code
fairly
well
for
these
yeah,
so
I
would
definitely
say.
An
action
item
to
take
here
would
be
create
some
kind
of
issue
discussion,
some
kind
of
follow-up,
so
that
we
can
do
exactly
what
John
just
suggested,
because
I
think
that's.
G
G
D
D
A
I
can
take
a
closer
look
at
our
tests,
but
I
know
that
we
have
an
issue
with
some
of
the
other
tests
in
the
suite
that,
like
spin
up
ad
hoc
resources
and
how
that
differs
from
like
the
resources
that
get
spun
up
in
the
beginning
of
the
suite
there's
some
issue
where
tests
that
need
to
spin
up
new
resources
within
the
scope
of
the
test
itself,
don't
seem
to
work
for
us,
but
so
yeah.
That
feels
potentially
relevant
to
this
discussion
too.
A
A
B
A
Sounds
good,
we'll
create
an
issue.
Shane
will
create
an
issue
for
follow-up
from
us
that
we.
B
A
A
Many
folks
here
probably
have
some
interest
in
it.
Potentially
overlaps
with
Gamma
or
mesh
cases.
It
also
potentially
could
be
implemented
as
a
standalone
like
egress,
Gateway
type
implementation,
so.
B
A
Probably
want
to
have
some
degree
of
flexibility
in
how
implementations
are
able
to
support
it,
but
there
should
probably
be
a
focus
on
defining
a
pattern
that
is
implementable,
either
with
Gateway
API
and
binding
routes
to
a
binding,
any
restaurants,
to
a
Gateway
or
through
gamma,
and
finding
something
like
the
consumer
routes
that
just
merged
which
are
effectively
a
sort
of
egress
type
routing,
depending
on
how
that
is
implemented,
whether
it's
at
a
sidecar
enforcing
it
or
whether
it's
at
like
a
namespace,
scoped,
egress,
proxy
or
something
else.
A
B
A
There's
a
discussion
that
is
scheduled
for
the
main
gateway
API
meeting
next
week
on
Monday,
so
definitely
would
encourage
folks
to
attend
that
if
you're
interested
in
that
discussion,
there's
also
a
doc
that
someone
started
around
egress
use
cases.
It's
some
interesting
context
particularly
focused
on
kind
of
like
the
Telco
world
and
their
use
cases
for
it
and.
A
I
think
this
is
like
from
and
two
and
references
this
branched
out
of
this
is
an
issue,
the
branched
out
of
comment
on
the
namespace
scope,
PR
that
just
merged
well.
This
is
potentially
relevant
just
in
the
context
of
a
syntax
that
may
be
applicable
to
egress
type
things.
A
A
D
Notes
here
that
makes
too
much
sense,
never
mind
I,
think
I
just
found
it.
A
There's
a
lot
of
content
there.
It's
it's
definitely
an
interesting,
read
and
I
think
there's
a
lot
to
think
about.
It's.
It's
egress
is
a
large
topic.
We've
touched
on
it
a
few
times
in
the
past
and
I
just
wanted
to
erase
it,
because
I
think
that
it's
definitely
relevant
to
the
needs
of
many
folks
here.
So.
D
A
Well,
that
brings
us
to
the
end
of
our
scheduled
agenda.
Is
there
anything
else
in
folks
find
that
I
want
to
talk
about
during
this
time.
B
G
A
That
is
in
this
Gateway
API,
TLS,
use
cases,
doc
and
I
believe
is
moving
forward
again
in
a
smaller
scope
in
the
main
gateway
API
meeting.
So
it
sounds
like
we're
moving
away
from
kind
of
the
overly
ambitious
back-end
properties
that
attempted
to
set
kind
of
like
a
template
for
doing
a
whole
bunch
of
other
things.
Instead
focus
on
just
the
narrow
case
of
decrypt
and
re-encrypt,
or
upgrade
and
unencrypted
connection
to
the
back
and
then
being
able
to
specify
that
potentially
through
a
custom
filter
or
something
like
that.
G
Yeah
I
know
I
already
did
no.
There
is.
There
is
a
discussion
in
Chinese
about
the
customizing
H2
settings,
you
know,
so
you
can
Max
connections
marks
whatever
window
sizes
whatever
and
and
I
was
wondering
if
how
if
there
is
interested,
if
other
vendors
need
to
customize
these
two
settings
and
where
would
that
be
in
because
there
is
client
settings
server,
settings
sidecar
to
application
settings
and
all
kind
of
places
where
they
show
up.
G
E
I
think
costume
is
still
still
has
something
he
wanted
to
finish.
Correct
awesome.
B
D
There
are
a
lot
of
cases
where
I
don't
feel
that
a
TLS
route
would
be
the
way
you'd
want
to
do
that
anyway,
because
those
workloads
are
not
going
to
be
speaking.
Some
random
TLS
protocol,
they're
speaking
HTTP,
2
or
they're
doing
grpc,
or
something
where
a
higher
level
route
is
the
right
thing
to
describe
that.
So
that
means
that
I
lean
a
little
bit
more
towards
something
that
isn't
a
route
whether
it's
a
you
know,
a
back-end
property
or
a
policy
attachment
or
insert
meta
resource
discussion
here.
D
At
the
same
time,
I'm
not
going
to
lie
they're
an
awful
lot
of
situations
where
I
feel
that
your
typical
mesh
user
not
only
is
not
likely
to
be
interested,
but
should
not
be
messing
with
those
parameters
of
that
configuration,
and
so
it
you
know
I'm
kind
of
okay
in
a
lot
of
ways
with
having
it
be
something
that's
maybe
maybe
there's
a
little
bit
of
extra
friction
in
in
that
particular
thing.
You
know
messing
with
that
particular
thing.
D
Keith
does
that
you
still
going
in
a
different
direction
or.
E
That's
that
that's
the
kind
of
the
direction
I
want
to
take
it
as
well,
so
that
worked
out
well,
I
get
this
sense,
and
this
is
but
I
feel
as
if
there
is
and
people
correct
me
if
I'm
wrong
here,
but
I
feel
like
there
might
be
some
some
hesitancy,
some
hesitation
towards
using
policy
attachment
for
some
of
these
extra
things,
because
it's
an
unknown
like
a
lot
of
different
implementations,
probably
have
resources
or
or
configuration
settings
that
describe
things
like
this-
that
are
like
properties
of
the
connection
TLS.
E
Don't
think
that
it
feels
like
some
of
these
things
for
the
average
mesh
user
aren't
on
the
Forefront
of
their
other
minds,
and
it
feels
like
it
might
it's
better
to
keep
those
out
of
the
main
routing
resources
and
and
attach
them
to
something
else
which,
against
there
are
a
lot
of
things
as
we've
talked
about
policy
attachment
that
sound
like
policy
attachment,
but
maybe
it's
something
about
the
language
I
think
I
haven't
put
my
finger
on
it
yet,
but
maybe
something
about
the
language
of
the
Gap.
E
Maybe
it's
the
kind
it's
the
example
that
was
used,
that
is
causing
friction
even
from
myself
at
seeing
it
as
a
viable
option.
For
some
of
these.
These
use
cases-
maybe
you
know,
to
The
Meta
resource
conversation.
That's
that's
kind
of
happening
on
the
Ingress
side.
Maybe
there
is
another.
Maybe
what
we're
thinking
is
the
the
absence
of
another
resource
to
describe
these
things?
E
E
That's
what
I'm
looking
for
there
is
some
entity
that
exists
feels
like
there's
some
entity
here
that
exists
that
we're
that
we're
reaching
for
that
doesn't
exists
in
the
Gateway
API
yet,
and
maybe
the
solution
to
back-end
properties,
TLS
settings
any
other
use
cases
that
have
come
up
like
perhaps
like
egress
or
routing
behavior
H2
settings.
Maybe
that
belongs
in
that
meta.
Resource
I,
don't
know,
discuss
yeah
I'm,
not
making
sense
that.
A
It
makes
sense
console
has
a
similar
need
for
stuff
like
this.
We
don't
go
as
deep
into
some
of
the
stuff
like
window
sizes,
but
we've
expressed
this
in
our
current
configuration
model
through
a
proxy
default,
so
basically
studying
common
values
for
all
sidecar
proxies
as.
A
Defaults,
which
is
like
specific
configuration
for
a
service
where
you
likely
want
more
of
a
developer
focused
use
case
of
I
want
my
timeout.
My
retries
Etc
proxy
defaults
may
be
more
common
to
connections
common
to
sidecars
that
are
tuned
by
a
cluster
operator
kind
of
like
infrastructure,
devopsy
type
person,
as
opposed
to
an
application
developer.
So
I
I
could
see
it
being
a
different
kind
of
meta
resource
something
attached
to
a
mesh
resource.
If
we
kind
of
need
to
introduce
that
at
some
point,
yeah.
D
C
A
Just
have
it
out
of
scope
for
now
and
have
it
be
mesh
specific
for
now.
G
So
in
Practical
terms,
I
mean
right
now,
I'm
kind
of
trying
to
block
the
the
change
in
history.
To
you
know,
until
there
is
some
understanding
of
what
gamma
Gateway
are
doing,
I
mean
if
it's
completely
out
of
Scopes
and
I,
guess
I'll,
just
let
them
go
through
right
now.
People
are
using
Android
filter
and
it's
that's
that's
pretty
brutal,
not
ideal
and
and
again
the
global
proxy
Falls.
That's
you
know,
that's
something
that
we
don't
want
to
put
on
our
proxies.
G
It's
something
that
you
don't
have
a
specific
Gateway
or
specific
sidecar
that
receiving
10
000.
You
know
wet
socket
long
lived,
I
mean
it's
a
different
patterns,
it's
a
usual
and
the
defaults.
Don't
matter.
We
have
very
large
buffers
or
high
packet
loss
or
whatever
age.
G
So
it's
a
clear
use
use
case
and
people
are
using
avoid
filters
right
now
and
we
need
a
solution
and
you
know
if
other
vendors
are
similar
and
we
have
some
common
way
to
express
it
as
wonderful,
otherwise,
I'll
just
you
know,
move
out
of
the
way
and
let
them
do
it.
That
was
my.
D
G
D
I
mean
some
of
that
is
because
I'm
here,
as
a
representative
of
a
mesh
that
doesn't
use
Envoy
under
the
hood
and
so
trying
to
implement
everything
that
an
Envoy
filter
can
possibly
do.
It
is
pretty
much
going
to
be
a
non-starter
for
us.
It
just
doesn't
make
sense,
but
yeah
backing
up
to
the
idea
that
your
typical
mesh
user
is
that's
far
more
likely
to
get
people
in
trouble
than
it
is
to
be
of
any
real
benefit
in
most
cases.
D
The
other
thing
that
I
was
going
to
point
out
was
that
okay,
somebody
brought
up
timeouts
and
I,
don't
remember
who
that
was
I
apologize,
but
that's
actually
a
great
example
of
a
thing
where
there
are
some
things
that
we
could
certainly
do
them
as
a
policy
attachment
or
some
other
kind
of
a
meta
resource,
and
you
know
you
could
absolutely
make
a
meta
resource
of
whatever
kind
that
sets
a
timeout.
On
the
other
hand,
that
strikes
me
as
an
example
of
a
case
where
that
probably
should
not
require
a
meta
resource.
D
You
should
probably
just
be
able
to
do
that
in
the
route,
because
that's
going
to
be
really
common,
and
it
makes
a
lot
of
sense
that
people
app
developers
should
be
able
to
do
things
like
Say
Hey.
I
want
a
route
here
and
I
want
a
three
second
timeout,
so
figuring
out.
A
way
to
do
things
like
that
without
a
meta
resource
is
something
I
am
definitely
very
interested
in.
G
D
I
think
and
I
think
that
you
know
I'm
calling
that
out,
because
that
distinction
I
think
is
really
really
important.
Yeah
Keith,
it
is,
and
one
of
the
challenges
with
timeouts
and
one
of
the
reasons.
Why
is
an
example
in
policy
attachment,
is
trying
to
figure
out
a
way
to
define
timeouts
that
are
common
across
implementers?
You
know
multiple
implementers
of
the
Gateway
API,
which.
D
I
I
have
not
had
bandwidth
to
go
and
do
a
bunch
of
research
on
that
one,
but
I
would
love
to
find
a
way
that
we
can
start
introducing
timeouts
as
a
specific
example,
I'd
love
to
find
a
way
where
we
can
start
doing
that
in
a
way
that
makes
sense
across
all
of
the
implementers
where
you
can
say
things
like
okay,
so
we
have
a
concept
of
a
request:
timeout
in
the
Gateway
API
as
a
standard,
structured
piece
of
a
of
a
route,
for
example
right
yeah.
It's
it's
on
my
list.
D
My
list
is
getting
really
long,
but
yeah
the
things
like
H2
settings.
Are
you
know
that
sort
of
thing,
yeah,
yeah,
I,
don't
know
things
like
TLs
ciphers
are
a
little
bit
more
of
a
gray
area
to
me,
where
most
people
probably
don't
need
to
mess
with
those.
But
it's
a
lot
easier
for
me
to
imagine
an
application
developer
needing
to
mess
with
the
TLs
ciphers
than
it
is
to
imagine
an
application
developer
needing
to
set
esoteric
H2
timeouts
for
example,
or
configuration,
for
example,.
G
Let's
open
and
discuss
it
again
next
time
and
give
people
time
to
think
about
it.
Yeah
I
I
mean
I'm
just
looking
for
you
know,
some
common
hate
more
than
one
vendor
is
willing
to
put
it
as
an
attachment
policy
attachment
or
some
Zen.
Probably
we
should
try
to
do
the
same
in
history.
We'll
see
how
it
goes
and
provide
feedback
later.
If
there
is
zero
interest,
then
we'll
just
go:
modify
the
existing
history
resources
and
be
done
with
it.
E
So
I
guess
it's
the
short
version
It's
the
tldr.
That
policy
attachment
is
a
little.
It
is
too
big
of
a
approach
for
some
of
the
things
that
folks
are
reaching
for
within
the
API,
like
timeouts
being
a
really
good
example.
A
D
Please
I
think
your
point
about
crd
proliferation
is
a
good
one.
It
the
thing
that
concerns
me
with
policy
attachment.
Is
that
not
only
do
you
end
up
with
multiple
crd
types,
multiple
I
should
say
multiple
crds
floating
around
that
have
to
be
supported
forever,
so
Thomas's
point,
but
also
in
practice.
You
will
probably
end
up
with
a
large
number
of
CRS
and
there
are
a
fair
number
of
cases
where
so.
D
Okay,
just
recently
I,
did
a
thing
where
I
was
talking
about
Liberty,
interacting
with
Ingress
controllers
and
one
of
the
English
controllers.
I
demoed
was
the
envoy
Gateway
and
it
took
a
few
more
CRS
to
get
the
envoy
Gateway
set
up
than
I
was
initially
expecting
because
I
chose
to
have
my
demo
application
in
its
own
namespace
and
so
I
instantly
ran
into
cross,
namespace,
routing
and
hey
guess
what
you
know
I
had
to
go
and
make
sure
that
I
had
the
right
things
in
place.
D
For
that,
and
you
know
stuff
like
that,
so
yeah,
it's
it's
a
thing:
yeah
Thomas.
What
crd
finalizers
always
work
perfectly?
Everybody
knows
that
yeah.
D
B
D
E
Ahead,
I
was
gonna,
say,
yeah,
I,
think
the
more
I
think
through
it.
That's
probably
my
biggest
hesitation
with
embracing
policy
attachment
is
that
I'm
having
to
commit
to
a
new
crd
and
all
of
the
complexity
that
comes
from
adding
a
new
crd
to
to
a
product
likes
from
from
the
OS
inside.
You
know,
we've
got
but
Sesame
semi-management
number
crds
and
we've
been
trying
to
start
consolidating
a
couple,
but
actually
depending
on
to
Flynn's.
E
Second
point:
you
know
the
number
of
CRS
that
are
being
created
in
your
in
your
in
your
cluster,
things
that
you
have
to
to
watch.
E
It
can
create
friction
with
users,
because
I'm
just
trying
to
configure
a
timeout
but
not
practical
and
like
create
a
custom
resource
and
then
think
about
this
default
and
overwrite
logic.
But
I
might
just
want
this
time
up
for
this
one
location.
E
Maybe
you
don't
want
the
burden
of
a
framework
or
something
like
that
so
yeah
I'm
I'm,
not
certain
of
the
of
the
answer
here.
Even
though
I
like
the
hierarchical
nature
of
policy
attachment
I,
think
that's
a
really
good
way
to
solve
certain
problems,
but
I'm
I'm.
Looking
for
something
more
lightweight
for
some
of
the
policies,
air
quotes,
policies
or
configurations
that
are
missing
in
the
routing
resources.
Right
now,.
B
G
If
I'm
reading
correctly,
it's
almost
a
consensus
that
you
know,
proliferation
of
crds
and
policy
attachment
may
not
be
the
most
popular
thing
in
this
meeting
at
least,
and
something
like
the
back-end
polish
or
whatever.
It
was
called
with
a
bunch
of
optional
fields
that
only
some
vendor
supports
and,
and
that
might
be
more
palatable
for
a
lot
of
people
or
more
more.
You
know,
kind
of
popular.
G
D
D
Obviously
there
are
multiple
implementations
of
the
Gateway
API
and
so
there's
going
to
be
a
substantial
amount
of
research
that
has
to
happen
to
make
sure
that
anything
that
gets
you
know
anything
we're
proposing
is
an
extension
of
a
route
is
going
to
have
to
have
something
that
is
consistent
across
those
implementations
right
and
that's
probably
not
going
to
be
a
small
job,
but
that's
probably
okay.
That
would
mean
that
we
would
be
careful
about
things
we're
proposing
adding
to
for
our
crds,
but
yeah
there
are.
E
It's
just
worth
the
topic
in
the
Monday
Gateway
API
meetings
to
what.
B
A
F
A
D
A
Yeah,
it's
definitely
does
feel
like
something
to
bring
up
there.
I
know
that
Nick
started
thinking
about
amount
of
resources
in
general
and
has
written
a
doctor
that
I
can
look
at
these
notes
at
some
point
and
yeah
definitely
merits
further
discussion
in
that
group.