►
From YouTube: [SIG Network] Network Policy API Meeting 20201102
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
B
B
I
put
10
minutes
for
cap
reviews,
but
we
can
take
longer
30
minutes
as
proposed
by
by
edward,
to
discuss
about
the
ftdn
proposal
and
in
the
final
five
minutes.
If
we
don't
get
any
other
subject
to
take
a
look.
If
people
have
seen
the
cube
procedure
proposal
under
the
coupling
and
how
this
is
going
to
impact
in
in
our
soup
subproject
either.
But
we
can,
we
can
make
things
we.
A
B
C
Yeah
I
mean
I,
I
don't
yeah,
I
went
ahead
and
updated
all
the
kind
of
some
of
the
minor
comments,
at
least,
but
then
the
the
thing
I'm
wondering
is,
I
kind
of
want
to
look
again
into
the
virtual
labels
thing
because
it
keeps
coming
up.
C
So
he
brought
it
up
again
and
then
that's
question
number
one
and
then
question
number
two
that
I
have
is
what
we
want
to
do.
As
far
as
that
whole
regex
notation
with
the
star
and
the
I
didn't
really
mind
it
that
much
but
now
I'm
like,
I
don't
really
have
strong
feelings
about
it.
B
So,
in
my
opinion,
I've
I've
also
put
the
it's
like,
because
the
original
proposal
of
namespace,
by
name
and
was
to
have
like
rejects
and
the
part
range-
was
to
have
exceptions
and
we
we
have
removed
the
exception
from
the
part
range
and
the
rejects
from
namespace
by
name.
So
I
want
to
bring
this
up
again
and
and
see
if,
if
we
are
comfortable
with
removing
those
like
those
things
from
the
user
stories
like
in
my
opinion,
I
don't
think
that
like
rejects
is
well.
D
I
I
agree
that
we
probably
don't
want
to
support
regex,
because
security
implications
like
you,
can
create
a
new
space
that
matches
the
regex.
But
I
do
think
that,
like
zhang
brought
up
a
good
point
last
time
around
being
able
to
support
all
name
spaces
in
a
way
so
like
I'd,
be
in
favor
of
you
have
to
specify
either
like
an
actual
name
space
or
a
wild
card.
That
says
online
spaces,
because
I
think,
there's
actual
like
pretty
valid
use
cases
for
being
able
to
select
every
name
space
except
you
know.
C
C
It's
like
it's
kind
of
a
hacky
way
of
implementing
a
global
cluster
scoped
policy,
and
it
feels
I
I
don't
feel
like.
I
I
don't
feel
like.
I
have
a.
I
don't
know
that
arg.
It
doesn't
appeal
to
my
intuition
well
enough
to
write
it
up
like
it.
I
I
like
it
as
an
idea.
I
I
don't.
I
don't
feel
super
comfortable
like
making
a
bulletproof
argument
around
it.
You
know
what
I
mean
like.
I
don't
want
to
exclude
anyone
else
from
making
that
argument,
but
I
feel
like
it.
I
don't
know
what
what
what?
E
Mind
if
I
ask
a
quick
question,
yeah
go
ahead
is
this?
Is
this
for
the
ingress
egress,
like
the
network
policy
selector
like
or
I'm
sorry,
the
name
space
selector
piece
is
that
in
the
same
scope.
E
Well,
so
so
can't
you
use
the
selector
just
to
do
like
a
you
could
do
like
match,
expressions
to
select
all
name
spaces.
Isn't
that
already
possible.
C
G
I
think
the
key
difference
here
would
be
that
the
match
expression
still
works
on
labels.
Well,
what
jay
is
trying
to
propose
is
that
we
would
want
to
match
based
on
names
instead
of
the
labels.
H
So
I
I
I
I
have
a
suggestion
to
say
I
feel
like
we
shouldn't
support
regex,
because
first,
it's
pretty
complicated.
Second,
that
is
existing
now.
Participants,
support
and
eradicates
anyway,
like
for
example,
table
selector.
Doesn't
support
label
rejects
matching,
so
we
don't
need
to
support
that.
If
we
want
to
select
all,
maybe
we
can
just
use
the
way
that
narrow
parts
does
is
to
say
if
you
have
a
match
name
as
a
array,
like
I'm
theory
it
matches
all.
H
Would
that
be
similar
to
say,
okay,
allow
everyone
just
a
quick
way
to
say
that
allow
everyone
would
that
make
sense
here,
just
to
simplify
things.
I
mean,
I
still
don't
see
a
way
to
do
a
reverb
match,
but
since
it's
not
supported,
I
I
don't
know
if
I
actually
couldn't
find
a
good
way
to
support
the
reverse
maximum.
C
C
C
And
it's
not
it
wasn't.
I
don't
know
it
feels
like
most
of
the
use
cases.
People
had
didn't
come
from
that
wanting
to
match
everything
need
it
came
from
for
from
other
issues
like
not
being
able
to
label
certain
things
so
that
they
did
match
a
namespace,
so
they
did
massive
policy.
But
if,
if
the
group
feels
strongly
that
we
should
keep
that
global
selector,
then
I
mean
I
guess
yeah
we
can.
I
can
update
the
kept
to
say
we
want
a
global
selector
and.
D
D
Follow-Up,
unless,
unless
someone
here
like
really
strongly
thinks
that,
like
it's,
it's
required
because
there
is
also
the
caveat
that
like
if
you,
if
you
introduce
the
field
without
supporting
it,
then
you
have
to
deal
with
like
version
sku
and
which
versions
support
wild
cards
and
which
versions
don't
so
like.
Ideally,
when
you
add
the
field,
it
also
supports
it,
but
yeah
like
no,
it's
doable
to
add
it
after.
C
Yeah,
so
zang
is
definitely
in
favor.
I'm
neutral
slightly
negative
andrew
sounds
like
you're
in
favor.
D
What's
the
argument
against
it
again
is:
is
it
that,
like
none
of
the
use,
cases
were
really
like
focused
on
select
like
having
the
catch-all
namespace
selector
anyways,
and
so
it
feels
like
we're
kind
of
just
adding,
like
kind
of
like
sugar,
on
top
of
what
we're
actually
trying
to
accomplish,
I.
C
I
kind
of
feel
like
yeah,
like
you
know,
not
that
I'm
against.
I
feel
like
it's
a
good
trojan
horse
to
put
some
cool
functionality
in
there,
but
I
feel,
like
I
don't
know
if
I
can
make
an
argument
to
do
that.
That's
really
rock
solid,
so
I
mean
that's
a
good
question.
What
is
the
real
argument
for
why
we
need
a
global
match
for
names?
What
is
the?
What
is
the
argument
we
should
make
for
that.
H
H
H
C
A
C
B
G
The
clumsy
way
of
matching
things,
which
I
think
I
would
assume
I
would
assume
that
you
would
write
a
empty
part
selector
in
a
v-name
space
and
have
a
two
two-rule
e-result
for
the
you
know:
match
name
cube
system,
name,
space
and
part
selector,
as
whatever
the
code
dns
body
label
are.
I
would
assume
that
would
be.
That
would
work,
and
but
you
will
have
to
create
a
policy
in
every
name
space
assuming
that.
C
C
A
G
Apply
the
policy
to
all
the
pods,
with
an
empty
selector
and
in
your
ingredients
rule
you
have
a
namespace
selector
with
match,
name
or
whatever
jay
proposes
to
match
the
names,
and
you
include
cube
system
as
the
name
so
that
you
don't
need
to
label
your
namespaces
and
and
then
for
code.
Dns
parts
you
you
have
you
additionally
add
the
part
selector
to
that
namespace,
selector
and
and
match
for
the
code.
E
C
A
D
So
digging
through
the
notes
from
last
time,
I
I
think
the
reason
why
we
introduced
the
wild
card
is
because
we
were
talking
about
it
in
the
context
of
having
an
accept
list.
But
if
we're
not
introducing
an
accept
list,
then
it
had
supporting
the
wild
card
is
the
same
as
putting
in
an
empty
namespace
selector.
So
in
that
case,
then
I
agree
with
jay
that
you
don't
really
need
it,
because
you
can
accomplish
it
with
an
empty
new,
fixed
selector,
anyways.
H
D
C
C
D
C
But
andrew
by
the
way,
welcome
I
didn't
know
the
other
andrew
d.
I
I
I
don't
think
you've
ever
come
before.
So
it's
really
cool
that
they're
helping
us
out.
E
Yeah
I
just
thanks
for
having
me.
I
just
figured
I'd
join
because
seemed
like
the
topic
list
was
relevant
to
some
of
the
problems
that
we've
had
as
of
late.
E
I
work
at
cloudflare,
we
have
some
large
kubernetes
clusters
and
I
maintain
them
so
previously
was
that
red
hat
so
yep.
B
D
Without
trying
to
find
the
tab
where
I
had
it
open,
okay,
you're,
basically
asking-
should
we
basically
what
we
were
just
talking
about
for
namespace
by
names?
Should
we
include
the
exception
right
now
or
later
in.
B
So
I
put
some
some
some
thoughts
up
thoughts
about
that
like
if
we
support
exceptions,
we
need
to
to
make
sure
that
the
exception
doesn't
conflict
with
with
single
parts
or
how
are
we
going
to
deal
with
that
and
if
that's
going
to
be
confused
for
the
users,
otherwise
I
I
don't
know
if,
like
we
are
not
going
to
support
exceptions.
If
everyone
agrees
that
right
now,
we
are
not
going
to
support
exceptions
in
the
port
range
and
if
we
can
move
forward
asking
for
the
review
from
the
catholics
from.
D
B
B
Yeah
yeah,
exactly
so
this
is
this
is
this
is
what
I
put
in
the
comm
in
the
comments,
but
I
have.
I
have
no
strong
opinion
about
that
like
if
this
is
something
that
we
want
to
do
right
now
or
if
we
want
to
to
insert
the
exception
like
as
an
array
field,
or
also
you
ask
it,
if
exception
was
going
to
be
a
port
range
either
or
just.
D
Yeah
I
tend
to
agree,
I
mean
my
understanding,
for
the
original
reason
why
we
talked
about
exceptions.
Is
that
it's
pretty
common
to
like
kind
of
single
out
single
ports
in
large
ranges?
D
D
I
think,
based
on
like
what
the
what
were,
what
the
use
cases
we
gathered
were
like
well
is.
It
is
the
use
case.
Report
ranges
almost
always
like.
I
have
another
cluster
and
I
want
to
allow
all
the
notepad
ranges,
because
if
that's
the
majority
of
the
use
cases,
then
I
agree,
you
don't
need
exceptions,
but
if
a
large
majority
of
the
use
cases
are
around
like
allocating
large
chunks
of
ports
but
they're
kind
of
like
staggered,
then
then
the
two
killer.
B
We
we
have
the
node
part
one
like
if
I
want
to
connect
to
the
node
parts
of
another
cluster,
and
we
have
this
one
that
abshad
pointed
in
the
in
in
the
user
stories
about
a
user
that
wants
to
allow
anything
except
the
connection
to
the
like
to
up
to
the
port
from
the
metadata
server
from
the
google
cloud
or
from
the
aws
he
wanted
to
block
like
you
can
go
anywhere
in
the
port
80s
except
like
I.
I
can't
remember
what
was
the
case,
but.
G
Scroll
down
yeah
this
one.
The
next
comment:
I
think,
that's
exactly
what
he
wants.
This
is
the
one
who
raised
the
issue
that
he
needs
only
port
6379
to
be
blocked
or
not
open.
G
So
I
think
that
is
the
only
use
case
which
we
now
which
we
can
solve
with
an
accept.
But
if
we
propose
just
allowed
quote
ranges
then,
instead
of
writing
a
port
in
in
every
sorry,
instead
of
writing
writing
down
each
and
every
port.
We
do
two
ranges
that
would
be
like
six
thousand
two,
six,
three,
seven,
eight
and
six,
three,
seven,
three,
six:
eight
zero,
two,
nine
thousand.
D
G
D
C
It
looks
good
in
a
previous
is
it
was.
Is
this
the
type
of
thing
that
the
api
server
can
just
validate?
Is
that
what
you're
thinking
I
don't
know
much
about
how
the
api
it
seems
like
you
make
this?
It's
a
synchronous
response
from
the
kubernetes
api
server,
because
it
can
do
some
quick,
math
and
say
you
have
a
you
know.
You
have
a
collision
or
something
like
that.
I
don't
know.
B
Yeah,
but
but
but
in
in
a
single
in
a
single
policy,
you
might
have
like
a
lot
of
port
ranges,
because
ports
is
an
array,
so
I
can
have
like
a
port
range
and
another
port
range
and
those
support
ranges.
They
might
my
my
have
conflicts
and
then
you
might
have
like
inside
one
part
range
an
exception,
but
I
think
that's.
B
B
D
B
Yeah,
I
think
it
would
be
great,
so
we
can
like
we
can
spare
some
time
in
the
reviews
and
and
make
this
move
forward.
But
if,
if
you
cannot
move
this
here,
like
also
too
so
we
can,
we
can,
we
can
keep
things
going.
I
think
it
would
be
great
to
discuss
this
in
the
game's
lag
like
have
a
trading
dislike
or
of
how
we
are
going
to
validate
that.
I
B
G
B
G
One
quick,
you
know
with
respect
to
the
portrait.
I
think
I
I
had
an
action
item
from
last
week
to
because
in
in
the
dan
I
think
mentioned
that
their
ovs
based
plugins
may
have
an
issue.
So
I
I
did
some
you
know
digging,
and
you
know
some
of
the
folks
on
entry
side
are
also
trying
to
solve
it
in
this
fashion.
G
A
G
Validated
against
just
or
matched
against
just
that
one
particular
port
number,
but
you
could
also
do
some
sort
of
a
mask
for
a
bit
wise.
I
think
the
documentation
gives
a
good
example
and
explanation
on
how
to
use
it,
and
if
you
use
a
port
with
the
mask,
is
basically
meant,
for
it's
basically
meant
for
allowing
a
port
range
to
be
matched
so
so
it
should
not
be
too
difficult.
G
I
think
the
only
thing
that
the
cni
providers
would
have
to
do
is
convert
a
given
port
range
from
integer
to
to
a
slash
mask
in
the
bitwise
form.
So
so,
if.
G
G
Good,
this
is
just
the
field
in
obs,
so
when
you're,
when
you're,
creating
an
open
flow
rule
for
matching
on
a
rule,
instead
of
setting
tcp
dest
equal
to
the
port
number,
you
set
tcp
desk
equal
to
the
port,
slash
mask
in
you
know,
hex
format
or
so
it's
this
is
this
is
this
is
actually
the
card.
G
This
is
mainly
for
the
cni
vendors
who
have
open
v-switches
or
that,
as
a
data
blame
for
them
to
like
that,
right.
B
I
saw
that
I
remember
the
the
the
issue
of
cube
rocks
with
fully
random
that
that
then
windshield
digging
to
to
see
like
the
the
bitwise
mark
from
the
iv
tables
mango-
and
I
said,
okay,
I'm
not
going
to
to
to
say
like
to
the
cni
providers,
how
they
are
going
to
do
that.
I'm
just
going
to
say
it's
possible,
but
I
can
even
understand
what's
happening
here.
G
And
I'm
pretty
sure
there
are
some
open,
v-switch
libraries
already
in
go,
which
which
does
this?
Where
you
you
just
supply
a
range
for
integer
format,
and
it
will
give
you
the
the
bitwise
mask
port,
slash
mask
for
it.
This.
B
G
Looked
at
that,
but
but
I
I
think
anyone
who's
programmed
in
openvis
should
should
probably
be
okay
with
this.
B
C
E
For
users,
in
that
api
previously
doesn't
like
inhibit
your
ability
to
re-encode
that
in
like
a
hexadecimal
representation
like
it,
this
is
these
values
are
all
the
same.
There's
just
different
encodings
like
do
we,
we
don't
have
to
show
the
hard
hardest
encoding
on
the
front
side.
I
guess
yep.
E
Well,
once
you
start
talking
about
trying
to
mask
those
values,
then
having
them
and
like
decimal
integer
becomes
way
more
difficult
right,
like
a
lot
easier
to
see
at
mass,
when
you
have
the
hex
bit
field,
but
it's
still
again,
you
know
the
same
whether
you
encode
an
integer
or
not
right,
like
just
semantics,.
B
E
E
C
E
D
C
I
would
not
mind
look
like
reading
a
proposal
about
this
at
all,
like
I
totally
it
would
be
really
interesting
to
read-
and
I've
said
this
before
I'm
a
big
advocate
of
us
exploring
things
in
this
group.
Sometimes
that
may
not
be
super
useful.
So
even
if
we
chose
not
to
do
it,
I
think
it'd
be
cool
to
see
a
proposal
around
it
and
maybe.
B
F
G
B
So
for
the
port
range,
I'm
going
to
add
again
the
exceptions
and
abstract
nodes
in
the
drawback
that
there
is
already
the
implementation.
I
think
that
we
can
move
forward
right.
I
I
I
expect
like
we
can
discuss
about
the
validation
in
the
in
slack
during
this
week,
and
I
I
want
to
try
to
close
this
like
in
the
next
cycle
and
ask
for
the
for
the
sea
leads
the
the
review
of
this
one
and
also
jay.
C
B
D
For
the
namespace
by
name
one,
I
think
one
of
the
action
items
for
jay
was
to
like
double
check.
If
match
names
under
namespace
selector
is
going
to
be
a
breaking
change.
Did
we.
C
I
had
the
old
implementation
with
that,
but
then
I
was
going
to
re-do
redo
it
with
whatever
we
come
up
with
after
today,
so
I
don't
yeah.
I
need
to
redo
all
that
and
I
never
finished
testing
the
original
one
I
did
so
that's.
I
have
to
do.
D
C
Yeah,
the
thing
we
don't
want
to
break
is
just
so
I
can
bound
what
I'm
trying
to
accomplish
there
you're
concerned
about
breaking
the
client.
The
go
client
right.
D
Yeah
so
so
I
think
there's
two
layers
of
compatibility.
We
need
to
worry
about,
like
the
actual
like
round
trip
like
json
serialization,
on
the
api
like
if
you,
if
you
wrapped,
like
namespace
selector
under
you,
know
like
another
struct
and
put
namespace
selector
as
a
or
label
selector.
As
like
an
inline
field.
D
Does
that
break?
Like
you
know,
json
serialization?
I
don't
think
it
will,
but
we
should
really
double
check
that,
because
if
we
accidentally
broke
that
it'd
be
really
bad
and
then
the
other
layer
of
compatibility
is
if
we
wrap
the
label
selector
under
new
struct.
That
breaks
like
compile,
compatibility
or
like
go
compatibility
and
I'm
not
sure
like.
I
don't
think
we
have
defined
rules
on
when
we
are
allowed
to
break,
go
compatibility.
D
C
Yeah
I
checked
on
that,
and
there
was
some
somewhere
some.
I
think
it
was
dan
winston
mentioned
in
writing
that
we
don't.
The
only
thing
we're
required
to
not
break
is
the
yaml
and
the
json.
I
don't
have
a
reference
to
that,
though
I
can
try
to
see
if
I
can
find
the
reference
to
that.
C
Nesting,
the
name
name
field
inside
the
map
is
the
thing
I
I
just
I'll
just
build
and
see
if
see
if
it
compiles
and
works
properly,.
C
B
Great,
so
we
we
have,
we
have
a
last
a
last
subject
about
those
running
cabs
and,
and
then
I
want
to.
I
want
to
check
with
the
the
clusters
called
network
policy
group
how
they
are,
but
about
about
this
android.
Then
then,
post
that
in
the
past
we
have
not
used
feature
gates
for
new
network
policy
features.
B
D
My
last
name
yeah,
you
do
need
to
feature
last
time.
I
checked
so
it's
true
that
in
the
past,
when
network
policy
was
initially
introduced,
we
didn't
futuregate
fields,
but
the
guidance.
I
don't
know
when
this
guidance
was
added,
but
the
guidance
now
for
any
new
api
api
is
added
to
a
stable
or
any
new
fields.
Added
to
a
stable
api.
D
C
D
B
C
I
mean
I
feel
like
we
need
to
do
a
whole
api
configuration
because
some
of
us
are
using
the
api
stuff
anyways.
So
I
I
definitely
don't
think
the
final
like
polished
version
of
this
for
sure,
but
I'll
I'll.
I
guess
I'm
just
going
to
add
back
in
that
we
are
going
to
do
a
feature
gate
yeah.
Maybe
you
can
just
enter.
If
you
want
to
just
add
that
reference
in
there,
then
we.
B
G
Actually,
I
do
not
have
any
update
because
we
cancelled
last
week's
meeting
because
of
the
ebps
summit.
Some
of
the
team
members
are
busy.
B
B
K
K
Thank
you,
ricardo.
So
a
quick
update
on
this.
I
actually
like,
went
through
all
the
comments
by
the
way,
first
of
all,
whoever's
on
the
line,
and
you
know
everybody
else
not
online.
Thank
you
for
the
comments,
and
this
is
probably
you
know,
made
me
sort
of
think
about
this
in
you
know
10
odd
ways
that
I
never
sort
of
thought
about.
So
this
is
amazing.
K
What
I
did
was,
I
went
sort
of
you
know,
line
by
line
through
each
of
those
comments,
and
I
put
a
if
you
scroll
down
ricardo.
I
put
a
section
of
open
questions
at
the
very
bottom
and
this
is
effectively.
You
know
capturing
all
of
the
open
discussions
in
the
comments
which
I
didn't
sort
of
resolve
and
they're
still
there.
But
you
know
this
way,
I'm
hoping
to
just
sort
of
summarize
all
of
the
answers
that
we
come
up
with
and
document
them
here.
K
So
the
idea
would
be
you
know
there
have
been
several
questions
around.
What
is
the
guarantee
that
this
feature
will
offer
right,
and
you
know
I'm
not
even
getting
the
implementation
specifics
but,
like
you
know
what
kind
of
semantics
should
it
offer?
You
know
what
what
sort
of
is
it
a
convenience
thing
or
is
it
an
accuracy
thing?
Is
it
an
l7
thing
or
you
know
another
policy
thing,
and
so
there's
been
some
like?
You
know,
identity.
K
You
know,
crisis
sort
of
questions
here
and
for
what
it's
worth.
I
still
think
this
is.
This
is
a
very
sort
of
valid
use
case
from
a
convenience
standpoint
and
what
I'm
doing
right
now
is
going
through
some
of
the
existing
policy.
You
know,
implementations
and
we're
sort
of
figuring
out
what
the
minimum
viable
product
would
be
here
like
what's
the
minimum
viable
specification.
K
So
what
I'm
thinking
here
and
I
would
love
some
feedback
from
you-
know
the
folks
on
this
line.
You
know,
andrew
especially
since
you
know
you
and
I
chatted
about
this
a
little
bit
as
well.
You
know,
let
me
know
what
your
thoughts
are,
but
what
I'm
thinking
is
we
do
egress
only
and
we
you
know,
for
the
sake
of
simplicity,
don't
do
any
pattern
matching
and
all
of
the
guarantees
are
effectively
rooted
in
the
dns
implementation.
K
So
this
policy
by
itself
will
not
it.
You
know
it'll
only
be
a
convenience
facade
on
top
of
whatever
dns
truth
is
available.
If
some
part
is
able
to
bypass
the
dns,
pods
or
service
to
get
ip
addresses
to
a
certain,
you
know
a
url
or
fqdn,
then
that's
not
something
we
can
cover.
I
think
there
was
a
comment
about
this
in
one
of
dan's
comments.
K
I
think
said
that
that's
okay,
but
I
I
would
like
to
be
sure
so
I'm
trying
to
see
if
that
that
is
a
good
mvp
definition,
of
course,
I'll
document
that
here,
but
it's
not
going
to
be
implementation
specific.
It
is
just
going
to
be
an
api
recommendation,
just
like
never
policy
and
it'll
be
up
to
the
providers.
You
know
cni
providers
to
implement
their
own
versions
of
that
api,
just
as
we
do
today.
K
My
apologies,
which
part,
did
I
lose
you
at?
I
guess
maybe
I
should
start
there.
D
K
Correct
yeah,
because,
since
some
of
these
you
know,
providers
already
have
like
fqdn
support
in
whatever
way,
shape
or
form
they
could
just
as
easily
prescribe
the
fact
that
hey
look.
We
already
have
this
in
our
object
or
whatever.
So,
if
you're
using
rcni,
you
can
continue
to
use
it
for
the
same
guarantees
or
whatever,
and
they
don't
have
to
use
a
new
form
of
doing
the
same
thing
or
they
could
simply.
You
know,
write
a
wrapper
and
have
that
api
and
go
into
another
implementation.
K
D
One
of
casey's
comment
was
that
we
shouldn't-
I
don't
know,
I
don't
know
if
we
all
agree,
but
what
he
said
was
that
we
shouldn't
add
things
to
the
api
that
we
don't
think
every
cni
provider
will
want
to
implement
like
either
either
as
like
part
of
their
own
crd
or
like
in
general.
They
don't
want
to
implement
it
at
all.
So
are
we
saying
that?
K
Oh
no,
this
is
actually
that's
actually
a
good
point.
I
think
now
we're
gonna
get
into
some
of
the
oh
sorry
about
that.
We're
gonna
get
into
some
of
the
implementation.
Specifics.
I
think,
to
your
point
andrew.
It
might
be
easier
to
implement
this
as
a
standalone
crd
object
or
something
like
a
dns
policy
object
or
whatever,
and
and
that
way
it
gives
you
the
freedom
it
gives
the
cni
provider
the
freedom
to
do
whatever
with
it
right.
B
B
So
if,
if
we
had
this
field
as
a
just
just,
supposing
that
we
had
this
field
as
a
network
policy
team
and
and
having
like
a
compatibility
matrix
of
which
cni
supports
which
fields
from
the
network
policy,
that's
a
that's
only
a
supposition,
I
think
that
it,
it
might
also
work.
I
I
I
understand,
like
casey,
casey
concerns
about
that
because,
like
how?
B
I
wouldn't
say
that,
okay,
we
will
do
do
we.
We
won't
support
fields
here
in
the
api
that
cni's
doesn't
doesn't
support.
I
I'm
I'm
not
like
I'm
not
strongly
against
that.
I
just
think
that
we
need
to
have
mapping
like,
or
even
the
cni's
have
mapped
with,
which
which
sort
of
features
they
support
or
not.
Otherwise,
we
are
going
to
block
anything
like
okay.
B
K
Is
that
is
that
a
question
for
me:
yeah
yeah
yeah?
Yes,
so
what
I'm
suggesting
is
that,
since
this
is
not
a
you
know,
we're
not
we're
never
going
to
be
able
to
inspect
the
packet,
you
know
the
payload,
I
should
say
we
will
not
know
what,
like
you,
know,
url
it's
going
out
to
so.
K
The
only
thing
we
can
do
is
look
at
the
ip
addresses
from
narrow
policy,
so
it
just
seemed
like
the
most
reasonable
thing
to
do
is
to
use
the
guarantee
that
the
dns
service
provides
and
that's
the
best
we
can
do
so.
If
that
means
that
you
know,
somebody
already
has
some
cached
ip
addresses
that
still
point
to
an
fqdn,
but
they
never
made
a
dns
request.
K
We
can't
really
protect
against
that
using
this
this
tool
so
yeah,
it's
not
it's
not
airtight.
C
It
seems
like
if
you,
if
you
go-
and
you
say,
you're,
going
to
change
an
api
and
you
don't
you're,
not
really
100
sure
that
the
cni
providers
are
going
to
support
you.
There
yeah
that's
kind
of
a
weak
position,
but
if
you
go
in-
and
you
say
well,
I
kind
of
want
to
make
this
api
up,
but
at
the
same
time
I
kind
of
have
a
canonical
implementation
in
mind
that
isn't
dependent
on
any
one
cni
provider
which
you
have
in
this
document.
Right,
like
there's
an
implementation
that
people
have
suggested
here.
We
can.
I
C
That
thing
exists.
That
thing
is
complemented
by
a
crd,
and
it
seems
to
me,
like
that's
an
iteration
towards
this.
It
may
be
wildly
successful
and
then
people
will
say
we
got
to
get
this
thing
into
the
api.
But
even
if
it's
not
wildly
successful,
I
think
you've
got
something.
You've
got
a
useful
tool
there.
I
think
that
some
people
would
probably
use
and
that
you
maybe
even
be
able
to
use
right.
C
Yeah,
the
crd,
where
we
literally
do
the
implementation
that
dan's
talking
about
right
there
where
you
just
have
to
plug
in
and
then
you
yeah
and
you
get
an
operator
that
makes
network
policies
under
the
hood
I
mean
exactly
yeah,
that's
the
whole
thing
right
there
who
needs
cni,
who
needs
to
see
an
ipad.
I
hate
to
say
it,
but
who
needs
to
see
an
ipa
if
you're?
Okay
with
that
solution,
we
can
build
that
solution.
Right
like
we,
don't
need
to
see
an
ipod.
K
Totally
yeah
exactly
so,
in
fact,
that's
that's!
Really
the
mvp
you're
you're
hitting
the
nail
on
the
head
here
that
that
was
my
intent
when
I,
when
I
went
through
all
of
this,
and
I
realized
that
you
know
this,
you
know
what
what
do
we
need
to
actually
do
in
order
to
demonstrate
value
and
and
really
make
sure
that
this
is
getting
iterated
on
instead
of
just
like
a
giant
vlog
that
sits
there
and
we
can't
really
address
it.
K
What
you're
saying
is
exactly
what
I'm,
what
I'm
suggesting,
which
is,
let's
just
do
an
mvp
where
we,
you
know,
rely
on
the
dns
semantics
as
much
as
possible.
Whatever
guarantees
the
dns
service
makes
that's
exactly
what
we
can
offer
and
that's
about
it,
and
we
can
use
the
crd.
No,
no
fast,
no
must
about
like
changing
the
existing
api
doesn't
have
any
consequences
on
the
existing
providers,
and
then
you
know
if
it
has
a
huge
uptake.
K
Yeah
or
you
can
do
that,
I
just
don't
know
what
kind
of
dependencies
will
require
from
the
dns
service
and
whether
that
will
be
sort
of
a
hey.
Now
I
need
to
plug
in
for
core
dns
or
cloud
dns
or
cube
dns.
Or
what
have
you?
So
that's
why
I
was
trying
to
centralize
it
as
much
as
possible
that
you
know
if
you
have
another
policy,
you
can
count
on
some
ground
truth
that
you
know
it's
enforced,
whether
it's
ip
tables
or
whatever
it
doesn't
really
matter.
K
You
know
it
follows
those
semantics,
so
that
was
that
was
my
only
thing,
but
your
point,
andrew
you're,
absolutely
right.
You
know
we
could
even
short
circuit
that
even
further.
C
C
Yeah
well,
this
is
my
thing
that
nobody
likes
my
idea,
but
my
idea
is
that.
C
B
A
B
I
don't
I
agree
that
that's
that's
we
don't.
We
don't
have
to
block
our
our
stuff
like
if
we
have
something
that
that
one
cni
doesn't
want
to
support
because
it's
yeah,
you
know
what
I
mean
like.
C
Well,
the
the
funny
thing
is
that
once
you
go
down
this
crd
road,
everything
we're
doing
could
be
done
with
some
kind
of
a
controller
operator
type
thing,
and
so
that
that,
even
though
I
I
don't,
I
don't
think
I'll
ever
get
a
whole
lot
of
agreement
on
that.
But
I
mean
it
just
keeps
it
keeps
hitting
us
right
like
the
fact
is
like
even
the
namespace's
name,
you
can
build.
So
once
you
start
building
an
operator
controller
thing,
it
might
allow
us
to
explore
other
problems
that
are
out
of
scope
of
cni's.
A
K
Yeah
no,
I
mean,
I
think,
that
we
always
get
into
these
conversations,
because
we
don't
have
a
default
implementation
in
our
policy.
Unfortunately,
I
don't
know
if
we're
ever
going
to
cross
that
bridge,
but
hey
I
don't
know
in
the
in
the
you
know,
interest
of
sort
of
you
know
making
progress
on
this
and
figuring
out
what
the
mvp
looks
like.
I'm
I'm
more
inclined
to
now
just
sort
of
go
down
the
path
of
having
a
crd,
having
a
controller
that
monitors
the
or
snoops
the
dns
traffic
and
configures.
K
Never
policies
you
know,
keeps
them
up
to
date
as
much
as
possible.
So
I
think
we'll
discover
some
nooks
and
crannies
there
that
need
to
be
addressed
based
on
the
you
know,
antics
of
the
dns
service
and
we'll
sort
of
address
them
as
we
go
along
in
the
controller.
K
I
suppose
you
know
it
would
be
great
to
have
any
you
know,
expertise
on
this
if
somebody's
in
dns
ninja,
please
let
let
me
know
and
be
happy
to
you
know,
chat
with
you
but
honestly,
like
we're,
trying
to
figure
out
how
we
can
get
an
implementation
out.
So
if
anybody's
interested
in
sort
of
maybe
I'll
propose
a
you
know,
dns
policy
spec
in
this
document
as
an
mvp,
and
then
people
can
comment
on
that
and
then
we
can
take
it
from
there.
Yeah.
D
K
Yeah,
I
just
you
know
personally,
I'm
full
disclosure,
I'm
not
not
an
engineer
on
cue.
You
know
kubernetes,
I'm
a
product
manager,
so
my
my
knowledge
of
how
source
source
space
works
in
kubernetes
is
limited.
So
you
know,
if
I
I
don't,
I
can't
anticipate
how
many
changes
and
surgical
things
will
have
to
you
know
make
in
the
dns
service
itself.
So.
D
B
K
You
know
funny
funny
story
ricardo.
I
used
to
be
an
engineer
at
google,
but
then
I
don't
know
I
moved
to
the
dark
side.
B
Okay,
so
we
are,
we
are
we
are
out
of
time.
I
would
like
just
to
suggest
you
to
take
a
look
into
this
cat
from
of
him
working
q,
proxy
architecture.
I
think
that's
it
might
hit
us
somehow
or
like
with
good
ideas.
Are
we
with
some
sort
of
re-architecture
of
things?
There
is
some
some
some
ideas
of
like
having
a
a
a
generic
implementation
of
q
proxy.
That
calls
like
even
the
same
way
that
cni
does.
I
think,
as
we
have
moved
forward
with
the
ftdn
proposal.
B
C
Yeah,
so
if
anybody
wants
to
own
a
story
that
would
be
cool,
we're
looking
to
get
involved.
If,
if
there's
something
you
really
care
about.