►
From YouTube: IETF110-NETMOD-20210312-1600
Description
NETMOD meeting session at IETF110
2021/03/12 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
C
D
I'm
sorry
I
misunderstood
so
to
the
working
group
kent
and
I
were
both
waiting
for
each
other
apologize
about
that
to
get
started.
Welcome
to
netmod
at
ietf
110.
This
is
our
our
one
and
only
session.
It's
also
the
last
session
of
the
day
of
the
of
the
week
of
the
meeting.
So
you
know,
hopefully
we
can
maintain
some
amount
of
energy
and
that
our
slow
start
is
not
an
indication
for
the
session.
D
So
apologize
for
that
and
let's
keep
moving
next,
please
oh,
I
should
introduce
my
co-chair.
So
I
have
kent
watson
is,
is
here
he's
projecting
joel
jagly
is
also
online
and
he's
helping
out
with
the
notes,
you'll
notice
in
the
chat
session,
there's
a
link
to
code
emd.
We
really
would
like
everyone
to
jump
on
and
help
us
take
capture.
What's
said
during
the
session
next,
please.
D
We
are
still
at
the
ietf
not
for
much
longer,
but
we
are
still
at
the
itf,
which
means
that
all
our
contributions,
all
our
actions,
are
governed
by
our
policies.
The
the
full
list
is
below
and
you
can
find
a
shortcut
to
it
by
going
to
the
note,
well,
if
you're
unfamiliar
with
this,
it's
really
important
to
to
be
familiar
with
it.
D
D
D
Please
put
mike
in
front
of
it
and
we
are
also
being
recorded
and
the
video
of
the
session
is
going
to
be
published
via
youtube.
We
already
talked
about
joint
minute.
Taking
five
people
have
jumped
on,
please
more
people
jump
in
it's
in
the
chat
session.
If
you
click
the
little
chat
button,
you'll
have
a
link
right.
There
it'll
be
easy
to
get
there
and
help
us
capture
the
minutes
and
also
capture
the
the
discussions
are.
Are
that
they're
accurate
there?
The
next
please?
D
D
Since
the
last
meeting
we've
had
one
rfc
published,
that's
always
great
to
see
rfcs
come
out.
Those
are
the
things.
That's
why
we're
here
right,
it's
the
published
standard.
So
thank
you
for
all
who
contributed
and
reviewed
it
and
contributed
to
this
work.
We
have
one
in
rfc
editor
queue.
I
think
this
document
may
have
been
in
process
the
longest
in
our
working
group.
I'm
not
sure
if
it
holds
the
record,
but
we're
up
at
rev,
26
we'd
love
to
see
it
done.
D
C
D
Thanks
again,
we
have
a
couple
of
other
documents
that
have
been
submitted
to
the
isg
for
publication.
I
don't
think,
there's
anything
worth
noting
there.
That's
pretty
you
know
they're.
Just
following
the
process.
I
see
rob
wilton
is
in
queue.
He
I
think
he's
preempting
me
on
the
post-last
call
where
I
was
going
to
try
to
come
on
the
spot,
and
here
he
is
jumping
in
rob.
Please
go
ahead.
A
No,
you
put
me
on
the
spot
down
in
a
moment.
I
was
just
on
the
nma
and
mda
diff
draft
I've
provided
comments
back,
I
think
andy
was
asking
whether
that
needed
any
in
terms
of
the
changes
that
would
need
any
confirmation
from
the
working
group.
So
I
would
like
to
put
that
to
the
chairs
to
decide
whether
anything
is
required
there
or
otherwise,
just
whether
the
authors
can
make
the
markups
and
then
I
can
progress
that
document.
So
I
don't
need
an
answer
now,
but
just
to
make
you
aware
in
case
you
weren't.
D
Well,
from
a
general
process
standpoint,
what
we
have
followed
is
is
that
we
ask
that
any
requested
changes
be
discussed
on
the
list
and
give
the
list
an
opportunity
to
say
no
to
chime
in
we
in
it,
unless
it
is
something
that
requires
going
back
to
the
working
group,
you
know
for
the
document
to
be
sent
back.
We
typically
do
not
ask
for
explicit
okays.
Of
course,
the
shepherd
that's
a
general
statement.
I
don't
know
if
joel
wants
to
make
a
specific
statement.
E
A
D
Just
publish
it
on
the
list
and
move
on.
You
know
it's
not
unless
there's
something
that
really
needs
an
explicit
okay,
what
we've
always
done
is
any
changes
that
come
in
during
iesg
processing.
We
just
make
sure
the
list
is
aware
so
that,
if
someone
wants
to
chime
in
they
can
that's
what
we've
always
done.
So
I'm
not
sure
why
we
do
anything.
Different
here
sounds
good.
Thank
you.
D
Okay,
so
stay
stay
around
rob
don't
go
far,
so
this
is
my
opportunity
to
put
rob
on
the
spot
so
post
last
call.
We
have
three
documents:
they've
been
sitting
there
quite
a
while.
There
was
one
minor
set
of
changes
that
were
requested
and
discussed
on
the
list,
and
I
thought
that
they
were
so
I'm
talking
about
the
first
two
documents,
interface
yang
extension
and
sub
interface
vlan.
D
A
I
they
are
progressing
very
slowly,
so
the
key
issue
at
the
moment
that
needs
to
be
solved
is
in
the
sub
interface
vlan
model
draft.
There
is
some
text
in
the
appendix
that
refers
to
the
ieee
yang
models
and
today,
so
that
text
was
inaccurate,
so
I've
been
trying
to
get
that
text
agreed
with
ieee
youngsters
like
informal
liaison
with
ieee.
I've
been
a
bit
slow
because
I've
missed
some
of
their
meetings,
and
so
it's
taking
a
longer
to
get
to
that
stage
of
working
out
what
to
do
with
that
text.
A
I
think
we
now
have
an
action
of
what
to
do
so.
It's
just
a
matter
of
updating
that
appendix
text
I
think
and
a
few
other
minor
changes
and
I
think,
hopefully,
we're
ready
to
go
so
that's
the
last
thing.
I
should
hopefully
be
able
to
clear
that
in
the
next
month
or
two
I
hope
and
then
be
able
to
progress
these
onwards.
D
Yeah,
that
would
be
great.
This
is
a
case
where,
if
we
were
in
the
room,
it
would
be
a
lot
easier,
but
scott
mansfield
is
presenting
from
with
a
youngster's
hat
on,
maybe
chat
with
him
and
the
participants
make
sure
you
guys
are
in
sync
on
whatever
needs
to
do.
That
happened
there
with
that
synchronization
between
the
itf
and
and
ieee.
D
F
B
D
We've
had
no
incoming
liaisons;
this
is
actually
a
slide.
I
think
this
is
my
fault
that
I
didn't
take
off
the
to
discuss
during
the
meeting
that
was
from
the
last
meeting,
so
my
apologies
for
that
that
last
bullet
is
is
just
a
hold
over.
So
if
you
think
we
have
an
outgoing
liaison,
please
let
us
know,
but
at
this
time
we
don't
expect
any
next.
D
Another
typo
here,
obviously
110
is
online.
111
is
still
tbd,
but
you
know,
I
think,
we're
all
used
to
working
online
at
this
point,
and
we
just
don't
know
how
long
it's
going
to
continue
the
virtual
meetings,
we
can
definitely
continue
supporting
them.
The
informal
meetings
which
are
regular
and
published
on
published
to
the
working
group.
I
think
those
are
really
good
tools,
even
once
we
go
back
in
person.
Maybe
that's
something
we
will
continue
doing
just
to
keep
the
ball
moving
in
the
working
group.
D
E
G
G
So
we're
gonna
have
three
presentations
around
this
work
today
my
overview
and
then
rashad
is
gonna.
Talk
about
the
the
module
versioning
draft
and
joe
is
going
to
be
talking
about
the
yang
semantic
versioning
draft.
Those
are
two
of
kind
of
the
most
critical
fundamental
drafts
for
this
work
continue
on
overall,
there's
kind
of
five
main
drafts
for
this
work.
G
G
G
We
shifted
our
focus
in
the
last
three
or
four
months
back
to
the
module
versioning
and
yang
summer
drafts,
so
those
are
two
of
the
kind
of
fundamental
ones.
We
had
a
number
of
major
difficult
issues
that
were
still
open
and
rashad
and
joe
will
address
those
in
order
to
try
to
progress
them.
We
held
two
netmod
virtual
interims.
G
We
had
one
in
december
and
one
in
february
we
had
pretty
decent
attendance,
18
and
12
people
so
got
a
little
bit
more
critical
mass
than
we
normally
have
in
our
weekly
calls,
and
they
were
fairly
successful
in
at
least
moving
those
issues
forward.
So
we've
made
some
decisions,
updated
the
drafts
and
and
we'll
talk
about
those
in
the
upcoming
presentations.
G
G
We
try
to
bring
all
the
key
issues
back
to
the
work
group
mailing
list
for
for
decisions
and,
let's
just
show
the
time,
time
and
date
here.
It's
tuesdays
9
a.m.
Eastern
I
already
mentioned
that
link
before
and
we're
basically
phasing
the
work,
because
there's
there's
quite
a
bit
to
talk
about
so
right
now
our
focus
is
on
wrapping
up
the
module
versioning
in
the
anxember.
G
Yeah.
The
one
kind
of
top-level
thing
we're
not
sure
about
is,
we
do
have
a
number
of
these
drafts,
and
actually
I
forgot
to
mention-
we
even
have
two
earlier
drafts.
There
was
a
requirements
draft
that
kind
of
led
to
all
this
work
and
a
solution,
overview
draft
which
presents
the
fact
that
we
have
five
different
drafts
and
how
they
fit
together.
G
Oh,
we
need
to
go
back
to
the
first
two
and
make
a
few
little
tweaks.
So
you
know
it
may
not
not
be
a
great
idea
to
totally
lock
down
the
first
two
drafts
and
bring
them
through
last
call.
So
at
the
moment
our
group
is
thinking
that
we
will
get
the
first
two
drafts
ready,
but
we
probably
won't
call
a
formal
last
call
for
those
until
we've
had
a
chance
to
progress.
The
other
three
drafts
a
bit
more,
but
we
may
you
know
we
may
kind
of
say
hey
these.
G
Are
these
are
kind
of
ready?
It's
not
official
last
call,
but
we
think
we're
done
with
these
docs
as
kind
of
a
first
level
overview
so
that
hopefully,
that
could
force
out
a
few
issues
or
concerns
ahead
of
last
call
that's
the
kind
of
way
we're
leaning,
but
I
don't
know
if
there's
other
opinions
in
the
group
on
that.
D
Go
ahead,
yeah
sure
that
it'd
be
great.
If
you
manage
the
queue
the
that
said,
this
is
lou,
I'm
gonna
jump
in
the
way
you
presented
it's
a
little
confusing
of
what
the
first
two
drafts
are.
I
read
the
first
two
drafts
is
what
you're
saying
is:
marginal
module,
versioning
and
yang
semver
verbally.
You
said
we
had
two
earlier
drafts,
so
those
could
be.
G
Right,
my
apologies.
I
did
I
realized.
I
introduced
that
confusion
in
this
presentation
and
to
be
honest,
with
most
of
our
work,
we've
been
more
or
less
ignoring
the
early
requirements,
draft
and
solutions
overdraft
overview
draft.
To
be
honest,
their
time
is
mostly
passed,
although
we
may
clean
them
up
and
issue
them
at
some
point.
So
I
I'm
referring
to
the
module
versioning
and
the
yang
sember
drafts,
and
I
I've
tried
mostly
in
my
presentation,
to
to
kind
of
say
that
and
put
it
in
brackets,
etc.
D
D
I
think
the
last
point
you
made
in
while
presenting
the
slide
is
is
sort
of
really
important,
which
is
we
don't
want
to
get
too
far
on
these
and
then
and
then
figure
out
that
we
have
to
go.
Oh
change,
something
while
we
figure
out
the
last
bits,
which
is
why
we
sort
of
taken
their
approach
of
let's
try
to
progress
them
as
as
a
set.
D
Now
that
said,
if
we
are
now
working
on
the
the
last,
the
last
little
bit
of
the
documents,
you
may
say
all
right,
we
know
we're
not
going
to
have
any
changes
and
then
it's
time,
but
you
know
I
don't
think
it
would
be
good
to
get
very
far
in
this
process
on
the
versioning
draft
and
december
draft.
Only
to
find
that
we
have
to
bring
them
back
to
the
working
group
to
fix
something.
G
C
Yes,
as
a
contributor,
or
actually
maybe
as
chair,
but
we're
having
a
similar
issue
in
the
next
conf
working
group
with
the
client
server
suite
of
drafts,
where
there's
a
a
base
level
of
drafts
and
and
then
you
know
subsequently
other
drafts
that
you
know
depend
on
them.
What
we
did
is
we,
we
moved
the
base
level.
C
G
G
H
Yeah,
hey
jason,
so
I
just
wanted
to
make
sure
I
got
a
clarification.
Was
that
from
the
design
team
perspective,
the
the
thought
was
is
that
all
five
of
the
drafts
would
enter
working
group
last
call
at
the
same
time,
because
you
mentioned
that
said
until
we
got
a
little
bit
more
work
progressing
on
the
three
drafts
I
didn't.
I
didn't
quite
understand
what,
though,
so.
G
But
it's
more
a
question
of
how
much
further
we
wait
on
the
last
three
to
bring
the
first
two
solution
drafts
to
last
call
so
yeah,
I'm
doubtful
that
I'm
doubtful
that
we'll
wait
on
all
five
for
last
call,
but
they
may
be
not
far
apart
depends
how
long
we
wait
to
progress.
The
last
three
before
we
trigger
the
first
two.
G
D
Excuse
me,
I
think
kent
makes
a
good
point.
Is
that
what's
really
important
is
that
we
progress
them
to
the
isg
as
a
set,
so
they
can
evaluate
the
total
solution
as
to
by
not
by
doing
piecemeal.
We
run
the
risk
of
the
isg
coming
back
and
saying
yeah,
but
you've
only
solved
part
of
the
problem,
so
if
it
helps
the
working
group
to
perceive
that
do
them
in
multiple
steps
and
then
hold
them
to
submit
for
publication
as
a
full
set
that
works.
D
I
I
So,
as
jason
was
mentioning,
we
had
couple
of
virtual
interim
since
last
itf,
that's
allowed
us
to
make,
I
think
more
progress
than
we
usually
do
between
two
itfs
well
in
one
itf
cycle
and
to
summarize
the
issues
which
we've
addressed
since
last
itf
and
during
the
virtual
interims
and
those
have
been
reflected
in
revision02,
so
number
one
and
all
those
things
have
been.
It's
not
just
me.
Obviously
behalf
of
the
authors.
Various
people
have
contributed
on
those
on
those
issues.
I
So
number
one
is
the
addition
of
backwards
compatibility
rules
for
config,
false
and
output
data.
I'm
going
to
talk
about
that
in
the
next
slide
in
a
bit
more
detail,
number
two
in
one
of
the
virtual
interims
or
maybe
in
both
of
them.
We
discuss
you
know
how
do
we
put
the
revision
label
in
file
names,
and
you
know
we
clarified
the
use
of
the
of
of
hash
number
three.
I
I
We
also
discussed
the
last
virtual
interim
how
what
you
know
what
characters
should
be
allowing
the
revision
label
we've
closed
on
that
the
document
has
been
updated
and,
last
but
not
least,
there's
new
text
for
hyanna
maintain
yang
modules.
Rob
did
send
an
email
to
the
working
group
on
this
and
got
feedback
from
lada.
I
believe
on
this
rob.
Is
there
anything
you
want
to
add
on
this
specific
topic
right
now
or
you
wait
until
the
end?
Okay,.
A
I
will
just
very
quickly
speak
and
just
say
that,
as
I
said
in
the
email,
the
plan
is
once
we've
got
this
iona
tech
sort
of
the
working
groups
happy
with
it
to
ask
ayanna
to
do
an
early
review
of
this.
I
was
speaking
to
michelle
yesterday,
just
explaining
it
and
I
sent
the
email
I
said
to
netmod
onto
her
she's
had
to
drop
from
this
meeting,
but
it'd
be.
A
The
aim
here
is
just
to
try
and
smooth
any
bumps
early
on
with
diana,
so
it
doesn't
happen
during
the
isg
review
and
then
have
to
come
back.
So
so,
if
anyone's
got
any
comments
on
the
other
text,
it'd
be
good
to
sort
of
share
those
early
on,
so
we
can
make
sure
that
that's
resolved
and
again
get
their
feedback.
I
Okay,
the
backwards
compatibility
rules
for
config
fall.
So
the
reason
why
we
tackle
this
is
because
7950
talks
mostly
or
only
about
configure
nodes.
So,
for
example,
you
know
if
you
shrink
the
range
of
a
leaf
node,
that's
non-backwards
compatible
for
config,
but
for
config
false,
it's
not
the
case,
so
those
rules
were
presented
by
balaj
were
written
and
presented
by
balaj.
I
believe
at
the
last
virtual
interim,
we
still
haven't
got
lots
of
feedback
on
them.
I
It
would
be
good
to
for
people
to
take
a
look
at
the
latest
rev
of
the
document
and
give
us
feedback
on
the
mailing
list.
Please.
So,
for
example,
I
mean
I
won't
go
through
this
exhaustively,
but
for
and
it
applies
to
output
data-
also
so
whatever
you're
getting
a
state
or
output
data
to
an
rpc.
Those
rules
apply
to
both.
I
You
know
if
you're,
adding
a
mandatory,
node
or
optional
schema,
node
that's
backwards,
compatible,
that's
fairly
obvious.
If
you're,
making
an
optional
node
mandatory,
that's
also
backwards
com
compatible.
We've
had
lots
of
discussions
on
number
three.
I
believe,
where
you
know
what
happens
if
you
remove
an
optional
schema,
node
or
entry
node,
we've
decided
to
make
those
and
to
make
that
and
and
and
bc,
and
you
know
similarly,
if
you're
changing
a
monitor,
number
four
you're
changing
a
mandatory
node
to
optional
that's
stacked
as
nbc
because
of
the
impact
on
the
client.
I
You
know
the
client
might
would
have
been
expecting
that
node
to
be
there
in
the
response,
whether
it's
the
in
the
operational
data
store
or
the
dc
output
of
the
our
our
pc
and
then
you
know,
there's
five
six
talk
about!
You
know!
What's:
okay
for
exp,
you
know
what's,
okay,
for
you
know
if
you're
expanding
a
range,
it's
fine
if
you're
for
config
false,
which
is
not
the
case
for
config,
true
and
anyway.
Next
slide.
Please.
I
And
this
again,
this
is
points
which
were
presented
last
virtual
interim
and
are
in
the
latest
rev
of
the
document.
It
talks
about
client
key
behavior.
You
know,
for
example,
num
number
one,
you
know.
If
you
know
a
client
is
getting
data
which
it's
not
expected,
because
you
know
maybe
the
you
know
some
attributes
have
have
been
added
or
leaf.
Nodes
have
have
been
added.
I
Similar
stuff,
for
you
know
getting
data
which
is
outside
of
the
value
space
so
again
for
con
config.
If
you
increase
the
range
that's
backwards
compatible
for
for
config
files,
the
client
might
not
be
expecting
that
by
default,
so
we're
saying
it
should
try
to
handle
those
things
as
gracefully
as
possible
and
similarly
for
the
last
item,
if
there's
you
know
max
elements
or
stuff
like
that,
and
it
typically
would
be
expecting
a
certain
number
of
elements.
I
If
it
receives
more,
please
no
assert,
so
that's
it
for
the
new
rules
for
config
files
and
output
data.
I'm
going
to
repeat:
please
take
a
look
at
them.
We
didn't
get
much
feedback
last
interim
and
on
the
alias
recently,
if
we
don't
get
feedback
on
that,
I
guess
when
we
go
to
working
group
last
call
that's
going
to
be
the
forcing
function,
but
it'd
be
good
to
have
those
feedback
before
we
get
there
next
slide.
Please.
I
Next
slide:
okay
in
safety,
white
space
changers,
the
tuesday
crowd-
feels
we've
spent
more
time
than
we
should
on
this.
So
hopefully
we're
going
to
be
closing
on
this
very
soon.
That
is
issue
number
eight
on
github,
you
know
white
back
and
forth.
We
spoke
about
that.
I
believed
yeah
during
the
december
interim
and
the
consensus.
Maybe
it's
rough
consensus,
but
it's
a
consensus
among
the
attendees.
I
If
you
look
at
the
section
11
of
79.50,
it
states
that
when
you
and
we're
talking
about
publish
changes,
you
know
if
you
publish
a
change
to
a
module,
it
requires
a
new
revision,
okay
statement.
You
know,
there's
no
going.
No,
it
can't
be
done
any
differently.
I
think
the
discussions
we're
having
on
the
list
entering
the
virtual
interim
is
for
non-published
changes.
What
if
I
take
a
module-
and
I
prettify
it
and
all
that
we're
not
addressing
any
of
that
here-
we're
saying
you
know.
I
Even
if
you
publish
a
a
new
revision
which
only
has
insignificant
white
base
white
space
changes
you
need
in
your
revision,
I
mean
we
believe
that
specific
scenario
should
be
rare.
That's
why
we
think
that
we've
been
spending
too
much
time
on
this
specific
topic
and
also
the
young
summer
draft
has
been
modified
by
joe.
It
gives
this
as
an
example
of
when
the
patch
version
is
being
changed,
and
the
next
step
for
this
specific
topic
is
to
clarify
it
in
the
module
versioning
document
next
slide.
Please.
I
Yeah,
this
is
something
we
haven't
discussed
extensively
on,
the
tuesday
call.
We,
I
don't
think
that's
been
brought
to
the
list
yet
so
the
issue
basically
is
tracking.
You
know:
what's
the
impact
of
adding
changing
or
removing
an
extension
statement,
is
it
a
rule?
It'd
be
seize
it
and
bc,
and
the
answer
is
we
don't
know
it
depends
on
the
extensions
statement
so
where
the
tuesday
call
is
leaning
right
now
is
to
say
when
an
author
is
defining
a
new
extension
statement.
C
Bitter
this
is
kent.
It
reminds
me
of
a
discussion
that
we
had
in
the
past
about
critical
extension
statements.
We
don't,
I
think,
it's
a
yang
next
issue,
but
the
ability
to
when
defining
extension,
statements
to
indicate
if
they're,
critical
or
not,
that
the
client
must
be
able
to
have
awareness
of
their
meaning.
Of
course,
that's
that's
not
again,
not
what's
here
today,
and
so
perhaps,
as
you
discuss
or
said
in
the
description
statement
handling
it,
this
way
is
the
best
we
can
do
for
now.
Thank
you.
I
A
I
A
I
I
Okay,
when
can
we
add
nbc
changes
substatement,
so
this
is
issue
83,
section
3.2
of
the
document
mentions.
This
extension
is
used
to
indicate
young
module
changes
that
contain
non-backwards
compatible
changes.
It
is
a
substatement
of
the
revision
statement.
It's
been
added
as
part
of
this
document,
and
you
know
it's
document
is
very
clear
if
somebody's
changing
a
young
module
and
issues
a
new
revision
and
knows
that
it's
an
nbc
change.
Well,
the
author
must
add
the
extension
assuming
that
you
do
that
module
supports
yang
module
versioning.
I
Should
be
allowed
if
all
changers
are
bc,
so
we've
discussed
this
a
few
times
during
the
tuesday
call,
and
there
is
no
consensus
yet
so
you
know
you
see
the
two
lines
in
bold
there.
The
first
one
says:
well,
you
know,
should
we
go
well?
Should
not
you
know
you
should
not
that
extension,
there's
no
real
reason
why
you
should
do
that,
but
using
should
gives
you
a
little
bit
of
leeway
or
the
second
line
which
says
no.
You
must
not
do
that.
I
C
I
Yeah,
but
there's
still
it's
still
not,
I
mean
I
mean
it's
much
for
the
general
public,
but
I
mean
they're
you're
right.
You
have
to
have
a
really
good
reason.
What's
a
good
reason
for
somebody
might
not
be
a
good
reason
for
I
mean
for
me.
It
just
just
gives
it
just
opens
the
door
very
slightly.
Whereas
must
not
you
know
if
you
don't
abide
you're
really.
K
I
I
On
the
other
hand,
if
you're
changing
a
regex
pattern
and
you're
not
sure
whether
you're
not
have
a
smaller
range
or
bigger
range
or
the
same
range,
but
it's
you
know
you
might
not
be
certain,
but
the
I
mean
there
should
not.
I
won't
pretend
to
be
a
lawyer
on
this.
I
mean
we
in
our
tuesday
call,
we've
been
seeing
a
subtlety
or
a
slight
difference
between
the
should
not
and
the
must
not.
If
that's
not
the
case,
we
need
to
realign
yes,
jason.
G
Yeah
jason
stern-
I
think
you
know.
One
of
one
of
the
cases,
for
example,
we
were
thinking,
was
that
there
may
be
some
changes,
for
example,
to
the
value
space
of
a
state
leaf
and
by
the
rules
we've
defined
strictly
it's
backwards
compatible,
but
we
want
to
leave
at
least
a
possibility
open
for
the
author
to
decide.
Well,
this
is
a
important
enough
change,
functional
change
that
we
we
really
want
to
flag
it
to
the
users
of
the
module.
G
G
C
I
I
mean
we
can
do
a
hum
if,
but
I
mean
whether
we
do
a
home
or
not
I'd
like
to
see
stuff
on
on
the
list,
I'm
in
the
home.
I
just
don't
know
this
is
a
new
issue,
we're
bringing
up.
I
just
don't
know
how
people
are
in
tune
with
that
issue,
but
if
you
feel
like
doing
home,
that's
good
with
me,
but
definitely
getting
feedback
on
the
list
would
be
good.
C
G
Tip,
thank
you
jason
yeah.
I
I
just
want
to
echo
that
I
think
this
issue
is
too
subtle
to
just
introduce
it
and
then
ask
for
a
hum.
I
think
it
needs
people
to
be
involved
in
a
discussion
minimum
on
the
list,
but
better
in
person
on
the
weekly
calls.
So
I
think
if
people
are
interested
in
this
or
have
an
opinion,
it
would
be
awesome.
If
we
could,
I
mean.
D
So
I
suspect
I
should
is
fine.
I
I
don't
think
I
get
all
the
subtleties,
so
I
can't
categorically
say
say
that
when
to
help
move
this
forward,
I
think
putting
into
the
document
why
you
might
not
follow
the
should
put
maybe
not
guidance,
but
some
consideration
and
I
think,
by
going
through
that
process,
it
may
help
crystallize
whether
this
is
a
should
or
a
must
or
should
not
or
must
not.
A
Thank
you
problem.
I
think
my
comments
actually
gonna
almost
mirror.
What
lou
was
saying
is.
I
think
we
need
to
have
a
bit
more
text
here
to
explain
the
reasons
why
so
I
don't
think
it's
just
that
these
centers
would
necessarily
stand
on
their
own
and
maybe
have
to
need
a
little
bit
more
background
information
here
and
hits
it's
probably
worth
getting
feedback
from
the
working
group
on
the
list.
Once
we've
got
that
paragraph
and
it's
seen
in
context,
I've
got
no
objections
to
doing
a
hum.
I
Okay
and
just
looking
at
the
pros
and
cons,
the
pro
is
what
jason
was
mentioning
earlier.
If
it's
a
case
where
you
know
you
know
it's
config
false,
but
you
want
to
attack
the
change
for
whatever
reason:
you're
worried
about
your
clients.
Might
you
know
trip
on
that
change
the
con?
Well
fairly
obvious.
You
know
if
we
start
over
using
this,
you
know
we've
used
the
term
diluting
the
meaning
of
the
nbc
change.
I
Yeah,
so
that
that's
something
which
has
come
up
very
recently,
I'm
not
sure
I've
got
the
right
issue
number,
but
the
somebody
who's
in
tune
in
december
contacted
us
and
basically
said
well
nbc
in
december
means
non-breaking
change,
which
is
the
opposite
of
non-backwards
compatible,
which
is
our
meaning,
while
demeaning
in
this
document.
So
quick
discussion
about
this,
we've
decided
to
rename
the
extension
to
non-backwards
compatible
it's
a
bit
longer
than
bc,
but
you
know
it's.
It
be
used
once
per
revision,
so
we
don't
think
it's
too
much.
A
I'm
just
going
to
add
to
that
that
I
think
I
don't
know
who
looked
at
this
jason
or
joe,
but
in
that
simba
terminology
I
don't
think
it
was
that
non-breaking
change
was
a
particularly
strong
usage.
I
think
it
might
have
been
used
once
or
twice
so
it
wasn't
as
if
this
was
prevalent
in
that
document
to
enough
to
force
us
to
change
all
of
our
terminology.
I
L
All
right,
hi,
I'm
joe
clark
I'll
be
presenting
on
behalf
of
the
authors
group
that
previously
mentioned,
meets
every
tuesday
on
yang
semantic
versioning.
So
next
slide,
please
our
current
status.
We
added
text
so
so.
This
was
also
presented
at
that
interim,
that
jason
mentioned,
and
we
added
text
to
address
version
gaps
and
by
gaps.
I'll
I'll
talk
a
little
bit
more
about
what
I
mean
there
in
the
upcoming
slide,
so
stay
tuned.
L
We
also
addressed
the
the
famous
github
issue,
number
45
by
adding
text
that
ietf
modules
must
have
a
yang
semantic
version
revision
label.
Again
I've
got
a
slide
on
this,
so
hold
your
praise
until
then,
and
we
added
some
rob
specifically
came
up
with
some
text
to
add
guidance
around
iana,
maintain
modules,
and
I've
got
a
slide
on
that
as
well.
L
L
All
right
so
version
gaps.
The
idea
here
is
that
someone
could
and
a
module
author
as
an
example
for
a
module
could
have
a
lineage
with
revision
labels
that
looks
something
like
1.01.1
1.3.
That's
fine,
they,
whatever
reason.
Maybe
1.2
was
an
internal
release.
1.2
they
just
felt
was
a
mess
and
they
never
released
it.
L
L
L
So
what
we
decided
was
that
we
would
allow
for
version
gaps
that
that
a
module
author
or
artifact
author
could
in
fact
create
something
like
1.01.1
1.3,
and
we
documented
the
risk
to
import
by
doing
so,
because,
essentially,
if
you
try
to
import
1.2
in
this
case,
it
will
fail.
There
will
not
be
a
history
entry
that
matches
1.2
just
like
if
you
tried
to
import
from
a
non-existent
revision
date
and
you
you
couldn't
resolve
that
you
couldn't
find
a
module
with
that
that
had
that
specific
revision
date,
that
import
would
fail.
L
So
we
we
clarified
that
in
the
document
and
then
we
want
to
and
rob
has
presented
some
text-
that's
currently
merged
in
github,
but
it
came
after
the
cutoff
window
to
address
this
issue
number
78
that
a
little
to
what
rashad
was
saying
about.
Would
we
add
the
nbc
change
modifier
for
a
module
revision?
We
know
didn't,
have
backwards
or
non
backwards,
compatible
changes,
so
the
same
thing
could
apply
in
simver.
Would
we
allow
for
bumping
the
semver
major
version
component
when
there
were
only
backwards
compatible
changes?
L
So
we
we
took
the
version
gap
text,
rob
massaged,
some
of
that
as
well,
and
we
merged
in
a
kind
of
a
clarifying
set
of
text
around
how
one
goes
about
increasing
or
bumping
or
changing
the
semantic
version
components
based
on
various
things
tying
that
back
into
text.
That
indicates
if
there
are
any
impact
or
things
to
be
aware
of
by
a
artifact
author,
specifically
around
or
in
one
case
around
this
version
gap.
So
so
that's
something
that
you'll
see
the
version
gap
text
you'll
see.
L
L
All
right,
I
was
kind
of
hoping
somehow
magically.
This
slide
would
get
skipped,
but
this
is
issue
number
45.,
so
we
we've
mentioned
this
issue
before
we
brought
it
up
here
in
in
various
meetings
and
talked
about
it.
We've
gotten
some
feedback
on
the
list,
but
we
went
ahead
as
a
set
of
authors
and
and
kind
of
made
an
assertion
here,
maybe
maybe
to
drive
a
forcing
function
and
issue
45
reads:
should
all
newly
published
ietf
yang
modules
include
a
yang
simva
revision
label?
L
Ultimately
we
decided
the
answer
would
be
yes,
reason
being
it
helps
the
reader.
The
human
at
a
glance
know
if
two
revisions
of
a
module
are
backwards
compatible.
So
I'm
not
going
to
read
the
text
there.
That's
the
paragraph,
the
reason
the
ed
is
in
brackets
there
I
noticed
the
typo
and
what
I
submitted
so
so
the
ed
was
left
off.
It's
it's
now
in
the
version
we
have
in
github,
but
essentially
what
we're
saying
is
that,
yes,
all
of
these
ietf
maintain
modules
the
when
a
new
revision
of
that
module
comes
out.
L
C
L
Absolutely
we
we,
as
you
know,
we've
got
dr
the
I
think
fifth
draft
in
our
set
of
solution
drafts
is
around
tooling.
It's
been
one
that
we
haven't
revisit
cert
we
haven't
visited
in
a
while,
but
but
yes,
we're
going
to
need
guidance
to
yang
doctors,
we're
going
to
need
some
of
that
data
tracker
tooling,
in
place
to
help
notice
this
and
and
kind
of
help.
Authors
arrive
at
at
the
right
value
and
certainly
flag
where,
if
this
is
ratified
flag,
where
we're
missing
required
data
italo.
K
L
I
just
added
a
revision
like
oh
0,
0
2
of
this
draft,
with
a
new
revision
of
the
yang
module
that
there
would
be
some
semantic
version:
revision
label
on
that
new
revision
of
the
anytime
you're,
putting
in
essentially
any
time
you're
putting
a
new
revision
into
your
module,
be
it
development
or
ratification
that
there
would
be
a
unique
revision
label.
That
is
a
yang
semantic
version.
L
L
I
don't
see
anyone
else
in
queue.
You'll
have
a
few
more
minutes
to
beat
up
on
me
because
I
have
this
slide.
So
this
is
guidelines
for
iana,
maintain
modules
and,
as
I
mentioned,
rob
proposed
some
text
here
that
we
batted
around
for
a
little
while
and
if
you
look
at
the
the
new
section
9.2
in
the
yang
semantic
version,
draft
you'll
see
a
lot
of
text
there.
I
didn't
want
to
paste
it
in
here,
it's
more
than
just
one
paragraph.
L
I
think
there
was
some
recent
comments
on
the
list
about
this,
but
I
don't
recall
the
I
don't
have
the
details
right
in
front
of
me.
So
if
someone
wants
to
comment,
please
do
come
to
the
mic,
but
the
highlights
of
these
changes.
Ayanna,
maintain
modules,
must
also
include
a
yang
simva
revision
label.
Now,
obviously,
we
don't
want
them
going
back
and
just
making
that
change.
So
the
idea
is
that
revision
labels
would
be
retroactively
applied
when
the
next
revision
of
a
module
is
published.
L
L
We
don't
necessarily
expect
a
lot
of
necessarily
major
version
changes
either,
given
that
for
the
most
part,
it
is
said
that
we've
heard
a
lot
of
times
said
in
the
ietf
that
things
would
maintain
backwards,
compatibility
but
obviously
semantic
version,
and
what
we
talked
about
in
our
version
solution
allows
for
that.
But
but
this
these
extra
modifiers
would
be
even
more
so
we
would
not
expect
them
to
show
up
in
these
iana
or
even
ietf
maintained
modules.
L
L
78
he's
got
some
background
on
the
sim,
verse,
spec
and
ironically,
semver
2.0.0
has
changed
over
the
years,
so
you
may
have
seen
in
the
recent
minutes,
rob
assigned
me
an
ai
to
go
back
five
years
and
see
what
that
text
looked
like.
So
I
went
into
the
way
back
machine
and
found
that
simver
2.0.0
that
page
from
two
years
ago
reads
slightly
different
than
that
page
today,
and
in
particular,
there
have
been
some
normative
changes.
Some
things
have
been
bumped
from
a
should
to
a
must.
L
Some
lowercase,
shoulds
and
musks
have
been
made
uppercase
so
that
the
the
spec
is
actually
evolving,
and
the
good
news
is
besides
some
of
those
normative
changes
that
don't
that
were
didn't
directly
affect
some
of
the
things
we
did.
It
hasn't
really
impacted
the
work
that
we've
done
thus
far
and
and
what
we've
incorporated
now,
we
joseph
left
a
ton
of
other
comments
in
that
github
and
I
have
another
ai
to
to
more
thoroughly
audit.
L
L
L
I
think
that
is
my
last
slide,
so
those
are
our
next
steps
to
kind
of
shore.
This
document
up,
but
those
are,
are
where
we've
arrived
now
in
terms
of
the
issues
and
those
should
be,
I
believe,
the
only
other
open
github
issues
around
yang
semantic
versioning.
So
with
that
I'll
open
for
any
final
questions-
and
I
appreciate
the
opportunity
to
present.
L
J
J
Yeah
document
status,
so
this
job
has
been,
has
just
been
adopted
in
the
end
of
last
year
and
until
called
was
adoption
has
been
initially.
The
second
one
ended
in
december
21
last
year,
so
many
thanks
to
the
ukraine
and
many
other
contributors
and
provide
good
use,
good
input
and
useful
comments
and
help
to
improve
this
document.
J
So
since
last
idea
meeting
changing
compared
with
the
previous
version,
actually
we
add
update
to
the
rfc8407
in
the
front
page
and
to
align
with
the
multi-tag
opc,
the
second
one.
Actually,
we
try
merging
the
self-describing
data
object,
use
cases
into
the
introduction
section
as
a
subsection
and
just
do
some
a
little
bit
restructure.
J
So
the
third
is,
we
clarify
the
relationship
between
the
data,
object
and
object,
tag,
property
tag,
metric
tag
in
the
use
cases
section
and
also
we
add
one
glossary
section
to
define
what
is
the
opm
and,
in
addition
actually
for
a
contest
information
tags
such
as
the
modules
tag,
magical
group
attacker.
We
clarify
the
appropriate
scope
next.
J
So
to
open
issue
we're
not
we
want
to
discuss
here.
The
first
issue
was
the
broader
opera
by
the
through
during
the
corporation,
actually
because
mod
as
we
know,
actually
module
tag,
offset
has
already
get
published
and
it
introduced
a
guideline
to
model
writer
for
standard
module
level
tag
definition.
J
So
this
requires
updating
to
rfc
8407
so
similar
to
the
module
tag
of
c.
This
draft
introduces
the
guideline
for
module.
Writer
for
standard
data
object
tech
definition,
so
this
also
requires
updating
your
rfc
8407.
So
so
we
make
the
changes.
So
this
has
already
been
reflected
in
the
kernel
version.
J
J
So
second
issue
is
about
the
data
data
node
tag
identification.
So
here's
the
model
structure
web
proposal
you
can
see
for
each
data
object.
They
can
have
multiple
attacks
so
for
for
data
node
tags
we
can
have
opm
tag.
We
can
have
a
context,
information
tag
for
opm
tag.
It
can
be
further
break
down
into
the
object,
tag,
property
tag
and
and
metric
tag
and
context
information
tag.
J
We
actually
define
two
type
of
tag:
one
is
margin,
source
tag
and
the
other
is
match
group
attack.
Actually,
this
is
only
applied
to
the
magical.
Related
data
object,
so
they
can
provide
a
second
level
tag,
and
so
the
issue
here
is
when
we
actually
have
multiple
date.
Note
tag
associated
with
the
one
data
object.
Is
the
object
name
sufficient
enough
to
identify
these
tags
so
based
on
our
analysis
actually
for
each
object?
J
J
So
we
also
have
being
aware
there's
a
draft
interest
in
draft
called
open.
Metric
drive
has
been
discussed
in
opswg
and
it
actually
defined
the
open
metric
for
both
poor
and
approach
based
data
connection,
and
they
propose
the
asymmetric
types.
It
has
already
open
sources
ready
to
open
telemetry,
and
we
think
this
is
ready
to
what
do
we
propose
in
this
chapter?
We
will
investigate
how
to
align
with
this
open
metric
work.
J
J
H
J
Yeah
for
our
data
node
tag.
Actually
we
call
telemetry
tag.
We
investigated
this
before
we
tried
to
provide
the
the
the
the
operation
or
management
data
classification,
so
this
is
also
we
can,
you
know,
sort
of
sort
out
sort
out
all
the
metric
metric,
related
objects
and
also
we
can
provide
five
granularity
metric
classification
and
we
in
a
current
job.
We
provide
like
a
context,
information
tag
such
as
magical
group.
J
We
can
classify
the
metric
further
into
the,
for
example,
bandwidth
or
pachelos
and
jitter,
and
so
these
here
the
mesquite
type
actually
provide
more
fine,
grained
united
narrative
for
metric
classification,
so
that
so
that's
something.
We
may
need
to
look
into
see
whether
we
can
you
know
reference,
because
we
we
actually
did
a
race.
This
issue
on
the
list,
actually,
when
we
in
the
first
convolution
and
define
some
of
like
a
unit,
but
this
is
something
it
was
suggested
to.
J
H
So
I'm
sorry,
but
I
still
didn't
quite
understand
what
you
would
propose
within
the
within
this
draft
itself.
Are
you
suggesting
that
there
will
be
new
standards
defined
tags
that
would
be
object-based
tags?
That
would
you
would
get
based
upon?
You
know,
metrics
the
information
that
came
from
the
metrics,
for
example.
H
J
Yeah
yeah,
actually
in
the
previous
page.
Actually
I
we
listed
the
context
information
tag.
This
actually
provides
a
second
level
tag
for
magical
related
data
object,
so
these
here
the
eight
metric
types
defined
in
urban
metric
drops
actually
provide.
Maybe
another
example.
We
we
may
say
this
see
as
a
second
level
metric
related
tag,
maybe
can
also
be
seen
as
a
contextual
information
related
tag.
So
this
may
be
still
the
open
issue
we
can.
J
B
C
So
as
sure
I
was
saying,
the
draft
brings
forward
what
I
consider
to
be
two
categories
of
proposal:
there's
the
gener
generic
approach
of
having
tags
per
nodes
and
then
there's
kinds
of
tags
for
nodes.
Where
I
think
metrics
is
a
kind
of
tag
I
was
just,
but
I
think
I
was
seeing
in
the
draft
that
the
metrics
were
actually
part
of
the
first
category
like
the
in
a
generic
sense
of
any.
J
Yeah
from
from
measured
attack-
actually
you
know
we
don't
know,
you
know,
define
any
new
new
metric.
Actually,
we
just
attack
magical
related
data
object.
Actually
it
belongs
to
the
first
category
for
second
category.
Actually,
we
see
these.
You
know
for,
for
example,
you
identify
and
a
bunch
of
magical
related
data
objects.
You
can
use
a
second
category
tag.
We
call
the
context
information
tag
to
to
further
break
down
the
the
magical
related
to
classify
this
magical.
Related
data
object.
A
Robert
yes,
just
I'll
just
look
at
the
draft
now
and-
and
one
of
the
questions
I
have
or
observations
I
have
relates
to-
and
this
is
a
contributor
relates
to
the
use
of
the
sort
of
standard
tags
and
updating
the
guidelines
to
model
writers.
Well,
I
have
I
have
two
sort
of
cons,
observations
or
concerns.
One
is
that
some
of
the
tags,
like
itf
object,
sort
of
feels
very
much
similar
to
what
a
list
element
is
in
yang
and
an
itf
property
seems
quite
similar
to
a
leaf
element
in
yang
anyway.
A
A
I
think
the
the
metric
one
is
potentially
a
bit
different
and
that
might
be
that
might
be
more
useful
to
to
have
to
label
the
things
you
might
to
read
in
terms
of
what
things
are
changing,
but
the
object
of
property
ones.
I
think
it'd
be
worth
looking
at
whether
that
information
can
be
inferred
from
the
yang
model
automatically
or
not.
J
Yeah
that
that's
good
question
actually
for
object.
Actually,
we
data
object.
We
actually
already
you
know
clarifying
in
the
chapter
to
see
how
these
data
objects
relate
to
the
container
leave
leave
list
and
it's
a
yeah.
This
is
just
a
server
that,
like
a
root
node,
actually
we
tagged
the
actually
all
the
data
node
can
be
tagged
with
object,
attack,
yeah,
you're
right
actually,
so
more
meaningful
is
a
magical
tag
and
property
is
a
little
bit
different
from
the
magic
attack.
J
A
Yes,
it's
just
it's
just
thinking
about.
If
we
put
these
in,
are
we
going
to
end
up
with
a
lot
of
noise
in
the
models,
and
is
it
definitely
the
case
that
every
operator
is
going
to
have
the
same
views
of
what
metrics
they
care
about
and
what
things
their
properties
so
the
stuff
where
they're
doing
it
dynamically
maybe
makes
more
sense.
I'm
just
questioning
writing
that
statically
into
the
model,
whether
that's
going
to
be
helpful,.
L
J
J
J
J
Yeah,
my
connection
is
not
stable,
actually
so
actually
for
easily.
They
can
be
realized
in
two
way.
Actually,
we
more
focus
on
the
second
way.
The
first
is
centralized
nanomanagement,
we
see
there's
another
limitation.
For
example,
they
have
slow
response
to
nano
changes.
They
have
huge
results
consumption,
so
so
we
may
need
to
consider
distribute
away
for
device
server
matching
with
dedicated
nano
control
to
the
server.
J
J
J
For
for
this
job,
so
so
we
thank
you
for,
for
all
the
contributor
and
and
the
commentator
to
to
for
for
the
comments,
especially
for
andy
actually
andy
actually
in
during
the
the
offline
disclaimer,
he
provided
a
foundation
for
this
document
actually
also
helped
us
to
provide
guidance
for
direction
of
this
document
and
in
the
second
working
adoption.
Actually,
we
have
a
bunch
of
issue
was
raised
there
and
we
have
five
issue.
J
J
J
J
So,
for
you
say,
a
policy
young
data
model
we
actually
adopt
a
similar
is
a
paradigm
or
we
call
the
imperative
paradigm,
and
so
the
event
actually
more
related
to
the
data
store,
subscription
and
event
stream
subscription
conditioning
is
very
similar,
but
for
actually
more
generic
so
base
these.
Actually,
we
think
nano
security
function
actually
is
the
example
use
case
for
easy
model
policy
draft,
so
we
actually
send
an
email
to
to
the
arduino
cell
menus
and
get
a
confirmation
from
the
author.
So
they
agree
with
this
conclusion.
J
J
So
the
internal
representation-
actually
they
in
many
different
contexts,
maybe
mean
different
scenes.
So,
for
example,
in
mit
they
define
they
give
the
intent
definition.
They
discuss
how
to
do
the
internet,
translation
or
internet
mapping,
so
that
this
internet
representation
is
not
a
scope
of
this
document
for
policy
expression
in
these
jobs.
We
think
policies
need
to
be
readable
and
expressed
at
a
high
level
abstraction
with
a
suitable
language
here.
So
we
think
young
actually
is
this
kind
of
suitable
language
can
be
expressed
by
the
mms
and
controller.
J
So
we
can
see
the
similar
example
like
a
riemann
and
smp
riemann
actually
is
extension
of
smp.
They
can
provide
a
traffic
flow
data
for
troubleshooting,
so
you
can
adjust
for
better
performance.
So,
similarly,
for
esa,
we
actually
can
provide
the
easy
policy
data
for
also
for
troubleshooting
or
cell
phone
management,
safer
monitoring,
and
we
can
manipulate
this
easy
and
for
the
better
performance
and
also
the
second
argument.
J
We
think
you
know,
unlike
a
transitional
policy
management,
we
think
this
esa
policy
expression
need
to
combine
down
to
the
primitive
representation,
not
more
close
to
the
execution
abstraction.
So
one
of
the
examples
is
primitive.
Representation
is
python
and
tcr
and
such
kind
of
scrivener
language
and
but
there's
a
pitfall
to
do
this
compilation
and
one
of
the
example
is
super.
Actually
they
compile,
they
actually
define
policy
in
in
uml
and
model.
Actually,
it's
a
very
complicated
model
user
young.
So
we're
not.
J
J
For
for
issue
three,
actually,
where
policy
execute?
Actually
we
can
reference
the
policy
based
management
framework
that
be
specified
by
the
ietv
and
dmtf.
The
two
key
component
is
pdp
and
pep,
which
is
a
policy
decision
point
and
a
policy
enforcement
point
for
the
centralized
policy
management.
Actually,
we
will
implement
pdp
in
the
management
system
will
implement
the
pep
in
the
nano
device.
So
in
these
cases
we
can
see
the
policy
is
executed
in
in
the
device.
J
When
we
delegate
some
management
function
to
the
device,
we
actually
can
have
a
local,
pdp
or
local
policy
decision
point
in
the
nano
device
and
it
can
communicate
with
pv
in
the
network
device.
So
in
in
these
cases,
we
also
can
see
actually
policy
is
executed
in
the
device
or
in
the
server
so,
but
the
the
policy
management
framework
is
not
not
in
the
scope
of
this
draft.
Actually,
we
more
focus
on
the
you
say:
policy
excluded
by
the
net
comp
or
risk
of
server.
J
J
So
the
the
fourth
issue
is
when
to
detect
or
resolve
the
policy
conflict.
So
for
the
easy
logical
we
can
see
the
the
first,
the
esa
model
policy
will
be
injected
into
the
network
device
or
server
and
and
then
we'll
extract
the
policy
variable
from
the
event,
and
we
can
map
the
policy
variable
into
the
xpath
variable,
and
then
we
can
evaluate
this.
You
see
express
expression
if
we
can
be
evaluated
successful.
We
will
execute
this
easy
action.
J
So
in
this
process
we
can
detect
policy
conflict
in
either
easy
express
expression,
evaluation
or
in
the
essay
action
execution
and,
in
addition,
actually
for
policy
conflict.
Actually,
we
can
detect
in
a
policy
design
or
definition
stage,
and
we
can
make
sure
the
the
new
policy
we
define
have
no
overlap
with
the
existing
policy,
so
this
can
help
to
resolve
the
policy
conflict.
J
J
J
J
For
example,
several
management
applications
service
assurance
application,
and
so
we
also
have
been
aware
actually
there's
a
existing
implementation
can
provide
good
basis,
such
as
event
event
management
actually
developed
by
the
cisco
ios
and
also
we
for
huawei.
Actually,
we
also
have
a
similar
feature
like
open
programmability
system
and
for
amazon.
Actually,
they
also
have
sns.
Actually
they
provide
a
similar
feature.
J
So
follow
up,
actually
we
will
address
the
remaining
columns
during
the
call,
especially
these
five
issue,
actually
for
the
first
issue,
we
already
addressed
this
security
agreement
for
other
four
issue.
I
I
think
for
for
the
second
issue,
about
abstraction
level
to
express
policy
and
intent.
Actually,
we
still,
you
know
we
received
some
feedback
from
the
uganda
and
and
some
other,
and
we
have
some
double
on
this
by
the
way
we
think
we
have.
J
We
have
we
we
can
debate,
discuss
this
and
by
the
way,
try
to
address
all
the
open
issue
and
also,
we
think,
maybe
we
can
set
up
set
up
the
github
for
this
job,
since
this
has
all
been
adopted,
that's
working
with
gender.
We
can
better
keep
track
of
this
issue
and
make
it
more
visible
to
the
to
the
list.
H
J
H
J
J
J
H
H
So
just
to
be
clear,
so
if
I
understand
it
correctly
in
this
draft,
the
a
a
policy
may
be
part
of
a
realization
of
an
intent,
but
it
isn't
meant
to
be,
but
the
the
policy
is
just
that
it's
just
the
realization
of
that
may
be
compl
associated
with
an
intent,
but
it's
not
meant
to
express
the
intent
itself.
Is
that.
A
Robert
I
was
just
going
to
ask
about.
I
was
looking
at
the
draft
and
which
I've
now
lost.
It
hasn't
mentioned
about
a
function,
call
in
the
draft
and
it
looks
like
they've
been
taken
out
and
then
put
back
in
and
look
at
the
text.
It
just
says:
there's
a
few
built-in
types
like
add
subtract,
etc,
but
I
can
see
there's
references
in
the
draft,
so
I
didn't
know
whether
more
text
is
needed
to
explain
that.
But
it
was
unclear
to
me
exactly
how
how
that
sort
of
function
call
works.
J
Yeah
yeah,
you
raised
a
very
good
question.
This
is,
you
know
we
did
discuss
with
andy
berman
about
this.
The
the
idea
is,
we
really
want
to,
you,
know,
think
compose
or
compile
the
easy
policy
into
into
the
imprimitive
representation
which
could
be
the
person
actually,
so
we
can
provide
a
standard
function,
call
or
library
so
so
for
the
function.
Call
we
we
need
to.
You
know
yeah,
you
are
right.
A
Am
I
writing
an
understanding
that
you
could
either
use
an
xpath
expression
here
or
you
can
use
things
like
this
function
called
I'm
just
wondering
whether
it
would
be
simply
the
draft
if
this
is
one
way
of
specifying
these,
but
perhaps
your
experience
is
saying
that
it's
better
to
have
multiple
choices,
and
if
so,
it
might
be
worth
having
those
under
feature
keywords.
So
not
all
implementations
that
necessarily
have
to
support
those.
J
M
J
J
B
J
J
J
L
L
So
what
this
presentation
is
is
just
the
summary
of
what
the
what
the
issue
is
and
I'm
looking
for
help
in
it's
coming
up
with
some
suggestions
on
the
path
forward,
so
we
can
write
something
down
somewhere.
I
don't
really
care
where,
as
long
as
we
can
write
it
down
so
that
we
don't
have
to
talk
about
it
anymore,
I
guess
is
the
bottom
line.
L
L
L
It's
on
the
right.
If
you
look
at
the
mac
address,
it
uses
colon
as
a
separator
it.
It
accepts
upper
and
lower
case.
The
pattern
allows
upper
and
lower,
but
it
says
lowercase
is
canonical
and
if
you
look
at
the
ieee
definition,
the
ieee
definition
and
I
provided
the
links
to
the
to
the
files
says
that
it
uses
dash
as
the
separator
and
it
allows
upper
and
lower,
but
it
says
upper
cases
to
be
used,
so
you
can
kind
of
see
the
problem
that
we
have
there.
So
why
is
this
a
problem?
L
So
the
concern
is
that
if
you've
got
both
data
types
in
your
module
or
even
if
you
have
one
use
one
of
the
data
types,
if
you
only
use
the
ieee
or
the
ietf
for
mac
addresses,
if
you
try
to
compare
two
mac
addresses,
you
have
to
make
sure
that
they're
exactly
the
same,
including
separators
and
upper
and
lower
case.
So
if
you
go
to
the
next
slide,
I
think
that's
what
this
one.
B
L
Slide
provides
some
examples
of
what
the
problems
are.
Let's
say,
skip
the
slide,
that's,
okay!
So
that's!
Okay!
This
is
just
a
list
of
some
sli
some
places
where
there
are
some
issues
that
where
a
mac
address
is
used
as
either
a
key
or
used
for
quote
matching,
so
it
matters
about
how
you
enter
in
the
value
and
how
it's
stored
and
how
you
bring
it
back.
So
if
you
go
to
the
next
slide,
this
is
why
snmp
is
different.
Well,
we
did
an
analysis
or
so
I
didn't
do
it.
L
Somebody
else
did
an
analysis
of
snmp
and
snmp
stores
the
mac
address
differently.
It
stores
it
specifically
as
an
octet
string
with
a
display
hint
display.
Hint
is
something
that
I
really
liked
in
snmp
and
I
wish
yang
had
it,
but
it
doesn't
so
the
way
that
it's
stored
is
different
than
the
way
it's
displayed.
So
there
had
there
hasn't
been
historically
an
issue
with
snmp
in
the
in
dealing
with
having
mac
addresses,
not
compare
when
you're
dealing
with
what's
on
the
wire.
L
So
if
you
go
to
the
next
line,
there's
next
slide,
please.
So
what
to
do?
I
mean
it's
these.
This
has
been
a
problem
for
years
and
so
common
wisdom
says
we
really
can't
just
go
in
and
change
the
definition
in
ieee
or
ietf
in
in
any
in
any
substantial
way.
It
would
be
an
excellent
example
to
try
to
leverage
and
exercise
the
semantic
version
and
non-backward
compatible
changes,
but
you
know
it's
getting
late
and
I'm
getting
punchy,
so
we
won't
go
there
right
now,
so
the
so.
L
What
I've
done
is
just
in
this,
like
I
say
to
put
this
in
perspective,
this
is
really
a
I'm
looking
for
suggestions,
I'm
looking
for
people
to
provide
input
on
this,
I'm
not
wedded
to
any
of
these
things,
so
I
provide
a
suggestion
on
the
next
slide,
but
then-
and
then
I
think,
there's
only
one
more
slide
after
that.
So
if
you
go
to
the
next
slide,
what
I
what
I
suggested
doing
here
is-
and
I
had
an
updated
version
of
this-
that
unfortunately
didn't
get
loaded.
L
There
is
one
other
issue
about
it
is
that
we
only
deal
with
the
six
octet,
but
there's
also
an
eight
octet
mac
address.
So
we
might
need
to
provide
a
union
here
for
the
type
def
to
provide
to
support
both
formats.
But
that's
a
that's
a
nit
anyway.
The
thing
that
I'm
suggesting
is
that
we
leave
the
ietf
and
the
ieee
definitions
alone
and
we
create
a
new
data
type.
That's
called
an
again.
L
So
in
this
pattern
there
is
no
ambiguity
of
upper
and
lower
case
and
there's
no
ambiguity
with
separators,
because
I
took
them
out
and
and
then
we
could
make
some
words
or
some
something
about
how
if
you
want
to
enter
a
mac
address,
you
can
use
this
as
the
way
to
enter
it,
and
then
you
can
do
whatever
you
want,
and
then
you
won't
have
any
issues
with
string
comparisons
or
with
keys
or
whatever.
So
this
was
just
one
suggestion,
because
I
like
playing
around
with
yang,
so
I
type
something
up.
L
L
L
Would
this
be
something
that
people
would
be
interested
in
to
provide
a
display
hint
like
capability
and
yang,
or
even
even
provide
something
that
would
allow
us
to
have
a
string
equivalence
pattern
so
that
associated
with
a
string?
You
not
only
have
the
pattern,
but
you
also
would
have
a
separate
thing
that
would
allow
the
back
end
code
to
say.
L
Well,
this
is
the
pattern,
and
this
is
what
I
have
to
match,
but
if
this
is
another
string
that
allows
me
to
say
if
I
see
things
that
are
within
this
range,
they're
they're
going
to
match
something
like
that
other
and
I'm
open
for
any
other
thoughts
that
you
have.
I
mean
this
is
something
that
we
talk
a
lot
about
in
in
the
ieee
where
the
ieee's
been
using
yang.
Now,
since
about
2017.,
we
have
a
group
that
meets
weekly
that
talks
about
guidelines
and
things.
L
So
we
get
really
good
support
from
the
yang
doctors
and
from
rob
and
and
others
that
that
help
us
learn
how
to
use
this.
So
we're
just
looking
for
ways
to
effectively
use
yang
properly
and
and
make
sure
that
our
the
ieee
modules
work
and
play
well
with
the
modules
that
come
from
the
ietf,
so
I'll
leave
it
there
and
thank
you
for
your
time
and
attention
and
look
forward
to
emails
or
we
can
mailing
list
or
or
if
anyone
has
any
thoughts
about
this
now.
Thank
you.
N
N
L
Okay,
great
yeah,
that's
I'm
looking
for
something
like
that,
because
there
there
are
many
things
that
yang
does
very
well
and
that
there
are
a
couple
of
things
that
snmp
smi
had
from
a
language
perspective
that
I
feel
are
missing.
That
and
and
that's
one
of
the
reasons
I'm
asking
right,
because
if
somebody
said
oh
well,
yeah
in
yang,
you
do
this
and
you
get
that
exact
same
functionality.
B
A
Yes,
I
just
wanted
to
add
that
this
is
an
issue,
that's
being
tracked
as
as
scotty.
As
you
already
know,
this
is
the
working
group.
This
is
an
issue.
That's
been
tracked
in
the
ieee
itf
liaison
meetings
to
try
and
find
a
resolution
to
this.
So
I
would
welcome
input
and
thoughts
from
the
working
group.
I'm
not
sure,
there's
any
easy
answers
here
and
sort
of
downsides
to
various
choices,
so
coming
up
with
a
good
technical
solution
would
be
good
at
a
minimum.
A
I
think
it
would
be
useful,
at
least
in
the
description
statements
of
the
types
to
potentially
flag
this
up
as
a
warning
to
say
to
sort
of
try
and
do
normalization
internally.
But,
as
jan
said,
if
this
is
turning
up
in
other
places,
that
may
be
enough
justification
to
try
and
look
for
a
wider
technical
solution.
That
sort
of
solves
this
problem
more
generally
or
at
least
investigate.
If
there
is
something
on
that
path
that
is
feasible.
L
Yes,
rob
I
I
did
I
kind
of
flew
through
the
slides.
There
was
in
one
of
the
previous
slides.
It
did
talk
about
that.
This
is
something
that
happens
in
other
places
like
when
you're
dealing
with
ouis
as
as
strings
and
things
so
there
are.
There
are
other
examples.
This
just
happens
to
be
the
one
that
was
top
of
mind.
D
H
I
ask
a
question
because
you
know
I
was
kind
of
it
was
interesting.
I
I'd
not
seen
that
you
know
this
was
an
issue
before,
because
you
know
in
all
honesty
everything
that
I've
seen
is
that
the
pattern
uses
the
you
know
the
colon
right.
I
have
not
seen
the
the
the
the
dash
as
a
pattern,
that's
in
wide
use
in
any
of
the
yang
modules
right,
whether
config
or
you
know
the
bbf
or
you
know
wherever
right.
So
I
was
kind
of
shocked.
So
my
question
is:
is
that
you
know?
H
L
L
L
L
Yes,
but
that
doesn't
solve
the
problem
with
matching
strings
right.
The
the
problem
is,
if
I
have
a
device
that
is
that
I'm
getting
a
mac
address
from
and
then
I
have
an
operator
that
has
a
mac
address
unless
those
mac
addresses
are
identical,
they're
not
going
to
match
right
and
that's
that's.
The
the
basis
of
the
problem
is
because
mac
addresses
are
strings
and
yang,
and
if
you
use
them
as
keys,
they
have
to
match
exactly.
That's
that's
kind
of.
L
L
Yeah,
I
would
create
an
ieee
thing,
a
new
data
type
or
I
could
do
it
in
the
ietf
too.
I
mean
it
doesn't
matter,
but
but
what
I
was
thinking
is
since
the
ieee
owns
802,
that
they
would
create
a
normalized
data
type
that
got
rid
of
the
problem
of
string
matching,
and
then
we
could
show
the
I
trip
the
ietf
and
if
they
want
to
use
it
great,
if
they
don't,
then
we
haven't
stopped
the
ietf
from
doing
what
the
idf
does
right.
So
so
there's
actually.
D
A
couple
of
options
in
there,
the
first
one
is
you
go
off
and
do
what
you've
said
for
the
ieee
sounds
like
a
great
idea
to
me.
Why
are
you
asking
the
ietf?
I
mean
that
would
be
my
first
reaction
and
then
right.
Why
you're
asking
is
because
part
b
is
you
want
to
do
either
a
joint
definition
or
you
want
to
ask
the
ietf
that
we
start
using
this
normalized?
D
L
D
That's
one
of
the
concerns
right
yeah
so
which
of
those
you
know
what
are
you?
What
are
you
after
from
us?
I
mean
to
me
yeah,
I
actually
buy
it
fully
buy
into
that.
This
is
a
real
issue.
You
know,
if
you
have,
if
you
have
linkages
between
the
i2,
ieee
and
ietf
models,
this
happens
right,
so
I
guess
yeah
I
buy.
I
completely
buy
it's
a
real
issue.
D
L
Well,
you
said
it
you,
you
said
exactly
the
issue.
The
issue
is,
is
that
if
we
get
into
a
situation
where
the
yang
is,
you
know
wildly
successful,
we're
10
years
down
the
road
and
there's,
you
know
thousands
of
ietf
yang
models
and
thousands
of
ieee
gang
models
and
you
need
to
use
them
at
the
same
time,
the
suggestion
would
be
if
you're,
using
ieee
and
ietf
yang
models
together
and
you
need
to
use
a
mac
address.
L
D
L
Like
otherwise-
and
I'm
also-
I
mean
you
guys-
are
the
yang
experts
right.
So
if
there's
something
that
I
missed,
I
was
I'm
looking
for
that.
If
there
is
a
better
way
to
do
this,
that
that
makes
compatible
changes
easier,
you
know
backward
compatible
changes
here.
The
great
let
me
know
you
know,
that's
that's
the
thing
so
italo.
K
Thank
you,
scott.
Yes,
I
was
wondering
for
background
compatibility,
whether
it's
more
better
to
do
an
alignment
in
the
pattern
and
some
description
that
allows
at
least
the
back
end
to
do
comparison,
because,
but
without
impacting
the
existing,
the
syntax
of
the
model.
That
looks
to
me
most
conservative
approach
to
solve
the
problem
and
that
doesn't
preclude
doing
a
normalized
for
the
future.
But
at
least
we
will
not
impact
the
existing
models.
Well,.
L
That
would
be
no.
That
would
that's
dash
the
second
dash
under
other
thoughts,
right
that
I
I
do
like
that
and
jan
is
saying:
oh,
he
might
be
willing
to
work
on
something,
so
we
could
that's
the
other
reason
to
talk
to
the
ietf.
You
guys
own
yang
right,
so
there's
something
we
can
do
to
make
yang
work
where
we
can
both
have
our
own
patterns
and
everything
works
great
then
that
would
certainly
be
a
better
solution
than
having
to
change
the
data
type
that
people
are
using
right,
so
rob.
A
I
told
you
two
comments.
One
was
actually.
I
had
asked
scott
to
come
and
present
here
just
yeah,
thank
you,
but
that
was
one
thing
to
work
that
the
workers
should
know
and
the
reason
I
asked
him
to
present
here
is.
I
don't
think
this
could
be
solved
in
ie
alone.
I
think
that
actually,
the
discussion
with
lou
that
was
sort
of
figured
out-
and
the
other
point
I
want
to
make-
is
the
comment
that
everyone
is
using
the
colon
and
the
rest
of
the
world,
and
this
is
ie's
problem.
M
M
L
Okay,
that
that's
a
good,
that's
good
input,
so
if
you
can
provide
that
you
provided
that,
but
if
you
could
put
that
in
an
email
or
send
it,
that
would
be
great.
But
your
other,
your
other
point
about
the
about
the
ietf
defined
using
the
colon
long
before.
Well,
that's
true
from
a
yang
perspective.
But
if
you
read
802
802
predates
the
yang
and
802
said:
use
a
dash.
So
that's
not
an
argument.
I
can
take
back
to
the
ieee
and
get
and
get
people
to
buy
into
so
kent.
C
Two
comments,
first
regarding
normalized
formatted
and
almost
think
that
the
normalized
format
is
binary
that
you
were
talking
about.
You
know
mac
or
even
ip
addresses
and
whatnot
they're
on
on
the
wire
or
you
know,
the
stringified
format
is
just
what's
used
on
the
wire
when,
when
communicating
like,
for
instance,
in
xml
or
in
json,
but
in
cbor,
it
would
be
the
binary
type
or
whatever.
So
I
think
when
you're
talking
about
and
then
from
a
convenience
perspective
when
in
ui
you
know.
C
Typically,
the
data
entry
follows
the
format
of
that
type.
As
it's
defined
natively,
you
know
inet
types
or
or
whatever
so
from
a
user,
a
interface
perspective,
there's
a
convenience
factor,
but
but
it's
perfectly
possible
and-
and
you
know
you
might
consider
necessary
or
one
one
might
think
that
you
know,
there's
a
middle
layer,
a
glue
layer
that
you
know
converts
between
what
is
actually
encoded
in
json
or
xml
or
sebor
to
a
binary.
That's
in
you
know,
application
metal,
middleware
type
memory
and
then
to
the
user.
C
C
My
second
comment
is
that
we
are
and
that
mod
working
group
is
in
the
process
of
revving
the
yang
types
draft,
which
defines
inet
types
where
this
is
coming
from,
and
so
you
know
it's
probably
not
possible
to
hoot
this
moment,
but
it
seems
to
me
like
if
we
had
the
semantic
versioning
stuff
that
was
presented
earlier
already,
that
you
know.
Potentially,
we
could
consider
a
you
know,
marking
something
as
obsolete
or
non-backwards
compatible
and
moving
towards
a
common
format.
L
A
Just
to
make
one
last
comment
was
that,
even
if
we
managed
to
convince
the
whole
world
to
move
to
the
existing
itf
definition
that
might
still
leave
us
open
with
the
problem
of
the
fact
that
you're
allowed
to
specify
either
using
uppercase
or
lowercase.
That's
that's
a
problem
right.
The
definition
does
say
the
canonical
format
is
lowercase
and
hence
that's
what
you
would
would
generate
it
to,
but
it
does
require
tooling
to
actually
do
that
conversion
and
make
sure
that
when
it's
comparing
these
things,
it
does
that
conversion.
A
L
Yeah,
that's
right
and
it's
opposite
of
what
the
spec
that
it's
supposed
to
be
implementing
says:
that's
not
what
802
says
anyway
the
well
that
was
it.
I
know
I
went
over
a
little
bit.
I
apologize
for
that,
so
I
look
forward
to
more
discussion
on
this
and
we'll
talk
about
it
on
our
weekly
ieee
yang
meetings,
I'll
work
with
rob
to
find
out
how
we
want
to
gather
comments
from
from
the
ietf
and
make
sure
everybody's
kept
up
speed
on
how
this
is
moving
forward.