►
From YouTube: Network Policy API Meeting
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).
B
What's
that,
okay
yeah,
do
you
all
see
the
spreadsheet?
Yes?
Okay,
so
hey
everybody!
Okay!
It's
see
it
is
the
10th
and
of
august.
So
this
is,
I
guess,
the
fourth
official
working
group
meeting
for
for
network
policy
v2
so
be
nice,
be
nice
to
each
other.
This
is
a
cncf
official
meeting
and
do
before
we
get
started.
B
Me
me
and
cody
kind
of
joined
a
little
early
to
try
to
see
if
we
could
get
some
of
this
stuff
converge
between
dan's
dock
and
the
user
stories,
and
I
looked
some
at
the
user
stories
a
little
bit
today
and
changed
a
couple
of
things
combined.
Some
stuff.
B
B
So
I
I
guess
the
first
set
of
things
I
wanted
to
bring
up
was
need
to
decide
what
to
do
right.
So
we
have
we
kind
of
have
a.
We
have
dan's
doc,
and
we
have
these
sort
of
user
stories
that
are
not
really
user
stories,
but
they're
sort
of
like
user
stories,
but
they
were
enough
to
get
the
conversation
started
and
I
think
there's
some
some
differing
opinions
on
what
to
do
next
and
different
people
want
to
do
different
stuff.
Some
people
want
to
do
more.
B
D
You
know
what
do
you,
what
do
you
mean
by
consumed
by
sick
network?
You
mentioned
something
about
slowing
down
and
having
it
consumed
by
network.
B
Yeah,
I
mean,
I
think,
there's
you
know,
there's
some
thought
that
we
we
have
these
user
stories
and
now
we
need
to
start
thinking
about
what
actually
is
practical
from
a
standpoint
of
what
can
get
done
and
and
what
what
we
can
do
and
what
we
can't
do
and
and
how
we
should
go
about
doing
things
and
and
so
on
you
know,
slow
down
is
probably
not
the
right
word
to
use
there,
but
it's
more
like
you
know.
B
We've
got
so
many
user
stories
in
here
and
we
have
to
think
about
like
what
like
what
we
can
accomplish,
what
we
can't
accomplish,
what
we
can
break
up
into
you
know,
community
projects
and
stuff,
like
that,
it's
kind
of
just,
I
think,
a
big
open
question
more
than
you
know
more
than
anything
else.
I
think
that,
in
absence
of
any
strong
opinions,
I
think
that
seems
like
the
lazy
consensus
would
be
to
move
forward
with.
B
What's
in
what
dan
has
because
he's
seemed
to
have
put
together
a
path
forward.
B
E
What
what
dan
did
a
good
job
of
us,
maybe
categorizing
and
classifying
some
of
these
stories
in
that
spreadsheet,
that
you
and
I
worked
on-
I
created
another
tab
where
I
started:
brainstorming
around
evaluation
criteria
and
I
think
it
would
be
a
useful
exercise,
maybe
to
talk
about
what
are
some
of
the
ways
that
we
want
to
evaluate
whether
a
user
story,
you
know,
meets
the
criteria.
E
B
B
Yeah
yeah
so
just
to
catch
everyone
up,
we
went
through
dan's
dock
and
kind
of
lined
up
his
high
level
categories
with
the
user
stories
that
were
there
so
that
we
could
get
some
feedback.
B
Try
to
quantify
some
interest
levels
in
the
various
stories
here,
with
the
understanding
that,
like
it's
kind
of
a
weird
thing,
I
I
was
telling
this
to
cody
that,
like
it's
like,
it's
not
like
any
user
is
going
to
say
they
don't
want
a
feature.
So
there
may
not
be
a
whole
lot
of
like
meaning
to
this
meaning
to
how
many
votes
we
get,
but
we
we
can
try
anyways,
you
know
we
could
do
the
thing
we
we
talked
about
a
couple.
B
I
think
it
was
a
month
ago
where
we,
where
we
basically
said
everybody
gets
one
or
two
votes
or
something
like
that,
but
I
think
the
big
I
don't
know
if
you
want
to
call
it
a
breakthrough,
but
we
we
were
talking
about
personas
here
and
I
think
one
of
the
things
we
need
to
add
to
these
is
personas.
B
For
each
one
of
these
and
make
sure
that
we're
very
clear
about
which
which
personas
are
are
really
in
support
of
these
things
so
yeah
but
yeah,
I
think
the
broader
question
to
go
back
abhishek
to
what
you
mentioned
is:
does
anybody
there's
the
other
thing,
as
does
anybody
have
any
use
cases
specifically?
They
want
to
talk
about
this
week,
because
these
continue
to
improve
and
get
better
and
get
re-categorized,
and
things
like
that
they're,
I
think,
reaching
an
asymptotic
state,
but
you
know
there's
always
more
to
do.
B
Yeah,
okay,
so
so
we
have
our
spreadsheet
now
and
so
cody.
What
do
you
think
I
mean
this
is
really
open
to
anybody,
but
what
do
you
think
we
should
do
here.
E
Get
to
some
type
of
an
objective
measurement
right
we
need
to.
We,
we've
got
to
come
up
with
a
way
to
score
like
what
we've
done
so
far,
and
so
that's
why
I
had
focused
on
some
of
the
criteria
for
for
measuring
this,
and
then
we
can
weight.
You
know
the
importance
of
those
criteria
and
actually
have
people
weigh
in
instead
of
just
a
simple
up
down
on
vote
right.
E
I
I
think
it
might
be
more
useful
to
to
look
at
the
different
dimensions
of
you
know,
each
story
and
and
how
important
it
is
to
users
from
different
perspectives.
So,
if
everybody's
up
for
it,
I
think
we
could
spend
maybe
15
20
minutes
just
looking
at
you
know.
How
do
we
want
to
evaluate
the
criteria
for
these
user
stories?
E
E
So
what
I,
what
I
put
together
here,
is
as
again
just
a
very
rough
brainstorm.
I'm
sure
I've
missed
several
things
here.
So
please,
you
know.
Everybody's
input
is
very
valuable
to
me
here.
I
started
with
you
know
some
criteria
like
the
most
basic
criteria
we
came
up
with
early
on
was:
does
this
even
relate
to
the
api?
E
You
know
if
it's
something
that
is
not
a
implementation,
that's
involving
the
api,
then
that
should
be
kind
of
a
a
first
cut
right,
and
so
you
know
we
can
give
that
a
pretty
high
weight.
You
know
what
is
the
there's
two
different.
You
know
groups,
I
think
that
are
involved
in
this
working
group.
You
know,
there's
we
have
representatives
from
those
that
are
actually
implementing
solutions
for
for
network
policy.
You
know
for
enforcing
it
and
we
have
users
here
that
are
actually
using
network.
E
Does
the
solution,
or
the
story
you
know
is
this
is
sorry-
is
the
solution
to
a
story
going
to
improve
usability
for
network
policy?
Is
it
going
to
improve
multi-tenancy
for
network
policy
and
then
maybe
even
look
at
you
know
we
might
wait.
You
know
what
we
work
on
by
who
it
benefits
right.
Is
the
solution
going
to
benefit
an
application
developer
versus
a
cluster
administrator
versus
a
class?
You
know
a
security
administrator.
There
may
be
some
other
personas
right.
We
may
want
to
consider
and
talk
about
how
to
differentiate
those
right.
B
Yeah
we
have
that
other
spreadsheet
and
then
so.
This
is,
I
think,
a
better
version
of
that
spreadsheet,
because
it's
informed
by
the
categories
that
dan
has
right.
So
sorry,
so
apologies
to
those
of
you
that
we
that
did
this
with
us
before
but
we're
gonna,
do
it
again,
but
I
think
it'll
be
the
last
time.
So
so
what
how
do
you
want
to
do
that?
I
mean,
should
we
just
so?
Do
we
want
to
just
like?
Should
we
should
we
do
an
active
like
go
through
each
one.
E
Of
these
well,
let's,
let's,
let's
just
stick
to
the
evaluation
criteria:
first,
right
before
we
actually
start
trying
to
apply
it,
and
let's
talk
about
like
what's
important
for
evaluating
network
policy
stories,
yeah,
let's
just
open
the
floor
to
see.
If
the
community
has
some
suggestions
on
this
on
how
we
can
improve
the
criteria.
E
B
B
G
B
Thanks
awesome,
so
we've
yeah,
so
so
the
original
thing
we
do.
Okay,
I'll
do
the.
Let
me
do
the
like
little
two
minute:
here's
what
we
here's,
what
we've
been
up
to
so
this
was
all
started
from
a
thread
about
two
months
ago,
where
we're
going
through
a
few.
I
was
going
through
a
few
things
in
types.gov
for
some
other
network
policy
related
stuff
that
I
was
doing,
and
I
just
had
some
questions
about
some
things
and
it
started
becoming
more
and
more
clear
that
there
was
a
lot
of
things.
B
So
we
had
an
informal
meeting
a
little
group
to
talk
about
this
stuff
and
then
that
informal
group
kind
of
turned
into
an
actual
working
group
a
couple
of
weeks
ago
per
one
andrew's
idea,
and
and
so
we
we
became
a
real
working
group
and
to
kind
of
formalize
this
stuff
and
really
it
was
all
just
started
with
oh
gosh.
There's
all
these
things
about
network
policies.
B
We
may
want
to
change
at
some
point,
so
let's
actually
start
a
conversation
around
it
and
collect
some
data
about
how
people
feel.
So
we
collected
all
these
api
stories
and
then
we
realized
we
collected
way
too
many
api
stories
and
cert
user
stories
and
some
of
them
weren't
really
user
stories,
and
some
were
so.
B
We
all
kind
of
went
off
and
tried
to
summarize
them
in
our
own
different
way
and
of
course,
dan
winship,
who
you
know
did
so
much
of
the
original
work
you
know,
along
with
casey
and
other
people
on
the
original
network
policies
came
up
with
a
sort
of
end
sort
of
a
really
nice
sort
of
engineering.
B
Categorization
of
these
in
terms
of
what
these
high
level
sort
of
goal
categories
of
these
things
were,
and
he
made
this
dock,
and
so
now
going
back
to
taking
these
detailed
user
stories
that
people
have
sort
of
written
up,
which
we
continue
to
iterate
on
over
time
and
combining
that,
with
these
higher
level
categorizations
for
network
policy
for
these
various
user
stories,
that
dan
has
we're
now,
basically
trying
to.
B
This
is
roughly
what
we
might
want
to
build
at
some
point,
and
I
think,
actually
you
know
one
of
the
one
of
the
things
that
we're
kind
of
I
feel
like
we're
running
into
now
at
this
point
is:
what
are
we
actually
going
to
do,
because
we
we
kind
of
have
all
this
data
that
we've
collected
and
we
we
need
to
figure
out
what
we're
actually
going
to
create,
and
I
I
was
so
so
so
I
was
going
to
you
know,
suggest
possibly
you
know,
opening
up
the
opening
up
the
conversation
about
as
a
group
like
what
what
do
we
see
ourselves
doing
a
month
or
a
week
from
now
and
you
know,
and
so
on
and
so
forth,
so
we're
kind
of
in
a
transition
point
where
we've
gone
from
talking
to
all
these
ideas,
like
here's,
all
the
things
that
people
visually
have
proposed
right
to
to
actually
trying
to
create
some
kind
of
an
artifact,
something
that
we
can
give
to
the
sig.
A
Yeah,
so
going
back
to
cody's
point,
I
think
these
are
pretty
pretty
good
criterias.
I'm
like
I
really
like
the
api
related
one.
I
feel
like
there
are
a
lot
of
user
stories
about
like
tooling
or
making
like
making
consumption
of
network
policies
easier
or
like
observability
of
of
or
not
observability,
but
there's
a
lot
of
ones
around
like
just
like
tooling
around
our
policies
that
I
feel
like.
A
Maybe
we
should
just
like
those
wouldn't
pass
the
api
related
criteria,
and
so
maybe
that
would
reduce
the
scope
of
what
we're
talking
about
here.
B
A
Yeah
exactly
I
mean
we
should
we
should
jot
it
down,
but
like
but
yeah
I
feel
like.
We
don't
want
to
spend
too
much
time
to
keep
out
those
if,
if
it's
not
eventually
going
to
make
it
into
like
make
it
into
the
api
as
a
concrete
change
that
people
can
consume.
B
Yeah
now.
A
I
mean
I
kind
of
consider
that
as
part
of
v1
compatibility,
because
to
me
like,
for
the
most
part
like
the
way
at
least
I've
been
seeing.
It
is
that
I'm
categorizing
the
problems
as
two
things
like
easy
additions
to
v1
that
aren't
going
to
be
breaking
changes
and
then,
like
the
v2,
like
far
in
the
future,.
B
What
about
like
services?
That's
the
one
that
I'm
thinking
of
right,
andrew,
like
services,
is
a
weird
one,
because
this,
the
semantics
of
how
you
would
add
a
service
level
construct
to
v1,
seems
to
me
like
it's
a
lot
harder
than
like
things
like.
You
know,
something
like
like
what
are
the
other
ones
like
where
where's.
D
I
think
adding
services
to
the
existing
v1
is
is
pretty
similar
to
other
cases
where
you
know
you
have
one
way
of
doing
things,
then
you
don't
want
to
introduce
another
way
of
just
just
in
order
to
simplify
things.
Unless
we
are
starting
from
scratch,
whether
let's
say
our
application
developers
specific
apis,
then
maybe
we
can
start
thinking
about
you
know.
Maybe
if
network
policies
did
not
exist,
do
we
want
to
start
off
with
a
service,
selector
or
part
selector,
but
as
an
addition
to
the
existing
v1
apis?
B
A
Know
yeah,
I
agree
with
abstract
and
which
is
why
I,
like
the
criteria
that
cody
put
around
v1
compatibility
like
difficulty,
is
a
more
it's
more
subjective,
whereas
we
can
it's
much
more
easier
to
reason
about,
like
u1
compatibility.
E
D
B
E
B
Oh
yeah,
that's
true!
That's!
No!
That's
not
going
to
be
an
easy
thing
to
resolve.
I
mean
we
might
as
well
just
keep
the
criteria
here
right
criteria.
Extra
criteria
is
not
going
to
hurt
us
right.
So
let
me
move
this
down.
Okay,.
E
A
A
B
Yeah
I
mean
it's,
that's
a
weird
one,
because
we
have
those
user
stories,
so
people
are
asking
for
syntactic
sugar.
The
question
is:
are
they
asking
for
something?
That's
not
in
their
own
in
best
interests,
because
they
haven't
thought
things
through
and
realized
that
having
two
ways
of
doing
things
makes
things
complicated
or
it's
because
they've
thought
of
things
that
we
haven't
thought
of
before
the
best?
One
is
example:
cody
is
your
synthesized
labels
thing
right
like?
Where
does
where
does
that
fall?
B
Let's
look
at
our
syntactic
sugar
ones.
We
have
like
a
we
call
it
syntactic
candy.
I
guess
we
don't
call
it.
We
call
it
sugar
now
right,
yeah
namespace
by
name
I
mean,
I
think
this
one.
B
H
A
I
D
Yeah-
and
this
is
why
I
I
think
that
this
probably
makes
sense
more
for
the
administrator
specific
policies
than
the
developer
focus
policies.
I
B
I
don't
know
what
category
I
put
this
in,
because
there's
some
people
that
would
use
it
as
an
easier
way
to
allow
something
and
then
there's
other
people
that
would
use
it
to
solve
an
actual
engineering
problem
around
labels
right,
so
it
definitely
could
be
perceived
as
syntactic
sugar
in
the
former
use
case.
B
E
Well,
I
didn't
mean
that
to
be
self-referential,
I
I
assumed
that
everybody
would
understand
what
syntactic
sugar
is,
but
we
could
define
syntactic
sugar.
I'm.
B
Yeah
I
mean
only
in
the
case
of
this
one,
where
it's
removing
it.
I'm
thinking
like
what
are
we
calling
syntactic
sugar,
okay
yeah,
not
to
like
turn
that
into
a
big
bike
shed,
but
let's
put
something
in
there
other
than
syntactic
sugar.
B
B
B
A
B
Means
I'm
just
well
yeah.
I
think
we
are
going
through
the
criteria.
I
just
looking
at
the
three
examples
here.
The
it's
that
pod
note
ip
addresses
pod
node
ips.
Is
that
a
syntactic
sugar
one?
B
A
I
I
think
it'd
be
fine,
just
to
have
the
first
five
like
I
think
multi-tenancy
is
important,
but
I
think
it
might
be
adding
a
bit
too
much
complexity
in
this
at
the
start.
So
I
think
yeah,
like
api,
related
user
and
implementer
priority
compatibility
and
usability,
are
pretty
good.
I
think
it's
the
rule
for
now,
like
even
syntactic
sugar
like
as
we
talk
about
it,
I
don't
think
we
need
to
add
a
category
for
that.
H
Think
mean
on
multi-tenancy.
I
guess
it
depends
on
how
much
we
consider
that
to
be
a
you
know,
primary
driver
of
the
working
group's
work.
You
know
we
can
either
treat
it
as
a
first-class
thing
or
just
as
another
feature
that
some
users
want
right.
D
So
to
clarify
the
multi-tenancy:
does
it
reference
tendency
as
a
name
space
or
a
tendency,
as
the
cluster
scope.
E
E
Hold
on
it
may
also
be
not
only
that
the
it
may
not
only
be
addressing
the
workloads
that
are
running
on
the
cluster,
but
also
the
personas
that
can
modify
those
workloads
right.
So
maybe
we
have
different
actors
that
are
involved
in
setting
up
the
policy
right
from
you
know
the
operators
of
the
cluster
to
the
security
administrators
to
the
developers.
E
D
E
D
E
That's
probably
true,
I
didn't
know
how
granular
we
wanted
to
make
personas
right,
so
some
people
look
at
an
auditing
function
as
separate
from
an
administrator
function
is
separate
from
maybe
a
network
operator
or
global
administrator
administrator.
Now
these
may
not
apply
here
in
the
sig
right.
These
may
be
more
specific
implementations.
B
D
So
but
my
my
my
statement
was
mainly
in
the
context
of
network
policy.
Apps
right
do
we
need
to
worry
about
having
a
separation
amongst
cluster
and
a
security
administrator.
B
A
E
If,
if
we
allow,
for
example,
a
cluster
administrator
would
be
more
kind
of
a
you
know
the
super
admin
he
can
basically
make
any
changes.
Any
network
policy
where
a
security
administrator
may
be
able
to
specify
policies
that
impact
multiple
tenants
or
cross-tenant
communication,
but
may
not
be
able
to
configure.
You
know
policy
for
the
entire
for
the
entire
cluster.
It
it
again
it's
it's
part
of
it's
a
discussion
of
how
granular
you
want
your
tendency
to
be
and
how
many
tiers
you
want,
and
you
know
there
are
different.
E
There
are
different
implementations
out
there,
and
so
I
didn't
know
how
closely
we
want
to
mirror
that
with
upstream
policy
right.
So
some
of
the
specific
cni
providers
provide,
you
know
additional
granularity
in
terms
of
how
how
those
concerns
are
separated
from
it
for
policy
administration,
okay,.
B
I
mean
it's
a
little
confusing
to
me.
I
kind
of
am
like
unless
there's
a
really
good
reason
to
have
it
like
there's
a
policy
we
can
think
of.
I
kind
of
feel
like
we
should,
but
I
don't
know,
I
don't
think
it
matters
again.
I
think
these
are
additives,
so
I
don't
think
they
matter
like.
I
don't
think
if
we
find
this
information
for
one
of
them
it
you
know,
I
don't
think
it
hurts
us.
B
So,
unless
anybody's
offended
by
any
of
these
or
thinks
they're
going
to
really
lead
us
in
the
long
direction,
I
think
we
just
go
with
all
of
them
and
we'll
see
which
ones
work,
but
I
have
no
idea
what
to
do
with
weights.
That's
where
it
gets
really
tricky
for
me,
because
why
would
how
do
we
like
one
I
mean
we
know?
Api
related
is
high
right.
We,
we
don't
really
have.
B
E
A
number
well,
the
weights
are
going
to
are
going
to
determine.
You
know
how
much
a
particular
criteria,
how
much
selection
you
know
capacity.
A
particular
criteria
carries
right,
but
typically
your
weights
would
add
up
to
a
hundred
percent
right
and
you
can
make
each
each
criteria.
You
know
if
they're
all
equally
weighted,
then
we
divide
by
the
number
of
criteria
100
divided
by
the
number
of
criteria.
E
If
we
think
one
particular
criteria
is
more
important
than
another,
we
give
it
more
weight
so
that
when
we
actually
begin
scoring,
the
other
thing
we
have
to
do
is
put
a
scale
right
of
some
sort
for
for
the
different
categories,
but
as.
C
B
E
B
B
E
E
Three,
so,
for
example,
if
if
we
think
I'll
give
you
a
good
example,
we
may
choose
to
weight
people
suggesting
user
priority
over
provider
priority
right,
because
you
know
at
the
end
of
the
day.
You
know
we
don't
want
necessarily
a
provider
building,
something
that
a
user
is
not
going
to
use.
However,
a
provider
may
have
some
insight
to
something
that
a
user
doesn't
right.
So
you
know
it's
it's.
Where
do
we
want
to
get
priority?
You
know
to
to
a
story.
E
The
other
thing
is
like,
for
example,
api
related
should
be
probably
a
pretty
heavy
weight
right,
because
that
should
be
a
you
know
that
should
be
kind
of.
Like
a
you
know,
a
high
pass
filter
right.
I
mean
that,
should
yeah
cut
out
all
the
stories
right
that
don't
right,
regardless
of
the
other
pieces
of
this,
of
the
criteria
right,
I
would
give
you
know
that
the
biggest
weight.
B
E
B
E
For
50
for
api
related
right,
that's
kind
of
a
very
important
one,
and
then
I
would
basic
you
know.
I'd
give.
This
is
important.
I'd
give
like
maybe
15
to
user
priority.
B
E
And
then
you
know
is
is,
for
example,
is
a
usability
as
important
as
v1
compatibility,
which
one
do
we
consider
more
important.
C
A
E
E
B
I
mean
it
seems
like
really
now
going
through
these
we're
going
back
to
andrew's
thought
earlier,
which
is
that
some
of
these
might
just
almost
not
be
worth
waiting.
Syntactic
sugar,
we
don't
even
know
if
it's
well.
B
B
C
Whatever
equal
sum
equal.
E
C
E
E
E
You
know
we
think
application
developers
are,
you
know,
probably
60
drop
the
security
administrator
for
now.
Just
have
it
too.
Maybe
we
do
like
you
know,
70,
30
or
60
40
on
on
that.
E
B
E
Just
in
case
it
doesn't
matter,
I
mean,
I
think
we
all
get
it
all
right.
How
do
you
say?
60
40,
maybe
or
something
like
that
for
now,
we
may
change
your
mind
right
after
we
talk
to
other
people
weigh
in
they
may
say
no
actually.
For
this
you
know
the
purpose
of
this.
We
actually
want
to
give
more
credence
to
cluster
administration
right.
So
that's
something
that
the
the
group
needs
to
weigh
in
on
okay.
E
We
we
have
several
people
in
this
call.
Right,
I
mean
don't
be
afraid
to
speak
up
here.
We
we
need
everybody's
opinions
right,
we've
had
about
four
people,
primarily
speaking
so
I
know
there's.
I
know,
there's
a
lot
of
great
ideas
from
the
folks
on
the
call.
Please
please
chime
in.
D
Maybe
maybe
you
want
to
like
do
a
sample
example
of
how
how
to
use
that
these
these
evaluation
criteria,
just
so
that
everyone
knows
how
to
use
it.
Sure.
E
E
E
E
E
Way
that
it
would
work
abhishek
is,
we
would
apply
columns
on
the
user
stories
right
and
then
people
could
could
weigh
in
on
their
scale
like
how
they
rated
each
one,
and
maybe
we
you
know,
potentially
even
duplicate
this
and
everybody.
You
know
fills
it
out
and
we
combine
all
the
results
or
something
that
would
be
one
way
to
do
it
or
we
just
have
a
you
know
a
master
and
just
have
comments
on
each
section
or
on
each.
You
know
one
well,
we
just
discuss.
B
E
Usability,
we
had
improved
multi-tenancy
and
syntactic
sugar.
E
So
what
I
had
intended
it
to
mean
was,
if
there's
a
user
story
that
is
suggesting
a
change
be
made.
That
is
already
accomplishable
with
the
existing
api.
For
example,
we
had
a
story
about
adding
another
another
level
of
abstraction
right
in
terms
of
forming
groups
and
things
right,
which
we
already
have
the
possibility
of
using
labels
to
to
accomplish
what
that
user
story
was
setting
out
to
achieve.
E
I
believe-
and
so
that
would
be
an
example
of
syntactic
sugar
right,
just
adding
another
level
of
abstraction
or
another
way
of
specifying
policy
that
accomplishes
the
same
goal
and
it
may
improve
usability,
but
there
are
probably
usability
improvements
that
are
not
possible
now,
because
a
feature
is
not
supported
or
something
like
that
right
usability
is
not
just
in
the
use
of
the
api
it
could
be
in
usability
could
be
an
improvement
in
how
we
actually
segment
applications
as
well
right.
The
api
doesn't
support
yet.
B
E
I'm
sorry
who
asked
that
question
me,
I'm
sure
yeah
okay
did
that.
Did
that
answer
your
question.
J
Yeah
part
of
it
yeah,
I'm
still
like
wondering,
I
think
there
there
are
network
policy
and
then
there
are
plugins
to
apply
those
network
policy.
So
this
syntax
tactic,
sugar
improvement
happened
in
in
which
part
is
that
in
the
network
policy
part,
or
is
that
in
the
plug-in
part
or
is
that
in
the
kubernetes,
the
kubernetes
system,
support
of
the
net
network
policy
part
I'm
just
wondering
like
where?
Where
does
it
happen?.
E
E
B
Yeah,
it
makes
me
kind
of
question
this
field
now
come
now
that
we're
talking
about
it,
because
I
didn't
really
think
about
it
before,
but
now
I'm
thinking
about
it
more,
I'm
like
yeah
that
api
related
thing
is,
is
weird
because
everything's
api
related,
but
listen.
E
B
D
Yeah,
I
think
there
are
some
dueling
related
yeah
like.
B
Yeah,
so
let's
do
one
for
practice.
I
I
mean
we've
got
10
minutes
left.
I
don't
see
why
we
can't
you
know
try
at
least
a
couple
of
these
for
practice.
E
E
B
Folks,
this
spreadsheet
is
here,
and
it's
I'll
put
it
in
the
in
the
original
link.
Here
this
way
we
can
just
kind
of
get
some
progress
done,
asynchronously
here
and
move
forward
with
this
thing,
because
I
think
I
think
people
are
people
are
ready
to
see
something
see
something
happen
here
so
and-
and
you
know,
maybe
reach
some
conclusions
so.
E
Please
we
did
have
a
point
here:
do
are
we
in
agreement
on
the
weights?
Do
we
we
want,
to,
you
know,
spend
some
time
just
making
sure
that
the
weights
are
right
before
we
actually
start
up
trying
to
apply
scale
to
individual
policies?
I
know
I
know
we're
eager
to
get
get
on
that,
but
but
let's
make
sure
that
you
know
we
have
our
weights
correct.
We
haven't
really
heard
a
lot
of
other
people
weigh
in
on
that.
B
I
I
have
no
opinion
on
the
weights
so
get
let's.
Why
don't
you
two
decide?
I
I
feel
like
yeah
good,
I
feel
like
they
may
change
over.
G
E
E
B
Yeah
because
different
there's
a
different
there's
going
to
be
variables
once
you
actually
look
at
the
user
stories,
so
there's
going
to
be
a
variable
like,
for
example,
let's
just
take
an
example
to
make
that
concrete.
So
this
one
is
not
an
api.
I
think
you
have
a
good
point,
which
is
kind
of
why
I
don't
really
care
about
the
weights
to
some
extent,
but
there's
but
like
what
like
this
one
will
have
a
api
related
of
zero
right,
because
we
know
it
has
nothing
to
do
with
the
api
or
like
this.
B
B
This
is
going
to.
This
is
gonna,
be
api
related
for
sure
so
quantitatively,
because
the
weight
is
so
high
right,
because
the
weight
for
api
is
so
high.
It's
gonna
automatically
make
it
so
that
there's
basically
no
way
that
we
ever
prioritize
this
over
this
right.
So
in
an
ex
that's
an
extreme
example
of
why
it's
valuable.
E
E
You
know
what
are
the
larger
themes
in
terms
of
improving
the
api,
and
so
really
the
the
weighted
category
or
the
rated
criteria,
rather
are
dealing
with
those
larger
themes
and
if
there's
a
theme,
that's
missing
here,
you
know
this
is
where
we
need
to
add
it
in,
so
that
we
can
better
objectively
select
from
a
lot
of
different
perspectives.
B
B
But
I
mean
I
think,
it's
a
fair
point.
You
make,
I
think,
to
some
extent
we
kind
of
it's
kind
of
a
foregone
conclusion.
We
kind
of
know
that
this
is
probably
what
we're
going
to
do
and
the
other
stuff
we're
probably
not
going
to
really
do
so
we're
just
kind
of
going
through
the
motions
to
some
extent
here
we
should
probably
be
transparent
about
that.
E
Yeah,
but
it's
not
a
one-to-one
mapping,
so
yeah,
I
still
think
we're
going
to
have
some
selections
fall
out
that
we
may
not
expect
yeah,
absolutely
yeah
so
again
back
to
andrew's
point:
let's
try
to
get
agreement
on
the
weight,
so
we
said
that
we
want
more
on
improved
usability,
so
let's
bump
that
up.
So
what
are
we
going
to
take
away
from
so
like?
I
would
almost
say
that
improved
usability
is
right,
but
I'd
almost
give
it
a
15
right,
which
is
good.
I
know
it's
going
to
put
us
over.
E
A
G
A
Yeah,
what's
interesting
about
api
related
is
that
if
something
is
not
api
related,
it
would
also
be
bumped
down
for
v1
compatibility.
So
that's
right
something
to
consider
it.
B
Personally,
I
I
think
some
of
the
non-api
related
things
are
actually
kind
of
interesting
they're,
just
not
that
it's
working
yeah.
B
Yeah,
well,
that's
the
point
I'm
making
is
that
we
need
to
take
that
stuff
and
move
it
somewhere
like
when
we're
done
with
this
right,
so
that
everything
is
api
related.
B
E
So
I
see
I
see
a
lot
of
folks
that
are
a
little
quieter
on
the
call.
So
I
mean
I
I
see
prabh
on
here
and
matthew
on
here
and
and-
and
I
think
foreign
you've
said
a
couple
things.
What
do
you
all
think
jobs
in
perspective
on.
E
E
We've
got
jacob
on
here
and
niha
and
a
kid
if
I
mispronounce
your
name,
I
apologize
again.
I
don't
have
a
very
strong
opinion
on
the
brains,
but
this
works
okay
and
that's
okay
too.
I
just
I
just
want
to
kind
of
understand
like
how
passionate
and-
and
you
know
I
don't
want
us
to
you-
know,
turn
this
into
a
three
or
four
person
decision
right
like
this
is.
This
is
important
to
the
whole
community.
K
Yeah,
I
agree
with
most
of
the
weights.
I,
although
I
do
think
that
the
user
priority
should
be
higher
okay.
Otherwise,
I
think
those
weights
make
sense,
but
I
guess
it
was
ajith
or
somebody
I'm
not
remembering
who
brought
up
a
point
that
most
of
the
ones
that
we
have
most
of
the
user
stories
would
potentially
already
have
more.
K
Relevance
only
to
specific
criteria
than
others,
so
it
will
probably
boil
down
to
like
the
weights,
are
more
or
less
indicative
of
the
priority,
although
we'll
see
how
it
pans
out
like
we
don't
know
that
yet.
But
I
would
at
least
given
the
split
right
now.
I
would
like
the
user
priority
to
be
weighted
a
little
bit
higher.
E
E
A
great
question
so
that
actually
makes
another
possible
interesting
category.
I
know
we've
hit
the
top
of
the
hour
here,
but
one
other
question
we
might
want
to
ask
in
in
rating
these
stories
is:
is
this
story
being
addressed
by
what
I
would
call
a
native
policy
rather
than
an
upstream
kubernetes
network
policy?
Now
and
users
are
tending
or
gravitating
toward
that,
because
it's
not
implemented
in
upstream
right?
That
might
be
another
interesting
measure.
E
So
the
way
that
I
would
I
would
couch
that
would
be
here
I'll,
just
type
it
in.
F
E
B
B
In
okay,
so
I
think
I
know
we're
at
the
top
of
the
hour,
but
I
just
do
want
to
ask
this.
I
want
to
go
back
to
my
one
of
the
original
things,
which
is
what
do
we
want
the
goal
for
next
meeting
to
be,
and
what
do
we
want
our
goal?
B
What
do
we
want?
Our
short-term
goal
to
be
as
a
group,
because
I
feel
like
I
do
feel
like
we're
reaching
a
point
where
feedback
is
is,
is
increasingly
sparse,
and
I
think
that
one
of
the
reasons
is
that
I
think
people
have
gone
through
this
stuff
a
few
times.
B
And-
and
I
think
I
think
we
either
you
know-
we
either
kind
of
define
an
endpoint
for
this
first
phase,
or
I
think,
what's
gonna
happen
is
we're
just
gonna
kind
of
we
kind
of
we're
just
going
to
kind
of
bike
shut
a
little
throughout
the
next
few
calls,
and
probably
the
overall
interest
will
drop
over
time,
and
I
think
you
know
I
don't.
I
don't
think
that's
the
best
situation
to
be
in
so
like
what
do
you
think
our
goal
should
be
for
the
next?
E
I
suggest
everybody
get
onto
the
agenda
and
actually
write
their
those
goals
out
and
then
we
can
review
them.
So
everybody
can
get
input
on
that.
B
B
That's
my
that's
kind
of
my
open
question
right
he's
like
I
don't
want
to.
I
don't
want
to
force.
I
don't
want
to
force
a
timeline
or
anything
on
anybody,
but
you
know,
and
I'm
not
sure
that
you
know
I
mean
I
think
we
probably
need
a
few
people
to
propose
a
few.
I
know
I
mean
andrew
cody,
whoever
else
anybody
else.
I
think
we
should
probably
talk
in
a
follow-up
this
week
about
what
we're
what
our,
what
our
timeline
is,
for.
B
E
Yeah,
okay,
one
one
thing
that
I
would
like
to
point
out,
though
I
I
do
think
it's
important
that
we
keep
it
all
on
this
community
meeting
just
just
to
maintain
the
structure
of
the
working
group-
and
I
I
don't
want
there
to
be
anything-
that's
closed
off
right.
Some
people
don't
feel
like
they
can
participate,
so
let's
definitely
keep
it
open
in
this
meeting.
E
I
I
think
if
everybody
wants
to
get
onto
the
agenda
and
offer
some
suggestions
on
timelines
and
goals,
then
that's
something
that
we
can
definitely
talk
about
at
the
beginning
of
next
meeting,
yeah.
Okay,
back
on.
B
Yeah,
I
think
next
meeting
I'm
gonna,
I'm
gonna.
I'm
fine
wait
doing
this
next
week.
You
know
you
have
a
good
point
right
like
we
probably
should
do
this
in
the
meeting.
I
I
you
know
I
feel
like
we
gotta
yeah,
so
I
think
yeah,
I'm
gonna
just
say
next
meeting
we
need
to
decide
just
I'm
gonna
decide
on
timeline
goals
and
frequency.
I
think
we
need
to
reevaluate
all
three
of
those
right
and
I
think
we
should
probably
do
that
before.
B
We
do
anything
else,
because,
because
I
think
that
you
know,
I
think,
we've
we've
gotten
a
lot
of
a
lot
of
feedback
from
people,
and
I
think
people
are
running
out
of
things
to
say
at
this
point.
E
You
know
sorry,
I'm
playing
police
cop
here.
I
know
that
we're
at
the
top
of
the
hour
and
other
people
may
have
other
meetings
to
pop
to
so
I
just
maybe
we
should
call
it
for
today
and
then
get
on
the
agenda.
You
know
add
your
thoughts
there.
Look
at
these
spreadsheets
add
some
comments
there
and
and
we'll
see
everyone
next
week.
I
think
we
made
some
progress
today.
Yeah,
let's
do
that
yeah.
Let's
do
this.
B
On
monday,
okay,
cool
thanks:
everybody.