►
From YouTube: Network Policy API Meeting for 20230509
Description
Network Policy API Meeting for 20230509
A
Okay,
hello:
everyone
today
is
Tuesday
May,
9th
2023.
This
is
a
meeting
of
the
city,
Network
policy
API
subgroup
to
sing
Network.
This
is
a
cncf
sponsored
meeting,
so
please
be
nice
to
each
other
and
use
good
language
and
let's
try
and
have
a
productive
one.
Today,
I
see
some
new
faces
in
the
chat
Blaser
Alex.
Do
you
all
want
to
give
kind
of
a
intro
to
yourselves
or
in
a
a
brief
overview
of
why
you're
here
you
don't
have
to
if
you
want
to,
but
try
to
do
that
with
new
folks.
B
Yeah
all
right:
okay,
so
yeah
I'm,
picking
up
my
things
into
the
networking
of
kubernetes,
so
I'm
trying
to
pick
an
Sig
to
contribute
to
so
I'm
attending
most
of
the
Sig
meetings
right
now,
yeah,
so
I'm,
working
as
a
team
late
at
and
also
as
an
architect
in
another
company
yeah.
So
yeah
I
have
previous
experience
at
VMware
and
yeah
I'm.
B
Just
doing
something
in
my
free
time
here
and
yeah
I'm
really
keen
on
networking,
so
I
decided
that
the
networking
sigs
would
be
my
thing
to
go
and
they
are
trying
to
attend
as
much
as
many
meetings
as
I
can
right
now.
So
yeah
I
can
connect
to
some
place
and
do
something
productive
with
my
free
time.
Awesome.
A
C
A
Well
excited
to
have
you
Rahul
from
Google
is
usually
here.
He
hasn't
been
here
last
time
or
two
but
I'm
sure
he'll
be
back
so
I,
don't
know
if
you're
on
the
same
team
as
him
or
yeah.
Oh
cool,
awesome,
good
to
know,
yeah
he's
done
a
lot
of
work
with
us
in
the
past,
so
good
to
see
that
that
team's
still
coming
here
great
well
thanks
for
coming
y'all,
like
I,
said
before.
Please
stop!
A
If,
if
you
have
any
questions,
what
we're
going
to
talk
about
mostly
today
is
admin
Network
policy
and
the
API
around
that,
because
that's
kind
of
what
we've
been
focusing
on,
but
we're
constantly
looking
for
people
to
own
kind
of
future,
looking
apis
in
the
same
vein,
so
cool
beans,
so
first
thing
I
have
on
the
agenda
is
a
PRI
open.
That
is
a
lot
of
work
that
I've
been
meaning
to
get
in
for
a
long
time.
A
I
was
gonna,
just
go
ahead
and
merge
it,
but
I
decided
it's
pretty
big,
specifically
it
kind
of
refactors
our
website
to
be
generic,
to
like
just
Network
policy
apis
in
general,
not
specifically
admin,
Network
policy
or
any
other
thing
we're
going
to
be
working
on
so
I'm.
Just
looking
for
review
on
that,
it
also
adds
some
versioning
docs
based
off
of
what
Gateway
API
does
the
one
main
difference
being
we
aren't
yet
adding
like
basically
stable
and
experimental
branches.
We
only
have
one
branch
for
now.
A
If
we
get
to
the
point
where
we
feel
like
we're
mature
enough
to
start
doing
that,
happy
to
add
it
back.
So
if
we
could
get
an
LG
TM
on
that,
you
know
sometime
this
week,
I
think
it'll
open
us
up
to
actually
cut
an
official
0.1.0
release
of
what
we
have
so
far.
And
so
then
we
can
kind
of
solder
on
ahead
to
working
forward
from
there
foreign.
A
The
one
question
I
did
have
for
this
group
that
kind
of
came
out
of
this
read
this
simple
website
redesign
was
so
Gateway
API
has
you
know
their
set
of
resources
that
are
geared
towards
multiple
personas?
The
way
we've
gone
down
so
far
has
been
kind
of
like
we're
going
to
have
different
API
sets
for
different
personas.
A
So,
like
the
the
road
we're
going
down
right
now
is
to
have
you
know
the
admin
Network
policy.
Api
is
the
first
API
we've
made
right
and
then
in
the
future,
we'll
have
like
the
developer
Network
policy
API
as
like
the
next
API.
We
work
on
the
way
Gateway
API
does
it
is
they
just
have
the
Gateway
API
and
they
steadily
add
new
resources
and
new
objects
at
varying
versions
like
as
they
pick
up
new
use
cases,
whereas
we're
looking
at
making
like
new
API
sets
is
what
I'm
calling
it.
A
A
D
It's
not
specific
to
like
developer
and
admin
Network
policy,
because
I
think
that
you
know
those
are
pretty
clear,
but
we
have
the
role
orientation,
which
we
kind
of
assign
roles
certain
apis,
and
yet
there
are
situations
that
are
kind
of
starting
to
grow,
where
it's
not
always
entirely
clear.
What
role
would
be
responsible
for
something
policies?
For
instance,
it's
not
always
100
clear.
So
just
keep
that
in
mind,
as
you
like
think
about
the
distinction
between
roles
and
stuff
like
that
that
there
may
be
some
Blurred
Lines
later
on.
F
Yeah,
my
question
was
actually
around
that
right,
like
if
we
were
to
look
at
it
like
a
single
API
with
many
personas.
How
would
that
look
like?
Because,
at
the
end
of
the
day,
we
still
want
to
give
some
amount
of
freedom
for
people
to
install
either
the
admin
one
or
the
developer
one
or
keep
them
separate?
If
they
don't
want
to
mix
it
right,
like
I,
don't
know
if,
if
putting
them
in
a
single
API
is
I.
A
D
No
yeah,
we
don't
do
the
installation,
usually
at
that
level.
You
certainly
could,
as
like
in
your
Downstream,
do
something
like
that
right.
We
don't
do
that
today,
you
just
install
all
of
them
and
then,
if
you
but
the
difference,
the
difference,
I
guess
the
distinction
is
that
with
Gateway
API
things
attached
to
each
other
a
lot,
and
so
you
often
need
all
of
them.
You
need
all
the
rules
to
like
make
something
happen
where
here
I,
don't
think.
That's
always
true
right.
A
A
No
I
I
think
it.
It
is
a
little
different
right
in
this
case,
like
the
admin
has
a
very
clear-cut
set
of
use
cases
they
want
to
tackle
with
the
admin,
Network
policy
and
Baseline
admin,
Network
policy,
but
and-
and
it
can
function
Standalone
so
I
think
like
what
makes
the
most
sense
is
I'll
go
based
on
Shane
and
Dan's
recommendations
and
change.
A
I
think
it
might
make
sense
for
us
to
actually
provide
a
way
to
just
install
like
specific
Persona
apis
from
Upstream.
So,
instead
of
like
collapsing
all
our
crds
into
a
yaml
for
folks
to
digest
we'll
have
like
a
admin
policy
yaml
and
then
like
a
developer
policy,
yaml
Etc.
Does
that
sound
like
a
good
direction.
C
A
F
Yeah
I
think
I
like
that.
For
starters,
right,
let's
start
with
that,
even
the
b-a-n-b
and
ANP
right,
while
do
while
we,
we
haven't,
really
figured
out
what
a
conformance
is
going
to
look
like
right.
Like
we
haven't
said
that
to
be
conformant,
you
have
to
also
Implement
B,
A
and
B,
because
in
my
opinion,
A
and
B
is
the
main
object.
F
An
admin
could
choose
not
to
have
guard
rails
right,
they
don't
have
to
implement
ba
and
pssc
and
I
if
they
don't
want
to
I,
don't
know
if
that
means
they're,
not
conforming
for
ANP.
You
see
my
point
like
mixing.
All
of
those
apis
is
one
and
making
all
the
cnis
Implement.
Everything
might
not
be
something
we
want
to
force,
but
but
I
think.
For
starters,
we
can
start
with
the
documentation
and
go
from
there.
A
Okay
sounds
good.
The
other
main
thing
here
was
I.
I
did
add
a
note
on
implementation,
it's
just
linking
to
psyllium's
and
Cal
Coast
tracking
issue
and
the
actual
PRS
and
other
kubernetes
and
Andreas.
So
that
should
be
a
good
place
for
folks
to
see
what's
going
on,
yeah
so
I
have
some
to-do's
then,
based
on
this
conversation,
I'll
try
to
get
to
that
today
and
it
should
make
it
a
lot
easier
for
users
in
the
future.
A
Okay
and
that
filters
right
into
our
V1
v0.1.0
release
cut.
You
know
this
is
our
first
quote:
unquote:
official
actual
release
that
we're
gonna
actually
have
a
tag
and
a
payload
and
everything.
So
last
time
we
had
gotten
loose
agreement
that
there
wasn't
anything
else
we
needed
to
get
in
before
that
I'm
hoping
that
loose
agreement's
still
here.
If
it's
not
please
comment
on
this
on
this
PR
and
we
can
work
it
out
there.
A
Oh
yeah,
that's
a
big
first
step
and
I.
Think
it'll
allow
us
to
you,
know
iterate
towards
Alpha,
two
or
beta.
You
know,
as
we
start,
adding
more
use
cases
so
rolling
into
use
cases.
The
last
three
I
think
kind
of
the
last
three
bullets
I
have
here
anyway,
go
together
in
a
way
Dan's
tenancy
documentation
which
is
kind
of
starting
to
explore
like
what.
A
If
we
want
to
change
how
tenancy's
defined
for
new
versions
of
our
AP
of
the
admin,
our
policy
API
kind
of
going
in
line
with
Syria's
stories,
she's
added
for
egress
control
for
admin
hour
policy,
it
all
kind
of
files
into
how
do
we
want
to
organize?
You
know
future
use
cases
that
come
down
the
pipe
I
think
we've
been
leaning
towards
kind
of
copying
again
what
Gateway
API
does
with
gaps
a
Gateway,
API
enhancement
proposals
and
doing
something
like
that
for
here.
Do
folks
have
any
opinions
there.
D
B
C
A
D
A
Documentation
around
it,
it's
more
just
like
we
need
some
short,
a
short
blurb
on
like
you're
someone
who
wants
to
see
a
new
use
case
developed
like
this
is
what
you
do
you
open
an
app.
You
describe
the
use
case,
and
then
we
can,
you
know,
merge
the
nap
and
then
go
into
API.
Is
that
how
it
works
in
Gateway
API
like?
Is
it
a
gap,
basically
a
new
use
case,
and
then
you
do
design
after
the
gaps
merged
API
design,
or
is
it
all
kind
of
been
won.
D
It's
part
of
it,
but
we
have
a
process,
so
gupps
are
meant
to
be
and
I
think
this
goes
back
to
the
kind
of
original
Spirit
of
cap,
which
doesn't
really
occur.
Much
Anymore,
where
it's
supposed
to
be
an
iterative
document
and
it's
reasonable
to
have
just
the
what
in
the?
Why,
with
no
how
in
the
first
iteration,
we
often
encourage
that
so,
like
somebody
comes
in
and
says
they
want
to
do
a
thing,
we
usually
tell
them.
D
Okay
start
with
a
tldr
which
is
like
the
summary
and
then
goals
and
non-goals
which
are
in
cap.
It's
Gap
is
like
cap
in
some
ways,
but
don't
do
anything,
but
that
just
tell
us
what
it
is
you
want
to
see
done
and
what
the
goals
are
before
you
try
to
come
up
with
an
API
or
a
design
or
anything,
and
that's
usually
a
good
way
to
get
started,
and
then
it's
usually
several
PR's
until
it's
finally
into
you
know
it's
actually
shipped
and
everybody's
using
it,
and
we
have
statuses
along
the
way.
D
So
there's
provisional
and
prototyping,
which
is
actually
a
recently
added
extension
of
provisional,
that
for
people
who
prefer
to
do
prototyping
as
part
of
their
research,
you
can
kind
of
just
say:
hey,
there's
a
prototype
available,
but
we're
still
in
the
provisional
stage,
so
so
that
you
can
kind
of
indicate
that
and
then
we
go
to
experimental
and
so
forth.
So
it's
a
graduation
path
along
the
way
where
things
have
to
be
resolved
before
it
can
graduate
and
so
forth,
and
it
takes
a
while.
D
Yeah,
it's
too
it's
too
hard.
If
nothing
else
like
there's
a
lot
of
things
you
could
say
about
that
process,
but
if
nothing
else,
the
smaller
iterative
thing
is
good
with
GitHub,
because
GitHub
PR
comments
can
often
end
up
being
getting
you
into
a
state
of
malaise.
Where
there's
so
many
comments
like
there's
there's
you
know,
maybe
the
Gap
is
fairly
long,
but
then
the
comments
are
like
10
times
as
long
right
in
terms
of
the
amount
of
text
you
have
to
read
and
keep
in
your
head
to
understand
what
you're
doing.
A
Cool
okay
yeah
so
originally
like
right
now,
based
on
what
Surya
and
Dana
done
are
kind
of
two
separate
ways
we
had
done
in
the
past.
Right
Dan
opened
a
document
that
doesn't
necessarily
describe
a
new
use
case,
but
may
kind
of
change
an
existing
use
case
to
be
a
little
more
expressive,
whereas
Surya
opened
a
PR
to
add
more
docs
around
a
totally
new
use
case.
A
F
F
B
E
Totally,
it
doesn't
necessarily
help
with
the
name,
but
if,
if
Gateway
API
is
doing
this
and
we're
doing
this-
and
you
know
who
knows-
maybe
other
working
groups
would
do
it
like?
Maybe
we
need
like
a
Sig,
Network
enhancement
proposal,
you
know
and
then
like
try
to
absorb
gaps
which
may
not
actually.
D
A
Yeah
and
I
think
that's
going
to
pave
the
way.
I
mean
there's
like
the
conformance
profiles.
It
seems
like
there's
stuff
coming
out
of
Gateway
API
that
are
going
is
going
to
be
used.
You
know
more
widespread
in
Sig
networks,
working
group,
so
I
don't
know
how
that
would
work,
but
for
now
we
should
probably
just
come
up
with
something
yeah
yeah.
You
should
probably
take.
D
A
look
at
the
reference
Grant
how
that
scenario
and
kind
of
track
it
basically
as
we're
kind
of
that's
going
into
like
Sig
off
and
potentially
going
in
tree.
So
if
you
have
things
eventually,
that
would
go
down
that
path
like
you
might
just
want
to
know
that
that's
there
and
kind
of
be
unaware,
because
I
think
we're
kind
of
breaking
ground
for
that
process.
A
F
I
can
start
to
write
some
documentation
for
the
pep
or
whatever
we're
going
to
call
it
as
I.
Do
the
enhancement
thing
for
the
egress,
but
the
one
question
I
had
is:
do
we
want
to
completely
shut
down
the
initial
use
case
proposal
thing
like
I,
think
we
could
tone
down
on
it
being
super
rigorous,
but
get
the
use
cases
at
least
sorted
out
right,
like
the
process
was
good,
because
we
were
able
to
reiterate
and
figure
out
that.
Okay,
this
is
a
valid
use
case.
F
A
So
I
I
I,
don't
want
to
duplicate
folks
effort,
I
think
if
we
do
the
pep
right
like
this,
should
literally
be
this
the
first
PR
for
a
pep.
It
should
be
it.
You
know
we
could
even
use
the
same.
Schema
you've
used
here
in
Syria
I
think
it
should
be
like
this
short
right.
It
should
be.
Do
we
agree
on
this,
or
do
we
not?
If
we
agree
on
it,
we
plus
one
we
go
charge
it
and
then
there's
no
other
overhead
for
the
developer
and
we
can
develop
it
in
in
future.
F
B
A
F
A
F
A
A
A
So
yeah
that
sounds
good
to
me.
Siria
I'm,
fine,
with
with
merging
it
for
now
and
then
getting
kind
of
our
infrastructure
set
up
to
actually
do
it
properly
in
the
future.
Do
it
in
a
standardized
way,
but
the
easier
we
may
make
it
to
open
one
of
these
peps
or
gifts
or
anything
the
better
right
like
it
should.
It
should
be
the
same
amount
of
work
where
you
just
have
to
describe
the
base
of
the
user
story,
and
you
know,
give
a
summary
and
description.
A
E
E
Basically,
the
the
fact
that
the
way
we
Define
tenancy
right
now
is
just
way
too
powerful
and
love
to
do
anything
and
is
probably
going
to
be
terrible
to
implement,
and
one
thing
that
we
had
talked
about.
I,
don't
know
if
Surya
had
mentioned
it
was.
Maybe
we
should
just
pull
tenants
out
of
V1
Alpha
One
so
that
we
can
think
about
it,
some
more
and
and
don't
you
know,
start
out
with
something
that
turns
out
to
be
bad
later.
A
F
F
Dancing
like
before
the
cut
since
there's
confusion
around
it,
like
he's
saying
like
well
just
remove
it
and
well
I
I
had
the
same
opinion.
Actually
we
talked
about
it
at
cubecon
and
we
were
like
yeah.
The
tenancy
is
not
well
defined
yet
right
and
we
need
to
re-itrade
on
it.
So
does
it
really
make
sense
to
go
ahead
with
same
and
not
same
only
to
remove
it
in
the
V2
version
right.
A
A
I,
don't
see
a
huge
negative
to
even
doing
a
V1
Alpha
too,
if
we
have
to
and
removing
it
there,
but
I
would
like
to
go
ahead
and
get
a
cut
right.
So
if
we
think,
if
you
all
are
saying
we
can
kind
of
just
remove
this
and
cut
and
move
on,
that's
fine
and
you
know,
get
a
tendency
solution
created
sometime
in
the
next
couple
months
like
I.
Guess
that
would
be
all
right,
but
I
don't
know.
F
A
A
A
Cool
yeah
because
I
I,
I
I,
didn't
really
know
the
details
of
getting
it
done.
I
had
been
told
in
the
past
that
it
was
just
getting
plus
one
from
chairs,
but
obviously
I
think
we
want
to
let
the
Sig
know
like
look
we're
just
about
to
cut
natural
release
like
these
implementations
are
pretty
much
there.
Like
we've
made
good
progress
It's
time.
You
know
we
need
the
our
parents
Sig's
help
in
broadcasting
this,
so
that
we
have
less
talks
and
kubecon
about.
A
F
Yeah
thanks
Andrew
for
rushing
on
that
I
do
agree,
plus
one
to
that
right,
like
we
have
all
these
Downstream
specific
API
talks
that
get
easily
accepted
versus
you
have
a
hard
time
getting
the
Upstream
ones.
So
it
would
be
good
to
have
a
maintenance
track
to
just
talk
about
the
API
and
get
more
implementations
in
our
radar.
F
A
Exciting
stuff
super
excited
on
the
progress
we're
making
here.
My
goal
is
to
hopefully
get
this
a
this
release
cut
done
before
that
Thursday
meeting.
So
if
folks,
could
you
know
take
a
pass
this
afternoon
and
tomorrow
on
my
PR,
that's
adding
all
that
release
tooling.
That
would
be
really
awesome,
because
it's
also
updating
our
website,
so
you
can
either
kind
of
focus
on
the
website,
design,
stuff
or
the
release
tooling
stuff.