►
From YouTube: IETF102-ANIMA-20180718-0930
Description
ANIMA meeting session at IETF102
2018/07/18 0930
https://datatracker.ietf.org/meeting/102/proceedings/
B
A
A
E
D
D
A
F
A
A
This
is
the
meeting
agenda.
We
had
a
quite
full
at
in
that
day
we
will
have
full
working
group
draft.
Each
of
them
helps
only
and
minutes
or
less
because
some
of
them
already
reached
the
end
stage
of
the
working
group
document.
So
hopefully
those
would
has
sufficient
time
for
them,
and
next
we
have
the
arc
operation
of
not
servicing
ASAP
networks,
and
we
have
the
put
struck
key
infrastructure
over
the
I
Triple
E
environment
and
the
next
has
the
autonomic
function.
A
Lifecycle
management,
together
with
the
correlation
between
autonomic
function
and
our
energy
exchange
done
by
Laurent
and
the
and
mentleman
boundary
and
by
parameter.
Then
that's
the
information
distribution
in
Ottomans,
networking,
piping
and
guidance
for
the
autonomic
service
agent,
together
with
the
transform
packingtown
her
over
grasp,
I
bran
and,
at
the
last,
its
trust,
networking
and
procedure
of
autonomic
networking
patty
any
at
in
the
posh
one.
A
Three
actors:
okay:
this
is
a
very
brief
summary
for
the
Masters.
Later
we
have
managed
to
publish
to
our
FCS
sense
masts,
ITF
meeting
in
London.
That
goes
for
our
virtual
and
stable
connectivity.
We
actually
it
before
that.
We
already
has
two
documents:
grasp
and
profits
management
rich.
They
are
say,
publishing
procedure,
but
has
been
held
down
by
the
mission
reference,
hopefully
in
where
we
be
able
to
do
that.
A
A
D
Alright,
so
the
quick
summaries
may
be
original
goal,
the
first
round,
seven
documents
to
are
out
now
right.
So
since
last
idea,
so
the
first
two
are
FCS
that
we
have
towards
to
help
held
hostage
in
the
RFC
editor
Q.
So
it's
the
three
others
that
were
basically
just
pushing
through
to
get
all
the
remaining
five
released.
A
So
that
gives
us
we
have.
Actually
three
documents
in
the
current
working
group
stage
puts
drop
key
infrastructure.
It
actually
already
passed
the
working
of
Lascaux
last
month
and
its
plan
to
submit
to
AST
this
month
and
when
you
knock
patottie
adopted
cross
api
in
December
last
year
and
the
constructed
and
just
rent
vulture
adopted
in
April
and
so
far,
don't
want
to
give
you
some
words
for
the
chattering
or
at
the
end
of
the
position
yeah.
We
can.
A
H
This
is
a
reminder
of
what
is
the
API
I
bought,
because
the
croc
cross
stack
is
not
located
in
the
kernel
space
and
in
order
to
that,
the
user
space
is
us
to
share
the
same
functions.
We
need
a
API
between
them
and
there
are
some
standard
functions
already
defined
in
cross,
for
example,
the
discovery
and
flood
and
negotiation,
synchronization,
etc,
and
in
the
future
we
may
also
have
some
additional
functions.
So
we
can
also
add
these
functions
to
be
called
by
the
SS.
As
the
picture
shows
the
extended
function,
library.
H
So
here
are
some
a
little
change
from
las
ATF.
We
had
some
discussion
regarding
to
the
even
loop.
The
comments
were
mailing
from
illness
and
the
result
is
that
we
obviously
notify
function
to
to
inform
the
even
loop
that
something
might
change
is
already
changed
for
the
session
and
the
even
locrians
for
the
constraint
device.
Is
that
not
capable
of
doing
multi
thread
grasp?
H
And
we
also
consider
in
to
align
the
error
code
values
to
be
consistent
with
a
standard
socket
API
because,
as
you
can
see
in
the
in
the
figure,
there's
a
IPC
between
the
API
and
and
the
kernel,
so
it
is
actually
buried
by
the
socket
API.
So
if
we
can
align
the
error
code,
there
will
be
more
consistent.
H
D
Okay,
I
wanted
to
give
a
quick
update
on
the
ACP
draft,
so
we
were
at
13
in
London
we
went
through
about
50
percent
of
the
ITF
iesg
review
five
more
votes
on
the
is
free
to
go.
There
was
a
lot
of
work
done
between
13
and
16
ow,
not
really
any
technical
changes
about
what
the
what
the
acp
aspect
does,
but
you
know
a
real
good
amount
of
technical
explanations.
Coming
back
from
you
know
the
questions
from
the
reviewers,
it's
on
the
iesg
challenge
at
first
of
august
or
a
2nd
of
august.
D
So
here's
basically
summary
of
the
high
level
points
that
were
added
so
applicability
and
scope.
You
know
for
for
readers,
easier
catch
up
in
the
B
in
the
beginning
of
the
document,
more
details
about
crl
certificate,
revocation
listing
we
didn't
have
the
security
ad
review
yet
so,
hopefully
we're
already
in
getting
in
better
shape
for
that
lifetime
of
certificates,
re-enrollment
of
certificates.
So
all
this
certificate
management,
the
things
that
we
were
you
know
expecting
to
be
understood,
but
then
you
know
most
of
the
reviewers
weren't.
You
know
these,
assuming
that
that
was
the
case.
D
So
we
had
a
lot
of
informational
text
in
the
document
at
the
end,
which
I
split
up
into
two
sections.
One
is
what
I
consider
to
really
the
important
stuff,
even
though
it
can
only
be
informational,
because
it's
all
the
operational
aspects.
So
that's
basically
now
the
new
section
about
registers
I'm
going
to
talk
about
and
then
the
existing
unchanged
on
diagnostics
and
enabling
disabling
the
ACP.
So
those
things
are
not
related
to
protocols
but
operators.
Unless
we
do
a
Yank
model,
this
is
informational
in
here
and
then
the
other
stuff
I
move
to.
D
You
know
the
discussions
about
why
we
did
things
and
what
we
could
do
in
the
future
that
might
even
go
into
an
appendix
through.
The
final
is
3
review.
I,
don't
particularly
like
the
ordering
of
appendices,
but
that's
the
point.
So
the
big
you
think
being
done
was
adding
a
lot
of
information
about
registers,
and
you
know
the
way
that
we
originally
tried
to
split
up.
The
work
was
that
we
were
thinking.
You
know
this.
D
So
one
other
possible
protocol,
for
example,
that
you
know
we
could
see
being
used
in
that
concentrate
and
environments,
would
be
in
our
versions
of
net
from
zero
top
touch
class
extensions
instead
of
a
brewski,
of
course,
using
the
voucher
and
all
that
security,
making
it
in
just
different
signaling
steps.
Right
and
ultimately-
and
this
is
hopefully
we're
going
to
have
a
little
fun.
D
D
D
D
And
then,
of
course,
also,
if
you
know
Nash
is
the
secured
flesh
and
doesn't
let
itself
be
considered
without
getting
it
after
that,
you
need
to
talk
to
your
vet
DeMatha
and
then
only
the
certificate
and
know
and
live
happily
ever
after
in
the
ACP
all
right.
So
that's,
basically
the
process
I've
done
this
manually
for
verification
a
long
time
ago,
and
so
basically
we
we
can
have
you
know
any
type
of
protocols,
people
or
whatever
it
is,
and
we'll
just
call
this
ACP
registrar's
and
that's
kind
of
what
the
text
now
says.
I
Brian
carpenter,
so
I
I,
like
the
fact
that
you
have
an
explicit
domain
admission
controller
there,
as
well
as
the
explicit
Massa
I,
think
it's
sort
of
I'm
not
quite
sure
where
that
is
right,
discussed
in
the
ACP
direct
draft,
because
I
haven't
looked
at
that
bit
of
the
text,
though
I
know
that's
a
point.
That's
left
vague
in
the
brewski
drafts.
Now
I,
don't
actually
care
which
of
the
two
documents
says.
Clearly,
there
is
a
separate
function,
which
is
the
domain
admission
controller,
whether
that
has
to
be
said
very
clearly
somewhere.
I
D
Think
you
know
there
have
been
differences.
You
know
point
well
taken
after
the
differences
in
how
different
authors
have
been
dealing
with
the
non
normative
part
of
the
text.
Right
there
are
authors
like
me
that
prefer
to
elaborate
more
than
necessary
and
the
ones
that
you
know
maybe
prefer
less
than
necessary.
We
had
this
text
in
brewski
and
right
now,
it's
gone
and
I'm
trying
to
remember
the
reasons
for
that,
because
basically
you
could
write
any
everything
or
nothing.
So
maybe
it's
really,
as
you
said,
just
the
minimum
statement.
D
D
To
get
the
certificate
and
then
the
the
operational
aspects,
you
know,
I
feel
a
berated
more.
The
Registrar
interactions,
like
I,
showed
them
certificate.
Renewal,
registrar,
centralized
policies
yeah.
So
please,
you
know
if
you
haven't
reviewed,
that
part
of
the
text
would
be
happy
to
get
that
feedback
too,
and
that's
it.
J
K
Can
I
ask
a
question?
Oh
of
course
thank
you.
My
name
is
Alex
Callie's
from
University,
College
and
I.
Don't
understand
very
well
the
progress
made
and
that's
remarkable
on
this
part.
However,
I
have
some
difficulty
to
understand
three
little
issues.
The
main
function
of
this
control
plan
is
to
allow
communication
between.
K
K
K
The
in
the
relation
between
the
real
control,
let's
say,
host
date,
control
plane
on
the
network
functions
already
and
this
communication
facility.
It's
not
very
well,
not
clear
to
me
and
that's
a
first
question:
where
are
this
interaction?
The
second
question
is
related
to
the
other
function
of
Cisco
cause
a
current
control
plane,
which
is
about
allowing
an
external
operator
or
a
management
system
to
practically
configure
it.
If
that's
the
case,
where
are
the
relevant
primitives
or
the
api's
to
allow
this
to
happen,
and
if
he's
happening,
is
it
a
control?
Planner?
K
D
So,
basically,
if
you,
if
you
check
the
the
reference
model,
which
is
why
we're
giving
an
overview
in
a
summary
right,
the
A&I
that
we're
doing
right
now
is
really
the
basis
of
just
you
know
any
communication
fabric
that
we
need
for
autonomic
agents
or
for
centralized
management.
It
basically
does
nothing
more
than
basically
giving
you
autonomically
configured
ipv6
reach
ability
between
your
autonomic
agents,
service,
discovery
through
grasp
and
security
through
the
certificates,
and
the
same
is
equally
available
to
anything
certain
centralized
in
the
north.
D
I
Come
on
carpenter,
again,
Alex
I
think
also.
Some
of
the
answer
to
that
question
is
supposed
to
be
in
the
SI
guidelines
draft,
because
you
know
it
is
an
a
si
that
actually
manages
objects,
devices
talking
devices
or
target
functions,
so
the
the
actual
action
of
managing
you
know,
radio
frequency
assignment
in
a
radio
system
or
something
is
not
a
function
of
the
ACP.
It's
a
function
of
the
autonomic
service
agent,
for
that
particular
part
of
network
management.
So
in
a
sense,
your
question
is
probably
addressed
to
the
wrong
draft.
D
In
cars
right
the
the
common
part
right
in
in
new
cars,
they
call
that
the
platform
and
then
they
basically
put
the
hood
and
everything
on
it.
So
maybe
it's
really
the
autonomic
control
platform
right,
just
the
lower
layers
and
the
ASA's
are
basically
the
hood
with
the
passenger
seats.
So
we'll
see:
okay,
just
a
quick
update,
unfortunately
Michael.
If
you're
willing,
I'd
be
happy
for
you
to
chime
in
and
say
anything
about,
brewski,
so
I
just
wanted
to
give
quick
status
update
right.
So
we
basically
went
through
shepherd
review.
D
We
got
one
new
IPR
disclosure
that
I
posted
to
the
list
from
juniper
and
that
actually
is
an
old
one.
It
was
just
the
ITF
process
that
it
has
to
be
associated
with
every
individual
draft
that
applies
to
so
this
was
disclosed
kind
of
as
an
IPR
I
think,
two
or
more
years
ago,
already
against
the
net
from
zero
touch.
Draft
so
equally
applies
to
brewski,
so
Shepherd,
write-up
and
I'm.
Trying
to
give
this
to
the
ad
this
week,
they're
a
couple
of
minor
foremen.
D
It's
Brian
carpenter
found
this
one
thing
where
texts
have
been
deleted
and
not
put
back
so
I'll
probably
try
to
mention,
and
it's
in
the
Shepherd
write-up
and
would
like
to
get
this
thing
going
quickly
into
the
ITF
in
iesg
review.
Man,
that's
pretty
much
all
of
our
brewski.
Unless
somebody
else
has
questions
or
Michael
wants
to
say
something:
okay,
yeah,
probably
northern
Canada
with
an
RV,
is
a
little
bit
difficult
for
an
average
ability.
Sir
okay.
A
A
A
L
Okay,
this
is
my
first
presentation
of
this
draft
in
this
working
group.
Thank
you
for
meit's.
It
has
been
accepted,
as
working
group
to
draft
so
makes
me
quite
happy.
It's
about
two
constraint.
A
voucher
I
will
try
to
explain
a
little
bit
how
it
is
situated
with
respect
to
the
key
in
fat
document
and
why
we
wanted
to
have
this
and
what
it
is.
L
Thus,
if
it's
Hansen
made
an
extension
to
the
voucher
for
for
the
for
the
for
the
cosine
cultural
perspective,
the
voucher
definition
and
what
it
also
does
is
that
in
the
voucher
it
uses
young
and
the
young
is
very
long,
identify
us
and
what
we
have
added
to.
That
is
that
we
use
the
seats
which
are
marked
here.
What
that
means-
and
you
know
instead
of
having
this
long
identifiers,
we
just
got
the
numbers
which
has
been
which
are
based
on
brass,
which
I
published
in
Decorah
working
group
on
the
other
one.
L
What
the
graph
does
it
instead
of
using
HTTP
it
uses
coop,
it
uses
seaport,
a
uses,
CMS
and
it
uses
cosy,
which
is
also
a
facility
to
do
end
to
end
payload
protection.
When
transport
yep
I
go
cover
more
details,
we
have
done
since
the
for
the
individual
version
has
done
some
progress.
We
have
defined
DC.
Yes,
oh
I
didn't
want
to
interrupt
at.
D
L
You
may
interrupt
now,
okay,
so
what
we
have
done
is
a
little
bit
about
that.
We
have
introduced
the
CMS
and
the
cozy
media
types.
We
have
introduced
the
definition
and
we
have
prepared
the
young
modules
which
an
extension
to
the
voucher
young
module,
which
has
already
be
defined
in
the
down
in
the
voucher
aircraft.
L
This
the
draft
relations
as
I
said
this
is
my
view,
so
actually
there's
much
more
in
the
world
and
is
described
here,
but
just
to
make
the
difference
is
clear.
So
what
we
have
is
the
Brisky
or
key
infra
which
uses
HTTP,
TLS
est
and
CMS
and
and
what
it
actually,
in
my
point
of
view,
does
miss
respect
to
the
draft
we
are
presenting
here
is
that
it
has
EST.
It's
the
voucher
request
that,
instead
of
doing
all
the
certificate
request,
you
also
have
to
file
a
request.
L
It
has
a
matter
added
to
it
and
something
which
is
very
important
also
to
visitors
enjoying
proxy
to
go
from
the
pledge
to
the
joint
proxy
to
the
register
etc
for
their
registration.
No,
there
is
another
draft
which
is
done
in
ace,
which
is
called
EST
coop
s
and
what
we
also
are
relying
on
and
which
it
actually
does.
L
L
Then
we
have
the
voucher
round,
which
is
based
on
John
and
Jason
and
uses
CMS
and
what
it
actually
does.
It
extends
Brisky,
in
my
point
of
view
again
we
Steve
out
respect
and
then
finally,
we
come
to
this
draft.
It
is
presented
the
animals.
Thank
you
very
much
what
it
just
it
uses
young
in
sable
seaboard.
Instead
adjournment
and
Jason
it's
to
reduce.
Actually
the
payload
uses
the
voucher,
but
it
extends
the
voucher
is
to
fields
which
permits
it
to
have.
L
Instead
of
owe
me
the
certificate,
also
an
public
key
added
to
it,
for
which
we
can
use
for
the
for
setting
for
the
security
of
the
of
the
of
the
air.
Now
school,
ok
for
the
process,
so
we
have
to
foul
her,
and
we
have
to
brisk
Eve
is
coercive
or
sober
which
we
use
the
cow,
Sasebo
format
and
thus
its
and
we
use
the
CMS
seaboard
mister
seats.
Why
do
we
use
two
of
these
cows
and
the
CMS?
L
The
cause
of
Allah
will
certainly
be
used
for
the
60s
working
group,
but
they
have
the
very,
very
small
devices,
and
we
will
use
the
CMS
in
the
case
for
for
for
the
stos,
which
are
still
dependent
on
CMS
and
don't
want
to
do
all
the
investment
to
change
all
that
the
products
to
immediately
go
to
the
cosy
about.
So
this
added
two
things
which
is
divine
additionally.
What
we
think
in
this
future
still
needed
is
the
clearance
of
constrained
joint
proxy,
which
is
specially
done
in
the
context
of
the
Brisky
for
st
oaks.
D
Yeah,
so
I
was
born
into
a
time
when
we
had
this
simple.
You
know
manually
defined
TLV,
so
drafts
try
to
be
very
simple,
because
it
was
a
lot
of
pain
to
write
this
up
so
now,
I'm
exposed
to
ever
more
different
encoding
things
and
gets
more
and
more
complex
and
more
and
more
versions,
because
everybody
has
so
yada
yada
yada.
What
are
there
any
real
relevant
functional
differences
between
all
these
different
versions?
If
I
eliminate
all
these
differences
in
encoding,
let's
say
I'm
trying
to
ignore
all
the
encoding
differences.
D
L
Okay,
this
is
about
abstraction
and
yeah,
it's
difficult
in
principle.
It's
all
the
same
Brisky
process.
You
have
a
pledge,
you
have
proxy
and
you
have
to
register
and
the
CA
and
you
have
the
vouchers
in
the
matter,
and
so
it's
all
about
that.
Only
what
is
different
is
that
we
want
to
reduce
the
payload
instead
of
HTTP.
We
want
to
use
co-op,
which
is
Bourdon
for
constrained
devices
which
also
payload
we
want
to
be
compatible
with
the
whole
co-op
environment.
So
you
see
the
cosa
which
is
coming
up
there
and
I.
D
J
A
J
L
Then
I'm
afraid
that
Michael
will
be
much
better
in
answering
that,
but
it
is
for
seeing
that
it's
not
only
that
he
wants
to
use
it.
I.
Think
in
the
60s
environment
that
we
use
the
the
certificates.
But
there
is
also
the
possibility
to
use
the
the
third
piece
of
our
public
keys
for
the
exchange
of
the
two
for
the
protection
yeah.
I
Brian
carpenter,
by
the
way
Michael
Richardson,
dropped
off
me
taker,
so
I,
don't
think
he's
with
us.
My
questions
about
the
last
line.
The
the
extra
document,
if
you
so
do
I
understand
that
the
constraint
join
proxy
would
not
itself
be
constrained,
it
would
be
a
sort
of
normal
device
or
it
would
be
a
normal
sort
of
piece
of
software.
I
L
I
L
Almost
so
here
are
the
CMAs
and
cosy
media
types.
So
this
is
the
register
that
you
want
to
propose
to
Jana
and
then
the
city
definitions
I
mean
it
is
just
for
your
information.
You
see
how
a
young
file
young
identifiers
and
you
see
that
instead
of
having
those
very
long
I
don't
identify
it,
you
can
reduce
them
to
only
one
number
and
they
have
to
be
registered
as
well.
So
it's
more
registration.
L
What
do
we
have
to
do
for
this
draft
to
make
it
draft
which
it
can
be
used
and
for
interrupts
and
all
that?
So
we
have
to
update
the
example
payloads,
given
that
you're
working
also
on
implementation,
I
think
once
we
have
the
implementation,
we'll
use
the
example
payloads
will
come
in
and
we
have
to
prepare
and
in
talk.
We
are
quite
optimistic
about
the
progress
of
this
draft.
L
A
M
A
D
The
best
sequence
is
to
try
to
figure
out
what
we
would
like
to
propose
to
the
working
group
as
we
charter
and
discuss
that
with
the
ad.
Then
basically
will
send
the
proposed
charter
to
to
the
working
group
list
and
then,
of
course,
we'll
Bechet
out
and
hopefully
we'll
get
accepted
soon
and
then,
of
course
afterwards.
D
D
That
is,
you
know,
after
bootstrap,
enrollment
ACP,
coming
up
continuously
through
its
lifetimes,
discovers
the
most
crucial
services
that
the
NOC
can
have,
so
that
the
NOC
can
contain
continue
to
Auto,
configure
it
right
and
they're,
really
I
think
a
very
few
services
that
you
need
to
auto
configure
initially.
Obviously
that
list
is
perfectly
well
for
you
know
when
we
adopt
this
for
the
working
group
for
a
discussion.
In
my
opinion,
the
first
one
you
want
to
have
is
you
want
to
have
some
accurate
time
write,
discover
your
NTP
servers.
D
So
then,
basically,
you
know
the
not
needs
to
know
what
the
heck
is.
The
node
is
doing
and
the
most
you
know
classical
way
on
how
to
do
that.
Diagnostics
is
syslog
right
there,
newer
alternatives.
So
as
my
colleagues
who
are
working
on
that
stuff,
but
basically
more
simple,
you
discover
syslog
and
then,
of
course,
you
need
some
way
to
remotely
interact
with
the
system
and
basically
there
are
two
kind
of
you
know
most
common
methods.
One
is
the
manual
operator
method
which
is
SSH.
D
The
other
one
is
net
conf,
obviously
they're
a
lot
more
right.
If,
if
people
feel
that
that
that
more
alternatives
are
needed
that
well,
we
can
perfectly
add
that
actually,
in
many
cases,
net
cons
is
just
run
over
SSH.
You
can
also
run
it
over
TLS,
so
those
might
be
parameter
differences
but
effectively.
The
idea
is
at
these
services,
our
auto
started,
so
that
from
the
knock
you
can
login
to
the
device
and
manage
them.
You
know
from
a
controller
or
from
a
CLI,
and
then
the
question
is
okay.
D
What
do
we
actually
need
to
announce
for
that
to
Auto
configure
this
service,
and
that
actually
is
just
an
authentication
mechanism
right,
because
you
can
have
all
type
of
different
instances
like
you
know,
Homer,
you
know
Tallis,
whoever
you
know
the
operators
are
the
names
of
the
different
you
know,
controller
systems
are
and
they
need
to
have
different
access
privileges
if
at
all
access
privileges
and
those
come
from
an
authentication
server.
So
what
we
want
the
NOC
to
announce
are
the
authentication
servers.
D
So
then,
basically,
as
soon
as
the
ACP
device
discovers
authentication
servers,
it
can
basically
start
these
remote
access
control
mechanisms
like
SSH
Netcom
and
basically,
if
somebody
tries
to
log
in
through
them,
ask
the
authentication
server.
Ok,
here
are
the
credentials.
What
can
this
card
ID
this
this
instance
do
right.
So
hopefully
this
this
is
a
good.
You
know
starting
quite
minimum,
and
it
changes
extensions,
obviously
more
than
welcome
okay.
How
does
this
work
so?
D
Basically,
I
present
it
I
think
last
year
or
earlier
this
year,
draft
accurate
enema
grasp
TN
SSD,
and
that
is
basically
a
generic
definition
of
brass
objectives.
To
basically
put
DNS
service
discovery
information
into
that
right,
and
that
basically
means
anything
you
can
do
with
DNS
SD.
You
can
basically
now
run
over
browse
and
that
it
really
just
means
on
the
NOC,
the
servers,
the
radio
servers
or
even
a
proxy
for
them,
your
anti-peace
or
whatever
you
have,
would
simply
send
out
these
rest
announcement
using
this
format
and
on
the
right
hand,
side.
D
There
is
the
there
is
the
the
way
it's
represented
in
brass
right.
So
basically,
this
is
the
standard,
Grass
flood
message,
and
then
you
have
something
like
a
name
of
the
instance.
The
service
is
now
syslog
here
and
there
runs
of
other
parameters
like
your
priority
and
wait,
which
are
known
from
DNS.
There
are
actually
two
interesting
new
things.
We
can
do
with
brass
that
we
can't
do
with
mdns
or
unicast
DNS
SD.
D
That's
an
important
thing
and
this
stuff
that
I
added
there
if
I,
want
to
have
redundancy
I'm,
obviously
wanting
to
lock
to
multiple
servers,
so
I
need
to
indicate
okay
you'll
find
20
servers,
please
log
to
your
top
two
or
three.
So
that's
another
parameter,
I
added
and
that's
pretty
much.
There
is
about
it
yeah.
So
just
that
same
in
more
detail
written
so
summary,
we
want
to
make
the
a
and
I
network
automatically
use,
knock
services.
D
L
D
At
this
point
in
time,
it's
basically
an
island
right,
so
we've
basically
been
thinking
about
keeping
very
separate.
Unless
somebody
stands
up
and
say
here,
I
think
you
know
we
need
to
have
the
following
information
swap
back
and
forth
and
then
of
course,
that
would
be
perfectly
possible.
I
mean
a
gateway
from
you
know:
mdns
unicast,
DNS,
SD,
back
and
forth
to
grasp
is
perfectly
possible.
I
just
need
to
figure
out
the
use
case.
What
we
wanted,
okay
and
the
hybrid
proxy
should
have
a
central
repository
where
all
the
discovery
information
is
situated.
D
D
So
that
the
which
I
didn't
represent
the
DNS
SD
Draft
right,
so
that
really
already
says
that
anything
that
is
described
in
Ayana
as
a
service
right
in
the
service
registry.
Basically,
the
draft
describes
that
that
is
one
by
one,
the
same
that
you
can
do
in
grass.
So
if
you
have
any
service,
you
want
to
use
that.
The
question
is:
what
new
do
we
need
to
standardize
right?
So
what
I
was
trying
to
standardize
here
is
the
minimum
that
I
would
love
every
node
that
supports
the
ACP
to
actually
implement
right.
D
So
current
node
right.
So
again
it's
a
separate.
It's
it's
meant
to
be
a
separate
RFC.
So
if
you
know
in
the
future,
people
come
out
with
much
better
nodes
that
don't
need.
You
know
an
TPS,
it's
not,
and
so
it's
just
basically
meaning
to
have
a
afterwards
a
a
very
simple
example
and
be
also
very
good
subsets,
where
you
know
in
an
RFP,
you
can
say:
ok
to
support
a
CP
brewski
and
oh
I
want
to
manage
it
from
the
NOC.
D
This
one
simple,
RFC
right
so
notwithstanding
that
I
would
obviously
love
to
apply
this
to
a
lot
more
service
and
other
stuff,
and
if
we
feel
it
should
be
mandatory,
it
should
go
into
this
document.
Otherwise,
you
know
if
we
feel
it's
more
like
a
specific
choice.
I
think
we
should
put
it
into
another
document.
Ok,
thank
you.
D
O
O
So
there
is
one
related
draft
as
well,
which
we're
gonna
be
covering
on
Friday
and
the
EMU
session,
which
is
how
you
do
brueski
at
layer
two
inside
of
a
tube
tunnel,
so
that
is
a
potential
solution
for
some
of
the
problems
with
Wi-Fi
onboarding.
So
if
you're
interested
in
that,
please
attend
the
musician
for
more
details
on
that.
O
So
what
problem
we're
trying
to
solve
you
parallel?
You
part
of
a
plate
for
the
first
time
it
could
be
your
ultra
constrained
light
bulb.
It
could
be
an
EKG.
You
could
be
90
phone,
the
device
powers
off
for
the
text,
multiple
SSID
switch
as
ID.
Does
it
use
to
connect
to?
How
can
you
ensure
that
the
device
is
correctly?
The
correct
SSID
are
not.
O
You
know
the
company
in
the
floor
above
you
or
the
company
on
the
floor
below
you
and
you're
in
the
building
you're
in
our
credentials,
device
used
to
connect
to
the
SSID
initially,
because,
when
the
device
first
time
powers
up,
it
has
its
ID
EV
ID
and
after
the
device
is
connected
to
the
network,
has
done
its
initial
authentication.
It's
done
the
Bruschi
floors
enrolled
and
burner
has
an
its
l
divided
e.
How
is
network
authentication
managed?
How
do
you
manage
that
network
authentication
transition
from
one
device
doesn't
have
an
identity.
O
Sorry,
it
doesn't
have
an
old.
By
date
one
device
does
in
the
middle
of
ID
and
how
do
you
do
that
on
a
Wi-Fi
network?
So
what's
draft
outlined?
Is
a
draft
outlines
multiple
different
potential
solutions
to
these
problems,
but
does
not
make
any
final
recommendations
in
what
the
correct
solution
is.
It's
one
discussion
document
for
now,
so
there's
multiple
potential
building
blocks
for
solving
these
problems
today
and
for
SSID
discovery.
There's
multiple
I
Triple
E
standards.
O
It
could
potentially
be
leveraged,
there's
also
Wi-Fi
Alliance
standards
could
potentially
really
reach
as
well
and
trust
introductions
by
the
manufacturer.
We
know
we
have
aerated
the
one
AR
with
the
brewski
flow
enters
existing
it
rated
1x
and
M
attitude
at
that
11
specs
for
onboarding
out
for
authentication
as
well
after
proof
of
possession
and
the
Wi-Fi
Alliance
has
an
easy
connect,
which
is
also
known
as
the
device
provisioning
profile
for
proof.
Possession
animal
risky
mentioned
sales
channel
integration.
O
For
proof
of
possession,
but
the
finds
has
been
out
of
scope
and
so
there's
multiple
ways
of
solving
all
these
different
problems
and
probably
need
to
try
and
agree,
is
what
is
the
workflow?
We
want
to
choose
for
solving
these
problems
and
then
for
the
standardization
needs
to
take
place,
solved
problems
so
bootstrap
steps,
high-level
boots,
Jeff
Steffes
is
the
device
discovers
candidate
Wi-Fi
networks
to
connect
to
the
device
does
an
initial
connection
to
the
Wi-Fi
network
prior
to
completing
brewski.
At
this
stage
the
device
only
has
an
IDE
available
to
it.
O
The
device
completes
the
risky
flow
and
enrolls,
and
then
the
device
may
have
to
reconnect
the
Wi-Fi
network.
Now
it's
been
Prudential
and
we
want
to
do
proof
of
ownership
and
depending
on
which
solution
we
chase
proof
of
ownership
could
happen
around
in
steps.
1,
2,
3
and
there's
multiple
different
technical
solutions
falling
across
multiple
different
standards,
bodies
for
how
we
could
do
proof
of
ownership.
O
So
looking
at
some
just
some
of
the
options
for
SSID
discovery,
these
are
all
documented
in
the
draft,
but
these
are
just
some
of
the
top
ones
and
we
could
bake
a
one
with
the
define
or
well-known
brewski
SSID
and
make
sure
the
network
operator
is
configured
that
SSID
name.
Then
devices
were
not
connected
apps.
We
could
define
an
arrow
to
extension
to
advertise
pretty
capability.
O
We
could
leverage
Wi-Fi
Alliance
extensions,
so
my
clients
already
has
DPP
we
could.
It
doesn't
quite
fit
the
bill,
but
we
can't
find
extensions.
Tpp
I
know
the
fallback
option
is
there
is
an
existing
attitude
at
11
new
internet
access
advertisement,
so
we
could
into
a
device
that
it
sees
an
open
network.
I
just
looked
for
a
vendor
default
registrar,
but
we
need
to
consider
and
device
state
machine
complexity.
If
you
want
to
do
that.
O
Some
considerations
for
authentication:
it's
a
pretty
risky,
a
new
device
only
at
the
site
of
ID.
It
needs
to
read
the
reach,
registrar
and
there's
multiple
possible
10th
occasion,
mechanisms
that
we
could
use
for
the
device
to
make
that
initial
SSID
connection
on
authenticators.
The
network
could
be
enforcing
wpa2
or
wk3
or
a
shared
bathroom
is
needed
and
we
could.
We
could
connect
to
a
Wi-Fi
network
doing
and
for
seniority
to
1
X,
8,
TLS
and
I'd
use
it.
O
O
But
some
considerations
here,
an
SSID
typically,
cannot
support
multiple
authentication
mechanisms
that
only
supports
one,
which
means,
if
you
want
to
transition
from
pre
briskly
to
post
risky,
using
a
different
authentication
mechanisms.
The
device
needs
to
connect
to
multiple
Isis
IDs.
The
device
state
machine
gets
very
complicated.
O
O
At
the
authentication
options,
so
I
categorized
into
pre
and
post
risky
authentication
options-
and
these
are
just
some
of
the
options
that
are
available
in
the
draft
number
one
is
device
connects
turn
on
thetic
on
authenticators
Wi-Fi
network
pre
Brisky.
It
completes
twisty
flow,
then
it
and
probably
has
to
reboot
switch
SSID
xandrie
IP
to
connect
to
an
altitude
of
1x
network
and
use
it
cell
divide
ii.
Option
2
is
a
device
connects
to
an
SSID
network,
that's
enforcing
wpa2
or
wpa2.
We
need
some
mechanism
to
get
that
WPA
or
wpa2
password
to
the
device.
O
There's
DPP
is
one
possible
way
of
doing
that.
But
again
if
the
device
is
switching
from
one
credential
to
our
second
credential
and
switching
between
us
as
IDs
device
is
going
to
have
to
reboot
and
re
IP
and
reconnect,
which
leads
to
a
very
complicated
device
debt
machine
number
three
is
the
device
uses
TLS
for
the
type
of
ID.
So
it's
doing
attitude
of
1x
ETLs.
O
Sorry
by
defining
new
T
Quixote's.
That
turns
word
to
brewski
messages.
So
when
the
device
connects
to
an
ADA
to
the
One
X
Network,
the
device
completes
the
layer
to
eat
flow
and,
as
part
of
that
layer
to
eat
fill
it
gets
credential
and
gets
as
L.
Divided
is
about
a
time.
Fanta
casein
is
complete,
it
is
credentials,
but
it's
held
up.
Id
we'll
be
talking
about
level
it
that
want
writer
so
for
proof
of
ownership.
O
So
proof
of
ownership
really
means
ensuring
that
your
device,
when
you
plug
in
your
lap,
your
lightbulb
your
device,
doesn't
connect
to
the
Wi-Fi
network
on
the
floor
above
you're
in
the
floor
below
you
there's
multiple
different
mechanisms.
Some
of
them
are
outside
in
the
draft
as
well.
One
is
you
could
leave
recorded
alluded
to
in
the
Brisky
draft
lee
reached
the
master
and
sales
channel
integration,
so
that
means
the
master
has
an
explicit
map.
O
Our
network
operator
owns
what
device
and
the
master
will
only
voucher
the
correct
network
operator,
so
you
connected
along
as
his
ID.
He
won't
give
a
third
option
to
doesn't
really
prevent
connection
to
the
wrong
network
option.
Two
is
the
network
operator
relies
on
mass
allows
to
detect
whether
their
missing
device
is
gone?
It's
locking
a
light
bulb.
You
see,
it's
powered
up,
you
don't
see
it
in
your
network,
the
query
massive
defined
it
who
owned
it,
who
vowed
tradition?
Number
three.
O
You
rely
on
network
operators
to
be
good
citizens
if
you
connect
the
wrong
SSID
you're,
relying
on
the
the
network,
the
wrong
network,
to
reject
your
request
that
we
can't
rely
on
that
because
most
opera
are
a
lot
of
operators
really
just
configure
permissive
network
policies.
Do
that
I
need
to
buy
some,
and
finally,
I
can
for
is.
The
network
must
prove
some
possession
of
a
shared
key.
O
So
does
the
shared
key
associated
the
device
it
could
be
a
public
year,
complete
private
key
and
the
device
will
not
connect
to
our
network
on
less
than
our
proves
the
ownership.
With
that
private
key
of
that
Cherokee
there's
multiple
ways:
you
could
do
this
multiple
technical
implementations.
You
can
do
this.
You
could
use
a
handshake
similar
to
Wi-Fi
lines
DPP,
you
could
use
a
symmetric
key
and
do
something
using
TLS
one.
The
three
PSK
inside
Nurit
tunnel
does
multiple
ways
of
doing
it.
O
So
summary
is:
does
multiple
options
available
for
us
at
each
selection,
dozen
multiple
options,
the
options
available
for
SSID
authentication,
with
multiple
options
available
for
proof
of
ownership,
those
options
found
in
multiple
different
standards
bodies
so
depending
on
which
workflow
we
want
to
chase.
The
technical
solution
will
live
within
the
remit
of
a
different
standards
organization
and
we've
been
discussing
this
a
little
bit
over
the
mirror
on
enough
the
last
couple
of
months,
but
I
don't
use
any
consensus
yet
on.
I
Brian
carpenter,
I
think
I'm
developing
a
standard
question
right
because
I
have
it
about
the
base
brewskie
document
and
the
ACP.
You
know
that
there's
a
lot
of
focus
here
to
proof
of
ownership
in
a
sense
of
proving
that
you're
joining
the
network.
You
are
happy
to
join,
but
I
want
to
hear
more
about
the
opposite
question
of
whether
the
network
is
happy
for
you
to
join.
It
I
think
it's
it's
a
slight
in.
G
I
Network,
which
is
the
inverse
pop
questions,
whether
the
pledge
wants
to
join
that
Network
and
the
same
thing
is
that
it's
very
lightly
dusted
over
in
the
brewski
document
and
the
ACP.
So
you
know
I
think
we
need
to
be
a
little
bit
more
clear
that
this
is
also
one
of
the
questions
to
be
asked
during
enrollment.
D
So
right
so
right
now
what
we
have
in
brewski
is
that
pretty
much
you
can
only
join
the
network
that
owns
the
XS
that
you're
using
like
whether
it's
a
wired
point
or
a
Wi-Fi
access
point
right.
So
somebody
owns
this
network
and
that's
the
domain
you
can
own.
You
can
reject
you,
but
you
can't
own
another
net.
D
O
G
D
I
mean
I
thought
in
one
email,
I
was
giving
a
simple
example
right,
I
buy
a
device
from
some
reseller.
The
only
thing
necessarily
is
the
the
reseller.
Basically,
you
know
is
sending
to
the
masa
or
you
know
whatever
the
service
doesn't
have
to
be
the
same
thing:
the
stuff.
Okay,
this
serial
number
was
sold
to
this
customer.
That's
the
only
thing
required
right
that
you
barely
get
we
resellers
into
it.
So
I.
Definitely,
wouldn't
you
know
say
that
we
should
exclude.
You
know
document
in
defining
this.
Just
because
not
everybody
can
do
this
right.
D
O
D
Work
for
everything,
but
you
know
I,
think
there.
If
I
look
at
all
the
different,
you
know
tracking
system
that
I've
seen
whether
it's
kind
of
you
know
from
a
large
inventory
list
of
lightbulbs
over
to
something
you
know.
Basically,
reseller
knows,
for
you
know,
bigger
routers
or
so
all
those
cases
I
think
it
would
work
easily.
So.
P
J
Brian
and
or
at
least
addressing
it.
I,
don't
know
about
answering
it
is
what
is
the
relationship
between
the
device
and
the
manufacturer
and
what
knowledge
does
the
manufacturer
have?
So
we
presume
the
device
was
manufactured
by
the
manufacturer,
and
so
next
question
is
what
knowledge
does
the
device
have
out
of
the
box?
Does
it
know
anything
about
the
deployment?
The
whole
point
of
brewski
is
that
it
doesn't
right.
J
D
D
E
D
N
Those
concept
have
been
already
presented
in
the
past,
so
the
idea
is
to
represent
it
very
quickly
and
then
get
your
feedback
about
if
this
is
useful
and
also
ask
for
collaboration
on
those
topics
next
like
this.
So
this
is
a
proposal
about
defining
a
lifecycle
management
for
autonomic
functions
for
their
deployment,
especially
from
an
operator
coming
to
you.
N
So
the
idea
will
be
that
developing
is
life
cycle
would
appropriators
to
concentrate
only
on
achieving
the
goal
they
want
to
get
from
deploying
those
functions
in
the
network
and
not
to
spend
effort,
money
and
time
in
understanding
from
each
vendors
how
the
configuration
should
be
all
the
deployment
should
be
and
make
a
uniform
application
about
all
these
deployment
options
on
there
so
really
get
the
use
of
the
functions
and
not
how
to
deploy
an
operator.
Second
thing
is
to
concentrate
on
the
core
functionality
and
not
how
to
interface
with
the
different
network
infrastructure.
N
This
should
be
embedded
into
the
deployment
of
the
asa
next
slide.
Please
yeah,
so
the
proposal
is
very
simple:
in
the
there
is
an
expired
draft
on
that,
but
we
propose
a
lifecycle,
and
this
will
be
the
core
of
this
torque
and
also
to
support
this
lifecycle,
a
set
of
different
objects
that
we
would
like
to
specify
for
the
ASA
in
order
to
make
this
lifecycle
usable
and
automated
next
slide,
please
so
the
lifecycle,
as
a
number
of
steps
I,
will
not
go
through
all
the
steps
but
I
like
in
special,
the
the
red
part.
N
So
we
start
from
neza
being
a
piece
of
software
that
is
installed
on
some
device
in
the
network,
and
then
we
want
to
see
how
we
can
go
from
I
mean
to
deploy
instantiate
the
different
instances
of
this
autonomic
functions
and
how
we
can
also
be
in
the
operational
phase,
so
instantiated
and
operational
and
the
different
stage
transition
and
the
different
object
needs
to
be
attached
next
slide.
Please
this
our
skip
next
slide,
please.
So
there
are
basically
three
objects
or
elements
that
we
need
to
be
proposed
to
specify
and
add
to
the
animal
specification.
N
First,
one
is
what
we
call
the
is:
a
class
manifests
or
class
manifests
a
bit
like
in
the
object-oriented
development.
You
can
have
a
salaried
functions
class
like
you
want
to
do:
traffic,
engineering
or
congestion
control.
You
can
have
a
family
of
those
out
of
different
autonomic
functions,
so
you
specify
a
manifest
descriptor.
But
what
what
does
this
function
is
doing?
What
kind
of
element
it
can
control
on
which
device
you
can
run,
which
version
of
OS
X
cetera?
N
So
this
is
just
an
example
that
we
have
I
mean
some
more
detailed
specification
and
also
reading
implementation
of
that
next
slide.
So
in
India
is
a
lifecycle,
this
mandate,
so
you
have
the
class
manifest
and
when
you
are
installed,
you
need
to
instruct
your
autonomic
functions.
What
what
what
you
want
them
to
do,
so
you
send
them
a
mandate,
and
this
will
deploy
the
autonomic
functions
over
the
network.
Next
slide,
please,
okay,
so
the
instance
mandate.
N
So
here
we
we
switch
from
class
to
instance,
because
we
want,
from
the
I
will
say,
generate
piece
of
code
of
atomic
functions
to
go
into
a
different
instances,
deploy
different
ASA
over
the
network.
So
here
you
need
to
have
an
instance
Monday
to
specify
for
this
piece
of
code,
exactly
on
which
device
it
needs
to
be
deployed
which
resources
it
needs
to
control
the
configuration
parameters,
the
operation
parameter.
So
it's
really
a
mandate
that
specifies
all
the
instantiated
aspects.
N
Are
matters
configuration
parameters
of
the
different
on
a
mix,
functions
that
will
be
deployed
over
the
network
next
slide,
please!
So
now
you
reach
the
states
where
you
are.
You
have
your
instance
shaking
the
different
atomic
functions
all
on
a
network,
and
you
can
have
the
autonomic
functions
to
when
they
are
deployed
to
a
feed
back
to
the
now
go
to
the
operator
or
to
the
management
system,
the
actual
configuration
when
when
they
have
been
deployed.
So
this
is
the
manifest
next,
so
this
is
the
instance
manifest.
N
So
we
have
the
mandate
mandate
express
what
the
functions
needs
to
do
when
the
manifest
is
the
the
other
way
around,
which
is
expressed
that
essa',
when
it's
deployed
give
feedback,
give
a
report
to
the
management
system
about
this
is
how
I've
been
instantiated
on
this
device.
Is
this
node
using
these
configurations,
this
just
kind
of
feedback
mechanism.
N
So
now,
in
the
number
steps,
when
the
actual
atomic
functions
are
running
on
the
network,
because
I
mean
ultimately,
you
just
want
them
to
just
you
just
say,
run
and
everything
will
be
perfect,
but
there
will
be
some
stages
where
you
want,
as
an
operator
or
as
other
functions,
to
be
able
to
control
the
behavior
of
those
after
Faison.
So
this
is
when
you
want
to
control
on
their
own,
so
we
need
additional
types
of
message
to
actually
turn
them
on
and
off
or
change
their
kind
of
operational
regimes
and
next
slide.
N
Please
now
also
the
steps
of
exchanging
information
or
even
knowledge
between
different
autonomic
functions,
because
in
terms
of
interactions,
you
can
have
interactions
that
are
given
atomic
functions
need
information
from
another
system
to
be
able
to
perform.
Well
some
functions.
May
collaborate
cooperate
together
to
achieve
a
common
goal.
Some
functions
will
conflict
so
using
information
exchange.
There
are
a
lot
of
of
those
interactions
that
can
be
either
enabled
or
control.
N
Yeah
so,
and
what
we
call
additional
users
is
what
I
will
express
in
the
following
presentation.
So
this
is
to
describe
a
bit
a
proposed
lifecycle:
how
to
deploy
and
operate
in
a
common
way.
Those
autonomic
functions,
and
we
will
use
this
lifecycle.
So
essentially,
the
management
system,
the
operator
to
deploy,
operate
and
get
feedback
on
the
operation
of
those
functions,
but
also,
they
can
be
I
will
say
other
autonomic
network
functions.
N
That
can
also
make
use
of
this
of
the
steps
of
this
lifecycle
of
the
elements
of
this
lifecycle
to
interact
with
the
user
function.
So,
essentially,
the
next
presentation
will
be
on
the
coordination,
as
I
mentioned,
different
interactions
between
those
functions,
but
also
in
exchange
of
information,
and
they
can
be
other
functions
for
for
the
ao9.
N
N
K
N
K
Since
then,
few
things
happen
and
I
would
like
to
comment
on
it.
Pure
connectivity
base.
Autonomic
functions
is
not
anymore.
The
main
goal,
in
other
words,
it's
a
time
to
look
at
network
services
as
well.
These
are
the
things
with
driving
now
and
try
knowledge.
There
is
already
worldwide
an
attempt
to
virtualize
or
if
you
on
software
eyes,
10,000
of
such
things.
Gradually
networks
may
happen
early
in
China
and
later
another
parcel,
but
is
happening
so
to
some
extent.
K
K
In
other
words,
a
genetic
network
atomic
function
is
going
to
be
enough
without
additional
guarantees,
and
when
you
come
to
it,
if
you
want
to
do
it
properly,
in
my
view,
it
does
not
make
sense
to
put
them
in
a
whole
network
because
they
could
interfere
to
each
other
and
sometimes
operator
wants
a
low
latency
network
functions,
and
the
other
word
want
something
else,
and
the
two
could
interfere
for.
This
is
where
slicing
comes
to,
and
therefore
this
loop
of
lifecycle,
which
I
mentioned,
should
be
sliced
aware.
K
Otherwise,
is
not
practically
magic,
so
that's
a
kind
but
strong
requirement
in
order
to
create
a
slice
for
some
parts
from
some
characteristic
and
mother
slices
if
you
run
parallel
for
other
as
a
way
to
easier,
and
this
has
to
be
taken
into
account-
these
are
called
precision.
Networks
are
called
Nautilus
to
have
you
guaranteed
KPIs.
If
you
aren't
for
a
particular
network
service,
this
have
to
be
involve.
You
add
it
to
this
process
rather
than
to
the
for
for
for
it.
K
Some
work
was
done
here
in
a
draft
about
slicing
and
may
be
useful
to
to
come.
But,
finally,
this
process
will
be
successful
if
it's
a
large
number
of
genomic
functions
or
autonomic
network
function,
network
service
functions,
but
in
this
way
could
be,
but
in
this
place
not
three,
not
five.
The
scalability
of
this
process,
like
a
DevOps
as
I
know
they
specifically
Saria,
has
to
be
developed
to
be
checked
and
so
on.
So
this
have
to
be
added
here
in
order
to
make
it
more
useful.
K
N
You
Alex,
because
I
still
have
two
to
presentation
to
give
I
mean
these
are
very,
very
valid
comments,
my
yeah.
What
we
present
is
really
also
to
get
the
view
of
the
chairs,
but
also
of
the
group,
but
this
is
kind
of
proposition
of
a
night
future
item
for
for
the
working
group.
So
for
sure
the
approach
is
not
fix.
N
K
K
N
As
a
question
involve
and
they'll
be,
with
your
point,
Alex
I
think
if
we,
if
we
are
modern,
the
12s
that
it's
important
to
discuss
this
odd
progress
on
this
item.
These
are
the
things
we
need
to
list
as
criteria.
What
is
the
scope
of
what
we
want
to
do?
What
will
be
implication
for
anima
and
then
start
to
work
on
specifying
a
bit
more
the
content,
the
forum
at
Exeter?
Can
we
Leo?
Can
we.
N
H
Know
in
in
general,
I
believe
this
work
is
necessary
because
you
read
this
work
could
be
considered
as
a
kind
of
meta
ASP
before
any
specific
aces
are
running
correctly.
We
must
have
some
mechanism
to
make
sure
how
the
is
as
could
be
initiated
on
a
device
and
how
they
could
be
terminated
and
to
also
to
make
sure
they
don't
have
serious
a
clearance
between
different
users,
so
in
this
sense,
I
I
think
it's
necessary.
H
Otherwise,
we'll
have
to
fall
back
to
manual
operations
of
these
eases,
which
I,
don't
think
is
acceptable
in
terms
of
autonomic
network
perspective.
Yes,
so
having
I'd
like
to
see
the
progressed
come
up
with
more
specific
protocol
extensions
or
some
not
behavior
requirements
into
details.
Thank
you.
Thank
you.
A
First,
working
on
this
I
have
process
comments
and
I
think
you
know
us
the
majority,
it
seems
particularly,
but
we
have
that
together
into
the
ASA
cadence.
But
beyond
that
you
definitely
need
to
define
something
new,
including
post
interface,
and
the
comments
you
would
like
to
sit
around
the
wire
so
that
maybe
lead
some
new
works
here
with
a
new
draft.
I
guess.
B
G
A
A
N
Liked
one
specific
aspect
that
can
be
obviously
using
the
previous
lifecycle
management
on
some
operation.
The
idea
here
is
to
highlight
a
problem
when
on
problem
in
when
you
have
multiple
atomic
function
running
in
a
network
and
ways
to
try
to
address
it
from
a
standard
quantity,
so
coordinating
multiple
atomic
functions
next
slide.
So
first,
why
we
need
to
coordinate
this
diagram
only
to
go
into
the
detail,
but
it's
an
example
of
different
autonomic
functions
in
a
mobile
environment
context.
N
While
you
have
a
set
of
parameters,
a
set
of
metrics
different
and
we
say,
functions
that
use
these
different
parameters,
the
metrics
and
the
interactions
of
all
these
different
functions
together.
So
it
can
become
quite
complex
to
understood
the
different
interactions
dependencies
among
these
function,
parameters
and
metrics,
especially
from
a
European
point
of
view-
and
this
is
just
for
one-
will
say
deployment,
and
this
is
a
what
we
call
a
static
deployment.
This
is
not
instantiate
it
and
deployed
environment.
N
So
imagine
that
you
can
scale
it
by
a
thousand
instances,
so
those
interactions
are
quite
complex,
so
we
want
to
have
non-human
interventions
to
coordinate
next
slide.
Please
so
different
types
of
interactions
they
may
be
always
but
essentially
conflict
and
it
needs
to
be
well
involve
cooperation
or
dependency
between
the
different
function
so
one
another
and
in
one
function
we
need
the
outcome
of
an
order
to
perform.
Well,
it's
complex
to
be
managed
by
humans
because
of
scale,
speed
and
island
appearances.
N
The
proposal
is
to
have
to
correlate
the
quality
behavior
the
common
function
that
we
be
able
to
all
AFM
a
bit
like.
We
have
a
previous
presentation
from
from
Tallis
about
NOC
services.
This
can
be
a
coordination
services
that
any
function
can
subscribe
and
say.
If
I
have
a
conflict,
then
I
may
use
external
services
to
arbitrate
the
conflict.
So
it's
not
on
the
job
of
the
AF,
but
it's
a
separate
service
next
slide.
Please.
N
There
is
a
kind
of
coordination
life
cycle
also
with
three
times
of
three
steps:
the
specification
time
you
can
already
identify
a
set
through
the
function
descriptors,
what
matrix
parameters
functions
or
what
what
the
function
is
doing.
So
you
can
already
develop
what
we
call
a
static
map.
So
it's
a
priori
knowledge
about
what
would
be
the
interactions
or,
but
if
you
deploy
such
functions,
then
there
is
a
deployment
time
when
you
actually
wants
to
deploy
the
software's
on
the
different
resources.
N
So
there
you
have
a
more
detailed
knowledge
and
view
about
the
e
potential
conflict
map.
So
this
is
the
deployed
conflict
map,
but
it's
still
not
running
instances
and
then
you
have
at
runtime.
This
is
where
you
already
have
all
the
other:
the
autonomic
function
that
are
really
running
operating
on
the
network,
changing
the
different
parameters
and
impacting
the
matrix,
and
then
you
have
that
dynamically
updates,
the
interaction
groups
and
the
interaction
map.
So
this
three
different
three
times
needs
to
be
taken
into
account
and
can
relate
to
the
previous
permutation
about
the
life
cycle.
N
But
when
you
deploy
operate
and
run
autonomic
functions,
this
is
probably
out
of
scope
of
what
animal
could
eventually
specify.
But
it's
just
to
give
a
light
about
that.
Our
workable
solution,
post
potential,
algorithm
and
mechanism
that
you
can
deploy
and
that
I
exist
to
address
different
coordination
or
interactions
aspect
of
autonomic
function.
So
you
can
be
really
random
token.
Based
approaches
versioning
time
your
article,
optimization,
more
or
less
sophisticated
approaches
or
algorithm,
you
can
imagine
that
can
be
more
or
less
also
adapted
to
the
different
type
of
conflicts
that
you
will
face.
N
I
mean
some
conflict
are
very
simple
and
you
can
just
by
separation
in
time
you
can
address
them,
some
really
more
complex
to
address
because
of
the
number
of
functions,
but
also
because
of
the
idiom
dependency,
and
so
you
need
maybe
more
sophisticated
approaches
to
fine-tune
the
interactions
next
time.
So
what
we
want
to
discuss
here
in
anima
is
the
implication
about
this
coordination
concept
and
the
services
that
could
be
a
proposed.
N
We
think
it's
important
from
an
operational
point
of
view
to
propose
is
to
manage
this
coordination
in
order
to
ensure
the
stability
and
the
convergence
of
the
network
operation.
It's
it's
a
program
that
is
not
at
the
scale
of
one
atomic
function.
It's
cross
autonomic
function,
so
it
should
be
reusable
component.
N
N
So
we
need
also
some
level
of
common
representation
of
information
on
knowledge,
as
we
alighted
in
the
complete
map
and
also
maybe
some
aspect
of
when
you
decide
about
what
time
of
correlation
you
want
to
to
do,
but
to
make
it
executable
under
networks
also
a
kind
of
interface
to
actuate
on
the
decision
of
the
of
the
coordination
mechanism.
I
think
that's
all
yeah.
A
A
N
N
D
N
So
why
is
it
important,
so
we
already
mechanism
in
animal
to
discover,
for
instance,
services
or
objectives
that
autonomic
functions
needs,
but
it's
not
always
this
sufficient
to
our
discovery
mechanism.
The
creation
of
knowledge
is
also
important
in
autonomic
networks
in
order
to
understand
the
context
of
the
operation
and
be
able
to
take
more
informed
decision.
So
this
is
why
there
is
a
need
to
go
beyond
simple
discovery
and
simple.
I
will
say:
data,
manipulation
or
information
actions
and
grow
it
to
a
level
of
kind
of
knowledge,
exchange
and
I
will
say.
N
The
message
what
we
have
tried
to
highlight
in
this
draft-
which
is
also
expired,
but
the
concept
is
here,
is
to.
We
don't
want
the
group
to
position
itself
on
the
creation
of
knowledge
and
definition
of
what
knowledge
excites.
Not
does
we
want
to
focus
on
the
mechanism
ours.
A
common
interface
is
common
mechanism
that
any
automic
functions
can
have
in
order
to
subscribe
to
knowledge
or
to
publish
some
some
knowledge.
N
If
at
the
end
you
have
1
million,
maybe
you
want
to
optimize
such
flows.
You
know
that
not
to
miss
it
to
overload
the
network,
so
there
are
also
so
information
for
optimization
subscription
flow,
simulations
or
different
types
of
aspects.
You
want
to
also
perform
at
the
network
level
about
this
knowledge.
In
fact,
knowledge
exchange,
infrastructure.
N
So
in
the
draft,
it's
a
bit
detailed
description
about
a
possible
implementation
with
some
specification
of
functionality.
This
is
not
what
we
would
like
the
group
to
really
go
over,
but
it's
well
to
give
an
example
that
this
is
feasible.
But
we
really
want
to
highlight
the
knowledge,
exchange
and
management
aspect
of
what
is
draft.
It
can
link
to
a
very
different
aspect-
monitoring
measurement,
but
also
to
fit
some
learning
mechanism
or
analytics
mechanism,
and
also
the
information
management,
information,
distribution
and
optimization.
N
So
what
we
have
in
the
draft
would
be
to
serve
as
the
basis
for
the
discussion,
but
is
it
useful?
Is
it
needed
and
what
needs
to
be
specified
by
this
group
in
terms
of
interfaces
and
behavior
of
the
different
entities
that
takes
parts
into
this
into
this
knowledge
sections
not
only
the
ordinary
function,
but
also
the
document
services.
K
That
it
changed
since
that
that
vision,
I'm
asking
for
some
additional
elements
to
be
looked
at
as
a
as
far
as
a
coordination
designer
is
now
called
orchestration,
and
there
are
eight
open-source
Orchestrator
developed
in
a
world.
Many
other
research
projects
that,
in
all
of
them,
are
about
cooperation
and
coordination
of
different
tasks
within
the
area
of
applicable
application.
K
There
is
a
lot
of
body
of
how
this
may
happen
and
how
to
to
create
the
protocols
if
UN
for
orchestration
that's
one
common.
The
second
comment
is:
it
does
not
makes
to
me
anyway,
to
have
one
coordination
or
one
orchestration
framework
for
everything,
because
he's
not
practical
in
terms
of
how
you
deploy
it
in
terms
of
how
you
use
it
there,
it
has
to
be
for
a
partition
concept,
slice
slice
based
coordination,
orchestration.
It
is
now
the
suggested
option.
K
K
How
different
Orchestrator
will
will
communicate
exchange,
monitor
information,
whatever
reasons
and
so
on,
which
potentially
has
to
be
one
topic
in
a
multi
domain?
Efficient
orchestration
is
now
the
norm.
She
started
without
attaching
this
element
by
the
time
we
finish
it.
It
will
be
already
some
distinct
relation,
what
the
expectation
so
multi
domain
orchestration.
The
interworking
is
one
of
the
topic
here
to
be
added
as
far
as
I'm
concerned
as
a
suggestion,
but
the
work
has
to
complete
and
once
this
is
completed
once
again,
the
question
is
the
infrastructure.
K
Also
anima
doesn't
need
to
change
to
take
advantage
of
this,
because
it's
our
high
level
management
concepts
at
the
end
of
the
day,
including
the
exchange
of
work,
knowledge
in
whatever
form,
including
the
cooperation
orchestration
in
whatever
form,
including
any
other
thing,
so
that
should
be
listed
as
a
way
to
look
forward.
It
may
be
the
sum
of
the
animal
need
to
change
a
bit
to
take
advantage
of
this.
It's
a
chicken
and
egg
situation,
but
it's
unavoidable,
but
running
really.
I
Okay,
I
should
say
before
we
start
that
this
draft
is
not
labeled
enema,
because
it's
talking
about
in
history
I
think
is
much
much
wider
than
just
anima,
but
if
it
isn't
solved
in
the
wider
space,
we
have
to
solve
it
for
anima
anyway.
So
this
is
not
about
splintering
of
the
internet.
This
is
not
about
DNS
domains.
I
This
is
just
about
the
mains
next
one
please
so
one
fact
it's
undeniable
I
believe
is
that
many
types
of
limited
domain
are
appearing
in
the
internet:
home
networks,
office
networks,
vehicle
networks,
building
services,
networks,
SCADA
networks
in
general,
sensor,
networks,
any
kind
of
edge
network
in
the
IOT
enterprise
networks,
campus
networks,
data
centers
hosting
centers,
by
the
way,
those
in
particular.
But
in
fact
almost
any
of
these
networks
can
be
distributed,
network
slices,
their
limited
domains
and
content
delivery
networks,
and
there
are
probably
other
examples.
You
know
this
is
just
to
make.
I
You
realize
that
limited
domains
in
the
Internet
are
very
common,
and
one
of
the
things
that's
also
come
clear
to
me
is
that
limited
domain
technologists
are
appearing
in
the
internet.
Differentiated
services
appear
twenty
years
ago,
for
example,
an
explicitly
limited
to
a
domain.
Within
a
domain
boundary,
a
network
function,
virtualization
service
function,
chaining,
nvo,
three
overlays
segment,
routing
autonomic,
networking
itself.
The
ACP
is
but
is
very
specifically
a
limited
domain
home,
that's
a
limited
domains
or
there's
an
H
NCP
protocol,
which
is
specific
to
limited
domains.
I
Locally,
even
using
address
bits
for
special
purposes,
insider
domain,
and
if
you
read
the
basic
documents,
the
debt
net
working
group,
you
will
discover
the
deterministic
networking
specifically
designed
for
limited
domains.
So
people
are
producing
limited
domain
topologist
technologies
and
there
are
all
sorts
of
different
limited
domains
in
the
internet.
I
Now
the
problem
we
have
in
animal,
for
example,
is
we
didn't
actually
define
what
a
domain
is
we
sort
of
assume
that
we
know
by
magic
what
a
domain
is
and
who's
in
the
domain
and
who's
not
in
the
domain,
and
it's
all
supposed
to
be
settled
during
the
bootstrap,
except
that
we
don't
have
a
general
guidelines
as
to
what
the
domain
boundary
is
or
who
is
allowed
in
and
who
isn't
allowed
in.
So
that's
a
technology
gap
in
anima,
but
it's
a
technology
gap
all
over
the
Internet's.
Far
as
I
can
see.
I
So
the
challenge
we
have
in
this
area
is
the
internet.
Doctrine
has
always
been
internet
standards
are
Universal
in
scope
and
applicability,
but
in
a
limited
domain
you
need
limits
to
the
applicability
of
the
protocol.
You
know
it's
commonly
written
in
various
documents
that
this
particular
thing
whatever
it
is,
must
not
appear
outside
the
domain
boundary.
But
you
don't
know
what
the
domain
boundary
is.
You,
you
hope
there's
some
firewall
somewhere.
That
knows
it's
the
domain
boundary
and
knows
to
stop
this
particular
thing
escaping.
I
Also,
if
you
have
a
limited
domain
requirement
for
your
protocol,
you
might
think
that
allows
you
to
simplify
the
protocol,
because
you
don't
need
to
worry
about
going
across
the
internet.
That's
not
actually
true.
It
means
the
protocol
needs
to
be
more
complicated
precisely
because
it
has
to
be
confined
to
a
certain
domain,
and
it's
security.
Design
is
certainly
going
to
be
complicated
because,
by
definition,
if
it's
a
limited
domain
protocol,
it
must
not
escape
from
the
domain
and
that's
means
there
must
be
a
security
design
to
prevent
that
happening.
I
We
also
know
about
fifty
years
experience
that
a
protocol
which
is
intended
for
a
particular
scenario,
will
be
used
in
other
scenarios.
You
will
escape
from
where
it
was
designed
to
be
used
and
it
will
appear
elsewhere
in
the
internet.
So
the
challenge
we
have
is
to
reconcile
those
aspects
and
either
this
is
solved
in
a
more
general
way
or
each
limited
domain
technology,
including
anima,
will
have
to
solve
it
themselves.
Now
it
could
rush
off
and
design
a
solution
right.
I
We
can
probably
build
a
solution
based
on
this
question
of
the
authorisation
policeman
that
Telus
showed
us
earlier
for
anima
I'm
a
little
bit
reluctant
to
design
a
solution
that
only
works
for
anima.
You
know,
maybe
we
could
be
clever
enough,
as
apparently
we've
been
with
brewski
to
design
something
that
other
people
will
want
to
use.
Even
though
design
anima
may
be
a
true
being
an
ITF
wide
discussion,
I
don't
quite
know,
but
I
think
there
is
some
work
to
be
done,
which
is
to
figure
out
common
aspects
of
these
limited
domains.
I
Make
the
case
that
some
protocols
should
be
standardized
to
work
only
inside
atom,
a
limited
domain
and
make
the
case
that
we
need
some
sort
of
mechanism
for
defining
the
boundary
defining
which
nodes
are
members
of
the
domain
which
nodes
are
edge.
Members
of
the
domain
and
that
would
have
some
protocol
and,
in
particular,
security
protocol
implications.
I,
don't
know
quite
where
to
go.
The
the
draft
deliberately
leaves
these
questions
open.
I
This
future
work
I
would
like
to
know
if
there
is
interest
in
this
working
group
in
tackling
the
problem,
either
specifically
for
anima
or
trying
to
develop
something
a
bit
more
general
in
scope
that
could
be
used
more
widely.
Obviously,
that's
a
discussion
that
we
are
after
we
have
a
new
charter.
You
know
I
wanted
to
raise
it
here.
The
next
slide,
please,
oh.
D
D
That
means
it's
just
your
get-out-of-jail-free
card,
if
you're
not
meeting
whatever
the
internet
requirement
is
so
maybe
you
know
before,
because
the
IOT
stuff
I
think
we're
going
to
ongoingly
in
anima,
struggling
to
figure
out
how
much
of
what
draft
is
applicable
in
that
particular
constraint.
Road,
so
I
think
I
have
a
hard
time
figuring
out
if
I
can
come
up
with
generic
solutions.
D
If
I
already
see
that
the
one
constraint
environment
like
the
IOT
stuff
will
have
us,
do
continuously
ongoing
specific
thoughts
about
them,
so
I
think
what
definitely
would
be
very
helpful
is
you
know
a
more
complete
taxonomy
and
you
know
also
recommendations
on
how
to
deal
with
them.
I'm,
not
sure
what
the
best
working
group
is
to
do
that
right
because
things
like.
Oh
you
right,
control,
network
and
evil.
I
Topic
yeah
we've
got
some
feedback
already
from
inter
area,
which
is
quite
positive
and
we've
got
people
asking
to
have
little
private
discussions
about
it.
So
I
think
there
is
interest,
but
I'm
scared
of
it
becoming
a
topic.
That's
too
general
to
have
a
concrete
discussion
about.
So
that's
what
I
would
like
to
find
out.
If
there's
you
serious,
focused
interest
in
actually
solving
it.
H
Being
a
Oh
again
a
reading
that
the
title
limited
domains,
they
are
at
least
two
different
aspects
pop
up.
In
my
mind,
I
think
one
aspect
is
regarding
to
human
operation.
We
need
to
limit
the
demand
for
scalability
or
for
security
considerations.
The
other
aspect
is
regarding
to
it
really
limited
some
mechanism
in
a
certain
domain.
It
implies.
We
can
allow
heterogeneous
mechanism
to
run
in
differently
in
each
domain,
so
I
I
think
maybe
we
need
to
distinguish
different
aspects.
What's
the
implementation
of
the
limit,
that
means
yeah.
K
As
soon
as
I
like
this
direction,
especially
that
in
my
view,
will
have
a
substantially
immediate
effect
as
well
as
things,
it
is
now
a
norm
that
this
domains
or
multi
domains
to
exist.
This
technology
domain-
you
exist
for
the
last
50
years,
but
also
there
are
some
administrative
domains.
The
domains
which
uniformly
an
operator
could
apply
a
group
of
policies,
working
security
domain
or
anything
like
that.
So
suddenly
you
have
two
types
of
domains.
They
do
exist,
which
means
that
the
common
aspects
for
autonomic
capabilities
to
be
looked
at.
It's
one.
K
One
way
about
the
other
way,
which
is
more
practical,
is
to
look
at
a
multi
domain
issues
because
they
do
exist.
It
is
Specter
what
I'm
saying
or
anybody
else
and
at
the
end
of
the
day,
end-to-end
solution,
a
MIDI
and
multi
domain
or
some
coordination.
Orchestration
is
now
the
norm
in
terms
of
research
and
development,
and
this
could
be
the
source
for
additional
protocols
to
be
added.
In
addition
to
the
common
elements
which
we
look
for
and
the
other
aspect
which
are
on
to
add
is
that
domains
are
changing.
K
So
it's
not
a
static
description,
which
means
that
the
not
age,
the
core
and
otherwise
will
change
all
the
time
falls
away
to
handle
this
coordination
of
such
a
domain
or
orchestration
is
to
look
at
the
way
in
which
you
could
change
as
well.
So
this
is
another
dimension
of
this
practical
work,
which
will
add
value
to
the
two.
K
I
I
R
R
I
P
Crystal
dr.
Montgomery,
I
guess
I
had
a
similar
concept.
Are
you
trying
to
standardize
the
conceptual
notion
of
a
limited
domain,
or
you
know
you
know,
you're
a
list
of
examples
of
different
kinds
of
technologies.
Some
of
these
domains
can
be
distributed,
I
mean
it
can't
be
topologically
based
it's.
So
the
definition
of
what
is
a
limited
domain
is
a
function
of
the
technology
that
you're
trying
to
apply
it
to
it.
I
Could
be
I
would
actually
like
to
reduce
it
to
a
question
you
know:
is
this
node
in
the
domain?
Is
this
node
an
edge
of
the
domain,
and
if
it's
virtualized,
that
question
is
still
valid,
you
see
what
I
mean
so
I
think
probably
can
be
turned
into
a
concrete
question
that
we
need
to
do
a
bit
more
analysis
before
we
get
there
and
I
know
how
I
could
turn
it
into
a
concrete
question
for
the
ACP.
I
A
H
H
Remember
the
information
distribution
is
a
function
to
handle
different
patterns
of
information,
exchanging
between
autonomic
nodes
and
we
are
using
a
cross.
As
the
barium
protocol
analyst
ITF,
we
reorganized
the
requirement
and
several
general
different
information
exchanged
patterns
which
are
the
instant
distribution,
is
point-to-point,
flood
and
selective
flooding
and
in
synchronized
different
synchronization
distribution,
the
sub
pub
and
even
queue
and
distributed
storage.
You
know
for
the
last
tool,
even
pute,
anti-civil
storage.
They
are
mostly
some
sophisticated
handling
within
the
knot
and
maybe
sub-interface
is
already
enough
for
them
in
terms
of
interface.
H
For
the
new
version,
next,
please
for
the
new
version
in
order
to
explain
the
abstract
requirement,
especially
for
the
even
queue
and
distribute
storage.
We
include
some
reference
scenarios
that
could
be
potentially
used
information
distributed
mechanism.
They
are
meaning
from
3gpp
5g
scenarios
and
5g
a
another
part.
Is
we
give
some
specific
definition
to
extend
grasp
next,
please,
the
the
use
is
one.
Is
the
number
function
entity
as
we
can
see
in
the
figure
the
service
consumer
need
to
subscribe?
Some
event
from
the
never
report
function,
and
this
is
quite
intuitive
next,
please
now.
H
This
one
is
about
the
even
queue
as
we
can
see
in
the
middle
of
the
net
network
is
polar
function.
They
will
collect
the
events
from
multiple
network
functions
below
and
they
will
pray
our
priority
these
events
and
to
sort
out
which
one
should
be
immediately
sent
to
a
relevant
application
function
but
which
one
could
be
hold
for
a
second.
So
that's
a
reference
scenario
for
the
even
queue.
H
This
is
regarding
to
the
distributed
storage
in
a
factory
system.
There's
a
logic
entity
called
Joseph
Teti
repository
defined
because
no
network
function
will
stall.
Whilst
all
the
user
related
data-
and
they
all
need
to
be
sought
in
the
in
the
user
data
repository-
and
it
is
not
acceptable
for
for
a
user
to
come,
statically
configure
the
URL
of
the
repository
in
neither
a
function
to
dynamically
discover
and
to
send
the
message
you
need
to
be
stored.
So
that
is
actually
what
the
distribute
storage
time
in
the
information
distribution
next
fist.
H
H
It
is
also
not
acceptable
that
all
the
vehicles,
the
connected
to
a
single
server
or
in
the
cloud
to
get
the
newest
firmware.
So
this
firmware
need
to
be
distributed,
storage
in
different
edges,
and
we
can
also
it
also
needs
some
subscription
when
they
are
the
newest
firm
we
are
available
and
the
real-time
HD
maps
is
the
similar
logic.
H
For
example,
when
a
car
driving
to
a
special
field,
it
can
get
the
the
part
of
the
HTML
of
the
exact
of
the
the
place
at
the
local
edge
without
download
it
from
a
single
point.
Okay.
Next,
please,
okay,
the
following
are
some
specific
extensions
to
cross
the
first
one
is
a
new
message
called
unsolicited
synchronization,
because
current
cross
only
to
synchronization
when
there's
a
request
and
requests
a
message,
but
sometimes
it
will
need
actively
push
the
information.
So
we
need
to
define
a
new
message
for
that.
H
Next,
please,
then,
there's
a
option
define
call
selective
writing.
This
could
be
encapsulated
in
the
flattened
message
to
indicate
whether
this
message
is
suitable
to
propagate
to
other
nodes
or
just
dropped
at
the
current
a
node,
and
we
also
define
a
sub
a
sub
option
called
the
match
condition:
option.
H
H
I
Brian
Carpenter
I
just
wanted
to
say
that
I
had
a
quick
look
at
the
proposed
Ross
extensions
with
respect
to
my
prototype,
cross
implementation
and
thought.
I
couldn't
really
see
any
fundamental
difficulty.
Almost
the
devil
is
in
the
details.
I
haven't
had
time
to
actually
write
any
I,
think
code,
but
I
didn't
see
anything
fundamentally
wrong.
The
only
observation
I
made
is
the
push
the
unsolicited
synchronized
only
works.
I
M
H
H
M
H
H
N
H
This
draft,
it
is
out
of
scope
for
the
semantic
part,
but
as
though
I
think
you
also
have
a
tract
of
knowledge
exchange,
maybe
it's
more
proper
to
discover
semantics
in
a
knowledge
exchange,
okay
and
also
other
suggests
we
can.
Maybe
some
part
of
the
knowledge
exchange
could
be
merged.
Distributing
we've.
N
Discussed
yes,
okay,
yes,
thank
you
second
point
is
I
mean
that
there
are
some
other
works
in
IETF
around.
We
see
telemetry
and
new
monitoring
protocols
or
aspect
of
collecting
information.
Exchanging
information.
Do
you
see
any
relationship
between
what
what
is
here
a
bit
more
specific
for
animal
and
linking
it
to
order
aspect
like
the
dementia
framework
or
monitoring
protocols
and
as.
H
Far
as
I
understand
the
telemetry,
mostly
regarding
to
centralized
weather
or
whatever
is
controller
or
NOC,
there's
a
centralized
server
to
pull
some
information
monitoring
formation
from
both
devices,
and
it
is
an
account
and
the
llamo
low
specific.
So
so,
I
think
that
telemetry
they
have
concrete
scope,
concrete
mechanism,
but
in
the
full
distribution
I
think
it's
more
about
the
devices
they
interact
with
each
other.
Without
a
centralized.
H
I
I
Apart
from
that,
we
are
really
waiting
for
some
more
contributions.
Probably
some
of
Lauren's
material
needs
to
be
boiled
down
to
one
paragraph
to
go
into
the
air
say
guidelines
on
the
assumption
that
his
his
documents
will
become
working
group
documents
anyway,
once
we
can't
reach
artists
and
we're
waiting
for
more
feedbacks,
so
we're
ready
to
put
the
question
the
working
group
adoption
for
this
draft,
but
I
think
we'll
wait
till
the
recharter
before
we
specifically
ask
you
to
do
that.
I
Next,
please,
the
bulk
transfer
over
grass
draft
ooh
there
were
a
few
minor
TPD
items
which
have
been
filled
in
I.
Think
there's
nothing
controversial
in
the
in
the
the
text.
I
think
we
already
mentioned
it
in
the
in
the
draft
that
you
know
since
firmware
update,
is
now
an
interesting
topic
in
the
ITF.
You
know
you
just
like
to
point
out
that
one
of
the
things
you
could
do
in
an
autonomic
network
is
trickle
firmware
updates
through
using
a
grass-based
mechanism.
I
wouldn't
use
it
for
performance
high
performance
requirements.
I
If
you
want
to
do
your
software
updates
very
very
quickly,
this
wouldn't
be
the
way
that,
if
you're,
just
trickling
you
through
in
the
background,
which
needs
to
be
a
favorite
method
from
many
many
vendors,
then
gross
would
be
a
fine
tool
and
again
we're
waiting
for
feedback,
and
we
will
put
the
adoption
question
at
some
point.
So
that's
really
all
I
had
to
say.
I
A
A
S
This
is
our
initial
draft,
zero
tract
trust,
networking
and
the
procedures
autonomic
networking
before
I
were
going
to
be
at
this
topic.
Actually,
this
is
not,
although
this
is
a
new
introduction
to
this
working
group,
but
we
have
been
working
on
on
on
this
topic
for
about
three
years
in
an
itu-t
cellular
thirteen,
and
we
produced
two
recommendation
standards
regarding
on
on
the
on
this,
and
one
is
on
overview
of
the
trust,
networking
and
the
other
is
on
and
architecture
mechanism
and
procedures.
S
Yeah
next
slide
please.
So
this
is
motivation.
I
have
introduced
a
security,
current
security
model
and
it's
some
limitations
here
in
this
slide.
As
you
can
see,
the
security
model
of
the
current
Internet
is
based
on
the
assumption
that
all
traffic
coming
from
Internet
is
suspicious
and
the
leg
of
inherent
security.
S
So
the
we
I
think
most
of
us
are
well
under
understand
the
the
the
current
script
model,
because
you
move
on
to
the
next
slice
yeah.
So
here
in
this
way,
I
have
a
the
two
pair
is
in
between
the
current
secured
model
and
the
trust
model
that
I'm
proposing
here.
Those
two
are
pretty
much
opposite
in
its
characteristics.
S
The
trust
model
is
based
on
the
contents
that
entities
in
in
a
trust
networking
domain
which
I
enjoy.
This
is
another
unlimited
command,
as
Brian
said,
I
never
do
harm,
and
while
this
cute
mother
is
based
on
the
suspicion
that
Edward
adversary's
attack
anytime
and
the
relationship
in
trust
model
is
binary
in
the
sense
that
an
entity
trust
another
specific
entity.
But
the
relationship
in
the
spirit
mother
is
unary,
because
the
entity
itself
must
protect
regardless
of
other
entities
and
with
respect
of
rules.
S
Trust
model
keeps
trusted
IDs
as
whitelist,
but
the
security
model
keeps
threatening
at
the
des
Pollak
waste
and
and
as
a
behavioral
entities
in
the
trust
model
is
productive.
While
the
security
model
acts
in
brick,
metal
as
I
said,
and
that
leads
our
powers
of
trust
model
is
to
prevent
risk
by
communicating
only
with
trusted
entities.
S
But
policy
of
the
security
model
monitors
all
the
communications
to
detect
and
read
most
returning
actions
and
trust
model
provides
mechanism,
folks,
entities
and
the
domains
after
verifying
their
trust
based
on
trust
index
and
while
the
security
model
provided
mechanism
for
watching
the
traffic
and
parking
the
threatening
traffic's.
So
as
a
result,
the
the
network,
space
of
trust
model
starts
with
a
restrict
space
and
incrementally
grows
as
a
new
entities
or
domains
are
accepted.
S
While
the
genetic
space
obscured
model
starts
as
an
unrestricted
and
open
space,
but
the
space
may
be
diminished
by
excluding
behaving
entities.
So
could
you
yeah
next
license
so
based
on
these
two
parents,
Linden
and
in
limited
limitations
of
the
current
scope
model?
We
try
to
propose
our
trust
networking
domain.
S
The
objective
is
to
provide
a
trustworthy
communication
network
infrastructure
for
a
special
for
in
this
working
group
context
it
for
the
autonomic
computing
and
the
automatic
domain,
with
respect
to
trust.
So
Colonel
to
my
domain
doesn't
have
such
characters,
but
has
a
limited
one.
But
in
this
proposal
we
try
to
oppose
the
autonomic.
Oh
my
with
respect
to
trust.
So
it's
the
collection
of
autonomic
notes,
which
trust
each
other
and
the
host
ending
communicating
elements
as
autonomic
no
same
so,
you
may
need
to
expand
the
the
post
wrapping
process
with
which
trust.
S
Aspects
and
then
define
need
to
define
trust,
manage
register
and
also
another
component
called
to
make
it
way
for
the
communicating
with
our
DP
owned,
a
particular
trust,
to
make
networking
to
me,
and
also,
we
need
to
consider
the
pay-go
the
comparability
with
existing,
like
its
network
next
slide.
Please.
S
So
we
define
in
interrupt,
we
define
what
trust
networking
domain
and
also
we
define
our
three
different
aspects,
which
is
how
we
can
protect
this
truck
just
networking
domain
and
know
how
we
can
expand
just
networking
domain
for
the
scalability
purpose,
and
also
we
define
how
to
communicate
with
the
external
domain.
With
external,
just
networking,
you
can
see
those
records
in
diagram
next
slide,
please.
S
So
we
define
this
trust
networking
domain
as
an
application
of
animal,
that's
kind
of
the
sub-functions
defines
capable
they
find.
The
initial
network
domain
are
the
a
set
of
ASA's,
so
it
has
trust
gateway
function,
it's
kind
of
a
sa,
as
you
can
see
that
and
since
all
those
within
the
trust
network,
inter
main,
maintain
circuit
trust
level
set
by
the
domain,
communications
within
the
domain
can
be
done
without
any
further
security
concern
and
communications
with
external
node.
E
S
This
Aria
port
for
for
the
configuration,
so
we
have
trust
men,
trust
management
plane
which
takes
care
of
the
configuration
and
provisioning
of
the
identities
of
the
notes
within
the
domain,
and
also
it
performs
the
trust
evaluation,
whether
better
than
nodes
a
there
are,
can
be
accepted
as
a
trust.
First
of
all,
our
entity
in
the
domain.
So,
due
to
the
time
time
limitation,
I
think
I
can
I
can
go
into
the
next
slide.
S
So
here
for
the
invention
process,
the
first
step
is
identification,
so
in
a
trust,
networking
domain,
each
autonomic
node
should
be
identified
as
an
example
in
our
in
our
proposal
we
are,
we
are
defining
a
ID
called
self-certifying
ID,
which
is
a
set
of
private
and
public
key
here,
and
also
the
hash
of
the
poverty.
Is
the
planet
self
certified
idea
of
the
node?
S
This
is
not
an
example,
and
this
ID
can
be
used
in
fellow
that's
check
of
acclaimed
key
against
the
actual
probability
of
identity,
and
also
not
only
the
this
self
certified
ID
of
the
identification
method.
We
are
also
defined
in
trust
relationship
between
between
the
nodes,
so
both
identification
and
tribulations.
It
has
to
be
satisfied
in
order
for,
for
the
the
autonomic
nose
Beatrice
trouble
in
the
in
the
domain
next
slide,
please
so
on,
and
then
next
step
is
to
discover
and
and
the
signal
between
the
nose
within
the
trust
networking
domain.
S
So
the
trust
management
information
database
used
for
discovery
of
autonomic
nodes
and
also
the
from
the
sickening
point
of
view,
I
think,
since
this
group
already
has
already
defined
the
aggressive
protocol
for
force
for
the
signalling
purpose.
So
we
can
utilize
the
existing
mechanism
for
communicating
between
the
demos
if
there
is
any
any
specific
extensions
needed,
I
think
it
mainly
consider,
but
I
think
it
is
for
for
further
further
study
against
okay
next
slide,
please
so.
S
Another
important
aspect
is
the
trust
evaluation
for
for
each
node,
whether
whether
that
node
is
trustful
within
DHS
domain.
So
the
evaluation
network
is
the
way
of
calculating
trustful
networking
services.
It
requires
a
data
collection
from
various
sources,
physical
and
the
local
data
sources,
as
you
can
see
here,
precursor
in
made
manually
configured
by
the
policy
management
etc.
So
with
based
on
these
information,
it
performs
the
trust,
evaluation
and
then
make
a
decision
that
are
the
node
or
entities
within
this
domain.
S
It
is
trust
wall
and
the
we
are
still
working
on
this
trust
evaluation
mechanism
under
this
cover
trust
index
and
then
I
think
if
we
still
still
need
to
work
on
this
inspecting
okay.
Next,
please
so
in
interrupt
we
defined
as
a
use
case.
We
defined
two
procedures.
One
is
for
another
registration
as
the
autonomy
node
to
register
as
a
trust
upon
trust,
repel
entity
within
the
domain,
and
you
can
see
then
order
a
one
node
in
the
diagram
here
interacts
with
the
main
gateway.
S
The
domain
Gateway
assigns
the
private
libraries
to
note
and
then
also
it
to
mend
it
is
assigned
as
a
tip
for
Katie
for
the
IP
network
and
chose
the
information
management
is
a.
There
are
three
AAS
defined
for
this
purpose.
One
is
a
trust.
Information
management
si
and
the
other
is
a
domain
member
management.
A
si
and
third
one
is
the
ideal
location
management,
a
si.
So
through
these
interactions,.
S
S
For
example,
here
in
the
host
two
wants
to
communicate
with
host
one
which
is
in
in
different
just
networking
domain,
to
do
that:
a
host
to
first
contacts
with
a
trust
to
main
its
own
domain
gateways
and
then
through
the
ID
mapping
from
the
generic
ID.
The
surf
surf
ID
to
specific
ID
to
into
specific
to
two
issues:
trust
net
on
a
domain.
Those
can
be
done
by
this.
S
Currently,
we
defined
these
two
procedures
at
use
cases
and
we
are
going
to
work
on
on
the
furthers
other
cases
in
the
future.
So
this
is
a
brief
introduction
on
on
the
chest:
networking
for
a
for
tanaami
networking,
so
a
kind
of
extension
of
the
trust
aspect
to
the
autonomic
networking
capabilities.
So
as
next
step,
since
this
is
our
English
work,
you
would
like
to
welcome
your
comments
and
feedbacks
and
then
trapped
update
document
prepared
a
another
version
if
working
with
Phil's
interest
in
this
work.
Okay,
thank
you.
Yeah.
A
A
At
the
very
beginning,
I
think
you
know
what
you
described
for
a
trust
and
security
is
what
you
know.
I
I
think
what
we
would
like
to
have,
but
when
you
occur
through
your
design,
I
sent
a
dream
realized.
What
you
your
design
target
is
what
we
already
achieved
in
the
element.
We
already
have
the
trust.
A
System,
the
battery
and
the
way
to
discovery
and
to
communication
to
each
other
within
the
economical
network
domain
and
the
only
thing
missing
from
the
current
Emma
you
know
to
what
you're
described
here
is
only
in
the
the
data
connect.
The
communication
policy
in
antennae
planned
to
stop
the
then
the
note
to
talk
to
the
other
nodes
in
here
and
out
out
of
the
network
pantry,
so
I'm
I'm
getting
is
lost.
What
do
you
want
to?
You
know
standards
here?
What
the
extra
goal
you
want
to
achieve
here.
S
S
I
think
this
just
basically
explicit
in
mechanisms
we
have
defined
in
this
working
right
and
then
beyond
that
the
communication
aspect
between
the
once
it
is
involved,
and
you
consider
that
as
it's
cure,
scuri
enough,
then
then
you
do
not
apply
any
particular
skill
in
mechanism
for
the
communication
between
the
entities.
I
think.
D
You
mentioned
that
you
had
been
doing
something
like
a
prototype
or
demonstration
or
so
I.
Think
if
we
had,
you
know
a
little
bit
more
idea
about
a
practical
implementation
or
you
know
a
thing
off
of
your
concept
and
I
think
it
would
be
easier
to
map
it
to
to
the
enemy
case
yeah
yeah.
Actually
we
have
a
protocol.
S
We,
what
in
our
proof
of
concept,
what
we
implemented
is
the
the
the
main
concept
here?
Is
the
domain
gateway
on
capabilities?
So
what
does
the
I'm?
They
keep
the
domain
gateways.
It
consist
of
three
three
things:
the
identification
and
then
five
story
management.
Sorry,
what
those
three
three
functions.
D
What
would
I
mean
so
or
by
the
identification?
I
guess:
I
have
an
idea
what
that
means,
but
the
other
pieces
I
fight.
They
have
no
clear,
yeah
I
read
the
draft,
but
it's
a
it's.
It's
still
kind
of
for
me.
Difficult
to
translate
so
I
mean
I
was
thinking
okay,
so
this
is
some
form
of
a
firewall
where
the
policies
of
the
firewall
are
determined
on
an
authorization
profile
of
the
identity
of
the
neighbor
or
something
but
I'm
just
guessing
right.
D
So
that's
kind
of
I
mean
it's
always
hard
to
overcome
somebody
else's
terminology
that
you're
unfamiliar
with
right.
You
heard
that
I've
been
thinking
about
different
terms
and
they
mean
the
same
thing.
You
know
that
obviously
helps
a
lot
to
more
practically
a
vision
envision.
What
you're
doing?
Okay.
S
That's
why
I
mean
it
I
described
two
procedures.
One
is
on
the
node
identification,
registration
and
second
procedure.
Here
is
the
communication
between
two
nodes
within
to
two
different
are
just
networking
domains
and
in
within
this
procedure
we
can
see
those
are
our
ASA's
capability.
I
mean
functions.
How
what
those
functions.
S
S
Engage
basically
yeah.
The
main
issue
is
basically
yeah.
You
can
consider
it
similar
to
fiber,
which
sits
in
in
the
border
of
the
main
gateways.
So
we
once
it
is
identified
as
trust
of
all
entity
with
interest
domain
communication
between
those
entities
can
be
can
be
done
without
that
particular
security
measures.
So.
I
Brian
carpenter
now
I
got
two
comments.
One
is
I
found
your
slides
easier
to
understand
than
the
draft.
The
draft
left
me
very
unclear
what
the
relationship
to
what's
on
it.
The
ACP
is
what
the
relationship
to
brewski
is.
You
have
some
references
in
your
list
of
references,
but
you
don't
use
them
in
the
text
and
you.
It
really
would
be
much
easier
to
understand.
G
I
You
were
very
specific
when
you
say
in
the
a
autonomic
networking
context:
this
function
is
done
by
brewski.
This
function
is
done
by
the
ACP
and
so
on.
Then
that
was
very
unclear
to
me.
The
other
thing
which
comes
back
exactly
to
what
Telus
was
asking
is
I,
don't
understand
how
you
domain
gateway
can
actually
authenticate
and
check
addresses.
How
does
it
protect
itself
against
spoofed
IP
addresses,
and
how
does
it
do
this
at
lime
speed,
because
I
I
couldn't
understand
how
that
could
work
without
going
through
a
cryptographic,
processing
for
every
packet
and
I?
I
F
Is
Cho
from
Christ
in
Korea
for
a
we
have
a
several
type
of
the
it's
a
use
case.
We
have
a
some
application
layer
use
case,
or
so
is
a
transport
layer
use
case
for
the
application
layer
use
case.
We
currently
it
develop
two
thousand
discriminated
on
the
table
up
to
the
IPTV
service.
We
classify
to
the
rather
different
of
the
media.
We
and
we
have
a
separate
up
to
the
what
kind
of
the
trust
domain
to
protected
on
the
top
of
them.
Another
one
is
a
sharing
economy.
She
owned
a
economy.
F
Sharing
the
car
looks
like
uber.
We
have
a
discriminate
that
are
it's
a
customer.
Socio
customer
says
trust
fair
enough.
Some
of
the
customers
not
so
stress-free
no,
and
that
that
kind
of
scenario
we
try
to
apply
to
the
trust
model
on
the
top
of
them.
That
is
kind
of
the
scenario
we
have.
A
lot
of
the
scenario
is
already
implemented
in
the
in
the
year
year,
application,
but
that
this
issue
is
not
the
network
issue
in
the
application
level.
Ii
should
be
applied
to
the
first
concern.
I.
S
A
Yes,
I
guess
you
know,
I
need
to
ask
a
clarification.
Question
use
your
purpose
here
to
explore
deployment
use
case,
of
which
you
use
animal
components
in
your
network.
You
know
serve
your
application,
narrow
SAS.
All
you
try
to
define
some
new
components
to
you
know
new
animal
come
current
to
serve
you,
your
purpose,
which.
A
F
Choice
is
one
of
the
background.
We
proposed
the
trust
concept
we
review
each
three
years
ago.
We
already
developed
it,
which
is
one
of
the
tangible
security
technology
security
code
aristocracy,
not
anyhow
actual
dessert
came
from
to
the
human
who
believed
on
human
behavior
and
the
air
kind
of
the
transaction.
F
Eventually,
we
have
of
any
kind
of
a
security
technology
is
not
enough,
and
then
we
focus
on
directly
focusing
on
to
the
bad
child.
Human,
nearly
believe
you
hola,
and
then
he
in
combined
with
the
animal
concept
we
have
our
some
of
the
data
management
function
and
that
accumulation
will
believe
that
that
such
a
kind
of
the
little
accumulative
function
is
Polly
winner,
and
then
we
built
up
the
trust
enough,
but
in
within
that
environment
we
try
to
compare
to
the
lot
of
the
tangible
security
technology.
F
S
D
Thank
you
very
much.
It's
just
that
you
know
I
think
five
minutes
ago
this
turn
from
a
working
group
into
a
hostage
situation,
because
we've
ran
out
of
time.
So
thank
you
very
much.
Everybody.
Please
take
everything
that
you
still
want
to
discuss
to
the
list
and
then
hopefully
we'll
see
each
other
again
and.