►
From YouTube: IETF102-NETMOD-20180717-1330
Description
NETMOD meeting session at IETF102
2018/07/17 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
C
C
C
C
C
C
We
are
yes,
we're.
Also
using
ether
pad
so
we'll
be
taking
notes
there.
I
won't
be
doing
any
of
those
things
since
I
guess
we'll
be
presenting
from
my
laptop
all
right.
So
we
have
two
sessions
this
week.
This
is
session
1,
obviously,
and
session
2
is
actually
on
Friday
morning.
We
intend
to
use
both
of
these
sessions
fully.
So
if
you
were
planning
and
skipping
Friday,
because
you
thought
it
would
be
light,
we
do
have
a
full
agenda
there.
C
C
That
is
the
design
team
exercise
and
that
actually
is
expected
to
take
up
the
balance
of
this
session
session.
2
we're
going
to
look
at
a
bunch
of
the
recent
submissions
or
documents
that
we
have
taken
updates
for
right.
Surely
I
believe
that
we
have
at
least
seven
of
those
currently
scheduled,
and
since
the
last
meeting
we
have
two
new
rfcs
RFC
83,
48
and
83
49,
so
that
is
the
entity
module
and
the
ad
22
Biss
work.
C
C
Acl
model
is
in
iesg
review
right
now
and
schema
mount,
which
you
know
we
actually
managed
to
get.
Closure
on
in
london
is
now
also
in
RFC
an
ISDN
review,
so
the
things
that
depend
on
schema
mount
that
are
sitting
in
miss
ref
will
likely
shortly
exit
that
position
so
a
whole
bunch.
We've
we've
broken
a
logjam
and
a
whole
bunch
of
documents
are
coming
free.
C
C
B
Don't
have
too
much
more
to
add
and
what's
on
the
slide,
the
one
thing
I'll
point
out
is:
is
that
I
believe
the
broadband
forum
liaison
just
got
refreshed,
it's
basically
the
same
liaison,
but
it
was
just
sent
to
list
so
clearly
they're
looking
for
some
reaction,
so
we
really
encourage
you
all
to
look
at
the
liaisons.
If
you
have
any
comments
on
them
or
have
any
thoughts
suggestions
on
responses,
if
you
think
they're
necessary,
please
send
those
comments
to
the
list.
D
Hi
Bob,
Wilson
and
I'll
just
say,
update
on
these
two
drafts,
so
there's
not
that
much
to
say
so:
go
through
relatively
quickly.
The
to
draw
scintillates
extensions
draft
is
adding
some
sort
of
common
functionality
to
interfaces
it
wasn't
in
the
original
interfaces
model.
This
work
has
been
going
for
quite
a
while
and
it
was
sort
of
slightly
languishing
because
the
nmda
work
took
priority.
Kissing
that's
out
finished
more
recently
have
now
updated
the
draft
of
the
examples,
which
was
one
of
the
sort
of
key
outstanding
things
to
do
on.
D
My
hints
I
think
this
draft
is
pretty
much
or
very
closely
ready
for
it
last
call
there's
two
issues
that
still
remain
to
be
resolved.
The
some
comments
from
only
been
in
the
yang
box
reality
to
check
that
they've
been
addressed.
I
think
the
most
them
happen,
what
the
check
they've
all
been
done
and
then
there's
a
bandwidth
leaf
that
was
in
the
original
model
and
I'll
cover
that
in
a
bit
more
detail.
So
the
other
issue,
the
author
of
resolve,
is
this
ban
with
leaf.
D
Much
might
be
helpful
to
see
if
it's
useful,
to
include
this
leaf
and
is
where
their
goes
into
this
model
or
whether
it
goes
somewhere
else,
there's
a
better
place
for
it.
But
I
don't
want
that
to
really
hold
this
draft
up.
I
want
to
effectively
either
choose
one
where
neither
goes
in
and
we're
done
or
it
doesn't
and
we
move
on
without
it.
So
that's
that's
effectively.
Only
minor
things
to
resolve
so
I
think
that
this
one
should
be
able
to
go
to
working
group
last
call
fairly
soon.
E
I
think
these
drafts
are
excellent
and
very
good,
a
very
good
value
for
people
who
are
implementing
these
things,
but
I
had
some
troubles
in
using
these
drafts,
together
with
the
I
Triple
E
drafts,
in
particular
other
problem,
with
implementing
simple
configuration
for
for
a
transplant
which
that
takes
just
four
lines
in
open
wrt
but
of
course,
valleys
now,
a
yang
with
you,
dot1q
from
something
from
I
Triple
E,
which
is
a
terrible
overkill,
and
it's
not
structured
well
enough
to
be
able
to
just
take
some
power.
That's
around
for
my
work.
E
So
we
had
some
discussion
about
that.
So
I
would
like
to
ask
whether
there
is
some
option.
The
the
I
Triple
E
liaisoning
was
mentioned.
I,
don't
know
if
we
can
do
reviews
of
their
modules,
because
I
believe
some
kind
of
better
structuring
of
their
more
use
would
be
immensely
useful.
But
I
don't
know
if
we
can
really
I.
D
Like
this
so
I
think
the
answer
is
the
boats
probably
sailed
already
on
that
ones.
I
Triple
E
models
been
around
for
quite
a
long
time
and
it's
been
developed
independently
with
some
awareness
of
this,
but
they
want
to
have
their
own
I
think
they
have
their
own
configuration
model
already
for
those
devices.
I
think
they're
trying
to
provide
a
complete
solution
that
map's
quite
close
to
the
a
2.1
q
draft.
D
So
in
not
this
draft,
the
next
one
I
talked
about
I've,
given
examples
of
how
to
use
sub
interfaces
with
the
LTL
TPM
model
and
that
allows
you
to
do
transparent,
bridging
as
well,
maybe
not
quite
the
same
so
flexibility
in
terms
of
VLAN
awareness,
but
that
might
be
another
option.
I
see
somebody's
posted
a
draft
today
about
and
transparent
forwarding
or
something
again
I,
don't
think
is
tied
into
this
model,
but
potentially
should
be.
E
D
D
F
Scott
mansfield
ericsson,
also
a
frequent
attendee
of
I
Triple
E,
as
well
as
IETF
and
other
things.
So
this
issue
of
yang
coordinate
is
something
that
the
ietf
that
the
I
Triple
E
has
been
trying
to
take
very
seriously
for
the
last
year
or
so,
and
the
I
Triple
E
in
the
itu-t
have
been
coordinating
on
work
to
ensure
that
the
I
to
use
performance,
monitoring
aspects
that
the
they're
creating
the
yang
model
on
that
for
Ethernet
and
it
needs
to
work
with
the
dot1q
and
the
CFM
modules
that
the
I
Triple
E
is
creating.
F
Okay,
that's
my
preface
the
to
back
up
your
point
about
dot1q.
The
dot1q
document
is
passed
whatever
the
magic
process
is
in
the
I
Triple
E
to
become
an
I,
Triple
E
standard,
and
so
that
that
draft
and
all
the
associated
modules
associated
with
it
are
what
you
got.
What
you
got
right
now
and
that's
going
to
be
the
standard.
There
is
upwards
of
eight
or
nine
other
modules
being
done
in
the
I
Triple
E.
That
also
have
to
work
in
augment
the
work.
That's
that
happens
in
dot1q.
F
So
it's
a
it's
a
pain
that
people
in
the
I
Triple
E
are
feeling
as
well.
So
having
said
all
of
that,
I
wanted
to
point
out
that
there
are
opportunities
for
collaboration
if
people
want
to
as
individuals.
There
is
a
meeting
of
a
yang
group
in
the
I
Triple
E,
the
last
Wednesday
of
every
month.
There
is
the
last
the
third
Monday
of
every
month,
there's
an
ITU
coordination
meeting
for
yang.
F
So
if
there
are
if'
people
that
are
interested,
if
there
are,
if
there's
work,
that
we
can
do,
the
I
Triple
E
does
use
the
yang
catalog
and
it
stores
its
drafts
there.
And
if
you
put
comments
on
the
drafts,
they
will
be
considered
when
you
look
at
the
yang.
That's
that's
in
the
yang
catalog,
so
there
are
ways
to
collaborate
and
ways
to
get
comment
back
in,
even
if
you're,
not
an
I,
Triple
E
member,
so
I'll
leave
it
there.
If
you
want
to
talk
about
that,
there's
lots
of
coordination
opportunities
thanks,
Scott.
B
F
Think
I
think
liaisons
are
helpful
because
it
didn't
it's
an
official
statement
from
the
working
group
to
another
another
group,
but
I
it's
helpful.
But
what
I
think
is
more
helpful
is
if
individuals
do
this
collaboration
that
we
have
a
couple
times
a
months
and
really
become
part
of
the
process,
because,
as
we've
seen
as
the
industry
changes
and
standardization
changes,
throwing
liaisons
of
one
another
is
not
the
way
to
get
progress
to
happen.
We
need
to
have
people
working
in
both
organizations
following
their
relative
organizational
paths
and
processes
to
get
change
to
happen.
F
D
I
think
actually
there's
a
fundamental
issue
here
that
there's
almost
two
different
configuration
models
that
involved
in
the
industry.
There's
one
there's
I
Triple,
E,
Don,
Q
based
and
there's
one
that's
IETF
based
I,
think
and
those
two
things
are
developing
in
parallel.
So
there's
going
to
be
issue
with
features
like
CFM
that
bling
long
sigh,
triply,
campin
and
and
actually
fit
into
that
model,
but
say
not
to
work
with
seven
phases.
So
so
I
don't
know
how
your
this.
F
Is
very
important
to
do
sure
at
that
point
as
well.
It
is
very
important
to
understand
that
the
CFM
module
that's
being
written
in
the
I
Triple
E
at
this
point,
is
being
written
so
that
it
can
work
without
being
tied
to
a
dot
1q
bridge.
Okay,
it's
the
same
for
the
work
that
the
ITU
is
doing
on
performance
monitoring.
It
doesn't
have
to
work
with
a
dot1q
bridge.
It
could
be
something
from
the
broadband
forum.
It
could
be
something
from
some
other
groups
at
once.
F
B
F
They're
already
well
my
opinion,
sorry
Scott
Mansfield
again.
My
opinion
is
that,
since
there
already
is
a
standing,
basically
a
standing
group
that
tries
to
coordinate
I,
eat,
EF
and
I
Triple
E
together
anyway,
getting
a
smaller
group
than
that.
That's
that's
focused
on
yang,
getting
the
something
that's
even
focused,
not
just
specifically
on
yang,
but
how
data
modeling
is
done
in
general,
because
what
happens
when
yang
becomes
the
has-been
and
there's
the
next
yang
right.
F
F
F
D
B
D
It's
not
it's
informative
ala,
normative
and
now
I
still
need
to
check,
with
the
dot
on
cue
working
group
that
they're
happy
with
the
change
that
I
made
previously.
So
that
needs
to
be
resolved
that
they
still
happy
the
structure.
I
hope
they
will
be
otherwise
again.
This
one
things
ready
for
working
group
last
call
I,
don't
have
John's
hit,
go
see
him.
So
any
questions
on
this
one,
a.
B
B
G
I
Everybody
right
so
this
is
just
an
update
to
module
tags
that
very
small
update
was
posted
recently,
basically
based
on
Andy's
comments
to
the
list,
and
so
that's
what
this
slide
will
address.
So
right.
There
was
a
recommendation
that
we
clean
up.
The
text
on
the
the
old
version
said
that
all
module
definitions
that
include
tags,
the
tags
would
be
standardized
I'm,
not
sure
if
he
meant
the
subtlety
that
I
took
from
that.
I
And
so
I
didn't
the
another
suggestion
was
well.
There
was
a
recommendation
to
vendors
to
put
an
org
name
or
something
that
would
probably
keep
collisions
from
happening
like
example.com,
so
I
took
that
in
I
didn't
adopt
the
extension
and
he
had
said
he
wanted.
He
thought
it
should
be
machine
readable,
but
it
adds
a
lot
of
complexity.
That
I,
don't
think
is
really
required
that
the
right
now.we
we
specify
what
tags
should
go
when
a
designer
wants
tags
added
to
a
module,
they
put
it
in
the
description
text.
I
That's
really
a
directive
towards
the
implementer
all
right.
It's
not
it's,
not
something
that
parses
it.
It's
not
something
that
goes
and
gets
parsed
and
then
Auto
generates
the
code
to
implement
a
model
right
I
mean
there's
actually
some
human
being
who
actually
writes
the
code,
and
you
know
this
is
so
adding
the
complexity
of
having
you
know.
Pi
yang
and
all
these
various
things
have
to
support
this
extension.
I.
Don't
think
it's
that
worthwhile,
but
that
was
it
from
the
comments.
I
think.
Oh,
there
was
one
other.
So
there's
two
other
issues.
I
I
What
the
Rob
and
I
were
talking
about
is
the
solution
we
have
here
we're
doing
something
in
this
in
this
draft,
we're
doing
something
that
might
come
up
later
in
other
other
people
might
need
and
that
we're
doing
some
concept
of
like
a
whiteout
right.
So
we're
deleting
something
through
configuration
right,
so
it
would
be
the
case
here
is:
if
a
vendor
adds
a
tag,
says
I
support
this
feature
and
then,
as
an
operator
I
say
no.
In
fact
you
don't
your
your
your
implementation
is
buggy,
so
I
want
to
remove
that
tag
right.
I
I
Don't
think
this
should
be
the
driver
for
that
I
think
we
have
a
fine
solution
here,
but
it
might
be
something
to
think
about
and
if
we
do
come
up
with
some
better
solution
before
this
gets
published,
then
we
could
incorporate
it
but
again,
I.
Don't
think
we
should
block
on
that
right.
So
I
think
we're
probably
ready
for
working
the
blast
caller
to
ask
for
it.
C
J
C
C
K
Okay,
Ken
Watson
Jennifer
networks
presenting
yang
data
extensions.
This
is
presented
last
time
by
Andy.
We
actually
haven't
made
much
progress
on
the
draft,
but
to
recap
RFC
80/40
defines
yang
data
in
the
IETF
rest
cough
module.
It
was
never
intended
at
that
time
to
be
used
outside
of
that
draft.
It's
really
just
defining
protocol
operations
and
errors
for
rest
off.
Hence
it's
neither
an
ideal
definition
or
having
an
ideal
location
like
it
being
inside
the
restaurant
draft.
It's
not.
K
What
we
want
to
say
expect
it
if
you
know
from
other
module
designers,
the
draft
defines
the
current
draft
defines
two
extensions:
there's
the
Aang
data
and
an
augment
yang
data
next
slide.
Talks
about
both
yang
data
is
intended
to
be
a
better
definition.
It's
slightly
more
tightly
defined
than
the
version
that's
in
80/40.
It's
also
a
better
normative
reference
and
import
targets.
K
So,
if
the
you
know
you'll
be
importing
IETF
yang
data
instead
of
IETF
restaurants,
which
is
nicer
for
drafts
like
zero,
touched
and
instance
data
and
subscribe
notifications,
all
that
are
currently
wanting
to
use
yang
data.
Two
of
them
are
currently
pointing
at
this
draft
and
I
think
subscribe.
Notifications
is
still
putting
it
RFC,
80/40
notice,
I,
say
here
is
nicer
for
zero
touch.
It
used
to
be
that
it
was
needed
for
zero
touch.
K
K
K
So
one
of
the
extension
statements
it's
nice
to
have
the
other
ones
must
have
or
what
we
can
debate
what
it
means.
You
must
have
it
see
there
we
go
okay,
so
last
thing
we
actually
thought
we
were
done.
But
then
some
working
group
members
raised
viability,
concerns
and
concluded
that
a
proper
definition
should
be
part
of
a
new
version
of
yang
I.
Think
the
history
of
the
original
yang
data
that
was
even
in
rest,
conf
a
lot
of
I
recall.
E
E
Think
the
fundamental
problem
is
really
an
extension
is
defined
in
RFC
7950
as
something
that
attaches
Nanyang
semantics
to
two
statements.
Whereas
here
we
are,
we
are
changing
youngsil
inside
this
yang
data.
The
semantics
of
yang
statements
is
different,
so
I
think
this
violates
this
principle
and
there
are
I
guess
two
problems
to
this.
I
understand:
it's
really
something
that's
needed
and
it's
very
convenient.
E
The
way
how
to
redefine
yang
so
I
will
just
put
something
at
some
extension
at
the
top
and
then
I
can
use
a
different,
different
syntax
for
regular
expressions.
Let's
say-
and
things
like
this
so
I
I
believe
this
is
really
slippery
slippery
slope.
So
if
we
want
to
use
it
internally,
then
let's
use
this.
E
K
E
B
E
B
E
Example,
if
you
before
this
work
start,
if
you
asked
this
working
group
who
knows
about
something,
that's
called
yang
data
expansion,
I
would
say:
maybe
5%
of
people
would
would
admit
they.
They
knew
it.
So
it's
really
something
that
it
can
be
used.
It
can
be
useful,
but
I
wouldn't
recommend
to
give
it
to
people
as
a
standard
to
for
the
data
modeling,
because
it
just
really
finds
quite
important
things
in
in
the
yang
that,
like
the
XPath
context
and
and
so
on,
and
so.
E
It
really
undermines
the
value
of
yang
as
a
standard
and
I
think
it
was
in
ideas
87
that
I
proposed
to
change
the
definition
of
en
to
remove
the
net
from
specific
parts
and
so
on
and
to
enable
such
uses
as
we
now
have.
But
this
didn't
happen
and
I
don't
know
if
I
think
it's
not
the
right
way
to
do
it.
This
favor
extensions.
K
L
K
That
being
the
case,
there
wouldn't
is
it.
You
think,
there's
a
possibility
that
there
could
be
an
applicability
statement
or
something
like
this
inside
this
draft.
That
would
sort
of
I
mean
I,
don't
know
if
it's
the
right
play,
you
think
I'd
ability
statement
would
really
be
about
yang
data,
not
so
much
the
use
of
the
extension
and.
B
E
E
One
of
them
was
this
syntax
for
for
patterns,
I,
don't
know
there
were
other
points
like
this
and
so
far
my
understanding
was
that
really
you
can
use
it
as
in
an
ACM,
for
example,
there's
an
extension
that
that
attaches
some
some
authorization
related
semantics
to
to
yang
statements,
which
is
okay
or
for
relational,
has
nothing
to
do
at
the
end.
So
that's
fine,
but
as
soon
as
we
start
changing
what's
written
in
RFC
7950,
then
it's
it's
really
a
problem.
B
Since
we
have
what,
since
the
base
extension
that
we're
talking
about
that
I
think
you're
really
talking
against
is
already
in
an
RFC,
maybe
what
you
really
want
to
do
is
put
out
a
draft
that
says
this
is
the
right
way
to
use
extensions
and
in
there
capture
what
you're
talking
about,
and
we
can.
We
can,
as
a
group,
agree
with
you
or
disagree
with
you
and
then
follow.
D
D
E
I
would
be
happy,
and
this
is
actually
what
I
proposed
in
Berlin
a
couple
of
years
ago,
and
so
it
means
what
we
could
do
is
to
really
remove
the
net
comfort
specific
part
to
make
to
make
basically
yang
just
limited
to
defining
the
schema
and
things
like
what
we
have
in
our
system
to
950
like
different
data
stores
and
xml
encoding,
which
is
the
only
encoding
actually
officially
find
at
the
time
for
for
en.
So
I
think
this
could
be
done
really.
E
K
And
just
clarify
what
I
was
saying:
I
think
that
if
a
new
version
of
yang
were
to
come
out,
it
might
find
this
statement.
Yang
data
is
a
top-level
statement,
but
without
the
use
of
the
extension
statement
it
would
just
be
yourself
a
top-level
statement.
So
in
that
sense
it
wouldn't
be
polluting
what
it
means
to
have
an
extension
statement.
Maybe.
E
K
Think
it
would
be
to
use
yang
to
define
the
data
model
without
any
notion
of
where
that
data
models
being
used
if
its
configuration
or
state
or
file,
or
it's
just
the
model.
Okay,
so
great
conversation
which
leads
us
right
into.
How
should
we
proceed
as
a
working
group?
We
have
three
options
in
front
of
us.
I
think
the
first
option
is
to
stick
with
the
current
scope
of
defining
both
the
yang
data
and
the
augment
yang
data.
The
second
option
is
to
only
define
augment
yang
data.
K
Remember
there
was
the
nice
to
have
and
must
have
so.
This
would
actually
still
provide
for
those
other
drafts
that
wanted
to
use
or
need
to
use,
augment
yang
data,
or
we
could
unadopted
this
draft,
which
would
mean
that
those
other
drafts
that
are
currently
referring
to
this
draft
would
have,
to
then
point
to
RFC
80/40
and
for
those
drafts
that
want
to
use
augment
gang
data
where
you
just
kick
the
can
down
the
road
and
they
need
to
revisit
this
idea
later.
K
H
B
K
F
Kill
Clark,
Cisco
I
would
prefer
one,
but
I
could
also
live
with
two
I
I.
Can
what
you're,
saying
and
I
like
your
idea
that
the
yang
next
I
want
an
augment
yang
data
or
I
want
some
way
to
you?
I
want
some
way
to
define
a
thing,
something
to
represent
a
thing
that
isn't
necessarily
implemented
on
a
in
a
datastore
and
then
I
want
to
be
able
to
augment
that
I.
Don't
think
any
of
the
other
drafts.
What
I'm
working
on
is
currently
internal
I.
F
C
B
B
D
B
C
C
Right
I
mean
that
that's
actually
a
fairly
important
distinction
like
I
use
lots
of
stuff
that
I
don't
like
very
much
right.
That
is,
in
fact,
you
know
the
nature
of
some
IETF
work
right,
but
it's
really
important
if
you
can
divine
that,
like
people
have
genuinely
good
reasons
why
they
really
don't
want
to
do
something
like
those
are
important
super
important
to
capture
like
if
they
exist
so.
K
As
as
far
as
improving
the
document
to
getting
to
last
called
there
I
do
have
next
slide
covers
one
issue,
but
in
addition-
and
that's
the
only
one
issue
I'm
aware
of,
but
in
addition
to
that,
I
do
recall
a
little
while
back
and
saying
something
about
the
wanting
to
clean
up
a
little
bit
more.
The
definitions
in
this
document.
If
we
were
to
move
forward
with
it.
So
even
though
I'm
only
gonna
cover
one
issue,
there's
actually
two
but.
B
Before
you
go
there
at
some
point,
when
we
start
talking
about
how
we
add
features
to
the
language,
it's
gonna
be
worthwhile
to
consider
that
there's
multiple
ways
to
do
it,
whether
we
do
something
like
a
1.2
or
we
use
this
extensions
and
I
actually
accept,
but
I
think.
A
lot
of
this
implication
is
that
we're
actually
not
using
we're
abusing
the
language
a
little
bit.
But
if
that
allows
us
to
be
a
little
more
nimble,
you
know
that's
not
necessarily
a
bad
thing
and.
K
D
Rob
Wilson
so
based
on
Ladas
coming
I
would
like
to
retract
my
option.
3
and
I
know
he's
fortune.
One
actually
I
think
if
he's
saying
that
people
were
to
use
this,
it
makes
sense,
but
and
also
to
go
to
lose
comment
that
maybe
we
should
consider
whether
we
refine
how
extension
states
allow
to
be
used.
If
the
issue
is,
it
is
one
about
how
extension
sounds
to
defy
today
and
limiting
the
scope
and
we're
finding
that
this
is
hampering
us
and
making
our
life
harder.
Should
we
consider
changing
that
I
think.
D
G
K
Great,
so
now
that
we've
I
think
our
iterating
towards
option
number
one
there
a
question
with
regards
to
the
yang
data
definition
and
specifically,
if
yang
data
can
have
the
same
name
as
he
top-level
node.
So
is
this
legal
or
not?
You
have
module
foo
with
container
bar,
but
also
yang
data
containing
container
bar,
and
so
the
options
here
are
yes,
it's
legal
because
only
one
bar
can
exist
in
any
given
context.
K
Andy
is
definitely
in
the
know
category
on
this
on
this
one.
So
probably
it's
long
Jerry's
about
to
say
that,
but
he's
definitely
thinking
that
need
to
have
you
know.
Given
an
instance
document,
he
feels,
like
you
know,
knows
I,
say
the
instance
document
alone
with
no
context
so
he's
thinking,
there's
no
extra
context.
So
in
that
case
you
don't
actually
know.
K
M
K
K
K
All
right,
yes,
sir,
so
actually
could
I
get
a
raise
of
hands
for
those
who
think
that
this
should
be
allowed.
It's
legal,
I
and
Martin
I
know
Martin
also
feels
like
there
should
be
allowed
so
a
few
and
then
for
those
who
think
it
should
not
be
allowed.
Please
raise
your
hand
and
also
a
few
but
more
double,
probably
I.
Think
so
and
I
know
sorry.
There's
comment
coming
to
microphone.
E
Vodka
understand
way,
it
is
important
to
to
say
no
here
because,
of
course
it
can
break
tools
who
just
want
to
have
one
yang.
They
turn
out
in
in
this
top-level
context.
But
in
fact,
if
young
data
is
used
for
defining
an
error
message,
there
is
really
no
reason
why
the
error
message
couldn't
have
borrow
whatever.
So
it's
really
some
CLR
that
and
I'm
afraid
that
we
will
need
to
come
up
with
more
such
cos.
You
know
in
order
to
make
this
thing
work
in
it
with,
so
it's
really
complication
and.
K
I
think
actually
ami
made
that
exact
same
point
about
tools
and
how
we
might
have
to
go
back
and
revisit
some
tools
to
ensure
they
don't
break
so
so
I
think
more
people
were
favoring.
No
and
I
know
that
Martin
and
I
had
previously
an
author's
meeting
said
that
we
would,
you
know
capitulate,
and
you
know
if
it's
okay,
we're
not
gonna
we're.
Okay,
we
can
live
with.
No
is
one
trying
to
say
so,
assuming
that
we're
moving
towards
no.
K
N
K
N
K
N
N
K
K
Illegal,
if
we're
choosing
no
and
we're
saying
that
this
should
not
be
legal
and
if
you're
saying
that
this
whitey
yang
data
was
actually
brought
into
this
module
through
an
import
of
a
sub-module
like
an
include
I,
shouldn't,
say
important
and
include
that,
then.
That
would
also
not
be
legal,
because
when
you're
using
includes
it's
just
a
way
of
factoring
your
yang,
it
doesn't
actually
change
the
nature
of
namespaces.
So.
N
N
K
D
D
So
a
very
quick
update,
the
design
team's
been
doing
it
was
formed
after
ITF
101
took
a
while
to
get
going,
but
once
you
get
going,
we
had
weekly
meetings
the
last
couple
of
months.
The
focus
being
is
very
very
specifically
on
the
problem
statement
and
the
requirements
themselves
rather
than
any
solutions
or
solution
discussions.
There
has
been
some,
but
that's
what
focus
has
been.
D
We
have
produced
a
requirements,
draft
0-0
draft
and
that's
what
I'll
go
over
next
I
know
the
requirements
in
detail
and
there'll
be
some
discussion
on
what
the
next
steps
could
or
should
be
and
I'll
cover
that
at
the
end
there
may
be
a
slot
to
discuss
the
clark
law
draft,
which
is
one
of
the
potential
solutions
here
at
this
time.
So
we'll
see
how
time
goes
so
requires
draft
is
fairly
basic.
We
have
a
short
summary
of
the
problem
and
we've
included
the
in
the
background
information.
D
We
think
what
the
requirements
and
sort
of
problem
statement,
text
and
I'll
go
over
that
that
problem
statement
here
or
summary
of
it
and
then
the
requirements
and
then
afterwards,
I'm
going
to
be
asking
for
of
which
we
discuss
working
group
adoption
not
necessary
as
a
way
to
take
to
a
wait
RFC,
but
to
show
the
working
group
agrees
broadly
what
the
requirements
are
and
we
head
in
the
right
direction.
So
problem
statement
summary
and
Soyoung
versioning
in
terms
what
we
want
to
do.
D
Young
obviously
has
had
quite
a
rigid
way
in
terms
of
how
you
do
upgrades
in
the
past
that
they
have
to
always
be
fully
backwards,
compatible
and
effectively
in
the
market.
We
found
some
issues
with
that
and
that's
what
we're
trying
to
address
and
change
here,
rather
than
requiring
that
your
young
models
are
perfect
or
perfection
on
day
one
we
want
to
allow
them
to
evolve
over
time
to
the
right
solution.
The
current
mechanism
is
that
once
you've
published
your
young
model,
you
can
make
no
backwards
incompatible,
no
non
backwards.
D
Capacitor
changes
too
much
also,
you
are
allowed
to
add
new
leaves
you're
now
to
extend
the
value
space.
That's
something
that
you
can't
either
reduce
the
value
space
or
change
the
type
or
delete
a
data
node
of
X,
and
the
think
that
this
has
this
sort
of
in
flexibility
has
made
people.
Try
was
too
hard
to
get
young
models
to
be
perfect
and
appointment
published
them.
D
So
if
you
have
to
be
forced
to
a
new
path
than
every
client
that
was
using,
that
existing
path
is
now
forced
to
use
a
new
path,
an
impact
there,
and
if
you
change
the
module
name,
space
impact
is
even
worse,
so
everyone,
that's
interacting
all
the
clients,
interacting
that
much
obviously
now
have
to
interact
the
new
module
name
and
all
the
imports
that
are
important.
This
will
also
need
to
be
updated
to
import
that
you
what
your
name.
D
So
if,
for
example,
you
wanted
to
make
an
on
backwards,
capacitor
change
to
ITF
interfaces,
perhaps
when
the
miner
leaves,
for
example,
if
you
are
forced
to
change
it,
to
ITF
interfaces
to
then
effectively
you're
going
to
fragment
the
include
or
import
statements
from
all
those
other
modules.
So
so
that's
not
really
necessary
a
viable
solution.
D
There's
some
other
related
issues
as
well.
That
aren't,
quite
so
so
directly
tied
to
back-fat
abilities
were
related
to
this
whole
thing
about
lifecycle
of
models,
and
one
of
the
means
that
today
the
way
that
yang
defines
States
deprecated,
it
gives
the
server
the
choice
as
to
whether
or
not
it
implements
this
note,
and
that
means
that
a
client
that's
interacting
with
one
of
those
servers.
If
they
see
a
node,
that's
not
status
deprecated.
They
do
not
know
whether
they
with
the
service
going
to
implement
that
or
not.
D
D
D
They'll
say
you
could
use
this
other
API
instead
or
give
an
explanation
as
to
why
it's
go
away
so
currently
yang
doesn't
have
that
the
state
of
statement
just
says
you
know
what
the
current
status
is,
and
although
you
have
the
option
or
maybe
of
updating
the
description
statement
associated
with
the
data
node,
a
better
solution
probably
is
to
have
a
description,
state
or
equivalent
tied
in
with
that
status.
So
you
can
actually
say
it's
been
deprecated.
D
We
have
it's
just
not
pragmatic
that
with
the
models
have
been
developed
in
ITF,
then
you
have
this
option,
and
almost
science
is
heading
for
that
wolf
of
creating
a
close
to
perfect
model
from
day
one,
and
that
you'd
be
very
strict
and
say.
Okay,
we
won't
allow
any
non
backwards,
compatible
changes,
the
cost
of
that's
too
high,
but
when
it
comes
to
the
vendors
and
things
and
these
yeah
models
are
often
being
generated
from
other
internal
data
models
and
those
internal
data
models
may
well
be
quite
closely
aligned
to
implementation
or
the
hardware.
D
So
the
requirements
themselves-
there's
five
slides
for
these
I-
think
about
50-
requires
in
total
my
intention
here:
I've
grouped
them
by
the
sect
intersection
and
that
they
come
under
I
will
go
re
through
each
the
requirements.
To
summarize
it
and
then
if
people
have
got
any
comments
or
questions
on
those,
then
please
come
up
as
I
go
through
these.
D
So
the
first
requirement
necklace
is
required
to
update
a
module
in
a
non
backwards
compatible
way
without
forcing
all
modules
with
import
dependencies
on
the
updated
module
from
being
updated
at
the
same
time
and
so
effectively.
What
you're
saying
is
that
when
you
want
to
update
a
module
in
on/back
was
collateral
way,
you
need
have
an
easier
mechanism
that
allows
other
people
that
are
import
not
to
have
to
change
their
import.
D
D
If
you
are
interacting
with
one
these
modules
that
you,
if
you
make
an
on
back
with
a
class,
will
change
it's
not
good
enough
to
say
oh
well,
the
answer
is
to
use
a
new
module
name
or
to
use
a
more
new
module
namespace
or
to
say
you
have
to
add
a
new
data
node
to
represent
this
and
Mark.
The
previous
one
is
deprecated
that
is
too
expensive,
and
the
specific
comment
here
is
that
if
there
was
say
small
subset
of
module,
maybe
was
under
a
feature
statement.
D
It
was
something
that
was
added
in
later
on
in
the
process
and
it
didn't
really
get
enough
review
or
coverage
and
people
weren't
using
it
and
then
at
the
point
that
they
come
to
use
it
they
fail.
Actually,
this
is
broken.
I
need
to
fix
this,
and
the
only
way
to
fix
that
is
either
by
saying
oh
I've
got
to
read
the
whole
module.
So
all
the
bits
of
the
module
that
are
fine
are
being
used.
D
You
force
a
namespace
change
or
module
name
on
that
or
your
force
effectively
to
continue
supporting
this
deprecated
part
and,
at
the
same
time
support
a
new
revision
of
a
fix-up
model,
so
we're
suggesting
that
there
needs
to
be
a
way
to
handle
that
the
third
requirement-
that's
related
to
this
is
that
a
refined
form
of
yang's
import
statements
must
be
provided.
That
is
more
restrictive
than
an
import.
Any
revision
I
just
import
and
less
restrictive
than
import.
A
specific
revision
input
by
revision.
Once
number
collateral
changes
to
modules
are
allowed.
D
The
refined
import
statement
is
needed
to
express
the
correct
dependency
between
modules.
So
so
what
yang
has
today's?
You
can
either
import
a
module
and
not
specify
a
revision
in
which
case
is
ambiguous
as
to
what
revision
you
get
an
implementation
is
only
allowed
to
implement
one
revision,
but
it
can
import
multiple
ones
and,
and
so
that
allows
the
modules
to
float
and
be
modified
and
updated.
D
So
I
think
the
import
by
revision
doesn't
really
necessarily
work
that
well
I
think
it
is
too
limited.
The
cases
where
you
can
use
it
in
a
sensible
way,
I
think
is
very
small.
Maybe
some
types
and
things
so
what's
being
proposed
here
in
the
requirements
is
saying
there
needs
to
be
something
that's
between
those
two
extremes
where
you
can
say:
I
want
to
import'
a
set
of
revisions
with
this
major
version.
Number
of
these
sets
of
major
version
numbers
or
any
minor
version
number.
This
may
fix
major
and
any
oh.
I
Chris
yeah
Chris
ups
italicum
so
that
I've
been
a
proponent
in
the
past
of
just
using
the
namespace
name
change.
So
it
looks
like
two
of
these
requirements
are
specifically
addressed
to
that
I'm
curious
I
mean
so
these
are
the
requirements.
Obviously
there
is
some
kind
of
justification
for
them
right
like
it's
too
hard
or
because
I'm
thinking
specifically
about
1.1
right
I
mean
why?
Wouldn't
you
want
to
go
back
and
at
least
look
at
your
I
mean
if
you're
importing
a
model,
and
you
have
now
a
backwards
incompatible
change
right?
I
I
I
I
You
don't
want
any
of
those
modules
to
automatically
use
the
new
model
until
you've
actually
looked
at
it
right
I
mean
that's
working.
You
have
to
do
when
you
make
a
backward
in
battle
change.
If
you
want
to
use
the
new
model
right,
I
mean
you
don't
have
to
use
the
new
model,
you
could
be
using
the
old
battle
still
and
then
everything
keeps
working
it's
only
when
you
want
to
update
to
the
new
model
that
the
namespace
changes,
and
then
you
have
to
go
change.
D
So
if
it
was
right,
if
interfaces
example,
you
were
completely
restructuring.
It
then
I
think
that
sort
of
thing
you
say:
well,
it's
fair
enough
to
define
an
ITF
interfaces.
That's
probably
the
right
answer,
but
if
you
were
changing
something
that
is
not
gonna
break
all
those
imports.
If
it's
like
a
leaf
in
the
model
list
that
you're
changing,
you
know
backwards
compatible
way,
then
it
seems
quite
a
lot
of
work
to
then
say:
I
want
to
change
this
one
leaf.
D
I
made
it
I
made
a
mistake
here
out
of
a
buck
and
I
want
to
change
it
or
to
change
its
type
and
then
you're
forced
effectively.
Everyone
has
to
update
their
imports
to
do
that.
To
pick
up
that
latest
leaf
and
they're
not
going
to
be
impacted,
so
I
think
this
stills
meant
to
be
some
common
sense
in
terms
of
what
numbers
classical
changes
are
meant
to
be
I,
don't
think
we're
trying
to
say
there
should
be
free
rein
and
anyone
do
anything.
I,
don't
think!
That's
the
aim
here.
I
J
So
Tim
Karen,
okay
just
to
fall
on,
but
isn't
what
you're
saying
in
1.2?
Just
what
you
said
you're
trying
to
get
away
from
what
you're
saying
is
in
1.2
I?
Have
it
a
leaf
node
call
it
foo
yeah
right
that
I
change
in
a
non
backward
compatible
way
and
the
client
still
will
reference
foo
right,
even
though
he
doesn't
know
it's
not
backward
compatible
or
potentially
so.
D
B
J
Understand
I
read
them
all:
okay,
okay
and
so
Mike,
and
this
is
the
one
requirement
that
I
had
a
concern
about
was,
was
because
I
looked
at
it
from
the
standpoint
of
the
client
having
something
called
foo
right.
That
was
not
backward-compatible
that
if
I
read
this
requirement,
that
said
well,
I'm
required
to
not
give
you
any
indication
that
this
is
not
backward,
that
this
is
as
a
client
I.
Don't
know
that
this
is
not
backward-compatible,
that
data
node,
that
leaf
node
foo,
that
I'm
using
right.
D
J
Q
You
tell
who's
it
from
away
I
feeling
that
too,
here
you
are
consider
the
case
where
you
are
greatest
server
to
a
new
version
which
is
not
backward-compatible.
You
want
the
client
to
run
smoothly
in
backward
compatible
way.
What
happens?
The
other
way
around?
You
are
create
a
client
in
you
know,
using
a
young
model
which
is
not
backward-compatible
and
you
don't
upgrade
a
server.
Q
Are
you
consider
in
this
case
and
consider,
for
example,
the
situation
where
you're
a
very
archaic
controller,
which
is
controlling
multiple
domains,
and
you
have
a
new
features
and
the
subs
a
subset
of
this
domain,
suppose
a
new
feature
and
knows
a
subset
of
both
domains.
Do
not
and
do
not
agree.
If
you
consider
also
this
use
case.
D
So
I
think
the
versioning
is
happening
between
a
client-server
interaction.
We
are
certainly
considering
the
case
that
you
want
to
do
some
sort
of
control
and
maybe
version
selection
between
those.
So
in
the
case
of
our
controller,
we're
talking
to
servers
where
some
of
them
support
some
functionality
and
some
some
don't
I
would
expect
there
to
be
some
negotiation
on
each
of
those
or
so.
Q
Q
D
If
you
had
a
client,
you
can't
have
a
client
talking
a
new,
a
young
model
to
serve,
took
an
older
one,
I
think
I,
wouldn't
work
I!
Think
we've
got
you
can
detect
that
case,
because
you
know
what
you
can
know:
what
versions
that
the
server's,
using
through
yang
library,
okay,
you
tell
you
could
detect
that
today.
D
Q
True,
true
true,
but
you
can,
if
you,
if
they're
great
is
us,
you
are
the
new
nodes,
a
new
leaf
and
leaf
is
associated
with,
for
example,
with
a
feature.
Then
a
young
model.
You
can
agree
the
server
the
client
without
a
grade
in
the
server
and
the
server
will
be.
You
don't
have
the
feature.
Something
like
that.
So
I
say
that
gonna
you
can.
If
you
have
the
new
features
to
your
young
model,
you
would
have
the
optional
feature
yeah.
As
soon
as
you
talk
with
an
older
server
that
doesn't
support
the
feature.
Q
D
Think
you
still
end
up
I
think
something
you're
maccalister's
do
the
same
thing.
So
one
of
the
in
terms
of
requirements.
The
requirement
is,
we
are
condoms.
The
later
accounts
are
should
we're
taking
away
obviously
yang's
for
compatibility
effects.
You've
always
upgrade
things,
and
as
part
of
that,
we
require
to
say
what
are
we
going
to
offer
stet
the
way
to
support
existing
clients.
P
Yeah
you
go
Bruce.
Can
I
way
I
support
the
issue
that
it'll
just
raise.
So
if
the
client
walks
a
was
20
sewers
and
works
in
exact
same
way.
So
now,
if
you
have
like
a
model
which
is
not
that
good
compatible
right,
some
of
them
do
things
differently
from
others,
and
there
is
no
common
ground,
okay
on
which
you
can
scale
down
and
come
up
with
a
common
solution
right.
So
it's
a
big
issue
so.
M
Well,
as
Daniel
Erickson
I
think
that's
the
case
today
as
well,
because
you
can
just
obsolete
or
deprecated
something
tree
it's
gone,
and
then
your
client
suddenly
finds
that
oh
I
thought
this
was
compatible,
but
it's
not
there
anymore,
also
for
the
other
way
around.
For
if
you
need
a
feature,
you
need
to
check
the
provision
of
the
model
on
the
yank
server.
D
Are
five
sets?
That's
true,
okay,
this
is
harder
to
read
so
readers
of
readers
of
modules
and
tools
that
use
modules
must
be
able
to
determine
where
the
changes
between
two
revisions
of
modules
to
do
to
backwards
compatible
on,
but
compatible
version
change.
In
addition,
it
may
be
helpful
to
identify
whether
those
changes
represent
bug
fixes
new
features
of
both.
D
Is
it
new
functionality
or
is
it
major
new
functionality
and
then
requirement
to
point
to
a
mechanism
should
be
defined
to
determine
whether
data
nays
between
two
arbitrary
yang
module
revisions
have
one
not
changed
to
change
them
backwards,
compatible
way
and
three
changing
a
numbers
compatible
way.
So
where
is
requirement
to
that?
One
is
at
a
module
level.
D
It's
saying
whether
or
not
the
whole
module
has
been
changed
in
the
backwards
compatible
numbers
collateral
way,
2.2,
which
is
a
huge
rather
than
us,
is
actually
looking
at
and
tracking
backward
compatibility
on
a
per
data
node
basis,
and
this
may
be
particularly
important
where
you
have
where
clients
are
using
in
subsets
of
modules,
rather
than
entire
all
the
leaves
in
a
module.
Then
they
may
be
particularly
interested,
whether
the
subset
that
they're
using
they
can
move
between
an
older
revision,
a
new
revision.
D
R
D
Should
probably
be
included,
schema
nodes?
Well,
you
wanted
the
not
risky
nodes
of
the
right
answer
as
well.
I
think
it
might
be
day
no
I
can't
what
the
definition
is,
but
yes,
those
but
you're
not
trying
to
track
the
change
of,
say
a
type
statement
itself
you're
to
tie
it
tight
to
the
actual
thing.
That's
instantiated
in
the
model
schema.
D
You
know
the
questions
on
these
or
shall
I
move
quickly
on
to
try
and
get
through
all
these
requirements
we
can
come
back
so
requires
three
supporting
existing
clients.
So
this
is
all
about.
We've
had
some
discussion
about
in
terms
of
how
do
you
handle
clients
they're
already
talking
to
the
server,
and
so
the
solution
must
provide
a
mechanism
to
allow
servers
to
support
existing
clients
in
a
backwards
compatible
way.
So,
whatever
solution
to
me,
these
requires
comes
up
with.
D
It
has
to
have
a
way
that
you've
got
an
older
client
talking
to
the
server
that
can
continue
to
talk
to
that
server
or
the
least
be
a
mechanism
or
a
way
how
to
support
that
and
then
related
to
that
is
3.2,
and
the
solution
must
provide
a
mechanism
to
allow
service
to
simultaneously
support
clients
using
different
revisions
of
modules.
A
client
choice
of
particular
vision
of
one
or
more
modules
may
restrict
the
particular
vision
of
other
modules.
Like
me,
that
may
be
used
in
the
same
request
or
session.
D
So
this
requirement
is
saying
that
the
any
solution
space
needs
to
be
have
a
way
that
clients
can
choose
which
module
revisions
or
versions
they're
talking
to
and
that
doesn't,
but
they
don't
have
free
rein.
They
can't
say
I
want
to
have
maybe
one
version
of
the
BGP
module
and
a
completely
different
version
of
ITF
interfaces
module
where
there's
dependencies
between
them.
D
This
probably
means
that,
actually,
when
you
select
one
version
or
module
or
a
set
of
modules
that
you
you're
selecting
between
a
set
of
them
and
that
affective
constrains
the
space
you
active
example,
this
concrete
example
might
be
that
you
have
a
vendor,
that's
producing
particular
software
releases.
Maybe
they
say
well.
We
support
an
order
revision
of
our
software
and
the
later
one
or
something
similar.
Something
like
that,
so
that
one's
a
lot
suggesting
any
comments
on
these.
D
K
As
a
contributor
yeah,
so
when
you
say
existing
clients
here,
do
you
mean
clients
too,
that
are
today
clients
using
existing
yang?
They
stamp
sort
of
version?
Or
do
you
mean
like
more
forward-thinking
that
after
semver,
whatever
the
solution
is
existing
clients
at
that
time,
and
then
you
are
moving
to
the
next
version,
so
I
think
existing
clients.
D
D
I
I
S
I
B
D
So
the
fourth
set
requirements
is
documenting
data
node
life
cycle,
so
4.1
on
my
velocity
super
smear
for
the
1a
mechanism
is
required
to
allow
a
client
to
determine
where
the
deprecated
nodes
are
implemented
by
the
server.
So
this
goes
back
to
today
that
the
deprecated
statement
doesn't
mean
that
the
device
is
necessarily
implementing
it
and
leaves
it
ambiguous.
So
there
needs
to
be
some
way
that
client
lease
find
out
whether
or
not
those
deprecated
nodes
will
be
implemented
4.2.
D
If
a
data
node
is
deprecated
obsolete
and
it
must
be
possible
to
document
in
the
yang
model
what
alternatives
exist,
the
reason
for
the
status
change
or
any
other
status
related
information.
So
that
goes
back
to
the
same
comment.
I
had
early
in
the
problem
statement
that
when
you
do
deprecated
something-
or
you
know
you're
about
to
then
having
additional
information
on
having
mechanism
to
provide
information
to
readers
and
users
of
the
modulus
to
why
it's
gone
away
and
what
the
alternatives
are
is
required.
D
D
For
around
24.3
yeah,
a
mechanism
is
required
to
indicate
there's
certain
definitions
in
a
young
module
will
become
status
obsolete
in
future
revisions,
but
definitions
marked
as
such
may
still
be
implemented
by
a
compliances.
This
sounds
like
a
strange
one,
but
effectively.
It
means
that
if
we,
if
we
don't
change
the
definition
of
Yang's
deprecated
statements
to
mean
it's
still
supported
but
will
go
away
in
the
future,
we
don't
do
that
then.
Instead,
we
need
to
introduce
some
alternative
mechanism
to
do
the
equivalent
of
of
a
deprecated.
D
That
means
it's
supported
today,
but
it's
going
to
go
away
in
future
ie.
The
standard
definition
of
deprecated
you'd,
see
in
like
a
programming,
language,
API
and
then
four
point.
Four
which
is
not
even
us
life
is
wrapped,
is
if
multiple
revisions
of
a
yang
module
are
published,
then
the
solution
should
allow
for
bug
fixes
to
be
made
to
know
the
revision
of
the
module.
D
So
the
idea
here
is
that
if
you
have
multiple
release
trains-
and
you
are
updating
modules
on
different
release-
trains-
like
vendor
modules-
there
needs
to
be
a
way
of
putting
bug,
fixes
and
changes
to
those
older
release
modules.
It's
not
sufficient.
Just
to
say
every
change
or
bug
fix
has
to
go
in
to
the
latest
revision.
That's
not
pragmatic.
D
D
5.2
is
the
solution
is
required
to
describe
how
to
transition
from
the
existing
yang.
Wonder
I,
wonder
wonder,
scheme
to
the
new
scheme,
so
obviously
you
got
to
describe
how
we
migrated
from
where
we
are
today
and
then
5.3
is.
The
solution
must
just
describe
how
the
versioning
scheme
affects
the
interpretation
of
instance,
data
and
references
to
instance,
data
for
which
the
scheme
definition
must
be
updated
in
a
non
backwards
compatible
way.
D
So
this
one
is
quite
interesting
and
it
says
if,
for
example,
you
have
some
configuration
on
a
device
which
you
regard,
as
instance,
data,
and
you
then
update
that
device
in
a
non
backward
compatible
way.
What
happens
to
that
data?
What
happens
to
the
bits
that
are
non
box
compatible
or
another
case
would
be-
is
Blaze's
instance,
data
document,
where
that
is
defining
some
instance
data?
How
what
happens
is
the
modules
that
have
been
used
to
represent
that
data
have
changed
in
a
non
backwards
could
cut
away.
D
I
D
I
Yeah
because
I
mean
that's
what
these
are
speaking
to,
but
so
I
mean
I've
got
a
pretty
good
idea
that
I
don't
want
to
talk
to
solutions
too
early
right,
but
you
know,
that's
I,
think
the
thing
we're
really
trying
to
do
is
allow
for
I
mean
I.
Remember
you
saying
allow
for
changes
quickly,
but
I.
Think
a
lot
of
what
is
going
on
here
is
to
make
it
less
painful
for
clients
right.
I
So
you
want
like,
if
I
can
make
this
incompatible
change,
but
everybody's
gonna
keep
running
anyway,
because
they
don't
hardly
you
that
little
thing
over
there.
All
right,
you
know
and
there's
obvious,
like
semantic
versioning-
is
a
fit
for
all
the
requirements
you've
put
up
there,
but
really
what
we're
thinking
is
is
describing
the
things
that
changed
having
a
sub
may
be
an
automatic
way
to
do
that
right
and
linking
alright
and
the
major
version
number
of
the
semantics
is
really
just
the
linking
right.
I
So
I
guess
what
I'm
saying
is:
I,
don't
I've,
never
liked
the
major
version
of
the
semantics
I.
Don't
think
we
need
it,
but
we
we
might
need
a
way
to
say
this
namespace
the
new
version.
You
know
a
pointer
to
it
right
and
maybe,
as
part
of
that
metadata,
you
include
the
changes
right
that
you
know
anyway.
I
don't
want
to
jump
too
far
in
this
lessons.
P
I
O
I
T
Forum
or
juniper
Networks,
so
what
makes
me
a
little
bit
nervous
when
the
mayonnaise
is,
what
exactly
does
backward-compatible
mean
and
how
do
we
define
it?
Because,
obviously,
if
something
crashes,
you
know
it
wasn't
backwards
compatible.
But
if
you
already
want
to
write
something
saying:
okay,
I
need
to
decide:
is
it
not
backwards
compatible,
yes
or
no?
We
had
discussions
before
about
which,
which
statement
was
legal
and
whether
we'd
accept
it
or
not.
So
how?
T
D
Think
it's
fun
that
it's
worth
adding,
so
the
definition
we're
taking
is
the
one
that's
in
7950,
so
they've
got
a
description
of
updating,
a
module
and
the
and
the
rules
as
to
how
you
update
a
module.
Are
these
the
rules
on
what
you
have
to
do
in
a
backward
compatible
way?
So
any
changes
you
make
to
a
module
outside
what's
allowed
in
rc7
950
by
definition,
not
backwards,
compatible
change,
so
I
think
we
can
understatement
to
the
to
the
draft
to
clarify
that
yep.
Thank
you.
U
Vladimir
I
hear
the
sense
that
making
this
for
the
notes
level.
For
me,
it
feels
like
it's
over
engineering.
It
and
I
can
put
it
in
the
same
category
as
introducing
sub
modules
like
when
you
introduce
sub
modules,
and
people
start
using
huge
modules
of
multiple
sub
modules.
Suddenly
you
have
that
problem
that
you
need
to
introduce
solution
for
node
level
compatibility.
So
if
we
stay
away
of
that,
I
will
be
very
okay.
D
The
rules
are
quite
clear
and
you
can
pick
up
what's
changed,
but
what
you
can't
detect
automatically
is,
if
you
change
the
semantics
of
a
node
in
a
description
statement,
there's
just
no
way
that
Orion
can
understand
and
read
English
or
where
it's
written
in
and
so
the
idea
there
is
have
some
way
of
marking.
Those
changes
to
then
allow
this
tooling
to
work
and
actually
then
say:
okay,
this
part
of
the
module
is
entirely
backwards
compatible.
These
changes
are
not,
and
you,
as
a
user
of
that
module.
D
D
I
Have
to
say,
I
have
a
strong
objection,
I
mean
it
might
be.
The
only
one,
but
I
have
a
strong
objection
to
the
requirement
in
one
right,
because
you're
forcing
a
solution.
You're
saying
you
requirement
of
this
is
that
you
have
to
be
able
to
do
this
without
changing
the
namespace
and
I'm
saying
changing
the
namespace
is
one
of
the
solutions
that
you
can
do
everything
else.
You
want
to
do
through
a
different
mechanism,
but
leave
the
change
in
the
namespace.
So
having
that
as
a
requirement
is,
is
removing
all
those
solutions?
M
Ashley
angel,
Erickson
I,
actually
don't
really
agree
with
you,
because
the
reason
we
want
to
keep
the
name
space
and
the
name
module
name
in
this
next
requirement
is
that
it
is
sometimes
much
more
expensive
to
change
the
name
and
namespace
to
reflect
compatibility
than
to
deal
with
any
problems
that
might
be
raised
by
the
incompatible
but
changed
incompatible,
but
but
still
kept
namespace.
You
have
to
track
down
all
the
potential
clients
scripts
whatever
who
have
written
it's
impossible,
really
to
track
them
down.
M
So
it's
sometimes
it's
and-
and
it's
a
rare
in
the
rare
case
where
you
say
that
yes,
a
backwards
incompatible
change
is
validated
is
reasonable
and
it
should
be
a
rare
case.
It
is
much
cheaper
to
keep
this
because
once
you
start
changing
the
namespace
or
the
module
name,
then
that
means
that
all
your
importers,
all
your
clients,
be
that
just
may
be
a
little
script
that
some
operator
must
be
updated
so
that
one
line
you
mentioned,
one
line,
update
x,
I,
don't
know
many.
I
So
what
I
mentioned
this
at
the
very
end,
I
wanted
to
give
a
solution
right
that
this
is
what
you
could
do
with
linking
right.
You
can
have.
You
can
have
a
link
between
the
two
different
names
faces
and
you
could
have
the
clients
automatically.
You
know
you
can
still
have
an
automatic
upgrade
mechanism
right
where
they
run
with
the
new
module
because
they
know
they're
compatible
because
they
looked
at
the
list
of
things
that
would
make
them
incompatible
right.
I
I
E
B
D
I
think
Chris
is
come
sight
differently,
saying
that
maybe
there's
a
there's
a
prone
to
be
solve
here,
but
it
might
not
be
that
this
is
the
problem
that
the
problem
is
that
you
can't
handle
changing
the
names
of
modules
in
an
easier
way
and
potentially
a
different
solution
would
be
to
find
better
way
that
that
could
be
managed.
Is
that
fair?
D
B
It
would
be
worthwhile
to
see
just
sort
of
get
the
feel
for
the
room
of
how
many
people
are
feeling
comfortable
with
the
the
requirements
presented
with
an
understanding
that
we
need
to
fix
1.2
at
least
and
just
just
sort
of
get
the
the
feel
of
the
room.
So
I'll
ask
a
couple
of
questions,
comfortable,
not
comfortable
and
maybe
disinterested,
so
how
many
feel
comfortable
with
the
requirements
as
they
get
presented
for
the
problem
that
the
design
team
is
trying
to
solve.
B
I'd
call
that
a
pretty
reasonable
number
yeah
subject
to
the
modifications
have
been
discussed.
So
that's
that's
a
pretty
reasonable
number.
How
many
are
uncomfortable
with
the
requirements
as
they've
been
discussed,
I
see
no
one.
Oh
please
so
I
think
we
saw
one
person
raised
her
hand
who
I
think
they
very
been
to
the
mic
and
express
what
their
discomfort
was
and
they're
nodding
their
head.
Yes,
and
how
many
are
think
this
is
not
a
problem
that
we
should
even
be
talking
about,
and
no
one
on
the
lotta
is
still
in
the
room.
B
All
right,
okay,
well,
I,
think
that's
a
pretty
good
direction.
It
sounds
like
we
do.
You
want
to
try
to
address
the
issues
first
before
we
do
an
adoption
call
or
doing
an
option
call
on
this
version
and
with
the
understanding
that
we're
gonna
try
to
address
really
the
two
points
that
were
raised
here.
The
one
I
took
away
the
one
as
the
one
point
two
as
in
don't
be
prescriptive
or
could
don't
constrain
the
solution
and
then
the
other
one
was
if
I
understood
it
correctly
was
about
complexity.
S
C
Submissions
are
unlocked
now,
so,
if
you,
if
it
sounds
like
you
guys,
are
comfortable
either
way.
So,
yes,
if
you
have
a
new
draft,
then
that's
certainly
something
we
can
ask
about.
Jason
Stern,
like
it's
I,
think
at
the
last
working
group
and
still
now
seems
like
there's
a
lot
of
interest
in
progressing
on
this
topic.
So
I'm
not
sure.
If
there's
a
lot
of
point
in
not
adopting
it
that
working
groups,
thinking
about
it
and
working
on
it,
we're.
B
I
B
To
resolve
the
issue,
the
open
issue
that
was
raised
here,
so
why
don't
we
plan
to
pull
this
in
short
order
after
the
meeting
and
if
you've
published
a
new
version
and
that's
what
we'll
that's
what
we'll
pull
and
if
you
haven't
we'll
pull
there
and
for
those
who
have
comments,
please
feel
free
to
reiterate
them
on
email
if
they
haven't
been
addressed,
I'm,
not
sure
we
fully
captured
that
other
comments.
It
would
be
really
good
to
get
that
on
the
list.
So
thank
you
all
right.
K
And
if
I
could
just
Kent
as
a
contributor
with
regards
to
the
yang
data
discussion,
yang
data
I
mean
there's
a
name
space
but
there's
no
other
instance
data
or
anything
to
identify
what
version
of
the
module
was
used
to
encode
that
yang
data.
So
I'm
not
sure.
If
this
is
an
issue
requirements,
we
need
to
address
it
or
maybe
it's
a
problem.
The
yang
data
authors
need
a
resolve.
That's
in
that
I.
B
D
D
So
so
the
next
step
to
so
only
something
that
will
adopt
this
document
fey
soon,
we'll
continue
to
refine
the
requirements,
as
people
have
comments
and
things
I'll
stay
because
a
document,
but
the
next
step
for
us
is
to
actually
consider
the
possible
solutions.
So
I
want
quite
clear
that
solution.
Proposals
and
ideas
are
welcome.
Chris
in
particular,
you've
got
an
alternative
solution.
Please
PLEASE
sketch
it
out
to
us.
D
B
The
question
on
the
prayer-
yes
I'm,
not
sure,
yeah
great
thanks,
so
in
considering
possible
solutions.
Obviously
they're.
The
members
of
design
team
have
set
of
solutions
that
they're
familiar
with.
If
we
have
other
people
who
want
to
bring
solutions
such
as
Chris
or
someone
else
who's
out
there,
what's
the
best
way
to
sync
with
the
design
team,
you
want
a
full
draft.
Can
you
know
people
drop
you
email?
Do
you
want
it
on
the
on
the
other
on
the
list?
D
Certainly
I,
don't
you
need
a
full
draft,
I'm
happy
for
it
to
be
an
email.
I
think
that
the
low
barrier
to
entry
is
good
as
well.
It's
thought
out.
I
was
suggest
sending
that
the
design
team
copying
the
networks
is
fine
as
well.
There's
no
shoes
there
in
terms
of
and
again
you've
got
solutions
for
just
some
of
the
requirements
you
say
well.
I've
got
a
good
idea
of
how
we
could
solve
these
problems.
D
Then
then,
that's
fine,
that's
great
I
think
some
of
these
requirements
is
sort
of
a
fairly
obvious
solutions
like
the
deprecated
potentially
and
adding
a
description
statement
to
status
seems
like
a
no-brainer
almost
so
some
of
those
I
think
are
fairly
easy.
Other
ones
I
think
it's
more
more
pragmatic.
So,
whatever.
A
D
Easy
way
to
do
it
is
my
suggestion
and
I
think
we
should
also
send
an
email
out
to
the
network,
a
deist
to
highlight
this
thing
on
this
reading
to
say:
look
this
is
opportunity
and
I
suggest
maybe
trying
to
get
something
in
before
before
the
end
of
August,
because
I
think
it'll
go
quite
over
the
summer,
so
that
gives
people
some
time
we'll
pick
up
more
steam.
After
that
I
suspect
and.
B
Just
to
be
clear
from
a
working
group
process
standpoint,
the
design
team
isn't
the
working
group.
So
if
you
have
a
proposal-
and
you
talk
to
the
design
team
and
they're
not
keen
on
it,
but
you
are
there's
nothing
that
prevents
you
from
bringing
it
to
the
working
group
and
socializing
it
may
be.
The
working
group
will
even
accept
your
proposal
over
the
design
team
and
that's
not
hypothetical
attack.
That's
actually
happened
to
me
before,
where
I
disagreed
with
the
design
team
and
ultimately
the
working
group
accepted
the
solution.
I
had
proposed.
D
So
so
this
is
sort
of
hypothetical
slide
in
terms
of
if
we
were
to
go
forward
with
the
semantic
versioning
solution,
then
there's
various
aspects.
We
already
know
what
that
would
look
like.
So
it
would
look
like
that.
We're
going
to
add
a
thematic
version
number
to
yang
modules,
we're
going
to
potentially
add
an
import
by
version
number
or
range
of
version
numbers
or
a
major
version
number
dot
star
star,
but
effectively
we
would
be
modifying
or
extending
the
import
behavior
today
and
potentially
through
an
extension
statement.
D
We
would
be
changing
the
young
module
update
roles
that
are
in
7950
they're,
quite
strict
as
to
what
you're
allowed
to
do,
and
obviously
this
work
would
be
allowing
those
rules
to
be
broken
and
then
perhaps
again,
we'd
be
requiring
version
selection,
which
would
be
changes
for
protocols
or
extensions
to
the
protocols
to
be
able
to
select
in
some
way
what
version
of
software
a
particular
client
is
interacting
with,
and
that
may
also
require
changes
to
yang
library
effectively
to
represent
that.
So
it's
very
clear
that
this
would
work
as
it
looks
at
the
moment.
D
How
do
we
do
this
work?
So
does
this
mean
that
we
can
do
an
extension
statement
or
use
extension
States
to
modify
yang
in
this
way?
Can
we
do
it
an
RFC
that
that
only
defines
yang
versioning
and
doesn't
touch
the
existing
drafts,
or
does
this
require
a
yang,
1.2
or
yang
to
the
youngest
document?
And
if
we
do,
that
is
that
gonna
then
delay
this
work
by
a
long
time?
How
do
we?
D
How
do
we
do
this
work
in
an
efficient
way
to
get
to
a
good
point
without
it
taking
a
long
period
of
time
and
then
related
to
that?
Some
of
the
discussion
that
design
teams
having
it
they
had
related
to
sort
of
yang
next,
is
that
there's
a
load
of
other
stuff
in
yang,
then
the
yang
dross
that
could
be
cleaned
up.
You
could
take
the
xml
encoding
out
of
Yang
and
put
it
into
a
separate
RFC
like
the
Jason
one.
D
It's
it'd
be
good
to
take
the
net
mods
the
net
conf
related
text
out
of
Sendai
fifty
and
put
that
into
a
net
Protocol
draft.
So
there's
a
reasonable
amount
of
cleanup
work
that
could
be
done
to
the
yang
draft.
Could
that
work
be
done
in
parallel
to
this?
Does
that
make
sense?
You
know
what
what's
the
best
way
of
going
forward
if
we
end
up
doing
a
Clark
like
solution.
K
Kent
as
a
contributor,
so
I
mean
I
think
there's
two
approaches
what
one
could
use
a
yang
version
that
we
have
today,
but
that's
never
yang
module.
But
if
we
were
to
change
that
and
that
would
necessitate
a
change
in
yang,
we
need
a
new
version
yang.
Another
idea
is
to
define
an
extension
statement
called
you
know,
whatever
semantic
version
yang
whatever
and
but
the
problem
with
that
is
that
extension
statements
are
optional
to
implement.
K
V
D
I
Crabs,
so
this
is
a
the
pain
that
we're
feeling
at
BT.
Right
now
is
sort
of
a
it's
like.
We
get
a
thousand
models
right
because
the
the
vendors
update
their
models
on
every
compile
right
like
or
whatever,
and
so
so
I
mean
we
really
do
want
some
way
to
be
able
to
easily
say.
Okay,
the
model
didn't
actually
change
all
right.
I
don't
want
to
have
to
do
any
work,
so
not
actually
fighting
against
that
I
want
that.
This
is
what
actually
worries
me
right.
I
The
reason
that
I'm
so
resistant
against
the
namespace
changes,
because
you
can
maybe
do
all
of
this
work
without
requiring
you
know
we
can
get
all
the
benefits
if
we
could
approach
us
differently
right
you,
you
know,
if
you
have
a
sort
of
sideband
solution
right
where
you
you
haven't,
you
have
an
extension
or
whatever
that
says.
I'm
gonna
describe
how
these
two
models
are.
Actually
the
same
here
are
the
changes
now
I
can
write
my
client
software
and
it
can
automatically
just
work
with
the
new
version
and
I.
I
Don't
have
to
wait
for
yang
1.2
right,
which
is
deadly
long.
Yeah
I
mean
it's
just
it.
That's
the
problem
with
that
solution,
anything
that
requires
waiting
for
another
revision
of
yang
I.
Don't
know
it's
that's
a!
We
have
a
problem
now
right,
we
need
salt,
and
in,
like
you
said,
I
mean
it's
affecting
how
we
design
a
model
modules.
You
know
it's
affecting
everything,
so
yeah.
B
So
there's
definitely
gonna
be
different
options
out
there.
This
is
the
type
of
question
that
I
think
it's
really
helpful
to
evaluate
in
the
context
of
a
specific
solution
and,
as
is
always
good
engineering
principle,
if
you
can
solve
something
in
a
less
disruptive
or
simpler
fashion,
you
know
you
there's
going
to
be
a
bias
towards
that.
Of
course,
if
the
simple
solution
is
wrong,
you
know
it's
wrong.
E
I,
don't
care
I'm,
not
sure
if
it
was
mentioned
in
in
the
requirements,
but
what
happens
if,
if
a
module
specifies
Norma
Norma
import
by
revision,
with
an
exact
revision,
so
does
it
mean
that
the
new
solution
can
just
get
rid
of
this?
So
this
is
not
taken
into
account
or
because
if
so,
then
I
would
locate
the
option
off
of
going
to
a
new
young
version,
because
then
it's
again
what
a
relief
did
the
same
popeye
revision?
E
D
K
K
K
It
seems
to
the
first
effort
to
that
might
be
to
iterate
over
the
issues
and
github
tracker
and
evaluate
them
on
a
few
different
dimensions,
such
as
easy
hard
backwards,
compatible,
not
backwards,
compatible,
important,
not
important,
right
like
that
and
and
so
I
think
I'm
as
a
contributor
might
do
this.
If
others
would
like
to
work
with
me
on
that,
perhaps
we
could
have
a
even
an
interim
I,
don't
know
if
one
actually
called
an
interim,
but
we
could
do
something
like
this
to
try
get
some
more
understanding
about
what
that
might
be.