►
From YouTube: IETF97-LMAP-20161117-1330
Description
LMAP meeting session at IETF97
2016/11/17 1330
A
B
All
right
so
I
guess
when
you
don't
get
to
get
started
it's
about
two
minutes
after
so
you're
at
this
is
the
L
map
working
group.
So
if
you
think
you're
at
somewhere
else
or
wanted
to
be
the
different
working
group,
that
was
the
time
to
run
out
all
of
our
presenter
presenters
today
or
a
remote.
We
actually
don't
even
need
the
box
today,
but
I'm
actually
Dan
Romus
Conda,
the
co-chair
it
will
be
presenting
well
he'll,
be
co-chairing
remotely
as
well.
Can
you
hear
me
Dan.
B
B
D
B
B
B
B
Alright,
the
agenda
for
the
day,
so
actually
I
should
do
it.
Let
me
do
the
work
working
rib,
stash
real
quick,
so
we
have
to.
We
have
both
the
framework
and
use
cases
as
our
seas
that
have
been
published.
We
have
a
metric.
Actually,
we
have
another
RFC
that
was
an
IP
p.m.
the
supporting
L
map
work.
The
current
work
items
that
we're
going
to
discuss
today
hinge
around
the
information
model,
the
yang
draft
discussion
and
the
rest
comp,
but
those
both
are
relying
on
the
information
model.
B
B
Anything
else,
and
then
we'll
see
where
we
end
up
at
the
end
of
this
discussion,
is
there
any
agenda
bashing,
so
you
want
to
add
anything.
I
just
know
for
the
the
working
group.
Both
both
shares
are
now
or
I'm
art,
I
know,
Dan.
You
can
feel
free,
I'm
not
sure
what
your
they
have
no
longer
employed
by
via.
So
it's
not
clear
whether
or
not
either
one
of
us
will
be
participating
ietf.
C
In
what
what
I
am
concerned,
the
I'm
retired
I
plan
to
continue
to
to
participate
in
the
ITF
work,
but
participating
in
meetings
will
become
rather
see,
exceptions,
answer
rules
so,
for
example,
my
next,
my
next
meeting,
probably
will
be
as
one
in
Prague
yeah.
So
I
will
call
I
will
continue
to
to
to
support
the
elm
at
work,
but
probably
it
will
be
difficult
to
participate
in
meetings.
B
C
C
B
E
Me
hello:
yes,
we
can
hear
you
apparently
so
good
afternoon,
so
we
have
a
few
issues
left
on
the
information
model,
the
first
one
and
we
had
some
discussion
about
it
on
the
list.
I
was
actually
raised
as
part
of
the
yang
doctors,
review
of
the
young
data
model
and
the
question
that
was
raised
was
why
the
arm
up
information
model
or
the
data
model,
but
it
also
applies
to
the
information
model
fields
in
charge
of
configuring,
the
device
ID.
It
seems
that
the
device
ID
is
something
that
isn't
really
an
obscure.
E
So
it's
not
something
that's
specific
to
the
a
map
infrastructure.
It's
something
that's
used
by
the
arm
up
infrastructure,
but
it's
not
specific
to
the
MF
infrastructure.
And
so
the
question
is:
why
does
the
above
information
model
talks
about
configuring,
the
device
ID,
and
so
the
proposal
is
to
actually
remove
the
configuration
of
the
device
ID
because
it's
outside
of
the
arm
up
scope?
And
somehow
we
haven't
settled
this
finally
on
on
the
list.
So
hopefully
we
can
settle
it
now.
I.
F
Think
Tim
will
so.
This
is
tim,
carry
nokia,
so
the
the
device
ID,
let's,
let's
step
back
right,
so
the
pre
configuration
elements,
information
elements
that
were
in
the
information
model
actually
was
driven
from
text.
That's
in
the
that's
in
the
framework
document
that
says
you're
going
to
need
you're
going
to
need
to
provide
a
couple
things
to
the
agent.
F
You
may
very
well
need
to
provide
its
its
ID
as
well
as
its
the
device
identifier
and
that's
very
explicit
in
the
framework
document
in
section
3
dot
one
and
the
information
model,
which
is
still
in
version
12,
because
I
just
pulled
it
down.
It
talks
about
the
pre
config
as
being
and
I'll
quoted.
It
says
the
information
is
the
minimal
information
that
needs
to
be
pre-configured
to
the
MA
in
order
for
it
to
be
successfully
communicate
with
control
or
during
the
during
the
registration
process.
F
Some
of
the
pre
configuration
information
elements
are
repeated
in
the
information
configuration
information
in
order
to
allow
the
Elm
app
controller
to
update
the
items.
Some,
not
all
so
I,
don't
expect
the
device
identifier
to
be
updated
by
the
way.
From
the
controller,
the
pre
configuration
information
also
contains
some
elements
that
are
not
under
the
control
of
the
omap
framework,
such
as
the
device
identifying
device
security
credentials.
So
it's
just
an
information
element.
F
That's
in
the
pre
config
section
that
really
the
controller
is
not
going
to
have
any
access
to
and
the
collector
in
terms
of
configuring
and
the
collectors
not
going
to
have
any
access
to,
and
it's
been
stated
clearly
in
the
information
model.
The
pre-configure
is
not
a
subset
of
what
the
configuration
is.
In
fact,
it's.
Those
two
elements
are
two
different
elements
that
just
so
happens
to
share
some
configuration
elements
and
so
I,
don't
think
the
the
device
identifiers
necessarily
needs
to
be
removed.
F
If
we
do
remove
it,
we
got
to
go
fix
the
framework,
probably
as
an
errata,
and
we
need
to
remove.
We
need
to
fix
this
text
documentation
in
section
3
dot,
one
personally
from
a
BBF
perspective.
I
would
remove
it
because
it
actually
conflicts
with
the
fact
that
we
have
other
elements
that
allow
you
to
config
the
device
identifier.
They
call
it
a
customer
equipment
adnan
fire
in
the
BBF,
so
it
actually
makes
my
chance
easier,
but
it
will
cause
you
guys
problems
in
the
ITF,
because
you
got
framework
problems
and
you
got
you
know.
F
The
information
model
problems
that
you
that
this
stuff
dribbled
down
through
right
I,
will
say
the
reason
why
we
do
in
the
BBF
we
allow.
This
thing
to
be
modified
is
because
it
gives
the
service
providers
a
chance
to
change
so
a
device.
Identifier
could
be
a
mac
address
the
surfrider
sigma.
I
don't
want
it
to
be
the
serial
number.
F
I
needed
to
be
something
else
in
the
serial
number,
because
guess
what
the
serial
number
between
two
different
vendors
they
use
the
same
serial
number
right
or
have
the
same
potential
for
a
serial
number,
so
they
use
their
own
identifiers.
So
that's
the
reason
why
it
was
driven
down
that
way.
Right
again,
if
you
choose
to
remove
it,
we're
going
to
have
to
do
something
with
the
framework
document
and
we're
going
to
have
to
figure
out
what
to
do
with
this
section,
3
dot
one
so.
C
F
B
F
Framework,
you
would
have
to
go
back
up
and
at
least
fix
the
framework,
because
the
framework
was
explicit,
which
is
why
it
was
in
the
pre
config
on
the
information
model
and
you'd
have
to
fix
the
information
model.
But
again
the
pre
config
has
no
bearing
on
should
have
no
bearing
on
the
data
model
unless
you're
trying
to
make
your
data
model.
Your
yang
data
model
a
bootstrap
model
to
the
MN,
and
if
it's
a
bootstrap
model
for
the
MA,
then
yeah,
then
it
does
come
into
play.
E
F
C
So
now
its
ends
with
him
that
look
looking
as
I'm
speaking
as
a
contributor
now
and
speaking
loud
to
some
extent
on
the
precum
freak.
So
it
looks
like
we
have
like
a
couple
of
options,
maybe
more
than
two.
Why
would
it
be
to
take
it
out
from
the
pre
config
and
decide
whether
we
want
to
to
amend
the
framework
which
is
kind
of
let's
say
optional
to
some
extent,
because
as
a
framework,
we
can
actually
put
a
note
pay
attention
we
may
not
be.
C
Now
speaking
as
a
chair
now,
I
would
very
much
like
to
try
to
get
out
with
resolutions
here
and
actually
give
instructions
to
Jurgen
as
editor.
What
to
do
in
the
next
iteration
should
come
very
shortly.
I
believe
that
he
make
him
make
him
a
k1
on
his
machine
already
and
then,
if
there
are
really
strong
opinions
about
what
he
has
done
in
the
revised
text,
then
this
audience
be
expressed
as
last
call
comments,
but
I
I
would
prefer
not
to
leave
open
issues
after
this
meeting
I.
B
F
Know
it
needs
it
needs
not
to
be
in
the
in
the
config,
but
it's,
but
it
makes
sense
to
be
in
the
pre
config
and
the
pre
config
doesn't
have
anything
to
do
with
the
data
model
unless
you're
talking
about
some
type
of
bootstrapping
I'm,
just
saying
so.
If
you
just
remove
her
from
the
config
itself,
that's
all
you
have
to
do
to
that.
Im
draft
and
everything's
still
consistent
with
the
framework
and
consistent
with
the
text
and
the
in
the
IM
draft.
That's
all
gotcha.
B
E
E
B
E
The
second
issue
is
about
the
reporting
of
the
agent
ID
I'm
right
now.
The
the
logic
is
that
there's
a
flag
saying
report
agent
ID
of
you,
set
it
to
false,
but
there's
no
group
ID
set
it's
still
sending
the
agent
ID,
which
is
kind
of
a
little
bit
surprising.
If
you
just
look
up
what
you
intuitively
expect
that
this
boolean
just
targets,
whether
the
agent
ID
is
sent
or
not,
and
so
the
proposal
was
to
actually
have
two
bits.
E
B
A
E
F
F
E
E
Jörgen,
did
you
have
that
as
a
item
I
didn't
have
that
as
an
item,
because
I
thought
we
had
agreement
before
that
we
actually
moved
from
that.
We
changed
the
labor
from
metric,
you
I
to
just
registry
URI
or
whatever
it's
called
know
before.
So
that's
why
I
made
the
edit
if
we
have
to
revert
that
someone
else
to
make
a
point.
G
Made
we
need
to
understand
it
a
bit
on
I
think
what
I've
seen
in
you're
going
to
correct
me
if
I'm
wrong
is
what
you're
saying
that
is
that
it
does
not
have
to
be
the
iono
registry.
It
kid
be
any
registry.
Would
it
would
your
expectations
still
be,
though,
that
it
is
in
the
registry
format,
or
would
it
be
in
some
other
format.
E
This
so
the
value
of
this
object
is
the
UI,
so
the
UI
can
point
to
pretty
much
anything.
The
metrics
registry
that's
done
an
IP
p.m.
is
about
metrics.
So
it's
about
anything
that
you
can
measure.
However,
a
map
has
a
number
of
tasks
that
don't
do
any
measurement
they
do
reporting.
They
do
things
like
that,
so
they
naturally
fall
outside
of
the
scope
of
the
metrics
registry
and
it.
E
G
Wondering
if
it
might
make
sense
that
if
it's
something
that
doesn't
fit
into
a
registry
format
/
the
I
ppm
registry
format,
then
maybe
it's
not
too
useful
to
have
a
URI.
So
maybe
the
URI
gets
left
blank
in
that
case,
but
I
think
it
would
be
useful
if
there
were
a
stipulation
that
this
particular
you
are
I
pointed
to
something
in
the
registry
format.
Would
that
be?
Okay?
No.
G
F
Sometimes
you
know
when,
since
we've
moved
everything
from
at
asking
228
a
ski
model
tasking
event
model
you're
going
to
want
to
do
things
that
aren't
I
ppm
related
you're
going
to
want
to
do
housekeeping
you're
going
to
want
to
do
stuff
even
in
the
BBF.
We
use
that
that
that
that
same
parameter
to
point
to
the
BBF
registry,
which
is
an
IP
IP
p.m.
when
we
do
our
care
1.3
test.
Yes,
but
it's
in
the
format.
So
you
would.
G
G
F
To
yes,
so
that
would
mean
that
if
you're
going
to
not
put
it
in
the
I
ppm
format,
you
neva,
if
you
do
you're
gonna,
have
to
have
a
repository
for
your
registry,
because
you've
got
a
point
somewhere
right
and
it's
got
to
be
in
some
format.
That's
well
known
right
and
that's
okay.
You
can
have
that
as
part
of
what
you
point
to,
but
yeah,
so
I
guess
the
question
jörgen
is:
is
that
free
for
those
things
that
aren't
directly
related
to
the
I
ppm
tasks?
F
E
Personally,
I
would
expect
this
to
be
likely
different
or
a
subset,
but
it's
difficult
to
say:
I,
think
the
I
ppm,
metrics
registry
format
isn't
really
final,
yet
or
well.
I
didn't
follow
the
IP
p.m.
session,
but
whatever
I
think
there's
a
number
of
things
in
the
IPM
I
ppm
metrics
format
that
definitely
are
needed
and
there
might
be
things
that
are
needed
for
the
tasks
that
aren't
in
the
IP
p.m.
vetrix
registry.
So
but
for
the
information
model.
I
think
we
are
fine.
D
Annular
here,
and
so
as
far
as
I
understand,
I
think,
with
the
current
information
model
that
it,
I
think
this
supports
everything
we
need.
So
what
I
understand
is
you
will
have
at
least
three
type
of
different
registries
that
you
will
need
for
this
to
work.
You
will
need
the
matrix
registry.
You
probably
need,
like
the
public
metric
registry.
You
probably
need
something
like
a
private
registry
that
the
operator
or
whoever
is
running
this
things
for
whatever
they
want
to
measure
that
it's
not
in
the
in
the
public
registry,
and
you
probably
need
something.
D
But
it's
like
l
map
operations,
type
of
registry
that
are
there
are
tasks
that
you
want
to
do
that
are
not
really
related
to
measuring
anything.
I
understand
that
that,
basically,
what
the
current
scope
is
them
in
the
car
approaches,
each
of
these
registers
will
have
their
own
your
I
a
type
of
a
naming.
Hence,
when
you
include
a
task,
you
can
clued
it,
which
you
start
with
the
URI
of
the
of
the
of
the
performance
metric
registry.
Then
you
will
go
to
those.
D
E
E
D
To
sort
out
right,
then
I
mean
the
question
I
think
the
real
question,
because
you
can
you
can
envision
other
ways
of
doing
this,
where
you
can
actually
envision
that
there
will
be
a
single
L
map
registry
that
actually
then
sub
contain
super
registries
that
contained
the
performance
registry,
for
instance,
or
so
you
can
make
on
call
different
kinds
of
structures
of
these
registries,
but
I
think
the
current
information
model
support
any
of
those
right
because
it
generally
enough
to
support
any
of
those
so
forth
from
the
information
model.
I
think
that's
fine.
D
B
E
E
E
Thinking
a
little
bit
further
about
it
I
my
proposal
is
actually
to
do
nothing
because
having
optional
options,
objects
is
by
itself
not
a
problem,
and
the
main
reason
is
that
not
necessarily
all
implementations
might
actually
support
the
access
control
model
that
we
have
and
so
having
these
are
objects.
Optional,
optional
might
actually
simplify
certain
implementations.
So
so
my
proposal
on
this
issue
is
just
to
do
nothing
and
drop
it.
E
Arm
that
was
raised
by
Martin
during
his
review.
We
have
a
couple
of
objects
that
report
the
current
Hardware.
The
MA
is
running
on
the
firmware
it's
running
on
and
the
device
ID
and
these
objects
overlap
with
objects
that
we
have
already
some
of
them
in
our
seas
and
some
of
them
on
the
way
to
become
our
seas,
so
that
some
particular
the
ietf
system
model
has
something
that
overlaps
with
a
hardware
and
firmware,
and
the
idea
of
hardware
model
will
have
something
that
overlaps
with
the
device
ID.
E
And
so
the
question
is
that
Martin
raised.
Shall
we
remove
those
overlapping
documents
and
I?
Think
personally,
that's
a
good
idea.
So
the
proposal
is
to
actually
remove
the
hardware
and
film
relatives
from
the
Elm
up
data
model
and
instead
at
text
somewhere.
That
says
those
objects
can
be
found
in
RC
7317
and
for
the
device
ID
to
essentially
the
same
and
point
to
the
hardware,
the
ITF
hardware
model.
E
The
only
little
detail
is
that
the
hardware
model
is
still
being
worked
on
in
the
net
much
so
that's
not
yet
on
our
see
but
I
checked
for
all
the
other
objects.
Where
we
do
the
same
thing
where
we
say
well,
we
don't
find
it
here.
It's
defined
over
there.
All
these
references,
actually
information
are
reference,
or
so
it
would
not
be
a
blocking
blocking
thing
that
holds
off
the
document.
E
F
E
E
I
didn't
hear
back
from
Martin,
so
I'm
not
sure
they
had
time
to
look
at
this
or
not,
but
probably
once
we
have
all
seven
that
might
be
reasonable
to
check
what
Martin,
whether
he
is
fine
with
the
changes
and
so
forth,
so
that
we
can
conclude
the
young
doctor
review
cycle
I
think
but
I
leave
that
to
the
chest
to
organize.
So
that's
one
necessarily
my
job
well.
C
He
shouldn't
oppose
any
any
of
the
proposals,
but
just
my
opinion.
The
other
solution
would
be
to
go
ahead
and
boozy
edits
and
at
last
call
time
sent
to
Martin
CID
and
the
lich
king
now.
Well,
this
is
a
last.
The
last
call
and
the
please
let
us
know
if
you
have
any
problems
with
proposed
solutions.
I
personally.
C
Yeah,
it
would
be
that
it
would
be
very
nice
if
people
that
the
last
call,
if
you
are
happy
with
what
is
going
on
with
a
Content
who
just
like
us
now
I
have
read
the
document
and
I
don't
have
any
pending
problems
with.
It
is
very
useful
as
well,
because
it
gives
us
a
feeling
about
the
document
having
been
read
and
agree,
traders
and
ignored.
C
F
This
is
Tim
Carey,
so
the
from
a
BBF
perspective
we're
doing
this
and
we
use
the
t69
protocol
with
the
with
its
associated
data
model.
So
it
has
its
own
data
model.
I
would
suspect
and
I
can't
speak
for
the
BBF,
but
I
would
think
that
we
would
from
for
my
from
my
perspective
is
that
we
would
use
what
the
IETF
is
done,
because
that's
generally
are
the
way
that
we
do
things
is
we
look
to
see
if
there's
already
modules
out
there
before
we
better?