►
From YouTube: IETF115-NETMOD-20221108-0930
Description
NETMOD meeting session at IETF115
2022/11/08 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
B
Kent,
oh
I'm,
gonna
be
I'm.
Sorry
I
was
thinking
you
were
presenting.
It
is
time
to
start
the
session.
I
am
Lou
Burger
Kent
Watson
is
my
co-chair.
He
is
remote
and
so
you'll
see
a
little
bit
more
exposed
to
how
we
work
things
because
we're
not
sitting
next
to
each
other
you'll
notice
that
we
have
some
changes
in
our
working
group,
structure
or
management.
The
first
is
Joel
jegley
is
has
been,
has
moved
on
as
chair.
B
B
So
this
is
our
note:
well
we're
the
second
day
of
the
ietf,
maybe
you're
familiar
with
it.
Hopefully
you
are,
if
you're
not
take
a
look
at
the
link
on
the
bottom
or
go
to
the
ietf
page
and
look
at
make
sure
you're
familiar
with
this.
It
governs
how
we
operate
and
contribute
at
the
ietf,
and
basically
everything
you
say
here
or
on
the
list
becomes
per
part
of
our
permanent
record
and
is
a
formal
contribution
to
the
group.
B
Next,
we
also
would
like
to
remind
everyone
that
we
have
a
code
of
conduct
that
governs
how
we
interact
with
each
other
and
basically
be
respectful,
be
professional,
it's
okay,
to
have
a
good
technical
discussion,
but
remember
that
you
know
to
work
in
an
appropriate
way
with
your
peers
and
there's
a
BCP
on
that.
Of
course.
Next.
B
For
those
that
are
in
person,
we
ask
you
two
things
and
they're
both
highlighted
on
the
slides
on
the
on
the
left.
The
screen
on
the
left.
First,
please
scan
in
that
covers
blue
sheet.
It
also
allows
you
to
participate
in
any
polling
that
we
do
and
we
will
be
doing
that
we're
not
doing
hums
or
hands,
because
we
want
to
be
fair
to
those
who
are
online
and
so
we'll
be
using
the
the
tool.
B
We
will
be
using
the
meat
Echo
for
Q
control,
both
remote
and
local,
that's
to
be
Equitable
to
those
who
are
to
remote.
We
also
ask
that
you
join
us
for
joint
minute.
Taking
the
link
is
in
the
the
meet
Echo
chat.
It's
also
on
the
every
one
of
our
materials
pages
really
helps
to
make
sure
that
your
comments
are
appropriately
captured.
So,
if
you
make
a
comment,
please
go
take
a
look
at
the
the
notes
and
make
sure
we've
got
what
you
meant
down
next.
B
B
So
where
do
we
stand
on
documents?
I'm
not
sure
I
want
to
read
through
all
of
these
we
have
I'll
highlight
the
post
last
call
ones.
The
first
one
is
actually
on
the
agenda,
which
is
great
to
see
it's
been
stuck
for
a
little
while,
so
that's
awesome.
We
need
to
still
work
out
on
how
to
get
the
second
one
unstuck
and
I.
Don't
know
if
you
want
to
say
anything,
Rob
or
or
not.
Don't
if
you
think
it's
good.
B
A
A
So
I'm
to
blame
for
these
and
I'd
like
to
thank
both
Scott
and
Don
Fussell
to
helping
out
pick
up
and
they'll
edit,
but
I
think
the
planner
said
in
both
of
these
documents
and
the
plan
is
to
try
and
do
the
first
one
first
and
then
once
that
one's
out
of
the
way
we're
lost.
Well,
then,
the
second
one
won't
go
through
so
I
think
there
is
a
plan,
it's
just
sort
of
getting
that
together.
So
it's
still
a
strong
desire
to
get
these
done.
B
Okay,
great,
that's
awesome.
The
next
document
we're
going
to
talk
about
a
little
bit
more
I
believe
on
the
next
slide.
If
I
remember
the
slides
right
and
the
other
two
we've
been
we're
actually
gonna
are
on
the
agenda
also,
so
we're
not
gonna
have
to
go
with
that,
and
so
on.
The
syslog
model
there's
been
an
update
and
the
question
to
the
authors
or
what's
left.
E
Hi
Joe
Clark
Cisco
good
to
see
you
there
Jason
and
thanks
Joel,
the
what's
left,
so
we
think
just
open
up
a
new
last
call
where
we
know
there's
some
pending
things
to
do,
but
we're
they're
minor
and
we're
just
holding
off
to
get
some
last
call
comments,
so
I
think
I
thought
Kent.
You
were
going
to
open
this
up.
I
I,
don't
think
there's
anything
pending
on
a
Mahesh
or
my
side,
but
that's
where
we
stand
right
now.
D
E
We
were
talking
about
bringing
in
more
of
the
the
kind
of
the
the
overall
TCP
structure
or
or
like
bringing
in
things
like
proxy.
The
the
authors
spoke,
the
consensus
seem
to
be
that
that
might
be
Overkill
for
what
we
want
to
do
with
syslog.
There
didn't
seem
to
be
a
need
for
that,
but
that's
something
I
think
for
to
bring
up
in
in
the
last
call.
What
does
what
does
the
working
group
think
as
it
stands
right
now?
We
weren't
going
to
make
that
change.
F
Can't
hear
you
very
well
either.
Can
you
hear
me
okay,
yeah
for
No
Tag?
Actually,
we
already
have
walking
group
law
school
I
think
we
adjust
all
the
comments
from
from
from
the
issue
raised
by
the
yugun.
Actually,
we
also
think
is
nothing
left.
We
want
to
move
forward,
but
for
the
change
we
proposed.
Actually,
maybe
we
need
to
Solitude
see
this.
Some
feedback
from
you
can
again
haven't
got
a
feedback
yet
yeah,
but
the
form
our
side
icing
is
ready
to
move
forward.
B
B
Basically,
there
were
a
few
points
open.
We
think
this
slide
captures
what's
left
and
we
have
a
proposal
on
how
to
move
forward
and
not
if
we
don't
hear
objections,
our
intent
is
to
move
forward.
So
now
is
your
opportunity
to
object
if
you
have
an
issue
with
what's
on
the
slides,
the
first
is
is
on
the
with
regard
to
the
address
no
Zone
discussion,
we're
going
to
add
I'm,
not
sure.
B
B
D
B
B
D
B
So
we
had
an
incoming
liaison
from
Oran.
We
actually
talked
about
it
a
little
bit
at
the
last
meeting
and
then
we
never
completed
the
action
on
it,
and
so
there
was
a
a
proposal
sent
to
the
list.
I
think
Jason.
Can
you
send
it
or
you
commented
on
it,
but
we're
going
to
continue
to
work
to
to
get
this
out
to
get
a
response
out
and
if
you'd
like
to
contribute
to
it
feel
free
to
send
a
message
to
the
list
or
to
the
chairs
Alias.
B
G
B
B
Webex
is
open,
open,
informal
meetings
just
want
everyone
to
be
aware
that
those
continue
to
go
on
and
if
you
would
like
to
participate,
you're
always
welcome,
and
if
you
have
a
topic
that
you
would
like
to
start
a
new
discussion
on.
That's
all
the
the
working
group.
Resources
are
available
to
you.
Just
contact
the
the
chairs
Alias
and
one
of
us
will
will
help
you
out
and
with
that
I
think
I've
hit
the
last
slide.
Next,
yes,
and
so
we're
going
to
move
on
to
Scott
Mansfield.
D
D
H
Oh
okay:
well,
that's
what
thanks
very
much
I
assume
that
you
can
hear
me
because
I'm
mumbling,
so
thank
you
very
much
for
providing
me
with
a
few
minutes
of
agenda
time
for
this
topic.
Hopefully
it
will
be
very
quick.
The
this
is
about
both
of
the
drafts,
the
interface
extensions
Yang
and
the
sub
interface
VLAN
yang,
so
I
click.
This
button
I
go
to
the
next
slide.
H
Look
at
that,
so
both
of
these
drafts
expired
in
January
of
2021
and
I,
provided
the
links
to
the
data
tracker
on
the
previous
page
was
the
links
to
the
GitHub.
These
are
the
links
to
the
expired
drafts
and
then
so
last
ietf
there
was
a
desire
to
progress
these,
so
Rob
talked
to
Don
and
I
about
taking
this
up.
So
what
we've
done
so
far
is
we've
progressed
the
work
on
the
common
interface
extension
Yang.
H
That
would
be
fabulous,
and
so
the
next
thing
is
they're
in
the
common
interface
extension
draft.
We're
trying
to
use
get
the
way
it
was
meant
to
be
used.
So
we
have
issues
written
down.
There
are
six
open
issues,
I've
put
them
all
here
and
provided
notes
on
on
the
ones
that
we've
accepted
the
ones
we
haven't
accepted.
I
have
created
a
new
draft,
but
it's
in
my
local,
my
local
clone
and
once
I
have
access.
H
H
There's
a
couple
of
things
here
that
there's
like
we
need
some
more
description
on
something
so
looking
for
the
experts
to
provide
a
little
more
input
on
that
next
slide
is
on
the
sub
interface
VLAN.
We
have
I
think
there's
also
six
issues
on
this
one.
We
haven't
progressed
any
work
on
that
I
want
to
finish.
The
work
like
Rob
said
finish
the
work
on
the
one
and
then
contact
the
authors
and
get
permission.
So
that's
the
same
thing
for
that
draft
as
well.
So
our
plan
is
to
progress.
H
J
Yeah,
so,
to
give
a
very
brief
recap,
the
use
cases
we
are
focusing
on
this
work
is
about
their
two
kinds
of
use
cases,
the
first
one
that
there
are
some
conflict.
True
data
nodes
which
are
immutable
and
I
said
in
immutable.
I
mean
that
is
not
not
allowed
to
be
created,
deleted
or
updated
and
is
independent
of
how
it
is.
J
How
is
instantiated-
and
the
Second
Use
case-
is
that
when
some
data
nodes
they
exist
in
multiple
instances
in
the
data
tree,
for
example,
is
a
list
or
leave
list
that
is
not,
while
some
of
their
instances
are
read
only
While,
others
are
not.
So
our
objective
is
reading
about
the
documentation
availability,
so
we'd
like
to
define
a
standard
magnetum
to
allow
the
server
over
to
document
their
existing
immutable
configuration
data
so
provide
more
readability
about
their
immutable
ability
characteristic.
J
But
we
need
to
emphasize
that
this
work
is
doesn't
mean
that
we
are
encouraging
such
adding
the
immutable
flag
behavior
for
thorough
implementation.
So
next
slide,
please
yeah
before
we
are
trying
to
get
into
the
solution
and
I
like
to
mention
that
there
is
a
definition
about
the
immutable
here
and
I
said
immutable.
We
mean
that
there
is
a
schema,
or
instance,
node
property
indicating
that
the
configuration
data
is
not
allowed
to
be
created,
deleted
or
updated.
I
know
that
it
might
be
a
little
different
from
our
understanding
of
this
immutable
world.
J
So
the
question
for
the
working
group
is
that:
can
we
do
better
about
this
terminology?
So
the
solution
we
have?
We
have
defined
a
immutable,
Young's
tension
and
immune
for
Magneton
notation
and
for
the
young
extension.
There
is
an
argument
statement
named
exceptions
which
is
defined
to
indicate
that
specific
operations
are
permitted
and
the
operations
I
mean
create,
update
and
delete.
J
For
example,
if
a
configuration
data
it
can
only
created
a
be
creative
and
deleted
and
and
modification
is
not
allowed,
so
you
can
say
that
immutable
and
create
and
delete
it
and
for
the
immutablement
data.
Annotation
currently
will
Define
this
annotation
as
a
type
of
Boolean
and
is
indicate
that
once
a
particular
instance
data
node
is
created.
Then
the
client
cannot
update
or
delete
it,
and
we
have
restricted
that
this.
This
annotation
is
only
applied
to
the
leave
a
list
or
leave
list
entries,
or
instance
inside
a
particular
entries.
J
J
J
So
there
is
nowhere
to
actually
delete
the
configuration
in
system.
So
that's
okay
for
a
clients
to
delete
that
in
running,
and
we
also
clarify
that
right.
Access
restriction
due
to
the
general
young
rules
has
no
need
to
be
marked
as
immutable.
For
example,
okay
live
in
a
list.
You
cannot
modify
it
or
dedicate
if
the
instance
by
the
instance
is
created,
but
there's
no
need
to
remark
as
immutable
and
also
clarify
that
how
the
immute
both
lag
interacts
with
the
neck
magnetome,
if
a
specified
data
node,
for
instance,
is
marked
as
immutable.
J
J
Yeah
and
another
app,
that
is,
that
we
have
add
a
new
section
to
discuss
the
inheritance
of
immutability,
so
the
draft
teacher
said
that
only
unless
otherwise
specified
through
the
immutability
in
the
hierarchy
just
is
inherited
downwards
towards
the
leaf
or
the
list
of
terminal
notes.
But
you
need
to
mention
that
if
a
node
has
a
child
element,
then
the
non-modification
to
that
node
just
means
that
is
any
child
elements
is
not
allowed
to
be
created,
update
or
deleted.
J
However,
there
might
be
a
desire
to
override
the
immutability
of
a
particular
descendant
node,
so
we
do
allow
it
to
be
overrated.
If
this
container
node
would
have
a
different
immutability
with
its
access
to
node.
So,
for
example,
it's
a
list
definition
and
with
immutable
youngstation,
which
means
that
this
list
instance
is
not
allowed
to
be
created,
updated
or
deleted
by
the
client.
But
there
is
only
if
an
important
number
it
has
a
immutable
with
the
exceptions
for
create
updated
deleted.
J
G
J
Yeah,
currently,
we
are
thinking
that
these
inheritance
are
only
applied
to
the
the
youngstation
mode
defined
in
the
young
module
and
because
it
might
be
a
too
strict
way
if
we
just
if
we
just
defined
as
a
metadata,
annotation
and
there's
no
way
to
override
this
limitability
of
this
descendant
node.
So
just
well
right
now
we
are
only
considered
applied
to
the
youngstation
about
this
inheritance.
Sorry.
G
I
wasn't
I
wasn't
talking
about
the
the
override
it
was
more
if,
if
an
object
in
the
schema,
if
at
the
list
entry
it's
immutable
and
you
read
the
data,
are
you
going
to
see
The
annotation
against
every
leaf
in
the
list
or
just
when
you
read
the
data?
Are
you
going
to
see
The
annotation
against
every
item
in
the
list,
every
leaf
in
the
list
or
just
against
the
list?
Entry
at
the
top
and.
C
J
L
L
Right
yeah
go
ahead,
so
I
mean
it's
always
nice
to
see
that
we
are
documenting
the
behavior
of
service
and
all
that
so
that's
I
mean
the
basic
stance
here.
This
is
not
ideal,
but
we
want
to
describe
to
the
world
how
things
work.
Let's
let's
go
to,
but
I'm
I
have
concerned
that
this
is
getting
closer
to
the
SNMP
world,
where
there
are
lots
of
special
rules
and
tricks
and
stuff
you
have
to
I
mean
you
can't
write
an
SNMP
client
that
can
manage
a
device
automatically.
L
L
So
okay,
immutable
eyes,
I
think
that's
fine,
but
when
you
say
that
something
can
might
be
possible
to
create
but
not
delete
or
delete,
but
not
create
I,
don't
believe
you.
There
is
no
such
thing
that
can,
if
you
create
it,
it
can
never
be
deleted.
It's
just
that
you
have
to
jump
some
through
some
other
Hoops.
L
So
if
we
are
to
have
annotations
like
this
in
the
model
to
say
that
oh
this
one
cannot
be
deleted,
we
have
to
tell
the
controller
so
how
what
do
I
need
to
do
in
order
to
actually
delete
it
and
should
I
go
to
the
top
level
list
or
should
I
go
to
factory
reset?
What
is
it
I
need
to
do,
because
if
we
are
leaving
this
as
a
sort
of
English
description
somewhere,
I,
don't
think
we
are
talking
about
netconf
anymore
than
we
are
talking
about
as
an
MP
or
nothing
else.
L
L
L
J
M
Systems
to
work
in
a
model
driven
way
instead
of
doing
separate
scripts
and
separate
Hoops
for
every
special
bit
of
data.
The
other
thing
is
also
as
a
participant
in
3gp
psa5,
which
has
I,
don't
know
some
hundred
or
well
around
100
yank
models.
Now
this
is
existing
behavior
for
the
last
I,
don't
know
20
years.
Their
question
is
about
this.
Can
we
document
this
in
a
standard
way
or
do
we
have
to
do
it
in
a
3gpp
way?
So
there
are
very
strong
use
cases
for
this.
B
While
Rob
is
coming
up,
I'm
going
to
start
a
poll
on
adoption
and
we
actually
have
three
states
here,
you
can
raise
your
hands,
you
can
answer
and
lower
your
hands
or
you
cannot
answer
and
so
we've
asked.
So
if
you
raise
your
hand,
you
think
it
means
it's
time
to
adopt.
You
do
not
raise
your
hand,
it
means
you,
don't
if
you
don't
participate,
you
don't
have
an
opinion.
A
So
I
don't
know
how
how
you
really
balance
those
two
things
to
say
this
is
like
this
is
maybe
documentation,
but
perhaps
it's
a
matter
of
saying
in
the
draft
that
this
is
not
a
recommended
way
of
managing
the
configuration.
It's
like
we
don't.
We
don't
recommend
this,
but
if
you
are
doing
this,
this
is
the
way
you
document
it.
I
I,
don't
know,
I'm
conflicted
on
this
one.
N
All
right,
I
was
probably
the
only
one
who
said
not
to
adopt,
but
I
think
this
is
just
a
special
case
of
a
deviation
really
and
it's
about
the
implementation,
so
it's
appropriate
to
use
a
deviation.
I,
don't
see
where
a
standard
module
or
any
kind
of
published
module
would
have
this
this
extension
in
it
to
to
predict
it.
This
way.
N
M
Okay,
I,
don't
think.com
is
the
good
place
for
this
big.
First
of
all
not
come
can
be
switched
off.
This
is
more
a
property
of
the
data
model.
What
you
can
and
cannot
do
with
this
Anakin
is
about
allowing
things
in
some
cases
not
allowing
it
in
other
cases,
but
also
nakum
can
be
switched
off
so
I.
No,
you
say
that
you
can't
imagine
published
models.
M
B
So
I
I'll
definitely
have
to
speak
with
Kent
offline.
We
usually
like
whisper
things
up
here,
but
we
can't
it's
a
little
difficult.
My
read
and
again
I
haven't
consulted
with
Kent
on
this.
Is
that
it's
pretty
split?
You
know
you
have
people
that
are
interested,
but
not
a
lot,
a
lot
more
than
think
that
this
isn't
ready.
B
Based
on
the
comments,
perhaps
you
could
put
more
in
the
draft
about
what
is
not
possible,
what
you
can
do
with
existing
mechanisms
and
why
you
think
a
new
mechanism
is
needed
and
that
might
help
those
who
have
said
no
to
understand
why
you
think
we
have
to
do
an
exception
or
addition.
Sorry,
thank
you.
B
B
F
Good
morning,
everyone,
my
name
is
so
I-
want
to
introduce
this
idea.
The
policy
based
Nano
access
control,
so
this
is
Ops
a
WT,
zero,
zero,
routine
chapter.
The
reason
we
come
here
because
the
basically
the
Pacer
model
is
developed
in
another
mode,
a
working
group,
or
we
also
have
ACL
extension
proposed
by
Oscar
admander.
So
we
want
to
you
know,
sort
of
feedback
for
this
one
yeah
next
foreign.
F
So
what
is
the
problem
statement
actually
usually
in
the
Enterprise
or
campus
Network
scenarios?
We
actually
use
Access
Control
list
to
you
know,
provide
network
access
control,
especially
for
the
fixed
device
user
and
at
the
sometimes,
these
kind
of
Acer
actually
has
some
limitation.
It
is
usually
it's
a
IP
address,
based
network
access,
control
or
Mac
address,
based
access
control.
So
for
Summer
mobile
device
users
they
may
move
from
one
location
to
another
location,
so
so
use
Acer
actually
has
its
limitation.
In
some
other
scenario.
Actually
we
really
want
to
install
more.
F
You
know
flexible
security
policy.
Actually
one
example:
we
have
the
attribute
based
access
control,
so
we
really
want
to
you
know,
apply
the
access
control
policy
to
a
set
of
the
user
under
the
different
circumstance
you
could
be
based
on
user
location
or
user
row,
or
it
could
be
based
on
the
time
of
day
or
type
of
the
network
device
to
be
used.
Next.
F
So
we
really
want
to
solve
this
limitation
of
the
network
access
control.
So
what
do
we
propose
actually
to
provide?
You
know
a
more
fine
granularity,
Access
Control
policy
based
on
the
user
group
identity.
So
here
we
give
a
some
example.
You
may
need
to
restrict
some
of
user
or
a
group
of
user.
In
a
specific,
you
know,
department
for
the
financial
department
to
to
restrict
access
to
the
service
or
resource
for
a
specific
time
period.
F
So
you
can,
you
know
you
need
to
design
the
access
control
policy
to
you
know
to
meet
these
requirements,
so
the
user
approval
here
could
be
the
you
know,
a
set
of
grouper
user
from
financial
department
or
from
IMD
Department.
Actually
they
will
represent
a
connective
identity
of
the
proofer
user,
so
this
user
can,
you
know,
can
have
commonly
you.
Can
access
the
network
or
consume
specific
network
service
or
resource
next.
F
So
here
is
our
model
design
overview.
Actually
you
can
see.
Actually
we
really
extend
a0
based
model
and
to
introduce
additional
attribute.
You
know
you
can
see
the
Red
Dot
rectangle
diagram
and
you
we
can
support
actually
Four
type
of
access
control.
For
example,
we
can
provide
a
user
group
to
use
a
group
access
or
we
can
provide
access
from
One
Source
app
here
to
as
a
prefix
to
the
destination
RP
prefix
address.
F
We
also
can
support.
You
know:
User
Group
to
RP
prefix
access
or
the
other
way
around
RP
prefix
to
the
YouTube
group
access.
So
we
give
the
example
of
the
user
group
based
ACL
example.
You
can
see
you
know
we
allow.
You
know
different
set
of
grouper
user,
for
example
from
cell
group,
or
they
can.
You
know,
communicate
with
the
Financial
Group
within
in
the
destination
youth
group
and
in
addition,
we
actually
can
restrict
a
set
of
users
at
the
four
specific
time
period.
So
we
introduce
time
range
type.
F
E
Question
I
you
submitted
this
to
opsog
and
I.
I
was
looking
at
it
then,
and,
and
the
biggest
question
I
have
is
what
is
a
user
group?
So
so
you
have
a
string
user
group
name
and
it
was
just
I
was
just
scratching
my
head.
How
does
this
resolve
like
like
what
what
do
I
do
with
this
I
mean
conceptually
I
get
it
Cisco
was
not
allowed
to
talk
to
wallet.
Let's
say
he's
an
example
of
user
groups,
but
how
does
that
actually
resolve
to
something
that
the
network
understands
yeah.
C
F
F
E
But
but
shouldn't
there
be
more
structure
around
the
the
user
group
like
like
keying
and
and
like
it's
a
string
which
feels
to
me
kind
of
arbitrary
shouldn't.
There
be
some
more
referential
mapping
to
to
really
understand
that
this
user
group
means
something
and
maybe
I
just
need
to
see
more
more
implementation
on.
But
but
that
was
a
little
of
my
confusion.
It
just
seemed
kind
of
arbitrary
and
and
it
it
was
tough
to
really
wrap
my
head
around.
How
I
would
actually
implement
this
yeah.
F
I
think
one
of
the
requirements
from
the
Acer
extension
job
they
really
wanted
for
Acer
are
not
tied
to
a
specific
interface
over
the
device,
so
they
won't
even
apply
to
settle
the
device.
So
these
are
you
know,
it's
tension
really
targeted
to
solve
this.
So
I
also
have
a
next
slide
to
explain
how
this
how
it
works.
Oh,
okay,
okay,
yeah,
move
to
the
neck,
so
this
is
actually
provided.
You
know
how
we
you
know
resolve
these.
F
Actually
we,
this
kind
of
HCL
is,
it
seems
you
know
not
a
diff,
it's
kind
of
different
from
the
a0
based
model.
Actually
you
introduce
these
kind
of
group
IDs.
So
so
we
really
want
to.
You
know,
establish
the
mapping
between
the
group,
ID
and
RP
address,
so
how
we
can
do
this
actually
for
user,
it
can
be
the
fixed
device.
The
user
can
be
mobile
device
user.
So
during
the
network
access,
actually,
you
need
to.
You
know,
involve
some
Triple
A
maximum
to
provide
network
access
authorization
after
authorization.
F
You
can
establish
the
mapping
between
the
group
ID
and
the
IP
address.
So
with
this
mapping
you
can
really
can
control
the
provided,
restrict
access
to
the
mobile
user
or
maybe
BYOD
device
user.
So
so
you
so
here
we
just
show
you
example
for
this:
the
the
the
mapping
table.
What
a
mapping
table
looks
like
you
can
see.
We
have
the
group
ID
or
we
have
RP
address,
and
then
we
also
had
some
other
attributes,
so
these
are
really
targeted
to
the
actual
build-based
access
control.
F
So
so
you
can
provide
more
fine
granularity
and
Nano
upside
control
for
for
the
user,
so
we
actually
have
two
use
cases
so
the
the
the
in
the
left.
Actually
we
assume,
actually
you
know,
policy
enforcement
Point
actually
will
co-locate
with
Chevrolet
device
in
the
network
node.
Actually,
so
you
can
easily
to
establish
this
kind
of
mapping
when
you
pass
through
this
kind
of
network
access
authorization,
but
for
second
Noah
you
may
separate
a
policy
enforcement
point
from
the
you
know:
geography,
client,
the
Chevrolet
client-
can
be
in
the
network
node.
F
So
you,
the
Chevrolet
client,
can
establish
that
can
imagine
they
can
you
know
you
know.
Export
is
kind
of
map
into
the
controller
or
controller.
Can
retrieve
this
kind
of
mapping
from
Triple
A
server
from
some
kind
of
you
know
repository
so
the
policy
enforcement
component?
Can,
you
know,
grab
the
the
mapping
from
the
controller,
so
you
can,
you
know
easily
to
pass
or
interpret
this
kind
of
network
access
policy.
So
this
is
a
basic
idea.
We
show
high
level
for
more
detail.
E
E
F
That
level
yeah
that's
good
question
actually
usually
in
the
Enterprise
and
then
oh
campus,
nanoid
scenario
you
may
have
policy
server.
You
may
actually
already
have
do
some
planning.
Actually
to
you
know
you,
you
have
financial
department,
you
have
ID
department
and
these
need
to
you
know,
set
a
specific
rules
so
these
so
they
can
actually
establish
this
kind
of
policy
in
and
install
in
the
policy
server
or
can
be
co-located
with
the
Chevrolet
server.
F
So
some
other
scenario
actually
maybe
for
the
BYOD
user,
this
kind
of
device-
you
know
unload
to
the
network
actually,
but
you
can
have
this
kind
of
pre-configure
the
the
access
control
rules.
So
you
can,
you
know,
restrict
the
access
to
this
unknown
device.
This
is
maybe
attack
you
know.
So
this
is
ideally
we
have.
B
O
O
You
might
want
to
look
at
the
work
that
the
calendaring
working
group
has
done
on
repeating
rules,
the
recurrence
rules
that
are
called
and
they
can
express
all
sorts
of
things
like
the
first
Tuesday
of
every
month,
Etc,
and
once
you
give
something
like
this,
people
are
going
to
want
something
like
that.
So
look
into
what
the
I
calendar
work
has
done
on
recurrence
rules,
okay,.
B
That's
it
okay,
so
last
slide
yeah.
So
we
note
that
this
is
listed
as
an
Ops
area
working
group
document.
So
thank
you
for
letting
us
know
about
it
and
we'll
look
for
the
work
to
proceed
there.
Unless
the
working
group
chairs,
like
Joe,
who
may
or
may
not
be
listening,
decide
that
they
need,
they
want
to
send
it
back
here,
but
until
it's
sent
back
here,
you
know
the
general
rule.
Is
you
come
to
that
mod?
Only
when
there's
nothing,
no
other
working
group
can
work
on
the
end.
Okay,.
B
P
So,
just
first
of
there's
a
little
bit
of
context
reminder
so
we
presented
a
few
itfs
ago
a
some
some
extensions
to
the
model.
So
just
to
recap,
the
hfc
8519
defines
the
access
control
list
and
model,
so
there
you
can
configure,
which
is
the
forwarding
behavior
of
the
device
and
they
find
entries
matches
and
actions.
Okay.
P
So
in
some
three
ideas
ago
we
presented
which
were
their
problems
that
we
detected,
so
it
was
based
on
operational
experiences
of
protein
ACLS
in
in
production
that
was
was
used
in
in
our
Network
and
there
we
wanted
to
see
what
was
the
the
best
approach.
If,
if
we
have
a
new
version
of
the
HL
model
or
do
augmentations
on
existing
models,
okay
and
try
to
remain
the
other
one
and
touch
so.
P
Yeah,
so
we
picked
a
choice
to
move
forward,
so
we
can.
The
feedback
was
okay,
do
some
jump
code
and
and
present
it
and
see,
see
how
we're
going
and
we
started
working
with
augmentation,
so
don't
touch
existing
RFC
and
they
are
work
on
that.
So
here
these
were
all
the
all.
The
problems
were
when
analyzed-
and
here
we
are
going
to
go
one
by
one
of
those
that
are
covered
by
by
the
current
proportion.
P
Okay,
so
we
didn't
cover
100
of
them
in
the
in
this,
let's
go
to
the
next
slide
and
then
we
can
start
so.
First
of
all,
there
was
one
problem
that
we
detected
in
terms
of
manageability
of
the
of
the
access
control
list
matches
at
a
we
required,
in
many
cases,
a
much
against
some
set
of
prefixes
of
set
of
ports.
Okay,
so
in
current
model
you
could
not
add
those
those
lists.
Okay,
so
the
idea
is
to
maintain
these.
These
sets
is
the
same
thing
that
you
have
in
the
in
the
routing.
P
Okay,
so
in
the
routing
policies
you
already
have
a
list
of
prefix
ranges,
and
here
in
the
years
to
that,
in
this
model
we
also
have
prefix
sets.
Protocol
sets
for
number
sets,
icmp
sets
and
well.
These
are
the
sets
that
we
came
came
upon,
but
you
could
have
more
so
the
so
we
proposed
to
have
at
the
top
level
of
the
ACL,
have
a
placeholder
and
Define
set
to
their
list
all
the
or
create
and
manage
all
these
sets.
So
then,
these
sets
can
be
reused
across
a
multiple,
multiple
ACLS
also
and
multiple
entries.
P
So
the
the
good
thing
there
is
that
they
can
be
managed
separately.
So
for
us,
in
our
case,
in
telefonica,
we
have
our
security
department
that
just
updates
these
the
specifics
list,
for
example,
and
they
updated
periodically
or
or
daily-
and
it's
so
here
this
is
documentation
proposed
okay,
so
next
next
slide
so
here
in
we
can.
We
can
show
the
how
the
full
tree
would
look
like.
So
we
have
the
based
on
the
feedback
that
we
had
separated,
ipv4
and
ipv
and
IPv6
prefixes.
P
So
we
are
just
playing
lists
ports,
protocols
on
the
icmp
base
field;
okay,
so
with
with
all
of
the
forces,
are
reusable
for
both
the
TCP
and
USB
all
and
any
protocol
that
would
use
new
sports
and
we
could
also
consider
other
ports.
For
example,
we
could
also
consider
matching
a
mpls
labels,
for
example.
That
is
a
also
one.
There
are
some
at
least
some
Hardware
that
is
able
to
do
the
machine
against
mpls
label,
so
you
could
also
create
those
those
sets
Okay.
So
next
slide.
Please.
G
P
G
C
Q
P
Okay,
so
a
couple
of
slides,
more
yeah,
so
then
another
of
the
problems
that
we
had
is
the
the
handling
of
TCP
flux.
Right
now
you
could
Define
just
one
bit
and
match
against
that
bit.
So
the
proposal
here
is
to
add
the
capability
to
define
a
bit
mask
and
an
operation
over
that
business
and
that
bitmask,
then
you
are
way
more
flexible
and
you
can
support
all
the
bdp
flow
spec
matching
operations.
Okay,
it
is.
It
is
good
to
be
consistent
across
IDF
Technologies.
P
So
here
is
the
example
of
how
it
would
look
like
so
next
slide.
Please
another
thing
is
we
needed
a
better
way
to
to
handle
fragments?
Okay,
so
this
is
why,
with
the
we
Define,
the
a
fragment
container
for
both
ipv4
and
an
IPv6
and
to
be
able
to
match,
for
example
it
just
if
there
is,
if
there
is
a
fragment
or
if
it's
the
first
fragment
it
is
the
last
fragment.
So,
for
example,
you
could
create
a
rule
to
discard
all
incoming
fragments
okay,
so
that
is
also
a
common
common
operation.
P
A
another
thing
is
that
in
current
ACLS
oracles
you
had
the
accept
dropped
and
reject
the
actions.
Okay,
so
you
accept
it
or
you
when
you
drop
it,
you
notify
or
not
be
honest
images,
but
we
saw
that
it
is
also
common
that
in
some
cases
when
you
detect,
you
don't
want
to
fully
drop.
So
you,
you
might
want
extra
policy
so,
for
example,
a
a
red
limiting
policy.
P
So
we
propose
that
it
is
interesting
to
add
also
that
you
can,
in
addition
to
accepting
the
have
a
an
action
in
the
forwarding
Behavior
to
have
another
forwarding
behavior,
that
is
limiting
the
regulation.
So,
for
example,
in
this
case
you
you
could
limit
the
rate
of
20
20,
okay,
so
next
slide,
and
then
we
can
have
some
time
for
for
discussion.
P
It's
a
little
bit,
sometimes
challenging
when
creating
those
augmentations,
and
sometimes
we
are
finding
some
limitations.
Okay
and
sometimes
what?
If
you
go
to
this
approach,
we
could
be
more
clean
and
even
maybe
some
some
things
could
be
fit
together
in
the
same
structure
instead
of
having
to
replicate
the
structures
and
the
second
question,
I
think
that
was
related.
Also
to
your
your
comments
that
that
we
had
is
where
to
position.
The
defined
sets
Okay,
so
they
Define
sets.
The
thing
is,
then
they
are
references
in
the
matches.
P
Should
it
happen,
I,
don't
know
if
it
happens
in
in
many
places,
but
if
someone
Imports
it
and
it
is
referencing
to
the
Apple
okay,
so
we
it
could
be
a
standalone
in
a
new
model,
so
in
any
model
just
have
a
separate
module
for
the
for
the
prefix
sets
or
for
the
sets,
and
you
just
reference
and
finally,
question
is
okay.
This
is
the
right
place
to
work
on
it.
The
net
mode
is
oops,
we
didn't
know
which
was
the
best
place,
but
as
ACL
model
was
done
here,
we
thought
it
was
here
so.
B
So
I'm
going
to
start
with
the
easy
one
which
working
group
you
know.
As
you
said,
this
is
built
on
top
of
ACL,
so
it
seems
like
the
right
place
to
do
it.
Kent
isn't
here.
You
know
for
me
to
whisper
again.
So
if
he
disagrees
he
was
the
shepherd
on
that
document.
So,
of
course,
if
he
disagrees,
I
actually
will
refer
to
him.
B
B
O
Q
Q
If
we
could
go
back,
I
think
it's
the
slide
before
this.
Yes
great
limit
actions.
I
would
suggest
that
this
is
not
the
right
Yang
model
for
rate
limit
action.
I
would
suggest
that
you
look
at
the
qos
Yang
model,
because
the
moment
you
put
any
kind
of
a
rate
limit,
you
also
need
to
have
some
metering
capability
in
the
same
module.
It
generally
is
not
the
case.
So
if
you're
looking
for
Q
I
have
some
kind
of
metering
look
at
the
model.
Q
C
E
Collect
Cisco
real
quick
on
the
last
question,
so
I
I
would
say
it
would
be
nice
to
have
this
in
a
standalone
container,
because
I
can
see
thinking
of
some
implementations
that
might
use
this
there's
other
things.
I
could
see
these
groupings
being
used
for
and
besides
just
ACLS,
so
I
think
it
would
make
it
easier
to
import
into
that
other
work.
B
Okay,
so
this
has
been
talked
about
a
couple
of
times
now.
The
last
time
was
a
little
bit
ago
wasn't
the
last
meeting,
but
we
thought
it
would
be
good
to
ask
the
same
question.
We
asked
for
the
previous
one
so
same
sort
of
guidelines
and
you
know
for
some.
They
may
not
be
aware
of
the
document,
so
this
might
by
a
hard
ask-
and
you
know
we
just
like
the
previous
one-
it
doesn't
mean
no
doesn't
mean
never.
Q
B
Okay,
I'm
gonna
close
that
session
I'll.
Note
that
a
few
people,
you
know
a
a
small
percentage
of
the
people
in
the
room
participated,
but
everyone
who
participated
was
supportive
of
adopting
so
I
think
this
one.
That's
a
pretty
good
indication
that
there's
you're
headed
in
the
right
direction.
People
are
interested
in
this,
but
it's
still
new
to
them.
So
I'll
talk
with
Kent
afterwards
and
we
may
see
a
poll
we
may
want
to
wait.
Another
meeting
it'll
be
based
on
offline
discussion.
Thank
you.
G
Okay,
so
there's
actually
three
parts
to
this
presentation,
so
first
I'll
just
be
doing
a
bit
of
an
overview,
because
there's
a
set
of
five
drafts,
we're
working
on
related
to
Yang
versioning
work,
then
I'm
going
to
present
on
kind
of
the
base.
Fundamental
draft,
which
is
module,
versioning
and
Joe,
is
going
to
present
on
the
Yang
sember
draft
for
anyone
who
just
wants
to
ramp
up
again
on
what
this
work
is
fundamentally
about.
G
You
can
always
flip
to
the
last
four
slides
of
this
presentation,
I'm
presenting
now
that
gives
you
a
very
quick
overview
of
what
the
work
is
about
with
a
few
nice
pictures
and
things
I'm
not
going
to
go
over
those.
Today,
though,
okay
next
slide,
please
so
we're
working
on
kind
of
a
broad
set
of
proposals
to
deal
with
some
Evolution
and
yang
versioning.
G
There's
five
separate
drafts
I'm
not
going
to
walk
through
all
of
these
at
the
moment,
but
a
big
Focus
has
been
on
number
one
and
number
two
here
to
try
to
get
those
standardized
now
as
quickly
as
we
can.
We've
been
seeing
increased
demand
to
wrap
that
work
up,
but
we
do
plan
on
bringing
all
of
this
work
to
RFC
in
a
phase
manner.
G
G
So
a
fair
bit
of
this
work
is
happening
on
a
weekly
call.
Tuesday
Mornings
everybody's
welcome
to
join
those
at
any
time
and
don't
feel
bad
if
you're
not
fully
ramped
up
or
not
in
the
middle
of
discussions
with
some
people
who
just
come
and
go
occasionally
it's
great
to
get
other
opinions
on
this
work,
so
please
feel
free
to
join
it's
important.
We
get
a
big
cross-section
of
people
and
we're
always
really
trying
to
especially
get
more
users
and
operators
in
these
meetings.
It's
pretty
heavily
vendor
focused.
G
G
Okay,
so
what
have
we
done
since
last?
Itf
time
is
kind
of
high
and
we're
never
quite
getting
as
much
done
as
we
kind
of
originally
hoped,
but
so
a
really
big
Focus
was
something
that
was
brought
up
on
the
list
as
part
of
the
last
working
group,
Last
Call
on
this
Dock,
and
that
was
looking
at
kind
of
an
alternative
to
our
top
level
version
and
non-backwards
compatible
markings,
and
that
was
looking
at
per
node
markings.
I,
don't
know
what
happened
to
our
lights
here.
G
C
C
G
We
d:
we
discussed
this
in
a
lot
of
detail
it
pretty
much.
It
was
really
the
focus
of
all
our
time
since
the
last
meeting,
so
we
have
gone
and
defined
these
per
node
annotations.
You
can
Mark
individual
nodes
as
okay.
This
one
was
non-backwards
compatible
in
this
release
Etc,
but
we
have
decided
not
to
include
it
as
part
of
the
base
draft.
So
there's
more
details
on
that
coming
up
in
the
next
presentation,
but
it's
not
going
to
be
part
of
the
base
draft
or
at
least
that's
our
proposal.
G
G
We
kind
of
debated
them
all
down
to
an
answer
amongst
the
weekly
call
group
and
authors
and
we've
replied
back
to
a
list
about
pretty
much
every
one
of
those.
So
we
feel
that
that
is
pretty
much
done.
We've
made
some
updates
to
the
drafts
and
we're
going
to
there's
still
a
few
updates
left
to
go,
but
we
think
we've
closed
most
of
the
process
from
the
first
working
group
last
call.
G
G
Then
the
plan
is
to
submit
those
two
drafts
to
a
on
second
and
what
we're
thinking
is.
Hopefully
final
working
group
last
call
and
the
intention
is
to
try
to
move
those
forward
to
RFC.
So
we're
not
going
to
wait
for
the
last
three
drafts
we're
going
to
try
to
drive
forward
to
completion
on
these
two,
the
work's
been
taking
a
long
time
to
converge.
I
apologize,
but
trust
me
there's
a
lot
of
hours.
I've
gone
into
this.
G
It's
not
because
we're
sitting
around
and
not
getting
to
it,
Oram
specifically
asked
to
have
these
two
completed
and
we've
heard
the
same
message,
informally
from
a
lot
of
other
people
who
are
interested
in
this
work
and
then
we'll
phase
work
on
the
remaining
documents.
After
that,
the
schema
comparison
packages
and
version
selection
and
there's
still
a
lot
of
work
to
be
done
on
those
as
well.
Okay,
next
slide.
C
G
G
G
As
part
of
the
work
where
we
created
the
per
node
backwards
compatible
tags,
we
rename
the
top
level
one
just
to
make
it
really
clear
that
it's
different.
So
it's
that
new
top
level
tag
is
now
called
non-backwards.
Compatible
revision
just
be
really
explicit.
That
applies
to
the
entire
revision
of
the
module.
G
We
removed
the
bullet
in
section
311,
which
is
the
list
where
we
take.
We
took
79.50
and
all
the
rules
in
79.50
about
what
is
compatible
and
what's
non-compatible,
and
we've
made
a
very
small
number
of
updates
to
that.
One
of
the
updates
was
that
we
were
originally
going
to
allow
reordering
of
Yang's
statements
outside
of
input
and
output
sections,
but
we
decided
against
that
in
the
end.
G
There's
a
number
of
places
we
had
to
make.
We
made
decisions
like
this,
where
there's
things
we
could
kind
of
optimize
and
change,
but
overall,
in
the
end,
we've
tried
to
kind
of
minimize
them
and
just
stick
with
most
of
79.50
other
than
try
to
fix
the
really
the
big
problems.
There's
lots
of
other
little
optimizations.
We
could
make
to
things
that
maybe
are
kind
of
backwards
compatible.
G
We
also
decided
that
changes
to
import
statements
are
going
to
be
classified
as
backwards
compatible.
So
if
you
change,
for
example,
in
an
import
which
version
you're
importing
the
idea
is
we're
not
going
to
kind
of
carry
through
changes
that
that
might
mean
into
the
current
module
we're
just
going
to
call
that
backwards
compatible.
So
if
different
modules
import
each
other,
a
server
and
client
can
know
about
changes
by
looking
at
each
individual
module
and
saying
has
that
module
changed
as
the
flag?
The
indicator
that
something
in
the
data
model
has
changed.
G
We
clarified
some
things
around
the
file
name
format,
so,
as
many
of
you
know,
there's
a
current,
a
current
format,
kind
of
recommended
in
the
guidelines
that
has
the
the
at
symbol
and
a
date.
But
what
we're
saying
is
that,
if
you're
using
labeling
we're
recommending
that
instead,
you
start
using
a
hash
and
the
label
okay,
if
the
label
is
available
and
then
we
also
clarified
some
text
on
what
it
means
to
reduce
the
value
set
of
a
leaf.
G
G
If
you
wish
you
can
Mark
what
what
this
work
says
is
you
can
Mark
individual
nodes
saying?
Well,
it
was
actually
this
node
that
changed
and
you
can
keep
a
whole
history
if
you
would
like
in
the
right
in
the
details
of
the
API,
there's
pros
and
cons
of
that,
but
it
is
an
optional
marker.
It's
particularly
useful
when
a
tool
or
even
a
user
might
assume
that
A
Change
Is
would
be
classified
in
a
different
way
than
you
might
expect.
G
G
So
if
you
had
a
range
100
whoops,
my
implementation
only
accepts
1
to
50..
The
server
never
would
have
accepted
the
value
75,
so
you
fix
the
module.
Officially,
that's
a
non-backage
compatible
change,
but
you
could
mark
it
here
that
specific
one,
no,
that
was
backwards
compatible.
So
there's
a
few
use
cases
for
this,
but
in
the
end
it
is
still
there's
a
number
of
reasons.
We
don't
want
to
include
it
in
the
base
draft.
G
So
one
one
thing
is
at
the
module
level,
the
top
level.
We
need
that,
no
matter
what
it's
kind
of
the
fundamental
marker
just
to
indicate
an
NBC
change
has
occurred.
That's
the
one
that
has
broad
interest,
we're
already
seeing
it
actually
used
in
the
industry
with
open,
config
I
think
some
vendors
are
actually
already
kind
of
using
proprietary
versions
of
it.
So
we
know
that
one
is
simple,
well
understood
and
there's
already
has
interest
in
adoption.
G
G
So
we
really
felt
that
is,
is
an
optional
extension
to
this
work,
not
part
of
the
base
work,
it
also
the
per
node
markers.
We
definitely
found
fit
better
with
the
schema
comparison,
discussions
and
the
tooling
topic.
So
we
think
there's
a
good
fit
there
with
the
schema
comparison
draft,
and
we
also
felt
that,
at
least
within
the
weekly
call
group,
we
kind
of
like
the
idea
that
the
body,
the
module
is
really
just
the
API.
It's
not
a
whole
bunch.
G
It's
not
littered
with
a
whole
bunch
of
history
about
how
the
API
has
changed
over
time.
It's
just
here's
my
version,
three
of
the
module,
the
body
of
it,
describes
the
API
and
it
sometimes
maybe
it's
better
to
leave
all
the
history
annotation
to
the
top
separate.
So
those
are
some
of
the
reasons
we
decided
that
we
don't
want
to
include
it
as
part
of
the
of
the
base,
module
version
and
graph.
G
G
G
We're
looking
at,
maybe
making
it
less
strict
as
a
hint
instead
of
a
absolute
strict
rule
and
I
do
have
a
slide
on
that
moment.
There's
about
a
half
dozen
more
minor
updates
required
based
on
the
working
group.
Previous
working
group
last
call.
We
have
the
captured
in
GitHub
issues
and
we're
just
trying
to
make
fix
the
text
for
those.
C
G
I
already
talked
about
the
third
bullet,
the
the
per
no
compatibility
extensions
next
slide,
Okay,
so
softening
of
revision
or
drive.
So
we
as
part
of
the
module
versioning
work.
We
are
trying
to
improve
how
imports
are
described,
so
a
Yang
module
can
can
import
another
Yang
module
in
7950.
You
can
do
that
by
saying.
I
want
to
import
a
very
specific
version,
but
there's
definitely
been
consensus
in
the
working
group
that
that
importing
by
specific
reversion
aversion
doesn't
really
work.
G
G
So
we've
introduced
this
concept,
which
is
it's
not
perfect
either,
but
it's.
What
we
believe
is
the
best
way
forward
to
solve
the
kind
of
worst
of
the
problems,
and
that
is
to
allow
Yang
module
to
say,
hey,
I
want
to
import
at
least
this
version.
Okay,
and
it
could
be
this
version
or
anything
after
it
because
I
know
at
least
I.
Have
the
new
definitions
of
this
grouping
or
I
have
a
6991
bits?
G
I
need
this
new,
whatever
one
of
the
new
things
that
we're
putting
in
the
6591
is-
and
you
can
say,
I
want
that
version
onwards,
where
we're
struggling
a
little
bit
and
still
a
bit
of
an
open
issue,
is
how
strict
we
want
to
be
about
that
so
today,
today,
the
language
in
the
draft
is
somewhat
strict.
It
says
You
must
import
a
version
that
is
at
least
this
version
or
is
a
descendant
of
it.
G
We're
looking
at
maybe
softening
that
and
it's
a
little
bit
to
do
with
trying
to
be
more
compatible
with
current
tools
and
the
way
current
tool.
Current
tools
will
work
which
allows
more
flexibility
in
what
version
is
used.
So
if
you
don't
specify
a
specific
version,
a
tool
or
a
client
is
allowed
to
kind
of
it's
a
bit
inconsistent
in
the
standards.
Right
now
some
places
say
you
have
to
grab
the
latest
some
say
it's
kind
of
undefined.
G
So
what
we
want
to
do
is
a
la
allow
that
to
maintain,
allow
that
behavior
to
be
maintained.
So
it's
more
we're
looking
up
to
be
a
suggestion,
saying
hey!
If
this
version
or
derived
version
is
around
we'd
recommend
you
pick
it
up,
but
if
you
don't
have
that
version
available
to
you,
you're
allowed
to
make
a
decision
like
the
current
7950
rules.
Allow
you
to
make,
as
in
pick
up
whatever
arbitrary
version
is
available
or
pick
up.
G
The
latest
part
of
the
part
of
the
thing
we're
scratching
our
heads
about
as
well
is
when
you
have
a
an
import
statement
by
by
version
in
a
Yang
module.
How
is
that
used?
What
users
or
tools
actually
use
that
when
you
picture
a
server
and
a
server
advertises
to
you
in
Yang
Library,
here's
the
modules
and
the
versions
I
support?
Well,
those
are
the
versions
it
supports.
So
if
whatever
the
constraint
says
on
the
import
statement,
the
server
is
telling
you
what
it's
supporting.
G
So
unless
there's
ambiguity
and
what
the
server
is
reporting.
If
the
server
is
reporting,
multiple
versions,
which
is
only
allowed
for
import,
only
modules,
it's
only
allowed
to
implement
one
module.
One
version
of
a
module
so
I
mean
the
client
at
that
point
knows
what
the
server
is
telling
it
is
to
be
used,
so
we're
also
in
the
middle
of
debating
exactly.
How
is
this
import
by
version
used
like
what
uses
it
it,
especially
given
a
server
is
going
to
advertise
what
what
versions
it's
using
so
apologize.
G
If
that
isn't
clear,
we're
still
actually
trying
to
hit
our
heads
around
what
we
should
do
on
this
one
and
it's
a
little
bit
of
a
complex
one.
Any
feedback
here
if
people
have
thoughts
is
great,
but
also
please
join
the
weekly
calls.
If
you
have
some
ideas
or
thoughts
around
how
this
import
should
or
could
work.
G
B
Thanks
for
keeping
us
up
to
date
on
where
the
document
stands
clearly,
this
is
getting
a
lot
of
interest
from
the
community
and
from
users
and
implementers.
If
you
haven't
been
tracking,
it's
a
good
time
to
go,
read
the
document.
We
are
closing
on
just
a
few
more
issues
and
then
expect
to
do
a
second
last
call.
E
I
sure
hope
not
everyone,
I'm,
Joe,
Clark
I'll
be
presenting
Yang,
simver
and
I
I
had
to
laugh
because
on
the
Jason's
slide
it
had
capital,
S
capital,
V
after
Yang
and
as
you'll
see
in
a
a
minute.
We
we
were
very
prescriptive
in
how
we
write
things
and
it
shouldn't
have
been
with
the
capital
V
anyway,
next
slide,
please.
E
So
what
happened
between
last
time?
And
this
time
we
released
a
REV
0.0008,
which
finalizes
the
working
group
last
call
comments
from
way
back
when
from
Jurgen
and
Andy,
or
we
think
we
hope
we
we
finalized
it.
Let
me
talk
about
that
sember
thing.
So
in
our
in
in
the
draft,
it
talks
about
the
December
2.0
and
if
you
go
to
December
2.0.0
and
if
you
go
to
semver.org,
you
will
see
that
the
way
they
write
it
is
capital
S,
capital
V.
E
E
There
was
a
discussion
in
working
group
last
call
about
when
one
should,
as
you're
doing
like
pre-release
you're
doing
module
or
draft
development
with
a
Yang
module
in
it.
When
should
you
if
you're
going
to
use
the
Yang
Simba
rules
and
we
and
the
I
we
think
is
the
as
the
people
on
the
call
that
we
should
push
for
Yang
simvar
to
be
used
as
a
revision
label
scheme
for
ietf
modules.
So
when
you're
doing
that
ietf
module
development?
E
When
do
you
have
to
bump
that
that
semver
or
the
the
revision
label,
so
we
clarified
when
that
happens,
and
in
fact,
because
we
did
make
some
changes
to
the
Yang
module?
That's
in
this
document.
This
is
a
time
where
we
did
bump
that
so
the
current
revision
label
for
the
module
within
this
document
now
does
match
08.,
and
then
there
were
some
ID
knit
problems,
some
long
lines
and
whatnot.
So
we
got
things
kind
of
Tidy
for
that
second
working
group
last
call
next
slide.
E
E
E
It
says,
given
this
revision
label,
it
points
to
a
revision
and
once
we
know
the
revision,
we
can
work
our
way
up
and
we
can
find
where
this,
where
our
current
module,
where
it
descended
from
who
was
its
its
its
parent
or
grandparent
and
so
on
and
so
forth,
and
that's
all
well
and
good.
That's
I
have
the
Alias
I
can
find
my
revision.
E
I
can
work
my
way
back
in
the
history
and
I
know
whether
or
not
I
was
derived
from
this
other
module,
but
there
are
implied
rules
with
semver
that
the
human
brain
just
latches
on
to
that
says
that
if
I
have
something
that
is
3.5
dot,
two,
let's
say
and
I
have
something
that's
3.5.1
or
let's
do
something
better.
If
I
have
something
3.7
and
I
have
something
that's
3.6
I
might
assume
that
3.7
is
backwards
compatible
with
3.6.
E
Just
because
that's
how
my
brain
thinks
about
simver,
but
what
we
realized
was
there
was
no
text
in
the
document
that
really
said
that
that
was
the
case
that
you
could
that
you
we
wanted
3.7
to
be
backwards
compatible
with
3.6.
So
we
started
to
explore
what
is
starting
on
the
next
slide,
please
what
are
good
and
and
bad
lineages
or
good
and
bad
trees.
So
here
is
the
bad
tree,
and
this
is
the
text
that
we
added
around
this
I'm
not
going
to
read
the
whole
text
there.
E
Well,
if
you
just
look
at
this
from
the
whole,
a
sem
a
yang
symbol
is
a
revision
label
which
is
an
alias
to
a
revision.
You
would
look
up
the
revision
and
you
could
find
that
3.20
did
in
fact
not
descend
from
3.6
great,
so
it
it
obeys
Yang
versioning,
what
Jason
described,
but
from
a
Yang
simmer
standpoint.
E
E
You
might
be
surprised
that
it's
not
and
that
there
is
no
backwards
compatibility,
this
type
of
revision,
this
type
of
changes
from
a
revision
standpoint,
it's
perfectly
legal,
we're
not
saying
that
it
isn't
the
text
that
we
added,
however,
says
that
if
you're
going
to
do
something
like
this,
you
can't
use
Yang
Simba
as
a
revision
label
scheme.
Yang
simber
has
some
additional
implications.
That
says
you
need
to
follow
those
rules.
The
human
brain
should
look
at
this
and
say
yep
3.20.0.
E
E
E
We
have
a
3.5.0
and
we
move
to
a
3.51
compatible,
and
we
did
that
because
it
was
a
an
editorial
or
patch
change
where
we
added
a
leaf
food,
so
we
have
to
use
our
modifier
compatible
and
later
on,
we
added
a
3.20.0
that
added
Leaf
bar
in
this
case.
We
think
yes,
this
is
allowed
because,
as
you
read,
the
text
with
those
modifiers
compatible
not
not
compatible.
E
All
bets
are
off
when
you
start
adding
compatible
that
when
you
start
adding
those
modifiers
all
bets
are
off,
and
we
think
this
is
more
of
a
corner
case,
because
we
think
in
general,
a
lot
of
development
would
not
necessarily
use
the
modifiers,
and
then
he
created
an
A2
which
is
like
A1,
but
with
additional
qualification
for
time.
But
still
we
think
that
both
A1
and
A1
Prime
are
A2.
Those
would
be
allowed
next
slide,
please
so
A3
is
this
allowed.
E
So
in
this
case
we
have
a
patch
or
editorial
change
2.3.5
and
we
created
a
new
2.3.6.
Maybe
we
fixed
the
spelling
of
the
word
registered,
which
I
did
in
our
draft,
because
I
forgot
an
e
and
then
later
on,
we
create
a
2.3.20
again,
a
patch
revision
or
editorial
descendant
from
2.3.5.
We
think
this
is
also
legal,
because
in
this
case
there
is
backwards,
compatibility
because
of
the
definition
of
what
those
patch
without
a
modifier,
what
those
patch
revision
changes
mean.
E
E
It's
an
A,
so
we
there
are
some
of
us
who
think
this
isn't
a
loud
thing,
but
really
what's.
Happening
Here
is
you're
with
in
time
you're
you're,
creating
this.
This
10
major
revision,
10
that
goes
to
Major
revision
11,
and
then
you
have
a
new
mate,
a
new
major
revision
20,
which
descends
from
10
not
11,
and
then
a
30
from
20.
E
I
think
this
is
allowed
personally,
because
once
you
get
to
Major
revision
changes,
we
document
the
human
brain
thinks
Here
Comes
Rob,
to
tell
me
I'm
wrong
that
that
these
are
not
backwards.
Compatible,
10
and
11
aren't
backwards.
Compatible,
20
and
11
aren't
backwards,
compatible,
20
and
10
aren't
backwards
compatible,
and
there
are
other
development
things
that
we
feel
would
fit
into
this.
So
we
I
think
the
consensus.
Is
this
isn't
a
loud
tree
but
Rob?
Please.
A
Robots
and
Cisco
as
a
contributed
to
this
work,
so
I
I
think
this
probably
is
allowed
I
think
sort
of
against,
in
my
mind,
against
the
spirit
of
what
what
semba
tries
to
achieve,
which
is
you're,
trying
to
always
update
the
head
of
the
the
main
development
branch,
and
that's
where
you
update
the
number
so
so
I
don't
think
we
should
disallow
this.
It
just
feels
to
me.
I
would
suggest
that
people
shouldn't
not
not
in
the
documents
they
shouldn't.
A
A
So
so
this
one,
though
I
do
have
more
concerns
with
I.
Don't
think
this
should
be
allowed,
because
the
two
three
2.3.20
also
should
be
backwards
compatible
to
2.3.6
so,
depending
on
what
changes
have
gone
into
that,
and
maybe
if
it's,
if
it's
a
patch
change,
maybe
it's
nothing
significant
and
it
doesn't
matter.
I,
don't
know,
but
again
back
the
same
things
with
Simba
I
expect.
A
These
things
are
always
sort
of
mainly
adding
to
the
head
of
the
branch,
and
we
have
the
the
sort
of
non-compatible
and
compatible
extensions
to
try
and
have
that
limited
branching.
But
I
I
do
also
admit
that
Simba
itself
is
not
brilliantly
specified
as
exactly
what
the
rules
are,
which
doesn't
really
help,
but
we
can
be
tighter.
E
G
Yeah,
so
for
this
one
here,
I'm
on
the
fence
and
not
don't
care
too
much
either,
but
one
thing
to
point
out
is
I.
Think
this
one
probably
is
okay,
because
don't
forget
the
minor
digit
hasn't
changed
here,
so
they're
still
compatible.
It's
only
editorial
fixes
that
are
the
difference
between
these.
So
I
don't
know.
If
we
want
to
restrict
this
and
say
it's
not
allowed
versus
the
other
variant
to
this
that
Joe
started
the
presentation
with
were
the
minor
digit
changes.
It
can
actually
cause
compatibility
problems.
A
So
yeah
I
I
think
for
me
the
thing
that
I'm
thinking
about
the
whole
thing
is
is
the
level
of
complexity,
complexity
that
we
have
and
that
we're
introducing
and
where
we
can
try
and
minimize
that
complexity.
I,
think
that
is
worth
it.
Even
if
we
potentially
disallow
some
of
these
cases,
it
feels
to
me
that
we
should
be
trying
to
drive
complexity
down
because
otherwise
I
I
think
people
are
going
to
struggle
to
understand
what
the
rules
are.
We
should
try
and
simplify
it.
E
J
A
G
The
problem
is
when
we
say
we
don't
want
this
or
especially
A4
I,
don't
know
if
you
had
a
slide
after
A4
that
showed
the
alternative.
If
you
don't
support
A4
and
if
someone
needs
to
describe
this
branching
scenario,
the
alternative
for
what
they
put
may
look
worse.
So
that's
something
we
should
consider
when
we're,
because
it's
not
just
don't
do
this.
It's
okay
and
I.
G
A
E
R
So
my
mother
has
any
with
swisscom
I
have
a
bit
more
fundamental
question
here.
So
here
this
is
the
reflection
of
the
development
history
of
the
version
right.
This
is
not
about
the
versioning
itself.
You
know
whatever
telling
you
clearly.
If
you
have
measure
upgrade
measure
revision,
you
have
a
new
version
and
they're
not
that
good
compatible.
So
whether
I
don't
understand,
what's
the
point
here
to
keep
track
of
the
history,
if
you
have
any
way,
non-compatible
are
virgins,
you
can
do
for
version
20.
You
can
do
the
diff
against
10
or
11..
O
E
Yeah,
the
the
fundamental
reason
for
somewhere
here
or
or
having
this
is
a
revision
label
scheme
is
to
give
that
consumer,
the
user,
a
a
hint
to
say.
Okay,
now
I
downloaded
or
this
device
is
now
supporting
this
version
of
the
module
oh
I'm,
currently
using
10
and
now
this
device
wants
to
use.
20.
I
need
to
do
more
work,
because
this
is
likely
going
to
impact
the
way
I,
the
tooling,
that
I
have
and
how
that
tooling
interacts
with
this
device.
R
E
E
E
Next
slide,
please
looks
like
I've
got
a
few
more
left,
I,
don't
think
I
have
your
alternative.
Now
I
move
into
illegal
bad
trees.
Try
not
to
use
the
word
illegal
in
the
draft.
I
don't
think
I
did.
But
X1
is
here.
You
have
major
versions
20
or
two
to
four
to
six
and
then
descendant
off
of
two.
You
have
three
and
five
I.
This
is
one
where
I
I
kind
of
disagree
with
the
college.
They
they
say
illegal
or
bad,
not
allowed
I,
say
it's
major
versions.
E
E
D
E
If
you
want
to
go
from
2.0
to
10.0
back
to
8.0,
maybe
your
cotton
reverse
causal
loop,
I,
don't
know,
but
it's
not
the
best
practice,
but
because
it's
major
version
numbers
I,
don't
want
to
add
I,
wouldn't
my
preference
would
be
not
to
add
text
to
disallow
this.
It
just
feels
it
just
feels
like
it's
bad
practice,
but
Rob's
clicking.
So
maybe
he's
joining
the
queue
oh
Kent
is
and
I'm
Rob
is
as
well
Kent.
D
D
A
E
So
here
I'm
I'm
conflicted
whether
or
not
we
need
to
add
text
whether
or
not
this
should
be
allowed.
I
I
would
say:
don't
do
this
just
like
we've
said
on
some
of
the
other
X's,
but
I
I
don't
know
if
we
need
to
call
this
out
as
a
counter
example
or
something
not
to
do
or
that
we
would
not
allow
with
with
Yang
Simba.
A
O
L
E
L
E
You
it's
something
we
I
mean
we.
We
went
back
and
forth
a
lot
on
these
modifiers,
as
you
know,
so
maybe
something
to
discuss.
I
I,
don't
know
that
we
want
to
change
it
now,
but
we
we've
it
can
certainly
be
brought
up
and
and
bannered
around
on
the
list
last
slide,
please,
which
is
really
a
anti-climatic.
B
E
G
D
B
O
B
Thanks
all
right,
great
thanks,
I'm
amazed
that
we're,
after
all
this
time,
we're
like
a
minute
ahead
of
schedule.
So
with
that
we're
going
to
go
to
the
last
slot
and
I
should
say
to
the
versioning
team
and
all
the
authors.
Thank
you
so
much
for
some
excellent
work.
It's
it's
super
important
work
and
we
know
it's
really
tough
and
it's
taken
a
lot
of
effort.
So
thank
you.
K
K
Thanks
the
opportunity
to
present
us
I'm
going
to
look
at
modeling
and
some
challenges
we've
had
in
certain
areas
of
modeling
and
suggestions
that
I'm
going
to
suggest
that
we
may
need
to
extend
meta
models,
extend
techniques
and
methodologies
and
so
on.
So
that's
what
I'm
aiming
for
here!
I'll
go
to
the
first.
If
you
know
the
first
slides
I'll
move
on
thanks
next
slide
next
one
so.
K
It's
there's
a
I've
got
an
idea
and
I've
put
in
so
there's
the
references
in
here
I'm
going
to
go
through
this
very
briefly.
Terminology
is
a
challenge
in
this
area,
so
we've
come
up
with
a
new
term
which
I'll
talk
about
which
tries
to
tries
to
help
us
discuss.
The
thing
I've
been
grappling
in
this
for
a
long
time
and
it's
I
keep
running
into
the
same
problem.
So
a
number
of
us
agree,
there's
there's
potentially
an
issue
here,
so
we
thought
we'd
present
next
slide
thanks.
K
So
this
gives
us
sort
of
an
overview
of
where
the
the
challenge
appears
to
lie.
So
as
we
look
at
Advanced
Solutions,
we
we
come
across
a
number
of
things:
intent
capability
expression
where
we're
looking
at
the
capability
of
the
underlying
devices
and
so
on
challenges,
partial
visibility
where
we
there
may
be
a
noisy
environment,
and
we
can't
we
can't
actually
see
the
full
view
of
the
detector
all
the
time
or
something
of
this
sort.
K
K
So
these
these
all
appear
to,
as
I
said
on,
the
second
board
it'll
appear
to
be
requires
some
kind
of
development
through
a
recursive
or
Progressive
narrowing
of
things.
So
with
my
ss7
negotiation,
I
start
with
a
very
vague
expression
of
something
I
gradually
narrowed
down
to
a
more
precise
one.
There's
no
specific
number
of
steps
I
might
take
here,
so
we,
you
might
think
of
a
process
of
metamodel
model
instance,
but
no
there's
no
number
of
specific
steps.
We
go
through
here
and
I
just
stop
at
the
right
level
for
the
Viewpoint.
K
K
So
we
coined
this
term
occurrence
because
we
couldn't
find
any
other
words.
I've
tried
to
use
various
other
terms
for
this,
but
each
one
of
these
narrowings
it
comes
up
with
an
occurrence
of
something.
The
occurrence
is
a
mixture
always
of
of
statements
of
of
what
look
like
specification
of
type
with
ranges
and
so
on
and
also
statements
of
precise
value.
So
the
the
the
process
we
seem
to
be
going
through
often
is
to
tighten
towards
this
instance.
K
K
Even
if
I
get
down
to
an
instance,
That's
Just,
An
Occurrence,
so
everything
appears
to
be
occurrences
and
everything
appears
to
be
a
progression
towards
this
narrow
and
narrower
thing,
and
the
the
properties
are
defined
in
terms
of
constraints,
even
a
single
value.
You
know
the
integer
is
five.
It's
still
just
a
constraint
on
that
integer,
it's
just
a
very,
very,
very
tight
one
and
the
the
method
then
requires
an
expression
that
mixes
types
and,
in
instance,
values
together
and
conventional
modeling
techniques.
K
Don't
appear
to
do
this
for
us,
so
we
then
struggle
inventing
things
in
the
middle
somewhere,
and
hence
this
suggestion
that
there
may
be
a
methodology
and
a
meta
model
requirement.
But
looking
at
Yang
with
I've
played
around
in
the
in
the
back
of
the
draft
with
some
in
an
appendix
with
some
variant
of
Yang,
it
appears
I
could
potentially
use
Yang
if
I
in
a
particular
way
to
be
able
to
do
this.
It
looks
like
Yang
might
be
extensible
to
this,
although
the
thing
I
do
is
very
strange
to
do
it.
K
So,
let's
get
on
the
next
slide.
Please
thanks
so
just
to
emphasize
these
things.
So
the
things
I
was
talking
about.
Obviously
in
the
idea,
use
expectation
intention,
because
I
like
to
look
at
intentions
being
a
two-sided
thing
where
one
of
the
client
expects
and
the
provider
intends
to
do
something,
but
that's
the
desired
outcome
in
terms
of
constraints,
capabilities,
opportunity
for
Behavior
exhibitive,
which
again
is
a
set
of
constraints
on
a
limited
bounded
thing
and
the
partial
partial
visibility
thing
is
I'm.
K
Expressing
that
I
can
only
see
something
within
some
kind
of
precise
range.
I
can't
tell
you
exactly
what
the
temperature
is
somewhere
between
30
and
50,
but
I
can't
say
precisely
or
I
might
not
know
or
I
might
you
know
be
currently
unsure,
but
you
know
eventually
short,
so
it
Narrows
and
broadens
you
can
go
to
the
next
slide.
Please
that'd
be
great
thanks.
K
Okay,
so
here's
a
sort
of
an
example
of
some
narrowing
I
start
off
with
a
standard
where
I'm
expressing
something
as
a
in
in
a
as
a
constraint
is
boundless
it's
an
integer.
It's
randomly
chosen
bit
rate
for
example,
and
then
in
a
particular
event
the
solution.
This
there's
a
specification
to
this,
where
that
many
solutions
able
to
operate
between
10
and
10
and
100
gigs
another
same
vendor.
K
Another
solution,
they've
got
where
there's
a
piece
of
Hardware
may
be
constrained
by
pricing
and
technology
is
able
to
operate
between
5
and
50
gigs
and
then
I
have
an
application,
a
where
the
requirements
between
10
and
50.
So
clearly,
both
those
things
will
work,
but
because
I
can
see
the
subset
of
the
specification,
then
at
some
particular
Point
30
50,
some
other
specific
time
at
some
particular
Point
50
gigs.
K
Only
so
these
things
are
different
statements
of
range
on
that
particular
property
when
I
want
to
be
able
to
express
those
ranges,
the
final
one
being
in
that
list
a
single
value
and
then
I
might
have
some
fruitful
concept
where
I
convert
it
to
a
numeration.
I
only
have
have
three
particular
values
and
then
a
particular
case
within
that
proof
of
concept
was
only
one
and
so
on,
and
then
even
the
instance.
K
K
Might
this
is
saying
that
when
I'm
assembling
a
system,
I
might
have
a
set
of
what
I
might
consider
as
classes
piece
Parts
I'm
going
to
assemble,
but
each
particular
application
of
those
parts
that
a
particular
part
is
subtly
different.
It's
a
different,
it's
a
different.
It
minimally
is
a
different
instance.
K
What
I
think
about
some
memory
and
building
a
memory
chip
I've
got
the
same
cell
repeated
over
and
over
and
over
again,
but
they're
not
identically
placed
clearly
because
then
they'd
be
the
same
thing
or
sell
and
they're
not
they're,
not
the
same
instance.
So
I've
got
this
subtle
variety
across
this
set
of
same
things
when
I'm
building
a
system
I
have
to
I
seem
to
have
to
reuse
Parts,
but
where
each
part
is
subtly
different
from
the
pre
another
usage,
and
that's
that
same
level
and
of
course
they
may
have
a
mod.
K
This
may
be
a
module
that
I
then
install
another
system
and
again
I've
got
the
same
Parts
being
reused
with
again
subtle
Variety
in
them.
The
particular
picture
here
is
a
it's
taken
from
some
INF
work,
we're
doing
where
we're
looking
at
some
defining
a
a
management
hierarchy
in
talking
about
View,
mappings
and
so
on,
but
it
shows
there
we're
finding
it.
We
find
it
in
all
of
the
other
specs
of
system
assemblies
we're
trying
to
do
and
clearly
they're,
not
instances,
because
it's
not
a
real
running
thing.
K
Can
you
go
to
the
next
slide?
Please
thanks
and
this
just
the
the
work
we're
looking
at
seems
to
overlap
severely
with
the
compatibility
and
also
versioning,
so
I
think
it
plays
well
into
what
you're
doing
in
that
area.
I'm
not
going
to
describe
this
like
it's
kind
of
the
the
actual
descriptions
and
the
and
the
ID,
but
I
see
I've
got
almost
no
time
left
so
I'll
have
the
question
so
I'll
go
into
the
next
next
slide,
which
I
think
is
the
final
one
too.
K
So
so
what
we
we're
looking
at
here,
it
seems
there
isn't
any
readily
available
terminology
to
deal
with
the
notion
of
the
currents
other
than
this
word.
We've
now
used
ourselves
and
but
but
it
it
it
may
be
that
there
is,
and
so
hence
I'm
looking
across
the
I
presented
this
on
on
the
an
MRG
yesterday
again
and
I'm,
also
we're
looking
for
assistance
to
identify
an
existing
set
of
techniques
or
terminology
that
might
fit
with
us.
I'll
take
the
question
at
the
end.
K
If
that's
what
we've
done,
you
know
why
so
improving
terminology
trying
to
homing
on
on
other
areas
where
this
has
been
just
determined
and
used.
It
seems
to
be
no
good
language
to
describe
this.
So
as
I
said
it,
maybe
we
can
take
Yang
and
refine
it
in
certain
areas
to
help
us
do
this,
solve
this
particular
problem
and
and
hence
bringing
this
here.
K
A
Robles
and
Cisco
no
hats
on
so
thank
you
for
bringing
this
work
here.
I
think
I
think
it's
really
interesting
what
you're
doing
here.
So
it's
interesting
I
do
I,
do
wonder
I'm,
not
sure
I've
found
the
the
example
use
case
to
you
that
compelling
in
terms
of
why
you
wouldn't
just
like
use
Like,
A,
Min
and
Max
for
those
two
values.
C
K
It's
it's.
It
was
severely
simplified
to
allow
me
to
describe
it
during
the
presentations
for
10
minutes.
Unfortunately,
so
that's
all
I
had
done
and
I
thought.
Bringing
a
very
simple
example
might
just
give
the
idea
of
the
range
and
that's
all
but
you're
right.
It's
it's
actually
a
lot
deeper
than
us
on
a
lot
more
challenging
in
many
areas
where
I've
got
into
related
properties,
which
I
wanted
to
describe
the
interrelationship
as
as
I
narrow
them.
They
don't
just
simply
narrow
I
mean
the
the
the
example
I've
seen,
which
is
probably
a
simple
one.
K
Again
is
temperance
humidity
Behavior,
where
the
humidity
acceptable
humidity
varies
with
temperature,
and
so,
as
you,
you
sort
of
get
an
area
described.
So
although
temperature
and
humidity
you
initially
finders
in
individual
isolated
values
and
they
seem
to
be
independent,
nice
big
broad
range
than
any
any
particular
application,
they
don't
play
separately.
They
play
together
and
I.
Don't
want
to
be
able
to
describe
that
sort
of
restriction.
So.
A
A
K
I
Bernard
class
and
I'm
going
to
be
very
quick
because
I
see
new
eyes
that
you
have
to
cut
the
line,
so
thanks
Angel
for
bringing
this
this
work.
This
has
been
on
my
mind
for
quite
some
time.
I
I
see
those
problems
from
multiple
angles,
from
intent
from
config
from
personal
data.
There
is
no
perfect
answer,
but
we
need
to
continue
working
on
this
because
I
see
all
of
these
problems
thanks.
Okay,
great.