►
From YouTube: SIG Network Gateway API meeting for 20230410
Description
SIG Network Gateway API meeting for 20230410
A
All
right
welcome
everyone
to
the
Gateway
API
meeting
for
April
10th
2023,
thanks
to
everyone
who
showed
up.
As
always,
we
are
looking
to
record
who's
attending
just
so.
We
get
a
better
picture
of
what
meeting
times.
Work
makes
sense.
We
are
trying
to
experiment
with
different
meeting
times
coming
soon,
just
maybe
more
Europe
friendly
meeting
times,
because
we
know
there
are
people
that
are
interested
that
just
can't
make
this
meeting
time.
So
we
if
we
have
an
accurate
record
of
who's
attending
these
different
meetings.
It's
very
helpful
with
that
said.
A
This
is
a
standard
kubernetes
code
of
conduct
meeting.
You
know
that
abides
by
the
code
of
conduct
so
be
nice
to
everyone.
Nothing
too
crazy
here,
but
this
this
meeting
is
open
to
everyone.
Please
feel
like
you're
welcome.
This
agenda
is
open.
It
should
be
in
the
meeting
invite
or
any
other
way
you
got
here.
Someone
is
willing
if
they
can
drop
a
link
in
chat
too.
A
That
might
be
helpful
but,
as
always,
don't
hesitate
to
add
something
to
the
agenda
or
mention
it
in
chat
and
we'll
try
and
get
to
it
in
today's
meeting
with
that,
I
think
I
see
maybe
one
or
two
new
names.
If
anyone
is
interested
feel
free
to
take
this
opportunity
to
introduce
yourself,
we
always
like
to
see
people
who
are
new
to
the
group
who
and
and
what
what
interests
them
in
Gateway
API.
A
All
right,
no
worries
I'll
keep
on
going
okay.
So
the
very
first
thing
on
the
agenda
is
the
0.7
release.
We
are
making
good
progress
towards
this
I
added
a
few
links
to
the
agenda.
I
think
it
was
Shane
went
through
and
cleaned
up
the
Milestones.
So
the
very
last
thing
left
is
this
API
review
PR
for
those
of
you
who
have
not
been
through
a
release
process
with
Gateway
API
before
the
way
that
we
do
releases
is
we
start
with?
A
You
know,
agreement
among
maintainers
that
we're
ready
to
start
the
API
review
process,
and
then
we
reach
out
to
Sig
Network
API
reviewers.
That
right
now
is
Tim,
Hawkins
and
Cal,
and
both
of
them
will
run
through
our
code
review
code
base.
Look
at
changes
specifically.
This
is
looking
at
changes
to
our
API
and
our
validation.
A
We've
got
some
feedback
already
on
this
and
then
once
they're
happy
with
our
the
state
of
our
API.
We
will
go
ahead
and
push
out
a
release
candidate
that
allows
implementations
to
test
out
the
release
and,
if
all
goes
well,
we
should
have
a
final
0.7
release
sometime
soon,
but
I
think
Shane
added
a
very
helpful
approximate
timeline
for
how
we
see
this
working.
This
is
based
on
previous
experience.
This
makes
it
look
like
our
final
release
for
070
may
be
made
two.
A
These
are
very,
very
approximate
timelines,
though
you
know,
everything
in
open
source
is
based
on
volunteers
that
don't
have
any
firm
time
commitments
here,
so
these
are
approximations
based
on
prior
experience
and
that's
it
so
we'll
do
our
best,
but
we
cannot
guarantee
any
of
these
dates
all
right.
Any
any
questions
on
that
before
I
keep
on
going.
A
A
This,
as
I
link
to
is
the
API
review
PR
itself.
This
is
where
we're
getting
feedback
from
Tim
and
Cal.
There
are
a
few
things
in
here
that
will
try
and
translate
into
issues,
but
before
that
happens,
if
you
see
something
that
you
want
to
take
on
and
try
and
help
out
with,
for
example,
this
one
seems
like
an
easy
one.
A
Instead
of
field.forbidden,
we
should
be
using
field.duplicate
if
you're
looking
for
a
way
to
contribute
to
the
project
and
speed
up
the
0.7
release,
taking
on
any
kind
of
any
of
these
little
comments
and
help
in
sending
a
PR
to
get
a
fix
in
would
be
very
helpful,
okay
and
then
very,
very
much
Final
on
the
0.7
release.
Topic
I'll
mention
that
this
is
the
review,
slides,
kind
of
overview
that
we
presented
to
Tim
and
Cal.
A
Just
last
week
it
was
just
a
a
very
high
level
overview
of
what
we
changed
in
the
07.0.
If
you
have
maybe
missed
some
things
or
not
seen
everything,
that's
happened
in
the
past
few
months.
I
think
these
slides
may
be
a
useful
reference
point
very
similar
to
the
changelog
to
understand
the
major
themes
that
are
changing
in
this
release.
A
A
Direct
policy
attachment
is
a
net
New
Concept
for
policy
attachment
thanks
to
Nick,
for
that
one
multi-cluster
services
and
Gateway
API
have
been
kind
of
formalized
into
a
concept
of
how
they
interact
with
each
other,
and
then
Shane
has
really
been
working
on
conformance
profiles,
which
is
going
to
be
really
really
great
set
of
improvements
for
our
conformance
tests.
So
those
are
the
main
high-level
things
that
are
that
are
happening
in
this
release,
but
that
is
just
kind
of
the
high
level
overview
and
there's,
of
course
more
in
it
than
that.
A
Okay,
that's
all
I've
got.
They
did
provide
some
high
level
feedback.
Just
in
the
discussion
itself,
there
were
some
concerns
about
the
policy
attachment
user
experience,
a
suggestion
that
maybe
we
should
work
with
API
Machinery
or
someone
to
create
a
concept
where
a
resource
could
implement
or
inherit
from
another
resource.
So
you
could
say:
hey
this
policy
is
a
type
of
Gateway
policy
or
maybe
introduce
some
kind
of
intermediate
resource
so
that
it's
very
easy
for
users
to
do.
A
Cube
cuddle,
get
Gateway
policy
bindings,
I,
don't
I,
don't
know,
and
you
could
say
okay
this.
This
policy
has
been
applied
to
this
resource
by
this
controller
as
a
rough
example,
so
some
ideas
there
to
try
and
smooth
out
the
ux.
Then
there
were
some
small
kind
of
non-blocking
concerns
about
the
lack
of
precision
in
the
current
MCS
Gap
and
then
I
just
a
suggestion
or
recommendation
to
share
just
an
overall
update
at
the
broader
Sig
Network
meeting
sometime
soon,
yeah
I've
been
talking
a
lot
so
I
know.
A
A
A
D
C
Cool
so
yeah
I
wanted
to
keep
pushing
on
the
session
persistence.
Api
we
had
started
out
with
The
Gap
I
can
link
that
here.
So
we
have
something
preliminary.
We
have
a
gap,
that's
in
the
in
the
in
the
repo
that
is
sort
of
preliminary
we've
got
a
couple
open
items,
but
I
sort
of
just
started
to
write
down
some
I
I.
You
know
I
asked
in
the
channel
like
what's
the
next
step
we
should
take
on
this
Robbie
mentioned,
like
maybe
it'd,
be
good.
C
If
we
wrote
down
configuration,
that's
common
between
a
lot
of
the
implementations
and
and
proxies
and
data
planes,
whatever
we
want
to
call
them
so
I
started
that
in
this
document,
I'll
admit
I'm
kind
of
wandering
a
little
bit
because
I,
you
know
this
is
my
first
sort
of
API
field,
so
I
could
probably
use
a
little
bit
of
direction.
Maybe
help
with
like
what
questions
we
want
to.
C
Sir
I
know
we
have
some
in
the
document
are
in
the
in
the
gift
that
we
want
to
answer,
but
I
was
I,
guess
curious
to
bring
this
up
to
for
maybe
review.
If
you
guys
think
this
should
be
in
a
gap
or
if
you
can
help
me
reduce
the
information
down
in
this
Google
doc,
and
then
we
can
get
it
back
into
a
gap
that
would
be
awesome.
A
C
I
think
there's
there's,
maybe
one
or
two
so
I
need
two
tables.
The
first
table
is
what
I
called
proxies,
but
I
recently
renamed
them
to
data
planes
and
then
the
second
table
right
below
this
is
implementations,
so
I
could
probably
use
some
help
with
if
that
makes
sense,
but
I
kind
of
broke
it
out
into
two
sections,
because
things
are
configured
I
guess.
C
The
main
reason
was
that
implementations
can
sometimes
Miss
configurations
that
that
data
planes
have
and
then
also
I
like
I,
discovered
something
kind
of
interesting
where
Contour
like
got
around
istio's
lack
of
native
support
for
cookie
attributes
and
by
using
Lewis
scripts.
So
it
kind
of
just
helps
I
guess
these
two
tables
help
enumerate
sort
of
the
possibilities
for
configuration.
C
Yeah
I
would
I
would
agree
that
it's
kind
of
the
lowest
hanging
fruit
at
this
point
where
that's
below
I
I
started
on
sort
of
an
analysis
of
cookie.
You
know
what
what
are
some
of
the
common
fields,
what
do
I
think
game
API
should
configure
so
yeah.
Maybe
that's
the
best
thing
to
start
with
here,
since
it
just
seems
like
the
easiest
thing
to
take
on.
E
C
A
Yeah
I
mean
this
is
this
is
a
great
reference.
I
know
what
you
had
done
already
earlier
with
this
Gap
has
already
been
used
as
a
reference
for
future
gaps
and
I
think
this
is
a
a
great
reference
point
again
for
future
gaps
of
just
having
again,
maybe
this
kind
of
high
level.
These
are
major
data,
plane,
implementations,
what
they
support
and
then
also
for
bonus
points,
the
active
implementations
of
the
API
today
and
what
they
support
so
yeah.
A
This
is
this
is
really
great
and
really
helpful
at
present
I'm,
not
seeing
any
reason
you
know,
I
feel
like
this
verbatim
is
probably
useful
to
get
into
the
Gap,
because
the
Gap
is
still
a
provisional
state
and
I
think
from
there
kind
of
the
the
natural
conclusion
here
is
really
what
you
know.
What
is
the
con?
A
The
Common
Ground,
the
this
set
of
configuration
that
most
implementations
are
going
to
be
able
to
support,
and
that
seems
pretty
clearly
to
be
cookie
based
Affinity
at
this
point,
our
session
persistence,
but
we
for
now
just
having
what
you
have
in
the
stock
seems
like
a
very
good
addition
to
the
Gap.
From
my
perspective,.
C
They
group
the
session
persistence
and
what
we've
defined
as
session
Affinity
or
you
know
weak
session
persistence
or
you
know
whatever
you
want
to
call
it,
which
is
more
like
load,
balancing
algorithms
or
you
know,
base
your
Affinity
on
a
source
IP,
so
I
guess
I
was
starting
to
think
about
like
the
API
structure
of
okay.
Well,
maybe
we
could
figure
out
how
to
configure
cookies,
but
does
it
make
sense?
We
should
try
to
answer
in
What
fields.
C
A
A
What
does
this
API
look
like
and
at
that
point,
I
think
we
really
need
to
explore
a
few
alternatives
and
that
that
feels
like
something
that
we
want
to
do
after
this
is
in
like
kind
of
the
the
next
Natural
Evolution
of
this
cup
I
haven't
thought
about
it
enough
to
to
decide
where
you
know
what,
where
we
should
limit
this
scope
to,
but
I
I,
yeah,
yeah
I
think
that's.
That
really
is
the
next
step
here,
costing
you've
got
a
hand
yeah.
C
Yeah,
so
that
that
that's
something
I
can
look
into
I
guess
my.
My
question
is
for
this
next
step,
which
I
guess
I
mean
next
PR
update
and
XPR
am
I
trying
to
answer.
Is
it
a
good
idea
to
try
to
answer
those
questions
yet
or
are
you
thinking
we
should
kind
of
take
what
we
have
here
just
get
it
into
another
PR
and
then
get
that
checked
in
and
then
proceed
with
trying
to
design
an
API.
A
Yeah
I
would
say
the
latter,
because
this
is
a
pretty
big
change
in
addition
to
the
Gap
and
I
think
it's
non-controversial
so
I
would
love
to
see
this
go
in
and
then
I
think
the
API
changes.
If
we
can
limit
that
PR
to
just
API
changes,
it
will
help
make
the
review
feel
a
little
bit
more
manageable
because
we're
not
reviewing
the
whole
Gap
we're
just
reviewing
the
proposed
API
on
top.
A
Okay,
the
the
one
thing
that
I
you
know
just
looking
at
this
a
little
bit
more
closely,
but
one
thing
that
would
be
really
helpful
to
have
is:
if
you
can
approximate
where
this
config
lives.
You
know,
one
of
the
things
with
other
features,
at
least
is
the
granularity
of
config
is
actually
a
pretty
important
detail.
A
You
know
if,
if
some
of
this
config
is
tied
to
a
service
in
one
data
plane,
but
others
have
it
at
a
slightly
higher
level
and
by
service
I
mean
the
equivalent
of
service
in
each
of
these
Concepts.
If,
if
that's
something
that
is
somewhat
straightforward
to
represent-
or
at
least
people
in
deciding
where
this
configuration
lives,.
C
It
just
seems
like
a
very
abstract
thing
to
talk
about,
because
I
guess
when
you
compare
like
Gateway,
APA
I,
guess
my
mindsets,
Gateway
gateways
routes
and
services
and
I,
guess
back-ends
and
then,
when
you
try
to
put
that
on
top
of
some
of
the
existing
implementations
it
it
becomes
kind
of
hard
to
talk
about,
but
yeah
I
think
that's.
That
would
be
an
interesting
thing
to
try
to
draw
some
some
common
parallels
with
so
I
can
give
a
shot.
A
A
A
If
you
know
any
of
the
people
here
are
going
to
be
at
kubecon,
there's
been
some
interest
in
informally
meeting
up
and
so
an
easy
thing
to
do
just
to
be
to
meet
for
lunch
sometime
after
that
session.
So
we
can
just
organize
and
slack
but
just
be
on
the
lookout.
If
you
are
there
Wednesday
morning,
we
would
love
to
meet
up
all
right
now.
A
Yeah
I
think
this
one
is
I
think
we
have
Shane.
You
may
be
able
to
pipe
in
on
this
one,
but
I
know
we've
been
trying
to
track
and
triage
these
kind
of
new
bugs
I
think
this
falls
under
the
category
of
this
would
be
cool
to
have,
but
we
just
don't
have
the
time
to
do
it,
but
you
know
I,
don't
think
anyone's
against.
You
know
different
different
kind
of
capabilities
here,
if
they're,
broadly
supportable
enough,
but
I
just
I,
don't
think.
There's
yeah.
F
F
A
Yeah
I
think
I'm
just
gonna
remove
help
from
this.
Just
because
I
know
me
personally,
when
I,
when
I
see
the
help
label
I
feel
some
obligation
to
help
review,
because
I've
kind
of
invited
a
new
contributor
I,
had
to
work
on
this,
and
in
this
case
I
know
like
if
it's
backlogged,
I'd
I,
don't
think
I'll
have
a
lot
of
time
to
devote
to
it.
F
A
A
We
already
need
to
change
the
attached
routes
because
attached
routes
refers
to
well,
we
had
a
condition
previously
that
was
attached.
That
condition
does
not
exist
anymore,
so
we
can't
really
rename
this
field,
but
we
should
at
least
update
the
godoc
around
it
and
likely
as
doing
that,
we
should
provide
some
kind
of
guidance
on
those
partially
invalid
state.
F
F
B
A
A
Yeah
there
there
was
basically
you
can
do.
We
should
have
some
kind
of
merge
strategy,
but
we
don't
have
a
unique
field
in
status.
Maybe
that
is
the
thing
so
right
now
the
the
problem
with
status
on
routes
is
that
we're
expecting
multiple
controllers
to
write
the
status
and
there
is
a
possibility
that
they
could
get
into
a
race
condition
if
they're
both
trying
to
write
at
the
same
time-
and
we
do
not
have
a
merge
key
specified
on
that
is
I.
Think
what
this
is.
B
A
A
A
So,
basically,
if,
for
example,
if
you
have
that
this
should
be
fun
because
like
as
John
mentioned,
you
should
just
be
able
to
retry
and
eventually
reach
a
consistent
state.
But
you
can
imagine
a
world
where
you
have
two
Gateway
implementations
that
see
a
brand
new
TCP
route
in
this
example,
and
that
TCP
route
is
trying
to
reference
both
of
their
gateways
separately.
Then,
both
of
those
controllers
May
at
the
same
time
try
to
write
to
status.
A
H
A
F
Definitely
in
the
in
the
you
know
like
a
kind
of
a
nice
to
have
category,
but
it
is
nice
to
have
excellence.
I
think
the
priority
on
it
is
good.
You
just
might
want
to
put
a
help
wanted
on
it
if
somebody's
interested
in
taking
it,
but
actually
in
retrospect
v080
might
have
been
a
little
bit
too
much.
Maybe
we
could
just
put
it
on
v01
and
see
if
we
can
make
it
for
ga.
A
F
F
A
A
G
So
I
think
that
this
is
like
a
really
reasonable
idea.
It's
sort
of
one
of
the
first
things
that
I
was
thinking
of
doing
in
a
second
pass
after
we
have
the
basic
grpc
functionality
in
trpc
web
is
a
different
protocol
from
grpc
proper,
and
so
there
are
a
couple
of
different
considerations
here
generally.
What
people
do
is
they
have
a
transcoder
sitting
at
the
front
of
their
system
so
with
the
API
Gateway,
it's
sort
of
a
natural
fit
for
something
within
the
Gateway
resource.
G
E
B
E
A
E
Yeah
also,
we
need
to
support
HTTP
because
many
implementations
of
gateways
in
particular
what
this
feature
would
be
enabled
may
not
support
grpc
route
because
it's
not
required,
and
it's
not
something
that,
for
example,
you
know
have
way
out
of
box
is
supporting
or
whatever
you
know,
manage.
Gateway
mitigator
may
not
have
native
grpc
support,
but
we'll
have
HTTP
support.
If
we
don't
support.
G
E
G
A
Okay,
so
it
sounds
like
this
is
something
that
is
relatively
straightforward
to
add
on.
After
the
fact,
it
is
not
something
that
needs
to
block
grpc
route-
it's
just
you
know,
maybe
even
somewhat
orthogonal
grpc
route
based
on
the
idea
that
we
would
also
want
this
to
this
kind
of
policy
or
config
to
apply
to
http
route
or,
while
the
Gateway
in
front
of
that.
So,
given
that
I
feel
like
the
likelihood
of
this
coming
in
before
GA
is
pretty
low,
so
I
may
just
remove
it
from
the
board.
E
B
F
F
A
A
E
A
A
E
A
And
there's
also
there's
been
a
long-lived
all
ports
kept
in
Upstream
kubernetes
on
service
and
the
person
working
on
that
it
is
no
longer
working
on
kubernetes
and
it
just
kind
of
fizzled
out
and
said.
Well,
maybe
Gateway
can
solve
this
and
eventually
we
should,
but
it
just
probably
won't
be
between
now
and
GA.
Well,.
F
A
F
Yeah
we
talked
about
it
and
we
were
basically
saying
Gap.
So
I
like
somebody
needs
to
actually
say
how
this
is
going
to
happen.
So
at
this
point
I
would
kind
of
vote
we
take.
We
got
enough.
Nga
I
would
vote
that
this
can
be
a
post
GA
thing.
We
still
do
it
but
accept
it,
but
call
it
Priority
back
quog
and
say
we'll
do
it
after
G.
A
A
A
E
A
E
A
A
A
B
H
This
came
up
briefly,
I
think
on
the
gamma
call,
and
it's
something
that
like
istio,
supports
and
console
supports
today.
So
there's
kind
of
a
question
of
like
is
this
something
that
would
ever
make
its
way
into
Gateway
API
and
like?
If
not,
why
not?
And
what's
the
recommended
alternative,
which
I
think
is
just
like:
creating
additional
services,
yeah.
A
Yeah
I
think
if,
if
I
understand
that
the
idea
right
now
correctly,
it's
that
services
are
pretty
heavyweight
because
they
include
so
many
things.
Gateway
API
is
trying
to
take
away
a
lot
of
that
extra
complexity
from
service
and
move
it
into
Gateway,
API
I.
Think
at
least
from
my
view
of
the
world.
This
is
you
know.
Service
is
still
meant
to
be
the
the
smallest
piece
of
this
puzzle
without
subsets,
but
Services
should
hopefully
become
lighter
weight
or
something
I
I,
don't
know
I.
Ideally
you
wouldn't
need.
A
B
A
It
belongs
is
for
anyone
unfamiliar
with
the
triage
process.
It
is
really
just
trying
to
determine
what
the
next
step
of
action
is
for.
Gateway
API,
you
know
is
this
something
that
we
should
turn
into
a
gap.
Is
that
something
like
that
is
really
just
a
question
about
the
existing
API
that
we
can
close
I'm,
not
sure.
F
A
F
B
A
B
Another
level,
more
than
that's
already
in
the
sense
that
a
controller
has
sent
the
configuration
to
the
proxy
and
proxy
has
ACT
back
that's
one
way,
which
is
an
active
act.
The
second
is
controller.
Can
health
check
or
config
check
to
make
sure
that
that
value
has
is
actually
part
of
the
data
plane.
B
A
B
A
A
D
Yeah
sorry,
I
I
missed
the
first
half
of
this
conversation,
but
I
was
a
bit
confused
because
this
issue
actually
doesn't
have
to
do
with
ready.
It's
actually
about
changing
a
route.
Basically
well.
The
issue
number
one
is,
but
that's
that's
a
bit
different,
I
guess:
I,
guess:
I
wasn't
a
focus
on
issue
too,
because
only
issue
too
was
very
interesting
to
me,
where
we
were
talking
only
about
one
there
with
ready.
D
D
D
Honestly,
even
two
isn't
because
two
is
saying
that
if
you
want
to
have
zero
down
time,
you
need
to
make
sure
that
you
don't
apply
a
route
too
early,
but
the
thing
that
you
should
be
waiting
for
is
not
whether
an
HTTP
route
is
ready.
It's
whether
the
back
end
is
ready.
So
it's
really
like
orthogonal
I
mean
you
could
argue,
like
sure,
set
the
HTTP
route
to
not
match
any
traffic.
Wait
for
that
to
be
ready
and
then
change
the
weight.
D
But
really
what
you
want
is
the
back
end,
ready
and
deployment
or
service
or
endpoints
ready,
actually
don't
represent
whether
the
back
end
is
ready,
because
those
are
that's
the
intent
whether
they
should
be
ready.
It's
not
whether
the
actual
data
plan
is
able
to
start
serving
those
right
away
right.
D
You
yeah
I
would
think
like
in
one
at
least
how
we
have
solved
this
so
far
is
in
one
week.
We
just
make
sure
that
is
the
case
in
our
implementation.
That
I
think
everyone
should
do
that.
Otherwise,
we
will
have
any
time
you
change
a
route
you
have
downtime,
which
I
have
experience
with
some
other
implementations.
I've
tried.
A
D
So
the
first
one
is
actually
not
necessarily
about
waiting
or
anything.
It's
like
I'll
just
explain
how
these
two
implements
it
and
then,
hopefully
it
will
make
it
more
clear
like
we
have
these
set
of
back
ends
right
and
in
this
example,
these
two
back
ends
have
been
static
for
hours
and
what
they're
doing
is
changing
a
route
to
point
to
back
end
a
then
point
to
back
end
B
and
back
and
forth
right.
D
So
basically,
like
the
back
end,
we're
pointing
to
is
just
like
an
atomic
pointer,
that's
flipping
between
the
two.
What
shouldn't
happen
is
like
you,
tear
everything
down,
and
then
you
spin
everything
back
up
and
there's
like
downtime
in
between
right.
It's
like
a
graceful,
restart
versus
shut
down
and
turn
on
I,
don't
know
if
I'm
explaining
this
well.
B
A
A
Them
yeah
I
think
that's
I,
think
that's
all
we
have
right
now.
I,
don't
know
that
we're
complete
at
least
I,
don't
think,
there's
a
complete
consensus
on
next
steps,
but
hopefully
I
think
what
we
need
here
is
just
somebody
to
make
sure
that
you
know
we're
continuing
this
discussion.
It
doesn't
get
lost
and
we
have
at
least
translated
it
into
reasonable
next
steps.