Minutes interim-2020-icnrg-03: Mon 18:00
minutes-interim-2020-icnrg-03-202008031800-00
Meeting Minutes | Information-Centric Networking (icnrg) RG | |
---|---|---|
Date and time | 2020-08-03 16:00 | |
Title | Minutes interim-2020-icnrg-03: Mon 18:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2020-08-06 |
ICNRG Meeting 2020-08-03: FLIC
-
DaveO presented https://www.ietf.org/proceedings/106/slides/slides-106-icnrg-flic-update-dave-oran-00
-
Christian: Segmented prefixes & directory features -- file system-like. Which are the core features, which features should be add later?
-
Marc: Namespaces have two aspects:
- name elements that go into an INTEREST
- 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:
- 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)?
- 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?
- one document that looks at Inode level (that is relevant to forwarders)
- 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 help much
- 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:
- namespaces
-
Marc: we tried to avoid not allowing for a different schema for root manifests vs. interior node manifests
-
Christian: two arguments:
- complexity
- 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
- what extensibility mechanisms do you put it?
- 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:
- 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
- Marc: options for annotations:
-
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
- Technical
- how to deal with annotations
- how to deak with name constructors
- Spec structure
- how to manage the documents to specify that
- Technical
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
Implementations
- Marc's Python implementation
- Christian's old C-based code, wants to move to Python