►
From YouTube: IETF112-NETCONF-20211108-1430
Description
NETCONF meeting session at IETF112
2021/11/08 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
Well,
you
are
here
in
this
meet
echo
session,
so
you
don't
need
the
link
watch
the
chat
window
for
comments
and
I
believe
it
can
be
made
a
separate
window.
If
you
want,
we
have
one
r
we
requested
for
one
hour
a
slot
for
the
netcat
agenda.
A
We
will
try
to
stick
to
the
time
that's
allocated
for
each
speaker
as
pretty
much
tight
on
time.
There
will
be
a
countdown
timer
at
the
bottom
of
the
screen
to
help
guide.
The
speakers
try
to
stick
to
that
time.
A
The
as
usual,
remember
to
cue
yourself
in
medical
by
clicking
on
the
hand,
symbol
and
to
speak.
Remember
to
unmute
yourself.
A
B
A
All
right,
we
are
going
to
ask
the
presenters
to
do
their
present
their
own
slides,
so
it
should
go
relatively
smoothly,
but
this
is
new
for
everyone.
A
So,
where
are
we
with
this
chartered
list
of
workgroup
items?
The
young
push
notification
capabilities
is,
of
course,
past.
I
say
review
it's
in
the
rfc
editor
queue
at
this
point.
A
The
https
notification
draft
kent
and
I
being
the
authors
on
it
believe,
have
addressed
all
the
open
issues
and
we
believe
it's
ready
for
publication.
C
Can
you
hear
me?
Yes?
Yes,
yes
thank
you
for
this.
I'm
sorry,
I
think
that's
that's
good.
One
question
to
the
working
group.
Is
it
be
if
anyone
is
offering
to
be
the
document
shepard
for
this
document?
That
would
be
appreciated
and
I
can
go
around
asking,
but
if
anyone
would
like
to
do
that
and
then
that
would
be
helpful
for
me
and
they
can
do
so.
A
All
right,
thanks
rob
the
yang
push.
Notification
messages
expired
today.
We
I
know
that
this
draft
has
been
on
hold
waiting
for
https
notification
to
get
done
now.
That
is
done.
We
would
ask
the
authors,
if
they're
here
otherwise
offline,
to
revive
the
draft
and
post
an
update
and
proceed
with
trying
to
finalize
the
draft.
A
Can't
any
comments,
oh
sorry,
we
let's
move
to
distributed
note
of
draft,
and
maybe
we
can
come
back
to
if
anyone
has
any
comments.
The
distributed.
Noted
draft
is
a
workgroup
document.
A
It
expires
soon
if
it
hasn't
already
expired.
The
authors-
I
don't
know
what
the
plan
is.
As
from
the
authors,
do
they
plan
to
continue
working
on
it
if
they
bring
they
will.
A
The
sctp
csr
draft
is,
I
believe,
I
saw
a
post
today
from
kent
and
you
just
updated
and
addressed
some
comments.
B
Correct
a
a
duplicate
paragraph
I
had
had
to
be
removed,
so
I
just
removed
that
paragraph
and
reposted
it
at
this
point.
It
should
be
ready
for
up.
B
Right:
okay
for
the
client
service,
suite
of
drafts
so,
first
and
foremost,
we've
completed
the
last
call
on
the
entire
suite
of
drafts.
B
B
And
then,
but
there
are
some
issues
pending
and
on
the
right
hand,
side
there's
it's
two
are
listed,
but
actually
there's
a
third
as
well.
I
need
to
speak
to
so.
Firstly,
you
may
recall
in
the
tls
client
server
draft,
there's
an
open
pending
issue
that
came
out
of
the
last
call
for
how
to
support
raw
public
keys
and
pre-shared
keys
for
tls
1.3
pom
pets
raised
the
issue
and
hank
dirk
schaff
was
going
to
help
resolve
the
issue,
but
we've
yet
to
actually
resolve
the
issue.
So
that's
remains
pending
open
item.
B
Secondly,
in
the
both
the
key
store
and
trust
store
drafts,
I
I
think
it's
incumbent
upon
us
to
ensure
that
the
language
there
does
not
preclude
the
ability
to
use
the
system-defined
configuration
work
that
the
netmod
working
group
is
engaging
in
that
currently,
these
built-in
keys
that
there's
discussion
about
how
they
show
up
and
operational,
and
maybe
they
need
to
be
copied
into
running.
B
But
we
want
to
ensure
that
you
know
if
the
system
work
goes
forward,
that
you
know
those
keys
could,
alternatively,
are
actually
preferably
show
up
in
the
system.
B
Data
store
so
just
want
to
go
over
the
language
there
and
make
sure
there's
no
or
it
doesn't
preclude
that
ability,
and
then
the
third
item
that's
not
listed
is
that
there
was
a
liaison
request
from
ieee
on
the
key
store,
draft
and
kind
of
related
to
the
same
point
about
built-in
keys
and
the
copying
them
to
running,
and
they
had
some
concerns
for
well
you're,
not
really
supposed
to
be
copying
private
keys
to
running
and
in
fact
the
they
claim,
ieee
802.1
ar
spec
says
you're
not
allowed
to
do
that,
and
so
I
think
actually.
B
This
is
just
a
misunderstanding
because
you
know
there's
the
actual
key
data
and
then
there's
sort
of
the
yang
node.
That
is
the
parent
node
of
the
key
data.
It's
really
just
the
yang
node.
That
needs
to
be
copied
into
running.
I
don't
think
that
subtlety
was
clear
enough
to
them
and
we
just
need
to
follow
up
with
that
liaison
request,
and
I
think
rob
was
going
to
suggest
having
a
meeting
of
some
sort
go
ahead.
Rob.
C
Yes,
so
I've
had
a
a
bit
of
an
exchange
with
glenn
parsons
the
attitude
at
one
working
chair
and
I
think,
we'll
set
up
a
meeting
between
you
and
the
person
raising
this
issue
myself
and
glenn
and
see
if
we
can
informally
work
out
the
right
solution
and
then
also
determine
whether
any
sort
of
liaison
back
to
is
required
or
not.
So
the
next
step
is
for
me
to
set
up
that
meeting.
A
A
A
We
have
seen
quite
a
bit
of
discussion
on
the
transaction
id,
so
ian
is
coming
back
having
updated
the
draft,
and
I
believe
the
list
pagination
draft
has
also
been
presented
before
all
right.
That's
as
far
as
the
chair
slides
are
concerned,
any
comments
or
questions
before
we
jump
into
the
agenda.
B
All
right
yeah,
this
can't
I
have
a
comment
which
is
just
basically
to
all
authors
to
please
try
to
be
proactive
about
bringing
discussions
to
the
mailing
list.
You
know
you
know
any
issues
that
you're
working
through
internally.
You
know
ask
the
working
group
for
their
opinion
as
well.
A
All
right,
so
we
have
the
first
draft,
which
is
the
udp
note
of
trap
and
I
believe,
who's
presenting
it
by
the
way,
okay,
alex
is
okay.
Will
we
grant
you
the
permission,
can
go
ahead.
D
D
D
D
We
were
asked
on
the
mailing
list
that
both
drafts
should
be
merged,
so
we
did
that
on
this
draft.
There
was
just
explained
on
that.
There
were
we.
We
have
to
use
dtls
1.3
to
secure
the
utb
notif
message.
D
D
We
were
requested
to
add
the
reference
of
the
rfcs
of
the
encoding
types,
this
one
cbor
and
xml,
so
we
will
do
that.
There
is
still
a
discussion
about
which,
where
version
should
be
used
of
sibor
the
rfc
one
or
the
draft
one,
and
this
morning
I
guess
I
I
received
also
a
feedback
from
maish.
So
thank
you
and
yes,
we
will
address
this.
This
feedback
soon
as
possible.
D
And
then,
for
from
our
side,
we
consider
that
that
our
draft
is
begin
to
start.
We
begin
to
be
stable
enough,
so
maybe
we,
it
should
be
sooner
less
called,
but
we
let
the
work
working
group
chairs
decide
that.
D
Yeah
go
ahead.
Rope.
C
So
so
one
sort
of
question
of
concern,
so
I
I
raised
this
draft
or
what
has
been
done
with
the
security
ids
today.
I
should
have
asked
them
previously.
C
They
have
some
concern
about
standards,
track
document,
basically
sending
data
over
an
unencrypted
channel,
so
so
something
that
that
we
need
to
work
out
whether
they
will
allow
standards
track
document
to
do
that
and
the
information
document
would
be
okay,
but
the
concern
is:
is
it
over?
Is
ever
it
being
a
standard
track
document?
So
that's
something
that
we
need
to
resolve.
C
We
could
potentially
try
getting
a
sec,
dir
review
or
the
other
choice
might
be
to
see
if
we
can
catch
one
of
the
security
ids
in
gather
dot
town
this
week
just
chat
over
this,
but
I
think
that's
an
issue
that
ideally
we
resolve
that
in
a
working
group
before
last
call
if
we
could
and
the
other
one
to
be
aware
of.
I
know
some
text
about
this
in
the
document
is
at
the
same
time
asked
that
question.
I
got
some
feedback
again.
C
C
B
So
rob
just
to
that
point
yeah,
I
think
syncing
up
with
this
or
ad
would
be
great.
I
do
actually
have
some
empathy
for
wanting
to
support
native
udp,
because
I
think
the
use
case
scenario
is
actually
for
a
private
network
consolidator.
B
It
could
be
inside,
like
literally
in
the
same
rack
as
where
the
log
generator
is
located,
and
for
you
know
so
you
don't
want
the
overhead
of
cryptography,
but
you
know
I
think
so.
That's
that
and
then
also
notably,
that
we're
not
actually
defining
the
protocol,
we're
just
simply
configuring
or
enabling
said
existing
protocols
to
be
configured.
So
these
are
things
that
can
be
discussed
with
the
sector
or
app.
D
C
And
then
just
just
one
other
comment
actually
is:
if
there's
anyone
can
join
the
the
note
taking,
that
would
be
really
appreciated.
So
if
people
could
also
help
contribute
to
the
notes,
that
would
be
helpful.
E
Go
ahead.
Bear
yes,
thank
you
regarding
the
security
support.
Are
you
saying
that
now
that
the
dtls
section
is
in
so
sending
udp
messages
encrypt
in
the
clear
is
an
option,
but
the
rfc
would
is
defining
dtls
report
as
well.
So
is
this
not
good
enough
and
also
with
respect
joining?
I
think
kent
on
this
with
respect
to
the
deployment
considerations
that
we
have
and
if
we
review
the
rfc
on
udp
applications,
we
are
clearly
in
the
field
where
I
mean
sending
messages
in
the
clear
would
be
should
be
tolerable.
C
So
so
to
answer
that
question
is
the
answer.
Is
I
I
don't
know
because
it's
not
it's
not
my
decision
as
such.
I
certainly
have
sympathy
with
the
the
way
that
both
you
and
ken
characterize
this
that
that
the
network
is
meant
to
be
secure
in
that
regards
and
management
network,
and
hence
that
should
that
should
be
sufficient.
I
don't
know
whether
that
would
be
good
enough
for
the
security
ids
or
not.
It
really
needs
to
be
or
in
the
security
area.
I
think
it's
probably
better
at
putting
it.
C
We
need
to
actually
check
with
them
and
have
a
conversation
with
them
and
they
may
we
put
sufficient
mitigate
mitigations
in
that
may
be
good
enough.
I
don't
know,
but
it
may
be
there.
They
just
say
no,
they
don't
regard
the
overhead
of
encrypting.
This
is
is
high
enough
to
justify
not
always
encrypting
it,
but
I
don't.
I
don't
know
how
to
ask
them.
E
Okay,
there
are
a
lot
of
protocols
where
we
will.
We
would
need
to
redo
that
discussion
then,
but,
okay,
okay,
with
respect
to
congestion,
I
think
it's
covered
in
the
draft.
So
on
your
comment
with
respect
to
use
of
udp
and
congestion
in
the
network,
when
we
discuss
the
applicability
and
the
consoles
that
you
have
when
you're
designing
a
udp
application,
I
think
it's
covered,
but
I
mean
we
can
have
this
discussion
offline.
If
you
want,
if
it's
not
good
enough,
we
can
work
on
this
on
this
description.
More
thanks.
A
All
right,
so
I
had
actually
one
comment
and
one
question
or
I'm
trying
to
answer
one
of
the
questions.
I
think
that
was
asked
on
the
mailing
list.
I
believe
that
the
draft
talks
about
you
know
a
transmission
timer,
not
a
retransmission
time,
but
a
transmission
timeout
value
to
be
said.
A
At
which
point
you
know,
there's
no
attempt
to
try
to,
but
there's
no
configuration
in
the
yang
model
for
actually
configuring
the
transmission
timeout.
So
I
don't
know
if
the
intention
is
to
keep
that
timer
or
not
keep
that
diamond.
A
E
F
E
We
may
want
okay,
okay,
if
it's
that
then
yeah
we
may
want
to
have
it
configured,
I'm
not
sure
people
are
going
to
care
much
changing
this
with
respect
to
the
default
value
that
would
be
provided
by
vendors
yeah
and
sorry.
I
forgot
your
last
question
your
second
question:
what
was
it
you
just
didn't
even
know.
A
E
Also,
it
does
not
make
too
much
sense
because
you
are
going
to
you
know,
open
multiple
ports
on
the
collection
side,
maybe
on
on
the
same
machine,
but
on
different
ports
to
do
some
load,
sharing
exterior
so
you're,
going
to
end
up
configuring
it
and
changing
this
anyway,
so
having
a
single
default
value
does
not
make
too
much
sense
when
we
look
at
the
big
picture
of
the
deployment.
So
in
my
opinion,
it's
not
really
needed
and
no
one
was
carrying,
so
I
think
we
removed
it.
E
B
Okay,
thank
you.
We
need
to
we're
just
a
little
bit
over.
We
should
move
on
to
the
next
presentation,
all
right.
A
A
G
Okay,
so
on
behalf
of
the
authors,
I'm
here
to
present
the
adaptive
subscription
to
young
notification
draft,
I
believe
that
this
work
has
already
been
presented
for
several
times.
An
adaptive
subscription
can
fit
in
the
scenario
with
massive
debt
collection
and
processing
with
expensive
data
management
cost.
Usually
the
higher
frequency
debt
collection
leads
to
more
resource
consumption,
while
low
frequency
data
collection
may
lead
to
insufficient
data
for
photo
localization.
G
The
notification
can
be
streamed
at
a
lower
rate,
so
our
proposal
is
to
enable
the
client
to
configure
an
adaptive
subscription
of
that
policy
which
contains
a
condition
and
allows
the
server
to
switch
to
different
period
intervals,
based
on
the
condition
and
the
condition
is
expressed
using
a
standard,
expat
evaluation
criteria,
but
in
last
itf
meeting
there
is
one
issue
I
I
think
is
read.
It
was
read
by
rob,
which
is
about
the
arbitrary
x-path
complexity.
G
G
C
Thank
you.
Could
you
go
back
a
slide,
please
so
so.
Thank
you.
I
saw
that
you'd
sent
me
a
summary
of
the
text
that
you
proposed
on
changing
this,
and
I
I
think
that
that's
on
the
right
tracks.
I
had
intended
to
send
some
comments
back
today.
I've
run
out
of
time.
I
think
that
the
description
about
why
it's
complex,
I
think
that
can
be
probably
condensed
down,
but
in
terms
of
your
solution,
I
think
that
seems
reasonable.
C
As
in
I
quite
like
the
idea
of
being
able
to
advertise
the
set
of
objects
you're
allowed
to
perform
this
on
through
the
capabilities
draft,
I
think
restricting
it
to
like
interject
integer
based
filtering
and
simplified
comparison
again.
I
think
that
makes
sense.
I
don't.
I
don't
object
to
allowing
implementations
to
support
a
more
complex
filter.
C
I
think
the
key
for
me
is
that
it
would
be
good
if
at
least
every
implementation
had
to
at
least
support
these
basic
filters,
because
those
my
concern
is
about
running
a
generic
xpath
evaluation
engine
repeatedly.
That
may
be
too
expensive.
So
so
I
think
that
that
makes
sense
and
then
one
other
thing.
I
would
add
is
that
it
would
be
useful
to
have
a
well-defined
error
code
or
error
to
be
returned
on.
C
If
you
do
allow
more
complex
queries,
so
they
have
an
error
code
to
say
when
it's
when
the
comparison
put
in
to
say
no,
this
is
too
complex.
I
can't
handle
this.
B
All
right,
I
was
on
the
other
window,
typing
notes,
and
so
the
the
concern
for
arbitrary
complexity
and
xpath
may
also
be
appearing
in
the
list.
Pagination
work
that's
going
to
be
presented
later
in
this
session
and
there
there's
a
concern
for
you
know
if
you
have
these
arbitrary
expressions
and
you're
mapping
to
a
backend
database,
how
can
you
do
that?
B
For
you
know
some
databases
aren't
that
rich
in
their
query,
language,
syntax,
and
so
I
think
it's
one
thing
to
say
there
needs
to
be
a
minimum
set
and
then
may
there
may
be
more
complexity.
But
how
does
the
client
know
what
extra
complexity
is
supported
by
the
server?
And
so
then
we
may
need
to
have
some
ability
to
enumerate
or
or
somehow
otherwise
enable
the
server
to
advertise.
B
What
all
the
extra
expressions
that
they're
supporting-
and
so
I
see
that
desire-
may
be
showing
up
here
in
this
work
and
also
in
the
list.
Pagination
work.
B
I
guess
we
can
move
to
the
next
deck
yeah.
I
think
so,
and
also
while
we're
moving
to
the
next
deck
in
yon
europe.
The
previous
presentation
on
the
udp
native
alex
was
that
you
speaking
or
was
it
pierre
speaking.
F
F
F
I
took
a
real
world
application
but
running
in
the
lab,
so
it
was
not
actually
a
real
world
in
the
true
sense
of
an
operator
running
something,
but
it
was
running
in
a
lab
and
it's
a
real
world
application
and
analyze
the
traffic
in
that
situation.
With
this
application
running
and
one
I
browse
eyebrow
razer
that
a
lot
of
people
reacted
to
was
that
91
percent
of
the
traffic
was
actually
in
young
1-0,
hello
messages.
F
So
that's
something
for
for
implementers
to
watch
out
for
to
move
to
yang
1.1,
to
get
rid
of
that,
but
simulating
or
calculating
what
sort
of
savings
would
have.
With
this
draft,
I
could
see
that
we
went.
We
would
go
down
from
569
to
378
round
trips,
for
this
particular
application
running
for
three
hours
and
almost
half
the
amount
of
configuration
data
being
exchanged.
F
So
I
think
there
is
some
value
to
this,
but
actually
the
real
value
that
I
see
in
this
work
is
not
so
much
to
reduce
strong
trips
or
number
of
bytes
being
sent
between
client
and
server,
but
it
is
the
reliability
that
a
set
of
clients
can
work
reliably
towards
a
set
of
servers
and
not
clobber
each
other.
F
So
that's
really
the
the
main
point
here
and
the
reduced
traffic
is
a
kind
of
nice
bonus,
so
what
I
did
from
double
o
to
zero
one.
Okay,
I
clarified
things
based
on
feedback
on
the
list.
I
separated
out
the
e-tag
specifics
into
so
it's
very
clearly
in
some
parts
and
non-e
tag.
The
general
mechanism
is
described
in
separate
parts.
F
F
There
was
a
lot
of
discussion
between
when
it
comes
to
who
should
set
transaction
ids.
Should
transaction
ids
be
set
by
the
server
or
could
they
also
be
set
by
the
client?
And
since
there
was
so
much
controversy
about
that,
I
completely
removed
the
option
for
clients
to
set
it.
I
still
think
that's
a
good
idea
and
I'll
make
a
case
for
that
in
a
few
minutes,
because
I
removed
that
I
had
to
add
some
other.
I
had
to
adjust
the
mechanism
a
little
bit.
So
that's.
A
A
I
think
you
just
started
on
this
particular
slide.
All.
F
Right
very
good
thanks.
So
here
are
the
open
questions
and
I'll
quickly
go
through
each
one
of
them
and
explain
what
we
have
chosen
to
imp
to
write
in
the
draft.
These
are
all
the
alternatives
that
were
raised
on
the
list
so
for
the
e-tags
we
have
now
adjusted
the
e-tag
assignments,
the
transaction
id
values,
to
match
exactly
what
it
says
in
in
rest,
cons
and
72-32.
F
F
F
We
have
this
question
that
I
mentioned
earlier:
that's
is
it
allowed
for
a
client
to
say
I
want
you
to
use
this
particular
transaction
id
when
it
sends
in
an
edit
config
to
a
server
and
right
now,
there's
no
text
about
that
at
all
in
this
draft,
but
I'll
come
back
to
that
in
a
minute
and
explain
why
I
think
that's
a
good
idea.
F
Similarly,
there's
some
people
ask
that,
maybe
even
if
we
don't
assign
e-tags
this
way,
maybe
we
could
allow
clients
to
send
in
a
free-form
string
to
associate
with
each
transaction,
because
then
you
can
send
in
things
like
who
was
doing
this,
why
it
was
done
which
custom
it
belongs
to
internal
order,
numbers
and
whatnot.
If
you
have,
if
you
can
put
comments
on
there,
so
you
can
use
the
transaction,
you
can
add
transaction
metadata
basically,
but
right
now,
there's
not
no
such
language
in
the
draft
at
all.
F
So
here
on
the
left,
you
see
a
client,
that's
sending
an
edit
config
with
some
blah
blah
blah
going
over
to
the
server
and
the
server
then
returns.
If
it's
using
this
transaction
id
thing
it's
returning,
okay
and
also
adding
a
sort
of
transaction
id
said
yeah.
I
know-
and
we
call
all
these
things
that
change
now,
ab5636
and
so
on,
and
the
only
difference
if
the
client
assigns
the
transaction
id
is
that
you
add
one
more
element
in
the
edit
config
optionally
for
the
client
yeah.
F
I
want
to
call
this
thing:
47
390
and
then
the
server
returns
47
390
at
the
end,
so
it's
very
easy
to
implement
this.
Otherwise
the
server
would
have
to
come
up
with
this
sort
of
random
value.
Now
it
doesn't
even
have
to
use
the
random
function
anymore
because
it
just
gets
disserved
from
the
client.
I
want
you
to
call
this
this
and
that's
what
it
gets
back.
So
it's
very
easy
to
implement.
F
And
I
claim
that
this
allowing
the
client
to
send
this
value
is
a
high
value
thing,
because
if
here
on,
the
left,
if
you
don't
allow
the
client
to
do
that,
it
computes
a
transaction
sends
a
few
edit
configs
to
the
number
of
servers
and
they
respond
in
their
time
and
the
server.
The
client
has
to
wait
for
the
slowest
of
them
to
respond
before
it
knows
the
transaction
id
and
can
update
this
database
with
what's
happened,
then
it
can
start
computing.
F
The
next
transaction,
sending
out
a
few
more
edit
configs,
wait
for
all
of
the
responses
to
update
the
database
and
so
on
so
keep
track
of
what's
going
on,
whereas
on
the
right
side.
Here,
if
you,
you
compute
the
current
control
transaction-
and
it
sends
out
this
edit
configs-
it
already
specifies
which
transaction
ids
things
should
have
so
the
database
it
has
locally
here
is
already
up
to
date
with
what's
going
on,
and
then
the
service
can
respond
in
their
time,
and
we
are
already
on
to
the
next
thing
and
computers.
F
It
increases
the
performance
quite
a
bit
and
of
course
this.
This
would
be
an
optional
feature.
So
I
don't
think
all
servers,
or
so
all
clients
and
servers
would
have
to
implement
this,
but
for
those
that
participate
in
high
performance
scenarios,
this
could
be
interesting,
and
I
think
I'm
just
on
time
going
to
the
last
slide,
which
is
saying.
B
So
this
is
kent
chair.
I
I
think
you
had
some
open
issues
and
there's
no
time
for
discussion.
I
know
we're
on
a
tight
schedule
here
with
the
interims.
I
do
think
we
should
take
items
to
the
list
so
for
each
of
your
open
issues.
Please
start
a
thread,
a
separate
thread
and
those
can
be
discussed
there.
Thank
you.
H
I
So
I'll
be
quick
canon
and
so
basically
I
really
support
engine
id
being
suited
by
the
client
or
at
least
having
a
way
to
to
label
transaction,
because
if
we
put
in
there
the
service
request
id
coming
from
the
orchestrator
and
it
has
great
value
in
case
we
could.
We
have
multiple
client
configuring
a
server
and
we
do.
We
could
do
a
look
up.
There
see
exactly
what
was
changed
for
in
time,
so
I'll
expand
on
the
list,
because
it
was
a
long
time.
B
While
we're
bringing
that
up,
I
guess
jen's
presenting
and
then,
while
I
do
also,
I
think,
there's
value
there.
We
just
need
to
discuss
the
best
way
to
introduce
it
hello.
Can
you
hear
me
yeah,
go
ahead,
jen
see
your
slides
in
here.
Go
ahead.
H
Yeah,
hello,
everyone,
my
name
is
ching,
so
I'm
here
to
present
the
list
of
designation
mechanisms
for
nanocomp
and
rest
conf.
We
have
three
dropped
and
the
name
we
here
are
also.
We
actually
set
up
design
team
for
this
next.
H
Oh,
oh
sorry,
I
I
forgot
yeah
yeah,
let's
yeah
just
recap
a
little
bit
motivation,
so
why
we
want
to
do
this
actually.
Actually,
when
you
retrieve
90
number
the
entry
from
list
and
leave
list,
actually
you
may
actually
don't
have
a
very
user-friendly
client
interface
actually
for
a
client
that
may
take
quite
a
long
time
to
retrieve
these
lists
so
we'll
introduce
quite
a
lot
of
latency
and
also
economy
consume
a
lot
of
resources.
H
So
our
idea
is
to
try
to
leverage
the
server-side
processing
combined
with
some
back-end
storage
system
and,
for
example,
index
mechanism.
Allow
you
to
allocate
the
data
without
need
to
search
all
the
row
in
the
database
table.
So
we
tried
to
borrow
this
concept
and
and
use
in
this
list
and
leave
list
retriever.
H
So
this
job
has
already
been
presented
in
iet
109,
and
we
got
quite
a
lot
of
discussion
on
rescon
for
connection
problem
this.
Actually
we
have
a
job
that
we
call
the
resconf
connection
which
get
expired,
so
we
actually
use
these
as
basis
to
come
up
with
this
idea,
yeah
and
so
before
we
discuss
this
pagination.
We
actually
have
three
key
acronyms.
H
First
is
pagination.
Really
it
is
a
standard
mechanism
to
control
the
filtering,
sorting,
retrieve
the
entry
and
of
less
than
a
lift
list,
and
also
we
have
two
acronym.
We
call
the
list
pagination
net
conf
and
this
page
nation
for
rescon,
which
focuses
on
product
extension
to
support
this
pagination,
and
so
what
do
we
do?
Actually,
since
iet109?
H
Actually
we
up
one
of
the
this
pagination
draft
from
the
other
two
one
is
focused
on
nanocock,
the
other
focus
on
redskonf
and
we
rename
the
cong
and
escape
parameter
into
the
limit
and
offset
because
we
borrow
the
concept
of
secure
language
from
the
backhand
database,
so
they
use
nimit
and
offset,
and
that's
why
we
switch
to
these
two
terminology
and
we
also
define
you
know
for
list.
Pagination
define
the
five
query
parameter,
which
will
be
discussed
in
detail
in
the
later
slides
and
also
for
decision
list.
Pagination.
H
We
also
introduce
one
query
parameter.
We
call
the
sublist
limit
and
also
we
actually
extend
the
server
capability
extension
and
to
actually
define
the
per
node
tags
and,
in
addition,
we
actually
in
appendix
we
define
the
example.
Young
data
model
dataset
and
query,
which
will
be
reused
by
the
nanocon
draft
and
the
restaurant
job,
and
so
the
other
two
dropped
the
first
net
conf
and
we
already
you
know,
posed
this
chart
and
we
made
it
up
data.
So
the
main
change
actually
is.
H
We
change
a
new
rpc
to
augmenting
three
out
net
rpc
one
is
net
conf
and
also
we
have
get
config
and
get
and
get
config
and
get
data.
The
second
change.
H
We
actually
try
to
reuse
the
grouping
defined
in
this
pagination
job
and
in
in
this
netcod
job,
and
also
we
actually
provide
the
example
to
show
how
how
it
works
and
for
rest
confer,
and
we
actually
update
the
rfc,
8040
and
align
query
parameter
for
rest
confirm,
and
we
also
declare
list
and
leave
list
as
a
valid
resource
target
forget
and
optionally.
We
can
support
delete
operation
based
the
discussion
with
design
team
member
and
we
think
for
young
model.
We
we
don't
think
it
is
value
we
don't
see.
H
Any
parameter
is
really
needed
in
this
model,
so
we
remove
this
yar
model
for
this
pagination
rascal,
and
so,
let's
drill
down
a
little
bit
into
this,
this
pagination
draft
and
we
actually
defined
actually
several
query
parameter.
The
first
is
where-
and
the
second
is
sold
by
and
where
actually
actually
ken
already
mentioned,
we
do
support
this
kind
of
filter
expression
and
we
provide
example
for
this
and
for
sold
by
very
similar
to
the
order
by
actually
the
by
default.
H
If
sort
of
is
not
set
actually
will
you
know
fall
back
to
the
order
by
and
direction.
We
support
the
forward
and
backward
direction
of
the
results
to
be
returned
and
also
key
parameter
is
offset
and
limit
and
which
actually
apply
to
the
list
and
leave
list,
and
it
could
be
returned
the
number
of
entry
to
be
skipped
or
the
number
of
entry
to
be
returned,
and
we
also
sample
is
the
limit
parameter
which
only
apply
to
the
dissident
list
and
leave
list,
and
we
also
set
the
processing
order.
H
The
first
high
priority
order
is
where,
and
then
it's
sold
by
interaction
offset
and
limit,
and
in
this
chapter
we
also
introduce
a
metadata
attribute,
we'll
call
the
remaining
and
remaining
parameter
can
use
together
with
a
limit,
query
or
separate
list
limit
query,
and
it
can
be
used
to
return
the
number
of
entry
not
included
due
to
the
limit
or
sub
limit
sublist
limit
operation.
H
And
here
is:
we
show
the
example
how
these
combination,
six
query
parameters
can
be
used
in
the
request
and
response
message
to
guide
the
whole
list
and
leave
list
should
be
returned,
so
you
can
see
this
example
and
we
actually
use
the
where
sort
by
and
direction
and
offset
and
limit.
Another
example
has
already
documented
in
appendix
so
3.7
and
even
in
time
limit,
I
will
skip
this
and
you
know.
In
addition,
we
introduce
another
example
to
to
to
to
discuss
how
remaining
is
used
in
in
the
requested
response.
H
Actually,
these
remaining
actually
can
be
applied
to
the
dissident
list
and
levelist.
So
we
gave
two
examples.
The
difference
is
that
the
target
node
is
different.
One
is
just
applied
to
the
one
data
node
we
call
the
member
who
name
is
alice
the
second.
The
target
node
actually
is
a
data
store.
It
is
a
intended
data
store,
so
response
will
be
different.
H
And
so
we
also
introduced
a
serverless
pagination
capability
discovery.
This
is
really
actually
built
on
top
of
the
server
capability
draft.
Actually
we
augment
from
system
capability
with
a
two
key
parameters.
We
call
the
constraint
parameter.
The
first
one
indicates
which
config
force
list
or
leaflet
node
are
concentrated,
it
will
apply
to
the
parent
node
and
the
second
is
indexed.
H
You
know
this
actually
applies
to
the
child
node
child
node,
actually,
which
will
show
actually,
which
node
may
be
used
in
a
where
and
sort
by
expression,
and
we
also
allow
some
future
extension
here.
We
give
the
example
you
may
not
support
100
x,
pass
1.0,
for
example,
you
support
some
of
the
expanse
function
for
some
other
experts,
for
you
don't
support.
So
we
can
allow
such
an
extension
because
for
back-end
database
system
they
may
have
different
capabilities,
so
we
should
allow
such
a
very
variety
difference.
H
And
the
second
is
the
net
conf
draft
and
the
the
you
can
see
the
overview,
this
model
structure.
Actually
we
augment
the
three
netcom
rpc
statement,
get
get
config
get
data,
so
you
can
see
the
parameter
you
know
actually
align
with
the
list,
pagination
shaft
and
on
the
same
query,
parameter
and
also
the
same.
The
type
data
type
I
applied
to
different
rpc
statements,
and
then
we
also
gave
an
example
to
show
how
this
parameter
can
be
used
in
the
request
and
response
message
pair.
H
H
The
first
product
chain
will
introduce,
we
add
a
list
and
leave
list
as
a
valid
resource
target
for
the
get
and
delete
operation,
and
we
also
try
to
apply
it
to
the
related
http
method
for
the
get
and
ahead
and
second,
actually,
we
add
a
new
media
type
application
young
data
xml
list
and
for
application
young
data
json.
Actually
we
try
to
reuse
the
one
defined
in
obviously
80
40.
We
don't
need
to
you,
know:
reven
reinvent
the
wheels.
H
The
third
product
extension
we
introduce
is,
we
add
a
six
new
query
parameter
and
we
also
you
know,
give
example
how
this
can
be
applied
to
the
delete
operation
for
the
list.
So
this
example
already
documented
in
the
appendix
3.2.
H
So
we
we
do
have
two
open
issue.
We
like
to
solicit
some
feedback.
The
first
one
is
about
cursor
support.
Actually,
we
our
pagination
id,
actually
the
key
parameter,
is
offset
and
limit.
Actually,
we
usually
would
call
it
as
offset
based
pagination,
but
in
some
cases
you
you
may
need
to
consider
whether
we
need
to
support
cursor-based
pagination.
So
what
is
the
pace?
Cursor-Based
pagination,
so
it
really
enables
the
paging
to
continue
over
the
snapshot.
H
Despite
the
dataset
changing,
for
example,
you
add
one
more
entry
or
you
may
delete
one
more
entry
for
the
client.
Actually,
you
may
don't
know
whether
the
list
gets
changed,
so
you
can
assume
that
the
client
you
know
so
the
client
actually
make
assumption
actually
that
this
doesn't
make
a
change
but
for
for
server
if
without
cursor
support
actually
in
some
cases,
so
we
may
have
some.
H
You
know
corner
case.
It
may
re
return
the
larger
remaining
value
than
the
previous
fetch.
So
one
example,
you
may
refashion
the
paging
in
a
time
series
log.
The
log
can
be,
you
know,
grow
too
large
actually
can
be
append
at
the
end,
and
so
this
will
face
these
kind
of
cases
and
so
for
config.
Actually,
actually
many
systems
have
a
internal
radar
writer
mixer
exclusive.
H
Actually
so
the
cursor
in
based
on
our
design
design
team
discussion
seems
maybe
not
needed,
so
we
also
have
some
mechanism
to
try
to
address
this.
For
example,
we
have
an
entity
tag
timestamp.
This
can
be
used
to
detect
the
dynamic
disk
change.
Now
also,
we
have
some
error
code
messaging.
This
error
code
message
can
be
used
to
indicate
the
end
of
the
list,
so
we
think
we
seem
similar.
We
think
we
lack
a
companion
use
case
for
this.
H
If
someone
have
some
concrete
use
cases,
please
let
us
know,
and
we
will
see
how
to
support
this
cursor
in
the
list.
Pagination
job
and
the
second
one
is
about
the
remaining
an
annotation.
So
the
remaining
is
used
to
return.
The
number
of
the
elements
not
including
the
result
set
actually
the
kernel
draft
states
that
if
no
elements
were
removed,
this
annotation
must
not
appear,
but
it
uses
the
minimum
value
0
to
represent
the
arnold
actually
based
on
discussion.
H
A
H
F
B
I'm
sorry,
I'm
not
sure
if
I
was
on
meet
or
not,
I
was
saying
all
the
authors
could
please
take
their
open
issues
to
the
list
and
and
then
for
everyone.
Thank
you
for
the
discussion
and
we'll
continue
the
discussion
on
the
list.
Please
have
a
good
rest
of
the
day.
Bye.