[1]An interesting approach to resolving cache "faults" would be for a node to request the method from the node that sent it the faulting capsule - forming a chain back to the originator of the capsule who could be expected to take ultimate responsibility for resolving the reference. Of course, the originator might do so by demand loading the code from their software vendor.

[2]At each hop, a capsule could translate itself into the language that is understood by the "next hop" node along its path. However, this approach seems extreme - even by our standards!

[3]One member of this set would be the method that allows capsules to request extension of their closures.

[4]We assume the availability of appropriate authentication and tamper-proof signature technology.

[5]There may be a further requirement to control the scheduling of some resources, such as transmission bandwidth. There may also be requirements for resource metering, accounting and/or auditing.

[6]Implicitly accepting the upstream node's assessment that the capsule is worthy of bandwidth. A capsule may also include a "lifetime" limit that precludes exponential growth as capsules traverse the network.

[7]If link capacity is a node's most valuable resource, then it may prove reasonable and simple to make other resource allocations proportional to it.

[8]Mechanisms such as those described in [NOW] might be used to "page" soft state to/from nearby nodes.

[9]Nodes may still require small reliable stores to track the state of transactions in progress.

[10]Low level services used in the composition of unreliable services are included in this category.