►
From YouTube: SIG Network Gateway API meeting for 20230109
Description
SIG Network Gateway API meeting for 20230109
A
This
meeting
is
being
recorded
hello
and
welcome
everybody
to
the
January
9th
edition
of
The
Gateway
API
Community.
Sync,
just
a
reminder
that
this
is
a
meeting
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
to
be
nice
and
respectful
to
one
another.
On
this
call,
we
don't
have
a
super
heavy
agenda
for
today,
but
we
do
have
Grant
Spence
starting
us
out
with
a
discussion
about
session
persistence.
Behavior.
Let
me
get
my
screen
shared
here.
A
Else
has
anything
to
add.
Please
do
feel
free,
there's
a
pretty
short
agenda
for
today,
so
feel
free
to
add
something
directly
to
the
Google
Doc.
A
All
right,
I
just
started
reading
this
because
I
just
got
back
from
holiday,
break
and
I
had
several
hundred
thousand
notifications,
so
I'm
not
100,
caught
up
on
it,
but
I
think
I'm
getting
the
gist
of
what
we're
doing
here.
Grant.
Do
you
want
to
go
ahead
and
start
talking
about
it.
C
Okay,
cool
yeah,
so
in
one
of
the
meetings
in
November
I
think
we
talked
about
a
couple
of
things.
One
of
them
was
session
persistence
and
the
idea
that
was
thrown
out
is
that
if
we
switch
some
implementations
from
one
implementation
to
the
other,
we
want
to
establish
some
sort
of
expectation
that
it
will
behave
in
the
same
way
or
at
least
I.
Guess
that's
what
we're
proposing
here
so
I
think
Nick
recommended
either
go
ahead
and
just
make
an
issue.
C
So
we
can
have
a
place
to
talk
about
it,
possibly
make
a
conformance
test,
but
I
think
we
can
talk
about
that
here.
In
a.
C
That
might
be
a
a
bit
of
a
contentious
thing,
but
the
goal
here
and
what
I,
what
we
wrote
up-
I
I
worked
with
Candace
and
Mikaya
a
little
bit
on
this
is
that
we
want.
We
would
like
implementations
to
specify
how
they
Implement
session
persistence
to
sort
of
establish
that
expectation.
B
D
Yeah
totally
I
mean
I.
Think
I.
Think
that
your
your
point
about
starting
off
with
defining
what
session
persistence
is,
is
a
very
good
call
that
has
been
getting
making
sure
we're.
All
speaking
the
same
language
has
historically
been
one
of
the
biggest
hurdles
for
us
to
overcome.
In
talking
about
this
sort
of
thing,
yeah
I
think.
D
Yeah
so
I
and
I
think
it's
a
very
fair
point
that
you
have
in
there
about
how
says
and
persistence
is
often
used
for,
but
is
not
necessarily
the
same
thing
as
a
session
affinity,
yeah
or
they're
often
used
in
tandem,
but
they're
not
the
same
thing.
That's
a
very
good
point:
yeah
I,
really
like
the
issue.
I
have
had
a
bit
of
a
look
over
it
I
think
in
general.
It's
a
great
it's
a
really
awesome
issue.
D
E
No
I
I
love.
This
I
want
to
clarify,
though
I
kind
of
got
two
two
perspectives
on
this
one
was
that
I
it
seemed
like
there
was
interest
in
just
documenting
what
implementations
of
Gateway
API
are
already
doing,
which
you
great
start.
Thank
you,
but
then
the
other
thing
is.
It
seems
like
there's
at
least
some
interest,
as
this
being
the
starting
point
for
an
actual
Gap,
to
provide
a
way
to
configure
this
in
the
API
itself.
Am
I
understanding
that
second
part
correctly.
C
Yeah,
that's
that's
not
the
intention
of
this
initially,
but
I
did
mention
that
that
I
think
this
is
a
great
starting
point
for
that
to
move
towards
I
think
what
you
you
meant
is
having
that
in
sort
of
like
the
official
specs,
so
you
can
set
up
or
configure
session
persistence.
Is
that
what
you
meant
not.
A
Exactly
like,
we
have
like
kubernetes
enhancement,
proposals
are
like
living
proposals
that
get
updated,
iteratively
that
aren't
necessarily
stud
and
stone
or
like
we're
not
like
all
in
on
them
until
we
say
yes,
we're
ready
to
take
this
and
start
actually
implementing
this.
It's
like
a
growing
document
or
a
declaration
of
intent
for
like
a
proposal.
Yours
is
your
thing
is
doing
exactly
that
they're
under
the.
A
If
you
look
in
the
in
the
repo
they're
all
under
site,
so
like
the
hair,
actually
were
there
they're
all
under
site
source
and
then
just
gaps
and
you'll
kind
of
see
all
the
different
proposals.
It
doesn't
have
to
be
a
completed
thing
to
be
in
here
either,
and
we
also
have
some
that
are
declined
and
so
forth.
So
there's,
probably
the
overview
I
think
will
give
you
kind
of
a
an
idea
of
what
is
going
on
in
here,
but
suffice
to
say
this.
A
It
you're
already
kind
of
like
close
to
the
format,
and
we
would
want
a
gap
for
this
eventually
anyway,
so
I
mean
I
I'd
like
to
just
kind
of
see,
it
I
think
it's
almost
ready
to
just
make
the
Gap
out
of
it,
which
is
more
or
less
just
putting
it
in
a
different
place.
At
this
point,.
D
A
D
D
We
do
need
to
document
a
what
session
persistence
is
and
what
everybody
does
precision
persistence,
but
it
does
seem
like
the
the
natural
extension
of
this
is
to
sort
of
be
like,
and
how
do
we
configure
social
persistence
in
the
in-go
API
yeah
like
we,
which
we
don't
currently
don't
have
a
way
to
do
yeah,
because,
right
now
all
the
implementations
might
support
it,
but
there's
no
there's
no
language
in
or
space
in
that
API.
For
for
you
to
actually
ask
for
it
to
be
configured.
C
Oh
yeah,
I
haven't
no
I,
wasn't
speaking
but
yeah.
That
makes
sense
to
me
like
yeah
it
at
least
defining
it.
In
the
beginning
we
get,
you
know
a
gap
can
help.
C
Do
that
I
think
one
of
the
the
goals,
I
guess
was
to
have
implementations
actually
document
somewhere
in
their
documentation,
whether
how
they
support
it,
I
I,
don't
I,
don't
really
know
if
the
precedent
on
that
I
mean,
if
you
guys
sort
of
require
implementations
to
document
somewhere
or
Candice
mentioned
below,
or
about
like
having
some
sort
of
central
repository
of
features
that
we
could
like
have
implementations
put
in
if
they
support
session
persistence
and
how
they
do
that.
F
So
yeah
this
is
Bowie.
I
have
a
question,
so
let's
say
we
can
agree
on
a
standard
for
cookie
based
session
persistence.
That
sounds
to
me
like
that
falls
completely
within
what
we're
talking
about
in
terms
of
extended
features.
Basically,
a
standardized
feature
that
might
not
actually
not
necessarily
be
implemented
by
all
things
is
that
what
I
guess
I'm
trying
to
understand
what
the
documentation
of
the
features
versus
the
existing
model
of
having
extended
features?
C
Yeah
I
think
I
think
the
difference
here
is
that
we
we
don't
have
a
way
to
configure
this
in
Gateway
API
as
it
stands
today.
So
even
before
we
have
some
sort
of
API
for
that.
The
question
is
whether
we
should
have
implementations
specify
what
their
default
session
persistence
functionality
is.
Does
that
make
sense.
A
I,
take
this
as
well
correct
me
if
I'm
wrong,
Grant
you're,
advocating
for
basically
just
having
more
people
from
different
implementations,
come
in
and
just
declare
how
this
how
they
could
or
could
not
implement
this,
and
what
that
would
look
like
before.
That's
like
a
baseline
is
that
what
you're
kind
of
advocating
for.
C
Yeah
I
think
that's
a
good
starting
point.
I
think
the
Hope
was
also
to
get
what
their
default
functionality
is
today.
So
we
have,
you
know,
maybe
it's
jumping
the
gun,
but
it'd
also
be
nice
if
they
could
tell
us
like
as
of
today,
if
we
switch
between
implementations,
what
our
expectations
would
be
for
session
persistence,
if
that
makes
sense,.
D
D
Yeah
I
don't
see
what
you're
saying
like
you
want
to
sort
of
get
an
idea
of
the
LIE
of
the
land
before
we
before
we
start
looking
to
go
too
far
into
sort
of
writing
down
how
you
can
figure,
it
I
think
the
I
think
in
the
past
we've
we
haven't
gone
too
far
down
that
road
because,
like
to
some
extent
like
as
long
as
everyone
supports
the
same
thing,
part
of
part
of
the
way
that
you
draw
out
like
the
best
way
to
draw
out
I
think
what
what
works
like
what
everyone
can
do
is
to
sort
of
start.
D
One
of
the
easiest
ways
is
actually
to
start
designing
like
how
you
describe
the
thing
and
that's
one
of
the
best
ways
that
you
can
sort
of
you
know.
I
I
think
the
table
you've
got
there
is
pretty
much
already.
If
we
could
fill
out
that
table
a
bit
more,
then
that's
pretty
much
everything
we
need.
You
know
if,
in
terms
of
that
effort,
I
think
that
there's
there's
another
question
there
that
you've
asked
that
I
see
you
Bowie
I'll,
get
you
a
sec.
That
I
think
is
another
thing.
D
D
Where
we
have
said
implementations,
you
must
I
think
we've
we've
had
I
think
we've
got
it
in
a
couple
of
places
where
it's
like
you
may
do
this
and
you've
got
a,
and
if
so,
you
need
to
tell
people
or
something
like
that,
but
I
think
we
might
have
only
done
it
once
before
for
some
for
an
extended
feature.
So
I
think
this
is
a
similar
thing
in
that
you
know
it's
like
you.
D
The
assessment
resistance
may
be
implemented,
but
like
right
now,
because
there's
no
way
to
configure
it
like
it's
like
you
know
it's
kind
of
like
there's
nothing
for
us
to
tell
people
to
do
like,
because
there's
no
language
in
the
API
to
do
it.
So
I
think
what
you
seem
to
be
saying
is
like
you'd
like
to
have
that
that
paragraph,
if
you
just
go
down
a
bit
Shane,
there's
a
italicized
paragraph
there.
That
is
what
you're
proposing
that
we
include
is
that
right
grant.
D
Yeah
so
I
mean
I
think
we
can
include
that,
but
like
right
now,
it's
not
it's
not
really
going
to
have
much
value
because
the
because
we
haven't
got
a
way
to
to
do
it
so
like
there's,
no
there's
no
way
that
you
can
do
social
assistance
at
the
moment
because
because
we
haven't
talked
about
how
how
we
would
do
it
sorry
Bowie
I
talked
too
much
over
to
you.
F
Yeah
thanks
thanks,
no
problems
all
right,
yeah
I
think
the
one
thing
is
I,
don't
know
if
most
implementations
would
have
any
sort
of
persistence
like
by
default.
So
it's
kind
of
hard
to
say
that
it
sounds
mostly
like
you're
trying
to
come
up
with
a
shape
of
something
that
could
be
standardized
is
what
I'm
hearing
this.
F
B
If
you
take
a
look
at
the
the
chart,
that
Grant
put
together
to
me,
that
that
indicates
that
that
many
implementations
have
have
thought
about
it
and
documented
it
and
there's
fewer
that
don't
offer
anything
in
terms
of
of
the
level
that
he's
looking
for.
A
F
H
I
was
the
things
we're
talking
about
how
this
is
implemented
across
various
you
know,
implementations,
but
should
should
we
also
look
at
what
are
the?
What
are
the
needs
from
session
persistence?
I
mean
things
have
moved
a
long
way
since
we've
started
doing
this
in
HTTP.
H
You
know,
there's
there's
certain
applications
that
don't
like
cookies
for
a
particular
reason.
Some
that
you
know
don't
want
things
to
be
in
the
URL
or
if
there
are,
if
we
can
get
that
information
from
these
vendors
to
qualify.
Why,
if
they
pick
this
the
the
implementation
method,
they
have.
That
might
be
more
useful
information
to
use
as
a
for
something
to
standardize
on.
F
D
G
G
I
right,
yeah,
I,
I,
I
I
noticed
that
it
was
good
to
say
it's,
then
it's
depending
on
the
route
class.
So
it's
and
then
it's
even
more
complicated,
because
then
you've
got
session
positions
for
HTTP
route
and
do
you
have
session
persistence
for
any
other
routes.
D
Yeah,
it
feels
to
me
like
session
persistence,
for
HTTP
requires
configuration
by
the
end
user.
You
need
to
be
able
to
say
the
session
persistence
should
work
using
this
prop
these
prop
this
metadata
of
the
connection
cookie
header,
that
sort
of
thing
for
for
TCP
and
UDP,
though
session
persistence,
is
kind
of
you're
only
ever
really
using
the
five
Tuple.
D
You
know
so
like
that.
That
feels
like
more
of
an
implementation
detail
that
that
could
be
defaulted
to
on
or
off
on
a
per
implementation
basis.
So
I
think
it
is
very
useful.
It's
very
useful
to
to
to
keep
that
in
mind
that
social
assistance
for
on
a
per
route
basis
will
be
different,
but
I
think
we
probably
should
clarify
that
in
this
case
we
are
talking
about
https,
HTTP
route,
search
and
persistence.
D
You
know
and
that
session
resistance
for
other
routes
will
be
dependent
on
the
type
of
Route,
so
grpc
route
will
be
able
to
use
HTTP
without
semantics,
broadly
I
would
guess,
and
then
TCP
right,
UDP
route
and
TLS
route
probably
will
only
be
able
to
use.
You
know
properties
of
the
connect,
the
other
properties
of
the
connection
aren't
so
session.
Persistence
for
those
will
be
different,
so
yeah
I
think
I.
Think
that's
a
very
good
call
out.
Thank
you
John
to
to
remind
us
that
this
is
this.
D
Api
is
not
just
HTTP,
although
a
lot
of
a
lot
of
the
use
cases
are,
and
so
we
need
to
be
careful
to
be
specific
in
our
language.
D
Do
we
need
yeah,
yeah,
I,
think
I
think
that
in
general
I
don't
think
there
are,
because,
as
long
as
we
do
it
in
the
ways
that
people
have
worked
out
already,
you
know
like
people
have
worked
out
sort
of
reasonable
approximations
for
security.
Here
you
know
like
as
long
as
you're
you
get
most
of
the
time
when
you're
configuring,
the
quicker
version
positions,
you're,
saying
session
assessments
could
be
done
using
the
value
of
this
cookie,
and
then
it's
you
know,
or
I
mean
and
sometimes
for
Envoy
based
ones.
D
Sometimes
it's
like
Envoy
will
store
the
assertion,
persistence
in
this
specific
Envoy
cookie,
and
so
you
so
you
can
ensure
that
you're
not
using
like
the
auth
cookie
for
searching
for
business
as
well
or
something
yeah
and
so
same
for
similarly
for
header
stuff.
D
So
that
you
can
configure
that
somehow
in
the
API
is
the
sort
of
Next
Step,
but
the
first
step
that
Grant
is
talking
about
in
this
issue
is:
let's
talk
about
what
you
can
configure
already
and
let's
be
clear
on
what
implementations
can
do
so
that
then,
when
we
come
when
it
comes
time
to
just
Define
how
to
how
to
the
language
that
we
use
to
be
able
to
configure
implementations
that
we
keep
in
mind
what
they
can
do
already
and
what
people
are
expecting
to
do
is
probably
the
other
thing.
That's
important!
D
That's
what
Bowie
was
talking
about
we're
talking
about
what
users
want
to
see.
Is
it's
important
to
keep
in
mind
what
you
know
what
a
user
would
expect
to
be
configuring
when
they
configure
your
session
assistance,
Candace.
B
B
Pull
requests,
I
think
that
the
chart
that
he's
using
and
Shane
I
think
you
you
brought
up
the
chart
before
for
I
mean
there's,
there's
a
chart
like
this
a
spreadsheet
of
all
features,
but
this
is
for
Ingress
controllers
and
funny
enough.
There's
a
Gateway
API
line
on
the
left.
B
If
you
it's
a
little
bit
out
of
date,
but
if
we
had
something
like
this
for
implementations,
it
would
be
really
really
useful.
I
think
yeah.
F
D
I
100
agree
that
having
a
table
like
this
somewhere
would
be
really
useful.
I
think
that
a
manually,
updated
table
like
this
one
is
is
sub-optimal
in
that
it
requires
there's
a
lot
of
manual
update
I
think
that
the
the
best
way
that
I
can
think
of
to
do
this
is
to
have
it
be
that,
oh,
that
there's
some
way
that
you
that
you
or
me
as
being
implementation
owners
can
PR
something
into
the
gateway,
API
repo.
That
will
then
generate
a
table
like
that.
D
That
would
be
my
my
sort
of,
and
ideally
eventually
that
one
would
hope
that
that
would
be
tied
into
the
conformance
testing,
and
so
you
know
you
idea
and
I
think
the
ideal
dream
state
for
this
is
that
when
you
run
the
conformance
tests
enabling
certain
extended
features
that
produces
a
conformance
test
output
of
some
sort,
you
upload
the
conformance
test
output
of
some
sort
to
a
specific
place
in
the
repo,
and
then
that
generates
you,
then
that
generates
that
those
specific
results
all
end
up,
generating
a
feature.
Comparison
like
this.
D
So
basically,
you
get
a
conformance
test
level
feature
comparison
of
how
of
what
works.
That's
the
dream,
we're
a
long
way
from
that,
but
like
in
my
mind,
that
is
the
dream.
Sorry,
so
Candace
I'll
leave
you
your
hand
up
to
respond.
Sorry,
oh.
B
No,
that
was
you're
responding
to
what
I
have
my
hand
up
for
and
I
think
that's
the
great
idea.
Oh
beautiful.
E
Yeah
and
I
I'll,
just
I'll,
just
follow
up,
then
that
is
absolutely
something
we've
been
thinking
about
for
a
long
time
and
I
I
hope
we're
not
that
far
away.
E
You
know
one
of
the
things
that
we've
we've
been
talking
about
is,
if
controllers
can
publish
that
the
Gateway
class
status
specifically
and
then
controller,
and
then
our
conformance
test
read
from
that
right
now
we
have
in
conformance
test
this
concept
of
supported,
features,
basically
feature
Gates,
I'd
love
to
get
rid
of
those
entirely
and
replace
them
with
things
that
were
published
on
Gateway
class
itself,
I'm
hoping
that's
not
that
huge
of
a
transition
to
make
we,
when
we
discussed
broader
themes
with
other
Sig
Network
reviewers
for
060
release.
E
This
is
something
that
came
up
in
that
discussion.
There
was
some
hesitancy
of
doing
something
that
was
just
for
Gateway
API,
because
apparently
this
is
a
problem
that
there's
broad
interest
in
solving
kubernetes
wide,
instead
of
just
for
Gateway
API.
So
if
anything,
we
may
get
a
little
slowed
down
by
trying
to
to
solve
this
more
broadly,
but
if
we
can
solve
it,
just
forgive
API
I
think
it
is
fairly
straightforward.
Hopefully
straightforward
I'd
love
to
make
that
a
priority.
D
F
Yeah
I
just
want
to
caution
that
we
should
probably
restrict
the
actual
stuff
to
things
and
extended,
because
one
of
the
reasons
that
spreadsheet
exists
is
that
the
Ingress
API
basically
didn't
describe
it
described
like
almost
nothing
and
all
the
functionality
was
sort
of
on
the
side.
I
think
if
that
becomes
the
case
for
Gateway
API,
we
kind
of
have
failed
in
some
ways.
So
that's
that's.
D
I
agree
that
a
summary
sheet
like
that
one
should
really
only
reflect
the
things
that
could
possibly
be
different
rather
than
the
things
that
must
be
the
same.
So
it
is,
however,
useful
to
note
that
implementations
do
not
have
to
sort
of
support
all
of
the
different
route
types,
so
it
would
certainly
be
useful
to
mark
down.
You
know:
does
the
implementation
support
you
know
HTTP
route?
D
Does
the
implementation,
support,
grpc,
TLS
route,
TCP
out,
udpure
out
and
then
and
then
have
extended
features
based
on
the
the
route
types
that
feels
like
the
right
way
to
structure
that
information
to
me
so,
but
yeah
I,
I,
100,
agree
Bowie
that
there's
no
point
having
you
know,
supports
yeah
supported
weighted
load
dancing
when
that's
caught
like
you
in
order
to
support
the.
D
Value
in
listing
all
of
those
things
separately,
maybe
I
mean
it
could
be
that
it's
useful
for
people
who
don't
understand
anything
about
the
API
to
have
all
the
core
features
listed.
I,
don't
know
so.
I
100
agree
also.
Sorry
last
thing
that
that
yeah
effectively
in
Ingress
almost
every
single
feature
was
implementation
specific
because
there
was
no
performance.
So
the
the
idea
here
for
Gateway
apis
that
we
have
extended
for
a
reason.
You
know
we
have
core
and
extended
for
a
reason.
D
A
D
A
H
A
Okay,
okay,
I
think
I
think
it
was
me.
I
was
gonna,
say
since
we're
at
30
minutes,
not
that
we
have
a
huge
agenda.
Maybe
we
should
start
thinking
about
the
action
items
that
we
want
to
take
here
to
me,
it
seems
that
we
have
two
potential
actions
that
we've
kind
of
discussed
so
far.
One
of
them
is
working
this
issue
into
a
gap
that
way
it
can
be
kind
of
put
in
the
repo
potentially
as
provisional
and
then
have
other
people
who
are
interested
iterate
on
it.
A
Until
we
get
it
to
a
point
where
we
can
agree
that
it's
something
that
we
can
put
into
experimental
and
then
the
other
thing
would
seem
to
be
that
we
need
to
at
least
make
an
issue
for
Candace's
spreadsheet,
with
some
of
the
caveats
that
we
just
discussed
those
things
like
those
seem
like
the
two
action
items.
D
Yeah
I
think
the
the
last
thing
was.
Do
we
want
to
put
that
the
italicized
paragraph
that
Grant
is
included
in
there?
Do
we
want
to
action,
putting
that
somewhere
in
somewhere
in
the
spec
yeah?
It's
probably
okay.
To
do
that
right
away
to
sort
of
say
you
know,
social
persistence
is
intended
to
be
included
in
the
API,
but
we're
working
on
it
to
see
this
Gap
or
something
like
that.
E
I,
don't
know
I'm
a
bit
hesitant
to
to
do
that
for
every
Gap
in
progress,
because
you
know
it
could
become
unmaintainable
if
I'm
understanding
the
request
correctly
to
to
add
it
to
the
to
the
spec,
correct,
directly,
I.
Think
I
would
rather,
you
know,
just
encourage
people
to
to
watch
our
gaps
for
things
coming
up,
as
opposed
to
putting
anything
that
could
potentially
come
in
our
spec
itself.
E
We,
you
know,
we
we've
we've
seen
with
gaps
that
most
of
them
make
it
through,
but
sometimes
we,
despite
our
best
efforts,
gaps,
end
up
not
working,
because
you
know
they're
not
as
broadly
implementable
as
we
thought
they
could
be,
or
you
know
whatever
and
I
don't
want
to
over
promise
anything
in
the
spec
itself.
A
Yeah
I
hesitate
to
add
that
one
myself
I
think
that
starting
to
say,
hey,
you
need
to
have
this
documented
to
be
compliant.
A
May
might
have
some
Merit
in
time,
but
trying
to
do
that
right
now,
with
one
specific
thing
feels
like
it's
just
gonna
end
up,
it
could
end
up
just
kind
of
going
under
the
rug
a
little
bit.
I
don't
know
in
the
past
we've-
and
this
is
mostly
I
guess
for
Grants
benefit
in
the
past.
We've
had
more
of
a
they
need
to
come
here
and
talk
to
us
kind
of
approach
which
has
been
successful.
A
So
I
think
you
want
to
kind
of
like
push
things
out,
but
we
usually
pull
people
in
and
get
the
people
who
are
the
most.
You
know
the
people
who
care
after
several
months
of
us
saying
hey,
we
have
a
thing
we're
trying
to
do
and
we
talk
to
people
and
we
kind
of
get
the
word
out
that
usually
works
out.
I
can't
think
of
any
really
bad
Fallout.
We've
ever
had
from
an
API
where,
like
somebody
later
comes
along
now,
knock
on
wood.
A
You
know
and
says:
hey
you
missed
me
and
now
I
absolutely
can't
Implement
that
what
do
you
think
Grant?
Are
you,
okay,
with
us
kind
of
what
are
your
feelings
or
thoughts
on
not
pushing
for
like
the
the
push
out
to
everybody?
Please
document
your
your
stuff,
but
rather
just
doing
this
with
a
gap
and
having
people
pulling
starting
to
pull
in
people
from
the
community.
C
Foreign
yeah
I
mean
I
think
that
makes
sense.
We
could
probably
continue
some
of
this
conversation
in
in
the
Gap
itself.
I
guess
as
well,
but
yeah
I
think
I
yield
to
your
your
judgment
about
the
precedent
of
you
know,
requiring
documentation
from
implementations.
D
So
yeah
in
terms
of
in
terms
of
the
next
steps,
I
would
say:
Grant.
Would
you
please
be
able
to
just
literally
take
the
markdown
that
you
have
there
and
drop
it
into
you?
Have
a
look
at
the
there
is
a
template
in
our
Gap
696
I.
Think
you
you
pretty
much
matched
the
template
already.
D
Would
you
mind
being
the
one
to
sort
of
pull
that
into
a
PR
and
and
get
this
Gap
in
as
sort
of
a
provisional,
slash,
introduction
I
can't
remember
what
this?
If
it's
is
it
just
provisional
or
the
yeah.
D
D
Yeah
awesome,
great
and
then,
and
then
I
mean
you
could
probably
just
change
change
the
title
of
that
issue
to
be
you
know,
yep,
you
know
session
persistence,
Behavior
or
something
like
that
and
then
make
it
yeah
and
then
sort
of
note
down
that
we've
created
created
this,
and
so
this
will
become
get
6.
16
19.
A
And
then
the
issue
or,
if
you're,
feeling
really
froggy
the
pr
for
or
what?
What
have
you,
if
we're,
adding
the
spreadsheet,
does
anybody
want
to
go
ahead
and
like
create
that
issue?
I
I
would
also
recommend
somebody
who's
feeling
really
strongly
about
me.
D
E
D
So
I
don't
know,
I
think
that
we
should
not
try
to
maintain
a
feature.
Spreadsheet
I
think
that
we
should
the
we
should
absolutely
have
an
issue
that
sort
of
documents
what
we
talked
about
with
the
the
the
eventual
vision
of
the
conformance
tests
rolling
into
a
summary
table
of
features
that
implementation
support,
that's
the
sort
of
the
dream,
and
then
we
can
have
you
know
we
can
have
steps
along
the
way
towards
that
dream.
D
But
the
you
know
it's
it'd
be
good,
that
that
then
becomes
a
good
epic
for
sort
of
tracking.
You
know
some
a
lot
of
the
efforts
around
performance,
because,
in
order
for
us
to
have
that
summary
table,
we
need
there's
a
bunch
of
stuff
we
need
to
have
working
like
you
know.
D
We
need
to
have
conformance
tests
and
output
things
in
a
standard
way,
and
you
know
status
in
the
Gateway
class,
and
you
know
and
ways
to
you
know
ways
for
people
to
submit
a
report
that
then
gets
that
then
gets
you
integrated
in
some
way
into
the
table.
D
Let's,
let's
do
that
one
and
then
leave
the
action
item
with
me,
because
I
think
I
have
a
pretty
clear
idea
of
what
we
need
to
do.
A
Awesome
all
right,
we
had
a
pretty
good
long
conversation
about
this.
It
seems
pretty
neat,
be
interesting
to
see
where
it
goes.
Thank
you
for
bringing
it
up
Grant
and
thank
you
for
all
the
effort
you
put
into
that
very
nice
document.
I
do
think
it's
probably
just
gonna
pretty
much
like
Lego
into
a
gap
which
should
be
cool.
A
We
got
a
couple
of
action
items,
so
we
should
be
able
to
move
forward
from
here.
Does
anybody
have
anything
else
to
say
on
this
topic,
or
can
we
move
on.
A
E
Yeah
this
is,
this
is
a
fun
one.
Ivan
asked
this
in
slack:
better
go
and
yeah
I
responded
there,
but
it
is
one
that
is
something
I.
Don't
think
many
of
us
have
thought
much
about
and
we
missed
some
things
that
would
have
made
this
easier
to
deal
with.
E
But
basically,
if
you,
if
you
take
a
route-
and
you
immediately
attach
it
to
two
gateways,
you
run
into
a
potential
race
condition
where
both
controllers
are
trying
to
update
status
at
the
same
time,
which
is
not
going
to
be
pretty
I
spent
some
while
a
while
chatting
with
Antoine
about
this.
You
can
see
I
copied
him
on
this
issue,
because
he
he
is
great
at
API,
Machinery
things
and
helps
me
understand
things
that
I
don't
understand,
apparently
a
couple
takeaways
from
this
first
off.
E
If
and
and
this
may
be
something
that
others
already
understand,
but
first
off,
if
you,
if
this
were
to
happen
and
both
controllers
were
calling
update
status,
which
is
what
I
would
expect
to
happen,
the
first
controller
is
going
to
win
and
the
because
both
updates
are
going
to
have
resource
version
in
them.
The
next
controller
is
going
to
fail
and
have
to
retry
and
fetch
again
and
try
and
update
again
so
hopefully,
controllers
have
that
retry
logic
already.
E
If,
on
the
other
hand,
we
had
done
this
properly
from
the
outset
and
added
a
list
type
with
a
map
key,
we
could
have
avoided
any
kind
of
conflicts
here
and
consecutive
updates
could
work
without
a
retry
to
do
that,
we
would
actually,
unfortunately,
need
to
retroactively.
E
E
Every
controller
is
not
going
to
catch
in
their
own
ewe
test
because
they're
just
testing
with
their
own
implementation,
but
it
is
a
pretty
annoying
Edge
case
that
I
could
imagine,
could
get
controller
stuck
indefinitely
if
they're
not
handled
unless
appropriately.
A
A
Because
because
my
first
inclination,
when
I
didn't
read
this
earlier,
because
this
is
only
a
couple
hours
old,
but
my
first
inclination
when
I
started
thinking
about
this
was
like
most
updates
are,
are
checked
for
errors
and
if
it's
a
conflict,
you
you
go
back
and
just
do
the
reconciliation
over
again
right.
So
naturally,
I
would
expect
this
to
be
accounted
for.
E
You
would
you
would
think
so.
Yes,
you
can
also
Imagine
the
case.
You
know
we
are
doing
things
right
now,
where
we
are
now
requiring
observed
generation
to
be
bumped
so
for
controllers
that
weren't
incrementing
that
before,
if
they
move
to
that
now,
it's
just
going
to
increase
the
chance
that
these
conflicts
happen.
E
I
I
agree
that
everyone
should
be
checking
for
that
I.
My
own
personal
take
is
there's,
probably
some
that
aren't
I
I,
don't
know
of
any
but
I'm
assuming
they
exist.
E
The
my
other,
my
other
concern
here
is
that
we
do
have
a
way
to
make
this
mostly
go
away
just
by
adding
an
API
field
to
status
and
I.
Think
that
is
probably
well.
E
F
D
So
yeah,
so
you
will
still
clobber,
but
the
the
other
thing
that
you
can
keep
in
mind
is
if
you're,
using
the
reconcile
pattern
that
controller
runtime
does
then
that
up.
So
the
fact
that
you
lost
the
race
will
mean
that
your
update,
you
you,
the
trick
is
that
you
need
to
be.
You
need
to
be
careful
about
when
you're
do
applying
status.
D
Updates
that
you
actually
like
check
the
status
you
have
and
make
sure
that
your
that
any
status
you
don't
know
about
you
use
you
reapply
and
then,
if
you
do
that,
then
the
status,
then
the
status
it'll
work
itself
out,
but
the
that's
the
tricky
part
is
that
if
so,
that
the
the
thing
that
will
happen
here
is
that
one
of
them
will
clobber
the
other.
D
If
you
do
that,
then
then,
then
there
will
be
a
a
period
where
the
status
sort
of
flip-flops
a
little
bit,
but
then
it'll
be
it'll
work
out,
okay
on
a
human
time
scale
the
it's
unfortunate,
but
like
that's
that's
what
happens
with
this
rice
condition
like
the
as
long
as
you're
checking
correctly,
then
then
everything
will
be
okay.
As
long
as
you're
checking
correctly
is
the
Opera
operative
word
there.
D
It
can
be
tricky
to
make
sure
that
you're
doing
this
correctly,
the
possibly
we
could
put
in
some
implantation
guidance
for
people
to
say
it's
really
important
that
when
you
write
your
status
that
you
that
you
take
that
you
take
whatever
status,
is
there
and
add
your
bit
over
the
top?
You
don't
that
you
don't
just
blind
copy
in
the
parent
refs
like
the
the
status
that
that
list
you
need
to
take
at
the
list
and
and
sort
of
merge
your
changes
into
it
properly.
D
That's
probably
the
main
thing.
If
you
do
that,
then
then
this
will,
then
this
problem
will
become
a
non-problem
because
it'll
result
itself.
A
A
A
E
Yeah
yeah,
you
are
right,
I
mean
this.
Is
this
is
a
common
enough
kubernetes
issue.
It's
just
I
feel
like
we
are.
There
are
some
unique
bits
of
our
API
one.
We
are
implemented
by
a
lot
of
different
controllers.
In
some
cases.
I
would
imagine
it's
the
first
time.
People
are
writing
kubernetes
controllers
and
then
second,
this.
This
API
really
really
encourages
multiple
controllers
to
write
status
to
the
same
resource,
which
is
not
something
that's
seen
in
many
other
kubernetes
apis.
E
D
Know
so
we
could.
We
could
I
think
the
chain
has
a
good
point,
that
if
you
have
an
implementation
like
Blix,
that
there's
like
a
relatively
neutral
reference
implementation
that
you
can
that
you
could
use
to
be
the
other
implementation.
In
this
case,
then
you
know,
then
you
can
do
a
status
thing
where
there
are
two
separate
implementations
and
they
coordinate
correctly
and
that
you
end
up
with
the
correct
result.
That,
in
my
mind,
is
a
conformance
test
for
this.
D
You
know
like
that,
after
a
certain
amount
of
time,
the
status
is
correct,
but
yeah
like
and
then
then
McCoy
asked
that
question.
Can
you
have
a
conformance
test
of
verified
like
I?
Think
you
can,
but
you
it'll
require
either
that
your
implementation
supports
running
two
instances
which
is
not
ideal
or
we
have
some
standard
implementation.
That
knows
how
to
do
enough,
that
it
can
that
it
can
interact
with
the
status.
D
You
know
if
you
interact
with
the
status
on
the
gateways,
for
example,
then
that
then
that
is
probably
all
we
need
to
test
that
this
is
working
because
most
people
are
going
to
reuse
similar
code
for
the
things
and
I
mean
I.
Think
that's
the
the
key
part
here
is
that
we
need
some
implementation
guidance
to
be
like
you
need
to
handle
the
following
cases
in
your
code:
we're
working
on
some
performance
tests
to
help
you
with
that,
but
but
like
this
is
the
implementation
guidance.
E
A
A
Status,
so
I
can
only
imagine
other
implementations
might
have
run
afoul
of
it.
So
all
right,
so
that
sounds
like
got
a
couple
things.
What
were
those
so
one
of
them
was
updating
the
developer
guide.
B
G
A
E
Okay,
yeah
feel
free
to
sign
it
to
me
for
now,
but
anyone
on
the
call,
if
you're
interested
just
don't
hesitate
to
Ping
any
one
of
us
and
I
hide
not
tied
to
doing
this.
One.
E
Yeah,
okay,
so
I
I
can
give
a
quick
intro
on
this
one.
We
have
attached
routes
in
gap,
Gateway
status
for
every
listener,
and
we
say
that
it
it
needs
to
represent
the
number
of
routes
that
have
been
successfully
attached
to
the
listener.
But
nowhere
do
we
Define
what
successfully
attached
means
and
what
is
especially
unclear
is
what,
if
the
route
is
partially
valid,
what
if
the
listener
is
partially
valid?
E
What
if
there's
a
lot
of
edge
cases
that
just
are
not
defined
and
somebody
I
forget
who
it
was,
but
somebody
started
writing
conformance
tests
for
attached
routes.
Thank
you
and
they
they
had
a
value
that
I
didn't
expect
to
be
the
value,
and
that
got
me
thinking.
Well,
we
just
didn't
Define
what
this
is
I
think
there's
at
least
two
options
for
how
we
could
interpret
this.
One
of
them
is
that
we
say:
hey
attached.
Routes
can
only
represent
routes
that
have
actually
been
programmed
by
the
Gateway.
E
This
is
a
very
literal
meaning
of
just
if
you've
programmed
this
route.
It's
attached.
If
you
haven't
it's,
not
the
other.
One
is
just
I:
don't
care
about
the
status
I?
Don't
care
if
it's
been
yeah
I,
don't
care
about
anything.
I
just
know
that
at
some
you
know
this
route
has
attempted
to
attach
to
me
and
there's
nothing
in
the
listener
configuration
that
would
prevent
it
from
being
attached.
E
What
the
second
one
is,
the
much
much
simpler
one
to
implement
it's,
it's
just
a
check
it
doesn't.
It
doesn't
depend
on
the
ability
of
The,
Listener
or
the
route.
It
is
really
just
some
math
at
that
point,
the
first
one
seems
like
it
might
be
slightly
ever
so
slightly
closer
to
what
a
user
might
expect.
A
Yeah,
the
first
one
is
well.
What
this
is
saying
is
one
means
that
attack
when
your
route
is
attached.
It's
actually
attached
to
your
Gateway
in
the
in
the
underlying
sense.
The
second
one
means
your
controller
knows
about
it.
Yeah
and
I.
Don't
know
if
I
actually,
like
your
controller,
knows
about
it,
is
the
definition
of
attached.
So.
D
I
think
I,
don't
know
this
is
actually
a
hold
of
from
the
old
condition
design.
So
in
the
old
condition,
design
attached
was
the
condition
name,
and
so
really
this
thing
should
be
called
accepted
routes
not
attached
rails,
because
that
is
the
condition
name
that
it's
talking
about
so
I.
D
Think
if
you
think
about
it
that,
like
that,
like
the
the
reason,
the
idea
here
was
originally
to
give
you
some
idea
of
like
how
many
routes
have
been
like
have
linked
up
correctly
without
us
needing
to
maintain
like
a
list
of
the
routes
that
have
that
have
been
linked
up,
because
that
is
a
fan
out.
That
is
a
status
fan
out
design
disaster
waiting
to
happen,
so
I
think.
D
The
idea
here
is,
in
my
mind,
is
closer
to
the
second
one,
where
it's
about
the
whether
or
not
the
route
is
attached
is
about
whether
or
not
the
configuration
of
the
attachment
of
the
the
you
know
the
link
between
the
listener
and
the
route
is
successful,
not
about
whether
or
not
the
route
is
available
for
for
routing
right.
This
is
about.
This
is
a
configuration
level
thing
that
tells
you
whether
you
know
is
there.
D
Have
you
have
you
you
know,
is
the
route
able
to
to
sort
of
attach
to
the
listener
to
to
be
accepted
in
list?
That
is
a
better
way
to
say
this
again,
the
terminology
is
confusing,
because
it's
using
the
old
name
for
that
for
that
relationship,
we
currently
call
it
accepted
not
attached.
E
E
Do
we
provide
any
guidance
on
the
accepted
condition
if
a
route
should
be
accepted
if
the
listener
itself
is
not
valid?
So
so,
where
this
came
up
is
there
was
a
conformance
test
where
the
TLs
certificate
ref
on
The
Listener
was
not
valid,
but
the
accepted
the
attached
routes.
Value
was
one,
but
you
know
the
route
had
every
reason
to
be
attached.
The
Listener
itself
was
not
valid
and
I
wasn't
sure
how
to
interpret
that
and
I.
Don't
know
if
we
have
guidance
for
accepted
either
right
in
what
that
means.
D
Yeah
I
can't
remember
if
we
have
guidance
for
accepted
or
not.
That
would
be
something
to
check,
but
I
think
in
my
mind,
what
we
should
aim
for
regardless
is
that
yeah
the
attached
rails
means
accepted
routes
means
they
are
the
the
route
binding
will
succeed.
D
You
know
configuration
wise
not
that
the
route
is
ready
or
available,
which
I
think
so
that
that
means
that,
in
my
mind,
that
means
that
the
the
status
of
the
listener
should
be
relatively
orthogonal.
It's
about
you
know,
it's
not
is
the
listener
completely
configured.
It's
is
the
attachment
between
the
route
and
the
listener
all
good
to
go,
and
so
that
I
mean
the
the
thing
I
think
place.
D
I
think
where
this
is
going
to
be
most
useful
is
if
you
have
an
allowed
routes
on
a
Gateway
that
is
like
allow
routes
from
anywhere
or
something
like
that,
and
so,
as
the
you
as
the
Gateway
owner,
you
might
want
to
be
like
well
how
many
routes
are
actually
using.
This
you
know,
are
actually
using
those,
and
it's
not
you
know,
like
you
know,
if
there's
20
routes
using
this
list
now,
maybe
don't
change
the
config
of
The
Listener
in
a
way
that
could
break
it.
D
You
know,
whereas,
if
there's
zero
routes
using
this
listener,
then
yeah,
zero
and
and
by
using
that
means
able
to
attach
not
not
like
configured
and
working
so
I.
Think
if
again,
if
we
go
back
to
like
why
you
have
this,
it's
for
the
person
who
owns
the
gateway
to
be
able
to
be
like
how
many,
how
many
of
these
things
like
are
actually
like.
D
How
many
relationships
are
there
or
how
many
relationships
can
there
be,
and
so
it's
a
this
is
actually
like
yeah
again,
it's
like
what's
the
number
of
routes
that
can
attach
like
not
yeah,
and
so
what
are
the
number
of
routes
that
are
configured
to
attach?
Not
what
are
the
number
of
routes
that
successfully
have
config
running?
That
would
be,
you
know,
ready
routes
or
something
like
that
or
programmed
routes
is
the
new
name
yeah.
E
Yeah
I
think
that's
entirely
Fair.
That
is
I,
think
also
one
of
the
simplest
possible
ways
to
implement
this,
and
it
does
feel
pretty
simple
to
explain
in
when
you're
writing
the
spec
too.
So
I.
D
I,
like
that,
I
guess,
should
the
should
ask
the
question,
given
that
we've
changed
the
names
of
all
of
these
things,
should
we
do
a
deprecation
cycle
on
this
on
on
attached
routes
as
the
name
and
say
and
do
the
thing
where
we
say:
okay,
the
the
name.
The
field
attachments
is
deprecated,
we're
going
to
add
an
accepted
routes
which
then
matches
up
better
with
the
with
condition
name,
and
we
do
a
you
and
then
we
then
we
sort
of
say
you
need
to
populate
both
of
these.
D
You
know
we'll
test
the
accepted
routes
not
attach
routes,
but
you
should
populate
it
for
now
and
then
eventually
we
throw
that
yeah.
We
drop
that
out
of
the
API.
E
I
think
a
field
is
really
hard
to
drop
at
this
level.
Yeah
I
know
I,
feel
I
feel
like
we're,
probably
stuck
with
the
field
as
it
is.
E
E
A
Okay,
so
we
are
running
really
close
to
out
of
time.
We
should
probably
make
a
decision
on
what
kind
of,
if
any
action
item
we
want
to
take
on
this
one,
because
there
was
kind
of
the
question
of
what
we
were
trying
to
do
here.
It
sounds
like
number.
Two
is
preferred.
I
think
I
can
agree
with
that.
B
D
Here
I'll
put
I'll
put
what
I
just
said
in
the
issue
right
now.
Thank
you.
A
Okay-
and
that's
that's
our
action
item-
for
that,
we
only
have
a
couple
minutes.
I
did
want
to
actually
go
back
real,
quick.
A
We
need
to
put
we
need
to
start
putting
priorities
on
these.
We've
just
recently
said
that
we're
going
to
start
doing
that.
Do
we
agree
that
this
one
is
wait,
did
I
not
put
parodies
in
there?
I
did
this
recently.
This
one
is
important
long
term
the
race
condition
and
route.
E
A
A
Mean
we
could
potentially
still
do
more
than
just
documentation
for
it,
and
then
this
one
we
just
talked
about
this
one
is
like
probably
important
short
term
right,
yeah
I.
A
Soon,
that's
what
we
called
it
all
right,
cool,
so
I
just
wanted
to
get
that
done
with
two
minutes
left
can.
A
We're
yeah:
let's
do
that!
We'll
come
back
to
TLS
route
conformance
next
time
next
week,
I'm
I
could
be
here.
I
probably
won't
have
the
day
off.
So
it.
D
Is
not
a
public
holiday
for
me,
so
I
am
happy
to
run
a
agenda
light
meeting
again,
if
that's,
what
who
want
to
do
for
people
who
are
not
in
the
US
and
thus
are
not
celebrating
the
amazing
Legacy
of
MLK.
E
I
think
we
might
as
well
leave
it
on
the
calendar.
I
know
there's
plenty
of
people
that
still
end
up
working
on
that
day
and
our
past
agenda.
Light
meetings
have
been
great,
so
thank
you,
Nick
for
for
leading
many
of
those
yeah
I'm
good
to
leave
that,
but
I
probably
won't
be
there
either.
A
Much
that,
and
with
that
and
37
seconds
left
I
think
we
should
call
it
a
day.
Thank
you,
everyone
for
coming,
that
we
will
be
available
next
week,
but
it
will
be
a
if
you
didn't
catch
what
we
were
saying
there,
it's
kind
of
like
a
but
just
we're,
not
writing
down
the
agenda.
We'll
just
come
in
and
do
kind
of
like
a
just
talking
like
a
forum
kind
of
thing
where
you
can
kind
of
just
bring
whatever
comes
to
mind,
otherwise,
we'll
be
back
to
normal
the
week
after
that.