►
From YouTube: SIG Network Gateway API meeting for 20230530
Description
SIG Network Gateway API meeting for 20230530
A
Hello:
everyone
Welcome
to
the
May
30th
edition
of
The
Gateway
API
sync
today
on
an
alternate
time
at
8.
30
a.m,
Pacific
to
be
more
friendly
towards
EU
time
zones.
As
usual.
This
meeting
is
governed
under
the
kubernetes
code
of
conduct
boiling
down
to
be
nice
to
one
another.
So
please
do
be
nice
to
one
another
and
in
general,
as
we
move
through
the
meeting,
if
you
haven't
been
to
one
of
these
before,
please
use
the
raise
your
hand
feature
in
Zoom,
as
it
helps
us
to
organize
conversations.
A
We
have
a
fair
amount
of
agenda
items,
but
if
you
have
something
else
that
you
want
to
add
it's
an
open
Agenda,
please
do
feel
free
to
drop
something
above
triage.
Underneath
people's
individual
agenda
items
as
we
go
and
I'll
share
my
screen
and
we
will
go.
A
Can
you
see
the
agenda
doc?
Yes
yeah,
so
the
turnout
here
is
pretty
good.
If
you
wouldn't
mind
putting
your
name
or
just
something
down
in
the
attendees,
we've
been
tracking
and
we
are
looking
to
hopefully
eventually
do
like
a
regular
EU
friendly
time
zone,
knowing
how
many
people
and
what
people
are
showing
up
helps
us
a
little
bit
just
to
know
better.
What
we're
doing
we
appreciate
it.
A
Okay,
so
I
have
a
couple
of
quick
updates
that
I'll
start
with
and
then
I'll
hand
it
off
to
Rob
talk
about
b071.
We
have
a
timeouts
Gap,
oh
yeah,
no
timeouts
get.
That
is
what
I
wanted
to
talk
about,
so
the
timeouts
get
is,
has
had
a
couple
of
iterations.
It
is
currently
in
provisional,
but
those
who
have
been
contributing
to
it
are
pretty
much
in
the
mood
to
move
it
to
implementable.
A
Now
I
asked
them
to
keep
it
in
provisional,
just
a
little
bit
longer
with
the
pr
that
merged
on
Friday,
so
that
we
could
take
a
little
bit
of
soak
time,
since
this
will
affect
probably
everyone
and
had
wanted
to
bring
it
up
so
that
everybody
just
knows
that
we're
at
that
stage.
Next
couple
of
weeks,
probably
we're
looking
at
moving
into
implementable
and
actually
like
getting
some
gas
in
the
tank.
So
please
do
check
it
out.
It's
1742
and
it's
up
on
our
website.
I
can
post
a
link
to
it
in
I.
A
C
A
So
please
do
check
it
out
if
you're
interested
I
feel
like
almost
anybody.
Who's
implementing
should
be
interested,
maybe
and
give
it
a
look
over,
make
sure
everything
kind
of
jives
and
we
really
encourage
people
to
come
up
with
small
PRS
to
tweak
the
document.
We
love
to
have
people
collaborate
join
together
because
we
will
almost
always
probably
come
up
with
a
better
solution
if
we
collaborate
up
front
than
if
we
get
it
to
a
point
where
we've
implemented
and
then
the
collaborators
come
in
and
we
have
to
change
things.
A
C
Yeah
that
so
custom
the
proposed
apis
in
the
pr
link.
It
is
fairly.
D
Is
that
it
is,
it
is
proposing
to
add
fields
to
http.
C
Yeah
the
yeah-
it
will
be
one
thing,
I
should
call
out
here.
The
last
bit
of
feedback
was
that,
or
at
least
that
I
added
was
that
the
original
proposal
had
suggested
that
the
lack
of
a
timeout
value
meant
no
time
out
and,
unfortunately,
like
that's,
not
backwards
compatible,
because
many
implementations
are
already
setting
a
timeout,
so
I
think
we're
going
to
run
into
this
pattern.
A
lot
where
the
lack
of
a
value
does
not
mean
zero.
It
just
is
implementation.
C
Specific
may
just
have
to
keep
on
using
that
as
a
pattern
for
lots
of
new
apis,
as
we
add
them.
D
C
Especially
at
least
for
apis
like
this,
this
is
HP
route.
Now
it's
already
largely
stable
and
no
breaking
changes.
There
I'd
say
for
resources
like
TCP
route
that
are
still
experimental
actually
and
that's
a
bad
example.
I
can't
see
that
one
having
a
breaking
chain,
I
I,
can't
see
many
examples
in
Gateway,
API
or
we'd
have
a
breaking
change.
You
technically
put.
D
It
in
experimental
but
yeah
you
technically
could
but
the
generally.
If
we
were
going
to
make
a
breaking
change,
we
would
rev
the
API
version
as
well,
so
it
yeah
we
would
have
to
have
V1
now
V1
Alpha,
three,
which
you,
the
three
of
us,
are
pretty,
who,
like
have
the
final
say,
are
pretty
reluctant
to
issue
a
new
API
version
without
a
very,
very
good
use,
case
yeah,
and
so,
but
we
are
100
sticking
to
the
kubernetes
API
conventions
and
API
changes,
stocks
that
are
available
upline
like
yes,
absolutely.
D
Yeah
so
I
think
I
was
sorry
yeah
that
that's
yeah.
You
found
the
you
found
that
you
found
the
API
for
custom.
Thank
you
yeah.
So
it
adds
a
timeout
stanza
with
with
with
two
timeouts
in
it.
A
A
So
that's
where
my
head
was
I
for
some
reason:
I
had
thought
it
had
merged,
but
it
it's
just
that
we're
not
when
this
merges.
We
won't
be
going
straight
to
implementable,
but
it
should
be
fairly
shortly
after
that.
So
now
is
the
time.
Please
do
jump
in
pull
request.
1997
has
a
lot
of
new
content
and
then
the
Gap
overall,
please
do
jump
in
and
check
it
out.
F
Meta
question
here:
how
will
be
the
process
to
roll
this
out?
So
let's
say
this
merges:
it
will
go
into
a
API.
You
know
version
the
crds
will
be
rolled
out
at
some
point
by
each
vendor
or
by
implementation
or
by
someone,
and
then
users
will
start
using
them
because
they
know
that
it's
there
or
how?
How?
How
do
we
kind
of
roll
out
this
kind
of
changes
in
in
real
life
in
production?
F
D
You
want
it
yeah,
so
yeah,
so
the
way
that
we
roll
it
out
so
there's
two
two
ways
that
we
two
parts
to
this
question.
Firstly,
there's
the
you
know
how
we,
how
we
roll
This
change
into
the
API
in
a
backwards
compatible
way.
This
is
adding
new
Fields
with,
as
Rob
said,
defined
Behavior
like
these
will
be
optional.
Shields
they'll
have
a
defined
behavior
when
they're
not
present,
and
you
know
or
the
defined
behavior-
is
that
it's
implementation
specific,
but
it's
still
a
defined.
D
It's
still,
there's
still
a
definition,
and
so
that
makes
this
a
backwards
compatible
change.
D
It
is
an
additive
change
and
so
like
would
there
would
be
a
new
API
like
the
CID
will
be
changed
as
part
of
a
bundle
version,
and
so
the
bundle
version
will
be
version,
801
1.0,
one
of
the
bundle
versions
and
then
and
then
yes
as
part,
the
users
will
know
how
to
use
it,
because
we
will
mention
it
in
the
Change
clock
for
the
release
of
the
kubernetes
API
and
one,
and
then
the
implementations
will
need
to
pick
up.
D
Obviously,
because
this,
because
of
the
way
that
this
is
being
added,
it
will
be
extended.
It
won't
be
a
course
port,
a
core
feature,
so
there
will
be
a
conformance
test
for
it
and
it
will
be
an
optional
feature
that
you
can
opt
into.
I
would
imagine
that
if
we
get
good
like
really
good
support
for
this
over
time,
then
this
is
a
good
candidate
for
something
that
would
be
able
to
conceivably
make
its
way
from
an
extended
decor.
However,
that
depends
on
core
means.
Every
implementation
has
to
do
it.
D
F
Yeah
I,
don't
know,
is
that
that's
that's
yeah,
normal
and
and
expected
I
mean
I
was
more
practical,
let's
say:
I'm
a
user
like
I
write
an
HTTP
route
and
I.
Add
this
time
out
and
I
happen
to
deploy
with
Helm
in
some
clusters
that
doesn't
have
this
version
like
JK,
for
example.
It's
you
know,
they're,
it's
a
managed.
It's
automatically
upgraded
assume.
Most
vendors
will
have
some
automatic
system
to
keep
this
in
sync.
So
will
it
will
the
config
be
rejected
now
I
think
the
validator
will
ignore
the
field.
So
it's
fine
yeah.
F
D
Yes,
it
is
dropped
when
it's
written
to
okay,
when
it
when
a
unknown
Fields
as
a
crds
moving
to
V1
field
pruning
is
enabled,
which
means
that
unknown
fields
are
pruned
and
are
never
persistent
to
LCD,
and
so
because
it's
never
persisted
to
ATD.
D
As
far
as
API
server
is
concerned,
it's
gone
if
you
try
and
apply
that
again,
the
same
thing
will
happen
until
the
the
CID
definition
includes
that
field,
at
which
time
then
it
will
be
added,
then
it
will
be
persisted
to
storage,
there's,
more
complexity,
there,
around
storage
versions
and
a
bunch
of
other
stuff
like
that.
That
I
think
Rob's
going
to
talk
about
in
just
a
minute.
C
C
We're
we're
reaching
a
point
where
it
will
be
very
helpful
for
implementations
to
understand
the
bundle
version
of
crds
installed
in
the
cluster,
and
when
that
bundle
version
is
newer,
then
they
are
aware
of
so.
Let's
say
istio
an
older
version
of
istio
is
running
and
a
newer
version
of
crds
is
installed.
C
Istio
should
probably
put
out
some
kind
of
warning
saying
this
version
of
istio
only
supports
you
know:
Gateway
v060
and
I,
see
that
you
have
Gateway
071
I,
don't
know
whatever.
Just
there
may
be
features
in
Gateway
API
that
you
are
configuring,
that
we
don't
see.
That
feels
like
kind
of
the
the
fundamental
thing
we
need
to
solve
and
find
a
way
to
communicate
consistently
throughout
the
API
and
I
think
costs,
and
that
may
have
been
where
you're
heading
with
this.
F
D
D
A
D
I
was
gonna,
say
yeah
as
an
action
that
that
last
thing
that
Rob
said
you
know
I
kind
of
have
a
pending
on
item
I've
had
for
a
while
to
put
some
updates
into
the
implementer's
guide
that
understanding
the
bundle
version
of
CID
has
been
recommending
that
people
check
the
CID
version.
Bundle
on
on
control
on
implementation,
startup
is
actually
a
you
know.
D
A
good
one
for
the
I
think
making
sure
unknown
fields
are
saved,
actually
is
a
complete
Minefield
that
API
Machinery
strongly
recommend
not
doing
it
has
like
weird
artifacts.
If
you
do
that
about
round
tripping
and
a
bunch
of
other
things,
so
it
is
strongly
recommended
that
you
don't
that's
why
you
can't
that's
why
CID
version
one
which
doesn't
putting
isn't
enabled
by
default
so
on
those
fields
are
not
never
saved,
isn't.
F
D
So
reapplying
it
will
once
the
CID
definition
includes
the
fuel
reapplying,
it
will
change
it.
However,
you
can
always
check
what
is
actually
saved
by
pulling
pulling
by
getting
the
config
from
the
API
server.
The
config
that's
saved
in
the
API
server
will
only
show
the
reason
you
do
this
is
that
the
configs,
that's
in
the
API
server
will
show
you
only
the
fields
that
have
been
resisted
sdd,
so
you
can
always
check
what
the
current
version
is
by
by
getting
the
resource.
F
F
A
We
have
a
couple
potential
action
items,
one
kind
of
a
general
thing
to
provide
some
something
related
to
what
Rob
said
about
providing
some
like
I'll,
say
standard
about
how
implementations
should
try
to
warn
users
about
unknown
Fields,
old,
crd
versions,
Etc
and
then
potentially
updating
the
gap
with
more
documentation
about
how
this
is
going
to
affect
people
in
the
field.
A
So
for
the
first
one,
does
anybody
just
want
to
go
spin
up
an
issue
for
that
seems
like
it's
fair
enough
to
just
kind
of
Define
what
we
talked
about
here
as
an
issue
and
Market
documentation.
C
A
Can
do
that?
Thank
you
for
the
second
one.
Costan.
Are
you
in
a
in
a
in
a
position
where
you
you'd
have
some
time
to
like
make
a
PR
to
the
Gap
to
kind
of
add
some
notion
of
like
we
need
to
have
some
sort
of
like
documentation
for
how
this
works?
Even
if
it's
just
one,
you
know
paragraph
about
like
how
this
is
expected
to
work
in
the
in
the
wild,
because
it
sounds
like
that's
what
you
were
kind
of
getting
at
right.
F
Actually,
the
issue
for
in
general
and
and
I,
don't
think
it's
specific
to
this
issue.
In
any
case,
I
mean
there's,
not
people
will
not
look
at
the
timeout
to
figure
out.
This
is
something
that
we
should
put
kind
of.
More
Central
applies
to
any
future
change
to
the
API,
so.
A
A
A
We
were
just
talking,
they
do
yeah,
they
do
yeah.
So
we
expect
this
to
not
really
be
an
issue,
but
there
may
be
somewhere
constant
seems
to
be
pointing
at
it
may
be
worth
documenting
somewhere
how
this
could
potentially
confuse
people
who
are
on
like
older
crd
versions
or
something
I'm,
not
exactly
sure.
I
was
trying
to
see
if
we
could
come
up
with
a
a
decent
action
item,
but
I
think
at
least
starting
with,
like
warnings
and
stuff
like
that
is
in
a
step
in
the
right
direction.
I'm
sure
Rob.
D
You
know
not
pruning
on
own
Fields
because
they're,
because
it
does
open
a
bit
of
a
open
response,
but
I
think
the
cost
dispoint
about
the
fact
that
if
your
thing
has
fields
that
are
unknown,
you
might
need
to
reapply
the
object
to
have
those
fields
take
effect
after
a
CID
upgrade
is
the
is
the
sort
of
the
key
call
out
there.
Sorry
I
cut
someone
off.
B
I'd
kind
of
like
to
see
I'm
I'm,
trying
to
think
through
a
situation
in
which
this
would
actually
bite
somebody,
and
it
would
be
nice
to
see
that
written
down,
just
as
a
an
example
of
what
exactly
this
concern
is
because
it
hasn't
applied
if
you've
not
applied
picking
on
timeouts.
If
you
have
not
applied
a
version
of
the
Gateway
crds
that
support
timeouts,
they
should
fail
validation,
and
if
you
have
applied
it,
then
the
cube
API
server
should
persist
it.
So
what
am
I
missing
here.
D
B
D
Yeah
yeah
I
think
yeah,
the
key
part
there
is,
it
all
depends
on
exactly
how
how
the
validation
works
and
you
whether
or
not
unknown
Fields
will
make
you
failed
validation,
which
I
don't
know
if
they
did
by
default.
So
if
that
doesn't
happen,
if
that
happens,
then
you.
A
A
No
problem,
the
next
thing
is
just
a
quick
little
burb.
Some
of
you
may
be
interested
in
ebpf
and
developing
and
deploying
ebpf
programs
to
your
kubernetes
nodes.
We
have
an
ebpf
Channel
now
and
we've
been
getting
more
attraction
than
I.
Think
we
expected
to
we've
had
a
lot
of
people,
including
some
of
the
bigger
names
in
like
the
ebpf
ecosystem
like
Bill,
Mulligan,
Dan,
Fenner
and
stuff,
like
that
have
kind
of
showed
up.
A
Liz
rice
has
showed
up,
and
we've
had
a
couple
of
impromptu
kind
of
fun,
zooms,
where
we
haven't
really
done
anything
super
serious,
but
we've
talked
about
the
general
problems
with
this
ecosystem
today
and
what
we
might
do
to
fix
it.
We
are
considering
whether
or
not
we
would
want
an
actual
working
group
to
work
on
some
specific
problems
and
if
you're
interested
I
just
wanted
to
do
a
call
out
because
I
figured
this
is
mostly
a
networking
group.
Ebpf
has
a
lot
of
roots
in
networking.
Please
do
join
us
there.
A
Our
next
meeting
I
think,
is
next
Monday
and
it's
kind
of
like
I
said
a
little
bit
relaxed
and
kind
of
laid
back
meeting
and
from
there
we'll
probably
decide
if
we're
going
to
move
forward.
But
the
general
purpose
is
to
make
the
ecosystem
for
these
kinds
of
programs
better.
C
Cool
yeah,
we
got
a
lot
of
cherry
picks
back
to
the
release,
07
branch,
which
will
be
071
coming
out
either
today
or
tomorrow,
but
awfully
soon
Milestone
is
amp
D.
That
just
means
we
need
to
change
log
and
to
trigger
release
with
patch
releases
like
this.
We
have
not
done
release
candidates,
so
I
expect
we're
just
gonna
go
straight
to
071.
C
C
Yeah
and
with
that
maybe
I'll
just
keep
on
moving
because
I
know:
we've
don't
have
that
much
time.
Next
up
is
a
really
big
change.
If
there
were
one
change
to
pay
attention
to
in
this
entire
meeting,
it's
this
one
I,
I'm,
biased
but
I,
feel
like
this
is
someone
something
that
could
trip
people
up.
This
is
really
just
keeping
the
ball
rolling
on
a
lot
of
changes
to
API
versions.
This
is
related
to
again
version.
Sku
would
become
problematic
here.
C
In
the
early
days
of
this
API,
we
said
it
is
fine
to
just
read
and
write
from
V1
Alpha
2,
because
V1
Alpha
2
is
in
the
crds.
That
is
no
longer
the
case
with
this.
This
PR.
Should
it
get
in.
What
it
will
mean
is
that
V1
Alpha
2
will
still
served
is
not
ex
is
no
longer
served.
C
So,
although
it's
present
in
the
in
the
crd
definition
for
conversion,
it
is
not
actually
served
and
accessible
for
anyone
trying
to
use
this
I'm
hoping
this
doesn't
come
as
too
much
of
a
surprise.
Anyone
using
it
in
Prior
versions
of
the
API
for
at
least
six
months
would
have
gotten
a
deprecated
warning,
so
hopefully
that's
sufficient
and
reference
Grant
is
kind
of
one
step
behind
this,
where
it's
moving
to
deprecated
and
we're
bumping
Alphas
moving
the
deprecated
or
bumping
the
storage
version
to
Beta
yeah.
C
Hopefully
this
does
not
come
as
a
surprise
to
anyone,
but
just
make
sure
your
implementations
are
reading
and
writing
from
beta
as
soon
as
possible,
because
this
will
be
a
big
change.
C
H
That's
all
probably
the
other
thing
to
add
to
this
is
you
need
implementations
or
deployments
of
your
implementation
to
migrate
off
of
Old
storage
versions?
Just
applying
the
crd
doesn't
trigger
this
migration
so.
A
C
C
It's
not
needed
for
this
specific
change,
because
the
old
versions
are
still
in
the
crd.
We
haven't
actually
removed
API
versions
right,
but
when
we
do
do
that,
if
we
do
that,
that
will
become
a
very
big
deal.
It's
called
Cube
Storage
version
migrator
and
basically,
what
it
does
is
any
any
resource
in
your
cluster
that
is
using
an
old
storage
version
is
just
touched,
like
a
no-op
update
just
to
use
the
latest
storage
version
yeah.
That
will
certainly
be
something
we
should
recommend.
If
and
when
we
fully
remove
Alpha
One.
A
B
H
Forget
exactly
what
it
is.
You
can
do
an
empty
patch.
It's
not
recommended
for
all
use
cases
for
this
use
case.
It
might
make
sense
like
in
Key
native
use
empty
patches,
because
we
know
the
backing
implementation
is
using
the
kubernetes
API
versus
like
a
some
sort
of,
like
extension,
but
the
storage
migrator
tool
actually
doesn't
get
and
then
update
yeah,
which
is
like
really
over
the
top.
A
Somebody's
taking
notes
thanks
yeah,
so
please
do
check
that
one
out,
I
put
it
in
the
channel.
That's
2069
is
the
poll
number
very
important
for
everyone
and
then
in
the
future,
be
ready
to
migrate
your
stuff
potentially,
but
not
super
soon,
all
right!
A
D
This
one
should
be
pretty
quick,
so
there
was
actually
two
ways
that
you
can
handle
having
a
single
Gateway
that
has
mobile
host
names
and
has
Superior
apps
that
attach
to
those
you
can
do
you
can
use.
You
can
name
name
your
rules,
yeah,
sorry,
name
listeners
that
should
be
listen,
name
and
then
parent
rev
section
name.
D
And
if
you
do
that,
then
you
know,
then
the
whole
system
will
work,
the
the
HTTP
routes,
PKA
section
our
listener
name
and
only
attached
to
that
listener.
However,
you
can
also
have
the
same
thing
happen
by
having
by
putting
a
hostname
a
distinct
hostname
on
each
listener
and
then
specifying
the
hostname
that
you
want
to
attach
to
in
the
HTTP
route.
This
will
work
out
the
same,
because
the
the
HTTP
route,
with
a
specified
host
name,
will
only
attach
to
the
distinct
listeners.
D
D
They
reached
first
up
for
the
for
using
host
names
as
discriminators,
rather
than
using
section
name
and
name,
so
it
may
be
sort
of
that
people
will
end
up
using
that
more
often,
in
which
case,
maybe
we
might
need
to
just
sort
of
make
a
couple
of
callouts
in
the
dock
somewhere
to
say
if
you're
doing
it.
This
way,
that's
okay,
but
the
you
know
there
are
a
couple
of
another
interactions
that
maybe
might
not
be
clear
for
you.
It's
not
necessary.
A
D
Yeah
good
day,
but
I
also
wanted
to
check
and
see,
does
that
Market
people
yeah
yeah
does
that
does
that
I
mean
it
means
that
we've
got
two
ways
to
configure
the
same
thing
kind
of
it's
not.
You
can
use
two
different
ways
to
configure
the
same
thing,
but
they're
not
really
the
same
thing
at
all
in
some
in
some
senses.
So
I
just
wanted
to
sort
of
bring
this
up
and
say:
hey
it
kind
of
means.
We've
got.
D
We've
tried
to
avoid
heading
down
the
the
the
Pearl
way
of
Tim
Toady,
and
you
know
we
should
own.
Ideally,
we
should
have
only
one
way
to
do
things
rather
than
having
multiple
ways
to
do
things,
but
I
think
that
you
know
in
this
case
it's
probably
acceptable,
but
I
just
wanted
to
call
it
out
and
for
people
to
think
about
it,
and
if
you
can
think
of
things
we
shouldn't
be
doing
or
should
be
doing
here,
then
that
would
be.
It
would
be
good
to
have
someone
else.
A
15
out
of
no
14
out
of
16
people
just
went
and
tried
to
search
Pearl
Tim
toady.
D
Yeah
Pearl
used
to
have
a
used
to
have
a
acronym
that
was
like
there's
more
than
one
one
way
to
do
it,
which.
D
Yeah
yeah
and
anyone
who
has
tried
to
read
Paul
written
by
someone
else,
can
tell
you
that
Tim
Toady
means
that
Pearl
is
very
idiosyncratic
language
and
it
can
be
very
difficult
to
read
Pearl
written
by
someone
else
or
even
you
three
months
ago,.
B
It's
actually
particularly
bad
if
you're
trying
to
read
Pearl
written
by
a
pearl
practitioner,
who's
more
advanced
than
you
are
oh
yeah,
but
it's
hard
for
me
to
see
why
having
two
ways
of
doing
this
is
as
a
practical
matter,
it's
hard
for
me
to
see
how
you
could
prevent
that.
It
doesn't
seem
like
a
terrible
thing
in
this
case,
and
it
does
seem
like
having
the
documentation
explicitly
call
out
hey
by
the
way.
There's
this
interaction
with
wild
card
hosts
and
host
names.
B
That
seems
like
a
great
thing
to
point
out
very
explicitly
in
the
docs
I
would
tend
to
agree
with
you
by
the
way.
I
would
think
that
people
would
I
would
think
that
people
new
to
the
API
would
be
much
more
likely
to
look
at
multiple
listeners
with
smaller
cardinalities
of
host
names,
rather
than
the
section
names
up
front.
B
D
I
guess
this
was.
This
was
also
me
trying
to
where
my
Flynn
had
for
a
bit
and
think
about,
and
fight
for
the
users
doesn't
work.
A
A
I
want
to
self-congratulate
myself
for
not
rambling
on
about
Pearl,
as
somebody
who
previously
did
Pearl
in
production
for
many
years.
During
that
conversation
and
actually
kind
of
kind
of
congratulate
myself
for
something
that
I
then
just
didn't
do
so.
A
Yeah,
thank
you.
Okay,
so
docs
issue,
so
Nick
you,
okay
with
just
creating
the
docs
issue.
You
have
most
of
the
contact
costumes.
Thank
you.
Yeah.
A
A
E
A
I
Yeah
I'll
try
to
keep
it
pretty
short,
but
generally
I
want
to
I
want
to
move
on
with
session
persistence.
I
was
I,
I
chatted
with
frop
a
little
bit
in
the
slack
Channel,
but
I
think
what
I'm
looking
for
here
is
really
trying
to
answer
the
the
questions
of
where
do
I
start
with
this.
So
I
think
the
big
thing
was
I'm,
not
really
totally
sure
where
session
persistence
should
go
into
the
API
and
I.
I
Think,
there's
probably
some
debate
that
needs
to
be
had
there
so
I
think
just
generically
asking
I
could
see
it
fit
in
as
a
relf
filter,
but
I
also
could
see
it
put
it
in
as
a
service
extension,
maybe
not
I'm,
not
necessarily
asking
for
the
answer.
Even
though
someone
has
the
answer,
please,
you
know
feel
free
to
tell
me,
but
also
what's
what's
what
how
do
I?
What
path
do
I
take
to
answering
those
questions?
I
Is
there
like
some
example
gaps
that
I
could
look
at
that
maybe
kind
of
outline
a
similar
scenario
or
what
have
you
Shane.
A
I'll
start
by
saying:
there's
a
bag
of
worms,
cats,
bag
of
cats.
I
appreciate
you
bringing
it
up
in
here,
though,
very
much,
because
it
can
be
it's
it's
not
so
often
that
we
remember
to
kind
of
go
and
actually
ask
the
community
hey,
I'm,
doing
an
implementation.
What
do
you
all
think
until
we
get
to
the
pr
level
so
I
like
that
you're
doing
it
ahead
of
time?
A
I
think
there's
a
lot
of
ways
that
you
could
go
about
trying
to
do
it,
including
like
organizing
I've,
done
some
things
where
I've
just
organized
with
a
few
people
who
are
interested
in
like
a
separate
zoom
and
done
some
brainstorming
as
far
as
prior
art
in
the
gaps,
I
can't
think
of
any
off
the
top
of
my
head.
Can
anybody
else
think
of
any
yeah.
C
I
mean
I
think-
and
this
has
definitely
had
some
experience
with
this
for
better
for
worse
with,
with
TLS
from
Gateway
to
back
end
I
feel
like
we
tried
to
do
that.
Every
possible
way
we
could
think
of
I
would
also
highlight
timeouts
proposal.
C
That
is
one
where
there's
you
know.
Both
were
also
considered
there
as
a
timeout
on
a
back
end
attached
to
a
service,
or
is
it
at
a
route
level?
And
what
is
in
that
Gap
PR,
that's
1997.,
it
just
has
Alternatives
considered,
so
it
proposes
one
and
then
details
the
Alternatives
that
were
considered
I'd,
say
that's
really.
The
standard
I
haven't
thought
enough
about
this.
F
Yeah
since
I've
been
working
on
this
personal
station
for
a
while
and
don't
get
it
in
in
I
think
that
the
biggest
question
is
because
there
are
two
points
of
attachment
when
it's
per
service,
it's
slightly
controversial,
because
only
if
you
implement
only
a
waiter,
you
can
do
it.
I,
I
I
think
we
we
need
to
figure
out
if
we,
if
we
want
to
do
both.
If
we
want
to
you
know
if
in
case
we
had
it
prepare
route.
F
If
we
follow
the
timeout
path,
where
we
are
the
top
level
field
and
it's
not
an
extension,
it's
a
core
feature
like
timeout,
and
if
we
want
to
go
with
backhand,
we
need
to
figure
out
what
happens
with
that
back-end
properties
attachment
whatever
it
was
called.
Is
it
moving
forward?
This
is
the
right
place
to
place
this
kind
of
off
settings.
G
So
Grant
I
think
your
PR
was
I'm.
Sorry,
your
your
Gap
listing
all
of
the
different
implementations
lists
pretty
good,
and
if
you
go
through
that
and
pick
the
variety
of
implementations,
you
know
sort
of
try
to
we'd.
G
You
know
prune
it
down
to
here's
the
four
different
manners
of
implementation
that
the
current
four
different
manners,
four
different
methods
that
the
current
implementations
are
using
to
do
this
and
the
pros
and
cons
of
each
at
least
when
people
review
The,
Gap
they'll,
have
some
idea
of
what
the
pros
and
cons
are
of
each
and
you
know
be
able
to
use
that.
As
a
talking
point,
my
advice.
I
I
D
I
was
yeah,
I
was
just
gonna
say
for
me,
one
of
the
things
that
has
worked
better
in
the
parties
when
you're
doing
that.
It'll
sort
of
you
want
to
do
a
slightly
faster
iteration
than
using
the
GitHub
PR
UI.
Sometimes
it
is
good
to
just
make
a
discussion
Google
doc.
Some
use
cases,
just
you
know,
get
something
down
on
the
page
that
and
and
maybe
Grant
added
access
to.
D
You
know
widely
so
sort
of
everyone
in
to
see
network
mailing
list
or
something
and
just
you
know
let
people
edit
it
or
you
know,
suggest
strongly
or
something
like
that,
but
just
get
a
get
a
Google
doc,
it's
much
easier
to
do
asynchronous,
faster
communication
on
a
Google
doc,
because
you
don't
need
as
many
sort
of
backwards
and
forwards
and
it's
slightly
easier
to
update
and
so
yeah.
D
If
you
want
to
just
sort
of
do
some
initial
brainstorming,
I
yeah
I
certainly
recommend
like
having
a
Google
doc,
even
if
you're
going
to
do
which
I
I
would
kind
of
recommend.
Also
saying
hey
I'm
going
to
do
a
session
where
we,
where
we
chat
through
talk
through
some
of
the
things,
and
then
you
write
the
Google
Doc
in
that
session.
That's
also
another
good
way
to
sort
of
really
speed
up
the
the
process
of
Happiness.
D
Then
you've
got
the
synchronous,
the
synchronous,
high
bandwidth,
communication
of
actually
being
in
the
call,
and
then
the
asynchronous
thing
for
people
who
are
not
on
the
right
time
zone,
who
you
know
if
you
can
catch
up
afterwards,
using
the
notes
and
sort
of
put
some
thoughts
on
the
notes.
Then,
when
you
come
to
doing
the
pr
it's
you
end
up
with
you
sort
of
cut
a
number
of
comments
that
you
end
up
with
on
your
PR
substantially
perfectly.
A
I
I
think
that's
good
for
now.
I
had
one
more
question,
but
costume
commented
in
the
chat
about
it
and
I
think
we
can
kind
of
take
that
question
to
one
of
those
discussion
forums.
F
D
There
is
one
problem:
it's
a
gap
1202,
which
was
the
generalized
backend
properties.
It
has
not
been
yet,
but
it
will
probably
be
declined
in
its
current
form,
so
backhand,
the
generalized
back-end
properties,
was
too
big
too
many
too
many
options
too
many
things
we
could
do.
We
might
come
back
to
it,
but
as
in
its
current
form,
it
will
be
declined.
F
D
Forward
yeah
so
1282
is
the
was
the
old
one,
the
sort
of
all-inclusive
one
that
I
don't
think
I
haven't
I,
don't
think,
we've
actually
moved
that
two
declines
yet,
but
but
it's
on
my
to-do
list
to
move
it
to
the
client.
Okay,.
E
E
D
A
All
right
Grant,
if
you
get
stuck
make
noise
and
slack,
please
please
don't
hesitate
to
ping
me
personally,
certainly
in
the
channel
and
whatnot.
A
E
I
think
Nathan's
have
to
go
to
a
different
meeting,
but
yeah
it
was
just
wanted
to
wanted
to
bring
up
like
well.
What
are
the
thoughts
for?
What
kind
of
filters
do
like
do?
We
need
to
do
all
the
HTTP
route,
filter,
combinations
and,
in
terms
of
conformance
like
in
terms
of
like
implementation
experience
like,
should
we
have
like
different
constants
for
like
for
like
requiring
those
conformance
combinations,
so,
like
I,
wanted
to
get
some
thoughts
from
The
Wider
Community
how
they
would
like
it.
C
Yeah
I,
it
is
a
good
question.
I
wrote
These
as
examples
of
conf
of
options
that
you
could
use
there.
So,
for
example,
the
the
core
ones
are
really
the
only
two
core
ones
that
exist
right
now
and
so
combining
them
seem
to
make
sense.
Then
combining
core
and
some
random,
extended
ones
seems
to
make
sense.
I
mean
you
could
you
could
have
every
possible
combination,
but
that
feels
you
know
unsustainable
to
try
and
keep
that
up.
C
My
personal
view
is
that,
since
every
extended
filter
would
have
its
own
feature
in
conformance
its
own
feature
gate
as
long
as
you
flip
that
feature
get
you'll
naturally
get
whatever
tests,
including
combination
tests
that
are
included
there.
So
I
think
it's
fine
I,
don't
think
we
need
any
more
feature.
Gates
I
am
open
to
different
combinations
than
what
I
suggested
an
issue
and
they
were
just
kind
of
randomly.
C
C
E
Yeah,
though,
like
do
we,
what
do
we
really
want?
Do
we
really
want
tests
for,
like,
let's
say,
I
have
two
like
two
extensions,
like
two
creature,
Gates
enabled
so
do
we
want
test
to
see
whether
they
extended
one
of
the
extended
features
is
like
working
well
with
the
other
one
or
because
we
could
end
up
with
endless
amount
of
content,
yeah.
C
That's
I
think
I
think
having
a
couple
could
be
helpful,
so
I
proposed
one
down
there,
but
I
I
think
it
yes
trying
to
have
full
coverage.
There
is
going
to
be
impossible
or
just
you
know
not
maintainable,
so
I
I
think
GPT.
D
E
I'm
not
sure
what
what
what's
a
more
buzzword
now
to
GPT
or
ebtf.
C
Yeah
I
mean
exponential
number
of
combinations,
every
new
filter
we
have
combined
with
every
filter
we
might
create
in
the
future,
the
alternative
being
we
just
pick
some,
yes,
that
that's
what
this
proposes
right
now.
It's
just
make
sure
everything
every
filter
is
combined
with
at
least
one
other
filter
in
a
conformance
test.
S.
E
To
make
it
more
maintainable
I
think
maybe
it's
worth
adding.
Let's
say
in
let's
say
if
I
support
your
right
so
in
the
URL
rewrite
filter
to
add
as
well
to
come
to
the
same
tests,
file
test
file
to
add
the
combination
with
core
and
if
we
want
to
support
like
extended
plus
extended,
have
separate
files
for
it
and
but
yeah
100.
D
Agreed
yeah,
yeah
I
think
every
every
test
for
extended
filters
should
include
them
combining
with
the
stuff
that's
in
core,
because
core
is
always
enabled,
whereas
your
extended
tested
with
other
extended
should
only
be
done
on
a
case-by-case
basis
where
they,
you
know,
are
yeah
when
they're
closely
related
or
they
might
have
some
weird
behavior
that
we
need
to
lock
in
that.
We
need
to
lock
in
the
correct
way
for
the
for
the
two
to
combine.
D
Yeah,
there's
not
an
explicit
plan
as
of
today.
However,
the
hope
is
that
over
time,
generally
features
will
work
their
way
towards
core.
So
if
everybody
supports
a
particular
extended
filter
that
what
a
filter
that
is
extended
as
of
today,
then
there
is
a
case
to
be
made
that
we
move
that
into
court
because
everybody
supports
it
and
so
making
it
all
make
sense.
D
If
that
was
the
case,
I
think
this
is
just
something
that
we'll
need
to
keep
in
mind
that
if
we
move,
if
you'll
just
support
the
core,
that
then
means
part
of
moving
filter
support.
Decor
is
going
back
and
touching
all
the
extended
filters
and
making
sure
that
now
part
of
moving
into
core
is
that
it
needs
to.
You
need
to
sort
of
interoperate
with
all
the
extended
buildings.
A
Me
I
hit
mute
because
I
thought
I
was
muted,
but
I
wasn't.
Do
you
and
Nathan
then
have
what
you
need
to
move
forward
here
like
do
you
got
enough
to
kind
of
continue
the
motion?
What
like
what
can
we
do
for
you,
yeah.
E
Nothing
like
I'm
I'm,
not
sure
like
he
lives
a
few
comments
there
that
I'm
not
aware
of
them,
but
I,
think
yeah
I'm
able
to
take
it
with
him.
A
A
D
A
All
right,
I
added
a
little
one
here
at
last
week's
sync.
We
talked
about.
A
Actually,
if
you
have,
if
you're
not
involved
in
Sigma
multicluster,
there
was
a
discussionistic
multicluster
a
few
weeks
ago
at
the
last
meeting,
that
kind
of
related
to
Gateway
API,
in
that
there
are
a
lot
of
people
in
the
Gateway
API
community.
That
I
have
become
aware
of
are
interested
in
multi-cluster,
but
are
basically
in
a
place
where
it's
like
the
interest
level
doesn't
match
up
with
any
strong
impetus
to
basically
go
forth
by
themselves.
A
So
some
of
us
in
the
Gateway
API
Community
I,
think
that
are
interested,
but
none
of
us
are
going
to
go.
Do
it
solo
there
may
be
room
in
the
multi-cluster.
Stick
is
kind
of
open
to
the
suggestion
that
if
we
had
more
people
join
Sig
multi-cluster
and
help
out
there
may
be
more
room
for
Machinery
there,
basically
to
build
that
together
in
Upstream
things
like
potentially
but
I'm,
not
don't
quote
me
like
an
implementation
of
service
import
that
was
kind
of
an
efficient
implementation.
No
generalized
one!
A
Don't
quote
me
on
that,
but,
like
stuff
like
that,
was
kind
of
something
that
we
discussed
if
you're
interested
it's
right
after
this
and
it's
every
two
weeks
just
wanted
to
kind
of
generally
invite
people
to
that
as
I
understand
a
lot
of
Gateway
API
people
are
kind
of
interested
with
that
I
think
you
wanted
to
get
to
some
specific
triage
items.
Rob
just
start
from
the
top
Yeah.
C
We
actually
have
more
time
than
I
thought
we
would
so
that's
great
I,
actually
just
added
some
that
and
this
one
in
particular
the
routability
from
Dave
feels
awfully
close
and
I
just
wanna
follow
back
up
on
that
thread.
One
huge
thank
you
for
today
for
pushing
this
one
through.
This
is
one
of
our
most
commented
gaps
ever
so
I
get
PR's
anyway.
C
So
thanks,
Dave
I
think
this
is
nearly
done,
if
not
done
the
one
that
was
blocking
it
is
the
was
the
infrastructure
gap
which
I
think
has
also
merged,
as
of
today
yeah.
So
this
is,
this
is
unblocked
and
I
think
ready
to
go.
So
really.
This
is
a
a
final.
Oh!
It's!
Oh
okay,
block
by
prow,
okay,
it
seems
like
I've,
seen
some
strange
issues
on
other
PRS
this
morning.
So,
okay.
C
So
we'll
merge
soon
whenever
we
figure
out
what's
going
on
with
unrelated
underlying
infra.
C
Yes,
yes,
it
is
okay,
so
that
that's
all
I
wanted
to
say
like
last
call
last
hour
or
so
for
comments,
and
then
I
think
this
one
merges
the
issue.
Well
any
any
comments
on
this
before
keep
on
going.
H
C
Right
then,
the
next
one
is
an
issue
that
I
don't
know
how
I
missed
this,
but
it
seems
problematic.
I,
don't
have
a
solution.
I
haven't
gotten
that
far,
but
when
I
saw
this
issue
come
in
I
just
it's
unfortunate,
but
we
have
a
default
without
a
default.
I
think
so
TLS
config
mode
is
optional,
but
then
we
say
when
it's
not
set.
We
inter
interpret
it
as
terminate.
C
D
I
think
we
might
just
have
to
update
the
documentation
to
document
what
is
actually
the
case
I.E
that
in
the
absence
of
yeah,
in
the
absence
of
a
of
a
mode,
it's
actually
it's
a
little
bit
more
subtle
than
than
what
it
says
here.
It's
actually
in
the
absence
of
a
specific
mode,
it
actually
depends
on
a
protocol.
D
You
know
the
selected
protocol,
both
via
the
protocol
field
and
the
routes
that
bind
to
The
Listener.
This
is
one
of
those
things
that
that
we
backwards
affords
on
quite
a
lot
of
times
very
early
on
and
then
sort
of
left
alone
and
yeah.
So
it's
like
four
HTTP
route.
It
defaults
to
terminate
a
TLS
route
for
TLS
protocol
it
defaults
to
pass
through
because
that's
what
makes
sense
for
the
for
the
protocol
right.
So
it's
not
quite
as
simple
as
it
defaults
to
terminate
all
the
time.
A
E
A
Had
limited
time
so
I
think
I
will
follow
up
with
both
of
you
asynchronously
on
this
one,
but
I
assigned
myself
to
continue
triaging
it
to
get
it
to
a
point
where
we
know
exactly
what
we
need
to
do.
A
C
Spare
yeah
I
just
wanted
to
highlight
this
one.
This
is
I,
think
a
pretty
important
set
of
conformance
tests
and
would
love
to
get
some
reviews
on
it.
Asap
yeah,
just
I,
think
this
could
catch
some.
Some
issues
so
I
appreciate
this.
This
getting
filed
and
with
some
heads.
D
Up
yeah
yeah,
with
a
current
set
of
conformances,
it's
possible
for
you
to
correctly
program
the
status
to
reject
to
say
this
secret
is
not
valid,
but
to
accidentally
end
up
programming
the
data
plane
with
the
secret
anyway,
because
we
don't
have
anything
in
the
conformance
tests
that
validate
that
when
these,
the
the
stls
secret,
for
example,
or
a
back
end,
has
been
rejected
that
that
it
actually
is
rejected
and
the
traffic
does
not
flow.
D
So
we
actually
need
to
have
requests
tests
that
that,
in
the
case
that
the
reference
gradient
is
rejected,
that
you
actually
don't
have
any
traffic
flow
as
well
right.
A
D
Adjust
that
the
status
is
said-
and
that's
actually
probably
a
good
thing
for
us
to
keep
in
mind
for
all
of
the
for
all
of
the
sort
of
one
where
we
are
currently
checking
our
status,
that
we
have
a
Behavior
test
as
well.
That
check
that
not
only
is
the
status
test,
the
status
correct,
but
that
the
you
know
the
behavior
is
not
happening
for
the
for
the
negative
tests.
A
Yes,
indeed,
all
right,
we
are
at
time
and
we
kind
of
got
through
everything.
So
great.
Thank
you.
Everyone
for
your
time,
we'll
see
you
again
next
week
at
the
usual
time,
and
we
will
be
looking
for
opportunities
for
maybe
a
regular
EU
friendly
in
the
future,
so
keep
a
lookout
for
that
cheers.