►
From YouTube: IETF111-NETCONF-20210728-2130
Description
NETCONF meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
All
right,
good
morning,
good
afternoon,
good
evening,
wherever
you
are
in
some
cases
in
the
middle
of
the
night
too,
this
is
the
netcom
perk
group
meeting
for
itf
111.
A
Is
everyone
able
to
hear
me
fine.
A
All
right
we
can
get
started
next
slide
is
all
about
the
noteworld.
Most
of
you
have
seen
this.
If
you
have
not,
please
be
aware
that
any
contributions
discussions
you
have
either
here
on
the
main
list
are
governed
by
the
noteworld,
so
do
take
some
time
to
go
through
it.
A
We
you're
here
in
the
meat
echo
session.
I
guess
so
you
know
how
to
get
here.
We
do
have
a
chat
window
up
on
the
top,
so
we
will
be
monitoring
our
comments.
If
we
miss
anything
to
prompt
us,
the
hum
vendor
is
also
next
to
well.
We
used
to
be
mixed
with
chapman.
I
guess
it's
not
there
any
more.
A
We
will
be
using
that
to
take
notes
for
the
meeting,
so
any
volunteers
who
do
want
to
scribe
for
the
meeting
are
welcome
the
more
the
better
notes
we
will
have
at
the
end
of
the
meeting.
So
we
highly
encourage
people
to
make
some
notes
there.
A
A
A
A
The
we
talked
about
kodi
md
and
the
mint
takers.
If
you
want,
you
can
even
make
it
a
separate
tab,
slash
window.
If
you
want
to
monitor
the
discussion
there,
the
notes
there,
while
you
are
watching
the
slides
right.
A
The
status
so
the
young
push
notification
capabilities
draft
is
in
80
hands
currently
and
it's
out
of
the
work
group.
So
thank
you
authors.
We
just
hope
to
see
you
through
kent
will
I'm
gonna
pause
for
a
minute.
I
think
we
have
rob
go
ahead
right.
B
I'm
just
gonna
say
for
that
one
I
I
finished
all
that
one
is
effectively
done.
It's
just
waiting
on
resolution
of
the
data
document
so
once
that
our
last
go
at
the
same
time,.
A
Okay,
all
right
kent
will
present
on
the
next
slide.
His
status
on
the
client
service
reader
drops
for
the
https
draft.
We
do
have
one
issue
before
we
can
call
it
end
on
the
workgroup
last
call,
the
details
of
which
will
be
discussed
in
this
meeting.
A
The
yang
push
notification.
Mesh
message
drops
is
still
sitting
in
expired
state,
we're
waiting
for
authors
to
update
it,
and
I
think
they're,
probably
waiting
for
https
or
maybe
and
now
would
be
a
good
time
to
kind
of
push
the
button
on
that.
A
C
Yes
sure
so
you
hear
me
yeah,
yeah,
okay
cool,
so
we
submitted
the
0-3
version
two
weeks
ago.
So
what
we
did
on
this
update
was
to
add
the
private
encoding
option
that
we
discussed
last
etf
to
allow
for
a
more
verbose,
encoding
description
than
what
can
be
done
with
the
et
field.
So
this
was
following
the
feedback
that
we
got
on
the
zero2
version.
C
We
added
a
security
section
to
basically
say
that
this
solution
is
not
secure
and
that
secured
solution
should
be
defined
elsewhere
that
in
this
draft,
this
is
not
the
plan
for
this
graph
to
for
this
draft
to
to
support
a
secured
option.
C
What
we
planned
for
the
dash
of
four
is
to
add
the
ayanna
section,
but
there
was
were
discussion
on
that
topic,
so
I
will
wait
for
them
to
be
resolved
to
start
introducing
the
call
to
create
the
iona
pools
and
what
we
also
plan
to
do
is
to
add
some
update
the
young
model
to
add
some
configuration,
notably
for
the
segmentation,
behavior
configuration
and
maximum
segment
sizes,
and
I
think
that
once
this
will
be
done
after
this
fourth
revision.
I
think
this
would
be
ready
for
last
call.
A
All
right,
let
me
just
quickly
finish
the
slides
and
then
there
any
questions.
So
the
sztp
csr
draft
is
also
an
adq.
I
don't
know.
If
there's
any
questions
you
can
ask.
D
Yeah
hi:
this
is
kent
as
a
contributor
and
speaking
for
the
client
service.
Who
would
address
first
off?
Can
you
hear
me?
D
Okay,
yes,
okay,
good,
so,
as
everyone
should
know,
the
last
call
is
completed
for
the
first
three
drafts
and
currently
technically
we're
still
in
la
the
last
calls
for
the
middle
four
tcp
ssh
tls
and
http
really
currently
we're
only
blocking
on
the
tls,
as
we
are
continuing
to
resolve
the
tls
1.3
support
for
pre-shared
keys
and
raw
public
keys,
and
then
it
is
the
the
chairs
have
expressed
a
desire
to
initiate
the
last
call
for
the
last
two
drafts
immediately
after
its
111
has
completed
so
expect
that
call
for
review
to
occur.
D
I
guess
next
week
regarding
the
sctp
csr
draft
that
is
in
the
adq.
This
is,
on
the
right
hand,
side
of
the
slide,
the
80
review
part
of
it's
completed,
but
there's
been
requests
for
updated
language.
In
some
of
the
description
statements.
D
D
Of
course,
any
updates
to
tryptotypes
will
be
sent
to
the
working
group
list
for
review.
That's
all.
Thank
you.
A
All
right
thanks
kent,
so
on
the
charter
of
sorry
on
the
agenda.
Sorry,
what
we
have
is
within
chartered
items.
We
have
the
https
notatraft
and
on
the
non-chartered
items
we
have
three
presentations
that
will
go
through.
D
Not
a
question
but
a
comment:
it's
I
think
we
were
looking
at
these
three
non-chartered
items
that
are
on
the
screen
currently
and
notice
that
they
all
have
in
similar
they're.
I
think
they're
all
augmenting
the
system
capabilities.
D
Actually
I
think
it's
maybe
an
rfc.
It's
already
passed
last
call,
and
so
I'm
just
I
guess
we're
interested
in.
You
know
ensuring
that
the
working
group
is
aware
of
that.
There
seems
to
be
a
lot
of
activity
going
on
with
regards
to
augmenting
the
system,
capabilities
structure,
data
tree.
D
A
All
right,
I
guess,
with
that
we
can
move
to
the
next
deck.
A
All
right
so
we're
going
to
use
this
at
the
next
20
minutes.
It
need
be
to
discuss
the
https
based
transport
firm
gang.
A
They
were
no
updates
to
the
draft,
but
there
was
plenty
of
discussion
on
the
mailing
list
around
the
capability
fetching
mechanism
and
while,
as
an
author,
we
believe
there
were
some
consensus
towards
keeping
the
changes
or
keeping
the
mechanism.
As
is
we
will
let
because
we
are
also
the
chairs,
we're
going
to
let
rob
kind
of
discuss
the
consensus.
Maybe
at
the
end
of
this
presentation,.
A
But
there
were
two
other
points
that
were
raised
by
rob,
and
one
of
them
had
to
do
with
whether
we
could
possibly
use
the
as
a
structure
extension
and
to
and
define
the
capabilities
and
the
idea
being
to
follow
the
rc
8791
as
x,
structure
definition.
A
If
that
was
to
happen,
we
of
course
will
need
a
third
module
to
implement
the
extension
and
format
on
the
wire
would
be
identical
to
the
one
that's
in
the
draft,
except
for
the
addition
of
the
namespace
right.
D
Previous
slide,
I
just
wanted
to
note
that
currently
the
draft
defines
pseudo
yang
to
describe
what
that
response
message
should
look
like,
so
you
know
it
it's
yang,
but
it's
without
the
envelope
of
a
yang
module.
So
it's
familiar
to
readers,
but
not
necessarily
usable
by
tool
tooling.
So
if
we
were
to
use
an
ss
structure,
then
it
would
make
itself
available
to
tooling.
A
So
assuming
that
we
go
with
the
first
change,
which
is
dsx
structure
change
that
was
identified
in
the
last
slide
again,
a
new
module
being
would
have
to
be
created,
probably
might
belong
to
an
iona
maintain
module
which
would
define
a
new
base.
Identity,
which
called
transport
capabilities
and
deriving
from
that
base.
Identity
would
be
four
new
sub
identities
that
have
already
been
identified
in
that
round.
A
A
I
also
noticed
that
some
of
the
other
drafts,
whether
it's
the
telemetry
data,
I
think,
which
also
tries
to
define
some
identities,
so
I
think
it
probably
would
benefit
to
have
a
common
module
with
these
transport
capabilities.
A
It
does
preserve
the
ability
for
the
modules
to,
of
course,
still
extend
and
define
their
own
custom
capabilities
and,
finally,
of
course
it
the
need
for
maintaining
an
eye
on
a
registry,
so
I'm
gonna
pause
there
to
see
if
there
any
comments.
Questions
about
the
suggested
changes.
B
B
What
I
was
actually
suggesting
was
to
do
something
like
the
way,
the
athei
and
safi
registries,
the
handle
for
the
php
routing
types
and
there
those
trusted
families
are
in
registries,
but
there's
an
automatic
procedure
to
generate
a
young
model
by
anna
to
contain
those
those
definitions
effectively
as
enum
genomes
in
that
case
rather
than
identities,
and
we
also
have
a
similar
case
with
the
if
types
which
I
think
might
be
defined
almost
in
amiibo,
maybe
registry
for
them
as
well.
B
B
A
Right,
okay,
so
I
guess
the
advantage
would
be
it's
that
it's
aina
controlled
and
managed,
and
it
still
gives
us
the
ability
to,
as
you
said,
to
create
a
yang
definition.
B
Yes,
it
does,
I
think
the
advantage
of
it
is.
It
puts
the
those
identities
all
those
values
in
one
place.
You
can
go
and
look
at
the
registry
and
see
them
and,
and
they
say,
disadvantages
you
can't
have
third-party
modules
adding
their
own
identities
and
again
it
depends
on
what
the
rules
are
for
updating
that
registry
as
to
whether
that
still
requires
rfcs.
B
D
Well,
I
guess
the
sorry
kent
is
a
contributor,
so
rob
first
off.
I
I
have
in
the
ssh
and
tls
client
server
drafts.
It's
doing
exactly
like
you
discussed,
there's
an
actual
iana
registry
and
it's
deriving
yang
modules.
Ayana
maintain
gang
module
so
familiar
with
that
strategy,
but
I
guess
the
question
ultimately
becomes.
Do
we
want
to
have
that
single
location
of
the
ayana
registry
or
you
know,
is
it
not
just?
Is
it
equally
suitable
for
to
just
have
yang
modules?
D
B
So
as
a
contributor,
yes,
I
agree,
that's
the
question,
I'm
not
sure
I
have
a
good
answer
for
you.
I
I
think
mainly
having
these
few
identities
is
probably
sufficient
for
most
cases
and
then
maybe
some
more
get
added.
So
so
I'm
I'm
ambivalent.
I
don't
feel
strongly
for
this,
so
unless
somebody
else
speaks
up
and
says
they
do
have
a
you
know
this,
I
would
leave
it
to
the
authors
to
decide
which
way
to
progress.
A
Okay,
I
think
then
maybe
kendra
and
I
will
confer
and
post
back
on
the
mailing
list
what
we
finally
decide.
A
All
right,
so
that
was
pretty
much
the
last
slide,
any
other
questions
or.
B
So
you
wanted
me
to
comment
on
consensus
on
the
sort
of
capability
mechanism
was.
Is
that
is
that
now
the
time
you
want
me
to
speak
to
that
or
yes,
thank
you.
B
So
I
think,
based
on
the
comments
I
sent
to
the
email
alias,
it
looks
to
me
like
now
that
this
has
converged
on
the
fact
that
keeping
the
capability
met
isn't
tied
to
this
particular
draft
seems
like
a
reasonable
way
forward
at
this
time.
A
So
there
are
no
comments.
I
guess
we
we'll
go
with
the
consensus.
D
Yes,
so
I
am
going
to
be
the
slide
actually
hold
on.
Did
we
want
to
see
if
folks
could
share
their
own
slides?
I
think
we
might
do
that.
So.
First,
we
have
the
telemetry
export
presentation
cufong.
D
D
E
E
Yes,
I
think,
as
mahaj
mentioned
there
are,
there
were
a
lot
of
discussion
on
capability
infection
mechanism
which
is
related
to
this
work
and
the
http
native.
So
thank
you.
Everyone
involved
in
the
discussion
thanks
for
the
comments
and
suggestion,
so
the
latest
update
of
this
draft
is
version
5,
and
the
main
change
is
that
we
revise
the
draft
to
online
focus
on
the
server
comparability
effect
mechanism.
E
E
But
in
our
draft
we
did
investigate
how
to
support
a
receiver
side,
commodity
discovery
through
standard
offline
file
formats,
but
failed
to
find
a
good
case.
So
we
believe
that
in
most
cases
there
is
a
demand
about
several
comparability
discovery
to
increase
the
likelihood
of
succeeding
in
negotiation
of
the
subscription
parameters.
E
We
change
the
type
to
empty
so
that
if
the
node
doesn't,
if
the
node
doesn't
doesn't
support
the
compabilities,
they
just
convert
to
the
client
by
the
absence
of
these
parameters,
which
saves
the
unnecessary
overhead
next
slide.
Please.
E
So
I
think
the
agreement
we
have
reached
on
the
list
is
that
we
both
should
focus
on
the
common
data
model
for
the
that
export
capabilities
instead
of
common
protocols.
So
we
would
like
to
define
a
common
mechanism
for
several
comparabilities
advertisement
and
leave
the
particle
extension
to
each
expert
specific
native
draft.
E
E
A
Since
I'm
first
in
the
queue,
thank
you
for
the
presentation,
the
the
use
of
the
term
again
server
and
client
can
be
confusing,
so
I
would
definitely
recommend
I
think
in
this
case,
when
you
say
server,
I
think
you're
referring
to
the
publisher,
so
it
might
be
helpful
to
kind
of
be
consistent
in
the
usage
of
the
terms
and
maybe
use
publisher
and
receiver
to
indicate
whose
capabilities
we
are
talking
about.
A
So
that's
just
a
suggestion,
but
there
are
two
other
comments.
One
relates
to
the
set
of
identities
that
were
have
been
defined
in
the
draft
and
they
relate
to.
I
think,
encoding.
One
is
encoding
formats
and
I
couldn't
help
notice
that
the
those
definitions
overlap
with
some
of
the
definitions
in
https
notif
and
maybe
even
udp
model.
A
So
maybe
one
of
the
things
to
kind
of
keep
track
is
if
we
proceed
with
the
suggestion
that
we
just
discussed
in
https
native
to
have
a
separate
module
with
all
the
transport
capabilities
that
all
that
your
draft
could
probably
derive
the
so-called
encoding
formats
from
that
same
set
of
identities.
A
There
is
a
separate
identity
that
you
define
for
compression
and
I
was
trying
to
understand
how
would
that
be
different
from
encoding
format,
I
mean
for
a
receiver
that
is
receiving,
say
a
gzip
file.
How
would
it
would
the
behavior
for
an
encoding
format
be
different
than
what
is
a
compression
mode
and
that's
a.
E
Do
you
mean
that
the
for
the
the
for
the
specific
native,
the
encoding
format
of
I
mean,
for
example,
the
economy
format
of
atp
native,
should
be
the
same
with
the
for
encoding
format
in
the
udp
native.
A
A
How
would
jesus
be
different
as
a
behavior
or
treatment
than
encoding
form?
I
mean
if,
if
you
were
to
receive
a
notification
in
a
gzip
format,
you
would
still
treat
it
much
like
how
a
gzip
file
needs
to
be
treated.
A
A
A
I
can
try
to
articulate
this
on
the
email,
also,
if
it's
not
clear,
maybe
I'll
give
cite
specific
examples
from
the
draft.
So
let
me
step
away
from
the
mic
for
a
minute
and
give
other
people
chance.
F
So,
just
I
I
do
have
one
question
a
comment
to
back
for
for
mahesh
is
that
the
compression
itself,
if
you
uncompress
it,
will
still
have
a
particular
encoding.
So
I
think
the
compression
is
actually
separate
from
the
encoding,
that's
my
opinion,
but
the
question
I
had
was
for
adoption
of
the
draft.
I
think
we
had
some
objections
last
time
that
we
were
going
to
try
to
resolve
on
the
list,
particularly,
I
think
andy
had
made
some
objections
about
the
complexity
of
the
draft
that
you
were
resolving.
F
E
E
F
A
Yeah,
I
was
good
I'm
going
to
thank
tim
for
that
clarification.
I
think
that
I
think
answers
my
question
as
far
as
why
you
might
need
the
compression
mode,
so
that
still
leaves
one
other
question
that
I
noticed
as
there's.
Another
identity
which
I
want
to
call
is
the
base
of
subscription
mode,
and
I
think
it
has
three
identities
on
change
event
and
periodic,
and
I
was
trying
to
understand
how
was
the
event
identity
different
from
the
other
two.
D
Okay
and
next
benoit,
I'm
just
wondering,
would
you
like
to
present
the
slides
yourself
or
would
you
like
me
to
present
them
for
you.
G
G
You
all
right
thanks
kent,
so
basically,
this
is
not
a
new
id,
that's
something
that
I
presented
in
itf
107.
I
simply
refreshed
the
draft.
This
time
didn't
have
time
to
update
it,
so
no
updates
in
the
last
time,
but
since
the
itf
netcam
notification
abilities
draft
is
kind
of
done
at
least
at
the
review.
Maybe
it's
a
good
time
to
to
review
this
this
premise
statement.
G
So
if
we
go
to
the
next
slide,
let's
do
a
little
bit
of
history
here.
So
we've
been
dealing
with
data
model
management,
and
so
the
first
thing
we
did
is
we
developed
a
lot
of
young
modules
because
we're
thinking
automation
needs
a
lot
of
yang
modules.
G
Then
what
we've
been
thinking
about
is
right,
but
we
need
to
have
a
good
tool
chain
to
do
that
right,
so
we
developed
the
validators
and-
and
we
developed,
you
know
editors
and
we
developed
all
these
for
the
life
cycle
management,
then
working
on
the
right
track.
There
then
we
said
okay,
but
we
need
to
have
metadata
about
the
jag
models.
We
need
to
understand.
G
If
we
speak
about
service,
yang
model
or
network
element
young
models,
and
we
need
to
understand
if
they
come
from
an
sdo
if
they're
ratified,
if
they
validate,
if
they
follow
an
mda
structure
or
the
open
conflict
structure
or
whatever,
because
you
need
to
combine
those
young
models,
so
we
did
that
with
the
young
catalog
and
now
we're
arriving
into
a
state
where
we
need
to
have
parent
capabilities
right.
It
was
mentioned
in
the
previous
draft
as
well.
G
So
exactly
like
we're
about
to
discover
from
a
server
the
young
models,
the
feature
the
deviation,
the
protocol
capabilities.
We
need
to
understand
some
of
the
current
capabilities.
Why?
Because
we're
dealing
more
and
more
with
telemetry
right
yang
push
and
because
we
want
to
do
closed,
loop
automation
and
to
do
the
closed
loop
automation.
We
need
to
have
those
node
capabilities.
G
So
if
we
go
to
the
next
slide,
I
want
to
give
a
practical
example.
So
you
know
on
typical
router,
at
least
one
I
know
of
if
you,
if
you
query
the
interface
counters
on
the
line
card
right,
you
will
discover
that
those
counters
are
not
updated
more
frequently
than
30
seconds
right.
So
whenever
you
play
with
telemetry
and
include
slip
automation
well,
if
you
pull
or
if
you
stream,
because
in
the
end
the
same
thing
right,
we
prefer
streaming
but
whatever.
G
If
you
stream
more
frequently
than
30
seconds,
let's
say:
15
you're
going
to
have
a
kind
of
a
graph
that
will
be
like
a
big
step
and
then
something
flat,
a
big
step,
something
flat,
which
means
that
if
you
stream
every
15
seconds,
you
will
draw
a
conclusion
that
there
is
no
counter
interface,
which
is
just
wrong
right.
So
knowing
this
you
know,
frequency
is
key
to
draw
the
right
conclusion
for
closed
loop
automation
based
on
your
telemetry
and
also
to
reduce
the
load
on
the
devices
right.
G
We
got
frequent
requests
saying
I
want
to
have
like
micro,
cadence,
micro,
second
cadence
of
of
things,
but
maybe
it
just
doesn't
make
sense.
So
the
use
case,
as
I
mentioned,
this
is
like
telemetry,
with
close
to
automation
or
call
it
service
assurance
and
or
in
10-bit
networking
or
self,
whatever
network
right.
But
it's
just
like
a
foundational
piece
that
we
need
and
there's
a
link
to
the
two
different
drafts
at
the
bottom
there.
G
So
getting
like
the
discovery
of
you
know,
telemetry,
so
per
node
information
that
are
useful
for
telemetry
and
closed
loop
is
important
so,
and
this
is
what
I
want
to
mention
next
slides
right.
So
it's
either
for
closed
loop,
automation
or
for
post
processing
analytics,
but
we
need
to
have
that
so
and
that's
what
we
did-
and
I
think
that
can
you
highlighted
this,
that
we,
the
three
draft
that
we're
proposing
now
are
all
discussing
in
an
augmentation
of
the
system
system,
young
module?
G
And
if
you
go
to
the
next
slide,
this
draft
actually
augments
the
itf
netcom
notification
capabilities
and
we
know
that
it
provides
structure
that
can
be
used
to
specify
young
related
system
coverages
for
a
server
and
specifically
telemetry.
There
is
unchanged
reported,
which
is
like
another
basic
information.
We
need
to
do
a
closed
loop
automation.
If
we
receive
an
event-
and
we
know
it's
unchanged
well-
it's
a
pretty
important
event:
it's
not
like
a
simple
log,
so
the
minimum
update
period,
the
support
update
period,
the
minimum
dampening
period.
G
So
this
is
the
draft.
This
is
an
id
review.
Now
the
new
specification
next
slide.
We
augment
that
itf
system
capabilities
and-
and
we
add
basically
two
rpcs-
so
it's
more
important
to
look
at
the
the
variables
that
we
add-
and
this
is
like
your
next
slide-
the
minimum
of
the
observable
period
right.
So
I
understand
that
there
is
something
similar
in
the
in
the
itf
netcom
notification
capabilities
with
the
minimum
update
period.
G
So
that's
something
that
could
be
interesting
to
receive
directly
from
the
server
the
optimize
measurement
point
well,
depending
on
how
your
server
is
is
built
sometime.
Whenever
you
want
to
receive
a
single
counter,
it
might
be
just
more
efficient
that
you
receive
the
entire
set
of
counters,
for
let's
say
that
interface,
because
it's
kind
of
structure
right.
So
if
the
speed
of
streaming
that
counter
is
important,
we,
we
might
have
a
suggestion
to
say
well
just
take
the
container
above
for
the
old
interfaces,
all
the
counters
for
interfaces
as
opposed
to
a
single
single
counter.
G
So
this
is
this
optimize
measurement
point
now
the
corresponding
oid.
Well
again,
this
is
important
that
you
know
if
you've
been
doing
polling
with
an
mp4
years,
as
most
people
have
been
doing
right
and
then
you
say
well,
can
I
just
move
to
this
telemetry
and
data
model
management.
This
is
this
might
be
important
to
know
the
corresponding
information.
If
the
the
the
server
or
the
router
knows
it
and
the
same
thing
for
the
written
notes
right
so
typically
open,
config
or
itf,
there
are
written
notes.
G
So
this
is,
it
might
be
interesting
to
to
send
information
directly
from
the
router
or
at
least
to
be
able
to
discover
it
on
the
next
slides.
There
are
two
rpcs,
because,
if
you're
building
a
closed
loop
automation
system,
well,
you
want
to
get
for
specific
nodes.
All
the
measurements
data,
so
the
set
of
all
the
different
objects
or
young
leaves
that
I've
been
showing
and
on
the
next
slides
the
open
issues.
G
Well,
I
mentioned
already
like
the
difference
between
the
minimum
update
period
and
the
minimum
observer
period,
which
is
one
in
its
draft
the
ladder
and
the
one
in
the
itf
conf
capabilities,
the
itf
netcom
notification.
Sorry,
so
the
open
issues
we
could
be
splitting
the
related
note
into
the
config
one
and
the
state
one,
and
I
believe
that
we
want
to
do
a
better
job
to
explain
the
rpc
from
the
client
side.
G
And
let
me
stop
here
in
terms
of
open
issues,
because
I
have
not
updated
the
draft,
but
basically
the
the
last
slide
is
I
want
to
get
from
from
the
the
people
here
if
they
recognize
the
problem
statement
and
whether
we
should
solve
this
one.
Personally
personally,
I
believe
the
answer
is
yes,
but
I'm
kind
of
biased.
G
So
the
ask
is
to
to
read
the
draft
to
provide
feedback
either
now
or
on
the
mailing
list,
regardless.
I
plan
to
clean
the
draft
and
to
to
update
it
so
and
I'm
proud
that
I
left
you
one
minute.
Kent.
D
Out
of
a
ton,
thanks
manuel,
if
you
don't
mind,
I'm
going
to
step
back
to
the
rpc
slide
here,
it
is
where
are
these
rpcs
being
defined?
Okay,
so
they're
get
measurement
metadata?
All
right,
I
tell
you
I'll,
take
it
offline,
I
thought
for
a
second.
There
was
something
different
to
talk
about.
D
Okay,
so
I
think
to
your
question
the
big
I
mean
going
back
to
the
in
the
chair,
slides
my
intro.
I
mentioned
that
there
seems
to
be
a
lot
of
interest
in
this
area
with
regards
to
augmenting
the
system,
capabilities,
draft
for
telemetry,
related
information
and
all
three
of
these
presentations
that
we're
having
right
now
are
related
to
telemetry.
So
I
think
in
general
there
appears
to
be
a
lot
of
interest
in
this
area.
D
I
therefore,
as
a
contributor,
I
think
you
know
we
support
this
right.
We
want
to
where
their
interest
is.
That's
where
we
want
to
put
our
attention.
D
I
think
I
would
like
to
understand
better
how
these
drafts
all
relate
to
each
other,
and
you
know
if
there's
an
opportunity,
but
it
doesn't
make
sense
at
all
to
combine
them
or
does.
Is
it
making
more
sense
that
each
of
them
are
actually
defining
their
own?
Silo
of
you
know,
focus
and
therefore
it
comple.
You
know
it
makes
sense
that
they're
actually
independent.
I
I
just
don't
know
I
don't
have
that
visibility
at
this
moment.
G
So
one
quick
remark
on
this
one.
If
you
don't
mind
so
whenever
I
saw
discussion
about
the
discovery
capabilities,
I
was
quite
happy
because,
as
I
said,
we've
got
the
capability
discovery
for
young
module
feature
deviation.
G
Now
we
need
to
move
this
to
the
next
step,
which
is
everything
about
telemetry,
the
encoding,
the
transport,
and
I
was
hoping
that
you
would
get
like
a
proper
mechanism
to
just
discover
everything
that
a
server
or
router
could
do.
And
yes,
I
agree
with
you
that
maybe
it
might
be
worth
to
think
about
that
holistically
if
that's
possible,
and
not
only
about
the
encoding
and
the
transport.
But
there
is
more
thing
that
we
need
if
you
want
to
do
a
real
intent
based
networking
solution
in
the
future.
D
All
right,
fantastic
and
now
we're
going
to
move
on
to
our
last
presentation.
Thank
you,
benoit
and
ping.
Did
you
want
me
to
present
your
slides,
or
would
you
like
to
present
them.
D
D
D
D
Yes,
it's,
but
I
think
you
want
to
go
to
full
screen.
D
I
Okay
and
hello:
this
is
paulie
from
channel
moba
and
I'd
like
to
introduce
the
draft
of
adaptive
subscription
to
young
notification,
and,
let's
have
a
recap.
First
and
the
young
push
subscriptions,
allows
client
applications
to
subscribe
to
continuous
data,
store,
updates
without
needing
to
pull
and
two
subscription
modes
are
supported.
I
One
is
a
periodical
subscription
and
another
is
unchanged
subscription
and
for
the
unchanged
subscription
it
is
triggered
by
subscript
data,
value
change
or
data
store
change
type
and
in
some
case
the
service
need
to
configure
both
collectors
and
publishers
with
multiple
period
intervals
and
automatically
switch
to
different
period
intervals.
According
to
network
resource
usage,
and
for
example,
there
are
massive
data
need
to
be
collected
and
the
process
processed
and
the
cost
of
data
management
will
also
be
expensive.
I
But
besides
those
since
high
frequency
data
collection
leads
to
more
resource
consumption,
while
low
frequency
data
collection
lead
to
no
enough
data
for
fault
localization,
so
the
unchanged
subscription
is
needed
and
we
propose
the
adaptive
subscription
mode.
It
allows
the
server
or
publisher,
support
multiple
fixed
update
intervals
and
switch
among
them
based
on
network
conditions,
change
in
the
mode.
The
external
expos
expression
can
be
used
as
part
of
subscription
policy
to
describe
the
condition
and
can
also
track
the.
I
Monitor
the
data
object,
change
such
as
wi-fi
signal,
strength
change
and
the
interval
can
be
changed
and
sent
as
a
notification
to
the
subscriber.
So
during
each
fixed
update
interval,
the
subscript
data
is
sent
in
the
same
way
as
a
periodical
subscription,
so
that
this
draft
was
presented
several
times.
And
here
are
the
changes
from
the
last
item
meeting,
which
is
from
version
four
to
volume.
Version.
I
Six
and
first
is
to
remove
the
modify
subscription
episode
usage
so
that
we
can
add
no
change
to
modify
sub
subscription
and
the
case
of
support
client
initiated
update
interval
change,
but
can
not
provide
promote
response
to
the
network
change,
and
the
second
is
to
reply
replace
the
example
of
wi-fi
mac
mode
definition
in
the
appendix,
with
example
of
wi-fi
network
diagnostic,
which
use
wi-fi
statistics
specified
in
the
chip
specification
and
the
reference
to
chip
specification
for
wi-fi
example.
Module
will
also
be
added
now.
I
We
also
update
the
example
to
align
with
the
wi-fi
example.
Module
change,
and
so
here
is
the
example
of
the
rpc
describing
the
basic
ideas
of
the
of
of
this
draft.
I
When
the
adaptive
subscription
policy
is
installed
and
when
the
value
of
isi
is
lower
than
minus
65,
dbm
switch
update,
interval
to
5
seconds
and
when
it
is
larger
than
minus
65
dbm
switch
update,
interval
to
50
seconds,
and
we
also
specify
the
module
of
the
updated
wi-fi
network,
diagonals
example,
which
can
be
found
in
the
upper
right
corner
of
the
page
next
step.
I
Since
we
have
presented
this
draft
several
times
and
have
received
the
support
and
the
comments
on
the
last
item
meeting
and
also
in
the
mailing
list,
especially
with
michael
and
many
thanks
to
him.
We
think
it
is
ready
for
adoption.
So
can
we
request
it
as
working
group
document
thanks
and
any
comments.
A
I
did
want
to
say
something:
okay,
so
I
again
thank
you
for
the
presentation.
So
if
I
understand-
and
maybe
if
you
could
just
go
to-
I
think
it
was
slide
number
one
where
you
were
doing
a
recap:
okay,.
I
A
Okay,
yeah
there's
one
okay
right,
so
you
mentioned
the
fact
that
there
are
two
subscription
modes
that
you
support,
both
the
periodic
and
a
quant
change
subscription.
So
I
imagine
that
this
adaptive
method
that
you're
suggesting
is
of
course
applicable
to
both
the
periodic
subscription
and
the
unchanged
subscription.
Is
that
true.
A
So
help
me
understand
what
does
it
mean
to
have
adapter
subscription
for
an
unchanged
notification,
because
I
would
imagine
that
an
unchanged
notification
should
be
ideally
delivered
as
soon
as
possible.
Right
and
that's.
The
whole
idea
of
I
guess
as
having
an
unchanged
notification
is
because
you
want
to
know
about
the
change.
I'm
I'm
a
little
confused
as
to
what
does
it
mean
to
have
an
adaptive
subscription
method
for
what
is
really
a
real-time
event.
I
Okay,
yes,
well!
What
we
want
to
do
is
that
we,
just
according
to
the
network
status
and
okay.
J
Okay,
can
you
hear
me
yeah,
so
let
me
clarify
a
little
bit.
Actually
we,
you
know
we
just
built
on
top
of
yam
push,
provided
you
know
two
existing
mode
periodic
and
unchanging
modes.
We
introduced,
you
know
another
mode.
Actually
it
is
a
third
mode,
but
we
don't
change
it.
Actually,
the
existing.
You
know
young
pushy
subscription
mode.
You
know.
J
We
just
you
know,
you
know,
you
know,
extend
you
know,
young
model,
you
know
you
can
support
some.
You
know
adaptive
subscription
policy,
you
when
you
get
this
policy
installed
on
the
server
the
server
can
automatically
switch
the
interval.
So
you
you
can
you
you
can
switch
the
the
you
know,
updated
interval.
This
update
interval,
you
know
related
to
the
periodic
subscription.
A
J
Yeah
I
mean
maybe
yeah
adaptive
subscription
mode.
It
may
be
a
little
bit.
You
know
similar
to
don't
change
it
substitution.
Better.
Not
you
know,
based
on
the
data
change,
you
know,
based
on
some,
you
know,
event
event
or
some
condition
can
be
satisfied.
You
may
keep
track
of
some
monitor
data
objects.
J
You
know
meet
the
sum
of
conditions,
so
we
give
that
wi-fi
motion
example,
for
example,
wi-fi
signals
strengths
may
be
greater
than
maybe
somehow
you
know
threshold
you
can
switch
the
the
the
updated
interval.
So
this
is
you
know
the
k
difference
from
the
you
know
unchanged.
Subscription.
B
A
K
Is
basically
to
adopt
the
the
dampening
period?
Is
it
is
this
the
suggestion,
because
I
think
that
is
something
that
you
could
say
is
adaptive.
I
mean
I
agree
with
the
with
the
segments
that
were
made
that
yeah
this
is
real
time
and
support.
Why
would
you
change
the
period
or
so
it
doesn't
make
sense
from
that
perspective,
but
the
dampening
period,
which
says
basically
how
how
often
you
wait
and
how
long
you
wait
until
you
would
report
on
the
next
change.
That
is
something
that
you
could
potentially
adapt.
K
J
B
Comment
from
rob,
yes-
and
this
is
just
as
an
individual
contributor-
I
still
find
the
solution
here.
I
think
the
problem's
interesting
I
still
find
the
conclu
the
solution
to
be
fairly
complex
and
my
concern
is
effectively
the
use
of
an
expath
evaluation
to
decide
on
whether
the
subscription
changes.
B
I
I
think
I've
made
this
comment
before
I
did
wonder
whether
another
way
of
solving
this
that
may
be
less
less
generic
and
less
intensive,
is
to
allocate
some
sort
of
qs
policy
or
priority
related
to
a
subscription
and
then
have
the
device
automatically
downgrade
the
subscription
in
some
way
that
can't
meet
the
service
requirements.
They
need
to
do
or
something
equivalent
to
that,
rather
than
switching
to
a
separate
subscription
on
these
particular
scenarios.
J
Yeah
robert
yeah,
I
I
know
what
you
propose.
Actually
you
know
if
we,
you
know,
go
with
your
proposal.
Actually
maybe
reuse
some
qs
the
attribute.
Actually,
I
think
you
can
not.
You
know,
have
a
you
know:
rapid
response
to
the
network
resource
changes,
so
you
still
economically
so
so
the
issue
we
you
know
raised
here.
J
So
but
I
don't
you
know,
the
router
usually
or
nano
device
usually
can
be
configured
with
the
multiple
intervals.
So,
if
you
can,
you
know,
you
know,
get
support
some
of
the
policy.
You
know
we
call
the
adaptive
subscription
policy,
you
know.
So
it
is
it.
You
know
it's
not
expensive.
You
know
to
switch
it
into
and
also
you
can.
You
know
to
to
greater
reduce
the
the
data.
You
know
be
connected
to
be
export
to
the
management
plan
and
you
can
reduce
them.
J
Yeah
but
brother,
you
know
in
another
way.
You
know
we
introduce
this
kind
of
condition.
Is
you
know,
use
the
external
exercise.
That
means
you,
the
the
the
the
monitor
data
node
doesn't
need
to
be
part
of
the
you
know
published
data,
so
it
you
know,
can
reduce
the
cost.
Also,
you
know
for
this
kind
of
condition.
We
mean
we
focus
on.
You
know
you
know,
try
to
reuse
the
existing
x-pass.
You
know
in
the
past.
We
have,
you
know
smart
field
use
cases
which
we
try
to.
B
D
All
right
well,
thank
you,
everyone
for
contributing
to
the
discussion,
and
I
guess
the
chairs
will
send
out
the
minutes
shortly.
Mahesh
do
you
want
to
say
anything
closing
comments.