►
From YouTube: IETF101-OPSAWG-20180319-1330
Description
OPSAWG meeting session at IETF101
2018/03/19 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
B
D
D
D
C
Me
try
and
yeah
the.
C
D
B
B
D
D
C
G
D
Okay,
then
so
that
only
took
us
nine
minutes
serve
them
stuff.
Good
things
were
good
thing,
we're
not
an
ops
group
or
anything.
So
hello,
everyone
welcome
to
the
UPS
area,
part
of
ops
area
and
ops
AWG.
We
here
is
the
note.
Well,
it
is
the
new
note.
Well,
it
is
fairly
similar
to
old
note
well,
but
has
other
changes,
so
we
are
going
to
need
a
minutes
taker
and
a
JavaScript.
D
So
we
are
going
okay,
who
it's
amazing,
how
like
nobody
makes
eye
contact
when
when
setting
up
at
the
front
being
like
who
would
be
willing
to
be
a
minute
taker,
whis
cleverly
took
Jabbar
because
now
I
can't
you
know
force
him
to
be
a
minute
taker
Joe
Clark
I
know
is
working
on
fixing
something,
but
I
figure
right
now,
he's
probably
fixed
it
and
and
rancid
I'm
sure
works
fine.
Now
and
so
Joe.
Will
you
be
minute
taker?
Oh
hang
on.
D
D
D
D
Does
anybody
have
any
bashing
of
the
agenda
that
they
would
like
to
do
great?
So,
first
off
we've
managed
to
figure
out
our
that
and
now
let
me
stand
up
and
go
to
the
big
Mike.
Actually,
I
can
do
this
sitting
so
as
everyone,
presumably
by
this
point,
knows,
Benoit
is
stepping
down
and
yes,
no
need
burst
into
laughter
at
this
point.
I
know
you're
happy
about
it,
so
yeah
Benoit
is
stepping
down
on
Wednesday
and
he
is
counting
down
the
hours
and
minutes
and
seconds
till
then.
D
But
you
know
I
would
like
to
personally
thank
him.
You
know
very
sincerely
for
having
been
an
awesome
awesome
ad
to
work
with
I
arrived,
knowing
absolutely
nothing
as
I'm
sure
he'll
be
happy
to
agree
with
I'm.
No,
knowing
absolutely
nothing
and
Benoit
has
been
truly
awesome
in
terms
of
sort
of
teaching
me
how
the
should
all
work
answering
a
lot
of
truly
stupid
questions
and
then
answering
them
a
second
and
third
time,
because
I
forget
the
answers.
D
The
first
view
and
just
you
know
generally
running
the
management
of
ups
and
management
for
a
large
number
of
years
in
a
very
dedicated
and
thorough
manner,
and
also
more
importantly,
sort
of
keeping
the
culture
alive
and
showing
how
stuff
in
the
IHG
should
be
done
and
the
right
way
to
run
things
and
so
seriously.
Thank
you
a
huge
amount
for
for
that.
It
really
means
a
lot
and.
D
K
Our
sponsor
would
say,
you
know,
make
right
choices
and
when
I
see
that
calorie
that
25
years
old
and
octomore
I
mean
these
are
pretty
good
choices,
so
proud
of
you
so
yeah,
it
was
quite
quite
a
fun
ride.
Six
years
you
know:
normally
you
always
do
with
term
or
two,
and
then
you
know
there
was
this
young
stuff
that
I
wanted
to
finish.
So
it
has
been
fun
challenging
sometimes,
but
I
don't
regret.
K
It
I
learned
a
lot,
and
you
know
with
the
question
that
you
are
asking
what
I
learned
after
six
years
is
that
the
more
I
know
the
more
I
know.
I,
don't
know,
because
there
are
so
many
things
that
was
happening
there.
It's
always
like
learning.
So
actually
I
learned
a
lot
from
you
guys
and
thanks
a
lot.
K
K
K
There
are
many
yang
modules,
so
somehow
its
success
for
what
you
guys
have
been
defining
and
yes,
there
are
many
yang
modules
right.
If
I
look
like
we
had
like
six
new
RFC
published
this
week
with
yang
modules,
we
still
have
like
250
yang
modules
coming.
If
you
look
in
the
the
yang
catalog
in
which
were
working
in
hackathon,
we
have,
as
of
this
morning,
3214
yang
modules,
unique
ones
right.
So
what
you
guys
have
been
defining,
it's
a
is
used,
and
you
know
it's
a
good
frame
to
have.
K
Now
we
are
on
track
I
believe
with
you
know,
yang
right,
so
the
idea
was
to
say
we're
going
to
solid
ice
of
protocols
and
the
encoding,
and
you
know
if
you
see
this
yang
catalog
and
this
logo
there
with
all
different
yang
modes
used.
The
idea
was
to
say:
let's
try
this
on
dice,
maybe
the
200
yang
modules
or
300,
the
ones
that
are
ki-44
for
everybody.
K
Now,
I
still
believe
that
we're
going
to
have
a
couple
of
challenges
and
I'm
going
to
just
throw
them
on
the
wall
and
see
what
sticks,
what
stick
and-
and
maybe
this
would
be
like
where
you
could
have
an
impact
right
so
in
terms
of
what
needs
to
be
improved
right,
because
the
solution
is
a
perfect.
We
are
inhalation,
where
we
are
running
current
consensus,
which
mean
that
by
definition,
consensus
takes
some
time,
and
you
know
for
operators
sometime,
it's
not
fast
enough
right.
K
So
in
terms
of
the
problem
we
might
be
having
we
have
right.
This
is
like
how
do
we
update
those
yang
modules?
That's
one
big
one,
all
right!
We,
we
know
that
you
know
by
definition,
by
with
the
yang
rules,
we
need
to
have
the
perfect
module
they
want,
because
they
must
be
within
a
backward
compatible
way,
but
we
know
also
that
this
causes
delay
right
because
they
have
to
be
perfect.
They
want
so
as
we
learn
more
about
those
modules
and
we
need
to
update
them
right.
K
The
last
case
was
from
a
difference:
do
a
hackathon
where
you
know
they
realized.
They
made
a
mistake
right,
so
they
need
to
be
updated.
So
this
is
where,
for
example,
will
need
to
have
something
like
semantic
versioning,
where
we
say
it's
a
major
minor
or
patch
upgrade
right
and
also
next
to
what
we've
been
doing
a
hackathon
those
health
metrics
about
young
modules
right
because,
regardless
of
how
good
we
believe
we
are
in
the
end,
isis
were
it's
used
because
it's
compares.
There
is
some
maturity.
It's
imported
there
is
called,
etc.
K
The
next
big
one
I
see,
is
the
examples
right.
We
start
to
have
many
examples
in
those
in
those
modules,
and
this
is
a
good
thing,
but
how
do
we
validate
those?
How
do
we
make
sure
that
they're
fine
right,
somehow
it's
done
by
the
inductors,
but
we
should
automate
this?
We
should
have
you
know
if
we
speak
about
github,
for
example.
Next,
the
yang
modules.
K
We
must
have
the
examples,
but
also
the
way
to
validate
the
examples
and
a
longer
time
have
more
and
more
examples
which
mean
that
we'll
have
two
different
life
cycles,
one
for
an
RFC
number
and
one
for
all
the
modules
and
the
examples
and
the
metadata
and
and
all
this,
so
that's
quite
a
big
one
as
well
and
and
the
other
one
is
maybe
where
are:
where
is
the
source
of
truths
for
all
these
modules
right?
So
people
still
extract
is
from
RFC's
right,
but
you
know
working
with
Ayana.
K
K
Word:
is
this
young
module
with
this
new
correction
right
now
we're
asking
people
to
extract
the
young
modules
and
to
apply
the
errata,
so
it
means
that
we'll
have
to
think
differently
and
maybe
have
this
in
Ayana
with
the
the
book
applied.
So
what
it
mean
there
is
this
time
zone
database
right
where
we
have
a
coordinator,
so
it
believe
at
some
point
in
time
we
will
need
to
have
the
same
thing
where
some
members,
the
committee,
would
be
in
charge
to
say
this
is
the
yang
module.
K
This
is
the
latest
version
and
if
we
combine
this
with
the
house,
matrix
have
been
mentioning
it
validates
and
as
we
learn
more,
there
are
more
varied.
There
are
more
features,
etcetera,
we'll
have
to
correct
thing.
So
this
is
maybe
another
thing
that
that
will
need
to
be
done
now
again.
Maybe
it's
the
long
list
of
problem,
but
these
are
good
problems
to
have.
We
went
away
from
the
face
where
we
have
to
sell
a
technology
to
it's
known.
K
L
Hi
Elliott
Francisco
first
Benoit,
thanks
very
much
for
your
service
for
these
many
years
and
for
your
commitment
to
operational
excellence
and
in
all
different
ways.
It's
very
much
appreciated
by
me
personally
and
having
a
level
head
in
the
room
always
always
helps
I
wish.
We
have
more
of
them
and
I'm
glad
to
say
the
ops
area
is
generally
and
pretty
good
about
that.
M
L
M
L
Into
the
IETF
they
should
answer
that
question
so
that
that
means
that
they're
not
just
going
to
come
here,
get
there
RFC
number
and
leave
but
actually
show
some
sort
of
commitment
to
me
to
maintaining
this
stuff.
I
think
that's
very
important
and
I
think
it's
a
little
different
from
the
TZ
model,
where
you
have
a
bunch
of
volunteers
who
come
and
go,
and
we
really
have
two
coordinators
who
honestly
have
been
doing
the
job
and
it's
sort
of
thankless
way
where
they've
been
sued
and
all
sorts
of
other
things
for
their
for
their
efforts.
L
F
All
right
so
Thank
You
Benoit
for
leaving
the
state
of
young
as
it
is,
and
for
me
to
try
to
take
that
over.
So
a
few
comments
on
on
the
view
of
the
other
things
might
continue
from
my
perspective,
so
my
view
is
that
the
core
work
on
young
language
itself,
the
protocols
is
mostly
done
not
necessarily
done,
but
mostly
done
it's
stable
and
so
sustainable.
F
We
certainly
need
maintenance
of
that,
but
the
bigger,
bigger
work
area
is
in
the
modeling
and
modeling
from
the
practical
point
of
view
that
now
we
don't
develop
models
just
because
it's
another
fashionable
trend
in
the
technology.
We
develop
the
models
which
address
the
actual
operational
needs
and
in
a
way
how
they
are
actually
being
used
in
the
field.
So
it's
about
operational
workflow
and
more
on
to
operational
workflow
and
usability
of
the
modeling
and
less
so
on
the
protocol,
mechanics
and
other
things
that
we
are
typically
used
to
work
in
IDF.
F
Idf
is
mostly
from
from
a
perspective
of
young
ITF
is
mostly
a
closed-in
organization.
Yes,
every
when
dealing
here
understands
that
technology
and
builds
on
that,
but
if
we
look
into
the
actual
field
into
the
deployments,
yang
is
still
not
there,
or
at
least
not
up
to
the
level
that
it
should
be
given
the
amount
of
work
that
we
are
investing
here
in
IDF.
F
So
from
that
perspective,
the
focus
likely
needs
to
shift
more
into
modeling
using
yang
becomes
more
of
a
tool
not
and
go.
But
this
is
just
a
tool
in
the
process
of
defining
how
the
other
technology
components
which
are
being
controlled
by
a
family
of
young
things,
can
be
used
operationally
and
in
a
practical
operational
way.
So
at
least
I
have
this
as
as
a
goal
for
myself,
and
then
you
understand
that
talking
is
easy,
but
trying
to
do
something
here
involves
a
lot
of
moving
parts
and
a
lot
of
other
entities
outside
of
IETF.
F
So
basically
we
we
need
to
focus
on
the
requirements
for
the
users,
the
users
of
the
technology,
the
users
of
a
young
and
less
so
on.
The
requirements
which
are
coming
only
from
other
working
groups
and
other
technology
domains
within
the
ITF.
So
I
think
that
work
phase
is
complete
young,
stable,
relatively
mature.
Now
it
needs
to
be
brought
into
usability.
H
N
Known
him
for
a
while
thank
you
were
at
Cisco
and
I
joined
back
in
98
already
we
went
through
some
hell
with
SNMP
together
some
hell
with
our
own
products
together
and
I.
Guess
some
hell
with
yang
together
and
we've.
You
definitely
got
me
a
lot
more
involved.
I
appreciate
that
you
got
me
a
lot
more
connected
to
Yang
and
solving
some
of
the
problems
and
hopefully
avoiding
some
of
that
hell
for
people
to
come
specifically
on
this
operation
of
thing.
N
One
of
the
things
Benoit
that
you
kind
of
brought
to
the
forefront
and
I
think
Ignace
to
your
point
about
operationalizing
Yang,
and
you
mentioned
the
product
of
the
IETF
shouldn't
just
be
the
RFC
number
and
Elliott
said.
Don't
just
get
your
RFC
number
and
go
it's
about.
How
do
we
move
faster
to
help
operators
adapt
or
to
help
the
operators
consume?
The
products
that
we're
putting
out?
K
So
you
know
this
job,
but
for
the
rest
of
the
audience,
what
we've
been
trying
to
do
to
address
Ignis
point
is
that
you
know,
even
if
I
mentioned
me
times
yang
in
in
my
talk,
alright,
maybe
too
many
times
in
the
end,
we
want
to
have
an
users,
not
caring
about
yang.
So
what
you've
been
doing
with
the
catalog
is
that
you
just
select
something
you
want
to
manage
a
vinum.
For
example,
you
select
it.
You
found
the
right
yang
modules
and
they're
plenty
of
ones.
K
Then
you
look
at
the
house
metric
there,
which
one
is
the
relevant
one:
there's
a
maturity
based
on
validation
based
on
code
whatever,
and
there
you
just
click,
and
then
you
just
produce
a
Python
script
that
will
go
and
configure
real
villains.
This
is
what
we
need
to
do
more
and
then
the
second
thing
I
want
to
add.
Is
you
know
we
did
that
during
ITF
hackathons
for
many
meetings.
K
Now
we
want
to
move
this
in
the
next
level
and
we're
trying
to
get
like
I
sock
money
to
have
one
person
assign
full-time
for
a
year
on
this
right,
because
if
you
want
to
have
this
like
an
introduction
right
really
for
operators
to
offer
them
a
service,
we
need
to
have
someone
like
dedicated
and
I'm
still
hopeful.
That
is
going
to
happen.
So
whenever
we
have
that,
then
we
have
the
full
story
and
we
have
like
all
the
revision
of
young
modules,
but
all
the
metadata
we've
got
the
usability.
D
D
D
D
So,
first
off
we
have
some
final
up:
Syria
administrivia.
We
currently
have
three
chairs
for
ops,
AWG
and
ER.
One
of
them
is
Ignace,
so
the
plan
is
Ignace
will
be
stepping
down
as
ops
AWG
chair
and
he
will
end
up
becoming
the
responsible
ad
for
for
UPS
AWG
instead
of
me,
so
you
know
thank
you
for
your
service
as
ops,
ADG,
chair
and
sucker
for
becoming
becoming
ad.
So.
F
Thanks
a
lot
for
that
and
this
this
will
happen
sometime
during
this
week
and
this
interesting
use
case
for
a
data
tracker
that
ones
formerly
80s,
which
ever
happens
then
we'll
try
to
do
the
chest
which
over
and
the
person
switching
is
the
same.
So
we'll
see
what
goes
with
the
data
track.
It's
a
test
case
for
that,
so
then
op
cwg
will
move
to
be
a
and
I
will
become
the
responsible
area
director
for
the
ops,
AWG,
the
rest.
D
F
N
N
N
J
Want
to
talk
about
after
last
meeting
the
service
model
explained.
The
document
has
been
published
as
RFC
a3
on
I.
Now
we
have
five
active
working
group
document.
Firstly,
the
Capricorn
external
document
has
finished
or
the
working
group
procedure,
and
now
is
he
waiting
in
the
RFC
queue
and
we
also
finished
the
first
or
last
core
for
the
I
fix
BGP
community
document.
The
major
problem
is
about
the
use
case
and
and
the
motivation
later
the
also
well
reports,
the
latest,
the
revision.
J
N
So
the
first
would
mud.
We're
gonna,
hear
an
update
from
Elliott
on
that
I
believe
that
the
there's
a
few
changes
that
might
need
to
be
made
la
will
touch
on
them
and
it
might
have
gotten
pushed
back
a
little
bit
from
a
telecheck
standpoint
due
to
some
other
cueing
yeah,
just
scheduling
in
terms
of
the
NAT
draft.
It
is
gone
through
its
Shepard
review
by
me.
It
has
been
submitted
for
publication,
as
shown
but
again
hasn't
hasn't,
had
a
chance
to
be
fully
reviewed
by
the
isg
again.
Do
this
scheduling
and.
J
O
N
O
O
For
text
that
you're
kind
of
in
a
state
there's
still
no
acknowledgement
that
a
good
section
of
the
security
considerations
text
was
written
by
me.
If
you
want
updates,
if
you
want
engage
I,
would
be
happy
that
/
editorship
and
do
whatever
the
working
group
wants
to
get
this
done,
but
waiting
months
and
months
between
the
reviews.
Sorry,
between
the
releases
dropping
a
new
leader
that
running
away.
It's
not
engagement,
hi.
O
F
Okay,
that
that
is
understood,
I
cannot
answer
for
our
other
office
I'm,
not
a
whether
any
of
them
is
present
in
this
meeting,
and
this
document
is
not
being
presented.
The
only
thing
that
I
am
stating
as
the
fact
that
I
did
lies
with
them
at
a
time
frame
or
0-7,
and
since
then
there
were
no
major
changes
from
this
particular
topic.
O
Were
to
address
my
reviews,
which
I
do
appreciate,
but
some
parts
of
my
reviews
were
no
I,
responded
to
and
did
not
result
in
changes
in
the
document.
So
I
mean
anyone
can
write
a
document
and
throw
it
over
the
wall.
Occasionally.
The
point
is
to
get
consensus
whether
you
want
to
see
that
happening.
So
if
the
author's
repeatedly
for
the
past
40
years
do
not
engage
and
do
not
move
towards
consensus,
that
I
have
to
question
why
this
document
is
here
or
why
the
working
group
cannot
put
someone
else
in
who
will.
L
O
O
F
F
L
Okay,
Eliot
here,
I
I
sympathize
with
Alan.
If
the
doctor
is
not
moving
at
a
reasonable
pace,
then
it's
worth
the
chairs
getting
involved
to
start
to
figure
out
how
to
get
it
to
move
I.
Think
that's
a
perfectly
reasonable
request.
I,
don't
think
you
can
solve
it
here.
I
just
think
it's
a
work
with
worthy
to
mention
it
and
and
then
let's
move
on
it's
my
suggestion,
yeah!
No,
we
failed.
Is
it
summery.
I
N
N
L
Hello,
its
Elliott
again
alright.
So
this
is
a
brief
status
on
mud,
it's
where
we
are
and
where
we
think
we're
going
to
go
for
next
steps.
So
mud
was
a
its
manufacturer
usage
descriptions.
Basic
idea
is
to
miss
for
the
manufacturer
to
be
able
to
communicate
various
aspects
of
a
device
to
the
local
deployment,
particularly
the
network
side,
but
it
doesn't
necessarily
have
to
be
limited
to
that
of
what
the
device
is.
How
it's
supposed
to
behave
next
slide
please.
So
this
document
is
passed
last
call
several
times.
L
So
that
means
that
some
of
the
examples
in
the
mud
document
will
probably
change
as
they
finally
wrap
up.
We
can
handle
that
in
all
48,
as
as
we're
moving
on
I
discussed
with
Warren
there's
a
one
error
in
the
current
draft,
at
least,
which
is
that
system
info
is
currently
listed
as
a
URL.
That's
a
holdover!
We
just
got
that
in
this
working
group.
L
It
should
move
from
URL
to
utf-8
the
reasoning,
the
reasoning
being
that
the
applications
people
in
the
reviews
basically
said
you
really
don't
want
to
do
a
lot
of
HTML
processing
too
many
bugs,
and
that
too
many
opportunities
for
vulnerabilities.
So
don't
do
that,
especially
on
your
first
time
around,
and
so
the
other
thing
they
said
is
and
stop
messing
around
with
the
URL.
That's
what
they
basically
told
me.
You
have
to
not
constrain
it,
and
so
we
had
a
fairly
lengthy
negotiation
about
that
basic
issue.
Is
that
be
CP?
L
190
says
you
can't
impose
strictures
on
the
form
of
the
URL.
On
the
other
hand,
it
was
written
at
a
time
when
you
phasic
aliy
had
a
web
browser
and
a
web
server,
and
you
don't
want
things
in
the
middle
monkeying
with
it.
We
don't
have
a
web
browser
on
one
end
of
this
discussion.
I'm
going
into
this
connection,
we
have
something
putting
out
DHCP
or
lldp
or
being
pulled
out
from
a
or
information
being
pulled
out
from
a
cert,
so
our
model
is
a
little
different
than
they
envisioned.
L
In
any
event,
we've
come
up
with
some
text,
which
is
advisory,
which
says,
look
just
leave
the
query
element
alone
or
we
advise
you
to
leave
the
query
element
alone,
because
we
might
be
standardizing
that
in
the
future-
and
we
haven't
decided
we're
going
to
have
that
conversation,
but
we're
not
going
to
have
the
conversation
in
last
call
of
a
document.
We're
just
gonna
we're
gonna
say:
well,
that's
future
work
and
let's
move
on-
and
this
is
where
we've
left
things
with
them,
and
the
applications
area
director
in
particular
Adam.
L
That
seems
pretty
happy
with
that
approach
and
then
he
wants
to
actually
have
the
conversation
which
is
really
good,
because
we
should
the
tell
a
chat
chief
for
that
is
April
19th.
My
one
regret
is
that
benoit
won't
be
able
to
yay
or
nay
this,
but
I
was
hoping
that
things
would
finish,
so
you
could
do
that
then,
while,
but
hopefully,
it'll
happen
soon
enough
and
as
Lauren
told
me,
the
stack
of
documents
in
front
of
us
is
quite
substantial,
which
is
why
the
date
is
what
it
is
all
right.
Next
slide,
please.
L
So
as
a
reminder,
you
know
what
that
what
all
this
is
about.
You
know
the
the
thing
that
mud
started
to
tackle
was
that
middle
green
one,
which
is
how
do
I
protect
it
on
my
network
and
also
the
only
one
below
it
which
is.
Is
it
doing
what
it
should
be
doing,
and
so
we've
been
focusing
on
that
and
so
for
the
other
stuff
like
what
is
this
thing?
L
We're
talking
about
using
mechanisms
like
E
and
a
8o,
2.1,
AR
and
other
things
to
identify
the
device
unit
to
the
deployment
and
then
we're
looking
at?
How
to
broaden
all
of
these
answers
for
various
different
forms
of
technology
like
802
11,
like
3G,
4G,
5g
and
across
different
markets
or
different
segments
of
markets?
Next
slide,
please
oops
just
a
little
bit
back.
L
If
you
would
there,
you
go
okay,
so
one
of
the
things
we
didn't
touch
with
a
ten-foot
pole
was
in
the
first
round
was
how
to
handle
sort
of
bandwidth
expectations
of
a
device.
One
of
the
reasons
is
that
I
still
have
scars
personally
from
dealing
with
QoS
in
the
early
90s
between
the
early
90s
and
late
90s,
and
wasn't
quite
ready
to
start
with
out
when
we
had
some
really
low
hanging
fruit
just
on
access.
L
But
now
we
really
have
this
question,
so
you
installed
a
you
know
device
and
you
don't
really
know
how
much
bandwidth
it's
going
to
take
out
of
your
network,
nor
what
it's
designed
to
take
out
of
your
network
and
maybe
it's
a
fire.
It
may
be
sort
of
like
a
little
temperature
sensor
to
detect
fires.
Maybe
it's
going
to
do
you
know
it's
going
to
need
like
yeah,
you
know
a
packet
every
five
minutes,
maybe
a
packet.
Every
minute,
depending
on
how
it's
designed
and
no
more
and
all
of
a
sudden,
it
starts
spewing.
L
Well,
it
could
be
that
a
there's,
a
fire
and
it's
saying,
hey,
there's
a
fire
or
it
could
be
that
it
has
a
noisy,
transceiver
and
so
something's
gone
wrong
with
the
device.
But
you
don't
know
because
you
don't
know
how
it's
been
designed.
That's
the
question
in
the
question
before
us
is:
can
we
provide
a
description,
or
can
the
manufacturer
provide
your
description?
L
Oh
that
sort
of
behavior
both
when
it's
a
nominal
state
and
maybe
when
it's
an
exceptional
state
and
such
that
the
deployment
can
have
understanding
of
how
the
device
will
behave
in
those
two
states
from
the
bandwidth
utilization
standpoint,
and
so
this
is
sort
of
research
II
in
that
we're
not
sure
that
the
manufacturers
are
actually
going
to
be
able
to
do
this.
But
it's
been
put
that
we
should
discuss
this
and
so
I'm
raising
it
with
you,
as
I
mean
as
a
point
for
future
work.
L
So
the
way
that
we're
thinking
about
this
is
that
you
know.
When
we
talk
about
bandwidth
utilization,
it
can
go
in
two
directions:
conveniently
the
mud
model
thinks
in
both
to
the
device
and
from
device
already
and
sort
of
thinking
about
extending
it,
extending
the
two
device
and
from
device
containers
such
that
you
could
add
some
sort
of
description
about
this,
and
the
idea
also
is
that
you
could
use
this
for
other
purposes
like,
for
instance,
provisioning
purposes.
L
So
if
you
have
a
bunch
of
devices
that
are
say
cameras,
it
might
all
be
chattering
at
the
same
time
at
say:
HD
speeds.
You
could
have
some
notion
as
to
add
up
the
amount
of
bandwidth
that
you're
that
you
might
need
in
those
environments
for
provisioning
purposes
over
time
now.
What
did
this
is
not
talking
about
is
how
to
duplicate
or
how
to
create
QoS
in
the
network.
That's
already
been
done
not
going
to
do
it
again.
Have
the
scarves
next
slide,
please,
okay,
so
I've
covered
a
bit
of
this
already.
L
So
it's
this
is
sort
of
again
it's
a
bit
research
heat
to
figure
out
exactly
the
right
elements
to
describe
utilization,
but
it's
not
that
researchy,
because
we've
done
this
before
you
know
their
context,
whether
it
you
know
it's
a
net
flow
where
we've
looked
at,
how
net
flow
or
how
ITV
III
p6
has
handled
flow
information,
we
can
probably
learn
a
lot
from
that
all
right.
So
next
slide,
please.
L
So
the
other
problem
that
we're
working
on,
which
is
sort
of
separate
from
is
more
of
an
onboarding
problem
and
this
I'm
going
to
talk
a
little
bit
about
an
emu
later
today
in
more
depth.
So
this
is
sort
of
a
little
teaser
for
if
you
don't
normally
attend
EMU,
and
why
would
you
because
this
is
op,
sorry
working?
It's
sort
of
a
security
thing
question
is:
how
do
we
we
now
gotten
to
the
point
where
we
can
describe
a
profile
of
a
device?
L
L
This
is
some
of
the
slides
didn't
come
out
quite
right,
okay,
so
the
the
problem,
though,
with
Wi-Fi
in
particular
with
trusted
introduction,
is
that
you
want
to
join
the
network.
Even
if
you
know
the
network
right
and
so
the
way
that
the
anima
brewski
flow
works.
Is
you
basically
have
some
restful
calls
and
you
do
a
little
restful
dance
with
something
called
a
registrar.
But
how
do
you
do
the
rest
will
dance
if
you
don't,
if
you
know,
if
you're
not
yet
authorized
to
use
the
network,
as
is
required
in
a
Wi-Fi
environment?
L
Okay,
that's
a
chicken-and-egg
problem
that
we
have
to
go
sort
so
we're
looking
at
several
different
ways
to
sort
that,
that
is
to
say,
we'd
like
to
use
this
animal
flow,
and
we
want
to
also,
but
we
don't
have
an
IP
address.
Well,
that's
sort
of
a
fish
right
in
order
to
do
that
and
there's
this
whole
thing
called
teep,
which
is
relatively
new,
which
is
new,
eat
method,
which
seems,
roughly
speaking,
to
be
what
we
want,
but
there's
not
a
lot
of
deployment
there,
which
makes
us
a
little
nervous.
L
So
there's
a
new
draft
that
own
feel
and
I
and
Michael
Richardson
wrote
on
this
to
go,
look
at
these
different
models
and
we
want
to
actually
try
and
take
a
swing
at
this
all
right.
So
next
slide
coming
back
to
mod.
We
have
some
open
issues.
As
I
mentioned
earlier,
the
apps
area
people
had
some
be
CP
190
issues
that
we
wanted
to
discuss,
and
why
would
we
care
about
URL
composition?
L
Well
right
now,
if
you
transmit
a
mod
URL,
if
you,
if
a
device,
outputs,
a
mud,
URL
say
in
a
certificate,
that's
the
manufacturer,
asserting
what
the
device
profile
is,
but
a
device
can't
change
that
URL
say
if
it
does
a
software
upgrade,
and
so
you
might
want
some
of
that
posture
information.
Well,
conveniently
NEA
has
done
a
lot
of
work
on
posture
information,
so
maybe
we
want
to
communicate
some
of
that
back
to
the
manufacturer,
so
say
a
device
is
running
version,
two
of
a
particular
piece
of
software.
L
In
version
two
has
more
capabilities,
then
perhaps
what
you'd
like
to
do
is
communicate
that
to
the
manufacturer,
so
it
can
provide
a
more
tailored
might
URL.
That's
just
one
example
of
how
you
might
want
to
add
stuff
into
the
URL
say
at
the
mud
controller
level,
and
we
didn't
touch
that
initially
in
them
in
this
document,
but
we're
now
thinking
about
it
and
we're
trying
thinking
about.
What's
the
right
way
to
go
about
to
go
forward,
one
way
is
to
append
stuff
into
the
URL.
L
Another
is,
for
instance,
to
create
an
HTTP
header
and
stick
that
stuff
in
there
and
pass
that
to
the
mud
file
server,
which
is
basically
an
HTTP
server.
We
didn't
really
want
to
do
the
latter
early
on,
and
the
reason
is
that
we
thought
the
simpler,
the
HD
that
the
the
web
server
implementation,
the
easier
it
will
be
for
manufacturers
to
implement.
So
this
is
one
issue
that
we're
thinking
about
as
well.
The
next
thing
that's
left
over
is
sort
of
a
lifecycle
issue.
L
Next
slide,
please,
and
so
suppose,
you've
got
a
device
that
you
know
you
bought
in,
say,
2018,
and
then
you
pulled
out
of
the
drawer
in
2050
and
wanted
it
to
work.
It
just
happens
to
be
an
old
light
bulb
now.
This
may
sound,
crazy
and
I've
chosen.
The
the
time
frames
to
be
a
little
bit
extreme,
but
it
could
be
instead
of
2050.
You
could
say:
well,
we
pulled
it
out
of
the
box
in
2025
or
something
like
that.
You
still
want
it
to
work
and
you
think
that's
crazy.
Consider
this
example.
L
The
Formula
One
team,
McLaren,
all
their
control
functionality
for
their
racing
car
is
on
like
Windows
95
and
what
they
did
is
they
bought
a
stack
of
PCs,
so
they'd
never
have
to
upgrade
the
software
in
the
car
while
they're
running
out
of
PCs
now
well.
This
is
sort
of
the
same
problem,
which
is
things
do
tend
to
there's
a
lot
of
stuff
that
tends
not
to
change
and
companies
do
go
away
and
with
them
go
their
names.
L
So
I
was
talking
to
Hank
about
this
at
lunch
and
he
said
oh
you're,
just
going
to
run
your
internet
simulator
in
2050.
You
need
to
a
query
for
this
information.
It's
like
yeah,
that's
a
way
to
solve
them.
This
came
up
apparently
at
the
S
Shack
meeting
it
I.
Can
violate
because
they're
thinking
about
long
long
lived
names
as
well.
Now
we,
you
know
people
keep
saying
what
happens.
L
What
are
you
doing
these
circumstances
and
my
first
answer,
you
know
my
first
order
answer
was
you're
screwed
the
names
gone
and
that's
that,
but
we
don't
really
want
that
to
be
the
real
answer,
so
we
actually
want
to
put
a
little
thought
into
name
lifetimes
and
mud
URLs.
So
these
are
the
things
that
we're
thinking
about
working
on.
I.
Think
that's!
L
My
last
aside:
if
memory
serves
and
hank
himself
is
thinking
about
mud,
URL
composition,
and
how
do
you
how
to
leverage
that
in
her
that
that
I,
that
classifier
for
other
uses
and
he's
going
so
far
as
to
say
you
know
over
time,
we
don't
really
want
to
use
yang
for
these
things.
We
want
to
use
something
else.
O
O
O
L
Alan,
you
know
one
of
the
the
fundamental
issue.
We
know
we
have
a
problem
with
you
know
with
with
these
things
up
there
or
any
particular
device
that
doesn't
have
a
direct
user
interface
and
wants
to
use
Wi-Fi
they
have
that
they
have
to
go
through
some
sort
of
dance
to
get
connected,
whether
it's
or
whether
it's
something
else
I
personally
think
using
something
like
eat
is
a
useful
mechanism,
because
it's
there
in
a
tremendous
number
of
deployments
already
et.
Isn't
we're
not
wedded
at
this
point?
L
I'm,
not
wedded
nor
any
of
the
co-authors
who
wrote
the
draft
I
reference
wedded
to
any
particular
mechanism.
We
are,
however,
wedded
to
solving
the
problem,
and
so
we're
looking
for
collaborators
on
that
point,
and
so,
if
you
haven't
read
that
route,
please
take
a
few
moments
and
read
Owen
fields.
Draft
on
this
Owen
is
around
I.
Don't
think
I
see
him
in
the
room.
Oh
there
he
is
okay,
and
so
any
Olins
got
a
problem.
He
can
talk
about
it.
L
P
P
P
P
Based
on
the
network
practice
to
analyze
the
traffic
to
do
traffic
engineering
or
to
the
deployments
quality
of
services,
we
want
to
know
the
traffic
the
network
traffic
generated
from
our
testing
to
some
canceled
customers,
services
or
the
geographical
regions
based
on
the
network
operators.
Bennion
PTP
communing
here
attributes
are
used
to
represent
such
country
information,
so
we
can
so
we
know
the
information
we
want
away.
P
P
We
do
not
define
any
new
PGP
community
attribute
in
this
document.
The
the
information
element
introduced
in
this
document
I
ought
to,
if
thought
the
already
defined
bgp
communities
such
as
the
standard,
particularly
the
candy
at
community
and
the
large
community,
and
this
document
is
not
used
to
replace
the
HP
monitoring
Patoka
either
for
the
effects
collectors
are
not
running
BGP
and
BMP
protocols.
P
By
supporting
the
information
elements
in
the
Austrians
a
document,
they
can
analyze
the
network
traffic
in
each
big
community
when
you
are
ready
directly,
because
you
know
both
Beach
P
and
P
NP
are
very
heavy
running.
Those
can
do
protocol
and
correlate
him.
The
traffic
flow
information
with
HP
information
are
not
trivial
for
the
effects
platters.
P
K
K
Liana
and
request
it
directly,
it
was
better
to
document
it
on
how
to
use
information
elements.
Okay,
this
is
good
now
when
I
just
checked
it
now
there
is
one
small
mistake
in
there
you
say
that
you
update
the
RFC
1712,
which
is
the
information
list
of
information
elements
like
effects.
Actually
you
don't
you
don't
need
to
update
that
RFC
you
just
using
the
ionic
procedure
in
that
RFC,
so
the
updates
in
the
header
of
that
of
your
draft
doesn't
need
to
have
you
want
to
remove
it.
You
don't
need
update
7012
that
make
sense.
K
N
K
Q
So
the
Greek
rules
of
this
world
telemetry
simply
means
remote
merriment.
So
in
this
sense
we
believe
telemetry
is
actually
about
Network
visibility.
So
any
technology
that
help
network
took
in
had
better
visibility
by
collecting
data
from
network
and
do
an
analysis
and
a
moment
nate
is
actually
qualified
as
a
telemetry.
So
in
this
sense
all
the
OEM,
our
techniques
arm
or
motor
coast
published
in
the
ITF,
is
actually
can
be
considered
telemetry.
Q
Q
So
you
can
see
in
this
a
network
architecture,
natural
reason,
visibility
become
more
and
more
important.
After
all,
if
you
know
you
don't
know,
what's
happening
in
network
in
real
time,
no
effective
network
control
and
the
operations
can
be
applied,
but
now
I
think
people
just
don't
put
enough
attention
to
this
technology,
and
you
know
we
believe
that
the
telemetry
should
be
promoted
as
a
first
class
citizen
in
the
network
technology
and
the
protocols.
Also,
if
we
look
at
current
status
of
such
technologies,
we
see
it's
pretty
much
a
frakkin
mint
fragmented.
Q
We
believe
we
need
to
unify
and
consolidate
and
integrate
the
existing
solutions
and
also
guides
the
future
work
in
a
unified
framework
to
help
such
technology.
Three
more.
Q
Also,
this
om
mechanics
are
scattered
throughout
ITF,
our
working
groups
and
our
lipid
are
organized
and
there
are
many
piecemeal
or
tico
solutions.
It's
a
very
hard
for
users
to
compose
them
into
a
complete
cohesive
solution
and
also
since
people
don't
work
under
the
same
framework,
there
are
occasionally
repetitive
and
redundant.
Work
is
happening,
and
this
also
lack
offer
collaboration
and
the
consolidation
between
them,
and
in
many
times
you
know,
om
is
not
considered.
You
know
it's
just
considered
a
afterthought
patches
to
the
existing
solution.
Q
Also,
it's
a
work
on
a
case
by
case
cases
and
there's
a
lack
of
a
holistic
and
systemic
view.
Therefore,
we
believe
a
framework
is
actually
needed
to
normalize
concepts,
terms
and
technology
standard
to
help
that
technology
and
standard
development
with
the
IETF
so
what's
needed
in
new
telemetry,
since
the
telemetry
will
be
data
where
we
consumed
by
machine
are
more
than
by
human,
it
means
the
data
quantity
is
large
and
it
happens
in
real
time.
The
the
network
need
to
continuous,
monitor
the
network
in
a
more
dynamic
and
interactive
way.
Q
Q
We
need
to
customize
what
data
to
collect,
which
means
we
need
to
rely
on
to
rely
on
the
network
to
pre-process
some
of
data
as
guided
by
the
application,
and
another
important
thing
to
think
about
is
that
the
telemetry
should
note
interfere
with
device
may
function,
which
is
a
folding
packet
fast.
So,
for
example,
you
can
note
by
a
monitoring
network
you
reduce
for
any
performance,
that's
acceptable.
Q
There
are
many
applications
existing
use
cases.
The
first
is
about
intent.
You
know
verification
or
enforcement.
The
intend
energy
may
apply
different
policies
or
have
different
service
layer,
layer
agreements
with
users
and
services,
but
the
telemetry
is
used
to
ensures
that
actually
meets
the
requirement.
Q
The
last
very
important
application
is,
of
course,
the
network
security,
for
example,
the
intrusion,
detection
and
prevention,
and
also
some
other
malicious
attacks,
can
be
attacked
and
identified
through
the
telemetry
technology.
So
all
these
applications
require
some
new
characteristics.
The
first
noticeable
wines
are,
the
push
based
technology
will
replace
the
poor
based
technology
such
as
was
used
in
SA
mg
and
the
since
the
data
quantity
is
a
huge.
It
requires
very
efficient
data
encoding
and
also
the
date
need
to
be
sent
through
the
collector
in
a
streaming
fashion.
Q
For
the
for
better
machine
consumption
of
the
data,
other
model
is
needed
and
also
all
as
I
said,
so.
The
data
crashing
need
to
support,
also
the
in
band
data
and
since
a
data
plane
or
device
and
becoming
more
programmable,
now
is
feasible
to
support
the
customer
and
on
demand
data,
which
means
the
the
controller
can
define
or
specify
what
data
need
to
be
collected
and
using
some
programming
or
configuration
waste
to
would
to
download
that
data
request
to
the
tip
lane
and
just
gets
the
exactly
what
data
they
want.
Q
Q
Therefore,
we
can
see
based
on
there's
different
planes
in
the
network.
Clearly,
there
is
better
to
a
partition
that
lamp
entry,
also
in
into
three
different
planes,
namely,
is
a
data
plane
telemetry
now
manager,
management,
plane,
telemetry
and
control,
plane,
telemetry
right,
but
between
this
different
planes
you
know,
they're
also,
some
interactions
between
them,
for
example,
the
many
playing
telemetry
can
also
collect
data
from
the
control
plane
and
the
date
of
name
and
in
each
plane.
We
can
further
partitions
our
telemetry
into
five
unique
components.
The
first
one
is
the
data
source.
Q
It
tells
ok
where
data
should
be
is
available,
is
accessible
and
the
second
component
components
is
a
data
subscription.
It
cares
about
tell
the
application,
you
know
how
you
can
subscribe,
what
protocol
or
what's
interface,
you
use
to
subscribe
data,
and
the
third
component
is
the
data
generation.
It's
about
how
the
data,
because
the
application
may
ask
some
custom
data
or
the
data
if
we
pre
process
in
data
plane
or
encoded
or
filtered
all
these
affections
I
belong
to
the
data
generation
and
the
preparation
and
another
components.
Q
Important
components
is
a
data
export
which
cares
about
how
you
deliver
the
data
to
the
application
who
consume
consume
the
data
and
the
last.
The
top
components
is
a
data
analysis
which
is
a
actual
applications
who
are
consume.
The
data
extracted
from
the
network
device
so
pace
on
this
a
partition.
We
come
up
with
this
two-dimensional
matrix
and
we
already
map
many
different
technologies
in
this
figure.
Most
of
them
are
from
IETF
existing
work.
Q
There
are
either
already
standards
or
some
recent
proposals,
but
only
under
the
data
analytics
part
you
can
see
most
of
them
I
still
open-source
project
or
some
open
source
tools,
but
later
that
might
be
also
some
standard
requirement
in
that
in
that
area,
I
don't
have
time
to
go
through
all
this
each
piece
of
technology.
If
you
are
interested,
you
can
read
our
draft
to
see
how
and
why
this
fits
fit
into
this
picture.
Q
So
from
this
picture
we
can
see
there
are
already
a
lot
of
existing
works,
but
they
are
might
come
from
very
different
working
groups,
a
different
area.
We
seem
to
be
the
better
if
we
can
map
them.
Clearly,
it
can
also
guide
us
in
the
future
how
we
are
max
maps,
the
new
work
into
this
picture
and
for
the
system
designer,
and
it
also
can
help
them
to
to
figure
out.
What's
a
best
suite
of
technologies,
you
can
collect
to
form
a
complete
solution
from
this
figure.
So
therefore,
I
think
is
a
very
useful.
Q
Rather,
we
should
consolidate
all
the
telemetry
work
and
provide
the
unified
interface
to
Action
Network
architecture,
and
we
also
want
to
ensure
that
to
make
ietf
still
the
leading
standard
organization
in
this
area,
and
in
this
document
we
want
to
formalize
other
telemetry
related
terms
and
the
clarify
the
technology
clarifications
in
ATF,
which
can
consolidate
the
existing
work
and
also
help
us
to
get
the
future
work.
Of
course,
this
is
just
a
very
early
step.
We
call
for
more
helps
and
collaborations
from
other
operators
and
the
vendors
to
finish
this
work.
F
Get
the
feeling
that
you
are
trying
to
boil
not
one
ocean
but
multiple
of
them
at
the
same
time,
the
scope
of
this
work
is
not
that
it
is
huge,
it's
it's
more
than
huge,
but
at
the
same
time
you
see
that
majority
of
the
components
and
the
other
work
areas
is
already
being
covered,
and
that
was
a
idea
and
to
me
what
you're
describing
is
much
more
of
network
designer,
actually
product
design
question
than
a
protocol
engineering.
What
is
typically
done,
an
idea
and
the
goal
to
have
a
one
universe,
absolutely
universal
interface.
F
That
covers
absolutely
everything.
That's
directly
contradicted
to
how
the
net
from
operational
point
of
view
works,
there's
a
differentiation
between
different
operators
for
a
reason,
because
they
are
trying
to
build
the
different
products,
different
interconnection
products
when
activity
products,
therefore
trying
to
build
one
really
nice
all-encompassing.
F
F
Q
Q
But
here
I'm
talking
about
if
in
the
future
we
have
this
intelligent
network
automatic
network.
You
know
he
keeps
a
human
adopts,
a
control
loop.
Then
you
need
to
present.
It's
really
I
think
it's
a
required
to
present
a
unique,
uniform
interface
to
the
intent
engine.
Are
you
it's
better
to
avoid
a
lot
of
different
incompatible
interface
protocols
to
talk
to
the
controller,
so
that
I
think
the
motivation
for
from
this
a
big
picture
and
we
released
in
the
matrix
are
several.
Q
Technologies-
and
we
can
see
actually
the
key
components
here
is
a
you
know:
what's
needed
to
communicate
with
intend
engines
actually
just
a
data
subscription
and
the
data
export.
You
know,
I
think,
there's
a
good
chance.
We
can
come
up
with
one
unified
solution,
everybody
will
grieve
is
and
then
we
can
support
such
kind
of
a
network
architecture
so
also
I,
don't
think.
F
Q
R
Q
Q
Q
A
data
export
and
for
the
storage
is
actually
in
the
data
analytics.
You
you're,
you
have
two
ways:
either
you
directly
consume
the
data
in
the
stream
fashion,
or
the
data
should
be
first
put
into
some
kind
of
database
for
later
analysis.
So
in
my
understanding
that
should
be
also
covered
in
the
data
analysis,
components
and
last
one
about
the
optimization
I
think
you
know
optimization
campaign
happen
everywhere,
particularly
in
the
data
generation.
Okay,
that's
I
intend
to
do
some
data
preparation
as
there's
a
lot
of
optimization
happen
there.
Q
It's
like
the
data,
t-tube,
a
filtering
and
compression
encoding
and
also
the
August
optimization
algorithms
can
also
happen
in
the
data
analysis,
components,
so
yeah
III
think
all
of
this
should
be
covered
by
this
on.
Maybe
we
can
have
a
better
description
of
each
components,
but
I
think
you
know.
Every
key
components
happening
in
a
telemetry
system
is
already
covered
here.
S
Yeah
I
just
want
to
say
a
couple
things.
One
I
want
to
reiterate
the
fact
that
you
boiled
a
big,
it's
probably
too
big,
to
boil
what
you're
trying
to
do
question
about
the
transformation
in
those
elements,
yeah
that
can
be
part
of
the
data
and
that
analysis
components.
But
it's
a
big
component
right.
You
got
enrichment
and
everything
else
that
you
have
to
go
through
there
and
so
to
just
say:
I'm
gonna
have
a
miracle
cure
occurred
here.
Called
data
analysis
I
think
would
probably
do
a
disservice
to
the
industry.
S
I
did
see
that,
as
you
were
going
through
here,
that
you
said,
let's
keep
our
eye
on
the
intent
framework
and
it
looks
to
me
as
we
went
through
this,
that
you
lost
you
lost
your.
You
took
your
eye
off
the
intent
framework.
So
if
you
take
into
10
right-
and
you
realize
all
these
sources
that
goes
to
the
one
protocol
piece
you're
going
to
realize
real,
quick-
that
the
tank
gets
realized
in
many
many
different
ways
right
and
that
many
many
different
ways
are
gone-
have
different
sources
of
data.
S
That's
going
to
come
up
to
you
and
they're
going
to
come
up
to
you
different
ways.
So
there's
not
going
to
be
one
protocol
that
you're
going
to
be
able
to
capture
these
elements.
So
there
you
have
to
expect
that
you're
going
to
realize
that
intent
in
multiple
different
environments.
You've
got
the
three
different
control
for
this
air
that
you
know
are
there.
They
are
the
largest
pieces
of
it
and
in
those
elements
themselves
will
be
going
down
and
being
collected
through
different
protocols
and
different
mechanisms.
That's
just
going
to
be
a
fact
of
life.
S
The
question
is
how
you
correlate
that
back
into
an
intent,
I
think
now
that
probably
has
some
value
right
and
trying
to
figure
out
how
you
would
correlate
the
sources
themselves
into
an
intent
framework
right,
but
to
to
say
that
you
want
a
single
protocol
going
into
an
intent,
control
engine
night,
I.
Think
I.
Don't
think
that
that's
going
to
be
a
reality,
probably
before
I
die,
so
so.
Q
So
in
my
I
might
be
too
ambitious
to
try
to
unify
all
the
technologies,
but
here
the
main
intention,
I
believe,
is
try
to
you
know
organize
the
existing
work
to
have
a
career
understanding,
how
what's
the
scope
of
this
problem
and
how
we
can
partition
the
technology.
How
we
can
map
say
existing
technology
into
this
map.
If
we
all
agree
with
that,
then
later
even
we
develop
new
technologies.
We
know
where
is
fate
and
how
is
fit
into
this
at
this
picture.
So
if.
S
Ones
here
I
can
go
to
you
know,
maybe
number
of
other
organizations
and
they're
probably
got
their
other
horrified
that
they're
doing
to
collect
stuff.
So
I.
Just
don't
think
it's
probably
something
that
that
that
that's
ever
going
to
happen
in
a
lifetime
and
I
think
you
have
to
look
at
how
you
would
then
be
able
to
set
up
an
appropriate
framework
that
would
be
able
to
map
and
transform.
L
S
T
I
think
this
is
the
fact
user
accurate
deployment,
so
we're
seeing
that
user.
You
hear
that
we
mainly
data
related.
We
assemblies
the
some
elementary
work
related
with
the
data
plane,
some,
the
new
om
you
can
mechanism
reintroduced
and
we
also
wanted
to
item
if
I
have
water
should
be
cope
with.
So
this
is
our
the
first
a
purpose.
Second,
why
you
that
that
user,
this
relationship
element
we
in
the
user
is
a
new
error,
is
related
with
the
filter.
T
Data
will
be
collected,
a
fear
from
the
network
and
the
YouTube
will
support
in
enemies
the
network
or
network
immigrants,
so
that
user
was
is
mr.
I
know
what
we
should
be
done,
so
we
will
set
up
a
clear
you
walk
to
that
attend
our
work
in
the
to
be
done
in
the
IETF,
so
I
think
her.
That
is
our
major
purpose,
but
I
agree.
This
work
will
relate
it
with
the
many
many
work
in
the
in
the
IETF.
T
N
N
Don't
think
we
should
be
that
the
one
true
gatekeeper
of
of
of
telemetry
so
focus
on
the
intent,
and
maybe
there
is
a
way
to
refine
or
sharpen
what
you're
trying
to
do
with
this
draft
so
that
it
does
fit
a
gap
that
you
perceive
or
that's
more.
Actually,
that's
real
with
what
else
is
already
going
on
and
work
that's
already
in
flight,
in
in
ops
and
in
other
areas.
J
Hello,
everyone,
my
name,
is
shir,
come
form
of
Italian
Telecom.
It's
my
pleasure
to
give
a
presentation
about
Kasim
cadre
to
the
address
space
management,
as
we
all
know
that
address
space
management
is
integral
part
of
any
network
management
solutions.
The
network
may
be
based
on
some
Lexy
ones,
or
some
new
kind
of
networks
such
as
such
as
cloud-based
network.
So
here
I
want
to
give
some
two
cases.
The
first
one
is
about
operator
network
Natsuki
operating
the
work
so
operator
need
to
manage
the
address
space.
J
The
second
use
case
is
for
and
prior
users,
some
and
prior
user
may
use
tools
such
as
FM
to
manage
the
address
with
sausage,
often
used
often
with
some
proprietary
database
in
the
universe.
So
there
really
need
to
develop
a
general
architecture
for
the
address
based
measurement
too
many
use
cases
to
you
know
either
whether
a
killer
use
cases,
so
the
Scopes
is
draft
in
this
traffic
chasm
is
the
general
and
synchronized
architecture
for
automatic
address
based
management.
It
is
intended
to
be
used
a
wide
array
of
use
cases.
J
Hopefully
it
can
help
to
reduce
the
workload
of
manual
combination,
which
is
very
popular
in
currently
Network,
and
also,
we
hope,
to
improve.
Address
resource
usage,
improve
the
efficiency
in
the
future.
So
this
draft
can
also
be
a
basic
document
for
us
works
such
as
scene
of
his
modeling
and
workflow
design.
J
The
use
cases
of
use
cases
of
chasm
which
make
our
automatic
address
allocation
and
release
every
applications
work
based
on
the
actual
usage
and
at
the
import
from
input
from
user
intent
in
some
for
some
service.
So
all
the
indicators
we
know
has
been
discussed
in
the
ITF
laminates
in
each
cargo,
such
as
address
configuration
for
PNG,
the
virtual
has
been
G's
transition
activity,
trusted
devices
dressed
configuration
or
at
hand.
J
J
J
For
the
the
coordinator
is
synchronized
functioning
and
each
in
which
many
used
to
maintain
overall
address
resources
and
processing
request
from
Lord
Leo
devices,
you
can
post
the
three
components,
such
as
address
poor
management,
address
management
and
address
database.
So
the
subtle
ear
is
a
device
layer.
The
device
agent
in
a
device
will,
we
are
processing
we
are
distributes
address
from
which
is
received
from
the
coordinator,
configuring,
the
device,
the
the
type
of
ative
that
have
a
device
may
be
various
or
may
be
virtual
of
physical.
J
J
So
when
we
address
block
is
not
used
anymore,
it
will
be
released
at
the
retainer
to
this
2000
kilometer,
as
well
as
who
so
to
improve,
address
usage
here,
will
give
some
general
features
of
chasm.
It
is.
It
is
designed
to
be
a
single
solution
for
y,
the
Raju
user
cases,
such
as
a
network
device
and
a
secure
device
server
in
the
new
points
of
this
call,
virtual
of
cost.
This
solution
should
have
meat.
Food
me
to
the
address
should
be
to
miss
the
wide
variety
of
address.
J
Tab
such
as
private
public
IP,
address
ipv6
address
and
not
cause
of
your
IP
address.
The
second
is
synchronized
a
dynamic
combination
model.
So
here
the
coordinator
can
mix
the
TCD
IP
address,
based
on
the
available
IP
address
resources
and
as
a
user
you
put
the
importer
from
from
the
devices
another
that's
one
is
that
it
is
open
until
you'd
be
in
each
greater
ways
as
a
management
service
such
as
legacy
it
radius
and
DHCP
server,
and
some
new
ones
such
as
OpenStack
and
SD
in
networks.
J
J
Actually,
we
have
implemented
as
a
field
of
trails
of
synchronized
address
management.
For
most
of
my
year
on
following
the
chasm
model,
we
dealer
develop
a
synchronized
address
management
system
and
the
deploy
eight
in
our
product
network
for
vendors
John
is
for
the
trail
and
the
the
equipment
include
a
virtualized,
PNG
and
physical
being
jeez.
So
we
system
we
can
manage
it.
J
We
can
coordinate
and
manage
the
address
centrally
dynamically
so
about
the
next
step,
and
the
current
document
will
be
further
refined
based
on
the
comments,
and
we
are
also
considered
to
Tozer
due
to
the
interface
deflation
in
other
new
drafts.
Any
confusions
are
welcome
and
I
hope
that
you
guys
can
join
us
work.
If
you
have
interest
to
this,
and
also,
and
also
don't
to
know
whether
it
can
be
adopted
as
a
working
item.
N
I've
got
before
we
open
it
up
for
comments.
You
had
a
ball
while
back
under
the
ietf
meeting
number
98,
ACOG,
okay
and
I.
Looked
at
the
mailing
list
recently
and
and
kind
of
conversation
died
off
there.
So
I'm
curious
what
what's
bringing
the
work
forward
now?
What
has
changed
since
the
Boff?
What
have
you
learned
out
of
that?
That
directly
influences
this
work.
J
J
N
So
John
Florrick
is
a
contributor.
I've
read
the
draft.
It
does
look
like
two
drafts
that
have
been
fused
together.
Unix
terminology
you
reference
drafts
that
have
been
expired.
It
was
really
confusing
to
read.
I'll,
be
honest
with
you,
because
you
mentioned
chasm
in
the
second
part
of
the
draft,
but
in
the
first
part
of
the
draft
you
have
different
either
acronyms
or
you
refer
to
the
same
text
in
different
ways.
So
it
was
a
little
bit
confusing
to
read.
N
J
F
So
one
comment
on
this
topic
while
ago
at
Nanak,
I
had
a
discussion
with
Enterprise
operators
and
while
the
topic
was
different,
but
it
naturally
came
about
address
management
and
when
I
told
that
at
some
point
of
time
in
90f
there
was
a
document
trying
to
address
that
there
was
a
big
interest
from
that
group.
I
approached
them
again
asking
for
a
review
of
your
document.
You
probably
haven't
received
that
because
I
haven't
seen
anything
but
one
suggestion
on
open
network
users.
F
Group
is
an
entity
which
covers
many
of
a
special
enterprise
users
and
enterprise
users
in
the
domain
of
containers,
virtualization
and
then
similar
type
of
things.
They
do
have
certain
problems
with
identifier
management.
Not
only
address
management,
but
identifier
management
in
general.
Not
only
IP
addresses,
but
that
might
be
VLAN
numbers
might
might
be.
A
MAC
addresses
might
be
other
things.
N
T
M
Hello
good
afternoon,
everyone,
my
name,
is
Hugh.
The
top
guy
I
want
to
introduce
it's
about
a
new
virtual
edition
overlay
resource
model.
This
is
actually
R
is
also
facing
model,
so
why
we
propose
each
other
actually,
as
we
know,
actually
ITL
proposed
up
quite
a
lot
of
young
beta,
moto
mozo,
actually
device
level
model.
We
also
have
a
few
service
level
model
and
male
make
a
CUDA
progress
recently
get
published
and
based
on
eros.
We
SM
piece
actually
is
obviously
82
949.
M
Actually
by
mapping
the
service
model
into
the
device
level
model,
we
can
actually
provide
a
service
delivery
fulfill
that
service
creation,
but
what
it
missing
part
is,
we
think.
Actually,
we
cannot
do
actually
provide
quite
like
a
service
monitoring,
several
insurance
and
when
you
get
a
networker
set
up
and
the
server
is
created,
how
do
you
monitor
the
surveys?
How
do
you
expose
the
network
performance
of
the
network
to
the
management
system?
So
this
is
a
gap
we
want
to
face.
M
We
want
to
feel
so
we
so
it
proposes
results
and
facing
model,
and
this
resource
in
Phase
II
model
is
translated
from
the
customer
facing
model
and
as
they
were,
walking
together
with
service
model,
to
provide
a
not
only
service
creation,
but
also
is
pro-beijing
as
service
monitoring
assurance
and
also
we
can
use
these
service
monitoring
information
to
choose
a
network.
Optimization.
M
So
why
so
why
the
service
model
and
network
enemy
model
is
not
in
love.
Actually,
we
we
can
say
service
model
is
a
service.
A
perception
is
a
kind
of
top-down,
a
it's
kind
of
a
top-down
model,
so
so
Cosmo
only
interesting
is
the
service,
so
they
can
program
the
service
into
layer,
one
layer,
two
layers
to
a
level
four
seven
security
service
and
they
can
do
the
mix
match
and
but
the
customer
don't
care
about
how
you
realize
these
surveys?
M
How
how
what
kind
of
resource
you
can
use
that
you
realize
these
service,
so
we
have
no
enemy
model.
They
actually
focused
on
the
resource
abstraction.
So
we
can
have
what
happen
model
is
actually
try
to
abstract
the
fundamental
negative
technology,
for
example,
layer,
one
layer,
two
there's
three
technology
and
typical
wines
like
topology
model
and
PGP
model
and
some
other
model,
and
so
so
so
what
do
we
try
to
do?
M
Actually
we
can
map
of
service
level
model
into
the
network
element
model,
and
actually
they
will
use
food
on
board
service
mode
as
input
and
and
and
into
the
automated
control
confirmation
application.
They
can
generate
the
many
congregation
parameter.
They
can
go
to
different
narrow
animal
model
and
welcome
citizen
together,
using
some
like
a
scream
among
or
some
other
mechanism
to
assemble
all
of
these
model
together
and
we
can
populate
it
this
model
into
appropriate
and
then
what
device.
But
that's
is
that
or
is
that
enough?
Actually
I
think?
What
is
the
missing
part
is.
M
How
do
you
expose
some
subset
apology
to
the
operator
itself
is
some
in
some
cases.
You
need
to
really
want
to
know
how,
where
or
how
bad
the
Nano
is
operator.
So
you
need
to
report
it
and
then,
with
performance
or
the
network
data
to
to
the
to
the
operator
or
to
the
management
system.
They
can
manipulate
these
kind
of
networks,
data
to
choose
a
network
reorganization,
so
you
can
actually
form
these
close
to
over
live
life
cycle
the
service
and
management.
So
there's
basic
idea,
so
we're
seeing
that
we
have
to
approach
those
crunches.
M
You
can
extend
like
a
surface
model
airway
SM
model,
but
we,
this
has
already
been
discussed
in
our
choice
and
what
can
go,
but
we
sink
early
to
add
a
lot
of
complexity
since
you
introduced
a
quite
a
lot
of
Stata.
So
the
second
way,
actually
you
can.
You
can
actually
create
another
model,
separate
a
model.
We
call
the
resource
efficient
model.
M
What
do
you
need
to
do
is
actually
choose
a
service
bounding,
so
we
gave
the
idea.
What
do
we
try
to
do
is
foster.
You
can
establish
this
topology
so
because
you
have
allocated
P,
II
device,
information
and
maybe
say
T
information.
You
can
replace
the
location
information
in
in
the
service
model
with
these
just
selected
a
P
information,
so
you
can
create
a
surface
topology
and
pieces
of
service
topology.
You
really
want
to
know
for
W
have
several
side
they
located
in
different
but
freaky
location.
M
So
you
need
to
establish
that
you
said
about
setup
of
the
path
between
this
site,
so
you
need
to
pay
some
choose
requirements,
so
so
we,
you
should
establish
their
service
bounding
to
bound
as
a
service
follow
ways
to
the
past.
Well,
after
you
do
that
you
set
up
the
paths
or
set
up
a
tunnel,
you
can
actually
monitor
performance
over
the
tunnel.
M
Maybe
the
town
rapture
is
a
Marty
Hawk,
so
you
need
to
maybe
monitoring
each
hub,
the
provenance
and
you
can
put
them
together.
You
can
aggregate
all
the
all
of
these
calculated
the
entering
a
tunnel
performance
and
the
pistes
tunnel
performance,
so
you
can
actually
to
try
to
do
some
reorganization,
so
you
can
actually
provided
a
closed-loop
service
management,
so
here
they
show
the
like
service
topology,
creating,
and
yet
we
already
discussed
this,
and
so
we
can
see
the
resource
model.
Actually,
it's
just
translated
from
the
service
model
or
instantiated
from
service
model.
M
M
Cues
parameter
aspect
there
from
the
service
model
and
you
can
face
this
future
apartment
that
you
calculate
the
paths
for
each
II
follow
and
you
can
find
it
finer.
The
service
follow
ways
the
pass
and
and
then
you
can
actually
actually
monitoring
that
the
past
performance
on
ton
of
a
performance
and-
and
you
can
report
this
to
the
management
system
and
and
you
can
enable
to
the
record
optimization.
M
So
we
for
the
performance
family
that
we
can
have
like
a
facade
and
metal
performance
parameter.
Also,
we
have
some
proponents
and
I
meter
associated
ways,
multiple
sided.
We
call
this
end-to-end
publicity
parameter
so
when
you
use
all
of
these
prophets
parameter
as
the
network
performance
criteria
to
to
calculate
that
the
path
basis,
the
performance
parameters.
So
that's
my
idea.
M
N
You
we're
over
time,
but
please
how
many
people
read
this
quite
a
few
actually
one,
two,
three
four:
five:
six,
seven,
eight
nine
ten.
Please
comment
on
the
list
where
the
blue
sheets
floating
around
excellent.
So
thank
you
very
much
for
attending
ops.
Aughh
will
comment
on
the
list
on
this
last
draft
on
all
of
them
and
we
will
see
you
next
time.
Warren
wants
to
say
something
and.