►
From YouTube: IETF99-NETMOD-20170719-1330
Description
NETMOD meeting session at IETF99
2017/07/19 1330
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
A
A
A
So
today's
session
would
scheme
amount
tree
diagram,
routing
area
working
group,
update
interface,
module
update
mounting
this
at
the
pier
mount
document.
Alex
is
actually
in
the
room
next
door,
so
we
might
have
to
be
flipping
the
last
the
yang
catalog
and
Alex's
pier
mount
depending
on.
If
you
get
some
time,
I
think
our
secretary
Michaels
kind
of
ping
him
when
his
time
so
I
was
coming
up,
so
hopefully
he'll
be
coming
in
time,
but
just
in
case
would
might
be
flipping
this
to
and
that's
just
we
don't
need
to
that.
C
Etherpad
show
the
link,
so
we
really
could
use
some
more
people
on
etherpad.
This
links
a
little
hard
to
use
that
it's
best
just
go
to
the
last
link
to
the
tools,
page
tools
that
ITF
that
org
slash,
WG,
/,
that
mod
and
then
click
on
the
agenda,
and
you
can
get
to
do
the
pad
that
way.
Click
on
minutes
minute,
sorry
and
please
join
in.
We
only
have
a
few
people
on
be
very
helpful
to
join
in
add
something
correct
something
we
would
appreciate
it
if.
E
E
E
So
this
palm
tree
references,
we
have
discussed
a
tourist
several
times.
So
let
me
just
review
the
motivation
for
that.
First,
there
there
is
an
agreement.
As
you
know,
we
have
two
ways
of
defining
amounted
schema.
One
is
so
called
in
line
that
basically
exists
an
embedded
yang
library
for
defining
the
schema.
So
there
is
an
agreement.
I
would
say
general
agreement
in
the
working
group
that
this
in
line
rate
of
defining
the
scheme
mounted
schema,
will
be
really
relatively
simple
and
so,
for
one
day
there
should
be
no
escape
from
so
called
mount
jail.
E
So
no,
my
references
are
possible
in
this
case.
However,
further
use,
kheema
method
of
defining
the
the
mounted
schema
as
it
turns
out.
It's
often
useful
to
be
able
to
reference
things
in
the
parent
data
tree,
especially
in
XPath.
Expressions
like
like
must
statements,
but
also
in
leaf
ref
references,
for
example.
So
here
is
an
example
coming
basically
from
the
network
instances
draft-
and
maybe
it's
not
the
current
revision
of
the
tree
above
the
idea
is
basically
the
same.
E
So
in
the
case
of
Network
instances,
as
you
can
see
from
the
data
tree,
we
have
a
list
of
interfaces.
Let's
go
Bob,
it
means
that's
shared
by
all
Network
instances,
whereas
routing
configuration
routing
stuff
and
other
things
are
specific
for
each
Network
instance,
but
of
course,
from
a
routing
configuration
we
often
need
refer
to
interfaces,
and
so
for
this
purpose
we
need,
if
it's
set
up
as
it
is
in
the
ni
draft.
E
We
have.
This
mounted
schema
for
a
rare
Network
instance,
and
we
need
to
refer
to
that
global
list
of
interfaces.
So
for
this
purpose
we
need
some
way
of
because
the
normally
the
list
of
interfaces
wouldn't
be
accessible
inside
the
mountains.
You
know
we
need
somebody
how
to
escape
from
the
mount
jail
and
the
mechanism
that's
currently
proposed
in
the
graft
is
to
use.
So,
as
I
said,
it's
only
for
the
you
schema
a
thought
of
defining
the
Mountie
schema
so
inside
the
u
schema
list,
which
is
state
data.
E
These
expressions
have
to
result
in
in
or
each
of
the
expressions
should
result
in
a
node
set
in
terms
of
xpath
1.0,
and
then
a
union
of
these
node
sets
is
taken
and
for
the
purpose
of
evaluating
XPath
expressions
inside
the
mounted
three.
These
resulting
the
union
of
the
non
set
is
added
to
the
array
level:
three,
which
means
that
from
XPath
expressions
and
he
fresh
and
so
on,
we
can
refer
to
selected
selected
notes
from
the
parent
tree.
There
are
some
technical
points,
of
course,
about
expert
evaluation.
E
So
currently
the
context
note
for
this
plan.
Reference
is
the
root
of
the
parent
tree,
and
one
thing
that's
somewhat
annoying
is
that
we
have
to
define
or
specify
the
namespace
declaration
that
XPath
requires.
So
this
is
done
basically
inside
the
state,
a
terrifying
defining
defining
the
mounted
schemas.
So
this
this
mapping
from
prefixes
to
main
spaces
is
done
there.
E
That's
something
that
need
me
to
be
added
to
those
state
data
I
have
to
then
emphasize
that
this
is
only
so.
We
snow
tower
only
available
used
for
expert
evaluation,
which
means,
for
example,
that
these
parent
3
notes
are
not
available
to
protocols
like
net
conf
or
restaurant.
Only
for
XPath
evaluation
and
each
time
an
expert
evaluation
is
performed.
F
I'm
just
wondering
how
this
reference
is
different
from
bind
and
I
named
the
friends
that
we
have
in
in
the
interfaces
to
associate
those
with
with
a
particular
ni.
Here.
It
seems
like
from
within
the
NIV
out
of
referencing
the
interfaces
how
this
is
different
from
binding
and
ni
named
attacked.
Well,
as.
E
Far
as
I
remember,
this
binding
is
done
in
the
parent
tree,
so
essentially
forever
interface.
You
can
specify
that
this
interface
is
bound
to
two
specific
Network
instances,
but
this
is
about
XPath
expression
inside
the
mounted
view
right.
So
we
have
some
beta
model
for
routing
for
a
routing
protocol,
for
example,
this
yang
will
you
by
itself
doesn't
know
anything
about
network
instances.
It
could
be
used
for
standalone
or
just
no
problem,
but
this
theta
model
may
refer
to
interfaces
so
in.
E
If
we
have
networking
instances,
then
of
course
we
need
to
somehow
get
outside
of
the
mound
jail
and
be
able
to
refer
the
global
list
of
interfaces.
I
will
have
an
example
iterate
with
this
bind.
So
what
this
means
here,
for
example,
this
example
means
that
from
the
as
you
can
see
here,
we
will
be
able,
after
this
from
the
mounted
tree
from
the
Network
instance,
we
will
be
able
to
refer
to
anything.
That's
inside
the
interface
interfaces
container,
so
all
interfaces,
no
matter
what
what
network
instant
they
are,
they
are
bound
to.
So
that's.
E
F
E
E
F
E
E
With
another
level
of
complications,
of
course,
it
would
be
possible,
but
because
of
course,
if
we
have
several
routes
that
it
can
be
used
for
evaluating
this
current
reference
expressions,
we
have
to
specify
which
we
have
in
mind
and
it
becomes
like
a
tricky
Sola.
I
would
personally,
but
basically
I
I,
don't
think
that
it's
very
sensible
to
define
many
levels
of
scheme
amounts.
So
what
we
are
addressing
here
basically,
is
this:
the
is
the
network
device
model,
a
nice
and
a
nice,
and
that's
about.
C
Eleni
and
ni
model,
if
you're
thinking
about
the
case
where
you
have
a
physical
device
that
you
then
put
into
one
of
these
logical
systems
or
an
LNA
and
then
from
there
go
into
verbs.
It
turns
out
that
when
only
you
would
have
two
separate
instances
of
exports-
and
you
wouldn't
have
to
do
this-
it
wouldn't
turn
into
a
parent
reference
of
a
parent
reference.
So
we
didn't
weren't
from
the
user
standpoint.
We're
not
envisioning
needing
that
right
now,
even
though
I
think
you
can
do
it
with
a
recursive
solution,
that's
available.
C
E
Think
we
discussed
this
last
time
and
so
basically
from
the
standpoint
of
expert
evaluation,
you
can
have
anything
so
you
can
have
both.
So
it
will
evaluate
to
something
but
I
believe
in
the
current
revision.
There
is
some
is
some
warning
that
this
shouldn't
should
be
done
so
as
soon
as
you
use
interfaces
in
the
parent
schema,
and
you
want
to
use
this
part
reference
mechanism,
it's
it's
not
advisable
to
use
interfaces
inside
that
mounted
and.
C
Keep
in
mind,
this
is
an
implementation
time
thing.
So
if
someone
can
figure
out
an
implementation
that
makes
sense
in
their
implementation,
that's
their
choice,
but
no
one's
forced
to
do
that
may
not
really
make
sense
to
do
it,
but
if
you
think
it
does
it's
your
box,
you
get
a
code
it
the
way
you
want
to.
I
E
E
Okay,
so
I
already
commented
on
that
example.
So
let
me
so
again
that
this
particular
example
means
that
interfaces
are
available
for
for
every
network
instances,
but
we
do
not
really
discriminate
between
interfaces
that
are
bound
to
that
network
instance
and
and
others,
but
basically
it's
the
same
way
how
it
works
with
used,
say
an
augment
instead
of
just
amount
mechanic
tonight.
A
E
Issues
here
because
they
may
they
may
be
erased
later
and
I-
would
like
to
ask
all
potential
office
of
modules
using
scheme
amount
to
consider
what
it
means
for
their
later
models.
So
one
is
about
that
context,
known
that
used
for
parameters
and
evaluation
and
then
another
another
option
is
to
define
it
and
references
insight
directly
inside
the
mount
win.
Definition
I
will
have
more
to
say
about
that
later,
but
let's
go
through
that
context.
Note
so,
as
I
said.
E
D
E
For
relay
this
restriction
that
only
interfaces
that
are
bound
to
that
Network
instance
will
be
available
for
expert
evaluation
inside
that
particular
Network
instance.
So
that's
of
course
nice,
but
on
the
other
hand,
I
believe
it
just
adds
another
level
of
complexity
to
what
we
already
have.
So,
if
you
consider
that
these
parent
references
are
used
for
in
run
expressions
inside
the
mounted
schema,
that
means
that
we
have
some,
even
the
the
mounted
ski
not
somehow
depends
on
suppose
on
stuff,
that's
in
in
the
parent
like
a
tree.
E
J
Ac
Linda
Cisco
Systems.
No,
no
doubt
this
would
be
useful.
I,
don't
think
you
know
independent
of
if
and
when
this
isn't
integrated
I.
Don't
think
you
should
call
it
a
constant,
a
context.
Node
I
mean
that
really
threw
me
off,
and
then
you
explained
what
it
is
and
I
said:
oh
that's
what
it
is.
Maybe
you
could
call
it
parent
reference
filtering
or
something
like
that.
Instead
of
context,
no
well.
E
As
as
long
as
as
we
are
using
XPath
for
these
purposes,
I
think
it's
appropriate
to
use
the
terminology
of
XPath
and
basically
context
note
for
every
X
path.
Expression
is
where
the
expression
is
supposed
to
start
right,
so
so,
where
from?
If
you
have
relative
erotic
part,
so
where
this
erotic
path
start
and
in
our
case
it
means
because,
in
the
current
situation,
we
get
the
same
results
of
of
this
plant
reference
evaluation
for
all
Network
instances.
Whereas
if
we
have
this
route,
as
the
context
note,
we
can
really
have
have
different
results.
E
A
E
The
second
open
issue:
it's
again,
we
have
some
pros
and
cons.
The
idea
is
here
because,
as
you
saw
currently
the
front
reference,
XPath
expression
is
defined
inside
the
state
beta
that
define
the
mounted
schemas
using
that
you
schema
method
here
in
this
proposal
it
would
be
different
and
it
would
mean
that
we
would
have
another
yang
expansion
called
parent
reference
say
that
will
define
this
XPath
expressions
inside
the
mount
point,
definition
that
appears
in
in
yang
modules.
E
So
of
course
the
advantage
would
be
that
in
yang
module
over
they
have
some
namespace
mappings
and
namespace
declarations.
Mapping
of
prefixes
to
to
namespace.
You
are
ice.
So
in
this
case
we
wouldn't
need
that
namespace
prefix
effect
definitions
separately
instead
Attah
that
could
be
inherited
from
the
yang
module
where
the
mountain
statement
appears.
But
there
are
drawbacks
also,
first,
because
we
use
this
mountain
expansion
both
for
in
line
and
use
schema
method
and,
as
I
said,
we
want
to
use
these
point
references
only
for
the
you
schema.
E
K
K
K
E
G
E
Is
true,
but
I
would
say
that
if
you
do
this,
so
you
probably
so
the
author
of
the
plant
module
has
to
envision
somehow
what
the
contents
of
the
multi-schema
is
going
to
be.
So
whether
a
schema
is
mounted
that
might
make
use
of
of
interfaces
in
this
space
right.
So
now
you
are
either.
Basically
this
means
that
the
author
of
the
print
module
can
immediately
tell
I
want
to
make
this
available
to
all
mounted
steamers.
So.
G
E
G
E
E
C
I
mean
that
gets
into
the
film
the
philosophical
discussion
we
had
the
other.
You
know
the
last
meeting
about
how
we
do
extensions.
Do
we
do
incremental
or
wholesale
and
I'm,
not
sure
I
really
want
to
go
there
right
now,
but
what
I'll
say
is
I
think
it
is
fair
to
say
that
we
can
consider
this
when
we
start
talking
about
design
time
amounts
and
that
this
is
just
one
form
of
it
and
it,
and
it
makes
sense
to
do
design
time
all
together,
rather.
C
E
So
if,
if
an
implementation
doesn't
know
about
mark
mount
point
that
there
are
other
problems
but
I
mean
that
it
could,
for
example,
if
it
understands
mount
point
but
does
not
understand
parent
reference,
it
would
mean
that
evaluation
of
XPath
expressions
inside
the
mounted
schema
or
inside
that
they
tell
that
belong
to
the
monkey
schema
could
give
different
results
because
in
one
case
you
you
have
these
extra
notes
available
in
the
mounted
data
and
in
another
case
these
won't
be
available.
So
XPath
expressions
could
give
different
results
right.
So
that's
not.
Okay,.
E
G
E
I
A
Okay,
so
just
any
more
flights.
Okay,
so
both
open
issues
have
preferred
solutions
that
would
verify
on
list
and
then
we
can
potentially
take
this
last
call.
But
first
I
need
to
ask
the
working
group
there's.
Does
the
work
group
believe
this
document
ready
for
less
call
and
and
please
ready
for
Lesko,
okay,
so
we'll
look
forward
to
an
updated
document
once
these
issues
are
resolved
and
actually
do
have?
One
question,
though:
there's
in
a
net
conf
working
group,
there's
the
young
library
discussion
and
in
that
maybe
there'd
be
relationship
to
scheme
amounts.
E
A
E
Currently,
there
is
no
dependency
because
we
use
another.
There
is
enough
young
library
insight
the
schema
right,
so
it
means
that
we
can
use
different
revisions
of
the
same
module
is
in
the
parent
schema
and
in
the
mounted
schema
I,
don't
know
it's
good
thing
or
not,
so
I
would
actually
prefer
to
have
everything
in
one
Alma,
you
that
are
youth
throughout
the
system
in
one
young
library
and
then
just
refer
to
it
from
use
key
moments.
Okay,
good.
C
E
But
I
think
you
wouldn't
mind
waiting
until
we
have
a
complete
solution.
You
know
you
also
have
the
discussion
about
adding
that
module
set
ID
yeah,
so
this
this
is
just
because
we
had.
We
have
different
different
sets
of
modules
in
different
language,
so
we
create
only
one
library.
You
could
just
have
one
module
set
ID
and
then
it
would
be
just
easier
to
understand
what
the
data
model
really
is.
Then,
if
you
have
to
somehow
go
from
one
place
to
another
written
of
a
young
library
and
so.
C
C
Say
is
chair:
if
we
have
a
document,
that's
ready
to
go
and
go,
we
shouldn't
wait
for
an
individual
draft
or
even
a
0-0
working
group
draft
to
get
our
work.
We
we
should
make
progress
and
if
we
need
to
come
back
later,
we
have
to
come
back
and
revenue.
There's
a
lot
of
discussion
about
working
groups,
doing
things
faster,
getting
models
out
faster
and.
E
C
Hi
I'm
Lou
burger.
This
is
a
document
that
I
put
together
really
starting
out
early
as
editor,
meaning
I
was
taking
other
people's
work
and
just
putting
them
into
a
document,
and
it
was
Martin's
work
on
how
to
represent
trees.
Since
then
I've
actually
say
I've
become
a
co-author,
so
I
wrote
a
whole
bunch
but
I'm
presenting
largely
because
Martin
isn't
here
so
previously
we
we've
talked
about
this
last
time.
We
had
a
problem
where
we
had
tree
representations
everywhere
and
had
to
figure
out
what
was
different
in
each
document.
C
So
we've
had
two
revisions
since
the
last
meeting.
The
first
was
to
publish
the
working
group
version
0-0
exactly
what
we
presented
in
the
previous
meeting,
and
then
we
have
zero
one
which
did
what
we
said.
We
planned
to
do
I,
philosophy
ting,
which
is
still
in
a
whole
bunch
of
sections.
There
is
still
one
section,
I
mentioned
a
moment.
That's
missing
the
other
thing
we
did
is
we
figured
it?
We
have
a
proposal
on
how
to
represent
scheme
amount.
C
So
I
think
I
went
through
most
of
these
pieces.
There's
a
little
detail
here
in
interest
of
time.
I'm
just
gonna
highlight
the
one
piece
that
we
haven't
thought
about,
or
we
haven't
discussed
or
documented
is
how
to
represent
extensions
right
now.
They
don't
show
up
in
some
tools.
I,
don't
know
about
all
tools,
they
don't
run
all
tools,
but
they're
generally
not
shown
in
the
tooling,
but
we
should
think
about
whether
or
not
we
want
to
represent
them
in
documents.
K
Rob
Wilson
one
client
should
provide
some
on
the
alias
X
is
used,
both
the
deprecated
and
X
for
our
pcs
in
actions,
I
think
it
might
be
worth
checking
and
what
role
with
deprecated
output
to
check
that's
not
too
confusing.
It
might
be
so
just
one
thing
it's
worth
checking,
if
you
can
repeat,
you
have
a
specific
proposal.
K
C
C
Is
there
something
better
there
and
what
we
sort
of
felt
and
we
read
the
consensus
of
the
room-
is
it's
better
not
to
change
something
unless
there's
a
real
need,
yeah
just
so
that
we're
consistent
with
the
existing
published
documents
and
and
and
things
people
are
familiar
with
yeah,
so
I
I
think
with
the
proposal
of
what
do
we
change
it
to
is?
Is
it
worth
it?
Yes,
our
grantees.
C
C
C
There's
one
other
bit
in
the
schema
definition.
You
can
define
whether
a
schema
is
mounted
read-only.
How
do
we
represent
that?
Well,
we
just
use
ro
or
B
for
the
module.
That's
right,
so
there's
no
extra
flag.
It's
just
that,
even
though
the
natural,
if
in
its
normal
mount
point,
would
be
our
W
in
the
in
the
only
case
or
config
equals
false,
we
would
just
say
ro
there.
C
E
I
think
that
here
I
think
this
is
not
possible
to
to
say
that
yeah,
maybe
in
some
special
cases,
but
in
general,
if
you
have
this
scheme
amount
references,
it's
really
about
instant
later
so,
whereas
this
tree
describes
the
schema
right.
So
in
general
it
really
depends
on
the
evaluation
of
the
reference
XPath
expressions.
So
it
could
happen
not
not
in
the
example
that
that
I
gave,
of
course,
because
it's
all
the
same.
E
H
C
That's
not
something
that
you
would
see
it
at
design-time
yeah,
but
we
do
believe
that
this
goes
to
the
question
that
was
asked
in
the
scheme
amount
discussion
of
if
I'm
a
vendor
and
I
want
to
relay
to
my
customers.
What
it
is
that
my
my
schema
really
looks
like
we
think
that
there's
gonna
be
this
representation
and
I
think
we
have
that
with
that
appropriate
caveat
in
the
document.
If
there
isn't
enough
text
around
that,
we
should
we
should
improve
the
text
so.
C
So
you
know
this
might
be
a
little
forward-looking.
It
might
be
a
limited
use
case
right
now,
but
we
think
I
think
it's
worth
including
it's
a
proposal.
If
the
working
group,
some
reason
doesn't
want
us
to
include
it,
we
can
remove
it.
You'll
see
that
we're
going
to
use
it
in
several
cases.
With
the
discussing
the
examples
of
lne,
you
know
Ellen
and
and
Network
instance,
so
we're
already
making
use
of
this
in
our
documents.
In
the
example
cases,
okay.
C
G
C
Of
a
an
actual
module,
with
its
shown
with
an
augmentation,
the
yellows
and
augmentation,
with
a
small
olives
and
playa
and
here's
the
math
one.
So
the
thing
you'd
only
thing
you
would
see
in
an
actual
schema
in
an
actual
module
definition
would
either
not
cry.
You
wouldn't
see
anything
ever
danger,
so
only
the
NP,
which
would
show
up
in
from
schema
data,
not
from
schema
information
in.
G
M
C
C
C
Should
we
put
comments
in
the
trees,
the
alot
of
comments
of
the
trees,
that's
that
actually
hasn't
come
up
before
or
at
least
in
the
part
in
my
thinking.
Well,
that's
it.
If
someone
would
like
to
propose
how
to
take
comments
from
the
tree,
which
I
imagine
would
come
out
of
description
and
I'm,
not
sure
if
you
just
what
you
would
do
there
written.
N
A
quick
comment
on
comments:
they're,
really
helpful
everywhere.
I
know
it's
extra
work
to
try
and
work
out
how
to
put
a
comment
in
there.
But
if
you
don't
put
a
comment
in
someone's
gonna,
just
try
and
shoot
on
a
comment
in
any
way
they
just
I
kind
of
assumed
comments
were
available
in
trees,
but
nobody
use
them.
E
But
since
these
two
diagrams
are
usually
created
by
tools,
that
would
mean
that
we
need
to
have
some
some
way
home
to
express
this
comment.
Gangmo
News
and
my
second
objection
to
this
is
that
we
already
these
three
diagrams
of
the
lines
are
quite
long,
so
we
fear
the
types
and
so
on
and
if
we
add
some
comments,
if
you'll
just
run,
run
off
the
right
margin,
so
I
don't
know.
Of
course.
If
in
any
presentation
one
can
usually
add
some
some
comments
in
another
font
so
that
it's
clear
but
I,
don't.
C
Know
yeah
I,
actually
I
was
immediately
thinking
about
all
right.
What's
what
what's
the
yang
change
to
do
this?
Do
we
now,
instead
of
just
along
with
description,
we
have
comment
or
do
we
say
the
first
end
characters
of
the
description.
So
if
someone
is
interested
in
comments,
I'd
say
send
a
proposal
to
the
list
talk
to
Martin
bye,
let's
see
if
he
has
any
opinions,
but
if
anyone
in
the
room
or
on
the
list
has
an
opinion,
please
send
a
proposal
and
that
we
can
consider
it
as
the
working
group.
O
O
C
C
We're
we
going
next
we're
gonna
fill
in
the
TV
DS
I
believe
the
only
thing
is
the
extension.
We
really
would
like
confirmation
from
folks
on
the
tree
representation,
including
the
schema,
mount
representation.
Please
take
a
look
at
it.
Please
send
comments
to
the
list.
This
is
highly
stylistic
and
subjective.
Some
things
are
easy
to
change.
Right
now
likes
the
schema
mount
part
other
pieces
which
have
been
used
for
a
long
time.
They
want
to
resist
change
but
to
make
changes
if
it's
if
it
adds
a
lot
of
value.
C
Please
discuss
this
on
the
list.
We
need
consensus
if
we
don't
get
more
feedback
and
we
make
these
changes
on
extensions.
We
think
we're
going
to
be
ready
for
a
last
call
and
then
maybe
the
last
call
becomes
the
forcing
function.
We
I
don't
have
a
specific
timeline
for
getting
the
extensions
done.
I
would
hope
in
the
next
few
weeks,
but
we
have
vacations
and
things
so
since
that
clash
is
done.
We'll
have
a
proposal
for
that.
One
open
section.
B
C
M
So
you
mention
whether
you
talked
about
the
extension,
so
the
extension
section
is
empty
at
the
moment.
Rekha's
do
the
authors
have
any
idea
what
they
want
to
do.
We
haven't
talked
about
it,
we're
at
a
time
because
I
mean
the
whole
structure
is
according
to
the
nesting
structure
of
data
objects.
Our
pcs
or
notifications
in
the
tree
and
extensions
are
not
supposed
to
add
anything.
H
C
A
P
K
J
J
What
I'm
willing
to
go
to
are
the
three
working
group
documents
or
the
design
yang
routing
design
team
is
working
on
and
where
the
and,
where
we
are
knows,
we
have
two
other
drafts
that
are
non
working
group
drafts.
Well,
I,
guess
one:
the
logical
organization
is
that
working
looked
at,
but
it's
only
it's
kind
of
dated
by
gated
by
the
tags,
which
is
an
individual
draft.
So
I'm
not
going
to
talk
about
those
two
today,
there's
gonna
be
more
work
done
on
those
and
NDMA
next
steps.
J
J
O
Q
There
Madonna
each
on
tags,
because
there
are
some
other
activities
on
where
they
could
come.
Useful
we've
got
another
name
of
a
draft,
it
was
discussed
in
the
ops
area.
So
having
tags,
you
know
for
the
for
the
young
catalog
and
for
the
young
library.
You
know
that
so
that
we
could
put
those
two
works
to
actually
those
works
together.
We
should
make
some
decisions
on
that
part.
J
J
J
One
I
mean
open
issue,
one
on
slide,
six
that
he
talked
about,
that
the
XPath
built
XPath
references
didn't
allow
you
to
specify
context
or
filtering
for
the
XPath
and
finally,
there's
a
lot
of
times
where
we
have
a
given
model,
and
we
know
we
always
want
to
mount
it,
so
we
can
foresee
that
future
work
on
the
design,
timeouts
and
otherwise
in
other.
In
other
words,
you
specify
a
mount
point
in
a
module.
You
also
say
this:
this
model
is
always
mounted
there.
J
We
see
that
as
a
useful
function
and
we're
ready
for
we
feel
we're
pretty
much
ready
for
working.
You
last
call
they're
only
worth
broken
as
a
reminder.
The
end,
the
LME's
these
are
like.
These
are
logical
network
elements.
These
are
like
your
virtual
routers
I,
don't
know,
I,
don't
know
what
they
call
them
on
on
IC
I.
J
Pretty
much
answered
the
aim
doctor
review
at
it
terminology
sessions,
see
I'm
not
going
to
go.
I
won't
go
through
the
example.
One
thing
to
see
here
we
added
a
notification.
If,
when
you
try
to
bind
the
LME
to
an
interest
in
interface
in
the
RFC
7223
interface
list,
if
it
failed,
we
have
a
notification,
for
that
is
just
an
example.
You
see
this,
isn't
he
you
see
in
that
tree?
That's
mounted
stuff,
that's
under
the
amount
point
in
Elleni.
J
There
it
is
just
as
both
routed,
it
says.
Man
is
true
and
it's
just
a
time.
I
won't
go
through
that
again.
We
discussed
in
previous
ayat.
Yes,
so
please
review
this
crap
I.
Think
having
yang
experts
review
it
in
addition
to
the
routing
working
group
would
be
ideal,
since
it
makes
heavy
use
of
the
schema
mount
extension
and
I.
J
There's
gonna
be
more
on
the
L
X
VPN.
That's
we're
gonna
talk
about
that
in
more
detail
tomorrow
in
the
second
afternoon's
session
in
the
best
working
group.
Let's
see
what
else
is
anything
interesting
here,
more
examples
in
appendix
D,
I
think
for
Network
instance.
The
examples
are
really
important.
J
We
have
what
we
did
for,
because
a
network
instance
corresponds
directly
to
an
l2,
VPN
and
l3
VPN,
and
we
have
a
third
type.
It's
a
combination.
You
know
for
your
integrated
router
bridge
of
an
l2
l3
VPN.
We
added
mount
points
for
those
and
we
also
added
an
anti-type
now
the
anti-type
is
is
also
a
choice
where
you
can
put
information.
That's
always
going
to
be
a
augmentation.
You
put
information
there,
that's
always
applicable
to
that
type
of
BN.
Q
C
J
Yeah
like
like
like
this,
is
that,
but
we
have
the
old
style.
This
is
an
MBA,
either
state
I
mean
format
and
hopefully
they'll
they'll.
Go
to
that
with
that
model,
and
here
I
referred
to
these.
These
are
the
well-known
mount
points
that
the
different
types
of
Network
instance
will
make
use
of
and
again
we
added
a
notification
for
the
case
where
you
try
and
find
an
interface
in
your
RFC
7223
interface
list.
Actually,
it's
the
it's.
It's
the
it's
the
one,
the
RFC
for
the
IP
specific
interfaces.
J
Interface
and
that
fails,
then
we
have
a
notification
for
that.
I
forget
that
is
that
RFC
seven-foot
77
or
something
RFC,
7277
I.
Don't
remember,
and
here's
just
an
example
of
the
augmentation
that
l3
VPN
is
going
to
going
to
make
to
ni
type
and
the
fact
that
they
have
that
if
you
have
an
else,
Ruby
PN
you'd
have
a
specific
mount
point
where
you
put
everything
under
there
like,
for
instance,
your
IETF
routing
module
and
your
protocol,
and
they
and
internet
list
control
plane
protocols.
J
J
Yeah,
here's
just
a
few
people
that
work
instance
tree
and
a
lot
of
this.
This
does
not.
You
include
anything,
that's
it's
mounted
right
now
or
augmented.
J
We
already
talked
about
that.
You
think
we
can
get
around
that.
You
see
we're
gonna,
accept
the
limitation
and
let
it
be
an
implementation,
even
even
though
it's
not
enforced
in
the
schema
with
the
with
parent
graph,
an
implementation
could
could
enforce
that.
You
couldn't
access
an
interface
that
didn't
that
didn't
have
a
bind
interface
name
of
the
specific
Network
instance
that
is
referencing
it
and
again,
please
review
this
document
as
we
don't
have.
J
The
yang
call
the
a
experts
in
the
routing
working
group
and
finally,
in
addition
to
IETF
types,
we
have
a
new
draft.
We've
had
a
lot
of
good
feedback
lately,
one
problem
with
this:
this
is
like
your
kitchen
sink
and
every
time
we
think
we're
done.
Somebody
asks
us
to
add
one
more
thing
that
they
think
is
gonna,
be
common
across
a
number
of
yang
modules,
and
so
we've
been
adding
those
one
thing
that
we
did
also.
J
Let's
see,
if
there's
anything
interesting
yeah
you
can
see
with
the
geo
coordinates,
we
don't
feel
those
drafts
are
mature
enough
I'm
on
some
of
those,
and
none
of
them
are
working.
Here's
one
in
list,
the
Dinos
editor
is
one
in
BGP
and
one
in
OSPF
and
is
is
so
we're
gonna
we're
gonna,
pull
that
out
and
put
that
into
separate
modules.
If
we
want
to
go
forward
with
routing
types,
given
that
all
the
routing
models
refer
to
those,
so
we
can
get
that
trubbish.
Tell
me
AC.
Can
you
please
wrap
up.
K
So
there
are
very
quick
update
on
to
draft
in
taste,
extensions
and
science-based
yeah
model
and
also
a
zero
in
new
to
draft
solve
all
the
problems
here,
so
they
won't
be
together.
They
see
since
the
last
ITF
in
the
entire
sixth
enters
draft.
I
got
to
do
on
the
feedback
from
us.
Itf
I've
had
a
young
doctor
brief
from
Andy,
thanks
Andy
to
fix
all
those
things
set
for
Tuesday
in
the
first
city
to
provide
examples,
that's
just
working
to
do
with
exciting.
K
The
second
is:
this
is
a
southern
face
property
which
is
meant
to
be
a
way
of
trying
to
abstract
away
a
list
of
interface
type
dependencies
instead
to
have
the
Colin
property.
Instead,
the
solution
I've
got
in
this.
All
these
to
just
doesn't
really
work
very
well.
It
has
problems.
It's
not
extensible
I
think
I
have
a
better
solution
in
this.
It's
a
2-0
draft,
so
I'm
going
to
present
that
draft.
That
was
the
end
of
this
and
then
wait
for
comments
on
the
walk
with
a
peeping.
K
That's
a
good
idea
to
do,
and
then
also
what
we
do
with
these
drafts.
Would
we
wait
we're
progressing
anyway,
Oh
so
I
said
the
resolution
anyway,
so
I
lost
a
concert
at
the
end
of
that
the
seven
space
feline
model
status
again
the
same.
This
hasn't
had
a
yang
box
review.
But
again
it's
close
to
being
complete.
I
think
is
I
want
to
try
and
get
these
two
models
out
the
door,
so
I
do
v
quicker.
K
The
main
change
are
maybe
some
simplification
to
make
the
structure
of
it
easier,
rather
than
using
a
list
of
tags.
There's
no
explicit
tag
names,
there's
one
certification
stone
that
needs
to
be
done.
That's
based
on
the
I
Triple
E
groupings,
so
once
they're
fixed
and
I
important
that
also
get
fixed,
there's
also
an
issue
raised
by
Vladimir
in
terms
of
compile.
So
that's
one
person
who's
already
trying
to
use
or
is
using
these
models
so
again
not
justification
to
try
and
get
them
out
George.
So
what
have
I
changed
to
fix?
K
This
is
what
it
was
in
the
old
draft
to
see.
This
is
the
elf
three
case,
the
other
ones
they'll
two
similar
there
was
a
list
of
VLANs
with
an
index
into
that
list,
which
is
what's
required,
config
wise,
that's
a
bit
messy
to
actually
have
to
handle.
So
instead,
I've
now
got
two
explicit
tags
out
tag
second
tag,
and
you
could
extend
this
in
future.
Further
packs
out
stack
and
you,
although
I,
don't
actually
expect
that
that's
likely
to
be
required.
K
The
one
quirk
is
still
remaining
is
that
extra
dot
and
cute
a
container
I
would
like
to
get
rid
of
those,
and
that's
the
thing
that
updating
the
groupings
and
I
Triple
E
would
solve
and
I'm
liaising
with
them
to
do
that.
So
once
that's
been
fixed,
the
the
yank
should
look
like
this
and
be
a
bit
simpler
to
use
as
the
plan.
K
S
K
S
F
S
K
Thank
you
so
in
turn,
and
toes
and
interface
properties,
you
see
an
issue
has
already
been
covered
in
the
draft,
so
it's
really
just
a
different
solution
to
those
problems.
Thank
you,
yeah.
So
a
minute,
ok,
examples
of
interests.
Properties
is
a
list
of
six
sorts
of
different
types
of
properties
here
so,
rather
than
having
properties
batted
interface,
I
like
to
describe
parties
like
it's
physical
interface,
with
virtual
southern
space,
point-to-point,
multiple
Ethernet
life,
and
once
you
can
add
these
new
properties
properties
that
is
defined
as
identities.
K
The
question
as
to
who
would
manage
your
own.
These
properties
with
Vienna
would
be
a
more
expert
group
to
need
to
manage
these
and
once
you've
define
those
as
identities,
and
you
can
then
effectively
use
those
in
the
IANA.
I
have
typed
yang.
So,
whereas
today
there's
two
flat
list
of
identities
my
proposing,
but
these
get
extended
to
also
derive
from
the
interface
properties.
Those
particular
interface
types
have
so
it
was
anythin.
Intubating
would
say:
I
have
a
property.
K
Physical
I
have
a
property
that
I
do
multicast
I,
have
a
property
done,
Ethernet
like
or
you
know,
a
lag
interface
might
say
on
the
property
that
I'm
a
virtual
interface
I,
also
support,
multicast
and
also
Ethernet,
like
there's
open
questions
again
as
to
how
to
get
this
mapping
right
and
who
Paula
police's
updates
to
this.
So
this
sort
of
procedural
issues,
but
in
terms
of
solving
the
technical
problem,
I
think
this
works
quite
well.
K
So
it
means
when
you
go
from
having
this
sort
of
augment
the
list
of
like
types
which
isn't
really
extensible,
because
in
future
you
have
a
new
interface
type
defined.
You
have
to
go
back
and
modify
this
young
model.
To
add
that
that's
that
new
needs
face
type
into
that
when
statements
to
pick
up
the
same
leafless
own
namespace.
Otherwise
you
have
to
have
perhaps
the
same
efinitely
leaf
name
in
the
new
namespace
from
you
module.
So
that's
what
it's
trying
to
solve
and
instead
this
is
what
it
turns
into.
K
I
K
And
so
my
real
questions
here
is
and
who's
who
would
manage
this,
and
is
it
really
Ayane
would
manage
this
I
think
I
speaking
to
yoga?
No,
it's
just.
That
might
not
be
a
good
idea.
So
in
summary,
who
owns
it?
Who
manages
this
stuff
and
I?
Think
the
final
properties
is
backwards
compatible.
You
had
new
ones,
I
think
adding
them
to
interface.
Types
is
also
backwards,
compatible,
changed
thing.
We
could
also
release
the
existing
drafts
with
defenses
and
harddrive
types
and
then
I'm
using
twice
properties
at
a
time.
K
Q
It's
more
of
a
comment:
I
would
prefer
to
finish
it
quick
sorry,
Dan,
Bogdanovich
I
would
prefer
to
finish
more
quickly
and
then
revise
later
yeah,
the
basic
you
know
the
skeleton
of
the
draft
is
their
looks.
You
know
that
it's
that
it
provides
another
functionality
that
is
being
looked
for
so
now
to
put
in
all
the
types
and
everything
else
what
is
needed.
We
can
figure
that
out
as
we
go.
C
So
is
there
interest
in
this
final
draft
being
taken
into
the
working
group
they
do?
Does
the
working
group
think
it's
useful
functionality,
and
is
this
a
good
place
to
start,
and
this
please
for
those
of
us
with
that?
So
that's
that's.
A
reasonable
number,
I
think
yosity.
How
many
people
have
read
the
draft,
so
it's
actually
less
than
the
people
who
think
that
it's
useful
functionality-
and
this
is
a
good
place
to
start.
Okay.
Thank
you.
S
So
Clemente
Parsons
again
I
would
reiterate
that
so
I
have
not
read
the
draft,
so
I'll
preface
it
with
that,
but
it
sounded.
But
from
what
you
presented.
This
has
impact
on
the
usage
of
the
VLANs
and
to
the
sub-interface
model,
and
you
have
this
alternative
proposal.
I
think
we'd
like
to
understand
that
in
802
da1
and
what
your
proposals
are
so
either
an
informal
liaison
or
format
that
was
the.
C
C
K
C
G
So,
hey
everybody,
I'm,
Alex
creme,
so
I
wanted
to
talk
about
a
yang
mount,
and
this
is
actually
in
a
draft.
It
has
been
in
the
air
for
a
while,
it's
basically
the
autumn
and
I'm,
actually,
basically
there's
their
holes,
ski
mamantov,
work
and
so
forth.
But
actually
there
was
another
mount
related
trap,
and
this
concerns
this.
One
problem
that
they
are
solve
is
actually
slightly
different.
G
That
work,
particularly
because
they
use
cases
for
the
original
young
man
also
do
remain
balanced
and
made
more
pressing
in
the
sense
that
application
is
to
require
visibility,
points
it's
data,
it's
not
just
essentially
it
on
the
server
itself,
but
on
other
servers,
also
in
the
same
seven
busy
their
various
various
use.
Cases
related
to
that
you
actually
outlined
in
the
draft
and
the
site
for
this
or
this
later
as
well.
G
Okay,
so
busy
just
in
terms
of
comparison
between
the
yang
mouth
and
the
scheme
amount,
so
basically,
it
is
yang
mode
is
very
much
to
provide
visibility,
additional
visibility
to
data
using
different
access
paths,
it's
not
to
reuse
existing
definitions
and
insert
them
in
there
in
a
tree,
and
so
I
see
the
analogy.
There
is
really
basically
that
of
a
softly.
It's
not
that.
G
Extend
those
and
extend
those
definitions,
and
likewise
also,
unlike
in
scheme
amount
they're.
Basically,
each
mount
point
has
an
authoritative
copy
of
the
data
that
you're
mounting
there
here.
Basically,
the
model
is
differently.
Actually
the
theta
that
is
mounted
the
authoritative
owner
is
wherever
is
the
original
location
of
the
data,
and
this
busy
first
provided
with
this
additional
with
this
additional
link
with
this
additional
access
with
people.
G
Likewise
also
there
is
actually
emphasis
is
more
on
data
retrieval,
there's,
no
validation
of
data
or
so
at
the
mount
point
is
also
different
from
schema
models,
but
you
do
of
course
me
to
do
the
elevation
here.
Basically,
is
really
just
to
provide
this
to
provide
it
to
provide
it
accents,
access
and
also
the
number
of
data
instances,
of
course,
does
not
increase
if
you'll
mount
a
piece
of
data,
it's
still
the
same
data,
so
you
don't
have
it's
not
additional
instance.
So.
G
This
pretty
just
to
delineate
distinguish
please
minutes.
Okay,
all
right
hurry
up
a
little
bit,
but
so
essentially
maybe
I
can
almost
skip
this
very
detailed
slide,
but
basically
it's
automatic
to
provide
these
new
path
structures
to
superimpose
them
on
top
of
those
young
data
trees-
and
this
is
rough,
Missy
Rock
conceptualization
of
what
is
going
on
there.
G
Allow
you
to,
for
instance,
realize
the
notion
of
a
federated
data
store
where
you
present
treat
and
network
as
a
system
you
can
busy
access
it
to
a
single
server.
You
can
basically
have
a
borderless
agent
if
you
will
just
your
busting
or
breaking
up
the
server
define
and
border
okay,
and
obviously
there
are
various.
This
is
a
basic
concept.
Obviously
there
are
various
consider
from
caching
considerations
for
eating
of
circular
mounting
and
so
forth.
G
So
the
next
steps
of
this
are
waiting
as
far
as
the
drug
is
commits,
remain
constant
content
actually
for
violence
and
part
of
this,
we're
basically
incorporate
into
open
daylight
and
make
utilizes
those
those
concepts
and
the
MD
Cell
editorially,
there's
some
editorial
cleanup
that
needs
to
occur.
Also,
the
relationship
really
it's
email,
hot.
We
need
to
be
elaborated
and
an
extended,
and
but
the
question
really
is
also,
but
in
the
purpose
of
this
presentation
here,
so
as
actually
the
working
group
so
there's
a
feedback
if
there's
interest
to
move
forward
with
this.
G
O
G
O
G
G
C
Know
I'm
so
I'm
sorry
to
do
this,
but
we're
really
running
out
of
time
on
this
and
the
question
is:
is
there
interest
in
the
working
group
on
the
topic
at
all
and
it's
okay?
If
you
say
we
need
more
discussion,
so
we
can
ask
it
three
ways.
Is
there
interest?
Do
we
need
more
discussion
and
we
want
to
accept
this
document
if
the
other
two
or
if
one
is
yes
and
the
others
know
so,
do
I
start
with?
Is
there
interest
in
this
type
of
function
in
the
working
group?
C
G
C
T
And
now
for
the
lightning
round,
my
name
is
Joe
Clark
from
Cisco
for
those
of
you
who
were
at
UPS,
our
ups
AWG
yesterday,
you've
probably
seen
some
of
this.
Ultimately
here's
what
we've
got.
We've
got
a
great
problem:
proliferation
of
yang
modules,
a
lot
of
what
module
is
being
written
across
mini
stos,
a
lot
of
vendors
implementing
them.
T
What
then,
was
done
is
pulled
together,
a
number
of
very
interested,
passionate
people
about
yang
to
set
up
it's
a
number
of
tools
to
help
people
find
the
right
yang
modules
understand
how
to
use
them,
learn
from
best
practices
and
validate
yang
modules.
That's
done
with
a
number
of
open
source
tools
at
yang,
catalog
org.
What
I'm
gonna
present
today
is
the
draft
that
describes
the
backing
store
for
yang
catalog
org.
It
is
a
yang
module
that
we
have
built
to
catalog
metadata
about
yang
modules.
Now
the
intent
of
this
and
I'll
get
to
that.
T
T
Now
some
of
you
may
have
heard
of
the
open,
config
catalog
model,
which
was
which
is
a
document
here,
as
we
started
to
implement
this
as
we
started
to
create
running
code
and
ran
into
some
problems
as
the
open,
config
catalog
module
evolved,
it
kind
of
deviated
from
what
we
needed.
Initially,
we
needed
a
way
of
cataloging
individual
modules
and
relative
to
that
their
implementations
and
they
started
to
deviate
from
that
in
their
o
to
Rev.
T
In
addition,
we
saw
some
discrepancies
in
terms
of
yang
regular
expressions
with
what
we
needed
for
the
demon
that
was
going
to
load
and
run
and
services
module,
and
there
was
some
overlapping
Leafs
and
the
open,
config
catalog
that
seem
to
contradict,
or
at
least
confuse
some
of
the
points
in
the
ITF
yang
library.
A
primary
use
cases
with
how
we've
structured
this
model.
This
yang
catalog
model
right
now
is
to
first
be
able
to
give
an
A
yang
model
find
all
of
the
metadata
about
it,
as
well
as
the
platform's.
T
A
vendor
platform
and
software
releases
that
implement
it
and
given
a
vendor.
A
platform
and
a
software
release
show
all
the
yang
modules
that
they
implement
their
conformance
level,
their
deviations
features
and
so
on,
and
we
also
want
to
be
able
to
provide
rich
per
module
metadata,
such
as
maturity,
the
document
from
where
it
was
extracted
in
the
ietf.
Where
was
the
originating
working
group
and
then
perhaps
some
other
per
sto
or
per
document
author
or
organization
metadata
as
well?
T
I've
got
a
tree
there.
So
this
is
the
full
tree
as
it
stands
in
the
0-0
draft.
We
are
also,
as
I'll
say,
on
the
last
slide,
working
with
the
new
semantic
versioning
kind
of
rapid
development
approach
here,
so
in
our
github
repository,
this
has
already
changed,
based
on
what
we
learned
from
the
hackathon
and
Kent
pointed
out,
something
very
excellent
in
that
we
are.
This
is
basically
just
yang
data.
We
don't
actually
have
a
server
here
deviation
here,
describing
a
module
that
doesn't
have
any
relevance.
T
So
what
we're
going
to
do
is
pull
that
out
and
click
that
into
the
implementation
section-
and
this
also
is
hopefully
going
to
help
inform
the
the
Biss
work
happening
in
the
net
comp
group
on.
Maybe
we
can
create
more
modular
groupings
in
the
yang
library,
so
we
don't
have
to
kind
of
copy
and
paste
their
work.
We
can
use
it
directly
from
yang
library,
just
real,
quick,
two
things.
Two
elements
of
this
that
might
not
be
obvious:
one
is
compilation.
T
Status,
Benoit
has
been
doing
a
great
amount
of
work,
thanks
to
in
part
to
all.
The
developers
have
built
great
yang
validation
tools
to
be
able
to
run
yang
module
through
a
number
of
validations,
as
modules
are
registered
with
the
catalog,
we
will
run
them
against
these
validators.
We
will
record
that
compilation
status
as
well
as
the
output,
and
that
would
be
metadata
in
the
Eng
catalog
I
mentioned
maturity
level
earlier.
What
I
mean
by
that,
and
and
some
of
these
terms
are
likely
to
change-
we
want
to
say
how
trusted
is
a
module.
T
Is
it
an
initial
individual
draft?
Has
it
been
formally
adopted
by
a
standards
organization,
or
is
it
ratified
by
a
standards
organization
that
can
help
a
module
consumer
know
that
yeah
I
can
pretty
much
trust
that
this
isn't
going
to
change
or
that
I
can
rely
on
this
and
it
can
help
another
module
developer
understand
that
the
type
dev,
so
the
semantics
in
such
a
module
can
be
trusted
and
perhaps
used
as
a
best
practice
or
a
learning
example.
T
Initially,
we
thought
of
trying
to
map
that,
with
vendors
and
benoit
pointed
out
that
that's
probably
going
to
get
dangerous
with
how
vendors
tend
to
work,
so
we're
going
to
add
a
new
element
for
not
applicable,
where
primary
focus
primarily
focusing
maturity
at
the
sto
level
or
standards
development
organization
level.
Our
second
sub
tree
is
the
vendor
tree.
So,
as
I
mentioned,
giving
a
vendor
given
a
platform
giving
a
software
release
show
me
all
the
modules,
and
this
is
we're.
T
Gonna
move
our
conformance
data,
so
you'll
also
be
able
to
see
what
conformance
level
is
it,
importers
that
implement
what
features
are
there
and
what
deviations
exists
on
a
per
module
per
implementation
basis?
And
finally,
yes,
three
minutes
the
intent
as
I
mentioned
is
not
necessarily
this
could
change.
T
Our
development
is
happening
openly
and
get
we
plan
on
pushing
another
revision
of
this
module
relatively
soon.
However,
it
is
already
dramatically
changed
with
what
I
presented
from
a
zero
zero
draft
standpoint,
a
lot
of
that
based
on
testing
from
juniper
from
Huawei
from
others
at
hackathon
99.
So
I
asked
you
if
you're
interested
and
you
want
to
contribute,
there's
a
link
to
contribute
to
the
catalogue
you
can
sign
up
to
our
announce
list
and
announce
that
yang
catalogue
that
org
will
be
sending
out,
updates
and
use
the
tools.
N
T
Benoit
will
answer
this,
but
I'm
going
to
answer
first
and
then
he's
going
to
tell
me
everywhere
I'm
wrong.
We
are
working
right
now
on
the
semantic
versioning
approach.
You
may
have
seen
the
Cimber
draft.
It's
got
the
noit's
name
on
it.
Richard
Barnes
was
very
big
contributor
to
it.
We
want
to
do
more
rapid
development
of
yang
modules
and
we
feel
that
this
module
is
going
to
continuously
evolve
as
we
develop
new
use
cases.
T
For
that
reason,
we
were
thinking
if
we
try
to
fit
into
the
structure
of
standardization
too
soon
it
might
hinder
our
our
work
in
making
this
module
truly
useful.
That
said,
if
semantic
versioning
really
takes
off
what
this
really
looks
like
a
promising
thing,
it
could
be
that
we
could
periodically
synchronize
back
to
the
IETF
with
an
RFC
nameplate
on
it
and
continue
to
iterate
our
work.
In
a
repository
like
github
now,
Benoit
tell
me
how
you.
B
Did
great
thanks,
but
not
less
so
one
more
thing
is
that
we
keep
adding
new
things.
All
the
time
bears
in
the
hackathon.
Typically,
you
know,
I
was
comparing
all
these
modules.
Some
of
the
vendor
modules
are
Native
models
because
they're
generated
so
obviously
I
mean
not
obviously
that
they
fail,
for
example,
they're
not
fully
compliant
with
67
this,
so,
okay,
we're
adding
a
new
leaf
is
degenerated
because
if
it,
if
it
is
I
mean
doesn't
matter
next,
one
is
okay.
B
I
was
just
taking
a
note
now
actually
missing
whether
the
service
model
or
network
element
model.
We've
got
this
draft
in
RFC
Q
right
now.
Another
one
is:
okay:
we've
been
speaking
about
nmda
we're
adding
now
the
NMD,
the
the
tree
type.
So
you
know
it
keeps
evolving
so
rapidly
based
on
people
using
that.
So
that's
that's
the
ID,
but
it
could
be
solid
ice
maybe
later,
but
it's
not
the
end
goal.