►
From YouTube: IETF99-NETMOD-20170717-1550
Description
NETMOD meeting session at IETF99
2017/07/17 1550
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
A
Thank
you
welcome
to
net
mod
in
Prague
I'm,
Lou
burger.
This
is
Kent
Watson,
we're
chairs,
obviously,
and
we
have
Michael
Wang
who's,
helping
us
out
as
have
been
helping
us
out
a
secretary
as
usual.
This
will
be
shown
again
as
usual.
We
on
our
slide.
We
show
where
you
can
find
the
different
information
on
the
tools
page
and
that's
the
easy
way
to
get
to
it.
A
You'll
find
that
there's
a
jabber
I'm,
sorry
there's
a
etherpad
link
and
if
you
could
join
the
etherpad
and
help
us
with
collective
note-taking,
we'd
like
to
take
you
that
before
we
get
into
the
session,
we
have
the
usual
note
well,
but
it's
actually
changed
slightly.
The
this
was
just
updated,
based
on
RFC
81-79
being
published.
Some
folks
may
have
noticed
the
blog
entry
talking
about
the
changes.
It's
a
new,
updated
IPR
policy
for
the
IETF.
It
clarifies
some
things
the
from
my
reading
of
it.
A
The
most
significant
thing
it
does
is
clarifies
what
a
contribution
is
and
isn't.
Basically,
if
you
say
anything
in
a
meeting
or
in
a
forum
or
even
give
any
indication
of
your
opinion,
that's
a
contribution.
The
other
thing
it
does
is
it
points
to
an
RFC,
the
number
of
which
I'm
forgetting
which
talks
about.
If
you
don't
follow
the
IPR
process,
what
are
the
steps
a
working
group
can
do
based
on
that?
That
really
goes
to
late
disclosures.
A
This
is
a
pretty
fresh
change.
It
was
just
published
in
may
may
not
have
noticed
that
before
you
might
want
to
take
a
look
as
usual.
We
have
neat
echo,
we
have
audio
and
we
do
have
some
participants
who
are
remote.
This
time,
blue
sheets
are
going
around,
please
sign,
sign
them,
and
again
here
is
another
way
to
get
to
the
ether
pad.
This
is
the
longer
form
if
you
get
to
the
tools
page
and
click
under
minutes,
that's
the
sort
of
the
easiest
way
to
get
there.
A
B
So,
at
a
high
level,
the
agenda
is
meant
to
be,
rather
than
going
through
all
the
working
group
documents
first
on
in
the
first
session
and
then
on
chartered
working
group
documents
in
the
second
session,
we're
breaking
it
up.
B
So
the
first
this
session
is
primarily
nmda
focus
with
some
other
documents,
sprinkled
in
they
may
or
may
not
be
working
group
documents
and
then
likewise,
the
next
session
will
be
primarily
focused
on
schema
mount
with
some
other
documents
sprinkled
into
it,
and
this
particular
agenda
has
been
ordered
with
the
ACL
draft
being
presented
first,
so
that
the
QA
for
the
nmda
would
get
at
the
end
gives
us
flexible
timing.
So
if
we're
running
at
it
short
on
time,
you
know
less
than
20
minutes,
but
if
we
have
more
time
we'll
be
more.
A
Okay
from
what's
changed,
what's
changed
since
the
last
meeting,
so
we
have
one
document
that
is
sitting
with
the
iesg,
although
our
ad
looks
confused
by
that,
maybe
not
so
we
have
one
document
sitting
with
the
iesg.
That's
working
through
the
process.
We
have
sixty
eighty
seven
bits,
which
is
the
guidelines
document.
That's
been
returned
from
the
IAS
G,
primarily
because
of
the
update
to
NMDA
guidelines.
That
document
that's
come
out.
The
intent
is
is,
and
we're
going
to
hear
more
about
this.
A
The
intent
is
to
take
the
guidelines
and
produce
a
distilled
recommendation
that
ends
up
replacing
the
current
section
in
sixty
eighty
seven
bits
and
once
that
replacement
is
agreed
to
by
the
working
group
will
submit
resubmit
sixty
eighty
seven
for
this,
we
have
a
couple
of
documents
that
are
in
last
call
be
good
to
take
a
look
at
those.
The
last
call
was
extended
because
it's
overlapping
with
this
week,
one
of
them
the
one
in
green,
is
on
the
agenda.
The
second
one
is
not,
but
please
do
take
a
look
and
send
comments.
A
We
have
a
bunch
of
other
updated
working
group
documents
that
we're
going
to
be
talking
about
over
the
next
couple
of
sessions.
I
already
talked
about
sixty
87.
This
I
think
we
talked
about
all
of
these
except
for
entity,
so
this
document
has
been
sitting
out
there
for
a
while.
The
authors
thought
the
technical
content,
the
the
hard
part
was
complete,
but
that
it
might
be
impacted
by
NMDA
and
and
in
fact
it
has
them,
and
the
authors
in
github
have
a
partial
update
already
completed,
but
it
sounds
like
there's
some
work
still
left.
A
A
D
D
F
A
Groups,
so
that
that
work
is
like
running
ahead.
Okay,
so
I
think
we
have
good
examples
if
you're
looking
just
for
an
example
and
ones
that
are
far
more
complex
than
this
one.
This
is
actually
a
pretty
simple
model
in
terms
of
what
we
submit
into
the
to
the
is
G
for
publication.
I
certainly
hope
that
this
is
out
very
soon
so
yeah.
It
would
be
the
first
one
submitted
by
this
working
work.
Okay,
thank
you
sure.
A
Nmda
right,
that's
actually
an
excellent
idea.
The
one
question
I
have
a
little
bit.
Maybe
for
you
is,
is
do
we
wait
till
we
have
agreement
on
the
recommendation
text
from
the
working
group
which
we
don't
have
yet
or
do
we
go
just
based
on
the
ad
recommendation?
That's
been
distributed,
and
maybe
some
other
folks
who
work
and
other
SDOs
might
have
a
view
on
this.
A
G
A
A
H
Representing
the
broadband
forum
so
yeah,
absolutely
we
unwelcoming
liaison
telling
us
about
an
MTA,
but
equally,
of
course,
we're
aware
of
it
already
and
we
and
it's
interesting
that
the
maybe
that
it'll
be
applied
to
entity
very
soon,
because
actually
you
know
that
is
one
of
the
the
drafts
that
words
are
actually
referencing.
Okay,.
A
A
So,
with
the
last
comment,
I
think
that
was
a
set
up
for
the
first
bullet
on
this
slide.
Thank
you.
We've
had
one
in
Kim
coming
on
the
A's
on
it
came
in
just
recently,
and
basically
it's
letting
us
know
that
this
other
organization,
the
broadband
forum,
is
interested
in
reusing
the
work
we're
producing
in
the
IETF
and
it
called
out
entity,
as
we
just
heard.
It
also
called
out
the
alarm
module
the
alarm
module.
A
As
it's
been
discussed
a
couple
of
times
at
the
IETF
privately,
it's
unlist
that
one
has
gone
over
to
see
camp
and
we
expect
that
work
to
be
done
there.
If
you
have
any
this,
this
one
is
not
asking
for
a
specific
response,
but
if
you
have
something
you'd
like
to
discuss
based
on
the
noise
on,
please
just
send
it
to
the
list.
A
With
that
we're
gonna
wrap
up
with
milestones
the
I'd
like
to
highlight
that
one
we
have
a
few
things
are
done.
We
have
a
few
things
that
are
a
little
late,
but
we're
close
and
the
entity.
We
really
need
to
figure
out
how
to
wrap
up
and
so
I'm
happy
to
hear
that
the
authors
are
working,
that
we
might
see
soon
see
an
update
and
with
that
we're
gonna
move
to
the
next
slot,
which
is
first
presentation,
ACL.
I
Basically,
support
of
combinations
of
ACLs
of
different
address
families
and
types,
and
will
also
allow
to
state
the
reason
why
this
was
done.
There's
also
been
inclusion
of
more
match
and
action
parameters,
and
this
was
taken
from
after
we
got
input
from
Netflix
and
there
were
also
a
lot
of
open
issues
that
we
found
based
on
the
review
of
a
various
Native
models
in
so
so
these
were
opened
up
as
as
issues
then
with
it,
and
we
documented
it
and
we've
taken
a
eyes
to
implement
this
okay.
I
So
why
did
we
include
support
for
if
you'll
address
families,
so
in
the
current
model
in
graph
number
10?
If
you
see
ACL
type,
is
not
strictly
checked
so
in
an
in
an
ACL,
you
can
have
aces
of
v4v,
say
and
l/2,
so
this
doesn't
work
for
vendors
who
want
to
who
can
only
support
ecl's
of
a
single
address
family
type.
Now
this
leaves,
if
we
haven't,
have
a
model
like
this.
I
We
needed
a
way
to
fix
that,
so
what
we
did
is
that
we
took
we
focused
on
l2,
l3
and
l4,
and
we
made
different
combinations
of
these
types
like
different
ACL
types.
So
when
you
have
the
exchange
message
you
can
specify
which
type
the
ACL
conforms
to
and
you'll
only
see
part
of
the
yang
model
that
conform
to
that
ACL
type.
So
there's
no
room
for
error
anymore,
so.
I
Okay,
so
so
what
we
did
here
was
that
we
created
so
what
I
have
on
the
right
hand,
side
are
the
identity,
feature
and
container
statements
for
a
particular
ACL
type,
and
this
is
extended
to
all
different
ACL
types
that
we
support.
Now
the
benefits
of
this
enhancement
are
that
you
have
very
strict
type
checking
so,
for
example,
if
you
support
only
be
for
ACL,
you
will
only
see
the
header
fields
and
ipv4
header
fields
that
pertain
to
v4
ACL.
I
There
is
no
way
you
can
now
configure
a
v6
ace
within
a
way
for
ACL
or
an
l2
ace,
so
this
also
makes
the
model
easy
to
extend,
because
in
case
you
want
to
extend
it
to
have
ACLs
I,
don't
know
like
an
l7
ACL.
All
you
need
to
do
is
write
the
identity,
feature
and
container
statement,
and
that
extends
your
model
right
away
and
you
don't
have
to
make
changes
to
the
main
body
of
the
model
like
you
wouldn't
have
to
do
earlier.
I
Identity
and
of
these
we
have
eight
new
types.
So
since
we
focused
on
l2
and
l3,
you
have
a
v4
HDL
v6,
the
Ethernet
ACL.
Then
you
have
a
mixed,
v4,
ACL,
I'm.
Sorry,
you
have
the
mixed
l2
and
v4
ACL.
You
have
mixed
l2
and
v6,
and
then
you
have
mixed
l2,
v4
and
v6,
and
then
you
have
something
so
we've
added
something
new
for
the
any
ACL.
So
the
ending
ACL
is
basically
a
presence
container
that
allows
you
to
override
your
default
routing
policy.
I
So,
for
example,
if
you
have
a
policy
that
says,
reject
all
packets
coming
in
from
I,
don't
know
some
source,
you
can
have
an
any
ACL
that
can
say
accept
or
accept
only
a
certain
subset
of
packets
that
come
in.
So
it's
basically
a
presence
container
that
lets
you
override
any
default
policies.
You
have
on
the
Box.
I
Ok,
the
inclusion
of
match
and
action
statements,
so
this
was
nothing
new,
so
this
is
this
was
added
after
we
got
feedback
from
Netflix
on
because
they
apparently
used
these
matches
and
actions.
So
one
was
adding
TCP
UDP
icmp
and
they
also
needed
logging.
So
this
was
just
a
small
subset
of
matches
and
actions
that
we've
added
there
are.
There
are
a
lot
that
are
actually
not
present
in
the
current
native
model
that
we
have
taken
as
an
open
issue.
I
Some
of
the
important
items
that
we
have
as
open
issues
are
currently
the
model
allows
only
a
single
address
and
a
single
port
to
be
specified
in
the
address
and
port
fields
for
source
and
destination
addresses
and
ports,
and
this
is
actually
not
scalable
and
it's
not
a
good
design
because
you'll
have
for
one.
If
you
have
only
a
single
ace,
you
have
to
have
multiple
aces
representing
a
particular
network
that
you
want
to
accept
packets,
from
so
most
of
the
bigger
vendors.
I
I
So,
for
example,
you
have
ingre
stats
and
egress
stats,
so
currently
the
track
number
11.
It
doesn't
address
this
issue
very
well
because
you
can
even
have
stats
that
come
in
that
are
aggregated
over
interfaces,
stats
that
are
per
ace
or
ACL
per
interface,
depending
on
how
much
resource
you
have
in
teakamp,
vendors
have
different
stats
that
are
allocated
so
stats
collection
is
one
big
issue.
Containers
for
addresses
and
ports
is
another
big
issue.
The
remaining
issues
are
basically.
I
Leaves
that
we
don't
have
for
like
ICMP
off
or
precedence
things
like
that
that
we
see
in
various
native
models,
so
if
we
want
to
get
a
model,
that's
you
know
that
looks
good
and
that's
similar
to
a
lot
of
the
native
models.
Then
we
need
to.
We
need
to
add
this
in
into
the
IDF
model
and
make
it
competitive
with
other
major
models
out
there.
I
I
I
B
A
We
might,
at
this
point,
sent
a
message
to
the
list
saying
that
well,
we'll
probably
send
a
message
to
the
list
saying
that
there
is
gonna
be
another
version,
because
it
doesn't
make
sense
to
force
folks
to
read
it.
Who
would
otherwise
on
not
read
it
and
then
do
another
last
call
and
try
to
get
them
to
do
it
again.
So
well,
let
people
know
that
doesn't
mean.
Don't
comment.
Don't
read
it's
just
that!
We're
not
gonna
have
a
successful
last
call
on
this
at
this
time
and
we'll.
J
I
J
A
K
K
Is
that
better,
yeah?
Okay,
so
so
I
want
to
give
an
update
on
on
the
datastore
architecture
draft
what
we've
changed
there.
We
think
it's
very
close
to
completion.
Actually,
so
we
would
request
people
review
it.
I
know,
there's
been
some
comments
on
the
ATIS
today,
I'm,
not
a
chance
to
read
through
all
those
in
detail,
but
thank
you
for
those,
and
so
weird
lights
are
trying
it
finished
fairly
soon,
if
possible.
K
So
the
quick
reminder
what
we're
talking
about
the
whole
purpose
of
the
nmda
architecture
and
the
problem
we're
trying
to
solve
is
this
separation
between
what
an
operator
is
asking
your
device
to
do,
I
their
intent,
the
intended
configuration
and
what
is
actually
doing
so.
The
desire
here
is
to
very
accurately
reflect
the
operational
state
of
device
and
to
align
the
namespace
of
those
as
close
as
possible
so
that
you
can
easily
correlate
between
both
the
intent
and
the
actual
operational
value.
As
you've.
K
Probably
all
aware,
we
spent
a
lot
of
sessions
discussing
and
time
different
solutions.
This
problem
I've
been
invaluable,
ITF
and
we've
converged
on.
This
is
the
solution
and
the
solution
defines
a
new
operational
state
datastore.
This
has
implications
on
the
structure.
The
yang
models
and
they're
not
being
simplifies,
simplified
for
nmda
and
I've
got
a
separate
talk
on
on
what
that
looks
like
and
how
it
affects
you
and
will
also
effectively
be
updating
Netcom
from
restaurant
as
well.
K
That's
what
the
pressure
state
datastore
and
there
will
be
talks
in
the
networking
group
covering
those
extensions
effectively
for
those,
so
we've
updated
our
canonical
they
doors
picture
and
the
the
lines
in
rail
effectively
show
you
what
we've
changed
and
there's
nothing.
Really.
This
that's
very
significant!
Here,
that's
changed.
K
So
this
is
summary
of
what's
changed,
and
this
is
since
the
oh
one
version
was
presented
in
Chicago.
We
also
published
an
O
in
the
interim
I
feel
that
what
we've
done
is
we've
improve
the
definitions
of
configuration
of
State
and
we
spent
a
long
time
on
this.
We've
pulled
in
clarified
some.
The
existing
definitions
of
the
existing
data
stores
that
defined
in
the
net
conf
RFC,
so
the
intent
here
is
this
is
a
canonical
definition
of
them.
K
K
So
as
part
of
that,
we
defined
the
term
conventional
conventional
configuration
data
store,
which
is
like
the
start
up
and
running
and
kinda
that
we
have
today
and
intended
is
also
thrown
into
that
category
as
well,
because
it's
sort
of
logical
exists
today.
Even
you
don't
see
it,
we've
added
a
definition
for
learned
configuration
now
that
one
is
probably
worth
again.
I
come
a
bit
more
detail
and
is
worth
thinking
about
bit
more
a
bit
more
because
some
people
have
some
concerns
about
definition.
K
K
Yes,
as
I
said
before,
we've
pulled
in
the
definitions
of
startup
candidate
and
running
and
I
am
here
just
to
have
them
all
in
one
place
rather
than
to
change
the
meanings
of
what
these
dates
are.
So
we've
tried
to
clarify
them,
provide
extra
text
more
accurate,
describe
them,
but
we're
not
trying
to
change
the
meaning
of
those
existing
data
stores.
I,
ask
you,
please
you
can
to
review
these
definitions
carefully,
because
once
this
has
been
published,
then
hopefully
there's
be
reference
for
quite
a
while
going
forward,
so
getting
getting
good
reviews
that
we
appreciated.
K
K
We've
now
tried
to
align
that
to
be
more
to
be
more
closely
based
on
that
and,
as
you
can
see
the
text
here,
the
first
sentence
is
based
on
the
same
as
the
net
conf
definition,
and
what
we've
actually
really
clarified
here
is
that,
for
in
yang
a
configuration
node
is
modeled
by
something
that's
conflict,
true
and
that
configuration
came
from
different
sources.
The
way
I
sort
of
like
to
think
of
this
is
the
conflict.
True,
on
a
node
means
it
can
be
configured
rather
than
it.
K
The
other
one
that's
been
more
contentious
is
definition
of
learned
configuration,
and
this
has
been
defined,
as
configuration
has
been
learned
by
a
protocol
interactions
with
other
systems
that
is
not
conventional
dynamic
configuration
so
we're
trying
to
find
the
label
for
the
configuration
data
you
might
get
from
BGP
or
from
one
of
your
other
peers
systems
in
the
case,
where
they're
overriding
a
leaf
or
a
node.
That's
in
your
configuration
tree,
so
an
example
of
this
might
be
a
timer
value.
K
This
configuration
isn't
coming
through
a
dynamic
datastore,
it's
just
coming
elsewhere
through
the
system
and
then
a
an
open
issue
that
we
haven't
quite
resolved
here
is
whether
the
learned
origin
can
also
apply
to
state
note
as
well
as
so
needs
to
be
discussed.
My
hunch
is,
the
art
will
be
yes,
it
can
be
that
that
the
origin
data
is
only
about
where
data
comes
from,
and
so
it
should
apply
there.
But
that's
the
open
question.
L
Ma'am
it
also:
what
is
your
proposal
for
the
handling
of
the
term
configuration
in
that
compared
at
C?
Are
you
proposing
to
replace
it
revise
it,
delete
it
I,
don't
know
I.
Guess
we're
going
to
supersede
it
effectively
that
this
would
so.
We
have
here
a
new
term
definition.
We
should
be
interested
to
decide
how
we
want
to
handle
the
old
term
definition.
It
can
be
deleted,
I
mean
in
Netcom
this
RFC
or
the
same
can
be
used
there
too,
but
copy
and
paste
is
not
good,
which
RC
are
you
thinking
about
the
Netcom.
A
So
one
option
is
that
this
document
lists
is
updating
that
RFC
and
we
can
identify
that
the
soul
update
is
in
the
name.
The
other
option
is
that
the
documents
that
are
headed
the
supporting
documents
that
are
going
on
in
Netcom
could
do
that.
So
I
would
sort
of
defer
to
the
negev
chairs
on
how
they
would
like
to
do
that.
So.
L
H
A
B
Also
add
to
that
many
times
in
drafts
when
they're
importing
terms
from
other
drafts,
they
specify
which
draft
that
are
importing
the
term
from
so
you
know
for
the
term
configuration
they
could
indicate.
Specifically
it's
the
old
or
the
current
Netcom
RFC,
or
the
new
revised
Davis
or
I've
seen
so
it
wouldn't
be
actually
ambiguous
in
the
terms
of
the
draft
ourselves.
K
Our
aim
here
is
to
try
and
simplify
devices
and
clients,
so
the
rather
having
this
mix
of
different
defaults.
You
might
support
to
try
and
converge
and
just
have
one
one
definition
that
everyone
uses,
because
it's
a
new
datastore
we're
hoping
everyone
for
work
on
the
same
thing.
So
the
idea
here
is
that
the
defaults
in
a
way
don't
apply
to
the
pressure
of
state
they'd
store.
The
operational
data
store
always
gives
you
the
values
that
are
in
use
by
the
device.
M
David
Lamm
Patrick,
so
I've
thoroughly
hit
my
head
on
default
values
in
schemas,
because
it's
not
only
the
device
that
needs
to
be
aware
that
the
absence
of
the
value
is
something
different
from
the
default
value,
but
it's
also
the
client,
libraries
and
every
single
thing
it
passes
through
in
the
middle,
so
I
think
there's
a
requirement
here
to
kind
of
maybe
not
even
have
the
default
of
the
schema
in
the
best
case,
because
otherwise
you're
still
trading
on
thin
ice.
Yes,.
K
So
to
answer
in
the
particular
case
you've
got
configure,
then
a
configuration
node
often
has
a
default
value
associated
with
it
and
that
configuration
knows
exists
in
the
operational
State
they
store
as
well.
So
you
have
it
often
in
the
schema
but
Inlet.
What
I'm
saying
is
in
this
case
you
would
return
that
value
if
it's
in
use.
K
N
K
C
Andy
Biermann,
yet
the
reason
for
suppressing
defaults
was
to
improve
the
transfer
efficiency
yeah.
So
if
you
have
a
whole
bunch
of
stuff,
that's
in
the
default
value
and
you're
wasting
60%
of
your
packet
with
stuff,
that's
redundant.
Yes,
you
don't
get
that
efficiency.
So
so
now
you're
saying
we
don't
care
about
efficiency.
We're
gonna,
send
all
the
values
all
the
time.
No,
not
quite.
K
So
in
terms
of
I've
said
here,
we
want
to
clarify
what
in
use
means
I
think
we
want
to
get
a
definition
of
in
use.
That
doesn't
mean
that
we
throw
back
a
lot
of
irrelevant
data,
but
we
try
and
find
that
so
scope
sensibly
that
the
default
values
you
get
back
ones
you
might
be
interested
in,
so
not
a
load
of.
So
if
OSPF
is
turned
off,
you
don't
return
all
the
default
values
for
OSPF
that
aren't
of
interest,
but
it
means
that
your
nose
gets
turned
on.
C
It
seems
that
explicit
mode
is
clearly
not
useful
because
you're
talking
about
read-only
data,
so
it
can't
be
explicitly
set
to
the
default
value.
So
only
trim
really
matters
which
is,
if
the
nodes
not
there,
then
it
must
be
using
the
yang
default
and
I
think
that
definition
is
rather
clear
and
yang.
1.1
I.
Don't
understand
why
it
needs
to
change
now.
So.
K
C
You're
well
I
want
to
get
to
this
later,
but
I
think
you
part
of
the
architecture.
That's
that's
completely
lacking
is
a
concept
of
conformance
for
data
stores,
so
I'm
reading
a
gang
module
I
want
to
know
what
is
a
server
that
is
conforming
to
this
model
supposed
to
do,
and
you
completely
failed
on
on
providing
that
information
for
data
stores.
C
Before
we
used
to
know
this
is
candidate
running
and
startup,
there
were
only
three
data
stores,
there's
no
way
to
add
new
ones
like
the
Acme
operational
data
store
which
is
now
allowed,
so
so
really
think
it.
There
has
to
be
something
in
the
yang
module
that
that
tells
developers
what
the
conformance
expectations
are
and
and
the
defaults,
as
is
it,
could
be
considered
part
of
that.
But
the
problems
that
I've
been
hearing
about
from
customers
with
operational
data
is
is
how
to
make
it
more
efficient.
C
C
Okay,
so
we've
had
to
add
operations
that
make
it
much
more
responsive
to
iterate
through
a
list
and
of
course
you
need
to
iterate
through
a
list
without
knowing
the
keys,
because
operational
data,
the
keys,
change
all
the
time,
so
so
I
think
you
really
should
focus
more
on
on
efficiency
because
it
especially
with
you
know,
large
routers,
which
you
have
a
lot
of
the
getting
lots
of
operational
data-
is,
it
needs
to
be
efficient.
Ok,.
M
David
Nutter
again
so,
unfortunately,
this
being
a
completely
new
data
store,
doesn't
help
with
the
defaults
either
because
it's
gonna
be
accessed
using
the
same
existing
libraries
and
that's
where
the
problem
really
is.
So
if
that
library
doesn't
allow
me
to
act
even
figure
out
whether
the
value
was
specified
or
it's
coming
from
a
default
which
does
exist,
our
library
is
where
I
can't
tell.
N
K
Mean
the
case
our
thinking
of
is:
if
one
of
your
demons
has
crashed
and
it's
not
returning
any
data,
then
then
effectively
that
doesn't
mean
that
those
values
are
now
and
turn
into
the
default
values
that
just
there's
no
data
to
be
returned
there
and
either
you
hang
the
whole
response
or
you've
got
to
compromise.
So
that's
why
I
think
it's
sort
of
nicer
for
a
semantic
point
of
view
to
always
return
the
value
it's
in
effect
and
I
do
take
Andy's
point
and
that's
what
we
try
to
find
the
balance
between.
K
O
Think
part
of
the
problem
is
that
yang
tries
to
cover
default
values,
both
in
configuration
and
operational
state
and
in
fact,
in
these
two
cases
the
semantics
of
the
default
values
is
quite
different.
So
yeah,
that's
why
it
might
be
difficult.
We'd
like
to
come
up
with
some
reasonable
definition
and
and
handling
of
defaults,
I.
A
K
K
Okay,
so
the
third
of
the
four
sort
of
major
changes
we've
made
on
a
major
changes
or
refinements
is
to
origin
metadata,
and
here
we've
refined
with
and
to
remind
you,
your
enjoy
metadata
is
about
where
the
values
come
from.
So
the
idea
here
is
that
you
can
differentiate
that
the
operational
values
come
from
configuration
or
it's
come
from
a
protocol
or
the
system
is
instantiated
that
value
like
a
system
created
interface,
for
example,
or
maybe
it's
been
overridden
by
i2
s.
K
So
that's
the
idea
here
is
you
can
identify
where
this
data
is
coming
from,
and
this
applies
to
all
the
a
nodes
in
operational
and
currently
we're
focusing
our
the
thoughts.
Westing
operational
state
datastore,
but
it's
possible.
It
may
apply
to
other
data
stores
as
well,
so
with
intended.
There's
the
thought
that
we
may
standardize
some
templating
mechanism
and
again
this
same
sort
of
idea
of
annotating,
where
that
has
come
from,
might
work
quite
well
with
that
to
say
whether
a
values
directly
the
configuration
or
its
templated
expand
it,
for
example.
K
And
finally,
our
intent
is
that
this
is
optional
to
implement,
because
we
appreciate
that
this
could
be
quite
expensive,
so
so
the
new
set
of
origin
metadata
identities
expanded,
so
we've
got
intended
dynamic
system
learned,
default
and
unknown,
and
these
match
the
definitions
we've
got
in
the
only
part
of
the
dock
intended
is
from
the
intended.
Datastore
dynamic
means
it
comes
from
any
of
the
dynamic
data
stores,
and
these
are
identities.
So
there's
multiply
dynamic
data
stores
of
IRS
has
different
levels.
K
For
example,
then
they
can
be
using
separate
identities
underneath
dynamic
to
identify
which
one
of
those
potentially
the
system,
identity
represents
effectively
configuration
or
state.
That's
coming
from
the
system
itself,
so
you're
automatically
configured
protocol
or
a
loopback
zero
interface.
That
always
exists,
for
example,
would
be
system
learned.
Is
this
one
that
we
discussed
earlier?
That's
slightly
more
contentious
about
theta,
it's
learn
from
a
peer,
and
this
is
essentially
stuff
that
isn't
dynamic.
So
it's
anything
that
has
come
from
another
system.
It's
not
configuration.
K
It's
not
dynamic
default
value
is
a
value
that
comes
from
the
schema,
so
either
an
explicitly
for
value
in
the
schema
or
where
you
might
have
a
description
stain
that
describes
what
that
value
is
circe
fault
and
we've
got
a
catch-all
unknown.
So
the
systems
that
can't
identify
where
piece
of
data
that
comes
from
they
can
at
least
actually
indicate
that
there
is
still
some
open
questions,
I
think
in
terms
of
what
the
best
way
of
encoding.
This
information
is
how
to
optimize.
For
that
I.
K
K
And
the
last
one
to
cover
is
refinement
to
XPath
context
and,
in
essence,
I
think.
What
we're
suggesting
here
is
the
fairly
intuitive
interpretation
that,
if
you,
the
XPath
expressions
for
data,
this
in
operational
will
resolve
two
nodes
in
that
data
stock.
They
won't
resolve
two
nodes
in
the
configuration
data
sort
of
example,
XPath
expressions
are
run
in
a
configuration.
K
Datastore
will
continue
to
resolve
to
the
same
datastore
that
they're
in
and
the
last
interesting
one
is
that
we're
saying
that
input,
output
parameters
for
notifications
are
PCs
and
action
statements
again
they
evaluated
in
the
context
of
operational,
so
that
doesn't
mean
that
those
operations
necessarily
have
to
just
apply
to
operation.
They
don't
and
we're
saying
that
when
parameter
is
evaluated,
that's
the
scope
that
they'll
be
evaluated
in
and
the
alternative
to
that
is
we
don't.
K
Okay,
so
open
issues
there's
been,
as
I
said,
there's
been
a
few
more
nailless
to
discuss
about
learned,
effectively,
origin
and
meaning
of
learned
data,
and
this
conversation
about
defining
in
use
these
two
refinement
in
terms
of
what
that
means,
and
also
how
to
optimize
the
data
return.
So
we
don't
turn
to
too
much
noise.
There's
been
a
question
about
guidelines
should
they
be
in
the
body.
This
is
for
the
guidelines
for
writing
new
datastore.
P
Me,
thank
you
very
much
name
is
sue
Harris
I'm
interested
in,
except
for
the
drive
identities.
I
didn't
find
that
when
I
walked
through
the
text
this
morning,
dynamic
data
stores
except
for
derived
identities.
Can
you
explain
that
maybe
I
just
don't
understand
what
you
meant
when
you
were
running
through
that.
K
Legs,
I'm
not
sure
I,
do
understand
either
so
I
think
is,
there
might
be
a
typo
effectively.
What
its
meaning
here
is.
The
dynamic
identity
itself
is
probably
more
likely
to
be
abstract
and
that,
rather
than
returning
that
at
your
dynamic
data
store,
you
derive
from
that
you
and
your
eternity
right
value.
P
E
Q
P
K
P
Mean
that's
good
I.
Just
didn't
find.
You
asked
me
to
read
the
draft
carefully
I'm
reading
it,
obviously
with
the
IRS
background,
with
dynamic
in
mind
and
I,
never
found
that
second
sentence,
or
the
exception
it
is
in
it,
is
carefully
laid
out
in
the
appendix
in
the
appendix
for
a
femoral
data
source
was
very
helpful
and
very
useful,
and
the
XPath
I
think
if
I
understood
it
also
is
generic
and
can
work
with
dynamic
data
stores,
as
well
as
yes,
I
think
so.
Yeah.
K
M
David
on
Twitter,
this
is
actually
a
good
solution
for
the
earlier
key
fault
problem
to
make
it
similar
to
this
I.
Think,
because
if
you
move
away
from
whether
the
value
is
present
and
actually
make
it
an
explicit
metadata
on
the
item,
then
you
can
just
put
have
the
bit
there,
whether
the
values
in
use
and
then
the
system's
actually
using
it
and
then
you're
done.
M
Matter
whether
you're
returning
about
you,
the
question
whether
it's
in
use
is
gonna
be
answered
by
the
metadata.
So
obviously
you
should
return
the
value
if
you're
using
it,
because
that
wouldn't
make
sense
otherwise,
but
if
you're
not
using
the
value,
it
doesn't
matter
if
you
return
one,
but
you
should
put
in
the
metadata
better.
It's
not.
D
E
Just
want
to
clarify
that
that
wasn't
actually
a
purpose,
the
purpose
of
the
way
we
allow
flexibility,
how
he'll
handle
defaults
was
for
configuration
because
we
had
implementations
that
handles,
handle
it
very
very
differently
under
iOS.
If
you
set
configure
of
a
configuration
variable
through
the
default
value,
it
disappears
from
the
configuration
under
that's
sorry,
Phil
Schaefer,
Gino's
900.
You
know
it's
my
baby.
If
you
put
it
there,
if
you
put
a
default
value,
if
you
can't
configure
default
value,
you
remain
because
we
think
you
knew
what
you
were
doing
so
so
there.
E
N
Mission
well
angel
Erickson.
Actually
we
had
three
different
methods
of
handling
before
the
the
other
method
is
that
if
you
have
a
default,
it
gets
there
and
you
don't
care
any
longer
how
it
got
there.
So
3-day
different
handling
and
I
think
if
we
have
with
defaults
on
get
data
that
would
solve
the
this
capacity
issue.
So
why
not
handle
that.
E
If,
if
there's
a,
if
I
have
an
interface
and
there's
a
default
MTU
and
the
interface,
isn't
there
I?
Don't
care
about
the
default
I'm
to
you?
If
the?
If
the
interface
is
down
I,
don't
care
about
the
default
into
you,
it's
not
in
use!
So
that's
that's!
Really!
The
the
the
value
of
having
the
operational
datastore,
give
actual
in
use,
values
and
I
think
that's
really
key.
O
Vodka
I
have
another
question
that
I
already
asked
before,
but
it
doesn't
seem
to
have
been
resolved
and
it's
about
templates.
The
draft
still
mentions
templates
several
times
very
very
lightly,
but
I
understand
that
validation
is
to
be
done
on
the
intended
datastore.
But
young
also
requires
some
constraints
to
be
satisfied
on
all
data
trees
and
I.
O
Don't
know
if
if
the
idea
is
that
none
expanded
templates
or
the
data
trivet
on
expanding
templates,
which
is
supposed
to
be
in
running,
probably
whether
it
is
really
necessary
that
all
these
constraints
are
also
satisfied
and
if
so
I
think
it
should
be
mentioned
in
the
drought
that
only
this
kind
of
templates
is
under
consideration
or
something.
K
N
Well,
Shannon
Erikson
I
think
this
compacts.
What
Andy
says
that,
if
you
are
not
forced,
for
example,
to
implement
intended
or
some
of
these
data
stores
and
if
you
choose
a
set,
the
specific
combination
of
data
stores
that
you
are
actually
implementing
each
of
the
for
each
of
these
combinations?
What
is
compliance
needs
well?
Which
parts
are
validated
how
that
the
flow
of
information
goes
true,
for
example,
for
us,
the
related
question
is
that
if
we,
if
have
a
model,
coffee
to
and
conflict
falls
mixed
up,
we
don't
show
the
called
operational
versus
running
differences.
N
K
So
I
think
that
to
answer
that
question,
whereas
before
you're,
comparing
like
running
with
config
faults,
you
actually
can
you
can
return.
That
is
in
a
single
get
operation
you
returning
the
intent
the
configuration
the
operator
is
asking
for
the
device
is
allowed
to
do
nothing
with
and
the
operational
States.
What
is
actually
doing
point
in
time.
So
if
you
had
a
large
company
that
had
a
system
running
a
large
amount
of
configuration
and
a
large
config
change
came
in
in
your
running,
you'd
see
the
new
configuration
and
all
the
operational
leaves.
K
The
config
for
sleeves
are
actually
related
to
what
it's
currently
doing
and
those
nodes
that
they
need
that
need
to
exist
for
it
to
be
able
to
to
be
as
returned.
The
data
might
not
even
be
there
in
the
new
configuration,
so
you
sort
of
stuck
with
the
existing
model,
whereas
with
this
one,
the
operation
of
state
they.
So
it's
obvious
you,
the
configuration
is
the
applied
configurations.
What's
there
and
running
in
the
system,
so
the
structure
always
logically
exists.
I.
N
K
Take
time,
okay,
so
the
other
question
was
about
intended.
For
example,
the
intended
datastore
just
degenerates
back
to
running.
If
you
don't
have
templates
support
or
you
don't
do
conked
out
conflict,
so
whether
you
allow
people
to
a
get
operation
on
that
or
not,
it
should
be
relatively
simple
to
code
to
just
point
to
the
same
data
as
in
running
I.
Take
the
question
about
in
terms
of
models,
but
about
validation
of
templates
I.
Think
that
needs
more
consideration
as
to
exactly
how
you
address
that
Chris.
F
Snaps,
those
Telekom
so
Phil,
you
just
said
something
it
confused
me
or
maybe
confuse
me
and
maybe
I.
So
if
the
interface
state
is
down,
do
I
lose
a
lot
of
my
operational
like
I'm
thinking
if
I
change
it
because
we
change
our
come
to
you-
is
that
something
I'm
gonna
run
into
where
I'm
only
gonna
see
it
and
intended.
If
the
interface
is
down.
E
E
F
E
A
F
E
R
Rick
Taylor
I'll,
try
and
keep
this
quick
I've
become
confused
about
the
difference
between
dynamic
and
learned.
I'm.
Really,
sorry,
I
can't
think
of
anything
that
has
an
origin
of
learnt
that
isn't
basically
just
dynamic.
It
may
only
get
set
once
right
at
the
bigger
you
know.
Your
protocol
may
negotiate
some
value
overriding.
Your
conflict
intended
value,
gets
overridden
by
the
negotiation.
Shorty,
that's
just
dynamic,
but
it
only
gets
updated
once
so.
K
This
this
identity
really
means
dynamic
data
store,
so
maybe
the
name
of
that
identity
should
be
dynamic.
Data
store
all
one
of
those
dynamic
data
stores,
so
so,
what's
learnt
then
learns
is
coming
from
a
protocol.
That's
not
not
one
of
the
configuration
protocols
and
not
through
a
dynamic
datastore,
so
something
that,
like
it's,
your
BGP
peers
or
your
therapy
peers
things
when
they
return
values
that
override
your
configuration.
That
was
what,
when
we
be
marked
as
learned,
configure
eight
known
values,
yeah.
R
E
R
A
F
Is
Christian
ops
again
so
I
do
have
a
suggestion
on
how
I
would
like
to
see
that
resolved
the
interstate
interface
down
State
thing.
It
came
up
earlier
in
routing
working
group
about
failures,
being
failures
that
happen
later
on
after
the
system
was
said:
ok
I've,
taken
that
value
right
and
I
replied
back.
Everything
went
ok
with
that
config
value,
but
later
on,
I
would
have
to
detect
a
failure
by
looking
into
operational
state
to
see
if
it
changed
right,
and
that
would
be
one
way
of
detecting
a
failure.
F
Another
way
might
be
a
notification
which
was
the
case
I'm,
not
working,
so
as
a
suggestion
for
how
to
determine
whether
something
is
in
use
like
MTU,
if
it's
not
available
condition,
I
kind
of
expect
it
to
be
applied
right,
so
in
other
words,
if
I,
if
I,
even
if
I
interfaces
down,
if
I
change
the
MTU
to
9,000
and
and
there's
just
no
case
where
that's
never
not
gonna
work.
When
the
interface
comes
up,
then
I
want
to
see
I,
think
change.
It
apply
right
because
there's
no
reason
for
it
not
to
yes.
F
K
Q
F
A
K
K
A
E
K
So
the
second
presentation
is
guidelines
effectively.
How
do
you
migrate
to
the
nmda
architecture?
This
is
the
same
presentation
I
gave
in
your
routine
working
group
earlier
today.
So
you've
seen
that,
so
you
can
tune
up
with
that
problem
definition
or
skip
over
that's
the
same
as
I've
just
presented
today.
In
terms
what
yang
models
look
like
in
various
drafts
and
different
bodies,
there's
really
three
fundamental
categories:
they
fit
into.
K
We've
got
the
ITF
split,
config,
state
top-level
style,
and
that's
like
the
interfaces
classes,
interfaces
state,
RFC
7230
has
that
style
and
the
the
interface
is
the
the
config
tree.
As
all
your
configuration,
the
state
tree
has
may
have
the
configuration
replicated
again.
It
may
be
slightly
different.
It
may
also
have
the
other
config
fall
sleeves
as
well.
So
in
this
particular
case,
ideally
they
would
marry
up,
but
they
don't
necessarily
do
that.
The
second
style
of
modeled
structures
we
come
across
is
the
open,
config
style
that
they've
been
pushing
forward
and
they're.
K
They
have
explicitly
config
and
state
containers
directly
above
wherever
the
configurational
leaves
are
so
as
soon
as
you
have.
Some
configuration
leaves
in
one
of
those
models
you
create
a
config
container
and
the
UK
create
PA
state
container
at
the
same
parent,
and
you
put
both
the
config
nodes
there
and
the
state
nodes
there
as
well.
That
uses
a
single
tree
structure
and
then
the
third
one
that's
obviously
I've
talked
about
here
is
the
combined
structure
as
well
as
the
nmda
style
is
a
single
tree,
but
without
any
replication.
K
So
as
an
example
to
try
and
illustrate
this
I'm
using
a
subset
of
the
BGP
model,
I'm
got
for
global
leaves
I'm.
Considering
two
in
blue
our
configuration,
the
ace
number,
the
reach,
ID
and
two
estate
leaves
the
total
partook
of
prefixes
I've
got
for
labor
labor
leaves
as
well
and
trying
to
put
those
that
in
to
illustrate
what
a
list
might
look
like
in
these
two
trees.
Two
of
those
these
config
two
of
those
are
in
a
container
and
state
notes.
K
So
what
does
that
look
like
so
I
start
with
the
ietf
split
confidence
state
tree.
That's
what
this
subset
of
bgp
would
look
like
on
the
left-hand
side.
You've
got
in
blue
you've
got
the
configuration
tree
named
bgp
with
all
the
configuration
on
the
right-hand
side.
You've
got
the
state
renamed
bgp
state
and
in
this
case,
I've
copied
all
the
configuration
leaves
across
to
that
configuration
nodes
and
then,
in
the
shaded
orange
boxes,
you've
got
the
config
false
notes
from
the
schema.
K
So,
although
the
whole
of
the
BGP
state
trees,
config
faults,
the
ones
that
are
liked
are
the
ones
that
copy
for
configuration
and
the
ones
that
are
shaded
and
those
real
sort
of
derived
data
operation
state
and
in
terms
of
how
you
produce
this
model
generally,
you
either
have
to
replicate
that
structure
by
hand
or
you
have
to
use
groupings.
So
you
get
the
same
structure
between
the
beach
piece.
Are
the
the
configuration
side
on
the
state
side
and,
in
my
experience,
the
models
I've
looked
at.
K
You
find
that
sometimes
these
state
trees
start
to
deviate
from
the
configuration
trees,
they're,
not
an
exact
one-to-one
representation.
So
you
can't
always
know
exactly
where
a
state
Leafs
going
to
exist
and
what
we
want
you
to
move
to.
Is
this
so
effectively
you
taken
those
config
four
state
leaves
ie
the
ones
that
aren't
a
duplication
of
the
configuration
and
you've
merged
them
in
into
the
appropriate
place
in
the
configuration
tree.
K
So
you
can
see
like
total
paths
and
take
the
prefixes,
have
just
moved
into
the
same
place
and
configuration
tree
under
the
same
parent
would
be,
and
likewise
with
the
ones
limit
out.
So
this
this
has
the
advantage
that
the
structure
is
guaranteed
to
be
right,
because
you've
only
got
one
structure
in
the
model.
You
can't
there's
no
separation
to
go
wrong
and
it's,
and
it
has
other
advantages
that
the
India
model
that
you
produce
is
generally
far
shorter
than
the
other
examples,
either
the
split
convict
state
tree
or
the
OSI
model.
Yes,.
O
Vodka,
so
here
in
this
example,
one
interesting
case
is
this:
router
ID,
because
if
I
remember
correctly
in
the
routing
data
model
base
feature
that
makes
this
router
ID
available
at
the
global
level,
or
something
like
that.
But
some
of
course,
if
this
feature
is
off
it
doesn't
mean
that
the
router
that
doesn't
have
any
ID
it
only
mean
that
there
is
some
algorithm
that
the
idea
becomes
assigned
automatically
somehow.
O
So
it
means
that
basically,
in
in
this
case
so
or
some
routers
will
have
both
outer
ID
in
configuration
and
in
Stata,
but
some
of
those
will
have
it
all
in
stay
later.
But
if
we
keep
this
a
feature,
for
example
on
this
router
ID,
we
need
to
distinguish
somehow
that
this,
if
you
want
to
have
just
one
they
tunneled
for
both
configurations
data,
it
means
we
have
to
somehow
distinguish
that
this
feature
does
is
not
does
not
hold
for
the
state
data
version,
so
things
like
this
will
will
come
up
very
often
so.
K
K
Right
but
we're
saying
so
effectively
in
this
case
we're
saying
that
honey
in
blue
saying
it's
confiture
doesn't
mean
it
has
to
be
configured
only
that
it's
configurable
and
a
and
we're
saying
that
if
you
configure
a
value-
and
you
end
up
using
a
different
value,
then
in
your
in
the
operational
tree,
you'll
see
that
different
value
and
your
seed
origin.
That
says
it's
a
different
value.
Camera
system,
whereas
who's
comfortable
configuration
will
be
see,
see
this
marked
with
the
same
values
come
from
the
intended
configuration
so
I
think
other
than
the
feature
comment.
P
Clarification
question
on
that
last
answer.
The
reason
the
router
idea
is
there
is
because
sometimes
people
configure
on
the
BGP
peer
another
router
ID.
Why
they
do
that
that
different
subject.
So
there
is
the
initial
one
that
lotto
is
pointing
to
very
nicely
and
then
there
may
be
a
different
one
by
understanding.
P
That's
those
are
two
facts,
my
question
and
clarification
because
this
can
be
set.
I
believe
it
operates
in
the
way
that
is
expected
in
the
BGP
configuration,
whether
the
that
it's
it's
unique
variable
how
its
populated
can
it
be
populated
from
the
base.
Or
what
are
you?
Are
you
saying?
Are
you
and
a
lot
of
saying
something
that
has
to
be
there
from
the
data
stories
that
just
general
logic
you're
trying
to
provide
I'm,
not
sure
I,
fully
answered
your
question.
K
It
that's
why
sometimes
it's
there
so
to
answer
your
question,
then
this
is
one
of
the
cases
I
think
the
Phil
described
a
sort
of
complex
default.
So
in
the
description
statement
of
the
data
model
under
the
router
ID,
that's
for
the
peer,
you
would
say:
if
there's
no
value
configured
here,
you
would
pick
up
the
value
that
is
assigned
to
the
global
Brewster
matter,
ID
effectively.
Okay,.
K
K
K
So
the
other
example
I'll
show
you
very
quickly
is
what
the
open
config
model
looks
like.
So
that's
this
again,
it's
the
same
leaves
here
as
I
was
mentioned
before,
under
or
above
each
configuration
leaf
like
the
AAS
and
the
route
ID
you
end
up
putting
in
a
config
container
and
then
as
appear
to
that
conflict
containing
you,
create
the
state
container
as
well
each
level,
and
then
you
put,
the
state,
leaves
underneath
that
state
container
as
a
copy,
both
of
learning
configuration
leaves
and
also
the
ones
that
are
traditionally
conflict,
falls
today
or
derived.
K
So
your
additional
state.
With
this
structure,
there
are
some
limitations,
because
it's
sharing
a
conflict
raise
any
one
tree.
So
in
elements
that
are
created
on
the
system,
like
I
mean
a
system
created
interface,
you
have
to
sort
of
bend
the
rules
of
yang
to
make
that
allowed,
because
you
can't
actually
it's
not
configured,
but
it
exists
in
a
conflict
tree
in
terms
of
a
get
operation,
for
example,
so
advantages
of
nmda
I,
don't
know
it's
worth
skipping
through
the
rest
of
this
slide.
Deck
I'll
bring
this
yeah.
K
Obviously
we're
saying
everyone
should
migrate,
their
model
is
in
Indian
architecture
and
all
the
ones
that
currently
published
will
be
revised
or
one
ones
that
need
to
be
revised
to
nmda
and
in
essence,
what
you're
doing
as
I
said
before
is
you're
copying.
The
config
false
leaves
in
the
state
tree
into
the
conflict
tree,
and
then
you
remove
the
food
state
tree.
K
It's
an
unpublished
draft
you
mark
as
deprecated
it
exists,
and
then
you
need
to
check
the
descriptions
for
some
of
these
cases
where
a
value,
the
configured
value
and
the
description
refers
to
a
configured
value
and
it
needs
to
be
massaged
a
little
bit
to
be
applying
better
consequence
state
and
then
the
other
thing
I
just
want
to
cover
is
well.
Can
these
modules
be
used
on
existing
Netcom,
Prescott
servers
and
the
answer
is
yes,
but
there's
two
conditions
where
there's
a
problem.
K
One
is
where
you
have
there's
no
way
of
reporting
the
applied
configuration
value.
So
if
you
had
some
protocol
configuration
like
the
MTU
on
that
Chris
mentioned
earlier,
there's
no
way
of
reporting
that
IMG
value
is
not
in
effect,
but
for
many
cases
like
the
MTU
example,
it
doesn't
actually
matter
what
you
put
in
is
normally
trivially
applied
over
some
period
of
time.
So
this
isn't
necessarily
a
breaking
thing
for
people
today
and
the
other
case
which
it
can't
handle
as
the
system
crated
objects.
K
So
this
new
combined
tree
of
interface
and
interfaces
States,
for
example,
you
be
able
to
rate,
represent
an
interface
a
system
created
interface.
Obviously,
when
you
have
the
nmda
that
comes
along,
that's
fine,
so
we
don't
Lisa
problem
for
most
modules.
But
for
the
case
that
there
is
a
problem,
then
you
can
easily
mitigate
this
by
creating
a
separate,
config,
false
version
through
States
version
of
that
module.
K
So
you
just
take
the
same
module
file,
the
chef
state
at
the
end
you
mark
it
all
conflict
faults
and
you
reuse
the
type
deaths
to
save
having
new
types
and
then
that's
a
way
to
something
you
can
use
until
such
times
nmda
implementations
available,
but
I
like
to
stress
that
we
only
expect
to
be
used
when
necessary,
put
in
the
appendix
avoid
if
you
can
and
it
waited
over
time.
Yes,.
S
Sorry
England
with
skin
quality,
so
I
had
this
situation
when
I
say
when
we
migrated
from
basically
I
don't
know
how
to
handle
without
nmda
situation
like
make
before
break,
say,
I
configured,
something
and-
and
it
succeeded
so
I
can
see.
If
there's
a
applied
configuration
right,
then
I
decided
to
modify
it
and
this
new
configuration
failed.
Okay,
so
with
the
nmda
architecture,
I
can
see
the
intended
configuration
my
laid
configuration
and
applied
configuration
which
is
currently
in
place
right.
So
if
I'm
not
using
MDA
right
architecture,
so
I
don't
know
how.
S
K
The
answer
is
you
can't
that's
point
one.
That's
effectively
mentioned
there
unless
you
create
this
duplicate
separate
tree,
but
in
many
cases
you
said
there
you
can
tell
that
when,
when
you
got
a
response
back
neck
home,
you
know
the
configurations
applied.
You
don't
actually
know
that.
All
you
know
is
the
system's
accepted.
The
configuration
will
act
on
at
some
point
in
the
future.
It's
not
guaranteed.
So
there's
lots
of
ambiguity
as
to
what
the
actual
semantics
of
net
conf
operations
say.
K
S
K
A
B
A
A
Actually,
we're
gonna
need
to
cut
the
line
because,
after
the
meet
echo
sorry
because
we're
really
over
and
we
worried
we're
gonna
steal
some
time
for
the
next
one.
So
this
question
and
then
okay,
we've
seem
to
have
lost
Eric
yeah,
so
if
he
shows
back
up
we'll
give
him
that
in
the
interim,
I
actually
want
to
ask,
the
question
is
share
that
the
their
key
from
all
this
is
not
only
us
getting
in
sync,
which
is
hugely
important.
It's
also
getting
agreement
on
the
language
that
goes
into
sixty
eighty
seven
bits.
A
K
O
K
K
A
C
Andy
Biermann
I
wasn't
going
to
go
to
the
mic,
but
you
started
talking
about
this.
Maybe
I
can
talk
with
camp
this
week
about
the
text.
But
what
are
the
guidelines
for
someone
who's
going
to
say?
Well,
I
want
the
the
keys
for
this
list
to
be
different
in
operational
state
than
they
are,
and
config
I
have
one
more
key
to
add,
or
they
say
the
operational
state
value
leaf
is
a
different
value
set.
C
A
Yeah
so
there
there
was
a
slide
deck
with
some
QA
in
it.
That's
good
to
look
at
also.
There
was
a
couple
of
questions
that
came
in
through
jabber
that
didn't
get
it
to
the
mic
because
we
were
cut
I
will
copy
in
the
jabber
questions
into
the
ether
pad,
so
that
become
part
of
the
record
and
actually
jabber
is
always
available
as
part
of
record,
either
way
and
sorry
for
not
getting
to
the
jabber
people.
H
Okay,
so
I'm
William
Lawton,
representing
broadband
forum,
I'm,
the
broadband
forum,
Software
Architect
I've
got
ten
minutes,
and
so
I
just
want
to
give
a
quick
update
on
broadband
forum
and
what
we're
doing
with
the
yang
and
sort
of
what
principles
were
applying
so
I
want
to
cover
all
this.
Very
briefly,
you
know
what
do
we
regard
as
being
in
an
out
of
scope?
What
are
we
currently
working
on
and
what
have
we
published?
How
do
we
publish
what
about
draft
yank?
H
Obviously,
where
I
remember
organizations,
so
our
work
is
not
all
publicly
visible
and
what
about
the
yang
catalog
and
then
finally,
a
little
bit
on
sort
of
best
practices
and
well
dependencies
on
external
young
and
best
practices,
so
our
emphasis
is
on
addressing
our
own
requirements
rather
than
on
general
solutions.
I
mean
we
don't
actively
avoid
general
solutions,
but
that's
what's
driving
us,
which
I
think
is
you
know
a
contrast
force
with
Korres
do
such
as
ITF,
where
I
think
the
emphasis
is
more
on
providing
something
generally
useful
and
our
current
emphasis
is
on.
H
We
will
call
broadband
access
nodes,
so
the
equipment
sort
of
between
the
home
and
the
and
the
internet,
for
example,
those
of
two
of
our
main
standards
that
are
providing
the
requirements
that
are
driving
our
current
work
and
so
will
define
in
BBF
yang,
where
it's
for
things
that
we've
defined
or
yang,
where
it's
for
things
other
people's
have
defined,
but
they
have
defined.
But
the
organization
is
not
interested
in
defining
it.
H
So,
for
example,
some
of
the
first
yang
we
did
was
four
so
ITU
unphysical
our
standards
and
we
will
reuse
yang
from
other
organizations
whenever
it's
possible.
So
these
are
our
current
projects.
Substrain
the
areas
on
the
Left
and
sort
of
internal
project
names,
just
quick
description.
Then
you
can
see
that
the
top
right
to
the
ones
we've
actually
published,
which
I've
got
a
little
bit
more
information
on
in
the
upcoming
slides.
And
then
you
can
also
see
in
bold
there's,
one
project
for
which
we
published
draft
yang.
G
H
Well,
okay,
it's
lost
a
picture.
It
was
a
beautiful
picture,
but
I
was
never
going
to
go
through
the
picture
in
detail
anyway,
so
these
were
the
first
ones
we
published
back
a
year
ago,
so
these
were
the
ones
I
just
mentioned.
Actually,
the
itu-t
ITT
physical,
our
standards
for
video
cell
2g
that
fast
and
also
some
sort
of
associated
sort
of
like,
for
example,
handshake
handshake
protocol
there
that
I've
got
more
of
on
dependencies
on
ITF,
but
they're.
H
The
main
dependencies
was
was
on
the
interfaces
model
and
we're
now
working
on
some
new
features
and
I'll,
giving
you
some
examples:
they're
bonding
in
Reverse
power
feed.
Then
there
would
have
been
a
picture
that
just
showed
the
modules
and
their
dependencies
lots
and
lots
of
sub
modules
here.
Actually
these
are
quite
complex
standards,
but
only
a
small
number
of
module
or.
A
H
Press
the
button
too
far
below
this
is
the
other
one
which
are
what
we
call
the
common
yang
modules
for
access
networks.
These
have
also
been
published.
So
the
idea
is
that
these
are
applicants.
It's
a
little
bit
analogous
with
net
mod
I
think
these
are.
These
are
modules
that
we
expect
to
be
widely
applicable
and
so
similar
arm
dependencies,
but
also
ITF
system,
an
RTO,
I
tip
Hardware
there.
It's
a
draft,
obviously
we're
aware
that
we're
going
to
have
to
think
about
how
to
apply
the
the
data
stores
here.
So
thank
you
for
that.
H
We're
also
working
on
some
new
features
there
and
I've
listed
some
there
and
no
alarm
management.
That's
another
dependency!
There!
I!
Don't
expect
you
to
be
able
to
read.
What's
on
that
picture
there,
but
it's
just
showing
you.
Those
are
all
modules
as
opposed
to
sub
modules
and
it's
showing
import
dependencies
and
it's
also
showing
areas,
and
it's
also
showing
external
organizations.
There
are
the
various
and
containing
boxes
and
colors.
So
how
do
we
publish
it?
We
have
a
software
release
registry,
which
is
a
grand
name
for
just
a
wiki
page
that
lists
everything.
H
We've
published,
including
both
draft
and
standard
yang.
It
all
goes
into
this
broadband
forum
area
yang
repository
in
github
with
separate
areas
for
draft
and
standard,
and
then
it's
also
all
available
far
the
sort
of
de
facto
standard
young
models
yang,
a
repository
via
a
sub
module
which
just
points
to
the
above
BBF
owned
module.
There's
some
examples
in
the
background
slides
draft
yang
for
some
projects.
In
fact,
only
really
one
sorry,
we've
made
draft
young
available
for
study
purposes
does
have
a
different
license
and
that's
in
that
area
of
the
of
the
github.
H
But
we
are
currently
working
on
making
sure
that
such
draft
yang
is
available
across
the
board
for
all
projects
and
will
be
updated
recently.
Frequently
I
mean
we
wouldn't
expect
every
commit
to
be
visible.
We
would
still
expect
there
to
be
some
sort
of
decision
to
make
it
available,
but
we
want
a
very
low
bar
on
making
that
decision
and
also
just
as
a
plug,
really
all
the
all
the
bots
draft
and
standard
yang
is
available
in
the
young
catalog,
so
I'm
going
to
flip
through
these
at
the
rate
of
about
one
every
two
seconds.
H
So
you
could
go
into
the
catalog
and
you
could
do
a
that's.
A
cunningly
constructed
regular
expression,
search
that
only
matches
one
thing
and
then
you
would
get
this
and
then
you
could
click
on
the
impact
analysis
and
you
would
get
there
this
from
which
you
can
see
that
some
there's
a
draft
BBF
module,
which
is,
is
it
green,
I'm,
not
sure
I'm,
Cala
blonde,
which
is
dependent
both
on
some
published
BBF,
yang,
Ananse
and
published
IETF
yang?
H
So,
ok,
just
to
put
it
all
into
one
place
back
to
external
Yang's.
So
we
do
have
a
policy
that
that
our
modules
must
use
external,
particularly
iron
and
IETF
young
yang
modules,
whenever
possible,
I
reduce
or
to
said
that.
But
we
did
this
isn't
just
this
is
intended
to
be
letter.
Adherence
to
the
letter
and
the
spirit
you
know,
we
really
would
do
want
to
be
using
these
modules
as
they
were
intended
to
be
used
I'm
just
to
pull
it
all
together.
H
Those
are
the
ones
were
currently
dependent
on
directly,
and
then
I
also
mentioned
this
already,
but
we
the
pub
the
the
stuff
we're
working
on
at
the
moment,
I'm
also
very
much.
We
intend
to
depend
on
the
ITF
alarms.
I
mean
this
is
actually
a
very
active
area
at
the
moment
that
we're
working
on
internally
and
then
just
finally,
we
also
have
our
own
sort
of
version
of
our
own
sort
of
young
best
practices
which
is
based
on
and
adheres
to
sixty
eighty
seven
bits
as
much
as
possible,
I
mean
in
the
future.
H
It
could
also
equally
refer
to
other
SB
o--'s,
but
right
now
it's
it's
ITF.
So
it's
a
mixture
of
qualification,
two
and
extensions
of
guidelines
that
are
in
687
bits,
but
also
there
are
some
additional
BBF
specific
guidelines.
We
do
plan
to
share
that
with
you
guys
because
haven't
got
around
to
deciding
how
best
to
do
that
yet
and
also
there
are
some
more
detailed
examples
of
guidelines
in
both
those
two
categories.
In
the
background,
slides
and
that's
it.
A
A
K
H
H
The
particular
implications
for
us
will
be
the
two
IETF
modules
that
we're
dependent
on
that
have
this
split,
which
would
be
the
interfaces
module
and
the
hardware
module
and
we're
just
going
to
have
to
deal
with
it
and
I
presume.
We
will
do
it
in
the
same
way
that
we
will
I
mean
I,
know,
there's
some
discussion
of
exactly
what
deprecated
means
at
the
moment,
but
we
will
I
presume
I'm,
not
sure
which
should
be
the
core
one.
The
state
one
I
think
is
the
proposal,
so
we
would
I.
H
Guess
is
that
right
we
would
deprecated
the
config
and
and
bring
the
config
into
the
core
or
the
other
way
around.
Okay,
we're
doing
the
way
around
we're
requested
to
do
it
and
just
to
take
the
hit
on
on
how
we
managed
how
we
decide
to
publish
that
and
and
so
on,
I
don't
see
that
we
have
any
option
we
weren't,
we
won't
ignore
it
all.
G
A
Back
to
the
Q&A
we
actually,
while
we
use
most
that
time
or
all
that
time.
This
time
we
have
a
talk
that
was
supposed
to
be
given
that
Alex
isn't
gonna
be
able
to
give
tomorrow.
No,
no,
you
said
you
are
gonna,
give
it
never
mind.
I
was
gonna
steal
your
time.
Oh
well,
good
thing,
you're
sitting
here
now
protected
it.
Alright,
we
have
10
seconds
left
so.
C
C
C
A
Right
this
was
for
discussion.
This
is
things
that
need
to
be
looked
at,
so
Rob
had
looked,
went
and
identified
some
RFC's
that
bear
some
investigation.
This
isn't
our
list.
As
chair
saying,
we
are
absolutely
doing
this.
This
was
input
for
discussion
it,
the
slides,
are
there.
They
were
intended
to
get
discussion
going.
Let's
get
the
discussion
going
on
the
list
all
right
with
that.
Thank
you
very
much,
and
we
will
see
you
at
the
next
session,
which
is
Wednesday
at
1:30
right
back
here.