Re: [icnrg] Options for FLIC NameConstructor

["David R. Oran" <[e-mail]>]

This seems eminently reasonable.
Couple of things embedded.

On 2 Sep 2020, at 18:33, Marc Mosko wrote:

> All,
>
> Here are some options on refactored name constructors for FLIC 
> manifests.  We could allow only a single NameConstructor in a Manifest 
> (in which case both data and manifest objects would be in the same 
> namespace), or we could allow one NameConstructor per hash group (in 
> which case manifest and data could be in separate namespaces).
>
Let me check my understanding here. If we adopt the file system analogy, 
we’d lack “softlink” capability if we forced manifests to be in 
the same namespace as data? In which case I’d strongly advocate for 
allowing a NameConstructor per hash group.

> I’ve represented TLV structures more like nested procedures, 
> hopefully this is easily understandable.
>
> NameConstructor(type = TYPE_0, length = …) {
>                 # Whatever name was used in the Interest for this 
> Manifest,
> # use that name for the next Interest plus the hash restriction
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
>
I wonder if routing hints belong in a Manifest as opposed in some other 
machinery. Would be good to discuss the design implications a bit. It 
seems routing hints might want to change way more frequently than the 
structure and naming of data. Also, there may be some security questions 
raised by this, as one would think that routing hints would want to be 
signed by *both* the producer *and* the network operator, just like 
other routing information.

> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
>
These make sense to me. Good inclusion from my point of view.

> NameConstructor(type = TYPE_1, length = …) {
>                 # Use any of these names in the Interest plus the hash 
> restriction
>                 UnorderedList(type = 0, length = …) {
>                                 # W could be the existing TLV type for 
> a name
>                                 Name(type = W, length = …) { … }
>                                 …
>                                 Name(type = W, length = …) { … }
>                 }
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
>
…as above…

> NameConstructor (type = TYPE_2, length = …) {
>                 # Use the name of this Manifest plus a hash 
> restriction
>                 # (does not apply to nameless objects)
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
>
…as above…

> NameConstructor (type = TYPE_3, length = …) {
>                 # Use any of these names, append the segment number 
> and
>                 # use the hash restriction.  The segment number is 
> computed sequentially
>                 # for each hash group number.  If you allow 
> NameConstructors per HashGroup, then
>                 # the manifest tree has its own segment # counter and 
> the Data tree has its
>                 # own segment # counter.  In this case, the 
> UnorderedList is likely of length 1.
>                 UnorderedList(type = 0, length = …) {
>                                 Name(type = W, length = …) { … }
>                                 …
>                                 Name(type = W, length = …) { … }
>                 }
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
…as above…

>
> Marc

> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO