►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220718
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220718
A
All
right
welcome
to
gateway
pm
meeting
for
july
18..
This
is
our
first
meeting
after
having
released
beta
v050.
Thank
you
to
everyone
who
helped
get
us
to
that
point,
and
now
no,
no,
no
rest
for
anyone.
Now,
we've
got
to
keep
on
moving
towards
060
now,
so
I
I
spent
some
time
just
trying
to
sketch
out
some
of
the
priorities
that
I
thought
made
sense
but
want
to
discuss
those
today,
but
before
we
go
any
further,
let
me
take
a
step
back
and
welcome
anyone.
I
think
I
see
a
couple
new
faces
here.
A
If
anyone
wants
to
introduce
themselves-
and
they
haven't
been
to
one
of
these
meetings
before
or
haven't-
had
a
chance
to
introduce
themselves
by
all
means,
we'd
love
to
meet
you
so
I'll
leave
just
a
brief
10-15
seconds
for
anyone
who
might
want
to
introduce
themselves.
A
Cool,
that's
fine.
I
will
keep
on
going
then
this
is
a
community
meeting
that
follows
the
same
practice
as
any
other
kubernetes
community
meeting
feel
free
to
add
agenda
items.
As
you
see
fit,
ask
questions,
there's
a
wide
range
of
expertise
or
experience,
you're
right,
shane,
I'm
sorry!
I
didn't
leave
enough
time,
but
yeah.
We.
We
have
a
wide
variety
of
experiences
here.
So
definitely,
if
you
are
not
as
familiar
with
this
api,
don't
hesitate
to
ask
any
questions.
Sometimes
we
don't
provide
as
much
context
as
we
could.
A
So,
as
always,
we
want
everyone
to
feel,
welcome
and
like
they
can
ask
any
question,
and
there
are
no
stupid
questions
here.
So
with
that
basic
introduction,
let's
get
into
priorities
for
o60,
first
up
grpc
route-
I
I
think
richard
is
here:
we've
I
feel
so
bad
richard.
A
B
A
A
Cool,
okay,
yeah.
I
need
to
take
one
more
look
at
it.
I
I
added,
I
think
one
comment
earlier
today,
but
otherwise
and
I
think
you've
already
resolved
it.
Otherwise,
I
think
this
isn't
an
awfully
good
place.
Does
anyone
have
any
hesitation
about
merging
this.
A
Okay,
well,
we'll
take
that
as
it
is
I'll
I'll
make
sure
personally
to
to
run
through
this
one
more
time.
But
I
know
this.
This
pr
has
been
waiting
to
go
in
for
a
while,
and
I
would
love
to
just
see
it
in
so
I'll
make
sure
I
spend
some
time
on
it
and
anyone
else
who
cares
about
grpc.
A
A
But,
yes,
there
is
still
definitely
room
for
feedback,
just
the
the
more
broadly
it
gets
deployed
or
used
the
harder
it
is
to
make
any
changes.
As
always.
A
Cool
all
right
next
on
the
list
is
reference
grant.
I
personally
am
very
interested
in
reference
grant
over
the
line
to
beta.
I
know
we
already
have
conformance
tests
for
it.
Thank
you
to
everyone,
who's
contributed
to
those.
I
know
we
have
several
implementations
that
support
it.
A
What
I
am
really
unsure
about
in
this
graduation
criteria
is
who's
actually
using
it
and
who's
actually
implemented
it
and
that's
kind
of
hard
to
know
in
the
world
of
open
source
where
anyone
could
have
implemented
it
without.
You
know
api
maintainers
being
aware,
so
I'm
interested
for
anyone
on
the
call.
A
C
So
we
do
have
like
a
really
basic
like
we,
we
have
references
to
it
in
our
code
and
we
do
have
like
a
really
basic.
I
believe
it's
a
namespace
check
that
we
do
using
it,
but
we
don't
have
any
users
using
it.
That's
where
we're
at.
A
C
A
That
makes
sense,
so
it
seems
like
we
probably
have
three
or
four
implementations,
but
very
little
to
almost
zero
feedback.
So
far
for
this
resource,
it
seems
like
what
what
we
may
need
is
the
next
step
here
is
some
kind
of
issue
tracking
reference
grant
graduation
criteria,
basically
and
calling
out
that
the
thing
we're
missing
right
now
is
user
feedback.
C
I
have
some
feedback
about
the
feedback
about
user
feedback,
so
we
have
been
intentionally
at
kong,
not
calling
our
implementation
of
gateway,
api
beta
and
has
been
off
by
default.
We've
called
it
an
alpha
level
feature
gate,
so
we
actually
use
feature
gates
like
upstream
kubernetes
does
and
gateway
is
a
feature
gate,
and
so
that
means
it's
been
default
to
off.
C
Basically,
we
were
waiting
for
the
first
beta
release,
so
now
that
we
have
beta
apis,
we
will
be
we're
we're
on
I'm
having
a
meeting
tomorrow
about
like
getting
it
into
a
this
is
beta
and
we
will
have
it
on
by
default.
So
we've
been
waiting
for
that.
We
did
not
want
to
say
yeah,
our
implementation
is
beta
and
everything
that
they
see
is
alpha.
That
didn't
make
any
sense
so
just
to
just
to
throw
it
out
there.
I
think
that's
probably
if,
if
not
likely,
it
seemed
likely
to
me
at
the
time.
C
Probably
most
implementations
are
doing
something
like
that,
or
at
least
now
that
we
have
a
beta
release.
There
will
be
more
adoption,
so
we
might
want
to
just
give
it
some
time
like
it
might
be.
As
simple
as
that,
because
at
least
from
our
perspective
we'll
be
turning
this
on
by
default
in
the
next
few
weeks
and
then
we'll
be
able
to
get
more
feedback
on
this
kind
of
stuff.
C
A
I
agree
with
that.
I
think
we're
running
into
the
age-old
problem
that
we've
had
with
kubernetes
apis
forever
is
that
it
is
near
impossible
to
get
widespread
usage
and
feedback
on
an
alpha
feature,
because
alpha
is
never
on
by
default
and
nobody
really
wants
to
use.
You
know
in
production,
at
least
these
kind
of
alpha
features.
You
really
have
to
go
out
of
your
way
to
test
these
out.
C
Yeah
we've
had
extremely
low
people.
Turning
on
the
feature
gate
like
it's
been
a
few,
it's
been
a
handful
really.
A
few
customers
like
there's
been
a
few
interactions,
but
it's
it's
not
a
lot
at
all.
A
A
With
that,
I
think
I'll
move
on
to
the
next
thing,
and
I
don't
see
jeff
on
this
call,
but
I
think
that
the
thing
that's
really
next
in
line
as
far
as
readiness
is,
this
route,
inclusion
and
delegation
discussion
right,
jeff
had
proposed.
This
we'd
had
a
number
of
discussions
in
the
spring
about
route,
inclusion
and
delegation,
but
I
think
it
just
kind
of
got
put
on
on
hold
while
we
released
v050
and
we
just
need
to
bring
it
back.
A
A
This
is
one
of
the
big
highlights
I
see
in
our
next
release
and
jeff
is
not
on
call,
but
I'll
follow
up
with
him
after
to
see
what
kind
of
what
the
next
steps
are
for
this
one
and
the
other
ones
I
I
can
think
of
here
are,
I
know,
we've
said
we
need
to
get
our
l4
routes
to
beta,
so
tcp
and
tls
seem
like
they
have
a
somewhat
clear
path.
A
Udp
route
is
harder
for
me
to
reason
about,
but
again
need
to
have
more
more
discussion
and
more
focus
on
these
kind
of
l4
level
routes.
Those
are
the
things
that
I'm
aware
of
in
gateway
api
that
already
have
some
existing
work
that
we
want
to
kind
of
push
to
the
next
level.
Is
there
anything
else
before
we
get
to
gamma
that
we
should
be
thinking
about
for
o60.
E
Sorry
to
be
late,
rob
the
I
don't
know
if
you
mentioned
before,
with
the
reference
game,
one
just
to
roll
back
to
that.
Contour
has
has
got
that
implemented.
I
don't
know
if
we've
got,
I
don't
know
if
we've
got
good
actual
signal
of
people
using
it,
but
we
do
have.
We
do
have
it
implemented
in
this
capacity
performance.
A
My
my
cursor
or
keyboard
focus
keeps
on
going
over
to
chat,
which
is
very
much
not
helpful,
but
yeah,
sorry
for
the
chat
spam,
but
it's
it.
It
sounds
like
thank
you
for
that
update.
A
It
sounds
like
con
contour
console
and
istio
I'll
support
this,
and
you
know
it
seems
like
almost
zero
feedback
so
far
from
us,
so
that
that's
kind
of
the
the
missing
piece
it
exists,
there's
some
some
support
for
it,
but
people
actually
opting
in
and
using
it
and
then
providing
feedback
is
kind
of
the
missing
step.
E
I
think
we
also
need
to
just
remember
that
other
apis
are
looking
at
using
this
api
as
well.
You
know
there's
at
least
two
instances:
I've
seen
where
other
apis
are
looking
at
using
reference
grant
in
their
own
apis,
and
so
they
would
like
it
moved
to
beta
as
well.
I
don't
know
if,
but
we
should
check
in
with
them
about
their
usages
of
the
alpha
reference
grant
and
see
if,
if
they
have
any
actual
information
about
it
being
used
or
if
they're,
just
still
in
the
design
phase,.
A
Yeah
good
point
yeah,
so
other
apis
as
well.
I
remember
this
is
its
storage
bucket
is
one
yeah.
I
think
that
was
that
k
yeah
yeah,
so
this
is
going
to
be
a
real
test
of
that
last
bit
of
the
graduation
criteria
of
people
are
actually
using
this
feature,
and
we,
you
know,
as
I
kind
of
mentioned
before,
we
need
some
probably
more
concrete
way
to
identify
what
that
means,
but
I
think
reference
grant
has
probably
met
every
other
piece
of
the
criteria
right
now,.
E
Yeah,
I
do
think
that
it's
it's
a
really
bad.
Look,
though,
that
you
can't
actually
you
that
if
you
want
to
be
able
to
do
crosstalk
search
references,
you
can't
do
them
properly
in
in
the
standard
channel,
and
so
I
think
we
need
to
work
really
hard
on
pushing
this.
A
To
to
beta,
I
yeah
completely
agree.
A
Cool
all
right,
so
that's
l4
routes
and
reference
grant.
Last
I
wanted
to
ask
about-
was
gamma
and
I'll
kind
of
hand
this
over.
I
see
john's
on
this
call
I
key
if
you're
on
this
call,
it's
probably
too
early
to
know
what
your
priorities
are,
what
you're
hoping
to
get
in
the
next
few
months,
but
any
idea
what
what
you'd
hope
to
do
sometime
this
fall.
B
I
I
was
just
about
to
kind
of
echo
one
of
the
questions
in
the
chat
which
was
do
we
have
a
targeted
release
date
for
this,
because
that'll
probably
affect
the
answer.
There.
A
You
know,
I
think
that
that
that's
a
good
question,
one
of
the
things
that
I
know
is
if
we
have
something
that
is
ready
to
graduate
to
beta,
like
let's
say,
reference
grant
that
is
very
close
to
ready
for
beta
and
whenever
that
hits
that
last
bit
of
this
is
ready
for
beta.
I
think
that's
we'd
have
to
you
know:
we'd
have
to
release
pretty
soon.
After
that,
I
would
like
to
get
one
more
release
out
one
more
minor
release
out
in
2022
this
calendar
year.
A
Personally,
I'm
open
to
what
others
think.
I
think
it's
at
least
possible
to
get
reference
grant
to
beta
in
that
time
frame.
I'd
love
to
do
more.
E
Yeah,
I
think
that
I
would
certainly
I
would
like
to
see
us
have
reference
grant
to
beta
before
coupon
in
a
that's
like
before
start
of
october.
Personally,
I
think
that
that
is
probably
doable.
E
If
we
can
get
some
actual
user
feedback
yeah,
it
might
require
being
clever
with
what
user
feedback
is,
but
you
know
like
we
should
be
able
to
get
some
something
from
people
who
are
actually
using
this
who
are
not
actually
on
this
call
right
now,
and
I
think
that's
the
key
is
that
you
know
we
need
to
have
some
people
who
are
not
involved
in
the
development
of
the
gateway,
api
or
or
implementation
yeah,
actually
saying
yeah.
This
thing
is
useful
and
we've
used.
E
It
is
the
is
the
key
thing.
That's
that's
my
that's
what
I
would
like,
I
don't
think
that's
unachievable
and
then
once
we've
done
that,
then
it
would
be
really
nice
that
it
would
be
really
nice
if
we
could
cut
another
one
this
year.
But
again
what
would
be
in
that?
I
have
no
idea.
B
Gotcha
to
go
back
to
your
question,
rob
with
that
being
said
and
john
or
mike
feel
free
to
offer
other
opinions
here,
but
I
think,
by
that
time
period,
I'd
at
least
want
us
to
have
a
a
model
for
how
to
think
about
service
mesh
and
get
ready
api.
I
think
that's
pretty
achievable.
B
We've
already
got
a
good
start,
and
ideally
it
would
be
pretty
cool
if
we
don't
even
need
to
add
resources
or
if
the
resources
we're
adding
are
just
like
you
know,
maybe
a
mesh
to
correspond
to
gateway
and
our
mesh
class
corresponding
gateway
class
depending
on
what
that
model
looks
like
it
would
be
great
if
it
was
minimal
and
like
the
first
step,
was
just
being
able
to
get
like
a
a
mental
map
for
folks
of
how
to
start
thinking
about
gateway
api
for
mesh
john
mike,
you
have
any
other
thoughts
there.
A
Feels
like
about
the
most
that
we
should
shoot
for
in
kind
of
this
time
frame.
I
I
don't
think
that
we'll
get
too
much
further
than
that
in
terms
of
like
actual
implementation,
yeah,
definitely
only
experimental
channel
targeting
in
this
time
here
I
think.
A
Yeah
I
mean
that
that
seems
great.
I
I
just
look
at
this
list
and
I
am
amazed
at
how
much
we
have
coming
up.
So
I
feel
like
we
say
this
every
week,
but
if
you're
interested
in
getting
more
involved
and
contributing
to
this
api,
we
have
all
kinds
of
opportunities
here,
all
kinds:
they're
there.
It
are
opportunities
to
go
up
the
you
know,
contributor
ladder,
lots
of
opportunities
in
this
project
and
great
ways
to
contribute.
So
if
this
kind
of
stuff
interests
you
we'd
love
to,
have
you.
E
Agreed,
I
would
sort
of
add
to
that
as
well
and
say
that
I
don't
think
we're
doing.
I
had
a
bit
of
a
look
through
like
our
good
first
issues
and
stuff
like
that,
and
we're
definitely
not
doing
a
good
job
of
making
it
easy
feel
at
the
moment.
E
So
if
you
are
interested
in
contributing,
but
you
can't
find
a
place
to
start,
please
feel
free
to
ping
me
personally,
your
nick
on
cubeslack
and
I
would
love
to
be
able
to
sit
down
and
go
through
some
open
issues,
and
people
can
talk
me
through,
like
the
sorts
of
things
you're
interested
in.
We
can
try
and
find
you
some
stuff
that
may
have
been
closed
by
the
stale
bot
or
you
know
that
sort
of
stuff
you
know
like
we
haven't
done
a
good
job
of
doing
this.
E
So,
like
you
know,
I
would
like
to
bootstrap
that
process
a
bit
and
you
know,
help
people
to
get
themselves
up
to
speed
on
like
what's
happening
and
what
needs
to
be
done
and
find
some
sort
of
lower
hanging
fruit
that
then,
and
then
figure
out
a
way
that
we
can
turn
those
low-hanging
fruit
into
like
things
that
you
don't
need
me
to
see
with
you
to
to-
or
you
know,
start
a
maintainer
to
see
with,
but
but
right
now
we
do
not
have
that
right.
E
So
we
need
to
build
that,
and
so
I
really
appreciate
if
anybody
wants
to
hit
me
up.
I
do
work
australian
hours
so
like
this
time
or
a
bit
later,
is
like
the
best
for
me
but
yeah,
but
I
I
will
make
time
for
anybody
who
wants
to
do
that.
Please.
A
Yeah
and
I'll
echo
what
nick
said
too
depend.
You
know
I
I
work
pacific
time,
but
between
us
and
and
shane
as
maintainers.
I
think
we
have
pretty
good
time
zone
coverage
so
find
a
maintainer.
That's
in
your
time
zone,
I'm
sure
we'd
all
be
interested
in
helping
get.
You
started
yeah.
E
Yeah,
I
think,
there's
a
couple
of
call-outs
we
should
make
before
we
move
on
to
any
further
discussion.
Mikey
had
a
good
call
in
there
about
tlsr
I've
been
to
steve
from
tcp
route.
We
talked
actually
a
lot
about
that
historically,
there's
quite
a
bit
of
context
there,
and
so
I
think
that
it
is
a
useful
distinction
to
have
personally
the,
but
I
would
that
would
that
is
a
discussion
for
another
time.
E
I
also
think
in
terms
of
the
layer,
4
stuff
udp
route
is
probably
the
hardest
one
to
do
with
an
in-cluster
proxy,
but
that
it's
going
to
be
really
important
for
the
basically
tcp
route
and
udp
route
are
the
most
important
for
service
type,
load,
balance
or
replacement
right,
like
a
lot
of
what
we've
talked
about
with
http
route
is
effectively
ingress,
object,
replace
ingress
resource
replacement,
the
other
the
tcp
router
udp
route.
To
a
lesser
extent,
tls
route
is
for
like
replacing
service
type
load.
Balancer
like
functionally
not
like.
E
A
A
Okay,
I
will
take
that
I
know
there's
a
few
discussions
here
that
will
probably
result
in
net
new
work,
but
I
think
these
are
the
major
themes
that
we're
going
forward
with
next
up
gamma,
you
have
decided
on
meeting
times
congrats
keith.
I
think
you
went
with
a
wheat
well
eight
days
from
today
at
this
time
that
yep
awesome
cool,
I
I
know
you're
you're
stuck
on
a
pr
I
pinged
casey,
to
try
and
help
with
that.
A
Hopefully,
we'll
get
some
kind
of
response
soon,
but
yeah
anyone
interested
in
mesh
and
gateway
api,
separate
meetings,
starting
for
that
awfully
soon.
E
I
definitely
have
some
thoughts,
but
that
are
not
fully
developed.
So
I'd
like
to
talk
through
some
of
them
with
you
all
I've
read:
I've
read
the
doc,
but
I'm
not
sure
where
to
put
my
comments
on
the
doc
so
yeah
so
I'll,
yeah
I'll
come
along
to
that
first
meeting
for
sure.
A
You
know
awesome
on
that.
On
that
note
one
of
the
things
I
you
know,
I
don't
know
that
we
have
time
to
get
into
a
full-fledged
discussion
about
what
this
would
look
like,
but
I
think
it
could
be
helpful
if
you
know
I
think,
there's
probably
a
good
amount
of
overlap
on
the
people
on
this
call
and
the
people
that
will
attend
that
call.
Is
there
some
homework
or
required
reading
kind
of
thing
that
would
help
us
be
better
prepared
for
the
first
gamma
meeting.
B
Question
yeah
that
I
think
I
linked
to
it
in
last
week's
meeting
notes.
I've
been
I
I've
linked
that
document
so
many
times.
I
forget,
where
everywhere,
that
I've
put
it
yeah
here
it
is
down
here,
but
this
is
probably
the
best
required
reading
here.
B
This
exploration
get
repayed
for
from
each.
So
that's
where
a
lot
of
discussions
kind
of
already
taken
place.
So
if
you
wanted
to
show
up
this
that'll
probably
be
our
starting
point
and
rob
just
for
some
to
add
in
into
your
bullet
point
on
meeting
times,
just
wanted
to
make
it
known
and
restate
here
that
we
are
planning
to
try
to
alternate
meeting
times
for
gamma
to
try
to
be
inclusive
of
both.
B
Those
in
kind
of
the
asia-pacific
time
zone
just
follows
those
in
europe
we'll
see
how
it
goes
as
most
things
in
software
now
we're
going
to
iterate
and
see
how
things
how
things
work,
but
this
next
one
on
july
26
is
going
to
be.
You
know
right.
You
know
same
time
at
this
meeting
at
five.
Well,
3
p.m,
pacific
time
and
then
the
next
week
on
august,
2nd
we'll
be
doing
8
a.m.
Pacific
time.
A
Sounds
great,
I
hope
we
get
more
attendees
from
the
europe
time
zones
and
others
we
tried
that
one.
We
tried
that
earlier
on
and
we
didn't
have
as
much
luck
with
it,
but
there
may
be
more
mesh,
maintainers,
specifically
interested
from
those
time
zones
so
yeah.
I
I
appreciate
that
you're
flipping
between
time
zones-
and
hopefully
we
get
more
attendance
that
way
cool
all
right.
So
the
last
bit
of
this
I
wanted
to
run
through
a
few
discussions.
Github
discussion
specifically,
I
had
been
okay.
A
Well,
not
that
great,
but
I
had
at
least
as
in
many
meetings
been
going
through
issue
triage
and
pr
triage,
which
is
basically
matching
upstream,
but
in
upstream
we
don't
have
discussions,
and
here
we
have
discussions
and
those
just
kind
of
fell
off,
at
least
for
me,
and
I'd
left
some
comments,
but
going
through
them.
There
are
some
really
good
discussions
in
here
that
I
have
not
paid
as
much
attention
to
as
I
should.
A
This
is
not
a
complete
list
by
any
stretch,
but
these
are
some
of
the
ones
that
I
thought
were
interesting
and
deserve
more
discussion
here,
as
always
feel
free
to
add
something
to
the
list.
If
you
think
we
should
discuss
it
here,
but
let's
start
with
one
that
has
been
in
discussion
over
the
past
week
or
two
and
that's
evan's
point,
which
is
a
great
one,
that
we
don't
have
a
good
way
of
specifying
the
upstream
protocol
for
some
some
period
of
time.
A
We
had
suggested
well
use
app
protocol
on
service
and
that
works
in
very
specific
scenarios,
but
isn't
as
portable
as
you
would
like,
as
as
we
would
like.
So
nick
you've
had
good
discussion
on
here.
I
know
I've
commented,
you
know
boys,
a
bunch
of
us
have
commented
on
this
specific
thread,
and
I
don't
even
really
know
where
to
start
this
discussion.
A
You
know
what
one
of
the
things
I'll
highlight
is
I
the
app
protocol
field
itself
on
service.
We
tried
to
add
this
kind
of
catch-all
thing
of
hey.
It
can
be
any
service
name
or
otherwise.
It
needs
to
be
a
domain
prefix
name,
and
this
list
of
names
is
very
long,
but
it
does
not
include
some
very,
very
common
things
like
it's.
A
A
This
is
the
thing
I
support,
but
in
many
cases
there
are
multiple
things
that
a
backend
may
support,
so
it
seems
like
app
protocol
is
lacking
what
we
really
want
here,
and
so
we
can
go
back
upstream,
and
you
know
at
least
for
something
like
it
doesn't
support
these
things.
We
can
just
say
well.
This
is
how
you
represent
these
very
common
protocols.
A
That's
like
one
starting
point.
The
next
part
is
much
harder
to
change,
and
that's
how
do
you
represent
multiple
multiple
of
these?
You
know
it's
just
a
string
field.
I
don't
think
we
want
to
go
through
the
exercise
of
turning
a
string
field
into
a
list
or
doing
comma
separated,
or
it's
all
messy.
So
this
is
me
coming
with
a
problem
and
not
a
solution,
but
I'm
interested
in
what
others
think
here,
any
any
feedback,
any
additional
thoughts
on
what
we
might
be
able
to
do
with
this.
E
And,
as
I
said
in
that
comment,
I
think
the
the
other
thing,
the
other
dimension
that
we
need
to
ensure
is
captured
here,
is
like
pro
capabilities
that
need
protocol
stuff.
Websockets
is
the
is
the
canonical
example
here
like
that
can
be
done.
Over
https
can
be
done.
Over
h2
can
be
done.
Over
http
1.1
can
be
done
with
clear
text,
but
there's
lots
of
places
where
that
can
be
done
in
contour.
E
We
ended
up
just
making
that
a
separate
field
of
its
own,
like
websockets,
enabled
true,
and
so
I
think
there
may
be
some
space
for
us
to
need
to
add
stuff
like
that.
I
would
be
nice
to
be
able
to
have
somewhere
to
do
it
a
bit
more
elegantly
than
that.
What
that
could
be
not
sure.
I
do
think
it's
also
important
for
us
to
use
the
right
words
here.
E
As
always,
the
envoy
nomenclature
of
upstream
being
in
this
use
cases
north
not
towards
the
internet
not
and
so,
and
the
back
ends
are
downstream.
It's
very
confusing,
so
I
think
that
we
need
to
make
sure
we
don't
use
upstream
and
downstream.
We
need
to
use
back
end
and
client
or
something
like
that,
because
otherwise
you
can
be
very
confusing
if
you're
used
to
working
on
onboard
things.
You
know
I
always
find.
I
have
to
clarify
that
with
people.
A
E
E
I
do
think
that
there's
a
really
important
distinction
to
talk,
because,
because
we've
got
like
a
protocol
field
on
the
listener,
which
is
the
client
side
internet
side-
and
this
is
we're
talking
here
about
the
back
end
side-
there
is
an
implied
translation
if
those
two
things
are
different,
and
so
it's
also
important
to
consider
like
what
that
implied.
E
Translation
means
and
is
it
possible,
like
you
know,
if
you
say
http
on
the
listener,
and
then
you
say
grpc
on
the
on
the
inside
or
or
use
grpc
route
see
richards
on
the
call.
Does
that
mean
that
you're,
implying
that
the
gateway
should
be
able
to
translate
translate
between
1.1
and
grpc
like
it
does
to
me,
but
like?
Is
that
what
we
want
to?
We
need
to
be
explicit
about
that
and
say
like
hey.
E
This
is
how
this
is,
how
you
do
this
yeah,
and
I
think
that
the
thing
that
the
thing
that
evan's
doing
really
well
here
is
he's
helping
us
make
sure
that
we
plug
the
holes
in
our
spec
right.
This
is
the
this
is
the
thing
that
we
absolutely
do
not
want
to
have
to
happen.
We
don't
want
to
have
a
vague
spec,
like
ingress
sort
of
be
what
we
only
end
up.
Building
around
like
we
want
to
be.
E
We
want
to
have
respect,
be
specific
and
handle
this
stuff
specifically
and
for
us
all
degree,
and
the
only
way
that
we
can
do
that
is
by
making
sure
that
everybody,
you
know,
talks
on
this
sort
of
discussion.
We
talk
about
it
in
some
meetings
and
we
come
to
some
general
agreement.
I
don't
think
the
specific
solution
is
nearly
as
important
as
us
coming
to
a
general
agreement
about
it.
John.
C
I
just
giving
some
not
solving
a
problem
that
this
is
a
canonical
problem
in
industry
and
it's
never
been
solved.
I
mean
there's
been
multiple
ietf
groups
formed
to
try
and
define
the
canonical
app
id.
I
think
every
vendor
and
we're
one
of
them
defines
our
app
ids
and
they
have
a
huge
mapping
table.
So
I'm
not
sure
if
there's
a
way
to
solve
it.
Absolutely
so
I
would
suggest
that,
however,
you
want
to
solve
it
or
how
we
would
try
and
solve
it.
C
C
E
E
I
think
that,
like
I
think,
we've
got
the
pieces
of
like
80
to
90
solution
already
right,
like
you
know
the
fact
that
the
fact
that
we've
already
got
a
distinction
between
the
one
side
and
the
other
like
and
that
lets
you
specify
like
implied
translations,
is
really
nice
property
of
how
we've
designed
the
how
we
ended
up
designing
the
listener.
So.
E
E
E
Yeah
I
mean
I
I
I'm
probably
not
in
favor
of
that
I'd
rather
have
that
the
translation.
If
we're
going
to
have
translation,
it
needs
to
be
very
early
on
and
it
needs
to
be.
This
is
the
way
you
do
it
and
there's
no
customizability
that
this
is
it
because
it's
hard
enough
already,
like
we've,
got
to
cut
scope
but
somewhat
somewhere.
I
think,
okay
and-
and
I
think
that
we
should.
E
Things
with
the
route
with
different
route
object
types
as
well
yeah,
I
mean
there's
some
stuff
there
that
we've
specific
that
we
left
under
specified
deliberately
because
we
wanted
to
come
back
to
it
later.
You
know
like
the
fact
that
the
listener
has
a
protocol
on
it,
and
then
you
attach
routes
that
may
or
may
not
match
that
protocol
like
what
happens.
If
you
specify
http,
is
the
listener
protocol,
and
then
you
attach
tcp
routes
like
don't.
C
Know
you
know
like
we
haven't
specified.
E
No,
I
think
correct
me
if
I'm
wrong.
A
No
yeah
you're
right
the
these
are
kind
of
the
painful
gaps
in
our
api
right
now
and
like
like
john
mentioned
it
it
is
challenging
to
solve,
and
we
we
need
to
be
very
careful
in
what
we
do
here.
So
we
don't
boil
the
ocean.
I
I
also
appreciate
that
guidance
yeah.
I
I
think
this
you
know
evan's
answer
that
yeah.
These
are
all
subsets
of
http
yeah
that
that's
true,
so
I
a
lot
of
yeah
this.
This
is
going
to
take
some
more
thought.
A
C
Yeah
I
mean
yeah,
I
see
it
is
a
very
sort
of
ingress
sort
of
proxy
center
thing,
but
I
don't
know
if,
like
network
policy
or
if
anybody
else
has
faced
this
problem
or
not
like,
if
they
have,
maybe
they
have
like
just
just
to
not
fragment
it
further
right
like
as
we
as
john
said
right,
this
is
already
a
pretty
fragmented
space
and
we
increase
the
fragmentation,
and
I
mean
I
would
also
like
to
move
fast.
It's
just
if
somebody
like
somebody
used
reference
grant.
You
know
great
so
something
like
that.
A
Yeah,
I
agree.
I
think
that
means
it's
a
good
idea.
I
think
we
should
bring
this
up
one
level
to
and
talk
about
it
at
sig
network
next
week
or
in
a
few
days
and
see
what
kind
of
other
discussions
have
already
happened
here.
I
know
we
tried
with
that
protocol
and
that's
a
relatively
recent
thing,
but
it
leaves
some
gaps
still
yeah.
A
A
All
right,
the
next
one
may
be
slightly
easier
to
discuss,
and
that's
this
repeated
query
params
in
the
url
itself.
A
I'm
not
query
params
in
our
api,
but
if
the
url
itself
has
a
equals
one
and
a
equals
two
which
of
those
do
we
match
on,
there's
been
some
discussion
in
this
already
that
basically
says
that
the
layer
that
gateway
api
implementations
largely
exist
at
doesn't
have
much
control
over
what
the
underlying
implementation
actually
does
here
right.
A
A
A
C
I
know
this
is
for
creative
parameters.
What
I'm
asking
is
like.
Do
we
even
like
what
is
the
behavior
with
headers?
You
know.
A
So
there's
two
things:
what
we
do
handle
is
our
configuration
itself
right
of
saying
that
duplicate
values.
So
if
you
have
in
the
query,
param
match
list
or
the
header
param
list
in
a
http
route,
that
duplicate
values
are
invalid
will
be
prevented
by
the
web
hook.
If
they
get
past
the
web
hook.
I
think
we
say
you
must
trust
the
first
value
I
don't
know,
but
we
we
have
some
level
of
guidance
on
what
you
do
when
there
are
duplicates
in
the
http
route.
A
E
E
E
A
C
Here
hi
this
is,
this
is
miquel
yeah.
I
I
just
want
to
sort
of
like
a
guidance
for
what
would
be
like
a
more
common
way
like
what
is
like
like.
If
we
don't
space,
let's
say
if
you
don't,
if
there's
no
like
standards,
what
is
like,
what
is
the
most
common
way
to
implement
like
I
I
come
from
like
the
engineering
executive
implementation
and
we
we
can
implement
it
using
different
ways,
so
we
can
support
multiple
ways.
C
This
can
be
implemented,
so
if
there
is
no
standard,
maybe
the
next
question
is:
is
there
like
some
common
way
among
all
the
proxies,
and
the
second
question
will
be
so,
I
think
nick
you
said
to
create
an
issue
something
to
specify
that,
but
maybe
it
should
be
specified
somewhere.
It's
like
a
very
corner
case,
but
maybe
it
still
should
be
specified
in
the
documentation
for
the
for
the
for
the
particular
field.
In
a
crd.
E
E
Go
ahead,
I
was
yeah,
I
was
just
gonna
yeah.
I
agree
that
we
should
end
up
specifying
something
in
the
crd,
but
I
think
we
need
to
have
a
way
to
say:
hey
we
haven't,
we
don't
know
enough
to
specify.
Yet
maybe
maybe
we
put
that
in
the
go
doc
and
say
you
the
you
know,
maybe
we
need
to
put
in
there
and.
E
A
My
guy
came
up
came
to
the
rescue
here
in
chat,
pulling
up
the
reference
to
what
we
did
for
header
matching
and
it
seems
like
we
just
want
to
copy
and
paste
that
and
say
the
same
for
query.
Paramatching
pr
is
welcome.
This
seems
like
a
pretty
straightforward
one.
D
I'm
wondering
if
we
should
be
a
little
more
cautious,
though
in
the
future
too.
Like
do
we
want
to
leave
ourselves
and
out
to
put
something
in
the
api
to
say
whether
we
match
exists
in
the
set
exactly
is,
or
things
like
that.
E
Yeah,
I
think
that
in
general
we
should
absolutely,
but
I
think
that
again
like
once
once
we
specify
once
we
specify
stuff
like
that,
you
can't
take
it
back.
So
you
know
we
need
to
be
careful
about
doing
that
sort
of
thing,
because
once
once
you've
done
it,
that's
it
it's
there
forever
or
it
is
hard
to
remove
it's
easier
to
think
of
it
as
being
there
forever
because
of
the
difficulty
of
removal,
then,
even
though
you
can
actually
remove
it,
it's
just
really
hard.
D
And
the
http
header
case
is
a
little
bit
different
too,
because
it
defines
that
you're
allowed
multiple
and
they
end
up
semi-colon,
separated
or
something
I
have
to
reread
the
spec,
but
and
then
some
fields
explicitly
state
whether
or
not
they
allow.
Multiple
like
the
sts
only
allows
one,
but
it
specifies
it
takes
the
first,
but
there's
no
firm
standard
in
either
headers
or
parameters.
What
the
real
behavior
will
be.
So,
especially
when
the
parameters,
I
think
it's
going
to
get
dicey.
E
E
E
E
Yeah
so
I
mean
some
of
these
fields
are
better
already
so
because
they're
in
http
route,
which
is
now
beta
so
yeah,
but
I
mean
we
do
have
the
we
have
the
experimental.
E
Can
mutate
some
of
this
in,
like
an
experimental
kind
of
way?
If
we
are
adding
new
fields,
we
can't
do
experimental
like
changes
to
the
go
doc
for
an
existing
field.
Yeah
like
it's,
that's
like
we
change
it
or
we
don't.
There's
no.
There's.
D
E
A
A
Yeah
that
that's
my
hesitation
here
I
I
know
many
implementations
here-
are
really
just
writing
to
an
underlying
proxy
that
they
don't
control
so
they're
kind
of
stuck
with
whatever
that
is
doing.
A
I,
and
in
some
cases
I
you
know,
I
did
a
bit
of
looking
around
as
I
was
looking
at
this
question
or
discussion
and
what
I
found
and-
and
I
could
be
remembering
wrong,
but
I
thought
I
found
some
implementations
that
I
only
looked
at
the
last
query
parameter
instead
of
the
first,
for
example,
right
yeah.
E
B
Yeah,
I
just
kind
of
want
to
echo
that,
like
there
are,
I
think,
two
different
audience
audiences
for
this.
There's
the
you
know,
implementation
developers,
who
are
you
know,
need
that
guidance
for
should
should
not
into
understanding
their
learning
proxy,
but
there's
also
the
users
who
are.
You
might
be
surprised
by
this
because
they
didn't
realize
that
their
the
thing
that
they're
using
has
a
different
implementation
if
you're
migrating
from
engine
next
to
contour
or
whichever
direction.
Oh
wait
now.
B
My
header,
my
my
matching,
is
all
broken
because
their
implementations
are
different,
so
I
think
those
kind
of
situations
where
a
end
user
could
find
themselves.
I
mean
that
that's
effectively
a
breaking
change
when,
if
you
move
between
implementations
and
that
kind
of
thing,
I
think,
is
important
enough
to
call
out
in
documentation.
D
E
Yeah
it
feels
like
we.
We
should
also
include
there
that
you
know
users
of
this
api.
Should
you
shouldn't
should
try
to
ensure
that
that
parameter,
matching
values
are
distinct
and
that
you
don't
have
duplicates
you
can.
E
Should
because,
like
in
the
event
that
we
have,
you
know
delegated
routes
that
allow
you
to
match
on
prams,
like
it
is
possible
that
you
could
end
up
with
two
and
defining
do
you
throw
them
out
and
stuff
like
that
is
really
really
complicated.
E
I'd
say
this
is
someone
who
wrote
who
wrote
a
significant
chunk
of
the
contour
code
to
handle
the
contours,
inclu
inclusion
thing,
which
for
reasons
was
even
harder
than
the
one
we're
talking
about
for
our
one,
so
yeah
yeah,
but
I
think
again
providing
some
should
guidance
at
least
we'll.
Let
people
be
like
hey
debbie
dragons
here
you
know.
Don't
don't
do
this
unless
you
really
really
really
know
what
you're
doing.
A
E
Expect
there
to
be
some
weirdness,
if
you
do.
E
E
D
Yeah
I
mean
there
are
absolutely
valid
use
cases
for
parameters.
The
question
is
like
you
can
pick
multiple
choices
on
a
list
right.
If
you
have
multiple
things
on
shopping
cart,
you
can
put
thing,
but
would
you
ever
route
differently
based
on
that,
like
that's
the
key
question
right,
why
would
you
ever
dispatch
on
something
that
could
have
multiple
potentially
selectable
values
for
routes
like
what
sense
does
it
make.
E
Yeah
yeah,
and
so
that's
what
I
mean
by
putting
putting
putting
stuff
in
the
spec
to
say
you
know,
users
of
this
api
users
who
are
doing
query
param
matching,
should
keep
in
mind
that
you
that
you
should
be
careful
about
what
you,
what
programs
you
pick
for,
matching
and
don't
don't
use.
Don't
you
try
not
to
end
up
with
multiple.
D
A
A
Yep
sounds
good
awesome,
thanks,
mikael
cool,
great
discussion.
I
think
we're
just
about
running
out
of
time,
but
I'll
try
and
real
quickly
go
through,
or
at
least
highlight
that
these
exist.
A
One
is
this
discussion
of
cluster
local
gateways,
I'm
interested
in
it
from
from
a
slightly
different
but
similar
perspective
of
network
local
gateways,
which
I
think
would
largely
be
configured
in
a
similar
way,
at
least
that's
my
perspective
on
this.
It
seems,
like
you
know,
of
our
discussions.
This
has
almost
the
most
up
up
votes,
so
it
seems
like
there's
some
level
of
interest
in
this
one.
I
there's
some
discussion
here.
I
need
to
get
back
to
it,
but
just
I
wanted
to
raise
this
in
case.
A
Anyone
else
hadn't
been
watching
discussions
that
closely.
If
you
have
thoughts
on
how
this
could
be
represented,
I
know
we
have
been
interested
in
kind
of
a
generic
way
of
representing.
I
want
this
gateway
to
be
internal
to
my
network
or
cluster,
or
something-
and
this
isn't
the
first
time
this
this
discussion
has
come
up.
C
E
C
E
Traffic
when
you
own
multiple
clusters
right
and
you
don't
want
to-
you-
want
to
be
able
to
say.
I
want
this
to
be
an
internal
network,
but
it's
still
inter
cluster.
So
I
think
I
think,
but
so,
but
it
could
be
that
it
could
be.
That
evan
is
also
saying
about
hey.
I
want
to
have
an
intra
cluster
gateway
that
is
like
hairpinning,
essentially
the
traffic
for
the
glassdoor,
which
is
actually
looking
so.
E
A
Yeah,
so
I
I
was
just
kind
of
adding
on
an
extra
one
of
same
network,
but
evan's
use
case
is
very
much
same.
Cluster.
E
E
And
I
know
that
you
know
what
I'm
talking
about
yeah
like
that's
yeah,
and
that's
that's
really
what
this
is
right.
This
is
like
taking
traffic
from
and
rather
than
doing,
the
there's,
probably
some
relevance
here
to
gamer
as
well,
because
like
rather
than
doing
the
describing
the
traffic
within
the
cluster
via
like
this,
it
sort
of
goes
up
and
then
back
down
again
right,
like
that's
happening,
there's
a
slightly
different
way
to
achieve
a
similar
thing,
and
that
is
very
important
in
the
candidate
right.
D
There's
an
interesting
interaction
through
with
network
policy
as
well
like
you
could
protect
a
resource
from
being
directly
accessed
for
security
reasons,
but
people
may
also
use
it
to
bypass
network
policy
restrictions.
So
it's
a
bit
funny.
E
Yeah
yeah,
so
you
get
the
the
same
joy
that
we
had
with
ingress
control
as
an
external
name
all
over
again,
if
you're,
not
careful,
which
was
not
cool,
so
yeah,
there's.
Definitely
things
to
talk
about
here.
A
Yeah,
I
think
we've
we've
run
out
of
time
for
our
meeting.
Thank
you
for
everyone
for
staying
around,
but
I
think
we've
got
plenty
more
to
discuss
on
this
one.
I
can
add
it
to
the
agenda
for
next
week,
but
in
the
meantime,
feel
free
to
add
comments
and
I've
run
out
of
time
for
everything
else,
but
just
something
to
think
about
longer
term.
Some
of
these
things
feel
like
they
could
be
better
represented
as
issues
I.
This
is
more
of
an
organizational
thing,
but
just
throwing
that
out
there.
A
Maybe
we
are
using
discussions
a
bit
too
much,
but
we're
past
time
yeah.
So
I
think
you
can't.