►
From YouTube: IETF104-NETCONF-20190325-0900
Description
NETCONF meeting session at IETF104
2019/03/25 0900
https://datatracker.ietf.org/meeting/104/proceedings/
B
C
C
There
is
a
course
of
audio
the
Medeco.
There's
being
so,
we
have
a
couple
folks
on
Medeco
and,
of
course,
there's
a
virtual
microphone,
so
you
can
come
to
the
virtual
microphone
to
speak
there,
typically
or
in
past
Oh
actually
forever.
It's
been
the
case
that
we've
asked
for
ether
pad
note-takers,
but
we're
not
going
to
do
that
this
meeting
or
any
well,
we
don't.
C
Instead,
we've
found
that
transcribing
the
YouTube
video
audio
and
then
repairing
it
to
get
a
perfect
transcription
is
much
more
effective
than
actually
having
people
take
ether
pad
minutes,
so
we're
no
longer
going
to
be
taking
either
pad
minutes,
but
we
do
need
a
jabber
scribe.
So
if
somebody
could
please
volunteer
to
be
on
jabber
and
subscribe
to,
the
drivers
cried
looking.
Somebody
volunteered
to
be
JavaScript.
C
C
Okay,
so
we'll
have
to
ask
for
support
to
see
if
there's
actually
a
problem
with
the
Jaguar,
but
we
do
have
me
taco
working,
so
we
can
at
least
work.
We
can
go
forward
with
that.
Oh
you
still
have
them
in
a
ticket.
I
thought
we
said
we
weren't
gonna.
Do
them.
C
So
that's
it
for
there,
okay!
So
since
last
times
meeting
we
have
published
a
number
of
RFC's
there's
RFC
85
25,
which
is
yang
library,
RC,
85
26,
which
is
the
Metcalfe
extensions
to
support
the
nmda
and
RFC
85
27,
which
is
the
rest
comp
extensions
to
support
the
nmda.
This
is
a
major
achievement.
The
local
group
should
be
very
proud
of
their
accomplishment
and
I'd
like
to
sort
of
kick
off
a
round
of
applause
to
everyone.
B
All
right
so
as
far
the
status
of
the
chartered
working
group
items,
the
yang
pushed
suite
of
drafts,
they
were
sent
into
IC
and
currently
I
believe
the
last
status
update
was,
and
a
last
call
has
been
issued
on
the
whole
suite
of
drafts
and
I
guess
is
C
will
be
picking
up
and
providing
reviews.
So
the
authors
should
be
prepared
to
respond
to
those
comments.
I.
B
The
net
con
risk
on
client
saw
the
suite
of
drugs
that
Kent
will
be
talking
about,
is
still
work-in-progress,
we'll
get
a
status
update
from
em
and
decide
the
next
steps
the
European
draft.
We
received
some
pushback
in
ITF
103
on
the
draft,
so
for
now
we
have
put
it
on
hold
and
been
with
the
ultimate
intention
that
we
wanted
to
place
it
with
the
multiple
streams
draft.
B
So
here's
the
agenda
for
today's
meeting.
We
have,
of
course,
a
whole
suite
of
drafts
that
our
working
group
items,
but
there
are
two
new
drafts
that
can
full
be
presenting
that
we
probably
will
take
a
roll
call
on
to
figure
out
whether
we
won't
adopt
them
as
the
troop
items
or
not
in
this
particular
presentation.
B
B
C
C
Okay,
so
just
quickly
I,
don't
want
this,
my
only
status
light,
but
the
sense
ITF
103.
All
the
drafts
were
updated
as
a
set
progress
is
made
on
the
two
issues
that
were
discussed
before,
and
this
presentation
just
focuses
on
those
two
issues,
plus
a
few
additional
issues
have
surfaced
and
we're
first
in
discussion,
beginning
in
discussion,
1
about
finalizing
the
crypto
types
identities,
acetone,
horn,.
D
Okay,
good
morning,
everyone,
my
name,
is
Ivo
Roma
highway,
actually
yeah
color
of
this
a
crypto
Java
types
crap.
This
ratios
change
the
limit.
You
know
that's
two
emergencies.
The
main
chains
are
actually
we
add
in
way
more
categories
and
change.
The
name
of
a
symmetric
key
encryption
to
assume
the
key,
at
least
for
the
details.
Please
refer
to
the
cottage
south
yeah
I
wa.
This
is
this
slide
shows
the
translators
of
the
visual
types.
We
actually
classify
the
crypto
algorithm
into
some
classes,
including
hash,
a
symmetric
key
algorithm,
the
Salam
yeah.
D
So
I
would
like
to
ask
two
questions
to
the
floor.
So,
firstly,
is
either
any
suggestion
to
the
classification
of
the
algorithm.
That
means
is
the
current
algorithm
classification
messages.
Yeah
good
are
there.
There
is
a
better
message.
Second
is
yeah!
You
there
new
category
to
be
in
the
classification
yeah.
E
E
E
Probably
going
to
happen
in
an
eye
on
our
edge
astray
in
the
corresponding
in
our
history
is
that
this
algorithm
will
be
labeled
as
deprecated
in
eye
on
our
terms,
but
since
apparently
deprecated
means
something
else
in
in
in
the
yang.
This
could
be
a
problem
I
believe,
because
currently
the
discussion
was
the
deprecated
items
basically
must
be,
must
be
implemented.
Anyways,
okay,.
C
So
first
off
I
think
you're
saying
that
it
rule
right
now
the
draft
would
be
published
with
knows
it
was
status
current
and
then,
as
in
when
INR
deprecates
an
algorithm,
we
would
have
to
republish
the
module
with
status
deprecated
and
button
and
your
point,
but
my
point
is
that
it
really
doesn't
work
the
way.
That's.
C
An
abusive,
even
more
deprecated
means,
but
I
think
that
we
would
move
forward
with
cognate
deprecated
because
of
the
yang
burgeoning
rules
that
we're
adopting
and
then
we
could
then
do
a
subsequent
update
to
move
it
to
up
sleep
to
match.
The
full
definition
of
INR
and
in
the
interim
implementations
could
do
a
deviation,
module
to
say.
C
E
F
So
Martin
Buckland
about
not
being
able
to
deviate
an
identity,
I
mean
you,
don't
have
to
implement
all
identities
in
a
module
right
and
there's.
We
have
an
issue
with
that.
How
do
you
actually
tell
the
client
which
identities
you
have
implemented?
So
that's.
That
is
a
young
next
issue,
so
I
think
that
part
is
being
covered.
Okay
and
also
we're
talking
about
going
directly
to
obsolete.
So
maybe
in
this
case
it
would
make
sense
to
go
directly
to
obsolete.
You
speak.
G
Within
current
in
that
idea
of
the
most
widely
used
and
most
low
your
poster
algorithms,
we
listed
there,
we
don't
include
some
duplicative
and
such
as
md5
or
3d
year,
something
just
our
promise,
but
we
also
notice
that,
with
the
tons
go
on
yes,
this
some
of
the
algorithm,
we
will
be
older
and
we
have
not
be
safe.
So
actually
we
I
think
with.
Maybe
Ken
has
some
solution
for
this.
Maybe
we
can
updated
based
on
the
ocean
young
ocean,
a
mechanism
to
to
solve
this
problem.
Yeah
and
I
hope
your
question.
We
have
considered.
A
C
The
two
new
drafts
that
they'll
be
in
a
second
discussion,
were
right
now
on
the
first
discussion.
So
can
you
hold
that
comment
till
then?
Can
you
go
back
to
the
next
slide?
Please.
You
know
on
the
first
question:
is
there
any
suggestion
for
regarding
the
classification
of
the
number
of
base
identities
that
are
currently
being
defined?
Are
they
sufficient
should
there
be
more
or
less
so
far,
I've
not
heard
any
responses
to
that
particular
question.
C
Yet
is
there
anyone
having
suggestion
for
okay,
I,
think
so
my
own
as
a
contributor
I
I
find
them
to
be
sufficiently?
They
are
currently
being
used
by
a
number
of
the
Association
to
a
lesser
or
as
I
mean
we
started
this
because
we
were
trying
to
use
them
for
the
purpose
of
the
Association
TLS
drafts.
C
We
need
to
ensure
that
gets
complete,
completely
implemented,
and
but
so
long
as
that's
done
then
from
our
own
consumption
perspective
they
would
be
sufficient.
We
will.
The
chairs
will
ask
for
early
sector
review
of
this
draft,
since
is
so
heavily
enthralled
in
security.
Consider
concerns
so
so.
We'll
also
get
that
level
of
review
from
security
director.
C
C
So
there's
just
the
TCP
of
HTTP.
There
is
no
HTTPS,
because
you
can
see
that
the
rest
comp
client
server
is
using
the
groupings
from
both
TLS
as
well
as
HTTP.
If
you
had
an
application
that
just
wanted
to
be
HTTP,
they
don't
use
the
groupings
from
TCP
and
HTTP,
so
you
can
the
application,
that's
being
a
consumer.
The
groupings
can
decide
the
stack
of
protocols,
that's
trying
to
use
to
sort
of
go
into
that
a
little
bit
more
I'm
sort
of
following
the
the
good,
bad
and
ugly
triple
here.
C
I
give
this
as
the
hazard
versus
is
a
object-oriented
relationship.
I
think
this
is
good.
It
enables
the
application
level
modules
to
compose
the
stack
of
use
of
statements,
so,
for
instance,
if
here
an
HD
client,
you
would
use
the
TCP
client
and
the
HTTP
client.
If
you're
an
HTTP
client,
you
would
use
the
TCP
clients,
the
TLS
client
and
the
HP
client.
C
If
you're
an
HTTP
call
home
client,
you
use
the
TCP
server
and
the
HTM
TLS
client
and
the
HTTP
client
seeking
build
your
stack
based
on
what
kind
of
client
or
server
you
are,
so
that
it's
very
flexible.
Also
this
being
the
hazard
versus,
is
a
avoids
what
I've
learned
originally
as
being
called
devil's
diamonds.
This
is
the
old
Scott
Meyer,
this
effective
C++
book.
C
But
basically
it's
a
multiple
inheritance
problem
where,
if
you're
using
groupings
from
two
different
sources,
but
each
of
those
groupings
are
using
a
common
grouping,
then
you
can
possibly
get
the
same
set
of
definitions
more
than
once,
which
is
not
what
you
really
want.
So
by
using
this
has
a
approach
it
avoids
della
diamonds.
You
don't
have
that
okay,
so
that's
the
good.
The
bad
top-level
grouping
nodes
are
in
the
same
namespace
and
thus
may
conflict.
H
Like
stupid
comment,
go
back
there,
caller
didn't!
Oh
damn
Bogdanovich.
The
color
schema
is
unreadable
if
you're
not
really
close
to
here.
Okay,
so
I.
C
C
Okay,
so
again
to
demultiplex
the
names
you
can
either
even
do
one
or
two
things
you
can
either
prefix
the
top-level
node
names
such
as,
for
instance,
having
the
grouping
tcp
client
grouping,
there's
leaf
remote
address,
which
is
not
prefix.
There's
container
tcp
keep
alive
so
that
one
is
prefixed
by
tcp
and
then
I
have
an
example.
Any
data,
TCP
foo
and
then
for
TLS
client
grouping
I
have,
as
example,
TLS
keep
alive.
So
you
see
it's
prefixed
by
TLS
short
and
then
HTTP,
so
that's
basically
prefixing
each
top-level
node
inside
the
grouping.
C
So
that's
option
one
option
two
is
instead
to
wrap
the
entire
contents
of
the
grouping
inside
of
container
which
the
king
of
the
containers
prefix.
But
then
it
enables
all
the
individual
nodes
that
were
previously
top-level
to
not
have
to
be
prefix.
So
that's
the
I.
Don't
think
this
is
a
big
issue.
We
just
need
to
decide
which
approach
we
want
to
take.
C
Okay,
I'll
take
that
one
to
the
list
and
the
ugly
okay,
so
should
the
Netcom
prescott
urls
also
follow
the
has
a
pattern
us
do
we
care
about
possible
protocols
built
on
top
of
net
con
from
restaurant?
So
currently
we
have
TCP
HTTP
till
sorry
at
TLS
and
ssh
they're,
all
basically,
these
little
groupings
that
are
encapsulating
the
configuration
parameters
for
a
single
socket
right,
but
then
we
have
the
neck
off
rest
comp,
which
are
more
they're,
not
just
a
single
socket
they're
more
like
a
list
of
devices
or
a
list
of
endpoints.
C
So
presumably
we
could
isolate
that
which
is
configured
per
socket
or
session
from
the
larger
multi
socket
multi-session
model,
supporting,
for
instance,
listen
and
call
home,
so
I'm
thinking
what
we
could
do.
Okay,
let
me
be
clear,
currently
the
grouping
if
you
were
to
do
an
instance
of
grouping
of
the
Netcom
client,
a
client
protocol.
Yes,
I,
start
grouping
an
account
grouping.
What
you
get
is
something
that
can
either
have
a
make
a
connection
to
a
list
of
endpoints
or
actors
that
call
home
recipient
right.
C
We
could
keep
that
grouping,
but
also
have
another
grouping
which
really
is
just
representing
a
single
Netcom
client
in
the
configuration
parameters,
for
it
so
and
be
very
skinny
like
Netcom
session
timeout
might
be
the
only
configurable
parameter
there
right,
it's
very
small,
but
it's
really
just
the
configuration
parameters
for
a
single
Netcom
session
and
then
that
grouping
could
be
used
by
the
larger
grouping.
So
if
you
wanted
to
little
higher
level,
application
wanted
to
compose
its
own
stack
and
a
some
where
net
comp
was
in
that
stack.
C
I
Tim
Kari
Nokia,
so
I
think
there's
some
value
to
this,
particularly
when
we
talk
about
proxies
like
if
I
had
a
proxy
between
you
know
the
example
would
be
a
proxy
between
arrests,
cough
and
a
net
cost.
So
I
think
there's
some
there's
some
usage
here
that
that
probably
would
make
sense
that
we
that
we
incorporate
Thanks.
C
Thanks
Jim
so
actually
with
proxy
and
I'm
thinking
when
you
said
that
I'm
thinking,
HTTP
proxy
yeah,
no,
not
H
so
they're
inside
the
while
you're
stepping
back
to
microphone
inside
the
HTTP
client
server
model.
In
fact,
there
is
one
of
configurable
parameters
of
proxy.
So
if
you
HP
client
want
to
connect
to
connect
directly
at
the
endpoint
or
via
proxy,
now.
I
B
Before
we
move
there,
one
note
as
soon
as
the
etherpad
link
in
the
agenda
is
concerned,
it's
not
the
correct
one.
I
just
sent
one
on
the
net
mailing
list
use
that
if
you
want
to
provide
any
comments,
there
are
people
who
are
writing
notes.
It
needs
bad,
and
so
before
we
move
to
the
discussion
number
three.
B
The
question
for
the
working
group
is
that
I
think
in
103
there
was
kind
of
a
poll
taken
to
figure
out
if
there
was
interest
in
working
or
adding
two
more
drafts
into
the
stack
of
drafts
that
you
have
specifically
to
address
the
question
of
TCP
and
HTTP,
so
keep
lights.
Yeah.
Thank
so
the
question
for
the
working
group
is:
is
there
enough
interest
in
the
working
group
to
maybe
start
an
adoption
call
for
those
two
particular
drafts
that
are
not
workgroup
items
as
yet
a
show
of
hands?
C
G
B
B
C
C
J
It's
rider
one
question,
so
we
see
in
the
web
scale.
Oh,
we
got
option
going
towards
quick.
So
do
we
have
anything
any
thoughts
or
odd,
maybe
moving
also
in
the
direction
of
quick,
and
we
will
combine
all
the
benefits
of
getting
quick
in
terms
of
security
round-trip
times
whatever
or
is
it
so
I'm
just
asking
if
there.
C
Of
HTTP
and
so
it'd
be
kind
of
like
how
can
we
Primrose
the
HTTP
model
just
and
for
that
matter?
Currently
the
HP
model
doesn't
make
distinctions
between
11.11
or
two
to
do
so.
Maybe
we
need
to
think
about
that,
and
so
please,
maybe
you
can
send
a
message
to
lists
and
take
it
up
there.
Okay,
great!
Thank
you.
Yeah.
B
C
So
in
the
course
of
making
these
updates
I
kind
of
unconscious
a
few
issues,
first
is
protocol.
Specific
parameters
are
per
socket,
which
can
lead
to
some
redundancy
in
the
model,
so,
for
instance,
the
TCP
keepalive
must
be
set
for
each
client
and
server
if
you're,
configuring,
anakov,
client
or
server
and
areas
connecting
to
a
number
of
endpoints
each
of
those
endpoints
have
to
have
their
TCP
keepalive
configuration
settings
set
for
each
one
of
them,
because
it's
like
that's
the
way
the
models
working,
we've.
C
Okay,
so
to
be
fair.
This
is
inherent
in
any
list
of
like
items.
So
anytime
you
have
a
list
of
items.
It's
not
unique
to
this
to
these
models
at
all.
If
your
list
of
items
and
there's
redundant,
you
know
information
across
them.
You
know
that
this
this
can
happen
proposed
fixes
to
do
nothing
and
instead
wait
for
a
TBD
template
team
mechanism.
C
At
some
point,
somebody
should
the
working
group
or
perhaps
net
mod,
should
define
a
mechanism
to
enable
some
snippet
of
configuration
to
be
applied
to
groups,
or
you
know
more
than
one
instance
of
a
another
model,
and
then
that
would
allow
for
common
configurations
to
be
factored
out
defined
once
and
then
applied
to
the
subset
of
the
particular
list
entries
that
are
inheriting
it.
This,
in
fact,
is
one
of
the
issues
in
being
next
number
18,
which
currently
has
importance
medium,
which
is
to
effectively
reproduce
junipers,
apply
groups
statement.
C
Okay,
second
issue:
the
keep
live,
config
may
be
present
for
periodic
connections.
Currently,
I
don't
know
if
people
remember
but
a
while
back,
we
previously
removed
that
keep
lives
from
periodic
configurations.
We
stated
that
while
periodic
connections
are
reddish
and
you
don't
need
to
keep
lives
to
keep
them
up,
you
only
need
keep
lives
for
persistent
connections,
so
we
removed
the
keep
alive
configurations
from
periodic
connections.
But
now
the
way
the
model
is,
the
keep
lives
are
being
configured
at
the
socket
level,
and
so
it's
being
configured
the
socket
level.
C
However,
I
think
as
I
was
creating
these
slides
I
was
thinking
to
myself
the
proposed
fix.
We
could
use
a
must
statement
where
we
say
you
know
the
keepalive
configuration
must
not
be
configured
when
you're
configuring
a
periodic
connection.
Something
like
this.
Yes,
okay,
next
issue
are
all
the
protocol
specific
keepalive
models,
correct,
so
Tim
I,
don't
know
if
you've
looked
at
them.
C
The
various
configurations,
but
so
currently
the
the
TCP
keepalive
configurations
are
very
much
like
the
POSIX
keepalive
mechanism,
there's
a
three
tuple
of
values,
but
then
there's
the
SSH
key
Politis
and
the
TLS
keep
lives
an
HTTP
keeper
lives
and
each
of
them
may
be
a
little
bit
different,
because
each
protocol
has
a
different
way
of
supporting
keep
lives,
I.
Just
so
I
think
TCP
is
okay.
Actually
you
know
model
it
directly
off
of
POSIX,
but
the
others
I'm
a
little
bit
uncertain
if
anybody's
looked
at
them.
As
concerns
good.
I
C
C
Good
number
four:
is
there
any
desire
for
other
protocol
specific
configurations,
some,
for
instance,
HTTP
proxy
settings
a
current?
Currently
you
know
the
groupings
are
per
socket
configurations,
I'm,
trying
to
keep
it
to
be
the
minimum
necessary
for
what
we
need,
which
is
really
a
transport-related,
so
I'm
not
trying
to
configure
every
possible
knob
on
HTTP
server
or
or
an
SSA
server
I'm,
just
trying
to
keep
to
the
bare
minimum,
but
I
do
think,
for
instance,
HTTP
proxy
settings.
C
You
know
it's
a
very
common
thing
for
a
client
to
need
to,
for
instance,
to
go
out
through
a
proxy,
so
I've,
that's
kind
of
transport
related
I
feel
like
maybe
that's
an
example
of
one
that
we
should
add
anyway,
I
don't
know
if
any.
Well,
since
no
one's
read
the
drafts,
you
probably
don't
have
suggestions
about
what
might
be
missing,
but
just
be
aware
that
we're
gonna
have
to
have
a
conversation
about.
You
know
there
might
be
some
issues
missing.
C
Http
proxies
one
number
I'm
thinking
about
right
now:
I,
don't
have
any
others
in
mind,
but
if
other
people
are
looking
at
it
and
you
think
that
there's
something
missing,
please
let
us
know
five,
not
all
HTTP
off
schemes
are
currently
defined.
So
if
you
look
at
the
HTTP
draft,
specifically
HP
supports
six
I
think
authentication
schemes.
There
may
be
more
sorry,
there
might
be
more,
maybe
eight,
but
and
I've
only
actually
defined.
C
Currently
the
configurations
for
three
of
them
I
think
the
remaining
of
them
are
just
these
little
fix
me
comments,
there's
actually,
zero
content
within
the
container
definition.
They're
just
ran
out
of
time.
So,
if
you're
looking
at
it
and
wondering
what's
going
on,
that's
why
six?
Why
do
we
have
special
breakout
groupings
again?
So
I
think
everyone
probably
saw
the
email
thread
I
had
on
list
just
recently
with
balázs,
the
other
blush
from
Ericsson
and
and
so
I
think.
The
net
result
of
that
is
that
we're
no
longer
needing
to
have.
C
C
B
C
C
A
Hello,
I'm
balázs,
Tanya
from
Ericsson
and
I'm
presenting
this
draft,
which
was
in
workgroup
it's
a
workgroup
draft
for
more
than
one
year,
but
actually
it
was
sleeping
in
a
way
because
we
had
other
more
important
things
to
do
really.
Yank
push
and
now
I
am
trying
to
restart
the
work.
It
is
needed
stuff,
but
yes,
it
is
based
on
the
anchor,
so
that
has
to
be
first.
A
The
base
problem
was
that
yank
push
has
the
unchanged
capability
notifications.
They
use,
modify
change
whenever
it
happens
immediately,
but
that's
a
very
difficult
proposal.
For
some
reasons
you
might
have
counters
that
change.
Every
microsecond
you
might
have
meaningless
changes
or
many
times
you
need
to
implement.
Schema
note
by
schema
knows
by
schema
not
one
by
one
that
only
change
notification
capability
and
it
will
take
time
for
that
to
happen
so
practically,
even
if
we
declare
that
we
generally
support
on
change
notifications
in
practice.
A
To
make
this.
We
don't
want
one
indication
for
each
data
node.
So
practically
we
have
a
default
on
the
top
level,
which
means
that
generally
I
support,
unchanged
notifications
for
config
and
or
for
state
data.
Config
and
state
in
many
implementations
have
handle
differently,
and
if
there
is
some
specific
part
of
the
datastore
that
is
doesn't
follow
these
default
values,
then
that
might
have
a
known,
not
own
specification,
whether
it
supports
no
unchanged
notifications.
A
Also,
we
have
some
other
cap,
not
no
capacity
related
capabilities
that
are
not
related
to
the
unchanged,
but
generally
to
yank
push,
and
the
idea
is
that,
yes,
this
should
be
available
online
restaurant
at
home,
but
also
for
management
system.
We
need
this
data
early
before
the
nodes
are
implemented
before
the
nodes
are
both
so
Yang
instance.
Data
would
be
the
vehicle
for
that.
A
This
is
the
data
model.
Top
part
are
the
general
capacity
related
problem
items?
How
many?
What
dampening
periodic?
We
can
support,
how
many
objects
per
update,
so
how
much
notifications
can
there
the
server
really
push
out
the
other
one
is
the
to
default.
The
lower
part
is
about
unchanged
notifications,
one
for
config
one
for
state,
and
this
unchanged
notification
capability
list
is
for
each
node.
You
can
specify
that,
yes,
generally,
it
is
supported
practically
for
this
specific
part.
Not
there
have
been
some
changes
since
the
last
IETF
added,
more
capabilities.
A
K
K
A
A
M
A
Think
unless
I'm
messed
up,
but
there
should
be
small
slides.
The
main
point
is
that
this
man
is
that
having
default
values
on
and
they're
having
multiple
values
that
indicate
specific
part
of
the
models
work
this
way
or
that
way,
that's
unseen,
somewhat
complicated
I
promised
to
some
of
you
that
I'll
add
examples
in
this
slide
outside
and
in
the
draft
to
make
it
more
simple.
To
understand.
A
One
point
is
that
what
categories
do
we
have
for
the
support
or
non
support?
One
was
an
open
issue
that
do
we
need
separate
indications
per
data
store,
so
some
ones
there
is
that
their
implementation,
with
supporting
notifications
on
change,
notifications
on
the
running
data
store,
but
not
on
the
candidate?
A
Yes,
I
I
can
accept
that
and
then
that
will
be
added
to
the
data
data
model
that
you
can
have
general
capabilities
for
all
data
stores
or
you
can
have
it
birth
data
store
separate
city.
The
other
was
that
this
logic
that
default
may
be.
Then
one
container
says
that
that's
it
I
say
that
default
is
support,
kept
us
unchanged,
but
the
next
container
says
I,
don't
support
unchanged
on
statistics,
because
that's
it's
good
and
then
maybe
under
that
I
say
that
the
default
was
support.
A
The
statistic
container
said
no
support,
but
son,
specifically
one
or
two
counters
I
do
support
it.
So
these
three
levels
of
that
say
the
default
container
or
this
that
contains
it
and
maybe
on
the
individual
leaf,
will
be
explained.
The
main
purpose
of
this
is
that
we
don't
want
the
hundred
item.
Long
list
of
individual
knows
that
support
it
doesn't
support.
Support
doesn't
support,
so
you
need
to
have
this
hierarchical
and
also
that
the
default
value,
whether
it
is
I
support
them
unchanged.
A
A
Unchanged,
notifications
for
in
objects
counters-
because
that's
that
might
be
the
case
for
some
some
others,
my
company,
but
others
as
well-
said
that
no
unchanged
clarifications
are
important
but
somewhat
difficult,
at
least
for
state
data.
So
for
each
group
of
common
counters
state
data,
each
group
of
individual
items
will
indicate
separately
when
we
start
supporting
unchanged
notifications.
So
the
default
in
one
case
would
be
support
for
everything
and
then
some
exceptions
in
other
case
defaults
for
nothing.
But
yes,
support
for
some
exceptions.
L
A
D
A
N
And
then
the
second
question
I
have
is
that
in
here.
Yes,
you
built
the
parallel
structure
that
represents
the
properties
of
what
can
be
whether
the
subscription
rates,
how
things
are
I,
wonder
whether
Harries
that's
going
to
be
be
used
and
whether
it
be
easier
to
have
like
an
RPC
mechanism
or
something
that
allows
you
to
query
a
particular
path
and
say:
what's
the
subscription
properties
for
this
path.
So
I,
it's
different
mechanism,
not
sure
works,
but
it's
just
a
thought.
I
think.
A
You
do
need
this
data
model
because
of
the
offline
need,
yes
and
I
would
say,
that's
a
kind
of
yeah.
What
whatever
you
like,
are
PC
or
data
generally
I
prefer
doing
this
with
data,
and
that
gives
you
a
and
then
and
they
there's
anyone.
If
you
think
we
need
some
art
pieces
to
make,
it
seem
more
simple.
We
can
discuss
that,
but
I
don't
feel
C
the
needs.
O
So
I'm
not
rest,
as
we
discussed
yesterday
by
lash,
but
I
want
to
make
sure
I
repeat
this.
For
the
group
there
are
three
different
use
cases.
The
first
one
is
that
an
entire
data
store
is
unchanged
capable.
So
we
want
to
be
able
to
write
this.
The
second
one
is
a
specific
schema
note,
which
is
unchanging
capable,
like
ok,
want
to
be
able
to
do
this,
but
the
the
the
next
one
is
also
alright.
O
A
We
don't
my
draft,
doesn't
support
data
stores.
Yet
I
will
ask
that
and
we
have
this
node
instance,
identifier
that
was
borrowed
from
access
control,
which
allows
you
to
specify
the
key
values
if
you
want,
but
it
allows
you
to
to
omit
the
key
values,
meaning
all
so
I
think
after
datastore
update
it
will
be
supported
what
you
are
very
good.
O
P
Eric
Voigt
Cisco
I'm
definitely
a
fan
of
this
work.
This
is
very
good.
One
thing
that
it
would
be
good
to
explain
a
little
bit
more
is
the
max
number
trying
to
figure
out
if
it's
for
all
updates,
whether
it's
for
a
certain
type
of
interface
sets
whether
it's,
whether
it's
for
different
parts
of
the
data
store,
be
good,
so
I
don't
have
any
strong
opinions
on
what
it
should
be,
but
just
additional
description
on
max
number
would
be
good.
I.
A
F
A
F
F
A
Could
build
this
out
to
a
full-blown
filter,
managed
by
expert
or
subtree,
but
I
think
that
would
be
overkill.
You
could
also
say
that
for
the
key
values,
I
love
regular
expressions.
For
example,
interfaces
are
e
th
/
whatever,
but
then
not
everyone
will
have
that
conversion.
So
I
I
don't
see
a
solution
that
would
make
me
happy
and.
O
But
I'm
speaking,
actually
they
are
to
use
cursors.
For
the
instance.
Draft
and
Bosch
there
is
like
I
need
the
instance
at
the
improv
at
the
design.
Time
and
I
agree
with
you
Martina.
There
is
no
way
to
know
about
instances,
and
there
is
like
a
second
one.
A
second
use
case
with
instance,
which
is
I,
don't
want
to
provide
it
like
with
a
yang
module
on
the
server,
but
it
will
be
offline.
This
one
could
potentially
be
solved,
but
again
in
that
situation,
I
agree.
Q
Rashaad
Raman
Cisco,
so
Bella
is
just
I
just
wanted
to
mention
the
comment
I.
Thank
you
by
email
yesterday,
this
my
understanding
is.
This
would
be
very
useful
if
it's
unchanged
capable
itself.
If
that
path
is
not
unchanged,
capable
it's
not
as
useful,
because
then
you
need
to
yeah.
So
it's
perfectly
fine
to
have
that
actual
data
to
be
in
as
a
node
selector
in
the
data
which
is
being
returned.
Q
L
C
R
Hello,
one
in
challenge
over
muhuali
and
I'm
going
to
talk
about
the
solution
alone,
subscription
to
multiple
stream
originators,
and
this
is
the
distributed
extension
to
the
existing
young
push
solution
and
it
provided
is
through
the
data
collection
mechanism
that
allows
multiple
data
streams
to
be
managed
by
a
single
subscription
and
per
working
group
discussion.
This
will
support
this
well
be
trans
for
the
independent
and
we
identify
the
true
use
cases.
One
is
the
data
collection
from
devices
with
main
border
and
the
line
cars.
R
We
see
existing
solution,
push
a
solution,
consider
only
one
pushes
over
residing
in
the
main
board,
so
that
are
crafted
from
deny
called
an
aggregated
in
in
the
maple
just
so
that
that
the
main
board
could
be
easily
become
the
the
bottleneck.
So
we
request
distributed
data
fraction,
medicine
that
can
directly
push
data
from
line
cards
to
the
crafter.
R
Okay,
here's
another
use
case
about
the
iot
of
narrow
and
I
just
gonna
skip
x
and
here's
the
solution
overview
and
I
think
we
we
also
introduces
this
last
time.
The
subscriber
whale
sends
the
Kuroko
subscription
to
the
publish
to
the
master
and
the
master
decomposed
their
decomposed,
the
subscription
through
the
component
subscription
to
the
n
sensual
agent.
R
So
the
agent
can
push
data
to
activate
to
the
receiver,
and
here
we
have
a
function,
that's
the
connection
between
the
master
and
the
agent
already
exist,
and
the
master
knows
how
to
decompose
the
how
to
decompose
the
subscription
to
component
subscriptions.
Somebody
may
have
may
have
interests,
abouts
the
interaction
between
the
master
and
an
agent,
and
it
would
be
another
protocol
for
the,
for
example,
for
the
agent
registration,
the
agent
management.
But
it's
right
now,
I
was
at
office
scope
of
this
draft.
R
Publications
need
to
compose
the
data,
so,
firstly,
the
reserved
the
receiver
can
recognize
data
recalls
associated
with
one
subscription
according
to
the
subscription
ID
and
then
the
receiver
assembles
data
generator
at
one
at
the
same
time,
Puran
based
on
the
recording
ham
and
then
the
receiver
also
need
to
know
the
number
of
component
subscriptions
for
the
insecurity
of
the
data.
So
we
propose
to
add
a
list
of
publisher
ID
to
the
subscription
state
started
and
the
subscription
modified
notifications.
R
The
publisher
need
to
send
the
subscription
state
change
notifications
to
the
to
the
character.
Here
we
have
two
options.
One
is
that's:
each
agent
send
its
own
notification
to
the
subscriber,
but
we
realize
the
character
actually
do
not
have
the
detail,
information
about
the
resource
and
the
location.
R
You
know
to
support
the
multiple
transport
we
re-examine
the
subscriber
notification
Yamoto,
it's
already
supported
there
and
it
provides
options
for
the
transport
for
the
encoding
and
the
detailed
information
about
the
receiver.
So
I
think
it
is
enough
for
four
for
this
for
this
solution
to
support
multiple
transport-
and
there
are
some
other
questions.
R
Firstly,
this
solution
is
based
on
is
generally
based
on
the
configure
the
subscription
we
here's
a
question:
do
we
need
to
consider
the
dynamic
a
subscription
I'm
I'm,
not
sure
if,
if,
if
the
dynamic,
a
subscription
concept
applied
here,
because
in
principle,
the
subscription
transportable
totally
different
from
the
publication
transport
and
sessions
and
some
other
question
like
is
there
any
other
issues
need
to
be
considered
for
this
distributed?
Extension
for
the
yunkish
work.
C
Okay,
so
Kent
is
a
contributor,
so
first
off
to
the
first
first
question
and
I,
don't
think
so
I
mean
in
theory
we
should.
But
given
that
we're
talking
about
line
cards
and
a
lot
of
data
for
a
dynamic
subscriber
to
ask
for
that
much
data,
it
doesn't
make
terrible
yeah
I
think
you
would
want
to
configure
it
more.
But
if
it's,
if
it
can
easily
be
done
and
great
if
it's
difficult
to
know
so.
C
And
then
otherwise,
I
think
everyone
just
needs
to
be
aware
that
what
we're
trying
to
support
is
that
this
is
a
notice
like
from
the
English
perspective.
This
is
just
another
is
enabling
and
the
note
of
drafts
to
be
configured
started
the
note
of
transports
to
be
configured
on
a
per
line
card
basis.
C
I
Tim,
carry
no
kiss
so
I
do
have
a
couple
questions,
because
it's
I
think
the
draft
as
you
presented
it
now
has
gone
beyond
elements
that
are
in
close
collaboration
with
Jeff
with
each
other.
In
other
words,
a
line
card
on.
You
know
the
master
board.
It
sounds
like
you
talked
about
some
IOT
nodes
that
actually
will
go
across
the
network
and
so
I
guess.
If
we
extend
the
draft
beyond
that
enclosed
ecosystem
right,
then
the
questions
come
up
to
say:
hey,
how
does
how
does
an
agent
discover
a
master?
I
R
N
Rob
Wilson
Cisco,
so
I
think
I
echo
Tim
Tims
comments
there.
Actually
there
may
be
two
separate
problems
here
and
maybe
they
have
necessary
quite
the
same
solution
and
generally
I
think
that
the
overall
problem
of
getting
data
offline
cards
efficiently
is
a
valid
about
the
use
case.
I
think
that's
that
matters.
People
are
doing
that
so
I
think
the
problem
that's
being
roughly
described
here
is
is
that
it's
a
good
one
to
solve
I
done.
Read
the
solution.
Drafts
I,
don't
know
whether
I
agree
with
that
or
not.
But
I
do
think.
P
Also,
to
echo
also
to
echo
others
comments.
This
is
an
important
problem.
I've
read
the
solution
document.
It
is
a
reasonable
solution,
as
for
dynamic
subscriptions,
I
agree
with
Kent
if
we
can
find
a
way
to
get
it
and
it's
useful,
but
the
times
I'm
seeing
it
used
out
in
deployments
now
is
mostly
for
configured
subscriptions.
S
Donnas
one
overall
comment
about
environment
in
where
this
is
all
operating,
and
this
has
been
triggered
by
some
early
reviews
from
a
transport
area
of
the
young
push
documents.
What
you
are
describing
can
be
potentially
large
amounts
of
data
exchanged
over
the
short
periods
of
time.
You
really
need
to
look
into
the
congestion
aspects
in
general,
how
that
will
operate?
What?
What
is
the
impact
from
a
transport
perspective
into
this
I'm
saying
this?
Just
as
as
as
a
friendly
suggestion,
because
if
this
document
goes
forward,
it
will
definitely
get
negative
reviews
from
a
transport
area.
R
C
Let
me
add
to
that
separately:
there
needs
to
be
some
new
notif,
for
instance,
binary
transport,
how
to
transmit,
and
then,
when
we
do
have
a
binary
notif
that
particular
notif
transport
could
plug
directly
into
the
configuration
model
that
he's
proposing
so
again
when
he
decides
independent
of
a
particular
transport.
Any
node
of
transport
that
gets
defined
in
the
future
could
be
used
either
for
yeah
for
the
configured
subscriptions,
whether
it
be
per
line
card
or
just
control
point.
So.
T
Why
we
want
to
propose
a
document
it
because,
as
we
know,
the
and
the
architecture
heart
already
be
published
and
the
protocols
Tenjin
also
be
published
and
our
Bataclan
has
deployments
and
with
the
architecture.
But
we
have
faced
some
backward
compatible
issues
so
with
the
rug
to
shears
as
issues
and
the
problem
to
the
working
group
and
want
to
solicit
and
comments.
And
if
the
working
group
agribusiness
problems
I
think,
maybe
we
need
to
amass
gate
somewhere
is
no
issue
to
our
stresses.
T
So
it
means
that
in
a
longer
period
of
time
there
may
be
coexistence
and-
and
they
support
hunted
now
empirical
support,
Kranti
and
the
server
and
anonymous
motor
server.
And
if
we
use
that,
if
the
am
de
Conti
can
it
be,
Carnot
can
use
a
convenient
operational.
Sir
sorry
to
can
use
it
a
conventional.
We
say
to
communicate
with
and
the
server
but
in
other
hand,
if
the
not
MJ
server
I
want
to
drive
the
data
from
the
anandhi.
A
spotty
server.
Zero
have
some
problems.
T
The
first
issue
is
how
to
distinguish
the
server,
how
to
distinguish
whether
the
current
spot,
MVA
or
not,
when
the
server
applicator
admit
and
I'm
the
agree
lover
and
the
eight
need
you
support.
It
may
need
to
support
both
and
they
can't
and
not,
and
not
on
the
account
and
Syria.
Is
that
no
standard
base
22
the
server
to
and
to
distinguish
whether
it's
a
contour,
our
support
MD,
especially
but
but
things
is
easy
to
solve
that,
because,
if
clan,
it
can
use
a
can't
predict
operation
to
distinguish
focus
ample
if
kind.
T
His
sense
cat
forget
config
at
the
config
this
our
pcs
to
tribes
data
and
the
server
can
assume
that
it's
a
card
is
a
non
negative
and
a
non
MMVAs
support
account,
and
if
it
is
a
current
syndicate
data
at
the
data
operation
to
which
one
data,
so
the
server
consumes
as
a
can't
hate.
It
support
empty.
A
Michael.
C
J
C
T
H
D
T
Our
second
tuition,
it's
another
issue-
is
it
how
to
handle
to
default?
The
data
the
Simmons
artisan
system
configure
the
default,
can
fake
data
is
moving
to
the
operational
data
store
and
there's
envy
the
server
so
is
not
clear.
Visors
and
the
aware
server
can
return
the
Simmons
out
to
none
and
a
contest
or
none
in
the
arrears
or
does
if
the
working
bruising
it
should
return
the
similars
out.
T
So
it
may
as
amazing
impact
on
the
operational,
especially
handles
a
default
behavior,
because
the
default
a
configuration,
a
system
configuration
that
move
into
the
operational
data
store.
So
if
we
use
a
cat
config,
for
example,
in
report
or
model
the
data
driving
around
that
run,
indeed
stall,
it
will
be
reduced
without
that
included
default
conflation.
And
if
we
use
a
if
we
user
added
the
data
on
running
digital
it,
we
can
create
her
to
fabricate
configuration
because
the
ranges
of
the
didn't
doesn't
have
over
a
defaulter
can
see.
F
So
Marty
murkland
I
really
don't
understand
the
problem
here.
I
think
there
are
different
or
pcs
and
and
I.
Don't
think
that
you
can
really
talk
about
the
client
being
non
MDA
or
an
NMDA
aware
I
mean
a
client
that
is
and
then
they
aware
might
send
an
edit
config,
for
example,
or
again,
that's
fine,
it's
the
operation
that
has
a
certain
behavior
and
the
behavior
of
those
operations
haven't
really
changed
with
nm
day.
So
I
I
I
agree
with
Ken's
review
and
I.
Don't
really
see
the
problem
here.
I
So
Tim
Carrey,
Nokia
I
will
say
that
we're
doing
this
same
type
of
analysis
in
another
organization,
because
we
do
see
the
problem
of
of
the
permutation
of
different
nmda
clients.
Non
MBA.
Clients
against
in
nmda
servers,
non
NDA
servers
and
there
some
some
aspects
that
are
causing
some
difficulties
unnecessarily
with
the
our
PCs
themselves,
but
with
the
interactions
and
in
the
data
stores
right.
And
so
if
the
IETF
is
taking
on
the
work
of
trying
to
figure
out
how
to
make
these
different
permutations
applicable.
I
F
C
Can't
as
a
contributor,
perhaps
what
you're
thinking
about
is
the
defaults
are
somehow
in
the
operational
data
store
and
and
therefore
an
MVA
server.
It's
not
in
one
of
the
configuration
data
stores
and
hence
when
you
do
I
get
config,
somehow
they're
not
available
for
returning
or
something
like
this,
but
is
not
really
the
way
to
think
about
the
default
values.
They're,
not
really
in
the
operational
data
store,
they're.
C
Just
simply
people
values,
the
the
opt
state
for
sure,
is
being
tagged
as
being
they're
being
tagged
as
default,
but
I
don't
live
in
an
operational
data
store,
but
as
Martin
and
I
have
been
saying,
the
the
of
the
RFC
6241
behavior
doesn't
change.
The
API
is
identical.
It's
just
an
implementation
at
the
nmda
aware.
Server
must
return
the
response
the
same
way
as
it
would
if
it
had
not
been
an
md
aware
server.
So
so.
T
C
T
That's
right,
this
is
another
issue,
is
another
issue?
Is
a
for
how
to
handle
that
system
or
config?
Okay?
Here
in
some
one
case,
if
the
kind
want
to
can
take
I
happy
to
interface
for
and
there's
an
interfacer
it
Auto
is
a
system
config
the
interface?
There
are
some
issue
because
we
hope
wrong
because
we
were
on
to
configure
the
IP,
but
as
it
interfaces
a
in
India
is
for
is
in
the
operational
data
store,
so
so
karna
may
need
to
create
a
interface
of
full
and
then
configure
the
IP
of
this
interface.
T
So
this
factory
isn't
the
same
as
the
Fiat
Auto
created
interface
Allah,
created
into
physical
configuration
into
run
into
the
stove
and
make
it
become
configuration
and
after
this
interface
configurations
applied
either
will
be.
Mercury
is
not
there
because
this
is
a
system
configuration
operation
that
is
to
okay.
C
Take
this
offline,
we
need
a
segue
into
the
net
mod
meeting
now
and,
and
so
we
can
just
switch
tables.
Thank
you,
Mahesh,
sorry
for
the
quick
turn
over,
but
we
are
running
late
and
I.
Don't
even
sure
that
from
it
we
were
gonna.
Do
five
minutes,
chair,
slides,
but
I,
don't
think
it'll!
It's
not
even
do
that,
so
we're
just
transitioning
into
the
net
mod
meeting.
There
was
a
mixup
with
the
agenda
scheduling
somehow
they
think
that
this
is
currently
session.