►
From YouTube: Gateway API GAMMA Meeting for 20230530
Description
Gateway API GAMMA Meeting for 20230530
A
It's
hello:
everybody
Welcome
to
the
May
30th
instance
instance
occurrence
of
the
kubernetes
Gateway
API
gamma,
meeting
quick
reminder
that
this
media
is
governed
by
the
kubernetes
code
of
conduct,
so
please
be
kind
respectful
to
everybody,
hopefully
not
just
within
these
meetings,
but
especially
within
these
meetings,
we
have
an
open
Agenda
that
I
will
post
in
the
chat.
A
So
please
on
the
agenda,
feel
free
to
put
your
any
topics
that
you
want
to
discuss
there,
and
we
ask
that
you,
if
you
can
put
your
your
name
and
affiliation
in
the
attendance
section
just
so
we
can
have
have
a
record
I
know
who
is
attending
these
things.
A
Just
to
you
know,
actually
change
the
order
of
the
agenda
just
a
bit
just
because
I
think
this
I've
got
a
quick,
PSA
and
I'll
also
share
my
experience
that
people
can
see
the
agenda.
That'd
be
nice
and
I'll
zoom
in
the
agenda,
a
good
bit
that
decent
size
for
everybody.
B
A
There
we
go
cool,
better
cool,
all
right
Okay,
so
let's
go
ahead
and
get
started
on
our
topics:
quick
PSA
from
the
regular
Gateway
API
meeting,
which
is
this
morning
still
wrapping
my
head
around
that
it's
great
to
say,
but
we
are
there's
a
change
coming
to
the
storage
and
surf
API
versions.
A
C
Yeah
sure
this
is
something
that
I
think
is
should
be
unexpected
should
be
expected.
I
should
say:
we've
been
working
towards
this
for
a
minute.
What
this
means
is,
if
you're
using
gateway,
gateway,
class
or
HP
route-
and
you
happen
to
be
interacting
with
that
with
B1
Alpha
two,
you
used
to
get
just
a
deprecation
warning
that
said,
hey
this
API
version
is
deprecated
upgrade
to
V1
beta1,
and
now
you
just
will
get
an
error.
C
It
means
that,
although
we
will
continue
to
have
the
API
version
present
in
the
crd,
it's
not
going
to
be
served,
which
means
it's
not
going
to
be
accessible
based
on
the
pr
it
seems
like
most
implementations
out,
there
have
already
upgraded
to
use
V1
beta1,
but
if
you
haven't
make
sure
you
do
before
080,
because
this
is
on
Pace
to
get
in
in
080.,
so
yeah
just
take
a
look,
there's
some
guidance
as
far
as
what
changes
you
should
be
looking
to
make.
C
If
you
haven't
already
yeah,
that's
coming,
I
haven't
seen
anyone
who
is
affected
by
this
yet
or
at
least
has
commented
on
here.
But
please
let
us
know
if
you,
you
will
be.
A
All
right
then
Flynn.
The
floor
is
yours.
B
So
as
of
last
week,
I
feel
like
the
last
time
we
were
talking
about
the
interaction
of
gateways
and
service
meshes
when
they
are
both
trying
to
do
gamma
things.
The
short
version
was
The
Proposal
that
I've
just
listed
in
the
tldr
there.
B
That
gateways
must
default
to
routing
directly
to
workload
endpoints,
but
may
offer
the
ability
to
route
to
service
cluster
IPS
if
they
want
the
last
time
we
talked
about
this
one
Mike
and
I
said
that
we
wanted
to
pull
that
out
of
the
requirements
for
the
next
gamma
Milestone,
which
was
done,
and
we
also
said
we'd
pretty
much
come
to
a
consensus,
but
there
was
a
lot
of
wordsmithing
still
to
be
done.
B
A
fair
amount
of
that
word
smithing
is
now
in
suggestions
in
the
document
and
hopefully
we'll
be,
you
know
actually
properly
in
the
document
at
which
point
I
expect.
We
will
turn
it
into
an
actual
Gap
document
fairly
shortly
after
that
and
yeah
that's
about
that's
about
it.
C
Okay,
that
I
that's
great
to
hear
the
the
one
thing
like
I'm,
just
just
glancing
at
this.
One
of
the
things
that
stated
is
the
Gateway
and
mesh
must
work
together,
I
D-
and
you
probably
do
go
into
that
in
more
detail
in
Doc
itself.
But
can
you
give
like
a
30
second
high
level?
The.
B
Main
impact
of
saying
that
the
Gateway
must
do
endpoint
routing
is
that
the
service
mesh
is
largely
cut
out
of
that
first
hop
between
the
Gateway
and
the
first
meshed
workload,
and
so
that
is
mostly
just
a
description
of
the
fact
that,
from
the
perspective
of
the
users
of
these
things,
rather
than
just
going,
oh
I
want
to
do
all
of
this
in
the
mesh.
Then
they
will
end
up
needing
to
rely
on
the
Gateway
for
part
of
it
and
the
mesh
for
a
different
part
of
it,
and
we
should
recognize
that.
B
C
Okay,
yeah
I
got
it
yeah.
So
what
what
this
is
really
describing
is
not
so
much
where
you
were
going
earlier,
which
was
you
know
the
cluster
IP
type
routing.
This
is
more
just
saying:
we
need
to
at
a
high
level,
have
a
plan
and
understanding
for
how
implementations
of
Gateway
can
interact
with
implementations
of
mesh
and
what
we
can
recommend
users
do.
Okay,
all
right
thanks!
C
Does
this
actually
make
recommendations
at
this
point,
or
is
it
primarily
just
kind
of
a
problem
statement
like
that
initial?
There.
B
Are
a
couple
of
recommendations
in
there
that
mostly
boil
down
to
things
should
work
if
you
specify
multiple
parent
refs
on
an
HTTP
route
and
one
of
them
is
a
gateway
and
one
of
them
is
a
mesh
and
things
like
that.
B
Okay,
again,
I,
don't
think
based
on
the
you
know,
the
last
conversations
that
we've
had
I,
don't
think:
there's
anything
that
you're
going
to
find
surprising
I
think
everybody
ought
to
read
it
once.
You
know
we'll
we'll
keep
updating
things,
and
hopefully
it
won't
be
anything
too
terribly
surprising
to
anybody
else
after
last
week,
either.
A
A
I
had
to
found
that
unmute
button,
cool,
I
feel
I'll.
Take
a
look
at
this
skimming
through.
A
Nothing
looks
too
objectionable,
but
I'll
take
a
take
a
second
month,
okay,
so
any
other
questions
or
things
to
discuss
on
this
topic.
It's
the
good
question
John.
It
is
the
actually
the
original
doc
from
October
that
is
being
edited.
I'll
explain
for
it
a
couple
of
times
myself,
oh
okay,
and
as
soon
as
I
say
that
he
found
it
classic
John
all
right,
great
all
right,
my
my
next.
My
topic
was
kind
of
similar
to
that
one,
in
that
our
Milestone
is
clear,
which
is
exciting.
A
That's
shame
to
move
it
so,
at
this
point,
we're
effectively
saying
that-
and
we
already
did
officially
say
it
via
this
implementable
PR.
But
there
are
no
issues
here.
I
wanted
to
start
thinking
about
080
and
I've
got
this
note
here
is
that
we
still
need
to
make
website
changes
for
gamma,
and
this
kind
of
final
call
to
see
if
there's
anything
left
that
we
feel
needs
to
be
in
that
Oedo
release
for
the
camera
go
ahead.
Rob.
C
Yeah
I
was,
this
is
great.
What
I
would
say
is
if
our
Milestone
is
clear.
That
Milestone
was
poor
implementable.
Is
that
correct?
Okay,.
C
So
we
probably
need
a
corresponding
milestone
for
or
something
for,
experimental
080
whatever
we
want
to
call
it
for
gamma
specifically,
and
maybe
we
can
track
some
of
these
things
like
the
documentation
updates,
API
spec
updates.
Just
so
we
make
sure
you
know
we're
what
I
think.
Four
weeks
away
from
when
we
said
we
were
going
to
aim
for
080
like
it's
pretty
soon
so
I
want
to
make
sure
that
we
are
on
track
and
not
you
know
not
missing
things,
and
the
other
thing
is
I.
C
C
Both
just
have
gamma
in
the
title.
I,
don't
know
if
there's
a
but
anyways
I
I'm,
not
sure
if
those
are
meant
to
fit
before
080
I
feel
like
the
first
one
by
John.
Probably
should
I
don't
know
about
the
second
one,
but
if
those
are
also
intended
in
scope
or
this
Milestone,
we
should
make
sure
they
get
added
in
track
somewhere.
D
D
D
C
No,
it
sounds
like
this
is
I
I,
don't
know,
I,
don't
know
what
we
were
aiming
for
here.
I
think
our
interpretation
of
this
was
this
is
implementable,
and
maybe
what
we're
aiming
for
for
v080
is
very
slightly
different
than
that.
It's
the
experimental
level,
which
means
it's
actually
part
of
the
API
release
in
080.
We.
C
Yeah
right
I,
don't
know
if
we
want
that
to
be
the
same
Milestone
like
just
reuse,
that
same
Milestone
or
if
we
want
to
create
a
new
one.
A
A
I'll,
take
a
I'll,
take
a
can
of
sprite.
That's.
A
B
A
That
I,
probably
I'm
right
above
the
stuff,
because,
let's
yeah,
let's
talk
about
where
we
are
in
relation
to
where
we
thought
we
were
going
to
be
so
I
remember
when
we
when
we
started
like
create
this
Milestone,
the
goal
is
just
to
get
something
out
there.
A
People
to
play
with
and
I
think
we
probably
overshot
that
goal
a
bit
a
lot
of
the
last
conversations
that
we
had
when
it
comes
to
gamma
and
getting
implementable
like
we're
kind
of
past
that
trying
phase
and
so
I
think
I
think
we're
probably
there,
but
when
it
comes
to
as
Rob's
mentioning
API
review,
getting
things
on
the
website
that
feels
like
another
bar
and
so
I'm
a
big
fan
of
celebrating
wins,
I'm
thinking
wins
so
personally,
I
think
it
would
feel
good
and
even
send
a
signal
community-wise
to
close
this
Milestone
and
open
up
a
new
one
and
then
use
that
new
one
to
track
progress
towards
Oedo,
not
sure
what
others
proud
to
others
feel
about
that
got
changed.
D
Yeah,
so
it
took
us
a
while
to
get
here
and
we
should
celebrate
like
no
joke,
like
I.
Think
that
closing
this
Milestone
and
saying
hey,
we
reached
a
milestone.
An
important
Milestone
is
good.
D
I.
Take
a
lot
of
pause
with
doing
this
long,
walk
to
implementable
and
then
a
short
walk
to
experimental
part
of
that
is
influenced
by
the
pain
we
are
currently
seeing
with
the
policy
attachment
method,
resources
Gap,
which
has
been
an
experimental
for
two
years,
so
experimental
has
lost
its
meaning.
D
It's
in
production
and
there's
pain
that
we're
going
to
pay
somebody's
going
to
pay
for
that
one
way
or
another,
so
I
would
I
would
be
more
cautious
about
calling
it
experimental
because
experimental
for
us
doesn't
mean
what
I
think
it
should
it's
just
the
nature
of
the
Beast.
This
is
what
it
is.
I
can't
change
that
right
now,
but
but
I
do
want
to
see
us
come
up
with
another
important
Milestone
that
doesn't
make
people
feel
like
there's
a
long
slog
ahead
either.
C
So
I
think
again
my
my
opinions,
biased
here
but
experimental.
B
C
It's
fair
experimental,
as
the
name
suggests,
is
pretty
clear
in
its
meaning.
I
think
the
problem
is
whatever
you
call
something
if
it
is
accessible
to
users
and
widely
implemented
or
some
period
of
time,
it
becomes
really
painful
to
change
that.
It
doesn't
really
matter
what
you
call
it
it's
just
if
it's
implemented
widely.
C
We
already
are
at
that
stage
and
then,
if
it's,
you
know
officially
recognized
by
the
API,
even
as
something
like
experimental,
but
if
it's,
if
there's
docs
there
that
state
that
which
almost
there
already
you
just
be
a
guess,
I,
don't
know,
you
know
I.
Think
in
my
opinion,
I
think
the
lesson
on
one
of
the
lessons
we
learned
with
policy
and
I
agree.
C
It
sad
and
experimental
for
a
very
long
time,
and
just
kind
of
you
know
variety
of
things,
but
what
I
would
say
is
we
should
aim
to
move
more
quickly,
but
not
calling
something
experimental,
even
though
it
meets
all
the
criteria
feels
unfortunate.
It
feels
like
that.
The
thing
we
should
be
trying
to
fix
is
moving
faster
from
experimental
to
standard.
C
B
But
it
really
does
make
me
wonder
what
sorts
of
things
we
could
do
to
try
to
make
it
less
likely
that
things
that
are
experimental,
don't
gain
the
the
excess
pain
of
people
trying
to
actually
use
them
in
production
yeah.
It's
also
tricky,
and
that
we
need
people
to
try
things
to
get
feedback.
But
we.
D
A
D
Don't
call
it
experimental
I'm
pointing
out
some
of
the
pains
that
we've
had
with
such
a
thing
that
we
don't
really
know
the
future
well
enough
to
know
how
far
we're
going
to
get
into
experimental
and
that
there
may
become
a
point
where
we
pick
Hefty
prices
for
implementations
that
are
out
in
the
wild
on
experimental
when
we
decide
that
there
are
some
things
that
we
want
to
do.
For
instance,
sorry,
if
you're
hearing
my
kid
in
the
background
by
the
way
for.
D
Not
liking,
it
he's
like
Dad.
What
no
Cal
and
Tim
have
repeatedly
mentioned:
potential
issues
with
the
hole
attaching
to
a
service
business
right
to
go
experimental
and
then
go
into
production
without
even
having
resolved
that
and
then
potentially
getting
to
a
point
where
it's
like.
Oh,
we
really
really
didn't
want
to
do.
That
could
be
painful,
very
painful
right.
That's
that's
kind
of
more
my
point
than
trying
to
say
do
this,
or
do
that.
It's
more
think
about
these
things.
D
It's
not
a
I,
don't
think
it's
a
cut
and
dry
decision
what
we
do
moving
forward.
C
Yeah
I
agree
that
we,
we
should
be
cautious,
I
I
should
clarify,
at
least
from
my
perspective,
what
the
difference
is
between
implementable
and
experimental.
From
my
perspective,
implementable
has
has
been
used
to
indicate
that
this
is
something
like
implementation
should
go
out
and
build
upon,
but
implementable,
in
my
opinion,
isn't
has
not
been
meant
to
be
a
long-term
state.
C
It
is
a
this
is
a
thing
to
act
upon,
but
then
we're
going
to
release
something
and
when
we
release
something
like
we're
going
to
call
it
experimental
in
the
case
of
gamma,
it's
a
little
funny
because
it's
not
like
we're
releasing
a
new
API
field
resource
anything
like
that.
We're
just
likely
just
updating
our
docs
and
go
changing
the
API
spec
to
say
with
gamma.
This
is
how
you
this
is
what
a
parent
ref
could
look
like.
You
know
it's
pretty
minimal
changes
all
the
way
around.
C
We're
really
just
saying
this
is
formally
Something
That
We're,
releasing
which
that,
if
we
were
not
to
to
graduate
this
to
experimental
I,
think
it
would
be
unfortunate
in
the
sense
that
I
think
implementable
generally
indicates.
This
is
a
thing
we're
intending
to
release:
go
implement
it
if
we
move
to
implementable
without
an
intention
of
getting
too
experimental
with
the
same
thing.
That
would
be
unfortunate
in
my.
D
C
A
C
A
B
D
D
So
don't
take
this
with
a
grain
of
salt
or
whatever,
but
I
kind
of
like
the
idea
that
experimental
comes
with
like
a
a
timing
check-in
where
we
basically
default
to
declining
things
if
they
can't
be
resolved
past
experimental
after
a
certain
time,
I
don't
know
if
that'll
be
a
problem
with
gamma
All
Things
Considered
I
do
Wonder,
though,
if
we
call
it
experimental
in
four
weeks,
if
that
will
be
driving
way
out
ahead
and
kind
of
pulling
everybody
along
and
getting
us
really
far
and
getting
us
into
production,
and
then
we
come
back
and
there's
a
lot
of
questions
still
left
to
answer.
D
I,
don't
know
I
don't
want
to
hold
this
whole
thing
up.
I
mean
I,
know
it's
just
like
seven
officer.
Oh,
it's
nine
of
us
now,
but
I
don't
want
to
hold
this
whole
thing
up
on
my
caution,
but
I
did
want
to
express
that
caution
and
I'm
open
to
what
we
do
about
it.
I
appreciate
that
you're
listening
to
it.
C
My
my
own
take
here
is
that
the
well
okay,
I'll
I'll,
agree
with
you
I
think
we
should
have
similar
guardrails
to
what
exist
in
Upstream
kubernetes,
which
is
that
when
something
like
is
experimental
or
in
kubernetes
in
a
non-ga
state,
there
are
guard
rails
where
within
and
releases,
this
needs
to
graduate
to
the
next
level
or
we're
just
gonna
drop
it
roughly
and-
and
that
seems
like
a
a
reasonable
idea
to
force
things
along
or
just
not
have
a
in
kubernetes.
It
was
avoid
Perma
beta
I.
C
You
know
I
guess
for
us
Perma
experimental
whatever.
That
is,
we
need
to
have
some
mechanism
there.
The
other
thing
I
wanted
to
say
just
briefly
is
that
implementable
is
something
that
happened,
maybe
a
little
a
little
later
than
it
should
have
like
people.
By
the
time
we
mark
this
as
implementable
on
gamma.
It
had
already
been
implemented.
It
was.
It
was
more
of
a
formality.
It's
not
like
you
know.
People
have
been
working
on
gamma
for
nearly
a
year.
Now,
maybe
long
I
don't
know
I,
others.
C
To
me,
I
feel
like
I
feel
like
it's
not
we're,
not
rushing
something
like
if
it's
been
kind
of
soaking
for
a
year,
and
that
was
implemented,
and
you
know
I
I
feel
like
it's
anything
less
than
pushing
this
through
to
experimental
is
just
kind
of
again
artificially
underselling
the
state
of
this
API
yeah.
Maybe.
B
There
isn't
there
is
an
interesting,
a
question
that
comes
up
there,
which
was
something
that
Shane
alluded
to.
So
we
go
ahead,
we
mark
it
as
experimental
people
start
building
on
it
I
six
months
from
now,
everybody
and
their
brother
is
going
through
and
binding
HTTP
routes
to
services
and
right
about
this
time
is
when
the
Upstream
folks,
with
kubernetes
itself,
come
back
and
go.
You
know
what
we
figured
out
all
the
reasons
why
this
truly
is
a
terrible,
terrible
thing,
and
we
need
to
cut
this
out
so.
B
Is
it
worth
considering
that
kind
of
a
future
and
figuring
out?
How
do
we?
You
know
how
we
would
get
out
of
that
particular
corner
and
yeah
I
am
kind
of
thinking
about
the
policy
attachment
scenario
here
too
right
where
we
have
people
at
this
point.
Obviously
I'm
biased
coming
in
to
say
you
know,
hey,
there
are
problems
here
and
one
of
the
bits
of
pushback
we
get
is
along
the
lines
of
well,
people
are
already
using
it.
B
You
know
so
that
question
about
is
this
something
we
pay
for
now
or
is
it
something
we
pay
for
later
is
an
interesting
question
to
me,
and
I
am
also
not
particularly
trying
to
argue
that
we
shouldn't
say
experimental
right
now.
I
am
saying
this
seems
like
something
we
might
want
to
think
about
a
bit.
Sorry
go
ahead,
Rob.
C
I
have
probably
been
monopolizing
conversation
here,
but
just
one
thing
I'd
say:
is
we
Upstream
kubernetes
moves
pretty
slowly
so
saying
anything
significant
is
going
to
change
in
six
months.
Is
hopeful,
but.
C
But,
but
what
I'll
also
say
is
we've
tried
to
be
as
inclusive
as
possible
in
Cygnet
leadership
in
getting
making
sure
that
upstring
Sig
Network
leaders
are
reviewing
every
release
and
what
it
means
to
graduate
to
experimental
is
that
gamma
would
be
in
scope
and
would
need
to
be
approved
by
so
far
it's
been
mostly
Tim
and
Cal,
but
anyone
at
Sig,
Network
leadership
level
is
welcome
in
in
part
of
that
review
process,
but
generally
I,
I
trust
them
to
not
say
oh
yeah.
This
is
fine
and
then
turn
around
and
completely.
C
You
know
turn
break
things
on
us.
They.
They
are
pretty
good
at
having
a
good,
long-term
picture
and
vision
in
mind
when
they're
reviewing
things
so
I
I
get
the
concern,
but
I.
Think
at
some
point
you
know
just
have
to
admit
that
we've
made
it
to
a
point
that,
even
if
it
yeah
I.
C
B
B
But
I
do
think
that
you
know
Rob
your
point
about
the
the
idea
that
Sig
Network
would
be
looking
at
that
and
trying
to
think
ahead
actually
really
does
do
you
know
that
that
goes
a
long
way
towards
addressing
that
particular
concern.
So
that's
a
good
thing
to
hear
that
feedback
on
sorry
Louis,
you
were
gonna,
say.
E
Yeah
I
mean
I,
guess,
there's
a
set
of
these
kind
of
long-term
alignment
issues
right
that
there
are
hand
wavy
concerns
about
right,
like
the
the
policy
attachment
to
service
stuff
and
Rob.
Correct
me
if
I'm
wrong,
but
Tim's
opinion
is.
This
is
bad,
but
there's
nothing
better.
Yeah.
E
Yeah,
the
nothing
better
part
to
fix
that
part
requires
changes
to
Services
itself
right
right.
The
the
disaggregation
of
the
concepts
of
service
into
different
API
resources
and
18
months
would
be
an
optimistic
timeline
projection
for
that
getting
into
kubernetes
at
best,
because
it's
so
freaking
fundamental
right,
like
maybe
right,
if
Sig
Network
put
60
of
its
meeting
effort
into
that
for
the
next
six
months.
D
To
come
up
so
I'm
kind
of
excluded
from
the
group,
because
I
have
a
bias,
but
I
know
that
Tim
and
Cal
basically
aren't
this
isn't
on
their
regular
agenda.
D
D
Agenda
when
we
push
it
on
their
agenda
kind
of
situation,
so
six
months
isn't
a
matter
of
when
they're
gonna
come
to
us
six
months
is
a
matter
of.
Will
we
go
to
them?
How
soon
will
we
go
to
them?
Next,
so
I
don't
know
I.
B
D
What
can
we
do
in
that
situation
in
a
non-prescriptive
feedback
situation,
we
can
try
to
find
an
alternative
or
continue
with
what
we
got.
I
think
my
pause
comes
mainly
from
the
fact
that
I'm
pretty
sure
we're
going
to
continue
with
what
we've
got
and
I'm
worried
about
the
knife's
edge
of
that
experiment
ending
up
in
production
where
we
we
get
to
the
point
where
we
make.
We
finally
realize.
Oh,
this
has
some
significant
drawbacks
in
production.
E
D
E
Yeah
so
right,
which
of
these
types
of
events
or
or
you
know,
Edge
triggers?
Are
we
going
to
consider
reasonable
to
attach
experimental
too
right
because
those
the
compositional
parts
of
the
API
right?
We
have
rough
timelines
in
our
heads
for
when
we
think
any
of
those
things
can
happen
now
a
different
choice
that
we
make
in
this
group
when
service
is
refactored
and
when
the
refactoring
of
service
goes
live
in
the
API,
the
last
two
being
very
far
out.
B
B
A
D
E
B
I
should
probably
point
out
that,
just
to
be
100
certain
that
we're
talking
about
the
same
thing
when
I
brought
up
attaching
stuff
to
Services
I
was
specifically
thinking
of
binding
an
HTTP
route
via
its
parent
draft
to
a
service
as
opposed
to
policy
attachment,
being
you
know,
attaching
a
policy
using
the
policy
attachment
mechanism
from
depth
713
to
a
service
I'm,
quite
certain
that
associating
an
HTTP
route
to
a
service
is
a
thing
that
needs
to
be
supported
right
now
and
I'm,
also
quite
certain
that
it
will
be
insufficient
in
the
future.
B
But
that
particular
comment
about.
Oh
you
know
if,
if
Tim
or
somebody
comes
up
and
hates
the
idea
of
you
know
of
services,
was
referencing
Shane's
comment
of
yeah.
We
know
that
some
of
the
Sig
Network
people
are
not
Terribly
Happy
with
bounding,
binding
routes
to
services.
I,
don't
think,
there's
any
great
new
alternatives
to
that.
Right
now
for
the
mesh
case,.
C
Yeah
yeah,
I,
I,
agree,
I
I
feel
like
the
direction
we're
heading
on
at
least
for
the
scope
of
gamma
as
it
exists
today
is
both
not
ideal,
but
also
there
is
no
better
alternative
that
will
exist
in
the
next
two
years.
Probably
that
you
know,
and
so
we
should
do
something
with
within
the
limitations
we
have.
That
does
not
mean
that
we
can't
improve
upon
that.
C
Yeah
there
you
know,
if
you
think
that
Gateway
API
is,
is
understaffed,
which
I
will
always
say
it
is
we
usually
get
more
attendees
and
interest
and
motivation
at
Gateway
API
meetings
than
we
do
at
Sig,
Network
meetings
and
Sig
network
is
much
broader
in
scope
than
Gateway.
So
it's
just
there's.
C
C
So
it's
going
to
take
some
time
yeah,
that's
that's
what
I
think
is
our
next
steps
and
I
just
want
to
make
sure
that
we're
on
track
for
that,
and
we
can
continue
all
these
discussions
kind
of
in
parallel
and,
like
I,
think
Shane
and
flynna
both
said.
We
probably
need
some
refinement
at
minimum
on
what
we
consider
experimental
versus
implementable.
D
C
C
I've
had
a
a
while,
where
I
keep
on
thinking.
Oh
man
I
want
to
improve.
You
know
this
this
you
know
process
or
policy
or
whatever,
but
I
don't
want
it
to
Target.
You
know
these
existing
gaps
and
so
I
I.
Don't
really
know
how
to
do
that,
because
there's
never
a
right
moment
because
there's
always
some
Gap
or
some
gaps
that
are
in
flight.
But
at
some
point
we
do
need
to
make
some
improvements.
There.
B
We
could
probably
start
talking
about
it
and
explicitly
grandfather
in
gaps
that
were
already
open
at
the
beginning
of
the
discussion.
Yeah
I
think
that
makes
sense
as
a
potential
mechanism.
Rob.
Do
you
wanna?
That
is
your
screen
right.
You
want
to
scroll
up
a
little
bit
so
that
people
can
sorry
other
direction
there
we
go.
Do
people
agree
with
that
summary
of
everything
that
we
just
said
or
shall
I
go
ahead
and
edit
that
further.