►
From YouTube: IETF112-NETMOD-20211111-1430
Description
NETMOD meeting session at IETF112
2021/11/11 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
Welcome
to
the
ietf
112
netmod
session,
I'm
blue
burger
here
with
my
co-chair
kent
watson.
We
also
have
a
third
co-chair,
who
I
think
may
be
trying
to
join
the
material.
For
that
we'll
be
going
over
today
is
all
uploaded
on
data
tracker
and
we
are
using
the
note
taking
tool
which
today,
I
think
is
called
hedge
doc
it'll
change
tomorrow,
but
we're
using
the
note
taker
tool.
The
link
is
here:
it's
also
in
the
chat
session.
We
ask
everyone
to
please
jump
on
and
help
us
capture
everything.
That's
said
during
discussion
time.
A
Excuse
me
we're
well
into
the
ietf
this
week,
so
I
think
folks
will
be
fairly
familiar
with
our
notewell.
We
have
a
set
of
documents
and
pcps
that
govern
how
we
interact,
how
we
operate
that
covers
both
technology
disclosures
patents,
ipr
as
well
as
code
of
conduct.
A
Please
keep
in
mind
that
everything
we
say
and
do
here
becomes
part
of
our
public
record.
We
are
recording
this
session
and
though
this
session
will
be
made
available
via
youtube,
as
well
as
other
ietf
memes.
A
One
of
these
pcps
is
our
conduct
guidelines.
It's
bcp54
we've
been
asked
by
our
leadership
to
highlight
this,
and
you
know
that
this
has
always
been
there
bcp54,
but
there's
been
some
recent
discussions
and
we
think
it's.
We
think
they
think
it's
very
important
to
ensure
that
we
keep
our
interactions
very
respectful
and
courteous
and
collegiate,
and
even
if
we're
having
heated
discussions,
which
is
also
just
fine
to
have
discussions
which
you
are
maybe
a
little
passionate
about,
but
please
keep
it
technical
and
always
respectful.
A
We're
using
medeco
if
you
are
listening,
you
you
found
us
and,
as
I
mentioned,
we're
going
to
make
a
video
recording
of
this,
so
you
might
be
seeing
this
on
video.
The
note
taking
we've
mentioned
before
it's
the
collaborative
I've
seen
one
person
join
since
I
asked
others
to
join.
We
have
please
take
a
look
and
click
on
the
chat
button
go
to
the
top
and
click
on
the
the
note
taking
page
and
and
help
us
capture
the
discussion.
It's
really
important
that
we
capture
actions
and
and
the
good
discussion.
B
Just
quickly
add
also
the
link
at
the
very
top
of
the
meat
echo
window.
The
fourth
icon
from
the
left
on
the
in
the
top
right
corner
is
taking
the
notetaker
tool
as
well.
Thank
you.
A
And
that
was
kent.
For
those
of
you
that
don't
know
the
agenda
is
basically
as
published,
we've
had
some.
I
think
we
had
a
speaker
update
and
some
versions
update,
but
the
the
agenda
is
largely
unchanged
again.
All
the
material
is
posted.
A
This
slot
is
actually
coming
to
us
from
a
c
camp
document
and
I
think
the
main
question
really
there
was
which
working
group
does
this
belong
in
and
generally
we
follow
the
the
practice
in
net
mod
as
if
there
is
another
working
group
that
has
expertise
on
the
material
being
covered
by
the
model.
It
should
be
done
in
that
working
group.
So
we
would
expect
this
to
continue
and
see
this
work
to
continue
in
c
camp,
as,
as
is
indicated
by
the
draft
name,.
A
We
have
not
had
any
rfcs
published
since
the
last
time
we
met,
but
we
do
have
some
items
in
the
rfc
editor
queue.
I
don't
think
there
was
anything
particularly
noteworthy
there
to
talk
about
I'll
defer
to
kent
if
he
wants
to
jump
in
with
anything,
but
I
don't
think
there
was
anything
really
noteworthy
there.
The
post-last
call
documents.
We
have
a
couple
that
are
expired.
The
authors
are
have
committed
to
doing
that
update,
so
these
aren't
dead,
even
though
they're
expired.
So
we'll
keep
an
eye
on
that.
A
We
do
have
one
document
that
was
returned
to
the
working
group.
Basically,
there
was
some
alignment
necessary
to
reference
documents.
The
action
for
that
sits
with
the
authors,
and
we
really
are
hoping
that
the
authors
take
initiative
there.
If
they
don't.
If
there's
others
who
wish
to
help
out,
I
would
suggest
that
they
contact
the
authors
as
well
as
cc
the
netmod
chairs,
and
we
can.
We
can
discuss
that.
A
We
have
several
documents
not
on
the
agenda.
No
tags
has
hasn't
been
modified
in
a
while.
There
has
been
an
update
on
the
list
a
couple
of
times,
so
we're
really
looking
for
an
update
there,
the
next
one,
the
the
we
there
was
some
recent
good
discussion
about
whether
to
take
that
to
last
call
as
is
or
wait
for
addition
additional
changes.
A
We
we
think
that
it
would
be
fine
to
move
this
forward
if
there
isn't
something
immediate
that
would
that
had
been
identified
by
the
working
group
that
should
be
added.
So
please
take
a
look
at
this
document.
If
you
think
you
have
something
you
want
to
add
to
it,
please
propose
it
on
the
list.
If
we
don't
see
anything,
probably
sometime
in
december,
we'll
take
it
to
last
call
versioning
requirements.
That
document
is
pretty
well
complete,
we're
just
waiting
for
the
other
versioning
work
to
it
to
advance
it.
A
We
haven't
had
any
recent
incoming
or
outgoing
liaisons
proposed,
if
you
think
you
have
one
that
is
important,
please
let
us
know,
and
the
best
way
to
do
that
is
on
the
list.
A
Yeah,
that's
sort
of
the
first
point
here
is
utilize.
The
list,
that's
where
we
do
consensus.
These
discussions
are
good.
The
interims
are
good
they're,
very
important
for
helping
us
make
progress,
but
decision
making
happens
on
on
the
list.
A
This
is
particularly
important
when
you
have
it
to
keep
in
mind
when
you
have
an
active
set
of
authors
that
are
actively
discussing
changes,
they
may
to
agree
to
a
set
of
changes,
but
if
it's
a
working
group
document,
the
acceptance
of
those
changes
is
governed
by
the
working
group,
not
the
authors,
so
those
that
it's
great
to
have
that
progress.
But
the
this
the
discussion
has
to
be
reflected
on
the
list.
Then
we
have
to
get
buy-in
from
the
working
group
there.
A
We
continue
to
support
and
offer
informal
meetings
that
we
can
that
the
chairs
can
support
that
through
scheduling
working
group
web
access.
We
also
can
have
virtual
interims,
like
we
did
last
month,
and
all
that
takes
again
is
a
request
to
the
authors
or
sorry
request
from
to
the
the
chairs.
A
C
A
A
C
C
What
we
are
doing
these
days
is,
we
have
the
first
two
drafts,
the
module
versioning
and
the
yanks
amber
drafts.
We
try
to
finish
that
and
push
them
to
work.
Group
last
call
so,
and
then
we
are
beside
this.
We
are
also
working
on
the
package
drafts
or
package
draft.
There
are
a
number
of
open
issues.
We
have
an
issue
tracker
on
the
idea
website.
C
And
re
solve
all
the
issues,
so
what
updates
we
have
been
doing?
We
had
are
at
dash
05
at
this
point
that
was
released
last
days
for
the
module
versioning.
Basically,
it's
editorial
updates
and
adding
a
few
small
statements
correcting
some
of
the
examples
and
that
not
nothing
new
major
com.
Functional
happened
here
for
the
stemware
this,
which
defines
our
versioning
labeling
method.
C
We've
changed
the
prefix
to
make
it
shorter
and
and
unique
in
the
in
our
yang
module,
and
then
there
were
a
number
of
editorial
changes.
C
C
C
Next
steps,
what
we
are
still
working
on,
we
have
the
tracker
for
the
first
two
modules:
module,
versioning
and
some
semantic
versioning.
The
issues
are
closed.
We
believe
we
found
a
solution
for
every
of
those
issues
and
the
authors
believe
that
these
two
first
drafts
are
ready
for
work.
Group
last
call,
so
we
call
on
the
chairs
to
decide
please
and
we
are
focusing
on
the
packages
draft
without
the
all.
C
The
number
of
issues
and
number
of
people
are
contributing
text
and
we'll
have
a
bit
more
presentation
on
what
is
happening
there
and
with
that
I'm
open
to
questions,
or
I
would
hand
over
to
my
colleagues
to
speak
about
what's
happening
in
packages.
B
D
B
Question
but
comment
just
as
a
recap:
the
the
plan
for
the
working
group
is
that
we
will
take
these
first
few
drafts
to
working
group
last
call,
but
then
the
chairs
will
hold
them
within
the
working
group
until
the
entire
set.
All
five
drafts
are
last
called
and
at
which
point
we'll
take
them
to
iesg.
E
C
And
besides
the
meeting,
as
the
chair
said,
we
we
try
to
get
all
issues
also
to
the
mailing
list
and
we,
I
hope
we
did
it
correctly.
E
Oh,
I
I
don't
have
comments
on
this,
I'm
just
preparing
for
the
next.
I.
B
E
Can
you
see,
but
right
now
same
size,
yeah,
it's
good,
hello,
everyone!
This
is
bohu
and,
as
just
lash
mentioned,
I'm
going
to
present
young
packages
dropped
status
on
behalf
of
all
the
authors
and
and
the
versioning
netmode
versioning
team.
E
Since
last
revision,
we
we
don't
do
very
major
changes,
but
we
we
tried
to
remove
the
package
check
some
definition.
Since
mod
module,
versioning
draft
has
removed
all
the
module,
versioning
module,
checksum
and
packages
draft
needs
to
keep
consistent
with
all
these
checksum
issues.
So
that's
the
only
changes
we
we
do
to
this
revision.
E
Regarding
all
the
other
open
issues.
Right
now,
we
still
have
20
open
issues
and
blush
also
mentioned
that
all
these
issues,
mostly
issues,
has
been
assigned
owners,
so
the
contributors
and
working
on
that
and
to
move
it
forward,
and
here
we
list
the
three
issues
we
are
in,
that
we
are
under
discussion
in
the
weekly
meeting
and
I'll.
E
I
took
it
each
on
this
and
about
issue
65.
This
is
a
quite
typical
one
that,
in
in
the
open
issues
that
we
need
to
refine
the
text
and
since
young
versioning
drops
has
been
stable,
and
so
this
draft
need
to
be
made
the
changes.
This
one
is
the
previous
version.
Young
packages
definition
just
use
same
word
label,
but
we
don't
have
a
samurai
label
scheme
so
in
in
so
right
now
we
are
blasha
working
on
this
and
to
to
to
proposal
text
on
it.
E
And
about
some
new
function
of
these
young
packages
is
scheme
amount
right
now
in
in
this
revision,
young
packages
doesn't
define
schema
amount
functions.
E
So
packages
can
give
some
constraints
on
the
mount
point
so,
for
example,
for
itf
basic
package,
it
means
mount
layer,
2,
vpn
or
layer,
3
vpn
packages,
so
for
young
packages.
Then,
in
the
on
the
mod
points
we
can
list
some
constraints,
whether
maybe
only
their
three
vpn
needs
is
allowable
package.
E
So
to
this
issue
with,
we
think
we
will
update
to
include
the
mount
point,
information
and
define
some
constraints
for
mounted
schema
here.
We
list
some
rules
on
this.
E
Like
some
package
package
x
can
constraints
the
instance
of
one
point
to
con
to
restrict
only
layers,
two
vpn
earlier
3
vpn
to
be
mounted
and
schema
months
listed
in
packet
is,
can
be
override
of
months
in
the
included
package
and
the
rule
number
three
will
be.
A
list
of
allowable
packages
must
include
all
allowable
packages
from
included
packages.
E
And
one
major
issue
is
that
right
now,
young
packages
also
define
a
model
list,
but
jan
proposed
this
issue
that
he
he
has
some
concerns
on.
There
are
already
four
mechanism
standardized
by
ietf.
E
Seventy
nine
fifty
mandates
in
one
one
one
dot
one
is
that
young
library
is
mandatory
and
so
module
list
is
already
there
and
also
we
have
883
42,
mmda
young
library,
so
young
package
will
be
the
fifth
mechanism
to
list
the
set
of
modules
and
so
right
now,
yen
is
working
on
this
to
try
to
propose
some
way
to
remove
this
duplication.
E
So
that's
almost
the
status
and
progress
we
made
and
and
also
the
k
issues
so
next
step
they
als
the
team,
are
working
on
the
open
issues
and
try
to
move
make
more
progress
on
this.
A
Thank
you
for
the
hard
work
and
progress
update
as
a
reminder
to
the
working
group.
Anyone
is
welcome
to
participate
in
it.
It's
a
working
group
activity,
it's
not
an
author's
activity,
so
it's
open
to
all
and
if
you
could
just
try
to
re-post
or
post
what
you
think
weekly
issues
that
are
going
to
be
discussed,
that'll
help
to
identify
help
people
to
identify
when
they
should
show
up
to
these
meetings.
A
It's
it's
a
request.
It's
not
a
you
know!
If
you
don't
do
it,
we
can
live
with
it,
but
it'd
be
nice
just
to
give
warning
of
what
issues
you're
going
to
talk
to
talk
about
each
week,
just
so
that,
if
someone's
interested
in
a
particular
issue,
they
can
show.
Thank
you
for
the
the
work
and
also
thank
you
both
for
ending
early
and
keeping
us
on
schedule.
B
F
F
As
you
can
see,
it's
a
zero
zero
volume
draft,
but
not
really
a
new
work.
Actually,
it
has
already
been
presented
in
netcaf
and
neta
mode
working
groups
for
two
times
and
in
last
itf
meeting.
It
inspired
a
lot
of
good
discussion,
so
thank
you,
jason,
blash,
rob
and
kent
for
your
valuable
comments,
and
also
there
was
a
lot
of
discussion
on
the
mailing
list.
It's
more
than
a
14
number,
a
40
number
of
messages,
and
about
one
month
ago,
a
two
hour
network
intern
meeting
was
held
on
this
work.
F
It's
about
15
participants
and
I
believe
that
we
have
reached
a
lot
of
agreement
with
the
objectives,
scope
and
solution
on
this
work.
So
a
new
draft
has
been
proposed
to
document
the
outcome
in
the
internal
meeting.
So
the
authors
tried
to
rewrite
the
previous
confidence
system
dropped
and
resubmitted
as
a
nato
model.
Individual
draft
based
on
chair
suggestion
so.
F
Yeah,
so
regarding
the
motivation
and
goal,
there
are
four
points
which
are
actually
aligned
with
the
objectives
discussed
in
the
internal
meeting.
If
you
can
still
remember
that
the
visibility
means
that
we
want
to
enable
a
server
to
better
document
the
system
configuration
and
convenient,
because
it
is
often
the
cases
that
the
client
want
to
the
clients
want
to
reference,
a
system
configuration
which
is
not
visible
in
running,
and
we
want
to
avoid
at
least
reduce
heaven
to
copy
the
entire
contents
of
system
configuration
into
running
when
possible.
F
F
F
F
A
client
could
define
a
new
value
in
running
which
will
overwrite
that
in
system,
and
it
may
also
be
possible
for
a
client
to
configure
a
descendant,
node
of
system
defined
list
entry
and
the
mod
results
will
flow
into
intended.
So
system
may
be
overwritten
or
extended
by
running
to
create
intended.
F
In
this
example,
suppose
system
provides
a
loopback
interface
configuration
with
a
name
and
two
ip
addresses
and
step
step,
one
and
step
to
show
that
the
configuration
what
the
configuration
looks
like
in
system
and
operational
respectively
and
in
step
three,
the
client
tries
to
configure
a
description
node,
which
is
a
descendant
node
of
system
defined
interface
list
node,
and
after
that,
the
configuration
of
loopback
0
shown
in
operational
includes
the
name,
description
and
two
ip
addresses,
and
the
original
value
of
those
explicitly
configured
in
running
is
intended.
Otherwise,
it
equals
system.
B
B
Do
you
find
that
they
should
just
continue?
Jason
might
be
having
issues
with
his
microphone.
F
D
F
D
Okay,
I
guess
my
question
was
about
step
four,
and
maybe
this
is
still
a
point
we're
debating
in
the
draft,
but
would
the
origin
there
not
be
running
instead
of
intended.
F
F
So
there
are
some
open
issues.
Some
of
them
may
have
already
been
discussed
during
the
interim
and
others
may
not.
First,
there
is
a
very
fundamental
question
whether
we
want
running
osp
valid.
I
know
that
both
7950
and
8342
define
that
running
must
always
be
a
valid
configuration
that
tree,
and
I
also
know
that
there
may
be
a
concern
that
if
we
allow
running
to
be
invalid,
then
comes
the
issue
of
backward
compatibility.
F
F
The
second
way
is
that
clients
explicitly
copy
and
paste
reference
system
configuration
into
running,
and
we
know
that
copy
and
paste
must
already
be
done
when
configuring
descended
nodes.
As
I
mentioned
before,
the
client
wants
to
configure
a
description
node
for
a
loopback.
The
interface.
This
node
with
a
key
name
is
indeed
is
needed
to
copy
and
paste.
But
the
question
is:
must
it
be
done
for
leaf
reference
2,
and
the
last
way
is
that
the
clients
use
always
system
parameter
to
get
a
module
view
and
then
validate
against
that
merged
view.
F
And
there
are
other
open
issues,
something
like
should
we
define
an
immutable
flag
which
is
used
to
indicate
to
the
clients
which
system
configuration
is
read
only
or
which
is
not.
The
server
will
return
an
error
if
the
clients
attempt
to
configure
a
value
for
a
read-only
system
configuration,
but
what,
if
configuring,
one
with
the
same
value
as
found
in
system,
is
more
like
a
copy
and
passed
in
this
case,
but
should
we
allow
it
and
whether
it's
sufficient
for
this
immutable
flag
to
be
carried
only
when
the
the
clients
retrieve
running
with
system
parameter?
F
The
server
must
remember
whether
a
specific
data
node
intended
comes
from
system
or
running,
but
my
question
is:
should
we
expose
this
origin
information
to
the
clients
and
should
the
origin
ecosystem
be
required
for
system
configuration
copied
and
tested
into
running?
Currently,
it's
more
like
a
explicit
with
default
basic
mode
and
in
default
data.
Nodes
explicitly
set
by
a
client
will
no
longer
be
treated
as
a
default
data,
even
with
a
same
value,
but
always
already
equal
to
intended
seems
more
like
and
overwrite,
rather
than
copy
and
paste.
D
Hi
guys
just
making
sure
you're
hearing
me
again.
A
D
Okay,
so
the
for
the
last
bullet
here
I
I
would
I'd
propose
that
if,
if,
if
like
an
interface
has
been
defined
purely
by
system,
then
the
origin
should
say
system,
but
if,
if
the
user
or
client
has
explicitly
declared
that
interface
in
the
running
config,
then
I
think
that
should
be
reflected
as
a
different
origin.
D
Somehow
so
either
intended
or
or
some
other
whatever
the
same
origin
is
for
explicitly
defined
config
to
show
that
that's
been
kind
of
you
know,
explicitly
entered
into
the
running
configuration
and
because
we're
kind
of
taking
the
stance
that
overrides
and
takes
precedence
over
the
system
configuration
and
that
my
second
comment,
which
is
kind
of
related
to
the
origin,
is
I
mentioned.
I
guess
I
asked
earlier
in
the
example
where
the
origin
should
be
shown
as
intended.
D
I
checked
nmda
and
you're
right.
It
doesn't
seem
to
be
a
running,
but
there's
going
to
be
a
little
bit
of
confusion.
I
think
because
system
merges
into
intended.
D
So
when
we
give
an
origin
of
intended
it's
it
could
it
could
be
a
little
ambiguous
as
to
whether
that
actually
came
from
system
or
from
running
I
mean.
I
know
we
have
an
origin
of
system,
but
we
may
want
to
have
some
more
discussion
about
about
those
origins.
F
B
You
yeah,
I
just
want
to
respond
to
jason's
comment,
actually
both
comments,
so
the
for
the
origin,
equal
system.
When,
when
copy
pasted
into
running,
I
think
the
idea
is
that
you
know
all
the
ancestor
nodes
or
really
everything
that
got
copied
would
initially
have
the
origin
equal
system.
But
then,
if
descendant
nodes
were
being
configured,
then
those
would
be
the
ones
that
would
have
the
origin
equals
intended
and
then,
but
then,
to
your
second
point
and
actually
the
middle
bullet
point
on
this
slide.
B
I
think
the
intention
there
is
whether
or
not
this
work
should
introduce
to
the
intended
data
store,
like
with
the
operational
data
store
inability
to
you
know.
When
you
get
the
configuration
from
intended,
you
could
actually
specify
a
with
with
origin
parameter
that
would
then
annotate
those
values
so
that
even
when
you're
getting
from
intended,
it
would
be
visible
as
to
whether
or
not
those
values
came
from
system
or
from
running.
Currently,
of
course,
that's
not
a
bill
that
nmda
didn't
allow
for
that.
F
Yeah,
the
the
server
must
remember
whether
a
data
node
intended
it
comes
from
system
or
from
running
so
so
that
you
can
make
sure
that
this
it
will
have
no
impact
to
operational.
Those
those
will
previously
present
in
operational
with
origin
ecosystem
will
still
ecosystem,
and
so
that,
but
this
question
is:
should
we
define
this
already
information
to
the
clients,
so
that
can
retrieve
from
intended.
C
So
the
third
bullet-
for
us,
a
very
common
use
case-
is
that
people
do
a
show
all
configuration
store
it
somewhere
and
then
replace
the
full
configuration
back
now.
In
the
such
case,
you
need
the
origin.
Equal
system
markings
to
be
able
to
say
that
yes,
but
the
origin
marked
nodes,
I
don't
we
don't
have
to
push
back.
If
we
would
lose
that,
because
it's
not
there
anymore,
then
we
try
to
override
them,
and
that
leads
to
problems.
So
yes
for
the
bullet.
Definitely.
F
C
D
I
guess
responding
both
to
to
kent
and
abelash
so
balash.
If,
if
someone
does
a
read
back
from
intended
or
operational
and
they
have
not
explicitly
declared
system
configuration
in
the
running,
then
it
would
it
would
report
those
system
configuration
items
as
origin
system.
D
I'm
only
advocating
that
if
an
operator
explicitly
declares
system
configuration
themselves
in
the
running
that
it
should
be
considered
with
an
origin
the
same
as
any
other
config
that
the
client
does
in
running.
I
think
it
would
be
odd
that
you
could
read
the
running,
see
certain
statements
in
there.
D
Then
you
read
operational
and
some
of
the
statements
from
running
have
a
different
origin
than
other
statements
in
running,
so
I'm
I'm
still
of
the
opinion
that
anything,
you
kind
of
anything
you
declare
and
running
that
overrides
system,
in
my
opinion,
that
that
is
considered
just
like
any
other
client
config
and
would
should
be
reported
as
that
as
that
origin,
when,
when
a
client
declares
something
in
the
running
in
order
to
make
offline
validation
work,
they
don't
have
to
copy
the
entire
object
and
all
its
descendant
leafs.
They
just
have
to
copy.
D
G
Thank
you
yeah.
My
main
concern
here
is
that
we
are
redefining
7950
and
83
42
and
in
a
sort
of
highly
incompatible
way,
and
I'm
not
very
favorable
with
that.
B
Contributor,
so
first,
I
think
actually
the
width
system
gives
you
the
normal
behavior
by
default,
but
we
should
double
check
that
to
jason's
point
the
comment
of
the
in
parenthesis
at
the
bottom
of
that
previous
slide
is
said:
much
like
the
default
flag
in
the
with
defaults
rfc,
in
the
sense
that
for
those
servers
that
had
the
explicit
mode,
you
know
the
default
flag
is
there
so
that
the
server
can
know
for
sure
that,
like
the
client,
was
configuring
back
into
running
the
default
value?
B
If
the
client
negated
or
neglected
to
specify
the
default
annotation,
then
the
server
would
say.
Oh,
even
though
this
value
is
the
same
value
as
the
default,
the
server
is
explicitly
configuring
it
so
that
exact
same
behavior,
I
think,
is
what
we'd
want
to
carry
over
into
this
system
idea.
Maybe
we
need
to
have
something
like
system
modes.
If
there's
you
know
with
default
modes,
maybe
there's
like
with
system
modes,
and
so
the
server
can
advertise
its
behavior
in
that
regard,
and
then
sorry.
B
My
second
point
is:
is
that
actually,
I
think
the
first
open
issue,
which
is
the
on
screen
now
is
probably
the
more
important
one
to
be
focusing
on
is
the
extent
of
backwards
compatibility
and
right
now.
I
think
this
work
is
teetering
on
needing
something
like
yang
next
or
neck
of
next
rest.
Comp
next
would
you
know
do
or
or
if
you
know,
we
could
structure
in
one
way
that
it
doesn't.
B
You
know,
because
it
could
be
the
case
that
a
legacy
client
a
client,
that's
not
aware
of
the
ability
to
process
system
information
will
be
suddenly
very
surprised
if
it,
you
know,
does
I
get
on
running
and
it
and
some
extra
annotations
appear,
such
as
the
origin
equal
system
by
default.
They
may
not
know
how
to
process
that,
so
I
I
guess
we
just
have
to
work
through
that
detail.
F
Yeah
there
is,
I
I
believe
we
have
already
discussed
the
issues
all
and
I
have
already
wrapped
up.
I'm
happy.
A
A
Yes,
please
really
good
discussion.
I'd
like
to
continue.
If
we
get
enough
intensity
and
interest,
we
can
always
hold
a
another
interim
and
with
that
moving
on.
H
And
let
me
see
sure
yeah,
that's
good.
Thank.
H
H
So
the
the
idea,
the
idea
of
the
or
the
motivation
of
this
draft
is
that
we
took
as
a
starting
point
the
acl
young
model
that
is
defined
in
net
mode
precisely
in
8519,
and
that
that
young
model
targets
the
configuration
of
the
forwarding
behavior
in
a
device
okay.
So
you
can
create
this,
these
filters,
okay,
so
this
model
you
can
create
the
entries,
so
this
acas
the
matches
and
the
actions.
Okay.
H
H
So
the
current
young
module
defined
in
the
in
rfc8519
is
prepared.
It's
already
prepared
to
have
some
augmentations
okay.
So
it's
been
prepared
to
be
to
be
extended,
however,
because
of
its
design,
there
are
set
of
limitations
that
it
makes
it
complicated
to
do
all
the
improvements
via
augmentation
okay.
So,
in
order
to
do
some
of
the
improvements,
we
will
need
to
do
some
redefinition
of
the
of
some
things.
H
So
here
is
the
the
list
of
the
or
the
functional
of
this,
this
enhancement
and
functional
gaps
and
classified
by
what
is
the
the
problematic
that
we
have
that
we
have
found
and
they
are
documented
in
the
draft.
So
on
the
one
hand,
some
that
lead
to
some
sub-optimal
configuration,
so
one
of
them
is
the
lack
of
manipulating
a
list
of
practices.
Okay,
so
typically
you
need
to.
H
You
can
only
do
one
prefix
at
a
time
in
one
entry,
okay,
so
you
will
have
to
duplicate
many
entries
to
create
that
for
manageability.
Also,
you
cannot
create
or
define
aliases
or
or
sets
for
example,
as
we
will
see,
prefix
is
a
very
common
functionality
that
we
that
we
require
and
then
functional
wise.
We
lack
the
handling
fragments
of
ip4,
so
we
can
discard,
for
example,
a
fragments.
Okay,
also,
the
the
handling
of
tcp
flux
is
sub-optimal.
H
For
example,
it
does
not
support
all
the
matching,
as,
for
example,
it
is
supported
in
pdb
flow
spec.
Okay,
so
will
see
that
we
could,
for
some
do
some
bit
some
mask
to
be
able
to
filter
several
several
deflects,
also
in
in
the
actions
and
right
now
you
can
accept
and
discard,
or
either
silently
or
or
not.
H
But
for
example,
you
could
also
have
rate
limited
actions.
Also,
you
could
perform
a
payload
based
base
filtering,
also
separately
the
couple
from
this
functionality
of
them
of
the
model.
The
current
model
is
a
device
model
okay,
so
it's
intended
that
you
have
a
device
that
has
them
that
you
program
there,
the
acl,
but
we
can
also
use
it
at
a
network
level,
okay
to
manage
the
the
acls
in
a
network,
for
example.
H
H
Okay
and
also
you
could
be
able
to
reuse
the
acr
and
the
content
of
the
acl
for
some
template
or
the
sets
across
regular
devices,
for
example,
the
prefix
list
that
you
do,
that
you
define
is
a
previous
list.
You
can,
you
can
use
a
multiple
device
and
you
can
define
it
once
at
network
level
and
being
able
to
apply
it
in
several
devices.
H
Okay,
so
we'll
go,
which
is
of
the
the
problem,
so
the
first
one
that
we
mentioned
is
the
the
not
that
we
currently
don't
have
a
possibility
to
work
with
list
of
prefixes
okay.
So
so
now
you
can
only
say
which
is
the
destination
ipv4
or
the
next
image
ipv6
or
the
source
and
ipv4
or
ipv6.
H
However,
when
we
didn't
want
to,
for
example,
mitigate
detours
attacks,
we
need
to
provide
a
big
list
of
addresses,
and
even
if
we
didn't
want
to
do
the
combination
of
sources
and
destinations,
even
if
it
makes
a
worse,
the
problem
multiplies
okay.
So
then,
if
we
want
to
create
those
rules
today,
we
wouldn't
require
a
and
multiplied
by
m
entries.
H
Okay,
so,
instead
of
creating
a
single,
a
single
entry,
okay,
so
this
is
how,
with
the
old
one,
just
to
create
the
destination
and
source
in
into
separate
entries-
and
you
could
combine
them
in
a
in
a
single
one
just
by
allowing
changing
this
to
to
allow
a
list,
also
the
how
we've
seen
that
operators
work
is.
Typically,
the
network
operators
maintain
a
prefix
list,
okay
to
to
use
initials,
okay,
and
also
it
is
very
common
that
the
department
that
is
manipulating
this
project
is
a
separate
department.
H
So
it's
typically
a
security
department
or
in
the
case
of
business
customer
even
is
the
it
can
be
the
part
of
the
business
department
that
maintains
their
own
list
of
officers.
So
typically,
people
like
to
maintain
one
list:
okay
with
some
naming
and
all
the
addresses
addresses
there,
so
that
the
management
is
separate.
Okay.
So
so
we
think
it's
it's
good
to
be
able
to
have
those
those
in
those
lists.
Okay,
so,
for
example,
the
the
rooting
policies
already
have
the
notion
of
sets,
and
particularly
the
prefix
sets
in
that
case,
it's
prefix
range
sets.
H
Even
they
call
it
a
prefix
sets.
So,
and
also
we
can
generalize
this
concept
also
to
have
aliases
or
define
sets
okay.
So
we
can
have
these
reusable
definitions
that
you
can
use
across
multiple
acls
and
you
can
have,
for
example,
these
prefix.
The
specific
sets
of
prefix
list,
where
you
have
all
these
ipv4
or
ipv6
prefixes,
the
protocol
says,
or
port
number
sets
you
defined
as
in
the
the
set
of
the
set
of
ports
to
reuse
or
even
icm.
H
Icmp
sets
what
you
can
filter
the
type
or
or
or
the
code,
and
you
can
have
them
already
pretty
fine
and
reduce
them
also
another
another
thing
that
we
that
mentioned,
is
the
the
handling
of
of
lux.
So
even
the
acl
is
applied
locally.
It
is
typical,
sometimes
it's
triggered
by
biodirectors.
For
example.
H
The
video
flow,
as
I
mentioned
before,
is
one
of
the
one
of
the
possibilities
and
the
we
cannot
easily
map
all
the
all
the
filtering
rules
and
in
particular,
one
of
the
things
that
we
we
cannot
do
is
the
correlates
handling
all
the
tcp
flags
in
the
in
the
current
draft.
You
can
have
select
one
flag
today
or
one
one,
one,
one
bit
of
the
tcp
flag,
but
you,
for
example,
cannot
create
a
mask
too
much
of
a
serial
tcp
tcp
flux,
okay.
H
So
what
I?
What
I
wanted
to
ask
the
working
world
today
is
several
questions.
First
of
all
I
mean
these
are
the
we
are
willing
to
work
on
on
the
extensions
necessary
to
to
fill
this
discuss,
but
we
need
some
guidance
from
the
working
group,
especially
that
the
starting
point
is
an
existing
rfc
okay.
So
so
what
are
the?
So?
H
We
want
to
ask
the
working
group:
what
is
the
best
suggestion
to
approach
the
enhancements
so
either
we
have
an
a
new
version
of
the
acl
model,
so
just
version
whatever
or
not
fcbs,
or
whatever
way
we
can
minimize
the
number
of
compatible
changes
there.
There
will
be
some
number.
There
will
be
some
changes
that
break
existing
structure,
but
minimizing
them
either.
We
could
augment
the
existing
ninja
module,
not
touch
everything
that
is
there,
but
only
if
we
need
to
add
things
we
have
everything
on
on
top.
H
D
In
queue
yeah,
I
guess
just
about
how
to
approach
the
work.
It
might
need
more
discussion
on
the
mailing
list
to
see
how
the
scope
of
the
work
evolves
and
how
much
functionality
is
being
added
and
how
backwards
compatible
it
is,
but
you
might
my
initial
gut
is.
It
would
probably
be
a
a
separate
rfc
that
augments,
you
know
with
with
extended
extra
functionality,
just
as
a
as
a
as
a
first
cut
from
what
I'm
seeing
from
this
about
the
network
versus
device
model.
D
I
guess
I
had
a
question
when
you
say
device
like
a
so
there's
per
interface
acls,
and
then
you
have
this
kind
of
device
or
network
acl
is
the
intention
that
that's
that's
an
acl
that
is
effectively
applied
to
traffic
coming
in
on
any
interface.
H
The
second
question
of
the
network:
no,
the
idea
is
to
be
able
to
manage
acls
that
or
or
sets
or
prefix
lists
that
are
used
in
several
devices.
Okay,
so
that
you
can
have,
for
example,
a
template,
an
acl
template
and
that
acl
template.
If
you
want
to
replicate
it
in
several
devices-
okay
from,
for
example,
from
a
controller
that
you
can
that
you
can
reuse
it
easily.
So
it's
something
to
facilitate
the
management
of
hcls
and
prefix
lists
from
a
central
location,
for
example,
especially
for
the
prefix
list.
H
This
is
independent
on
the
device
that
you
are
your
running
needs,
so
you
will
define
it
once
and
then
you
will
say:
okay.
This
applies
in
this
device,
this
device
and
this
device.
Okay
from
a
controller
perspective,
then
you
will
download
the
specific
configuration
to
the
device,
but
the
network
model
is
when
it's
referred
to
network
is
that
applies
to
several
devices,
okay,
that
was
the
and
to
be
able
to
help
in
managing
several
devices.
At
the
same
time,.
A
Okay,
it
looks
like
jason,
doesn't
have
anything
more
there,
so
in
general,
it's
a
judgment,
call
of
whether
you
augment
or
revise
right
and.
A
Into
some
of
the
details
to
figure
that
out
and
then
when
we
start
getting
into
the
details,
we'll
also
figure
out
what
the
details
are
of
device
relative
to
network
and
if
there's
a
existing
model,
you're
augmenting,
all
of
those
getting
to
those
details
will
help.
You
answer
the
questions
on
your
slide
right
now.
A
You
just
have
you
know
an
empty
section,
so
it's
a
little
hard
to
evaluate
or
give
you
a
definitive
answer,
but
you
know,
as
a
general
rule,
if
you
can
it's
a
judgment
call,
but
if
you
can
augment
and
you're
adding
optional
capability,
augment
is
the
way
to
as
a
separate
rfc
is
definitely
the
way
to
go.
If
you
are
looking
for
revising
the
core
behavior
that
everyone
needs
to
adhere
to,
then
you
definitely
want
to
rev.
A
The
the
motivation
that
you've
given
here
is
just
right
for
the
presentation,
I
think,
for
the
draft,
rather
than
focus
on
motivation,
focus
on
what
you're
actually
going
to
do
so
focus
on
the
new
capabilities
you're
defining
in
the
draft,
describe
them
and
then
throw
out
some
proposals,
some
details,
and
then
we
can
really
jump
into
asking
this
question.
So
you
know
from
I
I
I
don't
think
you
know
we
haven't
heard
anyone
jump
in
and
say
you
know.
This
is
completely
wrong
down.
A
What
we've
heard
is,
is
you
know
looking
at
you
know
the
best
way
to
do
it,
but
again
having
details
will
help
us
understand
help.
The
working
group
judge
whether
it's
something
that
they
want
to
a
support
and
b,
what's
the
best
best
mechanism
to
implement
it.
H
Okay,
so
we
can
update
the
draft
with
with
a
we
can
go
in
the
we
can
propose
in
the
drive
that
if
you
want
the
two
directions-
okay,
one
that
implies
breaking
a
little
bit.
What
was
there
and
the
one
that
we
would
augment?
H
A
That's
great,
thank
you.
Jason's
in
queue
we're
a
little
over
time,
but
jason
you
can
have
the
last
word.
D
Just
a
really
quick
question
is
there
is
any
of
the
functionality
you're
proposing
here
means
stateful
firewall
behavior?
Is
it
all
stateless.
A
Thank
you
for
the
presentation
look
forward
to
seeing
the
next
revision
as
well
as
future
discussion
on
the
list
with
that
we're
actually
out
of
time
and
thank
you
all
for
participating
in
this
meeting,
look
forward
to
possibly
seeing
some
people
in
person
the
the
next
meeting.
There's
you
know
rumors
that
that
might
be
hybrid.
So
thank
you
all
for
contributing.