►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20220927
Description
Gateway API GAMMA Bi-Weekly Meeting for 20220927
B
Can
kick
us
all
off
all
right?
Welcome
everybody
to
the
September
27th
Gateway
API
meetings.
This
is
at
8am
Pacific
time.
As
always,
the
communities
contact
rules
are
in
effect,
so
please
screenshot,
respectfully
and
feel
free
to
add
your
name
to
the
attendees
list.
So
we
can
keep
track
of
who's
able
to
make
these
meetings.
And
if
you
have
anything
that
you'd
like
to
talk
about
it's
an
open
Agenda,
so
please
feel
free
to
add
anything
to
the
remix
section,
foreign.
B
I
guess
we'll
wanted
to
kind
of
Kick
this
off
with
a
summary
of
what
happened
during
last
week's
Gateway
graduated
for
folks
who
I
think
most
folks
were
able
to
attend
that
one.
But
if
you
missed
it,
please
like
it,
is
well
worth
your
time
to
check
out
the
reporting
we
or
I
guess
presented
the
depth
proposal
for
HQ
root
mesh
binding.
So
this
is
kind
of
our
first
like
substantial
ux
for
how
we
might
hope
to
actually
get
gamma.
Implementable
is
kind
of
going
to
be
the
goal
for
for
that.
B
So
there
were
many
good
questions
during
that
meeting
that
came
up
if
you're.
If
you
have
questions,
they
were
that's
definitely
a
chance
that
somebody
else
has
already
thought
of
them
and
already
asked
them
during
that
meeting.
So
it
is
well
worth
checking
that
out,
but
kind
of
what
is
the
current
status
now
is.
B
I
am
working
on
updating
this
proposal
and
I'm
going
to
move
it
to
a
formal,
Gap
and
open
the
pr
and
with
the
intent
of
protecting
it
to
the
broader
Gateway
API
median
next
Monday,
so
that
would
be
October
3rd
is
the
plan
for
that.
B
And
yeah
I
guess
the
tlgr
is
it's
proposing
to
advance
the
direct
finding
from
HTTP
route
to
kubernetes
service
approach.
There's
several
other
approaches
that
were
documented
as
alternative
ideas
in
there,
but
that's
the
one
that
we
felt
made
the
most
sense,
given
the
trade-offs
and
would
be
the
most
direct
for
understanding,
specifically
the
transparent
proxy
functionality
and
making
that
clear
ux
for
users.
B
B
So
with
that,
are
there
questions
that
any
folks
have
on
that
proposal
or
kind
of
like
next
steps
or
other
topics
that
which
we're
interested
in
talking
about
I
know
that
Keith
kind
of
wrapped
up
the
meeting
last
week
with
with
kind
of
an
open
invitation
to
consider
what
we
should
move
to
next,
because
there's
certainly
there's
a
vast
scope
of
service
mesh
functionality,
and
it
would
be
great
to
have
some
ideas
about
where
we
should
go
from
here.
A
Well,
I'll
ask
again:
if
there's
anything
I
can
help
with
in
terms
of
that
Gap
preparation,
the
Gap
is
going
to
cover
the
traffic
splitting
case
correct.
A
Yeah,
it's
a
little
tough
for
me
to
suggest
the
next
thing
we
should
cover
until
knowing
which
things
were
are
going
to
be
in
that
one
right
sure
timeouts
and
reaches
immediately
to
mind.
But
that's
you
know,
policyish
stuff.
A
One
of
the
other
things
that
we're
wrestling
a
little
bit
with
over
on
the
buoyant
side
of
the
world
with
linkerty
is
the
distinction
between
client-side
policy
and
server-side
policy,
where
that
ends
up
being
pretty
meaningful
in
our
world,
and
so
that
may
be
something
that
is
worth
talking
about.
Maybe
next
time
but
yeah.
C
Maybe
maybe
I'm
feeling
ambitious,
because
we
made
some
some
smaller,
but
it
almost
feels
like
that's
like
a
good
thing
to
actually
tackle
next
authorization
policy,
I
think
is
important
and
it
tackles
that
problem.
So
that
could
be
a
place
to
go.
Authorization.
A
C
C
A
Yeah
I
think
I'd
be
fine
either
way
there
auth
Z
might
actually
make
a
little
more
sense
to
tackle
first
because
it's
I
feel
like
that
might
be
a
little
bit
more
applicable
to
every
mesh
out
there
always
100
of
the
time,
and
so
let's,
let's
let's
tackle
that
one
next
that'll
be
fun.
Yeah.
C
I
was
also
planning
not
for
like
a
different
policy
type,
which
I
think
adds
more,
but
for
Route,
specifically
to
have
consumer
oriented
routes.
I
was
I,
am
planning
like
an
addition
to
Mike's
proposal
so
I,
but
we
can
do
that
in
parallel.
I
think
we
don't
need
to.
You
know
only
do
one
thing
at
a
time:
I,
don't
think
it's
that
big
of
a
can
of
worms
like
the
the
implementation
is
kind
of
obvious.
C
Once
we
already
have
this
as
long
as
we
agree
that
we
should
do
it
that
way,
it
may
be
controversial,
I
think
but
I
don't
think
there'll
be.
You
know
a
lot
of
work
in
deciding
what
it
should
be
once
we
kind
of
have
this
Baseline,
which
is
why
I'm
super
happy
that
we've
at
least
gotten
to
this
point
already
yeah.
D
But
I
I
would
say
that
authorization
policy
and
few
other
things
probably
would
be
better
discussed
in
common
with
a
Gateway
API,
because
authorization-
it's
for
example,
is
super
important
for
gateways
as
well
and
again.
Last
Gateway
meeting
was
also
very
interesting
about,
and
overlapping
with
what
we're
discussing
about
service,
binding
or
attaching
policies
like
back-end
policies
and
other
things.
So
we
have
our
own
view
of
the
world
compared
to
Gateway
API,
but
many
of
those
things
will
definitely
need
to
be
shared
between
them.
D
B
Yeah
definitely
agree
that
we
should
record
it
together
and
make
sure
that
we're
clear
about
this
ambiguity
like
where
it
makes
sense
to
like
use
things
that
may
already
exist,
like
reference
Grant
or
where
those
things
may
need
to
be
extended
to
add,
like
L7
policy
support
or
whether,
where
places
like
policy
attachment
or
something
like
that,
may
make
more
sense.
So
yeah
definitely
something
to
work
on
together,
so
that
we
have
a
consistent
model
across
all
of
Gateway
API.
Very
much
agreed
and
yeah
I.
B
Just
one
thing
that
came
up
during
the
proposal
for
the
responding
that
I'm
working
on
a
like,
separate,
smaller
gift
kind
of
like
keep
that
are
contained,
is
about
how
mesh
and
Gateway
routes
should
interrupt,
should
or
should
not
interoperate.
B
So
there's
kind
of
two
different
models
there
of
what
like
and
it's
more
focused
on,
like
a
single
vendor
case,
where
you
have
say:
console
API,
Gateway
in
front
of
console
service
mesh
or
an
SQL
Gateway
in
front
of
sto,
where
routes
that
have
traffic
coming
in
through
a
Gateway,
whether
that
is
automatically
following
gamma
mesherality
rules
or
whether
it
should
require
some
kind
of
explicit
configuration.
B
So
that
was
a
significant
question
that
came
up
and
I'm
planning
to
do
a
separate,
smaller
Gap,
just
to
kind
of
cover
the
various
options
we
may
have
up
there.
A
B
D
Yeah,
maybe
that
would
be
the
first
to
do
to
agree
because
many
implementations
have
put
Gateway
and
mesh
and
that
will
cause
a
lot
of
user
confusion
if
we
don't
have
common
approach.
B
Yeah,
exactly
and
and
also
are
we
setting
up
users
for
missed
expectations
for
like
multi-vendor
deployments,
so
that's
definitely
a
consideration
as
well.
D
On
Gateway
about
delegation
or
composure
or
routes,
and
that's
kind
of
the
same
thing
in
anyways,
we
should
qualify
it
to
that
group
as
well.
B
D
It's
a
kind
of
words,
I
mean
we
need
this
to
to
have
to
kind
of
be
consistent
with
that
with
the
working
group,
managing
better
policy
and
and
see
if
they
extend
ourselves.
Do
your
duplicate,
the
overlap,
how
they
compose
this
kind
of
stuff,
I.
Think
it's
it's
important
to
to
get
I
mean
it
will
be
a
large
another.
Big
discussion
like
we
had
with
with
this
one.
B
And
son,
you
have
a
question:
is
parent
refs,
optional?
Yes,
sorry,
I'm.
E
Just
catching
off
with
this
yeah,
so
my
key
question
is
whether
this
is
optional.
It
wasn't
clear
on
the
document
you
guys
might
have
discussed
this
last
week
as
I
joined
a
little
bit
late
last
week,.
B
Well,
it's
optional
in
the
sense
of
a
route
can
have
zero
or
more,
but
unless
you
specify
at
least
one,
that
route
will
not
be
in
effect,
it
would
not
be
applied
to
anything
and
I'll.
Be
configuring.
Anything
I,
I,
don't
know
if,
like
the
web
hook
like
rejects
things
that
have
zero
paragraphs
specified
but
like
in
practice,
you
should
typically
have
at
least
one
I
think.
E
C
E
C
Yeah
sure,
that's
that's
how
it
works
in
HBO.
That's
in
two
places:
it's
not
terrible,
but
it's
yes,
but
the.
A
C
C
C
A
C
C
B
B
That
may
or
may
not
be
something
that
is
controversial,
but
that's
I
think
the
most
possible
password.
If
there's
an
interest
in
making
it
less
for
you,
yeah.
C
F
C
C
Useful
is
like
Port
things
because,
for
example,
if
you
have
a
service
with
multiple
ports-
and
you
say
my
parent
is
service
Foo
and
then
send
to
who
on
Port
80.
well,
now
did
I
accidentally
redirect
I,
don't
know
Port
90
to
Port,
80
and
I
didn't
actually
mean
to
so.
We
do
have
a
port
as
parent
ref,
where
they
could
do
the
correct
thing
right.
They
could
say
it
match
Port
80
on
Foo
and
send
to
Port
80
on
Foo,
but
maybe
they
forgot
right.
C
A
F
Yeah,
because
it's
something
that
we're
thinking
of
using
for
Lincoln's
policy
attachment
and
one
of
the
questions
that
we
had
is,
can
you
actually
use
named
ports?
So
if
the
service,
for
example,
has
a
name
to
Port,
can
you
use
that
in
the
routes
parent
ref.
A
F
Yeah,
so
the
the
basic
idea
is
that
the
port
name
results
in
a
required
translation
of
instead
of
a
port
number,
which
represents
a
single
port
number.
A
port
name
can
refer,
represent
a
different
port
number
per
backend,
which
can
be
frustrating
to
implement
foreign.
A
F
Agree
with
all
of
that
mistakes
of
the
past
that
we're
trying
not
to
propagate
any
further
that's
yeah
well,.
A
And
you
know,
realistically
the
reason
why
people
would
do
it
is
that
they're
trying
to
do
in
the
mesh
case
they're
trying
to
do
something
like
you
know,
I,
don't
know
a
b
testing
and
the
B
version
of
the
port
listens
to
B.
Version
of
the
service
listens
on
a
different
port
for
whatever
reason
right,
yeah
yeah.
D
C
D
C
D
It's
very
confusing,
since
back
and
Port
is
different
than
service
port,
and
there
are
kind
of
other
issues,
section
name
and
and
using
the
port
name
there
or
putting
this.
Your
name
or
string
has
other
benefits
in
terms
of
flexibility.
A
D
A
F
No,
it's
just
about
the
same
thing
as
costen
I
think
we
see
a
lot
of
people
use
port
names
and
we
personally
use
them
as
well.
So,
for
example,
for
admin
ports,
we
never
used
a
port
number.
We
used
a
port
name
so.
B
B
B
B
Yeah
I
guess
with
that
thanks.
Everyone
for
coming
I,
really
really
appreciate
it
and
yeah
looking
forward
to
presenting
our
first
like
implementable
proposal
next
week
about
stroke,
API
meeting.
So
thanks
everyone
for
your
participation
and
review
of
the
doc
so
far
and
yeah
have
a
good
rest
of
the
day.
Y'all
foreign.