►
From YouTube: SIG Network Policy API Meeting 20200824
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
Touch
the
the
conduct
rules
apply,
and
so
please
be
kind
to
everybody
on
the
call
and
also,
let's,
please
welcome
anybody,
that's
new
and
make
sure
that
we
hear
all
voices
so
that
we
can
continue
to
move
this
idf
or
v2
network
policy
forward
as
a
community.
A
A
A
One
of
the
things
that
we
wanted
to
avoid
was
continuing
to
rehash
the
same
concepts
and
ideas
and
make
sure
that
we
were
moving
toward
an
actual
set
of
documents
that
describe
what
we're
wanting
to
accomplish
and
and
do
this
in
a
way
that,
when
we're
finished,
we'll
have
something
that
has
been.
A
Rather,
that
would
begin
to
put
in
some
structures
so
that
we
can
take
changes
in
a
very
github
way
that
you
know,
allows
people
to
submit
prs
and
this
actually
move
forward
on
on
the
the
kubernetes
enhancement
proposals
or
the
caps
by
which
we
want
to
track
the
desires
coming
out
of
the
group,
the
user
stories
and
such
so
with
that
we
had
our
first
meeting
last
week
and
by
the
way
last
week
was
very
busy.
A
I
know
a
lot
of
you
attended
kubecon
and
had
a
lot
of
different
things
going
on,
but
we
were
able
to
squeeze
a
little
time
in
as
a
as
a
smaller
draft
group
to
put
together
some
of
the
basic
pieces
that
were
going
to
be
necessary
to
continue
to
capture
ideas
within
this
larger
group,
so
jay
and
and
and
abhishek
and
ricardo.
Some
of
the
others
that,
were
you
know,
part
of
that
yang,
I
think,
was
part
of
that
as
well.
A
I'm
going
to
share
with
you
a
repository
that
was
created.
We
are
going
to
relocate
this
repository
very
likely
to
a
more
sig
central
repository
moving
forward.
We
just
got
quickly
started
with
this
jay,
I'm
going
to
share
your
repository
kind
of
what
we
did
to
begin
with
and
then
talk
about.
A
A
All
right,
so
what
we
did
as
a
group
is,
we
went
ahead
and
created
a
repository
under
jay's,
username
and
github.
We
would
like
to
move
this
again
to
a
more
sig
central
repository
jay.
I
believe
your
repository
is
open
up
for
pr
inbound
prs
from
anybody
who
wants
to
contribute.
Is
that
correct.
C
A
Yeah,
so
so
in
this
repository,
there's
a
couple
things
that
we
wanted
to
capture
and
I'm
going
to
let
the
owners
of
these
different
areas
talk
a
little
bit
more
about
what
they're
working
on
as
we
get
to
them.
So
please
be
ready
to
speak
up
on
on
your
different
parts.
A
So
this
this
read
me
file
is
really
a
representation
of
the
larger
umbrella
of
motivation
and
desires
around
network
policy
v2,
and
we
wanted
to
capture
that
in
long
term
it
will
end
up
turning
into
a
cap-like
structure,
but
we
wanted
to
give
some
overall
guiding
principles
for
what
we're
trying
to
do
with
this
network
policy.
V2
right
now,
it's
it's
more
of
an
outline
than
it
is
an
actual
set
of
pros
that
will
develop
over
time,
but
we
did
some
brainstorming
initially
to
talk
about.
A
You
know
what
the
what
the
context
of
this
is,
what
what's
motivating
of
this
work?
What
deliverables
we're
looking
for
and
assigned
some
temporary
owners
to
those
various
pieces?
And
so,
if
you
get
a
chance,
I
would
encourage
everyone
to
and
jay
could
you
post
this
into
the
chat?
Please
so
that
everybody
knows
where
this
repository
is.
A
A
In
terms
of
you
know
what
they're
trying
to
represent,
I'm
going
to
turn
each
one
of
those
user
stories
into
a
separate
kep
document
under
the
stories
directory,
so
that
we
can
actually
track
each
individual
story
separately
and-
and
everyone
can
make
you
know
pr
submissions
to
those
stories
individually,
as
as
we
work
out,
not
only
what
the
the
user
story
is,
but
maybe
what
you
know
what
are
implications
in
terms
of
the
roles
and
personas
involved
in
that
story?
A
A
And
I
think
I
just
sent
in
that
first
pr,
I
don't
know
if
it
got
merged
yet,
but
there
you
know,
for
example,
we'll
have
oh
you've
already
merged
excellent.
A
So,
for
example,
under
stories,
one
of
the
ones
we
talked
about
was
name
as
a
policy
target
right,
so
I'll
go
in
and
as
a
policy
creator.
I
want
to
do
this,
so
the
first
step
is
just
making
sure
we
have
a
very
crisp
understanding
of
the
story
and
then
we'll
start
adding
details
to
each
one
of
these
stories
as
we
go
along
based
on
the
previous
work
that
we've
done
as
a
group
in
in
capturing
all
these
ideas,
as
well
as
figuring
out.
A
You
know
how
these
stories
relate
to
each
other.
What
stories
are
priority,
etc
and-
and
some
of
that's
outlined
here
in
this
user
stories,
in
terms
of
you
know
what
are
non-v1
modifying
stories-
v1
modifying
you,
know,
cluster
scoped
user
stories
etc.
Some
of
that
got
outlined
here.
Some
of
this
came
out
of
dan's
work
that
he
did
and
so
we're
going
to
try
to
take
all
the
existing
work.
That's
been
done
and
incorporated
into
into
these
documents.
A
Okay,
so
with
that,
let's
talk
a
little
bit
about
some
of
the
other
assets
that
are
in
this
directory.
So
right
now
me
and
jay
and
andrew
ricardo
were
working
on
on
the
user
stories,
prioritizing
those
making
sure
that
they're
cleaned
up
and
very
clear
about
what
they're
trying
to
accomplish
abhishek
and
and
do
you
want
to
tell
us
a
little
bit
about
what
you're
doing
around
the
concepts
component?
Are
you
online.
D
Hey,
yes,
I
think
me
and
jayla
are
talking
about,
like
you
know,
once
we
have
the
user
story
set
in
what
should
be
the
move
forward.
So
on
a
broad
scope,
I
think
there
are
three
three
kinds
of
user
stories.
One
is
you
know
towards
the
application.
Developer
focused
api
user
stories,
the
other
is
towards
you
know
an
administrator
or
a
cluster
scoped
api.
D
I
think
I
have
not
yet
captured
the
third
one.
The
third
one-
and
I
think
this
kind
of
came
up
with
our
talk
with
christopher
this
morning
is
you
know
some
tooling
aspect.
I
think
we
would
also
want
to
incorporate
this
as
part
of
the
agenda
for
the
goals
so
to
have
like
some
sort
of
a
cli
or
a
tool
well
defined,
which
kind
of
gives
more
clarity
into
the
into
the
network
policies.
D
So
so
so
so
the
idea
would
be
to
you
know,
get
these
user
stories
together
and
like
come
up
with
you
know:
either
a
crd
for
the
cluster
scope
policy
or
or
an
update
or
a
new
developer,
focused
resource
for
the
existing
network
policies
and
then
some
sort
of
a
sketch
for
the
the
policy
cutter
tool.
D
So
that
would
be
like
the
three
high
level
scope,
and
I
think
I
think
some
of
this-
and
actually
a
lot
of
this-
also
overlaps
with
the
with
the
da
with
the
idea
or
the
proposal
that
dan
winship
had
put
forward
a
couple
of
weeks
ago
in
his
document.
So
that's
why
I
think
we
would
also
hope
that
dan
would
be
able
to
contribute
to
this,
because
you
know
the
ideas,
kind
of
align.
A
Great,
so
in
terms
of
implementation,
ricardo
or
chris,
do
you
want
to
discuss
what
part
3a
and
3b
are
around
keps
and.
E
Crds
yeah
from
from
me,
I
hadn't,
started
anything
yet
about
the
cap
structure,
I'm
more
waiting
for
the
discussions
and
then
maybe
we'll
start
drafting
something.
I
haven't
even
reached
richard
crazy.
Yet.
F
B
Yeah,
as
for
caps,
we're
looking
for
user
stories
that
make
sense
as
caps,
so
I
just
created
one
potentially
that
just
got
merged
a
little
bit
ago
about
the
cider
story,
and
this
is
one
that
would
be
potentially
switching
the
cider
selector
such
that
it
would
refer
to
a
slice
instead
of
a
string
which
it
is
now
that's
something
that
we
could
potentially
do
in
v1.
B
B
Basically
allow
or
deny
all
with
respect
to
egress
or
ingress
so
having
some
other
sort
of
moniker
in
there
which
stands
for
that,
and
that
is
issue,
that's
actually
in
the
user
stories.
I
linked
it
in
there
there's
a
specific
user
story
on
that,
one
that
one
I
have
a
little
less
idea
of
how
we
would
actually
go
about
that.
What
what
we
would
do,
what
was
better,
but
I
think
it's
definitely
something
that
potentially
someone
could
create
a
cap
for.
B
C
Great
and
for
for
3b,
I
think
that's
where
so
many
of
them
fall
right,
because
there's
all
these
cluster
network
policy
things
that
you
know
we
could,
in
my
opinion,
we
could
hack
away
at
them
and
come
up
with
something
that
would
allow
us
to
experiment
with
how
those
things
would
get
potentially
implemented
in
a
generic
way.
C
Cody
mentioned
there
could
be
a
lot
of
corner
cases
there,
where
some
of
them
may
not
work
as
well
as
if
you
have
native
cni's
integrating
them,
but
I
think
that
they're,
cheap
and
easy
enough
to
play
with
and
implement
that
it's
worth
at
least
exploring
what
those
might
look
like.
There's
another
way
to
explore
that
which
is
to
literally
take
what
folks
in
calico
global
network
policy
are
doing
and
folks
in
the
intra
community
have
for
global
network
policy
and
look
at
other
apis
and
just
do
a
matrix
comparison.
C
And
I
think
that
is
the
thing
that
I'm
interested
in
playing
around
with
and
looking
for
volunteers
who
want
to
hack
on
that
with
me
in
a
somewhat
undefined
undirected
manner.
So,
but
just.
A
To
be
a
little
more
to
to
be
a
little
more
clear
here,
what
I
think
you're
trying
to
do
with
this
effort
is
find
an
early
way
to
test
out
apis
without
necessarily
having
a
native
implementation,
so
basically
translating
from
a
new
api
to
an
implementation
that
utilizes
existing
existing
enforcement
capabilities
of
existing
csis
right,
using
just
like
v1
v1.
So,
for
example,
to
do
cluster
network
policy.
You
would
translate
that
into
like
multiple
namespace
policies,
or
something
like
that.
C
Yeah
exactly
taking
v1
as
a
set
of
primitives
as
opposed
to
a
set
of
incomplete
semantics,
which
is
the
way
we're
looking
at
it
now
and
saying.
What
can
you
do
with
these
primitives
right?
Because
other
people
in
the
community
have
done
stuff
like
that
and
it
seems,
like
you
know,
nobody's
really
completely
fleshed
out
those
ideas,
but
people
have
built
things
around
them.
Openshift
has,
as
we
know,
done
stuff.
C
You
know
to
this
effect,
and
so
has
you
know,
there's
there's
some
network
policy
operators
out
there
and
stuff
like
that,
and
so
many
of
the
user
stories
allude
to
wanting
a
solution
like
that.
So.
A
Sure
so
I
I
think
that's
an
interesting
approach.
I
I
I
did
caution
jay,
that
you
know
that
as
a
final
solution
may
not
be
very
efficient,
but
it
may
help
us
to
work
through
making
sure
that
we
get
the
right
api
abstractions,
at
least
for
for
accomplishing
these
these
user
stories,
and
I
think
it's
very
closely
related
with
the
next
section,
around
templates,
as
well
as
go
bind
on.
A
Yes,
sir,
I'm
here
all
right
so
on
on
this
section
and
I'll,
let
you
elaborate
more,
but
my
understanding
is
that
we
wanted
to
as
as
we're
thinking
about
these
new
user
stories
right.
We
also
want
to
understand
how
the
existing
set
of
primitives
are
being
used
to
accomplish
various
stories
so
that
we
can
at
least
see
where
we're
overlapping
or
or
maybe
where
we
already
have
a
way
to
do
something,
and
we
just
don't
know
how
that
works
or
help
us
to
understand.
A
G
No,
I
think
that
that's
correct,
I
just
wasn't
sure
like
if,
if
we
were
like
because
of
open
source
and
how
it
works,
I
I
wasn't
sure
if,
like
we're
only
talking
about
the
api
and
improvements
to
it
or
whether
templates
are
also
part
of
this,
this
effort,
so
I
wasn't
sure
what
the
actual
sort
of
quote-unquote
contribution
would
look
like.
You
know
what
I
mean.
A
Well,
I
I
thought
about
this
through
the
weekend
a
little
bit
more
and
I
think
that
it
is
actually
a
useful
exercise
as
we
as
we
look
through
the
user
stories.
Right
also
think
about
how
we
would
approach
that
with
v1
primitives,
so
that
we
can,
at
least
you
know,
have
a
a
concrete
layout
of
of
how
you
know
those
various
various
stories
would
be
solutionized
with
v1
right
and
then
and
then,
as
we
think
about
the
two,
we
have
a
more
concrete
way
to
actually
compare
and
contrast.
A
You
know
simplifying
the
api
or
or
the
overall
approach
right.
So
I
do
think
that
we
need
to
at
least
start
with
what
is
possible
today,
more
than
just
the
api,
but
actually
applied
applied,
use
cases.
G
Yeah,
no,
I
totally
agree
and
to
to
that
effect
I
mean
we.
We
already
published
a
few
templates
for
number
policy
and
they're
all
open
source
they're
on
github.
I
can
add
the
link
here
into
this
dock
as
well,
but
they're
they're,
trying
to
attack
this
exact,
exact
thing
where
you
know
we
have
some
use
cases
that
we
already
know.
F
G
A
G
Yeah
yeah
I
mean
the
thing
is:
what
ends
up
happening
is
something
that
you
would
you
know
almost
say
in
one
sentence
to
you
know
when
you're
talking
about
it
is
like
oh
yeah
I
want
default
deny
you
know
something
like
that
as
a
baseline
sort
of
set
of
policies
which
is
pretty
common,
when
you
can
imagine
like
you
know,
many
customers
would
would
like
to
use
kubernetes
for
stuff
like
that.
But
you
know
when
you
actually
get
to
it
and
try
to
implement
something
like
that
with
our
another
policy
api.
G
It
gets
very
hairy
very
quickly
and
then
it
becomes
a
natural
deterrent
for
customers
to
actually
try
to
use
it.
So
we
just
sort
of
like
went
ahead
and
said
yeah
this
one
sentence:
here's
a
gigantic
policy,
but
you
don't
really
care
you
can
just
you
know,
put
it
on
your.
You
know
your
cluster
and
it's
done
so
so
I
think
it's
really
worth
doing
that
exercise.
I
agree.
G
G
A
A
You
know
we
need
to
get
a
little
paint
on
the
canvas
right
so
that
we
can
start
critiquing
it
and
involving
others
so
yeah
it's
it's
sometimes
useful
to
at
least
like,
for
example,
with
the
user
stories
to
have
a
couple
of
them
written
out,
and
then
others
can
take
some
of
the
other
user
stories
and
start
following
kind
of
a
template
right
to
understand
what
all
aspects
of
that
story
they
need.
F
A
List
out
and
and
how
to
make
it
easier
to
consume
for
the
for
the
larger
community,
so
absolutely
get
involved
on
that.
Okay,
so
we
we've
laid
out
at
least
an
approach.
Now
we've
got
an
existing
repo,
so
there's
a
still
a
couple
of
outstanding
items.
One
is
where
should
this
like?
I,
I
really
appreciate
jay
creating
this
repo.
I
don't
know
that
it
needs
to
necessarily
live
there.
I
think
it's
going
to
be
appropriate
to
move
that
into
a
sig
repo.
A
So
I
think
a
couple
of
outstanding
items
that
we
need
to
accomplish
is:
what
is
it
going
to
require
to
to
move
this
effort
into
a
sig
network,
repo
number
one
and
number
two?
We
need
to
open
the
floor
up
right
now
from
to
the
community
to
give
some
feedback
on
this
approach.
What's
missing,
what
what
do
you
want
to
see?
More
of?
B
C
Okay,
yeah
do
we
have
excel
the
process
for,
for
forgetting
one
of
those
like
like
it
seems
like
it's
one
of
those
things
that
you
you
might
ask
for
one
and
then
you'd
have
to
justify
it
somehow
and
I've.
That's
what
I
was
wondering
like
I
don't
want
to.
I
don't
want
to
be
the
guy.
That's
like
give
me
a
repo.
You
know
like
for
like
what
do
we
do?
How
do
we
do
that.
H
I
do
yeah
so
for
kubernetes
six,
we
post
it's
actually
much
easier.
You
just
have
to
get
one
of
the
sick
co-chairs
to
sign
off
on
it,
okay,
yeah,
so,
but
if
but
if
we
wanted
a,
you
know,
kubernetes
we
go
to
that
has
to
go
through
sick
architecture
and
everything.
But
I
don't
think
we
need
that
here.
H
Yeah,
I'm
saying
just
open
an
issue
in
the
in
the
org
repo
and
then
yeah.
I
guess,
assign
it
to
one
of
the
church.
A
A
That's
that
way,
it
that's
right
that
way,
it
falls
under
the
standard,
cncf
usage
guidelines
and
all
that
kind
of
stuff
right.
So
we
want
to.
We
would
like
to
be
part
of
that
official
repo,
since
this
is
an
official
working
group.
A
Okay,
so
I
I
see
some
other
people
on
the
call
that
are
that
are
not
part
of
this
initial
draft
team.
Any
comments,
I
don't
want
to
call
you
all
out
by
name,
but
I
would
like
your
feedback.
You
know.
Is
this
something?
That's
you
find
useful.
Do
you
feel
that
it
there's
enough
information
that's
been
given
for
you
to
get
involved
in
potentially
the
editing
of
of
the
stories
or
the
crd
work
or
the
template
creation?
You
know
so
we
can
understand.
You
know
how
how
the
v2
ideas
are
different.
A
I
A
First,
I
agree
yeah.
Thank
you,
anakit
for
the
feedback.
Anything
that's
missing
that
we
are
are
not
addressing
that.
You
think
that
we
need
to,
as
as
that's
going
to
be
a
required
deliverable
for
the
larger
sig
network
group.
C
C
I
would
have
she's
just
curious
if
you
know
we're
looking
for
people
to
help
us,
maybe
own
and
hack,
on
some
of
these
different
things
in
smaller
groups.
You
think
you
might
be
interested
in
in
grabbing
the
reins
on
any
of
these
and
helping
out
with
with
any
of
these
specific
things
and,
if
so,
which,
which
ones
or
or
anybody
else
jacob
or
matt
or
anyone
else
or
shoe
fang
or
whoever
else
is
here.
A
Your
your
opinion
and
your
your
input
matters
right.
We
we're
glad
that
you're
listening
in,
but
we
also
want
you
to
get
involved
and
let's
see
if
we
can
push
this
together
as
a
community
not
trying
to
be
pushy,
but
I
I
think
the
whole
community
benefits
when
everybody
jumps
in
and
does
some
of
the
lifting
here.
A
So
if,
if
you
decide
that's
something
that
you
can
contribute,
please
in
the
next
couple
of
days,
go
in
and
submit
a
pr
to
the
readme,
with
your
name
on
one
of
these
areas
and
one
of
the
initial
draft
team
members
would
be
more
than
happy
to
spend
I'm
sure
30
minutes
or
an
hour
with
you
to
sit
down
and
talk
about
what
could
be
your
initial
contribution
and
and
would
be
there
to
help
you.
You
know
through
that
contribution
in
any
way
that
they
can.
A
So
I
want
this
to
again
be
you
know,
as
collaborative
as
we
can
so
please.
Let
us
know
how
we
can
help
you
get
involved
all
right.
So
jay,
you
talked
about
some
process
around
triaging
and
as
these
these
prs
come
in
and
and
kind
of
how
you
want
to
handle
this.
As
a
team
did
you
want
to.
Did
you
want
to
discuss
some
of
your
ideas
there.
C
Yeah,
I
was
just
hoping
cody,
we
could
you
know
people
could
file
issues
about
things
they're
concerned
about,
and
we
could
just
tackle
those
as
the
way
that
we
address
things
that
aren't
clear
yet
because
what
we've
been
doing,
you
know
before
seemed
to
just
been
a
lot
of
going
in
circles,
because
there
are
so
many
things
and
there
wasn't
a
targeted
goal
when
we
were
discussing
the
user
stories,
but
it's
it's
very
clear
that
there
are
people
who
really
do
want
to
continue
improving
the
user
stories.
C
So
I
was
thinking
to
raise
the
bar
for
how
we
talk
about
user
stories.
Is
you
know
so
that
the
conversation
has
a
little
more
information
content?
You
know
we'll
from
now
on.
We
we
file
an
issue
against
a
user
story.
If
we
think
it's
incorrect
and
we
specify
exactly
what
that
user
story
is,
and
we
we
just.
We
triage
it.
Just
like
any
other
issue
in
any
sig
wood.
You
know
and
we
will
just
work
through
it.
So.
A
I'm
going
to
make
one
recommendation
just
to
ensure
that
we
have
efficient
use
of
this
time
number
one
is:
I
think
that
the
interaction
in
the
community
needs
to
continue
to
be
async.
I
think
that
this
going
forward
this
hour
that
we
have
set
aside
every
week
should
be
used
to
review
what
changes
were
made
between
this
meeting
and
the
last
meeting
and
for
us
to
for
ones
that
seemed
to
be
more
contentious
or
had
more
discussion
about
right.
We
bring
those
to
the
forefront
and
share
that
with
the
overall
community.
A
If
there
were
things
that
were
simple
changes
that
there
was,
you
know
a
lot
of
agreement
on
then
maybe
we
we
push
those
to
the
bottom
of
the
priority
stack
and
then
that
way,
this
time
is
used
to
actually
discuss
things
that
we
did
have
contention
on
or
that
need
that
need
more
group
discussion
to
flush
it
out.
I
A
A
Is
there
anything
that
was
added,
and
I
know
we
talked
about
kind
of
the
structure
of
the
repo
and
some
of
the
initial
things
that
were
put
in
place?
Is
there
anything
that
we
want
to
review
that
was
initially
added?
That
may
have
enough
information
yet,
or
are
we
still
in
a
draft
stage
that
we
want
to
push
some
of
the
initial
review
to
next.
A
B
A
C
Yeah-
and
I
know
people
just
got
a
whiff
of
this-
I
know
andrew-
is
going
to
definitely
have
some
things
he's
going
to
want
to
just
to
clarify
also-
and
he
just
I
just
I
just
now-
sent
him
the
link
to
it
five
minutes
ago.
So
maybe
you're
right.
Maybe
it's
not
really
ready
for
a
full
triage.
Maybe
we
can
triage
this
async
and.
A
D
So
I
have
a
question
I
think.
D
A
So,
let's,
let's
go
over
the
motivation
and
then,
if
there's
additional
things
that
we
think
we're
missing
on
either
the
motivation,
the
goals
or
the
non-goals,
let's
go
ahead
and
get
these
itemized
and
then
once
we
have
a
good
outline,
we
can
start
converting
that
into
a
pros
for
the
actual
so-called
super
cap
that
we're
putting
together
here
so
number.
One
kubernetes
is
becoming
the
os
of
the
cloud.
G
So
one
thing
I
wanted
to
actually
I
tried
fixing
this
in
my
local
repository,
but
I
had
trouble
checking
it
back
in
somehow
so
I'm,
but
I
think
there
are
two
negatives
in
the
sentence.
It's
not
it's,
not
the
lack
of
deficiencies.
It's
it's
either
the
lack
of
order
deficiencies.
G
G
But
I
do
agree
with
the
general
premise
of
the
sentence
which
is
like
because
we
are
missing.
You
know
a
few
key
sort
of
you
know
ways
that
people
are
used
to
doing
say
firewalling
or
whatever
they
do
prefer
vendor-specific
apis
and
you
would
hear,
like
you
know,
hierarchy
and
deny
rules,
and
things
like
that
that
come
up
quite
frequently.
A
Yeah,
we
just
need
to
take
a
lack
of
out
of
there.
I
think
yeah
yeah,
that
makes
sense
perfect.
Cluster
administrators
need
apis
beyond
current
developer,
focused
apis
for
securing
the
cluster,
not
just
apps.
G
C
A
Possibly
maybe
we
should
have
a
related,
a
related
set
of
things,
because
I
think
in
the
real
world
you
know
auditing
is
you
know,
however,
we
construct
network
policy,
making
it
easy
for
cni
or
network
policy
enforcers
in
general
right
to
provide
auditing
is,
is
a
requirement
in
most
in
most
uses,
so
I'll
figure
out
how
to
break
that
out.
A
Sorry,
I've
got
children
in
the
background.
Making
lots
of
noise
apis
are
confusing
for
basic
use.
Cases
like
default
deny.
A
A
G
A
G
We
can
move
that
down
like
growing
the
sort
of
scope
and
breadth
of
of
the
functionality
of
network
policy.
The
last
bit
is
around
like
ease
of
use
and
the
middle,
I
guess,
is
more
enterprisey
stuff.
F
I
kind
of
remember
that
calico
they
have,
they
delivered
something
called
calico
network
policy
looks.
F
F
Like
from
their
documentation,
it
looks
like
their
calico
network
policy
can
provide
some
other
secure
options.
Besides
the
network
policy
api
that
we
are
providing.
A
C
Yeah
so
like
one
of
our
goals
would
be
that
people
can
still
use
calico
or
you
know,
tujara
or
whatever.
Vendor
is
involved
with
that,
but
at
least
when
they
write
those
network
policies.
C
Even
if
their
vendor
has
a
great
excellent
implementation,
they
don't
have
to
go
and
learn
some
vendor-specific
api
language
for
something
that's
so
fundamental
to
kubernetes
like
like,
like
the
network
policy
right
that
should
be
like
yeah.
Well,
I
was
going
to
say
one
other
thing.
It's
almost
like.
We
should
one
of
our
goals.
C
A
G
A
A
As
you
know,
if
we're
adding
new
things
and
such
we
want
to
make
sure
that
you
know,
there's
a
clear
distinction
between
the
new
way
and
the
old
way
of
doing
something
so
that
we
don't
we
don't
muddle
things
even
further,
if
they're,
already
confusing
or
and
or
break
something
did
that
did
that
make
sense,
or
do
we
need
to
add
more
clarity
to
that
statement.
A
A
A
What
we're
talking
about
specifically,
is
how
does
one
go
about
creating
the
upstream
resources
in
a
way
right
that
allows
you
to
migrate
from
from
one
api
to
the
other
api
or
or
to
you
know,
do
things
with
the
new
api,
while
you
still
may
have
things
that
are
operating
in
the
old
api,
so
I
want
to
clearly
separate,
like
the
actual
runtime
upgrade
of
an
enforcement
engine
or
cni
from
you
know
the
use
of
the
api,
and
maybe
we
need
to
call
that
out.
C
I
mean
that
said:
I
get
what
you're
saying
cody,
but
I
mean
given
that
one
of
the
things
we
want
to
do
ultimately
is
help
people,
if
we
can
to
use
policies
and
and
and
the
solutions
may
not
be
as
simple
as
changing
changing
the
apis.
C
I
wouldn't
rule
that
out.
I
wouldn't
rule
what
he
said
out
as
something
that
somebody
may
be
interested
in,
exploring
and
contributing.
I
just,
I
think
it's
harder
to
frame
that,
like,
like
you,
said
right,
it's
harder
to
frame
right.
A
Well,
some
of
the
migration,
for
example,
I'll
give
a
specific
example
right.
We
may
tackle
a
use
case
that
is
currently
solvable
using
a
vendor-specific
api.
Now
we
are
not
going
to
be
responsible
for
writing
a
migration
engine
that
goes
from
that
vendor-specific
api
to
the
to
the
upstream.
I
A
That's
true
develop
a
new
set
of
apis
for
application
policies.
I
didn't
write
this
one
who
who
submitted
this
one
that
wants
to
talk
about
that
sorry.
Did
we
skip
one?
A
G
C
Note
that
that
could
wind
up
being
an
opa
hook.
We
haven't
really
talked
to
the
opa
people,
but
the
policy
people
reached
out
a
few
weeks
ago
and
they
asked
if
one
of
us
could
come,
give
a
talk
over
there,
which
I
would
encourage
anybody.
If
you
wanted
to
do
that,
go
ahead
and
do
it
maybe
I'll
do
it,
if
not,
but
there's
a
policy
group,
and
this
might
wind
up
being
something
that
would
be
done
in
collaboration
with
them
or
that
they
may
be
more
appropriate
to
own.
I
think.
A
C
D
So
I
think
we
need
to
revert
the
previous,
the
administrator
api,
because
you
know
there
seems
to
be
some
sort
of
confusion.
I
think
there
are.
There
are
two
things
that
are
being
overloaded
there.
One
is
that
we
are
looking
to
write
a
new
resource
which
would
satisfy
all
the
administrator
user
stories.
D
So
that
would
be
you
know,
if
you
add,
into
a
cluster
scope,
network
policy
or
like
a
global
network
policy.
I,
I
wouldn't
say
global
sorry,
I
would
say
cluster
scope,
network
policy,
the
second
one,
the
current
one,
that
we
are
talking
about
like
a
developer
new
set
of
apis.
I
would
reword
it
as
develop
a
new
set,
slash,
update,
existing
network
policy
apis
which
are
meant
for
the
application
developers.
A
A
Next
goal-
and
I
know
we've
got
eight
minutes
left,
so
I'm
going
to
keep
moving
this
forward,
deliver
value
as
quickly
as
possible.
I
wrote
this
one
because
I
wanted
to
make
sure
that
part
of
the
reasons
of
breaking
the
stories
into
individual
caps
is
that
we
wanted
to
set
our
proposals
up
in
such
a
way
that
we
can
show
progress.
We
know
that
the
sig
network
is
loaded
and
especially
the
technical
review
that
happens.
C
A
Be
a
massive
overhaul
effort,
yeah,
better
documentation
was
a
goal,
and
I
think
I
don't
think
anybody
can
argue
against
that
generalize.
The
concept
of
endpoint,
not
just
pods
what
this
has
to
do
with
there's
a
couple
of
user
stories
around
targeting
workloads
that
are
not
native
kubernetes
workloads
as
an
example,
and
these
are
going
to
be-
you
know
where
we
target
things
like
I
p
addresses
network
sitters
or
a
named
resource.
That
includes
both
of
those
things
that
way.
A
Okay,
comprehensive
error
reporting
so
that
when
we
have
errors
occur,
this
is
somewhat
tangential
to
the
better
documentation
we
want.
We
want
better
runtime
information
from
our
tooling
from
our
logging
and
and
and
such
the
question
is,
is
where
would
we
draw
the
line
between
native
implementation
and
what
the
upfront
api
can
offer?
So
this
is
more
of
do
we
provide
some
type
of
a
facility
for
providing
feedback
as
part
of
the
api.
A
There
are
other
facilities
within
kubernetes
right
that,
like
events,
for
example,
that
can
be
recorded
against
crds,
and
so,
if
we
have
suggestions
on
improving
the
overall
usability
of
network
policies,
we
might
be
able
to
capture
various
pieces
of
feedback
as
an
event,
for
example,
and
and
make
that
as
a
requirement
for
compliance.
You
know
to
the
api
those
types
of
things:
oh
got
it:
okay,
yeah.
That
makes
sense.
G
A
Okay,
so
the
non-goals
and
then
we'll
wrap
up
the
meeting.
Graphical
user
interfaces
are
out
of
scope
in
general
right
we're
not
talking
about
building
the
next
ui
for
network
policy.
A
A
D
So
one
thing
that
I
saw,
which
is
missing
in
both
goals
and
non-goals,
is
the
the
you
know.
A
lot
of
user
stories
are
geared
towards
the
you
know:
more
visibility
into
the
into
the
policies
like
whether
my
policies
have
been
realized
correctly.
D
A
D
The
the
devops
tools
related
or
the
cli
related
things
you
know
like,
for
example,
I
I
need
to.
I
need
to
know
whether
my
pods
are
able
to
communicate
with
each
other,
because.
A
So
so
I
think
we
need
to
further
flush
that
out.
I
think
what
I'm
hearing
from
those
that
have
been
participating
is.
It
would
be
useful
to
have
a
defined
way
from
a
from
a
command
line
perspective
or
a
tool
set
perspective
to
query
and
interact
with
policies
we
might
similar
to
the
way
we're
developing
apis
for
network
policy
right.
We
may
say
that
hey,
if
you
enforce
network
policies
to
be
compliant
with
with
the
overall
user
tooling,
you
also
need
to
implement
a
a
native
tool
that
you
know
provides
these
querying
capabilities.
A
You
know
using
using
these
formats,
I
feel
like
it's
api
driven
right,
I
mean
the
cli
itself
is
an
api,
just
not
a
kubernetes.
You
know
crd
type,
api
right
and
you
know-
maybe
maybe
we
end
up
even
developing
a
query.
Crd
object
right
that
can
be
fulfilled
by
native
implementation,
so
I
don't
think
it's
completely
off
the
table
yet.
C
Yeah
I
mean,
I
think,
that
non-goals,
I'm
not
really
a
big
fan
of
being
super
like
restrictive
about
the
non-goals,
because
I
feel,
like
you
know,
I
feel
like
we.
We
do
need
to
spend
some
time
exploring
these
concepts,
and
I
feel,
like
some
of
these
non-goals
will
help
us
to
do
the
primary
work
that
we
need
to
do
so
I
feel,
like
I
almost
feel
like
the
non-goals
is
more
of
a
thing.
C
That's
a
kept
thing,
because
you
want
to
be
clear
about
exactly
what
you're
defining
and
some
of
the
things
from
a
formal
cap
may
not
have
a
perfect
impedance
match
to
what
we're
trying
to
do
here,
which
is
kind
of
build
a
community
right
and
the
community.
C
If
enough
of
us
are
interested
in
something
or
people
say
they're
interested
in
something.
I
think
that
that
helps
that
you
know
that
that
could
become
more
or
less
of
a
goal,
but
it's
certainly
not
a
primary
goal.
To
your
point,
abhishek
right,
like
yeah,
like
the
original
reason
we
formed,
was
not
to
build
a
command
line
tool
right.
So
I
I
think
that's
worth
specifying
too
that
you
know
not
all
goals
are
created,
equal
right.
D
Yeah
it's
worth
calling
out
because
even
though
it's
a
very
desirable
feature
or
user
story,
I
feel
like
you
know
that,
will
help
us
move
on
to
the
next
steps
of
actionable
items
and.
A
A
One
of
the
things
we
might
think
about
is
we
know
that
there's
the
concept
of
readiness
on
a
pod.
Well,
if
we
know
that
a
particular
pod
has
to
be
able
to
contact
a
particular
service
right,
we
might
want
to
build
in
as
part
of
that
readiness
check
the
capability
to
access
that
service
right
and
if
that
ever
changes
right
like
could
be
able
to
have
feedback
and
there's
other
ways
to
do
that.
A
Right
I
mean
the
pod
could
actually
query
that
service
and
if
it
can,
it
could
report
back
readiness
status
so
we're
getting
to
muddle
things
like
again.
This
was
just
off
the
top
of
my
head,
so
I
don't
say
that
it's
a
good
idea,
but
you
know
there
may
be
some
standard
way.
We
want
to
think
about
that.
C
A
So
so
we're
at
the
top
of
the
hour.
It's
it's
been
a
I
think,
of
a
useful
and
productive
meeting.
I
think
we
need
to
bring
it
to
a
close,
though
so,
if
there's
not
any
other
issues
that
the
community
wants
to
address,
please
we
will
link
out
this
repository
in
our
agenda
and
please
visit
this
repository
begin
making
some
pull
requests
by
friday.
We
should
be
putting
together
a
agenda
for
the
next
meeting
of
specific
pr's.
A
We
want
to
discuss
and
or
user
stories
etc,
and
let's
work
this
week
to
begin
fleshing
out
the
details
of
these
stories
and
begin
to
criticizing
them.
So
I
appreciate
everybody
jumping
on
board
today
and
at
that,
unless
there's
any
other
issues,
I'm
going
to
go
ahead
and
bring
this
to
a
close
yeah.
Please
do
file
issues
if
you
have
any
ideas.