►
From YouTube: IETF106-NMRG-20191121-1000
Description
NMRG meeting session at IETF106
2019/11/21 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
So
we
have
a
very
tight
agenda
today,
so
we
will
start
right
away
and
I
will
ask
the
presenters
to
really
stick
to
the
time
and
if
you
are
willing
to
make
comments,
please
be
to
the
point
and
try
to
be
short,
so
goals
of
the
IGF,
the
IGF
conducts
research.
It
is
not
a
standards,
development
organization.
This
is
a
sort
of
message
reminder
that
we
are
putting
in
research
groups
to
highlight
the
difference
between
rhf
and
IETF.
A
Nevertheless,
IETF
follows
IETF
policies,
and
so
this
is
the
note
well
reminder
on
the
IHF
policies,
in
effect
on
various
topics
such
as
patents
or
code
of
conduct.
So
please
be
aware
of
those
policies
and
comply
to
them,
so
this
we
can
skip.
We
already
have
thanks
to
Dan
for
being
our
meter
call
scribe,
and
gentleman
myself
will
take
after
of
the
minutes,
if
anyone
is
willing
also
to
help
us
with
the
minutes.
We
have
the
heath
apart
here
and
you
can
directly
put
it
on
your
notes,
blue
sheets,
so
please
circulate
the
blue
sheets.
A
A
quick
glance
on
what
will
be
left
this
week,
so
we
already
close
to
the
end
of
the
meeting,
but
today
we
have
our
first
session,
which
will
be
concentrated
on
intern
base.
Networking
and
tomorrow
we
have
also
a
second
session
with
two
main
topic:
discuss
a
bit
of
the
rich
authoring
process
and
a
synthesis
of
the
different
activity
on
network
artificial
intelligence.
As
I
said,
we
have
two
full
agenda,
so
please
stick
to
your
time
and
be
concise
in
your
comments.
A
A
Then
we
have
a
couple
of
technical
presentation
on
the
active
internet
draft
for
the
group
intern
classification
from
all
there
that
will
be
removed
and
Alex,
which
will
make
an
update
on
the
IBM
concept
draft
and
then
the
final
sort
of
today
we
have
a
set
of
technical
presentations.
I
will
not
go
through
that,
but
this
is
covering
a
different
set
of
topics
and
also
new
proposals.
A
Anybody
has
something
to
add
or
change
to
the
agenda
squit
for
you.
So
a
bit
of
overview
of
the
status
of
the
research
group.
There
is
an
ongoing
revision
of
the
Charter.
We
have
sent
email
yesterday
to
the
group
and
also
to
the
IETF
chair.
We
think
we
have
a
stable
version
of
the
revision,
but
it's
welcome.
We
welcome
your
comments
and
we'd
use
on
this
new
charter,
so
you
have
the
link
to
the
Charter
and
on
the
mailing
list.
A
You
have
also
links
to
the
comparison
between
the
document
and
the
first
version
of
the
Charter,
so
the
idea
is
to
have
a
kind
of
umbrella
text
covering
describing
quickly
the
main
research
direction
of
the
group
and
the
relationship,
and
also
to
highlight
a
more
detailed
word
plan
on
the
intern
by
topic,
which
is
the
main
topic,
the
working
group,
the
research
group
is
working
on
so
far.
We
aim
to
approve
the
new
charter
by
the
end
of
this
year
and,
of
course,
your
comments
and
feedback
are
most
welcome.
A
A
Zero
precondition
so
update
your
individual
draft
taking
track
on
the
comments,
discuss
the
issues
on
the
meaning
list,
so
keep
dating
your
document.
This
is
a
good
sign
that
this
document
is
alive,
then,
for
the
adoption
first
check
that
you
validate
a
set
of
criteria,
do
you
have
a
precise
scope
of
the
draft
needs
to
be
clear
and
hopefully
will
not
change
once
the
research
group
document
is
adopted,
we
are
looking
for.
We
are
doing
research.
A
We
are
looking
for
good
scientific
quality
and
we
expect
a
good
impact
also
in
the
community,
so
it
needs
to
be
a
rigorous
scientific
base
and
the
current
contents
must
be
mature
enough.
We
are
not
looking
for
finalized
document,
but
still
we
need
to
have
not
mature
enough
technical
contents
in
the
document.
We
need
to
also
have
indication
how
you
plan
to
continue
the
efforts.
A
The
content
of
the
draft
evolution
of
the
document
must
be
already
player.
If
you
can
have
also
an
indication
of
work
plan
on
milestone,
this
is
even
better
and
to
know
a
bit
more,
we
will
work
on
the
draft,
so
this
is,
we
hope,
commitment
from
the
authors,
but
also
in
the
group,
if
you
have
indication
of
people
willing
to
review
or
if
you
are
willing
to
join
the
effort.
This
is
also
important
indicators
to
know
that
this
is
of
importance
to
the
research
group
and
that
it
will
be
progressed.
A
I
need
to
speed,
okay
and
then
request
for
adoption,
so
you
can
ask
it
on
the
meet
during
the
meeting
on
the
mailing
list
and
also
the
research
group
chair.
We
also
forward
the
the
the
call
for
adoption
on
the
meaning
list
to
let
anyone
a
chance
to
to
comment
an
overview,
a
few
projects
that
we
have
inside
the
research
group
so
idea
and
resource
a
project.
A
This
is
an
idea
to
create
a
place
website
to
get
whatever
the
form
we
have
not
said
yet,
which
will
be
open
to
all
and
to
a
user
for
an
interface
to
collect
external
resources
on
intern
base.
Networking
technologies,
article
standards
documentation
on
product,
whatever
it
could
be
useful
for
the
community
to
have
in
one
place
we're
also
working
on
a
participation
to
Akutan.
A
We
have
a
target
a
bit
in
the
future
July
next
year
in
Madrid,
we
would
like
to
grow
the
idæan
activity
on
practical
aspects,
with
development
of
tools,
demonstration
of
proof
of
concepts.
So
the
idea
is
to
also
work
theoretically
in
the
research
group,
but
also
make
some
implementations
and
we
want
to
leverage
the
European
location
also
to
invite
different
teams,
European
or
white
teams,
but
also
in
EU
funded
projects,
and
so
we
have
made
first
steps
at
this
hackathon
to
connect,
and
you
will
hear
more
in
the
coming
weeks.
A
We
also
need
network
AI
challenge
project,
as
your
home
will
make
synthesis
of
that
tomorrow.
Different
aspects
were
working
on
definition
of
the
use
cases,
identification
of
datasets
oil,
relation
platforms
and
publication
aspect
of
the
challenge
meeting
plans
for
next
year.
So
this
is
tentative.
There
is
a
lot
of
things
that
are
still
open,
but
we
plan
to
meet
in
the
difference
I
HAF
meetings.
We
also
plan
to
have
a
few
internal
meeting
face
to
face
co-located,
for
instance,
with
IM
noms
to
2020
in
budapest,
as
we
used
to
do.
A
We
are
also
looking
to
have
ensuring
either
in
tokyo
with
the
IPOP
conference
or
in
a
brazilian
with
SPRC
conference.
This
is
still
being
discussed
with
the
local
organizations
and
we
have
also
monthly
virtual
meetings.
So
we
will
see
if
we
need
one
in
december,
but
at
least
next
one
will
be
surely
in
mid-january.
A
Was
it
for
the
research
group
status
any
question
on
the
research
group
before
I
move
to
the
report,
if
not
okay,
so
this
is
a
quick
report
on
the
interim
meeting
we
had
in
October
in
Roma
and
co-located
with
the
network
of
future
conference.
The
focus
of
this
interim
meeting
was
practical
aspect
of
intern
business
working.
We
have
invited
for
a
joint
demo
session
with
the
conference
and
we
received
four
papers,
three
demos
and
invited
invited
torch
to
make
demonstration
on
IBM
technologies
and
also
discuss.
We
have
two
days
of
sessions
discuss
a
bit
more.
A
The
practical
aspects
of
intern
base.
Networking
technology.
We
wrote
a
report
of
this
event,
so
this
is
currently
available
on
the
data
tracker.
You
have
the
link
here,
but
this
user
will
also
be
published
as
part
of
the
Proceedings
of
the
conference.
So
you
have,
you
can
find
it
on
an
ultra
poly
Explorer
and
also
the
the
demo
papers
were
part
of
the
conference
and
they
will
be
published
with
the
proceedings.
A
A
We
learn
a
lot
from
the
implementations
they
had
to
make
decisions
on
the
format
of
intent,
the
infrastructure
to
support
it,
the
transformation
of
intensive
it
was
really
useful
to
compare
different
choices
and
also
to
confront
theory
and
practice
because
in
the
group
we
had
several
drafts,
but
this
is
a
theoretical
design
and
then
in
the
implementation,
this
was
not
to
report
on
implementation
choices,
and
it's
also.
It
was
also
helpful
to
generate
further
ideas
for,
for
instance,
the
akhaten
project
and
collaboration
between
different
teams
working
on
those
tools.
A
Again,
the
idea
is
not
to
go
into
a
full
report.
If
you
want
to
read
a
bit
more,
there
is
a
four
six
pages
reports
available.
You
can
also
come
to
us.
It's
very
synthetic,
very
quick
to
read.
You
have
all
the
information
on
the
demos,
the
links
and
all
the
materials
also
available
on
the
the
interim
meeting
page.
A
We
have
also
identified
a
few
further
directions
out
of
this
meeting,
so
to
create
a
code
repository
for
the
tools
and
the
demos
and
with
insert
installation
guides
and
installation
and
user
guides.
This
is
still
in
our
to-do
list.
We
have
also
defined
a
Ibn
tool
data
sheets
to
describe
the
different
experiments,
so
the
participants
of
the
meeting
committed
to
describe
their
tools
using
these
data
sheet.
You
think
it
will
be
useful
also
to
have
these
data
sheets
so
that
people
can
know
a
bit
more.
A
What
are
the
the
tool
is
doing
and
also
provide
a
bit
of
documentation.
We
work
with
we're
also
proposing
to
have
a
kind
of
mapping
table
mapping
table
is
to
make
the
bridge
with
the
draft
on
intend
classification.
So
in
the
demo
they
have
made
choices
of
the
environment,
the
intern
format.
So
the
idea
was
to
use
the
mapping
table
to
see
where
it
fits
in
the
classification
so
maintains,
and
updates
of
your
overall
IBM
told
you.
A
So
this
is
this
kind
of
this
is
the
true
review,
so
we
have
a
draft
intent
lifecycle
and
we
try
to
map
the
component
of
the
different
demos
to
the
different
stages
of
the
lifecycle,
the
different
functions.
So
this
was
a
work
in
progress
during
the
the
meeting
and
we
want
to
keep
updating
this
table
and
use
it
to
understand
if
we
are
missing
something
in
the
life
cycle,
if
some
fortune
ality
are
well
designed
or
we
need
to
split
them,
etc.
A
A
B
Sorry,
like
I,
didn't
have
the
list
of
names.
I
only
had
the
video
because
of
the
format
of
the
screen.
Sorry
for
this
I'm
really
sorry
I
was
not
able
to
join
you
in
Singapore,
so
I'll
try
to
be
quick
because
I
took
a
few
minutes
of
your
time.
So
what
I'll?
What
I'll
present
today
is
the
version
2
of
our
intent,
classification,
draft
and-
and
here
is
the
list
of
contributors
through
version
0,
0,
0,
1,
&,
0
2.
B
So
next
slide
for
those
of
you
who
sorry
the
previous
for
those
of
you
who
were
not
who
are
not
familiar
with
this
draft.
Our
goal
was
to
achieve
agreed
terminology
related
to
intense
and
to
propose
a
classification
approach
for
different
types
of
intends
for
our
group,
but
also
to
guide
other
groups
in
ITF,
ITF
and
even
other
standards.
So
folks
of
this
draft
is
the
user
intense
and
to
define
and
classify
those
intense.
B
The
scope
was,
you
know,
relevant
for
any
system
or
node
that
expects
interaction
with
human
user
in
the
int
and
River
networks,
and
that
human
user,
besides
being
operator,
administrator
and
use
a
customer,
is
also
the
application
developer.
Who
is
building
applications
on
top
of
the
intent
interface
and
intend
driven
approach
is
applicable
to
both
autonomic
networks
and
and
networks.
The
new
future
networks,
it
machine
learning
and
AI,
as
well
as
the
traditional
networks
where
it
can
intent,
could
be
used
on
top
of
the
existing
controllers
and
management
systems,
etc.
B
Our
classification
approach
was
based
on
different
solutions:
users,
their
purpose,
lifecycle,
judgment
requirements,
scope
in
the
network,
scope,
network
function,
scope,
etc,
and
also
abstraction
for
the
interns,
whether
they're
technical
with
technical
feedback
or
not
so,
and
we
have
different
intent.
Examples
next
slide,
please.
So
this
is
the
these
are
the
milestones
for
draft,
as
you
can
see,
version
zero
one,
and
we
are
here
now
in
November,
2000
and
nineteen.
B
We
are
proposing
version
two
to
be
adapted,
and
then
we
are
looking
at
potentially
at
March
2020
for
the
version
three,
which
would
include
all
the
comments
and
outstanding
things.
So
the
the
following
is
the
list
of
comments
received
and-
and
we
addressed
all
of
these
comments,
we
added
some
use
case
references.
B
Some
of
the
comments
would
be
addressed
by
different
draft
that
we
started
for
the
intent
framework,
because
this
draft
is
only
about
intent,
classification,
some
of
the
comments,
one
of
the
comments
that
Diego
had
was
more
related
to
the
framework.
So
therefore
there
is
a
new
draft
intent
framework
being
started
on.
B
There
was
also
a
good
suggestion
from
Lauren
about
the
classification
table
and
as
the
table
he
discussed
when
presenting
the
status
from
the
Rome
meeting,
and
that
is
we
added
that
table
as
Excel,
but
then
also
to
the
draft
so
that
everyone
can
use
it
and
that
box
can
use
it
for
their
classification.
So
we
would
appreciate
any
comments
for
any
of
the
paths,
but
especially
for
classification
table.
There
were
also
comments
from
Ericsson
about
the
they
they
proposed,
not
to
use
the
term
granularity
and
instead
to
use
potentially
abstraction.
B
So
we
also
addressed
this
issue
added
abstraction
section,
but
also
use
the
input
from
China
Telecom,
where
they
were
suggesting
to
talk
about
technical
feedback
or
not.
So
we
we.
We
now
have
a
proposal
to
use
for
clarification,
obstruction,
technical
with
technical
feedback
or
non-technical
without
technical
feedback.
There
are
other
few
comments
that
we
are
going
to
address
or
been
addressing
at
the
moment
next
page.
B
So
so
this
shows
the
table
of
contents
for
version
1
and
what
parts
have
been
changed
mostly
main
updates
in
this
version.
So
you
can
see
that
section
for
those
who
want
to
review
only
the
change
sections
already
review
the
previous
version,
its
section
3.
The
two
intend
solutions
and
intend
users
in
section
4
by
point
2,
which
used
to
be
granularity,
and
now
it's
called
feedback
section
5
has
been
added
and
it
is
a
intent.
B
Classification
table
example
with
table
for
careers
table
for
data
center
solution
and
table
for
enterprise
solutions
and
section
5
has
been
moved
to
6
and
we
added
7
clarifications
in
section
6,
which
has
been
moved
to
section
7
next
slide,
please
so
the
use
cases
and
some
reference
is
valid.
The
example
for
carrier
networks
scenario
use
case
where
the
user
wants
to
watch
high-definition
video
and
the
system
then
has
to
map
their
intent
into
the
technical
requirements
for
the
network
for
data
center
network
scenarios.
B
When
hosting
a
video
conference,
the
remote
access
is
required
and
the
network
operator
has
an
intent
that
for
any
use
of
the
application
that
everything
has
to
be
synchronized
between
50
milliseconds,
the
video
in
order
to
reach
the
destination
viewer
of
each
conversation
session.
So
these
are
the
use
cases
in
China
Telecom
and
help
to
bring
this
use
cases
next
slide.
B
So
the
feedback
section
was
added
and-
and
we
classified
we
created
two
categories
here-
your
ordinary
users,
so
that
would
mean
customers
and
users
or
non-technical
users
or
application
developers.
You
know
some
applications
that
there,
where
they
don't
care
about
how
intent
is
executed
really
did
what
they
interested
in
is
the
feedback
in
terms
of
success
or
failure
of
that
intent.
B
Other
type
of
the
users
is
more
technical
users,
and
for
them
they
that
intent
may
be
more
technical,
but
their
feedback
may
also
be
technical,
because
what
they
are
interested
in
is
they're
also
interested
is
how
intent
is
realized
on
the
network,
so
they
interested
in
network
resources
parts
some
some
resource
information,
so
in
that
case
it
would
be
a
technical
intent
with
technical
feedback
and
next
slide.
Please.
B
So
also
there
was
some
request
to
add
some
more
information
about
how
a
I
a
technology,
what
role
it
can
play
in
the
intent
driven
networks
intend
based
networks.
So
we
added
some
explanation
into
section
6.
The
originally
section
6
was
talking
about
that.
A
IML
driven
system
would
be
driven
by
intent
by
the
goal,
intent
or
policy
intent,
goal
intent
would
present
the
target
state
and
policy
intent
would
present
some
guidelines
in
how
to
realize
and
deliver
that
goal
intent.
B
B
B
So
here
is
the
just
example
of
one
of
the
tables,
and
this
is
really
where
ever
it
would
be
great
for
all
pox
from
our
previous
meetings
to
may
be
position
themselves
and,
of
course,
any
comments
we
consider
this
table.
We
did
take
a
lot
of
comments
and
and
we'd
kind
of
spend
a
lot
of
time
working
on
it.
But
of
course
we
are
hoping
that,
in
version
3
of
this
document,
there
would
be
more
reviewers
and
contributors
which
should
bring
value
to
this
table.
This
is
example
of
different
type
intents.
B
So
please
see
these
tables
and
tell
us
if
you
have
any
comments
on
those
next
slide.
So
so
the
conclusions
here,
our
current
version
addressed
most
of
comments
received
online
and
offline.
There
are
some
comments
that
we
received
also
in
in
the
last
few
days,
and
we
would
be
addressing
them
in
the
future,
but
we
do
believe
that,
because
of
major
updates
and
as
well
of
addition
of
classification
table,
it
would
be
good.
B
We
want
to
ask
for
adoption
of
version
2
as
a
draft
so
that
this
draft
could
be
reviewed
from
now
on
by
the
community.
These
are
some
of
the
next
steps,
like
start
using
collaboration
tool,
and
we
put
it
currently
on
the
Google
Drive
as
the
version,
but
we
we
would
communicate
with
all
contributors
and
maybe
get
their
preferences.
We
won't
alter
the
section
briefly
describing
intent,
work
status,
another
SDOs,
and
we
also
want
to
work
with
community
to
de
river,
unified
intent
definition
that
encompasses
all
intent,
types
for
all
solutions
and
intent
users.
B
So
these
are
some
of
the
next
steps
and
also
to
address
all
additional
comments
and
update
a
document
based
on
the
response
and
feedback
from
the
community.
They
also
have
few
additional
contributors
that
that
show
the
interest
potential
contributors
that
show
the
interest,
so
they
may
add
more
contributors
to
the
list,
so
I
would
like
to
I
would
ask
for
adoption
as
a
draft.
C
C
A
C
The
intent
realization,
and
when
reading
the
text
for
me,
it
seems
that
you,
it's
exclusive
classification,
that
an
intent
will
provide
it
back
to
the
user
or
not
in
the
realization
of
the
intent,
but
I
suppose
that,
for
example,
an
internet
express
by
hand
user
can
actually
does
not
need
to
project
back
to
the
user
itself,
because
it
does
not
need
to
know
the
technical
realization
of
the
intent.
But
at
the
same
time,
yet
misrata
of
the
system
may
want
to
have
the
feedback
to
know
all
the
user
intent
as
mineralised
13z,
basically
gez.
C
B
You
are
right
for
the
for
the
customer
intents
and
application
interns
administrate
and
operator
would
always
be
able
to
see
the
states
of
the
network
and
to
check
the
network,
but
this
is
specifically
mentioned
if
the
administrator
and
operator
is
the
intent
user,
so
in
that
case
their
intent
would
be
more
technical
than
the
intent,
even
if
their
intent
does
the
same
thing
as
the
intent
of
the
customer,
let's
say,
network
service.
So
if
the
customer
requests
the
network
service,
it
may
be,
it
may
be
non-technical.
B
If
the
administrator
requests
it
would,
it
could
be
more
technical,
but
also
the
feedback
it
receives,
for
that
could
include
some
realization
information
and
if
it's
another
user,
non-technical
intent
user,
then
that
feedback
wouldn't
contain
that
information.
So
we
are
talking
about
both
intent.
We
technical
or
non
technical,
but
also
responds
to
that
intent
being
non
technical,
technical,
but
I.
Agree
like
the
administrator
and
operator
would
also
have
his
ability
into
intense
of
all
other
users.
Yeah.
D
So
the
zelich's
come
and
I
also
dress
also
from
a
cursory
read,
but
perfectly
explained
this
year.
So
looking
at
all
the
tables
that
you
were
adding
with
a
classification,
one
thing
that
is
not
quite
clear
to
me
is
how
you
would
actually
use
this.
I
mean
this
is
very
refined.
You
can
be
given
greater
and
hilarity
tag,
basically,
the
the
different
it
tents
that
yeah
they're
not
being
defined,
but
how
would
that
be
expected
to
be
to
be
used?
I
mean
other
different.
D
B
So
we
were
saying
it
would
be
great
if
he
can
classify
those
different
parks
and
demos,
so
the
teach
POC
or
dime
or
any
tool
in
the
industry
can
say
these
are
the
categories
that
we
are
delivering
and
this
is
our
focus
so
primary
primarily,
we
were
looking
at
this
table
as
being
a
tool
that
could
be
used
with
different
pox
and
Deimos.
To
say
this
is
the
intent
that
we
are
demoing,
or
this
is
the
type
of
category
that
he
addressing
I
hope
that
answers
the
question.
Thank
you.
A
C
C
Okay,
yeah
so
between
between
1
and
2,
I
will
say
so,
maybe
oh
yeah,
we
will
anyway,
you
send
a
formal
:.
The
milling
is
to
have
all
the
feedback
from
all
the
participant,
as
we
say
in
the
procedure
and
then
based
on
the
feedback,
we
will
be
able
to
take
a
decision
and
discuss
with
you,
so
you
can
also
review
the
difference
in
back.
You
will
have,
but
thank
you
again.
Olga.
D
D
So,
basically,
since
last
time
the
draft
has
undergone
one
one
revision
cycle,
so
you
know
in
revision,
0,
3
and
basically
the
updates
are
all
pretty
much
every
tutorial
nature.
One
thing:
basically,
there
is
consider
section
con
said
the
intent
life
cycle.
We
did
a
number
of
diagrams
but
relatively
little
text.
So
basically
these
text,
textual
gaps,
have
been
have
been
filled
in
and
the
life
cycle
has
been
described
in
much
greater
detail,
including
the
various
intent
fulfillment
in
and
intent
assurance
functions,
which
are
part
of
it
life
cycles
and
how
they
interact.
D
So
this
is
just
again
the
intent
life
cycle
diagram,
which
is
ok,
I,
think
in
the
interest
of
time.
We
don't
have
to
go
through
this.
This
has
not
really
been
updated.
This
has
not
change,
but
basically,
this
is
about
this
concerns
the
aspect
of
the
document.
It
has
undergone
a
lot
of
texture
of
revision,
and
so
this
here
is
the
document
structure,
so
the
updated
document
structure
and
compared
to
previously,
you
will
see
it's
essentially
the
same
structure
but
the
research
challenges
in
terms
of
open
items
and
accepts
for
this
document.
D
So
there
are
a
few
editorial
updates
that
that
still
need
to
be
made.
One
thing
is
basically,
there
are
currently
two
diagrams
on
the
intent
lifecycle,
which
need
to
be
consolidated.
There's
one
aspect.
Second
aspect
is
because
a
lot
of
the
function
have
been
defined
as
partner
of
the
lifecycle.
There's
some
textural
alignment
that
editorial
and
yes,
that
has
to
occur
between
section
6,
which
talks
about
the
lifecycle
and
section
7
which
talks
about
the
function.
D
D
Okay,
so
in
terms
of
also
next,
if
we
do
believe
actually
that
the
document
well,
this
is
very
weird
fits
with
e
within
the
energy
charter,
so
basically
documenting
the
fundamental
concepts,
background
and
terminology.
This
is
the
main
focus
of
this
document
and
accordingly,
we
wanted
to
actually
also
request,
like
the
previous
speakers
and
requested
option
as
anonymity
work
item,
because
we
believe
it
supports
directly
the
our
Charter
questions.
E
E
What
and
I
think
it
deserves
note
that
it
is
also
more
attention
about
how
is
the
security
of
intent
and
how
you
express
security
requirements
by
intent
basis
and
something
that
deserves
more
attention.
Note
that
so
far
what
I
have
seen
in
the
draft
is
still
in
a
burly
early
stage,
but
this
I
think
it's
a
it's
a
quite
interesting
path
to
follow.
D
Thank
you
yes,
so
we'll
definitely
I
think
the
implication
need
to
be
analyzed
clearly
in.
Regarding
the
classification
and
one
thing,
the
discussion
we
need
to
have
actually,
but
we
had
in
mind
originally
for
this
document,
not
the
the
other
one
was
actually
a
much
coarser
level,
but
just
distinguishing
between
the
high
level
operation,
content,
intent
versus
intent
for
service
instance
versus
the
intent
for
the
force
for
fro
and
just
leave
it
at
that.
But
anyway,
thank
you
for
your
comments.
C
F
Hello,
everyone
so
I
represent
the
Indian
basin
working
approach
that
we
are
following
if
I
Yi
pro
yet.
So.
This
is
a
tool
basically
developed
by
the
people
from
winds,
which
is
opponent
of
the
consortium,
and
I
will
present
basically
on
behalf
of
him,
so
just
for
understanding
what
505
is
basically
to
set
up
facility
for
a
foggy
experimentation
across
Europe.
So
there
are
facilities
in
Spain,
Greece,
Italy
and
France
with
doing
the
currently
datacenters,
and
it
is
to
offer
abstractions
to
the
vertical
vertical
customers
in
order
to
deploy
services
in
that's
all
services.
F
Utility
companies
like
electricity
de
France
or
train
companies
like
Trenitalia,
or
a
give
assistance,
assisted
different
sectors
from
industrial
space.
So
sorry,
briefly,
the
architecture
of
I
give
what
we
have
on
the
bottom
part
of
the
site.
Is
this
multi-site
facilities
with
a
number
of
tools
for
orchestration
and
programmability
of
the
networks
we
have
osm,
we
have
phone
app.
We
have
different
kind
of
Sdn
controllers
there.
F
A
agree
box
and
I
will
explain
basically
what
well
it
consists
now
so
in
10
base.
The
purpose
of
inter-basin,
if
I,
give,
is
to
provide
a
way
for
this
vertical
experimental
set
the
instance.
It
is
an
experiment,
so
they
experiment,
designed
at
the
finish
on
face
and
little
on
the
trigger
for
being
deployed
in
insights
through
this
intent-based.
What
we
basically
do
is
to
translate
the
the
request
of
the
vertical
to
the
political
service
blueprint.
So
basically
we
filled,
we
fill
a
form
for
the
describe
in
the
experiment
and
passing
through
the
orchestration
framework.
F
The
the
final
step
is
the
creation
of
this
experiment
descriptor
in
such
a
way
that
what
these
services
deployed
and
experiment
is
run.
There
are
two
choices
at
the
time
of
the
clay
in
the
service.
One
is
the
usage
of
a
guided
selection
through
a
graphical
user
interface,
a
kind
of
wizard
and
the
other
one
is
the
free
text,
translation
where
basically,
the
requests
of
this
pediment
or
the
vertical
is
interpreted
and
is
translated
for
filling
up.
That
form.
F
Only
tool
will
be
documented
in
deliverable
for
the
one
from
this
project
that
this
is
likely
to
be
released
as
public
in
a
in
the
for
coming
months.
So,
probably
by
the
end
of
the
year,
will
be
already
public
the
galena
to
design.
We
have
a
graphical
user
interface
that
allow
the
dispara
mentors
to
provide
their
intention,
so
they
write
down.
What
is
the
objective
of
the
test
experiment
to
be
performed?
F
Also,
the
tool
is
consists
of
a
database
where
all
these
experiments
are
stored
and
also
these
databases
use
for
check-in
if,
in
in
the
intended
site,
to
really
play
the
service,
there
are
enough
resources
for
further
breeding
the
service
and
also
the
to
check
the
scheduling
of
the
experiment
and,
basically,
a
server
all
this
application
insist-
or
you
have
here
a
link
to
the
tools.
So
probably
this
tool
also
can
be
of
the
tools
that
are
positive,
that
you,
you
were
mention
at
the
beginning,
so
didn't
beat
the
the
two
different
notions
that
we
have.
F
We
have
this
free
text
format,
so
basically
the
experimenters
made,
if
in
my
define
an
intention
by
using
natural
language,
so
they
express
the
experiment
that
they
will
they
want
to
perform.
The
way
of
expressing
the
Perriman
is
basically
the
political
customer
requires
to
use
some
kind
of
key
words
or
some
key
words.
They
say
and
in
some
cases,
on
special
characters,
characters
for
identifying
the
specific
field,
for
instance
the
specific
format
for
the
time
of
the
day,
so
my
specific
format
for
the
date
to
be
run.
F
This
spellemann'
also
for
signal
in
the
number
of
instances,
and
so
in
case
that
there
are
NT
files
that
the
office
that
cannot
be
completely
filled
after
the
intention
of
the
other
political
customer.
The
system
is
able
to
interrogate
the
vertical
again
for
completing
the
information
which
is
machine,
yeah
and
in
case
the
the
vertical
experimenter
put
some
data
that
is
not
run
at
all.
That
is
wrong,
or
this
is
not
good
at
all
the
system
disabled
as
well
to
innervate
the
vertical
in
order
to
fix
what
is
what
can
be
be
seen
for?
F
You
cannot
see
from
there,
but
the
the
here
some
examples
of
how
this
is
happening
and
in
any
case
this
will
be
documented
in
a
in
the
variable
that
I
mentioned
before
the
second
way
of
requesting
the
service.
With
this
guided
selection,
which
is
basically
a
kind
of
Whizzer
well,
the
vertical
customer
can
go
through
different
menus,
let's
say
and
start
filling
the
data
for
this
Perriman.
F
So
that
was
what
we
are
doing.
In
fact,
if
the
next
steps
that
we
are
considering
is
to
generalize
this
concept
to
the
processing
of
the
SMA
of
the
EPP
as
ice
templates,
so
in
both
GSMA
and
3vp,
both
are
working
in
this
and
apple
slice
template.
So
the
idea
would
be
to
take
this
ideas
that
we
have
developed
if
I
give
porting
them
to
the
request
of
services.
That
would
be
expected
from
coming
from
fy'y
from
front
VPP.
Let's
say
for
for
the
fiv
services
for
the
new
college
license.
F
Another
intention
is
to
document
this
in
in
address
target
in
annex
ITF
for
reporting
well
having
some
some
grapple
of
how
this
has
work
in
reality
in
the
de
ferran
experiments,
and
also
we're
exploring
this
way
of
holding
this
ideas
to
3d
PPS
stuff.
And
that's
all
from
my
side.
Do
you
have
questions.
A
So
you
mentioned
that
I
see
clearly
a
connection
with
the
activity
want
to
do
on
the
experimentation.
This
could
be
a
good
addition
to
the
to
the
pool
of
demos.
You
mentioned
that
you
would
like
to
work
on
a
draft.
Yes,
have
you
already
identified
if
it
will
be
more
towards
the
IETF
or
IO
GF
or
and
what
will
be
the
it
would
be
a
kind
of
use
case,
experimental
type
of
draft
or
more
and.
F
They
be
able,
with
those
properties,
I
mean
to
take
this
idea,
that
we
have
a
sporting
fate,
but
port
into
the
generic
case.
Nice
template
and
then
I
want
a
slice
template
from
VPP
so
because
they
did
what
we
have
if
I
give
these
vertical
service
blueprints
are
not
does
not
much
higher,
actually
the
area
slice
templates
and
whenever
I
see
a
plate,
so
they
do
would
be
to
take
this
from
experiments
that
we
have
done
in
five,
but
moving
to
work
with
what
could
be
a
true
as
I
Stan,
a
slice
request
from
VPP.
G
G
G
G
So
a
fully
automated
refinement
process
in
nefi
I'm,
an
assistant
editor
an
open
issue.
This
contest
we
take,
we
tackle
this
problem
and
we
propose
a
dns
planner
that
is
coronated
policy
finally,
procedure
for
an
FEV,
my
assistants
and
basically,
it
combines
the
rich
description.
Logic
is
expressivity
with
the
efficiency
of
automated
plan
assistance
base
it
on
your
desk
iroquois
task
networks,
so
it
you
basically
use
our
well-funded
etienne
planner
to
perform
the
gory
netted
policy
refinement
procedures
and
it
proposes
the
use
of
one
ethology
in
addabbo
l
to
call
it
on
top
laner.
G
So
this
figure
showed
the
architecture
of
NS
planner
and
we
skip
some
parts
and
focus
on
the
three
main
functionalities
and
we
will
start
talking
about
the
the
functionality
that
is
performed
by
this
model.
They
go
oriented
polish
management
model
and
this
model
enable
one
to
describe,
store
and
maintain
go
policies,
and
for
this
we
propose
it.
G
These
discs
agreement,
there's
this
language
agreement
and
basically
summarizing
one
goal,
applies
for
one
or
more
visual
nature
functions
of
I,
specifically
network
service,
and
of
course,
we
can
define
one
or
more
service
attributes
for
this
goal
and
the
response.
It
is
also
possible
to
define
the
degree
of
importance
of
this
go
as
high
medium
or
low.
G
This
second
functionary
that
I
want
to
discuss
with
you
is
the
policy
refinement
procedure
II
and
there
is
perform
at
by
the
planet
generation
model
and
once
I
go
require
a
gory
find
many
requires
arrives
to
the
system.
This
modeling
work
as
follows:
the
first
step
it
study
its
instant
heat,
our
copy
of
on
top
laner
in
a
memory,
and
it
distracts
the
curity
state
of
the
domain
and
they
requested
to
go
information.
All
this
information
are
stored
in
the
on
top
laner
and
then,
after
that
it
builds
a
planning
problem.
G
Dot
met
in
Lisp
code,
I
will
talk,
I
will
talk
about
more
later
and
it
used
this
plenty
problem.
Domain
model
and
a
preview
lose
definite
planning
domain,
as
he
put
for
an
eighteen
planner
in
order
to
perform
the
planning
process.
That
is
basically
policy,
the
policy
refinement
and
once
the
the
planning
process-
and
it
created
a
first
of
all
policies
using
it
outputs
and
it
stored
these
enforceable
policies
into
the
on
top
lane
a
copy.
Finally,
it
performs
dl
reason
to
provide
constants
verification.
G
This
in
consists,
this
dis
check
is
performed
in
order
to
detect
if
the
states
constraints
I'll
cross
it
okay,
and
if
the
there
are
no
in
constants,
the
enforceable
policies
are
extracted
from
the
on
tone,
plane
a
copy
and
return
it
to
the
usage
API
move
on.
This
figure
illustrates
how
the
enable
the
creation
of
policies
they
are.
Basically,
if
it
condition
action
rules,
okay,
again,
I
I
want
gatekeeper.
G
I
would
get
deeper
in
this
context,
because
we
have
a
short
time
and
continuing
the
last
functionary
I
want
to
discuss
with
you
is
the
detection
of
volleys
conflicts?
Name,
it
policy
analysis,
and
it's
worth
mention
that
policy
analysis
requirement
for
policy
refinement
systems
and
to
achieve
its
functionality.
We
created
two
as
double
air
rules,
one
for
to
detect,
go
conflicts
and
another
to
detect
the
echo
rule.
The
enforceable
policy
conflicts.
G
So
if
there
are
constants
the
reason
we
identify
the
the
arrows
and
provide
the
possible
explanations,
so
we
develop
an
NS
planet
prototype
in
Java
and
basically
it
use
the
spring
boots,
implement
the
rest
for
api's
and
the
auto
WL
API.
In
order
to
enable
the
auto
planning
management
and
the
conflict
that
they
conflict
detection
mode,
we
use
the
Amity
reason
a
fully
compliant
Sado,
wl2
reasoner
and
the
plenty
management
model
use
the
top
well
found
an
ATM
planner.
G
That
is
pertinent
by
university
of
maryland
and,
of
course,
in
order
to
validate
the
NS
play.
We
implemented
a
use
case.
That
is
basically
a
plain
domain
model
for
the
resilience
attribute,
and
this
figure
here
sure
show
parts
of
the
test:
the
composition
of
their
resilience
goal
and
I'd
like
to
highlight
two
sub
goals
that
are,
the
failure
prevented
and
a
failure
controlling
the
the
foreman
focus
in
setting.
G
G
To
indicate
the
DNS
planet
as
an
appropriate
is
appropriated
to
be
use
it
in
our
production
environment
as
an
auxiliary
tool
for
an
FF
e
mono
frameworks,
and
we
believe
that
this
work
leverage
two
contributions
to
an
emoji,
the
first
one
in
s,
planet
enable
oriented
policy
refinement,
and
this
contest
an
Esplanade
focus
on
entity.
Specifically
aspects
since
go
policies
described
is
already
states
in
our
environment
are
a
sequence
of
actions.
G
E
G
Basically,
the
solution
at
this
presentation
just
a
short
view
of
the
entire
solution,
so
we
have
another
mechanisms
to
perform
this
replay.
Nning
was
this
dissolution
detects
that
some
policies
are
not
working
properly
and
besides,
these
disciplinary
process
generates
some
enforceable
alarms
that
can
detect
any
problem
in
during
the
the
infrastructure
and,
of
course
it
applies,
the
the
correct,
the
corrective
actions,
but
the
repair
process
is
performing,
but
it's
another
part
of
the
work.
G
G
E
Definitely
and
yes,
just
a
question
because
you
I
see
so
three
three
inputs
I
mean
you
mentioned
the
operator
and
twice
the
orchestrator
to
two
different
modules.
Let
me
see
little
bit,
that's
where
no,
no
here
so
you
have.
The
operator
provides
some
pretzels.
The
nav
Orchestrator
provides
any
goals
to
this
goal
happy
and
at
the
end,
to
the
plan
area
yeah
in.
G
G
E
E
G
As
I
mentioned,
I
defined
these
rules,
where
I
can
find
conflicts
between
all
those
that
are
storied
that
are
registered
in
the
Delta
planner
and
basically
were
at
water
check
here.
If
let
me
see
her,
that's
better,
if
there
are
at
least
two
goes,
that
applies
to
the
same
network
servers
and
intersects
with,
but.
G
A
A
G
I,
choose
it
to
I
decided
we
decided
to
work
with
an
eighteen
planner.
Is
this
automated
planning
system
well
in
which
we
can
define
up
planing
domain
model
in
a
plane,
any
problem,
and
it
these
two
models
are
using
as
input
for
this
planar
and
but
based
on
what
you
define
there.
Do
you
it
it
to?
You
generate
a
plane,
a
sequence
of
reactions
that
you
have
to
perform.
Okay,.
G
G
It's
more
CLE
clear
about
how
human
feels
so
basically,
and
we
need
we
need
something
that
from
this,
this
kind
of
test
the
composition,
because
we
don't
want
to
define
just
a
sequence
of
actions
and
generate
a
planning
based
on
their
preconditions
and
effects.
We
want
something
that
we
can
start
for
from
high
level
tasks
and
then
generate
just
the
actions
that
okay
I.
A
G
G
A
I
A
You
can
also
come
a
come
to
us
to
know
who
to
contact.
My
question
is
also
from
the
more
on
the
theoretical
base,
because
you
are
proposing
some
techniques
to
address
the
the
golda
composition,
the
the
planning
phase
and
I
can
see
relationship
with
the
lifecycle,
so
the
different
steps
that
we
have
for
the
intent.
We
have
also
decomposition.
A
I
A
J
J
J
Oh
so
can
he
is
it
better,
then,
a
description
of
the
framework
we
proposed
the
first
conclusion
and
the
challenges,
so
the
the
the
initial
use
case
was
this
demo
that
involved
several
burlaps
facility,
and
this
was
about
deploying
slices
for
IOT
and
EMB
B
of
over
a
cloud
run.
So,
as
you
can
see,
you
have
already
several
types
of
clouds
so,
and
so
the
problem
was
that
to
have
it
up
and
running
each
time
it
was
in
requiring
like
one
and
a
half
to
two
hours
of
expert
engineer
and
researcher
configuration
operation.
J
So
when
we
looked
at
existing
research
in
intent
on
intent
based
networking
for
those
type
of
use
cases,
we
found
out
that
as
it
is
written
in
several
drafts.
Currently
the
current
work
at
that
time
was
focusing
on
policy.
The
service
was
connectivity
and
there
was
already
there
was
that
lack
of
languages
to
translate
instruction
from
one
system
to
another
one.
J
So
what
we
proposed
is
to
extend
the
intent
based
networking
from
connectivity
to
applications
from
network
operation
to
over
the
top
application,
provisioning
and
from
fixed
network
to
more
heterogeneous
networks
such
as
cellular
width,
and
the
current
focus
on
this
work
is
to
look
at
the
intent
request.
Feasibility
check
we're
not
working.
This
work
is
not
about
translating
and
natural
language
processing
and
stuff
like
that,
and
also
the
the
other
focus
is
on
intent.
J
Network
application,
slice
automation,
so
this
is
the
framework,
so
I
tried
bit
between
the
two
versions:
I
uploaded
I
try
to
play
with
some
colors
to
map
it
with
the
work
that
draft
on
intent
based
concepts.
So
this
sorry
so
the
so
the
functions.
This
is
the
architecture
framework
for
the
intent
based
the
in
OTT
intent.
Sorry-
and
this
was
already
here-
the
only
thing
I
did
was
adding
the
outlines.
So
we
have
already
this
space
here.
J
So
in
the
draft
you
have
the
this
is
why
I
took
my
paper,
the
user
space
here,
and
this
the
functionality
of
the
use
of
space,
as
indicated
they
interact
with
the
user.
So
this
one
takes
in
the
application
slice
request.
This
one
provides
system
feedback,
and
this
is
a
key
function
to
in
our
vision,
because
this
makes
the
difference
between
a
Gillian
and
then
stuff
it.
It
is
this
system
feedback
that
the
user
gets.
This
is
the
history.
J
J
This
is
what
is
called
the
this
is
the
core
IBM
framework
functions,
so
these
function
Maps
the
intent
requests
to
a
first,
a
first
level
of
what
is
called
service
graph.
It's
a
graph
of
the
the
main
function
that
needs
to
be
that
needs
to
run
to
perform
the
service.
So
this
is
not
yet
talking
about
how
many
replicas
and
stuff
like
that.
This
is
like
a
blueprints.
J
So
so
you
have
this
initial
graph
and
upon
this
initial
graph
before
ever
going
continuing.
The
first
thing
is
that,
given
once
you
know
what
function
you
need
to
run
your
service,
you
should
be
able-
and
once
you
know,
of
course,
what
application
you
want
to
run
once
you
also
know
the
population
of
your
application,
which
means
how
many
endpoints,
for
example,
you
should
be
able
to
provide
a
first
level
of
dimensioning.
So
this
is
not
there's
nothing
new
there.
J
So
before
ever
continuing
used,
you
have
to
check
the
resources
available
whether
your
infrastructure
is
able
to
deploy
the
necessary
functions.
So
to
do
so
you
so
you
go
through
this
function,
and
this
function
is
fed
by
other
functionalities
that
compute
the
dimensioning
and
that
computed
based
on
patterns
and
where
these
patterns
are
based
on
system
measurements.
J
So
this
is
like
some
classical
loop,
but
we
feel
that
it
is
very
important
for
a
reliable
intent-based
system
to
have
already
at
this
stage
this
check,
because
if
this
does
not
work,
your
intent
will
never
be
fulfilled
and
you
will.
The
risk
is
to
run
steps
here.
Unnecessarily,
to
lose
time,
whereas
if
you
check
this
immediately,
you
just
have
a
system
feedback
and
say,
for
example,
no,
not
enough
resources
or
other
reasons.
I
am.
This
does
not
cover
the
no
go
on
ok
from
the
system
due
to
access
right,
our
policy
user
policy.
J
Okay.
So
once
you
have
once
your
you
have
the
ok
regarding
the
resources,
the
systems,
the
system
computes
the
deployment
plan.
So
you
know,
theoretically,
that
you
have
several
classes
of
servers
on
which
you
can
deploy
your
functions
and
this
functionality
computes
the
deployment
plan.
So
this
I
will
not
detail
this.
What
this
will
be
presented
in
December
in
Dropcam,
and
then
once
this
is
finished,
so
the
system
generates
the
ibis
control
commands
where
Ibis
stands
for
intent-based
application
slicing,
so
the
system
genera
it's
the
commands.
J
It
can
also
progressively
have
several
sets
of
commands
that
map
to
given
sets
of
instruction
and
then
once
it
is
ready.
These
commands
are
sent
to
this
functionality,
which
is
the
iPass
control.
This
work
function
and
the
other
blue
function
belong
to
the
network
operation
space
and
in
this
framework,
I
also
have
outlined
here,
are
the
the
blocks
in
different
colors,
and
this
corresponds
to
intent,
fulfillment
so
intent.
Fulfillment
is
the
block
for
intent.
Fulfillment
are
surrounded
by
grey
with
grey
and
the
function.
J
The
function
blocks
for
intent
assurance
are
surrounded
with
blue,
so
once
the
instructions
already
they
are
sent
to
the
iPass
control
and
this
entity
is
able
to
talk
to
all
the
management
functions.
So
the
the
intent
framework
here,
hence
over
the
action
and
the
commands
to
control
functions.
That's
where
the
intent
scope
stops
in,
in
all
other
proposed
view.
J
For
ott
intents
and
here
you
can
see
that
you
have
something
that
is
named,
live
intent,
because
the
one
main
implementation
for
Sdn
controller
is
on
us,
and
you
have
this
famous
ad
on
us
intensive,
which
are
encapsulate
s--,
quite
complex
computation
for
connectivity,
but
in
our
sense
here
for
ott
it
can
be
considered
as
too
technical,
because
somebody
who
requests
a
costumer
who
requests
to
deploy
a
slice
for
I,
don't
know.
Agriculture
has
no
clue
of
a
hostname
and
port
number
and
stuff
like
that.
J
But
the
system
here
at
this
layer
at
this
level,
this
function
is
able
to
talk
to
other
controllers,
and
this
one.
This
one
function
does
have
the
skills
to
express
an
intent
which
is
much
more
technical,
and
these
technical
intent
can
also
seem
very
abstract
to
the
southbound
of
a
controller.
So
just
the
the
first
conclusion
of
this
framework
is
that
already
we
already
have
the
complexity,
although
this
is
considered
as
a
basic
example,
because
you
just
have
one
request
that
is
expressed
on
the
northbound.
J
Ok,
so
I
will
rush,
so
this
is
the
proposed
framework
and
how
it
fits
to
with
the
concepts
and
what
we
think
we
should
be
added.
So
basically,
control
function
that
warranty
that
you
have
their
availability
resources
and
also,
at
this
level,
verification
and
validation
and,
for
example,
so
I'll
skip
this.
This
is
how
the
the
intent
is
expressed
using
just
parameters
a
parametric
model.
So
typically
regarding
the
assurance,
the
validation
is
done
here
by
just
verifying
the
traffic.
A
J
J
J
I
J
Okay,
so,
okay,
so
this
is
another
another
way
of
valid
a
buddy
dating
the
system.
There
I
think
there
is
a
need
for
specifying
validation
functions
at
several
level,
even
looking
at
the
how
long
you
take
so
by
the
way,
the
set
up
time
was
like
a
couple
of
minutes,
even
if
this
is
very
system
specific.
Of
course,
this
can
be
used
again
to
verify
that
the
the
slice
has
been
correctly
deployed.
So
matching
this
again
against
expected
results,
and
this
is
something
that
is
very
that
was
discussed
in
Montreal
as
well.
J
This
is
something
that
is
very
useful.
I
think
in
this
intent
framework
and
in
the
work
that
is
being
defined
here,
is
define
some
targets
and
look
at
what
happens
and
compare,
maybe
adjusting
the
target,
but
now
and
then
decide
should
I
adjust.
My
system
should
I
adjust
my
target,
so
the
challenge
is
here
is
that
okay?
J
This
was
a
very
basic
example,
although
very
complex,
because
involving
several
clouds
or
classes
of
clouds
and
several
functions,
but
this
is
basic
and
we
we
believe
that
in
real
life,
the
the
system,
the
deployments,
are
much
more
complex.
You
in
real
life,
you
have
several,
you
have
a
constellation.
You
may
have
a
constellation
of
such
deployments
and
the
the
big
I
mean
there
is
a
lot
of
work
still
to
be
done
on
what
I
just
presented.
J
But
the
big
concern
is:
what
happens
if
I
have
a
several
such
system
interacting
with
themselves?
What
happens
if,
for
example,
I
talked
to
several
controllers
to
five
different
implementation
of
controllers,
so
there's
a
lot
of
work
that
is
needed
to
be
able
to
to
send
correctly
my
instruction
to
these
controls.
How
do
I
know
that
the
controlling
function
I
talked
to
has
understood
my
my
request
and
how
do
I
expose
how?
E
J
J
E
E
C
E
J
The
slice
is
the
set
of
cloud
and
network
resources
that
is
allocated
to
run
this.
This
application
I
mean
in
this
it
was
very
basic
and
typically,
the
slice
was
specified
by
the
chain
of
functions
and
replicas
that
we
use
to
run
this
application
and,
together
with
the
budget
of
infrastructure
resources,
okay,.
E
A
I
I
J
I
J
Completely
agree
and
I
see
your
point.
This
presentation
completely
skips
the
aspect
of
whether
I
would
call
the
definition
set
of
the
application
that
definition
set
of
the
intent.
That's
yet
another
issue
to
to
tackle,
but
so
in
this
presentation.
Yes,
indeed,
we
only
consider
we
well.
This
is
a
very
basic
example
and
we
on
purpose.
J
We
started
like
a
zero
point,
with
no
complexity
regarding
where
do
I
deploy
this
and
we
and
the
as
I
said
the
the
definition
set,
the
topology
up
abstraction
and
what
you
can
already
request
and
have
as
constraint
regarding
the
topology,
where
you
I
mean
the
infrastructure
when
you
want
to
deploy
your
service.
That's
yet
another
problem.
Ok,.
K
Thank
you
all
right.
The
pink
cross
be
difficult,
not
to
move
but
okay.
So
what
I
want
to
present
here?
This
is
service
assurance
for
intent-based
networking.
So
words
come
from
at
the
last
Montreal
meeting.
We
spend
like
a
day
of
any
margin,
intent
and
I
say
to
explain
a
couple
of
concept
there
in
the
end,
I
wrote
the
slide
about
it.
The
way
we
have
to
understand
this
is
okay.
K
K
So
the
issue
that
that
we
have
is
that
okay,
we
configure
a
service
as
an
operator
great,
it's
configure,
it
doesn't
mean
it
works
correctly.
Then
we're
telling
we
could
be
sending
all
the
telemetry.
You
know,
data
like
he
do,
machine
learning,
etc,
and
we've
got
the
issue
of
the
needle
in
the
haystack.
K
What
are
we
trying
to
do?
Operators
they
want.
You
know
one
or
service
degrades.
Where
is
the
fault,
and
it
could
be
an
easy
one
like
the
faces
down?
This
is
the
root
Coast,
but
most
of
the
time
we
need
to
have
the
centum
of
what's
happening
and
we
to
do
some
more
analysis.
The
second
thing
I'd
like
to
do
is
when
a
network
component
fails,
which
service
are
impacted,
typical
data
center
issue
of
a
D&C
CMP
issue,
and
we've
got
no
clue
what
the
services
are,
which
one
are
impacted.
K
So
we
know
the
end
goal
would
be
like
self-driving
self-healing
networks.
With
the
closed
loop
automation,
we
could
take
a
top-down
approach,
the
creative
way
it's
a
nice
concept,
but
that
works
mainly
for
a
Greenfield
deployment
and
in
my
world
of
operators.
Well,
it's
not
that
easy.
So,
let's
try
to
service
differently
by
trying
to
decompose
the
the
issue
of
assertions
into
smaller
components,
trying
to
assure
those
smaller
components
one
by
one.
Now,
if
we
combine
his
approach
with
the
end-to-end
cinetic
traffic
test,
then
we
have
a
complete
view
of
the
disservice.
K
K
What
is
more
interesting
is
maybe
not
more
interesting,
but
the
most
applicable
is
informational
dependencies
who
are
in
this
example,
I
just
put
ecmp
right.
So
I've
got
the
multiple
paths
in
my
EMP
group,
and
then
one
of
them
is
buddy
behaving.
Is
my
service
impacted?
What
it
depends
is
the
answer.
K
That's
why
we
have
this
as
informational
dependencies,
so
what
we
knew
so
far,
if
we
know
the
Ashwin's
graph
and
if
we
know
the
house
of
the
different
components
in
there,
we
know
were
default
s,
or
at
least
to
start
with
were
its
not
because
everything
is
Halcyon,
green,
except
a
couple
of
points
we
could
start
by
investigating
those
components.
We
know
also
the
symptom
for
the
root
cause
now,
because
I've
got
the
three
in
one
direction.
I've
got
it
also
in
the
reverse
direction,
which
is
something
interesting.
K
I
see
this
component,
my
network
is
failing
or
degrading
and
I
know
the
impact
on
all
the
services
that
are
configured
now.
This
is
the
architecture.
Let
me
quickly
go
over
it.
We've
got
like
a
service
configuration
Orchestrator
I
made
difference
between
this
one
configuration
and
the
one
for
assurance,
which
is
the
sin
of
castrator,
so
we
extract
the
service,
and
this
is
for
us
a
starting
point
for
the
intent.
So
we
don't
go
from
declarative
right.
We
try
to
extract
it
from
the
from
the
service
now
from
there.
K
So
if
we
don't
do
it
by
component-
and
we
say:
okay,
the
service
is
filling.
What
do
we
do?
Do
we
reconfigure
it?
Well,
not
quite
right,
there
are
a
situation
between,
but
this
is
the
point
now.
This
is
a
flexible
architecture.
Were
both
orchestrators?
The
one
fresh
trans
configuration
could
obviously
be
the
same
box
and
same
thing
for
the
the
agent
which
could
be
in
the
Box
in
the
router
or
not.
K
Now
it's
also,
it
must
be
an
open
architecture
right
if
we
solve
this
one
for
a
single
vendor
great,
but
not
many
networks,
every
single
vendor,
and
how
do
we
do
this
with
a
yang
module?
Obviously,
for
me
a
yang
mode
using
API,
and
we
can
recommend
this
yang
module
for
multiple
service
types
and
for
vendors,
cific
information.
K
What
we're
not
doing
here
is
trying
to
get
the
kind
of
standard,
ARS,
Orchestrator
or
open
source
Orchestrator,
and
also
the
expression
that
are
used
to
say
this
is
how
we
we
get
the
house
of
you
know.
Data
plane
is
is
not
in
there,
but
this
actual
architecture
should
be
open.
So
this
is
the
full
yang
module.
I,
don't
want
you
to
look
at
it
this
way,
but
I
want
you
to
just
read
it
through
Omni.
What
is
in
blue
there?
K
K
You
want
to
understand
from
the
yang
module
that
you
can
create
your
own
sub
services
with
your
own
parameters,
obviously
a
parameters.
What
is
this,
if
I'm
doing
the
house
of
this
device,
this
device
ID
if
I'm
doing
the
health
of
an
interface?
This
is
that
interface
on
that
device
ID,
so
the
parameters
will
be
different.
And,
finally,
you
want
to
understand
that
we
could
open
this
even
with
some
vendor
specific
sub
services,
which
in
the
end
will
happen
anyway,
even
within
a
single
vendor.
K
We
have
different
platforms,
for
example,
coming
back
this
an
example
of
the
device,
health
and
I
think
I've
been
fast
enough,
as
you
want
it
to
provide
discussion,
which
is
more
interesting.
So
this
is
the
time
to
to
discuss
this
and
get
your
feedback.
I
received
quite
some
feedback
already
from
from
operators
in
the
ops,
aw
gee.
So
up
to
you
now
for
more
feedback.
If
you
want
I.
A
Will
see
that
the
Asturian
graph
can
be
used,
I
mean
you
can
map
it
into
our
internet
life
cycle
in
the
phase
of
your
service,
where
you
want
to.
You
have
already
decomposed
your
intent
and
you
want
to
be
able
to
monitor
what
corresponds
to
an
intern
so
to
make
the
way
up.
So
I
think
this
could
be
a.
We
could
use
that
as
an
example
of
a
technique
that
can
be
used
to
fulfill
a
step
of
the
life
cycle.
I
think
it's
a
valid
contribution.
In
that
sense,
a
question
I
would
have.
A
K
To
redo
this
version
of
your
draft
that
for
me,
okay,
my
personal
view
and
then
the
answer
to
your
question:
I,
never
liked
the
term
intent
because
it's
fuzzy
to
me
at
least
when
I
speak
to
you
to
operators.
Now,
however,
I
I
take
the
beginning
of
an
intent
starting
from
the
service
definition
which
I
get
from
the
orchestrator
configuring
the
service
and
most
of
the
time,
those
services
are
at
a
specific
type.
I
want
to
do
an
l2
VPN,
an
ultra
P
and
I,
want
to
do
that
vnf
and
for
a
specific
service
type.
K
L
Judgments,
your
abstract
there's
a
layer,
that's
missed,
it
cannot
be
an
intent
or
and
l3
VPN
l3
VPN
is
an
implementation
of
intent.
So
again
there
should
be
to
your
question
layers
that
could
consume
internists
coming
from
the
user
and
tell
the
the
way
data
model
is
built.
Look
I
need
you
to
implement
particular
intent
as
LCVP
and
our
evpn
or
sometimes
so.
I
would
agree
with
that.
K
L
D
Alex
trim,
yeah,
I,
think
actually
the
dependency
graph
and
those
sort
of
things
I,
don't
think
it's
specific
it
and
clearly,
but
I
think
it's
more
widely
applicable,
but
one
question
that
I
would
have
I
think
it
raises
the
other
day
as
well
as.
Actually
how
do
you
maintain
this
dependency
graph?
I
think
this
seems
to
be
one
of
the
key
things
that
you
basically
yeah
that
you
capture.
Do
you
basically
establish
them
as
part
of
the
provisioning?
Basically,
you
have
basically
additional
operations
there,
or
do
you
discover
them
or
how
do
you?
D
K
It's
both
part
of
the
configuration
and
both
discovered.
You
know
if
I
take,
for
example,
if
I
rely
on
ecmp
for
service,
we're
not
going
to
configure
a
CMP
part
of
a
service
right
if
we,
if
we're
depending
on
ice,
is
or
SPF
we're
not
going
to
configure
si
as
part
of
a
service.
Definition
is
done
by
a
different
group
right.
So
it's
part
partly
what
you
get
from
the
search
definition
and
what
you
get
from
a
network.
And,
yes,
you
have
to
maintain
it
and.
A
K
M
33.3%
less
time
approximately
great
okay,
so
I'm
dropping
down
a
little
bit
from
decorative
slash
intent
looking
at
imperative
policy.
Now
this
was
a
piece
of
work
that
was
presented
in
net
mod
earlier
this
week.
So
apologies.
If
you
attended
that
session,
there's
going
to
be
some
slight
repetition
here,
but
just
wait
for
the
final
slide
and
hopefully
I'll
try
to
put
the
discussions
the
context
of
the
nm
RG.
So
we
don't
really
need
to
spend
any
time.
M
I
think
talking
about
ECA
you're,
all
sort
of
highly
aware
of
flick
ability
of
ECA
for
applying
policy
to
technology
selection,
service
deployment
may
be
resource
usage.
Just
a
reminder
actually
that
for
some
of
you,
you
may
be
have
been
aware
of
a
previous
working
group.
Super
simplified
use
policy,
abstraction
which
look
to
sort
of
harmonize
some
of
the
imperative
policy
usage
across
various
technologies
in
the
ITF.
M
Unfortunately,
we
never
actually
managed
to
publish
a
data
model.
We
just
couldn't
constrain
the
problem
space
enough
even
for
ECA
and
apply
it,
but
we
did
actually
have
some
success
with
publishing
a
framework.
So
there
is
an
RFC
that
was
published
by
the
ISE.
So
as
you're
kind
of
discussing
or
continue
to
discuss,
intense
and
the
you
know,
I've
looked
at
a
couple
of
the
documents
that
the
NMR
do
is
working
on
now.
You
may
also
want
to
look
at
that
super
documents,
although
it
is,
does
talk
about
sort
of
two
information
models.
M
One
is
a
general-purpose
information
model.
The
other
is
an
ECA
BAE
information
model,
so
going
back
to
net
mod.
Essentially,
what
we
wanted
to
do
with
this
document
was
treat
it
as
a
gravity
world
and
pull
some
of
the
philosophical
Fissel
of
some
of
the
general
discussion
of
eca
out
of
the
data
model
solution
work.
So
in
terms
of
what
are
the
use
cases,
how
do
you
define
the
process?
How
do
you
manage
a
condition
and
event
and
an
action?
Where
do
you
store
the
state?
M
What
type
of
language
might
you
apply
or
how
you
would
not
all
the
tree
to
actually
implement
the
logic,
how
you
handle
notification,
things
like
policy
management,
rule
management
and
policy
resolution,
especially
in
the
case
of
conflict
or
competing
rules?
You
know
all
of
these
are
actually
quite
important
aspects
and
not
necessarily
discussion
that
you
want
to
have
in
the
solution
documents
themselves.
So
that's
why
we
kind
of
put
together
this
framework
document
and
you
don't
necessarily
implement
the
framework
you
just
use
it.
M
You
know
for
your
your
own,
maybe
sort
of
vendor
or
operator
specific
implementation,
so
it
doesn't
necessarily
give
you
an
exact
guide
of
how
to
implement
ECA,
obviously
into
your
network.
The
document
also
talks
about
some
implementation
considerations.
Around
operations
and
security
and
I
noticed
that
earlier
today,
security
was
kind
of
mentioned,
I
think
in
Alex's
documents
as
an
open
issue,
but
it
was
also
it
seems
to
be
an
open
issue
as
well
in
terms
of
discussion
in
the
intent
classification
document.
So
there
may
be
some
text
that
we
could
actually
build
on.
M
That's
actually
used
in
this
document
now,
because
we're
kind
of
constrained
on
time
for
for
this
presentation,
I'm
not
going
to
go
to
all
of
these
slides.
What
you
could
do
offline
is
if
you're
interested
in
the
framework
document
is
kind
of
take
a
look
at
some
of
the
questions
that
we're
asking
at
the
moment.
So
you
know
things
like
the
preparation
of
ECA
rules
are
scheduling
delegation
cataloging.
M
How
you
manage
state
is
essentialized
as
a
distributed
is
a
combination
of
both
yes,
probably
depends
on
the
application
and
and
if
each
of
those
actually
represents
almost
another
set
of
decision,
trees
and
sort
of
some
fairly
complex
systems
management,
again
things
that
you
probably
don't
want
to
specifically
describe
in
a
solution
document
ie
the
data
models
themselves.
So
this
this
document
may
never
be
published
actually
in
net
Mott.
It
may
have
a
time
horizon
of
six
months
and
then
we
just
kind
of
close
it
down.
M
M
So
all
all
of
these
things
are
actually
sort
of
really
important.
I
mentioned
that
the
the
document
in
net
mod
also
has
some
sort
of
implementation
considerations,
discussion
text,
so
these
around
operations
and
security.
So
here
again
in
terms
of
database
management,
so
using
ECA,
how
do
you
authorize
it?
You
know:
how
do
you
manage
who
has
access
or
how
you
delegate
a
particular
ECA
to
a
device
who's
allowed
to
do
that?
When
are
they
allowed
to
do
that?
What
kind
of
method
would
you
use
in
order
to
apply
that
policy?
M
We
also
sort
of
highlight
some
database
discussion
as
well,
specifically
the
various
states
of
data.
So
what
are
we
looking
for
in
the
NMR
G
currently?
Well,
not
much
really
just
sort
of
highlighting
that
this
particular
document
exists,
and
then
it
points
to
some
of
the
solution
work.
Obviously
it's
it's
low
level,
it's
imperative
policy
usage,
but
it
may
make
a
lot
of
sense
actually
to
consider
how
this
work
I.
You
know,
II
see
a
maps
to
intent.
M
You
know
your
things
like
intent,
classification
or
service
insurance,
so
documenting
the
relationship
between
some
of
the
net
mod
work
and
some
of
the
discussion
that
we're
having
in
this
document
to
existing
NMR
G
discussion
documents.
Although
they
are
individual
efforts
at
the
moment,
you
know
could
be
of
interest
and
also
a
piece
of
work
that
I'm
working
on
currently
under
the
UK
project
called
NGC
di,
which
has
converged
digital
infrastructure.
M
Eca
against
and
essentially
a
device
isn't
just
a
router
or
some
kind
of
forwarding
or
functional
element,
but
it's
a
limited
controller
in
you
may
be
in
a
very
sort
of
specific
technology
domain
comprising
of
a
couple
of
notes
and
actually
what
we're
doing
there
is
also
trying
to
identify
what
are
the
applicable
languages,
the
rules?
What
is
the
current
arch?
How
widely
deployed
are
they
are
they
applicable
for
all
types
of
ECA?
Obviously
not
so
we
are
looking
at
network
and
resource
and
database
management
and
just
trying
to
classify
them.
A
E
E
That
is
not
everything
is
suitable
for
ITF
activity,
but
it's
interesting
here,
especially
because
ECA
probably
is
the
best
way
we
have
to
discuss
about
what
I
would
call
low-level
intent
or
base
intent
or
whatever
we
call
it
in
the
previous
presentations
we'll
be
talking
about
precisely
through
a
conflict
resolution,
reasoning,
etc
and
reasoning
about
how
this
is
translated
and
how
different
sources
of
intent
and
different
channels.
This
is
something
that
would
help
and
well
would
help
us
well
to
understand
better
what
we
are
referring
when
we
talk
about
intent.
This
is
something
interesting.
A
And
I
think
especially
for
question
two.
This
is
something
I
indicated
to
Dan
through
some
exchange
that
I
think
a
good
starting
point
could
be
positioning.
We
offer
the
kind
of
internal
proto
intern
framework.
You
have
your
ETL
framer
proposal.
I,
really
think
that
there
is
a
link
between
the
two
where
ECI
is
kind
of
end
of
the
chain.
A
Application
of
an
intent
could
be
interesting
to
see
how
the
two
maps,
if
there
are
gaps,
how
they
get
into
work,
so
potential
interesting
questions
to
discuss
and
again,
if
you
translate
into
documents
even
better
for
IHF
or
IETF.
Thank
you
very
much
cool.
We
at
the
end
of
the
session
time.
Thank
you
very
much
for
the
presenters.
A
First,
all
the
good
questions
and
comments,
especially
for
the
to
last
presentation,
since
they
were
also
linked
to
draft
that
are
being
proposed
in
the
IETF
I,
would
propose
that
the
offers
can
send
an
already
been
done
partially,
but
send
the
draft
to
the
nlg
mailing
list
and
ask
for
opinion
from
the
group
a
way
to
maintain
some
kind
of
relationship
between
this
different
bodies
of
work.
I.
Think
it's
interesting
proposal
and
I.
We
really
would
like
that
it
doesn't
stops
after
this
meeting,
so
maybe
try
to
entertain
some
some
some
discussions.
Thank
you
again.