►
From YouTube: Network Policy API Meeting for 20230131
Description
Network Policy API Meeting for 20230131
A
Okay,
awesome
today
is
Tuesday
January
31st
2023.
This
is
a
meeting
of
the
Sig
Network
policy
API
subgroup
to
Sig
Network.
This
is
a
cncf
certified
meeting,
so
please
follow
all
the
rules
and
be
nice
to
each
other,
I.E,
no
cussing
or
making
anyone
feel
bad.
Those
are
the
general
rules
for
this
meeting.
A
We
don't
have
much
on
the
agenda
today.
Last
time
we
talked
a
bit
about
Network
policy
V2
and
my
plan
for
today
was
Hispanic
to
kind
of
continue
with
that
conversation
going
off
of
a
doc.
Dan
has
put
together
generously
since
the
last
meeting
before
we
hop
into
that.
We
have
some
newer
faces
here.
I'll
just
give
you
all
a
chance
to
kind
of
give
an
intro.
A
If
you
want
no
worries,
if
you
don't,
but
if
you're
new
to
this
meeting,
you
want
to
introduce
yourself
feel
free
to
go
ahead
and
do
it.
B
I
can
go
first
hi,
you
know
hi
everybody
good
morning,
good
evening,
I'm
K7
and
I
work
for
LinkedIn.
B
My
first
meeting
here
I've
heard
a
lot
of
good
things
from
somebody
else
out
at
Google
about
some
of
these
sick
meetings,
and
you
know
this
is
my
first
day
so
I'm
hoping
to
learn
and
I
personally
I've
started
something
on
silium
and
evaluating
Calico
on
implementing
Network
policies
for
our
next
10
systems
and
stuff,
so
I'm
hoping
to
learn
and
kind
of
the
learn,
the
do's
and
especially,
what
not
to
do
stuff.
So
so
yeah
I'm
excited
to
be
here
and
thanks
for
the.
A
Awesome
well
we're
super
happy
to
have
you.
You
know
we.
We
always.
We
often
forget
that
we've
all
been
meeting
for
quite
a
long
time.
So
if
there's
any
questions
like
Stop
Us,
Mid
meeting
we're
happy
to
take
them,
you
can
also
reach
out
in
Stig
Network
policy
API
black
channel,
so
we're
there
to
help
feel
free
to
reach
out
individually
around
the
channel
whatever,
but
yeah.
Thanks
for
coming
appreciate
it
completely.
A
Cool
okay,
anyone
else
don't
ask
twice:
it's
old
I
think
everyone
else
has
been
here:
Shane
is
dropping
in
thanks,
Shane
yeah,
it's
been
a
while
yeah
for
sure,
so,
just
kind
of
as
a
rewind
I
alluded
to
it.
At
the
beginning.
Last
week,
John
Howard
from
I
believe
a
service
mesh
group
I
can't
remember
exactly
which
one
kind
of
came
in
and
restarted
pushing
on
some
more
features
for
Network
policy
and
that,
as
usual,
our
answer
is
Network
policy.
V2
right
like
we're
trying
to.
A
We
are
avoiding
adding
any
new
features
to
network
policy
and
we're
looking
towards
the
future
of
what
V2
may
look
like
we're
still
looking
for
an
owner
for
that.
If
anyone's
watching
this
video
and
wants
to
spearhead
this
effort,
we
need
the
help
so
reach
out
to
us.
That
would
be
really
great.
A
So
our
goal
is
to
kind
of
roll
over
into
a
new
document
like
let's
redefine
some
of
the
user
stories.
Some
of
the
ideas
around
our
policy
too,
in
the
last
two
weeks,
Dan
put
together
a
document
kind
of
highlighting
some
of
his
thoughts,
so
I
thought
we
could
just
maybe
run
through
these
kind
of
quickly
give
a
shout
out
in
general
for
people
to
give
a
look,
but
I
think
it
gives
a
good
overview
of
like
the
guiding
principles.
At
least
I
think
that
go
with
B2.
A
So,
okay,
so
this
document
I'll
share
the
link
in
the
chat.
It's
in
the
agenda,
which
is
a
part
of
the
calendar.
Invite
but
I'll
also
share
it
in
the
chat
here.
So
you
can
hop
in.
A
You,
oh
sorry,
I
got
it
awesome.
I
didn't
see!
You
happen.
Sorry,
that's
great!
Thank
you!
Yeah!
So
Dan's
Network
positive
you
two
thoughts.
Dan
I,
don't
mean
to
put
you
on
a
spot.
Do
you
want
to
run
through
these
at
a
high
level,
or
do
you
have
any
like
overarching
things
to
say,
I,
don't
think
we
need
to
necessarily
like
walk
through
this
dock
I.
Think
it's
a
thing
that
folks
need
to
go
and
read
and
get
some
comments
on
so
that
we
can
morph
it
into
like
a
community
dock.
C
Yeah
I
mean
I,
guess
I
can
just
like
Summarize
each
point
pretty
quickly.
So
the
first
one
is
just
that
you
know.
While
we
always
talk
about
Network
policy,
V2
like
API
V2
means
something
very
specific
in
in
kubernetes,
and
we
don't
actually
want
that.
So
we
can
keep
calling
it
Network
policy
V2.
But
people
just
need
to
keep
in
mind
that
it's
not
actually
we're
going
to
have
to
change
the
name.
It
can't
still
be
called
Network
policy
anymore.
C
So
my
second
suggestion
was:
it
needs
to
be
fully
interoperable
with
with
V1
I
mean
it
would
be
great
if
we
could
just
say
yeah
we're
just
going
to
totally
throw
away
V1
and
forget
about
it.
But,
like
you
know,
people
will
be
installing
bits
of
software
that
come
from
different
places
and
some
of
them
may
have
been
upgraded
to
know
about
Network
policy
V2
and
some
of
them
might
not,
or
they
might
want
to
like
still
be
using
V1
so
that
it's
compatible
with
both
old
and
new
clusters
and
blah
blah
blah.
C
D
A
That
yeah
I
think
this
is
like
a
direct
problem.
The
Gateway
API
folks
dealt
with
going
from
Ingress
to
the
Gateway,
API
and
I
know
I
posted
a
tool
there,
like
they
literally
have
a
tool
that
converts
Ingress
objects
to
Gateway
API
objects.
If
it
was
my
opinion,
like
obviously
need
to
do
well,
specked
out,
but
I
think
I
would
say
like
this.
Instead
of
being
fully
interoperable
I
think
the
feature
set
of
network
policy
V2
needs
to
be
like
complete.
A
It
needs
to
include
all
of
the
features
in
our
policy
V1
already
had
but
expanded
upon,
so
that
you
can
express
any
network
policy.
V1
object
as
a
network
policy.
V2
object.
C
And-
and
we
sort
of
get
to
this
later
in
the
document,
but
my
idea
of
network
policy
V2-
is
that
it's
actually
two
separate
objects,
or
rather
three
admin,
Network
policy,
Baseline
admin,
Network
policy
and
developer
Network
policy,
and
so
some
individual
Network
policies
the
way
I'm
imagining
this
would
be
expressible
as
either
an
admin,
Network
policy
or
well
you
you
might
need
a
combination
of
the
different
policy
types
rather
than
necessarily
being
able
to
convert
any
npv1
object
into
a
single
V2,
but
yeah.
D
D
So
my
thought
on
that
is
that
the
current
Network
policies
are
nice
and
that
they
have
very
few
addresses
in
there.
They
talk
about
objects
to
orbit
communication,
and
it
doesn't
say
anything
about
which
network
that
is
used
for
this
communication
and
therefore
it
should
in
reality
also
cover
multi-networking.
A
I
I
think,
in
my
opinion,
like
we
need
to
give
the
base
framework
for
multi-networking
to
be
accomplished
with
network
policy
V2,
but
I.
Don't
think
it's
necessarily
this
group's
job
to
figure
that
out.
Just
because
the
multi-network
group
is
you
know,
I
already
have
a
bunch
of
time
invested
right
and
I
think
it's
going
to
highly
depend
on
what
they
come
up
with
at
the
end
of
the
day.
A
So
I
think
it
needs
to
be
built
such
that
we
can
expand
to
support.
Whatever
comes
out
of
that
working
group,
I,
don't
know
when
that's
going
to
be
obviously
Fair.
Maybe
you
have
a
better
idea
on
that.
D
C
Yeah
I
I:
we
we
should
not
I
I,
think
we
we
shouldn't
try
to
push
all
of
this
onto
multi-network
like
we.
We
should
be
explicitly
thinking
about
both
multi-network
and
multi-cluster,
because
those
are
both
cases
where
existing
Network
policy
has.
It
has
not
good
enough,
and
you
know
if
we're
redesigning
everything
we
want
to
include
all
the
important
things
in
the
design
and
I
didn't
mention
either
of
those
in
this
stock.
So
yeah.
A
Cool
no
I
think
it's
important.
Let's
keep
it
in
mind.
This
stock
I
think
is
like
kind
of
some
overarching
ideas
about
npv2
when
it
comes
down
to
the
actual
user
stories.
We're
gonna
have
to
spend
a
lot
of
time
as
a
group
passing
out
of
each
one
and
I
think
Network
our
multi-network
will
definitely
be
one
of
them.
D
C
C
Can't
because
then
you
know,
old
implementations
won't
see
it
and
they'll
interpret
it
incorrectly.
So
we
need
to
figure
out
a
way
to
deal
with
that
like
once
and
for
all
need
fewer
gotchas.
You
know
you
can
read
the
details
there,
but
everybody
knows
Network
policy
B1
is
is
tricky
and
confusing,
and
we
don't
like
that.
C
So
we
don't
want
mpv2
to
be
npv1,
but
just
more
more
like
and
and
go
through
and
read,
like
Network
policy
V1
evolved
in
a
way
that
was
very
different
from
how
it
was
originally
designed
and
as
a
result,
it's
a
complete
mess,
and
we
don't
want
that.
So
we
need
to
like
go
back
to
basics
and
figure
out
how
to
have
a
a
clean,
well-designed
npv2,
which
in
particular
means
the
next
bullet
point.
We.
D
C
We
need
to
clear,
be
very
clear
about
when
we're
doing
policies
for
administrators
and
when
we're
doing
policies
for
the
application
developers
or
application,
deployers
and
and
I'm,
proposing
that
you
know
we
keep
those
separate.
So
we
adopt
admin,
Network
policy
as
being
the
first
half
of
npv2,
and
then
we
work
on
a
second
developer
Network
policy
to
cover
the
the
application
side
of
it
and
then
the
two
of
them
combined
are
npv2.
A
C
A
D
C
Yeah,
and-
and
actually
it's
a
another
time
here-
is
that
some
of
the
use
cases
that
I
talk
about
like
we,
we
may
want
to
end
up
pulling
in
the
F
the
the
fully
qualified
domain
name,
Network
policy
stuff,
which.
A
I,
don't
even
think
it's
been
an
argument
of
how
we're
going
to
do
it
from
an
API
sense.
It's
been
an
argument.
It's
been
that
kind
of
backwards.
Argument
of
you
can't
put
that
in
your
API,
because
we
can't
implement
it
right
and
nobody's
really
hashed
out
that
it
I
mean
people.
Do
it
already
and
we
end
up
always
digressing
into
an
argument
of
like.
Is
this
actually
a
good
implementation
which
really
shouldn't
be
part
of
the
API
design?
Well,.
D
But
anyway,
it
comes
down
to
how
are
you
egressing
right?
Are
you
doing
it
that
they
sort
of
layer,
three
layer,
four
level,
we're
doing
it,
that
sort
of
layer,
seven
layer
and
the
the
answers
becomes
different
right
at
one
level,
it's
layer?
Seven!
You
actually
see
this
URL.
What
are
the
other?
The
translation
happens
somewhere
and.
C
B
A
A
A
Yeah
I
totally
agree.
So
in
my
personal
opinion,
like
this
Doc's
awesome,
if
I'm
gonna,
let
the
review
continue
and
maybe
next
time,
if
no
one
has
any
objective
objections,
we're
gonna
check,
we
can
just
change
and
Dan
doesn't
have
any
objections.
We
can
just
change
this
to
network
velocity
V2
thoughts
and
it
can
be
kind
of
like
the
start
of
our
investigation
into
this
I'm,
also
happy
to
make
another
Doc
and
just
copy
and
paste
some
of
this
stuff
or
try
to
organize
it
differently.
A
D
A
Bye
I
think
it's
a
really
great
start.
It's
stuff,
we've
talked
around
for
a
long
time
and
Dan
has
put
into
words,
which
is
what
always
needs
to
be
done,
so
huge
shout
out
to
Dan
thanks
so
much.
This
is
really
really
great
for
folks
watching.
Please
take
a
look
at
this
we'll
talk
about
it
again
next
meeting
and
hopefully
actually
start
down
the
path
of
getting
some
stuff
done
with
our
policy
V2,
because,
obviously
we
need
it.
A
Cool,
nothing
really
there's
nothing
on
the
agenda,
but
there's
still
some
open
issues
on
our
repo
around
website
changes
and
getting
stuff
done
for
having
network
policy.
A
Ryan
I
know
is
working
on
some
stuff
kind
of
in
a
band
he's
in
the
meeting,
but
he
actually
just
had
a
child.
So
congrats
Brian,
that's
awesome,
but
he's
looking
at
working
on
cyclonus
and
some
integration
testing
bits
for
admin.
Network
policy
Surya
is
looking
at
integration
and
implementation
of
kubernetes,
so
things
are
moving
along,
albeit
very
slowly
feel
free
both
of
you
all
at
any
point.
Not
today,
you
don't
have
to
to
give
an
update
on
where
you
are
to
this
group.
We're
all
happy
to
hear
about
it.
A
A
Cool
I
don't
have
anything
else
for
today.
If
there's
no
questions
I'm
happy
to
end
the
meeting
early
I'll
open
it
up
open
up
the
floor.