►
From YouTube: CNCF CNF WG Meeting - 2021-02-01
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
Okay,
I
think
we
can
probably
get
started
today.
So
thanks
everybody
for
joining
the
cnn
working
group
just
once
more
drop
the
link
to
the
meeting
minutes
in
the
chat.
If
you
want
to
just
add
your
name
there,
then
we
can
get
started
before
we
kind
of
jump
into
our
topics
today.
Does
anyone
have
anything
they'd
like
to
add
to
the
agenda.
A
Okay,
seeing
nothing
we
can
jump
in
just
two
things
I
want
to
highlight
for
those
that
are
interested.
The
first
one
is
kubecon
cloud
nativecon
europe
is
coming
up
in
may,
so
it's
may
4th
through
the
7th
and
something
that
might
be
especially
interesting
to
this
group.
Is
that
there's
now
going
to
be
the
kubernetes
on
edge
event
at
co-located
to
kubecon,
so
it's
the
monday
before
kubecon
actually
starts.
The
cfp
is
currently
open.
A
B
Sure
yeah
thank
you
for
pulling
them
up,
so
you
got
I'm
sorry,
I
missed
last
week,
but
the
group
has
a
large
approved
an
existing
pull
request
for
we
adding
context
so
specifically
like
when
we
start
talking
about
best
practices
providing
a
little
context
just
because
a
best
practice
might
be
very
use
case
specific.
For
instance,
there
was
in
the
discussions
a
lot
of
talk.
I
always
use
this
example
of
them
privileged
containers.
B
B
There
will
be
other
instances,
though,
like
when
we
start
getting
into
some
of
the
more
fuzzier
definitions
of
what
is
and
isn't
a
cf
but
like
if
a
orchestration
provisioning
service
comes
with
the
cnf
and
it's
built
in
it
needs
to
make
requests
of
the
infrastructure
underneath
to
do
that,
it's
going
to
have
to
have
privilege
right,
like
it's
going
to
be
able,
it
needs
to
be
able
to
talk
to
the
colonel,
make
requests
least
privileged
one
still
applies
so
just
because
it
should
only
have
the
privileges
it
needs,
but
just
in
general,
right
like
saying
hard
and
fast,
all
containers
would
never
need
to
talk
to
the
colonel
is
a
little
misleading
right
so
that
got
approved.
B
I
talked
to
taylor
last
week
and
we
agreed
that
maybe
the
place
that
I
originally
stuck.
It
was
a
little
bit
awkward
on
how
it
flows
with
the
overall
proposal
layout,
and
so
we
kind
of
just
put
it
in
a
spot.
We
think
it
flows
a
little
bit
better.
It
comes
before
the
user
stories,
but
after
the
initial
pitch
that
way,
you're
not
adding
any.
B
Like
you
know,
I
don't
I'm
going
to
say
negativity,
but
basically
kind
of
like
already
adding
like
counter
arguments
to
your
own
proposal
before
you
get
to
you
know
the
meat
and
potato,
so
you
get
to
the
entire
pitch
and
then
right
before
you
hit
user
stories.
You
say
by
the
way
you
know
it's
for
these
specific
types
of
things.
B
It
might
not
apply
to
these
specific
things,
and
then
you
can
start
building
your
user
stories
now
that
you
have
the
context,
so
that
was
just
kind
of
the
thought
on
why
we
moved
where
we
think
context
should
go,
and
then,
conversely,
I
had
waited
until
we
agreed
that
context
was
needed
in
the
first
place
before
attempting
to
go
to
the
actual
template
and
adding
it
there,
and
so
I
created
a
separate
pr
just
in
case.
We
don't
want
to
move
it.
B
A
Cool
thanks:
does
anybody
have
any
thoughts
on
this.
A
A
Yeah
yeah,
so
it's
just
essentially
moving
something
higher
and
then
adding
a
note
in
here
about
adding
a
warning
when,
obviously
not
all
workload
types
are
the
same.
So
there
should
be
a
warning
when
things
aren't
the
same.
C
So
one
comment
to
add:
for
those
who
weren't
on
the
telecom
user
group,
one
of
the
areas
of
discussion
was
how
do
how
are
we
going
to
work
with?
What's
currently
available
and
and
potentially
building
from
there
and
dealing
with
current
active
problems
on
networking
deployment
orchestration
other
things,
so
the
way
that
this
that
bottom
area
for
notes,
constraints
and
caveats
ties
in
is
to
communicate
where
a
best
practice
may
have
problems,
and
that's
the
importance
of
this.
C
So
a
best
practice
may
be
put
forward,
but
it
wouldn't
help
with
a
specific
type
of
workload
and
calling
that
out
for
those
that
it's
not
implicitly
visible
is
is
a
good
thing
and
that
the
workload
context
at
the
top
is
supposed
to
help
drive
those
type
of
decisions
and
thoughts
on
whether
or
not
the
best
practice
is
useful.
For
you.
C
I
I
think
that
probably
needs
to
be
changed,
based
on
the
direction
that
we've
been
moving
and
adding
this
that's
a
they're,
not
optional.
When
we
look
at
the
outside
and
referencing,
so
it's
having
some
context.
Maybe
it
was
just
originally
we
had
so
many
items
there,
watson.
D
Yeah
like
but
not
optional,
and
on
the
anti-context
or
whatever
that
section
was
where
it's
saying
oh
in
these
contexts,
it's
not
this.
I
guess
best
practice
or
whatever
is
not
useful
or
whatever
I'd
say,
make
it
so
to
where
that
part
is
also
not
optional
for
those
user
stories,
if
you're
going
to
put
something
in
there,
you
should
have
a
real
reason.
Why.
C
D
Make
up
a
user
story
at
least
yeah
have
them
to
where
they
write
a
user
story
and
other
people?
If
we're
going
to
have
them
separate
it
links
to
a
user
story,
and
then
people
can
either
vote
on
it
make
a
survey
off
the
user
story
whatever
just
you
make
up
a
user
story
and
it
has
zero
people
supporting
it.
Then
that's
the
strength
of
your
user.
C
The
argument
for
your
best
practice
proposal
and
so
yeah
so
on
the
user
story,
specifically
when
you're,
when
you
have
a
best
practice
that
you
want
to
talk
about
then
but
you're.
Not
maybe
you
don't
even
have
a
full
user
story
but
you're,
saying
they're
using
this
type
of
methodology
process
or
whatever
you're
looking
at
over
in
the
kubernetes
world
for
other
applications,
and
it
seems
like
we
should
use
it
here,
but
you
can't
quite
come
up
with
the
user
story.
C
You're,
probably
better
off,
not
creating
a
pull
request,
but
instead
go
create
a
github
discussion
and
say
I'm
trying
to
I'd
like
to
have
help
on
creating
the
user
story
so
that
by
the
time
we
get
in
and-
and
you
say,
let's
create
this
as
a
a
pull
request.
We
think
we've
found
a
solid,
a
solid
best
practice
proposal.
C
C
And
I
want
to
separate
that
from
the
notes
and
caveats
section
so
when
you
get
into
the
notes
and
caveats
so
that
this
is
essentially
a
catch-all,
so
we
may
want
to
break
that
out
and
not
just
have
it
with
all
those
constraints
and
caveats.
So
we
may
notes
could
just
be
reference
tied
in
with
like
the
references,
so
any
any
other
details
that
are
helpful
to
understand
the
best
practice.
That's
what
this
is
for
and
I
don't
think
we
should
have
an
a
a
required
note
section.
C
D
C
So
then
that
should
be,
it
seems
like
that,
should
be
split
from
that
section
and
just
not
have
it
at
the
end
that
third
third
piece
that
you're
there
bill.
If
you
highlight
we
have
three
pieces,
there
notes
constraints
and
caveats
and
we
could
make
the
caveats
another
section,
maybe
right
right
below
user
stories.
C
A
C
And
feel
free
to
rename
it
if
you
think
trade-offs
helps
with
I'm
guessing
that
you're
saying
on
the
language
trade-off
would
communicate
what
you're
you're
saying
any
best
practice
is
going
to
have
trade-offs
or
any
solution.
That's
proposed
will
have
its
own
trade-offs.
A
Yeah,
okay,
so
thanks
watson
for
making
the
pull
requests
on
that.
No,
I
guess
going
back
to
like
this
pr,
so
this
is
just
moving
something
like
up
above,
I
know
jeff.
I
think
he
made
this
just
earlier
today,
so
I
think
I'd
be
happier
for
you,
oh
four
days
ago,
like
I'm
happy
to
approve
it
as
is,
but
I
don't
know
if
other
people
want
to
like
have
time
to
add
their
comments.
C
D
A
Okay,
great
so
thanks
jeff
for
making
those
pull
requests
and
forgetting
that
merge
gin
and
for
watson
for
opening
up
a
pr
to
help
change
that
too
great
so
point
two
so
making
the
goals
more
concise.
A
So
this
was
changing
around
the.
So
this
is
in
the
readme
and
it's
like
basically
changing
around
the
goals
of
the.
A
C
So
that
I
guess
at
the
highest
level,
there's
two
things
number
one:
we're
moving
away
from
talking
about
required
or
conformance
type
words,
so
moving
away
from
that
language
towards
this
language
of
best
practices,
so
we're
putting
forward
best
practices
that
could
be
relevant
to
either
developers
so
you're
you're,
developing
cns
or
you're
on
maybe
you're
an
act,
an
ops
operator,
ops,
team,
sorry,
not
just
an
operator
but
you're
on
an
ops
team,
and
is
this
best
practice
relevant
to
you
so
moving
forward
towards
that
as
far
as
language?
C
And
then
the
other
part
would
be
thinking
about
networking
in
general.
So
that
was
another
earlier
topic,
if
you're
on
the
tag
call
and
and
shrinking
that
in
and
then
a
little
bit
more
focus
around
kubernetes.
So
it's
that's
really
the
language
we've
been
using
that
other
places.
So
this
is
trying
to
update
the
charter
to
to
match
that,
and
there
was
some
of
these.
That
was,
I
think,
from
earlier.
C
And
then
I
see
you've
expanded
a
few
of
those
things
kubernetes
versus.
Do
you
mind
if
I
commit
that
I
I'm
looking?
I
just
I
hadn't
read
those
so
efficiency
versus
effectively.
There
are
some
comments
about
even
removing
some
of
these
because
they're
duplicate,
but
I
think
we
can
do
that
in
another
iteration.
A
C
C
So
that's
kind
of
shows
we're
we're
primarily
removing
a
lot
of
the
extra.
A
Words
yeah,
so
I
think
we
have
four
approvals
now
unless
there's
a
lot
of.
C
F
Well,
just
regarding
that,
in
the
first
bullet,
you
are
removing
the
cloud
at
least
dropping
a
little
bit
about
the
cloud
native
principles.
Is
that
okay,
like
the
way
that
you
describe
like
it's
just
identifying
best
practices,
but
it's
not
referring
anything
to
cloud
native
principles,
is
that
is
that
it
is
not
reducing
the
scope
of
this
bullet
or
is
keeping
the
same.
C
So
that's
a
good
comment.
I
guess
the
first
part
would
be
the
rest
of
the
charter.
If
you
look
at
the
whole
context,
cloud
native
principles
and
kubernetes
native
best
practices
is
still
there.
If
you
look
at
those
two
goals
by
themselves,
then
then
the
change
does
drop
that,
but
that's
that's
not
the
intention,
and
these
are
would
be
identify.
C
Kubernetes
native
and
at
a
general,
more
general
level
level
would
be
cloud
native
best
practices
so
that
that
could
be
explicit
to
identify
kubernetes
and
cloud
native
best
practices
for
cns.
That
would
be
how
I
would
write
that
the
main
part
was
to
remove
the
portion
on
using
to
to
be
used
to
demonstrate
how
well
software
adheres
to
cloud
native
principles.
C
So
that's
not
the
intent
really.
What
we're
saying
is
whether
you're
a
cnf
developer,
you're
developing
software,
that
that
could
be
run
on
cube,
that's
to
be
run
on
kubernetes
or
you're,
a
an
operator
trying
to
find
different
networking
applications
that
you're
going
to
use
and
you're
you're
handing
this
over
to
your
ops
team
to
identify
those
we're
hoping
that
the
best
practices
will
help
developers
to
build
better
software
that
runs
kubernetes
and
the
ops
team
to
see
software
that
helps
them.
Do
the
life
cycle
management
they're
going
to
do
so.
C
That's
what
the
language
is
about.
So
not
just
saying
we're
demonstrating
that's
good,
but
it's
actually
helping
their
lives,
but
putting
the
cloud
native
back
in
front
of
identify
before
best
practices
could
be
a
good
idea
before
where
so
I
I.
What
we
lost
here
was
the
cloud
native
principles
or
cloud
native,
so
it
would
be
between
it'd,
be
right
after
two
identify
cloud
native
best
practices
or
cube
native
whatever
we
want
to
say
on
here,
but
you
could
put
cloud
native
yep
there
we
go.
D
A
Great
also,
thank
you
for
the
comment
and
bring
that
back
was
that
victor.
That
said,
that.
A
Yeah,
thank
you
for
helping
out
with
that
cool.
The
next
one
is
taylor's,
so
these
one
actually,
these
two
next
two
actually
kind
of
go
hand
in
hand.
A
A
G
Yeah,
I
I
think
for
the
time
being,
we
stick
them
in
there.
This
doesn't
have
to
be
perfect
apart
from
anything
else,
but
secondly,
it
just
confuses
it's
not
always
clear
in
people's
mind
when
something's
a
use
case
and
something's
a
user's
story,
but
with
apologies
because
I
didn't
write
my
documents.
Last
week
I
was
going
to
put
together
the
a
grand
overarching
user
story
that
pretty
much
walks
through
the
the
general
deploy
and
use
cycle.
G
Saying
you
know,
roughly
operators
and
architects
decide
how
this
works
and
are
going
to
want
to
go
through
these
stages,
I'll
stuff
it
in
the
user
in
the
use
case
folder,
and
then
I
think,
actually
with
a
concrete
example
in
front
of
us,
we'll
be
better
off
able
to
decide
whether
that's
where
it
belongs
or
if
we
need
to
do
something
else.
E
A
C
So
this
pull
request.
46
is
like
the
like,
the
last
two
just
one
iteration,
so
we
can
come
back
over
this
and
and
add
more
just
like
we've
been
doing
in
the
pull
request
itself,
we
don't
have
to
have
it
to
perfect
if
it
doesn't
encompass
everything,
it's
a
structure.
Can
you
click
on
the
other
view
again
thanks
bill.
C
So
one
thing
to
point
out
is
we're
using
the
wording
of
networking
use
cases,
because
it's
been
talked
about
many
times
that
the
networking
applications
can
be
used
in
the
toco
world
and
also
outside
you
have
the
same
application.
That's
used
many
places,
so
we
want
to
make
sure
that
the
use
cases
aren't
restricted
where
they're
going
to
have
a
larger
application
and
then
in,
I
believe
in
the
could
have
been
slack
or
it
could
have
been
on
the
discussion
board.
Ian
pointed
out
that
there's
going
to
be
both
use
cases
and
best
practices.
B
C
On
this,
the
discussion
I
mean
on
the
pr
it
says:
networking
use
cases,
the
folder
itself
is
use
case
and
when
we're
requesting
use
cases,
if
you
have
one
that
you
may
not
think
is
networking
specific,
that's
applicable
outside
then
feel
free
to
add
something.
It's
we're
not
we're,
not
limiting
it
to
just
networking
if
it's
applicable
and
the
first
part
of
this
is
we're
creating
a
folder
just
to
mainly
talk
about
a
very
important
area,
and
this
is
use
cases.
C
I
don't
know
that
we
need
a
a
user
story,
but
I
do
want
to
point
out,
for
those
who
don't
know
a
use
case
and
a
user
story
are
two
different
things,
so
we
may
need
to
expand
on
this.
To
say
we,
if
you
have
a
user
story
or
a
use
case,
then
you
can
put
those
in,
but
this
is
getting
started.
C
So
we
have
this
use
case
folder,
where
we
can
add
larger
documents
that
we
want
to
keep
around
like
ian
was
talking
about.
If
you
have
a
smaller
use
case,
and
we
have
it
fully
fleshed
out,
then
we'll
get
pull
request
in
there.
If
you
don't
really
have
anything
other
than
maybe
you
just
have
the
title
of
a
use
case,
you've
seen
it
someone's
talking
about
it.
C
You
know
it
would
be
relevant
to
bring
over
here
then,
probably
that
first
discussion
topic,
which
is
the
link
there
in
that
first
paragraph,
how
to
add
so
there's
we
have
a
discussion.
Long
github
discussion.
Just
add,
add
the
add
the
title,
maybe
a
link
whatever
else,
if
you
already
know
about
a
yet
right
there,
so
you
can
just
add
to
this
add
to
this
topic
and
we
can
sit
here
and
and
keep
adding
more
as
we're
going
along.
C
C
It's
I'm
sorry,
not
bullet
point
second
paragraph
under
how
to
add
so
just
create
a
brand
new
discussion
topic,
and
then
you
can
put
inline
images
whatever
you
want
to
do,
link
to
external
material
and
we
can
start
building
it
out
before
we
do
a
full
write
up
and
add
it
into
the
use
case
folder
and
then
once
we're
actually
ready
to
add
something
into
the
use
case.
Folder,
because
we're
saying
we're
planning
on
referring
to
this
from
the
different
best
practices.
C
We
do
want
to
keep
as
much
material
within
the
repo
itself
rather
than
say,
link
to
an
external
google
doc.
So
we
don't
want
a
use
case.
Markdown
that
just
says:
go
read
the
real
one
over
here
or
a
pdf
for
something
else.
So
we
want
to
try
to
bring
the
content
internally
and
I
think,
tooling
and
stuff
around
that's
like
to
be
determined,
but
just
think
of
intent
of
trying
to
go
internal
and
as
much
as
possible.
Have
the
content
go
inline.
So
we
don't
want
to
just
upload
a
pdf
to
the
get
repo.
G
Yeah,
so
to
expand
on
that.
There's
two
aims
there:
one
is
our
use.
Cases
are
version
controlled,
because
if
we
change
our
mind,
we
want
to
know
we've
changed
our
mind.
If
you
basically
refer
out
to
a
google
doc,
then
there's
two
problems
with
that
one
is:
the
link
can
break
right.
You
delete
the
google
doc
because
you've
moved
on
the
other
is
that
you
can
change
the
document
without
going
through
any
sort
of
approval
process.
G
So
anything,
that's
really
kind
of
concretely
meaningful
to
to
the
use
case
wants
to
be
actually
committed
so
that
it's
version
controlled
and,
as
I
say,
the
other
part
that
is
external
references
links
age
out.
We
we
want
to
make
sure
that
doesn't
happen
to
us.
If
it's
got
material
information
that
we
don't
want
to
lose.
G
Editability,
I
think,
is
pretty
clear
right
if,
if
the
document
is,
if
somebody
embeds
a
pdf
and
it's
not
got
any
source
and
it's
uneditable
and
more
to
the
point,
it's
not
even
difficult
if
it's
a
whopping,
great
binary,
so
word,
documents
will
fall
into
the
same
category,
then
you're,
basically
just
cutting
a
barrier
to
entry
and
to
understanding
of
what
changes
are
being
made
as
well.
I
can't
diff
two
word
documents.
G
A
G
We
were
also
having
a
conversation
on
diagrams
and
I'm
not
saying
that
we
favor
at
all
over
others,
but
I
would
point
out
that
draw.I
o
you
can
embed
editable,
pngs
or
editable
svgs,
which
at
least
means
that
somebody
stands
a
chance
of
being
able
to
change
your
your
nice
png
if
you
put
it
in
there.
So
just
bear
that
in
mind
when
you're
selecting
your
tools
to
illustrate
your
use
case.
A
Yeah,
so
I
see
we
have
a
couple
different
discussions
here.
I
don't
know
the
current
status
of
these
taylor.
Did
you
make
this
change
so
relating
real
world
use
cases.
C
C
We
seem
to
agree
with
that,
so
we
just
have
the
relating
and
not.
We
don't
really
need
the
best
practices,
so
you
can
do
a
suggestion.
If
you
do.
C
A
A
I
guess
this
is
a
discussion.
Do
we
want
like
a
kind
of
a
template
or
not
going
for
this
going
forwards
for.
A
B
I
think
we
should
like,
I
think,
there's
got
to
be
some
kind
of
distinction
between.
This
is
a
use
case.
We
all
agree
because
in
the
previous
call
we
were
talking
about
potentially
using
those
as
like
foundational
pieces
to
then
start
building
best
practices
off
of
or
when
we
start
talking
about,
like
the
orchestration
task,
force,
etc.
C
Okay,
I
agree
that
we
need
templates.
My
suggestion
right
now
is:
let's
move
forward
with
the
request
for
use
cases,
and
then
we
start
building
out
the
templates
either
next.
So
if
someone
wants
to
take
on
that,
then
they
feel
free
to
or
organically,
as
we
start
to
see
use
cases
if
we
actually
had,
let's
say
10
use
case
prs,
because
people
were
ready.
They
just
said
I
have
all
the
content.
C
I
have
svg's
I'm
ready
to
create
prs,
I'm
happy
to
have
that
problem
right
now.
We
don't
have
any
use
cases
fully
fleshed
out
at
all.
C
B
Yeah,
I'm
fine
with
resolving
this
comment.
I
do
at
the
top,
though
some
of
the
wording
choices.
I
would
like
us
to
look
at
it.
I
put
some
stuff-
and
I
think
we
kind
of
skipped
past
that
one,
but
this
one
I'm
fine
with,
like
I'm
fine
with
just
getting
something
down
instead
of
googling
forever
on
some
of
these
initial
pr's.
B
A
E
G
Sorry
I
was
trying
to
get
rid
of
the
passive
voice
at
the
same
time.
So
it's
not
quite.
The
wording
that
jeff
used
is
agreed
upon
is
is
just
awkward.
It
basically
says
you
know
this
will
happen
without
your
assistance.
Don't
we
worry
about
it?
So.
B
B
No,
I
mean
the
big
thing
for
me
was
just
a
couple.
Things
is,
I
think,
like
most
clearly
like
I
don't
know
you
just
I
I
know
you
were
you
know
slacking
me
and
saying
you
don't
think
it's
quite
as
strong
as
I
just
sometimes
when
you
you
say
stuff
like
that,
like
I
just
know
that
there's
executives
in
my
company
that
will
latch
on
to
that
and
then
like
they
just
like,
run
amok.
B
You
know
when
you
use
stronger
language
like
that
and
then
the
other
thing
is
is
in
which
you
put
it
in
your.
Your
rework
is
specifically,
you
know
tying
it
into
like
the
kubernetes
piece
right,
because
once
again
to
you,
I
just
think
there
was
a
little
too
much
ambiguity
of
you
know:
kubernetes
best
practice
versus
cloud
data
best
practice.
First,
you
know.
I
know
you
are
sneakily
underneath
behind
the
cnc
and
like
well.
B
I
could
just
say
this
is
a
best
practice
because
we
agreed
upon
and
it
doesn't
matter
if
it
even
uses
kubernetes
so
just
being
a
little
bit
more
succinct
and
direct
here
I
think,
is
helpful
and
I
I
I'm
cool
with
bill.
What
ian
reworded
this
to.
G
A
Okay,
great
so
it
looks
like
we've
resolved
all
the
conversations
on
this,
so
unless
anybody
has
anything
else,
they
want
to.
G
Yeah,
I
don't
hate
to
use
the
the
trite
phrase,
but
the
the
perfect
is
the
enemy
of
the
good.
We
can
always
accept
these
changes
and
change
them
again
later.
There's
nothing
wrong
with
that.
A
Yep
exactly
this
is
another
one:
that's
been
kicking
around
for
a
while.
There's
been
quite
a
long
discussion.
A
There's
a
lot
about
this,
like
defining
the
actors,
and
I
think
this
will
play
into
the
use
cases
if
anybody's
interested
in
writing
up
kind
of
a
summary
of
all
these
discussions.
I
think
there's
quite
a
lot
of
material
here
and
now
we
just
need
to
refine
it
into
kind
of
like
a
first
draft
yeah.
G
G
C
I
would
go
to
the
top
on
that,
so
that
not
the
the
bottom
area
can
I
maybe
share
my
screen
for
a
moment
on
this
and
then.
G
F
C
Okay,
it
looks
good,
so
I've
tried
to
keep
coming
back
and
updating
the
top
and
which
I
think
you
can
see
here
this
way.
If
you
I
don't
know,
if
y'all
are
able
to
see
yourself
when
you're
on
the
on
the
discussion
board,
but
if
you
hopefully
can
see
the
revisions,
so
the
revisions
are,
as
I
tried
to
merge
what
everyone
was
talking
about
and
coming
to
some
type
of
consensus
around
it.
What
it
doesn't
have
is
the
last
updates
like
it
doesn't,
have
this
one
and
it
doesn't
have
a.
C
I
think.
System
integrators
are
there,
but
it
may
not
have
this
one
here
and
then
this
longer
thread
there's
a
part
right
here.
I
think
jeff
that
you
added
it
may
not
have
those.
Oh
the
purchaser.
I
think
the
purchaser
is
probably
the
biggest
one,
but
if,
if
you
start
here
and
look
at
what's
there
and
then
go
look
to
see
what
questions
or
comments
have
been
added,
that's
where
I
would
start
because
I
am
trying
to
keep
this
updated
to
whatever
is.
C
Current
consensus,
but
that
was
the
last
one
was
on
december
9th,
so
there's
been
a
little
bit
more,
so
we
tried
to
separate
the
different
orgs
from
the
actors.
This
context
part,
is.
We
don't
have
to
do
that
every
time,
but
the
point
was:
you
may
have
a
cnf
developer,
that
is
at
a
service
provider.
They
may
have
an
internal
team
and
you
may
have
a
ops
team
person,
that's
similarly
they're
outside
they're
inside
any
of
these.
So
we
try
to
separate
those
from
the
org
and
system
integrator
they're
added
here.
G
G
There
are
set
roles
that
are
completely
independent,
of
which
organization
they're
in
right
and
then
there
are
a
set
of
organizations
that
matter
because
they
tend
to
define
the
way
the
roles
communicate
with
each
other
a
little
bit.
So,
for
instance,
if
I've
got
service
provider
and
it's
a
fairly
common
example,
that's
buying
in
everything
right,
they're
buying
the
platform
from
one
group,
they're
buying
them
cns
for
three
or
four
other
vendors.
G
They
have
a.
They
either
employ
a
system
integrator
or
they
are
a
system
integrator,
but
there's
definitely
system
integration,
that's
happening,
so
the
roles
exist,
but
what
we're
actually
doing
is
describing
the
situation
on
the
ground
which
we
could
do
separately
in
an
extra
section,
the
roles.
G
I
think
we
need
to
be
a
little
bit
more
wordy
about
what
the
roles
do,
and
I
would
point
out
and
you're
going
to
argue
with
me
that
an
infrastructure
developer
is
not
a
cnf
developer,
so
that
one's
just
basically
slightly
the
tree
is
a
little
bit
wonky
but
yeah,
and
then
you
might
argue,
some
of
these
things
are
not
so
much
roles
as
hats
that
are
all
wears
right
when,
when
a
cnf
operator
is
got
his
security
hat
on
he's,
looking
at
it
in
a
certain
specific
way,
in
a
particular
with
a
particular
mindset,
it
doesn't
necessarily
mean
that
there
is.
G
G
C
G
And
maybe,
rather
than
trying
to
do
it
in
a
bullet
pointed
list,
we
try
and
give
a
a
paragraph
or
two
to
each
role
to
explain
how
we're
thinking
of
them,
because
you
know
two
words
we
know
from
past
experience
like,
for
instance,
network
to
take
one
example-
are
ambiguous
enough
that
you
don't
necessarily
get
the
detail
down.
So
you
know
putting
some
words
on
that
basically
says
we
are
thinking
of
a
cnf
developer
as
this.
C
B
C
The
repository,
but
do
we
want,
I
think
the
actors
are
relevant
as
well,
but
if
it
do,
we
want
to
to
start
a
new
discussion
just
for
the
roles
or
have
the
roles
as.
G
If
this
is
a
discussion,
then
the
answer
is
probably
that
we've
got
enough
information
in
here
and
common
thinking
that
we
could
put
a
pull
request
together,
trying
to
actually
put
that
into
a
document,
because
at
this
point
actually
trying
the
document
so
that
we're
not,
as
you
say,
editing
the
first
element
in
the
discussion.
All
the
time
is
it's
maybe
time
it's
maybe.
G
C
All
right,
I'm
wondering,
as
far
as
the
you
you're
saying
that
we
could
have
paragraphs
for
the
roles.
But
what
are
the
roles?
If
we're
going
to
have
that,
then
we
could
have
a
list.
C
Moving
to
a
document,
that's
possible
sounds
like
we
may
need
to
maybe
the
interest
on
moving
forward
on
this
discussion
here
and
so
now.
People
are
wanting
to
have
a
something
that
we
can
update
quicker.
So
a
google,
a
google,
doc
or
whatever
might
be
easier,
but
it
seems
like
we
still
need
roles
so
that,
like
what
is
what
are
these
roles
that
we're
talking
about.
G
Well,
I
mean
the
ones
I've
been
working
with
are
effectively
the
operator
who
is
actually
running
a
cnf
day-to-day
the
network,
architect
who's
deciding
and
describing
how
the
cnf
fits
into
their
network
long
before
it's
actually
implemented
the
cnf
developer,
who's
actually
making
a
runnable
cnf
the
platform
developer,
who's,
making
the
kubernetes
that
the
cnf
is
running
on,
whether
that's
enhancing
that
kubernetes
or
deploying
it
both
of
those
really.
G
You
know
the
piece
of
software
that
the
operator
is
going
to
use
and
I
think
the
system
integrator
because
there's
a
whole
bunch
about
how
this
is
configured
and
poached
and
prodded.
When
it's
running
where
you
can
arguably
say
it's
a
system,
integration
task,
because
you
know
you
do
it
for
the
operator
lays
hands
on
it
and
you
continue
to
do
it
while
the
operator
is
using
it
to
make
their
job
easier.
G
So
those
are
the
roles
I'd
stick
with
and
then
try
and
you
know,
there's
a
question
of
which
companies
do
those
roles
live
in
and
how
strong
are
the
lines
of
communications
with
them,
which
is
you
know.
You
could
provide
example
context
and
whether
or
not
they
look
at
things
with
different
perspectives,
like
you
know,
the
the
cnf
operator
needs
to
satisfy
the
security
requirements
of
their
customers.
G
C
G
A
Cool
taylor-
I
guess
now
that
you're
sharing
screen
can
you
just
go
back
to
the
agenda
doc.
A
A
Okay,
so
we
have
about
eight
minutes
left,
so
I
guess
we
might
not
have
a
full
discussion
on
these
last
couple
issues,
but
I
definitely
want
to
get
to
them.
I
know
there's
kind
of
two
ones.
Actually
I
think
I'll
skip
over
this
one
for
right
now.
I
know
I
saw
reuben
was
on
the
call
and
he
made
this
polar
cross
dance
to
read
me
reuben.
Do
you
want
to
just
quickly
just
like
walk
through
this.
H
H
If
my
wording
is
not
english
completely
perfect,
some
other
people
can
turn
that
out
better
than
me,
but
I
hope
you
understand,
you
understand
the
content,
so
it's
just
about
speaking
first
about
life
cycle
management
for
cnf
operators
and
then
giving
an
example,
because
there's
I
felt
is
more
to
it
than
just
deploy
and
management.
I
mean
config
management,
upgrades
deployments,
remove
it
and
I
could
think
of
tons
of
other
things.
That's
all.
A
Yeah,
thank
you.
This
is
great.
I
guess.
Are
there
any
comments
on
this
pull
request?
I
don't
know
if
lisa
is
also
adding
saying
she
likes
the
addition
of
life
cycle
management.
A
I
know
this
just
came
in
four
hours
ago,
so
I
wouldn't
merge
this
day,
but
I'm
happy
to
like
approve
this,
but
I
just
want
to
make
sure
other
people
have
time
to
comment
on
it
too.
If
that
makes
sense
for
you
reuben.
A
Yeah,
thank
you
for
that
full
request,
though,
so
I'm
gonna
leave
this
open
for
another
week,
just
that
people
have
time
to
look
at
it
and
if
you
have
things
you
want
to
add,
the
pull
request
is
here.
A
The
other
thing
that
we
have
is
cnf
candidates
for
assessment.
I
know
there's
just
some
comments
here.
If
anybody
one
idea
was
to
start
with,
if
we
are
gonna,
have
those
like
use
cases
to
actually
pull
down
some
cnfs
and
see
what
the
problems
are,
and
so,
if
anybody
has
any
ideas
who
would
be
interested
in
providing
a
cnf
to
see
what
the
potential
like
use
cases
are
and
what
best
practice
practices
we
can
pull
from
them?
A
And
then
so
we
have
about
five
minutes
left,
so
I
just
wanted
to
touch
on
a
couple
last
things.
So
last
week
we
announced
we
are
going
to
be
looking
for
chairs
for
the
working
group.
Very
soon
we
were
supposed
to
have
the
governance
pr,
because
at
cncf
we
really
believe
in
open
governance
having
the
governance
pr
ready
for
this
meeting,
but
unfortunately
we
didn't
quite
get
it
there,
but
it
will
be
at
some
point
this
week.
A
C
Bill,
let
me
let
me
add
to
that
a
little
bit
so
the
main,
the
just
like
all
the
rest
of
the
stuff
that
we've
been
talking
is
iterative
process.
So
we,
the
charter,
exists
right
now
we
have
some
information,
of
course,
already
in
the
charter.
The
governance
section
is
empty
practically,
so
that
the
parts
that
we're
going
to
be
adding
into
there
are
starting
with
what
are
roles.
What
are
the
different
roles
within
the
governance
portion,
so
we'll
be
adding
to
that?
C
That's
the
first
thing:
that's
going
to
be
built
created
based
on
what
exists
in
existing
cnf,
cncf,
sigs
and
working
groups.
So
if
you
go
and
look
at
the
toc
sig
formation
roles,
where
you
go
look
at
some
of
the
other
sigs,
it's
based
on
that
and
we'll
be
pulling
from
those
to
create.
What's
what
we're
going
to
be
using
and
then
the
the
other
part
is
about
the
pr
process
around
elections.
A
Yeah
thanks
taylor
and
then
the
last
thing
on
the
agenda
is
maybe
taylor.
Do
you
want
to
give
a
two-minute
summary
of
what
happened
in
the
tug
meeting
and
kind
of
the
discussion
there.
C
C
I
would
say
I'll
just
say
all
the
rest
of
the
cncf
telecom
and
networking
focus
efforts
that
we've
been
doing
and
that
was
there's.
We
really
came
to
a
decision
that
there's
two
main
parts.
One
was
finding
the
problem
statement
around
the
networking
and
orchestration,
and
what
are
we
trying
to
do?
There
gap
analysis,
other
things
and
how
does
that
fit?
C
And
then
looking
for
potential
solutions
that
are
there
right
now
and
presenting
those
so
presentation
of
solutions
and
other
things
we're
going
to
have
a
follow-up
for
a
project
called
eno
on
the
next
telco
music
group,
probably
before
next
month,
potentially,
and
then
the
problem
analysis
and
putting
forward
those
is
going
to
move
into
a
discussion
topic,
probably
a
new
one
and
then
maybe
become
some
documents
in
the
cnf
working
group.
So
we're
going
to
continue
to
move
forward
and
on
that
because
it
is
related
to
multiple
groups.