►
From YouTube: NETMOD WG Interim Meeting, 2020-12-14
Description
NETMOD WG Interim Meeting, 2020-12-14
A
Okay,
so
we
are
recording
this,
it
is
we're
a
virtu,
formal
virtual
interim
of
the
netmod
working
group.
A
General
information
is
on
the
screen
in
the
chat
session.
I
hope
everyone
sees
that
there's
a
request
to
join
and
add
your
name
to
the
virtual
blue
sheet.
I
just
sent
it
again,
I'm
not
sure
if
it
shows
up
for
everybody,
but
please
join
the
link
there
and
without
the
colon,
I'm
not
sure.
Let's
try
one
more.
A
As
is
always
the
case
in
the
ietf,
please
meet
yourself
if
you're
not
talking
the,
as
this
case
is
always
the
in
the
ietf,
we
have
our
notewell.
This
governs
our
participation
and
basically
says
anything.
You
say
here
or
on
a
mail
list
becomes
part
of
our
permanent
record.
This
meeting
is
being
recorded
and
will
be
minuted
as
well.
A
We
are
using
that's
interesting.
This
says
meat
echo,
that's
pretty
funny
we're
not
using
meat
echo
we're
using
webex
and
please
use
the
chat
for
the
queue
in
the
past.
We've
asked
to
use
jabber
we're
still
making
that
request,
but
the
reality
is
people
aren't
joining
jabber
right
now,
it's
me
and
a
bot.
A
So
if
you
feel
like
you
want
to
put
something
in
the
chat,
yeah
go
ahead,
but
it
won't
be
part
of
the
minutes
unless
we
talk
about
it
on
the
audio
again
blue
sheets
and
material
thanks
to
the
presenters
who
put
the
material
together.
That
is
all
uploaded
our
agenda.
Why
are
we
here?
A
We
really
want
to
try
to
get
some
feedback
from
those
who
may
have
been
less
active
on
the
versioning
topic
in
the
working
group
and
there's
two
open
discussions
that
the
authors
would
like
to
or
two
open
topics
that
the
authors
would
like
to
talk
about.
I
did
add
a
link,
although
it
didn't
show
here
properly,
it
shows
on
the
in
the
powerpoint
version.
A
Actually,
I
added
the
link
to
the
materials
of
the
slides
from
itf
108,
which
is
gives
a
sort
of
a
a
snapshot
of
where
things
were
at
I'm
sorry,
itf
109,
where
they
were
as
well
as
an
overview
of
all
the
documents.
So,
if
you're
less
familiar
with
the
material,
I
suggest
you,
you
open
up
the
materials
page
and
look
at
that
last
package
as
we're
going
through
it.
A
As
a
reminder,
we
would
like
you
know
we're
going
to
be
working
like
this.
For
a
while.
110
is
already
online.
We
can
do
virtual
interims
whenever
authors
request,
as
as
they
did
in
this
in
this
case,
or
when
we
see
an
issue,
we
also
can
do
informal
meetings.
A
I'll
also
mention
that
the
ietf
gather
is
still
available
for
anybody.
If
you
are
doing
informal
meetings,
I
think
it's
a
good
idea
if
you
include
the
working
group,
a
notification
of
the
working
group
that
you're
doing
that,
because
that
thereby
the
working
group
is
understands,
what's
going
on,
maybe
you'll
have
some
people
who
participate
to
learn.
What's
going
on
or
even
better
you'll
have
new
contributors
to
the
work.
So
please
do
keep
everyone
in
the
loop
as
he
gone.
A
So
with
that
we're
going
to
jump
off
to
the
first
topic
and
I'll
bring
up
the
agenda
just
so
we
have
it
and
we
are
getting
more
trouble.
C
C
My
name
is
jason
stern,
so
I'm
I'm
part
of
a
group
of
of
us
from
the
netmod
working
group
that
are
meeting
in
a
weekly
calls.
So
those
are
those
are
everybody's
invited
from
the
working
group
by
the
way
to
those
you've,
hopefully
seen
some
occasional
invites
and
minutes
on
the
mailing
list,
there's
probably
about
a
set
of
six
to
eight
of
us
who
who
show
up
fairly
regularly,
for
these
calls,
mostly
authors
of
the
drafts
from
a
fairly
wide
variety
of
organizations.
C
So
there's
people
from
a
number
of
different
vendors,
and
so
it's
a
fairly
good
cross-section
of
people,
but
we
have
been
finding
it
challenging
to
converge
on
some
key
issues
around
the
versioning
drafts.
C
Some
of
the
topics
are
a
bit
difficult
and
even
within
the
the
kind
of
the
weekly
meeting
group,
the
author
group
we're
finding
it
challenging
to
to
resolve
a
few
issues
and
would
really
have
been
interested
in
engaging
more
people
in
the
working
group.
C
So
that's
one
of
our
our
challenges
is
to
just
try
to
get
a
bit
more
people
involved,
and
so
this
one
of
the
next
steps
we
we
wanted
to
try
was
a
set
of
virtual
interim
meetings
where
we
really
zoom
in
on
a
few
key
topics
and
try
to
have
a
bit
more
time
to
discuss
those
specific
topics
and
issues.
C
So
we
actually
expect
to
call
further
virtual
interims
over
the
next
little
while
and
today
is
the
first
one.
So
today,
what
we
want
to
focus
on
is
some
of
the
key
issues
around
what
we,
I
guess,
we'd
kind
of
consider,
our
primary
draft,
which
is
the
yang
module,
versioning
draft
and
there's
two
topics
of
particular
interest.
We're
going
to
try
to
tackle
today.
C
So
chad
is
going
to
lead
the
first
one,
which
is
related
to
imports
and
yan
is
going
to
lead
the
second
one
which
is
about
white
space,
and
what
we're
going
to
do
is
allocate
about
30
minutes
to
each
of
those
topics
and
then
at
for
the
last
30
minutes
of
this
meeting,
we'll
come
back
to
whichever
topic
or
or
both
if
needed,
whichever
one,
we
think,
is
the
most
valuable
to
try
to
to
progress.
C
D
It
and
I'll
it
seems
your
mic
is
the
one
that's
noisy.
Is
there
any
way
you
can
clean
that
up.
E
Oh
give.
A
E
I'm
sorry,
I
missed
turn
off
what.
A
Use
your
mic
as
quick
to
talk
only
on
mute
when
you're
gonna
talk,
please.
Okay,.
E
Yeah
just
one
second,
I'm
going
to
try
to
go
back
to
my
headset,
okay.
C
Yeah
so
I
was,
I
was
just
wrapping
up
so
rashad's
gonna
rashad's,
leading
in
for
the
first
topic
here
and
and
then
we'll
so
we'll
stick
with
that
for
about
half
an
hour.
A
A
E
Please,
okay,
so
yeah!
Officially,
I'm
richard
ramen,
I'm
part
of
the
group
of
authors
and
contributors
and
today
I'm
going
to
be
leading
the
discussion
on
two
issues
related
to
versioning
and
imports.
As
jason
said
previously,
those
are
things
we've
been
talking
about
for
at
least
a
couple
of
years,
and
we've
had
a.
E
Consensus,
maybe
on
the
second
one
the
group
now
has
consensus,
but
in
the
first
one
we've
been
going
back
and
forth.
So
the
first
issue
is
the
impact
of
doing
non
backwards,
compatible
changes
on
imports
and
specifically
whether
we
need
a
new
extension
statement
for
imports,
which
is
revision
or
derived
compatible
here
and
then
there's
the
link
to
the
github
issue.
E
E
If
we
consider
module
8
1.0,
which
is
importing
module
b
at
2.0,
let's
assume
that
there's
only
major
version
one
and
two
for
b
no
three.
This
means
that
alia
will
be
importing
some
two
dot
wide
of
z
of
module
b.
We
don't
know
which
one
at
least
a
version
which
contains
2.0.0.
E
Now
on
the
third
bulletin,
we're
basically
saying
now,
you
know
consider
if
there's
a
new
version
of
module
b3.0.0
that
we
did
nbc
changes
with
that
statement,
revision
or
derived
module
a
may
end
up
importing
3.0,
because
it
includes
its
drive
from
2.0
and
that
could
break
clients
using
module
a
on
the
other
hand.
You
know
it's
also
possible
that
it
does
not
want
the
changes
in
in
module
b,
I
made
in
version
3.0
of
module
b.
It's
also
possible
that
module
a
watts,
those
changes.
E
So
we've
been
going
back
and
forth
on
this
one
and
we
so
the
point.
What
we're
basically
coming
down
to
is.
Do
we
want
another
extension
which
is
revision
or
derived
compatible?
The
keyword
there
being
compatible
to
limit
the
import
set
to
backwards
compatibles
versions,
so,
for
example,
2.00
derive
compatible,
would
limit
the
imported
version
to
two
dot,
something
three
dot:
three
four
versions:
three
and
four
major
version
would
not
be
candidates.
E
So
that's
the
essence
of
what
we've
been
discussing
and
you
know
many
of
the
contributors
can
attest
to
this.
We've
been
going
back
and
forth.
You
know
one
week.
We
think
yes,
one
thing
we
think.
No,
and
actually
I
find
that
personally
jurgens
reply
to
the
mailing
list
over
the
weekend
was
pretty
accurate
in
terms
of
what
that's
the
main
reason.
Why
we're
having
a
hard
time
closing
on
this,
because
we
don't
know
what
we
want
next
slide.
E
E
Just
a
quick
reminder
and
import
the
first
one
is
the
regular
import
by
date.
That's
in
rfc
7950.
E
The
second
one
is
the
revolution
or
derived
that
we've
been
talking
about:
that's
in
module
versioning,
so
we're
basically
saying
we
want
2.0.0
or
anything
derived
from
version.
3
version,
4,
major
versions,
three
and
four.
What
we're
considering
and
discussing
is
whether
we
want
revision
or
derived
compatible,
which
would
limit
it
to
only
versions
for
shock
compatible
with
2.0.0.
E
So
we're
going
to
go
through
two
quick
examples
about
you
know
why?
Maybe
we
won't
want
that
new
extension
and
why
maybe
we
would
not
the
first
examples
actually
from
rob
which
we've
discussed
in
our
meetings
is
the
case.
I
mean
we're
all
looking
at
hypothetical
examples.
You
know
if
we
want
to
obsolete
if
index
from
itf
interfaces
and
iaf
interfaces
would
be
the
module
which
is
being
imported.
E
All
the
important
modules
which
are
using
that
statement
would
be
getting
the
new
version,
because
3.0.0
is
derived
from
2.0.0
with
compatible.
You
would
not
get
it
because
you'd
be
limiting
to
to
you,
know:
bc2
version
2
up
and
all
the
important
modules
would
need
to
be
modified
to
be
able
to
import
3.0
and
that's
a
bit
like
the
same
problem.
We
have
by
revision
importing
by
date.
E
E
E
Now
you
know
it's
possible
that
some
either
specific
platform,
so
implementations
or
servers
might
want
to
keep
vpn
id
as
an
integer
while
others
might
want
it
as
a
string.
If
you
use
the
derived
extension
you
everybody
would
get
the
new
definition
of
that
grouping
of
that
node
in
that
grouping.
E
Maybe
that's
good,
maybe
that's
not
good.
With
the
compatible
flavor
of
that
extension,
you
would
keep
the
old
definition.
E
E
And
then
next
slide.
The
next
slide
is
the
final
slide
on
this
topic,
which
is
a
summary
so
again.
You
know
why
we
would
want
the
compatible
the
pros
we've
we've
spoken
about.
You
know,
there's
no,
accidental
breakage,
you
know
exactly
what
merger
version
you
are
are
are
getting.
E
You
know
you
can
use
it
for
reactive,
okay,
repair,
that's
something!
You
know
we've
been
discussing
recently
where
you
know
if
you
use
the
other
the
wide
open
one,
and
you
realize
that
it's
breaking
your
module,
you
can
revert
to
the
compatible
extension
to
so
that
your
module
would
work
the
cons.
Well,
there's
also,
you
know,
we've
been
discussing
well,
it's
very
similar
to
import
by
date.
E
If
you
want
something
which
is
not
covered
by
your
major
version,
you
need
to
go
to
all
the
importing
modules
and
change
them.
There's
none
backwards,
compatible
fixes
which
you
may
want,
and
you
don't
get
automatically
it
could
be
confusing
to
you
I
mean
we've
always
already
had
the
feedback
from
a
few
people,
that
the
whole
solution
is
a
bit
confusing
and
complex
and
having
two
different
extensions
to
do
similar
stuff
might
be
confusing
to
authors
of
yang
modules.
C
C
There's
a
question
as
to
whether
we
have
any
import
by
revision
statement
at
all
in
the
yang
modules
themselves
and
whether
we
rely
on
techniques
that
are
outside
the
module
to
indicate
dependencies
between
modules,
and
you
know,
there's
several
examples
of
of
how
that
works,
the
one
of
the
ones
I
I
only
looked
at
one
of
the
links
that
jurgen
sent,
but
at
least
the
first
one
for
cargo.
C
It
does.
You
know
out
of
band
or
a
separate
indication
of
of
dependencies,
but
I
did
notice
it
seems
to
have
the
concept
of
revision
or
derived
compatible.
So
when
it
it
mentions
you
can
import.
When
you
can
like
combine
certain
versions
of
things,
it
seems
to
have
the
logic
that
you
can.
C
You
can
include
anything
as
long
as
the
major
semver
digit
does
not
change
so
so
that
one's
a
kind
of
a
out
of
the
module,
a
solution
that
has
semantics
similar
to
the
derived
or
compatible.
C
C
I
think
was
a
a
little
bit
to
a
degree,
the
opposite.
He
seems
to
be
advocating
in
his
email
to
to
at
least
fix
the
problem
we
have
in
yang,
where
you
can
only
specify
a
specific
version,
and
he
was
he
was
kind
of
asking.
You
know
please
just
solve
that
problem
and
seem
to
be
indicating
that
he
wanted
a
a
version
or
derived
concept,
but
not
not
the
or
compatible
one.
C
Now-
and
you
know,
I
think,
I'd
you're
gonna
join
the
call,
so
he
might
be
able
to
clarify
some
of
his
thoughts,
but
I
don't
think
andy's
on
so
I
I
think,
there's
you
know,
even
in
those
two
emails
are
seeing
a
little
bit
of
of
the
conflict,
we're
also
getting
in
the
in
the
group
about
how
to
how
to
resolve
this.
F
A
C
It's
just
okay.
I
I
just
to
address
italo's
point
I
I
hopefully
I'm
interpreting
correctly,
but
I
think
italo
was
was
saying
that
he's
leaning
towards
having
the
derived
or
compatible
because
of
the
concern
that
a
could
inadvertently
be
including
a
non-backwards
compatible
version
of
b.
The
problem
is
that
just
because
b,
changed
in
a
non-compatible
way
doesn't
mean
it
necessarily
affects
module
a
so
the
feeling
from
at
least
some
of
the
authors.
C
Some
of
the
group
from
the
call
or
weekly
call
is
that
most
of
the
time,
especially
in
standards
modules,
a
change
to
b,
even
if
it's
non-backwards
compatible,
is,
is
actually
not
likely
to
impact
a
it
may,
but
often
there's
going
to
be
changes
to
b
that
maybe
aren't
even
used
by
a
or
in
standards
bodies.
You
know
b
might
be
changed
in
an
nbc
manner,
but
they're
they'd
be
conscious
about
trying
not
to
break
things
for
a
so
it's
not
guaranteed.
C
But
our
worry
was
that
we
would
be
a
little
bit
too
pessimistic
if
we
always
enforce
people
to
use
the
derived
or
compatible
inclusion
and
it
may
it
may
mean
that
someone
spins
b
in
a
way
that
is
non-backwards
compatible,
but
it
doesn't
affect
a,
but
if,
if
they
had
used
derived
or
compatible
in
a
that
would
force
a
to
go,
have
to
go
back
and
re-spin
to
include
the
new
version
of
b,
so
we're
we're
feeling
that
it
may,
if
derived
or
compatible,
is
used.
F
Okay,
okay,
thank
you.
Okay,
yeah.
I
understand
the
drawback,
but
my
concern
is
that
the
risk
is
much
higher,
because
the
big
problem
is
that
you
don't
know
you
don't
know
whether
the
model,
the
change,
the
number
of
compatible
changes,
module
b,
is
going
to
affect
module
a
especially
you.
Don't
know
that
when
you
write
a
module
a
because
you
don't
know
what
what
will
happen
in
the
future
when
you
do
module
b
and
and
then
you
can
really
assess
at
every
time.
F
F
The
even
the
things
become
even
worse
when
you
you
go
and-
and
you
have
this
problem
coming
up
over
multiple
imports,
so
think
about
the
case
that
you're
changing
module
b
is
affecting
module
c,
which
is
importing
module
a
which
is
important
module
b.
That's
so
you
can
have
a
module
which
is
number
echo
compatible
because
a
a
a
module
which
is
imported,
many
steps
behind
you
is
non-background
compatible.
G
So
it's
rob
wilton
here
as
a
contributor,
so
I
think
that
the
the
the
concern
I
tell
you
is
that
actually,
if
you
have
that
sort
of
fixed
dependency
with
that
range
dependency,
you
end
up
with
everything
being
too
much
in
lockstep.
G
So
you
start
finding
the
case
that
in
the
like
the
itf
interfaces
example,
when
you
deprecate
a
node
that
nobody's
using,
you
would
then
have
to
if
everyone
was
using
revision
or
derived
compatible.
You'd
have
to
update,
like
50
yang
models,
to
be
able
to
use
that
new
mod
version
of
itf
interfaces
without
deprecated
or
obsoleted
node.
G
So
I
think
actually
it's
too
constraining
and
I
think
the
answer
is
by
and
large
what
jurgen
is
saying
is
that
that
really
compatibility
between
yang
models
is
something
that
should
be
done
by
and
large,
outside
the
model
definitions
themselves
in
and
solved
in
a
separate
way
packages
might
be
some
that
could
be
extended
to
that.
I
haven't.
I
haven't
thought
about
that,
but
that
might
be
some
some
other
way.
I
do
also
have
simply,
though,
for
andy's
comments
where
it's
useful
to
say
when
I
write
this
young
module.
G
I've
got
a
minimum
dependency
on
this
other
yang
module
because
it
defines
a
particular
type
or
identity
or
a
path
that
I'm
using
augmenting.
So
I
still
think
that
the
revision
or
derived
version
of
import
is
is
helpful
on
a
pragmatic
basis
when
people
are
looking
at
yang
models
and
trying
to
build
them
together
into
cohesive
sets.
So
my
proposal
here
is
to
keep
the
revision
all
derived,
but
don't
do
the
revision
or
derived
compatible,
but
with
the
aim
that
the
revision
derived
its
only
purpose
is
effectively
specifying
a
minimum
dependency.
A
Lou
is
contributor,
I
think
it's
worthwhile.
To
think
of
you
know
what
problem
we're
trying
to
solve
here
and
rob.
I
I
think
you
actually
gave
the
answers
for
for
this
point.
One
is
as
we're
designing
modules
being
able
to
specify
things.
A
Well,
I
guess
this
is
from
andy,
but
specify
some
minimum
dependencies
or
minimum
requirements
and
keeping
in
mind
when
we're
doing
things
that
are
really
backward
compatible
and
where
they're
not
and
then
the
second
one
is
as
we're
implementing
what
combination
makes
sense
and
perhaps
yang
packages
is
an
answer,
but
I
I
think
we're
really
talking
about
two
separate
problems
and
I
think
it's
worthwhile
to
keep
those
separate.
Keep
that
in
mind
when
talking
about.
G
A
Yeah,
I
think
you
and
I
are
in
violent
agreement
here-
jason
since
you're
sort
of
managing
this
section.
Do
you
want
to
try
to
get
more
feedback
on
this
topic,
or
do
you
want
to
move
on.
C
This
it
feels
like
maybe
a
good
time
to
move
to
the
other
topic,
but
maybe
we'll
touch
base
with
the
group
at
the
end,
if
there's
time
to
come
back
to
this
in
case
you
know,
people's
brains
are
churning
and
want
to
revisit
this,
so
let
I'd
propose
we
switch
over
to
tion's
white
space
discussion
and
and
then
we'll
revisit.
If
we
have
time
to
come
back
to
this,
we.
C
Oh,
I
apologize
you're
right.
Sorry,
there
was
part
two
sorry.
A
I
I
oh
okay,
I
thought
rob
was
in
cube,
but
he
just
removed
himself.
Okay,.
E
Thank
you
so
that
issue
has
also
been
fairly
contentious
in
the
past.
It's
basically,
the
impact
of
you've
got
the
importing
module,
which
says
I
want
2.0.0
or
derived,
and
then
we
change
that
statement
to
be
3.00
or
derived,
and
you
know
going
back
to
what
italo
rob
and
jurgen
said
earlier:
an
email.
E
E
So
the
you
know
the
contributors
who
meet
every
week.
We
believe
that
such
a
change
in
import
statements
should
be
considered
to
be
backwards,
compatible
change
that
that
revision
label
of
the
module
really
represents
a
schema
defined
in
that
module
and
that
we
have
to
use
other
means,
whether
it's
young
packages
or
yang
library
for
clients
to
have
the
full
scheme
of
you.
E
You
know
just
just
you
know
guessing
in
some
way
that
the
impact
of
that
statement
is
bc
or
nbc
on
a
is
is
is
not
is,
is
not
correct.
You
know
it
may
be,
the
change
is
in
the
grouping
which
is
not
used
by
a
or
it
could
be
in
a
grouping
which
is
used
by
a
we
just,
don't
know.
E
E
We
also
considered
you
know,
depending
on
on
on
on
the
impact
you
know
to
decide
whether
it's
vc
or
bc
change
one.
We
believe
it
could
be
error
prone.
You
know
it's
hard
for
a
tool
to
go
and
figure
that
out.
There's
potential
ripple
effect
where
you
know,
if
you
got
a
you
know
a
hierarchy
of
modules,
including
others
that
this
could
ripple
up
to
the
top,
so
it
could
be
many
changes.
I
mean
changes
have
to
be
done
in
many
modules
and
last
you
know.
E
E
A
So
again,
if
you're,
the
only
one
in
queue
feel
free
to
jump
in
so
rob.
G
So
again,
with
no
hats,
I
was
just
going
to
say:
if
there's
no
comments
on
this,
the
the
other
question
to
what
to
work
that's
worth
asking
is:
is
anyone
opposed
to
the
change
that
we're
proposing
or
the
the
solution
we'll
propose
on
the
previous
slide,
I.e
that
if
you
change
the
import
is
regarded
as
a
backwards
compatible
change,
so
is
anyone
opposed
to
that
resolution?.
G
C
C
H
So
this
is
jurgen.
I'm
wondering
whether
this
this
needs
to
be
a
hard
rule,
because
there
could
be
corner
cases
where
you
really
think
that
the
data
type
that
I'm
using
changed
in
such
a
way
that
the
semantics
actually
change
in
the
module.
So
it
it
might
default
to
be
a
backwards,
compatible
change.
But
it
might
be
cases
where
it's
not
a
backwards,
compatible
change.
C
So
that's
an
interesting
question
as
to
whether
module
a
is
allowed
to
then
bump
his
version.
So
I
two
two
thoughts
on
that.
One
is
in
general
in
our
specifications.
So
far,
we've
generally
leaned
towards
saying
that
you
know
when
there
is
definitely
a
change.
You
must
bump
the
revision,
but
we
are.
We
are
not
preventing
someone
from
bump
from
false
positives.
We
absolutely
want
to
prevent
false
negatives,
but
we
allow
false
positives.
In
other
words,
even
if
you
aren't
certain
etc,
you're
allowed
to
bump
a
version.
C
So
so
you
know,
strictly
speaking,
you're
going
module.
A
is
perfectly
allowed
to
bump
the
version
if
they
wish,
even
if
something
directly
in
module
a
didn't
change,
so
we're
not
preventing
that
as
to
whether
we'd
recommend
that
our
feeling
is
that
you
know
when,
when
you're
looking
at
a
schema
that
a
server
supports
and
and
whether
a
client
can
talk
to
that
server
and
use
that
schema,
it
has
to
consider
the
whole
set
of
modules
that
make
up
that
schema.
C
So
if
a
includes
b,
you
know
the
the
server
and
the
client
both
have
to
look
at
a
and
b
and
any
other
modules
in
that
set,
and
they
have
to
look
at
whether
there's
been
an
nbc
change
in
any
of
them,
and
then
they
have
to
go.
Look
at
those
nbc
changes
to
say
well.
Does
this
affect
my
implementation?
Does?
Is
this
a
part
of
the
model
that
I
use?
F
With
what
was
said
before
so,
if
the
importable
revision
is
always
used
to
say
what
is
the
minimum
version,
you
need
to
import
us
nothing
to
say
about
whether
your
revision
is
beco
compatible
or
not
with
the
previous
one.
By
we
mean
we
alone,
number
compatible,
okay,
changes
by
import,
and
then
you
we
move
to
the
to
the
user,
to
figure
that
out.
That's
consistent
with
what
you
said.
C
F
C
Yeah
I
mean
ultimately
when
they
see
an
nbc
change,
they
have
to
go
look
at
what
change
and
where
and
how
it
affects
their
implementation.
You
know
whether
it's
included
by
a
or
not
they
have
to
look
at
the
specific
change
in
the
end
and
figure
out
whether
it
impacts
them,
but
it
will
be
indicated.
It'll
just
be
only
indicated
in
b,
not
kind
of
by
proxy
in
in
a's.
I
All
right
so
yeah
just
trying
to
see-
if
I
understand
correctly
here
as
a
modulator,
I
see
that
it's
still
difficult
to
predict
the
impact
by
this
impulse
by
revision
right.
So
we
don't
know
how
the
model
b
changes
will
impact
a
and
c
so
in
normal
cases,
in
most
cases,
when
I
write
a
module,
I
assume
I
still
use
the
import
with
no
revision.
E
I
think
what
we're
saying
is
that
we,
you
change
the
version
of
the
of
the
module
where
you
made
the
changes
you
I
mean
by
default.
I
mean
I'm
not
sure
whether
we're
going
to
probably
be
changing
import
version
of
importing
modules,
but
we're
saying
definitely
by
default.
E
I
E
E
A
E
Sorry
I
forgot
to
take
myself
out
of
the
queue
I
already
said.
What
I
had
to
say.
I
guess
next
is
joe.
D
Thanks,
I
first
what's
on
the
slide,
I
agree
with
I
I
wanted
to
go
back
to
what
jurgen
was
saying,
though,
because
something
jason
you
said,
which
was,
if
a
is
importing
b
and,
let's
say,
b
a
updated,
it's
its
import
to
say
now
we're
going
3.0
and
yeah.
You
would
see
that
that
the
module
b
does
have
an
nbc
marker
in
there.
I
I
like
what
jurgen
was
saying
and
certainly
in
december
draft.
We
do
have
language
that
says
you
can.
D
If
you
have
a
reason
to
you,
can
bump
the
major
version
number
indicating
an
nbc
change
for
whatever
reason.
Obviously,
you
should
use
that
with
caution,
but
on
that
data
type
thing,
I
I
think
if,
if
you
know
in
module
a
that
when
you,
when
you
change
your
import
statement
to
say
I
want
this
new
major
revision
of
module
b
and
nbc,
and
you
understand
the
impact
that's
going
to
have.
D
I
think
flagging
that
for
your
users
of
the
consumers,
directly
of
module
a
is
useful,
and
so
I
I
I
agree
with
not
making
this
hard
and
fast.
I
think
this
is
good
guidance
that
it's
in
it's
a
bc,
change
to
change
the
import,
but
having
a
a
way
to
do
that
when
you
know
that
there's
going
to
be
a
usability
impact
is
a
valuable
thing.
G
So
is
rob
here
again
as
a
contributor,
I
actually
almost
think
so-
I'm
not
quite
sure
jurgens
one,
but
I
think
that
in
terms
of
some
of
the
worst
discussions
going
to
is
rather
than
the
import
being
thought
of
as
a
way
of
checking
compatibility
really
the
only
time
you
should
probably
bump
the
import
minimum
version
number
is
if
you've
got
some
dependency
in
that
new
module.
So
if
a
new
type's
been
added
in
then
you
might
want
to
bump
it,
but
otherwise,
arguably
you
shouldn't
need
to
do
that.
G
So,
given
that
basis,
I
wonder
whether
then
it
should
ever
be
a
nbc
change.
I
wonder
whether
tying
the
two
together
is
a
mistake
and
actually
the
the
text
about
when
you
bump
this.
The
version
number
is
when
you
have
a
new
dependency
and
hence
it
isn't
really
tied
to
what
the
version
number
is
it's
tied
to
some
dependency.
You
have.
D
I
think
I'm
I'm
the
only
one
in
queue.
Let's
say
it's
not
a
new,
a
new
type.
It's
it's!
A
truly
nbc
change
to
an
existing
type
that
you
happen
to
be
using
in
a
and
you
understand
the
impact
of
moving
to
say
what
what
what
3.0
did
in
b
and
you
want
to.
You
want
to
further
clarify
or
illustrate,
or
whatever
word
you
want
to
use
to,
to
the
consumers
of
your
module,
a
that's
at
least
what
I
had
in
my
head.
D
Maybe
a
type
got
after
analysis
got
further
refined
or
you
know
shrunk
in
in
scope
or
something,
and
that
you
want
to
bubble
up
it.
It
would
make
sense,
I
think,
to
bump
the.
G
G
That's
a
metadata
information,
because
the
the
module,
if
you
haven't
changed
a
then
it
was
still
compatible
with
the
older
version
of
b
anyway,
that
hasn't
really
changed,
you're
just
saying
now,
as
a
user,
when
people
are
using
a,
I
think
that
they
should
really
be
using
this
later
version
of
a
later
version
of
b,
and
we
know
that
they
work
together.
G
Purposes
and
to
be
clear,
I'm
not
I'm
not
totally
opposed
to
what
jurgen's
suggestion
is.
I
just
wonder
whether
having
that
room,
at
least
to
start
with
means,
it's
more
likely.
D
Regardless
I
joe
clark
again,
I
I
think
that's
what
I
was
saying
that
that
we
have
text
that
says
you
could,
but
in
general
this
is
the
thing
that
you
would.
That
would
be
recommended,
though
I
guess
you
would
have
to
change
the
word
always
if
you
would
allow
for
something
else,
but
I
also
understand
what
you're
saying
about
packages
too
and
how
that
kind
of
separates
the
two
issues.
A
C
Yeah,
I
guess
I'm
I'm
echoing
the
same
sentiment
that
we
can
say
aloud.
I
I
would
go
a
bit
stronger
and
say
it's
not
suggested,
and
I
think
we
probably
should
actually
in
the
draft,
explain
that
separation
of
purpose
that
we
could
say,
look
it's
allowed.
If
you
really
feel
that
you
know
this,
we
can
say
it's
not
prevented,
but
it's
not
recommended
the
recommended
solution.
For
you
know
describing
dependencies
is
packages.
A
That
would
be
must,
if
you
really
thought
it
was
sounds
like
we've
actually
reached
closure
on
this
point.
That's
right.
C
A
Yeah
on
this
part,
I
think
I
heard
some
closure,
which
is
it's
a
good
with
an
explanation
or
you
know,
recommended
or
re
not
recommended
with
explanation.
I
always
like
the
positive
versus
the
negative,
but
that's
a
personal
comment.
C
All
right
yeah,
so
we
can
bring
that
back
to
the
list
to
just
kind
of
ratify
and
see
if
there's
further
for
the.
J
J
So
that's
the
purpose
with
this
yang
semantic
versioning
to
add
classification
of
changes
into
three
different
classes.
First,
we
have
the
non-backers
compatible
changes
where
you
step
the
first
digit.
We
have
backwards,
compatible
changes.
We
just
take
step
the
second
digit,
and
then
we
have
editorial
changes
that
has
no
functional
difference
where
you
step
the
third
digit,
so
you
would
have
something
like
2.2.1
next
slide,
please.
J
So
what
came
up
here
when
it
comes
to
white
space?
Is
that
some
people
said
that
well
there's
something
called
insignificant
in
significant
white
space,
which
actually
is
a
fourth
category,
where
you
would
not
detect
changes
to
insignificant
white
space
in
your
version
at
all
it
it
sort
of
would
would
have
it's
been
stepping
the
fourth
digit,
but
we
don't
have
a
fourth
digit,
so
we
don't
step
anything
or
do
we
treat
well.
J
So
that's
that's
really
the
question
that
we
have
to
answer
and
if
we
decide
that
well,
there
should
be
some
sort
of
changes
to
yang
files
that
should
not
be
detected
by
the
version
step.
Well
then,
exactly
what
is
in
significant
white
space,
I
think
most
people
agree
that
it
would
only
be
outside
yang
literal.
So
if
it's
inside
quotes,
it
would
always
be
a
change,
even
if
it's
just
changing
a
double
space
to
single
space.
But
I
suppose
that's
up
to
this
debate
as
well.
J
If
you
change
the
indentation,
is
that
why
insignificant
white
space
change
or
not,
if
you
add
or
remove
blank
lines,
is
that
insignificant
white
space?
What
if
you
use
other
kind
of
space
characters,
I
mean
we
have
tabs?
Obviously,
but
there
are
also
other
utf-8
space
characters
like
vertical
tabs,
and
you
know
all
sorts
of
stuff
should
we
use
utf-8
attributes
for
white
space
to
detect
this,
and
so
so
and
then,
of
course,
comments
are
also
have
no
particular.
J
J
J
If
you
want
to
compute
checksums,
obviously
any
change
at
all
to
a
young
module
would
matter
quite
a
bit
because
the
standard
tools
that
you
have
out
there
they
would
be
counting
every
byte
in
the
file,
but
you
could
also
define
a
sort
of
cleaning
operation
where
you
normalize
all
the
white
space
in
yang
files.
You
specify
what
the
line
endings
should
be
like,
or
maybe
you
treat
them
as
a
single
space.
J
All
double
space
is
replaced
by
single
space,
all
other
kind
of
white
space
characters
like
tabs
or
whatever
are
replaced
by
spaces,
and
then
you
take
that
normalized
yang
representation
and
completely
check
some
over
that
or
we
decided
well
this
whole
business.
We
check
something
is
actually
not
important
and
then
we
don't
need
to
say
anything
about
how
you
compute
checksums
or
whether
whitespace
change
is
a
different
version
or
not.
We
can
just
leave
that
aside.
J
J
So
if
you
treat
jain
files
as
sort
of
binary
files,
then
you
can
use
all
the
existing,
let's
say:
md5
or
sha
256,
or
something
tools
that
exist
on
the
market
and
just
apply
that-
and
this
agrees
pretty
pretty
well
with
the
intuitive
feel
that
people
have
for
for
how
versioning
and
checksums
work-
and
you
can
even
use
these
things
like
okay,
you
see
file
size
being
different
between
two
young
models.
Then
you
know
they
are
different
versions.
J
When
you
have
this
sort
of
binary
approach-
and
it's
also
easy
to
identify
the
latest
version
of
a
module,
even
if
there's
only
white
space
changes
because
there's
the
the
version
number
signifies-
which
one
is
the
newer
one,
so
that
if
somebody
did
fix
up
the
white
space
to
align
the
indentation
or
whatever
it
was
or
remove
some
double
spaces
or
clean
up
the
line,
endings,
whoever
is
going
to
make
the
next
version
of
that
can
see.
Oh
here's,
the
one
I
should
be
working
off
of
otherwise
there's
a
risk.
J
We
can
go
to
the
next
slide
if
you
have
this
white
space,
normalized,
younger
presentation
and
and
work
with
that,
you
would
be
treating
the
modules
as
text
files.
Basically,
and
then
we
need
to
specify
in
extreme
detail
how
this
white
space
normalization
procedure
should
work,
and
I
think
most
people
will
feel
that
is
relatively
easy
until
they
start
actually
doing
that.
J
J
J
This
is
the
last
slide
and
we
could
also
say
that
we
don't
want
checksums,
because
this
is
too
complicated
and
then
we
can
actually
duck
down
and
not
talk
about
white
space
changes
at
all.
Just
ignore
that
it's
not
going
to
matter
much
anyway.
If
you
don't
have
jigsaws
and
we
would
have
to
drop
the
checksum
id
from
the
jank
packages
draft
in
that
case.
But
it
means
quite
a
bit
less
of
work,
and
this
is
a
way
out
if
we
think
this
is
getting
out
of
hand
and
with
that
I'll.
J
Let
the
moderators
moderate
queue.
C
Okay,
okay,
jason
stern
yeah,
so
your
last
slide
just
made
me
realize
that
checksums
is
one
use
case.
Well,
as
one
factor
that's
making
us
wonder
about
this,
the
other.
Even
if
we
didn't
have
checksums,
though
I
guess
one
question
is
you
know
if
we,
if
we
don't
track
the
difference
between
two
versions
of
a
module?
So
so,
let's
say
let's
say
we
have
our
module
a
and
at
version
one
zero,
zero
and
then
the
authors
or
whoever
decides
to
do
some
formatting
cleanup
where
they
fix
up
some
description
alignments.
C
C
If,
if
we
don't
track
that
with
the
minor
digit,
then
we
would
have
floating
out
there
in
the
yang
space
version,
one
zero,
zero,
non-cleaned
up
and
version
one
zero,
zero
cleaned
up
and
there'd
be
no
way
to
specifically
identify
or
formally
request
or
name
the
cleaned
up
one.
So
what
I
mean?
What
if
someone
says?
Well?
No,
no,
I
wanna!
I
wanna
give
me
the
cleaned
up
one
please.
I
wanna
edit
that,
like
there's
no
separate
name
for
that
or
identifier,
so
I
mean
even
even
outside,
of
where
they're
doing
checksums.
G
So
I've
added
myself
in
the
queue,
hopefully
again
as
a
contributor
that
others
will
comment
on
this.
I
think
the
key
question
here
to
me
is
is
what
does
the
semantic
version
number
apply
to
is?
Does
it
apply
to
the
file,
or
does
it
apply
to
the
statements
within
the
file
and
the
reason?
I
think
that
matters
is
in
terms
of
tooling
that
if
you
run
a
tool
that
pulls
in
that
yang
module
and
it's
going
to
then
process
it
should
it
care
if
the
white
space
is
different
between
those
two
files.
G
I
think
that
is
something
that
has
it
as
it
has
an
implication
on
the
result,
depending
on
what
the
solution
is,
but
I
think
it
needs
to
be
resolved
regardless
and
one
other
aspect
that's
also
interesting
here
is
the
issue
that
came
up
about
is,
if
you
generate
the
yang
programmatically
from
another
source
of
data,
for
example
like
from
yin
or
maybe
you
they
get
converted
from
some
other
schema
format.
G
Then
the
question
again
is
that
if
the
white
space
is
significant,
that
may
make
it
harder,
then,
if
it
becomes
generalized,
then
you
can
have
two
tools
producing
the
same
structural
yang
with
different
white
space
formatting
and
they
still
have
the
same
semantic
version
number.
C
I'll
respond
to
part
of
that,
I
guess
one
thought
is
so
we
do
have
I
mean
so
the
trick
is
the
module
versioning
draft.
Doesn't
you
know,
as
independent
of
which
label
scheme
we're
going
to
use?
But
if
we
look
at
something
like
sember
that
our
authors
group
is
proposing
a
yang's
ember,
we
do
have
the
three
digits
and
the
first
two
digits
are
kind
of
reserved
for
the
stuff
that
matters
as
far
as
the
api
goes
and
the
third
digit
is
defined
by
definition
as
things
that
don't
affect
the
api.
C
So
you
know
at
least
for
that
revision
scheme.
We
do
have
the
ability
to
be
very
clear
about
which
which
parts
of
the
semver
are
api
affecting
which
aren't.
The
problem
is
our
generalized
yang
versioning
draft,
which
is
supposed
to
work
with
any
scheme,
doesn't
necessarily
so
like
revision
date
doesn't
have
that
level
of
of
semantic
understanding.
G
But
even
in
that
case
you
still
have
examples
where
that
third
digit
is
useful.
For
example,
if
you
were
to
fix
a
typo
or
a
spelling
mistake
in
a
description
or
or
a
modifier
reference,
for
example,
then
I'd
regard
those
as
being
changes
that
don't
don't
actually
affect
the
api.
G
So
they're,
not
minor
version
changes.
They
just
become
editorial
version
changes
so
use,
there's
still
a
use
for
that
digit.
Even
if
it's
not
for
white
space
changes.
A
A
I'm
in
the
queue
as
a
contributor
that
makes
sense
to
me
using
that
third
digit.
G
A
Comment,
I
think,
having
the
ability
to
distinguish
a
specific
version
and
refer
to
it
whether
the
is
useful.
Even
if
it's
the
only
consumer,
is
just
people,
and
so
I
you
know
for
the
first
two
digits.
Certainly
if
the
yang
is
the
same,
maybe
you
don't
want
to
change
that,
but
for
the
the
document
management
purposes,
using
that
third
digit
to
cover
white
space
or
non-visible
to
yang
changes,
seems
like
a
reasonable,
reasonable
thing.
A
A
G
So
the
only
the
only
the
problem
that
came
up-
I
think
I
have
most
sympathy
with-
is
the
one
regate
related
to
generating
yang
from
from
other
sources
other
inputs.
So
if
it's
generated
from
yin
for
example,
and
then
the
concern
I
think
was
that
if
you
go
from
yang,
generate
a
yin
and
then
come
back
to
yang,
I'm
not
sure,
that's
a
plausible
example,
but
if
you
take
in
and
then
generate
yang,
then
the
fact
that
the
revision
is
tied
or
the
verb
or
version
or
revision
is
tied
to
the
white
space.
G
Isn't
necessarily
that
helpful.
So
that's
a
particular
case,
and
it
does
have
the
benefit,
though,
if
you
tie
it
to
the
white
space
of
the
file,
it
makes
the
checksum
very
easy.
It
gives
a
very
well
defined,
meaning
that
the
checksum
is
just
a
standard
checksum
of
the
contents
of
the
file,
so
that
that's
the
big
benefit
of
it.
G
A
D
K
Do
you
hear
me
now?
Yes,
so
one
problem
we
constantly
have
we
had
with
these
wine
spaces
that
people
took
of
the
yank
file
copied
it
over
to
their
own
disk,
changed
changed.
Let's
say
blind
and
line
ending
from
windows
to
linux,
or
vice
versa.
K
C
Jason,
so
so
I
guess
about
balash's
comment,
so
blast.
I
guess
you
know
if
we,
if
you
have
two
version,
if
you
have
version
one
zero,
zero
floating
around
and
and
somebody
puts
it
into
unix
or
and
someone
else
takes
it
into
dos
and
then
they
pass
the
file
around
they're
gonna
have
two
versions
of
one
zero:
zero
floating
around
that
have
maybe
different
lengths
or
different
check
sums
they're,
somehow
different,
but
they're
both
labeled
one
zero
zero.
C
If
we
no
matter
which
way
we
go
on
this
like,
if
we,
if
we
don't,
require
people
to
bump
the
the
version
when
they
do
white
space
changes,
they're
still
going
to
have
that
problem
that
different
people
are
going
to
grab
the
version
one
zero
zero.
They
may
check,
make
whatever
white
space
changes.
And
now
you
have
multiple
versions
floating
around
being
emailed
around
being
posted
here
and
there.
C
C
C
Well
we're
talking
about
yang
revisions
here,
not
their
underlying
revision,
so
they're
going
to
publish
some
yang
if
they
change
their
tools
and
it
changes
their
white
space.
I
would
argue
it's
their
responsibility
to
either
bump
the
version
or
make
sure
their
tools
produce
consistent
white
space
output.
K
I
agree
with
you,
but
in
practice
this
is
a
big
hassle.
Even
in
standardization,
let's
say:
3gpp
people
started
editing
and
get
gitlab
natively,
and
then
they
changed
a
lot
of
white
space
because
the
github
local
editor
does
that
and
then
we
looked
for.
Is
this
really
different
or
just
messed
up?
K
C
Okay,
but
if
we
don't
bump
the
version,
I
think
that
same
problem
occurs.
So
if
we
say
if
we
say
you
know,
white
space
doesn't
matter,
then
there
can
be
two
versions
of
that
of
that
module
floating
around.
And
anyone
who
does
a
diff
on
those
two
versions
is
going
to
see
all
those
differences
and
get
confused.
C
K
If
we
consider
that
these
are
actually
same
files,
so
do
we
declare
that
yep
very
significant
white
space
doesn't
make
them
different?
Then
I
think
that
helps.
C
C
I
I
guess
I
mean
this
also
comes
down
to
you
know
whether
people
need
to
whether
we
want
to
allow
whether
we
want
to
stick
with
kind
of
standard,
diff
and
checksum
tools,
to
figure
out
differences
in
modules
or
whether
you
we
need
yang,
specific
checksum
tools
and
yang
specific
diff
tools.
G
So
jason,
I
was
just
going
to
make
a
comment
strob
here
on
the
one
I
can
certainly
see
the
benefit
of.
If
you
had
fixed
the
white
space
say
the
file
was
badly
formatted
and
you
wanted
to
clean
it
up.
I
can
certainly
see
justification
saying
in
that
case
it
definitely
makes
sense
to
bump
the
editorial
number
to
make
it
clear
that
this
is
the.
This
is
the
good
version
that
people
should
be
using.
This
is
the
updated
one,
so
so
that
sort
of
case
is
fine.
G
A
E
No,
I've
got
one
thing:
I've
just
wanted
to
say
back
to
what
jason
was
saying.
You
know
regarding
you
know,
by
addressing
how
you
diff
and
you
don't
know,
I
think,
actually
having
an
editorial
bump-
and
I
forget
whether
that's
been
said
already
said
it
in
the
past-
actually
helps
the
person
saying.
Hey,
there's
been
a
drill,
but
somebody
took
the
time
to
compare
and
is
telling
me
that
I
should
not
care
about
this
change,
so
I
won't
bother
doing
a
diff
as
opposed
to
it's
the
same
version
number.
J
J
A
That
was
an
old
comment
that
we
don't
need
to
talk
about
it
at
the
mic.
I
think
the
you
know
someone
already
made
the
comment
you
might
have
yang
specific,
tooling.
H
So
I
think
that
that
rob
made
a
very
important
point.
It
needs
to
be
it's
important
to
be
clear
what
the
version
number
stands
for.
Is
it
the
content
or
is
it
the
serialization
of
the
contents
of
the
specific
file
format
and
that
will
answer
the
question
kind
of,
depending
on
how
you
decide
what
the
version
number
stands
for
the
other
problem?
If
you
load
a
file
into
an
editor
that
does
white
space
changes
for
you
without
you
actually
having
control
clearly,
they
won't
assign
a
new
version
number.
H
So
the
the
problem
of
tools,
doing
line
and
conversion,
and
so
on
I
mean
that's
going
to
remain
with
us.
That
is
not
going
to
change,
and
if
you
have
decent
div
tools,
they
will
handle
it
or
if
you
have
your
versioning
repository
set
up
properly,
it
will
handle
it.
C
C
My
my
my
feeling
is,
that
is
that
we
probably
want
to
make
life
a
little
bit
easier
for
consumers.
That's
generally
a
larger
number
than
purdue
producers,
so
the
producer
of
a
module
is
you
know
one
entity
or
a
bunch
of
people
working
together,
but
consumers
is
going
to
be
a
wider
variety
of
organizations
and
and
and
people.
So
my
my
feeling
is
it's
easier
on
the
consumers.
C
If
they
get
told
that
there's
been
a
bump
for
editorial
changes,
so
you
know
go
back
to
balash's
problem.
So
if
there's
two
versions,
if
there's
two
copies
of
version,
one
zero,
zero
floating
around
the
consumers
will
know,
even
if
diff
tools
say,
there's
a
diff,
the
consumer
will
know
well,
there's
probably
there's
probably
just
some
white
space
stuff
for
my
editor
because
there
was
no
bump.
C
But
if
a
producer
actually
wants
to
clean
up
and
make
a
change
and
does
some
things,
you
know,
I
think
the
onus
is
on
them
to
bump
the
version
to
one
zero
one,
because
then
now
you
have,
you
know
those
two
versions
of
the
file
floating
around
and
the
consumers
know.
Oh
actually,
you
know
there
is
some
intended
editorial
fixes
in
in
this
101
version.
I'm
not
just
looking
at
you
know:
carriage
return
line,
feed.
C
J
J
K
G
Go
ahead,
okay,
I'll
make
my
comment
and
then
let
joe
go
afterwards.
So
just
on
the
so
I
agree
with
jason
in
terms
of
we
should
be
optimizing
for
consumers,
but
one
issue
that
we
potentially
have
is
if
a
file
has
been
published
and
it's
been
published
in
a
format-
that's
not
great,
then,
as
a
consumer,
if
the
version
number
is
tied
to
the
exact
layout,
you
have
no
way
of
sort
of
cleaning
up
that
file
and
making
a
copy
of
it.
That,
because
you're
not
allowed
to
give
that
copy.
G
The
same
version
number
and
you
can't
allocate
a
new
version
number,
because
you
don't
own
that
file,
there's
just
no
way
to
say.
Actually,
you
took
the
itf
modules
that
have
been
formatted
to
72
characters
or
73
characters
and
then
say
actually
I'd
like
to
make
them
formatted
to
80
or
something
to
make
them
easier
to
read
or
longer,
then
that
that
becomes
not
an
option.
There's
no
way
to
do
that.
If
the
version
number
is
tied
to
the
file-
and
I
don't
know-
if
that's
a
good
or
a
bad
thing,.
J
A
Yeah
so
let's
just
be
it's
aware,
I
think
you've
skipped
joe
at
least,
and
maybe
someone
else
so
joe.
If
you
want
to
get
back
in
the
queue
just
do
plus
q
to
make
sure
we
don't
lose.
A
A
I
think
yeah
you're
getting
yawn
asked
you
to
bump
joe.
I
just
didn't
want
to
lose
joe.
That's
all
go
ahead.
H
D
Thanks,
I'm
joe
clark,
I'm
in
agreement
with
jurgen.
I
I
think
that
a
module
publisher
is
going
to
that
they're
going
to
know
me
just
like
if
I
I'm
using
a
source
code
control
system.
If
I
clean
up
a
module
check
it
in,
I
get
a
new
revision
for
it.
I
might
probably
publish
that
with
editorial
changes.
I
think
just
like
with
the
imports.
We
have
two
different
situations,
two
different
issues
here.
I
think
the
moral
of
the
story
is.
D
We
need
good
tooling,
because
a
lot
of
times
people
are
going
to
just
pull
modules
off
of
the
server
from
a
consumption
standpoint,
and
the
server
may
compact
things
to
preserve
memory
space
whatever,
but
it
doesn't
mean
that
the
semantic
meaning
of
what
you
pull,
what
the
client
pulls
down
to
the
server
is
any
different.
So
if
I
had
a
a
1.002
1.00
copies
of
the
same
module,
I'm
still
going
to
need
some
gang-aware
tooling.
To
really
be
able
to
say:
do
I
have
the
same
module?
D
If
we
don't
have
yang
aware
tooling,
that
makes
it
easy
to
truly
diff
a
yang
module
semantically
between
two
we're
going
to
run
into
problems
anyway,
because
we're
just
going
to
see
different
people
aren't
always
going
to
go
back
to
the
package
and
pull
the
canonical
version
and
do
the
checksum
they're
going
to
consume
it
the
way
they're
going
to
consume
it
and
that
might
involve
pulling
it
off
the
server
and
that
server
might
have
done
some
optimization
for
it.
I.
G
G
I
was
just
gonna
add
one
more
thing
I
thought
of
actually
is
we've
been
busy
talking
about
version
numbers
here,
but
we
also
need
to
remember
that,
in
terms
of
the
yang
files
that
we
have
to
have
a
unique
revision
date
for
each
version
effectively,
so
we're
adding
both
of
those.
And
although
we're
talking
about
the
meaning,
are
related
to
version
numbers,
I
think
they
would
equally
apply
to
the
revision
dates
as
well
as
in.
G
If
you
change
the
layout
of
the
file,
do
you
have
to
have
a
new
revision
date
or
or
can
you
change
the
format
of
the
file
with
the
same
revision
data?
C
Yeah,
although
I'd
say
I'd
phrase
it
a
bit
differently,
if
you
are
the
owning
publisher
of
the
module
and
you're
publishing
a
new
version
of
the
module
you
own
in
the
place
that
you
publish
it
officially,
then
you
have
to
like
there's
been
some
examples
of
well.
If
I
take
itf
interfaces-
and
I
do
my
own
reformatting-
that's
all
fine.
A
C
Any
organization
you
know
for
their
own
purposes:
they
can
change
some
ford,
magma
module,
but
they're
not
going
to
republish
that
as
an
official
new
version,
they
can
include
it
in
whatever
repository
they
want.
But
all
they're
saying
is
that
this
is
the
you
know.
This
is
the
cisco
copy
or
the
nokia
copy
of
itf
interfaces
like
they.
They
aren't
warranting
that
that's
the
official
100.
If
they're
publishing
you
know
some
other
copy
or
distributing
some
other
copy
of
itf
interfaces.
G
J
J
Now,
from
from
the
discussion
about
this
second
topic
that
we
discussed
now,
I
think
that
there's
no
clear
consensus
even
on
this
call,
I
heard
many
strong
arguments
for
both
sides
or,
for
I
mean
there
was
maybe
three
options,
so
I
don't
know
how
we
should
go
on,
but
would
the
chair
people
like
to
conclude
the
call
somehow
formally.
A
Yeah
absolutely
thank
you
all
for
participating
stay
tuned
for
the
follow-up
meeting
that
jason
mentioned.
So
there
is
going
to
be
some
suggestions
of
additional
discussion
on
versioning
and
we're
at
the
top
of
the
hour.
So
thank
you
all
very
much
for
participating.