►
From YouTube: SIG Network Policy API Bi-Weekly Meeting for 20220328
Description
SIG Network Policy API Bi-Weekly Meeting for 20220328
A
Okay,
hello.
Everyone
today
is
march
28
2022.
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup
to
sig
network.
This
is
a
cncf
certified
meeting,
so
let's
all
be
nice
to
each
other
and
have
a
productive
day
as
I
share
before.
Starting
the
recording.
The
agenda
is
pretty
light.
Most
folks
are
dealing
with
kubernetes
code
freeze
this
week,
so
priorities
are
elsewhere,
but
we
would
like
to
get
started.
I
guess
we
can
go
ahead
with
you
laura.
A
B
B
One
potential
proposal
is
a
working
group
about
multi-cluster
networking
in
particular
for
as
long
as
these
shared
projects
are
in
flight,
but
we
also
can
just
continue
as
we
are,
or
just
all
you
know,
more
informally,
negotiate
where
we
hang
out
with
each
other,
don't
want
to
unnecessarily
add
extra
meetings
on
people,
but
also
don't
want
people
to
feel
like
they
need
to
go
to
ten
different
meetings
to
get
the
brain
share
of
everybody
that
they
need
for
their
proposals
so
anyways.
That
was
it.
B
A
A
I
do
kind
of
think
it
would
be
nice
to
maybe
not
even
have
a
new,
sig
or
anything,
but
maybe
have
representatives
from
both
groups
agree
to
start
going
to
sig
multi
cluster
to
have
those
discussions.
So
then
we
have
everyone
there.
There.
It
hasn't
been
a
lot
of
correlation
between
the
multi-network
sig.
I
guess
we
can
call
it.
I
don't
think
they're
a
sig,
but
it's
just.
A
I
I
totally
agree,
I
think
we
need
all
the
brains
together
there
to
kind
of
correlate
for
for
multi-cluster
multi-network
we're
not
gonna,
be
able
to
do
it.
Trying
to
like
relay
information
between
the
meetings.
I
think
the
easiest
way
to
do
that
would
just
be
to
go
to
all
go
to
sig
multi-cluster,
because
we're
kind
of
you're
kind
of
in
the
middle
of
it
all.
I
don't
know
what
other
folks
think.
C
A
B
A
B
Yeah,
I
would
say
we're
not
even
to
that
point
and
really
the
the
symptoms
that
I'm
seeing
is
that
people
need
to
run
around
to
to
get
different
people
or
there's
not
kind
of
one
place
where
we
triage,
like
this
proposal
hasn't
gotten.
You
know
comments
since
x
time
like
can
we
move
it
along?
So
it's
more
that
everything's
really
early
stage,
and
we
don't
have
a
I.
B
A
Yeah
I'd
say
from
our
experience.
The
best
thing
to
do
is
start
documenting
early,
so
that
people
that
hop
in
at
different
steps
of
the
way
you
can
point
them
back
just
to
catch
up.
So
I
don't
rehash
stuff
a
lot.
I'd
say
too
a
good
place
to
get
started,
and
it's
actually
really
good
right
now,
because
we're
still
in
review
is
to
read
the
the
admin
network
policy
api
pr
just
because
there
might
be.
I
know
like
last
time
we
had
met
the
discussion
was
around.
A
Do
we
make
a
new
api
for
multi-cluster
use
cases,
or
do
we
try
to
repurpose?
Maybe
this
new
one,
that's
coming
in.
Add
a
network
policy
more
like
a
cluster
scope
policy
object
and
have
implementations
of
the
ncst
api
adapt
the
use
of
that
for
for
multi
multi-cluster
scenarios,
so
that
might
be
a
good
place
to
have
eyes
from
sig
multi-cluster
people
just
like
a
good
entry.
But
overall,
I
think
meeting
all
together
in.
D
A
B
B
A
Yeah
and
sanjeev,
I
think
it
has
the
most
documentation
around.
What's
already
been
done,
yeah
yeah
and
I
think
what
would
be
really
great
is
for
us
to
come
together
and
just
agree
on
on
use
cases.
That's
that's
where
this
is
all
going
to
start
like.
Can
we
as
three
groups
kind
of
say?
Okay,
these
this
set
of
use
cases
like
truly
makes
sense,
and
then
we
can
move
from
there
right
as
to
where
those
are
persisted.
A
B
Okay
cool,
then
I
think
in
conclusion,
it
sounds
like
the
multi-cluster
network
policy
proposal
has
mostly
actually
been
discussed
in
sig,
multi
cluster
and
maybe
in
cig
network.
More
than
here
I
don't
know,
I
don't
know
exactly
all
the
history
but
anyways
that
that
probably
sig
multicluster
is
a
place
to
try
and
consolidate
the
like
triaging
and
discussion
about
those
and
other
related
multi-cluster
proposals,
at
least
for
now,
and
did
I
miss
anything
else?.
A
A
C
I
took
a
path-
I
I
didn't
really
put
anything
onto
it
because
from
the
the
the
api
said,
I
feel
like
it's
solid
because
we
basically
just
used
whatever
is
in
the
cap
right
now,
so
we
we've
been
going
through
the
discussions
a
couple
of
times
now
and
I
I
do
remember
that
one
of
the
things
that
might
still
be
contending
would
be
the
priority
zero,
because
I
vaguely
remember,
we
talked
about
sending
out
a
survey
to
see
how
people
think,
but
did
that
actually
never
happen.
So.
C
B
A
C
Right
so
so
I
would
guess
that
maybe
we
probably
needed
to
present
the
debate
on
the
pr
itself
so
that
anybody,
for
example,
you
know
casey-
had
a
random
review
right.
So
at
least
when
he's
you
know
reviewing
it,
we
see
this
still
going
on
and
maybe
we
can
get
this
conversation
started
there.
If
people
have
any
other
ideas
about
power
d0,
otherwise
it
will
be
as
it
is,
and
I
I'm
totally
fine
with
it.
But
I
remember
other
people
having
you
know,
troubles
with
having
zero
being
baseline.
So.
A
They
haven't
been
really
represented
here
in
general
comment
on
the
pr
after
the
kept
emerged
saying
he
was
not
comfortable
with
overloading
the
priority
okay
variable,
so
that
was
another
check
mark
against
it.
So,
just
for
folks
who
are
just
who
are
tuning
in,
let
me
rewind
a
little
bit
in
the
cap.
A
More
can
be
read
on
that
in
the
cap,
but
yeah
I'm
happy
to
start
that
discussion.
Those
two
unresolved
items
still
haven't
really
been
addressed
on
the
api.
Pr,
the
next
one
that
I've
been
thinking
a
lot
about-
and
some
folks
have
reached
out
to
me-
is
the
question
of
you-
know
north
south
traffic
right.
That's
still
the
overarching.
A
E
A
D
E
A
A
E
Right
but
but,
and
if
you
want
to
like
completely
flip
the
underlying
model,
then
you
only
need
one
rule
but
like.
Even
if
somebody
you
know,
has
a
more
complicated
thing
where
they
want
certain
kinds
of
traffic
to
be
allowed
and
certain
kinds
to
be
denied,
and
that
might
be
most
easily
expressed
as
multiple
policies.
C
So
that's
why
we
felt,
like
you
know,
for
the
baseline
in
my
for
99
of
these
common
use
cases,
people
might
get
away.
Just
writing
a
single
policy
using
simple
single
priority
with
you
know,
specific
rules.
So
that's
where
we
work
on
with
this,
but
you
know
we
definitely.
Somebody
can
come
up
with
a
specific
case
where
you
have
to
have
multiple
policies
and
yes,
that's
a
sort
of
like
a
rupaul
in
the
in
a
design
right
now.
Ralph.
Will
you
want
to
say
something?
Sorry
I'll
move
myself.
D
Oh
yeah
no
worries.
It
was
just
a
minor
point,
one
of
the
things
that
we
talked
about
even
like
in
the
regular
admin
network
policy
thing
was
we
had
some
like.
You
know
hypothetical
concerns
about
the
fact
that
we're
creating
this
priority
list,
which
basically
forces
us
to
do
a
a
linear
evaluation.
D
Right
of
like
you,
have
to
look
at
priority
one
before
you
look
at
two
before
you
look
at
three
I'd
be
a
little
bit
concerned
if
we
essentially
doubled
the
size
of
the
the
potential
search
space
by
adding
you
know
another
thousand
priorities
below
network
policy.
That
would
be
a
little
bit
concerning.
I
I
don't
know
if
we
need
to
run
benchmarks
or
you
know-
have
sample
implementation.
C
E
E
So
and
he's
talking
about
his
experience
with
calico
network
policy,
which
only
has
more
network
policy
like
selectors
and
doesn't
have
the
same
labels
and
different
labels
and
all
that
stuff.
So
it
might
be
worthwhile
to
get
him
to
give
examples
of
things
where
people
have
needed
multiple
levels
of
priority
in
calico
network
policy
and
see
if
those
things
can
be
implemented
without
multiple
priority
levels
in
admit,
network
policy.
E
A
I'll
reach
out
to
him
on
the
cap-
and
you
know
I
I
brought
this
up
just
so
we
could
could
look
at
it.
This
is
kind
of
what
we're
talking
about
for
folks
who
are
less
than
familiar
like
this
is
an
easy
way
for
us
to
say
we're
going
to
flip
the
baseline
stance
of
everything
in
the
cluster
to
deny
but
dan
saying.
Oh
what
if
we
only
wanted
to
flip
the
baseline
stance
of
a
few
name,
spaces
right
that
becomes
harder
here,
oh
well,
it
becomes
a
tricky
unless.
A
Right
well,
then,
you
could
just
have
different,
multiple
ingresses,
but
yeah
right.
The
main
problem
is
you're,
limited
by
a
single
subject
of
an
admin
network
policy,
and
originally
we
had
multiple
subjects.
We
did
remove
that
because
we
decided
it
didn't,
have
enough
of
a
value
add
at
the
end
of
the
day,.
C
But
yeah
adding
adding
a
data
point
here
we
actually
when
we're
hashing
out,
you
know
sample
specs
for
andrea
quota
called
cluster
network
policies,
which
is
not
exactly
administered
policies
and
we
were
hashing
now.
You
know
the
examples
backs
for
these
policies
and
one
of
the
really
common
use
cases
you
know
for
the
baseline
deny.
C
So
there
are
some,
you
know
funny
things
we
can
do
to
a
lot
of
the
selectors
here
to
make
the
policy
work
as
intended,
but
it
not
it
might
not
be
just
as
straightforward
as
you're
having
multiple
rules
stack
on
top
of
each
other.
So
we're
essentially
sort
of
advocating
pico
people
to
write
a
policy
in
certain
way
so
that
it
will
be,
you
know
more
easier
on
the
priority
side,
I
guess.
A
And
and
in
practice
I
think
most
cni's
advocate
for
customers
to
write
policy
in
a
certain
way,
but
for
some
reason
we
don't
really
do
that
upstream,
we
don't
tell
users,
they
should
use
it
like
this,
even
though
I
think
with
this
one,
I'd
like
to
have
documentation
that
recommends
suggested
use
pattern,
because
most
people's
use
patterns
are
the
same
and
that
might
be
kind
of
a
solution
to
this
problem
right,
not
not
these
solutions
anyway.
I
I
think
there
are
some
good
point
really
good
points
here.
A
I
try
to
take
a
few
notes
on
the
agenda.
I
would
like
to
like
continue
this
thought
on
the
kep
itself,
so
we
can
kind
of
hash
it
out
there.
I
think
there
was
a
couple
of
good
options
thrown
out
and
it
doesn't
have
to
be
one
or
the
other.
Maybe
we
just
we
stop
overloading
priority
and
we
give
a
limited
range
for
for
baseline
rules.
We
don't
give
zero
priority
zero
to
a
thousand.
We
only
give
zero
to
ten
and
maybe
that'll
be
plenty.
A
D
A
Lists
which
I
well,
I
think
most
of
us
can
agree
with
right
now.
It's
calculated
as
the
total
summation
of
admin,
network,
quality,
ingress
rules
and
egress
rules
in
a
single
amp
instance.
So
if
we
had
it
would
be
the
same
for
baseline
policies,
I
would
assume,
but
you
aren't
really
going
to
max
out
a
baseline
policy.
I
don't
think
this
is
a
smaller
unresolved
item
overall.
E
A
A
E
A
A
Yeah
so
right
now,
priority
is
bound
zero
to
a
thousand,
and
then
we
we
still
in
here
we
have
ingress
negatives
rules,
just
like
network
policy
and
and
the
summation
of
the
two
cannot
exceed
a
hundred.
That's
that's
what
we
have
right
now,
that's
unresolved
on
the
cap,
happy
to
change
it
around
based
on
review.
I
I'm
less
worried
about
that
one
than
yeah.
I
have
no
real
opinion
about
that.
Either.
A
Verif
to
validate
this-
and
I
don't
think,
there's
a
way
to
validate
like
the
total
summation
of
ingress
and
egress
using
the
open
api
spec.
That
would
be
the
one
thing
to
think
about,
or
you
just
say
you
can
only
have
50
ingress,
50
egress
and
then
it's
easy
to
do
schema
validation,
but
yeah
are
there
any
other
opinions
there.
D
A
D
Yeah
I
mean
I,
I
think
it
only
gets
harder
the
deeper
retarder
nest,
but
for
validation's
sake
anyway,
yeah
yeah.
No,
I
mean
this
makes
sense.
I
just
I
guess
in
if
we
in
an
ideal
world,
it
feels
like
we'd,
really
want
to
limit
the
number
of
peers,
because
that's
probably
that's
the
real
scaling
factor
at
the
end
of
the
day,
but
yeah.
A
A
The
last
thing
I
want
to
talk
about-
which
I
think
is
the
most
important-
is
kind
of
a
two
thing
sort
of
thing
right
now:
admin
network
policy
for
those
of
you
who
have
been
along
the
whole
ride,
does
not
reference
north-south
traffic.
It
is
written
to
address
certain
use
cases
that
only
touch
in-cluster,
east-west
traffic.
So
what
some
people
see
as
a
big
negative
to
the
api?
Is
you
can't
technically
isolate
a
pod
from
the
entire
world
right?
A
E
Like
I've
been
involved
in
various
customer
calls
and
like
pm,
meetings
and
stuff
lately,
where
things
keep
coming
up,
it's
like
oh
yeah
admin.
Network
policy
is
totally
what
this
customer
needs
like.
It
will
solve
all
their
problems,
except
inevitably
they
care
about
blocking
egress
traffic.
It's
not
even
ingress,
usually.
C
But
what
does
that
mean
for
the
the
not
sell
or
not
same
labels,
because
does
that
mean
that
everything,
except
these
name
spaces
or
everything
in
the
cluster,
except
these
name
spaces?
And
if
we
mean
the
latter,
how
would
the
cni
essentially
differentiate
it?
Basically
and
that's
still
a
problem?
I
I
I
guess
at
the
end
of
the
day
on
the
spread
people
we're
just
saying
that
you
know,
let's
let
cnx
decide
what
to
implement
basically
for
them
for
the
first
pass
and
then
see
how
it
goes.
I
I
remember
that
being
the
conclusion
there.
A
D
A
As
it's
allowed,
I
mean
north-south
traffic
is
not
selected
period
and
that's
the
hard
line
right
now,
so
it
is
defined.
I
mean
okay,
the
the
question
I
have
is:
if
we
go
with
as
it's
defined
in
this
api,
how
much
of
an
absolute
nightmare
I
mean
we're,
building
the
api
to
be
more
extensible,
specifically
with
how
we
are
defining
how
you
select
workloads.
This
is
a
good
example.
A
We
fail
close
like
we
define
namespace
set
as
a
way
to
select
name
spaces,
but
if
a
consumer
sees
the
nothing
set,
it's
specified
that
something's
unknown.
We
need
to
fail
close,
so
so
from
that
perspective,
it'd
be
easy
for
us
to
add
a
new
selector
from
a
from
a
user
perspective.
I
I
also
have
been
kind
of
having
nightmares
about
what
dan
just
said,
thinking
that
every
customer
in
reality
is
going
to
want
to
address
north
south
traffic.
E
Know
so
the
the
big
problem,
I
think
that
that
resulted
in
it
getting
removed
is
that
if
you
just
add
an
ip
block
selector,
there
are
all
these
weird
edge
cases
that
that
network
policy
currently
has
that
are
terrible.
Right
and
again,
ingress
is
worse
than
egress
for
this.
So
maybe,
if
we
only
added
egress
support
for
now
and
the
other
thing
is
we
only
ever
added
ip
block
ingress
support,
because
people
didn't
like
the
idea
of
having
different
selectors
for
ingress
and
egress.
Nobody.
C
E
E
A
Yeah
I
mean
my
my
overarching
goal
and
reason
behind
pushing
only
addressing
not
addressing
north
south
in
this
originally
was
a
to
simplify
the
cap
and
not
have
to
answer
some
of
these
questions,
because
we
already
had
to
deal
with
answering
a
lot
of
questions.
Second
of
all,
second
of
all,
I
believed
that
there
were
enough
user
stories
that
were
different
to
warrant
a
new
resource
like
ego's
firewall.
So
in
a
perfect
world,
I
would
recommend
users,
you
know,
control
their
cluster
with
a
admin
network
policy
set
and
also
a
cluster
egos
firewall
set
right.
A
D
A
follow-up
point
to
what
andrew
was
saying
was:
I
we've
seen.
People
want
to
configure
matting
capabilities
as
well
on
on
the
egress
like
they
want
to
be
able
to
say,
let's,
let's
set
up
a
g
in
that
gateway,
essentially
right
and
then
rob
traffic
through
that.
That
may
or
may
in
my
mind,
that's
a
vote
for
a
separate
object,
because
the
interaction
between
an
admin
network
policy,
egress
traffic
and
in
that
gateway
is
similar
to
the
interaction
between
ingresses
and
network
policy.
Today,
which
is
a
total
disaster.
D
It
would
be
nice
if,
if
you
know
we
all
sat
down
and
said
hey,
if
we
want
to
talk
about
egressing,
a
cluster,
here's
the
list
of
things
that
we
need,
we
need.
You
know
in
my
mind
at
the
very
least
natting-
and
you
know
a
certain
like
allowed,
deny
firewall
capabilities,
and
maybe
there's
a
few
others
that
we're
missing,
and
maybe
they
all
need
to
be
bundled
together
right
out
of
the
gate
to
prevent
some
nasty
interoperability
right.
But
then
it.
E
You
know
you
can't
talk
to
any
external
ip,
but
then
once
they
do
that
suddenly
they've
blocked
pods
from
talking
to
other
pods
as
well,
and
they,
like
you,
know
the
the
things
get
in
each
other's
way.
So
so
we
want
to
make
sure
that
we
define
this
in
a
way
that
doesn't
get
in
the
way
of
what
people
might
want
to
do.
If
it
doesn't,
you
know
actually
solve
it,
and
that
probably
requires
more
thought.
But.
D
C
A
E
A
A
If
there
was
you
could
you
could
have
technically
technically,
then
you
could
force
with
admin
network
policy
force,
folks
to
use
things
the
way
they
were
designed
right.
You
could
block
everything
to
a
pod
outright
and
then
say
you
have
to
use
ingress
api
to
get
traffic
to
the
pod,
because
that's
the
only
thing
we
know
about
it's
the
only
thing
we
can
select
and
vice
versa
for
egress,
but
it
doesn't
work
because
we
don't
have
anything
for
you
guys.
A
E
These
are
some
really
really
good
thoughts,
although
I
mean
people
could
still
implement
like
their
own
egress
routers.
Basically
right,
like
pods
in
this
name,
space
can't
are
only
allowed
to
talk
to
pods
in
this
other
name.
Space
and
pods
in
that
namespace
can
can
talk
everywhere,
and
so
you
know
people
could
write
their
own
egress
routers,
but.
A
But
then
it
goes
back
to
what
has
been
done
for
so
long
and
that's
the
major
problem
right
that
really
I'd
say
from
sig
network's
point
of
view.
Stuff
hasn't
been
used
exactly
as
they
intended
a
lot
of
the
times
right.
So
I
look
at
that
and
I
think
this
group
looks
at
that
and
says:
how
can
we?
How
can
we
push
not
not
force
anyone
to
do
anything
but
push
folks
in
the
right
direction?
Right,
okay,
these
are
some
really
good,
really
really
good
thoughts.
D
D
D
A
Resolution
to
that
question,
from
tim
and
from
everyone
I
think,
has
been:
let's
get
v1
alpha
1
in
and
if
cni's
can't
implement
it,
they
can't
implement
it.
This
api
is
going
to
work.
We
have
to
re-analyze
it
I'm
coming
back
today
and
saying
I've
been
hearing
it
kind
of
along
with
dan
has
has
stated
like
more
and
more
I'm
worried
about
customers.
A
E
C
Yeah
right
so
coming
from
the
entry
perspective,
you
know
we
have
some
sort
of
like
solution
for
this.
It's
not
you
know
really
clean,
but
it
works.
So
essentially,
if
you
actually
know,
for
example,
something
like
the
cluster
slider,
then
the
sider
is
whatever
you're
you're
implementing
in
the
in
the
acl
rules
and
then
for
the
not
self
kind
of
things
you
might
know
the
namespace
either
or
if
you
don't
have
something
like
that,
you
might
know
what
pod
exists
in.
In
that
name
space
you
have
specific
ips.
C
A
Right,
but
if
we
did
define
it
as
segmenting
everything
so
going
back
again
to
like
the
baseline
deny.
I
keep
thinking
about
this
a
little
more
for
now
and
say
that
if
you
deny
a
workload,
everything
is
blocked
north
south
east
west
and
we
still
didn't,
allow
a
way
to
poke
holes
in
that
north-south
wise.
Would
that
be
the
most
outlandish
thing
ever
like?
I
need
to
go,
look
and
see
how
many
implementations
actually
have
like
an
ingress
or
egress
router.
A
A
Okay,
I
think,
if
anything
you
know
thinking
just
about
egress
definitely
is
the
right
way
forward,
not
focusing
on
ingress
and
egress,
and
this
is
something
we
should
definitely
talk
about
more.
Is
there
a
good
way
for
me
on
the
kep
or
on
the
api
pr
to
bring
this
to
the
forefront
like?
Should
I
just
toss
some
sort
of
egress
selector
in
there
and
try
to
advocate
for
discussion,
or
should
I
just
make
a
big
comment
on
the
pr
and
maybe
open.
A
A
The
jedi
masters,
okay
cool.
I
will
also
actually
open
an
issue
just
for
this
specific
thing,
because
the
other
stuff
we
can
debate
on
the
cap,
I
feel
like
it's
really
small.
This
is
a
question
I'd
like
to
maybe
summarize
what
we've
talked
about
here
today
and
put
it
in
an
issue
so
other
folks,
coming
in
after
code.
A
Freeze
next
week
can
see
like
where
we're
at,
and
why
we're
here,
because
this
was
a
really
great
conversation
today,
we
didn't
come
to
any
super
conclusions
for
anyone
watching
the
recording,
but
I
think
there's
a
bunch
of
good
points
that
need
to
be
written
down
and
debated
before
we
merge
this
api
before
it's
too
late.
Essentially
so
yeah
is
there
any
other.
Any
other
concluding
points
folks
would
like
to
talk
about
in
terms
of
admin,
network
policy.
A
D
I
I
mean
I
can.
I
can
just
tell
you
what
I'm
like,
where
I'm
at
right
now,
so
I
I've
been
busy
for
the
past
couple
of
weeks
with
like
non
fqdn,
kubernetes
stuff,
but
the
last
the
status
as
I
last
left.
It
was
that
we
decided
in
the
sig
network
meeting
that
we
would
want
to
send
out
a
survey
to
just
you
know,
network
policy
users
at
large
and
get
an
idea
of
what
are
they
doing
with
this
fqdn
behavior?
What
are
they
looking
for?
D
Are
they
looking
for
a
proper
l7
policy?
Behavior,
like
you
know,
with
http
verbs
and
like
really
full
l7
support,
or
do
they
really
really
want
this
fqdn
behavior,
where
we
resolve
an
fqd
into
ips
and
then
apply
a
policy
based
on
that
I
yeah,
so
I
I
put
together
a
sample
or
a
draft
of
a
survey
that
I
was
just
kicking
around.
It's
not
ready
yet,
but
I'll
try
to
get
it
polished
up
and
send
it
out,
maybe
later
this
week
or
early
next
week,
where
we
can
just
brainstorm
on.
D
A
D
D
A
A
Awesome
well,
hey
thanks!
So
much
for
everyone
showing
up
today,
really
appreciate
you
having
you
dan
you're,
a
big
help
here
for
for
some
of
this
discussion,
and
hopefully
we
can
get
the
api
agreed
upon
and
merge
soon
and
you
know
start
actually
implementing
something
in
this
group.
I
think
we'll
have
our
hands
full
when
that
actually
happens.
So
that's
all
I
have
for
today
thanks
everyone
and
we'll
be
talking
to
you
all
soon
have
a
good
one.