►
From YouTube: IETF99-ICNRG-20170719-0930
Description
ICNRG meeting session at IETF99
2017/07/19 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
We
have
the
note
well
that
I
think
most
of
you
have
seen
there
is
a
slight
difference
between
the
IRT
F
and
their
IETF,
the
that
that
we
require
a
bit
more
timely
disclosure
of
IPR
things.
So,
if
you
haven't
looked
at
that,
do
that
and
I
know
that
there
has
been
an
update
to
the
IETF,
it's
still
unclear
to
us.
If
this
one
should
be
updated
in
accordance
with
that
or
not,
but
we
used
one
we
used
for
the
last
couple
of
times.
Still
we
don't
have
Ellison
in
the
room
to
be
okay.
A
So
yeah
this
is
the
basic
infrastructure
for
our
research
group
that
mailing
list
web
Viki
the
week
is
the
place
where
we
keep
agendas
in
meeting
announcements
and
so
on.
So
if
you
want
to
keep
updated
that
besides,
the
mailing
list
are
the
two
main
resources
there
is
also
github
and
for
the
meeting
now
we
have
an
ether
pad
where
we
will
take
notes,
and
anybody
is
welcome
to
help
out
adding
to
the
notes.
Do
we
have
anybody
that
can
volunteer
as
a
note-taker
for
this
meeting.
B
C
A
C
A
C
A
A
D
A
Okay,
so
I
think
the
agenda
by
the
way,
I
should
also
mention
that
the
the
minutes
of
the
Sunda
meeting
is
uploaded
as
that
and
it
was
sent
out
on
the
mailing
list
for
comments,
and
we
haven't
heard
anything
on
that.
So
unless
we
get
some
comments
by
the
end
of
this
meeting,
we
will
consider
them.
Fine
I
will
not
load
them.
E
F
All
right
thanks,
so
we
had
a
full
day
meeting
again
on
Sunday,
which
was
actually
quite
interesting
and
if
you
haven't
been
there,
so
not
sure
if
you
heard
that
there
was
a
previous
ICN
for
computing
workshop
as
I
said
networking.
So
we
have
a
report
on
that.
If
you're
interested
there
a
couple
of
papers
and
presentations
that
are
really
relevant
to
the
work
we
are
doing
here,
we
only
mentioned
the
Intel
and
NSF's
on
that
research
program
for
ICN
Wireless
edge
computing.
F
So
we
kind
of
update
about
the
selected
projects
and
so
what
they
are
doing,
and
we
had
a
couple
of
say:
ICN,
research,
presentation
so
one
by
Edmund
on
using
NBN
for
data
intensive
science,
so
think
about
disseminating
CERN,
LHC
data
dissemination,
so
one
by
Alicia,
so
on
ICM,
augmented
reality
in
in
wireless
edge.
So
how
you
would
leverage
ICN
picture
for
that
cédric
on
network
coding,
I
see
em
and
Yanis
about
a
mobile
application,
shirring
framework
based
on
ICM,
and
then
we
had
a
slot
with
some
demo
content
demos.
F
So
first
Lucca
updated
us
on
the
Fido
CIC
n
project.
So
Fido
is
an
insulation.
Open-Source
project
for
like
a
software
switch
architecture
based
on
VPP
and
so
there's
a
ICN
activity
in
that
project
that
develops
my
CN
stack.
That
is
leveraging
this
underlying
framework,
and
so
we
also
gotta
get
a
demo
of
how
you
could
build,
for
example,
emulated
networks
using
this
year,
ICN
software
and
configure
them
and
do
things
like
multi
access,
communication
and
so
on.
So
it
was
pretty
interesting
next,
like.
F
That's
basically
using
several
ICN
technologies,
so
ICM
networking
name
resolution
and
so
on
to
build
a
say.
Larger
system
for
data
dissemination,
for
example,
also
iot
and
then
Bastion
at
us
on
the
terminology
document
that
we.
So
it's
like
clarifying
some
of
the
key
technology
for
ICN
that
was
recently
updated.
F
D
F
Okay,
moving
on
so
before
this
meeting
we
issued
last
calls
on
to
CC,
annex
specification,
drafts
or
messages
and
semantics
and
have
specifying
like
the
base
is
the
next
protocol.
Essentially,
and
so
from
our
perspective,
we
got
positive
feedback
and
say
no
issues
were
raised
to
us,
so
we
we
would
consider
this
last
call
as
complete
finished,
and
that
would
mean
we
could
actually
move
these
documents
forward.
G
G
Alright,
so
expect
that
by
the
end
of
the
week,
those
are
by
the
way
for
everyone,
those
are
intended
as
experimental
RFC's,
because
they
contain
protocol
specifications
they're,
not
there
they're
pretty
core
documents
that
many
people
are
using
in
order
to
actually
build
real
systems,
so
they
have
a
reasonably
high
degree
of
importance
to
this
community.
Thank
you.
F
So
we
think
that's
actually
a
good
milestone
that
we
reach
that
we,
you
know
finally
publish
say
specification
documents
coming
out
of
this
group-
that's
something
we
you
actually
want
to
do
more
in
the
future.
So
if
there's
something
you
are
working
on
that
would
be
of
this
nature
will
be
really
happy
to
help
progressing
that
and
with
that
yeah.
F
E
Okay,
so
good
morning,
everyone
again,
my
name-
is
Prakash
Sita
I
work
for
Cisco
and
I
had
two
of
my
other
colleagues
on
the
call
as
well,
but
I'll
be
presenting
on
their
behalf.
What
I'm
going
to
discuss
today
is
the
person
to
of
this
document.
We
started
putting
together
way
back
in
November
of
last
year,
and
then
we
published
the
worse
than
zero
right
around
IETF
98,
and
after
that
we
had
two
more
revisions
on
that.
E
We
have
been
discussing
quite
a
bit,
and
there
are
a
lot
of
thought,
provoking
that
why
do
we
need
a
new
draft?
What
is
so
different
about
this
ICN
in
the
cellular
mobile
network
so
based
upon
some
of
our
discussion
internally
with
so
the
researchers
in
this
area,
as
well
as
my
experience,
particularly
in
the
mobile
network?
E
The
second
thing
is
most
of
the
ICN
work
is
either
in
the
fixed
wireline
or
in
the
Wi-Fi
area,
but
no
work
has
been
done
in
the
cellular,
so
this
draft
addresses
that,
and
the
third
aspect
is
that
there
is
so
much
of
characterization
of
video
in
the
mobile
and
most
of
the
the
content
which
we
download
is
video,
which
is
the
biggest
benefit
for
ICN.
So
we
wanted
to
do
some
research
and
get
some
understanding
on
that.
E
What
you
see
on
the
right
hand,
side
are
the
the
the
changes
taken
place
in
this
draft
since
our
first
release,
and
luckily
we
got
lot
of
feedback
from
you
all
and
also
from
day
over
on
in
particularly-
and
it
took
almost
like
three
months
for
us
to
go
back
and
then
experiment
it
again
and
see
what
we
can
put
our
findings.
So
when
you
look
at
the
worse
than
2,
you
will
find
quite
a
big
difference
compared
to
what
we
had
in
version.
E
Zero
I
want
to
cover
very
briefly
about
how
we
envision
this
ICN
to
be
deployed,
and
we
are
also
working
very
closely
with
3gpp.
So
some
of
the
findings,
what
we
come
up
here
can
go
into
the
specific
essence:
development
for
for
3gpp.
So
my
colleagues
from
Cisco
who
are
working
on
3gpp,
they
are
taking
some
of
our
work
and
proposing
there
and
I
look
forward
for
partnership
from
the
community
and
and
all
other
researchers
in
this
area.
E
So
we
can
kind
of
pay
proposed
in
the
3gpp
as
well
the
first
key
aspect
in
in
terms
of
the
Yui
or
the
client
or
the
device
which
is
trying
to
get
the
content.
What
we
are
proposing
is
that
we
put
a
in
order
to
put
this
ICN
inside
the
the
mobile
protocol.
What
we
can
do
is
that
we
can
have
a
transport
selector
as
a
layer,
and
this
transport
selector
is
nothing
but
it's
an
icy
and
for
order,
and
it
can
do
very
two
important
function.
E
The
first
function
could
be:
it
can
help
decide
whether
the
data
should
be
sent
using
the
the
radio
protocol,
I
mean
say
like
LTE,
or
this
would
be
then
using
the
Wi-Fi,
or
this
can
be
done
using
both
based
upon
a
digital,
prioritization
and
second
thing.
It
could
be
also
based
upon
content
type
content
preference,
so
some
of
the
the
logics
logics
can
be
built
into
the
transport
selector.
So
that's
the
the
function
for
that
and
I
got
lot
of
comment
around
this.
We
in
the
worse
than
0,
the
name
was
different.
E
It
was
no
transport
selected,
we
had
ICN
for
order,
but
we
decided
that
transport
selector
will
be
more
generic
around
that.
The
second
party
that
at
the
network
layer
we
want
to
introduce
I,
see
and
function
and
that
will
coexist
with
the
IP
and
both
of
these
functions
will
have
a
interoperability
with
the
transport
selector
on
the
top.
And
what
do
you
call
a
PD
CP
layer
at
the
at
the
bottom?
E
One
of
the
most
important
function
is
performed
by
the
by
the
PD
CP
layer,
which
is
basically
doing
the
header
compression
decompressor
and
encryption,
as
well
as
for
betting,
the
the
message
coming
from
the
application
layer,
so
it
can
be
sent
towards
the
radio
and
that
layer
has
to
be
modified.
The
draft
content
lot
of
detail
about
what
all
changes
supposed
to
be
there
into
the
PDC
P
layer.
So
these
are
the
three
layer
we
are
proposing
to
make
changes
rest
of
the
the
lower
layer
like
our
LC
mac
layer
or
hy
layer.
E
There
is
no
change
around
that
they
will
remain
as
it
is.
So
that's
the
the
changes
in
the
Yui
then
the
second
aspect
again
in
this
draft,
you
will
find
lot
more
changes
around
the
II,
not
B
or
the
base
station.
So
what
we
are
proposing
here
is
that
the
radio
should
be
the
ICN
forwarder
and
the
way
it
should
work
is
ICN.
Forwarder
is
that
the
request
will
come
from
the
the
user
on
the
radio
interface.
E
It
will
come
to
the
a
node
B
and
after
that
it
will
have
a
logics
which
can
work
in
the
three
different
way.
The
first
one
will
be.
It
can
simply
handle
the
the
ICN
request,
and
if
the
ICN
transport
is
available,
it
can
send
the
request
on
the
ICN
transport.
The
second
thing
could
be
if
the
user
is
requesting
based
upon
the
IP
and
if
the
IP
is
available
it
can
send,
or
if
the
user
is
requesting
either
IP
or
ICN.
E
It
can
have
edits
the
logics
based
upon
parameters
and
then
it
can
send
it
out.
The
the
key
part
is
that
even
the
the
client
is
requesting
like
IP
and
IP
is
not
available.
Is
there
only
or
the
IC
and
transport?
Then
you
can
send
IP
on
top
of
IC
and
transport,
or
vice
versa.
So,
and
also
we
want
to
provide
a
capabilities
where
you
can
program
the
not
be
based
upon
certain
type
of
transport
available.
So
we
are
proposing
a
northbound
API
from
the
management
interface
on
that.
E
The
the
third
part,
what
we
want
to
do
is
that,
right
now
most
of
the
transport
between
the
radio
and
the
gateways
is
all
IP,
but
we
envision
that
in
future
there
might
be
a
dualistic
scenario
realistic
in
the
sense
it
could
be
IP
and
ICN,
both
or
in
certain
part
of
the
network.
This
could
be
just
ICN,
so
what
we
are
proposing
this
is
that
we
can
implement
this
ICN
in
the
transport
part
and
eventually
this
will
help
in
removing
some
of
the
encapsulation
tunnels.
E
E
We
look
at
the
the
security
which
is
implemented
for
IP.
It
has
to
be
there
for
the
IC
n
as
well,
and
the
third
part
is
that
DDoS
attack
for
the
mobile
gateways
or
the
services
we
had
yet
which
are
being
offered
and
if
it
move
to
the
IC
and
how
to
protect
those
those
areas
and
then
the
rest
for
in
terms
of
the
content
poisoning
in
terms
of
the
casing
and
then
pollution
Kassie
and
also
related
to
the
naming,
routing,
forwarding
and
application
security.
E
What
I
want
to
propose
is
that,
based
upon
our
last
three
months
work,
there
is
lot
of
questions
around
security.
Then
the
answers
which
you
could
find
if
any
of
you
are
working
in
this
area
and
want
to
provide
some
more
input.
I
really
welcome
because
after
I
got
feedback
from
our
worse
than
zero,
we
realized
that
security
hasn't
been
addressed
adequately,
especially
in
terms
of
the
the
mobile
scenario,
even
though
the
the
two
specific
cases
were
not
highlighted
here,
Tecna
TS,
thirty,
three,
three
one
zero
and
three
to
zero.
E
But
what
we
believe
based
upon
the
work
so
far,
is
that
maybe
it's
time
for
you
guys
to
help
us
with
some
more
collaboration
and
also
I,
want
to
request
that
chair.
It
would
be
really
good
if
we
can
adopt.
This
is
a
working
draft.
So
that
way
we
can
get
more
feedback
and
we
can
make
a
quick
progress
on
that.
So
with
that,
I
am
open
for
questions.
H
This
actor,
oh
man,
thanks
for
the
update,
I,
had
read
the
previous
version
and
it
was
good
Akbar,
AKB,
AR
I
had
read
a
previous
version
and
it
was
good.
But
what
the
one
comment,
if
you
go
back
one
slide
to
the
security,
please,
as
you
know,
I'm
going
to
be
presenting
the
deployment
considerations
next
and
I
had
a
similar
question
to
look
into
security,
and
what
I
found
is
that
RFC
791
that
had
been
done
in
this
working
group
with
security
considerations
actually
covered
like
some
of
these
issues.
E
H
H
One
more
with
the
UE,
where
you
have
the
UE
stack
yeah,
so
I
think
so.
Essentially,
if
I
understand
correctly
you're
proposing
the
the
dual
dual
sort
of
dual
stack
approach:
right,
yes,
yeah
and
so
the
ICN
function
knew
that
would
be.
When
would
you
use
that
that
would
be
if
you
had
4G
deployment
that
was
fully
upgraded
to
ICN?
E
It
back
few
years
back
when
ipv6
came
into
the
network,
we
used
to
have
only
ipv4
at
that
time
and
then
an
ipv6
was
introduced.
They
introduced
some
fun
kappa
bilities,
where,
when
the
client
attached
you
a
test,
it
can
indicate
the
preference
that
a
I
want,
ipv6
or
ipv4.
What
we
are
proposing
through
this
draft
is
that
now
it's
the
time
to
do
exactly
something
familiar,
but
we
can
introduce
ICN
in
addition
to
the
IP.
E
H
E
E
But
especially
when
the
when
the
user
is
attaching
to
the
cellular
network,
it
has
to
indicate
its
its
point
of
attachment,
and
that
is
what
this
slide
is
trying
to
explain
that
when
you
power
up
the
phone
when
it
attached
first
time,
it
has
to
indicate
that
a
I'm,
a
ICN
client,
and
that
is
how
I'm
going
to
do
all
the
product
walls
in
terms
of
the
transport
of
the
data.
Okay.
Thank
you.
It's
a
good.
J
Draft
thank
you.
Yeah
I'm
hide
across
an
individual
other
question
ability
I
do
like
to
draft
a
lot.
The
dual
stack
other
things
very
good,
it's
good
to
integrate
it
into
into
LT.
The
question
I
have
is
about
the
top
box.
You
talk
about
existing
applications
and
you
slot
the
transport
selector
in
between
to
just
dispatch
the
different
to
the
different
stacks.
But
I
wonder:
do
you
believe
a
transport
selector
is
really
what's
the
key
issue
or
isn't
there?
You
know
some
form
of
you
know
semantic
adaptation.
J
E
If
you
look
at
the
so
let
me
go
to
the
next
sorry,
one
second
yeah.
If
you
see
this
light
this
light,
they
start
the
exact
replica,
but
this
so
they
high-level
protocol
layers
between
the
client
on
the
left
side
and
the
nodes
on
the
right-hand
side.
So
what
we
used
to
have
is
that
application,
which
are
actually
either
requesting
the
content
or
consuming
the
content,
and
then
all
they
need
is
the
socket
either
TCP
or
UDP,
socket
to
connect
to
the
IP
layer
and
send
it
out
now.
E
What
we
are
trying
to
do
is
that
we
are
trying
to
introduce
one
additional
mechanism
in
addition
to
the
existing
IP,
and
also
we
want
to
create
some
form
of
a
preference
like
like
tomorrow.
You
might
have
some
app
where
you
say:
I
want
to
use
only
ICN
and
and
another
person
say
I,
don't
care
ICN
or
IP,
but
if
the
QoS
is
better
in
any
of
them,
I
want
that.
So
that
is
what
we
want
to
propose
that
using
this
transport
selector,
you
can
have
all
this
kind
of
mechanism
built
into.
E
E
K
L
Hi
John
Darrell
from
Airbus
I'm,
pretty
new
to
this
group,
so
I
saw
if
this
conversations
had
even
had
before
I
work
costs
a
lot
in
DTN
delay-tolerant
networks,
where
we
have
the
concept
of
using
any
old
transport
layer
and
then
the
bundle
protocol
that
runs
over
the
top
of
that
bundle
protocol
being
the
thing
actually
holds
all
the
payload.
Now
what
we
have
between
the
two
is
a
concept
of
a
convergence
layer
and
what
that
does
is
that
adapts
the
bundle
protocol
to
whatever
transport?
L
E
Ok,
thank
you,
I
will
I
will
go
through
that,
actually
it
will
not
transfer
selected
earlier.
I
had
a
name
as
an
IC
and
forwarder,
and
then
we,
when
we
had
that
ICN
forwarder
we
were
thinking
we
are.
We
are
kind
of
a
boxing
ourself
only
to
the
ICN
not
giving
an
additional
option
for
the
protocol.
So
hopefully
this
transport
selector
is
little
more
open,
with
more
choices,
to
determine
how
the
packets
can
be
forwarded
from
the
user.
L
E
L
F
Okay,
thank
you
if
I
can
just
inject
something
year,
so
that
the
good
comments
so
parts
of
the
ICN
community
I
think
also
have
a
bit
of
DPN
background
and
there's
definitely
also
a
relationship
and
things
that
can
be
learned.
There
has
actually
been
some
work
on
running
IC
and
over
DTM,
so
I
think
Stephen,
Farrell
and
folks
actually
have
submitted
a
draft
once
on
that.
E
F
F
E
A
lot
of
feedback
from
community,
as
well
as
from
my
company
as
well,
because
I'm
from
Cisco,
and
they
they
had
a
lot
of
influence
around
that.
So,
yes,
we
had
a
lot
of
additional
input
to
work
on
on
top
of
what
Dave
and
then
team
sent
to
us.
But
my
request
is
that
if
we
adopted
working
draft,
probably
I'll
get
a
lot
more
collaboration,
so
right.
F
So
we
think
this
is
probably
of
sufficient
interest
for
uber
large,
but
stood
like
this.
That
can
you
provide
an
extra
vision
and
then
we
normally
our
way
work
is
that
we
have
this
adoption
discussion
on
the
mailing
list,
so
people
basically
raise
their
voice
and
and
express
their
opinion
whether
this
is
a
sufficiently
mature
to
be
adopted
and
so
on.
So
we
normally,
we
kind
of
go
like
figure
out
the
interest
in
the
room
here
and
then
we
do
the
discussion
on
the
maintenance,
okay,
okay,
well,.
A
I
also
would
like
to
ask
the
room,
the
people
here
to
provide
another
round
of
comments
and
reviews
of
this
document
before
you
do
that
revision.
Do
we
have
anybody
that
would
be
willing
to
review
this
document
within
not-too-distant
future?
Okay,
we
have
two
people
down
there
and
they're
caught
yeah,
so,
okay,
Greg,
so
Derek,
Crossing,
Greg,
Ravi
and
Akbar.
D
A
So
that
would
be
really
great,
and
anybody
else-
and
also
this
has
a
lot
of
part
of
LT
and
the
mobile
thing
I
would
ask
people
who
have
colleagues
that's
working
closely
with
the
mobile.
If
you
could
ask
them
to
have
a
look
at
this
and
see
if
they
think
this
is
a
reasonable
approach.
I
think
that
would
be
grow.
Valuable
input
for
us
on
this.
Okay.
E
F
A
H
Okay,
okay,
thank
you.
So
my
name
is
aqua,
Rahman
and
I'm,
presenting
on
behalf
of
my
co-authors,
Dirk
Cross
under
Kuchar
and
Ravi,
and
the
title
of
the
draft.
As
you
can
see
his
deployment
considerations
for
ICN-
and
this
is
the
second
revision
just
to
give
you
some
background.
As
you
probably
all
know,
the
ICN
RG
charter
clearly
identifies
deployment
guidelines
as
an
important
topic
area
for
the
community
and
specifically
the
Charter
states
that
defining
clear
migration
paths.
H
H
The
key
changes
we
did
between
the
initial
and
the
current
Rev,
so
the
first
thing
it
it,
sir
I
think
it
set
the
stage
for
the
whole
draft,
so
I'll
just
mention
it
here.
Initially,
we
had
the
draft
title
as
configuration
Department
configurations,
but
the
feedback
given
to
us
is
that
really
you
know
we're
not
looking
for
a
formula
book
or
detailed
guidelines.
What
what
really?
What
what
the
draft
was
trying
to
cover
and
what
people
wanted
to
see
was
more
meta
guidance
on
how
to
deploy
ICN.
H
H
Second
point
is
I
haven't
just
here
listed
as
you
can
see
by
sections.
So
second
point
is:
we
were
asked
to
rework
all
the
definitions,
because
we
sort
of
you
know
meet
up
new
definitions
of
ICN
and
the
N
etc.
Some
of
the
key
terms,
so
it
made
sense
to
rework
that-
and
it's
referred
to
the
existing
ICN
terminology
draft
when
possible
and
or
other
RFC's,
for
example,
you
know,
there's
there's
rfcs
for
Sdn,
etc.
So
in
general
the
only
new
definition
we
have
in
this
section.
H
It
really
is
for
what
we
mean
by
deployment
itself,
and
for
that
we
had
a
short
definition,
meaning
that
we
were
in
the
context
of
this
document.
Deploying
deployment
means
integrating
and
interworking
an
ICN
network
with
the
existing
internet
and
being
able
to
do
useful
and
user
work.
Basically,
you
know
be
able
to
send
and
receive
content
for
a
real
life
end-users.
So
that
was
update
to
the
definition.
H
Then,
as
you'll
see,
we
have
several
basic
configurations
that
we've
defined
and
one
of
the
configurations
we
have
is
at
the
ICN
and
a
slice
so
basically,
usually
referring
to
the
5g
version,
and
this
review
was
kind
enough
to
give
us
a
lot
of
new
text
in
this
area
because
he's
the
expert
on
this
and
in
a
way
it
of
course
ties
into
the
previous
presentation,
which
was
about
I
CNN
4G.
So
we
were
looking
more
ahead
forward
to
the
5g
version,
which
is
the
ICN
in
a
slice.
H
We
updated
it
to
make
it
more
clear
and
map
to
one
of
these
existing
configurations
that
again
I'm
going
to
describe
in
a
few
in
a
bit
more
detail
in
a
few
slides,
but
we
grouped
it
under
the
appropriate
overlay
or
underlay
category
in
that
deployment
trials.
We
also
added
a
new
trial
trial
summary,
which
was
for
ICN
2020,
and
they
support
both
ndn
and
CCN
versions.
H
So
we
added
that-
and
one
important
comment
that
we
have
got
from
several
people
in
the
meeting
and
also
later
on
from
Dave-
was
that
that
that,
in
this
draft
we
should
clearly
identify
the
functionality
required
to
enable
interoperation
with
existing
internet,
for
example,
that
the
fact
that
HTTP
or
co-op
messages
must
be
mapped
to
ICN
messages
in
certain
deployment
scenarios
or
that
dynamic
naming
must
be.
You
know
more
clearly
specified
in
the
community.
H
Also
we
had
we
identified
a
few
I
think
was
a
list,
a
fairly
short
list
of
six
or
seven
items
and
basically
what
we
clarified.
Technically,
what
these
items
are
that
require
potential
protocol
effort
going
into
the
future
in
IETF,
but
we
removed
all
references
to
actually
I.
Try
to
identify
working
groups
are
buffs
because,
as
they
take
another
pointed
out,
that's
really
premature
and
that
can
be
done
in
a
second
step.
The
main,
the
main
issue
is
really
identifying
the
work
that
has
to
be
done.
So
that
was
one
more
major
change.
H
Then
we
expanded
the
conclusion
really
because
it
was
skeletal
at
that
point.
So
we
tried
to
make
sure
it
covers
the
major
conclusions
from
all
the
different
sections
and
we
had,
as
in
the
previous
four
G
discussion.
We
had
a
lot
of
comments
about
that.
We
should
have
a
security
consideration
section
that
was
filled
out
because
in
the
initial
version
it
was
just
empty.
So
I
had
to
think
a
lot
about
this,
but
fortunately
I
saw
RFC
7
9
4
5,
which,
as
the
title
suggests,
already
covered
a
lot
of
security
considerations.
H
So
I
read
through
that
carefully
and
identified
the
ones
that
were
relevant
to
deployment.
For
example,
they
identified
that
ICN
network
capability
to
Ridge
to
resist
do
s.
Attacks,
for
example,
still
is
that
it's
infancy.
They
also
identified
the
fact
that
the
security
of
the
in
cashing
units
in
the
network
still
is
that
its
infancy.
So
these
these
are
practical
issues
that
have
to
be
addressed
before
real
deployments
can
happen,
and
then
we
ourselves
added
some
text
basically
centering
on
the
fact
that
ICN,
of
course
has
very
good
built-in
authentication
and
optionally
encryption
properties.
H
But
if
you
want
to
really
inter
work
with
the
rest
of
the
Internet,
you
can't
just
consider
the
security
within
the
IC,
and
you
have
to
have
some
end-to-end
context
for
the
security.
So
we
identified
that
that's
one
issue
that
has
to
be
really
looked
into
a
bit
more.
For
example,
if
an
HTTP
message
comes
and
you
inter
work
with
ICN
and
we
send
back
HTTP
response,
what
is
the
end
to
end
security
context
of
the
whole
thing,
so
those
were
the
main
major
changes.
H
Any
questions
so
far
did
I
miss
anything
that
anyone
had
asked.
Okay,
good,
then
just
to
highlight
here
what
what's
actually
covered
in
the
draft.
So
the
terminology,
as
I
mentioned,
we
start
off
basically
by
identifying
the
key
deploy,
what
we
call
the
deployment
configurations
and
really
its
four
major
ones,
there's
the
sort
of
so
called
green
field.
You
know
the
initial
ICN
idea
where
you
would
replace
everything
with
ICN,
so
we
call
that
the
wholesale
replacement-
that's,
of
course
you
know
practically
going
forward
and
from
what
we
saw
from
the
experiments,
the
least
likely.
H
Then
we
have
the
two
other
ones.
The
ICN
is
an
overlay
where,
basically,
a
lot
of
the
experiments,
for
example,
have
been
run
as
an
overlay.
So
that's
definitely
one
because
a
configuration
then
there's
the
icns
and
underlay,
where
basically,
you
will
have
either
at
the
edge
or
at
the
core.
Some
basic
ICN
fabric,
including
perhaps
you
know,
writing
ICN
directly
on
layer,
2
and
then
you'll
do
that
mapping
at
the
ingress
and
the
egress
of
HTTP
co-op
or
whatever
the
the
protocol
use
in
the
rest
of
the
network
and
in
the
devices.
M
Thomas,
which,
for
Hamburg
what
I
miss
a
little
bit
in
your
in
your
first
of
all,
thanks
for
all
these
enumerations
and
for
this
for
this
work.
But
what
I
miss
a
little
bit
is
the
activities
that
have
been
done
about
ICN
over
wireless
and,
in
particular
about
about
lossy
low-power
wireless
networks.
H
N
H
J
So
it's
just
so
very
quick,
come
from
ISO
to
cross
again
I
actually
suggested
the
reference
is
too
late.
I
know
they
fit
under
each
network.
We
had
a
discussion
at
our
recent
protocol
enery
where
one
of
the
project
members
pointed
out,
but
we
had
already
Ising
submitted.
202
and
I
didn't
want
to
push
another.
J
Oh
three
in
there
the
list
of
references
can
be
significantly
extended,
I
I
think
we're
all
aware
of
that,
and
and
and
if
people
just
look
at
the
categorization
and
it
almost
I
think
Dave,
he
suggested
it
at
some
point
you're
having
this
almost
like
a
living
document
that
kind
of
like
gross
in
references
and
things.
This
is
by
no
means
complete,
I,
think
we
are
aware
of
that.
You
know,
but
I
should
have
told
you
that
before
that
it
was
mentioned,
the
other
was
my
mistake.
Okay,.
H
No
problem,
thank
you
so
we'll
take
the
action,
we'll
talk
to
Thomas
and,
of
course,
Dirk
is
a
co-author,
even
I,
guess
the
the
work
that
Prakash
had
presented.
We
could
somehow
you
know
reference
added
here,
because
I
think
we
have
the
I
Sienna
in
a
slice,
but
we
didn't
that
was
more
specifically
oriented
to
5g.
So
if
we
wanted
to
add
4G
reference
or
somehow
tie
it
in
either
as
a
deployment
trial
or
something
I
think
it
would
be,
it
would
be
nice
for
completeness.
H
H
So
do
they
do
they
assume
new
applications
that
are
ICN
enabled
or
do
they
exist,
assume
existing
applications
that
somehow
to
inter
work
with
ICN,
then
there
was
more
specific
Network
components,
which
was
basically
CDN,
as
we
saw
from
the
literature
and
from
reviews,
and
discussions
is
a
key
use
case,
probably
for
ICN
going
forward
to
be
deployed
because
it
it.
It
is
basically
anyways,
caching
and
based
on
names.
H
H
You
know
the
interworking
issues,
because
the
whole
idea
here
is
that
we're
trying
to
give
guidance
on
future
deployments.
Considerations
for
that
and
one
of
the
I
think
the
obvious
things
the
industry
knows,
and
we
try
to
codify.
Here
is
really
what
are
the
key
protocols
that
we
need
to
affect,
whether
they
be,
for
example,
for
multicast
distribution,
whether
they
be
to
support
existing
HTTP
co-op,
whether
they
be
to
do
the
mapping
of
these
messages,
etc.
Hi.
O
Yves
Schuler
from
Intel
I
was
just
curious
in
your
research
of
all
these
trials.
You
said
they
these
they
range
from
just
a
few
nodes
to
hundreds
of
nodes.
Did
you
get
any
trials
that
you're
aware
of
that
are
experimenting
with
more
sizable,
even
more
sizable
ICM
deployments,
because
I
think
that
that
might
actually
be
an
issue
for
the
for
the
later
section
about
known
gaps
that
you
know
is
that
is
that
a
large
enough
deployment
to
understand
all
the
gaps,
even
right.
H
I
I
think
it's
a
valid
question,
but
we
just
looked
at
the
corpus
of
information
available
and
really
we
didn't
see
anything
that
was
in
the
tens
of
thousands,
for
example,
if
I've
missed
that
I'd
definitely
like
to
be
told
about
it,
but
I
think
it
was
really
in
the
order
of
I
think
the
biggest
was
probably
in
the
low
thousands.
So
that
seems
to
be
the
range
of
yes.
O
H
It's
a
very
good
question
that,
on
the
other
hand,
I
think
something
that
alleviates
the
concern
a
bit.
Is
there
were
so
many
different
approaches,
so
there
was
like
India
and
CCN.
You
know
there
was
overlay
underlay,
so
they
look
at
the
the
I
think
the
problem
has
been
looked
at
for
many
different
angles
and,
as
we
saw
in
the
in
the
the
chair
summary,
some
of
these
these
protocols
are
have
been
so
well
tested
that
they're
now
going
to
RFC,
so
I
think
there.
That
gives
a
slight
bit
of
confidence.
J
I
might
follow
up
on
this
and
I
think
the
scale
issue
is
really
one,
but
that's
an
identifier,
but
you
know
medical
deployments
noisy
and
I.
Remember
a
very
strong
remark
of
one
funding
agency
about
three
years
back
on
scale
of
IC
and
research
and
I.
Think
at
that
stage
there
were
tens
of
nodes.
I
think
a
lot
of
it
has
to
do.
J
But
the
point
is
a
lot
of
these.
The
software
will
be
utilized
for
that.
It's
either
heavily
soft
engineered
on
the
ICN
side
and
utilizing
platforms
that
are
heavily
software,
yet
I
think
that's
a
real
issue.
When
it
comes
to
scale,
but
that
leads
me
to
another
remark-
I
actually
had
about
excluding
simulations,
as
we
had
a
discussion
and
I
fully
agree
to
that.
But
there
is
a
thing
in
between
and
we
have
a
little
bit.
J
Migration
for
and
it's
actually
very
much
related
to
the
LTE
traffic,
because
it
was,
it
was
considering
a
dual
stack
deployment
and
the
transition
from
overlay
and
native
existing
towards
a
native
ICN
deployment
kind
of
thing
now
I
think
to
me
they
are
still
relevant
because
even
though
they
are
not
deployments,
but
they
are
deployment,
oriented
studies
and
I
do
know.
But
I
couldn't
remember
the
reference.
I
know
the
ndn
project
has
at
least
done.
Another
study
and
I
have
to
look
it
up
because
I
used
to
know
it.
J
I
might
find
myself,
but
these
I
think
would
be
things
quite
interesting
aren't,
but
in
because
they
are
obviously
very
focused.
They're,
not
I,
don't
know
testing
a
protocol
in
scale,
but
it's
really
looks
at
transition
certain
migration
parts,
so
we
focus
in
this
work,
for
instance,
on
core
and
edge
Network
migration,
etc,
and
that
could
be
quite
relevant
as
references
are
without
here.
Unless
you
might
know
what
that
reference
is
because
I
do
know
the
work.
P
I
think
our
work
has
not
so
much
of
a
transition
because
we
believe
the
most
advantages
of
a
new
architecture
can
only
be
explored,
but
the
Zegna
application
that
actually
take
advantage
of
it.
You
try
to
transit
and
you
can
see
I
happen
to
run
over
I,
see
in
I'm,
not
a
confident
you
actually
get
the
most
advantages.
I
think
this
relates
to
all
the
things
I've
heard
so
far
back
up
out
the
first
one.
It's
at
the
first
one
I
hope
they.
H
P
The
Falchi
deployment
I
saw
that
sly
scene
that
I
see
in
just
the
follow
the
transport
that'll
be
a
very
long
discussion
that
I,
don't
want
to.
You
know,
take
your
time
here
on,
but
that
we
were
much
like
to
chat
with
people.
Afterward
I
have
a
pretty
different
picture.
Thank
you.
Thank
you.
I
just.
H
Briefly
in
in
the
deployment
migration
paths,
the
section
4
is
where
we
try
to
identify
the
issues
related
to,
as
the
name
implies
deployment,
and
we
clearly
identified
application
as
a
key
area
that
has
to
be
looked
at.
So
do
you
assume
that
the
applications,
as
I
mentioned
previously
are
I,
said
enabled
or
the
existing
application
that
have
to
be
adapted
so
just
to
respond
briefly
in
there
go
ahead?
Please.
P
Okay,
existing
applications
can
benefit
greatly
from
ICN,
but
given
that
they
were
developed
on
top
of
v/o,
at
least
on
that
you
know,
point
point:
I,
dress,
based
that
delivery
model
and
without
the
security
actually
intrinsically
built
in
my
personal
will,
I
said
they
will
not
be
able
to
benefit
fully,
and
so
is
a
transition
about
you
know
putting
ICN.
Just
you
know
it's
an
IP
replacement.
P
P
F
P
H
A
H
H
Okay,
so
just
to
go
through
the
deployment
configurations,
I
I
sort
of
had
covered
I
think
the
main
points,
but
just
to
go
through
it
quickly.
So,
basically,
as
I
mentioned,
it's
a
considerations
draft
trying
to
give
some
guy
what
to
look
at
when
you
deploy
I
see
and
what
are
the
the
issues
and
what
are
the
possible
approaches.
So
the
first
thing
we
started
off
with
is
actually
identifying
that
the
configurations
that
we
saw
from
all
the
different
publications
and
experiments
etc.
H
So,
as
I
mentioned,
the
wholesale
really
you
know,
most
ICN
projects
start
off
considering
a
whole
wholesale
or
clean
slate,
but
practically
speaking,
they'll
often
migrate
to
one
of
the
other
two,
which
is
first
icns
and
overlay
sometimes
refer
to
as
tunneling
loosely.
So
you
have
various
flavors
of
that
you
can
have
ICN
sent
over
UDP.
You
can
have
ICN
names
map
to
ipv6
addresses.
You
can
have
some
sort
of
convey
convergence
layer
to
map
ICN
semantics.
This
I
think
relates
to
the
previous
point
for
more
gay.
H
You
have
ICN
as
an
underlay,
so
here
really
you
would
have
ICN
infrastructure
Islands,
either
at
the
edge
or
the
core
of
the
network
and
then
through
gateways,
essentially
or
network
attachment
points
at
the
ingress
and
egress.
You
would
do
protocol
mapping.
So
some
examples
are
given
there
HTTP
co-op
IP
onto
core
ICN
messages,
core
network
ica
messages,
edge,
tcp/ip,
core
TCP,
ICN
messages,
edge,
ICN
messages
on
the
core,
HTTP
co-op,
IP
message.
So
you
have
many
different.
H
You
know
not
ICN
enabled
you
could
start
off
with
just
an
edge
IOT
deployment
and
expand
out
from
there.
I
guess,
as
time
goes
on
final
one.
The
ICN
is
a
slice.
This
wrap,
you
had
done
a
lot
of
work.
So
basically
the
idea
is
you
know
what
the
famous
five
network
slicing
to
deploy
ICN
there
either
it
could
be.
On
top
of
IP
or
layer
to
it,
there's
many
different
possible
options:
I.
P
Waited
until
you
show
all
the
three
slides
to
see
that
the
point
I
I
care
most
showed
up
here,
I
think
it's
not
there.
This
is
actually
ICO
pack.
A
comment
Thomas
made
earlier,
that
is,
the
native
and
I,
see
any
running
directly
on
top
of
wireless
and
having
application
directly
on
top
of
ICN
I
believe
that
actually
is
a
picture
suggested
by
this
ICN.
P
J
Dough
Crossin,
if
I
might,
if
I
might
disagree
the
dimensioning
of
the
draft
he
said
it
outlines
at
which
part
of
the
network,
the
my
Croatian
happened,
which
was
ICN
over
Wireless,
is
the
edge
network.
That's
in
the
draft
know
the
reference
are
missing
me.
We
said
that
would
be
at
the
the
references
pure
IC
and
applications
is
in
because
you're
doing
application
service
migration.
In
that
case
you,
don't
you
simply
don't
Mike
right,
you
do
new
applications.
J
We
specifically
point
out
new
applications
which,
by
the
way,
obviously
one
of
the
issues
maybe
of
the
is
energy.
The
new
applications
really
have
been
missing
for
many
years.
We
haven't
really
seen
too
many
exciting
ones,
but
that's
a
different
issue
right
I
do
believe
they're.
Both
in
the
problem
is,
you
have
to
read
the
draft
multi-dimensionally,
but
Bay's
application
and
service
migration
happening
at
various
parts
of
the
network
and
therefore,
u
io
t
scenario:
Wireless
fits
into
application
lives.
J
My
collation
at
the
edge
network,
so
it
is,
it
is
in
the
references
will
be
added,
but
the
point
is
also
I'm.
Sorry
that
the
excitement
of
ICN
work
happens
in
deployment
in
parts
of
the
network,
not
everybody
is
as
excited
maybe
about
core
migration.
I
can
understand
that,
and
maybe
some
people
will
believe
that
ICN
at
the
edge
is
the
most
exciting
thing,
but
the
draft
is
supposed
to
cover
the
different,
my
Croatians
as
they
happen.
G
I'm
gonna
cut
in
just
because
I
have
a
piece
of
information
may
be
relevant
Alicia
here,
which
is
that
at
least
one
of
the
teams
working
on
the
when
project
is
explicitly
looking
at
running
ICN
over
a
slice
on
5g.
So
at
least
one
of
the
approaches
being
done
in
ICN
win
is
exactly
the
same
as
what
one
of
the
deployment
options
here
yeah.
There
are
other
approaches
yeah.
If
you
want
to
contribute
to
the
draft,
that
would
be
really
great
I.
E
Just
want
to
back
that
up,
I
mean
when
you
see
I,
see
another
slice,
bringing
I
see
a
nice
close
to
the
emojis.
So
in
that
sense
your
5g
ran,
isn't
purely
the
radio
layer
and
you
could
actually
do
mobility
on
top
of
Iceland,
so
I
mean
I,
don't
think
you're
missing
anything,
and
if
you
probably
even
listened
to
the
talk
yesterday
on
5g
from
the
3gpp
folks,
it's
a
most
kind
of
flexible
architecture
that
you
have
there,
there's
no
custom
gateway
functionalities
and
such
like
that.
E
P
P
Don't
cut
me
off,
let
me
say
it
I'm,
so
glad
I
agree
with
Dirk
chosen
on
this
agreement.
Yes,
that
is
the
the
the
machining
to
say,
I,
think
a
round
table
awareness
and
then
period
is
now
to
the
picture.
I
tried
to
comment
earlier.
Maybe
I
need
to
make
a
career,
but
that's
not
the
picture.
I
think
as
really.
There
is
a
new
way
of
trying
things
out.
Lysine,
it's
a
I've,
I've
seen
parties
and
night
is
a
picture.
P
If
you
just
say
you
say
great
segment
of
the
picture
to
say:
oh
I,
seen
on
the
wireless
and
then
on
the
other
side,
I
would
say:
I
say
I'm
about
I,
don't
know
III
CNN
transport,
so-called
the
transport
of
today,
and
then
you
build
applications.
That's
a
very
different
picture.
I
also
want
to
reply
to
Rafi
that
I
understand.
Falchi
has
their
own
regions
of
the
pictures,
but
there's
also
you
can
look
at
the
same
the
world
from
different
angle
from
mango.
P
H
F
Well,
I
think
that
was
a
useful
discussion.
Oh
I
mean
so
basically
we
have
seen
that
they
are
really.
You
know
different
perspectives
of
the
ICN
deployments,
and
so
this
draft
lists
I
think
quite
a
comprehensive
set
of
options.
We
also
got
some
additional
feedback,
so
I
think
there's
the
potential
for
us
to
do
another
wife
on
this
which
you're
greener.
Yes,.
H
F
I
think
I
mean
this
is
really
a
a
I
mean:
okay,
yeah
I
shouldn't
handle
this
as
a
quarter.
To
be
honest,
okay,.
A
So
my
proposal
is,
as
we
did
the
same
as
the
previous
prep,
that
that
we
people
to
continue
to
comment
now
in
a
short
time.
You
do
another
Reb
of
the
document
and
after
that
would
take
it
to
the
list
to
see.
If
the
group
feels
it's
ready
to
adopt
this
as
a
working
group
or
research
group
draft.
Would
that
make
sense
so.
G
Look
one
other
way
we
could
deal
with
this
is
we
could
just
get
more
comments
on
the
current
Rev,
so
that
doesn't
occur,
doesn't
have
they
threw
two
revs
right
before
we
look
at
adoption,
so
we
can
get
some
more
comments
and
then
and
then
get
a
readout
of
that
and
then
look
at
adoption
rather
than
rather
than
issuing
yet
another
version
of
the
draft.
Now
that's
all
no.
A
L
G
G
Q
It
off
I
just
wanted
to
make
the
point
that
you
know.
Maturity
is
obviously
an
issue,
but
the
other
question
for
adoption
is:
does
the
research
group
think
this
is
interesting
stuff
that
the
research
group
should
publish
and
I
certainly
think
it
is
so
I
mean
from
my
perspective?
Certainly,
this
is
something
that
we
want.
That
is
useful
to
put
out
so
I'm
yeah
I
haven't
read
the
latest
document,
so
I
cannot
comment
on
the
extra
maturity
of
the
test,
a
text,
but
that's
from
you
secondary
issue
actually
right
the
primary
issue
of
adoption.
Q
H
A
G
C
Q
Q
Magic
cool,
so
the
first
thing
and
maybe
I
start
with
the
title,
and
we
actually
had
the
same
issue
at
the
last
IDF,
where
the
chair
suggested.
Somebody
should
actually
give
the
drafter
Thoreau,
Reid
and
aqua
was
so
kind
to
do
that
and
provide
us
with
a
lot
of
comments.
So
after
you
posted
the
comments
on
the
list,
I
replied
on
the
list.
So
but
the
main
goal
of
this
presentation
is
to
summarize
it
your
comments
and
how
we
address
them.
Q
So
if,
if
you
feel
in
any
way
what
I'm
saying
isn't
was
not
your
comment,
please
come
to
the
mic
right
away
and
we
can
discuss,
and
but
the
first
comment
you
made,
it
was
actually
the
title
and
I
actually
agree
with
you
and
Sarina
renamed
the
title
to
research
directions
for
using
ICN
and
disaster
scenarios.
The
time
the
whole
title
was
just
using
I
see
any
disaster
scenarios,
but
since
this
is
a
research
group
document,
I
just
wanted
to
make
the
working
for
where
so.
We
think
this
new
actually
good
suggestion.
Q
We
changed
it,
but
if
people
feel
it's
not
an
adequate
title,
just
you
know.
Let
us
know
I
think
it's
a
good
title,
because
it's
it's
me
more
this.
This
document
is
more
or
less
like
a
position
paper
right.
We're
trying
to
argue
that
ICN
is
good
for
disaster
scenarios
and
we
give
some
research
partners
so
yeah
with
that.
Q
Maybe
yeah
I
can
do
it,
and
so
I
just
want
to
go
quickly
over
this
slide,
because
I've
presented
this
multiple
times,
and
so
we
have
a
lot
of
people
have
been
working
on
and
applying
ICN
technologies
to
solve
an
issue.
Q
Like
you
see
in
the
picture
where,
after
disaster,
a
network
has
lots
of
broken
links
and
but
you
still
want
to
be
able
to
communicate
with
each
other
in
a
DTN
type
of
fashion,
so
we
looked
at
several
key
use
cases
they're
all
in
the
document,
so
I
don't
really
want
to
go
over
this
too
much
because
I've
presented
this,
who
has
not
seen
a
presentation
from
me
on
the
disaster
document,
see
very
few
people.
So
if
because
I
presented
multiple
times
yet
I
see
energy.
Q
If
you
really
want
to
get
more
information,
just
read
the
document.
There's
a
lot
of
text
in
there.
So
I
don't
want
to
bother
people
and
just
a
reminder
of
the
history.
We
had
a
lot
of
initial
versions
and
over
over
the
years
we
had
actually
research
project
mainly
working
on
this
use
case,
and
this
is
an
output
and
over
the
years
we
got
various
feedback.
One
one
big
concern
was
from
the
DTN
people
who
were
said.
Basically,
this
is
our
turf.
Q
Why
is
ICN
now
in
our
turf
and
we've
added
a
lot
of
text
explaining
why
we
think
that
actually,
an
ICN
could
also
be
good
starting
point
to
address
DTN
style
communications
and
it
has
been
adopted
last
year
and,
like
I
just
mentioned,
and
the
chair
said
weld
to
to
to
move
the
document
ahead.
Why
don't
we
give
it
a
thorough
review
and
aqua
was
so
kind
to
do
that
and
he
gave
multiple
comments
and
we
think
we
dress
them
all
or
the
ones
we
didn't
address.
Q
Q
Q
Anyway,
I
mentioned
this
already,
so
this
was
such
as
such,
as
should
we
we
talked-
and
this
was
actually
a
good
point
and
we
talked
a
lot
about
how
you
want
to
do
disaster
communication
with
ICN
or
how
you
can
do
it,
but
a
comma
at
the
point
that
actually
in
existing
mobile
networks,
there's
also
some
services
out
there
right,
you
can
do
say
broadcast.
You
can
send
SMS
at
notifications
out
to
people
if
there's
a
disaster,
so
I
think
aqua.
Q
Your
point
was
to
just
mention
these
existing
services
to
say:
okay,
even
in
today's
mobile
networks
are
some
services,
but
you
know
if
the
network
breaks
down.
Maybe
you
want
to
you
have
a
comment
day:
okay,
so
so
yeah.
So
we
took
this
as
a
good
comment
and
we
added
some
text
as
you
can
see
here.
Another
point
is:
we
talked
a
lot
about
security
and
authentication
in
the
document
and
in
fact
also,
this
was
a
very
good
comment.
There
are
services,
so
the
dock
at
the
old
document
read
like
well.
Q
If
you
are
offline
from
your
centralized
service,
you
can
do
nothing
in
today's
mobile
networks
and
that's
not
entirely
true,
and
you
made
a
very
good
point
there,
or
course
there
are
some
services.
Everybody
knows
about
emergency
calls
right.
So,
even
without
authentication
you
there
are
some
services
available.
I
try
to
highlight
here
in
the
text
that
there
are
certain
things
that
you
still
cannot
do
in
today's
network.
Q
If
you
don't
have
access
to
an
authentication
server
and
those
are
the
kind
of
things
we
think
ICN
can
do
better,
and
so
one
of
the
things
would
be
like
you
and
user.
You
want
to
inform
authorities
and
you
still
want
to
be
authenticated
in
these
kind
of
things.
So
we
added
some
text
here
too
and
yeah,
and
this
is
where
actually
the
one
comment
we
didn't
agree
on
with
you.
You
said
the
list
is
not
exhaustive.
Q
There
certainly
should
be
more
added
more
things
and
I
actually
had
some
alt
text
in
the
document
saying
yeah,
the
list
is
not
complete.
We
actually
think
at
this
point.
The
risk
list
of
ICN
benefits
we
listed
is
rather
complete
and
we
basically
think
this.
This
document
should
not
be
a
living
document.
Until
you
know,
we
found
all
the
possible
and
way
sighs
I
see.
I
can
have,
but
rather
like
a
position
paper
arguing
some
key
points
so
actually
I
removed.
Q
That
text
and
I
replied
also
in
the
mails
yeah,
and
this
is
actually
the
the
one
comment
that
triggered
a
lot
of
discussion
among
the
authors
of
the
document,
because
you
were
saying
well,
you
talk
about
a
sock
by
again
right,
you,
you
said
in
one
of
your
key
comments.
Well,
and
you
talked
about
desire
communication
after
disaster,
the
the
one
thing
people
want
to
do
after
that
disasters.
They
want
to
make
a
voice
call
right.
Q
Q
Having
said
that,
of
course,
and
we
put
put
a
pointer
here-
and
there
has
been
work
on
doing
voice
over
IP
style
communication
over
ICN
I
mean
how
do
you
call
that
voice
voice,
the
end,
I,
guess
or,
and
so
you
can
do
real-time
communication
over
ICN,
but
in
the
scenario
we
are
considering,
we
think
that's
almost
impossible
to
do.
Having
said
that,
again,
of
course,
you
can
do-
and
this
was
what
a
cool
comment
from
some
some
of
our
co-authors,
that
you
and,
of
course
you
can
do
and
voice
messages
like
whatsapp
has
right.
Q
So
why
not
might
not
be
able
to
do
if
I
want
to
reset
Rick
I
might
not
be
able
to
have
a
phone
call
with
them,
but
I,
certainly
with
the
communication
we
are
considering.
The
model
we
are
considering,
I
can
send
it.
I
can
put
out
a
voice
message
and
Devender
it
eventually
it
reaches
them.
So,
in
short,
the
answer
is
you're,
making
a
good
point,
and
it's
good
that
we
added
some
I
think
it's.
Q
H
J
Sorry,
the
quick
Amida
shouldn't
it
be
one
of
the
advantages
of
ICN
to
have
the
choice.
I
mean
you
do
you,
you
can
imagine
to
be
even
a
fragment
of
situations
where
you
happen
to
be
in
proximity
of
real-time
communication,
good
point,
and
obviously
you
probably
would
like
real-time
communication
to
happen
at
case,
but
if
I
am
fragmented.
Indeed,
you
actually
automatically
switch
to
leaving
a
voice
message
right
right
right,
so
that.
Q
More
it
takes
you
actually
right,
I
mean
there
are
certain
cases
where
I
can
actually
do
voice
and
I
I
mean
I.
Think
we
wrote
it
there
explicitly.
You
can
do
voice
of
ICN
if
you
want,
but
in
most
of
the
sin
that
the
interesting
cases
we
are
considering
is
where
it's
not
possible,
but
there
may
be,
you
know,
I,
think
the
point.
J
J
Q
Just
saying
yeah,
if
you
have
someone
in
your
proximity,
of
course,
if
you
have
direct
connectivity,
of
course,
you
can
do
voice
of
ICN
and
there
have
been
some
research
papers.
Oh
okay,
okay,
thanks
and
yeah.
That
was
just
a
small
comment.
I
mean
we.
We
talked
about
IC
and
data
mutes
a
lot
in
the
document
and
actually
we
listed
and
and
in
this
section
actually
gave
a
lot
of
pointers
to
existing
work,
and
your
comment,
Aqua
was
well.
Has
urban
also
work
on
IC
and
data
muse
and
of
course
there
has
so
I.
Q
We
decided
one
of
the
papers
yeah
and
that's
a
good
good
question
so
and
I
think
your
comments
is
that
the
old
document
sounded
like
all,
problems
have
been
solved,
which
is
certainly
not
the
case,
so
we
revised
the
text
saying
well
yeah.
So
this
is
it
kind
of
like
a
position
paper.
There
has
been
another
work.
It's
we
think.
Icn
is
a
very
good
starting
point
to
address
all
of
these
problems,
but
certainly
there's
need
for
further
research
and
I.
Think
it's
now
explicit
in
the
document.
Right.
Q
That's
like,
however,
further
more
detail
challenges
challenges
exist,
so
that's
important,
and
this
one
actually
is
a
good
point
and
III
would
like
to
also
mention
this
to
the
research
group,
and
so
the
comment
was:
how
does
this
all
relate
to
idea
of
standardization
and
obviously
raised
a
lot?
It
relates
a
lot
to
ITF
civilization
because
to
make
all
of
this
feasible
in
an
interoperable
way.
Q
That's
what
I'm
saying
okay
yeah
and
so
in
that
sense
there
is
a
big
relation
to
to
standardization
work
in
order
to
make
this
vision
that
we
kind
of
have
here,
I
mean
there's
been
a
lot
of
research,
but
in
order
to
make
this
really
deployed
stuff,
you
would
in
an
interoperable
way,
between
different
vendor
devices.
You
would
need
a
a
core
protocol,
so
this
is
actually
a
good
motivator
that
we
need
this
kind
of
stuff
and.
Q
Yeah,
so
next
step
I
actually
didn't
change
the
decide
from
the
last
time.
I
present
it
because
we
think
it's
quite
mature
and
but
I
really.
Thank
you
for
your
comments.
I
think
it
really
improves
the
document,
because
a
lot
of
this
stuff
was
implicitly
in
our
head,
but
we
really
didn't
mention
it
and
you
you
caught
some
good
things
there
and
yeah
I'm
open
for
suggestions
how
to
move
this
forward
and
I
think
so
we,
the
authors,
think
it's
quite
quite
mature.
At
this
point.
Q
The
document
and
I
just
wanted
to
highlight
that
the
objective
is
an
information
RFC
and
we
don't
want
to
have
be
this
an
exhaustive
document,
but
rather
and
like
a
position
paper
right
X.
So
the
question
for
me
to
judge
if
this
document
is
ready,
is
if
you
read
it,
you
should
think
to
yourself:
does
it
provide
enough
convincing
arguments
and
not
is
it
a
complete
list
of
you
know
all
the
papers
out
there
and
everything
so
right.
F
So
the
chairs
actually
inclined
to
you
know
last
call
this
pretty
soon.
So
I
think
this
has
been
around
for
some
time.
You
have
received
comments.
They
are
incorporated.
Okay,
so
I'm
like
today,
you've
got
one
additional
thing
you
sure
might
want
to
do
sure.
So
that
could
be
the
last
thing
you
do.
You
can
do
revision
and
then
we,
okay.
F
F
Q
F
Q
Q
F
R
Okay,
great
so
hi,
my
name
is
jenkin
I'm
from
Hamilton
we
are
presenting
our
yeah.
That's
the
first
presentation
of
our
party
subscribe
Department
option
for
the
Indian
in
constraint
networks.
So
if
you
look
at,
for
example,
that
use
cases
or
IOT
scenarios
where
we
have
very
low
or
resource
constrained,
IOT
devices
and
especially
content
that
is
produced
as
a
result
of
events,
let's
take,
for
example,
in
this
room.
R
So
what
else
do
we
have
I
mean
in
a
request
rhythm
paradigm?
Should
we
employ
a
push
mechanism?
Well,
I
think
you
all
know
that
pushing
in
and
the
N
is
a
very
delicate
topic
and
if
you
yeah
scheme
out
this
push
mechanism
wrongly
or
if
it
fails,
then
you
break
the
ND
n
beloved
flow
balance
that
we
have,
or
you
create
cache,
poisoning
scenarios
or
even
in
area
of
service
in
these
IP
networks.
R
So
we
should
stick
to
the
NBN
request
response
scheme
for
our
approach,
and
this
is
what
actually
we
proposed.
So
we
have
a
publish/subscribe
option
that
propagates
the
information
that
is
generated
by
events
in
a
timely
fashion
or
immediately
actually
to
some
sort
of
control,
unit
or
I'll,
say
it
and
we
call
it
the
content
proxy
in
this
case
and
the
data
is
explicitly,
data
is
not
pushed.
R
This
is
what
I
want
to
highlight
here,
so
we
deploy
or
we
employ
a
control
plane
in
which
we
yes
signal
the
name
that
is
about
to
be
what
that
was
triggered
and
after
receiving
this
signaling,
which
is
just
link
locus.
So
it
is
just
the
name
singling
to
the
next
neighbor
and
after
receiving
this,
then
the
information
is
requested
in
a
yeah
request,
for
whom
way-
and
this
is
then
repeated
at
top-
was
analyzed
fashion
until
the
until
the
the
data
is
replicated
to
the
content
proxy.
R
So
I
will
go
into
this
in
detail
for
our
option.
We
are
focusing
on
certain
topology,
which
is
actually
a
sink
tree
that
we
built,
or
that
is
routed
from
a
on
the
content
proxy,
and
there
are
working
groups
showing
that
actually
a
sink
tree
or
the
role
working
workhorse
at
otech
is
actually
very
efficient
in
the
IOT
scenarios,
because
we
have
an
m21
communication
where
m
sensors
talk
to
or
the
information
from,
M
sensors
propagates
to
to
one
source.
R
So
what
we
do
is
we
built
this
century
by
propagating
prefixes
or
prefix
names
on
the
control
plane
and-
and
this
is
like
I
said
before-
just
a
linked
local
communication.
So
this
is
broadcasted
and
we
call
it
Pam,
the
prefix
that
has
a
message
and
the
Pam
is
broadcasted
into
the
neighborhood
and
once
the
neighbor
receives
this,
it
also
joins
the
tree
and
repeats
this
process
in
a
hopeless
fashion.
R
So,
let's
go
to
the
publish
when
information
is
generated
or
data
needs
to
propagate
to
the
content
proxy.
What
we
then
do
is
we
advertise
this
name?
For
example,
here
we
have
as
the
temperature
at
10
a.m.
that
is
generated,
and
we
use
nem
messages.
We
call
them
name
advertisement
messages.
This
is
again
just
on
the
control
plane
and
linked
scoped,
so
the
name
is
received
by
the
upstream
neighbor.
This
is
a
unicast
message.
This
is
received
by
the
upstream
neighbor.
R
G
I
ask
a
clarifying
question:
yes,
because
maybe
other
people
didn't
misunderstand
this
drift
nearly
as
badly
as
I
did
okay,
but
in
most
of
these
other
designs,
the
control
plane
is
something
that's
running.
On
top
of
the
data
plane,
not
in
parallel
to
it
so
you're
defining
something
that
is
not
running
on
top
of
the
standard
ICN
data
plane,
because
it
doesn't
have
the
same
semantics.
So
this
is
running
directly
on
top
of
layer
n
minus-1.
In
parallel
with
the
request
response
paradigm
of
the.
G
R
G
G
R
N
N
M
Yes,
it
is
not,
it
is
not
an
interest.
Message
is
not
an
IC
end
data
message:
it
doesn't
follow
the
interest,
data
semantics
and
well,
that's
probably
a
question
of
naming
I'm
a
bit
confused
that
you
say
it's
difficult
to
understand
how
to
to
find
this.
A
control
plane,
I
mean
I
I
mean
maybe
we
can
take
it
offline,
but
I
would
consider
this
a
classical
control
plane,
but
anyway,.
R
Yes,
so
the
objective
was
to
not
overload
the
semantics
of
the
interest
packet,
which
requires
the
data
in
return.
So
we
do
this
link
local
scope
signaling
to
to
the
upstream
rota,
which
is
in
the
fib
from
from
the
first
process
and
after
receiving
this
advertised
name,
then
the
information
or
the
content
is
requested.
Where
content
we
are
interested
in
data.
R
E
N
E
Which
they've
published
content
and
all
and
they
might
have
different
names?
So
in
that
case,
if
you've,
the
aggregator
really
wants
to
reach
one
of
those
devices
and
full
content
out
of
it,
then
you're
going
to
end
up
with
the
order
of
number
of
the
embedded
nodes
in
the
constraint
domain.
This
I
guess.
M
Rings
settled
a
little
bit
misleading.
You
have
one
one
flippant,
reaper,
prefix
or
of
a
prefix
aggregation
point,
which
is
the
country
content
proxy.
So
if
you
actually
have
different
namespaces,
then
you
have
different
entries
in
the
fib.
But
the
point
here
is
all
names
aggregate
that
that
have
a
say
the
common
prefix
aggregate
clearly
aggregate
to
this
content
proxy.
So
you
have
per
prefix
only
one
entry
in
the
fit
yeah.
That
is
then
a
sort
of
a
prefix
specific
default
world.
So.
E
R
Great,
so
what
then
happens
we
propagate
the
data?
Twice
I
mean
we
just
repeated
iteratively
until
the
contents
receipt
at
the
content
proxy.
So
now
the
content
proxies
contains
the
the
information
that
was
published
and
now
the
beauty
of
this
is
if
another
node
wants
to
ask
for
this
information
or
subscribe
subscribes
to
this
particular
name
in
the
novel
India
North.
R
The
Pitti
entries
will
leave
the
breadcrumb
back
to
this
node
and,
due
to
the
due
to
the
default
prefix
routing
that
we
have,
he
subscribed
or
the
this
is
another
interest
message
which
moves
along
the
gradient
towards
towards
the
content
proxy.
There
is
no
other
way
to
go
so
the
content
proxy
will
receive
this
interest
and
if
the
publish
or
if
the
information
that
is
asked
is
not
there
yet
I
mean
it
will
stay
open
till
the
intercept
times
out.
So
if
the
publish
or
the
replication
receives
its
receiver,
the
quantum
proxy.
R
R
But
this
is
like
Thomas
said
this
is
a
different
name
spacing,
so
we
use
in
this
in
this
prefix
name
that,
if
you
use
content,
is
not
to
be
pulled
from
quantum
proxy,
of
course
you
can
run
something
parallel
where
you
differently,
pantries
and
and
different
naming
schemes
for
names
that
must
be
both
by
the
condo
proxy,
but
porting
is
not
something
that
we
want
to
do
here.
Okay,.
G
Quick
question:
why
did
you
discard
the
idea
of
just
doing
an
interest
interest
data
exchange?
Why
we
did
this?
Why
did
you
discard
the
idea?
That's
been
around
for
a
long
time
of
just
doing
an
interest
interest
data
exchange?
Well,
the
interest
interest
rate
is
I
mean
you
in
okay,
the
interest,
in
other
words,
the
publisher,
sends
an
interest.
R
G
The
towards
the
the
namespace
that
the
CP
knows
about
and
our
when
it
gets
it
that
interest
contains
the
name
of
the
thing.
The
CP
should
go
at
issue
an
interest
for
down
to
the
publisher
yeah.
The
first
interest
is
thrown
away
right
and
then
the
one
comes
back.
The
other
way
it
seems
like
you're
hop-by-hop
protocol,
basically
reintroduces
all
of
the
push
problems.
They're
just
localized
well,.
I
G
G
Know
we
already
have
to
build
boss,
protection
and
congestion
control
for
interest
messages.
Now
we
have
to
build
another
mechanism
to
do
the
same
thing
for
this
hop-by-hop
scheme,
okay,
sis
so.
R
It
you
propose
that
this
namsan
terms
that
we
introduced
on
the
lower
there
should
be
interest
interest
our
interest,
data
and
ruse
data
mechanisms-
I
mean
so,
but
it's,
but
it's
still
generating
a
little
bit
more
traffic
than
this
approach.
But
I
think
this
is
good,
discuss
discussion
that
we
can
keep
further
on.
So
the
beauty
of
this
approach
is
once
we
have
this
hope,
wise
replication
and
in
a
wireless
network
or
in
constraint,
networks
in
wireless
media.
R
We
have,
of
course,
a
lossy
link,
so
information
can
go,
you
can
be
lost,
so
the
thing
is
that
we
have
with
this
approach:
publisher,
mobility,
so
once
because
it's
a
hopper
hopper
supplication,
once
we
the
know
detects
that
this
information
is
not
replicated
because
there
was
no
interest
requesting
for
this
data.
We
can
just
reposition
the
tree
or
degrade
into
another
position
and
take
this
enter
a
new
food
pantry
into
into
the
flip
and
try
the
publishing
wind
again.
E
R
Are
not
pushing
data.
This
is
saying
we
single
names
on
the
so
called
control,
plane
and
and
in
response
of
this,
of
receiving
the
this
kind
of
signaling,
we
request
the
name.
Well,
it's
still
up
to
the
to
the
router,
of
course,
if
it
wants
to
request
a
name,
but
this
approach
requests
the
name
immediately.
So.
R
M
It's
probably
easier
than
then
I
mean
what
you
do.
Is
you
tell
that
there
is
an
entity
which
you
use
a
name
entity
which
you
usually
would
do
in
a
routing
protocol.
So
that's
why
we
call
it
a
control,
plane
message,
but
you
do
it
this
only
link
locally.
So
you
are
not
in
the
situation
that
you
can
DDoS
any
node
in
the
network.
M
You
can
only
tell
your
neighbor
and
since-
and
we
had
this
discussion
a
little
bit
with
Dave
already
since,
since
you
always
can
can
flood
a
wireless
link,
this
actually
doesn't
doesn't
introduce
any
new
attack
vector
on
the
network
layer
because
you're
you're
not
getting
beyond
the
next
stop.
That's
and
you
get
these
things
that
which
what
changed
just
a
drastic
splaying
the
mobility
and
the
partition,
tolerance,
which
you
don't
have
if
you
had
actually
signal
path
over
the
network.
R
Up
and
we
propose
yeah
deployment,
option
second
option
which
replicates
data
hop-by-hop
it
decouples
not
just
in
time
and
space.
It
also
recovers
in
synchronicity.
This
means
information
or
the
authority
of
information
is
given
up
to
the
quanta
proxy.
If
information
is
asked
by
any
entity,
the
quadrant
proxy
will
be
asked
first,
or
will
the
earth,
because
the
fifth
point
to
the
quantum
proxy?
R
So
this
means
that
nodes
can
sleep
after
publishing
the
information
they
don't
have
to
wake
up
for
every
interest
that
is
made
and,
of
course,
I
showed
you
that
producer
mobility,
and
yet
he
can
lie
characteristic
in
the
disability
of
resilience
and
partition
networks.
And
of
course
we
have
a
minimal
fib
state.
Here
we
did
did
some
experimental
evaluation.
You
say
right:
the
operating
system
for
the
IOT
and
using
CC
a
night
which
is
a
lightweight
implementation
of
different
Island
dialects,
including
Indian.
R
So
we
used
an
NBN
on
right
and
this
in
a
large-scale
test
that
the
IOT
dev
test,
that
with
up
to
over
hundreds,
three
hundreds
of
nodes,
three
nodes
in
constraint,
environment-
and
it
looks
quite
promising.
I,
don't
have
the
results
here
with
me,
but
I
can
share
them
on
the
on
the
list
or
the
next
presentation
of
this,
then
we
received
thanks
to
Dave
a
lot
of
comments
some
weeks
ago
to
the
zero
version
of
this
raft
and
I.
Think
Dave.
R
E
On
the
producer,
mobility
thing
so
you're
not
talking
about.
Basically
those
nodes
are
not
having
global
names
right
they
just
having
local
names
so
basically
I'm
monitoring,
a
truck
fleet
and
basically
the
truck
I,
have
to
monitor,
get
sensor
data
from
the
truck.
So
basically,
you
probably
would
give
a
global
name
to
that
truck
so
you're,
because
mobility
cannot,
if
you're
doing
in
bringing
actual
infrastructure
into
the
picture.
There
are
different
ways
you
have
to
handle
mobility.
So
I
see
your
mobility
somewhere
limited
to
local.
R
R
E
R
M
E
R
Thanks
so
to
move
on,
there
was
another
question
from
Dave
talking
about
whether
contact
proxy
is
a
repo
or
cache,
and
the
recorder
proxy
is
a
cache
with
guarantee
us
guarantee
cache
with
lifetimes
for
the
published
content.
So
there
was
a
learn.
Another
long
question
from
from
Dave
regarding
whether
our
proposal
is
like
analysts
are
or
or
Kronos,
Inc
and
I
mean
explicitly.
We
are,
we
are
making
distance
vector,
routing
and
not
link
state
routing.
R
N
R
Can
discuss
later
so
the
the
draw
statuses?
It's
still
in
the
only
state,
the
missing
parts
in
the
raft,
and
we
need
to
work
on
this
and
we
have
to
work
out
that
the
packet
header
thinks,
whether
we
go
and
on
this
layer
or
using
the
interstate
or
intrastate
approach
and
the
subscriber
needs
to
the
boy
elaboration.
So
we
will
provide
a
major
version.
Soonish
weather
at.
A
Thank
you,
I
think
we
have
two
very
interesting
discussion
here
and
I
think
it
would
be
very
good
if
you
could
continue
this
discussion
on
the
mailing
list,
the
people,
so
you
get
some
kind
of
conclusion
of
that
discussion
before
do
the
next
version
of
the
draft
I
think
that
will
be
very
useful.
Okay
thanks,
okay,
thank
you.
I
A
Sir
yeah
Rob
yeah
so
I
want
to
say
that
that
the
good
thing
is
that
that
we
have
had
a
very
interesting
discussions
here
today.
The
bad
thing
is
that
we're
doing
pretty
bad
on
timing
robbery
you
have,
but
the
good
thing
is
that
it's
your
free
drafts,
yeah
I,
don't
know.
My
proposal
is
that
you
focus
on
the
notification
draft
and
we
the
the
other
RIT
drafts.
We
have
had
discussions
on
many
times.
You
can
continue
that
discussion
on
the
mailing
list.
Maybe
that.
E
E
So
we
have
some
of
the
collaborators
from
that
space
also
here,
so
this
Jeff
primarily
talks
about
having
this
new
semantics
of
push
in
in
IC
and
in
CC
and
indian
networks.
So
I
mean
there's
been
also
some
related
paper
in
in
the
last
year.
Sitcom
I
mean
III
point
this
paper
out
because
it's
just
to
bring
the
point
just
because
you
can
do
some
flow
control
at
the
endpoints
and
flow
balance.
It
doesn't
mean
you
have
congestion
control.
E
Apart
from
the
faster
ones,
and
then
those
caches
are
useless
and
your
retransmitting
the
content
and
consisting
the
links,
so
you
need
more
machinery
just
because
flow
balance
is
there
that's
a
good
framework
to
have,
but
more
measuring
is
required
to
actually
win
with
the
simple
interest
data
model
to
actually
get.
You
want
to
use
a
network
fairly
among
different
flows
and
to
ensure
that
you
have
end-to-end
application
rate.
E
That
is,
that
is
in
such
a
way
that
it
doesn't
slow
down
the
produce
or
a
lot
to
the
slowest,
pursuers
receiver
and
so
on
so
forth.
So
so
in
that
sense,
I
mean.
So
since
then,
in
the
last
presentation
we
made
the
comment
from
the
chairs
was
to
say:
you
know
why
this
interest
data
abstractions
fail
and
that's
what
we
try
to
address
in
this
particular
in
this
particular
revision.
E
So
so
yeah
so
I
mean
even
of
course,
in
the
so
vision
we
had.
We
included
a
lot
of
discussion
or
on
fluent
congestion
control
and
some
of
the
work
they
said
work
and
all
that
fundamentally
says
that
Jews
can
be
applied
to
actually
you
can.
You
can
leverage
them
to
to
control
notifications
in
the
network,
so
so
this
is
the
outline
of
the
draft.
E
I
will
mostly
stick
to
the
the
main
kind
of
discussion
points
where
probably
you
can
also
provide
a
feedback,
but
this
is
a
main
motivation
here
to
say
that
you
know
you
have
IOT.
Most
of
the
data
is
going
upstream
compared
to
others.
Normally
smart
devices
and
I
think
the
main
motivation
comes
from
applications
like
the
URL
LC
application
that
you
have
in
5g,
so
this
class
of
application
require
very
low
latency.
E
They
are
talking
you're,
expecting
some
because
you're
talking
about
this
vehicle-to-vehicle
autonomous
driving
kind
of
situations
and
one
to
ten
millisecond
and
absolutely
kind
of
zero
kind
of
packet
losses
and
stuff.
And
of
course
you
have
an
entire
industry
that
fundamentally
depends
upon
pub/sub
systems
and
even
IOT
systems.
You
know
most
of
them
things
like
MQTT
they're,
all
based
on
this
kind
of
application,
fundamentally,
that
the
fact
that
that
messages
himself
data
itself
is
produced
at
random
intervals,
and
so
the
only
thing
you
can
do
is
an
efficient
way.
E
Yeah,
so
I
know
so.
You
have
I
mean
there
are
some
other
proposals
of
the
ICN
protocols
that
fundamentally
support
both
push
and
pull
so
I
just
wanted
to
say:
I
mean
this
probably
could
be
something
that
might
be
demanded
out
of
ice
in
protocol
toast.
So
the
main
thing
here
is
I
mean
some
of
the
requirements
we
listed
here
is
that
you
have
to
support
the
push
intent.
E
So
when
you
are
actually
pushing
out
the
data
it
has
to
reach
the
set
of
receiver
sets
it's
intended
to
support
multicast
security,
and
you
should
be
able
to
get
all
the
security
feature
that
you
have
in
a
normal
name.
Data
object,
routing
and
forwarding
support
in
the
sense
that
you
should
treat
it
separately
from
pull
where
you
can
actually
do
different
forwarding
strategy
mechanisms
to
and
basically
learn
from
where
the
data
is
coming
from
instead.
E
So
here
you
may
not
have
any
response,
you're
just
pushing
data,
because
you
just
just
subscribed
once
and
you
want
to
push
it
out
and
you
want
to
minimize
processing,
should
be
subjected
to
in
minimal
bit
and
CS
processing.
You
avoid
this
involving
the
them
in
the
in
the
in
the
day
in
the
message
processing
pipeline
to
ethically
it
is
again
to
to
ensure
its
its
it's
meeting.
The
need
for
what
you
want
to
do
with
that
thing
is
to
pushed
it
out.
E
So
there
are
four
basic
approaches
that
we
define
in
this
draft
and,
as
I
said,
the
main
changes
has
been
in
this
section
of
using
inter
data
abstraction
for
push.
So
you
have
long
lived
interest.
You
have
polling
that
Schenk
was
talking
about.
You
have
overloading
interest
and
interest
figure
that
they
was
talking
about,
and
so
most
of
the
discussion
that
we
provided
in
this
draft
is
in
the
context
of
a
normal
infrastructure,
where
you
have
multiple
providers
and
their
multiple
consumers
and
they
are
all
operating
under
the
given
group
perfect.
E
E
Okay,
if
you
have
this,
you
have
this
n
number
of
providers
for
using
data
and
the
producers
themselves
are
not
in
sync
with
one
another
and
you
you
basically
I
mean
the
consumers
can
ask
data
based
on
the
fact
that
they
are
being
generated
in
a
sequential
manner.
So
the
only
way
you
can
actually
get
the
data
because
you
don't
know
which
content
ID
is
being
provided
by
which
producer
is
to
actually
kind
of
multicast.
This
interest
out
to
all
the
providers
out
there.
So
there
are
inefficiencies
with
this
solution.
E
Is
that
as
I
said,
that
you
have
you
fundamentally,
you
have
to
to
send
out
all
this
interest
increases
the
fundamental
pitch
state
and
the
main
important
thing
is
that
because
data
is
only
coming
from
one
of
the
providers,
you
have
a
lot
of
redundant
pitch
states
lying
in
the
network
that
may
not
be
consumed,
and
the
other
thing
is
that
how
do
produces
themselves
sync
among
themselves
right?
So
that's
another
syncing
problem
or
another
notification
problem.
E
So
unless
you
solve
the
first
problem,
you
cannot
really
solve
the
second
problem
right
I
mean
if
you're
doing
this
in
the
push
model.
All
you
do
is
that
group
IDs
I
mean
the
names
can
be
purely
immutable
based
on
either
content,
I
content,
hashes
or
something-
and
you
just
you-
would
push
that
content
out
into
the
network.
E
So
this
is
with
long
live
interest.
So
the
way
you
address
this
is
that
okay,
you
instead
of
having
this
long
live
interest
and
having
this
state
in
the
pit.
You
can
do
it
by
that.
You
can
do
it
by
pulling
right.
So
what
shrink
mentioned?
Was
you
you
pull
the
network
so
here
polling?
Would
fundamentally
mean
by
saying
that,
okay,
you
have
this
set
of
providers,
and
fundamentally
we
are.
A
B
E
But
the
basic
problem
with
this
approach
is
that
it
leads
to
message
losses
because
they,
because
you
most
definitely
don't
know
exactly
at
what
instances
the
the,
because
they
are
fundamentally
separated
in
time
and
space.
So
they
don't
know
exactly
what
instances
they
are.
Basically,
the
content
has
been
generated
and
there's
a
good
chance
that
you
might
lead
to
message
losses
in
this
game.
E
So
the
other
thing
is
you.
You
can
avoid
that
problem
by
saying
that
okay,
I'm
I'm
not
going
to
have
this
producer
sync
with
each
other,
but
I'm
going
to
give
different
namespace
each
one
of
these
producers.
And
now
you
basically
give
a
provider
ID
as
one
of
those
one
of
the
name
components
and
they
start
they
start
publishing
under
the
under
that
name.
E
So
your
query
would
be
straightforward,
but
the
key
thing
here
is
that
now
the
solution
becomes
more
like
a
host
centric
thing,
because
the
producers,
consumers
have
to
know
all
the
producers
out
there.
It
avoids
all
the
packet
losses
fundamentally
because
you
can
kind
of
pipeline
this
interest
and
you
can
get
all
the
data,
but
it
still
doesn't
solve
the
problem
of
having
this
bit
state
because
of
long
live
interests.
E
And
the
other
problem
is
that
if
you
say
that
the
group
ID
itself
is
shared
among
multiple
devices,
it
goes
back
to
the
problem
of
having
long
live
interest.
Where
this
group
I
this
devices
under
the
group
have
to
now
sync
somehow
to
make
sure
that
the
the
the
names
themselves
are
basically
there's.
No,
they
are
not
using
the
same
names
to
produce
content,
so
the
the
other,
the
way
you
could
avoid
this
is
again
going
back.
E
Okay,
you
are
giving
this
provider
IDs
and
group
IDs
to
different
providers,
but
now
you
start
producing
them
under
different
time
stamps
and
the
query
would
be
to
basically
give
so
here.
Basically,
you
are
doing
things
mostly
at
the
some
kind
of
an
application
level,
you're
sending
up
interest
with
a
certain
nonce
and
basically
give
content
of
a
given
amount
of
time.
So
in
this
particular
case
you
are
now
they
applied
the
application
layer,
you're
aggregating
bunch
of
interests
and
then
you're
responding
to
be
to
the
consumers
request.
E
E
So
this
thing
on
basically
saying
that
now
I
could
have.
Instead
of
saying
that
producers
need
to
know
all
the
providers,
I
will
have
one
say
some
some
proxy
server.
The
producers
themselves
will
will
publish
to
the
server
and
then
I
just
know
the
server
and
get
the
content
from
it.
But
again,
this
and
server
will
offer
some
kind
of
aggregated
response,
but
then
this
goes
into
the
same
IP
model
where
the
server
becomes
a
single
point
of
failure.
E
You
again,
the
caches
are
not
useful,
as
in
the
previous
case,
and
it
kind
of
boils
down
to
a
host
centric
approach.
Okay,
so
this
is
the
other
thing
about
interest
overloading.
So
in
saying
that
with
interest
overloading,
what
you're
saying
is
that
I
would
put
the
payload
into
my
interest
messages
and
send
it
out.
So
this
fundamental
issue
here
is
that
now
the
routing
and
forwarding
has
to
suffer
no
meant
to
differentiate
between
between
the,
where
you're
actually
pulling
content,
where
you
are
actually
pushing
out
consumer
again
somewhere.
E
You
know
this
again,
because
these
are
pushes
you
know
the
fibs
are
somehow
coming
from
the
endpoints
and
that
should
fundamentally
reach
all
the
providers.
So
that's
where
the
routing
implication
comes
from
again.
The
issue
is
that
you're
always
engineering
the
network
for
certain
size
of
interest.
E
Applications
in
triggers
have
to
reach
all
the
receiver
endpoints,
so
you
still
have
the
routing
and
forwarding
challenges
and
the
trigger
names.
Okay,
so
the
trigger
name
space
have
to
be
carefully
defined.
Okay,
so
design
here
so
are
the
parts
of
the
draft.
We
have
not
changed
here,
things
on
protocol,
semantics
flow
condition,
control,
discussion
and
there's
one
use
case.
We
show
how
you
could
use
the
vacation
for
pub/sub,
so
those
fundamental
things
have
not
been
touched
so
questions
here
and
and
any
comments
on
the
track.
E
What
is
the,
what
is
your
plan
with
this
draft?
I
mean
I
would
definitely
like
to
see
this
somewhere
get
because,
as
I
said,
like
flow
balancing
by
itself
just
gives
you
a
first
step,
but
you
need
some
other
mechanisms
to
handle
condition,
control,
that's
what
the
paper
actually
indicates
so,
but,
as
I
said,
you
definitely
need
some
other
mechanism.
E
If
you
have
notifications
you
have
to,
but
some
of
the
mechanisms
that
the
set
papers
designs
where
they
actually
are
sending
that
window
information
from
the
consumers
into
the
network
to
control
the
data
that's
flowing
down
or
to
get
the
best
application
rates
to
the
receivers.
Those
things
can
be
easily
applied
in
this
case
too
so
I
mean
this
is
this
is
what
I
want
to
understand
this?
E
They
don't
solve
the
case
of
where
you
require
this
machine,
critical
updates
and
notifications
and
stuff,
and
to
say
that
now
we
should
be
practical
in
the
sense
that
considering
IOT
and
the
social
networks
out
there
with
people
who
are
actually
building
the
systems
would
be
happy
with
just
having
these
one
abstractions
to
support
all
the
applications.
So
for
me,
from
my
perspective,
application
requirements
come
first
of
course,
then
you
have
to
engineer
the
network
to
make
sure
that
the
security
and
and
the
and
the
condition
control
mechanisms
are
taken
care
of.
M
Tomas
for
member
I
pretty
much
agree
mated
with
most
of
what
you
said
on
the
in
the
presentation,
but
it
doesn't
really
exist.
I
mean
it
doesn't
really
seem
to
fit
to
the
title
of
the
draft.
I
mean
I
would
consider
the
title
of
the
draft
would
be
better
something
like
problem
statement
and
briefs
away
or
something.
Oh.
E
E
We've
talked
to
Park
and
we
discuss
this
notification,
and
so
it
was
actually
proposed
kind
of
extension
to
the
CCR
next
protocol.
But
then
you
know
the
thing
literally.
Then
it
took
I
think
more
a
research
direction
where
we
added
the
flow
condition,
control
yeah,
definitely
I
can
work.
I
can
change
that
to
put
it
as
research
directions
and
had
then
stuff
to
make
it
a
broader
scope
and
stuff,
but
I
think
definitely
you
know
there
is.
There
is
there's
this
good
community
that
is
looking
into
this
problem
and
suggesting
different
ways.
E
F
Ok,
I
think
we
most
of
us
would
agree
that
say
asynchronous
notification
and
push
that's
one
of
the
interesting
in
crucial
topics
for
for
ICN,
and
there
are
really
different
approaches.
So
you
mentioned
data
sets
orientation,
interest
interest.
All
these
things
I
think
it
would
be
good
to
kind
of
you
know,
keep
working
on
this
talking
minute.
Maybe
I
am
so.
People
are
still
working
in
this
field.
So
I
think
that
this
could
for
some
time
be
like
a
living
document.
Perhaps.
E
E
E
E
So
this
is
fundamentally
kind
of
kind
of
spending
lot
of
the
time
in
to
basically
give
people
a
motivation
on
solutions
that
can
be
around
to
serve
those
kind
of
functions
and-
and
basically
we
also
provide
a
lot
of
discussion
around
how
NDMC
CC
and
our
mobility
first.
There
are
this
two
protocols
we
consider
in
specific
discussions
related
to
that.
E
So
again,
we
have
collaborators
here,
I
mean
focus
folks
who
are
in
IOT
space,
and
we
have
P
folks
who
are
doing
kind
of
more
something
that
I
know
LC
name
resolution
system
and
we
have
people
who
work
from
the
indian
space.
So
both
those
opinions
and
kind
of
solutions
are
being
pursued
are
being
reflected
in
this
job.
So
so
the
main
change
from
I
mean
we
lot
of
changes
are
specifically
spread
around
the
draft,
but
we
kind
of
in
the
section
4.1
we
kind
of
separate.
E
We
had
only
initially
device
discovery,
but
we
added
one
section
on
device
onboarding
and
discovery
because
they're
fundamentally,
two
different
things.
So
when
you
do
something
like
onboarding
of
devices,
it's
it's.
Basically,
you
want
to
it's.
It's
movie
about
authenticating
the
device
that
is
coming
into
the
network
and
the
network
called
the
device
authentication
to
the
network
and
network
also
authenticates
to
the
device.
So
that's
the
onboarding
one
and
the
discovery
is
when
you
are
actually
announcing
to
the
network
somewhere
that
ok,
this
device
is
there,
and
so
you
can
route
to
this
device.
E
You
can
pull
content
from
this
device.
So
that's
where
my
question
for
Schenk
was
in
most
of
the
this
argument.
Discussions
we
have
in
the
device
onboarding
you
actually
give
a
name
to
the
device
right.
So
you
actually
say
this
is
this
is
a
thermostat
or
basically,
if
those
names
could
also
be
actually
coming
from.
The
actual
agree
later
point
itself.
So
but
this
the
sizes
I
mean
if
you
want
to
get
data
from
that,
it's
actually
operating
on
different
namespaces,
and
you
also
have
some
touch
mechanisms
actually
routed
on
that
namespace.
E
So
so
that's
where
my
question
was
earlier
so
anyway.
So
this
is
the
mostly
the
outline
of
the
draft
there's
a
lot
of
material
in
this
draft
I
mean
it's
good
for
code.
Some
people
could
comment
and
and
basically
tell
us,
you
know
how
we
could
improve
it,
but
I'll
just
go
through
the
updates
of
this
draft.
So
we
we
presented
this
in
96
ITF
and
then
we
have.
We
didn't.
We
haven't
received
any
feedback
yet,
but
we
did
a
revision
of
it.
E
Considering
I
see
an
IOT
there's
a
lot
of
work
going
on
the
last
three
four
years
and
some
of
it
is
reflected
in
this.
So
as
I
said,
this
is
design
consideration.
This
is
kind
of
follow
up
from
the
design
consideration
stuff.
We
basically
consider
a
typical
IOT
system
architecture
I
see
in
base
middleware
functions,
so
we
discussed
the
middle
wave
functions
to
achieve
secure
self
configuration
and
scalability
to
accommodate
many
IOT
devices.
E
Again,
we
provide
high-level
solutions
as
well
as
kind
of
specific
mechanisms
that
endian
that
you
can
do
an
NT
and
CCN
and
also
from
the
mobility
first
perspective
for
specific
middleware
protocol
solutions.
These
are
also
discussed
in
the
draft,
so
the
main
one
of
the
things
that
we
change
in
this
I/o
I
see
an
IOT
system
architecture
is
they
are
the
we
added
the
authentication
manager,
because
that
is
a
very
important
component.
When
you're
talking
about
onboarding
devices,
I
mean,
but
it's
it's
still
a
kind
of
a
function,
a
service
function.
M
E
Yes,
so
it's
really
similar
I
mean
you
have
embedded
systems
that
they
can,
if
you
want,
they
can
mesh,
or
they
can
also
form
a
tree
to
the
aggregate.
It's
very
similar
to
what
the
earlier
presentation
was,
and
then
you
have
a
local
service
gateway.
The
local
service
gateway
is
within
the
local
domain
boundary
and
then
per
me.
It's
a
border,
router
kind
of
a
thing,
and
then
it
basically
interconnects
to
this
service
gateway.
E
Sorry
it
can
into
it
connects
to
the
kind
of
the
infrastructure,
and
then
you
have
the
authentication
manager
which
can
be
actually
within
the
local
domain
or
outside
in
the
internet
kind
of
thing.
And
then
you
have
consumers
and
services
that
is
asking
for
the
content
that
is
being
generated,
so
that
goes
to
the
actual
network
infrastructure
network
and
basically
comes
out
so
I.
Look
at
the
IOT
IOT
server
can
be
I
mean
you,
so
this
is
basically
assuming
that
you,
because
in
IOT
you
can
do
lot
of
hierarchical
processing.
E
E
So
that's
where
we
have
large
scale
like
van
level
of
sub
kind
of
systems
lying,
but
you
can
also
have
data
that
is
being
consumed
within
the
local
domain,
like
the
embedded
systems
that
is
connected
to
one
aggregator
might
talk
to
another
aggregator
to
get
the
data
from
its
own
embed
system
or
something
so
you
can
have
local
level
local
domain
communication
as
well
as
you
have
infrastructure
level
communications.
It
covers
both
the
spoke
aspects
here.
N
P
K
E
P
E
P
P
E
You,
oh
this
one.
This
is
simply
a
system
architecture,
I'm
not
showing
I
mean
I'm,
not
specifically
going
into
the
protocol
details
or
specific
naming
functions
here
so
I
mean
this
is
simply
saying
that
this
is
what
a
typical
IOT
system
looks
like
I
mean,
irrespective
of
whether
it
is
today's
system
or
ICN
system.
They'll
all
have
the
similar
set
up.
So
that's
all
this
is
strengths.
A
let.
P
S
P
J
A
P
P
N
E
So,
of
course
yeah
you,
you
basically
name
it
so
I
mean
we
talk
in
terms
of
naming
offering
namespaces
under
which
I
mean.
So
when
you
talk
about
IOT,
we
say
that:
okay,
you
could
name
devices,
services
and
content,
okay,
so
the
thing
about
how
you
would
locate
that
name
to
a
particular
location
is
the
name
resolution
problem
right
and
there
are
different
ways
to
do
it.
So
here
mostly,
we
focus
on.
How
do
you
assign
names?
E
I
mean
when
you
talk
about
IP
context,
you
are
naming
interfaces
right
and
then
applications
also
tend
to
use
it.
But
in
here
we
are
basically
we
there's
a
clear
separation.
Icn
focuses
on
pro
giving
names
to
I
to
services,
content
and
devices,
and
then
you
can
basically
place
it
on
any
kind
of
transport.
G
Chair
hat
off,
so
this
is
personal
comment.
I
think
it's
at
least
a
year
and
possibly
three
years
premature
to
try
and
construct
a
system
architecture
for
ICN
IOT,
this
top-down
stuff,
it
presumes
an
awful
lot
of
things
are
decided
that
or
not,
and
we
need
a
whole
lot
more
bottom-up
work
on
each
of
the
individual
pieces
before
we
understand
what
kind
of
a
system
architecture
or
we
should
have.
If
any,
we
may
not
need
a
system
architecture,
a
single.
G
E
P
E
Okay,
I
mean
we
do
build
IOT
systems
and
I
mean
I.
Don't
know
why
this
this
is
there's
so
much
of
this
with
this
system
setup,
because
this
is
a
very
typical
system
to
stuff
in
any
IOT
sister
I
mean
whether
it's
IP
or
ICN
I,
don't
know.
Why
should
this
differ?
Because,
fundamentally
all
this
is
saying
that
you
want
to
kind
of.
F
E
But
the
key
thing
is
that
I
mean
what
we
discuss
it
I
mean
I,
mean
I,
don't
have
the
picture,
but
there's
a
picture
in
the
truck
where
we
thought
that
okay,
there
are
basic
functions
that
ICN
provides
in
terms
of
caching
or
in
network
computing.
That's
fundamentally
ICN
functions,
but
you
have
to
build
certain
basic
middleware
functions
like
what
we
discussed
in
this
draft
to
to
to
make
a
IOT
system
self
configure,
send
self
configurable
scale
and
to
do
last,
KL
content,
distributions
and
stuff.
So
that
is
the
focus
of
the
draft.
So
many.
E
E
E
Isolate
the
Gateway,
which
is
basically
at
the
border,
to
the
infrastructure,
but
this
is
like
you
have
several
aggregators
to
which
all
the
embedded
systems
are
talking.
To
so
I
mean
you
can
do
a
lot
more
optimization
there
to
ensure
that
battery
lives
and
all
things
that
kind
of
things
can
be
taken
care
of
so
yeah.
Basically,
you
can
see
there.
Doe
tags
for
the
RPL
will
hang
out
of
the
aggregators
right.
M
M
E
M
E
E
So
if
you,
if
your
data,
if
aggregator,
wants
to
get
the
data
from
embedded
system,
it
goes,
it
can
directly
go
from
one
aggregator
to
on
the
aggregator
to
the
embedded
system
or
go
home
the
aggregator
to
aggregate
and
pull
the
content,
because
you
probably
people
again
publishing
the
content
in
the
aggregator.
So
now
we
are
really
running
out
of
time.
I
E
So
this
is
like
I
said,
like
we
have
provided
more
discussion
on
device
onboarding,
and
so
there
are
lot
of
kind
of
sub
functions
that
we
that
we
we
discussed
under
this
like
device,
polling,
mutual
authentication,
key
generation,
discussion,
distribution,
protected
data
transfer.
We
provide
discussion
in
the
context
of
Indian
and
MF,
and
the
basic
assumption
here
is
that
the
embedded
system
is
coming
with
the
pre
shared
key
or
could
have
a
symmetric
key
to
bootstrap
the
whole,
basically
onboard
the
device
into
the
system.
So
we
talked
about
naming
service
device.
E
Discovery
gives
you
a
local
ID,
but
you
can
also
give
it
a
global
name,
and
the
names
can
either
come
from
the
preloaded
keys
like
the
for
self
certified
keys,
or
you
can
offer
names
with
the
certificates
from
the
from
the
authentication
manager
or
the
local
service
gateway
to
the
device.
So
that
fundamentally
gives
you
ability
to
do
global
communication.
E
We
talked
about
service
discovery,
discovery
I
mean
there's
a
discovery
between
the
embedded
system
and
the
aggregator,
but
this
audience
of
service
discoveries
between
the
aggregator
points,
and
you
want
to
do
secure
service
discovery
to
ensure
that
you're
only
allowing
legitimate
users
to
do
it,
and
there
are
discussions
on
that
also
context,
processing
and
storage.
So
this
context,
processing,
fundamentally
INSEEC
an
Indian.
E
You
have
name
networking
function,
name
function,
networking
in
mobility;
first,
there's
compute
layer,
the
fundamentally
it's
it's
about
talking
about
how
devices
can
expose
certain
contexts
to
the
to
the
into
the
network
layer,
and
then
you
can
use
the
application
level
context
to
match
with
it
and
so
and
to
basically
pulls
on
service
functions
and
to
produce
data
in
in
an
appropriate
manner
that
meets
those
context.
Queries
then
we
talk
about
pub/sub
management.
This
goes
into
the
previous
discussion.
Also
about
being
pulled.
E
E
So
I'm
done
here
so
there's
also
some
discussion
we
talked
about.
When
you
have
multiple
IOT
islands
with
different
naming
structure,
then
you
can
there's
a
proposal
on
an
intern,
Eames
kind
of
architectures
to
handle
those
kind
of
scenarios,
and
so
next
steps
I
just
said
there
I'm
sure,
there's
a
lot
of
comments
and
they've
come
in
this
premature
work,
but
I
think
we
will
definitely
keep
this
we'll
try
improving
this
draft
I'll.
Take
this
comment
and
probably
look
at
some
of
the
experimental
work.
E
A
Let's
just
check
who
has
read
this
draft
to
you:
the
latest
version
that
just
came
out
or
isn't
or
the
previous
any
version
of
this
craft.
So
it's
it's
just
a
few
hands.
So
if
you
think
this
is
interesting
work,
please
read
the
draft
and
comment
on
the
the
mailing
list
and
discuss
it
there.
If
you
have
other
ideas
of
how
the
research
group
should
address
this,
these
issues
will
also
glad
to
hear
them,
because
I
really
think
we
need
something
in
this
area.
A
E
As
I
said,
like
I
mean,
as
Lisa
was
saying
that
you
know
we
don't
have
the
bandwidth
to
do
all
kinds
of
applications.
We
do
build
systems,
but
if
there
are
I
mean
there
is,
there
is
J
who
was
doing
he's
an
Indian
collaborator
so
he's
we
have
a
lot
of
inputs
for
him,
but
if
other
Indian
folks
want
to
join
in
this
draft,
surely
yeah
and.
A
And
unfortunately,
we
don't
have
time
for
the
design
considerations,
but
I
just
want
to
do
sure
hands
on
that
one
also
who
has
read
the
Desai
III
design
consideration
drafts
any
version
of
it,
so
that
still
also
just
a
few
hands.
So
we
need
more
eyes
to
look
at
this.
We
need
what
you
think
about
it.
If
you
don't
think
this
is
the
right
thing,
we
need
other
ideas
how
how
to
move
along.
So
please,
if
you
think,
I
sent
an
IOT
is
something
that
can
be
useful.
O
N
O
Comments
about
you
know,
sort
of
an
overarching,
IOT
architecture
are
important
comments.
I
almost
wondered
whether
there's
you
know
some
other
places
within
the
broader
IETF
IRT
F,
where
there's
IOT
work
going
on
that
you
know
there
are
architectures
being
discussed
there.
Things
like
smart
object,
networking
being
discussed,
there's
security
considerations
being
discussed
and
there
needs
to
be
coordination.
There
yeah.
F
Robbie
so
IOT
and
I
and
I
see
any
that's,
really
an
important
topic,
and
we
basically
we
see
this
as
a
forum
to
facilitate
more
experiments.
So
if
you
are
doing
some
work,
please
feel
free
to
kind
of
tell
people
about
it.
It
doesn't
have
to
be
written
up
in
a
Hana
page
draft
or
something
I
mean
just
a
presentation
about
some
experiments.
Maybe
some
principle
idea.
That's
also
really
helpful.
I
mean
we.
We
don't
need
to.
You
know,
produce
documents
just
because
the
IETF
also
does
this.
F
So
we
are
really
interested
in
just
you
know
having
discussion
and
learning
things.
Okay.
So
with
that,
so
we
have
a
couple
of
things
coming
up,
so
there
will
be
the
ICN
conference
end
of
September
in
Berlin
and
especially
if
you're
interested
in
IOT
I
recommend
attending
that.
So
there
will
be
a
thing
to
thing
RG
meeting
on
the
weekend
before
there
will
be
a
riot
summit
so
directly
on
the
days
before
the
conference
and
we're
also
planning
to
have
an
icy
energy
interim
meeting
after
the
conference.
F
So
we
often
use
that
to
also
bring
new
people
to
through
this
group
and
also
maybe
to
have
presentations
about,
for
example,
presented
papers
at
the
conference,
but
go
to
a
bit
more
detail
and
have
a
bit
more
time
for
for
discussing
technical
aspects.
So
it's
normally
quite
quite
rewarding
these
meetings,
so
yeah,
please
consider
coming.
We
also
planned
to
meet
in
Singapore,
so
definitely
have
a
another
regular
meeting
during
the
week.
The
chairs
would
also
be
available
and
willing
to
to
go
for
a
a
weekend.
F
Sunday
meeting
depends
a
little
bit,
of
course
on
contributions.
What
people
think
we
should
be
discussing
and
so
on,
but
this
doesn't
definitely
an
option
doing
that.
Finally,
so
there's
and
I
frequently
communications
magazine
issue
coming
up
on
ICN
security.
So
if
you're
working
in
that
field
deadline
is
November,
1st
I
think
you
can
find
the
papers
and
everything
online
with
that
yeah.
We
are
done.
Thank
you
very
much
for
coming.
Thanks
to
all
the
polenta's
and
hope
to
see
you,
many
of
humulin
and.