►
From YouTube: Network Policy API Meeting for 20230117
Description
Network Policy API Meeting for 20230117
A
Foreign
today
is
Tuesday
January
17
2023..
This
is
a
meeting
of
the
Sig
Network
policy,
API
subgroup
to
Sig
Network.
This
is
It's
the
ncf
sponsored
meeting.
So
let's
follow
the
rules
and
be
nice
to
everyone
and
yeah
have
a
good
meeting
today.
So
this
is
the
first
time
that
we
are
meeting
at
the
new
meeting
time.
A
9
00
a.m,
PST
12,
PM
EST-
and
this
is
to
help
you
know-
facilitate
getting
more
folks
here,
especially
EU
contributors
and
other
sort
of
folks,
so
happy
to
see
some
faces
and
yeah
I.
Think
the
agenda
is
pretty
light
today,
but
I
don't
know
John
Howard
you
haven't
been
here
before.
Do
you
want
to
kind
of
give
a
quick
intro?
Or
maybe
you
have?
No?
This
is
my
first
time.
B
Awesome
yeah,
so
I'm
I'm
from
the
East
Geo
community
and
we've
been
looking
to
kind
of
adding
some
Network
policy
support
for
for
a
while.
We've
had
our
own
policy
authorization
policy
as
a
name
but
we're
insured
in
splitting
the
full
L7
authorization
policy
with
kind
of
the
El
for
and
network
policy,
of
course,
does
many
of
the
things
that
we
want
to
kind
of
have
policies
over
at
L4,
so
we've
been
kind
of
looking.
B
If,
like
we
want
to
make
our
own
resource
or
use
Network
policy,
what
would
it
take
to
make
that
happen
and
for
us,
there's
kind
of
a
few?
A
few
main
gaps
I
think
with
where
Network
policy
is
today
with
where
we
would
want
it
to
be
to
use
one
of
the
big
ones
is
service
account
as
kind
of
a
matching
criteria,
that's
kind
of
the
bread
and
butter
for
istio
kind
of
one
of
the
most
important
things.
B
B
Some
other
things
as
well
is
because
we
are
not
like
the
Coursey
and
I
we're
kind
of
running
alongside
a
real
cni.
So
we
were
also
interested
in
some
ways
to
kind.
B
So
yeah,
that's
kind
of
where
we
were
I,
was
recommended
to
kind
of
come
just
kind
of
casually
discuss
where
you
know
what
we're.
What
we're
interested
in
so
here
I
am.
A
That's
awesome
well
great
to
have
you
here
and
yeah
I
think
this
is
the
perfect
place.
So
you
know
you
touched
on
a
couple
things
I
think
the
most
the
first
one
is
kind
of
the
network
policy
selector
for
with
service
accounts
and,
like
you
said
that
has
been
discussed
before.
But
it's
been
quite
some
time
and
you
know
it
would
just
kind
of
involve
some
folks
kind
of
picking
it
back
up.
A
However,
there
is
some
prior
things
that
have
happened
between
like
the
time
this
was
last
brought
up,
and
now
one
of
the
main
ones
being
is
us,
as
a
group
have
kind
of
concluded,
it's
almost
impossible
to
add
new
stuff
to
the
existing
Network
policy,
API
for
a
bunch
of
backward
compatibility,
reasons
and
stuff,
that's
kind
of
documented
if
you
read
back
through
the
agenda,
so
in
my
opinion
and
others
can
agree
to
disagree
here,
I'm
happy
to
hear
it
like
I-
think
Network
policy
V2
is
kind
of
a
place
we'd
like
to
see
new
selectors
such
as
service
kind
of
selectors,
maybe
service,
selectors,
Etc
kind
of
come
into
the
picture.
A
Obviously
that
means
like
a
bigger
chunk
of
work
like
we
need
this
community,
a
group
of
people
here
to
like
really
own
the
network
policy,
V2
effort-
and
you
know
we're
always
looking
for
help
because
currently,
like
there's
a
bunch
of
stuff
people
want
there's
fqdn,
there's
these
new
selector,
sorry
fully
qualified
domain
name
policies,
there's
these
types
of
new
selectors
and
not
really
a
single
entity
driving
that
yet.
A
So
that's
like
a
little
bit
of
of
historical
context
for
you,
I,
don't
know
if
you
have
any
questions
and
I
don't
know
if
anyone
else
here
like
is
interested
and
would
want
to
maybe
help
John
kind
of
hop
in
on
this.
D
Not
an
immediate
need
but
I've
been
vaguely
interested
in
the
applicability
of
these
exact
things
to
awesome.
Adult
Aussie
concerns
in
Gateway
API
gamma
work
so
get
way
back
for
mess.
E
I
I
have
been
thinking
about
Network
policy
V2,
just
like
you
know
what
we
might
want
to
do
about
it,
but
I'm,
not
I'm,
maybe
we'll
get
to
this,
but
the
second
half
of
the
proposal
has
to
do
with
cni's
sort
of
selectively
implementing
the
spec,
which
is
I,
guess
a
second
can
of
worms.
A
A
A
Cool
I,
just
I'm,
looking
at
your
your
name
and
and
zoom,
and
it's
a
power
job
cool,
so
yeah
in
your
case
with
the
istio
case,
you
said
like
would
istio
be
implementing
this
policy
outside
of
the
cni
in
your
case,
or
it
has.
B
B
Yeah
one
thing
too
on
what
Rahul
said
about
selectively
implementing
I
didn't
mention
this
earlier,
but
we'd
also
probably
want
to
not
support
Source
labels
as
a
field.
B
So
that's
kind
of
why
I
mentioned
like
Ingress
class,
like
my
initial
thought,
was
like
something
like
Network
policy
class
I
mean
I
know.
You
said
it's
hard
to
add
field,
so
this
is
maybe
theoretical
and
practical
for
the
existing
API.
But
like
a
network
policy
class-
or
you
know
they
can
say,
okay,
this
is
the
Eco
policy
and
then,
if
they
have,
you
know
Source
labels.
We
can
just
reject
it,
because
we
don't
support
that.
If
and
then
they
can
add
service
account
types,
because
we
support
that
a
different
scene.
B
A
A
Yeah
I
think
that
supportability
Matrix
makes
a
lot
of
sense
role.
You
were
touching
on
it
and
it's
something
we
can
definitely
be
explicit
about
in
in
V2
like
we
can
follow
those
those
designs,
such
as
Ingress
class,
and
see
what
works
for
us,
but
it
it
still
kind
of
boils
back
to
like.
We
have
folks
a
lot
of
folks
coming
in
and
asking
for
new
features,
and
you
know
it's
just
a
matter
of
getting
someone
to
spearhead
it
with
this
community
behind
them
to
help
it
help
them,
and
that's
like
really
the
stalemate.
B
Yeah
totally,
if
that
makes
sense
one
question
I
do
have.
If
we
were
to
say
oh,
we
don't
want
to
wait
for
me
to
we're
just
gonna
shove,
like
a
fake,
lit
pod
label
for
service
account
kind
of
like
that,
the
namespace
label
thing
and
like
how
terrible
is
that
are
we
have
we
committed
the
cardinal
sin
of
network
policy,
or
is
it
just
kind
of
an
acceptable
hack.
A
Well,
if
you
ask
like,
can
we
create
a
new
or
or
just
out
of
the
box?
Add
this
to
the
existing
Network
policy?
Api,
that's
living
in
tree
I'd
say
it's
Ricardo!
You
can
chime
in
here
I'm
saying
it's
probably
going
to
be
received
as
a
cardinal
sin,
like
from
our
from
our
experiences
in
the
past,
like
yeah.
A
B
They
add,
like
these
extra
labels,
and
you
know
it's
an
appealing
step
step
aside.
I,
don't
know
if
that's
something
that
will
come
back
to
bite
us.
You
know
psyllium.
F
B
Well,
they
have
that,
but
you
can
also
actually
put
in
the
Pod
label
section.
You
can
put
these
labels
that
don't
actually
live
on
the
Pod.
One
of
those
is
service
account
they're
kind
of
like
these
synthetic
labels
that
psyllium
understands.
So
it's
not
actually
literally
looking
at
pod
labels
for
the
Pod
label
Fields,
it's
looking
at,
like
pod
labels,
plus
some
other
info
that
it
adds
on
the
pod.
F
Yeah
Yeah,
we
actually
have
something
like
that:
an
open
shift
as
well
there's
a
a
fake
namespace
label
that
matches.
A
Yeah
and
as
to
is
that,
like
a
cardinal
sin,
no
I
mean
obviously
we
want
to
do
everything
in
the
Upstream
like
that's
the
best
way
to
do
it,
but
looking
back
at
even
the
like
cluster
scope,
Network
policy
effort.
Most
of
these
providers
like
had
their
own
hacks
Downstream,
because
the
Upstream
process
was
just
too
slow,
and
so
you
know
at
the
end
of
the
day
like
we
want
to
align
here,
but
it
requires
it
requires
quite
a
big
alignment
within
the
community
and
and
that's
not
the
easiest
thing
to
do
so.
A
G
Think
I
think
that
yeah,
the
the
cons
on
that
is
that
you,
you
kind
of
don't
have
any
more
a
standard
right
on
each
one
having
its
own
network
policy,
custom
research
definition,
but
on
the
other
hand,
and
and
doing
that
like
for
maybe
two
years,
following
with
that
Winship
J
on
the
other
things
that
SJ
as
Andrew
raised
it
on
that
like
we
took
something
like
one
and
a
half
year
to
add
a
few
to
to
promote
a
few
to
GA
right.
G
We
roll
it
back
another
another
thing
right
now,
which
is
a
status
because
it
would
be
just
not
that
useful
when
you
still
would
have
to
wait
for
the
cnis
to
implement
on
that.
So
my
I
was
wondering
as
you
as
you
are
doing
at
the
the
cluster
Network
policy
and
rail,
if
it's
worth
to
like
start
drafting
a
network
policy
V2,
but
not
with
without
any
commitment
on
that.
G
Like
saying
hey,
if
you
wanted
to
have
a
new
natural
policy,
how
this
should
look
like
and
and
like
then
then,
when
she
as
an
example,
can
be
really
creative,
with
all
of
the
things
that
he
he
has
been
saying
on
the
network
policy
V1
as
well-
and
maybe
we
say,
hey
folks.
So
this
is
the
way
that
we
think
it
should
look
like.
G
And
we
saw
that
happening
on
Ingress
on
past
as
well
so
increases.
They
just
started
to
rely
more
on
annotations.
What
what
I
can
see,
as
then
say,
from
Red
Hat,
on
on
the
cni
of
openshift
and
and
even
from
missio,
that
we
are
again
hacking
on
the
existing
object,
but
instead
of
using
annotations
just
using
labels.
A
See
what
you
mean
I
think:
that's
a
really
good
idea,
like
a
pre-cap
like
let's
just
design
an
API
and
see
where
it
goes.
A.
G
G
It's
just
like
something
that
we
should
discuss
in
the
future,
because
I
don't
think
it's
gonna
exist
any
of
those
new
Fields
without
existing
on
your
policy,
video
and
and
as
you've
seen
Andrea
was
there
like
even
the
cluster
Network
policy,
it's
something
that
takes
a
lot
of
discussion,
a
lot
of
things
and
in
the
end
you
just
have
one
specific,
cni
saying
hey
this
is
this
doesn't
apply
to
me
or
the
other
one?
So
it's
probably
just
going
to
be
too
painful
or.
G
Just
go
back
the
way
that
Gateway
API,
they
did
and
say
hey.
We
do
the
things
really
simple.
If
you
want
something
a
a
bigger
then
go
to
the
custom
resource,
they
say
that
they
have
like
an
extended
version
of
Gateway
API
or
something
like
that.
I,
don't
remember
as
well
like
level,
one
level,
two
level,
three
sure
right.
A
D
Something
a
little
bit
more
yeah,
so
Gateway
API
has
I
can
drop
a
link
in
the
notes
here.
Oh
there's
a
couple
different
variations
of
how
like
versioning
and
performance
happens.
D
The
two
big
ones
are
the
conformance
levels
that
you
were
talking
about,
there's
core
conformance,
which
is
basically
all
implementations,
are
expected
to
support
this
functionality.
That's
in
this
marked
as
core
conformance
extended
conformance,
is
kind
of
a
like
pick
and
choose
category
of
here's.
D
The
thing
you
can
choose
to
support
any
one
of
maybe
a
dozen
different
features
you
can
support
one
or
many
or
sometimes
they're
mutually
exclusive,
but
if
you
do
it
should
behave
in
a
specific
way
that
we
have
specified
and
have
conformance
tests
for
and
then
kind
of
the
third
level
beyond
that
is.
There
are
a
few
spots
that
are
marked
as
implementation
specific
extensibility,
so
it's
explicitly
undefined.
You
can
add
your
own
filter,
that's
specific
to
istio
mesh
or
console
service
mesh
or
whatever
it
may
be,
where
you
can
Implement
stuff.
D
That
is
not
specified
and
is
not
all
part
of
the
conformance
suite
at
all.
So
that's
kind
of
like
an
escape
patch
to
do
whatever
certain
suits
your
purposes
and
then,
aside
from
that,
we
also
have
just
like
releases
with
the
typical
kubernetes,
like
Alpha
Beta,
GA
Cadence.
So.
A
D
A
D
Yeah
so
I
think
they're
things
would
generally
start
at
an
implementation,
specific
or
extended
conformance
when
you're
proposing
a
new
feature.
D
It
may
start
like
if
it
if
it
can
happen,
buying
implementation
without
changing
the
course
back.
It
can
have
an
implementation
specific
one
of
those
hatches
then
potentially
get
standardized
into
extended,
or
similarly,
someone
can
start
and
extended,
and
then,
if
it's
determined
that
it
should
be
implemented
by
everybody,
it
could
be
promoted
to
court,
but
there's
definitely
not
an
expectation
that
everything
extended
is
going
to
move
to
core
like
there's
very
much.
This
is
things
that
might
make
sense
for
one
implementation
and
not
others.
Yeah.
D
I
forgot
all
we
have
two
channels:
oh,
we
have
the
experimental
Channel
and
the
standard
release
channel,
so
I'll.
Let
John
figure
out
whether
yeah
things
would
start
an
experimental
and
not
move
to
the
standard
Channel
until
they're,
ready,
yeah.
B
I
was
just
gonna
add
like
one
thing
that
makes
it
a
bit
different.
Is
the
resources
are
decomposed
in
Gateway?
So
first
example
like
there's,
HTTP
route
is
core,
but
then
some
of
the
implementations
could
have
like
my
SQL
route
or
something
which
could
just
start
not
even
entry,
just
like
in
some
random
implementation,
and
then
maybe
it
moves.
Maybe
it
doesn't
it's
kind
of
composable
for
Network.
B
Guessing
we
would
end
up
with
just
kind
of
one
resource,
probably
so
we
can
then
kind
of
end
up
with
just
the
infield
for
like
new
Fields
type
of
thing
as
part
of
the
promotion.
A
Yeah
I
think
it's
more
intuitive,
but
I
do
like
you
know
the
way
you
can
like
an
influence
or
someone
outside
of
the
core
group
can
start
an
API
and
then
say
like
what
do
you
all
think
about
this?
Put
it
in
a
community
centered
place
and
then,
if
the
community
likes
it
move
it
in
tree
like
that
flow
seems
a
lot
faster.
I
mean
it
kind
of
Skips.
The
kept
flow
a
little
bit
right,
but
that's
not
necessarily
the
worst
thing.
Sorry
Rahul,
you
have
your
hand
up,
go
ahead.
E
No
worries
I
was
I
was
just
curious
that,
like
the
idea
of
extensibility
via
objects,
maybe
it
doesn't
make
as
much
semantic
sense
for
admin
Network
policy,
but
did
we
ever
consider
something
like
that
like
right?
Now
we
do
like
it's
a
monolithic
object
with
the
status
field
that
helps
us
sort
of
add
new
things
right
like
did.
We
did
we
consider
making
it
sharded
across
objects,
or
was
that
too
confusing.
A
I
mean
we
sharded
it,
but
originally
there
was
no
well
originally.
There
was
a
baseline
adminator
policy.
Then
there
wasn't
and
now
in
the
actual
implementation,
there
is
two
objects:
there's
admin,
Network
policies
and
Baseline
adminary
policy,
so
slightly
sharded,
but
no
generally,
we
didn't
think
about
like
adding
new
features
via
new
objects.
Does
that
make
sense?
A
But
yeah
I
mean
it's
working
for
the
Gateway
API
and
like
I
always
like,
if
I
ever
have
a
question
about
this
stuff,
like
I,
always
kind
of
go
back
and
ask
Rob
or
look
at
like
what
they
gave.
Api
folks
have
done
because
they've
run
into
a
lot
of
this.
It's
like
I,
wouldn't
put
it
out
of
the
question
in
my
opinion
like
where
we
started
this
conversation
just
now
like
it
all
revolves
around.
Like
the
fact
like
we
have
all
these
features,
people
want
them.
A
We
need
somewhere
to
start
our
Network
policy
V2,
like
maybe
that's
a
working
document
for
now
I
think
we
actually
had
a
working
document
and
it's
right
here,
it's
just
kind
of
been
dropped,
so
maybe
we
need
to
pick
that
back
up.
My
whole
thing
is
like
with
any
API
or
any
feature.
We
just
need
someone
to
raise
their
hand
and
say,
like
I
will
help
own
this.
Not
I
will
do
it
all,
but
I
will
be
the
one
to
kind
of
like
push
this
every
week.
A
I
will
be
the
one
to
kind
of
track:
What's,
Going,
On,
Loosely
and
just
kind
of
help
it
along
and
I
know
like
for
me.
I
can't
do
it
right
now,
but
I'm
happy
happy
to
help
facilitate
it.
So
that's
kind
of
where
we're
at
I
I
think
Ricardo's
mention
of
like.
Let's
start
it
somewhere
is
really
important,
like
let's
pick
up
back
up
on
the
stock,
maybe
and
see
what
we
can
do.
A
It's
in
the
agenda
at
the
top
and
let
me
I'll
bring
it
back
down
it's
under
important
links
in
the
agenda,
Network
policy
V2
working
dock,
and
that
was
actually
some
folks
from
Juniper
Networks,
who
are
not
involved
anymore,
but
they,
you
know,
started
something
right
and
I,
don't
know
someone.
We
could
look
at
this
and
say
we
don't
want
to
keep
going
with
what
they
have
here.
It's
kind
of
a
jumbled
notes
at
this
point
and
it's
pretty
broad.
A
We
could
start
something
new
I'm
pretty
open
to
anything,
but
this
is
what
we
have
so
far.
A
From
the
this
group
standpoint
like
if
I
was
to
just
get
something
started
where
we
could
start
dumping
docks,
do
we
think
a
Google
Docs
is
a
good
place,
or
should
it
be
in
a
readme?
Should
it
be,
like
literal
just
start,
designing
types
like
a
rough
outline
of
an
API
like
what
would
be
the
best
way
to
facilitate
getting
this
going
in
y'all's
opinion.
F
F
A
Okay,
that's
a
good
point.
I'll,
look
at
adding
that
to
the
next
agenda
and
I'll
run
I'll,
try
to
run
through
this
document
and
decide
if
we
want
to
just
make
like
a
clean
document
or
if
I
can
clean
this
up
a
bit
because
I
know
it's
a
little
bit
like
a
lot
of
just
random
notes.
At
this
point.
A
Cool
and
yeah,
if
anyone
wants
to
help
like
please
reach
out
like
this
is
this
is
definitely
an
opportunity
to
like
own
something
pretty
big
or
help
own
something
pretty
big
enough.
Stream
So
I
think
it
gets
a
really
cool
opportunity.
If
anyone
has
time
and
if
anyone's
watching
this
recording
and
thinks
they
have
time.
G
Do
not
have
to
have
compatibility
which
we
want
no,
but
I'm
I'm
I'm,
asking
this
seriously
I
mean
then
then
can
can
chime
in
on
that.
But
when
you,
when
you
have
this
API
migrations
that
you
say
like
I'm,
going
from
view
on
to
V2
kubernetes
has
this
contract
that
you,
you
should
keep
compatibility
between
them
right.
So.
F
A
100
yeah
yeah,
so
we
did
a
cluster
Network
cool,
okay,
so
I
think
we
have
a
good
kind
of
go
on
I'm
gonna
do
my
best
to
kind
of
get
this
on
the
agenda
for
next
time,
but
I
could
use
help
so
definitely
reach
out.
If
you
want
to
help
okay
moving
on
thanks
Sean
for
bringing
that
up,
I
think
that
was
constructive.
Hopefully,
if
we
can
actually
get
something
moving
in
the
meantime,
please
bring
back
anything
you
do
in
istio,
maybe
as
a
temporary
hack,
we'd
love
to
see
it.
F
A
Other
things
I
had
on
the
agenda.
One
was
the
admin
Network
policy
cap
update
from
Yang
I
gave
it
a
review.
I
think
it's
pretty
much
ready
to
go
in
obviously
just
needed,
LG
TM
from
one
of
the
people,
with
the
proof
Powers.
So
if
we
could
get
that
looked
at
that
would
be
awesome.
A
Yeah,
it's
not
a
huge
thing.
It's
just
making
sure
that
the
cap
is
up
to
date
with
what
we
actually
merged
in
the
API
yeah
I'll.
A
A
I
didn't
I
didn't
know
who
did
so
but
I
appreciate
it.
I'm
sure
you
and
I
have
both
given
it.
The
plus
one
we'll
be
good
to
go
cool
and
then
the
last
thing
I
want
to
talk
about
today
was
this
issue
which
has
come
up
a
few
times
and
I
was
doing
some
like
stale
issued
triaging
and
debugging
I
thought
I'd
bring
it
back
up
here
because
it
was
marked
as
fail.
I
see
story
has
been
commenting,
Dan's
been
commenting.
A
This
is
all
around
adding
a
flag
to
network
policy
to
stay,
enable
or
disable
it
and
obviously,
from
our
conversation
we
just
had.
This
is
probably
something
that
would
go
into
a
next-gen
network
policy,
not
necessarily
the
original
Network
policy.
It
seems
like
it's
worth,
leaving
open.
Do
others
agree
disagree.
E
F
E
F
C
Yeah
I
was
just
gonna
ask
if
we
do
need
a
cap
to
discuss
where
this
would
go
right
like
what
would
be
the
potential
Solutions?
It's
not
like.
We
can
just
change
the
existing
API
right.
F
No
I
mean
like
we
added
Port
ranges
right,
like
it's
sort
of
I
mean
we
would
have
to
say
that
this
feature
may
or
may
not
actually
be
implemented,
and
so
you
know
setting
the
disabled
flag
may
or
may
not
actually
work,
which
is
you
know,
kind
of
lame,
but.
F
A
So,
in
your
opinion,
Dan
like
in
a
case
like
this,
where
we
have
someone
asking
for
a
feature
like,
and
maybe
the
community
doesn't
have
the
bandwidth
to
open
a
cap
like
what
do
we
do?
Do
we
just
kind
of
let
it
sit,
do
I
keep
this
issue
open,
do
I.
You
know
close
it
and
say
when
you're
ready
to
open
a
cup
reach
back
out,
how
do
we
handle
it?
I.
F
Mean
I,
guess
I
would
let
the
Bots
Age
the
issue
out
and
unless
you
personally
find
it
useful
to
keep
it
open
as
a
tracking
for
things
that
the
the
network
policy
working
group
wants
to
remember
right.
A
That's
kind
of
why
I
left
it
open
because
it
seemed
like
a
good
one
for
a
V2.
In
my
opinion,
okay
sounds
good
I'm
gonna
as
part
of
trying
to
like
get
a
V2
doc
more
up
to
date,
I'll,
hopefully
be
able
to
add,
like
a
list
of
things.
People
have
asked
for,
and
this
will
be
an
atlas,
so
I
will
leave
it
open
for
now
and
yeah
if
anyone's
watching
and
wants
a
really
good
first
cap.
C
Yeah
I
actually
wanted
to
wanted
to
do
what's
happening
to
jump
on
helping
out
with
this.
But
if
this
is
dependent
on
the
V2,
then
it
brings
us
back
to
the
earlier
discussion
that
we
will
have.
A
A
Yeah
I
think
that's
all
we
have
so
thanks
for
coming
everyone,
it's
good
to
see
you
all,
and
hopefully
this
new
meeting
time
is
a
little
bit
better
for
everyone
here
and
yeah
I'll
see
you
in
two
weeks
thanks
so
much
bye.