►
From YouTube: Network Policy API Bi-Weekly Meeting for 20210322
Description
Network Policy API Bi-Weekly Meeting for 20210322
A
Starting
now
h,
j-
and
this
is
the
sig
network
network
policy-
sub
project-
it's
march,
22nd
2021
everybody
be
nice
to
each
other.
This
is
going
to
be
on
the
internet,
all
right.
So
should
we
start
with
issue
triage?
I
guess
as
usual,
I
don't
know
if
we
have
any
issues,
but
we
can
see.
A
A
Don't
see
anything
here,
this
doesn't
look
policy
related,
so
in
general,
now,
let's
see
if
so,
there's
no
new
network
policy
issues,
let's
see
if
there's
any
old
ones,
that
we're
not
following
up.
A
A
A
B
A
B
A
A
B
A
A
A
C
A
Think,
oh,
I
just
wanted
to
say
hi
to
yang
and
stoickas
who
just
joined
and
really
quick.
Before
you
start,
I
see
there's
a
new
person
asa
wine
here
and
just
in
case
you
wanted
to
introduce
yourself
and
also
hate
of
vinai
as
well.
In
case
you
wanted
to
introduce
yourself
feel
free,
hey
guys.
D
A
Hey
so
all
right,
satish
go
for
it.
D
Hey
so
I
think
the
like
we
remember
we
have.
We
had
this
discussion
about
how
we
are
going
to
like
when
we
think
about
cluster
network
policy
v2
versus
introducing
new
spike
right.
I
mean
the
service
selector
in
general,
run
into
that
issue
where
we
are
trying
to
introduce
a
new
field
and
we
are
going
to
fail
open
right.
D
So
so
I'm
actually
waiting
for
that,
like
I
mean
the
long
term
solution
to
take
place
or
like,
or
we
have
some
consensus
around
that
and
then
based
on
that,
we
like
try
to
see
if
this
proposal
makes
sense
or
like
I
mean,
or
should
it
align
with
that
long-term
goal
of
achieving
network
policy
v2
like
the
net
policy
v1,
but
a
new
spec
yeah.
D
So
I
mean,
if
you
guys,
think
it's
a
a
discussion
that
I
mean
like
the
genetic
policy.
V2
versus
the
service
sector
is
a
different
goals.
In
general
I
mean
then
I
mean
like.
If
those
can
be
tackled
barely
then
we
can
do
that,
but
I'm
just
trying
to
see
if
that
discussion
is
is
on
track
and,
like
I
mean
like
we
actually
thinking
of
anything
in
general
or
that.
D
I
mean
so
I
mean,
if
you
look
at
my
proposal,
I
I
did
avoid
fail,
open
problem
by
introducing
a
new
field
in
the
spec,
but
but
it's
not
ideal
as
what
I
would
say,
but
because
I
mean
I
introduced
a
field
now
for
service
selector,
for
example.
Tomorrow
there's
something
called
node
selector
that
comes
and
we
need
to
introduce
a
new
in
this
spec.
So
that
might
be
a
lot
more
confusing.
D
So
I
think
that
aligns
with
our
our
initial
discussion
about
having
a
new
spec
or
like
network
policy.
We
do,
I
guess,
okay,.
A
C
So
I
I'm
assuming
like
when
we
go
to
v2.
So
if
someone
did
apply
these
constructs
in
v1,
it
would
gracefully
fail
without
there
should
be
some
handling
of
these
right.
I
mean
like,
if
you
still
use
the
v1
controller
for
this,
but
the
crd,
I
think
it
should
not
fail.
A
C
No
meaning
like
let's
say,
let's
say
we
go
to
v2
and
we
add
this
new
construct
that
we're
discussing
right
and
then
someone
accidentally
like
creates
a
crd
using
all
these
new
constructs
and
then
it
turns
out.
The
controller
is
still
using
v1,
so
it
can
still
parse,
but
things
that
it
doesn't
understand
it
should
just
discard
instead
of
like
you
know.
C
Because
I
don't
know
see,
the
thing
is,
if
we
so
again,
this
is
the
stance
that
we
can
take.
I'm
not
clear
about
how
the
rest
of
this
the,
when
we
upgrade
the
versions
for
the
resource,
how
how
the
backward
and
upward
compatibilities
are
handled,
but
I
think
we
should
be
consistent,
but
I'm
thinking
like
is
that
something
that
we
should
stake
out
a
position
on.
I
think
it
would
be
useful.
At
least
we
can
get
a
consensus
amongst
our
group
right.
A
I
don't
really
know
I
mean,
because
we
haven't
really
decided
whether
now
is
the
time
to
start
talking
about
the
v2
thing
yet
so
like
right.
I
think
I
don't
think
there's
any
wrong
answers
there
and
the
question
is:
do
we
want
to
actually
do
the
v2
thing
and
then.
E
C
Yes,
actually
that's
a
good
idea
and
I
think
right
after
satish,
I
have
a
proposal
for
similarly
for
service
accounts
using
service
accounts
to
select
pods,
and
then
I
think
there
are
a
few
other
things
too.
So
we
can
just
combine
all
the
students
together
and
make
it
yeah.
Then
a
couple
more
things.
I.
D
Yeah
there's
also
one
more
proposal
which
is
actually
tangential
to
v2
I
mean
we
can
have
like
ricardo
brought
up
this
new
proposal.
As
such,
like
we
can
have
a
separate
spec,
so
I
mean
like
we
still
use
v1
network
policy.
V1
network
v1
has
spec
there's
one
more.
We
can
add
one
more
field,
saying
something
like
new
spec
or
something,
and
then
new
spec
will
accommodate
the
existing
ones,
but
also
leave
the
space
for
the
the
you
know,
like
the
new
use
cases
that
we
are
actually
trying
to
tackle.
D
So
what
that
means
is
like,
so
the
customers
can
either
choose
to
specify
spec
or
new
spec,
and
the
old
cni
implementers
will
continue
to
use.
Spec
and
new
spec
will
be
good,
but
the
new
controllers
will
try
to
use
new
spec,
and
so
that
will
actually
fail.
Close
is
my
assumption,
because
so,
if
the
old
controller
doesn't
understand
new
spec,
it
doesn't
do
anything
with
it
and
yeah
so
and
the
same
thing
goes
when
a
new
controller.
D
So
I
mean
when
I
say
I
think,
failed
op
and
versus
fail
closed.
It
doesn't
allow
any
additional
traffic
as
such,
but
I
mean
allow
me
to
understand.
Like
I
mean,
if
like,
would
it
make
sense,
or
would
it
be
like
I'm
trying
to
understand
like
in
what
cases
like
I
mean?
If
there
is
a
policy
that
I
mean,
we
will
ignore
certain
part
of
the
spec,
but
we
will
not
allow
traffic
that
the
customer
is
not
trying
to
allow
sort
of
thing.
I
mean
right.
I
think.
C
So
so
satisfy
me
right
if
you
can
get
the
definition,
I
think,
as
jay
was
saying,
if
you
get
the
definition
of
fail,
open
and,
like
you
know,
fail
close
if
you
have
a
clear
definition
of
what
that
is,
that
we
all
agree,
and
I
think
it
will
make
it
useful
fail
open.
I
think
the
way
it
says
I've
used
it
in
the
past
several
years.
It's
been
that
you're,
given
a
configuration
that
the
controller
provides.
It
comes
in
the
networking
world
right
here,
you're
all
doing
network
policy
in
here.
C
So
let's
say
the
bgp
protocol.
That
is
two
daughters,
are
exchanging.
The
protocol
fails.
Okay,
so
what
happens
is
fail?
Open
means
you
do
not
withdraw
that
out.
You
just
keep
them
as
it
is
like
in
the
in
a
typical
sgm
kind
of
environment.
The
controller
fails
loses
connectivity
to
the
switches.
You
don't
delete
the
flows,
you
have
to
remain.
That's
a
failure.
C
Fail
closed
model
is
like.
If
you
fail
something,
then
the
switches
will
say.
Okay,
I
lost
connectivity
to
the
controls
to
the
controller
I'm
going
to
delete
all
the
phones.
I
don't
know
what
the
real
statement,
so
that
is
the
fail
clause
yeah
the
world
clause
using
the
definition.
So
let's
define
what
we're
trying
to
do
here.
A
C
Yeah
either
that
or
we
can
just
say
hey,
there
is
something
the
weird
stuff
that
I
don't
even
know.
Even
that
may
be
safe,
I'm
not
gonna
again.
This
is
a
posture
that
we
can
decide.
We
don't
need
to
decide
now,
but
I
think
it
would
be
good
to
have
a
consistency
across.
I
don't
know
what
the
other
resource
is.
Crds
and
kubernetes
do
okay?
Is
it
like
a
do?
We
have
a
common
policy
for
this
or
is
it
like?
You
know,
every
resource
does
its
own
thing.
A
C
B
B
Exactly
the
user
expects
something
but
like
like
the
problem
is
then:
let's
imagine
that
you,
you
create
a
policy
that
you
select
like
a
bot
and
a
service
okay,
just
just
just
just
that,
and
and
this
is
like
an
end
policy
or
maybe
just
you
select
only
only
a
service
right.
B
So
what
happens
when
you
create
that
body?
So
you
are,
you
are
doing
a
default,
deny
for
everything
else
and
allowing
just
that
bodies
right.
But
when
you
try
to
select
something
that
returns
a
new
or
like
an
empty
view,
you
are
actually
allowing
any
traffic
right
right
because
you
are
so
so
you
are
creating
now
the
folding
eye
and
then
a
default
at
the
follow,
and
this
is
fill
open
problem.
D
Yeah,
but
that
happens
only
if
you
define
the
selector
inside
the
the
current
spec
right,
but
exactly
exactly,
but
so
it
find
a
new
spec,
so
it
will
still
I
mean
so
from
that
perspective
it
won't
allow
any
additional
traffic.
As
such
I
mean
it
will
still
be
default
open
right.
I
mean
if
you
use
new
spec
instead.
E
A
B
B
What
I
wanted
to
do,
jay
was
actually
being
folks
in
sign
network
meeting
list,
but
this
is
going
to
start
like
an
endless
discussion
right.
My
my
my
fears
here
is
that
okay,
I
want
to
create,
I
want
to.
I
want
to
create
a
new
spec
that
doesn't
fail
open
when
every
time
you
want
to
add
a
new
selector.
B
I
don't
want
to
to
to
fail
open
right
because
we've
been
like
we
did,
that
with
port
range,
the
namespace
by
name
it
was
fine,
but
how
can
we
improve
what
if
something
new
rises,
and
we
want
to
to
to
do
that
right,
yeah?
So
my
point
is
the
the
easiest
way
to
do
is
going
to
have
like
the
new
spec,
but
as
we
have
the
new
spec
thing
and
like
copying
everything
and
saying
okay,
new
spec
is
like
a
network
policy,
spec
v2.
Why
don't?
B
A
E
A
B
Yeah,
on
the
first
time,
I
wanted
to
have
a
new
spec,
and
that
was
why
I
suggested
to
satish
that
also
like
satish.
Why
don't
we
have
like
a
spec
v2
and
that's
all,
but
then
I
I
have
started
to
figure
out
that
the
effort
that
we
are
having
we
are
going
to
have
this
on
on,
like
having
a
spec
v2,
probably
is
not
worth
than
creating
a
whole
v2
object
right,
jay.
A
E
You
bring
to
them
is
like:
can
we
make
a
v2
and
they're
gonna,
ask
like?
Is
the
v2
gonna
encompass
all
the
features
of
v1
plus
the
new
features
we
want
and
like
is
our
goal
in
the
long
run
for
every
user
of
kubernetes
to
move
to
v2,
or
is
it
like,
okay,
you're
only
moving
into
v2?
If
you
want
these
new
features
like
what's
gonna
happen,
are
we
gonna
deprecate
v1,
I
mean
there's
so
many
other,
but
those.
What
I'm
saying
is
those
all
those
questions
apply
with
a
new
spec.
B
What
I
think
it's
it's
good
to
to
to
do,
jay
now
that
we
are
like
in
a
in
a
smaller
group.
Is
that
because,
when
we
started
to
to
discuss
about
the
v2
thing,
we
got
a
lot
of
ideas,
but
a
lot
of
them
were
just
like.
Okay,
I
want
to
separate
like
networking
between
processes,
and
I
think
that
we
are
mature
enough
now
to
know
what
we
want
to
do
in
v2
and
what
we
we
don't
want
to
touch
right.
So
mostly
our
problems.
A
E
B
I
guess
we
can.
I
guess
we.
We
have
like
a
good
scope
here.
I
don't
know
if,
like
the
other
a
here
I'll
agree
with
that,
but
I
guess
we
have
like
a
good
scope
here
that
we
want
to.
We
want
to
extend
all
the
all
the
selectors
with
all
without
like
having
a
fail
open
and
that
that
we
we
want
to
specify
the
actions
instead
of
only
doing
like
an
a
defy
deny
or
a
default
law
right.
B
So
I
guess
we
can
like
move
right
in
between
us,
like
a
v2
spec
that
that
can
that
can
deal
with
with
the
needs
from
vinai
and
google
and
the
needs
that
that
you
have
at
vmware
and
like
the
needs
that
andrew
had
at
red
hat
and
with
the
scope
that
we
know
that
we
are
following
right.
That
is,
have
something
a
lot
compliant
with
v1,
but
like
easier
to
use
or
easier
to
extend.
We.
B
D
So
one
question
I
was
like
is
like:
are
we
going
to
make
it
backward
compatible?
D
So
that's
the
question
that,
like
everyone
will
ask
it
I
mean
so,
is
it
going
to
be
breaking
change,
so
in
that
sense
we
can
make
certain
decisions
to
have
like
different
selectors
and
the
way
we
do
implicit
isolation
and
things
like
that.
We
can
improve
there,
but
it
depends
whether
we
are
actually
making
it
backward
compatible
or
not.
E
I
mean
what,
if,
in
in
v2,
we
kind
of
combined
both
ideas,
we
could
have
like
a
legacy
spec
in
v2
legacy,
spec
and
then
like
new
spec,
so
that
everyone
can
still
use
the
exact
same
policies
they
use
with
v1
they
work.
But
then
you
also
have
the
ability
to
use
the
new
stuff,
or
that
might
just
be
too
complicated.
You.
A
B
B
E
B
F
Yeah,
I
would
say
I
was
just
trying
to
provide
some
data
point
here,
because
I
work
on
the
intra
and
for
the
intranative
policies.
We
also
have
different
versions
which
are
not
compatible
backward
compatible.
So
what
we
do
is,
as
ricardo
suggested,
we
provide
api
machinery
with.
F
You
know
what
what's
the
what's,
the
version
we're
storing
and
using
primary
when
we
start
a
pantry
and
then,
if
user
actually
specify
a
version,
that's
you
know
v1
instead
of
v2,
then
internally
in
the
in
the
api
machinery
would
provide
a
conversion
function
for
the
old
spec
to
be
convert
converted
to
a
new
spec
internally
by
the
controller
and
then
that
converted
policy
gets
gets
enforced.
This
is
how
I
think
entry
handles
those
kind
of
situations.
D
Yeah
yeah.
Sorry!
So,
hang
a
follow-up
question,
so
the
conversion
function
is
is
inserted
by
the
anterior
controller.
Is
that
correct.
F
I
I
don't
know
what
you
mean
by
inserted,
but
I
think
in
the
network
policy
case.
I
think
the
conversion
function
should
be
a
part
of
the
v1
package.
For
example,
if
we
wanted
to
move
to
v2.
D
I
see
oh,
what
do
you
mean
by
different
packages.
F
So
so
in
the
in
the
v1
network
policy,
like
networking,
dot,
v1
package
right,
you,
you
will
have
the
the
specs,
the
crd
definitions
for
the
current
network
policy,
for
example.
And
then,
if
we
want
to
move
to
v2,
then
in
the
same
package
we
will
have
a
conversion
function.
F
Ideally
that
converts
the
old
v1s
back
to
the
new
v2
spec,
because
it
it
shouldn't
involve
any
sort
of
like
controller
intervention
right,
because
you
should
be
able
to
look
at
the
the
odyamo
in
v1
and
then
you
know,
convert
every
field
to
the
to
the
v2
spec.
Essentially,
so
it's
like
a
literal
conversion
and
that
function
should
be
sort
of
like
provided
in
the
v1
package.
D
Yeah
is
it
through?
Is
it
through
the
the
custom,
the
crd
definition
itself
or
through
the.
D
Do
you
provide
the
the
conversion
function
in
the
package?
Is
it
is
it
through
the
the
crd
definition
itself
that
we
registered
with
the
aps
network
or.
F
There
there's
always
a
conversion.gold
file
in
the
in
the
package.
If
I
remember
correctly,.
F
Yeah
yeah
right.
If
you
look
at
the
example,
this
will
be
yes
exactly
so
so
there's
there's
gotten
to
be
this
conversion.gold
file,
where
you
can
write
conversion
functions
from
v1,
alpha,
1
or
beta1
resources
to
beta2
resources.
B
Yeah,
so
so
this
happens.
Actually
this
happens
in
the
api
machinery
when
the
I
don't
know,
if
that
that's
during
the
persistence
or
when
the
object
is,
is
shown
to
the
to
to
the
one
that
requests
that
right.
So
when
you
request
the
the
so
probably
seem
hawking
jordan
legit,
they
know
better,
but
when
you
do
a
get
into
the
that
object,
that
object
is
provided
with
with
the
right
fields
in
in
in
in
the
right
place
as
compatible
to
to
the
v1
theme.
B
So
when
we
start
thinking
about
the
video
we
need
to
do
something.
That's
not.
How
can
I
say
that
that
doesn't
break
a
lot
of
things,
otherwise
the
conversion
is
going
to
be
hard
right,
yeah,
but
I
I
guess
we
should
probably
try
doing
that
and
and
and
saying.
Okay,
we
can.
We
can
specify
everything
here.
B
Those
are
all
the
fields
that
that
we
want
to
have
this
here,
because
I
I
think
that
major
problem
here
is
not
going
to
be
only
the
conversion,
but
the
cni
is
understanding
this
v2
right
so
like
andrea
and
calico
and
celium
and
openshift.
That's
the
end.
They
knowing
how
to
consume
this
v2
network
policy,
otherwise
they
are
trying
they
are
going
to
like
consume
the
v1
always
and
how
can
like
a
user
say?
Okay,
andrea,
go,
go
and
use
the
v2
network
policy.
B
F
Yeah
and
and
the
other
other
question
regarding
the
fail
open
thing
is,
I
think
you
know
if
we
actually
move
to
a
v2
spec
in
some.
In
some
cases
there
is
just
no
way
you
can
convert
the
v2
spec
to
v1,
for
example,
for
for
service
lecture,
for
example
right.
So
any
pause
and
stuff
like
that
that
service
resolved
to
will
be
will
be
computed
in
runtime
by
the
controller.
F
So
it's
impossible
for
you
to
look
at
the
v2
spec,
which
has
service
selector
and
convert
it
back
to
v1,
because
you
know
the
the
depending
on
how
what
what
are
the
positive
runtime
for
the
service?
It
is
sort
of
like
converts
to
different
things
you
know
for,
for
we
want.
So
there
are
some
new
stuff
that
we
add
in
v2
that
are,
there
are
simply
unconvertible
to
v1.
If
that's
the
case.
E
C
C
E
F
Yeah
yeah,
exactly,
I
think
my
point
is
definitely
v2
needs
to
capture
everything
like
in
v1,
but
if
you
look
at
the
conversion
functions
right,
so
in
most
cases
they
have
little
two-way
conversions.
That's
where
you
know
things
gets
tricky
because
in
the
conversion
functions
you
usually
have
to
provide
it
with.
You
know
how
v1
is
going
to
convert
to
v2
and
v2
is
going
to
convert
back
and
in
in
that
case
you
know,
some
of
the
things
in
v2
might
just
have
to
be
dropped.
D
So
I
think
one
of
the
yeah-
I
think
I
understand
young's
concern
here
better,
so
I
think
so
like
if
you
have
the
kubernetes
version
122
that
supports
v2,
but
then
calico
is
still
using
client
api
from
118.
D
So
it
will.
I
mean
kubernetes
api
server
like
when
it
reads
from
humidity's
api
server.
It
will
convert
back
to
v1
and
latency
object,
so
we
need
the
conversion
logic
from
v2.
F
E
D
Yeah,
but
I
think,
like
some
of
those
cases
will
be
fail
open.
I
guess
I
mean,
for
example,
you
have
if
you
have
a
service
selector,
that
selects
a
service
and
allows
all
the
traffic
I
mean,
there's
no
way
to
convert
it
back,
so
I
mean
so
in
that
case,
do
we
see
a
v1
network
policy
that
selects
all
the
parts
or
like
I
mean
it,
depends
on
the
conventional
logic
that
we
are
doing
there.
E
B
A
A
The
question
is:
are
we
going
to
do
it
and,
if
so,
who
wants
to
lead
it?
Who
wants
to
own
network
who
wants
to
be
who
wants?
Who
wants
to
be
that
spectacular,
superstar
that
brought
the
next
genera
generation
of
network
policies
to
the
cncf?
Is
it
going
to
be
you
andrew
stoicas?
Is
it
going
to
be
vinai?
Is
it
going
to
be
satish?
Is
it
going
to
be
ganging.
C
I
think
it
should
be
collective
if
we
agree
it's
a
consensus
right.
This
is
like
a
network
policy
working
group.
We
all
sit
down
and
we
present
it.
Not
it's
not
an
individual's.
It
is
a
group
consensus.
That's
the
reason,
you're
hashing
it
out,
so
I
would
say
we
go
collectively
as
a
group
and
then
we
say
we
present
it
and
I
think
so,
if
you
don't,
if
you
don't
have
a
consensus
in
our
group,
I
don't
think
we
should
go
and
present
it.
C
I
agree
now
what
I
meant
there
could
always
be
a
spokesperson.
You
could
ricardo
or
you
one
of
them
could
be
spokesperson,
but
what
I'm
saying
is
like
they're
speaking
on
behalf
of
the
the
group,
and
I
think
now
completely
agree
with
you,
so
we
I
think
we
we
are
not
too
far
off.
I
think
we
can
just
need
to
agree-
and
we
say,
support
each
other
and
say
like
this
is
how
we
think
like,
for
example,
the
master
network
policy
that
clp
abhijit,
and
you
know
young
myself
and
satan.
C
A
Yes,
let's
change
the
word
from
superstar
hero,
whatever
I
said
to
spokesperson
whatever
you
want
to
call
it.
Who
wants
to
be
that?
Because
that's
the
thing
that
the
person
who's
going
to
drive
this
and
really
be
the
person?
That's
out
there
who's
going
to
do
that
because
we've
been
so
many
people
are
so
saturated
and
we've
been
doing
this
for
a
year,
and
I
want
to
make
sure
that
somebody
really
wants
to
drive
this
forward.
That's
right.
B
A
Yeah,
okay,
and-
and
neither
can
I
I
and
the
reason
I
can't
is
because
one
I
want
to
see
the
community
grow
like
sort
of
horizontally
and
then
two
I
feel
like
for
me,
there's
some
coupe
proxy
stuff
that
I'm
gonna
be
taking
on
and
ricardo's
going
to
be
helping
with
that
to
improve
the
service
selection.
So
that's
kind
of
what
I'm
thinking,
I'm
not
saying
I
can't
ever
do
it.
I
just
feel
like
in
the
next
two
months.
C
A
So,
let's,
let's
make
this
the
focus
of
this
group
from
now
on
is
this
work.
Time
worked
for
you
tonight
on
mondays,
yeah,
one
to
two
years
books
from
yes,
cool
and
and
I'll
help
too
for
sure,
I'm,
I'm
totally.
I'm
totally
invested
in
this
man
for
sure,
but
it's
man.
I
really
appreciate
this.
A
This
is
great
because
I
I
just
love
to
see
the
fact
that
you
know
you're
stepping
up
to
do
this
very,
very
ambitious
thing
and
we're
gonna,
like
you
said,
fully
support
you
along
the
way,
so
you're
not
doing
it
by
yourself.
C
Sure
you
just
well
satish
is
also
going
to
be.
I
think,
since
I
think
you
should
also
like
you
know,
jump
in
and
then
we
should
all
do
it.
Yeah
yeah
sure.
E
B
B
A
A
C
So
I
so
do
we
have,
can
we
agree,
and
so
I
need
to
teach,
and
I
need
to
figure
out
how
so
I
need
to
start
planning
things
around
how
much
time
I
can
allocate
at
the
moment.
So
what
I
can
do
is,
if
you
give
me
like
one
or
two
days,
to
teach
and
I'll
sync
up
and
see
how
much,
based
on
that
we
can
come
back
and
do
some
follow-ups.
A
All
right
so
yeah
cool.
So
why
don't
you
just
reach
out
to
me
or
ricardo
this
week?
One
of
us
will
jump
on
the
zoom
with
you
and
we
will
just
sit
there
and
we'll
get
you
into
the
right
channels
and
do
it
all
together
so
that
you're
dialed
into
the
same
stuff
that
we
are
that,
maybe
is
the
simplest
way
to
start
right
and
then
we
can.
If
we
want
to
have
a
brainstorm
session
later,
we
can
have
that
at
a
different
time.
Right.
C
A
Cool
okay:
this
is
cool,
so
we've
got
so
satish.
This
has
been
a
long
road
for
you
and
why
and
you
started-
I
just
want
to
give
you
a
shout
out
because
I
you
know
you
started
and
you
worked
on
the
service
policies
and
we
knew
it
was
not
going
to
be
easy
and
you
did
a
really
good
job
on
the
proposal.
A
And
then
you
got
us
to
the
point
now
that
not
only
do
you
have
a
proposal
for
service
policies,
but
you
also
now
have
given
us
the
ammunition
that
we
need
to
go
to
sig
network
and
say
we
want
a
new
api
and
for
one
year
we
have
not
had
enough
data
to
make
that
case,
and
now
we
have
that.
So
this
is.
I
hope
that
you
consider
this
a
a
a
significant
accomplishment
as
much
as.
C
If
this
is
the
path
that
we're
going
to
do,
I
think
it
may
be
a
good
opportunity
to
also
pause
and
see
if
there's
anything
else,
that
we
can
scoop
up
and
put
it
in
the
v2
like,
and
I
think
these
are
like
these
are
just
selectors-
that
you're
looking
at
the
miner,
but
if
there's
any
larger
issues
that
I
think
we
should
also
that
are
worth
looking
at
again,
I
think
we
can
spend
so
I
can
spend
some
time
and
if
somebody
else
has
some
ideas,
let
me
know
you
can
roll
it
up
in
this
proposal.
A
You
know
I
have
my
same
stupid
idea
that
I
all
proposed,
which
is,
we
could
do
a
service
network
policy
operator
that
took
a
services,
input,
introspected
the
label
targets
and
then
made
v1
policies
from
it,
and
I
think
that
would
be
a
really
cool,
little
side
project
like
the
like
the
one
we
demoed
two
weeks
ago
or
last
week,
but
I
think
it's
orthogonal,
but
I
think
it
could
be
kind
of
a
cool
standalone
utility,
basically
a
v1
service,
selector
controller
right
other
than
that.
E
Yeah
I
mean,
I
think,
that's
like
a
super
important
part,
though,
is
trying
to
really
really
brainstorm
on.
What
are
we
trying
to
incorporate
totality
wise,
instead
of
you
know,
give
like
to
give
that,
like
two
weeks
before,
we
even
start
thinking
about
a
spec
or
a
new
definition,
because
if
we
miss
stuff,
it's
not
like
we're
going
to
be
doing
this
again
for
another
two
years,
so
yeah.
A
A
We
have
this
network
policy
subproject
where
we
put
the
url
in
here
where
we
went
and
we
we
went
and
we
got
user
feedback.
I
don't
know
if
satish-
and
I
I
don't
know
if
you
all
were
around
at
this
time
when
we
were
doing
this
yeah.
A
So
we
we
created
this
and
then
we
we
went
through
the
mailing
list
and
we
went
through
every
comment
that
anybody
has
ever
made
asking
for
new
things
coming
up
with
ideas
and
thoughts
and
stuff
just
and
so
I
feel
like
this
is
kind
of
a
really
for
what
what
andrew
is
talking
about
in
terms
of,
let's
make
sure
we
have
a
holistic
approach
to
this.
I
think
this
history
file
might
be
a
really
really
good
start,
because
it
basically
goes
over
every
crazy
idea
that
anybody's
ever
had
right
can.
A
Yeah
and
then
also
we
also
have
some
quantified.
A
We
have
some
quantitative
results
here,
because
we
have
the
zeros
this
this,
where
we
have,
I
think
we
had
votes,
so
you
can
look
in
here
and
see
like
things
that
people
actually
voted
for
and
said.
I
really
want
this
or
I
don't
want
this
or
whatever.
A
A
A
Need
another
one
yeah
yeah,
so
yeah
don't
feel
the
pressure
to
read
through
the
whole
thing,
but
mike
just
glancing
through
the
history.
Looking
at
things
like
l7
and
service
selector
might
give
you
some
some
good
sound
bites
for,
as
you
put
the
proposal
together,
cool
so
yeah
reach
out
to
us
this
week.
A
C
C
A
C
A
A
I
will
make
a
little
advertisement
for
me
and
ricardo
finally
decided
that
we
need
to
do
the
same
thing
for
network
policies
for
coupe
proxy,
because
there's
a
lot
of
problems
with
nobody
has
really
unified
and
put
brought
into
a
public
channel
the
dialogue
around
how
we're
going
to
move
out
of
tree
there's
been
a
lot
of
back
channel
discussion.
A
There's
been
a
lot
of
single
person
projects,
and
so
we
decided
we're
going
to
open
that
up
and
try
to
start
an
informal
group
to
start
working
on
that
and
it's
going
to
be
thursdays
at
what
4
30
est
to
start
for
just
a
half
hour
or
maybe
longer.
So
if
anybody
wants
to
join
that
just
reach
out
to
me
on
the
sig
network,
slack
or
dm
me
or
ricardo
and
we'll
send
you
an
invite.
We
also
put
a
we're
also
putting
that
on
the
google
group's
mailing
list
for
city.
B
B
B
I
think
team
team
and
some
other
someone
else
did
say
that
it
wasn't
a
good
time
for
them.
But
michael
who
is
the
proposer
from
the
cat
v2
said
that
the
the
pro
that
could
proceed
to
that
that
one
with
xds
grpc
he
said
that
he
is
going
to
attend
us.
So
it's
good
because
he
he
already
has
something
in
mind
also
as
well.
A
Yo
but
tim
said
thursday
is
the
worst
possible
day
of
the
week
for
me.
Well
because
it's
tim,
let's
stay,
let's
sync
up
after
this
ricardo
and
think
and
talk
more
about
it,
yeah,
so,
okay,
cool
I'll
ping,
you
on
on
on
zoom
or
slack,
and
if
anybody
else
wants
to
talk
about
this
feel
free
to
reach
out
to
me
with
cardo.