►
From YouTube: CNF WG Meeting 2021-04-12
Description
CNF WG Meeting 2021-04-12
A
A
A
Greetings,
if
you
didn't
see
already
the
meeting
notes
and
posting
them
to
the
zoom
chat,
we'll
get
started
in
a
couple
of
minutes
at
five
after
you
can
add
your
name
and
any
agenda
items
to
the
meeting.
A
A
A
If
you
don't
have
any,
if
you
don't
have
access
to
the
google
doc,
it
is
open.
But
if
you
can't
reach
it
because
firewalls
or
whatever
you
can
post
your
name
and
any
topic
that
you'd
like
to
discuss
in
the
zoom
chat
or
in
slack
and
add
that
or
just
speak
it
out
loud.
A
A
B
A
Right
so
the
first
item
here
is
yours,
and
it's
this
use
case
wish
list.
C
Okay
yeah,
so
the
reason
I
put
this
up
is
in
part
because
we've
been
doing
a
lot
of
admin
and
I
thought
it
would
be
useful
to
get
to
the
point
of
what
we're
actually
supposed
to
be
doing,
which
is
use
cases
turning
into
best
practices
via
probably
a
few
design
documents,
and
I
thought
one
way
of
getting
us
moving
on
that
was
basically
to
put
a
wish
list
up
so
that
anyone
who
wanted
to
attack
any
other
problems
had
a
place
to
start
if
they
had
five
minutes
and
they
wanted
to
have
a
go
at
something
and
had
no
no
imagination.
C
So
I'm
not
remotely
suggesting
these
are
all
of
them.
They're,
just
really
the
first
ones
that
came
to
mind.
Anyone
who
has
any
thoughts
on
it,
who,
obviously
I'm
not
going
to
say
no,
would
like
to
take
any
of
them
on
or
would
like
to
add
any
more.
They
think
are
worth
mentioning
to
it
then
now
now's
your
chance
and
I
will
find
a
better
home
than
in
the
meeting
minutes
for.
C
C
Stony
silence:
that's
that's
not
promising
any
any
immediate
thoughts
on
what
I
put
there
or
anything
else
to
say.
D
Point
of
the
wish
list
is
to
kind
of
jump,
start
more
youth
cases
or
is
this?
What
was
the
point.
C
C
Actually,
anybody's
problem
will
do
just
fine.
I
will
take
problems
for
developers
I'll
take
problems
for
anybody,
but
I
mean
basically,
if
we're
going
to
produce
cns
that
do
people
some
good.
Then
they
need
to
be
installed
and
if
they
need
to
be
installed,
then
there
needs
to
be
some
best
practices
that
make
them
installable
and
that's
going
to
be
a
little
confusing,
because
I
think
it's
hard
to
say
what
a
best
practice
is
when
people
haven't
had
too
much
experience
of
this.
C
But
on
the
other
hand,
if
we
work
through
the
problem
but
saying
well,
this
is
precisely
what
you
know
we're
going
to
want
to
do.
I'm
going
to
receive
I'm
going
to
have
development
team,
whether
it's
minor
or
vendors,
I'm
going
to
receive
a
cnf
in
some
form,
I'm
going
to
want
to
spread
it
liberally
around
my
network,
I'm
going
to
want
to
run
it
on
clouds,
which
is
obviously
the
starting
of
a
cnf,
which
is
the
next
phase.
D
For
some
of
these
that
we're
saying
here,
it
seems
like
all
of
the
use
cases
need
to
solve
these
problems
so
install
cns
start.
How
does
cnf
deal
with
the
lifecycle
event,
so
he's
kind
of
saying
that
the
use
case
should
address
well,
it
would
be
nice
if
the
use
case
said
these
are
issues
we
also
want
or
put
a
high
priority
for
them
to
be
solved
in
the
use
case,
yeah
so
separately,.
C
Some
of
these
these
are
use
cases
so
we're
describing
what
somebody
wants
to
do,
and
I
would
expect
one
use
case
per
rather
than
a
use
case
that
describes
all
of
them
and
then
beyond
that.
Obviously,
what
we're
actually
trying
to
deliver
is
best
practices,
so
a
best
practice
is
going
to
be
better
if
it
takes
these
use
cases
into
account,
maybe
it
attacks
one
of
them
specifically
and
doesn't
really
touch
any
of
the
other,
in
which
case
we've
only
got
to
measure
it
against
one.
C
D
Yeah,
so
I'm
looking
at
the
the
sources
so
for
bgp,
it
seems
like
when
they're
just
someone
must
be
describing
their
bgp
problem
type
thing
it
seems
like
interoperability
would
be
a
quality
they
would
want
or
or
not
want.
Maybe
they
don't
care,
but
if
they
do
want
it,
the
way
that
they
install
the
cnf
is
important.
D
They
don't
want
it
in
such
a
way
to
where
it
doesn't
work
in
someone
else's
platform
or
so
on
and
so
forth,
and
then
these
so
these
I
I
think
I
get
what
you're
doing
and
it
doesn't
need
to
be
addressed.
I
just
kind
of
back
and
forth
on.
If
these
are
individual
use
cases
or
not,
they
can
I
don't
care
as
long.
A
A
Don't
I
don't
know,
I
think
the
main
point
is
to
just
get
the
conversation
started.
So
what?
If
someone
already
has
a
problem-
and
they
want
to
put
it
forward
as
a
use
case,
then
they
can
do
that
if
they
don't
know
where
to
get
started,
they
can
come
and
look
at
the
wish
list
and
then
maybe
they
read
it
and
go
this
didn't
say
enough:
maybe
it
should
say
this
and
they
add
to
it
or
they
create
a
new
one.
A
It's
it's
to
help,
get
the
conversation
started
and
get
people
going
on
eventually
creating
full
use
case.
So
I
I
think
we
may
have
you
and
you
said,
let's
put
it
somewhere
outside
of
the
notes.
The
discussion
board
could
be
a
first
start
before
we
have
anything
else.
Like
a
document.
C
Use
cases
and
user
stories
and
that
wouldn't
be
a
terrible
place
to
sort
of
stick
these
things
in.
But
if
we've
got
no
arguments
on
any
of
them,
then
it
would
be
better
if
we
basically
had
a
checklist
of
some
variety,
whether
that's
a
trello
board
or
something
else.
It
doesn't
really
matter
so
that
we
can
actually
tell
how
we're
progressing
on
these
things.
But
yes
yeah
I
mean
there
is
that.
A
Okay,
well
then
suggestion,
maybe
we
take
a
look
and
we
can
do
this
afterwards,
but
we
could
probably
create
a
board
inside
of
github
for
projects,
and
you
can
do
you
can
look
at
that.
Okay,.
E
I'd
like
to
yeah
I'd
like
to
start
the
argument
going,
I
I
think
some
of
us
might
have
a
different
idea
of
what
a
use
case
is.
Most
of
these
do
not
look
to
me
like
what
I
would
call
a
use
case.
The
use
case
is
a
more
specific
application,
so
mobile
upf
sounds
more
like
it.
I
think
I
think
the
list
you
started
to
create
here
already
has
an
opinionated
breakdown
of
of
the
use
case.
E
This
is
in
a
way,
a
step
ahead,
even
ideas,
for
example
installing
a
cnf
versus
starting.
It
already
assume
a
very
specific
life
cycle
that
you
know
has
to
be
examined
per
use
case
and
to
see
if
it's
even
most
appropriate
for
it.
E
You
know
what
does
install
exactly
mean.
We
often
use
words
like
onboarding.
Some
aspects
of
the
cnf
might
be
have
to
be
pre-installed,
starting,
I'm
not
always
exactly
sure
how
different
that
might
be
from
installing,
sometimes
well.
E
So
I
I
can
understand
the
rationale
generally.
I
I
feel
like
these
are
I
I'm
tempted
to
call
these
things
aspects,
aspects
of
all
use
cases
all
use
cases
would
have
to
have
some
of
this,
assuming
even
that
all
use
cases
are
really
divided
into
cnfs
right.
This
is
an
issue
maybe
with
even
the
name
of
this
particular
work
group
right,
we're
assuming
that
all
network
services
are
decomposed
to
network
functions
that
can
be
recomposed
together
in
some
way.
E
It's
to
me,
this
is
jumping
putting
jumping
a
little
bit
too
far
ahead
already,
I
I
guess
I
prefer
to
start
with
use
cases
that
have
to
do
with
what
telcos
call
use
cases
that
is
actu
use
case
is
another
word
in
telco.
I
think
for
application
or
application
type.
C
C
I
am
trying
to
do
a
certain
networking
thing,
but
a
user
story
is
telling
the
story
of
a
user
trying
to
use
one
of
these
applications,
and
these
are
stories
that
a
user
has
that
are
indisputably
necessary
to
actually
get
to
the
point
that
my
cnf
is
on
the
network
and
working
and
doing
useful
things.
For
me.
F
Maybe
let
me
chime
in
and
the
discussion,
look
speaking
if
you
look
current
definition
of
the
of
the
use
case
in
the
template
and
a
few
examples,
it
is
actually
none
of
what
was
discussed.
It's
not
the
application.
F
So
I
would
not
look
at
and
now
try
to
artificial
or
not
artificially,
but
try
to
force
them.
They
need
to
come
from
the
users
or
from
the
from
the
stakeholders
that
are
facing
certain
limitations,
certain
problems
and
describing
their
their
situation.
Their
their
challenges
in
in
the
way
of
of
description
of
the
use
case
should
give
us
as
an
input
something
to
work
with
to
put
it
black
and
white.
If
nobody
is
coming
up
with.
I
have
this
situation
and
I
have
these
challenges.
F
Then
we
should
not
address
it
even
but
now
I
understand
ian
trying
to
stimulate
a
bit
more
work
on
the
use
cases
so
that
we
get
these
contexts
and
these
situations
more
transparent
so
that
we
can
work
with
them.
F
C
Well
then,
to
take
that
start
example,
then,
when
you
start
cnf
today,
how
does
that.
F
Work
yeah:
this
is
something
let's
say
I
could.
F
I
could
make
an
attempt
to
to
describe
actually
like
we
are
onboarding
a
couple
of
cns
or
prospective
cnfs.
I
call
them
and
they
indeed
come
with
a
with
a
in
the
two
flavors
one
flavor.
Is
I
deliver
you
like,
like
a
cnf
developer
vendor
I
deliver
your
entire
stack
from
bottom
up
and
then
it's.
It
happens
by
some
magic,
not
by
some
magic,
but
by
some
deployment,
ways
and
configuration
ways
that
vendor
put
together
an
entire
stack,
including
kubernetes,
underneath
and
so
on.
F
But
if
it
is
on
boarding
on
on,
let's
say
third-party
cloud
or
on
a
let's
say,
operator
managed
environment.
It
comes
indeed
with
the
10
or
15
and
12
pages
20
pages
of
instructions,
and
it
is
mostly
done.
It
mostly
boils
down
to
you
know
getting
the
helm
charts
getting
the
artifacts
in
the
right
places,
editing
the
values
in
those
hem
charts,
trying
repairing
it's
a
bit
of
artisan
manual
process
at
them
or
not
fully
manual,
but
a
lot
of
manual
work
involved.
F
And
then,
when
it's
deployed
I
mean
starting,
that's
a
good
question.
So
installing
and
starting
it
from
what
I
see
is
when
it's
installed
it
starts
itself,
it
checks
the
readiness
liveliness
and
then
it
it
either
is
in
reconciliation,
loop
waiting
for
other
components
to
happen
or
is
simply
failing,
or
so
there
is
not
not.
This
thing
like
starting
a
cnf.
C
Well,
all
right
to
draw
a
line
between
those
two
then
installing
clearly
involves
to
me
getting
into
a
registry
somewhere
right.
You
need
your
helm,
charts
in
a
registry.
You
need
your.
F
This
is,
this
is
actually
the
most
of
work.
If
I,
if
I'm
talking
now,
I
I
could
think
of
describing
this
in
in
a
use
case,
format
and
saying
this
is
how
we,
what
we,
what
we
see
and
face
today-
and
these
are
maybe
some
some
challenges
but
you're
right.
So
it's
the
first
step
is
really
understanding
what
the
application
is.
F
These
applications
are
in
most
of
the
case,
your
cnfs
are
not
open
source
project
with
the
projects
with
the
comprehensive
readme
files
with
a
let's
say,
documentation
that
is
end
user
friendly
or
not
end
user,
but
operator
friendly.
So
they
are
mostly
done.
F
It's
name
of
my
daughter,
sorry
here
she
used.
Actually
I
see
who
is
taking
the
notes,
so
it's
book.
Actually
sorry.
F
F
Yeah,
so
you
have
now
right
name,
so
where
was
I,
the
applications
are
not
are
mostly
intended
for
the
for
the
service
professional
service,
people
of
that
vendor
who
developed
application
and
not
for
the
direct
usage
by
by
the
the
operator.
F
So
this
is
involving
a
lot
of
interactive
verbal
discussions
in
a
number
of
online
sessions
in
which
we
are
understanding.
Okay,
why
do
you
have
these
artifacts,
like
that?
Where
are
the
the
the
containers
how
you
get
them
into
registry?
Where
are
the
hem
charts?
Are
the
hem
charts
with
the
umbrella
or
not
with
umbrella?
F
F
First
time
like
starting
up
and
saying
hey.
Now,
it's
I'm
ready
to
to
be
configured
or
to
accept
some
traffic.
So
this
is
what.
F
F
F
And
making
making
a
sort
of
use
case
verbally.
C
There's
some
interesting
bits
that
are
coming
out
there
right
everybody
I've
ever
spoken
to
on
this
automatically
jumps
to.
We
start
it
by
running
a
helm
chart
which
is
interesting
so
at
least
today
that
is
best
practice,
and
I
don't
see
a
reason
why
that
would
necessarily
change.
We
could
write
it
down
as
well.
C
F
Yeah,
I
mean
in
our
case
it's
a
bit
different
and
this
is
where
we
are
debating
with
some
of
the
cnf
providers,
because
we
don't
started
by
by
using
helm
install
because
we
follow
the
githubs
process.
So
we
started
by
committing
its
definition
in
git
and
then
wait
until
it
gets
started
in
the
reconciliation
loop,
and
this
is
what
most
of
the
of
the
this
could
be.
Also
one
of
the
use
cases.
Actually,
we
tend
to
see
the
pattern
most
of
those
functions,
as
I
saw
today.
F
I
cannot
name
them
now
by
name
of
vendor
and
and
type
because
they
are
under
nda,
but
most
of
them
are
really
made
for
the
imperative,
like
you
sit
on
the
com
on
the
command
line
on
some
jump
host-
and
you
are
typing
helm-
install
this
and
help
me
install
that
and
then
looking
what
happened
and
then
wait
until
one
part
is
up,
and
then
you
do
the
next
part,
and
you
follow
these
20
pages
documents
which
are
in
most
of
the
cases
written.
F
Extra
or
on
purpose
for
that
particular
installation,
it's
not
like
a
very
general
documentation
because
I
guess
most
of
them
are
not
yet
in
a
in
a
shape
and
in
a
form
to
be
like
widely
available
like
when
you
get
the
I
don't
know,
office
365
you
get
installed,
you
get
some
install
guide,
you
click
and
then
you
go
through
it,
so
they
are
not
made
yet
for
for
such
consumption.
A
F
Made
for
a
system
integration
which
is
on
one
side
right
to
be
so
another
size,
something
that
could
be,
let's
improve
with
some
best
practices.
C
The
thing
about
githubs
is
interesting,
because
that
one
strikes
me
as
not
necessarily
a
part
of
the
cnf
itself,
but
a
part
of
the
way
that
you
put
the
cnf
to
work
in
the
sense
that-
and
I'm
going
to
borrow
an
o-run
term
here,
because
it
lets
me
escape
the
the
legacy
of
etsy
in
etsy.
We
had
a
vnf
manager
and
it
did
a
lot
more
for
a
cnf
than
you're
ever
going
to
need
to
do
for
kubernetes
in
orange.
C
You
have
a
thing
called
a
dms
and
I
think
it's
a
deployment
management
system.
It's
not
so
much
the
detail
of
what
they
think.
Dns
dms
does
that's
important
and
I
don't
know
that
it's
explicitly
or
fully
defined,
but
it's
the
idea
that,
in
order
to
start
cnf,
then
yes,
you
probably
do
need
a
little
bit
of
external
help
to
actually
kick
it
in
the
right
direction
to
begin
the
process,
and
so
it's
reasonable
to
assume
that
there
is
some
external
component
that
does
the
general.
C
You
know
kicks
it
in
the
way
that
it
expects
to
be
kicked,
but
we
don't
really
have
a
pattern
for
what
that
is,
as
you
say,
install
documents-
and
I
know
full
well
that
cisco
is
no
better
at
this
than
anybody
else.
There's
no
pattern
for
this
there's
no
common
approach
for
doing
this.
Everybody
would
do
it
differently
because
you
know:
there's
no
shiny
example
that
we
can
take
and
follow
or
best
practice,
yeah.
C
Precisely
that
I
I
have
a
nasty
feeling
that
we're
gonna
have
to
write
some
very
basic
form
of
cnf
to
just
see
how
this
could
work
and
run
some
experiments
and
take
that
as
feedback
for
our
best
practices,
and
I'm
not
looking
forward
to
that,
because
no
one
likes
writing
best
cnfs
that
they
can't
sell.
So
it's
going
to
be
a
little
bit
of
a
fight
to
actually
accomplish
that.
C
But
on
the
other
hand,
if
we
want
to
work
out
what
is
best,
then
we're
going
to
have
to
find
out
what
is
better
and
what
is
worse.
So
I
think
there
might
be
some
experimentation
involved.
A
Out
here,
al
just
a
second:
we
we
had
a
a
question
added
in
here.
I
don't
know
if
you
saw
this
ann
will
these
use
cases
cover
scenarios
on
how
a
cnf
can
be
deployed
orchestrated
with
onap
and
other
lf
projects.
C
Well,
I
mean,
as
far
as
I
can
tell
service
providers,
don't
100
use
onap
everywhere
I
mean
some.
Do
some
don't
so
the
question
is
what
makes
it
amenable
to
whatever
they
might
choose
to
do,
but
on
the
other
hand,
you
know
onap
is
relatively
logical
in
what
it
wants
to
do.
It's
not
actually
asking
terribly
much
so
whatever
we
do.
Should.
Yes,
indeed,
work
with
own
app,
so
another
question
here
another
way
of
approaching
it
is:
what
does
one
want
you
to
do?
What
makes
things
work
with
onap.
F
Okay,
I
mean
we
also
have
these
discussions
and
it
is
a
question:
how
do
you
transition
from
the
vnf
into
into
cnf
world,
and
also,
how
do
you
make?
F
How
do
you
bridge
over
the
the
period
of
coexistence
of
many
different
shapes
of
the
network
functions
because
there
will
be
vnfs
still
for
for
a
number
of
years
or
even
longer,
they
will
be
there
even
in
a
real
scenarios,
there
are
even
pnf's
physical
network
functions
so
how
we
reason
about
that
is
actually
a
higher
level.
Orchestration
is
needed,
and
we
have
also
one
type
of
of
orchestration
here-
is
needed
to
connect
and
to
manage
this.
F
How
to
say
service
training
like
when
you
have
a,
for
example,
service
consisting
of
the
of
the
cnf
and
vnf
and
pnf.
What
is
this
higher
order?
Orchestrator
that
understands
the
telco
network
setup
and
they
can
wire
those
three
things
or
five
things
together,
so
that
they
can
provide
the
end-to-end
service
yeah.
C
F
We
struggled
and
then
we
are
still
in
these
discussions
like
okay,
but
this
onap
or
or
mano
or
or
whatever
you
use
it.
I
mean
it's
one
form
of
mono.
F
If
I,
if
I'm
not
mistaken,
they
say
okay,
but
you
know
how
do
you
control
the
pod
failover
the
scaling
of
the
of
the
replica
set
or
this
kind
of
things,
and
then
we
have
to
explain
to
to
people
it's
not
anymore,
the
role
of
this
type
of
software,
so
you
need
to
abstract
it
either
on
a
higher
level
and
see
how
it
fits.
F
So
I
what
I'm
pushing
internally
is
really
keeping
that
for
a
cnf's
on
the
level
of
the
service
training
orchestrator,
when
it
can
talk
to
netconf
of
the
particular
network
function
and
that's
it
not
to
deal
with
the
deployment
and
redeployment
of
that
function
and
the
stuff,
because
it
should
be
in
our
opinion,
in
the
kubernetes.
F
D
D
To
me,
this
looks
like
more
along
user
stories
and
I've
volunteered
to
take
with
your
list
here
and
put
them
in
which
is
what's
called
gherkin
so
given
when
then
so,
given
on
an
operator
when
I
have
you
can
fill
in
the
you
know
like
I,
when
I
have
a
vgp
problem
or
when
I
want
to
install
the
ep,
I
need
to
be
able
to
call
this.
You
know
making
it
very
simple,
so
we
can
address
these
very
low
level,
steps
that
are
kind
of
orthogonal
to
describing
another.
D
Maybe
a
higher
level
demand
that
you
would
get
with
a
use
case
where
you
can
have
scenarios
and
things
like
that,
and
then
we
can
solve.
We
can
address
both
sides
and
ian's
wanting
to
address
some
of
these
basic
steps
that,
as
a
someone
in
the
world
world,
how
they
go
about
responding
to
that
that's
handled
very
nicely
with
the
user
story,
as
in
a
user
story,
can
be
like
two
lines
or
one
line.
D
So
we
can
solve
this
very
quickly
to
handle
what
ian's
doing
we
can
put
a
document
out
there
mark
down
with
what
people
are
saying
at
these.
Very
lower
simplistic
levels
or
lower
levels
and
and
everybody
can
be
happy,
you
know
people
can
see
it
know
that
it's
captured
and
those
are
separate
than
say
quality,
so
interoperability
or
some
other
things
which
we're
kind
of
mixing
those
qualities
in
with
steps
so
and
then
all
of
that
being.
C
Demanded
yeah,
I
would
add
that
we
talk
about
the
the
two
things
we've
promised
ourselves.
We'll
write
are
user
stories,
use
cases,
requirements
and
best
practices,
which
is
arguably
implementation,
and
normally
you
would
find
a
set
of
design
in
the
middle.
So
I
think
what's
going
to
happen
here,
is
that
we'll
write
up
some
user
stories
and
then
somebody
will
have
to
propose
a
design
for
some
of
these
things.
C
That,
for
instance,
the
requirements
of
eno
to
take
tells
you
know
baby
is.
It
is
a
consequence
of
a
design
that
hasn't
necessarily
been
made
completely
clear.
You
know
it
arguably
solves
use
cases,
because
if
you
design
your
system
in
a
certain
way,
the
use
cases
all
basically
get
solved
by
the
implementation,
which
is
eno
to
take
one
example,
but
to
vox
point
just
a
moment
ago.
C
You
know
we
have
things
like
service
chaining.
How
are
these
cnfs
working
with
each
other?
How
do
they
know
where
to
talk
to
each
other
and
so
on?
With
things
like
mixing
and
matching
pns,
which
absolutely
are
not
going
away?
I
don't
get
very
far
without
topper
rack
switch
it's
a
pnf
and
cnfs.
C
I
think
our
problem
is
probably
a
problem
of
lego,
which
is
it
doesn't
matter
what
color
and
shape
my
brick
is.
What
matters
is
that
it's
got
the
right
novels
on
it,
so
that
it
connects
with
other
bricks
and,
to
my
mind,
that's
where
we
should
find
ourselves
ending
if
we're
describing
specifically
cnfs,
we
might
choose
to
go
further
out
and
describe
what
the
mano
stack
looks
like
in.
C
If
we
consider
that
to
be
a
best
practice
that
basically
makes
cns
work,
but
if
we
work
out
what
cnf
looks
like
from
the
outside,
how
you
relate
to
it,
how
you
wire
it
to
other
things,
then
we
should
be
able
to
use
it
with
vnfs
and
pnfs
without
getting
too
much
in
detail
of
how
those
vnfs
and
pnfs
are
being
looked
after.
G
A
C
I
I
think
that
would
be
my
take
honestly
if
you're
again,
we
had
our
audiences,
but
if
you're
not
the
developer
of
the
cnf,
if
you're
not
interested
in
making
it
beautifully
cloud
native
to
make
it
more
easy
to
develop
more
agile,
if
you're,
actually
a
consumer
of
a
cnf,
then
the
thing
that
matters
is
not.
You
know
what
language
they
chose
and
how
many
containers
they're
running
it's
things
like
how
does
it
export
its
logs?
How
do
I
wire
its
network
interfaces
to
other
network
interfaces
in
other
cnfs
or
other
devices?
C
This
sort
of
thing
it's
very
much
looking
at
it
from
the
outside
and
not
asking
what
the
ingredients
are,
but
making
sure
that
the
outside
is
the
shape.
You
think
it
should
be,
and
we
sometimes
forget
that
when
we're
designing
things
it's
like
we,
we
want
to
open
the
box
and
see
what's
inside,
see
what
the
workings
are.
Look
at
those
springs
they're
all
very
shiny,
but
in
actual
fact
the
outside
shape
is
probably
the
more
important
thing
to
us
here,
because
that's
what
makes
it
usable.
E
I
I'd
like
to
suggest
something
that
I
hope
will
be
constructive
here.
I
I
think
what
we
need
as
part
of
the
description
of
these
use
cases,
and-
and
I
agree
that
using
a
user
case
story
is
a
good
idea,
but
I
would
underscore
specifically
what
the
assumptions
are,
because
there
could
actually
be
different
assumptions
for
each
of
these
and
best
practices
address
those.
E
You
know
best
practices,
don't
come
in
a
vacuum
right
you,
you
might
already
have
a
platform
and
environment
with
certain
processes
within
your
telco
that
you
know
that's
what
you
work
with
so
somebody's
saying.
Well,
you're
doing
it
wrong
and
this
way
is
better
well.
That
might
be
great
on
paper,
but
you
still
have
to
work
with
what
you
have
so,
for
example,
even
the
trivial
case
apparently
trivial
case
of
installing
a
cnf,
which
I
think
is
nothing
close
to
trivial
assume.
E
You
already
have
an
inventory
management
system
right,
so
you
have
to
onboard
it
in
a
certain
way.
With
certain
descriptors,
you
might
already
be
working
with
an
orchestrator
which
might
not
be
your
choice.
You
know
if
it's
say
its
own
app
right
and
onap
has
its
own
issues
and
etsy
mano
as
well,
and
that
they're
still
trying
to
understand
what
to
do
with
cnfs
in
the
first
place,
and
my
hope
is
that
from
our
group
we
can
give
recommendations
that
can
help
them
move
forward
in
some
ways.
E
But
but
in
any
case,
we
don't
always
get
to
choose
these
environments
and
tool
chains
and
middleware
that
we
have
to
work
with.
So
so
I
think
it's
very
important
to
put
those
assumptions
right
thinking
about.
Oh,
it
could
be
a
helm
chart
or
a
git,
ops
or
or
some
other
kind
of
inventory
management
system
and
and
the
processes,
the
business
workflows.
E
The
operational
workflows
that
get
you
to
the
case
where
you
have
a
cnf
running
right,
which
might
be
part
of
not
just
that
cnf
in
isolation,
but
part
of
the
general
network
service
that
you're
deploying
including
site
management
and
all
these
other
things.
So
so
I
I
think
all
of
these
can
work
for
me
if
they
have
these
assumptions
listed
with
them.
Otherwise,
yeah.
Let's.
D
D
With
the
with
the
assumptions
requirement
other
than
to
say
that,
given
when
then
standard
will
work,
because
when
you
write
it
down
and
then
you
see
17
assumptions
in
the
given
portion
of
the
user
story
and
then
it
starts
to
look
like
oh,
this
is
not
something
that
will
be
a
best
practice.
This
is
an
edge
case,
and
but
you
have
it
written
you're
not
going
to
know
until
you
see
this
thing
written
out.
A
Oh
y'all,
let's
bring
this
back
to
the
topic.
What
we
had
here
was
a
request
from
ian
to
try
to
kick
start
adding
user
stories
or
use
cases
either
one.
This
is
to
build
a
list
so
that
people
can
get
started
and
then
everything
else
we
are.
We
have
already
started.
Addressing
so
tell
you,
you've
brought
up
multiple
times
that
we
don't
want
to
have
assumptions.
You
want
to
get
down
to
the
base
level
and
hold
everybody
accountable.
A
A
If
someone
wants
to
focus
on
something
larger
great,
whatever
you're
wanting
to
contribute
to
that's
the
point
that
ian
was
trying
to
get
started
was
let's
get
contributors
for
more
use
cases
and
user
stories,
and
I
think
watson,
it
sounds
great
to
start
creating
some
set
of
user
stories
that
provide
the
context.
What
we
don't
have
is
a
template
for
user
stories,
but
you're
talking
about
something
that
would
address
stuff
but
get.
We
want
to
just
get
started
and
not
block
anyone.
C
A
I
agree
so
this
might
be
for
the
user
stories,
the
use
cases
wishlist
adam
here,
adam
somewhere
watson,
if
you
want
to
create
a
a
first
set
of
user
stories
based
on
stuff.
That
sounds
great.
We
just
want
to
get
started,
is
the
main
point
everybody's
been
talking
about
it
and
ian
was
trying
to
help
get
things
started
by
let's
at
least
create
a
list
and
not
block
people
from
contributing.
F
Yeah,
it's
actually
to
to
start
meaningfully
addressing
the
or
creating
the
best
practices.
We
need
a
consensus
or
not
a
consensus,
but
we
need
a
bit
more
context
and
this
context
is
going
to
be
built
with
a
couple
of
use
cases
that
cover
I
was
a
decent
surface
for
for
the
beginning.
We
don't
need
to
to
paint
entire
picture
or
write
entire
book
of
every
edge
cases
and
so
on.
F
But
at
least
we
have
a
couple
of
and
to
say
is
this
what
we
are
also
sharing
as
a
as
a
real
situation
as
a
let's
say,
set
of
pain
points?
And
then
let
us
you
know
in
a
follow
up
on
that
start,
describing
the
best
practice
here
or
debating
the
best
practices,
if
you
will
so
what.
A
F
Volunteer
is
really
continuing
what
I
did
with
the
life
cycle
and
maybe
talking
a
little
bit
on
onboarding
to
describe
what
we
are
facing
with,
and
somebody
can
jump
in
and
maybe
correct
it
from
another
angle
or
complement
it.
A
F
A
Idea
of
complimenting
vuck,
so
this
you
added
this
one.
It
seems
like
in
response
to
ian
talking
about,
install
it's
okay.
If
we
have
multiple
use
cases
covering
the
same
area,
yeah
absolutely.
F
A
E
I
I
just
want
to
add
a
small
tangential
ian.
You
mentioned
the
fact
that
we
might
need
to
write
cnfs
and
actually
create
something
that
might
be
difficult.
So
I'll
just
mention
on
my
team
is
working
right
now
on
creating
oran,
cns
well,
they'll
be
moxie
nfs.
The
point
is
that
we
we're
trying
to
build
something
that
we
can
actually
orchestrate
and
compose
the
cnfs
themselves.
Don't
do
anything,
but
they
will
the
intent.
E
Is
that
they'll
be
fully
configurable
using
the
3gpp
yang
models
that
are
referenced
by
the
oran
project,
so
maybe
that
can
help
and
we're
definitely
using
it
as
a
place
where
we
can
play
around
with
what
we
think
the
best
practices
are.
So
we,
for
example,
prefer
to
use
kubernetes
operators
as
a
way
to
to
install
and
manage
and
do
ongoing
changes.
A
I'm
sure
that
you
all
have
a
lot
of
use
cases
and
user
stories,
and
it
would
be
great
if
those
could
be
maybe
broken
down
enough
to
not
have
any
anything
that
would
be.
I
guess,
proprietary
similar
to
what
vic
was
trying
to
do
when
talking
about
onboarding
y'all,
probably
have
a
lot
of
use
cases
that
would
be
applicable
outside
of
red
hats,
so
that
would
be
a
good
area.
C
I
think
we,
I
don't
think
we
have
to
build
a
fake
or
a
real
ran
architecture
to
necessarily
come
up
with
useful
things.
You
know,
I'm
not
going
to
say
that
a
router
is
a
particularly
useful
thing
to
build,
because
it
isn't
quite
honestly,
but
a
router
that
takes
static
routes
is
nevertheless
doing
a
good
proportion
of
what
cnf
would
need
to
do.
If
it's
forwarding
traffic,
they
all
basically
have
a
fairly
common
set
problems,
and
a
lot
of
them
would
be
shown
up
by
having
one
of
those.
C
Similarly,
a
bgp
speaker,
if
I
took
go
bgp
and
tried
to
make
it
into
a
cnf,
would
show
up
a
lot
of
the
common
problems
that
we
would
come
up
with.
So
it's
possible
that,
rather
than
again,
we
get
into
some
difficulty
here,
because
we
all
have
jobs
that
we're
paid
to
do
and
writing
an
open
source.
C
C
Then
we
might
find
that
it's
going
to
work
a
lot
faster
than
trying
to
get
people
to
share
what
they're
doing
with
their
own
cnfs
that
they're,
producing,
which
to
be
clear,
is
usually
set
in
stone
by
the
time
that
anyone's
willing
to
discuss
it,
because,
oh
it's
shipping
now,
so
we
can't
change
it.
Customers
are
using
it
that
way,
so
we
can't
change
it.
We
need
to
compromise
a
little
bit
to
find
out
how
to
get
ahead
of
this
otherwise
yeah.
C
You
know,
we've
already
seen
that
you
know
different
cnf
vendors
and
again,
I'm
not
saying
that
we're
blameless
in
this
have
their
own
patterns
for
doing
this.
That
may
or
not,
may
not
be
good,
but
once
you've
released
a
product,
they're
actually
kind
of
hard
to
get
anyone
to
admit
that
they
need
changing.
C
A
Let's
go
ahead
and
move
on
if
anyone
has
any
any
items
to
add
as
far
as
new
user
use
cases
or
user
stories
either.
One
for
right
now
add
them
to
this
discussion
item
where
we
already
have
some
listed
and
then
we'll
move
towards
whatever
we're
going
to
do
as
far
as
if
we
migrate
them
over
to
another
document,
if
we
put
them
in
the
project
board.
A
F
If
I
just
may,
regarding
this
writing
the
cnf,
I
think
we
would
have
enough
cnfs
or
cnf
references
to
use
in
our
discussions
debates
developing
best
practices,
so
I
would
probably
foresee,
like
not
immediate
thing
we
need
to
do,
but
when
we
have
a
comprehensive
set
of
best
practices,
we
could
even
invite
all
interested
and
say
hey.
Can
you
bring
up
the
network
function
that
would
satisfy
all
these
best
practices
or
most
of
these
best
practices
in
a
form
of
kind
of
competition
or
something
to
show
okay?
F
This
is
really
cloud
native
or
according
to
the
best
practices
is
a
function,
so
I
think
we
could
create
an
intrinsic
motivation
after
we
publish
the
set
of
best
practices
and
then
invite
openly
yeah
community
to
to
bring
up
something
and
then
show
off
at
the
end.
A
A
F
Was
requesting
the
edits
on
it,
which
I
think
I
fulfilled?
I
was
not
coming
back
to
it
since
I
was
off
last
week
and
then
some
days
before,
but
I
remember
that
I
was
addressing
most
of
the
issues
and
I'm
honestly
either
waiting
for
his
feedback
on
the
new
text
or
if
you
go
scroll
down,
I
think
there
was
a.
F
Let
me
let
me
check
that
I
need
to
log
into
that
one,
but
other
way
other
way
around.
If
you
go
to
the
bottom,
you'll
see
that
one
train
requested
in
the
changes
requested
in
this
pipeline
run.
So
if
you
look
at
this,
I
think
I
did
made
those
changes
just
taking
jeffrey.
Maybe
we
can
follow
offline.
A
A
F
Just
need
to
quickly
open
the
tissue
or.
A
A
A
A
A
B
C
C
I
I
tried
to
reorder
it
a
little
closer
to
the
sequence
of
events,
I've
padded
out
each
of
the
sections
so
that
some
clarity
and
what
sections
mean
and
then
I
just
set
to
on
the
language
so
that
we're.
Actually
you
know
when
you
read
this
in
a
list.
It
looks
a
little
bit
more
like
you're
talking
about
comparable
things,
but
yeah
nothing
too
exciting.
Here,
I'm
mostly
impressed
that
people
were
approving
it
without
complaining
about
it.
So
I
I
guess
we're
roughly
in
the
area
of
consensus.
C
A
B
C
H
Yes,
I'm
here:
okay,
probably
this
point
yeah
and
to
erase
the.
H
A
A
C
Yeah
well
one
other
thing
I've
found
with.
That
is
because
this
is
actually
checked
into
the
repo.
When
you
push
to
your
own
branch
before
you
make
a
pull
request,
then
it
runs
the
tests
on
your
branch
for
you,
so
you
do
get
some
feedback
there
as
well.
It
should
get
it
should.
Any
problem
should
come
up.
You
know
several
times
before
we
try
and
commit
anything.
A
A
The
first
step
was-
or
I
guess
the
first
iteration
suggested-
was
a
simple
list,
and
I
believe
this
was
based
on
something
like
kubernetes
community
or
are
you
on
lissina?
I
don't
know
if
you're
able
to
speak
to
this
the
reference
where
this
actually
came
from
this
a
simple
list,
adding
values
into
the
charter
related
the
mission.
A
All
right
well,
this
one,
I
think,
could
use
some
more
responses.
There's
a
lot
of.
Oh
okay.
I
see
a
chat
message
so
there's
oh
yeah,
here's
the
references
so
tess
go
harbor.
Take
the
some
different
cncf
projects.
There's
been
a
lot
of
comments
on
this.
A
So
the
the
main
comments
in
here
about
do
we
expand
from
a
simple
list
and
have
longer
explanations
and
are
there
anything
else
that
we
want
to
cover,
and
this
would
be
more
of
the
with
the
split
of
the
charter
and
the
governance.
A
A
Feedback
there's
a
pr
process
approval.
I
don't
know
if
bill
is
here,
I've
put
in
a
discussion
item
and
we're
right
on
time.
So
just
I
will
need
to
drop,
but
if
you
can
take
a
look
at
this,
this
discussion
about
trying
to
make
the
whole
process
or
pull
request,
be
a
lot
faster
and
simpler
for
most
items.
A
There's
been
some
people
that
have
already
started
giving
feedback
and
you
can
see
how
it
fits
into
the
charter
and
the
and
the
contributing
guide
so
charter
and
then
the
contributing
guide.
C
Yeah,
so
there
are
a
couple
of
points
here:
one
is
we
were
sort
of
debating
about
tech
leads
and
what
they
do,
and
my
proposal
is
that
we
basically
work
out
a
reviewing
process.
Where
then
we
add
tech
leads
to
it
to
speed
it
up.
So
we
put
something
together
which
basically
just
uses
community
members
for
the
minute,
and
then
we
start
you
know
we
can
build
a
role
for
the
tech
leads.
C
We
know
what
they're
going
to
do,
because
it's
clearly
how
we
get
things
to
go
moving
forward,
so
we're
not
building
things
in
advance
of
knowing
whether
they
will
help
or
not,
and
the
other
one
is
that
we
don't
need
to
get
too
complex
just
yet.
If
we
aren't
ready
to
build,
you
know
best
practice,
baselines
that
we're
going
to
put
out
and
saying
here's
our
version
one.