►
From YouTube: SIG Network Gateway API meeting for 20221205
Description
SIG Network Gateway API meeting for 20221205
A
A
Hi
everybody
Welcome
to
today's
episode
of
Gateway
API.
Remember
that
this
meeting
is
governed
by
the
kubernetes
code
of
conduct,
which
basically
boils
down
to
be
nice
to
one
another.
B
A
A
But
if
you
want
to
just
say
hi
and
like
why
you're
here
and
what
you're
trying
to
get
out
of
it
and
also
for
anybody
who's
in
here
who
hasn't
put
something
on
the
agenda
but
would
like
to
it's
kind
of
a
full
agenda,
but
do
feel
free
to
put
your
item
on
the
agenda
if
we
have
to
bump
it,
we
have
to
bump
it
but
feel
free
to
add
that
in
all
right,
let's
go
ahead
and
look
at
the
agenda.
Then.
A
C
Okay
yep,
so,
let's
see
we
did
discuss
this
in
in
in
slack
a
little
bit
so
I
probably
don't
need
to
spend
too
much
time
on
it
in
the
call
today,
but
I'm
doing
conformance
tests
for
TLS
route
pass
through
I
just
went
through
the
code
and
and
came
up
with
a
list
of
28
performance
tests,
and
it
turns
out
that
that
what
I'm
really
testing
there
is,
you
know
just
API
validation,
stuff,
so
I'll
need
to
whittle
down
that
list.
C
So
the
first
question
is
answered:
do
we
need
to
all
28
cases?
No
and
I'll
just
take
a
second
look
at
them
and,
let's
see
yeah
one
of
the
questions
I
had
was:
can
it
can
the
Gateway
listener
protocol
be
https
instead
of
TLS
for
TLS
row,
I?
Think
I
tried
it
with
https
and
it
didn't
work
for
me.
Didn't
work
until
I
made
it
TLs,
but
it
looked
to
me
like
the
specs
says
otherwise.
D
That
that
field
is
completely
underspected
at
the
moment.
I
would
say
the
that
it's
sorry
yeah
that
right
now,
it's
kind
of
those
are
suggestions
for
the
implementation
rather
than
a
properly
spec
field.
So
it's
going
to
be
very
implementation.
Specific,
yes,
I
100
agree.
We
should
fix
that,
but
like
for
now,
I
think
that
yeah
so
I
think
that
for
now
it's
probably
fine
to
just
to
just
be
say
something
like
it's
allowed
in
the
spec.
D
So
like
we
won't,
you
know,
stop
you
from
working,
like
necessarily
but
I,
think
it's
probably
also.
We
could
probably
just
say
we.
We
suggest
that
you
should
just
set
it
to
TLS
for
TLS
route
or
like
recommend,
maybe
or
something
like
that
for
now
and
just
assume
in
the
conformance
test
that
it's
tier
list
for
TLS
route
and
then
update
this
back
later.
Once
we've
got
the
performance
test
to
back
it.
C
D
C
C
Just
as
long
as
I'm
not
missing
something
that
was
a
you
know,
tribal
knowledge
or
something
yeah,
so
the
third
I
guess
is
yeah.
Do
we
need
tests
for
terminate
as
well
as
pass
through
TLS
mode
in
dis
Suite?
Or
can
we
address
it
in
a
separate
compliance?
Suite.
D
I
mean
I,
don't
really
understand
the
use
case
for
terminating
the
case
of
TLS
route
because,
like
you
know,
the
whole
point
of
TLS
route
is
that
you're
using
the
Sni
and
stuff?
That's
in
the
TLs
negotiation,
not
actually
unwrapping
it
like
you,
shouldn't
actually
need
to
unwrap
the
packets,
and
in
fact
I
would
go
so
far
to
say
is
unwrapping
the
packets
of
weird.
D
So
that's
why
I
would
say
no,
don't.
Let's
not
do,
terminate
things
for
now
and
wait
and
see
if
anyone
actually
needs
that
use
case.
Sorry
about
the
place
yeah.
C
D
Yeah
yeah
and
so
I
I,
think
Mike
put
in
a
in
the
chat
that
yeah
pass
through
is
also
another
Relic
like
TLS
mode.
That's
like
kind
of
weird.
It's
a
bit
duplicative,
some
of
some
of
the
stuff
around
TLS
mode
and
like
pass
through
it,
terminate
and
stuff
like
that
is
like
is
kind
of
from
before.
D
In
the
API
we
had
the
really
strong
distinction
between
HTTP
route
and
TLS
route,
and
so
like
we
you
it
predates
that
a
bit
and
so
like
we're
kind
of
stuck
with
it
now,
but
I
think
that
we
can
get
our
way
out
of
this
situation
by
by
either
being
very
specific
about
what
like
over,
specifying,
rather
than
under,
specifying
and
being
very
specific
about
yeah
about
what
TLS
modes
are
valid
with
what
route
pipes
and
then
the
same
for
the
you
know,
and
then
that
way
we,
you
know
we
say
yeah
and
the
same
for
the
protocol
field.
D
You
know
like
TLS
router
is
only
available.
Tls
end
of
story
pass
through
is
only
available
to
your
lists.
You
can't
do
terminate
with
TLS
route
Lewin
asks.
Is
it
true?
You
can
only
specify
certificates
into
a
less
route,
so
no
so
TLS
route
is
intended
for
when
you're
passing
through
the
TLs
stream
to
a
back-end
pod
that
has
its
own
certificates
so
supplying
certificates
in
the
Gateway
or
in
the
listener.
There
is
kind
of
weird
Rob.
E
Yeah
I
think
I
think
there's
lots
of
understandable
confusion
here,
because
we
did,
for
a
short
time,
have
certificate
certificate
routes,
certificate,
refs
in
routes,
and
so
there
was
a
time
and
all
you
know,
Alpha
One
of
the
API,
where
you
could
specify
a
certificate
route
and
attach
it
to
a
route,
a
certificate
wrap
and
attach
it
to
a
route
I'll
get
there.
E
Eventually,
we
removed
that
and
tried
to
provide
some
guidance
on
how
you
could
do
that
with
some
kind
of
automation,
where
you
could
tie
a
certificate
to
a
route
via
some
kind
of
controller
right.
That
would
say:
okay,
this
this
certificate
belongs
to
this
Gateway,
so
I'm
going
to
attach
it
up
to
this
Gateway,
because
that's
effectively
what
was
happening.
Anyways
TLs,
are
out
I,
think
kind
of
like
what
Nick
was
already
saying
was
just
it's
a
way
to
route
based
on
Sni
that
that's
it
it's
it.
E
There's
no
special
capabilities,
Beyond,
just
what
it's
sprouting
on,
but
I
I,
get
that
that's
confusing
and
any
any
help
with
our
docs
on
that
I
know.
Our
TLS
related
docs
are
very
confusing
right
now.
So
if
anybody
has
some
cycles
and
wants
to
help
make
them
less
confusing,
that
would
be
amazing.
D
D
I
was
just
about
to
say
sorry
if
anyone
does
want
to
work
on
that
feel
free
to
hit
up
me
or
Rob.
On
slack
to
sort
of
we
can
have
a
chat
about
the
tribal
knowledge
required
there
to
sort
of
give
you
the
background
and
fill
in
to
sort
of
understand
why
things
are
the
way
they
are,
and
so
you
can
explain
to
people.
This
is
weird
because
of
History.
D
You
know
here's
what
we're
doing
to
work
around.
It
basically
is
kind
of
what
I
think
we
need
to
do
there.
A
D
Yes,
I
would
say:
that's
a
plus
one
for
me.
I
think
that
having
TLS
mode
terminate
like
I
mean
we
could
even
just
to
be
honest.
The
easiest
thing
to
do
is
probably
just
to
say:
TLS
mode
is,
you
know,
is
deprecated,
you
know
and
has
no
effect,
like
that's
probably
it's
difficult
to
remove
field
like
that
from
the
API,
because
it's
technically
a
breaking
change
and
thus
needs
an
API
rev,
but
we
can
just
I.
D
A
I
think
I
mean
it
seems
as
simple
as
we
don't
know
anybody
actually
needing
it.
We
don't
understand
the
use
case
like
why
somebody
would
need
that
in
TLS
route,
so
like
bring
it
back
in
scope.
If
somebody
comes
around
is
like
yeah,
we
definitely
need
this.
Here's
our
implementation.
We
need
to
do
this,
but
until
then,
why
have
it?
Why.
D
Right
I
think
I,
think
TLS
mode
terminate
with
a
TCP
route
is
probably
okay
but
like
yeah
for
TLS
route.
No,
but
yeah
again.
That
feels
like
a
thing
that
we
should
be
more
explicit
about
sorry,
yeah.
A
C
C
E
E
Yeah
so
I
I
think
that
is
still
consistent
with
what
we're
doing
with
HTTP
route.
Maybe
a
misunderstanding:
the
question
so.
C
Let
me
let
me
put
it
in
context:
I'm
I'm,
creating
I
I'm
at
a
point
in
the
code
where
I'm,
adding
certificates
to
just
test
a
normative
case
and
I
I
realize
I've
only
done
it
for
one
host
name,
I've
only
added
one
certificate,
but
then
I
realized
that
host
names
can
be
multiple
in
this
case.
So
do
I
I
need
to
iterate
over
host
names
and
add
additional
certificates,
and
is
that
going
to
be
something
that
would
work
or
does
it
seem
weird
or
or
normal.
D
The
way
I
expected
that
to
work
is
that
the
inclusion
of
a
host
name
in
The,
Host
names
field
in
any
type
of
Route
is
not
a
must
match
all
host
names,
hostname
and
then
the
logic
that
Rob
was
talking
about
is
that
you
know
it
also
is
there's
like
a
supersetting
Arrangement,
where,
if
you
have
a
hostname
at
The
Listener
and
a
host
name
in
a
route,
then
there's
a
binding
that
needs
to
happen
between
them
and
that
the
the
they
either
need
to
be
exact
matches
or
the
or
the
listener
needs
to
be.
D
Oh
sorry,
the
the
route
needs
to
be
like
a
subdomain,
that's
covered
by
a
wild
card
on
the
listener.
Okay,
so
yeah,
but
so
I
think
the
in
terms
of
like
TLS
route,
the.
D
If
the
you
know,
if
you've
got
like
three
host
names
in
there,
then
that
means
that
as
long
as
the
request
matches
like
any
one
of
those
it's
up
to
the
T,
it's
up
to
the
TLs
certificate
to
be
like.
Does
it
like?
Does
the
certificate
handshake
complete
right
like
when
it
I,
don't
think
we
want
to
be
in
the
business
of
having
to
unwrap
certificates
like
implementations
having
to
unwrap
certificates,
to
say
it
does
this?
Does
the
certificate
you've
given
validate?
D
D
The
TLs,
the
field,
the
field,
the
host
names
field,
I,
think,
is
yep
yeah.
C
A
D
Thank
you.
Thank
you
that
that
issue
is
really
great
I,
to
be
honest,
like
if
you
ever
feel
like
it
like
that'd,
be
awesome.
If
we
got
some
an
issue
like
that
for
everything,
but
I
mean
at
least
then
we
can
be
like
this
is
ticked
off
by
you
know:
validation,
validation,
validation,
validation.
This
needs
a
convolence
test
like
if
anyone
else
wants
to
do
a
really
good
exercise
to
to
really
get
to
know
a
particular
out
type
really.
D
Well,
then
I'm
doing
something
like
Candice
did
where
you
go
through,
like
all
of
the
possible
error,
States
and
stuff
like
that
is
a
really
good
way
to
really
like
grock
how
our
artworks,
yeah
so
I
was
top
work
kind
of
really
good.
A
Yeah,
thank
you.
We
appreciate
it
all
right.
We
got
a
couple
good
actions
out
of
that
and
we
got
that
other
issue
for
kind
of
General
reform
and
thank
you
for
implementing
canvas,
I'm
sure
it'll
help
to
kind
of
head
this
thing
in
the
right
direction
and
mature
it
all
right.
So,
moving
on
to
the
upcoming
meeting
schedule,
I
think
Rob
is
suggesting
these
two
are
canceled
and
wants
to
know
about
this.
One.
E
Yeah,
that's
that's
exactly
it.
I
know
for
myself
personally,
I
will
not
be
around
on
December
26
or
January,
2nd
I.
Imagine
that's
likely
true
for
many
or
most
people
on
this
call.
If
anybody
as
always,
if
anybody
wants
to
meet
more
than
welcome
to
but
I
think
those
are
safe
to
cancel
the
December,
19
I
will
be
around
I
just
wanted
to
put
a
feeler
out
to
see
if
anybody
else
would
be
around.
If
we
had
a
call.
E
Cool
all
right
that
that
simplifies
that
so
we'll
keep
on
going
with
December,
19
and
plan
on
canceling,
26th
and
second.
D
I
would
actually
suggest,
because,
hopefully
we
should
have
had
you
know
we
should
have
060
out
by
then,
and
you
know
we
should
be
we're
in
the
sort
of
a
wind
down
period
where
there's
not
going
to
be
as
much
stuff
happening.
I'd
actually
suggest.
Let's
try
for
another
agenda,
light
meeting
where
people
can
bring
questions
and
stuff
like
that.
D
I
thought
that
was
that
was
really
useful
and
it
was
a
really
great
chance
for
us
to
just
have
a
bit
of
a
like
more
office,
hoursy
kind
of
thing,
I
think
that
would
be
really
nice,
especially.
You
know,
we've
got
lots
of
people
well
lots
of
new
people
who
probably
have
tons
of
questions
and
I
think
that
it
would
be
good
to
be
able
to.
You
know,
drop
the
tribal
knowledge
as
we
need
and
try
and
make
it
less
tribal.
E
Yeah
I
think
that's
a
great
idea.
It's
not
worth
trying
to
start
a
a
big
new
thing
on
the
19th.
That's
for
sure,
so,
just
open,
open
Agenda
is
a
great
idea
so
and
thanks
thanks
again
for
for
running
that
last
time,
yeah
no.
A
This
will
be
a
real,
quick
update
of
bleached,
which,
for
the
uninitiated,
is
a
a
layer,
4
load,
balancer
built
with
Gateway,
API
and
ebpf
and
rust
for
the
data
plane
that
we
are
using
to
build
like
a
basically
a
reference
implementation
of
Gateway
API
that
will
be
used
for
conformance
tests
and
demonstration
and
stuff
like
that.
A
It
is
being
donated.
So
there's
now
a
an
issue
open
to
get
it
donated.
The
discussion
in
the
email
thread
so
far
was
no
problems.
It
is
kind
of
interesting
because
I
think
it
is
the
first
repository
in
kubernetes
six
that
will
be
predominantly
or
heavily
rust,
so
that'll
be
kind
of
neat
and
one
other
thing
that
we
were
trying
to
do.
Andrew's
not
here
but
Andrew
and
I
were
talking
about.
A
We've
had
I
think
you
can
see
from
the
repository
now
that
there's
like
quite
a
few
contributors
and
there's
a
couple
more
that
aren't
even
counted
here
yet
that
are
kind
of
like
hovering
around
the
project
and
interested
in
it.
A
A
So
if
you're
interested
in
such
a
thing,
I
think
we're
going
to
start
posting
those
in
the
Gateway
API
kubernetes
slack
Channel,
and
it
would
just
be
like
it's
not
specifically
for
Blitz,
but
like
that's
what
we
would
kind
of
start
with,
because
we've
been
doing
those
with
like
a
group
of
small
people,
and
we
want
to
make
it
available
to
anybody
who
wants
to
jump
in
so
just
be
on
the
lookout
for
that
and
if
you're
interested
in
general,
please
feel
free
to
ping
me
on
kubernetes,
Slack,
yeah.
H
D
I
think
it's
more
like
I
feel
like
I'm,
letting
everyone
down
because
I'm
reviewing
things
too
slowly,
and
so
you
I
think
that
you
know
there's
really
sort
of
three
of
us
who
are
the
main
reviewers
and
you
know
like
be.
This
is
because
we
have
like,
like
I,
said
the
best
problem.
Like
you
know,
we've
got
lots
of
work
coming
in,
we've
got
lots
of
people
interested
we've
got
people,
you
know
doing
lots
of
great
work
and
I,
don't
know,
I,
don't
know
about
anyone
else,
but
I'm.
D
You
know
I
have
a
day
job
as
well,
and
it
can
be
tricky
to
keep
up
with
all
the
Gateway
API
stuff,
especially
to
give
big
reviews
like
you,
like
the
API
review,
the
attention
they
deserve,
and
so
like
yeah
it'd,
be
really
good.
If
we
could
increase
our
pool
of
reviewers
Rob's
already
talked
before
about
having
a
better
contributor
letter,
and
so
yeah
Rob
and
I
mentioned
I
think
we
talked
briefly
about
you
know.
Maybe
we
need
to
start
talking
about
like
having
our
own
sigs.
D
Essentially,
you
know
like
and
and
of
which
or
working
groups
or
whatever
you
want
to
call
them,
but
like
gamma
would
be
the
first
one
probably
and
then
you
know
start
having
people,
you
know
having
people
get
gain
approval
rights
over
the
docs
or
the
API
or
performance,
or
that
sort
of
thing.
So
you
can
focus
in
on
a
specific
area
and
you
know
be
a
reviewer
for
that.
You
know
I
could
think.
There's
a
couple
of
people.
D
Who've
spent
heaps
of
time
doing
great
work
on
the
conformance
tests
that
probably
know
more
about
the
performance
test
than
I.
Do
that
would
be
far
better
off
reviewing
PRS
for
the
conformance
tests
than
I
am
at
the
moment,
so
yeah
I
think
I
think
the
more
that
we
can
do
that
sort
of
thing,
the
better
and
yeah
but
yeah
as
I
think.
The
last
thing
that
Rob
added
to
that
is
that
you
don't
need
to
have
a
formal
role
to
help
with
the
reviews.
Just
doing
reviews
and
saying
yeah.
D
This
looks
good
to
me
is
really
useful,
even
for
me
even
so
yeah
that
was
that
was
what
I
wanted
to
talk
about
here.
E
Yeah,
just
I'll
I'll
Echo
everything
that
Nick
said
here
I.
You
know
we
are
overloaded,
we
I
apologize
that
we
aren't
getting
to
I,
know
I,
have
some
reviews
I've
been
meaning
to
get
to
for
longer
than
I'd
like
and
my
GitHub
notifications
are
just
out
of
control,
and
so
just
anything
you
know
we
have
a
lot
of
great
people,
helping
us
out
with
Gateway
API
making
contributions.
E
If
you
feel
like
you
are
interested
in,
you
know
climbing
a
contributor
ladder
there
are,
you
know,
I
can't
say
this
for
every
kubernetes,
Sig
or
whatever,
but
I'd
say
in
Gateway
API.
We
have
just
endless
opportunities
to
fill
in
gaps
and
to
you
know,
make
it
to
maintainer.
You
know,
like
there's
a
there's,
a
very
clear
process
that
we
can
develop
here
of
becoming
a
reviewer
becoming
approver.
E
We
have
so
much
and
that
that
doesn't
even
count
the
various
sub-projects
of
us
of
Gateway
API,
which
includes
Ingress
to
Gateway
soon
to
be
bleaks
and
I,
don't
know
what
else,
but
there's
there's
endless
opportunities
to
help
out
and
to
have
a
formal
leadership
role
in
kubernetes
org,
so
yeah,
just
we'll.
We
are
working
on
formally
defining
what
that
looks
like
I.
Don't
think
anything's
going
to
be
too
surprising,
but
please,
if
this
is
something
you're
interested
in
definitely
reach
out
yeah.
D
Yeah
I
guess
the
other
thing
I
just
want
to
reiterate.
There
is
yeah
my
this.
This
was
also
me
saying
sorry,
the
same
thing
that
Rob
did
sorry
for
taking
a
long
time
for
a
lot
of
these
PRS
yeah
and
it's
and
I
think
the
other.
The
other
concoction
here
that
we've
had
is
that
060
has
taken
us
a
lot
longer
than
any
of
us
would
have
liked
to
get
out,
because
you
know,
there's
been,
we've
had
a
whole
bunch
of
you
know.
D
This
has
been
a
classic
case
of
you
know
you
turn
over
a
rock
and
you
find
another
like
three
rocks
underneath
it,
and
so
it's
just
it's
taken
us
a
long
time
to
get
to
o60,
because
we've
been
trying
to
fix,
fix
things
properly
and
set
ourselves
up
for
being
able
to
go
faster
in
the
future.
The
more
people
we
have
that
can
help
the
faster
that
that
sort
of
stuff
will
be
in
the
future
too.
F
One
thing
that's
a
little
confusing
for
me,
and
this
is
probably
particular
to
me.
Keith
and
John
is
that
I
seem
to
be
getting
like
Auto
assigned
PR
reviews
that
are
like
due
to
the
like
gamma,
whatever,
where
I
am
involved,
like
owners
thing
that
I
do
not
have
the
contact
or
understand
to
like
know
it
if
I
should
or
if
it's
sufficient.
F
So
some
anything
we
can
do
to
like
scope.
The
owner's
file
to
like
areas
of
the
code
base
like
a
code
owners
or
something
like
that,
because,
like
I'm
happy
to
help
with
your
reviews
on
performance
tests,
for
example
or
gamma
stuff,
but
there's
a
lot
of
stuff
that
I
get
Auto
assign
to
that
I.
Don't
understand
well
enough
to
feel
confident.
Reviewing.
E
Yeah
I,
I,
agree,
I
and
I
know
why
it
happens
and
it's
you
know
it's
unfortunate,
but
my
understanding
is
because
gamma
leads
are
listed
as
project-wide,
reviewers
and
reviewers
are
the
bias
you
know
biased
to
be
assigned
first
as
a
reviewer,
and
then
you
know
it
goes
to
approver.
Next,
you
get
a
lot
Auto
assigned
to
you,
which
is
not
efficient.
For
you
know.
Whatever.
F
A
Makes
sense
right,
I've
been
kind
of
thinking
personally,
that
it
might
make
some
sense
to
have
a
Gateway
Dash
API
gamma
repository
mostly
for
gaps
and
then,
like
things,
can
come
back
to
the
main
API
as
like
PRS,
it's
just
a
thought
that
I've
been
having
because
it'll
help
to
kind
of
isolate
the
gamma
stuff.
Quite
a
bit.
Let
people
focus
on
gamma.
Let
people
that
want
specifically
to
like
contribute
to
gamma
contribute
to
gamma.
E
A
Normal
code
owners,
you
can
make
it
so
that
certain
people
have
just
like
basically
just
responsibility
for
that
directory.
Yeah.
E
And
there
is
one
other
thing
that
I've
seen
in
Upstream
kubernetes,
where
there
have
been
some
Bots
that
will
look
for
keywords
in
a
PR
and
label
appropriately
and
then
determine
reviewers
based
on
those,
but
as
a
first
step,
just
sensible
directories.
That's
that's
very
easy
to
do
that.
That
seems
like
a
good
starting
point.
So
we're
not
just
assigning
a
bunch
of
PRS
to
people
that
it,
you
know,
doesn't
feel
like
the
right
fit.
E
D
Oh
Nate,
yeah
I,
didn't
know
about
that
Candice
also
asking
chat.
Is
there
a
way
to
get
a
prioritized
list
of
waiting
reviews
yeah
right
now?
No
I
think
that
probably
that's
going
to
need
human
intervention
for
a
while
to
sort
of
add
priority
labels
to
the
two
reviews,
but
I
think
that
that
feels
like
something
that,
where
you
rob
Shane
and
I
can
work
on
doing
that
for
things
that
are
higher
priority.
E
Yeah
I
think
yeah
I
think
roughly.
What
we've
done
so
far
is
anything
that
is
blocking.
060
Milestone
gets
in
that
Milestone,
and
so
that's
like.
If
anyone
has
Cycles
work
on
anything
in
that
Milestone,
then
we
have
an
061
Milestone,
which
is
you
know,
coming
up
as
soon
as
we
release
and
then
an
070
which
is
eventually
so
I
feel
like
that's,
basically
taking
the
place
of
priorities.
It's.
D
E
C
D
D
Thing
yeah
yeah
I
mean
we
should
do
it
anyway,
but
but
yeah
I
think
that
it'll
make
it
easier.
If
you
know,
if
people
can
say
hey
priority,
I
think
let's
have,
let's
I,
think
let's
take
a
while
to
consider
the
priority
levels
thing,
but
I
think
for
now.
The
the
sort
of
action
item
list
for
anybody
who
wants
to
help
with
reviews
is
look
at
the
Milestones
for
now.
D
A
Yeah,
the
two
that
can
complement
them
each
other.
You
can
definitely
have
like
priority
labels
and
Milestones,
where
they
complement
each
other.
So
the
Milestone
is
like
we're
saying
we're
only
working
on
this
Milestone,
but
there's
High
priorities,
but
the
high
priorities
and
the
other
Milestones
don't
interact
with
those
until
that
Milestone
is
basically
an
in
cycle.
So
I
don't
know
if
we
want
to
do
things
that
way,
but
it
could
work
all
right.
So
I
put
that
as
a
consideration
for
next
time.
Just
make
sure
we
remember
to
consider
priority
labels.
A
This
could
be
helpful
for
people.
It
sounds
like
I
missed
my
lost
my
place
here.
Oh
nope
I
lost
my
place
again
here.
We.
A
Yeah,
that's
that's!
Okay!
So
if
everybody's
on
board,
with
that
I
can
bring
up
at
the
gamma
meeting
tomorrow,
if
they
have
any
problem
with
that
and
then
let
me
just
go
with
that,
does
that
sound
good?
We
just
talk
to
them
and
see
like
before
we
just
executively.
Do
it
just
say:
hey
we're
thinking
we'll
do
this
sound
good.
D
Works
I
think
we've
got
Mike
and
John
here.
So
that's
two
in.
A
D
E
Yeah
yeah
I
just
want
to
do
this.
It
sounds
like
it
so
yeah.
Let's,
let's
just
go
forward
with
it,
you
can
assign
that
one
to
me
I,
don't
mind
taking
it.
Well,
though,
if
you're
doing
it,
I'm
not
gonna
get
in
the
way.
A
A
A
So
all
right,
zv060
update,
oh
I'm.
Sorry
did
anybody
have
anything
else
to
say
on
this
topic
before
we
move
on,
we
have
one
action
item
which
is
specifically
meant
to
help
it
it's
kind
of
focused
on
gamma,
but
should
take
a
a
chip
out
of
it
and
then
we'll
continue
to
follow
up
on
ways
to
make
this
better
foreign.
E
Right
so
I
know,
many
of
you
are
probably
look
looking
for
a
final
vl60
thanks
to
Nick
for
releasing
rc1
last
week.
Hopefully
some
of
you
have
had
a
chance
to
try
it
out,
and
hopefully
it's
mostly
worked,
but
please
please,
please
take
some
time
to
run
conformance
tests.
Anything
else
you
you
can
with
the
release
candidate.
That's
what
it's
there
for.
We
really
want
to
get
as
much
feedback
as
possible
in
the
next
few
days.
E
Generally,
the
way
things
work
is,
you
know
we're
trying
to
run
through
a
whole
host
of
feedback
from
Tim
and
Cal
as
Cygnet
API
reviewers,
once
that's
complete
I
will
send
out
a
rc2
usually
and
then
usually
a
day
or
two
after
rc2.
We
hit
the
final
release.
Again,
we
are
really
kind
of
relying
on
implementations
to
take
this
opportunity
run
conformance
tests
test
test
it
out,
ensure
that
we
haven't
done
something
especially
stupid
here.
E
Please
please,
let
us
know
before
we
hit
the
release
on
vo60,
which
really
gives
you
this
week
at
most
to
to.
Let
us
know,
ideally,
the
next
few
days,
yeah
and
so
I
linked
over
to
the
actual
PR.
That's
getting
all
the
feedback
from
Cal
and
Tim
there's
a
lot
of
comments.
Shane
took
the
first
PR
to
get
a
bunch
of
fixes
in
I've
got
another
PR
that
should
merge
shortly.
E
Richard
has
another
PR
for
grpc
related
fixes,
lots
and
lots
of
changes
going
on
here,
but
I'd
still
say
we're
only
a
little
over
halfway
through
this
PR,
hopefully
I'm
pessimistic
there,
but
I.
You
know
there's
a
lot
of
comments
that
I
haven't
had
a
chance
to
get
to
yet
so
my
request
here
is
I
know
many
of
many
of
the
people
on
The
Scholar
are
interested
in
getting
060
out
as
quickly
as
possible.
This
is
the
thing
that's
in
between
us
and
that
release.
E
So
if
you
are
able,
if
you
can
help
us
out
by
running
through
some
of
these
comments,
if
you
see
some
that
say,
Hey
I
can
I
can
take
that
I
can
fix
that
just
comment
and
say:
hey
I'm,
taking
this
and
it's
yours,
you
know
the
the
more
people
we
have
working
on
this,
the
faster
we
can
get
a
release
out
and
you
know
I
I-
think
we're
all
very
invested
in
getting
a
release
out
in
the
next
week
or
so
yeah.
A
E
Do
yeah,
and
so
I'll
just
highlight
a
couple
things
that
I
think
are
worth
further
discussion
here.
If
you
go
back
to
the
agenda
just
briefly,
Shane
yeah.
A
I
was
oh
sorry,
I
was
looking
for
was
actually
related
to
this.
I
was
looking
for.
Github
can
tell
you
when
people
are
using
you
as
a
library.
I
was
wondering
if
that
could
help
us
I,
don't
think
we
have
that
turned
on
right
now,
but
so
the
is
anybody
using
this
package.
You
tell
translator
thing.
F
We
were
interested
in
using
it,
but
have
not
yet
what's
the
context
is
it
that
it
needs
to
be
tested
or
it's
going
away?
There's
some
potential.
E
Know
that
that's
that's
it
basically
there
the
comments
from
Tim
and
Cal
are
basically,
these
seem
really
simple.
Is
anybody
actually
using
them
roughly
and
and
if
they
are,
can
we
can
we
use
generics
instead
of
you
know,
rewriting
this
a
million
times
and
so
I
I
feel
like
this.
Everything
we
have
in
translator
was
potentially
more
useful
earlier,
but
I
don't
know
that
it
ever
took
on
and.
E
E
E
D
I'm
pretty
sure
the
Contour
is
using
it
and
they
so
Contour
contributed
originally
and
so
I'm,
pretty
sure
Contour
of
using
it
I'm,
not
100,
Envoy
Gateway
may
be
using
it
as
well.
Oh,
it's
been
a
little
while,
since
I
looked
at
that
part
of
the
code,
so
yeah
I
think
those
are
probably
the
people
to
check
with.
D
I
wasn't
going
to
drop
you
in
that
Dave
because
I
like
I
know,
I
haven't
looked
at
that
code
for
a
long
time
and
you
know
I
yeah.
So
it's.
G
A
Yeah
probably
want
to
do
like
a
follow-up
on
this
one,
because
this
is
kind
of
important
to
like
get
done
as
soon
as
possible.
So
I
think
there's
an
action
item
here
to
say
somebody
just
needs
to
like
check
in
with
these
groups:
Dave
you're
on
kubernetes,
Slack,
yeah,
okay,.
D
Yeah
I
think
I
think
in
the
Gateway
API
Channel
saying
hey
we
want
to.
We
need
to
know
who's
using
this,
because
we
need
to
change
it
around
a
little
bit.
Can
you
yeah
reply
here?
If
you
are.
E
Yeah
I
mean
it's,
it's
basically
do
we
take
the
time
to
clean
it
up
and
dramatically,
simplify
it
or
do
we
drop
it
entirely
since
it's
never
been
released
to
this
point,
those
are
basically
the
options
we
have.
C
A
F
D
Can
do
that?
It's
fine
thanks,
Nick,
oh
and
and
yeah
Dave
yeah
feel
free
to
hit
me
up
with
anything
that
anything
as
well.
Yeah!
That's
fine!
Just
leave
it
on
me.
A
E
So
this
is
one
that
I
just
wanted
to
highlight
because
Cal
spent
a
bunch
of
time
going
through
our
validating
Web
book
cleanup,
and
this
is
one
that
does
not
none
of
it.
None
of
his
comments
feel
particular.
You
know
some
of
the
comments
in
this
PR
take
some
thought
and
you
know
I'm
not
sure.
Why
did
we
do
this
I'm,
not
sure
a
lot
of
these
comments
that
I
highlighted
are
just.
We
could
clean
this
code
up
in
our
valid.
E
So
this
is
the
the
reason
I'm
highlighting
this
is
it's
the
kind
of
thing
that
anybody
with
really
no
background
on
our
API
can
just
jump
in
if
you've
written
go
code
before
you
can
jump
in
and
try
and
address
some
of
these
comments.
So,
if
you're
looking
for
a
place
where
you
can
help
out
and
jump
in,
that's
where
I'd
recommend
starting
there's,
you
know
just
again
comment
on
any
one
of
those
and
say
you
want
to
take
it
or
a
set
of
them
and
they'll
be
for
you.
But
again,
please.
A
Yeah
and
do
what
Rob
was
saying
before,
please
do
put
your
like
add
to
the
comments.
So
we
don't
get
two
people
working
on
the
same
thing
say:
I'm
gonna,
take
this
yeah.
E
Cool,
that's
that's
all
I've
got
any
help
is
always
appreciated
on
this,
but
yeah
thanks.
A
Roger
that
all
right,
we
have
15
minutes
left
14
minutes
left
Dave
questions
about
policy
attachment,
okay,.
H
Yeah
I
kind
of
posted
for
Canada,
we
were
our
ambitionists
use
a
Gateway
API,
so
we
don't
even
have
to
touch
any
implementation,
specific
resources,
but
then,
when
I
saw
retracting
like
retry
policy
as
one
thing
and
kind
of
saw
got
lumped
into
like
oh
well,
you
know
what
we
can't
tackle
this
problem
now.
H
H
That's
fine
for
end
users
or
operators,
but
like
as
a
platform,
that's
trying
to
like
create
these
things.
Programmatically,
it's
like
a
huge
pain
because
then
it's
sort
of
like
well.
H
We
we're
trying
to
get
away
from
programming
implementation,
specific
resources,
so
one
thing
I
was
kind
of
wondering
is
like:
does
it
make
sense?
Well,
this
is
sort
of
solutioning.
Does
it
make
sense
to
have
sort
of,
like
generic
shapes
for
certain
policies
that
we
could
create?
A
Yeah
so
some
degree,
that
is
what
we
kind
of
have
do
you
so
have
you
just
to
make
sure
you've
seen
like
the
bits
where
we
try
to
give
like
a
at
least
a
loose
outline
of
how
the
attachment
part
of
it
should
work
right.
So
you're
asking
for
like
something
a
little
deeper
than
that.
Is
that
what
we're
getting
at.
H
I
yeah,
it
still
feels
like
you
need
to
create
some
non-gateway
resource
in
order
to
affect
like,
for
example,
retries
or
timeouts
and
stuff
like
that.
Yeah.
A
So
I
think
today
we're
kind
of
making
that
into
something
that
is
implementation
specific.
But
it's
not
out
of
the
question
for
that.
So,
like
the
way
the
API
Works
in
general
I
would
maybe
fully
familiar
with,
but
just
to
kind
of
go
over
it
is
we
have
different
levels
of
conformance
and
what
policy
ends
up
being
is
like
completely
implementation
specific
stuff.
A
D
You
Nick
yeah
yeah,
so
there's
some
background
here
and
that's
one
of
the
reasons
that
we
have
policy
attachment
is
that
I
at
one
stage,
Rob
and
I
sort
of
sat
down
and
tried
to
figure
out
how
we
could
write
a
struct
would
describe
timeout
policy
across
any
implementation.
It
is
impossible.
D
It
is
not
possible
to
reconcile
timeout
policy
across
different
data
plane
implementations
because
they
all
slice
so
say.
You've
got
like
total
client
time
out
here,
right
like
or
something
like
that,
they
all
slice
the
timeout
into
different
chunks
right.
D
So
what
the
reason?
One
of
the
reasons
that
we
are
in
the
situation
where
we're
like.
Oh,
this
is
all
implementation
specific
is
because
we
haven't
been
able
to
find
enough
commonality
to
be
able
to
make
something
that
that
works
across
enough
implementations
to
make
it
work.
Probably
retry
policy
is
more
tractable,
I.
Think
because
retry
policy
is
going
to
be
a
bit
more
described
like
more
common
between
implementations.
D
Timeout
policy
is
literally
the
example
I
use,
because
it's
because
it's
one
of
those
ones
that
seems
like
it
should
be
a
completely
solvable
problem,
but
it
turns
out
not
to
be,
and
so
I
think.
Probably
the
best
case
scenario
we
can
end
up
with
for
timeout
policy,
for
example,
is
that
there's
like
a
data
plane,
data,
plane,
specific
versions
right,
like
so
an
Envoy
timeout
policy
and
an
nginx
timeout
policy?
D
And
you
know
something
like
that
that,
because
of
implementation
details,
the
intent,
my
intent
here
with
policy
attachment
is
that
what
I
would
like
to
see
is
people
make
policy
objects
that
are
implementation
specific
and
then
ask
try
to
take
a
couple
of
them
once
we
have
a
couple
of
implementations,
do
them
and
try
to
find
what's
common
between
them
and
then
build
a
gateway
gateway,
API
extended
performance
object,
that's
that
is,
that
is
sort
of
the
The
Hope
and
the
dream
that
that
we
can
take
things
from
implementation
specific
to
Extended,
and
then,
if
everybody
supports
it
to
core,
but
like
the
you,
the
problem
with
a
lot
of
policy
attachment
stuff
is
that
it's
very
imp
like
it
is
very
implementation.
A
That
was
exactly
what
I
was
trying
to
get
at
before,
so
somebody
sorry
go
ahead.
E
Yeah
I
I
was
just
gonna,
follow
up
and
and
Nick
actually
ended
up
saying
the
same
thing
I
was
going
to
say
at
the
end,
but
yeah
I
think
there's
a
lot
of
room
here
for
data
plane,
specific
policies,
I
talked
at
the
last
kubecon
I
talked
with
a
few
different
people
that
were
interested
in
generic
Envoy
branded
set
of
policies
that
worked
for
all
Envoy
implementations
of
the
API
I
think
that's
yeah,
approximately
80
percent
of
implementations
seem
to
be
Envoy
based
right
now,
so
that
would
cover
a
pretty
large
chunk
would
be
interested
to
see
where
that
goes.
E
But
again
you
know,
unfortunately,
because
different
underlying
data
planes
have
different
configuration.
We
can't
just
you
know,
Force
everyone
to
be
able
to
communicate
the
same
thing
and
and
next
example
of
timeout
sad.
They
are
surprisingly
different,
depending
on
whether
you're
talking
to
nginx
or
AJ,
proxy
or
Envoy
or
whatever
else,
and
so
a
truly
generic
thing.
There
was
sadly
impossible
and
I
imagine
there
are
going
to
be
other
things
that
also
as
much
as
which
we
want
to
get
as
much
as
we
can
in
the
core
API.
I
A
Need
to
be
part
of
the
change
that
you
want
to
see
in
the
API,
like
you
getting
more
involved
in
you're,
welcome
to
and
we'll
be
like
happy
to
help
you
like
get
more
involved
in
being
a
voice
for
this
and
for
the
specific
things
that
you
want,
because
we're
going
to
need
help
to
start
moving
those
things
into
extended.
We've
already
covered
a
lot
of
ground
in
this
API
over
the
last
few
years
and
we're
starting
to
get
to
these
edges
where
it's
going
to
take.
A
You
know,
individuals
who
are
strongly
motivated
to
kind
of
tease
these
things
out,
especially
if
we
want
to
get
more
things
like
policy
attachment
things
that
we've
traditionally
thought
of
as
implementation
specific
and
start
seeing
if
we
can
at
least
get
them
into
like,
for
instance,
that
group
of
of
implementations
that
use
Envoy
and
so
forth.
So
I.
G
I
do
hopefully
you
can
hear
me
so
one
interesting
thing
is,
as
a
I
see
you
as
like
a
user
is
to
understand
what
your
requirements
are,
because
one
of
the
difficulties
we
faced
is
that
we
could
come
up
with
specific,
for
example,
timeout
policy
for
specific
implementations,
but
it
was
unclear
what
way
to
abstract
it
so
that
it
would
be
portable,
so
I
think
it
would
be
really
good
to
hear
from
your
side
what
you
see
as
a
usable
subset
that
could
potentially
be
generic,
because
that
was
something
like
as
the
implementers
right.
G
H
D
D
I
mean
I
haven't
looked
into
it
like
I
did
with
like
Rob
and
I
did
with
timeout
yeah,
so
I
think
we
could
definitely
I
think
it's
definitely
worth
spending
some
time
to
have
a
look
on
that,
but
I
should
I
think
it's
really
important
for
me
to
be
clear
that
overall,
my
aim,
what
I
would
like
to
see
at
some
the
dream
is
that
there
are
standard
policies
that
are
part
of
a
Gateway
API
right
like
for
the
things
that
we
can
do,
that
for
absolutely
I
want
to
see
like
a
retry
policy
or
something
that
is
a
member
of
the
Gateway
API
Group.
D
Maybe
it's
only
extended
but
right
that
that
we
take
the
things
that
that
we
can
make
generic
enough
and
bring
them
into
the
gateway
API
Group,
just
just
like
you
were
saying
Dave
so
like
yeah,
that's
I
I
just
want
to
be
super
clear
that,
yes,
that
is
definitely
like
a
personal
goal.
For
me.
You
know
in
terms
of
the
policy
attachment
stuff,
yeah,
sorry.
H
I
think
the
other
thing
that
might
be
interesting
to
think
about
is
because
I've
seen
the
the
slides
from
I
think
like
two
kubecons
ago,
when
you're
talking
about
like
the
Gateway
conformance
as
in
being
like
a
sphere
with
smaller
spheres
and
yeah
and
I
wonder
if
the
simpler
thing
for
some
of
these
policies
is
more
not
necessarily
like
it
comes
to
the
core,
but
it
could
be
an
opt-in.
H
So
the
idea
of
maybe
this
just
belongs
and
extended
then,
but
like
there
is
a
type
of
policy
that
applies
then
implementations
can
kind
of.
This
is
what
I
mean
by
having
the
same
shape,
to
begin
with,
like
maybe
retries,
a
simple
one
to
start
with.
First,
but
I
do
agree
with
you,
knowing
all
the
client
side
and
also
server
side
timeouts
that
are
in
the
go
links.
D
So
yeah
so
I
think
retry
does
seem
like
a
more
tractable
one.
That
would
be.
It
would
be
really
good
to
get
to
try
to
have
a
crack
at
and
yeah
I.
D
Think
that
the
the
sort
of
the
definition
in
my
mind
of
extended
is
he
lives
in
the
Gateway
API
like
in
the
repo
and
under
the
API
Group,
and
we
have
conformance
tests
for
the
behavior,
so
those
are
sort
of
the
you
know
if
we
can
have
a
retry
policy
that
is
implementable
across
like
a
majority
of
implementations
and
we
make
it
extended.
That's
100,
fine
with
me.
That's
what
I
would
hope
to
see
extended.
Just
means
is
implementable
by
quite
a
few,
quite
a
few
implementations
and
is
able
to
be
tested.
A
H
A
I
think,
since
we're
running
pretty
low
on
time
and
I
would
like
to
get
to
our
last
agenda
item
or
so
would
how
would
you
feel
Dave
about
an
action
item
for
this?
A
One
being,
would
you
mind
putting
together
a
discussion
on
like
GitHub
discussion,
where
you
kind
of
tease
out
some
of
your
thoughts
on
this,
get
put
in
a
little
more
details
about
some
of
the
things
other
than
just
like
turning
off
retries
that
you'd
like
to
see,
we
can
kind
of
work
from
there
and
see,
if
maybe
some
of
these
things
we
can.
You
know
over
time,
start
to
build
up
into
something
that
would
be
extended.
H
Yeah
I
can
I
can
start
a
good
discussion.
Yeah.
B
I'd
love
to
participate
in
that
because,
like
my
personal
interest
in
being
here,
coming,
I
really
I'm
coming
from
the
end
user
world
before,
where
I'm
at
now-
and
it's
like
I,
want
to
make
sure
that
you
know
like
we
get
feature
complete
at
some
point
with
all
the
things
that
I
would
have
used
as
an
end
user.
So
I'd
love
to
participate
in
that.
A
Sounds
good
and
then,
since
we're
running
low
on
time,.
H
A
We'll
follow
up
on
that
GitHub
discussion
s
rampal!
You
have
questions
about
multi-cluster
support.
I
Yeah,
hey
so
I'm,
not
a
regular
member
of
this
community
and
I
had
looked
at.
It's
not
multi-cluster
functionality.
Several
months
back
and
at
that
time,
Gateway
API
had
been
demoing.
I
Some
multi-cluster
topology
is
using
service
import
as
backend
references
to
routes
and
the
service
import
is
referring
to
the
multi-cluster
services.
Api
I
just
wanted
to
reconnect
on
this
and
I
was
at
a
meeting
Shane
with
you
a
few
days
ago,
and
you
mentioned
to
kind
of
just
bring
it
back
to
the
agenda
of
one
of
these
meetings
to
see
where
things
start
so
I
just
wanted
to
check
on
you
know.
I
I
E
Yeah
this
is
this
is
a
big
interest
area
for
me.
Personally,
I
am
hoping
in
the
next
couple
months
to
spend
some
time
formalizing
and
documenting
what
we
recommend
as
the
intersection
of
Gateway,
API
and
multi-cluster
service.
Api
I
think
those
are
the
easiest
apis
to
answer
that
question
for
I
I
think
we
definitely
want
to
have
a
clear,
well
thought
out
approach
for
those
apis.
I
know
that
you
know
gke.
E
We
we
already
have
a
a
product
based
on
multi-cluster
service,
API
and
Gateway
API
I
know
that
there
are
others
in
progress
by
other
implementations
and
I'd
love
to
just
clearly
document
what
what
that
should
look
like
across
the
across
the
the
environment,
the
ecosystem,
I.
The
mesh
question
is
a
little
bit
more
open-ended
and
we
have
some
gamma
maintainers
on
the
call
here,
but
I
know
we're
also
at
time,
but
I
am
very
interested
in
what
this,
how
Gateway
API
interacts
with
multi-cluster
and
mesh?
E
It's
easier
for
me
to
answer
the
multi-cluster
service,
because
that's
already
a
well-defined
kubernetes
API
but
multi-cluster
and
mesh
is
not
well
defined
in
kubernetes
yet
and
yeah
I'm
I'm
very
interested
too
I.
Don't
think
it's
been
discussed
very
much.
I
So
yeah
I'm
happy
to
help.
You
know
do
my
part
to
work
with
you
guys
to
take
this
forward
and
I
guess
the
summary
of
what
I
think
I'm
hearing
from
you
is
that
both
leveraging
the
MCS
API
for
multi-cluster
backends,
as
well
as
potentially
leveraging
mesh
service
backends
both
are
options
still
on
the
table
and
some
amount
of
further
clarification
would
help.
Yeah.
E
I've
gotta
drop
but
I'll
say
real
quickly.
That
multi-cluster
service
is
much
clearer
to
being
defined
than
anything
else,
but
I
think
there's
broad
interest
in
both,
but
with
that
I've
got
to
run,
but
you
can
keep
on
yeah.
A
Sounds
good,
I
think,
since
we
are
past
time,
we'll
probably
try
to
wrap
up
here,
but
there
is
this
discussion
about
multi-cluster
mesh,
in
particular
I
guess
for
now,
though,
there's
not
really
much
of
an
action
item
for
this
part.
If
you
want
to
be
specifically
involved,
I
would
say
not
not
to
do
this
to
Raw
but,
like
you
know,
Pingus
and
Gateway.
A
Api,
he's
I,
think
the
person
most
interested
in
this
like
Ping
Rob
about
this
in
our
Gateway
API
kubernetes
channel
on
kubernetes
slack
sorry
and
kind
of
keep
the
thread
going
over
the
next
couple
months,
as
this
starts
to
get
teased
out.
A
Yeah,
thank
you.
Okay,
I
think.
That's
all
we
have
time
for
today.
The
last
couple
things
I
think
were
just
some
really
basic
stuff.
So
thank
you.
Everyone
for
coming,
we
will
be
here
on,
go
ahead.