►
From YouTube: Gateway APIs Meeting (APAC Friendly Time) 20210802
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
All
right
we're
recording
it's
august,
2.
we've
got
lots
going
on
for
gateway
api
and
hopefully
we're
getting
awfully
close
to
v1,
alpha
2
being
ready.
I
I
created
this
kind
of
makeshift
table
here
just
to
track
where
we
are
with
all
these
different
gaps.
A
I
think
there's
kind
of
an
invisible
line
here,
where
I
guess
it's
not
really
invisible,
but
I
in
my
mind
this
is
a
nice
to
have,
but
certainly
not
necessary
in
any
way.
So
we
really
need
to
be
focusing
on
getting
everything
here
and
above
in
in
the
next
ideally
week
or
so
nick
had
a
pr
for
reference
policy
that
implements
it.
I
think
a
few
of
us
have
already
left
some
feedback
on
it.
So
thank
you
to
everyone
that
has
that
this
feels
pretty
close.
A
I
think
everything
in
here
is
primarily
nitpicks
and
not
nothing
that
we
need
to
spend
much
time
discussing
here.
I
think
in
in
most
cases
the
implementations
of
gaps
should
be
pretty
straightforward,
it's
more
just
typos
or
other.
You
know
small
things,
so
I
don't
think
we
need
to
spend
too
much
time
on
this.
Just
a
heads
up
that
it
exists
and
if
you
have
any
opinions,
get
them
in
otherwise,
hopefully
we
can
get
merged
in
pretty
quickly
for
policy
attachment.
The
there
were
two
pros
one.
A
A
I've
had
some
feedback
on
this
one,
but
if
anyone
has
time
to
take
another
run
through
this,
I
would
be
helpful
feels
like
we're
awfully
close
again.
This
is
really
just
translating
components
of
the
gap
into
either
docs
or
go
types,
and
hopefully
what
we
already
had
in
the
gap
was
pretty
close.
A
What
I'm
more
concerned
about
is
so
back
in
ref.
I
think
this
one
is
also
very
close.
I
I
added
a
bit
of
feedback
just
before
the
meeting,
so
sorry
for
the
late
notice
on
this
one
harry,
but
I
I
added
a
suggestion
to
rename
this
to
backend
ref
and
we've
kind
of
we've
kind
of
gone
in
circles
around
the
naming
here.
A
But
it
looks
like
the
api.
Can
conventions
strongly
prefer
or
require
that
ref
suffix,
but
otherwise
looks
great.
A
725
this
one
is
massive.
Thank
you.
I
know
most.
Everyone
has
at
least
an
initial,
or
I
guess
not
quite
everyone,
but
we've
had
an
initial
round
of
review
from
a
lot
of
people
on
this
and
discussed
it
last
week
in
more
detail
and
in
the
week
before
that,
so
I
don't
want
to
spend
too
much
time
discussing
this
again,
but
I
just
wanna,
I
just
wanna.
A
This
feels
like
the
one
that
we're
furthest
away
from
consensus
on,
and
I'm
not
saying
that
that's
that
far
away,
it's
just
the
other
ones
are
just
you
know
like
one
nitpick
away
from
an
lgtm
approve
and
go
forward.
This
one
feels
like
there's
still
some
broader
questions
on
it.
I
wanted
to
kind
of
give
one
last
opportunity
like
most
of
the
comments
on
here
are:
oh
thank.
You
are
of
the
small
nature
like
nothing,
nothing
groundbreaking
that
nothing
saying
we
could.
A
We
should
do
something
entirely
different
for
this,
but
I
wanna
I
wanna
give
anyone
an
opportunity
like.
Is
this
an
approach
that
feels
too
extreme
to
you?
Should
we
should
we
be
looking
at
a
different
approach,
or
is
this
you
know
conceptually
the
direction
that
we're
comfortable
with
for
this
change
any
kind
of
hesitation
as
far
as
the
big
picture
direction
here.
B
I
think
I
don't
know
if
I
left
that
comment
or
not,
but
I
think
overall.
I
think
this
is
in
the
right
direction.
It
is
a
narrower
api
than
the
previous
one,
so
we
could
again
extend
it
if
needed,
it
would
introduce
some
some
hassle,
but
I
think
it
can
be
done.
B
So
that's
good
overall,
I
think
the
easy
path
becomes
slightly
or
it
becomes
more
complicated.
So
that's
that
one.
That's
one
thing
that
I
think
I
personally
don't
like,
but
I
also
don't
see
another
option
to
balance.
You
know
how
to
balance
security
and
user
friendliness
here
so
but
overall
yeah
a
plus
one.
A
Yeah,
that's
that's
a
confusing
part
of
this
gap.
What
I
be
and
a
confusing
part
of
what
exists
right
now,
I'm
planning
on
keeping
everything
but
the
namespace.
Sorry,
the
route
selector
on
gateway,
so
there
will
still
be
a
namespace
selector
on
gateway
pointing
down
towards
routes,
but
the
actual
route
selection
is
something
that
I
think
provides
very
little
value
and
adds
a
great
deal
of
confusion.
C
C
A
C
There's
kind
of
a
couple
of
cross-cutting
issues
here
that
are
sort
of
related
and
make
things
a
little
bit.
Fuzzy
first
is
the
need
to
put
multiple
kinds
of
routes
on
the
same
listener
yeah.
So
I
guess
the
way
you'd
have
to
do
that
now
would
be
the
way
we
the
way
that
was
suggested
in
the
pr
originally,
which
is
you
have
a
you,
depend
on
the
listeners
being
collapsed,
that
you
have
multiple
listeners
on
the
same
ports
and
each
one
selects
a
different
kind
of
route,
and
then
your
implementation
collapses.
C
Those
down
the
other
thing
that
I
think
is
maybe
worth
discussing
a
little
bit
is
how
this
effect,
how
this
interacts
with
the
reference
policy.
C
So
I
pinged
nick
on
on
on
slack,
and
I
think
one
of
the
one
of
the
useful
things
you
could
almost
do
with
reference
policy
is,
if
you're
a
gateway
owner
you
could,
if,
if
you're
a
gateway
owner,
you
could
say
this,
this
specific
gateway
object
can
receive.
You
know
these
objects,
these
kinds
from
namespace
a
and
this
other
gateway
object
can
receive
kinds
from
namespace
b
and
to
do
that.
C
We've
kind
of
split
the
policy
across
reference
policy
and
gateway
because
gateway
can't
because
reference
policy
can't
specify
an
object
by
name,
and
so
you
have
to
specify
the
kind
and
the
namespace
in
the
listener
of
the
object.
So
it's
a
little
bit.
C
Their
policies
are
spread
across
two
objects,
which
feels
a
little
bit.
It's
a
little
bit
awkward.
A
It's
I
think
I
missed
the
last
part
of
that
so
you're
right,
the
reference
policy
is
a
little
bit
more
broad
in
how
it
actually
be
before
I
go
into
that.
Let
me
let
me
there
were
two
parts
and
the
first
part
was
the
kinds
the
how
routes,
how
gateway
selection
can
support
multiple
kinds.
This
is
something
that
one
of
the
it
may
have
been.
Actually
a
discussion
with
you,
james,
I'm
not
sure,
but
one
of
the
initial
bits
of
feedback
pointed
to
an
issue
where
there's
more
discussion
on.
A
Maybe
we
should
make
this
the
time
where
we
support
multiple
kinds
per
listener,
because
this
is
nowhere.
This
is
no
longer
a
concept
of
selection.
This
is
no
longer
a
concept
of
select.
You
know
an
implementation,
doing
some
kind
of
query
and
former
list.
Whatever
of
this
kind
of
this,
you
know
whatever
so
supporting
multiple
kinds
becomes,
maybe
marginally
more
sensible
in
this
approach.
A
There's
some
good
feedback
from
harry
that
maybe
we
still
need
to
make
this
a
required
and
explicit
list
which
I
I
can
I
can
get
behind,
but
the
the
fundamental
idea
I
think
of
this.
It
helps
with
your
first
point
that
it
does
become
slightly
easier
to
handle
multiple
kinds
per
listener,
so
maybe
yeah.
Let's,
let's
start
with
that
discussion.
Does
that?
Does
this
approach
generally
make
sense
to
you.
C
Yeah,
I
think
so,
but
I
I
think
that
you
there.
I
guess
it's
not
something
that
you
couldn't
have
done
before.
D
A
Right
and-
and
it's
also
not
something
that
is
entirely
reliant
on
this
change
of-
you-
know
the
the
routes
directly
referencing
yeah,
so
I
you're
right.
A
I
think
your
your
later
point
was
probably
more
important
here
or
or
larger
in
scope,
and
that
was
how
this
interacts
with
reference
policy
right,
and
you
had
some
concerns
like
reference
policy,
as
you
mentioned,
does
not
support
a
reference
by
name
right.
You
say
I
trust
resources
of
this
type
in
this
namespace
to
be
able
to
reference
resources
of
this
type.
A
In
my
namespace-
and
this
is
a
slightly
different
model
than
that-
it's
similar
you're
saying
from
the
gateway
side,
you're
saying
I
trust
resources
of
these
kinds
in
these
namespaces
to
be
able
to
attach
to
me.
So
it
seems
pretty
similar
to
me,
but
I
think
you
had
pointed
out
some
more
some
larger
differences
that
I
might
have
missed.
C
Yeah,
so
I
think
that
I
think
the
question
is
that
the
policy
you're
trying
to
implement
is
now
split
across
two
places.
Like
you
have
one
thing,
which
is
called
reference
policy,
but
to
make
the
reference
policy
specific
in
in
a
way
that
seems
like
a
reasonable
practice,
you
actually
need
to
augment
it
with
you
know
the
gateway,
which
kind
of
implies
that
the
reference
policy
api
isn't
specific
enough
or
isn't
quite
complete
right.
You
can't
express
you
can't
express
the
policy
that
you
can't
express
the
policy
for
this
use
case
using
reference
policy.
A
That's
fair
and
I
mean
you
can,
but
it
just
gets
very
messy,
as
I
show
in
alternatives
that
you
just
you
need
so
much
more.
It
becomes
very
verbose
to
to
express
this
with
reference
policy.
A
A
So,
given
that
I
yeah
I
I
feel
like
there's
there's
ways
you
could
extend
reference
policy
to
make
it
work
for
gateway,
but
as
the
alternatives
show,
I
think
it
it
is
rather
messy
and
verbose,
and
we
could
we
could
try
and
force
reference
policy
to
handle
this.
I
just
I
don't
know
that
it
makes
sense.
You
know
what
one
thing
we
could
say
in
the
future
is
that
you
could
choose
to
say,
use
reference
policy
to
trust.
A
B
I
mean
think
about
a
very
complex
sorry
to
interrupt.
You
so
think
about
a
very
complex
organization
where
they
want
to
separate,
like
trust
relationship,
and
the
only
way
you
can
solve
with
our
bag
in
kubernetes
is
to
have
two
different
resources
there,
so
it
so
if
a
custom
implementation
wants
to
do
that,
probably
nothing
is
preventing
them
to
do
that.
E
Yeah,
I
think
my
my
take
on
reference
policy
for
gateway
is
that
the
gateway
route
relationship
is
the
by
far
the
most
common
one
that
gets
used
and
in
most
organizations,
we've
seen.
There's
there's
relatively
few
gateways
or
there's
like
a
gateway
is
either
relatively
a
small
pool
of
gateways
or
a
gateway
pretend
such
that
it
doesn't
the
to
to
centralize.
The
policy
makes
it
more
complex
to
do
something.
E
That's
very
common
which
to
me
it
feels
like
it's
adding
too
much
verbosity
to
do
something
that
a
lot
of
users
will
have
to
do.
They'll
have
to
get
to
know
a
new
resource
which,
which
makes
I
think,
which
warrants
it
for
the
more
unique
use
cases
like
route,
inclusion,
secret
references
and
things
like
that,
but
it
I
don't
know
it
feels
like
a
bit
too
much
for
the
gateway
route
relationship.
C
Yeah,
I
think,
rob's
point
about
you
know
this
binding
being
or
the
scoping
being
per
listener.
Also
kind
of
complicates
the
the
idea
about
putting
it
into
directly
into
into
reference
policy
too,
because
then
we
have
to
go.
C
You
know
take
off
take
on
the
same
complexity
that
we
did
for
the
the
other
pl
when
we
start
talking
about
section
names
and
things
like
that.
A
Yeah
exactly
yeah
yeah,
so
that
that's
what
led
me
to
the
current
proposal-
it's
it
seems
like
we're
pretty
close
here,
but
I
know
there's
there's
some
recent
feedback
I
need
to
follow
up
on,
but
if
there
are,
and
actually
some
poor
indentation
too,
but
if
there
are
any
other
things
that
that
come
up
that
you're
in
any
way
hesitant
about
definitely
ping
me
or
added
to
you
know,
add
feedback
on
the
pr
whatever,
but
I
would
love
to
get
this
in
soon.
A
I
would
I
certainly
love
to
get
this
in
this
week,
I'll
plan
on
updating
this
pr,
based
on
the
feedback
today
later
today,
like
after
this
meeting,
but
otherwise
I
I
hope
we're
pretty
close
here.
A
Having
this
discussion
makes
me
think
that,
and-
and
the
discussion
in
previous
meetings
makes
me
think
that
this
is
probably
a
reasonable
way.
You
know-
I,
I
don't
think
it
has
its
flaws,
but
I
think
it's
probably
the
least
bad
of
our
options
right
now,
and
it
leaves
us
lots
of
room
to
expand
in
the
future
if
we
need
to
add
more
capabilities.
A
Oh,
actually,
I
see
harry
added
a
comment
in
chat
that
I
missed
that
reference
policy
is
more
of
an
extension
point
and
not
a
core
feature.
I
do
believe
we've
considered
reference
policy
extended,
need
to
triple
check
on
that,
but
there's
a
very
a
very
small
list
of
exceptions
for
when
you
might
not
want
to
support
it,
and
it's
I
I
forget
exactly
how
it's
defined
in
the
gap
and
nick's
more
recent
pr.
A
B
A
A
A
Cool
all
right,
well
I'll,
skip
over
the
redirect
re,
redirect
redirect
and
rewrite
one
here.
That's
7
27
there's
been
some
good
feedback
and
discussion
here,
but
since
you
know,
if
there's
time
I'll
come
back
to
it,
but
I
want
to
make
sure
we
can
get
to
v1
alpha
2
first
and
some
pr
and
issue
triage
as
well
for
viewing
alpha
2.
I
spent
some
time
looking
through
the
milestone
and
if
you
look
at
it
you
can
say:
oh
wow,
this
looks
rather
overwhelming
and
that
would
be
accurate.
A
A
A
Yeah
now
that
was
the
argument
when
we
moved
back
in
policy
that
any
replacement
would
be
rather
complex
and
focusing
on
something
that
is
really
only
relevant,
for
you
know,
118
and
be
and
be
low.
It
seems
like
a
poor
use
of
time,
so
yeah
so
yeah.
This
seems
easy
if
anyone
wants
to
volunteer
for
this.
This
is
a,
I
think,
a
straightforward
one,
to
write
up
basically
of
99
percent
of
features.
This
api
works
for
116
plus
there
are
some
features
currently
limited
to
app
protocol
that
will
require
118
or
119.
B
A
Oh
actually,
it
looks
like
jimin
I
volunteered
in
chat
if
here
yeah,
oh
perfect,
yeah.
That
would
be
awesome
if
you're
able
happy
to
help
out
in
any
way,
but
yeah
we'd
love
additional
contributors.
Here,
thanks.
B
A
Then
there's
a
213
there's
been
some
more
recent
discussion
on
this
one
around
header
value.
You
know
matching
multiple
header
values
this
one,
I
think
we're
pretty
close
here.
A
Let's
see,
I
think
we
just
need
someone
to
actually
document
what
we
expect
to
happen
here.
Envoy
had
some
some
weird
buggy
be
almost
buggy
behavior
before
here
and
how
it
did
header
matching,
but
it
seems
like
most
others
are
going
to
do.
The
comma
separated
value
for
header
matching.
A
C
I
think
in
envoy
you
need
to,
I
think
the
envelope
behavior.
Is
it
coalesces
everything
into
a
single
separated,
comma
separated
string
and
you
have
to
regex
match.
C
F
B
F
F
F
C
C
F
Yeah
yeah,
I
think,
like
it's
okay,
to
say,
I'm
assuming
that
the
proxy
implementations
some
people
might
have
gotten
it
wrong,
but
we
should
just
note
that
that
we
expect
yeah
we'd
have
to
test
like.
If
people
know
proxy,
I'm
assuming
most
proxy
implications
actually
do.
What
envoy
did,
I
think
nginx
actually
does
what
envoy
does.
G
I
feel
like
this
is
something
that's
kind
of
weird
to
say:
you
have
to
behave
this
way,
because
the
reality
is
that
every
implementation
of
this
api
is
building
on
existing
proxies,
at
least
today
like
there's,
no
gateway
api,
ground-up,
purpose-built
proxy,
and
I
feel
like
everyone's
just
going
to
use
what
the
underlying
proxy
does
like.
I
don't
care
what
the
spec
says:
I'm
probably
not
going
to
go
change
envoy
so
that
I
can
match
a
different
way
if
it
doesn't
go.
F
F
G
Yeah
I
mean
that
kind
of
applies
to
a
lot
of
fields
too.
The
more
specific
we
get
about
matching
like
in
some
ways,
it's
good,
because
we
want
to
be
specific,
but
on
the
other
hand,
because
we're
not
using
purpose-built
implementations
of
this
a
lot
of
times
it
makes
it
so
you
can't
actually
implement
the
api
in
accordance
to
the
spec.
F
A
C
A
Perfect
awesome
thanks
all
right
and
the
one
last
one
we
currently
have
in
the
v1
alpha
2
milestone
is
this
one
tls
spec
on
route
and
tls
on
route
is
something
that
I
think
we've
gone
around
in
circles
on
and
before
I
go
too
far
into
this
discussion.
A
I
want
to
ask
more
broadly
of
different.
You
know
implementations
out
there.
How
critical
of
a
use
case
is
this
is
this
something
that
is
is
a
very
important
to
you.
I
know
this
is
something
that
I
came
up
earlier
very
early
in
the
design
and
I'm
trying
to
understand
the
stories
for
it
more
just
so,
when
we're
framing
this
discussion,
we're
framing
it
properly
and
translating
the
use
case
into
something
that
actually
makes
sense.
B
I
know
of
some
users
who
have
asked
for
this
in
cong
and
then
there's
also
like
I
don't
have
issues
at
hand,
but
I
think
the
ingress
engine
x
project
also
has
that
you
know
some
contributors
asking
for
this,
because
this
leads
to
within
respect.
It
leads
to
problem
with
gateway
api.
Maybe
that's
not
a
problem,
so
that's
that's
some.
That's
how
I
read
that.
B
Yeah
so
within
respect
you
could
have
like
you
know
two
different
name
spaces
or
two
different
ingress
resources,
no
matter
where
they
live
and
they
could
have
like
food.example.com
and
specify
a
dls
search
for
them
for
that
host
name.
And
what
happens
if
you
know
that
host
name
is
different.
So
that's
like
one
problem
and
then
the
second
issue
that
that
comes
up
a
lot
with
I
mean
gateway.
Api
simplifies
that
right.
So
if
you
do
hostname
and
ls
cert
at
the
listener
level,
then
you're
good.
B
So
I
mean
so
with
that
case,
it's
fine.
I
know
I
took
an
objection
here.
It
was
just
to
make
sure
that
we
we
move
it
to
extend
it
for
reasons
we.
A
Understand
I
was
unmuted.
Sorry
I
yeah.
No,
I
I
agree,
and
I
think,
before
we
get
into
discussion
around
whether
or
not
this
should
be
extended.
I
wanted
to
understand,
like
I
know,
there's
some
concerns
about
how
this
is
implemented,
how
safe
it
is
and
and
other
things,
but
before
I
went
there,
I
wanted
to
properly
understand
the
use
cases
here.
It
sounds
like
you
know
the
bring
your
own
domain
kind
of
thing
mikaya.
A
A
Sorry,
so
this
is
the
ability
to
define
a
certificate
on
a
route
on
http
route
that
can
be
attached
to
a
gateway.
So
it
is
essentially
saying
that
there
is
another
way
to
attach
certificates
that
is
not
tied
to
a
gateway,
so
non-gateway
admins
can
provide
their
own
certificates
if
the
gateway
admin
allows
them
to.
D
A
D
Not
per
listener
necessarily
per
route
per
route;
well,
okay,
her
host's
name.
A
A
There
is
the
bet
at
the
end
about
potentially
changing
this
to
extended
support,
and
I,
I
think
that's
a
larger
discussion,
which
it
would
firstly
be
good
to
understand,
use
cases
before
and
and
understanding
of
interpretation
here
before
we
go
too
far
into
support
level,
but
to
clarify
here-
and
this
is
like
a
key
point-
when
you're
attaching
a
certificate
from
a
route.
A
Is
it
acceptable
that
that
certificate
applies
to
other
routes
using
the
same
host
name
for
this,
for
that
listener,
like?
Is
that
something
that
we're
considering
acceptable
that
this
route
trusts
this
gateway
and
this
gateway
press
routes
in
these
five
namespaces?
So,
therefore,
by
trusting
this
gateway,
you're
also
trusting
routes
in
those
other
name
spaces
to
attach
certificates
is
that
is
that
a
trust
relationship
we're
comfortable
with,
or
do
we
really
need
something
more
than
that.
F
Sort
of
the
question
that
we
hit
talking
to
a
few
folks
is
like
there
may
be
some
implementations
that
just
flat
out
say
we
don't
want
to
allow
this
kind
of
delegation
which
I
guess
you
could
do
with
just
using
opa
or
something
to
zap
out
the
field
for
the
people
who
are
supporting
it,
which
sounds
like
you
guys
have
a
very
clear
use
case.
A
Yeah,
I
mean
that's
part
of
it,
but
it's
also
part
of
it
is
is
due
to
interpretation.
I
one
when
you
see
a
certificate
attached
on
a
route,
it
is
only
natural
to
look
at
that
certificate
and
say
this
certificate
applies
to
this
route
and
so
far
in
our
documentation.
What
we're
saying
is
this
certificate
is
a
way
to
attach
a
certificate
to
the
gateway,
listener
or
listeners
that
the
route
is
attached
to
that's.
A
A
Right
like
yeah,
so
I
don't.
I
don't
even
know
that
that
even
makes
sense-
I
guess
just
clarifying
that
is
this
risk
acceptable.
Then
you
know
it
is
the
the
risk
that
I
have
a
route
in
namespace
a
and
I
can
affect
these
five
other
namespaces
because,
like
the
gateway,
I'm
I'm
providing
the
cert
to
trust
these
other
namespaces
too.
A
Are
we
going
to
have
some
kind
of
security
issue
related
to
this
in
the
future,
because
we
didn't
document
things
clearly
enough.
We
didn't
limit
the
capabilities
here
clearly
enough,
I'm
not
sure
it
just
it.
It
raises
some
concerns.
D
D
The
main
use
case
I
mean
it's
really
about
allowing
the
application
developer
to
supply
the
certificate.
It's
not
necessarily
certificate
needs
to
be
closely
associated
with
the
route
but
more
the
certificate.
It
needs
to
be
possible
for
the
person
who
owns
the
application
behind
this
route
to
be
able
to
supply
the
corresponding
certificate.
G
Why
don't
we
be
able
to
satisfy
the
same
use
case
of
letting
them
bring
their
own
certificate
if
we
just
instead
allow
that
certificate
reference
to
cross
the
namespace
boundary
as
well
and
then
use
like
reference
policy
to
allow
that
binding?
So,
just
like
we
say
we
want
routes
from
the
app
name
space.
We
also
say
hey.
A
Though
so
one
of
the
things
that
that
helps
with
is
the
confusion
around
the
the
potential
conflicts,
that's
what
I'll
say.
So
if
a
listener
selects
multiple
routes
and
says,
allow
override
true
and
three
of
those
routes
provide
certs
and
they're
different
in
in
any
way
or
there's
some
kind
of
conflict,
it
gets
very
messy
very
quickly
and
what
you
avoid
with.
If
I'm
understanding
john's
suggestion
there,
it
would
be
a
direct
reference
from
gateway
to
cert.
A
So
this
unfortunately
requires
a
fair
amount
of
coordination
between
gateway
owner
and
route
admin
or
app
admin,
whatever
whoever
that
is,
but
it
does.
You
know,
make
that
a
lot
less
ambiguous,
ambiguous.
It's
very
clear.
This
cert
applies
to
this
listener
and
there's
no
way
for
multiple
certs
to
be
attached
to
a
given
listener.
A
So
I'm
not
sure
if
this
solves
and
that's
why
it's
helpful
to
understand
the
use
cases
here,
because
if
that
solves
the
use
case,
that
that
makes
everything
a
thousand
times
easier
in
my
mind,
but
I'm
not
sure
it
does,
and
I
guess
mike
you
can
chime
in
or
anyone
else.
Who's
interested
in
this
feature
has
used
cases
for
it.
D
I
think
that
would
solve
the
use
case
so
right,
the
user.
The
application
developer,
would
be
able
to
define
the
route
and
then
define
the
certificate.
Doesn't
they
don't
need
to
themselves
reference
each
other,
but
then
the
gateway
has
is
configured
to
select
secrets
and
routes
from
whatever
name
space,
the
secret
and
rather
in
right.
A
Yeah
that
that's
one
interpretation
of
it,
this
election
actually
is
maybe
that's
an
interesting
way
of
looking
at
it.
I
I
had
in
my
head
thought
of
it
as
a
direct
reference
from
listener
to
secret,
but
a
selector
would
give
a
little
bit
more
flexibility.
There.
D
F
D
D
A
You
would
it's
per
host
name,
I
would
be
my
interpretation,
and
so
in
that
case
it's
not
so
much
associating
a
certificate
with
a
route.
It's
associating
it
with
a
given
host
name
on
a
given
gateway,
and
even
even
when
you
were
attaching
certificates
to
routes,
the
route
was
just
a
means
of
achieving
the
same
end.
It
was
still
I'm
attaching.
A
A
So
a
listener
can
have
and
host
names,
and
you
know,
infinite
postings.
In
that
sense,.
A
B
One
other
use
case
for
this
is
like
you
know:
you
have
star
dot
foo
example
and
start.example.com
at
the
listener
level,
and
then
these
delegate
to
two
different
name:
species,
foreign
bar
and
within
those
you
have
like
more
specific,
like
you,
don't
want
wildcard
certificates
like
that's
something
that
I've
heard
like
we
won't
name
certificates,
something
like
that
so
yeah
in
that
in
that
model,
you
actually
don't
run
into
security
issues
unless
you
configure
the
gateway
wrong.
B
B
That's
right
and
you
also
have
the
host
name
as
filled
as
the
filter.
Right
so
let's
say
I
have
a
namespace
base
and
that
can
and
gateway
forward
star.bash.example.com
to
that
that
namespace
now
in
that
namespace,
if
I
specify
foodart
as
the
food
or
like
anything
like
foobar.food.example.com
in
that
case,
that
route
wouldn't
be
matched
right,
because
a
route
always
has
to
be
is
first
filtered
by
the
listener.
F
Yeah,
so
I
think
I
thought
someone
had
a
use
case
where
they
didn't
want
that
constraint.
I
don't
think
we
say
that
the
certificate
is
constrained
by
the
host
name,
or
did
we.
F
Chose
to
at
least
the
format
that
we
specify
things
makes
it
potentially
possible
to
use
it
as
a
constraint.
But
we
never
went
ahead
and
said
that
it
should
be
a
constraint.
C
Yeah,
I
think
we
have
an
open
issue
where
I
believe
nick
was
going
to
add
some
language
to
say
that
that
hostname
and
sni
should
be
bound.
B
A
F
I
think
that's
a
interesting
boundary
because,
for
instance,
at
the
very
least,
you
could
specify
that
this
route,
namespace
can
only
have
food.com,
and
this
route
can
only
have
bar.com.
F
B
Sure,
yeah
I
mean
yeah,
we
could
add
some
guidance
with
that
right,
like
you,
you
specify
a
more
specific
wildcard
matching
a
hostname
matching
in
the
listener,
and
then
you
allow
this
feature
right.
This
feature
is
opt-in
disabled
by
default.
So
in
that
case,
does
does
like
the
trust
problem,
go
away.
A
Maybe
it
it
feels
like
this.
This
requires
more
thought,
at
least
for
me,
to
properly
understand
the
different
risks
involved
here.
All
I
all
I
know
is
that
if
there
there
are
risks
involved
here,
we
probably
have
missed
at
least
one
of
them,
and
if
there
are
ways
to
simplify
this
or
further
restrict
it,
we
potentially
limit
the
not
attack
surface,
but
the
yeah,
and
I
guess,
attack
surface
and
complexity
of
this
api
and
and
so
trying
to
find
it.
A
You
know
if,
if
we
properly
understand
the
use
cases
for
this,
we
can
at
least
look
at
alternatives
and
see
if
they
would
fulfill
that,
like,
like
the
alternative
of
that
john
mentioned
of
tls,
sir
being
reference,
you
know
being
still
being
def
referenced
from
gateway
directly
but
referencing,
something
like
in
another
namespace.
F
I
think
that
goes
against
the
self-service
yeah,
but
we
should
investigate
it.
I
feel
like
if
we
put
this
restriction,
it
does
fix
a
lot
of
the
issues.
I
just
remember.
There
was
a
conversation
where
people
didn't
like
this
restriction,
or
they
had
a
use
case
around
this
restriction.
But
if
anyone
on
the
call
remembers
that
conversation-
maybe
it
didn't
happen.
B
I
think
it
was
I'm
not
certain
if
I
remember
that,
but
we
have
run
into
like,
I
think
more
liberal
use
cases
where
people
trust
everything
on
all
the
names,
because
maybe
that's
not
a
good
idea,
but
that
that's
another
model
where
you
know
one.
One
persona
controls
all
of
these
resources,
and
so
they
want
to
organize
these
things
a
little
differently.
C
So
I
think
with
I
guess,
with
this
discussion-
there's
it's
kind
of
tricky
to
keep
this
discussion
on
on
track
right,
because
there's
different
security
issues
that
that
we're
kind
of
thinking
about
so
on
on
the
serving
side.
You
know
we
need
we're
thinking
about,
what's
like
finding
a
sni
to
certificate
selection
to
https
names
and
we're
trying
to
protect
we're,
trying
to
make
it
easy
for
people
for
operators
to
get
a
secure
deployment
by
default,
something
that
won't
have
you
know,
domain
fronting
attacks
or
or
surprising
configuration
results
in
the
cluster.
C
What
the
security
problem
that
we're
trying
to
tackle
is
is
sort
of
around
privacy
of
tls
keys
and
preventing
unexpected
access
to
two
tls
keys,
which
would
result
in
them
being.
You
know,
exfiltrated
or
something
like
that,
so
we
kind
of
got
these
two
separate
problems,
and
I
think
if
we
try
to
look
at
them,
maybe
if
we
try
and
look
at
them
in
as
as
separate
problems
rather
than
like
this
whole
tls
configuration.
A
I
at
least
for
me
you
cut
out
at
the
end
there,
I'm
not
sure
it
could
have
just
been
me,
but
the
bit
I
heard
at
the
end
was
something
about
the
controller
needing
to
support
all
namespaces.
A
A
Okay,
yeah,
that
makes
sense-
I
it
yeah,
I'm
gonna-
have
to
spend
some
time
thinking
this
one
through.
As
far
as
how
we
can
handle
this.
It
does
seem
like
what
what
we've
been
discussing
here
about
ensuring
that
tls
that
hostname
and
nsni
match
would
help
here
with
the
potential
risks
associated
with
this.
A
I'd,
I
think
part
of
my
my
rationale
for
extended
was
thinking
through
that
this
is
this
feels
like
a
scary
feature,
and
some
implementations
may
not
want
to
support
it
because
it
seems
scary,
but
that's
that
is
not
the
bar
we
have
had.
You
know
if
it
seems
scary,
we
should
probably
just
not
have
it
in
the
api
or
we
should
find
a
way
to
make
it
less
scary.
A
The
requirement
that
hostname
and
sni
match
may
be
sufficient,
but
interested
in
other
ideas
here
as
well.
A
A
Okay,
well,
I
know
where
we're
at
time
here
I
those
are
the
issues
that
are
not
covered
by
gaps.
I
think
the
last
two
are
pretty
straightforward
and
this
one
will
require
some
more
work
for
me
and
please
take
some
time
to
review
at
least
7
19
and
7
25,
and
hopefully
we
can
get
them
in
really
soon.