►
From YouTube: CNCF CNF WG Meeting - 2020-12-07
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,
great
it's
about
five.
After
so
I
think
we
can
get
started
today.
So
thanks
everybody
for
coming
to
the
cnf
working
group
meeting.
This
is
not
the
meeting
you're
expected.
Please
feel
free
to
jump
out
right
now.
The
other
thing
this
session
is
being
recorded.
So
just
be
aware:
if
you
come
like
voice
something
or
say
something
on
camera,
it
will
be
on
youtube
after
this.
A
So
the
link
to
the
meeting
notes
are
in
the
chat,
please
feel
free
to
add
your
name,
so
we
can
know
who's
discussing
things
today.
So
the
first
thing
I
just
want
to
point
out
again.
This
is
a
new
working
group,
so
we
do
have
an
overview
deck
for
anybody.
A
Point
out-
or
I
guess,
on
the
overview,
some
of
the
peop-
some
people
were
on
the
cncf
telecom
user
group.
So
the
tug
call
right
before
this-
and
just
in
case
you
weren't
on
that
there's
is
a
difference
between
the
two
groups.
The
talk
is
going
to
be
more
of
an
industry-wide
discussion
on
broader
topics
of
challenges
facing
the
industry
and
have
more
like
white
papers
coming
out
of
that.
A
Well,
this
group
is
kind
of
more
focused
on
a
narrow
set
of
problems
and
trying
to
accomplish
something
more
in
the
short
term
and
like
have
results
around
some
specific
issues
outlined
in
our
charter,
and
we
will
be
kind
of
having
a
discussion
about
that
later
with
the
presentation
from
frederick-
and
I
believe
he's
on
the
call
so
jumping
off
of
that,
if
you
haven't,
if
you're,
not
in
the
cnf
working
group,
slack
channel
on
the
cncf
slack
you're
really
missing
out,
it's
been
extremely
active
over
the
past
week,
and
so
thank
you
for
everybody,
that's
contributing
to
the
discussion.
A
A
The
second
part
thank
you
to
swisscom
and
deutsche
telekom
for
adding
their
interest
to
the
charter.
Please
feel
free
to
add
this
to
the
charter,
to
add
your
company
as
interested
to
the
charter.
Now
why
this
is
important
is
because,
as
we're
trying
to
set
up
like
a
formal
governance
under
the
cncf,
we
need
to
know
who,
like
the
interested
parties.
So
then
we,
when
we
go
before
the
technical
oversight
committee,
we
can
show
them
that
there
are
enough
parties
interested
in
this
and
who
those
parties
are.
A
A
We've
changed
a
lot
of
the
wording
to
best
practices
rather
than
saying
conformance,
and
so
thanks
taylor
for
making
that
change
more
details
in
the
merge,
github
issue
or
get
help
pull
requests,
and
the
second
part
is
adding
into
the
charter
providing
a
list
of
cloud-native
benefits
as
a
best
pack
practice
provides.
So
that's
another
thing.
That's
been
added
into
the
charter
right.
This
is
an
open
source
community.
A
So,
if
there's
anything
that
you'd
like
to
add,
please
feel
free
to
open
a
pull
request
or
open
an
issue
against
the
charter
or
anything
in
the
repo.
A
With
that
taylor,
do
you
want
to
talk
a
little
bit
about
the
tug
and
cnf
working
group
roles?
I
saw
that
you
just
added
that
I
don't
think
I
added
that
okay,
so
somebody
else
did
okay,
so.
B
But
I
mean
it's
good,
I
mean
so
that
you
kind
of
went
over
it
at
the
start,
and
I
the
the
main
thing
is:
we
want
to
both
have
a
place
where
we
can
have
more
open
discussions
to
cover
as
much
and
as
many
concerns
that
service
providers
and
vendors
and
everybody
in
the
telco
domain
and
kubernetes
can
come
together
and
and
then
we
also
want
to
make
sure
that
we
have
a
a
place
where
people
can
come
together
and
know
that
we're
moving
forward
on
on
something
that
has
been
decided.
B
So
there's
kind
of
two
audiences,
and
I
think
daniel
bernay,
from
bell
canada
and
vuk
from
douche
telecom
have
both
kind
of
talked
about
this
and
the
cnf
work
group.
The
audience
for
the
cnf
and
the
cnf
group
slack
channel
the
audience
that
we're
looking
at
for
the
cnf
working
group
are
people
that
are
already
wanting
to
adopt
cloud
native
and,
let's
say
kubernetes
based
platforms
and
technologies
and
really
looking
to
say.
How
can
we
most
efficiently
use
these?
B
Yet
maybe
it's
something
that
isn't
covered
yet
in
kubernetes,
but
it's
a
need
within
the
telco
industry,
or
maybe
there's
so
many
options
that
there
hasn't
really
been
consensus
within
the
community
about
those
things
or
alternatives
that
just
maybe
don't
even
look
like
anything,
that's
there
yet.
So
that's
really
what
the
telecom
user
group's
about
and
the
presentation
today
for
those
that
didn't
see
it.
B
One
of
the
main
items
was
something
that
jeffrey
salence
was
talking
about
the
telco
drivers
and
concerns,
so
we're
hoping
to
go
ahead
and
resurface,
a
white
paper
that
he
started
last
year
and
gather
that
information.
So
this
is
a
lot
of
the
questions
that
people
have
put
in.
What
are
our
motivations?
Why
are
we
putting
stuff
about
kubernetes
best
practices
for
cns
like?
Why
are
we
talking
about
this?
If
we
don't
know
the
motivations
and
that's
when
we
put
the
little
benefits
in
the
the
scope
for
the
charter?
B
We
added
that,
but
we
don't
want
it
to
be
the
main
focus
within
the
cnf
work
group.
We're
not
trying
to
say
is
this
relevant
at
all.
The
cnf
working
group
is
actually
the
place
where
people
go.
We
know
it's
relevant
help
us
to
actually
find
the
best
ways
to
utilize
these
here's,
a
specific
network
function
that
we're
using
and
we're
trying
to
figure
out
the
best
way
that
we
can
manage
it.
B
The
life
cycle
management
and
those
sort
of
things
in
the
telecom
user
group,
though
we
can
go
deep
into
those
drivers
and
all
the
y's
and
source
that
information
as
it
becomes
available
into
the
work,
the
cnf
working
group
as
well
as
other
groups.
So
I'm
the
test
suite
itself,
I
mean
being
able
to
have
more
context
the
f
test,
but
another
initiative
can
utilize
any
of
those
things,
as
well
as
other
groups
like
aniket,
with
the
reference
architecture
and
reference
implementation
that
they're
doing
on
kubernetes,
and
so
I'm
hope.
B
B
Yeah
thanks
I'd
like
to
open
for
feedback
to
bill
and
try
to
see
if,
if
anyone
has
any
thoughts
or
discussions
around
this,
like
roles
and
scope
that
we're
talking
about
for
the
cnf
working
group-
and
you
may
bill
want
to
even
bring
up
the
charter
itself
for
those
who
haven't
looked
at
it
lately,
so
that
we
can
see
what
is
the
new
version
based
on
all
the
different
updates.
B
C
Hi
taylor,
it's
tommy
how
you
doing,
I
think,
looking
at
the
slack
over
the
past
few
days,
the
biggest
query
that
seems
to
be
in
people's
minds
is:
where
do
we
write
down
the
business
requirements?
C
And
I
think
it
would
be
it'd
be
good
if
there's
a
kind
of
an
agreement,
understanding
whatever
as
to
which
of
the
three
communities
that
level
of
thing
needs
to
land,
because
I
think
it
would
it
would.
It
wouldn't
be
sub-optimal
to
try
and
write
it
down
in
each
community
and
and
so
it'd
be
interesting
people's
opinion
on
which
community
that
would
be
a
good
place
to
source
that
information.
B
All
right:
well,
I
guess
there's
there's
kind
of
two
parts
to
it
that
I
I'm
saying.
Probably
the
telcom
user
group
is
a
place
to
have
business
requirements
that
are
available
for
any
different
group
or
community,
including
those
outside
of
cncf,
and
make
it
available
to
anybody
so
telco
business
requirements
and
then
specifically
for
the
cnf
working
group.
B
If
you
look
at
the
the
best
practice
proposals
which
thanks
bill
for
bringing
them
up
so
the
best
practice
proposals,
one
of
the
things
that's
in
the
template,
what
we're
expecting
is
for
people
to
provide
references
and
motivation
behind
stuff.
So
if
you
sh,
if
you're
proposing
here,
is
a
best
practice
that
we
think
a
cnf
would
be
good
to
follow.
B
That's
all
we're
saying,
with
these
best
practices,
they're
not
going
to
apply
to
every
cnf,
because
not
everything
is
going
to
be
implementable,
but
for
the
ones
that
are
here's
ideally
a
way
that
the
app
the
telco
application
being
developed
can
best
utilize
and
consume
the
capabilities
and
services
within
kubernetes,
and
one
of
the
things
that
they
should
have
in
the
proposal
is
what
are
the
underlying
business
driver,
and
it
may
be
that
so
this
is
the
the
one
part
that
may
be
a
little
off
from
what
you
were
saying
tom.
B
Ideally
it
would
be
in
one
place.
I
don't
think
that's
ever
gonna
fully
be
the
case
especially
distributed
and
everything
else
group.
And
what
could
happen,
though,
is
you
may
end
up
where
someone
is
working
on
a
proposal
and
they're
thinking
about
existing
application
and
starting
to
talk
about?
How
would
this
be
done
following
best
practices
for
kubernetes
like
a
kubernetes
native,
and
they
may
come
up
with
that
business
requirement?
B
D
D
One
thing
I
want
to
like
throw
into
the
mix
too
is
the
vast
majority
of
us,
and
we've
talked
about
it
from,
like
the
you
know,
csp
perspective
right,
like
telcos,
cable
providers,
internet
service
providers,
but
I
think
long
term,
just
network
operators
in
general
are
gonna
care
about
this
stuff.
So
my
personal
opinion
is
is
within
the
tug.
D
I
would
like
people
like
you
bernier,
et
cetera,
to
help
me
get
telco
specific
business
requirements
that
we
would
then
push
into
this
group
and
say
this
is
what
we're
hoping
to
get
out
of
here,
because
what
I'm
worried
about
is
if
we
were
to
build
them
say
in
here,
then
it's
going
to
become
which
we've
seen
we've
been
really
notoriously
bad
at
doing
this
in
lfn
is
the
telcos
come
in
and
we
shove
our
paradigm
down
everybody's
throat
and
then
the
bank
of
americas
of
the
world.
D
You
know
the
disney's,
the
cokes
that,
like
run
massive
massive
networks,
are
trying
to
you
know
figure
stuff
out.
Additionally,
to
you,
it's
been
brought
up
by
multiple
people,
myself
included
that
we're
hoping
to
get
some
of
the
big
public
cloud
providers
in
here,
and
I
would
really
like
to
see
some
of
their
requirements
pop
up
into
some
of
these
individual
proposals.
D
But
I
know
I've
been
the
biggest
one
harping
on.
We
need
to
design
the
requirements.
I
want
requirements
and
I
specifically
the
selfish
part
of
me-
wants
telco
cable,
specific
requirements,
so
it
doesn't
necessarily
have
to
be
the
tug,
but
I
would
like
us,
as
providers
to
go
into
one
of
the
forums,
that's
specifically
geared
towards
us
for
us
to
capture
our
requirements
and
then
push
those
into
some
of
these.
You
know
more
cross-organizational,
cross-domain
teams,
so
that
way
our
voice
is
heard,
but
we're
also
not
drowning
out.
E
So
hello
guys
this
is
robbie,
so
I
think
requirement
may
be
an
an
overused
term,
so
I
do
understand
that
requirements
can
come
from
the
cncf
user
group.
I
know
there
are
some
requirements
coming
from
the
cnt
before
and
there's
certainly
a
few
requirements
in
there,
but
maybe
what
we
really
need
here
is
kind
of
principles
that
we
know
are
very
important
and
maybe
trying
to
understand
what
are
the
principle
foundations
that
will
make
this
work
important,
not
necessarily
frame
it
as
a
business
requirement
or
a
technical
requirement.
F
If
you've
got,
I
mean
that
is,
you
might
just
be
right.
That
requirement
is
an
overused
word,
but
you
know
a
requirement
is
really
is
theoretically
here
a
thing
that
you
need
in
order
to
be
successful.
So
you
know
what
you're
calling
a
principle
in
in
traditional
software
engineering.
We
would
call
a
requirement.
I
think.
D
The
big
thing
is,
is
I
want
to
know
what
we're
using
to
measure
stuff
if
we
go
out
and
make
the
bold
claim
as
a
group
of
collaborators,
that
this
is
a
best
practice?
How
did
we
validate
and
measure
that
best
practice
to
say
it
is
actually
better
than
what
we
had
before
that
it
does
do
something
that
we
needed
to
do
and
that
we're
not
just
doing
it
because
we're
a
bunch
of
nerds
who,
like
to
geek
out
on
you,
know
cool
linux,
deck.
G
So
so
this
is
suctive,
so
isn't
that
something
which
cnpp
is
doing
so
in
ra
2,
they
are
defining
the
requirement
in
ri
2.
They
are
implementing
them
and
rc2.
They
are
actually
testing
for
conformance
against
these
requirements.
So
so
all
of
that
is
being
discussed
so
and
and
they
do
work
with
cncf
tug.
So
why
do
we
need
to
redo
all
of
that
here?
G
Why
not
take
it
work
in
conjunction
with
cntt,
ra2
and
and
and
see,
what's
missing
what
and
that's
strictly
being
driven
by
telcos
and
and
why
not
bring
other
players
like
you
mentioned,
jeff
the
cloud
providers
and
and
the
bank
of
americas
and
whatnot
in
there
and
see,
look
at
it
what
what
what
pieces
are
missing
and
rather
than
re
redoing?
G
All
of
that
here
take
what's
there
and
then
figure
it
out
what's
missing
and
what
we
need
to
do
here
so
rather
than
re
resetting
everything
I
mean
this
is
crazy,
that
every
other
year
or
every
year
we
just
fork
off
a
new
group
and
just
for
fun
of
it.
We
start
all
over
again.
There's
no
point
in
doing
that,
and
so
so
why
not
we
look
at
it
has.
Is
everybody
here
familiar
with
cntt
ra2
and
have
they
looked
at
it?
G
C
B
Yeah,
so,
let's
be
honest,
let
me
address.
Let
me
try
to
address
this
directly,
because
this
has
come
up
several
times
before,
and
it's
also
it's
not
just.
If
we
look
at
the
cnt
or
anakit
work,
it's
also
other
groups.
This
can
come
up
again.
So
why
are
we
creating
something
new?
That's
the
question
and
I
wish
daniel
was
on
here
because
he
said
this
I
mentioned
again.
I
don't.
I
don't
think
you
saw
this
book.
B
B
There's
other
groups
out
there
that
are
that
are
doing
stuff
outside
of
life
as
well,
but
cncf
is
focused
on
on
a
specific
type
of
audience,
those
that
are
wanting
to
adopt
the
philosophies
and
methodologies
that
are
behind
cloud
native
so
and
specifically
the
ones
if
you
look
at
cncf
or
self
in
see,
cncf
is
about
showing
and
highlighting
various
options.
You
could
think
of
it
more
all
a
cart.
You
can
go
in
and
say
here's
how
they
fit
together
and
try
to
promote
interoperability
between
them,
but
they're
not
being
opinionated.
B
Lfn
is
for
an
audience
that
says
we
need
something.
We
want
prefer
something.
That's
opinionated.
We
want
something.
Also,
that's
maybe
a
little
bit
it's
going
to
be
more
focused
on
supporting
integration
between
different
groups
outside
in
philosophies.
B
B
That's
not
going
to
be
what
you
would
look
at
if
you,
if
something
came
out
of
a
totally
different
group
out
of
lf,
you
have
other
groups
that
are
coming
up
with
other
platforms
and
ideas
which
may
be
very
useful
for
a
service
provider
and
vendors
may
say
this
fits
our
our
model.
So
the
cncf
and
specifically
the
cnf
working
group,
is
trying
to
provide
something.
That's
following
the
philosophies
that
are
within
the
kubernetes
and
cloud
native
community
and
that
fits
the
best
the
most
efficiently
to
kubernetes.
B
That's
not
going
to
be
a
match
to
what
comes
out
of
cnt,
so
there
should
be
by
the
way
they
are
two
options,
because
there
are
two
different
audiences
that
they're
both
trying
to
talk
to.
Can
I.
B
I
I
am
struggling
a
bit
like
to
to
reconcile
the
things
between
the
starting
point
where
we
discussed
about
the
conformance
or
idea
of
achieving
certain
framework
of
conformance
testing,
where
we
can
prove
different
types
of
cnfs
if
they
are
conformed
to
something
that
we
are
hopefully
about
to
agree
as
a
cloud
native
and
the
discussion
with
the
with
the
best
practices.
So,
let's
say
the
biggest
interest
or
biggest
value
that
we
could
see
out
of
such
working
group.
I
Even
recommendations
for
the
conformance
that
would
make
a
cnf's
work
in
in
a
kubernetes
in
a
native
unopinionated
or
a
very
little
opinionated
kubernetes
as
a
value
for
us,
so
that
that
would
be.
That
would
be
something
where
we
hoped:
okay,
as
a
telecommuter
who
is
deploying
their
own
upstream
base
kubernetes,
we
will
not
be
in
a
constant
struggle
with
different
vendors
who
are
preferring
opinionated
setups.
I
J
Yeah,
I
think
that
this
is
frederick,
but
by
the
way,
so
I
think
part
of
what
we
need
to
look
at
as
well
is
separate
out
some
of
the
some
of
the
layers,
because
there's
the
concept
like
from
what
actor
you're
coming
from
what
what
type
of
thing
that
you
want
to
do.
So,
if
you're,
a
consumer
you're,
not
a
telecom
but
you're
you're,
a
consumer
of
this
world,
you're
likely
not
going
to
care
about
like.
Is
it
a
cnf,
a
vmf?
J
Do
you
care
that
there's
an
api
that
it
meets
certain
both
functional
and
non-functional
requirements,
and
you
can
call
it
and
consume
it
in
an
explicit
way.
J
As
the
operator
of
this
you
care
very
much
about
how
this
thing
is,
is
ran
and
operated,
and
one
of
the
problems
that's
been
expressed
by
multiple
by
multiple
operators
is
that
you
have
a
very
rich
set
of
things
underneath
of
you
that
you
need
to
control
and
manage,
and
how
do
you
produce
this
environment?
That
is
that
you're
not
you're,
not
you're,
minimizing
as
much
complexity
and
trying
to
give
something?
J
That's
a
little
bit
more
uniform
to
to
basically
run
a
command
and
control
over
your
over
your
infrastructure
when,
if
you're,
the
vendor,
there's
two
type
at
least
two
types
of
vendors,
major
ones
that
we've
seen
the
first
one
is
from
an
infrastructure
provider.
How
do
I
build
an
infrastructure
that
you
can
run
these
things
on
following
a
common
set
of
rules
which
cntt
is
very
heavily
focused
on,
among
others,
and
the
final
portion
of
that
is
like
you're,
a
vendor
of
a
cnf?
J
How
do
you
deploy
into
into
a
cnf
infrastructure,
environment,
and
so
part
of
the
problem
that
we
ran
into?
Is
that
we've
had
we've
tried
to
focus
on
too
much
in
many
of
these
groups
rather
than
saying?
Okay,
what
are
some
of
these
things
at
this
core
and
then?
How
do
we
get
these
communities
to
interact
with
each
other?
J
Because
then,
what
ends
up
happening
is
that
whoever
has
a
loudest
voice
in
if
you,
if,
if
in
the
larger
community,
ends
up
being
the
primary
speaker
at
the
expense
at
the
expense
of
others.
So,
by
providing
a
smaller
forum
that
we
can
say,
okay,
like
what
are
the
best
practices
of
running
in
a
in
a
kubernetes
environment,
and
that
doesn't
mean
that
openstack
is
any
less
important
or
pnf's
are
any
less
important.
J
J
How
do
we
get
something
to
to
say
like
this
is
how
to
how
to
op
how
to
operate
it
in
kubernetes
and
then
we'll
we'll
work
out
and
share
this
information
from
best
practices,
and
it
doesn't
mean
that
you
have
to
follow
these
these
rules
exactly
the
market
will
decide
what
works
and
what
doesn't,
what
is
important
or
not
important,
but
to
be
able
to
say
these
are
the
best
practices
you
need
in
order
to
in
order
to
move
forward.
J
So
those
are
some
of
my
thoughts
that
I
that
I
have
certainly
they're.
I
know
they'll
be
insufficient,
so
I'm
hoping
that
others
can
help
fill
in
or
tell
me
where,
where
I
am,
where
I'm
wrong
as
well.
I
I
I'll
just
maybe
two
more
minutes,
try
to
get
it
or
to
throw
it
in
the
round.
F
I
More
pragmatic
and
then
the
round
could
decide.
Is
it
something
relevant
for
this
working
group
or
maybe
just
half
away
relevant?
I
The
thing
is,
as
we
are
working
with
the
many
many
application
developers,
vendors
of
cnfs,
like
ericssons
nokias,
mavenieres
cisco's
of
the
world,
many
other
smaller
ones.
I
We
are
getting
now
to
situation
that
everybody
has
something
like
a
cold
cloud
native
or,
let's
say
containerized
applications,
network
functions
of
different
kinds,
but
each
one
has
has
a
caveat
yeah.
But
the
best
way
to
run
this
platform
or
to
this
application
is,
if
you
take
nokia
what
they
call
cast
container
as
a
service
or
kubernetes,
essentially
platform,
or
if
you
take
eric
zones
or
if
you
take
this
one
or
if
you
take
that
one
and
then
as
an
operator
who
runs
dozens
of
network
functions.
I
You're
facing
the
situation
that
you
have
a
cloud
native
platform
on
one
side,
you
have
a
a
huge
scale
that
public
cloud
providers
are
achieving
and
having
only
one
type
of
let's
say,
parametrizable
and
configurable
platform,
and
then
you
cannot
use
that
because
simply
the
cnfs
are
using
patterns
and
developments
and
practices
that
they
tied.
You
into
certain
very
opinionated
frame,
which
I
believe
is
nothing
that's
efficient
for
for
the
future.
I
So
what
we
are
looking
kind
of
to
get
is,
could
we
establish
one
basic
foundation,
cloud
native
upstream,
based
that
every
cloud
native
network
function
can
be
conformed
to
and
can
work
better
or
worse.
F
I
C
I
Different
type
of
understanding
what
cloud
native
is,
but
it
always
goes
in
a
very,
very
opinionated
directions,
and
then
you
can
have
a
cloud
native
platform
per
net
for
function,
probably
or
per
network
function
vendor
in
order
to
make
it
work.
So
that's
what
I
wanted
to
try
to
draw
as
a
business
problem
as
a
business
requirement.
We
want
to
have
a
one
platform
that
is,
you
know,
cloud
native
enough,
flexible
enough
to
cover
multiple
network
functions
running
on
the
scene.
F
So,
but
I
I
think,
that's
because
you're
getting
exactly
what
you
ask
for,
but
you're
not
asking
for
what
you
want
cloud
native,
we're
using
it
to
mean
a
lot
of
different
things,
but
applications
are
cloud.
F
Native
platforms
are
not
cloud
native
and
these
applications
are,
you
know,
designed
to
be
run
on
a
cloud
in
that
sense,
they're
cloud
native
and
you're
asking
them
to
you
know,
apply
or
align
with
a
bunch
of
rules
like,
for
instance,
immutability,
which
they
absolutely
do,
which
is
what
your
vendors
are
telling
you,
but
what
you
actually
want
is
something
that's
consumable
in
your
devops
environment,
that
aspect
of
cloud
native.
The
thing
that
you
see
from
the
outside
of
the
cnf,
not
the
are
these
containers
designed
and
run
by.
F
You
know
orchestrated
in
a
way
that
would
suggest
their
cloud
native,
because,
ultimately,
that
doesn't
matter
to
you
so
much
it
matters
that
you
can
consume
the
result
that
it
aligns
with
continuous
testing
and
then
automatic
deployment.
F
At
no
point
will
you
find
a
cloud
native
definition
that
says
must
deploy
with
one
api
call
or
one
click,
although
it's
a
perfectly
reasonable
thing
to
want
and
ask
for-
and
it
is,
you
know,
strongly
aligned
with
cloud
native
principles,
but
I
think
that
is
what
you
want.
F
If
I
understand
what
you're
saying
and
that's
why
I
keep
saying
I
want
to
bring
this
back
to
audiences,
because
we
want
to
assign
why
we're
doing
something
to
a
group
that
cares
and
a
lot
of
cloud
native
principles
are
designed
so
that
the
group
that
cares
is
the
developer
of
an
application,
because
kubernetes
itself
is
very
application:
developer
centric,
it's
trying
to
make
applications
easy
to
develop
because
a
lot
of
people
use
kubernetes,
develop
applications
that
they
then
run.
F
That's
not
the
model
we're
on
here
we're
on
a
model
here
where
we've
got
service
providers
in
particular,
are
most
focused,
I'm
not
saying
they're
exclusively
focused
but
they're
most
focused
on
operating
an
environment
including
cns,
and
on
making
sure
those
cnfs
can
be
architected
to
within
their
network.
F
The
development
side
of
things
is
more
on
the
vendor
side
of
things
not
exclusively
again,
but
vendors
are
more
interested
in
making
sure
that
cloud
native
development
principles
which
typically
apply
to
application
developers,
are
helping
them
and
that
they
can
police
their
development
teams
to
ensure
that
where
a
cloud-native
development
principle
is
significant
enough,
they
want
to
ensure
it's
present.
So
the
thing
about
audiences,
I
think,
is
that
it's
not
just
one-sided.
F
We
have
actually
about
three,
maybe
four
audiences,
if
you
consider
what
the
platform
must
provide
to
allow
a
cnf
to
get
its
job
done,
and
if
we
have
those
four
audiences
I'll
be
representing
all
of
them
properly
and
or.
Alternatively,
if
we're
saying
this
is
done
in
the
tug
or
if
we're
saying
this
has
been
done
in
the
cncf
do
either
of
the
sets
of
requirements.
There
have
a
justification
that
says
this
is
the
audience
that
cares,
and
this
is
why
they
care.
J
You
know
one
other
one.
Other
point
of
context
as
well
is
that
we
have
to
realize
that
by
running
on
top
of
kubernetes
and
part
of
the
reason
for
the
best
practice,
this
year
is
also
to
determine
what
gaps
are
there
in
running
in
this
space,
and
we
have
to
consider
the
the
ecosystem
at
large,
so
kubernetes
does
not
run
in
a
vacuum.
J
It's
certainly
not
a
telecom
only
thing
so
the
majority
of
use
cases
of
kubernetes
is
relatively
small
clusters,
the
small
to
medium-sized
clusters
in
the
enterprise
space
and
so
any
any
gaps
that
we
find
any
changes.
We
have
to
be
thoughtful
of
those
communities
because,
if
we're
not,
then
any
proposals
we
make
are
going
to
be
squashed,
and
so
in
the
process
of
navigating
that
we
also
have
this
larger
ecosystem.
B
Yeah,
I
think
I
think
we're
starting
to
now
potentially
overuse
the
word
audience.
So
I
don't
know
what
should
be
there
instead
or
an
an
additional
one.
B
An
actor
okay,
so
frederick
you,
you
had
some
slides
about
that
that
uses
actor
too.
So
the
actors
that
sounds
fine
and
then
whether
the
other
part
is
within
the
actors
or
the
roles,
those
type
of
people,
the
personas,
whatever
you're
going
to
then
have
people
that
have
maybe
different
preferences.
B
So
you
can
have
someone
that's
on
an
ops
team,
but
they
don't
care
anything
at
all
about
cloud
native,
maybe
they're
doing
embedded
software
or
some
I
don't
know
whatever
it
is
you're
doing
an
ops
team
on
a
submarine
and
not
following
anything
about
agile
or
devops.
They
don't
care
so
there's
the
persona
or
actor
and
then
what's
important
to
narrow
down
is
what
is
the
cnf
working
group?
It's
not
or
the
tag
or
what
is
it
in
cncf
or
elephant
or
any
of
those?
B
There's
we
care
from
you
could
say
from
hardware
all
the
way
up,
it
doesn't
mean
it's
always
covered
at
all.
There
can
be
gaps
all
over,
but
you
care
about
how
they
could
be
layered
up
for
sure
from
the
what
we,
the
kubernetes
infra
and
each
layer
up,
above
as
they
integrate
within
the
cnf
working
group
that
the
comments
earlier
were
about.
How
do
we
have
something
and
frederick?
You
were
talking
a
little
bit
about
this?
How
do
we
move
something
forward
that
we
do
agree
to
for
that
subset
of
actors?
B
That
say
we
want
something:
we've
we've
decided
we
do
want
to
utilize.
Kubernetes
we're
not
trying
to
bit
bought
in
those
discussions
are
happening
in
the
tug
or
somewhere
else.
We
are
now
at
a
point
where
we're
trying
to
see
how
do
we
best
utilize
these
for
our
telco
concerns
as
a
ops
team
as
a
a
developer,
as
whatever
the
you
know
you
you
have
four
different
audiences
in
and
I
think
are:
actors
and
frederick
you
have
a
few
as
well.
Whatever
you
are.
B
That's
what
we're
currently
looking
at
is
a
focus
point,
and
it
could.
I
think
it
will
expand
beyond
application
and
probably
get
into
infrastructure
within
the
scenic
work
group,
but
wanting
a
starting
point
so
that
we
can
focus,
it
doesn't
mean
we
don't
need
the
drivers,
it
doesn't
mean
that
we
don't
want
the
general
purpose.
B
A
Yeah,
so
I
think
that
no
so
I
I
think
frederick
has
a
presentation.
That'll,
as
jeffrey
said,
I
think
we're
like
spiraling
a
little
bit.
That'll
help
us
like
focus
the
discussion.
So
frederick,
are
you
on
the
on
the
call
and
would
be
willing
to
share
the
slides
that
you
prepped
sure
so.
A
J
J
Okay,
so
my
the
thing
I
wanted
to
focus
on
specifically
is:
if
we
have
the
charter,
what
is
a?
What
is
a
model
that
can
that
we
can
build
underneath
of
that
charter
and
what
can
we
carve
out?
We
want
to
start
off
with
something:
that's
that's
relatively
small,
and
that
doesn't
mean
it's
the
only
thing
we
focus
on,
but
it's
the
first
small
thing
that
I
propose
that
we
that
we
try
to
focus
on
and
so
back
onto
the
problem.
Scope.
J
We've
spoken
a
lot
about
this,
so
I
won't
spend
too
much
time
I,
but
I
will
say
this
earlier:
models
focus
primarily
on
what
is
a.
F
J
J
We
do
want
to
take
into
consideration
on
whether
we
are
following
cloud
native
to
the
best
of
our
understanding,
because
there's
no
single
definition,
that's
that's
really
ever
settled,
but
at
the
same
time
we
we
don't
want
to
spiral
down
the
philosophical
example
of
or
the
philosophical
question
of
what
it
what
is
cloud
native.
J
Instead,
I
think
we
should
look
at.
Let's
add
a
few
questions.
What
are
we
really
trying
to
do
with
a
focus
on
val
on
value
there,
and
also
the
question
is
value
value
for
who-
and
these
are
things
that
we
can
explore
as
as
we
move
forward
a
couple
straw,
man
things
to
consider
in
that
is:
there's
there's
a
push
for
automation
and
automation
means
that
you're
able
to
do
things
like
auto,
healing
you're
able
to
to
auto
provision
auto
replace
things.
J
J
A
firewall
from
a
certain
vendor,
it
could
be
like
cisco
or
poland
or
palo
alto,
and
you
want
to
you
want
to
change
to
the
other
yeah.
What
what
is
this?
What
are
we
thinking
about?
Scalability?
In
fact,
the
scalability
even
a
an
issue
is
that
something
we
want
to
focus
focus
on,
and
I
try
to
tie
these
down
to
values
now.
The
assumption
that
I
think
we're
making
here
as
a
community
is
that
most
of
these
costs
are
driven
by
opex.
J
This
is
something
very
important
to
consider
as
well,
because
if
the
costs
are
optics,
then
we're
going
to
take
a
specific
approach,
but
if
most
of
the
costs
we're
trying
to
reduce
are
capex,
then
we
have
a
very
different
set
of
conversations
that
we
need
to
have,
and
so
one
of
the
things
to
ask
yourself
is
is:
are
we
focusing
on
the
right
things
from
a
financial
perspective
and
how
do
we
reduce
complexity
in
the
running
infrastructure
and
value
for
who?
Because
in
the
best
case,
the
value
chain
benefits
everyone?
J
It
should
not
be
a
push
and
pull
against
like
operator
versus
vendor
versus
versus
the
company.
That
comes
in
who's
contracted
to
manage.
It
needs
to
be
something
that
is,
that
is
that
the
value
add
for
for
all
and
for
the
best
chance
for
for
these
efforts
to
succeed,
and
if
we're
not
seeing
value
for
everyone,
then
we
really
should
ask
what
can
we
do
to
to
bring
that
in?
But
again,
many
of
these
questions
are
not
for
here,
but
they're
things
to
consider
because
they
can
derail
such
such
efforts.
J
So,
let's
separate
out,
how
do
I
consume
from
the
operational
details
and
so
a
few
actors
that
we
can
look
at
and
these
these
may
be
too
many
or
too
little
things.
So
these
are
more
some
of
the
things
we
have
to
look
at,
but
we
have
the
group
who's
going
to
consume
it.
We
have
the
cms
vendor
or
the
ob,
the
cnf
operator,
again
repeat
those
same
things
on
the
cnf
infra
side,
who
provides
the
infra
who
operates
the
infra
and
what
other
actors
are
there
as
well?
J
There's,
certainly
some
like
there'll
be
some
in
terms
of
perhaps
storage
or
others
that
we
can
eventually
consider.
But,
but
I
think,
if
we
focus
on
on
these
ones
as
an
initial
set,
then
that
may
help
us
form
some
of
our
some
of
our
opinions
and
the
the
thing
that
I
think
we
should
focus
as
a
community.
These
are
all
important
questions,
but
I
think
the
one
we
should
focus
on
the
community
primarily
is
around.
J
What
is
what
does
it
mean
to
be
a
cnf
in
kubernetes?
How
do
I?
How
do
I
build
and
deploy
something?
What
are
best
practices
and
the
reason
I'm
not
saying
the
others
are
not
important
questions,
but
very
specifically,
we
start.
We
start
here
with
informed
by
how
do
I,
how
do
I
operate
this
particular
system,
and
this
gives
us
the
it
gives
us
something
small
that
we
can,
that
we
can
produce
in
a
relatively
short
amount
of
time
to
help
us
gain
that
momentum,
because
that
this
is.
J
This
is
like
what
I
what
I
tell
my
my
kid,
who
is
around
as
a
young
teenager
and
one
of
the
things
that
she
that
that
I
tell
her
is
that
the
reason
that
you're
doing
all
of
your
things
here
with
school,
even
though
it's
easy,
is
to
develop
good
work
habits
to
develop
good
and
what
we
need
to
develop
now
is
good
community
habits
so
that
when
we
get
into
the
harder
problems,
we're
in
this
process
of
of
collaboration
and
with
a
very
pragmatic
view
on
how
do
we
solve
the
problem
at
large
we're
all
going
to
have
different
opinions?
J
J
And
what
and
what
can
we
improve,
providing
this
information
as
if
you
want
to
run
a
if
you
want
to
run
a
cnf
on
kubernetes
or
a
network
function
on
kubernetes
to
be
more
exact?
These
are
the
these
are
the
type
of
things
that
you
may
run
into.
You
may
need
to
expose
certain
pieces
of
hardware
into
it
in
a
specific
way.
J
There's
gaps
around
pneuma
alignment
that
are
still
being
resolved.
What
can
you
do
about
it
today?
What
do
you
expect?
What
do
we
expect
for?
It
to
be
able
to
do
about
it
tomorrow
and
to
focus
on
best
practices
where,
if
you
do
a
lift
and
shift,
then
these
are
the
problems
you're
going
to
run
into.
If
you,
if
you
redesign
your
architecture,
to
be
horizontally,
scalable
and
to
run
in
a
container
then
and
to
provide
information
to
kubernetes
so
that
they
can
orchestrate
you,
then
what
what
benefits
do?
J
J
If
you
were
to
follow
best
practices,
you
can
deviate
at
your
at
your
own
risk,
but
at
least
at
least
understand
what
the
best
practices
are,
and
you
can
make
an
informed
decision
so
that
so
you're
not
deviating
out
of
out
of
not
knowing
and
the
purpose
of
it
is-
is
to
accelerate
the
is
to
accelerate
the
space
and
then
in
time
we
can
expand
this
out.
Like
one
of
the
big
question
is:
where
do
we
draw
the
line
between
application,
orchestration
versus
infrared,
orchestration
and
I'll
use?
J
An
example
enterprise
example
that
if
you
install
the
test,
the
test
will
run
around
the
underlying
pods
for
your
system,
but
the
test
itself
will
actually
run
the
orchestration
of
mysql
itself
and
so
there's
there's
an
infrastructure
versus
application.
J
There's
certain
things
that
only
only
the
application
can
know
how
to
do,
because
we're
application
specific
and
we
have
to
define
where
that
particular
line
is
and
make
it
make
it
very
clear
rather
than
saying
kubernetes
will
orchestrate
everything
for
you,
because
it
clearly
won't
there's
also
questions
in
terms
of
what
do
we
want
to
do
about
about
multi,
multiple
vendors
on
on
the
same
infrastructure
or
type
of
infrastructure.
So
how
do
we?
How
do
we
set
this
thing
up?
J
So
they
have
a
more
uniform
composer,
so
they're
composable,
and
that
they're
they're
consumable
again
from
a
best
practices
perspective,
and
it's
not
clear
that
there's
a
best
practice.
That's
that's
fully
surfaced
yet,
so
we
may
end
up
having
to
publish
multiple
things
on
this
space,
but
and
identify
that
that
is
a
gap
and
and
future
things
that
we
can
work
towards
it.
J
And
how
do
I
ensure
that
they're
compatible
with
each
other?
The
litmus
test
could
be
swap
out
one
vendor
for
another,
with
a
vision
towards
zero
touch
automation.
J
So
in
many
of
these
things
we
can
push
into
the
cnf
testbed,
which
already
exists
today,
and
that
could
be
an
initial
focus
to
help
codify
and
test
some
of
the
best
practices
and
in
so.
In
short,
those
are
some
of
my
some
of
the
thoughts
that
I
that
I
have.
I
don't
have
anything
else
in
these
particular
documents,
but
I
want
to
put
this
as
an
as
an
initial
framework.
E
I
have
actually
one
comment.
I
think
I
completely
agree
with
the
conclusion
few
slides
now.
The
one
thing
that
I
wonder
about,
since
we
are
trying
to
define
the
actors,
which
is
you
have
a
slide
who
says
number
five.
I
think
who
are
the
actors
and
the
problem?
I
see
here
that
we're
trying
to
find
define
the
questions
in
their
behalf.
So
maybe
one
approach
we
can
do
is
once
we
define
the
actor.
Let's
ask
them,
let's
ask
them:
what
is
the
main
pinpoint
they
would
like
us
to
solve?
E
It
might
be
worth
doing
a
survey
targeting
only
those
actors
that
we're
trying
to
target
and
ask
them
really.
What
are
the
three
pin
points
you
find
that
we
can
help
you
solve
and
this
way
actually
we
can
create
a
roadmap
for
this
group
by
trying
to
really
do
it
in
a
way,
that's
serving
the
customer
themselves.
The
audience
for
this
work.
J
Yeah,
I
completely
agree
with
that
as
well,
and-
and
I
I
put
I
had-
I
wanted
to
have
some
continuity
in
the
slides.
But
if,
if
you
look
at
this,
like
nobody
really
wants,
that's
like
something
like
this
sorry
iov
like
you,
you
want
it
from
an
implementation
detail,
but
what
the
cons,
what
the
customer
really
wants
is
a
faster
system
or
connection
into
a
very
specific
system
or
additional
properties
are
being
added
in
by
their
top
of
rack
switch.
J
They
don't
really
care
about
the
actual
mechanism
itself,
and
so
so
I
think,
like
how
do
I
consume
this
particular
thing
versus
some
of
the
operational
details
that
we
there's
there's
things
that
we
can
that
will
need
to
to
to
work
out
with
that,
and
I
think
when
we
start
asking
some
of
these
types
of
questions
like
some
of
these
type
of
differences
or
challenges
to
our
assumptions,
will
will
pop
out-
and,
I
think,
doing
some
type
of
a
survey
of
each
of
these
types
of
groups
like
if
you're
a
cnn
offender,
what
what?
J
What
are
your?
What
are
you
trying
to
do
like?
What
is
your
value
proposition?
Why
are
you
doing
this?
What
are
your
pain
points?
We
can
come
up
with
a
variety
of
different
questions
too,
to
ask
to
help
us
inform
these
type
of
these
type
of
things
and
as
we
and
and
these
ones,
we
shouldn't
like
these.
J
Some
of
these
particular
questions
there's
different
forms
of
this
question,
depending
on
where
you
come
from
as
well
like
if
you're
a
cnf
vendor
and
you're
saying
how
do
I
consume
the
network
versus
you're,
a
customer
and
you're
saying
how
do
I
consume
a
network
service,
the
two
very,
very
different
things,
even
though
it's
the
same
question,
even
though
it's
the
same
words
in
the.
L
So
I
I
think
you
know
the
question
that
this
slide
provokes
in
my
mind,
is
is:
does
it
make
sense.
L
To
perhaps
have
either
different
subgroups
or
have
even
different
work
groups
as
a
right.
I
I
think
I
think
I
I
keep
thinking
that
we're.
We've
got
to
the
point
of
audiences
and
and
actors.
We
have
different
people
who
want
different
things
out
of
this
work
group
and
that's
why
we
keep
getting
stymied
on
the
charter
and
to
me,
this
slide
really
crystallizes
that
and
I'm
wondering
if
it
might
make
more
sense
to
to
reformulate
what
exactly
we're
trying
to
do
in
these.
J
Terms
yeah,
it
may
make
sense
one
of
the
things
that-
and
this
is
one
of
the
challenges
that
we
have
as
well,
is
in
in
the
past,
and
I'll
put
it
very
bluntly,
because
I
I
the
risk
and
these
pieces
do
not.
No,
no
one
be
offended
by
this
specific
thing.
J
I
want
to
be
very
clear,
because
this
is
that
this
highlights
a
problem
when
you
look
at
the
ratio
of
of
different
groups
that
are
here
like
we
still
don't
have
very
many
cmf
vendors,
there's
still
very
small
numbers,
a
very
small
number
of
them,
because
the
infrastructures
has
not
been
ready
for
them
to
really
build
and
deploy
on.
J
It
gets
their
opinions
heard,
but
at
the
same
time
we
don't
establish
it
in
a
way
that
that
overwhelms
any
any
of
the
single
actors,
especially
if
those
actors
are
are
smaller
in
number,
and
so
that's
something
that
we
have
to
be
very,
very
careful
with
in
how
we
how
we
organize
these
particular
these
picture
paths
and
different
a
different
working
set
of
subgroups
could
help
with
that,
but
there's
also
the
risk
that
they
become
isolated.
J
So
if
we
take
that
approach,
we
need
to
make
sure
that
that
we
have
somewhere,
that
the
work
groups
meet
together
on
a
regular
basis
to
to
describe
the
high
level
things
they're
doing
and
to
make
sure
that
that
all
parties
are
heard.
M
So
I
think
you
really
did
a
good
job
at
underlying
the
issue
here,
because
in
the
end,
we
we
list
all
these
actors,
but
we're
going
to
be
dictating
or
guiding
the
cnf
vendors
in,
particularly
in
particular,
so
they're
a
little
bit
cornered
in
in
the
way
where
we're
building
things
right.
Now.
If,
if
I
join
the
brainstorming,
maybe
I
have
one
suggestion
of
a
way
out
of
this
is
instead
of
thinking
about
the
individual
actors,
the
maybe
the
scope
of
this
work
group
can
be
specifically
on
integration.
M
That
is,
our
job
is
not
to
tell
anybody
how
to
build
a
cnf,
but
rather
to
integrate
all
these
various
actors
together
and
make
sure
that
they
have
ways
that
the
operator,
the
vendor
the
platform
provider,
that
everybody
can
work
together
in
the
best
possible
way.
L
I
was
getting
at
when
it
came
to
you
know.
You
know:
we've
sort
of
danced
around
the
idea
with
best
practices,
which
is
unfortunately
not
terribly
concrete
and
hard
to
action.
You
know
we.
You
talked
earlier
about
vendor
lock-in
and,
as
I,
as
I
mentioned
earlier
in
the
in
the
chat,
you
may
not
have
seen
it
fred
because
you
were,
you
were
presenting
the
fun.
L
What
what
what
vendor
lock-in
is
really
a
proxy
for
is
the
challenge
of
integrating
new
things
and
the
general
challenge
of
interoperability,
and
I
think
that's
what
what
tal
was
just
pointing
at
as
well
and
also
what
this
slide
really
gets
at,
and
so
I
think
that
that
tall
is
is
right
and
and
again,
I
really
think
this
slide
crystallizes.
L
You
know
what
we're
all
really
struggling
with
they're
they're
separate
but
related
things
that
build
on
each
other
and
fundamentally,
when
it
comes
back
to
is
how
do
we
integrate
and
how
do
we
ensure
interoperability
and
if
we
can,
if
we
can
focus
on,
I
think
from
that
lens,
as
opposed
to
you
know,
how
do
you,
you
know
the
specifics
of
how
something
is
built
or
something
like
that.
I
think
that
that
that
gets
to
what
everybody
really
needs
here.
B
Yeah
yeah,
so
I
want
to
make
sure
we
close
here
and
then
we
can
we'll
for
sure
next
week
planning
on
and
having
a
call.
I
think,
the
week
after
we
may
have
two
gap
weeks
and
then
in
january
we
may
go
to
a
twice
a
month.
Type
of
call
the
I
think
the
focus
right
now
is
going
to
be
what
you've
presented,
though
frederick
at
and
that's
where
the
charter
and
everything
else
has
kind
of
gone
to.
It's,
not
that
we
may
not
expand
later.
B
We
can
always
adjust,
but
looking
towards
something
more
actionable,
I
think,
is
going
to
be
easier
if
we
have
a
narrower
focus.
B
So
this
what
you're,
calling
cube
native
or
kubernetes
native
is
implementations
of
the
cloud
native,
and
I
I
think,
as
far
as
the
testability
that's
going
to
be
part
of
the
proposals,
so
there's
a
if,
if
anyone's
interested
in
trying
to
help
with
this,
that
would
probably
be
one
of
the
first
areas
trying
to
take
an
idea
like
I,
I
posted
one
in
zoom,
the
about
containers
dropping
root
privileges
which
is
actually
part
of
the
open
shift
guidelines.
B
If
you
look
at
those
guidelines
so
coming
to
something
and
then
giving
references
on
why
this
is
a
practice,
how
it
can
be
testable,
that's
part
of
it
why
it's
valuable
to
telcos!
That's
where
we
want
to
center
the
discussions
and
then
come
back
and
go
okay.
Is
this
actually
something
that
is
going
to
solve
a
telcos
problem?
Is
this
something
that's
going
to
benefit
a
vendor
because
they
can
get
something
to
market
faster,
whatever?
What?
What
are
the
drivers
all
around
that?
B
That's
where
we
want
to
start
centering
on
putting
forward
those,
whether
it's
a
simple
idea
or
something
existing
that
you
go
and
and
and
looking
at
the
docs,
but
I
think
otherwise.
We
need
to
continue
with
this
conversation,
and
maybe
some
news
actually
view
some
of
the
proposed
best
practices
for
next
week.
B
So
I
I
want
to
maybe
finish
with
one
words
that
someone
on
the
call
early
in
this
call
said
it
was
about.
Is
that
the
best
practice
or
the
requirement
or
whatever
you're
looking
at,
however,
we're
going
to
call
this?
Does
it?
Is
it
worse
or
better?
That's
what
we're
talking
about
in
this
most
of
them,
I
don't
think,
will
be
requirements
for.
B
If
you
look
at
jeffrey
said,
the
service
providers
are
going
to
have
different
stacks,
so
they
will
come
up
with
the
requirements
and
work
with
each
vendor,
but
that's
going
to
be
a
selection,
hopefully
of
if
we
have
best
practices
are
useful.
They
can
select
what
they
want.
A
la
carte.
What
we're
going
to
allow
help
is,
are
you
doing
something?
That's
worse
or
better?