Nexus Observatory Sign inCreate account
Observatory Protocol

/

Specification

/

Implementers

Profiles and planes for implementers.

What an implementation of each profile must provide, and the planes across which it communicates.

Read the specificationContribute
Functions
12
State machines
11
Objects
21
Standards
48

The practice this part continues.

1984 End to end, rough consensus
Saltzer, Reed and Clark argued that functions placed in the network can be completely and correctly implemented only with the knowledge of the end systems; RFC 1958 recorded the principle for the Internet’s architecture. The IETF’s working method, summarised in RFC 7282 as “rough consensus and running code”, sets the standard for how an open protocol should change. The protocol keeps authority at the site and changes only through open proposals. [1][2][3]

What each implementation provides.

Choose the profile that matches what you build; it names the functions you must implement.

Node agents and devices
OBSP-NODE: Join, Describe, Time, Observe, Qualify, Orchestrate (apply), Exit.
Site controllers
OBSP-SITE: OBSP-NODE plus Admit (local), Orchestrate (plan), Correct, Prove (verifier).
Cluster and grid control planes
OBSP-GRID: OBSP-SITE plus Federate and Exchange.
Hardware, software, model and data providers
OBSP-PROVIDER: Admit, Describe, Exit.
Applications reading products
OBSP-CONSUMER: Exchange, Correct (subscribe).

Four ways into the specification.

Specification

The functions

The twelve functions and their requirements.
Specification

The state machines

Typed transitions and their evidence.
Specification

The wire bindings

One open binding per plane.
Specification

Conformance

Profiles and levels.

References

Sources for the historical and standards statements on this page.

  1. Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
  2. Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org/rfc/rfc1958
  3. Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org/rfc/rfc7282
  4. Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org/rfc/rfc2119
  5. Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org/rfc/rfc8174

Read it, test it, propose a change.

The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.

Read the specificationContribute

Enrol an instrument in a few lines.

Agents, SDKs and reference designs for building on the protocol: enrol a node, describe it, keep its clock, publish what it observes. Everything here is planned.

Read it, test it, propose a change.

The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.