►
From YouTube: IETF105-NETMOD-20190722-1550
Description
NETMOD meeting session at IETF105
2019/07/22 1550
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
A
A
Okay,
administrative
details:
we
do
have
a
media
echo
session
for
this.
I
was
scribing
in
there
for
who
was
speaking.
We
have
the
same
etherpad
as
previously,
so
we
can
just
pretty
much
pick
up
where
we
left
off
all
right,
so
agenda
wise.
We
are
going
to
start
in
with
the
design
team,
and
so
this
is
actually
about
half
of
our
agenda
for
this
session
and.
C
So
there
are
agenda
today,
will
be
five
minutes,
hopefully
less
for
me,
followed
by
I'm
gonna,
guess
the
bulk
of
the
time
with
Rob
and
then
Bala
will
round
us
out
and
Rob
will
take
us
to
next
steps
next,
please
so.
The
first
thing
we
want
to
talk
about
is
the
versioning
requirement
changes
and
the
reason
this
is
only
five
minutes
is
because
this
is
going
to
be
fairly
short.
Essentially,
last
time
we
agreed
that
we
would
adopt
this
document.
C
It
was
still
unclear
as
to
what
the
fate
of
this
document
will
be
if
it
will
be
taken
RFC
or
if
it
will
just
be
something
that
the
working
group
agrees
to
that.
These
are
the
requirements
that
we're
trying
to
solve,
and
instead
we
will
then
adopt
solutions,
work
through
those
solutions
as
a
working
group
and
take
those
two
RFC,
but
we
did
adopt
it.
There
has
been
one
change
since
just
transitioning
it
over
to
an
IETF
net
mod
document,
and
that
is
changed
to
text
for
requirement
1.4
based
on
feedback.
C
We
got
directly
at
the
last
meeting
next,
please
that
change
was
the
original
1.4
said,
essentially
that
non
backwards
compatible
changes
must
be
allowed.
There
was
some
consternation
over.
Why
must
they
be
allowed?
Instead,
what
they
were?
What
we
really
wanted
to
focus
on
was
win
non
backwards.
Compatible
changes
occur.
Those
changes
need
to
be
signaled
or
documented,
so
that
one
can
see
that
between
two
revisions
of
a
particular
yang
module
that
backwards-compatible
changes
have
occurred.
So
what
you
can
see
down
there
under
the
new
heading
is
the
new
text
we
arrived
at.
C
This
was
posted
to
the
mailing
list
a
little
bit
of
while
a
little
while
ago.
We
haven't
heard
any
additional
comments
on
this.
So
at
this
point
the
design
team
feels
that
the
requirements
draft
the
ITF
version
at
revision.
0-1
is
final.
These
are
the
requirements
that
we
have
been
working
towards
in
terms
of
a
solution.
At
this
point,
questions.
C
All
right
as
to
what
the
final
resting
place
of
this
document
is.
We
of
course,
leave
that
to
the
chairs
and
the
working
group.
The
design
team
feels
that
what
I
said
earlier
this
document
will
not
progress
to
an
RFC.
It
will
just
be
there
to
serve
as
the
guidelines
for
the
requirements
that
will
inform
the
solution
or
solutions
that
come
forward.
D
Actually
on
the
next
document,
but
it
maybe
is
pertinent
to
this
question:
wait
and
it's
really.
Why
not
combine
the
two
and
you
have
like
a
solution
overview
document
that
repeats
a
whole
bunch
of
requirements
in
it.
If
you
really
believe
that
we
need
requirements
somewhere,
let's
keep
it
at
one
place
rather
than
have
because
the
requirements,
even
though
you
don't
think
it
needs
to
be
documented.
D
It's
not
meant
twice
so
it'd
be
great
just
to
have
one
document,
and
maybe
maybe
what
we
end
up
as
from
a
working
group,
is
a
requirements
in
solution,
overview
or
requirements
and
framework
document,
and
that's
how
we
end
up
publishing
that
so
we
fold
in,
what's
now
an
individual
document
into
the
working
group
document
and
let
that
go
forward-
and
you
know-
maybe
all
the
historic
stuff
goes
in
an
appendix
just
for
context.
Okay,.
C
E
D
C
D
C
F
Okay,
so
so
I
need
a
quick
update
for
next
slide.
Please
so
I
just
want
to.
We
continue
to
have
semi
regular
meeting
since
ITF
104,
there's
quite
a
few
people,
who've
I'm
dialed
in
either
a
weekly
or
semi
weekly
basis
and
we've
continued
to
progress.
Various
documents
I
like
to
thank
everyone
down
there
on
that
list,
I,
don't
repeat
them
and
our
main
output
really.
Is
that
tweak
the
requirements
document?
F
My
opinion
is
that
this
draft
accommodates
all
sort
of
core
feedback
we
received
during
the
working
group
meetings
and
also
the
versioning
discussions
we
had
at
1:04,
and
so
we
think
it
was
sort
of
reflects
that
consensus
from
that
next
slide.
Please
so
I'm
now
going
to
spend
the
next
20
minutes
discussing
the
solution
overview
I'm.
Just
trying
to
set
the
scene
of
where
these
drafts
ought
to
hang
together,
then
there's
me
subsequent
talks
on
some
of
those.
There
are
different
parts,
so
next
slide
please.
F
So
my
intention
here
was
that
the
solution-
David
Dreier
you
draft-
is
meant
to
be
a
sort
of
transient
temporary
document.
The
the
idea
here
really
is
just
to
help
the
readers
who
are
reviewing
those
drafts
understand
how
they
fit
together.
What
bits
haven't
yet
been
written,
but
in
what
will
be
written
a
mind?
Teacher
wasn't
intended
to
take
this
to
RFC
I
mean
it
could
be
done,
but
that
the
attention
of
this
was
to
help
people
during
the
review
process.
F
In
terms
of
updates,
there
will
be
a
separate
presentation
by
balázs
on
updated
mod
revision.
Handling.
I
will
talk
about
young
packages
after
this,
and
Rashied
will
talk
about
version
selection,
so
those
three
ones
will
be
covered
in
more
detail
next
slide,
please
so
the
overall
solution,
as
we
see
it
now,
is
made
up
of
five
different
parts.
F
There's
a
really
just
a
semantic
version
number
scheme
that
it
sure
could
be
described
fairly,
abstractly
that
hasn't
been
written
yet,
but
we
derived
from
the
text
from
the
previous
one
draft
30
over
DT
net
mod
yang
Simba's,
eros
eros,
or
take
the
semantic
versioning,
a
definition
from
that
draft.
You
just
extract
that
text
and
I'm
putting
in
isolation.
So
we'll
do
that
in
the
next
phase.
There's
a
version
yank
packages
draft
and
this
one
was
published.
F
This
update
was
much
before
ITF
104
I
need
some
changes
to
take
into
account
the
changes
in
the
updated
yang
mode
revision
handling,
so
I
will
present
that
one
this
time
it
wasn't
presented
in
104,
and
but
there
needs
to
be
some
updates
to
that.
There's
also
a
draft
for
protocol
operations
for
package
version
selection.
So
that's
draft
Wilson,
Ahmad
yang
vs.
election
0/0
again
that
one
was
published
before
104.
Rashad
will
be
talking
about
that.
So
again
that
is
sort
of
quite
early
draft.
F
We
expect
there
to
be
more
substantial
changes
to
that
and
then
the
final
part
of
this
whole
puzzle
we
think
he's
tolling
related
to
doing
schema
comparisons
between
either
a
module
by
module
basis.
All
you
group,
a
set
of
modules
together
into
one,
is
yang
packages
to
actually
version
and
be
able
to
compare
two
schemas
and
report
at
the
schema
level
what's
different
or
maybe
on
a
per
leaf
node
base
of
data
node
basis.
F
D
F
Well,
I
think,
probably
not
at
this
stage
the
ones
that
came
out
of
the
Verde
T,
the
design
team
obviously
have
the
Verde
T
prefix,
the
young
version
yanked
packages
and
the
packaged
version
selection
were
not
work.
There
was
output
from
the
design
team
there
in
need
to
individual
drafts
that
I
wrote
but
I.
That's
not
because
the
design
team
doesn't
align
necessarily
with
that
direction.
F
D
D
F
F
So
of
the
first
of
those
five
drafts,
the
updated
yang
module
revision
handling.
This
is
the
one
there's
a
more
detailed
talk
on
this
by
launch,
we'll
cover
all
of
the
different
parts
of
this
in
a
lot
more
detail.
So
this
is
just
a
one
slide
summary
of
what
we've
done
and
what
the
draft
covers
and
you
have
the
core
enhancements
to
Yang
or
to
allow,
but
not
necessarily
encourage
nonlinear
module
development
eg
for
bug
fixes.
F
So
we
allow
we
allow
some
sort
of
branching
to
occur
in
yang
module
history
and
to
document
when
not
on
backwards.
Compatible
changes
have
occurred
in
the
revision
history.
So
we're
not
saying
that
we're
not
encouraging
that
people
should
do
this,
but
even
when
they
do
occur
at
least
be
able
to
describe
that
so
that,
when
clients,
when
people
read
these
documents
and
or
client
tools
are
processing
them,
they
can
know
where
and
Nan
box
classical
changes
have
occurred.
F
We
define
a
new
version
of
import,
so
today,
yang
has
an
import
that
will
choose
any
revision
or
has
an
import
that
chooses
a
very
specific
revision
and
one
of
those
is
two
general
ones
to
specific.
So
we
are
introducing
one
that's
import
by
revision,
data
or
derived
and
that
effectively
you
will
find
you
a
revision.
F
We
define
backwards-compatible
versus
non
backwards-compatible
changes,
and
these
are
actually
the
non
backwards-compatible
change.
So
bogus
collateral
changes
are
very
close
to
what
is
defined
in
our
c
7950,
with
some
tweaks
and
the
non
box-cutter
ones
fairly,
obvious
from
that
we
clarify
and
prove
yang
status
handling.
So
in
particular
we
clarified
the
deprecated
means
you
still
have
to
implement
the
node
or
otherwise
and
use
deviations
to
indicate
you're,
not
implementing
it
and
obsolete
means.
F
Next
slide,
please
so
the
second
draft
and
this
one's
not
been
written
yet-
and
this
is
the
semantic
version
number
scheme
so
I'm
just
saying
what
the
plan
is.
Do
it
and
we
tend
to
to
do
this
over
the
next
window.
Next
four
months
is
to
define
a
semantic
versioning
scheme
that
allows
a
bug
fixes
to
release
software
released
software
assets
so
effectively.
F
It's
what's
already
documented
the
algorithm
in
the
draft
DT
net,
mod
yang
symbol,
0
0,
and
it's
a
version
of
semver
2
0
0,
but
with
the
ability
to
add
these
bug
fixes
in
to
the
released
assets
when
necessary.
The
main
changes
to
is
that
doesn't
actually
now
need
to
define
what
constitutes
a
backwards
compatible
or
non
box-cutter
will
change
that
would
be
assumed
to
be
defined
outside
this,
and
this
is
this
is
what
will
be
used.
We
expect
this
is
some
people
as
a
revision
label
so
effectively
the
revision
labels.
F
You
have
will
use
this
semantic
versioning
scheme.
So
you
end
up
with
having
semantic
version
for
your
young
modules
and
then
again,
it's
worth
pointing
out
that,
in
terms
of
this,
this
versioning
scheme
is
not
going
to
be
tied
to
yang.
So,
although
it
will
be
defined
or
have
some
references
to
the
and
models,
it
could
be
used
anywhere
where
you
want
to
do
this
sort
of
semantic
versioning
of
assets.
But
you
want
to
have
a
bit
more
flexibility
to
be
putting
be
to
put
bug
fixes
in
two
older
released
code
or
released.
F
Api's
looks
like
so
yang
package
again
an
overview.
I'm
I've
got
with
more
detail
on
this
later
on.
So
what
is
a
yang
package
is
identifying
a
set
of
yang
modules
and
their
dependency.
So
it's
a
bit
like
taking
Watson
Yang
library
and
putting
it
into
a
file
or
this
one
example,
but
it's
a
bit
more
flexible
than
that.
F
So,
whereas
Yang
library
will
tell
you
what
the
schema
is
for
a
particular
data
store
an
entire
device,
this
allows
you
to
do
subsets
of
yang
modules,
so
bits
of
bits
of
stuff
together
and
group
them,
and
the
key
thing
here
is
that
those
packages
can
then
be
versioned
in
the
same
way
that
modules
are
being
versions
so
rather
than
having
each
vendor
implementing
choosing
exactly
which
module
version
module
they
want.
So
every
single
language
will
they're
implementing
I
think
the
use
of
packages
could
encourage
people
to
have
more
commonality
in
what
they
implement.
F
So
if
you
took
the
ITF
young
model,
for
example,
you
could
have
a
package
that
defines
the
base
models
and
types
and
things
you
could
have
separate
package
for
routine.
You
could
have
a
separate
package
for
VPN
services,
for
example,
and
those
would
be
versioned
over
time
and
so
rather
than
somebody
saying
well,
I
want
this
version
this
or
this
version
of
that
you
could
choose
something
off
that
the
history
of
those
version
packages.
Yes,.
G
F
F
F
So
yes,
in
terms
of
packages
that
could
be
available
offline
using
the
yang
instance
data
document,
they
also
the
plan
is
to
augment
yang
library
so
that,
rather
than
necessarily
downloading
the
full
module
list
off
a
device,
if
you
knew
and
expected
what
package
version
it's
going
to
implement,
you
can
just
check
that
it's
implementing
what
you
expect
so
make
it
an
easier
check
for
comments,
conformance
wise
and,
as
I
said,
there's
a
separate
present
presentation
on
this
following
later.
So
that's
what
I
cover
now
next
slide.
F
So
the
fourth
one
is
protocol
operations
for
package
version
selection.
So
one
of
the
key
aims
of
yang
packages
is
to
allow
devices
to
potentially
implement
different
versions
of
modules
as
cohesive
sets
and
then
to
allow
clients
to
select
which
ones
to
use.
So
this
could
be
done
where
they're
choosing
between
some
different
sets
of
vendor
modules
or
it
might
be.
F
H
F
Slide
please
and
then
the
last
one,
so
there's
no
draft
written,
yet
they
slightly
lower
priority.
I
do
think
it's
a
key
part
of
this
set
and
that's
to
define
an
algorithm
to
compare
to
schema
trees.
The
detects
backwards-compatible
versus
non
backwards-compatible
changes.
So
it
looks
through
those
two
schemas
and
says
that
these
are
where
the
changes
are
so
P
yang
already
does
some
of
this.
F
So
if
they
are
only
using
no
1/3
of
a
particular
protocol
module
they're
not
using
these
options,
then,
when
you're
comparing
to
see
what's
changed
between
two
versions
of
that
module,
you
may
not
care
if
stuff
has
changed
in
the
stuff
you're
not
using
so
again
be
able
to
compare
the
schemas
and
subset
it
in
to
the
stuff
you
care
about.
I.
Think
gives
you
almost
like
the
perfect
answer.
F
F
Then
everything
that
might
want
to
use
semantic
versioning
scheme
'obviously
has
dependency
on
that,
but
other
schemes
could
be
used.
It's
just
one
choice:
the
packages
draft
depends
on
the
module
versioning
and
the
package
version
selection
of
C
depends
on
that
one
and
then
the
schema
comparison
touring
depends
on
packages.
If
that's
what
you're,
comparing
or
modules,
if
that's
what
you're
comparing
now
next
slide,
and
that's
it
for
me.
So
any
questions
on
that
overview
section
at
all
in
terms
of
the
sort
of
overall
picture
of
how
the
solution
fits
together.
B
F
Yes
in
the
in
the
next,
so
the
module
revision
handling
draft
will
be
covered
in
detail
next.
So
that
covers
all
that
and
a
lot
more
detail
of
those
examples
in
there
I
will
talk
about
the
packages
version
schema
draft
after
that
Rashaad
will
talk
about
the
package
version
selection.
The
two
that
we're
not
covering
any
more
detail
today
is
the
semantic
versioning
scheme.
That's
based
on
what
was
there
before
we
have
written
in
yet,
and
the
schema
comparison
told
him
that
we
haven't
really
looked
at
in
great
detail.
F
What
I
would
like
to
know
is
where
the
people
in
this
room
think
that
as
a
sort
of
solution,
space
of
solving
the
entire
problem
is.
Does
this
look
like
the
right
set
of
things
that
we
are
solving
and
does
it
look
like
it
covers
all
the
pieces
you
would
expect
it
to
cover?
Does
it
look
like
it's
morally,
the
right
approach
so
obviously
they've
become
some
individual
drafts
and
things,
but
does
this
look
like
overall,
the
right
thing.
G
Then
work
is
needed
exactly
all
of
this.
With
you
show
there,
I
am
I'm,
not
hundred
percent
sure
that
maybe
the
scope
is
too
much
over
there
trying
to
put
it,
but
what
they
see
as
a
problem
when
doing
yank
are
the
dependencies
and
figuring
out
what
are
my
dependencies,
what
they
have
flawed
in
order
to
enable
the
service,
and
we
are
planning
to
be
able
to
create
abstractions
at
different
layers,
that
going
to
change
where
they're
happening
and
be
able
to
take
into
the
content,
and
maybe
even
prepackaged
those
things
up
and
saying.
G
F
D
Earlier
we're
looking
for
the
design
team
to
come
up
with
a
full
and
set
of
it
documents
that
answers
all
the
requirements
and
then
bring
them
to
the
working
group
for
further
option
call.
So
it's
important
to
make
sure
that
the
working
group
is
aware
of
what's
going
on
in
the
design
team
and
is
generally
aligned
with
the
answers
once
once
they
become
working
group
documents,
we're
going
to
follow
a
normal
working
group
process,
which
is
everyone
in
the
working
group
has,
it
will
have
an
opportunity
to
provide
equipment
influence.
D
I
Don't
you
blurt
about
the
pre-comp,
so
when
you're
the
semantic
version
sounds
great,
I
was
always
wondering
why
it
didn't
start
out
that
way.
So
it
that's
not
great.
When
you're
talking
about
visualizing
the
difference
between
schemas,
would
it
be.
The
resolve
schema
once
you've
resolved
all
the
groups,
because,
usually
that's
what
consumers
baby
eyes
are
mentally
visualize
or
is
it
visualizing
I.
F
Think
I
think
both
is
answer
so
I
think
you're
comparing
a
module
itself,
then
you
might
do
it
on
the
module
text,
but
even
even
then,
actually
I
think
you
have
to
resolve
the
sub
modules
and
allow
groupings
and
things
to
move
around
so
I
think
it's
sort
of
the
the
resolved
schema
to
some
level,
but
I
might
not
be
fully
resolving
all
dependencies.
It
might
be
this
module
with
dependency
still
hanging
in
open
or
it
might
be
the
entire
scheme.
F
J
So
this
draft
is
there,
let's
say
the
main
out
main
output.
At
this
point,
we
derived
it
from
the
complete
solution.
We
try
to
separate
parts
of
it
and
we
believe
that
we
had
discussions
on
the
last
IDF
on
the
on
the
meeting,
but
also
outside
afterwards
with
many
people.
We
believe
that
all
the
all
the
main
comments
were
included.
J
J
J
J
We
also
explicitly
state
that
we
allow
nonlinear
yang
module
development,
so
branching
and
updating
previous
previous
revisions,
which
was
not
forbidden
in
7950,
but
many
people
assume
that
they
are
there.
We
will
have
linear
development
only
we
introduced
to
revision
labels
because
many
people,
many
companies,
have
nice
versioning
scheme,
Sykes
same
wear
or
some
other
ones,
and
they
would
like
that
information
that
gives
a
short
compatibility
information
short
history.
J
Information
in
some
form
to
be
included,
provision
or
derived
was
also
mentioned
earlier,
so
that
states
that
you
can
import
something
that
is
newer
than
whatever
mode
module
date.
You
chose,
but
it
can't
be
just
a
date
because
of
the
nonlinear
development
anymore.
We
had
to
update
what
backward
compatible
and
the
unknown
backward
compatible
changes
mean
because
we
want
to
accept
some
NBC
changes
and
especially
the
status
related
changes
were
not
clear
in
79
15
we
have
some
additions
for
status,
handling
and
yang
library
are
updates,
as
we
mentioned
next
slide
please.
J
So
maybe
the
most
important
part
is
here
the
red
thing
we
have
and
BC
changes
that
indicates
inside
the
revision,
information
that
this
revision
made
are
incompatible
and
on
backwards-compatible
change.
To
compare
to
the
previous
revision-
and
it's
always
in
this
full
list
of
revision
statements-
the
previous
revision.
That
means
that
you
should
not
remove
revision
statements.
Maybe
you
can
remove
the
description,
part
or
shorten
the
description
parts,
but
you
should
not
remove
their
revision
statement
itself,
because
at
that
point
you
lose
this
information.
J
J
In
on
this
tree,
we
don't
this
boss.
This
is
a
possibility
that
can
be
misused.
We
don't
recommend
arbitrary
branching,
especially
not
for
as
the
earth
and
each
yang
module.
The
text
by
itself
will
represent
one
route
from
the
leaf
of
this
tree
up
to
maybe
the
root
or
at
least
to
some
level.
Next,
please.
J
So
we
have
revision
labels
because
the
NBC
only
tells
you
that,
yes,
we
have
and
change,
but
to
actually
understand
that
you
have
to
parse
the
module
already
and
look
up
all
the
revision
statements,
which
is
quite
a
bit
of
work.
So
as
an
alternative,
you
can
have
revision
label
that
contains
similar
information.
J
J
The
format
is
rather
free.
Only
concern
is
that
it
should
not
be
not
be
mistaken
or
as
a
date,
and
it
can
be
used
later
for
other
in
the
import
statements
as
well
yeah
next,
one
please,
okay,
here,
is
an
example
of
what
the
revision
labels
for
assembler
would
be.
If
you
see
that
the
main
number
changes
every
time
when
we
have
this
read
NBC
changes
extension
there
so
from
when
we
just
add
something.
Then
we
only
go
from
3
to
0
to
3
1.
Next,
please.
J
Okay,
import
by
revision
or
derived-
that's
a
very
important
part
of
this
work.
So
we
said
the
simple
import
without
any
revision
date
is
too
liberal.
If
you
have
the
revision
date,
there
is
too
strict
what
the
usual
case
is
that
I
want
something
that
includes
the
functionality
I'm
depending
on
already
and
anything
later
on.
I,
very
much
hope
that
it
will
not
remove
what
the
functionality
I
depend
on.
It's
not
a
strict
promise
that
everything
afterwards
is
good
for
me,
but
usually
it
is
enough.
J
No
should
it
no
because
most
of
the
time
the
NBC
changes
don't
impact
the
import.
There
is
a
risk
there
and
that
we
had
in
earlier
versions
very
complex
sets
where
we
said
that
from
this
version
to
that
version,
and
it
gets
more
and
more
complex
and
usually
you
want
to
leave
it
open-ended
because
you
don't
know
what
changes
the
new
revisions
will
bring
and
many
many
times
that,
even
if
the
changes
are
NBC,
they
won't
impact.
Your
import
won't
impact
your
importers.
J
F
The
revision
will
derive
dependency.
It's
almost
like
a
source
time
dependency.
When
you
actually
come
to
use
these
modules,
you
knew
something
like
downline
really
on
package
that
will
constrain
exactly
which
version
you're
going
to
use
anyway,
and
in
the
case
that
something
comes
along
and
breaks
your
source
dependency,
they
made
some
nautical
change
at
that
point.
You've
expected
probably
to
releasing
a
new
version.
You
revision
off
your
jewel
to
do
the
import
then
fixes
to
a
later
provisional
derived
or
changes
up
to
them
to
fix
the
important
pence
again.
F
So
we
think
that
this
is
the
right
balance
being
not
too
strict,
because
otherwise,
if
you
limit
it,
it's
more
likely
than
actually
but
I
said
you're,
not
gonna,
be
impacted.
You
start
update
your
module
anyway,
so
we
think
it's
better
to
be
better
to
ask
forgiveness
them
to
be
too
strict,
performed.
B
Okay,
I
think
my
only
analogy
here
would
be
like
suffered.
You
know
when
you're
building
and
you
have
dependencies
on
libraries
and
you'll
say
I
depend
on
library.
You
know
three
dot,
one
dot
two,
so
if
three
dot
X
I'll
support,
but
if
it
ever
goes
to
for
TEDx
I,
don't
want
to
support
that
so
sometimes
there's
the
ability
to
put
brackets
or
limits
into
how
much
future
you
want
to
support
automatically
but
I
accept
you
know.
B
It's
been
discussed
by
the
design
team
just
want
to
make
sure
that
was
something
that
you
guys
have
to
cover
and
also
previous
might
as
well.
I
think
it
was
yes.
So
this
the
the
two
future
statements
that
you're
creating
here
is
this:
what
I
understand
to
be
possible
extensions
to
yang
quarreling
gang
language?
Yes,
okay,.
J
Max
next,
okay,
so
in
order
to
define
what
is
when
we
put
in
those
statements,
we
have
to
define
what
is
backward
compatible
and
NBC.
7950
gives
us
a
very
good
basis
for
that,
but
not
the
full
statement,
because
deprecating
and
obsoleting
nodes
can
actually
be
NBC
or
BC
depending
on
how
it's
implemented.
J
J
We
want
to
change
what
deprecated
and
adopts
elite
means
we
still
is.
This
is
not
a
mandatory
statement,
so
it's
not
a
must
or
a
shell,
but
we
say
that
deprecated
should
be
still
there.
Working
fully
functional
while
obsolete
should
be
removed.
If,
if
you
don't
remove
obsolete
that
can
or
that
can
also
result
in
surprising
and
errors,
so
even
for
obsolete
I
think
we
is
important
to
define
this,
but
for
backwards
compatibility
we
put
into
the
Yang
library
to
the
extra
leaves
that
states
that
do
you
follow
what
we
recommend
here
or
not.
J
If
you
don't
put
these
extra
Leafs,
then
you
are
backward
compatible,
meaning
you
can
do
anything
you
like,
and
your
clients
will
be
surprised,
maybe
also
when
you
deprecated
or
obsolete
something.
Often
you
have
a
reason
for
that.
Often
you
have
a
time
line
when
you
will
actually
remove
it.
Maybe
you
have
a
replacement,
so
a
status
description
statement
was
added
for
that.
B
J
D
B
D
Since
you're
doing
extensions,
you
can
change
the
rules
for
implementations
that
implement
that
extension.
So
you
can
say
if
you
implement
this
extension,
you
must
do
these
things,
okay
and
it's
probably
worth
reducing
the
number
of
options.
So
in
the
case
where
you
have
an
extension
think
about
making
things
more
bus
than
shirts.
J
F
J
J
So
what
we
have
in
the
yang
library
is
two
nodes:
deprecated
nodes
implemented,
obsolete,
node,
up
steps,
and
these
are
the
first
two
bullet
points
we
have
discussed
lately
and
if
they
are
not
there
and
then
there
anything
can
happen
with
these.
That's
one
of
the
problems
that
in
yang
one
that
one
that
they,
the
definition,
is
too
open.
The
other
problem
was
that
currently
yang
library
doesn't
specify
which
version
which
revision
of
a
yang
module
is
imported.
J
J
F
Or
in
a
question
whether
the
second
point
here
exists,
really
bug
fixes
is,
is
something
that
a
raft
failed
to
cover
or
not.
My
precious
is
a
change
of
behavior
offensive.
It
couldn't
be
covered
in
an
errata,
but
he
was
opening
that
if
we
could
get
in
after
that
would
be
better
he's
clarifying
I
hate,
Lee,
that's
ambiguous
today.
F
J
D
J
Data,
it
was
required
requirements
to
do
say
what
it
what
happens
with
versioning
instance.
Data
itself
is
not
version
because
what
backwards
compatibility
means
there,
that's
not
defined.
On
the
other
hand,
it
back
versioning
is
very
useful,
for
instance,
data
understanding
if
the
schema
defining
modules
can
be
somewhat
different.
Next,
please,
and
then
we
have
some
guidelines
telling
others
how
to
do
changes
that
not
to
do
NBC
changes
and
try
to
make
the
changes
for
the
clients.
That's
painful
use,
deprecation.
J
J
J
My
first
answer
is:
I,
don't
know,
don't
care.
This
only
says
that
we
have
a
revision
label
where
you
can
put
in
some
numbers
now
there
will
be
a
separate
draft
about
Sandler
based
the
revision
labels.
Yes,
ember
has
difficulty
with
unlimited
branching
there.
Whatever
you
put
into
the
revision
label
will
have
its
limitations,
or
maybe
you
have
a
versioning
number
version
numbering
scheme.
That's
all
powerful
them
no
limitations,
but
that's
not
part
of
this
draft.
J
F
Robin,
just
have
one
comment
to
that,
so
you
so
somebody
might
a
vendor
might
choose
to
choose
their
module
labels
as
foo
and
bar
and
what
said
like,
choose
whatever
they
want,
so
he's
whoever's
doing.
That
scheme
is
define
the
semantics
of
the
scheme
so
very
quickly
to
cover
the
next
steps.
There's
just
one
slide
here.
Actually
we
sort
of
discussed
it
earlier.
So
at
the
beginning
we
were
going
to
seek
adoption
for
this
first
draft
I.
Think
the
feedback
from
the
chairs
was
that
actually
they
want
to
adopt
this
as
a
set,
so
I.
F
Think
of
fatally
we're
going
to
continue
on
the
same
track.
Any
comments
we
received
on
the
module
version
draft
will
update,
but
the
other
ones
will
effectively
work
on
the
other
ones.
The
static
version
scheme,
yank
packages
in
version
selection
drafts
and
also
the
tooling
one
but
I'm
not
sure,
we'll
get
those
all
done
before
the
next
IDF
there's
still
a
lot
of
work
there
and
then
on
seryung
packages.
Please.
F
F
And
so
yes
effectively,
the
idea
here,
as
beforethe
said
'is
to
diversion
sets
of
young
modules
together
with
their
dependencies
and
in
terms
of
how
the
yank
packages
draft
is
written.
At
the
moment,
it's
using
the
yang
cember
solution
as
a
way
of
identifying
or
the
the
version
number
scheme
for
these
modules.
That's
the
one
thing
I
think
we
need
to
update,
or
at
least
discuss
relative
to
how
we've
changed
the
modular
versioning
and
made
the
semantic
versioning
number
a
label
and
option
thing
rather
than
things
tied
in
the
packages
could
be
hierarchical.
F
So
a
package
can
import
other
packages
and
that
gonna
curse
down
the
packages
themselves
can
be
I
their
complete
or
incomplete.
So
you
don't
necessarily
have
to
tie
off
all
your
dependencies
depending
on
what
you're
doing,
and
that
might
help.
If
you
were,
you
had
dependencies
and
like
type
modules
and
things
that,
like
you
may
not
want
to
depend
those
the
package
themselves
can
be
available
from
yang
library
or
they
can
be
available
on
a
lot
of
line
and
yeah
instance
data,
and
in
the
yang
in
stated
discussion.
F
There
was
talk
about
how
you
identify
the
schema
using
yang
library.
I.
Think
yang
packages
might
be
another
example
which
were
a
good
way
of
defining
that
schema
a
better
way,
because
it's
it's
more,
what
you're
actually
trying
to
do
rather
than
yang
robe,
it's
returning
slightly
different
information
and
as
I
mentioned,
the
draft
is
slightly
out
of
date
because
it
hasn't
been
updated
with
the
changes
that
we've
done
to
the
module
level.
Versioning,
you
say
it
works,
but
I
think
it
does
say.
Yes,
it's
just.
F
F
If
you've
got
young
packages
and
your
and
your
versioning
for,
like
the
ITF
routing
protocols
and
every
time
the
module
gets,
a
new
routing
module
gets
updated.
You
add
that
into
the
yank
package
then,
and
a
new
version
that
yang
packed
you've
now
got
a
more
linear
update
in
terms
of
how
these
packages
are
evolving,
but
you're
not
fixed
to
that.
You
can
still
deviate
those
the
packages
that
you
still
use
your
override
and
say
actually
I'm
going
to
support
this
baseline
package
with
these
changed
in
these
differences
to
it
another
one.
F
Another
use
case
for
them
is
to
avoid
downloading
this,
this
full
set
of
modules
off
the
device
and
having
to
check
your
exactly
what
you
want,
because
that's
a
hard
thing
to
do,
it'd
be
much
nicer
to
say,
actually
I
support
this
package
or
these
packages.
These
API
is
the
things
I
support
with
these
modifications
and
rather
have
to
do
an
individual
check
on
every
single
module.
F
Either
I've
got
a
higher
level
conversation
about
the
API
that
you're
supporting
and
as
to
say
and
again
you
can
do
this
with
yang
library
making
the
schemer
available
offline,
so
you
can
check
it
in
advance
and
you
can
design
your
tooling
to
expect
to
talk
to
a
device
and
expect
which,
which
API,
which
package
version
it's
using
and
correlate
those
is
easier
than
how
to
deal
with
full
sets
of
of
packages
when
the
full
sets
of
modules
when
they
differ
next,
please.
So.
This
is
just
an
example.
F
I've
I've
got
a
simple
ITF
network
device
version,
1.1.2,
there's
some
metadata
description
and
other
information
where
you
can
wake
and
a
URL
of
where
to
download
that
package
from,
and
that
lists
a
set
of
modules
that
implements
here
and
it
lists
a
set
of
modules,
our
import.
Only
and
again,
this
could
be
fully
resolved,
it
might
not
be
resolved
and
the
definition
includes
metadata
like
URLs,
where
to
find
it.
It
lists
features
that
mandatory
so
which
features
that,
if
you
implement
this
package,
you
are
obliged
to
implement
and
support.
F
It
has
a
list
of
the
imported
packages,
not
there's
none
shown
here
but
list
the
pictures
you
importing
list
the
modules
that
are
implemented
by
that
package
and
the
import
only
module,
it's
a
very
similar
to
yang
library.
From
that
point
of
view,
except
it
recursos
and
has
a
list
of
imported
packages
and
then,
finally-
and
again,
it's
not
shown
here
is
import
conflict
conflict
resolution.
So
if
you
combine
two
packages
and
they
each
those
packages,
import
different
versions
of
modules
and
you
have
conflicts.
F
So
when
you
do
that,
when
your
package
pulls
in
two
separate
packages
with
conflicts,
you
surface
and
you
specify
exactly
which
version
of
which
module
you
resolve
to
next
slide,
please
one
more
slide.
So
this
is
another
example.
Package
example
ITF
basic
routing
package,
and
this
one
is
importing
from
Network
instant
network
device,
is
one
that
1.2
and
then
so.
It
lists
the
extra
modules
that
are
implemented
as
part
of
that
extra
imports.
On
top
of
that,
and
as
I
said
before,
any
version,
conflicts
or
change
must
be
explicitly
resolved.
That's
that's
one
thing.
F
That's
critical
here,
the
forgiven
package
definition,
the
list
of
modules
that
it's
using
is
is
exactly
tightly
defined.
That's
the
specific
versions
and
the
package
version
indicates
the
nature
of
changes
in
the
modules
or
package
imports.
So
the
version
number
that
we're
using
here
is
again
using
like
a
somatic
versioning
scheme.
So
if
you
update
your
package
to
include
a
module,
that's
changing
a
number
non
box
compatible
way
which
in
semver
would
mean
going
from
no
2.00
to
3.0
to
0.
F
Then
your
package
would
also
have
a
major
version
change
in
its
version
number
as
well.
If
you
had
minor
version
changes
in
your
packages
or
you
own
or
you're
importing
more
modules
in
your
package
definition,
then
you
have
a
minor
version
change,
so
it's
using
the
same,
send
their
ideas
and
rules
and
things
for
doing.
Versioning
applied
a
package
level
rather
than
a
module
level.
B
F
You
you,
what
you'd
be
allowed
to
do
is
you've
allowed
to
run
the
saying
you
you
implement
this
package.
You
would
implement
your
own
package
on
top
of
that
or
they're
in.
They
includes
this
one
and
then
has
it
extra
modules.
With
deviations
listed
in
terms
of
features
you
would
list
the
features
you
support,
but
you're
obliged
to
support
the
features
that
are
listed
here.
The
mandatory
features
or
otherwise
deviate
those
nodes.
F
Think,
probably
it's
better
for
yang
packages
also
to
have
that
same,
be
coupling
so
for
it
not
to
have
be
hard-coded
to
a
particular
semantic
versioning
scheme,
but
just
to
say
actually
it
can
use
any
scheme.
That's
partially
ordered
sets
of
identifiers
to
have
that
more
flexibility
in
to
what's
in
terms
of
what
it's
done
or
in
terms
of
what
it
uses
and
allow
yang
cember
as
one
example
of
what
could
be
used
in
that
case,
then,
the
question
is
is
to
be
is
how
flex
lie
you
in
that?
How
do
you
do
that?
F
Do
you
have
an
identifier
or
an
enumeration
to
identify
the
different
schemes?
I'm,
not
sure
we
want
to
have
a
huge
proliferation
of
them,
because
every
single
different
scheme
will
have
impact
on
clients
that
need
to
be
able
to
compare
these
things
so
but
same
time,
toyotas
yang
Semba
might
be
a
mistake.
F
I
think
entirely
decoupled,
so
I
think
you'd
be
allowed
to
there's
no
correspondence
between
the
package
version
number
and
the
version
numbers
inside
other
than
other
than
the
semantic
change
the
package.
So
if
you've
made
a
change
to
the
what's
included
in
that
package,
this
numbers
compatible
because
you've
changed
your
numbers
compared
to
a
module
or
you've
down,
read
the
module
that
would
be
like
a
non
box.
Non
backwards
would
change
to
that
package
definition,
so
it
would
go
from
1,
0
0
to
2
0
0.
M
N
F
Yes,
so
you
see
effectively
say
on
the
config
resolution,
say:
I
want
to
have
this
particular
version
and
I.
Think
I
try
to
remember.
Having
read
the
draft
recently
I
think
in
terms
of
import.
Only
again,
you
might
need
to
identify
which
specific
import
you
are
overriding
and
the
and
the
overriding
version,
but
it
be
only
other
day
you're
explicitly
saying
this
is
the
version
I'm
gonna
use
in
the
circumstance.
I
think
you
are
now
up.
F
So,
in
terms
of
the
modular
version,
the
reason
for
doing
that
is
because
that's
what
some
people
wanted.
They
thought
that
they
don't
like
the
yang
symbol
scheme
because
they
find
it
too
restrictive.
Some
people,
other
people,
think
it's
not
well.
Why
don't?
We
just
use
the
standard,
Semba
and
I?
Think
it's
not
flexible
enough.
So
there's
difference
opinions
as
to
what
version
of
scheme
is
required
and
if
you
are
a
vendor
and
you
end
up
having
arbitrary
branching
of
your
modules
for
whatever
reason
then
the
semver
scheme
we
defining,
can't
accommodate
that
deliberately.
F
So
it's
limited
deliberately
some
partial
branch,
but
not
too
much
so
I
think
that's
the
reason
we
had
that
separation
in
the
module
level
stuff
and
then
in
terms
of
packages.
The
question
is
whether,
if
you've
got
modules
that
have
that
flexibility
and
you
package
them
together,
you
probably
need
a
versioning
scheme
for
the
package
has
the
same
number.
Flexibility.
D
We
progress
from
the
design
team
to
the
working
group
because
to
the
eventual
something
we
submit
to
the
is
G
we'll
really
want
to
think
hard
about
whether
we
want
that
flexibility,
because,
anytime,
you
have
flexibility,
but
that
really
leads
is
to
interoperability
problems
and,
of
course,
the
reason
we
have
standards
is
you
know
for
interoperability.
So
if
there's
good
reason
to
allow
that
different
off
those
different
options
sure,
but
if
there's
not,
you
know,
we
should
think
really
hard
about
the
cost
of
that
flexibility.
Greatly.
H
F
Can
we
resolve
that
so
if,
for
example,
this
was
importing
two
modules
to
the
two
different
packages
and
one
of
them,
he
was
using
IETF
types
version,
1,
0,
0
and
up
was
using
ITF
types,
1
0
1,
then
this
package,
as
well
as
doing
the
import,
would
say
I'm
going
to
use
ITF
1
0
1.
As
my
version
for
this
package.
H
H
F
If
you've
got
that
sort
of
splitting
your
yang
ecosystem,
where
you
got
the
modules
that
that
different
and
there
and
there's
no
way
you
can
combine
them,
you
got
some
dependencies
on
the
older
than
you
well
you're,
combining
them
into
one
package.
So
if
you
got
dependency,
says
half
of
my
package,
depending
on
ITF
interfaces,
one
and
half
as
depending
on
ITF
interfaces
and
there's
significant
changes
between
the
two.
F
F
B
B
F
J
F
N
Yes,
so
I'll
be
presenting
the
version
selection
graph
on
behalf
of
Robin
myself,
so
this
slide
talks
about.
Why
are
we
doing
this?
Well,
this
comes
from
the
requirements
3.1
and
3.2
from
the
requirements
draft
you
spoke
about
and
the
what
this
is
basically
saying
is
because
yang
modules
are
change
in
non
backwards,
compatible
ways
we
need
to
help
clients
migrate,
so
servers
can
support
multiple
versions
and
help
clients
select,
which
version
they
actually
want
to
run
with
next,
please
so
the
summary.
N
So
it
allows
servers
to
do
non
backwards,
compatible
changes
without
forcing
clients
to
make
immediately
migrate.
It
does
make
use
of
the
yang
packages.
Draft
Rob
was
presenting
earlier,
and
it
provides
mechanism
for
servers
to
advertise.
What
versions
of
the
package
is
the
support
and
it
allows
clients
to
choose
among
the
ones
advertised
which
one
they
want
to
run
with
on
the
pitch
Lee
recession.
N
So
before
people
start
throwing
bricks,
servers
are
not
required
to
concurrently
support
clients
using
different
schema
versions.
Those
things
are
optional.
Servers
are
not
required
to
support
every
published
version
and
they
are
not
required
to
support
all
parts
of
all
version
schema.
The
important
thing
is
when
we
say
support
non
backwards
comes,
come
all
changes
if
you
remove
functionality
in
the
later
yahng
yahng
yahng
version.
N
Obviously
you
cannot
support
the
newer
one
and
the
older
one,
but
in
some
cases,
if
you've
we
organized
your
yang
module,
you've
moved
your
nodes
around
in
a
non
backwards
compatible
way.
The
server
should
be
able
to
support
all
the
older
version
and
the
newer
version.
Next,
please,
okay,
so
the
overview
which
you'll
see
in
the
yang
tree
NEX
is,
you
know
a
version
schema.
It's
a
yang
schema
which
Rob
was
talking
about
with
an
Associated
yang
revision.
N
That
could
be
the
semantic
version
number
in
the
draft
which
will
be
done
soon
and
yes,
as
I
said,
this
could
be
yang
package.
The
schema
set
is
a
set
of
related
yang
schema,
one
per
datastore,
the
server
support
configuration
for
the
default
schema
and
they
also
support
configuration
for
what
we
call
the
secondary
and
maybe
more
net
confess
count
instances
to
use
different
schema.
This
is
done
by
a
port
number
for
both
net
count
and
restaurant
and
for
restaurant.
N
N
You
can
see,
you
know
you
can
you
can
configure
your
the
schema
sets
and
all
that
or
read/write,
but
in
terms
of
the
information
per
datastore?
That's
all
what
the
system,
the
server
decides
to
support,
I,
don't
believe
we
got
any
comments
on
the
we
probably
need
to
do
in
Ex,
Rev,
based
on
the
latest
discussions
from
104
work
and
all
that
and
hopefully
we'll
get.
This
cut
will
get
comments
on
this
draft
and
the
yang
packages
draft
and,
as
Rob
was
explaining
earlier
in
the
next
steps
for
the
design
team.
N
O
D
B
N
F
B
B
B
C
O
Okay,
sis
chapter
2,
funding
model
fold
is
a
base,
the
network
policy
management
and
it
can
provide
some
billete
to
fold
an
imagine
function
to
control
that
information.
A
monitor
state
changes
on
the
network
element
and
if
the
sister,
if
the
trigger
condition,
be
meted-
and
you
can
perform
some
simple
and
instant
action-
and
this
document
has-
we
discussed
toys
in
the
working
group
and
the
since
many
people
are
interested
in
two
interesting
related
works.
O
So
we
update
sir
document
and
in
this
version,
made
a
new
leaf,
a
group
ID.
It
can
be
used
to
group
a
set
of
events
that
can
be
the
group.
A
set
of
key
witnesses
can
be
excute
together
to
perform
some
specific
tasks,
for
example,
to
provides
a
service
assurance,
and
the
way
also
optimized
must
even
leave
it
moving
from
action
lists
to
trigger
condition,
lists
and
allow
the
one
even's
trigger
to
reference
nazareth,
even
stuff
nation
and
the
way
a
change,
stratford
condition
in
choose
a
variation
condition
to
further
clarification.
O
If
the
trigger
a
to
be,
we
be
set
up,
so
it
can
trigger
even
the
B
and
the
even
P
use
a
call,
even
if
the
even
exist
and
there's
a
polling
condition
net,
sending
the
triggers
corresponding
action
to
active
standby,
a
fair
work,
okay
and
we
use
a
group
ID
to
groups-
is
to
event
to
perform.
The
proverb
provides
a
sort
of
surance
a
test.
Okay,.
O
O
Processing
units
just
is
provide
for
routing
policy,
and
here
we
use
this
doc
use
this
module
to
perform
such
high
service
assurance.
If
you
here
is
example,
if,
for
example,
food
loss
package
across
the
street,
then
it
can
perform
the
relate
action.
For
example,
logins
you
lost
packet,
cross
their
food
and
then
perform
some
action
to
Octavian
birth
of
fare
over
taxes.
M
O
M
Yes,
so
yes,
so
I
understand
this
record.
I
think
I
understand
this
correctly.
There
is
no
correlation
between
either
work
neurotic
working
group
in
the
policy
there
using
the
event
condition
action
as
well
as
well
as
some
constant
question
and
in
this
work
here.
Is
that
accurate?
Now
this
work
here
I
would
have
mixed
on
standings
incorrect.
Is
this
work,
just
data
plank
or
is
admit
the
general
was?
Is
it
meant
for
control,
playing
or
other
usages.
F
Q
A
Thank
you,
who's
read,
Benoit
clays,
so.
O
E
K
E
A
A
A
D
A
R
A
H
Q
Q
Actually,
my
colleague
actually
revised
this
chapter
base
his
experience
on
the
network
network,
a
conversation
very
question,
so
we
sinker
we
most
negatives
job
to
turn
an
empty
ative
actually
for
actually,
but
you
know
they
can
work
together
with
the
problem
is
a
negative
right
now
can
compare
the
difference
between
the
datastore
by
the
limitation.
Is
the
latter
type
ability
to
verify,
whereas
an
elevation
from
Indian
or
other
sauce
take
effect?
Q
So
we
we
sink
so
that
the
the
solution
we
propose
is
that
affine
notification
actually
to
reporter
this
cannon
a
verification
event
to
check
these
miscalculation
issues,
but
the
week
not,
you
know
check
out
all
these
miss
conversion
issue,
because
for
for
summer
cases
may
rely
on
you
need
to
export
data
from
different
device.
So
so
we
gave
some
cases
like
you,
wanna
maintain
the
considered
a
consistency
in
network
configuration.
May
cover
a
two
different
device.
Q
You
want
to
maintain
the
consistency
as
it
is
something
we
cannot
just
use
this
event,
and
here
we
gave
one
use
cases
and
we
think
we
can
use
a
native
to
compare
the
antenna
with
the
operational
data
store
and
we
have
two
different
cases
so
for
some
object
that
may
be
present
in
but
another
present
in
operational,
for
example,
you
may
have
an
interface,
but
another
physical
exist,
so
it
can
exist
in
antennae
but
not
existing
in
operational.
Another
cases
they
may
present
in
operational,
but
not
a
present
in
intent.
Q
So
typical
case
actually
is
interface
MTU
and
so
here
the
maximum
weight
way
proposed.
Actually,
we
need
to,
you
know,
make
sure
the
server
can
detect
the
hardware
changing.
So
this
may
rely
on
the
system,
interaction
with
the
hardware
so
based
on
this
assumption,
actually
we
can
detect
whether
there
are
some
miss
compression
issues
and
probably
actually
here.
Okay,
we'll
get
some
phrase.
We
can
compare
the
difference
between
in
10
and
operational
and
we
can
make
sure
all
this
actually
caused
by
some
mystery
sauce,
and
here
is
the
motor
structure.
Q
A
Yeah
so
I
think
the
challenge
with
discussing
this
since
I,
don't
see
anyone
running
to
the
mic
at
the
moment
is
that
at
104
and
103
there
were
pretty
few
people
who
had
read
this
I
guess
that
is
their
queen.
Our
show
of
hands
of
anybody
who's
read
this
in
either
its
present
form
or
the
I
guess,
o
1
and
O
2
versions
that
are
have
been
present
previously
prevented
presented.
F
So
that's
one
observation.
The
other
one
is
I
think
that
it's
possibly
really
hard
for
some
systems
to
implement
this,
to
be
able
to
report
back
when
some
of
these
operations
have
failed
because
to
be
committed
to
the
running
datastore.
The
configurations
there,
the
actual
apply
phase
with
system
might
go
through
many
different
demons
and
my
how
other
intermediate
failures
and
things
like
that
so
I
think
generally,
my
experience
is
really
hard
to
track
these
errors.
Back.
We've
always
struggled
with
this
sort
of
thing,
so
I'm
not
sure
that
helps
I'm,
not
sure
yeah.
Q
K
F
It's
a
certain
thing
for
the
verification
side
and
check
into
the
verification.
The
configuration
is
valid.
What
your
state's
all
about
completely
agree
with-
and
that
makes
sense,
but
in
terms
of
the
next
set
of
applying
it,
which
is
sort
of
a
sickness
or
semi
asynchronous
and
systems,
are
aware
of
that's
the
big
thing,
that's
harder
than
trackback.
So
I
think
that
if
you
have
a
simple
device,
you
may
be
able
to
do
that
and
may
have
value
for
that.
M
Jim
Carrey
Nokia.
So
when
I
read
the
draft,
there
was
a
couple
things
that
were,
it
was
running
through
our
mind.
I've
just
couldn't
I
just
couldn't
form
an
opinion
on,
because
what
I've
seen
here
is
is
what
we've
done
in
the
past
is
grated
up.
The
examples
that
you
use
this
is
well
if
I
have
something
tonight
of
the
sign.
Oh
so
did
you
did
and
now
I'm
going
to
put
it
and
there's
a
difference
between
that
and
call
me
differences
between
data
source.
M
Those
things
where
I
think
it's
also
saw
that
those
particular
notifications
are
generalized
notifications.
There's
notifications,
in
the
context
of
the
problem
that
you're
trying
to
resolve
on
I'm,
going
to
do
a
quick
meet
I'm
going
to
do
that
type
of
stuff
and
so
I.
That's
what
I
was
like
going
on.
I,
don't
know
if
this
will
do
you
realistically.
If
this
will
be
you
and
you
really
use
because
I
think
it's
the
problem,
the
maintenance
of
the
use
in
the
and
the
person
or
the
enemy,
that's
interpreting.
M
A
Thank
you,
I
think.
What
we're
hearing
here
like
is
some
people
who
have
given
this
a
little
thought,
but
they're
not
they're,
not
necessarily
interested
in
being
consumers
of
it,
and
that
would
actually
I
think
be
the
sort
of
thing
that
would
drive
interest
or
its
implementation
and
refinement
and
would
also
get
us
better
feedback,
so
I
think
I,
I
think
borrowing
some
kind
of
expression
of
interest
of
that
variety
on
the
list.
This
is
probably
not
something
that
we
need
to
revisit.
A
If,
if
you
know,
if
we
can
find
that
or
muster
the
energy
in
the
community
for
people
who
are
interested
in
it,
then
I
think
it's
pretty
easy
to
come
back
here
and
go
well.
We've
reviewed
this
enough
that
we
can
call
for
adoption,
but
I
don't
think
we
have
I,
don't
think
we
have
the
level
of
energy
or
enthusiasm
with
respect
to
being
consumers
of
this.
That
would
cause
us
to
to
really
ask
that
question
at
this
point.
Okay,
thank
you
for
your
diligent
efforts.
However.
Yeah
thank.
Q
S
Q
Q
Actually
recap
a
little
bit
because
right
now,
actually
Nana
colress
coming
and
he
has
ought
to
be
published
and
actually
right
now,
mostly
idea
for
young
anymore
should
be
the
NMDA
compliant
and
also
there's
more
young,
a
motor
that
developers
should
be
done
be
combined,
but
we
still
see
actually
there's
some
temporary
and
no
MDA
actually
exist
to
bridge
the
capper
of
the
time
period
and
kill
them
they
can
be
available.
So
we
see
there's
transition
stages.
So
our
you
know
confusion
is
how
how
so?
How
long
is
this
transition
period
will
will
take?
Q
Actually
when
this
can
get
started
when
and
so
so
so
we
have
some
misconception
with
sinker.
The
current
are
empty.
Young
town
lying
actually
only
provide
a
guideline
for
the
young
trans
transition,
but
the
tenant
provide
the
transition
kind
line
for
the
protocols,
actually
so
especially
another
case
actually
so
protocol.
Actually,
if
we
forego
support
empty,
but
you
you
still
can
use
some
Nnamdi
modules
so
so
this
is
something
we
think
maybe
there's
some
gap.
Actually.
Maybe
this
is
a
misconception
we
already
discussed
this
on.
Q
The
man
is
also
offline
discussion
with
several
people,
and
so
here
we
give
several
option.
You
know
we
have
a
client,
actually
they
can
be.
The
MBK
liner,
convenient
lambda
cannot
client
for
the
device
who
support
a
net.
Amd
could
be
the
AMD
server
on
and
no
long
an
MDA
server,
but
in
a
between
we
single
may
be
the
other
cases
you
know
for
the
server.
They
only
implement
MDA
Maxim,
but
it
doesn't
implement
the
button
tenant
support.
Mda
combined
young
data
model
so
actually
talked
with.
Q
Q
Q
We
propose
a
three
different
solutions,
so
the
first
one.
Actually
you
know
we
can
add
as
a
state
a
copy
node
in
in
the
inner
MTA
young
big
mantra.
I
think
this
is
another
good
approach
it
because
we
already
moved
to
order
an
MD.
We
add
back
actually
seems
you
know
actually
not
a
reasonable
actually,
but
this
is
the
one
solution
we
can
using
the
get
operation
challenging
get
operation
to
care
as
a
system
generator.
Q
So
whether
we
should
you
know,
ask
all
the
NMB
multi-with,
you
provide
us
data
module,
so
this
is
a
something
we
single
could
be
the
solution,
but
the
with
this
data
mode.
You
stay
the
model.
We
can
actually
address
the
problem.
We
can
care
system
generate
the
confirmation
from
these
data
modules,
the
third
option.
Actually
we
can
actually
you
know,
enhance
the
get
operation
to
allow
uses
the
traditional
ket
operation.
You
get
a
system
generated
a
pattern.
Q
This
actually
the
impactor
is,
you
know
only
modular
post,
so
we
think
that's
possible
to
actually
get,
but
that
we
simply
is
very
you
know
the
influence
we
haven't
evaluated.
We
Singham-
maybe
it's
very
hard
to
see
this,
so
we
so
we
we
propose
these
three
different
solution.
So
so
the
first
question
we
want
to
ask
is
actually
church,
as
you
know,
as
we
assumed
actually
we
may
have
for
for
the
server
name,
a
support,
semi
an
MDA,
so
we
you
know.
So
the
question
is
a
supporter.
Q
You
know
when,
when
we
migrated
to
the
MDA
just
athos
away
supporter
and
MDA
protocol
like
an
alcohol
rescue,
empty
air
support,
and
then
we
can
support
a
M
de
young
beta
model.
Are
we
when
we
implement
all
the
other
choices
that
we
implement
the
young
Vinney
model
and
MDA
protocol
at
the
same
time?
So
so
so
we
for
the
option
we
we
proposed.
Actually
we
may
have
three
option
me.
We
may
actually
be
single.
We
can
skip
these
transition
stage
if
we
can
go
directly
to
the
nmda
solution.
Q
Actually,
this
already
be
done
by
ITF
is
a
completed
standard
solution,
but
the
we,
the
problem
we
are
facing
is
we
sink.
We
assume
many
at
nanoka
line
that
doesn't
support
an
mp4
right
now
at
this
stage
here
how
to
migrate
it,
and
so
we
propose
the
another
to
option.
One
is
option.
One
actually
option
will.
Actually
you
may
take
a
one
of
solution.
We
prefer
actually
the
the
solution
to.
Actually
you
may
define
a
state
a
module,
but
this
is
not
a
standard
state,
a
module
in
some
cases.
Q
F
So
I
mean
I,
I,
think
pragmatically,
probably
something
to
so
I
think
one
Colin
here
is
the
potential
for
a
given
server
or
vendor.
They
could
have
a
bespoke
in
a
conflict
switch
to
choose
whether
it's
going
in
and
nmda
mode,
I
think
for
a
lot
of
deployments,
that's
probably
sufficient
and
fine,
and
that
the
operators
would
would
either
upgrade
all
their
clients
and
won't
go
or
not.
So
to
do
this
in
terms
of
the
option
to
we
do
there
is
a
specification
in
the
young
off
guidelines
of
how
to
generate
that
state
module.
F
That's
quite
prescriptive
and
fairly
easy
steps.
So
one
option
here
could
be
to
say
the
ITF
young
modules
that
we
run
through
that
process
and
we
dump
those
date
trees
and
the
names
well-defined
into
github,
for
example,
and
then
they're
just
there.
So
I
think
that
that
may
be
a
pragmatic
way
for
it.
And
then
the
other
session
I
had
was
I.
Think
on
vesties
in
terms
of
the
new
young
library
and
get
operations
used
to
have
a
case
of
where
existing
gets
returns.
F
Q
Yeah
the
puzzle
we're
facing
is
the
way
which
taker
the
operation
to
actually
we
need
to.
You
know,
have
a
completed
standard
solution
you
for
every
an
MD
model.
You
should
define
and
stay
the
module
so
for
some
Oh
an
empty,
a
model
they
may
didn't,
define
the
state
model,
such
as
a
motive
attack
or
some
maybe
some
other
cases
or
so
that
will
delay
implementation.
So
how
do
you?
How
do
you
address
these
so.
H
F
Publishing
I
took
routine
state
I,
think
that's
okay
with
the
same
version
number
and
you
follow
that
also
how
to
generate
it
and
then
you've
got
that
state
route,
so
even
if
they
are
not
included
with
the
appendix
that
module
how
to
construct
that
equivalent
state
module
is
defined,
so
it
logically,
this
doesn't
just
because
this
is
a
file
somewhere.
I
think
two
different
vendors
could
apparently
generate
that
same
module.
F
B
So
Kent
as
a
contributor,
so
you
say,
agree
that
there's
an
NDA
a
transition
period
I
mean
that
is
in
fact
what
we
have
right.
Now
we
are
in
a
in
MD
a
transition
period,
so
I
don't
think,
there's
anything
to
agree
on
the
you
also
early
on
your
other
slide.
I
think
is
solution.
Number
two.
You
mention
the
possibility
that
the
bad
state
module
is
missing
but
I
think
that's
a
hypothetical
like.
Do
you
actually
have
an
example
of
dismissing
ya.
B
That
one
that
particular
draft
was
discussed
on
this
just
recently,
it's
okay
for
that
draft
not
have
a
state
equivalent
because
it
contains
no
config
false
notes
and
also
the
has
no
meaningful
operational
impact
have
tracked
the
operational
value
of
the
conviction
notes.
So
it's
actually
allowed
to
not
have
a
state
variant
for
that
draft.
Yeah.
Q
But
I
see
the
nd
respond.
Actually
he
sees
is
wrong,
but
I
don't
know,
but
it
may
be.
This
is
another
cool
example.
Actually
we
have
some
other
you
dumb,
prods
Chester,
you
know
operated
for
some
of
be
compliant
model,
doesn't
define
state
emotive,
so
so
these
state
a
mode
we
should
be
follows
a
young
and
a
young
kind
line,
and
but
this
is
not
a
standard
state
Amodeo.
So
it's
just
that
defined
in
the
appendix
issue.
Q
D
K
D
There's
a
reason
not
to
and
if
the
ist
is
processing.
If
the
is
GE
is
processing
such
in
in
other
areas,
they
the
ISP,
should
should
say
you
need
to
get
formed
with
the
PCP,
and
it
is
true
that,
like
in
tags,
one
of
the
ways
you
conform
is
we've
looked
at
it
and
don't
think
it's
opiate
for
this
particular
module.
So
that's
a
that's
an
okay
way
to
conform
with
the
BCP.
Okay.
Q
B
Says
that
the
I
think
it's
the
introduction
or
the
abstract
to
say
that
module
conforms
to
NMDA
or
not,
it
just
says
to
imitate
well,
it
should
also
have
in
it.
The
thing
like
we
have
especially
looked
at
and
have
concluded
that
it's
not
necessary
to
conform
to
NMDA.
So
it's
explicit
supposedly
said
yeah
there's
some
saying
maybe
there's
something.
Guideline
should
be
modified
to
just.
M
M
There
are
organizations
that
said
I'm
not
going
to
produce
a
module
that
has
produced
eight
modules,
friends
of
d8,
so
their
organization.
Yes,
yes,
sir,
that's
the
standard
operating
procedure.
There
are
organizations
that
says
that
will
do
them
right.
So
there's
a
problem
in
the
industry
that
were
not
consistent
on
our
point
of
the
Rothstein
transition
to
them.
M
Yet
and
I
would
say
that
as
the
the
authors
and
the
owners
that
probably
has
incumbent
upon
this
group
us
to
provide
guidance
where
it's
necessary
above
and
beyond
now,
we've
done
that
need
some
of
the
some
of
the
guidance.
I
will
say
the
guys
in
some
of
the
groups
that
are
marketed
and
looked
at
that
since
1918
and
has
has
made
some
decisions
of
it
right
s.
I
can't
go
into
too
much
because
of
both
member
organization.
M
Tree
had
have
made
decisions
on
some
sort
of
some
of
the
decisions
that
have
been
made
here
says
everything
has
to
be
a
state
model
but
they're
getting
caught
up
on
some
of
the
permutations
that
human
even
was
missed
in
earlier
drafts,
which
says
I
got
that
non
on
a
client's
client.
You
know
for
permutations
trying
to
find
the
circuitry
audience.
Aw
server
is
not
defined
like
in
what
and
they're
getting
cut
up
around
like
some
of
the
operations
that
we're
introduced.
M
B
Okay,
so
we
are
out
of
time
just
quickly
so
three
things,
one
I'm
and
we'll
have
to
take
all
this
the
lists,
but
one
I'm
wondering
if
we
should
consider
a
flag
day
something
on
the
order
of
currently
the
guideline
to
say
you
know
as
soon
as
possible,
but
maybe
we
should,
as
important
group
say
how
many
years,
one
year,
two
year,
three
years
like
is
there
a
deadline?
Should
there
be
a
deadline?
If
so,
could
we
do
that?