►
From YouTube: IETF113-NETMOD-20220322-0900
Description
NETMOD meeting session at IETF113
2022/03/22 0900
https://datatracker.ietf.org/meeting/113/proceedings/
B
I
think
they're
they're,
looking
at
the
total
attendance,
remote
and
so.
C
We
definitely
have
less
people
in
the
room
physically
and
virtually
than
normal,
but
welcome
to
netmod
at
ietf
113..
C
You
have
the
chairs
myself,
lou,
berger
kent,
watson
and
joel
juggling
and
in
the
room
we
have
charles
eckel
who's
volunteered
to
help
us
out.
It
doesn't
look
like
he's.
Gonna
have
too
many
people
in
there
to
to
manage,
but
we
appreciate
the
help
very
much.
C
As
this
is
the
ietf,
we
have
our
notewell,
which
talks
about
our
rules
governing
our
participation
in
these
meetings,
in
our
mail
lists
and
in
the
physical
and
virtual
hallways
and,
if
you're
unfamiliar
with
it.
Please
take
a
look
at
the
note
well
and
similarly,
we
also
have
a
code
of
conduct
that
talks
about
how
we
should
treat
each
other
professionally
and
with
respect.
C
On
the
administrative
side,
we
are
using
meat
echo
for
q
control.
There
actually
is
a
nice
slide
for
those
who
are
local,
who
that
talks
about
how
to
do
that,
but
we're
in
the
second
day
now
and
all
three
or
four
of
you
are
professionals
at
this
point
at
the
new
meat
echo
tool
for
the
rest
of
us
you're
hearing
this
so
you've
made
it
welcome.
I've
put
the
note-taking
link
in
the
chat.
Also
there's
a
nice
button
for
meet
echo
to
take
you
there,
please
jump
on
to
that.
C
The
hedge
dock,
the
notes
page
and
help
ensure
that
we
capture
any
of
the
discussion
in
the
meeting.
You
don't
have
to
capture
all
the
presentation.
Just
the
the
discussions.
C
First,
up
on
our
agenda
is
the
important
topic
that
we've
been
working
about.
Versioning
and
we've
had
two
documents
go
through
working
group
last
call
recently,
and
we
have
another
set
of
documents
that
we're
hoping
to
last
call
soon.
But
the
authors
tell
us
there's
some
issues
to
work
through
and
that's
what
we'll
be
trying
to
do
here?
The
if
you
look
at
the
hedgehog
you'll
see
that
there's
a
version
of
a
slightly
modified
version
of
the
agenda
in
there
and
you'll
see.
C
C
Since
the
last
meeting
we've
had
several
rfcs
published,
that's
great
after
all,
that's
why
we're
here
is
to
get
these
documents
through
the
process
appreciate
everyone
who
worked
on
it,
whether
you
were
author
contributor
or
just
working
group
member
who
commented
on
it.
So
thanks
all
for
getting
us
over
the
hurdle
of
getting
those
documents
published.
C
We
have
two
documents
which
are
almost
perpetually
post
last
call
waiting
on
a
minor
update
and
expired,
and
I
was
gonna
put
the
person
the
author
on
the
spot
I
saw
he
was
about
to
move.
Maybe
he
wants
to
come
to
the
mic
and
say
something.
D
Yes,
rob
wilson,
cisco,
so
yes,
I
I
had
tried
to
find
some
a
co-author
to
help
with
this
last
late
last
year
and
that
fell
through
and
there's
somebody
else,
who's
interested
scott
man.
Manson
said
he
might
be
interested
so
I'll
chase
to
see
if
and
get
him,
but
I
need,
I
think,
having
somebody
else
to
help
me
on.
On
finishing
these
would
be
helpful,
but
otherwise
I
still
want
to
get
them
completed.
It's
just
fun
in
the
time
all
the
other
workload,
so
apologies.
C
C
Don
fedec
try
him
us,
we
can
talk,
hopefully,
okay,
yeah.
We
look
forward
to
like
getting
that
done,
they're
very
useful
pieces
of
work
and
we
don't
want
to
lose
that
that
went
there
all
the
effort
that
went
into
that.
We
have
three
others.
I
mentioned
the
last
two
that
we
have
got
mine's
killed
in
the
tower.
C
For
your
information
I
never
saw
the
mic
button
go
the
color.
It
means
that
you
you're
unmuted,
so
you
were
muted
that
whole
time.
Kent
do
you
want
to
add
anything
about
69.91.
A
It
completed
your
class
call
and
it's
I
think
it's
on
me
now
to
do
the
shepherd,
write
up
and
move
through
the
process.
C
Okay,
great
yeah,
on
the
the
other
versioning
documents,
we
did
get
some
comments.
We
I
believe
a
new
rev
is,
is
needed.
C
These
documents
will
once
they're
complete,
we'll
we
will
hold
them
until
the
whole
set
is
ready
to
go
so
there's
other
other
documents
that
are
on
the
agenda
until
they're
ready
once
they're
also
passed
working
group
last
call
we'll
put
them
through
the
isg
as
a
set,
so
they
can
be
processed
as
a
set.
That's
that's
our
plan.
We
have
one
document
that
was
returned
to
the
working
group.
It's
not
on
the
agenda
it
needs.
C
It
doesn't
need
a
lot
of
work,
but
it
needs
someone
to
pick
this
up
to
really
close
on
it.
Kent
you're,
looking
for
a
volunteer
to
help
out
there
right.
A
Volunteer
for
syslog
yeah,
or
do
you
think,
that's
covered
up?
Yes,
if
someone
could
help
with
that,
it's
a
it's
a
working
group
document.
It
doesn't
need
to
be
the
original
authors.
Really.
All
that
needs
to
be
done
right
now
is
to
update
the.
A
I
think
the
examples
I
mean
originally,
it
was
to
go
through
the
whole
thing
to
make
sure
you
know
what
all
the
needed
updates
are,
but
I
think
a
quick
review
and
I
I
feel
like
it's
probably
just
a
matter
of
updating
the
examples
and
then
putting
it
back
into
the
queue.
That's
all
we
need
someone
to
help
us
with
that
very
easy.
C
All
right
well,
if
anyone's
willing,
please
contact
the
chairs
or
even
better,
just
suggest,
changes
on
the
list,
and
then
we
can
close
this
document
out
and
bring
it
back
to
the
ihg.
C
We've
had
no
incoming
liaisons
or
communications,
and
I
think
we
all
are
well
adept
at
working
remote.
Just
a
reminder,
though,
that
we
do
we
can
do
formal
interims,
and
if
you
have
a
topic
that
you
would
like
to
request
to
be
a
formal
interim,
just
contact
the
chairs
and
with
that
we're
ready
to
move
on
to
the
versioning
update.
C
Hey
joe
charles,
do
you
want
to
take
slide,
control
or
I'll,
send
it
to
you.
C
For
future
speakers,
the
app
lets
you
do
that
if
you
had
the
meet
echo
app,
but
since
you
don't,
I
gave
it
to.
H
Cool
this
is
even
though
on
the
agenda.
It
says
that
this
is
going
to
be
mainly
on
module,
versioning
and
and
yan
would
cover
simver.
This
is
going
to
cover
kind
of
an
intro
where
we
are
as
well
as
module,
versioning
and
simver.
I'm
joe
clark,
your
host
for
this
particular
part
of
the
program.
Next
slide,
please,
charles,
so
that's
me.
H
I
it
says
rob
will
be
presenting
packages,
but
jan
will
actually
be
presenting
packages
and
in
this
deck
we
have
some
backup
slides
that
cover
kind
of
the
wherefore,
some
examples,
but
we
won't
bore
you
with
that,
we'll
just
focus
on
what
has
changed
since
112.
next
slide,
please.
H
These
are
the
five
drafts
that
we
are
going
to
come
up
with,
some
of
which
have
already
happened
and
we'll
be
focusing
on
the
semantic
versioning
and
the
module
versioning
and
then,
as
I
mentioned,
yan
will
get
into
packages
and
the
next
set
of
work
in
the
order
that
we
are
going
to
look
at
it
are
the
protocol
operations,
so
version
selection
is
next
and
then
the
tooling
around
all
of
this,
the
yang
the
related
yang
tooling,
to
process
the
the
versions
to
look
at
like
the
lineage
of
these
yang
modules.
H
All
of
our
work
is
being
tracked
in
git,
so
we
we
kept
the
old
design
team
get
repo.
We
have
issues
there
and
next
slide.
Please
we
meet
regularly
every
tuesday.
In
fact,
today
is
a
tuesday
and
we
are
going
to
have,
or
at
least
attempt
to
have
our
meeting
today.
It
is
at
2
p.m
or
daylight
savings
time
and
we're
kind
of
in
this
interesting
bubble
where
the
u.s
switched
and
the
rest
of
the
world
hasn't
yet,
but
generally
it's
around
9
a.m.
Eastern
2
p.m.
H
In
the
uk,
we
have
a
number
of
represent
representatives
that
attend
us,
consisting
of
operators,
various
vendors,
where
we
discuss
all
of
these
five
drafts
and
we've
kind
of
been
tackling
them
in
the
order
that
you
saw
on
the
previous
slide.
These
meetings
are
open
to
all
we
host
them
on
webex.
The
chairs
set
that
up
so
by
all
means
you
are,
are
free.
Anyone
is
free
out
there.
I
think
most
of
the
people
in
this
room
actually
attend
those
meetings,
but
you're
free
to
join
and
and
help
us.
H
With
these
discussions
we
bring
back
minutes
and
we
bring
back
discussion
points
to
the
list.
Jason
stern
has
typically
been
doing
that
so
you'll
see
updates
on
the
netmod
list,
as
we
discuss
things
next
slide,
please.
H
So
what
have
we
been
doing
since
112.?
As
lou
mentioned?
We
we
got
the
module
versioning
and
we
got
the
simver
drafts
into
last
call
and
we'll
talk
about
the
comments
we
got
on
those
in
a
bit.
So
we've
been
focusing
mainly
on
the
packages
on
what
what
is
the
the
kind
of
the
where
for
the?
Why
of
yang
packages?
H
What
does
the
structure
of
those
look
like?
We've
explored
different
kind
of
different
layouts
or
different
architectures
for
that
opening
and
closing
some
issues.
We've
talked
about
different
types
of
packages
and
yan
will
get
into
this
idea
of
an
api
package
versus
an
implementation
package
as
well
as
what
is
the
metadata
around
yang
packages.
What
does
that
look
like
and
what
are
the
use
cases
that
led
to,
as
I
mentioned,
a
ton
of
issues
and
we've
been
working
through
them?
H
What's
going
to
happen
next,
as
we'll
see,
is
we're
going
to
focus
back
on?
The
working
group
last
call
comments
that
we've
received
on
the
the
two
drafts
already
as
well
as
continuing
in
in
this
packages.
Work
next
slide,
please
so
module
versioning.
So
this
was
the
the
first
draft
and
that
leads
in
december.
H
We
just
closed
working
group
last
call
lou
mentioned
there
will
be
a
revision
at
least
one
revision
of
this
draft.
Jurgen,
italo
and
andy
brought
up
issues
we
haven't
had
a
chance,
yet
on
the
the
kind
of
the
author's
contributors
call
to
go
through.
All
of
these
that's
going
to
be
kicked
off.
H
Probably
today,
if
we
get
some
critical
mass,
but
certainly
in
the
next
few
weeks,
we'll
be
discussing
these
issues
and
you
see
some
of
them
there,
we
had
some
contradictions
in
normative
language,
around
file
names
and
ultimately,
we
want
to
clarify
and
improve
and
discuss
different
ways
or
different
complexities
with
the
solution,
so
that
we're
for
the
most
part
from
a
a
consensus
standpoint
that
we're
comfortable
with
with
what
the
yang
versioning
the
module
versioning
solution
presents
and
how
it
will
be
used
next
slide.
Please.
C
Joe
before
you
go
on,
I
should
have
mentioned
that,
based
on
the
update
we'll
decide
whether
there
needs
to
be
a
second
last
call.
If
it's
mainly
editorial
and
consistency
checks
changes,
we
won't
do
a
last
call,
but
if
there's
something
really
substantive
there,
that
needs
to
be
discussed
at
the
working
group.
We
will
my.
C
H
Thanks
we
will
I
I
I
I
kind
of
evaluate
some
of
what
jurgen,
andy
and
atallo,
especially
on
on
module.
Versioning,
have
said
it's
kind
of
like
what
an
aed
might
to
do.
It
might
do
with
a
discuss.
H
I
think
it's
going
to
require
a
lot
of
that
discussion
back
and
forth
and
the
the
changes
that
come
out
of
that.
As
you
said,
we'll
see
the
level
of
substantive
change
that
needs
to
happen
and,
and
perhaps
a
another
last
call
might
be
warranted
with
the
semver
draft.
Mainly
jurgen
responded
but
italo
we'll
we'll
actually
look
at
atallo's
comment
in
a
second
here.
H
Some
of
jurgen's
changes
were
fairly
editorial
in
nature.
He
recognized
some
typos,
some
some
things
that
were
quote-unquote
low-hanging
fruit
to
fix.
They
have
already
been
fixed
in
our
get
repository.
H
However,
there
were
some
things
that
will
require
that
additional
discussion,
and
so
I've
raised
issues
for
that
and
we're
going
to
go
through
them
again
anyone's
free
to
join
and
help
us
with
those
conversations
and
we'll
get
back
to
the
list.
So
we're
not
ignoring
you
year
again,
we
will.
We
will
get
back
and
address
these
items
that
we
we
have
as
issues
here
next
slide.
Please,
it's
hollow's
comment
was
interesting,
so
he
asked
what
about
in
in,
like
the
code
begins
or
in
rfc
version,
three
format:
the
source
code?
H
What,
since
we're
proposing
an
alternative
file
name
and
this
the
alternative
file
name-
is
with
the
revision
label,
which
can
be
a
yang
simver.
We
would
in
the
module
versioning
draft.
We
state
that
you'll
use
a
hash
mark
to
delineate
that
what
comes
after
is
a
revision
label
italia
asks.
H
Should
we
change
the
code
begins
and
the
source
code
tags
in
the
internet
draft
language
to
accept
those
alternate
file
names,
and
if
we
do,
if
we
do
do
things
other
than
a
revision
date,
do
we
run
the
risk
of
blowing
up
the
line
length
because
you
could
have
a
fairly
long
module
name
with
some
ridiculously
long
revision
label
as
well?
So
we
discussed
this
a
little
bit
and
the
the
consensus
among
among
the
contributors
is,
keep
it
either
as
it
is
now
or
or
rob
is
actually
fairly
keen
on
what?
H
If
we
stipulate
that
don't
include
anything
just
the
module
name-
and
this
is
where
tooling
will
come
in
and
find
the
latest
revision
in
the
module
and
extract
that
to
a
file
as
both
module
name
at
revision
date
and
module
name,
pound
or
hash
revision
label,
as
is
present
in
the
module.
This
way,
it's
it's
a
little
simpler.
It
actually
reduces
some
of
the
errors
we've
seen
in
extracting
modules
where
people
change
the
revision,
but
they
don't
change.
H
The
code
begins
tag
and
hilarity
ensues
with
the
zim
tool
and
and
what's
happening
in
the
data
tracker
in
yang
catalog,
so
we're
going
to
figure
out
what's
the
best
solution,
do
we
leave
things
as
they
are
now?
That's
obviously
easiest,
or
do
we
add
some
text
that
says
we
recommend
not
including
the
revision
date
there
either
and
and
leave
it
up
to
tooling
to
do
the
right
thing.
So
that's
kind
of
the
one
issue
we
discuss.
H
We
are,
of
course,
open
in
all
of
these
to
what
the
working
group
may
may
want
to
suggest
or
offer
in
terms
of
guidance
next
slide.
Please.
H
The
other
big
thing
that
was
raised
so
so
jurgen
commented
on
the
the
last
call
on
that
thread
that
lou
started
and
then
started
a
new
thread
in
parallel
to
that,
with
an
alternative
to
yang
simver
and,
to
some
degree,
the
the
module
versioning
as
well,
and
just
by
way
of
an
example-
and
this
is
directly
from
his
email.
What,
if
on
every
node
where
there
is
a
non-backward
compatible
change,
that's
nbc,
non-backwards
compatible.
H
There
is
a
tag
that
is
added
nbc
change
as
an
example
listing
the
revision
date
at
which
that
non-backwards
compatible
change
was
introduced
and
then
describing
what
that
non-backwards
compatible.
The
semantic
change
need
the
semantic
change
that
was
that
was
done
in
the
beginning,
a
while
back
when
we
first
started
talking
about
yang
versioning.
H
This
was
brought
up.
There
was
some
discussion
with
this.
There
was
some
back
and
forth
that
maybe
this
would
add
too
much
verbosity.
This
could
be
something
that
that
gets
moved
into
the
tooling
section,
but
it
needs
further
discussion.
H
We
we
fully
admit
we've
read:
we've
read
this:
we've
we've
heard
both
jurgen
and
andy's
comments
here
or
read
them.
I
should
say,
and
we're
going
to
discuss
this
further
and
and
decide
what
the
the
the
response,
what
the
action
to
take
here
is
going
to
be.
So
this
is
going
to
be
one
of
those
items
that
gets
added
on
to
the
to-do
list
for
our
weekly
calls
after
this
meeting
next
slide,
please
all
right.
H
So
this
takes
me
towards
the
end
of
my
section
and
and
I'll
be
handing
things
over
to
yon.
As
I
mentioned,
we're
discussing
these
weekly
the
issues
here,
you
can
look
at
our
whole
issue
tracker
at
the
the
github
project
link
there,
and
you
can
also
look
at
the
latest
revisions
of
all
of
the
drafts
and
see
what
state
we
are,
even
if,
before
we
publish
to
a
data
tracker
so
going
forward,
we're
going
to
address
we're
absolutely
going
to
address.
H
Those
working
group
last
call
comments
that
we
got
on
versioning
in
simber,
we're
still
focusing
very
much
on
the
the
packages
draft
and
getting
a
lot
of
good
input
from
the
the
various
participants
on
our
contributors
call
and
then
we're
going
to
break
into
those
those
final,
two
final,
two
work
items
on
version
selection
and
the
schema
comparison
or
the
tooling,
as
it
were
once
we're
kind
of
getting
that
same
last
call
state
for
packages.
H
So
any
questions
before
I
hand
over
to
yon.
H
B
C
No,
it's
it's
the
next
presentation.
I
don't
know
why.
It's
not
letting
me
have
to
do
it
now.
Let
me
you
have
to
pass
control
back
to
me.
C
No,
it
says
it's
taken,
so
maybe
you
can.
You
can
do
that
if
you
have
control.
B
C
G
C
F
C
I
So
first,
a
few
updates
on
what's
happened
since
112,
and
one
of
the
things
we've
been
talking
about
is
something
we
call
issue
57
it's
about
what
we
do
with
mount
points
when
they
appear
in
packages.
I
I
Should
we
in
some
way
prescribe
or
allow
an
implementation
to
prescribe
what
sort
of
packages
that
may
end
up
being
mounted
on
that
mount
point
or
not,
and
it's
an
open
discussion,
let's
say
another
thing
we
tried
or
discussed
is
about
the
how
packages
are
communicated
when
you
connect
to
a
device.
How
do
you
know
which
packages
are
implemented
on
this
device?
I
I
mean,
if
you
remember
from
my
discussion
earlier
about
how
net
conf
performance
can
be
increased.
I
took
a
real
world
application
and
measured
it
for
one
hour
and
all
the
traffic
that
was
sent
there
to
a
particular
device,
and
we
found
that
in
that
particular
real
world
application.
91
of
all
the
traffic
was
hello
messages
and
that's
kind
of
high,
but
that
was
of
course,
a
device
that
was
using
a
lot
of
yang
1-0
modules
with
zhang
wanted
one.
I
The
traffic
would
of
course
reduce
dramatically
when
it
comes
to
hello
messages,
but
in
principle
the
mechanism
for
finding
out
what's
available
on
the
device
is
still
fairly
similar.
Even
with
the
angle
inject
library.
It's
just
that
you're
exchanging
the
information
in
young
library
less
often,
but
what
we
can
do
with
packages
is
then
to
try
to
reduce
the
gap
with
how
people
think
about
what's
running
on
the
device.
I
We
don't
generally
go
around
and
list
and
say:
what's
this
device
doing,
and
then
you
list
1
000
modules
we
think
of
it
as
functional
groups,
something
like
packages,
but
now
we
have
a
number
of
different
mechanisms
that
a
client
needs
to
understand
in
order
to
be
able
to
manage
the
device
generically.
We
have
the
young
1.0
mechanism,
hello.
We
have
the
young,
the
1.1
mechanism
with
the
young
library.
I
We
have
net
monitoring
and
it's
starting
to
build
up
with
different
mechanisms
that
you
need
to
understand,
and
packages
would
be
the
fifth
mechanism
adding
to
the
list
of
things.
You
need
to
understand
to
do
this,
so
we
had
a
discussion
of.
Could
we
maybe
integrate
this
into
yang
library
in
some
way
to
reduce
the
gap
and
reduce
the
amount
of
code
that
you
need
to
have
in
order
to
understand,
but
in
the
end
we
gave
up
and
found
that
the
gain
of
trying
to
integrate
those
two
was
not
really
making
things
easier
anyway.
I
We
are
talking
about
the
issues
133
135,
about
optional
packages
or
optional
modules
that
are
optionally
part
of
the
packages,
and
this
ties
back
with
this
discussion
that
I'll
show
you
in
a
few
slides
about
api
and
implementation
packages.
I
I
We
talked
about
adding
revision
labels
for
packages,
and
we
decided
that
we
propose
to
you
to.
Itf
must
use
yang
zamber
labels
for
packages,
and
we
recommend
that
other
organizations
should
use
that.
I
Another
concern
we
have
had
is
how
deviations
are
part
of
packages,
and
we
updated
the
text
to
make
it
even
more
clear
that
the
standardization
body
cannot
use
deviations
in
their
definitions,
and
the
reason
for
that
is
that
that
would
basically
create
a
sdo
war.
You
cannot
an
implementer
cannot
implement
an
sdo
that
is
leveraging
in
other
sdos
packages.
If,
if
we
allow
deviations
in
these,
of
course,
implementations
can
use
deviations.
A
particular
device
can
have
deviations
from
a
standard,
but
the
standards
cannot
have
deviations
in
themselves.
I
We
had
checksums
for
packages
for
a
while,
but
they
have
been
removed.
Now
I
think
there
there
is
some
value
attached
to
this
concept.
You
could
verify
that
the
modules
are
indeed
the
ones
that
you
expect
so
that
even
if
people
forget
to
add
the
revision
statement,
when
the
module
is
changed
that
would
be
detected
by
checksums,
but
there's
also
a
bit
of
complexity,
defining
how
to
compute
those
checks.
B
Yeah
thanks,
so
I
just
had
one
question
going
back
about
that
standards:
creating
a
deviation
of
a
standard.
How
do
you
envision
biz
versions
working?
Would
there
at
least
be
a
like
a
bit
of
a
transitions.
I
The
the
sort
of
task
force
that
is
working
at
this
is
called
the
zhang
versioning
design
team
right.
So
all
of
these
five
or
six
different
documents
are
about
versioning
and
how
you
handle
things
that
are
changing
over
time.
So
I
I
think
well
in
any
way,
deviations
are
not
the
mechanism
to
communicate
version
changes.
I
I
I
Yeah
checksums,
we
removed
those
because
of
the
complexity,
even
though
they
have
some
merits.
We
talked
about
or
we're
in
closing
the
discussion
about
nbc
changes
and
parents
in
history,
and
there
was
some
mix
up
between
version
and
revision
statements
in
the
terminology.
I
Nothing
is
optional
in
the
implementation
package,
because
it's
it
documents,
the
actual
implementation,
and
it
may
contain
deviations
then,
and
to
separate
these
two
could
be
useful
because
it's
more
clear
than
what
you
can
and
cannot
do
with
within
the
package.
For
example,
in
an
api
package,
you
wouldn't
have
any
deviations,
whereas
in
the
implementation
you
might,
but
it's
also,
we
are
trying
to
discuss
to
see
exactly.
Where
is
the
line?
Is
it
really
worth
the
effort
to
separate
this
into
two
different
kinds
of
packages?
And
what
does
that
difference?
I
I
I
And
we
are
considering
having
two
different
lists
of
packages
to
make
this
even
more
clear
than
to
have
a
packages
and
the
api
and
the
packages
implementation
underneath.
I
You
have
an
api
package
that
could
be
coming
from
ipf,
so
it's
routing,
for
example,
this
corresponds
rather
well
with
how
people
think
about
modules
and
sets
of
modules,
and
it's
routing
would
then
consist
of
itf
network
device.
Idfpgp
and
itf
is
is
in
the
particular
versions,
but
it
would
also
list
packs
that
is
compatible
with
that.
We
know
that
would
work
here.
It's
not
part
of
the
package.
I
So
if
you
say,
if
the
device
says
that
it
supports
itf
routing,
we
would
know
it
has
itf
bhp
and
isis,
but
it
would
not
necessarily
have
rip
vrp
and
eccles,
but
it's
still
valuable
to
have
the
information
about
compatible
packages
as
a
designer
can
pick
a
package
that
should
work
well
together
and
then
on
the
right
side.
We
have
the
implementation
package
example,
we
call
it
vendor.
I
I
So
this
is
discussion.
Is
this
split
between
api
and
implementation
packages?
Useful?
Do
you
think
it's
an
open
question
to
the
thor.
C
I
K
Let's
see
if,
if
the
implementation
package
first
work
works,
if
it
does,
then
maybe
it's
a
nice
to
have
to
say
the
itf
is
proposing
this
bigger
package
that
you
call
api
and
by
the
way,
apis
work
to
me,
because
most
of
them
are
apis,
but
the
itf
is
targeting
this
specific
set
of
modules
to
work
together.
K
L
Tom
hill
bt,
I'm
going
to
say
exactly
the
opposite
of
memoir,
I
feel
like
the
api
packages
are
absolutely.
C
So
I
see
myself
next
in
queue,
and
I
was
going
to
say
that
something
along
the
lines
of
tom
that
you
know
as
a
from
a
a
provider
standpoint
or
a
user
standpoint,
I
could
see
wanting
to
define
a
package
and
then
have
my
vendor
tell
me
what
they
actually
do.
So
I
I
I
think
it's
a
useful
concept,
also
from
both
perspectives,
thanks.
That
was
my.
G
I
So
we
have
been
discussing
with
about
how
much
optionality
we
should
allow
in
a
package.
Of
course
we
want
package
to
be
a
flexible
concept.
So,
that's
you
can
say
yeah,
okay,
routing
is
here.
I
So
then
the
second
alternative
is
to
not
allow
optional
modules,
but
have
this
list
of
compatible
modules
that
to
make
it
easy
for
designers
to
figure
out
which
combinations
of
packages
might
work
well
together.
And
this
is
still
certainly
being
discussed,
and
we
feel
that
probably
or
leading
a
bit
towards
the
second
choice
here.
But
it's
still
very
open.
I
And
if
we
want
to
have
optional
modules,
we
have
been
designing
it
like
this.
In
the
yang
we
have
a
field
called
optional,
which
could
be
true
or
false,
and
both
for
on
the
package
level
and
on
the
module
level,
so
it
could
be
listed
there
if
we
wanted
to
have
optional
features
in
packages
and
with
option
two.
B
L
Hello,
it
was
quite
loud
in
the
room,
so
I
apologize.
If
I
wasn't
well
heard.
L
So,
just
to
repeat
what
I
what
I
said,
I
I
was
going
to
point
out
the
opposite
of
of
what
benoit
had
iterated.
I
am
much
more
in
favor
of
api
packages
than
implementation
packages
and
the
reasoning
behind
that
is
because
I
would
like
to
define
what
my
routers
across
multiple
vendor
types,
multiple
software
versions,
what
they
adhere
to
and
the
power
the
packages
that
they
would
and
the
modules
that
they
would
form
into
yang
rather
than
query
them
and
ask
them
what
they
can
do.
L
I
need
to
be
quite
prescriptive
about
making
sure
that
they
are
in
aligned
in
the
the
yang
that
they
generate,
and
that's
why
I
think
I
prefer
the
api
package.
L
B
L
K
K
Jan,
can
you
go
back
to
a
previous
slide
where
we're
comparing
this
one
exactly
right,
so
the
one
on
the
left
is
the
list
of
things
that
typically,
you
would
ask
from
different
vendors
right,
and
you
would
say,
give
me
this
set,
because
I
need
to
be
interoperable
right,
the
one
on
the
left
and
then
the
one
on
the
right
is
okay.
What
are
the
vendors
doing
right
now
at
different
stages?
K
That's
the
way
I
understand
the
one
on
the
right,
which
is
like
okay,
you
aspire
to
go
to
the
one,
the
left
and
right
now,
because
there
are
different
versions,
it's
life
cycle,
etc.
You
have
the
one
on
the
right,
so
my
question
is:
is:
is
it
the
right
way
to
formalize
the
one
on
the
left
and
if
you
go
back
to
your
previous
slide,
yam
right
this
one?
K
Is
it
the
right
way,
tom
to
formalize
all
this,
the
one
from
the
itf
one
in
this
format,
because
you
want
to
compare
easily
what
you
want
to
have
with
what
you
are
receiving
right
now
from
the
different
vendors
or
just
telling
the
vendors?
This
is
my
list
of
things
I
want
in
rfp
is
good
enough
see
my
point.
L
If
some
of
my
router
vendors
are
producing
yang,
that
is
different
to
the
others.
So
I
can.
I
can
entirely
see
why
we
would
want
to
have
both
types
of
packages.
It
might
suit
different
operators.
Absolutely
fine,
but
for
me
lots
of
networks,
lots
of
platforms,
lots
of
vendors,
and
I
don't
want
to
write
extra
code.
L
I
need
to
be
more
prescriptive
and
focus
on
enforcing
the
left
and
not
we
might
forego
some
features,
but
we're
also
hoping
to
encourage
interoperability
across
vendors,
which
is
why
I
would
like
to
be
more
prescriptive
about
the
packages
and
the
modules
rather
than
query
the
router
and
say
what
can
you
do
and
say?
I
would
like
you
to
do
this.
L
K
K
B
C
You
have
several
more
in
queue,
I
don't
know
if
benoit
and
tom
want
to
stay
around
because
it
might
be
relevant
robert
or
rob.
D
Sorry
yeah
so
robinson
speaking
as
a
contributor,
so
I
just
wanted
to
emphasize
that
this.
These
two
types
patches
are
solving
different
problems,
as
has
been
has
been
discussed
here
that
the
api
package
is
trying
to
to
give
the
specification
of
what
is
desired
and
the
implementation
packages
is
giving
the
real
implementation
of
saying
for
a
particular
device.
D
This
is
what
it's
doing,
and
you
may
have
that
implementation
package
just
being
served
up
from
the
device
itself
in
the
same
way
that
yang
library
gives
you
that
information
today,
and
it
also
allows
a
vendor
to
advertise
that
off
the
box
and
say
for
my
particular
version
of
this
os
these
these
the
packages
that
I
implement,
the
apis
that
I
implement
and
I
have
these
deviations
because
I
can't
implement
them
completely
faithfully,
but
it
allows
the
the
people
who
write
the
instrument
instrumentation
code
to
know
what
those
differences
are.
So
it's
about.
D
M
Done
my
homework,
the
thing
I'd
observe
here
is
that
there's
sort
of
a
heating
set
of
requirements
and
we've
touched
on
some
of
them.
What
I
would
sort
of
highlight
a
desired
behavior
is
as
much
as
the
thing
on
the
left
is
what
people
may
want.
You
know:
here's
a
set
of
things
that
are
supporting
a
set
of
protocols
and
the
modules
are
part
of
them.
M
What
is
perhaps
better
to
focus
on
is
the
top
deliverable
is
for
a
given
module.
Egp
is
an
example:
it's
going
to
have
a
set
of
dependencies
and
other
modules,
and
we
look
for,
for
that
version
bjp.
What
is
the
compatible
set
of
it
modules
that
you
pull
into?
You
know,
implement
bgp
or
any
of
the
other
protocols,
ideally
just
like
with
linux
distribution.
M
M
C
J
N
So
I
think
it
would
be
very
interesting
if
we
could
specify
a
method
or
maybe
even
a
tool
that
would
say
that.
Does
this
implementation
package
fulfill
the
api
package
does
it
does
it
do
everything
that
the
api
package
is
asking
for?
I
We
have
been
trying
to
make
sure
that
the
package
definitions
are
such
that
if
a
package
is
announced,
we
would
know
rather
quickly
and
easily
from
a
client
side
if
that
package
is
fully
implemented.
We
of
course
have
deviations
that
goes
on
top
of
this
and
it
complicates
the
picture,
but
that
is
how
we
have
been
discussing
when
it
came
to
this
question
here.
I
Actually,
what
we
wanted
to
know
really
was
whether
this
concept
of
api,
separate
from
implementation
package
was
a
relevant
concept
and
from
the
discussions
that
came
in
here,
I
think
we
struck
a
chord
and
definitely
feels
like
the
distinction
here
is
meaningful
to
people.
So
that's
a
good
thing
to
to
understand
from
this.
Thank
you.
I
I
only
have
a
couple
of
slides
left,
I
think.
Let
me
yeah,
we
talked
about
optional
modules
and
how
that
would
look
the.
I
I
think
we
have
already
talked
about
this,
so
the
last
thing
is
about
scheme
amount,
as
I
mentioned
earlier,
we
have
been
thinking
about
what
happens.
If
you
have
a
mount
point
in
a
module,
that's
inside
a
package
can
we
in
some
way
convey
what
to
clients
what
they
will
find
at
that
mount
point,
we
have
seen
a
number
of
different
use
cases
and
for
some
of
them
it's
fairly
easy
to
describe.
I
I
C
So
I
think
any
any
other
questions.
M
O
Okay,
thank
you
good
morning,
everyone
good
afternoon.
This
is
ching.
I'm
going
to
present
this
participating
pack
and
the
main
objective
is
status
update.
The
current
version
number
is
version
six.
O
Recapture
a
little
bit
about
why
we
propose
this
worker
self-describing
data
object.
Tag
is
very
used
to
classify
the
data,
especially
for
the
operational
data,
and
you
can
capture
those
data,
or
example,
kpi
data.
So
it's
a
you
know.
Similarly,
choose
a
module
tag,
another
difference
the
multitasker
only
used
at
the
module
level
and
for
the
object
tag
used
at
the
data
node
level,
so
self-described
describing
bit
object.
Tag
can
be
using
streaming
telemetry
scenario
targeted
to
reduce
the
amount
of
the
data
export
destination.
C
O
O
Changed
since
the
zero
floor-
and
we
actually
made
a
two
update,
this
is
the
released
actually,
the
main
change
we
have
made.
The
first
we
add
user
tag,
maintenance
clarification
because
in
the
job
we
define
not
only
user
tag
but
also
ietf
tag
and
reserve
tag.
How
user
tag
is
distinguished
from
other
tag,
so
we
add
some
clarification
and,
secondly,
we
provide
a
guidance
to
discriminate.
O
Experts
for
evaluation
of
young
data
model
tag
registry
and
also
young
data
object
tag
prefix
rejected
and
we
made
a
two
update
to
the
bigger
one
and
v2
with
additional
text,
and
we
also
enhance
the
security
section
for
the
user
pack
management
and,
in
addition,
we
actually
based
on
young
computer
review.
We
changed
the
data
object
name
into
the
short
name
and
and
also
we
made
some
other
additional
changes
to
address
the
region's
comments
and
comments
from
young
doctor
review
and
first
actually,
we
made
an
update
to
the
figure
man
with
additional
tags.
O
You
can
see
in
the
version
four
in
the
left.
Actually,
we
only
described
the
the
several
tag,
object,
tag
and
the
metric
tag
and
the
metric
group
tag
property
attacker
and
discuss
just
introduce
the
relation
with
the
data
object.
O
So
in
the
version
six,
actually
we
try
to
you
know,
add
additional
tag
which,
because
we
already
added
the
minor
source
tags,
so
we
change
the
metric
group
attack
to
magic
type
tag.
So
this
is
kind
of
you
know
rewarding,
and
so
you
can
see
the
change
we
have
already
made
and
this
kind
of
mighty
source
attack
is
not
actually
a
new
attacker.
It
has
already
been
defined
in
this
worker,
mostly
used
to
capture
the
data
object
from
multiple
source.
O
So
second
change
we
actually
made
in
the
ayanna
section.
Actually
we
really
need
to
provide
guidance
for
the
designing
the
experts
to
for
for
assignment
policy.
So
so
we
make
a
change
to
section
9.1
and
section
9.2
and
for
section
9.1
we
we
didn't
actually
add
any
specific
guidance,
but
we
added
some
statement
actually
to
make
sure
that
presumption
of
the
code
point
can
be
granted
hold
and
in
section
9.2.
O
Next
is
the
user
tag
for
meta
clarification
and,
as
we
clarify
we
introduce,
we
define
the
user
tag
and
ietf
tag
and
also
resolve
attacker.
We
only
readjust
the
ietf
tagger
for
usertag,
maybe
conflict
with
other
type
of
photogrammetries
of
tag
so
because
it
can
use
prefix
started
with
a
user
column
or
it
can
have
no
prefix
so
to
address
the
issue.
O
And
next
is
about
target
management
conflicting
resolving.
We
think
that
this
issue
has
to
be
discussed
on
net
network
manager.
We
actually,
this
is
maybe
not
only
applied
to
this
job,
but
also
applied
to
the
module
target
that
has
already
published
in
the
nether
mode.
The
working
group
and
the
problem
is,
when
one
client
add
or
remove
the
tiger
for
some
other
client
may
get
a
wrong
data.
O
O
We
do
see
some
cases,
you
may
add
a
remote
tag
in
the
running
timing
stages.
So
how
to
deal
with
this
so
to
address
this
issue,
we
added
some
text
in
the
security
section
to
really
strictly
the
client,
with
a
specific
client
level
or
specific
privilege,
and
this
issue
we
actually
we
posted
on
the
list
and
we
only
solicited
feedback
from
audio
tagger,
also
about
having
here
the
feedback
and
the
so
for
next
step.
We
think
of
all
the
issue
we
received
has
been
addressed
and
we
are
happy
to
receive
any
comments
in
this
meeting.
C
Yeah
hi
I'm
in
queue
as
contributor.
If
you
don't
mind
going
back
once
a
month.
C
I'm
not
sure
why
tag
is
any
different
than
a
any
other
read
write
leaf
here
or
leaf
list.
You
know,
I
I
don't
see
how
it
reveals
anything
additional
than
you
would
with
anything
that
could
be
written
from
a
client.
So
maybe
I'm
missing
something.
O
O
C
B
Okay
rob
go
ahead,
you're
on
the
cube,
I'm
checking.
E
D
Wilton
sorry
rob
wilson
as
a
participant,
so
just
looking
in
the
module
and
use
node
instance,
identifier,
which
I
think
is
the
right
answer,
and
it
looks
like
that-
allows
you
to
associate
a
tag
with
a
particular
instance
in
the
data
store
or
also
gives
you
the
flexibility
of
leaving
the
keys
out
and
associating
a
tag
with
all
instances
or
a
subset
of
instances
is.
D
My
first
question
is:
is
that
the
intention
seems
like
it's
a
good
thing
to
do
and
if
it
is,
it
may
be
helpful
to
to
to
sort
of
spell
that
out
and
clarify
that
in
the
draft
that
these
that
you
have
that
flexibility
when
you're
using
this.
O
D
I
need
to
check,
I
only
have
a
quick
look,
so
maybe
the
text
is
there,
but
I
think
spelling
that
time,
if
it's
not
there
already
would
be
helpful.
So
I
just
are
just
gripping
it
for
the
attack,
the
yang
type.
So
so
it
might
be
there
already,
but
it's
be
useful
over
there.
If
you
can.
G
Okay,
thank
you.
I
think
that's.
C
Yeah
but
oh
you,
so
you
think
the
document's
ready
for
working
with
last
call
right.
So
we
didn't
talk
about
that.
Yes,
yeah,
whether
we
last
call
immediately
or
not.
It's
good.
It's
a
good
time
to
get
extra
review
from
the
working
group.
The
chairs
will
discuss
the
the
working
glass
call
after
the
meeting.
Personally,
I
don't
see
any
reason
not
to
do
that,
but
you
know
that's
just
one
opinion
I'll
definitely
talk
with
the
co-chairs.
F
So
hello,
everyone
good
night
and
this
presentation
is
about
the
system
defined
collaboration,
work
with
that
we
have
the
and
in
john
this
work,
and
so
this
last
item
meeting
where
I
just
do
a
lot
of
passion
on
knowing
this
about
the
open
issues
of
this
work.
So
thank
you,
everyone
for
getting
involved
in
this
work
and
sharing
her
great
ideas
about
his
work,
and
there
are
a
few
issues
which
I
posted
to
the
mailing
list
since
last
item
meeting.
F
Let's
say
that
the
client
references
a
system
defined
configuration
which
is
not
present
in
running
actually
and
maybe
for
online
validation.
The
server
can
just
accept
it,
but
for
offline
validation,
it
will
fail,
and
maybe
we
can
say
that
the
server
can
just
validate
running
by
validating
intended.
F
But
it's
true
that
both
the
9,
15
and
ns3
42
defined
that
running
must
always
be
valid
and
also
to
maintain
backward
combability,
especially
for
those
lexical
lines
which
are
heavily
relied
on
the
offline
validation
of
running.
We
don't
really
want
to
break
those
clients
and
the
existing
implementations,
so
the
authors
decided
to
answer
yes
to
this
first
question.
Yes,
we
think
that
must
offline
validation
of
running
alone
be
required,
and
the
second
issue
should
the
origin
b
system,
or
intended
for
system
configuration
which
is
copied
and
tested
into
running.
F
I
think
we
received
different
opinions
about
this
issue,
but
more
folks
seem
to
incline
to
use
intended
as
the
value
of
origin,
but
it's
also
okay
to
use
already
ecosystem.
It's
a
value
keeps
unchanged,
so
the
current
draft
doesn't
really
limit
which
origin
should
be
used
about
this
issue
and
then
the
third
issue
about
immutable
flag.
F
It
has
already
been
defined
in
another
individual
draft,
since
we
may
not
restrict
this
flag
to
system
configuration
only
so
the
following
presentation
given
by
me.
We
will
talk
about
this
issue.
I
will
present
this
and
then
the
the
last
bullet
should
be
with
origin
parameter
b,
supported
for
intended.
F
A
Okay,
on
the
last
point
I'm
wondering
I
mean
I
do
understand
that
it's
defined
the
derived
from
or
self
when
expression,
but
we
could.
I
think
this
rfc
could
update
that
other
rc
if
necessary
and
and
extend
the
expression
so
that
it
could
be
operational
or
system
and
because
it's
like
it,
expands
the
scope,
it
wouldn't
break
any
existing
modules.
A
A
We
should
probably
discuss
what
what
do
we
want
and
then
and
then
decide
whether
or
not
it's
worth
updating
the
privacy.
D
Rob
wilton
as
a
participant,
so
I
I'm
conflicted
on
one
about-
must
running
always
alone
be
valid.
So,
although
I
agree
that
it's
always
useful
to
be
able
to
validate
running
so
you
should
have
that
capability.
I
do
wonder
about
whether
that
makes
life
difficult.
So,
if
you're
creating
interfaces
today,
I
think
the
interface
itef
interface
is
yang.
Model
allows
the
interface
type
to
be
instantiated
by
the
system
and
to
then
be
added
in,
and
I
don't
know
whether
what
the
answer
is.
Are
we
saying
that?
D
Actually
we
want
to
always
force
clients
to
specify
that
interface
type
whenever
they
configure
an
interface
to
make
that
like
a
valid
configuration,
or
are
we
saying
that?
Actually
we
allow
the
system
to
instantiate
that
value
in
running,
which
again
is
sort
of
breaking
the
idea
of
the
running
data
to
always
being
in
control
of
the
client
or
always
the
reality
that
actually
the
system
will
inject
an
interface
type
as
it
needs
to
and
then
do
the
validation
against
the
intended
data
store,
so
the
value's
there
as
required.
D
So
I
think
it
would
be
potentially
useful
if
we,
we
wrote
down
the
actual
configuration
steps
for
that
example
and
there's
agreement
as
to
how
this,
how
this
should
work
and
how
it
should
behave
to
to
understand
what
what
the
actual
operational
steps
would
be
for
this
and
to
check
that
that
makes
sense.
N
Yes,
just
reacting
to
rob,
there
are
a
number
of
other
sdos,
for
example,
3gpp,
which
explicitly
state
that
some
items
are
created
by
the
system.
So
if
we
would
want
to
restrict
that
in
any
way,
that
would
be
a
big
problem.
E
I
So
I
think
that
if
we
want
to
go
ahead
with
this
yang
project
that
where
we
can
reason
about
obligations,
we
should
stick
to
those
formal
rules
about.
F
I
Yes,
I
I
just
want
to
add
that
it's
not
exactly
the
validation.
That
is
the
problem
here.
The
clients
can
validate
or
not,
but
it's
the
reasoning
about
the
data
on
the
server
that
let's
get
broken
if
things
are
interfering
with
in
runtime,
without
letting
the
clients
know.
N
I
N
D
So
rob
wilson
as
a
participant
so
back
to
yan's
comments.
So
just
trying
to
understand,
are
you
saying
that
what
you
think
the
best
way
of
achieving
this
is
that
having
an
extra
option
to
the
edit
config
request
explicitly
says,
I
want
you
to
copy
the
system
parameters
into
running
and
that
would
allow
a
client
to
effectively
provide
a
partial
configuration
that,
for
example,
leaving
out
interface
types
and
by
having
that
explicit
you
copy
this
into
running.
D
F
We
here
admit
the
requirements
of
validation,
of
offline
validation
of
running
alone
and
define
that
any
referenced
system
configuration
in
syst
any
reference.
The
system
configuration
in
system
data
store
must
be
present
in
running
to
macron
invalid,
and
since
we
already
defined
that
the
reference
system
configuration
must
appear
in
running,
we
don't
really
need
the
system
parameter
which
is
used
to
return
a
merged
view
of
running
and
system
configuration
previously.
F
The
entire
contents
of
system
configuration
into
running
when
possible,
so
we
have
defined
another
parameter
reload
system
and
this
is
used
for
edit
config
and
edit
data
operation,
and
it
indicates
to
allow
the
server
to
populate
the
reference
system
configuration
automatically
to
make
the
running
configuration
valid
without
the
client
doing
the
the
option
explicitly
and
the
server
can
can
auto
populate
of
the
the
data
store.
Only
when
this
parameter
is
provided
and
for
lexical
lines
which
know
nothing
about
this
parameter,
they
don't
see
any
change
in
the
edit
config
or
edited
operations.
F
And
there
are
some
quotations
from
the
current
draft,
which
I
think
is
important
for
understanding
the
ideas
and
the
principles
of
the
draft.
So
I
just
give
some
quotations
here,
the
very
first
one
that
server
must
ensure
that
running
contains
any
referenced
system.
Con
system
objects,
as
I
have
mentioned,
in
addition
to
being
consistent
with
the
definitions
of
in
existing
rfcs.
We
are
intended
to
maintain
the
backward
capabilities
for
lexical
lines
here,
and
clients
must
exp
either
explicitly
config
system
defined
nodes
in
running
or
use
the
resource
system
parameter.
F
If
the
first
sentence
is
said
that
the
reference
system
configuration
must
be
present
in
running,
I
think
this.
This
sentence
answers
the
question
of
how
how
can
it
be
in
running?
There
are
two
ways
right:
clients
can
explicitly
config
the
system-defined
nodes
if
they
do
not
want
the
system
to
touch
the
configuration
actually
or
they
can
use
a
reload
system
parameter
for
convenient,
so
two
ways
define
that
online
system.
Awares
clients
copy
reference
system
nodes
from
system.
F
How
clients
are
aware
of
the
system
that
store
can
find
appropriate
configurations
beyond
the
scope
of
this
document
and
obviously
the
system
data
store
is
designed
as
a
standard
mechanism
to
allow
the
clients
to
see
what
system
configuration
is
available,
but
for
lexi
clients
that
know
nothing
about
this
document.
So
it's
it's
out
of
scope,
how
they
can
find
the
system
configurations
and
the
last
one
if
the
readout
system
parameter
is
not
given
by
the
client.
The
server
must
not
modify
running
in
anywhere
not
specified
by
the
client.
F
There
is
a
desire
to
let
it
declined
on
the
configuration,
so
there
used
to
be
an
objective
mention
in
the
draft
is
the
client
control.
The
configurations
should
be
totally
controlled
by
the
client,
so
we
have
just
so.
We
just
think
that
even
the
server
is
allowed
to
configure
the
reference
system
configuration
automatically.
F
N
Sorry,
this
last
bullet,
if
I'm
not
misunderstanding
it,
this
is
a
very
big
nbc
change
and
different
clients
might
have
different
ideas
about
this.
So
I
have
to
check
on
this,
but
this,
for
me,
is
a
showstopper
and
there
are
some
other
sbos
like
3gpp,
or
run
very
clearly
state
that
some
things
some
list
entries
are
only
created
by
the
system
itself.
A
N
Yes
here
it
says
that,
except
for
some
cases,
the
server
must
not
modify
running
in
a
number
of
other
sdos,
most
notably
in
3gpp,
and,
I
think
also
in
oran.
There
are
young
modeled
objects
which,
where
they
have
a
sentence,
that
this
object
is
created
by
the
system.
Only
so
the
client
is
not
even
allowed
to
create
that
object.
N
A
N
A
I
think
I
understand
so
now,
I'm
I'm
going
to
switch
to
speaking
as
contributor.
I
remember
several
years
back
when
we
were
working
on
yang
next,
I
forget
which
city
we
were
in,
but
you
were
at
that
time.
Talking
about
3d
3gbps
need
to
dynamically
create
configuration.
N
N
A
We
need
to
discuss
this.
I
think
the
appropriate
thing
would
be
for
3gpp
to
put
the
system
created
things
into
the
system
data
store.
I
understand
that
that
didn't
exist
before,
but
that's
what
it
should
have
been
that
they
moved
forward
anyway,
with
an
effectively
unapproved
non-standard
approach
is
something
that
we
should
discuss.
Whether
or
not
the
idf
caters
to.
N
A
It
was
actually
just
discussed
on
the
mailing
list,
not
that
long
ago,
and
in
fact
I
think
there
was
a
vigorous
discussion
about
how
the
system
can
act
like
a
client
and
and
itself
make
the
update
to
running
as
a
client
and
and
that
whole
discussion
was
in
fact
to
avoid
the
appearance
of
system
or
the
server
making
changes
automatically.
But
please,
let's
take
this
offline.
C
Yeah,
I
was
just
that
this
is
louis
contributor.
I
was
just
going
to
comment
if
there's
no
rfc,
that
precludes
something
we
can't
say
that
it's
not
allowed
just
an
email.
You
know
if
we
have
to
go
by
the
documents
and
if
the
documents
are
quiet
on
a
topic
we
generally
in
the
ietf
said
that's
a
loud
behavior,
so
we
should
think
about
when
we
start
adding
new
restrictions,
the
implication
on
someone
who
might
be
doing
something
that
is
wasn't
specifically
recruited.
C
So
I
I
guess,
I'm
agreeing
with
belage
here
that
this
that
his
point
is
something
we
should
consider
in
this
document
of
how
to
how
to
deal
with
clients.
Sorry,
how
to
deal
with
young
models
and
implementations
that
might
have
been
doing
something
that
was
not
previously
discussed
in
any
document.
N
And
also,
we
risked
really
alienating
a
big
community,
3gbp
and
old
radio
operators
if
we
force
them
to
avoid
yank.
They
have
at
this
point.
Two
solution
sets
one
based
on
yank
and
netconf,
the
other
based
on
json
schema
and
the
open
api.
N
C
Yeah
and
more
than
that,
this
is
a
change
in
allowed
behavior.
You
know
before
the
document
was
silent.
Our
documents,
all
the
I
don't
think
anywhere-
talked
about
this
explicitly
in
an
rfc,
so
we
we
had
something
that
was
allowed
in
existing
rfcs.
This
changes
that
so
I
think
we
have
to
take
that
into
consideration.
F
F
C
You
know
it's
clear
you're
generating
a
lot
of
discussion,
so
at
least
we
should
resolve
those
points
that
we
still
have
the
question
of
whether
or
not
the
group
wants
to
adopt,
but
I
think
that,
with
the
current
open
issues,
you
know
it
would
be
a
little
bit
contentious.
So
if
you
can
address
those
and
then
come
back
to
the
working
group
with
changes,
that
would
be
great.
F
So
if
there
is
no
other
comments,
I
will
put
this
open
issue
to
the
oh.
There
is
another
another
open
issue
addressed
by
kent
on
the
mailing
list
about
this
about
this
one.
So,
let's
move
into
the
the
next
presentation.
F
And
I
mentioned
earlier
the
this
idea:
an
immutable
flag
is
derived
from
the
system
defined
configuration
work
because
there
are
some
system
configurations
which
are
generated
to
be
non-deletable
or
even
non-modifiable
to
clients
they
are
configured
but
with
only
two
clients
and
but
some
some
are
read-only,
while
others
can
be
modified
so
allowing
some
configurations
modifiable
while
others
not
is
inconsistent
and
introduce
confusion
actually
so
to
resolve
this
issue,
we
want
to
define
a
standard
mechanism
to
see
what
system
configuration
is
with
only
two
clients
and
if
there
exists
some
system
configurations
which
are
generated
to
be
immutable,
we
want
to
make
this
information
visible
to
clients.
F
So
a
metadata
annotation
called
immutable
has
been
defined
to
indicate
the
immutability
of
a
data
node,
and
although
this
concept
is
motivated
by
system
defined
configuration,
we
do
not
really
want
to
restrict
this
flag
to
being
used
only
for
system
configuration
and
it's
used
to
annotate
instance
of
young
data
nodes
rather
than
schema
nodes.
And
after
it's
created
any
data.
F
Node,
annotated
with
immutable,
equal,
true
is
read
only
to
clients,
which
means
modification
or
deletion
should
not
be
allowed,
but
the
following
operations
should
be
allowed
like
create
an
immutable
data
node
with
some
value
initially
set
by
the
system.
If
it
does
not
exist
in
the
data
store
and
the
immutable
system
configuration
is,
is
not
present
in
running
and
the
client
can
configure
it
with
the
same
value
as
found
in
system
data
store
into
running.
F
So
this
should
be
allowed
and
delete
the
parent
node
of
an
immutable
data
node
unless
the
parent
node
is
also
annotated
with
immutable
co2.
For
example.
We
cannot
re,
really
delete
a
leaf
data
value
inside
a
list
instance,
but
it's
okay
to
delete
the
whole
list
entry,
which
includes
that
immutable
instance.
F
Here
gives
some
example
about
how
to
use
this
flag.
So,
on
the
left
side
of
the
slide,
there
is
an
interface
configuration
with
an
immutable
type
when
the
client
retrieves
a
targeted
data
store
like
system
and
got
such
a
reply,
it
should
realize
that
the
type
for
interface
eth0
it's
read-only
and
should
it
should
not
be
allowed
to
modify
it,
but
the
server
should
attempt
to
accept
an
edit
config
operation
towards
running
to
configure
the
interface
eth0
configuration
with
the
same
value
of
the
type
as
in
system
and
any
other
values
should
not
be
accepted.
F
It
should
be
rejected
and
on
the
right
side
of
the
slide,
there
is
a
system
defined
neck
rules
with
the
leaf
list
and
the
list
entries
annotated
with
immutable
equal.
True,
the
username
here
is
defined
as
a
leaf
list.
The
user
or
the
mean
for
the
admin
group
and
guest
for
the
group
visit
is
generated
to
be
immutable,
which
means
that
deletion
is
not
allowed,
and
the
rule
list
instance
for
the
admin
excel
is
also
immutable.
So
any
modification
and
deletion
to
this
list
entry
is
not
allowed,
while
the
other.
F
These
entries,
like
the
rules,
entry
for
visit,
scl,
the
annotation
for
this
and
the
annotation
for
this
entry,
is
not
specified,
and
the
default
is
the
same
as
the
the
parent
node
of
the
the
the
same
as
the
in
the
immutable
immutable
value
of
its
parent
node,
which
is
the
neck
in
this
in
this
example
so,
and
the
default
immutable
value
for
top
level.
That
node
is
false,
so
it's.
F
So
there
are
some
open
issues
about
this
work
and
the
first
issue
is
the
backward
capability.
What
if
the
lexi
clients
receive
some
annotations,
they
do
not
do
not
understand,
and
I
they.
We
have
two
options
here
and
option.
One
is
that
annotations
always
return
body
client
ignore
unknown
annotations,
silently
and
option.
F
Two
is
to
define
a
parameter
in
the
operation
request
to
indicate,
including
an
immutable
annotation
in
its
response,
and
the
current
draft
follows
option
1,
but
I
have
such
a
concern
that
the
design
may
break
the
lexical
line,
but
maybe
I
think
it's
okay,
because
there
is
a
fundamental
requirement
and
defined
in
the
79
15
2.
It
says
that
the
annotations
set
by
a
server
should
not
break
clients
that
do
not
support
them.
So
this
is
about
the
first
issue.
F
The
second
is
that
how
would
the
client
know
if
immutable
is
applied
to
the
whole
list?
Release
entries
or
both
the
same
applies
to
the
leaf
list,
because
these
annotations
can
only
be
attached
to
individual
list
or
leaflets
instance.
Then,
how
should
we
indicate
the
immutability
of
the
whole
list
or
leave
list?
F
The
whole
list
of
the
whole
leaf
list
so
so
that
the
client
can
understand
that
the
additions
or
deletion
to
the
list
or
leave
list
is
not
allowed.
I
think
this
is
a
question
so
and
then
the
the
third
one
is
that
when
should
the
server
reject
modifications
to
immutable
data
node
and
the
current
draft
said
that
the
error
reporting
is
performed
at
various
different
time
according
to
the
selected
target
data
store.
F
So
we
we.
We
all
know
that
if
there
is
an
attempt
to
modify
an
immutable
data
node,
the
server
should
reject
it.
But
when
should
it
reject?
If
the
target
data
store
is
running
or
startup
should
be
in
an
edit
config
or
edit
data
operation?
And
if
the
target
data
store
is
candidate,
the
reject
is
delayed
until
a
commit
or
valid
operation
takes
place.
F
The
last
issue
that
should
we
allow
the
client
to
delete
an
immutable
system
initiated
not
in
running
and
yet
because
I
know
that
there
seems
nowhere
to.
I
actually
did
the
system
defined
configuration
in
system
because
we
already
defined
that
the
deletable
system
configuration
must
be
defined
in
factory
default
and
the
non-digital
system
configuration
must
be
defined
in
system
and
system
configuration
system,
data
store
will
be
merged
into
intended
and
sent
and
much
into
operational.
D
So
rob
wilson
as
a
participant
contributor,
so
as
a
participant.
So
where
is
the
previous
work
on
the
with
systems?
Data
store?
I'm
quite
supportive
that
I
think
that's
solving
a
good
thing.
I
have
a
bigger
concern
here
that
if
we
allow
servers
to
to
arbitrarily
decide
that
some
configuration
is
immutable,
that
that
makes
life
much
harder
for
generic
clients
because
they
won't
know
up
front
just
from
the
schema.
D
What
things
are
immutable,
what
things
may
be
immutable
and
what
things
aren't.
So
it
feels
to
me
that
having
a
mutual
confidence
makes
life
harder
for
clients,
and
ideally
we
shouldn't
have
it.
It
is
my
opinion
now
I
know
that
balaj
may
feel
differently
for
his
implementations
or
the
3gpp
stuff
that
uses
this.
So
so
I
have
concerns
there.
So
I
think
the
another
way
look
at
this,
maybe
as
a
way
of
of
not
encouraging
a
mutual
configuration,
but
a
way
of
describing
it
if
it
is
there,
in
which
case.
D
I
think
that,
for
like
a
first
question,
your
option,
two
of
having
a
request
that
returns
a
parameter
that
says
return.
This
seems
like
a
better
choice
to
me,
so
it
allows
you
to
annotate
stuff,
that's
immutable,
it
doesn't
say,
encourage
and
say
you
should
do
this
and,
and
I
don't
think
it
should
sort
of
change
the
behavior
of
the
server
either
way
it's
just
providing
some
extra
metadata
that
comes
back
out
and
then
so
for
the
last
one.
D
In
terms
of,
should
we
allow
our
client
to
delete
an
immutable
system
data
node,
I
think
that's
that
should
almost
be
yes
in
the
sense
that
if
you
move
from
one
entire
configuration
to
another
entire
configuration,
any
cases
where
you
have
that
you
have
arbitrary
restrictions
on
that
makes
it
very
hard
for
clients.
Lots
of
operators
like
to
do
like
a
commit
replace
of
the
entire
configuration
and
anything
where
you
say:
oh
no,
you're
accidentally
changing
a
type
from
a
valid
type
to
another,
valid
type
for
an
interface,
for
example.
I
I
Basically,
so
we
are
already
in
in
the
dark
when
it
comes
to
rejections,
they
can
happen
anytime
for
any
reason,
but
this
this
initiative
here
to
at
least
tag
things
with
immutable,
helps
the
clients
to
at
least
have
a
chance
at
knowing
where
these
business
restrictions
sit.
F
I
I
think,
to
to
respond
ian
and
rob.
I
think
this
is
not
really
a
restriction,
because
there
does
exist.
Some
system
configuration
which
is
read
only
generated
to
be
immutable
to
clients,
yeah
that
exists
such
kind
of
system
configuration,
and
we
just
want
to
make
this
information
visible
to
the
clients.
N
N
One
is
again
3gpp
and
some
other
sdos
are
using
something
called
invariant,
which
means
that
once
you
create
it,
let's
say
a
leaf.
You
cannot
change
it
and
we
might
say
that
this
is
not
a
good
idea.
I
might
even
agree
with
it,
but
it's
the
fact
of
life
and
we
either
support
that
or
or
they
will
put
young
extension
statements
on
that
or
we
will
not
document.
It
still
will
work
that
way,
just
it's
not
documented
in
yang
anyway,
so
this
invariant
yeah
it's
there.
N
N
Where
yeah,
you
would
like
to
say
that
I
don't
know
I
support
reporting
periods,
1
5,
20
and
whatever,
and
I
want
those
to
be
visible
and
I
want
those
to
be
static.
No
new
values
created
no
new
those
values
removed.
That's
again,
something
that's
already
in
use
and
another
use
case.
I
don't
know
that
if
this
is
the
correct
tool
for
that
is
system
created
and
system,
enforced
access,
control
rules
where
we
say
that
this
thing
in
the
configuration
is
must
be
there
and
it
no
one
is
ever
allowed
to
remove
it.
D
So
rob
wilson
as
well
as
participants
again
so
just
sort
of
back
to
yang's
comments
and
bellagio's
that
I
so.
I
think
that
I
feel
that
providing
metadata
information
to
tell
clients
about
how
the
system
is
behaving
is
is
fine
and
good.
I
just
want
to
make
sure
that
by
doing
this
work
we
don't
sort
of
encourage.
D
N
F
C
P
Oh
okay,
okay:
to
get
select
control.
Okay!
Here
I
got
yeah
okay!
Thank
you.
I'm
using
I'm
presenting
this
draft
which
has
been
submitted
to
this,
because
the
technical
content
of
the
draft
is
related
to
the
tease
work,
but
we
have
a
thumb
ups
on
the
process
that
we
can
follow
to
move
this
draft
forward
and
we
would
like-
and
this
issue
can
be
more
generic
than
just
this
document.
We
would
like
to
get
the
feedbacks
from
the
netmod
working
group.
So
what
is
the
problem
we
are
trying
to
address?
P
We
need
to
do
a
tiny
and
backward
compatible
update
to
a
young
module,
in
this
case
the
itft
types
which
is
already
published
in
the
into
an
itf
rsc,
and
actually
the
change
that
we
need
to
do
in
this
specific
case
is
just
a
new
type
def
and
a
new
grouping
with
tulips.
So
it's
a
very
small
update
but
which
is
blocking
some
other
work
and
there
is
some
reluctances
from
the
people
on
moving
those
definitions
in
in
these
d
types
because
of
the
piece
of
portion.
P
We
didn't
find
any
other
approach
at
this
moment
in
time
to
update
a
young
module
after
being
published
in
rfc
than
doing
the
beast.
The
problem
of
the
piece
is
that
the
base
rsc
is
a
very
long
rfc
and
I
calculated
four
pages
in
the
pdf
version
and
it
doesn't
contain
only
one
module.
It
contains
other
modules,
another
module
which
does
not
need
to
be
updated.
P
P
The
working
group
also
started
a
few
minutes
ago
on
one
of
them
and
we
just
want
to
make
them
in
the
types
to
make
available
to
a
broader
scope
than
just
the
documents
and
the
yammers
where
they
have
been
originated
so
because
of
the
dependency
and
and
the
maturity
of
the
dependent
work.
We
need
to
have
a
fast
approach
or
a
fast
process
to
to
get
this
changes
approved
by
the
itf,
without
really
delaying
the
process
of
the
other
working
group
documents
and
the
b
is,
is
quite
an
heavy
document.
P
P
So
what
we
propose
is
to
have
this
new
document
that
is
rafter,
which
is
updating
rather
than
obsoleting
the
rsc
8776,
and
it
is
defining
a
new
revision
of
the
itft
types
only
of
the
itfd
types
such
that
the
the
documents
that
depends
on
these
definitions
can
import
this
new
version
in
this
device,
I'm
using
the
assembler
label,
just
to
simplify
the
slide,
to
understand
to
clarify
which
one
is
rough,
which
one
is
approved
and
which
one
is
an
update
of
which
and
and
then
other
drafts
can
still
point,
and
it
can
still
import
the
t
types
back,
tt
packet
types
from
the
lsc8776
if
they
see
if
they
don't
need
any
update
for
that
for
that
module.
P
P
And
what
are
the
issue
that
we
have?
The
first
issue
is
that
we
want
to
limit
the
scope
of
the
work
to
make
it
faster
only
to
the
what
we
update,
so
the
td,
tiny
and
vector
compatible
updates
that
we
need,
and
for
for
the
proposed
solution
that
we
would
like
to
follow
with
this
document
is
to
include
in
the
main
body
of
dlc
text
only
the
changes,
not
the
definitions
which
are
already
in
rsc8776.
P
However,
by
doing
all
of
the
changes
we
I
we
are
afraid
that
we
create
some
problem
with
a
young
tool
chain
like
rfc
strip
or
the
young
catalog,
which
is
extracting
the
whole
module
from
the
rsc
so
to
to
solve
this
problem.
The
proposal
is
that
we
can
include
the
whole
module
revision
into
an
appendix
these.
Appendix
is
just
providing
the
complete
revision,
and
we
can
consider
these
appendix
as
out
of
for
the
review
and
comments.
P
It
is
there
just
to
allow
the
tooling
to
work,
and
but
now
we
have
a
possibility
to
get
the
text
in
the
main
body
and
the
text
the
penis
will
go
out
of
sync.
So,
to
make
sure
that
there
is
alignment,
we
can
generate
the
text
in
the
main
body
with
an
automatic,
simple,
lift
tool.
We
propose
one
in
the
document.
If
there
are
better
tools,
we
are
willing
to
to
take
them
into
account
such
that
by
running.
P
P
The
technical
content
of
this
document
through
the
this
working
group
or
following
the
working
group,
normal
processor,
thank
you
and
in
the
in
the
backup
there
are
some
and
there's
a
drafts.
We
describe
additional
alternative
options
that
we
have
evaluated
and
why
we
think
these
approaches
will
be
better.
J
All
right
danny,
so
I
just
wanted
to
give
you
my
experience
having
gone
through
this
recently,
we
had
just
published
rfc
the
pft
yang
module
and
had
to
go
through
a
process
of
actually
correcting
the
proposed
model,
so
it
was
a
backward
incompatible
change
so
which
may
not
be
exactly
what
you're
looking
at,
but
I
think
in
terms
of
a
process.
It
was
very
similar.
J
We
then
went
ahead
and
added
an
explanation
in
the
appendix
section
describing
what
the
change
was
and,
finally,
if
there
were
any
other
modules
that
were
dependent
on
it,
those
were
also
updated
to
reflect
the
fact
that
they,
even
if
they
were
not
being
directly
impacted
they
that
the
model
that
they
were
referring
had
changed.
So
therefore
they
had
it
had
to
undergo
a
change.
Also
so
in.
I
think,
in
summary,
that
those
are
the
set
of
changes.
J
Now
I
don't
know
as
far
as
fast
or
slow
the
approach
is
still
taking
months.
We
still
haven't
finalized.
The
draft
is
still
not
approved,
and
this
is
about
three
months
old.
At
this
point,.
J
C
Yeah,
the
the
there's,
a
jeff,
put
it
into
the
chat
mahesh
before
you
go
away.
I
know
you've
already
walked
just
to
clarify
there.
Were
you
updated
the
versions
even
of
the
modules,
even
of
the
modules
that
were
not
changed.
J
D
Yeah
so
rob
walton,
so
so
my
thoughts
on
this
is,
I
think
that,
because
this
is
a
backwards
compatible
update
to
that
module,
I
don't
have
any
issues
with
this
going
into
a
separate
draft.
That's
updating
that
base
draft
and
I
have
no
issues
with
updating
just
one
of
those
modules.
I
think
that's
okay
and
I
think
the
dependencies
will
work.
D
If
you
go
back
to
your
previous
slide,
please
I
wasn't
so
sure
about
your
proposal
of
effectively
having
a
diff
in
the
main
part
of
the
draft
and
a
full
version
of
the
appendix
I
think
you'd
be
better
off
just
putting
the
latest
version
of
the
module
in
the
main
body
of
the
draft,
because
that's
what
you're
now
publishing
and
then
having
some
text
which
could
be
in
the
introduction
it
could
be
in
the
appendix
that
flags
what's
been
added
or
what
the
differences
are.
D
I
think,
in
terms
of
the
review
process,
you
just
need
to
make
sure
that
when
this
goes
to
young
doctor's
review
or
and
through
the
isg
review,
we're
saying
look,
these
are
the
only
things
that
are
changing
and
if
that's
highlighted,
I
think
most
ads
will
be
happy
just
to
do
a
diff
review
of
the
new
stuff.
They
don't.
They
won't
review
other
stuff,
that's
already
there.
D
B
J
Have
jeff
please?
Okay,
I
was
just
going
to
answer
the
question
that
lou
asked
about
did
and
did
we
have
to
update
the
other
modules?
The
answer
was
yes,
so
what
we
changed
was
the
types
module
and,
if
any
of
the
modules
imported
the
types
module,
then
we
also
bumped
the
revision
date
on
those
modules
that
were
importing
the
updated
module.
M
Sorry
go
ahead.
The
the
there
is
some
controversy
as
to
what
we
ended
up
doing.
So
what
the
language
requires
us
to
do
at
the
moment
is
just
simply
bump
the
things
that
aren't
directly
impacted.
M
We
did
so
primarily
for
bfd,
but
he
was
sort
of
pushing
to
have
this
done
across
the
board.
I
don't
think
that's
necessarily
reasonable.
What
I
would
suggest
is
most
of
this
thread
is
available
on
the
bfd
mailing
list
and
I
would
suggest
taking
a
look
at
it
because
that's
affected
the
procedure.
That's
under
debate.
C
M
G
I
might
assume
rob
good
rob
removed
himself.
C
Yeah,
I
think
italo
rob
gave
you
the
solution
that
you
want,
which
is
just
do
a
just,
take
the
the
module
that
you
want
to
modify
and
put
it
in
its
own
document
that
updates
the
space
the
base
rfc,
rather
than
do
a
this,
and
I
think
that
covers
the
narrow
case
that
you're
covering
you're
discussing
the
vfd
conversation
is
much
more
interesting
because
it's
nbc,
but.
C
C
I
do
also
want
to
echo
the
comment
that
rob
made,
that
going
forward
with
a
way
that
requires
new,
tooling,
is
probably
not
the
way
to
go,
and
you
know
creating
new
ways
of
defining
modules
with
diffs,
and
things
like
that
is,
is
just
likely
going
to
cause
a
lot
of
confusion.
C
Now.
The
narrative
part
of
your
text,
of
course,
can
highlight
the
differences,
but
the
module
part
should
be
a
normal
module
that
our
tooling
supports.
P
C
With
that,
we're
actually
a
little
over,
and
thank
you
all
for
a
good
session
and
look
forward
to
hopefully
seeing
you
in
person
in
philadelphia.
C
You,
oh
and
charles,
thank
you
for
supporting
us
in
the
room.