►
From YouTube: IETF115-ICNRG-20221108-1300
Description
ICNRG meeting session at IETF115
2022/11/08 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
C
C
Okay,
welcome
to
IC
energy.
This
is
this
meeting
is
spending
the
globe
I
think
so
it's
in
UTC
time
zone,
I'm,
plus
eight
Davis,
minus
six,
I
think
and
I
know
that
Mark
is
there
from
-9.
C
C
Okay,
before
we
start
the
usual
housekeeping
things
so
we're
here
in
the
internet
research
task
force,
we
follow
the
ietf
IPR
rules,
there's
total
rules.
C
So
let
us
know
if
there's
any
IPR
related
contribution
that
you
make
or
that
you
see
or
that
you
are
aware
of
in
this
context
and
okay,
the
most
important
thing
here
is
The
Mask
policy.
C
It
sounds
a
bit
strange
because
we're
not
wearing
masks,
but
we
are
just
by
ourselves,
and
so
we
just
got
reminded
to
announce
this
again.
Please
keep
your
your
ffp2
or
n95
mask
up
unless
you're
already
speaking
at
the
microphone,
and
you
cannot
be
heard
otherwise.
C
Okay,
usual
agenda
hints
and
a
quick
reminder.
This
is
the
internet
research
task
force.
We
are
not
doing
internet
standards
here
we
are
doing
research
and
the
RCs
that
we
produce
are
typically
of
informational
or
experimental
nature
to
enable
future
experiments
and
then
generate
some
insights
for
the
like,
larger
community,
okay
yeah.
C
My
question
is
David
I'm
I'm,
the
Kucha,
and
before
we
move
on,
we
have
to
find
a
note
taker
and
if
you're
new
to
this,
this
is
a
fairly
light
job.
So
we
are
not
capturing
all
the
presentations
just
did
and
just
of
the
discussions,
and
it
is
quite
informal.
So
it's
just
important
that
we
kind
of
capture
the
technical
content
and
yeah.
It's
all
the
other
groups.
We
cannot
move
on
without
a
notaker.
C
C
So
what
you're
thinking
about
it?
Maybe
just
one
other
thing:
please
use
the
media
Collide
tool,
even
if
you
are
in
the
room
and
to
form
like
the
queue
management
so
that
people
can
get
your
name.
It
makes
it
much
easier.
Also
I,
don't
know
taker
foreign
and
it
doesn't
hurt
to
just
say
your
name
when
you're
making
comments
or
questions.
D
C
C
C
Great,
so
this
is
our
agenda
for
today,
so
we
are
going
to
have
like
two
presentations
on
manifest
container
topics.
C
Then
one
on
the
C4
ccnx
implementation
and
its
application
to
Cloud
native
use
cases
and
and
then
I'm,
going
to
talk
a
bit
about
some
ideas
for
rest
for
ICM,
and
then
we
can
discuss
any
other
business.
Is
there
anything
else
that
we
want
to
talk
about
today
or
that
you
would
like
to
change
in
the
agenda.
C
Okay,
then,
let's
look
at
our
research
group
status,
so
we
have
a
couple
of
documents
that
should
be
published
soon,
so
CC
and
info
is
sent
to
the
RC
editor
things
not
yet
published.
C
We
last
called
time
tlv
and
it's
now
waiting
for
Colin
to
initiate
the
irs3
review.
I
think
flick,
we're
going
to
talk
about
in
a
minute,
and
then
we
have
ICM
ping
Trace
out
and
path.
Steering
and
yeah
Dave
can
give
us
an
update
on
this
since
he's
heavily
involved
in
those
yeah.
B
So,
as
most
of
you
know,
we
last
call
both
ping
and
Trisha.
Quite
a
while
ago,
it's
been
through
irsg
review
successfully
got
some
very
good
comments
from
Chris
Wood
and
a
couple
of
other
people,
and
those
have
been
revved
and
checked
back
through
and
are
pretty
much
ready
to
go
to
the
final
stages
of
iesg,
conflict
review
and
final
Ayana
processing.
B
But
we've
had
a
conversation
with
the
ir3f
chair
and
because
both
of
those
capabilities
for
management
are
significantly
enhanced
if
they
can
make
use
of
the
capabilities
of
path,
steering
we
sort
of
jointly
felt
that
we
invest
to
progress
all
three
of
these
to
publication
as
rfcs
together,
so
we're
going
to
hold
up
ping
and
trace
route
from
the
sort
of
the
final
processing.
Although
of
course
please
go
ahead
with
you
know,
modified
implementations
and
experimentation
on
those.
So
we
can
finish
up
paths
here
now.
B
Status
of
pad
steering
is
as
follows.
It
was
an
individual
draft
for
a
while.
It's
been
went
through
a
number
of
revisions.
It's
been
looked
at
pretty
carefully
by
people
in
both
the
CCN
and
in
the
end
communities.
Matter
of
fact,
the
last
version
had
some
major
changes
to
how
we
do
the
nvn
encoding
to
bring
it
up
to
date
with
the
way
the
ndn
protocols
have
gotten
partitioned
into
to
combined
protocols
and
a
little
while
ago
it
got
entered
as
an
RNG
draft.
B
So
it's
fairly
mature,
although
it
hasn't
been
an
RG
draft
for
a
whole
long
time,
but
we'd
like
to
progress
it
very
rapidly,
so
that
we
don't
hold
off
ping
and
trace
route
very
much.
So
our
plea
is
to
have
everybody
in
the
RG.
Please
look
at
the
current
draft
review.
It
send
comments.
B
We
would
very
much
like
to
last
call
this
soon
like
within
the
next
month
or
so,
and
get
that
done
before
the
holidays,
so
that
we
can
get
it
to
IR
ski
review
expeditiously
and
have
everything
wrapped
up
in
a
few
months.
So
thank
you
and
in
advance
for
your
help
on
on
moving
this
forward.
C
Yes,
thanks
so
I
mean
this
is
yeah
pretty
useful
and
but
also
cool
technology,
so
I
mean
past
steering
is
a
really
nice
feature
and
I
think
that
would
be
really
important
and
valuable
output
from
IC
energy.
C
All
right
with
that
I'd
like
to
hand
it
over
to
mark
for
his
presentation
on
flick
and
just
let
me
okay
bring
your
slice
up.
C
So
do
you
want
to
run
near
the
slides
yourself
Mark?
What's
the
best
way
for
you.
C
If
I,
but
I
can
do
I
can
I
can
bring
them
up
and
then
give
you
control
over
it
and
that's
maybe
the
best
way
sure
just
a
moment.
Sorry
I
didn't
realize
this
earlier.
E
Hey
look
at
that
clever
people
right
making
that
product
all
right.
So
this
is
the
flick
draft
for
file
like
ICM
Collections
and
the
active
authors
right
now
are
Dave
and
myself
and
Christian.
Shooting
and
Chris
Wood
have
also
contributed
quite
a
bit
in
the
past.
E
So
in
this
presentation,
I'm
gonna
talk
about
the
background
for
flick
and
review
some
of
the
history
and
then
I'm
going
to
walk
through
the
main
flick
features
that
are
in
the
04
draft
and
then
conclude
with
issues
that
we
know
about
for
the
04
draft
I'm
not
really
going
to
do
a
Delta
from
the
O3
I
could
talk
about
that.
E
If
someone
has
specific
questions,
but
I
decided,
it
was
better
just
to
go
over
what
is
flick
since
it's
been
quite
a
while,
since
we've
had
a
had
this
in
the
meeting.
E
So
the
the
history
so
flick
was
first
conceived
long
ago,
maybe
around
2014-ish.
You
know
that
time
frame,
2014
2016.,
the
first
draft
was
in
2017
and
we're
now
in
the
04
draft
in
2022..
E
The
the
content
of
flick
is
is,
is
that
it's
a
manifest
and
it's
meant
to
make
it
easier
to
use
hash
based
naming
which
can
be
used
for
you
know
one
within
CCN
we
called
nameless
objects
or
segmenting
large
objects
or
doing
collections
or
offloading
signatures.
So
there's
a
lot
of
very
useful
features
for
it.
It's
been
implemented
and
used.
You
know
in
several
of
the
CCN
iterations
before
So.
Currently
Dave
and
myself
are
the
main
authors.
Christian
has
contributed.
E
You
know
a
fair
bit
for
the
I
think
two
or
no
three
drafts
and
Chris
Wood
was
active
with
the
earlier
drafts.
The
04
draft
cleaned
up
a
lot
of
the
style.
Ken
Calvert
gave
us
a
lot
of
useful
feedback.
Hopefully
we'll
get
some
more
feedback
on
the
04,
so
we
can
tidy
it
up
for
the
final
o5
that
we
can
submit.
E
So
what
flick
does
is
it
provides
a
manifest
of
hashes,
so
you
can
retrieve
all
the
segments
of
a
piece
of
application
data
using
hash
based
naming
the
hash
is
higher
or
the
sorry
the
Manifest
is
hierarchical.
So
you
know
you
don't
have
to
fit
it
all
in
one
object
and
the
pointers
in
the
hash
can
point
to
either
more
manifests
or
to
application
data.
E
There
is
a
canonical
traversal
order
and
there
is
metadata
that
could
provide
other
traversal
hints,
such
as
for
video
flick,
has
its
own
encryption
mechanism,
I
mean
it's
using
standard
product,
you
know
protocols
and
all
that,
but
it
is
specified
how
you
would
encrypt
a
manifest.
E
There
are
also
several
interest
construction
techniques,
so
these
are
depending
upon
the
way
that
the
publisher
has
decided
to
create
the
application
data
that
is
referenced
by
the
Manifest.
There
might
be
different
ways
that
you
construct
the
full
name
to
put
in
an
interest
and
flick,
has
several
techniques,
and
we
could
add
more
techniques
later
on.
E
So,
as
a
manifest,
you
know,
using
hash
based
naming
is,
is
very
efficient
because
it's
an
exact
match
name
and
in
ccnx.
That's
also
very
important.
Since
you
know
everything
has
to
be
an
exact
match
name,
manifest
techniques
have
been
around
for
a
long
time
to
distribute
hashes.
So
this
is
a
the
current
you
know
hopefully
standardized
way
of
doing
it.
Manifest
can
also
offload
authentication,
because
you
only
need
to
sign
the
root
of
the
Manifest.
E
A
flick
manifest
has
one
or
more
hash
groups,
and
each
hash
group
can
have
its
own
naming
convention
and
its
own
metadata.
So
we'll
talk
about
those
name
Constructors
in
a
few
slides.
E
So
the
traversal
order
in
flick,
we've
defined
to
be
pre-order,
which
is
the
basic
top
down
left
right
style
of
traversing
a
tree.
A
consumer
of
course,
can
retrieve
the
pieces
in
any
order
that
they
want,
but
to
reconstruct
the
original
data
as
intended,
you
would
follow
the
traversal
order.
Some
applications
might
not
care
about
perfect
reassembly
and
they
might
use
metadata
or
other
hints
to
skip
around
the
content.
E
You
know
for,
for
example,
video
playback,
the
hash
pointers
can
point
to
other
manifests
or
application
data,
and
the
publisher
is
free
to
put
those
in
whatever
order
they
want.
So
you
could
do
all
manifest
first
and
more
data
data.
First,
then
more
manifest
you
could
intermix
them.
You
could
put
all
interior
nodes
having
only
manifests
and
leaf
nodes,
having
only
data
and
so
forth.
You
know
it's
entirely
up
to
the
publisher
how
they
do
that.
E
There
are
what
we
call
metadata
and
annotations,
so
metadata
generally
applies
to
Hash
groups
or
the
overall
manifest
content
object,
and
these
can
be
things
like
the
size
of
the
sub
tree
rooted
at
the
Manifest
or
the
size
of
the
sub
Tree.
In
a
hash
group.
The
amount
of
and
and
these
sizes
are,
the
application
data
underneath
there
not
counting
manifests.
You
can
have
digest
of
that
information.
E
You
could
have
sizes
for
the
immediate
Shield
application
data
Children
of
the
node,
there's
locators
for
routing
hints,
and
so
these
are
the
you
know
metadata
that
we
put
in
the
draft,
but
it's
entirely
extensible
by
more
tlv
tags.
Annotations
can
be
applied
to
individual
pointers
and
the
only
one
that
we've
put
in
the
draft
would
be
the
size
of
the
application
data
underneath
a
specific
pointer,
though
we
have
tossed
around
ideas
about.
You
know
video
hints,
but
those
are
not
in
the
draft.
E
And
these
are
the
definitions
of
the
things
that
I
just
said
so
I'll
skip
that
locators
and
name
Constructors.
So
a
locator
is
a
routing
hint.
So
in
ndn,
of
course,
they
have
a
you
know
an
explicit
routing
hints
for
interest
in
ccnx.
You
can,
if
you're
using
nameless
objects.
You
know
the
the
the
name
of
the
interest
is
essential
is
essentially
your
routing
hint,
so
these
can
be
used
by
both
protocols.
E
The
mechanism
differs,
but
the
publisher
or
someone
providing
the
content
can
provide
the
locators
to
use
in
the
interest.
Construction,
how
you
name
an
interest
and
all
the
other
flags
that
might
go
in
the
interest
can
be
part
of
what
we
call
a
name
Constructor.
So
the
Manifest
will
specify
the
scheme
that
that
a
consumer
should
use.
You
know
based
on
either
the
locators
or
other
names
and
we've
defined.
E
Four
of
those
that
are
I
didn't
go
to
the
details
of
those
here,
but
they
are
in
the
draft
yeah.
E
So
a
hash
group
is
the
collection
of
pointers
and
you
can,
as
I
said,
you
can
have
one
or
more
of
those.
So
an
example
of
why
you
might
want
more
than
one
would
be
if,
for
example,
child
manifests
are
under
one
namespace
and
application
data
is
an
under
another
name
space.
E
So
you
could
have
a
hash
group,
a
first
hash
group
for
the
child
manifest
and
a
second
hash
group
for
the
child
data
and
those
can
have
the
different
name
Constructors
you
know
and,
and
you
could
intermix
these
or
interleave
them.
However,
you
want
there
is
a
default
name
Constructor.
So
if
you
don't
specify
anything,
there
is
a
default.
E
Behavior,
locators
and
name
Constructors
are
inherited,
so
one
could
only
Define
them
in
the
root
of
the
Manifest
tree
and
then,
as
you
Traverse
the
tree,
you
would
just
keep
reusing
the
same
values
as
you
go.
E
E
E
One
is
a
pre-shared
key,
where
there's
only
a
key
ID
and
a
nonce
in
the
manifest
content,
object
or
there's
a
wrapped
key
technique,
and
it
is
you
know,
extensible
you
can
Define
more
and
hopefully
we
will
get
more
than
those
two
for
pre-shared
Keys,
there's
just
the
key
ID
and
it's
assumed
that
you've
either
done
out
of
band
or
key
exchange
protocol
to
know
about
those
key
IDs.
We
use
unauthenticated
encryption,
authenticated
data
mechanism
with
AES
encryption,
I'll
just
be
a
very
standard
stuff.
E
For
the
wrap
key
approach
you
know
the
the
intention
is
that
this
is
wrapping
the
AES
key,
that's
being
used
by
the
pre-shared
key
mechanism
to
encrypt
the
Manifest.
So
you
don't
have
to
have
a
key
exchange
protocol
and
there
is
a
you
know,
then
just
the
kind
of
standard
you
know
for
ICN,
there's
a
key
ID,
the
wrapped
key
and
a
key
locator
for
the
key
ID.
E
If
you
wanted
to
fetch
it
instead
of
having
it
wrapped
in
the
manifest
it
uses,
RSA,
oaap
and
future
extensions
could
be,
for
you
know,
full
key
encryption
data
encryption
mechanism
or
for
using
elliptic
curve.
E
So
we've
we've
defined
this
to
be
usable
by
ndn
or
ccnx.
So
really
flick
is,
is
a
grammar
and
a
structure
and
and
and
and
a
set
of
you
know,
techniques
for
using
the
Manifest,
but
they
would
be
natively
encoded
in
either
ccnx
or
ndn
We've
provided
encodings
for
both
of
those.
So
hopefully
you
know
the
the
ideas
of
this
can
become
standardized
and
you
would
have.
Hopefully,
even
you
know,
a
standard
library
implementations
for
it
between
the
two
protocols.
E
Foreign,
so
in
the
draft
we
also
talk
about
our
Root
versus
a
root
plus
top
manifest.
So
this
is
so
the
the
the
root
manifest
approach
is
is
basically
as
simple
as
it
sounds
right.
You
have
the
top
level
manifest
where
you
have
your
signature,
you
might
have
your
name
locate
and
your
name
Constructors
and
locators
there,
and
then
the
rest
of
the
Manifest
is
just
normal
stuff.
E
Another
technique
that
we've
described
as
having
a
root
plus
a
top,
so
you
would
generate
your
content
manifest
you
know
as
normal
and
you
have
the
root
or
the
top
level
manifest
of
that
structure,
and
then
you
glue
on
a
root
manifest
on
top
of
that.
So
this
means
that
if
you
want
to
be
changing
your
locators
or
your
signature
or
other
things,
name
Constructors
that
are
in
the
Manifest
you're,
just
swapping
out
the
root
and
all
the
rest
of
the
Manifest
stays
the
same.
E
All
these
hashes
are
the
same
alvet
you
know
about
pushing
out
to
caches,
and
so
forth
is
all
the
same.
So
that's
that's
the
intention
between
having
a
root
plus
top
versus
just
a
plain
root.
Again.
This
is
entirely
up
to
the
publisher
what
they
want
to
do
about
it
and
they
could
even
use
some
other
technique
that
you
described
in
the
draft
and
so
still
to
be
done.
We
have
some
python
prototype
code,
that's
really
just
about
building
the
the
manifests
and
the
trees.
E
It's
not
really
a
protocol
implementation,
but
that
prototype
is
behind
the
draft.
So
we
need
to
bring
that
up
to
the
draft.
Flick
actually
supports
acyclic
digraphs,
not
just
trees,
so
we
should
have
an
example
of
that.
The
the
kind
of
standard
example
of
that
is,
you
have
a
deduplication,
so
maybe
you
have
one
content
object,
that's
like
all
zeros
and
you
could
refer
to
that
content
object
from
multiple
places
in
your
tree.
You
know,
if
that's
a
common
content
object
for
your
encoding.
E
The
next
two
are
are
really
around
the
nonce
and
salt
and
and
kind
of
the
some
of
the
differences
between
the
RFC
descriptions
of
those
in
the
nist
description.
So
this
is
more
so
just
a
note
that
we
need
to
make
sure
that
how
we
describe
these
things
is
is
clear.
Given
the
standards-
and
there
were,
there
were
some
usages
of
the
nonce,
where
we
weren't
exactly
clear
about
how
the
salt
and
the
explicit
knots
get
used.
So
we
will
clarify
those
in
the
o4
draft.
E
We
might
also
want
to
consider
using
a
kdf
to
ensure
that
there's
no
repeated
nonses
between
manifest
nodes
or
entire
manifest
trees
of
the
same
keys
are
used,
and
so
that
will
be
put
into
the
o4
draft.
We
have
the
Ina
consideration
section
to
go
over.
They
did
send
some
feedback
on
the
draft,
so
we
need
to
review
that
and
incorporate
it
in
on
into
o5.
E
Of
course,
security
considerations
needs
to
be
worked
out
more,
especially
since
we
are
talking
about
having
a
specific
encryption
protocol
in
in
this
draft,
and
the
ndn
section
I'm
sure
is
stale,
because
it's
it's,
you
know
three
or
four
years
old,
so
that
needs
to
be
touched
up
for
recent
nvn
changes
and
I
suspect.
That
is
the
end
of
the
presentation.
C
C
Solid
piece
of
work,
lots
of
effort
went
into
it
and,
at
the
same
time,
it's
also
a
very
important
mechanism
right,
any
ICN
application.
Any
system
that
wants
to
share
larger
objects,
probably
use
something
like
manifests
and,
and
so
it's
kind
of
like
a
key
part
of
the
system,
and
we
really
want
to
publish
this
soon.
D
Chrome
and
I
are
disagreeing
about
whether
I
gave
permission
for
my
camera
so
but
I
will
go
through
and
and
review
the
04
draft.
Thank
you
for
the
updates
and
I
just
wanted
to
say:
I
have
a
student
who's
working
on
trying
to
implement
it
from
the
04
draft
for
in
the
end,
so
we
may
have
some
feedback
for
you
on
the
ndn
section.
D
He
has
had
some
personal
challenges
this
semester,
so
we
didn't
make
as
much
progress
as
we
wanted,
but
I'm
hoping
we
can
get
to
that
early
next
year,
but
anyway,
I
will
try
to
get
feedback
before
the
end
of
this
year.
For
sure.
E
Okay,
that
that's
excellent
and-
and
you
can
have
the
student
contact
me
directly
and
I'm-
you
know
very
happy
to
help
them
along
as
best
I
can
great
and
the
they're
I'm
trying
to
remember
whether
I
sent
the
email
to
the
mailing
list
or
just
just
to
the
other
co-authors.
But
you
know
there
is
kind
of
a
bullet
list
of
of
updates.
That
I
know
needs
to
be
made.
E
So
you
know
if
the
student
has
any
questions
about.
You
know
the
encryption
in
particular
or
other
things.
You
know
reach
out
to
me
rather
than
spin
your
wheels,
because
there
might
have
just
been
no
mission
in
in
the
04.
E
Well
there
there
there
was
an
implementation
in
in
einc
of
an
early
flick
version,
maybe
like
or
or
something
like
that,
but
I'm,
not
sure
of
the
status
of
that
knowledge.
Okay,.
C
So
I
actually
have
an
implementation
myself.
That
is
I,
think
maybe
on
the
same
level
as
the
python
prototype.
If
anyone
is
interested
or
has
a
student
who
likes
to
program
some
closure,
so
this,
let
me
know
I'm
happy
to
hand
over
this
implementation.
I.
Currently
don't
have
time.
For
that.
C
All
right,
yeah
anything
else,
any
other
question.
C
C
For
giving
us
the
update,
let's
move
on
so
next
we
have
Jen's
finco
is
on
the
agenda.
C
And
so
how
are
we
going
to
do
this
now
with
this
life,
you.
C
A
G
C
All
right,
yeah,
so
yeah,
maybe
you
can
introduce
your
work
yourself.
I,
don't
need
to
do
this.
You.
A
Have
to
yeah
thank
you.
Could
you
could
you
skip
already
to
the
next
slide
sure
sure,
thanks
yeah,
okay,
so
I
I
mean
twinkle
as
I
run,
a
very,
very
tiny
r
d
company.
You
know
non-profit
actually
in
internet
technology
right.
So
this
is
a
building
block
container
format.
I,
don't
need
to
tell
you
too
much
about
the
purpose
there.
It's
work
done
under
ngi0,
which
is
managed
by
an
element,
foundation
and
I,
guess:
I
guess.
A
The
reason
I'm
I'm
talking
here
is
because
I'm
taking
a
very
different
approach
from
a
manifest
and
when
I
started
out.
Actually
the
approach
was
to
use
a
manifest
and
all
that
kind
of
thing,
but
then
I
did
some
parallel
work
for
the
iso
foundation
and
that
sort
of
influenced
the
design
a
little
bit
so
I
mentioned
them
here
as
well
that
they
did
not
actually
pay
for
this
work.
A
Thank
you.
Can
you
go
to
the
next
slide?
Okay,
so
I
have
very
different
goals.
My
background
is
not
on
the
slide,
but
I
want
to
tell
you
there's
anyway.
My
background
is
in
in
peer-to-peer
video
streaming.
So
video
is
a
very,
very
high
use,
Case
High
high
priority
use
case
for
me,
which
means
I
wanted
to
make
it
streaming
friendly,
also
to
include
the
ability
to
Multiplex
different
different
content
types
into
the
same
resource.
A
A
I
wanted
to
support
offline
first
usages,
not
everywhere
in
the
world,
has
connectivity
I,
don't
know
if
you've
been
to
the
tube
here
when
I
was
last
using
it
this
little
while
ago
there
was,
it
was
just
a
black
hole
and
you
know
you
might
want
to
do
some
work
on
something
and
then
come
back
out
of
the
tube
again,
and
it
actually
merges
with
what
you
with
what
you
had
before
another
use
case
that
I
have
in
mind
is
collaborative
editing.
Some
having
multiple
authors
do
the
same
resource.
A
You
can
solve
this
in
a
container
format.
You
need
something
like,
for
example,
a
crdt,
which
was
something
we're
also
working
on,
but
the
container
for
Tacoma
can
help
with
this
a
little
bit
and
that's
what
we've
tried
to
aim
here,
for
it
should
be
end-to-end
encrypted
by
default.
Yesterday,
I
was
speaking
at
dinner
G.
Why
I
thought
that
was
my
important
other
than
the
obvious
privacy
and
security
concerns,
but
yeah
that
that
was
an
important
part
from
me
where
I've
seen
some
proposals
say
well.
A
Basically,
encryption
is
more
of
an
application
concern.
So
that's
from
my
point
of
view-
and
a
very
European
thing,
I
suppose
is-
is
the
gdpr
we
have
this.
This
derived
right
to
be
forgotten,
which
means
content.
Deletion
was
a
very
important
use
case
for
me,
which
is
not
something
I
see
most
of
the
time,
and
that
leads
to
a
very
different
design.
A
Next
slide,
please,
yes,
so
yeah
we're
we're
right.
I
read
through
I
was
I,
wasn't
really
aware
of
the
details
of
ICN
before
you
know,
before
a
couple
of
weeks
ago,
I
I
read
through
the
RFC
7927,
was
concerned
with
name
data
objects.
In
our
case,
an
object
name
is
I,
as
I
interpret
the
ROC
right.
An
object
name
is
not
just
a
hash
there's
something
else
to
it.
I'll
go
into
details
later
vessel
does
provide
data
original
authentication.
As
per
section
4.1.
A
We
have
a
powerful
solution.
It
needs
more
work
for
Distributing,
public,
key
information
or
key
information
in
general,
so
that
also
we
can
deal
with
with
that
part
and
other
sections
there.
For
for
what
is
it,
yeah,
encryption
and
and
what
was
the
other
doesn't
matter?
You
know,
you
know,
you
know
this
document
better
than
I.
Do
next
slide,
please,
okay,
so
alternative
approaches,
so
you
this
is
just
telling
you
what
you
already
know.
A
A
A
So
my
problem
with
manifest
is,
is
I,
have
a
couple
of
problems
with
manifests
from
the
gdpr
and
rightly
forgotten
perspective
in
a
manifest
in
order
to
delete
something
with
a
manifest
approach.
You
just
do
not
reference
this
anymore,
that's
not
quite
the
same
as
deleting
it.
It
could
still
exist
everywhere
in
the
network
and
it's
still
retrievable
with
an
old
manifest.
Basically,
I
wanted
to
have
something
slightly
more
robust.
I
know,
I
can't
guarantee
anything,
but
I
can
try
to
to
be
a
bit
more
robust
than
that.
A
The
streaming
problem
that
I,
see
everywhere
with
manifest,
is
that
you
have
to
have
real-time
updates
to
the
manifests,
as
as
your
resource
grows
streaming,
maybe
disambiguate
this
a
little
bit,
so
you
can
stream
an
existing
resource
right
or
you
can
live
stream,
something
like
a
broadcast
video
and
it's
more.
The
second
kind
of
situation
that
I'm
concerned
with
and
most
of
the
Manifest
approaches
the
completely
consistent
finding
themselves.
A
When
you
have
multiple
authors
and
you
sign
your
manifest,
somehow
becomes
the
question:
who
does
the
signing
and
at
what
point
I
find
that
a
little
bit
unsolved
there,
usually
there's
just
no
support
for
this,
which
is
also
okay
right.
It's
just
not
not
what
I
needed
to
to
go
towards
and
when
you
do
have
multiple
authors,
you.
You
also
have
this.
A
This
problem
that
you
can
create
conflicting
manifests
that
are
equivalent
equally
valid
for
a
given
time,
Point
and
then,
when,
when
node
starts
synchronizing,
then
you
have
to
have
the
mechanism
for
merging
this,
and
that's
probably
it's
a
new
manifest
which
again
has
to
be
synchronized.
So
I
see
I,
see
problems
coming
out
of
the
Manifest
approach.
A
When
you
have
multiple
authors
as
well
as
streaming
as
well
as
deletion
next
slide,
please
so
I
tried
to
get
rid
of
the
Manifest.
Basically,
and
the
approach
is:
is
it's
not
particularly
magical,
it's
just
very
similar
to
something
like
git
dust
or
even
a
blockchain,
without
proof
kind
of
thing,
I,
just
oh
yeah.
By
the
way
these
these
content,
Parts
I'm,
calling
them
extends
from
file
systems.
A
The
first
one
in
a
in
a
resource
has
a
random
identifier,
excuse
me
and
then
I
just
create
every
subsequent
identifier
as
a
hash
of
the
parents.
Parents
extend
identifier
and
the
author
identifier,
and
you
have
a
verifiable
and
deterministic
and
also
conflict-free
way
of
of
just
allowing
multiple
authors
to
to
create
extents
in
parallel.
The
problem
is
that
this
Con,
if
you
just
don't
give
a
mechanism
for
choosing
the
best
the
ideal
parent,
then
you
create
a
then
you
end
up
with
a
tree.
A
That's
that's
that
can
be
very,
very,
very
wide
comes
harder
to
merge
into
some
consistent
State
later
on
so
I
added
section
on
choosing
the
ideal
parent
identifier,
which
is
based
on
the
the
leaf
node
with
the
longest
or
most
linear
path.
I,
don't
know
how
to
better
explain,
explain
this
other
than
in
the
next
slide
yeah.
So
here
I
have.
This
is
from
from
my
my
pre-draft.
A
If
you
want
I
haven't
submitted
it,
so
I
haven't
created
an
ID,
yet
as
an
example,
expanded
tree
that
might
come
out
of
this,
each
each
sibling
is
basically
must
be
created
by
a
different
author.
Under
the
scheme
right,
so
you
have
at
minimum
three
different
authors
in
this
year
and
if
you
look
at
the
longest
Parts
well
visually
speaking,
it's
going
to
be
one
of
the
one
of
it's
not
going
to
be
the
one
that
goes
through
through
node
B
B1
at
the
top.
A
A
So,
basically,
it's
really
simple:
I
mean
I'm,
just
taking
the
the
weight
of
the
edge
between
two
nodes
as
the
as
one
divided
by
the
number
of
siblings,
I
I,
add
all
the
the
individual
segments
into
a
pathway
and
that
that
gives
us
a
result
by
the
way.
There's
a
small
mistake
here
in
the
in
the
table
that
I've
fixed
in
the
documents,
but
not
here
yet
in
line
six,
you
have
a
b2d
and
then
in
line
seven,
it's
ab1d
that
should
be
B2
and
then
nine
eight
the
same
thing.
A
And
then
you
end
up
having
two
equally
weighted
paths
and
then
there's
a
simple
tiebreaker
bitwise
ordering
really
very
simple
between
the
the
last
extent,
identifier
and
that
shows
F2
next
slide.
A
So
extends
must
be
signed,
but
the
encryption
is
is
optional.
You
either
have
a
signature,
a
public
key
signature
when
there's
no
encryption
or
aad
when
when
it's
also
encrypted,
as
this
RFC
says,
there's
a
key
distribution
challenge
here,
the
way
I'm
hoping
to
solve
this-
it's
not
quite
there.
Is
that
because
I
also
have
this
multiplexing
feature
here,
we
can
do
some
key
distribution,
also
just
multiplexed
into
the
same
resource.
A
Next
slide.
Please.
A
So
Multiplex
means
that
that
the
content
isn't
just
binary
data
at
all.
It's
it's
data
sections.
Now
there
is,
of
course,
a
Blog
section
for
binary
data,
but
that's
just
one
of
of
of
a
few
having
this
section
also
makes
the
the
format
very
extensible
to
other
use
cases.
A
The
sector
has
a
type
self-explanatory
and
the
topic,
the
topic
is
more
of
a
context
in
which
to
interpret
this.
This
also
creates
resource
substreams.
If
you
want
so
you
can
have
a
topic.
That's
dedicated
to
to
your
video
content,
a
topic
that
syndicates
to
your
German
language,
audio
and
so
forth,
and
you
can
have
a
topic
for
future
play.
Of
course,
that's
not
in
my
draft
right
now.
A
I
have
some
thoughts
on
how
to
do
this,
but
I've
just
reserved
the
topic
slot
for
that's
in
this
draft,
and
you
have
a
content
type
section
which
works
very
much
like
in
HTTP.
You
define
the
type
of
The
Blob.
This
is
that's
that
might
follow
in
this
in
the
same
topic,
next
slide,
please
all
right,
editing
and
deleting
with
this
scheme,
you
can't
really
rearrange
the
tree
right,
that's
not
possible!
A
It's!
This
there's
a
permanent
order
to
to
the
extents.
So
this
whole
idea
of
just
forgetting
about
one
is
not
going
to
be
be
viable,
which
is
on
purpose.
So
every
extent
also
has
a
kind
of
version.
I
quote
the
version
thing
here,
because
in
in
the
document,
actually
there
I
use
version
for
two
different
things
already,
so
I
didn't
want
to
introduce
a
third
one.
A
It's
it's
a
sculpt
counter,
sculpt
to
the
author,
that
the
author
increments,
whenever
they
create
a
modify
an
extent,
and
that
means
that
actually,
if
you,
if
you
want
to
be
precise,
the
the
object
name
is
talked
to
pull
off
the
extent
identifier
and
counter,
because
that
gives
you
the
specific
version
of
the
extent.
A
And
if
you
have
that
kind
of
scheme,
then
you
can
start
updating
your
your
extend
with
empty
and
empty
content
right.
So
erasing
is
just
deleting
the
content
section
overwriting
the
content
sections,
but
keeping
the
extend
identifier
intact,
and
they
can
resign
it
and
update
it
next
slide,
please
that
has
an
effect
because
with
the
Manifest
approach,
if
you
forget
about,
if
you
exclude
a
block
from
from
your
manifest,
if
you
forget
about
this,
you
can,
of
course
out
of
band
notify
caches
that
this
is
no
longer
relevant.
A
It
should
be
deleted,
but
it's
very
easy
for
cache
to
just
ignore
this
I
mean
it's
it's
easier
to
not
add
functionality
than
to
have
it
right.
That's
why
this
is
actually
a
bit
fragile
for
my
taste,
whereas
if
you
have
end
to
end
encrypted
extends
and
deleting
is
nothing
but
overwriting
the
content,
then
a
cache
cannot
really
distinguish
between
an
editing,
a
deletion,
and
that
should
make
it
more
likely
that
they
accept
the
deletion
as
a
valid
operation
that
they
want
to
support,
because
they
don't
know
about
it.
A
Of
course,
it's
still
possible
to
find
ways
around
this.
You
know
Cache
can
keep
all
versions
of
an
extend,
but
that
incurs
in
cost
and
I
hope
that
that
helps
get
these
things.
Actually
deleted
next
slide,
please
so
from
the
collaborative
editing
point
of
view,
which
is
where
we
we
sort
of
start
or
one
of
the
angles
for
which
we
started.
The
container
format
doesn't
actually
solve
that
much,
but
at
least
it
does
a
couple
of
things
in
the
single
author
use
case,
you
don't
even
have
a
tree.
A
You
just
have
a
single
linear
list
of
of
of
extends
and
you
don't
have
to
update
the
Manifest,
so
you
have
a
slightly
improved
stream
friendliness
there
in
in
this.
In
the
multi-auto
use
case,
because
of
the
ordering
scheme
I
explained
earlier,
you
have
partial
ordering.
A
What
you
can't
guarantee
is
that,
within
a
group
of
siblings,
what
the
precise
order
of
sections
should
be,
but
you
can
guarantee
that
all
descendants
of
a
particular
extent
come
after
the
parent
and
that
can
also
already
already
help
with
with
ordering
things
like
crdt
operations
and
other
than
excuse
me
other
than
then
that
I
I
really
do
think
that
that
something
like
end-to-end
encryption
and
the
ability
to
embed
AAA
content
is
is
very
fundamental
to
how
we
want
to
shift
data
around
in
the
world
and
so
I
I
really
think
it
should
be
in
a
sort
of
an
infrastructure
thing
that
when
the
upper
layers
like
this
here,
the
T
or
whatever
you're
going
to
use
there
Can
can
then
use
next
slide.
A
A
Next
type
is
right,
so
what
we
also
have
is
nothing
to
do
with
this
is
is
something
called
Caprock?
It's
capability-based
system
with
cryptography.
Yesterday
in
energy,
we
had
a
talk
about
power
of
attorney.
I
I
urge
you
to
look
at
that,
because
the
approach
is
almost
exactly
the
same.
A
Just
independently
done,
that's
something
we
worked
on
under
the
iso
Foundation
Grant
and
really
the
the
work
that
needs
to
be
done
as
well,
but
that's
a
separate
sort
of
document
as
to
her
to
specify
how
we
can
put
these
tokens
into
AAA
sections
investors,
so
that
comes
part
of
the
authorization
scheme.
Let's
put
it
that
way
that
we
can
send
authorization
information
along
with
the
data
we
might
I,
don't
know
yet
exactly
also
provide
key
exchange
in
either
cap
rock
or
an
additional
AAA
sections
investor.
A
C
Some
oh
yeah
yeah.
H
Hi
hi,
my
name,
is
real
I
am
at
the
University
of
Glasgow.
Thank
you
for
interesting
talk,
so
the
scope
I'm
just
trying
to
double
check
that
my
understanding
is.
G
H
A
I
mean
what
we're
doing
is
we're
building
our
our
own
software
stack.
That
reads
very
close
to
an
ICN
type
solution
right,
and
it's
really
for
that,
but
it
has
the
potential
of
having
having
other
users.
Of
course,
no,
so.
H
H
So
so
I
know
that
you
don't
guarantee
that
right
to
forget
and
forgotten
is
actually
you
know
enforced,
but
yeah
I,
I
I,
don't
know
how
you
you
approach
this
sort
of
I
couldn't
fully
understand
how
you
would
want
to
approach
the
have
the
right
to
forgotten
and
the
offline
kind
of
well
offline.
First
kind
of
use.
Do
you?
Could
you
maybe
elaborate
a
little
bit
about
that,
so
that
I
can
get
my
head
or
not
yeah.
A
What
they're
sort
of
they're
sort
of
unconnected
in
a
sense
right,
but
when,
when
they
do
connect,
it
becomes
interesting,
you're
right
about
that
so
offline
first,
is
simply
the
the
notion
that
I
I
in
our
system.
We
don't
want
to
have
constant
connectivity
as
as
a
requirement
right.
So
that's
that's!
That's
really
it
because
we
have
locations
in
the
world
where
there
is
no
connectivity.
A
A
The
cash
to
delete
content
is
very
difficult
because
you
don't
know
which
caches
are
involved
and,
and
it's
sort
of
impossible
to
know
right
so
yeah
you
can
start
sending
hints
out,
maybe
in
a
different
protocol,
but
that
seemed
more
complicated
to
me
than
saying
well
actually,
deletion
and
overwriting
with
zero
bytes.
A
You
know
it's
kind
of
the
same
and
if
we
hide
the
fact
that
it
might
be
a
different
operation
from
the
caches
and
they're
just
more
likely
to
go
along
with
it.
That's
that's
really.
The
whole
thing
there
past
that
I
can't
guarantee
anything
so.
B
All
right,
yeah,
my
questions
in
the
same
vein,
doesn't
necessity
of
Fool's
Aaron
to
try
and
delete
data
in
a
large-scale
distributed
system.
I
mean
this
like
every
bit.
That's
ever
been
sent
over
a
wire
was
stored
somewhere,
so
yeah.
So
I
I
really
don't
understand
the
idea
that
you
tried
to
delete
things
from
caches.
The
caches
won't
have
the
encryption
keys
anyway,.
A
A
well-behaving
cache
is
not
a
problem,
it's
always
a
malicious
cash.
That's.
B
A
That
that
is,
that
is,
that
is
the
hopeful
version.
Yes,
I
mean
I
I
agree
as
long
as
the
cryptography
holds
you're
right
at
that
point.
We
don't
need
it,
but.
B
If
the
cryptography
doesn't
hold,
none
of
none
of
stuff
works
anyway,
true
true,
okay,
one
other,
it
seems
to
be
working
towards
some
of
the
same
goals
you
do.
Is
a
system
called
secure,
scuttlebutt,
I.
B
Yeah,
it
seems
to
have
this
distribution
properties.
Is
your
system?
That's
why
you
know
partial
ordering
single
Source
chain
data.
C
Okay,
okay,
other
questions,
yeah.
Thank
you
very
much,
Jens,
of
course,
so
yeah.
We
do
this
from
time
to
time
say
having
presentations
and
say
in
the
broader
context
of
if,
if
you
like,
information,
Centric
systems-
and
it's
also
sometimes
quite
interesting
to
you-
know-
understand
their
particular
constraints
and
as
yeah
we
just
mentioned
scuttled,
but
we
discussed
earlier.
C
So
let's
keep
doing
this.
But
now
we
come
back
to
say
a
core
ICN
topic
again
and
we
have
talking
about
ICN
as
a
service
using
the
C4
implementation,
and
let
me
bring
this
up.
F
Hi,
thank
you
for
introduction
is
from
NSD
Japan
today,
I'll
talk
about
CFO
ccnx
based
Cloud
native
that
talk
functions
for
deploying
the
ICN
as
a
services,
so
is
the
next
starfish.
F
F
The
concept
is
changing
an
end
of
our
network
from
the
host
Centric
to
the
content
Centric,
and
the
icing
is
a
country
forked
to
the
several
Concrete
Network
objectives,
ccnx
as
specified
in
the
iot
overseas
and
the
ndn
name,
data
networking
by
the
NDA
project,
and
actually
we
and
ICT
are
developing
the
servo,
which
is
combined
with
the
ccnx
1.0.
And
so
what
is
an
open
source
software
platform
and
enabling
a
ccnx
based
Communications
and
yeah
and
the
the
software
there's.
F
A
lot
of
the
research
is
about
the
routing
and
farting,
and
the
caching
and
now
security
has
been
proposed
by
the
some
several
many
research
communities
of
an
ICN.
But
the
one
missing
a
piece
might
be
a
development
Solutions
of
the
icing
modules
into
the
existing
internet
infrastructures.
F
So
next,
please
so
in
my
presentation.
First
I
will
introduced
the
Sephora,
which
is
open
source
software
platform
for
enabling.
F
Specs
Communications
and
also
therapico,
which
is
a
application
development
on
tools,
and
then
we
try
to
integrate
the
CFO
with
a
Docker
platform
and
for
easy
and
love
it.
The
deployment
of
the
ice
and
so
we'd
like
to
introduce
a
method
for
easily
deployment
icing
as
a
micro
services
and
a
quick,
quick,
constructing
the
icnbs
networks.
F
So
next
step,
please
so
now
I
introduce
say
for
ccnx
based
extensible
pocket,
one
NG
and
the
server
Pico.
So
next,
please
so
therefore
stands
for
the
yeah
I
see
it's
going
to
base
the
X
and
pocket
Warrior
engine
and
which
is
compared
to
visual
system
is
1.0
and
sorry.
F
Okay.
Thank
you.
Next.
Sorry,
please
so
simple
sets
us
throwing
a
free
design
policies,
find
the
right
weight
and
usability
and
extensibility.
So
most
important
thing
is
a
lightweight
implementation,
so
the
software's
platform
should
be
usable
for
the
resource
concerned
devices
such
as
a
sensor
node
and
also
depending
on
the
situations
or
network
requirements.
We
need
to
extend
it,
so
the
platform
should
be
easily
extensible
to
the
accommodated
novel
functions
to
the
satisfy
the
future
network
needs.
So
next,
please.
F
F
D
is
a
caching
engine
so,
depending
on
the
situations
for
in
the
case
that
you
require
the
high
Network
networking
performance,
we
need
you
need
to
prepare
some
high-end
machines,
such
as
the
routers
and
enable
the
second
D
and
the
Cs
manager
D,
and
there
is
some
various
programs,
so
you
can
deploy
the
full
icing
stack
node,
but
but
you
require
the
lightweight
implementation,
such
as
a
plus
value
by
implementations.
You
just
enable
the
second
ID
with
some
minimum
programming,
so
researchers
can
install
necessary
eyes.
E
F
Functions
depending
on
the
situations
under
their
requirements,
machine
requirements
for
considering
the
there
was
in
resource
course
right.
So
next,
please
next
slide.
Please
so.
F
With
the
extensive
Province
and
consumer
product,
our
consumer
utilities
and
the
producer
utilities,
and
also
we
provide
a
network
management
tools,
CCN
info,
so
this
is
for
our
own
package.
So
you
exercise
please.
F
Is
a
simple
person
compact
package
and
which
is
open
in
the
following
URL
so
and
the
same
Pico
is
a
python-based
wrapper
program
that
helps
development
systems,
X
applications
so
and
it
can
enable
easy
coding
of
the
Python
program
as
compared
to
the
original
C
language.
For
example,
you
want
to
send
the
interest
packet.
You
need
to
write
the
33
lines
in
C
language
answer
in
the
left
figure,
but
we're
using
a
server
Pico.
F
F
So
next
slide
is
no
now
I
enter
the
main
top
and
Docker
Integrations.
So
what
is
a
doc
aziro?
The
docker
is
very
famous
platform
for
computer-based
virtualization
Technologies
for
the
quick
and
the
scalable
Network
Services,
so
there's
some
features
and
benefits
lightweight
and
performance
and
scalability.
So
the
most
important
point
is
local
doesn't
have
the
OS,
so
it
is
very
lightweight
and
you
can
enrich
the
evaluations
over
the
scenarios
and
you
can
facilitate
the
Comfort
double
test
of
the
develop.
The
ICN
services,
and
also
scalability
also
so
next
side,
Breeze.
F
So
this
is
just
a
simple
example:
scenarios
with
a
several
Docker
based
networking.
So
in
this
scenarios
a
consumer
download
a
file
from
the
producer,
the
producer
responds
to
that
they
are
request
and
the
send
back
the
data
and
the
resistor
X
router
the
course
definitely
stores
relationship
data
into
the
Cs.
F
So
such
as
a
CS
manager
ID,
so
this
is
a
very
simple
scenarios
so
next
time
please,
this
is
a
how
to
lighting
a
Docker
file
so,
but
I'll
show
skip
my
details
of
the
this.
How
just
interesting
is
we
use
a
we
Define,
the
three
services
one
is
the
base
Services,
which
is
a
base
functions
as
I,
say,
node
and
the
next
slide.
Please,
and
then
we
use
a
minimum
function
serving
as
a
ICM
node.
F
That
is
installation
in
the
application,
vibrations,
Next
Step,
please,
and
also
the
we
need
a
cache
services.
So
you
can
Define
the
sketch
Services
as
following
the
docker
file,
so
we
totally
use
a
free
this,
so
we
type
over
the
talker
file
and
there's
three
types
of
microsources
so
like
so
please,
and
also
we
leverage
the
docker
compose
tools
which
is
very
useful
for
defending
defining
and
learning
and
multiple
contains
local
applications.
F
So
it's
very
easy
configurations
we're
using
a
yamra
style
file,
as
shown
in
the
light
figure
and
it
can
create
the
and
starts
the
or
the
services
from
the
configuration
with
a
single
command.
So,
in
my
experience,
it
is
very
easy
to
conduct
a
scenario
based
evaluations
such
as
immigrations,
unlike
metal
oxidations
such
as
nl3,
so
the
answer
in
the
right
figure.
So
in
this
example,
we
Define
the
producer
services
and
my
router
services
and
consumer
services,
and
each
service
are
built
from
the
cache
or
the
minimum
images.
F
So
this
is
a
video
streaming
use
case
is
over
the
internet
and
we
in
the
city
had
the
icing
summer
workshop
last
year,
which
is
headed
in
the
fully
online
Style,
and
we
demonstrated
the
Marcus
video
streaming
using
a
simple
Docker
platforms
and
in
this
demonstration
the
producer
is
located
at
the
nicth
Tokyo
and
the
consumers
are
around
in
Japan
and
let's
see
with
the
video
streaming
from
their
home
or
schools
or
companies.
F
So
what
is
important
here
is
the
old
purchase.
Participants
are
including
the
beginners,
such
as
a
larger
students,
can
construct
icna
node
on
their
laptop
and
they
can
receive
the
video
stream
successfully.
So
this
is
very
I
think
this
is
very
comfortable
based
ICN
networking
is
very
comfortable
and
useful
for
the
special
beginners
and
which
is
very
kind
and
yeah
comfortable
for
IC
network
over
the
internet.
F
So
next
slide
please
yeah.
This
is
a
my
conclusion.
So
in
a
future
we
are
now
passing
a
possibility
of
a
collaboration
with
the
emerging
orchestration
technology
such
as
kubernetes,
and
we
believe
that
this
as
a
whole
Docker
based
networking,
can
be
a
one
possible
options
for
the
easily
constructing
the
as
a
networks
over
the
existing
internet
infrastructures.
C
Okay,
thank
you
very
much.
Do
we
have
questions.
H
Hi.
Thank
you
very
much
for
interesting
talk.
My
name
is
Rio
from
University
of
Glasgow,
so
you
mentioned
using
this
on
a
sensor
node.
What
kind
of
sensor
node
have
you
looked
into
running
it
on
a
real
Hardware?
Have
you
tried
it
so
far,
I
I'm
just
curious
about
sort
of
using
Docker
based
system
on
the
sensor.
Node
I,
don't
know
what
kind
of
like
power
you
like
scale.
You
were
talking
about
so
I
just.
F
Wow
so
I
introduced
a
simple
is
running
on
the
doc
sensor.
Node
such
as
a
Raspberry
Pi,
but
I
never
I'll
try
to
do
the
integration
in
the
sensor,
but
it
can
be
used
on
the
the
act
because
several
says
Raspberry
Pi
is
a
very
what
should
I
say.
H
F
Capable
yeah
Constructors
very
lightweight,
so
it
can
be
easily
act
so.
H
H
Said
you
said
only
one
package,
then
you
also
said
that
the
the
you
can
have
subset
of
it
to
make
it
more
lightweight
to
adapt
to
more
less
powerful
devices.
Are
these
all
Impact
only
one,
as
in
like
the
there's
one
binary
that
contains
everything
and
you
switch
it
on
and
off,
or
you
have
like
a
lightweight
binary
that
you
create
for
the
cases
of
using
on
a
low
storage
device?
Is
it
the
fomo
or
the
latter.
H
F
H
F
Oh,
no,
no
just
I'm!
Sorry,
though,
later
on
this
right,
so
for
building
the
support,
that's
a
could
you
back
to
the
docker
fire
constructions?
That's.
G
F
So
when
building
this
C4
previous
one,
please.
F
Yeah,
so,
as
you
can
see
they,
when
configuring
the
server
and
the
building
is
whole,
we
can
configure
What.
We
want
to
use
the
other
options
enabling
the
cache
functional,
HDs
manager
functions,
so
you
don't
have
to
or
building
all
the
binaries.
So.
E
G
F
Such
as
a
HTTP
or
some
other
serving
applications,
so
in
there
thank
you
for
your
question,
so
I
mean
ICN.
The
Lotus
can
act,
the
Hope
by
hope
matter,
so
on
the
they
can
do
the
in-network
they
can
provide
inner
functions
such
as
caching
and
such
as
transcoding
or
something
or
some
intelligent
function
is,
can
be
equipped
if
it
means
the
each
router.
So
recovery
of
the
packet
is
also
so.
F
We
can
enhance
the
quality
of
the
story,
streaming
quality
compared
to
the
conventional
HTTP
or
some
other
approach
we
I
think
have.
F
C
C
Okay,
yeah:
this
target
is
about
a
few
ideas,
how
we
can
build
relevant
applications
with
ICN
and
then
protocol
mechanisms
that
we
know
and
yeah.
Obviously,
one
important
application
is
the
web
and,
and
so
Dave
and
I
put
some
say
initial
thoughts
together.
C
The
background
is
that
so
we
we
started
this
as
a
so-called
statement
or
a
vision
paper
to
the
ICN
conference
in
September,
and
this
is
like
a
short
two-page
paper,
so
it
doesn't
take
long
time
to
read
it,
and
so
this
was
somehow
put
in
a
context
of
meta
works,
and
so
it
wasn't
really
presented
at
the
conference
but
appeared
in
a
panel
which
was
fine,
but
so
we
thought
it
could
be
interesting
to
actually
present
the
idea
and
get
get
a
bit
more
feedback
and
maybe
also
kick
off
some
work
here
in
the
group.
C
The
other
background
is
that
you
know
currently
there's
you
know:
lots
of
talk
about
quick,
hdb3
and
and
so
on,
and
so
here's
an
interesting
blog
posting
by
Bruce
Daly,
who
is
characterizing,
quick,
basically
as
the
say,
long
missing,
RPC
mechanism
in
in
the
in
the
Internet
Protocol
suit,
so
for
efficient
RPC
communication
and
it's
not
casting
you're,
not
as
a
TCP
replacement
but
more
like
an
IPC
system
which
TCP
isn't
really
good
good
basis
for
in
his
View.
C
And
so
we
we
tend
to
agree
and
when
we,
when
you
talk
about
web
communication,
you
have
like
two
elements.
So
you
you
need
something
like
efficient,
say:
RPC
style
communication,
but
you
also
need
something
that
is
typically
called
rest,
so
some
kind
of
state
Evolution
on
servers
and
and
clients,
and
then
some
protocol
framework
to
manage
that.
C
And
so,
whereas
quick
is
say,
admittedly
much
better
than
say
the
like
previous
protocol
Stacks,
it's
so
the
the
approach
that
we
take
in
this
paper
here
is
that
okay,
can
we
maybe
improve
it
even
further
with
the
data
oriented
design,
so
quick
reminder
or
intro
tool
to
rest?
C
So
the
idea
is
that
you
have
clients
and
servers,
and
you
have
say,
well-defined
protocol
mechanisms
that
allow
you
to
say,
setup
State
on
a
server
and
then
via
interactions,
modify
the
state
and
say
if
evolve
it
both
on
the
server
and
the
client
side,
and
so
in
reality,
yeah
even
HTTP
is
stateless,
but
you
need
some
mechanism
to
refer
to
this
state
in
your
interactions
and
so
in
reality
we
have
used
things
like
cookies,
for
example,
to
you
know,
identify
clients
and
then
indirectly
also
the
client
stayed
in
invest
for
communication.
C
And
if
you
look
into
this
this
the
like
state-of-the-art
systems,
they
are
so
you
could
say
they
are
not
quite
as
optimal
as
they
could
be.
So,
first
of
all,
they
are
something
like
implementation
complexity,
so
you
have
several
layers
of
of
of
Stacks
with
their
interactions,
so
several
protocol
layers
in
in
this
deck
and
you're.
C
On
the
other
other
hand,
if
you
look
at
the
interactions
say
using
like
modern,
HTTP,
3
communication,
of
course
you
have
quite
a
few
messages
going
back
and
forth
and
you
have
request
parameters,
cookies
and
so
on,
and
so
the
key
idea
for
HTTP,
3
and
quick
is
of
course,
that
you
have
the
quick
connection
context
and
then
potentially
several
streams
in
there,
and
so
we
well
okay.
Maybe
we
actually
have
a
very
good
tool
to
come
up
with
a
say,
even
better
approach.
C
That
tool
is,
is
ICM
of
course,
and
so
we
thought
okay.
What
would
we
need
for
for
building
a
platform
for
rest
for
communication
and
then,
by
extension,
maybe
for
future
modern
web
protocols,
and
so
what
we
want
to
do
is
say:
do
rest
Communication
in
an
ICN
idiomatic
way.
So
not
you
know
blindly
copy
all
the
interaction
or
message
flows
but
think
what
it's
really
needed.
So
for
a
rest,
you
would
have
clients
and
servers
in
a
session.
C
So
it's
you
could
say
yeah
it's
a
it's
a
an
implementation
of
of
this
larger
concept
and
you
need
some
understanding
of
the
state
Evolution
and,
of
course
it
needs
to
be
applicable
to
any
different
applications
and
yeah.
You
cannot
ignore
security
and
privacy.
C
So
if
you
want
to
use
this
for
any
relevant
application,
you
want
to
have
a
similar
security
features
as
HTTP
and
TLS
today.
But
so
can
we
do
this
better
than
like
HTTP
3
over
over
quick
today?
Can
we
simplify
the
protocol
Machinery?
Can
we
maybe
even
have
less
overhead
on
The
Wire
without
losing
all
the
nice
ICN
features
that
we
appreciate.
C
And
okay,
so
if
you
kind
of
start
doing
this
in
a
naive
approach,
you
would
say
yeah.
Well,
we
have
interest
data
interactions,
so
we
could
just
map
the
say,
HTTP
or
arrest
requests
onto
interest
packets,
and
then
we
get
data
back
and
we
could
invent
some
naming
scheme,
perhaps
even
the
URI
like
naming
scheme
and
so
on.
So
we
have
discussed
this
earlier.
C
This
is
not
really
a
good
idea
right
so
because,
as
we
have
seen
earlier
in
this
client
server
communication,
you
typically
have
to
transmit
lots
of
data,
so
you
need
to
negotiate
Keys.
You
have
context
information
Cookies.
All
these
things.
You
really
can't
stuff
this
into
interest
packets
right.
So
we
we
have
this
flow
balance
concept
and
we
use
interest
something
like
the
equivalence
to
X
and
TCP
acknowledgment
and
TCP,
and
so
that
would
kind
of
screw
up
this
concept.
We
have
a
product,
uncontrolled
uncontracted,
not
contractual
data
in
the
network.
C
Also,
if
I
can
send
say
any
large
blob
to
any
server
is
not
really
good
from
a
security
and
robustness
perspective,
so
you
open
up
the
door
to
computer
and
overload
the
text
and
so
on
then
also
in
ICN.
Well,
our
interest
data
interaction
is
kind
of
controlling
things
like
interest
rates
on
the
client.
So
it's
it's
operates
on
a
network
time
scale.
So
we
kind
of
time
out
these
interests
eventually,
and
this
triggers
say
re-transmissions
and
so
on.
C
C
So
these
things
operate
in
a
different
time
scale
and
then
also
I
need
some
some
say
other
security
concept
around
this,
and
so
we
have
talked
about
this
in
the
context
of
reflexive
forwarding
and
and
Rise,
where
we
proposed
a
mechanism
where
a
say
client
can
initiate
say
RPC
like
requests,
but
then
we
use
ICN
idiomatic
interest
data
in
the
opposite,
so
reverse
direction
from
the
server
without
exposing
any
client
identity.
And
so
this
is
an
ICN
forwarder
extension
that
it's
needed
there.
C
I'm
I
won't
go
into
this
today,
but
we
talked
about
it.
I
think
last
last
time,
and
so
the
design
that
we
came
up
with
is
basically
about
enabling
this
client
server
communication
with
a
series
of
request
response
interactions
in
a
session
context
so
like
in
HTTP,
you
can
say
we
employ
reflexive
forwarding
so
directly
for
RPC
communication
and
so
a
lot
all
kinds
of
parameter
passing,
and
we
also
apply
this
to
the
key
exchange
that
we
are
going
to
talk
about
in
a
minute
to
set
up
these
sessions.
C
And
what
we
want
to
do
is
this
restful
communication,
but
not
say
inside
connections
or
tunnels.
So
they
say
response
data
that
we
get
should
be
ICN
data
objects,
so
they
of
course,
would
be
encrypted
in
most
cases,
but
we
apply
the
usual
ICN
security
mechanisms
and
we
don't
want
to
use
any
tunnel
mechanism.
C
And
so
of
course,
when
you
do
this,
and
you
want
to
have
good
performance
so
comparable
to
to
http
yeah,
you
have
a
series
of
requests
in
a
session.
You
want
to
avoid
setting
up
context
State
again
and
again,
so
this
shouldn't
require
more
round
trips,
and
so
the
challenge
is
that
we
want
to
establish
and
maintain
this
shared
assessment
session
State
in
in
these
sessions.
C
So
what
we
do
is
we
use
the
key
identifiers
in
in
this
session
and
so
the
associated
security
context
that
we
set
up
in
the
negotiation
phase
and
through
to
identify
the
the
session
stage,
and
then
we
use
the
recording
parameter
passing
for
clients
to
refer
to
previously
created
application.
C
State,
and
this
you
could
say,
emulates
something
like
HD
cookies
and,
of
course,
when
you
do
this,
you
have
when
you
think
about
so
so
what
is
is
kind
of
the
say
root
of
the
shared
application
state,
so
we
decided
that
we
tie
it
to
the
key
IDs,
and
so
because
this
is
kind
of
an
essential,
say
agreement
that
the
client
and
server
have
have
to
establish.
So
it
seems
to
make
kind
of
sense
to
use
this.
C
Basically,
as
the
session
identifier,
the
drawback
could
be
that
or
if
you,
if
you
change
Keys,
then
or
if
you
Wiki,
then
you
have
to
reset
up
your
your
context
in
this
system.
You
also
you
have
some
kind
of
coupling
or
binding
between
client
and
server,
because
server
has
the
security
context
and,
of
course,
also
the
application
context.
So
we
have
to
make
sure
that
your
say
subsequent
interest
reach
the
same
server.
C
This
is
a
kind
of
maybe
a
bit
yeah
something
to
take
care
of
in
an
ICN
environment
or
you
need
to
implement
some
kind
of
server,
back-end,
State
transfer
or
state
synchronization
system.
For
that.
C
So
Mark
and
colleagues
earlier
specified
ccnx
key
exchange,
so
in
a
draft
here
as
well
and
and
what
this
does
is
basically
TLS
1.3,
like
key
exchange
between
two
peers.
That
is
basically
following
what
TLS
1.3
does
for
establishing
a
shared
forward,
CQ
key,
which
you
could
use
for
confidential
communication.
C
The
main
use
case
at
the
time
was
something
like
a
tunneling
scheme,
so
you,
you
can
have
a
wrapping
in
a
ICN
Communication
in
an
outer
TLS
like
context
so
for
applications
like
you
know,
tele,
banking
or
something
you
would
show
any
kind
of
commercial
thing
you
would
you
would
use
it,
and
so
it
was
designed
for
this
client
server
scenarios
and
it's,
but
in
the
end
you
still
have
interests
and
data,
so
it's
orthogonal
to
reliability
and
congestion
control,
and
so
what
we
did
here
is
we.
C
We
used
this
exchange
protocol,
but
we
don't
want
to
use
this
say,
tunneling
approach,
so
in
this
paper
we
kind
of
describe
how
we
are
now
implementing
the
season.
X
key
exchange,
part
with
reflexive
forwarding.
So
because
we
wanted
to
avoid
you
know
sending
interests
in
both
directions.
So
we
want
to
do
it
in
the
reflexive
forwarding,
so
in
our
view,
more
ICN
native
way.
So
that's
that's
one
part,
and
then
we
basically
derive
a
key
for
encrypting.
C
The
the
data
objects
later
in
the
session,
maybe
a
bit
too
intricate
to
go
through
all
of
this
right
now,
because
we
are
also
running
out
of
time,
but
yeah
I
would
like
to
refer
you
to
this
paper
and
I
mean
this
is,
is
the
first
idea
like
a
sketch
essentially-
and
we
haven't
really
implemented
it
yet,
but
what
we
think
is
that
it's
now
a
really
good
time
to
think
about
web
over
ICN.
C
So
clearly
it's
not
enough
to
say
well,
we
just
use
interest
data,
and
so
the
key
idea
here
is
to
leverage
this.
C
What
we
think
really
useful
work
on
key
exchange
coupled
it
with
reflexive
forwarding
and
then
use
it
for
a
data
oriented
ICN
communication,
and
so
we
roughly
approximate
the
capabilities
of
like
HTTP
3
over
quick.
But
if
you
do
this
correctly,
the
resulting
system
implementation
may
actually
be
simpler
because
we
don't.
We
don't
have
this
relay
approach.
We
can
leverage
some
IC
and
optimization.
We
have
all
the
other
ICN
benefits,
still
like
caching
and
general,
and
a
name
oriented
system,
so
it
could
be
potentially
easy
to
implement.
C
Of
course,
the
devil
may
be
in
a
detail,
and
so
we
think
that
could
be
a
really
interesting
basis
to
build
like
the
next
generation
of
ICN
systems.
C
C
C
Okay,
that
was
our
quick
heads
up
on
on
restful
ICN.
We
don't
have
much
time,
unfortunately,
for
questions
it'd
be
great.
If
you
have
questions,
if
you
could
direct
them
to
the
mail
list
and
before
we
close
so
Dave
and
I
have
so
I'm,
not
sure
if
you
were
aware
there
was
a
side
meeting
on
Monday
at
the
ITF
in
London,
on
networking
for
metaverse
so
distributed
AR
VR
applications
and
a
bit
of
the
Mind
share.
C
There
is
actually
going
in
the
ICN
Direction
so
and
I
also
Blended,
say
some
some
ICN
ideas
in
that
concept
context,
and
so
we
thought
maybe
now
it
could
be
a
good
time
to
say
in
this
group
here
think
a
bit
about
a
research
agenda
and
and
also
recapitulate
a
little
bit.
C
What
we
have
in
terms
of
in
technology
is
things
like
multi-destination,
multi,
forwarding
and
multi-pass
forwarding
and
what
is
potentially
missing
so
for
building
this
say,
which
are
social,
arvr
applications,
and
so
we
thought
it
could
be
good
at
nice
to
have
a
interim
meeting
in
the
not
so
distant
future,
perhaps
end
of
November,
beginning
of
December.
C
So
if
you
are
interested
in
that,
please
feel
free
to
talk
to
us.
Of
course,
we
will
also
send
a
message
on
the
main
list
and
yeah
see
what
it's
kind
of
try
to
negotiating
the
interest
there
all
right
anything
else.
We
need
to
talk
about.