►
From YouTube: CNF WG Meeting 2021-07-12
Description
CNF WG Meeting 2021-07-12
A
A
B
A
A
A
B
B
Entry
in
here,
although
there
isn't
a
great
deal
to
say
about
it,
we've
got
tug
meeting
our
companion
group
on
monday
august,
the
2nd
so
stick
that
in
your
calendar,
if
you
intend
to
turn
up,
I
certainly
plan
to
both
the
kubecon
and
the
on-es
call
for
papers
has
now
closed.
So
we're
all
done
with
writing
those
up,
but
we
don't
know
what
the
schedule
is
going
to
be
or
which
papers
will
be
accepted
and
we
won't
find
out
until
the
end
of
the
month.
B
C
B
To
give
us
a
bit
of
motivation
would
be
one
point
and
I
think
actually
it
would
be
useful
as
well,
to
have
some
example
work
to
that.
We
have
completed
by
onis
and
kubecon.
In
fact,
which
is
you
know,
we've
got
some
time
before
that
happens,
but
yeah
I
mean,
I
think
it's
more
a
motivation
thing
than
than
anything
else.
At
this
point.
D
Also,
some
people
in
external
communities
are
looking
to
see
the
deliverables
of
this
work
group.
So
I'm
I've
been
so
far
reluctant
to
point
them
anywhere,
because
I
treat
everything
here
as
work
in
progress,
but
it
will
be
useful
to
have
something
marked
as
a
0.1
or
whatever
version
that
we
can
refer
external
folks
to.
A
We've
I've
been
hearing
that
as
well
randy
everybody's
asking
to
point
and
similar
to
ann
said
examples,
so
it
can
help
other
people
get
started.
If
they
have
an
end
goal,
they
may
have
use
cases
that
they
talk
about,
but
if
they
have
a
goal
for
why
they're
talking
about
a
use
case,
then
that
could
help
or
it
may
cause
a
best
practice
discussion
to
pop
out
of
a
use
case
because
they
start
having
that
framework
in
mind.
A
I
do
want
to
reiterate
something:
we've
said
before,
but
even
the
best
practices,
whatever
we
say
version
one
or
is
a
release
or
whatever
you
call
it
they'll
all
be
up
for
updating
in
the
future.
If
things
change
and
a
best
practice
doesn't
match
the
current
reality,
then
we
will
update
it
to
match
reality.
B
And
one
other
thing
there
is:
you
know
our
process
as
we've
outlined,
it
is
going
to
be
use
cases,
a
design,
some
best
practices
and
then
a
baseline,
which
we
give
a
version
number
two
and
you
know
a
set
of
use
cases
more
than
zero
gives
us
the
opportunity
to
actually
complete
that
so
that
we
know
the
full
cycle
of
the
process.
And
then
we
can,
you
know,
set
a
timeline
for
going
to
the
next
version.
E
B
A
A
B
Yeah,
we
haven't
got
much
work
on
this
and
I
think
I
could
do
well.
I
know
I
could
do
more
because
I
haven't
been.
I
haven't
had
much
time
for
this,
but
I
I
think
something
on
you
know
how
to
apply
least
privilege
would
be
my
personal
favorite.
It's
quite
technical
when
you
arrive
at
the
recommendation,
but
the
justification
for
doing
it
is
relatively
straightforward.
B
And
honestly,
I
don't
expect
anyone
to
comply
with
it.
You
know,
do
not
use
privilege
of
any
sort
or
you
know,
find
ways
to
dodge
using
privilege
based
on
cnfs.
I've
worked
with,
I
suspect
that
would
be
actually
quite
hard
to
achieve,
but
on
the
other
hand,
the
point
of
recommendation
is
to
give
people
clues
about
what
they
could
be
doing
differently.
So
I
would
not
necessarily
have
a
problem
with
that.
E
B
C
A
Pal
are
there
any
you're
saying,
there's
gonna,
be
a
whole
set
of
practices
under
operator
usage.
So
are
there
any
in
particular
that
you
think
are
more
agreeable
to
a
larger
set,
and
another
thing
that
we
could
say
is
if
it's
very
agreed
to
or
fully
agreed
to
within
kubernetes
community
and
everybody
is
on
other
applications
are
saying
this
is
the
normal
practice
you
should
use
in
this
situation,
then
that
would
also
be
a
good
one
to
look
at.
C
Well,
we'll
see,
I
really
hope
to
be
done
with
it.
This
week
I
keep
adding
more
sections.
It's
I'm
not
following
our
our
structure
very
closely.
It's
more
a
discussion
of
architectural
considerations
versus
practical
considerations
and
main
uses.
I'm
looking
at
are
stateful
components,
configuration
management
and
disaggregation,
which
is
a
more
architectural.
C
So
I
I
don't
know
if
anything
I
write
will
really
be
objectionable,
but
I
I
think
it
will
have
to
be
shoehorned
into
the
format
that
that
we
have
here,
but
I'm
you
know,
I'm
happy
to
I'm
contributing
it
anyway
to
to
the
universe,
and
you
know
we
can
maybe
use
it
to
grab
things
or
start
a
discussion
or
see
where
it
goes.
It's
just
hard
for
me
right
now
to
commit
that
this
would
be
a
deliverable
at
a
certain
time,
but
I'll
throw
it
into
the
pipeline
and
see
what
happens.
B
Yeah,
I
would
say
with
that
that
you
know
it
may
be
that
our
structure
I
mean,
because
I've
had
thoughts
about
this
as
well.
It
may
be
that
our
structure
isn't
exactly
right
for
expressing
some
of
these
ideas,
because
you
know
I
do
this
exactly
the
same
as
you
do.
Sometimes
you
arrive
at
a
conclusion
from
studying
the
technical
problem
rather
than
the
use
case,
and
I
think
there's
a
little
bit
of
both
thrown
in
here.
B
How
do
I
put
this?
You
view
best
practices
in
isolation
and
see
whether
they
make
sense
for
us.
You
don't
always
drag
your
every
bit
of
information
to
to
come
up
with
a
recommendation
from
the
experiences
of
an
operator
so
yeah.
It
doesn't
surprise
me
that
you're
coming
up
with
a
document
that
doesn't
entirely
align
with
the
way
we've
structured
things,
but
that
may
be
that
the
structure
needs
a
little
bit
of
looking
at.
C
G
G
G
G
F
A
G
Yeah
it
does.
I
asked
the
question
because
I
guess
in
the
white
papers
right
where
we
have
the
cloud
native
network
functions,
definitions
can
be
tied
back
to
the
definitions
that
we
were
working
earlier
a
couple
of
weeks
ago
in
this
working
group,
so
that
was
the
main
intent.
Whenever
we
have
the
work,
the
artifacts
and
the
best
practices
use
cases
produced
through
this
working
group.
Can
we
leverage
some
of
those
under
the
telecom
user
group.
A
A
F
A
B
Yeah,
I've
certainly
seen
this
practice.
In
fact,
I've
used
this
practice,
so
I'm
actually
not
I'm
not
objecting
to
it.
My
comment
is
more:
can
we
find
the
objective
way
of
saying
why
it's
worth
doing
versus
openshift
requires
it
or
it
shifts
severely
it
significantly
benefits
from
it.
So
if
we
can
find
that
objective
view
that
will
make
it
easier
to
write
up.
A
B
C
C
But
there
are
aspects
here
that
are
unrelated
to
kubernetes.
The
the
question
is:
does
the
does
the
operating
system
itself
have
support
for
it
and
there
are
actually
two
approaches
to
implementing
sctp
and
linux,
one
of
which
is
using
a
user
stack,
a
user
mode
stack
and
there
are
also
kernel
modules
that
could
do
it
as
well.
Now,
when
you
write
your
applications,
you
target
either
of
them
they're
they're,
not
the
same
apis.
C
A
user
stack
would
be
trivial
to
deploy
everywhere
and
would
be
able
to
fully
support
kubernetes.
But
if
you
rely
on
the
kernel
stack,
you
need
requirements
for
the
actual
infrastructure
for
the
host
for
the
module
to
be
loaded.
So
there's
there's
a
pretty
easy.
I
think
way
we
can
come
in
here
and
offer
best
practice.
B
Yeah,
well,
I've
seen
models
of
using
sctp
that
don't
require
kubernetes
features
and
benefit
from
that
as
well,
which
you
know.
If
you
have
a
a
second
interface
and
the
kernel
modules,
then
you
just
go.
Go
and
use
scp
on
your
sctp
on
your
second
interface
and
kubernetes
has
no
involvement
in
that
other
than
the
platform
as
a
whole
has
to
have
the
kernel
modules.
B
So
questions
we
could
ask
ourselves,
firstly,
is:
would
we
expect
the
kernel
modules
to
be
present
on
a
platform
that
is
running
that
is
going
to
run
cnfs,
and
the
answer
seems
to
be
to
me?
Why,
wouldn't
you
I
mean
it
seems
like
a
logical
thing
to
basically
build
that
module
in,
even
if
it's,
even
if
the
cns
happens,
not
to
use
it,
it's
no
skin
off
anyone's
nose
to
actually
install
it.
H
So
it
it
may
be
re
removed
from
certain
environments
because
they're
in
the
security
hardening
they're
trying
to
reduce
the
attack
surface.
So
you
may
actually
see
some
environments
where,
where
it
ends
up
being
removed
and
it,
but
it
is
good
to
call
out
to
say
that
if
you,
if
you
want
to
use
scp
with
with
kubernetes
or
within
the
kernel
space,
then
they're.
These
are
the
type
of
things
that
you
should.
You
should
enable,
but
I
would
be
a
little
bit
careful
on
that.
C
C
B
C
B
I'm
willing
to
you
know
I
our
recommendations,
ideally
shouldn't
be
ill-considered,
so
getting
that
expertise
is
perfectly
useful,
but
that's
fine.
You
know
it
doesn't
necessarily
mean
it
needs
somebody
on
this
meeting
every
week.
What
it
means
is
that
you
need
to
survey
your
audience.
You
need
to
talk
to
people
who
are
doing
this
and
I
can
think
of
people
from
cisco
that
you
might
want
to
talk
to
on
this
subject.
B
C
C
B
Okay
well,
but
that
was
a
conversation
now
I
threw
in
cnf
packaging
for
delivery.
I'm
not
saying
this
is
necessarily
easy,
but
I
think
some
of
the
use
cases
we're
already
talking
about
about
you
know
initial
startup
start
speaking
in
this
direction.
A
cnf
is
a
collection
of
containers.
It
is
hypothetically
a
helm
chart,
it
doesn't
have
to
be
a
helm
chart,
but
you
know
we
would
reasonably
assume
that
it
would
be
a
helm.
B
B
B
B
C
C
We
all
participate
in
other
standards
body,
and
I
don't
think
we
want
this
group
to
be
a
standards
body.
We
definitely
don't
our
best
practices
guys
aren't
supposed
to
be
standards,
recommendations.
If
we
I
at
least
I
don't
think
so.
But
if
we
do
reach
a
point
where
we
want
to
suggest
standards,
then
it
could
be
an
output
from
this
group
that
goes
elsewhere,
but
yeah.
This
doesn't
seem
the
best
place
to
do
that.
C
Specifically.
So
so
it's
more
about
looking
at
the
ecosystem
what's
available,
so
you
mentioned
helm,
helm
is
very
popular
at
least
right
now,
so
standardizing
on
helm
would
not
be
something
that
we,
I
think,
should
suggest
right.
It's
it's
more
a
question
as
if
you're
using
helm,
if
you
decided
to
have
a
chart
repository
in
your
deployment
environment.
B
Yeah,
that's
fair,
I
mean,
I
think
you
know
again.
This
is
more
about
how
we'll
write
standards
than
it
is
about
best
practices,
but
every
standard
needs
an
out
for
this
technology
will
become
outdated
and
when
you
have
the
next
one.
This
is
how
you
use
this
standard
with
the
with
the
with
the
next
technology
you
want
to
use.
It's
been
it's
quite
easy
to
do.
It's
quite
easy,
for
instance,
to
basically
have
a
package
that
basically
says
there
is
a
health
chart
in
there.
C
Right
and
in
the
end,
I
think
it's
more
about
a
general
approach,
so
I
agree
with
how
you
started
this
when
you
said
that
when
we
talk
when
we
think
about
packaging
in
the
end,
it's
these
manifests
right
that
are
usually
enamel,
although
they
could
be
adjacent
too,
but
these
manifests
can
be
generated
from
something,
so
it
could
be
a
helm
chart.
It
could
be
some
other
tool,
but
the
point
is
is
really
focusing
on
those
resources
and
what
they
are
enumerating
them
managing
them
thinking
about
them
together.
B
Yeah
perhaps
not
generated
from,
but
describing
the
fact
that
such
a
thing
is
in
the
package
and
how
it's
supposed
to
be
used.
But,
yes,
your
point
is
valid,
so
we're
saying
that
if
a
packaging
format
were
to
exist,
we
don't
necessarily
have
to
define
the
packaging
format,
but
we
could
say
these
are
the
properties
we
expect
of
it,
including
there
is
a
manifest.
The
manifest
will
contain
this
information.
Then
we
can
go
and
take
that
and
write
a
packaging
format.
That's
compliant
and
stick
it
somewhere
that
isn't
within
the
cnf
working
group.
C
Aspects
here
are
important
because,
as
you
pointed
out,
delicately
there's
a
difference
between
day
one
and
day
two
you
know
helm
can
do
one
and
not
really
the
other
and
yeah
there's
a
lot
of
thinking
there.
It's
it's
packaging
is
not
simple,
but
I
think
we
we
might
be
able
to
make
a
contribution
and
specifically
for
cns
and
not
just
generally
well.
Frankly,
if
you
could
write
a
document.
B
Because
I
mean
seriously
it,
it
is
a
problem
that
I
keep
encountering,
that
a
any
two
cns
literally
no
idea
how
to
start
them.
And
then
you
have
to
go
and
beg
for
the
document
that
tells
you
how
to
start
them
and
then
it's
a
new
exploration
into
a
a
new
way
of
doing
it,
because
it's
never
the
same
as
anyone
else's.
C
Exactly
yeah
I
mean
this
is
where
operators
can
come
in,
workflows
can
come
in,
so
the
ecosystem
is
quite
broad,
and
I
think
what
we
can
do
is
maybe
take
a
more
high-level
approach
and
look
at
different
ways.
You
can
think
about
it,
so
you
can
think
about
it
as
okay
here
are
manifests,
and
then
there
are
instructions
on
how
to
raise
it.
C
B
Yeah
but
right
so
you,
you
know
there
is
always
a
bootstrap
phase
here
right,
I
can
walk
backwards.
Well,
what
brings
the
pods
up?
Oh
well,
the
operator
brings
the
pods
up
well,
what
brings
the
operator
up
oh
well,
yeah,
and
then
what
puts
the
software
in
a
place
where
the
operator
could
even
be
brought
up,
and
so
it
may
be
less
about
worrying
about
the
stages
in
between
which
are
theoretically
optional.
I
can
use
an
operator,
I
don't
have
to
use
an
operator.
B
There
are
benefits
using
an
operator,
but
how
would
I
get
that
first?
So
you
know
there
is
always
a
first
step
where
I
have
a
shiny,
new
kubernetes
cluster
with
no
software
on
it,
and
I
need
to
put
software
on
it
if
we
could
work
out
what
the
first
step
was,
so
that
following
steps
could
happen,
then
you
know-
and
if
that
were
held
right,
helm
is
a
perfectly
reasonable
way
of
making
an
operator
happen.
Then
that
would
get
us
a
certain
well
if
it
gets
further
than
we
currently
are
at
least.
C
B
B
B
Okay,
that
was
a
long
discussion.
It
involves
lots
of
items.
It
might
be
a
good
idea
if
we
had
a
chat
on
the
channel
afterwards
and
see
if
we
can
actually
pick
some
items
that
everybody
promises
to
work
on
for
a
couple
of
hours
this
week,
just
because
I
know
for
well
I'm
terrible
at
committing
time
to
this,
if
I'm
probably
better.
If
somebody
holds
me
to
it,
if
anyone
else
wants
to
work
that
way,
then
we
can.
We
can
try
and
figure
it
out
in
the
channel
later.
A
B
Yeah
for
everything
else,
for
you,
you
and
I,
I
think,
would
happily
kind
of
again
we
we
could
do
some
work
on
least
privilege
this
week
and
see
how
far
we
can
take
it.
Let's
worry
less
about
what
we
produce
and
more
about
actually
spending
some
time
on
it.
So
if
I
promise
you
half
a
day
of
sitting
there
and
beating
on
these
privileged
documents,
that
would
that
seems
like
a
productive
way
of
going
about
this.
B
I
mean
taylor
and
I
in
the
past
have
found
that
basically
holding
ourselves
up
in
a
meeting
and
sitting
there
effectively
typing
at
each
other,
does
actually
it's
one
reasonably
good
way
of
making
progress.
You
know
you
can
all
play
that
game
if
you
want
to
basically
find
a
partner
and
work
with
them.
B
Me,
okay,
let
us
move
on
to
the
pull
requests
and
with
apologies
because
zuma
hates
my
laptop,
so
I'm
actually
on
my
phone.
I
can't
easily
share
the
screen,
but
I
will
have
a
look
at
the
pull
requests
and
if
anyone
else
wants
to
basically
take
the
lead
and
share
what
share
of
website
you're
welcome
to.
We
have
three
poll
requests
sitting
here.
One
is
onboarding
cnfs
one
is
updating
the
glossary
and
one
is
adding
5g
rand
use
cases.
B
C
B
B
Oddly,
I
mean
I
know
it's
technically
in
depth
and
it's
probably
not
okay
area.
We
have
you
know
everybody
knows
what
we're
talking
about,
but
it
should
be
one
where
we
can
basically
be
quite
straightforward
in
writing
it
up.
You
need
synchronization
and
timing
propagated
by
the
network
with
great
accuracy.
B
There
is
a
perfectly
good
way
of
making
that
happen
in
the
kernel.
There
is
a
perfectly
good
way
of
consuming
that
from
cnf
processes,
so
the
best
practice
is
actually.
There
is
only
one
way
of
doing
this.
The
best
practice
is
really
easy
to
write
so
that
one
independently
of
the
other
one
should
be
pretty
easy
to
deal
with
use
case.
Two,
I
think,
is
the
standard.
B
B
So
my
personal
opinion
is
that
use
case
2
treads
in
areas
where
we
know
that
things
like
eno
exist
and
there's
some
finding
exactly.
The
right
thing
to
say
is
difficult,
but
use
case
one
is
probably
not
terribly
contentious,
because
there's
really
just
one
way
of
doing
it,
writing
it
down
is
actually
the
most
useful
thing
we
can
do.
You
know
you
will
run
ptp
for
l.
Your
cns
will
keep
checking
the
kernel
clock
because
it
will
be
tightly
bound
to
the
clock
that's
distributed
over
the
network.
B
Then
we've
got
the
things
that
the
relevant
audiences
should
be
doing
in
order
to
get
an
accurate
clock
and
again,
if
it
proves
insufficiently
accurate,
I
don't
think
we're
going
to
be
the
ones
here
to
say
what
accuracy
means.
I
know
that
sounds
weird,
but
you
know
if
I
were
to
go
and
grab
the
system
clock
precisely
how
many
nanoseconds
from
the
absolute
truth.
Is
it?
Well,
that's
a
very
difficult
question
to
answer,
but
you
know
we
can
just
say
this
gets
you
a
this
is
the
best
practices
for
getting
an
accurate
clock.
B
B
B
A
So
that's
so
we're
talking
about
a
use
case
and
not
a
best
practice.
There's
a
few
formatting
things
that
have
been
committed.
Does
this
item
that
you
and
frederick
are
talking
about
for
virtualized
or
not
and
to
talk
here?
Is
it
a
blocker
for
a
use
case
versus
a
best
practice?
This
is
a
situation
that's
being
put
forward.
A
B
B
H
H
Every
time
that
you
perform
an
an
off
code
or
every
time
you
have
a
every
time,
you
have
a
certain
action
occur
within
within
the
cpu,
and
we've
actually
had
issues
with
this
in
file
systems
before
where
you
might
have
two
threads
running
in
into
separate
cores,
and
they
become
desynchronized
enough
that
the
order
of
timestamps
to
get
synchronized
end
up,
not
not
matching
what
you
would
expect.
So
you
can
have
something
that
it
came
afterwards.
That
appears
to
have
happened
earlier
in
time
in
terms
of
timestamps.
H
So
there's
a
couple
of
accuracies
like
that.
That
tend
to
occur
from
that.
So
that's
why
I
was
saying
that
these
things
are
not
are
not
virtualized,
but
there
there
is
sometimes
depending
on
the
so,
where
you
get
your
time
that
there
can
be
issues
of
synchronization
there,
depending
on
the
hardware
architecture.
A
B
A
B
Yeah,
you
need
ptp
suitable
hardware,
whether
it's
the
the
nic
or
another
device,
and
you
need
a
device
driver
in
the
kernel
that
offers
the
ptp
interface.
But
then
everything
from
there
goes
again.
We
can
write
this
down.
Some
of
this
is
really
a
step-by-step
deployment
thing.
I
wouldn't
be
averse
to
writing
that
down
in
a
best
practice,
but
I
think
that
would
be
auxiliary
information.
I
think
the
best
practices
the
network
has
the
timing
information
on
it.
It
shall
be
offered
to
the
application
this
way
and
then
here's
the
details.
B
A
F
B
A
B
C
C
I
I
don't,
I
don't
know
what
to
do
with
this
pull
request
anymore.
It's
I
think
we
just
need
to
continue
to
discuss
until
until
we
reach
an
alignment
that
that's
basically
it
and
I
I
would
like
to
do
it
on
github,
but
I
think
very,
very
few
of
us
here
are
are
looking
at
github,
so
I
think
these
meetings
are
the
right
place
to
to
to
get
feedback
from
everybody
I'll
try.
A
I
I
I
don't
know
like
if
they
are
not
depending
on
each
other,
then
maybe
we
could
like
discuss
one
or
two
terms
come
to
an
agreement,
put
it
up
in
a
pull
request.
If
anyone
wants
to
comment
in
the
next,
I
don't
know
week
or
two
they
can.
If
there
are
no
objections,
just
merge
that
one
and
then
move
over
to
the
next
one.
So
we
don't
have
to
nurture
one
big
pull
request
and
chew
on
it.
For
months.
C
So,
and
and
to
an
extent
it
doesn't
matter,
you
know
if
we
resolve
issues.
These
are
many
pull
many
issues
right.
If
you
resolve
a
conversation,
that's
resolved
so
when
it's
finally
done
it'll
be
merged,
I
nobody
is
putting
a
gun
to
our
head
and
saying
merge
it
right
now,
so
it'll
be
it'll,
be
ready
when
it's
ready.
Yes,
it
would
have
been
nice
if,
if
in
the
beginning,
I
could
have
divided
it
into
multiple,
but
they
they
did
come
as
a
set.
C
A
A
C
C
A
That's
true,
and
I
I
guess
from
that
standpoint
tal,
you
could
always
say
I
don't
want
any
changes
and
then
someone
else
can
come
in
not
saying
that
you're
actually
communicating
that,
but
anyone
putting
a
pr
if
you're
working
on
it
and
you're
like
nope.
I
disagree,
that's
fine.
Someone
else
can
come
and
copy
everything
and
make
the
changes
in
another
pr
so
similar
to
open
source
fork
it
and
do
what
you
want
and
put
that
forward
and
then,
in
the
end,
as
a
group
we'll
decide
on
which
direction
we
like.
A
I
want
to
bring
this
back
the
just
the
discussion
on
the
main
items
that
were
problematic.
It's
what
tal
you
were
pointing
at
the
different
approaches
to
defining
network
function.
So
this
one,
I
believe,
is
what
you'd
originally
put
forward.
I
don't
know
if
it's
been
modified,
I
don't
think
it
has.
I
think
this
was
what
you
had
for
a
cnf.
A
A
The
my
thing
which
I
was
pointing
here
with
regards
to
network
function
is
when
people
are
coming
to
this
group,
particularly
so,
if,
if
they're,
looking
at
the
group
they're
looking
at
best
practices
and
other
information
that
we
put
out,
then
they're
going
to
go.
Okay,
so
all
are
the
cloud
native
network
function
working
group?
So
what
does
that
mean?
Well,
that
means
this.
Okay,
it's
a
network
function.
Okay!
Well,
then,
what
is
a
network
function
so
immediately
they're,
starting
from
the
point
of
your
group,
is
about
cloud
native
with
you
know
these.
A
Whatever
this,
it's
a
cloud
native
application,
that's
what
it
says,
a
cloud
native,
it's
a
cloud
native
application,
developed
using
cloud
native
principles
and
it's
a
network
function.
Okay,
so
that's
must
be
I'm
without
knowing
anything
else.
I
guess
that's
a
type
of
application
because
it
says
it
is
a
cloud
native
application,
so
now
let's
actually
go
and
see
what
a
network
function
is
it's
a
functional
block
within
infrastructure
and
maybe
components
of
network
services.
A
A
What
is
network
infrastructure
and
I
think
the
very
last
one
I
put
in
two
commits
so
we've
had
a
long
discussion.
I'm
not
gonna
go
through
all
this.
Someone
wants
to
if
you're
interested
go,
read
it.
This
is
really
the
last
part
to
relate
to
the
current
cnf
definition
that
you
proposed
so
trying
to
phrase
net.
The
definition
for
network
function
to
be
related,
an
application
providing
a
unit
of
network
functionality
so
trying
to
communicate.
What
do
we
mean
by
a
network
function
or
functional
block?
So
it's
functionality.
A
A
A
I
would
say
which,
for
those
that
you
haven't
seen
it
there's
a
discussion
item
and
you
can
go
look
at
the
diagrams
that
he
had,
but
a
bump
in
the
wire
small,
transparent
firewall
can
be
providing
a
network
service
and
it's
a
singles.
It
could
be
a
single
small
network
function
or
application,
that's
providing
that
service,
but
it
also
could
be
one
component
of
something
much
larger,
like
maybe
the
convergent
charging
service
and
a
5g
mobile
core
and
you're
gonna
have
a
lot
of
different
components
but
say:
okay.
A
C
I
it's
fine,
I
feel
like
this
is
network
function
is
not
very
controversial.
I
I
made
the
point
here
that
you
know
in
the
end,
some
of
these
terms.
We
don't
really
own
it's.
You
know
we
we're
not
going
to
find
the
best
definition
of
network
function
in
our
group.
We're
not
the
right
place
to
do
that.
Specifically,
it's
something
we
accept
as
a
given
network
functions
are
used.
C
C
B
Yeah
so
again,
let's
start
with
work:
let's
commit
the
definitions
as
necessary,
one
by
one
that
we
are
not
arguing
about
cloud
native
network
function.
Oddly,
we
seem
to
have
settled
on
even
if
we
can't
define
network
function.
Yes,
it
would
be
nice
to
have
a
definition
of
network
function,
but
I
would
live
without,
if
we're
being
quite
honest-
and
there
are
a
handful
of
others.
B
So
if
we
can
go
through
them
and
I'm
sorry
tell-
I
know
this
falls
on
your
head
and
I
know
you
very
much
tried
to
do
a
good
job
here
and
get
everything
done,
but
if
we
can
try
and
get
them
done
just
one
by
one
in
from
least
to
most
controversial,
that
would
be
forward
progress,
whereas
at
the
moment
this
is
a
very
much
a
monster
comment.
Fest
and
the
discussion
has
been
useful,
but
it's
not
going
to
conclude
as
a
whole
in
a
while.
So
maybe
you
can
do
this
in
piecewise.
C
So
I
sure,
and
I'm
not
sure
really
what
to
do
here
I
mean
I
can
just
click
resolve
conversation
when
I
feel
it's
resolved,
but
I
I
think
what
you're
asking
here
is
to
get
some
sort
of
agreement
among
committers
for
it,
which
I'm
not
really
sure
how
to
do
do.
You
expect
me
to
reach
out
to
them
personally
or
what
do.
B
You
want,
let
me
take
an
example
if
I
took
the
definition
of
cloud
native
network
function
that
we
have
and
I
threw
in
that
it
doesn't
mean
containerized,
because
I
think
that's
useful
context.
If
I
took
the
definition
of
virtual
net
function
that
we
had,
which
I
think
became
quite
clear,
and
the
discussion
did
help
clarify
it.
Would
anyone
throw
their
arms
up
in
the
air
and
say
that's
wrong
at
this
point.
A
F
A
F
A
B
A
B
I
wasn't
asking
a
question:
I
was
simply
saying
there
are
uncontentious
and
more
contentious
problems
here,
the
uncontentious
ones
can't
we
get
shot
at
them,
so
that
we
can
focus
our
attention
on
why
we
have
problems
with
more
contentious
ones,
because
you
know
the
fact
that
we're
having
this,
you
know,
we've
gone
from
point
to
point
to
point
down.
This
means
that
we're
not
committing
any
of
it.
A
A
If
you
read
through
these
they're
just
general
conversation
and
nobody
is
specifically
saying-
let's
modify
physical
clarified
network
function,
I
I
don't
know
I
haven't
looked
to
see
if
who
said
to
remove
or
not,
but
I
I
think
we
should
remove
clatified.
I
don't
think
it
helps.
So,
let's
see
containerized
network
function,
there's.
F
B
My
request
to
you
all
is
if
we
can
work
out
what
is
not
contentious
and
put
a
pull
request
in
for
just
that,
so
that
we
get
it
done
and
if
there's
anything
else
that
is
contentious,
then
you
know
the
subset
of
interested
parties
can
argue
to
their
hearts
content,
but
but
hopefully
other
people
can
work
with
the
the
definitions
that
are
actually
you
know
offended
but
honestly
foundational
to
what
we're
trying
to
do
so.
It
gets
us
moving
forward.
C
All
right
I'll,
say
I'll
resolve
network
function.
I'll
just
take
your
definition,
taylor,
because
I
I
simply
don't
care,
I
don't
think
it
matters
how
we
defined
it.
So
if
there's
something
that
you
prefer,
I'm
very
happy
to
give
you
that
cloudify
network
function
is
more
complicated.
Let's
discuss.