Minutes interim-2020-icnrg-03: Mon 18:00
||Minutes interim-2020-icnrg-03: Mon 18:00
# ICNRG Meeting 2020-08-03: FLIC
* DaveO presented
* Christian: Segmented prefixes & directory features -- file system-like.
Which are the core features, which features should be add later?
* Marc: Namespaces have two aspects:
1. name elements that go into an INTEREST
2. each hashgroup can have its own namespace. Do not necessarily have to
point to different files.
* Christian: F-LIC vs. D-LIC?
* should we constraint FLIC to just hashes?
* danger of introducing loops?
* Marc: different namespace are all for hash-based names
* difference is how to construct prefix for the hash
* Christian: so, we won't have loops?
* Marc: yes
* Ken: not obvious
* Dave: retrieval loop vs. traversal loop
* Marc: FLIC manifest is still a hash tree
* child node cannot point to parent node
* Dave: are there features that might not be put into core spec?
* Marc: need to support preferred ways of naming data objects
* CCN would prefer hash-based naming
* NDN would prefer segmented prefix naming
* Ken: sent comments to list. Comments on 02 draft:
* trying to abstract from differences between CCNx and NDN -- some things
are unclear * Inode model seems useful * but documents talk about
additional ways of using FLIC
* Dave: Inodes for files and directories are different (in filesystems)
* Ken: argueing for simple approach
* Marc: might be better to keep the inode anology to the beginning of draft only
* analogy has some limitations
* Ken: when hash value inside manifest -- can I tell whether it points to
another manifest or app data?
* Dave: yes
* Marc: pointers can have labels
* Dave: two observations:
1. If we strip down to basics, can we succesfully split the document in two
pieces, so that more advanced features can be specified as add-ons (instead
of having a set of independent documents)? 2. namspace terminology may be
problematic (maybe something like "name constructors")
* Marc: applications can organize manifest in different ways
* so that consumers don't have to fetch objects to tell whether something
is data object or manifest
* Marc: important to work out a few different ways for doing encryption
* to make sure that basis spec supports encoding these variants
* Christian: could we base document scope on what forwarders have to understand?
1. one document that looks at Inode level (that is relevant to forwarders)
2. one document that deals with directory features
* Dave: traversal order and hash order can be important to apps.
* If we had to invent extension mechanism -- does it take you already 90%
towards supporting extended features?
* Christian: can also split into core hash features and annotations etc.
* Dave: if individual index entries need annotations than splitting might not
* forwarders do not necessarily have to look at manifest at all
* Christian: would we be able to assign use cases two different specification
(if we did the split)?
* Dave: we could possibly break off namespace-related things, but some
annotations could be useful for basic use cases already
* e.g., size
* Christian: could we have meta data as a "companion tree"?
* Dave: need more RTs to fetch metadata then?
* Marc: could be one way of doing it
* Marc: combined approach could be less error-prone (with separate trees,
you would have to make sure trees will be aligned) * Christian: could also
be a feature if could re-publish meta-data independent from actual data *
Marc: how to tell that the current annotation manifest is?
* Marc: topics in 02 draft that are related complexity discussion:
* annotated pointers vs. naming convention
* Dave: index-table / hash-group data structure without annotation in
individual entries -- how would one annotate them -- separate data structure?
* Marc: top-level manifest needs to say which manifest is for data and which
one for annotations
* Dave: what could be split out:
* Marc: we tried to avoid not allowing for a different schema for root
manifests vs. interior node manifests
* Christian: two arguments:
2. architectural argument: evolvability, can have different ways to
construct directories etc.
* Marc: thinks is good to have flexibility for producers to specify annotations
etc. at different locations
* Christian: brainstorming on splitting?
* Ken: would be helpful to name the classes of applications that FLIC is
expected to support
* value in producing a simple specification
* Dave: simplicity lacking extensibility may be problematic, too
1. what extensibility mechanisms do you put it?
2. what core features?
* Marc: manifest should be explicit on app generates its names
* consumers should be able to fetch manifest and figure out how to
construct names from manifest itself
* Christian: parallel specification approach
* Marc: in favor of having a more technical discussion on that
* Marc: namespace / name creation does not have to be that flexible --
could be simplified * Marc: could have pre-shared key encryption in based
spec only and break out other stuff * Dave: splitting up should not
complicate signing and encryption * Marc: idea could be to split
RSA-related things into separate document
* Christian: how do we deal with profiles, optional features etc?
* Marc: options for annotations:
1. parallel data structures, but in same manifest (annotation group),
all in same data structure, i.e., multiple arrays with all the same
size. Minimal app only needs to understand hashgroups
* Dave: can have typed hashgroups specified in different documents
* Dirk: plan for a technical discussion
* invitited different proposals, ideas
* Dave: exchange ideas by e-mail for a while, plan for a meeting in a
couple of weeks, Aug 24 or later * Marc: will write an e-mail to list
describing different ways to do annotations
* second e-mail on namespaces (name constructors, name templates etc.)
* Possible meeting topics
* how to deal with annotations
* how to deak with name constructors
* Spec structure
* how to manage the documents to specify that
# This section of the notes is to record action items and assigned person
- Editorial pass of FLIC-02 for general cleanup - DaveO
- IANA/Security considerations
- Manifest Manifesto: Christian
* Marc's Python implementation
* Christian's old C-based code, wants to move to Python