►
From YouTube: SIG Network Gateway API meeting for 20230711
Description
SIG Network Gateway API meeting for 20230711
A
This
meeting
is
being
recorded,
hello.
Everyone
welcome
to
the
July
10th
edition
of
The
Gateway
API
sync,
as
usual,
we're
reminded
this
sync.
This
community
meeting
is
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
effectively
to
be
nice
to
one
another.
So
please
do
be
nice
to
one
another.
Please
try
to
use
the
raise
your
hand
option
in
Zoom
when
you
have
a
question
or
you
want
to
interject
and
we'll
try
to
we'll
try
to
prioritize.
Accordingly,
we
have
a
little
bit
on
the
agenda
today.
I
wouldn't
say
it's
a
lot.
A
We
have
some
triage
to
fill
in
the
time
if
we
need
to,
and
people
who
don't
want
to
do
triage
can
kind
of
fall
off
at
that
point
if
they
like.
If
you
do
have
anything
you'd
like
to
add
to
the
agenda,
it's
an
open,
Agenda
feel
free
to
put
it
at
above
the
triage
and
if
we
can
get
to
it
today,
we
will,
if
not,
we
can
roll
it
over
to
the
next
meeting.
Also
we
like,
if
people
can
put
their
attendee
account
on
there,
we
just
it,
helps
us.
A
B
Oh
yeah,
just
a
few
quick
notes
on
080
I
know
we'd
been
trying
to
finish
this
out
and
transition
into
API
review
early
July.
So
what
that
means
at
this
point
is
that
we're
trying
to
say
that
anything,
that's
smart,
that
merges
by
the
end
of
the
week,
is
fair
game
and
will
be
covered
by
API
review,
but
we
are
trying
to
start
the
API
review
process
and
release
candidate
process
next
week.
B
We
have
some
thoughts
about
what
gaps
may
or
may
not
make
it
in
there's
a
lot
of
things
right
on
the
edge
right
now.
One
in
particular
that
feels
awfully
close
is
the
timeouts
one
on
HD
route,
but
we've
gotten
into
quite
the
rabbit
hole
in
terms
of
formatting
which
I'll
discuss
later,
but
that
may
end
up
missing
this
milestone,
but
again,
I
think
that
the
main
the
main
goal
here
is
we're
trying
to
get
everything
that
we
can
in
this
week.
B
B
So
yeah,
that's
that's
just
a
heads
up
on
where
we
are.
We
are
trying
to
get
080
out
as
soon
as
we
can,
but
if
you
have
something
you're
trying
to
get
into
this
release,
please
make
sure
it's
in
and
merged
by
the
end
of
this
week,.
A
D
Yes,
yes
I'm
here!
Thank
you
right,
so
I
think
I
wrote
this
down
a
while
ago
and
yes,
we
skipped
it
July
4th.
So
it's
feeling
like
it
I,
haven't,
looked
at
this
for
a
bit.
D
So
there
there's
a
couple
of
questions
still
outstanding
in
in
this
enhancement
proposal
which
I
wanted
to
know
which
ones
would
block
the
gap
or
you
know
if
people
haven't
had
a
chance
to
take
a
look
at
it.
Yet
I'd
like
to
reintroduce
this.
B
B
I
don't
have
as
strong.
My
strongest
opinion
is
that
it
Port
shouldn't
be
in
spec.
Well
it
should
it
shouldn't
be
in
the
actual.
You
know,
body
of
the
policy
itself.
It
should
be
part
of
Target
ref
or
something
like
that,
because
it's
really
a
way
to
to
you
know
Target
a
specific
section
of
a
resource
with
that
said.
I
haven't
thought
as
much
about
if
it
makes
sense
to
just
Target
an
entire
service,
regardless
of
Port
it
might,
in
which
case.
Maybe
we
can
add
port
at
a
later
point.
B
I,
don't
know
if
anyone
else
has
an
opinion
on
that
or
Candace.
If
you
have
an
opinion
on
that.
D
B
B
E
Yeah
I
was
just
kind
of
a
general
comment
like
I
know,
we've
had
a
lot
of
struggles
with
the
scope
of
this
and
what
it
should
be,
but
I
want
to
make
sure
that
if
we're
going
to
have
a
small
scope,
we
explicitly
acknowledge
what
that
means,
because
we've
talked
about
things
like.
Oh,
we
can
just
add
mtls
later
like
from
my
understanding.
This
is
a
dead
end
like
we
will
never
add
mtls
to
this
API.
E
It's
not
fit
for
mtls,
so
I
want
to
make
sure
that
we're
not
glossing
over
things
and
saying
we
can't
think
about
all
the
scope
of
future
things
and
make
sure
that
we
are
thinking
about
them
and
maybe
putting
them
out
of
scope,
but
not
kind
of
forgetting
that,
and
you
know,
you're
down
the
line.
You
start
thinking
about
empty
lesson,
whereas
we
made
a
huge
mistake
in
this
Gap.
E
So
I
could
be
wrong.
Maybe
I'm
misunderstanding:
how
this
can
support
mpls
ever
so
I
might
give
this
some
clarity
on
how
that
could
happen
or
explicit
acknowledgment
that
something
like
that
is
is
not
going
to
work.
Basically,
is
my
point.
B
Maybe
yeah
I
mean
that's
a
good
point,
maybe
just
for
orthotic
a
quick
thought
experiment
here.
B
What
I
think
we're
talking
about
when
we
talk
about
mtls
is
kind
of
a
client
search
that
the
Gateway
would
use
to
communicate
with
the
back
end
as
like
one
piece
of
configuration
that
we
would
want
to
add
somewhere
in
Gateway
API.
Potentially,
this
policy
is
that
what
you're
thinking
as
well
John.
B
And
so,
okay,
and
so
in
that
case,
these
are
both
things
that
the
Gateway
is
doing
to
communicate
with
the
back
end.
Right,
like
one
part,
is
it's
validating
the
the
cert,
that's
served
by
the
back
end
and
two:
it's
configuration
for
what
cert
it
should
use
when
communicating
to
that
backend,
which
is
feels
similar
enough,
that
it
could
potentially
live
in
the
same
resource
right.
E
Well,
another
issue
is
that
one
is
a
server
side,
config
and
one's
a
client
config.
So
we
can't
have
those
be
one
resource
right
like
a
server
can't
tell
me
what
my
password
should
be
when
I
connect
to
it.
It
doesn't
make
sense,
it
can
say
here's
the
properties
of
the
server
and
the
server
goes,
configure
some
and
tell
clients
you
should
use
a
password.
You
should
use
TLS
or
you
know,
use
a
certificate,
but
I
can't
tell
if
what
certificate
to
use
right,
then
it
doesn't.
C
C
D
And,
and
why
do
you
want
to
solve
so
right
now,
mtls
isn't
isn't
supported
in
Gateway,
API,
anyways
right
or
it's
not
defined
or
specified.
At
this
point.
G
E
A
H
A
Say
other
than
I'm
a
little
confused,
so
I
get
the
general
idea,
but
the
the
length
it
might
be,
the
language
more
so
than
the
intention.
That's
kind
of
confusing
me
right
now,
the
the
currently.
This
thing
is
talking
about
how
to
do
TLS
to
a
back
end.
It
does
not
talk
about
how
to
do
Mutual
TLS
to
that
back
end
you're
worried
that
we
might
be
in
a
situation
where,
if
we
don't
specify
that
or
acknowledge
that
we're
never
going
to
do
that
now,
we
won't
be
able
to
do
it
later.
E
E
E
E
D
So
then
I
took
that
to
mean
that
we've
already
decided
that
we're
going
to
handle
these
these
two
different
parts
of
the
connection
separately.
D
So
we're
going
to
handle
the
connection
to
this
from
the
gateway
to
the
server
separately.
Then
we're
going
to
handle
the
connection
from
the
client
to
the
Gateway
and
that's
that's
a
given.
E
D
G
D
So
I'm
going
to
go
out
on
a
limb
and
say
I
I,
don't
I
I
think
we
were
pretty
clear
from
the
beginning
about
the
scope
of
of
this
proposal
and
and
I'm
not
sure
why
it
remains
kind
of
open
or
that
that
we
would
still
be
wanting
to
address
mtls
within
this
proposal.
G
D
A
A
Think
I
I'm
still
a
little
fuzzy
on
the
the
restrictions
to
growth,
I
kind
of
get
it
but
I
think
end
of
the
day.
Just
acknowledging
in
here
somewhere.
That
mtls
is
not
in
scope,
sounds
like
what
John's
asking
for
as
a
potential
outcome,
something.
G
So
I
guess
sorry,
Shane
I
think
I
spoke
over
you,
but
my
general
take
on
it
is
that
if
we
go
this
direction,
it's
okay,
that
we
leave
it
out
of
scope.
But
then
we
also
need
to
basically
say
that
it
needs
to
be
defined,
but
it
will
be
a
different
API
resource
for
mtls
right,
like
that's
the
natural
consequence
of
that.
D
Yeah
I
I
already
mentioned
since
this
is
called
TLS
connection
policy.
I
already
mentioned
something
could
be
done
along
the
lines
of
mtls
connection
policy.
D
I,
don't
know
if
that
was
just
so
terrible
that
nobody
made
a
comment
on
it,
but
or
that
nobody
saw
that
that
or
maybe
John
didn't
see,
that.
E
Have
seen
it
but
I
also
don't
like
a
word
we're
going
to
end
up
with,
like
so
many
different
apis
like
I,
get
the
appeal
of
a
narrow
scope
API,
because
it's
possible
to
make
forward
progress.
Otherwise,
but
you
know
we
we
don't
want
to
end
up
with
500
different
apis
for
every
little
narrow
use
case.
Most
likely
do.
A
A
Mcls
and
the
everything
else
is
something
that
we
can
live
with
going
forward
as
a
provisional
Gap
long
as
we
don't
go
out
of
provisional
until
we
have
solved
the
mtls
thing
or
are
there
other
major
things
we
need
to
resolve
within
this
gift
this
PR,
because
if
it's
just
that
I
would
suggest,
let's
try
to
move
forward
with
everything
else.
That's
in
here
put
a
big
to
do
at
the
top
of
this
Gap.
That
says,
we
do
not
move
out
of
provisional
until
we
have
some.
A
E
A
Not
block
it
for
mtls
but
make
sure,
because
I
think
the
general
idea
here
is
that
if
we
can't
resolve
mtls,
because
this
doesn't
try
to
slash,
doesn't
set
up
a
growth
path
for
it.
Do
we
end
up
having
a
do?
We
end
up
causing
ourselves
a
lot
of
additional
maintenance
in
the
API
over
time
when
we
eventually
do
need
mtls
and
those
are
concerns.
We
always
have
to
be
thinking
about.
With
this
API.
A
We
have
to
make
sure
that
we're
not
putting
our
putting
ourselves
in
in
a
corner
because
there's
so
like
this
is
such
a
high,
a
high
traffic
API
and
stuff
like
that,
and
it
would
be
if
we,
if
we
didn't
think
a
little
bit
ahead
in
terms
of
like
where
we
can
actually
path
to.
A
We
would
end
up
with
so
many
different
apis,
so
many
different
attributes
for
so
many
things
and
it
would
be
a
maintenance
Nightmare
and
the
API
would
be
hard
to
use
for
users
like
users
would
get
to
a
point
where
it's
like
there's
so
many
freaking
options,
and
we
have
to
balance
that
because
there
are
already
so
many
freaking
options.
So
it's
like.
D
To
be
honest,
I
think
separating
this
out
from
all
the
other
pieces
of
the
API.
The
way
that
I
have
been
forced
to
is
is
kind
of
a
you
know,
a
symptom
of
that.
This
is
already
like
picking
it
apart
in
a
way
that
I
don't
think
we
need
to,
but
I
went
that
way.
You
know
to
play
along
with,
what's
going
on
and
in
the
hopes
that
you
know
it's
okay
for
us
to
pick
it
apart
in
this
way.
D
So
now
what
we're
talking
about
is
no,
we
don't
want
to
pick
it
apart
anymore.
We
want
to
go
back
to
like
kind
of
combining
things
together
so.
D
Of
futile
to
continue
this,
to
be
honest,.
A
A
A
Has
to
make
it
in
this
in
this
Gap
just
that
we
have
to
because
we
have
to
respect
everyone's
equity
in
the
process,
and
we
have
to
look
at
things
like.
Are
we
going
to
be
able
to
path
from
here
to
a
future
with
a
nice,
clean,
mtls
implementation,
or
is
it
going
to
cause
problems
to
do
that?
We
have
to
kind
of
stop
and
do
that
exercise
now,
unfortunately,
go.
G
Yeah
but
I
think
like
why
we
have
these
discussions
is
because
there's
fundamentally
a
several
different
usage
models
that
we
are
trying
to
capture
and
unfortunately
they
are
somewhat
in
Conflict
right
like
there's
one
where
we're
saying
hey
the
person
creating
the
service
is
also
going
to
determine
these
things
and
that
there's
another
usage
model
where
it
says.
Actually,
no,
you
know
if
someone
else
like
the
Gateway
owner
should
be
determining
it.
G
G
It
would
be
good
to
hear
other
folks
opinion
on
this,
because
I
think
if
we
separate
these
two
things,
because
they
are
essentially
in
conflict
with
each
other,
so
there's
like
no
way
to
sort
of
like
merge
them
into
the
single
API.
It
might
be.
Okay,
it's
a
bit
more
complicated,
but
that's
kind
of
how
the
world
is
being
represented.
A
Right,
so
maybe
maybe
it's
as
simple
as
that,
and
we
just
need
to
document
it
and
then
the
other
thing
here
it
looks
like
we
are
kind
of
running
really
high
on
time
for
this
one
issue,
so
we
will
have
to
kind
of
wrap
it
up,
but
I
think
I'd
like
to
see
this
just
do
some
kind
of
follow-up
where
we
say
either
we
we
do
resolve
the
mtls
thing
and
document
it
slash.
You
know
whatever
we
want
to
end
up
doing
with
that.
E
A
Okay,
thank
you
all
right.
So
two
more
major
things
to
follow
up
on
in
here.
The
resolution
does
not
have
to
be
the
implementation
of
mtls
is
added.
It
just
needs
to
be
acknowledged
what
we
thought
through
a
little
bit
and
acknowledged
what
we're
going
to
end
up
needing
to
do,
and
then
the
sand
one
needs
to
have
the
same
treatment.
Some
kind
of
continued
pursuit
of
it.
A
D
I'd
just
like
to
comment
that
I'll
be
able
to
work
on
the
mtls
stuff.
That's
not
my
area,
I,
don't
know.
I
I,
don't
really
know
what
the
concerns
are.
So
I
think
we
need
to
split
that
off
from
this
somehow.
A
B
Yeah
I
think
that
makes
sense
in
Upstream,
usually
what
it
is.
It's
an
unresolved
Block
in
in
a
case
of
cap,
but
I
think
that's
what
we
want
here.
I
know
this
has
been
a
really
long-running
PR
and
we
didn't
want
to
make
some
progress
and
there's
a
lot
that
there
is
consensus
on
here,
but
certainly
the
the
path
forward
to
mdls.
B
A
A
This
gets
focus
on
the
same
thing
get
this
merged,
and
then
we
can't
move
out
of
provisional
until
we
just
hyper
focus
in
on
the
mtls
bits
which
I
understand
that
you're,
not
particularly
interested
in
that
one,
we'll
kind
of
have
to
follow
up
on
that
one
Candace,
but
I
just
want
to
say
that
I
appreciate
all
the
effort
that
you
put
in
so
far
and
I
appreciate
the
effort
of
everyone.
Who's
been
reviewing
and
helping
to
try
to
make
sure
that
we
come
up
with
something
that
everybody
can
use.
A
Thank
you
all
right
onward
and
forward
Rob
Geb
1742.
B
Sure,
okay,
so
this
one
has
become
quite
the
rabbit
hole
itself
as
it
turns
out.
So
this
is
really
just
an
addendum
to
the
Gap
related
to
timeouts,
which
is
Gap
1742
they.
B
This
was
initially
proposed
as
using
meta,
V1
duration,
I
think
it
was
Tim
and
maybe
some
others
called
out
that
that's
not
really
been
used
in
a
kubernetes
API
before
at
least
a
official
kubernetes
API
and
there's
significant
discomfort
with
the
idea
of
relying
on
go
duration,
parsing
for
a
kubernetes
API,
so
we've
been
trying
to
figure
out
well
what
could
we
possibly
do
here?
The
simplest
option
is
just
use
an
INT
that
represents
milliseconds,
that
it
gets
really
annoying
when
you're
trying
to
represent
a
longer
timeout.
B
That
would
be
measured
in
hours,
minutes
or
seconds.
The
other
option
would
be
to
use
a
string
and
then
have
a
very,
very
small
set
of
values
that
we
support,
such
as
minutes
seconds
and
milliseconds.
So
it
looks
awfully
similar
to
go
duration,
but
it's
a
very
small
subset
of
that.
I
had
thought
and
hope
that
that
would
work
very
similarly
to
the
XML
spec.
B
Just
because
of
how
crds
were
handled
very
nicely
with
the
meta
V1
duration,
using
that
parsing,
but
as
it
turns
out,
the
actual
XML
spec
has
some
variations
that
Tim
has
highlighted
below.
Unfortunately,
and
so
this
is
more
of
an
update
just
to
say
we're,
maybe
back
to
the
drawing
board
on
this
one
and
apis
are
fun.
B
Ideas
welcome,
you
know
I,
unfortunately,
we're
just
you
know
trying
something
that
just
hasn't
been
done
very
much
in
kubernet
well
at
all
and
kubernetes
apis
I
know
there's
some
prior
art
in
other
implementations
as
far
as
trds,
so
it's
useful
to
get
some
feedback
there
as
well.
But
if
anyone
has
ideas
very
welcome
on
this
one.
A
B
And
that
is
I
guess
option
three
in
that
we
could
do
floating
point,
but
that
has
its
own
problems
and
it's
it's
right.
B
A
B
I'll
have
to
double
check
I
it's
at
least
you
shouldn't,
but
I.
It
may
be
more.
A
B
Yeah
I
I
think
that's
it.
You
know
I
I,
really
time
out.
This
Gap
was
very
close
to
making
it
into
080.
and
it's
annoying
that
it's
getting
held
up
on
what
feels
like
a
technicality.
But
it
is
an
important
one
and
it's
it's
hard
to
to
walk
back
from
something
like
if
you
don't
get
it
right.
The
first
time
I
did
in
the
zoom
chat,
add
a
link
to
the
API
conventions
and
the
guidance
given
and
as
Bowie
kind
of
alluded
to
the
concern
is
round
tripping.
B
H
C
A
A
All
right,
yes,
please,
do
join
in
anybody
who
has
any
thoughts
on
that
any
experience,
especially
we'd
love,
to
hear
some
people's
experiences
road
to
GA.
So
I
did
put
a
post
out.
A
Some
of
you
might
have
missed
it
on
Monday,
before
the
4th
of
July
I
wasn't
really
going
to
be
in,
but
I
was,
and
just
kind
of,
went
through
the
board
and
stuff
like
that
on
my
own
pruned
a
couple
of
things
and
kind
of
made
a
post
about
like
some
of
the
things
that
are
in
the
road
to
GA,
so
I
thought
we'd,
look
at
it
real,
quick
today,
Rob
and
I
before
this
meeting
actually
just
went
Nick's
out
for
a
couple
weeks.
A
So
we
just
kind
of
have
been
doing
a
series
of
over
the
last
few
months
of
like
continuing
to
prune
this
continuing
to
clean
and
try
to
get
it
in
good
shape
and
at
this
point,
we're
down
to
10
things
that
are
ready
to
be
picked
up.
A
21
things
in
progress,
although
I
think
Rob
and
I
are
going
to
kind
of
go
through
these,
because
some
of
these
may
not
be
accurately
described
as
in
progress
but
overall
10
things
that
need
to
be
done
and
then
four
clean
up
things
that
are
kind
of
administrative.
Once
these
things
are
done
to
get
to
ga.
A
So
I
just
wanted
to
kind
of
point
that
out
to
everybody,
if
you
haven't
seen
the
board
before
it's
not
you
can
use
it.
If
you
want
it's
kind
of
been
just
for
us
to
kind
of
do
backlog
grooming,
but
it
is
an
accurate
representation
of
what
it's
going
to
take
left
to
right
to
get
to
GA
and
we're
looking
pretty
good.
You
know
we
have
a
few
months.
We
don't
we
we're
in
a
you,
know,
open
source
community,
so
we
don't
have
like
dedicated
for
sure
engineering
hours.
A
So
there's
always
some
risk.
If
there's
anything
that
you
can
pick
up
anything
that
you
even
have
an
inkling
that
you'd
like
to
pick
up.
Please
do
and
please
do
reach
out
to
us
and
ask
for
help
like
if
you're,
like
I
kind
of
want
to
work
on
this,
but
I
just
don't
even
know
where
to
start.
Ask
us
where
to
start
we'll
be
happy
to
have.
You
know
a
sync
with
you
on
slack
or
something
like
that
and
kind
of
help
you
along
the
way,
and
we
appreciate
the
help.
A
F
Hey
hi
everyone,
so
this
is
more
on
along
the
lines
of
an
informational,
update,
I
believe
we've
been
having
this
discussions
regarding
how
we
can
improve
the
observability
of
policy
attachment.
One
of
the
options
mentioned.
There
was
like
to
develop
some
kind
of
a
plug-in
or
a
binary
or
a
library
so
that
you
can
kind
of
see
what
which
our
policies
are
attached
to
your
gateway
resources.
F
So
I've
tried
to
come
up
with
some
kind
of
a
minimal
boc
which
tries
to
do
or
achieve
that
it's
still
in
a
very
nascent
stage
and
there's
lots
of
things
to
be
done.
But
I
just
wanted
to
call
this
out
that
I'm
working
on
something
similar
to
this
and
yeah.
If
we
have
some
time,
maybe
I'd
like
to
share
my
screen
and
show
you
what
all
we
can
support
right
now
or
if
you.
A
Sure
all
right
I
think
so
let
me
let
me
double
check.
Actually
yeah.
We
have
like
one
more
item.
We
should
be
good.
I
will
have
to
make
you
co-host,
I
think
for
it
to
work.
F
F
One
of
the
things
is
like
finding
out
what
all
policies
are
available
to
you,
so
you
can
do
it
through
if
we
got
to
get
policies
on
this
should
list,
like
all
the
policies
that
are
attached
to
various
resources.
For
example,
I
have
a
health
check
policy
which
which
is
attached
to
this
particular
Gateway,
so
this
kind
of
tries
to
solve
that
problem
that
you
don't
know
which
our
policies
are
affecting
your
resources.
F
We
can
also
do
something
like
fit
all
policy
crds,
which
will
show
you,
which
all
policies
are
available
to
you
to
create
resources
for,
for
example,
right
now
we
just
have
like
these
are
some
dummy
policies
that
I
created
test.
This
out,
you
could
do
stuff
like
some
of
this
is
like
inheriting
things
from
Cube
control.
F
For
example,
you
can
list
HTTP
routes,
but
how
it
shines
is
that
you
could
do
something
like
describe
HTTP
routes,
and
this
will
show
you
what
detail
view
of
what
your
HTTP
routes
are,
along
with
any
policies
which
may
be
affecting
you.
There
could
be
direct
policies
which
are
attached
to
your
HTTP
routes
directly,
or
it
will
also
also
show
you
like,
if
it's
being
affected
by
any
inherited
policies,
for
example
from
your
gateway
or
your
gateway,
class
or
yeah
right
now
there
isn't
support
for
name
spaces,
but
I
will
add
it
soon.
F
So
I
thought
I'll
call
this
out
that
if
anyone
has
any
brilliant
ideas
regarding
how
we
can
improve
this
or
any
concerns
or
stuff
like
that,
please
do
reach
out
to
me
on
slack
or
through
the
issues.
Yeah
I
think
I'll.
Stop
sharing
my
screen
now.
Yeah,
that's
cool.
B
B
Awesome
to
see
a
live
demo
go
perfectly
so
well
done.
B
Really
great
to
see
this
I
think
this
is
something
that
we
were
interested
in
in
making
a
you
know:
kubernetes
six
project
or
maybe
integrating
directly
in
Gateway
API
at
some
point.
But
it's
great
to
see
this
just
you
know
working
already,
I,
don't
know
you
still
have
more.
You
want
to
do,
but
a
really
great
demo
and
I
I
think
this
is
going
to
make
the
policy
ux
a
lot
more
manageable
and
easier
for
people
to
to
wrap
their
heads
around
so
yeah.
Thank
you.
A
F
A
B
Yeah
I
talked
a
bit
with
Shane
about
this
as
well,
and
we
you
know,
the
the
big
question
is
if
this
becomes
something
like
University
Gateway,
a
separate
project
or
if
we
integrate
it
directly
in
Gateway
API,
the
repo
itself
I
think
there's
good
arguments
either
way.
If
someone
has
an
opinion
on
that,
definitely
let
us
know,
but
I
think
we
we
do
want
this
to
become
community
owned,
it's
just
where.
So,
if
anyone
has
a
strong
opinion,
let
us
know.
A
Thank
you
and
next
Dave,
the
Gateway
routability
PR's
you're,
going
to
be
out
on
Thursday,
so
want
the
feedback
sooner
rather
than
later.
I
did
just
CC
myself
on
this.
It's
like
seven
o'clock
my
time
so
I
won't
do
it
tonight.
C
A
Thanks:
okay,
good
yeah,
so
we
we
did
drop.
It's
dropped
in
v080
with
the
expectation
it
would
probably
be
merged
this
week,
we'll
see
but
yeah
I
get
the
I
appreciate
you
making
the
extra
call
out
that
you
won't
be.
Oh
actually,
I
read
that
wrong.
The
first
time
you'll
be
gone
Thursday
morning,
you'll
be
going
Wednesday
night.
So
next
couple
of
days,
okay,
yeah.
C
A
All
right
don't
see
any
hands
raised
on
that
one.
Just
to
call
out
for
review,
we
can
move
on
to
triage
I
did
notice.
We
have
a
pretty
big
turnout
today,
it's
like
25,
it's.
C
A
Decent
I
think
in
the
future,
I
should
remember
to
ask
people
if
they're
like
like
ask
for
I,
think
there's
probably
some
newcomers.
We
should
probably
like
do
the
thing
where,
like
people
talk
about
what
they're
doing
please
do
come
to
the
next
one,
we'll
try
to
remember
to
do
that.
More
often,
we'd
love
to
hear
from
people,
especially
people
who
are
just
joining
and
stuff
like
that,
like
what
your
use
cases
are
and
stuff
like
that,
it's
really
great
to
see
such
a
big
turnout
but
I.
A
A
B
Yeah
I
think
honestly,
I
think
this
one
is
an
unfortunate
bug.
Almost
I
think
we
can
get
away
with
making
a
field
that
had
no
default
have
a
default.
If
it's
a
no
one
value
I
think.
But
this
is
someone
who
just
we
just
need
to
go
through.
Api
Machinery,
maybe
try
it
and
then
see
if
it
gets
caught
in
API
review,
but
we
should
try
round
tripping
and
seeing
if
it
if
it
works
with
the
the
API
conventions
that
in
backwards
compatibility
guarantees
that
we
already
have.
B
A
H
B
Yeah,
if
you're
going
to
specify
a
certificate
ref,
it
feels
awfully
strange
to
have
it
for
any
reason,
other
than
terminate
so
I,
don't
know.
Maybe
someone
from
an
implementation
that's
handling
this
today.
Is
anyone
handling
that
the
MV
state
today
with
with
any
Behavior
or
just
invalid.
E
B
B
Maybe
this
is
a
non-issue,
okay
cool!
Why
don't
you
assign
that
one
domain
I'll
clean
it
up?
If
it's?
If
it's
not
an
issue.
A
B
Here
yeah
he's
he's
in
EU,
so
you
can't
make
this
one,
but
this
is
more
just
an
informational
there's,
a
gap
that
exists
for
this
system,
like
we've
talked
about
for
a
while.
Leora
has
started
work
on
it,
but
there's
been
some
reviews
already.
But
if
you
care
about
this
feature,
especially
if
you
have
an
implementation
that
is
populating
support
features,
this
is
very
relevant
to
you.
B
A
Yes,
indeed,
that's
pr2163,
if
you
don't
mind
taking
a
look
supportive
features
in
Gateway
class
status,
I
guess
the
summary
is
effectively
any
controller.
If
you
will
that
picks
up
and
acknowledges
a
Gateway
class
would
then
say
in
the
status
what
features
it
supports
for
HTTP
route
and
so
forth.
A
That's
like
extended
features
so
in
case
that
wasn't
clear.
I
just
want
to
make
sure
I
clarified
it,
but
maybe
that
was
redundant.
A
B
Yeah
I
don't
see
him,
but
I
I
would
just
say
that
this.
This
is
something
that
GK
would
be
interested
in
and
I
think
obviously
others
as
well.
A
Are
you,
are
you
suggesting
like
we?
We
do
it
as
like
a
nice
to
have
try
to
see
if
we
can
get
it
in.
B
D
B
Are
interested
in
this
maybe
add
a
thumbs
up
or
or
something
like
that.
C
A
B
This
is
one
I
I
had
lost
track
of,
but
I
know
Grant
put
a
lot
of
effort
into
it.
It
just
happened
to
come
up
when
I
was
out
of
office.
I
think
something
like
that
and
I
haven't
had
enough
time
to
give
it
up
a
thorough
review.
I,
don't
know
if
Grant
is
on
this.
Oh
Grant,
you
are
on
this
call.
So
I
don't
know.
If
you
have
anything
more
to
say
about
it,.
H
None
I
I
got
a
review
from
Sanjay
and
he's
been
helping
out
a
lot
but
welcome
anybody
else
to
come
and
take
a
look
at
what
we're
talking
about.
I
I.
Don't
think
this
is
perfect,
yet
I
I
think
I,
just
kind
of
took
a
stab
at
what
a
possible
solution
would
be
and
we're
kind
of
iterating
over
that
right
now.
So
I
definitely
welcome
other
ideas
and
different
opinions.
A
You
pinged
me
I'm.
Sorry,
I
missed
this.
Oh
it
was
five
hours
ago.
I
don't
catch
up
with
things
until
like
it
takes
a
while
to
get
through
my
queue.
All
right,
I'll
take
a
look
at
this
one
tomorrow
morning,
probably-
and
here
I'll
just
bookmark
it
to
make
sure
I,
don't
miss
out
on
that
I'm
sure
I
have
a
notification.
I
haven't
gotten
to
yet,
but
cool
session
persistence.
One
is
quite
in-depth
appreciate
all
that
effort.
C
B
This
is
one
that
came
up
in
a
review
of
I
forget.
Oh,
this
is
routability
specifically
and
for
those
not
familiar,
we
have
a
series
of
awful
hacks
in
our
crd
generation
code
that
allow
us
to
do
the
experimental
model
we
have
today
and
it
basically
it
looks
for
that
Gateway
experimental
tag
and
removes
the
the
field
from
standard
crds.
It's
it's
just
a
series
of
hacks,
but
it
so
far
has
worked
for
us.
B
One
of
the
things
we're
running
into
now
is
that
we're
adding
more
and
more
experimental
guidance
to
the
API
spec
itself.
So,
for
example,
gamma
has
a
lot
of
it's
API,
spec
guidance
that
is
really
only
specific
to
the
experimental
Channel.
We
don't
have
a
good
way
to
exclude
that
from
crd
API
spec.
Anything
like
that
I
I.
This
basically
just
is
a
reference
to
some
code
where
that
lives
today,
I
know
in
Gateway
API.
B
Most
of
our
most
of
the
work
that
you
can
contribute
to
right
now
is
API
changes
in
docs
and
whatever
this
is.
If
someone
just
wants
to
hack
away
on
good
old-fashioned
code,
this
is
a
an
issue
that
is
wide
open
for
the
taking
and
would
be
really
nice
to
have
pre-ga,
not
not
strictly
required,
but
would
be
really
nice.
F
A
A
series
of
hacks
that
do
what
we
need
right
now
sounds
so
much
like
the
usual
timid
way
of
talking
about
your
production
code
base.
But
do
you
do
you
want
me
to
mark
that
one
as
on
the
road
to
GA
and
in
V1,
but
we
just
won't
call
it
a
release.
Blocker
then.