►
From YouTube: IETF100-NETMOD-20171115-1330
Description
NETMOD meeting session at IETF100
2017/11/15 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
As
Lou
just
mentioned,
and
we
do
have
etherpad
and
there's
the
link
on
this
on
the
slide
or
maybe
not
that
thing-
okay,
Soph
you're
too
late,
I'll
be
on
the
next
slide.
So
here's
the
note
well,
this
anything.
Do
you
say
or
do
you
know,
contribute
in
the
room?
It's
considered
an
IETF
contribution.
Please
be
aware
of
that.
A
As
mentioned,
there's
audio
Medeco
streaming,
it
is
recorded,
will
be
posted
to
youtube
later.
On
so
make
sure
you
use
microphones
when
you're
speaking
and
be
sure
to
say
your
name.
Blue
sheets
are
being
passed
around
the
room,
so
please
fill
in
a
blue
sheet
and
hand
them
to
other
people
as
they're
walking
in
we
do
need
note.
Takers
do
and
I
will
do
something.
They're
taking
and
our
secretary
Michael
will
do
some
note-taking,
yes,
okay.
C
A
So
we
have
two
sessions
today,
back-to-back
there's
a
break
in
between
them
same
room.
Fortunately,
we
were
able
to
rearrange
or
reschedule
the
room
assignment
to
enable
that
the
agenda
for
the
first
session
is
as
follows:
essentially,
we'll
go
over
schema
mount
and
then
the
ACL
drafts
and
then
kick
off
a
discussion
on
revisions
or
how
we
handle
yang
model
revisions
in
session.
Two
we'll
continue
going
over
some
post
last
call
specifically
the
revised
data
store
drafts
and
then
we'll
get
into
tree
diagrams
yang,
catalog,
module
tags
draft
and
then
some
other
not
yet.
A
Working
group
charter
drafts
yang
data,
extensions
and
modeling
finance,
state,
sheens
and
the
art
being
muddled,
okay,
so
update
since
last
meeting,
we
do
have
a
new
RFC's,
81
99
yang
module
classification.
So
congratulations
and
thank
you
for
that
back
from
is
G-
is
the
60
87
biz,
currently
pending
an
update,
Shepherd
right
up.
A
We
do
have
a
couple
new
working
group
documents:
72
23,
biz
and
7277
biz
and
post
last
called
ducts,
revised
datastore,
which
will
be
discussed
today
in
the
syslog
model,
which
we're
waiting
for
the
author
to
provide
an
update
on
continuing
with
revised
working
group
documents,
the
the
ones
in
green
we're
going
up
today.
The
ones
are
not
in
green
we're
not
reviewing.
Today.
B
A
All
right,
okay,
so
there's
one
from
the
I
Triple
E,
which
we
received
informally,
so
it
has
not
yet
been
formally
submitted.
So
we
don't
have
yet
the
LEAs
a
number
for
it,
but
essentially
they're
asking
for
an
update
on
when
we'll
be
able
to
complete
our
nmda
related
activities.
I
did
send
an
email
to
the
working
group
asking
for
us
to
just
proactively
try
to
conclude
on
providing
them
a
response
even
before
receiving
the
official
liaison.
A
D
E
Tim
Keri
Nokia
yeah,
so
it
was
just
it's
pretty,
probably
pretty
similar
to
the
I
Triple
E.
You
know
with
the
fact
that
NMDA
is
now
out
there.
Standards
organizations
are
trying
to
figure
out
what
to
do
right
because
they
base
their
base,
their
models
like
on
7223,
and
you
know
the
the
hardware
model
and
they
were
all
you
know,
state
based
and
they
split
it
and
they're
now
now
you're
bringing
them
back
together
again
and
there's
some
guidance
in
here
about
whether
we're
gonna
create
state
models.
E
B
E
The
BB
I
think
that,
if
that's
what
the
answer
is,
I
think
they're
willing
to
accept
that
right,
I
think
they'll
be
asking
they
would
want
to
know
in
the
interim.
You
know
how
long
would
we
be
doing
like
the
state
model
separation
that,
when
we
produce
a
model,
will
produce
a
state
model
type
of
thing
and
I
think
they'll
also
just
kind
of
want
to
get
some
assurance
that
you
know,
maybe
this
thing
is
is
good
enough
that
we
can
they
could
proceed
and
start
converging
their
models
right.
You
know,
there's.
B
B
The
current
of
recommendation
for
within
the
ietf
I
would
I
would
be
hard-pressed
to
see
that
it
would
be
different
outside
the
ietf,
but
one
of
the
nice
thing
about
the
recommendations
with
having
this
these
module.
The
models
in
sorry
modules
in
the
appendix
is
that
sort
of
is
good
risk
mitigation,
because
you
can
go
down
that
path,
while
the
other
parts
being
developed
without
any
concern
about
in
long
term,
incompatibilities
or
long
term
hiccups.
So
we
can
certainly
put
together
a
response
along
those.
F
B
As
always,
we
hope
that
someone
in
the
working
group
will
draft
the
response
we
circulated
in
the
working
group
look
for
ensure
we
have
a
consensus
position
and
then
we
can
send
the
formal
liaison
response,
but
even
though
it
comes
from
the
chairs,
it's
really
from
the
working
group,
and
we
want
to
make
sure
there's
consensus
on
that.
Okay,
all.
B
Yeah,
absolutely
it's
completely
reasonable,
as
is
on
the
screen.
The
PDF
conversion
lost
the
font
so
that
supposed
to
be
a
red
arrow
be
great.
If
we
could
have
someone
in
the
working
group
prepare
a
draft
response,
can
we
see
if
there's
any
volunteers,
who
will
it
someone
willing
to
prepare
a
draft
response
for
the
working
group
to
review
one
hand?
Oh,
we
got
all
right
so
Michael.
Thank
you
for
volunteering
to
look
for
a
proposed
response,
and
perhaps
we
can
use
the
same
one
for
both
the
I
Triple
E
and
BB
F.
G
Binoculars
so
Tim,
the
the
problem
you
mentioned
are
there
valid
for
any
SDO
is
right.
So
yesterday
or
recall
this
week,
we
had
like
a
breakfast
meeting
with
I
Tripoli
management
team,
and
we
went
the
same
thing.
The
point
is
that
we've
got
multiple
source
of
information.
We've
got
like
the
tool
that
Rob
wrote
on
converting
things.
We've
got
the
freaking
ask
question
as
well
that
the
Rob
mentioned.
What
we
showed
you
yesterday
in
Tripoli
is
that
from
the
catalog
I
could
do
select
all
yang
modules
were
a
Tripoli
and
cedar
States.
G
So
I
think
that
what
we
need
to
do
is
be
proactive
and
contact
all
the
different
SEOs
in
the
most
project
that
are
dependencies
on
or
yang
module
and
explain
what
the
guidelines
are,
the
tool
that
we
have
etc.
The
only
thing
that
will
be
missing
in
there
at
agreement
is
one
would
be
complete
in
the
working
group.
E
They're
kind
of
wondering
what
you
mean
in
a
little
no
I'm,
sorry,
they're
kind
of
wondering
when
that's
gonna
be
complete,
was
the
other
piece
of
it,
but
then
why
I
will
say
that
that
one
of
the
things
I
know
from
the
BBF
perspective
is
it's
important
to
them.
Is
that
you
know
it's
kind
of
like
they
want
to
make
sure
that
the
the
state
models
will
exist
for
a
period
of
time,
because
they've
got
stuff
that
they
just
published,
and
then
you
know
they
got
to
react
right.
You
know
it's.
E
E
A
All
right
from
a
milestones
perspective,
we
did
complete
60
87
biz,
but,
as
we
mentioned,
we
may
have
to
make
a
modification
to
four
tree
diagrams
and
model
classification
also
has
done
the
ACL
model
and
into
the
and
in
purple.
These
are
the
ones
that
are
coming.
You
know
on
track,
so
ACO
model
into
the
scheme
amount
and
revised
datasource
are
all
on
track
for
milestones.
The
syslog
model,
unfortunately,
is
a
lacking.
I
was
supposed
to
be
published
back
in
April
and
I.
A
H
It's
a
revoltin
to
the
interest,
extensions
one
I
think.
Actually
it's
just
I
need
to
add
examples
into
that
document
and
then
that
one
I
think
is
pretty
much
pretty
ready
to
go
to
work.
We've
last
call
so
that
one's
not
far
away
the
problem.
One
actually
is
that,
second,
on
the
bottom
on
the
layer,
the
sub
interface
yang,
one
I,
Triple,
E
I
changed
the
structure
to
simplify
it
and
I.
Triple
E
had
had
some
concerns
with
that.
H
So
I
need
to
follow
up
with
them
to
check
that
they're
happy
with
their
with
the
current
structure,
in
terms
of
how
the
VR
tags
are
represented.
So,
depending
on
how
quickly
that
goes,
is
is
what's
going
to
control,
they
say
is
fine,
then
then
it's
ready.
They
say.
No,
then
there
be
more
discussion.
A
I
So
when
the
first
one
is
about
prefix
and
namespace
declaration
in
the
schema
mounts
specification,
we
need
it
because
we
use
XPath
expressions
in
the
specification
of
the
so-called
parent
references.
If
you
remember
what
it
is,
and
so
we
can
use,
of
course,
namespaces
prefixes
in
those
XPath
expressions.
So
that's
why
we
have
this
simple
list
declaring
just
the
prefix
and
URI.
It
was
done
so
because
it
is
really
very
close
to
the
notion
of
how
XML
deals
with
namespaces.
I
That
means
a
prefix
and
namespace
URI,
but
I
think
Rob
proposed
that
maybe
we
should
add
module
name,
because
this
is
what
what
we
have
here.
Of
course,
we
have
a
module
and
the
names
main
name
space
is
uniquely
assigned
to
every
module.
So
that's,
of
course,
possible.
On
the
other
hand,
to
have
to
have
both
URI
and
module.
I
I
The
question
now
is
whether
our
proposal
we
discussed
this
with
Martin
and
our
proposal-
is
to
leave
it
as
it
is
because
it's
not
really
so
important
but
of
course,
as
a
second
option,
I
would
propose
maybe
to
use
my
new
name,
because
it's
of
course
easier
easier
to
read
for
human
readers,
so
other
any
opinions
on
this.
This
is
really.
I
J
B
I
I
An
in
fact
we,
as
you
know,
we
have
the
two
methods
of
specifying
the
mounted
schema
and
for
the
you
schema
method.
This
method
should
just
work,
because
you
can
imagine
it's
just
some
kind
of
an
augment
where
the
target
note
is
specified
externally
to
the
module.
So
assuming
that
augments
work
with
with
an
amine
da
architecture,
they
of
course
shoot.
I
Then
this
use
schema
method
should
work
as
well,
whereas
in
the
in
line
method
there
are
some
problems
and
some
gaps,
because
the
mounted
schema
in
this
case
is
specified
by
some
instance
data
and
namely
state
data.
So
this
data
is
only
present
in
the
operational
data
store
and
since
other
data
stores
like
intended
can
defer
their
contents.
I
It
could
also
be
that
this
state
data
with
the
Yang
library
is
not
present,
for
example,
consider
a
mount
point
instance
in
intended.
That
is
a
part
of
some
pre
provisioned
configuration
for
non
existing
hardware
at
the
moment,
but
it
can
be
in
intended,
but
since
the
resources
don't
exist
yet
this
entry
may
not
exist
in
operational,
and
so
we
have
no
place
to
look
for
the
yang
library
that
that's
that's
supposed
to
specify
the
schema.
I
I
Maybe
it's,
as
Martin
suggested
in
our
discussion,
it's
possible
that
the
use
cases
for
the
in
line
method
are
so
that
this
is
not
an
shoo,
but
in
any
case
this
is
how
it
works,
and
so,
if
the
inline
method
is
used,
it
has
to
be
ensured
that
this
simply
cannot
happen,
because
otherwise
you
might
have
problems.
There
are.
J
I
It
is,
as
I
said,
it's
possible
that
it
will
never
happen,
but
you
know
the
you
schema
case
is
really
general,
so
you
can
use
it
as
as
you
can
use
augments
anywhere
and
don't
care
about
anything.
In
this
case
it
is
just
this
small
catch
I'm,
not
saying
it's
a
big
problem,
but
we
have
to
I
care
about
this.
I
really
don't
see
to
be
it.
You
know
to
be
it
as
a
real-life
problem.
All
right
any
more
comments
to
this.
I
I
thought
this
is
not
an
issue,
whereas
again
for
the
inline
method,
it
very
early
use
cases
and
I
hope
that
will
confirm
where
we
can
have
a
nation,
an
ACN
beta
both
in
that
parent
three
and
in
in
the
mounted
three.
So
the
reasonable
rules
in
this
case
could
be
that
the
top
level
and
ICN
rules
apply
to
because
in
this
case,
in
most
cases
we
will
have
these
split
management.
I
So
because
in
this
case
the
client
only
sees
this
dismounted
data
tree,
and
so
it
makes
sense,
be
an
ACM
moves
to
talk
only
about
this
data.
So
in
this
case
an
ACM
rules,
of
course,
can
only
refer
to
the
mounted
beta
tree
and
never
to
the
parameter
T.
Even
though
we
might
have
the
option
to
use
this
parallel
fences
to
somehow
make
pants
data
accessible
to
it.
But
this
should
be.
This
should
be
banned
by
the
rules.
I
So
we
have
two
options
here:
either
specify
such
rules
in
this
document
or
address
these
special
rules
elsewhere,
for
example
in
the
an
ICM
document
or
in
the
next
revision
of
this
document.
Our
proposal
here
is
to
include
some
simple
rules
like
this
in
in
this
document.
Of
course,
this
may
need
some
discussion
in
the
mailing
list.
J
J
Regard
to
the
knock'em
rules
from
the
LME
perspective,
they
are
really
important
because
you
are
separating
the
you
know,
the
administrative
domains
nurse
and
you
are
essentially
defining
who
can
read
what
data
coming
up
with
the
rules
in
this
document
will
just
delay
the
schema
mount
and
until
we
really
learn
what
rules
would
we
really
need
as
a
minimum
I
would,
you
know
essentially
really
say
put
it
out
in
the
in
the
napkin
document
of
those
rules
will
be
specified
in.
We
can
add
them
for
use
cases.
J
I
A
B
I
B
So
matter
it's
good
to
establish
for
that,
the
in
the
base
case
when
you
use
you
schema,
that's
not
an
issue,
because
that
can
inform
what
we
can
do
here
with
Ellen
II,
because
Ellen
E
has
two
cases.
One
case
is
identical
to
the
NI
case
when
managed
equals
true,
which
means
that
that
case
is
exactly
the
same,
so
it's
covered.
In
the
other
case,
we're
managed
as
false.
There
is
no
access
from
the
top
level
at
all.
B
I
B
J
I
Case,
okay,
yes,
I
just
said
this
is
only
an
issue
for
the
case
where
we
have
some.
We
want
to
have
some
access
from
the
pantry
to
the
Mountie
tree.
If
no
such
use
case,
then
we
have
no
issue
at
all,
of
course,
and
the
last
issue
that
was
raised
by
Rob
I
believe
is
about
yang
library
and
scheme
amount,
integration
and
actually
it.
It
makes
a
lot
of
sense,
because
these
two
basically
define
how
the
over
betta
model
looks.
I
Like
young
library
gives
you
the
collection
of
modules
that
we
have
and
the
schema
mouth
without
schema
monk.
They
have
to
be
used
side
by
side
by
side
or
older
all
the
yang
beta
models
coming
from
the
yang
modules,
whereas
with
schema
mount,
we
can
have
some
some
hierarchical
arrangement
of
the
module
trees
and
actually
there
have
been
already
two
concrete
proposals:
the
first
one
by
myself
several
month
ago
and
then
recently
Rob
started
a
new
threat
which
is
I
believe
now
in
the
net
conf
mailing
list
that
discusses
alternative
proposal.
I
Of
course,
this
is
a
bit
difficult
because
it
changes
it
might
change
young
librarian
in
some
way,
and
it
would
certainly
take
some
time
so
I'm
not
proposing
to
do
it
now.
Maybe
we
can
just
see
how
things
work,
but
in
my
opinion,
we
have
to
strive
for
making
things
simple
because
for
for
a
newcomer
wants
to
start
with
the
egg.
It's
in
my
view,
really
important
that
the
concepts
are
relatively
simple
and
it
doesn't
help.
B
Rob
goes
from
the
jabber
room.
Martin
makes
the
comment
on
the
previous
slide
and
I
apologize
them
for
getting
too
late.
Is
that
this
really
must
be
done
in
this
document
and
I?
Think
I
think
we've
established
that
we
will
cover
knock'em
considerations
in
this
document
before
it
goes
forward
both
because
of
this
issue,
which
Martin
actually
somebody
raised,
Joe
Clark
raised
and
also
Martin
trees,
raising.
H
H
But
okay,
so
I'll
be
covering
this.
The
different
options
for
yang
library
that
we're
looking
at
tomorrow
in
the
Netcom
session
as
part
of
my
slide
set
there
I
don't
have
an
opinion
as
to
whether
we
should
wait
or
not.
But
it
is
the
case
that
effect.
The
yang
library
is
open
at
the
moment
to
updates
and
we
want
to
get
that
finished
quite
quickly
as
well,
so
the
timelines
may
align
somewhere.
It
slows
down
by
a
couple
of
months
out
of
those
and.
D
I
Made
a
high-level
proposal
I
think
so.
Disclaimer
I
have
to
say
that
this
is
not
necessarily
Martin's
opinion,
but
I
think
it
would
make
a
lot
of
sense
really
to
structure
the
specific
vacations
into
the
documents
and
document
number
one
would
cover
some
kind
of
really
small
metamodeling
language
meta,
meaning
that
the
granularity
here
is
at
the
level
of
yang
modules.
B
I
B
I
B
J
So
please
ban
bogdanovich
document,
as
is,
in
my
opinion,
a
is
good
enough
to
move
forward
and
for
us
then,
to
try
to
cover
you
know
the
multiple
corner
cases
that
are
not
you
know,
being
that
I,
don't
see
them
being
like
a
real
life
issue
and
then
to
try
to
reorganize
the
document
to
postpone
the
in
the
publishing
or
the
RFC
I.
Think
it's
a
it's.
J
B
F
F
Okay,
so
basically
in
graphs,
12,
13
and
14,
we've
incorporated
a
lot
of
new
match
and
action
criteria,
we've
incorporated
statistics
and
also
the
attachment
of
the
ACL
to
the
interface,
a
list
of
ACL
Stu
interfaces,
and
this
data
has
been
gathered
by
looking
at
several
vendors,
namely
the
two
big
vendors
that
we
looked
at
were
juniper
and
Cisco
and
Arista.
So
we
took
a
lot
of
their
matches
and
actions
and
put
them
into
the
ACL
yang
model.
F
Okay,
so
one
big
enhancement
is
the
support
for
statistics
on
a
per
a
spur
interface
basis.
This
is
needed
because
stats
can
be
gathered
on
a
as
the
packet
enters
the
specific
port
on
the
line
card.
We
have
stats
that
are
collected,
so
this
change
now
gives
us
matched
packets
and
match
octet
on
a
per
ace
per
interface
basis
in
both
directions.
The
previous
draft
did
not
have
the
support.
J
Me,
yes,
the
previous
one,
so
the
stats
collection
and
the
Aces
are
highly
dependent
on
the
basic
implementation
and
on
some
of
them
you
can
do
that
only
on
the
Egret
ingress
side
and
on
some
of
them
not
on
many
of
them.
You
will
have
also
on
the
egress.
So
in
this
case
you
are
then
sent
your
trying
to
put
onto
something
that
will
not
always
work
on
all
the
Asics.
F
D
E
J
F
F
F
J
H
F
There,
after
we
publish
draft
number
fourteen,
there
was
a
lot
of
feedback
given
by
Christiaan,
which
were
all
mostly
very
valid
comments
which
are
in
the
process
of
being
incorporated
in
the
next
version
of
the
draft.
So
those
include
so
some
of
his
comments
deal
with
the
usage
of
containers
versus
groupings,
the
way
that
we
do
for
the
input
interface.
Maybe
we
want
to
divide
that
into
ingress
and
egress
input
interface
and
he
had
a
few
more
comments
on
life
statistics
and
the
groupings
of
the
different
types
of
ACLs.
K
F
J
One
last
comment
on
on
the
ACL
white
as
a
this
ACL
model
is
getting
fairly
complicated
and
you
know
all
the
iterations
that
are
trying
to
be
put
into
a
basic
model.
Well,
you
know
turn
into
such
a
mess
with
deviations
from
the
vendors
that
it
will
be
like.
Oh,
you
know
what
just
forget
it
and
you
use
whatever
else.
There
is
from
the
vendor
side.
So
if
you
really
want
to
cover
those,
why
not
create
a
basic
base
model
and
then
create
then
created
the
extended
models
that
can
cover?
J
You
know
those
variations
and
then
the
vendors
can
say
which
of
those
variations
they
will
have,
but
it
will
be
the
same
base
model
for
everything.
If
you
will
you,
you
cannot
cover
all
the
vary,
all
the
variations
in
Asics
that
are
out
there
even
by
the
same
vendor.
They
there
are
significant
differences.
It
will
make
the
implementation
so
complex
and
it
will.
It
will
just
be
a
nightmare.
L
Quick
follow-up
point
to
that
as
well:
just
jumping
in
Rick
Tony,
the
other
end
of
the
spectrum
from
doing
ACLs
and
Asics
is,
if
you're
doing
ACLs
in
a
full
software
stack.
So
I
want
to
look
at
any
16
bits
anywhere
in
the
packet
for
ACLs,
so
how
many
young
models
do
I
have
how
many
extra
and
all
the
officers
I
got?
I
have
four
offset
23
offset
58
I
think
you
need
to
break
this
down
into
a
core
model
that
can
be
extended
over
time,
or
this
is
never
going
to
be
finished.
This.
B
A
D
J
That
is
fine,
because,
right
now,
today's
vendors
are
calling
a
filter
or
ACL
and
they
are
being
differently
constructed
and
you
always
have
to
know
to
do
all
that.
Parsing
if
you
start
with
the
base
model-
and
you
say
this-
isn't
layer,
2
and
an
IP-
and
you
know
just
having
the
very
basic
one
that
you
can
then
start
from
there.
But
if
you
try
to
cover
all
the
variations,
I
think
you're
getting
into
fairly
complicated,
but
you
can
should
take
this
off
the
list
in
order
to
be
on
time.
Ok,.
B
Alright,
we've
had
some
discussions
on
yang
revisions
and
we've
run
into
a
couple
of
real-world
use
cases
that
have
ended
up
with
some
good
discussions
in
the
content
of
a
bist
that
we've
planned
8220
to
this
there's
some
in
discussions
in
l3
related
to
an
STL
3sm
documents,
and
we've
also
had
examples
of
some
solutions
coming
out
in
terms
of
drafts.
What
we
wanted
to
do
is
to
sort
of
kick
off
a
discussion
here
here.
What
was
the
real
world
use?
B
What
we
are
going
to
do
is
make
sure
we
have
some
good
understanding.
So
that
we
can
get
some
good
discussions
on
current
proposed
solutions
as
well
as
get
people
thinking
about
what
alternative
solutions
there
should
be.
So
the
first
thing
is:
is
that,
with
the
current
rules
in
in
the
in
yang
specification,
there's
some
very
limited
types
of
changes
that
can
be
made
within
the
same
module
and
the
in
order
to
affect
other
types
of
changes.
B
I
want
to
call
it
problem,
but
the
current
situation
starts
is
it
starts
with
number
one
what
our
rules
are
and
the
rules
state
very
clearly
that
they
any
changes
in
a
module,
any
updates
to
a
module
must
be
backward
compatible,
and
that
goes
to
both
the
definition
of
leaves
and
structure,
as
well
as
the
presence
of
those
of
leaves
and
structures.
You
can't
remove
things
you
can
deprecated,
but
you
can't
remove
if
we
want
to
make
any
other
changes
the
what
the
document
says,
what
the
rules
say
is
we
need
a
new
module
name.
B
The
other
thing
is
to
keep
in
mind
is:
is
our
process
inside
the
IETF?
Remember
our
resort'?
What
we
produce
here
are
documents
and
those
capturing
models.
Our
documents
allow
us
to
have
some
metadata.
That
says
one
document
updates
another
or,
and
that
or
one
document
replaces
another.
We
know
missus.
We
do
them
all
the
time
right.
The
problem
is,
is
that
doesn't
show
up
in
the
tooling
sorry
show
up
in
the
model
to
support
tooling.
B
We
have
the
real
world
case
of
it,
the
l3
s/m,
where
we
have
basically
a
broken
module
that
came
out
whether
that
was
the
right
thing
of
the
wrong
thing
doesn't
matter
it
happened,
but
we
according
to
a
strict
interpretation
of
our
current
rules.
We
can't
use
the
same
name
for
the
fix
in
the
case
of
8022.
We
wanted
to
remove
some
nodes,
but
that's
not
allowed.
So
that
means
we
have
to
change
the
name,
but
then
we
run
into
the
linkage
problem,
which
is
the
third
bullet.
B
If
we
wanted
to
support
some
more
complex
changes,
like
you
do
in
in
source
code,
for
example,
you
have
a
branch
that
becomes
a
maintenance
branch
and
you
want
to
make
a
modification
in
that
maintenance
branch.
We
don't
have
semantics
to
do
that,
not
saying
that
is
what
we
want
to
do,
but
people
have
talked
about
using
code
source
code
models
and
apply
them
to
yang
modules,
and
if
we
do
that
this
is
a
very
natural
thing
that
happens
with
source
code
and
we
should
think
about
it
and
I.
B
Think
we've
cover
really
the
major
points.
So
the
goal
is,
we
would
like
to
find
a
solution
that
allows
us
to
deal
with
all
types
of
module
revisions.
There's
been
some
change.
Some
some
discussion
in
email
there's
been
a
proposed
document.
We're
gonna
hear
a
little
bit
that
in
a
moment
other
solutions,
as
I
mentioned
before
or
possible.
We
want
to
kick
this
as
a
kickoff
of
a
discussion.
It's
not
a
time
we're
not
at
the
point
saying
we're,
saying
we're
ready
to
select
an
answer.
B
We're
saying
we
need
to
focus
it's
time
for
the
working
group
to
focus
on
this
come
up
with
some
good
solutions.
Discuss
those
here
now
to
start
and
then
sorry
discuss
the
problem
start
in
one
solution.
This
is
a
start
and
then
moving
forward,
particularly
hopefully
at
the
next
meeting.
We'll
have
some
documents
that
have
solutions,
and
we
really
want
to
try
to
push
forward
on
selecting
the
right
solution
quickly.
So
with
that
we're
ready
for
AC
and
then
we'll
hit
come
back
to
discussion.
C
C
We
wanted
to
minimize
the
disruption
and
the
work
and
start
with
clean
slate,
so
we
started
out
with
new
naming
we
had
IETF
routing
to
IETF
ivb
for
unicast
routing
and
so
on,
just
in
the
same
vein
as
what
was
done
with
me
of
one
in
May
and
back
in
the
SNMP
days.
Well,
this
proved
to
be
you
know.
Our
goal
was
a
clean
split.
This
proved
to
be,
you
know,
based
on
input
received
on
the
list.
This
was
much
more
disruptive
and
it
was
inconsistent.
C
What
was
done
for
RFC
72
23
bits
and
RSC
72,
whatever
the
whatever
the
one
is
for
IP
IETF,
IP
interface,
routing
so
so,
and
part
of
the
reasons,
but
in
wasman
has
in
detail
and
he's
going
to
go
through
it.
The
whole
story
of
the
IETF
routing
and
why
that
broke
tooling
and
everything
else.
That's
that's
in
I,
don't
know
how
many
of
you
got
a
chance
to
read
the
new
yang
module
update,
but
that's
going
to
be
in
this
whole
thread
of
discussion
on
revisions.
He's
going
to
talk
about
that
later.
C
One
thing
we
did
differently
because
we
wanted
to
limit
the
implementation
cost
of
this
and
there
weren't
a
lot
of
implementations
and
deployments
of
IETF
routing.
We
went
straight
with
the
that
now
redundant
with
revised
datastore
state
trees.
We
went
straight
to
obsolete,
we
didn't
take
the
deprecated.
What
this
allows
is
it
for
new
implementers
of
IETF
routing
and
it's
children.
It
allows
a
much
simpler
implementation
than
having
to
implement
all
these
deprecated
notes
and,
like
you
can
look
at
the
draft
for
this.
C
We're
correct
we're
in
the
process
of
connecting
and
collecting
comments.
We've
gotten
some
good
input,
input
from
Valdemar
and
also
rob,
has
a
pending
comment.
I
got
to
talk
to
him
about
one
thing:
it's
we're
going
to
have
to
decide
is
whether
or
not
we
need
on
the
imports,
whether
we
not
need
to
specify
a
revision.
Now
that
we
have
multiple
versions
of
these
modules
and
that
doesn't
that's
all
part
of
this
discussion.
We
also
there's
possibly
also
now
that
we've
moved
along
with
RFC
sixty
eighty
seven
biz.
C
I
G
A
G
So
I'll
make
it
ten
okay
right,
but
I
can
reduce
it.
I
want
I
want
to
have
discussions
so,
okay
anyway,
let
me
start
talking
thanks
you
for
the
intro.
It
was
well
stated,
Thanks
ac,
for
the
explanation.
What
I
want
to
do
here
is
show
you
what's
happening
from
a
tooling
point
of
view.
I
won't
be
repeating.
What
was
you
said
Lou
and
there
were
things.
I
will
skip
a
lot
of
points
now,
from
a
tooling
point
of
view,.
B
F
G
Very
good,
so,
okay,
if
you
get
a
next
slide,
you
know
that
I
try
to
work
from
toolings
right.
So,
if
you
look
at
this,
you
would
see
that
this
is
the
idea
of
rounding
in
the
middle
and
all
the
dependent
yang
modules
right.
So
what
do
you?
What
does
it
mean?
It
means
that
if
you
change
this,
one
there's
a
lot
of
impact.
Now,
if
you,
if
you
go
to
the
next
slide
as
soon
as
AC
publisher
draft,
is
the
ITF
routing.
F
G
It
showed
up
in
the
in
the
tool
right
now
what
it
mean.
It
means
that
someone
is
committing
and
I
take
the
role
for
that
as
to
contact
every
single
document,
author
of
the
depending
draft
on
ITF
routing
to
say:
hey:
there
is
a
new
version
with
a
new
name
and
you
should
be
thinking
about
importing
the
ITF
routing
right.
G
So,
if
you
look
back
at
this
slide,
it
means
a
lot
of
people,
part
of
the
tooling
we've
been
doing
in
the
yang
cataract.
We
had
to
create
a
script
to
do
that.
It's
kind
of
automatic
in
the
ITF
right.
We
extract
from
the
dependent
yang
module
draft
name.
We
extract
the
author,
now
ITF
routing,
it's
a
ITF
for
your
draft.
Sorry
for
the
other
yang
modules.
This
is
a
cross
as
your
issues.
G
If
we
look
at
something
like
the
ITF
interface
yang
module,
we
have
like
dependencies
in
I,
Triple,
E,
BB,
F,
open
config,
any
F,
Vander,
etc.
So
does
it
mean
that
now
I
would
have
to
contact
by
a
liaison
or
process
all
different
SDOs
or
even
the
guys,
I,
don't
know
about
to
say,
well
change
your
import
because
there's
a
new
module
name
and-
and
you
see
things
that
are
even
weird,
like
some
modules
import,
both
of
them
so
from
a
tuning
point
of
view
from
a
automation
point
of
view,
it's
a
mess.
G
Alright,
it's
not
a
new
problem
right.
The
open,
config
people
came
like
some
time
ago
and
express
the
same
thing
now
we
could
say:
well,
you
know
if
you
go
from
ITF
routing
to
ITF
routing.
Well,
there
is
a
way
to
do
that.
It's
an
RFC
header.
There
is
like
an
obsolete
or
update
there,
but
you
know
in
this
world
of
automation,
going
via
a
level
of
indirection,
which
is
you
go
from
a
yang
module
to
the
RFC
header
tag
to
see
if
it's
updates
obsolete
another
one,
it's
a
non-starter
alright.
G
G
Now
we
had
like
two
examples
and
that's
not
a
new
problem,
but
it's
the
first
time
we
see
it
with
two
occurrences
in
the
ITF,
with
the
l3
VPN
module
and
we'll
ITF
routing
module.
The
address
M
was
something
was
somehow
different
because
it
was
broken
so
not
in
implementable,
but
we
have
to
rethink
the
way.
We
update
our
yang
modules.
Now
this
could
be
fine,
but
what
is
the
bigger
problem
or
the
angle,
the
operators
they
want
to
automate
their
services.
So
we
have
an
issue
of
service
composition
right.
G
If
we
take
an
Orchestrator,
we've
got
a
service,
it
maps
to
multiple
yang
modules,
potentially
in
different
network
elements
and
wikidot.
Nothing.
So
whenever
an
operator
want
to
do
a
service
creation,
it
has
to
know
which
yang
modules
work
together
right
this,
what
some
people
call
a
release,
bundle
or
a
package.
Now,
typically
an
operator
would
look
at
some
metadata.
It
come
from
the
same
as
the
O
or
you
know.
There
is
like,
in
the
yang
catalog
a
metadata
called
three
type
if
it's
nmda
compatible
as
a
value.
Well,
they
should
be
working
together.
G
G
Like
let
me
move
so,
the
bigger
issue
is
a
service
maintenance
or
the
update,
if
you,
for
example,
update
a
device
OS
right
again,
if
you
have
dead
device
OS
with
new,
is
this
one?
Okay,
if
you
update
for
the
third
time
a
device
source,
then
you
might
have
new
yang
modules
right.
So
if,
for
example,
you
change
from
ITF
routing
to
ITF
rotting,
it
mean
that
you
have
to
change
all
the
yang
paths
for
your
mapping
every
single
time.
You
have
to
change
your
service
to
update
the
yang
pass.
G
This
is
the
the
big
issue
now
whenever
you
get
your
device,
maybe
because
you
want
to
upgrade
your
service,
so
whenever
you
want
to
just
upgrade
for
something
different,
you,
you
might
have
some
non
backward-compatible
yang
modules.
That's
a
fact
of
life
right
there
are
different,
is
a
shoe
that
works
with
non
backward-compatible
yang
modules.
There
are
Native
models
in
the
wild,
so
that's
the
fact
that
we
have
some
backwards
incompatible
yang
modules.
So
whenever
you
update
that
device
what's
happening,
is
that
you
break
your
services.
At
least
we
want
to
be
a
that.
G
G
That's
the
end
goal
proposed
solution
is,
first
of
all,
we
believe
that
we
have
to
relax
the
rules
to
update
yang
modules
right
going
from
the
ad
VPN
to
Anthropy
and
just
to
fix,
okay,
a
big
issue,
but
one
issue:
it's
an
issue
right
for
me
turning
point
of
view,
so
we
want
to
keep
the
same
yang
module
name
now
we
want
to
mention
if
a
yang
module
that
you
produce
is
backward
compatible
with
the
previous
version.
We
propose
to
have
something
based
on
semver,
again
proposed
by
open
config
some
time
ago.
G
Now.
What
we
have
done
in
the
catalog
is
an
experiment
as
well
right,
so
there
is
code
for
that
and
then
we've
got
like
two
types
of
semantics.
There
is
one
you
know
the
open,
config
people
they
have
like
semantic
semantic,
versioning
extension
there.
We
can
get
it
directly
and
we
have
got
upload
the
metadata,
but
you
know
we've
got
also
the
derive
semantics,
so
we
use
ping
check
update
from
and
we're
about
to
check
if
there
is
like
some
semantics.
G
No
sorry
if
there
are
some
syntactic
changes,
which
is
something
different,
so
it
goes
by
comparing
the
the
young
trees
and
telling
us
if
you
think
that
there
is
something
different
now
it
is
a
perfect
solution.
Well,
not
really.
We
were
just
checking
with
Jo
right
now.
It
would
not
check,
for
example,
obsolete
right.
G
It
doesn't
support
yang
one,
not
one
for
now,
but
we
have
plans
to
update
the
two
sets.
Now.
It's
not
semantic
versioning
right,
because
it
means
that
we
have
the
same
yang
modules,
but
the
semantics
behind
it
is
different.
So
it's
not
the
ideal
solution.
The
ideal
solution
is
that
someone,
whenever
it
creates
the
gang
module,
will
tell
us
yes,
its
semantics
backward
compatible
or
not
with
major
minor
and
patch.
G
G
We
experiment
this
with
a
catalog
and,
most
importantly,
it
fits
Wells
into
the
service
composition,
because
whenever
you
want
to
update
your
service
or
update
your
your
servers,
you
check
what
would
add
what
would
happen
if
I
would
move
from
OS
version
X
to
X,
plus
one
you
can
pair
a
semantic
versioning,
and
we
do
this
in
the
catalog.
You
compare
if
the
yang
paths
that
you
have
in
your
mapping
are
affected.
G
If
they
are
affected,
you
get
an
issue
with
your
service,
so
as
Lou
mention
it
should
be
the
beginning
of
discussion
on
which
one
we
want
to
solve
right.
I,
like
the
way
that
you
phrased
it
with
multiple
bullets,
and
we
want
to
see
which
solution
fits
with
those
bullets.
And
yes,
they
are
like
open
issues
like,
for
example,
if
we
go
with
semantic
versioning,
what
do
we
do
with
import
right
right
now?
G
We
don't
use
like
import
by
revision
or
really,
maybe
you
want
to
say,
I'm
able
to
import
everything
which
is
like
above
major,
for
example.
So
there
are
corner
cases,
and
maybe
we
want
to
have
like
new
naming
conventions
like
having
the
sender
directly
into
the
yang
name,
and
maybe
you
want
to
tackle
a
different
problem
which
is
modular
bundle
or
package,
so
how
the
yang
modules
will
work
together.
G
A
Okay,
I
think
I'll
kick
off
with
the
first
question,
or
comment
in
yang
I
think
currently
we're
only
able
to
implement
a
single
version
of
a
module
at
a
time,
and
this
works
because
of
the
backward
compatibility
support
that
we
have.
But
now
who
moved
to
actually
allowing
for
breakage
and
backwards
compatibility.
Would
we
then
need
to,
for
instance,
support
multiple
versions
of
module
to
enable
both
backwards,
compatible
view
of
the
legacy
version
and
also
the
new
version
in
a
server.
G
B
G
Yes
and
no,
we
could
export
multiple
who
wants
library,
but
only
one
could
be
implemented.
Now
you
want
to
give
the
choice
to
say:
ok,
I'm
exporting
new
one
and
the
old
one
you
could
you
could
advertise
them
and
you
expect
that
one
controller
or
one
Orchestrator
will
say
which
one
to
use,
but
if
you've
got
multiple
ones
exactly.
G
B
Think
about
it,
you
have
a
customer
that
has
a
deployment
there.
They
have
some
news
that
they
have
some
old
software
and
they
have
some
new
software.
They
want
to
be
able
to
keep
the
old
software
running
and
they
upgrade
your
router,
but
they
also
want
to
be
able
to
use
the
new
software.
Yes,
maybe
on
a
particular
session,
you
would
only
use
one
version,
and
you
know
that
might
be
the
compromise,
but
you
would
want
the
server
to
be
able
to
support
both
the
old
and
the
new
understood.
B
I
First
of
all,
I
would
like
to
say
that
I
support
this
effort.
It's
it's
been
missing
for
long
times
and
something
like
this,
you
are
proposing
and
second
I
believe
it
would
be
useful
to
move
the
update
rules
away
from
the
specification
of
young,
the
language
and
maybe
define
them
in
the
in
December
draft,
just
to
say
what
what
changes,
what
updates
are
possible
within
one
minor
version
and
so
on,
because
I
believe
in
the
definition
of
that
beta
our
modeling
language.
I
G
I
That
we
have
to
something
with
the
import
statement,
so
this
has
to
be
done
in
in
the
yang
specification,
certainly
but
I'm
talking
of
all
the
texts,
I
think
it's
section
11
or
something
in
7950
that
talks
about
an
update
of
whom
or
you
cannot
do
this
and
can
do
this.
So
I
think
this
is
some
kind
of
policy
that
different
groups
can
use
different
policies.
Perhaps-
and
this
really
doesn't
belong
to
the
specification
of
the
language
itself-.
M
By
Daniel,
Erickson
I
have
wrote
a
quite
long
mail
about
this
yesterday.
Just
some
of
the
main
points
from
this
first
of
all,
I
strongly
disagree
that
we
can't
make
incompatible
changes
today.
When
you
obsolete
or
deprecated
any
data
node,
then
you
are
not
mandated
to
implement
it
anymore.
So
you
are
you
even
today
we
allow
to
remove
complete
sub
trees
and
keep
the
model
module
name.
We.
B
Mischaracterizing
the
rules
right
what
the
first
stage
is
and
I
get
these
backwards.
I
had
you
deprecated
first
and
there's
an
expectation
that
deprecated
is
used
to
support
a
transition
period,
and
then
you
end
up
with
obsolete
where
it's
removed,
but
well
during
the
deprecated
you're,
not
supposed
to
use
it
but
you're
supposed
to
implement
it.
Alright,
don't
remember
the
exact
phrasing,
but
it's
a
transition
period.
So
you
know
we
have
the
notion
of
a
phase-out.
B
M
M
B
M
M
M
G
Would
agree
with
your
last
point
somehow
we
open
this
with
a
draft
tooling.
We
see
this
issue
by
the
way
we
knew
it
for
two
years
right
and
now
we
start
to
just-
and
we
just
got
this
also
there
with
the
yang
doctors,
that
we
wanted
to
open
discussion,
trying
to
see
which
four
we
solve
so
I
I
agree
with
you
at
the
notion
of
bundle.
Maybe
it's
not
part
of
this.
G
M
We
with
our
own
solution,
which
is
very
similar
to
this
one.
We
had
many
cases
where
the
model
exactly
didn't
exactly
change,
but
the
behavior
expected
by
the
model
changes
so
manual.
Assignment
of
these
semantic
version,
numbers
is,
is
needed
sometimes,
and
also
I,
propose
that
for
every
yang
revision
statement,
a
mandatory
sub
statement,
at
least
for
new
models
to
have
these
semantic
versions
and.
M
More
point
is
that
prefixes
are
also
very
important.
We
like
to
think
that
we
have
the
namespace
the
module
name.
Who
cares
about
the
prefixes?
It
can
be
exchanged
any
time
no
prefixes
are
stored,
both,
for
instance,
I
identifiers,
both
and
identity
references
and
also
in
human
conversation.
We
very
often
refer
to
more
use
with
their
prefixes
yang
glib
is
common
reference
in
emails
and
other
places.
So
if
we
update
something
to
yang
library,
will
we
keep
the
prefix
or
not?
M
B
Two
comments
from
jabber
I'm
gonna
actually
go
out
of
order
because
Martin
is
responding.
+
us
and
the
comment
he
has
is
that
a
server
is
always
allowed
to
remove
support
for
a
module
on
a
new
software
version.
So
we
have
even
a
bigger
compatibility
issue
with
that
are
potential
cab
backwards.
Compatibility
problem.
Thank
you
more
coffee,
please
yeah,
but
of
course
an
a
vendor
would
be
sort
of
foolish
to
remove
something
that's
used
by
their
customers.
B
That
was
comment
number
one
now
from
Jeff
Haas,
oh
by
the
way,
the
the
commented
that
one
at
the
end
was
mine,
not
Martin's
from
Jeff
Haas.
The
issue
is
somewhat
analogous
to
the
issue
of
multiple
modules
managing
similar
information,
for
example
the
BGP
module,
which
we
have
open
config
and
one
still
working
through
IETF
I'm,
actually
trying
to
figure
out
how
that
relates,
but
I
have
to.
It
was
a
comment
on
your
presentation
earlier.
Maybe.
H
Rob
Wilson
Cisco,
so
I
strongly
support
this.
Unlike
this
idea
of
doing
semantic,
versioning
I
think
that
change
you
how
to
change
a
modules
name
and
the
prefix
whenever
you
ought
to
do
a
major
version.
Change
is
a
real
hassle
for
everyone
involved,
saying,
don't
think.
That's
the
right
solution.
I
also
quite
like
to
lose
point
that
he
made
on
earlier
on
about
the
fact
that
you
use
github,
develop
these
modules
and
want
to
put
patch
changes
and
things
like
that
again.
H
The
semantic
version
version
here
marries
to
that
quite
well
in
terms
of
how
you
naturally
manage
this
developers
are
also
very
used
to
using
this
sort
of
version
scheme.
So
it's
not
like
it's
a
brand
new
scheme
that
people
don't
understand.
It's
a
scheme,
that's
well
use
in
the
industry,
seems
to
work.
It
seems
to
be
well
understood.
I
also
agree
that
the
the
suggestion
that
import
by
revision
effect
needs
to
be
fixed
I'm,
not
even
sure
that
the
one
today
is
actually
that
useful.
H
H
One
last
comment
I'd
like
to
make
is
that
perhaps
the
issue
that
came
up
about
having
to
support
two
versions
of
the
same
module
in
terms
of
upgrade
ability?
Could
that
perhaps
solved
by
you
configuring
on
the
device
which
which
virgin
you
want
the
device
to
provide
I'm
meds
allowed
to
different
clients
both
to
access
the
different
versions,
but
it
does
allow
the
some
control
of
is
to
which
version
it's
going
to
export
the.
H
J
B
M
M
G
So
let
me
understand
this
because
I
couldn't
have
multiple
ways,
so
you
would
like
to
have
an
extension
not
on
in
December
but
like
the
module
name
semver.
That
could
be
one
way
which
could
solve
a
specific
issue
that
you
don't
want
to
bring.
But
maybe
we
want
like.
Let's
pretend
there
is
an
ITF
VLAN
yang
module
right,
and
we
do
this
as
a
temp
solution,
while
yeah
Triple
E
does
that
the
real
one?
So
whenever
you
actually
will
do
the
real
one
was
a
different.
G
M
B
I
Regarding
to
the
prefix
issue
that
Marsh
mentioned
I
just
checked
the
specification
for
the
IANA
yang
module
registry,
and
it
only
says
that
module
and
sub
module
names
and
namespace
here
I
have
to
be
unique,
so
I
think
not.
Nothing
prevents
us
from
reusing
the
same
prefix
or
modules
with
different
name.
I,
don't
know
if
it's
but
it
in
some
cases
it
might
really
be
useful
and
really
I
and
I
should
accept
such
a
registration
without
any
problems
and.
G
And
I
think
this
is
part
of
the
the
thing
that
we
have
to
decide
right.
We've
been
listing
multiple
problems
already
like
the
update,
like
the
semantic
versioning
like
the
urin
like
the
package,
it
would
be
good
to
agree
on
what
we
want
to
solve
right,
and
maybe
we
do
this
in
sequence.
But
in
the
end,
what
we're
trying
to
solve
is
like
the
the
deployment
on
those
yang
modules
seriously
good
thing.
H
Ro
Bolton
so
I'm
one
columnist
earlier.
Actually
it
was
about
packages
and
I.
Think
we
need
to
be
very
careful
with
packages
similar
to
Jeff.
Has
his
comment
that
we
don't
want
to
type
the
couple
lot
of
particular
versions
together
such
that
you
can't,
if
y'all
have
to
upgrade
one
module
you
end
up
and
upgrade
the
whole
lot.
I
mean
you
look
at
the
Linux
packaging
system
that
it
seems
to
work
very
well
where
you
mostly
can
pull
in
particular
packages
and
upgrade
some
of
them
as
you
want.
H
G
I
would
agree
with
that,
because
most
of
the
packages
I
mean
mine
are
service,
oriented
and
your
service
is
of
my
service
is
not
a
different
service,
so
in
the
end,
whatever
we're
going
to
send
yet
yet
that
they
work
together.
This
could
be
resolved
with
like
metadata.
Those
are
all
the
set
of
nmda
compatible
yang
modules.
G
Those
are
all
the
ones
that
are
precious
RFC's
and
and
then,
depending
on
what
you
care
about,
you
will
pick
the
right
values
in
the
set
of
metadata
that
we've
got
as
opposed
to
us
telling
for
whatever
service
you
could
think
of.
This
set
will
work
because
after
some
time
the
services
will
evolve
and
it
will
not
work
any
longer.
I
think.
H
M
Well,
enjoy
Ericsson
I.
Think
for
me
at
least
the
two
main
root
problems
are
one
is
that
I
need
a
small
bit
of
information
like
the
module
name,
combined
with
the
semantic
version
that
tells
me
if
this
version
of
the
module
is
compatible
or
not
with
the
previous
one.
We
don't
have
this
today.
This
would
provide
us.
The
other
one
is
I
want
to
be
able
to
find
out
that
it's
compatible
just
without
comparing
the
full
modules
and.
M
And
also
the
other
big
problem
is
that
we
want
to
allow
some
level
of
incompatible
changes.
The
routing
and
some
others
stated.
Yes,
they
should
be
indicated
clearly
by
December
or
some
other
way,
but
sometimes
keeping
the
name
and
the
prefix
and
namespace
and
still
doing
incompatible
changes
is
needed,
so
find
out
easily
what
is
compatible
and
sometimes
allow
limited
incompatible
changes.
These
are
two
problems
for
me.
G
G
M
B
B
So
I'd
like
to
we'd
like
to
try
to
wrap
this
up.
We
think
the
most
important
thing
is
is
that
we
agree
on
the
problem
rather
than
the
specifics
of
one
solution,
because
we,
as
a
group
really
haven't,
spent
enough
time
thinking
about
solutions
to
think
this
is
the
one
solution
we're
going
to
follow
or
if,
after
when
we
go
back
to
go
back
home
and
have
some
time
to
think
about
it,
we
come
up
with
something
different.
B
So
it
would
be
good
to
make
sure
we
agree
on
the
basic
problem.
Definition
and,
like
everyone,
take
a
look
at
the
screen
for
a
moment.
I'm
not
going
to
say
we
spend
a
huge
amount
of
time
coming
up
with
this.
So
if
we
think
that
there's
a
better
formulation
we'd
be
happy
to
change
it,
but
is
this
close
enough
to
capture
the
problem
space
we've
talked
about?
Yes,
we
know
that
on
certain
solutions
that
it
we
may
have
implications
that
are
not
captured
here.
But
that's
that's
a
solution
problem,
not
that's
not
a
problem.
B
I'm
microphone,
please.
B
A
comment,
no
comment
is
a
call
for
comment
so
based
on
not
hearing
a
lot
of
discussion
on
this.
While
we
had
a
lot
of
good
discussion
on
a
specific
proposal,
I'll
take
it
that
we're
close
enough
here
to
have
some
agreement
that
this
is
a
problem
that
we,
as
a
working
group,
need
to
solve.
There's
no
polling
on
this.
Do
we
think
it's
a
problem,
we're
saying
this
is
a
problem
and
we
must
solve
it
at
this
stage,
we'd
like
to
ask
the
working
group
to
think
about
solutions
proposed
alternative
solutions.
B
If
you
have
them
discuss
the
solution
that
has
already
been
documented,
and
let's
do
this
on
list
I
would
expect.
Although
we
haven't
figured
out
Tommy
I
would
expect
that,
given
the
importance
of
this
discussion,
we're
likely
to
have
an
interim
on
it
before
between
now
and
101,
although
we'll
have
to,
of
course,
be
sensitive
to
the
holiday
period.
That's
coming
up
final
comments.
We
have
three
people
come
up.
N
Lou
I
appreciate
you
reminding
me
sue
hair's
in
this
hat
properly
are
to
us,
no,
not
artis.
Idr
I'll
get
those
letters
out.
I
sat
there
and
thought,
and
so
this
is
a
clarification
question,
but
well
we
often
have
augmentations
to
models.
Are
you
tracking
the
augmentations
and
how
they
go
back
to
another
module?
Is
that
the
catalog.
B
N
B
We
absolutely
have
to
make
sure
that
whatever
we
come
up
with
covers
augmentation
I'm,
sorry,
I,
missed
Martin
and
Q,
so
I'm
going
to
repeat
I'm
gonna
know
he's
here:
jabber
uh-huh,
so
he's
responding,
I,
don't
know
it's
Mike's
he's
responding
to.
What's
on
the
screen.
He
says
by
design
and
I
agree
that
to
is
correctly
stated,
so
we
have
Martin
Dan
and
then
we
should
close
out
and
maybe
still
have
time
to
go,
grab
a
coffee
or
so
I.
Just.
I
H
J
B
Others
I've
said
this
before
at
other
context.
Whatever
we
do
in
yang
has
to
support
any
protocol
underneath
it
at
this
stage,
so
whether
it
should
it
should
support
Netcom
press
conf.
Whatever
comes
next
doesn't
matter,
it's
got
to
support
them
all.
So,
yes,
we
have
to
make
sure
that
it's
accommodated
I'm
gonna
go
to
Jeff
and
then
response
to
suit
in
response
to
sue.
Most
of
the
big
items
are
likely
to
be
augmentations
with
a
feature
statement.
So
that's
from
Jeff
pause.
G
B
G
B
So
one
of
the
solutions
you
talked
about
was
actually
bringing
the
version
into
the
X
into
the
path,
and
is
that
the
same
name?
Where
is
that
now
a
different
name?
I
think
we
have
to
discuss
the
same
context
of
the
specific
solutions
we
want
to
minimize
impact
to
the
community
into
the
implementations.
But
we
really
have
to
talk
about
it
in
the
context,
specific
solutions.