Replication Issue [PLACEHOLDER]

[mwherman2000]

Replication Issue [PLACEHOLDER] from today's SDS/CS WG call.

[agropper]

If it's fair to presume that each EDV resource (e.g. JWE) has one resource owner (RO, the entity that gets the capability issued by the EDV), then:

Does EDV replication presume that all replicas are owned by the same RO or, that replicas may be accessed (and become owned by other end-users?

[mwherman2000]

It could be one of a number of different scenarios: Here's one I proposed earlier today: https://hyperonomy.com/2021/03/04/trusted-content-storage-tcs-stack-secure-resource-sharing-srs-using-replicated-stubs-solution-concept/

BTW, I think you can think of someone being the resource owner but it might be better to think of them as Resource Controllers.

[mwherman2000]

If one doesn't have an architecture reference model (ARM) in mind when talking or thinking about replication, it' hard/too abstract to have a fruitful discussion, here's the one I use: Generic Replication Pipeline:

Figure 20. Generic Replication Pipeline (Syntergy Replicator for SharePoint)

Outbound Processing Service Outbound Processing Service is responsible for capturing and recording Replication Events that occur in the Source Repository. Outbound Processing Service is controlled by Replication Maps which determine what Events need to be captured, packaged, and transferred to the Target Repository. Groups of Replication Events are packaged into two types of messages or objects: Queued Items and Replication Packages.

Queued Item A Queued Item is a unit of work to be transferred to a Target Repository for remote execution. The Replicator Web Service on a Target Repository is called to push a Queued Item from the Source Repository to a Target Repository.

Replication Package A Replication Package is a collection of one or more Replication Events plus data about the changed information that is packaged in a format specific to the Replication Transport being used. When an Event is being processed, Outbound Processing Service calls the Source repository object model to extract the changed information from the Source Repository.

Package Transfer Service The Package Transfer Service activity is responsible for the transfer of Queued Items and Replication Packages (Packages) from the Source Repository to the Target Repository. Package Transfer is the process that sits between Outbound Processing Service (on the Source Repository) and Inbound Processing Service (on the Target Repositories).

Inbound Processing Service Inbound Processing Service is responsible for processing the Queued Items and Packages received and accepted by the Target Repository and applying them to the repository. The Queued Items and Packages are applied to the Target Repository content base by calling the Target Repository object model.

The above was taken from an early draft of my Trusted Content Storage architecture (TCS Stack) whitepaper I mentioned on the working group mailing list: https://docs.google.com/document/d/1-Ve263KT7svN7oppIHyhK6idXikcbBsn/edit

[agropper]

@mwherman2000 Naming things is hard and that applies to roles in various use cases. I use the names as defined in GNAP Section 1.2.

I PROPOSE that we incorporate these roles in our discussion. I know they are likely to change and SDS may find reason to diverge but for now, I will raise an issue that we start with the current GNAP roles. #203

[mwherman2000]

Here's a few dimensions to consider in terms of an overall replication service ...based on the above Replication Pipeline...

1. Replication network scenarios a. Offline replication b. Air gap replication c. Slow, high-latency network connections (e.g. Satellite communications to Antarctica): Replicated stubs d. Bi-directional vs. Uni-directional
2. Outbound Replication Processing a. Real-time replication b. Replication filtering c. Selective Replication: Outbound filtering and Inbound package acceptance
   • Content types: content, metadata, schema, container hierarchies, security permissions, security principles, roles, event handlers/workflow instances, configuration settings
3. Package Transfer a. Dynamic, multi-hop routing b. Cross-firewall replication c. Peer-to-Peer (P2P) topologies: Direct and Mediated d. Dynamic, multi-hop routing e. Cross-firewall replication f. Peer-to-Peer (P2P) topologies: Direct and Mediated
4. Replication Inbound Processing a. Multi-master replication b. Conflict management
   • Conflict detection
   • Conflict resolution
5. Security a. Data at rest; data in motion (replication packages) b. Mapping security principles and roles c. Activity anonymity
6. Performance Management a. Bandwidth throttling b. CPU throttling c. Disk management d. Scalability
   • Support for large objects (terabyte blob)
   • Support for large containers (petabytes)
   • High-frequency content changes
7. Failover/service recovery a. Disaster recovery: feasibility, fidelity, time/bandwidth/processing required

[mwherman2000]

@agropper I believe the Sovrin Glossary (and ToIP's clone) are in more common usage: https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.3wjdvvstzjf0

e.g.

Controller An Identity Owner that is responsible for control of another Entity—specifically the Private Keys needed to take actions on behalf of that Entity. For example, a Thing Controller has a Controller relationship with a Thing. It is one of three types of identity control relationships described in Appendix C.