►
From YouTube: Gateway APIs Meeting (APAC Friendly Time) 20210719
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:
well,
we've
got
just
a
few
things
to
get
through
today.
Lots
of
gaps
to
discuss
interesting
feedback
on
all
of
these
first
question
here
is:
how
do
we
feel
about
github
discussion
boards
yeah?
So
this
is
a.
This
is
something
that
apparently
there
is
precedent
for
in
oh
in
oss
kubernetes
shane
had
suggested.
I
don't
see
him
on
the
call,
yet
I
don't.
I
don't
think
any
of
us
really
have
a
strong
preference
either
way
on
this
one.
A
At
least
that's
been
the
feeling
I've
gotten
from
the
participation
in
this
issue.
It's
people
are
rather
ambivalent
towards
this.
Does
anyone
want
to
you
know,
push
for
these
being
added
as
another
discussion
forum
for
gateway,
api.
B
B
I
think
it
was
the
release
cadence
kept.
There
was
a
bit
of
discussion
on
a
discussion,
so
there,
the
nice,
the
nice
part
about
that
for
sort
of
slightly
more
contentious
things
is
that
the
replies
are
threaded,
so
yeah,
it's
easier
to
have
multiple,
separate
threads
of
discussions
about
something.
So
I
feel
like
it's
good
for
it's
particularly
good
for
things
that
are
contentious
or
require
lots
of
different
areas
of
discussion.
B
A
B
A
Yeah,
I
guess
you
know,
there's
everything
has
been
done
and
it's
unclear
how
how
well
any
of
these
have
worked,
but
yeah,
okay,
so
yeah
this.
This
threading
is
nicer
for
sure
than
what
we
have
available
on
issues.
A
I
here's
what
I'll
say
I
I
don't
mind.
I
don't
mind
it
existing,
but
I
also
don't
care
enough
to
invest
the
time
to
figure
out
how
to
make
it
work.
But
if
someone,
if
someone
else
wants
to
by
all
means,
I
I
I'm
happy
to
have
it.
B
Oh
yeah,
I
I
guess
I'm
also
the
same
like
I
I
have
said
yeah
like.
Why
not
do
it,
but
equally,
I
probably
don't
have
to
bend
with
to
invest
the
time
to
make
it
work.
As
you
say,
yeah.
A
Yep
that
makes
sense
all
right.
Well,
we've
got
lots
more
to
get
through
so
I'll
move
on
from
that
one.
I
I
will,
if
anyone
wants
to
just
follow
up
with
a
brief
summary
of
of
that
discussion,
that
no
one's
against
it,
but
there's
not
anyone
volunteering
to
figure
out
how
to
add
it.
A
Awesome
thanks.
One
thing
that
we've
done
a
little
bit
internally
at
google
is
these
kind
of
uxr
sessions
and
we're
really
surveyed.
So
we
we
have
some
customers
that
are
quite
interested
in
this
api,
and
so
we've
had
some
initial
uxr
sessions
with
them
running
by
this
api,
and
that's
when
we
mention
user
feedback.
A
That's
often
what
we're
referring
to,
but
we've
been
wondering
you
know
we
already
have
general
purpose
content
for
uxr
sessions,
running
them
and
wondering
if
we
can
take
this
concept
into
oss,
and
I
asked
around
trying
to
figure
out
if
that
there
had
been
much
precedent
for
a
uxr
session
for
kubernetes
api
and
apparently
hasn't
really
been
done
before
at
least
no
one
I
talked
to
is
familiar
with
it.
I
reached
out
to
sig
usability
today
I
just
trying
to
get
feelers
on
the
best
way
to
do
this.
A
Maybe
it's
a
survey
instead
of
a
session
that
people
attend,
I
don't
know,
but
I
would
like
to
get
some
kind
of
feedback
and
really
try
and
get
more
users
aware
of
this
and
giving
feedback
before
we
get
to
a
point
where
we
can't
really
make
the
bigger
changes
that
we'd
like
to,
but
I
wanted
to
open
it
up
to
others
that
might
be
interested
in
this
kind
of
discussion
topic
like.
Are
we
interested?
Do
you
have
customers
organizations
whatever
that
might
be
interested
in
participating
in
this?
A
Any
you
know
preference
on
just
wide
open
oss.
Whoever
comes
up
comes
in
comes
in.
I
don't
know
it's
just
kind
of
a
wide
open
topic
at
this
point.
D
My
name
is
martin
cole.
I
work
at
medallia
and
I
I
work
in
in
a
team
that
that
handles
the
api
gateway
that
that
we
have
and
a
company
is
like
migrating
to
kubernetes
like
a
very
large
workload
and.
D
I'm
kind
of
following
this
work
to
consider
considering
this,
as
I
guess,
a
path
forward
for
us
for
my
team
to
onboard
our
workloads
and-
and
we
haven't
yet
provided
an
a
kubernetes-based
solution
for
for
api
gateway.
D
We
use
some
some
other
systems,
so
I'm
really
interested
in
what
you
were
just
mentioning
and-
and
maybe
I
can
like
be
a
part
of
that.
That
sounds
good
and
now
that
for
for
letting
me
know.
A
Yeah
no
welcome
and
thanks
thanks
for
joining
us
and
it's
great
to
have.
D
You
I
worked
at.
I
was
an
intern
at
google
before
just
just
a
little
bit
more
about
me,
microsoft
too,
and
I
I'm
based
in
argentina.
So
I'm
spanish
native
speaker,
I
go
by
and
yeah
yeah
and
and
compute
have
computer
science
have
computer
engineering.
So
anyway,
that's.
A
That's
awesome
well
yeah
great
great,
to
have
you,
and
I
think
this
is
all
the
more
evidence
that
there's
there's
plenty
of
interest
out
there
and
and
trying
to
run
a
few
uxr
sessions
in
in
the
broader
community,
and
we
already
it
sounds
like
have
one
volunteer
to
be
part
of
that
could
be,
could
be
very
beneficial,
so
yeah,
thanks
and
and
really
great
to
have
you
and
interested
in
your
feedback
throughout
yeah.
Anyone
else
have
have
any
strong
feelings,
one
way
or
another.
A
As
far
as
uxr
sessions.
C
Sorry,
james
things,
hey
sorry
it's
over
each
other.
I
think
uxr
seems
like
one
of
those
sessions
where
it's
like
the
qualitative
feedback
is
really
useful
so
like
when
you
come
out
and
say:
hey,
we
had
user
feedback
that
that
does
we
had
user
feedback
about
this,
then
it
immediately
makes
everyone
want
to
say.
C
Well,
you
know
question
that
like
why
how
what
are
all
the
details,
so
I
think
getting
that
qualitative
feedback
about
about
people's
experiences
is
really
really
really
interesting,
although
it's
also
difficult
to
give
that
without
you
know,
producing
the
the
whole
of
the
recorded
session
or
something
so
maybe
there's,
I
think,
genuine
overall
yeah,
I'm
very
much
in
favor.
A
I
let
nick
go
too
while
you're
yeah
sorry,
I
was
just
a
plus
one:
okay
cool
yeah,
so
I
and-
and
I
think,
like
james
mentioned
it's
hard
to
accurately
record
the
results
of
these
and
and
avoid
biasing
participants.
A
But
if,
if
we
can
do
that-
and
since
mark
has
been
the
one
who
set
them
up
internally
for
us
and
since
we
already
have
some
kind
of
content
to
go
with,
maybe
it'll
be
not
too
bad
to
translate
that
into
oss.
But
yeah.
That's
that's
all
I
have
there.
We
have
lots
more
content,
but
just
a
heads
up,
that's
something
that
I've
been
thinking
about
and
trying
to
figure
out
how
to
organize
yeah
so
get
follow-up.
A
If
you're,
if
you're,
new
or
weren't
around
last
week,
I
had
this
stock
that
set
a
rather
ambitious
v1
alpha
2
release
plan
and
basically
the
the
goal
was
that
every
cap
would
basic
every
gap.
Sorry
would
have
a
three-week
cycle
where
the
ideally
within
a
week
it
would
reach
an
approved
state
and
within
another
week
it
would
reach
an
implemented
state.
And
when
I
say
three
weeks,
I
really
just
mean
three
different
community
meetings
where
we're
discussing
and
and
finalizing
different
details.
A
So
at
this
point
we're
at
the
kind
of
approval-
and
hopefully
these
are
ready
to
merge
or
just
about
ready
to
merge
for
two
rather
large
gaps
and
we're
also
at
the
point
where
we
are
about
to
discuss
more
large
gaps.
So
there's
there's
a
lot
to
get
to
and
I
don't
want
to
spend.
I
don't
want
to
delay
anymore
on
this
one.
So,
first
just
try
and
time
box
these
two.
I
don't
know
five
minutes
each
or
something
like
relatively
small.
A
A
But
at
this
point
I
don't,
I
don't
think
we've
gotten
much
feedback
on
this
one.
So
I
think
the
reference
policy
gap
is
maybe
the
least
controversial
here.
Anyone
hesitant
about
moving
forward
with
it.
B
F
B
B
I
think
I'm
minus
one
on
having
one
with
both,
because
I
think
that
we
should
only
have
one
that
goes
in
one
direction,
because
that
way,
the
I
think
that
the
reference
from
is
effectively
the
selector,
like
the
selector,
if
you,
if
you're
having
a
reference
from
policy
like
you're
kind
of
like
you're,
using
the
selector
effectively
as
a
reference
from
policy
like
the
yeah-
and
I
feel
like
the
point
of
this
thing-
is
to
enable
the
person
who
owns
the
object
to
say
I
I
don't
want
to
allow
certain
things
or
actually
no.
B
That
is
not
the
right
way
to
say
it.
The
point
of
this
object
is
to
say
that
the
person
who
owns
the
object
must
explicitly
allow
things
to
refer
to
them
across
namespaces,
so
that
the
the
point
there
being
that
by
default
nothing
works
across
namespaces.
You
must
explicitly
go
in
and
allow
reference
inbound
references
to
your
namespace
for
name
forecast,
namespace
references
to
work,
and
the
reason
for
that
is
that
then,
that
that
keeps
some
a
bit
more
safety
around
the
whole
idea
of
of
namespaces
and
communities.
B
If
we,
when
I
initially
did
this
with
a
from
two,
I
think
that
was
one
of
the
things
that
I
hadn't
spent
enough
time
thinking
about,
but
the
fact
that
we
had
the
the
cbe
from
cross
namespace
references
makes
me
very
leery
of
being
too
open
by
default
with
crosstalk
space
references.
F
Yeah,
I
think,
like
one
thing,
that.
A
Yeah,
maybe
that
that's
it,
but
I
mean
you
could
you
could
argue
that
different
people
control
reference
policy
than
control
gateway?
So
you
could
say
I
only
want
gateways
in
my
namespace
to
be
able
to
reference
these
other
name
spaces,
but
it
seems
like
such
a
stretch
and
so
over
complicated
that
I
can't
see
a
need
for
an
outbound
reference
policy.
I
feel
like
if
you've
made
it
that
far
it's
it's
too
complicated.
F
A
C
B
I
think
rob
bowie
and
I
kind
of
an
agreement
that
that
we
feel
it
should
just
be
a
one,
a
single
directional
like
reference
policy
for
inbounds,
and
that
the
the
outbound
reference
policy
doesn't
add
enough
to
merit
the
inclusion
at
the
moment,
and
I
think
it
then-
and
I
think
it
runs
risks
of
accidentally
over
including
things
and
and
messing
with
the
cross
namespace
references
too
much
like
with
the
nato
security
behind
you
too
much.
C
C
B
B
A
Sorry,
sorry,
the
okay,
so
the
the
only
the
only
question
is:
do
we
ever
want
an
outbound
equivalent
to
that,
and
I
think
what
we're
leaning
towards
here
is
no
and
then
and
then
the
second
variation
of
that
is.
If
we
do
want
that,
would
we
want
that
to
be
included
in
the
same
resource
type
or
as
a
different
resource.
C
C
I
think
nick
and
I
are
kind
of
normally
normally
I'm
like
hey.
You
should
have
another
cid,
so
we've
sort
of
swapped
around
on
this
one,
a
little
bit
a
little
bit
yeah.
B
C
I
got,
I
don't
know
if
there's
a
case
to
restrict
the
permissions
for
inbound
and
outbound
reference
policy
differently.
So
you
might
it
like.
Is
it
at
all
useful
to
be
able
to
say,
do
you
have
to
give
give
service
accounts
permission
to
write
an
inbound
policy,
but
not
an
outbound?
B
Yeah,
I
think
it
feels
overly
complex
to
me
because
I
think
that
effectively
the
outbound
policy
is
handled
by
most
of
like
the
outbound
you
haven't
by
default,
an
outbound
policy
by
the
way
in
which
you
are
selecting
from
the
from
the
object.
That
is
referring
to
an
object
in
another
namespace,
but
that's
effectively
an
outbound
policy
right.
You
know
it's
a
policy
that
says
whatever
I
have
selected
is
allowed
and
you
do
do.
Is
it
all
that
useful
to
be
able
to
constrain
what
people
may
select?
B
I
don't
think
so
and
that's
what
we
were
talking
about
before.
I
don't
think
it's
useful
enough
to
justify
building
a
special
thing
for
it.
So,
and
I
think
that
I
also
think
that
the
the
I
think
that
what
I'm
trying
what
I'm
getting
at
is
that
the
bi-directional
binding
that
we
talked
about
before
is
kind
of
you.
B
I
think
that
the
important
part
is
that,
in
this
case,
the
bi-directional
binding
is
achieved
by
having
the
referring
object,
selects
the
things
that
can
that
can
or
that
will
be
referred
to,
and
then
the
reference
you
have.
B
The
ability
have
to
opt
into
being
selected
and
so
that
that
that
then
is
a
two-way
binding,
but
that
there's
a
two-way
binding
that
respects
the
fact
that
the
people
who
are
in
the
referred
in
the
referred
name
space
in
the
reference,
namespace
only
objects
that
are
being
referred
to
and
that's,
I
think,
the
key
part
that
we
really
need
to
make
sure
that
we
keep.
Is
that
when
you,
when
you
own
objects
in
the
namespace
they're
your
objects
and
other
people
shouldn't
be
able
to
refer
to
them.
B
Other
people
should
not
be
able
to
refer
into
your
namespace
without
without
you
explicitly
opting
in
that's
how
the
that's,
how
the
name
spec
that's,
how
we
keep
the
namespace
separation
safe,
and
so,
if
you
have
a
namespace
from
you're
kind
of
like
you're
you're
restricting
yourself
agreed,
but
I
don't
think
there's
good,
there's
enough,
there's
enough
use
case
for
that
to
to
make
it
a
thing.
So
I
guess
at
the
end
of
the
day,
what
I'm
saying
is.
I
think
we
should
call
it
reference
policy.
We
should
hold
that
we
can
add.
A
B
Fair
enough,
so
I
think
I
think
the
important
part
is
that
we
define
to
start
with
a
reference
policy
is
an
inbound
reference
policy.
Like
that's
the
when
we
say
reference
policy,
we
mean
a
reference
policy
to
an
object
in
a
namespace
like
the
reference
policy
lives
in
the
same
name
space
as
the
object
that
it
refers
to.
That's
the
that's
the
key.
That's
part
of
the
definition
of
a
reference
policy.
A
That
sounds
fair.
I
I
can
add
a
little
bit
of
cleanup
to
this
to
make
that
very
clear
in
the
description
here
and
then
I'll
ping,
everyone
again
to
get
this
this
pr
in,
but
I
think
that's.
I
think
that
is
all
there
is.
You
know
this.
This
pr
also
added
a
reference
to
the
vulnerability
but
yeah,
I
think
that's
all.
That's
left
on
this
gap,
all
right,
one
last
chance
for
anyone
at
any
hesitation
on
this
p
on
this
gap,
all
right,
cool
I'll,
keep
on
moving.
Then
policy
attachment.
A
This
is
a
big
one.
I
got
a
lot
of
discussion
on
it,
a
huge
thank
you
to
everyone
who
commented
yeah,
117
or
whatever
comments
lots
of
lots
of
participation.
Thank
you
everyone.
I
I
feel,
like
almost
everything
is
resolved
at
this
point.
If
I
have
not
addressed
one
of
your
comments,
please
let
me
know
oh
whoops,
I
I
missed
paul's
last
comment.
I
need
to
just
address
this
last
one
yeah.
Okay,
I
beyond
that,
so
I
should
I
should
highlight
it
doesn't
look
like.
A
I
got
much
feedback
after
the
last
update
I
pushed.
I
don't
think
that
there's
a
lot
of
huge
changes
in
that
update,
but
I
do
want
to
point
out
that
there
is
this
new
sample
policy
resource.
I
also
I
also
have
been
splitting
these
commits
into
what
these
things
into
different
commits.
So
if
you
want
to
track
between
rounds
of
you
know
feedback
you
can,
but
the
the
big
thing
that
I
added
based
on
feedback
is
this.
A
You
know
basically
template
service
policy
that
anyone
can
use
to
create
their
own
policy
resource
yeah.
So
there's
a
lot
here.
This
is
this
is
a
large
gap.
I,
but
I
wanted
to
check.
Does
anyone
have
any
hesitation
about
getting
this
one
in?
Is
there?
Are
there
big
things
that
are
outstanding?
I
know
there's
that
at
least
that
one
little
bit
of
feedback
that
I
missed.
A
C
I
think
one
discussion
that
maybe
I
missed
was
that
sub
resource
anchor
part
where
you
can
have
names
within
your
resources.
Was
there
a
more
detailed
rationale
for
that.
A
A
Yeah
sure
so
section
name,
so
this
is
in
the
policy
target
ref.
The
idea
is
that
you
may
want
to
apply
policy
or
attach
policy
to
a
specific
listener
within
a
gateway,
a
specific
rule
within
a
route
or
a
specific
service
within
a
port,
a
specific
port
within
a
service.
A
I
don't
anticipate
this
being
a
common
thing,
but
I
I
either
there
was
some
discussion
on
here
about
how
it
would
just
generally
be
useful
to
have
names
associated
with
these
things.
So
you'll
see
this
in
the
next
gap
that
we'll
discuss
today
about
gateway
route,
attachment
that
having
having
names
for
listeners
can
actually
be
really
helpful.
When
you're
trying
to
describe
where
you
want
to
attach
to
something.
A
F
A
Yeah,
sorry
that
so
you
mean
the
listener:
okay,
so
yeah.
I
guess
this
would
be
any
other,
the
the
same
formatting
as
any
other
kubernetes
name.
I
had
not
thought
that
through
that
much
but
yeah
that's
so
I
added
this
as
a
diff
somewhere.
I
don't
know
somewhere
in
this
gap,
about
what
the
name
would
actually
look
like,
but
I
think
it
would
be
just
like
this
formatting,
so
there's,
unfortunately,
with
crds,
we
don't
have
a
lot
that
we
can
do
for.
A
I
guess
we
could
do
a
regex
for
validation,
but
I
I
think
this
would
be
basically
the
starting
point.
It's.
F
A
Right
exactly
I
mean
so
I
we
can
control
the
formatting
of
listener,
name
and
rule
name,
but
we
obviously
can't
like
this,
and
this
I
need
to.
I
need
to
extend
this
a
little
bit
more,
but
this
can
obviously
be
extended
if
you
have
a
custom,
backend
type
right,
if,
if
you
want
or
some
other
resource
that
is
somehow
nested
has
a
list
within
it,
this
this
concept
could
extend
there
as
well.
I
C
F
A
B
Yeah
it
feels
like
it
feels
like
having
to
be
unique,
would
be
useful
in
some
ways,
but
then
would
rule
out
the
thing
that
james
says
yeah.
It
feels
like
if
you
need
to
be
able
to
select
multiple,
multiple
listeners
within
a
gateway,
but
not
all
of
them,
maybe
you're,
better
off
breaking
the
gateway.
Apart
into
into
like.
B
Having
multiple
gateways
with
each
with
a
set
of
listeners
yeah
I
mean
we
should
note
that
that
this
section
name
thing
could
be
handled
in
that
way.
For,
for
most
of
these
things,
I
think
the
thing
that
it's
most
useful
for
is
service,
where
we
don't
control
the
spec.
B
C
B
Yeah,
I
think
it
makes
sense.
You
said
this
earlier,
but
it's
not
reflected
there
that
the
support
for
second
name,
I
think,
should
be
extended
yeah,
and
we
should.
We
should
document
that
yeah.
We
should
have
some
stuff
in
here
that
documents
like
how
it's
expected
that
the
section
name
will
work.
The
section
name,
reference
will
work,
so
it
should
be
like
you,
names
should
say
something
like
names.
B
Names
of
sections
are
not
necessarily
unique
and
if
they
are
not
like,
and
if
they
are
not
unique,
you
implement
something
like
implementations
may
may
or
may
not
loads.
They
may
require
uniqueness
of
names.
If,
if
they
don't,
then
it's
expected
that
it
will
behave
in
this
way
or
something
like
that
like
we
just
need
to
define
what
the
behavior
is,
if
you,
if
you
do,
have
unique
names
and
define
what
it
is,
if
you
don't
and
or
something
like
that,
like
john's,
got
his
hand
up.
J
Yeah
yeah,
so
you
talked
about
making
it
extended
and
my
understanding
of,
like
the
feature
status
or
whatever
we
call
it
for
like
core
versus
extended,
is
that
the
idea
is
that
some
controllers
can't
implement
it
because
of
various
requirements.
J
A
B
Yeah,
so
I
thought
that
extended.
The
reason
I
suggested
it
was
that
I
thought
extended
was
not
necessary
to
be
a
conformal
implementation.
J
Right,
but
what
the
rationale
for
putting
an
extended
I
would
have
thought
is
that
it's
because
not
everyone
can
implement
it,
not
just
because
I
don't
know
someone
doesn't
want
to.
I
don't
know,
maybe
that's
not
the
case,
but.
B
F
B
F
A
Yeah,
I
guess
the
the
only
thing
that
I
have
yeah.
Okay,
let
me
let
me
just
remove
support
level.
I
mean
it's
like
you
want
to.
You
want
to
describe
this
pattern
as
a
whole
as
having
a
support
level
of
extended
almost
I
because
we
realize
that
not
every
policy
is
going
to
be
able
to
be
attached
at
every
level
in
every
hierarchy
for
every
implementation.
F
B
So
just
so
just
to
reiterate
that
means
that
extended
means
you,
don't
it's
not
mandatory
to
implement
it,
but
if
you
do,
then
there
are
rules
around
how
you
do
yeah
exactly.
A
K
Rob
I
was
going
to
mention
is:
is
this
section
name
support
something
that
we
feel
is
required
for
this
gap
like?
Are
there?
Do
we
think
this
is
mvp
functionality?
I
mean,
I
don't
know
if
I've
seen
a
use
case
that
would
suggest
that,
like
we
need
to
have
it
because
it
maybe
we
should,
we
should
punt
it
see
how
people
want
to
use
service
policy,
and
that
would
help
us
inform
a
little
more
because
this
kind
of
seems
like
a
niche
thing
that
has
a
lot
of
complexity
associated
with
it.
A
Yeah,
I
I
don't
mind
pulling
it
out
if,
if
there's
hesitation
around
this
one
and
I'd
have
to
dig
back
through
the
the
feedback
initially
to
see
how
broadly
interesting
this
one
was.
B
I
I
guess
the
question
I
would
have
is
is
for
john:
what
do
you?
What
do
you
think
he
meant
like?
Do
you
think
that
this
this
should
be
like
core
support,
or,
like
I
mean
you
raise
the
question
like?
What
do
you
think
we
should
do?
Should
we
take
it
out
all
together
and
then
just
put
this
back
in
later?
If
we
need
it.
J
No,
I
think
section
name
is
definitely
something
that's
useful,
if
not
required
for
a
lot
of
use
cases,
especially
the
listener
name.
So.
C
That's
you
know
we
want
to
apply
policy
to
a
slice
of
something,
but
section
name
is
just
one
of
the
cases
where
you
want
to
apply
some
policy
to
some
slice
and
specify
the
size
like
somehow,
and
I
don't
feel
like
it's
a
particularly
flex,
I
mean
people
will
find
useful
uses
for
it
and
it's
kind
of
okay.
It's
just
that.
It's
it
I
feel
like
it
doesn't
really
fulfill.
C
C
I
can't
do
it.
I
can't
do
it
through
this.
I
can't
do
it
through
this
way,
but
I
could
do
it
through
policy
and
if
I
can
express
it
through
policy,
maybe
I
don't
need
the
service
name
like
there's
lots
of
there's
lots
of
subdivisions
right,
and
I
guess
this
is
just
one
of
them
so
well,
I
don't
really
have
any
strong
objection.
It's
also
it
also,
you
know,
doesn't
really
solve
a
lot
of
the
kind
of
use
cases
that
I've
been
thinking
about.
B
E
B
K
I
just
don't
know
how
to
turn
it
off,
but
yeah.
I
just
want
us
so
just
since
the
only
reason
I
suggested
separating
it
is
only
because
I
feel
like
we
have
a
lot
of
consensus
on
other
areas
of
service
policy
and
if
we
don't
in
this
area
because
there's
a
lot
of
options,
then
as
cus
as
people
use
service
policy,
we'll
get
a
lot
of
better
ideas
about
how
we
might
want
to
implement
this.
K
So
if,
as
opposed
to
kind
of
doing
theoretical
arguments
now,
but
I
mean
I
don't
feel
like-
we
have
to
punt
it.
If
we're
all
kind
of
agreeing
about.
K
E
Okay,
well,
I
wanted
to
ask
about
section
name
whether
I
mean
if
this
is
a
general
thing
where
right
now
we
have
gateway
route
service.
Presumably
it
could
be
extended
to
other
resources
or
those
resources
could
be
extended.
I'm
wondering
if
it's
impossible
that
there
might
be
in
the
future
or
a
resource
one
of
these
or
some
other
resource
where
you
have
multiple
sections,
so
a
bad
example
would
be
with
gateway.
You
have
listener,
you
also
have
addresses.
Maybe
you
want
to
refer
to
a
specific
address.
D
E
Understand
what
I
mean
should
we
have
something
like
some
apis
have
object
field
selector?
Where
you
can,
I
think
that's
what
it
is
where
you
can
specify
the
path
of
the
field,
and
then
you
could
specify
a
name
within
that
field.
If,
if
that,
assuming
that
field
is
a
list,
does
that
make
sense.
A
Yeah
that
does
make
sense.
I
I
think
all
of
this
is
leading
me
to
the
the
conclusion
that
we
should
punt
on
section
name
and
I'll
I'll
move
this
down
to
kind
of
potential
expansion,
and
then
it
seems
like
the
rest
of
this
gap
is,
is
pretty
close
to
consensus.
So
I
don't
want
to
get
stuck
on
this
one
kind
of
extension
of
it.
So
I'm
fine
to
punt
on
this
and
get
the
the
core
in
and-
and
I
agree
that's
a
good
point.
J
About
punching
it
and
not
ever
solving
it,
though,
because
I
feel
like
this
is
absolutely
critical,
I
mean,
I
think,
there's
some
underestimating
of
how
important
it
is
to
be
able
to
select
a
specific
port,
because
a
lot
of
people
are
coming
from
ingress,
which
only
kind
of
has
80
and
443.
C
In
in
the
context
of
of
port,
specifically,
did
you
look
at
prior
art
in
ingress
controllers,.
C
No,
I
did
not,
because
I
know
most
ingress
controllers
have
some
sort
of
annotation
scheme
that
deals
with
this
today,
so
I
mean
that's
how
we're
addressing
port
specifically.
So
I.
B
It
does
seem
to
me
like
this
is
a
large
enough
space
that
we
need
to
spend
a
little
bit
time
and
think
about
think
through
alternatives
and
do
like
a
prior
art
review
and
that
sort
of
stuff
to
say,
hey
know.
We
need
to
be
able
to
refer
to
some
sub
portion
of
an
object.
What's
the
best
way
to
do
that
in
a
general
and
extensible
way.
B
I
completely
acknowledge
john,
that
you're
100
right
that
people
are
going
to
need
to
be
able
to
pick
port
is
probably
the
first
and
most
important
one,
but,
like
the
you
know,
is
there
a
more
general
way
we
can
do
it
than
just
having
a
the
the
name
field
is?
Is
that
the
best
way
is
the
question?
I
think
we
need
to
answer.
J
Yeah,
I
think
that's
that's
reasonable
and
fine.
One
thing
I
would
say,
and
this
we
can
still
defer.
This
is
that
if
you
look
at
rob's
other
proposal
with
like
the
binding,
yes,
the
section
name
also
plays
a
critical
role
there,
and
so
we
need
to
make
sure
that
whatever
we
do
here
is
kind
of
aligned
with
what
we
do
there,
which
I
think
that
feel
like
leans
towards
section
name.
But
that's
totally
fine.
J
B
Yeah,
I
think,
for
me
the
thing
that
we're
taking
out
is
the
section
name
reference.
I
think
that,
having
a
name
adding
a
name
into
the
fields
into
the
listeners
and
the
the
routes
and
stuff
like
that,
I
don't.
I
think
that
that
is
like
a
zero
loss
thing
to
do
like
there's,
no
reason
not
to
do
that
to
have
names
in
those
fields.
E
C
Well,
you're
kind
of
okay.
I
feel
like
there's
there's
two
concerns
here.
So
nick
wants
to
put
names
on
things
for
better
user
experience.
So
right
so
you
can
say
here's
the
name
of
which
listing.
Are
you
talking
about?
Oh
this
one,
so
I
can
show
an
error
and
I
can
say-
and
it
can
show
an
error-
that's
like
on
this
listener,
with
this
name
so
to
solve
that
to
address
that,
need
you
I'd
probably
say.
B
C
So
for
policy
match
I
kind
of
want
to
match
policy
on
things
that
are
more
like
labels,
so
I
don't
necessarily
want
to
have
one
policy
per
one
listener
I
might
want
to.
I
probably
want
to
have
like
one
policy
for
listeners
which
look
like
this,
not
necessarily
targeting
you
know,
policies
individually
by
name
and
managing
them
like
one
at
a
time.
A
A
A
So
if,
if
we're
good
with
that,
I
I
would
be
very
happy
to
move
on.
I
know
we,
you
know
we're
we're
limited
on
time
here
and
where
there's
other
topics.
So
if
that's
good
with
everyone
I'll
keep
on
I'll,
keep
on
going
to
the
next
gap
for
discussion,
because
it
is
also
highly
related.
A
Cool
all
right
so
with
that
this
is
this
is
a
huge
gap.
This
is
one
I
didn't
a
month
or
two
ago.
I
didn't
anticipate
ending
up
with
this
suggestion
proposal
as
it
is
today,
and
I
am
very
interested
in
feedback
on
it,
but
this
refra.
I
know
I've
had
other
proposals
around
this,
but
this
suggests
that
we
refresh
route
gateway
binding
and
it
has
you
know
a
number
of
goals.
A
A
A
You
may
eventually
have
some
kind
of
custom
gateway
resource
or
for
mesh
implementations.
I
can
imagine
at
some
point
you
might
be
interested
in
some
kind
of
like
mesh
type
reason.
You
know
I
don't
think
gateway
as
a
resource
is
a
good
way
of
modeling
an
instance
of
a
mesh,
but
maybe
there's
a
mesh
resource
out
there
that
you
might
want
as
a
parent
to
your
route.
I
I
don't
know
so.
The
clear
thing
that's
out
of
scope
here
is
defining
how
route
inclusion
will
actually
work.
A
Most
of
you
are
already
very
familiar
with
the
existing
approach.
That's
from
gateway.
We
have
a
route
label.
Selector
and
namespaces
can
either
be
same
namespace,
a
selector
or
all,
and
then
routes
have
three
options.
Either
same
namespace,
you
specify
a
list
of
gateways
or
you
say
any
gateway
can
attach
to
me.
So
you
kind
of
have
this
two-way,
almost
selection
happening
here.
You
know
one
can
be
a
selector.
One
can
be
a
list.
A
This
has
led
to
confusion
so
and-
and
I
think
one
of
the
things
that's
confusing
for
users
to
understand
is
the
the
idea
that
you
have
two
different
selectors.
You
have
a
label
selector
on
name
spaces,
plus
a
label
selector
for
routes,
and
this
may
just
be
in
my
imagination,
but
trying
to
compute
the
the
union
of
both
of
those
can
be
confusing,
so
that
led
me
to
a
proposal
that
again
really
interested
in
feedback
on
this
one.
A
So
we
know
that
if
you're
going
to
have
a
direct
reference,
although
we
started
with
you,
know
way
back
in
the
beginning
of
this
api.
We
started
with
this
list
of
gateway
route,
references
inside
gateway
and
that
didn't
work
because
it
didn't
scale
large
enough.
But
what
we
do
know
is
each
route
is
likely
to
have
a
a
fairly
small
set
of
gateways
it's
attached
to.
So
if
you
wanted
to
include
a
list,
you
could
potentially
do
it
there
and
this
matches
the
initial
user
feedback.
A
We've
gotten
that
route
owners
app
owners,
really
care
about
which
gateways
they're
attached
to
and
want
to
have
very
clear
control
over
that,
and
also
it's
natural
as
you're
building
your
route,
you're
you're
configuring,
everything
for
your
app!
You
want
to
be
able
to
attach
your
application
to
a
specific
gateway.
A
A
This
is
different
than
what
I
had
proposed
and
what
we've
talked
about
for
a
while.
So
I
really
want
to
get
a
lot
of
discussion
around
this.
The
actual
changes
here
are
relatively
modest.
It
removes
the
route
selector
from
gateways
and
replaces
the
three
options
from
route
to
gateway
with
a
single
reference
list.
A
A
So
I
I
went
through
and
actually
went
through
the
api
changes,
but
one
thing
I
want
to
make
sure
we
have
time
to
cover
here
is:
I
can
cover
the
advantages
and
disadvantages
in
a
bit,
but
the
obvious
thing
you
must
be
thinking
at
this
point
is
why
wouldn't
we
use
a
reference
policy
for
this
and
I
I
tried
to
make
reference
policy
work
at
this
level
and
I'm
not
sure
that
it
works
as
well.
A
I
think
it
works
amazingly
from
route
to
back
end
or
route,
but
I'm
not
sure
that
I
could
that
we
can
find
a
way
to
translate
it
for
the
gateway
route
relationship,
and
so
I
I
kind
of
explored
two
different
options
here.
One
this
kind
of
downward
selection,
so
gateway
continues
to
select
route
and
then
reference
policy
points
back
up,
but
it
gets
a
very
verbose
very,
very
quickly
and
we
still
have
that
kind
of
dual
selector
going
on
here
that
I
I
think,
can
be
confusing,
and
you
have
this.
A
You
know
well,
who
really
controls
who's?
You
know
you
have.
Is
it
the
person
labeling
the
route
or
is
it
the
person?
That's
actually
controlling
the
selector.
You
have
the
unclear
roles
here
and
then
you
have
the
opposite
of
reference
policy
decides
which
routes
it
trusts
inside
the
info
name
space.
But
again
you
end
up
with
all
kinds
of
weirdness,
because
in
that
case
reference
policy
would
need
to
understand
the
name
of
the
listener.
A
Like
you
know,
you
need
a
unique
reference
policy
for
every
listener
involved
here
and
that's
also
very,
very
verbose
and
complex.
So
those
are
the.
A
Yeah,
so,
okay,
one
of
the
yeah.
Thank
you,
the
one
of
the
core
use
cases
of
multiple
listeners
in
gateway
is,
I
have
foo.com.
I
want
to
delegate
that
to
foo
namespace
and
I
have
var.com,
and
I
want
to
delegate
that
to
bar
namespace
to
describe
that
in
this
model
you
need
a
reference
policy
for
listener,
name
foo
and
say
I
trust
routes
from
foo
namespace
and
you
need
a
separate
reference
policy
for
bar
to
say.
I
trust
you
know
references
from
bar
namespace
to
my
bar
listener.
C
B
More,
I
think
you
might
end
up
with
you.
It
makes
it
harder
to
infer
the
config
intent
right,
like,
I
think,
that's
a,
I
think,
that's
the
thing.
I
think
that
right,
like
that,
when
the
h,
when
the
route
selects
the
gateway,
it
doesn't
say
like
the
route
is
not
selecting
so
so
you
do
have
the
route,
selecting
a
section
name
here.
Rob
do
you
have
that
in
so
you
have
that
in
this
one.
Do
you
have
that
in
the
in
the
base
in
the
in
the
actual
suggested
one?
A
Yeah
and
this
one,
this
is,
the
route
is
attaching
to
gateway
scenario.
If
you're.
B
A
Yeah!
That's
that's
what
john
that's!
Why
thank
you
john
for
trying
to
pull
this
all
together,
but
that's
john
saw
that
the
connection
here
between
section
name
as
it's
proposed
and
policy
attachment
and
as
it's
proposed
here
they're
both
you
know-
I
admit
that
for
many
organizations,
they're
going
to
have
a
single
listener
gateway
or
something
like
that,
where
section
name
or
equivalent
concept
is
not
as
important.
A
But
for
these
examples,
where
you
have
unique
listeners
per
name
space,
the
concept
of
section
name
or
something
like
it,
becomes
very
critical
either
in
this
example
or
in
that
other
reference
policy
example
as
well,
because
the
whole
idea
of
attaching
to
something
a
specific
item
within
a
list.
A
Yeah
that
that
is
a
real
possibility.
You
could
do
a
hostname
match
here.
That
would
work.
It
is
maybe
not
as
precise
as
you
would
like.
So
one
of
the
examples,
if
you
looked
at
harry's
pr
for
redirects
right
now,
one
of
the
examples
is
a
an
example
where
you
have
a
single
route
that
does
a
redirect
https,
and
then
you
have
all
your
other
routes,
just
listening
on
https,
which
makes
all
the
sense
in
the
world.
A
E
A
Yeah
well,
even
if
it
is
the
same
host
name
like
even
if
it's
acme.com
and
but
the
that's,
you
know,
that's
only
for
the
listener
on
port
80
and
its
sole
purpose
is
redirect
to
the
listener
on
port
443.
B
So
it
sounds
like
I
mean
this
again
comes
back
to
that
same
section
and
discussion,
but
it
sounds
like
there
are
definitely
cases
in
which
having
a
unique
name
for
each
listener,
particularly
will
be
useful
and
requiring
the
name
to
be
unique.
That
doesn't
mean
that
there
aren't
cases
where
you
don't
where
you
want
to
be
able
to
select
business
based
on
some
other
set
of
things
but
like
there
are
definitely
cases
where
you
must
select
a
unique
listener
and
only
a
unique
listener
yeah.
C
I
kind
of
see
it
I
feel
a
bit
like
this
is
the
this
use
case
is
the
purpose
of.
I
think
it
was.
This
is
the
original
purpose
of
the
reference
policy.
It's
the
like
the
primary
driver
for
doing
reference
policy
at
all.
C
So
it
feels
a
little
un
unfortunate
to
me
that
reference
policy,
like
it's
an
extension
to
re
it's
this
kind
of
tweaky
extension
to
reference
policy
that
actually
makes
it
work.
It's
not
sort
of
the
the
main
path.
The
primary
path
through
reference
policy
isn't
enough
to
actually
solve
the
thing
that
we
wanted
to
solve
originally,
which
seems
a
little
I
I
guess,
I'm
a
little
surprised
about.
I
haven't
read
this
one
fully.
A
A
Yeah
and-
and
I
this
is,
this
is
a
lot
to
digest
in
just
a
few
minutes.
I
know
we're
already
over
time,
so
I
I
am
very
interested
in
feedback
on
this.
I
I
did
try
and
make
reference
policy
work.
I
am
also
not
upset
if
it
doesn't
work,
because
I
think
reference
policy
has
a
very
clear
and
useful
purpose
for
route
to
service
route
to
route
and
maybe
other
resources
like
secrets
in
the
future.
A
So
I
like,
I
think
reference
policy
does
still
have
a
very
clear
place,
an
api.
I
just
am
not
sure
that
this
is
the
place,
but
I
I
agree.
That's
that's
why
you
know
I
listed
two
alternatives
and
they
were
both
reference
policy,
because
I
was
trying
to
find
a
way
for
that
to
work,
but
I'm
not
sure
that
it
makes
sense
here
so
yeah,
but
feedback
very
welcome
on
this.
B
B
That's
that's
fair,
but
I
do
think
that
the
key
part
of
this
change
is
that
http
routes
should
be
the
thing
that
select
gateways,
not
gateway
selection
periods,
like
that
the
key
part
is
that
that's
the
http
route
that
owns
the
relationship
to
the
gateway
and
that
that,
if
that,
then
there
is
some
mechanism
for
the
gateway
to
effectively
accept
or
reject
that
the
the
the
binding
attempt
from
the
from
the
route
yeah.
A
Yeah,
the
so
the
other
way
of
looking
at
it,
and
I
really
really
will
call
this
the
end.
But
the
other
way
of
looking
at
this
is
routes
become
the
central
focus
and
everything
is
a
direct
reference
from
a
route,
whether
it's
route
to
route
route
to
service
or
route
to
gateway.
A
Everything
is
directly
referenced
from
that
central
point.
So
routes
become
the
center
and
if
you
look
at
it
that
way,
it
does
feel
somewhat
consistent,
but
I
I
recognize
that
it
is
frustrating
not
to
have
reference
policy
here
so
yeah.
I
am
very
interested
in
alternatives.
Other
ways
to
do
this,
but
I
just
wanted
to
get
this
conversation
going.
C
So
if
we
went
the
path
so
basically
just
to
drag
it
out
over
time,
so
what
you're
talking
about
there
is,
instead
of
having
the
listeners
reference
the
route
reference,
the
gateway
so
having
the
gateway
listeners
having
the
selector
for
routes.
You
you
flip
it,
so
the
routes
say
attach
me
to
this
gateway.
You
have.
A
I
I
B
A
G
A
C
B
B
This
one
and
have
a
think
about
it.
We
are
way
over
time
yeah.
We
only
read
this
and
have
a
think
about
it
and
comment
on
it.
This
this
is
a
big
deal.
This
is
a
very
big
change.
I
think
I
think
it's
100
fair,
rob
to
say
that
doing
what
you've
got
as
the
main,
as
the
main
idea
at
the
moment
is
you're
100
right.
It
changes
it
changes
it
to
be
like.
B
B
A
Yeah
cool
well,
thank
you,
everyone
for
the
feedback
and
thanks
for
staying
over
interested
in
what
you
think,
and
there
is
another
gap
that
we
didn't
get
to.
I
think
this
one's
smaller
in
scope,
but
yes
thanks
again
and
yeah,
we'll
talk
to
you
throughout
the
week
and
in
the
next
community
meeting
as
well
have
a
good
one
see
y'all
later.
Thanks,
see
ya.