►
From YouTube: Kubernetes SIG Network meeting 20200716
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).
A
B
All
right,
thank
you,
dan
all
right,
so
the
gist
is.
Last
week
we
had
some
discussion
about
getting
some
repositories
created
for
srov,
cni
and
device
plug-in,
and
you
know
the
group
brought
up
that.
Maybe
we
should
have
some
type
of
governance
structure
to
to
kind
of
define.
You
know
the
rules
of
the
road
for
having
some
repositories
under
you
know
on
some
common
ground
here
and
I
think
that's
a
great
idea.
I
think
it's
a
little
overdue,
so
yeah.
B
I
think
that
it's
a
great
time
to
tackle
that
one.
So
I
have
started
a
proposal
document
it's
in
the
agenda,
but
I'm
throwing
it
into
chat
as
well.
Basically,
what
I
did
here
is
well,
first
of
all,
just
let
you
guys
know
I
did
so.
B
I
love
that
and
basically
what
he
said
was
you
know
what
try
to
cover
these
two
things
first
and
then
expand
from
there
as
need
be
and
what
he
said
to
focus
on
was
how
do
you
become
a
member
of
the
group
and
then
how
do
you
become
a
core
contributor
to
the
group,
so
I
attempted
to
write
up
with
a
focus
on
those
two
things
and
then,
additionally,
I
proposed
a
code
of
conduct
document
that
I
that's
a
boilerplate
from
contributor
covenant.org.
B
So
that's
what
I've
got
in
there
so
far
and
there's
been
a
number
of
other
comments
on
the
document
and
some
other
considerations
that
I've
heard
and
one
of
those
considerations
is.
Should
we
have
something
that
looks
like
a
like
technical
steering
committee,
something
that
we
can
use
to
resolve
issues
that
arise.
You
know
and
maybe
to
give
guidance
on
on
those.
So
that's
something
that
would
expand
upon
those
like
first
two
considerations
there
and
anyways
that's
kind
of
where
I'm
at
so.
B
Let's
see,
I
guess
one
other
thing
I
wanted
to
get
input
on
to
as
well,
and
I
think
that
the
hopefully
we
can
come
to
a
consensus
on
a
code
of
conduct
at
least
quickly.
I
think
that
it
should
be.
You
know
that
shouldn't
be
too
too
hard,
but
I,
I
guess,
there's
a
few
different
paths
we
could
go
there.
Contributor
covenant
looked
like
an
easy
path
and
I'd
used
it
for
some
other
repositories
before,
but
we
could
possibly
use
the
cncf
code
of
conduct
as
well,
but
yeah.
B
I
think
the
code
of
conduct
would
be
kind
of
nice
because
I
mean
to
put
it
succinctly:
it's
sort
of
nice
to
let
people
know
hey,
you
know
you
should
be
a
decent
human
being,
and
I
think
that
stuff
should
be
easy
to
agree
to
yeah
any
questions
or
comments,
and
we
can
talk
about
some
of
the
comments
in
the
doc
too.
A
Well,
I
was
just
gonna
ask
what
kubernetes
used,
but
it
seems
like
they
have
also
adopted
the
code
of
conduct,
at
least
at
one
point.
Do
you
have
any
idea
how
the
cncf's
code
of
conduct
is
different
from
contributor
covenant.
B
B
B
So
there
was
something
to
me
about
the
like
simplicity
of
that
and
essentially
what
it
boils
down
to
in
contributor
covenant
as
far
as
violation
is,
if
you
feel
like
these
have
been
violated,
here's
the
way
to
contact
x
and
they'll
decide
what
to
do
so
at
any
rate
yeah.
I
certainly
would
love
some
other
perspectives
on
this
one
for
sure,
and
also
dig
up
the
cncf
code
of
conduct
too.
A
Okay,
I
think,
at
the
very
least,
we
should
set
a
deadline
of
next
meeting
for
people
to
review
and
then
decide
on
which
code
of
conduct
or
covenant
that
we
should
use.
It
seems
like
two
weeks,
is
a
pretty
reasonable
amount
of
time
to
take
a
look
at
one
or
two
or
three
of
the
choices
that
you'd
propose.
Doug.
B
All
right,
cool,
yeah
I'll
make
sure
that
I
update
the
agenda
with
some
more
information
to
give
people
a
little
bit
more
more
food
for
thought.
But
I
guess
I
would
say
generally
from
my
read-throughs-
I
mean
they
do
they.
They
tend
to
cover
the
same
type
type
of
stuff
and
at
any
rate,
I
also
would
like
to
thank
the
group
for
making
it
so
that
we
have
not
had
to
cover
this.
C
A
C
B
Write
some
short
blurbs,
some
executive,
summaries
and
and
I'll
give
my
own
recommendation
and
yeah
happy
to
get
feedback
for
sure.
I
also
will
another
action
that
I
have
is.
I
am
gonna
sit
down
and
specifically
review
this
document
with
people
that
have
written
governance
before
this
will
include
josh
burkus
who's,
a
member
of
the
cncf
governance
working
group.
B
So
I
think
it'll
be
pretty
nice
to
get
some.
You
know
expert
expert
opinion
on
this
particular
document,
but
certainly
that
that
should
happen
before
our
next
meeting.
B
So
if
you
don't
mind,
I'd
like
to
take
just
a
minute
to
look
at
some
of
these
comments
and
get
some
feedback
from
the
group,
so
that
I
can
make
sure
that
I
cover
that
stuff
with
josh
and
get
his
take
on
it,
and
you
know
to
create
a
dialogue
about
this
for
sure
and
cover
all
the
stuff
that
we're
worried
about
sure
go
ahead,
all
right.
B
So
the
first
one
here
is
from
zenghui,
and
it's
about
the
question
of
how
do
we
determine
a
project
can
be
hosted
under
our
network
plumbing
working
group,
github
organization?
B
Previously,
I
think
the
process
has
generally
been.
We
bring
it
up
on
a
meeting
if
there's
no
previously
the
way
it's
happened
is
it's
been
brought
up
there
as
far
as
I
know,
hasn't
than
anyone
who's
disagreed
to
create
a
repository,
so
it's
basically
been
like
bring
it
up.
If
no
one
descends,
we
create
the
repository
and
yeah.
I.
A
Do
agree:
it
would
be
good
to
have
some
criteria
there
yeah,
you
know,
even
to
be
as
explicit
as
it
has
to
be
something
related
to
the
network,
plumbing
working
group
or
an
implementation
of
a
specification
that
the
group
has
developed.
A
Something
like
that.
Absolutely.
B
And
yeah,
what
do
you
think
so
just
to
go
over
a
little
bit
of
the
of
the
details
of
what
I
had
here
for
so
essentially
two
parts
in
governance,
which
is
how
do
you
join,
and
the
answer
of
how
do
you
join?
Is
you
just
participate
unless
you
break
the
code
of
conduct
right
and.
B
A
core
contributor,
I
essentially
said
to
become
a
core
contributor
on
the
project,
put
your
name
in
the
agenda
and
which
projects
you'd
like
to
be
a
core
contributor
on
and
then
we'll
take
a
vote.
And
so
I
guess
I
would
say
possibly
to
scope.
You
know
the
criteria
for
a
new
project.
B
Maybe
I
would
write
something
along
similar
lines
that
says,
if
you
want
to
get
a
new
project
in
put
it
in
the
agenda,
write
a
description,
explain
how
it's
relevant
and
then
we'll
take
it
to
a
vote,
and
then
it
might
kind
of
echo
the
same
the
same
thing.
How
do
you
guys
feel
about
that?
And
I
can
take
it
as
an
action
to
jot
down
something.
C
I
think
the
reason
I
have
these
comments
and
many
because
I
know
there
are
one
of
the
main
reason
we
drive
this
process
is
that
there
are
several
projects
we
want
to
actually
add
into
the
under
the
network,
plumbing
group
and
and
those
projects,
for
example,
for
the
srv
ones,
which
somewhat
somehow,
as
vendor
specific
some
of
those
invitations,
and
we
do
want
those
projects
which
all
support
features
that
is
already
upstream,
for
example,
we
may
elaborate
some
kernel
features
in
order
to
implement
some
functions
there,
but
if
that
feature
is
not
available
upstream
in
kernel,
then
do
we
also
considering
adding
those
features
of
those
projects
under
mpwg?
C
So
some
other
questions
similar
to
this
yeah,
probably
we
we
can
have
some
guidelines
on
how
people.
If
people
want
to
add
a
project
into
this
group,
then
they
need
to
meet
several
categories
there.
Maybe
upstream
is
a
the
first
one.
You
need
to
have
your
dependencies
the
upstream
in
order
to
add
project
here,
and
that's
just
one
example.
I'm
sure
there
will
be
other
circle
and
and
also
I
think,
for
for
hardware.
C
Related
projects
like
srv
drives
plugins
in
nine
and
vendor
may
have
different
limitations
there
and
how
we
guarantee
that
we
are
actually
contributing
to
a
general
solution
instead
of
understanding
yeah.
B
Yeah,
I
I
absolutely
understand,
and
I
think
that
it's
a
yeah,
I
think
it's
smart
to
to
consider
to
you
know.
You
know
I
think
all
of
us
want
to
create
projects
with
a
healthy
life
cycle
that
encourages
people
to
contribute
to
them.
B
D
Doug,
just
a
quick
knit
you're
for
your
notes
and
changes.
You
have
the
17th
today's
the
16th.
Are
you
planning
on
fixing
that
tomorrow,
or
is
that?
Oh.
B
B
A
Right,
let's
see
so
next
thing,
going
back
a
little
bit
to
the
code
of
conduct
and
covenant
stuff,
you
know,
there's
a
section,
an
overview
that
proposes
that
we
accept
the
code
of
conduct
and
links
to
the
covenant
contributor
covenant.
But
then
section
a
on
governance
also
talks
or
says
that
interactions
with
the
group
are
covered
by
the
cncf
code
of
conduct.
B
C
B
B
B
I
think
that
that
would
be
okay
to
specify
adrian.
Would
you
want
to
write
a
blurb
for
it.
B
F
F
Kind
of
my
make
like
the
statement
of
making
sure
that
prs
like
are
aligned
with
the
project.
You
know,
project
scope
or
the
network
farming
mission
statement
requires
that
you
know
we
have
those
two
so
going
back
like
if
we
go
to
like
to
zengui's
comments
there.
I
also
added
something
there
beneath
about
like
do.
We
have
like
a
mission
statement
for
the
network
plumbing
working
group,
which
you
know
some
general
guidance
and.
B
I
mean,
I
can't
argue,
I
can't
argue
against
it.
I
mean
it's
like
when
you
go
to
decide
if
it's
relevant
or
not,
it
would
probably
be
good
to
have
something
to
refer
to
to.
You
know
back
up
the
reasoning
there.
I
guess
I
guess
my
cons.
My
concern
is
a
little
bit,
as
is
two
part.
Is
you
know?
Sometimes
what
we
focus
on
can
be
like
very,
very
focused
like
when
we
talk
about
like
the
network
attachment
definition
specification
like
it's
a
very
specific
crd
right.
B
It's
you
know
it's
super
specific.
By
the
same
token,
I
wouldn't
necessarily
want
us
to
over
limit
ourselves.
So
at
least
to
me
it
sounds
very
challenging
to
to
write
a
mission
statement
I
feel
like.
I
know
it
I
feel
like.
I
know
it,
but.
F
Yeah-
and
I
agree
it
needs
to
be
broad
enough
right.
I
mean
I
I
like,
if
we're
talking
about
the
stereo
v
so
and
and
srv
device
plug-in,
so
I
mean
that's
not
only
like
we
are
saying
we
are
focusing
on
the
definition
of
you
know
defining
how
to
enable
secondary
networks
in
kubernetes
right.
So
that's
kind
of
related
right,
but
I
mean
looking
purely
at
the
crd,
so
it's
only
right.
F
It's
only
multis
is
relevant
here
right
because
essentially
secondary
networks
means
how
we
define
the
crd
and
how
a
delegate
plugin
should
act,
but
right
it's
more
than
that.
I
mean
it.
B
Absolutely-
and
I
mean
I
think
that
we
can
all
see
that
you
know
that
specification
enables
a
lot
of
other
relevant
usage
and
I
think
that
it
encompasses
like
a
lot
of
different,
tooling
and
options,
et
cetera,
just
as
like
a
short
example
is
like
we
have
a
repo.
That
is
that
we
call
reference
deployments,
and
I
mean
it
gives
you
a
number
of
different
options
of
ways
that
you
could
possibly
set
stuff
up.
So
I
think
that
there's
a
lot
of
you
know
ancillary
technology.
B
That
is
that
I
think,
is
relevant.
So,
let's
see
all
right
I'll
take
a
crack
at
writing.
A
mission
statement.
F
And
this
would
mean
right
that
related
project
would
need
to
be
aligned
with
that
mission
statement
by
the
way.
Does
the
group
here
feel
that
I
mean
I
see
adrian
moreno's
comment
here
about
having
a
well-defined
project
scope
for
let's
say
for
project
that
we
add
in
that
sounds
also
reasonable
right.
I
think.
F
B
I
would
say
you
know.
B
At
least
to
me,
I
think
that
it's
good
to
have
some
scope
description.
I
would
say
well
defined
to
me
probably
in
order
to
make
a
decision
on
it.
Maybe
a
couple
paragraphs
kind
of
a
thing.
I
don't.
B
I
necessarily
need
like
yellow
paper.
You
know.
F
C
Yeah,
I
agree
with
the
agent
on
that.
I
think
each
project
will
come
with
a
scope
definition
what
should
be
added
into
this
project
or
not,
and
I
think
as
it
evolves.
If
there's
any
change
on
the
scope,
then
there
should
be
a
process
how
we
can
change
the
scope
of
each
project
right.
That's.
F
G
One
question
so
so
at
that
time
the
yeah,
I'm
just
thinking
about
the
the
project
as
the
github
repository
at
that
time.
There
sometimes
do
we,
we
may
have
there
some.
G
How
do
does
a
well,
not
scoped
repository
like
the
early,
the
equivalent.
Let
me
let
me
check
the
repository
in
the
network,
prompting
working
group
like
reference
deployment
repository
or
some
stuff
contains
the
not
so
clear
scope,
but
of
course
this
is
required.
I
think
so.
I.
G
I'm
I
don't
have
the
clear
conclusion
yet,
but
today
we
could
have
some
flexible
stuff
for
scoping
for
our
project.
B
Yeah
good
call-
and
I
think
that
you
know
you
know
I-
I
am
definitely
not
a
lawyer,
but
I
do
know
that
the
way
that
laws
are
typically
written
is
to
make
them
they're
made
in
such
a
way
that
they
can
be
interpreted
so
that
you
know
a
a
reasonable
person.
Can
you
know,
make
a
judgment
call
on
it
so
like,
for
example,
to
prevent,
like
some
stupid,
technical
loopholes
or
whatever?
B
So
maybe
the
maybe
the
right
thing
to
do
is
to
leave,
leave
some
wiggle
room
to
write,
to
write
a
mission
statement
and
to
leave
some
parts
of
it.
That
are,
you
know
somewhat
broad,
so
that,
for
example
like
just
this,
just
like
silly
example
but
anish-
who
I
think
is
on
the
call
and
thank
you
for
this
anish
had
made
a
contribution
to
reference
deployments.
B
That's
for
dhcp,
cni
damon
to
run
in
pods,
and
it's
like
a
daemon
set
for
that,
and
it's
really
a
cni
thing
right,
but
it's
really
useful
for
somebody
who's
say
spinning
up
multis,
which
is
a
reference
implementation.
So
it's
you
know
these
are.
This
is
handy
tooling,
to
have,
and
it
fits
kind
of
under
the
umbrella
of
additional
networks
and
how
how
you
utilize
them
and
how?
How
they're
used
in
the
real
world.
D
C
B
I
absolutely
agreed-
and
I
feel,
like
you
know
it's-
we
have
valuable
code
in
there,
that's
related
to
to
pocs
and
yeah.
They
might
be
experiments
and
they
might
be
tangential
in
some
way,
but
they
do
have
some
relation
for
sure
yeah.
Thank
you
billy,
without
a
doubt,
all
right,
changing
the
topic
lightly,
but
in
the
spirit
of
some
of
the
stuff
that
we
do
best
in
this
group
is
we're
good
at
writing
some
specifications
and
then
making
some
implementations
and
having
some
constructive
dialogue
to
see
how
these
mesh
together.
B
B
Would
we
want
to
have
somebody
to
write
those
proposals
for
next
week
and
see
what
a
proposal
looks
like
in
relevant
to
like
this
governance
model
that
we
have
and
then
use
that
as
feedback
for
both
of
those
things
so
that
we
can
say:
okay,
hey
here's,
what
a
proposal
looks
like
here's,
what
the
governance
model
looks
like.
Can
we
like
mesh
these
together?
Does
that
sound
interesting
to
anybody.
C
Hey
doc,
so
what
you
expect
in
that
proposal,
for
example,
let's
take
the
sro2
as
plugin
as
example,
and
then
the
documentation
to
be
will
be,
for
example,
what
action
would
take
in
order
to
move
that
into
mpwd
group.
B
So
this
so
yeah
definitely
a
creative
invention.
B
What
is
allowed
here,
my
gut
is
so
I
put
I
just
stubbed
in
here
a
section
c
which
would
be
addition
of
new
projects
under
our
github
organization,
and
I
guess
I
was
going
to
say
something
that
echoes
something
like
what
the
becoming
a
core
contributor
has
there,
which
is
essentially
to
say
added
to
the
agenda,
add
some
kind
of
description
to
it
and
then
we
would
put
it
put
it
up
for
put
it
up
for
a
vote.
B
So
I
would
say
generally
it
would
be
an
agenda
item
that
has
one
or
two
paragraphs
that
talks
about
how
the
projects
are
relevant
to
the
group
and,
as
adrian
mentioned,
is
the
you
know
that
probably
needs
to
be
guided
by
a
mission
statement
so
that
you
have
something
to
refer
to
to
determine
that
it
is
relevant.
So
some
of
this
stuff
would
happen
in
parallel
or
do
we,
so
I
guess
I'm
getting
the
feeling.
C
B
C
C
B
Yeah
that
sounds
really
good
and
yeah.
I'm
totally
happy
to
look
at
that
with
you,
anytime,
just
ping
me,
and
we
can
look
at
that,
because
that
will
also
be
helpful
in
me
to
to
have
the
other
perspective
of
writing
the
proposal
and
then
to
use
that
as
mental
feedback
for
me
for
moving
forward
on
this
governance
dog
all
right.
B
Cool,
I
think
that
that
covers
the
main
stuff
that
I
am
thinking
about,
and
I
also
just
want
to
give
a
huge
thanks
to
everybody
for
all
the
like
thoughtful
commentary
on
this.
This
is
it's
really
good,
and
I
think
that
there's
a
lot
to
consider-
and
I
think
that
we
can-
I
think
that
we'll
be
able
to
move
forward
very.
D
A
All
right
also
doug,
it
might
be
one
last
point.
It
might
be
useful
to
see
what
the
criteria
and
setup
process
is
for
the
kubernetes
working
groups
like
official
cube
working
groups
and
then
incorporate
some
of
that
into
the
governance
as
well.
So
like.
B
And
I
feel
like
some
of
sometimes
we
do
our
best
work
when
we
have
good
reference
points.
I
think
that
is
for
basically
everything
in
life,
whether
it
be
art
or
science
or
anything
else,
but
yeah.
I
think
that
having
some
more
reference
points
is
good
I'll.
Look
into
that.
Thank
you,
david.
A
H
H
Putting
up
putting
together
a
poc
of
this
proposal,
credits
to
perry
from
erickson
who's
here
and
who
has
helped
me
a
lot
doing
this
demo.
There
is
a
recording
at
the
bottom
of
the
agenda
and
yeah
and
all
the
urls
of
the
repositories.
H
I
have
put
all
the
logic
that
has
to
do
with
how
the
device
information
is
written
and
retrieved.
H
I
have
put
that
in
a
library,
so
we
so
changes
in
the
spec
should
not
modify
each
individual,
cni
or
or
device
plugin
very
much.
It
should
just
mostly
affect
the
library,
so
I
hope
that
makes
it
easier
to
iterate
on
on
the
proposal.
A
Yeah
or
at
least
discuss
them
like
what?
What
are
the
limits
of
the
proposal?
There's,
obviously
an
objective.
But
what
are
some
things
that
we're
specifically
trying
not
to
achieve
since?
Sometimes
that
helps
frame
the
debate
and
make
sure
that
we
don't
go
too
far
in
a
direction
that
won't
be
useful.
D
Yeah,
I
agree.
Sorry
real,
quick
agent,
you
said
you
put
it
in
the
chat,
but
I
don't
see
it
I.
I
will
paste
it
in
there.
H
B
H
H
Go
ahead:
oh
sorry,
this
this
zoom
up
anyway
yeah!
So
what
I
specifically
don't
want
to
cover
with
this
proposal,
I
guess
is
mainly
what
the
cni
or
of
the
device
so
the
ways
this
devices
are
created
and
consumed
by
cni's
device,
plug-in
or
workload.
H
I
am
more
interested
in
the
way
the
information,
the
meta
metadata,
the
information
about
these
devices
is
passed
and
passed
along
and
shared
between
the
different
elements
of
of
of
the
system,
so
yeah
I'll
try
to
write
it
down
any
anyone
has
any
other
idea
of
what
we
should
not
cover
on
this
document.
On
this
proposal,.
A
I
I
tried
to
take
note
of
what
you
just
said
and
put
it
in
a
reply
to
my
comment
in
the
doc.
I
I
I
agree
with
that.
I
think
that's
a
good
place
to
start
at
the
very
least
is
specify.
H
Yeah
that
works
for
me,
yeah
and-
and
this
attaches
a
bit
of-
and
maybe
a
problematic
issue,
because
we're
here
in
this
proposal
kind
of
establishes
how
the
cni
should
work
or
how
the
cni
might
be
given
certain
information
or
how
the
device
plugin
should
should
and
up
to
now,
this
group
has
been
focusing
on
how
the
how
the
implementation
this
this
network
plumbing
working
group
implementation,
such
as
multis
behave.
H
So
I
don't
know
if
trying
to
say
trying
to
specify
what
the
device
plugin,
for
example,
should
do
is
going
out
of
the
scope
of
this
group,
or
you
know
it's
it's
a
blurry
area
for
me.
I
don't
know
if,
if
writing
this
down
in
this
document,.
H
Makes
any
sense
until
the
devices
plug-in
and
the
cni
come
together
in
in
this
in
this
organization?
That
dog
is
putting.
D
Yeah,
that's
a
good
point
dan
doug.
How
do
y'all
feel
about
that?
I
mean
the
original
start
of
this
was
to
kind
of
specify
like
how
to
you
know
with
maybe
like
the
network
status,
how
to
more
standardize
what
information
is
passed
into
the
container,
but
now
we're
getting-
and
I
agree
I
mean
we've
had
to
do
all
this-
to
figure
out
where
some
of
this
data
that
we
want
to
pass
into
the
containers
come
from,
but
does
it
fall
out
of
the
scope
of
the
spec
or
is
it
a
a
second
spec?
A
Work,
if
we're
going
to
touch
the
network
plumbing
working
group
spec,
I
think
we
should
have
those
pieces
so,
for
example,
sections
about
what
the
key
looks
like
in
the
status
annotation
or
something
like
that
be
specified
in
the
plumbing
spec,
but
that
can
certainly
refer
to
another
document.
I
don't
want
to
shove
a
bunch
of
stuff-
that's
not
specifically
related
to
that
stuff
into
that
document.
At
least
just
right
and.
A
A
Doing
a
more
comprehensive
view
of
exactly
what
this
process
should
look
like
and
to
end
and
trying
to
standardize
that
and
we
can
distribute
the
actual
wording
and
the
actual
specification
work
between
you
know
one
or
more
documents
as
we
see
fit.
Okay,.
B
Yeah,
just
a
plus
one
yeah,
I
I'm
excited
to
see
you
know
how
you
know
how
much
consideration
has
gone
into
this
document
and
certainly
happy
to
get
updates
to
the
the
additional
network
spec,
but
the
de
facto
crd,
but
yeah.
I
think
that
this
is
there's
so
much
consideration
here
that
it's
worthy
of
its
own
documentation
for
sure-
and
I
mean
I
would-
I
would
leave
it
to
you
guys
on
how
you
would
want
to
word
it
in
terms
of
these
are
the
best
practices.
B
A
So,
just
time
check,
we've
got
about
10
minutes
left.
Are
there
specific
things
that
you're
blocking
on
adrian
continuing
on
this?
That
you'd
like
comment
on.
H
Not
really
that
I'm
blocked
on,
I
well
the
the
proof
of
concept
kind
of
works,
so
I
I
have.
I
haven't
got
time
to
go
through
the
comments
that
you
have
added.
I
will
do
that
right
now
and-
and
everybody
is
welcome,
all
the
comments
are
welcome.
I
I
I'm
not
blocked.
I
would
like
to
keep
improving
the
poc
and
keep
putting
more
details
into
the
document
and.
H
A
Okay,
yeah,
like
doug,
said
thanks
for
all
the
work
on
this
so
far.
One
last
question
I
had
was
what
are
some
of
the
pain
points
that
you
found
so
far
in
doing
the
poc.
What
things
have
been
not
as
smooth
as
you
hoped
or
expected,.
H
But,
generally
speaking,
I
think
they
were
mostly
due
to
my
lack
of
experience
on
it.
H
Also,
I
so
I
have
found
bugs
here
and
there
that
I
will
report
and
fix.
H
H
So
that
is
that
was
not
happening
in
malta's
and
so
in
the
next
weeks.
I'll
try
to
go
deeper
into
how
to
avoid
leaking
files.
E
A
Good
to
hear
I
would
say
that
delete
is
a
little
bit
tricky
because
sometimes
you'll
get
the
first
delete,
that'll,
have
information
and
then,
depending
on
whether
or
not
cache
files
have
been
cleared
or
garbage
collection
in
cube,
you
may
or
may
not
get
all
of
the
information
on
the
next
delete
if
you
get
to,
but
we
can
have.
If
you
want
more
clarity
on
what
the
behavior
is,
there
feel
free
to
reach
out,
or
you
know,
send
email
to
the
plumbing
working
group
list
or
something
like
that.
H
Excellent
then
I
I
will
yeah,
as
I
said,
I
will
investigate
further
and
and
if
I
see
something
that
looks
complicated,
I
will
reach
out
okay.
A
All
right,
so
please
review
doug's
proposal
again
and
add
more
comments
to
that
and
then
we'll
also
wait
for
some
of
doug's
investigation
or
recommendations
and
doug
when
you
get
that
done
or
if,
if
you're
able
to
clean
up
the
governance
proposal
in
the
next
week
or
so,
would
you
mind
sending
mail
to
the
group.
B
Yes,
so
we
got
a
heads
up.
B
Yeah
I'll
plan
on
getting
that
by
next
thursday
and
I'll
have
a
mail
out,
so
people
have
a
reminder,
but
if
you
want
more
updates
in
real
time
I'll
actively
be
working,
the
doc
and
I'm
happy
to
take
in
place
edits
as
well
too.
Leave
comments
and
I'll
also
update
the
primary
agenda.
So
take
a
look
there.
If
you're
looking
for
something
in
more
real
time
before
then,
but
I'll
make
sure
to
give
you
guys
a
weak
warning,
it's
it'll
be
sweet
to
have
some
feedback.
So
thank
you
guys.