►
From YouTube: CNF WG Meeting 2021-08-02
Description
CNF WG Meeting 2021-08-02
A
A
B
B
Please
add
your
name
and
if
you
have
any
agenda
items,
let
me
know
right
now:
does
anyone
have
anything
they'd
like
to
add
otherwise
I
can
look
at
pull
open,
pull
request.
B
All
right,
it's
very
quiet,
I'm
going
to
presume
my
audio
is
working
and
we
worked
on
the
last
call.
B
All
right,
so
I
think
this
one
came
out
of
comments
in
the
last
call
about
best
practices
and
the
the
template
we
put
together
was
based
on
the
kubernetes
enhancement,
proposals
or
caps,
and
this
was
before
we
actually
had
best
practice
proposed
and
trying
to
see
what
would
be
most
relevant
and
useful
for
us.
B
The
test
plan,
just
the
wording
around
that
was
throwing
throwing
off
some
of
the
view
of
what
we
needed
to
have
in
there
and
it
seemed
like
test
objectives
was
an
agreeable
one.
B
Let
me
see
if
I
can
give
some
context
like
this:
there
we
go
so
when
you're,
giving
a
test
plan
I
mean,
and
talking
about
is
the
best
practice.
Testable
is
the
main
thing,
so
I
think
some
of
the
comments
were
we
put
a
plan
to
how
detailed
do
we
need
to
get
when
we
handed
it
over.
Is
it
so
specific
that
anybody
could
implement
it,
and
the
agreement
was
we're
overall,
saying
test
objectives
and
is
the
best
practice
testable
in
letting
implementation
of
that
be
up
to?
B
D
B
B
B
D
I
will
note
that
I
appreciate
jeffrey's
idea
here
of
calling
it
testing
considerations,
but
I
think
testing
objectives
is
fine.
It's
under
that
you
can
put
considerations
for
those
objectives
right
how
to
reach
them.
So
it's
it's
all
about
the
details
agreed.
B
B
All
right,
if
you
want
to
oh
thanks
ronnie,
I'm
gonna
count
that
as
a
plus
one,
you
can
also
click
on
for
those
who
haven't
done
this.
You
click
over
on
files,
click
review,
changes,
click
approve,
do
a
plus
one
or
lgtm.
B
Thanks
this
one's
a
pretty
minor
one,
I
think
we
haven't
like
specifically
labeled,
but
for
bigger
ones.
We
wanted
five,
I
believe-
and
if
I
go
look
at
the
merge
notes
on
on
how
we're
going
to
do
that.
B
B
B
C
Sorry
I
was
yeah,
it
was
just
adding
the
space
afterwards.
So
all
the
checks
would
pass.
B
This
is
a
hidden
html
comment
and
I
won't
click
rich
shift
because
I
think
it
may
yeah
disappear,
but
having
that
whenever
anyone
copies
the
content
over
that
the
best
practice
that
you
have
would
have
like
the
template
version.
So
if
we're
updating
it
we'll
know,
hey
we
changed
test
plan
to
test
objectives,
let's
make
sure
and
get
all
those
updated.
B
B
So
the
next
one
is
this
best
practice
that
ian
and
I
put
in,
but
there's
been
a
lot
of
comments.
I
think.
B
Let's
see
and
jeffrey
says
yes,
so
I'm
gonna
update
that
one,
so
the
summary
would
be
containers
have
a
list
of
their
own
users
independent
of
the
host
system,
one
of
which
is
uid0
or
the
root
user
containers
should
run
processes
as
a
user
other
than
root,
which
makes
it
easier
to
run
these
images
securely.
B
And
going
down
victor
application
bug?
Okay,
so
this
around
goals,
his
opinion,
application
bugs
and
generic
term,
which
cover
application
bugs
or
bugs
are
a
generic
term
which
cover
many
aspects.
B
As
far
as
I
understand
yeah,
as
far
as
I
understand,
the
main
idea
is
to
reduce
the
attack
surface
of
by
limiting
permission,
so
this
update
was,
I
think,
removing
the
behavior
of
applications
when
bugs
occurs
and
ian
seemed
to
not
agree-
and
I
also,
I
guess,
disagree
with
the
change,
because
the
you
could
have
non-security
issues.
B
But
if
there's,
if
you
have
root
in
a
container
and
just
something
some
bug
or
anything
occurs,
then
the
application
could
do
more
problems
because
it's
less
restricted
without
being
malicious
or
causing
like
a
potential
security
like
access
to
something.
Maybe
it
just
doesn't
behave
properly
or
you
have
data
corruption
or
whatever
else
is
a
result
of
that
victor.
You
got
a
thumbs
up,
but
if
anyone
victory,
you
want
to
comment
on
this
or.
D
B
All
right
so
jeffrey
just,
I
think,
talking
about
the
way
the
goals
section.
It's
I'm
gonna
kind
of
scroll
because
you
gotta
see
the
whole
thing
here,
so
the
goals
section.
I
think
it
was
more
of
a
formatting.
He
verbalizes
on
the
call
and
then
added
a
comment
as
well,
that
it
wasn't
formatted
in
a
way
to
see
it
as
goals.
B
I
think
was
the
main
thing,
and
so
I
split
it
out
so
where
that
rewarded
it
so
this
bottom
line,
he
commented
that's
a
goal,
avoid
compromise,
that's
causing
more
damage.
So
I
took
the
the
way
the
senate
structure
was
improve
the
security
and
behavior
of
application
when
bugs
occur,
added
the
defense,
in-depth
strategy
against
external
compromises,
and
then
we
have
avoid
compromised
apps,
causing
more
damage.
B
I
think
I'll
have
to
delete
a
maybe
this
extra
space
so
that
they'll
just
be
one
after
another.
But
that's
the
idea
there.
F
B
B
All
right,
I
guess
we
were
the
summary
captures
well.
B
Understood
so
the
summary
covers
that
motivation
refers
to
the
user
and
I
guess
within.
If
you
take
the
context
of
all
of
that,
and
maybe
the
next
sections
on
the
like
the
proposal
section,
then
you
get,
how
are
we
going
to
do
it
so
the
whole
best
practice
is
about
don't
use
the
root
user
so.
G
B
B
Okay,
I
got
maybe
let
me
I'm
gonna
address
this
one
and
then
approve
improve
the
security
favor
when
a
bucks
occur.
I
I
agree
with
maybe
improve
the
security
behavior
of
applications.
B
Okay,
so
that's
like
sorry
go
ahead.
Tell
me.
D
Yeah,
this
does
read
a
little
bit
strange
to
me
because
these
goals-
they
are
so
general
and
and
if
we
really
do
want
to
apply
that
principle,
I
mean
there
are
all
these
aspects
that
have
well
beyond
root.
You
know,
well,
if
you're
using
another
user,
have
you
given
it
full
permissions
to
do
anything
it
wants.
It
might
as
well
be
root.
Are
all
your
files
set
with
attributes
that
allow
any
user
to
write
them?
D
For
example,
there's
we're
really
narrowly
focused
here
and
but
but
the
goals,
on
the
other
hand,
are
really
really
broad.
It
sounds
kind
of
strange.
B
B
I
think
that's
just
known
and
we
may
be
able
to
share
more
as
we
go
on
and
say:
here's
some
general
information
like
the
glossary,
but
we're
not
trying
to
get
it
perfect
between
them
to
get
started.
So
if
we
have
something
general
and
then
have
another
best
practice
based
on
lease
privilege,
it
may
have
some
of
the
same
goals
and
right
now
I
think
we
just
recognize
that
and
that's
okay.
B
D
F
Yeah,
but
the
no
root
in
containers
basically
helps
achieve
the
goals
that
are
being
listed,
so
improving
security
and
behavior
is
a
very
good
goal
and
it
you
know
no
routine.
Containers
contributes
towards
that.
No
routine
containers
also
contributes
to
defense
and
depth.
If
you
will,
as
well
as
at
least
least
privilege,.
B
F
B
Yes,
I
think,
like
that,
plus
I'm
going
to
delete
the
extra
line.
Add
a
dash
avoid
compromise
apps
from
oops
from
causing
more
damage.
B
D
D
The
other
ones
are
just
so
general
this.
This
is
what
root
does
right.
Root
helps
avoid
compromised
apps
from
causing
more
damage.
E
D
Well,
it
shouldn't
be
the
host,
otherwise
there's
something
very
wrong
with
your
container
technology
or
you're
running
in
a
privileged
container,
which
is
another
problem
that
we're
not
talking
about
here,
but
but
we're
assuming
here
that
the
container
works
and
really
containerizes.
D
But
you
know
what
the
kind
of
things
that
root
can
do
very
much
depend
on
what's
running
in
the
container,
so
files
networking
anything
root
can
do
anything.
It
wants
right.
D
App
uses
root
to
change
ip
tables
and
send
information
to
the
wrong
place.
Something
silly
like
that,
or,
of
course,
change.
B
Configuration
files
all
right,
so
here's
how
it
looks
right
now,
goals,
avoiding
root
and
containers
can
help
too,
and
this
is
high
level,
then
how
improve
the
security
and
behavior
of
applications.
So
this
will
be.
We
could
say
a
high
level
goal
out
of
the
defense
in-depth
strategy
against
external
compromises
again
high
level
tied
in
with
all
the
other
work
we
can
do
and
then
a
specific
avoid
compromised,
apps
from
causing
more
damage.
B
B
Comments
looks
like
well
I'll,
just
read
it
for
those
haven't
seen
it
when
building
a
container,
the
container
should
be
built
to
run
its
processes
as
a
non-root
user
setup.
Sid
processes
should
not
be
required
to
do
the
work
inside
a
container
again.
This
is
the
best
practice.
The
root
user
is
a
container.
B
The
root
user
in
the
container
has
fewer
rights
and
is
distinct
from
the
platform's
group.
The
containerization
process
includes
a
user
using
a
c
group
user
c
group,
which
means
the
containers.
Users
are
distinct
from
the
platform's
users
and
do
not
include
the
most
dangerous,
elevated
rights,
so
victor
you
talked
about.
B
This
is
the
case
for
the
mapping
from
the
container
from
the
platform.
If
it's
actually
enabled-
and
ian
was
saying-
maybe
we
should
talk
about
best
practices
that
may
be
a
a
platform
type
of
best
practice
that
you
should
do
that
and
always
enforce
it,
and
I
made
a
a
change
here.
Victor
and
it
looks
like
you
did
something
an
exception
to
that
would
be
separation.
Container
runtime
is
not
using
username
spaces,
but
it
looks
like
you've
made
another
change,
yeah.
E
Well,
I
was,
I
was
just
trying
to
clarify
the
first
thing,
which
is
talking
about
rights
and
linux
kernel
capabilities.
The
first
thing
that
you
mentioned
in
the
beginning:
it's
more
like
yeah,
so
I
guess
it's
more
accurate.
I
think
then,.
G
B
E
B
B
All
right
and
then
and
it's
confusing,
you're
correct
and
what's
fixing
it's
username
space,
not
a
subgroup,
so
we
use
the
wrong
word
but
namespaces.
Some
c
groups
do
very
similar
things.
Okay,
so
I
don't
think
he
oops
I
scrolled
way
too
far.
I
don't
think
that
ian
is
disagreeing.
B
He
didn't
explicitly
give
a
thumbs
up,
but
he's
saying
the
words
wrong.
So
I'm
gonna
say
that
sounds
like
agreement
and
I'm
good
with
committing
this
and
ian,
and
I
like
submitted
this
best
practice
together.
I'm
I'm
good
with
just
taking
this
one.
They
said.
G
B
And
you
could
add
it
right
in
here
to
the
as
a
comment
too
penkai.
B
B
B
B
B
Well,
you
can
put
it
down
and
then
we
can
check
it
out
we're
trying
to
get
down
to
the
point
where
we
can
actually
get
plus
ones
right
now
we
have
please
updates,
let's
see
if
yeah
only
place,
updates
all
right.
So
let's
go
on
we'll
come
back
to
yours
in
a
moment,
ponchai
so
under
tradeoffs
constraints,
caveats
and
any
notes,
that's
a
big
section,
header.
B
Right
vulnerability,
malicious
container
with
minimal
user
action
of
rats
host
runs
the
binary
gains
root
level
code,
some
other
things.
Oh
yeah,
that
sounds
good,
just
add
it
in,
and
so
this
section
is
it's
under
the
notes
area
just
so
that
people
can
look
at
more
info
and
we
have
references
so
that,
if
someone's
wondering
why
we're
suggesting
this
as
a
best
practice,
what
benefits
and
everything
else,
this
is
references.
So
you
can
go
read
what
folks
in
the
industry
are
doing
so.
B
Yes
to
add
that
if
you'll
do
a
suggest
edit
vector,
but
where,
in
the.
B
Alternatives,
so
we
just
put
a
couple
of
things
in
here.
I
don't
I
don't
know
these
are
alternatives.
What
other
things
you
might
do,
you're
allowing
root?
What
you
could
do
talked
about
rootless
victor.
You
put
this
forward.
We
talked
about
this
a
bit
and
kept
on
that
a
new
cap
to
address
some
rootless
stuff,
and
I
think
the
comments
were
saying
that
this
may
be
a
little
different
from
this
best
practice,
but
there's
no
hasn't
been
any
updates.
B
D
I'm
I'm
a
little
confused
about
this
alternative
section.
Are
we
talking
about
alternatives
to
applying
the
best
practice
or
caveats
or
ways
to
mitigate
there?
There's
there's
a
huge
discussion
that
could
can
be
had
here.
B
Yeah
though
this
would
be
alternatives
to
using
the
best
practice,
so
we
have
the
caveats
and
you're
in
here's
problems.
You're
gonna,
see
or
notes
where
you
go.
You
know
whatever
other
comments
when
you're
using
the
best
practice-
and
this
is
alternative
paths
and
it
may
not
be
necessary
on
every
best
practice
but
and
we're
not.
D
So
the
assumption
here
is
that
somebody
is
not
able
to
apply
the
best
practices.
So,
okay,
if
you,
if
you
absolutely
have
to
use
roots,
here's
what
here's,
what
you
can
do
that
could
be
close
to
that.
Is
that
what
we're
saying
so
it's
like
compromises
rather
than
alternatives,
because
they're
not
alternatives
to
there,
is
no
alternative
to
not
using
root.
B
Maybe
maybe
alternative
slash
compromises
for
this
section
would
be
good.
So
if,
if
we
there
probably
are
best
practices
where
you
could
have
the
same
outcome
with
two
different
best
practices-
and
maybe
this
one
doesn't
we're
just
saying
you're,
either
going
to
use
root
or
you're
not,
and
if
you
don't
and
you
compromise,
then
here's
some
other
paths
to
deal
with
it.
D
I
I
guess
what
I'm
looking
for
is
something
like
considerations
right:
okay,
why?
Why
do
you
absolutely
need
to
use
root?
And
if
you
do,
what
can
you
do
about
it?
Something
something
like
that
that
that
to
me
is
where
it
could
become
useful.
Do
not
run
the
container
in
privilege
mode.
I
guess
that's
what
it
means.
Well,
I
I
is
that
an.
D
It's
a
different
approach
to
and
it
achieves
something
else
so
again
going
back
to
the
goals
you
know.
If
these
are
our
alternative
ways
to
achieve
the
goals
are
goals.
Some
of
them
are
extremely
general
right.
So
if,
if
you're
looking
for
an
alternative
way
to
make
your
application
more
secure,
there
are
lots
of
other
things.
We
can
suggest
sure.
B
So
if
we
don't
have
anything
specific
like,
then
we
just
leave
it.
We
don't
want
to
block
this,
but
if,
if
there's
something
like
victor
saying
using
so
alternative
slash
compromises,
whatever
we're
going
to
say
on
this,
then
maybe
one
of
them
would
be.
If
you
must
use
root,
you
could
take
a
look
at
using
kata
containers
which
give
more
isolation
and
then
a
link
over,
and
we
don't
talk
about
it
in
depth.
B
B
A
D
I
guess
I
think
here
is
very
beneficial.
I
I
kind
of
think
that
everything
else
we
had
in
the
document
so
far
is
to
me
reads-
is
kind
of
trivial.
I
know
we're
picking
on
low
hanging
fruit
here,
because
we
want
to
get
something
out,
but
it's
it's
fairly
obvious.
Most
of
it.
I
I
think
where
we
can
make
a
contribution,
is
exactly
in
this.
Well,
if
you
can't
run
root
here,
here's
an
in-depth
discussion
of
of
how
workarounds
you
know
rather
than
alternatives,
maybe
another
way
to
think
of
it
as
workarounds
right.
D
You
absolutely
must
run
root.
Here
are
a
bunch
of
suggestions
we
have
for
for
how
you
can
work
in
that
situation,
then
suddenly
the
document
becomes
useful.
G
Yeah,
I
I
agree
100,
I
think
that's
the
gist
of
this
work
group
to
find
these
to
come
up
with
this
recommendation,
I
mean
saying
you:
don't
have
to
run
root.
You
don't
need
this
word
group
to
say
that,
but
we
as
a
work
group,
I
think
we
our
responsibility,
should
be
analyzing.
Why
do
network
functions
need
root
like,
for
example,
if
you
need
to
create
a
raw
socket
for
your
crazy
protocol?
Okay,
how
do
you
do
that?
Just
saying?
Don't
run
root?
G
Okay,
so
I
don't
can't
use
my
protocol,
so
we
need
to
discuss
here
ways
that
maybe
kata
containers
is
one
thing,
maybe
others,
but
I
agree
with
100.
This
is
what
we're
here
for
to
to
help
people
with
solution,
not
just
saying
giving
them
the
don'ts
but
giving
them
the
dues
as
well.
B
B
F
G
It's
not
even
worker
and
that's
exactly
like.
That's
the
whole
thing
that
we're
trying
to
define
here.
It's
not
a
workaround,
it's
like
the
solution,
so
the
problem
is,
you
cannot
run
root
and
here's
the
solutions,
solutions
that
we
are
proposing
for
you,
so
I
wouldn't
call
them
even
work
around
them.
I
would
call
them
like
recommendations
or
solutions
or
whatever.
D
D
D
B
So
what
we're
talking
about
here
is
the
best
practice,
not
the
exceptions.
So
in
the
best
practice
you
should
do
no
root,
and
now
we
say,
but
what?
If
we
have
another
use
case
where
we
say
we
must
have
some
type
of
privileges,
and
maybe
that
means
that
you
say
well,
you
should
you're
going
to
need
root
and
you
we
suggest
you
run
it
in
kata
containers
or
you're
going
to
need
root,
and
we
suggest
that
you
split
it
off
and
run
it
somewhere.
I
don't
know
whatever.
That
is
that's
fine.
B
It
wouldn't
be
in
this
best
practice,
so
we're
not
giving
the
solutions
in
this
particular
one
for
running
root.
That
will
be
an
additional
document
which
we
can
link
in
here.
So
if
we
write
those
up
and
we
do
the
work
on
it,
we
can
put
whatever
we
want
to
call
this
section
alternatives
or
best
practice.
We
can
have
another
section
best
practices
for
when
you
need
root
and
we
will
link
out
to
that
which
will
be
a
different
document.
D
E
And
taylor
regarding
this
section
is
just
related
to
cure
matters
or
just
cns
in
general,
or
I
mean,
for
example,
user
remap
is
not
supported
by
kubernetes
by
now,
but
it
is
supported
by
docker,
so
maybe
using
user
namespace
remap
can
also
mitigate
that.
That
problem
like,
but
definitely
it's
not
going
to
be-
is
it
still
not
supporting
kubernetes
yet
so.
B
All
right,
like
the
is
it's
coming,
related
practices.
Okay,
it's
I'm
trying
to
find
a
word
tal
that
fits
what
we're
talking
about
here.
This
section
is
to
point
people
to
and
other
places,
you've
you're
saying
we're
going
through
this
and
some
people
may
agree
not
agree
with
naruto
or
whatever.
Hopefully
we
convince
them
for
the
case
they
can,
but
for
your
case
tal
and
randy,
you
get
to
a
point
where
you
go.
We
understand
this
is
a
best
practice,
but
we
have
to
do
it.
B
So
what
do
we
do
so
this?
I
think
this
section
is
supposed
to
kind
of
point
people
somewhere
else
and
right
now
it
would
be
very
limited
because
we
don't
have
anything
else
other
than
we
can
kind
of
point
some
stuff
out,
but
would
related
practices,
alternatives,
related
practices.
D
Sorry
go
ahead,
not
avoid
them.
I
I
just
wanted
to
say
taylor.
You
said
you
know
in
the
future,
we
can
have
more
prs,
let's
just
not
waste
time
on
it.
Right
now,
remove
it.
If,
in
the
future,
we
want
to
add
something,
maybe
the
name
would
be
more
apparent
once
we
actually
have
content.
B
I
want
to
see
what
victor
you
come
up
with
and
if
I
don't,
if
we're
right
now,
we
don't
have
any
plus
ones,
but
I
we're
we
still
need
the
use
case
so
maybe
next
week,
if
we
don't
have
anything
useful
in
here
victor.
If
you
add
anything,
then
we
can
take
a
look
and
I'll
think
about
it,
tal
for
just
deleting
or
not
on
the
wording,
but
add
a
comment
here.
If
you
can
tell
on
your
thoughts
like
about
the
section
and
and
stuff
so
we'll
be
able
to
come
back
to
that.
B
G
I
mean
if
we
just
say
you
cannot
use
root,
that's
it!
Okay.
How
much
value
did
we
bring
to
the
end
you
to
the
to
the
audience?
I
mean
if
we
say
okay,
you
cannot
use
root,
but
here's
some
further
reading
or
some
suggestion
to
where,
where
you
might
start,
I
think
that's
more
powerful
than
just
saying
you
cannot
use
root
period,
go
figure.
It.
B
B
Alternatives,
there's
like
something
you're,
saying
or
anywhere
it's.
This
is
like
it's
suggestions.
G
B
B
B
Probably
what
that's
going
to
happen
is
iterative
for
this
suggestions,
for
you
want
something
like
this
for
when
you
must
use
root,
something
like
that
yeah,
but
we
don't
we're
not
ready
there
yet,
but
that's
what
we
want,
I'm
going
to
delete
that
for
now.
B
D
D
B
So
this
section
is,
let's
see,
oh
sorry,
do
not
run
the
container
in
privilege
mode.
Okay,
I'm
just
going
to
grab
that
pankai
that
one's
pretty
straightforward.
E
F
B
B
B
B
B
B
B
D
I
don't
think
so
kind
of
left
it.
Where
was
the
problem
is,
I
think,
there's
just
discussions
there
that
haven't
been
resolved.
We
can
revisit
and
talk
again.
D
I've
resolved
a
few
that
seem
to
me
seem
to
me
to
be
resolved,
but
for
some
of
them
I'm
not
sure
everybody
is
completely
on
board.
So
yeah.
B
We
don't
have
to
have
agreement
if
we
can
have
a
if
we
feel
like
everybody's
been
heard
and
we're
at
a
point
to
accept
it.
Even
if
we
disagree
are
we
at
a
point
to
accept
it,
as
is
where
we
can
update
it.
So
this
physical
network
function,
pnf
definition,
there's
been
a
lot
of
talk
about
it,
but
no
suggest
edits
and
I
don't
think
any
right.
Yeah.
That's.
D
Why
that's
why
I'm
stuck
a
little
bit?
I
feel
like
a
lot
of
these
conversations
are
just
conversations
which
is
fine.
B
Yeah,
so
is:
is
this
one
one?
Where
do
we
have?
Are
there
any
objections
to
resolving
it
for
now,
as
is
to
keep,
and
then
we
can
go
update
the
glossary
later,
if
there's
changes.
H
Also
regarding
the
glossary,
we
have
another
discussion
for
some
networking
terms
for
the
glossary.
This
hasn't
moved
for
for
a
while.
There's
no
objections
on
the
terms
currently.
So,
if
you
people
can
just
review
it
a
bit
and
maybe
we
can
create
an
extra
pr
for
that,
if
everybody
is
on
board
with
those
terms,
I
have
pasted
the
link
to
the
to
the
agenda
so.
D
D
Right
that
actually
seems
sensible
to
me
to
have
the
discussion
in
discussions
and
then
maybe
create
a
pr
from
that,
but
I
I
don't
know
I
mean
we
can
still
I'm
not
trying
to
push
my
pr
through,
but
we
can
accept
my
pr
and
just
treat
it
as
a
draft.
You
know
and
continue
continue.
Iterating.
B
The
pnf
and
let's
go
ahead,
yes
for
talking
on
the
discussion
board,
that's
what
those
are
for.
We
can
keep
if
there's
someone's
unhappy
with
something
that's
being
merged.
Please
continue
on
the
discussion
board
or
create
a
new
pr
and
demetrius.
If,
if
you
have
something
specific
that
you
want
to
add,
ideally
glossary
terms,
we
want
to
add
the
minimal
amount
necessary
at
any
given
pr
so
that
we
can
get
it
through
sooner.
B
D
That
was
the
most
controversial,
but
the
the
the
one
problem
with
removing
this
cloudified
network
function
term
it
I
and
the
and
the
knf
term.
I
refer
to
this.
I
use
it
as
a
classification,
and
here
I
explain
kind
of
why
that
is
needed.
I
didn't
have
a
real
response
to
my
response,
so
I
anyway,
I
feel
like
it's
still
just
unresolved.
D
B
Sounds
good:
let's
do
that
and
please
tell
check
out
the
try
to.
I
guess
add
any
comments
on
ones
that
you
fill
or,
if
you're
good,
to
go
forward
with
any
given
one
then
give
it
a
plus
one
as
a
work
in
progress,
and
if
anyone
else
has
comments-
and
please
add
them
and
we'll
continue
with
that,
one
continue
with
glossary.
B
D
The
the
biggest
block
right
now
is,
in
fact
you
taylor,
you,
you
had
the
biggest
objection
to
the
clarification,
clarified
network
function
term,
and
maybe
we
can
just
discuss
privately
and
see
if,
if
there's
some
compromise,
we
can
find.
D
That's
that's
my
way.
The
comments
just
start
getting
very,
very
long,
long
speeches
about
terms,
so
I
feel
like
we're
in
a
bit
of
an
impasse
a
there
so
but
yeah
we
can.
We
can
discuss
this
next
time.
Sorry,
don't
want
to
take
more
time.
People
have
to
go
thanks.
Everyone
see.