►
From YouTube: CNCF CNF WG Meeting - 2021-03-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).
B
Okay,
I
think
we
can
probably
get
started
now.
So
thanks
everybody
for
joining
this
is
the
cnf
working
group.
We
meet
every
monday
at
1600.
Utc
talk
about
cloud
native
network
functions
before
we
dive
into
the
agenda
today.
Is
there
anything
that
anyone
would
like
to.
B
B
Okay
hearing
nothing,
I
think
we
can
probably
jump
right
in
so.
The
first
thing
on
the
agenda
today
is
the
use
case
template
that
look
put
together.
So
I
saw
him
on
the
call
earlier-
and
I
know
there's
still
quite
a
few
comments
around
this.
But
does
anybody
want
to
kind
of
talk
through
this,
or
does
anybody
have
comments
or
look?
Is
there
anything
you'd
like
to
say.
C
The
template
for
the
use
case
was
supposed
to
be
informative
about
the
use
case,
practical
use
case
that
should
serve
as
a
basis
for
for
extracting
or
recognizing
or
discussing
some
best
practices
that
we
wanna
finally
end
up
with,
and
I
try
to
put
actually
the
template
together
in
a
way
to
to
serve
this
purpose
of
informing
who
are
the
actors
or
personas
or
roles
in
this
use
case.
What
do
they
want
to
achieve
agnostically
of
technology?
C
B
Yes,
actually
have
one
question,
so
I
see
here
that
you
put
it
in
the
like
the
ccdp
like
folder.
Now
it's
actually
wondering
if
it
would
be
better
to
put
it
in
the
use
case
folder.
B
C
You're
right,
it
was
my
omission.
Actually
I
overlooked
when
was
creating
a
pull
request,
so
I
think
I
made
another
commit
in
the
in
a
fork
that
I'm
not
sure
I
need
to
to
create
additional
merge
requests
for
that
to
to
end
up
in
the
in
the
main
repo.
C
So
we
could
do
it
either
by
me,
correcting
that
and
pushing
another
creating
another
pull
request
or
approving
that,
and
then
I
make
a
correction
with
additional
pull
requests
there.
C
Correct
but
I'll
I'll
look
at
that
and
we'll
correct
it
we'll
reach
out
to
you.
If
I
have
some
blocking
points.
D
You
should
be
able
to
modify
on
your
own
side
in
your
own,
and
you
may
need
to
do
a
a
merge,
because
I
see
that
your
branch
is,
it
might
be
behind.
C
You
know
not
in
the
user,
in
the
github
interface
you'll
need
to
clone
it
and
to
do
it.
D
E
B
Okay,
yeah,
the
other
thing
I
wanted
to
chat
about
just
to
hear
like
other
people's
opinions,
so
just
because
this
also
goes
into
like
an
issue
that
we
have
open
right
now.
B
It's
like
this
involved
parties
section
and
there's
kind
of
like
a
discussion
whether
this
should
be
defined
in
this
section
or
should
it
reference
out
to
like
a
separate
documentation,
yeah
and
so
the
related
issue
in
case
people
are
interesting,
is
issue
number
54
of
creating
similar
to
how
we
have
the
use
case
section
and
like
a
like
proposal,
section
also
creating
like
an
actors
section
and
look
correct
me
if
I'm
wrong,
but
you
said,
like
people
should
go
in
here
and
define
that
like
in
the
use
case,
whereas
some
other
people
are
asking
like
for
it
to
be
defined
in
a
separate
document.
C
So
we
could,
I
was
really
thinking
about
what
would
be
the
most
or
easiest
and
the
most
meaningful
way
for
people
who
are
writing
the
use
cases
to
do
that.
So
if
we
define
it
in
a
sense
of
foreign
key
and
say
here
are
the
you
know
you
need
to
hear
in
this
template
pick
one
or
more
of
the
roles
that
are
defined
in
another
document.
C
It
might
be
for
some
people
who
are
writing
that
additional
burden
to
look
and
say
okay,
which
persona
which
actor
is
there
and
if
there
is
no
actor
that
he
wanted
to
do
it.
He
will
need
to
ask
to
extend
that
other
document.
So
I
settled
down
on
leaving
it
a
bit
more
freestyle,
because
it's
the
information
that
we
will
extract
later
on
in
the
best
practices
and
we'll
map
it
to
real
personas
or
actors
there,
but
I'm
also
not
very
much
fixed
into
whether
it's
like
this
or
or
open.
C
So
the
idea
is
for
for
the
the
chapter
describing
the
the
parties.
I
think
I
wrongly
used
the
word
party
didn't
mean
parties,
but
the
different
hats
that
people
have
or
different
personas
to
actually
summarize,
who
are
the
human
participants
in
this
use
case
and
then
what
do
they
want?
What
are
their
needs
and
then
in
the
next
stage
which
system
components
are
involved
in
that
use
case,
and
then
how
do
they
behave?
A
This
is
watson,
I'm
seeing
it
seems
like
people
are
using
the
phrase,
use
case
and
user
story
almost
interchangeably,
and
I'm
wondering-
and
we
and
I've
seen
in
here
that
we're
saying
that
we're
going
to
have
a
requirement
for
use
case,
not
a
requirement
for
you,
the
story.
It's
wondering
what
people
are
thinking
about
that,
just
as
an
aside,
they
use
a
story
as
a
a
lower
barrier
to
entry
than
the
use
case
like
if
we're
going
to
say
people.
If
they're
going
to
submit
a
principle,
they
need
to
point
to
something.
A
The
use
case
has
a
higher
threshold,
but
yeah,
I
don't
know
if
anyone
else
has
seen
that.
B
Yeah,
I
was
actually
gonna
bring
that
up
later,
because
we
do
kind
of
have
like
another
issue
open
where
we
have
where
we
talked
about
like
creating
use
user
stories.
And
obviously
this
pull
request
is
around
the
use
case.
Because
that's
how
we
originally
defined
the
issue-
and
I
I
guess
maybe
that's
a
open
discussion
like
we
prefer-
to
have
user
stories
or
use
cases
and
yeah.
G
A
Yeah
and
it's
important
here
because
we're
starting
to
say
one
of
something's
required
so
we're
saying
that
use
cases
required
their
use
cases
have
more
information
in
them
than
user
stories.
Normally.
So,
if
we're
going
to
go,
buy
like
a
iver
jack
of
our
jacobson's
definition
use
case
so.
C
How
I
reasoned
about
the
use
case?
It
is
something
that's
very
practical
and
that's
kind
of
mine
to
to
mind
the
best
practices
out
of
it
to
trigger
the
discussion,
so
real
life
stories
from
different
angles,
who
are
saying
hey
here,
is
my
my
situation.
This
is
how
I
think
it
should
work,
and
then
this
should
enable
me
if
I
move
to
the
cloud
native
net
world
and
cloud
native
network
function.
F
I
think
that's
yeah,
I
I'm
not
sure
that's
true.
If
you
look
at
the
the
the
use
case
that
I
put
in
the
other
day
the
other
week,
it's
specifically
a
use
case
because
it
says
I
need
a
tool
to
do
a
job.
F
A
user
story
would
theoretically
describe
the
job,
but
the
problem
with
user
stories
is
you
don't
really
want
somebody
to
be
describing
their
their
situation
as
regards
you
know
how
they're
going
to
make
money
out
of
their
customers?
It
gets
complicated
so
that
bgp
use
case
actually
works
quite
well
as
a
use
case.
I
want
bgp
and
it's
reasonably
self-evident
why
you
might
want
bgp,
a
user
story
and
there's
one.
F
I've
got
in
motion
that
I'm
trying
to
well
actually
make
look
like
you
use
the
story,
because
it's
got
altogether
too
much
in
the
way
of
opinion
in
it
at
the
moment
would
basically
say
in
this
instance,
it's
gonna
say
I
want
to
install
a
cnf
on
my
network.
What's
it
gonna,
what
are
people
going
to
want
to
do
in
the
process
of
doing
that?
F
D
I
mean
we're
talking
around
the
questions
so
that
I
think
one
of
the
questions
was
do
we
want
to
require
one
and
which
is
it
or
both
we
could
say
this
is
requirements
and
specifically
for
best
practices.
So
when
you're
proposing
a
best
practice,
what
is
required?
They
are
two
different
things.
I
don't
think
there's
any
disagreement
on
that
and
then
which,
if
any
of
them
are.
F
E
C
F
I
think
that's
the
problem
with
these
terms
is
we're
not
100
consistent,
how
we
define
them,
because
what
you're
calling
a
use
case?
I
would
call
that
I
find
I've
been
tainted
by
rally.
I
would
call
an
epic
which
is
another
form
of
user
story
with
a
broad
scope,
but
the
the
reason
I'm
distinguishing
in
my
head
use
case
doesn't
necessarily
involve
actors.
It
involves
more
about
functionality.
I
am
trying
to
do
this
thing
and
this
tool
would
help
me
to
do
it,
or
there
is
a
thing
I
won't
be
able.
F
B
C
Anchored
in
the
in
the
real
life
that
this
is
really
an
essence
that
we
need
to
bring
out
of
either
user
story
or
use
case
or
or
whatever,
so
that
we
can,
when
somebody
proposes
something,
be
able
to
discuss
around
it,
to
understand
why
it
is
so.
Is
it
like
real
case?
Is
it
maybe
a
theoretical
case?
C
Is
it
a
very
broad
case
happening
everywhere
or
very
focused
niche
one,
and
then
out
of
that
derive
understanding
of
what
should
be
done
in
order
to
make
things
a
better
in
the
cloud-native
sense,
and
this
last
piece
is
best
practice
actually,
which
I
mentioned.
C
B
C
B
D
I
guess,
with
the
talk,
the
confusion
on
use
cases
and
user
story,
my
gut
feel
on
it
is
that
we
should
have
two
different
templates
and
ideally
not
only
a
template,
but
if
we
can
point
to
two
examples
that
people
go
yeah,
that's
a
good
user
story.
I
understand
why
that's
a
user
story
and
then
the
same
for
the
use
case.
F
My
suspicion
here
is
that,
while
vox
stuff
is
useful
at
the
moment,
it's
the
answer
is
before
we
commit
it.
We
try
and
use
it
to
see
how
well
it's
working
and
then
we
can
adapt
it
to
what
does
actually
work
when
we
try
and
put
real
information
in
or
alternatively,
we
just
commit
it,
and
we
say
here
is
a
work
to
example.
Try
this
it's
not
mandatory
that
you
use
this,
but
we
recommend
this
as
a
as
a
starting
point.
F
It
depends
on
what
we're
trying
to
do
here.
Are
we
trying
to
tell
people
they
must
comply
with
this
template,
or
are
we
trying
to
tell
people
that
if
they
use
something
like
this
template,
their
job
will
be
easier.
C
F
Yeah,
I
think
I
I
certainly
agree
with
that.
I
think
we
all
do
actually.
I
I
think
we
have
consensus,
so
I'm
fine
with
that,
but
on
this
particular
document.
Yes,
so
we
for
best
practices.
We
need,
you
know,
context,
use
cases
for
use
cases.
F
F
But
if
we
attempt
to
write
a
few
more
use
cases,
I
wonder
whether
we
could
do
a
better
job
of
that,
because
we'll
see
where
it
turns
out,
they
do
need
information
and
where
it
turns
out,
they
don't
and
then
you'd
have,
rather
than
as
basically
arguing
somewhat
academically
about
what
would
be
good
and
what
would
be
bad.
We
could
say
you
know
this
is
what
would
work
best
for
us,
because
now
we've
got
a
little
bit
practice.
We've
got
our
hands
dirty.
C
Well,
actually,
I
had
in
mind
to
write
one
or
two
use
cases,
but
I
put
that
on
hold
until
we
discuss
the
template
and
not
not
to
write
something
and
then
the
temp
according
to
template,
and
there
is
a
lot
of
other
ideas.
C
So
I
can
certainly
proceed
with
that
and
maybe
if
somebody
else
would
volunteer
and
proceed
with
the
additional
one,
maybe
following
partially
or
fully
the
template
and
then
exactly
what
you
said:
jan
get
the
hands
dirty
and
then
simply
say:
okay,
we
we
had
this
struggle
with
this
template
or
we
couldn't
fit
this
or
that
and
then
we
adopted
it.
D
Doesn't
or
the
I'll
say,
the
update
to
the
readme
doesn't
say:
use
of
the
template
is
required.
D
It's
not
we're
not
demanding
that.
So
the
template
is
to
help
people.
If
you
have
no
idea
what
you're
doing,
I
guess
for
building
a
use
case
or
try
to
provide
answers
to
questions,
so
I'm
not
opposed
I'll
say
to
moving
forward
on
merging
something
just
so
if
people
wanna,
if
they
wanna,
build
a
use
case,
and
they
have
a
lot
of
content,
they
don't
know
how
to
format
it,
and
this
helps
them.
Then
that
would
be
fine
too.
We
can
always
go
back.
D
One
thing
that
I
would
suggest
is
if
we
can
link
out
to
references
for
stan
the
standard
definitions
for
use
cases
and
user
stories
would
probably
be
good,
maybe
at
the
top
of
or
somewhere
in
here,
so
that
we're
not
you
know
we
don't
have
to
come
up
with
our
own
thing.
These
are
old
terms
and
there's
probably
a
lot
of
templates.
B
Yeah,
I
guess
so
also
randy
put
in
the
comments
plus
one
for
committing
now
and
perfecting
later,
I
guess
maybe
my
suggestion
is.
It
sounds
like
both
looking
in,
like
both
have
like
use
cases
that
they
like
are
considering
writing
up.
B
Maybe
I
propose
like
try
using
this
template
and
come
back
like
next
week
and
if
you
don't
have
any
like
major
issues,
we
say
like
this
is
our
first
first
draft
of
the
template,
and
this
is
what
we're
going
with
for
now,
but
obviously
it's
completely
open
to
be
perfecting
later.
You
know
we
can
always
change
things.
This
isn't
just
a
static
document
that
keeps
on
living.
So
I
think
maybe
we
yes,
we
try
it
out.
B
F
Yeah,
I
think
I
would
go
a
step
further
than
that.
I
would
say
if
at
any
point
in
the
week,
we
think
this
template
is
good
enough.
If
it
hangs
together
in
itself
consistent,
then
you
know,
if
everybody's
happy,
we
can
get
it
in
as
well.
There's
no
need
for
it
to
be
perfect.
It's
sitting
in
review
forever
is
not
helping
us.
It
just
gives
us
somewhere
to
kind
of
needle
work
and
basically
point
out
all
the
shortcomings
of
the
document.
F
That's
not
helping,
so
you
know
I
think,
there's
a
I
don't
know
how
many
comments
really
do
sort
of
point
to
strong
need
for
change,
but
if
we
go
through
that,
I
think
we
could
probably
have
this
ready
for.
Certainly
next
week
and
possibly
in
the
week.
D
Main
item
to
address
out
of
this
that
there
didn't
seem
to
be
big
disagreement.
It
was
about
the
actors
or
personas
or
whatever
you
want
to
call
them
the
roles
and
being
able
to
break
that
out.
F
Well,
if
we
got
nowhere
else
to
budget
right
now,
then
why
don't
we
put
it
in
here
and
then
break
it
out
in
a
separate
commit
which
is
a
you
know
and
then
find
the
actor
list
will
be,
maybe
not
our
perfectly
considered
opinion,
but
again,
if
this
is
a
place
to
start
with
the
use
case,
that's
fine
and
then
we
we
can
put
more
consideration
into
that
active
list
and
then
just
refer
it
out
when
we,
when
we
put
the
actualist
committee.
D
Okay,
so
if
you
had
comments
and
this
pr
that
you're
asking
for
changes,
then
go
back
and.
B
C
Like
they're,
just
for
formatting
they're,
not
visible
in
the,
if
you
view
file
go
to
view
file
in
the
three
dots
up,
yeah,
not
there.
Three
dots.
E
C
C
C
C
E
B
Great
then,
I
guess
this
kind
of
discussion
goes
into
the
next
one
about
like
user
stories,
and
I
guess
this
issue
is
like
there
should
be
user
stories
too.
I
guess
my
question
was:
do
we
want
to
close
this?
Do
you
want
to
have
a
separate
thing,
and
it
sounds
like
kind
of
from
the
previous
discussion
is
that
we
see
user
stories
as
like
a
different
way
to
justify
a
best
practice,
so
we
should
have
use
cases
and
also
user
stories.
So
we
should
leave
this
issue
open
for
right.
F
B
B
And
then
this
this
next
issue,
too,
is
also
the
issue
for
defining
the
actors
and
their
roles.
But,
as
we
said
before,
this
is
going
to
be
in
a
letter
pr.
B
F
That
I
think
taylor's
got
a
proposal
and
I've
had
some
thoughts
on
this.
So
if
we
take
it
together
and
we
can
have
a
proposal,
we
can
put
pull
requests
out.
Okay,
sorry,
taylor,
I'm
volunteering!
You
who
you
alright.
B
Okay,
I'm
going
to
assign
both
of
you
on
the
issue
right
now,.
D
And
luke,
if
you
want
to
review
or
talk
with
us
about
it,
let
us
know.
B
Okay,
great
then,
the
next
thing
is
so.
This
is
after
the
comments
and
discussions.
Last
week
around,
like
the
governance,
we
tried
to
define
things
a
little
bit
more,
so
I
think
there's
some
confusion
about
what
all
the
roles
do
and
what
they
all
mean.
So
we
tried
to
like
write
something,
and
obviously
this
is
I
mean
the
governance
is
up
to
the
groups.
This
isn't
like
how
it
they're
saying
this
is
how
it
is
this
is
we
it
would
be
great
to
have
feedback
on
this,
so
one
is
oops.
B
One
is
around
defining
the
max
representation
so
saying
that
one
company
can't
come
in
and
kind
of
control,
the
whole
control,
the
whole
thing,
and
so
what
this
is
is
one
person
from
any
company
can
hold
a
chair,
roll
and
also
one
third
of
the
tech
leads.
Can
any
can
be
from
one
company
at
a
time,
and
I
think
taylor,
where
did
you
pull
this
from?
Is
this
from
kubernetes.
D
I'm
I
don't
remember,
it
was
a
kubernetes
or
tsc
type
of
thing.
B
E
B
So
I
think
ian
that
should
resolve
your
comments
too.
I
don't.
B
F
See
no
problem
with
your
diffs.
That's
fine!
You've
taken
out
the
reference
to
the
word
committee.
We've
worked
out
what
we're
drawing
people
from,
but
maybe
not
what
they
do
quite
yet,
and
so
that's
fine
we're
solving
them
as
separate
problems.
I
think
it's
good.
I
don't
have
any
problems
with
this.
F
B
I
B
I
I
think
the
other
pr
for
the
voting
does
the
organization
okay.
So
maybe
it.
J
D
I
I
gave
a
link
to
the
it's-
the
kubernetes
steering
committee-
there's
other
ones
too,
but
that
was
one
of
the
main
ones.
I
E
C
B
No,
you
can
you
can
commit
those,
it's
fine
and
then
yeah,
thanks
for
pointing
that
out
and
then
also
related
to.
That
is
around
the
pr
approval
process,
because
I
think
there
is
a
this
wasn't
defined
anywhere.
So
this
is.
B
I
started
this
as
a
discussion
because
I
didn't
want
to
start
it
as
a
pull
request,
because
I
I
think
this
is
like
open
kind
of
defining
what
each
of
the
roles
do
and
kind
of
like
what
I
don't
want
to
say
power,
but
maybe
responsibility
that
they
have
and
kind
of
the
way
that
I
thought
about.
This
was
kind
of
right.
The
the
lowest
bar
should
be
like
the
easiest.
B
Oh
thanks
for
the
comment.
Yeah
we
can,
if
you
want
to,
you,
can
go
in
and
put
slash
people,
but
I
think
company,
slash
organization
is
as
far
as
I'll
go
today,
but
essentially
so
it's
all
right.
The
the
use
cases
is
the
lowest
kind
of
like,
let's
say
bar
with
one
tech
lead
and
two
community
members.
B
The
charter
updates
is
two
chairs,
one
tech
lead
and
three
community
members
best
practices
is
two
tech
leads,
and
three
community
members
and
kind
of
the
idea
here
is
showing
that,
like
tech,
beads
are
really
important
for
doing
this,
because
they're
the
ones
actually
like
deep
diving
into
this,
and
neither
the
chairs
nor
nor
the
tech
leads
completely.
B
Have
like
the
final
say.
We
want
to
have
community
input
in
everything
that
we
do
so,
while
it's
important
because
they're
helping
kind
of
like
let's
say,
organize
or
like
lead,
the
group
they're-
not
they
don't
have
saying
like
this-
is
how
it
is,
and
this
is
exactly
how
I
do
it,
but
it's
also
driven
by
the
community
too.
So
this.
This
first
idea
I'd
like
to
hear
like
some
thoughts
on
like
these
different
roles
and.
F
I'm
not
sure
that
those
numbers
necessarily
work,
but
on
the
other
hand
I
mean,
if
we've
got
a
group,
then
it
seems
like
a
quorum
and
then
a
majority
would
make
more
sense
for
charter
updates.
But
you
know
conceptually
the
idea
that
we
deal
with
this
in
a
separate
document
and
we
basically
put
thresholds
in
place
seems
perfectly
logical.
J
F
Experience
with
openstack-
I
I
know
it's
anathema
around
here,
but
I'll
just
give
it
as
an
example.
Then
it
would
be
most
pull.
Requests
would
be
approved
by
two
core
developers
agreeing,
and
that
was
maybe
a
little
centralized,
but
it
wasn't.
A
terrible
idea
seems
to
me
that
there's
not
necessarily
the
use
case
and
the
best
practice
side
of
things.
There's
not
necessarily
any
great
value
in
having
them
differ.
A
A
Yeah
this
is
watson
I
was.
I
think
we
should
consider
the
option
of
just
a
veto
power
for
stakeholders
so
for
for,
in
our
case,
service
providers,
so
users
and
the
ability
for
them
to
maybe
have
veto
power
on
their
best
practice.
D
I
would
put,
I
guess
tying
in
with
what
watson
is
saying,
plus,
I
guess
what
both
ian
and
frederick
y'all
were
talking
about
the
complexity,
the
two
things
that
I
think
are
the
most
critical
to
care
about
with
regard
to
getting
approvals
or
the
charter
and
the
best
practices
so
charter.
D
I
think
that
was
probably
easier
to
say.
We
want
to
be
careful
on
on
what
happens
there
and
the
chairs
are
supposed
to
help
with
that
whoever's
elected
or
that's
one
of
their
main
things
is
trying
to
keep
that
moving
forward.
The
best
practice
ties
in
with
stuff
ian
you've
talked
about
and
other
people
the
best
practices.
D
D
A
Yeah,
I
think
my
my
point,
though,
is
there's
a
separation
between
the
kind,
the
person
or
group
that
creates
things
and
then
there's
a
separation
and
then
there's
another
group
that
is
affected
by
those
things
that
are
created.
So
you
could
call
those
second
group
stakeholders
if
you
want,
but
that
second
group
there's
certain
limitations.
They
should
have
on
what
someone's
creating
something.
A
Maybe
the
direction,
maybe
is
probably
not
the
best
place
for
them
to
be.
They
can
create
something
if
they
want,
but
they
shouldn't
be
saying:
oh,
don't
create
this
kind
of
thing,
but
when
it
comes
down
to
saying
oh,
this
is
the
best
for
everyone
and
you're
the
one
consuming
it
that
that
affects
you.
And
so
that's
where
getting
this
state
the
veto
power.
D
A
It
can
be
abstracted
away
from
this
and
put
into
government,
and
things
like
that
who
is
it
that's
affected
by
someone
polluting
the
water?
But
someone
else
is
the
person
that
does
irrigation
or
does
all
these
other
things
with
the
water
they're,
not
necessarily
experts
at
mining
or
managing
water,
but
they
do
want
to
say
no.
You
can't
do
that
in
my
neighborhood
or
my
city
or.
E
A
Yeah,
so
at
the
at
so
having
the
stakeholder
or
in
our
you
know,
in
our
example
the
citizen,
but
you
could
say
service
fighter
whatever
they
don't.
They
aren't
saying,
go
ahead
and
move
around
or
go
ahead,
and
here
are
the
very
specific
kinds
they
don't
have
power
over.
Here
are
the
very
specific
kinds
of
drilling
for
the
example
you're,
seeing
or
very
specific
kinds
of
technology
you're
going
to
use
to
solve
the
problem,
but
they
can
say
that
they
want
to
oh
microservices.
That
is
something
or
microservices.
A
A
A
D
D
Like
a
big
controversial
law-
and
you
talk
about
the
descent,
so
this
dissenting
view,
I'm
just
thinking
of
if,
if
what
you're
saying
so,
the
first
is
you're
saying
veto
power
and
no,
which
means
if,
if
a
best
practice
proposal
is
put
forward-
and
you
have
let's
say
most
of
the
community-
the
cnf
recruit
community
is
like.
Yes,
let's
do
it,
but
you
have
someone
with
veto
power
that
says
no.
D
D
So
a
lot
more
sense.
If
you
had
a
so,
you
now
have
a
role,
so
this
sp
it
could
be
that
we're
saying
this
is
all
going
towards
sps
as
the
end
users
for
the
product
of
the
best
practices,
so
applications
and
infrastructure.
Whatever
is
developed
following
a
set
of
best
practices,
the
sps
are
going
to
consume
that,
and
now
we
have
a
quorum
of
sp
representatives
that
say
no.
We
don't
want
you
all
to
adopt
that.
We
would
prefer
not
to
see
it.
That
would
make
sense.
D
So
we
don't
have
that
role
right
now.
We'd
need
to
figure
that
out,
but
I
it
makes
sense
to
me
which
shane
watson.
D
This
is
about
the
pr
practice
pr
going
in,
so
I'm
not
sure
what
you're
thinking
do
you
have
any
thoughts
on
how
that
would
tie
in
with
this,
or
that
you
could
add
into
the
discussion.
Otherwise,.
H
D
H
Oh
yeah,
just
referring
this,
this
discussion
is
only
focused
on
the
voting
part
like
because
I
guess
we
are
assuming
that
any
pr
has
to
address
all
the
comments
and
doesn't
have
any
glitter
issues,
or
things
like
that.
So
are.
We
are
considered
those
as
part
of
the
approval
process
or
is
just
we're
just
assuming
that
those
are
going
to
be
there
like.
D
We
should
definitely
write
this
down,
so
this
is
only
for
the
approvers.
This
says
approval
process.
What
we
should
it
really
could
be.
The
discussion
is
how
how
many
approvers
do
we
need
in
the
pr
process
before
we
approve
a
emerge?
B
Yeah
this
is
a
good
conversation,
but
I'm
gonna
push
it
to
the
github
discussion
until
next
week
because
it
seems
like
we
still
have
some
more
ideas.
So
I'd
like
to
hear
kind
of
other
people
put
their
thoughts
in
here,
because
I
don't
think
we're
going
to
come
to
a
conclusion
today.
So
it'd
be
great
to
have
some
more
thoughts
in
there,
because
we
only
have
five
minutes
left
for
today.
B
I
just
wanted
to
get
through
kind
of
like
the
last
couple
things
on
the
agenda,
one
of
them
being
the
voting
process.
So
there
is
some
discussion
here,
but
there
hasn't
been
kind
of
anything
since
last
week.
I
just
wanted
to
check
in
if
people
had
had
time
to
look
at
this
if
they
had
any
more
questions
and
things
like
that,
because
I
think
this
is
kind
of
like
an
important
thing,
because
the
elections
are
going
to
be
coming
up
here.
B
B
Okay,
so
four
minutes
left.
I
also
wanted
to
bring
to
everybody's
attention
that
the
self
nomination
period
is
currently
open
and
just
as
a
reminder
in
case,
you
forgot,
there's
also
the
link
to
here
to
nominate
yourself
for
either
a
co-chair
or
a
tech
lead
position.
B
Please
send
the
information
to
the
mailing
list,
we'll
get
it
approved
there
and
so
far
we
do
have
nominations
for
a
co-chair
from
jeffrey
in
the
service
provider
co-chair
from
ian
for
co-chair
in
the
cmf
developer,
co-chair
position
and
also
from
book
for
the
co-chair
or
tech
lead,
so
he's
nominating
himself
for
both.
That
means.
B
We
currently
don't
have
anybody
yet
from
the
kubernetes
community
who's
self-nominated
themselves,
and
we
only
have
one
tech
lead.
So
all
the
conversations
you're
having
earlier
about
the
pr
approval
process
would
be
for
naught
if
you
have
one
tech
lead,
because
none
of
that
cleared
the
bar.
So
I
encourage
people
and
if
you're
interested
please
consider
running-
and
I
know
I've
talked
to
a
couple-
people
who
have
who
were
interested
in
running
and
just
and
just
haven't
submitted
yet.
B
So,
if
you
have
any
questions,
please
feel
free
to
reach
out
to
me
or
taylor
to
chat
about
if
it's
you're
interested
in
yeah
are
there
any
questions
about
the
self
nomination
period?
It
does
end
next
monday.
D
I'd
like
to
propose
extending
that
we've
had
a
bunch
of
questions.
Okay,
trying
to
address
some
confusion,
so
extend
both
of
them
by
at
least
one
week
and
maybe
extend
the
tech.
The
tech
leads.
D
We
had
more
interest
earlier
and
I'm
trying
to
get
some
responses,
especially
on
the
kubernetes
community.
There
was
discussions
before
the
holidays
and
there's
been
some
calls
after
maybe
extend
that
one
a
week
out.
So
it's
staggered.
I
I
must
admit:
I'm
a
bit
confused
about
the
tech
leads,
because
I'm
not
sure
I
I
know
what
the
tech
domains
are,
and
so
every
candidate
kind
of
defines
the
domain
and
then
proposes
themselves
as
the
leader.
But
can
we
try
to
somehow
flesh
out
ideas
for
what
are
the
tech
domains
that
we're
looking
for
leaders
for.
D
D
The
short
would
be.
We
can
have
more
than
one
there's
no
limit
on
the
number
of
tech
leads,
although
probably
everybody
shouldn't
just
go
forward.
The
main
idea
is,
if
there's
an
area
that
you
think
is
that
we
need
to
that's
important
to
focus
on
for
the
cnf
working
group,
and
you
have
time
and
a
passion
to
go
into
it.
D
Then
you
can
put
yourself
forward
for
it.
We
don't
have
to
say
a
specific
domain.
You
may
say
I
want
to
help
with
use
cases
so
that
could
be
general
or
you
could
say
you
want
to
help
with
a
maybe
a
best
practice
area
like
handling
state
in
a
cloud-native
way.
You're
like
I'm
passionate
about
that,
because
we're
building
applications
that
need
to
deal
with
state.
D
So
I
want
to
go
into
that
and
that
could
be
a
focus
area,
but
we're
also
talking
about
nominations
for
both
chairs
and
tech
leads
that
are
going
a
year.
I
believe
is
the
same.
Isn't
it
bill
it's
a
year,
but
which
means
you
may
be
focused
on,
let's
say
cloud
native
state,
because
that's
an
area
that
you
care
about
now,
but
three
months
from
now.
That
may
not
be
the
focus,
but
you
probably
have
multiple
things
that
are
going
to
be
happening.
D
I
B
Yeah
I
mean
actually
maybe
a
good
first
place
to
start
would
actually
be
in
the
oops.
J
B
D
Here
right,
so
those
are
based
on
categories
trying
to
take
a
lot
of
the
coordinated
principles,
breaking
them
into
various
categories,
and
that's
really
what
we're
saying
so
any
anything.
D
If,
if
we
go
from
cloud
native
principles-
and
you
start
going
down
into
an
area,
you
can
be
at
a
higher
level
and
say
security,
I
want
to
I
care
about
anything
security.
Well,
that's
gonna
cover
a
lot
of
things
where
you
could
start
getting
down
and
go
deployment
issues
of
security.
So
it's
whatever
you
want
on
that.
But
definitely
the
cloud
native
principles
would
be
the
first
place
and
I
gave
another
link
fundamental
concepts.
D
That's
I
would
say
even
a
little
bit
higher
than
what
this
is,
but
targeting
cloud-native
principles.
B
So
yeah
so
we'll,
hopefully
send
out
some
information
later
this
week
to
clarify
what
the
different
areas
are
and
then
we'll
also
extend
the
nomination
period
for
a
week,
so
we
are
a
bit
over
so
thanks
everybody
that
could
stay
on
the
line.
I
appreciate
it
unless
anybody
has
anything
else,
I
think
we
can
probably
close
for
today.