►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20220920
Description
Gateway API GAMMA Bi-Weekly Meeting for 20220920
A
A
B
A
Yes,
it's
a
lot
of
context
and
the
reason
I
want
to
bring
this
up
is
not
because
it's
a
fun
point.
It's
not
because
these
those
slack
threads
were
off
base
in
any
sort
of
way
or
unnecessary.
Again
again,
those
were
very
useful
information,
but
kind
of
as
a
matter
of
of
I,
guess,
I,
guess,
focus
and
and
reiterating
our
goals.
A
You
know
everything
that
we
are
proposing
here.
As
far
as
talking
about
service,
binding
or
or
method
presentation
things
like
that,
it's
all
within
the
experimental
channel
of
of
Gateway
API
and
to
a
further
extent
we
are
hoping
to
you,
know
to
to
move
quickly.
We
set
that
kind
of
the
outset
of
this
lack
of
buttercream
experiment
with
a
gamma
and
we're
hoping
to
you
know,
like
I,
said,
move
forward
quickly
and
to
iterate
on
on
the
different
approaches
and
so
I.
A
What
I
you
know
and
cautious
of
as
as
a
lead
of
gamma,
is
that
we
don't
get
so
caught
up
in
making
something
perfect
that
we
don't
end
up
making
anything
at
all.
There
will
always
be
another
degree
of
another
Edge
case
to
add.
On
another
thing,
you
could
just
write
an
API,
but
I
I
just
want
to
acknowledge
that
you
know
we
all
write
software
for
a
living.
C
C
C
D
B
One
of
the
prevailing
questions
about
one
of
the
prevailing
questions
that
showed
up
often
in
those
slack
threads,
was
to
the
tune
of
right.
So
is
the
point
of
gamma
to
be
capturing
a
common
API
for
things
that
people
are
already
doing
versus
the
point
of
gamma
to
be
coming
up
with
new
things
that
people
should
be
doing
and.
C
C
C
C
Yeah
sure
sure
I
can
I
can
handle
that
so
so
one
other
thing
I
should
be
clear.
On,
though,
is
one
of
the
reasons
I've
been
objecting
about.
This
is
some
of
this
stuff
is
that
I'm
I
have
had
to
get
an
API
past
the
Upstream
API
machine
reviewers,
and
a
lot
of
the
objections
I
am
making
are
the
ones
that
they
will
make.
C
So
you
know
like
be
be
aware
that,
like
you
know
that
you're
gonna
need
to
make
good
cases
for
some
of
the
stuff
that
you're
talking
about,
if
it's
not
if
it
doesn't
fit
in
under
the
API
guidelines,
then
you're
gonna
need
to
have
a
really
good
reason
why
it
doesn't.
Okay,
that's
where
we
are
going
to
need
to
do
that.
Sorry,
you
know
like,
and
but
you.
A
It's
a
good
call
out
there
I'll
just
this
popped
into
my
into
my
head
because
of
some
some
reading.
I
was
doing
the
past
couple
of
days.
Chris
Nova
had
a
article
about
imperfect
systems
and
inevitability
of
imperfect
systems
and
there's
a
quote
in
there
that
more
Plus
Engineering
teams,
but
I
think
is,
is
has
consequence
for
what
we're
doing
here.
A
At
least
it's
my
perspective
doesn't
mean
that
we
should
that
we
should
just
completely
forget
about
correct
this.
I
I
appreciate
a
lot
of
the
objections
that
Nick
has
raised
because
I
think
it's
important
to
talk
about
them
and
to
go
through
that
process
of
weighing
something
that
might
be
more
technically
correct
versus
something
that
might
have
a
smoothie
experience.
A
Trade-Offs
are
the
name
of
the
games.
What
we
do
so
I
value
that
exercise,
but
I
also
think
that
it's
important
to
remember
that
users
aren't
imperfect
in
their
CI.
Cd
pipelines
are
imperfect
and
you
know
are
likely
going
to
be
imperfect
and
they're
going
to
be
any
in
number
of
imperfections
that
exists
in
the
consuming
systems
and
that's
something
that
we
need
to
be
aware
of.
F
All
right
so
yeah,
I
guess.
Over
the
past
weeks,
we've
gone
through
We've
shared
the
each
group
mesh
finding
get
proposal
document
thanks
and
I've
gone
through
recently
and
tried
to
clean
up
some
of
the
existing
comment.
Threads
tried
to
clarify
some
of
the
goals
and
non-goals
suggestions
that
seem
to
have
mostly
reached
consensus,
and
after
discussing
with
Keith
and
John
as
the
code
weeds,
we
want
to
propose
to
move
forward
with
the
direct
finding
to
Service
at
with
the
parent
rough
field.
F
So,
to
start
with
kind
of
like
one
of
to
like,
if
I
kind
of
like
Flint's
point
was
that
we
think
this
most
accurately
reflects
how
users
conceptually
think
of
the
way
that
Services
relate
to
each
other
in
the
mesh
correctly
and
then
also
from
the
user
perspective.
This
was
the
most
direct
way
to
support
a
transparent
proxy
implementation.
F
F
It
would
potentially
introduce
a
lot
more
layers
of
abstraction
and
make
it
harder
to
reason
about
where
that
configuration
is
happening,
and
then,
finally,
one
of
the
nice
benefits
of
this-
is
that
it's
flexible,
where
it
does
not
require
any
immediate
changes
to
http
root.
It
does
not
require
us
to
figure
out
how
to
do
experimental
fields
on
HTTP
root,
and
it's
extensible
such
that.
F
So
yeah
I've
gone
through
into
the
document
and
I'm
currently
working
on
adding
some
of
the
context
to
the
mesh
service,
I
I
think.
Ultimately,
the
issue
that
message
is
trying
to
solve
is
an
upstream
concern
with
an
overloaded
service
resource
and
really
the
best
long-term
way
to
solve.
That
is
probably
an
upstream
cap
and
the
approach
that
we're
proposing
with
direct
binding
Service.
It
would
minimize
the
churn,
but
not
foreclose
the
possibility
of
us
moving
to
something
like
that
if
it
has
promise
and
traction
stream.
So
that's.
F
F
B
Yeah
for
the
record,
I
need
to
read
this
more
carefully,
since
my
life
has
been
a
little
complex
for
me,
the
last
couple
of
weeks,
but
on
the
face
of
it
I
would
say
yeah.
Let's
do
it,
bearing
in
mind
everything
that
we've
been
talking
about
just
recently
about
the
perfect
being
the
enemy
of
the
good
and
wanting
to
kind
of
nail
something
down
that
we
can
all
play
with
and
really
see.
Okay,
how
does
it?
How
does
it
help
us
or
how
does
it
hinder
us.
B
E
G
I
think
I'm
next,
so
I
just
wanted
to
understand.
I
I
I
should
back
up
a
second
and
say
I
am
excited
to
see
progress
here
and
I
I
agree
with
everyone
can't
let
the
perfect
be
that
enemy
of
good.
Here
we
just
should
move
forward
with
something
with
that
said,
I
am
curious.
You
know
right
now,
I
think
you're
describing
a
parent
ref
of
a
service,
and
you
know,
theoretically,
a
parent
ref
could
be
some
other
thing.
G
G
Like,
let's,
let's
just
go,
you
know
years
down
the
road
and
imagine
that
we
have
a
Gateway
class
cluster
IP,
yeah
Let's,
and
if
we
do
that,
you
know
any
number
of
reasons
that
you
may
want
to
have
a
different
kind
of
parent
ref.
Another
idea
service
import,
other
things
like
that.
How
do
you
know
that
the
parent
ref
is
like
this
route
is
for
mesh.
F
So
yeah
like
one
of
the
things
that
we're
not
proposing
to
implement
yet
but
could
be
a
way
to
help
disambiguate
that
in
the
future,
if
needed
is
adding
a
second
paragraph,
So
Right
Now
paragraph.
It
accepts
multiple
references
to
or
multiple
object
references
you
can
define
a
refer
to
a
surface
and
a
ref
to
a
mesh
representation
object.
If
we
find
that
to
be
necessary.
F
That
also
like
I
think
it
would
be
helpful
to
like,
in
the
context
of
thinking
about
mesh,
Gateway,
implementations
or
service
or
import
like
what
are
the
specific
use
cases
that
they
are
intended
to
model
and
how
like,
what's
the
role
that
HTTP
replaced
in
that
so
yeah?
It
is
like
yeah,
obviously
like
there's.
Definitely.
F
H
H
We
could
certainly
go
with
this
and
then
do
that
afterwards,
though
you
know
you
could
lay
all
the
concerns
like
like
Rob
said
of
you
know
what,
if
what,
if
the
line
becomes
more
blurred
between
match
and
Gateway,
what
gateways
represent?
You
know,
services
that
type
of
thing
there's
also
kind
of
future.
Looking
things
like
okay,
we
need
to
represent
a
hostname
like
how
do
we
do
that
now
right?
H
E
D
Here
is
that
parent
ref
will
be
what
we're
attaching
to,
and
service
is
probably
the
most
common
and
the
most
important
to
move
forward
with
and
later
on.
You
know,
vendor
specific
or-
or
you
know
we
can
attach
to
other
things
like
Gateway
class
like
like
I
was
mentioning
we
can
attach
to
you
know.
Whatever
else
we
we
finances
in
a
stateful
set
is
one
important
case
that
we
need
to
address
at
some
point,
but
just
like
we
did
with
HTTP
route
versus
TCP
route
and
other
things
I
mean
it's.
D
One
is
kind
of
moving
forward
because
it's
very
common
and
very
useful
and
the
others
can
you
know,
kind
of
lag
a
bit
behind
and
wait
for
vendors
to
to
think
more
about
what
other
pattern
reps
Maybe,
but
the
important
thing
is
parent
Drive
is
objects
that
that
the
route
is
attaching
to
and
is
no
longer
the
mesh.
So
we
we
will.
If
we,
if
we
ever
need
to
support
multiple
meshes,
we
may
need
an
alternative
way
to
indicate
that
a
particular
route
belongs
to
a
particular
mesh
I
think.
H
F
H
H
So
certain
data
playing
clients
will
do
sort
of
wild
card
queries
and
they'll
get
all
listeners
corresponding
to
a
particular
scope.
I,
don't
see
any
mechanism
within
this
proposal
for
sort
of
sensing
things
off
into
one
domain,
whether
it's
prod
staging
Dev
is
there
any
way
that
you
would
recommend
doing
that,
because
the
issue
that
I
could
see
is
now.
You
have
sort
of
a
blast
radius
of
an
entire
kubernetes
cluster
rather
than
a
particular
configuration
scope.
D
Yeah
and
and
I
think
we
discussed
it
in
the
past,
and
we
agree
to
postpone
this
discussion
about
how
we
fragment
or
have
multiple
measures
until
later
point
and
it's
articular
to
this
I
mean
there
will
be
a
mechanism
issue
as
a
sidecar
import
I
mean
there
are
mechanisms
to
do
it
without
being
tied
to
Route.
It
doesn't
have
to
be
in
HTTP
route
itself.
B
H
A
I
think
I
do
have
a
slight
concern
on
that
front
as
far
as
a
custom
trust
domain
custom.
Trust
me
not
the
right
word,
but
like
a
custom
suffix
because
there
are
I
know
of
you
know,
run
into
it
several
times
of
customers
who
have
like
a
accordion
s,
rule
to
to
redirect
cluster.local
to
something
else.
F
Yeah
yeah
I
got
what
you're
saying
and
costumes
comment
in
chat.
Yeah,
I
I
think
that
would
just
be
easily
to
be
explicit
or
like
don't
hard
code,
cluster.local
like
it.
If
it's
reconfigured
to
something
support
that
reconfiguration.
Basically,
the
intent
is
that
it
will
work
with
transparent
proxy
for
existing
kubernetes
DNS
references
in
the
vanilla
cluster.
However,
that
may
be
configured
and.
C
One
of
the
one
of
one
of
the
you
know:
I,
don't
want
to
be
the
objection
you
got
but
like
one
of
the
things
that
I
think
is
really
important
here.
Is
that
the
is
to
remember
is
that
having
anything
keyed
off
an
unstructured
string
inside
a
field
inside
a
resource
inside
kubernetes
is
a
it's
a
really
bad
API
spell
right,
and
our
hostname
is
an
unstructured
string
right
like
having
to
impute
structure
on
like
onto
a
string
to
make
it
stretch
it
like
effectively.
C
Structured
is
a
really
bad
idea
right
like
and
that's
that's
why
I
have
been
always
been
like
no
don't
use
hostname.
Is
that
that's
the
sort
of
the
rule
that
I'm
taking
that
from?
Is
you
need
to
pull
that
data
apart
and
structure
it
somehow
and
then
use
the
structured
data
as
the
thing
that
you're
taking
off
not
the
unstructured
button,
yeah
so
and.
F
A
A
F
I
will
say
that
it
is
explicitly
included
as
an
or
case
as
like
War
handling
so
like
it
should
not
extend
the
scope
of
what
that
HTTP
route
targets.
I
am
open
to
considering
it
as
an
and
case
to
narrow
that
scope
I'm,
not
as
familiar
with
that.
If
somebody
else
is
interested
in
contributing
that
functionality
to
this
proposal,
but
yeah
I
think
just
I
want
to
avoid
focusing
on
on
the
egress
cases,
kind
of
the
intent
care.
H
F
H
H
H
So
if
we
were
to
say
that
the
paragraph
service
means
that
we're
actually
going
to
match
the
cluster
IP
and
that's
how
we
know
that
it's
actually
going
to
the
service
and
the
hostname
is
still
completely
valid
right.
A
typical
use
case
you're
not
going
to
match
on
it
becomes
just
a
header
match,
essentially
typically
you're
not
going
to
do
a
header
match
on
top
of
that
for
the
host
header.
H
The
matching
logic
in
the
actual
proxy
is
fairly
straightforward
and
I
believe
some
implementation
is
already
doing
exactly
this
today,
but
I
think
that's
what
makes
sense
to
me,
but
at
the
very
least,
we
need
to
be
very,
very
explicit
on
you
know
what
this
actually
means
like
at
one
time.
Eventually
that'll
be
a
conformance
test,
but
in
the
short
term,
as
part
of
the
gap.
E
Yeah
so
I
have
comments.
I
know,
you
know
at
least
what
I
hear
about
my
customers
like
multi-class,
is
here
everyone
multi-class
on
multicaster
right.
You
know
when
people
recommend
you
know
you
want
to
serialized
architecture,
you
want
to.
You,
don't
want
the
one
class
to
go
in
infinitely
right.
So
how
do
we
deal
with
this?
I
mean?
Is
our
API?
This
is
going
to
be
for
looking
at.
Is
it
works
in
the
multitask?
Okay.
H
Yeah
my
opinion-
and
maybe
this
hasn't
been
about
clearly
but
when
at
any
point
where
we
say
service,
we're
not
talking
just
capital
S
service,
but
we're
talking
about
general
service
representations
of
which
their
service
and
service
import
as
part
of
kubernetes.
Already-
and
you
know,
vendors
may
have
custom
ones,
but
the
service
in
part
service,
import,
part
already
kind
of
takes
care
of
the
multi-cluster
right.
That
would
allow
matching
on
you
know:
multi-cluster
services.
E
F
Think
I
think
that's
a
really
good
question
and
by
like
initial
I
think
it
would
be
good
to
explicitly
add
that
as
part
of
the
step
too,
just
like
how
that
could
be
implemented.
So
I
think,
like
my
initial
consideration,
is
service.
Import
is
a
perfectly
valid
back-end
ref
to
be
able
to
redirect
traffic
following
the
service
import
rules
which
I
I
believe
oh
God
I
forgot
the
exact
implementation,
but
like
targeting
service
rep
should
be
able
to
forward
traffic
to
either
to
that
reposition
representation.
Yeah
implemented
yeah
instance.
F
Sorry,
oh
God,
to
the
instance
of
that
service
within
the
cluster
or
if
it
does
not
exist
within
the
cluster
to
a
different
cluster
in
the
cluster
set
based
on
how
that
service,
import,
DNS
results,
I
think
is
what
it
should
do,
I'm
a
little
fuzzier
on.
If
service
import
should
be
allowed
as
a
parent
ref,
because
I
think,
like
the
typical
case,
is
the
service
owner
who
is
like
producing
that
service
should
be
configuring
to
be
configuring.
E
B
B
It
definitely
feels
to
me
reasonable
to
be
able
to
support
having
one
back-end
graph
of
a
service
and
one
being
a
service
import
to
split
traffic
across
clusters.
If
you
want
to
do
that,
it
also
feels
completely
reasonable
to
me
that
the
host
name
should
end
up
being
a
header
match
for
the
authority
of
an
HTTP
request.
B
E
C
All
of
the
other
discussion
aside,
it
really
does
feel
like
the
thing
that
I
have
got
the
most
out
of
all
of
this
discussion
to
be
like
is
the
really
the
importance
of
the
distinction
between
the
front
end
and
the
back
end
of
the
service
resource,
the
kubernetes
service
resource
capital,
S,
and
the
other
thing
is
about
the
distinction
between
the
producer
and
the
consumer
of
any
particular
service.
Lowercase
s,
meaning
an
application
right
like
those
are
the
two
like.
C
B
I
was
also
going
to
say
that
kind
of
along
that
line,
the
the
discussion
about
hostname
in
the
other
sense,
where
you're
trying
to
figure
out
how
to
deal
with
egress
I
think
is
going
to
be
really
interesting
in
the
near
future.
Yeah
so
I
feel,
like
the
egress
case,
is
yeah
there's.
There
are
too
many
cases
that
I've
run
across
of
people
who
want
to
use
either
the
Ingress
or
the
mesh
to
talk
to
things
that
are
outside
of
the
cluster
and
so
I
think
we
should
tackle
that
at
some
point
soon.
F
C
C
So
I
think
those
those
are
just
like
I,
don't
really
mind
like
again
I'm
not
going
to
object
to
any
of
this,
because
I've
done
enough
objecting,
but
but,
like
I,
think
it's
really
important
to
call
out
like
to
make
something
implementable.
That
is
really
important
to
call
out
which
things
should
be
con,
like
which
things
are
valid
parent
Rifts
and
which
ones
we're
going
to
be
like.
C
That
will
never
be
a
thing
that
one
might
be
a
thing,
but
it's
too
hard
and
we're
going
to
do
it
later,
but,
like
I,
think
cluster
IP
is
the
obvious
one.
Where
yeah.
We
all
understand
that
that's
probably
the
one
we're
mostly
talking
about,
but
the
other
ones
are
ones
where
you
just
need
to
make
a
call
now,
definitely
out
of
scope
or
in
scope
or
deferred.
G
Cool
I
just
wanted
to
understand
just
I
think
we've
had
this
conversation
in
the
past
and
I've
lost
track
of
what
the
conclusion
was.
But
is
there
ever
a
goal
for
the
same
route
to
apply
to
a
gate
like?
Would
you
ever
have
a
Gateway
and
a
service,
and
the
same
set
of
parent
rests
for
the
same
route
with
the
intention
of
the
same
routing,
configuration
is
used
for
both.
B
F
So
that
case,
I
would
hope
could
eventually
be
implemented
through
basically
some
form
of
Route
delegation
of
interoperability
between
the
north-south
Gateway,
API
and
Gamma.
So
if
a
service
that
is
defined
as
a
back
end
ref
on
a
HTTP
route
that
is
bound
to
a
Gateway,
if
that
service
also
has
an
HTTP
root,
referencing
it
as
a
parent
ref
to
configure
a
mesh
split,
then
yeah.
G
A
So
I
raised
my
hand
before
Rob's
question
and
now
I
can't
stop
thinking
about
Rob's
question
so
I've
effectively
forgotten
what
I
was
gonna.
Ask.
Oh,
oh
I,
remember
I
put
this
in
the
chat.
Do?
Is
there
a
a
list
of
acceptable,
backend,
ref
kinds
and
Upstream
Gateway
API,
and
if
so,
can
we
lean
on
that
for
Gamma,
or
can
we
or
maybe
for
parent,
wrap
or
background
for
some
sort?
A
A
So
that's
probably
worth
a
chart
somewhere
fully
like
a
matrix
fully
showing
when
each
type
of
service
kind
or
service
type,
two
distinct
things
showing
when
those
are
appropriate
for
which
field
do
we
have
to
let
that
Upstream
that
we
can.
We
can
kind
of
add,
and
if
not,
is
it
worth
creating
something
like
that
in
the
for
the
Ingress
case.
C
C
So
you
know
that
that's
the
sort
of
the
rules
we
have
right
and
so
yeah.
That's
that's
why
I
called
the
made
the
call
out
about
types
you
I
know
for
you
when
I
was
maintaining
Contour
like
we
specifically
ruled
out
having
external
name
types
of
services,
backend
refs,
because
it's
concerning
for
that
use
case,
but
like
there's
nothing
that
stops
you
doing
that
right,
like
there's.
No,
we
haven't
written
any
rules
like
that
into
the
spec.
D
D
Do
we
want
to
restrict
that
backend
refs
are
subsets
of
that
particular
service,
which
would
mean
that
it's
a
strict,
you
know
traffic
split
for
that
particular
service.
Or
do
we
want
to
allow
the
backend
reps
to
be
completely
arbitrary
destinations
and
only
allow
you
know
arbitrary
restriction,
arbitrary
destinations
if
there
is
no
selector?
So
do
you
want
to
add
another
additional
field
or
some
way
to
indicate
that
the
semantics
of
traffic
split
versus
arbitrary?
D
But
do
we
want
to
explicitly
select
it
to
to
be
explicit
in
the
API
either
by
you
know,
putting
a
condition
if
it
has
selector
or
not
or
some
explicit
field?
Or
do
you
want
by
default
to
be
always
arbitrary,
because
in
as
an
implementation,
it's
sometimes
it's
good.
If
we
have
the
user
intent
to
be,
you
know
a
traffic
split,
because
it
has
impact
on
how
we
we,
we
we,
you
know
kind
of
implement
it
and
how
we
I.
B
Don't
know
yeah
I
think
I'd
personally
lean
towards
not
dictating
policy
at
that
level
and
if
the
user
wants
to
use
it
as
an
A
B
split,
as
opposed
to
it
like
like
a
B
in
the
sense
of
oh,
do
the
users
like
this
implementation
better
than
this
implementation
versus
load,
balancing
traffic,
split
versus
canaries,
I?
Think
all
that
stuff
is
fair
game
and
we
should
allow
it.
G
Yeah
I
I
think
just
kind
of
piling
on
to
to
that
I
think
I
agree
with
that
approach
that
you
never
know
what
kind
of
service
might
exist.
You
know
one
of
the
examples
I've
heard
of
is
a
selected
a
service.
You
know
in
in
front
of
two
actual
services
with
selectors
for
the
version
that
seems
valid
to
me,
taking
a
step
back.
G
What
I
originally
raised
a
hand
for
was
the
idea
of
what
services
are
supported
in
which
cases
and
it
feels
like
what
we
really
are
looking
for-
is
a
set
of
characteristics
right,
so
a
service
that
has
a
front
end
going
back
to
nixcom
everyone's
comment
about.
You
know
a
service
that
has
a
front-end
a
cluster
IP
assigned
to.
It
is
really
all
that
we
could
have
as
a
parent
ref
and
then
as
a
back-end
ref.
E
F
Cool
so
I
I've
dropped
a
handful
of
to
do
notes
into
the
middle
of
the
service
resource
parent
Rush
approach.
I
will
follow
up
on
those
after
the
speaking
and
there's
a
few.
That
I
would
definitely
appreciate
some
help
with
such
as
the
specific
types
of
service.
If
somebody
feels
to
add
in
a
paragraph
or
bullet
points
on
those.
B
C
I
would
guess
the
last.
The
last
thing
that
I
wanted
to
call
out
as
just
being
a
thing
to
keep
in
mind,
is
to
be
really
is
to
make
sure
that
we're
I
think
it's
better
to
be
extremely
arbitrary
about
like
who
owns
what
you
know
like
making
it
so
that
you
can
only
attach
the
services
HTTP,
router
and
service
that
are
attached
have
to
be
in
the
same
namespace.
Don't
try
and
be
clever
with
cross
state
and
I
suppose
references
yet
just
be
really
like
this.
C
All
this
whole
system
has
to
be
all
in
the
same
namespace
and
a
story
no
cross
thanks
to
no
support
to
start
with,
because
doing
class
things
is
very
difficult,
really
tricky
and
nasty,
and
so
just
make
it
be.
All
of
these
things
have
to
be
in
the
same
namespace
specifying
a
namespace
other
than
the
namespace.
That
one
of
them
is
in
is
is
an
error.
B
C
I
I
think
in
terms
of
like
admin
stuff,
it
feels
fine
to
me
to
get
the
get
to
an
implementable
State,
not
an
accepted
state,
so
that
then,
like
people
can
Implement
things.
Okay
be
like
hey.
This
is
experiment,
it's
implementable
and
experimental,
and
that
way
people
can
like
try
it
out
and
see
how
it
goes,
because
this
doesn't
need
a
lot
of
changes
to
http
route.
C
Biggest
advantage
of
the
the
pro
ship
that
we're
proposing
here
is
that
we
don't
need
to
do
like
field
level
or
resource
level
changes
to
to
or
already
existing
go
API
resources
right,
like,
let's
put
it,
make
the
putting
this
to
implementable
and
then
having
it
be
like
okay.
Now,
everyone
have
a
crack
at
this
and
see
how
you
go
is
a
like
feels
to
be
to
be
like
effective.
It
lets
us
do
like
a
podcast
of
how
this
will
work,
but
Community
block
right
like
and.
C
A
big
win
personally
for
me,
like
I,
didn't
I,
don't
want
to
go
too
far
down
this
road,
but
one
of
the
things
we
need
to
discuss
at
some
point
is
when
we
actually
do
end
up
releasing
things
for
this.
We
need
to
discuss.
Do
these
things
live
in
the
same
API
Group
as
the
Gateway
API
thinks,
because
maybe
they
shouldn't
right,
like
they're,
going
to
be
different
things
so.
E
C
I,
don't
that
decision
that
question
should
not
be
answered,
discussed
or
answered
right
now.
I
just
wanted
to
put
that
in
your
head
for
something
that
you
need
to
think
about,
so
that
we
can
talk
about
it
later,
but
making
this
marking
this
is
implementable,
not
you
know
accepted
or
whatever
the
state.
The
exact
state
of
the
Gap
is
means
that
you
know
people
can
iterate
quickly.
It's
accepted
that
this
is
like
a
way
experimental.
Even
this
is
a
more
experimental
than
experimental.
F
Cool
yeah
that
sounds
really
good
to
me
and
yeah,
just
like
for
concrete
things
like
the
questions
that
were
raised
in
this
meeting.
To
kind
of
like
give
clarification
on.
Are
we
thinking
about
this?
Are
we
not
Are
there
specific
constraints
that
we
should
add?
That
kind
of
stuff
is
really
helpful
and
I
definitely
do
want
to
include
that
in
kind
of
like
the
get
PR,
the
things
I
don't
want
to
do
is
like
reopen
bike.
Shutting
on.
Is
this
the
right
approach
at
all.
A
A
It
sounds
like
with
the
match
representation
with
sorry,
with
the
service
bonding
approach
that
we've
taken,
there's
not
yet
a
need
for
a
mass
representation
resource
which
might
even
be
counted
as
a
win.
Less
less
competition
to
have,
but
I
want
folks
to
start
thinking
about.
What
do
you
want
to
tackle?
Next
I
can.
Speaking
from
my
use
case,
we
have
a
pretty
big
need
around
policy,
specific
authorization
policy,
we're
migrating
from
SMI,
and
so
there
is
currently
a
gap
around
that
in
the
state
of
the
specs.
A
So
that's
I
like
to
spend
some
time
doing.
That.
I
also
believe
that
we
might
maybe,
at
the
point
once
this
Gap
gets
accepted,
that
we
can
start
doing
parallel
streams
of
work
which
is
very
exciting
so
start
thinking
about.
You
know
what
sorts
of
things
you
need
to
see
from
gamma
slash
Gateway
API,
to
really
implement
this
for
your
implementation
and
bring
those
to
the
next
meeting
or
actually
I'll
scratch
that
put
them
in
slack,
and
we
can
start
you
know
seeing
where
folks
have
have
investment
from
there.
G
Hey
yeah,
mine
is
really
short.
I
mentioned
this
in
the
meeting
yesterday,
but
there's
a
contribute
Summit
at
kubecon
we're
hoping
to
get
a
chance
to
meet
with
everyone
in
person.
Talk
through
some
of
these
things
do
some
brainstorming
whatever.
So,
if
you
can
make
it
we'd
love
to
see
you
if
you're,
not
an
org
member
yet,
but
you
want
to
make
it
reach
out
to
one
of
us
maintainers
and
we
can
help
get
you
there.
G
C
Probably
yeah,
so
there
are
two
days
pre-events
I
know:
lots
of
people
have
other
events
on
those
those
days.
My
experience
with
the
contributor
Summit
has
been.
It
is
by
far
the
most
useful
thing
that
I
do
at
coupon
by
far
and
in
terms
of
like
actually
getting
work
done
and
learning
about
like
what's
actually
happening
in
Upstream
Cube.
So
you
know,
if
you
are
in
this
call,
I
would
strongly
encourage
you
to
do
your
best
to
try
and
come
to
the
computer
Summit.
A
G
C
A
All
right
thanks,
strange
I,
think
I
started
moderating
this
and
then,
and
then
Mike
did
a
really
smooth
job
of
trying
to
stepping
in
there
and
managing
everything
so
appreciate
it,
and
thank
you,
Flynn
for
working
on
notes
and
keeping
our
our
minutes
up
to
date
really
appreciate
the
effort
and
all
the
discussion
as
well
love
working
with
you
all.
We
will
be
meeting
again
on
the
27th
at
8,
A.M
Pacific.
Thank
you
and
you
all
have
a
great
rest
of
your
weeks.