►
From YouTube: IETF103-NETMOD-20181108-1610
Description
NETMOD meeting session at IETF103
2018/11/08 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
On
the
administrative
side,
we
are
doing
our
usual
audio
and
video,
please
make
sure
to
say
your
name
at
the
mic.
We
do
have
blue
sheets.
That
Mike
the
chair
will
hand
off
that
are
going
around
please
sign
up.
We
will
be
doing
our
usual
note-taking
on
etherpad.
Please
look
at
the
link
here
and
jump
on
it
and
help
us
take
notes.
It's
also
available
from
the
tools
page,
if
you
find
that
easier
to
get
on,
I
will
be
on
jabber
and
I,
see
that
we
have
folks
who
are
in
the
room
also
on
jabber.
B
Yeah
so
hi
Christian
hops
and,
as
Lou
said,
the
module
tags
draft
went
into
working
group
last
call
and
we
got
some
lively
comments.
Go
over
the
changes,
pretty
much
adopted.
B
So
right
so
pretty
much
adopted,
I
say
adopted
all
suggestions.
It
was
actually
one
that
came
after
that
we
didn't
adopt
and
the
changes
were
to
add
an
extension
statement
for
predefined
tags,
so
that
would
be
machine
parsable.
That
was
the
one
that
I
think
garnered
the
most
sort
of
contention,
because
I
pushed
back
on
that
I
didn't
think
there
was
a
need,
but
it
doesn't
really
hurt
to
have
it.
B
B
So
the
extension
statement
before
I
put
that
it
should
just
be
in
the
description,
because
my
thinking
was
the
predefined
tags
would
be
added
by
the
author
that
the
implementers,
so
they
had
to
write
code
anyway,
something
would
be
reading
the
module,
it
wasn't
actually
something
that
would
be
machined
parsed.
But
you
know,
machine
parsed
is
better
than
random
text.
I
guess
so,
and
it
doesn't
hurt,
it
doesn't
actually
cut
make
it
harder
to
implement
this
to
have
this
extension.
B
C
C
B
A
B
B
A
F
B
And
also
the
length
saying
it
was
one
to
max
so
the
structure
changes.
This
was
basically
just
I
guess
best
practices
Martin
likes
a
container
so
before
it
was
just
the
list.
So
you
just
have
module
tags,
module
tags,
module
tags
in
your
XML
throws
XML
now
it'll
be
module
tags
and
inside
that
module
module.
B
So
the
other
comments
that
were
on
the
working
group
last
call
there
was
a
request
for
non
MBA.
Appendix
version
I
disagreed
with
this,
and
also
somebody
else
did
who
didn't
really
get
any
other
comments.
My
thinking
was
not
only
is
it,
this
is
brand-new
work.
It
won't
be
deployed
for
a
little
while
and
also
from
an
operator
standpoint.
I
I
don't
want
to
make
it
really
easy
for
people
not
to
implement
an
MDA.
So
this
you
know
if
you're
gonna
do
this.
You're
gonna
have
to
do
nmda.
B
If
you,
if
you
want
to
support
that
it'll
work
without
it,
it
just
won't
work
as
well,
and
there
was
a
email
exchange
on
just
even
clarifying
justifying
the
use.
So
that's
pretty
much.
It
I
think
that
covers
all
the
comments
that
we
got
and
like
I
said
this
was
a
new
version
that
was
pushed
out
during
worth
of
the
blast.
Call.
B
G
Read
this
during
working
group
last
call
he
well
or
or
before
I
mean
that
was
version
o
too
so
I
think
we
have
a
pretty
good
sense
of
a
pretty
good
population
in
the
room
of
people
who
had
the
opportunity
to
comment
on
it
during
last
call
or
there
abouts
and
are
actually
reasonably
familiar
with
it.
So
are
there
any
changes
to
the.
B
I
H
And
now
for
something,
everybody
loves
the
Thank
You
polish,
the
product
of
so
last
time,
Rob
Wilton
presented
the
requirements
for
our
yang
versioning
design
team.
This
is
the
update
to
that
which
I
dissipate
will
have
absolutely
no
one
saying
anything
as
we
work.
We've
met
numerous
times
as
a
design
team,
both
physically
here
at
IETF
103.
We
met
at
IETF
102,
we
talk,
we
had
external
conversations
with
stakeholders
and
we
met
many
times
on
the
call.
This
is
the
design
team
you
can
see
here.
H
Changes
since
version
zero,
zero.
We
added
some
terminology
specifically
around
what
we
mean
when
we
say
non
backwards,
compatible
and
I'll
get
to
that.
We
had
it
as
some
clarification
on
what
clients
should
do
if
they
get
incidents
data
from
a
server
that
they
do
not
understand.
So,
for
example,
7950
section
11
really
talks
about
what
to
do.
If
a
client
tries
to
do
an
edit
config
or
change
something
and
those
the
modules
that
they're
changing
should
be
backward
compatible.
H
But
what
if,
for
example,
you
have
a
CPU,
something
that
represents
a
CPU
and
initially
you
do
a
range
of
1
to
100
and
you
realize
a
CPU
can
be
0%,
so
you
add
0
and
now
a
client,
an
old
client
reads:
0
if
it
doesn't
get
so
we're
saying
we
just
added
some
clarification
to
say
a
client
should
be
able
to
handle
that
I'm
not
going
to
go
into
any
more
detail
on
that
one.
We
reworded
requirement
1.2
and
I'll
get
to
that
and
we
added
a
new
requirement,
1.4
and
I'll.
H
Get
to
that,
and
there
has
lately
been
some
discussion
around
requirements,
3.1
and
3.2
and
I'll
talk
about
that.
So
these
are
the
requirements.
Terminology
wise.
We
define
non
backwards-compatible
in
accordance
with
RFC
7950,
section
11,
but
we
also
add
that,
with
respect
to
this
document
in
our
requirements,
non
backwards-compatible
takes
into
account
the
status,
so
the
status
means
that
any
addition
or
change
of
a
status
that
would
allow
a
server
to
remove
support,
for
example,
going
to
obsolete
results
in
a
non
backward
compatible
change.
H
The
NVC
part
is
actually
a
parenthetical
in
the
draft
we
say
BC
to
mean
a
backwards
compatible
change.
Nbc
is
non
backwards,
compatible
non
backwards,
compatible
change
when
Rob
gets
up
here
to
talk
about
solutions.
So
hold
all
your
questions
for
him
here.
We'll
talk
about
the
head
of
a
branch
or
the
head,
the
yang
module
at
the
head,
and
in
that
regard
it
means
the
most
current
in
development
history,
as
you
would
think
of
a
revision
control
system
being
the
head
or
the
master,
the
the
head
or
tip
of
the
of
the
branch.
H
That's
terminology
requirement.
1.2.
We
wanted
to
simplify
the
text
so
that
the
new
text
and
requirement
1.2
says
that
any
non
backwards
compatible
updates
of
a
module.
So
let's
say
I
change
a
one
node
a
leaf
in
a
non
backwards
compatible
way,
but
I
don't
touch
any
other
Leafs
within
the
module
that
must
not
impact
clients
that
access
only
modules
that
have
not
been
updated
in
back
or
been
updated
and
backwards
compatible
ways.
H
H
We
added
a
new
requirement:
I'm
gonna,
put
this
down.
I
anticipate
I
might
be
here
for
a
minute
on
this
slide,
the
design
team
discussed
that
there
is
going
to
be
despite.
We
don't
necessarily
want
to
do
this,
but
this
is
going
to
happen.
We
are
going
to
have
the
instance
where
we
have
a
module
at
an
older
version.
Let's
say
one
dot.
X
we've
since
made
some
changes.
H
We've
created
a
a
branch,
a
2
dot,
X
version
of
that
module,
we're
making
changes
to
2
dot
X,
and
we
have
to
go
back
and
we
have
to
make
a
fix.
We
have
to
do
some
kind
of
change
to
1
dot.
X
vendors
do
this
today
and
in
fact,
on
the
design
team
sue
Harris
mentioned
that
this
is
something
that
could
potentially
happen
within
the
standards
body
in
some
IDR
work,
where
we
have
to
kind
of
parallel
streams
of
modules,
and
we
wanted
a
requirement
that
says
this.
H
J
Here
from
Google-
and
why
is
this
requirement
phrased
in
terms
of
a
single
module
needs
to
be
needs
to
have
deal
with
this
in
this
case
right,
because
you're,
basically
saying
I
must
be
able
to
fork
any
point
in
the
branch
an
arbitrarily
cherry-pick
from
any
point
in
time
and
I
want
a
single
versioning
scheme
that
deals
with
that.
But
we
have
augment
and
deviation
stainless
I.
J
Think
Christian
actually
made
this
point
elsewhere,
all
right,
so
the
union
of
in
any
server
is
going
to
have
a
you,
the
set
of
modules,
this
portion,
it's
really
there's
some
versioning,
that's
based
on
the
union
of
them
all,
so
you
can
fix
a
number
of
these
things
so,
like
I
want
to
enhance
version,
one
lazier
and
we're
at
version.
42.0
I
can
add
some
new
augmentation
that
adds
in
features
without
changing
the
version
or
wonders
there.
Alright,
so
I
think
you
kind
of
made
this
problem
statement
very,
very
specific.
H
J
H
So
we
we
talked
about,
we
talked
about
deviations
and,
if
feature
we
again,
this
is
the
requirement
the
there
could
be
a
number
of
solutions
that
address
this.
We
want
to
be
able
to
have
the
capability,
the
requirement
to
be
able
to
fix
these
things,
to
fix
it,
to
make
these
bug
fixes
in
non
latest
releases
and
allow
for
the
solution
to
accommodate
that.
K
Rebuilding
Cisco
to
speak,
to
speak
to
Rob's
from
his
point.
I
think
that
if
you
use
either
deviation
or
augmentation,
you
lose
the
sort
of
continuity
of
that
fix.
So
you
can't,
unless
you're
going
to
carry
that
augmentation
through
all
time,
which
you
don't
necessarily
want
to
do
or
use
a
deviation,
then
I
think
you
end
up
with
losing
it's
harder
for
a
client
just
to
see.
K
J
We
have
that
problem
anyway.
Right,
do
you
can't
use
an
individual
module
by
itself,
so
when
we
inside
the
catalog
work,
we've
specifically
said
this
is
why
we
have
the
idea
of
release
bundles
right.
We
have
a
bundle
of
modules
that
need
to
work
together,
so
we
already
have
a
multiple
version
problem
like
a
or
module
version
of
a
no
release
set
together.
So
it
doesn't.
J
There's
another
module
in
there
to
fit
to
fix
this
problem
and
I.
Think
I
did
rather
mix
this
problems.
They
may
have
with
this
statement,
which
is
why
is
it
this
within
a
single
module
with
a
potential
solution
that
I
think
that
the
requirement
here
is
you
want
to
be
able
to
change
older
version
right
in
some
particular
way,
I
understand
that
you've
shipped
some
version
not
having
it
and
the
way
your
character,
is
it
based
on
software
release,
etc.
I
think
we're
just
creating
huge
complex.
Thank
you.
I.
H
I
get
I,
so
yes,
I
I,
the
the
term.
The
wording
of
this
might
that
the
spirit
of
this
wording
is
there
are
multiple
train
streams,
releases
of
software
and
our
customers,
and
this
was
expressed
in
the
design
team,
have
a
need
to
have
fixes
to
releases
that
aren't
the
latest.
This
is
where
this
requirement
came
from
and
we
found
that
there
might
be
needs
within
standards
bodies
to
do
the
same
thing.
How
do
we
address
that
right?.
J
H
That
III
would
agree
that
that
the
way
this
is
stated
is
confusing.
Christus.
A
B
Christian
hops
yeah,
so
I
actually
love
the
wording,
because
it's
exactly
what
you
want
right
and
as
an
operator,
it's
exactly
what
I
don't
want.
You
know:
I,
don't
I,
don't
want
your
developers
off
making
a
change
on.
You
know:
XR
I'm,
sorry,
the
specific
version,
X
and
version
Y
right,
and
these
two
teams,
maybe
don't
work
together
right
and
so
version
X
developers
are
over
there
and
they're
making
some
changes
and
they've
got
some
automated
tools
and
it
pushes
it
in
in
whiz-bang,
because
I've
got
versions.
B
Now
it
changes
the
major
because
it
sees
its
incompatible
and
why
over
here
is
doing
their
development
separately
and
whiz-bang.
It
works
because
we've
got
these
versions
now
right
and
as
an
operator,
I'm
screwed,
because
now
I've
got
all
these
different
stupid
incompatibilities,
because
people
couldn't
get
together
right
and
create
a
single
train
for
the
AP
is
that
your
shipping
and
the
whole
point
of
net
mod
right
was
to
get
away
from
CL
eyes
and
into
all
these
little
differences
all
over
the
place.
B
B
If
you
restricted
major
version,
changes
to
non-structural
I'd
be
good
with
it,
but
I.
Don't
think
that's
what
you're
doing
I
guess.
The
last
thing
I'll
say
is
I'd
like
to
see
some
use
cases
because
I
keep
hearing
you
know,
I
mean
we
can
all
and
we
can
Oh
picture.
We
can
all
picture
hand.
We
can
all
picture
the
changes.
You're
talking,
you're
bug
fixes.
Oh
my
customers
I'm
your
customers.
B
Your
customers
want
bug,
fixes
I'm,
not
your
only
customer
I
understand,
but
your
customers
want
bug
fixes
right,
but
I
mean
like
Rob
was
talking
about,
like
I'd
like
to
see
some
justification
for
these.
These
things
that
can't
be
done
with
the
other
mechanisms
we
already
have.
You
know,
because
it's
just
it's
sort
of
tenuous.
It's
like!
Oh
there's.
B
These
bug
fixes
you
might
want
to
make
I
mean
I,
know
the
use
case
that
people
want
to
use
this
for,
and
it's
not
for
these
bug,
fixes
it's
it's
to
be
able
to
just
freely
release
multiple
trains
of
modules
and
and
that
the
scale
there
is
the
vendor
is
a
small
number
of
people.
The
users
is
a
large
number
of
people.
Your
impact
is
very
large
right,
so
we
have
to
be
very
careful
about
who
we're
making
things
easy
for
all
right.
B
H
H
We
talked
about
a
BGP
module,
a
1.0
of
a
BGP
module,
and
we
want
to
introduce
this
concept.
This
new
backwards,
compatible
concept
called
BGP
groups
in
1.1,
it's
backwards
compatible,
but
so
now
we
have
a
1.1
and
we
have
a
1.0.
A
customer
comes
along
and
says:
I
found
a
bug
that
requires
a
actual
fix
to
the
module
which
we,
it
might
be
rare,
that
the
module
fix
might
be
rare,
but
let's
say
they
do
require
a
fixed
to
the
module
in
one
dot.
H
H
Now
we
can
protect
that
behind
if
feature,
we
can
deviate
the,
and
this
is
why
I'm
now
getting
into
the
solution,
because
now
I'm
getting
beyond
the
requirement
and
the
solution
stuffs
debatable,
but
now
we're
adding
all
this
extra
baggage
to
these
yang
modules
as
we
go
baggage
that
that
kind
of
has
to
exist
for
a
long
time.
So
the
Rob
will
talk
about
the
solutions
that
we
arrived
at
and,
in
fact
one
of
the
things
you
said.
H
Chris
was
very
pertinent
in
the
sorry
Rob
I
see
you
going,
I'm
gonna
kill
you
later
on
Joe
and
that's
fine
I
accept
death.
One
of
the
things
that
Rob
will
talk
about
in
his
slides
is
he
has
that
spectrum
hard
for
operators
hard
for
vendors,
and
we
we've
said
explicitly.
We
wanted
ultimately
we're
gonna,
walk
away
compromise
so
that
nobody's
happy.
It's
a
comprar
mind
the
happy
medium.
H
We
that
the
problem
space
is
real
though,
and
these
are
the
requirements
be
it,
they
might
need
to
be
wordsmith,
but
these
are
the
requirements
that
we,
as
a
design
team,
feel
that
this
will
achieve
the.
If
we,
if
we
can
satisfy
these
requirements
and
maybe
their
trade-offs,
we
will
achieve
something
that
ultimately
is
a
better
solution
to
the
problems
we're
facing.
H
We
say
we
must,
but
this
could
be
areas
as
we
implement
this,
as
we
discuss
the
solutions
to
these
requirements
that
we
have
to
say,
look
we're
going
to
then
wrangle
or
we're
going
to
fence
what
types
of
changes
can
be
made
to
these
other
historical
streams,
we're
gonna
limit
branching
and
again.
We
might
not
see
so
much
of
this
because
it's
a
module-
and
maybe
there
isn't
a
need
to
bug
a
nullpointerexception
null
pointer.
H
Dereference
till
do
bug
fixes
in
my
code,
but
we
want
to
allow
vendors
are
gonna.
Do
this.
We
want
to
allow
some
kind
of
fence
around
this
some
sort
of
quantification
of
this,
and
that's
why
we
wrote
the
requirement
and
okay
we'll
change
the
wording,
but
that's
why
we
built
the
requirement,
because
we
want
the
solve
for
the
vendor
problem.
We
want
to
solve
for
the
standards
problem
as
best
we
can
I.
A
M
Yeah
Rochelle
Robin
sisqó
I,
actually
forgot
what
I
wanted
to
say.
It's
been
so
long
waiting
here.
Actually
I
wanted
to
reply
to
Chris,
who
I
think
you've
sent
an
email
to
you're,
worried
that
this
is
just
going
to
give
Anders
a
free
card
to
say:
I
can
screw
up
the
users
whenever
I
want
to.
This
is
not
the
goal.
If
you
think
there's
never
need
to
know
any
NB
C
change,
then
we're
done,
but
sometimes
that
change
will
be
needed.
This
is
a
way
of
addressing
that
and
yes,
I
think
we.
M
K
Robots
in
system
nicely,
let's
say
the
same
comments.
Chris
is.
It
is
not
our
goal
to
give
carp
lunch,
that's
so
we
can
change
this
text.
The
goal
is
to
allow
for
bug,
fixes
potential
enhancements
and
to
have
a
way
of
describing
what
those
are.
So
you
could.
As
a
as
a
user
of
those
modules,
you
can
understand
what
the
changes
happened.
So
that's
that's
our
goal.
J
Probably
Google
again
I
think
that
you're
those
multiple
requirements
from
distilling
this
conversation
that
you've,
you
said,
there's
a
problem
about
how
do
I
release
my
software,
such
that
I'm
able
to
link,
understand
the
set
of
functionality,
that's
in
it
and
to
be
able
to
granularly
choose
what
to
to
up
right
and
what
not
to
and
then
there's
the
problem
of.
What
does
the
module
version
itself?
J
Look
like
perhaps
a
good
thing
to
do
is
to
explain
what
the
release
problem
is,
because
that
this
is
kind
of
the
Union
of
modules
problem
anyway
and
then
discuss
how
that
that's
implemented
across
both
servers
and
tooling,
because
if
I
look
at
our
toolset
right
now,
we
we
do
something
similar
to
what
I
was
suggesting
right.
So
we
have
a
set
of
changes.
We
have
a
bunch
of
clients
that
haven't
moved
and
we
maintain
these
really
small
compatibility
modules
and
they're
there
to
say.
J
Okay,
this
deviated
out-
or
this
leaf
is
still
here
and
then
we
go
and
work
with
all
the
folks
to
move
which
is
equivalent
to
your
customers,
who,
upgrading
so
and
I,
haven't
found
that
a
big
problem
in
terms
management
and
it's
quite
clear
to
me
how
I
version
my
set
of
releases
like
my
generated
code
or
whatever,
is
the
people.
That's
the
API
that
my
my
users
are
integrating
against.
J
So,
like
I
think
we
should
break
it
down
and
figure
out
what
those
look
like,
because
I
really
don't
think
that
this
problem
space
really
is
a
difference.
Its
own
approach
in
the
version
and
in
module
to
meet
the
same
requirement
and
I
just
want
to
say
that
I
think
we
should
make
it
super
hard
not
to
have
a
single
head
like
I,
think
anything,
that's
encouraging
you
to
have
9
million
different
branches,
where
you
cannot
merge
them
back
together,
which
we
see
software.
That
does
this
every
day
like.
J
H
I
agree-
and
this
is
some
of
the
things
that
we
talked
about
as
coming
out
of,
in
fact,
some
of
what
you
just
said
around
the
compatibility
shims.
We
in
fact,
even
today
talked
about
things
around
that
space
from
a
solution
standpoint,
but
from
a
requirements
standpoint
independent
of
how
this
is
worded.
It's
not
just
the
vendors
there.
There
has
been
expressed
a
need
to
have
a
non-linear
need
to
update
modules,
maybe
not
willy
nilly,
but
it
has
been
expressed
so.
J
Let's
write
those
things
down
because,
as
the
original
or
one
of
the
original
authors
of
the
BGP
model
that
you've
referenced
in
idea
and
as
probably
I
think
only
person
is
room,
that's
maintaining
a
semantically
version
set
of
yang
modules
is
one
of
the
leads
of
a
project.
I'm,
not
sure
my
experience
matches
with
your
impassioned
plea
for
this.
N
J
If
an
operator's
toolchain
can't
pick
up
one
compatibility
module,
there
is
a
bigger
problem
with
their
compatibility
tool
chain,
and
so
remember
here
you
have
a
conversation
with
your
customers,
in
which
you,
may
you
not
be
allowed
to
say
no,
the
or
encourage
not
to
say
no
or
they
might
have
enough
dollars
that
thing.
There
is
not
a
thing
the
ATF
does
not
have
to
operate
under
those
constraints,
so
you
can
version
your
modules.
You
know
forty
seven
different
point
releases
and
use
the
entire
Unicode
character
set
as
part
of
the
the
versioning.
K
B
J
We're
not
we're
not
saying
that
we
go
back
and
change
an
old
module,
so
the
old
module
keeps
its
exact
same
version
and
then
the
Union
set
modules
lets
you
link
them
together
and
that's
what
exactly
what
you
can
do
in
your
code
without
with
having
semantic
versioning
for
young
modules,
so
that
if
you
want
to
talk
about
how
to
do
release
bundle
versioning,
that's
maybe
a
different
problem.
But
I
think
that
you
can
use
semantic
version
for
both
release,
bundles
and
for
individual
modules
and
what
just
fine.
K
So
I
think
it's
more
Rob,
Wilton
I
think
it's
more
that
you're
you
suggesting
that
the
modules
will
do
deviations
to
fix
it
or
augmentations,
but
but
I,
don't
think
so.
I
think
that's
a
solution
to
this
ignore
the
first
line
and
the
second
line.
That's
a
way
of
handling
I
need
to
do
bug,
fixes
and
enhancements
for
all
the
modules
the
language
already
has.
J
So
the
problem
here
is
that
this
is
meant
to
be
a
requirement
about
how
to
put
a
version
in
a
yang
module
right
but
you're,
but
there's
been
other
work
to
try
and
address
this
like
we,
we
put
the
catalog
draft
into
into
the
working
group
link.
I
know
three
years
ago,
four
years
ago,
someone
someone
can
check
the
date,
but
so
I
don't
understand
why.
This
is
a
requirement
that
relate
at
all
to
the
version
I
put
in
a
na-yang
module
and
when
we
originally
raised
the
the
versioning
problem.
B
O
B
A
O
H
H
H
We
found
that
very
hard
what
we
wanted
to
be
able
to
do
with
this
requirement.
Independent
of
the
first
line
was
really
about.
As
we
discussed
this
on
the
design
team
amongst
all
of
us.
We
we
kept
circle
and
going
back
and
forth
because
we
had
a
need
based
on
what
our
customers
came
to
us,
as
is
so
what
Chris
just
said.
There
was
some
big
like
kind
of
low-hanging,
fruit
and
I.
Think
Rob
Shakir
said
it
as
well
low-hanging
fruit
with
things
we
had
to
fix,
and
then
we
started
to
talk
about.
H
J
What
vendors
do
are
going
to
do
anyway,
should
not
be
endorsed
by
the
ITF
right
like
please
pray
the.
How
do
we
solve
this
problem
correctly
from
how
shitty
is
this
release
gonna?
Be
because
it's
it?
This
is
like
the
problem
is,
if
I
look
at
your
versioning,
if
I
look
at
my
versioning,
they're
gonna
be
entirely
different,
and
so
it
as
soon
as
we
try
and
have
this
problem
space
of
trying
to
link
link
these
behaviors
with
it
within
a
certain
release,
train
into
something
wider.
J
That's
in
the
module
and
we're
both
kind
of
disagree
and
to
the
point
about
it
bug
fix
I
mean
we
tried
to
write
a
doc
there's
a
doc
on
an
open
conflict
net
that
describes
the
semantic
versioning
approach.
We
use
and
lists
a
set
of
criteria
for
what?
What
do
we
consider
as
a
as
a
backwards
incompatible
change?
We
have
a
set
of
things
that
say
this.
This
is
I,
think
we
use
the
we
don't
use.
The
word
bug
fix.
J
We
use
something
like
a
non
feature
patch
and
it's
yeah
sure
there's
some
word
smithing
to
be
done
in
similar,
but
I
don't
understand
why
this
problem
is
apparently
so
difficult
when
I
don't
remember
it
took
us
I
think
it
took
us
a
lot,
a
bunch
of
debate,
but
not
like
not
as
many
meetings
as
you
were.
He
suggested
we
required
to
get
to
this
point.
J
A
H
A
H
So
that,
actually,
this
is
I,
think
the
second
to
last,
an
ultimate
I
wasn't
even
going
to
put
this
on
here,
because
these
didn't
change.
These
were
discussed
as
they
are
written
last
time.
However,
Andy
brought
up
recently
on
the
list.
What
do
these
requirements
mean
and
again
these
are
the
requirements
not
to
speak
of
any
particular
solution.
H
3.2
is
I
think
where
we
have
a
little
bit
more
contention.
It
says
the
solution
must
provide
a
mechanism
to
allow
servers
to
simultaneously
support
clients
using
different
versions
of
modules,
I'm
going
to
stop
there,
because,
according
to
the
rules
of
yang,
a
server
supports
one
revision
of
a
module
that
was
brought
up.
However,
today,
if
you,
if
you
take
that
and
again,
this
is
a
requirement,
so
I'm
not
going
to
necessarily
dive
into
the
solution.
H
But
if
you
take
that
today
and
say,
ok
well
today,
if
I
want
to
make
a
backward,
a
non
backwards,
compatible
change
to
a
module,
let's
say:
I
want
to
redefine
a
leaf
and
I
don't
want
to
change
the
name
of
the
leaf.
So
you
know
what
I'm
gonna
create
a
new
module
I'm
going
to
create
module
used
to
be
called
foo,
I'm
gonna
call
it
bar
now,
but
you
know
what
I
didn't
like
foo
I'm,
just
gonna,
not
include
it.
H
In
the
next
release,
I'm
just
gonna
have
bar
the
client
is
still
inconvenienced
because
the
client
says
well,
there's
no
food.
There
I,
don't
know
how
to
go
to
bar
there's
no
implicit
relationship
between
those
modules,
so
the
status
quo
kind
of
provides
a
mechanism
for
this,
because
it
doesn't,
you
could
say,
oh
I-
can
just
create
another
module.
What
we're
trying
to
do
with
3.2
is
come
up
with
a
better
way
to
link
to
tell
the
client
that
this
module
has
has
moved
ahead,
but
then
we
thought
what
about
the
old
clients?
H
H
Ok,
one
of
the
solutions
we
talked
about
just
to
give
some
an
example
context
was
that
there
would
be
a
way
of
the
client
signaling,
as
maybe
part
of
the
hello
negotiation,
that
this
is
the
module
set
or
the
module
context
or
the
set
of
modules
that
I
want
to
use,
and
there
would
be
various
versions
of
those
modules,
I
think
it
kind
of
like
what
Rob
with
a
package
of
module.
This
is
the
within
this
context.
I
want
to
use
this
and
so
that
the
old
client
can
can
kind
of
tell
the
server.
H
J
Kerrigan
actually,
I
think
there's
a
need
to
support
this
kind
of
module
filtering
anyway
right.
So,
if
you
look
at
most
servers,
the
reality
is
even
if
they
support
one
version,
if
the
module
they
support,
multiple
modules
that
export
the
same
data
right.
So
you
yes,
okay,
go
and
do
a
get
on
slash
I
get
back
in
the
entire
contents
of
your
native
modules,
as
well
as
whatever
third-party
modules
you
support.
J
J
This
kind
of
approach,
I,
don't
know
that
we
have
ever
thought
about
influencing
filtering
solely
on
the
module
rendering,
but
I
think
that
there's
a
good
reason
to
have
this
and-
and
this
I
think
it's
questionable
whether
it's
actually
reality
that
you
can
we'll
just
support
one
module
it
it's
a
kind
of
challenge.
If
you
have
linking
in
it
requires
some
coordination
at
software
upgrade
time
to
mutate,
the
stored
running
configuration
yes
and.
H
B
B
If
you
see
if
the
client,
because
the
client
knows
what
you
know,
if
I
write
some
software
and
the
client
I
know
what
modules
and
what
versions
I
wrote
them
to
it's
not
hard
for
me
to
include
that
and
then,
if
I
signal
that
to
the
server,
the
server
can
actually
deal
with
having
incompatible
changes
that
can
map
them.
For
me,
I
mean
why.
So
you
decided
against
that,
though.
No.
H
No
I'm,
you
have
just
agreed
that
this
is
a
requirement
you
in
rabaa,
both
in
fact
Rob
even
said
it's
implemented.
I'm
done!
No.
You
just
agree
that
it's
requirement
again.
This
is
the
requirements
draft
and
we
wanted
to
put
forth
that.
We
think
this
is
a
requirement
and
there
could
be
multiple
ways
of
solving
it,
as
as
you
and
Rob
pointed
out,
so
we
wanted
to
address
the
the
comments
that
were
on
list,
that.
Why
is
this
a
requirement?
H
H
Okay,
no
one
thought
it
was
possible,
but
here
we
are
so
we
think
up
until
10
minutes
ago
that
the
requirements
were
complete
with
respect
to
what
the
work
Ruben
said.
Clearly,
there
is
some
work
still
to
be
done:
the
wording
of
1.4
in
particular
and
Lou
you
brought
up.
Maybe
we
need
to
be
a
little
bit
more
specific
about
what
we've
discussed
and
agreed
to
I
think
from
a
requirements.
Standpoint
though,
the
design
team
is
on
the
same
page
solutions.
H
A
K
A
H
B
A
B
K
A
B
A
B
A
J
She
can't
I
think
we
should
remove
this
entire
requirement.
I
don't
agree
with
the
second
sentence,
either
I
think
the
the
assumption
here
is
that
your
did
this
assumption
that
everything
has
to
be
done
in
a
single
module
is,
is
sufficiently
controversial
that
you
removing
this
requirement
and
working
out
what
the
actual
requirement
is
is
probably
the
right
thing.
H
J
I
think
these
you
can
look
through
our
like
the
the
changes
in
versions
in
open,
config
or
matter
for
the
get
history
right.
So
you
can
look
at
what
the
changes
that
we've
made
across
now
a
few
years
of
developing
modules,
look
like
for
the
different
types
of
things
that
we
will
have
had
to
patch
right.
So
the
I'm
happy
to
point
that
out
and
point
out
what
what
what
we've
had,
what
changes
we've
had
to
make
and
no
thank
you
to
the
design
team.
I've
spent
many
words
in
that
mod
conversations.
H
We
so
sure
all
all
data
is
good
data.
It's
something
to
read
and
understand.
We
have.
We
have
put
forth
and
I
think
we,
the
design
team,
has
put
forth
examples
and
and
I
agree
that
maybe
we
should
quantify
bug-fix
a
little
bit,
but
for
the
examples
where
there
is
a
compelling
need
to
fix
things
without
introducing
additional
like
if
feature
or
deviations
it
it's
it.
J
Was
actually
raised,
Rob's
kyogen,
the
cost
you're
avoiding
is
a
cost
that
the--
the
operator
site
already
has
to
deal
with
right
because
any
module
that's
out
there
you've.
Given
me
a
set
of
augmentations
for
oh
I
support,
you
know
whiz-bang
knob,
a
which
isn't
in
the
module
or
a
serve
deviations
that
we
don't
support.
H
J
This
is
coming
down
back
to
the
point
I
made
earlier
about.
This
is
more
about
release
versioning
of
sets
of
modules.
Then
it
is
an
individual
module
and
those
are
separate
problems
that
we
should
address
in
in
ways
the
general
not
trying
to
shoehorn
in
the
into
the
version.
That's
in
the
module,
some
some
crazy
level
of
complexity
of
yours
release
cycle
and
because
because
it's
then
it's
negatively
impacted
everyone.
That's
dealing
with
this
version.
Cantus.
C
Chair,
so
do
you
think
we're
talking
about
solution
right
now,
going
back
to
the
I
think
Rob
said
that
he
wanted
to
strike
the
entire
requirement
and-
and
actually
he
spoke,
he
said
the
same
thing
before
when
this
slide
was
on
the
screen
and
he
actually
had
different.
He
expressed
it
some
shirts
in
the
recording
or
will
have
in
the
minutes
how
the
requirement
could
be
re-expressed
that
would
be
suitable
to
him.
So
I
think
that
was
the
point
that
he's
trying
to
make
about
striking
the
entire
requirements.
O
Michael,
a
brezza
so
Rob
just
said
what
I
was
going
up
there
to
say,
but
I
just
want
it
say
it
more
clearly.
If
there
is
a
thousand
customers
using
this
model
now
a
thousand
customers
have
to
change
stuff
in
their
NMS
with
this
incompatible
change,
so
you'd
get
less
work,
but
a
thousand
people
gets
more
work
because
they
had
to
do
stuff
in
there.
Any
messages
for
the
name
compatible
change.
That
is
the
point
you're
making
right
work,
I.
H
J
Think
it's
a
mixture
of
the
two
right
I
got.
The
point:
I
was
making
that
there's
there's
a
challenge
with
the
backwards
incompatible
like
making
any
packaging
capital
change.
Of
course,
that
means
that
you
have
to
say
there's
some
requirement
to
be
able
to
vote
for
people
to
consume
that
now
the
the
this
is
kind
of
more
an
argument
of.
J
Should
you
support
more
than
one
version,
or
do
you
have
to
spawn
more
than
one
version
of
the
same
module,
because
then,
at
that
point
you,
like
presumably
there's
one
of
your
customers
once
this
thing
and
nine
hundred
a
nine
you
don't
and
I
think
that's
a
slightly
orthogonal
point
to
the
one
I
was
making,
which
was
already
when
you
get
a
vendor
released.
They
just
then
don't
support
all
of
the
module.
So
you
have
to
support
this
combination
of
modules
working
together
and
you
have
to
support
deviating
or
augmenting
and
how
to
consume
that.
J
How
to
manage
the
fact
that
now
you
have
n
what
vendors
who
have
all
got
different
set
of
augmentations
and
deviations.
Why
I
was
saying?
Is
this
requirement
and
the
way
and
this
being
lumped
in
with
module
versioning,
ignores
the
fact
that
you've
already
had
to
deal
with
all
of
that
as
an
operator
and
and
and
the
rather
gives,
and
it
introduces
a
new
thing
in
the
version
to
be
able
to
deal
with
that
and
what
I'm
saying
is
I.
J
D
Tim
carried
no
kids,
so
somewhat
agree
with
with
Rob.
So
are
we
dealing
with
versioning
as
it
relates
to
the
module
or
the
varying
in
the
context
of
a
module
right?
Are
we
dealing
with
versioning
of
what
comprises
a
solution,
which
is
a
software
release
right,
and
so
this
has
gone
beyond
just
a
module
right
to
the
larger
system
requirement
right.
This.
H
No
but
frankly,
this
is
poorly
written
and
if,
if
I,
if
anyone
ever
invents
a
time,
machine,
I'm
gonna
go
back
and
strike
that
first
sentence.
So
it's
never
presented
the
part
of
what
we
discussed
in
the
solutions
which
you
you
may
hear.
Next
did
talk
about
that
kind
of
composite
of
multiple
modules
and
how
one
might
again
solutions
that
could
be
multifaceted.
How
one
might
address
that
composite
of
modules?
The
requirements
in
this
draft
are
specifically
around
versioning
a
module
or
how
do
we
indicate
non
backwards?
Compatible
changes
within
a
module.
D
D
J
Rubbish
yet
can
I
just
encourage.
We
have
we
published
in
October
2015,
a
catalog
and
registry
for
yang
modules,
draft
that
has
a
section
that
covers
specifically
versioning
of
things
together
and
bundling
of
separate
several
modules.
I
would
not
because
it's
a
excellent,
read
and
gonna
have
you
throw
all
you
just
for
background
of
where,
where
the
point
comes
from
and
the
wider
problem
space
we
try
to
describe
it.
There.
K
So
robots
and
Cisco
I
to
me,
this
requirement,
saying
to
the
operators,
is:
if
we've
shipped
to
release
and
it's
using
a
beautiful
module
and
you're
using
that
you
discover
a
bar,
you
find
it
can't
take
a
particular
IP
address
because
a
mistake
in
that
easier,
acceptable
for
us
to
say,
I'm.
Sorry,
we
cannot
fix
this
for
you
to
get
the
fix.
You
have
to
upgrade
to
the
latest
release
of
this
module,
which
means
you
have
to
upgrade
to
the
latest
release
of
this
software
and
by
new,
but.
J
That's
not
what
we're
saying:
Rob
Shakira
frustratedly
in
brackets,
we're
not
saying
that
this
that
there
must
be
up.
You
must
go
to
the
head,
the
tip
of
head
every
time
right
because
there
are
already
ways
to
deal
with
those
cases.
So
this
compatibility
module
already
deals
with
it.
But
that's
not
what
this
problems
saying
right.
This
is
about
module
versioning
and
it's
saying
that
it
must
the
module
versioning
should
support
something
that
is
a
cross
module
problem.
What.
G
H
B
H
A
Think
with
that
one
change,
do
your
best
update
one
for
market,
as
that
item
is
still
under
discussion
under
review
and
we'll
pull
now
with
that
change.
How
many
think
that
that
would
be
a
suitable
foundation?
That
document
be
a
suitable
foundation
for
identifying
the
requirements
of
our
solution
for
simple
or
sorry
for
versioning
at
a
twenty,
you
send
versed,
there's
a
solution
so.
J
J
A
E
E
K
The
quick
agenda-
yeah,
okay,
so
first
of
all,
I,
am
going
to
say
we're
coming
some
interesting
questions
for
students
to
consider
some
of
those
actually
have
been
quite
heavily
debated
already
then
there's
the
solutions.
Capacitor
draft
with
sittest
five
solutions,
I,
wouldn't
say
that
the
design
team
thinks
these
the
only
solutions
possible.
Now
the
ones
that
we've
discussed
in
the
deep
most
detail,
I
wouldn't
say,
there's
necessary
consensus
within
the
design
team
on
I.
Particular
one
of
these
solutions
is
the
best
way
forward.
K
Although
in
the
discussions
we've
had
this
week,
the
room
was
converging
towards
one
particular
solutions.
Their
preferred
by
at
this
time,
modified
timber
is
the
one
that
we
liked
the
moment
a
hence
I'll
cut
that
a
little
bit
more
detail
at
the
end
and
then
either
this
time
time
permitting.
There's
other
related
issues
to
versioning
that
we're
also
considering
such
as
data
node
lifecycle,
light
proposing
change
to
the
status
statement,
revision
dates
important
by
River
by
version
or
and
and
compatibility
that
will
also
discuss
at
this
time
next
slide.
K
So
this
is
one
that
Joe
already
pointed
out.
It's
the
same
thing
that,
in
terms
of
solution
space
at
one
end,
you
have
stuff
that
is
really
easy
for
clients
and
hard
for
servers
and
authors
ie.
The
ideally
is
to
produce
perfect
models
that
never
change
at
the
other
extreme.
You
have
something
that's
hard
for
clients
and
easy
first
servers
and
authors
several
implementations
where
they
can
say
we
can
do
whatever
we
like
and
clients
just
have
to
suck
it
up
and
cope
with
it.
K
B
Already,
can
you
pull
that
side
back?
So
how
what's
the
is
this
weighted?
Is
this
a
logarithmic
scale?
No,
because
I
hope
it's
logarithmic
right,
because
if
you're
looking
for
the
middle
there's,
only
a
few
vendors
right
and
there's
tons
of
users
all
right
see,
you
definitely
want
to
push
it
towards
the
tons
of
users.
You
don't
want
something
in
the
middle
there's.
K
So
in
terms
of
this,
we
had
given
again
we've
Hanson's
discussion,
there's
a
question
about
what
level
of
change
in
yang
models
should
we
accept
both
for
new
developments
and
in
this
which
level
of
changes
should
we
accept
at
the
head
of
development
as
in
where
the
tip
of
the
current
staff?
What
should
you
allow
to
allow?
No
change
at
all?
Should
your
now
backwards-compatible
changes
only
or
should
you
allow
for
NBC
changes,
and
then
you
have
that
same
question
can
be
applied
to
and
sort
of
branched
history
stuff.
K
So,
where
you
got
older
revision
of
the
software
again,
should
you
allow
no
changes
to
that,
or
should
you
be
allowing
some
changes
like
bug
fixes?
Maybe
should
you
be
allowing
non
backwards
compatible
changes
which
might
be
bug
fixes?
There
might
be
a
heart
suppose,
there's
questions
here
as
to
what
should
be
allowed
and
other
sorry
that
was
needed
on
unsane.
It's
like
the
same
questions
apply
to
bug
fixes.
So
what
effectively,
should
you
be
allowed
to
do
at
the
head
to
fix
a
bug?
K
What
should
you
been
out
to
do
in
an
older
release
on
a
branch
somewhere
again?
What
what
should
you,
which
would?
What
should
the
solution
be
allowed
to
do
and
then
there's
open
questions
of
that
like
what
is
the
definition
of
bug
fix
that
as
Joe
was
saying,
we
discussed
this
in
the
design
team
and
we
did
not
come
to
consensus
of
what
a
bug
fixes
to
give
that
in
a
bit
more
detail.
K
I
think
a
bug
fixes,
for
example,
any
broken
functionality
you're
trying
to
make
that
right
is
my
interpretation,
whereas
Juergen
had
a
different
interpretation.
That
said
along
the
lines
of
the
description
statement,
describes
the
intended
behavior
and
hence
you
could
fix
other
yang
statements
to
marry
up
to
the
description.
K
How
many
beats
in
his
fix
in
a
pattern
statement?
Do
you
label
that
errs
and
non
backwards,
compatible
update
and
similar
major
updates,
or
do
you
label
it
something
else
as
a
bug
fix,
because
somebody
could
be
broke
by
it?
Something
might
not
be
most
people
won't
be,
and
then
one
of
the
discussions
we
have
in
the
design
team
is
whether
we
should
be
even
trying
to
differentiate
between
bug
fixing
hearts.
Bizarre
toys.
K
Is
that
a
fool's
errand
to
actually
try
and
differentiate
these
two
cases
and
maybe
in
terms
of
a
scheme,
you
don't
need
to
do
that.
You
just
have
a
way
of
labeling
these
releases
and
you
have
a
way
of
describing
documentation
what
the
best
practices
are
without
trying
to
pin
these
things
down.
That
could
be
hard
to
define.
K
So
and
then
the
last
one
that
we're
considering
is
in
terms
of
how
much
branching
do
you
want
to
allow
how
much
brighter
should
we
allow
and
the
left-hand
side
this
side,
then
we
have
sort
of
strictly
linear
history
and
that's
what
our
c7
950
rules
are
today.
That's
what
my
interpretation
of
those
rules
are
yogin
pointed
out
that
well
you
can
create
new
modules
and
some
senses.
You
can
create
branches
with
that
I
don't
know,
maybe
that's
possible.
So
even
there's
questions
with
that.
K
So
if
the
five
solutions
that
we've
looked
at
and
we've
discussed
a
few
more
and
dismiss
some
more
some
of
these,
but
the
ones
that
effectively
had
most
discussion
on
is
is
standard
December
and
this
is
defined
per
symbol.
The
org
and
I
think
I
don't
know
vo
can
config
definition
is
exactly
the
same
symbol
that
all
Gore
is
refining
that
maybe
Rob
can
clarify.
J
K
Thank
you
now
in
repose,
a
modified
version
of
that
we
call
modify
December.
We
had
a
her
release,
semver
that
we
discussed
I'll
present
that
and
then
there's
a
sort
of
scheme
of
comparison
saw.
This
is
quite
different
way
of
solving
the
problem
and
and
looks
quite
different,
so
discussed,
and
then
finally,
we've
left
in
the
existing
do
no
changes
will
keep
the
RFC
791
up
their
rules
and
what
that
looks
like
so
question.
A
K
This
is
just
covering
our
subset
of
requirements.
Okay,
so
there
are
some
requirements
that
are
covering
those
other
slides
at
the
end
that
some
that
we
haven't
even
got
to
yet
okay.
This
is
this
is
essentially
what
we
felt
like
was
tacking.
The
biggest
problem,
maybe
not
everyone
will
agree,
is
the
biggest
problem.
That's
what
we
feel
a
design
team
is
they're
the
number
one
thing
to
try
and
get
pinned
down
first
and
then
try
and
settle
everything
else
around
that,
but.
K
Yes,
quite
possibly
that's
true,
we
may
look
at
or
may
request
staging
the
solution
so
that
we
have
solution
to
some
of
the
requirements.
And
then
you
have
separate
draft
solving
other
bits.
Okay,
because
some
of
may
require
language
changes
and
there's
a
question
of.
Do
we
wait
for
Yaga
to
die,
which
I'm
mocking.
K
Symphysis
clarify
what
the
C's
of
anyone
doesn't
know.
Simba
has
a
version
number
which
is
major/minor
Dogpatch
specification
assembler
that
organic
specification
is
actually
quite
as
tight
as
it
should
be.
There's
some
ambiguity
into
what's
allowed
and
as
far
as
I
think
my
interpretation
of
Simba
is
is
really
talking
about.
The
head
of
the
development
or
II
is
saying
that
when
you're
changing
at
the
head,
you
update
the
Simba
different
ways
to
integral
sort
of
change
you've
made.
K
If
you
make
a
non
backwards,
compatible
change
of
a
head,
you
increment
the
major
version
number
and
you
reset
minor
and
patch
back
to
zero.
If
you
make
a
backwards
compatible
change,
you
increment,
the
minor
you
leave
major
is
the
same.
The
increment
minor
and
you
reset
patch
back
to
zero,
and
if
you
make
a
into
the
symbol,
is
defined
as
it
really
is
an
implementation
change
in
terms
of
a
yang
model
which
I
think
really
defines
an
API.
It's
an
editorial
change,
then
increment
patch.
K
K
Oh,
you
can
create
1.0
at
one
and
one
that
zero.
So
you
can
create
patch
changes,
because
you
don't
conflict
with
anything,
but
you
couldn't
you
had
one
zero
to
zero
and
one,
but
one
that
I
already
defined
you
couldn't
do
either
a
major
or
minor
change
to
one
that
zero
zero
couldn't
put
a
bug
fix
in
that
actually
has
any
change
in
behavior,
because
you
can't
give
a
useful
number.
B
K
K
You,
wouldn't
you
would
put
it
on
both
of
them,
so
it's
quite
plausible.
So
if
you
have
this
is
the
tree
of
schemas
you're.
Managing
these
entirely
separately,
like
open,
config,
maybe
and
then
you've
got
various
releases
they're
shipping.
This
some
of
these
modules,
unreleased
X,
is
shipping
with
module,
1,
0,
0
and,
and
you
come
up
to
me
and
say,
you've
got
a
bug
in
this
I
need
you
to
fix
it
all.
I.
K
Q
K
K
J
I
think
this
diagram
is
a
little
bit
mystery,
misleading
right
because,
but
essentially
I
don't
think
that
there's
this
cases
in
which
you're
really
going
to
go
back
and
produce
1
0
1
on
1,
0
2.
It's
really
it's
it's
incrementing
in
time
and
it's
like.
Oh,
we
published
1
0
0
and
we
like
screw
it
up
and
then
run
the
spell
check
against
it.
So
we
fix
it
and
then
it's
just
what
is
head
called
at
this
point
in
time
and
then
at
some
point
it
becomes.
J
K
J
Is
possible
yet
I'm,
not
I,
think
I
think
that
that
yeah
there's
this
kind
of
a
question
here
about
software
development
practice
that
you
want
to
follow
versus
software
development
practice
that
an
arbitrary
versioning
scheme
can
be
because
otherwise
we
could
just
version
based
on
the
shower
and
get
and
we're
gonna
be
super
happy.
Okay,.
K
K
Zero
will
only
do
it
on
well,
one
one
to
zero,
for
example,
but
that's
where
you
could
put
it
in
here
and
then
you
say:
okay,
but
I
want
to
have
that
fix
in
the
software
you
ship
to
me
and
it's
like
well,
we
can't
give
that
to
you
because
it
means
we
need
a
back
port,
the
feature
that
is
in
1
1
0,
so
that
relates,
we
won't
do
I.
Do
that's
too
expensive
in.
B
Is
that
I
mean
this
is
a
valid
question?
I
think,
is
that
something
we
want
to
solid
ITF,
how
you
ship
software
to
your
customers,
I
mean
I,
understand
that
you
it
makes
it
may
be
a
little
easier,
but
it
just
it
seems
like
it's
outside
the
scope.
It's
like.
We
have
this
low-hanging
fruit.
Why
aren't
we
solving
that?
Let's
version
the
requirements
and
put
the
low-hanging
fruit
and
version
one
of
the
requirements,
and
then
you
can
put
all
this
crazy
stuff
in
version
two.
So.
J
So
Rob
and
I
think
what
you
just
said
is
not
true
right
so
in
in
one
let's
say:
there's
this
bug
in
1
0
1,
here
1
0
2.
There
is
no
requirement
for
you
to
go
and
implement
everything.
That's
in
1,
1
0
there
right.
So
you
don't
have
to
say
oh
I'm,
getting
like
there
was
this
new
feature
in
1
1
0
and
it
was
I.
Just
ton
introduced
it.
J
The
hardware
is
not
there
or
whatever,
because
you
can
still
DV
deviate
in
everything
and
say:
I,
don't
support
this
feature
and
I,
don't
think,
there's
any
schemer
in
which
other
than
your
native
schema,
where
you're
going
to
support
all
of
it.
So
you
already
have
to
deal
with
this
idea
that
there's
parts
of
the
model
that
aren't
supported
so
it
then
just
becomes
for
this
platform
for
this
software
release.
This
supports
one
one
zero,
but
it
doesn't
support
one
one.
K
J
I
think
you
have
to
so
so
there's
there
is
no
vendor
today,
that
is
shipping,
a
non-standard
schema
that
doesn't
have
also
shipped
deviations
with
them.
So
so
I
think
that
you're
like
we
can
create
these
kind
of.
Oh
I,
really
want
to
do
this
thing
in
isolation
if
we
want
to
but
I
think
if
it.
If
we
write
off
of
something
that
we
write
off
a
solution
based
on
that,
there's
really
a
mistake,
because
we
have
we
have
to
look
at
this
wider
versioning
problem,
but.
K
I
think
that,
effectively
through
using
deviations
today,
they
defined
as
deviations
to
the
API
specification.
That's
what
I
said
deviation
is
the
implementation
does
not
meet
the
API,
whereas
here
it's
you're,
saying
I
want
to
now
use
deviations
to
make
changes
to
the
API
book
fixes
to
the
API,
not
the
implementation,
no.
J
To
different
to
different
potential
solutions
right,
my
point
was
specifically
to
this
case.
If
you
wanted
to
make
you
wanted
to
introduce
a120,
essentially
here
the
annuus
that
you'd
made
the
assertion
that
to
introduce
a
1
to
0,
you
had
to
up
graph
everything
you
have
to
support
everything
that
was
in
one
one,
but
you
don't
have
to
supply
everything
that
was
in
one
one
right.
You
only
have
to
the
the
minimum
work
you
need
to
do
is
to
support
anything
that
was
in
capacity.
J
That
was
a
incompatible
change,
but
between
these
two
versions
there
were
no
incompatible
changes
right
because
they're
one
one
versus
one,
two,
so
like
I,
guess
I'm
just
saying
it
isn't
the
case
that
you
are
doing
anything
different
with
deviations
than
you
were
doing
before,
which
is
I.
Just
don't
support
out
this
API.
K
You're
using
the
deviations
you
knew
the
deviations
to
effectively
control
the
version
of
the
system,
though
so,
when
some
is
looking
at
that
and
saying
I
want
to
go.
You
you're,
saying
you
only
advertise
your
module,
you
say
I
support
one:
two,
oh
you're,
not
really
supposed
to
want
to
row
you're,
supposing
one
two
row
modulo
is
set
of
deviations
actually
take
it
back
to
some
two
different
version,
but
that
was
my.
J
Point
right:
actually,
the
only
way
you
can
work
with
a
young
schemer
and
a
device
today
is
to
consider
those
modulo,
because
there
is
no
implementation
that
supports
all
leaves
in
another
another
module.
So
this
is
the
point
about.
Is
it
a
bundle
of
modules
that
you
want
to
version
versus
the
individual
module?
Like
already?
We
have
to
deal
with
that
so
for
these
scenarios,
we're
sure
that,
like
it's,
it's
the
union
of
them
becomes
the
version
for
what
supported
look.
K
J
Say
that
the
complexity
of
dealing
with,
what's
supported
in
a
yang
module
today
is
pretty
high
right.
You
have,
if
feature
you
have
deviations,
you
have
augmentations
so
already,
we've
got
a
number
of
ways
to
be
able
to
wrangle
with
what
supported
an
open
config.
We
said
we
don't
do
a
feature
right.
We
will
specifically
use
separate
modules
to
add
new
sets
of
functionality,
so
we'll
extend
based
modules
then,
and
then
we
oh,
but
we
already
have,
we
have
to
deal
with
augmented
and
deviation
just
because
that's
the
reality
of
any
implementation,
I
guess
I.
J
What
I'm
encouraging
us
to
think
about
is
to
think
about
the
complexity
that
the
the
client
has
already
had
to
deal
with,
because
they
have
that
scenario
and
more
rather
than
saying
oh
look
here
is
this:
is
this
this
progression
that
we
can't
support
with
say?
Well,
okay,
if
we
have
this
scenario
that
we've
got
this
this
fix,
we
need
to
make.
How
can
we
do
that
with
the
tooling
that
we
already
have?
Okay.
K
J
K
D
Tim,
karaoke
and
I
I
kind
of
agree
with
Rob
on
this
one
is
that
you
know
with
Rob
yeah
the
Rob,
that's
speaking
well,
so
so
the
yeah
either
way
right.
So
so
the
because
the
idea
is
that
you're,
starting
at
a
base
a
base
in
time
and
see
they're
gonna
be
one.
Oh
one,
one,
and
it's
a
lot
easier.
You
know
if
you're
trying
to
sit
back
and
saying
I'm
gonna
take
one.
Oh
one
one
and
deviate
the
heck
out
of
it
right
for
a
fix,
that's
in
1
0-0.
D
That
just
seems
to
me
to
be
something
that
you
don't
want
to
do
it's
just
not
because
you're
advertising,
as
you
noted,
and
what
what
got
that
was
that
you
said
you're
advertising
one
one
like
with
with
this
amount
of
deviations
right
versus
this
change,
that
you're
trying
to
fix
and
so
I
I
think
you
I,
think
Rob's.
Probably
Rob
Wilton
has
probably
got
a
better.
A
A
K
K
Think
that
is
the
point
that
you
have
a
virgin
laugh
level.
Then
you
to
remove
deviations
and
things
then
you'd
start
to
say
well
that
if
you
change
about
package
level,
I,
don't
think
an
image
of
module.
You
can
do
that
because
you
don't
have
the
binding
at
different
modules.
It's
just
a
module
full
of
deviations.
J
So
Rob
here
just
to
respond
to
the
other.
There
kind
of
many
negatives
thing
you,
so
you
can
always
publish
a
module
that
only
augments
the
other
version
right.
So
so
you
can
say:
okay,
there's
this
and
I'm
going
to
deviate
out,
and
then
you
can
have
a
okay,
here's
that
version
plus
this
augmentation
to
fix
it.
J
So
there's
a
few
different
solutions
around
this
and
actually
I
think
it
comes
down
to
looking
at
what
you
actually
see
in
your
code
and
how
you
choose
to
fix
the
bug,
because
sometimes
you
might
fix
the
bug
in
a
way.
That's
yes,
less
neat
than
you
would
have
liked,
because
you
have
the
perfect
leaf
name
and
now
you
don't
want
you,
you
can't
use
it
anymore,
but
just
to
keep
the
aversion
in
more
consistent.
F
But
that
seems
I
mean
that
seems
to
me
to
be
a
decision
about
how
you
write
the
young
modulus,
and
the
decision
seems
to
be
made
that
the
right,
the
way
that
a
young
module
will
be
updated,
is
to
have
a
complete
replacement,
that
that
has
the
changes
and
then
indeed
rely
on
tooling,
for
example,
there's
a
P
Young
output
option.
You
know
the
checkout
date
from
and
I
mean
40
or
69.
We
actually
used
to
use
a
different
approach.
F
We
used
it
because
we
never
wanted
to
change
a
publish
file
and
we
wants
to
do
new
versions.
We
always
used
to
do
essentially
augmentation
to
the
data
models,
but
it's
more
complicated.
It
complicates
the
tooling
in
many
ways
I
think,
and
it
means
that,
in
order
to
see
what
what
you've
actually
got,
you
have
to
look
at
the
output
from
the
tool,
whereas,
if
you're
just
going
to
update
the
module,
you
can
always
see
what
you've
got
and
so
I
think
I
mean.
Okay.
K
Before
us
so
pros
and
cons
of
this,
my
perception,
so
the
benefits
of
similar
is
quite
clear
that
you
compare
two
versions
of
a
module.
You
can
determine
whether
it's
backwards
compatible
and
non
bucks
compatible
on
editorial
change.
So
that's
that's
the
problem
of
somewhere
somewhere.
It's
widely
used
now
it's
used
by
a
config,
which
is
also
benefit
into
the
system
and
there's
disadvantages
here
in
terms
of
the
bug
fixing
effect.
K
What
we've
been
discussing,
what
it
allows
and
doesn't
allow
and,
as
as
Rob
said,
there's
different
solutions
you
can
use
to
solve
to
mitigate
that,
but
in
terms
of
what
strict
Sendler
allows
it
has
that
issue
and
I.
Don't
think
that
issue
to
just
send
those
on
it's
only
specific
to
yang's
usage
of
it.
You
look
at
the
wide
documentation
on
December
I.
Think
there's
lot
to
other
people
pointing
out
this
sort
of
problem,
but
it's
the
it
works.
K
Well,
when
you
can
force
people
to
move
to
the
latest
release,
you
say
I'm
not
going
to
support
you
in
older
release.
You
need
to
move
the
latest
next
slide
quickly
for
asking
the
questions
so
modify
December.
So
what
we
been
suggesting
or
trying
to
change
this
or
in
Harts
ember,
is
effectively
to
mitigate
this
issue.
That's
what
the
aim
is
here.
So
if
you
look
at
the
head
of
the
development
branch,
you
you
Simba
exactly
as
before.
K
There's
no
changes
there
you'd
use
major
minor
patch
exactly
as
before,
but
what
we're
allowing
is
to
say
that,
rather
than
the
patch
number
being
restricted
to
only
up
for
only
editorial
changes,
we
also
allow
the
patch
number
to
represent
major
and
minor
changes
as
well.
But
if
you
do
that,
you
append
either
a
little
m
for
a
minor
change
or
big
M
for
a
major
change
to
that
patch
number,
that
straight
and
effectively.
J
K
J
K
So,
in
terms
of
the
scheme,
the
the
idea
here
is
not
to
encourage
the
use
of
these
extra
letters.
It's
not
that
we're
saying
that
this
is
great
Eggar
shadowing
uses
everywhere
we're
trying
to
say
this
is
a
way
of
documenting
you've
done
this.
So
it's
better
to
actually
what
we're
saying
to
the
skin.
H
Under
cleric,
we
talked
about
an
alternative
to
this.
That
would
add
a
lot
more
complexity,
but
for
the
arguments
that
Rob
just
said,
we
said
this
is
something
that
we
don't
want
to
have
happen
often,
and
we
wanted
it
as
kind
of
a
get-out-of-jail,
a
an
emergency
like
you
said,
and
we
didn't
want
to
layer
on
additional
complexity,
to
try
to
address
what
you
just
said
like.
How
would
you
know
what
the
compatibility
is
between
1
1,
2
and
1,
more
1
1
1
2?
K
But
one
thing
actually
I
cannot
do
it.
The
next
sort,
the
same
diagram,
so
the
the
pros
that
benefit
to
the
scheme.
We
think
he's
that
it's
like
Cimber
so
has
the
cember
stuff
at
the
head
of
the
head
of
dirt.
On
that
train,
see
how
that's
great
that
stuff
works
as
before
it
allows
those
fixes
and
actually
the
scheme
allows
any
arbitrary
change
in
any
revision
effectively.
You
can
do
what
you
like.
K
We
won't
recommend
that
we
wouldn't
advise
you
doing
that,
but
it's
possible.
The
numbering
scheme
has
a
way
of
representing
that
and
so
to
support
it,
but
not
necessarily
not
necessarily
recommended
the
key
downsides
to
it
is
that
it
differs
from
semver
so
that
higher
complexity,
I,
don't
know
this
scheme
exists
or,
if
you
like,
the
scheme
as
those
different
version
schemes
out
there,
but
this
isn't
the
classical
similar
to
being
used
and
from
a
technical
point
of
view.
K
As
soon
as
you
start
using
those
little
ends
of
begins,
you
lose
the
compatibility
story,
so
you
can't
go
from
two
zero
one
little
m2,
two
one
zero.
That
may
be
an
on
back.
That
will
change
because
once
you've
put
those
little
letters
at
the
end,
you're
sort
of
throwing
out
you're
in
no
man's
land,
but
still
we
can
see
that
it's
better
to
go
to
label
those
changes
than
either
not
to
be
able
to
make
them
or
how
to
make
them
different
way.
Rob,
hey.
J
Rob
kit,
so
what's
the
guarantees
that
are
made
about
two
to
zero
in
this
case
right,
so
you
make
one
more
modern
begin.
Like
is
two
to
zero
mandated
to
include
the
change
of
one
one
one
or
like,
because
this
is
there's
no
consistency
in
the
version.
Assembler
has
that
case
that
I
know
that
2:01
was
subsumed
by
3,
0,
1
and
4
0
would
definitely
substitute
3,
but
there's
no.
You
know
you
always
know
that
if
I
take
tip
of
head,
it's
got
this
at
the
latest.
It's.
K
J
K
Not
made
to
be
game
here,
the
aim
is
to
have
that
one
train
of
progress
with
side,
shoots
that
have
fixes
to
them
and
in
terms
you
saying,
is
the
fixing
one
ones
one
one
one
in
definitely
in
two,
two
zero.
You
have
no
idea.
It's
depends
temporarily
when
that
happened.
If
you
say,
if
you're
putting
fixes
in
all
the
branches,
yes,
you
should
put
them
all
the
way
down
the
tree,
because
that
make
sense.
Okay,.
J
K
J
I
guess
why
I'm
saying
that,
in
that
case,
I
would
expect,
let's
say,
there's
a
bug
and
it's
all
through
through
all
of
them.
The
the
thing
we
should
encourage
is
making
the
change
at
tip
of
head
yeah
and
back,
and
then
cherry-picking
right.
If
this
is
something
that
we're
going
to
do
so
is
like
your
M
is
you've
lost
a
bunch
of
information
because
you've
got
a
single
character
now,
but
you
could
use
some
something
that
saves
this
chirping
I.
Don't
think
this
is
the
right
thing
to
do.
I
think
it's
going.
J
This
is
where
it's
gonna
get
particularly
complex.
If
you
end
up
with
that,
but
I
would,
if
this
is
something
that
that
is
progressed.
I
think
there
needs
to
be
a
bunch
of
guidance
about
how
to
make
changes
such
that
you
there's
not
end,
come
in
compatible
versions
with
no
information
as
to
why
they're
incompatible.
K
K
But
we
still
think
that
this
scheme
is
better
to
be
able
to
tell
the
operators
the
clients
of
what
has
changed
than
to
pretend
they're
not
happening
than
to
lie
and
cheat
which
is
sort
of
what
happens
today
or
or
use,
do
different
approach
all
right
next
one.
So
the
the
recent
are
not
I.
Don't
talk
like
I.
Don't
talk
about
this
one
for
very
long.
This
is
effectively
approach.
I
think
that
we've
dismissed
this
anyway.
K
So
the
idea
here
is
that
you
do
send
person
Cimber
per
release
to
have
a
release
number
at
the
top,
and
then
you
have
the
major
minor,
Patras
ember
and
each
time
you
have
a
release
in
sorry,
Chris,
don't
wanna
die
each
time.
You
have
a
release,
you
increase
the
release,
number
fine,
great
and
within
early
systems
and
rules
of
is.
E
K
So
the
benefits
of
this,
the
ROI
of
blackwell,
so
the
benefits
of
that
effectively
is
you-
can
do
a
2
December
per
branches
but
the
obviously
the
major
downside
this
which
almost
person
ruins
this
is
that
you
lose
the
Cimber
between
releases.
Any
two
releases.
You
have
no
idea,
what's
changed
so
so
I.
Don't
think
this
really
has
any
legs.
K
Schema
comparison
tool,
so
this
is
the
other
thing
I
actually
like
so
I'd
be
interested
in
feedback
on
this.
The
idea
here
is
sort
of
similar
to
what
Rob
was
getting
at
in
the
way
that,
but
that
the
version
number
is
a
humanly
identified
to
help
guide
you
to
what
might
have
changed.
I
totally
can
use
that
depending
on
the
rules.
But
then
you
have
a
question
about
bug:
fixes
B,
NBC
and
not
and
things
that
means
that
the
automated
process
may
break
with
that.
So
I
know
ask
in
the
comparison
tool.
K
Is
you
have
different
way
of
doing
this,
and
that
is
that
you
effectively
construct
your
entire
schema,
the
entire
set
of
modules
from
release
a
and
you
have
another
software
release,
release
B,
and
you
constrict
and
construct
the
entire
system
modules
for
each
B.
You
apply,
you
want
to
your
deviations
to
those
you
apply.
K
If
you
want
to
the
features
that
being
used
between
those
two
things
and
then
in
and
then
third,
you
could
even
want
to
subset
those
down
to
the
subset
of
the
actual
modules
that
you
use
as
and
operate,
and
you
say
actually
don't
use
these
features.
I,
don't
use
I,
don't
use
this
subset
of
the
modules
I.
Don't
I'm,
not
interested
in
these.
K
Do
you
substitute
it
down
to
those
two
trees
that
the
stuff
that
you
actually
use
in
both
cases
we're
looking
applied
and
then
use
automated
tooling,
like
PI
yang,
to
then
say:
okay,
what's
the
compatibility
on
a
node
by
node
basis
of
these
two
trees?
And
then
you
can
give
a
summary,
a
top-level
figure
that
says
all
the
changes
in
here
are
bucks,
combative
law,
the
some
non
bucks
collateral
changes
or
whatever,
so
you
effectively
prepare
them
side
by
side
using
tooling.
Now
the
is
this.
This
is
schema
diff.
That,
yes,
is.
G
K
A
schema
diff
tool,
no
yet
yeah,
but
it,
but
it
is
schema,
define
pi
yang,
provides,
provides
that
does
this.
There
are
limitations
so
Eve
for
the
majority
of
changes
you
can
determine
from
the
tooling
as
to
what's
changed
or
not.
You
can
determine
programmatically
saying
this.
Is
that
was
collateral
change?
This
is
not
about
collateral
change.
There
are
some
cases
like
you
change
your
description.
You
can
change
a
pattern
statement.
K
You
change
an
XPath
where
either
the
tooling
simply
cannot
determine
that
until
to
Rob's
companies
produce
strong
AI
or
you
get
the
case
where
it's
very
hard
to
figure
it
out.
It's
like
you,
you
probably
could
do
it,
but
it's
too
difficult
and
in
those
cases
that
would
probably
need
to
be
some
sort
of
annotation
added
into
those
nodes.
In
the
schema
to
say
either
I've
made
a
non
backwards,
compatible
update
at
this
stage
or
I've
made
a
backwards
compatible
stage.
Update
I,
don't
know
which
way
round
is
better.
K
J
J
K
Yes,
it
could
be
it's
more
I'm
thinking
that
if
you're
running
some
vendor
software
release
X
and
you
want
to
move
to
release
Y,
then
those
vendors
would
produce
instance,
data
Lang
instance
documents
with
the
version
of
the
yang
library
information
of
what's
on
those
devices
and
also
what
features
are
supported
and
give
that
to
you
and
say
look
this
is
what
you
and
then
you
look
and
say
well,
I'm,
using
this
of
release.
X
I
want
to
remove
thérèse.
Why?
What's
the
impact
going
to
be?
J
So
here's
the
the
more
shooting
part
we
tried
to
do
something
like
this
and
say:
oh,
we
can
always
just
use
schema
for
or
compare
it,
comparing
whether
some
to
releases
they're
going
to
be
compatible
with
each
other,
mainly
on
the
telemetry
side,
and
it
did
sure
it's
an
indicator
as
to
how
much
work
you've
got
to
do.
But
it's
not
sufficient
because
the
like
you
can't
know
how
what
happened
in
the
description
statement.
So
so
you.
J
J
P
Hi
Elliot
here
I
was
listening.
I
was
with
you
there
Rob
right
up
until
you,
you
picked.
The
description
example
there's
a
point
at
which
in
this
process,
perhaps
you
have
to
allow
for
the
fact
that
the
people
are
coding.
These
things
up
are
actually
not
stupid.
Right
in
that
you
know,
if
you're
going
to
change
the
epoch
right
as
an
example,
that's
a
good
case
where
you're
probably
going
to
use
you
know,
you're
doing
damage
right.
You
know,
you're
gonna
have
to
either
use
a
new
note
or
something
like
that.
J
Rubbish
get
to
respond,
I
guess
I'm
stupid,
because
I
think
this
is
actually
something
that
we
had
a
problem
with.
Basically
I
had
a
type
def
that
described
at
epoch
somewhere
and
then
we
didn't
redefine,
or
we
assumed
a
different
one
somewhere
later
so
I
think
the
the
point
I
guess
I'm
trying
to
make
is
it's
it's
very
difficult
to
be
able
to
rely
on
this
as
a
way
to
know
whether
things
are
compatible,
because
as
soon
as
it
say
so,
like
this
shouldn't
happen
it
doesn't.
K
K
So
the
key
one,
the
pros
and
cons
the
key
well
I
think
actually
is
at
the
bottom.
That
was
with
me
out
is
that
we
don't
think
this
is
a
solution
on
its
own.
So
I
think
this
is
something
that
would
be
used
above
and
beyond
a
module
level
version.
But
that's
that's
our
impression
that
this
gives
you
extra
information.
It
doesn't
replace
that
need
for
a
module
level
version
number
and
in
fact
the
labeling
of
on
particular
nodes
of
it
be
an
MVC
change
or
a
BC
change
probably
requires
a
module
level.
K
Yes,
option
5
is
effectively
is
to
be
do
nothing
we
whatever
we
got
done.
Today's
is
perfect
at
something.
This
is
the
right
option
and
that
effectively
says
that
all
changes
back
is
compatible.
We
either
introduced
new
nodes
or
new
loads
of
new
modules
for
any
NBC
changes,
deprecated
and
then
obsolete
old
nodes
and
effectively
I
would
argue
that
the
history
strictly
menu,
in
this
case,
all
updates
of
the
latest
revision.
You
may
say
introducing
new
modules
as
some
sort
of
branch
analyst
as
well.
K
K
J
J
K
And
then
the
other
implicit
assumption
here
in
terms
of
box
compatibility
is
that
if
you
introduce
a
new
module,
then
the
old
modules
going
to
stick
around
that
it's
not
acceptable.
Just
to
say,
I've
created
this
new
module.
We
don't
support
your
one
and
it's
fine
are
still
gonna
breaking
system.
Clients
next
slide,
please
so
pros
and
cons.
Obviously,
this
is
already
defined.
That's
good!
This
gives
this
full
backwards
compatibility
for
clients,
so
this
is
right,
I
think
right
up
the
clients.
End
of
this
is
great
because
it
makes
life
easier
for
them.
K
Disadvantages
is
I,
don't
think
this
is
sufficient
and
the
design
team
I
think
broadly
doesn't
think
this
is
sufficient,
because
I
think
it
would
be
here
if
it
was
this,
doesn't
my
a
bug
fixes
to
order
releases?
Yes,
you
could
use
deviations
to
achieve
that.
Questions
must
whether
that's
a
good
thing
to
do,
and
our
perception
is-
and
this
is
so
ambiguous
if
you
think
that
using
new
modules
breaks
all
existing
parts
as
a
question
mark
as
to
what
the
definition
of
our
path
is
were,
that
includes
the
module
namespace
or
not
but
effectively,
I.
K
Think
with
this
solution
that
when
you,
when
you're
choosing
new
module,
you're,
probably
going
to
impact
the
clients,
but
that's
how
our
thinking
on
this
as
to
why
we
that
this
is
a
great
choice
and
their
last
one
I
think
that
for
me,
the
thing
that
we
can't
rationalize
in
terms
of
the
solution
is
that
we
think
the
case
on
the
conflict
path
where
you
have
two
separate
leaves
write
it
in
different
versions:
writing
to
the
same
underlying
system
property.
We
think
that
has
lots
of
problems.
K
N
G
K
A
J
So
Rob
Kerrigan
it
isn't
it's
probably
the
last
part.
The
problem
you
described
is
unavoidable
right
because
we
have
no
system
that
solely
has
yang
is
the
way
to
interact
with
it.
I
mean
now.
No
existence
is
so
by
default.
We
have,
unless
you
are
using
a
model
that
exactly
one
to
one
corresponds
to
your
CLI
or
existing
configuration.
You
already
have
to
deal
with
this
idea
that
there's
two
input
views
to
one
lying
data
source
so.
K
J
Saying
that
actually
native
doesn't
actually
match
CLI
right,
so
so
it's
not
like.
So
if
I
can
go
prods,
it's
just
sisty
B,
let's
assume,
there's
something
called
that
and
and
I
can
then
type
something
into
the
CLI
and
those
two
things
are
writing
to
the
same
underlying
thing,
but
with
different
schema
representations
right.
Q
K
Right,
we'll
move
on
to
the
next
side:
Baker's,
hello,
I'm
wrong,
so
I
a
solution,
comparison
table
anomaly,
Beauty
context,
but
this
is
this
is
one
we
threw
together
effectively.
So
this
is
just
something:
that's
summarizing
the
same
things
we
had
before
and
I.
Don't
know.
If
you
want
to
look
at
this
in
more
detail
here
now
or
you
want
to
cover
the
extra
stuff,
I
don't
think,
do.
E
K
H
Joe
Clark,
hey-
that
was
one
of
the
things
we
discussed
if
I
create
a
module
bar
based
on
foo,
because
I
can't
make
backwards,
incompatible,
changes
to
foo
and
then
I
just
say:
you
know
what
the
heck
with
foo
I'm,
not
supporting
it
anymore,
haven't
I
essentially
done
the
same
thing.
I've
put
the
onus
on.
A
A
K
So
currently,
our
the
design
team-
and
it's
not
everyone's
view-
is
modified.
Assembler
is
where
is
the
sort
of
current
front
runner
and
it's
not
a
perfect
technical
solution?
We
understand
that
we
don't
think
there
is
a
perfect
technical
solution
here.
I
think
it's.
We
think
it's
compromises
between
different
choices.
We
think
it
strikes
pragmatic
balance
to
the
two.
We
still
think
that
vendors
should
decoupled
version
of
modules,
the
API
from
the
software
version
artifact,
so
they
bromination
certain
so
going
back
to
Chris's
point
very
early
on
into
the
quants.
K
K
The
scheme
does
allow
some
things
that
are
desirable,
so
it
gives
you
too
much
freedom
potentially,
but
we
still
think.
We
therefore
need
to
provide
sensible
usage
guidelines
and
constraints.
How
you
should
use
this
when
you
should
use
the
extra
letter
at
the
end,
try
and
minimize
its
usage?
K
It's
there
as
a
last
resort,
rather
than
other
than
the
first
choice,
and
then
there's
still
an
open
issue
in
terms
of
this
approach
is
that
whether
updating
the
major
minor
version
number
is
strict,
so
summer
discussion
has
been
about
whether
you're
only
allowed
to
upgrade
the
major
major
version
number.
If
you
made
a
number
possible
change,
or
some
people
would
like
to
potentially
go
to
update
that
per
release
anyway.
So
there's
a
question
as
to
whether
that's
a
good
choice
or
not
and
the
solution
there
maybe
be
somewhat
ambiguous
on
that
slide.
K
So
some
example
guidelines.
These
were
not
top
of
rallies
and
relatively
quickly,
so
they're
not
complete
they.
They
may
not
correct
some
things,
so
the
guidelines
might
look
for
things
like
churns
paper
for
clients.
Try
to
ship
high-quality
modules,
keep
them
stable,
so
it's
all
common
sense,
stuff
minimized
on
back
special
updates
particular
release
code.
So
this
is
same
using
the
air
in
the
air
Liz
Lemon
again,
there's
a
tour
of
last
resort
use
normal
sender
where
you
can,
because
that's
easier,
and
it
maintains
this
history
between
the
versions.
K
You
should
version
modules
independently
for
releases
have
said.
If
a
fix
is
made
under
older
branch,
then
port
it
to
all
new
branches
at
the
same
time.
So
that's
the
same
thing
about
you
know:
let's
cherry-pick
these
fixes
and
make
sure
they
go
everywhere
and
also
the
deprecating
nodes
is
an.
It
is
a
backward,
compatible,
change,
obsoleting
and
notice
the
numbers
collateral
change.
I
think
we're
changes
in
definition.
So
this
is
the
example
of
the
stuff
that
we
would
also
document.
K
K
We're
proposing
changing
status
at
the
moment
currently
and
status
is
defined
to
be
that
seven
allowed
to
implement
it
or
not.
We
ought
to
change
deprecated
to
mean
that
the
server
must
implement
it.
We
were
to
change
obsolete,
to
mean
the
server
must
not
implement
it,
and
we
want
to
allow
a
description
statement
under
status
to
give
more
and
more
information
to
the
clients
of
those
modules.
K
To
tell
you
why
it's
been
deprecated
obsolete
it,
to
give
you
guidance
I
made
me,
give
a
guidance
as
to
what
the
replacement
some
alternative
is,
and
do
this
this
in
a
backward
compatible
way.
The
the
intention
is
to
make
this
requirement
review
its
versioning
and
to
have
two
leaves
Global
leaves
and
yang
lightly.
That
says
effectively
the
sneak
is
specified.
This
says
the
server's
going
to
have
these
behaviors
or
these
two
different
two
different
behaviours.
Next
slide.
K
Revision
dates
is
a
good
in
a
good,
open
question
here
when
you
come
to
the
news
versioning
effectively,
revision
dates
become
less
useful.
If
your
history
isn't
strictly
chronological
than
revision
dates
are
less
useful.
The
question
is:
do
you
remove
them
all
together
or
do
you
keep
them
but
make
them
less
strict?
So
currently,
the
proposal
is
that
we
retain
revision
dates
without
break
anything,
but
we
don't
require
through
chronological
anymore,
so
you
put
a
fix
in
an
older
module.
Then
you
can
choose
a
revision
date.
That's
just
either
that
doesn't
match.
K
We
are
suggesting
that
we
keep
uniqueness
requirements,
so
you
cannot
have
two
different
modules
with
the
same
revision
date.
Let's
try
that
and
two
different
modules,
same
name
with
different
with
the
same
revision,
but
but
effectively
that
the
module
name,
revision
date,
pairing
and
uniquely
identify
as
a
module
and
the
design
team
is
currently
meeting
towards
two.
So
retain
it,
but
change
the
world
slowly.
K
Import
by
version,
so
this
is
something
we
haven't
looked
at
much
detail.
Yet
we
need
to
look
this
a
bit
more
but
more
time
effectively
with
these
versioning
changes,
we
still
have
an
issue
that
import
by
the
revision.
We
think
it's
too
tightly
bound
today
and
if
you're,
using
version
numbers
of
smart
versions
and
modules
for
want
to
do
some
sort
of
import
by
version
number
and
choose
this
version
or
latest
or
later
or
be
able
to
sum
to
some
subset.
K
K
Thing
we
talked
about
so
now
we
think
we're
discussing
it
today.
We
think
you
could
do
it
as
an
extension.
So,
if
you're
doing
important,
don't
specify
revision
dates
today
it
doesn't
specify
which
version
and
whatever
you
get
so
you
think
we
could
do
an
extension
to
it
to
the
existing
port.
That
says
I'm
going
to
select
this,
and
if
you
understand
it,
you
get
the
one
you're
selecting
you
don't
understand
it.
K
Sometimes
you
can't
do
these
mappings.
It
depends
what
your
change
is.
It's
gonna
be
cases
where
it's
impossible,
so
if
you
need
need
to
be
able
to
handle
that
it's
worth
observing
that
this
can
be
done
in
the
server
done
in
the
controller
to
be
done
in
a
client
and
there's
question
is
to
what
version
would
a
client
get?
If
it
didn't
do
this
negotiation,
it
didn't
choose
what
to
get
by
default.
K
We
in
terms
of
the
design
team,
there's
big
questions
as
to
whether
vendors
would
implement
this,
so
I
am
still
of
the
opinion.
It's
definitely
right
to
specify
this,
but
there
is
a
question
as
to
whether
the
vendors
will
actually
spend
the
money
to
implement
it,
and
it's
because
it's
a
hard,
expensive
problem
and
it's
hard
expensive,
where
it's
implemented,
but
it's
in
the
client
or
server.
K
So
next
steps
so
incorporate
feedback
from
the
working
group
and
obviously
one
that
there's
a
design
team
or
two
conversion.
A
solution
I'm
not
quite
sure
whether
we're
there
yet
I
think
this
I'd
like
to
see
what
you
like,
you're
gonna,
write
up
on
the
lose
look
at
me
like
that.
Yes,
I'd
like
to
see
that
from
you
and
maybe
you're,
going
to
talk
about
to
make
the
two
of
you
can
discuss
and
producer
because
I'd
like
to
see
that
solution
effectively.
K
The
hope
is
to
have
an
issue
of
solution,
draft
very
thought
for
one
at
four,
but
that
wouldn't
be
everything
I
think
we're
aiming
to
do
like
maybe
a
core
solution,
one
which
is
the
much
of
version
numbering.
We
include
the
import
stuff
in
there.
The
states
changes
in
there
and
then
we
do
a
separate
extension
for,
like
version
selection,
stuff
I,
think
that's
more
complicated
that
come
as
a
subsequent
draft.
K
R
I'm
binoculars
from
Cisco,
so
I've
been
quite
so
far
and
I'm
wondering
what
to
do
at
this
point
in
time,
so
the
design
team
with
money,
vendors,
I,
counted
five.
So
apparently
that's
an
issue
at
least
four
vendors
now
I
would
say
that
not
all
of
us
have
the
luxury
to
start
from
scratch.
With
data
modelling
management
I
would
like
the
world.we
perfect
with
models.
You
know
they
won.
They're,
perfect
they're,
only
augmented,
and
there
is
no
no,
no
but
portable
changes.
R
It
would
make
the
love
our
customers
way
more
easier
that
way,
but
you
know
it
doesn't
work
that
way,
at
least
for
the
vendors
I
wish.
We
had
like
no
train
and
platform
issues.
We
do
that's
a
fact
and
I
wish
that
we
no
requirements
from
customers.
Turning
to
us
asking
for
an
update
of
that
specific
module
and
the
platform,
a
train,
we
do
so
if
it's
a
perceive
as
an
ITF
issue
right
that
the
vendor
issue,
who's
got
like
trains
and
platforms
and
who's
trying
to
transition
into
this
perfect
world
of
model
standard
models.
J
Rob
cheeky,
a
Google
I
think
that
I
would
like
to
see
some
comparison
of
what
you
can't
do
with
a
multi
module
solution
right
because
they
kind
of
the
aim
here
is
so:
okay,
we're
gonna
go
semver
with
some
modification
based
on,
like
you
have
to
believe
that
you
can't
solve
this.
You
don't
have
to
solve
the
bundle
problem
and
you
you
can't
solve
your
fixes
with
orphan
and
DVA.
Okay.
J
B
So
I
kind
of
wanted
to
address
one
comment:
I
I,
don't
think
anybody
is
not
understanding
that
you
have
issues
as
vendors
right
to
solve
and
I'm,
not
saying
that
and
I,
don't
think.
If
we're
not
saying
oh,
do
you
definitely
can't
solve
them
with
an
ITF
solution
either?
It's
not
that
it's
just
that
there
are
ways
to
solve
it
without
putting
it
is
a
one-to-one
mapping
in
the
require
right,
I
mean
there
are
ways
to
solve
the
the
Train
issue
with
features
and
deviations
ago.
B
F
K
One
one
last
question
to
the
room
is
for
me
is
there's:
does
the
room
feel
like
we're
going
the
right
direction
here
and
they
don't
thought
so
now?
If
they
don't
would
be
useful
to
drop
us
an
email
and
say
no
go
for
a
long
track
or
if
you
think
we
are
heading
in
the
right
direction.
That
goes
to
be
good.
Snack.
L
K
N
K
K
A
A
K
K
A
Speak
for
myself
as
one
chair,
and
so
this
is
what
the
chair
had
on,
but
by
other
chairs
may
disagree.
I
think
you
do
continue
on
and
come
back
give
us
updates,
but
don't
forget
about
the
hard
problems.
I.
Think.
If
I,
if
you
say
I
mean
you
don't
to
start
with
the
hard
problems,
I
think
the
notion
of
decomposing.
The
problem
then
and
funny
you
know,
hit
the
easy
ones
first
and
make
sure
you
have
a
solution
from
there.
A
But
then
you
have
to
test
them
against
the
hard
ones
mm-hm
because
they
may
not
hold
together.
Once
you
hit
the
hard
one,
I
mean
they
have
to
throw.
You
know
some.
There
might
be
some
simple
solution
to
a
hard
problem.
That's
just
wrong
and
you
won't
know
it
until
then
test
it.
Okay,
yeah
I,
don't
know
if
I
the
floor
wants
to
respond,
or
my
co-chairs
won't
respond.
I
That
works
for
me,
you
know
Charles
I
call,
so
it
seemed
to
me
like
we
were
pretty
much
just
between
is
somber
or
just
modified
some
for
the
right
way
for
it.
I
didn't
hear
anyone
really
going
towards
those
other
things,
so
it
seemed
to
make.
There
was
pretty
broad
agreement
on
at
least
December
part,
and
then
it's
just
this
bit
of
hey.
Do
we
really
need
to
modify
some
verb
or
is
there
a
better
alternative?
So
to
me
it
felt
like
we're.
You
know,
showing
around
a
pretty
close,
pretty
tight
area
of
solution.
I
A
Working
on
it
of
my
cuca
vendors
working
on
it
are
converging
on
a
problem
on
a
solution
that
they
agree
with.
It
doesn't
cover
the
full
requirements
that
so
you
know,
I,
don't
think
we
can,
and
you
know
so,
I've
heard
some
people
who
responded
pretty
strongly
that
they're
not
happy
with
the
direction
and
I.
A
I
That's
my
read:
I
thought
Robin
Chris
may
be
misunderstood,
but
I
thought
you
were
both
thinking
summer
would
work
pretty
well
and
and
then,
but
the
thought
that
Rob
was
saying
and
Joe
was
that
that's
not
quite
that
still
causes
us
in
grief.
We
need
this
modified
summer
and
I
thought
those
were
the
two
things
we
were
kind
of
bouncing
between.
But
if
that's
not
the
case,
then
maybe
I'm.
A
G
I
mean
I
think
the
question
is
actually
worth
asking
again
on
the
list:
I,
don't
think
the
we
are
going
to
have
to
ponder
the
answer
for
a
while,
but
I
think
like
there
has
been
abundant
feedback
lately.
I
mean
there's
a
number
of
points
where
there
should
be
next
steps
that
we
can
take
by
consulting
them
the
minutes,
but
we
still
have
hard
problems
to
actually
address.
First
before
we
decide
that,
like
everything
is
hunky-dory
and
we
should
proceed
down
this
road
I.
A
R
J
I
think
Rob
Lowe
I
think
that's
well,
characterized
I,
don't
think
I'm
very
happy
if
Zimmer
as
the
solution
here,
because
I've
already
done
it
for
a
while
I'm,
probably
when
I'm
going
to
change
the,
but
what
I
do
think
the
wider
solution,
I
think
needs
to
be
considered
is
how
this
problem
space
entirely
works.
So
I
think
we
can
look
at
a
small
set
of
the
problems
and
kind
of
say:
okay,
this
is
the
case.
J
Then
we
have
to
look
at
like
overall,
not
only
just
the
requirements
that
we
have,
but
what
the
reality
of
running
a
system
is
before.
We
can
really
conclude
if
this
is
the
right
direction,
so
that's
the
raising
my
hand
for
I
think
you
should
look
at
other
things.
I
think
it's
take
a
step
back
and
look
at
consider
more
than
one
module
on
a
server.
So
that's.
L
G
Any
further
down
the
road
I
think
this
evening,
so
I
think
we
should
probably
call
it
at
that
point.
There
definitely
is
work.