Subject: [icnrg] Options for FLIC NameConstructor

From: Marc Mosko <[email-masked]>
Date: Wed, 2 Sep 2020 22:33:20 +0000

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).

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 #
}

Optional ProtocolFlags(type = TYPE_8, length = …) {
                # e.g. NDN must be fresh, Interest lifetime hints, etc.
}
}

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.
}
}

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.
}
}

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.
}
}

Marc

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 03 Sep 2020 10:27:19 -0400

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.

>                 # 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.

>                 # e.g. NDN must be fresh, Interest lifetime hints, 
These make sense to me. Good inclusion from my point of view.

>                 # e.g. NDN must be fresh, Interest lifetime hints, 
…as above…

>                 # e.g. NDN must be fresh, Interest lifetime hints, 
…as above…

>                 # e.g. NDN must be fresh, Interest lifetime hints, 
…as above…

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

DaveO