►
From YouTube: [SIG Network] Gateway API Office Hours 20201104
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
I
think
we
are
really
on
pace
again
for
that
milestone
timeline
here,
but
let's
just
run
through
these
really
quickly
harry
had
a
great
pr
to
add
a
simple,
getting
started:
guide
I've
added
a
few
little
nitpicks
on
this
one.
I've
gone
back
and
forth
a
little
bit,
but
I
think
we're
nearly
at
the
end
of
this
and
I
think
it's
just
about
good
to
go.
But
if
anyone
else
wants
to
take
a
look
at
this,
I
definitely
encourage
it.
A
A
We
one
of
our
blocking
issues
that
we'll
get
to
shortly
asks
for
two
things:
one:
it
wants
a
gateway,
gateway,
class,
http
route
combination.
This
does
this
and
it
also
wants
an
example
of
targeting
routes
in
multiple
namespaces,
which
this
also
does,
if
I'm
remembering
correctly,
yes
selects
routes
from
all
namespaces.
A
So,
given
that,
I
think
this
is
actually
a
really
good
pr,
and
once
we
get
this
in,
which
feels
really
close,
we
should
be
able
to
consider
this
issue
potentially
done
enough.
There's
lots
more
room
to
expand
on
this,
but
we
will
have
these
two
bullet
points
which
are
the
ones
we
considered
blocking
taken
care
of
lots
of
room
to
improve
there.
A
With
that
said,
the
next
one
is
also
from
harry,
and
it's
all
about
app
protocol
again.
This
feels
awfully
close
to
me.
I
had
again
just
a
couple,
tiny
knits
that
I
added
today
as
far
as
review,
I
don't
think
there's
too
much.
Let
me
actually
look
at
the
diff
real
quick,
I
don't
think
there's
too
much
of
interest
or
that
might
that
would
surprise
anyone
here.
A
A
So
at
this
point
the
only
thing
I
had
left
as
a
suggestion
was
just
a
little
bit
of
cleanup,
but
if
anyone
is
really
interested
in
that
protocol
definitely
take
a
look,
and
so
with
that
we
are
awfully
close
to
being
done
with
our
blocking
requests
and
that
leaves
the
all-important
tcp
route
and
udp
route
match
all
requests.
I
talked
a
little
bit
with
damian
this
morning
afternoon.
I
don't
know
time's
a
blur
about
this
one.
That
sounds
like
you're
still
able
to
take
this
one
on.
B
C
A
Yeah
yeah
and
I
I
think
that
I
think
that's
obviously
the
easiest,
because
it's
not
actually
you
know
a
new
api
field,
but
it
it's
also
probably
the
easiest
to
understand.
I
you
know
I
we.
I
had
at
least
initially
thought
of
this
kind
of
enum
based
approach,
but
I
think
that
would
just
get
confusing,
especially
since
you
can
have
multiple
matches,
so
you
have
yeah
I'd.
So
I
I
completely
agree
with
the
direction
you're
going.
B
B
If
you
could
scroll
back
down
to
my
comment,
though,
because
and
just
you
know
the
initial
pass,
I
did
kind
of
question
why
this
issue
doesn't
call
out
tls
route,
though
I'm
not
sure
if
you
can,
if
you
can
just
kind
of
go
to
the
tls
route,
match
yeah,
and
we
could
take
a
look
at
that
really
quick
because
I
feel
like
maybe
we
needed
to
find
something
there,
because
there's
no
real
definition,
all
right.
The
tls
route
match
criteria.
B
You
know
says
based
on
the
sni's
that
are
specified
right,
which
very
similar
to
host
name
right.
It
could
be
precise
or
we
could
have
a
wild
card.
But
if
we
think
here
is
well
what,
if
it's
not
specified,
if
you
look
at
line
99
right,
I
mean
we.
We
admit
that
there's
no
defaulting
going
on,
and
so
I
don't
know
if
that's
maybe
a
bug
where
we
should
have
a
default
or
we
should
remove
the
omit
empty
and
this
field
should
be
required.
A
Yeah,
this
is
a
confusing
combination
here,
because
we
have
a
min
items,
one
here
and
omit
empty,
which
doesn't
make
sense
so
yeah
we've
we
can
probably
remove
omit
empty,
but
then
up
here
matches
has
no
min,
so
matches
are
technically
optional,
it
seems,
and
we
do
not,
we
do
not.
You
know.
The
closest
thing
we
say
here
is:
if
any
one
of
the
matches
is
satisfied,
which
seems
to
infer
that
if
there
are
no
matches,
then
it
isn't
a
match
like
if
there
are
no
matches
specified,
which
would
be
inconsistent.
A
A
A
A
B
B
C
B
Why
didn't
I
play
around
with
this
from
the
tls
route
standpoint?
Unless
I
mean
we
can
still
discuss
it,
but
maybe
I
just
yeah
submit
a
pr.
I
just
wanted
to
call
out
that
you
know
I.
You
know
I
looked
at
the
different
apis
and
it
looks
like
the
issue.
What
is
it?
415
doesn't
specify
tls
rod,
it
just
says
udp
route
and
tcp
rod
and
I
feel
like.
We
also
need
to
address
tls
route.
A
A
B
A
B
A
It's
it's.
This
is
not,
as
I
thought
we
had
something
more
clear
than
we
do
here,
but
my
recollection
was,
the
intent
is
if
no
host
name
is
specified
got
it
all
traffic
you
know
goes
through
the
route
rules
and
then
obviously
the
other
thing
that
isn't
explicitly
said
here
is
matches
are
based
on
the
most
specific,
the
longest
combination
of
longest
matching
combination
of
host
and
path.
So,
if
host
isn't
specified,
it's
really
a
catch-all.
A
A
A
A
No,
that's
fine!
That's
fine
yeah,
so
I
think
I
think
this
will
also
be
a
good
way
to
clarify,
though
this
may
not.
I
think
we
still
need
something
to
be
a
little
bit
more
clear
when
host
name
is
not
specified
here.
I
think
we
may
be
clear
on
gateway
listener.
That
may
be
what
I'm
thinking
of,
but
in
an
http
route.
It
looks
like
we're
not
clear
enough
for
what
happens.
D
Something
that
I
was
thinking,
while
you
guys
were
talking
about
those
other
host
name,
specifics
like
in
in
say
a
standard
http,
no
tls
is
it
that
we're
just
going
to
ignore
like
that
host
field
of
http
header,
like
is
that
the
appropriate
behavior
and
like
only
depend
on
the
routes,
I
guess
is
that
being,
is
that
the
intent
behind
saying
if
hostname
is
not
provided
yeah
we
yeah.
That
is
that,
is
that
correctly,
okay,
yeah.
B
A
A
A
That
feels
like
another
thing,
where
we
need
a
tie,
breaker
and-
and
the
proposal
here
I
think,
makes
sense,
even
though
this
is
a
real
edge
case,
and
I
don't
know
how
possible
this
is
to
actually
implement.
But
the
idea
is
the
number
of
header
matches.
The
largest
number
of
header
matches
is
given
precedence
here.
A
E
D
E
D
Given
the
offer,
the
one
thing
that
did
stand
out
to
me,
hopefully
doesn't
distract
us
too
much
from
that
question
is
that
the
host
name
in
terms
of
hanging
a
host
colon
http
header?
That
also
is
a
header
not
that
we
have
to
get
bogged
down
in
that.
But
it
does
seem
kind
of
strange
that
we
have
that
delineation
yeah
that
that's
what
it
is.
It's
not
possible
to
have
a
header
post.
A
D
Yeah,
that's
a
good
point.
Well,
I
guess
to
go
back
to
your
question.
I
I
thought
about
this.
For
a
while,
it
didn't
seem
like
there
was
any
reason
that
you
couldn't
have
a
len
length
call
or
something
to
that
effect,
once
you're
already
parsing
that
header
right,
so
it
seemed
yeah
implementable.
I
suppose
yeah.
A
Yeah,
no,
I
I
I
think
I
agree
with
that
too,
like
I
think
I'd,
I
think
I'd
been
part
of
this
discussion
or
suggestion
or
something
like
and,
and
it
seemed
reasonable
to
me
as
well.
I
just
wanted
to
make
sure
that
there
were
no
red
flags
here
for
anyone
else
that,
but
but
it
sounds
like
not
so
I'll
call
that
a
win.
E
A
E
I'm
a
little
concerned
about
the
first
bullet
point,
the
longest
matching
combination
of
host,
name
and
path.
I
assume
that
is
because
you
have
wild
cards
right
yeah,
but
it
seems
like
that
could
produce
some
really
unintuitive
behavior,
if
you
had
say
startupfood.com,
foodbar
and
then
foobar.foo.com
foo
and
you
have
to
figure
out
yeah.
E
You
have
to
really
think
about
which
one
of
those
is
more
exact
because
you're
taking
the
cabination.
I
assume
right
yeah
and
I'm
trying
to
come
up
with
a
concrete
example,
but
it
seems
like
you
really
have
to
think
about
that
it
I
feel
like
it
would
make
more
sense
to
match
on
something
like
the
most
specific
host
and
then,
if
you
have
multiple
matches,
then
you
go
to
the
most
specific
path
or
the
longest
matching
path.
A
D
C
A
E
A
No
in
the
ingress
docs
on
the
on
the
website,
there's
I
think
we
may
have
a
couple
tables,
but
one
of
them
we
have
for
different
path
matches.
We
have
a
path,
a
like
a
path,
that's
specified
in
the
ingress,
spec,
a
request
path
and
whether
or
not
it
matches
kind
of
thing
all
the
way
down.
That's
my
approximate
right,
a
prop
approximate
memory
of
how
we
structured
that,
but
but
something
that
that
makes
it
clear
like
some
examples
of
okay,
you
have
this
input.
D
D
A
A
A
So
with
that
said,
let
me
pull
up
the
v1
alpha
1
milestone.
There
hasn't
been
a
lot
of
movement
here.
I
just
wanted
to
raise
attention
to
one
issue
I
created
today
and
this
I
have
not
prioritized
this.
It
probably
shouldn't
well
it's
something
that
we
need
to
figure
out
in
very
close
relation
to
the
v1
alpha
one
launch
and
that's
how
we
how
we
structure
our
repository
after
we've
released
an
api.
That
is
final.
You
know.
A
What's
less
clear
is
how
we,
how
we
handle
documentation,
how
we
structure
other
parts
do
we
do?
We
need
release
branches
kinds
of
things.
This
is
not
something
we
need
to
answer
on
this
call,
obviously,
but
I
just
wanted
to
get
that
that
discussion
started
and
get
people
thinking
about
this,
because
we
really
are
at
this
point.
I
think,
two
weeks
away
from
when
we
said
we
would
have
a
v1
alpha,
one
release
cut
so
yeah.
A
I
don't.
I
don't
think
this
is
an
absolute
requirement
to
have
everything
figured
out
before
v1
alpha
1
launches
it
just
it
basically
prohibits
us
from
making
any
progress
beyond
v1
alpha
1
until
we've
solved
these
things,
so
we
obviously
would
need
to
do
it
relatively
quickly
and
yeah
like
bowie,
says
posting
some
examples.
A
A
A
Appreciate
it
thanks
yeah
and
if
anyone
else
comes
up
with
anything
yeah
just
add
them
here
and
yeah
thanks
all
right.
So
that's
the
milestone
and
the
one
thing
that
I
wanted
to
cover
today,
it
seems
like
we'll
have
time
is
to
run
through
this.
You
know
this.
I've
I've
been
watching
our
suggested
names
for
gateway,
and
you
can
see
the
last
suggestion
came
in
six
days
ago,
so
I
think
you
know-
and
I
mentioned
it
at
the
elastig
network
meeting
last
week.
A
I
think
we
might
have
gotten
one
or
two
since
then
and
that's
been
about
it.
I
think
we
have
a
reasonable
starting
point
here,
but
I
think
one
thing
that
they
did
well
in
multi-cluster,
which
I'm
basing
this
process
off
of
loosely,
is
ran
through
with
maintainers
of
the
project
and
tried
to
identify
names
that
maintainers,
just
really
didn't
like
you
know,
basically
gave
the
opportunity
to
veto
any
potential
names
here.
A
Unfortunately,
I
think
some
of
these
probably
need
to
be
trimmed
before
we
opened
voting
on
this,
but
I
think
most
of
them
are
probably
acceptable
and
we
can.
We
can
also
revisit
this
later.
I
may
post
in
slack
as
well,
but
I
think
the
the
most
obvious
one
I
think
is
at
least
to
me
is
ingress,
which
I
would
love
to
do:
ingress
v2,
but
obviously
this
kit.
This
is
both
a
bit
broader
than
that,
and
also
something
that
cannot
easily
round
trip
between.
A
A
A
I
yeah
I've
spent
a
while
thinking
about
exactly
how
this
could
work
and
I
I
think
it
would
be
overly
confusing
unfortunately,
and
it,
and
it
also,
I
think,
would
be
confusing
to
users
to
think
that
you
know.
Okay,
I
have
ingress
and
v1
and
ingress
and
v2
is
approximately
a
quarter
of
what
ingress
and
v1
was,
and
so,
where
did
everything
else
go?
You
know,
I
think
at
that
point.
It
makes
sense
to
just
have
a
different
name.
A
E
D
A
C
A
C
A
Looking
for
yeah
yeah,
okay
on
ramp,
I
think
on-ramp
and
a
lot
of
these
actually
all
kind
of
refer
very
clearly
to
ingress,
which
I
think
is
you
know,
potentially
an
issue.
If
we're
also,
you
know
longer
term
thinking
of
potential
egress
use
cases
for
the
same
api.
I
don't
know
how
serious
any
of
those
egress
use
cases
are,
but
on-ramp
does
seem
to
limit
us
to
a
single
direction
that
this
would
model.
A
I
I
hate
to
I
hate
to
get
rid
of
too
many
of
these,
because
you
know
I
do
want
a
reasonable
amount,
but
I
think
the
ones
closer
to
the
top
are
better,
in
my
limited
opinion,
so
I
and
anyone
I
these
are
things.
These
are
my
personal
preference,
please
feel
free
to
to
say
no.
This
is
actually
something
that
we
should.
We
should
keep
on
the
easy
list,
all
right
entry.
I
think,
how
do
you.
A
Yes,
yeah
yeah
entry.
I
think,
for
the
same
reason
I
I
would
personally
say
everything
that
is
suggesting
a
one-way
direction
is
something
I
would
prefer
to
avoid
here,
but
maybe
you
know
I
I
don't
know
I
don't.
I
don't
want
to
rule
out
too
many
if,
if
egress
is
not
going
to
be
much
of
a
use
case
here,
I
know
that's
that's
more
of
a
conceptual
thing
at
this
point,
but.
A
A
A
Yeah
so
well,
I
I
I
get.
I
guess
I
I
guess
I
don't
have
to
well
technically
this.
This
is
this
the
same
idea
as
inflow
and
oh
and
inlet,
and
that
it
is
a
single
direction.
So,
for
that
same
reason,
I
will
strike
this
one
out:
service,
router,
edge,
router,
app
gateway
and
gateway.
Obviously,
gateway
has
to
be
one
of
the
options.
A
C
A
A
B
A
A
I
think
we
need
to
get
rid
of
this
if
it
overlaps
with
anything,
though
I
don't
know,
is
this
a
strong
enough
overlap.
Yeah,
it
looks
like
it's
still
actively
maintained,
though,
admittedly,
we're
never
going
to
have
a
completely
unique
name.
So
if,
if
anyone
wants
to
push
for
it,
I'm
fine
with
the
keeping
it
as
well.
A
A
A
A
Yeah,
so
I
think
I'll
have
to
include
all
this
background
and
if
yeah,
this
is
a
doc
that
anyone
can
edit.
So
if
you
want
to
go
in
here
and
edit
or
suggest
changes
to
reasons
to
change
the
name
or
to
keep
it
the
name
the
same,
I
want
to
include
this
kind
of
background
as
a
starting
point
for
the
survey.
A
A
This
is
this
is
a
a
huge
one
and
I
know
we've
covered
it
relatively
recently.
So
I
don't.
I
don't
want
to
open
this
can
of
worms
too
far
again,
but
just
this
is
going
back
to
the
short
name
and
trying
not
to
conflict
with
istio
and
all
that
fun
stuff
and
very
related
to
the
conversation
we
just
had
about
potential
alternatives.
A
So
you
know
you
could
use
short
names
to
get
around
this
problem
by
always
using
instead
of
coop
cuddle
get
gateway
in
our
examples,
coupe
kettle
get
gtw
or
something
like
that.
That
would
be
unique
and
work,
but
that's
potentially
less
than
ideal,
so
yeah
I,
this
pr
has
mostly
laid
silent
for
around
a
week
now
and
it's
not
at
all
blocking
v1
alpha
one.
A
So
I
don't
think
it
needs
to
be
a
high
priority
item,
so
my
preference
is
probably
just
to
wait
and
see
what
happens
as
far
as
naming
here
and
if
we
find
an
alternate
alternate
name
great
and
if
we
don't
then
we'll
come
back
and
revisit
this,
but
just
good
to
have
in
the
back
of
your
mind
as
we're
thinking
about
alternate
names
yeah,
and
with
that
I
think
I
think
everything
else
has
been
covered
already
or
hasn't
changed
since
we've
covered
it.
Anyone
want
to
bring
anything
else
up.