►
Description
WG-Network Policy API Bi-Weekly Meeting for 20220509 (part 2)
A
Hello,
everyone
today
is
may
9th
2022
the
week
before
or
of
cubecon,
and
this
is
a
meeting
of
the
sig
network
policy,
api
subgroup
district
network.
This
is
a
cncf
certified
meeting,
so
please
be
nice
to
each
other
and
no
cursing
and
yeah.
Let's
have
a
good
meeting
today
so
hopping
right
into
more
work
on
the
admin
network
policy,
api,
specifically
the
semantics
of
the
pr
to
do
that
itself.
A
So
let
me
pull
up
my
screen
here
and
we
can
kind
of
discuss
some
of
dan's.
Most
recent
comments:
a
lot
of
nets.
I
clearly
am
not
that
great
at
proofreading,
my
my
own
spelling
so
sorry
about
that,
but
I
think
we
can
talk
about
some
of
the
more
major
things
and
he
also
added
something
to
the
agenda
about
this,
so
the
first
one
was
basically
trying
to
make
subject
and
pure
more
parallel.
A
So,
basically,
like
there's
a
little
bit
of
overlap
in
the
api
itself
regarding
right,
like
like
selecting
a
subject
for
an
advent
network
policy
is
different
from
selecting
a
peer
for
a
number
of
reasons,
and
so
we've
defined
that
as
such
as
various
different
types
within
the
api
and
he's
saying
like,
can
we
explore
maybe
creating
an
overlap
in
the
sense
of?
Can
we
share
types
between
the
two?
I
believe
that's
what
he's
saying
so
I
this
stems
from
kind
of
his
dislike
of.
A
B
B
D
A
D
D
D
E
E
A
Cool
awesome
well
great
to
have
you.
We
currently
are
kind
of
running
through
the
admin
network
policy
api
that
we're
implementing
and
if
you
look
in
the
agenda,
there's
some
links
to
the
kep,
which
will
describe
it
more
and
the
actual
pr
we're
looking
at
today,
so
feel
free
to
follow
along
thanks:
okay,
hey
dan!
We
were
just
talking
about
some
of
your
comments.
A
Yep
we
were
going
on
the
first
one,
so
talking
about
basically
trying
to
make
subject
and
pure
more
parallel.
We
looked
at
this
and
we
were
just
yang
wanted
to
verify
that
this
is
actually
what
would
happen
like
this
double
nesting
of
pods.
I
think
when
I
looked
just
before
this
meeting
like
it
could
happen,
so
we
just
wanted
to
look
really
quick
at
the
actual
code.
A
B
F
B
Right,
yeah
yeah.
I
agree.
I
agree.
I
agree
this
is
I
I
I
agree.
This
is
wrong,
so
I
I
feel
like
under,
if
you
scroll
down
to
namespace
pod
pier,
I
think
it
should
have
name
spaces
with
namespace
pair
is
fine,
because
you
will
have
all
the
the
self
nothing
labeled
stuff
under
there
right,
but
for
for
the
second
one
it
should
just
be
post
factor.
It
shouldn't
be
another
level
of
nesting
that
doesn't
really
make
sense.
A
B
Right
right
on
that
note,
I
think
I
think
we
had
this
conversation
before,
if
I
remember
this
correctly,
with
tim
and
the
other
guys,
and
the
reason
why
we
decided
to
go
with
separate
fields.
Is
that
you
know
for
the
subject.
Something
really
doesn't
really
make
sense.
So
when
you
select
subjects
you
are
really
clear
on,
you
know
which
label
namespaces
you
want
to
select
or
which
label
path
you
want
to
select.
But
in
that
particular
case
you
cannot
basically
say
something
like
I
want
to
select
subject
and
the
name
space
is
from
self.
B
B
A
A
A
D
Yeah,
but
I
think
it
applies
to
it
applies
to
part
as
well.
If
I
understand
correctly
because
for
the
subject,
there
is
no,
there
are
no
multiple
selectors,
but
here
we
have
multiple
selectors,
because
we
do
have
a
part
selected
like
I
mean
like
selecting
the
constructs
within
the
cluster
versus
selecting
outside
the
cluster.
So
that's
why
we
added
additional
indirection.
Is
it
correct.
A
The
additional
interaction
was
all
for
extensibility
like
like
in
the
future,
just
to
make
it
a
little
bit
more
explicit
and
easier,
and
it's
just
kind
of
the
api
design
syntax
that
tim
is
advocating,
for,
I
think,
we've
all
kind
of
agreed
on
what
he.
What
dan's
saying
basically
is
like
and
yeah.
We
just
have
one
less
layer
of
interaction
and
everywhere
else
we
have
it.
So
it's
kind
of
confusing
to
write
the
ammo
for
it.
B
But
in
the
namespace
past,
subject,
there's
only
a
namespace
vector
and
if
continue
on
your
argument
before,
if,
if
you
do
a
namespace
selector
here,
it's
also
one
less
indirection
from
for
the
selectors,
because
if
you
wanted
to
write
a
namespace
part,
both
selectors
in
the
subject
case
and
in
the
peer
case
in
the
subject
case,
you
will
have
one
less
line.
If
you
will,
if
that
makes
sense,.
C
A
Okay,
as
an
action
item,
all
I
will
make
that
consistent
in
terms
of
nesting
and
then
also
remove
the
deepest
pod
pure
indirection
layer.
We
have
that
we
don't
need,
and
then
I
think
after
this
round
of
reviews,
I'd
like
to
just
write
some
yammels,
maybe
some
real-life
animals
and
try
to
see
like
if
there's
anything,
we're
missing.
Yeah.
F
F
Right
so
so,
so
I
think
I
was
saying
like
actually
it
looks
like
in
well.
I
I
was
saying
that
the
the
one
that's
just
selector
here
should
be
name
space,
selector
right
and
again,
you
know,
maybe
I'm
the
one
who
argued
against
that
before
yeah.
I
think
you're
right
andrew,
I
think
you
you
need
to
like.
A
B
A
B
F
B
Namespace
part
here
right,
so
so
that's
I
think,
that's
where
I'm
confused
about.
Essentially,
if
you
specify
namespace
pop
here,
you
need
to
both
provide
namespaces
and
pause
and
actor,
so
that
might
make
it
a
little
bit
more
unclear
because
if
you
say
in
in
the
in
the
example
you
just
you
just
if
you
go
back
to
the
comment,
so
essentially,
you
cannot
do
that
if
we
just
get
rid
of
the
extra
level
of
parts
right
right.
B
B
A
No,
no,
no,
I
mean
if
we
get
to
this
scenario
right,
we
are
coming
from
admin,
network
policy,
pier
and
then
we'd
basically
say
pods.
I
think
it'd
be
confusing
because
we'd
say
pods,
but
oh
you're,
saying
if
we
get
rid
of
that
level
and
direction
right
that,
that's
why
we
did
it
in
the
in
the
beginning,
because
you're
saying
if
this
was
just
a
pod,
selector
like
this
would
end
up
just
being
selector.
A
A
A
Okay,
I
will
do
that
writing
out
a
couple.
Examples
will
be
awesome
and-
and
we're
gonna
have
to
do
it
anyway
and
and
we're
almost
to
a
t
of
equalization.
So
I
shouldn't
have
to
redo
it
a
bunch
of
times
we
talked
about
pod,
pure
I'm
gonna
clean
up
this,
because
at
the
end
of
the
day
like
we
need
to
do
whatever
it
takes
to
make
these
yamls
look
readable,
like
it's
pointless
for
us
to
make
an
api
that
has
stuff
like
that
in
it.
A
A
A
This
was
one
I
was
going
to
ask
you
about
you're,
saying,
basically
reusing
the
admin
network
policy
status.
Struct
for
both
is
seems
out
of
sorts,
but
I
was
trying
to
think
of
a
actual
reason
for
creating
you
know:
an
admin
network
policy
status
truck
and
a
baseline
admin
network
policy
status
truck
like.
Are
they
ever
going
to
be
different,
or
is
it
just
a
purely
read?
Reading
through
the
code,
you
have
a
problem
with
yeah.
F
A
A
D
A
Think
everything
else
was
pretty
straightforward
besides
this,
so
I
will
clean
up
what
we
have
and
and
push
some
changes
here
later
today
and
start
writing
some
yamls.
I
mean
we
should
have
a
list
of
yamls
anyway
that
just
as
reference
to
be
probably
put
in
this
repo
as
well
so
that'll
be
good,
any
other
comments
or
questions
with
admin
network
policy
bits
after
this.
F
A
A
While
all
this
is
fresh
in
our
head
in
our
heads,
because
it's
going
to
be
really
important
to
have
good
documentation
for
this
api
and
it'll
be
good
for
the
implementers
which
I
feel
like
are
going
to
be
basically
the
folks
in
this
room
right
now,
so
at
least
the
first
round
of
influencers.
Are
you
going
to
implement
this
for
sdn
dan,
or
should
I
just
do
it
for
11k.
A
I
have
a
pr
up,
adding
yang
as
an
owner
for
this.
I
might
do
the
same
for
you
dan.
If
that's
something
you
would
like,
we
definitely
need
to
add
you
to
the
contributors
list
for
this,
because
you've
been
super
incremental
here,
yeah,
that's
all
I
have.
I
will
poke
the
group
when
I
have
the
rest
of
this
done
and
if
we
could
just
get
some
final
read-throughs
and
lgtm
some,
we
can
move
forward
from
there.