►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220418
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220418
A
All
right
we're
recording
it
is
april.
19..
We've
got
lots
on
well
april,
18
or
19,
depending
on
your
time
zone.
We've
got
lots
going
on
today
for
consistency,
actually
I'll
changes
to
18,
but
I
recognize
that
plenty
of
people
are
joining
this
from
april,
19.,
anyways,
happy
happy
monday
or
tuesday,
depending
on
where
you
are.
As
always.
There
are,
I
think,
one
or
two
names
I
don't
recognize
here
so,
if
so
welcome
to
gateway
api
meeting.
A
If
you
have
any
questions,
if
you're
new
to
this,
this
is
just
like
any
other
kubernetes
style
meeting
the
agenda
is
wide
open.
You
can
ask
any
question
anytime
or
add
something
to
the
agenda
drop,
something
in
chat,
whatever
works
for
you.
We
are
always
happy
for
more
content
and
discussion,
but
with
that
mike,
I
think
you
had
first
thank
you
mike
because
you
added
some
awesome
content
related
to
status.
B
Sure
so
yeah.
I
think
that
this
is
linked
from
the
link
says
bubble
up,
or
maybe
it's
not
yeah
in
case
I
can
add
a
link
to
the
docs
or
to
the
issue,
but
yeah
there
when
I
was
working
through
the
reference
policy
implementation,
I
kind
of
discovered
a
handful
of
rough
edges
around
status.
B
Yeah
number
one,
one,
one,
two,
it's
a
link
there
and
tried
to
capture
all
of
these
rough
edges,
or
as
many
as
I
could
in
an
issue.
So
hopefully
we
can
get
some
discussion
going
in
terms
of
expectations
across
different
implementations,
around
reasons
that
are
not
currently
specified
that
seem
like
they
should
exist
or
kind
of
gaps
where
it's
under
specified
in
terms
of
what
the
expected
behavior
is
so
yeah.
B
This
is
the
issue
thanks
for
getting
that
open
and
then
yeah,
the
the
other
half
is
just
kind
of
that
would
love
final
set
of
eyes
on
the
reference
policy
conformance
tests
that
I've
been
working
on.
I
think
those
are
in
a
state
where
they
at
least
implement
a
like
minimum,
understood
and
agreed
upon
set
of
checks
for
checking
the
ref,
not
permitted
state
on
the
route
conditions
and
then
there's
a
few
to
do's
left
in
there
for
parts
that
are
underspecified
and
need
more
discussion.
B
But
I
hope
that
we
could
merge
without
blocking
on
solving
all
of
those.
Now.
A
That's
a
lot:
let's
start,
let's
go
back
and
start
with
reference
policy.
I
know
I
have
a
pr
sorry,
a
review
in
progress
on
this
one.
I
I
have,
I
think,
two
nits
so
far.
I
will
probably
find
something
else
maybe,
but
I
think
this
is
really
close.
I
agree
with
your
your
sentiment
that
this
is
basically
good
enough
to
get
in
and
a
huge
improvement
and
a
huge
addition
to
our
conformance
test
suite
so
yeah
thanks
thanks
for
getting
this
in.
A
If
not
I'll
I'll,
try
and
get
that
review
finished
today,
but
thanks
again
for
all
the
work
on
this
one,
this
is
a
a
massive
pr.
B
So
I
feel
like
a
scope
grouped
a
little,
but
it
kind
of
lays
some
of
the
foundation
for
things
that
we'll
need,
like
opt-in
and
opt-out
flags
for
future
performance
test
stuff.
So
kind
of
excited
about
that.
A
Yeah
and
if
I'm
remembering
correctly,
this
is
blocked
on
a
smaller
pr.
Now
you
so
you
added
another
pr.
A
All
right,
that's
good!
Actually,
so
I
I
started
reviewing
your
reference
policy
pr.
I
saw
a
condition
change.
Well,
you
know.
Let's
say
it
would
be
nice
if
you
pull
these
out
to
another
pr.
I
understand
why
you
did
and
then
I
saw
oh
there's
another
pr
for
this.
So
thank
you.
You.
You
were
a
few
steps
ahead.
I
think
I
did.
I.
C
A
A
My
my
only
suggestions
here
were
that
I
don't
think
we
need
to
keep
these
in
for
backwards
compat
and
I
yeah
some
reorganization,
but
that's
it
and
I
forgot
to
make
this
okay
to
test.
So
sorry,
awesome.
A
A
Yes,
so
there's
a
lot
going
on
in
this
issue
and
we
kind
of
just
briefly
highlighted
it,
but
there
or
no,
maybe
I'm
confusing
this
with
one
of
your
other
issues
where
you
basically
made
yes,
this
is
the
one
this
is
you're,
basically
describing
a
set
of
eight
or
so
changes
that
you'd
like
to
happen
to
status
right.
A
So
this
this
seems
significant
and
I'd
like.
Maybe
you
can
summarize
I.
I
think
this
is
a
good
summary,
but
what
I
guess
yeah
you
would
like
to
do
next,
with
this.
B
So
this
is
stuff
that
I
feel
like.
I
would
like
to
see
some
sort
of
consensus
around,
like
consistency,
consist
to
find
some
of
these
terms
kind
of
like
reducing
things
that
are
one-offs
that
are
logically
equivalent
to
other
terms
that
we're
using
hopefully
before
we
go
to
a
v
one
beta
one.
B
I
I
know
I
kind
of
like
threw
us
a
wrench
into
some
of
the
current
plans
there,
but
yeah
some
of
it,
the
the
bottom
one
or
two
or
three,
the
bottom
like
yes,
the
second
to
last,
just
in
the
bullet
points
there
are
done
in
the
route
condition
reason
pr,
I
believe
so
the
accepted
and
ready
yeah,
the
ones
that
are
about
conditioned
reasons
I
think
are,
are
done
in
that
other
pr.
B
But
there's
a
few
other
things
like
switching
detached
to
attached
to
be
more
consistent
with
how
we're
using
not
the
like
inverse
terminology
for
most
other
cases
and
then
just
around
like
invalid
versus
invalid
parameters,
swapping
pending
and
waiting
just
pick
one
of
the
terms,
rather
than
having
two
things
that
sound
roughly
similar.
A
Yeah,
those
all
make
sense,
the
one
so
with
detached
I'm
trying
to
remember
do
we
we
already
used
attached.
Do
we
have
attached
anywhere,
or
is
this
just
a
straight
reading
of
existing.
B
Attached
exists
as
a
reason
for
the
the
detached
false
case.
It
is
expected
to
have
reason
attached,
which
I
think
is
so.
This
is
really
confusing.
A
D
A
A
There
was
no
clear
preference
of
positive
or
negative
polarity,
and
so
we
we
ended
up
with
conditions
that
were
of
both
just
based
on
a
rather
arbitrary.
What's
what
feels
more
natural?
I
think
one
of
the
ones
that
we
had
the
most
difficulty,
switching
to
a
positive
polarity
was
or
a
healthy.
You
know,
state
polarity
was
conflicted.
A
You
know
I
had,
and
I
think
you
even
mentioned
that
here,
that
you
recommend,
or
in
one
of
the
other
issues
that
you
recommended
leaving
conflicted,
as
is
because
it's
kind
of
hard
to
come
up
with
an
equivalent,
but
I
think,
if
I'm
reading
the
other
suggestions
here
correctly,
you're
suggesting
moving
to
a
positive
polarity
like
attached,
instead
of
detached
in
a
number
of
these
other
cases,.
B
A
Yeah
that
makes
sense-
and
I
think
the
other
thing
that
we
may
not
have
clarified
anywhere
in
our
docs
right
now.
But
my
understanding
and
expectation
was
that
for
the
negative
polarity
conditions
such
as
conflicted,
they
would
only
be
present
if
they
were
true.
A
So
the
lack
of
conflicted
as
a
condition
meant
that
there
were
no
conflicts,
not
conflicted
false,
but
I,
but
maybe
I'm
misremembering,
that
I
don't
know
someone
else
with
more
context.
D
E
A
E
I
think
if
the
condition
doesn't
exist,
I
think
it
it
translates
to
unknown
rather
than
false.
I'm
not
sure
the
the
upstream
guidance
is
really
not
intuitive
at
all.
It's
like
the
whole
opposite
of
what
you
would
expect.
So
that's
that's
where
we
landed
last
time
where
even
if
it
is
like
detached,
is
false
on
a
gateway
only
confuses
users,
but
you
we
have
to
encourage
them
based
on
api
guidelines,.
D
A
Okay
yeah,
so
in
that
case
we
we
can
have
them
all
present
all
the
time
that
that
is
kind
of
tangential
to
what
you're
proposing
here,
I
I
kind
of
went
off
on
a
sidebar
that
I
don't
think
you
had
intended
mike,
but
yeah.
A
B
Yeah
this
one
just
tries
to
specifically
narrow
in
on
that
polarity
inversion
case
for
the
listeners
for
the
detached
status.
B
The
other
one
is
more
of
just
a
broad
super
set
of
things
that
are
trying
to
like
have
one
tracking
issue
for
all
potential
change,
changes
for
consistency.
D
A
Well,
no,
we
never
had
to
make
everything
negative.
I
honestly
can't
remember
why
we
chose
shows
detached
over
attached.
I
know
j.
I
know
there
was
a
doc,
then
this
goes
back
a
long
time,
but
james
wrote
a
doc
that
had
negative
and
positive
polarity
for
every
condition
that
exists,
and
we
there
was
one
meeting
in
particular.
We
just
went
through
and
picked
one
of
those
for
each
one
and
we
had,
I
think
we
must
have
just
picked
detached
instead
of
attached.
A
Maybe
that
was
under
the
false
assumption
that
it
would
only
be
present
if
it
was
negative
like
if
it
was
true,
I'm
not
sure,
but
I
I
agree
it
feels
out
of
place
or
that
attached
would
be
a
an
improvement
over
this.
A
Cool
okay,
good
discussion,
there's
a
there's
a
lot
here,
I'm
just
trying
to
figure
out
how
we
can
move
all
this
forward.
This
all
relates
to
a
issue
that
is
already
in
the
v1
beta
1
milestone,
which
is
nick's
kind
of
umbrella
issue
to
that
our
status
is
wonky
and
we
need
to
improve
it
and
you
you
took
that
a
few
steps
further
and
actually
highlighted,
I
think,
most
of
the
key
places
that
it
should
and
could
be
improved.
A
A
This
also,
I
think,
belongs
in
the
milestone
any
any
other
thoughts
on
like
mike.
If
you
were
choosing
which
ones
do
you
think,
should
block
beta
release.
B
Weirdly
enough,
I
think
that
the
detached
inversionist
thing
doesn't
have
to
block
it,
because
you
can
just
keep
that
condition
as
optional
or
deprecated
and
add
a
new
attached
condition,
and
you
already
have
the
reason
for
it.
The
one
that
I
would
like
is
the
larger
one,
the
112.
which
yeah,
oh
sorry,
not
112.
Maybe
it's
111.,
the
one
that
has
the
tracking
like
the
use
of
pending
versus
waiting
and
accepted
versus
attached
or
yeah,
getting
rid
of
admitted
and
potentially
adding
like
invalid
or
invalid
parameters,
and
just
consistency
around
that.
A
C
Only
thing
I'd
say
is
you
know:
nick
just
went
through
and
really
rethought
statuses
for
the
route
inclusion
gap,
and
I
don't
know
if
if
any
of
this
would
conflict
with
what
he's
proposing
there
or
is
different
from
that
it's.
Finally,
my
only
caution
since
he's
just
gone
through
and
mentally
come
to
the
exercise
of
figuring
out
how
things
need
to
change
with
statuses.
I
hate
to
change
them
right
now
and
just
need
to
revive
them
again,
so
that
would
be
my
only
consideration
or
caution.
I
guess.
A
That's
a
really
good
point.
I
agree
with
that.
I
at
first
glance
I
think
these
are
compatible
with
the
changes
nick
has
proposed,
but
I
want
to
make
sure
that
we're
not
creating
extra
work
for
either
side
right
to
make
sure
that
we're
by
adding
this
we're,
not
slowing
down
delegation
inclusion
work
either
so
yeah,
let's,
let's
make
sure
this
is
compatible
with.
What's
what's
been,
you
know
proposed
right
now
for
inclusion.
A
Yeah,
I
I
think
that
you
know
fundamentally
the
more
users
we
have
the
more
implementations
we
have
any
rename
that
comes
after
this.
You
know
the
later
rename
exists,
the
more
painful
it
becomes.
So
I'd
agree
with
that
comment.
I
think
what
mike
mentioned
as
a
as
an
option
of
technically
we
can
leave
a
condition
in
place.
Consider
it
deprecated
and
add
a
new
one
is
compatible
and
it
works,
but
it
just
you
know
the
longer
we
wait
to
do.
It
is
more
painful.
That's
all
so.
It
sounds.
A
Are
no
there's
not
any
hesitation
to
adding
this
to
the
milestone,
correct
me.
If
I'm
wrong
all
right
I'll,
add
this
one
to
v1
beta1
mike.
Do
you
think
the
other
one
I
was
thinking
of?
Is
the
112
the
clarification
of
invalid
back
and
reps,
and
I
think
you
already
have
a
is
this
the
one
you
already
have
a
pr
that
solves
or
am
I.
B
I
absolutely
do
not
solve
all
of
it.
The
the
what's
it
called
conformance
tests
for
reference
policy
touch
some
of
this,
particularly
the
unpermitted
section,
but
this
kind
of
like
open-ended
questions
around
how
like
what
happens
for
partially
valid,
partially
invalid
routes.
I
think
that's
something
that
definitely
needs
consensus
amongst
multiple
implementations,
because,
right
now
it's
really
unclear.
D
A
D
I
meant
was
that
question
for
me:
yeah
yeah.
I
remember
we
discussed
this
with
the
security
or
someone
about
how
our
back
works
like.
If
you
someone
mounted
a
volume
or
something
and
then
the
our
back
was
like
disappeared
and
it
was
like
well,
they
were
permitted
to
do
at
that
time.
So
then
it
just
keeps
going,
but
it
wasn't.
It's
like
a
very
strict
thing
that
is
very
well
defined,
but
that
was
how
I
understood
that
kubernetes
generally
works.
A
Yeah,
I
think
it
depends
on
if
you
look
at
this
as
something
like
our
back,
which
is
allowing
an
event
to
occur
at
a
point
in
time
versus
network
policy,
which
is
I
I
the
the
way
I
look
at
reference
policy
is
somewhere
between
our
back
and
network
policy,
where
network
policy
is
something
like
that,
if
you
make
it
more,
restrictive
is
going
to
affect
everything
at
that
point
or
if
a
network
policy
that
allowed
a
set
of
traffic
is
removed.
D
That's
true:
it's
like
do
we
want
or
no
I
guess
you
can't
take
it
back
like.
Can
we
make
a
decision
now,
that's
very
explicit
that
doesn't
restrict
us
in
the
future,
or
is
it
just
like
a
kind
of
have
to
make
an
explicit
choice
now
or
if
we
let
some
freedom
in
this,
then
it's
kind
of
end
up
with
a
result
that
you
can't
take
back.
A
I
think
one
other
bit
in
our
api,
like
one
one
of
the
guidelines
we've
had
in
our
api
development
here,
is
that
you
want
a
controller
to
be
able
to
restart
look
at
the
state
of
the
world
and
be
able
to
as
close
as
possible,
build
an
accurate,
accurate
representation
that
mirrors
what
it
had
you
know
before
it
restarted
basically,
and
so
if,
for
instance,
you
were
too,
you
were
looking
at
reference
policy
as
a
point
in
time
at
a
point
in
time,
this
reference
was
allowed
and
then
controller
restarts,
and
it
loses
that
knowledge
for
some
reason.
A
A
Right
exactly
yeah,
so
I
so
that's
what
I'm
saying
it
I.
I
guess
this
is
also
a
little
tangential,
but
that's
again
we're
not
nest,
we're
not
actually
trying
to
graduate
reference
policy
as
part
of
beta
as
part
of
this
beta.
So
we
have
a
bit
more
time
in
how
we
define
that,
but
my
my
preference
would
be
to
treat
it
more
similar
to
network
policy
than
to
our
back
in
this.
Not
not
that
you
need
to
drop
every.
D
A
Okay:
okay,
there's
a
lot
there's
a
lot
in
this
issue
as
well,
I'm
not
as
certain
about
where
this
belongs.
Are
there
parts
of
this
that
feel
like
they
need
to
be
completed
before
v,
one
beta
one
mike
you're,
probably
most
familiar
with
the
the
content
here.
B
Yeah,
so
I
think,
like
there's,
there's
two
kind
of
like
ignoring
for
a
second
filled
like
individual
use
cases.
I
can
just
cut
two
big
buckets
of
like
what
happens
when
initially
applying
a
route
and
like
is
it
accepted
by
gateway
or
rejected,
and
is
there
some
kind
of
partial
acceptance
so
like
if
one
back
end
is
valid
and
one
back
end
is
invalid?
What
does
the
gateway
do
with
it
and
and
then
there's
also
the
kind
of
life
cycle
question
which
is
the
later
on?
B
B
Does
traffic
just
start
503
for
only
the
invalid
back
end
or
kind
of
like
what
happens,
so
those
are
kind
of
like
the
two
large
cases
and
I'm
uncertain
on
it
needing
to
block
beta,
but
definitely
something
that
I
would
like
to
figure
out
what
what's
the
intent
here?
I
gotta
get
some
agreement
on
that.
You
know.
C
I
was
just
gonna
say
we
did
address
this
kind
of
scenario
right
in
the
right
inclusion
gap.
We
made
a
distinct
distinction
between
attached
and
bound
being
that
an
attachment
is
basically
the
fact
that
you've,
you
know,
you've
got
a
like
a
parent
ref
from
a
route
to
a
gateway
or
from
a
route
to
a
route
in
that
regard
as
versus
a
bound
or
binding,
which
means
it's
actually,
you
know
actively
functioning.
C
So
if
you
will
so
you
could
reject
you
know
a
change
that
that
is,
isn't
valid
and
continue
to
operate.
You
know
or
continue
to
have
that
relationship
exist,
but
not
you
know
actively
part
of
the
the
runtime
configuration.
C
D
Yeah,
I
was
going
to
say
that
this
might
be
an
area
where
we
have.
We
can.
Let
implementations
have
a
bit
of
leeway,
because
I
know
some
implementations
will
are
mostly
operating
from
like
no
state
like
they'll.
Just
look
at
the
config.
That's
exists,
so
if
you
have
anything
that
require
them
to
do
something
clever
like
know
that
there
was
a
previous
valid
thing
and
then
they
like
made
it
slightly
invalid
and
then
what
to
do
there?
C
Anybody's
implementation-
that's
like
that
probably
wants
to
go,
look
at
the
inclusion
gap
and
make
comments,
then,
because
it
does
not
take
that
model
into
account.
It
assumes
that
the
controller
understands
the
the
distinction
between
the
configure
a
configured
configuration
and
a.
A
To
clarify,
I
think,
you're
describing
a
what
you're
describing
it
seems
very
similar
to
what
nick
and
others
have
proposed
in
the
issue
I
linked
further
down,
but
it
was
basically
the
idea
of
there
there's
two
states
for
a
route
that
one
state
is
I've
accepted.
A
Let
me
before
I
misspeak
here,
but
one
one
reason
is
one
condition
is
a
that's
attached.
I
believe,
and
the
second
condition
is
something
like
ready
or
programmed
and
you're
you're
saying
a
similar
level
of
separation
would
exist
for
route
inclusion
right.
The
first
is
this
is
something
that
I
understand
is
the
implementation
and
I'm
planning
to
do,
and
the
second
is
I've
re
sent
the
config
to
the
control
plane
and,
from
my
perspective,
it's
done,
but
there
may
be
some
other
work
happening
for
a
few
seconds.
C
It's
a
little
bit
more
than
that
because
you
still
have
to
be
aware
of
you
know
if
you
don't
have
this
concept
of
kind
of
an
accepted,
running,
config
and
yeah.
Oh,
yes,
everybody
go
read
the
cuff.
C
You
know
the
you
don't
want,
like
the
entire
parent
route,
completely,
not
binding
to
a
gateway
if
one
of
the
child
routes
causes
a
problem,
especially
if
somebody
like
changes,
one
of
the
child
routes
that
is
no
longer
compatible,
you
don't
want
it
to
then
blow
away
all
the
rest
of
your
infrastructure.
That's
that's
dependent
on
that
parent
route.
C
So
you
know
you
have
to
kind
of
maintain
a
a
distinction
between
you
know
what
people
are
have
tried
to
configure
and
what
the
system
is
actually
configured
at
the
you
know
what
it's
actually
programmed
the
data
plane
to
do
so,
and
I
I
see
this
is
really.
This
issue
is
related
to
that
so
yeah.
So
it
does
go.
It
does
go
back
to
what
we're
talking
about,
but
it's
not
exactly
the
same.
B
And
I
think,
aside
from,
like
the
the
ready
status,
it
sounds
like
it's
going
to
be
potentially
really
difficult
to
implement
accurately
it's
basically
being
able
to
communicate
some
sort
of
partially
invalid
error
state
such
as
like
accepted
true,
but
still
having
resolved
refs
false
with
a
ref,
not
permitted
or
something
or
invalid
ref,
or
something
like
that.
A
Okay,
yeah
makes
sense,
I'm
just
okay.
So
let
me
let
me
take
a
step
back,
let's
go
to
mike
you're
you're.
I
think
you,
you
really
hit
on
some
of
our
most
important
things
remaining
for
v.
One
beta
one
right
and
that
is,
and
and
it's
kind
of
been
looming
for
for
a
minute
is:
if
you
look
at
our
v1
beta1
milestone,
we
have
a
lot
of
cleanup
things.
Documentation
we
need
to
make
the
web
hook
deploy
better,
and
then
we
have
this
one
api
change
whatever
of
this.
A
This
is
our
last
remaining
api
thing
and
it's
clean
up
our
status
and
you
have
defined
everything
very
well.
Do
you
feel
like
you,
have
everything
you
need
to
move
forward
like?
Maybe
it
does
a
gap?
I
seem
like
the
right
step
for
this
or
I
do
you
feel,
like
you
have
enough
information
to
to
work
on
something
like
that.
B
I
think
the
biggest
thing
that
I
really
need
blocking
this
is
input
from
other
implementations,
like
I
think
I've
tried
to
capture
our
experience
and
kind
of
like
the
rough
edges
that
we've
found,
but
I
really
want
to
hear
from
other
implementations
of
if
they
agree
with
these,
if
they
have
specific
proposals
for
addressing
some
of
them,
that
may
differ
from
mine.
Anything
like
that
and
and
if
a
gap's,
the
right
format
for
that,
then
I
can
clean
this
up
and
put
it
into
that.
But.
C
A
Yeah
I'd
agree
with
that.
I
I
only
represent.
You
know
what
the
implementation
I'm
I'm
most
familiar
with,
so
I
I
can
only
provide
one
perspective,
but
I'm
very
interested
in
what
other
others
think
as
well.
I
you
know
historically,
we've
let
individual
new
reasons
come
in
without
a
gap,
because
it's
just
you
know
a
small
addition,
because
this
represents-
or
these
series
of
issues
seem
to
be
a
broader
series
of
changes.
A
Yeah,
probably
is
the
easiest
way
to
represent
those
changes,
so
if
yeah,
if
you're,
if
you
have
the
time
I'd
love
to
see
it,
get
for
this,
and
also
I've
been
talking
a
lot
on
this
call,
but
if
any
other
implementation
implementers
want
to
speak
up
and
either
agree
or
disagree
with
any
of
this,
these
suggestions,
I'm
very
interested
too.
A
Maybe
to
call
some
people
out
harry,
or
maybe
the
wind
I
do
do,
have
you
run
into
either
of
these
kinds
of
issues.
F
A
No
worries
no
worries.
Thank
you.
So
what
we're
just
trying
we
mike
has
done
great
work
here,
trying
to
highlight
some
of
the
lack
some
of
the
flaws
in
our
status
right
now
and
he's
proposed
some
changes
so
for,
for
example,
adding
new
reasons
such
as
ref,
not
permitted.
A
That
would
be,
I
think,
most
relevant
for
to
in
reference
policy,
not
permitting
a
cross
name
space
reference
or
these
kinds
of
things
have
you
run
into
any
other
similar
shortcomings
where
it's
not
clear
what
to
put
in
status.
F
A
Yeah,
that's
helpful.
Actually,
nathan
were
you
about
to
say
someone.
D
I
was
gonna
say
like
even
for
us
right.
A
lot
of
these
things
didn't
come
up
until
we
started
trying
to
write
conformance
tests
and
you're
like
oh.
What
should
this
look
like
and
either
like
you
made
an
assumption
when
you're
doing
the
implementation,
or
you
just
didn't
think
about
this
edge
case,
so
it's
likely
that
other
implementers
just
haven't
run
into
it.
Yet.
A
That's
great
okay!
Well,
thank
you
for
raising
this
discussion.
Looking
forward
to
a
gap
and
yeah
is.
A
I
added
oh
I'd,
guess
I
didn't
add
this
specific
one
too.
So
I
think
we
need
some
improvements
to
status.
We
need
to
at
at
a
minimum,
make
sure
our
conditions
and
reasons
are
consistent
across
types.
I
think
that's
probably
the
most
important
thing
in
this
list
and
then
the
way
I
understand
112,
if
I
can
get
there,
is
that
this
is
really
just
trying
to
expand
our
reasons
so
they're
a
little
bit
more
descriptive.
C
B
A
That
makes
sense.
Okay!
Well
thanks
a
bunch.
I
know
I've
spent
a
lot
of
time
on
this,
but
thank
you
for
the
great
write-ups
on
all
of
these
and
good
discussion.
All
right.
Let's
move
on
nathan.
You've
got
the
next
one.
D
Yeah,
so
I'm
kind
of
basing
this
next
set
of
conformance
tests
and
what
mike's
got
going
there,
but
it's
instead
of
route
to
back
end
permissions.
It
is
a
gateway
to
certificate
permissions
or
secret,
and
there
was
a
distinction
made
in
the
docs
that
the
route
to
back
end
ref
was
part
of
core.
A
I
my
best,
I
took
a
quick
look
at
this
before
the
meeting
and
as
far
as
I
can
tell
no,
I
think
this
is
an
accidental
omission,
I'm
trying
to
remember
the
history
of
reference
policy,
but
I'm
wondering
if
it
started
with
support
for
backend
ref.
A
I
think
I
think
reference
policy
started
with
the
ability
to
forward
to
a
different
namespace
and
that's
when
these
docs
came
in
and
then
I
think
we
at
a
later
point
added
the
ability
for
it
to
support
cross
namespace
certificate
or
secret
references,
and
it
never
made
it
to
this
dock.
That's
my
rough
recollection
of
the
history
here.
D
A
A
D
Guess
to
clarify
it's
just
a
feature:
flag
versus.
Is
it
an
individual
test
case
because
they
should
be
two
individual
test
cases?
Yeah
there's
like
that's
less
of
a
big
deal,
whether
or
not
like
when
you
run
it,
you
have
like
one
flag
and
then
later
on,
we
need
two.
So
we
just
break
it
up.
Yeah,
there's
like
there
ends
up
being
like
six
separate
test
cases
across
all
the
different
applications
of
reference
policy.
D
A
A
So
it
may
just
be
nick,
and
I
know
some
people
had
asked
in
slack
as
well,
so
it
seems
like
some
others
will
be
there
too
we're
planning
on
or
hoping
to
do
some
meetups
either
at
the
contributor
summit
or
just
after
the
gateway
talk.
A
If
you
know
anyone
who
will
be
there
and
who
might
be
interested,
definitely
link
them
to
our
slack
and
wherever
else,
but
always
always
happy
to
meet
people
and
happy
to
get
back
to
kubecon
in
person.
So
maybe
we'll
see
more
people
at
kubecon
in
detroit
later
this
year,
who
knows
cool?
I
I
just
added
this.
This
really
should
just
be
under
the
issue
triage,
but
I
just
wanted
to
make
sure
this
didn't
get
missed.
This
has
been
through
a
few
rounds
of
review
right
now.
A
It's
kind
of
gotten
lost,
I
think
so.
If
anyone
is
able,
I
think
any
work.
Member
can
do
this,
but
1066.
I
think
I've
resolved
all
the
final
comments
on
this.
D
Oh
rob
I'll.
Take
a
look.
I'm
assuming
I
see
like
a
bunch
of
comments
already
resolved
so
yeah,
okay,.
A
Cool
thanks:
well,
that's
that's
great!
Next,
we'll
move
on
to
pr
and
issue
triage.
A
lot
of
the
new
issues
that
came
in
were
related
to
status.
A
I
went
through
and
I
can
remove
the
stale
lifes
that
are
committed
to
doing
this.
I
think
added
this
to
the
milestone.
A
Let's
see
what
else
is
new
this
this
time
I
have
a
new
pr
that
fixes
this
issue.
Let
me
let
me
just
highlight
that
real
quickly.
This
is
one
that
I
added
to
the
milestone
as
well,
because
or
I
think,
should
be
added
to
the
milestone.
A
This
is
so
tiny.
James
made
the
very
good
point,
and
it
just
kind
of
got
lost
that
we
have
this
requirement,
that
a
parent
ref,
if
it's
invalid
needs
to
have
status
set,
but
the
whole
idea
of
a
parent
ref
is
if
it's
invalid.
How
do
you
know
who
should
implement
it?
You
know
I'm
like
who's,
the
parent,
if
you
so
anyway,
this
just
removes
that
and
hopefully
makes
a
little
bit
clearer,
good
point
yeah.
A
So
all
right,
sorry.
What
was
that?
I
just
thought.
That's
a
good
point:
oh
yeah
yeah.
So
this
was
a
funny
one,
but
thanks
to
jeff
for
fun,
sorry
james
for
finding
this
one
out
cool
those
are
the
main
issues.
So
I've
been
out
for
a
few
days,
so
I'm
just
trying
to
get
get
back
into
things,
but
those
are
the
main
ones
I
saw
come
through
in
the
past
few
days.
A
A
There
were
some
bigger
pr's
that
came
through
this
week.
One
of
the
big
ones
right
up
at
the
top
is
richards
richard.
Are
you
on
this?
Not
yeah
yeah,
I'm
here
cool,
so
I
think
you're
just
actually
implementing
the
grpc
route
gap
right.
This
is
great
this.
This
is
really
just
verbatim
from
the
gap,
adding
the
types
and
then
generating
based
on
that
right.
Yep.
A
A
That's
like
earlier
in
the
meeting
I
was
trying
to
determine
okay,
what
what
issues
belong
in
v1
beta
1,
and
you
know
just
trying
to
make
sure
that
we
can
actually
get
this
release
out
the
door
and
everything
else
is
just
kind
of
underneath
that
list
in
terms
of
prioritization,
but
this
I
I'm
hoping
will
be
fairly
straightforward.
Since
we've
discussed
most
things
in
the
gap.
I
just
yeah.
A
Yeah
well
said
well
said,
and
I'd
say
it's
a
similar
thing
for
this
gap,
which
is
also
huge
and
well
written,
but
it
is
not
blocking
v1
beta1
so
again
encourage
anyone
who
has
extra
time
to
to
go
through
this
one.
But
if
you
see
things
in
the
milestone,
which
is
the
v1
beta
1
milestone,
those
are
the
ones
that
we're
really
trying
to
make
sure
we
prioritize
in
the
next
few
weeks
next
couple
weeks
really
a
lot
of
those
have
open
prs,
if
not
a
lot
of
them.
A
A
Cool,
let's
see,
are,
were
there
any
other
one?
Yes,
I
really
wanted
to
discuss
this
one
more
broadly.
This,
I
think,
led
to
some
confusion.
I
started
to
type
up
some
comments
on
this
and
I
got
more
confused,
and
so
maybe
I
think
I
misunderstood
the
use
case
or
I'm
not
understanding
the
use
case
fully
in
this
mike
when
you're,
when
you're
running
when
you're
running
tests,
I
think
what
you're
describing
is.
A
B
Oh
yeah,
this
is
something
feel
free
to
close.
If
it
doesn't
make
sense,
it
was
just
something
that
was
helping
me
debug
when
cleanup
flag
wasn't
behaving
in
the
way
that
I
had
initially
expected
it
to
kind
of
reflecting
on
it.
I
think
it's
probably
just
a
misunderstanding
on
my
part,
so
unless
other
folks
want
this,
behavior
feel
free
to
close
it.
A
So
I've
I've
definitely
been
one
who
has
modified
modified
tests
in
a
similar
way
when
I've
been
running
conformance
tests.
So
I
understand
this
use
case,
but
I
wanted
to
clarify
when
you're
modifying
so
when
I
was
doing
it,
it
was
when
I
was
running
a
very
specific
test.
I
wanted
those
resources
to
stay
around
afterwards.
A
What
I
think
is
really
dangerous
is
if
we
let
all
resources
stay
around
indefinitely,
because
basically,
these
conformance
tests
are
written
in
a
way
that
they
they
all
operate
in
their
own
little
bubble
and
are
likely
not
very
happy.
If
you
know
weird
things
happen,
if
you
have
another
conformance
test
running
without
the
previous
ones
being
cleaned
up,
and
then
your
parent
reps,
instead
of
having
two
parent
reps,
you
have
three
or
four
or
whatever
it
is
you
know,
and
then
the
tests
are
brittle
enough
that
they
just
say.
Well,
I
expected
two.
A
I
don't
know
why
there's
four
now
so
that
that
was
the
thing
that
scared
me
about
this,
but
I
wanted
to
understand
if
that
was
actually
the
use
case
you
had
to
or
if
you
were
running
the
full
suite
same
use
case
running
a
single.
D
Okay,
I
I
actually
ran
into
the
same
bit
of
confusion,
so
I
would
appreciate
like
if
we
could,
at
least
just
add
a
comment
or
something.
That's
like
here's
what's
happening.
And
why?
Because
I
think
between
mike
and
I,
we
probably
wasted
a
reasonable
chunk
of
time
figuring
out.
A
That
that
makes
a
lot
of
sense.
It
seems
like
we
really
need
and-
and
I
think
someone
suggested
this
in
the
thread
down
here
somewhere,
but
it
seems
like
we
really
have
two
different
feature
requests.
We
have
the
one
thing
that
is
supported,
but
not
documented
well
of
let
the
base
resources
stick
around
after
test
run
and
that
is
currently
communicated
with
the
cleanup
flag,
which
is
maybe
probably
not
the
best
term.
For
that,
and
then
the
the
second
item
is,
I
have
a
specific
test.
A
I
think,
what
you've
what
this
pr
does
right
now
is
it
merges
the
purpose
of
those
two
flags
together,
where
I
think
we
want.
We
still
want
the
other
flag
to
exist.
The
base
resource
thing
you
know
so
the
reason
for
some
for
some
implementations
like
gk,
where
it
can
take
minutes
for
gateways
to
spin
up
and
then
seconds
for
other
things
to
happen.
A
It's
very
helpful
to
just
say
those
base
resources.
I
just
want
them
to
stick
around
across
runs
and
then
the
other
thing
you.
A
Rename
this
flag-
I
agree,
I
I
agree
yeah,
so
it
seems
like
two
things:
rename
flag
and
second
optionally,
add
a
new
flag
that
does
the
full
cleanup
of.
I
think
the.
D
A
Okay,
mike,
do
you
have
time
to
take
this
or
to
follow
up
with
this
one.
B
Probably
not
at
the
moment,
but
I
can
close
it
with
the
explanation
of
what
we
decided
or
the
path
forward
for
anybody
else.
Let's
say
there's
a
few
other
folks
interested
in
this
issue
who
may
be
able
to
pick
it
up
cool.
A
Well,
I
see
a
few
others
have
commented
on
this,
so
if,
if
anyone
else
it
seems
like
this
is
plenty
of
people
are
interested.
So
if
anyone
else
does
have
time,
I'd
love
to
get
this
one
in
or
a
variation
of
this
in
cool
all
right.
I
think
that's
everything
that
I
wanted
to
highlight
in
today's
meeting,
but
let
me
know
am
I
am
I
missing
anything
anything
else
we
should
discuss
today.
C
I
had
a
quick
question
I
it's
kind
of
like
I
don't
know
if
I
should
bother
raising
this
as
an
issue
or
not
so
you
know,
we've
we've
said
that
that
gateways
only
are
influenced
by
the
gateway
class
settings
on
creation
and
that
changes
to
the
gateway
class
after
that
will
do
not
affect
gateways.
C
I
totally
get
the
understanding.
You
know
why
we
did
that.
But
what
about
the
situation
where,
as
an
admin,
you
know
who
owns
the
gateway
class?
I
do
want
to
force
the
change.
You
know
we
don't
really
have
a
way
of
doing
that
in
this
spec.
D
You
will
have
to
recreate,
so
I
think
I'm
trying
to
remember
if
we
actually
wrote
this
down
so
it
there
was
some
discussion
where
it's
like.
Well,
maybe
this
should
be
up
to
the
implementation
to
allow
if
you
wanted
to
basically
have
like
a
class
option,
change
propagate
that
you
could,
if
your
implementation
can
support
it,
but
that
we
don't
necessarily
exclude
people
from
not
propagating
it.
I
think
we
have
some
explicit
thing
here.
D
A
Yeah,
I
think
I
think
there
were
two
two
principles
here.
One
is
fundamentally
limiting
that
blast.
Radius
right
of
one
change
to
gateway
class,
affects
all
these
gateways.
You
know,
potentially,
all
your
production
production
traffic
across
and
load
balancers,
whatever
it
is
right.
The
other
thing
is
that,
at
least
for
some
implementations,
this
change
can
represent
that
you
know.
A
This
is
just
a
recommendation
in
the
spec
right
now,
with
this
kind
of
you
know
exception.
Whatever
that
I
highlighted
here
that
you
can
choose
to
propagate
gateway
class
changes,
but
that
needs
to
be
very
clearly
documented
by
your
implementation.
A
C
It
seems
almost
like
we
need
a
a
way
to
to
tell
a
gateway
to
re-reconcile
itself
in
a
sense,
and
you
know,
re-read
the
configs
and
and
see
if
there's
been
changes
and
and
implement
them.
D
I
guess
the
question
would
be
if
you
delete
and
recreate
it
should
do
that,
because
you
can
look
at
the
uuid
to
know
that
that
resource
has
basically
disappeared.
D
C
Yeah,
because
if
you've
got
like
multiple
instances
of
the
same
gateway,
then
you
you
might
want
to
trigger
re-reconcile,
but
on
an
instance
by
instant
spaces,
a
kind
of
a
rolling
upgrade
in
a
sense,
sorry
nate.
I
think
that.