►
From YouTube: IETF111-NETMOD-20210727-2130
Description
NETMOD meeting session at IETF111
2021/07/27 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
Hello
and
welcome
to
ietf
111
netmod
working
group
online.
I
appreciate
everyone
being
here
in
whatever
time
zone
you're
in
and
whatever
position
that
may
or
may
not
compose
I'm
lou
berger,
I'm
here
with
my
co-chairs,
kent
watson
and
joel
dugley,
and
if
you're
listening
to
us,
obviously
you've
found
the
right
place.
Well,
hopefully,
next
slide,
please.
A
As
an
ietf
meeting,
we
are
covered
by
a
certain
code
of
conduct,
as
well
as
policies
related
to
our
contributions
to
the
ietf,
and
all
activity
here
is
being
recorded
and
becomes
part
of
our
public
record.
I
hope
you're
familiar
with
the
note.
Well,
if
you're
not
take
a
look
at
the
slides
and
even
better,
take
a
look
at
the
link
at
the
bottom
of
the
page
itf.org
about
noteweld
html.
That
really
will
go
into
all
the
policies
and
procedures
related
to
conduct
and
the
disclosure
for
the
ietf.
Next.
A
So
we're
here
again
on
need
echo.
We
are
using
integrated,
chat
and
jabber
that
there's
a
nice
pop-out
feature
if
you
like
that
blue
sheets
are
automatic,
so
you
don't
have
to
do
anything
for
that.
If
you're
part
of
media
meet
echo,
we're
using
the
kodi
md
minute,
taking
there's
a
link
right
at
the
start
of
the
chat,
so
you
want
an
easy
way
to
find
it.
That
also
has
links
to
the
needy
materials
and
all
the
other
session
related
links.
A
Please
go
to
the
code
emd
to
help
capture
comments
that
are
being
made
and
also
that
the
comments
you
make
are
appropriately
captured.
I'm
being
told
I
have
some
audio
problems.
Hopefully
this
corrects
it
I'm
not
sure
what's
going
on,
but
if,
if
it's
not
adequate,
we
can
switch
one
like
compares
something
in
next.
A
Our
agenda,
it
is
not
overly
tight,
but
we
do
only
have
one
hour.
I'm
sure
we
will
feel
tight
at
that
we're
running
late.
At
the
end,
we
we
do
have
a
countdown
timer
that
we're
going
to
try
to
use
this
session
for
the
chartered
items
for
that
30
minute
block
we're
actually
just
going
to
put
up
as
much
time
as
left
for
that
group
and
they
can
divide
among
themselves,
and
we
have
one
non-chartered
item
next.
Please.
A
And
oh
right
document
update,
so
we
don't
have
any
rfcs
recently
published.
Of
course
we
like
seeing
things
published,
because
that
means
we've
done
our
job,
because
that's
what
we're
here
for
the
we
do
have
one
document
that
was
returned
returned
from
the
editor
queue
to
the
working
group:
hentais
the
shepherd.
A
Basically,
that
document
was
put
forward
a
long
time
ago
and
it
was
waiting
on
a
reference
and
that
the
document
that
it
was
referring
to
changed
and
because
of
that
change,
it
needs
to
come
back
and
the
document
needs
to
be
aligned
with
that
reference.
Of
course,
that's
why
it
was
sitting
in
miss
rough.
A
These
things
do
happen
occasionally
so
we'll
come
back
and
hopefully
have
energy
to
complete
that
document.
We
do
have
several
documents
that
went
to
the
isg
for
publication
and
the
only
one
that
really
is
interesting
there
is
is.
I
want
to
point
out
to
the
nmda
diff
authors
that
they
were
waiting
on
a
comment
back
from
you
or
an
update
from
you.
B
B
A
That's
great,
if
you
didn't
send
a
list,
especially
saying
that
you
know
the
action
item
has
been
addressed.
Please
do
so.
I'm
actually.
A
It's
best
to
go
to
the
person
who
raised
the
issue
joel's
the
shepherd
he
may
know
off
the
top
of
his
head.
Who
raised
that
issue?
I
don't
I
don't
remember
quite
honestly,
but
it's
good
to
go
back
to
the
person
who
raised
the
issue
and
say
that
you've
addressed
their
comments
and
you
know
please
go
ahead
and
clear.
Your
discuss
usually
there's
a
disgust
associated
with
it.
C
Thanks
we.
A
D
So,
just
in
the
enemy
nmda
diff
draft-
I
think
that's
post
isg
review
and
it
looks
like
there's
no
discuss
is
blocking
it's
just
the
comments.
They've
been
raised,
no
objection
comments,
so
if
they've
all
been
addressed,
I
can
check
the
document
and
then
I
think
that
I
can
go
forward.
A
D
Yeah,
yes,
so
they're,
both
they're,
both
waiting
me
to
update
and
I
still
struggle
to
find
the
time
to
do
it,
and
particularly
the
sub
interface
vlan
model.
I
have
had
further
comments
from
ieee
on
what
I
need
to
do
resolve.
I
can't
remember
those
before
the
last
itf
or
not,
but
I
just
need
to
update
those
and
resolve
that
with
them.
D
A
Me
no
worries,
we
understand
the
workload
you
might
want
to
consider
taking
that
person
up
on
their
added
help.
D
And
I
can.
I
can
also
give
a
quick
update
on
the
other
two
drafts
there,
so
the
geolocation
document
that
one's
got
discuss
on
there
from
ben
kadek.
D
I've
chatted
with
him
yesterday
about
his
disgust,
and
I
think,
he's
he's
planning
to
send
some
proposed
texts,
hopefully
to
resolve
that
with
chris.
I
I'm
not,
I
have
it
might
be.
The
other
thing
to
do
chris
is,
if
you
are
able
to
meet
up
in
jab,
gather
dot
town
at
some
point
with
ben.
Maybe
we
can
resolve
it
verbally
to
work
out
what
what
the
next
step
is
to
clear
that
discuss
and
then
the
yang
instance
file
format.
D
One
that's
had
a
comment,
I
think
from
andy
biehmann
that
we
need
to
resolve,
and
hopefully
that
should
be
too
tricky
and
then
then
I
can
take
that
on
to
the
ice
g
or
work
itef
law,
school.
A
A
Next
slide,
we've
got
no
incoming
liaisons
or
communications.
As
always,
we
ask
if
there's
anything,
that's
needed
that
to
be
discussed
during
the
meeting
was
a
holdover
that
should
have
been
deleted.
My
bad
apologies
on
that
next
slide,
so
we
continue
to
work
remote.
We
want
to
remind
everyone
that
our
mailing
list
is
where
we
gauge
consensus.
A
We
do
want
to
remind
everyone
that
we
get.
We
can
have
virtual
meetings,
both
informal
and
formal.
All
it
takes
is
a
request
to
us
the
chairs
and
we
will
set
it
up,
and
hopefully,
we've
been
responsive
on
that.
The
the
the
the
versioning
topic
continues
to
be
a
you
know,
a
hot
item
and
substantial
work.
If
there's
reasons
to
ask
for
an
interim
there,
we'd
look
to
the
authors
to
do
that
or
even
working
group
participants,
but
that's
something
just
to
keep
in
mind
next.
F
Okay,
so
I'm
doing
kind
of
an
update
on
a
general
update
on
the
the
versioning
work.
I
guess,
as
far
as
I
guess,
maybe
a
question
for
the
chairs
before
I
get
in
too
far
here,
who's
gonna
manage
the
the
queue
of
questions.
F
Okay,
maybe
to
start
I'll,
let
you
guys
manage
it
and
feel
free
to
jump
in
when
you
think,
like
just
just
interrupt
me
when
you
think
it's
needed
at
any
time,
I'll,
try
to
pause
and
and
see
if
there's
anything
in
the
queue
as
I
go
along
as
well.
A
Okay,
any
questions
as
people
show
up
or
do
you
want
to
take
it
at
the
end
end
of
each
section.
F
F
Okay,
next
slide,
please
so
there's
three
presentations
going
to
occur
on
the
versioning
work.
I'm
gonna
give
an
overview,
that's
this
presentation
and
then
the
next
ones
we're
going
to
give
a
specific
update
on
the
module
versioning
draft
I'll.
Do
that
one
and
then
joe's
going
to
give
an
update
on
the
yang
semverdraft
next
slide.
Please.
F
The
next
bunch
of
slides
are
just
kind
of
a
review
for
people
to
remember.
What's
going
on
with
all
the
versioning
we're
kind
of
we're
focused
on
five
main
drafts
that
are
part
of
the
work
that
we
kind
of
target
to
to
to
bring
all
these
to
rfc.
F
Eventually,
the
first
two
are
the
ones
we've
been
most
focused
on
for
the
last
last,
while
trying
to
get
those
ready
for
working
group
last
call,
but
there's
there's
been
some
work
on
the
other
drafts
as
well.
So
the
first
draft
here
is
kind
of
the
basics
of
module
revision
handling.
F
F
Way
of
indicating
a
yang
revision,
rather
than
just
using
a
revision
date,
there's
kind
of
a
semver-like
label,
so
you
can
have
a
major
minor
editorial
version
and
then
packages
basically
allows
you
to
specify
kind
of
a
collection
of
modules
that
form
a
schema
and
a
server
can
advertise
an
entire
package
saying
you
know.
I
support
this
package
with
all
these
different
with
a
specific
list
of
modules
and
versions.
F
The
fourth
draft
is:
is
a
is
a
scheme
for
allowing
a
client
to
actually
ask
to
select
which
version
of
a
schema
they
want
to
use,
so
a
server
can
advertise
and
say
hey.
I
support
version,
1
and
version
2
of
my
schema
and
the
client
could
actually
say.
Well,
I
want
to
stick
with
the
my
good
old
version,
one
I
don't
want
to
have
to
move
to
your
version
two
and
then.
Finally,
the
fifth
draft
here
is
some.
F
F
So
the
next
four
slides
are
just
a
little
bit
more
detail
just
to
remind
everybody
kind
of
the
main
points
we're
dealing
with
in
the
first
two
drafts
here.
So
these
are
kind
of
our
main
two
drafts.
They
specify
the
the
bulk
of
the
versioning
changes,
the
really
the
the
basics
of
the
versioning
changes
not
really
intended
to
have
much
discussion
here.
F
It's
just
to
remind
people
kind
of
what
are
the
main
parts
of
of
these
two
drafts,
so
this
first
slide
shows
that
one
of
the
first
things
we've
done
is,
if
you
look
over
in
the
revision
history
whoops,
a
lot
of
yellow
highlight
happened,
but
we've
added
this
rev
non-backwards
compatible
tag
into
the
into
the
revision
history,
and
so
you
can.
You
can
look
at
the
revision
history
of
a
module
and
see
back
in
the
lineage
of
that
module.
F
F
Another
interesting
part
of
the
first
two
drafts
is
we're
adding
some
a
bit
of
evolution
to
how
import
is
done
by
version.
So
today,
in
7950,
there's
some
problematic
aspects
to
how
import
is
done
by
version.
It's
only
an
exact
version
which
has
a
lot
of
problems
in
in
real
life,
so
we've
added
a
new
import
by
revision
or
derived,
which
is
basically
saying
you
know
this.
This
module
can
import
the
example
module
and
it
can
be
any
version
300
or
any
descendant
of
that
version.
F
So
kind
of
the
third
thing
I'm
going
to
point
out
here
out
of
out
of
the
four
items.
The
next
thing
that's
fairly
significant
is
we're
adding
a
new
what
we
call
the
yang
semver
revision
label.
F
F
F
I
would
encourage
you
to
take
a
look
at
the
draft,
there's
a
fair
bit
of
detail
in
the
latest
draft
on
how
that
non-compatible
tag
works
and
then,
finally,
the
last
bit
of
kind
of
just
review
here
on
the
next
slide
is
again.
This
is
an
optional
part,
but
if
you
know
you're
going
to
be
using
yang
semver
as
kind
of
your
identifier
for
a
unique
version
of
a
module,
we've
kind
of
specified
a
file
name
recommendation
with
a
hash
and
then
december
at
the
end.
F
So
that's
just
a
recap
of
kind
of
the
the
bulk
of
the
concepts
that
are
in
the
first
two
drafts.
We're
really
focused
on
right
now,
I'll
maybe
pause
there.
I
don't
want
to
spend
too
much
time
reviewing
what
these
are,
but
I
could,
I
could
probably
probably
do
a
couple
of
questions
if
there's
some
something
for
related
to
these
slides
so
far,.
G
C
G
C
Yes
and
since
I'm
also
driving
the
slides
I'll
just
quickly
go
back
to
the
one
number,
the
second
item
you
mentioned.
Sorry
here,
you
said
import
by
revision
or
derived
what
happens
if
the
derived
version
actually
breaks
backwards,
compatibility.
F
So
the
quick
answer
is
there
was
quite
a
bit
of
debate
over
that
and
we,
we
were
looking
at
one
point
about
having
two
different
extensions:
one
was
revision
or
derived,
and
one
was
revision
or
derived
compatible,
but
in
the
end
we
decided
to
kind
of
keep
it
simple
and
we
think
the
majority
of
the
realistic
use
cases
don't
require
a
derived
or
compatible.
F
F
Even
though
there's
nbc
changes
in
that
module,
there's
going
to
be
a
lot
of
times,
they
won't
affect
the
modules
that
are
importing,
that
module
and
also,
if
we
say,
derived
or
compatible
we'll,
be
forced
to
go
back
and
update
all
the
importing
modules
that
use
that
if
we
ever
do
issue
a
version
of
the
imported
module
with
an
nbc
change.
Even
if
that
npc
change
doesn't
affect
any
of
the
importing
modules.
C
Take
this
offline,
but
it's
been
just
discussed.
That's
the
main
thing.
F
Okay
next
slide,
so
we
have
we're
having
weekly
calls
and
we
send
out
minutes
of
those
to
the
netmod
group.
Along
with
how
to
join
the
call
there's
we
we
have
a
fairly
it's
a
the
call
happens
pretty
much
every
week,
definitely
open
to
anyone
who
wants
to
join.
We
do
have
regular
participation
from
a
set
of
probably
five
to
seven
people
across
five
different
companies.
Right
now.
It's
mostly
equipment
vendors.
F
There
is
some
participation
from
operators,
so
I
know
like
tom
hill's
joined
from
bt
a
number
of
times
and
a
few
others,
but
it
would
be
really
good
to
get
more
users
of
modules
and
operators
to
participate
in
those
calls.
F
So
certainly
the
weekly
minutes
are
there,
and
then
we
try
to
kind
of
summarize
any
key
issues
that
we
close
back
on
the
working
group
list
and
we're
definitely
focused
on
the
on
the
module
versioning
in
the
angsember
drafts,
which
were
the
first
two
in
that
list
and
those
are
getting
pretty
close
to
complete
at
this
point.
So
most
of
the
issues
have
been
closed.
We've
made
we've
made
now
not.
F
Just
put
in
people's
minds,
but
we're
going
to
come
back
and
discuss
this
at
the
end
of
our
time,
so
because
this
could
just
chew
up
the
whole
rest
of
the
of
our
30
minutes
and
just
want
to
have
people
to
have
this
in
mind
when
we
go
through
the
next
two
updates
on
the
first
two
drafts,
so
one
of
the
I
mean
we
did
adopt
this
work
in
netmod
there's.
F
Definitely
you
know
agreement
that
we
have
a
real
problem
with
yang,
both
in
in
in
vendor
modules,
especially
but
even
in
standardized
modules
that
that
need
some,
some
additional
evolution
in
how
we
manage
versioning
for
yang
modules.
So
we
did
adopt
the
work,
but
definitely
a
question
has
kind
of
reared
its
head
a
few
times
and
and
and
and
has
come
up
again,
and
that
is
do
we
should
we
adopt
these
drafts,
bring
them
right
to
rfc,
as
updates
and
extensions
of
yang
1.1.
F
F
You
know
yang
2.0,
along
with
dozens
of
potential
other
improvements,
we're
discussing
for
yang,
2.0
or
actually,
maybe
not
so
much
not
discussing
at
the
moment,
but
we'll
be
discussing
so
so
option
b
would
be
a
fairly
long
road
to
getting
any
of
these
evolutions.
F
F
So
these
are
a
few
options
we
could
consider.
The
the
versioning
call
group
is
is
proposing
that
that
this
is
should
be
an
extension
to
yang
1.1.
F
I
know
we
don't
have
consensus
for
that
necessarily
across
the
working
group
at
the
moment,
but
we
are
really
proposing
that
this.
This
work
is
worthwhile
to
add
to
1.1
without
waiting
for
a
yang
next
or
having
to
spin
to
a
yang
1.2.
F
F
Okay,
yeah:
let's
come
back
to
that,
is
there
one
more
slide?
Okay,
so
next
steps
we're
tracking
everything
in
github
with
the
link
here.
So
you
can
see
the
issues,
the
detailed
issue
discussions
and
we
bring
anything
important
back
to
the
working
group
mailing
list
and
our
next
steps
is
we're
trying
to
wrap
up
these
first
two
drafts
get
them.
F
Baselined,
probably
go
to
working
group
last
call
on
them
and
then
hold
them,
and
then
we're
gonna
move
on
to
packages
and
try
to
try
to
work
on
start
more
focused
work
on
that
shortly
after
itf
111..
F
Okay,
that's
it
for
the
overview.
The
next
presentation,
I'll
also
be
presenting,
is
focused
on
the
module
versioning.
F
F
Okay,
so
first
give
a
summary
of
some
significant
things
that
have
happened
since
itf
110.
F
So
one
of
the
first
changes
is
there
was
a
lot
of
debate
and
discussion
around
what
we
should
do
for
state
data
for
non-config
data.
But
after
discussion,
including
a
number
of
people
in
the
work
working
group,
we
really
it
seemed.
It
made
sense
to
keep
specific
rules
for
non-config
nodes
out
of
scope
of
this
work.
F
So
basically
we
we
had
started
going
down
the
path
of
providing
a
number
of
different
rules
for
state,
which
was
a
bit
different
from
the
rfc
7950
approach,
which
kind
of
has
just
a
set
of
common
rules,
and
we
decided
we're
going
to
just
leave,
leave
it
like
79.50.
As
far
as
the
difference
between
config
and
state.
It's
just
a
single
set
of
rules-
and
this
you
know
having
something
very
specific
and
different
rules
for
state-
is
something
that
we'd
proposed
should
be
tackled
for
in
yang
next.
F
The
second
actually
I'll
pause
there
in
case
there's
a
question
about
that.
First,
one.
F
So
if
you
as
an
author,
want
to
publish
and
make
available
kind
of
a
cleaned
up
version
of
your
module
that
just
fixes
white
spaces
and
and
formatting
etc,
you
can
do
that,
but
it
needs
a
new
revision
date.
It
needs
a
new
label,
so
you
can
clearly
identify
well,
which,
which
version
of
the
module
you
talking
about
so
it
it
kind
of
means
that
the
revision
label
effectively
represents
the
file
version,
not
necessarily
just
the
schema.
F
F
Slide:
okay,
I'm
gonna
move
on
to
the
next
one:
okay,
a
few
more
updates
yeah.
So
the
third
item
here
is:
what
is
the
impact
of
changing
an
extension
statement
in
your
draft.
So
if
you're,
if
you're
using
some
some
yang
extension
and
you
change
the
extension-
not
the
definition
of
the
extension,
but
you
change
the
your
use
of
the
extension
statement-
it's
it's
not
necessarily
clear
whether
that's
backwards
compatible
on
backwards
compatible.
F
F
F
This
was
based
on
some
feedback
from
the
semiver
community
to
say:
non-backwards
compatible,
so
it's
fairly
minor
but
hopefully
will
help
with
clarity
and
then
the
fifth
item
here
is:
we
had
a
we
kind
of
had
a
mix
of
using
the
terms,
module
and
submodules
in
the
draft,
so
we
we
did
a
bit
of
cleanup
there
to
make
sure
that
the
right
terms
are
used
where,
where
appropriate,
so
some
places
just
mentioned
modules,
some
places,
mention
modules
or
sub
modules,
as
as
appropriate
in
the
draft
next
slide.
F
And
then
this
is
the
last
change
again.
This
is
this
was
kind
of
this
decision
was
made
at
ietf,
110
and
and
and
and
on
the
on
the
list
shortly
after,
but
we
just
clarified
that
when
the
non-backwards
compatible
extension
can
be
added,
so
basically
it
must
be
added
if
there's
a
known
and
nbc
change
and
a
revision
that
only
contains
backwards.
F
Compatibles
shouldn't
include
it,
but
there
are
cases
where
an
author
is
free
to
add
it
if
they
believe
a
change
could
negatively
impact
clients,
even
though,
strictly
by
the
rules
defined
in
the
in
the
rfc
in
our
drafts-
and
maybe
tools
might
say,
it's
identical,
but
an
author
may
know
that
actually
there's
a
there's,
a
change
there
that
may
impact
backwards,
compatibility
and
or
or
a
change
that
isn't
clear,
whether
it
impacts
backwards,
compatibility
and
we'd,
rather
err
towards
flagging
it.
F
So
I
think
that
was
the
last
slide
for
this
deck.
Maybe
there's
a
next
steps
open
issues,
I
don't
yeah,
so
there's
no
major
open
issues.
The
authors
want
to
do
one
last
kind
of
top-down
review,
but
we
expect
to
do
working
group
last
call
the
document's
ready
for
that
pretty
soon
and
then
I'll
hand
over
to
joe.
F
H
H
Can
you
hear
me
here,
you
go
joe
okay
good
took
a
delay.
I
guess
well!
Thank
you.
Yes,
so
jason
set
me
up
rather
nicely
in
terms
of
introduction.
So
next
slide
please.
H
So
here
we
have
the
the
yang
simver
draft
and
its
current
status
is,
you
may
have
if
you
were
at
110.
You
know
that
we
talked
about
coming
up
with
text
to
describe
a
pre-release
precedence.
That
is
I'll
talk
about
it.
I
have
a
slide
after
this
on
that
we'll
dig
a
little
bit
more
into
that.
We
also
clarified
when
a
major
or
minor
digit
should
versus
must
be
incremented.
H
This
was
documented
in
issue
78
on
github.
We
wanted
to
recognize
the
fact
that
some
module
authors
may
want
to
increment
the
major
version
number
when
in
fact
just
backwards
compatible
changes
had
been
put
in
only
backwards,
compatible
changes
for
various
reasons
like
there
was
some
implementation
changes
and
they
wanted
to
stress
that
more
attention
should
be
paid.
So
we
we
added
some
some
text,
some
clarity
around
that
as
well.
H
One
of
the
funnier
things
that
came
up
that
was
brought
to
us
brought
to
our
attention
by
a
member
of
the
semver
community,
was
that
simber
2.0.0,
which
we've
been
pontificating
about
for
so
long,
was
in
fact
changing
and
over
the
past
five
or
so
years
changed
in
a
number
of
even
normative
ways
without
changing
the
the
2.0.0
version.
So
it
should
have
probably
gone
to
2.1.0
at
some
point
based
on
the
changes
they
made,
maybe
even
a
a
3.0.
H
But
what
I
did
was
I
went
back
and
and
found
kind
of
where
we
had
the
the
authors
had
and
what
we
had
discussed
with
the
working
group,
where
we
kind
of
landed
on
a
stable
revision
of
that
and
the
x
ref.
Now
as
you'll
see,
we,
we
statically
referenced
that
in
their
in
their
github
or
in
their
git
repository,
and
we
also
recognize
that
when
reading
through
the
the
text
we
yang
simber.
H
This
draft
introduces
this
this
terminology
artifact,
because
we
also
can
use
yang
simvir
to
apply
to
the
packages
the
yang
packages
which
we
haven't
talked
about
in
a
while.
But
that's
still
part
of
this
work,
and
but
when
we
were
talking
about
modules
in
the
yang
symbol
draft
we
only
mentioned
modules
and
it
really
in
many
ways
applied
to
both
module
and
or
sub
module.
So
we
we
adjusted
the
text
there
to
also
mention
some
module
where
appropriate.
H
Now
the
last
bullet,
there
is
actually
a
lie
at
this
point
today
the
the
group
of
contributors
went
through
the
open
issues
on
github
and
we
did
find
some
as
we
as
we
get
close
to
that
finish
line.
We
did
find
some
issues
that
we
wanted
to
tag
with,
respect
to
gang
simver
and
go
back
and
revisit.
Some
of
them
have
been
fixed
since
in
our
github
repository,
but
the
the
version
that
has
been
submitted
to
the
working
group
currently
for
review
doesn't
have
them.
H
So
there
are
still
a
few
issues
that
we
want
to
get
to.
So
that's,
not
all
of
them
are
closed,
but
the
the
link
that
jason
shared
for
the
github
issue
list
will
show
you
what
is
currently
now
open
for
semver
next
slide.
Please
all
right!
So
pre-release
precedence
just
to
remind
you
what
pre-release
precedence
is
talking
about.
We
had
this
issue
where
a
module
might
go
from
1.0.0,
then
the
the
initial
vision
was
that
there
will
be
a
2.0
we're
going
to
make
some
non-backwards
compatible
changes
in
this.
H
So
we're
going
to
the
first
pre-release
version
will
be
called
2.0.0
pre-release,
then,
as
the
the
team
or
author
working
on
that
that
module
as
they
put
the
work
in
they
decided,
you
know
what
this
isn't
really
going
to
be
a
2.0
we're
not
going
to
make
those
non-backwards
compatible
changes.
Instead,
we're
going
to
it's
just
going
to
we're
going
to
add
some
features.
So
it's
going
to
be
a
minor
increment
of
the
version,
so
it'll
be
a
1.1.0
ultimately.
H
Well,
that's
all
well
and
good,
but
if,
if
someone
is
tracking
the
pre-release
version,
what
they
see
is
2.0.0
pre-release
becomes
1.1.0,
prerelease
and
there's
some
confusion
as
to
which
of
those
is,
is
technically
greater.
So
the
the
clarity
that
we
added
in
in
the
document.
The
two
salient
points
are
there
on
the
subsequent
bullets.
Authors
should
maintain
only
one
revision
statement
in
a
pre-release
module
that
reflects
the
latest
revision.
H
This
is
because
you
can
take
either
one
of
those
prerelease
versions,
2.0.0
pre-release
or
1.1.0
pre-release,
and
you
can
easily
compare
that
back
to
1.0.0
the
last
ratified
or
quote-unquote
released
version
of
the
module,
and
you
can
say
that
1.1.0
is
not
only
greater,
but
you
understand
from
december
rules
that
there's
only
additional
changes
or
there's
there's
additions
made
to
it,
whereas
2.0.0
prerelease
you,
you
may
suspect
there
might
be
non-backwards
compatible
changes
in
there.
H
The
second
salient
point:
there
is
with
respect
to
ietf
modules,
the
authors,
the
itf
authors,
may
choose
to
use
the
appendix
in
the
associated
draft
to
track
those
overall
changes.
So
while
the
pre-release
module
just
has
the
the
current
pre-release
revision,
the
authors
can
can
do
like
they're
doing
now
and
use
the
appendix
to
track
those
changes.
H
I
don't
see
him
in
the
queue
so
next
slide.
Please
kent!
Yes,
the
the
irony
the
irony
is
dripping.
So
what
we
did
was
we
went
back
and
looked
at
github
and
looked
at
where
kind
of
the
the
the
changes
that
had
come
in
and
instead
of
we,
we
picked
up
essentially
all
of
the
changes,
because
all
of
them
were
relative
to
where
we
really
started
talking
or
the
changes
that
happen
after
that
that
we
started
talking
about
simver
or
really
honing
in
on
the
december
2.0.0
spec.
H
They
were
just
readability.
They
were
editorial
changes
at
that
point,
but
knowing
that
they've
changed
in
in
kind
of
substantial
ways
over
the
past
five
years
means
that
they
could,
in
the
future,
continue
to
change.
So
in
order
to
avoid
that
in
the
future,
where
now
the
xref
anchor
the
target
changed
to
that
june,
19th
2020
revision
of
the
spec.
So
if
the
spec
changes,
that's
fine,
we
we
could
choose.
H
I
guess,
to
to
look
at
newer
ones,
but
for
purposes
of
this
of
this
draft-
and
this
document
were
anchored
to
the
june
19th
2020
revision
next
slide,
please
so
our
next
steps
we
want
to
do.
As
I
mentioned
initially
when
I
wrote
the
the
deck
the
that
bolded
bullet
point
on
that
second
slide
was
true.
Now
we
have
other
issues
to
kind
of
address
and
iron
in
so
we
we
still
want
that
final
top-down
review
from
all
of
the
authors
and
then
we
would
like
to
as
jason
mentioned.
H
We
would
like
to
start
getting
some.
Some
more
working
group
highs
on
this.
So
if,
if
the
desire,
even
if
it's
not
to
go
forward
yet
to
conduct
a
working
group,
last
call
for
this
and
module
versioning,
we
think
might
be
a
a
good
way
to
force
those
eyes
to
look
at
this.
So
we
can
get
that
additional
feedback
that
we
want
on
on
this
and
module
versioning,
and
that
is
the
deck.
So
I
I
will
now
definitely
pause
for
questions.
C
F
F
I
guess
in
the
meantime,
people
can
start
addressing
it.
It's
the
question
of.
Do
we
want
to
bring
this
work
in
and
make
it
part
of
yang
1.1
or
is
there
are
people
concerned?
There's
a
need
to
defer
it.
As
a
reminder,
the
working
group,
the
the
weekly
call
group,
which
which
has
a
you
know
at
least
representation
across
five
different
organizations,
are
pretty
pretty
unanimous
and
feeling
that
we
should
make
this
part
of
yang
1.1
it's
without
it.
F
A
A
Wow,
I
guess
it's
the
day
for
chairs
having
problems
with
mike.
I
we
we
heard
in
the
beginning
part
of
what
you
said
kent.
I
guess
I
should
say
we
particularly.
I
particularly
want
to
hear
from
those
who
oppose,
but
if
you
want
to
support,
that's
fine
as
well.
C
Yeah
I'll
try
again
just
quickly
I'd,
see
no
downside
in
that
when
we
do
yang
next
and
if
it
breaks
backwards
compatibility,
it
can
also
break
backward
compatibility
as
needed
to
adjust,
for
whatever
is
not
going
to
be
done
now.
C
Rashad
I
had
to
kill
your
mic.
There
is
too
much
distortion.
I
could
not
understand
a
word.
You
were
saying.
G
Comment
on
the
question
of
when
and
how
I
completely
support
the
work
I
just
wanted
to
see:
whatever
is
the
fastest
way
of
getting
this
work
standardized,
so
if
it's
1.1
as
so,
we
just
choose
whatever
it
takes
fastest.
There
are
other
studios
that
are
kind
of
watching
and
waiting
for
this
division
labeled
to
be
adopted.
F
Year,
yeah,
I
think
you
know
in
the
meantime
I
know
some
vendors
are
already
going
ahead
and
doing
similar
things
on
their
own
and
the
open,
config
group,
you
know,
went
ahead
with
the
december
on
their
own.
For
some
of
this,
the
other
thing
is
I
can,
I
think
I
can
paraphrase
what
rashad
was
saying.
F
I
believe
he's
just
pointing
out
that
some
of
the
folks
with
with
concerns
about
including
this
as
part
of
yang
1.1,
I
believe,
are
not
on
the
call
today,
so
we
may
be
missing
some
representation
from
those
guys
and
it'll
be
important
to
you
know
as
always,
go
back
to
the
list
on
this
point.
A
Yeah
and
we'll
have
opportunities
both
on
the
list
and
particularly
when
we
last
call
the
documents.
That'll
be
a
good
opportunity
to
I'm
sure
revisit
the
issue,
no
matter
what
list
discussion
ends
up
being.
E
D
Yes,
as
a
contributor,
I
just
got
a
process
a
process
question
on
on
the
next
steps
effectively,
so
these
documents
are
pretty
much
done.
The
authors
want
to
have
a
sort
of
last
review
of
these
a
couple
of
comments.
Some
questions
have
come
up
issues
that
come
up
during
the
chats
and
things.
So
we
need
to
check
those.
D
A
For
either
one
of
us
can
say
the
same
thing,
we
think
you
know
pretty
much
last
call
as
they
are
ready
make
sense
and
that
holding
them
until
we
can
submit
to
isg
as
a
group
is
also
makes
sense.
I
think
we
could
probably
have
some
debate.
This
is
lou
speaking,
not
for
the
other
that
we
probably
have
some
debate
whether
we
submit
the
first
four
or
first
five.
A
You
know
there's
a
little
bit
of
a
gray
area
on
that,
but
certainly
we
can
start
the
last
call
process
as
soon
as
the
authors
think
it's
ready.
A
Moving
on
to
the
next
presentation,
we're
gonna-
we
actually
only
have
about
11
minutes
left.
I
think
that's
what
kent
is
asking
to
do.
So
I
think
we're
on
to
our
last
presenter.
Thanks
for
a
good.
C
Yes,
if
you
could
speak
a
little
bit
later,
though
that'd
be
better.
J
Okay,
okay,
fine!
This
is
hello
everyone.
This
is
chufama
and
so,
on
behalf
of
the
authors
I'm
here
to
present
the
system
configuration
that
handle
behavior,
and
this
work
has
just
been
moved
from
the
net
conflict
group
based
on
cheer
suggestion
next
slide.
Please.
J
J
So
the
reference
that
item
must
be
copied
into
running
to
make
sure
successful
validation,
which
seems
inconvenient
if
the
system
configurations
gets
get
updated,
there
is
nowhere
to
detect
and
synchronize
update
into
running.
J
J
So
here
here
we
introduce
a
system
configuration
data
store
which
is
config
true
and
read
only
to
hold
all
the
system
configurations,
and
our
initial
proposal
was
to
define
two
system
configuration
modes.
One
will
update
running
this
system
automatically
when
the
device
is
powered
on
all
the
physical
results
is
present
and
the
other
will
not
do
the
autocopy
operation
for
the
device
next
slide.
Please.
J
J
Some
high-level
updates,
since
the
last
meeting
will
remove
the
system
configuration
that
handle
it.
A
data
retrieval
behavior
definition
for
now
and
in
order
not
to
cause
any
confusion
and
misunderstanding
with
with
default
mechanism,
we
change
our
terminology
of
system
configuration
data
modes,
just
change
the
report
out
auto
populate
and
explicit
to
non-populate,
and
we
also
consider
the
factory
default
rfc
to
work
with
this
draft
next
slide.
Please.
J
So
when
we
have
a
system
data
store,
is
there
any
alternatives
to
our
proposal?
There
are
some
discussion
about
which
data
style
should
system
be
merged
into.
I
think
there
we
have
three
options:
option
one
is
being
merged
into
operational
to
keep
with
mda
rfc,
but
as
kent
and
I
discussed
on
the
list,
we
think
that
for
some
system
defined
templates
in
system,
this
option
cannot
go
through
the
template
expansion
and
if
the
operators
reference
the
system
configurations,
it
will
not
pass
the
validation
due
to
missing
references.
J
So
the
option
two
is
to
be
merged
into
intended
and
further
into
operational,
so
that
the
system
defined
templates
can
be
expanded
and
the
present
in
the
intended-
and
this
also
enables
intended
to
pass
validation.
But
please
note
that
the
running
itself
here
cannot
be
valid
so
option
three
is
to
merge.
Maybe
a
pattern
of
the
system
into
running
to
make
sure
successful
validation
and
unreferenced
system
configuration
may
also
be
merged
into
operational
directly.
J
But
to
compare
the
option
two
and
option
three
should
running
be
right
here.
Actually
we
find
something
which
seems
a
little
confusing
in
mda
that
is
mda
defines
that
it
is
intended
which
is
subject
to
validation,
but
it
also
says
running
must
also
be
available.
Configuration
data
tree.
J
So
the
question
is
there:
should
the
running
to
the
running
be
valid
here
to
hold
the
reference
the
system
configurations,
so
my
understanding
here
is
that
the
the
validation
intended
just
means
the
configuration
transformation
to
perform
from
running
to
intended,
but
running
still
need
to
be
valid.
That
means
to
satisfy
the
young
model
constraints
defined
in
rfc
7915,
but
this
is
just
my
individual
opinion.
So
any
comments
on
that
on
on
this
slide
before
we
move
to
the
next.
F
Yep
a
couple
of
a
couple
of
issues,
so
I
guess
first
of
all
a
question
about
option:
three
in
option:
three:
if
we
merge
into
the
running,
are
you
proposing
that
all
of
the
system
config,
whether
it's
referenced
or
not
like
everything
in
your
system,
configuration
becomes
part
of
running
and
then
a
a
get
config
of
running?
You
would
see
all
of
that
system
configuration
as
well.
J
Yes,
I
think
this
question
is
what
I
prepared
to
to
present
on
the
next
slide.
This
is
the
folder.
This
is
open,
still
open
and
need
further
discussion
with
opengroup.
I
think.
F
Okay
and
then
my
next
comment
is,
I
recognize
the
issue
you're
hitting
here
about
should
running
be
valid,
because
I
think
we
also,
I
think
we
also
have
a
problem
at
some
point
we'll
need
to
tackle,
and
that
is
with
the
intended
data
store.
F
You
know
the
intention
there
is
to
have,
for
example,
template
expansion
done
between
running
and
intended
and
that
we
haven't
standardized
that
yet,
but
I
I'm
also
a
bit
uncertain
about
how
running
can
be
valid
in
the
presence
of
template
expansion,
because
template
expansion
can,
for
example,
populate
some
mandatory
fields,
so
I
I'm
also
struggling,
and
it
may
be
relevant
to
your
draft
as
well.
As
you
know,
there's
a
number
of
transformations
that
can
happen
between
running
and
intended.
F
Does
that
mean
running
is
not
valid.
We
may
want
to
discuss
it
with
with
template
expansion
as
well
in
mind.
This
seems
like
the
same
problem.
Yeah.
C
Yeah
I
had
the
same
comment
and
I
think
rob
did
you
want
to
say
something
next.
D
Yes,
please
so
I'll
make
a
few
comments.
Actually,
it's
first
of
all
to
say
thank
you
for
bringing
this
work.
I
think
this
is.
I
think
this
is
useful
both
in
the
approach
here
and
also
trying
to
resolve
this
issue,
to
answer
the
one
about
running
being
valid.
That
was
always
a
slight
quirk
or
strangeness
of
the
nmda
architecture.
D
I
think
we
were
trying
to
avoid
changing
the
definition
in
rlc
7950
and
my
interpretation
of
it
effectively
is
that
whenever
you
update
running
you
update
intended
at
the
same
time
and
you
validate
intended
and
effectively
running
is
valid
if
intended
is,
is
valid,
so
it's
halted
by
implication,
it
gets
validated,
it
doesn't
get
validated
separately
or
another
way
of
thinking
about
it
is
logically
running
is
valid
if
all
the
template,
expansion
and
all
that
other
work
is
done,
so
I
think
the
rfc
could
be
clearer,
but
that's
the
way
it
sort
of
makes
sense
in
my
head
in
terms
of
these
choices
here,
I
I
think
to
me
probably
option
two
is
looks
to
me.
D
Like
the
most
the
best
answer
here,
I
would
like
to
try
and
go
back
to
the
original
authors
to
understand
why
we
put
system
into
option
one.
So
we
did
that
for
a
reason.
I
can't
remember
what
the
justification
was
for
doing
that
at
the
time
why
it
feeds
into
there
and
not
fire
up.
So
I
think
that
would
be
worth
seeing.
We
can
figure
that
out
in
terms
of
the
third
option,
I
don't
really
like
system
updating,
running
I'd.
Much
prefer
that
running
is
only
updated
by
clients.
D
So
if
you
have
an
explicit
rpc
to
do
that,
then
I
don't
have
any
issues
or
isn't
it
done
by
edit
configuration,
but
I
wouldn't
like
system
changes
to
automatically
update
running.
I
don't
think
that's
the
right
solution.
C
All
right,
there's
still
a
couple
people
on
cue
and
we
are
running
out
of
time.
So
try
to
keep
your
comments
brief
and
I'm
sorry.
This
discussion
is
probably
the
most
important
takeaway
from
this
conversation,
for
this
presentation
is
one
president:
do
you
want
to
say.
E
We
are
planning
systems
which
don't
have
a
separate
intent
and
data
store.
I
think
that's
a
valid
case
and
in
that
case
option
two
looks
very
strange.
F
Yeah
this
is,
I
don't,
have
a
solution
either,
but
the
other
thing
to
keep
in
mind
with
two
rob
mentioned
that
if,
if
intended
is
valid,
then
we
consider
running
valid
but
that
breaks
offline
validation.
So
if
you
grab
the
running
and
try
up
on
your
client
to
validate
against
your
yang
model,
you
can't
validate
that
unless
you
know
all
the
rules,
a
server
uses
to
expand
from
running
to
intended,
so
that
gets
tricky.
J
J
The
option
one
is
to
copy
the
system
into
running
automatically
when
there
is
any
updates
in
system,
but
but
I
also
know
that
there
are
some
concerns
that
the
behavior
may
violate.
The
definition
of
running
this
running
should
be
totally
controlled
and
driven
by
the
operators,
so
I'm
also
wondering
whether
it's
good
to
define
rfc
option
to
to
copy
the
entire
system
into
running.
J
So
in
this
way,
it's
totally
driven
by
the
operators
who
perform
an
rpc
and
it
could
be
fewer
shots
if
not
one
shot,
because
you
just
copy
the
entire
system
rather
than
item
byte
item,
but
both
both
auto
populate
and
this
way
will
cause
some
unnecessary
system
configurations
exist
in
running.
So
the
third
option
is
just
the
existing
mechanism,
like
edit
config
operation,
to
redefine
the
reference
system
configuration
in
running.
J
C
F
C
Yeah,
okay,
good
all
right!
Well
with
that,
I
thank
everyone
for
their
participation
and
a
lot
of
interesting
discussion,
things
to
take
off
list
and
maybe
even
even
into
virtual
interims,
and
with
that
I
will,
unless
my
co-chairs
have
anything
they
want
to
say
we'll
end
the
session.