►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210421
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
this
is
april
21
and
we've
got
lots
to
get
through.
This
is
really
our
most
significant
meeting
before
our
planned
release.
I
think,
on
april,
29.
of
vo.3.0
so
really
trying
to
get
through
a
lot
and
focus
on
what
we
have
planned
for
this
milestone.
What
might
make
it?
What
needs
a
little
bit
of
a
nudge
and
what
will
likely
not
make
it?
A
So
that's
I've
added
a
bunch
on
the
agenda
related
to
that,
but
feel
free
as
always
to
add
anything
else
as
well.
I
also
want
to
point
out
that
we've
got
a
straw
poll
going
on.
I
think
everyone
here.
Almost
everyone
here
has
already
filled
this
out.
If
you
haven't,
please
do
there's,
there's
trends
that
are
appearing
on
this
drop
straw
poll
for
new
meeting
times
and
for
context.
This
was
inspired
as
it
was
becoming
clear
that
we
really
could
benefit
from
a
different
meeting
time.
A
We
had
one
meeting
time
that
was
pretty
terrible
for
whether
you
were
in
europe
or
australia
as
an
example,
and
we
happened
to
have
people
contributing
from
both
of
those
places
and
it's
very
hard
to
find
a
time
that
works
for
both
of
them.
But
we
may
want
to
consider
going
back
to
a
pattern
where
we
were
rotating
between
times.
B
That
work
did
people
have
who
are
on
the
call
today
I
know
it's
not
everyone
like
did
that
work
out
actually,
or
did
people
just
end
up
attending
both,
and
it
was
just
on
average
like
okay,
it's
like
the
compromise,
it's
like
to
make
it.
I
guess
like,
on
average,
worse
for
everyone
slightly.
A
Yeah
my
perspective
on
that
that's
a
good
point
is
it
makes
it
more
confusing
for
everyone
to
to
rotate
back
and
forth.
I
it
did
to
a
point
enable
I
think
we
had
more
of
an
opportunity
to
get
contributions
from
or
a
conversation
with,
folks
that
otherwise
wouldn't
be
able
to
attend
the
meeting
on.
On
the
other
hand,
it
just
it
does
complicate
things
now
that
we
do
have
significant
contributions
from
you
know.
Different
continents
shall
we
say
and
and
different
significantly
different
time
zones
it's.
A
It
feels
like
it's
worth
exploring
again,
but
I'll
I'll
admit
that
it
was
not
the
easiest
thing
to
do.
You
know
it
it's
it's
challenging
when
you
have.
You
know
when
you
kind
of
want
to
time
the
content
for
the
attendees.
You
know
like
these.
This
set
of
maintainers
is
really
interested
in
this
topic,
so
we
really
shouldn't
discuss
it
this
week.
We
should
discuss
it
next
week,
but
I
mean
I
don't
think
anyone
has
solved
this
problem
of
scheduling
meetings
across
time
zones.
A
I
don't
know
any
anyone
else.
Okay,.
B
A
Yeah
I'd
agree
with
that.
Go
ahead,
steve.
C
A
Yeah
yeah,
you
can
see,
what's
what's
surprising
to
me,
like
we
have
12
people
who
have
responded
so
far
and
I
think
there's
a
couple
more
that
still
need
two,
but
the
highest
number
I
can
find
right
now
is
eight
and
which
is
mondays
at
three
pacific
and
what
you're
seeing
there
is
that
a
number
of
the
people
that
can't
meet
there
can't
meet
there
because,
but
they
could
meet.
You
know
morning
time,
which
is
a
a
more
europe-friendly
time,
so
you
can
see
how
you
could
potentially
make
morning
in
that.
A
A
I
think
for
now
I'll
leave
this
open
for
another
week.
Try
and
get
a
couple
more
responses
here,
but
if
anyone
has
strong
opinions
on
this,
we
do
have
a
pretty
strong
first
choice,
which
is
when
most
you
know,
two-thirds
of
current
respondents
can
meet,
but
if
we
could
get
even
more
than
that,
that
would
be
awesome.
So
maybe
that
does
involve
going
back
to
the
rotating
system.
A
All
right,
and,
of
course,
if
you
haven't
had
a
chance,
please
go
ahead
and
vote
on
this
link
should
be
in
the
agenda
all
right.
The
the
next
thing
I
had
on
here
was
kind
of
an
overarching
topic
that
came
up
related
to
back-end
policy.
What
the
future
is
where,
where
it
belongs,
all
of
the
above
and
so
timeouts.
A
There
was
a
good
conversation
in
a
slack
thread,
maybe
yesterday
fairly
recently,
and
also
tried
to
surface
some
of
the
highlights
from
that
on
a
github
issue
and
there's
there's
been
some
follow-up
conversation
there
as
well.
But
what
I
had
initially
thought
was
a
clear
path
to
portability
or
a
reasonable
path
for
portability.
Between
timeouts,
I
really
became
more
and
more
challenging
as
he
started
to
dig
into
the
nuance
of
what
a
specific
timeout
setting
meant
on
each
implementation
and
there's
what
I've
seen
is
significant
variation.
A
So,
as
an
example,
let's
say
you
split
up
your
your
request
into
a
bunch
of
different
segments.
Some
some
implementations
cover
from
b
to
e,
where
others
cover
from
c
to
d,
and
you
know
it
it's
very
difficult
to
find
a
a
consistent
way
to
configure
this.
That
would
truly
be
portable
well.
B
It
is
there
like
one
way
to
do.
It
is
to
literally
look
at
how
it's
implemented
and
say
the
behavior
has
to
be
100.
The
other
one
is:
are
there
some
so
there's
two
things:
actually
one
of
them
is:
is
there
a
generic
one
that
we
could
implement?
That
is
reasonably
easy
to
explain
that
covers
most
of
the
user
use
cases,
and
then,
of
course,
if
they
have
to
dig
into
it,
they
have
to
get
into
how
the
implementation
specifically
does
it
the
other
one
is
do.
B
Is
it
the
case
that
all
of
these
are
kind
of
separated
out
and
it's
not
meaningful
to
have
a
bunch
of
knobs
and
then
say
hey
if
you're
interested
in
the
specifics,
you
can
go
and
look
at
the
the
specific
implementations,
for
example
right
like
in
csi,
like
let's
say
you
have
like
a
storage
volume,
and
it
has
particular
you
know
like
failure
semantic
like
do.
We
need
to
does
that
need
to
be
specified,
or
is
that
mostly
up
to
the
implementation
like?
What
is
that?
B
A
But
I
highlighted
some
implementations
that
had
some
similarity
here,
so
you
can
see
that
you
could,
if
you
squinted
your
eyes
enough-
and
you
know
tried
to
make
things
look
similar,
you
could
see
some
similarities
between
gcp
envoy
traffic,
aha
proxy
skipper
like
they.
They
have
some
concept
of
timeout
that,
if
defined
broadly
enough,
could
be
considered
similar.
A
So
that
was
that
was
a
path,
but
it
does
notably
leave
out
implementations
and
there
are
fairly
significant
deviations
between
what
each
of
these
timeouts
mean.
So
if,
if
it's
valuable
to
have
just
kind
of
a
generic
timeout
concept
and
each
implementation
can
kind
of
map
it
to
something
similar
to
that
that's
reasonable,
what
I
think
could
get
confusing
is
a
number
of
implementations
have
say
three
or
four
different
timeouts,
that
they
support
and
those
right.
B
Because
from
the
user
standpoint
you
know
what,
if
the
portable
thing
is
just
like
the
easy
button-
and
they
just
say,
I
want
a
timeout
or
I
want
some
timeout
and
then
it's
up
to
the
implementation,
to
kind
of
render
it
into
a
reasonable
policy
from
their
standpoint.
But
it's
not
necessarily
the
case
that
for
the
portable
one
we
need
to
basically
say
you
know
this
time
out
is
for
the
fact
that
the
right
syscall
didn't
return.
B
B
The
request
didn't
finish,
like
basically
there's
some
general
notion
of
a
timeout
in
that
http,
especially
there's
some
request
response
events
and
that
that
chain
had
it
timed
out
right,
like
I'm,
assuming
that
that
is
implementable
everywhere
now,
the
specifics
of
like
did
the
the
packet
or
reads
this
call
happen
or
writes
it
like.
That
is
what
I
consider
to
be
like,
maybe
something
that's
rendered
from
that
more
general.
A
Notion
yeah
there
yeah,
I
mean
there's
room
for
some
concept
of
portability
here.
If
we
define
this
very
broadly
and
generically,
I'm
interested
yeah
carrie
anyone
else
feedback
on
this.
D
D
We
have
been
prescriptive
enough
that
you
know
they
are
at
a
fairly
high
level,
but
users
will
still,
you
know,
expect
things
to
work
across
implementation
in
certain
way,
right
like
it.
Let's
take
a
very
simple
example
of
path.
Matching
right,
that's
become
very
portable,
even
in
like
ingress
v1,
we
work
to
make
it.
You
know
portable,
as
in
like
you,
take
the
spec
and
drop
in
across
multiple
implementations,
and
it
will
work
fine
and
that
provides
some
value
to
the
end
user.
A
B
That's
true,
I
think
it's
a
value
if
we
can
describe
it
in
like
this
is
a
timeout
for
these
http
or
protocol
level.
Events,
for
example,
request
and
response
like
the
timeout
for
that
whole
transaction.
I
think
every
implementation
necessarily
has
to
kind
of
be
built
to
address
that
use
case,
and
that
would
be
the
portable
aspect
of
it.
The
nitty-gritty,
in
terms
of
like,
when
a
specific
thing
might
fire
that
one
might
have
to
be
implementation
specific,
but
the
overall
concept
would
still,
I
would
hope,
be
a
portable
one.
B
Like
let's
say
I
am
coming
to
this,
and
I
don't
necessarily
care
about
the
nitty-gritty,
but
I
do
want
to
say
that
within
10
seconds,
if
this
request
response
transaction
didn't
complete,
then
just
give
me
a
timeout.
Give
me
an
error
in
some
way
like
how
would
that
be
possible?
It
might
not
be
possible,
but
it
just
seems
like
that.
That
is
something
that
is
like
a
use
case
that
people
would
be
very
natural
for
every
system.
D
D
A
A
A
A
Sure,
but
a
request
timeout
is
different
than
that,
like
you
know
like
that,
what
you're
describing
is
more
like
an
idle
timeout,
as,
as
I
understand
it,
right.
B
A
A
A
request
timeout
will
trigger
even
if
you're
still
getting
a
response
like,
even
if,
in
some
cases
you
know
it's
still
being
worked
on
it's
just
taking
longer,
but
the
request
timeout
would
still
trigger
so
you're
still
making
forward
progress,
but
these
timeouts
are
going
to
trigger
because
the
response
isn't
complete
yet
or
depending
on.
I
guess,
like
yeah,.
B
A
D
So
so
the
problem
here
is,
as
we
as
we
have
just
like
you
know,
like
this
discussion
has
demonstrated.
Timeouts
are
notoriously
hard
to
even
communicate
right.
There
is
so
much
language
to
it.
You
know
one
thing
that
means
something
to
me
means
something
else
to
somebody
else
and
if
we
try
to
like
we
can.
D
I
think
what
we
are
trying
to
do
is
doing
something
good
for
the
end
user,
but
if
we
try
to
do
an
abstraction,
we
are
just,
I
think,
increasing
the
problem
of
confusions
with
timeouts
in
the
industry
right
like
right
now
everybody
gets
confused
about
it,
and
then
you
know
we,
we
sort
of
you
know
like
there's
that
xkcd,
where
you
know
you
have
so
many
standards,
time
to
write
a
new
standard.
That's
what
we
are
doing
here
is
what
I
personally
feel
yeah.
B
A
And
and
if
we
can't
do
that,
then
the
it
becomes
difficult
to
see
the
value
in
adding
it
to
the
api
because,
like
like
harry,
had
mentioned
you
you
end
up
in
this
place
where
you
are
either
confusing.
Users
like
timeout
means
something
different
for
each
implementation
or
your
or
you
just
or
other
implementations
are
still
going
to
have
to
provide
their
own
way
of
specifying
their
own
timeouts,
so
minimal
value.
Here,
okay,.
B
B
D
Yeah,
I
think
people
want
to
set
timeouts
right,
but
again
users
in
most
cases
right.
Not
all
cases
want
to
set
time
out.
You
know
at
a
global
level.
I
think
there's
another
issue,
that's
going
on
around.
You
know
like
global
policy
or
something
like
that.
So
if
we
can
somehow
separate
out
this
implementation,
specifics
like
timeout
timeout
is
the
first
thing
we
are
discussing,
but
I'm
sure
there
are
more
such
lower
level
details
right,
which
are
not
guided
by
any
rfcs.
You
know
or
ietf
documents.
D
So
in
that
case,
if
we
use
you
know,
we
have
today
backend
policy,
and
you
know
service
policies
under
discussion.
If
we
use
those
resources
and
somehow
like
lay
out
the
resources
in
a
way
where
we
have
the
portability
aspects
is
inside
like
http
route,
resources
and
gateway
gateway,
resource
is
sort
of
portable,
but
you
know,
then
there
might
be
some
specifics
in
there
right
and
then
then
gateway
class
is
something
very
specific,
very
implementation,
specific,
probably
so
in.
D
If
we
think
about
in
that
pattern,
then
we
can
probably
put
time
out
in
a
play
if,
like
configurations
like
timeout,
should
be
specified
in,
let's
say
back
in
policy.
That's
an
example
not
not
being
prescriptive
here,
but
and
then
there
is
an
extension
point
to
define
timeouts
the
way
you
want
to
define
right,
and
that
gives
us
enough
enough
portability
experience
where
you
know
you
don't
have
to
dig
too
deep
in
you
know
all
resources
when
you
are
porting
from
one
implementation
to
another.
A
Yeah,
I
think
that
transitions
really
well
to
my
overarching
point
here
and
I
don't
want
to
spend
too
much
more
time
because
there's
lots
more
to
get
to,
but
I
and-
and
that
is
that
I
I
was
really
you
know
I
was
trying
to
build
out
back
end
policy
at
for
this
milestone.
So
I
looked
at
timeouts
looked
at
health
checks
and
I
looked
at
retries
of
those
retries
felt
the
less
the
least
portable.
I
could
not
find
good
ways
to.
I
couldn't
find
a
huge
number
of
implementations
that
support
it.
A
A
What
are
the
concepts
in
back-end
policy
that
are
truly
going
to
be
portable
because
even
with
health
check,
not
every
implementation
supports
them
and
the
ones
that
do
support
kind
of
this
core
set
of
functionality,
but
not
everything,
and
so
what?
What
does
that
look
like
for
the
implementations
that
support
more?
Do
they
create
their
own
policy
resource
to
allow
them
to
specify
all
the
health
check
config
that
they
want?
This
is
kind
of
a
broad
question.
You
know
I
I
I
had
a
branch.
A
I
I
have
a
branch
that
I
can
submit
for
pr
for
health
checks,
but
I
kind
of
wanted
to
bring
this
up
as
a
broader
discussion.
Here
is
this:
is
this
something
like
we
want
to
be
in
the
api,
or
is
this
something
that
we
want
to
have
you
know,
as
as
part
of
a
service
policy
concept,
a
policy
concept
where
implementations
bring
their
own
policy?
A
You
know
like
that.
You
know
where,
where
do
we?
Where?
Where
do
we
draw
that
line
between
this
is
a
portable
concept
that
should
be
an
api,
or
this
is
an
implementation,
specific
concept
that
should
be
in
a
policy-like
resource?
That
implementations
can
provide.
B
A
A
Some
of
these
thresholds,
port
that
are
not
necessarily
supported,
and
then
you
have
to
ask
well
how?
How
would
the
implementations
that
support
those
allow
for
them
to
be
configured.
A
B
So
I
guess
what
I'm
saying
is:
instead
of
this
table
like
we
can
sort
of
sketch
out,
like
let's
say,
no
shared
object,
how
would
people
play
it
out
shared
object
and
then
combination
of
custom
stuff
yeah,
because
it
seems
like
the
custom
stuff
is
gonna
exist?
No
matter
what
like
there's?
No,
I
don't
know
if
we
can
get
around
that,
it's
mostly
like
the
coexistence
of
them.
B
What
would
that
look
like
yeah?
It
sounds
like
we're
getting
to
a
place
where
it
doesn't
make
sense.
We
just
need
to
double
check
that
through
an
example,
I
think
if
we
write
out
the
example,
then
that
that
would
probably
make
the
arguments
more
concrete,
like
you
could
actually
point
to
the
fact
that
one,
if
you
can't
do
something,
it's
a
clear
indication
that
something's
wrong
and
then
to
kind
of
look
at
it
and
see
like
how
would
someone
manage
it.
A
Yeah
yeah
like
right
now.
I
think
our
our
strongest
case
for
portability
at
this
level
is
health
check,
but
even
that
has
issues
and
if,
if
anyone
else
has
ideas
of
other
concepts
that
might
be
portable
that
could
attach
to
policy,
I
am
very
interested,
but
I
think
I
think
that's
enough
discussion
on
this.
I
I
think
I'm
going
to.
I
do
have
that
branch,
but
I'm
not
sure
that
I
that
health
checks
belong
like
that.
We
should
introduce
health
checks
to
the
api
if
we're
still
not
sure
about
it.
A
B
Yeah,
because,
at
the
end
of
the
day,
like
the
use
that
that's
what
we're
giving
the
user
and
we
could,
for
example,.
B
A
D
On
the
hilltech
side,
I
think
if,
if
enough,
if
most
implementations
do
support
it,
and
then
it
might
be
worth
experimenting
with
the
feature
in
in
the
extended
space,
extended
conformance
space
and
seeing
like
how
you
know
essentially
how
the
community
like
reacts
to
it
like
do
that?
Do
people
like
it
do
people
not
so
it
might
be
worth
experimenting.
Let
me
we
need
to
experiment
a
little
bit
with
back-end
policies
like
or
some
policy
early
like
right
now,
otherwise,
the
whole
whole
concept
of
you
know.
D
Portability
of
you
know
these
lower
level.
Things
goes
out
right
and
maybe
it's
it.
It's
it
wants
only
enough
to
not
know
like
the
api
is
vague
enough,
that
there
is,
it
allows
for
extension,
points
and
backing
policy
that
are
well
defined.
That's
all
right,
so
you
define
timeouts
and
health
checks.
The
way
you
want,
but
this
is
how
you
should
you
know,
define
define
them
right.
The
details
and
semantics
can
change,
but
there
is
at
least
like
when
users
are
moving
from
one
implementation
to
another.
They
are
not
completely
surprised.
You
know.
B
Yeah,
I
think,
like
back-end
policy,
was
almost
a
design
pattern
versus
an
actual
thing.
Unfortunately,
there's
like
no
way,
except
for
in
just
like
the
script
like
pros
to
kind
of
just
describe
design
patterns
it
yeah.
I
do
agree
like
it's
worth,
pushing
it
a
little
bit
just
to
understand
how
it
will
break
and
that
was
kind
of
aligned.
With
my
my
statement
about,
let's
put
together
an
example
doc
to
like
really
push
it,
so
we
can
unders
get
in
some
sense
of
how
it
breaks.
A
Yeah,
that's
fair
there.
There
is,
if
we
have
time,
I'm
not
sure
if
we
will
there
there's
further
discussion
around
back
end
policy
and
really
service
policy.
If
we
get
to
issue
triage,
but
I
I
think
that
back
end
policy
is
inevitably
going
to
transition
to
a
model
like
service
policy.
A
The
question
becomes-
and
I
think
this
is
an
overarching
question
with
service
policy-
is
if
any
of
the
policies
that
that
model
refers
to-
or
you
know
includes,
are
actually
core
resources
in
the
api
or,
if
it's
more
of
a
model
for
attaching
custom
implementation,
specific
policy
resources
but
like
like
you're
saying
we
do
need
to
experiment
to
some
degree
with
this
to
get
a
better
understanding
of
how
things
actually
interact.
E
Rob
I'll
just
say
one
thing:
I
think,
the
the
complexity
of
using
both
actual
customer
like
I'll
call
it
yeah
custom
service
policies
and
also
extended
service
policy
resources
like
one
that
would
be
a
standard
service
policy.
That's
used
by
all
implementers.
E
I
think,
there's
a
lot
of
complexity
in
in
juggling
both
kinds
of
resources
and
that
maybe,
if
they're
yeah
yeah,
but
I
just
don't
know
if,
if
it's
worth
it,
it
feels
like
it's
too
much
complexity,
so
that
if
there
is
kind
of
like
health
check,
maybe
that
just
goes
into
everybody's
custom
service
policy,
or
maybe
that
goes
into
some
of
the
core
resources
like
route.
I'm
not
sure,
but
I
definitely
think
that
juggling
both
kinds
is
going
to
be
a
little
complex.
A
Yeah
that
I
mean
that's
exactly
what
I
was
struggling
with
right.
You
know
with
health
checks,
it's
portable
for,
let's
say
five
of
the
seven
fields
implementations
might
want
to
support.
So
for
those
two
other
fields.
What
do
we
do?
Do
they
support
them
in
their
custom
service
policy,
in
addition
to
their
yeah.
E
You
know
you
wouldn't
want
to
split
your
health
check
config,
so
the
minute
you
have
one
additional
field
within
that,
like
configuration
block,
then
it's
like.
Oh
you
have
to
move
wholesale
to
the
custom
service
policy,
at
which
case
you
basically
have
to
support
all
the
extended
fields
that
exist
and
the
custom
ones
in
every
service
policy.
B
A
Okay,
well
I'll,
follow
up
with
that
and
link
it
to
an
issue,
and
in
slack
all
right.
Let
me
let's
start
moving
on
the
milestone,
because
that
is
really
what
we
need
to
get
in.
Harry's
done
some
awesome
work
on
the
admission
web
hook
server.
I
tested
it
out
myself
and
it
worked
perfectly
first
try
for
me.
At
least
I
know
this
is
also
building
on
chris's
work
from
before.
A
D
Yeah
so
yesterday
I
spent
a
bunch
of
time
looking
at
how,
like
you
actually
do
like
we
have
some
code
and
now
into
build
and
push
it
to
like
a
docker
registry.
So
I've
gone
through
a
bunch
of
rooms
and
there
is
some
work
to
do
there
and
we
need
to
rely
on
external.
You
know
like
that,
pr
that
you
just
linked
in
the
comment
we
need
to
get
that
merged
in
and
then
we
need
to
ping
some
folks
to
create
google
groups
and
reports,
and
things
like
that.
D
So
there's
that
side
of
work,
what
I
was
hoping
was
if
somebody
else
can
also
review
this
and
if
you
can
sort
of
get
this
pull
request
marched
in,
so
that
it
is
in
the
code
and
if
you
know
we're
making
any
code
changes.
You
know
this
is
part
of
the
mainline
trunk
and
then
getting
actual
build
out
requires
us
to
add
a
couple
of
files
to
the
repo.
It
requires
an
additional
pro
job
and
then
it
requires
setting
up,
like
renaming
our
service
apis
to
gateway
apis
repo.
D
A
Yeah,
I
think
I
think
you're
right
that
this
is
kind
of
a
chicken
and
egg
problem
where
we
can't.
We
can't
solve
this
entirely
without
getting
some
con.
Some
part
of
this
in
first
it
feels
like
we
do
need
at
least
the
web
hook
code
in
before
we
do
anything
beyond
that.
A
I
one
concern
I
have
like
one
of
one
of
your
suggestions
was
to
add
a
to-do
here,
instead
of
using
that,
I
think
that's
reasonable,
I'm
wondering
if,
in
addition
to
that,
we
also
need
some
kind
of
comments
or
something
to
make
it
clear
that,
although
this
yaml
exists,
it's
not
quite
ready
for
use
just
to
clarify
that
we
have
a
web
hook.
It's
checked
in,
but
it's
still
very
much
work
in
progress,
but
it
does
seem
like
if
I'm
understanding
the
other
bits
of
the
process
correctly.
A
D
Yeah
we
disk
and
then
there's
another
cloudbuild.yaml
file
that
we
need
to
check
in
into
main
and
then
and
then
test.
Then
then
the
brow
does
its
thing
and
then
fix
things
if
things
don't
work
as
they
should,
but
but
I
mean
we
can
add
cloud
build.tml
to
this
pr.
It
requires
some
other
changes
in
the
code
base
and
then
merge
that
or
we
can
merge
this
and
then
you
know.
Okay,
we
want
to
update
the
make
file
and
sort
of
all
the
other
plumbing
around
it
and
that
can
be
a
separate
beer.
A
A
All
right,
steve
you've
got
a
you.
You
ended
up
creating
this
pr,
which
is
for
gateway
listener,
and
we
really
we
la
in
the
last
meeting.
We
labeled
this
as
critical
urgent
doesn't
like
that.
We
really
wanted
to
get
in.
I
think
this
is
awfully
close.
There
was
just
some
confusion
around
naming
here
lots
of
discussion
around
naming
my
latest
suggestion
here.
A
I'm
interested
in
feedback
on
would
be
like.
There
was
confusion
if
we
called
this
back
end
ref
or
if
we
called
this
forward
too,
because
those
already
have
existing
meaning
in
the
api
elsewhere,
and
since
this
feels
more
like
a
shortcut,
a
a
route
shortcut,
I
was
curious
if
we
could
use
route
2..
C
Okay,
yeah,
I'm
not
sure.
I
know
I
did
the
pr,
but
I
I
guess
chat
about
it.
Why
I
didn't
want
to
do
any
more
until
we
sort
of
kind
of
landed
on
some
sort
of
agreement
on
how
to
handle
it
in
a
way
you
know
yeah
yeah,
I
I
I
think
that
could
work.
I
don't
know
sometimes
route,
I
think
of
like
l7
route,
but
maybe
that's
just
my
my
history
with
contour
and
that's
what
I
think
of.
First,
that's
fair
yeah.
E
Yeah,
I
don't
know,
I
think
I,
and
it
makes
sense
only
because,
like
what
we
want
to
do
is
basically
have
a
it's
a
route
shortcut
right
and
in
all
the
three
cases
we
talked
about
using
this,
whether
it's
for
doing
a
route
shortcut
for
a
tcp
to
skip
over
a
tcp
route
or
to
skip
over
an
http
route.
All
cases
are
route
shortcuts.
So
I
think
using
a
new
name
like
that
does
make
sense.
E
F
So
something
that
comes
to
mind
with
this
shortcut
is
without
the
shortcut
we
kind
of
have
this
bi-directional.
You
know
binding,
so
it's
like
a
service
owner
can
say
you
know,
even
though
a
gateway
exists
right.
I
want
to
make
sure
that
my
route
doesn't
automatically
bind
to
the
gateway.
I
mean,
how
do
we
support
that
same
concept
with
a
shortcut
and
if
we
don't
support
it,
you
know
is:
is
that
a
concern.
A
Yeah
this
this
is
currently.
This
is
currently
scoped
the
same
name
space
only,
but
I
I
agree
with
the
point
danian
made,
and
but
I
think
that
there's
a
little
bit
of
nuance
there
in
that
right
now
the
two-way
handshake
we
have
is
between
gateway
and
route.
A
What
we
don't
have
is
a
two-way
handshake
between
route
and
service,
but
we
probably
do
need
that
if
the
route
service
relationship
ever
ends
up
crossing
a
namespace
boundary-
and
I
think
whatever
we-
if
we
did
that-
and
I
don't
know
if
we
should-
but
if
we
did,
that
should
be
solved
the
same
way
as
it
is
here,
but
right
now
both
of
these,
whether
it's
a
route
to
service
relationship
or
a
gateway
to
service
relationship.
Our
same
namespace.
B
G
Agree
with
rob
today
today
our
routes
can't
be
crossed.
Namespace
I
mean
they
can't
reference
a
service
in
another
namespace.
So
neither
should
this,
but
I
do
think
that
we
should
make
the
browse
across
native
space,
in
which
case
this
would
also
be
cross
namespace,
but
we
don't
necessarily
need
to
mix
them.
A
Right
and
we've
already,
you
know-
we've
we've
already
been
very
clear.
This
is
a
shortcut.
This
is
not
a.
This
is
not
going
to
have
the
full
functionality
of
route.
It's
not
going
to
have
traffic
splitting
or
anything
else.
This
is
really
just
a
shorthand
for
a
route
that
that's
and
keeping
the
scopes.
Tiny
is
very
important,
I
think
so,
I'm
fine,
if
if
we
really
leave
it
as
service
name
and
port,
I
think
this
is
really
meant
to
make
l4
specifically
more
practical,
though
it
also
has
other
helpful
use
cases.
D
Yeah,
I
think
I
agree
with
like
keeping
this
as
simple
as
possible
and
like
using
other,
more
complicated
features
to
achieve
anything
more
because
if
you
actually
look
at
it,
you
can
just
you
can
do
cp
and
udp
like
pass
through
using
this,
but
you
can
also
do
like
like
if
you
want
to
do
tls
terminations
and
then
do
a
tcp
by
stream.
You
can
also
do
all
that
and
you
can
do
some
complicated
stuff
as
well.
Using
this.
A
F
Was
just
gonna
ask
I
haven't
had
a
chance
to
to
look
at
this.
A
quick
question
would
be
is
if
this
shortcut's
meant
for
layer
four.
Is
the
spec
updated
with
this
pr
that
that
specifies,
like
the
kind
must
be
ud?
You
know
udp
route
or
tcp
route.
A
F
A
A
D
So
so
now
no
one
can
define
like
routing
inside
the
gateway
itself
right.
So
if
somebody
could
figure
out
an
outback
policy
where
the
route
owners
have
right
access
to
gateway
resource
and
then
the
gateway
resource
like
each
supposedly,
there
is
a
business
use
case
where
each
tcp
ports
gets
forwarded
to
a
an
application
right.
So
then,
the
owner
of
that
service
creates
a
gateway
with
that
tcp
port
and
forwarding
to
the
service
of
that
team.
D
A
Okay-
well
maybe
this
maybe
this
pr
does
need
a
bit
more
discussion,
all
right.
It's
funny!
I
I
I
know
when
we
initially
had
the
issue.
It
seemed
like
it
was
a
fair,
a
fairly
straightforward
idea,
but
yeah
as
we've
dug
into
it
further.
Maybe
there
are
areas
where
we
need
more
discussion.
D
I
think
if
we
keep
this
simple,
we
don't
need
much
discussion.
If
you
just
keep
like,
you
cannot
just
say
same
name,
space
just
follow
to
the
service,
I
think
then
become.
The
simplistic
case
is
okay
yeah
about
all
of
these
more
complicated
problems.
Otherwise
we
cannot
do
the
simple
use
case.
Right
shortcut
is
for
simplicity,.
E
Yeah,
I
think
the
intention
was
to
basically
model
what
or
to
to
make
this
more
comparable
to
the
service
load,
balancer
type
yeah
and
which
is
in
you
know
in
the
same
name,
space
and
kind
of
the
same
security
model,
because
if
you
can
create
a
service,
then
you
can
expose
it,
but
the
I
mean
it
implies
that
the
service
owner
also
owns
the
gateway
like
I
might
my
at
least
my
assumption
was
that
in
this
case,
yeah
the
service
owner
would
would
be
creating
the
gateway
as
well.
E
I
know,
there's
no
way
with
kubernetes
are
back
at
least
I
think,
to
specify
what
kind
of
gateways
you
can
create
like,
depending
on
the
gateway
class,
but
ultimately,
for
there
to
be
likes,
you
know
the
ability
to
create
layer,
4
gateways,
but
not
layer,
7
gateways
would
require
something
like
gatekeeper.
I
think
to
actually
pull
that
off
yeah.
We.
A
Yeah
we
provided
some
sample
policies
or
a
sample
policy
that
would
implement
that,
but
you're
right.
I
it's
it's
hard
for
me
to
think
of
a
use
case
where
someone
would
have
access
to
create
gateways
in
the
namespace,
but
not
services
it
just
it
feels
it
feels
like
gateway.
Is
such
an
elevated
resource
in
terms
of
control.
A
Yeah,
I
think
that's
fine.
I
I
think
it's.
I
think
it's
reasonably
safe,
at
least
for
my
understanding
to
assume
that
a
gateway
owner
has
control
over
services
in
the
namespace.
It
has
control
over
gateways
in,
or
at
least
is
trusted
enough
that
you
know
you,
you
assume
someone
with
control
of
gateways
in
a
namespace
is
highly
trusted.
A
Okay,
all
right!
Well,
if,
if
there's
any,
maybe
if
there's
any
opposition
to
this
or
additional
feedback,
add
it
to
this
pr
soon,
but
otherwise
I
would
like
to
get
it
in.
I
think
this
is
you
know,
based
on
what
we've
been
going
for
for
this
milestone.
A
We
really
do
want
to
get
these
kinds
of
helpful
features
in,
and
you
know
we
still
have
the
ability
to
break
things,
but
right
now
I
think
this
is
a
you
know,
requested
feature
that
would
be
helpful
and
I
I
would
lean
towards
getting
it
in
myself
at
least.
A
A
Cool
well,
I
know
we've
got
more
to
go
through,
but
if,
if
someone
has
time,
please
take
a
look
and
review
that
one.
A
Okay,
so
adding
a
controller
this,
I
think
this
is
one
of
the
most
straightforward
ones.
This
came
from
an
issue
earlier.
A
I
think
john
had
filed
this,
that
it
could
be
confusing
to
clean
up
status
route
status
if
you
didn't
know,
as
a
controller
that
you
previously
owned
a
gateway,
and
so
these
the
solution
that
we
came
to
in
that
issue
was
to
add
controller,
to
status,
add
to
the
gateway
reference
in
status,
so
that
you
can
clearly
find
all
all
gateways
that
you
as
a
controller
added
to
status
for
a
route
and
therefore
can
remove
them.
B
C
B
C
A
B
A
That
works
one
more
tiny
follow-up
here.
This
is
a
pr
based
on
some
feedback
that
we
did
not
have
clear
guidance.
If
there
was
a
conflict
within
a
route-
and
you
know
you
had
basically
an
equivalent
role
within
a
route.
This
adds
that
this
is
again
based
on
an
issue,
and
I
think
we
have
relative
consensus
on
this
one,
so,
hopefully
not
too
controversial,
and
the
last
one.
A
A
But
if
you
don't
feel
like
you
have
time
to
take
this
on,
we
can
try
and
find
someone
else
for
it
too.
I
just
want
to
make
sure
we
can
get
it
in.
A
Thanks
awesome,
yeah
thanks
sounds
good.
Okay,
that's
all
I
had
and
I
think
I
think
we
don't
have
enough
time
to
get
into
back-end
policy
discussion,
but
I
do
want
to
highlight
it
for
anyone
who's
interested
in
all
the
policy
conversation
going
on.
I
thought
there
were
really
good
updates
and
discussion
here
with
john
and
mark
on
both
that
issue.
That's
583
and
6
11,
which
is
the
service
policy
issue
and
great
conversation
in
both
cases.
A
So
if
you
want
to
continue
the
conversation,
I
think
both
these
updates
are
great,
but
I
don't
think
we
have
enough
time
to
cover
them
today.