►
From YouTube: IETF105-ICNRG-20190723-1000
Description
ICNRG meeting session at IETF105
2019/07/23 1000
https://datatracker.ietf.org/meeting/105/proceedings/
B
C
C
C
I
see
energy
has
the
usual
infrastructure,
we
have
a
main
list
and
a
wiki.
We
not
used
a
wiki
to
know,
publish
info
on
upcoming
meetings
and
so
on.
These
are
my
coaches
day
for
Ren
and
go
you
woman,
I'm
deaf
crucial
and
yes,
we
mentioned.
We
really
need
a
note-taker
to
start
this
meeting
and
note-taking
is
really
a
light
job
and
we
don't
catch
all
the
presentations,
just
the
question
and
answers.
So
that's
the
gist
of
the
discussion
and
there
are
no
big,
formal
requirements.
C
So
any
text
notes
what
we
find
out
thanks
a
lot
Janice,
that's
great!
Okay.
C
So
we
gathered
a
few
updates
about
what
happened
in
icy
energy
and
I,
see
em
in
general
moment
we're
not
talking
about
the
ICN
when
program.
Sorry
I
forgot
to
update
the
agenda,
so
Dirk
is
gonna.
Give
us
a
update
of
the
ICN
over
5g
draft
and
the
ICN
v
chillin
draft
Tasha
is
some
update
about
the
CCM
info
work.
C
D
E
C
Okay,
there's
a
there's,
a
story
to
live
up
to
this
photo
so,
as
you
may
have
seen,
the
RSC
editor
has
recently
published
you
see
sine
X,
cosine,
X,
semantics
and
message
formats.
So
thanks
to
the
great
work
of
the
authors,
Micmac
Moscow,
natural
solos
and
Chris
Wood,
this
is
now
officially
published.
C
Right
this
is
not
the
end,
it's
a
new
beginning,
okay,
yeah.
So
then,
let's
get
to
the
say,
updates
and
information
on
what
has
been
going
on
in
ICN.
So
we
had
this
interim
meeting
on
Sunday
if
you
couldn't
make
it
so
these
were
the
topics
that
we
discussed.
So
Christian
gave
us
an
update
about
his
his
ideas
on,
say:
yeah,
push
based
operational,
say,
push
based
application
semantics
and
how
that
could
be,
or
should
be
mapped
to
say,
I,
see
and
network
layers,
and
so
there
are
different
views.
C
C
That
could
be.
You
can
use
for
discovery,
for
example.
So
that's
the
idea
that
you
can
basically
attach
predicates
through
the
name
in
an
interest
packet
and
then
notes
that
support
this
feature
can
basically
yeah
gives
you
information.
Based
on
on
these
predicates,
we
havin
a
new
version
of
the
ipok,
so
IP
over
CCN
draft
by
Greg,
and-
and
so
we
want
to
adopt
this
as
a
research
group
item.
So
three
information.
We
would
also
do
the
usual
confirmation
on
the
main
list.
C
C
So
if
you
had
been
at
the
the
previous
IETF
meeting
it
and
at
the
ice
energy
meeting
there,
so
that
we
had
a
longer
discussion
about
ICN
and
Q
s
and
so
basically
exploit
the
potential
so
in
general,
the
idea
is
that
since,
when
I
see
em
you
first
of
all
you,
you
have
mooc
resources
that
you
can
control
that.
Allow
you
to
do
something
useful
for
4q
s
behavior,
but
also
you
have
potentially
more
expressiveness
in
the
protocol
so
and
the
names,
for
example,
to
actually
classify
flows,
for
example.
C
C
Two
minutes
resources
yeah
according
to
the
application
requirements,
and
so
that
presentation
had
some
interesting
results
so
basically
showed
the
great
potential,
and
so
that
was
an
interesting
discussion,
and
so
we
we
have
other
documents
on
IC
nqs
that,
for
example,
I
talked
about
how
to
label
flows
how
to
implement
us
treatment.
So
this
discussion
will
continue.
C
Hopefully,
next
time,
next
video,
ok,
quick
announcement.
So
there's
going
to
be
that
the
ACM
ICN
conference
in
September
in
Hong
Kong
also
by
Hong
Kong
City,
you
nobility,
the
TPC
meeting
for
the
main
program,
has
just
happened
on
the
weekend,
so
the
program
will
be
announced
say
in
a
few
weeks.
Okay,
so
give
us
some
time,
but
there's
still
an
open
call
for
posters
and
demos.
So
if
you
want
to
be
part
of
that,
please
check
it
out
and
see
how
you
want
to
contribute.
C
So
that's
September,
24
to
26
and
on
the
day
day
before
September
23rd,
there's
a
really
cool
event,
also
in
Hong
Kong.
So
it's
not
co-located
to
the
conference
on
using
ICN,
in
this
case
NDN
for
producing
media,
so
that's
Jeff,
Burke's
activity
so
trying
to
connect
the
ICN
Indian
community.
That
was
the
media
and
Performing
Arts
community.
So
should
be
really
nice.
If
you
come
to
Hong
Kong
anyway,
consider
attending
an
event
as
well
itself.
Three.
C
C
Okay,
quick
reminder:
this
is
almost
but
not
100%,
complete
overview
of
say
that
the
work
that
we
do
in
icy
energy-
and
so
you
see
like
the
fundamental
activities
so
underlies
embeddings
core
protocols,
and
then
we
have
things
like
us
that
I
just
mentioned
I
just
brought
up
a
picture
again
because
of
follow
that
Dave
showed
earlier,
because
these
are
the
core
specs
that
we
just
published
and
just
to
explain
this.
So
it's!
This
is
an
a
research
group.
So
it's
not
that
basically
produce
like
the
one
ICN
standard.
We
don't
use
the
nuts
anyway.
C
These
are
just
experimental
specifications,
but
this
is
just
one
way
of
doing:
I
see
em,
that's
CG
and
X,
so
this
group
is
totally
open
to
other
ways.
Other
protocols,
applications.
The
whole
idea
is
what
who
document,
those
that
people
are
interested
to
use
that
are
kind
of
mature
in
some
way
with
the
goal
to
enable
more
experiments
and
more
more
cool
research,
so
just
to
to
to
explain
it.
This
is
not
basically
the
only
only
technology
or
the
only
protocol
that
I
see
energy
is
doing,
and
so
this
brings
up
the
number
of
ice.
C
C
D
D
Okay
and
there's
another
one,
which
is
the
next
one
disaster
disaster
which
has
is
in
IRC,
final
poll
and
I,
think
some
of
the
irst
members
have
yet
to
send
in
their
poll
votes,
okay,
Colin,
so
both
of
those
are
within
days
week
or
two
from
going
to
the
RFC
editor
for
final
qualification
right.
There's.
C
A
C
D
There's
a
two-step
process
when
we
finish,
we
finish
anarchie
all
everybody's
happy.
The
next
step
is
there's
our
actual
formal
review
by
IRS,
G
members
and
I
believe
we
are
waiting
to
start
that
with
you
or
it's
a
dinner.
If
you
know
I
think
we're
wait,
it's
calling
in
the
room,
no
all
right!
Well,
we
need
to
go
vote
Colin
because
here's
this
reaction
items
now.
C
But
we
will
do
that
this
week
and
so
there's
one
one
draft
that
is
currently
expired,
that
this
is
flick,
so
file
like
ICN
collections,
manifests
or
see
CNX,
at
least
so
far.
So
that's
a
also
really
say
useful
and
important.
You
could
say
base
technology
that
for
for
our
city,
necks,
so
we
hope
to
we
select
this
pretty
soon.
Cynthia
can
see
a
few
words
so.
D
Christian
and
Mark
and
I
got
together
earlier
I
forget
what
day
it
was
already,
and
we
have
a
plan
put
together
for
finishing
that
draft.
There
doesn't
need
to
be
very
much
work
on
it.
It's
very
solid,
but
there
are
three
things
that
really
needed
to
be
done,
which
we
will
do
in
the
next
iteration
and
we'll
get
it
resubmitted
number
one
is
to
formally
define
the
extensibility
model
and
how
you
extend
the
manifest
formats,
because
that
was
under
specified.
F
D
Manifest
are
two
raw
hashes
which
says
that
if
the
consumer
wants
to
know
something
about
the
content,
they
actually
have
to
fetch
the
content.
So
there
was
no
capability
of
any
cup
of
annotations
or
small
metadata.
That
would
give
a
consumer
advice
about
whether
they
actually
want
to
bother
fetching
that
content
or
not
so
we're
adding
annotations
on
the
hash
values.
D
So
an
example
of
what
you
might
use
this,
for
is,
if
it's
a
manifest
for
a
video
asset
and
each
hash
value
is
a
frame
of
the
video
you
can
annotate
that
with
with,
for
example,
what
the
preferred
fetch
order
is,
should
you
fetch
in
decode
order
or
presentation
order
well
and
potentially
other
annotation?
So
those
are
the
three
changes
enhancements
we
expect
to
make
to
it,
and
hopefully
they
have
a
new
version
for
people
who
see
in
the
future.
C
Thank
you
Dave
just
quickly
again
on
the
season
X
specifications.
So
if
you're
new
to
this
group
and-
and
you
want
to
understand
what
this
is
about,
of
course,
first
of
all
check
out
the
RCS,
but
other
than
that
mark
is
going
to
give
a
short
summary
of
those
documents
later
today
in
IOT,
IRT,
F
open,
so
be
there
if
you're,
interested,
ok,
and
so
with
that.
This
concludes
our
updates
overview
and
material.
C
C
G
The
updates
relate
to
draft
that
we
we've
currently
as
a
have
as
an
IRT
F
2
alpha,
which
is
the
the
4G
draft
Ford
was
in
law
school,
but
I
might
get
that
wrong.
We
also
and
I
come
to
this
slider.
It
relates
to
the
the
next
presentation
draft,
where
we've
taken
things
out
and
put
it
into
a
separate
draft,
and
this
12
have
said
is
about
enabling
IC
n
5g
systems,
so
it
makes
direct
references
to
ongoing
5g
work
in
3gpp
and
leverages.
Some
of
the
design
principles
are
also
included
in
the
4G
traffic.
G
So
it's
good
to
also
look
at
that
traffic.
Maybe
there's
an
overlap
and
also
says,
as
you
will
notice,
the
updates
in
v4.
We
did
a
couple
of
editorial
changes
that
we
combined
the
architectural
pieces
together
do
not
have
too
many
sections.
We
combined
the
actual
next-gen
core
architecture,
which
talks
mainly
about
the
5g
components
as
they
defined
its
TPP
and
the
specific
part,
and
how
to
actually
extend
the
factory
core
connection
with
IC
and
support
that's
being
combined
in
a
single
section
for
editorial
reasons.
G
We
also
simplified
the
section
that
was
new
in
vo3,
which
talks
about
the
5g
launch,
support,
which
is
another
area
in
in
the
sweet
bippy
work
on
5g
at
the
moment
and
specifically,
we
removed
the
part.
There
was
a
use
case
for
this.
The
IP
/
ICN
/
5g,
learn
to
separate
internet
draft
which
comes
next
and
that
might
the
whole
section
simpler
and
we
only
kept
the
actual
ICN
over
5g
lon
peace
in
the
actual
draft.
So
it's
a
trunk
the
section
down.
G
We
also
added
a
new
description
in
a
separate
section
code
on
consideration.
So
what
we've
done?
We
positioned
the
the
the
traffic
against
the
deployment
consideration
draft
itself.
So
how
does
it
fit
in
the
categorization
of
underlay
versus
overlay,
as
well
as
the
different?
My
equations
and
it's
based
on
the
latest
version,
is
currently
in
the
in
the
in
in
the
poll
that
the
chairs
outlined.
So
these
are
the
updates
we
made.
G
These
are
some
of
the
pictures
you
can
see
in
the
draft,
as
well
as
the
5g
core
design
guidelines
that
are
being
that
are
being
utilized.
They
all
been
taken
essentially
from
the
various
which
BP
documents
that
you
can
find
the
references,
the
one
that
we
added
is
the
distributed
land
support.
That
was
added
in
version
3,
which
is
a
new
part.
G
This
is
an
updated
picture
we
have
in
the
draft
on.
How
do
you
recognize?
How
do
you
realize
the
actual
applications
over
the
so-called
transport
convergence
layer
which
sits
in
between
the
app
and
the
actual
dual
ICN
IP
stack,
and
they
have
been
some
updates
to
the
text
on
how
the
this
TCL
works
and
makes
the
selection
of
the
actual
packets
to
be
routed
either
over
ICN
over
IP?
G
And
there
are
some
updates
in
the
draft
and
this
most
of
the
artists
have
been
oh
they're,
actually
not
updates
oversimplifications
being
made
on
ICN
over
5g
lon
we're
and
explaining,
specifically
the
new
interfaces,
which
is
a
so-called
NX
interface,
and
it's
called
NX,
because
the
switch
PP
didn't
come
up
with
a
number.
Yet
usually
the
the
interfaces
have
a
number
boring
like
and
four
and
six
and
nine
whatever
this
one
is
called
NX,
because
it
has
got
a
number
yet
and
the
forwarding
is
that's
this
being
described.
G
There
is
one
of
the
ongoing
piece
of
work
in
3gpp
on
so
called
using
so-called
pass,
based
forwarding
over
that
new
interface
to
establish
an
end-to-end
LAN
connection.
So
the
idea
here
is
that,
instead
of
having
an
IP
Bearer
on
your
cellular
device,
you
would
have
a
LAN
Bearer
on
your
seller
device
and
the
actual
lance
can
be
separated
from
each
other.
So,
therefore,
you
might
have
a
different
alarm
for
one
application
versus
yet
another
line
for
another
application,
or
the
the
LAN
separation
obviously
happens
between
devices.
G
For
instance,
the
section
describes
how
the
actual
paths
are
being
set
up
and
encoded
between
the
ups
ups,
our
user
plain
functions
in
a
5g
system
or
for
like
a
better
word.
If
you,
if
you
want
to
associated
with
its
technology
very
often
their
Sdn
switches,
they're,
usually
slightly
more
complex
in
SD
inspectors,
but
as
a
simplification,
and
that
probably
gives
you
an
idea
with
a
UPF.
Is
it
describes
that
the
positive
news
provides
are
bi-directional
by
design?
So
you
can,
you
know,
send
you
know
back
and
forth.
G
That's
intentional
I'm,
similar
to
alarm
communication
that
you
would
have
as
well
as
that
several
pass
identifiers
can
be
combined
into
a
multicast
model.
That's
the
part,
that's
currently
being
pushed
into
release
17,
so
that
hasn't
been
and
there's
a
note
in
the
text
that
describes
dish
based
on
the
last
meeting
value.
While
we
were
actually
writing
the
draft,
we
expect
that
this
solution,
possibly
to
be
adopted
and
released
16
it
actually
has
been
pushed
into
the
discussions
from
release
17.
G
So
this
is
all
worked
as
ongoing
in
parallel
to
what's
going
on
in
sweetie
VP,
so
the
multicast
has
not
yet
been
agreed
at
the
sweetie
pp
level.
I
mean
probably
a
needle
should
make
the
note
a
bit
stronger
in
the
graph
to
describe
says
we
also
described
in
the
graph.
Often
how
do
you
utilize
the
pathways
forwarding
to
send
the
packet
from
one
layer
to
seller
device
to
yet
another
one?
G
How
does
that
work
with
a
generic
packet
structure
described
at
the
bottom
through
the
the
MAC
addresses
that
of
being
assigned
to
the
devices
at
the
barrel
level?
So
once
you
once
you're
attached
to
the
device
is
very
similar
to
today's
IP
model.
You're
you're
getting
an
IP
I
saw
a
MAC
address,
assigned
rather
an
IP
address,
and
then
how
is
the
actual
forwarding
at
layer
2
being
realized,
as
described
in
the
draft
as
well?
G
The
next
steps
we
have
is
to
collect
feedback
from
the
ice
energy,
in
particular
on
the
changes
there.
As
I
said,
there
is
a
difference
in
changes.
Some
of
them
are
editorial.
Some,
the
5g
part
has
largely
been
update,
as
mainly
updating
following
the
specifications.
The
5g
LAN
part
is
newer,
because
the
ongoing
work,
but
to
get
comments
from
the
working
group
would
be
very
useful
to
see
where
we
are
with
that.
We
also
with
the
author's
felt
that
in
combination
to
the
4G
traffic,
is
already
a
research
group
item.
G
H
Yes,
indeed,
over
just
a
process
question
so
I'm,
not
a
5g
expert,
but
obviously,
if
actually
a
sanitization
is
still
ongoing,
yeah.
So
what's
your
vision
is
then
this
should
be
a
living
document.
I
mean
that
doesn't
matter
regarding
and
working
group
adoption
right,
we
or
research
we
can
adopt
it
and
still
have
it
as
a
living
document.
But
do
you
want
to
have
it
hanging
on
until
5g
is
done
or
or
do
you
do?
You
foresee
any
major
changes
in
the
5g
lon
again
I'm,
not
an
expert
I'm
just
so
for
the
for.
G
The
FRG
Korca
Texas,
no,
this
is
I-
mean
the
update.
They
also
a
minor
it's
relative,
so
there
were
updates
to
that
part
of
the
text.
I
said
the
five
Jalan
is
a
little
bit
of
a
moving
target
at
the
moment
because,
as
I
said,
while
we
were
writing
and
we
were
actually
expecting
the
multicast
mode
5g
LAN
at
the
moment
really
16
is
a
LAN
tool
on
communication.
It
doesn't
actually
describe
how
to
do
multicast,
which
is
slightly
strange
right,
but
it
has
been
moved.
G
G
I
G
I
G
Exactly
the
question,
be
we
could
at
this
the
reason
we
didn't
add.
It
is
because
we
didn't
want
to
have
to
moving
targets
in
a
why,
because
even
the
tears
n
is
equally
fluid
at
the
moment,
so
we
left
that
out
and
basically
focus
on
the
baseline
line.
Communication.
Okay,.
C
C
G
D
G
Okay,
so
this
craft
is
a
new
traffic,
but,
as
I
mentioned
before,
this
came
out
of
a
notorious
decision
to
actually
move
parts
of
the
previous
draft
out
into
a
separate
one
I'm.
So
in
a
way
this
is
the
second
time
the
content
is
being
presented,
but
the
draft
itself
is
a
new
submission.
I,
don't
think
there's
any
of
my
quarters
here.
Ict
is
here
sorry?
Yes,
he
indeed
is
here,
so
they
were
later
draft.
G
As
I
mentioned
it's
the
previous
one
and
we
took
the
in
the
previous
one
in
the
previous
version
of
the
previous
draft.
The
IP
over
ICN
over
fifty
line
was
a
use
case
for
the
ICN
over
five
Jalan
and
I
said
we
then,
but
there
is
the
the
overlap
that
we
utilized
in
this
draft
is
to
the
5
g
5g
core
design
principles
of
enough
repeating
all
of
it.
We
have
a
certain
recap
of
the
5g
lon,
which
is
much
shorter
than
in
the
actual
5g
traffic
s.
G
And
we
say
so.
What
we
are
focusing
on
here
is
how
to
utilize
ability
and
implement
actually
IP
over
a
noisy
ICN
over
for
chillin
over
this
table.
Arrangements,
we
describe
news
cases
in
the
draft.
I
said
the
site
of
a
petitioner
recap
of
the
actual
realization
of
five
Jalan.
In
fact,
in
the
five
gene
core
network,
and
then
we
focus
in
the
in
the
main
part
on
the
realization
of
IP
based
services.
G
J
G
The
ip-based
services-
yes,
it
made
they
title
very,
very
long
to
call
it
IP
based
services
device.
In
fact,
you
learn,
but
I
could
have
done
that
the
the
actual
section
is
called
IP
based
services,
though.
A
G
K
G
G
So
maybe
we
have
the
various
items
in
the
section
and
then
we
do
the
same
as
we've
done
in
a
change
for
the
ICN
over
five
g12
that
we
linked
to
these
Roman
considerations
in
a
separate
section,
so
I
said
in
the
recap:
we
focus
particular
on
these
two
new
interface
at
the
n6
interface.
It
has
a
number,
so
it
is
a
little
bit
older.
G
The
NX
interfaces
that
new
one
that
I
was
talking
about
before,
so
we
discuss
specifically
how
these
interfaces
play
a
role
in
our
realization,
but
to
a
large
extent,
we
you
refer
back
to
the
separate
ICN
over
5g
traffic
in
order
to
keep
the
section
shorter.
This
relatively
and
a
half
hour
next
on
bullet
item
1,
which
is
hopefully
a
little
bit
more
useful,
and
this
rather
full
picture
shows
on
the
left-hand
side.
If
you
can
recognize
that
actual
device
is
talking
to
each
other
at
the
application
level.
G
On
the
left
hand,
side
on
the
right
hand,
side
you
have
a
forwarding
structure
in
in
the
middle
of
which
east
of
5g
LAN
network
and
at
the
bottom
we
also
talked
about
how
to
indicate
legacy
devices
that
have
a
full
IP
tcp/ip
protocol
stack
over
a
so
called
service
proxy.
G
So,
in
short,
we
describe
with
this
alongside
this
picture
of
how
every
internet
IP
based
service
is
interpreters,
the
named
service
transaction
that
is
being
routed
over
an
ICN
layer,
which
is
the
ice
in
vivace
LAN
layer
that
is
described
in
a
separate
raft,
how
the
broader
caustic
flattens
to
the
four
layers
being
the
action.
Ip
based
services
are
long
site,
not
on
top
of
each
other
and
the
name
based
routing
together
with
the
layer,
one
and
layer
two.
So
that
gives
you
the
four
layers.
G
We
then
also
describe
the
interaction
of
the
ice
and
layer
with
the
name
resolver,
which
you
could
see
in
the
previous
picture.
It
was
somewhere
in
that
wild.
Ask
it
wrong.
In
the
middle,
the
register
I
discover
IP
based
services
to
determine
the
actual
intent,
a
packet
forwarding
information.
So,
in
order
to
retrieve
actual
path
based
forwarding
information,
you
use
the
name
resolver
to
do
that
and
it's
that's
been
done
for
differ
for,
depending
on
what
type
of
IP
based
service
you're,
considering
the
one
that
we
described
in
the
draft
are
HTTP
services.
G
We
can
do
this
and
said
the
interfaces
to
legacy
devices
and
IP
based
peering
networks
is
established
to
the
service
proxy
devices
which
were
at
the
bottom
of
that
picture,
and
they
terminate
a
traditional
internet
protocol
stack
and
then
communicate
with
the
the
actual
IP
protocol
stack
based
devices,
the
next
step.
We,
this
is
an
initial
draft.
G
It
is
longer
than
the
piece
that
we
had
included
in
the
in
the
joint
raff
the
last
time,
so
it
has
already
more
information
than
we
had
at
the
last
IDF,
but
still,
obviously,
what
we
are
interested
in
is
to
collect
feedback
from
the
ice
energy,
not
only
only
about
the
name
of
the
craft,
but
also
about
some
of
the
operations.
I
said,
one
of
the
questions
we
had
is
to.
We
want
to
include
all
of
the
mappings
to
be
half.
G
We
have
mapping
so
HTTP
4
over
IP,
4
coop
and
for
some
other
services
do
we
want
to
have
them
as
separate
sections.
At
the
moment
we
only
describe
how
to
map
HTTP
based
services.
We
also
have
a.
We
have
an
updated
certain
protocol
details
like
the
flow
management
and
the
mobility
handling.
They
are
to
be
done
for
future
versions.
G
J
Lot
for
a
comment,
which
is
that
ice
cream,
I'm
walking
to
this
color
guy
I,
think
I
would
stick
with
the
HTT
based
services
and
the
reason,
roughly
speaking,
is
this
I
think
that
a
significant
set
of
people
in
this
in
the
larger
networking
community
outside
of
this
room
can
understand
why
that
would
make
sense.
Mm-Hmm
right
they
can
so
HTTP
is
kind
of
an
information
transport
protocol
on
top
of
IP
now
I'm
at
the
services
enticing.
That
all
feels
really
right.
I.
J
G
Okay,
good
thanks,
it's
kind
of
like
the
reason
that
we
used
to
put
HTTP
at
the
moment
in
because
it
it
also
lines
spread
over
the
use
case.
I
mean
there
was
a
reasoning
as
well
the
use
case.
If
you
read
the
use
case
section,
they
are
actually
82
feet,
use
cases
right
and
there's
the
reason
for
it,
because
it
becomes
more
blinding
you're
obvious
why
you
would
do
that
all
right.
The
reason
we
do
IP
is,
if
you
don't
know
anymore,
what
to
do.
We
just
hand
it
to
the
IP
layer.
G
That's
the
reason
we
do.
The
IP
mapping
I
think
somebody
comes
was
a
and
we
had.
We
had
a
trial
a
couple
of
two
years
ago,
where
somebody
allegedly
did
HTTP,
but
it
turned
out.
It
was
a
ready-made
version
of
HTTP
I
mean
just
handed
straight
back
to
the
IP
layer.
We
actually
detect
that
and
just
give
it
to
IP
and
said
okay
and
a
lot
of
the
benefits
that
our
scribe
in
the
use
cases
are
not
obviously
visible.
If
you
do
that
at
the
IP
layer.
H
Why
do
I
think
Dave
was
caught
other
saying
that
while
you
can
do
HTTP
over
I
see
and
a
lot
of
the
tricks
that
modern
web
pages
and
are
not
so
easy
over
I
said
right,
Dave,
remember,
oh
I
know
the
paper
well!
Well
so
I'm,
just
it's
just
a
comment:
I
mean
you're.
This
is
standardization,
so
you
basically
defining,
but
maybe
you
want
to
have
a
look
at
the
paper
that
reality
a
lot
of
the
stuff
that
we
have
on
the
web
today,
it's
not
so
easy
to
do.
G
G
J
D
L
G
So
the
the
section
on
secure
that
it
was
not
analyst
there
was
an
eg.
This
section
of
security
consideration
is
to
be
filled
as
well,
so
that
goes
to
the
HTTPS
one.
We
actually
have
a
the
question
about
the
microservices.
We
have
a
draft
in
the
coin
RG,
which
is
on
Thursday,
where
we
use
this
technology
in
the
at
the
terminal,
so
with
what's
actual
change
protocol
stacks
to
do
micro
services
underneath
monolithic
applications,
so
we
decompose
Android
apps
just
because
we
don't
only
do
Android
for
some
reason.
G
J
So
I
found
stuff
because
I
heard
the
word
standardization,
previous
speaker
and
I.
It
isn't
right.
This
is
a
research
draft
and
I
think.
Actually
it's
a
really
excellent
question
to
say:
okay,
look.
We
know
that
HTTP
is
and
abused
in
and
twisted
beyond
all
recognition.
It's
a
really
interesting
question.
How
well
and
how
broadly
the
mapping
applies.
I
think
it's
a
good
research
question.
Okay,.
C
Thanks
yeah,
just
as
a
comment
from
Jess
I
mean
the
the
HTTP
mapping
is,
that
is
not
the
core
part
of
the
of
of
this
work.
It's
certainly
a
good
topic
for
for
the
school
to
consider
so
how
to
do
web
/,
ICN
in
general,
and
and
also
address
the
interesting
challenges
that
the
n,
for
example,
and
I
brought
up.
But
it's
not
a
core
part
of
this
document.
No.
G
No
I
mean
they
say:
yeah
I
mean
the
for
those
of
you
actually
have
been
in
the
research
group
for
quite
some
time.
You
presented
early
work
of
this
as
early
as
2015-2016,
so
this
comes
out
of
work
that
we've
actually
tuned
much
more
towards
standardized
system,
so
we
had
research
prototypes
in
2015,
I,
think
that
even
demonstrated
to
the
cream
and
the
reason
we
lean
more
to
you
know
what
is
possible
in
5g
is
because
some
of
the
the
design
we
utilize
it's
actually
being
brought
into
5g
standardization,
not
every
saying
the
HTTP
mapping.
G
Is
it
and
tried
the
API
mapping
is
really
something
that's
much
more
related
to
the
ICN
discussions,
which
is
why
we,
we
have
the
discussions
here
but
stuff
around
five
Jalan
path
based
forwarding
etcetera,
is
currently
being
poured
into
five
civilization
might
be
very
part
of
running
systems.
You
know
at
some
point
I'm
good.
Okay,
thank
you
to
the
demo
in.
C
F
So
this
is
a
changes
from
version
one
to
version
2
thanks
to
Davis
commenting
a
mailing
list.
We
clarified
server
communities,
the
first
one
is
doctors
or
content.
Hoarders
there
sometimes
miss
you
leading
so
I
clarify
the
meaning
of
louder's
and
the
meaning
of
content
orders
usually
actually
love.
Does
it.
Just
a
mission
has
a
denote
who
has
a
mission
to
pour
the
data
and
the
interns
packet
and
the
content
order
means
that
it's
a
cash
Lauda
who
cashed
a
corresponding
cache
that
is
requested
via
interest
packet
and
the
cash
versus
aunt
expired
the
cash.
F
So
this
is
something
like
a
mix
in
a
document,
so
I
clarify
the
cash
freeze,
just
catch
that
may
be
expired
or
may
not
be
expired
and
I
expired
caches
as
I
as
it
says,
it's
not
expect
expired
yet,
and
the
section
3
2,
1,
1
I
changed
the
price
at
Brock.
This
is
over
thanks
for
the
Deb's
comment.
I
scale
up
the
object
size
for
the
place,
a
Brock.
Previously
the
content
object.
Size
was
bite.
This
body
is
a
unit,
and
now
it's
the
unit
is
kilobyte.
F
F
So
we
add
this
statement
if
the
cache
is
refreshed
after
reboot
Jack
Carter
must
be
refreshed
must
set,
so
the
counter
must
set
to
zero,
and
if
the
cache
remains
after
reboot
check
counter
must
not
be
refreshed,
which
means
must
not
must
be
kept
at
ease,
and
we
also
need
to
add
this
some
Ayane
section,
but
even
though
it's
not
completed
yet,
but
we
added
the
Ayane
section.
So
this
is
just
a
leak.
F
If
you
use
along
the
pit
entry,
this
is
a
basic
behavior,
so
the
default
behavior,
especially
for
the
situation,
the
louder
supporting
the
plotter,
supports
the
mouths
pass.
Fifth,
some
louder
may
have
strategy
for
multiple
falling
when
it
sends
interest
message
to
multiple
neighbor
routers.
It
may
delay
or
prioritize
to
send
a
message
to
the
upstream
loudest
the
seasoning
request
as
a
default
complies
with
such
strategy,
which
means
that
CCNA
for
user
could
tracer
actual
falling
past
based
on
the
foiling
strategy.
F
So
this
is
something
like
a
data
playing
trace,
but
we
also
add
some
compress
situation.
We
call
the
full
discovery
request.
They
mean
that
there
may
be
the
case
that
season
four
user
wants
to
discover
all
potential
floating
paths
based
on
louder's
fib.
This
means
that
it's
not
a
request
any
broadcast
requests,
so
the
feeb
may
have
a
multiple
entries
for
specific
content,
but
according
to
strategy,
as
I
said,
it
may
be
trade
or
prioritize.
F
Now,
if
our
seasoning
for
user
sets
the
F
frog
in
the
request,
Park
of
the
request
message
to
the
request
to
request
the
food
discovery,
the
upstream
louder's
water
request
to
the
old
mouth,
perhaps
room
based
on
the
FIB
simulation
area,
then
the
seasonal
views
I
could
trace
all
potential
boarding.
Pass.
Note
that
some
lot
of
may
you
know
the
full
discovery
request
according
to
a
policy
in
that
case
throughout
our
time,
is
a
request.
F
F
Maybe
I
remember
three
seconds
as
I.
Do
sorry
torso,
please
read
a
draft
two
or
three
seconds
as
a
default,
in
other
words,
unlike
the
ordinary
interest
data
communication
incision.
If
the
lot
accept
a
field,
full
discovery
request
that
louder
should
not
leave
the
pit
entry
created
by
season
in
full
request
until
the
timeout
Part
B
expires.
F
So
the
conclusion
for
at
this
moment
season,
which
is
compatible
with
CC
+
x/y/z
one
TLB
format,
but
of
course
it's
compatible,
but
we
add
several
new
packet
type
and
type
values
and
it
is
a
powerful
network
tool
providing
various
information
incision
and
the
most
important
point
of
this
draft
is
that
we
need
to
have
some
get
some
agreement
on,
especially
on
mod
pass
and
security.
So
these
are
the
maybe
biggest
issue.
So
please
read
the
draft
and
give
give
us
a
comment.
F
It's
really
welcome
and
the
implementation
is
almost
done
in
our
open
source
implementation.
C4
c4
is
not
only
for
seasoning,
for
it's
really
compatible
with
Metis
folder,
so
we
already
tried
the
interoperability
test
with
Metis
and
it's
a
full
set
of
assisi
and
avoiding
demo
and
the
content
store,
so
it's
already
included
in
a
safe
or
so.
If
we
are
interested
in
please
access
to
the
the
safe
for
dotnet
website.
D
D
H
One
of
the
other
issues
regarding
security
is
in
the
IP
world.
You
kind
of
do
the
there
are
different
caches
of
DNN
decided,
yet
DNS
usually
decides
which
one
you
use
and
then
the
traceroute
to
do
on
the
IP
layer
just
goes
to
one
source
right
and
here
in
the
ICN
word
we
have
both
intertwined
as
we
know
so.
One
question
from
a
security
perspective
is:
if
I
guess
that
you
are
asking
for
security
comments
right,
so
one
issue
could
be
I
have
to
have
to
look
at
it
closer,
and
is
that?
H
Can
you
use
this
for
discovery
of
caches
and
that
you
know,
maybe
the
ICN
service
provider
doesn't
want
you
to
discover
because
usually
routes
to
the
other
one
or
I
mean
then
then
he
would
probably
block
see
see
an
info.
Is
he
supposed
to
do
that?
Is
he
allowed
to
do
that?
I?
Don't
know
right
right,
right,.
D
H
D
F
H
D
D
H
D
Don't
think
we
want
to
replace
Rhea
sort
of
like
go
around
the
wheel
again
with
what
happened
with
traceroute
and
ISPs,
where
they
just
dropped,
trace
routes
and
refused
to
answer
them
rather
than
then
figuring
out
how
to
allow
trace
routes
to
propagate
and
see
the
parts
of
the
path
that
aren't
sensitive
right.
So.
H
F
Full
discovery
is
not
broadcast
so
who,
even
though
you
get
to
some
answer
from
full
discovery
that
both
or
multiple
replies
must
be
legal,
because
the
feeble
already
coordinated
just
according
to
the
strategy,
some
of
the
past
is
prioritize
and
the
secondary
or
Sadri.
They
are
just
prior
to
lower
priority
so
anyway,
so
the
full
discovery
is
not
again.
It's
not
broadcast.
It's
not
a
true
Wow
the
broadcast
discovery.
So
it's
a
coordinating
to
discovery,
but
the
strategy
may
not,
let's
say
something
like
ignore.
F
Such
kind
of
a
prioritization
may
be
ignored,
so
this
is
a
difference,
but
anyway
mister
thanks
for
your
great
comment,
it's
really
interesting,
but
also
a
several
discussion
about
the
security
sled
or
something
like
access
control,
and
so
we
already
mentioned
slightly
mention
in
a
drafter.
So
please
read
the
draft
and
we
are
really
happy
to
get
you
your
comment
again.
Thank
you.
C
C
M
Give
us
an
update,
yeah
something
completely
different.
This
is
actually
a
story.
That's
going
on
for
a
while
and
I
just
took
just
said.
It
wouldn't
be
better
to
give
a
brief
recap
on
what
this
actually
is
about.
I
don't
have
slides
for
this,
but
so
I'm
doing
this
hand
waving
Lee.
If
you
look
at
low
power,
lossy
networks
in
the
IOT
of
constraint,
devices
that
operate
on
batteries-
and
you
have
different
link
layers
like,
for
instance,
IDO
2.15
for
Bluetooth,
Low
Energy,
or
you
have
this
w
pan
things
like
Laura
and
and
stuff.
M
So
these
these
wireless
technologies
have
the
property
that
they
have
that
they
are
very
constrained
in
several
ways.
They
can
only
send
a
very
low
rate
of
packets.
The
the
maximum
transfer
unit
size
is
pretty
low,
so
ada
2.11,
there's
120
27
by
its,
including
the
layer,
2
header.
So
this
is
all
different
from
the
common
picture.
We
have
from
fixed
networks,
big
pipes
that
are
interconnected
and
where
you
can
actually
do
a
lot
of
complex
operations
without
doing
any
harm
and
to
to
adapt
the
IP
role
to
this
there's.
M
A
lot
of
a
lot
of
work
has
been
done
and
is
still
ongoing
in
several
groups.
The
most
prominent
was
the
6lowpan
adaptation
layer
that
that
the
IP
ipv6
world
ADA
got
15-4
and
if
you
want
so
this
is
the
correspondent
work
for
ICN,
which
is
in
some
in
some
cases
pretty
similar
or
even
just
transverse,
the
concept
one
to
one.
So
it
doesn't
reinvent
them,
and
there
are
a
couple
of
things
in
this
draft
that
that
is
very
specific
to
in
the
end
SEC
and
India,
and
it
addresses
both.
So
what
is
rather
generic.
M
Well
generic
is
that,
if
you,
if
you
are
in
a
15.4
network,
you
need
to
tell
the
layer
because
it
doesn't
have
a
type
field
or
a
payload
type
field.
You
need
to
tell
the
the
the
receiving
node
that
reads
the
layer.
What
actually?
What
is
the
protocol,
so
this
is
done
via
a
dispatch
field
in
in
6lowpan.
M
So
we
extend
this
dispatch
field
to
address
that
there's,
Indian
or
CCN
coming
and
not
ipv6,
then
there's
a
stent
more
or
less
standard
fragmentation
mechanism
that
fragments
larger
chunks
onto
these
small
small
empty.you
sizes
that
is
more
or
less
straightforward,
to
transfer
to
Indian
as
well.
And
then
there
are
a
lot
of
mechanisms
that
relay
to
compression
to
make
the
transfer
of
of
packets
or
of
data
chunks
more
efficient.
And
these
these
compression
mechanisms
address
headers
I'm,
not
data.
M
Versatile
means
getting
getting
the
things
small,
but
do
it
in
a
way
that
it
is
not
addressing
every
narrow
corner
case,
making
the
thing
extremely
complex,
but
being
very
useful
for
let's
say
80
90
percent
of
the
cases
and
that's
where
we
are
actually
in,
and
this
is
what
this
graph
does
and
this
in
the
middle
of
the
disk
of
more
or
less
converging
discussion.
So
we
had
two
updates
since
the
last
time.
One
updates
last
time
was
last
presentation
here
was
proc.
One
update
was
from
version
to
version
3
on
the
the
the
other.
M
One
is
from
version
3
to
version
4.
So
what
did
we
do
in
this
in
this?
First,
the
the
key
discussion
that
was
around
was
first
on
on
the
on
the
way
how
to
encode
timers
time
tier
V
section,
and
the
second
was:
how
can
we
sort
of
even
simplify
the
scheme
to
by
just
not
not
taking
and
taking
or
accounting
for
exceptions
that
are
more
or
less
not
so
important?
So
what
do
we
do?
M
First,
we
editorial
staff
Tory
stuff,
also
quite
a
number
of
just
writing
and
clarifying,
and
then
we
we,
we
selected
the
the
time
TF
our
values.
That
was
a
we
also
simplified
the
the
way
and
how
the
compression
works
and
here's
some
details.
So
the
idea
with
the
time
TF
how
is
borrowed
from
from
an
lopen
RC,
that's
basically
the
idea
to
have
to
compress
the
time
values
into
water
pipe
and
the
by
it
should
should
be
able
to
cover
with
decent
ranges
of
numbers.
M
So
ranges
up
to
days,
but
not
but
at
the
price
of
granularity,
so
you
can't
express
any
now
every
number,
but
you
you
express
like
many
numbers
in
the
small
range
and
and
fewer
numbers
and
the
large
range
this
is
done
by
an
encoding
using
exponent
and
mantissa
and
then
using
an
exponential
representation.
It
is
written
on
the
slides
here
and
you
get
you
get
things
that
are
that
are
in
these
ranges
of
sub
milliseconds
to
45
days.
M
The
point
here
or
the
the
thing
that
was
actually
on
the
discussion
here
is
that
you,
if
you
compress
an
arbitrary
number
in
this
way,
then
you
can't
recover
the
number
exactly
you
kind
of.
If
the
number
is
not
representable
in
this
way,
then
you
are
actually
you
need
to
round
to
round
to
the
nearest
or
nearest
largest
larger
number,
which
is
actually
in
the
draft.
M
D
So
for
any
any
any
time,
values
in
CC
n
x
that
aren't
inside
the
security
envelope
we'd
be
able
to
compress
them
this
way
and
that
for
most
of
the
uses
of
timers
in
CC
n,
it
has
the
again
the
nice
property
that
this
exploits,
which
is
that
the
the
longer
the
time,
the
less
precision
you
need
in
the
actual
time
things
stay,
you
know,
are
being
measured
so
it
this
is
something
we'll
discuss
as
perhaps
being
done
globally.
Further
all
the
specs
I.
H
D
M
D
M
D
The
one
that
it
would
be
the
Delta
for
expiration
over
current
time
right,
because
data
expiration
might
very
easily
be
longer
than
45
days
right,
but
all
the
rest
won't
look
at
it.
Look.
M
D
M
That's
the
one
so,
and
the
second
is
the
the
state
compression
scheme
is,
is
built
in
a
way
that
we
are
trying
to
Eli
trying
to
cut
out
a
lot
of
type
and
length
values
from
the
TLV
encoding,
and
this
is
by
fixing
fixing
in
order
and
fixing
certain
types,
and
that
is
that
the
scheme
gets
more
complicated.
If
you
give
you
give
more
freedom
to
the
to
the
to
what
you
encode-
and
there
was
one
discussion
on
op
limits
in
in
the
end
in
the
end,
has
an
optional
hop
limited.
M
So
we
actually
decided
to
say:
okay,
we
always
we
assume
there
is
a
hop
limit
and
if
there
is
no
hop
limit,
then
we
can
just
insert
a
255
which
is
a
maximum
up
limit
size
that
doesn't
do
harm
and
and
and
then
we
don't
need
to
deal
with
the
case
that
that
there
is
no
hop
limit
and
if
the
same
as
we
also,
we
assume
the
hop
announces
present
and
then
we
can
actually
fix
the
order.
And
then
we
can
use
that.
M
If,
if
an
interest
lifetime
is
there,
then
we
can
actually
use
it
from
the
header
length,
because
it's
a
remaining
the
remaining
bytes
and
the
one
that
time
tre
encoding
is
is
I
already
mentioned,
and
the
same
is
a
little
bit
for
the
data.
So
we,
if
we
fix
the
order,
we
can
actually
once
again
be
used
at
last
the
last
field
and
that's
a
fresh
freshness
period.
This
is
optional.
M
If
it's
there,
we
see
it
from
the
header
length
and
if
it's
not
and
the
header
is
exhausted
and
in
in
the
cases
I
mean
that's
always
the
format
in
the
cases
where
all
these
schemes
don't
apply
softens
the
freshness
period
cannot
be
converted
to
the
to
the
TV
or
whatever.
Then
we
can
always
fall
back
to
sending
uncompressed
data,
so
that
is
that's
always
in
a
fallback
that
is
not
not
efficient
but
compatible
to
everything.
That's
that's
like
the
the
escape
Ian.
M
Of
course,
the
objective
is
to
hit
most
of
the
cases
to
be
to
be
applicable
in
most
of
the
cases,
so
the
second
update
we
had
is
very
recent.
That
is,
we
had
a
room,
GL
I
can't
really
pronounce
the
name.
Sanchow
had
kindly
provided
a
thorough
review
to
before
the
version
3
and
while
we
we
had
discussions
on
the
list,
we
also
had
offline
discussions
on
some
details
with
him.
There
was
a
number
of
things
stressful
to
straighten
out,
and
this
is
numerated
here
and
there's.
M
M
He
pointed
out,
which
was
a
very
smart
point
out,
pointing
out
that
the
forwarding
hints
could
also
work
with
a
TLV
compression
scheme
that
actually
applies
for
the
names,
so
we
added
this,
then
we
had
some
adaption
on
the
newest
versions
of
ndn.
There
was
a
parameter,
renamed
application
parameter.
We
adopted
this.
That's
minor
details
here
was
also
an
editorial
thing.
M
The
the
discussion
point
here
is
actually-
and
we
I
wanted
to
bring
this
to
the
to
this
group-
is
the
question
about
compressing
names,
so
we
always
assume
that
we
have
all
name
components
of
the
type
generic
name.
That
means
it's,
it's
opaque
and
the
end
forces
the
the
the
option
to
have
type
names.
So,
for
instance,
you
could
have
part
of
the
name
being
a
temperature
with
some
some
semantics
and
some
syntax
or
being
something
I,
don't
know
some
counter
or
some
of
a
certain
length.
M
H
M
H
D
M
D
D
You
know
how
many
types
are
in
the
registry
now
like
2
3,
maybe
4
and
of
those,
maybe
only
we
can
talk
about
which
ones
we
actually
expect
to
see
commonly
used,
and
we
can
you
know
we
you
can
do
you
know
constant
dictionary.
You
know
static,
Dictionary
compression
of
the
types
that
we
expect
to
see.
I
had
one
a
quick
question:
when
you
say
we
don't
compress,
do
you
lose
all
the
compression
of
everything
or
only
the
compression
of
the
name.
M
N
K
N
M
N
M
Mean
they're
actually
two
two
ways
to
do.
This
I
mean
the
this
draft
also
addresses
stateful
compression,
but
not
for
the
names
now.
So
we
could
could
include
this
interstate
full
compression,
the
the
emini
types
I
mean
even
leave
this
approach
for
the
generic
and
then,
if
you
they
are
type
name
components
and
put
this
into
stateful
compression.
The
other
will
be
like
to
to
squeeze
this.
M
N
For
I
mean
for
names,
usually
you
have
enough
repetition
between
all
the
different
names
in
the
packet
that
just
doing
a
teeny
dictionary
at
the
start,
you
know,
would
let
you
do
arbitrary
compression,
but
still
get
a
lot
of
compression
man.
L
L
M
This
actually
exists
here
too,
so
we
have.
We
already
have
this
state
for
compression
of
common
prefixes
here,
which
is
that's
more
or
less
straightforward
translation.
So
you
just
cut
the
cut
the
prefix
that
is
common
to
the
communication,
and
then
you
you,
you
fix
it
at
the
nodal
state
yeah.
But
here
would
it
would
be
something
like
what
I
guess.
What
mark
means
is
so
it
would
be
something
like
we
have
a
name
that
is
built
of
component
type,
1
type,
2
type
3,
and
this
name
repeats.
M
So
we
can
say
this:
we
have
of
name
type
five
or
so,
and
this
has
this
structure.
So
we
we
note
that
we
are
actually
communicating
it
at
five
name
and
then
we
can
write
down
the
compressed
format.
So
what
what
mark
says
basically
is
that
the
names
are
not
arbitrary,
but
they
follow
some
logic,
so
I.
M
C
Rather
that's
more
of
you
so
who
has
read
the
latest
version
of
this
draft,
not
the
latest
but
the
one
before
so
a
version?
Okay,
okay,
so
there
are
two
things
so
one
is
we
want
to
obey
the
outcome
of
the
name
component,
discussion,
yeah
and
but
second
is.
It
would
be
good
to
get
a
few
more
eyes
on
this
on
this
draft.
So
maybe
somebody
who
maybe
hasn't
read
it
yet
could
have
a
dog
who's
fresh
eyes
so
that
we
just
do
some
quality
assurance
in
the
group
here.
L
B
C
F
C
So
this
is
really
interesting
work
in
a
sense
because
it
really
demonstrates
the
usefulness
of
ICN.
So
there's
other
work
well.
That
team
that
you
know
demonstrates
all
the
nice
properties
in
terms
of
robustness,
performance
and
so
on.
So
comparing
ICN,
our
lopen
networks
was
like
IP
based
stacks
and
the
reliance,
if
I
may
say
so,
are
really
really
promising.
So
this
is
really
one
one
area
where
I
see
and
really
shines,
and
so
that's
also
why
we
want
to
get
this
out
and
publish
this
as
a
one
of
our
next
specifications.
O
O
Okay,
hello,
everyone,
I'm
Chong
Chong
from
a
tree.
This
is
the
update
on
NRS
document.
We
have
a
to
an
arrest
document
which
is
adopted
after
ITF
102,
and
one
is
requirements
for
NRS
in
ICN
and
the
other
is
architectural
consideration
of
ICN
using
NRS.
The
first
one
had
the
title
of
the
first
one
has
changed
it
in
to
design
guidelines.
The
reason
why
we
change
it
when,
when
we
say
requirement
it
is
too
strong
and
also
the
things
that
we
have
described
in
the
trap.
O
O
So
the
first
one
design
guidelines
for
energy
in
IC-
and
this
is
the
zero
2
version.
We
haven't
changed
the
name
file
name
yet
so
it
has
the
requirements
in
it,
but
next
time
we'll
change
it
into
the
guidelines,
and
we
have
about
six
authors,
and
this
document
focuses
on
NRS
itself
as
a
service
or
as
a
system
in
ICN,
and
this
Tucanos
defines
what
is
NRS
in
ICN.
O
We
also
capitalized
the
NL's
approaches
and
also
provides
the
comparison
of
the
each
among
the
the
approaches
we
provides
the
functionality
of
the
NRS
in
ICS,
which
is
which
includes
how
analyst
is
used
in
different
ICN
architectures.
We
provides
the
design
guidelines
as
well
for
NRS,
as
well
as
the
security
considerations.
O
Originally
we
had
the
analysis
of
the
analyst
approaches
before,
but
in
the
lab
in
the
previous
version,
we
removed
it
because
we
concentrated
on
D,
and
that
is
a
system
itself,
but
somehow
we
had
a
discussion
among
the
authors
that
we
better
to
help
these
approaches
back,
so
we
put
it
back
in
there.
So
let
me
enter
explain
a
little
bit
about
the.
What
these
approaches
are.
O
The
first
exploitive
name
resolution
approach
is
there
is
that
you
have
the
name
resolution
service
system
as
standalone
in
your
architecture
and
that's
mostly
user
way,
and
the
second
lane
based
routing
approach
is
like
a
CCN
and
in
the
end
you
do
the
hop-by-hop
them
resolution
when
you
for
the
interest,
packets
and
the
third
is
a
hybrid
of
of
those
two
and
then
we
have.
We
give
some
comparison
up
to
those
approaches.
In
section
subsection,
3.0
and
section
4,
it
was
the
originally
way
back.
O
O
So
we
have
all.
We
are
five
now
and
the
scope
of
this
document
is
the
this
focuses
on.
Things
relate
to
the
ICN
architecture,
so
the
difference
between
the
first
one
is
equal
ease.
The
first
one
was
the
we
try
to
focus
on
the
inner
system
itself,
but
the
second
is
these
are
things
which
is
related,
I,
see
and
architecture,
so
things
you
have
to
consider
in
respect
of
the
ICN
architecture
here.
O
So
this
document
also
discussed
how
an
ICA
routing
system
has
to
be
changed
when
analysis
is
integrated
into
ICF,
because
another
system
is
is
not
a
mandatory
to
the
ICN.
So
you
have
you
need
you
have
a
certain
purpose
to
use
the
analysis
in
your
in
your
architecture.
So
when
you
integrate
your
architecture,
then
there
are
I
said
routing
has
to
has
to
be
changed
so
internal.
O
And
this
is
the
major
changes
from
previous
one:
we
added
some
terminologies
and
sexual
5.1.
We
change
it
from
the
name
resolution
to
the
name,
mapping,
record
registration
resolution
and
update,
and
this
is
about
to
hear
the
terminology
actually
originally
in
here.
The
new
Tamales
is
the
name
another
server
and
analyst
reserver
as
the
generous
components
and
the
other
two
is,
namely
registration
and
name
resolution
as
the
NRS
process.
O
These
for
tamales
was
defined
origin
in
the
previous
version
of
the
requirement
top
man,
but
before
like
we
had,
but
these
four
is
covered
only
by
the
explicit
name
resolution
service
approaches.
So
we
remove
from
the
this
party
some
knowledge
from
the
first
trap,
since
the
first
draft
covers
the
post
approaches,
but
this
drop
assumes
explicitly
the.
O
Explicit
name
resolution
service
approaches,
so
we
thought
it
is
Tom.
Lonny's
is
appropriate
for
this
document,
so
we
moved
from
there
to
this
document
and
then
we
change
it.
The
subsection
5.1.
It
was
a
short
description
about
the
who
does
the
name
resolution
or
how
does
the
name
their
position
or
when
does
the
limited
resolution
the
system?
And
then
we
still
we
keep
the
contents
of
that
participation,
but
which
is
the
way
we
describe
has
been
changed
into
the
we
explain.
O
What
is
named
is
name
registration
and
name
resolution
and
what
is
the
name
we
could
update
according
to
day,
we
still
they
are
explaining
that
who
does
the
name
resolution
and
when
does
the
name
dissolution.
So
in
this
picture
we
haven't
added
this
picture
in
the
draft,
but
just
to
just
put
it
in
this
light
that
the
name
is
the
registration
can
be
done
by
producer
or
I,
see
a
router
also
named
the
dilution
can
be
done
by
consumer
side
or
the
I
say
router.
That's
your
choice.
When
you
design
the
system.
C
So
while
Mark
walks
up
to
petrification,
so
these
are
two
in
informational
documents,
and
so
the
idea
is
that
we're
not
saying
every
IC
pendant
system
needs
name
solution,
it's
more
like,
so
if
you
are
inclined
to
use
them
illusion.
These
are
the
considerations
regarding
the
say
in
our
system
and
the
impact
it
would
have
on
your
ICN
system.
N
O
N
O
F
F
N
N
N
Q
Things
so
I'm
gonna
expose
my
lack
of
knowledge
here.
How
does
this
relate
to
the
two
different
kinds
of
name
services?
The
mobility
first
provides.
One
is
the
name
certification
service,
which
also
does
kind
of
human
friendly
name
to
do
UID
and
the
other
is
the
global
resolution
service,
which
goes
from
G
UID
to
something
that
helps
you
find
things,
but
so
they've
got
they've
partitioned
the
name
resolution
problem
into
two
parts
intentionally
because
they
need
they
have
different
kinds
of
requirements.
O
We
try
to
include
all
types
of
the
name
resolution
and
we
we
deal
with
the
we
didn't
provide
that
we
try
to
not
to
fry
the
too
deep
in
each
cases.
Buffer
like
like
what
you
are
saying,
we
I
think
we
could
include
it
as
a
mobility
support
functionality.
Developed
is
like
that.
Yes,
so
we
covered
it
yeah,
but
we
didn't
with
in
the
draft.
We
try
to
avoid
the
specific
like
mechanism
or
system,
or
something
like
that.
We
try
to
like
more
keep
the
general
information
about
it.
So.
G
I
wanted
to
make
sure
that
it
would
be
good
to
actually
highlight
these
two
different
steps,
because
in
another
system
where
it
might
be
a
bit
unusual,
but
this
it
actually
includes
the
notion
of
main
base.
Routing
is
3gpp
5g
3gpp
five-year
has
the
option
to
do
control,
plane,
routing
based
on
name
based
routing
mmm-hmm,
strangely
enough,
but
it
actually
has
two
steps.
It
has
to
so
called
this
service
discovery
profile
resolution
and
the
actual
name
based
routing
solution.
It's,
unfortunately,
all
called
name
resolution
function,
which
is
the
thing
that
I
disagree
with
me.
F
G
Actually
makes
sure
that
differentiate
these
two
different
steps,
so
it
says
yes,
I
want
to
do
I,
don't
know
an
authentication
management
function
and
it's
Dave
being
in
the
u.s.
under
their
subscriber
ID.
Please
give
me
an
actual
real
name:
I
can
route
on
and
that's
the
very
first
step.
The
second
step
is
the
one
once
I
have
that
name:
how
do
I
get
to
the
instance
action,
conservator
and-
and
it
seems
it
might
be-
quite
useful
because
it's
very
similar
to
what
the
movie
first
it
they
actually
make.
G
F
G
A
Yeah
I
can
comment
on
those
two
things
is
that
the
way
these
parts
are
written
is
that
we're
describing
these
at
the
high
generic
level.
So
you
have
the
explicit
name
resolution
that
you
map
something
at
the
server
like
DNS
or
something
like
that
and
you
have
name,
is
trapping,
and
then
we
have
the
third
thing,
which
is
a
hybrid
approach
where
you
combine
these
in
some
way.
So
I
think
all
of
these
alternatives
are
covered
at
the
high
energy
level
in
the
draft
and
I
believe
we
have
examples
for
mobility.
First,
in.
Q
I
think
one
of
the
things
that's
interesting
about
mobility
first
model
is
that
they
named
the
high
level
resolution
service.
They
recognized
that
there
may
be
many
of
them.
I
could
choose
one.
That's
fast,
I
could
choose
one.
That's
specialized.
I
could
choose
one
that
certain
characteristics,
so
there
are
multiple
different
possibilities
for
that
name
resolution
surface,
but
the
understanding
is
once
you've
gone
to
the
once.
You've
mapped
to
that
name
which
needs
to
be
globally
resolvable
there.
You
need
one.
Q
A
For
the
world
you're
saying
and
being
very
careful
to
talk
about
the
name
resolution
service
and
not
the
name,
resolution
system
or
multiples.
So
we
what
we
talked
about
this-
that
you
can
have
a
service
that
didn't
name
or
solution
and
that
can
be
implemented
as
different
systems.
And
you
can
have
things
that
scale
between
different
applications
in
R.
So.
Q
C
Okay,
great
so
I
mean
this
book
has
has
have
been
discussed,
and
you
did
a
couple
of
times
here
in
the
group.
So
what
and
we
think
it
has
reached
a
good
level
of
maturity.
So
what
we
would
like
to
do
is
issue
that
which
I
should
last
call
on
the
list
now
and
of
course,
if
there
are
more
comments
like
this,
we
will
deal
with
them,
but
we
think
that
that's
a
good
next
step
now
for
us
to
just
have
people
read
it
again
and
yeah
come
up
with
their
substantial
comments.
E
C
So
that
was
the
end
of
our
technical
agenda.
Just
a
few
pieces
of
information,
so
I
mentioned
the
ICN
conference,
there's
actually
another
ICN
event
even
before
that
there
is
the
NBN
community
meeting,
September
fifth
and
six
in
Gaithersburg
Maryland,
so
at
the
Hong
Kong
ACM
conference.
So
that's
going
to
be
the
main
conference
that
I
before
there's
the
touch
and
the
end
event,
and
we
would
also
like
to
have
an
interim
meeting
after
the
conference
so
on
Friday
the
27th.
C
C
No
big,
so
we
have
always
been
I've,
been
doing
this
for
the
last
year's
at
the
conference,
because
it
was
actually
always
a
really
nice
opportunity
to,
for
example,
do
a
deep
dive
on
certain
interesting
topics
that
came
up
at
the
conference.
Give
people
a
chance
to
really
say,
discuss
things
with
more
depth
so
that
we
prefer
a
tour
papers
actually
quite
useful,
and
in
past
years,
other
than
that
we
are
also
planning
for
a
nice
energy
meeting
at
Singapore.