►
From YouTube: IETF108-NETMOD-20200730-1410
Description
NETMOD meeting session at IETF108
2020/07/30 1410
https://datatracker.ietf.org/meeting/108/proceedings/
A
Hello
and
welcome
to
our
online
ietf
108
meeting
we're
at
our
appointed
start
time,
so
we're
going
to
get
started
if
my
audio
level
or
any
audio
levels
are
not
great,
just
feel
free
to
put
that
into
jabber.
I
think
we
have
enough
people
watching
that
will
catch
that
we
have
myself,
I'm
blue
burger.
We
have
ken
watson
and
and
joel
juggling.
My
co-chairs
online.
I
actually
just
did
something
I
meant
to
remind
people
not
to
do
which
is
when
you
start
talking.
A
Please
identify
yourself
so
that
others
can
easily
recognize
who's
talking.
We,
our
agenda,
has
been
posted
as
of
all
in
the
slides.
Also,
please
join
us
in
the
link
that
I
just
sent
into
chat
to
help
us
out
with
the
joint
minute
taking
we
have
a
new
tool
that
is
replacing
etherpad
next,
please.
A
By
the
way,
thank
you
to
kent
who's
going
to
show
slides
for
all
presenters.
This
is
our
well.
It
should
be
pretty
familiar
to
to
everyone.
The
if
you're,
not
please,
click
on
that
link
at
the
bottom
or
go
to
the
link
on
the
bottom,
and
that
will
tell
you
about
what
governs
our
interactions
here.
It
governs
that
what
you
say
here
will
become
part
of
our
permanent
record,
it's
being
recorded.
Also,
it
is
a
contribution.
A
A
So
I
think
we
all
know
we're
on
meat
echo.
We
are
using
midoco
for
q
control.
If
you
want
to
join
the
queue
select.
The
speech
button,
the
mic
and
we've
already
mentioned,
the
joint
note-taking
blue
sheets
are
being
handled
by
media
echo,
so
we
don't
have
to
do
anything
special
there.
A
So
we're
gonna
cover
a
number
of
topics
ranging
from
the
more
mature
to
the
less
mature.
We
have
an
update
on
a
couple
of
documents
that
are
long
past
last
call
and
then
talking
about
where
the
versioning
activity
is,
and
we
have
a
couple
of
updates
on
that.
Excuse
me
and
then
on
to
the
the
common
data
types
and
that'll
be
the
end
of
our
working
group
documents,
and
we
have
one
document
that
is
an
individual
draft.
Next.
A
So,
in
terms
of
where
are
we
we,
we
have
a
couple
of
new
documents
published
by
the
rfc
editor,
so
that's
that's
always
great
to
to
see
new
documents
published.
We
also
have
three
documents
in
the
editor
queue.
A
One
of
them
is
just
recently
in
there
I'm
identifying
the
shepherds
for
on
each
of
these,
and
if
they
want
to
chime
in
and
say
anything
they
can
or
if
there's
any
questions
of
the
right
people
to
ask
about
that.
A
A
Thanks
so
we
have
no
liaison
activity
right
now,
but
the
next
two
documents
that
are
going
to
be
discussed
relate
to
ethernet
technology,
which
is
really
owned
by
the
ieee,
and
recently
there
was
some.
A
A
A
We
wanted
to
remind
folks
that
we
have
definitely
transitioned
to
a
new
world.
A
I
mean
I
think
we
all
are
living
it,
so
we
all
are
keenly
aware,
but
it's
going
to
be
some
time
while
we're
going
to
continue
working
remote,
and
we
wanted
to
make
it
clear
that
the
working
group
resources,
notably
the
working
group
webex,
is
available
for
informal
meetings
on
on
documents,
as
well
as
interim
meetings,
virtual
interims
and
all
that
it
takes
to
do
either
of
those
is
to
send
a
message
to
the
art,
the
chairs,
and
to
make
a
request
and
we'll
we'll
happily
set
up
a
meeting.
It
will
be.
A
A
B
Okay
yep,
so
hopefully
I
keep
this
update
fairly,
quick.
So
actually
now
it's
interface,
extensions
yang,
10.
I've
published
a
minor
update
yesterday,
so
I'll
cover
that
as
well.
So
next
slide
please
so
the
question
is:
is
wikiblast
call
complete.
This
is
this.
The
work
last
call,
I
think
was
initiated,
might
have
been
a
year
ago,
certainly
at
least
eight
months
quite
well.
I
took
a
long
time
to
resolve
this.
B
I
got
slightly
distracted
with
some
of
the
young
versioning
work
and
then
I
became
an
ad,
so
I've
had
various
issues
with
my
time
to
get
the
results.
I
think
now
that
all
the
issues
that
have
been
raised
through
working
in
law
school,
I
believe,
have
been
resolved
in
the
documents.
B
I've
posted
an
update
to
the
list.
A
couple
of
weeks
back,
I
haven't
seen
any
response
for
them.
My
guess
that
martin
is
probably
worth
sailing.
So
it's
tricky
for
him
to
respond
to
me
to
wait
a
little
bit
longer
and
also
waiting
for
don
to
feed
back
there's
one
issue
in
each
of
the
drafts.
I
just
wanted
to
highlight
in
terms
of
that
working
last
call
most
of
the
other
issues.
I
don't
think
particularly
they're
important.
B
So
in
the
interface
extensions,
I
think
when
I
presented
this
two
itfs
ago,
I
was
looking
back
through
the
slides.
There
was
a
proposal
to
add
a
new
in
discards,
overflow
counter
to
this
module
that
this
was
missing
and
useful,
and
whilst
I
agree
it
is
useful,
I'm
not
sure
it
really
fits
into
the
scope
of
what
this
document
is
covering.
B
This
draft
is
covering,
and
hence
my
proposal
is
that
we
shouldn't
do
this
now
for
this
document
and
if
we
do
want
to
have
this
count,
I
think
would
be
better
as
an
update
to
the
base
itf
interfaces
yang
module
if
anywhere
so.
My
proposal
here
is
to
make
no
changes
and
not
introduce
this
counter.
So
does
anyone
have
any
objections
to
that.
B
So
I
don't
see
any
if
there
is,
can
you
please
bring
it
to
the
list
very
quickly?
Otherwise
I
think
it
will
stay
as
it
is
the
moment
next
slide.
B
So
so
most
of
the
working
last
call
updates
I've
made
to
recently
been
to
the
sub
interface
vlan
model.
There's
lots
of
useful
helpful
comments
in
terms
of
improving
the
young
module
and
tightening
up
some
of
the
descriptions
in
various
places.
The
technologies
that's
useful.
The
most
significant
change
here
really
is
a
name
change
for
the
modules
so
before
it
was-
and
this
was
one
that
martin
requested
before
is
it
ifl3
vlan,
given
that
this,
the
vlan
encapsulation,
the
basic
v9
encapsulation,
could
be
used
for
l2
as
well
as
l3.
B
I've
changed
the
name,
the
module
to
just
iotif,
ifvlan
encapsulation
and
then
the
other,
the
other
yang
module
it
flexible.
Encapsulation
has
had,
if
added
into
it,
to
make,
make
it
clear
that
it's
sort
of
effectively
augmenting
interface
technologies.
B
I
think
this
gives
a
more
clear
split
between
like
basically
that
functionality
and
the
flexible
encapsulation
that
you'd
normally
use
for
l2
and
allows
you
to
match
on,
say
ranges
of
vlans
or
or
dot
one
p
bits,
for
example,
and
to
do
sort
of
manipulations.
So
that's
the
key
change.
That's
really
happened.
Most
of
the
other
changes
have
been
sort
of
editorial
changes
and
cleaning
out
and
clarifying
various
places.
B
I
don't
see
any
or
bring
it
to
the
list
so
otherwise
I
I
sort
of
feel
that
we're
probably
done
and,
from
my
perspective
I'll
leave
the
chairs
to
comment
on
that.
I
think
it
would
be
good
to
hear
back
from
from
the
individuals
who
provided
comments
during
the
last
call
to
check
that
they
are
happy
that
their
comments
have
been
been
addressed.
A
You're,
a
little
quick,
removing
the
slides,
though
so,
on
the
question
of.
Are
we
ready?
I
think
you
you
hit
it.
We
need
to
confirm
with
those
who
had
comments,
that
the
the
comments
are
addressed
be
great
for
the
to
ask
them
on
lists
and
get
them
to
respond
on
lists
if
they
only
respond.
Privately,
that's
okay,
just
both
know
that
they
respond
to
you
privately.
A
The
other
thing
on
this
change.
I
do
remember
we
had
a
a
little
bit
of
a
discussion
about
whether
ieee
would
worry
about
the
vlan
use
of
the
vlan
terms,
since
that's
really
theirs,
and
this
goes
back
quite
a
while.
I
believe
you
and
I
had
a
private
discussion.
That
said,
oh
we're,
calling
it
l3v
land,
so
that
should
keep
them
happy.
But
this
sort
of
goes
to
the
larger
question
of.
Do
we
need
to
send
a
liaison
over
to
the
ieee
saying
you
know
we're
progressing
these.
A
Do
you
have
any
comments,
or
you
know?
Are
we
okay
with
our
the
fact
that
you
are
a
contributor
there
and
we
have
the
ieee
coordination
group
and
I'll
point
out
that
we
have
the
ieee
coordination
group,
but
that
other
i2rs
document
which
we
thought
had
been
raised
many
times
the
ieee
came
back
and
said:
no,
you
didn't
raise
it,
so
I'm
a
little
hesitant
just
to
leave
it
there
with
that.
B
Back
to
you
so
yeah,
so
to
answer
this
question
and
the
other
thing
I
should
make
obviously
being
an
author
on
these
two
drafts.
The
intention
is
to
hand
responsibility
ad
responsibility
over
to
warren.
I
think
he's
agreed
to
do
that.
I
hope
he's
happy
to
do
that
and
in
terms
of
I
hate
I
I'll
leave
it
to
him
to
confirm.
B
What's
proposing
here
in
terms
of
ieee,
I
don't
think
any
formal
liaison
is
required,
so
the
ieee
certainly
had
chances
to
review
these
documents
or,
in
particular,
the
the
sub
interface
vlan
model
and
have
provided
feedback
into
them
in
terms
of
the
current
structure
and
things,
so
they
have
been
involved
in
the
process.
So
that's,
I
think,
hopefully
good
and
I
believe
that
they
are
reasonably
accepting
of
what
the
current
structure
is.
B
I
would
like
them
to
be
able
to
review
these
final
versions
and
check
that
they
are
still
happy
with
that,
rather
than
a
form
of
liaison.
B
The
way
I
would
propose
is
to
go
both
through
the
iatf
ieee
coordination,
email
address,
email,
alias
and
also
a
meeting,
if
required,
but
there's
also
an
ieee
youngsters
meeting
that
I
participate
in
on
a
semi-regular
basis,
and
so
I
would
make
a
suggestion
that
that
those
ieee
youngsters
review
the
latest
version
of
these
documents
to
check
that
they're
still
happy
and
for
for
confirmation,
it's
that
will
be
youngsters
who
are
currently
reviewing
the
i2rs
document
to
check
that
they're
happy.
So
so
I
have
some
connections
with
them
there.
B
A
While
we're
giving
time
for
warren
to
enter
the
queue,
if
he
so
chooses
to
me,
that
sounds
just
fine
and
to
be
clear,
you're
saying
you'll
send
that
message.
The
alternative
by
the
way
is
I'm
on
both
of
those
lists.
Also,
I'm
happy
to
send
it,
but
I'm
also
whatever
you
prefer.
B
Either
so,
let's
take
that
one
off
line,
I
think
I
I
don't
mind
which
way
around
we
can
work
out.
I
don't
think
it
I
mind
if
it
comes
from
you
or
from
me,
either
work
or
even
more.
C
Yep
sounds
good
to
me.
I
prefer
it
comes
from
somebody
other
than
me.
The
email
but
yeah
general
plan
sounds
good
happy
to
run
this.
Thank
you
very
much.
A
Okay,
great,
thank
you
rob
why
don't
you
send
the
mail
and
unless
you
send
me
a
mail
saying
I'll,
I
prefer
you
to
do
it
and
we'll
go
from
there.
A
All
right
I'll,
please
copy
the
at
least
that
mod
chairs
I'll
already
get
it,
because
I'm
on
both
lists,
but
the
other
chairs
may
not.
Okay.
Thank
you.
So
moving
on.
D
Oh
and
I
apologize
for
the
end
of
the
abrupt
screen
share
ending.
That
was
the
way
I'm
presenting
the
slides
when
it
hits
the
last
slide
it
automatically
the
tool
just
automatically
stops
sharing.
When
I
hit
the
next
button,
so.
E
Okay,
thank
you,
okay,
so
my
name's
rashad
and
I'm
going
to
be
presenting
a
summary
update
on
the
versioning
solution
on
behalf
of
authors
and
contributors.
Next
slide.
Please.
E
So
the
agenda,
so
this
slide
deck
as
just
mentioned,
is
going
to
be
presented
by
myself.
The
following
presentations:
we're
going
to
be
presenting
the
two
main
drafts.
Well,
the
two
main
ones:
we've
been
focusing
on
the
first
presentation
on
updated
module,
revision
handling
is
going
to
be
by
myself
and
then
the
one
after
yang
semantic
versioning
is
going
to
be
presented
presented
by
joe
next.
Please.
E
So
that's
a
slide.
You
probably
have
seen
at
four
or
five
itfs
in
a
row
now
so
the
versioning
solution
overview.
You
know.
Basically,
this
consists
of
five
drafts.
The
first
one
is
the
module
version
handling,
which
you
know
it
supports
branching.
It
introduces
revision
labels,
it
helps
you
how
to
document.
You
know
non-backwards
compatible
changes
between
different
regions
and
all
that.
The
second
one
young
semantic
versioning,
which
we've
also
called
modified
revolution,
handling
sorry
semantic
versioning
in
the
past.
It's
basically
an
example
of
the
of
the
revision
label
scheme.
E
The
third
one
is
yang
packages
which
basically
allows
you
to.
You
know
group
modules
together,
you
know
and
do
versioning
at
schema
level
number.
Four:
that's
how
to
allow,
how
to
how
to
enable
clients
to
to
select
a
version
when
a
device
supports
multiple
versions
and
the
last
one
is
a
comparison
tool.
E
Please,
okay,
this
slide
also
you've
seen
a
few
times.
The
colors
and
arrows
might
have
changed
a
little
bit,
but
that's
basically
the
relationship
between
the
five
documents
there's
hard
dependencies
and
there's
possible
dependencies.
E
E
E
A
A
From
the
last
meeting,
I
believe
what
we
had
said
on
these
is
that
we
were
going
to
hold
them
for
and
just
keep
them
ready
to
last
call
as
a
as
a
group
as
a
set,
just
in
case
there
were
updates,
rather
than
having
to
send
out
a
bis
to
an
rfc
that
you
know,
probably
by
the
time
we're
done
with
the
process.
It'll
be
right
when
we're
publishing
that
there
will
know,
there's
changes.
A
Of
course,
the
alternative
is
that
the
since
it
does
take
a
while
that
there
we
we
hold
it
up
at
the
last
minute,
as
opposed
to
the
first
minute
of
the
publication
process.
So
I
I
believe-
and
I'm
again
I'm
going
through.
I
I'm
going
from
memory,
so
it
may
be
wrong,
but
I
believe
we
said
we
were
going
to
hold
them
until
the
other
documents
were
ready
to
go.
E
Okay,
module
revision
handling
that
was
adopted
right
before
last
itf.
This
draft
has
had
you
know,
fair
number
of
changes
since
march,
and
the
next
presentation
is
going
to
go
over
those
and
the
open
issues.
E
Similarly,
for
young
semantic
versioning,
quite
a
few
changes
since
march
and
presentation
to
follow
from
joe
next
slide.
So
the
three
other
drafts
of
the
of
the
set
of
five
have
had
no
changes.
Since
march,
the
authors
and
contributors
in
the
weekly
meetings
have
been
focusing
on
the
first
two
and
I
think,
once
we
have
soon
quote
unquote
less
issues
or
no
issues
on
the
first
two
drafts,
then
those
three
are
going
to
be
next
in
line
to
be
progressed
further.
E
So
just
a
reminder
to
the
working
group:
there
is
an
open
meeting
weekly
meeting.
We
it's
the
same
set
of
people.
You
know
who
meet
every
week
or
mostly
every
week,
we've
been
doing
that
since
march.
E
We
discussed
the
key
issues.
We
bring
them
back
to
the
working
group
mailing
list,
as
you
probably
have
seen,
and
so
it's
2
p.m.
Uk
time
on
tuesday
9
a.m.
Eastern
thanks
for
all
the
authors
for
regular
attendance
and
also
to
contributors,
bo
yan
and
italu
for
meeting
regularly.
E
The
issues
are
tracked
on
the
link
specified
here
on
the
second
bullet
and,
as
we
were
just
okay
saying,
as
I
was
just
saying,
we
in
terms
of
phasing
we
want
to
get
the
module,
versioning
and
yang
semantic
versioning
first
to
working
group
last
call-
and
you
know,
as
that
is
progressing
you
know-
will
be
then
attacking
the
three
remaining
documents.
E
E
Document
so
the
presentation
I
mean
it's,
it's
it's
split
in
two
parts,
one
we're
going
to
go
over
the
changes
we've
done
in
the
last
revision.
Those
are
mostly
based
on
issues
which
have
been
brought
forward
around
adoption
call
time
and
also
various
issues.
We've
had
among
we've
been
discussing
among
authors
and
contributors
next
slide.
Please.
E
So
the
previous
version
of
the
document
had
some
text,
which
said
which
you
know.
If
it
looks
like
a
young
semantic
version,
then
we
should
be
interpreting
it
as
a
yang
semantic
version.
The
comment
we
had,
I
believe
from
martin
was
well
well.
You
know
what,
if
I
use
another
flavor
of
semantic
versioning,
well
you're
going
to
interpret
a
cassian
semantic
versioning,
even
if
it's
not
so,
we've
updated
the
document
to
say
to
we
have
a
new
extension
which
specifies
what
scheme
a
module
or
sub-module
uses.
E
E
E
Represent
label
in
file
name,
so
the
previous
version
of
the
document
basically
said:
if
you
had
a
file
name,
you
would
use
the
add
sign
to
put
the
revision
label
in
and
the
comment
we
got
from
a
few
people
was
that
well
we're
basically
losing
the
functionality
of
using
revision
date.
If
you
know
we're
looking
for
a
certain
revision
date,
then
we
need
to
look
inside
the
module
and
anyway,
the
comments
were
fairly
consistent,
that
what
was
there
was
not
liked.
E
So
the
document
has
been
updated
and
that's
been
mentioned
on
the
list
that
what
we
have
now
is
the
we
have
the
number
sign,
the
pound
sign
as
delimiter
in
any
file
name,
so
you
can
use
either
add
revision
date
or
you
can
use
a
pound
revision
label.
E
What
that
means
is
that
you
could
have
two
file
names
for
the
same
module
contents.
You
may
use
symbolic
link
you
don't
have
to,
but
that's
basically
what
what
what
that
means.
E
E
We've
updated
section
3.3
of
the
latest
revision
to
basically
state
that
a
sub
module
you
know
it
can
use.
It
can
have
a
it,
can
have
a
statement
for
revision
label
scheme.
It
may
use
a
different
scheme
than
the
including
module.
We
went
back
and
forth.
Look
on
that
one.
F
D
A
D
A
Think
rob
is
volunteering.
D
D
E
E
We
state,
you
know
that's
what
the
initial
text
was
trying
to
say
that
the
label
space
of
sub-modules
is
separate
from
the
one
of
including
modules
and
the
last
two
points.
There
is
basis
saying
that
if
you
change
a
sub-module
well,
you
must
have
a
new
revision
label
for
that
sub
module
and
the
including
module
and
finally,
well,
it's
kind
of
obvious.
But
if
you
change
the
sub
module
you're,
not
changing
the
revision
label
in
other
sub
modules.
E
E
Okay,
so
this
is
in
the
context
of
you
know,
could
we
have
two
different
files
for
the
same
module
with
same
same
revision
label
but
different
contents?
E
And
I
forget
whether
this
was
brought
up
to
the
mailing
list.
But
what
the?
What
we
concluded
in
the
meetings
is
to
say
that
if
two
files
have
the
same
version,
then
the
file
contents
have
to
be
exactly
the
same
and
by
contents.
One
thing
which
is
not
clear
in
the
current
version
is
that
including
revision,
history
also
so
revision.
History
has
to
be
the
same.
So
I'm
just
going
we're
going
to
add
the
including
reversion
history
in
section
3.3
of
the
next
update.
D
A
lot
of
did
you
have
a
question,
you
know.
Yes,
you
hear
me.
No,
yes,
he
hear
you
and
you
may
have
had
a
question
on
a
previous
slide
as
well.
So
if
you
want
me
to
go
back
to
that,
please
say
so.
E
So
the
first
one
thank
thank
you
lada,
I'm
not
sure
understood
your
question
fully
so
you're,
basically
saying
having
the
symbolic
link
is
an
issue
or
not.
Having
symbolically
is
an
issue
or
both
are
issues
it.
G
Is
it
is
just
another
issue
for
for
systems
like
git,
but
the
basic
issue
is
having
the
survision
number
included
in
in
the
file
name,
which
makes
it
difficult,
because
each
time
you
change
something
in
the
file,
you
are
supposed
to
change
the
file
name,
so
it's
then
difficult
to
keep
the
history
of
of
that
file.
So
to
me
this
is
real,
something
that
makes
it
difficult
for
using
such
systems
like
it
or
github
in
general.
E
G
B
Can
I
just
have
a
comment
as
well:
rashad
yep,
so
rob
wilton
here
is
an
individual,
so
I
would
have
thought
forget.
Probably
the
best
thing
to
do
is
potentially
not
to
have
the
revision
date
or
the
original
label
in
the
the
artifact
that's
being
stored
in
git.
But
if
you
publish
these
these
somewhere
else,
that's
the
point
you
may
want
to
put
one
or
both
of
these
on
is
what
I'm
thinking.
G
G
Here
so
we
are
talking
about
a
specific
version
of
the
module.
Does
it
mean
that
this
also
includes
some
changes?
Let's
say
in
white
space,
or
does
it
mean
that,
as
soon
as
this
schema
remains
the
same,
then
the
revision
is
the
same
or
what
is
the
idea?
That's.
E
That's
a
good
question:
we
actually
have
a
as
part
of
the
next
issues
or
discussion
top
topics,
there's
a
later
slide
for
that
ladder.
If
you
don't
mind,
we
can
wait
until
then.
Okay
sure,
thank
you.
E
If
no
more
questions
next
slide,
please,
okay,
so
the
previous
version
of
the
document
had
the
status
description,
which
was
kind
of
a
workaround
for
not
having
description
for
status
statements.
A
few
people
didn't
like
it
and
it's
you
know,
there's
a
I'm.
The
workaround,
for
it
is
to
you
know,
update
the
description
of
the
of
the
attribute
itself.
So
basically,
we've
removed
the
status
description
and
you
know
there's,
I
believe,
there's
an
open
issue
against
young
next.
For
that
next
slide.
E
E
So
section
311
had
text
regarding
ordering,
but
it
was
incomplete.
The
document
has
been
updated.
It
talks
about
order
of
sub
elements
in
input
and
output
and
also
before
that,
the
text
at
rpc
only
action
is
also
okay
covered.
To
summarize
we're
basically
adhering
to
79.50
79.50
next
slide.
Please.
E
E
Grammar
for
new
extensions,
so
basically
the
yang
modules,
the
extensions
were
not
complete,
didn't
have
you
know,
basically
the
grammar
describing
and
what
statements
those
extensions
can
be
present
and
what
sub
statement
they
can
have
document
has
been
updated
next
slide.
Please.
E
E
So
this
issue
is
this:
topic:
is
we've
been
discussing?
How
making
an
mbc
change
in
an
imported
module
can
break
the
importing
module?
So
you
know
you've
got
let's
say:
module
a
at
1.0.0
and
it's
saying
it's
importing
module
b,
it's
stating
2.0.0
or
derived
and
again
you
know
those
examples
here.
Use
sanver,
that's
not
limited
to
sender.
E
So
the
next
step
we
have
in
mind
right
now
is
to
add
some
text
on.
You
know
the
impact
of
the
guidelines
on
the
impact
of
making
non-backwards
compatible
changes
in
a
module
which
is
imported.
I
mean
many
of
those
things
are
similar
to
the
other
guidelines.
We
have,
such
as
you
know,
obsoleting
a
node
before
deprecating,
duplicating
it,
etc.
D
As
a
contributor,
I'm
wondering
if
it's
possible
to
make
it
that
the
instead
of
2.0
or
derived
it
can
be
to
anything
2.0
or
greater,
but
not
but
less
than
or
equal,
but
less
than
3.0.
E
Yes,
yes,
so
we've
actually
had
a
little
bit
of
discussions
last
week
via
email
that
came
up
exactly
for
the
same
reason.
E
We
haven't
closed
on
that
yet,
and
I
think
it's
still
an
open
item
on
our
side
to
see
whether
we
want
to
go
ahead
with
that.
That's
probably
one
of
the
things
we're
going
to
be
discussing
in
the
meeting
after
I
itf.
E
E
This,
but
to
answer
your
question
kent,
yes,
this
is
something
which
is
possible.
Okay,
thank
you.
It's
not
covered
in
the
document
now,
but
it's
something
which
we
have
to
discuss.
D
Yeah
I
mean
just
to
since
we're
discussing
it.
I
can
imagine
I
mean
yes,
3.0
means
a
break
and
backwards
compatibility,
but
the
breaking
backwards.
Compatibility
may
not
be
around
the
area
that
matters,
and
so
it's
okay.
I
can
imagine
how
the
discussion
could
go
both
ways.
I
appreciate
that.
Thank
you.
B
So
I
think
kent
makes
a
good
point
there
and
that's
the
same
one
I
would
have
raised.
The
other
thing
to
be
aware
of
here
is
that
the
import
revision
x
or
derived
is
actually
doing
it
by
the
revision
date
and
the
revision
history.
So
it's
not,
although
you
can
use
the
version
label
to
identify
it,
it's
not
actually
using
any
semantic
meaning
from
the
version
label
to
make
decisions.
So
that's
the
other
thing.
B
We
need
to
be
very
careful
about
here
that,
even
though
send
the
numbers
are
being
used
in
those
revision
labels.
That's
not
exactly.
The
underlying
mechanics
are
being
used
here
in
terms
of
choosing
which
version
which,
which
revision
of
a
module
is
being
imported.
That's
been
done
purely
by
the
revision
history,
I'm
not
sure.
That's
helpful
or
more
confusing
than
what's
been
said
previously.
D
And
again,
as
a
contributor,
just
adding
on
to
my
previous
comment
in
the
python
package
publishing
world,
you
know
many
times,
people
publish
packages
and
so,
for
instance,
right
now
I
have
some
python
packages
are
being
published
and
they
declare
compatibility
with
3.7
3.8.
Really
I
expect
compatibility
also
3.9,
but
specifically,
I
don't,
I
say,
not
compatible
with
4.0
or
above,
but
as
soon
as
it's
discovered
when
ford.
D
is
released,
and
I
can
do
some
testing
and
I
can
see
that
things
work,
then
I
would
update
that
restriction
and
allow
for
the
4.0.
So
maybe
something
like
that,
where
initially
you
know
just
because
you
don't
know
what
the
future
brings
you
it's
constrained,
but
then,
once
you
know,
some
visibility
is
provided
or
the
constraint
can
be
relaxed.
B
The
the
problem
is,
though,
that
is
the
decisions
not
being
based
on
whether
it's
4.0
or
not
or
400.
The
decision
is
being
based
on
on
whether
the
revision
history
of
the
module
you're
importing,
contains
the
revision
you're
looking
at.
So
it's
not
looking
at
the
like
the
semantic
version
labels
at
all.
It's
just
looking
at
the
dates
and
seeing
is
is
this:
is
this
one
in
the
revision
history
newer
than
the
minimum
revision
date
that
you've
specified?
So
I
think
that's
something
we
need
to
be
careful
here.
B
That's
because
you've
got
a
split
between
the
revision,
dates
and
revision
labels
in
the
base
draft
and
the
yang
semantic
version
numbers
in
a
separate
draft.
Then
the
sort
of
constructs
between
the
two
are
slightly
separate.
Maybe
that's,
maybe
that's
a
bit
confusing,
but
not
sure
we
can
really
mitigate
that.
E
So
my
understanding
of
what
kenki
is
saying
is
that
the
whole
purpose
of
this
effort
was
to
address,
allow
when
nbc
changes
happen
and
in
this
case
we're
doing
an
ndc
change
and
it
could
break
it
could
not
break.
But
it
could
break.
D
You
did,
and
I
think
it's
the
case-
that
when
the
microphones
turned
on
the
first
couple
seconds,
maybe
getting
clipped
so
just
to
repeat
myself.
What
I
said
is
it
does
sound
confusing
and
that
it
did
seem
broken,
because
I
thought
the
the
whole
intent
of
this
effort
was
to
resolve
these
issues.
B
A
Yeah
sorry
same
clipping
problem:
this
is
blue.
As
chair
rob,
I
think
it'd
be
really
good.
If
you
send
your
example,
the
list
to
help
facilitate
that
discussion.
A
E
You,
okay,
this
is
a
follow-up
to
the
previous
issue.
The
first
two
steps
are
exactly
the
same
as
in
the
previous
issue.
If
the
difference
here
is
that
we're
looking
at
the
case
where
there's
an
explicit
change
to
module
a
where
module
a
now
goes
hey,
I
want
version
3.0.0
or
or
derived.
E
Is
this
a
bc
or
an
nbc
change?
So
we
started
discussing
this,
and
I
mean
there's
also
a
next
slide
on
on
this.
Just
to
before
I
start
getting
questions
on
the
two
options.
I
just
want
to
say
that
I
don't
believe
there
is
unanimity
amongst
the
authors
and
contributors
yet,
but
we'll
get
on
that.
E
I
will
get
to
that
on
the
next
slide,
so
the
first
option,
which
option
a
basically
states
that,
depending
on
the
impact
of
changing
that
import
statement,
a
decision
is
made
on
whether
the
change
to
module
is
bc
or
nbc.
So,
for
example,
if
module
b
changed
a
type
or
restricted
range
which
is
used
by
module
a
you
would
go
none
backwards
compatible
else.
You
would
go
backwards,
compatible
the
pros
of
this.
Well,
you
know
you
made
a
change
in
module
a
and
you
address
the
version
diversion
label
of
module
a
accordingly.
E
The
change
is
again
is
an
import
statement.
Change
the
count
against
this
is
that
you
know
there
is
questions
as
to
whether
this
makes
it
harder
or
con
tooling,
there's
also
the
potential
issue
that
it
isn't
inconsistent
with
the
previous
issue,
although
we
that
point
may
change
depending
on
how
we
resolve
or
if
we
resolve
the
previous
issue
so
again
option.
Is
you
look
at
the
impact
of
changing
your
import
case
statement
so
just
just
to
make
it
clear.
E
E
Via
some
other
means,
young
packages
was
discussed,
potentially
yang
library.
Also,
sorry,
one
point
I
forgot
to
mention
in
option.
A
one
comment
is
that
one
comment
against
that
is
that
it
was
felt
that,
if
you're
making
an
nbc
change
in
module
b
and
if
you
end
up
making
revision
labels
change
nbc
change
to
both
a
and
b
that
could
be
viewed
as
double
jeopardy
for
lack
of
a
better
term
that
there's
two
version
changes.
E
Because
of
that,
I
guess
that's
one
way
of
looking
at
it
anyway,
back
to
option
b.
The
good
thing
about
that
is
that
well
good,
maybe
whether
you're
importing
your
imported
module
is
changing
or
whether
you're
making
a
change
to
import
statement.
It's
the
same,
it's
dealt
in
exactly
the
same
way.
The
what's
not
nice
about.
It
is
looking
at
the
version
of
of
module
a
you,
don't
get
the
full
picture,
you
know
it
it.
May
you
know
you
you're
looking
at
1.0.0
and
it's
it's
all
1.0.1.
E
E
E
B
I
was
just
going
to
make
a
quick
ask.
A
quick
question
is:
is
the
example
sufficiently
clear,
as
is
rob
sufficiently
clear
for
people
to
understand
what's
being
asked?
It
may
be
that
we
have
to
put
this
again
in
an
email
to
the
regular
list
to
make
sure
people
understand
the
problem
and
what's
being
asked,
because
it
may
be
that
it's
hard
to
follow,
rob
just
to
be
clear.
Are
you
speaking
as
a
contributor
or
as.
D
A
Sorry,
rashad
yeah,
please
do
send
me
the
email
again.
I
thought
I
understood
it
until
your
last
statement.
Quite
honestly,
when
your
last
statement,
where
your
you
know,
the
revision
implies
all
the
everything
that
it
includes
as
well
to
me
sounds
like
the
the
the
sort
of
the
pack
almost
getting
towards
the
packages
document.
A
So
you
know
I
had
a
little
trouble.
First
thing
what
you
meant
there:
okay.
E
That
might
okay,
so
that
point
might
not
have
been
the
one
which
was
the
most
well
made.
So
please
revert
your
understanding
to
what
it
was
before.
Looking
at
the
change
to
the
in
portuguese
statement,
I
was
just
trying
to
provide
a
different
angle
way
of
looking
at
it.
I
thought
it
would
make
things
clearer
but
looks
like
it
has
not
so
ignore
bullet
three
on
on
the
current
slide.
A
Yeah
going
back
to
the
point
where
we
talked
over
each
other,
you
I
think
you
were
saying
you
were
going
to
send
something
to
the
list.
It
seems
that
we're
not
getting
a
lot
of
feedback
from
the
group
in
this.
You
know
this
new
way
of
doing
business
they're
holding
our
ietfs,
so
I
think
you
know
if
you
send
it
to
the
list
and
try
to
get
discussion
going
that
way.
I
think
that
would
be
great
so
appreciate
it.
E
E
If,
if
you're
configuring
that
device-
and
you
know
you
you-
you
know-
if
you're
shrinking,
you
know
the
value
space
of
a
of
a
config,
false
node,
you
know,
for
example,
you
know
that's
backwards
compatible.
So
in
essence,
what
we,
what
we
discuss
is
that
the
way
7950
is
done
and
an
mda
you
can
all
that
it's
basically
expecting
clients
to
be
liberal
in
what
what
they
receive.
E
E
When
you
look
at
stuff
like
features,
you
might
have
a
statement
which
says,
if
not
feature
as
opposed
to,
if
a
key
feature,
so
you
know
we,
we
want
to
stay
away
from
this,
so
what
we
thought
was
potentially
a
good
idea.
We
believe
is
a
pandora's
box,
so
the
update
is
no
change
and
if
this
is
needed,
we
believe
this
should
be
part
of
yang
next,
not
part
of
this
document.
E
Next
slide,
please
this
is
you
know,
what's
the
impact
of
you
know,
you've
got
a
yang
module.
It's
got
an
extension
statement,
you
know,
exception
statement
exists.
You
either
change
the
existing
statement,
you
remove
it
or
you
add
it.
We
had
some
discussions
in
in
the
meetings
we
thought.
Maybe
we
could
come
with
a
rule
which
applies
everywhere
and
the
feedback,
I
think
really
is.
This
really
depends
on
the
extension.
E
How
do
we
capture
this
per
extension?
Should
each
extension
describe
the
impact
of
adding
that
extension
changing
the
extension,
removing
the
the
extension-
and
I
think
belarus
pointed
out
that
this
was
actually
it's?
The
extension
thing
is
part
of
that
yang
next
issue.
So
we're
not
too
sure
what
to
do
about
this,
except
you
know,
put
guidelines
what
extension
statements
should
have
in
their
description
for
this
also
questions
like
you
know.
E
So
6991-bis
has
a
has
a
type
there
for
revision.
Identifier
and
currently
young
module
is
the
itf
yang
revisions
is
using
that
definition
from
six
nine,
nine
one
bis
and
one
concern
we
have
is
you
know
if
six,
nine,
nine
one
this
and
it's
a
big
if
becomes
version
someday?
This
would
create
a
circular
dependency.
When
you
know,
itf
young
versions
would
depend
on
six
nine
and
one
this,
and
vice
versa.
E
So
what
we
will
be
doing
or
strongly
considering
doing,
look,
I'm
not
sure,
is
removing
the
dependency
on
yang
revolutionary,
not
specifically
because
of
the
young
original
infrared,
but
to
have
no
dependency
on
six,
nine,
nine,
nine
one
bis.
D
D
Yeah
kent,
as
a
contributor,
so
you're
talking
about
removing
the
dependency
on
699
biz,
which
would
also
remove
the
use
of
the
revision
identifier.
What
would
then
the
draft
the
module
do?
Would
it
define
its
own
revision?
D
E
E
Okay,
so
this
is
lada's
question
from
earlier
regarding
what
about
you
know
all
white
spaces
white
space
changes
allowed
with
two
two
modules.
Having
the
same
version,
we
discussed
that
a
fair
bit
among
the
authors,
contributors.
We
don't
have
unanimity
most
of
the
authors.
Contributors
believe
that
white-based
change
should
result
in
a
new
revision
label,
indicating
you
know,
for
example,
in
the
case
of
young
sembler,
indicating
a
editorial
change.
E
The
main
reason
for
this
is,
we
believe
it.
You
know
we
want
to
be
explicit
if
you're,
basically
validating
a
module,
doing
a
checksum,
that's
where
that's
way
easier.
Otherwise,
if
you're
comparing
two
versions,
you
might
need
to
do
normalization
and
stuff
like
that,
but
we
understand
that
this
may
be
issue
for
some
implementation
or
some.
F
Yeah
I
I
just
wanted
to
understand
the
use
case
why
a
updated
version
of
a
module
would
get
published
that
had
only
white
space
white
space
changes.
I
can
see
white
space
changes
along
with
other
things,
but
it
seems
like
if
I
understand
this
question
correctly:
it's
what
if
the
only
change
was
white
space
and
if
the
only
change
was
white
space.
Why
would
why
would
someone
you
know
choose
to
update
a
module
just
to
make
white
space
changes,
because
I
don't
understand
that
use
case.
D
F
All
right,
yeah
yeah-
this
is
charles
eccle.
Sorry,
if
my
announcement
of
my
name
got
cut
off
or
if
I
forgot
to
do
it
but
yeah.
I
just
had
a
question
about
white
space
change
and,
and
why
why
would
I
understand
what's
being
proposed
here?
Is
that
the
only
change
in
the
module
is
white
space
change?
E
It's
a
good
question.
It's
a
good
point.
I
don't
have
an
answer
for
you
because
I
think
the
personal
persons
who
were
recommending
this,
I
think
we're
referring
to
more
to
internal
implementations
or
tooling.
So
I
don't
have
a
good
answer
for
you.
D
A
Okay,
this
is
from
jan
there's,
probably
no
reason
to
publish
with
only
white
space
changes.
The
point
is
that
there
should
be
a
version
number
for
every
different
check
set.
F
Yeah
I
mean
that
makes
sense
to
me,
but
I
wouldn't
I
mean
this
question
kind
of
becomes
moved,
but
but
I
guess
the
answer
then
would
be
if,
for
some
reason,
a
module
got
published
with
only
white
space
changes
yeah,
it
would
need
a
new
version
number
because
the
checksum
would
change.
But
basically
you
shouldn't
do
that.
A
G
Yeah,
this
is
a
tricky
issue
with
this
white
space
because
in
yeah
the
young
spec,
we
still
have
this
alternative
syntax
called
the
yin,
and
while
I
may
be
the
last
person
to
use
it,
it's
it's
still
there.
So
it
looks
like
basically,
this
index
cannot
be
used
for
for
this
version
versioning,
because
otherwise
it's
really
difficult
to
have
the
same
revision
in
in
both
syntaxes
due
to
this
white
space
issue.
G
D
Because
kent
has
the
contributor
responding
to
letter
comment,
but
a
lot
of
the
yen
files
have
a
different
suffix.
So
how
about
a
problem.
G
H
I
didn't
mean
to
leave
the
queue.
Thank
you
you're
here.
So
a
lot.
If
I
understand,
if,
if
I
had
a
module
foo
that
was
written
in
yang
in
a
mo
in
the
same
module,
foo
and
yin,
they
could
both
have
the
same
version.
Semantic
version,
revision
label
and
if
I
revised
module
foo
in
both
yang
and
yin
syntax,
then
even
though
the
the
syntax
or
the
the
language
is
different,
the
ultimate
the
modules
are
equivalent.
So
the
versions
could
be
parallel.
H
If
I
converted
one
to
one,
I
I
we're
changing
the
whole
syntax,
but
we're
not
changing
the
meaning
of
the
of
the
module.
So
I
would
imagine
the
version
number
could
stay
the
same.
H
Then
we
would
want
to
note
that,
and
the
reason
is
is
mainly:
we've
come
to
the
agreement
that
if,
if
I'm
looking
at
fu.yang
at
two
versions
of
fu.yang,
I
would
want
my
shaw:
1
shaw,
256
md5,
whatever
checksum
tool,
to
show
they're
going
to
be
different.
So
I
would
want
them
to
have
different
version
numbers.
So
I'm
I'm
aware
that
okay,
there
is
some
differences,
maybe
it's
just
editorial,
but
I
need
to
maybe
be
aware
of
that
same
thing
for
other
text.
H
Part
processing
tools,
if
it's
fu.yang
and
fu.yen,
I'm
already
aware
that
they're
going
to
be
different.
So
I'm
not
necessarily
looking
to
compare
apples
to
apples.
But
if
I
look
at
food.yang,
1.00
and
fura
yen
1.00,
I
would
expect
the
same
overall
schema.
The
same
overall
lack
of
a
better
term
meat
of
the
module.
G
Yeah,
this
is
slider
again
well,
consider
that
someone
just
takes
the
module
in
in
the
in
syntax
and
uses
some
tool
for
translating
it
to
to
yang,
and
as
far
as
I
know,
there
is
no
requirement
that
this
translation
has
to
be
the
same,
including
white
space
handling,
and
it
isn't.
If
you
use
different
tools,
then
really
you
can
come
up
with
something
different.
G
So
to
me
this
would
mean
that,
of
course,
this
requirement
on
everything
being
the
same,
so
that
you
can
make
the
sha.
I
show
something
this
simply
brings
down
after
this
right.
H
Yeah,
I
I
see
what
you're
saying
and
that
in
that
regard,
comparing
a
dot
yang
to
a
dot
yen.
Even
if
you,
if
they're
the
same
module
and
same
version,
their
text
tools
aren't
going
to
do
you
much
good
you're
going
to
need
the
deeper
set
of
tools
like
I
said,
we
hadn't
considered
the
alternate
syntax.
We've
just
been
wanting
to
help
like
the
human
brain,
identify
that,
if
I'm
looking,
I
wouldn't
want
to
see.
Food.Yang
1.00
and
another
food.yang
1.00
have
different
checksums.
That
would
bother
me
that
that
was
the
main
use
case.
H
There
we
go
I'll
do
my
best
because
I'm
the
next
presenter
anyway.
This
is
joe
clark,
cisco,
hi
joe
thank
you.
So
we
after
lotta's
comment.
We
we
knew
that
there
was
going
to
be
more
discussion
here
regardless.
This
was
going
to
end
up
in
yang
semantic
versioning
because
well,
just
frankly,
the
the
lineage
part
of
the
actual
module
versioning
doesn't
really
matter
it's
like.
If
I'm
going
to
release
another
revision
of
a
module,
then
it's
going
to
have
another
revision
and
it's
going
to
extend
that
lineage.
H
We
were
wanting
to
know
how
to
reflect
that
in
yang
semantic
versioning.
So
I
get
and
rashad's
back,
but
I
I
don't
know
what
you
what
the
chairs
want
to
do
here.
I
can
keep
going
or
pass
it
over
to
him.
He's
probably
better
prepared
at
this
point.
H
E
E
So,
as
you
can
see,
we've
got
a
few
outstanding
issues,
a
few
of
those
going
to
be
discussed
on
the
alias
we'd
like
to
I
mean
our
plan
is
to
get
it
to
working
group
last
call
our
desire
before
our
next
itf.
E
H
H
H
All
right,
so
what
changed?
Between
our
last
virtual
interim
and
today
we
replace
the
rather
disliked
lowercase
m
and
uppercase
m
suffixes,
we'll
get
into
that.
We
removed
that
text
that
rashad
mentioned.
That
said,
anything
that
looks
like
a
semantic
version
in
quack
select
a
semantic
versioning
must
be
a
semantic,
a
yang
semantic
version.
H
We've
applied
some
guidelines
based
on
some
feedback
from
the
list
for
both
general
module
author
development,
as
well
as
ietf
specific
module
development
on
how
to
use
semantic
versioning
within
a
development
cycle.
So
before
a
module
becomes
fully
released.
We
expanded
the
version
component
size.
It
was
a
kind
of
an
odd
32768
which
which
wouldn't
have
really
fit
it,
a
a
by
two
boundary
all
the
way
up
to
two
to
the
thirty
first
minus
one.
H
So
the
the
each
revision
each
version
component,
major
minor
patch,
can
be
relatively
large.
We
don't
necessarily
expect
that,
but,
like
lou
said
earlier,
we're
trying
to
account
for
a
all
possible
scenarios
and
finally,
we
added
some
ietf
module
development
flow
as
an
example
into
an
appendix
a
next
slide.
Please
all
right!
H
Instead,
we
opted
for
something
that
is
compatible
with
the
semver
2.0
spec,
but
is
very
detailed,
and
that
is
the
underscore
compatible
and
underscore
non-underscore
compatible
with
the
former
being
the
stand-in
for
lowercase
m
and
the
the
latter
being
the
standard
for
uppercase
n.
Remember
these
are
the
sticky
labels
that,
when
you
can't,
as
you
see
in
the
example
here
when
you've
got
a
1.0
and
you
went
to
1.1.0
to
make
some
backwards
compatible
changes
and
then
you
released
a
non-backwards
compatible
2.0.0
and
again,
these
are
the
yang
semantic
version,
revision
labels.
H
You
might
have
gone
with
a
1.101
for
some
bug
fixes,
but
then
your
customer
said
you
know
what
I
need
you
to
port,
that
new
feature
to
my
1.1
module
and
well,
you
can't
go
well.
In
that
case,
you
could
go
to
a
1.2,
but
they
didn't
want
to
do
that
for
whatever
reason,
let's
say
so,
you
you
had
to
add
this.
This
underscore
compatible,
so
this
module
is
compatible.
H
Then,
in
the
last
case
there
1.1.3
non-compatible,
you
couldn't
go
to
2.0
since
it
already
existed,
and
that
was
something
else,
but
maybe
that
same
customer
wanted
you
to
backport
a
a
breaking
change
to
your
their
1.1
module.
So
those
are
where
those
sticky
tags
come
in
and
once
something
goes
to,
the
non
underscore
compatible
adds
that
nbc
change,
where
there's
already
a
a
major
fork
in
the
module.
That's
when
that
can
never
leave.
H
So
if
there
was
a
1.1.4,
even
if
it
just
contained
bug
fixes
onto
1.1.3
1.1.3
non-compatible,
it
would
also
need
to
retain
the
underscore
non-underscore
compatible.
We
think
in
general.
This
is
going
to
be
not
that
frequently
used,
but
we
know
already
from
a
number
of
vendors
that
there
is
a
need
for
this.
So
this
just
replaces
the
m
and
the
m
to
be
a
little
bit
more,
a
little
bit
clearer
with
what
those
suffix
suffixes
mean
next
slide.
Please.
H
And
again,
I'm
watching
to
see
if
anyone
steps
up
so
interrupt
me
at
any
time
we
added
a
new
revision
label
scheme.
This
just
extends
this
is
the
very
small
yang
module
at
the
end
of
the
yang
simver
draft.
H
This
extends
what
rashad
mentioned
in
the
yang
or
the
module
versioning
draft,
so
we
just
add
a
scheme
there
and
we
reference
the
draft
that
talks
more
about
the
syntax,
there's
also
a
type
def
in
the
same
module
that
mentions
the
actual
syntax
for
yang
semantic
versioning.
But
you
must
reflect
this
scheme
if
you're,
if
you're
using
yang
simver
next
slide,
please.
H
H
I
should
say
that
is
mentioned
in
the
draft,
but
in
this
case
maybe
you've
gotten
a
little
bit
more
along
in
your
development
process,
so
you're
using
the
you're
saying
that
this
is
going
to
be
will
be
when
it
ra
when
it's
ratified
the
1.0.0
version
of
this
module,
while
in
development
you
include
the
full
draft
name
that
is
currently
that
the
module
is
currently
published
in
and
this
would
only
be
required
for
those
modules
which
are
going
to
be
or
versions
which
are
going
to
be
submitted
to
data
tracker.
Let's
say
so.
H
H
If
you
go
to
the
next
slide.
The
reason
we
chose
this
was
to
support
parallel
development
as
well
so
oftentimes
you
may
have,
especially
in
maybe
the
best
case.
You
might
have
two
compe
initially
competing
proposals
for
a
solution
and
we
wanted
to
make
sure
that
there
was
a
way
of
differentiating
the
two.
So
in
this
case
you
might,
this
is
not
a
net
new
module.
This
is
an
enhancement
to
an
existing
publish
1.0.0.
H
Let's
say
the
target
is
going
to
be
1.1,
but
both
jane
doe
and
john
doe
have
proposed
different
initial
solutions
and,
and
they
might
have,
the
the
module
version
would
be
the
same
1.1.0
the
target,
but
the
drafts
that
contain
those
modules
are
different,
so
we
have
the
support
for
that.
They
can
happen
in
parallel.
Then,
let's
say
the
working
group
would
adopt
one
of
these
or
maybe
a
combination
of
these.
The
draft
name
would
change
to
still
be
1.1.0,
but
it
would
be
draft.itf.netmod
so
on
and
so
forth.
H
So
the
moral
of
the
story
is
these
version.
Numbers
all
have
to
be
unique
and
by
using
the
draft
by
using
this
target
approach
by
including
the
draft
revision,
even
with
parallel
development.
Like
this,
we
get
unique
versions
even
in
development,
and
that
was
one
of
the
things
we
were
striving
for,
but
as
you'll
see
in
an
upcoming
slide,
it
did.
H
I
think,
italo
mentioned
that
it
does
open
up
an
issue,
so
we're
going
to
talk
about
that
next
slide,
I
think,
is
a
as
a
filler
slide,
so
I'll
pause
for
a
second,
because
I
know
we're
running
out
of
time.
No
questions.
I
don't
see
someone
coming
up
so
discussion
topics.
H
Speaking
of
the
devil
here
is
that
issue.
So
let's
say
your:
the
target
module
is
initially
going
to
be
a
the
next
revision.
You
plan
a
non-backwards
compatible
change,
a
major
version
change,
so
the
initial
target
becomes
2.0.0
and
you
do
that
pre-release
notation.
H
Then,
during
development
you
decide,
you
know
what
there
really
isn't
consensus
for
this
nbc
change,
we're
going
to
make
it
backwards
compatible.
But
if
you
go
backwards
in
your
version
number,
your
target
version
number
there's
an
issue
with
precedence
with
pre-release
precedence
that
that
now
you
can't
say
that
1.1.0
dash
pre-release
is
greater
than
the
previous
2.0.0
pre-release
there's
a
breakage
there.
H
H
They
can
always
take
that
up
if
they
need
it
towards
the
end
of
development
like
right
at
the
end
of
development,
make
it
a
1.1
or
a
2.0,
and
that
way
you
you
inform
them
of
the
risks
of
of
making
too
big
of
a
target
leap,
while
at
the
same
time
recognizing
that
in
general
the
guidance
is
to
do
small
increments
and
then
right
at
the
end,
say
this
is
what
the
official
release
ga
whatever
again,
whatever
you
want
to
call
it
version
number
for
the
revision
label
will
be
so
that's
still
in
discussion
on
those
calls
that
rashad
mentioned.
H
Sorry,
I
didn't
know
if
there
was
a
question
okay,
so
the
the
big
elephant-ish
thing
in
the
room
is:
do
we
mandate
using
revision
labels
for
ietf
modules
and
do
we
mandate
using
yang
simvar
as
the
scheme
for
those
revision
labels?
Thus
far,
the
authors
and
contributors
on
these
weekly
calls
have
said.
Yes,
the
reason
being
the
primary
reason
is
it.
H
It
allows
human
beings
to
look
at
two
different
modules,
quickly
or
sorry,
revisions
of
the
same
module
quickly
and
see
that
you
know
what
there
are
differences
here
and-
and
I
may
need
to
use
some
more
tooling
and
dig
a
little
bit
deeper
to
understand
the
true
nuances
of
those
differences.
H
But
at
a
glance,
if
you
have
two
revisions
of
the
module,
you
know
whether
or
not
they're
backwards
compatible
or
if
there
are
difference
or
what
level
of
differences
there
are
and
then
the
second
like
addendum
to
this
question
is
there
are
some
iana
controlled
modules?
Should
they
also
use
this
yang
simvar
revision
label?
Admitting
the
rules
will
probably
be
much
simpler
here
because
we're
not
necessarily
expecting
any
nbc
changes,
but
those
are
the
open
questions.
In
addition
to
the
white
space
thing,
we
we
already
raised
a
rashad
raised
for
yang
simver
comments.
D
So
we
are
running
out
of
time
and
I
I
welcome
anybody
to.
Please
come
to
the
mic
and
if
you
have
a
question
in
this,
do
so,
while
I'm
switching
slides
and
okay
great
you're
gonna.
If
you
could
come
to
the
queue
I'll
come
to
the
mic,.
A
A
I
I
I've
posted
all
the
issues
to
the
list.
So
it's
it's
good.
If
people
actually
follow
up
on
on
the
list,
if
they
have
specific
commands
because
we're
running
short
on
time,
the
first
one
is
the
young
date,
which
is
more
like
a
reminder.
There
was
also
no
comment
on
the
list.
Essentially,
the
the
change
that
is
being
proposed
is
to
make
the
time
zone
optional.
I
At
the
moment
the
date
has
a
mandatory
time
zone
and
that
kind
of
limits
certain
use
usages
of
the
type,
and
so
the
proposal
is
to
make
that
actually
optional
and
add
additional
clarifying
text
what
it
means.
If
you
don't
have
the
time
zone
I
there
was,
there
was
no
comments.
I
believe
people
wait
for
my
edits
and
that's
it
go
to
the
next
slide.
Please
there
was
a
discussion
issue
on
the
xpath
definition,
which
is
a
little
bit
xml,
encoding,
specific
and
doesn't
really
say
anything
about
what
happens.
I
If
you
have
expressions
that
where
the
prefixes
are
not
necessarily
xml
prefixes
but
might
actually
be
something
different,
this
is
a
bigger
issue
that
young
has,
because
it
originally
it's
so
so
when
it
comes
also
to
the
node
instance
identifier,
it's
a
little
bit
xml
specific
in
that
space,
and
at
the
moment
it
seems
the
the
best
option
is
to
not
do
anything
at
this
point
in
time
and
to
rather
wait
until
young
next
has
probably
resolved
that
issue,
and
so
my
proposal
is
to
leave
the
definition
as
it
is
essentially
waiting
for
for
young
next
to
eventually
clear
this
up
next
issue.
I
I
Now
it
has
the
same
issue,
it's
kind
of
xml
specific
and
it
has
little
details
in
there
and
the
proposal
I'm
making
is
to
do
exactly
the
same
to
not
copy
it
over
at
this
point
in
time.
So
if
people
want
to
use
node
instance
identifier,
they
would
import
it
from
nakam
as
they
do
now,
and
to
rather
wait
until
young
next
has
resolved
the
issue
and
then
probably
have
a
new
definition
that
is
consistent
with
what
the
young
next
solution
in
this
space
is
slide.
Number
five.
I
People
suggested
to
add
longitude
latitude,
which
I
think
we
should
not
add,
because
we
have
a
separate
document,
even
though
it
doesn't
really
define
types
it
defines
groupings.
So
I
don't
really
know
the
details,
whether
there's
an
issue
with
that,
but
I
believe
we
should
now
that
we
have
a
separate
document.
We
should
actually
put
those
definitions.
There
also
proposed
was
postal
code
and
country
code,
which
I
started
to
look
up,
whether
there's
official
definitions,
how
these
are
structured
so
for
posts
for
country
codes.
I
I
I
I
I
believe
it's
so
simple
to
define
this
type.
Then
it's
probably
not
useful
to
come
up
with
a
set
of
percentage
types
definitions
that
might
be
generally
useful.
So
I
would
again
my
proposal
is
to
not
add
a
percentage
type.
If
you
need
a
integer,
1
0
to
100
range
type,
there
is
one
and
for
the
other
ones,
just
roll
your
own
one
slide
number
seven.
I
I
The
issue
was
that
the
host
name
was
just
a
domain
name,
which
is
a
sequence
of
a
labels,
and
there
are
additional
restrictions
for
host
name.
For
instance,
you
you're
not
allowed
to
have
an
underscore
in
there
and
I
wasn't
really
captured,
and
so
what
this
type
dev
does
is
capturing
that
so
hostname
is
restricted
to
letters
and
digits
on
dashes
and
dots
and
there's
a
requirement
that
a
hostname
has
to
be
at
least
two
characters,
long,
which
is
captured
here.
I
We
ended
up
having
a
site
discussion
about
internationalized
domain
names.
So
the
way
you
you
represent,
an
initial
internationalized
domain
name
is
currently
using
the
the
ascii
compatible
encoding,
which
is
not
extreme,
not
very
convenient,
and
so
we
today
had
a
discussion
with
between
lara
and
myself
to
probably
have
a
second
definition
that
that
allows
to
represent
internationalized
domain
names.
I
So
I
think
we
are
reaching
agreement
on
what
to
do,
and
I
think
I
understand
the
edits,
so
I
will
put
something
into
the
next
revision
slide.
8.
I
There
was
a
suggestion
I
think
it
was
originally
coming
from
kent
to
add
an
email
address
definition
and
the
best
thing
that
probably
can
be
done
is
to
to
use
the
address
back.
That's
also
used
in
the
mailto
url
scheme,
and
that
has
a
number
of
formats,
but
at
the
moment
the
definition
doesn't
really
capture
all
of
them,
and
so
there's
work
to
be
done
to
to
capture
in
the
regular
expression,
all
the
different
formats
that
address
back
allows,
and
so
what
I
need
to
do
is
it's
homework.
I
It's
that's
tweaking
regular
expressions
to
get
them
right
and
actually
I
have
a
separate
collection
of
test
cases
and
I
probably
need
to
to
write
up
enough
test
cases
to
make
sure
that
the
pattern
actually
gets.
Does
the
right
thing
if
anybody
wants
to
help
with
this
yeah
send
me
an
email
help
and
getting
this
right
as
well
slide.
Number
nine.
I
There
was
a
proposal
to
add,
there's
a
ui
type
and
there
was
a
proposal
to
actually
have
a
broken
out
version,
so
you
have
the
uan
scheme
and
the
ui
authority
and
the
ui
path
and
ui
query.
There
are
some
technical
issues.
The
the
non-technical
issue
is
that
it's
not
clear
to
me
how
commonly
used
those
data
types
would
be.
It
was
only
suggested
once
and
then
nobody
ever
said
yeah.
I
really
need
this.
I
Loopback
addresses
that
was
the
the
last.
The
latest
request
that
came
in
so
some
people
have
a
need
to
represent
loopback
addresses
and
that's
a
very
fairly
special
kind
of
address,
for,
if
you
think
about
configuration,
usually
you
don't
even
configure
loopback
addresses
they
just
are
system
assigned,
but
anyway
there
seems
to
be
an
mpls
thingy
that
actually
uses
loopback
addresses,
and
I
could
add
those
in.
I
don't
know
how
commonly
used
they
will
be,
I'm
pretty
neutral
on
this.
I
D
Great
and
I
think
with
the
two
minutes-
maybe
we
can
try
to
bring
up
the
next
presentation.
I
know
it's
not
really
there
enough
time
for
them,
but
I'll
start
queuing
up
those
slides
in
the
background.
J
J
J
So
my
idea,
actually
the
problem
we
want
to
saw
is
we
already
can
you
know
achieve
many
seconds
or
seconds
data
connection
rate,
but
facing
massive
data
connection
processing.
Actually,
it
may
overload
the
network
device
and
consume
too
much
resource.
So
what
we
try
to
do
is
we
can
actually
tag
the
telemetry
data
to
capture
key
feature
data
and
we
can
provide
a
better
nano
visibility
and
next
yeah.
So
the
in
sensor
there
is
a
draft
actually
is
provided.
J
10
meter
data
classification,
the
key
parameter
will
propose
like
a
opm
tag.
It
can
classify
telemetry
data
into
object,
type
property
metric
and
metro
can
be
also
seen
as
a
kpi
data
it.
Actually,
if
it
is
a
kpi
data.
Actually,
we
also
can
specify
operation
type
and
range
of
the
kpi
data
and
provide
granularity
the
metric
unit,
and
we
also
can
classify
the
telemetry
data
from
data
source
type
and
and
basic
data
data
source
type
and
also
if
the
kpi
data
can
come
from
different
source.
J
D
Can
ken
we're
about
to
get
cut
off,
and
I
think
it's
probably
best
that
we
just
stop
here
and
we'll
have
to
pick
up
this
discussion
on
the
list.
I
think
and
okay.
J
D
A
This
one
and
planning
do
an
adoption
call.
I
think
I
will
ask
the
adoption
call
what
part
is
covered
by
ipr,
just
so
that
the
group
understands
what
is
being.
D
And
I
think
similar
work
was
being
presented
in
metconf.
We
probably
should
look
to
see.
What's
the
level
of
the
importance
of
the.
J
D
Okay,
sorry,
for
at
least
we
were
able
to
give
you
that
a
little
bit.
Thank
you,
everybody
for
joining,
and
I
will
send
minutes
to
the
list
when
they're
ready
and
pick
up
on
the
discussions
there
for
all
the
other
items.