►
From YouTube: Network Policy API Bi-Weekly Meeting for 20220214
Description
Network Policy API Bi-Weekly Meeting for 20220214
A
Awesome,
hello.
Everyone
today
is
february
14
2022..
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup
district
network.
This
is
a
cncf
certified
meeting.
So
let's
be
nice
to
everyone
and
have
a
good
day.
I
added
some
small
stuff
to
the
agenda
role.
I
see
you're
here.
I
don't
know
if
you
wanted
to
just
maybe
have
kind
of
any
idea
bouncing
before.
A
B
Yeah
yeah
that
sounds
good
yeah,
so
the
the
long
story
short
is.
We
presented
a
rough
deck,
which
was
basically
just
transcribing
the
working
doc
that
we've
had
going
for
a
couple
weeks.
Now
we
presented
it
to
sig
network
and
I
think
the
broad
strokes
were
people
were
generally
supportive
of
an
fqdn
api
in
entry
or
in
the
as
a
part
of
the
oss
specification.
There
was
some
concerns
about
what
the
wildcard
specifier
would
do,
but,
generally
speaking,
the
api
seemed
fine.
B
I
think
where
there
were
a
lot
of
pretty
valid.
Concerns
were
around
integrating
fqdn
into
the
existing
network
policy.
Api,
specifically
the
the
sort
of
v1
api,
and
I
think,
bowie
and
tim
and
dan
made
a
good
a
few
good
points,
especially
about
conformance
basically,
today
there
is
no
proper
conformance
for
network
policy.
B
We
have
a
bunch
of
features
in
network
policy
and
we
don't
make
a
good
effort
to
define
what
features
are
optional
or
what
features
are
required
and
we
don't
have
test
grids
that
enforce
that
or
anything
of
that
nature.
And
so,
especially
when
you
add
something
like
this
pattern
match,
which
ostensibly
some
cni
providers
could
you
know
decide
not
to
implement
because
it's
a
lot
harder
than
doing
an
exact
match.
We
need
a
good
story
around
all
right.
How
do
we
indicate
that
this
is
optional?
B
B
B
C
B
Okay,
cool
my
bad.
What
I
was
saying
was,
I
I
think
tim
was
mentioning
that,
because
of
the
all
ports
feature,
I
believe,
which
is
in
beta
right
now
in
network
policy,
v1,
there's
there's
some
concern
around
cni
is
not
supporting
it
and
so
they're
thinking
of
adding
a
status
field
to
network
policy
itself,
and
so
maybe
we'll
want
to
keep
track
of
how
they're
doing
that
and
sync
up
here.
B
But
what
I've
done
is,
I
you
know,
took
heavy
inspiration
from
the
old
status
cap
and
basically
sketched
out
an
idea
of
all
right
if
we
wanted
to
have
some
sort
of
conformance
indicator
as
part
of
this
fqdn
api.
What
would
that
look
like,
and
so
I
have
this
status
with
a
bunch
of
conditions
that
you
can
set,
namely
enforcing
to
say
that,
yes,
I
am
trying
to
enforce
a
particular
feature
or,
oh
actually,
the
status
gap
is
merged.
B
Yeah,
I
guess
I
need
to
read
up
on
this
captain
I
haven't.
I
haven't
been
quite
current,
but
I
think
the
idea
would
be
that,
since
there
is
a
status
in
network
policy,
we
can
potentially
explore
what
adding
fqdn
would
look
like
in
v1
and
whether
we
can
leverage
the
status
capabilities
to
cleanly
implement
that
in.
But
the
the
approach
that
will
probably
get
us
quick
traction
in
sig
network
is
to
say,
okay,
why
don't
we
create
a
brand
new
api
object?
B
D
E
Per
let
me
let
me
suggest
something
before
we
jump
into
the
technical
details.
Sure
I
think
I
think
that
right
now
what
we
should,
what
we
should
do,
because
from
from
from
from
my
perspective
on
the
end,
part
right
and
all
of
the
other
caps
that
I've
been
dealing
and
also
andrew,
has
been
dealing
right.
So
if,
if
we
decide
right
now-
and
I
agree
with
you
that
we
we
need
to
have
some
concerns
on
on
the
technical
implementation
side,
I
just
don't
think
that
right
now
is
the
right
timing
to
do
that
right.
E
So
we
can,
we
can
come
and
say
hey.
So
this
is
the
api
design.
This
is
the
way
that
we
think
that
it
should
work
and
then
jumping
into
the
cni
implementations.
We
need
to
discuss
with
them
if
they
want
to
do
that
or
not,
and
by
my
experience
as
an
example,
so,
let's
let's
say
psyllium
right
so
psyllium
they
do
have
their
own
way
of
implementing
these,
which
is
as
an
example
intercepting
via
ibpf
the
query
for
dns
right.
E
So
this
is,
I
don't
know
if
this
is
the
way
that
they
do
that.
But
this
is
like
a
way
that
probably
it's
possible
and
the
same
thing
for
like
let's
say
on
tria
we
can
as
an
example,
I
don't
speak
for
entry.
A
young
does,
but
I'm
just
giving
an
example.
Okay,
so
in
andrea
we
can
give
an
intercept
so
the
implementation
side
for
the
cni
right
now.
In
my
opinion,
we
should
not
discuss
about
that
right.
E
E
Right
think,
okay,
so
I
I
just
I
just
don't
want
to.
I
just
don't
want
to
discuss
right
now
sure.
What's
what's
what's
implementation,
what's
the
implementation
caveat
on
that
right?
So
what
what
the
cni's
or
I
mean,
I
think
that,
right
now,
what
we
need
to
do
is
hey
cni's.
We
we
do
have
this
proposal
right
so
yeah.
Does
this
make
sense
for
andrea
to
implement
casey?
Does
this
make
sense
to
to
to
khali
to
implement?
If
not,
should
we
start
implementing
this
as
like,
as
jay
always
bring
as
a
controller?
E
So
you
probably
does
have
a
user
story
to
bring
this
to
us,
like
a
user
need
for
that,
and
probably
google
does
or
does
not
have
a
way
of
implementing
that.
So
I
I
would
I
wouldn't
in
my
in
my
perspective,
probably
I
am
wrong,
usually
usually
I
am,
but
I
wouldn't
spend
too
many
time
right
now
discussing
about
implementation.
Caveat
because.
A
A
A
A
A
People
were
like,
oh
yeah,
we
need
this
like
I,
everyone,
a
lot
of
implementations
and
and
distros
already
have
some
sort
of
dns
matching
the
biggest
thing
that
we
got
hung
up
on
in
that
meeting,
which
was
funny
was
the
wild
card
matching,
and
it
was
a
conversation
of
is
this
possible
or
not
right?
So
rather
explaining.
D
D
E
But
yeah,
I
I
agree
with
you
and
and
this
is
why
I
think
that,
right
now
we
shouldn't,
because
we
don't
have
everyone's
opinion
here
right
now.
We
don't
know
how
how
google
as
an
example,
if
they
don't
use
psyllium
if
they
are
going
to
be
able
to
implement
that
over
there
borg
thing.
I
don't
know,
I'm
just
I'm
just
throwing
random
words
right.
I
don't
know.
I.
E
D
Works
right
so,
in
that
case,
sort
of
what
the
capabilities
a
conforming
implementation
must,
that
is
mandated
that
it
must
handle
and
what
this
optionally
and
then
sort
of
you
fill
in
you.
When
you
have
your
implementation,
you
say
with
capabilities
that
is
fulfilled
by
a
particular
implementation.
D
E
D
E
Long
as
it's
clear
that,
yes,
my
point
here
right
now,
my
point
here
right
now
is:
let's
allow
rahu
to
to
present
the
whole
situation,
but
maybe
we
should
start.
Maybe
we
should
start
just
commenting
all
of
the
implementation
caveats
and
then
and
then
cycle
back
again
to
the
cab
review.
That's
good!
E
E
E
In
the
minutes,
it's
there
yeah
so
so
put
your
comments
on
there
and
probably
on
the
next
meeting.
We
can
because
we
we
still
need
to
to
to
work
on
something
in
this
group
right.
So
in
the
next
meeting
we
can
we
can
discuss
about
like
the
the
questions
over
every
every
comment.
I
still
need
you
to
add
that
so
we
can
at
least
we
can
have
the
whole
picture
right
now.
Probably
I
will
take
some
notes
on
that
as
well.
Machinery.
D
E
Yeah
all
right
yeah,
so
rahu,
if
you
wanna,
if
you
wanna,
move
forward
with
that,
I
don't
know
if
you
already
presented
that
I
just
jump
in
just
just
jump
it
in
because
of
the
network
policy
status
stuff.
I
wanted
to
to
to
give
you
some
some
status
over
the
network
policy
status,
but
go
ahead.
I
forgot
to
add
into
the
agenda
as
well
so
andrew
you
can.
You
can
just
curse
me
and
ask
me
to
come
back
another
week
doing
that,
but
right
now
now
you're.
B
Yeah-
and
I
mean
that
that's
a
fantastic
point-
the
the
optional
the
optional
matchers
is
something
that
we
really
do
want
to
make.
As
you
know,
a
core
part
of
the
api
that
we're
designing,
and
so
I
yeah,
I
encourage
you
to
read
through
what
I've
sketched
out
for
this
status
and
conformance
section
here
is.
I
will
I
need
to
do
my
homework
as
well.
I
need
to
go:
read
the
network
policy
status,
stuff,
understand
and
internalize
that
and
then
flesh
out
this
example
a
little
bit
more.
B
This
was
just
hacked
together
and
you
know
slapped
on
as
a
last-minute
addendum.
But
ideally
what
I'd
like
to
do
is
flesh
this
out
before
thursday,
and
I
think
we
have
a
little
bit
of
time
in
sig
network
where
we
can
come
back
and
present
this
again,
there's
also
a
section
on
expected
behavior,
which
starts
to
get
a
little
bit
into
the
nitty-gritty
of
you
know.
How
should
this
policy
behave?
How
should
it
be
enforced
and
stuff
like
that?
B
A
Yeah,
I
I
think
you
did
a
really
good
job
on.
Let
me
just
say
that
instinct
network
last
time
like
it's
hard
to
keep
that
group
corralled,
and
I
think
we
had
a
pretty
constructive
conversation
and
the
general
just
was
like
we
like
this.
We
don't
like
the
implementation
right.
So,
let's,
let's,
like
ricardo,
said,
let's
focus
on
the
api,
making
it
as
best
as
we
can
to
solve
the
use
cases
right
now
and
then
like.
Maybe
we
will
circle
back
and
take
some
time
and
even
look
at
you
know.
A
D
A
D
D
That's
all
of
my
scare
when
I
see
something
like
that,
you
do
a
request
and
get
the
data
structure
back
that
contains
addresses
and
not
not
names
that
they're
not
looked
up
but
I'll.
You
want
the
comments
already
by
thursday
right,
that's
what
he
says
you
can
present
again
on
on
thursday,
so
I'll
I'll
try
to
get
some
time
tomorrow,
too.
A
To
go,
that'd
be
awesome
and
circling
back
to
conformance,
so
this
kind
of
goes
in
line
with
expected
behavior.
You
know
a
lot
of
this
is
done
with
cyclonus
and
I
I
keep
raving
about
it.
I'm
working
to
try
to
bring
that
kind
of
in-tree
in
our
repo
and
we
could
literally
build
in
fqdn
policy
conformance
testing
within
cyclonus,
like
it's
just
an
extension
of
it.
It's
a
nice
piece
of
software
that
just
sits
and
almost
gets
forgotten
right
exactly
so
I'd
love
for
us
to
be
able
to
to
hold.
A
You
know
the
crd
definitions
and
api
definitions
for
these.
These
objects
we're
proposing,
especially
if
they're,
going
to
be
implemented
as
crds
and
I'd
also
love
to
hold
the
tools
that
help
us.
You
know
verify
what
features
are
supported.
What
features
are
not
against
various
implementations
and
cyclonus
already
does
a
lot
of
infrastructure,
so
I
think
it
fits
right
in
here.
That's
a
little
bit
down
the
road,
but
I
don't
even
know
if
you
want
to
mention
that
here
you
know
in
signet
work
yet,
but
something
to
look
forward
to.
F
D
Started
looking
really
seriously
on
the
multi-cluster
rules
yet,
but
I
mean
that
must
be
even
on
the
same
problem
right
there.
Two
clusters-
people
are
not
supposed
to
know
about
the
underlying
eyepiece
and
you
want
to
say
what
can
talk
to?
What
can
you
talk
about
the
objects
inside
there
or
you
need
to
use
the
dns,
for
it
can.
B
B
Use
case
yeah
absolutely
so
I
have
a
couple
of
user
stories
at
the
top,
but
I
mean
just
to
talk
through
who
those
folks
are.
Basically
the
the
request
was
that
you
can
use
ip
blocks
and
they're
and
the
the
people
who
want
to
use
this.
Are
you
know
conceptually
okay
with
using
ip
blocks
to
allow
and
reject
traffic?
The
the
concern
is
mainly
around
supportability
of
that
behavior
like
for
one.
It's
a
little
bit
tricky
to
look
at
an
ip
block
and
understand
what
this
particular
rule
is
doing.
B
It's
easier
just
from
a
use
perspective
to
look
at
a
fqdn
and
say:
okay,
I
understand
what
this
rule
is
trying
to
achieve.
So
that's
one
reason
that
we've
had
this
request
and
the
other
one
was
to
yang's
point
about
ephemeral,
ips
or
rotating
ips,
and
things
like
that.
They
don't
want
to
keep
track
of
a
changing
record.
They
want
to
be
able
to
just
point
you
to
an
fqdn
and
say:
okay,
go
figure
this
out
the
just
just
because
you
might
brought
it
up.
B
The
multi-cluster
thing
is
a
really
good
point
and
I
have
a
to
do
in
the
expected
behavior
about
how
we
want
to
handle
in
cluster
services
and
those
dns
records.
I
that's
that's
a
very
open
point
and
I
I
think
we'll
have
to
dial
in
on
that.
You
know
in
future
iterations
but
yeah.
I
think
it's
very
much
still
open
about
how
we
handle
in
cluster
services
and
also
services
exported
from
a
multi-cluster
scenario,
or
something
like
that.
F
F
B
D
B
F
F
To
always
assume
that
there
can
be
some
sort
of
a
amino
policy
in
the
cluster
where
admin
can
configure
like
if
in
a
cluster,
there's
actually
no
other
means,
for
example,
then
a
network
policy
with
fqdn
rules
in
the
best
case
scenario,
should
be
working
on
its
own
right.
So
in
that
case
it
will
be
something
like
you
specify
fqdm
rule
and
another
egress
rule
just
to
egress,
to
the
dns
namespace,
for
example.
F
B
You
actually
that
raises
an
interesting
point
which
I
hadn't
thought
of,
is
I
guess
what
we're
saying
with.
If
we
choose
to
go
down
the
route
of
making
this
its
own
api
object,
what
we're
saying
is
that
it
can't
stand
alone
for
most
implementations
right,
like
just
installing
fqdn
and
programming.
A
bunch
of
rules
will
actually
just
not
work
for
you.
No.
F
It
for
for
standalone
resource
it
will
work
because
for
standalone
resources
you
can
define
another
semantics
right
because
you're
saying
this
for
this
fqdn,
we
are,
for
example,
only
only
talking
about
all
of
cluster
things.
So
so,
when
you
apply
the
rule
with
an
fqdn,
it
doesn't
really
affect
or
lock
down
anything
in
cluster
it
just
lock
down,
for
example,
all
of
cluster
access.
F
Then
we
don't
have
this
problem,
but
if
you
wanted
to
combine
this
with
current
network
policy,
v1
for
example,
then
you're
matched
with
this-
you
know
tricky
little
caveat
that
comes
with
input
isolation,
but
but
if
you
have
a
whole
different
resource,
then
you
can
define
whatever
semantic
you
want.
You
can.
You
know
using
another
semantics
to
get
around
this,
but
I
I
doubt
it
will.
It
will
be
well
receiving.
D
E
Services
is
this,
is
this
is
actually
one
of
the
decisions
that
I
remember
about
being
a
discussion
of
this
fqdn
think
right.
So
if
it
should
be
just
like
a
way
to
block
queries
on,
coordinates
and
be
like
a
plugin
for
coordinates
or
if
we
really
want
to
be
on
the
middle
of
the
data
path,
and
I
think
that
right
now
again
it's
for
me,
it's
an
implementation
detail
that
we
should.
We
should
take
care,
but
also
ask
for
the
users
on
or
on
the
user
story.
Hey
what
do
you
want?
D
E
E
This
yeah
but
hold
on
this
is
the
implementation
detail
that
I'm
talking
about
so
right
now.
I
think
that
okay,
we
we
have
caveats
on
both
of
them,
but
we
should
just
heard
from
just
heard
from
the
user
say
actually
from
the
cluster
admins
hey.
What
do
you
mean
by
an
ftdn
policy?
You
want
to
change
the
dns
query
or
you
want
to
change
the
data
path
right
and
over
that
we
we
can
decide.
We
can
decide
with.
How
is
the
implementation
going
to
be
so?
B
I
have
a
data
point
about
that,
so
this
is
something
that
I
I
know
gobind
and
maybe
andrew
sykim.
I
forget
who
else
they
talked
about
this
during
the
last
iteration
of
fqdns
and
gobin
did
a
a
bit
of
reach
out
to
customers,
and
I
can
ask
him
to
share
the
the
data
I
don't
have.
You
know
the
raw
data
on
hand,
but
the
the
upshot
of
that
was
that
customers
expected
this
to
be
a
data
path
protection,
not
just
a
dns
protection.
B
D
E
And
this
can
be
a
haircut
sorry,
sorry
for
interrupting
you,
so
no
I
was
done.
This
is.
This
is
something
that
that
can
be
part
of
the
cap.
Okay,
so
you
can
put
the
caveats
you
can
put
the
limitations.
You
can
say
that
this
solves
and
this
doesn't
solve
the
problem.
So
right
now
we
don't
know
if
this
is
going
to
be
accepted.
E
We
need
to
map
everything
on
that
and
and
just
add,
but
again
trying
to
stick,
in
my
opinion,
with
the
implementation
details
all
over
the
cab
right,
because
then
you
can
call
as
an
example.
We
don't
have
all
of
the
all
of
the
cni
folks
here,
but
as
soon
as
we
as
soon
as
you
send
that
in
sig
network,
all
of
the
cni
folks
that
are
going
to
jump
in
and
say
hey
this
is
possible.
This
is
not
possible.
This
can
be
done.
This
cannot
be
done
and
then
we
can.
D
D
If
we
intercept
sort
of-
and
we
can
still
describe
a
model
right-
that
it
comes
from
that
that
you
have
to
intercept
the
dns
call
and
then
check
that
against
the
filter,
and
so
on
I
mean
I'm
not
sure
we
can
describe
a
model
for
it
at
least
an
abstract
model,
not
how
it
should
be
implemented.
But
to
describe
how
the
sort
of
what
the
expected
outcome
is.
D
B
A
B
At
the
end
of
the
day,
if
we
can
just
get
a
determination
on
the
the
way
the
winds
are
blowing,
I'm
hearing
make
this
a
new
object.
It
simplifies,
you
know
how
we
define
it
and
the
expected
behavior.
So
if
I
can
basically
pitch,
I
guess
what
is
proposal
2,
essentially
in
this
case,
which
is
building
a
brand
new
resource,
and
you
know
with
some,
you
know
incorporating
the
lessons
learned
from
the
network
status
if
we
create
a
brand
new
object
with
fqdn.
B
Does
this
broadly
appeal
to
the
sig
community
and
I
think
if
we
can
just
get
a
yes
we're?
Okay
with
creating
a
brand
new
object,
we
still
need
to
define
exactly
its
behavior,
and
you
know
exactly
whether
cni's
can
support
this,
but
if
I
can
probably
get
a
yeah
go
ahead
with
you
know
further
explorations
on
this.
I
think
that's
a
good
outcome
on
this,
where
everyone's
aligned
that
okay,
we're
gonna
make
a
new
object.
A
A
Cool
okay,
awesome,
perfect
thanks,
so
much
roll.
The
only
other
thing
I
had
on
the
agenda
today
was
just
some
wrap-up
stuff.
With
ann
p,
there
was
kind
of
a
little
funny
thing.
I
don't
know
if
some
of
you
might
have
not
might
not
have
seen
that
we
had
actually
merged
the
anti-cap
without
it
being
marked
as
implementable,
and
so
I
had
to
file
an
exception,
but
it
got
passed
and
everything's
good
now,
but
it
was
just
a
funny
little
hiccup
at
the
end
of
a
very
long
road.
A
So
thanks
for
all
the
help
there,
the
next
thing
for
amp
is
just
finalizing.
There's
two
to-do's
in
the
kep
still
before
we
can
actually
start
opening
a
pr
to
implement
the
api,
and
I
was
just
going
to
ask
here
like
what
do
we
think
is
the
best
way
of
resolving
those
to
do's,
because
these
are
both
things.
I
I
have
it
in
the
agenda.
A
One
is
the
meaning
of
priority
zero,
of
course,
and
the
other
is
to
calc
how
to
calculate
the
number
of
maximum
rules
in
a
single
amp,
and
I
want
to
resolve
these
well.
The
two
options
are:
we
resolve
them
before
I
start
implementing
the
api
or
I
start
implementing
the
api
and
we
resolve
them
in
that
pr.
I
don't
know
if
folks
have
opinions
on
one
way
or
the
other,
but
I
don't
really
to
be
honest.
A
I'm
gonna
take
that
as
in
no
one
has
any
opinions
on
how
to
how
to
solve
that
one.
I
think
the
right
thing
to
do
is
gonna
be
getting
maybe
another
small
separate
meeting
with
like
the
likes
of
tim
and
the
people
who
you
know
had
objections
to
what
we
had
originally
and
see
if
we
could
come
come
to
some
sort
of
conclusion.
So
if
no
one
has
any
objections
to
that
I'll
set
something
like
that
up.
A
A
But
I
think
by
now
it's
somewhat
obvious,
so
yeah
congrats
again
to
everyone
who
worked
on
this
thing
and
we'll
just
work
to
keep
moving
it
forward.
The
last
thing:
I
guess
you
are
here
ricardo.
Do
you
want
to
say
anything
else
about
the
network
policy
status
cap?
Do
you
want
to
you
know,
clap
your
hands
get
excited.
I
don't
know
what
one
more
kept
for
me.
E
Yeah,
so
just
just
to
to
to
to
put
everybody
on
the
same
page,
so
the
cap,
the
stereos,
got
merged.
That
cap
was
a
a
recommendation,
actually
a
requirement
from
the
the
prr
and
the
and
also
team
review
to
get
and
part
and
market
sga
in
a
way
that
cni
is.
They
can
provide
an
information
on
why
a
network
policy
was
or
wasn't
merged
was
a
wasn't
implemented.
Sorry,
so
I
have
started
implementing
that
thing
right
now.
E
So
I
plan
by
the
end
of
this
week
to
have
at
least
the
implementation
of
the
api,
the
the
model
and
and
and
maybe
start
adding
some
some
tests
if
they
are
required
and
then
poking
c
network
approvers
and
api
reviewers
to
say
hey,
can
this
get
merged
or
hey?
Can
should
we
put
this
on
a
hole?
I
think
that
I
wanted
to
bring
to
you
folks,
as
we
have
some
some
folks
from
from
cni
here.
E
Cnice
is
that
the
airport,
when
I
sort
of
implemented
the
end
part
logics
on
on
some
of
the
cni's
right,
so
I
did
that
on
calico.
I
did
that
on.
I
did
that
on
cube
router,
and
I
did
I
did
that
some
sort
of
a
park-
a
proof
of
concept
in
in
cilium,
and
there
is
a
pr
open
for
that
right.
I
didn't
did
that
on
montreal.
I
wish
I
could
yen.
They
did
that
and
I
didn't
did
that
on
an
open
shift,
one
right.
E
So,
in
the
network
policy
status,
there
are
some
graduation
criterias
as
well
for
the
cni's,
but
I
wouldn't
be
able.
I
won't
be
able
to
do
this.
Do
this
sheffield
in
on
on
the
cni's
on
the
other
cni's.
So
we
can
we
we
have.
We
do
have
the
risk
of
getting
stuck
in
alpha
status
or
better
status
if
no
cni
wants
to
implement
that
right.
E
So
probably
this
is
something
that
we
should
keep
on
on
track
and
because
this
getting
stuck
will
get
stuck
also
the
port
ranges-
and
this
can
get
also
direct
impact
on
the
fkdn1
as
well.
If
they
put
the
status,
if
we
decide
to
put
the
fkdn
field
on
the
network
policy
object,
instead
of
in
like
getting
a
different
object,
and
this
get,
this
can
be
a
risk
for
for
other
things
as
well.
A
D
C
E
A
C
A
A
Cool
great,
so
is
there
anything
else
from
anyone
comments,
questions
concerns
going
once
going
twice:
sold;
okay,
cool!
Well,
hey
thanks!
Everyone
for
coming
I'll,
be
in
touch
shortly;
rahul,
if
you
need
any
help
this
week
before,
like
review
just
reach
out
in
the
slack
channel,
and
I'm
happy
to
take
another
round
of
look
at
the
document
and
stuff
so.