►
From YouTube: CNCF Telecom User Group Meeting - 2020-04-06
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
A
Yeah,
can
you
can
you
add
the
link
in
to
the
because
my
my
eleven-year-old
is
doing
zoom
just
learning
from
home
now
and
he's
going
to
very
much
want
that
added
yeah.
A
Well,
with
my
background
right
now,
but
okay,
so
first
of
all,
I
do
just
want
to
say
that
these
are
very
challenging
times
right
now
and
so
I
very
much
appreciate
getting
444
participants
on
the
call
is
great
and
I
hope
that
all
of
you
are
safely
able
to
work
at
home
and
your
loved
ones
and
friends
and
such
are
doing
well
so
I'm
here
in
New,
York
and
my
family
is
fine.
But
certainly
we
are
kind
of
battened
down.
A
So
in
terms
of
this
telecom
user
group,
I
went
out
that
last
week
we're
supposed
to
be
cute,
calm,
Amsterdam
and
that's
when
we
wanted
to
be
releasing
the
prologue
white
paper
that
got
delayed
several
weeks
with
the
virus
and
then
with
me
focused
on
a
board
meeting
last
week.
But
I
am
actually
trying
to
get
that
finalized
in
the
next
week
or
two
and
then
to
move
on
to
ideally
a
second
or
third
white
paper.
A
And
so
the
aspiration
so
far
at
least
on
these
white
papers,
is
that
they
not
be
enormous,
ly,
controversial
or
shocking
documents
and
instead
that
they
kind
of
catalogue
a
moment.
A
point
in
time
that
we
can
have
a
vocabulary
and
agreement
on
process
and
such
and
then
with
an
understanding
that
they
will
evolve
over
time.
A
I
think
the
problem,
the
prologue
very
much
accomplishes
that
and
then
I
do
have
another
white
paper
that
I'm
gonna
be
sharing
very
shortly,
which
is
largely
about
trying
to
get
across
some
of
the
ideas
in
this
CNF
conforming
to
slide
deck.
That
most
of
you
have
reviewed
in
the
past,
so
I
think
that's
the
main
updates
that
I
want
to
give
on
the
on
the
white
paper.
A
We're
gonna
have
this
call
in
two
weeks
on
a
more
China
friendly
time,
I
hope
at
least
many
of
our
Europeans
here
will
be
able
to
join
that
one
as
well
and
I'll.
Look
to
have
meaningful
progress.
I'll
also
be
announcing
the
plans
or
schedules
as
such,
in
both
the
email
and
the
slack
and
the
github
repo.
So
no
one
should
be
surprised
by
it.
So
then,
let
me
just
see
if
there's
any
comments
or
questions
or
thoughts
about
on
the
white
paper
before
I
go
to
the
next
next
topic.
A
Okay,
well
so,
in
a
minute
I'd
like
to
have
Taylor
and
his
team
walk
us
through
the
progress
on
this
CNF
conformance
test
suite,
but
before
he
does,
that
I
think
maybe
it
would
make
sense
for
it
looks
like
Robby's
not
on
for
her
way
to
take
us
through
some
of
the
CN
TT
work.
That's
occurred
in
the
last
month
or
so,
and
I
think
would
be
a
useful
context
for
talking
about
the
CNF
conformance
test
suite.
We
are
you,
okay.
With
that
order,
would
you
prefer
the
other
direction.
C
Indirect
or
from
front
registries,
we
will
work
on
both
the
implementation
and
certification
part
and,
of
course,
we
truly
believe
that
this
should
be
worked
together
with
the
CN
CF,
the
nikon
user
group
and
and
c
NT
t--.
Also,
we
will
have
what
we
call
a
virtual
face-to-face
meeting,
so
it
will
be
basically
a
virtual
conference
for
several
days
discussing.
C
The
the
topics
of
ce
NT
t--
and
I
think
Robby
posted
the
schedule
to
the
minutes
and
we
will
have
a
deep
dive
about
the
reference
attitude
to
on
22nd
of
april
from
11:00
know.
It's
like
11:15
UTC
will
have
a
deep
dive
one
on
the
reference
architecture
to
then
we
will
have
a
deep
dive
on
the
reference
implementation
to
which
is
the
coitus
based
one
and
then
a
deep
dive
about
the
reference
certification.
C
C
The
so
how
the
reference
conformance
to
can
Intel
work,
with
with
the
other
conformance
frameworks
and
and
tests,
so
that
will
start
from
11
o'clock
UTC
April
23rd,
and
it
would
be
really
good
if
you
could
find
the
time
to
join.
All
of
these
sessions
will
be
on
/
zoom
and
without
any
registration
fee
and.
D
Point
that
maybe
it
worth
mentioning
Kobi,
PFS,
211
or
BP
phase
2
now
has
greatly
mentioned
we're
working
very
closely
in
the
in
see
entity
to
define
requirements.
We're
looking
forward
to
discussing
more
with
the
tag
and
CNC
have
testbed
and
conformance
tests
around
the
RC,
especially
when
it's
that
we
start
kicking
it
on
now
to
formalize
this
as
an
industry,
xi
is
bringing
the
whole
vp
cloud
native
certification
program
that
will
allow
CNF
as
well
as
infrastructure,
to
be
certified
against
the
sea
entity
requirements.
D
You
this
case
is
written
by
various
communities,
including
the
cnc
of
projects.
Now
that
would
mean
more
collaboration,
I
think,
would
be
useful
between
11
quality
ways
to
team
and
the
tog,
and
in
particular,
do
you
see
any
areas
where
potentially
we
could
have
some
john
sessions
or
some
discussions
needed?
How
do
you
like
to
approach
this
particular.
A
E
C
C
A
C
A
C
A
G
G
So,
on
the
CNF
conformance,
there's,
probably
some
updates
on
the
Senath
testbed
a
little
bit
related,
but
focus
on
the
scene
of
conformance
first,
so
most
of
the
work
has
been
on
the
workload
sites
of
CNS,
actually
testing,
CNS
or
components
of
applications.
That
would
be
running
on
top
of
a
platform
and
that's
been
continuing
as
far
as
adding
tests
that
are
focused
on
checking
compliance
with
cloud
native
principles.
So
these
are
not
focused
on
say,
integration
tests
or
anything
like
that.
G
At
this
point,
those
are
probably
out
of
scope,
but
the
the
main
focus
has
been
adding
more
tests
to
validate
the
cloud
native
principles
and
then,
in
addition
to
that,
we've
been,
it's
been
primarily
focused
on
the
development
of
those
and
making
sure
that
environment
for
doing
the
test,
building
the
test
and
then
doing
validating
that
everything
is
working
as
expected
from
a
testing
same
points
been
working.
So
we
now
have
the
test
running
from
a
CI
system
and
and
SPECT
test
for
the
entire
conformance.
G
We
turn
out
running
on
every
commit,
so
that's
been
part
of
the
effort
and
then
concurrently
what
we've
started
looking
at
was
how
we
can
be
aligned
with
some
of
the
Santa
T
works.
So
looking
at
we've
been
collaborating
and
working
in
the
RI
to
meetings
as
as
well
as
the
new
and
upcoming
rc2
for
the
conformance
and
then
doing
a
very
deep
analysis
of
the
requirements
on
the
Santa
T
reference
architecture.
G
So
we
were
hoping
to
publish
from
the
assessment
and
there's
some
tickets
and
stuff
I'm
posting
a
few
things
in
the
chat.
But
what
we're
hoping
to
have
as
a
result
of
this
is
some
documentation
that
will
go
into
the.
Why
paper
I'm
sorry
into
not
the
light
paper,
but
a
document
that'll
be
on
the
github
page
for
the
scene
of
conformance
about
testing
for
the
platform
itself.
G
So
we've
been
on
the
workload
now
we're
looking
at
how
to
test
cloud
native
aspects
on
the
platform
itself
and
what
we
expect
and
what
we're
finding
right
now
is
is
there's
some
portion
of
the
platform
that's
being
built
for
Santa
T
platform
that
should
be
covered
by
either
kubernetes
conformance
or
maybe
the
extended
eight
a
test.
So
some
of
the
some
of
the
aspects
in
the
requirements,
the
actual
Santa
T
requirements,
look
like
they're
going
to
be
covered
and
then
outside
of
that.
What
items
could
we
cover
with
other
upstream
tooling?
G
So
that's
kind
of
the
path,
and
this
would
lead
to
complimentary
work
with
Santee
T
on
the
reference
implementation.
So
if
you
look
at
I,
don't
think
I
gave
this
link.
So
if
there's
a
lot
of
links
inside
of
the
sandy
t.ri
to
works,
room
meeting
notes
where
they
go
to
Sandy
T's
specific
tickets
on
stuff,
like
what
lab?
What
labs
could
we
build
for
the
RI
to
on
the
Santee,
P
side,
weather,
different
stages
and
layers
for
the
sandy
T
reference
implementation,
the
platformer?
We
should
say
the
reference
architecture
and
then
how
does?
G
How
can
we
choose
those
so
I
think
there's
complimentary
efforts
that
go
between
the
needs
of
the
screen
of
conformance
on
the
platform.
We
need
to
be
able
to
have
a
platform
that
we
can
test
the
CNF
conformance
similarly
to
our
IT
RI.
To
is
a
way
to
say
here:
are
the
CMT
T,
here's
a
C,
NT
T
platform.
G
So,
looking
at
those
and
thing
where
it,
overlaps
has
been
a
lot
of
the
efforts
and
we've
been
because
we've
been
using
the
CNF
testbed
to
bring
that
back
for
the
CNF
conformance
to
deploy
a
platform
unto
packet
with
bare
metal
machines
and
provision.
Networking
automatically
and
stuff
we've
been
looking
at
what
aspects
map
between
the
c
NT
t--
reference
architecture
to
requirements
and
what's
covered
by
what
we
can
deploy
and
we're
building.
G
G
G
C
D
G
B
G
G
What
we're
looking
at
is
what
are
the
aspects
of
the
platform
that
should
be
that
we
could
cover
from
a
cloud
native
aspect,
and
this
this
particular
document
is
the
high
level
of
that
and
then
thinking
of
stuff
like
this
is
a
translation
of
requirements.
So
maybe
the
requirement
for
CR,
DS
and
using
let's
say
ap-
is
open,
api's
and
other
stuff
could
map
to
stuff
like
CR,
DS
and
config
Maps,
and
then
does
it
use
device,
plugins
and
other
things.
G
This
is
a
high-level
breakdown
and
trying
to
map
as
much
as
possible
in
this
and
and
then
looking
at
stuff
like
this
is
where
we
talk
about
coverage,
so
this
particular
area
on
network
acceleration.
This
this
covers
a
few
of
this
chapters
and
the
NTP
reference
architecture.
So
what
are
we
looking
at
for
kubernetes
coverage?
Well,
there's
a
lot
of
stuff
that
looks
like
it
should
be
covered
at
least
partially.
So
this
is.
This
is
kind
of
an
estimate.
G
If
you,
if
you
saw
the
like
the
even
like
this
reference,
it's
a
massive
amount
of
stuff
that
is
primarily
from
looking
at
the
language
internally
for
the
scene
of
conformance
and
then
kind
of
mapping
that
out
it
doesn't
without
understanding
from
the
side
of
the
code
and
other
aspects
of
the
CNF
conformance
it
wouldn't
make
as
much
sense.
So
we
need
to
take
these
and
make
it
into
something
that
that's
usable
outside
does
a
full
mapping.
So
that's
the
effort.
G
Now
this
was
the
first
effort
to
internally
see
and
wet
there's
a
ticket
I
think
this
the
103.
So
this
is
the
current
one
of
the
main
focuses
is
a
more
in-depth
view
of
the
kubernetes
testing
can
amount.
So
this
is
breaking
down
each
of
those
requirements,
and
this
is
using
the
language
should
may
mess
should
in
May,
so
optional.
Is
it
optional?
Is
this
recommended?
G
G
Some
of
them
can
go
directly
like
virtual
compute.
This
seems
to
be
a
must
they're,
not
all
labeled,
but
we've
tried
to
interpret
as
much
based
on
the
the
other
knowledge
that
we
have
from
going
through
these
and
then
looking
at
stuff.
Like
is
this
in
scope,
so
virtual
networking
resource
this
in
the
CNT
tea
context
means.
Can
you
have
a
virtual
network
interfaces
with
some
other
hardware,
specific
things?
This
is
outside
of
scope
of
kubernetes.
G
It
doesn't
mean
it's
outside
of
scope
for
a
cloud
native
conformance,
but
are
we
going
to
test
it
immediately
with
kubernetes
tests?
Probably
not
so
we
said
it's
not
part
of
conformance,
it's
not
part
of
ad,
and
then
it
could
be
part
of
the
kubernetes
extensions
or
add-ons.
So
this
would
be
say:
C&I
plugins
could
give
you
that
capability.
G
G
I,
don't
know
if
folks
are
saying
the
chat
messages,
but
the
goal
here
again
is
to
take
this
and
have
something
published
into
github
so
that
we
can,
or
somewhere
that's
shareable,
so
that
we
can
start
using
it
to
talk
about
the
complimentary
goals
between
the
different
projects,
and
this
can
not
only
go
into
stuff
like
what
CNT
tea
is
doing
with
our
i2
and
our
c2,
but
also
a
VP's
work
and
other
initiatives
and
projects.
I.
D
Think
this
is
amazing
work
you
see
any
potentially
of
giving
some
feedback
to
see
entity
based
on
you
analysis,
because
I
think
one
of
the
things
that
we
really
need
to
get
good
grip
on
the
feedback
loop.
Well,
if
you
see
during
the
assessment,
has
any
suggestions
or
communication
to
see
entity
to
change
any
aspect
of
what
we
do.
These
would
have
been
good
in
the
assessment.
Or
how
do
you
see
that.
G
Absolutely,
as
we
were
on
the
RI
we've
been
following
the
RI
to
work
stream
and
we've
attending
those
and
trying
to
get
feedback
directly.
There
talked
up
talking
a
lot
with
Tom
and
Bill
from
Litzy
and
and
other
folks
as
they've
been
joining
and
trying
to
help
with
those
some
of
those
are
specifically
about
trying
to
bring
up
the
lab
and
other
things
and
and
then
feeding
back
into
the
reference
architecture
itself.
I.
G
That
is
definitely
something
I
think
would
be
good
and
we're
trying
to
do
that.
I
I
think
as
we're
pulling
this
together
over
the
next
few
weeks,
and
maybe
some
of
that
can
directly
go
back
in
so
that's
a
goal
and
I
think
something
that
we
can
keep
doing.
If
there
are
some
specific
workstreams
that
would
be
good
to
collaborate
on
there's
a
lot.
G
G
G
What
I
just
shared
ace,
a
Google
spreadsheet
that
I
think
probably
would
end
up
getting
moved
over
to
I,
can
assure
my
screen.
It's
shared
in
the
zoom
chat,
but
this
is
the
start
of
a
spreadsheet
that,
and
we
started
on
just
last
week,
copying
stuff
from
the
massive
amount
of
hack
and
detox
into
a
spreadsheet,
which
I
think
could
be
moved
into
the
LF
c
ntp
wiki
in
a
spreadsheet
format,
it's
hard
to
work
in
a
spreadsheet.
G
So
this
is
why
it's
it's
delayed,
but
the
idea
would
be
to
have
something
that
lists
all
of
the
requirements
which
we've
been
trying
to
do,
they're,
not
in
a
format.
That's
throughout
the
entire
document.
That's
directly
explicit.
This
is
a
requirement.
Some
of
them
say
this
is
a
requirement
and
it
must
be
some
of
them.
G
You
have
to
enter
it
by
context
of
paragraphs,
but
building
out
a
say
table,
probably
for
break
break
down,
and
you
can
see
this
is
kind
of
an
idea
of
it
of
each
chapter
and
probably
sections
and
then
saying
whether
it's
a
must
should
or
may
type
of
requirement
what
sections
are
in
would
be
a
good
thing
for
everybody
engaged
and
so,
as
part
of
our
to
discussions
started
building.
This
I
think
what
one
thing
that
this
would
lead
into,
which
is
an
open
open
tickets
on
the
Santee
T
side,
is
features.
G
So
if
you
look
at
requirements,
you're
going
to
take
those
requirements
and
eventually
build
out
end
user
features
and
to
get
those
you
need
to
be,
if
you
have
any
user
features,
you
need
to
say
what
are
the
requirements.
So
that's
I
deal
with
this.
The
requirements
behind
it
that
we
actually
need
to
confirm,
and
then
we
can
end
up
with
items
like
this.
So
is
this
a
physical
or
platform
I've
added
some
other
sections
here
that
started
to
put
in
tying
in
with
what
I
was
discussing
earlier.
G
Like
is
this
covered
by
seeing
a
conformance
or
is
it
covered
by
AED
test?
There's,
probably
other
aspects
that
we
could
put
in
here.
That
would
be
useful
for
a
broader
audience
and
with
that
I
think
we
could
share,
share
a
lot
I'm
going
to
dilute
that
by
accident.
But
this
is
just
kind
of
an
idea
to
discuss,
and
maybe
something
like
this
would
be
good
on
the
ra2
and
I'll,
make
sure
and
look
at
those
meetings
and
try
to
get
that
on
my
agenda.
G
D
G
Imagine
that
the
different
initiatives
are
going
to
have
slightly
different
angles.
Some
of
them
will
be
shared,
but
there
will
be
overlap
and
I.
My
hope
would
be
that
we
can
find
the
complementary
areas
and
then
outline
those,
of
course,
any
missing
gaps
or
anything
that
could
help
each
other,
but
I
think
ovp
would
be
one
area
where
there's
going
to
be
overlap
between
I'll,
say
CNF,
conformance
and
say
the
CNF
testbed,
which
has
goals
beyond
the
CNF
conformance
like
the
use
cases,
but
I
think
OB.
G
P2
is
going
to
have
items
that
overlap
and
then
other
items
that
are
going
to
be
beyond,
say
the
CNF
conformance
that
need
to
be
tested,
or
would
it
be
desired
and
I
believe
that
there's
there's
probably
other
groups
and
initiatives
and
stuff,
and
you
could
think
even
direct
projects.
So
if
we
have
requirements
listed
clearly
and
people
can
understand
those,
then
in
projects
that
are
trying
to
provide
those
would
be
able
to
improve
themselves.
So
that
could
be
specifically
something
like
a
project.
G
D
G
That's
not
like
I'm
on
a
related
note,
something
that
I
hadn't
pointed
out.
Yet
it
was
the
school
some
type
of
scoring
system
or
results
from
running
CNF
conformance.
So
that's
something
that
we've
had
in
mind
and
if
you're,
if
you
look
at
the
slide
deck
that
Dan
shared
earlier
about
the
scene
of
conformance,
we
don't
yet
know
what
it's
going
to
look
like
what
we
think
will
probably
happen
as
some
type
of
spectrum
and
then
within
that
spectrum
of
us
scores.
G
You
could
say
there
could
be
categories
and
that's
where
gold,
silver,
bronze
and
other
things
and
I
come
from,
and
we've
been
looking
to.
How
scoring
could
work
and
probably
end
up
having
groups
based
on
the
the
categories
which
are
the
categories
of
scenic
informants
are
based
on
cognitive
principles,
essentially
and
then
within
those
you're
going
to
have
pieces
that
could
test
different
aspects
of
either
the
workload
component,
a
CNF
or
a
platform,
and
within
that
you're,
going
to
end
up
with
a
large
set
of
small
tests.
G
If
you're
familiar
with
it's
like
any
any
type
of
testing
for
market
it'll
get
done,
the
past
fell.
So
how
that
rolls
up
into
weights
on
scoring
that's
some
of
the
efforts.
That's
been
happening
over
the
last
couple
of
weeks,
and
this
is
more
of
what's
in
an
a
potential
idea.
Maybe
you
could
think
of
this
as
like
a
prototype
scoring.
So
there's
some
efforts
on
that
right
now,
so
that
we
can
have
some
type
of
discussion
over
the
scoring
and
I.
G
Think
one
of
the
big
aspects
we'll
have
to
get
will
want
to
have
feedback
on
the
important
items.
Some
of
those
we
can
infer
from
likes
aunt
Edie's
reference
architecture
where
it's
a
hard
requirement,
then
it's
probably
important
for
operators.
So
that
probably
means
that
we
need
that
to
be
a
stronger,
more
weighted
type
of
test,
potentially
and
others.
We
may
need
feedback
on
weighting,
and
this
could
be
anything
from
a
group
of
tests.
G
Would
give
you
more
positive
points.
Let's
say
to
the
to
the
maybe
the
extreme
end.
If
you
fell
one
of
the
tests,
that's
are
very
important,
then
you
could
potentially
fill
the
whole
test
and
others
may
be
marked
as
completely
optional.
Just
like
the
same
TD
requirements
that
you
have
a
May,
which
is
an
optional
requirement
and
if
you
fell
those
then
it
may
have
any
effect.
But
it's
a
positive.
If
you
have
it.
G
Yes,
some
type
of
waiting
for
that
it
may
not
be
a
direct
mapping
to
see
entity
on
those.
There
may
be
something
that's
say:
a
should
so
recommended
requirement
from
the
san
TT
side
and
then,
but
looking
at
it
from
the
CNF
conformance.
It's
a
must
for
the
cloud
native
side,
or
maybe
it's
a
completely
optional.
It's
it
doesn't
matter
from
the
cloud
native
side,
so
I
think
there's
going
to
be
overlap,
but
not
a
direct
one-to-one
mapping.
D
One
more
thing
we're
doing
in
see
entity
we're
introducing
the
concept
of
exceptions,
meaning
we
might
have
a
shield
requirement
that
will
move
to
become
a
must
in
the
next
series,
and
this
is
where
we
trying
to
manage
that
transition
of
the
workload
from
being
a
seminal
cloud
native
into
cloud
native.
So,
for
example,
we
might
allow
a
particular
technology
to
be
used
in
the
cities,
but
the
next
releases,
with
expectations
for
vendors
to
move
away
from
their
given
technology.
So
that
requirement
that
used
to
be
sure
that
will
become
must.
D
G
I
think
it'll
be
similar,
like
I
would
think
that
the
CNF
conformance
is
going
to
be
organic
and
it'll
grow
based
on
the
needs
of
the
community.
So
if
we
look
at
stuff
like
maybe
a
cloud
native
aspect-
is
not
testable
right
now,
because
it's
not
implemented
anywhere,
and
we
may
take
that
into
account
when
you're
doing
testing
but-
or
we
may
say
it's
a
hard
requirement
from
the
the
CNF
conformant
side,
but
later
it's
optional,
it
could
go
either
direction.
I
think
it'll
be
very
similar.
A
A
H
H
It's
a
much
less
complex
project
and
platform,
but
also
one
of
the
things
that
we've
been
doing
is.
We
also
have
been
working
with
groups
like
the
C,
NTT
and
ovp
phase,
2
that,
in
order
to
help
with
with
cloud
native
I
guess
outreach,
it
would
be
the
right
word
and
not,
and
not
only
in
a
sort
of
the
way
that
I've
been
looking
at.
H
The
main
things
that
we've
been
working
towards
is
is
helping
with
that
and
one
of
the
things
that's
helped
with.
It
is
the
CNT
tee
has
very
smartly
put
into
their
system
different
layers,
like
you,
have
a
reference
architecture
versus
a
reference
implementation,
where
the
architecture
could
say
something
like
should
support
multiple
connection,
endpoints
versus
implementation,
which
can
then
make
a
choice
on
one
or
more
different
things
to
check
and
provide
forward
for
that
initial
implementation.
So
that's
getting
that
wording
to
be
more
generic
in
the
architecture
has
has
helped
tremendously
with
with
those
bills.
B
Can
I
add
something
to
it?
Frederick's
was
just
talking
about
it's,
not
just
generic
terminology.
It's
specifically
making
sure
there's
a
clear
delineation
between
requirements.
Ie
I
need
multiple
interfaces
into
a
pod.
I
need
separation
between
control,
plane
and
data,
plane
versus
architecture
and
implementation,
which
are
typically
recommending
a
solution.
B
I
know,
Tom
Clinton
has
done
a
ton
of
great
work
and
helping
clean
a
lot
of
this
up
on
the
sea
MTT
side,
but
as
we're
all
kind
of
collaborating
on
this
I
think
it's
super
super
important
that
we
don't
stifle
future
innovation
by
making
a
solution
of
requirement
versus
describing
what
that
solution
should
be
providing
via
the
requirements.
If
that
makes
sense,.
G
D
Uncertain
and
the
bedrock
at
the
entity
specifications
without
the
different
segmentation
or
reference
architecture.
It
is
evolving
with
time
and
the
plan
is
really
to
keep
the
innovation
coming
and
if
we
see
any
other
technology
that
it
makes
sense
to
take
advantage
of,
we
need
to
make
sure
it
is
reflected
in
the
RA
and
RI.
D
So
what
now
it
says,
even
if
we,
in
the
reference
limitation
specifically
if
we
select
a
leading
technology
to
be
the
pace
of
the
implementation,
C
entity
platform,
that
does
not
mean
that
in
the
future
releases
we
won't
consider
automatic
technology
said.
Certainly
this
is
an
ongoing
process
and
we
keep
evolving
technology.
I
think
what
matters
the
most
was
that
any
solution
available
out
there.
It
is
done
in
a
consistent
way
to
remove
the
fragmentation
of
our
cloud
platforms,
and
this
is
really
the
call
of
the
entity.
D
C
C
Solutions
also
need
to
define
comprar
and
stuff
at
it,
and
this
is
why
we
organized
the
reference
later
should
work
in
two
different
chapters
and
we
are
organizing
the
the
work
in
a
way
that,
in
in
chapter
2,
we
collect
requirements.
Chapter
3,
the
high-level
architecture,
design
in
chapter
4
are
about
the
the
components
but,
as
Robbie
said,
we
are
willing
to
change
these
as
time
progressing
and
a
new
technologies
mature.
B
Yeah
I'm
not
saying
that
there's
anything
wrong
with
being
very
prescriptive
in
the
later
chapters,
where
you're,
specifically
defining
an
architecture
specifically
recommending
an
implementation
it
just
it
needs
to
be
clearly.
You
know
pointed
out
and
the
different
things
like
said:
Tom's
been
cleaning
a
lot
of
it
up.
So
it
looks
a
lot
better
now,
but
the
earlier
chapters
need
to
describe
what
the
requirements
are
to
successfully
deploy.
You
know
cloud
native
networking,
you
know
you
don't
want
to
start
with
the
solution
before
you
define
what
you're
solving
for
yes.