D3 Technical Requirements
Requirement: Legacy device
The ideal solution should be able to address legacy devices. Making meaningful statements about device type should be possible without changing the implementation of pre-existing end devices.
Requirement: Manufacturer Trust
The ideal solution should address the fact that the original manufacturer is not always the best authority on device type. We should allow other stakeholders to create candidate device types and make statements against these candidates.
Requirement: Bootstrap
The ideal solution should address the network effect problem. It should be possible to generate value from device type descriptors without assuming that every manufacturer fully complies with the process.
Requirement: Continuity
The ideal solution should have no single point of failure. Indeed, the mechanism should not be wholly dependent on manufacturer-supplied cloud/IT infrastructure — this independence future-proofs against the legacy problem.
Requirement: Uncertainty
The ideal solution should be able to handle uncertainty. Not every inference about device type identity is entirely reliable or accurate.
Requirement: Interoperable with data sources
The ideal solution should interoperate with pre-existing and evolving methods of asserting and inferring device type identity.
Requirement: Conflict resolution
The D3 system can support data conflicts. Conflicts can be due to inherent uncertainty in the system, or that different D3 providers have different views on the status quo. The D3 inference system must be able to resolve these inconsistencies to conclude an action.
Requirement: Time variation
Observations change over time, and the underlying knowledge contained in a D3 statement may change. The representation of a D3 statement and the inferencing model must support changes to the underlying data.
Requirement: Subjective trust
The D3 client must be able to define their own trust foundations on which D3 inferences can be made.