►
From YouTube: NETMOD WG Interim Meeting, 2021-02-01
Description
NETMOD WG Interim Meeting, 2021-02-01
B
Intro
slides
right
go
ahead.
Yes,
it
is
now
recording
great
welcome
to
our
second
interim
on
the
topic
of
versioning,
and
if
you
came
on
a
little
early,
you
heard
one
of
the
authors
say
we
really
want
to
move
forward
on
the
issues
that
are
being
raised
here.
So
even
though
we
we
don't
have
a
huge
participant
list,
a
huge
amount
of
participants
we're
going
to
try
to
achieve
that
objective
of
reaching
consensus
in
here
and
then
bring
that
bringing
those
that
consensus
to
the
list
for
final
agreement.
B
B
B
If
you
want
to
have
a
side
discussion,
jabber
is
the
place
for
that,
although
I
have
to
say
that
people
are
not
joining
jabber
in
general
right
now,
I'm
the
only
one
in
there,
but
that's
really
the
place
for
side
discussions
you'd
like
to
try
to
keep
the
chat,
the
the
media,
sorry,
the
webex
says
media,
let's
just
say,
webex
chat.
Just
for
that-
and
I
know
we're
not
always
successful
on
that.
Almost
all
the
slides
posted
there's
one
deck.
That's
missing!
B
B
The
the
presenters
are
going
to
be
managing
the
time
here
and
so
hopefully
we'll
keep
things
moving
along,
and
this
is
sort
of
the
the
standard
disclaimer
we've
had
during
these
covid
times.
If
you
would
like
to
have
an
interim,
please
just
let
the
the
chairs
know
if
you'd
like
to
have
informal
meetings
and
use
the
working
group
webex,
please
also
let
the
chairs
know,
although
I'll
also
point
out
that
we
have
other
online
tools
that
are
available.
C
C
You
go
yeah,
they
look
good,
okay
and
I
can
be
heard
obviously
right.
So
this
is
one
of
the
one
of
the
four
issues
I
think
we're
going
to
cover
today.
I'm
hoping
that
this
one
is
not
very
difficult,
contentious,
so
I'll,
try
and
go
over
this
fairly
quickly.
There's
only
three
slides
to
talk
about
and
then
take
any
questions
that
you
might
have
or
comments
on
that.
C
C
And
I'll
solve
that
problem
a
minute
I
can't
see
who
the
only
one
asks
questions
you
may
have
to
speak
up,
because
I
can't
see
so.
The
iron
considerations
ayanna
publishes
some
yang
modules
based
on
registries,
and
so
some
examples
of
that
is
the
inr
iftypes.yang
that
we
know
that
have
all
the
different
interface
types
ayanna
routine
types.yang
is
another
one
and
there's
under
some
more
mostly
when
they
added
like
additions
to
those
base.
Registries
and
the
young
issues
get
updated.
C
Their
back
was
compatible,
but
there
have
been
instances
where
there
have
been
some,
or
at
least
one
set
of
non-backwards-compatible
changes
to
the
iana
routing
types
when
they
were
modifying
yafi-safi
families.
I
think
so
so
at
least
one
case
where
there's
a
reason
that
the
registry
was
being
changed
in
a
non
backwards
compatible
way,
and
so
the
young
module
being
generated
by
anna
was
also
changing.
Lumbar's
computer
weight
was
consistent.
C
We
believe
that
we
should
provide
guidance
to
iona
on
how
to
manage
these
generated
young
modules
with
respect
to
backwards,
compatible
changes
and
non-box
cluster
changes
and
you
to
semantic
versioning.
The
proposal
here
is
I've
added
text
actually
hasn't
been
committed
to
the
document
will
be
by
the
next
revision.
The
proposal
is
to
once
we've
gone
over.
The
the
key
points
here
is
to
ask
ayanna
for
an
early
review
of
that
text
to
check
that
they're
happy
with
it
with
the
proposed
rules
and
guidance
text.
C
So
there's
two
drafts
that
we've
updated
ins
sections
two,
the
first
one
is
the
yang
module
versioning
draft
and
I
haven't
cut
and
paste
the
text
here.
I'm
not
sure
that's
helpful,
but
an
overview
of
what
it's
going
to
say.
Is
it's
going
to
give
an
example
of
the
issue
where
it
was
modified
in
a
non-banks
commercial
way
and
that's
the
20?
Well,
they
said
the
december
31st
revision
last
year
of
the
iona
routine
types.yang.
C
It's
going
to
make
a
request
of
ayana
to
follow
version
guidance
in
the
module
version
draft.
It's
going
to
request
diana
to
add
rev
nbc
changes
statement
when
needed.
So
whenever
a
module
has
been
updated
and
non
backwards
compatible
way,
then
it's
going
to
suggest
that
that
statement
be
added
and
and
one
other
side
effect
of
that
is
we're
proposing
that
whenever
an
existing
iron
module
is
updated
to
go
back
and
retrospectively,
add
any
rev
nbc
changes
labels
where
required
so
next
time,
ayanna
rooting
types
is
updated.
C
It
would
also
update
and
add
a
rev
nbc
changes
label
to
the
31st
of
december
2020
revision
as
well.
To
mark
that's
where
an
nbc
change
has
happened
and
then
the
last
point
is-
and
this
one
is
more
interesting-
is
that
the
plan
was
to
provide
some
non
non-normative
example:
text
of
likely
backwards,
compatible
or
nbc
changes
updates.
That
might
happen
to
and
maintain
gang
modules.
So
obviously,
these
documents
have
a
full
set
of
guidance
and
reference
back
to
seven
950
module
rules.
C
So
that's
proposed
in
the
module
version
draft
and
that's
half
of
the
solution,
and
then
the
other
half
is
in
the
yang
simva
draft,
and
this
was
going
to
request
in
fact
required.
Iona
adds
yang
simva
versions
to
iona
modules
and
following
the
standard
rules
and
when
updating
existing
modules,
the
proposal
is
to
retrospectively
add
version
labels.
C
C
We
will
we'll
put
this
extra
text
in
this
is
non-operative
text
and
then
we'll
also
ask
ayanna
whether
they
feel
that
text
is
useful
or
not
required
or
whether
they're
happy
just
referring
back
to
the
main
rules
for
these
things.
So
that's
all
I
have
on
the
iana
topic,
so
any
questions
or
comments
on
this.
E
Hi
this
is
kent,
rob
we're
just
using
the
chat
window,
so
I'd
put
a
plus
q
there
yeah
I
can
see
now,
but
as
an
individual.
My
question
is
so
you're
asking
ayanna
to
retroactively.
You
know,
put
versions
to
the
drafts,
would
they
be
involving
the
authors
or
the
chairs,
or
I
mean?
Are
they
going
to
do
it
on
their
own?
What's
the
guidance
there.
C
C
In
this
particular
case,
these
modules
are
generated
purely
by
anas
ayana.
So
they
will.
I
think
people
could
potentially
ask
for
I
go
back
a
couple
of
slides.
They
can
ask
for
a
new
interface
type
to
be
allocated.
They
must
be
registered
for
that
and
whenever
a
new
interface
type
is
allocated,
then
I
believe
in
if
types
gets
updated
automatically
to
reflect
that
registry
and
the
same
with
iona
routing
types
that
when
some
change
is
made
to
that
registry,
the
iona
routing
type
is
updated
automatically,
so
there
are
rfcs
that
make
that
request
of
ayana.
C
B
And
lu
blue
is
individual.
Does
it
make
sense
to
put
some
recommendation
in
when
it's
appropriate
to
have
a
module,
that's
sort
of
self-managed
by
anna,
when
it's
not-
and
I
know
that
this
may
belong
more
in
the
guidelines
to
for
yang
documents,
but
it
doesn't
have
it
in
there.
I
just
did
a
quick
search.
Unless
I
missed
it,
I
don't
think
it
has
it
in
there
in
it.
It
might
be
worth
telling
people
when
to
not
use
nyana
defined
module
when
they're
defining
new
ones.
B
C
Yes,
although
I
could,
I
could
foresee
that
you,
even
if
you
didn't
have
the
interface
types
registry
and
assuming
the
one
exists,
I
could
imagine
that
you
might
just
have
the
yang
module
and
have
ayanna
own
up
by
updating
those.
I
guess
in
the
end
it
seems
like
actually
in
all
those
cases,
you'd
probably
say:
here's
the
registry
of
values
and
the
yang
module's
always
derived,
I
suspect.
C
B
F
Jason,
but
just
just
to
address
the
last
point,
a
little
bit
like,
I
think,
there's
two
slightly
different
things
here
and
maybe
lou.
I
think
you
were
looking
for
maybe
some
guy
general
guidance
on
when
ayanna
would
own
a
yang
module
and
what
it
wouldn't.
I
think
that's
useful
to
clarify,
although
I
think
it's
a
little
outside
the
scope
of
our
work,
so
maybe
that's
more
of
a
kind
of
a
side
point.
This
is
kind
of
more
when
the
decision
has
been
made.
That
ayanna
is
is
owning
a
module.
B
Yeah-
and
I
I
completely
agree,
it
better-
belongs
in
what
is
it
6087
the
guidelines
document,
but
we're
not
going
to
rev
the
guidelines
document
to
put
in
one
sort
of
one
one
informational
statement
of
when
you
do
it.
It
just
sort
of
seems
like
it
could
fit
here,
not
as
a
you
know,
a
hard
requirement,
but
as
just
some
guidance,
because
we're
we're
having
text
here
on
guidance
and
part
of
that
could
be
to
for
iana
to
understand
when
they
should
push
back
on
accepting
a
new.
C
C
C
F
G
G
We
see
the
same
as
the
same
yang
module,
which
has
two
different
file
names
here,
one
using
the
date,
which
is
the
current
method
in
7950
and
then
the
second
one
using
the
revision
label,
which
is
what
we're
proposing
here.
So
we
went
back
and
forth
and
we
came
back
to
this
issue
is
not
really
needed.
G
The
I
mean
there's
no
design
team
anymore,
but
the
people
who
meet
on
tuesdays
believe
that
having
the
version
label
in
file
names
is
definitely
useful
for
human
readability,
and
you
know
it's
potentially
useful
for
tools.
Also,
one
question
which
you
know
we
have
and
that
I
guess
depends
on
the
crystals
and
various
implementations
is
you
know,
what's
the
implication
of
having
two
copies
of
the
same
module
with
different
file
names?
G
E
E
G
E
I
do
like
the
idea
of
the
module
showing
up
twice
or
I
mean,
let's
just
say
each
system.
You
know
a
system,
that's
legacy
and
has
been
using
revision
labels.
It
would
persist
the
file
locally
using
the
at
simple
and
then
maybe
new
systems
would
be
using
pound
symbols.
Then
I
like
the
the
transition
or
migration
strategy
that
it
implies,
but
there
is
this
question
that
and
that
you
raise,
would
it
immediately
break
in
existing
tools?
I
think
we
need
to
test
it.
Okay,.
H
F
G
I
Right
yeah,
so
I
think
tools
will
eventually
converge
on
making
this
work,
I'm
sure,
but
I'm
a
bit
worried
about
the
cognitive
load.
If
you
take
a
typical
router
or
something
like
that
with
a
thousand
yang
modules,
would
suddenly
have
two
thousand
yang
modules.
So
it's
it's
adding
to
the
human
operator's
cognitive
load,
trying
to
make
sense
of
it.
So
I'm
not
particularly
in
favor
of
having
duplicates
as
bad
as.
G
I
G
F
E
Right
well,
rashad
may
have
just
said
it,
but
I
was
going
to
say:
I
think
it
is
actually
one
or
the
other
not
not
duplicated,
as
I
mentioned
before,
legacy
systems
would
only
be
using
the
revision
dates,
and
those
systems
that
were
migrating
from
one
to
new
would
actually
have
the
option,
but
they
would
only
have
one.
They
would
always
only
be
the
1000
files,
not
not
never
the
2000
files.
E
Right
but
sorry
to
respond
when
the
new
file
is
being
imported
into
system.
The
system
can,
you
know,
say:
hey
you're,
not
meeting
my
import
file,
naming's
requirement.
You
must
use
the
file
name.
That
includes
the
revision
label,
not
the
not
the
versioning
string,
and
so
so
that
system
will
only
ever
have
the
files
that
it's
able
the
single
copy
named
the
way
that
it's
able
to
support.
C
Yeah,
I
think
I
basically
agree
with
what
kent
saying
here
is
you're
allowed
to
have
both
of
you
really
want
to
if
you've
got
some
reason
to,
but
my
expectation
is
is
that
you
would
move
to
using
this
new
scheme
if
you're,
using
modules
that
are
being
revisioned
using
somatic
version
numbers,
for
example,
and
that's
what
you'd
expect
to
turn
up
in
like
packages
urls
and
things.
I
don't
think
you
would
end
up
with
two
sets
of
these.
It's
just
which
way
you
label
those.
G
Okay,
thank
you.
Okay,
next
slide.
Okay,
so
then,
when
we
started
talking
about
revision
labels
in
file
names
that
led
on
to
the
discussion,
well,
what
should
we
allow
in
revision
labels?
We,
you
know.
Obviously
we
you
know
the
two
diameters
we're
talking
about
in
file
names
should
should
be
avoided.
Maybe
that
should
be
a
must.
I
don't
know
we
discussed
in
weekly
meetings,
whether
we
should
allow
different
character
sets
and
all
that
and
for
now
we're
saying
we
don't
believe.
That's
needed.
G
There's
two
main
options
which
we
discuss.
One
is
either
be
very
restrictive,
start
restrictive
with
a
small
set
of
what
we
allow,
or
you
know,
by
default,
we're
permissive
and
we
disallow
some
specific
ones.
Other
stuff
we
discussed.
Do
we
allow
comma?
Well,
you
know
we
went
back
and
forth
on
that,
and
then
there
was
an
example
which
was
given
where
it's
used.
I
forget
in
what
system
for
precedence?
G
E
G
C
I
was
just
gonna
thank
you,
yeah
she's,
gonna
jump
in
actually
so
just
to
go
back
to
kent.
The
one
extra
character,
at
least
that
we
are
adding
if
you
look
at
2a,
is
definitely
the
plus
character,
and
I
think
the
comma
also
are
characters
that
we
will
be
adding
beyond
what's
specified
for
a
yang
identifier
and
I
think
there's
definitely
cases
where
plus
would
turn
up
in
versioning
schemes
and
the
commas
being
used
in
at
least
one
version's
versioning
scheme.
So
that's
why
that
was
on
the
list,
but
in
the
design
team
meetings.
E
J
So
if
you
add
a
mandatory
leaf
to
a
config.
True
part,
that's
nbc,
but
if
you
add
something
extra
that
comes
back
from
the
node
yep,
you
can
just
ignore
it
and
it
works.
So
we
proposed
to
add
a
separate
compatibility
rules
for
config
false
data
that
are
partly
different
from
what
we
have
today
in
79.50.
J
J
Also,
there
is
not
just
the
config
force
data,
but
output,
section
of
notifications
and
actions
and
rpcs
are
the
same.
So
they
are
again
any
data
that
comes
from
the
node
or
most
of
it
is
very
similar,
and
then
we
want
to
put
really
some
requirements
on
clients
most
basic.
They
should
be
able
to
survive
whatever
comes
out
of
the
node
or
whatever
does
not
come
from
the
node
and
then
some
simple
things
like
this
discarding
elements,
attributes
properties
should
be
trivial.
J
On
the
other
hand,
the
well-designed
client
should
be
able
to
do
more
than
this.
So
if
part
of
the
data-
let's
say
a
big
chunk
of
data-
is
valid,
it
should
be
able
to
use
it.
Even
if
the
other
is
discarded
value.
Space
extensions
should
be
tolerated
to
some
level,
also,
the
too
many
lists
or
the.
If
this
item
should
be
tolerated,
just
discard
the
rest,
so
we
came
up
with
some
basic
rules.
J
One
is
that
adding
mandatory
optional
data
nodes-
and
these
are
rules
strictly
for
config,
false
data,
so
just
those
just
those
ones
so
adding
anything
extra,
that's,
okay.
Basically,
if
the
client
can
discard
anything
that
comes
out
and
consequence,
if
that
you
make
something
optional
or
into
mandatory
yep,
that's
just
a
bit
of
extra
data.
If
the
client
doesn't
care
discard
it
more
controversial
is
removal
of
optional
data.
One
thought
about
this
was
that
it's
optional,
so
the
client
never
promised
you
you
it
or
sorry
the
server
never
promised
it
will
send
anything.
J
J
Similarly,
okay,
the
next
one
is
removal
of
mandatory
data.
Yes,
the
client
should
survive
into
the
crashing,
but
if
it
expects
mandatory
state
data,
then
yeah,
that's
that's
on
on
backwards
compatible
and,
as
a
consequence,
changing
mandatory
data
into
optional.
That's
the
same
thing
as
potentially
removing
mandatory
data.
J
Value
space:
now
it's
a
bit
of
a
reverse
compared
to
configuration.
So
if
it
is
decreased
yep,
then
that
should
be
perfectly
acceptable.
No
one
said
that
we'll
use
every
value
of
it
all
the
time.
On
the
other
end
expanding
the
value
space,
it
should
be
tolerated.
It's
strictly
speaking.
This
can
cause
problems
to
a
client.
If,
let's
say
it,
stores
the
integers
on
a
byte
because
they
believe
that
never
we'll
go
over
it.
But
I
think
we
should
be
more
liberal
in
this
case.
Otherwise
all
the
changes
will
become
nbc.
J
F
A
E
I'm
just
replying
to
that
last
comment.
I'm
thinking
as
jason.
If,
if,
if
a
vendor
were
to
drop
all
the
statistics,
that
would
probably
be
not
appreciated
by
the
market
and
they
would
lose
you
know
market,
I
people
would
I
don't
think
they
would.
I
mean
theoretically,
yes,
but
in
practice
I'm
not
sure
if
it
would
happen.
F
F
So
I
mean
our
general
spirit
here
is
that
when
you
just
suddenly
stop
returning
something
in
a
state
model,
that's
or
it's
a
bit
different.
If
you
suddenly
start
having
those
items
in
the
model,
you
know
an
old
client
is
working
with
the
old
model.
That's
fine!
He
just
won't
receive
those
leafs,
but
I'm
still
struggling
with
how
intuitive
that's
going
to
feel
to
people
that
when
you,
you
know,
you
remove
an
octet
counter
from
your
model
or
remove
some
other
piece
of
state
that
somehow
that's
still
considered
backwards,
compatible.
E
And
just
to
quickly
add
on
to
respond
to
that,
I
would
hope
that
they
would
go
through
a
deprecation
policy,
so
they'd
first
deprecate
it
and
then
subsequently
obsolete
it
and
remove
it.
They
could,
but
they
don't
have
to
because
it's
considered
fully
backwards
compatible.
I
know
but
again
managing
expectations.
So
if
you
were
a
good
vendor
and
that's
you
know,
you
would
do
that.
J
B
B
Why?
Because
I
think,
if
you're
removing
the,
if
you're
reducing
the
value
space
on
mandatory
data,
that's
a
non-backward
compatible
change
from
a
user
standpoint.
I
may
have
some
sort
of
automation
system
that
relies
on
that
mandatory
data
and
relies
on
that
value
space
and
as
a
vendor
you're
not
going
to
know
that,
and
you
give
me
a
model,
that's
supposed
to
be
docker
compatible
and
you
break
my
automation
system.
B
B
J
J
B
Statement,
I've
built
an
expensive
automation
system,
that's
relying
on
that
changing
state.
When
I
see
it,
I
do
a
whole
bunch
of
things
your
you
know
the
equipment's
been
tailored
to
the
the
equipment
and
it's
been
working
great
and
now
this
new
version
that's
not
flagged
as
non-backup
compatible.
You
know
I
tell
my
vendor:
I'm
only
going
to
take
backward
compatible
models,
they
say
sure
this
is
backward
compatible
and
all
of
a
sudden,
my
very
expensive
automation
system
breaks.
C
C
J
C
But
to
to
give
an
example,
you
could
have
a
counter
on
an
ethernet
interface
which
splits
them
out
between
unicast
multicast
and
broadcast
packets,
and
that
makes
sense
for
those
ethernet
interfaces.
You'd
expect
it
always
to
be
returned,
but
if
you
had
another
interface,
a
sonnet
interface
or
something,
then
you
wouldn't
have
that
split
out.
So
you
can't
really
make
it
mandatory
because
it
doesn't
make
sense
in
some
cases,
but
for
all
those
interfaces
you
would
expect
it
always
to
be
returned
or
if
the
system
doesn't
support
it,
to
deviate
it
away.
E
Okay,
yeah
two
responses.
I
guess
first
to
lose
comment
the
removal
of
mandatory
data.
I
think,
there's
a
difference
between
the
leaf,
removing
the
leaf,
which
was
mark's
mandatory
true
and
if
the
was
type
enumeration
you
know
the
enumerated
values
were
they
marked
mandatory
or
not
and
but
to
others
points
historically,
we've
been
very
lax,
probably
in
the
marking
of
state
data
and
especially
enumerations
just
enumerated
values
as
if
they
are
mandatory
or
not.
E
Secondly,
as
we're
going
through
this
transition,
we
may
need
to
retroactively
mark
things
appropriately,
so
that
the
expectations
can
be
managed
going
forward
and
then,
lastly,
it's
a
slightly
different
point,
but
it
goes
to
the
fourth
sub-bullet
point
here:
expanding
the
value
space.
I
think
this
also
needs
to
take
into
account
patterns.
E
J
A
I
Jan
is
next
in
the
queue
okay,
so
I
think
I'm
very
much
with
balaj
here.
If
you
read
a
yang
model
and
it's
not
giving
you
any
guarantees,
we
shouldn't
be
reading
in
additional
thoughts
about
what
the
author
had
intended
with
something.
So
I
mean
backwards.
Compatibility
is
not
only
about
optional
or
mandatory,
it's
not
only
about
when
expressions.
It's
also
about
what
the
description
statement
says.
I
So
if
you
are
something
removing
some
intermediate
interface
state,
that's
no
longer
existing
or
something,
then
you
supposedly
would
write
about
that
in
the
description
statement
and
that
wouldn't
be
backwards
compatible.
Perhaps
we
can't
just
assume
that
I
mean,
if
there's
nothing
written
in
the
description,
there's
nothing
in
when
nothing
mandatory.
Why
should
we
expect
that?
It's
that
the
device
would
actually
return
this
optional
leaf,
but
if
there
is
something
in
the
description,
we
can
trust
that
and
that
might
be
incompatible
change
if
we
change
the
statement.
C
I
C
J
C
I
F
So
my
points
are
all
around
the
exact
same
discussion.
I'm
I'm
I'm
definitely
more
in
line
with
rob
on
this,
but
I
I
think
the
common
expectation
in
these
models
is
that
it's
like
I
don't
I
don't
think
we
should
be
mark.
I
don't
think
we
should
be
transitioning
to
this.
A
situation
where
we
try
to
mark
all
sorts
of
state
leaves
and
our
models
mandatory.
F
I
think
there's
a
lot
of
behavior
around
state
that
is
too
difficult
to
describe
in
the
model,
I
think
describing
the
existence
of
counters
in
the
model
and
what
format
you
could
expect
for
the
counter,
but
things
like
interface
stats.
Some
of
the
counters
are
applicable
to
some
types.
Some
aren't
some
may
be
applicable
in
some
situations
that
aren't
really
describable.
F
I
I
think-
and
you
know,
clients
the
things
with
the
state
estate
variable
clients.
I
I
think
clients
need
to
be
designed
around
the
fact
that
they
generally,
they
can't
count
on
a
state
variable
being
returned.
But
when
it's
returned
they
need
to
know
how
to
handle
it,
and
if
it's
returned,
that's
what
the
model
tells
them.
What
to
do.
I
I
We
are
not
seeing
agreement
here.
If
the,
if
you
have
a
case,
that's
undescribable,
you
can
never
know
you
cannot
really
tell
from
the
outside.
If
it's
going
to
be
returned
or
not.
If
you
stop
returning
it
in
that
case,
nobody
will
be
able
to
tell
the
difference
so
that's
backwards
compatible.
But
if
you
do
have
a
description
statement,
this
is
going
to
be
delivered
for
all
the
interfaces
under
certain
conditions
and
as
long
as
those
conditions
are
met,
it
would
be
back
with
compatible
not
to
return
it.
I
F
Mean
it
would
be
nbc,
I
think
you
meant
you
know
like
if
the
description
says
this
is
this
is
usually
returned
and
you
don't
I
mean
there's
two
things
here.
We
got
to
be
careful
about
guys,
there's
what's
in
the
model
and
there's
what
a
server
does,
so
those
are
two
slightly
different
things
and
what
what
we're
trying
to
decide
here
is
what
do
we?
What
do
we
mark
in
a
change
to
the
model?
F
J
C
C
So
you
can
change,
you
could
change
the
language,
not
you
know
what
I
want
to
say.
If
we
were
to
go
down
the
path
say
mandatory
is
the
default.
Major
is
the
default
for
config
false
nodes
unless
you
turn
it
to
be
mantra
false,
but
it
seems
to
be
if
we
require
people
just
to
add
the
word
mandatory
to
all
config
false
nodes,
it's
just
going
to
be.
Noise
doesn't
actually
really
help.
C
J
F
F
But
I
think
that's
very
unusual
in
the
industry.
From
from
my
experience,
I
don't
see
mandatory
in
much
state
out
there
at
all.
I'm
not
sure.
If
other
people
are
I
mean,
I
haven't
done
the
research,
but
from
my
memory
of
cruising
around
state
models
and
open
config
and
hours
and
ietf
models.
I
that's
a
pretty
rare
thing.
I
think,
to
see
state
marked.
F
Mandatory
again,
I'm
not
so
much
arguing
what
mandatory
maybe
should
mean
for
state.
I
think
mandatory
true,
probably
should
mean
the
same
thing
as
can
well,
it
should
mean
that
the
it's
guaranteed
to
be
returned.
I
think
what
I'm
arguing
a
little
bit
more
is
I'm
not
sure
that
should
be
widespreadly.
F
That
should
be
used
much
at
all
in
many
models,
because
I
think
too
many
of
them
will
have,
even
if
they
have
one
percent
of
the
cases
or
five
percent
of
the
cases
where
it
really
is
allowed
to
be
suppressed,
because
it's
not
applicable.
Well,
then
you
can't
mark
it
mandatory
mandatory.
You
have
to
be
really
certain
that
you're
only
conformant
to
that
model.
If
you
are
returning
that
thing,
any
query,
no
matter
what.
J
J
E
All
right,
I
I
yeah,
I
agree,
I
think,
historically,
it's
been
best
effort,
but
I
also
think
that's
probably
not
in
the
interest
of
interoperability,
ultimately
we're
trying
to
enable
clients
to
be
interoperable
with
an
upgraded
server
and
the
focus
has
been.
You
know
on
the
being
able
to
push
configuration,
and
you
know
whether
or
not
that
semantics
of
the
prior
configuration
is
still
understood
by
the
server,
but
also
it's
the
values
that
come
out
of
the
server.
And
you
know
if
this
client
is
not.
E
If
it's
legacy
understanding
is
no
longer
valid,
then
you
know.
However,
it's
done
whether
it
be
in
a
description
statement
or
not.
It's
still
breaking
the
expectations,
and
I
do
think
it's
probably
a
problem
that
we
have
not
been
good
on
setting
the
mandatory
values
on
the
state
data
like
so
we
have
and
to
rob's
point
I
don't.
I
don't
think
we
can
just
modify.
You
know
say
it's
like
default
mandatory
true,
so
you
only
have
to
you
know
flag
it
when
mandatory
false
that
that
would
actually
be
breaking
existing
semantics.
E
We'd
have
to
have
yang
next
in
order
to
introduce
that
kind
of
change,
but
I
don't
see
the
issue
I
mean
you,
you
spoke
through
it
being
noise,
so
what
noise
to
a
computer?
It
doesn't
really
matter
if
they
can
process
it.
Fine,
I
mean
if
you
humans
are
reading
the
module.
Maybe
it's
a
little
bit
more
busy
looking,
but
I
don't
necessarily
see
that
as
a
reason
for
not
to
do
it
relative
to
the
issue
that
we're
facing.
J
So,
as
I
see
it,
we
have
one
principle:
there
are
questions.
How
strict
do
we
want
to
be
with
allowing
things
to
be
changed
like
removable,
optional
data
and
reducing
value
space,
and
there
are
two
thoughts.
One
is
that
mandatory
means,
mandatory
optional
means
optional,
that's
one
way,
and-
and
that
is
a
good
thing
in
the
end-
that
we
really
say
what
we
mean,
or
we
can
say
that
in
practice,
people
are
not
using
mandatory
properly.
C
K
F
F
Then
I
think
I
think,
there'd
be
a
second
interesting
discussion
of
how
much
you
should
use
those
strict
markings
like
I
yeah
like
what
would
an
information
implementation
do
so
say
we're
strict
and
we
marked
the
iaf
module
and
mark
all
those
counters
as
mandatory
the
all
the
different
error
counters,
the
so
so
like
from
the
ifm
there's
a
bunch
of
different
error
counters
right.
Some
of
them
are
related
to
there's
like
disc
out
discards,
out
errors,
etc.
F
So
we
mark
all
that
as
mandatory
and
then
and
an
implementation
has
some
corner
cases
where
they
sometimes
don't
return,
those
for
certain
types
of
interfaces.
What
would
they
do?
Would
they
they're
not
going
to
deviate
those
leafs
because
they
return
them
for
some
but
they're
going
to
break
the
contract
for
some.
F
E
We
we
need
to
wait
for
yang
next,
to
you
know,
put
new
rules
that
are
more
strict
or
deterministic,
let's
say,
and
and
then
only
the
yang
next
specific
modules
can
have
those
guarantees
that
we,
that
that
we
want
slash
the
market
needs
in
order
to
to
to
address
this
issue
fully,
so
we
may
actually
be
in
a
in
a
gray
area.
Now
we
just
need
to
do
the
best.
We
can.
E
C
E
Well,
so
actually
I
mean
there's
but
there's
a
prior
statement
to
that,
which
is
when
my
client
first
investigate
or
interrogates
the
gang
library
to
see
what
version
of
the
module
is
being
used
and
it's
compatible
with
it.
So
we're
I
mean
it
would
presumably
be
I
mean,
as
of
today.
We
don't
yet
have
this
nbc
structure.
You
know
in
place
just
yet
so
like
there's
no
code
yet
written
to
handle
that
case.
E
The
client
you
know
connects
and
then
has
the
potential
to
look
at
yang
library
to
figure
out
if
it's
compatible,
but
it's
a
different
thing
with
configured
subscriptions
because
then
the
publisher
could
just
start
sent.
It
could
be
updated
to
a
new
revision
and
just
start
sending
potentially
newly
defined
information
to
a
receiver.
That
has
no
a
clue
as
to
you
know
that
information
that's
coming
and
and
how
would
it
handle
that
scenario
I
don't
know
again.
J
F
J
F
K
C
It's
rob
here
actually
just
to
clarify
again
that
all
my
comments
has
been
answered
as
a
contributor
and
the
same
here.
So
actually,
I
think
that
the
kent
was
probably
on
the
money
here
where
he
says.
Actually
solving
this
properly
is
potentially
an
issue
to
be
pushed
off
to
yang.next.
I
think
that
is
the
right
answer,
but
I
also
believe
in
the
interim
and
for
the
moment
that
having
two
as
being
nbc
is
is
the
right
choice
from
where
we
are
today.
C
It
may
not
be
the
right
choice
in
future
and
the
reducing
the
value
space
for
mandatory
again.
I
think
that,
that's
probably
it
seems
reasonable
for
that
to
be
nbc
with
where
we
are
today
and
how
often
mandatory
has
been
used
today,
but
I
do
agree
that
it's
it's
not
easy
to
solve
this
generically
unless
we
change
yang
in
some
way
or
clarify
it.
F
E
Sorry
can
I
just
add
one
more
thing
to
that
discussion.
The
the
business
about
the
client
validating
the
rpc
reply
and
potentially
failing
if
it
doesn't
match,
if
it
doesn't
validate,
could
be
seen
as
a
developer
aid
of
the
server
that
you
know
the
developers
are
actually
using
the
client's
ability
to
validate
their
responses
to
catch
potential
issues
that
you
know
they
didn't.
They
do
mean
to
implement
this
back
to
standard.
E
C
Just
it's
rob
here,
just
one
quick
response
to
kent:
it's
also
probably
worth
checking
the
nmda
spec,
because
that
has
that
certainly
allows
a
server
to
break
those
constraints,
at
least
temporarily,
as
the
data
data's
being
resolved.
So
if
the
clients
are
strictly
validating
it,
then
then
they'll
have
issues.
I
think
so
I
think
it's
fine
to
validate
it
and
flag
up
warnings
or
errors,
or
things
like
that.
I
think
refusing
to
accept
the
data,
because
you've
got
validation,
error.
I
think
that
that
could
be
a
problem
in
the
general
case.
C
I
think
it'd
be
true
for
config
force
as
well,
so
you
might
have
something
where
you've
configured
a
leaf
in
configuration
and
that's
getting
applied
through
the
system
and
then
there's
other
things
being
updated.
On
the
back
of
that
and
an
mda
is
saying
that
you
can't
assume
that
the
view
of
data
you
see
from
operational
is
always
going
to
be
con
self-consistent
across
the
whole
thing.
C
F
D
D
It's
been
mostly
just
discussion
at
this
point,
so
this
issue
is
affectionately
called
github
issue
number
61
on
yang
simvar
version
gaps,
but
it
also
covers
a
a
related
issue
and
that
is
stripping
of
history
or
stripping
of
revisions
from
yang
modules.
So
the
way
the
issue
is
stated
is
in
a
question:
can
there
be
gaps
in
the
semantic
version
history?
D
Initially,
the
the
comments
in
the
github
issue
were
yeah.
Sure,
of
course
you
can
do
that
and
then
the
follow-up
was
well.
If
you
allow
that,
then,
in
the
case
of
import
revision
or
derived-
and
you
had
a
lineage
that
went
like
this
1.01.1
1.3,
what
would
happen
if
someone
imported
your
module
at
1.2
revision
or
derived
since
the
revision
label?
D
E
D
D
K
D
And
then,
as
for,
why
you
might
have
1.2
missing
again,
we
were
asking
the
question:
would
you
allow
for
revision
gaps?
Maybe
I
don't
know
1.2
was
an
internally
released
revision
that
just
never
had
the
light
of
day,
but
internally
you
you
didn't
want
to
confuse
your
tooling,
so
you
released
a
1.3
and
1.3
became
the
publicly
released
module.
E
D
See
how
where
this
goes
so
so
our
stance
was
that
you
would
allow
it
should
you
have
a
need,
like
I
said
from
in
that
perhaps
internal
usage
of
a
revision
label,
and
you
thought
okay,
we're
going
to
have
a
1.2
up.
We
can't
release
that
so
we'll
come
up
with
a
1.3
instead,
so
that
externally,
no
one
ever
sees
a
consumer.
D
D
The
tooling
would
look
to
see.
Oh
can
I
resolve
1.2.
It
would
look
up
the
list
of
revisions
and
if
it
can't
find
it
there,
it
fails
to
import
just
like
importing
from.
If
you
specified
an
incorrect
or
a
date
that
didn't
exist,
a
revision
date
that
didn't
exist.
You
wouldn't
be
able
to
resolve
that
import
either.
J
There's
one
more
important
reason
for
gaps.
If
you
imagine
branching,
you
go
one
dot,
one
one,
two,
two
one
two
three
and
then
you
realize
that
I
need
a
additional
something
on
one,
the
two
or
let's
say
one:
two:
zero
additional
functions,
so
it
must
be
1.5.
Then,
when
I
develop
1.4
in
the
main
branch
further
1.5
is
already
used.
I
have
to
skip
to
1.6
and
then
it
looks
like
that
on
the
main
branch.
That's
1.5
is
a
gap
and
also
failed
projects
are
very
common,
so
yeah.
We
need
that.
E
Okay,
just
a
couple
quick
responses
to
that.
The
first
tablage
blast.
This
point-
I
don't
know
I
mean
so
that
sounds
like
an
internal
merging
issue.
I
don't
know,
but
I
mean
I
perhaps
it
does
happen,
but-
and
maybe
this
leads
into
my
first
comment
also
to
joe's
thing,
which
is
I
mean
it's
all
about
managing
expectations
and
in
in
I
mean
with
revision
dates
of
it
never
never
mattered,
but
we're
introducing
now
version
numbers,
and
I
mean
I
don't
know
of
any
library
that
skips
right.
E
I
mean
if
it
goes,
you
know
if
there's
a
sequential
sequence,
if
there's
a
sequence
of
numbers,
there's
always
every
you
know
value
within
the
sequence
you
know
and
if
a
value
is
missing,
then
immediately
people
say
well.
Where
is
it?
Why
isn't?
Why
isn't
it
present,
like
the
the
expectation?
Is
there
and
so
anything,
that's
against
the
expectation
you
know
is
going
to
flag
confusion
and
whatnot.
So
that's!
This
is
what
I'm
trying
to
avoid.
Well.
D
Okay,
so
I
I
I
take
a
a
kind
of
example
of
of
some
of
the
way.
Gnu
does
does
dev
versions
versus
fcs
versions,
and
if
you
you
take
that
to
an
extreme,
and
you
say
that
every
odd
minor
revision
or
minor
version
is
internal,
only
just
dev
and
we're
going
to
release
on
the
even
versions.
Then
externally,
you
would
have
1.2
1.4
1.6,
and
that
would
to
your
point,
can't
be
expected,
but
it
would
also
be
a
gap
from
a
sequential
numbering
standpoint.
F
I
think
to
have
consistency
in
those
numbers
like
I
wouldn't
I
wouldn't
want
an
internal,
I'm
thinking,
probably
more
on
the
vendor
side.
You
know
if
we
had
some
internal
versions,
I
would
hate
to
have
to
have
a
mapping
that,
because
we're
forced
to
have
our
external
versions
contiguous,
when
we
had
a
bunch
of
internal
versions,
it
would
be
really
painful
to
have
that.
F
So
I
guess
it's
not
so
much
that
we're
going
to
really
recommend
skipping
numbers,
it's
more
that
we
allow
it
and
we
thought
it
would
be
okay,
because
our
algorithm
to
find
if
something
is
allowed
to
be
imported
is
purely
this.
You
can't
assume
that
the
number
four
comes
after
the
number
three
you
just
search
through
the
history
period,
because
you
can
have-
I
mean
we
talk
about
december,
but
we
also
allow
we
could
allow
a
label
revision
label
scheme
as
random
words.
I
got
my
star
wars
revision.
I
got
my
pluto
revision.
F
E
C
I
I
actually
have
a
bit
more
sympathy
for
what
kent's
point
is
here.
Just
a
couple
of
comments
here
is,
I
don't
think
the
vendor
should
ever
be
required
to
publish
all
versions
or
revisions.
I
don't
think
that
makes
sense,
but
it
is
plausible
that
in
the
revision
history,
if
you
went
from
1.1
to
1.2
as
an
internal
version,
then
1.3
is
is
what
you
want
to
publish
you
publish
version
1.3.
C
You
still
keep
an
entry
in
the
revision,
history
of
1.2
and
maybe
update
the
description
just
to
say
an
internal
version.
So
in
terms
of
what's
published,
you
only
publish
1.1
and
1.3,
but
in
terms
of
looking
at
the
history
in
1.3,
you
can
see
that
1.2
existed
somewhere.
It's
just
not
available
to
see
what
the
contents
of
that
file
was.
Yeah.
C
D
Strong
sure
I
I
I
I
would
say
the
same
thing
that
that
jason
said
about
bloat
and
and
also
the
the
our
arbitrariness.
I
mean
we're
treating
these
as
numbers,
but
they
could
be
well
for
some
where
they
are.
They
could
be
something
else,
but
I
I'm
okay
actually
softening
some
of
that
to
to
we,
I
thought
aloud
was
fairly
or
fairly.
You
know
we
weren't
saying
you
should
or
you
you
it's
more.
You
may
have
have
gaps
in
in
this,
and
maybe
there's
something
to
say.
D
Keeping
some
lineage
there
is
is
helpful,
though,
even
with
an
internal
revision.
I
I
don't
know
that
it
is
now
that
I'm
I'm
thinking
about
it
because,
again
with
the
dates,
if
you,
if
you
went
like
a
whole
year
between
a
release,
is
that
really
do
you
really
want
to
talk
about
all
the
development
you
did
between
all
of
those
releases?
If
you're
not
using
semver,
you
probably
don't,
and
you
don't
care
that
people
can't
import
between
january
1st,
2020
and
january
1st
2021.
D
Okay,
joe,
I
think
you
persuaded
me
so
the
the
second
part
of
the
proposal,
because
I
think
one
minute
left
to
kent.
Your
point,
pruning
of
revision
out
of
history-
should
not
be
done.
I
think
we
were
discussing
on
the
last
call
that
there
might
be
issues
where
some
or
might
be
situations
where
some
someone
might
do
that,
so
we
didn't
say
must
not,
but
we
we
went
with
the
second
strongest
should
not
be
done
for
the
reasons
that
list
here.
D
It
would
be
very
difficult
if
you,
if
you
force
people
to
go
back
into
different
instances
of
the
module
to
complete
the
lineage.
You
know,
like
I
suggested
a
linked
list
type
of
following
where
you
just
have
the
one
previous
revision
and
you
have
to
keep
jumping.
So
the
idea
was
simplicity.
You
have
all
of
the
revisions
for
the
lineage
that
you
want
in
a
single
module
and
you
either
resolve
or
you
do
not
resolve
dependencies.