►
From YouTube: IETF110-NETCONF-20210308-1200
Description
NETCONF meeting session at IETF110
2021/03/08 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
A
You
should
be
able
to
see
the
chat
window
that
you
can
actually
detach
and
keep
it
as
a
separate
tab
and
the
hum
windows.
I
think,
next
to
the
chat
or
if
you
remove
it's
now
right
next
to
the
list
of
attendees
and
that's
where,
if
any
polls
are
conducted,
you
will
see
any
messages.
A
The
virtual
blue
sheet-
you
don't
have
to
do
anything.
The
meat
echo
will
record
your
presence
and
the
queue
and,
of
course,
screen
management.
B
Echo,
that's
just
a
quick
thing.
I
did
post
a
link
to
the
suggesting
people
signed
into
a
virtual
blue
sheet
at
the
bottom
of
the
code,
md
page,
so
maybe
that
was
miscommunication,
but
okay.
A
To
cue,
make
sure
that
you
use
the
microphone
icon
with
the
hand
symbol
to
indicate
that
you
want
that.
You
want
to
speak
and
then,
of
course,
when
it's
your
turn
to
speak,
you
can
use
the
microphone
icon
with
the
play
symbol.
Actually,
there
is
no
play
symbol.
It's
just
a
microphone
icon
now,
so
there's
a
hand
raised
to
get
into
the
queue
and,
of
course,
the
microphone
to
speak.
A
Jabber
we'll
see
in
the
next
slide.
There
is
also
a
note
taking
pad
so
would
love
to
have
everyone
contribute
to
that
page?
We
use
that
to
compile
our
minutes
at
the
end
of
the
meeting.
A
You
can
find
the
answers
to
all
your
questions.
Whatever
you
post
on
jabber
will,
of
course,
get
cross
posted
to
the
meet
echo
chat
window,
which
is
what
we
will
be
monitoring
and,
of
course,
the
logs
will
be
available
after
the
meeting
at
the
link
provided.
A
Trust
anchors
and
key
stores,
a
set
of
drafts
that
are,
I
believe,
still
in
working
group
last
call
they
went
through
the
two
of
them
went
through
sector
review
and
I
believe
currently
we
are
waiting
on
young
doctors.
A
Response
for
crypto
types,
which
is
the
third
draft
in
that
suite
of
transaction
for
working
group
last
call,
is
waiting
on
a
sector
review
at
this
time
and
just
like
trust,
anchor
and
keystore
we're
still
waiting
on
young
doctor's
response
to
to
the
comments
we
have
that
the
author
has
provided
the
client
server
suite
address,
which
is
the
remaining
set
of
drafts,
will
start
working
group
last
call
after
idf110.
A
Yes,
it
has
expired
and
the
last
time
we
said
we
would
probably
wait
for
https
native
to
go
through
before
resurrecting
this
rap.
A
At
this
point,
I
believe
that
two
can
be
are
not
linked
anymore
and
the
push
notification
messages.
Can
the
authors
can
go
ahead
and
provide
an
update.
A
All
right,
if
there
are
no
other
comments,
here's
what
we
actually
the
agenda
is
slightly
modified
from
what
it's
here
we
are
going
to
get
an
update
on
the
udp
or
unite
set
of
traps
before
this,
and
then
kent
will
come
on
to
present
his
client
server.
Suite
of
drafts.
A
Okay,
I
think
I
have
the
agenda
wrong
here,
so
let
me
just
read
off:
what's
actually
in
them,
so
we
have
telemetry
data
export
capability,
followed
by
adaptive
subscription,
which
will
be
followed
by
with
system
capabilities
and
then
finally
I'll
come
back
to
talk
a
little
bit
about
netcount
next
and
rest
count.
Next,.
A
All
right
that,
let
me
stop
sharing
and.
B
I
believe
tomas
is
supposed
to
present
my
hash
between
your
two
shares.
It
could,
I
just
say
a
thing
we
did
receive
a
sorry.
This
is
kent.
We
did
receive
a
liaison
request
from
the
oif
technical
committee.
B
They
are,
they
noticed
this
is
the
220
transport,
sdn,
api
interoperability,
demonstration,
white
paper
and
they're
having
a
virtual
meeting
scheduled
in
two
days.
No,
I'm
sorry
not
two
days
may
the
10th
not
march
the
10th,
and
actually
I
see
I
would
share
this
screen,
but
there's
a
number
of
oaf
individuals
on
the
participant
list,
as
well
as
some
names
that
we
are
familiar
with
anise
sheikh
and
rob
shakir
from
open
config.
B
C
D
Okay,
perfect,
then,
I
will
start.
I
would
like
to
give
a
brief
presentation
what
we
did
last
week
in
the
the
virtual
hackathon
with
the
bmp
young
push
in
this
presentation.
I
will
just
focus
on
the
young
push
part
in
case.
You
want
to
see
also
what
we
did
on
the
bmp
on
the
bgp
monitoring
protocol
part.
Then
please
follow
up
the
link,
the
presentation
so,
regarding
yang
push,
our
focus
was
mainly
on
the
two
drafts
udp
no
different
distributed
motif.
D
B
A
A
A
D
So
then
let
me
go
back.
Can
you
see
the
screen
now?
Yes,
good!
Thank
you.
Okay,
sorry
about
that.
So,
as
I
said
on
the
functionality
part,
we
were
working
on
to
the
integration
into
a
pmact
for
the
collection
library
and
also
for
the
mockup
publisher
and
for
the
performance
part
we
were
looking
into
testing
the
efficiency.
D
After
all,
for
us
important
is
scaling
that
we
can
get
as
much
as
fast
as
possible,
the
matrix
from
the
from
the
network
and
also
see
how
it
performs
in
terms
of
values,
packet,
sizes,.
D
So
that's
the
software
we
used
within
this
network
environment
and
the
collector,
and
also
the
the
democrat
software
both
are
implemented
in
c
segmentation
is
supported
and
it
has
been
integrated
into
a
pmacct.
D
This
is
basically
in
this
hackathon,
the
first
time
we
were
able
to
produce
a
matrix
into
apache
kafka
and
in
regards
to
the
performance
test
sector
which
we
did
is.
D
We
were
basically
set
one
dedicated
core
on
this
linux
machine
for
the
for
the
collector
we
did
in
10
test
runs
with
500
000
messages,
east
each
and
we
were
body
varying
basically,
the
the
message
sizes
between
200
bytes,
1500
and
jumbo
frames,
and
depending
on
the
the
packet
size,
we
we
achieved
different
throughput
throughput,
which
is
a
much
higher
with
the
current
young
push
provides
the
young
push
implementations,
so
we
are
quite
pleased
with
the
results
which
we
achieved.
B
I
see
chiffon
lou
has
his
hand
up.
B
B
Okay,
I
don't
see
that
anymore
in
the
chat
window.
Slm
is
request,
is
asking
about
the
blue
sheet
apparently
meet.
Echo
will
automatically
log
your
attendance
in
the
call,
so
you
don't
need
to
actually
sign
the
blue
sheet
and
I'm
going
to
remove
shifang
from
the
queue
thomas.
Please
proceed
or
I
guess
you're
done
any
other
questions
for
thomas.
Oh.
D
B
Thomas,
I
have
one
question
for
you.
You
said
that
performance
was
much
better.
Was
that
in
terms
of
a
latency
or
throughput
or
both,
and
also
can
you
give
any
relative
numbers
as
to
what
the
proprietary
implementations
are.
D
Achieving
I
can
say
that
we
haven't
been
testing
on
on
latency,
so
we
were
focusing
this
time
only
on
throughput
and
it's
hard
to
to
compare
it
to
existing
implementation
with
grpc.
D
But
what
we've
seen
is,
we
are
by
factors
well
beyond
10,
20
times
higher
and
then
grpc,
but
one
of
our
next
goals,
basically
throughout
the
year,
is
now
to
add
a
basic,
also
https,
notif
and
then
compare
https
notified
udp
notif
to
see
what
are
the
performance
difference
in
them.
B
I
would
hazard
a
guess
that
it's
actually
worse
than
grpc,
even
okay,
you
know
because
it's
neither
binary
nor
it's
also
requiring
an
acknowledgement
per
notification.
So
I
mean,
even
though
it
can
be
pipelined,
but
just
my
expectation.
D
Right
and
also
maybe
you
need
to
state
that
the
encoding
is
a
chase,
and
so
it
will
obviously
change
when
you're
switching
from
json
to
simple
encoding.
B
Yes,
and
also
the
actually
the
hp
node
of
draft
it's,
the
encoding
is
media
type
defined.
So
currently
the
draft
defines
json
and
xml,
but
it
is
possible.
I
think,
what
you're
just
alluding
to
for
a
c
board
to
be
encoded
as
well.
B
B
Okay
looks
good,
okay,
thank
you.
So
continuing
with
these
client
server
suite
of
drafts,
a
quick
update
since
109
the
three
lowest
level
drafts
have
been
updated
twice.
Sorry,
once
the
updates
were
primarily
around
the
various
sector
reviews
that
had
come
in
and
in
particular,.
B
We
updated
the
security
considerations
section
to
detail
or
specify
more
information
about
the
unconstrained
public
key
usage
in
unconstrained
private
key
usage.
Essentially,
what
we
mean
by
unconstrained
here
is
typically
certificates.
B
B
To
implementable,
it
nicely
jurgen
pointed
it
out
in
his
yang
doctor
review,
which
was
sort
of
beyond
the
the
scope
of
what
a
young
doctor
would
be
expected
to
do,
but
nonetheless
appreciated
that
he
discovered
a
gap
and
then
I
conferred
with
russ
housley,
who
is
a
security
expert
and
over
the
course
of
a
couple
weeks,
managed
to
come
up
the
solution
that,
actually
I
shouldn't
say,
is
difficult,
but
it
was
really
just
an
issue
of
logistics
and
us
coordinating
the
time
to
talk
about
it.
B
Also,
we
added
a
password
grouping
example
to
the
cryptotypes
usage
example.
It
wasn't
there
before
so
now.
That
example
in
the
draft
of
the
crypto
text
draft
is
complete.
B
So
each
of
the
possible
groupings
that
are
defined
in
the
graph
of
the
draft
are
now
having
a
representation
in
that
example,
and
we
added
an
encrypting
password
section
to
the
security
consideration
section
so
that
whole
section
was
missing
before
and
of
course,
the
young
doctor,
other
young
doctor
reviews
comments
were
addressed
for
both
trust
tankers
and
key
stored,
the
same
kind
of
update
into
their
security
considerations.
With
regards
to
the
unconstrained
public,
slash
private
key
usage
and
also
other
comments
that
were
affected
by
the
yang
doctor
review
next
slide,
please.
B
Okay
and
then
effective
really
for
the
remainder
of
the
drafts
that
all
of
them
there
is
a
sort
of
collateral
damage,
or
you
know
that
they
all
had
comments.
They
were
all
modified
in
ways
that
were
addressing
comments
raised
by
the
young
doctor,
reviews
in
the
crypto
type,
trust
store
and
keystore
drafts,
but
special
to
just
the
http
client
server
draft.
B
Please
and
the
last
slide.
Okay,
so
we,
I
should
say
the
chairs
requested
early
sector
reviews
for
these
three
lower
level
drafts,
crypto,
tribes,
trust
anchors
and
keystore.
So
far,
we've
only
actually
received
the
sector
reviews
for
the
latter
two.
We
never
actually
received
a
sector
review
for
crypto
types
itself,
so
we're
kind
of
wondering
if
this
is
an
issue
you
know,
and
so
potentially
it's
not
an
issue
and
the
reason.
B
Why
is
because,
in
order
to
review
the
trust
or
the
keystore
drafts
it
and
requires
or
entails
understanding
the
cryptotypes
drafts,
so
those
the
cryptochip's
draft
was
sort
of
implicitly
reviewed
in
in
part
and
also
because
the
cryptotypes
draft,
as
I
just
mentioned,
russ
housley,
worked
with
me
closely.
He
used
to
be
a.d
of
the
security
area
and
you
know
so.
He
was
deep
in
the
weeds
with
me
on
the
cryptid
types
draft.
B
So
I
think
that
it's
pretty
solid
from
his
perspective
and
then
lastly
recall
that
the
only
reason
we
do
early
sector
reviews
is
to
hope.
You
know
to
sort
of
hedge,
our
bets
so
that'll
more
likely
get
through
the
isg
last
call
review
when
when,
when
the
you
know
it's
published
to
the
isg
and
of
course
they
will
at
that
time,
do
a
sector
or
not
it's
not
even
sector.
At
that
time
they
will
do
a
security
review.
B
So
I
think
the
fact
that
the
crypto
type
strap
did
not
actually
obtain
an
early
sector
review
is
not
a
blocker
of
any
sort,
and
we
we
should
proceed
with
that.
Any
comments
on
that
before
moving
to
the
next
item.
E
E
So
just
got
a
question
on
this.
I
think
what
you're
proposing
makes
sense
to
me.
The
only
question
is
if
any
issues
came
up
with
crypto
types
during
isg
review
or
a
sector
review
before
that,
would
that
have
any
impact
on
the
other
drafts.
B
Absolutely
possible
but
mind
you
that
at
least
from
a
working
group
strategy.
Well,
the
next
bullet
point
is
we
plan
to
move
the
remainder
of
the
drafts
into
working
group
last
call,
and
I
we,
the
chairs,
think
that
it
would
make
sense
for
the
you
as
a.d,
to
sort
of
hold
off
publishing
the
group
of
drafts
to
isg
until
they've
all
been
collected
and
then
published
them
together.
B
So
if
we
were
to
publish
the
crypto
type
draft,
it
would
really
just
be
in
your
queue
and,
if
necessary,
we
could
pull
it
out
and
and
work
on
it
somewhere.
B
Great
and
then
I'm
sort
of
completing
that
second
bullet
point.
As
just
stated,
we,
and
also
in
the
agenda
slide
maha
stated
we
do
plan
to
initiate
the
working
group
last
call
on
the
remaining
drafts,
my
hash,
if
it's
easy
for
you
to
do,
maybe
the
the
slide
that
shows,
I
guess,
is
the
title
slide.
The
first
slide
that
has
all
the
list
of
drafts.
B
Perhaps,
but
if
we
were
to
do
two
chunks,
you
could
imagine
tcp,
ssh,
tls
and
http
all
being
together
and
then
and
then
as
a
second
tranche,
then
that
come
from
rest,
conf
drafts
the
or
or
do
them
all
together
and
in
one
go
and
so
the
what
I'll
say
is
that
the
first
four
drafts
are
like
each
other
in
the
sense
that
they're
all
kind
of
transport
oriented
and
they
provide
groupings
that
are
ultimately
used
by
the
net
conflict,
rest
count
drafts
and,
of
course,
the
nekop
and
rest
counterapps
are
the
ones
that
are
providing
the
the
final,
not
only
just
groupings
but
containers
that
that
we're
using
to
configure
that
confirmed
clients
and
servers.
B
A
Yeah
from
my
perspective,
I
think
it
makes
sense
to
break
it
up
into
the
four
drafts
before
sending
net
confidence.
Confident
to
last
call,
but
I'm
more
than
happy
to
hear
what
the
work
group
thinks.
E
So
just
so
as
an
individual,
I
I
also
agree
with
what
mahesh
is
saying.
I
think
it
would
make
sense
to
try
and
focus
on
those
four
drafts.
First,
the
tcp
ssh,
tls
and
http,
but
still
allow
comments
to
go
into
the
other
draft.
If
that
came
up
in
that
discussion,
so
maybe
try
those
four
first
and
if,
if
it
looks
like
the
other
two
are
required,
then
maybe
bring
them
in
later,
but
try
to
do
in
two
steps
might
get
better
reviews.
I
think
that's
just.
B
Yep,
and
also
just
add
to
that,
those
four
drafts
are
relatively
smaller
than
that
not
come
from
restaurant
crafts
and
and
and
but
the
netcome
from
restaurant
crafts
share
are
highly
similar.
So
anyway,
okay
good.
Let's
do
that,
as
that
will
be
our
plan
and
so
we'll
plan.
The
chairs
will
plan
to
kick
off
the
first
four
drafts,
a
workgroup
bus
call
after
this
itf110,
and
with
that
I
think
it
concludes
my
presentation.
B
Are
there
any
other
open
questions
or
comments
and
if
you
could
quit
screen
share
I'll
start
the
next
next
presentation,
okay,
soldiers
thank.
B
A
A
Next
slide,
please.
So
we
did
a
couple
of
updates
coming
up
to
zero
eight
to
try
to
address
the
working
group
last
call
comments
that
we
received,
so
we
did
get
a
lot
of
comments.
So
thank
everyone.
A
I'll
talk
a
little
bit
about
the
resource,
urls
that
had
a
few
questions
and
same
thing
with
discovery
of
re
receiver
resources
and
then
conclude
by
providing
some
clarification
around
receiver,
popular
publisher,
interaction,
followed
by
any
changes,
not
any,
but
the
changes
that
we
have
made
in
the
ini
consideration
section
next
slide.
A
A
One
is
the
capabilities
resource
and
which
publisher
can
do
a
get
request
on.
So
its
path
in
that
case
would
look
like
a
get
slash
some
path,
slash
capabilities
where
the
receiver
is
able
to
publish
its
set
of
capabilities
and
then
the
second
resource
url
that
is
exposed
on
that
same
path
is
the
ruling
notification
resource,
which
is
where
a
publisher
would
post
the
notifications
that
it
wants
to.
A
So,
in
order
to
discover
the
receiver
capabilities,
as
I
mentioned,
of
course,
the
publisher
would
issue
a
get
request
and
if
the
receiver
has
say
requested
sorry,
if
the
publisher
has
requested
a
both
xml
and
json
and
the
receiver
supports
xml,
then
you
will
get
the
response
on
the
left.
A
The
response
is
very
similar.
Basically,
it's
publishing
a
set
of
capabilities
and
say
if
it
supports
all
the
capabilities
that
we
talk
about
in
the
draft,
then
what
it
should
get
back,
those
three
capabilities
that
you
see
and
then
coding
for
json
and
encoding
for
xml
and
then
encoding,
sorry
and
the
rfc
is
8639
39
enabled
capability.
A
So
let's
talk
a
little
bit
about
those
receiver
capabilities,
what
they
are,
so
we
did
introduce
a
new
capability,
the
rfc
8639
capability,
which
essentially
indicates
support
for
rfc
8639
state
machines.
So
anything
that
falls
under
what
that
rfc
describes
is
what
would
be
supported
by
the
receiver
if
it
advertises
the
xml
capability,
it's
basically
indicating
support
for
notifications
in
xml
format
and
if
it
advertises
json,
then
of
course
it's
saying
that
I
am
capable
of
receiving
notifications
in
json.
A
The
point
to
note
here
is
that-
and
this
is
this
change
where
we
were
talking
about
notification.
Messages
now
can
go
ahead
and
add
support
for
something
like
bundle
messages
by
essentially
advertising
there,
that
particular
capability
in
their
own
draft
in
the
same
ini
consideration
section
that
I'll
talk
a
little
bit
about
later
and
by
advertising.
A
So
you
would
notice
that,
with
the
latest
version
of
the
draft,
we
have
trimmed
down
the
diagrams
and
focus
really
on
this
very
simple
interaction
of
how
notifications
are
sent.
A
A
A
A
So
that's
an
open
question.
If
anyone
has
any
comments,
feel
free
to
go
ahead
and
comment
either
here
or
on
the
mailing
list.
E
As
a
contributor,
what
what
other
codes
would
you
think
about
defining
so
are
there
some
standard
ones
you'd
expect
to
find
or.
A
Yes,
so
we
both
kent
and
I
have
looked
at
it.
We
don't
believe
that
any
others
need
to
be
documented
per
se
in
our
draft,
and
I
don't
know
again,
I
don't
think
so,
there's
any
else
that
we
expect
by
default
from.
B
Right
yeah
so
rob
said
what
would
we
think
to
define
so
to
be
clear,
we're
not
going
to
define
anything,
it's
only
a
matter
of
what
other
codes
might
be
used.
You
know
because
http
is
an
existing
standard
and
any
of
the
existing
possible
http
responses
could
be
returned,
such
as
on
screen.
You
see,
401
not
authorized,
you
know,
there's
also
others
like
resource
not
available
or
you
know.
There's.
I
don't
know
that
it's
possible.
B
It
seems
to
me
that
a
publisher,
an
hp
s
note
of
publisher,
would
have
to
be
effectively
a
an
http
client.
I
mean
it
is
an
hp
client
and
it
would
have
to
be
capable
of
handling
the
various
kinds
of
hp
responses
that
would
come
back.
B
Of
course,
the
expectation
is
none
of
those
other
responses
would
come
back,
but
they
might,
and
we
can't
prevent
it.
I
don't
think
in
this
draft,
so
we're
just
sort
of
it's
not.
I
think
what
mahesh's
point
is
is
to
what
extent
should
this
draft
go
to
making
that
statement
and
perhaps
even
further
trying
to
indicate
under
like
every
possible
response
or
issues,
no
known
hp
response
code,
what
it
might
mean
or
how
it
could
be.
B
I
mean
if
there's
any
semantic,
you
know
behavioral
impact
above
and
beyond
what
http
defines.
I
don't
think
so,
but
I
think
that's
what
match
is
leading
up
to.
E
A
That
I
think
the
the
response
would
really
be
at
that
level
from
a
implementation
for
this
particular
draft
perspective.
I
don't
think
so.
There's
anything
that
the
draft
is
going
is
guiding
towards
in
terms
of
response.
It's
whatever
needs
to.
B
Be
declined,
well
maybe
to
rob
okay.
So
if
you
look
at
hpe
status
codes,
they're
grouped
into
categories
so
there's
the
one
xx,
the
two
to
x,
three
x
x,
four
x,
six
five
x
axis
so
four
x
x
is
client
errors
and
five
x
axis
server
side
errors.
B
B
You
know,
for
instance,
maybe
the
back
end
database
that
the
server
is
writing
into
is
full
and
it
can.
It
can't
persist
the
log
or
for
something
like
that.
I
don't
know
and
for
some
reason
or
another
it.
It
returns,
a
five
xx
type
error
to
the
client
effectively
saying
I'm
not
able
to
process
this
request.
B
What
would
the
client
do
in
that
in
order
to
the
publisher
do
in
that,
that
instance,
and
and
maybe
what
you're
suggesting
is,
does
that
entail
buffering
on
the
client
you
know
until
as
and
when
it's
able
to
deliver
that
message
or
something
like
that?
Is
that,
where
you're
thinking
the
draft
should
go
into
that
level
of
detail
and.
E
No,
not
necessarily,
I
think
my
question
is
more
is
if
there
is
some
defined
behavior
that
that
client's
expected
to
take
or
publish
I
want
confusing
three
around.
This
is
then
that's
worth
specifying
if
it's,
if
it's,
if
they
handle
it
all
the
same
way
regardless
or
if
that's
what
has
been
specified
elsewhere,
then
I
don't
think
it
needs
to
be
restated
here.
So
I
guess
it's
worth
specifying.
If
some
action
needs
to
be
taken,
otherwise,
not.
B
Okay,
well,
I
think
I
mean,
as
an
author,
I
think
it
makes
sense
for
us
to
state
that,
for
any
of
the
servers,
client
server
errors,
the
5x
category
of
errors.
This
draft
is
not
itself
defining
the
need
for
any
buffering
to
occur.
A
Reasonable
all
right
next
slide.
A
All
right,
I
think,
I
believe
the
next
slide
which
can
scroll
into
yes,
is
the
ionic
consideration
section.
So
we
did
modify
the
anna
consideration
section.
We
of
course,
have
the
registry
to
register
the
yang
model,
but
now
a
new
registry
has
been
added
to
define
the
capability
you
are
in
that
we
talked
about
a
couple
of
slides
ago
and
it
of
course,
has
been
initialized,
with
the
three
warrants,
the
three
capabilities
that
we
talked
about
a
couple
of
slides
ago.
So
that's
the
change.
A
As
far
as
the
ionic
consideration
section
is
concerned,
we
do
have
some
outstanding
comments
and
that
we
will
meet
the
authors,
kent
and
I
will
respond
to
after
this
meeting
to
address
any
the
remaining
last
call
comments.
But
at
that
point
I
believe
we
would
have
addressed
any
and
all
remaining
comments.
B
And
the
hash
as
a
contributor,
I
just
noticed
that
the
encoding,
sorry,
the
urn
for
the
8639
encoding,
I'm
sorry
supported
that
we,
the
urn,
actually
used
the
word
encoding
into
it.
It's
not
actually
an
encoding,
so
we
should
change.
F
B
B
B
C
But
I
can't
see
this
okay.
Okay,
I
see
the
slice
okay,
hello.
This
is
pony
from
china
mobile
and
I'd
like
to
introduce
the
draft
of
telemetry
edit
export
capability,
excise.
C
C
C
Please,
okay:
this
draft
was
second
presented
in
the
last
meeting
and
a
few
issues
were
discussed
and
first
is
to
support
multiple
transport
protocols
advertisement
from
the
server
to
the
client.
C
First,
we
change
data
export
capabilities
into
list
type
to
support
multiple
transport
protocol
encoding
on
the
server
and
second,
is
adding
usage
example
of
interaction
with
odp-based
transport
for
configured
subscript
subscription,
which
can
be
formed
in
the
appendix
in
the
draft
and
third,
we
add
thomas
as
a
contributor
and
first
we
update
motivation
in
the
introduction
to
clarify
why
this
work
is
needed.
C
It
is
because
I'm
guaranteed
of
inserting
hands
into
error
response,
so
this
document
defines
a
corresponding
solution
that
is
built
on
top
credibility
of
the
existing
draft,
netcom
notification
capabilities.
And,
finally,
we
add
the
support,
udp
and
http
notification
as
two
optional
transport
in
the
yum
data
model.
Next
slide,
please.
C
So
here
are
two
issues
that
need
to
be
clarified
and
first
is
multiple
transport
protocol
support.
We
got
the
question
that
in
some
cases
the
server
may
support
multiple
transport
protocols.
So
how
does
the
server
advertise
multiple
transport
protocol
supported
to
the
we
give
example?
Both
udp
and
http
notification
are
supported
by
the
server,
so
we
propose
that
change
data,
export
capabilities.
C
From
container
and
type
to
the
this
time
to
support
multiple
transpo
transport
protocols
and
with
this
transport
protocol
capability
advertisement,
the
client
know
which
transport
protocol
is
need
to
specify
in
the
established
subscription
rpc
or
modify
a
subsequent
subscription
of
rpc
next
time.
C
F
C
Because
another
issue
is
inserting
came
into
error
response,
as
described
in
section
3.1
of
the
existing
rc
simple
negotiation,
for
example.
Inserting
hands
into
error
response
to
a
field
office
request
between
subscribers
and
publishers
for
subscription
parameters,
increase
the
likelihood
of
success
for
a
subsequent
rpc
request,
but
not
guaranteed,
which
may
cause
unexpected
failure
or
additional
message
exchange
between
the
client
and
server
so
introduce
telemetry
transport
capability.
C
Advertisement
increase
likelihood
of
success
of
the
first
episode
request
and
reduce
the
number
of
subscription
message
to
be
exchanged
between
them
and
but
at
the
cost
of
introducing
advertisement
message
before
the
netcup
or
last
cup
session
is
established.
G
Hi,
yes,
so
this
is
tim
carrey.
I
do
have
a
question
regarding
just
just
if,
if
everything
was
taken
care
of,
I
saw
that
you
did
look
at
the
multiple
transports
and
coding
situation
where
you
were
where
you
had
one
before
that
was
brought
up
by,
I
believe
rob
on
the
last
meeting,
but
there
was
also
some
outstanding
issues
with
respect
to
the
adoption
of
this
thing
and
discussions
that
were
happening
through
the
online
email.
G
Were
those
issues
resolved
regarding
specifically
the
complexity
and
if
weather
was
really
needed
and
some
of
the
unnecessary
subscription
exchange
were,
I
didn't
see
anything
in
there
that
was
resolved
or
not.
H
H
Hi
tim,
this
is
the
chin.
Can
you
hear
me.
G
H
Okay,
yeah,
let
me
clarify
a
little
bit.
Actually,
we
discussed
two
issues
for
second
issue.
Actually
you
mentioned
by
this
brought
up
by
the
robot.
We
have
already
addressed
to
support
a
multiple
transfer
protocol
and
encoding
for
for
the
first
issue.
Actually,
we
also
you
know,
discuss
you
know
the
existing
solutions
that
that'll
be
proposing.
H
Obviously,
actually
it
is
actually
inserted
error
response
into
into
the
response
message.
Actually,
we
maybe
we
can
go
back
a
little
bit
the
first
issue.
Actually
we
we
can
take
a
look
at
that.
H
Yeah,
so
we
will
verify
this,
oh
not
on
this
one.
The
second
second,
the
issue,
two
sorry
yeah.
So
if
this
solution
is
inserted
kindly
into
the
error
message,
error
response
actually.
But
but
you
know
we
think
you
know
it
may
cause
some
out.
You
know
it
actually
may
not
guarantee
to
be
successful
for
the
second
second
around
the
rpc
request.
So
if
we
can
introduce
this
capability
advertisement
so
for
the
first
rpc,
actually
we
increase
the
likelihood
of
success,
but
we
verify
for
for
this.
H
Actually
you
you
have
some
cost
that
you.
You
need
to
also
need
to
this
advertisement
message,
but
we
this
message
actually
based
on
the
young
person
notification
that
has
already
been
standards
in
bb
discussed
in
the
nether
culver.
Actually,
this
is
a
course
that
we
should,
you
know
satisfy,
but
we
also
have
benefit.
You
know
increases
the
the
likelihood
of
success
for
the
first
ibc
request.
So
this
is
something
we
discuss
and
also
you
know
clarify
in
the
introduction
section
and
motivate
for
the
motivation.
H
G
G
Yeah,
so
I
just
wanted
to
make
sure,
but
did
you
directly
go
back
to?
I
think
it
was
andy
that
had
these
objections
before
did
you
go
back
and
verify
the
the
solution
with
with
andy
who
had
the
direct
question
or
concern.
F
H
A
So
tim,
what
I
think
vhs
can
do
is
I
we
can
ask
andy
specifically
if
his
issues
have
been
addressed
or
not.
G
Yeah-
that's
all
I'm
just
I'm.
I
just
had
that
documented
from
last
time
was
that
there
was
some
concerns
still,
and
I
just
wanted
to
make
sure
that
you
know
that
the
people's
direct
concerns
were
validated
with
the
people
that
made
those
concerns.
G
A
A
H
A
I
had
a
question
so
for
the
first
issue
that
you
talk
about
where
you
want
to
support.
So
what
is
the
scenario
in
which
a
publisher
might
want
to
choose
between
different
transport
mechanisms?
At
the
time
I
learned
the
capabilities
and
then
choose
generally.
Wouldn't
the
publisher
already
know
which
kind
of
transport
it
wants
to
use.
H
Yeah,
this
is
something
we
also,
you
know
discussed
about
your
your
job
to
actually
be
notified.
We
think
you
know
you
you,
you
can
discover
the
receiver
capability
for
us.
Actually,
the
server
also
can
otherwise
advertise
their
capabilities.
So
so
these
compute
advertisement
can
be
leveraged
by
the
by
the
young
push
subscription.
For
example,
you
you
establish
subscription.
You
need
to
decide
what
kind
of
encoding
you
should
choose
or
what
kind
of
transport
you
you
want
to
select,
and
you
can
leverage
this
computer
advertisement
from
the
server
yeah.
That's
our
scenario.
H
B
This
is
kent.
As
a
contributor
jen,
you
just
mentioned
established
description.
I
know
that
that
is
a
notification.
A
yang
notification
statement
defined
in
yang
push,
I
think,
but
when
using,
for
instance,
that
the
https
notif
draft-
these
are
one-way
messages.
It's
a
one-way
flow
of
messages.
There's
no
response
you!
I
know
we
were
talking
earlier
about
http
status
codes
and
you
know
four
x-axis
and
five
x-type
responses,
but
there's
actually
no
application
level
response
like
containing
a
payload
that
the
receiver
could
communicate.
H
Yeah,
I
think
both
work
has
such
a
limitation.
Actually
is
a
one-way
message
actually,
but
you
know
I
I
think
we
talked
with
thomas
because
they
have
a
udp
native.
Actually
they
really
want
to.
You
know
bet
on
sending
water
server
support
for
the
encoding,
so
they
can
leverage
these
several
advertisements
for
the
encoding.
So
I
I
think
another
concern
so
for
my
side,
actually,
the
the
I'm
not
sure
we
really
want
to
define.
You
know
two-way
message
to
address
this.
I
I
think,
just
like
you
know,
young
pushy
notification.
B
I
know
thomas
isn't
on
the
call
anymore,
but
it
it
does
seem
that
the
udp
notif
and
and
for
that
matter,
any
other
future,
no
transport
notif
that
we
might
define
that
they
would
want.
I
think,
follow
the
pattern
that
the
https
draft
is
using,
whereby
there's
a
something
like
a
get
capabilities
which,
for
the
case
of
a
udp
notif,
would
would
have
to
be
probably
a
tcp
oriented
request.
B
Perhaps
I
mean
that
could
be
discussed,
but
but
then
the
actual
flow
of
notifications
begins
using
udp,
and
but
so
I
mean
that
that
kind
of
makes
sense
and
something
I
would
expect
to
be
defined
inside
the
udp
node
of
draft.
As
being
part
of
that
work,
is
it
then
the
is?
Would
that
then
be
an
overlap
with
what
you're
describing
here.
H
No,
actually,
we
didn't
discuss
with
thomas.
You
know
about
this.
Actually,
the
we
actually
you
know
so
so
for
you
different
native.
Actually,
they
can
leverage
the
mechanism
defined
in
this
draft.
To
do
the
you
know,
server
capability
discovery.
Actually,
I
I
think
there's
no
overlap
and
either
you
did
or
reference
this
draft
or
or
this
java
reference
udpnotif,
I'm
okay
with
this.
H
Yeah,
that's
one
option.
Actually
I
I
think
yeah
I
haven't
thought
about
this
issue.
Actually
I
I
think
we
we
can
talk
about
this.
How
how
do
you
leverage
this
server
capability?
I
think
your
your
your
maximum
in
actually
native.
Actually,
they
provide
the
receiver
discovery,
and
so
this
is
something
we
I
haven't.
I
haven't
seen
single
thing
about
this
issue,
maybe
yeah.
F
B
You
know
we're
near
the
working
group
last
call
on
that
draft,
and
but
I
mean
as
a
contributor,
I
think
that
it
makes
sense
for
each
node
of
transport
to
define
its
own
mechanism
for
how
it
would
discover
the
capabilities
of
the
receiver.
But
I
don't
know
if
okay
I'll
just
leave
with
that.
H
G
B
No
well
I
mean
that
is
the
question
and
why
I
asked
him,
but
the
response
was
not
solid,
and
so
I
would
it
makes
me
question
if
you
know
it
seems
like
we
want
to
go
all
one
way
or
all
the
other
way
right
and
but,
and
but
my
intuition
is
that
that
would
prob
that
that
it
makes
it
like,
for
instance,
with
the
hp
s,
sorry
yeah,
the
hps
notif,
the
mechanism
that's
used
to
get
the
capabilities
is
https
and
it's
you
know
it's
kind
of
baked
into
that
protocol.
B
If
you
were
to
do,
for
instance,
a
grpc
notice,
you
would
probably
use
a
grpc
request
if
you're
using
you
know,
you
know
so,
for
each
transport
could
be
a
transport
oriented
way
about
going
about,
you
know,
learning
the
the
capabilities,
so
so
my
intuition
is
that
we'd
probably
want
maybe
to
have
allow
each
transport
to
have
its
own
to
define
its
own
mechanism
for
doing
that.
B
But
so
that's
that's
the
quandary.
I
guess
where
I'm
at
right
now.
H
Yeah,
I
I
think
for
our
job
there
right
now.
We
support
a
udv
node
event,
hdb
node.
Before
there's
new
transporter.
We
can,
you
know,
add
it
actually
in
as
a
one
option.
No
problem.
B
E
Yeah,
yes,
as
a
contributor,
I
think
this
is
an
interesting
question
more
generally
about
how
we
manage
capabilities
of
servers
and
how
those
are
reported
and
exported.
I
think
that
at
the
moment
it
seems
like
there's
different
approaches
to
that
problem,
and
certainly
I
think
it's
probably
worth
having
some
further
discussion
to
find
one
way
to
do
this.
I
have
concern
you
know.
As
you
see,
you've
got
your
draft
to
work
with
last
call
at
the
moment.
E
That's
defining
one
mechanism,
but
if
we
decide
to
do
a
different
way,
then
that
that's
a
potential
issue,
but
I
I
does
feel
to
me
that
we
should
come
up
with
a
common
solution
to
this,
rather
than
doing
it
differently
for
different
sorts
of
capabilities.
B
One
thing
I'll
note
is
in
rfc
8639
in
the
configure
descriptions
yang
module
for
each
subscriber
sorry
for
each
description.
There's
a
leaf
called
encoding,
which
is
an
identity,
ref
and
defined
values,
are
xml
and
json.
B
If
it's
even
visible.
The
when
statement
will
disable
the
the
presence
of
that
that
that
leaf
of
the
encoding
leaf
is
not
there.
So
this
was
discussed
some
by
the
authors,
and
you
know
it
seemed
that
the
static
configuring
or
statically
configuring,
the
encoding
xml
versus
json,
was
less
desirable
than
a
dynamically
learned
response
that
you
know
you
could
obtain
the
from
the
public.
Sorry,
the
receiver,
what
encodings
it
supports
that
way
and
then
have
a
more
dynamic
response,
so
the
hps
notice
draft
does
not
when
it
when
it
goes
to
define
that
identity.
B
It
does
not
do
it
in
a
way
that
enables
the
when
statement
and
and
hence
the
configurability
of
that
encoding
leaf
is
not
possible
when
using
the
hps,
notif,
transport
and
and
but
then
further
on,
I
mean
so.
We
could
suss
the
details
out
of
that,
but
also
note
that
the
there's
a
there's
other
capabilities
above
and
beyond
those
of
just
encoding
like
if
the
encoding
is
json
versus
xml,
there's
also,
for
instance,
we
as
defined
in
our
draft
already
the.
If
you
support
the
8639
state
machine.
B
E
Yes,
exa
exactly,
and
I
think
as
you
s,
that's
the
key
point
to
me
is
that,
in
terms
of
capabilities,
we
have
one
base
capabilities
draft
and
we
have
another
one,
adding
some
extra
color
to
that,
but
there's
a
whole
scope
of
capabilities
that
device
has
in
terms
of
configuration
and
what
it's
doing
things
like
that,
and
I
wonder
whether
we
need
to
have
a
more
holistic
view
of
all
those
capabilities
and
work
out
what
the
best
way
of
expressing
those
is
in
yang.
E
I
just
worry
that
we
will
take
a
piecemeal
approach
here.
We've
got
some
base
capabilities,
we've
got
some
that
are
extending
it
for
telemetry,
we've
got
the
notice
drafts
and
things
that
are
doing
their
own
capabilities.
I'm
wondering
whether
we
should
have
a
look
at
trying
to
work
out
what
the
solution
to
the
entire
space
is
rather
than
solving
each
bit
independently
is
what
I
was
thinking
of.
A
Okay,
so
kent,
actually
me
when
I
look
at
the
bino's
comment,
what
he's
saying
is
that
he
he
actually
agrees
with
you
that
it
makes
sense
to
have
discover
capability.
A
So
the
approach
that
say
the
http
is
not
a
draft
has
taken
and
I
think
binocular
speak
for
himself
so
I'll.
Let
him
do
it,
but
that's
my
interpretation
go
ahead.
I
Right,
so
it's
exactly
my
view
right,
so,
okay,
we're
defining
netconf
and
roscom
for
notifications
right,
but
trying
to
get-
and
this
I
want
to
react
to
what
you
said.
The
last
sentence
can't
you
know,
maybe
three
or
five
minutes
ago,
telling
it's
important
to
have
discovery,
capabilities
right
and
it's
important
for
a
telemetry
for
transport
and
a
draft
that
rob
mentioned
to
you
for
object
as
well.
I
B
So,
as
a
contributor,
I
I
think
I
understand,
or
that
dynamic
discovery
is
preferred
over
static
discovery
is
what
I
think
you're
saying,
but
the
mechanism
for
dynamic
discovery,
holistic
versus
per
node
of
transport.
That's
something
that
we
should
probably
look
at
more
deeply.
B
Okay,
so
with
that,
I
think
we've
completed
this
drafts
presentation
unless
there's
any
other
comments,
I'm
gonna
start
bringing
up
the
next.
F
F
F
F
However,
in
some
cases
there
is
a
need
for
a
service
to
configure
both
collectors
and
the
publishers
with
multiple
period
intervals
and
automatically
switch
to
different
different
period
intervals
according
to
resource
usage,
for
example,
thinking
about
a
wireless
network
performance
case
when
the
wireless
signal
stress
falls
below
or
configure
the
low
water
mark,
the
subscribe
data
can
be
streamed
at
a
higher
rate.
However,
the
while,
when
the
wireless
synchronous
stress
across
is
a
configured
high
water
mark,
the
subscribe
data
can
be
streamed
at
a
lower
rate.
F
F
F
F
F
The
recent
progress
we
have
met
is
reflected
on
the
latest
update
variant
3..
We
clarify
the
difference:
differences
between
low
priority
telemetry
data,
dropping
and
collection
red
reach,
switching
in
the
introduction
session
and
update
the
abstract
and
introduction
session
to
focus
on
collection,
with
switching
in
the
server
without
interaction
with
the
remote
client
and
other
editorial
changes.
F
F
An
alternative.
A
solution
is
to
prioritize
a
telemetry
data
collection
and
get
loyal
priority.
Telemetric
data
dropped
it
use,
uses
fixed
telemetry
data
collection
rate
or
fixed
update
interval.
However,
it
is
not
sufficient
to
detect
and
diagnose
the
problems
and
verifying
correct
network
behavior,
and
another
alternative
is
to
use
client
initiative
to
establish,
subscription
or
modify
subscription
rpc.
F
F
B
Comments
hi:
this
is
kent
as
a
contributor,
I'm
wondering
about
your
previous
issue
and
since
I'm
driving
the
slides
I'll
just
scroll
back
up
to
it,
you
mentioned
that
the
alternative
solution.
Point
number.
The
second
bullet
point
is
to
use
client
initiated
established
description
to
modify
subscription
rpcs.
B
F
Yes,
the
if,
if
it
is
in
the
two-way
subscription,
then
you
can.
The
client
can
use
the
modify
subscription,
but
in
the
udp
or
itp
subscription
case
and
the
client
may
use
the
established
subscription.
F
But
it
needs
to
change
the
augmented,
the
ipc
to
allow
this
client
to
switch.
The
update
interval.
B
Different
sorry,
just
one
second
again,
I'm
just
saying
that
we're
repeating
back
when
it's
a
dynamics,
description,
that's
when
you
know
the
the
receiver
is
already
a
rest
conference,
client
and
it's
connecting
and
then
respectively,
over
the
existing
netcomfort
connection
and
starts
to
receive
the
flow
of
notifications.
B
Then,
of
course,
it
makes
sense
to
send
these
establishes
modify,
subscription
messages
over
that.
But
when
it's
a
configured
description,
so
the
flow
of
logs
or
notifications
are
occurring
out,
the
back
end.
There
need
to
be
a
secondary,
netconf
restaurant
connection
on
the
top
side
in
order
to
affect
the
changes.
That's
my
understanding.
H
Yeah,
okay,
ken
you
are
correct.
Actually
I
just
want
to
clarify
for
dynamic
subscription,
actually
we're
not
supposed
to
have
a
second
connection.
We
still
use
the
existing
connection
actually,
but
you
can
you
use
the
modified
subscription
to
to
change
some
of
the
parameters
still
maintain
the
same
connection,
but
for
configure
separation.
I
agree
with.
H
B
So
sorry,
I'm
just
thinking
about
this,
so
some
of
the
the
publisher
is
aware
of
some
of
the
con
issues
of
congestion
with
related
to,
for
instance,
if
the
tcp
right
buffer
is
overflowing.
B
That's
an
indication
of
a
problem
potentially
also
the
receiver
could
become
aware
of
some
issues
if
their
sequence
numbers
and
they
can
see
that
messages
are
dropping,
which
would
probably
be
an
issue
more
on
the
for
udp,
because
other
transports
are
tcp
based
and
so
the,
if
anything,
were
to
drop
the
the
publisher
would
be
aware
of
it.
B
But
then
that
then
suggests
that
the
receiver
has
some
backend
ability
to
communicate
with
the
orchestrator
in
order
to
send
the
messages
they
sell.
The
modified
subscription
message
down
to
the
publisher
to
modify
that
subscription.
B
I'm
just
thinking
about
the
round
tripping
of
it,
I'm
thinking
out
loud
just
making
sure
it
makes
sense,
is
that
what
you're
envisioning
as
well.
H
H
Yeah,
so
so
right
right
now
for
for
server
actually,
because
it
automatically
switches
the
data
connection
rate.
It
will,
you
know,
send
a
notification.
Actually,
we
define
the
notification
to
to
to
inform
the
receiver
about
the
data
connection
rate
change.
Actually,
this
is
what
we
we
have
in
in
the
current
draft.
If
you
think,
do
you
think
additional
capital
that
needed
it.
H
B
Okay,
I
see
that
you
have
you're
gonna,
make
a
comment.
Can
I
open
up
the
next
slides.
A
Yeah
you
can
go
actually.
I
just
had
one
question
with
a
chair
hat
on
the
author
suggested
that
they
were
having
conversations
with
thomas
on
this
trend
and
that's
great
that
you
have
that
interaction,
but
I
would
recommend
that
the
authors
post
their
questions
and
and
or
whatever
discussions
they're
having
to
the
mailing
list,
also
so
that
other
participants
can
pitch
in
and
help
contribute
that
I
think
it'll
help
you
guys
in
the
end,
so
it'll
be
good
to
be
able
to
have
that
discussion
on
the
mailing
list.
H
Yeah,
that
makes
sense.
Actually
we
can
make
a
summary
and
send
thank
you.
That
is
we
already.
You
know,
discussed
with
thomas
about
this
and
probably
some
some
of
the
you
know
conclusion.
Actually
we
we
we,
we
can
make
a
summary
yeah
and
share
on
honest.
H
F
F
B
I
said
national
phones
but
jim
on.
B
No
she's
coming
back.
Okay,
she's
back
sorry
about
that.
F
After
fba
it
introduced
system
configuration
is
defined
in
the
mdi
draft
as
a
configuration
that
is
supplied
by
the
device
itself
and
it
should
be
present
in
operational
data
store.
But
the
issue
is
that
when
the
client
references
the
system
configuration
all
the
system,
configuration
is
in
the
when
or
master
statement.
F
F
F
So
here
is
our
solution
overview.
We
introduced
a
new
data
store
named
system,
it
is
read
only
and
it
does
not
have
to
persist
across
reboots
at
each
boot
time.
The
device
generates
system
configuration
in
system
data
store.
We
also
define
two
basic
modes
report.
All
and
explicit
running
is
automatically
synced
up
with
system
in
the
report
or
basic
mode.
For
example,
system
configuration
is
automatically
loaded
into
running
when
the
device
is
powered
on
all
the
physical
results
is
present.
F
F
So
here
gives
the
life
cycle
of
the
system
configuration
and
a
synchronization
between
system
and
running
data
store
can
be
reflected
here.
First
diagram
you'll
stress
the
initialization
during
reboot.
When
the
device
boots
it
generates
system
configuration
in
system,
then
it
loads
the
saved
startup
into
running
and
at
the
top
at
the
time
of
loading
startup,
some
special
functionality
may
be
enabled
so
conditional
system
configuration
may
be
created
in
system.
F
F
F
F
A
valid
create
operation
must
fail
with
a
data
exist,
error
tag
and
a
valid
delete
operation
must
succeed.
On
the
other
hand,
in
the
explicit
basic
mode
ending
system
configuration
up,
any
system
update
will
not
be
loaded
into
running
so
for
a
system
configuration
data
node
that
is
not
explicitly
set
by
the
client.
A
create
operation
must
succeed
and
a
delete
operation
must
fail.
A
valid
delete
operation
attribute
for
a
data
node
explicitly
set
by
the
client
must
succeed.
F
I
think
that
exactly
indicates
the
key
values
of
our
draft,
since
we
have
avoid
synchronizing
into
running
manually
when
reference
the
system
configuration,
but
you
can
still
put
it
into
running
manually
in
the
explicit
basic
mode.
In
addition,
we
propose
a
standard
system.
Configuration
that
hand
only
behavior.
So
we
would
like
here
to
collect
some
feedback.
Is
this
problem
worthy
of
discussion
and
is
our
proposal
reasonable
enough
and
in
comments
and
suggestions
would
be
much
appreciated
and,
of
course,
contributions
and
causes
overcome?
E
So
so
I
think
this
is
an
interesting
idea,
so
thank
you
for
presenting
this.
I
think
we
need
to
be
very
careful
that
what
you're
proposing
here
doesn't
break
some
of
the
axioms.
E
I
should
this
is
all
as
a
contributor
break
some
of
the
axioms
that
the
nmda
architecture
is
trying
to
define
which
is
really
trying
to
allow
the
running
data
store
the
contents
of
it
to
be
controlled
by
the
clients,
the
operators
and
not
be
modified
by
the
device.
So
that
was
the
aim
of
that
architecture
and
sort
of
quality
to
that
is
the
desire
to
allow
that
configuration
to
be
validated
off
the
device
if
possible.
E
So
the
aim
there
is
to
have
all
of
the
configuration
that
you
need
to
get
the
the
system
running
available
in
one
go,
but
I
do
acknowledge
that
in
some
cases
you
have
the
system
created
configuration
coming
to
the
system,
it's
in
operation.
You
don't
see
this,
so
I
think
the
idea
of
of
having
a
system
data
store
is
interesting.
It's
worth
exploring
and
having
that
feed
into
operational
makes
sense
to
me.
E
I
that
the
ability
of
it
updating
running
automatically
seems
dubious
to
me,
I'm
not
sure,
that's
a
good
idea,
and
I
didn't
really
understand
how
that
ties
in
with
the
two
different
basic
modes.
If
that
was
your
with
defaults
handling
or
not,
I
think
that
that
is
probably
not
the
right
approach,
but
you
could
have
manual
rpcs
in
my
mind
that
copied
configuration
from
system
into
running,
that's
driven
by
an
operator
to
do
that
and
say,
okay.
E
I
want
you
to
move
this
over
this
time,
but
I
think
we
need
to
be
very
careful
not
to
change
the
fundamental
axioms
of
how
the
nmda
architecture
is
working.
Otherwise
I
think
it
will
devalue
that
architecture.
F
Okay,
thank
you
for
the
comment.
I
think
we,
our
intent
here,
is
trying
to
maximize
the
convenience
of
the
client,
because
the
client
retrieves
the
system
configuration
from
operational
and
then
put
it
into
running
into
running
manually.
The
operation
is,
could
be
complicated
with
low
efficiency
and
when
the
system
configuration
got
updated,
the
client
cannot
detect
it
automatically,
but
the
same
updates
should
be
reflected
into
rounding.
So
we
think
that
it's
unreasonable
that
the
system
generates
a
configuration
automatically,
but
the
client
needs
to
reconfigure
it.
F
Regarding
the
two
two
basic
modes,
the
report
or
basic
mode,
will
update
running
with
the
system
configuration
in
the
system.
Data
store
automatically
that
resolve
our
issue,
but
we
still
reserve
the
explicit
basic
mode
is
to
be
compatible
with
the
existing
mechanism,
because
I
think
for
some
implementations
they
maybe
cannot
afford
to
change
a
large
logical
code
so
that
they
can
support
explicitly
only.
J
Yes,
we
hear
you
okay,
so
three
comments.
One
is
that
we
already
have
a
rfc
about
a
factory
default
configuration
which
seems
to
somehow
that
that
should
be
included,
at
least
in
initialization
use
case.
J
The
other
comment
is
that
I
don't
find
this
mick
are
using
the
report
or
an
explicit
mode
and
these
terminology
from
with
defaults
intuitive.
In
this
case.
J
I
think
that
that
was
all
really
for
more
for
reporting
something
than
than
for
actually
configuring
anything.
I
would
probably
use
a
different
terminology,
and
the
third
is
that,
although
it's
not
popular
in
our
circles
but
other
standard
organizations,
for
example,
3gpp
do
use
systems
that
automatically
configure
parts
of
the
running
configuration
it
has
its
problems
definitely,
but
they
do
use
that.
J
H
Hi,
this
is
ching
actually
to
answer
the
question
raised
by
the
robert
williams.
Actually,
he
suggested
maybe
use
ibc,
but
you
know
for
kalani
initiated
this
rpc
how
the
client
detects
the
system
configuration
changes.
So
this
is
the
challenges.
So
that's
why
we
haven't
think
about
how
to
use
this
rpg
to
address
this
issue.
A
E
G
F
G
Yes,
but
I
was
saying
that
if
you
were,
if
you
were,
took
the
approach
that
you
weren't
doing
a
writable,
a
writable
running
type
of
approach,
you
were
doing
you
know
the
approach
that
you're
similar
to
the
approach
that
you're
doing
now
and
and
but
you
were
the
the
other
method-
was
to
say
if
I
use
rpcs
and
I
use
subscriptions,
why
wouldn't
I
just
use
the
subscriptions
on
operational
right
and
then
the
client
would
use
the
rpcs
to
write
into
running.
You
wouldn't
need
a
system
data
store.
E
Just
to
reply
to
tim,
I
think
one
difference
would
be
that
the
system
data
would
show
you
purely
the
system
configuration.
Whereas
what
is
in
operational,
it
is
possible
that
some
of
those
system
values
might
be
overwritten
with
explicit
configuration
or
other
values
that
come
elsewhere.
So
what
use
operation
wouldn't
necessarily
have
all
that
system
configuration
an
example
would
be
an
interface
that's
created
automatically
because
it
exists
a
physical
interface
on
the
device
that
would
live
in
system.
E
But
if
you
were
using
that
interface,
you'd
have
explicit
configuration
as
well
to
configure
the
properties
of
that
interface.
So
what
you'd
see
in
operational
would
be
labeled
as
configuration
coming
from
intended
rather
than
system,
so
there
would
be
a
difference
between
what
you
would
get,
whether
that
would
actually
matter.
I
don't
know,
as
it
may
be,
that
that
is
not
important.
Given
that
you've
already
configured
those
those
properties,
it
may
be.
The
fact
that
you
don't
see
them
in
operational
doesn't
matter.
E
Absolutely,
but
I
think
it
only
returns
a
single
value
and
I
can't
remember
if
it
tells
if
it
gives
a
precedence
to
the
different
orderings.
But
I'd
always
imagine
that
if
you
had
an
interface
that
comes
from
both
explicit
configuration
and
system
that
what
you
report
is
the
explicit
configuration
it
seems
to
be
of
higher
importance.
Whereas.
G
G
B
B
Kent
has
a
contributor
responding
to
tim.
I
think
that
same
issue
is
was
in
discussed,
slash
envisioned
in
the
nmda
work,
with
dynamic
data
stores,
at
least
you
know
there
we
defined.
We
said
that
if,
if
the
configure
value
you
know
came
from
the
dynamic
data
store,
then
I
think
the
origin
value
would
specify
that,
but
it
didn't
ever.
You
know
if
there
was
a
multiplicity
of
dynamic
data
stores,
while
the
collection
of
them
were
envisioned
to
be
processed
after
intended,
how
they
would
be
processed
amongst
each.
B
You
know
the
ordering
amongst
themselves
was
never
defined
and
sort
of
left
as
future
work,
and
it
seems
to
me
that
this
system
data
store
would
have
to
be
viewed
in
that
way
as
well.
B
H
B
Yeah,
it
would
be
best
if
we
could
have
a
discussion
on
the
list
for
each
of
these
drafts
and
sort
of
break
have
that
discussion
come
to
a
head
before
we
initiate
any
sort
of
adoption.
Thank
you.
Okay,.
H
A
So
while
kent
is
trying
to
bring
up
the
slides,
so
we
wanted
to
take
the
remaining
time
we
had
initially
anticipated
this
finishing
a
little
earlier,
the
rest
of
the
presentation,
but
anyway
with
the
remaining
15
minutes.
The
topic
really
is
about
what
we
want
to
do
next
with
rescant
and
x
resconf.
A
So
next
slide
please.
So
this
is
a
question.
Is
open
forum
feel
free
to
jump
on
the
queue
and,
if
you
want
to
suggest
something,
I
don't
have
an
ordered
sequence
of
things
that
I
want
to
go
through,
but
there
are
some
fundamental
questions
that
we
probably
want
to
try
to
get
an
answer.
To
first
is:
does
the
workgroup
feel
that
the
protocols
have
been
mature
have
been
implemented
and
maybe
needs
either
minor
tweaking
or
maybe
a
major
revision?
A
And
if
so,
is
it?
Do
you
want
to
target
both
net
comp
and
rescum
protocols
for
revision,
and,
as
maybe
the
question
of
deciding
whether
it
is
a
minor
tweak
to
the
protocol
or
major,
would
be
decided
based
on
the
issues
that
we
decide
to
address,
so
that
obviously
brings
up
the
question
of
what
issues
that
we
do
want
to
address.
If
we
do
want
to
wrap
the
protocols,
there
is
a
list
of
issues,
maybe
next
slide,
we
can
just
flash
it.
A
A
So
back
to
the
question
to
the
working
group,
oh
there's
a
corrected
url.
I
guess
it's
not
next
is
netconf
anyway.
So
the
question
back
to
the
working
group-
and
I
is
do:
does
the
working
group
feel
that
these
protocols
are
ripe
for
a
revision
and
I'll
pause
this
to
see?
If
anyone
has
any
comments.
B
Hi
match
as
a
contributor
and
also
as
presenter,
I'm
just
going
to
move
to
the
next
slide,
so
people
can
at
least
see
that
slide.
While
we're
having
this
conversation,
there
are
some
rest
conf
next
issues
as
well,
but
so
as
a
contributor,
I'm
aware
of
the
fact
that
netmod
working
group
also
has
a
yang
next
tracker
and
with
a
desire,
I
think,
there's
over
a
hundred
issues
that
are
being
tracked
there
over.
B
You
know
for
the
past
three
or
four
years
now,
it's
probably
getting
ready
for
some
work
to
be
initiated,
and
you
know
so
to
what
extent,
if
you
know
with
these
protocols,
should
they
any
update
to
them
to
be
deferred
until
that
effort
and
that
mod
has
resolved,
or
at
least
has
kicked
off.
So
we
there's
more
visibility
into
what
it
looks
like.
A
Yes,
I
mean
there
would
be-
I
guess
some
follower
from
whatever
yang
next
decides
to
address
when
they
decide
to
address
yang
next.
I
think
that
is
at
least
one
item,
maybe
in
the
rest
count
not
in
the
restaurant
in
the
next
next
set
of
issues
that
has
to
do
with.
I
think,
if
you
bring
up
that
slide,.
A
Has
to
do
with
cleanup
of
the
specification
relative
to
yang
xml,
so
we
do
allude
to
what
we
do
know
as
it
takes
us
in
the
young
rfc.
But
we
don't
know.
Of
course,
what
will
yank
next
might
bring.
A
But
I
think
there
is
a
lot,
a
larger
issue,
which
probably
has
to
do
with
quick
as
a
transport
so
and
rob
wanted
to
particularly
highlight
that
so
I'll.
Let
him
speak
to
the
question
of
what
impact
quick
might
have
on
both
the
protocols
rob.
E
Yes,
I
was
hoping
to
hear
more
input
from
other
participants
in
the
working
group,
I'll
just
let
you
know
my
thoughts
as
a
participant.
So,
first
of
all,
quick,
that's
pretty
much
it's
through
the
isg
now
and
it's.
I
think
it's
probably
on
its
way
to
the
rfc
editor
that
it's
quite
got
through
there.
E
Yet,
but
but
quick
is
the
new
version
of
tcp
in
essence
along
with
tls,
and
it
does
have
some
features
that
may
be
of
interest
to
us
for
net
confidence,
particularly
to
do
with
telemetry
the
fact
that
it
allows
sessions
to
be
set
up
more
easily
and
it
allows
separate
streams
to
be
carried
within
the
same
protocol
session.
So
I
think
it's
certainly
worth
thinking
about
quick,
whether
that
is
useful
for
netconf
and
correspondingly
http
3,
which
is
the
same
as
http
2,
but
over
quick
for
resconf.
E
In
my
mind,
the
question
is
to
whether
we
should
concentrate
on
one
protocol
or
the
other.
I
think
that
they
both
have
different
goals
that
they
are
serving
and
hence
I
think
it
makes
sense
to
try
and
work
on
both
of
them
over
time.
I
don't
know
whether
this
is
the
right
time
or
not,
but
I
do
think
that
it's
potentially
worth
looking
at
to
see
if
it's
now
time
to
to
to
consider
revolt
evolving
these
protocols.
A
A
A
I
Okay,
very
good
thanks,
so
there
are
plenty
of
features
right
and
I
see
them
on
the
two
links
that
you
shared
right.
I
see
jaylen
encoding,
support
and
netcam
great.
There
are
plenty
of
things
you
could
be
doing,
but
what
would
be
interesting
is
to
understand
what
are
if
all
these
features
are
coming
from
real
operators
right
and
if
that
be
the
case,
then
it
means
that
we
know
what
we
work
on,
because
these
are
paint
point
in
developing
or
new
features
that
they
want.
I
B
Right
as
a
contributor,
this
counts.
I
was
thinking
the
same
thing
like
if
I
I
mean
at
least
as
I'm
aware
I
don't
know
any
pain
points
that
are
being
expressed
by
operators
exactly
you
know,
I
mean
we
have
a
certain
number
of
drafts
that
we've
are
in
flight
right,
some
that
are
chartered
and
some
that
are
not
yet
chartered.
B
For
instance,
the
list
pagination
work,
something
that's
been
discussed
and
it's
been
highlighted
as
a
pain
point
of
sorts,
but
for
that
draft
and
and
others
that
are
in
in
progress,
they
are
in
updating
existing
netconf
rocs,
as
opposed
to
replacing
them
with
business.
B
And
so
I
would
hope
that
maybe
you
know
we
could
continue
doing
that.
You
know-
and
I
don't
know,
if
that's
possible
with
quick
if
that
would
necessitate
a
biz
of
the
rfcs
or,
if
it's
possible,
to
do
as
an
update,
but.
B
E
Just
respond
to
your
question
kent
on
quick,
I
certainly
there
is
a
a
draft
in
the
quick
working
group
for
doing
netconf
over
quick,
but
I
presume
that
that
is
merely
doing
exactly
what
it
does
today,
but
with
just
quickest
underlying
transport,
as
in
I'm
not
sure
you
potentially
are
making,
it
would
allow
netconf
or
telemetry
to
be
making
use
of
the
new
capabilities
of
quick
or
it's
just
a
standard.
This
use
this
is
the
transport,
so
so
that
what
you're
proposing
is
these
point
updates?
Maybe
that's
possible,
I
don't
know
it's
worth
investigating.
E
I
do
wonder
whether
there's
when
it
gets
to
a
large
enough
set
of
them,
whether
you
need
to
do
something,
that's
a
bigger
change
and
again
the
other
one.
I
think
on
there
is
things
like
the
binary
encoding.
I
think
that
mahesh
had
a
go
at
doing
that,
but
it
looked
like
it
was
getting
a
bit
tricky.
I
guess
to
do
that
as
an
update,
so
I
don't
know
if
it
will
just
stop
some
of
this
work
happening.
E
B
Well
and
one
I
see
time
in
the
queue
but
quickly
responding
to
rob.
One
thing
that
occurs
to
me
is
that
you
know
if
you're
going
over
quick
that
might
necessitate
allocating
a
new
port.
B
Currently,
you
know
rescon
servers
and
netcom
servers
have
dedicated
ports,
so
perhaps
a
different
port
would
need
to
be
used.
B
G
I
was
speaking
to
mute
so
for
a
couple
other
standing
standards,
bodies
that
we're
currently
working
with
and
having
discussions
with
operators
as
well
on
on
certain
features
we
constantly
or
we
come
up
against
questions
about
the
utilization
of
yang,
with
with
grpc
and
and
gpb
right.
In
fact,
I
had
some
discussions
earlier
this
morning
with
an
operator
on
on
a
topic
or
a
couple
of
operators
on
a
topic
with
that
right.
G
So
I
I
don't
know
if
that
fits
into
a
rest,
comp
type
of
transport
binding
and
encoding,
or
if
that's
its
own.
You
know
you
got
rest
conf
net
conf
and
something
else
conf
right,
grpc
conf
or
something
like
that.
I
don't
know,
but
it's
a
it's
interesting
that
you
know,
particularly
as
we
get
into
telemetry
or
we
get
into
control,
plane
relay
and
we
want
to
utilize
yang
as
a
as
a
way
of
conveying.
You
know
that
the
semantics
of
the
of
the.
F
G
Data
model
effectively
the
data
model,
it's
grpc
and
and
gpb
as
a
way
of
encoding.
It
is
becoming
more
and
more
acceptable
right,
and
so
I'm
not
quite
sure
what
that
means
in
terms
of
netcomp
and
rest
comp,
if
that's
just
a
binding
or
if
that's
a
new
protocol.
A
Okay,
so,
and
since
we're
coming
up
to
the
end
of
the
meeting,
let
me
just
quickly
summarize
what
I
understand
of
the
comments
that
we
have
received
till
now.
A
I
absolutely
agree
with
benway
as
far
as
trying
to
get
more
operator
input
in
trying
to
decide
what
are
the
issues
that
we
want
to
try
to
address,
and
maybe
that
will
of
course
decide
whether
we
have
both
the
protocols
or
just
one
of
them
and
what
are
the
features
we
try
to
address
as
part
of
that,
but
I
think
rob's
point
about
the
fact
that
the
quick
protocol
itself
might
associate
a
rev
for
both
the
protocols
is
an
important
consideration
to
have
it's
not
something
we
might.
A
We
can
decide
to
ignore
for
some
period
of
time,
but
I
think
if
adoptions
go
ahead
as
they
are
for
quick,
then
we
might
come
back
and
have
to
look
at
saying
what
it
takes
to
what
changes
would
be
needed
for
risk
on
the
next
netcon.
But
so
that's
my
observation
of
based
on
the
comments
that
I've
seen
till
now.
So
we
can
continue
the
discussion
on
the
mailing
list
and
understand
anyone.
Has
anything
else
they
want
to
add.
A
Okay,
so
we
are
at
the
end
of
the
hour
and
the
end
of
the
meeting.
Thank
you
everyone.
We
will
be
posting
the
minutes
of
the
meeting
once
when
kent
and
I
have
had
a
chance
to
go
with
them
and
thank
you.
Thank
you.
Everything.