►
From YouTube: IETF-IVY-20230920-1400
Description
IVY interim meeting session
2023/09/20 1400
https://datatracker.ietf.org/group/ivy/meetings/
A
A
D
A
Okay-
okay,
that's
good,
so
I
think
it's
time
now.
So
let's
get
started.
Okay,
so
hello!
Everyone
welcome
to
the
ITF
IV
intermitting
I.
Think
it's
a
virtual
meeting
and
good
morning,
good
afternoon
and
good
evening
for
everybody.
I
think
it
might
be
a
challenging
time
for
some
of
you
guys
to
participate
in
our
today's
meeting,
but
we
are
glad
that
you
all
make
it
on
time.
So
thank
you.
Everyone
and
again
I
would
like
to
remind
everyone
that
Please
be
aware
that
this
session
is
being
recorded
and
for
note,
12,
I
I.
A
Think
still
I
would
like
to
remind
everyone
that
Please
be
aware
that
when
you
contribute
you
are
expected
to
follow
the
ITF
processes
and
the
IPR
policies
and
if
not
not
familiar
with
the
the
the
the
slide.
You
can
take
a
look
at
this
slide
and
a
couple
of
documents
in
the
in
this
slide
and
for
our
today's
meeting
I
believe
we
will
have
an
hour
and
a
half
and
this
online
meeting
and
for
the
mini
attacker.
A
A
The
discussion
should
happen
in
Iris,
so
this
is
to
be
done
for
the
chairs
to
create
the
IV
vehicle
for
your
design
team
discussion.
So
if
you
have
some
favorite
slot
to
discuss,
then
just
let
us
know
so
that
we
can
send
the
meeting
invitation
or
you
it's
okay,
that
if
you
would
like
the
same
slot
as
the
C
Camp
design
team
discussion.
So
just
let
the
chairs
know
and
also
in
the
near
future.
A
The
chairs
think
that
this
work
might
not
be
tightly
very
tightly
related
related
to
the
the
current
focus
of
IV.
Now,
but
still
it's
a
very
it's
a
very
interesting
work
to
explore,
so
we
will
have
10
minutes
to
discuss
it
and
finally,
we,
hopefully
we
will
have
30
minutes
for
the
open
discussion
and
the
wrap
up.
A
How
to
move
forward
with
the
network
inventory
core
model
and
the
options
include
any
of
the
network
inventory
related
drafts
that
has
been
presented
in
the
itf-117
meeting
at
San
Francisco,
and
here
the
we
read
a
poll
and
with
three
options
for
the
working
group
to
choose
their
their
favorite
one
and
option
one
is
to
adopt
the
secam
hardware.
Network
Hardware,
inventory
draft
in
IV
and
involved
to
become
the
network
inventory
based
model
and
option.
Two
is
to
adopt
the
Ops
area.
The
network,
Inventory
management,
Dropped
In,.
A
D
D
E
F
E
A
A
A
A
So
I'm
so
I
I'm
trying
to
say
that
in
the
last
three
weeks
we
were
having
a
poll
on
the
mailing
list
and
there
are
three
options
and
option
one
and
option
two
regarding
to
adopt
the
existing
drafts
in
currently
in
other
working
groups.
I
think,
is
in
sea
camp
and
in
Ops
area
working
group.
We
would
like
to
ask
for
the
working
group
preference
about
adopt
them
in
Ivy
and
involved
to
become
the
network
inventory
based
model
and
for
option
three
in
case
none
of
them.
A
The
working
group
think
that
none
of
them
is
good
enough.
The
chairs
might
like
write
a
zero
zero
version,
including
just
the
table
of
content,
and
we
would
like
to
be
covered
in
each
session
and
which
will
then
be
handed
over
to
Apple
of
others
to
bring
it
to
the
working
group
adoption
and
next
slide.
Please.
A
A
In
the
second
draft
which
the
chair
thing
might
be
a
little
confusing
and
close
to
option
three
or
option
4,
which
I
will
explain
later
and
also
we
have
some
other
viewpoints.
I
think
it's
from.
They
are
from
the
authors
and
contributors
of
the
first
draft,
the
indicator
to
use
a
mod,
a
modular
approach
which
allows
us
to
publish
a
hardware
inventory
module
first
and
then
with
a
one
or
more
augmentation
module
models
that
cover
others,
which
is
in
the
IV
status
scope.
E
A
A
I
think
Alex
had
met
a
comment
which
is
about
with
you
to
say
that
I
guess
this
makes
me
a
proponent
of
option
three,
but
with
the
caveat
that
this
would
not
need
to
restart
from
scratch,
really
an
option.
4
that
says:
merge
for
overall
structure
and
common
paths,
which
in
this
case
is
possible
and
split
the
remaining
difference.
So
I
I
think,
let's
say
it's
an
option
for
temporary.
A
So
do
we
have
a
fair
amount,
people
with
option
one,
while
the
other
half
prefer
option
three
and
option
four,
and
it
seems
that
in
the
end
it
seems
that
the
boundaries
among
the
different
options
has
blurred
right.
There
doesn't
seem
to
have
so
much
difference
now
between
option
one
and
option
three
or
four
as
a
result.
Previously,
for
example,
even
we
go
with
option
one
or
two
at
the
starting
point.
We
can
update
it
and
might
still
take
valid
aspects
from
the
other
draft.
A
That's
which
is
actually
a
combination
of
both
but
I
think
we
might
decide
whether
we
want
a
merged
effort
or
a
modular
approach.
So
here
I
would
like
to
emphasize
that
this
is
not
about
any
decision
making
of
This
chair's
presentation.
I
know
that
we
are
still
having
the
following
up
presentation
from
the
authors
of
the
drafts,
so
for
this
part
the
chairs
try
to
have
the
working
group,
identify
the
divergency
among
different
opinions
and
hopefully
to
help
steer
the
working
group
into
agreement
and
next
slide.
A
Please,
and
also
we
have
some
questions
derived
from
the
the
polling.
It's
a
under
very
top
wind
is
the
separate
evolution
of
hardware
and
additional
inventory
in
different
drafts.
Is
this
something
the
working
group
wants
to
pursue?
I
think
the
the
authors
will
have
will
still
have
to
present
this
part,
and
this
is
something
the
chairs
would
like
the
working
group
to
consider
and
if
we
decide
to
go
with
the
option
three
options
file
to
send
more
to
existing
drafts.
A
A
Does
this
make
sense
to
you
or
if
or
you
have
any
other
suggestions
or
you
can
voice,
and
also
there
is
another
question
I
think
has
already
been
also
be
touched
by.
The
working
group
showed
the
equipment
room
be
included
in
the
network
inventory
based
model
I.
Think
Alex
has
met
some
comments
and
suggestions,
and
the
working
group
should
consider
this
because
I
think
the
equipment
room
is
about
the
location.
Information
is
in
the
IV
charter
school
that
showed
this
location.
A
G
D
One
thing
that
I
wanted
to
add,
which
is
I
mean
which
I
added
a
as
a
bullet
point
in
one
of
the
previous
slides,
is
the
fact
that
the
fact
that
we
were
pulling
the
one
draft
or
the
other
it
it
doesn't
mean
it
didn't
mean
that
the
draft
were
was
ready
to
be
adopted
and
then
sent
to
the
HG
for
publication.
I
mean
in
both
cases
we
were
trying
to
understand,
which
was
the
draft,
if
any.
D
That
was
a
meeting
most
of
our
requirements,
and
that
was
easier
to
to
use
as
the
foundation
for
for
our
work
so
that
that
that's
why?
In
the
end,
the
difference
between
option,
one,
three
or
four-
is
extremely
extremely
negligible,
whether
we
we
we,
we
decided
to
go
for
option
one
option
three
or
option:
four,
the
result
is
a
is
basically
is
basically
the
same.
D
Another
thing
is
that
we,
we
will
now
listen
to
the
three
different
presentations
from
from
different
authors,
and
we
will
try
to
answer
the
questions
that
we
raised
here.
At
the
end
of
the
session,
we
have
half
an
hour
for
for
open
discussion.
So
ideally,
a
successful
meeting
is
is
a
meeting
that
allows
us
answering
these.
The
the
the
the
three
questions
that
that
you
see
here.
A
E
D
G
G
G
So
this
slide
is
about
what
we
have
discussed
with
the
sea
Camp
authors
on
some
like
merging
efforts,
so
at
ietf
117
we
received
some
good
useful
comments,
such
as,
like
that
most
people
don't
like
RC,
8345,
topology
augmentation
and
removing
some
non-inventory
attributes.
So
after
revising
our
model
on
the
September
secam
inventory
weekly
call,
we
try
to
discuss
VC
Camp
author
to
see
whether
our
cases
use
cases
can
be
incorporated
into
c-camp
inventory
model.
G
G
G
And
also
some
some
attributes
from
ITF
system,
and
but
we
extend
the
iitf
hardware
class
with
some
software
class
components.
So
that's
the
model
we
proposed
and
this
model
we
we
proposed.
We
can,
based
on
the
discussion
on
the
last
ITF
meeting.
Most
folks
feel
that
license
should
be
optional,
not
be
the
core
core
part
of
the
network
inventory.
So
we
we
also
agree
with
that.
G
G
G
So
we
try
to
see
whether
we
can
merge
through
the
augmentation
approaches,
as
the
most
most
of
us
feel
that
the
second
Hardware
inventory
can
be
the
base
Network
inventory
model.
So
here
we're
trying
to
see
whether
from
this
base
model
can
achieve
what
the
generic
inventory
model
and,
let's
see
from
the
let's
begin,
with
the
option.
Two
I
think
these
two
options.
Actually
they
came
from
the
italos
117
presentation,
so
here,
I
I
divide
it
into
two
types
and
the
option.
G
This
is
a
difference
between
the
the
authors
of
the
two
drafts
like
from
the
second
authors.
It
suggested
that
the
common
inventory
model
can
be
obtained
through
simple
augmentation,
just
based
on
the
hardware
only
inventory,
but
I
don't
think
this
works,
because
if
we
want
to
like
augment
had
a
model,
we
cannot
change.
The
definition
of
network
element
in
current
see
can
be
inventory
model.
The
network
element,
actually
they
defined
as
a
physical
device.
G
G
Here,
I
I
made
some
more
modification
to
the
second
inventory
model
to
to
to
make
more
straightforward
comparison.
The
purpose
of
change
actually
is
to
reflect
definition.
Consistency,
although
ccamp
inventory
model
doesn't
like
explicit,
said
that
Network
elements
is
physical,
but
actually
in
the
the
draft
it
says
so
so.
I
I
made
this
change.
G
G
So,
from
my
perspective,
I
think
the
like
ITF
Hardware,
the
component
cost
has
been
be
restricted
to
Hardware
class,
so
this
Hardware
model
cannot
be
like
be
augmented
to
a
generic
platform
model
like
open
config
did
right.
It's
the
open,
config
platform
model
cannot
be
like
just
extended
the
hardware
model
to
to
be
a
hardware
and
software
together
model.
You
can
see
that
it
changed
the
type
of
the
component
to
the
union
so
then
to
support
software
and
Hardware
together
and
similar.
G
G
G
In
that
way,
we
can
have
a
consistent
terms
for
the
network
inventory
and
also
the
network
element,
whether
the
network
element
represent
a
physical
device
or
virtual
device,
and
also
in
that
word,
draft
can
provide
extension
guide.
Guidance
on
on
other
inventory
items
like
whether
the
size
or
racks
at
the
location
is
also
Network
inventory.
G
So
this
is
another
thing
next
slide,
please
so
here's
something
we
proposed
to
the
working
group
I
think
this.
Our
proposal
is
quite
relevant
with
the
chairs
questions,
so
we
don't
have
like
strong
preference
that,
whether
like
have
a
hardware
only
model
or
like
software
and
Hardware
together,
but
we
still
think
hardware
and
software
within
a
generic
model,
is
our
presentation
by
the
way,
don't
like
we
agree.
G
I
agree
with
Hardware
only
because
I
discuss
with
the
authors
and
I
agree
that
requirements
is
it
there,
so
so
I
I,
I
I
can
say,
there's
some
requirements
for
the
hardware.
Only,
but
still
I
I
see
that
networking
management
model
is
also
a
way
to
go,
but
it's
not
based
on
Hardware
inventory,
but
a
separate
module
that
need
to
be
defined
and
option.
D
D
G
C
C
Some
paraphrasing
of
the
question
that
has
been
raised
by
the
by
the
chairs
is
about
whether
the
split
between
other
and
soft
other
rolling
another
plus
after
use
cases
is
something
you
want
to
pursue
and
whether
it
makes
sense
to
start
focusing
on
hardware
and
then
software
as
an
addition
on
top
of
it.
And
the
second
question
was
about
the
point
touched
by
the
human
room,
whether
they
are
connected
and
whether
they
should
be
part
of
the
core
model
or
addresses
on
top
next
slider.
Our
answers.
C
Okay,
next
slide:
okay,
oh
yeah,
on
the
on
the
first
question,
the
answer
is
yes,
sir,
and
for
the
splitting
between
other
and
software
is
not
a
trivial
and
that's
why
we
have
some
slizer.
We
try
to
go
into
more
details
about
how
this
could
be
done
for
the
connection
between
a
camera
room
and
inventory.
We
think
they
are
connected,
but
for
the
second
question
core
model
versus
additional
model,
it's
a
bit
complex
answer,
so
we
will
go
with
some
more
detailed
answers
in
the
next
slides.
C
Okay,
then,
when
we
look
at
try
and
try
to
combine
hardware
and
software
I
think
Hub
also
showed
there
are
many
ways.
For
example,
we
can
have
a
physical
and
virtual
Network
elements
in
the
same
list
or
in
a
different
list.
We
can
have
hardware
and
software
components
in
the
same
list
or
in
different
lists,
and
if
you
want
to
be
extreme,
you
can
also
have
the
inventory
of
the
licensee
can
be
in
a
separate
list
or
in
the
same
list
as
the
address
of
the
components
in
these
slides.
C
We
made
assumption
that
we
follow
the
approach
in
the
wzwb
draft,
so
we
try
to
see
whether
we
can
modularize,
even
if
there
we
want
to
have
a
physical
investment
requirements
in
the
same
list
address
of
the
components
in
the
same
list
and
they
seem
everybody
agrees
on
having
the
licenses
as
a
separating
list.
These
are
the
Assumption
in
these
slides
and
we
need
maybe
to
get
confirmation.
That
is
the
direction
the
working
group
also
go
versus
other
options
next
slider
by
the
way,
these
are
the
the
most
complex
assumptions.
C
C
There
was
a
clear
indication
that
if
the
the
the
top
level
container
needs
to
be
renamed
as
Network
inventory,
to
have
a
broader
scope
than
just
hardware,
and
what
we
need
to
do
is
to
make
the
list
of
components
more
generic,
so
the
definition
of
the
component
list
should
be
more
generalized
that
it
will.
It
will
be
able
to
cope
with
the
software
components
and
not
only
with
other
components.
Even
use
of
the
components
are
not
defined
in
this
document,
and
then
we
can
have
a
separated
document,
which
is
a
separate
module.
C
Sorry
which
is
based
on
the
software,
which
is
adding
software
inventory.
On
top
of
it,
then,
which
can
be
used
together
with
a
base
inventory
when
we
have
our
use
cases
to
support
other
parts
of
the
use
cases,
and
this
model
can
be
follow
the
approach
on
the
wjwb,
and
then
we
can
Define
the
attributes
and
in
the
entities
that
are
needed
for
software
inventory
and
then
another
augmentation
for
the
license
system
and
also
licenses
proposed
in
wcwb.
So
we
can
have,
we
can
take.
C
We
can
cherry
picking
from
that
list
how
to
do
licenses,
and
then
we
separate
modules
people
can
address
different
type
of
use.
Cases
are
there
early,
other
plus
software,
other
licensee
or
other
plus
software
plus
licenses.
Next
slide.
Please
it's
just
a
matter:
okay,
the
the
okay.
In
order
to
make
the
the
definition
of
the
component
list
the
more
generic,
we
can,
for
example,
adopt
the
approach
to
define
the
class
no
more
as
a
hardware
type
other
identity
Union,
so
as
proposing
it
out
WWB.
C
The
attributes,
as
we
said,
as
was
said,
are
more
or
less
the
same,
so
we
can
take
as
the
basis
what
we
have
in
a
draft
in
the
second
draft.
The
list
of
network
elements
will
be
part
of
the
of
the
core
of
the
base
inventory
model
for
the
for
the
overarching
network.
Inventory
container
I
have
another
slide,
so
we
can
discuss
later
on
next
line
and
the
software
inventory
can
be
just
an
augmentation
in
a
different
module.
C
That
will
means
that
if
you
implement
a
Target
software,
you
have
to
implement
the
two
modules
next
slide
and
the
same
for
the
licenses.
The
license
will
be
augmented
under
the
top
container
Network
inventory.
This
means
that
if
you
don't
support
license,
you
don't
implement
this
model
and
you
can
combine
this
model
only
with
other
or
we
bought
ardony
software
and
the
the
attributes
can
be
taken
from
we
have
already.
The
the
wjwb
draft
is
proposing
some
as
a
starting
point.
We
can
use
that
one
next,
one,
okay
for
the
for
the
human
room.
C
Okay,
we
also
in
the
second
discussion
that
we
we
discovered
that
the
Kimber
rooms
is
a
little
bit
too
restrictive.
So
the
proposal
here
is
to
generalize
the
concept
of
the
of
the
human
rooms
and
they
find
a
more
genetic
concept
like
site.
The
akime
room
is
just
a
type
of
site
and
by,
but
we
can
in
future
Define
a
new
type
of
site
by
extending
the
the
type
we
may.
We
are
also
thinking
that
size
can
be
recursive.
C
For
example,
a
campus
is
a
site
which
contains
buildings
and
a
building
can
be
another
type
of
site
which
contains
gimbers
and
so
on,
and
this
list
of
sites
based
on
the
discussion
and
the
proposal
from
Alice.
It
seems
a
common
agreement
that
it
will
be
good
to
have
in
a
separating
module,
because
also
in
this
case,
we
in
discover
there
are
some
cases
where
people
where
there
are.
There
is
a
requirement
to
report
the
site.
In
some
cases
where
reporting
the
size
is
not
required.
C
If
you
want
to
retrieve
all
the
information
in
your
network,
you
can
you
just
do
a
single
rest,
conf
get
operation
on
the
top
level
container
and
get
everything
in
one
operation
rather
than
in
three
different
operations,
so
next
slide.
Okay,
this
will
be
how
the
augmentation
for
the
metric
for
the
electro
Academy
location
can
look
like.
You
have
a
list
of
sites
and
okay,
the
common
attributes
for
the
size
will
be
on
this
side,
and
then
you
have
a
site
class
for
which
we
can.
C
At
this
moment
time
we
have
defined
only
the
key
room
and
what
is
specific
to
the
camera.
Room
will
now
go
under
the
human
room,
specific
information
that,
like
the
list
of
racks
and
the
list
of
shelves,
which
is
a
camera
technology,
size,
specific
next
slide,
and
so
basically
the
the
the
this
is
graphical
representation.
From
the
two
models
that
we
have
a
cap,
Network
inventory
and
an
event
that
we
have
today
on
the
table.
We
can
split
into
four
models.
C
One
network
inventory
base
model
which
three
augmentation
one
for
network
communication,
one
for
networking
licenses
and
one
for
software
inventory
and
we
can
piggyback.
You
can
cherry
pick
from
the
two
models,
in
particular
on
the
core
model.
We
can
look
at
the
as
a
Next
Step
article
by
artificiency.
If
there
is
some
attributes
that
we
can
copy
from
the
WWB
draft
internet
documentary
next
slide.
C
Okay,
now
Ivy
proposed
the
four
four
modules
for
getting
the
the
fifth
module.
That
was
about
the
the
association
with
inventory.
We,
the
question
is
how
many
documents
we
can
have
two
documents
and
one
for
the
base
model
and
any
location
or
another
draft
for
the
staff
and
the
second
document
for
software
license
inventory
or
can
go
with
four
documents.
So
we
can
be
very
moderating
one
draft
for
each
module,
which
becomes
maybe
five
documents,
if
you
consider
also
the
topology
in
navigation,
to
work.
C
Apology
and
the
idea
is
not
one
draft
because
one
draft
we
are.
We
are
mixing
items
which
are
more
mature
with
item
which
are
less
mature.
It
doesn't
look
an
effective
time
effective
way
to
organize
the
documentation
next
one
and
the
next
step
is
basically
two
up
to
to
once.
We
agreed
how
many
drafts
and
which
content
and
how
to
modify.
We
can
do
the
update
and
I,
don't
see
any
reason
why
we
cannot
adopt
all
the
drafts.
C
D
D
C
D
H
Perfect,
thank
you
for
the
presentation.
I
have
one
commander
and
I
will
reiterate
in
my
presentation
as
well,
but
I
understood
on
the
purpose
of
the
ID
working
group.
It
was
to
take
basic
modules
for
covering
inventory
and
that's
why,
as
well,
we
have
been
a
bit
with
dmlmo.
We
have
been
out
of
the
discussions,
but
if
my
feedback
on
on
this
proposal,
if
we
consider
licensing
as
part
of
another
and
I
I,
believe
it
should
be
another
basic
another
module
right,
not
basically
but
another.
F
H
D
C
B
B
Why
would
we
still
be
augmenting
Network,
inventory
I
think
actually
the
location
is
something
that
can
be
kept
separate,
I
mean,
of
course
you
want
to
cross-reference.
You
want
them
to
be
able
to
to
cross
reference,
but
I,
don't
I,
don't
see
any
reason
why
your
location
should
be
included
in
an
inventory.
Maybe
there's
a
design
detail
but
I
think
I
I
just
want
to
yeah
bring
this
up
here
and
ask
for
that
on
on
the
record,
and-
and
so
that's
so
that's
my
first,
my
first
common
question.
B
The
second
one
concerns
actually
the
the
top
level
container
and
I
think
it's
it.
It's
good
to
rename
it
to
the
the
field
of
inventory
is
a
lot
more
General
and
so
forth.
However
I
my
question
is:
actually,
why
not
go
a
step
further
and
get
rid
of
the
container
and
tear
entirely
I'm,
not
sure
if
it
is
actually
needed,
I
think
we
can
do
without
it
again.
Maybe
design
detail,
but
I
just
wanted
to
bring
this
up
here
and
and
hear
your
your
reaction.
C
Well,
yes,
if
you
get
rid
of
the
of
the
top
level
container,
I
think
the
first
answer.
The
first
question
is
become
the
answer,
because
the
network
element
location
will
be
a
top
level
container
by
himself.
So
yeah
I
think
the
the
reason
why
I
I,
where
is
Live
preference
for
the
top
level
container,
is
really
the
fact
that,
with
the
top
level
container,
you
cannot
drive
everything
in
a
single
operation.
Rather
because,
if
you
look
at
the
oh,
if
you
implement
everything,
you
will
have
a
three
top
level
containers.
B
D
Sorry,
Alex
I
just
wanted
to
make
a
comment
if
we
go
for
the
top
level
container,
that
the
name
is
a
super
generic.
It's
a
network
inventory.
We
need
to
be
super
careful
to
clear
this
data
what's
in
scope
and
what
is
not,
because
if
you
read
the
ITF
Network
inventory,
you
might
think
that
it
includes
a
software
licenses
locations
Etc.
So
we
need
to
be
super
careful
in
and
super.
E
B
D
B
Question
here
sorry,
one
question
actually
on
this:
one
also
is
so
yeah
so
clearly,
so
if
the
only
use
case
is
Network
inventory,
then
okay,
fine
and
maybe
but
I'm
always
concerned
with
basically
expanding
on
the
instance
name
because
every
instance
now
gets
this
gets
needs
to
have
this.
This
prefix,
at
least
in
the
XML
rendering.
B
The
other
thing
is.
There
are
maybe
other
use
cases
which
are
which
want
to
use
this
inventory
model
but
which
are
not
inventory
per
se.
So,
for
instance,
when
we
talk
about
Network
digital
twin
right,
that
would
be
able
to
operate
on
that
as
well.
But
that
would
be
yeah
I'm,
not
sure.
If
we
would
say
the
digital
twin
works
on
an
inventory,
because
it
would
need
things
like
s,
attacks
for
instance,
but
I
do
think
actually
would
be
in
scope
in
terms
of
the
use
cases
being
addressed
here.
B
C
D
C
G
C
B
C
Know,
for
example,
if
you
have
a
network
inventor
without
the
software
Network
inventory
that
have
only
all
the
devices
are
physical.
If
you
have
both
Network
and
software,
then
you
know
that
you
have
a
mix
of
virtual
and
physical
devices,
and
then
you
know
you
will
you
will
need
to
have
an
attribute
that
distinguishes
the
amount
that
you.
G
I
I
still
don't
agree
with
you
on
this
definition,
because
I
I
don't
think
like
using
a
simple
augmentation
will
like
change
the
network
element.
Definition,
that's
not
I
I
mean
you
divide
it
into
four
Parts,
but
the
I
I.
Don't
still
don't
think
the
software
Network
inventory
is
the
right
way
to
go.
C
G
G
C
The
modeling,
you
can
see
the
slide,
it's
an
attribute
that
says
the
network
element
is
virtual,
which
and
I
think
if
other
we
can
also
have
a
type,
and
then
we
can
say
okay,
this
is
the.
There
are
different
type
of
network
element
and
we
can
export.
We
can
find
the
physical
and
then
you
can
have
a
different
type
of
network
elements
of
the
network.
Inventory
I
mean
there
is
always
a
way
to
extend.
C
D
Probably
one
thing
that
would
would
help
would
be
to
Define
what
is
a
software.
It
is
just
a
virtual
node
or
it
includes
also
something
else,
and
because,
if
it's
just
a
virtual
node,
it's
probably
one
type
or
or
or
or
or
better
one
type
of
node.
If
it's
something
more,
maybe
you
need
something
something
different.
But
let's,
let's
move
on
with
the
with
the
queue
we
still
have,
Olga
and
Rob.
I
Hi
thanks,
everybody
I
have
two
comments,
and
one
related
both
are
related
to
the
some
parts
of
the
discussions
that
we
already
had.
The
first
one
is
about
the
the
top
level
component
that,
if
you
are
talking
about
a
virtual
Network
functions
versus
physical
Network
functions,
I
do
believe
having
some
kind
of
Common
Core
model
there
that
incorporates
the
two
that
could
be
added
through
augmentation
is
better
than
starting
from
physical.
I
Only
because
these
are
the
kind
of
two
different
things,
especially
if
you
think
in
terms
of
how
you
are
presenting
them,
and
you
know
how
they're
related
they
could
exist,
one
beside
the
other
and
in
some
cases
you
may
want
even
to
abstract
them.
So
you
don't
care
whether
they're
with
virtual
or
physical.
If
we
are
talking
about
software
again
and-
and
they
agree
with
them
well
in
terms
of
software
versus
virtual
Network
function,
there
may
be
need
for
augmentation
there,
but
that
doesn't
mean
that
the
top
level
one
is
just
physical.
I
It
could
be
physical
or
virtual.
Next
comment
is
similar
to
Alex's
about
the
location.
You
know
having
location
augmenting
physical
inventory,
I
would
say,
I'm
not
saying
that
it's
not
the
the
best
way.
I
think
we
need
more
discussions,
how
to
model
the
locations
in
terms
of
how
it
relates
to
Paul
topology,
how
we
will
kind
of
connect
to
the
digital
map
and
how
will
it
will
be
used
in
digital,
so.
I
C
On
the
hardware,
physical,
entertainment
and
Hardware,
but
the
definition
will
be
General,
I
mean
it's
like
a
it's
like
a
type.
You
know
you
have
a
type,
and
then
you
say:
okay,
you
have
any
derived.
For
example,
you
can
say
the
network
element
is
physical,
then
I
know
all
the
details.
Other
other
identities
can
be
added
in
the
future
and
then,
when
you
have
a
new,
a
new
type
of
network
element
is
just
a
matter
of
defining
a
new,
a
new
identity
and.
I
Then
we
are
going
from
specific
and
augmenting,
you
are
not
going
generic
like
other
standards
would
go.
You
are
going
from
mentosi
perspective,
which
is
older
than
the
kind
of
seed
perspective
or
Etsy
perspective,
or
an
F
perspective.
That
is
talking
about
generic
things
like
resources
and
then
they
could
either
be
physical
or
logical
or
virtual.
You
know
so
you
are
going
from
if
you
say
that
the
top
level
is
physical,
then.
I
I
C
C
D
C
There
will
be
the
list
of
network
elements
and
the
list
of
components,
and
but
no
no,
no
type
I
mean
there
will
be
just
a
basic
entity
for
the
type
of
network
element
for
the
type
of
component,
and
then
you
can
have
the
other
inventory,
where
you
define
the
hardware
components
and
eventually
other
specific
augmentations,
and
there
will
be
the
softening
language,
refinance
software
components
yeah.
Well,
you
have
something
which
is
not
implementable
as
a
loan.
C
D
J
So,
just
because
a
contributor
I'll
try
and
keep
my
comments
very
quick,
because
I'm
conscious
of
time
moving
forward,
I.
Think
for
me
one
thing
that
I'm
hearing
these
discussion
is
there's
some
confusion
about
terminology
in
terms
of
what
does
physical
versus
Hardware
mean?
Does
that
include
virtual
devices
and
things,
and
also
what
is
meant
by
software
again?
J
The
other
aspect
of
this
I
think
is
interesting.
Is
you
look
at
the
open
conflict
model
which
I
appreciate
it's
a
device
level
model,
not
a
network
level
model.
They
have
a
lot
of
flexibility
as
to
how
components
are
put
together
and
how
you
sort
of
have
components
of
sub-components
both
at
the
hardware
level
you
can.
You
can
do
it
down
to
like
the
list,
the
RPS
and
the
line
cards
under
a
network
device,
but
the
same
at
the
software
level.
J
You
can
also
list
those
software
packages
and
sub
packages
and
things
as
well.
So,
in
that
model,
suddenly
they
allow
some
flexibility
to
allow
these
components
to
be
delivered
each
other
I
can't
imagine
why
you'd
have
Hardware
under
software
in
that
case,
in
terms
of
like
software
packages,
so
so
I
think
that's
worth
thinking
and
also
the
other
thing
generally
I.
A
Working
group
contributors,
so
I
I,
think
I
can
understand
the
requirements
that,
for
the
hardware,
owning
use
cases
from
the
operator's
perspective,
but
I
I'm
thinking
that
have
you
ever
considered
the
filter,
magnesium,
like
the
top
XPath
or
subtree
filter
that
used
to
get
the
hardware
only
data
instead
of
instead
of
moduleing,
the
software
and
Hardware
separately.
You
can
still
model
them
together
by
use
some
filter
mechanism
to
fill
out
the
hardware.
Only
that
I
think
that
might
be
okay
for
the
hardware.
Only
cases.
D
Thank
you.
I
would
say
that
the
technically
it
works,
but
I
I
would
say
that
we
are
more
ready.
We
are
at
the
more
advanced
stage
if
we
tackle
just
the
the
hardware
part
first
and
then
we
go
the
documentation
later
from
a
technical
point
of
view.
I
agree
with
you:
I,
don't
see
any
big
difference,
but
I
mean
given
that,
from
another
point
of
view
we
already
have
a
lot
of
good
material
and
we
are
in,
let
me
say.
E
D
D
D
F
F
Sorry
miraka
takes
a
long
time
to
get
turned
on.
Let
me
turn
on
the
mic.
I,
don't
understand
why
so
Tony
Lee
Juniper
Networks
I'd
like
to
bring
up
a
new
topic,
I'm
interested
in
doing
power
management
of
hardware,
and
it
seems
like
this
something
that
could
be
easily
augmented
into
the
models
that
you're
building.
C
D
This
is
also
in
liner
with
the
discussion
that
Alex
and
I
had
a
while
back
on
the
billion
list.
Basically,
for
for
the
green
networking
part,
there
is
a
portion
of
it,
which
is
basically
what
you
can
read
on
on
the
data
sheets,
which
can
easily
be
added
as
an
augmentation
to
the
network
inventory.
The
the
top
the
top
material
here
would.
F
D
Well,
things
are
like
actual
power,
consumption
I'm,
not
sure.
That's
that's
inventory
inventory
again.
The
very
first
thing
that
we
needed
to
do
is
is
some
some
terminology
and
scoping
on
what
is
inventory.
What
is
not?
We
came
into
a
some
sort
of
agreement
on
the
mailing
list
if
I'm
not
mistaken,
that,
eventually
is
what
you
can
read
the
on
on
a
data
sheet,
but
I
mean
that
was
just
at
the
very
early
stages
of
our
discussion.
That
can
be.
That
can
be
changed,
but
just
just
to
give
some
some
scope
to
the
discussion.
D
H
D
I
H
If
you
go
to
next
slide,
okay-
and
you
might
remember-
this
is
like
from
previous
IDF
meetings
and
many
of
the
points
that
has
been
highlighted
already
here
on
the
session.
We
have
been
somehow
addressing
that's
why
we
believe
it
will
be
good
to
keep
as
a
reference
the
the
draft
as
well
from
the
best
practices.
H
And
if
you
see
on
the
diagram
of
the
life
cycle
management,
we
have
been
looking
at
a
different
states
and
what
we
could
consider
part
of
the
discussion
that
has
been
here
on
the
inventory,
the
location,
that's
the
placement
of
that
Hardware
or
software.
It
is
one
of
the
use
cases
we
are
looking
for
on
the
our
premise
statement
proposal
entitlement
and
we
call
we
don't
call
it
Hardware
or
software
as
we
call
it
is
an
asset
and
we
highlighted
that
an
asset.
H
It
is
any
hardware
or
software,
even
a
component
right
and
even
the
association
of
those
components
that
my
bring
another
asset
and
with
an
extent
to
the
concept
of
a
service
when
there
is
a
kind
of
a
solution
built
from
that
Network
offering
right.
But
our
purpose
on
Almo
is
basically
the
the
use,
since
we
know
what
we
have
to
to
get
into
our
Network,
and
the
next
step
is
how
we
are
going
to
use
it.
We
have
to
associate
the
license
or
an
entitlement
we
have
to
enable
certain
features.
H
H
We
are
not
looking
at
the
inventory
itself
as
we
can
consume
and
we
prove
and
I
want
to
make
another
call
out
to
the
appendix
be
part
of
the
of
the
draft,
where
we
give
a
practical
example,
and
thank
you
to
janlin
blood
for
the
exercise
that
we
did
on
the
augmentation.
We
can
augment
adding
modules
that
will
add
attributes
on
top
of
what
we
could
consider
a
hardware
based
module
or
a
software-based
module,
or,
as
we
were
proposing
initially
an
asset
based
module.
H
If
you
go
to
next
slide,
Manila
and
I
just
want
to
highlight
the
the
what
is
important
to
consider
as
part
of
the
work
of
IB
working
group
and
I
mentioned
about
asset
right.
We
try
to
combine
the
concept
of
fireworks
software
for
even
for
Hardware,
also
well
being
virtual
or
physical
and
even
a
service.
There
is
an
easy
extension
of
the
attributes
that
we
want
to
extend
from
the
basic
module
and
the
augmentation
on,
or
the
consumption
of
those
modules
that
will
be
part
of
a
basic
inventory.
H
It
is
possible
within
the
the
mlmo
and
some
practice
that
could
be
taken
for
a
new
process.
I
believe
that
might
be
part
of
the
outcome
of
the
ivy
working
group
with
the
reducing
the
word
that
we
also
have
done
and
I
mentioned
before.
We
don't
refer
based
on
the
feedback
we
got
in
the
officer
working
group.
H
You
can
go
to
next
slide.
This
is
our
proposal
for
our
next
IDF
right
in
the
meeting
to
work
on
the
coming
weeks,
but
we
will
release
a
new
version
of
Almo
based
on
the
IV
working
group
and
a
new
version
for
a
data
model
for
Almo
based
on
the
dmlmo,
and
that
already
is
is
theirs.
But
this
will
be
as
part
of
our
proposal
for
the
next
IDF
session.
H
We
would
like
to
come
with
the
collaboration
from
the
teams
as
well,
and
this
is
kind
of
how
we
started
a
couple
of
years
ago
ago
with
the
mlmo
and
the
main
characteristics
that
we
have
been
working
on
since
then.
And
hopefully
you
have
the
the
summary
of
what
we
are
also
trying
to
achieve
for
next
ideas
to
present
a
more
solid
Proposal,
with
a
better
description
on
the
use
cases
as
well
on
the
Almo.
And
this
is
the
new
version
for
the
data
models
on
Almo
for
IB
working
group.
H
D
E
D
E
D
D
The
software
part
of
the
opsa
draft
remaining
in
the
draft
that
could
be
adopted
as
the
software
Network
inventory,
the
licenses
for
the
licenses
part
we
could
adopt
the
Almo
draft
I,
don't
know
if
I
mean,
as
Marisol
said,
that
there
is
more
than
licenses
in
in
Almo
I,
don't
know
if
that
could
be
split
or
we
change
licenses
into
something.
That
is
something
more.
If
I
currently
on
the
student
entitlement
is
a
licenses
plus
something
more,
for
example,
the
power
consumption
thing
would
fall
into
into
entitlements.
D
If
no
one
has
a
big
concerns
against
the
split
I
think
that
the
the
the
the
way
is
pretty
straightforward
and
we
can
adopt
all
the
documents
and
reshuffle
the
content
according
to
this.
Drawing
probably
the
only
thing
that
remains
to
be
discussed
is
the
the
issue
that
Bo
and
Italo
were
discussing
before.
A
J
F
J
I
sort
of
agree
with
you,
I
think
I
think
it'd
be
a
good
idea
to
for
you
to
write
that
proposal
down
on
the
list.
So
it's
sort
of
clear,
what's
been
proposed
here
to
get
reaction.
I
did
wonder,
though,
whether
doing
a
non
my
orders
gone
with
a
non-indictive
show
of
hands
to
see
what
people
think
this
is
the
right
direction
now
might
be
interesting,
but
it's
I
have
it's
like
a
non-binding
vote.
J
D
B
D
D
D
Any
one
of
the
six
that
were
against
it
would
like
to
say
something
now
in
any
case
that
we
are
continuing
the
discussion
on
the
main
list.
We
will
articulate,
we
will
put
down
the
proposal
and
then
we
we
can
have
a
a
better
discussion
there.
But
if
someone
wants
to
say
why
not
now
probably
it
it
could
have.
B
I
I
put
no
I,
I,
didn't
know
exactly
I,
think
I
agree
with
the
overall
philosophy,
but
what
you're
doing
here?
I
don't
I'm,
not
sure
I'm
bored
with
some
of
the
details
like
what
I
mentioned
right,
the
element,
location,
I
still
think,
should
be
separate.
It
should
not
be
augmenting
Network
inventory
again,
there
are
details,
but
I
think
that
is
missing
the
thing
where
I
said
just
as
it
is
depicted
here
right
now,
I
said
we
need
to
have
a
little
further
discussion.
G
Can
you
hear
me
yeah
I
mean
still
the
this
mapping
doesn't
clear
to
me
because
the
I
don't
know
what
the
network
inventory
is
and
like
what
the
network
elementing
is
because
if
I
can
not
understand,
what's
this,
like
this
mapping
means
reason
why
I
still
needs
more,
like
term
clearly
precise
term
definition,
to
make
a
decision
yeah.
Please.