►
From YouTube: Gateway API GAMMA Meeting for 20230627
Description
Gateway API GAMMA Meeting for 20230627
A
A
As
a
reminder,
we
do
have
an
open,
Agenda
and
I
have
linked
that
agenda
to
here
in
the
chat.
So
please,
if
you've
got
a
topic
about,
discuss,
app,
feel
free
to
add
it
onto
the
agenda
and
also,
if
you
wouldn't
mind,
go
ahead
and
put
your
name
and
Company
affiliation
or
just
general
affiliation
in
the
attendees
list.
Just
so,
you
have
a
record
of
your
attendance
as
we
constantly
try
to
evaluate
our
meeting
times,
make
sure
we're
being
inclusive
to
as
many
people
as
you
can.
A
A
That
looking
okay
size,
everything
good
to
everybody,
fantastic.
A
B
Yeah
I
think
this
is
really
just
a
follow-up
from
the
last
meeting
as
well,
but
thankfully
we
have
made
some
progress,
a
big
thanks
to
Mike
not
on
this
call,
but
he
has
a
PR
out
for
apis
spec
updates.
B
That
is
the
one
thing
of
all
of
this
that
we
absolutely
do
need
to
get
in
before
we
can
go
to
API
review
like
the
goal
I
had
was
to
be
code
complete,
ideally
this
week,
but
ASAP
I
know
we're
about
to
run
into
some
holidays,
but
we
do
really
want
to
get
this
this
through
as
quickly
as
possible.
I
think
this
is
the
big
blocker.
B
In
my
opinion,
this
is
awfully
close,
I
added
some
kind
of
nitpicky
things,
but
I,
don't
think,
there's
huge
blockers
anywhere,
but
would
appreciate
some
more
reviews.
Keith
I
appreciate
you
taking
a
look,
but
others
on
the
call.
B
If
you
can
take
a
look,
this
is
really
the
first
time
that
gamma
is
being
represented
in
API
spec
and
it's
a
little
bit
messy
I'll
say
that
you
know
we're
trying
to
combine
two
concepts
and
and
make
them
both
make
sense
in
the
same
spec,
I
I
think
Mike
did
the
best
that
we
possibly
could
here,
but
it
is.
It
is
a
tricky
thing,
so
yeah
help
advice
whatever
wanted
here.
B
One
thing
I
do
want
to
call
out,
and
maybe
good
for
discussion
here,
I
added
a
comment
that
I,
don't
think
has
been
discussed
before
I
just
missed
the
topic,
there's
one
on
reference,
Grant
yeah,
that's
the
one!
Thank
you
kind
of
two
questions,
but
I'll
start
with
maybe
the
easier
one.
B
First,
if
a
reference,
Grant
grants
accessed
from
an
HTTP
route
to
a
service,
is
that
intended
only
for
backend,
refs
I'm
assuming
so,
but
we
haven't
really
clarified
that
anywhere
because
now
we're
introducing
another
way
where
an
HP
route
can
reference
a
service,
and
we
haven't
really
clarified
what
that
means
for
reference
Grant.
B
Anyone
have
a
strong
opinion,
like
I
I
mean
one
potential
interpretation
of
that
is
that
if
you
use
reference
Grant
and
you're
using
gamma
and
parent
ref
for
service,
then
what
was
a
consumer
route
was
a
becomes
a
producer
out
I
mixed
those
up
in
my
comment
but
like
you
could
like
mix
interpretations,
but
it
feels
really
funny
to
do
that.
I,
don't
think
we
actually
want
to
do
that.
A
Yeah
so,
from
my
perspective,
reference
grants
purpose
is
sort
of
I
think
it's
fairly
orthogonal
to
the
parent,
rep
interpretation
of
of
service
or
the
other
parent
representative
service,
because
especially
a
lot
of
the
consumer
routes,
piece
of
the
of
the
gamma
application
of
the
step.
Essentially,
what
you're
saying
is
when
I
send
connections
to
this
endpoint
to
this
host.
A
Then
this
is
the
configuration
right
you're,
not
it's
not
a
producer,
giving
or
it's
not
something
giving
access
to
another
service.
That's
more
of
saying
this
is
my
destination
and
do
it
and
make
changes
to
the
configuration
or
to
the
traffic.
In
this
way.
It's
it's
probably
the
closest
thing
we
have
to
something
like
egress,
but
that
that's
kind
of
that's
that's
irrelevant,
but
yeah
because
of
the
outbound
nature
of
of
it.
A
I,
don't
see
where
reference
Grant
makes
sense
for
parent
ref
from
a
ideological
perspective,
not
to
mention
the
fact
that
the
ux
just
gets
really
confusing.
If
you
can
have
reference
grant
for
both
parent
and
back
and
graph.
A
Those
marriage
alone,
I,
wouldn't
be
in
favor
of
it,
but
I
think
we
have
a
strong
enough,
a
strong
enough
set
of
definitions
that
we
don't
have
to.
We
can
say
no
and
more
than
just
a
ux
ux
basis
that
that's
my
perspective
anyway.
B
I'm
not
hearing
any
strong
opinions
other
than
that
and
I
agree
with
everything
you
said,
but
please
anyone
else
feel
free
to
jump
in
I.
I
think
that
that
is
the
most
sensible,
oh
actually
John,
maybe
you're
about
to
say
something.
Yeah.
D
D
C
B
Clarify
yeah
right
now
we
aren't.
We
haven't
said
that
anywhere
in
the
spec
and
I
am
suggesting
that
maybe
we
should
and
I
I
guess
no
I
should
I
should
say
that
reference
Grant
could
still
be
useful
in
gamma.
D
D
Yeah
yeah
I
definitely
agree,
never
apparent
ref.
Never
reference
grant
that
that's
I
think
clear
the
lot
not
using
for
back
and
ref-
that's,
maybe
a
bit
more
controversial,
but
it
is
specified
in
the
Gap
in
conformance
tested.
D
Rationale
was
that
in
Ingress,
you're
saying
like
there's
this
thing,
that's
exposing
things
publicly
and
now
some
random
person's
exposing
you,
but
in
mesh
it's
more
like
I,
can
already
call
you
and
now
I'm,
just
configuring
how
I
call
you
it's
not
really
so
inversion
of
visibility
and
whatnot.
How.
D
Most
implementations
of
mesh
cannot
bypass
Network
policy
kind
of
by
definition,
all
the
sidecar
stuff,
like
there's
no
really
way
to
bypass
Network
policy.
So,
yes,
I,
don't
know
if
I'll
say
that
everyone
like
I'm,
not
sure
the
details
of
how
psyllium,
for
example,
does
it
because
they
are
both
the
network
policy,
enforcer
and
the
mesh.
B
So
I
think
I
think
what
we
have
in
the
spec
already
is
that
there's
some
such
notion
of
you
don't
need
reference
Grant
for
cross
namespace
background
refs,
if
you
have
some
other
form
of
security
available.
Network
policy
is
an
example
of
that.
As
long
as
Network
policy
interacts,
you
know,
affects
your
your
routing
Behavior
and
is
not
just
going
to
be
completely
bypassed
by
something
like
a
load.
Balancer
interpretation.
B
Okay,
so
it
sounds
like
we
just
need
to
clean
up
the
it
sounds
like
we
all
agree.
We
just
need
to
make
sure
that
the
spec
is
awfully
clear
around
that
okay
I
can
I
can
sketch
I
can
update
my
comment
or
I
have
a
follow-up
comment
after
this
meeting,
but
yeah
I
think
that's
the
only
thing
I
wanted
to
call
out.
I
definitely
appreciate
anyone
else.
Take
another
look
at
this
PR,
but
I
think
it's
fairly
close.
B
Yeah
Flynn
mentioned
in
slack
today
that
he
was
unfortunately
not
going
to
be
able
to
make
it
to
today's
meeting,
but
I
hope
to
get
some
docs
updates
out
later
this
week.
I
would
imagine
that
he
would
certainly
welcome
help
if
anyone
is
around
and
able
to
help.
I
I
can
imagine
that
that
would
be
very
welcome
here.
B
So
there
there
are
two
things:
one
is
the
general
docs
updates
thing
is
just
adding
larger
and
more
information
around
the
gamma,
instead
of
just
right
now,
everything's,
hidden
in
gaps
and
then
secondarily
drafting
a
blog
post
that
we
can
use
to
announce
080,
and
you
know
the
official
graduation
of
gamma
to
something
that
is
released
in
080
yeah,
and
so
we
have
some
rough
idea
for
co-authors,
but
if
you're
not
already
looped
in
and
our
interest
in
being
listed
on,
that
definitely
I
guess
never
reach
out
to
Flynn.
B
Man,
I
think
I
think
I
have
everything
on
this
agenda,
so
anyone
feel
free
to
jump
jump
in
oh
great,
thanks
David
for
reaching
out
okay.
So
next
up
is
just
meeting
time
changes,
I've,
I
kind
of
went
back
through
the
agenda
to
try
and
see
when
people
were
showing
up
and
it's
kind
of
a
mixed
bag.
I
thought
the
morning
the
earlier
time
slot
was
getting
more
attendees,
but
it
doesn't
seem
obvious
either
way.
They've
both
been
fairly
lightly
attended.
B
What
does
seem
increasingly
I,
don't
want
to
say
clear,
but
it
seems
like
we
may
be
moving
to
a
point
where
we
only
need
a
meeting
every
couple
weeks
instead
of
a
meeting
every
week,
so
I'm
at
least
suggesting.
That
could
be
something
to
consider.
I,
don't
know
if
anyone
has
opinions
on
that
I'm
just
trying
to
make
sure
we're
we're.
Making
an
efficient
use
of
these
times
sounds
like
Sean's
on
board.
With
that
anyone
else,
cool.
A
I'll
I'll
come
up
mutant
just
and
say
that
I
I
think
bi-weekly
makes
sense.
There's
a
lot
of
a
lot
of
open
questions
in
the
beginning
of
gamma.
Improving
this
out
and
I
think
the
frequency
that
the
weekly
frequency
was
really
helpful
and
aided
in
US
kind
of
getting
to
where
we
are
a
year
from
now.
I
think,
because
so
much
of
I
think
this
is
a
good
thing.
A
I
think
a
lot
of
the
gamma
conversations
are,
you
know
also
happening
in
the
Gateway
yeah,
the
main
meeting
the
Ingress
meeting,
because
they're
it's
cross-functional
they're,
at
least
for
me,
I'm
I'm,
seeing
less
mesh
specific
things
pop
up,
usually
there's
going
to
be
some
I
think
we
need
to
go
check
out.
The
main
Gateway
group
about
so
I
think
bi-weekly
for
now
really
really
makes
sense.
A
I
will
say
that
there
is
I've
had
several
conversation
with
folks,
especially
notably
during
during
kubecon
on
Amsterdam,
about
mesh
in
kubernetes
in
general.
How
gamma
is
kind
of
a
place
where,
where
lots
of
most
people
want
to
have
been
looking
to
get
things
to
happen,
but
Gateway
API,
like
a
Gateway
API
Sub
sub
project
is
necessarily
the
best
place
for
those
same
things
to
happen
and
I
think
that
to
point
Rob
made
earlier
I
think
some
of
the
attendance
changes
might
be
indicative
of
that.
A
So
I'll
say
if
there
are
things
that
you
feel
like
you,
if
you
have
Integrations
with
kubernetes
and
service
maps
that
you
feel
aren't
being
met
or
nobody's
looking
at
reach
out
to
me,
I'd
love
to
check
to
see
if,
if
there
might
be
a
way
for
us
to
do
that,
one
area
that
comes
to
mind
for
me
is
is
telemetry
and
obserability
in
general,
so
I
have
another
another
good
one
is
like
cni
compatibility
between
service
mesh
and
Technologies
and
such
so.
A
If
you've
got
thoughts
on
that,
let
me
know-
or
you
know
let
anybody
know
but
I'm
interested
in
talking
to
more
books
and
companies
and
figuring
out
what
the
best
place
for
some
of
those
conversations
would
be
because
I
don't
want
to
don't
want
to
have
the
scope
of
this
meeting
this
group
get
too
too
large.
So
it's
a
lot
of
words
to
say
yes,.
B
A
B
Yeah
I
think
those
are
some
really
good
points
and
I
certainly
don't
want
Gateway
API
to
be
a
limiting
factor
of
what
this
this
group
can
do.
I
think
mesh
and
kubernetes
is,
is
awesome
and
want
to
see
more
standardization,
Gateway
API
and
his
kind
of
the
starting
point.
I'm
glad
that's
working
but
I
know
mesh
can
can
be
broader,
so
yeah
open
to
ideas.
B
It
sounds
like
there's
there's
broad
agreement
for
going
back
to
bi-weekly
meetings
then
so
that
seems
good
and
then
the
only
other
question
I
had
is.
Should
we
continue
to
rotate
between
earlier
and
later
times.
B
B
Cool
yes,
I
I
also
I
mean
Pacific
time
earlier
is
I
I
can
I
can
manage,
but
I
don't
love
it.
So,
yes,
it's
good
to
hear
someone
else
appreciates
the
later
time.
B
Okay,
great
so
maybe
what
that
means
is
we'll
we'll
transition
to
bi-weekly
meetings,
rotating
and
I,
don't
know,
I,
think
any
of
the
gamma
leads
have
enough
access
to
update
Signet
calendars
and
such,
but
if
not
at
least
Shane
and
myself
do
so
yeah,
just
just
let
us
know
and
and
I
think
we
already
mentioned
this,
but
next
week
the
meeting
is
on
July
4th,
which
for
many
of
us
in
the
U.S,
no
one's
going
to
be
around
so
just
canceled
and
so
we're
already
accidentally
starting
our
bi-weekly
transition.
So
yeah
cool.
E
This
is
David
by
the
way
I
just
wanted.
The
comment
on
Keys
common
one.
You
know
other
projects
to
integrate
with
and
Argo
CD
and
Flagger
I
think
the
supported
SMI
in
the
past,
or
maybe
they
still
do
and
I
know.
You
worked
on
the
SMI
initiative,
Keith
I,
don't
know
if
that's
the
same
thing
that
we
would
pursue
with
gamma
I
know
there
they
have
a
little
bit
more
or
the
the
SMI.
Crds
are
a
little
bit
more
nuanced
than
the
gamma
CDs.
A
Yeah,
that's
a
really
good
point,
so
SMI
resources,
it's
important,
I,
know
that
lager
yeah
it's
Fragger
and
are
going
to
roll
out
to
go
support.
Smi
I
know
Flagger
specifically
does
have
completely
API
support
for
Ingress.
At
least
I
do
think
that
it
that
effort
has
borne
a
conversation
to
see
what
kind
of
you
see
if
there's
any,
essentially
resources
that
guidance
needed
to
get
that
to
get
sort
of
the
same
integration
for
Gateway
API
for
mesh
or
gamma.
A
In
in
what
ways
we
do
have
conformance
tests.
We
I
love
to
like
to
have
more
conformance
tests,
as
we
prevent
more
of
a
set
I
think
that'll
be
helpful.
A
My
understanding
is
that
SMI
will
be
as
a
CSF
project
should
be.
Our
cut
will
be
archived
in
the
somewhat
near
future
and
so
I
think
that
reaching
out
to
them
would
be
a
good
idea.
Let's,
let's
chat
offline
about
that,
some
more
David
and
and
see
what's
what's
necessary,
there
yeah.
E
And
think
of
the
two
from
what
I
know,
Argo
is
probably
more
higher
party
than
Flagger
from
when
I
can
tell
more.
People
are
adopting
Argo
for
the
CI
CD
stuff
is.
C
This
question
about
using
Argo
rollouts
with
with
like
HTTP
route.
C
B
Yeah
they
actually,
they
had
a
really
good
demo
at
kubecon
a
little
bit
ago,
maybe
two
ago,
I'm
not
sure,
but
yes,
they've
been
great
or
maybe
I'm,
mixing
up
what
the
demo
was,
but
anyway,
I
know.
Argo
and
flag
are
both
both
support,
Gateway,
but
I
think
our
Focus
has
been
on
the
Ingress
side
of
things.
B
I
think
the
difference
is
fairly
minimal,
because
it's
both
HP
route
is
the
focus,
and
it's
really
just
can
they
support
a
service
as
a
parent
instead
of
a
Gateway,
so
there's
probably
still
some
work.
That
needs
to
be
done,
but
hopefully
minimal,
and
you
know
I
think
this
080
release
is
really
neat
thing
to
encourage
Integrations
like
that
to
go
ahead
and
and
build
something
on
top
of
it.
E
A
A
Okay,
all
right.
The
next
adamant
is
mine.
I
want
to
give
the
update
on
operation
policy
a
couple
names
ago.
I
took
the
action
at
him
to
start
doing
some
some
research
and
and
write
a
a
what
and
why
get
around
why
we
might
want
operation
policy
for
gamma
I've
got
the
outline
of
these
kind
of
kind
of
figured
out.
I
want
to
share
the
current
form.
A
The
document's
still
a
way
to
go
to
fill
in
some
of
this
stuff,
but
want
to
make
sure
that
the
scope
is
what
folks
were
thinking
and
make
sure
I
wasn't
missing
anything
before
I'll
go
off
and
pull
this
in
I.
Basically,
and
just
stuck
my
introduction
about
what
we're
trying
to
achieve.
You
know
ideally
there's
a
robust
enough
subset
of
common
functionality
between
different
data
implementations
and
that's
really
kind
of
the
focus
of
the
signature
exploration.
A
My
initial
scope
is
around
the
semantics:
allowed
and
I
absence
of
rules
empty
list
of
rules,
all
those
sorts
of
nuances.
In
addition
to
what
attributes
are
available
for
matching
traffic
in
the
policy
split
by
L4,
L7
type
of
type
of
attributes
got
a
couple
of
different
data
planes
for
for
prior
Arts,
like
for
kubernetes
I
should
I
should
say
kubernetes
cni
as
one
because
there
is
Network
policy
as
well
as
the
admin
Network
policy
cap.
A
That's
being
developed,
got
one
going
for
Envoy
that
should
capture
envoy-based
implementations
and
the
next
we'll
enter.
Do
you
really
love
Linker
these
docs
here,
because
I
was
able
to
just
copy
all
of
this
stuff
in
this
pretty
pretty
straightforward?
So
thanks
liquidity
for
making
my
my
job
easy
and
then
until
you're,
affiliate,
Network
policy
resource?
A
D
I
think
looking
at
just
the
envoy
ones
may
be
a
bit
misleading
because
the
envoy
API
is
not
for
humans.
D
A
A
I'm
tempted
to
say
data
plane,
capability
first
and
then
maybe
I
add
an
actual
actual
private
art
section
for
apis
and
maybe
edit
and
then
edit.
You
know,
dig
deeper
into
link
routine
here
and
just
pull
out
the
these
two
things
so
semantics
and
attributes
and
then
dive
deeper
into
API
differences
and
then
that'll
be
very
much.
Istio
versus
console
versus
I
actually
got
Kong
and
Kuma
in
here
as
well.
That's
when
I
that
I
forgot.
B
Yeah,
that's
that
was
actually
what
I
was
going
to
suggest.
I.
Think
it's
good
to
highlight
kind
of
the
the
high
level
Envoy
API,
but
maybe
almost
as
sub
headings
or
or
maybe
it's
just
different
sections,
but
I
know
there
are
several
Envoy
based
meshes
that
are
part
of
this,
so
like
istio,
Kuma,
I
think
console
would
also
be
all
under
Envoy,
so
you
could
potentially
include
them
all
there
too,
but
I
think
they
all
have
fairly
different
apis.
D
E
A
I
don't
know
I
put
on
whether
on
my
console
and
then
right
awesome
all
right
thanks.
That's
the
reason
why
I
my
ass
okay,
yeah
you're
right
Jonah
said
total
API
as
well.
It's
somewhat
the
same
but
I'll
add
a
sub
subheading
for
the
tunnel.
D
I
was
just
gonna
say
my
other
comment.
I
know
right
now.
This
is
focus
on
gamma.
It
may
make
sense
for
similar
things
to
also
apply
to
inverse
something.
We
should
keep
in
mind
or
talk
about
or
something.
B
Yeah
I
think
we're
quickly
going
to
end
up
moving
in
a
different
direction
where,
for
so
many
things,
Gateway,
API
and
Ingress
were
first
because
it
started
first
but
I.
Imagine
especially
when
it
comes
to
authorization
policy
will
originate
from
from
gamma,
but
I.
Imagine
Ingress.
Some
Ingress
implementations
May
care
about
this
too.
So
maybe
a
new
reality
where,
where
things
start
here
and
go
the
other
direction
for
a
change.
A
So
I
guess
the
for
me.
The
question
is:
what's
the
overlap
between
operation
policy
and
reference
Grant
and
and
how
you
have
to
figure
this
out
now,
you
know
we'll
just
get
further
that
I
just
had
one
thing:
I
I
did
I
remember
this
earlier.
We
got
it
in
until
now,
but
as
far
as
non-goals
go
I,
I
think
it
still
makes
sense
to
keep
mtls
out
of
scope.
A
Here,
we've
come
explicitly
from
the
beginning:
I'll
try
to
keep
in
TLS
implementation
details
out
of
the
spec
I.
Think
that
still
makes
sense
here
and
we
can
just
when
designing
the
API
just
lean
on
identities,
without
necessarily
defining
how
those
identities
are
populated
or
communicated.
A
C
D
C
D
You
know
you
could
have
a
match
that
says
like
the
things
that
should
be
unauthenticated
and
then
we
could
add
some
static
response
or
something
you
put
a
403
there,
but
it
kind
of
can
get
a
bit
unmanageable,
probably
like
you
might
imagine,
for
example,
a
filter
that
does
oauth
authentication
and
then
I,
don't
think
you
match
you
match
before
filters.
Not
after
so
then
how
do
you
do
like
a
match
that
they're
authenticated?
What
does
that
even
mean?
D
D
I
think
there's
also
some
desire
to
like
matching
is
just
matching
a
lot
of
times.
The
policies
have
allows
versus
denies,
which
can
kind
of
decouple
the
policies
from
the
routes.
D
That
also
is
useful
for
attaching
outside
of
a
route
like
you
may
want
to
say,
I,
don't
think
this
is
really
it's
synthetic
but
like
I,
want
to
deny
all
post
requests
across
my
Gateway
right.
You
can't
really
represent
that
in
a
route,
there's
probably
much
better
examples
of
that.
Maybe
denial,
unauthenticated
traffic
or
something
would
maybe
be
a
more
realistic
one.
D
So
that's
that's.
How
I
see
it
it's
less
critical
for
mesh,
because
today
we
don't
have
kind
of
an
inbound
route
system
at
all
in
gamma,
so
it
was
actually
like
Alternatives,
but
I.
Think
it's
still
fairly
important
to
have
something
along
these
lines.
In
Ingress.
A
Yeah,
my
my
gut
feeling
is
that,
when
writing
the
API
we
are
going
to
have
to
be
very
clear
about
when
the
authorizations
after
authentication
happens
in
the
like
in
the
like
traffic
life
cycle.
A
I
also
wouldn't
be
surprised
if
we
see
maybe
not
hooked
with
the
Gateway
API
itself,
but
if
we
don't
see
other
implementations
or
specific
implementations,
how
things
like?
Oh
walk
policy,
filter
and
or
JWT
policy,
or
whatever,
like
a
suite
of
different
policies
for
specific
things
that
might
take
place
before
after
the
messages
John
said,
there's
a
lot
of
potential
complexity
I.
My
goal
for
this
is
for,
like
that
very
basic
level,
routing
of
policy.
This
I
don't
think
you
can
talk
to
this
identity
versus
not
this
identity
and
I.
A
Think
if
we
can
get
that
done
well,
I've
solved,
like
maybe
70,
to
80
of
the
use
cases,
maybe
that's
idealistic,
and
then
we
can
have
interested
parties
iterate
on
some
of
the
other,
more
finely
grained
policies
for
cranky
things
like
a
lot
they're.
What
have
you
just
my
lunch
anyway?
A
Yeah
if
there
are
no
other
thoughts,
like
I,
said
I'm
gonna.
My
goal
is
to
try
to
have
this
by
the
next
meeting,
which
is
in
two
weeks,
so
that
gives
me
a
good
time
to
continue
the
survey
if
you've
got
anything
specific
for
your
implementation,
that
you
want
to
make
sure
is
added
or
some
Nuance
that
you
want
to.
A
You
know
be
watching
want
me
to
watch
out
for
just
let
me
know,
I'll
paste
the
link
to
this
in
the
meeting
notes.
I
realize
you
never
did
that.
A
All
right,
if
there's
nothing
else
on
that
topic,
we
can
move
on
to
triage.
We've
got
TLS
from
Gateway
to
backend
yeah.
B
Neither
of
these
are
that
tied
to
mesh,
but
they're
they're
leftovers
from
the
last
meeting,
which
is
a
hybrid
meeting.
C
B
This
is
just
more
of
a
call
out
that
these
things
really
need
review
this.
These
are
I,
think,
probably
our
our
most
critical,
open
PRS
that
are
kind
of
more
more
long-term.
You
know
make
making
longer
term
effects.
Api
changes
so
just
could
could
use
some
fresh
reviews
on
that
one
and
then
especially
the
the
last
one,
which
is
the
timeouts.
This
one
still
has
a
chance,
a
thin
chance,
but
a
chance
that
it
can
make
it
into
080.
B
I.
Think
one
thing
that
maybe
hasn't
been
expressed
clearly
enough
is
that
HP
or
out
timeouts
and
what's
included
here,
is
probably
not
the
the
last
set
of
timeouts
that
make
it
into
the
API,
but
they
are
a
set
that
are
fairly
broadly
implementable.
B
A
Yeah
the
the
timeouts
had
set
my
mind
so
I
appreciate
the
the
heads
up
here:
cool
yeah,
I'll
I'll
go
back
and
add
this
to
my
list
and
read
through
it.
B
Yeah
this
I
should
add.
This
is
a
bit
of
a
for
people
who
may
not
have
it's
hard
to
keep
track
of
everything,
but
this
is
an
unfortunate
thing
where
both
timeouts,
that
are
being
added
are
extended
only
we
could
not
find
any
that
could
be
labeled
as
core
and
largely
what
these
are
going
to
be
is
implementable
by
at
least
Envoy
and
H.A
proxy
based
implementations,
maybe
others,
but
it's
it's.
It
sounded
like
at
least
nginx
would
have
some
difficulty
here
and
I.
B
C
D
is
planning
to
important
piece.
In
fact,
you
know
the
sooner
that
we
can
get
this
merged,
actually
the
better
for
us.
So
I'm
really
excited
to
see
this
merge.
You
know
soon,
if
possible.
Oh.
B
Okay,
well,
that's
that's
great
I
I
got
that
wrong,
but
that's
awesome
to
hear
so
yeah.
It
I've
got
a
review
I'm
hoping
to
finish
up
this
afternoon,
but
more
reviews
helps
this
move
a
little
faster,
so
yeah
awesome.
A
That's
fantastic
news:
yeah
thanks
for
putting
this
up,
I
think
that
triage
in
the
gamma
meeting
has
been
historically
light,
just
because
we
haven't
had
a
ton
of
gamma-specific
PRS
in
play,
but
I
really
love
that
this.
This
was
a
holdover
from
the
from
the
hybrid
meeting
because
it
helps
you
know
these
two
like
TLS
and
timeouts
are
very
relevant
to
a
lot
of
mesh
mutations,
some
of
which
have
gateways
and
some
don't
so.
We
appreciate
the
call
out
here.
A
I'll
get
both
of
these
some
review
in
the
next
couple
days.
A
All
right,
and
with
that
that
is
the
end
of
our
agenda,
do
we
have
any
last
topics
or
conversations
anybody
wants
to
have,
or
else
I'll
give
you
20
minutes
back.
C
I
just
wanted
to
ask
on
on
that
time
up
here
we
were
just
looking
at
you
know.
If
the
stars
do
align
and
we
get
those
reviews
coming
in
quickly
when's
the
soonest.
We
could
expect
that
to
potentially
merge.
B
Yeah,
so
our
goal
was
to
have
code
completion
by
the
end
of
this
week.
We'll
see
if
that
happens,
this
one
is
largely
code
complete.
The
the
thing
I
was
asking
for
I
have
a
few
nitpicks
on
that
I'm
about
to
add
on
that
on
the
actual
PR,
but
I'm
I'm,
hoping
it
will
merge
in
the
next
couple
of
weeks
and
our
goal
for
release
is
end
of
July.
B
So
what
what
happens
in
between
is?
We
need
to
go
through
API
review
process
with
Cygnet
API
reviewers,
and
that
takes
usually
two
to
three
weeks.
It's
just
slow
back
and
forth
kind
of
process.
I
usually
have
a
release
candid
out
out
fairly
early
in
that
process
and
then
hopefully,
we'll
have
a
final
one
out.
B
A
B
Yeah
and
I'll
say
these
are
really
difficult,
conformance
tests
to
write
because
you're
kind
of
getting
out
ahead
of
any
implementation
that
exists
to
support
it.
So
it's
kind
of
a
best
effort
and
will
almost
certainly
be
adjusted
as
time
goes
on.
But
it's
helpful
to
have
that
kind
of
initial
framework
in
place
that
can
be
built
on
later.
A
Yeah
I
for
one
one
thing
last
thing
I'll
say
on
this-
is
that
it's
really
cool
for
to
see
this
come
through
because
I
remember.
A
This
is
one
of
those
things
that
historically
Gateway
API
had
kind
of
tried
before
and
had
to
come
back
around
to
it
and
it
we
found
some
Way
Forward,
even
if
it's
just
extended,
so
the
conformance,
it's
still
something
that's
invariance,
first
class,
an
API
on
HTTP
routing,
so
that's
really
cool
to
see
the
community
at
work
here,
people
it's
a
first-time
contributor
to
get
my
API
people.
So
that's
just
really
cool
to
see
the
community
kind
of
Stack
hand
on
this.
B
Yeah
this
is
this-
has
been
really
neat
to
see.
This
particular
author
was
mirroring
the
Gap
as
the
Gap
was
being
written,
the
implementation
was
being
written
and
it
just
kept
on
staying
in
sync
the
whole
time,
and
so
that's
how
we
have
a
quick
turnaround,
which
is
awesome.
A
I'd
love
to
see
it
well
soon,
but
there's
no
so
I'll
go
ahead
and
close
this
out
thanks
as
always
for
coming
participating.
Everyone,
and
our
next
meeting
will
be.
Oh
goodness,
what's
the
date
on
that
in
two
weeks,
it's
not
next
week
for
the
next
week
take
care.
Everyone.