►
From YouTube: SIG Network Gateway API meeting for 20230123
Description
SIG Network Gateway API meeting for 20230123
A
Thank
you
all
right,
welcome
to
the
Gateway
API
meeting
for
January,
23
or
24,
depending
on
the
time
zone
you're
in
thanks
to
everyone
for
showing
up
again.
This
is
a
standard
kubernetes
community
meeting.
So
all
the
same
guidelines
apply.
We
have
a
kubernetes
code
of
conduct
that
could
generally
be
summarized.
It's
just
be
nice
to
each
other
yeah,
nothing,
nothing
too!
Out
of
the
ordinary
there.
I
will
say
this
agenda
is
open.
Anybody
should
be
able
to
add
things
to
it
to
it,
that's
by
Design.
A
So
if
you
have
something
that
you'd
like
to
bring
up,
please
by
all
means
add
it
to
the
list,
maybe
mention
it
in
chat.
Whatever
is
easiest
for
you
and
we'll
try
and
get
to
it.
I
think
we
should
have
time
with
today's
agenda,
but
I'm
always
a
terrible
predictor
of
how
long
we'll
spend
on
topics.
So
with
that
I
don't
know,
I
can't
tell
is
Arco
here
today.
A
Not
yet
it
looks
like
so
maybe
I
I
think
I'll.
Take
this
one.
Anyways
I
would
like
to
do
a
06061
release.
There
were
some
validation
fixes
that
got
in
recently.
That
I
would
like
to
release
and
there
have
been
some
good
conformance
test
updates.
A
I,
don't
see
any
reason
not
to
do
an
061
but
I'll
defer,
I,
don't
know
Nick,
Shane
I,
agree
any
reason,
not
okay,.
A
Maybe
we
can
try
and
do
that
in
the
next
couple
of
weeks.
I
don't
know
I,
don't
I,
don't
have
a
firm
idea
on
timeline,
but
there
are
a
sufficient
number
of
things
out
there
that
they
seem
worth
releasing
I
can't
I,
don't
know
of
anything.
That's
just
on
the
horizon.
That
would
be
useful
to
add.
C
No
I
don't
think
so.
Yeah
I
guess
I
saw
that
Candace's
Taylor
throughout
the
initial
conformance
test
as
much
so
that
would
probably
be
nice
to
get
in,
but
there's
a
bunch
of
other,
basically
I
think
any
conformance
test
or
your
validation
updates.
Should
we
should
pull
in
yeah
might
just
be
a
matter
of
creating
backboard
issues
for
all
of
them
yep.
C
So
if
you
have,
if
you
have
something
that
you
would
like
included
in
the
061
release,
then
please
feel
free
to
create
a
you
know,
a
backward
issue
that
says
please
backboard
this
thing
to
061
and
then
we
can
put
it
in
the
Milestone
and
we
can
have
a
burn
down
list.
A
A
Cool
okay
with
that
I
think
Shane
you're
up
next.
B
Yeah
sorry
in
advance,
if
I
sound,
crummy,
I'm
not
feeling
great
today
so
for
those
who
don't
know
blixt
is
a
reference
and
testing
implementation
of
Gateway
API
that
uses
ebpf
for
the
data
plane.
We
have
been
working
on
it
since
about
kubecon.
B
B
B
B
We
have
completed
some
of
the
egress
work
that
we
need
to
make
that
happen
and
there's
an
open
PR.
That's
a
whip
that
Andrew
and
I
are
working
on
right
now
to
kind
of
get
the
groundwork
laid
for
that
and
then,
ultimately,
we
started
doing
the
Gateway
API
code
Jam
as
part
of
a
an
effort
to
just
have
some
time
to
do
do
more
like
paired
programming
stuff
for
Gateway
API,
but
it's
mostly
been
focused
on
bleaks
and
it
probably
will
be
for
the
near
term.
B
So
on
Fridays
we've
been
doing
that
and
the
attendance
has
been
really
good
if
you're
interested
in
working
on
Blix.
That
is
a
great
place.
It's
on
the
Sig
Network
calendar
to
kind
of
just
join
in.
It's
not
recorded
it's
just
kind
of
for
fun.
It's
still
under
like
the
community
code
of
conduct,
but
it's
just
it's
very
relaxed
place
to
come
talk
about
the
project
and
maybe
just
do
some
live
coding
and
stuff.
So.
A
Cool,
that's
awesome,
yeah,
thanks
for
the
update,
very
cool
to
see
Blix
coming
along,
and
it
will
be
great
to
work
this
into
our
conformance
tests
and
really
have
a
kind
of
a
a
good
implementation.
So
so
we
have
a
bit
more
of
a
feel
on
any
any
kind
of
pain
points,
especially
at
L4
that
we
might
run
into
along
the
way.
So
yeah
awesome
any
last
bits
on
that,
or
should
we
keep
on
moving.
A
Questions:
okay,
all
right,
so
I
shared
this
talk
with
Community
on
slack
and
mailing
list.
I,
don't
know
a
week
and
a
half
ago,
I
want
to
say,
but
we
haven't
had
any
kind
of
formal
agenda
driven
meeting
since
then
so
chances
are
you
you've
probably
looked
at
this
I
I,
don't
know,
but
I'll
provide
a
little
bit
of
an
overview
since
we
haven't
had
a
chance
to
discuss
it
in
a
meeting.
Yet
one
of
the
things
that
I've
been
thinking
about
a
lot
is
how
on
Earth
we
go
from
to
ga.
A
You
know
what
what
does
it
look
like
for
Gateway
API
to
have
Alpha
Beta,
And,
GA,
API
versions,
and
how
can
we
do
that
in
a
way
that
is
maintainable,
sustainable
and
just
not?
You
know
ridiculous
overhead
for
implementers
users
and
the
rest.
A
You
can
also
see
I
I
linked
out
to
a
really
related
doc.
That
Tim
has
where
he's
also
Tim
Hawkin
has
written
a
doc,
that's
more
Broad
and
it's
talking
about
potential
changes.
We
could
make
to
Alpha
Beta
GA
cycle
in
kubernetes
as
a
whole
because
we
as
Gateway
API,
exist
ever
so
slightly
outside
of
that,
we
have
a
little
bit
more
flexibility
in
what
we
do
and
I
have
a
proposal
here,
and
this
is
very
much
still
at
a
pro
proposal.
This
is
not
approved
or
anything.
A
This
is
just
my
perspective.
One
I
think
that
wherever
possible,
we
should
remove
the
concept
of
beta
from
Gateway,
API
I.
Think
in
general,
we
there
are
two
states
in
kubernetes
apis.
A
There
is
the
on
by
default
and
stable
State
and
there's
the
off
by
default
and
unstable
state
beta
has
always
existed
in
this
kind
of
weird
in-between
of
in
some
cases
on
by
default,
less
so
and
somewhat
stable,
but
not
as
stable
as
stable,
and
my
argument
is
that
maybe
we
just
have
the
two
states,
this
largely
maps
with
what
we
already
have
in
Gateway
API.
We
have
a
standard
Channel,
an
experimental
channel.
A
It's
really
just
saying
those
will
be
our
only
channels
and
we'll
call
what
we
have
in
standard
GA
at
some
point
in
the
future,
and
anything
else
we'll
just
have
to
meet
a
higher
bar
to
get
to
that
standard,
Channel
and
that
will
become
ga.
That
is
my
idea.
The
the
reason
behind
this
is
that
every
new
API
version
adds
significant
cost,
whether
it's
to
maintainers,
to
implementers
or
to
users.
A
We
have
dealt
with
this.
If
you've
worked
with
kubernetes
for
any
period
of
time,
you
have
likely
dealt
with
the
pain
of
version
compatibility,
trying
to
convince
users
to
upgrade
to
the
latest
API
version.
Older
API
version
gets
dropped,
it
it's
just
it's
a
mess
and
then
with
crd
specifically,
this
is
just
some
slides
from
kubecon
contribute
Summit
talk,
I
gave.
The
idea
is
that
if
we
do
things
properly,
every
API
version
goes
through
this
four
release
cycle
and.
A
Kind
of
highlights
what
we've
done
with
Gateway
API
already,
but
if
you
can
imagine
that
for
every
API
version
it
needs
to
run
through
four
different
minor
releases.
That's
you
know
a
real
cost
and
that's
your
best
case
scenario,
where
you
get
every
every
little
part
of
the
process.
Right.
If
you
miss
one
and
one
release,
then
you
know
okay.
Well,
let's
add
one
to
that.
Four
is
really
your
best
case
scenario
yeah.
A
So
a
lot
of
a
lot
of
thoughts
written
out
about
this
I
want
to
just
maybe
open
it
up
to
some
discussion
around
this
here,
there's
yeah
this
is
this-
does
represent
a
big
change,
it's
it
would
be.
We
would
be
the
first
official
kubernetes
API
to
take
this
approach.
A
E
If
I
can
make
a
small
comment,
Java
servlets
or
go
and
pretty
much
everyone
in
the
world
has
dealt
with
this
problem
and
have
maintained
stable
apis
with
understanding
that
once
you
launch
an
API,
it
remains
stable
and
you
will
need
to
support
it
forever.
I
think
it's
a
very
good
thing
to
take
the
same
approach
and
not
pretend
that
hey,
we
can
change
the
apis
and
you
know
have
people
use
it
and
then
change
our
mind,
and
so
this
is
a
great
idea.
E
A
Yeah
yeah
I
appreciate
that
and
I
think
that
is
really
just
this
recognition
that
once
things
graduated
to
Beta
effectively
in
kubernetes,
we
were
we
weren't,
really
meaningfully
changing
things
and
when
we
did,
we
regretted
it
at
least
speaking
from
personal
experience
yeah.
So
that's
my
perspective.
Shane
I
think
you've
got
a
hand.
B
It
seems
to
me
like
one
of
the
the
the
reasons
why
you
would
want
the
beta
these
days
is
the
ostensibly
so
that
you
could
say
we
are
technically
in
production,
but
if
we
absolutely
needed
to
make
a
breaking
change,
we're
kind
of
telling
people
it's
beta,
we
still
might
do
it.
Have
we
done
that
meaningfully
recently
like
what
are
some?
What
are
some
examples
to
talk
about
of
like
actually
having
done
that
recently,
because
if
there's.
A
I
am
very
familiar
with
the
Ingress
API
and
taking
that
from
beta
to
GA
and
the
mistakes
made
along
the
way,
largely
by
myself
and
I
know.
That
was
a
painful
migration
for
everyone
involved,
and
you
know
I
kind
of
alluded
to
it.
In
retrospect,
I
wish
we
just
hadn't
made
changes,
yeah
yeah
and
you
know
it
was
and
then
endpoint
slice
I'm
very
familiar
with
that.
We
did
beta
to
ga.
A
We
were
trying
to
get
rid
of
a
field
in
that
transition
that
we
didn't
think
we
needed
anymore
and
we
introduced
a
bug
in
that
process.
So
again,
I
and
I
don't
know
that
we
added
any
value.
So
the
two
times
I've
seen
changes
again.
They
were
small
but
changes
between
beta
and
GA
I'd
say
in
both
cases
they
were
regretted.
B
My
thinking
is
like
I
remember,
those
I
mean
I
was
working
on
clusters
at
the
time,
but
my
think
my
thinking
is
like
leans
towards.
If
we're
not
able
to
actually
get
that
value,
then
we
don't
need
beta,
but
I.
Also,
you
know
Counterpoint
have
we
actually
exercised
like?
Is
it
possible
that
we
just
made
other
mistakes?
It
wasn't
specifically
because
you
can't
make
that
work
correctly.
A
Yeah
no
I,
yeah,
I
I
agree
with
what
you're,
saying
and
and
I
would
say.
I
still
see,
there
is
some
limited
value
in
beta
apis
I.
Just
don't
think
that
that
value
outweighs
the
costs
associated
with
that
extra
API
version,
because
the
costs
are
significant
and
guaranteed.
The
value
is
possible,
but
not
guaranteed.
A
C
I
think
it's
important
to
remember
that
the
biggest
the
biggest
cost
like
one
of
the
biggest
costs,
is
for
implementers
right.
Like
the
you
know,
you
have
to
maintain
separate
type
definitions,
separate
deserializations
and
a
lot
of
the
times
like
separate,
watches
and
stuff
like
that
for
the
different
API
versions,
and
so
the
more.
If
you
have
three
API
versions,
then
that
means
you
know
like
if
you
support
for
some
brief
period
of
time,
you
support
all
three.
That's
three
copies
of
a
bunch
of
code.
C
Essentially
I
mean
a
lot
of
the
time
you
can
get
away
with
type,
switching
and
like
answer
type,
conversion
and
stuff,
but
sometimes
you
can't,
especially
if
you've
made
big
changes
between
like
Alpha
versions
or
something
like
that.
C
That
was
what
happened
when
we
went
from
V1
Alpha
One
to
V1
Alpha,
two
for
Gateway
API,
so
I
think
the
you
like
I'm
in
favor
of
this,
because
I
think
that
it
really
it
marks
down
what
effectively
has
happened
historically
in
the
past,
with
in
with
Ingress,
mainly
but
with
with
other
apis
as
well.
Once
it
moves
to
Beta
people
are
like
oh
yeah.
Okay,
this
is
probably
stable
enough
to
start
using,
but
then
once
people
are
using
it,
then
it's
now
stable
enough
that
you
can't
change
it
anymore.
C
Like
you
know,
like
yeah,
that's
that's.
The
problem
is
that,
like
beta
is,
is,
is
usually
stable
enough
that
some
people
will
start
using
it,
but
once
people
are
using
it,
if
you
change
it,
you
break
all
the
people
who
are
already
using
it,
and
so,
like
you
know,
and
and
the
best
case
is
that
you
go.
Oh
okay.
We
need
to
make
a
breaking
change
now.
This
is
V1
beta
2.,
but
then
all
the
people
who
are
still
using
Vivo
and
beta1
now
need
to
convert.
C
C
This
is
working
and
we
knit
like
if
every
time
you
do
a
deprecation
in
a
removal
cycle
like
it's
a
lot
of
work
for
everybody,
everybody
uses
maintainers
everybody
now
implant
is
everybody,
and
so,
like
I,
think
that
making
the
removing
the
intermediate
intermediary
step
of
you
know
beta
just
makes
it
more
clear
that
that's
the
case
that
when
you,
when
an
API
leaves
Alpha,
you
are
making
API
guarantees.
C
You
know
yeah,
maybe
and
I
think
that
the
that
maybe
what
we
might
need
to
do
is
just
if
we
are.
If
we
do
decide,
we've
made
a
mistake
with
something
that
we've
moved
to
GA.
Then
we
just
be
more
aggressive
about
saying:
okay,
V2
V2,
Alpha
One.
It
is
baby
right,
like
you
know,
we
just
say:
okay,
we're
making
a
breaking
change.
This
is
the
next
version
of
the
API.
C
A
Yeah
I,
don't
think
I
explicitly
said
that
in
here,
but
that's
exactly
what
I'm
saying
that
you
know
if
we
need
to
make
an
API
change,
that
we
go
back
to
Alpha,
we
V2
Alpha,
One
whatever
it
is
that
that
seems
like
the
the
correct
way
to
do
that.
Instead
of
trying
to
make
a
change
and
still
call
it
stable,
it.
A
C
Additive
AP
compatible
API
changes
are
okay
additive
compatible
API
changes
are
defined
in
the
API
conventions.
They
are
the
result
of
like
long
hard
one
experienced
by
a
lot
of
people,
and
so
that's
I
think
that's
a
really
relevant
thing.
B
F
A
G
Do
we
I
mean
I,
think
you
mentioned
in
the
beginning
that
we
would
be
the
first
kubernetes
component
to
do
this?
Could
we
be
the
second.
A
Yeah
I
I
know
I
I
would
love
to
be
the
second.
In
many
things
you
know
it
would
it
would
make
life
a
lot
easier,
but
just
the
very
nature
of
Gateway
API,
it
seems
like
we've
been
Paving
a
path
for
for
many
things.
You
know
one
of
the
first
major
apis
to
use
crds.
A
To
begin
with
that,
it's
you
know,
official
kubernetes
thing
and
and
I
think
by
very
nature,
we're
we're
running
into
some
of
these
other
problems
first
too,
and
trying
to
come
up
with
solutions
that
make
sense.
I
I
was
talking
with
Tim
about
this
Tim
Hawkins
about
this
as
well
and-
and
he
has
been
supportive
of
the
idea
and-
and
you
know
the
guidance
that
I've
I've
heard
from
that
perspective
is
just
we
are
For,
Better
or
Worse.
A
We
are
the
ones
that
get
to
try
things
out
in
the
community
first
and
and
provide
you
know
we're
the
guinea
pigs
I.
Guess
we
get
to
see
if
if
this
idea
makes
sense-
and
if
it
does
I
expect,
others
will
adopt
it
and
if
it
doesn't
well,
we
we've
learned
the
hard
lesson
but
I'm
hopeful
that
it
will
but
yeah
and
and
and
on
that
note,
I
I
would
say
you
know.
I
was
also
asking
around
like
what
does
it.
A
You
know
we're
kind
of
in
this
unique
place
where
it's
unclear.
What
kind
of
approvals
we
really
need
to
make
this
change.
You
know,
Sig
Network
seems
to
be
okay
with
this,
but
got
a
suggestion
that
we
really
should
bring
this
to
Sig
Arch
as
well.
So
this
got
sent
out
to
both
cigarch
and
Sig
Network
mailing
list
I
have
not
received
any
pushback,
but
I
want
to
explicitly
raise
this
on
an
agenda,
get
a
discussion
going.
So
that
is
on
a
cigarch
agenda
for
this
week,
January
26th.
A
If
anyone
wants
to
attend
and
that
you
know,
depending
on
the
feedback,
there
will
be
our
final
go
or
no
go.
I
expect
on
this.
D
C
I
think
I
think
we've
been
out
in
front
for
so
long
now
that
we're
kind
of
stuck
here
as
the
people
out
in
front
trying
all
this
stuff
out
yeah.
A
Yeah
good
questions.
Next
up,
let
me
run
into
you
know:
I
think.
A
lot
of
our
stuff
is
is
kind
of
starting
to
bleed
into
other
cigs
a
bit,
and
this
is
another
example
of
that,
as
I
think
we've
discussed
before
reference
Grant
has
been
used
by
Sig
storage
now,
which
is
awesome,
but
it
means
that
there
is
some
onus
on
us
and
six
storage
to
work
together
to
pull
reference
Grant
into
some
kind
of
neutral
home.
A
Segoth
has
been
receptive
to
that
idea,
and
so
we
created
a
cap
and
Nick
and
I
have
written
this
up
to
describe
what
that
would
look
like.
There
has
been
all
kinds
of
good
feedback
and
although
cigarth
reviewed
the
initial
reference
Grant
API,
when
we
were
designing
it
to
begin
with
we're
getting
some
really
good
questions
now
that
we
can't
just
you
know
in
the
initial
reference
Grant
design,
we
could
just
say
well,
we
have
two
very
clear
use
cases
and
they
look
exactly
like
this
and
therefore
reference
Grant
makes
sense.
A
Now
we
have
to
deal
with
a
little
bit
more
of
the
unknown
of
reference.
Grant
needs
to
be
sufficiently
generic
that
it
can
work
in
many
cases,
so
really
good
feedback
really
good
questions.
It's
going
to
take
some
time
to
respond
to
the
feedback
we
already
have,
but
if
anyone
wants
to
help
out
with
this
I
I
know
I'm
very
welcome
to
join
the
conversation
help
with
the
cap,
whatever
whatever
it's.
It's
helpful
I
think
we've
got
around
two
weeks
left
until
the
Upstream
kept
free.
A
So
that
means
in
the
next
couple
weeks
we're
trying
to
get
this
merged.
But
there
are
still
some
large
open
questions
on
this
one
Nick
I
know
you
have
touched
this
most
recently.
Are
there
any
specific
things
you
want
to
highlight
on
it.
C
No
I
think
the
seagull
folks
have
had,
like
I,
tried
to
address
a
bunch
of
the
questions
that
I
raised
earlier
when
you
presented
this
to
them.
But
there's
a
couple
of
that:
I
missed
that
Jordan
has
brought
up
so
yeah
I.
Think
I'm
gonna
try
and
bring
in
some
of
the
discussion
there
and
like
answer
it
in
comments,
but
then
also
bring
it
into
the
text
to
sort
of
so
there's
a
record
of
it.
Yeah
I
think
you
know,
we've
obviously
got
some
feedback
about.
C
You
know
using
kind
instead
of
resource
and
a
few
other
things
that
calls
that
we
made
that
I
think
yeah
I
think
we've
made
the
right
call
but,
like
you
know,
there
are
sort
of
corollaries
to
that.
That
are
pretty
reasonable,
that
we
need
to
make
sure
we've
addressed
in
the
cab
to
make
the
behavior
clear.
I
also
think
that
it's
very
fair
to
say
that
the
re
that
you
we
were
aiming
to
be
like.
C
Oh
we're,
just
going
to
take
what
we've
got
and
move
it
into
beta
in
this
new
thing
and
I.
Think
Mo
made
the
fair
point
that
you
know
this
is
the
chance
where
you
you
get
this
you're
moving
it.
So
you
get
to
make
some
any
changes
you
want
to
make.
So
I
think
we
might
end
up.
It
feels
like
from
the
feedback
that
we're
getting
that
we
might
end
up
making
at
least
some
changes.
C
You
know
we
need
to
go
back
and
think
about
things
like
do.
We
have
a
namespace
selector
for
the
namespaces.
Do
we
you
know?
Do
we
make
it
explicit
that
if
we
don't
that
that
star
is
all
Native
spaces
or
you
know
that
sort
of
stuff
not
huge
changes
but
but
changes
nonetheless,
yeah.
A
Yeah,
yeah
and
I
think
one
of
the
interesting
comments.
I
I,
don't
remember
all
of
them
offhand,
but
because
we're
getting
sick,
auth
review
on
this
we're
getting
some
I
think
really
neat
ideas,
one
of
them
I
think
also
from
Mo
was
the
idea
of
can.
Can
we
create
something
that
translates
a
reference
grants
into
our
back
basically
and
creates
a
and
allows
consumers
of
this
API
to
just
do
a
subject,
access
review
as
a
way
of
consuming
the
API
I'm?
A
Not
sure
that
would
work,
but
it's
you
know
there
are
lots
of
good
questions
on
here.
So
yeah
I
this
as
much
as
I
think
both
of
us
would
hope
we
could
just
take
the
existing
API
and
move
it
over
verbatim.
C
As
always,
this
is
one
of
the
reasons
why
caps
can
often
take
a
while
is
that
you
sometimes
it's
the
first
time
that
people
who
know
a
lot
about
like
know
like
have
been
doing
kubernetes
API
review
for
many
years,
have
a
look
at
something
in
depth
and
then
they're
like.
Oh
what
about
this?
What
about
this?
Have
you
thought
about
this
and
you're
like?
Oh,
those
are
all
really
good
points
that
I
never
thought
of.
A
Yep
yep
well
said
cool
all
right,
so
I
think
that's
all
for
reference
Grant
again.
If,
if
anyone
has
ideas
feel
free
to
jump
in
we,
we
are
always
looking
for
help
to
push
this
one
forward.
A
The
the
next
thing
I
kind
of
wanted
to
highlight
before
we
get
into
triage
here,
is
just
starting
to
think
about
our
next
release.
I
know,
at
the
end
of
last
year
we
kept
on
saying
we
want
to
do
more
smaller
releases,
so,
instead
of
just
assuming
that
our
next
release
will
be
say
four
months
away,
we
may
want
to
break
that
assumption
and
assume
that
our
next
next
minor
release
could
be
in
a
few
a
few
weeks.
A
With
that
in
mind,
I
I
wanted
to
just
jot
some
ideas
down
that
I'm
aware
of
thinking
about
on
on
the
road
map
that
could
be
part
of
another
release.
Right
I
know
gamma
well,
maybe
I
think
Mike
at
least
you're
on
the
call
I
don't
know
if
any
other
gamma
maintainers
are
here,
but
do
we
have
any
ideas?
What
what
kind
of
timeline
we're
looking
for?
And
you
know
when
we
might
have
something
more
concrete-
that
we
could
bundle
with
a
release
from
gamma
perspective,
foreign.
F
So
I
think
it
would
probably
depend
on
wrapping
up
the
outstanding
issues
in
the
Milestone.
That's
probably
the
best
like.
What's
the
content
of
what
we
want,
we're
pretty
close
to
getting
a
substantial
addition
to
the
reality,
the
scope
of
the
routing
stuff
emerged
and
there's
a
handful
of
edge
cases
that
will
probably
just
focus
on
basically
like
routing
only
but
pay
off
the
edge
cases
and
make
sure
that
that
is
in
good
shape
for
review
is
kind
of
the
goal
as
far
as
content.
F
I,
don't
have
a
good
answer
as
far
as
time
at
this
point,
but
that's
definitely
something
that
we
can
bring
up
during
the
gamma
meeting
tomorrow.
Yeah.
A
Yeah
that'd
be
good,
I
mean
let's,
let's
just
say
that
we
we
are
ready
to
release
vo70
in
one
month
from
today.
Just
imagine
is:
is
that
a
you
know-
and
this
is
I
think
just
a
question
for
tomorrow,
but
is
that
something
that
we
could
possibly
include
something
from
gamma
and
and
again
you
know
we're
trying
I
think
all
of
our
goals
here
are
trying
to
make
it
less
painful
to
miss
a
release.
A
So
if
you
miss
a
v070,
it's
not
like
you're
waiting
for
six
months
or
eight
months
for
080
or
1.0,
whatever
yeah,
okay,
yeah,
so
I
I'm
I
expect
I'll
be
at
the
gamma
meeting
tomorrow
as
well.
So
we
can
discuss
this
there
I.
Just
that's
one
of
the
things,
that's
top
of
mind
for
me.
Next
up,
GA
for
gateway
gateway,
class,
HP
route,
this
you
know
we've
basically
hit
the
the
criteria.
I
think
that
we
defined
for
ourselves
in
terms
of
what
that
means.
A
I
feel
like
the
thing
that
we
don't
know.
Yet
is
the
outcome
of
this.
This
talk
of
does
beta
still
exist,
so
it
basically
there's
there's
two
separate
paths.
There's
a
path
where
we
keep
all
API
versions:
Alpha
Beta
GA,
and
then
we
have
a
experimental
standard
and
stable
channel
of
the
API.
So
three
release
channels.
Three,
you
know
I
think
at
this
point,
I
I
am
personally
leaning
towards
you
know,
obviously
the
simpler
option
here,
but
until
we
know
that
I
think
this
is
kind
of
stuck.
A
We
may
know
that
as
soon
as
January
26th
but
yeah
I
think
whenever
we
do
this
GA.
My
vote
would
be
that
we
call
the
API
1.0.
So
whenever
we
GA
L7
resources
is
yeah.
Okay,
maybe
not
but
interested
in
what
others
think
here.
I
don't
know
when
we
call
this
API
1.0.
If
it
isn't
that
point.
C
I
feel
like
one
Auto
means
that
we
have
the
TLS
route
like
the
the
existing
route
types,
possibly
excluding
grpc
route.
You
know
the
sort
of
the
ones
that
we
started
with
that
those
feel
like
the
ones
that
we
needed.
We
need
to
have
the
layer,
four
ones
and
the
layer,
seven
ones
you
know-
and
the
and
TLS
route,
because
it's
not
a
clean
layer,
all
the
ga
for
us
to
call
this
API
ga.
C
So,
like
you
know,
I
feel
like
saying:
go:
API
is
GA
when
we've
got
gateway,
gateway,
class
and
HTTP
route.
Maybe
then
again
that
depends
on
what
we
do
with
reference.
Grant
I
would
say.
Probably
you
know
again
if
we're
having
a
new
reference
Grant
in
another
API
Group,
that's
Alpha,
like
you
know,
a
lot
of
what
we
do
depends
on
having
reference
Grant
available
and
so
like.
C
If
we're
going
to
have
another
shared
reference,
Grant,
that's
Alpha,
do
we
you
do
we
rely
on
that
or
do
like
you
know,
so,
there's
there's
some
other
stuff
there.
So
I
think
you
know
it
feels
to
me
like
Gateway,
API
being
1.0
says
this
thing
is
like
you
know,
this
thing
is
definitely
ready
for
like
production
use.
This
thing
is
definitely
ready
for,
but
you
like
are
we
gonna
say
that
this
thing
is
ready,
for
this
thing
is
pretty
for
production
use
means
oh,
but
only
for
http.
C
H
F
C
Disagree
that
the
HTTP
stuff
is
ready
for
producting
use,
but
like
doesn't
Gateway
API
also
include
layer.
4
use
cases
like
the
words
Gateway
API.
Doesn't
that
include
layer,
4
use
cases
shouldn't
if
we
say
Gateway
API
as
GA
does
that
should
we
include
layer,
4
use
cases
in
that
and
TLS
route
yeah?
That's
that's.
My
only
concern
is
like
what
do
we
mean
when
we
say
the
API
is?
Is
1.0
like
right?
We.
B
C
Or
go
ahead,
I'm
sorry,
yeah
I
mean
I
would
say:
1.0
is
East
ceremonial
in
some
respects,
but
it's
also
not
ceremony
in
that
it
sends
a
signal
to
the
world
that
you
yeah,
like
it's
in
the
single
level
yeah.
This
is
ready,
use
right
like
we're
not
going
to
change
this.
The
yeah
like
the
stable,
the
stableness
is
real.
C
You
know
like
yeah
and
so
I
mean
I,
think
Bowie
Bowie
says
in
the
in
the
chat,
like
you
know,
beta
equals
launch
right.
You
know
like
we
all
agree.
The
better
resources
we
have
in
gateway
gateway,
class
and
HTTP
route
are
ready
to.
You
know
to
be
to
be
marked
as
GA
I
I.
Don't
do
not
dispute
that
in
the
slightest.
What
I'm
saying
is
what
does
the?
What
does
saying
that
the?
What
does
bumping
the
bundle
version
to
1.0
mean
and
that's
like
yeah?
B
Think
it's
partially
ceremonial
and
I
I
lean
towards.
We
have
a
good
chunk
of
functionality
through
the
three
apis
well
for
apis
that
we're
talking
about
that
covers
a
very
large
percentage
of
what
people
are
actually
doing
with
the
API
and
I
think
we
should
just
have
that
ceremony
sooner
rather
than
later.
I'm
leaning
against
it
Nick
to
be
honest,
I
kind
of
feel
like
it's.
A
Yeah
I
think
I
think
my
concern
is
anything
below
1.0
and
sembar
does
not
invoke
any
term
of
stability.
So
if
we're
calling
something
stable
but
still
calling
a
released
version,
o
dot
whatever
that
feels
to
be,
you
know
a
conflict
and
then
and
then
there's
there's
so
many
different
moving
targets
we
could
have
you
know
I
I,
think
you
you
brought
up
the
most
obvious
one
like
we.
H
A
Wait
till
L4
routes
or
GA,
but
then
the
next
one
is
which
L4
routes.
You
know
what,
if
TCP
moves
before
the
UDP
before
grpc
Oh,
and
not
not
that
not
that
L4,
but
just
other
route
types
right
and
then
at
the
same
time,
there's
there's
other
ideas
like
gamma.
You
know,
gamma
is
going
to
start
experimental.
You
know
you
could
potentially
say
well.
We
should
wait
until
that's
ready,
I.
C
I
see
what
you're
saying
like
the
I
think
that
Travis
asked
a
question
in
the
chat
that
you
know
is
there
anything
in
particular
for
The
L4
apis
would
want
to
be
more
stable.
Yes,
there
we
have
a
checklist
for
them.
You
know
we
need
conformance
tests.
We
need
implementation
support
and
you
know
we
need
to
be
confident
that
we
don't
need
to
have
anything
to
those
apis.
C
I
feel
like
we
haven't
got
any
of
those
three
things.
Yet
we
don't
have
conformance
tests.
We
don't
have
good
implementation.
Sport
like
there
are
some
implementations
that
support
it,
but
without
the
conformance
tests
you
know
like
what
does
support
really
mean
and
then
I
personally
do
not
feel
comfortable
with
The
L4
things
that
there's
nothing
that
we'll
need
to
add.
C
People
have
definitely
said
that
they
want
some
sort
of
Ip
filtering
functionality,
but
you
know
as
when
we,
when
we
start
when
we
added
that,
before,
like
Tim,
raised
a
really
good
point
that,
like
that's
kind
of,
makes
a
Gateway
a
firewall
as
well
yeah,
and
so
we
need
to
be
clear
about
what
you
know
if
we
are
adding
that
water.
C
What
do
these
things
mean
and
stuff
like
that,
and
so
there's
a
lot
of
work
to
do
for
the
il4,
apis,
I
think
and
I
I
think
you're
you're,
all
right,
like
the
the
I
think
Rob,
your
point
is
probably
I.
Think
that's
weighs
me
the
most
that
you
know.
If
we're
going
to
call
something
stable,
it
makes
sense
for
the
API
itself
to
have
a
1.0
to
be
like
hey.
C
Some
of
this
API
is
stable
right,
there's
experimental
bits,
but
this
thing
will
be
to
stable
prop
and
we
mean
stable
yeah
and
the
V1
API.
Group
also
says
that
right,
like
when
an
API
Group
goes
to
V1.
That
means
that
it
is
no
longer
alpha
or
beta.
It
is
proper
stable.
It
doesn't
mean
that
we
can't
make
compatible
additive
changes,
which
is
what
we
are
doing
already
and
that's
what
you're
trying
to
say
with
the
you
know,
phasing
out
beta
anyway.
C
It
would
be
easier
to
phase
out
beta
if
we
had
no
resources
in
beta
so
like
if
we
graduate,
if
we
graduate
all
the
resources
that
we
know
and
that
we
know
are
good
already
2ga,
you
know
call
the
bundle
version
whatever
we
want
and
there
is
nothing
in
beta,
then
removing
the
removing
phasing
our
beta
is
all
of
a
sudden,
a
lot
easier.
C
So
I
guess
I
guess
this
is
me
thinking
out
loud,
but,
like
you,
I,
I,
guess
I
kind
of
withdraw.
My
objections,
like
yeah
I,
think
that
that
probably
makes
sense
that
that
we
say
hey
if
we're
going
to
GA
any
resources.
That's
when
we
do.
C
If
we're
going
to
GA
those
three
sort
of
early
resources,
then
that's
when
we
do
1.0
I
do
think
that
probably
we
should
look
at
you
know
we
we
do
need
to
wait
to
decide
on
that
to
find
out
what
happens
with
reference
Grant,
because
a
lot
of
what
we
do
is
very
dependent
on
reference
gain
or
the
idea
of
reference
Grant.
And
so
you
know
the
yeah.
C
If
that's
going
to
go
back
to
Alpha,
then
like
yeah,
maybe
we
want
to
hold
on
to
the
beta
for
a
little
bit
until
we
can
be
confident
that
the
reference
grain
is
going
to
move
through
relatively
quickly
but
yeah
yeah
I.
Think
that's.
That's
really.
My
only
concern
at
that
point.
A
Yep
yeah
I
think
I
think
those
are
all
entirely
Fair
points,
so
I
yeah
a
lot
of
discussion
there,
I
I,
think
the
my
high
level
takeaways
from
this
whole
discussion
are
that,
yes,
we
do
want
GA
gateway,
gateway,
class
and
hbr
to
go
to
ga.
When
that
happens,
we'll
probably
call
the
API
1.0
we're
waiting
for
to
see
what
happens
with
reference
Grant
we're
waiting
to
see
what
happens
with
cigarch.
A
As
far
as
this
idea
of
removing
beta
and
at
the
same
time
we
want
to
keep
on
moving
forward
with
other
things
we
did.
This
does
not
need
to
block.
You
know
0.7.0.
This
is
something
that
is
probably
going
to
sit
for
a
little
bit,
even
though
we
by
and
large,
have
met
the
graduation
criteria.
A
We
should
we
should
wait
till
we.
We
have
a
very
clear
picture
of
what's
happening
for
reference
Grant,
what's
happening
with
API
versioning
cigarch,
and
then
we
can
come
back
to
that.
D
A
So
with
that
said,
that
leads
me
to
think
that
we
have
at
least
a
v07.0
between
us
and
GA,
so
at
least
that.
So
on
that
note,
let's
talk
about
path,
redirects
and
rewrites.
That's
a
gap
that
I
started
a
while
ago.
It's
it's
sad
and
experimental
for
long
enough.
A
I
think
we
have
enough
implementations
of
this
now
Leora
recently,
added
conformance
tests
for
I
think
a
full
set
of
functionality
here,
but
I,
don't
think
those
have
been
released,
they're
just
sitting
in
the
main
branch,
but
they
would
be
part
of
an
061
release.
Has
anybody
so
maybe
just
a
quick
survey
here
of
people
that
represent
implementations
here,
anyone
out
there
that
has
implemented
the
features
in
this
Gap,
specifically
path,
redirects
and
any
form
of
rewrite.
A
Maybe
I'll
I'll
follow
up
with
a
question
in
slack
or
GitHub
discussion.
It
is
until
we
have
centralized
conformance
reporting.
It
is
always
difficult
to
to
know
for
sure
who's
actually
implementing
and
using
a
thing.
But
my
guess
is
that
we
probably
have
enough
usage
here
or
or
implementation
to
push
this
one
forward
relatively
soon.
I'd
expect
with
no
changes.
A
So
this
this
feels
like
one
of
the
most
straightforward
candidates
to
keep
on
moving
in
070.
At
that
point,
it's
just
joining
standard
Channel
and
joining
beta
for
for
those
features,
but
I'll
follow
up
the
next
one
is.
C
Before
we
open
the
policy
attachment
yeah
Pandora's
Box,
we
should
I
can't
say
that
Candace's
question
yeah.
A
Yeah,
that's
that's
a
good
one.
Let
me
just
add
back-end
properties
that
that
feels
awfully
close
to
TLS
route,
but
no
I'll
put
it
I'll
put
it
up
here,
foreign.
A
Candace,
maybe
what
do
you
think?
What
do
you
think
we
need
here?
I
know,
I
know
it's
kind
of
gotten
stuck
and,
and
we
we
got
stuck
in
in
a
bunch
of
back
and
forth
about
what
actually
belongs
in
this
in
this
resource.
G
G
Well,
it's
been
a
while,
since
we
as
a
group
looked
at
it,
though
I
know
that
that
Nick
has
been
updating
the
document
and
other
people
have
been
looking
at
the
document
for
the
TLs
use
cases
and
Nick.
It's
probably
a
better
describer
of
of
what's
Happening,
we're
pretty
much
have
dropped
the
concept
of
back-end
properties,
I,
think
and
we're
now
moving
into
getting
a
better
sense
of
the
TLs
use.
Cases
is
that
is
that
your
impression
Nick.
C
Yeah
I
think
so.
I
think
that
back-end
properties
was
a
little
bit
too
generic
I
think
yeah.
There's
there's
definitely
a
there's.
Definitely
a
a
reasonably
straightforward
user
requirement,
for
the
use
case
of
my
part
is
already
doing.
Tls
and
I
want
to
be
able
to
have
Ingress
traffic
to
that
point,
to
also
do
TLS
either
in
the
forwarded
TLS
case
or
in
the
you
know,
unzip
to
the
Gateway
and
then
re-encrypted
use
case.
Like
that's
a
reasonably
well
understood
thing.
That
is
a
real
problem
that
people
have.
C
The
problem
is
that
as
soon
as
we
start
designing
ways
to
talk
about
this
in
in
gamma
API,
like
we
run
square
into
the
button,
you
can
also
use
that
to
describe
a
lot
of
the
stuff
that
we
want
to
do
with
the
gamma.
So
I
think
that
for
these
two
for
this
to
be
something
that
we
need
to
do,
we
need
to
design
something.
That's
relatively
tightly.
Scoped
that's
tightly
scoped.
C
To
doing
you
know
the
straight
Ingress
use
cases
the
the
figures
out,
a
way
that
we
handle
this
for
the
straight
Universe
use
cases,
and-
and
though
we
are
clear.
This
is
for
this
use
case
where
the
Pod
is
the
the
processor's
running
inside
the
Pod
has
its
own
cert.
That
is
managed
in
some
other
way
that
we
don't
care
about,
but
the
Gateway
needs
to
know
that
it
needs
to
do
TLS
to
talk
to
the
to
talk
to
the
back-end
service.
That's
the
thing
that
we
need
to
tell
here.
C
There
are
really
two
use
cases
there.
One
is
TLS
route,
you
know
like
the
the
Gateway,
doesn't
unwrap
the
HTTP
route
and
re-rewrap
it.
The
other
one
is
a
subset
of
HTTP
route
where
it
does
terminate
the
TLs
traffic
and
then
want
to
re-encrypt
it.
That's
what
we
mean
by
re-encrypt
so
and
and
I
think.
A
Yeah,
okay,
that
makes
sense
what
so
I
I
think
we're
we're
narrowing
down
the
use
case,
the
use
cases.
We
have
a
slightly
clearer
idea
of
what
we
need
to
configure.
A
What
what
are
the
things
that
we
need
to
do
to
actually
move
this
forward.
C
I
think
we're
gonna
need
we're,
gonna,
need
it
like
effectively
to
I
think
we
should.
C
We
should
Mark
the
one
two
way
to
get
the
back
end
properties
Gap
as
declined
or
whatever
the
status
is
called,
and
we
should
start
a
new
one
that
is
English
specific.
You
know
TLS
re-encryption
or
something
like
that,
the
and
then
you
and
then
yeah.
Then
we
need
to
figure
out
how
we're
going
to
do
that.
You
know
someone
in
one
of
the
in
the
use
cases
doc
raise
the
possibility
of
using
a
filter
which
is
like.
Maybe
you
know
that's.
C
That
would
be
a
good
place
to
hang
that
sort
of
thing
where
we
could
add
it
in
as
a
as
sort
of
a
an
alpha
thing.
That
would
be
very
it's
very
clear
that
it's
Alpha,
because
you're
using
the
the
sort
of
the
filter
extension
Point
rather
than
rather
than
adding
in
stanzas
yeah,
and
then
we
consider
if
we
make
that
you
know
if
we
make
the
filter
into
a
standard
filter.
C
That
is
definitely
one
way
we
could
do
it.
Otherwise
would
be
that
we
add
stuff
to
the
back
end.
The
actual
back
end
stanza
to
sort
of
say
you
use
TLS
to
this
back
end
or
something
like
that.
C
The
problem
is
that
use
TLS
to
this
back
end
then,
has
crossover
into
gamma
because
we're
using
the
same
resource
for
both,
and
we
need
to
be
specific
about
hey.
If
we
add
those
things
in
then
then
you
say
that
doesn't
work
for
gamma
use
cases
or
something
so
that's
going
to
apply
for
it
either
way
but
yeah.
Basically,
the
next
steps
are
the
next
steps
are
come
up
with
some
proposals
and
have
people
have
a
think
about
them.
I
think.
A
Okay,
it
feels
like
maybe
we
should
start
the
new
gap
before
we
completely
give
up
on
the
old
Gap
just
in
case
the
new
Gap
ends
up
looking
like
it
probably
will
be
different,
but
maybe
if,
if
we
have
an
idea,
if
we
have
a
you
know
a
compelling
plan
forward,
then
it's
easier
to
just
decline.
The
old
one.
When
we
clearly
know
we
have
a
better
way,
but
that
that
all
makes
sense
to
me
is
there:
is
there
anyone
who's
currently
or
working
on
that
or
planning
on
working
on
that?
G
There's
there
is
an
original
issue:
I
I,
don't
want
to
get
like
completely
far
away
a
completely
I.
Don't
want
to
completely
ignore
the
original
issue
that
I
started
with,
which
is
specifically
for
for
re-encrypt.
We
kind
of
expanded
it
to
to
do
backend
properties
more
more
generically,
rather
than
than
you
know,
just
properties
for
for
re-encrypt
and
now
I
think
we
want
to
go
back
and
not
do
back-end
properties
in
a
generic
way,
but
specifically.
G
What
is
this,
what
is
the
set
of
things
that
that
we're
talking
about
here
other
than
re-encrypt
I,
think
you
said
two
things
Nick,
so
it's
re-encrypt,
but
it's
also.
There
is
also
something
else
that
you
mentioned.
C
So
I
think
yeah
and
when,
when
you're
talking
about
ranked
groups,
you
need
to,
you
know,
consider
what
settings
might
the
Gateway
as
a
TLS
client
need
you
know.
So
if
the
gateway's
data
path
is
being
a
TLS.
H
C
C
You
know
and
that
a
lot
of
the
complexities
around
how
you
handle
like
do
you
allow
or
Force
the
Gateway
data
path
to
have
a
client
search
per
route
back
end
or
one
Global
one
or
a
few
other
things
like
that.
So
yeah
there's
a
few
there's
a
bit
of
design
in
there.
That's
like
once,
you
say:
the
Gateway
data
path
is
now
so
I'm
using
data.
Parks
I,
don't
want
to
say
proxy,
because
not
everyone
has
one
the
see
the
data
plane
for
the
Gateway.
C
Once
it's
a
TLS
client,
you
need
to
be
able
to
configure
that
TLS
client.
You
know
you
there's
a
few
other
things
that
we
talked
about
in
the
TLs
use
cases,
doc
that
we
are
leaving
on
the
table
by
by
focusing
tightly
in
on
that
things
like
TLS
minimum
versions.
C
You
know
other
stuff
that
we
talked
about
in
the
back-end
properties
thing
like
you.
What
past
websockets
is
enabled
on,
and
some
other
things
like
that
that
or
what?
What
parts
should
the
gateways
data
plane
allow
to
be
to
handle
the
websocket
upgrade,
and
things
like
that,
but
I
think
that
a
lot
of
those
are
going
to
be
relevant
in
the
gamma
use
cases
as
well,
so
yeah.
C
A
I
think
that
I
think
that
makes
sense
yeah
I
do
I
do
want
to
move
on
because
we
do
have
a
few
other
things
on
the
list.
But
just
is
there
anything
we
can
do
to
make
sure
we
don't
lose
this
context.
Well,
I,
guess
they're
they're,
all
right.
It
sounds
like
God.
C
It's
on
my
to-do
list
or
at
like
my
to
keep
an
eye
on
list.
That's
why
I've
been
poking
at
the
TLs
use
cases
doc,
but
to
to
make
100
sure
that
we
don't
do
that.
Like
that's,
why
I
propose
making
a
new
Gap
issue
so
Candace?
We
already
have
the
the
sort
of
the
feature
request
issue
that
you
logged
ages
ago,
but
that's
I
think
that
it
would
be
good
to
have
a
new
Gap
issue.
C
You
know
and
that
you
basically
then,
and
then
maybe
we
add
some
stuff
about
TLS
right
and
how
you
handle
some
of
those
things.
But
but
the
the
core
use
case
here
we're
dealing
with
is
your
tailless
on.
You
know
on.
C
Re-Encrypt
at
the
Gateway
level
and
make
sure
that
we're
tightly
scoping
it
to
just
Ingress
so
that
we
can
ensure
that
we're
clear
that
this
is
not
about
the
camera
stuff,
so
I
think
that's
probably
the
next
step
is
to
have
is
to
for
one
of
us
to
create
that
Candace.
If
you
want
to
do
that,
that's
cool!
Otherwise,
if
you
don't
I'm
happy
to
do
it.
C
So
yeah,
so
our
Bowie
makes
the
point
that
this
is
that
we
shouldn't
call
it
re-encrypt,
because
you
could.
This
could
also
be
an
upgrade
feature.
We
should
be
relatively
so
it
could
be
that
you
get
plain
text
HTTP
in
and
you
get
https
out,
but
so
the
yeah.
So
this
this
is
about.
D
Https
as
well
as
tcps
right,
so
you
don't
have
to
terminate
at
the
HTTP
level.
You
could
terminate
just
a
TCP
and
transform
either
way.
C
I
think
so
that's
something
yeah.
We
definitely
need
to
think
about
I
think
so
yeah,
because
it's
only
about
the
TLs
layout
it
shouldn't.
We
shouldn't
be
using
any
TLS
specific
things.
There
yeah.
C
Yeah
yeah
I,
understand,
I,
understand
it's
just
yeah
I
I,
don't
think
we
I
mean
the
main
use
case
like
the
first
use
case
we
want
to
get.
Is
the
https
like
yo?
Is
the
Gateway
encrypting
HTTP
straphics
into
https,
but
you're
right?
We
should
try
and
ensure
that
we
don't
rule
out.
You
know
generic
TLS
stream
when
we
did
the
design
yeah.
A
I
I
do
want
to
do
a
time
check
here.
We've
got
a
few
other
things
to
get
through
yeah.
Now
the
great
discussion
I
think
we
have
clear
follow-ups
here,
and
hopefully
this
means
we'll
have
lots
of
good
discussion
on
a
a
focused
Gap
and
yeah
I
would
love
to
see
that
move
forward.
A
A
A
Maybe
this
is
another
one
where
I
need
go
ahead,
Shane
or
is
that
just
a
a
yes.
A
And
and
I
know
we
we
already
support
that
in
gke
and
yeah,
so
I'll
just
again
time
today.
Anyone
else
feel
free
to
add,
add
yourself.
There
I
am
trying
to
find
what
it
takes.
I.
C
Had
I
have
an
open
PR
actually
to
to
add
some
extra
wording
to
that.
C
Yes,
yeah
so
yeah,
there
is
an
open
PR
that
adds
a
bunch
of
language
to
that.
That
sort
of
clarifies
a
few
things
and
adds
makes
clear
a
couple
of
other
things
that
were
that
are
not
currently
clear,
and
it
actually
reverses
one
thing
that
is
in
there
that
says
that
you
can't
do
custom
filters
and
policy
attachment
at
the
same
time.
C
I
think
that
one
that
one
was
a
thing
that
we
put
in
when
we
first
think
about
this,
but
I
think
that's
a
mistake
and
the
policy
industry
is
actually
the
best
ways
if
you
are
doing
custom
filters
to
be
able
to
configure
those
to
be
able
to
sort
of
do
a
higher
layout
configuration
of
a
custom
filter.
A
Let
me
find
interesting:
okay,
okay,
yeah
now,
I
I
will
follow
up
with
that.
I
do
remember
that
it's
been
ages
since
I've
taken
a
look.
I
am
interested
in
moving
this
one
forward.
I.
A
You
know
it's
still
labeled
as
Alpha.
This
is
not
a
resource
itself.
It
is
a.
It
is
just
a
a
set
of
types
really
in
a
pattern.
C
Really
yeah
yeah
examples
of
implementations
doing
it
then
it
will
remain
so.
It.
C
On
my
wish
list
for
a
long
time
to
have
a
sort
of
included
in
the
API
one
that
we
or
some
you
know
some
reference
in
the
docs
to
some
standard,
relatively
standard
or
like
good
implementations
of
this
API,
but
that
requires
people
to
actually
do
implementations
of
the
API.
The
one
I
wanted
to
do,
which
I
was
considering
doing
for
on
the
Gateway,
is
an
Envoy
timeout
policy.
F
C
As
we
said,
timeout
policy
timeout
policy
is
really
hard
to
do
and
basically
requires
something
like
policy
attachment.
Sadly,
I've
had
a
number
of
discussions
with
people
that
are
like.
Surely
it's
not
that
difficult
and
I'm,
like
trust
me,
Rob
and
I
spent
weeks
weeks
trying
to
make
something
work
and
we
couldn't
you
know
so,
yeah
I
think
yeah.
So
there's
definitely
that's
what
I'd
like
to
see
eventually.
Is
that
page?
C
Have
you
know
not
only
sort
of
here's
generically
how
you
use
it,
but
also
some
links
to
say
here
are
some
limit
some
implementations
of
this,
to
give
you
some
ideas
about
what
this
looks
like,
but
the
the
other
thing
that's
included
in
that
update
is
an
update
to
the
language
that
makes
clear
that
policy
attachment
is
a
type
of
meta
resource.
A
meta
resource
is
a
resource
that
you
modifies
or
Alters
or
enhances
the
functionality
of
another
resource
reference.
C
Grant
is
another
example,
and
so
you
just
just
to
make
that
language
a
little
bit
clearer,
because
I
think
that
people
using
policy
attachment
to
in
the
policy
attachment
part
in
my
mind,
is
about
the
hierarchy
and
cascading
down
down
the
hierarchy.
Defining
a
policy
at
Gateway
having
it
apply
to
routes
is
what
policy
attachment
is
really
about
so
yeah.
So
that's
why
I
wanted
to
make
that
update.
So.
A
Okay,
anyway,
well,
I
I
will
definitely
add
that
list
to
try
and
review
it
this
week.
Thank
you.
We
ran
out
of
time
for
the
rest
of
the
round
types
here,
but
I
know
Candace.
Thank
you.
Your
conformance
tests
have
already
merged
I.
That
was
one
of
the
biggest
blockers
for
TLS
route.
I.
Think
a
lot
of
these
were
just
going
to
also
be
asking
for
what
implementations
out.
There
are
already
supporting
TLS
route,
so
you
know
in
until
we
have
centralized
conformance
reporting.
A
The
best
thing
we
can
do,
I
think
is
just
ask
in
slack
or
GitHub
and
try
and
you
know,
standardize
work.
You
know
centralize
the
responses
there.
That's
probably
the
trickiest
part
of
our.
You
know
graduation
Beyond,
Alpha
right
now,
but
TLS
route
feels
like
the
next
closest
thing
at
this
point
and
then
the
rest
are
all
a
little
bit
further
off,
but
excited
for
oblixt
and
hopefully
that'll
help
us
move
through
these.
We
are
at
times
so
I
want
to
be
recognize
that,
but
there
are
pull
requests
that
could
use
review.
A
I've
been
a
little
underwater,
but
I
am
hoping
to
get
through.
Some
of
these,
but
if
anyone
else
has
time,
other
reviews
are
very
very
welcome.
Yeah
with
that
any
any
last
things
before
we
close
off.
A
Great
have
a
good
rest
of
your
week.
Everyone-
and
some
of
you
will
see
you
for
a
gamma
meeting
tomorrow,
have
a
great
one,
bye.