►
From YouTube: SIG Network: Network Policy API Meeting 20200928
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).
C
A
B
Yeah
so
last
week
we
have
decided
to
to
assemble
a
really
short
document
with
with
the
four
user
stories
that
we
think
they
were
in
the
issue
30
or
33.
I
can't
remember
and
that
we
decided
that
it
could
be,
it
could
ship
to
the
v1
api
network
policy
api
without
any
without
not
huge
impacts,
and
so
I
have
assembled.
B
I
have
taken
the
responsibility
to
assemble
this
document
and
that's
sent
to
you
in
the
signature
channel,
and
I
think
that
also
in
slack,
so
everyone
could
take
a
look
into
the
document.
We
can
close
our
concerns
about
this
document
and
present
this
to
sig
network
in
the
meeting
next
thursday.
I
think
that
is
thursday.
D
B
Of
each
of
the
the
the
changes
and
and
then
starting
the
dprs
of
the
caps
and
then
moving
to
to
improving
the
dual
network
policy
without
having
impact
in
into
our
job
into
our
work
with
with
the
v2
network
policy,
so
I've
set
the
document
linked
to
you
in
the
slash
in
the
zoom
chat,
but
if
you
want,
I
can,
I
can
share
my
screen
here
and
we
can
like
andrew
has
made
some
comments.
B
Abhishek
also
has
made,
has
made
some
comments.
My
expectation
about
this
is
that
we
close
this
document
today
and
can
present
this
in
the
next
in
the
next
meeting
this
thursday,
so
yeah.
If
you
want
to
share
and
go,
go
ahead
and
draw
a
thing,
that's
better.
B
So
we
are
seeing
andrea's
screen
right
now,
and
the
first
proposal
was
the
port
ranges
and
port
set.
I
have
organized
this
document
into
the
objective.
Abstract
suggested
that
we
put
the
limitations
with
v1
api
and
the
problems
to
be
solved.
So
the
first
one
is
port
ranges.
Part
set,
allow
a
network
policy
to
contemplate
a
set
of
parts
in
a
single
room.
B
B
B
I
think
that
that
the
message
of
this
example
is
wrong.
I
agree
with
that
with
that.
So
using
like
a
sort
of
problem
like
I,
I
want
a
low
degrees
to
the
north
node
port
range
of
a
different
cluster
like
egress
to
portrait
three
thirty
thousand
to
thirty
two
thousand.
I
would
need
to
declare
like
each
part
in
the
network
policy,
and
we
want
to
solve
this
kind
of
problem
here.
E
Yeah,
I
think
so,
can
I
I
can
remove
this
yeah.
A
B
Sure
so
the
for
the
first
one
is
the
port
range
sports
set
yeah.
Next
one
is
the
select
name
space
by
name
in
in
network
policy.
The
third
one
is
the
node
selector
for
network
policy
and
the
fourth
one
is
the
cluster
scoped
network
policy.
The
idea
of
the
last
one,
the
the
cluster
scope
network
policy
is,
is
a
new
object
and
not
changing
the
older
one,
but
we
are
going.
We
are.
E
Yeah
that
that's
basically
where
we
like
what
the
four
came
from
and
I
I
think
what
what
we're
trying
to
do
right
now
is.
E
It
seemed
like
we
got
contestants
from
the
broader
group
on
these
four,
as
like
kind
of
I
don't
want
to
say,
low-hanging
fruit,
like
things
we
can
get
started
on
for
v1,
and
I
think
what
we
want
out
of
this
meeting
is
if
there
are
strong
objections
to
any
of
these
four
that
are
worth
calling
out.
We
should
do
that
right
now,
so
that,
if
we
need
more
time
to
think
these
through
and
reason
about
some
of
the
use
cases,
we
can
do
that.
E
Otherwise,
I
think
ricardo
wants
to
pull
the
larger
stick
network
group,
for
if
these
are
going
in
the
right
direction
or
not.
B
A
B
The
the
main
idea
here
is:
okay.
We
we
we've
been
discussing
these
like
in
the
last
six
months,
and
this
is
what
we
we
want
to
do
right
now
with
v1,
but
we
want
also
to
do
some
some
other
stuffs
in
v2,
but
doing
this
will
solve
a
lot
of
problems
for
the
community
and
the
users,
and
it
doesn't
seem
so
hard
to
cheat
to
ship
this.
F
Sorry
can
I
can.
I
also
ask
one
other
question
related
to
the
port
rangers
port
set.
Would
it
be
a
completely
different
use
case
or
an
extension
of
this
use
case
if
we
said
that,
for
let's
say
you
wanted
to
write
an
ingress
from
port
or
something
like
that,
because
right
now,
when
you
write
an
ingress
rule,
you
only
can
specify
the
ports
on
the
pod
that
is
receiving
that
packet,
but
you
can't
necessarily
specify
the
port
of
the
sender.
F
B
B
I
don't,
I
don't
think
relevant
to
the
cni's,
because
they
because
the
implementation
of
the
cni
is
much
like
the
aws
security
groups
and
other
stuff,
like
you
are
more
concerned
about
the
the
destination
part
like
the
origin,
the
origin,
the
destination
and
the
destination
port
if
they
are
ingress
or
the
other
than
the
search
part,
because
you
don't
confirm
the
search
part.
So
that's
that's
my
opinion.
F
F
So
that
would
be
just
some
some
sort
of
like
cloud
specific
implementation,
or
something
is
that
is
that
mine
is
my
sign.
E
E
I
don't
think
it's
necessarily
like
based
on
clouds.
I
think
it
is
like
an
implementation
detail
where
I
guess
a
network
policy
implementation
could
block
source
ports
like
outbound
source
ports
at
certain
ranges
and
whatnot.
But
in
my
experience
that's
not
usually
required,
like
you
block
it,
based
on
what
the
outbound
destination
port
is
and
not
sure
what
this,
what
the
source
part
is.
Okay,
so
yeah,
I'm
not
really
sure
what
you
meant
by
that
question.
F
So,
okay,
let
me
give
you
an
example.
I
guess-
or
maybe
this
isn't
going
on-
maybe
we
can
come
back
to
this
afterwards.
I
was
just
curious
if
this
is
related
to
the
first.
You
know
user
journey
here.
A
I
I
don't
think
it's
not
unrelated.
It's
just.
I
think
it's
fundamentally
crossing
boundaries
of
the
data
model,
though,
because
even
if,
like
I
don't
even
I
don't
know
whether
it's
a
valid
use
case
or
not.
I
I
can't
really
comment
much
on
that,
but
I
I
just
know
that
the
way
ports
are
now
they're
tied
to
an
ingress
or
an
egress
rule
that
you're
making
on
a
specific
policy
to
secure
a
specific
pod
right.
A
So
it
would
be.
It
would
be
very
awkward
so
for
the
purposes
of
this
conversation,
which
is
this
document
which
is
low
hanging
fruit
right
because
you're
going
to
be
contorting
the
data
model,
it's
not
relevant
here,
right,
okay,
I'm
all
for,
like
you
know,
whatever
we
can
put
it
somewhere
else
and.
E
Talk
about
it
as
a
tier
2
use
case
or
something
sounds
good.
I
think
I
think
it's
worth
clarifying
right
to
me,
like
the
reason
in
the
past.
It
hasn't
is
because
source
ports
are
generally
random
from
the
client
so
and
usually
like
the
connect,
the
contract,
implementation
or
the
connecting
tracking
implementation
like
just
tracks
the
source
port
to
where
the
regress
destination
is
and
when
the
pack
comes
back,
it
just
maps
the
source
part
back
to
the
inbound
packet.
So
in
nature,
it's
dynamic
and
it's
not
supposed
to
be
tracked.
I
think.
F
I
see
so
you
would
say
that
only
source
ips
would
be
used
for
something
like
that,
something
like
what
exactly
for
prevention
of
dos.
F
The
reason
I
was
asking
is
because,
like
if
you
think
about
how
kubernetes
is,
you
know,
is
on
the
receiving
end
of
packets
from
the
other
side
of
the
you
know,
the
internet
there's
many
layers
of
you-
know
protection
on
the
way,
but
if
you're
deploying
in
like
say
an
on-prem
environment
or
something
like
that,
you
don't
have
the
luxury
of
like
you
know,
cloud
load,
balancer
is
doing
dos
protection
for
you
and
things
like
that.
F
So
and
you
could
potentially
see
narrow
policy
as
a
way
to
do
real
time,
like
dos
prevention
on
your
pods.
That's
that's.
Why
that's
what
I
was
thinking
about
and
ip
and
ford
was
a
good
combination
to
come
up
with
for
dos
prevention.
So
that's
that's
what
I
was
asking
and
this
sounded
related,
but
but
I
guess
it's
a
to
j's
point.
Maybe
it's
contorting
the
neural
policy
model.
E
B
F
I
think
yeah
that
makes
sense
to
me
yeah.
I
just
wasn't
like
I
think,
when
I
didn't
have
the
realization
in
my
head,
that
this
would
actually
fundamentally
be
altering
sort
of
the
data
model
or
the
the
purpose
of
their
policy,
and
that
that's
why
it
probably
is
not
just
an
extension
of
the
use
case
here,
but
rather
a
much
broader
scope
exercise.
So
that
makes
sense.
B
So
can
we
move
to
the
next
one
select
namespace
by
name
in
a
network
policy,
so
this
one?
There
is
like
a
large
discussion
about
whatever
labels
or
names
are
authorities
in
in
namespace
in
the
sick
architecture.
I
recommend
everyone
to
read
that
and
also
propose,
but
the
idea
here
is
that
we
will
not
allow
a
network
policy
to
use
a
namespace
name
as
a
selector
instead
of
labels.
B
B
By
labels,
and
by
name
because
we
have
some
problems
specified
below
in
the
end
in
the
secret
architecture,
mating
lists.
So
the
first
one
is
that
a
group
of
users
wants
to
allow
ingress
in
their
bots
from
any
pods
in
another
namespace.
But
they
don't
want
to
trust
the
label
as
a
selector
of
the
namespace,
because
per
cluster
airbag,
any
user
can
put
their
own
labels
in
their
own
namespace
and
become
a
opening
space.
B
So
this
is
a
problem
I
I
actually
I
didn't
solve
that
because
we
are
pretty
restrictive
in
my
company
with
the
policies,
but
I
think
that
you
can
allow
a
user
to
put
their
own
labels
in.
B
There
is
other
another
proposal
here
from
andrew
that
namespace
are
often
standalone
and
may
not
need
to
be
logically
categorized
using
labels
yeah
exactly
like
system.
We
don't
want
to
use
labels
in
this
case
to
select
so
referencing
by
name
prevents
necessary
labeling
of
namespace
to
fit
into
the
network
pulse
api.
So
anyone
have
any
consideration
about
this.
I
think
this
is.
This
is
one
that
is
going
to
bring
probably
more
discussion
that
the
cluster
api
with
the
cluster
sculpted
are
the
nodes
selector,
because
there
is
a
a
sense
in
in
since
architecture.
B
H
I'm
not
sure
if
it's
a
solution
might
just
be
more
problems,
but
I
I
had
seen
where
the
service
v2
apis.
They
had
a
similar
discussion
and
seems
like
the
direction.
H
I
have
to
go
back
and
check
the
specifics,
but
the
direction
was
that
you
know
they
were
intending
to
have
the
cluster
and
infrastructure
personas.
You
know
labeling
those
name
spaces
in
the
context
of
like
a
gateway
class,
and
so
I
guess
when
you
said
you
know,
moving
away
from
putting
labels
on
namespaces.
H
I
guess
I
was
worried
that
the
folks
are
actively
heading
more
towards
that.
At
the
same
time,
I'm
just
not
sure
if
that's
gonna
be
all
that
gonna
be
agreed
upon.
Rather,
you
know
what
I
mean
outside.
E
E
You
see
out
there,
but
then
there
are
cases
where,
like
you
just
have
one
namespace,
that's
isolated
to
do
one
thing
and
it
may
not
necessarily
belong
to
any
team,
but
you
want
to
like
kind
of
allow
or
deny
list
it
in
your
policies
and
it'd
be
kind
of
awkward
to
force,
assign
like
a
team
label
to
it
when
it
doesn't
belong
to
the
team.
H
The
example
they
used
was
internal
versus
external
or
a
network
gateway
right,
but
yeah.
No,
I
see
your
point.
D
G
B
B
E
Two
three,
so
I
I
I
one
one
thing
do:
would
it
be
useful
to
change
the
ordering
of
these
two
problems
that
we're
solving?
Because
I
feel
that
the
usability
of
listing
namespace
by
names
is
likely
a
better
selling
point
than
around
the
multitask,
the
multi-tenancy
story
and
security
around
label
selectors
for
namespaces,
because
this
one
is
more
ambiguous
in
terms
of
like
whether
it's
an
actual
problem
or
not,
whereas
being
able
to
select
name
spaces
by
their
like
specific
names,
is
more
of
a
improvement
to
the
usability
of
api.
E
Yeah,
but
basically
what
I'm
saying
is
that
I
think
we
should
order
these
problems
to
be
solved
in
the
order
that
we
think
are
most
important
to
least
important,
and
so
I'm
basically
asking
do.
We
feel
that
this
problem
we're
solving,
is
more
important
than
the
first
one,
and
should
we
swap
the
order.
D
So
I
think
the
first
problem
statement
is
also
related
to
or
relevant
to
the
the
admission
controller's
namespace
letter.
So
maybe
there
is
yes
like
a
broader
user
story.
In
that
particular
statement.
B
B
And
we
wanna
solve
a
problem,
I'm
gonna
read
andrews
first
and
then
my
my
next
so
the
last
one
is
a
group
of
nodes
in
a
cluster
may
be
labeled,
maybe
label
to
run
a
specific
class
of
workloads,
whereas
traffic
between
those
nodes
should
be
allowed,
but
any
traffic
to
other
nodes
should
be
restricted
like
this.
Is
this
the
case
of
life
is
probe
also
emperor.
Do
you
think.
B
C
A
B
Yeah,
I
was-
I
was
thinking
about
this
thing
here.
Oh
okay
and
a
group
of
users
works
in
a
really
restricted
environment.
We
deny
our
rules
by
default
and
they're
responsible
for
the
cluster
monitoring
and
need
to
open
a
row.
Super
meteors
running
cluster
can
reach.
The
tablet
read
only
part
for
every
node
of
the
cluster,
but
only
that
also
this.
This
case
is
like
I
have
a
namespace,
that's
that's
restricted
with
prometheus,
but
I
need
to
reach
like
only
api
server
to
discover
the
nodes
and
then
the
couplet
really
only
part
with.
E
So,
regarding
jay's
comment
around
pods,
no
local
traffic,
and
maybe
this
is
going
to
implementation
details,
but
I
I
think
it's
good
to
have
an
answer
for
this
ahead
of
time.
I
agree,
like
it'd,
be
a
breaking
change
the
api.
If,
by
default
we
denied
no
local
traffic
and
you
you
had
to
then
add
a
network
policy
to
allow
the
local
traffic
to
pass
through.
E
E
There
need
to
be
some
built-in
api
field
or
something
that
says
like
deny
from
all
of
their
nodes,
but
allow
local,
because
maybe
you
for
like
liveliness
probes
or
whatever
I
mean
it
also
sounds
like
the
default
should
be
to
allow
node
local
always
to
not
break
existing
users.
E
D
I
say
this
is
the
user
story
that
I
kind
of
struggle
with
a
little
is
that
I
feel
like?
Maybe
this
is
something
like
a
subsection
of
the
next
user
story,
which
is
the
cluster
scope
network
policy,
because
I
feel
like
this
is
more
geared
towards
the
administrators
than
the
developers
and
then,
if,
if
that
is
the
case,
then
then
it
will
be
a
v1
of
a
new
resource
and
that
is
not
kind
of
making
existing
v1
network
policy
again.
D
But
but
if
we
do
strongly
feel
that
the
developer
api
should
also
include
node
selectors,
then
we
need
to
explain
why
how
we
can
not
have
the
story
break.
You
know
backwards,
compatibility.
A
A
A
E
D
The
only
thing
that
I
wanted
to
bring
it
up
this
week-
or
I
wanted
to
add
this
as
part
of
like
a
as
a
subsection
of
the
next
user
stories,
because
that
way
we
don't
have
to
you
know
kind
of
give
an
explanation
about
how
it
does
not
affect
backwards
compatibility,
because
it's
not
something
that
we
intend
to
add
to
the
network
policy
view
and
api,
but
yeah.
This
is
the
story
that
I
feel
like
needs
a
lot
more
thought
than
I
could
in
my
mind,
I
don't.
D
Yeah
because
alls
are
not
or
your
nodes
are
not
really
caring
about
whether
the
chord
is
in
space
a
or
namespace
b.
The
node
is
hosting
paths
of
all
kinds
of
namespaces.
E
Okay,
so
I
guess
I
guess,
okay,
because
I
don't
want
to
spend
too
much
time
on
this
one
thing,
but
it
sounds
like
there's
a
lot
of
thinking
that
needs
to
go
through
it,
and
most
of
it
is
probably
like
for
the
cap.
Do
we
still
find
the
use
case
compelling
enough
to
write
that
cap
or
do
we
feel
like
too
abstract?
Let's,
let's
punt
it
for
later
and
maybe
jay?
E
A
Yeah,
that's
a
water
carrying
thing,
though
I
I
talked
to
a
lot
of
people
about
that
right,
like
I
think
I've
talked
to
you,
andrew
and
so
but
yeah
I
mean
if
I'm
the
owner
of
it.
I
don't
mind
right.
I
guess:
okay,
if
I'm
the
owner
of
it,
ricardo
and
and
you
all,
I
mean
everybody
really
decides
that
we
want
to
do
this
and
we
want
to
do
it.
B
I
don't
know
if
other
people
are
thinking
about
it.
I
was
going
to
to
suggest
that
we
prioritize
the
both
from
the
to
first
part
range
and
select
mean
space
by
name
and
then
go
to
cluster
scope
network
policy,
because
this
is
this:
probably
something
that
who
is
this
bothering
that's
my
question
like
how
many
people
is
asking
this
look
select
or
what?
What's
the
the
need
of
the
community?
E
A
Yeah,
it's
almost
like
the
people
that
have
thought
a
lot
about
this
see.
This
is
a
problem,
but
it's
not
something
that's
popular
in
the
community,
because
most
people
in
the
community
haven't
thought
through
the
security
holes
that
are
sitting
there.
So
it's
a
weird
one
right,
like
yeah,
it's
classic
like
inverse
bike
shedding
right,
like
the
people
who
really
know
what's
going
on
are
like
yeah.
We
have
to
have
this,
but
it's
not
an
easy
thing
to
talk
about
so.
E
Okay,
so
it
sounds
like
it's
important,
but
very
thorny
problem,
so
ricardo
good
to
remove
it
from
this
stock
at
least
and
we
can
revisit
for,
but
maybe
there
may
be
a
follow-up
proposal
for
other
v1
stuff,
but
with
this
one
for
many
distributions,
anyone
else
think
that
anyone
else
object
to.
A
I
mean
I
feel
like
the
best
would
be
to
move
it
to
the
bottom
so
that
we
don't
necessarily
have
to
remove
it,
but
I'm
okay,
removing
it.
But
I
just
that's
another
option.
B
So
here
we
go
it's
okay,
so
the
last
one
is
the
cluster
scoped
network
policy.
The
objective
is
enforced,
natural
policy
rules
for
a
set
of
or
all-name
spaces
in
a
cluster
limitations
with
view,
and
the
api
only
supports
the
inspective
rules,
but
you
cannot
create
a
route
that
applies
to
a
set
of
namespace
or
the
whole
cluster.
B
D
B
F
I
don't
know
I
make
a
quick
clarification
to
the
first
bullet
of
problems
to
be
solved.
Cluster
admin
wants
to
once
that
all
name
spaces
have
a
default,
deny
rule
for
ingress
and
egress,
but
it's
up
to
the
developer
to
open
a
new
namespace
specific
network
policy.
So
if
I'm
understanding
this
correctly,
if
some,
if
an
administrator,
puts
a
cluster
scope,
never
policy
says
no.
Namespaces
can
talk
to
each
other
on
this
cluster.
B
Yeah,
so
so
something
that
we
have
discussed,
I
think
in
the
last
meeting,
is
that
we
have
two
two
classes
of,
in
my
opinion,
took
two
classes
of
cluster
scope
with
network
policy.
You
have
like
a
defaulting
eye,
that's
protecting
the
namespace,
but
that's
not
required.
You
can
buy
passive
and
you
have
like
a
compliance
natural
policy
that
doesn't
allow
your
like.
B
I'm
not
going,
I'm
going
to
allow
you
to
reach
core
dns,
even
if
you
would,
if
you
don't
want
to,
are
I'm
not
going
to
allow
you
to
to
reach
like
the
portmap
port
from
our
from
anywhere,
because
that's
a
a
policy
from
the
the
cluster,
but
I
I
I
think
that
this
one
we
should
like
evolve
better
in
the
cab.
How
are
you
going
to
reach
this.
D
Okay
yeah,
but
we
kind
of
discussed.
I
think
you
know
when
we
spoke
about
precedence
in
our
call
like
when
we
yeah
yeah
this
this
kind
of
problem.
Maybe
we
can
you
know
detail,
but
it
does
require
both
kind
of
precedence
like
you
know,
something
which
is
has
higher
precedence
and
then
some
some
default
precedence.
B
F
Sorry
when
I
said
inheritance,
I
I
meant,
like
you
know:
the
admin
sets
sort
of
a
super.
You
know,
maybe
the
base
policy
or
something
and
then
the
developers
can
go
and
like
keep
adding
more
stuff
to
it.
And
the
hierarchy
is
like
you
know,
the
the
administrator
can
set
a
rule
and
that
always
gets
enforced
before
the
developers.
And
if
that
action
you
know,
denies
it,
then
it
denies
the
action
and
entirely
it
doesn't
go.
F
A
This
is
just
gonna,
be
a
very
big
cap.
Bro
right
like
this
is
a
tricky
one,
because
I
mean
what
is
this
kept
really
gonna
be
right,
like
I
mean
you're,
gonna
have
to
put
priorities
into
it.
You're
gonna
have,
to
put
I
mean,
like
you
know,
you're
gonna
have
to
have
that
thing
that
I
saw
that
thing
in
the
last
community
meeting
the
andrea
community
meeting,
where
you
had
that
big
division
of
priorities
with
decimals
and
all
that
stuff.
Obviously,
like
I
don't
know
like
how
are
you
going
to
do
this?
A
D
B
A
A
D
So
yeah,
that's
that's
again.
Kind
of
like
ask
this
question
in
the
first
leg
in
the
beginning
is
that
we
are
not
going
to
talk
about
implementation
or,
like
the
api
sketches
in
each
of
these
stories.
I
think
the
the
when
we
propose
this
to
the
sick
network.
It's
more
like
you
know.
These
are
the
user
stories
that
are
more
common
and
agree
upon
and
we
will
work
as
caps
for
these
stories
and
then
you
know,
detail
them
individually,
but
but.
B
D
I
think
this
this
is
similar
to
what
the
service
api
thing
is,
that
you
have
to
come
and
implement
a
new
api
sketch
and
for
for
this
particular
user
showing.
So
it's
it's
an
effort
which
is,
like
you
know,
think
about
like
the
ipv6
dual
stack
effort,
it's
a
very
large
effort
because
I
think
a
single
cam
which
then
maybe
spans
across
releases
or
things
like
that.
So.
A
I'm
almost
like
tend
to
think
that,
like
we
should
be
basically,
this
doc
should
have
this
as
like.
Actually
this
will
be
maybe
the
purpose
of
this
working
group
moving
forward.
Here's
like
the
small
improvements
we
could
make
and
then
like
really,
the
main
focus
of
the
group
moving
forward
would
be
to
do
if,
if
you
think
this
is
the
scope
of
the
service
api's
group
that
from
now
on
our
meetings
are
you
know,
a
majority
is
planning
that
and
then
the
minority
of
the
meetings
is
figuring
out
all
the
other,
smaller
use
cases.
D
You
know
what
I
mean:
yeah
yeah.
I
think
this
is
like
a
two-pronged
approach
like
where
we
try
to
get
these
additive
use
cases.
You
know
on
a
faster
pace,
but
this
is
the
one
that
will
you
know
will
require.
The
group
to
you
know
come
up
with
and
come
up
with
this
sketch
on
a
longer
timeline
basis,
but
it
is,
it
is
going
to
be
like
a
group
effort,
I'm
not
saying
that
then
I
am
going
to
just
write
something,
and
this
is
what
I
did
dictate.
A
A
A
You
know,
including
goldman's
use
case
that
he
brought
up
today
right.
So
I
don't
know,
that's
that's
like
what
I
would
say,
but
I
don't
know
I'm
happy
to
include
it
in
this
doc.
If
you
all
want,
I
just
wanted
to
spitball
that
for
a
little
bit.
D
So
I
thought
the
purpose
of
this
talk
was
to
talk
to
the
sig
network
and
see
these
are
the
ideas
that
the
group
is
going
to
work
on.
Some
of
these
ideas
are
something
which
will
be
faster.
D
You
know,
which
will
be,
which
can
be
done
immediately
with
smaller
caps,
and
one
of
this
idea
will
require
a
larger
effort,
but
these
are
the
items
that
we
are
looking
at
actively,
and
hopefully
there
is
no
one
in
the
sig
network
network
network
which
who
thinks
that
this
is
a
completely
bad
idea
that
we
should
not
move.
E
Yeah
my
interpretation
from
what
ricardo
said
last
week
was:
these
are
just
the
use
cases
that
we,
as
a
group
think
are
the
most
important,
but
also
the
use
cases
that
we
can
add
to
the
existing
networking
kubernetes.
I
o
view
on
networking
api
group,
so
I
agree
with
jay
that
this
is
a
huge
effort,
but,
technically
speaking
it
can
be
a
non-breaking
additional
resource
in
v1,
which
is
why
it
landed
here.
A
Okay,
we
should
just
add,
maybe
an
okay.
We
should
probably
add
a
note
there
that
this
is
different
than
the
other
two
you
know
like
in
sesame
street,
where
they
have
an
apple
and
an
orange,
and
they
say
one
of
these
is
not
like
the
other
right
there's
something
different
here
that
I
think
we
should
express
somehow
other
than.
But
you
know.
A
A
E
Instead,
just
maybe
do
yeah,
you
can
add
large,
like
t-shirt
sizes,
maybe
exactly
yeah.
A
E
Small
small
yeah-
I
don't
know
if
the
name
space
I
don't
know
if
the
namespace
one
is
small,
let's
call
it
medium
only
because
it
it
may
end
up
being
a
larger
conversation
around
how
generic
resources
should
reference
spaces.
So
we
may
have
to
be
pulled
into
that
in
order
to
unblock
us
for
the
namespace.
F
Can
I
remove
this
well
who
added
this
this?
This
was
me
I
was
going
through
this
and
I
just
you
know
I
couldn't
help
but
think
that
if
this
is
the
first
set
of
things
we're
going
to
propose,
we
should
have
fud
and
address
to
never
policy.
F
F
Sure,
I'm
sorry
my
whole
news.
I
thought
this
was.
I
can
write
this
out
too.
I
so
effectively.
Instead
of
writing
ip,
you
know
sliders
or
labels
or
whatever
you
should
just
be
able
to
say.
I
don't
want
my
pasta
to
talk
to
dub,
dub
google.com
or
something
whatever
right,
this
stuff
like
that
and
sure
like
it,
you
know
it.
People
could
do
the
mapping
and
write
the
ip
addresses.
F
But
you
know
the
extra
convenience
is
so
much
nicer
because
they
can
comprehend
that
policy
when
they
read
it,
which
is
which
is
worth
a
lot.
E
Yeah,
like
this
is
kind
of
where,
like
the
border
between
the
network
policy
and
service
mesh,
I
think
kind
of
playing
because
yeah,
like
I
agree
with
jay
like
this,
is
like
network
policy
by
name
is
like
l3,
maybe
l4
right,
dns
is
kind
of
going
into
like
the
whole
stack,
I
think,
which
gets
interesting
because
you're
kind
of
like
exploding
the
scope
of
what
policy
can
do
at
that
point.
A
B
That's
a
nice
user
story.
Cerium
actually
supports
that,
but
in
in
a
layer,
seven
also
basis
like
they
implement
these
with
an
avoid
capturing
stuffs
and
directly
into
like
you.
Can
you
get
you
cannot
to
get?
You
can
go
to
this
to
this
dns
call
to
this
url
or
to
this
dns?
So
I
think
that
the
problem
adding
this
is
not
that
the
field
won't
support
it,
but
how
the
cni's
are
going
to
support
like
they
are.
B
B
So
it's
up
to
like
focus
user
using
vpf
folks,
using
like
something.
F
F
Calico
has
dns
policy
and
they
use
iv
tables.
F
He's
pretty
sure,
but
I
mean
to
be
fair,
like
I
I
do
want
to
like
use
the
last
five
minutes
talking
about
the
actual
policy,
not
the
implementation,
just
to
sort
of
make
sure
that
we
at
least
agree
on
the
premise.
If
that's
that's
it
yeah.
So
it's
your
point,
andrew
about,
like
never
policy
being
you
know,
a
sort
of
a
layer,
three
layer,
four
concept,
but
completely
agree.
I
think,
like
I
think,
of
fqdn
as
sort
of
labels
right
labels
that
also
get
translated
into
ipad
versus.
F
E
Yeah,
that's
a
that's
a
good
point
so,
like
I
guess
the
and
I
guess
we're
going
back
to
implementation
details
but
like
if
I'm
just
thinking
about
like
service.
I
think
that
makes
sense
because
you
can
take
a
s
at
the
fqdn
of
a
service
and
if
you
know
the
you
know
the
cluster
dns,
you
can
derive
the
set
of
pods
that
represent
that.
E
But
then,
but
then,
if
you
go
like
outside
the
cluster-
and
you
just
have
like
generic
fpdm's
like
how
do
you
assign
that
to
pods?
And
does
it
make
sense
for
network
policy
to
try
to
do
that?
I
guess:
is
the.
H
I
think
it's
the
same
thing,
because
you
could
use
an
external
ref
service
right
and
then
label
that
and
then
like
work
your
way
around,
because
at
some
point
there's
an
external
state
of
a
dns
to
ip
mapping
and
then
once
on
the
wire
you
know,
ip
datagrams
will
have
ip.
H
H
I
don't
think
that
we
should
limit
ourselves
just
because
our
current
policy
implementation
tools
talk
more
about
dns
talk
more
about
ips
than
dns
yeah
anyways.
I
think
it's
the
same.
I
guess.
F
And
I'm
happy
to
sort
of
fill
out.
The
you
know
then
put
a
template
around
just
like
the
other
other
policies
here.
If
that's
you
know
if
that
helps,
but
I
just
wanted
to
sort
of
call
out
the
fact
that
this
is
probably
one
of
the
you
know
very
sort
of
popular
asks
of
kubernetes.
E
Yeah,
it's
the
first
time,
I'm
hearing
it
and
I'm
really
curious
about
it.
Now
that
you've
brought
it
up
governed,
do
you
feel
that
we
should
discuss
it
some
more
and
think
about
it
before
and
and
decide
if,
if
they
should
go
into
this
talk,
oh
sure,
yeah
yeah.
F
Yeah
happy
to,
I
think,
do
you
want
me
to
sort
of
put
it
in
the
main
user
story,
doc
that
we
were
all
sort
of
contributing
to
or.
A
D
D
But
I
think
it
is
like
from
the
networking
perspective,
it
is
a
little
challenging
to
implement
it,
but
I
I
do.
I
do
agree
that
this
is
like
a
valid
use
case
like
where
people
don't
want
to
write
iv
blocks
and
would
prefer
them
to
be.
You
know
dynamically
resolved
well
I'll
copy
paste.
The
issue
once
at
home.
Thank
you.
E
B
I
think,
in
my
opinion,
that
that's
the
same
thing
as
the
search
part
we
can
move
forward
and
and
probably
catch
these
in
the
in
the
issue
like
in
the
caps
like
okay,
we
want
to
sh.
We
want
to
change
this,
we
we
can
make
our
first
cycle,
that's
related
to
adding
some
newer
fields,
and
then
we
can
make
another
cycle
that
we
want
to
support
like
ftdns
in
the
from
or
in
the
to
two
rooms.
Also,
I
think
that's
what
one
thing
doesn't
block
other
that's
my
opinion.
E
Yeah,
I
guess
I
was
worried
that
if
we're
sending
this
stock
to
sig
network
and
we're
saying
these
are
the
things
we've
talked
about
and
the
use
cases
we
want
to
tackle
and
we're
going
to
write
caps
for
it,
then
I
don't
want
us
to
like
two
weeks
from
now
add
like
another
use
case
last
minute
and
then
kind
of
like
I
I
want
like.
E
If
we're
doing
like
one
rounds
of
like
reviewing
use
cases,
we
get
that
and
get
the
six
opinion
and
then,
if
we
want
to
add
new
things,
we
create
a
new
dock
and
we
iterate,
maybe
some
of
the
user
stories
from
here-
get
copied
there.
I
don't
know,
maybe
I'm
being
a
bit
a
bit
too
specific
around
around
this
I'll
defer
to
you,
ricardo.
B
D
B
B
I
think
that
adding
dns
themes
ftdn
is
going
to
to
mess
up
a
lot
of
things
and
we
are
probably
going
to
lose
the
the
train
for
like
for
those
additions
that
are
also
going
to
help
like
jay
and
the
others
in
in
other
stuff
that
that
they
are
hacking
in
in
natural
policy
with
with
port
sets
and
names.
So
I
think
we
are.
We
are
trying
to
move
a
lot
of
things.
B
But
I
also
agree
that
in
v2
we
need
to
we
need
to
support
the
idea
also
or
v1.5
okay.
So
I'm
going
to
add
in
this
network
meeting
we
are
out
of
time.
Sorry,
I'm
going
to
add
this
like
a
a
time
window
of
10
minutes.
I
expect
all
of
you
to
help
me
to
explain
all
of
those
cases.
Please
let
me
be
massacred
by
the
other
folks
from
the
city
and
I
think
that's
it
so
I'll
as
they
accept
this.
B
H
I
have
one
more
question:
maybe
you
guys
already
covered
sorry
jay
before
you
close
this
out
this
doc?
Is
this
coming
back?
I
guess
I'm
confused
about
what
happens
with
it
next
like?
Does
it
get
merged
in
to
the
main
repo
or
like.
B
Yeah
yeah,
so
this
dot
is,
is
only
a
a
like
a
summary
of
of
what
we
are
going
to
do,
I'm
going
to
merge
this
into
jay's
ripple,
so
we
don't
lose
the
track
about
this
one,
that's
going
to
be
merged
in
the
unofficial,
but
official
jazz
ripple
and
as
this
and
we
are
going
to
discuss
this
in
the
interstate
as
they
see
accept
the
discussion
and
say:
okay
go
ahead
with
that,
we
are
going
to
open
three
issues.
Three
or
one.
I
don't
know.