►
From YouTube: Network Policy API Meeting 20210913
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
Hello,
everyone
today
is
september
13th
2021.
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup,
2
sig
network.
This
is
a
cncf
certified
meeting,
so
please
be
kind
everyone
and,
let's
all,
have
a
productive
time
today.
So
first
things
first
issue
triage
nothing
new.
I
think
incoming
issue
account
to
sig
network
has
been
pretty
low
overall,
so
not
much
to
talk
about
there.
There
is
a
issue
ava
check
that
one
that
was
open
against
network
sig
network
policy
api
to
import
some
legacy
documentation.
A
It
was
the
issue
you
opened
to
do
this,
and
kudan
did
a
first
pr
stab
at
it.
Have
you
talked
to
him
since,
or
is
this
kind
of
a
stale
pr?
No,
I
think
I
did.
A
Yeah,
I
guess
we'll
give
it
another
couple
weeks
and
see
if
he
gets
back
to
us.
If
not,
we
can
look
at
taking
it
over
ourselves.
The
one
glaring
thing
I
saw
was
that
the
gifts
from
the
original
repo
weren't
imported
and
those
are
really
helpful.
So
that's
just
a
small
thing
that
I
wanted
to
talk
about,
keep
an
eye
on
it.
A
Cool
okay:
let's
spend,
let's
save
cmp,
I
think
for
last
and
jump
straight
over
it
for
now
to
the
network
policy
status
cap.
So
ricardo
opened
this
back
up
for
us
and
he
does
not
have
the
bandwidth
to
take
it
on.
So
I
think
we're
gonna
need
to
kind
of
spread
out
and
find
someone
to
own
this.
A
C
I
I
can
actually
help.
I
just
can't
do
everything
by
my
own
here
folks.
I
know
that
so
just
just
to
put
some
some
some
history
about
that.
What
happens
is
that
we
we
we've
got,
we
we've
got
the
end
part
feature
going
on
and
on
past
we
already
got
some
other
features
that
we
we
wanted
to
implement
and
and
see
the
the
production
readiness
reviewers.
C
They
have
asked
before
graduating
and
part
to
ga
to
have
a
way
to
know
how
many
people
is
actually
using
that
feature,
or
I
I
mean
if
everything
is
going-
fine
and
cni,
providing
some
feedback.
Some
metric
feedbacks-
and
I
have
richard
tim
about
that
because,
first
of
all
I
I
think
I
I
understand
their
feeling,
but
it's
it's
not
the
same
as
adding
like
a
metric
from
some
internal
component
in
kubernetes.
C
But
it's
something
like
I
would
have
to
go
to
each
of
the
cni
implementations
and
say
hey
so
now
we
have
this
status
view.
Then
you
should
probably
add
your
feedback
here
for
the
users
and
we
would
need
to
define
a
standard
for
that
and
some
sometimes
the
standard
for
one
doesn't
doesn't
doesn't
feel
right
for
the
other
one,
and
so
so
what
I?
What
I
asked
a
team.
It
was
something
like
hey.
Okay,
I
understand
that,
but
we
should
probably
keep
this.
C
This
simple
right
in
a
sense
that
cni's
can
provide
the
feedback
and
a
user
can
know
if
something
was
implemented
or
not,
and
tim
proposed
that
we
did
add
some
some
sort
of
a
tuple
like
was
the
cni
name,
description
and
message
and
leave
the
cni's
to
add
any
message
that
they
want.
So
I
know
that,
for
example,
calico
can
process
the
rules
and
turn
the
rules
into
internal
calico
structure
and
say
hey.
C
I
could
do
that
or
I
couldn't
do
that
so
adding
some
some
something
like
I
have
processed
these,
and
this
is
what
I
understood
from
this
network
policy,
for
example
right.
I
know
that
we
could
do
something
like
that
for
andrea
as
well.
What
we
shouldn't
be
doing,
in
my
opinion,
is
something
and,
and
leaving
that
really
clear,
is
something
like
yeah.
This
network
policy
was
implemented
or
not.
This
network
policy
is
implemented
in
a
node
or
not
this
network
policy,
because
it's
gonna
be
turn
stuff
really
hard.
C
So
I
think
that
we,
we
should
probably
seek
into
something
simple
like
saying:
cni
could
parse
this
or
not
using
this
specific
api
version
or
not
right.
So
we
can
even
add
that
to
status,
saying,
hey
dcni
is
using
this
kubernetes.
This
kubernetes
client
version
can
be
a
json
can
be
anything
I
don't
know
so
I
I
was
actually
expecting
also
team
tim
hawking
to
take
a
look
into
that
and
say
what
he
thinks
about
that.
C
C
I
think
we
can,
but
the
problem
is
that
doing:
let's,
let's,
let's,
let's
make
an
exercise
here.
So
imagine
that
you
are
a
cni
that
doesn't
doesn't
recognize.
For
example,
the
end
part
field
right
and
someone
puts
the
end
part,
but
from
your
side
as
you
don't
recognize
that
you
are
going
to
simple
to
drop
that
field.
So
you
still
process
that
that
feel
that
that
that
rule
that
policy,
but
it
didn't
process
it
the
the
the
end
part
one.
C
So
your
feedback
is
partially
right
because
you
could
process,
but
you
didn't
say
what
what
you
got
from
that
right.
So
no.
D
D
C
How
can
the
cni
know
that
it
didn't
process
it
correctly,
a
rule
if,
for
that
cni,
for
example,
import
fuel
doesn't
exist
right,
so
the
the
it's
using
an
old
kubernetes
library
and
that
that
old,
kubernetes
library
doesn't
have
on
on
the
type
spec
the
end
part,
so
it
got
the
it
got
the
the
rolling
process
it
processed
the
rule,
so
it
it
don't
know
about
the
end
part
the
input
field
right.
C
D
D
D
C
Yeah,
but
here
here
is
the
problem.
So
so
here
is
the
problem.
Network
policy
was
already
on
v1
when
we
added
and
part,
and
we
didn't-
we
didn't
incremented
network
policy
version,
for
example,
from
v1
to
v1.1
or
v1
or
v2
right,
so
the
object
for
that
one
is
still
v1.
No,
no
conversion
happens.
C
C
It
just
does
doesn't
know
the
the
end
part
field
inside
v1.
So
in
past
then
then
wrote
like
a
cab
about
micro
versioning,
but-
and
I
remember
him
presenting
that
on
on
on
some
c
network
meeting
or
something
like
that.
But
the
discussion
wasn't
wasn't
positive
in
a
way
of
saying
yeah.
We
really
want
a
micro
version
inside
like
a
major
version
of.
D
So
one
quick
question
is
endport
is
an
import.
The
only
field
that
was
new
post
v1
definition
is
endport.
The
only
change
in
the
api
since
the
v1.
B
B
I
had
like
a
you
know
when
dan
had
originally
introduced
that
versioning
and
status
kept
what
I
was
thinking,
how
we
could
implement
this
was,
and
we
can
shoot
this
idea
down.
Is
you
know
we
have
like
this
in
status?
A
lot
of
statuses
for
resources
are
implemented
as
conditions.
B
So,
for
example,
you
can
look
at
deployment
conditions,
spot
conditions
and
all
those
kind
of
things.
So
I
was
thinking.
Maybe
we
also
do
something
similar
where
we
have
like
network
policy
status,
which
is
you
know,
a
list
of
conditions,
network
policy,
network
policy
conditions,
and
then
each
of
those
conditions
are
actually
very
well
defined,
and
that
is
there
is
a
condition
type.
There
is
a
reason,
a
message
and
and
and
of
condition
value.
So
the
condition
type
is,
let's
say,
feature
not
supported,
and
then
the
value
is
always
a
boolean,
true
or
false.
B
B
If
the
feature
is
not
supported
within
the
network
policy,
then
you
set
the
value
to
true
and
within
within
the
reason
or
the
the
message
you
have
the
more
verbose
information
that
the
cni
provides.
For
example,
end
port
feature
is
not
supported.
The
policy
will
be
created
with
blah
blah
blah
without
the
importance,
so
so
this
is
how-
and
this
is
a
list-
this
is
a
list
of
conditions.
So
that
means
that
this
is
extensible
tomorrow
you
could
add
a
new
condition
to
it.
B
So,
for
example,
like
you
know,
for
whatever
reason,
you
need
like
a
separate
condition,
apart
from
the
feature
not
supported
network
policy,
realized
or
unrealized,
true
false,
and
then
you
can
add
new
conditions
without
having
to
change
the
status
api
all
together.
So
that
is
how
I
thought
we
can.
We
could
have
done
that
in
the
past
or
at
least
in
the
in
the
cap,
and
I
think
it's
simple
enough,
because
you
know
there
is
a
lot
of
precedence.
B
Every
resource
in
kubernetes
has
conditions,
there's
a
proper
guideline
on
how
to
write
status
conditions.
If
there's
a
there's
a
page
for
that.
So
so,
and
then
each
of
those
fields
are,
you
know,
very
defined,
so
we
won't
be
the
first
ones
to
implement,
but
I
can
also
forward
the
the
link
to
that
conditions
page
on
how
to
define
those
for
statuses.
D
D
If,
if
the,
if
the
api
server
process
power
provides,
let's
say
an
end
port
and
the
cni
does
not
know
that
is,
is
does
the
cni
not
even
get
that
object
in
the
json
or
the
cni
will
get
that
object
in
the
json?
It
will
just
ignore
it
because
it
did
not
know
to
look
for
the
input
right.
D
So
basically,
if,
if
there's
anything
in
the
json
that
the
cni
does
not
know,
then
it
should
be
marked
as
not
green,
and
you
know
you
can
have
additional
granularity
of
status,
but
I
don't
see
the
issue
in
having
a
very
minimal
status,
which
says
I
recognized
everything
in
the
json
and
I
processed
everything
in
the
json.
Hence
my
status
is
green
else.
It
is
not
green.
That's
it!
Isn't
that
a
starting
point
enough.
C
Yeah,
I
I
I
am
still.
I
still
have
some
some.
I
still
have
some
concerns
about
about
how
how
to
how
to
how
to
how
to
deal
with
missing
feuds.
C
We
can,
we
can
say
okay,
so
we
know
that
import
is
a
field,
a
new
field
and
and-
and
we
are
going
to
use
that
one
as
the
processing
like
the
extra
processing
effort
right
so
saying
we
can
process
everything
and
we
can
say
if
we
could
process
or
not
just
and
part
as
well.
I
think
it's
a
it's
an
approach.
C
D
If
either
I
did
not
recognize
something
in
the
json,
maybe
because
it
was
a
new
field
that
got
added
later,
which
I
have
not
yet
added
supported
for
or
because
my
hardware
doesn't
support
it
or
whatever
my
driver
doesn't
support
it.
Then
my
status
is
not
green
and
that's
sort
of
the
minimal
flag
and
then
beyond
that
yeah
like
abhishek,
was
saying
you
can
add
various
kinds
of
conditions
beyond
that.
For
this
particular
feature
every
feature
every
sub
feature,
but
it
seems
like
it's
valid,
I'm
not
talking
about
like
that.
Granular
I'm
talking.
A
Right
so
the
cni
might
not
even
see
it
depending
on
version
right,
that's
good
yeah!
I
was
saying
too
like
for
oven
kubernetes,
for
example,
like
I
think,
or
we're
still
on.
We
could.
Our
client
go
package
could
still
be
back
on
1.18,
it's
not,
but
if
it
was
like,
we
wouldn't
even
see
that
but
you're
also
gonna,
you
wouldn't
see
anything
about
endpoints
endpoints.
You
are
imports,
you
wouldn't
say
anything
about
statuses,
so,
like
you're
gonna
have
that
problem
with
the
status
guild
itself
too
right.
That's.
D
D
B
B
Yeah,
I
think
there
is
a
slight
misunderstanding.
Even
if
we
have
a
an
older
client
go
as
long
as
you're
requesting
a
v1
resource,
you
will
get
the
entire
you.
B
B
If
you're,
if
you're
requesting
an
older
version,
let's
say
we
want
better
one
and
it
doesn't
have
input
so
then
it
will
drop
the
newer
ones.
But
if
you
are
still
requesting
a
v1,
you
should
still
get
like
the
entire
v1
object.
D
A
Yeah,
I
agree
so
I
think
moving
forward.
We
just
need
you
know
some
people
to
kind
of
pick
up
and
help
ricardo
on
this.
So
yeah,
I
don't
know
if
anyone
here
is
interested
in
helping
ricardo
out.
I
don't
really
have
the
bandwidth
right
now,
maybe
in
a
month
or
so,
I
would
but.
B
Yeah,
if
go
ahead-
and
I
was
gonna
say
if
you
know
if
you
want
some
help
in
terms
of
like
the,
if
I
have
written
some
status
conditions
in
the
past,
I
can
just
help
you
with
like
how
to
like
what
is
the
design
of
the
status
condition
that
I
had
in
mind,
and
I
can
copy
paste
that
information
and
it
should
look
similar
to
what
andrew
was
just
you
know,
showing
on
his
screen
and
yeah.
But
beyond
that,
maybe
wait
after
cnp
stuff,
this
yeah
yeah
I'll
see.
C
Help,
I
don't
think
there
is
a
huge
worry,
but
I
will
I
will
ping
team
again
to
see
at
least
if
we
are
moving
in
the
right
direction
right,
because
I
don't
want
to
write
the
cap
and
then
and
then
like
near
to
to
to
cap,
freeze
124
kept
freeze,
someone
says:
hey,
we
we
don't
want
that.
We
can
do
that,
etc.
C
D
C
A
If
you
ice
the
way,
you've
isolated
it,
though,
by
explicitly
saying
like
we
are
not
trying
to
solve
the
problem
of
saying
this
network
policy
is
implemented.
I
think
that
takes
apart
a
lot
of
the
arguments
that
were
coming
in
about
it,
because
that's
where
most
people
had
problems,
they
were
saying
it's
impossible
to
to
explicitly
make
the
cni
say
this
policy
is
implemented,
like
it's
programmed.
You
know
in
in
the
data
plane
like
because
they
aren't
going
to
be
able
to
do
that
accurately
all
the
time.
So
you
know
isolating.
D
A
I
mean
it's
best
effort,
it's
it's.
Does
the
cni
understand
the
fields
that
were
given
in
a
network
policy
and
and
does
the
cni
think
it's
implemented
it?
It
can't
be
used,
for
instance,
in
ci
like
you
couldn't
you
could
use
it,
but
it
might
not
necessarily
work.
You
could
block
a
test
on
network
policy
until
the
status
is
green,
but
at
the
end
of
the
day,
like
there's
still
going
to
be
race
conditions
in
there
there's
no
way
to
absolutely
say
without
testing
right.
This
policy
is
implemented
in
the
data
plane.
D
So,
okay,
so
there's
two
issues:
one
is
this
definition
itself
of
the
spec,
which
I
think
is
that's
why
ricardo
is
saying:
do
the
absolute
minimal
right,
the
absolute
minimum
is
literally
a
flag,
saying
I
recognized
all
the
fields
and
I
processed
all
the
fields.
D
If
so,
my
status
is
green.
Yes,
my
status
is
read
this.
This
is
the
minimum
definition.
If
you
want
to
have
status
at
all
and
then
so
there
should
really
be.
No
no
debate
about
that
debate
will
be
about
more
fancy
things,
but
if
cni
can't
even
tell
you
that
it
applied
that's
the
limitation
of
that
cni,
why
are
we
even
having
this
feature?
The
whole
point
of
this
feature
was
to
know
whether
this
applied
this
policy
goes
actually
applied
in
the
data
plane
or
not.
C
No,
no!
No!
No!
No!
No!
No
from
my
I
I
already.
I
actually
say
that,
on
on
on
on
the
beginning
of
the
meeting
andrew,
your
screen
is
leaking.
I
don't
know
if
you
want
us
to
see
your
slack
sorry
about
that
yeah,
no
problem.
I
always.
I
always
do
that.
I
I
say
that
on
on
the
beginning
of
the
meeting,
so
my
idea
is
that
we
restrict
into
the
if
the
control
plane
could
understand
what
that
policy
means.
C
C
D
Status,
that's
just
hcd
validation,
checks.
C
C
See
see
see
this
way,
I
mean
we
we
can.
We
can
provide
some
feedback
to
the
user
to
why
the
con,
because
all
the
cni's
they
have
that
at
least
the
majority.
They
have
that
control,
that
controller
right,
that
that
takes
the
network
policy
objects
and
turn
that
into
something
internal,
so
calico
does
have.
I
know
that
that
mantria
have
as
well
right.
C
So
what's
the
idea,
sometimes
those
those
things
they
fail
and
why
they
fail
because
of
of
any
reasons
so
and
part
not
being
supported
or
an
invalid
field
that
wasn't
validated
in
in
api
server,
et
cetera
right
so
for
the
cis
admin,
it
would
be
something
like
I
need
to
go
to
that
controller
logs
and
see.
C
So
it's
not
about
saying
if,
if
it
was
applied
on
on
all
nodes,
even
because
we
it's
it's
almost
impossible
for
us
to
know
which
node
that
that
policy
needs
to
be
applied
or
not
right,
so
for
the
user
yeah
you
create
a
policy
saying
I
I
want
to
communicate
with
all
of
the
pods
selected
by
this
label
x.
No,
no,
so,
would
you
have
a
status
with
like
10,
15
nodes,
saying
that
that
policy
was
applied
or
not?
I
don't
think
it's
I.
C
I
understand
your
your
view
about
that
valve
that
that
value,
I
I
do
as
a
user
I
do.
I
think
it
would
be
like
more
information
is
always
better.
I
just
think
that
we've,
if
we
try
to
put
that
as
a
minimum
viable
product,
we
are
not
never
going
to
deliver
these
status
as
well,
right
and-
and
I
think
we
should
we
should
probably-
we
should
probably
try
to
improve
at
least
like
the
feedback
of
if
it
was
processed
or
not,
but
not
if
it
was
applied
or
not.
C
D
So
I
think
the
biggest
value
of
this
feature
is
knowing
whether
the
policy
is
in
effect
or
not,
because
then
I
know
whether
I'm
dropping
packets,
that's
intentional,
or
it's
a
bug
right
or
I
have
this
policy.
Why
am
I
not
dropping
this
packet,
but
if
it
cannot
tell
you
that,
then
I
think
the
value
is
quite
reduced.
D
You
know
and
we
can
always
add
more
validation
checks.
So
I
would
if,
if
we
want
to
not,
if
you
want
to
have
basically
just
say
it
was
processed,
but
I
don't
know
whether
it
was
applied.
D
A
Yeah-
and
I
I
have
a
ton
of
I
agreed
with
you-
I
totally
like-
was
in
your
in
your
mindset
as
well
sanjeev,
and
then
I
had
a
conversation
with
dan
and
I'll
go
back
and
find
it.
He
tried
to
do
this
and
failed
and
basically
chalked
it
up
like
this
is
impossible.
It's
not
gonna
work
and
he
has
a
list
of
arguments
that
I
cannot
rattle
off
on
the
top
of
my
head,
but
let
me
find
them
and
I'll
put
them
in
the
agenda
and
I'll
poke
you
when
I
do.
C
Just
just
to
be
clear
about
that,
that's
not
that
I
want
to
implement
status.
I
was
living
fine
enough
with
that
with
that
they
asked
us
to
implement
that
on
on
on
on
the
network
policy
as
part
of
of
of
graduating
to
ga
front
part
yeah
exactly,
and
I
wrote
that
on
the
pr
on
the
cap
saying
hey,
I
don't
think
this
is
easy,
as
we
think
it
is,
but
anyway
proposal,
the
team's
proposal
was
just
just
a
tuple
of
like
the
cni
the
description
on
the
message.
C
So
if,
if
tim
agrees
that
this
is
like
an
approach,
I
think
that
we
we
may
try
at
least
to
evolve
that
in
in
at
least
as
much
as
we
can,
but
not
getting
not
sweating
too
much
on
that.
Like
saying
hey,
we
are
now
going
to
to
to
implement
the
status
for
each
note,
because
it's
really
really
really
hard.
If
then,
could
couldn't
do
that,
I
don't
think
I
will.
A
I
will
be
able
to
sorry
and
I'll
find
that
there's
a
bunch
of
old
conversation,
but
anyway,
for
now,
if
it's
alright
with
y'all,
I
say
we
move
on
is
that
cool.
A
Okay,
great
ricardo,
I'm
gonna
reach
out
to
some
members
of
my
team
internally
and
see
if
anyone's
interested.
I
think
this
would
be
a
really
great
project
for
like
a
newer,
a
newcomer
to
hop
into
and
help
you
out
with,
I
already
poked
them
once,
but
I'll
do
it
again
and
we'll
see
if
we
can
get
anyone
else
to
join
and
kind
of
start
helping
out
here,
especially
with
like
the
right.
The
documentation
and
stuff
sounds
good
thanks.
A
Okay,
yeah
and
I'm
gonna
try
to
find
some
of
the
prior
art
to
this
status
cap,
and
I
have
it
like
back
when
this
agenda
somewhere
and
coalesce
it
up
near
the
top.
So
we
can
all
see
it.
A
Okey-Doke
network
policy,
v2
update,
I'm
not
sure
who
threw
this
on
here.
Is
there
some
things
people
want
to
talk
about
regarding
v2.
B
E
B
A
E
E
Look
for
comment
and,
if
and
I'll,
try
to
respond
to
them
on
the
dock
itself,.
A
Sounds
good
thanks,
and
hopefully
you
know
in
the
next
week
or
two
we'll
have
have
a
clearer
way
forward
to
cmp
our
plan
is
to
for
this
thursday
to
present
to
them.
So
then
we
should
be
able
to
move
forward
with
v2.
A
Okay,
thank
you,
and
now
I
guess
we
will
hop
back
up
into
cmp
stuff.
I
really
just
would
like
to
hear
I
know
abhishek.
You
had
a
meeting
with
tim
last
friday
and
I
think
it'd
be
good.
If
you
could
just
give
us
a
brief
summary
of
what
y'all
talked
about
there.
B
Yeah
sure
I
think,
as
part
of
that,
just
before
that
meeting
I
added
some
diagrams,
because
I
remember
last
time
he
mentioned
that
he
responds
better
to
diagrams.
So
so,
basically,
I
gave
him
an
overview
of
the
three
proposals
that
we
had
and
essentially
how
they,
each
of
them
works
and
kind
of
like
the
pldr
of
that
meeting
was
that
he
is
in
favor
of
some
former
passion
of
like
proposal
b
or
c,
which
is
this.
I
think
a
he
feels
is
a
bit
harder
to
grasp.
B
So
between
b
and
c,
he
feels
like.
Maybe
some
of
that
can
go,
and
I
think
he
he
was
actually
saying
that
he
slightly
leans
towards
c,
because
he
feels
that
it
is
okay
for
an
administrator
to
be
more
complex
than
we
are
sorry
than
the
kubernetes
developers.
B
So
he
feels
that
c
can
work
in,
but
that
comes
with
additional
attachment.
That
is
that
we
need
to
ensure
that
there
is
proper
tooling.
On
top
of
of
of
this,
if
we
have
to
go
with
proposal
c,
we
need
proper
tooling.
On
top
of
it,
such
that,
when
you
describe
this
policy,
it
describes
those
conflicts,
it
describes
things
and
if
it's
not
c,
if
it's
b,
then
you
know
we,
we
have
some
documentation.
B
That
needs
to
be
done,
which
needs
to
explain
like
what
is
this
new
proposal
and
how
this
works,
but
he
also
had
some
suggestions
for
us,
which
I
have
like
incorporated,
as
you
know,
c,
prime.
So,
if
you
look
at
proposal
c,
prime,
which
is
and
the
the
the
main
difference
here
between
c
and
c
prime,
was
that
if
you
look
at
c
sorry
sorry,
I
have
to
go
back.
If,
if
you
look
at
c
our
empower
or
the
past
action
here
means
that
you
will.
B
You
know
like
to
completely
pass
all
this
cluster
network
policy
rules
and
directly
go
to
kubernetes
network
policies
and
what
happens
when
there
is
no
matching
humanitarian
policies.
That's
like
the
default
rule
that
we
were
talking
about
right
and
and,
as
our
proposal
for
c
was
that
we
use
some
sort
of
a
priority,
zero
or
some
some
numeric
priority,
which
defines
what
should
be
the
default
rules
for
the
cluster.
B
If
none
of
the
policies
match
so
his
suggestion
was
that,
instead
of
using
a
new
priority
number,
what
what
we
could
do
is
like
you
know,
the
pass
is
more
like
a
consult
option
wherein
you
you
know,
you
consult
the
kubernetes
network
policies.
First,
if
there
is
a
rule
that
matches
it,
then
you
or
you
enforce
that.
But
if
none
of
the
rules
match,
then
you
move
on
from
where
you
were.
So,
if
you
look
at
the
c
prime,
like
proposal,
you
can
see
the
difference
there.
There
is
no.
B
Is
it
just
my
screen
or
can
I
can
you?
Oh
wait?
Sorry,
it's
my
screen.
So
if
you
look
at
the
bottom
of
the
diagram,
there
is
no
default
rules
block
in
there.
B
If
you
look
at
the
arrows
which
the
pass
action
is
defined
with,
once
you
match
a
pass
action
rule,
it
will
go
and
consult
the
kubernetes
network
policies.
If
something
matches
you
implement
those
you,
that
will
be
the
terminal
action,
but
if
it
doesn't,
then
you
move
on
to
the
next
priority
rule
which
could
be
the
deny
rule
or
in
in
the
left-hand
side
it
would
be
a
p50
denial,
but
it
could
be
like
a
p50
allow.
B
So
those
are
two
separate
policies
or-
and-
and
you
know
if
so
in
the
second,
the
diagram
on
the
right
hand,
side
shows
that
you
know
you
move
on
from
where
you
were,
you
don't
go
all
the
way
at
the
top.
So,
for
example,
in
the
second
figure
pass
action
is
at
p50
and
you
consult
the
kubernetes
network
policy,
nothing
works
out.
Then
you
go
to
p10,
you
don't
go
back
to
p100,
so
you
basically
you
know
it's
just
like
you
know.
You
are
looking
into
the
kubernetes
network
policy
rules.
B
A
B
So
I
think
we
don't
add
special
rules.
This
is
just
the
understanding
of
a
pass
action
group.
So
pass
action
basically
means
that
you
go
look
into
the
community's
network
policies
and
then
continue
your
journey
forward.
In
your
case,
if,
let's
say
there
was
no
p10
block
on
the
right-hand
side
right,
that's
what
you
were
trying
to
say
right,
p50
and
that
given
internet
policy
yeah,
so
the
effect
would
be
that
it
matches
the
pass
action
rule.
It
will
look
into
kubernetes
network
policies
and
then
it
doesn't
find
any
matching
rule.
B
It
goes
back
to
the
next
priority
which
in
case
there
will
be
none,
so
it
just
falls
through
and
it
will
be
allowed
as,
as
is
the
case
with
kubernetes
policies,
defaults.
Okay,
so
you
don't
need
a
special
crd.
You
know
you
don't
need
special
keywords.
You
don't
need
a
special
delimiter
or
you
know
to
to
solve
the
default
use
case.
B
D
So
I
think
this
is
a
little
convoluted
just
to
get
around
the
default
issue,
because
a
people
could
be
adding
and
deleting
netfalls
and
sometimes
you're
going
down
and
checking.
There
is
something
and
then
you
come
back.
Sometimes
you
don't
come
back
later
on.
They
add
some
network
policy
or
remove
it.
Then
you
do
come
back
loop
around.
D
I
think
that
the
default
should
be
if,
if
we
have
a
default
at
all,
it
should
be
a
simple
logic.
So
it's
fair
to
have
this
as
an
option,
but
I
would
like
to
think
about
it
as
whether
it's
worth
the
complexity
just
for
have
a
default
policy
in
order
to
do
this
sort
of
look
ahead
and
come
back
logic
but
other
than
the
default.
So
this
is
just
to
address
default,
but
other
than
the
default
did.
He
express
an
opinion
between
b,
prime
and
c,
prime
or
b
and
c
yeah.
B
B
Yeah,
I
think,
for
him
he's
mentioned
that
the
b
seems
simpler,
but
the
problem
of
another
b,
prime
the
b
proposal
yeah,
I
think
in
b
proposal
b.
He
feels
like
the
problem
of
you
know.
The
ability
to
add,
like
an
emergency
deny
rule,
is
harder
like,
for
example.
B
B
B
So
I
mean,
is
he
saying
c
then,
because,
if
he's
so
first
yeah,
so
that
is
the
only
reason
why
he
would
slightly
favor
c,
because
you
have
the
ability
to
write
this
one
highest
priority
rule
which,
which
can
be
which
can
be
used
for
that
use
case,
and
that
is
the
only
reason
why
he
would
favor
c,
but
he
does
acknowledge
the
fact
that
b
is
you
know,
b,
for
with
b,
you
don't
need
to
do
additional
tooling,
you
don't
need
those
extra
ux,
the
user
experience
will
be
simpler,
with
b
okay.
B
So
for
that,
I
think
this.
The
b
prime,
is
what
I
just
you
know
thought
about
over
the
weekend,
which
is
this,
what
we
are
seeing,
and
that
is
that
you
know
it's
similar
to
b.
It
is
again
similar
in
terms
of
default
actions
where,
where
you
don't
necessarily
need
like
a
separate
crd
or
a
separate
boolean
flag,
you
know
you
take
the
next
default
disposition.
B
Just
like
what
c
prime
is
in
addition
to
that
there
is
this
one
single
highest
kind
of
block
at
the
top
called
emergency
deny,
which
is
to
be
used
only
for
that
purpose.
Wherein
you,
you
know,
there's
no
skipping.
Those
rules,
there's
no
deny
there's.
No,
you
know
going
around
the
emergency
tonight.
Those
are
the
top
most
denials,
wherein
your
only
expectation
is
to
use
those
in
cases
of
emergencies
where
you
need,
like
a
malicious,
deny
or
sorry
malicious
part
to
be
denied,
and
that's
like
a
way
around
to
so
way.
B
And
that's
just
an
you
know,
just
a
separate
proposal.
I
just
thought
about
the
weekend
and
maybe
we
can
see
if
you
know
this
is
whether
this
is
an
improvement
on
b
and
whether
this
is
something
that
is
a
better
user
friend
I
mean
more
user
friendly
and
also
is
like
somewhere
midway
between
the
priority-based
proposal
and
the
three-action
proposal.
D
And
did
he
have
any
feedback
on
bringing
this
to
sig
network
and
getting
input
from
others.
B
Oh
yeah,
I
think
the
the
idea
is
that
we
are
already
on
the
agenda.
This
was
just
for
him
to
so
like
so
we
are
on
for
day
after
tomorrow.
I
believe
so
right.
We've
already
put
our
names
in
there.
Okay,.
D
A
B
B
A
A
No
worries
my
my
first
reaction
to
at
least
c
prime,
is
it's
a
little
less
intuitive
and
would
and
would
just
require
more
hand
holding
on
the
tooling
right.
The
tooling
would
have
to
be
a
little
smarter
just
to
push
the
user
towards
this,
which
I
don't
think
is
a
game
break
game.
A
deal
breaker
at
all.
That's
just
my
first
thing.
B
To
see
if
the
tooling
recommendation
was
for
both
c
and
c.
A
Yeah,
but
if
we,
if
we
remove
some
sort
of
mechanism
for
default
rules
like
and
have
more
of
a
go-to
solution,
which
I
understand,
I
think
your
tooling
would
have
to
be
pretty
explicit
like
and
say:
if
you
pass
here,
go
it
goes
to
x,
rule.
That's
there
right,
like
you
would
have
to
let
your
user
know
what's
happening
at
the
end
of
the
day,
based
on
the
current
state
of
the
cluster
right
always
so
anyway.
Super.
A
B
For
the
for
the
implementation
perspective,
if
I
think
about
it
in
terms
of
obs,
how
we
will
implement
this,
the
c
prime
becomes
a
bit
harder
to
implement,
because
now
you
need
to
especially
with
different
priorities.
It's
a
bit
more
difficult,
because
now
you
need
to
go
to
an
ovs
table,
or
I
mean
I'm
talking
here
obs.
B
But
you
know
every
other
implementation,
probably,
which
has
some
sort
of
like
table,
and
rules
within
itself
would
have
this
issue
wherein
the
the
go-to
point
is
very
dynamic,
because
the
priorities
could
be
different,
like
your
pass.
Action
could
be
in
the
middle
of
like
two
deny
actions
remember
to
allow
actions
and
there
could
be
multiple
pass
actions
because
you
know,
and
they
can
have
different
priorities,
so
so
the
go-to
for
each
of
those
pass
rules
would
be
different
dynamic.
You
can't
just
go
to
like
a
ovs
table
directly.
B
You
need
to
find
that
particular
priority
role
within
it.
So
it's
going
to
be
a
bit
confusing
to,
or
rather
I
would
say,
not
so
optimized
way
of
doing
it.
Yeah.
B
B
D
D
Focus
on
presenting
abc
later
on,
we
can
say:
okay,
there
are
very
some
variations.
These
were
some
based
on
some
feedback
from
him,
but
let's
not
get
diverted
into
a
b
b.
Prime
c
prime,
that's
like
five
different.
So
for
thursday
go
with
abc
and
then
later
and
say:
okay,
there
are
some
variations
based
on
some
feedback
from
tim,
but
I
think
that
especially
c
prime
is
pretty
hacky.
In
my
view,.
D
B
This
this,
these
separate
variations
were
just
for
our
purpose
to
see
whether
whether
do
we
have
like
improvements
on
on
our
proposals,
but.
D
A
Yeah,
okay
and
then
so
for
thursday,
do
we
want
to
have
a
list
of
like
key
points
we
want
to
get
through?
I
know
like
last
meeting
we
I
kind
of
ran
through
the
beginning
of
the
powerpoint,
like
you
know,
and
the
assumptions
like
do
we
want
to
run
through
those
again
or
should
it
be
more
of
like
we
hope,
you've
reviewed
it.
Let's
talk
about
it.
How
do
we
want
thursday
to
go
forum
wise
while
we're
there.
D
I
think
a
little
bit
of
review
would
help,
because
not
everybody
is
the
same.
We
can
talk.
Maybe
we
can.
Some
of
us
can
chat
offline
as
to
how
how
to
do
it.
Okay,
but
then
rest
of
it
could
be
on
the
yaml
and
also
leave
enough
time
for
him
to
speak
his
mind
as
he's
already
committed
his
feedback
and
then
invite
input
from
casey
and
others
sounds
good.
D
Let's
chat
offline
abhishek
and
you
and
I
or
whoever
else
is
interested
about
how
we
want
to
go
over
on
the
thursday
call.
But
I
would
say
a
little
bit
of
review
some
on
the
yaml
and
then
open
question
open
discussion.
D
A
Yeah,
there's
nothing
on
the
agenda
for
next
for
this
week's
sig
network
meeting,
so
I'm
going
to
go
ahead
and
make
it
and
put
our
names
on
there.
First.
D
Yeah,
I
think
this
was
very
good
to
have
him
kind
of
spend
time
on
it
really
thinking
about
it
before
so
that
at
least
one
of
the
leads
has
really
spent
time
on
it.
A
I've
talked
to
dan,
I
I
think
it's
on
his
list.
I'll
keep
poking
him,
so
hopefully
we
get
some
feedback
from
him
as
well.
I
think,
if
we
can
get,
is
somebody.
A
I
would
hope
they
would,
I
don't
know
them
directly,
so
I
don't
feel
comfortable
like
reaching
out
directly,
but
I
would
hope
they
would
see
the
sig
network
pokes.
If
there's
someone
on
the
call
who
could
reach
out
to
them
directly,
I
I
can.
I
can
ping
casey
and
thomas
on
on.
C
Slack
yeah.
That
would
be
awesome.
Just
just
just
send
me
what
what
do
you
want
me
to
bring
them,
and
I
can't
think
them.
I
guess
there
is
someone
from
on
our
signature
policy.
Api
group,
slack
and
casey.
Is
there
as
well?
So
if
you
want
to
also
post
there
and
being
casey-
and
I
guess
that
andre
is
there-
probably
they
are
gonna
they're
gonna
answer,
but
anyway
you
can.
You
can
also
post
whatever
you
want
on
signature
policy
api
and
I
can
mark
them.
B
D
A
B
D
Calico's
pass
is
slightly
different
than
what
we
are
yeah.
That's
true,
calicos
is
more,
but
I
mean
you're
right.
Calculus
is
actually
to
pass
to
those
special
profiles.
Yes,
but
anyway,
the
point
is
to
make
some
kind
of
delegation
slash
exception.
B
B
Yeah
yeah.
No,
I
think
I
like
the
introduction
of
this
pass
action
in
priority,
because
my
biggest
beast
that
was
or
the
the
proposal
c,
was
that
it's
extremely
hard
to
get
those
intra
name,
space
policies
to
be
delegated
and
with
the
pass
action
introduced.
I
think
that
makes
it
much
more
easier
to
write
those
policies.
You
don't
have
to
rely
on
so
many
so
much
of
norton's
and
all
those
complicated
negative
connotations
to
the
rules,
so
the
the
introduction
of
pass
actually
is
a
bit
of
good.
A
B
C
A
A
B
A
I
love
it
yeah.
There's
the
man
awesome,
okay!
Well,
thanks
all
for
coming
today.
I
think
that
was
really
productive.
Meeting
take
some
of
these
action
items
and
hopefully
we
have
a
good
meeting
on
thursday
and
we
can
move
forward
and
start
getting
some
of
the
fun
stuff
with
cmt.
So
I
appreciate
your
time
and
we'll
talk
to
you
next
week
or
later
see.
You
folks
see
you
next.