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:

  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 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:

  1. complexity
  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

  • Technical
    • 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

Implementations

• Marc's Python implementation
• Christian's old C-based code, wants to move to Python