►
From YouTube: [SIG Network] Gateway API Meeting (APAC Friendly Time)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Reporting
here
we're
recording
this
is,
I
think,
going
to
be
a
relatively
short
meeting
today
we
are
getting
to
the
wonderful
point
where
we
have
less
and
less
on
our
v1
alpha
blockers
list
and
less
and
less
even
on
our
nice
to
have
list
for
v1
alpha
1..
A
We
also
have
a
bit
more
to
discuss
around
gateway,
naming,
I
think,
that's
mostly
sealed
up
now.
I
just
want
to
cover
that
a
little
bit
before
we
actually
send
that
out
for
a
vote
and
then
a
bit
of
pr
on
issue
triage,
but
again,
there's
not
much
on
any
of
these,
so
this
could
be
a
relatively
quick
meeting.
A
Let
me
get
started
with
this
list
of
blockers
right
now.
This
actually
looks
larger
than
it
is.
I
know
it's
already
pretty
small,
but
part
of
this
is
because
some
of
the
issues
are
being
double
counted,
because
we
have
a
pr
and
an
issue:
that's
they're,
both
being
counted
as
blockers,
so
I'll
start
with
damian's.
First
pr
here
this
does
a
lot.
A
This
was
primarily
trying
to
solve
the
issue
that
we
had.
No
good
way
of
you
know
routing
to
everything.
Matching
all
requests
for
tcp,
tls
and
udp
routes,
and
this
attempts
to
solve
that,
and
it
does
a
lot
more
so
I
you
know,
I
think
it's
worth
going
through
just
a
little
bit
to
see
if
anything
stands
out
here.
This
is
just
a
small
change
of
moving
this
around.
A
I
I
have
a
little
bit
of
feedback.
I
have
been
meaning
to
add.
I
just
looked
at
this
briefly
before.
A
The
one
of
the
things
that
we
had
previously
left
unanswered
is
what
happens
when
forward.
Two
is
unspecified
and
there
are
no
filters.
A
The
idea
is
forward,
two
is
optional
intentionally
and
it's
optional,
because
in
the
future
there
might
be
something
like
a
redirect
filter
where
a
forward
two
just
wouldn't
make
sense,
and
it's
not
something
we
want
to
require
in
that
case,
but
we
do
need
to
clarify
what
happens
if
there's
no
forward
to
no
filters
or
maybe
even
more
specifically,
if
the
filters
we
have
don't
terminate
the
request,
then
we
need
some
kind
of
description
of
what
happens
here.
I
think
there's
a
little
bit
more.
A
The
other
change,
I
think,
is
I
potentially
larger
so
in
tcp
route,
he's
adding
a
max
length
for
rules,
but
there's
one
route
further
down
here.
Let
me
not
jump
too
far
ahead
here.
I
think
it
was.
Maybe
it
was
just
udp
route
where
we
didn't
have
a
yes
udp
route.
A
Wait!
What
okay,
I
okay,
never
mind.
I
thought
he
was
room.
I
think
I
thought
he
was
adding
udp
route
rule.
I
was
wrong,
it
already
existed.
It
was
just
moving
it
down,
so
disregard
what
I
was
going
to
say
here.
So
this
is
actually
a
fairly
large
pr.
We
don't
have
enough,
you
know
I
don't.
I
don't
think
it's
worth
it
to
go
through
every
little
detail
in
this
call.
A
But
if
you
have
time
on
your
own,
I'm
going
to
take
some
time
immediately
after
this
call
and
go
through
and
review
it
and
see
if
anything
stands
out
to
me,
but
this
is
a
key
pr,
because
it
one
cleans
up
some
of
our
documentation,
our
godox
that
is
and
two
it.
It
solves
one
of
our
blockers,
which
is
simply
that
we
have
no
way
to
commute
to
communicate,
match
everything
on
these
routes
which
may
have
been
assumed
before,
but
we
never
actually
said
it.
A
So
I
think
that's
all
that
I'll
say
about
this
one.
I
know
there's
been
some
feedback
here,
but
both
daniel
and
harry
are
not
on
the
call
right
now.
So
I
will
leave
this
one
alone
well
before
I
before
I
leave
it
alone.
Did
anyone
have
any
any
comments
on
this
pr.
A
Cool
all
right,
I
will
keep
on
moving
then.
As
far
as
the
v1
alpha
one
milestone,
you
know,
I
know
it's
very
easy
to
focus
on
what
we've
considered
blockers
and
that's
what
we've
labeled
with
this
critical
urgent
priority,
but
obviously
it
would
still
be
good
to
have
the
rest
of
these
in
it's
just
just
because
they
haven't
been
classified
as
a
blocker
for
release.
A
A
A
We
do
still
probably
need
at
least
one
more
example
here
we
kind
of
have
an
example
of
a
gateway
that
targets
routes
in
multiple
namespaces,
but
it's
not
as
clear
as
it
could
be
out
of.
That
is
the
purpose.
So
we
may
want
to
expressly
call
that
out
in
a
separate
example
yeah,
but
in
general
I
think
we're
getting
awfully
close
here,
but
if
you
have
time
to
pick
up
any
of
these
other
ones,
I
think
all
of
the
ones
that
are
blocking
are
accounted
for,
except
for
this
example.
A
So
if
we
want
to
take
these
on,
rich
has
already
taken
this
one
on
for
documentation,
but
there's
still
a
few
more
that
we
would
really
like
to
have
in
sooner
than
later,
as
far
as
next
steps.
So
if
you
have
any
time,
I
think
these
are
the
ones
to
focus
on
cool,
okay,
we're
just
flying
through
these.
A
Let
me
go
through
gateway
naming
one
last
time
here
we
covered
this
a
little
bit
in
office
hours
yesterday,
just
we.
We
ran
through
the
names
that
had
been
submitted
by
the
community
and
we
ruled
out
a
bunch
of
them
for
various
reasons.
We
should
probably
write
in
some
more
reasons
why
we
ruled
out
some
of
these,
but
we
are
left
with
a
few
that
I
think
are
reasonable.
A
I
actually
I
talked
with
some
of
the
istio
maintainers
actually
john's
on
the
call
and
it
it
sounds
like
they
don't
actually
mind
us
conflicting
with
their
istio
gateway
resource.
So
it
may
not
be
as
big
of
a
deal
as
we'd
initially
thought.
A
B
Know,
what's
going
on,
I
would
say:
is
that,
like
that
the
name
I
sounds
great,
but
we
should
have
a
way
that
users
can
select
like
youtube
that'll
get
without
conflict,
whether
that's
just
not
using
the
same,
alias
or
changing
cube
cuddle,
since
otherwise,
that
would
just
be
a
huge
pain.
I
don't
know
which
one
will
win,
but
whoever
what,
whichever
one
loses,
will
be
a
poor
experience.
So.
A
Yeah
absolutely
so,
I
think,
like
right
now,
harry
has
a
pr
that
would
add
a
short
name
and
I
think
if
we
used
a
distinct
short
name,
a
distinct,
alias
that
istio's
not
currently
using
that
might
be
sufficient.
A
You
know,
as
long
as
you
know,
not
every
service
api's
user
is
going
to
have
sdo
installed
and
not
every
sdo
user
is
going
to
have
service
apis
installed
in
their
cluster,
but
as
long
as
there's
an
obvious
way
to
interact
with
both.
At
the
same
time,
I
think
that's
a
win.
A
And
I
think
there's
a
couple
different
people
on
the
call
that
weren't
on
office
hours
yesterday.
So
if
there
are
any
names
that
are
not
currently
crossed
out
that
you
would
be
unhappy
with
feel
free
to
veto
them
at
this
point,
and
I
can
just
not
include
them
as
part
of
the
names
we
vote
on.
A
But
I
will
always
interpret
silence
as
agreement
with
with
the
names
that
we
have
right
now
on
the
list,
and
so
everything
that
is
not
currently
crossed
out.
I
will,
I
don't
know-
maybe
tomorrow,
but
probably
will
be
early
next
week.
I
will
translate
these
into
something
that
we
can
actually
vote
on
as
part
of
sig
network
and
see
what
what
everyone
else
thinks.
A
I
I
agree
with
that,
and
I
I
hope
that
well,
I
don't
know
what
I
hope
for,
but
that's
I
I
agree
with
that
thought
as
well.
Maybe
if
we
get
overwhelming
support
for
another
name
in
community,
then
you
know
sure
we
can.
We
can
consider
that.
But
what
I'm?
A
What
I'm
honestly
hoping
is
that
this
just
validates
our
original
choice
and
I
think
it's
helpful
to
have
gone
through
the
process
and
gotten
stronger
feedback
from
community
as
far
as
our
name
here,
but
I
I
do
tend
to
agree
that
gateway
probably
is
still
the
best
name
on
this
list,
and
I
imagine
that
as
votes
come
in,
it
will
probably
continue
to
lean
that
way.
But
we'll
see
are
there
any
names
here
that
just
really
feel
terrible
to
you.
D
A
I
I
generally
agree
with
that
consensus.
I
I'm
really.
A
You
know,
I
guess
I
guess
that's
kind
of
the
danger
of
a
vote
is
that
I
I
really
don't
like
any
of
the
alternatives
right
now
and
you
know
we
open
it
up
to
community
to
provide
alternatives
and
even
still
I
I'm
struggling
to
to
see
any
of
them
really
being
used,
but
maybe
we'll
learn
something
like
maybe
maybe
the
community
as
a
whole
really
prefers
another
name,
and
if
we
see
that
feedback,
maybe
we
will.
I
don't
know,
I
don't
know.
A
Okay,
I
will
keep
on
thinking
about
that
and
probably
send
something
like
out
next
week
and
if
and
if
people
don't
want
to
even
open
up
for
voting,
we
can
discuss
that
too.
I'm
not
I'm
not
too
set
on
any
one
way
here.
A
Okay,
so
we'll
move
into
a
pr
triage,
there's
been
a
couple
prs
that
have
come
in
in
the
past
week
and
there's
also
this
app
protocol
pr
from
harry
that
I'll
police
mention
here.
I
added
a
little
bit
of
feedback
on
this
one.
A
Well,
okay,
I've
added
a
bunch,
but
I
just
had
one
tiny
little
note
that
I
added
this
morning
on
this
and
I
think
it's
good
to
go.
I
think
someone
else
has
added
some
feedback
as
well,
but
I
think
I
think,
I'm
generally
happy
with
the
idea
of
an
app
protocol
annotation
and
it's
very
clearly
scoped
now
to
be
specific
to
service
and
specific
to
kubernetes
versions
before
1.18.
A
A
The
he
looks
like
he's
already
updated
some
things
here.
A
One
of
the
questions
that
still
remains
is
this:
so
we're
trying
to
differentiate
a
little
bit
as
far
as
how
we
should
how
http
route
rules
should
match
and
what
is
most
specific,
I
guess,
and
one
of
the
things
we're
missing
is
if
host
name
and
path
match
what
exactly
you
know
like
if
they're
equally
specific,
it
seems
like,
we
would
then
go
to
header
matching
and
how
do
we
determine
which
header
match
combination
is
more
specific
if
header
matching
exists,
and
so
this
suggestion
of
the
largest
number
of
header
matches
is
rather
imprecise
but
seems
like
maybe
our
best
option
here.
A
I
I
don't
know
this.
This
yeah,
I
mike,
I
had
a
great
suggestion
yesterday,
which
was
to
split
this
from
the
longest
matching
combination
of
hostname
and
path
to
hostname,
so
longest
matching
hostname.
First
then
longest
matching
path
and
then
largest
number
of
header
matches
so
kind
of
this
three-step
process.
Here.
A
And
I
think
that
would
also
be
a
great
improvement
and
looks
I
don't
know
if
we
ever
added
that
as
a
formal
comment,
so
maybe
I'll
do
that
after
this
call
yeah
my
guide,
did
you
add
a
comment
around
that
or
I
think
I
think
rich
was
on
the
call,
so
he
may
have
already
gotten
that
idea.
D
I
didn't
add
a
comment
I
thought
rich
was
planning
to
make
that
change.
C
D
A
No
yeah-
and
I
thought
that
was
more
of
a
document.
I'm
not
sure
what
happened
there,
but
it
looks
like
it
had.
The
the
pr
has
been
updated
since
we
talked
yesterday,
but
we
missed
that
part.
C
A
Cool,
but
I
think
this
is
another
great
improvement
and
it
looks
like
it
needs
some
code
generation
a
few
other
things,
but
it
will
be
good
to
get
this
one
in
the
lat.
The
latest
pull
request
is
the
one
that
we
already
briefly
covered
at
the
top
of
the
this
meeting
and
that's
danian's
pr
that
is
doing
api
cleanup.
A
A
This
is
also
you
know,
fixing
what
we're
considering
a
v1
alpha,
1
blocker,
and
once
we
get
this
one
fixed,
we're
really
near
the
end
of
the
list
for
v1,
alpha
and
blockers.
A
A
A
B
Know
exactly
I
haven't
looked
at
the
cube
pedal
implementation,
but
in
my
experience
the
service
api
is
always
one,
so
keep
cuddle
get
gateway,
but
always
do
the
service
apis
one
and
then
you'd
use
easter
short
name
to
get
the
east
jail
one.
But
it's
also
possible
that
it's
like
first
one
wins
or
something
or
last
one
wins,
and
I
just
always
did
one
order.
I
haven't
confirmed.
B
A
Okay,
I'm
surprised
by
that
yeah.
I
thought
it
was.
You
know,
based
on
install
order
or
something
like
else
it's
strange.
You
know
it
seems
alphabetically
wait.
What
are
the
what's?
The
group
for
istio
crds.
A
B
A
Yeah,
okay,
interesting,
okay.
So
if
if
we
find
that
that
is
not
consistent,
then
I
guess
we
should
try.
We
should
make
this
more
of
a
priority
before
everyone
alpha
one,
but
otherwise
that
sounds
great.
It
would
be
great
if
it
consistently
worked
in
one
way
or
the
other,
but
who
knows
yeah?
Okay-
and
I
think
that's-
I
think-
that's
really
all
that
is
worth
discussing
today.
Unless
anyone
else
wanted
to
bring
something
up.
Yeah
are
there
any
open
items.
A
Cool
well,
that
was
easy.
Thank
you.
Everyone
for
your
time
enjoy
the
rest
of
your
week
and
I
think
we're
we're
getting
awfully
close
here.
Just
encourage
you
to
take
a
look
at
this
latest
pr
from
damian
and
if
you
have
time,
take
a
look
at
the
milestone
itself
and
pick
up
some
of
the
higher
priority
items
that
are
still
outstanding,
but
so
far
I
think
we're
looking
good,
so
yeah
have
a
good
rest
of
your
week.