►
From YouTube: IETF110-CORE-20210312-1200
Description
CORE meeting session at IETF110
2021/03/12 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
I
guess
you're
back
kirsten.
Yes,
I
am
okay
right
on
time,
we're
on
the
clock
and
I
think
we
can
start
so
welcome
everybody
to
the
second
session
of
the
co-working
group
for
itf
110.
I
am
marco
tilolka.
My
culture
is
jaime
hemets,
who
couldn't
make
it
for
this
meeting.
We
have
a
custom
borman
as
then
being
chair
for
itf
110.
A
So
next
slide,
please
and
other
than
the
first
point
mentioned
already
as
usual.
We
assume
people
read
the
documents
presented
today.
We
have
to
try
to
make
good
use
of
this
time,
especially
to
solve
big
issues
on
the
document
and
not
well
applies
more
on
that
later,
the
blue
sheets
is
filled
automatically,
so
you
don't
need
to
specify
your
name
anywhere
I'll,
be
your
jabber
sky
for
today,
and
we
have
ricard,
does
not
take
her.
Thank
you
very
much
rika
for
taking
it.
I
will
also
try
to
help
with
the
minutes.
A
A
Please
right
a
bit
of
practicality.
Please
use
the
q
tool
on
my
taco
to
enter
the
queue
and
to
leave
the
queue
using
the
hand
on
your
top
left
and
the
chairs
will
add
me
in
the
queue.
Otherwise,
you
can
request
to
relay
your
comment
or
question
in
the
jabber
chat.
The
meeting
has
been
recorded
already
and
again.
Participation
blue
started
automatically
next
slide.
Please,
and
this
is
the
agenda
for
today.
A
It's
mostly
working
group
documents
open
points
raised
during
the
shipper
write-up
for
one
of
the
core
comp
documents
and
next
steps
to
take
for
the
tu
cinema
documents
and
then
new
block,
which
has
passed
working,
your
plus
call
and
time
link,
and
then
we
have
two
individual
submissions
on
resource
directory
extension
and
the
new
work
on
data
centric
deployment
for
co-op.
We
have
also
quite
a
bit
of
flex
time,
so
we
don't
need
to
rush,
and
I
think
then
we
can
move
to
the
next
presentation.
B
B
There
are
four
count
documents
that
that
have
passed
working
group
last
call
and
two
of
them
are
in
ietf
last
call
right
now:
the
young
sibo
and
the
sid
document.
So
we
are
waiting
for
the
the
various
reviews
and
ad
opinions,
and
so
far
there
is
one
review
in
which
is
by
the
security
directorate
about
yang
ziba
and
sean
rightly
states.
B
There
are
not
really
security
conservations
here
and-
and
that
is
all
right.
So
so
it's
hard
to
invent
security
considerations
here,
I'll
talk
about
sid
in
a
moment,
the
the
other
two
documents
are
komari
and
yang
library,
so
these
are
in
in
data
trackers.
That
is
waiting
for
a
shepherd
write
up
and
that's
me
and
for
comai.
I
actually
generated
some
comments
and
I
believe
these
actually
need
to
be
resolved
before
we
can
submit
this
to
the
isg
and
with
respect
to
yang
library.
B
So
these
two
will
be
the
next
block
we
hand
over
to
the
isg,
but
we
wanted
to
make
sure
that
yank,
sieber
and
sid
are
done
first.
B
Normally
security
normally
ads
comment
when
when
there
is
time
for
the
isg
to
to
take
a
ballot
position,
but
this
time
ben
actually
mentioned
at
the
start
of
the
last
call
that
this
appears
that
the
consent
document
appears
to
be
a
proposal
to
create
the
registry
and
design
globally
unique,
urine,
c4
values
to
items
in
unrelated
yang
modules,
and
that
is
a
new
global
naming
system.
B
And
yes,
indeed,
that's
the
point-
and
we
are
very,
very
interested
in
in
hearing
the
the
views
that
the
security
community
has
about
that.
B
There
is
one
issue
that
actually
I
didn't
notice
in
in
my
shepard
review,
but
that
independently
came
up
in
the
netmod
working
group
and
they
didn't
notice
that
it
actually
applies
to
kumai,
so
so
that
that's
a
connection
we
had
to
make
in
that
mod.
There
was
a
discussion
about
type
equivalence.
B
So,
for
instance,
is
it
a
backwards,
compatible
change
to
go
from
a
uint
8
to
an
intage
or
back,
and
that's
actually
a
discussion
item,
and
it's
not
not
yet
completed,
but
it
seems
to
go
into
the
direction
to
say
that,
essentially,
the
built-in
types
are
the
boundaries
between
the
different
type
top
level
types,
and
you
cannot
switch
your
built-in
type
without
essentially
needing
to
to
allocate
a
new
identifier.
B
So
it
seems
to
resolve
in
such
a
way
that
we
don't
have
to
make
a
change
in
comai.
But
the
question
of
course
still
is:
do
we
need
to
rely
on
it
and
right
now
there
are
certain
inconsistencies
in
the
draft.
Well,
not
really
inconsistencies
but
different
ways
to
handle
similar
things
that
are
not
motivated
by
giving
a
rational,
and
let
me
explain
that
so
this
is
the
table
that
explains
how
to
encode
a
yang
data
type
in
a
uri
query
parameter.
B
So
the
the
encoding
of
yang
and
sibo
is
defined
in
the
young
zebra
document.
Of
course
that
doesn't
erase
this
kind
of
problem,
but
the
ui
encoding
is
separate
from
that
because
your
eyes
aren't
binary.
So
we
cannot
just
stuff
siber
encoding
in
there
and,
as
you
can
see
from
the
table
when
we
actually
want
to
do
that,
we
have
to
use
base64
and
for
about
half
of
the
types
we
use
base64,
but
because
we
know
the
type
we
actually
can
apply
different
encodings
to
different
types.
B
B
So
we
have
some
some
leeway
here,
but
the
question
of
course
is:
is
it
really
necessary
to
encode
uint8
and
ind8
in
two
different
ways,
so
the
the
pink
places
are
the
places
where
we
simply
use
the
key
and
interpret
it
as
an
integer
and
convert
this
integer
into
a
decimal
string
and
use
that
in
the
uri
query-
and
it's
not
quite
clear
to
me
why
we
have
to
encode
negatives
or
potentially
negative
numbers
in
c
war
and
and
can
send
the
positive
numbers
as
they
are.
B
So
this
is
a
little
bit
of
a
mystery
clearly,
if
the
number
is
0
to
9,
then
into
string
is
more
efficient,
but
that's
also
true
for
india.
That's
not
just
true
for
urine
tate.
B
B
So
I
think
we
have
to
take
a
long
hard
look
at
this
table
again
and
I'm
pretty
sorry
that
that
I'm
really
noticing
this
only
now
because
of
course
changing
this
table
will
impact
implementations
and
we
don't
really
want
to
to
mess
up
the
implementation
space
of
this.
But
I
think
it's
this
is
actually
worth
looking
at
once
more
any
comments
on
this
slide.
B
Okay,
then
I
go
on.
We
can
discuss
things
at
the
end.
There
are
a
few
more
things
in
in
the
comment
document
that
are
probably
worth
changing.
One
is
the
text
about
block
wise
transfers.
That
really
doesn't
say
anything
that
is
specific
to
coma.
It
just
has
some
some
general
observations
about
block
wise
transfers
and
I'm
not
sure
that
we
have
to
repeat
those
general
observations
in
the
coma
document.
B
So
I
think
what
we
need
to
do
here
is
just
mention
that
there
is
as
soon
as
you
get
into
the
the
field
of
block
wise
transfers.
There
are
additional
considerations,
but
we
shouldn't
try
to
speculate
about
potential
solutions
for
that.
B
The
other
item
is
related,
but
it
is
not
about
block
wise
transfers
of
yang
zebra
data,
but
it's
about
discovery
data,
and
here
the
text
says
pagination
should
be
provided
for
discovery
data
in
well-known
core
and
that
doesn't
work
because
right
now
we
don't
have
a
way
to
do
pagination
for
well-known
core.
We
have
one
for
the
core
resource
directory
which
may
need
to
deal
with
much
larger
data
sets
and
therefore
needs
pagination
even
more,
but
we
don't
have
one
for
well-known
car.
B
So,
first
of
all
the
the
requirement
that
is
put
out
here,
it's
not
clear
how
to
actually
fulfill
that,
and
then
it's
a
should
and
the
next
question
with
the
should,
of
course,
is
always
now.
Why
is
this
not
a
must,
or
in
other
words,
why
didn't
we
write
down
what
the
conditions
are
in
which
this
should
can
be
violated.
B
And
I
I
didn't
fail
to
note
that
that
pagination
is
actually
something
that
is
actively
being
discussed
in
the
net
confnet
mod
working
groups
as
well,
because
it's
it's
even
the
problem
for
yang,
and
so
it
would.
B
It
is
important
if
you
have
a
system
that
that
somehow
has
has
the
whole
default
routing
table
or
something
like
that
and
you
you
want
to
retrieve
that
that's
pretty
big,
so
it
probably
makes
sense
to
divide
this
in
into
multiple
rest,
con
transactions,
for
instance,
and
there's
even
a
draft
that
discusses
this.
I
don't
know
where
that
draft
is
right
now,
but
maybe
we
should
not
try
to
solve
this
here,
but
wait
for
for
the
yang
community
to
come
up
with
a
way
to
do
this.
B
So
I
think
these
two
need
to
be
cut
down.
I
don't
think
we
want
to
add
new
material
here.
I
think
we
we
just
want
don't
want
to
require
things
that
that
are
not
well
defined
or
are
essentially
impossible
on
this
slide.
B
Okay
and
finally,
there
are
a
few
nits
where
I
think
the
conclusion
is
pretty
clear
how
to
solve
them,
but
but
they
still
need
to
be
done.
So
the
current
text
is
is
not
clear
about
leading
zeroes
in
in
the
base64
encoding
of
numbers
of
sid
numbers,
and
one
could
read
it
as
saying
we
lied
all
leading
zeroes,
including
the
only
zero
if
we
encode
the
zit
the
sit
zero.
B
Nobody
probably
has
thought
about
that,
because
the
city
zero
is
unlikely
to
be
allocated,
but
still,
I
think
that
there's
a
certain
danger
here
to
do
something
that
that
can
be
abused
in
some
form.
So
we
should
probably
just
say
that
0
is
a
single,
a
and
and
don't
create
ambiguity
and
then
yeah
the
rest
is
just
stuff.
B
So
I
think
the
plan
is
to
to
have
a
new
version
of
comai
with
with
these
things
addressed,
and
I
think
that
the
technical
work
is
really
looking
at
this
again.
So
I'm
not
saying
we
have
to
change
it,
but
I
think
we
we
do
need
to
make
one
more
round
at
it
and
really
be
sure
we
want
it
to
be
that
way,
because
creating
a
non-backward,
compatible
incompatibility
between
int
and
uint
is
is
asking
for
trouble.
Even
if
the
the
young
doctors
tell
you,
everything
is
fine.
A
Okay,
so
discussion,
first
of
all,
thanks
karsten
for
raising
this.
These
good
points,
just
relaying
from
the
chat
on
on
your
point
about
pagination
and
well
done
core,
both
evo
and
christian
agree,
and
especially
if
there
are
broader
comments
from
from
me,
was
a
calls
or
please
take
the
mic.
C
So
from
my
point
of
view,
those
are
all
fair
comments,
as
you
set
for
the
table
for
encoding.
C
We
could
consider
changing
it
from
from
my
point
of
view,
that's
maybe
make
more
sense
for
the
implementations.
I
know
of
that
shouldn't
be
a
big
problem
to
to
change.
B
A
B
So
my
my
only
question
would
be:
do
we
have
to
do
another
working
glass
call
if
we
change
the
table
and
as
a
current
xx
chair
of
this
group,
I
I
probably
don't
have
to
make
that
decision,
because
I
won't
be
a
chair
anymore
when
that
decision
has
to
be
made,
but
I'm
not
entirely
sure
that
I
know
the
answer.
A
Yeah
I'll
open
that
with
me
too,
just
to
notice
there'll,
be
the
third
14
year
pass
call
if
you
count
the
the
whole
cluster
of
korkov,
so
just
by
gut
right
now,
I
lean
for
not
necessary,
but
it's
something
to
consider
later
on
you're
right,
okay,.
B
So
there
are
two
documents
in
the
cinematic
cluster.
One
is
the
versions
document
where
we
have
a
dash
02.
That
is
addressing
jaime's
comments.
So
heimer
did
a
review
and
he
asked
for
more
explanation
about
the
bit
mapping
approach
and
that
definitely
was
a
good
comment.
So
we
we
edit
that
added
a
few
references.
B
That
would
give
us
24
years
to
to
invent
another
way,
to
extend
cinema
and,
and
probably
that
won't
be
too
hard
in
particular,
since
we
have
must
understand
the
labels
that
we
can
use
as
well,
so
that
that's
dash
02,
there
is
also
an
implementation,
so
ari
put
an
implementation
of
the
the
bit
that
we
allocated
for
additional
units
into
his
cinema
validator
and
here's
an
example
where,
with
the
bit
set
kilometers
per
hour,
is
accepted
and
with
a
bit
cleared,
kilometer
per
hour
is
identified
as
invalid,
because
additional
units
are
not
to
be
used
unless
you
set
that
bit
yeah.
A
Dear
yeah,
we
discussed
already
at
the
meeting
in
november
that
we
wanted
to
have
some
comments
and
we
got
from
jaime.
So
the
next
step
is
definitely
starting.
A
working
group
class
called
this
and
not
sure
how
how
many
substantial
comments
or
requests
for
requirements
would
come,
because
it's
a
very
short
and
simple
document.
But
of
course
everyone
is
welcome.
B
Good,
so
the
other
document
is
the
data
content
format
document,
so
that
was
updated
with
a
few
editorial
clarifications
and
dimension
of
decompression
bombs
as
a
security
issue
in
the
security
considerations.
So
if
you
can
put
a
random
media
type
there,
you
might
be
able
to
put
in
a
media
type
that
enables
decompression
bombs,
and
then
you
can
attack
an
implementation
by
by
doing
that,
so
that
that
is
all
done.
B
It
looks
like
we,
we
will
first
need
to
restate
what
we
want
to
do
and
then
it
looks
like
this
will
turn
into
a
working
group,
and
so
this
looks
like
a
process
that
will
take
a
year
or
something
so.
My
proposal
for
for
getting
closure
on
the
data
content
format
document
is
just
to
remove
that
normative
reference
to
copy
over
the
abnf,
which
is
essentially
just
a
b
and
f.
That
has
been
wisely
chosen
from
the
various
abn
f's
record
reference.
D
Yeah,
that
sounds
like
the
most
straightforward,
but
I
would
like
to
see
more
discussion
in
the
dispatch,
because
that
was
the
output
right,
that
we
need
to
have
more
discussion
yeah
and
if
we
okay,
if
we
can
figure
it
out
quickly,
I
think
we
should
at
least
try
and
then,
if
we
can't,
then
yes,
we
move
forward
in
this
way.
B
Yeah,
but
I
I
think
I
will
still
prepare
the
pull
request
that
has
this
copy
over
thing
in
it,
and
I'm
I'm
not
proposing
to
abandon
the
media.
Quantum
type
format
thing
at
least
until
we
find
out
it
will
be
more
effort
than
it's
worth,
but
we
still
have
to
see
that
I
just
want
to
decouple.
The
trajectories
of
the
two
drafts
sounds
good.
E
A
Okay,
so
the
next
practical
step
is
a
pull
request.
Basically
exactly
okay.
B
A
A
F
I
am
okay,
so
yeah
just
bring
an
update
on
the
clockwise
transfer
and
basically
bottom
line
is.
We
believe
we're
ready
to
go
to
the
next
stage,
but
we'll
take
us
through.
So
if
you
can
go
to
the
next
slide,
please.
F
Okay,
so
there's
going
to
cover
changes
since
we
last
met
as
a
itf
conference
where
we're
at
with
the
implementation
and
what
the
next
steps
are
next
slide.
Please,
okay,
so
updates,
post
07,
so
christian
came
back
with
some
more
points.
We
have
worked
with
that
and
we've
actually
now,
just
this
morning,
uk
time
published
dash
08
covering
the
situation
here.
So
the
csm
option
for
tcp
getting
rid
of
extra
detail
was
not
necessarily
needed.
F
So
we've
got
rid
of
that
again,
emphasizing
the
disadvantage
within
the
new
block
of
being
able
to
mix
con
and
non
within
the
same
request
response.
We
have
to
be
one
or
the
other.
We
can't
mix
and
match.
Otherwise,
things
fall
apart
with
the
recovery
logic
and
some
clarity
over
peers
that
have
different
max
payloads,
the
consequences
of
that
and
how
they
can
be
possibly
synced
up,
which,
in
effect
is
out
of
scope
of
this
document.
F
So
after
much
debate,
we
went
for
q
block
one
and
q
block
two
and
then,
although
with
the
o2
o7,
is
quite
a
lot,
it's
just
really
evolved
since
the
last
ietf,
and
thanks
primarily
to
marco
and
christian
in
terms
of
feedback
and
excellent
work
there,
bringing
it
into
document
a
much
more
solid
space.
So
we've
added
in
some
additional
disadvantages
of
using
this
method,
in
one
sense,
to
discourage
people
to
use
this
as
an
alternative
to
the
old
blocking
mechanism.
F
This
is
kind
of
specifically
for
the
the
dots
requirement
where
there
are
likely
to
be
lossy
networks
and
we
cannot
handle
in
those
networks
confirmable
type
stuff,
but
in
order
to
test
four
gigabyte
q
block
we
have
to,
we
have
to
we've
mandated
that
it's
you've
got
to
be
using
confirmable.
Otherwise
we
just
get
back
reset
messages,
as
opposed
to
for
two
bad
options,
et
cetera.
It's
just
it's
very
difficult
to
work
out.
F
What's
going
on,
the
csm
now
has
dropped
added
in
clarification,
the
mixing
of
q
blocks
and
blocks
in
terms
of
inner
and
outer
wrappers
within
os
core.
F
You
can,
within
a
particular
wrapper
inside
or
outside
you
can
only
have
q
blocks
or
blocks,
but
you
can't
mix
and
match,
but
you
can
within
the
two
wrappers
and
we
just
put
in
some
additional
clarity
on
the
use
of
the
m
bit
in
requests
in
terms
of
the
block
end
bit,
and
essentially
that
means
giving
me
the
next
payload,
plus
all
the
ongoing
subsequent
payloads.
F
It
just
makes
things
simpler
and
more
clarity
in
there
next
slide.
Please,
and
so
in
terms
of
the
408
response,
which
basically
was
saying
we
are
missing
these
particular
blocks.
The
request
tag
could
be
derived
from
other
mechanisms,
so
we
removed
that
within
the
congestion
control
to
make
sure
that
things
keep
flowing
if
there
is
suitable
network
bandwidth,
etc.
F
For
the
the
q
block
one
when
we're
sending
effectively
block
ones
out,
there's
the
use
of
the
continued
response,
so
we
can
continue
quickly
after
setting
up
max
payloads,
which
is
defined
as
10
bodies
and
we'll
go
and
then
there's
a
special
case.
Q
block
2
request
special
case
of
the
using
the
mbit
where
the
client
can
say.
I've
got
all
that
stuff.
Give
me
the
next
lot
please,
rather
than
hanging
around
waiting
for
congestion,
control
of
a
default
of
two
or
four
seconds,
depending
on
what's
happening,
we've
updated
the
examples.
F
F
F
We've
had
it
up
and
running
in
dots
environments,
testing
in
lossy
networks,
it's
all
behaving
as
is
expected,
so
it's
from
an
implementation
perspective.
It
is
solid
next
slide,
please,
so
we
believe
that
all
the
things
that
have
been
raised
changed
and
all
the
rest
of
it
we've
adequately
handled
them.
Consider
them
come
back
with
suitable
changes
and
it's
been
proven
out
in
the
implementation.
So
you
know
essentially
we're
just
requesting
moving
forward
with
this
document.
G
With
all
the
changes
that
have
happened,
I'm
largely
happy
with
that
document.
It
fits
within
the
scope
that
it
sets
out
to
do.
I'm
there's
a
few
mechanisms
in
there,
I'm
not
fully
enthusiastic
about,
but
for
that
for
those
things
it's
supposed
to
do,
I
think
it
should
work
fine
and
I'm
happy
with
that,
and
thanks
to
both
the
authors,
you've
done
a
lot
of
work,
addressing
all
the
comments
and
it's
become
a
lot
better
than
than
I
have
expected.
Originally
thanks.
F
Okay,
great
thanks
very
much
christian.
It's
certainly
appreciated
all
your
input,
etc
and
yeah.
I
can
see
a
79
59
biz,
coming
out
where
it
will
take
some
of
this
work
and
other
work
to
make
block-wise
a
lot
more
kind
of
stable
moving
forward
and
it's
you
know
you
know:
we've
referred
to
already.
You
know.
Block-Wise
is
a
challenge
point
in
one
of
the
previous
presentations
by
carsten.
So
it's
you
know.
A
Yeah,
I
concur
thanks
john,
and
I
think
especially
the
last
update
clarifies
even
better
the
scope
you
had
in
mind
all
the
way.
I
suppose-
and
I
think
it's
also
a
good
seminar
as
a
seminal
material.
At
least
part
of
it
for
a
possible
block-wise
base
work
in
core
okay,
any
any
more
comments
opinion
on
this.
A
A
If
not,
then
I
think
the
next
step
is
the
shepherding.
I
can
be
the
shepherd.
I
hear
that
in
mind
already
considering
the
reviews
I
gave
before
so
I
think
next
week
already,
I
can
start
working
on
on
a
final
review
and
write
up.
I
don't
expect
to
come
up
with
big
comments
or
anything
considering
that
the
previous
review
and
and
the
building
up
on
christian's
comment
but
I'll
go
through
all
the
steps.
F
H
Okay,
hello,
everybody.
Can
you
hear
me
yes,
bill,
hi!
Okay,
just
give
me
a
second
I'll,
just
switch
my
desktops
a
little
bit,
so
I
can
optimize.
A
H
Great
great,
thank
you:
okay,
hello,
everybody!
So
I'll
give
you
a
quick
update
on
dyn
link
and
I
don't
have
very
many
slides
so,
firstly,
before
we
start,
I
would
like
to
thank
everybody
who
has
been
reviewing
the
documents
and
giving
lots
of
feedback,
and
I
see
that
ellen
and
michael
are
also
present
with
us,
and
they
have
been,
of
course,
instrumental
in
shaping
the
the
dangling
drops
lately
as
well,
or
at
least
michael
has
been
there
since
the
beginning.
H
Okay,
can
you
please
move
to
the
next
slide.
H
H
The
library
m2m
community
has
been
very
forthcoming,
with
some
modifications
and
and
requests
for
changes,
and
we
have
been
incorporating
that
and
also
dynamic
was
discussed
as
one
of
the
one
of
the
last
interim
meetings
held
last
month
in
in
core.
So
I
think
we'll
continue
to
have
these
kinds
of
like
during
meetings
to
progress.
The
draft
further,
let's
move
to
the
next
next
slide.
H
Okay,
the
first
change
is
a
substantial
facelift
in
the
in
the
editorial
sections.
What
we
did
was
that
we
started
to
accumulate
quite
a
lot
of
different
kinds
of
attributes,
and
then
it
became
necessary
to
be
able
to
logically
separate
them
into
two
kinds
of
classes:
the
multiplication
attributes
and
the
control
attributes.
H
So
now
there
are
two
tables:
one
of
them
contains
the
the
attributes
that
are
basically
conditional
notifications
and
then
the
other
ones
are
control,
attributes
that
that
more
or
less
refer
to
how
the
server
should
evaluate
certain
conditions
or
perform
sampling
and
so
on.
H
Now,
among
these
attributes,
the
the
new
ones
that
have
been
added
into
draft
13
are
the
last
two
from
both
tables,
so
the
age
attribute
and
the
confirmable
notification
attribute
before
that
we
already
added
the
epmain
and
etmax
that
you
see
in
the
table
too.
H
So
I
just
wanted
to
to
briefly
describe
what
edge
and
con
do.
If
you
move
the
next.
H
Slide:
okay,
now
I
see
it
all
right
so
h,
the
conditional
different
interview
is:
is
a
boolean
value
based
attribute,
basically
to
indicate
interest
for
receiving
notifications
of
either
the
following
age
or
the
rising
edge
transition
of
a
boolean
resource
state?
H
And
it's
fairly
obvious
when
the
when
the
the
value
of
age
is
zero,
then
then
you
are
basically
telling
the
server
notified
the
client
each
time
the
resource
state
changes
from
two
to
false
and
and
conversely,
the
value
of
h
is
one.
Then
the
server
notifies
the
client
each
time
the
resource
state
changes
from
false
to
true.
So
essentially,
by
setting
the
notification
attribute,
you
can
substantially
reduce
the
in
the
notifications
that
you
obtain,
if
by
perhaps
really
seeing
you're
gonna
apply
to
fifty
okay.
H
The
next
slide,
please
so
then
comes
con
column
is
the
conditional
control
attribute
and
sorry?
What
am
I
saying
here?
Yeah,
it's
not
conditional,
so
it's
confirmation
control
attribute.
Sorry,
that's
a
mistake
on
my
part,
so
con
is
used
to
flag
to
the
server
that
the
client
would
like
to
receive
multiplications,
essentially,
firstly,
by
saying
it's
on
the
conformal
transport,
but
it's
actually
saying
that
you
want
to
have
a
confirmable
message.
H
So
if
corn
is
one,
then
the
the
query
in
the
query,
then
the
column
interview
indicates
confusions
must
be
confirmable.
I
took
the
liberty
ellen
of
also
including
that
the
value
of
zero
is.
It
does
not
mean
that
the
notification
is
non-conformable,
but
but
then
it's
basically
surveying
several
dependents,
so
you
can
either
confirmable
or
not.
H
But
that
leads
me
to
the
next
question
to
the
working
group,
which
is
in
the
next
slide.
H
The
the
basic
thing
is
that
we
have
band
and
we
have
corn
and
in
our
current
graph
they
are
defined
as
parameters
that
have
boolean
type
values.
So
essentially
I
mean
in
rfc
3986
when
you
look
at
query,
query
components:
it
doesn't
necessarily
specify
the
query.
Parameters
have
to
be
key
value.
H
We
use
a
lot
of
the
conditional
attributes
to
have
key
value
passed,
but
on
the
other
hand,
we
have
a
little
bit
of
a
semantic
issue
that,
for
example,
ban
we
said:
if
ban
is
present
in
the
query,
then
it
basically
modifies
the
behavior
of
gd
and
lt
and
the
same
thing
is
with
column.
You
save
scores
one.
Then
it's
it's
basically
a
confirmable
message
that
you
want
to
receive
notifications
in.
H
So
the
question
is
whether
we
should
harmonize
this
behavior
so
that
for
ben
and
for
corn
we
eliminate
these
that
they
they
actually
have
value.
So
it's
easy
enough
that
we
just
indicate
that
there's
a
ban
or
a
chord
present
in
the
query.
D
I
I
hope
they're
here
we
have
in
in
the
past
needed
to
state
that
the
presence
of
band
is
equal
to
saying
band
equals
true
and
the
absence
of
band
is
equal
to
saying
band
equals
false
yeah.
So
it
would
not
hurt
my
feelings
if
we
just
made
it
explicit
and
always
required
a
name
value
pair,
but
there
may
be
other
reasons
to
not
do
that.
H
B
Fasting
yeah,
I
just
checked
7252
because
it's
been
a
while,
since
I
last
looked
at
that
section
and
it
actually
says
the
query
serves
to
further
parameterize
the
resource.
B
It
consists
of
a
sequence
of
arguments
separated
by
an
ampersand
character,
so
the
amberson
character
is
really
hard
coded
in
in
the
way
crap
handles
your
eyes
and
then
it
says
an
argument
is
often
in
the
form
of
a
key
equals
value
appear
so
that
that
is
definitely
not
hard
coded
and
and
from
the
point
of
view
of
7252
query
parameters
without
an
equals
design
are
fine.
B
F
B
Next
question
is:
what
does
the
parameter
actually
try
to
say?
So
if
you
have
a
boolean
parameter
that
you
can
set
to
zero
one
or
two
t
and
f
or
whatever
you
essentially
have
three
values,
one
is
zero.
One
is
one,
and
one
is
no,
no
preference
and
with
a
parameter
that
doesn't
have
liquid
sign,
you
only
have
presence
and
absence,
and
given
that
absence
will
be
used
by
everybody
who
doesn't
know
about
that,
query
parameter
it's
pretty
much
equivalent
to
no
preference.
B
So
you
essentially
only
can
say
I
I
have
something
I
want
to
say,
or
you
have
no
preference
and
that
that
something
I
want
to
say
from
my
point
of
view,
for
instance,
fits
very
well
to
the
con
attribute,
because
that
that's
really
an
an
option
that
that
the
requester
may
want
to
set
or
may
not
want
to
set
and
and
not
setting.
It
essentially
means
I
don't
have
a
preference
and
setting
it
means
the
requester
does
have
a
preference
so
for
for
con
that
really
works.
Well,
I'm
not.
B
H
Exactly
yes,
so
that's
that's
where
we
need
also
on
ellen's
input,
because
corn
is
used
in
like
with
m2m,
so.
J
J
J
I
I
I
would
assume
band's
kind
of
the
same
thing,
because
if
it's
not
present
you're
expecting
the
existing
behavior,
which
means
you're
treating
the
gt
and
ulti
independently
versus
the
the
band
is
present,
then
that
means
you
are
stating
a
preference
by
default,
which
means
you
do
want
it
to
be
painted
as
band
equals,
one
which,
once
again,
why
send
x
two
extra
characters
for
no
value.
H
Yeah,
so
I
I
would
like
to
respond
to
that,
because
we
actually
have
three
attributes
that
that
are
specified
as
boolean
types.
The
last
one
is
h
and
in
h
there
actually
is.
Is
that
significant,
whether
zero
or
one
for
ben
and
and
corn,
they
they
are
used
more
as
qualifiers.
So
I
would
also
recommend
that
we
drop
the
specification
that
ben
and
con
are
basically
boolean
values,
they're,
just
basically
attributes
with
no
values.
It's
just
qualifiers.
I
Something
yeah
yeah.
I
wanted
to
say
that
I
don't
think
band
is
the
kind
of
thing
where
you
would
let
want
the
server
to
choose,
not
have
a
preference.
I
think
you
always
have
a
preference
for
band,
because
the
behavior
is
different
and
you
will
get
notifications,
you
didn't
expect,
or
you
will
not
get
notifications.
You
do
expect
if
band
isn't
set
the
way
you
want
it.
So
I'm
not
sure
I
agree
about
band.
I
It's
to
me.
It's
more
like
edge,
it's
very
much
like
edge.
In
fact,
I
have
some
more
comments
about
edge,
but
I
can
do
that
in
writing
later
and
con.
Also,
in
my
experience
with
the
implementation,
it's
useful
to
specify
that
you
do
not
want
confirmable
responses,
because
what
happens
in
constrained
networks
is
sometimes
it
works
better
to
not
have
the
extra
messages
and
the
system
performs
better
if
you
just
use
non-confirmable
messages
so
also
for
khan,
it
it
seems
like
there.
I
have
seen
value
in
being
able
to
set
it
to
false.
I
J
J
Which
covers
the
default
so
that
you
don't
have
to
send
it
every
observation,
so
the
defaults
generally
is
non-confirmable
and
that
way
you
don't
have
the
extra
traffic
and
then
you
only
sit
at
the
confirmable
in
those
explicit
observations
that
you
think
are
critical
in
nature.
So
that's
why
we
kind
of
wrote
it.
The
way
we
did
is
is
by
default.
The
system
does
not
send
a
confirmation,
because
it's
things
like
you
know
the
temperature,
the
current
temperature
reading,
which
is
you
know
once
per
minute.
J
H
I
I
I'm
I'm
not
sure
now,
but
it
still
seems
like
it's
useful
to
depend
on
it
being
false
and
if
there's
no
way
to
do
that,
it
might
limit
the
use
of
it.
You
know
if
the
system
can
only
choose-
and
I
don't
have
an
option
of
saying
false
that
might
limit
some
some
uses,
but
there
again
there
might
be
better.
There
might
be
better
to
do
it.
For
other
reasons,.
H
J
Yeah,
michael,
I
agree
because
we've
got
a
default
state
that
gave
us
some
freedom.
If
you
assume
no
default
state,
then
you
want
each
god.
I
hate
to
use
the
word
item
potent,
but
you
want
each
independent
observation
to
be
able
to
set
the
characteristics
full
characteristics
of
that
observation
without
assuming
some
default
behavior,
in
which
case
con
equal
one
or
con
equals
zero
makes
more
sense.
So
if
we
do
want
to
do
it
that
way,
it
makes
you
know
it's
it's
a
better
independent
configuration.
J
That
would
change
that
behavior,
because
now
there
is
a
stated
behavior
that
sort
of
is
expressing
without
the
assumption
of
a
default.
So
I
would
go
to
each
other.
I
think
carson
said
that
there's
really
three
states
the
service
expressing
that
it
wants
a
confirmable
con
equal
one.
The
server
is
expressing
it
once
it's
non-confirmable
chronicle,
zero
or
the
server
is
not
expressing
a
preference
which
con
does
not
exist
in
the.
I
Observation,
michael
well,
so
so
I
think
I
just
heard
ellen
say
that
he
would
want
three
states.
F
I
Settings
they
definitely
do
it.
Definitely
don't
do
it
and
I
don't
care
you
choose,
and
I
think
that
I
was
thinking
more
like
two
states
like
if,
but
I
guess,
if
you
don't
care,
you're
you're
saying
that
for
band,
if
you
don't
include
the
option,
I
don't
know
if
we'd
make
it
mandatory
or
not.
But
if
right
now,
if
you
didn't
include
the
option,
we've
been
saying
that's
equal
to
saying
that
it's
false,
I
don't
know
if
that's
a
good
rule
or
not,
but.
I
H
I
I
We
have
historically
said
that
the
system
ultimately
can
choose,
because
of
maybe
it's
only
built
one
way
or
the
other,
and
you
might
have
to
deal
with
what
the
system
does,
but
so
maybe
con
is
more
of
a
hint
and
and
and
maybe
the
other
ones
aren't
I'm
not
sure
about
that
because
of
the
general
behavior
for
confirmable
responses.
We've
we've
kind
of
always
said
that
it's
you
know.
I
G
Christian
is
on
the
queue
doing
doing
doing
the
con
as
more
of
a
hint
sounds
like
the
right
thing
to
do
for
me,
especially
considering
all
those
cases
when
I
know
I
know
some
parts
of
this
are
not
really
fought
for
proxies
either
anyway,
but
there
are
so
many
reasons
why
there
could
be
a
con
involved
that
making
this
a
hard
rule
sounds
excessive
to
me.
H
So
do
you
think
that,
because
currently
in
our
draft
the
when
con
is
set
to
one,
then
it's
a
must
that
the
notification
must
be
sent
in
a
confirmation
message.
A
G
G
Do
you
think
it
would
make
sense
to
when
coming
to
the
later
parts,
where
it
talks
about
the
different
ways
and
observation
binding
can
be
set
up,
whether
that's
oops
by
observation
or
by
pushing
to
distinguish
which
of
those
attributes
are
usable
with
all
of
them
and
which
are
only
usable
with
those
that
are
those
like
push
because
edge,
for
example.
Edge
for
observation
doesn't
sound
too
actionable
for
me,
because
that's
already
the
latest
state
of
that
resource
view.
G
So
it
doesn't
change,
for
it
doesn't
make
sense
for
observation,
but
it
makes
a
lot
of
sense
for
for
for
put
for
posting
and
not
so
much
for
putting
actually
so
that
I
think
it
would
help
if
that
would
wear
a
bit
fleshed
out.
H
Yeah
just
to
comment
on
that.
So
that's
that's
some
that
that's
the
case
that
I
have
been
mulling
over
also
so
so
what
do
we
do
with
edge
when
you
set
edge
together
with
evin
and
pmax,
when
you
send
a
notification,
whether
it's
actually
a
notification
cost?
Because
you
are
you
had
the
you
have
had
the
resources
already
changed
states
two
times
and
then
sending
a
message
because
of
age?
Or
is
it
because
you,
you
have
just
you're
trying
to
keep
the
messages
going
with
bmx.
So
there's
that's
some!
H
H
So
if
there's
nothing
else,
then
we
can.
We
can
move
on
there's
only
a
couple
of
more
slides,
which
are
just
basically
updates,
and
these
are
updates
just
from
the
feedback
that
we
received
at
the
last
internet
meeting.
H
So
so,
essentially,
because
of
the
fact
that
that
we
are
now
trying
to
also
include
the
fact
that
p
main
can
be
equals
to
p
max
to
indicate
that
that
the
server
should
be
sending
notifications
to
clients
at
every
n
seconds
and
the
fact
that
that's
actually
a
constraint
that
perhaps
the
server
may
not
be
able
to
fulfill
the
implementation.
Consideration
section
provides
tax
that
this
is
performed
as
a
best
effort
service
from
the
server.
H
Next
slide,
so,
finally,
we
also-
I
want
to
update
the
next
steps
in
this,
so
I
I'm
not
entirely
certain
whether
we
are
actually
incorporating
any
more
attributes,
but
we
have
been
discussing
what
happens.
What
happens
if
there
are
the
if
there
are
one
or
more
proxies
sitting
between
the
client
and
the
server,
and
what
is
the
impact
in
the
behavior
of
the
conditional
notifications?
H
I
think
it
would
be
very
good
of
the
discussions
actually
that
we
should
actually
include
some
more
examples
in
the
apprentices
to
illustrate
the
cases
better
and
then
the
final
thing
is
that
in
section,
3.3
michael
contributed
some
code
that
discusses
the
server
side,
processing
of
conditional
attributes,
and
I
think
it
would
be
good
to
be
able
to
maybe
perhaps
include
a
state
machine
there
as
well
to
describe,
for
example,
what
happens
when
you
actually
have
e
and
eating
next
that's
been
set.
B
Anymore,
those
controls
are
really
weird
anyway,
so
you
talked
entirely
about
the
the
conditional
notification
part.
There's
also
the
ping
table
part
as
there'll.
H
H
No,
no,
not
yet
that's
that's
the
other,
the
other
big
question,
whether
whether
the
draft
should
be
split
into
two
parts,
one
one
focusing
on
the
conditional
multiplications
and
one
focusing
on
the
on
the
the
link
itself
and
we
haven't
had
much
discussion
yet
on
the
second
part
of
the
draft,
where
there
has
been
the
issues
that
that
were
describing
the
attributes
for
the
links.
I
Yeah,
so
I've
been
thinking
about
this
and
kind
of
like
looking
at
different.
It
occurs
to
me
that
the
dynamic
link
concept
can
be
used
independently
of
the
observed,
attributes
and
and
observe
attributes
are
already
being
used
independently
of
the
link.
So.
I
To
make
a
lot
of
sense,
this
is
already.
This
has
already
been
split
from
one
draft
before
interfaces,
but
now
like
we,
we
probably
should
split
it
again,
and
I
think
that
there
were
some
independent
questions
and
there
really
isn't
a
lot
of
of
interaction
at
all.
So
to
me
it
would
have
very
little
impact
splitting
it
also.
B
I
H
I
would
support
that
argument,
but
christian
is
there
and
carsten
is
on
the
cube
with
two
people.
G
Yeah
also
also
supporting
this
as
much
as
I'd
like
to
kind
of
hook
on
to
the
momentum
this
document
has
and
get
pulled
by.
It
was
the
part
that's
interesting
to
me,
which
is
the
dynamic
links
and
not
so
much
the
the
attributes.
G
H
So
it
looks
like
with
the
working
group
is
in
favor
of
this
document
being
split
into
two
parts.
B
A
H
H
H
So
is
it
you
know
if
you
really
want
to
consider
these
interactions
to
be
end-to-end
or,
as
we
saw
talk
about
hob,
and
I
think,
as
authors
and
and
and
myself,
we
we
kind
of
were
looking
at
the
whole
hope
approach,
but
but
if,
in
fact
it
is
necessary
to
look
at
it
from
the
perspective
of
a
proxy
sitting
in
the
middle
of
a
of
I
don't
know
what
you
call
a
downlink
client
landing
server,
then
we'll
have
to
look
at
what
what
the
proxy
can
do
to
impact
this.
A
A
A
G
So
I
start
with
the
resource
track
during
extension,
because
that's
what
triggered
the
the
transport
negotiator
transport
communication
topic
in
the
first
place,
I've
presented
this
as
an
interim
last
itf
or
one
of
their
story,
never
mind.
You've
seen
this
slide
before
next
slide.
Please
sorry,
that's
a
bit
of
a
more
more
concise
expression
of
what
is
in
there.
G
Rd
extensions
is
about
all
those
things
you
can
do
with
a
resource
directory
without
having
to
change
how
the
resource
directory
specification
works,
which
allows
us
to
get
this
out
finally,
and
doing
doing
more
things
with
it
of
all
those
that
are
listed
here.
G
I'd
like
to
pick
out
the
one
that
I
think
is
most
important,
because
there
are
many
use
cases
where
people
rather
go
with
mqtt,
even
though
they
need
most
of
co-op
semantics,
but
they
take
impurities,
because
this
way
they
can
have
their
devices
in
the
network
and
still
get
out
through
their
through
their
firewall,
because
they
have
something
in
be
something
that
you
out
there
that
redirect
that
gives
them.
This
kind
of
redirection
next
slide
please,
and
this
is
something
that
an
rd
based
reverse
proxy
can
do
so.
G
The
thing
that
I'm
describing
in
the
in
the
extensions
section
is
that
if
you
specify
this
additional
registration
attribute,
which
is
proxy,
equals
on
much
by
chatting
to
be
had,
but
that's
for
later,
then
you
ask
the
resource
directory
to
provide
you
with
a
with
a
proxying
service.
Give
provide
another
name
for
you.
That
is
publicly
reachable,
because
your
20280
address
might
be
behind
a
stateful.
G
Firewall
might
not
even
be
on
the
latest
version
of
the
internet
protocol
what's
or
not,
and
just
give
you
a
name
that
everyone
else
can
use
and
become
a
reverse
proxy
for
you
and
by
the
by,
because
your
resources
are
already
discovered
through
the
resource
directory.
That's
a
good
point
where
the
directory
can
hook
in
and
rewrite
the
addresses
and
send
things
on
to
you.
G
This
is
being
used
a
lot
in
practice,
even
not
by
this
precise
name
and
this
precise
agreement,
but
most
of
library
m2m
does
precisely
that
the
end
points
register
at
the
resource
directory
and
that
very
connection
be
that
the
udp
five
tuple,
that's
now
known
to
the
stateful,
firewall
or
b,
that
the
tcp
connection
that
has
been
opened
is
then
used
to
enroll
reversal
mode
to
send
all
the
requests
that
come
in
through
the
proxy
onto
the
onto
the
actual
server
in
lightweight
m2m.
G
That's
mostly
done
through
a
proxy
that
is
caching
that
is
eagerly
caching,
that's
kind
of
taking
things
in
and
they're,
not
exposing
it
as
co-op
on
the
other
side.
But
the
mechanism
that's
described
here
is
is
already
widely
deployed,
at
least
with
at
least
in
this
particular
setting.
G
We've
used
this
for
a
few
times,
also
in
the
in
the
hackathon,
because
if
you
have
your
local
server
running,
you
don't
have
to
do
all
those
firewall
things.
You
just
register
your
device,
add
a
resource
directory
that
has
this
proxy
facility
and
then
let
let
that
do
its
magic
and
see
the
question
from
the
on
table.
G
G
G
I
don't
think
it's
a
completely
stupid
idea,
because
then
I
wouldn't
be
presenting
it,
but
it
has
a
big
downside
that
is
urialising,
which
is
we
now
have
two
uris
being
the
one
that
the
resource
director
minted
and
the
original
ip
address,
based
one
that
both
refer
to
the
same
resource
and
in
the
general
web.
G
It's
good
practice
to
avoid
this
now
conceptually
this
could
be
avoided
if
all
the
clients
use
the
resource
directory
as
a
proxy
only
to
access
the
device
under
its
original
name
and
its
canonical
name,
that
it
picks
for
itself
behind
the
resource
directory.
Hard
part
is.
G
The
clients
would
have
to
discover
that
proxy
and
that's
a
topic
we've
already
had
at
some
point
being
in
the
protocol
negotiation,
because
there
we
have
the
same
issue:
that
for
technical
reasons,
not
for
uri
design
reasons.
We
have
different
addresses
that
are
in
the
server
used
for
the
same
purpose.
G
So
there
was
a
say
working
group
in
the
working
group
in
in
t2
grg
for
some
time
until
none
of
us
had
too
much
drive
or
time
to
to
continue
there
to
finish
what
was
started
as
protocol
negotiation
originally,
and
also
to
do
a
bit
of
work
on
on
the
sms
side
and
driven
by
that
resource
directory
use
cases.
G
I've
decided
to
just
take
this
up
again
and
send
write
out
something
that
could
be
used
starting
point
here
and
I
think
it
just
dresses
most
of
the
most
of
the
the
things
we
need
there.
So
how
it
works
is
that
a
server
can
announce
via
the
regular
link
relations
that
we
use
all
around,
that
it
has
a
proxy
at
a
particular
location.
G
With
this
precise
semantics,
being
everything
that
is
hosted
on
this
host
is
a
resource
that
is
reachable
if
you
go
through
that
proxy
and
that
solves
the
that
solves
most
of
the
urializing
problem,
because
then
you
just
send
a
proxy
request
through
co-op
plus
tcp,
and
it's
not
for
what
it
does.
Proxying
usually
is,
but
it's
just
taken
internally
and
that
proxy
really
I'll
call
it
the
self-hosted
proxy
there.
G
It's
just
a
proxy
for
this
very
device,
but
this
allows
us
to
get
around
all
this
uri
alliancing
troubles
there's
an
additional
facility
in
there
that
describes
that
you
can
also
advertise.
That
is
a
unique
proxy,
which
just
means
that
the
proxy
is
proxying,
but
it's
not
looking
at
the
proxy
scheme
or
uri
host
at
all,
and
it's
just
a
stupid
proxy
that
forwards
to
one
location
only
so
that
you
don't
have
to
send
those
verbose
ip
address
and
scheme
name
in
the
trend
in
the
transport.
G
So
there
is
in
a
sense
some
uri
ally,
sing
in
that,
if
you're
looking
at
it
from
a
package
point
of
view,
you
see
there's
a
request
there
and
it
gives
you
the
same
response
as
the
other
one,
but
on
the
application
level,
you
never
get
to
see
all
the
ugliness
of
of
your
that
that's
lurking
at
some
point
in
there.
As
long
as
we
don't
send
additional
data
next
slide,
please
so.
B
G
That's
just
that's!
No!
That's
that's
really
just
one
other
resource,
that's
being
advert
advert
advertised
on
that
server
and
to
some
extent
the
justification
for
the
example
that
I
stripped
when
I
later
shortened
the
slides.
G
But
the
point
is
you
discover
this
whole
thing
from
co-op,
h1
example.com
and
then
you
see
that
there's
the
resource
and
there
is
the
proxy
that's
for
the
general
host
and
because
resource
and
that's
what
the
statement
you
gives
resource
is
by
all
those
implicit
rules
of
6690
hosted
on
slash
and
because
slash
in
full
being
co-op
h,
one
example:
com
slash
having
this
proxy.
You
can
also
address
that.
Ask
that
proxy
for
a
representation
of
co-op
h1
example
comres,
but
I
could
also
say.
G
G
G
The
next
steps
for
me
are
just
to
bring
this
out
into
the
community
gather
feedback,
there's
probably
a
lot
of
of
tuning,
not
only
in
terms
of
name
by
chatting,
but
also
in
which
direction
do
the
relationships
work
best
so
that
you
can
express
them
by
utilizing
all
the
compression
mechanisms
that
are
and
then
update,
drd
extensions
to
show
how
that
could
be
used.
G
So
I'm
not
sure
that
the
reverse
proxy
in
case
that
I
have
now
goes
away
there,
because
there
are
probably
many
applications
that
really
don't
care
about
your
realizing
and
that
are
that.
Don't
have
good
names
for
the
devices
themselves
anyway,
and
anything
that
the
rd
gets
them
is
good
enough
as
a
public
name,
but
there
are
certainly
other
cases
where
we
care
do
care
about
urializing
and
there
that
could
be
used
in
say
a
proxy
with
in
a
proxy
option
that
could
distinguish
between.
Do
you
do
I
want
the
reverse
proxy?
G
That's
it
as
far
as
I'm
concerned,
questions
comments.
A
G
K
B
A
L
Good
things:
okay,
first
of
all
many
things
to
the
chairs
for
providing
this
presentation
slot.
We
are
looking
together
with
christian,
also
into
information
centric
networks
for
constrained
iot
deployments
for
quite
some
time
now,
and
recently
we
discovered
that
you
can
like
draw
some
intriguing
parallels
between
icn
and
co-op
deployments.
L
So
next
slide,
please,
let's
start
with
what's
icn?
Well,
it's
an
alternative
networking
paradigm
that
specializes
in
content
delivery
and
it
provides
a
very
loose
coupling
between
data
and
content
producers,
an
application
that
asks
for
network
or
actually
an
application
like
that
ask
for
data,
will
never
specify
a
server
endpoint
in
in
these
cases,
and
there
are
true,
very
prominent
architectures
that
implement
these
kind
of
icn
paradigms
and
that
are
named
data,
networking
and
content.
L
The
key
protocol
features
of
these
architectures
are
that
they
support
the
name
based
and
stable
forwarding.
They
have
an
on-path
content.
Caching
and
they
have
object.
Security
on
the
content
level
and
more
and
more
research
well
indicates
that
icn
systems
can
be
promising
candidates
for
constrained
iot
deployments
next
slide.
Please.
L
So
in
the
end
and
ccnx
can,
for
certain
scenarios
and
to
some
extent,
increase
network
resilience
and
reduce
link
reversals
object.
Security
provides
an
end-to-end
protection,
which
is
of
course
well
known
in
this
group,
with
all
the
oscar
efforts,
and
this
protection
also
applies
to
cache
contents,
especially
when
the
contents
are
like
cached
for
longer
periods.
L
If
we
look
at
the
technical
aspects
of
andy
nccnx,
then
we
can
easily
see
that
there
are
some
parallels
to
co-op
first
and
the
end
cc
and
x
follow
a
request
response
paradigm,
which
is
also
true
to
some
extent,
for
co-op.
There
is
a
request,
message
called
interest
and
there's
a
response
message
called
data
next
slide.
L
L
Please
next
slide,
please
and
as
the
last
component
in
the
ncc
nx
yeah,
they
employ
content,
object,
security
and,
like
I
said
before,
this
group
is
of
course
well
aware
of
well
this
kind
of
technique
with
all
the
oscar
efforts.
So
we
can
skip
this
next
slide.
Please.
L
L
Now
the
proxies
give
us
give
us
a
hop-wise
request
date
and
also
hop-wise
caching
and
top-wise
re-transmissions.
So
exactly
like
it's
what
ccn
and
ndn
is
giving
us
and,
in
addition,
the
forwarding
decisions
on
the
proxies
are
now
done
by
uris.
L
Instead
of
the
ap
addresses
so
again,
very
similar
to
what
indian
and
ccnx
are
doing,
there's
also
a
bonus
that
we
actually
this
or
if
we
that
surprised
us,
when
we
looked
at
the
wireshark
dumps
between
the
proxies
we
used
linked
local
ipv6
addresses
and
in
these
well.
These
addresses
were
derived
from
the
15.4
mac
address.
So
6lowpan
is
now
able
to
fully
align
the
ipsource
and
destination
addresses
and
we
saved
around
32
bytes,
using
this
deployment
for
each
packet
between
the
proxies.
L
So
most
icn
systems
also
support
multi-party
communication,
mostly
using
the
features,
request,
aggregation
and
response,
fam
out
and
request,
find
out
and
response,
duplication,
deduplication
and,
of
course,
by
using
a
data
centric
deployment
co-op
would
be
able
to
benefit
from
from
the
same
moody
party
communication
feature.
L
There
is
not.
We
have
much
research
now
this
area,
but
we
are
working
on
providing
more
results
and
experiments
that
focuses
more
on
the
multiparty
communication.
Next
slide.
L
Next
step
brings
us
to
the
conclusions
and
outlook,
so
the
takeaway
is
that
we
were
able
to
show,
in
our
experimental
results,
that
this
kind
of
deployment
actually
increases.
The
network
resilience
reduces
latency
and
also
the
link
stress.
The
location.
Independence
of
content
allows
for
and
easy
mobility
support.
We
can
employ
an
efficient
multiparty
communication,
and
this
kind
of
deployment
also
proves
that
coop
is
kind
of
very
versatile.
L
B
L
Yeah,
if
you
go
back
to
the
slide
number,
what
was
it
eight?
I
think,
then
we
can
see
yeah
yeah
yeah,
the
below
picture
there.
You
can
see
that
I
mean
this
is
a
co-op
deployment
in
the
below
picture
and
of
course
we
don't
have
interest,
but
we
have
gets
in
this
case.
So
this
is
the
co-op
version
of
doing
requests.
L
You
get
for
a
specific
uri
where
to
forward
this
message.
Of
course
we
need
some
form
of
logic
here.
This
means
it
could
be
like
a
forward
information
base
on
the
proxy
level.
What
we
did
in
our
experiments
was,
of
course,
hard
coding
it.
Hence
the
future
work
item
to
making
this
dynamic.
B
So
how
would
how
could
the
resource
directory
actually
maybe
aid
this
process.
L
Yeah
yeah,
that's
at
least
for
the
discovery
part
part.
We
also
thought
about
using
the
research
directly.
I
think
christian
also
had
some
strong
comments
regarding
this.
G
It's
more
the
the
discovery,
it's
more
about
local
discovery
of
links,
so
in
in
say
when,
when
you
take
the
setups,
we
have
now
and
apply
the
apply
this
then
the
next
step
you
would
look
into,
is
actually
your
routine
table
so
rather
than
having
a
next
hop
for
basically
for
each
name
on
the
network,
and
just
if
you
use
result
winning
names,
then
for
each
ipv
for
each
ip
subnet
you
would
have
a
route
to
go
to,
and
that
would-
and
there
might
be
some
there
might
be
something
better
than
just
sending
it
out
as
a
get
in
that.
G
L
G
B
Directory,
okay,
so
all
the
usual
scaling
issues
apply
and
so
how?
How
do
you
get
back,
some
hierarchy
and
and
so
on,
but
yeah
that
looks
interesting.
L
L
L
Yeah
actually
yeah.
Actually,
we
did
add
oscar
to
this
picture,
and
this
is
also
we
use
the
the
cachable
oscar
draft.
That
christian
has
because,
as
you
know,
oscar
is
not
yet
casual
and
it
worked
quite
good.
I
mean
we
saw
like
an
improvement
of
success
rates
in
a
network
that
has
a
lot
of
losses
and
we
were
able
to
like
recover
a
lot
of
messages
by
having
this
yeah
pulling
closer
of
content
for
each.
A
L
L
A
Thank
you
very
much.
Thank
you.
L
Yeah
I
mean
this.
Of
course,
this
kind
of
deployment
works
very
well
with.
I
think
it's
called
in
this
group
safe
requests
or
like
requests
that
are
like
important
and
where
the
request
to
a
specific
name
or
uri
always
like
results
in
the
same
content,
which
of
course
then
benefits
from
the
cachets,
and
I
think
the
use
case.
That
is
very
good,
for
this
is,
of
course
like
firmware
updates
and
software
deployment
and
stuff,
and
maybe
we
can
look
into
this
direction.
B
B
Experiment,
so
they
are
not
using
us
car
for
end-to-end
security.
They
have
their
own
suit
thing
for
for
securing
the
the
update,
but
still,
I
think
it
that's
maybe
interesting
to
propose
that
as
an
experiment
to
get
the
firmware
update
from
the
closest
place
where
it
is
instead
of
having
to
to
get
it
from
a
server
all
the
time.
L
A
And
we
are
at
the
end
of
the
agenda
with
plus
one
it's
good
to
have
a
bit
of
delay.
Anyway,
we
have
time
in
case
there's
any
open
point
to
discuss
from
anyone.
A
Otherwise
we
are
going
to
resume
with
a
series
of
interim
meetings,
starting
from
the
28th
of
april
back
on
wednesdays,
and
we
are
going
to
have
six
interim
meetings
before
its
111.
B
Can
you
maybe
give
an
overview,
a
guest
divination,
whatever
what
these
interims
will
be
about
the
next
ones
that
we
are
going
to
have.
A
We
don't
have
an
agenda
on
them
yet,
but
I
can
imagine
discussions
on
online
link,
possibly
uncashable
score
and
on
some
open
points
that
were
opening
up
the
coming
days,
especially
on
group
combis.
B
B
Yeah
I
think
april
28
is
far
enough
out
that
we
should
be
able
to
to
make
ourselves
a
little
bit
of
a
program
what
we
want
to
have
prepared
by
them,
so
that
that
people
just
don't
drop
their
pencils
and
then
pick
them
up
on
april
28th
again,
but
but
actually
know
that
that
we
will
be
doing
something
there
and
it's
maybe
useful
to
prepare
something.