►
From YouTube: ICNRG Interim Meeting, 2020-08-03
Description
ICNRG Interim Meeting, 2020-08-03
A
B
B
A
B
A
C
B
B
B
B
A
B
A
A
A
C
B
E
A
B
B
So
in
the
past
we
have
been
doing
the
like
these
typical
research
group
meetings
with
like
all
kinds
of
general
presentations,
and
you
know,
work
items
updates
and
so
on,
and
so
this
time
we
wanted
to
try
something
new
and
really
focus
on
on
one
of
our
our
ongoing
work
items
and
this
that
is
flick.
So
it's
a
bit
a
different
style.
Let's
see
how
it
goes
so
if
you
haven't
seen
the
link
to
the
shared
note-taking
tool.
B
That's
the
second
thing
here
in
the
list.
We
also
uploaded
the
slides
to
data
trigger
regarding
these
instructions
here.
So
I
don't
think
we're
gonna
be
a
very
big
group
today.
So
I
think
we
can.
We
don't
need
to
obey
this
webex
plus
q
minus
q
protocol.
So
I
think
just
use
your
microphone
and
we
can
have
an
a
more
lively
discussion.
I
think.
B
B
And
also
check
the
privacy
and
code
of
conduct
that
the
irtf
adheres
to
so
just
quickly.
The
irtf
is
the
research
system
organization
of
the
ietf,
so
we're
generally
making
standards
so
we're
doing
research
and
in
ic
energy
yeah.
We
try
to
encourage
foster
new
experiments
with
icn,
and
so
the
flick
topic
today
is
also
say
one
activity
in
this
perspective
quickly.
B
Note
taking
for
this
meeting,
I
will
just
do
that,
so
we
don't
have
to
find
somebody
else
today
and
quickly.
The
agenda,
that's
really
short,
because
we
really
want
to
allocate
most
of
the
time
to
flick
so
discussing
current
status
next
steps
and
also
assigning
to
do
items
if
there's
time
in
the
end
and
people
want
to
discuss
something
else.
That
would
be
fine,
so
let
us
know,
maybe
is
there
anything
that
you
urgently
want
to
discuss
today,
you're
just
quickly
asking
around.
B
B
A
A
Hello,
hello,
yeah:
can
you
see
it
yeah
so
well?
Here
we
are
so.
The
the
the
work
on
flick
has
gone
in
little
little
bursts
here
and
there
and
then
sort
of
goes
on
the
back
burner
for
a
while.
So
we
did
a
burst
on
it
prior
to
ietf,
106
and
and
then
put
it
back
on
the
back
burner,
so
it
sort
of
like
keeps
crawling
slowly
toward
being
finished,
but
but
never
quite
getting
there.
So
the
current
version
has
expired
as
a
data
tracker.
We're
not
worried
about
that.
A
A
A
We
have
a
python
implementation.
There's
a
proposal
for
how
to
do
group
keying
with
flick,
which
is
probably
pretty
important,
and
people
should
look
at
and
some
initial
thoughts
that
mark
wrote
up
on
how
to
do
key
wrapping.
So
so
you
don't
have
to
re-key
everything
you
can
do
key
evolution
on
on
when
keying
the
manifests,
and
we
have
some
worked
out
examples
next
slide
yep.
A
E
B
A
I'll
start
talking
without
the
slides
and
we'll
catch
up,
so
I
don't
want
to
waste.
I
don't
really
don't
want
to
waste
time
on
history
when
we
could
be
moving
things
forward.
So
the
history
is
that
this
has
been
around
for
a
long
time
manifests
are
in
ndn,
considered
a
useful
thing,
but
not
fundamental.
A
So
we
have
these
things
called
nameless
objects
in
ccnx
that
just
have
a
hash
and
it's
used
for
the
segmentation
of
large
objects,
not
not
just
having
a
sequence
number
as
one
of
the
as
the
trailing
element
of
the
name
and
also
allows
you
to
use.
These
manifests,
as
collections
of
like
directories,
for
structuring
lower
parts
of
a
namespace,
so
it's
been
implemented
and
used
all
along
on
a
lot
of
applications.
Next
slide.
A
A
Yeah,
so
what's
changed
is
the
first,
so
one
major
change
is
that
namespaces
are
explicitly
supported
in
in
flick,
so
you
can
have
an
hash
based
namespace,
a
single
rooted,
namespace
or
a
segmented
namespace,
and
those
can
be
used
for
a
variety
of
things.
So,
for
example,
for
just
getting
at
pieces
of
a
single
object,
you
can
use
the
nameless
version
with
just
the
hash
names.
A
So
we
redid
for
for
the
current
version
of
spec.
We
redid
encryption
pretty
much
from
the
ground
up
to
make
it,
as
I
said
quite
a
bit
more
flexible,
there's,
no
information
leaks
in
the
manifest,
so
anything
that
might
have
problems
with
privacy.
We
believe
are
covered
by
the
encryption
of
the
manifest
and
in
place.
A
It
supports
in
place
encrypt
decrypt,
so
you
don't
have
to
do
data
copies
one
encryption
key
for
manifest
and
specif,
but
what
we
have
in
the
spec
is
a
pre-shared
encryption,
key
method
which
you
use
as
sort
of
a
basic
thing,
but
doesn't
give
you
very
much
flexibility
and
two
group
keying
mechanisms.
The
idea
of
using
group
key
mechanisms
is
that
our
expectation
is
that
manifest
would
be
consumed
by
multiple
clients
and
not
by
a
single
client.
So
you
would
like
a
group
key
to
be
what's
used
for
the
manifest
next
slide.
A
A
Now
we
have
both
plane
pointers,
which
just
is
effectively
what
you
use
to
construct
the
name
in
an
interest
and
annotated
pointers.
So
plain
pointers
are
just
as
they
were
before.
An
array
of
hash
values.
Annotated
pointers,
however,
which
are
new,
will
allow
you
to
add
metadata
and
various
extensions
to
the
pointers.
A
So
when
we
put
in
or
in
directly
in
the
spec
is
object
size
so
that
when
you
fetch
a
manifest,
you
don't
actually
have
to
go
and
try
to
fetch
individual
items
pointed
to
by
the
manifest
in
order
to
figure
out
how
big
they
are.
You
can
get
the
size
directly
out
of
the
manifest
and
then
there's
some
other
ones
that
we're
proposing,
don't
define
in
here,
but
proposing
would
be
potentially
useful
for
various
applications,
like
hints,
for
traversal
order.
A
D
A
B
B
B
F
Derek,
can
you
hear
me
yeah?
Yes,
we
can.
I
was
thinking
about.
Let's
quickly
do
a
round
of
where
do
we
see
the
current
write
up,
the
scope
of
it
and
whether
we
already
agree
the
thing
still
to
be
done
assumes
that
it's
just
about
finishing
here,
the
pieces
that
are
missing,
but
maybe
we
should
quickly
just
make
sure
that
we
are
all
on
the
same
page.
F
What
I
observe
is
that
it
has
become
quite
complex
to
some
extent
that,
with
these
segmented
prefixes
and
the
idea
of
having
even
directory
style,
it
almost
looks
like
a
kind
of
a
file
system
snapshot.
It
is
not
only
a
single
file
like
collection,
it
is
now
file
system
like
collection
thing,
and
there
is
a
lot
of
security
that
has
come
in
whether
for
me,
it's
not
so
clear
how
much
has
to
be
included
or
whether
it
is
sufficient
to
just
have
the
hooks.
F
So
it
would
be
maybe
good
to
characterize.
Where
should
we
stop?
Should
we
really
have
all
the
things
in
that,
or
should
we
think
about
cutting
a
core
which
have
then
the
extensions
that
can
be
added
on
later?
I'm
putting
that
just
as
the
questions
and
maybe
especially
the
the
last
two
having
worked
on
that
burst,
dave
and
mark
could
maybe
comment,
but
also
the
others.
What
is
the
feeling
about
that?
D
Sure
look:
I
can
tackle
a
few
of
those
questions.
So
the
you
know
the
the
name.
Spaces
have
two
aspects
to
them.
One
is
you
know,
so
the
the
the
point
of
a
namespace
is
to
say
what
convention
is
used
to
generate
the
name
that
goes
in
an
interest.
That's
created
from
the
manifest
and
and
the
ones
that
I
put
in
here
were
hash,
naming
single,
prefix
and
segmented
prefix.
D
Those
are
independent
of
whether
the
thing
you're
talking
about
is
a
single
file
or
multiple
files.
Or
what
have
you
there?
You
know
it
doesn't
imply
anything
about
what
the
actual
thing
is.
You're
fetching
they
just
govern
the
rules
about
how
you
make
the
name
of
the
thing
that
you're
fetching
and
then
the
other
aspect
is
each
hash
group
can
have
its
own
namespace.
D
So
if
you
did
want
to
talk
about
two
different
things,
for
instance,
hash
groups
that
point
to
other
manifest
might
use
one
namespace
and
hash
groups
that
point
to
data
might
use
a
different
name
space
and
again
that
that
doesn't
mean
that
the
data
is
referring
to
multiple
objects
or
a
single
file.
You
know
it's
just
saying
you
know
I
can
use
different
name
spaces.
D
F
Yes,
absolutely,
but
the
question
is
exactly:
should
we
really
cover
both
because
you
could
think
also
about,
we
could
have
a
f
lick,
so
the
file
lick
and
the
d
like
a
directory
lick.
If
we
only
are
at
with
use
working
with
hashes,
we
avoid
some
of
the
problems
that
come
with
going
to
d-lick.
We
have,
for
example,
potentially
loops
in
the
manifest
right.
You
are
not
building
a
tree
anymore,
there
could
be
loops,
and
that
is
one
other
point
where
then
we
have
to
discuss
about
the
security.
F
Your
algorithm
about
parsing,
a
manifest
depends
on
the
data
provided
by
potentially
malicious
slick
writer,
and
I
didn't
see
a
section
on
that
from
experience
on
implementing
the
first
flick
for
myself.
I,
this
is
one
of
the
headaches
I
had
so
that
is
what
I
put
on
the
table.
Should
we
really
go
for
the
full
thing
or
make
sure
that
we
are
already
comfortable
with,
for
example,
only
hash
based
one
and
then
see
whether
we
can
how
far
we
can
go,
but
maybe
in
a
different
document.
D
D
F
D
D
C
A
D
Yeah,
I
I
I'm
I'm
I'm
still
not
well,
you
know,
yeah,
I'm
still
not
sure
that
you
could
construct
a
hash
tree,
so
the
flick,
manifest
is
still
a
hash
tree.
You
know,
if
you
ignore
all
the
decorations
for
for
how
you
create
the
name
for
it,
it's
still
a
hash
tree,
and
I
don't
know
how
you
would
have
a
parent.
No
sorry,
a
child
node
point
to
its
parent,
because
the
parent
can't
be
created
until
after
the
child
is
created.
A
D
C
C
C
A
D
D
A
Occam's
razor
might
lead
one
to
the
conclusion
that
we
should
not
put
them
in
yet
and-
and
I
I
think,
that's
an
oh-
I
think
that's
an
open
question.
It's
an
open
trade-off,
I'm
obviously
on
the
side
of
some
of
these
things
going
in,
because
you
know
I've
always
been
of
the
opinion
that
manifests
are
really
pretty
deep
and
fundamental
in
an
icn
architecture,
and
hence
they're
not
just
for
dealing
with
single
large
segmented
objects,
right,
they're,
they're,.
D
A
D
So,
as
far
as
far
as
the
name,
spaces
ccn
would
prefer
to
use
the
hash
based
naming
you
know
in
a
lot
of
situations
and
ndn
would
prefer
to
use
the
segmented
prefix
naming
so
every
data
object
has
a
unique
name.
That
I
mean
that's
my
understanding
of
the
the
the
ndm
preferences
is
you
know
everything
should
have
a
uni
unique
name,
and
you
know
we
we
want.
We
want
these
manifest
to
accommodate.
D
D
So
I
I
I
think
I
think
that
just
to
support
the
diversity
of
ways
that
people
use
these
things,
you
know
having
you
know
at
least
the
two
namespaces
of
hash
based
naming
and
segmented
prefix
naming
you
know
need
to
be
in
there.
You
know,
maybe
you
could
throw
out
the
single
prefix
name.
If
you
wanted
to
do
that.
C
Okay,
I
mean
I
had
the
general
idea
that
mark
just
described
a
minute
ago,
but
I
didn't
know,
for
example.
Well,
there
was
a
bunch
of
stuff
that
I
was
still
unclear
about
and
it
may
be
because
you
know
I
didn't
realize
there
was
a
python
implementation.
I
didn't
look
at
that,
but
I
I
I
got
the
I
think
I
said
this
in
my
comments
that
I
felt
like.
C
Maybe
there
was
stuff
that
I
should
have
known
and
didn't
before
looking
at
it,
but
you
know
when
the
at
the
beginning,
when
it
said
I
know
the
inode
model,
I
thought.
Okay,
great,
that's
a
simple,
very
useful
building
block
capability
and
but
then,
as
I
read
the
document,
there
were
all
these
options
and
and
possibilities
for
ways
to
use
the
thing
and
that
just
it
made
it
harder
for
me
to
understand
what
actually
was
was
there
and
wasn't
there.
C
C
D
So
so
ken
you
know
thanks
a
lot
for
your
comments,
so
those
that
was
really
great
to
get
those
from
you
and
and
yeah
it
it
it.
It
might
be
better
to
have
the
inode
analogy
in
the
beginning,
and
you
know,
like
all
good
analogies,
you
know,
keep
it
short
and
simple
and
not
try
to
carry
it
through
the
whole
document.
D
The
yeah
one
of
the
big
differences
is,
you
know
the
the
flick
entries.
You
know
it's
actually
trying
to
have.
You
know
one
format
that
serves
both
for
you
know
more
manifest
entries.
You
know
a
directory
entry
and
and
also
the
same
thing
for
you
know,
data
entries.
So
you
know
the
the
analogy
to
I
know
is:
you
know,
perhaps
limited
the.
C
A
A
That's
probably
a
very
bad
choice
of
terminology,
because
anybody
who's
not
who's
coming
at
this
naively,
is
going
to
go
what
what
the?
What
the
hell
that
what
this
is.
I
know
what
a
name
space
is,
and
it
isn't
this
so
it
occurs
to
me
that
maybe
we
need
to
change
the
terminology
there
and
call
it
something
like
name.
You
know,
name
constructors,.
D
C
D
Right
so
so
you
know
a
a
different
way
of
constructing
this
is
to
use
one
hash
group
for
data
and
one
hash
group
for
manifests
or
or
you
could
interleave
them.
You
could
have
multiples
of
each
type
or
to
use
annotated
data
pointers
where
it's
not
just
an
array
of
hashes.
But
you
have
an
indication
about
whether
this
hash
is
a
data
pointer
or
a
manifest
pointer,
so
that
there's
lots
there's
a
not
lost,
but
there's
a
few
different
ways
that
an
application
can
organize
manifest.
D
So
it
could
tell
you
know
if
it
understood
you
know
the
manifest
nature
it
that
and
and
and
an
application
can
organize
its
manifest
one
way,
but
a
consumer
doesn't
need
to
actually
understand
that
it
was
constructed
that
way.
It's
just
going
to
keep.
You
know,
walking
the
tree
and
retrieving
data
pointers.
So
even
if
it
doesn't
understand
it
could
still
fetch
the
whole
thing,
but
an
application
that
understood
the
semantics
of
it.
You
know,
might
have
optimized
behavior
on
the
manifest
and
you,
since
each
half
group
can
have
its
own
encryption.
D
D
So
you
know
we
had
talked
about.
You
know
like
only
doing
like
the
super
basic
encryption
in
this
document,
and
you
know
if,
if,
if
there
you
know,
if
there
was
the
energy
and
ability
to
then
publish
like
some
follow-on
documents
with
you
know,
like
group,
key
security
and
broadcast
encryption
or
whatever,
that
would
be
great,
you
know
I.
I
think
that
it
is
important
to
have
worked
out.
D
F
F
Would
it
be
possible
to
also
use
the
forward
criteria
to
separate
or
to
handle
what
should
be
in
a
document
or
not
all
the
directory
related
discussions
might
not
be
really
digested
by
any
forwarder,
while
the
pure
hash
based
tree,
that
might
be
still
in
the
reach
of
a
forwarder.
So
I'm
thinking
hearing
in
terms
of
trying
to
split
the
file
system
style
document
and
then
keep
exactly
as
they've
already
played
out.
F
We
have
only
one
level
of
inodes
and
it's
now
a
different
level
of
looking
at
what
is
inside
these
things
collected
by
an
index
table
or
inode,
and
so
we
would
have
also
two
different
documents
for
that:
one.
That
only
looks
at
the
I,
the
inode
level,
without
knowing
anything
about
directories,
but
the
forwarder
could
make
benefit
of
that
and
everything
on
top
of
that.
What
this
then
typically
use,
I
call
the
logical
file
system
would
be
handled
differently
in
a
different
operation.
A
A
F
F
Yeah
but
exactly
should
it
be
added
inside
the
directory
document,
or
is
it
really
in
the
inode
itself
and
I
think
they're,
as
you
say,
things
have
changed.
What
I
see
from
other
object,
drop,
show
objects,
and
I
point
out
now
the
dats
or
the
hyper
core.
They
really
try
to
stick
to
one
sort
of
hash
based
thing
and
then
how
you
use
these
hash
based
things.
Is
you
have
a
second
one?
F
So
what
I
mean
you
say
a
base
document.
There
could
be
a
two-based
document,
one
exactly
only
the
inode
level,
the
the
hash
based
pure
binary
thing
and
then
the
second
more
file
system,
annotation
hints
whatever
you
want
in
a
second
one.
They
of
course
both
would
be
existing,
but
they
would
have
a
clear
focus
and
you
would
wouldn't
have
one
some
of
the
questions
we
had
today.
A
Again,
if,
if
the
thing
that's
in
the
index
table
does
not
require
any
annotations
on
the
individual
index
entries,
I
can
see
how
to
get
there.
Yes,
but
if
the
individual
index
entries
in
order
to
do
the
more
sophisticated
functions
need
annotations
either
they
have
to
be
there
on
day
one
or
you
have
to
have
defined
an
extension
mechanism
in
the
base
back
to
be
able
to
add
them
later.
F
F
F
F
I
mean
so
I
mean
this
is
now
starting
to
to
become
work
and
trying
to
solve
the
work.
While
we
are
discussing,
I
mean
we
had
some
use
cases
of
manifest
that
you
can
do
that.
You
can
extend
and
the
the
question
is:
if
we
try
think
about
splitting
the
document,
can
we
really
then
assign
these
use
cases
or
how
we
wanted
to
use
fix
really
in
which
of
the
documents
they
belong?
So
that
is
something
that
would
have
to
be
done.
F
If
we
go
for
a
document
splitting,
it
was,
for
example,
relocating
or
moving
a
complete.
Let's
call
it
flick
now
a
pure
flick
to
some
other
repo
or
provider.
It
is
all
possible
still
if
we
do
the
split
or
at
the
end,
we
will
have
to
merge
it.
This
is
something
I
can't
really
tell
and
functionality
wise
we
might
have
to
quickly
look
at,
but
I
understand
dave
has
basic
objections
of
inefficiency.
If
we
have
to
redo
the
same
thing
right
right,.
A
So
so
so
my
intuition
here
is
that
we
could
probably
break
off
some
of
the
stuff
around
what's
now
called
name
spaces,
and
we
might
change
to
something
else
and
a
few
of
those
things.
But
if
you
think
about
the
point,
the
the
annex,
the
index
table
entries
or
pointer
annotations,
I
don't
see
how
you
add
them
later.
So
I'll
give
you
an
example,
one
of
the
one
that
we
define
is
size
right.
F
A
F
F
A
F
Is
there
a
possibility
to
have
the
methadone
really
as
a
shadow?
It
would
be
really
only
let's
call
it
as
a
directory
level.
You
have
a
kind
of
a
second
manifest
before
the
size
information
that
is
then
compact,
you
know,
so
you
can't
you.
Instead
of
having
one
tree
where
every
node
is
annotated,
you
have
two
trees,
one
with
the
raw
bits
and
the
other
with
the
raw
size
information,
and
that
this
raw
size
information
can
be
much
more
compact.
D
D
Yeah,
so
so
so
doing
doing
a
parallel
tree
metadata.
You
know
whether
it's
size,
information
or
you
know
like,
like
the
other
annotations
that
you
would
typically
typically
put
in
there
are
things
like.
Does
this
hash
point
to
another
manifest?
Or
does
this
point
to
data
or
things
like
you
know,
time
codes
or
you
know
other
things
that
might
help.
You
pick
the
right
thing
to
choose
from
yeah
sure
that
that
that's
another
way
of
doing
it
and
and.
D
D
F
D
F
A
F
D
Yep
you
know,
then
you
also
have
like
the
version
thing.
You
know
if,
if,
if
you
have
your
manifest
published
under
one
name
and
then
you
have
your
annotation
published
under
another
name,
and
then
you
update
it,
you
know,
then
the
consumer
has
to
be
sure
that
they're
getting
whatever
the
current
you
know,
annotation
is
for
that
matter.
F
D
F
It's
but
the
dangerous
thing
is
here
we
are
inventing.
While
we
discuss
the
solutions,
I'm
not
sure
we
should
do
that.
I
was
starting
with
the
scope,
discussion
and
trying
to
see.
Are
we
really
confident
that
we
have
the
right
path
to,
or
should
we
have
a
round
of
checking
the
potential
split
or
whatever
other
kind
of
trying
to
reduce
to
something
that
that
is
not
controversial?
Let's
call
it
that
way.
D
C
D
B
A
A
D
Well,
yeah
yeah,
so
there'd
be
a
bunch
of
different
ways
of
doing
it.
You
know
that
that
might
be
getting
too
in
the
weed,
but
yeah.
That's
that's
what
I'm
saying
you
know,
there's
there's
there's
issues
about
how
they
might
get
out
of
sync
that
you
have
to
be
careful
about
what
I'm
you
know.
Maybe
a
related
question
to
that
is,
if
we
just
have
this
simple
cash
pointer,
manifest
with
no
annotations
in
this
top
level
manifest
that
says
this
is
the
data
and
this
is
the
annotation.
D
F
A
So
one
thing
is
one,
so
one
thing
I
think
we
could
split
out
is:
what's
been
called
name
spaces
right.
In
other
words,
the
basic
document
assumes
you
know
how
to
construct
an
interest
name
and
fetch
things.
When
all
you
have
the
hash
pointers,
and
the
second
document
says
maybe
only
allow
it
in
a
top
level
manifest
which
limits
your
flexibility
somewhat,
but
not
a
lot
that
says
you
know
this
top
level
manifest.
Has
this
extra
data
structure
that
contains
the
name
constructors?
A
A
D
Yeah
yeah,
you
know
what
one
path
you
know
we
we
tried
to
avoid
was
saying
they're,
you
know,
you
know
ignoring
the
annotations
for
now,
but
just
talking
about
what
I
call
name
spaces
is
not
having
a
different.
You
know
a
a
schema
for
a
root
manifest
versus
a
you
know:
interior
node
versus
the
leaf
manifest.
D
You
know
the
way
it's
written
right
now,
there's
just
one
syntax
for
all
manifests
where
you
know,
regardless
of
its
position,
we
make
some
recommendations
that
say
well,
you
should
probably
do
this
only
in
the
root,
but
but
there's
nothing
that
says
you
can't
do
it.
You
know
wherever
you
choose
to,
if
you
have
a
good
reason
to.
D
F
B
Not
so
christian,
what
are
exactly
the
reasons
to
split
the
document
into
like
one
or
two
with
different
features?
Is
it
because
you
think
the
features
are
controversial
and
we're
not
quite
sure
which
one
we
really
need,
or
is
it
just
the
complexity
argument
that
we
made
take
too
long
to
to
get
them
written
up
correctly.
F
F
If
we
separate
that
out,
we
can
have
different
ways
of
doing
directories
doing
hints
having,
for
example,
you
can
offer
alternate
ways
to
fetch
stuff,
I'm
not
sure
if
the
choice
currently
can
be
easily
found
in
the
manifest
or
you
have,
by
the
way,
three
different
ways
to
access
the
bits.
I
mean
there
are
many
different
ways
to
then
to
handle
this,
but
we
need
a
first
basic
way
to
keep
the
bits
together,
and
that
is
so
it's
an
architectural
concern.
I
have.
B
D
All
right
so
yeah,
I
I
mean
you
know
you
know.
Clearly
you
could
put
a
pointer.
You
know
at
the
top
level
of
a
manifest
that
says
you
know
here's
where
you
could
find
you
know
some
sort
of
annotation.
For
this
manifest
and
and
not
you
know,
and
you
know
you
could
leave
the
specifications
about
what
those
look
like
to
separate
documents.
D
D
So
you
know,
maybe
one
person
wants
to
just
put
like
the
annotation
pointer
and
the
name
space
construction
directive
in
in
in
some
top
level
things
and
people
always
have
to
fetch
that
and
walk
down
from
it.
You
know
another
producer
might
say.
Well,
you
know.
I
know
that.
There's
these
break
points
every
so
often
where
someone
might
be
joining
in.
D
E
F
Well,
the
one
of
the
slides
said
we
need
volunteers.
So
if
I
said
I
volunteered
to
take
part
of
a
brainstorm
afternoon
and
exactly
do
that
split
discussion,
is
it
worth
or
not
so
who
would
join?
Who
would
join
me
in
doing
such
an
exercise,
or
am
I
running
here
too
traversal
and
you
would
like
rather
prefer
to
go
on
with
the
current
path
and
just
get
it
ready
for
november,
and
we
don't
consider
splitting
at
all.
A
Well,
we
want
to
get
things
we
want
to
get
things
right.
We
don't
want
to.
I
mean
this
is
a
research
group
right,
so
we're
not
driving
towards
some
kind
of
standardization.
That
has
you
know
five,
just
5g
deployment,
deadlines
and
stuff
like
that.
So
you
know
if
there's
important
questions
outstanding,
that's
the
purpose
of
a
research
group
which
is
to
explore
them.
A
E
A
That's
true,
but
that
could
be
again.
You
know
that
could
be
in
the
manifest.
It
could
also
be
secret
information
in
the
application.
Just
like
remember
when
people
construct
name
spaces,
there's
all
kinds
of
side
assumptions
about
various
semantics
and
structures
that
are
not
explicitly
encoded
in
the
name.
A
Well,
I'm
not
I
mean
I'm
not,
I'm
I'm
not
arguing
against
this.
This
name
construction
thing
I
think
it's
very
useful,
but
I
don't
think
the
lack
of
it
prevents
an
application
from
you
know
having
something
in
the
code
that
already
knows
how
to
interpret
a
manifest
that
doesn't
have
that
information.
D
C
So
I
I
that
doesn't
it's
awesome.
That's
that's
a
great
point,
but
I
think
it
would
be
very
helpful
to
sort
of
stake
out
the
classes
of
applications
that
this
thing
is
is
designed
to
support
and
when
I
I'm
as
I'm
listening
to
this,
I'm
thinking
about
the
implications
for
somebody
that's
going
to
build
a
library
and
maybe
a
transport
protocol.
C
That's
going
to
make
use
of
this
fundamental
building
block
protocol
to
support
applications
right
and
you
know.
The
other
observation
is
that
history,
I
think,
suggests
that
getting
a
simple
thing
out
there
and
and
letting
people
build
on
it
and
learn
with
it
is
the
as
opposed
to
trying
to
and-
and
I
I
totally
hear
what
you're
saying
mark
and
I
think
some
of
the
applications
make
a
lot
of
sense
like
having
the
ability
to
put
metadata
in
you
know
deep
down
in
the
structure
and
those
kind
of
things.
A
The
second
is
what
explicit
features
do
you
put
in
so,
for
example,
in
terms
of
the
annotations
we
didn't
put
all
these
annotations
in
we
put
one
in
just
so:
we'd
have
a
proof
of
concept,
which
is
the
the
object
size
right,
but
there's
an
eq.
But
the
question
is:
what
do
you
do
if
you
have,
if
you,
if
you
promulgate
a
a
very
basic,
the
only
thing:
that's
there
is
the
pointer,
and
then
you
decide
gee
it'd
be
really
nice
to
have
this
annotation
right,
then.
A
D
D
I
guess
I'm
much
more
in
the
camp
of
saying
that
the
manifest
needs
to
be
explicit
about
how
you
generate
the
name
and-
and
you
know,
because
what
once
it's
out
there,
I
don't
necessarily
know
what
what
application
generated
it.
You
know,
if
you
want
these
things,
to
only
be
useful
within
one.
You
know.
Individual
application
domain
then
sure
keep
it.
You
know
opaque,
but
I
I.
F
F
There
might
be
different
ways
to
do
that,
so
I
I
see
you
argument
about
sensibility.
Where
should
it
be?
I'm
still
not
convinced
we
have
to
put
it
in
the
hard
drive
in
and
the
lower
bits
on
each
block
and
that
it
would
like
in
the
unix
case,
you
could
separate
that
out
at
the
high
level
and
have
many
different
file
systems
and
using
the
parallel
three
con
approach
to
run
their
file
system,
they
would
have
their
own
documents
and
application.
Libraries
would
say:
okay,
I,
this
is
the
on
the
market.
F
Okay,
so
I
would
probably
then
start
thinking
about
having
an
intermediate
annotation
layer,
three
different
parallel
structures,
but
I
I
see
the
the
critique
that
will
immediately
come
for
that,
but
I
try
to
put
it
again
on
the
meta
level.
I
would
I
think
it's
worth
doing
that
study.
We
have
now
spent
now
what
is
it
an
hour?
20,
I'm
not
sure
we
conclude
today
so
yeah.
I
still
stand
to
that.
F
B
B
It's
more
like
we
don't
really
know
yet
how
applications
will
end
up
using
flick
and
manifest
in
the
end.
So
what
we
I
think
are
interested
in
in
is
enabling
more
experiments
enabling
more
people
to
to
build
applications-
and
you
know
play
with
with
flick,
manifests,
and
that
could
be
an
argument
to
produce
say
one
specification
now
that
allows
you
to
do
all
these
things
in
like
different
ways
so
that
we
have
this
flexibility
built
in.
So
that
could
be
an
argument
against
spitting.
F
B
E
A
I'm
missing,
you
are
you
saying,
and
now
we
we
do
two
ver.
We
we
do
two
manifest
specifications,
one
in
the
style
you're
talking
about
and
one
in
the
style,
that's
the
current
document
and
then
let
application
people
decide
which
one
they
want
to
try
and
experiment
with.
I
would
be
in
favor
of
that
christ.
We
have
two
completely
different
wire
format:
protocols.
F
F
A
A
Right
we
didn't
discover
for
five
years.
It's
like
for
more
than
five
years.
The
selectors
are
probably
a
bad
idea
right,
so
perhaps
we'll
put
some
features
in
now
on
the
presumption
that
they're
useful
and
find
out
later
that
they're.
Not
that's,
certainly
that's
certainly
a
danger
right,
but
that's
what
research
is
about.
D
D
You
know
thing
to
think
about,
and
you
know
see
what
it
looks
like
you
know,
for,
for
the
name,
space
or
or
or
you
know,
main
creation
mechanism,
you
know
it
it,
it
doesn't
need
to
be
as
flexible
as
it
is
in
the
current
draft.
We
could
just
make
it.
You
know
like
one
thing
that
exists,
you
know
somewhere
in
the
manifest,
and
it's
not
repeated
it
can't
be
different
between
hash
groups.
D
It's
you
know,
just
a
you
know,
one
specification,
you
know,
that's
fine
as
long
as
it's
something
you
know,
so
we
we
could
simplify.
You
know
how
how
that
is
done.
We
could
break
out
the
you
know.
We
could
just
have
the
very
simple
pre-shared
key
encryption
in
the
document
and
break
out
the
others
to
other
documents,
but
you
know
as
long
as
they're
done
in
parallel,
so
we
know
that
they
all
have
you
know
are
likely
to
work.
You
know
that
that's
fine
with
me
too,
so.
A
A
So
if
splitting
things
up
in
two
layers
complicates
encryption
or
doesn't
complicate
encryption
that
that
that's
that
that
makes
it
less
of
a
burden,
but
if
it
turns
out
that
it
it
makes
encryption
harder.
That's
a
counter
argument
right.
So
it's
something
that's
something
to
look
at
right,
whether
yeah,
you
know
if,
if
the,
if
the
basic
thing
can
be
signed
with
a
different
key
from
the
annotation,
what
does
that
mean?
Is
that
is
that
a
feature
or
is
it
a
bug?.
D
D
E
D
It's
written
up
and
and
as
far
as
the
parallel
tree
annotations,
you
know
as
far
as
I'm
concerned,
the
the
the
the
syntax
or
grammar
of
those
annotation
objects
is
like
completely
wide
open.
You
know
it
doesn't
need
to
be
anything
at
all.
That
looks
like
the
flip
grammar,
though
you
know,
keeping
it
closer
would
make
implementation
a
lot
easier,
but
so
yeah,
but
but
you
know
that
that
kind
of
gets
you
know,
depending
on
how
much
you
pry
it
open
to
being
different.
A
D
A
D
F
Yeah,
I
will
not
engage
right
now
in
that
discussion
that
I
suggest
it
would
be
an
afternoon,
but
maybe
ask
the
following:
do
we
have
a
notion
of
a
kind
of
another
standards,
kind
of
profile,
a
kind
of
a
let's
call
it?
The
compliance
application
would
add
me
at
least
need
to
implement
that
but
optionally
this
or
what
is
your
feeling
about
the
zero
two
standards,
all
the
things
written
down.
There
must
be
more
or
less
implemented
to
be
part
of
the
game.
D
Right,
so
so,
so
what
let
me
bring
up
one
other
option
for
the
annotations
which
which
I
think
we
talked
about
like
ages
ago,
but
one
is
to
do
parallel
data
structures,
but
in
the
same
manifest,
so
I
can
have
a
hash
group.
That's
just
a
list
of
data
of
data
pointers
and
it's
the
simple
thing.
Then
I
could
have
another
group:
it's
not
a
hash
group
anymore.
D
It's
like
an
annotation
group
that
has
my
annotations
that
I
have
to
keep
aligned
with
my
pointers,
but
it's
all
in
the
same
data
structure
right.
It's
not
a
it's,
not
a
separate
object
that
I'm
doing
this
with
it's
all
one
object,
and
so
I
just
have
basically
two
arrays
or
three
arrays
or
four
arrays
that
I
make
all
the
same
size.
D
So
I
I
I
I
it
it.
You
know,
that's
another
approach
to
it.
So
in
that
example,
a
minimum
compliant
application
only
needs
to
understand
the
hash
groups
that
have
pointers
in
it.
It
doesn't
need
to
understand
hash.
You
know
other
groups
they're,
not
a
hash
group
anymore,
they're,
an
annotation
group.
It
doesn't
need
to
understand
any
annotation
groups.
They
can
just
ignore
those.
A
F
A
A
A
C
D
That
yeah
yeah,
so
you
know
we
would
probably
you
know,
start
just
calling
them
like
a
group
and
a
hash
group
would
be
specifically
a
group
that
has
hashes
in
it.
Then
you
would
have
you
know
different
annotation
groups
that
would
have
whatever
it
is
they
have
in
them
and
those
could
all
be
specified
in
different
documents.
C
D
It'll
be
pretty
close,
you
know
the
it'll,
be
you
know
well
yeah.
So
who
knows
what
your
memory
architecture
is
like,
but
yeah
you
know
you.
You
would
be
able
to
find
each
group
easily
because
each
group
has
its
own
length.
So
you
just
skip
ahead
to
the
next
group
in
the
next
group
and
you
find
all
the
groups
and
so.
B
A
B
So
I
mean
maybe
it's-
we
spent
like
90
minutes
on
this
now
as
a
constructive
proposal.
How
about
planning
for
having
this
technical
discussion
on
the
say
document
or
specification
structure
so
that
we
kind
of
could
plan
for
another
meeting
where
we
maybe
invite
say
a
few
proposals
so
for
how
we
organize
the
specification
in
the
future.
So
I'm
I'm
hoping
that
christian
would
be
able
to
prepare
some
ideas.
A
Discussion
yeah
by
the
way,
it
would
be
really
helpful
in
that
discussion
to
have
some
input
given,
but
now
that
I
look
at
who's
on
the
call,
it's
some
people
who
have
built
ndn
applications
would
weigh
in
on
what
what
they
would
like
to
see.
If
anything,
I
mean
some
people
build
ndn
applications
without
using
manifests
at.
B
Yeah,
so
I
was
thinking
we
seem
to
have
exhausted
the
kind
of
discussion
of,
say,
different,
say,
preferences
and
potential
pros
and
cons.
I
think
next,
what
we
need
is
yeah,
some,
some
more
yeah
thinking,
time
and
moment
like
preparing,
so
writing
things
up
in
a
more
structured
way,
so
that
we
can
really
have
this
say
next
level
of
technical
discussion.
Otherwise
I
don't
think
we're
making
much
progress
if
we
continue
today.
A
Yep,
so
here's
a
suggestion:
let's
go
often,
you
know,
exchange
ideas
over
email
for
a
while
next
week
is
sig
com,
so
I
would
not
suggest
we
try
to
push
things
that
early,
but
that
we
schedule
we.
We
need
some
kind
of
deadline
to
motivate
people
and
some
maybe
we'll
do
something
in
a
couple
of
weeks.
A
D
F
A
B
F
F
F
E
D
D
D
F
D
E
F
B
F
B
E
B
Yeah,
I
think
the
discussion
actually
really
really
had
to
understand
this
concern
and
so
the
different
options
that
we
have
in
front
of
us.
So
thanks
a
lot
everybody
so
looking
at
the
clock,
it's
here
in
1946,
is
there
anything
else
on
on
flick
or
the
manifest
topic
at
large
that
we
should
discuss,
or
at
least
bring
up,
not
forget
about.