►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220711
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220711
A
All
right
welcome
to
gateway
api
meeting
for
july
11..
We
hope
this
is
our
last
meeting
before
having
released
the
0.5.0
so
excited
about
all
those
things.
It's
a
huge
release
for
us.
We're
really
excited.
Thank
you
to
everyone.
I
think
everyone
on
this
call
has
helped
in
some
form
or
fashion,
to
get
us
to
this
point.
A
So
hey
we're
we're
excited,
but
we
have
a
few
little
odds
and
ends
to
get
through.
I
think
that's
mostly
what
this
meeting
is
about,
but
also
I
want
to
welcome
again
keith
and
everyone
who's
been
working
on
service,
mesh
and
gateway
and
how
that
works
together.
A
I
think
you'll
have
some
something
to
talk
about
closer
to
the
end
of
this
meeting,
so
yeah
and
as
always,
I
should
add
that
kind
of
standard.
Welcome
that
this
is
a
standard,
kubernetes
community
meeting
this
if
you've
been
to
any
kubernetes
community
meeting
this
functions
very
similarly,
anyone
is
welcome
to
comment,
feel
free
to
add
things
to
the
agenda
that
you
want
to
talk
about
and
yeah
welcome.
Welcome
everyone
with
that.
Let's
get
started.
I've
added
the
first
couple
things
to
the
agenda.
A
I
think
we
may
have
gone
just
a
little
step
too
far
on
this
one,
and
so
I'm
proposing
reverting
part
of
a
change
we've
made
earlier.
We
so
throughout
this
api
we
have
a
number
of
enum
values.
In
this
case
we
have
an
address
type
on
gateway
and
one
of
the
values
we
had
there
or
allowed
there
was
named
address
it
was
removed
earlier
with
the
argument.
Being
that
named
address
is
not
really
portable
in
the
sense
that
it
will
mean
something
different
on
every
cloud.
A
A
What
I
think,
where
I
think
we
made
a
mistake,
is
removing
the
value
altogether
as
a
valid
thing.
That
could
be
said.
I
my
concern
here
is
that
so
far
we've
said
whatever
was
valid
in
v1.
Alpha
2
is
valid
in
v1
beta
1..
You
know
this
release.
Is
you
know
if
you
had
a
valid
manifest
and
v0.4.0
it's
going
to
be
valid
in
v0.5.0,
and
I
recognize
not.
Many
people
have
used
a
named
address
type,
but
for
anyone
that
has
this,
would
this
would
break
that
for
them
this
would
say
hey
when
you
upgrade.
A
A
My
argument
is
just
to
you
know
let
that
values
continue
to
be
set
any
any
comments
or
hesitation
about
this
change.
I
know
we'd
we'd
agreed
to
remove
it
initially,
but
I'm
I'm
regretting
that
that
specific
change.
B
I
think
regressing
that
change
and
reverting
that
change.
It's
probably
the
right
thing
to
do.
Good
observation.
A
Yeah
plus
one
for
me
too,
okay,
that's
good!
I
think
that's
good
to
go
then
I
just
I
know
I
I'm
always
want
to
be
very
careful
when
I
revert
a
previous
change
that
we'd
agreed
to,
but
I
think
there's
enough
consensus
here
that
I'll
remove
the
hold
and
let
this
one
go
in
all
right.
Next
up,
I
just
gonna
run
through
the
v050
milestone
and
actually
before
before
I
do
that
I've
been
talking
with
other
maintainers.
A
Our
release
process
is
slowly
evolving,
we're
getting
slightly
better
at
this,
but
it
still
is
at
the
place
where
we
basically
need
two
active
maintainers
online.
At
the
same
time,
whenever
we're
hitting
release
and
life
happens-
and
we
don't
have
that
many
maintainers
right
now,
so
we
we
needed
to
find
a
time
where
everyone
was
gonna,
be
well
as
many
people
as
possible
were
going
to
be
online
and
I
think
just
logistically-
that's
not
going
to
be
tomorrow.
A
We
had
really
hoped
it
was
going
to
be
tomorrow.
I
think.
Instead,
what
will
likely
happen
is
we'll
cut
rc2
either
today
or
tomorrow,
and
we
will
aim
for
the
final
release
on
wednesday
and
I
know
everyone's
in
a
different
time
zone.
But
what
I
mean
is
approximately
48
hours
from
now
will
aim
to
have
v0.5.0
released
so
that
that's
the
goal
with
that.
Let's
run
through
this
milestone
and
make
sure
we
haven't
missed
anything
too
significant.
A
The
first
one
is
this
docs
update.
I
I
really
appreciate
everyone
who's
helped
here
I
know
keith,
you
did
some
work
here.
Emily
has
done
a
lot
of
the
work
on
this
one
and
there's
one
tiny
bit
left
and
I
think
emily
has
volunteered
to
take
it.
But
if
not,
we
can
make
sure
that
that
someone
can
it's
just
a
tiny
little
bit
left
on
this
one
to
document
how
you
install
experimental
crds
instead
of
just
standard.
A
That's
that's
the
last
little
bit
on
this
one,
I'm
not
too
worried
about
this,
and
it's
not
like
that
can
happen.
Post
release
if
necessary,.
A
Next
up,
this
is
a
bigger
one
and
nick
maybe
I'll
hand
it
off
to
you,
because
I
know
you've
been
doing
a
lot
of
work
on
this
pr
and
I've
kind
of
lost
track
of
the
current
state
but
yeah.
Maybe
you
can
give.
D
Here
I
mean
the
the
because
there's
a
few
changes
here:
we've
moved
changed
some
of
the
reasons
around
for
having
an
individual
back
end,
ref
being
invalid
to
the
actual
backend
ref
godoc,
and
then
we've
put
the
rules
for
handling
invalid
backer
drifts
in
the
the
background
field
of
the
http
route
rule.
So
that
means
that,
because
this
basically
means
that,
in
the
sort
of
part
where
there's
a
list
of
back
end
refs,
we
can
say
hey
if
you've
got
zero
back
end
refs,
here's
how
it
works.
D
If
you've
got
you
at
least
one
here's
how
it
works
and
if
you've
got
like
there
is
a
case
where
you've
got
one
at
least
one
valid
back
and
left,
and
then
at
least
one
invalid
there's
a
specific
behavior
that
we
have
to
mandate
there.
So
I've
sort
of
moved
things
around
a
little
bit
to
do
that.
I
think
that's
okay,
it's
just
in
the
getting
the
performance
test
right
to
test
a
bunch
of
this
stuff
as
much
as
possible,
and
the
other
thing
that
we've
changed
here
is
that
we've
changed.
D
We've
changed
some
of
the
error
codes.
It
used
to
be
404s
everything
we
moved
to
500
for
a
lot
of
things,
so
everyone
will
need
to
update
that.
That's
why
I
wanted
to
that's
why
I
wanted
to
make
sure
that
there's
you
know
the
conformance
tests
reflect
the
new
behavior.
I
think
I've
mostly
got
that
steve
called
out.
There's
one
one
thing
that
I,
because
I
changed
some
stuff
in
the
conformance
test
and
that
breaks
a
couple
of
other
ones.
A
Yeah
I'll
say
personally
for
me:
I
I've
taken
some
time
to
run
through
this,
and
thanks
for
this
is
a
massive
pr
heavy
lift.
I
appreciate
you
taking
this
one
on
and
actually
taking
the
time
to
update
and,
I
think,
even
add
conformance
tests.
If
I'm
remembering
correctly
on
this
one
yeah
yeah.
D
A
D
I
think
it
definitely
will
need
a
call
out
in
the
in
the
change
log
that
yeah
behavior
has
changed
a
bit
yeah
I'll,
try
and
update.
The
first
comment.
D
A
Yeah-
and
I
think
I
think
our
last,
like
our
first
release
candidate-
included
the
the
change
to
500.
I
think
it
was
a
chain,
but
this
really
clarifies
a
lot
that
was
kind
of
left
murky
in
that
initial
one.
So
it's
not
you
know
from
the
outside
in
it's
not
a
huge
change.
It's
just
clarifies
a
lot
and
makes
it
part
of
conformance,
which
I
think
is
awesome.
F
Hi,
sorry,
sorry
to
jump
in
like
this,
but
I
think
it's
relevant.
I
I
had
an
audio
glitch
and
I
missed
whether
we
were
gonna
do
an
rc2
and
then
the
oh
five.
Oh.
A
Yeah
thanks
for
thanks
for
asking,
I
tried
to
write
it
out
here,
just
because
it's
it's
easy
to
miss
these
things.
But
my
goal
here
is
to
release
rc2
there's
a
chance.
It
could
happen
today
but
likely
tomorrow
and
then
a
final
release
on
wednesday,
and
that's
just
you
know
that
there's
a
limited
set
of
maintainers
do
do.
Let
us
know
if
you
are
interested
in
becoming
a
maintainer
and
getting
on
that
track.
A
We
are
always
up
for
more
help,
but
because
we
have
a
limited
set
and
we
really
need
you
know
several
around
to
to
get
a
release
going
wednesday's
our
best
day.
For
that.
A
All
right
I'll
keep
on
moving
through
this
list.
Shane
has
done
an
awesome
job
with
the
blog
post
and
I
think
you
added
a
comment
on
that
pr,
but
I'll
I
linked
it
in
the
agenda
as
well.
A
lot
of
that
discussion
and
feedback
has
moved
over
to
the
kubernetes
website.
Pr,
we
will
mirror
the
blog
post
that
we
have
on
gateway
api
on
gateway
api
over
to
kubernetes.io
blog
we've
gotten
a
lot
of
great
feedback
on
this.
One
tim
always
has
great
docs
feedback.
A
I
love
getting
reviews
and
his
feedback
and
I
think
they're
yeah.
I
love
some
but
yeah.
If
you
have
thoughts,
if
you
care
about
how
we're
presenting
this
release,
I
would
love
to
get
your
comments
on
this
one,
but
shane
has
done
a
great
job.
Getting
this
blog
post
in
it
ready
to
go.
A
D
Yeah
yeah.
Basically,
so
I
one
of
the
reasons
I
haven't
opened
a
pr
for
this
yet
is.
I
was
evaluating
if
I
should
do
if
we
should
do
performance
tests
for
this.
This
is
basically
saying
everywhere,
where
we
use
an
enum
queue
builder
tag.
We
need
to
have
something
there
saying
hey.
We
might
add
new
values
to
this.
You
need
to
handle
unknown
values
without
crashing.
D
I
wanted
to
see
if
it
would
be
possible
to
make
a
course
test
that
checks
that
everybody
can
handle
unknown
values
without
crashing,
but
it's
surprisingly
difficult
because
it
involves
forcing
forcing
incorrect
values
into
cube
past,
both
layers
of
validation,
that
we
have
both
open
api
validation
and
the
validating
workbook,
which
is
hard.
D
So
I
think
I'm
just
going
to
leave
this
as
a
I've
got
the
change
mostly
done
I'll,
open
a
pr
today,
I'll
I'll
leave
this
as
just
a
doc
like
a
doc
string,
update
now
to
say:
hey,
remember
that
for
enum
values,
if
you
know,
if
there's
something
in
there,
you
don't
rec,
you
need.
Basically,
you
need
to
have
a
switch
statement
with
a
a
yeah
with
a
default
case
handler
that
says
hey.
I
can't
do
anything
with
this
yeah
yeah.
We
could.
D
I
kind
of
I
kind
of
I
thought
about
that
as
well
by
bobby
suggested
in
the
chat
that
we
have
like
an
invalid
and
invalid
value
that
we
that
we
allow,
through
the
things
and
then
test
for
that,
but,
like
I'm
kind
of
like
well,
then
it's
if
we
allow
it
through
the
validations,
then
it's
a
valid
value,
not
an
invalid
one
right,
so
so
yeah.
I
I
think
for
now.
I
I'd
like
to
pump
this
the
actual
figuring
out
how
the
conformance
works
down
the
road.
D
D
Hey
yeah
effectively
make
sure
you're
handling
this
with
a
switch
statement
with
a
default
and
the
default
is
hey.
I
don't
know
what
to
do.
Basically
so
yeah
yeah
this.
This
is
because
you
know
the
the
api
convention
sort
of
say:
hey,
be
careful
with
enums.
You
know,
there's
a
implicit,
this
kind
of
an
implicit
understanding
that
when
you
have
an
enum
that
it's
closed
over
additions,
so
we're
just
being
specific
that
at
the
enums
that
we
have
here
are
not
closed
for
editions.
D
A
Yeah
thanks
for
catching
this
and
adding
it
to
the
milestone
I
yeah
it'll
be
good.
You
know,
like
you're
saying
those
api
conventions
are
are
a
little
tricky
and
if
we
don't
say
this
up
front,
we'll
regret
it
later
so
glad
glad
you're.
Taking
this
one
on.
D
A
Yeah
this
next
one
is
just
actually
the
next
few
are
just
prs.
The
examples
to
v1
beta
1
wanted
to
wait
until
we
actually
released
v1
beta
1
before
we
updated
the
examples,
but
it's
ready
to
go
thanks,
emily.
A
The
named
address
we
just
covered
that
earlier,
and
this
one
also
is
one
we
covered
earlier.
It's
fixing
the
issue
we
discussed
above,
so
that
is
everything
in
the
milestone.
I
feel
pretty
good
about
where
we
are
and
again
goal
is
to
hit
rc
tomorrow
in
the
next
24
hours
and
then
in
the
next
48
hours
to
do
a
final
cut
of
vo
50..
A
Any
any
last
comments
or
questions
on
this
release
process.
Before
we
move
on.
A
Great
okay,
keith:
I
think
it's
up
to
you,
service,
mesh
stuff.
H
Yeah
appreciate
it
and
thank
you
to
everybody.
Who's
been
involved
with
this
process
so
after
conferring
with
the
steering
committee
on
thursday,
their
guidance
for
kind
of
what
we're
wanting
to
do
here
is
to
kind
of
keep
it
within
the
confines
of
gateway
api
which
we're
happy
to
do
the.
H
H
I've
talked
to
up
until
this
point
has
a
strong
opinion
on
naming,
so
I've
got
two
options
here:
one
kind
of
cheeky
and
then
one
kind
of
more,
more
chill
gateway,
api
for
mesh
management
and
administration
or
gamma,
and
then
just
get
api
mesh
exploration
group,
since
the
term
working
group
is
not
has
has
not
been
blessed
for
our
usage
in
this
use
case.
So
the
purpose
of
this
topic
is
just
to
kind
of
redirect
some
of
the
focus
for
this.
H
It's
not
going
to
be
it's
not
going
to
be
at
the
kubernetes
steering
committee
level.
Just
submitting
to
y'all
at
the
gateway
api
level
to
figure
out
what
you
all
want
to
how
you
want
to
move
forward
with
this.
D
I
love
gamma,
I
love
vida
whimsy
and
naming
that's.
I
love
name
huge
plus
one
from
me,
plus
it's
easy
to
say.
A
Yeah,
I
mean
I'm
a
fan.
I
I
I
like
both
of
these
names
but
gamma
certainly
more
fun.
A
So
I
yeah
I'll
support
that
I
just
I
just
want
to
welcome
you
to
gateway
api
community
and
I
know
you've
been
contributing
for
for
a
bit,
but
just
I
I'm
excited
to
see
where
mesh
goes
and
I'm
excited
that
we
have
people
volunteering
to
actually
lead
that
effort
and
something
that
I
know
we've
been
talking
about
or
had
in
the
back
of
our
heads,
but
never
had
anyone
to
just
drive
it
forward,
and
so
I'm
excited
about
that.
C
So
so
I
had
a
question:
are
we
thinking
of
starting
a
new
set
of
meetings
or
we
can
just
use
this
set
of
meetings
and
then,
in
terms
of
slack
channel,
do
we
need
a
new
stack
channel
or
we
just
reuse
the
existing
one.
H
Yeah
great
question,
so
the
kind
of
perspective
that
we've
had
so
far
and
we're
open
to
opinions
and
thoughts
in
the
community,
of
course,
but
the
the
kind
of
idea
we've
been
leading
with
so
far
is
that
we
really
don't
want
to
distract
from
any
of
the
work
happening
kind
of
in
the
main
gateway
api
meeting.
H
There
are
a
lot
of
meshes
a
lot
of
folks
who
have
been
who
are
interested
in
wanting
to
to
be
involved
here,
which
is
a
good
thing,
but
we
definitely
don't
want
to
dilute
the
the
signal
to
noise
ratio
happening
here
for
the
kind
of
primary
ingress
use
cases,
and
so
a
a
we've
kind
of
been
looking
for
a
new
meeting
schedule,
as
well
as
a
a
kind
of
a
dedicated
slack
channel
for
communication
kind
of
within
this
effort,
and
then
any
changes
that
we'd
be
proposing
to
api
or
any
new
resources
we'd
like
to
consider
adding
to
the
gateway
api
would
be
submitted
through
gateway
enhancement
proposals
and
the
final
decision.
C
Yeah
I
I
just
had
a
alternate
proposal,
which
is
you
might
want
to
just
do,
of
course,
everyone's
free
to
kind
of
meet
offline,
but
to
do
most
of
because
this
group
meets
every
week,
which
is
a
fairly
high
cadence,
so
like
I
can,
I
can
just
see
that
it
might
just
be
okay
to
use
this
meeting,
especially
since
everyone
is
most
participants
here
are
actually
care
about.
Both
topics.
F
Hi
I'd
be
plus
one
on
bowie's
counter
proposal.
I've
got
too
many
slack
channels
and
meetings
and
stuff
already.
F
E
Say
is
I
mean
if
everyone
here
thinks
that
they,
I
think
the
assumption
has
been
that
the
mesh
folks
are
kind
of
somewhat
separate
from
the
ingress
folks.
If
everyone
here
is
like
I'm,
just
gonna
have
to
join
that
meeting
now
as
well,
then
I
kind
of
agree,
if
not,
I
would
say
like,
at
the
very
least
in
the
first
few
weeks
or
months
like
we're
going
to
have
a
lot
to
talk
about,
while
we're
kind
of
getting
these
off
the
ground,
certainly
even
if
they're,
not
overlapping
groups.
E
I
feel
like
in
a
you
know,
month
months,
maybe
a
year
time
span
like
it
would
make
sense
to
fold
it
in
probably,
but
we're
going
to
have
probably
full
agenda
mesh
every
week,
for
you
know
the
foreseeable
future.
If
we
do
it
here
which,
if
everyone
wants
that,
like
it's
fine
with
me
personally,
just
be
warned.
H
Plus
one
to
that,
I'm
not
sure
if
a
lot
of
folks
have
had
a
chance
to
look
at
our
get
our
mesh
exploration
document,
but
it's
pretty
thick
and
it's
just
the
beginning.
So
I
agree
with
everything
you
just
said,
john.
If,
if
that
is
the
case,
then
yeah,
I'm
sure
I'm
keeping
in
this
meeting.
But
there's
gonna
be
a
lot.
A
So
I
so
here
I
have
a
few
thoughts
here.
I
definitely
think
that
there
is
a
point
potentially
not
far
from
now,
where
everything
belongs
in
the
same
meeting
all
over
again
like
I.
I
think
that
is.
That
is
definitely
where
we're
heading.
A
I
am
open
to
trying
anything
for
some
period
of
time,
because
you
know
you
never
know
until
you
try
right
what
I'll
say
is
it's
taken
us
a
long
time
to
get
to
this
beta
release
and
we've
had
basically
full
agendas
for
every
meeting
we've
had
every
week
for
a
long
time,
and
we
haven't
really
like
mesh-
has
just
kind
of
grazed
the
surface
of
a
couple
meetings
you
know
on
the
edge
on
the
periphery.
A
I
can't
predict
future
meetings.
It
may
be
that
after
we
hit
release
on
this,
the
ingress
discussion
kind
of
dies
down,
but
I
know
we've-
we've
just
kind
of
you
know
claimed
bankruptcy
on
grpc
route
on
route
delegation
of
oh
we'll
get
to
that
later
and
later
was
supposed
to
be
right
after
this
release
and
this
release
kept
on.
A
But
like
there's
things
in
the
agenda,
we
just
haven't
had
time
for
yet,
and
I
completely
believe
that
this
mesh
topic
is
is
sufficient
in
scope
and
scale
and
everything
to
consume
full
hour-long
meetings
every
week
for
some
period
of
time.
A
So
I
I
don't
want
to
make
the
any
kind
of
final
decision
here,
but
my
bias
would
be
to
start
on
a
separate
track
until
we
we
have
a
bit
more
stability
around
what
mesh
for
gateway
even
means
and
then
maybe
start
to
merge,
as
we
see
that
both
meetings
are
kind
of
not
filling
up
their
full
time
slot
and
could
fit
back
together
again,
but
that
this
is
just
my
perspective.
I'm
open
to
others.
C
Yeah,
I
think,
like
long
term,
we
should
probably
see
the
two
joined
together.
Maybe
this
initial
kickoff
is
probably
a
little
bit
time
intensive.
I
I,
the
only
issue
is
like
I
do
see,
for
example,
those
two
topics,
grpc
route
and
without
delegation-
are
actually
relevant
for
both.
D
It
feels
to
me,
like
an
important
part
of
getting
this
started,
is
sort
of
working
through
the
the
like
how
the
mechanics
of
what
your,
what
what
you
all
are
being
the
service
mesh
group
like
to
be
honest,
I'll,
probably
be
involved
anyway,
but
that
one
wanted
you
know
want
to
do
like.
Is
it
that
way?
D
You
know,
we've
talked
we've
talked
on
and
off
a
little
bit
about
having
a
mesh
as
like
a
root
resource
instead
of
a
gateway
or
something
like
that,
like
you
know
talking
through
sort
of
how
would
that
work?
You
know
what
did
we
learn
from
building
gateway?
You
know
that
that
is
a
separate
and
involved
enough
discussion
that
it's
going
to
take
a
while,
like
it's
going
to
be
more
than
one
a
couple
of
one-hour
slots
to
to
get
to
agreement.
D
On
that,
I
think,
and
so
like
I'm
in
favor
of
you
know
some
I
like,
even
if
we
call
them
like
extraordinary
meetings
of
of
you,
know
the
broader
project
that
we
just
dedicate
to
that
and
just
say
hey.
Let's
do
let's
do
a
few
weeks
of
extraordinary
like
hour
here
or
two
hour,
even
like
meetings
like
you
know,
because
I
I.
D
Discussions
will
get
in
depth
and
an
hour
won't
be
enough
time.
You
know,
and
so,
like
a
couple
of
those,
I
think
will
set
us
up
to
then
to
then
sort
of
be
ready
to
write
a
gap
that
will
then
that
will
then
and
then
once
that,
once
the
initial
sort
of
gap
of
like
here's,
how
we're
going
to
deal
with
mesh
is
done,
then
I
think
that
it'll
be
much
easier
to
bring
it
back
in,
but
I
think
that
doing
it
separately
until
then
and
having
it
just
be
hey.
D
These
are
extraordinary
meetings
in
the
like
literal
sense
of
determining
that
they
are
yeah
extraordinary
yeah
meetings.
G
What
is
this
the
last
item
we
have
on
our
agenda
for
today?
H
So
it
would
probably
be-
and
john
keep
be
honest
on
this,
linking
the
dock
for
folks
to
put
it
here
in
the
chat
for
folks
to
peruse,
based
on
the
discussion,
we've
been
having
so
far,
we'll
probably
be
picking
a
a
set
of
semantics
for
what
it
means
to
attach
routes
to
things.
What
is
the
mesh
in
the
gateway
api?
What
are
the
attachment
resources,
or
whatever
the
attachment
targets,
rather
for
the
x-ray
resources?
H
Upgrades,
not
upgrades,
but
you
know
just
you
know:
mesh
domain
object,
ideas
and
figuring
out
what
the
best
best
path
forward
for
that.
That's
the
immediate
the
immediate
goal
of
conversation
and
we've-
we've
really
only
scratched
the
surface
towards
that,
as
you
might
be
able
to
tell
in
this
talk.
G
Yeah,
that's
very
big,
I'm.
It
feels
very
big
and
nebulous
in
my
head.
It's
it's
certainly
something
I
could
see.
I
can
kind
of
see
it.
Both
ways,
like
part
of
me,
wants
to
just
like
add
mesh
stuff
to
the
agenda
and
just
if
we
start
to
feel
overloaded,
then
deal
with
that.
You
know
make
a
breakout
session,
but
the
other
part
of
me
is
like
I
wouldn't
mind
like
I'm.
I
have
both
ingress
and
mesh
in
my
purview,
I'm
going
to
be
a
part
of
the
mesh
stuff
that
we
do.
G
I
can
agree
with
the
notion
that
we
may
not
want
to
have
a
bunch
of
extra
meetings,
but
I
see
a
lot
of
weight
to
this
and
I
could
say
why
don't
we
just
either
start
adding
something
to
the
meeting
we
have
or
make
one
meeting
and
see
if
we
you
know
where
that
goes,
I
don't
know
I'm
kind
of
in
the
middle
on
it.
I
would
almost
be
happy
to
spend
a
good
chunk
of
the
rest
of
this
meeting.
Talking
about
that
topic
in
particular,
and
then
going
from
there.
H
B
I
think
we
should
decide
what
we're
how
we're
going
to
handle
this
going
forward
before
we
start
doing
that.
I
I
think,
as
somebody
else
said,
there's
there's
going
to
be
a
lot
of
us
that
have
interest
in
both
aspects
of
this.
Maybe
that
you
know
the
company
we
represent
may
have
you
know
one
person
in
in
each
camp
or
maybe
the
same
person
in
both
camps,
but
I
think
that
echoes
somewhat.
What
rob
was
saying
about.
B
You
know
that
we've
got
some
big
lifting
still
to
do
on
the
ingress
piece
of
this
with
about
delegation
and
grpc
and
and
other
issues,
and
I
think
we
would
really
slow
us
down
on
progressing
that
stuff
if
we
try
to
handle
the
mesh
use
case
issues
within
these
meetings,
as
you
know,
as
rob
was
mentioning
we've
pretty
much
always
filled
virtually
every
weekly
meeting,
with
a
full
slate
and
and
oftentimes
run
out
of
time.
So.
G
I
get
that
I
get
that
I'm
just
I'm
seeing
a
different
perspective
too,
like
I
said,
I'm
kind
of
on
the
fence,
but
I'm
seeing
a
different
perspective
too,
where
we
just
spent
a
lot
of
time
in
this
meeting
and
recently
with
like
a
post
and
trying
to
get
a
work
group
started,
we
spent
a
lot
of
time
trying
to
do
the
organizational
part
that
people
are
saying
need
to
come
first,
and
that
has
lost
a
lot
of
time
too.
So
it
might
be
good
to
just
start
diving
in.
I
don't
know
it's
a
suggestion.
G
H
No
no
argument
from
me
there
I'm
ready
to
get
to
work
as
well
and,
like
I
said
it's
whatever
is
going
to,
you
know,
be
most
beneficial
for
the
community.
You
know
I
I
absolutely
hear
the
intersecting
use
cases
and
maybe
the
the
answer
to
that.
Is
that
we're
just
if
we
do
split
it
off
we're
careful
about.
You
know
what
we
what
we
bring
to
the
api
meetings.
H
Maybe
we
bring
a
subset
of
conversation,
topics
from
mesh
meetings
to
the
greater
gateway
api
meeting,
maybe
to
clarify
the
use
of
a
certain
resource
order
to
propose
something
there
but,
like
I
said,
no
super
strong
opinions
either
way
whatever
the
community's
gonna
make
us
make
it
the
community
most
effective
is
what
I'm
for.
B
So
what
I
would
suggest
sorry,
real,
quick
I'd
suggest
that
the
mesh
those
are
interested
in
the
mesh
use
case
initiate
some
independent
meetings
to
start
putting
things
together
and
reviewing
proposals.
I
think
things
like
this
gateway
api
mesh
proposal
that
you
that
keith
you
you
just
linked
in
the
chat.
I
think
you
know
that
stuff
should
be
shared
on
the
slack
channel
for
gateway
api.
A
I
think
one
thing
to
keep
in
mind
with
what
has
been
proposed,
even
if
it
is
a
separate
meeting
that
we
start
with,
is
that
we're
still
talking
about
gaps,
we're
still
talking
about
things
that
would
come
back
here
and
be
proposed
and
discussed
and
approved,
but
mesh
is,
from
my
perspective,
much
less
def,
well-defined
than
say
ingress,
right
and
in
terms
of
scope
and
in
terms
of
what
what
is
you
know,
what
is
ingress
routing
versus
what
is
mesh
routing
there's.
You
know
that
it's
a
little
bit
broader
or
whatever.
A
A
Very
you
know
unstructured,
and
just
this
is
a
working
meeting
where
we're
just
running
through
proposals,
whatever
very,
very
loosely
and
actually
working
through
like
making
making
edits
as
we
go
kind
of
thing,
and
I'm
not
trying
to
suggest
how
you
do,
how
anyone
would
do
a
service
focused
meeting,
but
that
that's
what
it
feels
like
like
there's
just
there's
so
much
to
do
just
to
form
a
sensible
proposal
to
then
discuss
at
something
like
this.
That's
my
working
theory,
at
least
as
a
starting
point.
A
I
I
echo
what
shane
said
and
that
I
and
and
and
keith
and
everyone
that
we
would
just
like
to
get
started
and
move.
But
you
know
my
personal
preference
is
just
to
make
sure
that
we
don't
disrupt
this
project
too
much
and
our
progress
towards
ga
and
everything
else.
A
I
would
personally
prefer
starting
separate
and
then
working
towards
merging
those
as
things
stabilize
and
become
a
little
bit
more
clear.
D
I
am
plus
one
on
something
like
that,
just
like,
I
said
extraordinary
meetings,
working
meetings
for
now
and
then
figure
it
out
as
we
go.
H
Awesome:
oh:
go
ahead.
Toby.
D
Yep
made
the
meeting,
I
think,
if
you,
if,
if
it
works
out,
if
we
can
make
a
case
for
another
another
slack
channel,
that
makes
sense
to
me
too
and
again
the
the
idea
there
being
that
that
is
for
the
the
nitty
gritty
discussion
rather
than
the
you
know,
and
then
and
then
bringing
gifts
back
rather
than
lots
of
stuff.
Just
to
keep
keep
the
signal
noise
in
the
main
channel
a
bit
higher
yeah.
It's
probably
going
to
need
to
be
called
like
something.
I'm.
C
D
C
I
I
might
have
an
unusual
viewpoint
on
this,
but
I
I
don't
know
I
don't
see
the
the
case
where
these
two
things
are
coming
together
in
the
future.
Only
because
we
just
had
this
similar
discussion
at
work
today.
We're
trying
to
keep
these
two
things
separate.
I
So
can
you
just
give
me
and
anyone
else
who
who's
interested?
We
might
be
the
you
know,
fewer
of
us
here,
the
the
reasoning
behind
why
service
mesh
and
gateway
api
are
like
bread
and
butter.
H
Yeah,
I
can.
I
can
take
that
so
a
lot
of
what
spurred
this
conversation,
this
this
effort
was
the
fact
that
service
mesh
facing
apis
like
smi
service
mesh
interface,
have
a
very
similar
api
service
to
get
api
same
kind
kind
of
routes
resources.
H
You
know
a
network
is
a
network
as
a
network.
Tcp
is
tcp
or
tcp,
and
the
the
idea
behind
this
is
you
know,
gabe
api's
done
a
really
great
job
at
describing
the
way
that
network
flows
within
the
community's
context
and
the
resources
there
are
similar
enough
between,
like
both
sets
of
smi
interfaces
and
and
your
api
interfaces
are
similar
enough,
that
why
not
just
have
one
and
that's
kind
of
what
we're
pursuing
yeah.
H
That
might
lead
to
some
some
desire,
some
some
changes
and
that's
what
we
want
to
explore
and
and
maybe
submit
those
informal
gaps,
but
at
the
end
of
the
day,
we'd
love
for
kubernetes
users
to
be
able
to
configure
their
mesh
and
their
ingress
using
the
exact
same
resources
and
kind
of
just
collapse.
The
community
a
bit
does
that
make
sense.
I
It
makes
sense,
but
unless
you're
coming
from
the
standpoint
of
a
someone,
who's
who's
working
with
ingress
controllers
and
has
never
worked
with
service
mesh,
so
it
does.
I
mean
a
network.
Is
a
network
until
you
get
down
to
you
know
what
are
the
messages
that
are
passing
back
and
forth?
Are
you?
Are
you
routing
connections?
Are
you
routing?
B
I
I
think,
they're,
I
understand
what
you're
saying,
but
I
think
there's
a
couple
of
things.
One
is
that
a
service
mesh
has
to
have.
You
have
to
have
a
way
to
get
this
traffic
in
and
out
of
the
service
mesh.
It's
not
just
like
in
you
know
another
extension
of
the
ip
network,
where
you
can
just
you
know,
directly
communicate
to
things
on
the
service
mesh
without
some
function.
Providing
in
that
ingress
point.
B
The
other
thing
is
that
a
lot
of
folks
that
are
companies
which
should
say
that
are
involved
in
the
gateway
api
are
also
companies
providing
service
mesh
solutions.
So
we
you
know
there
for
those
of
us
that
are
in
that
position.
B
There's
a
there's,
some
good,
there's
some
strong
arguments
to
be
said
that
to
use
the
same
overall
api
to
handle
both
the
east
to
west
and
the
north
to
south
traffic
configuration.
So
I
think
there's
there's
pretty
good
arguments
for
for
why
they
do
that.
D
I
feel
like
at
the
largest
level,
the
the
the
big
advantage
of
having
the
the
gateway
api
described
both
the
ingress
case,
and
the
mesh
case
is
that
it
lets
you
slide
from
from
the
you
know,
I'm
hand
this
gateway
handles
the
the
just
the
ingress
case
and
the
sort
of
the
I
use
very
loosely
simple
use
case,
and
then
it
lets
you
sort
of
you
know
theoretically,
add
on
bits
as
you
need
to
go,
provided
your
implementation
can
handle
it
like
having
the
same
description.
D
Language
like
means
that
for
the
same
sort
of
set
of
broad
problems,
really
it
speaks
to
me
that
it
it
would
mean
that
in
in
the
magical
world
we
had
where
all
of
this
was
fully
implemented,
then,
theoretically,
you
could
install
an
implementation
that
does
both
start
with
just
using
the
ingress
stuff
and
then
end
up
with
the
full
service
mesh
bits,
and
that,
I
think,
is
the
sort
of
the
end
game
that
that
we
should
all
hope
to
to
end
up
with.
Personally
sorry,
john.
C
E
I
can
do
istio
right.
It
does
kind
of
the
same
thing
that
gateway
api
did
for
ingress,
but
at
a
wider
scale.
So
all
these
custom
integrations
can
just
create
a
route
and
if
that's
handled
by
mesh,
that's
great,
if
that's
handled
by
ingress,
that's
cool
as
well.
You
know
like
east
geo,
for
example.
That's
where
my
background
is:
we've
used
the
same.
E
Apis
almost
completely
overlap
between
the
two
and
I
think
there
there
are
obviously
differences
between
them,
but
the
vast
majority
of
stuff
we
want
to
do
is
the
same
like
we
want
to
be
able
to
route
match
and
filter,
and
you
know
I'll.
Do
these
things
to
http
traffic?
We
want
to
add.
This
is
not
part
of
spec
now,
but
authorization
policies,
for
example,
could
be
something
to
explore
in
the
future.
All
those
things
are
common,
regardless
of
where
we're
trying
to
run
them.
A
Is
that
we've
kind
of
made
it
modular
by
design
right
and
so
routes
hold
the
vast
majority
of
logic
right
and
they
can
be
attached
to
anything
and
so
far
we
focused
on
gateway
right,
like
a
route
is
attached
to
a
gateway,
and
that
represents
an
entry
point
into
your
network,
for
example,
or
it
could
represent
many
things
I
know,
but
that
gateway
can
represent
many
things
with
that
said,
you
know,
there's
been
some
interesting
discussion
about
egress
right
like
what,
if
you
use
routes
to
represent
the
way
out
of
your
cluster
or
your
network
and
similar
for
mesh,
and
I
think
our
routes
are
really
the
core
of
this
api,
despite
the
gateway
api
name,
but
I
think
there's
some
really
cool
promise,
an
interesting
promise
for
mesh
and
I'm
just
excited
to
see
what
it
looks
like
I
I
don't
know
I
don't
have
the
full
vision
yet,
but
I'm
excited
to
see
what
they
come
up
with.
A
And
yes,
I
I
agree
with
bowie.
Yes,
we
we
should
have
called
this.
The
the
routing
api
route
api,
something,
but
I
can't
rename
it
again.
One
rename
and
you're
done.
Yeah.
A
A
Finally,
I
just
two
or
three
days
ago,
I
finally
removed
what
I
think
is
the
last
reference
to
service
apis
from
our
code,
so
it
I
think
it's
finally
gone,
maybe
but
we'll
probably
still
find
something
somewhere
down
down
the
road.
A
But
with
that
said,
I
want
to
bring
this
back.
I
think
we
have
clear
next
steps:
baby
keith
john
mike,
if
you
want
to
come
up
with
some
suggested
times
for
an
initial
meeting,
I
don't
think
this
meeting
needs
to
run
indefinitely.
A
I
think
the
goal
is
to
merge
these
back
together,
but
just
to
start,
if
you
want
to
suggest
some
times
and
and
we
can
get
started
with
the
separate
meetings,
I
will
probably
be
one
of
many
that
attends
both,
but
no
no
need
don't
feel
like
you
need
to
to
attend
both,
but
if
you're
interested
in
both
mesh
and
the
main
gateway
api,
I
think
we'll
probably
start
with
two
meetings,
and
then
I
think
we
agreed
to
start
in
the
same
slack
channel
and
use
threads
a
lot
and
if
that
becomes
overwhelming
split
out,
does
that?
J
Yep
cool
I'll
make
my
my
one
play
to
say
that
if
you
have
something
that
needs
a
discussion
longer
than
fits
in
like
30
minutes,
please
put
it
in
like
a
github
issue,
at
least.
Eventually,
I
don't
know
the
slack
thread.
Ux
is
just
painful
for
me,
like
basically
it's
everything
that
I
care
about,
gets
lost
when
it
gets
pushed
over
random,
but
new
threads
that
have
just
been
updated
more
recently
yeah.
I
feel
that
pain.
H
Maybe
this
is
a
a
reason
to
push
these
github
discussions
or
whatever
the
whatever
that
that
that
product,
that
price.
J
Is
well
yeah,
that's
basically
what
is
already
in
use
for
most
of
the
gateway
api
stuff.
So
actually,
yes,
good
job
on
that
that
has
made
like
the
longer
more
complex
discussions
like
much
easier
to
parse
through
than
some
other
like
communities
so
yeah.
Please
do
use
github
discussions
for
complex
things.
J
We
have
to
find
things
for
alpha
and
beta
first
and
then,
when
we're
clear.
H
Very
nice,
but
so
yeah
next
step,
sound
good
to
me
just
calling
out
something
john
asks
in
the
chat:
can
we
get
a
label
or
something
for
mesh
on
github
I
plus
one
that
I
think
that
would
be
very
useful
for
for
both
parties
here
and
then.
Second
on
my
list
is
once
we
get
those
times.
Do
you
want
us
to
just
ping
the
slack
channel
ping
y'all
directly?
Okay,
I
see
nods
for
ping
slap
channel
and.
H
Okay,
yeah
good
call
out
I'll
I'll
take
that
as
an
action
item
for
my
stuff,
because
I've
been
doing
the
whole
working
group
thing
beforehand,
I'll
get
that
bro
I'll
get
the
decisions
for
for
this
meeting
kind
of
tacked
up
in
a
draft
and
then
once
we
get
the
times
hammered
out,
hopefully
that
that
announcement
will
have
a
first
meeting
time
and
day
here.
If
you're
interested.
Please,
please
show
up
and
we'll
try.
C
C
Thing
put
the
meeting
info
on
our
community
contrib
page
on
the
main
dock
site.
A
Yeah
we
could
so
let
me
I
don't
have
a
great
link
for
it,
but
we
have
a
community
page
on
gateway
api
website.
It
also
includes
an
embedded
google
calendar
of
all
sig
network
meetings,
so
that
means
we
should
add
this
to
the
sig
network
meeting
calendar.
So
anyone
who's
in
sig
network
gets
an
invite
yeah
just
yeah.
You
know
I
just
ask
around
on
slack
I'm
happy
to
help.
I
know
any
other
maintainers
too,
but
we'll
make
sure
everything
gets
set
up
for
you.
H
D
Also,
I
know
I'm
I
think
I'm
the
only
one,
but
it
would
be
really
nice.
If
the
meeting
could
be
around
about
this
time,
then
I
can
actually
come
if
it's
early.
D
Pacific
time
I
really
like
you
all,
but
I
ain't
I
ain't.
You
know
working
at
2
a.m,
for
you
so
yeah.
If
you
could
do
it
about
this
time.
I
would
very
much
appreciate
it.
A
Cool
all
right:
well,
thanks
everyone
we'll
see
you
on
the
other
side,
we
should
have
a
release
out
and
we
should
have
a
new
meeting
schedule.
A
new
gamma
group
very
excited
thanks
everyone
for
a
great
discussion
and
we'll
see
you
next
week.