Re: [icnrg] draft-irtf-icnrg-flic-01

On 8 Jun 2019, at 3:02, Mosko, Marc wrote:

> All,
>
> I will work with Christian and Chris to finish the FLIC draft.
>
> My main technical issue with the draft is there is no way to seek 
> through a tree.   The "OverallByteCount" only applies to child data 
> nodes, so one does not know how many bytes are contained in a child 
> manifest (subtree).  I assume that one would like to be able to seek 
> in log time to any position over the tree.
>
This makes sense, at least for files (I know, the “F” in FLIC).

> It is also not clear if there is anyway to know the total application 
> file size and application hash for an entire subtree, which I assume 
> would be useful stuff at the top level of the manifest.
>
Yes. I also commented earlier that the extensibility model for Manifests 
needs to be spelled out now, so we can evolve the specification without 
either starting over or creating hacks (like a new kind a root manifest 
that contains metadata + a FLIC root Manifest).

> Finally, there is the FLIC encryption introduced in the -01 draft.  I 
> think this needs to be greatly expanded and an example or two given.
We might want to look at the more recent NDN work on explaining NAC to 
see what if any effect that approach might have on FLIC manifests 
(https://users.cs.fiu.edu/~afanasyev/assets/papers/zhang2018nac.pdf)

> Do we want to have one draft without encryption and one draft on an 
> encrypted manifest?  Or keep it all as one?  What I would lean towards 
> is one draft with unencrypted FLICs and a second draft with encrypted 
> FLICs that gives at least one concrete set of algorithms and 
> procedures for adding and removing users.
>
I lean the other way, for two reasons:
1) the management overhead for progressing two specifications, when the 
two are so closely related
2) the political hassle of getting an unencrypted Manifest spec through 
the security and privacy reviewers.

> The draft makes some mention of manifest encryption versus application 
> data encryption.  I am not sure we want to tie those together.  FLIC 
> should be able to assemble an encrypted application payload without 
> any idea how to decrypt it.
>
Yes. The FLIC draft should only deal with encrypted Manifests, with the 
main goal being protecting the privacy of the names/hashes and 
especially any metadata that gets added to manifests.

> Marc
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO