►
From YouTube: IETF102-NETCONF-20180716-1330
Description
NETCONF meeting session at IETF102
2018/07/16 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
A
So
while
you
are
speaking
and
on
the
might
make
sure
that
you
do
state
your
name
clearly
enough
for
people
to
know
who
you
are
and
for
people
who
are
taking
notes
of
course
speak
into
the
mic,
the
blue
sheets
have
been
handed
out.
Make
sure
that
you
have
entered
your
name
JavaScript.
We
do
need
a
JavaScript
default,
JavaScript
adei,
so.
A
A
The
Netcom
frisk
on
client-server
suite
of
droughts
are
kind
of
work
in
progress.
The
yank
push
suite
address,
which
we
I
guess
we'll
also
discuss
today,
are
also
work
in
progress.
The
nmda
suite
of
drafts
and
that's
include
78
95
biz
and
in
the
Netcom
press,
conf
are
already
in
ic
publication
queue
and
UDP
pub
channel
is
still
work
in
progress.
A
Anything
else
you
want
is
the
agenda.
For
today
for
chartered
items
we
have
Eric
and
Alex
talking
about
the
FTP
updates
to
yank
push
and
their
related
drafts,
followed
by
Ken
that
he'll
talk
about
the
status
of
client
server,
drops
and
issues
they're
in
and
the
last
item
on.
The
chatted
item
is
about
you
to
be
based
publication
chance
that
will
be
followed
by
nan
chattered
items,
and
we
have
a
few
of
those
I
won't
necessarily.
B
C
C
Let's
go
on
now,
we've
been
in
working
group
last
call
and
started
a
little
while
ago
for
the
three
drafts
that
we're
trying
to
push
as
the
first
set
from
the
overall
suite
of
drafts.
That
includes
a
custom
subscription
to
event
streams,
the
yang
data
store
subscriptions
and
the
Netcom
support
the
session
here
is
going
to
be
talking
about
a
couple
of
the
other
of
the
drafts
that
are
not
yet
ready
for
for
completion.
That's
the
rest,
comp
stuff,
as
well
as
the
notification,
headers
and
bundles.
That's
also
part
of
this
suite
of
drafts.
C
But
all
a
lot
of
the
items
are
dependent
on
the
first
three
drafts
or
the
first
two
drafts,
at
least
for
getting
the
base
infrastructure
for
subscriptions
nailed
down
reposed,
and
that's
what
we've
been
trying
to
accomplish
with
a
lot
of
the
mails
that
you've
seen
on
the
mailing
list
now
to
get
some
context,
we
did
start
on
the
stuff
about
night
and
2814
across
I,
Taurus
and
net
Kampf.
In
the
time
since
we
started,
there's
been
some
parallel
industry
work
going
specifically
with
OSI
to
limit,
read
yang
and
Gianna.
C
My
and
the
other
efforts
have
progressed,
and
the
real
pressure
in
this
point
at
this
point
is
to
complete
the
work
so
that
we're
able
to
provide
something,
the
industry
so
that
the
implementations
don't
go
all
their
paths,
because
we
weren't
able
to
close
and
that's
one
of
things.
We
have
to
recognize
that
there
is
a
a
window
of
relevance.
Ballasts
have
a
message,
just
I
guess
started.
Last
week,
yang
pushed
now
trying
to
say
that
there
is
a
window
for
closing
some
of
these
specs.
C
If
we
one
hit
relevance
for
a
subset
of
the
drafts,
there
are
new
drafts
over
in
the
in
the
yang
push
side
such
as
the
Comey
stuff.
That
Hank
is
talking
about,
which
maybe
does
have
a
longer
time
window
for
relevance,
but
there's
still
desire
to
get
the
basic
basic
infrastructure
going.
So
this
other
drafts
can
build
upon
it
terms
of
changes
with
working
group
coalesce.
So
far,
there
have
been
a
number
of
comments,
real
heads-up
and
thanks
to
to
Martin
and
Kent
for
doing
a
lot
of
the
heavy.
C
The
comments
here
there's
been
a
lot
of
good
interactions,
things
that
have
been
changed
as
we've
moved
receiver
address.
I
know,
there's
been
some
comments
back
and
forth
for
a
number
of
people.
Oh
that's
appropriate,
but
I
think
we
did
settle
a
on
on
removing
address
from
the
common
model
and
putting
all
the
transport
specific
parameters
in
the
transport
draft.
We
added
a
very
small
update
for
replay
previous
event
time
to
make
the
lost
discovery
easier
for
a
new
subscription
started
for
configured
subscriptions.
We
did
some
minor
renaming
of
event.
C
Counters
desi
became
an
optional
feature
at
last
working
group
and
there's
another
wording
tricks.
There's
one
open
mechanism
which
I'm
hoping
to
talk
about
next
slide,
and
that
is
do
we
have
support
for
configured
subscriptions
and
replay
and
we'll
be
talking
about
that
one
on
our
next
slide.
We're
hoping
to
get
an
answer
for
for
that
here.
The
basic
issue
is
this:
for
configured
subscriptions,
there
is
a
need
to
figure
out
when
that
subscription
started,
because
it
continues
to
reboot.
What
do
you
do?
Do
you
do
it
at
the
reboot
time?
C
Do
you
figure
it
at
the
time
when
the
transport
session
comes
up
and
in
terms
of
the
apps
that
I've
been
seeing?
A
lot
of
them
are
dealing
with
security,
really
if
they
want
replay,
they
want
to
replay
from
the
point
where
the
boot
is
going
and
the
thread
we've
had
is
really
do
we
really
need
it
configured
subscription
capability?
What
do
we
do
if
we
don't
have
that
capability
in
here,
so
at
least
for
some
places,
our
classes
of
applications
which
do
need
a
start
point
which
is
nailed
down
a
particular
time?
C
C
There
is
requirements
on
the
receiver
that
must
be
supported
and
also
importantly,
if
you
have
four
or
five
receivers,
if
you're
trying
to
get
the
same
set
of
events,
there's
no
way
to
time
it.
So
the
events
start
from
the
same
period.
So
I
guess
the
first
question
to
ask:
you
guys
see
if
we
can
get
feedback
and
hopefully
close
this
one
way.
Another
is
an
option
determined
whether
we
support
configured
replay
or
whether
we
don't
and
either
way
it's
fine.
C
B
D
Sorry
I
just
this
is
Hank
just
like
clarifying
question.
There
is
a
replay
feature
for
streams
already
for
notifications.
They
have
a
history,
so
in
theory
the
the
mechanics
to
do
some
kind
of
replay
are
oddly
in
place,
they're
not
applied
to
the
data
store.
They
are
available
for
the
stream
option.
Correct.
D
C
D
We
have
replay
on
a
configured
subscription
for
a
stream,
but
as
I
I'm
new
to
this
event.
So
there
is
a
kind
of
history
we
play
already
in
there
somewhere
right.
You.
C
B
That's
a
good
lead-in
if
I
understand,
if
a
lost
connection
would
require
another
subscription
started
notification
right
it
could
you
would
write,
and
currently
it
is
the
case
that
the
client
would
have
to
do
a
dynamic.
The
draft
says
the
client
should
do
a
dynamic
description
to
fill
in
any
gaps
as
correct
so
already,
there's
this
a
function
or
a
requirement
for
clients
to
do
that.
So
this
is
just
a
special
case
of
when
the
box
is
rebooted
and
it's
starting
as
configured
descriptions.
C
B
B
C
Author's
choice,
I
guess
alright
option,
one
I
mean
it
just
closes
it.
It
provides
a
feature
alright
from
there
yang
push.
They're
really
only
been
minor
review
comments
based
on
this,
so
there's
not
really
much
work
at
all
to
be
reporting
on
that,
so
the
so
the
working
group
last
call
for
gangwish.
As
far
as
you
know
there.
The
comments
are
closed.
C
Alright,
so
the
more
interesting
draft
comes
down
to
the
Netcom
event
notifications,
in
other
words
the
transport
draft
for
net
comp.
We've
had
a
number
of
wording
updates.
We've
changed
some
examples,
but
the
most
interesting
discussion
since
last
go-around
was
a
proposed
yang
augmentation
for
call
home
to
to
the
ITF
net
comp
server
yang
drafts,
which
we'll
be
hearing
about
later
now,
the
question
of
when
to
do
that.
Augmentation
is
relevant
here.
As
we
know,
we
need
some.
You
know
yang
push
now
type
stuff.
C
Do
we
wait
for
the
for
the
configured
subscription
support
in
order
to
close
one
or
more
of
the
drafts,
and
so
the
real
question?
That
is
the
unresolved
question.
That
is
the
the
big
one.
To
hopefully
close.
The
set
of
drafts
out
is
the
question
of.
Do
we
progress
only
the
dynamic
subscription
requirements
through
last
call
or
whole
and
then
hold
off
for
a
biz.
C
Once
the
Netcom
server
yang
supports-
or
do
we
just
finish
our
current
slides
the
drafts,
or
do
we
go
ahead
and
refactor
all
the
work
back
through
the
original
drafts
of
the
yang
push
and
configured
subscriptions
two
totally
separate
contribute
configured
subscriptions
there.
That's
the
big
question
for
the
group,
and
so
the
question
that
I'm
trying
to
expose
here
is
that
the
need
for
a
transport
draft
or
net
cough
does
close
the
question
needed
now
of
do
we
support
the
current
version
of
net,
confident
notifications
or
variation
where
the
net
cough
event.
C
Notifications
just
supports
configured
subscription.
Sorry
dynamic
subscriptions,
so
that's
the
main
issue:
I'm
gonna.
Try
to
open
the
issues
up
on
the
next
slide
and
that'll
be
the
next
book.
So
yang
push
now
thread.
How
do
we
get
to
closure?
There's
really
three
options.
The
first
option
is
the
three
current
drafts
provide
dynamic
and
configured
together.
C
We
can
be
done,
I
mean,
as
you're
gonna
point
it
out
on
the
thread
it's
better
to
have
80%
than
120%.
The
authors
definitely
believe
that
you
know
the
four
years
of
work
that
we've
done
so
far,
get
us
to
a
reasonable
and
implementable
set
of
features,
and
it's
matching
as
best
as
we
could
to
the
Charter
of
having
both
configured
subscriptions
and
dynamic
together
with
support
for
different
transports.
C
So
that's
the
authors
preferred
option,
there's
an
option
to
which
is
dynamic
and
configured
subscriptions
together,
which
includes
the
current
subscribed
notification,
a
Yank
push
without
changes,
but
also
then,
an
update
of
net
comp
notifications
that
just
supports
dynamic
subscriptions,
there's
a
thread
with
Kent
and
I,
where
we
divided
up
what
that
would
actually
mean
and
there's
an
open
question
of.
Is
it
you
know?
C
Is
it
a
support
of
this
viable
now,
as
well
as
support
of
enhancements
to
Netcom
notif
when
ITF
Netcom
server
completes
so
there
you
know
it's
not
a
really
big
change
to
have
a
net
count
only
dynamic
subscription
draft.
The
authors
believe
that
that
would
be
a
fairly
minimal
time
delta
and
it
would
be
okay
to
make
the
kind
of
changes
that
we
had
tret
chat
tracked
with
the
kenta
a
few
weeks
ago.
The
last
question
is:
do
we
hold
configured
subscriptions
off
after
dynamic,
subscribed
notifications
and
yang
push?
C
We
authors,
and
you
might
have
seen
it
now,
because
comment
really
do
not
believe
that
is
the
right
path,
mostly
because
the
yang
model
and
the
documents
are
so
intertwined
after
four
years
of
work,
that
it
would
be
extremely
difficult
to
tease
apart
these
elements
and
and
it
would
require
refactoring
the
yang
model
and
and
all
all
the
text
in
those
first
drafts.
So
based
on
that
and
based
on
the
fact
that
we're
at
the
very
end,
we
strongly
recommend
against
that
and
probably
would
be
looking
for.
C
Different
authors
who'd
be
willing
to
complete
the
work
if
we
are
willing
to
go
down
the
step
of
a3
just
because
just
because
we
just
believe
it's
at
the
market
time,
in
fact
out
of
clothes.
So
the
last
I
think
things
we
have
to
hear
now
is:
if
people
have
a
choice
of
the
first
one
which
is
done,
the
second
one
which
is.
D
Again,
a
clarifying
question:
I'm,
Hank
and
I:
just
looked
it
up,
so
the
milestone
says
September
18
for
a
start
of
working
group
last
call,
so
is
this
dependent
on
being
are
going
to
ask
all
completed?
That
could
be
a
long
time,
and
this
has
minimal
data
and
and
the
milestone
does
not
end.
It
looks
encouraging
and
with
respect
to
minimal
time
data.
Yes,.
B
Mahesh
and
I
modified
the
milestones
recently.
Our
thinking
was
that
that
September
milestone
would
be
for
the
a3
up
surprised
to
hear
it
might
take
longer.
The
idea
is,
it
could
take
less
time
if
you
know,
if
we
do
the
a
one
option
so
I
know
the
full
address
perspective,
it
looks
kind
of
done,
but
still
there's
things
in
flux
and
especially
with
the
notice
and
you
know,
there's
still
discussions
and
there
may
be
a
dependency
on
the
client
server
drafts
which
could
actually
push
out
when
you
know
it
could
become
RFC's.
B
B
A
two,
so
there
was
a
comment
about
it:
whether
or
not
it's
viable
and
I
do
want
to
sort
of
touch
on
that,
because
I'm
not
sure
if
we,
if
we
can
actually
do
a
two,
if
I
understand
it
correctly,
the
idea
would
be
that
the
SUBSCRIBE
notifications
yang
would
have
config
through
nodes.
You
could
configure
a
subscription,
you
configure
a
list
of
receivers
and
then,
when
you
get
down
to
a
receiver,
all
you
would
have
is
its
name,
there's
no
actual
like
configuring.
B
If
it's
in
that
copper,
rest
column,
for
you
know
what
IP
address,
what
port
number
or
what
security
parameters?
Nothing!
It's
just
just
that!
So
it's
really
not
confined.
What
are
you
configuring,
exactly
where's,
the
interoperability
to
it?
If
you
were
to
try
to
have
no,
you
know,
what's
the
protocol
so
I
think
I
think
a
to
leak.
I
can
understand
from
implementation.
It
could
be
done,
but
from
a
no
standards
perspective,
I'm,
not
sure
how
the
interoperable
I
do
question
if
a2
is
viable.
Does
anybody
I
think.
C
I
can
give
an
example
of
where
they're
certainly
vendor,
implementations
that
talk
about
other
types
of
transports.
So
if
you
want
to
have
a
single
subscription
model
and
use
a
vendor
Augmented
transport
node,
then
it
makes
it
quite
direct
to
have
the
basic
receiver
with
a
vendor
augmentations
for
other
transports.
So
there
are
values
and
having
the
name
for
use
for
implementations
beyond
the
IDF
certain
thing
on
Jeopardy,
please.
B
Okay,
so
back
to
again,
the
goal
of
this
is
to
try
to
get
something
to
RFC
status,
faster,
a
one
it
says
done,
but
I
think
that
against
there
could
be
dependencies
that
would
drag
it
out
into
when
it
would
get
to
RFC
status.
Until
you
know,
potentially
you
know
later
right
so,
but
if
a3
is
I
mean
here's,
the
authors
are
suggesting
that
they're
gonna
walk
away.
Then
that's
not
gonna
get
done
faster.
Unless
someone
wants
to
raise
her
hand
and
try
to
do
a
three.
B
G
B
C
B
H
Hi,
my
name
is
Rashad
Rahman
I'm,
going
to
give
you
an
update
on
the
restaurant
transport
draft.
So
here
you
see
the
changes
from
revision
for
to
revision.
Six
one
of
the
first
set
of
changes
was
error:
mechanisms
to
match
the
embedded
restaurant
mechanisms.
That
I
believe
is
section
3.3
in
the
latest
draft.
H
The
document
was
also
restructured
if
you're
a
bit,
if
you
do
it,
if,
but
you
know,
for
K
no
sex,
there's
quite
quite
a
bit
of
restructuring
Yankee
to
model
was
added
for
HTTP
specific
parameters.
That
I
believe
is
the
URI
for
the
subscription
and
the
examples
were
changed
and
the
examples
which
are
in
the
restaurant
transport
dock
now
mirror
the
ones
in
the
net.
Can't
transport
draft
upcoming
changes
for
rep.
Seven
there's
been
discussions
on
the
list
regarding
using
a
leaf
ref
for
the
for
call
home
to
the
restaurant
server.
H
H
The
last
bullet
says
when
last
call
actually
should
not
be.
One
last
call
should
most
likely
be
what
is
needed
to
go
to
working
group
last
call
so
I
think
the
fact
that
well
yes,
so
that's
a
question
to
the
chairs
and
and
to
the
room
I
mean
I,
don't
know
how
much
attention
people
have
paid
to
that
specific
job,
because
I
know
the
three
others
have
been
getting
way
more
love
there.
C
Are
a
couple
of
interesting
questions
that
were
raised
in
the
last
week?
Starting
up
another
thread?
You
can,
you
can
look
for
them,
but
that's
who
thinks
things
are
needed.
For
example,
how
do
we
get
the
rest
comp
call
home
in?
Do
we
actually
have
a
linkage
for
for
direct
connection
without
having
to
call
home
from
the
from
the
publisher
to
the
receiver?
C
The
issue
is
the
call
home.
Do
you
want
a
direct
connection,
or
do
you
want
to
go
back
to
something
else
to
inject
a
question,
a
connection
back,
and
that
was
in
these
point
on:
do
we
just
go
ahead
and
call
home
and
drive
a
dynamic
subscription
back,
so
I,
don't
think
that's
nailed
down
and
that
still
has
to
be
worked
through
on
the
list?
Okay,.
B
So
I
put
into
the
list
a
couple
times:
I
think
that
the
note
of
drafts
might
need.
We
might
need
more
of
them
right
and
so
so,
and
some
of
these
comes
her
to
the
neck
transport
as
well.
But
I
mean
there's
a
notion
of.
Is
the
server
going
to
send
the
messages
using
that
comp
as
a
client
or
as
a
tech,
op
server
using
call
home
same
for
restaurant
and
and
or
maybe
just
hhtv
to
you
to
write?
Or
you
know
and
I
know.
B
C
It
could
definitely
I
don't
think
that
the
net
comp
has
the
same
issues
that
rest
comp
does,
because
in
net
comp
there's
only
the
net
comp
client
has
to
be
the
originator
in
terms
of
the
HTTP
to
subscriptions
just
like
G
RPC.
Often
the
client
server
is
always
unidirectional.
So
the
idea
of
the
client
being
the
publisher
for
HB
2,
does
make
it
different
than
if
something's
being
originated
from
the
rest
comp
side.
C
So
the
interplay
of
client-server,
flopping,
back
and
forth
for
the
different
roles
is
something
that's
been
out
there
for
a
while,
but
I
don't
think
we've
had
sufficient
working
group
review
of
all
the
implications
there.
One
good
implication
that
we
have
to
nail
down
is
sse
sse2
for
HP
1.1,
and
that's
what
andy
has
right
now
with
with
the
rest
comp
and
the
other
authors
have
the
rest
comp
draft.
However,
you
don't
really
need
SSE
with
HTTP
2,
because
the
way
it
works
and
how
do
we
go
ahead
and
deal
with
a
legacy
support?
C
B
I'm
not
sure
if
I
understood
what
you're
saying
about
restaurant
client-server
I
understood
that
there
was
a
lot
of
concerns
about
what
like,
when
a
cop,
how
there's
a
hello
exchange
it'd
be
unusual
for
or
just
a
server
to
start
pushing
messages
without
some
sort
of
RPC
to
kick
him
off.
So
I
think
there
was
some.
Is
that
what
you're
talking
about.
C
I,
don't
think
that
actually
is
the
case
on
and
them
on
the
http/2
side
there's
plenty
of
times
they
you
can
just
stream
the
other
other
side,
because
you
have
the
need
to
do
a
a
push
and
have
to
get
a
response
back
that
your
push
is
working.
There
is
a
means
with
configured
subscriptions
to
do
effectively
in
okay
that
it's
ready
to
receive
information
before
you
push
the
updates
it's
in
the
draft,
but
we
can
talk
about
it
further.
B
B
No
you're
talking
about
the
rest,
cough
yeah,
no
distress
but
I'm.
Trying
in
general,
the
note
of
drafts
are
going
to
go
quickly,
they're
going
to
follow
a
pattern,
there's
a
sort
of
a
template
and
they're
all
gonna
argument
into
these
subscribe
notifications
model
and
do
something
so
so
you
know
if
you're
bringing
in
here
says
ITF
SQL,
Server
I
said
without
B
of
call
home,
but
you
know
there
could
be
another
draft
which
is
using
IETF,
Prescott
client
right,
so
it's
basically
also
pushing
using
rest
cough.
B
But
as
a
client
and
so
I
you
know
are
those
will
be
two
different
nodes
of
strategies
they'd
be
and
in
likewise
to
give
you
the
same
thing
with
Mecca
so
Mike,
you
know
going
back
to
sort
of
Eric's
previous
conversation
with
the
options,
a
1,
a
2,
a
3.
B
C
In
general,
I
think
that
you
know
rest
confident
and
net
comp
or
independent,
and
if
you
have
chosen
one
transport
you've
chosen
the
transport.
So
a
mandatory
to
implement
really
to
me
is
a
choice
of
the
transport
model.
Underneath,
if
you
chosen
one,
then
it
works
in
terms
of
the
net
comp
draft
I.
Do
think
that,
from
my
perspective,
no
more
changes
are
needed.
C
B
B
So
again,
originally
we
just
had
ITF
key
store
which
had
both
the
keys
and
the
trust
anchors
and
but
then
we
created
trust
anchors
as
a
separate
draft
in
an
attempt
to
get
rid
of
key
store,
but
we
wanted
up
keeping
key
store
in
the
end
and
yet
trust
anchors
remain
separate.
So
the
question
is
now:
do
we
actually
keep
them
separate
or
bring
them
together?
Trade
offs
of
keeping
them
separate
provides
more
applicable
names,
so
key
storage
s
stores,
keys
and
provides
some
modularity.
D
I've
calming
it
yes,
so
this
is
my
TC
TC
G
at
the
trusted
computing
group
hat
on
em
terminology
and
the
trusted
computing
group
differentiates
between
work
of
trust
and
shielded
vocation,
which
is
basically
the
store
and
the
key
that
the
anchor
sorry.
So
they
they
they
deliberately
divided
those
terms
and
did
not
tell
them,
call
them
a
shielded
secret,
but
would
be
both,
for
example,
but
it's
about
a
sheeted
location
about
the
capabilities
of
you
of
trust
provides.
D
A
B
Okay,
that's
option:
number:
okay,
next,
keep
the
local
key
store
keys,
so
there's
a
grouping
and
in
the
grouping
there's
a
choice
called
local
or
key
store,
which
came
from
wanting
to
have
application
specific
keys
blush.
This
was
your
common,
where
you
know
keys
that
are
not
shared
for
any
other
purpose
and
the
choice
statement
accurately
configures
single
use
keys,
but
it
makes
for
rather
busy
models
if
you
looked
at
them,
they
kind
of
busy
looking
in
ultra,
but
when
I.
B
When
you
made
that
comment,
this
is
what
I
thought
would
make
sense,
but
it
occurred
to
me
after
the
fact
that
an
alternative
could
have
been
to
instead
have
all
the
keys
in
the
key
store
and
just
let
the
application
the
operator
deal
with
ensuring
that
some
keys
are
only
used
one.
So
they're
not
referenced
more
than
once
so
do
we
stick
with
option
one
as
it
is
having
this
construct
local
or
keys
for
choice
or
eliminate
the
local
option,
and
just
have
these
in
the
key
store
and
let
the
operator
deal
with
any.
I
B
B
A
B
B
There
is
a
feature
called
a
key
store
implemented,
and
you
know
so
for
those
who
don't
want
to
implement
key
store,
they
don't
have
to,
they
could
just
have
all
the
keys
be
local,
and
so
we
could
have
if
defined,
not
key
store
implemented,
which
then
would
do
it,
but
that
would
be
a
global
on/off
switch
right.
So
whether
or
not
the
server
implements
key
store,
it's
it's
a
global
selection.
B
It
wouldn't
be
per
use
of
the
grouping,
so
you
couldn't
have
some
keys,
be
in
the
key
store
and
other
keys,
not
the
case
where
just
one
or
the
other
option,
2
is
really
the
same
as
out
from
one,
but
instead
of
doing
the
not
key
store
implemented,
you
create
something
called
local
key
supported
or
something
like
that.
But
it's
again
it's
a
global
on/off
switch,
it's
not
per
use.
B
So
what
which
what
feature
are
they
augmenting
in
and-
and
it
looks
almost
like-
a
global
selection
at
that
point
and
then
option
forward,
we
don't
attempt
to
disable
a
local
choice
at
all,
just
it's
always
available,
and
so
it's
not
what
you
want.
But
so
that's
the
rationale
behind
why
and
for
this
one
night,
a
to
Rob's
point:
I
do
have
a
preference,
I
think
option.
4
is
probably
the
better.
We
don't
try
to
limit
it,
but
you
think.
F
B
F
F
B
Alright,
next
should
some
of
key
stores
groupings
be
moved
to
crypto
types.
So
at
the
top
of
the
slide,
you
see
that
there's
five
groupings
listed
that
are
not
key
store
specific
and
then
there
are
three
groupings
that
are
key
store,
specific
and
actually
by
their
namesake.
You
can
see
that
these
are
the
ones
that
have
a
leaf
or
f2
key
store,
so
they
you
know
they
depend
on
the
existence,
the
key
store.
So
the
this
one
is
for
those
five
groupings
that
aren't
key
store
specific.
B
You
know
you
would
think
it's
it
be.
Definitely
would
want
to
do
that,
but
I
think
it's
a
little
bit
unusual
to
put
groupings
in
two
types
modules.
If
you
look
at
gang
types
or
I
am
ax
types,
you
don't
really
have
groupings
in
them,
so
it
might
be
just
a
little
bit
unusual.
From
that
perspective,
also
note
these
groupings,
the
ones
with
asterisks
is
they
actually
have
an
inline
notification
statement?
So
again
it's
a
little
bit
more
than
what
you
normally
have
in
a
types
module,
so
so
one
option
option.
B
B
Okay,
this
one
I
think
I
might
take
two
lists
actually
because
there's
probably
some
like,
maybe
Apple,
we
try
to
look
at
it's
more
well,
it'll
make
more
sense.
Okay,
next,
should
algorithm
identities,
be
moved
from
the
SSH
TLS
common
modules
to
the
crypto
text,
module
this
one's
actually
there's
a.
We
don't
have
any
solutions
for
this
currently,
so
it's
kind
of
a
open
discussion,
the
uses
for
these
identities
are
to
define
algorithms
and
their
key
definitions.
B
You
know
whether
they're
you
know
it
doesn't
matter
if
they're,
local
or
in
the
key
store
to
constrain
the
allowed
key
algorithm
types
so
as
to
conform
to
some
security
policy,
so,
for
instance,
when
you're
doing
a
handshake,
you
know
a
TLS
handshake,
they're,
a
subset
of
the
protocols
are
being
advertised
just
not
all
of
them,
so
you
know
how
the
identities
were
used
as
well
also
to
specify
a
preference
for
certain
key
types
in
order.
That's
what
I
said.
B
The
problem
is
that
there
we
have
three
sets
of
identities
right,
so
there's
identities
that
are
being
defined
at
SSA,
Jeff,
cessation
layer,
also
the
TLS
layer
and
then
and
then
finally,
at
the
key
key
store
layer,
we
have
to
have
them
the
key
store
layer
right
so
you're
creating
a
key.
What
algorithm
was
the
key
trading?
B
So
RSA
is
the
elliptical
curve
curve
first
key
length,
you
know
all
that
it's
it
has
to
be
there
because
you're
creating
a
key
but
then
you're
using
that
key
at
the
protocol
layer
and
then
there's
you
know
almost
a
different
set
of
identities
and
then
how
do
we
bring
them
together?
So
I
haven't
in
a
discussion
with
Frank
huawei
who's
into
crypto
and
also
Gary
Wu
from
Cisco.
So
hopefully
you
know
they
can
help
us
resolve
some
of
this,
but
as
well.
You
know
this
is
an
open
issue.
B
B
Okay,
that
one's
going
to
list
for
sure
next
add
a
periodic
feature
enabling
the
initiating
the
the
initiating
peer
to
optionally
support
periodic
connections.
So
this
is
in
the
client
server
drafts,
and
you
know
when
the
when
making
the
connection,
whether
you're,
acting
as
a
client
or
call
home
it
doesn't
really
matter.
It's
you
know,
are
you
having
a
persistent
connection
or
is
it
more
of
a
periodic
connection?
So
I
think
you
know
pretty
standard
is
to
have
persistent
connections.
Right
I
mean
everyone
has
the
default.
B
It's
the
easier
thing
to
do
harder
is
to
code
for
periodic
connections,
but
they're
better
in
a
way
they're
using
less
resources
and
they're
actually
more
secure.
So
there's
there's
benefits,
so
the
trade-offs
would
be.
It
seems
that
periodic
connections
are
not
commonly
implemented.
A
feature
would
primarily
be
to
accommodate
that
market
market
trend
right
just
dealing
with
reality
in
a
way,
periodic
connections
are
incredibly
useful,
but
but
by
not
having
a
feature,
we
might
not
the
end
just
industry
into
supporting
them
much
more
right.
B
And
I
see
some
other
heads
nodding
to
that,
so
I
think
often
one's
good.
Thank
you
next
and
last
I
think
adds
support
for
TCP
keeper
lives.
So
there
was
a
discussion
with
the
folks
from
the
BBF
who
are
interested
in
in
this.
The
Netcom
restaurant
client-server
models
currently
support
configuring
keeper
lives,
but
those
keeper
lives
are
assumed
to
be
happening
at
the
trip
to
a
layer
level
right
so
SSH
based
keep
Elias
or
TLS
level
keeper
lives.
B
It
turns
out
that
TLS
keeper
lives
aren't
well
supported
in
TLS
libraries,
so
open
open,
SSL
doesn't
implement
them
currently,
in
fact
they
were
implementing
them,
but
then
they
because
they
had
a
security
issue.
They
are
trying
to
take
it
out
and
there's
a
discussion,
there's
a
budding
IETF
statement.
I
think
some
of
you
saw
it
that
says
that
when
using
a
crypto
transport,
the
aliveness
checks
should
not
occur
via
the
underlying
clear
text
protocol
right
that
actually
it
introduces
a
problem
with
sorts.
B
So
there's
that
should
not
right,
but
in
that,
but
here's
the
configuration
model.
So
what
should
the
configuration
model
do?
Question
1
do
nothing
and
only
support
crypt
at
a
level,
keep
your
lives
or
do
something
to
also
support.
Tcp
keep
lives.
Okay,
so
we'll
just
do
question
1
before
we
go
to
question
two.
J
Tim
Kari
Nokia,
so
we
brought
this
up
from
the
broadband
forum
and
so
they're
looking
at
persistent
connections
that
they
need
to
keep
that
through
firewalls
and
proxies.
They
have
to
keep
that
up
and
right
now,
they've
got
to
keep
allies
going
for
it.
What
they
need
to
have
is
a
way
of
configuring
that
so
they
can,
through
these
persistent
connections,
so
that
they
can
so
they
can
manage
those
those
keep
allies
both
from
the
client
to
server
server
decline
right
the
domains,
many
of
the
domains
that
they
have
are
in
secured
area.
J
Tls
doesn't
work
because
of
the
support,
as
noted,
so
the
option
would
be
to
do
this
here
or
do
it
up
at
the
the
net
conf
layer
and
by
the
way
the
net
says
that
we
do
it
at
the
rest,
comp
layer
right
because
it's
at
the
protocol
there
or
you
allow
for
both
I
know
that
there
right
now
they
they
are
planning
on
using
these
modules
and
even
if
they
have
to
augment
for
the
TCP,
keep
lives.
They'll.
J
F
B
F
J
So
again,
Tim
Kerry,
so
I
again
I,
don't
think
they
care
if
it's
at
the
protocol
layer
so
long
as
it's
at
both
protocol
layers.
Okay-
and
it's
both
ways
that
we
do
this-
that
you
that
you
allow
for
these
configurations
and
again
you
know
they
can
just
augment
off
the
TCP
key
for
lives
in
the
short-term
waiting
for
the
drafts
to
show
up.
That's.
B
Necessary
yeah
and
one
follow-up
regarding
the
implementations
like
open
SSL
implementing
it
part
of
the
discussion
we're
having
with
the
TLS
80s
and
the
transport
area.
Abs
is
to
have
an
ITF
level
statement
that
we
can
then
take
back
to
the
open,
SSL
community
and
say:
look
you
know
here.
It
is
you
guys
really
should
support
TLS
level
people
lives
and
hopefully
get
that
implemented,
but
you
know
how
quickly
would
that
happen?
I
may
not
be
within
your
timeframe.
B
Okay,
so,
okay,
again,
currently
in
the
model
models,
there
is
a
keepalive
right,
it's
optionally
configured
and
if
you
do
configure
it,
you
know
so
that
you
know
just
like
how
often
do
you
send
people
iOS
how
many
failed
responses?
What's
the
delay,
you
know
those
kinds
of
parameters,
you
know
it
distant
for
says:
keep
lives,
it
doesn't
say
you
know,
SSH
keep
lives
or
TLS
keep
lives,
just
says,
keep
lives,
so
it's
kind
of
neutral
as
to
what
kind
of
keep
keep
lives
it
is
so
I.
Don't
really
think
it
would
be.
B
B
J
So
I
mean
what
we've
done:
management
protocols
forever
right
and
every
management
protocol,
as
it
has
a
keep
a
lot
of
mechanism
in
place,
usually
at
the
protocol
level
right.
So
that's
probably
the
preferred
approach
to
do
this.
You
know
from
both
ways,
but
there's
also
I,
think
when
you
look
at
the
draft.
There
are
some
attributions.
You
know
just
some
Leafs
that
that
probably
are
missing.
You
know,
because
you
got
the
intervals
and
lo
there's
like
two
or
three
attributes
that
need
to
be
placed
in
there.
J
You
know
again
whether
it's
at
the
protocol
would
be
preferred
the
tcp
if
they
need
up
that
they
can.
They
can
augment
it
and
right
now
that,
because
of
the
time
frame
that
it
takes
to
get
this
stuff
through
ITF,
you
know
frankly,
they're
gonna
augment
the
thing
and
waiting
for
the
drafts
anyway
right
well,.
B
Okay,
so
so
my
concern
and
by
I'm
bringing
this
to
working
group
is
that
I
didn't
I
was
concerned
that
we
might
try
to
configure
something
which
is
actually
not
recommended
from
an
IT
perspective,
but
and
I
would
be
a
TCP
keeper
lives,
but
I
think
it's
definitely
recommended
to
do.
Protocol
level
keep
lives
and
we
should
actually
add
something.
So
we
have
the
the
the
configure
whoever's
doing
the
configuration
can
choose.
Do
they
want
triple
level
people
to
keep
lives
or
do
they
want
protocol
level
keep
lives?
We
do
that
and.
J
If
you
do
that,
just
make
sure
you
feature
them
because
put
a
feature
in
there
such
that
you
know
the
people
that
may
very
well
be
going
along
the
world
for
TCP
keep
lives
can
use
that
and
they
don't
have
to
have
the
baggage
of
the
you
know.
The
application
protocol
keeper
lives
that
go
through
there,
so
there
could
be
a
time
we're
gonna.
J
So
the
problem
is
that
there's
gonna
be
a
time
where
they're,
where
they
may
very
well
have
to
tcp
keeper
lives
in
place
right
or
or
a
protocol
level
keep
alive
in
place
that
they're
not
going
to
want
the
one.
That's
out
of
the
standard,
so
just
make
sure
that
some
sort
of
a
may
on
it
right
because
they
can
feature
okay,
so.
B
K
Hello:
everyone,
my
own
I'm,
going
down
from
Holly.
Yes,
this
draft
is
about
the
udp-based
publishing
channel
and
last
night
ITF.
Oh,
we
not
do
the
petition
because
we
not
they're
not
not
so
many
discussed
in
the
Middle
East.
At
the
time
we
discussed
some
issues
and
comments
in
the
merest
Anna
we
updated
the
draft
and
because
there's
not
to
plantation
so
many
times.
So
we
reintroduce
augment
China
for
the
UDP
here
for
unity
publishing
in
channel
2.
We
asked
TCP
for,
like
overnight,
confer
address
count
for
all
or
the
IPC,
and
here
data
collector.
K
We
were
soft.
Now
country
suffer
a
lot
of
TCP
connection
from
many
line
cards
encrypted
on
different
devices,
for
the
distributed
diversities
and
has
no
connection.
Data
needs
to
be
maintained.
So
UDP
incubation
can
be
easily
implemented
by
the
hardware,
some
like
cement
chip
chips,
which
will
further
improve
the
performance
and
because
I
was
a
lightweight,
so
you
DB,
incapacitation,
high
frequency
and
better-trained
see
the
performance
can
be
achieved
which
is
important.
The
photo
stream
telemetry
and
and
a
new
udp-based
publication
channel.
We
have
promoted
here
which
a
facility
distributed
at
each
collection
mechanism.
K
Like
for
directly
populate
push
data
from
the
line
class
on
many
devices
to
a
collector
and
the
support,
multiple
encoding,
including
binary
and
all
for
Jason
yeah
and
adapting
to
the
subscriber
notification
and
a
young
push
and
enable
some
option
for
the
its
its
inability
here
is
the
transporter
mechanism.
At
this.
E
K
We
updated
in
to
the
draft
and
here
how
to
main
McNeil
way,
the
dynamic
subscription
and
a
configured
subscription.
Here
we
have
two
euro
for
collector
and
publisher
and
for
the
dynamic,
like
the
subscriber
notifications.
First
establishes
a
subscription,
then,
after
the
confirm,
replied
to
the
subscription.
K
The
instant
indications
from
Marty
Lanka's
by
the
UDP
and
the
collector
king
modified
the
subscription
by
the
control
channel
to
the
publisher
after
success
modified
successor,
the
publisher
was
the
updated,
the
future
and
maybe
some
new
subscription
and
send
it,
and
it
came
deleted
from
the
character
to
the
publisher
to
delete
the
subscriptions
and
the
multi-line
Karla
we
were
terminated
subscription.
This
is
the
for
the
dynamic,
a
subscription
and
the
folder
configure
solution
simile.
K
This
time
it
is
a
security
layer
for
with
the
TT
RS,
who
was
UDP
and
the
40gr,
so
it
provided
a
reusable
security
and
authentication
function
over
UDP
and
for
the
message.
Header
here
is
some
important
information
before
the
this
arising.
The
notification
like
that
encoding,
encoding
method
for
TPP
COBOL,
maybe
some
others
and
the
photo
may
generate
RT
for
the
line,
casts
and
a
photo
sequence
number
and
where's
the
support
of
implementation
and
some
other
options
for
its
instability
and
a
for
the
no
to
a
message.
K
It
included
a
notification
header
as
defining
another
traffic.
Current
draft
of
owners,
messages
which
just
no
alcohol
introduced
and
encoded
with
the
content.
Here
is
the
diplomates
of
the
duty,
publishing
channel
message
header
it
had
it
included
for
the
washing
for
the
header
ocean
and
a
photo
flag
like
some
options,
for
the
liability
fermentation
and
for
the
encoding
type
lines
and
a
message
and
generate
RT
to
max
of
which
source
comes
from
and
for
the
may
study
and
some
other
options.
K
F
F
B
Have
a
comment
Kent
as
a
contributor,
so
it
seems
like
for
configured
descriptions.
It
seems
like.
Maybe
we
should
have
a
note
of
truth
right
like
it
would.
It
would
actually
be
a
like
a
note
of
UDP
note
of
something
like
this
and
it
would
augment
then
to
the
receivers
list.
Just
like
a
right.
Have
you
looked
into
for
configured
subscriptions
yeah,
argumentum,
Eric,
subscribe
notification,
strap
yeah.
G
G
B
G
B
K
K
F
J
K
J
K
A
J
J
E
J
E
J
That
that's
all
I'm
just
saying
is
that
I'm
not
saying
implement
Komi
or
co-op
I'm
saying
that
header
has
got
things
there
for
reasons.
It's
got
extensions.
It's
got
the
whole
bit
that
that
you
want
to
do,
and
it's
doing
it
in
a
very
concise
fashion
right,
but
to
me
it
would
seem
like
it
would
be
something
that
maybe
you
want
to
make
consistent
right,
at
least
for
protocol
analyzers,
for
protocol
implementers
that
type
of
stuff,
okay,.
D
Hi
yeah:
this
is
Hank
speaking
as
an
IT
director,
there's
not
only
the
coop
RFC.
D
There
are
a
lot
of
extensions
to
it,
so
some
things
haven't
been
addressed
in
the
core
co-op
draft,
of
course,
in
Carmen,
Coronado
and
and
so
there
are
things
like
reliable
transport
via
WebSockets
DTS
as
a
TLS,
and
then
something
and
there's
also
like,
like
observing
resources
having
basically
a
subscription
there's
also
resilience,
there's
also
finding
a
home
using
coop,
that's
basically
unlearning
mind
so
I
think
there
are
a
lot
of
puzzle
pieces
that
are
already
there
and
what
I
would
like
to
know
what
the
gap
is.
That
was
just
been
talking
about.
D
What
if
the
video
we
incubate
something
and
then
core
or
is
its
own,
that
comes
specific,
that
is,
it
is
natural
intuitive
to
do
it
here.
So
what
I
would
really
like
to
see
is
the
gap
which
I'm
actually
really
unaware
of
so
there
might
be
a
lot
of
gaps,
but
you
have
to
have
to
look
at
all
the
building
blocks
and
core
and
in
what
you
want
to
achieve.
D
D
B
Can't
as
a
contributor
sort
of
add
on
to
Tim
and
Hanks
comments,
you
know
so
we
have
these
client-server
drafts
and
I'm
thinking.
You
know
that
complaint
server
and
rest
compliance
over
I
think
that
we
might
want
to
have
a
co-op
client
server
someday
right
and
and
if
there
were
a
co-op
client
server,
then
there
would
be
I
think
almost
by
definition
of
co-op
notif
draft
right
and
that
co-op
note
of
draft
would
no
augment
into
the
SUBSCRIBE
notifications
tree
as
well.
B
So
if
you
wanted
to
do
a
dynamic
subscription,
the
client
would
start
a
co-op
connection
to
the
co-op
server
and
basically
do
subscribe
notifications
over
co-op,
which
would
give
you
the
UDP
and
DPOs
all
that
or
if
they
want
configured
subscriptions.
They
could
configure
that
as
well,
so
so
sort
of
I'm,
I'm
I
know
we.
We
adopted
this
draft,
what
I'm
actually
questioning.
If
this
is
the
right
approach,
should
we
instead
be
actually
just
using
co-op
and
have
co-op
client
server
drafts
and
co-op
notif
and
go
that
route
instead,.
J
The
director
that
I
I
think
he's
got
the
right
approach
to
if
you
want
to
go
down
that
path.
Do
some
analysis
because
there's
a
lot
of
extensions
and
some
overhead
with
coop,
even
with
Comey
stuff,
that
they're
doing
right
I
was
just
noting
the
same.
They
solved
many
of
these
problems
and
core
right.
You
know
for
co-op
that
you
may
be
missing
some
things
right,
so
I
think
the
analysis
is
before
you
go
off
that
off.
L
J
B
Sort
of
one
more
fun
alone
comment,
a
lot
of
what
this
draft
is
about
is
allowing
the
notification,
so
we
sent
it
from
the
line
cards
themselves.
You
know,
so
they
don't
have
to
go
to
the
routing
engine,
for
instance,
to
get
sent.
How
is
it,
how
is
that
configured
like
it?
What
like,
if
you
were
to
like,
do
a
dynamics
description?
How
do
you
say
that
you
want
it
to
come
from
with
line
cards
versus
from
the
routing
engine
or
or
if
you're
doing
configured
subscription?
How
do
you
configure
that.
K
I
think
for
the
subscription
for
the
collector.
That's
me
for
the
client
for
the
subscriber.
These
are
not
depending
whether
hello
Madeline
card
right.
Just
a
configure
I
need
I
needed
your
push
to
some
receiver.
It
was
a
target
and
it's
a
system
itself.
We
decided
whether
whether
distributed
that
Madeline
had
a
st.
Midas's
yeah,
so
that
reason,
support
I,
think
for
whether
Madeline
has
or
not
is
decided
by
our
city,
the
server
itself
so
for
the
client
I
know
another
can
state
so.
B
B
Be
more
aware,
I'm,
just
thinking
that
I
mean
in
Eric
and
all
of
your
subscribe
notifications
work.
It's
always
been
the
assumption
that
there's
just
all
the
even
notifications
are
being
funneled
into
the
routing
engine,
and
then
you
know
like
that.
So
it
seems
like
we
need
to
do
something
to
a
flag
to
say
something
to
help
support
the
multi
linkers
yeah.
K
Yeah
he
is
for
the
yeah
horse
subscribe
to
multi-stream
ordinator
now
is
the
fall
was
not
drafted.
We
now
is
for
genes.
That
discussed
for
the
use
kiss
enough
for
this
draft,
I
think,
is
the
from
the
beginning
is
separated
from
the
UDP
telemetry,
yes,
which
is
castle
Erica
and
Andy,
and
some
other
guys
yeah.
We
think
maybe
for
this
the
scenario.
K
Maybe
we
can
define
it
another
draft
to
discuss
further
comment
and
say
yeah
here
for
the
use
kiss
of
pasta
with
begin
with
the
use,
kiss
I
think
you
seem
for
a
large
amount
of
data
collection
from
devices
with
main
distributor
architecture,
design,
hardware,
design
with
the
main
border
and
a
nine
class,
and
maybe
exiting
country
existing
solution.
Consider
only
when
happy
Sawa
is
studying
the
main
board,
which
is
a
team
performance,
the
board
and
Erica
for
the
collector,
when
data
are
forwarded,
ur
to
the
main
board,
yeah.
K
E
K
For
the
used
is
to
for
here
some
some
key
Caesar
for
the
ulti
collector
keynote
a
subscriber
accepted
directly
from
a
Latinos,
so
subscriber
data
from
the
maybe
for
the
bottle.
Rotor,
as
in
body
rotor,
distributes
a
substring
to
the
nose,
the
Audi
nose
stream
data
to
the
collector
through
a
border
rotors
in
the
collector
a
same
substrate
data
exists,
and
here
is
a
initially
is
ruching
overview.
K
We
define
the
role
of
the
ruching
for
character,
publisher
for
collectors
there,
as
though
it
may
be
usual
as
for
subscriber
and
a
receiver
here,
like
diagram,
yeah
and
a
publisher.
They
have
two
roles
for
master
and
a
cinta,
because
Aaron
Marcus
James
under
for
for
substance
server
and
the
components
are
in
Sawa,
like
in
the
diagram
and
now
issue
the
being
worker
is
a
full
sovereignty,
composition
to
keep
check
out
resources
and
associate
publisher
and
a
make
decision
on
that.
K
Composes
decomposing
the
calaboose
exertion
into
multiple
components,
absorption
and
for
publication
composition
to
compose
a
component
and
application
into
one,
because
the
sauce,
maybe
from
multi
stream
and
some
supreme
elements,
some
IRA
costs
related
to
the
subscription
accommodation
and
a
component
in
a
subscription
and
for
the
notifications.
The
owner,
subscription
States
changes
each
component.
A
sub
solution,
maintains
its
own
substance
States
and
is
responsible
for
sending
is
owing
away
notifications
and
some
other
potential
issues
such
as
a
synchronization,
and
so
the
discovery
may
be
net
may
be
security
yeah,
that
is
water.
A
K
A
Have
a
case
where
you
have
single
box,
which
is
acting
as
a
proxy,
which
is
use
case
to
order,
and
you
have
the
other
case
where
it's
it's
really,
the
bottleneck
right
so
and
the
individual
line
cards
are
sending
them
or
means.
This
is
the
connection
right
right,
so
you
have
one
case
where
one
is
a
proxy.
In
the
other
case,
it's
not
a
proxy.
The
line
cards
are
sending
it
directly.
So
the
question
I
have
is
to
the
common
that
Kent
made
is
when
you're
making
a
subscription
notification.
A
K
Mean
for
this
for
for
this
use,
Kies
tool
for
either
one
other
cases,
yeah
I
think
it
was.
This
is
to
use
this
not
only
be
not
seen
for
use
kiss
one,
for
maybe
the
notifications,
maybe
the
size
or
the
traffic
is
a
well
big.
So
in
this
case
the
force
used
is
one
maybe
the
main
board
over
up
upon
the
neck,
but
for
the
hour
T,
as
we
know,
maybe
there's
a
not
fiction,
not
so
many
so
different
scenarios,
no.
K
For
configuration
I
think
for
for
the
client
to
subscriber
it
are
not
concerned
whether
it
whether
it
is
distributed
or
centralized
a
for
the
generator
itself,
but
they
know
the
scenario
whether
the
new
scenario,
maybe
they're,
the
Mattie
Mattie,
so
smart
generator.
So
as
for
you
to
be
publishing
channel,
we
have
the
generator
D
yeah,
so
Anna.
For
now
we
are
discussing
how
to
define
the
for
configure
complicate.
Maybe
when
we
configure
the
subscription
they
were
is
algebra
publisher
will
require
some
parameter
like
a
to
notify
the
subscriber
with
a
Haywood
multi
lanka's
or
not.
K
C
Just
a
support
for
use
case,
one
I
definitely
think
this
is
valuable
work
and
it's
been
stuff
that
a
number
of
vendors
have
been
talking
about
for
a
year.
So
whenever
you're
ready
to
push
for
adoption,
not
certainly
say
yes,
I,
don't
know
if
now's
the
time
we're
not,
but
it's
certainly
useful
work
in
terms
of
the
configuration
versus
when,
where
the
messages
come
off,
we
have
done
a
mapping
in
the
past
of
each
individual
state,
change,
notification
and
configuration,
and
it
does
Maps
cleanly
onto
the
lines
from
the
subscribed
notification
draft.
C
B
K
M
N
A
Yeah
I
think
you
might
want
to
consider
both
the
points
that
this
person
from
Nokia
made
and
previous
comment
with
respect.
What
Kent
made
is
isn't
this.
If
this
has
already
solved
in
your
UDP
pops
had
kept
up
channel
draft,
you
may
want
to
actually
keep
the
UDP
butchered
to
deal
with
the
distributed
sending
of
notifications
and
just
pick
this
draft
just
to
the
for
the
use
case.
Yeah,
we
were.
P
Channel
from
Huawei
and
this
we
use
this
to
a
use
cases
to
introduce
a
more
general
distributed
data
crafting
framework
and
for
this
framework
atom
we
can
also
use
TCP
based
channel.
We
can
use
you
to
be
based
channel
wherever
so
here
this
is
the
framework,
but
for
the
previous
chapter
we
focus
on
the
UTP
base,
the
publication
channel.
That's
the
difference,
I
think.
A
All
right,
I
will
talk
about
binary
encoding.
Just
a
quick
recap
from
the
London
ITF.
There
were
a
couple
of
questions
on
what
is
it
going
to
be
encoding?
Our
assertion
is
that
it's
simpler
to
do
one
switch
to
a
new
encoding
format
and
do
it
for
all
the
operations.
That
would,
of
course,
include
not
not
just
edit
gate
but
but
get.
E
A
The
other
question
on
the
list
was:
is
this
also
relevant
for
restaurants
and
the
question
there
is
I?
Think
Andy
responded,
saying
there
is
already
a
content
type
header
in
HTTP
that
can
be
used
to
specify
the
encoding
format.
So
maybe
the
minimum
thing
that
we
could
agree
in
this
working
group
is
what
are
the
encoding
formats.
We
are
going
to
support
and
register
them
in
a
registry
in
IDF
and
reskin
could
use
those.
A
If
we
were
to
go
with
that
notion
that
we
switch
to
a
new
encoding
right
after
hello,
any
form
of
notification,
whatever
this
workgroup
finally
agrees
not
only
on
52
77,
but
the
newer
format
would
then
could
benefit
from
using
the
new
encoding
that
is
already
negotiated.
On
the
session
on
issue
number
three,
we
had
initially
indicated
in
0-0
draft
that
we
might
have
to
indicate
actual
start
of
the
new
encoding.
A
But
again
after
discussing
with
Andy
and
a
couple
of
other
authors,
we
believe
that
we
don't
really
need
an
explicit
activate
operation
that
the
server
will
send
an
unordered
list
of
encoding.
The
client
will
indicate
its
preference
with
an
ordered
list,
and,
whichever
is
the
first
match,
is
what
is
going
to
be
picked
for
the
encoding.
A
F
So
you
want
this
information
early
and
for
that
reason
the
proposal
is
to
define
a
yang
model
that
would
document
which
they
will
send
and
or
do
not
send
their
own
change
notifications
and
then
I
use
the
yang
instance
data
draft
to
document
that
early
in
implementation
time,
and
then
you
can
do
the
or
OSS
integration
or
the
OSS
development.
Accordingly,
okay,.
F
What
changed
since
the
last
time
I
presented
this
based
on
the
comments
from
Martin,
your
clone,
the
yang
data
model
was
simplified.
It's
no
longer
an
augmentation
to
the
ITF
young
library,
because
then
connecting
it
to
the
different
yang
will
use
individual.
It
would
be
complicated.
It's
not
the
augmenting
subscribe
notifications
either,
because
that
doesn't
have
a
single
route
which
is
good
to
augment
sets
standalone
model.
It
contains
default
values.
So
if
your
note
supports
on
change
notification
for
everything,
then
you
have
to
support.
Just
two
leaves
don't
change
defaults
and
then
you
are
finished.
F
If
you
have
that
say
some
sounds
special
in
cases,
then
you
can
specify
that
individually,
but
because
the
unchanged
capability
is
inherited
down
the
containment
model,
we
believe
there
will
be
only
few
leaves
to
individual
leaves
needed.
This
is
the
new
model.
It's
not
a
big.
It's
read-only
should
be
set
by
the
system
itself,
and
this
is
just
an
example
of
how
this
would
look
like
in
an
instance,
data
file.
Again,
there's
a
wrapper
around
it
and
then
it's
quite
simple.
F
There
are
some
open
issues
should
we
model
the
unchanged
notifications
capability
separately
for
at
the
nmda
data
stores
and
yurgin
a
beer.
Don't
argue
strongly
for
that,
sir,
you
can
shouldn't
bother
argue
strongly
for
that.
On
the
other
hand,
I
don't
see
the
use
case
why
this
would
be
needed.
If
someone
could
tell
that,
then
it
would
be
nice
and
the
names
in
the
multi
rent
model
are
too
long,
but
that's
a
separate
small
issue.
Yes,
they
should
be
made
shorter
and
I.
F
Think
I
would
like
to
request
adoption
by
the
work
group
Italy.
We
received
quite
a
bit
of
support
from
the
last
year
ITF
methinks
someone
received
some
comments
and
support
on
the
mailing
list
and
the
one
objected
really
and
the
problem
that
we
really
must
know.
If
the
font
changes
notifications
are
coming
or
not.
This
problem,
maybe
is
not
a
good
answer.
I
I
It
can
actually
choose
what
rate,
for
example,
so
you
had
cobbler
counters,
maybe
it
returns
of
every
five
seconds
every
10
seconds,
so
I
wondered
whether
in
addition
to
has
been
yes
or
no,
it
might
useful
to
have
some
way
of
saying
what
that
rate
is
a
that's
too
complicated
to
do,
because
that
might
be
I
mean
this.
Just
as
useful
is
you'll
only
get
counted
every
ten
seconds,
I.
F
Think
they're,
really
the
basic
problem
will
be.
Is
it
really
implemented?
What
is
for
that
specific
note?
Data?
Don't
I
think
that
would
be
a
much
more
common
problem
and
yeah.
If
you
look
at
this
meaningless
small
changes,
which
is
one
more
reason,
it
was
not
my
use
gaelic,
that's
one
more
reason:
why
not
implemented
this
case?
I
Another
option
could
be
to
actually
have
a
string
that
gets
returned,
so
we
can
return
and
then
the
device
could
say
just
provide
extra
information
as
to
what
that
granularity
can
be
so
doesn't
help
an
automated
device.
If
it
does
help
the
user
was
looking
at
it,
they
can
say.
Okay
finally
goes
data,
every
10
seconds,
I.
F
I
J
So
I
Tim
Kerry
Nokia
I,
wanted
to
be
asked
about
the
nmda
support
the
on
change
per
data
store
right,
so
I
know
in
other
organizations.
We
do
have
to
differentiate
whether
it's
an
operational
data
store
for
certain
elements,
particularly
like
it
be
enabled
right.
You
know
where
you
configure
it
to
enabled
versus
disabled
administrative
Lea
right,
but
then
you
have
the
operational
status
that
can
flap
back
and
forth.
B
J
The
point
is
that
we
have
attributes
least
nodes
right
that
enable
it
is
an
example
right
work
and
go
enable
disabled
right
and
it
just
what
they
did.
Is
they
grouped
it
together
in
a
single
leaf
right
and
the
data
store
is
what
provides
the
the
semantics
around
it
and
some
semantics
that
we
care
about
like
if
whether
it's
administratively
changed
do
it
on
change
for
that
right.
But
you
don't
care
about
necessarily
the
operational
status
of
it,
for
example
from
the
running
right,
because
it's
flapping
back
and
forth
there
right
and
you
just
don't.
J
You
got
too
much
perturbation
there
and
so
I'm
just
saying
that
we've
seen
those
types
of
things
and
other
management
protocols
where
that
where
they
wanted
to
turn
it
on
for
one
and
not
on
the
other
day
on
chains
right,
particularly
the
active.
This
is
an
active
notification
mechanism,
and
so
I
was
wondering
if
that
was
the
scenario
that
you
were
asking
about
right.
If
people
would
sing.
F
N
Then,
what
less
so
I
would
like
to
come
back
to
the
comment
from
the
rate
and
then
Rob
that
cetera
I
think
that
you
want
to
keep
it
simple.
The
drafts
of
a
single
problem,
which
is
you
know,
I,
would
like
to
have
one
change
on
all
my
objects
in
my
router.
Practically
it
won't
happen
for
various
reasons.
Just
knowing,
if
it's
support
or
not,
it
solves
a
great
issue
and
going
into
the
rate
and
frequency
of
what
you
said.
It's
too
complex
already.
C
Q
C
A
O
Hello,
everyone,
my
name,
is
Tim
I
want
to
introduce
this
topic
empty,
a
base
event,
and
this
topic
actually
has
been
discussed
in
the
last
idea
meeting.
Actually
we
have
to
open
you
we
discussed.
Actually
one
is
about
how
the
event
we
propose
in
this
job,
the
relative
you,
the
young,
especially
unchanging
unfortunate.
The
second
is
what
change
is
needed,
that
you
support
an
MBA.
So
after
last
idea
meeting
we
worked
out
whether
with
my
colleague
or
rocky
and
I,
try
to
resolve
this
open
issue.
O
We
seem
actually
have
potential
open
overlapping
with
young,
so
we
actually
proposed
to
replace
the
original
event
with
we
put
in
the
chapter
with
an
empty,
a
paid
beta
validation
event
and
another
open
issue.
Actually,
we
did
actually
pakka
with
the
origin,
also
the
OP
c64
78
medical
co-pays
event
document
and
whether
we
should
actually
make
a
piece
for
the
obviously
74-64
70
actually,
and
he
actually,
if
a
battery
sink
actually
is
better
to
keep
a
medical
based
event
at
as
VR,
and
we
should
define
new
event
a
specific
to
the
MDA.
O
So
also
we
responsible
to
Tim
Kelly
from
Nokia
the
comments.
Actually,
we
sink
right
now,
the
data
store
parameter
only
affect
the
net
call
for
configure
change
events
before
as
a
event
actually
there's.
No
such
data
store
parameter
so
resolve
these
two
open
issue
and
we
update
this
job
and
actually
we
write
the
post
reaction
and
introduction
and
replace
the
original
event
way,
poster
with
the
new
event
and
empty
a
data
validation.
O
So
this
is
a
use
case
for
the
an
empty
data
validation.
We
think
actually
there's
quite
background
activity
from
the
time
the
congregation
has
been
complete
committee
into
the
running
and
to
the
time
when
the
congregation
is
applied
from
intend
to
the
operational.
So
in
some
cases,
actually,
you
may
actually
some
contribution
cannot
be
applied
with
operational,
because
some
miss
results
of
validation,
failure.
So
in
such
cases,
some
for
client,
naturally
the
amount
to
know
well,
what
is
the
validation
result?
What
is
the
failure
reason?
O
So
one
typical
use
case
is
the
way
you
have
validation
have
partial
failure,
so
you
need
to
know
how
many
object
are
really
affected.
So
this
is
what
we
propose
for
the
solution.
Actually,
we
define
a
new
event
now
call
me
when,
especially
to
the
MD.
Actually,
this
event
will
be
generated
by
the
server
who
support
young
based
the
protocol
actually
to
detect
the
event
that
take
place
during
the
time
period,
as
we
mentioned
about.
O
Actually,
there
is
actually
we
call
the
event
and
say
the
change
of
the
data
validation,
and
we
think
these
are
coming
opinion
that
they
need
to
be
specific
to
the
Nanticoke,
but
also
can
be
applied
to
the
restaurant
and
other
young
face
the
protocol
Apogee
RPC,
and
we
think
we
should
inherently
the
the
management
session
parameter
from
original
medical
pace
event.
After
actually
also,
we
can
actually
allow
the
client
to
get
access
these
events
through
various
different,
separate
sub
screeching
mechanism,
and
so
this
is
the
example,
the
empty
data
validation.
O
Actually,
we
support
a
success,
failure
and
a
partial
failure
in
case
of
the
failure
of
partial
failure.
We
released
actually
a
set
of
the
obstacles
that
are
being
affected,
so
we
think
actually,
we
resolve
to
open
usual
resisted
in
the
NASA
meeting,
and
this
job
actually
has
not
been
stable.
Will
act
recall
a
requester
working
with
you
covered
option
for
these
jobs.
That's
it.
B
Can't
as
a
contributor
so
I
mean
this
is
interesting
right,
but
where,
where
we
have
the
configuration
it's
gone
to
running
and
then
intended,
but
it
whether
it's
applied
is
the
question
and
the
its
applicability
or
it
could
be
flapping.
You
know
someone
could
pull
a
line
card
or
gonna
be
different
reasons
for
why
it's
not
been
applied.
So
these
notifications.
This
is
a
way
to
provide
visibility
to
the
application
as
to
how
much
of
the
configuration
or
which
parts
of
the
configuration
have
not
been
applied,
and
so
this
would
happen
asynchronously
you
have.
Q
R
Turn
Nokia
apologize,
I
haven't,
read
the
draft,
but
just
keying
on
what
Kemp
said.
Is
this
about
determining
that
a
data
store
became
invalid?
Hence
the
word
validation,
or
is
this
a
notification
saying
hey
something
didn't
get
applied
because
the
word
validation
yeah
in
this
made
me
think
that
some
set
of
config
is
no
longer
valid,
but
what
you're
describing
us
and
the
example
seemed
to
imply
hey
this
leaf
didn't
get
applied
yeah.
My
understanding
is
the
latter.
Yes,.
J
R
B
Again,
I
think
it's
an
important
problem
to
solve,
probably
would
want
to
have
some
synchronous
way
of
determining
what
parts
have
been
applied
as
well.
I
mean
there's
a
datastore
diff
right.
So
if
you
do
the
diff
between
applied
and
operational,
maybe
that's
another
way
of
determining
what
hasn't
been
applied
so
who,
who
in
the
room,
thinks
this
is
an
important
problem
to
solve.
Raise
your
hand
please.
I
Think
you
would
continuously
monitor
the
state
operation
static
device
and
you
continuously
rationalize
that
against
the
configuration
you
were
putting
in
so
naturally
on
a
per
data
node
level.
You
would
be
rationalizing
whether
or
not
that
particular
variations
apply
it
rather
than
querying
or
not
saying
it's
a
notification
is
a
bad
thing.
It's
not
quite
sure
whether
it's
necessary
or
not
I
think
it's
okay,
I.
O
Think
one
of
us
in
that
way
we
can
see
that
actually
we
we
did
concede
actually
there's
a
lot
of
data.
You
need
in
monitoring,
so
to
really
organize
this.
Actually,
we
only
when
you
failure
of
partial
failure
will
actually
include
a
affected
object,
so
we
did
actually
more
of
these
in
a
younger
model
and
it
may.
I
But
the
other
issue:
there
is
some
luck.
It
can
be
hard
on
some
systems
to
actually
be
able
to
provide
this
your
systems
asynchronous
in
terms
of
how
things
have
been
propagated
through
the
system.
You
may
not
easily
know
if
the
states
have
enriched
why
they
were
successfully
or
as
a
failure
depend
on
how
it's
implemented.
A
R
Jason
sooner
like,
if
a
line
cards
not
plugged
in
it,
doesn't
get
applied.
So
do
you
call
that
an
error
like
sometimes
it's
hard
to
determine
if
something
didn't
get
applied,
because
I'm
error
or
versus
just
the
requirements
aren't
there
for
the
config
to
be
able
to
be
applied
like
it's
not
like.
We
talked
about
the
classic
example
of
when
you
configure
an
interface,
but
the
line
cards
not
plugged
in
then
that's
not
applied.
That's
not
an
error
right.
R
O
I
So
I
think
it
depends
on
the
user
than
the
configuration
in
there.
You
will
know
whether
or
not
they're
doing
pre
conflict
and
hence
whether
or
not
it's
an
error,
so
they're
not
doing
pre-configure.
They
may
expected
to
work
and
not
fail,
but
if
they
are
doing
pretty
config
and
Union
and
system
was
hot.
I
R
B
Q
O
Q
Know
central
one
single
RPC
took
out
all
the
failures,
so
we've
got
the
notification
one
by
one
hundred
notifications
on
may
bundling
together
got
ten
notifications
thence
after
the
client
who
deal
with
them,
so
the
normal
notification
will
cover
that.
Why
do
we
have
separate
RPC
to
query
the
failure.
O
A
O
Another
chapter
is
about
the
factory
factory
default,
setting
capability
for
red,
scarf
and
I
think
it
also
applied
to
the
neck
hole
and
that
goal
actually
is
allow
the
restaurant
line
at
you.
You
know
configure
the
unity
powered
device
with
precomputing
stated
you're
in
the
mega,
for
example,
they
were
attached
bootstrapping
process
and
also
you
can
restore
the
conflation
into
the
priests
computer
initiate
stated
during
the
the
server
restart
or
server
federic
arrow
process.
So
we
motivation
to
do
this.
O
Actually,
we
see
a
lot
of
limitation
for
the
medical
and
a
reskin
flow,
for
example,
when
an
account.
Actually,
we
have
delete
the
config,
but
they
only
actually
can
return
the
device
to
the
factory
before
the
setting
it
only
applied
to
the
startup,
but
don't
apply
to
the
wronging
for
the
config
copy
configure
operating.
Actually,
you
can
use
that
operation
actually
to
copy
when
they
distort
you
another
datastore,
but
without
a
factory
beta
star
as
a
salsa,
you
cannot
return
the
target
video
store
in
to
the
factory
default
setting.
O
So
also
there
are
some
limitation
for
the
rest,
comm
similar
reason.
Actually,
equal
rest
can
be
implemented
in
the
device
that
has
nano
for
server
support.
Actually,
you
may
consider
to
use
a
copy
configure.
You
may
actually
face
a
similar
issue.
Actually,
you
copy
won't
be
destroyed
into
another
paper
store,
but
without
the
factory
data.
So
you
cannot
return
the
tacky
data
soy
into
the
the
pre-computer
initial
State
so
another
case.
O
Actually,
if
the
rest
camp
is
implement
in
a
device
that
doesn't
have
an
account
support,
so
the
rest
count,
client
can
actually
be
the
nmda
datastore
aware.
Actually
he
can
use
HTTP
buta,
measured
as
specified
by
obviously
8840
and
but
the
HTTP
put
measure
can
only
actually
replace
in
high
in
contents
with
some
configures
it's
splitting
here
we
give
the
example.
You
cannot.
Actually
you
know
copy
one
people
story,
not
another
datastore
use
this
kind
of
a
duty
we
put
so
this
is
solution.
We
propose
that
we
propose
to
define
the
factory
data
store.
O
This
factory
store
can
initialize
longing
into
the
factory
before
setting.
Actually,
if
you
only
have
the
wrong
name,
but
you
will
have
a
wrong
and
stop
both.
Actually,
you
can
actually
initialize
powerful,
stop
and
running
into
the
pre-configured
initial
State
in
some
case
that
you
really
need
service
Sparta,
and
so
you
so
we
here
we
want
to
upon
out
actually
there's
some
consistent
usual.
O
For
example,
you
want
to
initialize
the
Romney
into
the
factory,
but
at
the
same
time,
there's
another
operation
like
a
at
a
config
actually
also
at
accountant,
so
I
alter
the
contents
of
their
running.
They
may
actually
immediately
update
it
to
the
estaba,
so
they
work
also
the
inconsistency
between
the
stop
and
Ronnie.
Can
you
quickly
wrap
up
so
we
define
these
data
store,
actually
as
a
read-only
data
store
actually,
and
we
need
also,
we
need
to
document.
O
The
factory
with
the
medical
restaurant
operation
may
be
restarted
or
Beijing
together,
but
we
actually
face
some
Evo.
We
document
this
kind
of
behavior.
We
also
need
to
address
that
you
open
issue.
Why
is
actually
do
we
need?
The
support?
Is
a
new
operation
like
a
faculty
priest
or
there's
some
discussion
on
the
list?
Actually,
some
more
people
favor
actually
using
existing
and
Coruscant
operation,
maybe
also
need
to
consider
we
start
off
with
operation,
but
we
also
have
some
argument
to
define
the
new
operation.
Actually,
we
see
actually
an
imitation
over
the
press,
conf
operation.
O
Also,
we
need
to
support
the
general
purpose
operation,
so
you
may
need
to
define
this
kind
of
general
purpose.
Operation
applied,
not
only
net
call
but
also
read
calm
and
as
a
young
basic
photos
and
in
some
cases
you
need
to
serve
early
star.
In
some
cases
you
Tony
nurse
every
style
for
you
have
operation.
You
have
restarted
Jaime
that
you
indicator
whether
rich
star
is
needed.
So
so
that's
that's
another.
O
Also
in
the
manage
to
it,
discusses
the
difference
between
the
system,
restart
and
reboot.
Actually,
we
think
system
restart,
actually,
the
difference
between
system
restart
and
every
structure
is
for
sitting
Rizal.
You
need
to
restart
the
whole
system,
not
only
me
to
the
Netcom,
but
we
started
just
that.
You
restarted
the
server,
so
that's
a
period
difference
and
the
report
is
similar
to
the
system
we
started,
so
the
pricing
actually
was,
we
believe.
A
I
I
So,
first
of
all,
what's
his
draft
about
really
it's
called
a
transaction
draft
by
the
way
I
think
he's
introducing
private
candidate
data
store
so
that
you
can
have
a
candidate.
They
distort
that
is
tied
to
your
session
and
he's
done
in
terms
of
rest
comp
here,
but
you
could
also
apply
this
to
Nick
off
as
well
so
the
moment
in
terms
of
what
neck
off
defiance
finds
a
candidate
store.
I
But
it's
been
big
us
on
this,
but
it's
may
see
basically
regarded
as
being
a
shared
Canada
date
store
and
use,
locking
to
control
it
what's
being
proposed.
Here
is
a
bit
different.
You
have
a
candidate
datastore
which
is
calling
somewhere.
Remember,
I've,
come
to
call
something
a
staging
I,
think
and
in
doing
that,
your
particular
session.
You
can
write
data
to
that,
make
multiple
updates
and
it
some
point
you
can
commit
there
in
the
data
and,
as
he
says,
its
enhancement
to
80/40
and
tastes
like
a
capacity
and
in
MDA
compliance.
That's
was
written.
I
Some
work
there
so
in
terms
of
his
implementation
he's
using
intended
as
the
converging
point
between
where
these
new
candidate
private
candidate
data
comes
into
I.
Think
that's
my
opinion,
pretty
mistake
and
you
can
read
intended
as
being
running
so
actually
that's
the
point
where
you'd
commit
this
configuration
to
there's
no
discussion
on
that
on
the
ADA,
so
I
think
he's
agreed
that
he
would
change
that
so
I'll
keep
discussing
terms
of
intended,
but
everywhere
you
see
intended.
You
could
probably
assume
that's
going
to
be
running
in
term
resolve.
I
So
in
terms
of
the
operations
have
been
added
in
here,
your
client,
you
get
a
state
one
of
these
stage
and
data
stores.
You
write
data
to
it
and
then,
when
you
decide
to,
you
can
then
commit
it
updates
here.
It
says
intended
I
think
that's
running
and
he's
also
defines
a
reset
operation
which
then
reset
staging
back
to
a
current
copy
of
intended
or
running
I'd
like
to
do
that
I.
Think
probably,
you
also
want
to
go
to
diff.
I
What's
in
staging
against,
attended,
running
and
we'd
use
the
same
diff
operation
that
other
people
really
proposed
and
the
last
thing
I
think
that'd
probably
be
useful,
would
be
to
be
able
to
update
staging
to
get
a
fresh
copy
against
intended.
So
you
keep
your
changes,
you
merge
it
in
with
what's
currently
and
intended
as
well,
and
so
it
requires
here.
The
intended
is
always
valid.
I
If
this
new
data
store
I
would
support,
calling
it
something
different,
because
I
think
it's
valid
potentially
to
expose
candidate
through
dress
conf,
it's
giving
it
a
new
name
is
better
there's
been
disguise
discussion
the
alias
between
whether
it
should
be
intended
or
running
as
I've
just
mentioned.
I
think
that
would
change
to
the
updating,
running
I.
I
Think
that's
okay
and
then
okay,
fine,
here's
some
examples.
They
got
running
code
in
terms
of
his
jet
confrontation
written
in
Python
3,
so
there's
running
counter
to
be
sorted
here
really.
I
think
this
is
an
interesting
problem,
though,
do
we
try
and
solve
this
in
the
working
group?
Do
we
actually
have
this
idea
of
private
candidate
dates
tours
so
I?
Think
that's
to
me
is
the
most
useful
question
that
maybe
it's
worth
asking
the
room
is.
This
is
the
sort
of
thing
a
good
idea,
so
in.
A
I
A
A
B
As
a
contributor,
I
also
think
this
is
an
important
problem
solve
in
fact,
I
think
it's
a
very
important
problem.
So
this
is
the
key.
This
difference
between
rest,
cough
and
net
cough
right.
The
reason
why
rest
cough
hasn't
been
able
to
eclipse
neck
off
yet
is
because
the
lack
of
transactions
and
support
for
things
like
confirmed,
commit.
If
this
brings
that
in
then
it
would
make
rest
cough
an
equal
player
in
the
protocol
space,
so
I
highly
suppose,
yeah.
A
But
I
also
think
that
the
implementation
of
individual
candidate
data
stores
has
been
pretty
much
left
undefined.
Some
have
chosen
to
implement
it
as
a
private
candidate.
Others
had
done
a
locking
mechanism
to
try
to
use
candidate,
so
maybe
some
specifications
around
what
is
a
candidate
datastore
and
whether
it's
staging
is
that
it
is
for
would
be
helpful.
I
To
solve
so
so
one
last
call
it
only
counts.
A
point
to
this
is
I
know
that
some
operators
say
this
is
not
required
and
their
justification
is
that
you,
you
can
generate
the
entire
change
set
in
your
clients
and
then
just
send
it
down
as
an
atomic
operation.
And
hence
you
don't
need
this
much
a
persistent
behavior,
but
that's
this
one
operators
view.