►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220314
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220314
A
All
right,
we're
recording
we've
got
a
few
things
on
the
agenda
today,
but
first
off,
I
want
to
hand
it
off
to
mike.
I
think
you've
got
a
question
about
route
status.
B
Sure
so
this
is
mostly
a
conversation
that
I'll
be
turning
over
to
nick,
I
believe,
but
I've
heard
it
anecdotally,
a
few
mentions
of
a
proposal
to
change
something
about
the
way
that
route
status
is
handled
specifically
in
relationship
to
like
how
the
gateway
is
where
a
lot
of
that
status
is
reflected
but
yeah,
I
guess
dick
or
rob
or
anybody
else
who
has
more
context
to
this.
I
would
be
very
interested
in
hearing
it.
C
All
right,
sorry,
sorry,
I
missed
that.
My
my
wife
came
back
sorry,
man.
B
Sorry,
yeah
I'll
repeat
that
yeah.
So
basically,
I've
heard
anecdotally
a
few
mentions
of
proposals
to
changes
of
how
route
status
is
handled
simply
in
relation
to
how
it's
like
reflected
on
the
gateway
and
how
the
gateway
can
kind
of
conveys
a
lot
of
information
about
each
individual
route.
I
would
love
to
hear
more
thoughts
or
detail
from
anybody
who
has
been
part
of
these
conversations
not
like
what
the
shape
of
some
of
those
concerns
are
and
like.
B
C
My
my
understanding,
so
we
have
talked
a
little
bit
that
basically
a
while
ago
james
did
the
work
to
define
the
the
status
flow
for
gateway
and
sort
of
went
through
all
of
the
different
permutations
and
made
made
the
conditions
and
stuff
like
that
for
gateway.
It's
just.
I
think
it's
more
just
that
no
one
has
ever
sat
down
and
gone
through
the
full
flow
for
hoshide
period,
make
sure
we
haven't
missed
any
conditions.
C
I
don't.
I
think
that
the
model
we
have
is
mostly
correct.
Right,
rob
correct
me
if
I'm
wrong,
but
the
I
think
the
model
we
have
is
mostly
correct,
but
we
might
just
need
like.
I
think
we
need
to
define
like
some
extra
some
extra
condition
types
and
some
extra
reasons
and
stuff
like
that,
to
sort
of
tidy
up
and
and
to
be
more
specific
about
route
status
about
what
happens
when
certain
things
happen
like
when
you
raise
certain
condition,
types
and
things
like
that.
I
know
the
contour
team.
C
When
we've
been
implementing
stuff,
I've
found
a
couple
of
gaps
and
then
I
think
that
we'll
need
to
do
a
similar
thing
for
the
once.
We
as
part
of
the
route
inclusion,
I
put
my
hand
up.
A
Yeah,
I
think
that
matches
my
experience.
My
understanding,
too,
I
don't
think
we
have
any
pending
changes
to
status.
That
are
what
I
would
consider
breaking.
A
Those
are
the
things
I'd
be
most
concerned
about
the
things
that
I
think
about
when
I
think
about
status
are
just
gaps,
things
lacking
conditions,
lacking
reasons
lacking
a
common
way
of
handling
certain
error
conditions
like
I
think
there
are
some
cases
in
gk
right
now,
where
our
implementation
has
created,
custom
conditions
or
event
types
or
other
things
to
communicate
an
error
state
that
maybe
we're
the
only
ones
that
have
or
maybe
there's
just
other
unique
handling
out
there.
A
A
That's
my
understanding
route
delegation
definitely
brings
another
element
here
of
instead
of
a
you
know.
Right
now,
our
route
gateway,
binding
is
so
our
status
in
routes
right
now
is
very
tied
to
the
parent
resource
and
a
route
having
a
parent.
That
is
another
route
makes
that
a
little
funny
and
weird-
and
it's
that's
exactly
what
got
me
thinking
about
this
like.
C
I
had
a
little
look
at.
I
had
a
little
look
at
it
as
well,
just
before
I
offered
to
to
do
the
rewrite
on
that
other
dock,
and
I
think
I
think
what
we've
got
is
actually
pretty
close.
C
You
the
the
fact
that
we've
referred
to
it
as
parent
ref,
the
whole
time
rather
than
gateway
ref
or
anything
like
that,
like
I
think
it
may
just
mostly
work,
but
we
just
may
need
to
sort
of
be
more
specific
about
these
things
mean
that
the
route,
the
whole
route
must
be
rejected,
and
these
things
mean
that
the
attachment
to
the
power
around
is
is
rejected,
and
we
need
to
tell
you
that
the
attachment
to
the
parent
route
was
rejected
for
some
reason,
and
that's
that
and
but
the
other
important
thing
is
that
you
know
that
we've
got
the
controller.
C
The
only
controller
thing
there
as
well,
so
that
so
you
can
know
which
controller
has
picked.
That
up
in
the
case
that
you
have
multiple
running
in
the
cluster,
so
yeah.
I
think
I
I
will
sit
down
and
have
a
think
about
that.
But
I
I
feel
pretty
good
that
we
shouldn't
need
any
changes
that
would
any
breaking
api
changes.
It
should
just
be
like
being
more
specific
about
the
flow
and
how
the
flow
works
and
what
we,
what
the
yeah
and
what
the
stages
are.
C
I
would
encourage
anyone
who
has
implemented
this
already
to
their
ears.
There's
like
an
implementer's
experience
discussion
that
someone
opened
a
while
ago
rob
I
will
get.
I
will
ask
the
contour
steve
chris,
the
contour
who's,
doing
the
contour
implementation
to
just
go
through
and
find
any
bits
where
I
know
he's
found
a
couple
of
places
where
we
ended
up
doing
our
own
conditions.
I'll
just
ask
him
to
comment
them
there,
so
we
can
try
and
collect
all
of
the
feedback
in
one
place.
C
If
you
could
do
that
as
well,
that
would
be
good
that'll
make
it
yeah,
and
I
would
encourage
anyone
else,
who's
doing
implementations,
who's
needed
to
do
route,
status,
conditions
or
custom
types
or
reasons
or
any
of
that
sort
of
stuff.
Then,
if
you
could
work
on
that,
I'm
thinking
I'll
in
a
minute
I'll
find
that
discussion
and
put
it
in
put
it
in
under
here.
A
Yeah,
that's
a
that's
a
really
good
point.
I've
been
meaning
to
do
some
kind
of
internal
audit
just
to
understand.
You
know
what
what
conditions
we
have
accumulated
at
this
point,
what
we're
publishing
and
which
of
those
seem
like
they
could
potentially
be
generic
and
upstreamed
yeah
good
idea,
and
yet,
like
you,
said,
any
implementation
in
progress.
A
There's
something
about
implementing
an
api
where
you
run
into
more
edge
cases
than
you
think
about
when
you're
actually
designing
the
api
so
yeah,
absolutely
so
one
one
tiny
thing
I
think
well
before
I
move
on
mike,
was
there
anything
else
to
cover
on
status.
B
No,
I
think,
that's
mostly.
It
was
just
like
trying
to
figure
out
if
there's
any,
like
large
change
floating
around
that's
been
discussed,
but
hasn't
made
it
into
a
proposal.
It
sounds
like
not
really
it's
kind
of
just
like
ironing
out
some
of
the
details
and
figuring
out
how
we
might
want
this
to
apply
to
the
route
inclusion
delegation
stuff.
It
sounds
good
thanks,
cool.
A
Great
yeah,
just
one
quick
note
on
kubecon:
we
did
get
our
session
in
it
is
a
maintainer
track.
Hopefully,
conditions
are
such
that
we're
able
to
make
it
there
we'll
see,
but
either
way
we
are
presenting
open
to
ideas
on
if
there's
specific
bits
of
content,
we
should
highlight
or
talk
about
in
that
session,
and
certainly,
if
others
are
able
to
make
it
to
kubecon,
it
would
be
great
to
see
people
there
again
if
conditions
allow
yeah,
I
don't
know
nick
did
you
have
anything
to
add
cool.
D
C
Don't
I
was
just
making
sure
I
put
that
discussion
in
while
I
thought
of
it.
You
know,
I
think,
rob
you
and
I
are
both
planning
to
be
there
right,
so
yeah,
so
we're
gonna.
Do
we're
gonna
run
the
the
session
in
person.
The
usual
format
for
these
things
is
pretty
prescribed
these
days,
like
you
need
to
do
an
intro
to
the
project.
C
You
do
a
demo
or
some
sort
of
you
know
sort
of
here's
what
the
project
actually
does
and
then
you
talk
about
the
where
the
project
is
going
on
the
roadmap.
So
that's
what
we
will
need
to
talk
about
yeah
cool,
yes,
yeah.
A
Cool
next
up
well,
actually
nick
yours
seems
very
well
no
I'll
go
through
what
yeah.
No,
let's
go
to
yours.
First
nick
you
have
a
few
little
install
things.
C
Yeah
yeah,
one
thing
I
did
I
did
realize
I
did
notice
that
we
have
been.
We
moved
straight
on
to
business,
but
we
didn't
we
didn't
really
we
haven't
been
doing.
I
don't
think
we're
doing
a
great
job
of
introducing
the
meeting
for
the
recordings
and
stuff
so
yeah.
Let's,
let's
take
a
moment
now
and
you
sorry
everyone.
This
is
the
gateway.
Api
meeting,
rob
scott
and
nick
young
me.
Are
you
we're
maintainers
and
we
tend
to
drive
the
meetings
a
lot?
The?
C
If,
if
it's
your
first
meeting,
please
feel
free
to
unmute
and
or
put
your
hand
up
or
something
and
say
hi.
If
there's
any
questions
we
have
an
agenda.
The
agenda
is
just
there
to
make
sure
that
we
don't
forget
things.
Please
feel
free
to
add
anything.
You
want
to
add
at
any
time
or
if
you
have
a
question
or
would
like
to
discuss
something
then
yeah
you
can
feel
free
to
do
that
too.
C
I
did
notice
there's
a
couple
extra
new
people
that
I
haven't
seen
before
yeah,
if,
if
you're
doing
an
implementation
or
something
like
that,
then
yeah
I'd,
love,
we'd,
love
to
hear
more
about
it
and
so
100.
Fine,
if
you
don't
feel
like
talking
about
it
today,
but
yeah.
Welcome
to
the
me
welcome
to
everybody,
okay,
so
yeah!
C
I
just
wanted
to
quickly
run
some
sort
things
past
so
that
people
had
a
chance
to
check
violently
before
I
go
away
and
do
the
work
to
actually
implement
these
things
so
yeah
I'm
working
on
the
making
it
so
that
making
it
so
that
installing
the
web
hook
is
a
little
easier
and
that
yam
author
installed
in
the
web
book
will
be
included
as
part
of
our
release
bundle.
So
there's
a
bunch
of
stuff
I
needed
to
figure
out.
C
This
is
the
the
sort
of
the
headline
things
there's
a
bunch
of
other
little
fiddly
details,
but
I
wanted
to
run
this
so
right
now
that
stuff
gets
installed
in
a
namespace
called
gateway
api.
This
feels
a
little
I
feel
like
renaming
to
gateway
system,
would
probably
be
more
reflective
of
the
fact
that
this
is
like
a
system
level
thing
if
you're
using
the
gateway
api
and
keep
up
with
the
sort
of
dash
system
nomenclature,
that
lots
of
other
parts
of
the
project
use
so
yeah
that
I'm
proposing.
D
A
Yeah
I'd
agree
with
that.
I
think
it's
a
reasonable
change.
I
think
the
install
base
of
gateway
api,
like
of
these
manifest,
is
probably
pretty
minimal,
but
we'll
just
need
to
make
sure
we
have
a
good
release
note
in
there
in
case
they
ended
up
end
up
with
two
web
hooks
at
some
point
in
the
future.
C
Yeah,
yes,
so
yeah
and
then
in
terms
of
actually
doing
the
install.
The
next
thing
is
right:
now
we
recommend
people
to
keep
total
customize
with
the
with
the
tag.
What
I'd
like
to
do
is
set
up
look
at
if
there's
a
way
to
set
up
a
rendered.
C
You
know
we
have
a
copy
of
the
rendered
stuff
in
the
branch
in
in
the
branch
and
possibly
have
a
thinking,
maybe
having
like
a
single
rendered
file
with
everything
in
it.
Like
you
know,
that's
the
easy,
install
and
then
having
those
rendered
files
live
in
a
directory
somewhere
that
that
that
you
know
that
has
individual
files
so
that,
if
you
want
to
customize
them
or
something
like
that,
it's
much
easier
than
they're
needing
to
you
know
do
something
yeah
to
pass
a
a
single
big
chunk
of
yammer,
really
sucks.
C
F
C
I'm
a
little
reluctant
to
do
to
go
too
far
down
like
a
helm
chart
or
something
like
this
for
this
for
this
setup,
because
almost
certainly
everyone
who's
going
to
be
installing
an
implementation
is
going
to
have
to
do
something
like
a
helm
chart
or
some
other
thing,
and
this
is
going
to
be
a
dependency.
I
would
much
rather
make
it
that
your
implementations
can
include
these
yamls
in
their
helm.
Chart
somehow,
rather
than
be
too
complicated
about
dependency
management.
C
So
those
are
my
feelings
again
wanted
to
give
everyone
a
chance
to
to
sort
of
tell
me
I'm
wrong
before
I
got
too
far
down
the
path
of
doing
this.
A
Yeah
I
can
jump
in,
I
am
all
in
all
on
board
of
less
generation.
Certainly
I've
heard
helm
and
crds
don't
play
well,
for
example,
customize
is
not
terrible.
You
know
it
can
be
a
simple,
I
think,
we're
we
make
it
over
complicated
in
our
install
instructions
where
now
it's
just
cuddle
apply
dash
k
and
it
just
kind
of
works,
but
less
cost.
A
You
know
like
just
as
whatever
we
do,
if
it
can
be
as
simple
as
possible
that
that
would
be
my,
like,
you
said
like
to
make
it
as
easy
as
possible
to
include
elsewhere.
I
don't
care
too
much
about
the
underlying
bits,
but
yeah
strong
preference
for
simple.
C
Yeah
yeah,
so
the
other
reason
I
wanted
to
be
simple
relates
to
the
next
item,
which
is
that
I
want
to
add
a
conformance
test
suite
for
the
workbook
validation,
so
that
my
idea
here
is.
We
need
to
ensure
that
implementations
as
part
of
their
standard
install
are
including
the
web
book.
So
we
need
to
ensure
that
we're
testing
that
the
stuff
that
we
are
validating
in
the
web
book
fails
when
it
should
fail.
C
Basically,
so
that's
what
the
conformance
test
suite
for
the
workbook
validation
will
be,
that
that
there
will
be
a
bunch
of
stuff
that
should
the
web
book
should
block-
and
you
know
the
conformance
test
suite
will
check
that
it
does
block
them
and
in
order
to
do
that,
we're
going
to
need
to
be
able
to
make
it
easy
for
implementers
to
install
the
the
web
hook.
C
And
ideally
it
needs
to
be
able
to
be
done
in
ci
right
so
that
you
can
do
a
single
line
thing
that
will
install
the
web
hook
and
that
and
you
can
wait
till
the
apple
comes
up
and
then
you
can
run
the
then
you
can
run
the
conformance
test.
C
So
I
want
to
make
sure
that
before
that,
as
part
of
like
very
soon
around
the
same,
in
the
same
release
that
we
add,
you
know
that
we
changed
the
way
the
install
worked
or
the
way
that
I
add
the
conformance
test
suite
that
we
have
that
we've
changed
the
way
that
install
works
so
that
it's
much
easier
to
do
that
sort
of
thing.
That's
all
yeah.
I
I
had
a
great
thanks
yeah
I
had
to
look
through
rob.
C
A
Okay,
well,
that
was
actually
a
really
good
transition,
because
one
of
these
things
I
added
to
the
milestone,
was
e2e
test
for
the
validating
web
hook,
which
seems
like
it
overlaps
with
your
last
bullet
point.
A
We
already
have
something
very
similar
to
that
with
our
kind
cluster
that
we
spin
up
and
run
some
basic
things
with
that's
just
using
testing
crd
validation,
it
seems
like
it
makes
sense
just
to
expand
that
to
include
webhook
validation,
so
yeah.
That
is
one
of
many
things
we
have
going
on
here.
C
The
thing
that
I
wanted
to
add
to
that
was
just
that.
I
think
that
we
should
make
sure
that
I'm
gonna
try
and
hit
every
bit
of
validation.
We
do
currently
in
the
workbook
and
make
sure
that
there's
a
test
for
it
and
then,
as
we
add,
if
we
ever
add
more
valid,
as
we
add
validation
to
the
workbook,
you
add
the
unit
tests.
C
But
then
you
also
need
to
add
the
the
the
conformance
test
so
that
that
way
that
we
can
make
sure
that
everybody's
stuff
is
keeping
up
to
date
and
as
we
release,
you
know
that
that's
it
all
just
lines
up
and
make
sure
that
everybody's
doing
the
right
thing.
C
The
other
thing
that
I
wanted
to
make
sure
we
is
available
for
people
here
is
that
if
you
want
to
take
the
web
hook
implementation
code
and
superclass
it
and
do
your
own
validation
as
well,
the
thing
that
will
be
required
for
conformance
is
whatever
is
in
the
upstream.
So
if
you
want
to
take
whatever's
in
the
upstream
and
do
a
bit
extra
validation,
you
can.
But
you
can't
take
away
validation
until
we
can
form
it
part
of
the
the
point
of
the
conformance
test
testing.
C
A
A
Okay,
so
I
we're
getting
awfully
close,
as
the
theme
of
these
meetings
has
been
to
a
v1
beta,
1
release,
v0.5.0
of
the
api
and
I
went
through.
We
have
that
we've
had
this
v1
beta
1
milestone
for
a
while,
and
I
went
through
and
added
a
bunch
of
issues
to
it
that
I
think
are
relevant
to
v1
beta
1..
Some
of
these
are
long-lived
issues
that
just
need
to
be
resolved
before
we
hit
v1
beta
1..
A
Some
of
these
are
brand
new
that
came
out
of
our
discussion
in
one
of
the
last
couple
meetings
at
the
very
top
of
the
list.
You
can
probably
tell
that
we
have
a
long-lived
issue,
one
that
has
been
neglected,
but
something
like
that
would
be
worth
reviving
discussion
on
again
in
our
initial
sig
network
review
for
v1
alpha
2,
we
got
some
feedback
that
port
range
or
all
ports
was
a
useful
use
case
of
the
api.
G
G
I
mean
it's
more
inspecting
all
traffic,
so
ports
are
useful
for
proxy
type
applications
like
http,
but
if
I
want
to
send
other
customers
and
send
all
us
all
their
traffic
to
say
inspect
it,
we
don't
want
to
have
to
go
and
tell
them
oh
list
all
the
ports
you
what's
inspected,
it's
like!
No,
they
want
to
say,
inspect
all
this
and
it's
it's.
You
know
it's
like
the
ideas
we
have
launching
today.
You
know
just
now:
yeah
they
don't
care,
they
don't
want
to
look
at
ports.
G
A
Good
good
to
know
that
that
does
that
does
seem
like
it
it.
It
is
different
than
kind
of
the
primary
use
case.
We've
been,
we've
been
building
a
lot
of
the
api
around,
but
it
doesn't
mean
that
the
api
can,
you
know
eventually
support
that.
It's
just
that
the
biggest
concern
I
have
with
this
potential
change
to
the
api
is
what
it
means
for
the
primary
use
case
of
the
api
right.
A
I
shouldn't
I
shouldn't
say
the
primary
use
case,
but
the
the
first
set
of
implementations
of
this
api
are
very
focused
on
a
you
know,
ingress
for
for
lack
of
a
better
term
ingress
traffic,
and
in
many
cases
you
know,
matching
all
ports
or
range
reports
can
be
more
complicated
or
just
not
scale
well
in
the
in
those
scenarios.
F
Oh,
I
had
one
comment
question
here:
do
we
have
a
table
with
implementations
and
and
for
each
proposed
feature
if
that
particular
behavior
is
supported
by
a
majority
or
or
a
subset
of
the
implementers,
because
I
I
can
see
you
know
with
some
representation,
it
will
be
very
easy
to
add
in
some
implementation.
It's
not
these
and
for
users.
It's
probably
important
to
to
know
that
each
particular
core
feature
is,
you
know,
is
implemented
by
everyone.
C
I
would
say,
like
the
the
for
this
specific
thing,
that
we're
talking
about
with
all
ports.
The
where
we
have
to
put
the
constructs
is
on
the
listeners.
So
you
can't,
you
know
changing
having
these
port.
C
These
port
ranges
available
will
affect
every
type
of
route,
no
matter
what
no
matter,
what
type
of
route
you're
actually
doing,
because
it
has
to
go
at
the
gateway
and
everybody
has
to
do
some
form
of
gateway,
that's
gateway,
ap,
it's
called
the
gateway
api,
because
the
gateway
is
kind
of
the
core
resource
around
everything
else,
it
spins
and
so
the
I
I'm
getting
to
answer
your
question
the
see
I
think
we
could
absolutely
so
when
we
add
when
we
do
the
stuff
to
add
all
ports.
C
This
stuff
has
been
done
before
in
kubernetes.
This
is
like
pluralizing
a
field
effectively,
there's
a
whole
bunch
of
api
guidelines
around
this,
and
it
can
be
quite
complicated
to
pluralize
a
field
like
port
into
ports
and
then
have
some
special
handle
some
special
case
handling
for
all
ports
and
have
that
be
backwards
compatible.
If
you
already
have
a
singular
port
id
so
adding
something
like
this
probably
is
a
breaking
change
and
we
need
to
that's
why
we
need
to
at
least
have
thought
about
it
now.
C
So
even
just
adding
a
place
to
put
this
information
is
is
a
breaking
change.
It
can
be
a
breaking
change
if
you're
not
super
careful,
if
you,
if
you're,
if
you
if
we
were
to
proceed
right
now,
to
beat
up
with
singular
port
and
then
we
wanted
to
add
something
that
would
allow
you
to
do
a
port
range
say
a
list
of
ports
and
some
mechanics
in
that
list
to
be
able
to.
C
Let
you
describe
like
what
range,
instead
of
just
you
know,
having
to
list
out
all
the
individual
ports,
then
that
doing
that
means
that
there's
a
set
of
rules
you've
got
to
do
about.
C
Well,
you
know,
if
you
have,
if
you
only
set
the
single
port
one,
then
that
then
that
should
be
auto
translated
by
your
implementation,
to
also
mean
you
know
a
set
of
ports
with
one
entry,
and
if
you
set
a
set
of
set
of
ports
one
with
one
entry,
then
then
it
should
be
translated
back
so
that
it's
backward
compatible,
but
that's
only
after
you've
done
the
stuff
to
move
to
beta,
where
there's
a
there's,
a
no
api
breaking
changes
guaranteed.
So
if
we
wanted.
G
G
C
Do
if
we
want
to
do
that,
if
we
wanted
to
just
add
ports
now,
then
it
would
it'll
actually
be
it'll
suck
right
now,
but
it'll
be
much
easier
in
the
long
run,
and
that's
one
of
the
reasons
that
robert
has
raised.
This
is
to
talk
about
it
in
terms
of
actual
use
of
this
cost
and
the
the
you.
I
think
that
it
seems
likely
to
me
that
that
what
john
is
saying
is
100
correct
that
people
who
are
going
to
do
tcp
route
and
udp
route
like
for
udp
routing
use
cases.
C
It
is
extremely
common
that
you'll
need
to
do
around
your
ports.
You
know
cf
rtp,
lots
and
lots
of
udp
protocols
require
you
to
forward
or
or
may
otherwise
make
available
a
range
of
ports.
So
like
it.
I
think
that
asking
people
to
have
implemented
this
when
we
haven't
defined
it
properly
is,
is
sort
of
put
a
cup
for
the
force.
F
Something
sometimes
I
know
just
I
was
trying
to
figure
out
because
you
know
the
api,
should
you
know
abstract
what
the
implementations
are
doing
and
what
is
commonly
supported.
So
I
I
don't
mind
the
range
of
ports
or
or
a
list
of
words,
but
I
want
to
make
sure
that
for
every
feature
that
we
have
to
the
api,
we
confirm
first,
that
the
implementations
that
exist
will
support
it
or
are
planning
to
support
it
or
have
capability
supported.
Because
you
know
it's
one
thing
to
listen
on
the
port
and
many
servers
do
that.
F
Yet
it's
completely
different
to
listen
to
multiple
ports
or
to
arrange
or
to
in
terms
of
implementation.
C
Yeah,
I
I
totally
get
that,
but
I
think
that's
the
the
other
thing
that
you've
got
to
remember
is
that
we
are
kind
of
defining.
The
point
of
this
api
is
to
define
what
implementations
can
support
as
well
right.
So
it's
not
it's
not
just
we're
going
to
take
what
what
implementations
are
going
to
support
we're,
also
about
defining
what
you
like
what
you
can
support
and
so
like
we
need.
C
We,
we
do
need
to
be
able
to
think
a
little
bit
ahead
and
make
sure
that
we're
not
painting
ourselves
into
a
corner
which
is
which
is
where
a
lot
of
the
things
that
we're
doing
are
coming
from
are
coming
from
other
experiences
in
other
parts
of
the
communities
apis
where
people
have
not
have
not
sort
of
made
allowances
for
this
sort
of
stuff
and
have
ended
up
having
to
do
like
big
long,
phased,
roll
outs
and
stuff
that
are
very
painful
and
rob
is
smiling.
C
Because
he's
had
to
do
this
for
a
couple
of
things
now,
personally,
so
yeah,
that's
yeah
I'll
hand
it
over
to
talk
for
a
second.
G
A
Yeah,
it's
incredibly
changed
very
possible.
It's
it's
a
very
good
question.
I
I
think
the
the
oh
we've
had
this
discussion
come
off
and
on
for
a
while
now,
the
last
time
I
think
it
came
in
in
full
force
was
in
as
part
of
our
sig
network
api
review.
When
we
were
going
to
b1,
alpha,
2
and,
and
part
of
that
was
hey.
A
We
really
need
to
have
an
answer
for
this,
as
we
get
to
beta
the
the
the
high
level
themes
that
I
remember
from
previous
discussions,
and
this
one
is
that
it
is
a
desired
use
case
for
at
least
some
implementations.
A
It
is
difficult
to
do
in
a
non-breaking
way
and
it
is
something
that
a
chunk
of
implementations,
a
non-trivial
chunk
just
cannot
support.
So
we
have.
We
have
a
few
conflicting
things
here,
and
this
also
somewhat
goes
up
against
the
li.
You
know,
as
nick
had
mentioned,
we
have
this
idea
of
field
level
stability,
so
we
have
okay.
A
This
is
this
is
something
like
a
support
channel
of
core,
so
everyone
is
going
to
support
this
feature,
this
field
whatever,
but
at
the
same
time
we
have
extended,
and
that's
usually,
what
we
bucket
these
into,
where
this
is
a
little
bit
more
complicated
is
that
this
is
such
a
core
concept.
This
is
this.
Is
the
port
I'm
listening
to,
so
you
can't
just
say:
well,
port
is
extended.
You
know
you,
you
need
some
very
clear
definition
of
what
is
core
functionality
that
we
want
everyone
to
support,
while
also
leaving
some
room.
A
It's
not
saying
we
need
to
add
this
to
the
api
tomorrow.
It's
just
saying
we
need
to
to
graduate
to
beta.
We
need
to
have
a
plan
for
how
we
could
add
it
to
the
api,
and-
and
I
think
that's
that's-
really-
the
work-
that's
required
here-
some
kind
of
plan.
Ideally,
that
plan
is
hey.
We
we
found
this
way
that
doesn't
require
breaking
changes.
A
Maybe
it's
learning
from
upstream,
where
they
just
kind
of
add
a
a
second
field.
That's
extended
and
that's
your
upper
limit,
and
that's
you
know
this
is
this.
Is
your
port
and
it
can
either
be
a
store
starting
point
of
a
range
or
it's
just
a
port.
You
listen
on
and
if
the
end
of
that
range
is
defined,
you
have
a
poor
range
of
you
know
and
just
ideas
right.
So
maybe
there's
a
way
where
we
can
do
this
without.
G
So
rob
I
think
this
directly
relates
to
how
the
networking
is
done,
that
if
you're
doing
a
proxy
of
listing
on
ports
and
sockets
that's
one
way
of
doing
networking,
we
typically
don't
do
that.
We
just
listen,
we
don't
listen.
We
take
all
the
traffic,
we
do
various
cni
magic
because
nick
mentioned
a
couple
of
meetings
ago.
G
F
Sorry,
I
just
want
to
say
yes,
I
agree,
I
mean
we
also
intercept
and,
and
we
could
implement
it,
but
there
are
some
implementations
where
it's
simply
impossible,
because
they
are
not,
I
think,
maybe
external
gateways,
maybe
they're
running
in
a
managed
infrastructure,
and
you
know
so
that's
why
it's
difficult
to
make
it
as
a
core
feature.
F
It's
perfectly
fine
to
have
it
as
an
extension,
and
I
thought
that
the
current
mechanism,
for
extension
I
mean
we
could
attach
you-
know,
policy
to
to
the
listener,
to
say
that
hey
this
listener
intercepts
every
single
or
it's
it's
capturing
a
range
or
other
things.
C
Right,
yes,
I
was
gonna
say
I
think
that
azeroth
says
in
this
case
it's
not
really
very
good
for
policy,
because
it's
such
a
core
part
of
the
api
like
this
one.
We
can't
we
can't
really
use
the
policy
mechanisms
and
stuff,
because
because
it's
such
a
core
so
right
now
so
jeff,
I
have
seen
your
hand
and
I'll
get
you
just
a
sec
right
now.
C
The
way
you
define
a
gateway
is
the
gateway
takes
all
the
listeners
which
are
a
set
of
ports
and
protocols.
That's
what
a
listener
is
and
attaches
them
to
and
binds
them
to
all
the
addresses
that
it's
supposed
to
listen
on
and
that's
what
a
gateway
is.
That's
what
that's,
what
the
object
describes
literally,
and
so,
if
we're
going
to
allow
multiple
ports,
then
that
is
a
significant
change
to
the
thing
and
I'd
like
to
be
clear.
I
think
we
should
allow
reports.
I
think
we
should
have
a
mechanism
to
describe
this.
C
Exactly
how
it
works
is
we're
going
to
be
really
dependent
is
going
to
be
very.
We
need
to
write
it
down
very
clearly
and
we
need
to
write
down
very
clearly
what
happens
if
you
can't
support
multiple
supports.
I
don't
think
it's
complicated.
I
think
that
you
can
say
if
your
implementation
doesn't
support
multiple
ports
and
someone
tries
to
define
it
that
that
just
means
that
your
gateway
is
not
admitted,
like
you
know,
that's
pretty
straightforward
and
so
yeah.
C
That's
that's
what
that's
what
I
think
we
should
do
here
and
that
to
say
and
say
the
thing.
The
thing
that
the
big
change
that
we
have
to
do
is
that
then,
in
order
to
be
able
to
support
multiple
ports,
the
current
acquired
port
field
needs
to
become
optional,
which
is
a
tricky
change
to
make
in
a
non-breaking
way,
and
so
that
one
is
the
one
that
we
might
need
to
do
before
we
go
to
beta.
E
Actually,
I
was
just
gonna
say
basically
what
you
just
said
there
at
the
at
the
end
is
that
you
know
having
ports
is
optional.
F
E
Be
a
good
way
to
deal
with
that.
We've
got
it
for
our
use
case
as
well.
There's
areas
where
we
don't,
we
don't
define
a
port.
So
what
we've
had
to
do
is
we
just
we'll
just
ignore
whatever
it's
set
to,
but
I
think
it
would
be.
You
know
better
for
just
officially.
We
made
that
that
field
optional.
So
you
know,
depending
on
the
use
case,
it
would
be
used
or
not.
A
That's
a
really
intere,
so
it's
good
to
hear
that
others
are
considering
port
optional,
a
good
use
case.
It
would
be
very
helpful.
This
is
issue
818,
john
and
jeff
if
you're
able
to
anyone
else,
who's
interested.
If
you're
able
to
add
comments,
just
explaining
your
use
cases
on
here,
I
think
really.
A
What
we
need
out
of
this
is
again
not
necessarily
to
make
the
api
change,
but
either
to
have
a
clear
path
forward
where
this
is
not
a
breaking
api
change
or
if
it
is
to
make
it
before
we
get
to
beta,
and
so
we
we
need
to
figure
that
out
as
as
soon
as
possible.
So
getting
these
additional
use
cases.
It's
interesting!
A
I'm
really
interested
in
in
your
use
case,
jeff
of
just
an
optional
or
empty
port,
because
you
it
sounds
like.
Does
that
mean
you're
just
listening
on
all
ports
in
that
case
as
well
or
is
it
a
bit
different
for
you.
E
Sometimes
we
were
getting
the
port
assigned
to
us.
Okay
got
it
got
it,
we're
just
asking
for
an
available
port.
C
That
makes
sense,
so
you
still
end
up
having
to
put
the
assigned
port
in
the
status
so
that
you
it's
this.
It
uses
the
same
mechanism
as
we
do
for
addresses
where,
if
you
don't
specifically
request
an
address,
the
expectation
is
that
an
address
will
be
assigned
for
you
and
you
and
you
take
whatever's
in
the
status
and
that's
your
address.
You
take
that
same
mechanism
and
use
it
for
port
yeah.
E
Yep
yeah,
so
carson
just
made
a
comment.
You
know
that
mesh
use
case
he's
right.
That's
where
you
know
we
just
in
certain
use
cases.
We
just
register
us.
You
know
we're
registered
as
a
service
and
and
so
to
access.
You
know,
just
you
look
up
in
the
registry.
E
What,
where
the
address
for
that
port,
yeah,
okay,
okay,
first,
the
port
for
that
key
gateway
service,
yeah,.
C
Yeah,
okay,
so
yeah.
I
think
that
feels
like
a
pretty
logical
extension
of
what
we're
talking
about
and
would
extend
well.
So
maybe
that
maybe
the
answer
here
is
the
thing
we
need
to
do
to
address
the
port
range
in
all
ports.
Use
cases
is
to
make
current
port
optional,
while
we're
at
it
like.
Maybe
we
should
just
put
like.
Maybe
we
should
just
think
about
what
would
I
report
like
a
ports
field?
Look
like
the
you
know.
C
There
are
upstream
examples
already
in
service
for
one,
and
so
maybe
we
should
just
lift
whatever
whatever
service
is
doing,
so
that's
the
same,
at
least
but
yeah.
So
I
think
that
is
definitely
a
pretty
clear
thing
that
we
could
do
that.
C
I
think
I
can't
remember
I
needed
to
look
up
api
changes
doc.
I
think
that
making
a
required
field
optional
is
not
actually
a
breaking
api
change.
A
Yeah,
that's
been
our
practice
so
far
it
it's
usually
something
that's
rolled
out
very
gradually
and
cautiously,
but
we're
going
from
alpha
to
beta.
We
can
likely
do
that
in
one
one.
Rep.
C
A
C
Think
I
think
in
the
case
of
custom,
I
think
the
the
what
we're
talking
about
here
is
not
services
like
services
in
the
like
traditional
senses.
This
is
talking
about
describing
traffic
flows
that
are
for
a
udp
flow,
or
something
like
that
like.
If
you
want
to
run
a
udp
service
inside
kubernetes,
that
does.
D
F
Usually
it's
a
very
large,
larger
rpp
for
for
webrtc
and
all
the
other
stuff,
and
it's
not
fixed,
I
mean
it's
usually
you
know
it's
pretty
much.
All
ports
can
be
assigned
dynamically,
so
it's
a
big
difference
between
dynamic
ports
and
and
listening
on
five
ports
or
even
a
range
of
ports.
It's
yeah
webrtc.
I
think
it
has
about
four
or
five
sports
that
are
used.
C
Yeah
so
I
mean
the
but
the
I
mean
in
terms
of
our
api.
We
only
have
really.
You
know.
We
only
really
have
three
options:
zero,
ports,
one
port
or
as
many
like
an
arbitrary
number
of
ports
like
in
terms
of
api
design.
Those
are
really
our
three
options.
Like
you
practically
I
mean
we
can
put
limits.
If
we
have
like
a
list
in
the
api,
you
can
put
limits
on
how
big
the
list
can
be.
Probably
we
would
want
to
do
that.
C
F
C
F
C
Be
honest:
what
I
have
in
my
head
is
that
you
have
a
list
of
ports
that
that
have,
I
don't
know
if
they
would
have
a
name
or
something,
but
they
would
have
a
string
description
of
the
port
that
can
either
be
a
single
like
the
string
can
contain
either
contain
a
single
integer,
the
word
all
or
two
integers
separated
by
some
separator.
That
would
describe
a
range
like
that
of
the
top
of
my
head.
C
That
is
what
I
would
do
to
handle
all
three
of
the
use
cases
of
those
use
cases,
and
then
you
mandate.
These
are
the
white.
This
is
the
formats
of
the
strings
and
then
and
that's
how
the
api
then
works,
and
we
have
the
validation
that
that
make
sure
that
you
have
only
those
characters
in
there
and
the
behavior
is
prescribed
by
the
api
to
say
that
if
you
define
the,
if
someone
writes
the
ports
in
this
way,
then
that's
what
then.
C
This
is
what
it
means
and
that's
how
that's
what
we've
done
for
the
rest
of
the
api
for
this
sort
of
thing.
Is
that
you
I
don't.
I
don't
see
that
that
we
would
have
the
ports
be
an
integer
that
you
specify,
like
you,
know,
a
thousand
integers.
No,
absolutely
not!
That
would
be
silly.
This
would
be
a
string
that
you
that
has
a
string
that
has
specific
formatting
that
can
be
applied
that
describe
the
different
types
of
things.
E
I
think
when
we
keep
moving
just
anybody
who
has
comments
on
this,
you
just
add
it
to
the
the
open
issue.
Yeah.
C
A
Perfect,
I
am
happy
to
follow
up
with
some
kind
of
doc,
but
I
it
would
be
a
lot
easier
to
write
that
if
whoever's
commented
here,
if
they
could
actually
add
that
comment
on
the
issue,
so
8
18
and
then
I
can
follow
some
link
and
anyone
interested
in
helping
with
the
gap
or
anything
like
that
very
open
to
help
on
this
one
cool.
Well,
we've
got
a
bunch
of
other
things
to
do.
A
I
think
we
could
discuss
this
all
day,
but
I
think
it's
it's
good
to
move
on
to
other
items
here.
So
let
me
move
on
through
the
rest
of
what
I've
added
and
I
think
everything
else
in
this
milestone
is
less
controversial.
I
hope
so.
First
off
we've
got
some
pre-beta
cleanup
tasks.
This
is
one
nick
you
created
you're
on
it.
This
is
just
making
sure
the
web
hook
is
actually
in
a
good
state.
A
I
appreciate
that
I
think
you
may
have
already
added
it
to
the
milestone.
If
not
it's
in
here
now
steve
added
a
suggestion
that
we
should
actually
validate
pathmatch
value
in
our
web
hook.
I
think
our
validation
there
is
not
as
good
as
it
could
be
so
again,
just
that
this
one,
I
think,
is
relatively
relatively
straightforward,
but
will
take
some
time
if
anyone
is
interested
in
volunteering
for
this
or
others.
I
think
this
could
be
a
good,
a
good
starting
point,
a
good
way
to
contribute.
A
A
A
C
A
Yeah
there's
a
few
docs
ones
here,
thanks
mike.
Thank
you.
Thank
you.
A
million
times
I
added
some
more
document.
You
know
you
see
all
these
kind
documentation
ones.
These
are
all,
hopefully
fairly
straightforward.
I
the
one
we
just
talked
about
e2e
testing
for
validating
webhook.
I
think
that's
in
a
good
place
and
finally,
the
v1
beta
1
types
for
resources
that
are
graduating
the
beta.
A
Yes,
so
with
that,
these
are
the
things
I'm
aware
of
that
we
need
to
get
to
before
v1
beta
1.
If
anyone
thinks
of
anything
else
that
we
need
to
get
to
in
this
milestone,
please
let
me
know,
I
think
most
of
us
can
add
things
to
the
milestone,
but
if,
if
you
can't
let
any
of
the
maintainers
know-
and
we
can
yeah
with
that,
any
any
questions
on
this
view
on
my
beta1
milestone.
E
C
You
yeah
there
has
been
a
vigorous
discussion
on
the
right
inclusion
document
about
about
why
why
we,
so
I
think
costing
this
is
yeah.
You
had
quite
a
few
questions
about
about.
Why
we're
looking
at
doing
the
parent
ref
option
rather
than
using
the
existing
sort
of
back
end
thing.
Is
that
what
do
you
think?
That's
a
fair,
some
summation
of
what
we've
been
talking
about.
F
C
Okay,
so
I
guess
the
reason
I
wanted
to
to
have
this
have
a
high
bandwidth
discussion
so
that
we
could
do
this
a
bit
quicker.
So
in
terms
of
so
what
so?
What
do
you
think
would
make
this?
What
would
you
feel
more
comfortable
with?
Would
you
is
it
that
you
would
like
this
to
be
not
a
label
selector
but
to
select
objects
individually.
F
Initially,
at
least,
I
think
it
will
be
a
good
idea
and
I
think
we
can
extend
it
later.
To
add
I
mean
if
we
we
cannot
any
point
out
what
you
propose.
I
mean
to
have
a
a
broad
selector,
but
if
we
start
with
just
explicitly
select
routes,
it
seems
to
be
safer
and
we
can
get
some
feedback
from
the
implementations
and
and
use
it.
C
So
the
reason
that
I
have
been
a
minus
one
on
that
is
that
contour
built
a
http
proxy
object
that
did
exactly
what
you're
talking
about
the
it
it
had
a
parent
of
a
patient
like
we
did
it
slightly
differently.
They
weren't
two
separate
types
of
objects,
but
you
have
a
parent
http
proxy
that
needed.
That
includes
a
child
one
and
it
has
to,
and
you
have
to
name
the
the
child
one.
You
give
it
a
name
and
a
namespace,
and
that's
the
only
way
that
it
works.
C
What
people
found
when
they
were
doing.
That
is
that,
because
it
was
so
specific,
it
meant
that
if
you
ever
wanted
to
change,
if
the
the
owner
of
the
child
one
ever
wanted
to
change
their
resource
or
do
like
a
a
flip
between
resources
or
something
like
that,
then
they
needed
to
have
the
have
the
owner
of
the
gateway
manually
like
edit
their
objects
and
people.
C
F
Yeah,
but
it's
not
the
same
thing,
because
here
is
it's
a
http
route
that
needs
to
be
modified,
so
it's
basically
it's
a
gateway.
It's
listening
on
a
port
and
it's
delegates
to
a
number
of
http
routes,
and
then
each
http
route
may
forward
the
subset
to
different
namespaces.
And
I
I
agree
with
you.
C
F
I'm
sorry
you
know
I
just
want
to
say
I
mean
the
reason,
your
approach,
the
regional
approach,
was
actually
not
bad.
I
mean
it
was
useful
for
for
people
who
care
about
security
and
about
having
control,
because
the
alternative,
that's
probably
the
alternative,
I
mean
it's
it's
it.
You
take
away
control
from
the
from
the
owner
of
the
gateway
that
who
controls
the
namespace,
basically
yeah.
E
You
go
jeff,
I
just
couldn't
say
I
mean
we,
I
think
from
the
expo.
What
nick
said
and
to
be
honest,
I
originally
custom
was
was
kind
of
looking
at
it.
The
way
he
did
when
I
looked
at
how
allowed
routes
work,
you
know
way
back
when,
but
I
think
that
what
nick
said
is
really
true
on
that
is
that
by
just
being
able
to
say
point
at
either
a
label
such
as
the
name
space
in
the
delegation
use
case.
E
I
don't
have
to
you
know,
I'm
telling
this
group
hey
this.
Is
you
know
this
is
the
way
or
this
is
where
you
plug
into
me,
and
you
do
what
you
want
you
know,
so
you
could
you
know
as
the
one
being
delegated
to
they
could
create
one
http
route
they
could
create.
E
You
know
a
dozen
http
routes
and
plug
them
into
the
same
spot
in
my
parent
route,
so
it
just
allows
the
the
team
that
would
be
you
know
or
responsible
for
the
child
is
got
great
flexibility
in
how
they
manage
their
their
piece
of
it.
B
And
also
part
of
the
intention
is
having
the
operator
be
able
to
narrowly
define
that
slot,
where
the
child
route
could
attach
basically
as
narrow
as
they
choose
like
it
could
be
as
wide
as
an
entire
name
space
on
a
host
name,
or
it
could
be
something
like
a
very
specific
specific
path.
Prefix.
B
So
there's
only
like
a
very
small
way
and
then
applying
filters
and
stuff
like
that
too,
to
narrow
it.
So
it's
designed
to
kind
of
yeah
be
flexible
in
that.
C
Way
so
it
is
yeah,
so
I
think
it
feels
like
you
the
thing
that
you're
saying
is
you
feel
like
it's
too
flexible
at
the
moment:
yep,
yep,
okay
and-
and
I
think
that's
that
is
fair.
I
think
the
reason
that
we've
all
ended
up
there,
though,
is
because
so
it's
a
little
bit
so
the
the
other
thing
that
I
think
is
really
important
to
remember
with
this
is
that
we
have
specifically
designed
this
with
a
two-way
handshake.
C
The
other
reason
that
I
wanted
to
do
it
with
the
paragraph
is
that
the
then
that's
the
same
mechanic.
You
reuse
the
same
mechanism
between
koa
and
route
and
route
and
route,
and
so
the
having
that
same
mechanism
means
there's
less
to
learning.
G
C
You're
keeping
the
same
sort
of
descriptors
and
stuff
like
that,
and
it
means
that
the
api
is
just
overall,
more
simple.
I
agree
that
it
means
that
you've
got
this
sort
of
complexity.
At
the
you
know
the
route
to
route
thing
where
you
can
say
where
it's
very
possible
to
have
a
very
wide
open,
you're,
like
it's
very
possible
to
say,
allow
all
namespaces
to
attach
routes
to
me.
But
the
thing
that
we're
trying
to
do
to
manage
that
risk
is
to
say
you
must
specify
exactly.
C
There's
no
default
behavior.
If
you
don't
specify
an
allowed
routes,
then,
and
and
another
route
tries
to
attach
to
that
route
as
a
parent,
it
will
fail,
and
so
there
needs
to
be
a
two-way
handshake
here.
There's
like
with
the
gateway
it
doesn't.
We
do
not
have
that
behavior.
If
you
don't
specify
anything,
then
routes
in
the
same
name,
space
are
allowed
to
request
to
attach,
but
for
for
route
to
route
one.
It
specifically.
C
C
F
Yeah
the
opposite
experience
I
mean
on
easter
side,
for
example,
is
that
by
making
it
too
flexible
and
that's
pretty
much
what
you
do
for
mesh
routes,
we
create
far
more
problems
and-
and
you
know
both
instability
and
and
because
you
know,
if
you
have
you
have
people
typically
attach
you
know,
put
service
entries
and
routes
in
randomly
spaces
and
they
affect
other
namespaces
without
realizing
they're
doing
it,
and
it
created
a
lot
of
problems
for
us.
That's
why
I'm
I'm
very
especially
everything
that
crosses
namespace.
F
It's
a
danger
and
it's
very
hard
to
understand
all
the
implications
of
it.
So
it's
for
for
gator
in
particular,
we
spend
quite
a
lot
of
time
going
over
every
every.
You
know
possible
scenario
and
trying
to
minimize
the
the
this
means
that
the
the
scope
of
this
mechanism,
but
if
we
extend
this
mechanism
to
routes
where
you
can
have
you
know,
attached
policies,
you
can
have
all
kind
of
other
complexities.
E
I
think
I
just
reiterate,
I
think
what
mike
mentioned
earlier
is
the
fact
that
you
know
you're
only
delegating
to
the
child
route,
the
specific
the
traffic
that
meets
the
specific
criteria
that
you
set
at
the
parent.
So
if
I'm
the
owner
of
the
gateway
and
I'm
the
owner
of
that
parent
route-
and
I
want
to
send
you
know,
delegate
some
part
of
the
traffic
processing
rules
to
space
foo.
E
E
Basically,
I
think
the
owner
out
restricts
what
the
child
can
do.
They
can't
mess
with
other
parts
of
the
traffic
besides,
what's
sent
to
them,.
F
How
about
can
we
make
it
a
bit
narrow?
I
mean
not?
Have
a
label
selector
but
just
specify
a
list
of
namespaces,
because
that
at
least
will
will
reduce
a
bit
because
label
selectors
are
the
problem.
Anyone
can
put
a
label,
it's
very
difficult
to
control
which
labels
are
with
admission
controllers,
which
labels
are
allowed.
F
That's
really
the
problem
to
me
that
you
put
label
foo,
I
mean,
except
for
the
ones
that
you
said
where
it's
a
list
of
namespaces
explicit.
You
see
you,
you
selected
a
space
which
is
equivalent
with
what
I'm
asking
for,
if
you
use
any
other
labels,
and
there
is
a
risk
that
people
are
setting
levels
of
namespaces
without
control
and
I
introduce
hacks.
Basically,
I.
A
Think
that
labeling
namespaces
or
any
kind
of
right
access
to
namespaces
in
kubernetes
has
to
be
viewed
as
a
cluster
admin
type
level
access,
especially
with
its
implications
on
network
policy.
Now
I
I
think,
we're
we're
really
copying
in
many
ways
what
network
policy
has
relied
on
here
where,
as
I
understand
that
there's
some
history
on
that
side,
where
again
a
list
of
namespaces
was
also
a
very
interesting
idea
for
them.
Instead
of
a
label
selector
and
instead
I
can
go
someone
who
was
very
involved
in
network
policy.
A
I
came
up
with
this
idea
of
automatically
labeling
namespaces
with
the
metadata
name
label,
and
now
that
we
have
that
we
can
do
you
know
basically
a
list
of
namespaces,
but
plus
you
know
any
other
things
too.
I
I
get
that
it
is
scary
that
it
it
does
allow,
for.
A
F
But
do
we
really
want
this
flexibility?
I
mean?
Is
it
this
kind
of
flexibility
really
required
for
this,
or
can
we
start
with
something
that
is
not
as
flexible
and
figure
out
the
security
implications,
because
again
we
had
plenty
of
bugs
with
and
security
issues
with
namespaces
with
crosstalk
space
security
issues,
so.
C
I
think
there's
so
there's
a
couple
of
things
I
need
to
talk
about,
so
I
think
the
problem
is
that
if
we
put
a
list
of
name
spaces
yeah,
I
think
if
we
put
a
list
of
namespaces,
the
problem
is
that
it's
then
that's
that's
there
forever
right
like
and
then,
if
we
want
to
add
a
selector
as
well,
then
the
how
you,
the
behavior
about
like
how
we
move
from
a
list
of
namespaces
to
a
selector
later,
is
tricky.
You
know,
and
migration
changing
this
later
would
then
be
hard.
C
The
in
this
specific
case,
I
think
mike
put
a
comment
in
the
chat
that
you,
I
think
we
definitely
need
to
have
good
guidance
on
and
say
you
should
almost
certainly
you
should
be
using
kubernetes.metadata
name
unless
you
really
know
what
you're
doing-
and
you
know
using
other
using
other
labels
means
that
anybody
has
permission
to
label
things
can
mess
with
this
conflict.
That
absolutely
should
be
a
call
out
in
the
in
the
documentation
of
this
field.
C
I,
but
you-
and
I
understand
that
what
you're
saying
I
think
that
the
other
thing
that's
relevant
here,
though,
is
you're.
You
are
100
right
to
be
quite
concerned
about
crosstalk
space
references.
We
have,
you
know,
rob
literally
found.
You
know
two
cbees
in
kubernetes
by
us
thinking
about
crosstalk
space,
since
we
are
a
hundred.
E
C
In
agreement
that
cross
namespace
references
are
very
risky,
the
only
way
that
we
that
we
have
been
able
to
come
up
with
to
make
them
better
is
to
say
that
there
must
be
this
two-way
handshake
between
the
owner
of
a
resource
and
whoever
refers
to
it,
and
so
that's
that's
where
the
gateway,
the
allowed
routes
plus
apparent
ref
on
the
child
route
comes
from,
and
that's
also
why,
in
this
api,
we
have
the
reference
policy
for
things
where
we
can't
change
that,
like
service
secret
and
other
kubernetes
kubernetes
objects,
we're
definitely
very
cognizant
of
the
security
risks
of
creating
crosstalk
space
references
and
but
the
only
this
is
the.
C
This
is
the
way
that
we
do.
We
mitigate
those
risks
is
by
saying
by
saying
the
gateway
you.
This
is
a
two-way.
This
is
a
two-way
street.
You
know
the
gateway
or
the
parent
route
needs
to
allow
explicitly,
allow
the
cross
name,
space
reference
and
then
the
parent
and
then
the
child
route
needs
to
create
it.
You
know,
and
that-
and
you
know
like
there's
a
there's-
an
extent
to
which
we
can't
protect
people
from
themselves
too
much
right
like
the
these.
C
The
capabilities
that
are
described
by
the
gateway
api
are
required
by
advanced
users
who
have
a
lot
of
knowledge
and
control
over
their
clusters.
They
need
the
flexibility
I
have
had.
Many
people
come
to
me
on
contour
and
be
like.
I
cannot
use
your
thing
unless
I
get
this
very
specific
knob
to
twiddle
you
know
and
yeah.
I
know
that
you
have
the
same
problem
on
this
year,
like
I
know
that
you
have
you
that
you
have
made
things
very
flexible
on
purpose,
and
that
has
been.
E
No
fine,
you
know
I
just
sense
of
work
we're
over
time
and
I
just
wanted
to
to
make
two
comments
on
the
route
inclusion
thing
one
is
I'm
pretty
seriously
considering
changing
the
conflict
resolution
to
be
fail
at
bind,
but
I
want
to
get
other
people
input
on
that.
E
So
you'll
see
it
coming
in
there
where
nick-
and
I
both
say
nick
nick
says
that's
what
he
he
thinks
we
should
do
and-
and
I
I'm
shifting
my
thinking-
and
so
you
know-
I
guess
it's
I
would
say
if
you
don't
want
it
to
change,
then
speak
up
loudly
in
the
doc
and
comment.
The
other
thing
is,
I
I'm
probably
going
to
try
to
get
this
into
a
actual
formal
gap,
at
least
a
draft
in
the
draft
state,
maybe
by
the
end
of
next
the
this
coming
weekend.
E
C
I
think
so
I
think
the
last
thing
I
want
to
say
there
that
I
think
is
relevant
to
what
costume
is
talking
about
is,
I
think,
one
of
the
concerns
I
feel
like
you
have
customers
like.
If
we
have
this,
then
we've
got
this
really
big
yeah
yeah,
so
we
we
need.
We
do
need
to
still
allow
people
to
do
dangerous
things.
Sadly,
like
I
would
love
to
be
able
to
be
like
now.
You
can't
do
dangerous
things.
You
can't
shoot
yourself,
but
you.
C
My
experience
with
the
kubernetes
api
is
that
sometimes
people
are
like.
Do
I
really
want
to
be
able
to
shoot
myself
in
the
foot
and
they'll
be
really
upset
at
you?
If
you
don't
allow
them
an
opportunity,
because,
sometimes
being
able
to
point
that
gun
straight
at
your
own
foot
is
important
so,
and
we
can't
do
this
with
an
extension
because
of
where
it
sits
so
some
of
the
stuff
we
can't
do
with
the
extensions
because
of
where
it
sits
in
the
api.
We
can
mark
things
as
extended
support.
C
F
I
I
need
to
disagree
with
this.
I
mean
there
are
a
lot
of
things
you
can
do
with
extensions.
It's
not
really.
I
mean
if
we
define
the
next
attention
so
again,
these
you
can
support
this
without
any
changes
to
the
api,
because
by
saying
that
hey
you
just
use
these
two
apis
and
we
keep
the
behavior
we
have
today.
C
The
thing
that
is
important
is
that
that
if
we
change
the,
if
we
change
the
conflict
resolution
as
jeff
says,
then
one
of
the
things
that's
important
to
remember
is
that
it's
expected
that
if
anything
is
weird
about
this
binding
that
it
fails
and
so
like
your
implementations
are
then
free
to
add
extra
rules
on
top
and
just
be
like
hey,
you
tried
to
attach
sorry,
that's
not
supported
you're
like
any.
You
try
to
do
something
that
your
implementation
doesn't
want
to.
Do
you
say
sorry,
I
don't
support
that.
C
We
describe
what
conditions,
what
what
conditions
describe
that
behavior
and
you
and
then
that's
the
way
that
you
can
make
this
more
extended,
like
some
specific
things
extend
to
support,
maybe
maybe
you
just
make
it
so
that
you,
you
still
you're
you're
in
an
implementation
like
no
and
so,
but
the
thing
is:
if
a
label,
if
a
label
on
a
namespace
changes
dynamically,
then
it
will
unattach
like
that's.
You
know
that
is
a
you.
It's
not
this.
This
behav,
the
binding
behavior
is
not.
C
Then
that
is
expected
that
if
something
changes
on
the
name
space
and
the
labels
change
on
the
namespace,
then
the
binding
will
will
start
failing
the
conflict.
You
it's
expected
that
the
the
config
would
be
removed
from
the
underlying
data
plane.
If
the
binding
is
changes
that
it's
removed
but
like
yeah,
that's
the
only.
F
How
about
how
about
we
spend
some
more
time
discussing
looking
at
the
security
implications
and
if
everyone
is
happy
with
security,
because
there
are
also
things
I
mentioned
there
about
attaching
policies
to
the
routes
and
what
happens
if
they
are
combined
and
mixed?
Basically,
if
you
have
some
policy
secretaries
attached
to
a
route
and
then
you
add
another
route
that
is
delegated,
how
does
it
interact
and
other
things
that
probably
need
to
be
addressed
before
we
wait?
Wait,
wait,
wait.
C
Yeah,
okay,
no
problem,
so
I
mean
what
I
would
suggest
boston
is
create,
create
an
issue.
Let's
talk
on
an
issue
about
it,
so
that
we
can
do
this
async,
that's
not
in
a
long
comment
chain
on
on
this
particular
specific
document.
I
think
that
you're
raising
really
great
points
that
we
definitely
need
to
have
discussed.
We
need
to
have
agreement
on
it.
C
A
Well,
hey,
I
think
we
are
past
time.
Thank
you
to
everyone
for
staying
good
discussion
all
around.
Thank
you
to
carson
for
creating
follow-up
issue.
There
are
a
few
different
things
we
can
follow
up
from
this
meeting
and
other
pr's
that
still
need
review.
I
think
richard
your
grpc
route.
Pr
is
ready
for
another
round
of
review.
A
I
left
some
comments,
but
yes,
there
are
other
things.
So
if
you
have
time,
definitely
pay
attention
to
github,
and
with
that
I
don't
want
to
take
any
more
time.
So,
let's,
let's
call
a
meeting
as
it
is.
Thank
you
so
much
everyone
and
we'll
talk
to
you
next
week.