Individual Submission W. Ackerman Internet-Draft Vertiv Holdings Co. Intended status: Standards Track 8 August 2026 Expires: 8 February 2027 Temporal Integrity Metadata (TIM) for Infrastructure Telemetry draft-ackerman-temporal-integrity-metadata-01 Abstract Distributed computing systems generate timestamped events from components whose clocks operate under fundamentally different synchronization conditions. Existing logging and observability standards -- including legacy BSD syslog (RFC 3164), RFC 5424, SNMP, NETCONF, and OpenTelemetry -- define message formats and telemetry schemas but provide no standard mechanism for an event source to declare the provenance, confidence, or synchronization state of its timestamps. Every platform that must correlate events across components independently invents a proprietary temporal reconciliation layer. These systems fail silently, cannot be validated against a published standard, and are not interoperable. This document defines Temporal Integrity Metadata (TIM): a transport- agnostic structure that any event-emitting system may attach to its telemetry to declare how its timestamp was generated, the synchronization state of its clock, a bounded uncertainty interval, the temporal reference domain, and a monotonic sequence token for ordering events when wall-clock time is unavailable. TIM is backward-compatible with existing protocols, implementable on constrained embedded hardware, and applicable from internet-scale distributed services to air-gapped and orbital deployments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Background and Motivation 1.2. Scope 1.3. Positioning vs. Adjacent Standards 1.4. Why This Standard, Why Now 1.5. Requirements Language 2. Problem Statement 2.1. Internet-Scale Scope of the Problem 2.2. The Temporal Fragmentation Problem 2.3. The Missing Declaration Standard 2.4. Impact Across Application Contexts 2.5. The Precision Discard Problem 2.6. The Temporal Reference Domain Problem 3. Terminology 4. Temporal Integrity Metadata (TIM) Specification 4.1. Overview 4.2. Required Fields 4.3. Conditionally Required Fields 4.4. Optional Fields 4.5. Collector-Populated Fields 5. Temporal Confidence Classes 5.1. Class Definitions 5.2. Class Boundary Rationale 5.3. Domain Scoping of Confidence Classes 6. Sync State Definitions and Transitions 7. Temporal Reference Domains 8. Leap Seconds, Smearing, and Time Scale Conversion 8.1. Leap Second Events 8.2. Leap Smearing 8.3. UTC / TAI Conversion 9. TIM Schema and Examples 10. Implementation Guidance -- Event Sources 11. Implementation Guidance -- Consuming Platforms 11.1. Temporal Reference Manager (TRM) 11.2. Backward Compatibility -- Devices Without TIM 11.3. Cross-Class Efficiency Metric Computation 11.4. Shared-Reference Comparison 11.5. Collector Reference Diversity 12. Relationship to Existing Standards 13. Security Considerations 13.1. Threat Model 13.2. Cryptographic Protection of TIM Fields 13.3. Replay Protection 13.4. Anomaly Detection 13.5. Multi-Classification Environments 14. IANA Considerations 15. References Appendix A. Deployment Scenarios Appendix B. Change Log Author's Address 1. Introduction 1.1. Background and Motivation Distributed computing systems generate timestamped events from components that do not share a common time reference. This is not an edge case -- it is the default condition of every networked system at scale. A web request traverses a CDN edge node, a load balancer, an application cluster, a distributed cache, and a database, each with independently synchronized clocks, generating log entries that are later correlated to diagnose performance or reconstruct an incident. The assumption embedded in that correlation -- that the timestamps are comparable -- is almost never verified and almost never declared. The same assumption fails in security operations (SIEM platforms correlating events across firewall, endpoint, identity, and network logs), in financial systems (distributed transaction processors ordering trades across geographically separated nodes), in telecommunications (call trace platforms reconciling CDRs across SIP proxies, media servers, and billing systems), and in industrial and infrastructure environments. In every case, the receiving system has no standard basis for knowing how trustworthy the timestamps in its event streams actually are. This document observes that the problem has been solved repeatedly, in isolation, for specific domains. The broadcast and motion picture industry solved an analogous problem in 1969 with SMPTE 12M, establishing the principle that a timecode label is not the same as actual time, and that synchronization state must be explicitly declared. Google's TrueTime [SPANNER] solved it for globally distributed databases in 2012 by representing timestamps as bounded uncertainty intervals rather than point values. What has never existed is a single, transport-agnostic standard that any event- emitting system can use to declare the quality of its timestamps. This document defines that standard. 1.2. Scope This specification defines the Temporal Integrity Metadata (TIM) standard. The following are within scope: * The TIM structure: a transport-agnostic metadata block for declaring timestamp provenance, synchronization state, uncertainty bounds, temporal reference domain, and sequence ordering * Sync State definitions: six states covering all operational scenarios from GPS-locked to sequence-only * Temporal Confidence Classes A through F: derived from declared sync state, uncertainty bounds, and temporal reference domain * Temporal Reference Domains: covering terrestrial UTC, orbital, cislunar, and facility-autonomous environments * Leap second, leap smearing, and time scale conversion behavior * Cryptographic protection and replay resistance for TIM metadata * Implementation guidance for event sources and consuming platforms Fundamental design principle: This specification does not require the existence of a globally synchronized time source. It defines a framework for expressing temporal information under conditions where such a source may be unavailable, unreliable, or undesired. Non-Goals -- this specification explicitly does NOT: * Synchronize clocks, discipline oscillators, or improve the accuracy of any time source * Replace or supersede existing timestamp fields in any protocol, log format, or telemetry schema * Guarantee the accuracy of declared values -- TIM declares the emitting system's temporal state at the time of emission; it does not certify objective accuracy * Define transport mechanisms for telemetry or modify existing message formats * Provide causal ordering guarantees -- TIM enables systems to reason about the bounds within which causal ordering can and cannot be established; it does not guarantee causal correctness 1.3. Positioning vs. Adjacent Standards TIM occupies a specific and previously unoccupied layer in the distributed systems standards stack: +=================+==================+===========================+ | Layer | Standard(s) | What It Addresses | +=================+==================+===========================+ | Time | NTP ([RFC5905]), | Making clocks accurate | | synchronization | PTP [IEEE1588] | | +-----------------+------------------+---------------------------+ | Telemetry | OpenTelemetry | Defining what telemetry | | schema | [OTEL] | data looks like | +-----------------+------------------+---------------------------+ | Distributed | W3C Trace | Propagating trace/span | | correlation | Context [W3C-TC] | IDs | +-----------------+------------------+---------------------------+ | Temporal trust | TIM (this | Declaring how trustworthy | | | document) | timestamps are | +-----------------+------------------+---------------------------+ Table 1: TIM in the Distributed Systems Standards Stack TIM does not replace any of them; it provides the missing fourth layer. NTP (RFC 5905) and PTP (IEEE 1588): These protocols synchronize clocks. TIM declares the quality of whatever clock a system has, regardless of whether it has been synchronized. A system with perfect PTP synchronization should declare TIM Class A. A system with no time reference should declare TIM Class F. Both are valid and useful declarations. OpenTelemetry (OTel) [OTEL]: OTel defines schemas for traces, metrics, and logs with timestamp fields but provides no mechanism for declaring how trustworthy those timestamps are. TIM operates orthogonally to observability schemas: it annotates time, not telemetry semantics. TIM is the missing provenance layer for OTel timestamps. TIM fields SHOULD be expressed as OTel resource attributes, extending OTel rather than replacing it. W3C Trace Context [W3C-TC]: Distributed tracing carries trace and span IDs but contains no timestamp information. Timestamps in distributed traces are assigned by each service independently. TIM provides what distributed tracing assumes but never defines: a standard for declaring the reliability of those timestamps. Legacy BSD syslog (RFC 3164) and RFC 5424 syslog: [RFC3164] documented, for informational purposes, the de facto BSD syslog protocol and deferred timestamp quality to the application layer. [RFC5424], which obsoletes it, added structured formatting but left the same gap. TIM fills this gap without modifying either specification. 1.4. Why This Standard, Why Now This problem has existed since the first distributed computing system was assembled. Four developments make standardization critically important now: AI systems, automation, and decisions without human validation: AI inference pipelines, autonomous vehicles, robotic control systems, and AI agents making real-time decisions operate on event streams without a human in the loop. When an autonomous system misorders two events, it may make an incorrect inference with no opportunity for correction before the next decision cycle. As the tempo of automated decision-making accelerates and human oversight decreases, the accuracy of event ordering becomes a safety and reliability property. The absence of a timestamp quality standard means every AI system must either assume all timestamps are reliable (they are not) or invent its own assessment (no two systems agree). Zero-trust security and audit requirements: The zero-trust model requires forensically defensible audit trails. An audit trail constructed from timestamps of unknown quality is legally and forensically weak. Regulatory frameworks increasingly depend on trustworthy event timing. MiFID II (RTS 25) explicitly mandates clock-synchronization accuracy and traceability to UTC for reportable events; NERC CIP, HIPAA, and the EU AI Act impose audit, logging, and record-keeping obligations whose evidentiary value rests on timestamp quality that no current standard lets a system declare. TIM provides the declaration vocabulary these regimes presuppose. Edge computing and IoT at scale: Edge deployments and IoT systems involve billions of devices with highly variable clock quality. Aggregating their events for anomaly detection and operational intelligence requires honest temporal integrity declarations at scale. Regulatory convergence: Multiple regulatory bodies are independently requiring timestamp accuracy declarations. The White House OSTP directive on cislunar time standardization [OSTP-LTC] is one example. A single open standard that serves all these contexts is preferable to parallel proprietary solutions. 1.5. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Problem Statement 2.1. Internet-Scale Scope of the Problem The absence of a timestamp quality declaration standard is not a niche infrastructure problem. It is a structural deficiency present in every distributed computing system on the internet. The global volume of timestamped events generated across internet- scale systems is measured in trillions per day. The fraction for which the receiving system can state, with any declared confidence, the accuracy of the timestamp, is effectively zero. This is not because the problem is unsolvable -- it is because no standard declaration vocabulary has existed. This document provides that standard. 2.2. The Temporal Fragmentation Problem Event-emitting systems operate under fundamentally different clock synchronization conditions: +=======+==========+===========+====================================+ | Tier | Accuracy | Protocol | Representative Systems | +=======+==========+===========+====================================+ | 1 | +/-10 ns | PTP IEEE | AI compute fabric, financial | | | | 1588 | trading systems, 5G base stations | +-------+----------+-----------+------------------------------------+ | 2 | +/-1-250 | NTP | Application servers, cloud VMs, | | | ms | [RFC5905] | PDU management cards, IoT | | | | | gateways | +-------+----------+-----------+------------------------------------+ | 3 | Relative | SNMP | Legacy network devices, embedded | | | only | sysUpTime | controllers | +-------+----------+-----------+------------------------------------+ | 4 | Unknown | Unsync'd | Offline devices, isolated OT | | | drift | RTC | networks | +-------+----------+-----------+------------------------------------+ | 5 | None | None | Air-gapped systems, constrained | | | | | embedded devices | +-------+----------+-----------+------------------------------------+ Table 2: Clock Synchronization Tiers in Distributed Systems All five tiers are present simultaneously in any large-scale deployment. No existing standard requires any device to declare which tier applies to its timestamps. 2.3. The Missing Declaration Standard [RFC3164] acknowledges that not all devices can timestamp their messages but offers no mechanism for a device to declare this condition. [RFC5424] adds structured timestamp formatting but provides no vocabulary for declaring uncertainty, sync state, or source. The consequence: a monitoring platform cannot distinguish, from message content alone, between a timestamp accurate to +/-10 nanoseconds and one accurate to +/-250 milliseconds. In the absence of declared temporal integrity, applications independently implement proprietary mechanisms for event ordering, correlation, and suppression. These mechanisms are not interoperable, cannot be validated against a published standard, and produce unreliable causal inference across system boundaries. Temporal integrity is a data-plane concern; causality is an application concern. SMPTE ST 12-1 established this boundary for broadcast infrastructure in 1969. TIM establishes it for networked computing. 2.4. Impact Across Application Contexts 2.4.1. Security Incident Timeline Reconstruction A SIEM investigating a data exfiltration incident correlates events from a firewall (NTP, +/-100ms), an authentication service (cloud- hosted, +/-50ms), an endpoint agent (Windows time service, +/-500ms), and a database audit log (GPS-disciplined NTP, +/-5ms). If the firewall alert and the authentication event are 200ms apart, the analyst cannot determine which came first -- the combined +/-600ms uncertainty makes the ordering ambiguous. With TIM: Each event carries a declared Temporal Confidence Class. The analyst knows which events can be trusted for millisecond-level ordering and which cannot. The SIEM presents the incident timeline with per-event confidence indicators rather than presenting all events as equally reliable. 2.4.2. Distributed Transaction Ordering A financial platform processes trades across distributed nodes. Node A (GPS-disciplined, +/-10ns) records a price update at T=14:23:45.100. Node B (NTP, +/-200ms) records a trade execution at T=14:23:45.050. The trade appears to precede the price update by 50ms -- possibly evidence of front-running. But the +/-200ms NTP uncertainty means the trade may actually have occurred as much as 200ms earlier or 200ms later than recorded; the true ordering is indeterminate within the interval. With TIM, the compliance system automatically flags that Node B is Class D and the 50ms lead is within the uncertainty window -- inconclusive rather than suspicious. 2.4.3. Telecom Call Trace Correlation A VoIP operator correlates events from a SIP proxy (PTP, +/-1us), a media transcoder (NTP, +/-50ms), a billing CDR system (NTP, +/-200ms), and a QoS monitor (SNMP sysUpTime, no wall-clock reference). Without declared uncertainty, the operator cannot determine whether a codec error caused packet loss or was caused by it. With TIM, the SIP proxy events anchor the timeline at Class A, the transcoder events declare Class C, and the QoS monitor declares Class F -- sequence ordering only. 2.4.4. Representative Emerging Efficiency Metric (AI Inference Tokens per Watt) A representative example of an emerging efficiency metric requiring cross-component temporal correlation is token throughput per watt for AI inference infrastructure. Computing this metric requires correlating primary compute throughput (PTP-synchronized, +/-10ns) with power consumption (NTP-synchronized, +/-250ms) and cooling load (Modbus, no time reference). TIM enables such metrics to be computed as bounded intervals derived from the declared uncertainty of constituent measurements, rather than as point values with false precision. This pattern generalizes to any multi-domain efficiency metric requiring temporal coherence across heterogeneous components. 2.5. The Precision Discard Problem A pervasive pattern: each layer of the software stack systematically discards precision that the hardware layer below it provides. A 5G base station synchronizes to GNSS to +/-1.5 microseconds. The mobile device connected to that base station uses NTP, achieving +/-100 milliseconds. TIM makes this gap visible, quantifiable, and actionable. 2.6. The Temporal Reference Domain Problem As computing extends to aeronautical, orbital, and cislunar environments, relativistic effects mean that clocks at different gravitational potentials do not tick at the same rate. For an observer on the lunar surface, an Earth-based clock loses approximately 56.7 microseconds per Earth day [OSTP-LTC]. No existing infrastructure logging RFC addresses this. TIM defines a Temporal Reference Domain field enabling any device to declare its relativistic and administrative time context. 3. Terminology The following terms are used throughout this document: Temporal Provenance The complete characterization of how a timestamp was generated, including its source, synchronization state, uncertainty bounds, and temporal reference domain. Temporal provenance is the concept; TIM is the standard for declaring it. Event Time (T_event) The time at which the condition being reported actually occurred at the source. This is the time of interest for event correlation. Emission Time (T_emit) The time at which the device generated and transmitted the message. MAY differ from Event Time if the device queues or batches events. Ingestion Time (T_ingest) The time at which the collecting platform received the message. Populated by the collector, not the originating device. Temporal Integrity Metadata (TIM) The structured metadata block defined in this document, attached to or associated with a telemetry emission to declare its temporal provenance. Sync State A declared operational state indicating the relationship between a device's clock and an external time reference at the moment of emission. See Section 6. Temporal Confidence Class A single-letter classification (A through F) summarizing overall timestamp quality implied by declared sync state and uncertainty bounds, scoped to a temporal reference domain. See Section 5. Uncertainty Interval A closed interval [earliest, latest] guaranteed to contain the absolute time of the event. Inspired by and modeled after Google TrueTime [SPANNER]. Sequence Epoch A device-scoped identifier (boot_id) delimiting a contiguous, monotonic run of sequence tokens. See Section 4.2. Temporal Reference Domain A declared context specifying the time scale and relativistic reference frame in which timestamps are expressed. See Section 7. Causal Anchor A high-confidence timestamp from a correlated event in a different domain, used to bound the uncertainty interval of a lower-confidence timestamp. A platform-level concept; not carried in TIM itself. 4. Temporal Integrity Metadata (TIM) Specification 4.1. Overview The TIM structure is a metadata block that SHOULD accompany every telemetry emission. It is transport-agnostic and may be carried as: * application/json -- in REST API responses and webhook payloads * Structured data in RFC 5424 syslog messages using a registered SD- ID * OID-value pairs in SNMP responses and notifications * A YANG data node in NETCONF notifications and RESTCONF responses * Any other structured representation appropriate to the transport TIM does not replace existing message formats. It augments them with temporal integrity metadata that existing formats cannot express. 4.1.1. Semantics of event_time and emission_time event_time: The time at which the reported condition occurred. This value MAY be directly observed or inferred. When inferred, the uncertainty_ns field MUST reflect the inference uncertainty in addition to clock quality uncertainty. Devices SHOULD declare event_time null rather than declare a value they cannot support with any uncertainty bound. emission_time: The time at which the device generated and transmitted this message. This value MAY be later than event_time due to queuing, batching, or scheduling latency. The gap between event_time and emission_time is observable evidence of reporting latency. ingestion_time: The time at which the collecting platform received the message. Populated by the collector, never by the originating device. Critical: None of these fields are guaranteed to represent objective ground truth. Each represents the best available estimate at the respective stage, qualified by the uncertainty declaration. Consuming systems MUST NOT treat any field as exact without verifying the confidence class. 4.1.2. Causality and TIM TIM does not guarantee causal correctness. It enables systems to reason about the bounds within which causal ordering can and cannot be established. Two events whose uncertainty intervals do not overlap can be confidently ordered. Two events whose uncertainty intervals overlap cannot be confidently ordered -- their causal relationship is ambiguous within the declared bounds. This is the same principle established by Google's TrueTime [SPANNER]: when uncertainty intervals overlap, ordering ambiguity must be resolved explicitly. TIM makes this uncertainty visible for any event type. 4.1.3. Symmetric and Asymmetric Uncertainty TIM supports two representations of the uncertainty interval: Symmetric (default): uncertainty_ns declares a half-width; the interval is [event_time - uncertainty_ns, event_time + uncertainty_ns]. Asymmetric (explicit interval): When a device can establish a tighter or directional bound -- for example, from NTP root dispersion combined with a measured offset direction, or during one-sided holdover drift -- it MAY declare uncertainty_earliest and uncertainty_latest directly. When BOTH interval fields are present AND the field uncertainty_asymmetric is true, the interval fields are authoritative and uncertainty_ns MUST equal max(event_time - uncertainty_earliest, uncertainty_latest - event_time), i.e., the conservative symmetric envelope, so that consumers ignoring the interval fields still receive a valid (if looser) bound. When uncertainty_asymmetric is absent or false, uncertainty_ns is normative and interval fields, if present, are derived representations; on inconsistency, uncertainty_ns governs. 4.1.4. Computing uncertainty_ns in Practice The uncertainty_ns field MUST represent a conservative upper bound on the absolute difference between event_time and the true occurrence time. Implementations SHOULD use the following reference models: +===================+===========================+===================+ |Sync Source |Recommended Computation |Notes | +===================+===========================+===================+ |PTP_IEEE1588 |grandmaster_clockAccuracy +|Use [IEEE1588] | | |path_delay_asymmetry |clockAccuracy | | | |field. Add 10% | | | |margin for | | | |uncompensated | | | |asymmetry. | +-------------------+---------------------------+-------------------+ |GPS_GNSS |gnss_receiver_accuracy_spec|Use manufacturer- | | | |specified accuracy.| | | |Typical: +/-10-30 | | | |ns. | +-------------------+---------------------------+-------------------+ |NTP_GPS_DISCIPLINED|2 x ntp_root_delay + |chrony and ntpd | | |ntp_root_dispersion |expose root_delay | | | |and | | | |root_dispersion. | | | |Conservative bound.| | | |Typical: +/-1-5 ms.| +-------------------+---------------------------+-------------------+ |NTP_INTERNET |2 x ntp_root_delay + |Same formula. If | | |ntp_root_dispersion |statistics | | | |unavailable, | | | |RECOMMENDED | | | |default: | | | |250,000,000 ns. | | | |During a declared | | | |leap smear window, | | | |add the maximum | | | |smear offset; see | | | |Section 8.2. | +-------------------+---------------------------+-------------------+ |IRIG_B |manufacturer_spec + |Typically +/-1 us. | | |cable_delay_estimate |Add approx 5 ns/m | | | |cable delay for | | | |runs over 100 m. | +-------------------+---------------------------+-------------------+ |Holdover (OCXO) |drift_rate_ppb x |Example: 50 ppb x | | |holdover_duration_s x 1e9 |3600 s = 180,000 | | | |ns. Update at | | | |60-second | | | |intervals. | +-------------------+---------------------------+-------------------+ |Holdover (Rubidium)|drift_rate_ppb x |Example: 0.1 ppb x | | |holdover_duration_s x 1e9 |86400 s = 8,640 ns | | | |per day. | +-------------------+---------------------------+-------------------+ |FREEWHEEL / UNKNOWN|null -- MUST NOT be |When no defensible | | |fabricated |bound exists, | | | |uncertainty_ns MUST| | | |be null. | | | |Implementations MAY| | | |provide an | | | |operator-defined | | | |fallback bound but | | | |MUST set | | | |uncertainty_source | | | |= OPERATOR_FALLBACK| | | |to distinguish it | | | |from measured | | | |uncertainty. | | | |Consuming platforms| | | |receiving this flag| | | |MUST NOT use it for| | | |Class promotion | | | |above F without | | | |explicit operator | | | |authorization or | | | |policy override. | +-------------------+---------------------------+-------------------+ Table 3: uncertainty_ns Computation Guide by Sync Source Inference uncertainty: When event_time is inferred from a polling interval, the inference uncertainty MUST be added to clock uncertainty. Example: 30-second polling + NTP +/-250 ms = total uncertainty_ns of approximately 30,250,000,000 ns. Bounds derived in this way SHOULD declare uncertainty_source: INFERRED (Section 4.4). 4.2. Required Fields The following fields are REQUIRED in every TIM emission: +================+========+======================================+ | Field | Type | Description | +================+========+======================================+ | tim_version | String | TIM version implemented. Current | | | | value: "1.2". MUST be present to | | | | identify the schema. | +----------------+--------+--------------------------------------+ | sync_state | Enum | Synchronization state at emission | | | | time. MUST be one of: LOCKED, | | | | HOLDOVER, RECOVERING, FREEWHEEL, | | | | AUTONOMOUS, UNKNOWN. See Section 6. | +----------------+--------+--------------------------------------+ | sequence_token | Uint64 | Counter scoped to this device and | | | | to the current boot_id (sequence | | | | epoch). MUST increment by exactly | | | | one for every emission within an | | | | epoch. Provides event ordering | | | | independent of wall-clock time. | +----------------+--------+--------------------------------------+ | boot_id | String | Opaque identifier for the current | | | | sequence epoch. MUST change | | | | whenever sequence_token continuity | | | | cannot be guaranteed (power cycle | | | | without non-volatile counter, | | | | factory reset, counter wraparound). | | | | RECOMMENDED: a 128-bit random value | | | | (e.g., UUIDv4) generated at each | | | | epoch start. | +----------------+--------+--------------------------------------+ Table 4: TIM Required Fields Sequence semantics: Monotonicity of sequence_token is guaranteed only within a single (device, boot_id) pair. Consumers MUST treat a change in boot_id as the start of a new ordering epoch: sequence tokens from different epochs of the same device MUST NOT be compared for ordering. Within an epoch: * A received token less than or equal to the previously received token indicates duplication, reordering in transit, or replay (see Section 13.3). * A gap greater than one indicates dropped events or tampering and SHOULD raise the SEQUENCE_VIOLATION anomaly flag (Section 4.5). * On reaching the maximum Uint64 value, the device MUST start a new epoch (new boot_id, sequence_token reset) rather than wrap silently. Devices with non-volatile counter storage SHOULD preserve both boot_id and sequence_token across power cycles so that a single epoch spans reboots. Constrained devices [RFC7228] without non- volatile storage MUST generate a new boot_id on every boot. 4.3. Conditionally Required Fields The following fields are REQUIRED under the stated conditions: +======================+===========+===============================+ | Field | Type | Description | +======================+===========+===============================+ | event_time | [RFC3339] | REQUIRED unless sync_state is | | | | UNKNOWN or FREEWHEEL with no | | | | wall-clock reference. MUST | | | | include timezone designator | | | | (Z for UTC). | +----------------------+-----------+-------------------------------+ | uncertainty_ns | Uint64 | REQUIRED when event_time is | | | | present. The conservative | | | | symmetric uncertainty half- | | | | width in nanoseconds. | | | | Normative unless | | | | uncertainty_asymmetric is | | | | true (Section 4.1.3). MUST | | | | be null when no defensible | | | | bound can be established. | +----------------------+-----------+-------------------------------+ | uncertainty_earliest | [RFC3339] | OPTIONAL (REQUIRED when | | | | uncertainty_asymmetric is | | | | true). Earliest bound of the | | | | uncertainty interval. When | | | | uncertainty_asymmetric is | | | | absent/false: derived, and | | | | uncertainty_ns governs on | | | | inconsistency. | +----------------------+-----------+-------------------------------+ | uncertainty_latest | [RFC3339] | OPTIONAL (REQUIRED when | | | | uncertainty_asymmetric is | | | | true). Latest bound of the | | | | uncertainty interval. Same | | | | precedence rules as above. | +----------------------+-----------+-------------------------------+ | uncertainty_asymmetric| Boolean | OPTIONAL. When true, the | | | | interval fields are | | | | authoritative per Section | | | | 4.1.3. Default: false. | +----------------------+-----------+-------------------------------+ Table 5: TIM Conditionally Required Fields 4.4. Optional Fields The following fields are OPTIONAL but RECOMMENDED where available: +==================================+=========+======================+ |Field |Type | Description | +==================================+=========+======================+ |emission_time |[RFC3339]| Time at which this | | | | message was | | | | generated and | | | | transmitted, if | | | | different from | | | | event_time. | +----------------------------------+---------+----------------------+ |sync_source |Enum | Type of | | | | synchronization | | | | source. Values: | | | | PTP_IEEE1588, | | | | CELLULAR_5G_PRTC, | | | | GPS_GNSS, | | | | NTP_GPS_DISCIPLINED, | | | | NTP_INTERNET, | | | | IRIG_B, HAVEQUICK, | | | | INS_HOLDOVER, | | | | WIFI_TSF, WIFI_FTM, | | | | MOBILE_5G, | | | | MOBILE_LTE, | | | | OSCILLATOR_OCXO, | | | | OSCILLATOR_RUBIDIUM, | | | | OSCILLATOR_CESIUM, | | | | LTC_LUNAR, | | | | SPACECRAFT_ATOMIC, | | | | NONE. | +----------------------------------+---------+----------------------+ |grandmaster_id |String | For PTP sources: | | | | IEEE EUI-64 identity | | | | of the PTP | | | | grandmaster clock. | +----------------------------------+---------+----------------------+ |holdover_duration_s |Uint32 | For HOLDOVER state: | | | | seconds since | | | | external reference | | | | was lost. | +----------------------------------+---------+----------------------+ |time_domain |Enum | Temporal reference | | | | domain. Default if | | | | absent: | | | | UTC_TERRESTRIAL. | | | | See Section 7. | +----------------------------------+---------+----------------------+ |leap_state |Enum | Leap second / | | | | smearing state. | | | | Values: NONE, | | | | LEAP_PENDING, | | | | LEAP_IN_PROGRESS, | | | | SMEARING. Default | | | | if absent: NONE. | | | | See Section 8. | +----------------------------------+---------+----------------------+ |smear_model |String | When leap_state is | | | | SMEARING: operator- | | | | or provider-defined | | | | identifier of the | | | | smear function in | | | | use (e.g., | | | | "linear-24h"). | +----------------------------------+---------+----------------------+ |tai_offset_s |Int32 | Current TAI-UTC | | | | offset in seconds as | | | | known to the device. | | | | Enables lossless | | | | UTC/TAI conversion. | | | | See Section 8.3. | +----------------------------------+---------+----------------------+ |relativistic_correction_applied |Boolean | Whether relativistic | | | | correction has been | | | | applied to | | | | event_time. | | | | Relevant for orbital | | | | and cislunar | | | | deployments. | +----------------------------------+---------+----------------------+ |relativistic_correction_ns_per_day|Int64 | Declared | | | | relativistic | | | | correction rate in | | | | nanoseconds per day, | | | | signed. Positive | | | | values indicate the | | | | local clock runs | | | | fast relative to the | | | | geoid. | +----------------------------------+---------+----------------------+ |uncertainty_source |Enum | Origin of the | | | | uncertainty | | | | declaration. | | | | Values: MEASURED | | | | (derived from live | | | | sync statistics per | | | | Table 3), SPECIFIED | | | | (manufacturer or | | | | standard | | | | specification), | | | | OPERATOR_FALLBACK | | | | (operator-configured | | | | default in the | | | | absence of a | | | | defensible measured | | | | bound), INFERRED | | | | (derived from | | | | polling interval or | | | | indirect evidence | | | | per Section 4.1.4). | | | | Default if absent: | | | | MEASURED. | +----------------------------------+---------+----------------------+ |domain_id |String | Operator-defined | | | | identifier for | | | | isolated | | | | classification | | | | domains (e.g., | | | | classification | | | | domains in DOD/DOE | | | | environments). | +----------------------------------+---------+----------------------+ |tim_signature |Object | COSE_Sign1 or JWS | | | | protection of the | | | | TIM block. See | | | | Section 13.2. | +----------------------------------+---------+----------------------+ Table 6: TIM Optional Fields 4.5. Collector-Populated Fields The following fields MUST NOT be populated by the originating device. They MUST be populated by the collecting platform upon receipt: +==============================+===========+======================+ | Field | Type | Description | +==============================+===========+======================+ | _collector.ingestion_time | [RFC3339] | Time the collecting | | | | platform received | | | | this message. | | | | Always from the | | | | collector's TRM. | +------------------------------+-----------+----------------------+ | _collector.confidence_class | String | Temporal Confidence | | | | Class (A-F) assigned | | | | by the collector | | | | based on sync_state, | | | | uncertainty | | | | declaration, and | | | | time_domain. | +------------------------------+-----------+----------------------+ | _collector.class_scope | String | "UTC" when the class | | | | applies to a UTC- | | | | traceable domain; | | | | otherwise the | | | | declared time_domain | | | | value. See Section | | | | 5.3. | +------------------------------+-----------+----------------------+ | _collector.device_tim_native | Boolean | True if the device | | | | emitted native TIM; | | | | false if TIM was | | | | inferred by the | | | | collector. | +------------------------------+-----------+----------------------+ | _collector.signature_valid | Boolean | Present when | | | | tim_signature was | | | | received; true only | | | | if verification | | | | succeeded. See | | | | Section 13.2. | +------------------------------+-----------+----------------------+ | _collector.anomaly_flags | Array | List of anomaly | | | | codes detected: | | | | SEQUENCE_VIOLATION, | | | | STALE_HOLDOVER, | | | | DOMAIN_MISMATCH, | | | | ANOMALOUS_LOCKED, | | | | SIGNATURE_INVALID, | | | | REPLAY_SUSPECTED. | | | | See Section 13.4 | | | | for definitions. | +------------------------------+-----------+----------------------+ Table 7: TIM Collector-Populated Fields 5. Temporal Confidence Classes 5.1. Class Definitions Temporal Confidence Classes are a standardized interpretation layer enabling consistent cross-platform reasoning about timestamp quality -- comparable to DSCP QoS classes in IP networking or severity levels in syslog. Collecting platforms MUST assign a Temporal Confidence Class to each received telemetry event based on the declared sync_state and uncertainty declaration, scoped as described in Section 5.3. +=======+==============+=============+==============================+ | Class | Typical Sync | Uncertainty | Typical Source | | | States | | | +=======+==============+=============+==============================+ | A | LOCKED / | < 1 us | PTP IEEE 1588 / GPS atomic / | | | AUTONOMOUS | | onboard atomic (within its | | | | | declared domain) | +-------+--------------+-------------+------------------------------+ | B | LOCKED / | 1 us - 100 | GPS-disciplined NTP / IRIG-B | | | HOLDOVER / | us | / rubidium holdover < 24h / | | | AUTONOMOUS | | drifting atomic reference | +-------+--------------+-------------+------------------------------+ | C | LOCKED | 100 us - 10 | GPS-disciplined NTP server | | | | ms | | +-------+--------------+-------------+------------------------------+ | D | LOCKED | 10 ms - 250 | Internet NTP | | | | ms | | +-------+--------------+-------------+------------------------------+ | E | HOLDOVER / | > 250 ms or | Oscillator holdover, re- | | | RECOVERING | growing | convergence | +-------+--------------+-------------+------------------------------+ | F | FREEWHEEL / | Null / | No reference / no defensible | | | UNKNOWN | undefined | bound / sequence only | +-------+--------------+-------------+------------------------------+ Table 8: Temporal Confidence Classes Classification key: Class assignment is determined primarily by the declared uncertainty bound, scoped per Section 5.3. The Typical Sync States column lists the states most often associated with each class; it is informative, not restrictive. Any sync state MAY appear at any class consistent with its declared uncertainty, with two normative exceptions: FREEWHEEL and UNKNOWN MUST be assigned Class F, since no defensible bound exists by definition (Table 3); and a LOCKED device whose declared uncertainty is implausible for its declared sync_source is an ANOMALOUS_LOCKED condition (Section 13.4), not a valid classification. In particular, a LOCKED device whose honest uncertainty is temporarily elevated -- for example, during a leap smear window (Section 8.2) -- classifies at the class its uncertainty indicates. FREEWHEEL and confidence: A device in FREEWHEEL state has, by definition, no defensible uncertainty bound (Table 3) and therefore MUST be assigned Class F. A device that has recently lost lock but can still bound its drift from a characterized oscillator is, by definition, in HOLDOVER, not FREEWHEEL, and is classified through the HOLDOVER rows above. (This resolves an inconsistency in the -00 revision, which permitted FREEWHEEL at Class D.) AUTONOMOUS and confidence: A device in AUTONOMOUS state (local atomic reference, no external synchronization path) is classified by its declared uncertainty within its declared time_domain: typically Class A while the ensemble is within specification and Class B as characterized drift accumulates. The class is domain- scoped per Section 5.3; the time_domain field MUST be populated. Class F constraint: Events with Confidence Class F MUST NOT be used for temporal ordering against events from other devices without explicit operator authorization or policy override. Such authorization SHOULD be recorded as an audit event. Sequence tokens remain valid for Class F events and SHOULD be used for relative ordering within a single device stream and sequence epoch. Holdover progression: A device entering HOLDOVER begins at the class appropriate to its last locked uncertainty. The class degrades as accumulated drift increases uncertainty_ns. Devices SHOULD update uncertainty_ns at regular intervals (RECOMMENDED: every 60 seconds) during holdover. 5.2. Class Boundary Rationale The class boundaries are anchored to the accuracy regimes of common synchronization technologies rather than arbitrary numeric divisions: Classes A and B correspond to PTP/GNSS-quality synchronization; Class C to GPS-disciplined NTP; Class D to internet NTP; Class E to oscillator holdover with growing drift; and Class F to devices with no usable time reference. The 10 ms boundary between Classes C and D is chosen because it separates the achievable accuracy of a well-provisioned, locally disciplined NTP service (single-digit milliseconds, dominated by LAN path delay) from the accuracy regime of internet-path NTP (tens to hundreds of milliseconds, dominated by asymmetric WAN delay). A device reporting internet NTP with unusually low root delay MAY legitimately classify as C; the boundary describes uncertainty, not topology. 5.3. Domain Scoping of Confidence Classes A confidence class expresses timestamp quality WITHIN the event's declared temporal reference domain. It does not, by itself, assert comparability across domains. * For events in UTC-traceable domains (UTC_TERRESTRIAL, UTC_LEO_CORRECTED with correction applied), the class scope is "UTC" and events MAY be directly compared subject to their combined uncertainty. * For events in relative or autonomous domains (WIFI_FTM_RELATIVE, FACILITY_AUTONOMOUS, SPACECRAFT_TAI without a declared tai_offset_s, LTC domains prior to conversion), the collector MUST set _collector.class_scope to the declared time_domain value. A Class A event in a relative domain declares nanosecond-quality ordering WITHIN that domain only. Consuming platforms MUST NOT correlate events across different class_scope values without applying the conversion requirements of Section 7.3. This scoping rule replaces the -00 behavior in which a relative- domain event could carry an unqualified Class A indistinguishable from a UTC-traceable Class A. 6. Sync State Definitions and Transitions Six sync states are defined. Devices MUST declare exactly one sync state in every TIM emission. +============+====================================================+ | State | Description | +============+====================================================+ | LOCKED | Device clock is actively synchronized to an | | | external reference within declared uncertainty | | | bounds. | +------------+----------------------------------------------------+ | HOLDOVER | External reference was lost. Device is | | | maintaining time using an internal oscillator | | | with characterized drift. holdover_duration_s | | | SHOULD be populated and uncertainty_ns MUST | | | reflect accumulated drift. | +------------+----------------------------------------------------+ | RECOVERING | External reference has been restored after | | | HOLDOVER or FREEWHEEL. Clock is converging. | | | uncertainty_ns remains elevated until convergence | | | completes. | +------------+----------------------------------------------------+ | FREEWHEEL | Device is operating on its internal clock with no | | | recent synchronization and no characterized drift | | | bound. No external reference is available. | +------------+----------------------------------------------------+ | AUTONOMOUS | Device is operating on a local atomic reference | | | with no external synchronization path. Applicable | | | to orbital, cislunar, and deep space deployments. | | | The time_domain field MUST be populated. | +------------+----------------------------------------------------+ | UNKNOWN | Device cannot determine its synchronization state. | | | Implies sequence-only ordering. | +------------+----------------------------------------------------+ Table 9: Sync State Definitions Devices SHOULD emit a TIM with the updated sync_state whenever a state transition occurs. Devices that cannot emit unsolicited transition events MUST reflect the current sync_state in the next scheduled emission. 7. Temporal Reference Domains 7.1. Motivation All existing infrastructure logging RFCs implicitly assume UTC on Earth's geoid. This assumption fails for infrastructure operating at significantly different gravitational potential or velocity. The direction and magnitude of the net correction depend on altitude. At ISS altitude (~400 km), velocity time dilation dominates gravitational blueshift and the net correction is approximately -25 microseconds per Earth day (the orbiting clock runs slow relative to the geoid). At GPS constellation altitude (~20,200 km) the balance inverts and the net correction is approximately +38 microseconds per Earth day. On the lunar surface, the net correction is approximately +56.7 microseconds per Earth day [OSTP-LTC]. Implementation note -- optionality: The time_domain field is OPTIONAL. Terrestrial deployments NEED NOT populate it; UTC_TERRESTRIAL applies implicitly. Implementations MAY ignore non- terrestrial domain values without loss of interoperability with other terrestrial TIM implementations. These domains are defined for future-proofing: (1) the field is optional and adds zero overhead to terrestrial deployments; (2) the White House OSTP issued a directive in April 2024 establishing Coordinated Lunar Time [OSTP-LTC], providing direct policy backing; (3) commercial orbital computing is actively being developed. 7.2. Defined Domains +=====================+==========================================+ | Domain Value | Description | +=====================+==========================================+ | UTC_TERRESTRIAL | Standard UTC on Earth's surface. | | | Default when time_domain is absent. | +---------------------+------------------------------------------+ | UTC_LEO_CORRECTED | UTC with applied relativistic correction | | | for low Earth orbit (approx -25 us/day | | | at ISS altitude; sign and magnitude vary | | | with orbital altitude). | | | relativistic_correction_ns_per_day MUST | | | be populated with the signed value. | +---------------------+------------------------------------------+ | LTC_LUNAR | Coordinated Lunar Time as defined by | | | NASA/OSTP. Approx +56.7 us/day vs | | | UTC_TERRESTRIAL. | +---------------------+------------------------------------------+ | LTC_CISLUNAR | Time standard for cislunar orbital | | | operations. Correction varies with | | | orbital parameters. | +---------------------+------------------------------------------+ | SPACECRAFT_TAI | International Atomic Time maintained by | | | onboard atomic clock, without leap | | | second corrections. See Section 8.3. | +---------------------+------------------------------------------+ | FACILITY_AUTONOMOUS | Facility-local time with no declared | | | relationship to any international time | | | scale. Events MUST NOT be cross- | | | correlated with other domains without | | | operator-defined conversion parameters. | +---------------------+------------------------------------------+ | WIFI_FTM_RELATIVE | Local relative time domain based on Wi- | | | Fi FTM ranging. Timestamps represent | | | elapsed nanoseconds from an anchor point | | | and are NOT directly comparable to UTC- | | | domain timestamps without calibration. | +---------------------+------------------------------------------+ Table 10: Temporal Reference Domain Values 7.3. Cross-Domain Correlation Requirements When correlating events from different Temporal Reference Domains, a consuming platform MUST: 1. Identify the declared domain of each event stream 2. Apply the appropriate conversion function and propagation delay correction 3. Compute resulting uncertainty as the sum of individual bounds plus conversion uncertainty 4. NEVER silently treat timestamps from different domains as directly comparable without conversion 8. Leap Seconds, Smearing, and Time Scale Conversion UTC is a discontinuous time scale: leap seconds inserted (or potentially removed) by IERS create instants at which naive timestamp arithmetic across the discontinuity is wrong by one second -- an error three orders of magnitude larger than the entire Class A-C uncertainty range. A timestamp quality standard cannot be silent on this. Note that the 2022 CGPM resolution to discontinue leap seconds by or before 2035 does not remove the requirement: historical data spanning past leap events, and any leap events occurring before discontinuation, must still be handled. 8.1. Leap Second Events Devices that receive leap second announcements from their sync source (NTP leap indicator bits, PTP announce messages, GNSS almanac) SHOULD declare: * leap_state: LEAP_PENDING from the time the announcement is known until the start of the leap event window * leap_state: LEAP_IN_PROGRESS during the leap event itself and for any implementation-defined settling period afterward During LEAP_IN_PROGRESS, devices whose clock implementation handles the leap by stepping, freezing, or repeating a second (rather than representing 23:59:60 natively per [RFC3339]) MUST increase uncertainty_ns by at least 1,000,000,000 ns (one second) for emissions within the affected window, since the relationship between the local representation and true UTC is ambiguous within that window. Consuming platforms correlating events across a leap boundary MUST account for the discontinuity when computing intervals that span it, and SHOULD surface leap_state in incident timelines. 8.2. Leap Smearing Several large NTP providers implement leap smearing: the served time is deliberately slewed (typically linearly over 24 hours) so that no discontinuity occurs, at the cost of being offset from true UTC by up to 500 ms during the smear window. A smeared clock is intentionally inaccurate. TIM requires this to be declared honestly: * Devices synchronized to a smearing source MUST, during the smear window, either (a) set leap_state: SMEARING and add the maximum smear offset of the declared smear_model to uncertainty_ns, or (b) if the smear function is precisely known and compensated, declare corrected time with normal uncertainty. * A device that cannot determine whether its upstream NTP source smears SHOULD apply option (a) conservatively around known leap events. * Consuming platforms MUST NOT correlate a SMEARING event stream against a non-smearing (stepped) stream at sub-second precision within the smear window without compensating for the declared smear_model. The practical effect: internet NTP devices in a smear window temporarily degrade from Class D to Class E. This is correct behavior -- the uncertainty is real. 8.3. UTC / TAI Conversion Domains based on atomic time without leap corrections (SPACECRAFT_TAI; some facility ensembles) differ from UTC by the accumulated leap second offset (TAI - UTC = 37 s as of the date of this document). Conversion between such domains and UTC-traceable domains requires knowledge of the offset in effect at the event time, including its full history for archival data. * Devices emitting in a TAI-based domain SHOULD populate tai_offset_s with the TAI-UTC offset they believe current. * Consuming platforms converting TAI-domain events to UTC MUST use the offset in effect at the event time (not at conversion time) and MUST add conversion uncertainty when the applicable offset for a historical event cannot be established. * When tai_offset_s is absent from a TAI-domain stream, the collector MUST treat the stream as a distinct class_scope per Section 5.3 rather than assuming an offset. 9. TIM Schema and Examples 9.1. Class A Example -- PTP-Synchronized Device { "tim_version": "1.2", "event_time": "2026-06-30T14:23:45.123456789Z", "uncertainty_ns": 10, "sync_state": "LOCKED", "sync_source": "PTP_IEEE1588", "grandmaster_id":"00:1a:2b:3c:4d:5e:6f:70", "sequence_token": 8472910, "boot_id": "5f3d9a2e-4c1b-4f0a-9d7e-2b8c6a1e0f44", "time_domain": "UTC_TERRESTRIAL", "_collector": { "ingestion_time": "2026-06-30T14:23:45.610Z", "confidence_class": "A", "class_scope": "UTC", "device_tim_native": true } } 9.2. Class D Example -- Internet NTP Device { "tim_version": "1.2", "event_time": "2026-06-30T14:23:45.123Z", "uncertainty_ns": 250000000, "sync_state": "LOCKED", "sync_source": "NTP_INTERNET", "sequence_token": 33201, "boot_id": "c81e1c52-70b5-4bb1-8a55-3f6b8f0f21aa", "time_domain": "UTC_TERRESTRIAL", "_collector": { "ingestion_time": "2026-06-30T14:23:45.890Z", "confidence_class": "D", "class_scope": "UTC" } } 9.3. Class F Example -- Minimal TIM (No Clock, Sequence Only) The absolute minimum valid TIM. No time reference. Only the sequence_token and boot_id are populated, enabling event ordering within this device stream and epoch. Conformant baseline for the most constrained embedded devices. { "tim_version": "1.2", "event_time": null, "uncertainty_ns": null, "sync_state": "FREEWHEEL", "sync_source": "NONE", "sequence_token": 12847, "boot_id": "e0a1b2c3-d4e5-4f60-8172-93a4b5c6d7e8", "_collector": { "ingestion_time": "2026-06-30T14:23:45.610Z", "confidence_class": "F", "class_scope": "UTC" } } 9.4. Class E Example -- Holdover in Progress uncertainty_ns is 400,200,000 ns (~0.4002 s); the derived interval bounds are exact to the declared precision. { "tim_version": "1.2", "event_time": "2026-06-30T14:23:45.123456Z", "uncertainty_earliest": "2026-06-30T14:23:44.723256Z", "uncertainty_latest": "2026-06-30T14:23:45.523656Z", "uncertainty_ns": 400200000, "sync_state": "HOLDOVER", "sync_source": "OSCILLATOR_OCXO", "holdover_duration_s": 3612, "sequence_token": 98341, "boot_id": "9b2f4d6e-8a0c-4e1f-b3d5-7c9e1a3f5b7d", "time_domain": "UTC_TERRESTRIAL", "_collector": { "ingestion_time": "2026-06-30T14:23:45.890Z", "confidence_class": "E", "class_scope": "UTC" } } 9.5. Class F Extended -- Unsynchronized RTC Device has a battery-backed RTC but it has never been synchronized. event_time is present and useful for human inspection but MUST NOT be used for temporal ordering against events from other devices. { "tim_version": "1.2", "event_time": "2026-06-30T14:23:45.000Z", "uncertainty_ns": null, "sync_state": "FREEWHEEL", "sync_source": "NONE", "sequence_token": 5501, "boot_id": "1f2e3d4c-5b6a-4798-8091-a2b3c4d5e6f7", "_advisory": { "note": "RTC present; last sync unknown. No bound established." }, "_collector": { "ingestion_time": "2026-06-30T14:23:46.001Z", "confidence_class": "F", "class_scope": "UTC" } } 9.6. Mobile / IoT Example -- 5G-Connected Device (OS NTP vs. Network Precision) Illustrates the precision discard problem. Device is connected to a 5G network (GNSS-disciplined to +/-1.5 us) but the OS uses NTP. The _advisory block flags that better precision is available but not exposed. { "tim_version": "1.2", "event_time": "2026-06-30T14:23:45.123Z", "uncertainty_ns": 250000000, "sync_state": "LOCKED", "sync_source": "NTP_INTERNET", "sequence_token": 884721, "boot_id": "7a8b9c0d-1e2f-4a3b-8c4d-5e6f7a8b9c0d", "_advisory": { "cellular_network_timing_available": true, "cellular_achievable_uncertainty_ns": 1500, "note": "OS does not expose cellular timing; NTP used instead" }, "_collector": { "ingestion_time": "2026-06-30T14:23:45.890Z", "confidence_class": "D", "class_scope": "UTC" } } 9.7. Wi-Fi FTM Example -- Relative Time Domain Device using Wi-Fi FTM ranging. event_time is null because this is a relative domain. The confidence class is A, but class_scope is the relative domain: nanosecond-quality ordering applies WITHIN WIFI_FTM_RELATIVE only (Section 5.3). UTC correlation requires a separate calibration record. { "tim_version": "1.2", "event_time": null, "uncertainty_ns": 2, "sync_state": "LOCKED", "sync_source": "WIFI_FTM", "sequence_token": 44102, "boot_id": "3c4d5e6f-7a8b-4c9d-8e0f-1a2b3c4d5e6f", "time_domain": "WIFI_FTM_RELATIVE", "_ftm": { "anchor_bssid": "aa:bb:cc:dd:ee:ff", "anchor_calibration_id": "cal-2026-06-30T00:00:00Z", "rtts_ns": 142847193 }, "_collector": { "ingestion_time": "2026-06-30T14:23:45.890Z", "confidence_class": "A", "class_scope": "WIFI_FTM_RELATIVE" } } 9.8. Orbital Example -- LEO with Relativistic Correction Compute node in low Earth orbit. GPS receiver provides Class A timestamps. The relativistic correction (-25 us/day at ISS altitude) has been applied to event_time before emission. { "tim_version": "1.2", "event_time": "2026-06-30T14:23:45.000010Z", "uncertainty_ns": 10, "sync_state": "LOCKED", "sync_source": "GPS_GNSS", "sequence_token": 220194, "boot_id": "6e7f8a9b-0c1d-4e2f-8a3b-4c5d6e7f8a9b", "time_domain": "UTC_LEO_CORRECTED", "relativistic_correction_applied": true, "relativistic_correction_ns_per_day": -25000, "_collector": { "ingestion_time": "2026-06-30T14:23:45.900Z", "confidence_class": "A", "class_scope": "UTC" } } 9.9. Leap Smear Example -- NTP Device During Smear Window Internet NTP device whose upstream provider is linearly smearing a leap second over 24 hours. The maximum smear offset (500 ms) is added to the base NTP uncertainty; the device temporarily degrades to Class E. { "tim_version": "1.2", "event_time": "2026-06-30T23:12:07.443Z", "uncertainty_ns": 750000000, "sync_state": "LOCKED", "sync_source": "NTP_INTERNET", "leap_state": "SMEARING", "smear_model": "linear-24h", "sequence_token": 991204, "boot_id": "b1c2d3e4-f5a6-4b7c-8d9e-0f1a2b3c4d5e", "time_domain": "UTC_TERRESTRIAL", "_collector": { "ingestion_time": "2026-06-30T23:12:07.912Z", "confidence_class": "E", "class_scope": "UTC" } } 9.10. Signed TIM Example -- COSE-Protected Emission TIM block protected by a COSE_Sign1 structure [RFC9052] over the deterministically encoded TIM fields, using a device-resident key. The signature value is abbreviated for readability. { "tim_version": "1.2", "event_time": "2026-06-30T14:23:45.123456789Z", "uncertainty_ns": 10, "sync_state": "LOCKED", "sync_source": "PTP_IEEE1588", "grandmaster_id":"00:1a:2b:3c:4d:5e:6f:70", "sequence_token": 8472911, "boot_id": "5f3d9a2e-4c1b-4f0a-9d7e-2b8c6a1e0f44", "time_domain": "UTC_TERRESTRIAL", "tim_signature": { "format": "COSE_Sign1", "alg": "ES256", "kid": "device-7f21:slot0", "payload": "detached", "value": "hDhCoSABoQRQ...base64url...9pXw" }, "_collector": { "ingestion_time": "2026-06-30T14:23:45.610Z", "confidence_class": "A", "class_scope": "UTC", "device_tim_native": true, "signature_valid": true } } 10. Implementation Guidance -- Event Sources 10.1. Minimum Viable Implementation A device with no time reference can still implement a conformant minimal TIM with four fields: tim_version, sync_state: "FREEWHEEL", sequence_token, and boot_id. This provides sequence ordering and ensures consuming platforms do not silently treat absent timestamps as reliable. 10.2. Sync Source Hierarchy for New Designs Device designers implementing TIM SHOULD implement sync source support in the following priority order, selecting the highest available tier: +======+==================+============+=======================+ | Tier | Source | Accuracy | Context | +======+==================+============+=======================+ | 1A | PTP IEEE 1588 | +/-10 ns | High-performance data | | | | | centers and compute | | | | | environments with | | | | | PTP-capable fabric | +------+------------------+------------+-----------------------+ | 1B | IRIG-B | +/-1 us | Air-gapped military, | | | | | DOE, industrial | | | | | environments | +------+------------------+------------+-----------------------+ | 1C | GPS/GNSS direct | +/-10 ns | Installations with | | | | | GPS antenna access | +------+------------------+------------+-----------------------+ | 1D | CELLULAR_5G_PRTC | +/-100 ns | 5G edge sites using | | | | - 1.5 us | base station T-GM | +------+------------------+------------+-----------------------+ | 2 | GPS-disciplined | +/-1-5 ms | Facilities with OCP- | | | NTP | | TAP or equivalent | +------+------------------+------------+-----------------------+ | 3 | Internet NTP | +/-100-250 | Commercial | | | | ms | deployments without | | | | | local time | | | | | infrastructure | +------+------------------+------------+-----------------------+ | 4A | MOBILE_5G / | +/-1.5-10 | When OS or app layer | | | MOBILE_LTE | us | explicitly exposes | | | | | cellular timing | +------+------------------+------------+-----------------------+ | 4B | WIFI_FTM | +/-1 ns | Wi-Fi FTM ranging; | | | | relative | relative domain | +------+------------------+------------+-----------------------+ | 5 | Sequence only | N/A | Constrained devices | | | | | with no time | | | | | reference | +------+------------------+------------+-----------------------+ Table 11: Sync Source Priority Tiers 10.3. Sequence Token and Epoch Requirements The sequence_token / boot_id pair is the most important mechanism for devices without reliable wall-clock time: * MUST: Increment sequence_token by exactly one for every emission within an epoch, without exception. * MUST: Start a new epoch (new boot_id, sequence_token reset to an implementation-chosen initial value) whenever counter continuity cannot be guaranteed: on boot without non-volatile counter storage, after factory reset, or at Uint64 wraparound. * SHOULD: Store boot_id and sequence_token in non-volatile memory so a single epoch survives power cycles. Constrained devices [RFC7228] that cannot provide non-volatile storage MUST generate a new boot_id on each boot and SHOULD document this limitation. * MUST: Generate boot_id values with at least 122 bits of randomness (e.g., UUIDv4) so that epochs are unique with overwhelming probability across the device's lifetime and across factory resets. 10.4. Holdover Uncertainty Reporting Devices entering HOLDOVER state SHOULD update uncertainty_ns at regular intervals (RECOMMENDED: every 60 seconds) to reflect accumulated drift. Constrained devices that cannot update on schedule MUST update uncertainty_ns on every emission during holdover. 11. Implementation Guidance -- Consuming Platforms 11.1. Temporal Reference Manager (TRM) Consuming platforms that ingest TIM-annotated telemetry SHOULD implement a Temporal Reference Manager -- a component responsible for maintaining the best available time reference for ingestion_time stamping, managing failover between sources, and assigning confidence classes and class scopes to incoming events. 11.2. Backward Compatibility -- Devices Without TIM Consuming platforms MUST operate correctly when receiving telemetry from devices that do not implement TIM. For such events, the platform MUST: * Assign Confidence Class F * Use collector ingestion_time as the best available timestamp * Declare the event as having no declared temporal integrity metadata * NEVER treat the absence of TIM as equivalent to a Class A timestamp 11.3. Cross-Class Efficiency Metric Computation When computing efficiency metrics from constituent measurements with different Temporal Confidence Classes, consuming platforms SHOULD compute the metric as a bounded interval rather than a point value. The interval width is determined by the least-confident constituent measurement, and the overall confidence class equals the minimum class across all inputs. All constituents MUST share a class_scope or be converted per Section 7.3 before the metric is computed. 11.4. Shared-Reference Comparison A consuming platform MAY deliberately discipline its Temporal Reference Manager to the same external time reference used by a monitored device population (for example, the same GNSS constellation or the same PTP grandmaster domain). When the reference is shared, the relative offset between the collector's clock and a correctly functioning device's clock is bounded by the sum of their disciplining errors, and the comparison of a declared event_time against ingestion_time isolates path delay plus device- side error. Under a shared reference: * The plausibility checks of Section 13.4 (ANOMALOUS_LOCKED) MAY be applied with tightened thresholds, since the shared reference removes reference divergence as an innocent explanation for observed offset. * A device whose observed offset from the collector exceeds its declared uncertainty plus the maximum plausible transport delay SHOULD be flagged ANOMALOUS_LOCKED even where the same offset would be plausible under independent references. Shared-reference comparison is a consistency instrument, not an accuracy instrument. Agreement between collector and device under a shared reference demonstrates mutual consistency with that reference; it provides no evidence about the accuracy of the reference itself, and a compromised or spoofed shared reference produces agreement between collector and devices while both are wrong (Section 13.1, upstream time attack). Consuming platforms implementing shared-reference comparison MUST NOT represent its results as certification of timestamp accuracy, and SHOULD implement the reference diversity recommendation of Section 11.5. 11.5. Collector Reference Diversity A consuming platform whose time reference shares a single failure or attack surface with the references of its monitored population cannot distinguish fleet-wide agreement from fleet-wide common-mode error. Consuming platforms SHOULD maintain at least one time reference that is independent of the synchronization sources of the monitored device population -- for example, a second GNSS constellation, a terrestrial PTP or IRIG-B distribution not derived from the population's source, or a characterized holdover-grade local oscillator (rubidium or better). Divergence between the collector's independent reference and its population-shared reference that exceeds the combined declared uncertainties is a signature of an upstream time attack or reference failure (Section 13.1) and SHOULD be surfaced as a platform-level security event. During such divergence, the platform SHOULD suspend confidence-class assignments that depend on the shared reference and SHOULD annotate affected events for later re-evaluation. Where independent attestation of computation on third-party infrastructure is the objective (as opposed to operational consistency checking), the verifying platform's temporal reference MUST be traceable through a chain outside the attested host's trust domain. A verifier whose clock is disciplined by the infrastructure it verifies has ceded the temporal dimension of the verification to the party being verified. 12. Relationship to Existing Standards 12.1. Legacy BSD Syslog and RFC 5424 Syslog TIM is additive to [RFC5424]. It MAY be carried as structured data using a registered SD-ID. The TIMESTAMP field carries event_time; the TIM structured data block carries provenance metadata. This document does not modify [RFC3164] (the informational description of legacy BSD syslog, obsoleted by RFC 5424) or [RFC5424]. 12.2. SNMP SNMP notifications carry sysUpTime as the event time reference. TIM MAY be carried as additional variable bindings in SNMP traps and informs, using an OID allocated under a registered enterprise MIB. The sysUpTime value remains present for backward compatibility. 12.3. NETCONF/YANG TIM MAY be represented as a YANG data node and included in NETCONF event notifications alongside the eventTime element. A YANG module definition for TIM is left for a companion document. 12.4. IEEE 1588 (PTP) When a device's sync_source is PTP_IEEE1588, the TIM grandmaster_id field SHOULD contain the IEEE EUI-64 grandmaster identity from the PTP domain [IEEE1588]. TIM does not replace or modify PTP; it declares the provenance of timestamps derived from PTP synchronization. 12.5. SMPTE ST 12-1 SMPTE ST 12-1 [SMPTE-ST12] established two principles that directly inform TIM: (1) a timecode label is distinct from actual time; (2) synchronization state should be explicitly declared. TIM formalizes both principles for infrastructure telemetry. 12.6. Google TrueTime The uncertainty interval model in TIM is directly inspired by Google's TrueTime API [SPANNER], which represents timestamps as TTinterval{earliest, latest} guaranteed to contain the absolute event time. TrueTime's central insight -- that acknowledging and bounding uncertainty is superior to asserting false precision -- is the conceptual foundation of the TIM confidence class system. 12.7. OpenTelemetry Anticipated reviewer question: "Why isn't this just part of OpenTelemetry?" OpenTelemetry [OTEL] defines what telemetry data looks like. TIM defines how trustworthy the time dimension of that data is. These are distinct concerns. TIM operates orthogonally to observability schemas: it annotates time, not telemetry semantics. A TIM implementation requires no knowledge of whether the event is a log record, a span, a metric, or a physical sensor reading. OTel defines timestamp fields but provides no mechanism for declaring their quality. TIM is the missing provenance layer for OTel timestamps. TIM fields SHOULD be expressed as OTel resource attributes and log record attributes, extending OTel rather than replacing it. OTel resource attribute names for TIM fields are left to a companion specification. 12.8. W3C Trace Context W3C Trace Context [W3C-TC] propagates trace and span identifiers but carries no timestamp information. Timestamps in distributed traces are assigned by each service independently. TIM provides what distributed tracing assumes but never defines: a standard for declaring the reliability of those timestamps. TIM SHOULD be propagated alongside Trace Context headers. 12.9. IEEE 802.11 -- Wi-Fi Timing Mechanisms 802.11 TSF: The 64-bit microsecond counter synchronized across a BSS via beacon frames. TIM implementations using TSF SHOULD declare sync_source: "WIFI_TSF". TSF resets MUST cause a transition to FREEWHEEL until a new anchor is established. 802.11 FTM: Enables nanosecond round-trip time measurement without clock synchronization. Devices declaring sync_source: "WIFI_FTM" MUST populate time_domain: "WIFI_FTM_RELATIVE". FTM is subject to spoofing attacks [IEEE80211AZ] and TIM security considerations apply with heightened weight. 12.10. 3GPP -- LTE/5G Cellular Timing CELLULAR_5G_PRTC: When a consuming platform directly subscribes to the timing output of a 5G base station's Telecom Grandmaster (T-GM) as a PTP source, sync_source SHOULD be declared as CELLULAR_5G_PRTC. The T-GM typically achieves +/-100 ns to +/-1.5 us accuracy per [ITU-G8275]. MOBILE_5G / MOBILE_LTE: These values apply when a device or OS layer explicitly synchronizes to cellular network timing. Devices that do not expose cellular timing SHOULD declare NTP_INTERNET and SHOULD populate the _advisory block to indicate that better timing is available but not exposed. 13. Security Considerations 13.1. Threat Model TIM carries metadata about a device's clock synchronization state. The metadata itself becomes an attack surface: an adversary who can influence TIM fields can influence how a consuming platform weights, orders, and correlates events. Relevant adversary capabilities and objectives include: * Confidence inflation: An adversary with write access to a device or its telemetry stream elevates declared confidence (fabricating sync_state: LOCKED, shrinking uncertainty_ns, or forging class-relevant fields) so that manipulated timestamps are trusted for ordering. Incorrectly elevated confidence is a high-impact integrity violation and MUST be treated as a security event by collecting platforms when detected. * Confidence deflation: An adversary degrades declared confidence of honest events (e.g., forcing apparent FREEWHEEL) so that genuine evidence is excluded from a forensic timeline. Consuming platforms SHOULD treat unexplained confidence collapses from previously stable devices as anomalies, not merely as degraded data. * Replay: An adversary re-injects previously captured, validly signed emissions to pollute a timeline with stale events. See Section 13.3. * Upstream time attack: An adversary manipulates the time source itself (NTP spoofing, GNSS spoofing/jamming, rogue PTP grandmaster). TIM cannot detect a perfectly executed upstream attack -- a device honestly declaring LOCKED to a spoofed reference is honestly wrong. TIM does, however, make the blast radius visible: grandmaster_id enables detection of rogue grandmasters against known topology, and sudden fleet-wide sync_state transitions are a detectable signature of GNSS denial. 13.2. Cryptographic Protection of TIM Fields Where device hardware security capabilities permit, implementations SHOULD sign TIM emissions. This document specifies two interoperable envelope formats; implementations claiming signed-TIM support MUST implement at least one: * COSE_Sign1 [RFC9052] -- RECOMMENDED for constrained and embedded devices. The signature is computed over the deterministically encoded (CBOR [RFC8949] canonical form) TIM block, carried in the tim_signature field with payload: "detached". The RECOMMENDED algorithm is ES256; devices with hardware-backed Ed25519 MAY use EdDSA. * JSON Web Signature (JWS) [RFC7515] -- suitable for platforms already using JOSE tooling. The detached-payload form [RFC7797] SHOULD be used so the TIM block remains readable in transit. Signing requirements: * The signed content MUST include, at minimum: tim_version, event_time, uncertainty declaration, sync_state, sync_source, sequence_token, boot_id, and time_domain. Collector-populated fields (Section 4.5) MUST NOT be included in the device signature. * Keys SHOULD be device-resident and hardware-protected (TPM, secure element, or equivalent) where available. The kid field MUST identify the signing key unambiguously within the operator's key management domain. * Consuming platforms MUST verify signatures when present and MUST populate _collector.signature_valid with the result. Events whose signature fails verification MUST be assigned Class F, MUST raise the SIGNATURE_INVALID anomaly flag, and MUST NOT be used for temporal ordering against events from other devices pending operator review. A failed verification is affirmative evidence of tampering, corruption, or key mismanagement and MUST be treated as a security event; it is not equivalent to the benign absence of a signature. * Absence of a signature is not an error: unsigned TIM remains valid and useful. Operators MAY configure an unsigned-TIM ceiling -- the maximum confidence class assignable to events that carry no signature -- and MAY set policy requiring signatures for specific device populations or confidence classes. The ceiling applies to unsigned events only; failed verification is governed by the preceding paragraph. Consuming platforms SHOULD treat all TIM metadata from unverified devices as untrusted input and apply independent validation where possible (e.g., comparing declared grandmaster_id against the known PTP domain topology, and checking declared uncertainty against the physically achievable range for the declared sync_source). 13.3. Replay Protection A signature proves origin and integrity; it does not prove freshness. A captured, validly signed TIM emission can be replayed later. TIM's ordering fields provide the replay defense: * Within a sequence epoch, a consuming platform MUST track the highest sequence_token received per (device, boot_id) pair. A signed emission arriving with a token at or below the tracked high-water mark, and not attributable to legitimate transport reordering within the platform's configured reordering window, MUST raise the REPLAY_SUSPECTED anomaly flag. * An emission arriving under a previously retired boot_id (an epoch the device has been observed to have exited) MUST raise REPLAY_SUSPECTED. * Because boot_id values are required to be generated with at least 122 bits of randomness (Section 10.3), an adversary cannot force a device back into a prior epoch by predicting its identifier. * Platforms MAY additionally bound freshness by comparing signed emission_time against ingestion_time, subject to the declared uncertainty; a signed emission whose emission_time precedes ingestion_time by more than the platform's configured staleness bound SHOULD be flagged for review rather than silently accepted into ordering decisions. 13.4. Anomaly Detection The following anomaly flags (Table 7) are defined normatively: SEQUENCE_VIOLATION Within a single (device, boot_id) epoch, a received sequence_token that is not exactly one greater than the previous token and is not explained by the platform's configured transport-reordering window. Indicates dropped events, duplication, or tampering. STALE_HOLDOVER A device declaring HOLDOVER whose uncertainty_ns has not been updated within the interval required by Section 10.4, or whose holdover_duration_s implies drift inconsistent with the declared uncertainty. DOMAIN_MISMATCH An event whose declared time_domain or domain_id is inconsistent with the stream's provisioned domain, or an attempted correlation across class_scope boundaries without conversion (Section 7.3). ANOMALOUS_LOCKED A device declaring sync_state: LOCKED whose declared values are physically or contextually implausible: uncertainty_ns below the achievable floor of the declared sync_source (e.g., LOCKED NTP_INTERNET declaring 10 ns); a grandmaster_id absent from the known PTP topology; or an event_time whose offset from ingestion_time exceeds the declared uncertainty plus the platform's maximum plausible transport delay. ANOMALOUS_LOCKED is the primary detection signal for confidence inflation (Section 13.1) and MUST be treated as a security event. SIGNATURE_INVALID A tim_signature was present and failed verification (Section 13.2). REPLAY_SUSPECTED Replay conditions per Section 13.3. Collecting platforms SHOULD alert on unexpected sequence gaps from devices operating in LOCKED state, and SHOULD correlate anomaly flags across devices: simultaneous ANOMALOUS_LOCKED or sync_state collapse across a fleet is a signature of an upstream time attack rather than isolated device failure. 13.5. Multi-Classification Environments In multi-classification environments (DOD/DOE), the domain_id field identifies isolated classification domains. Consuming platforms MUST enforce that events from different domain_id values are not cross-correlated without explicit operator authorization, as unauthorized correlation across classification domains may constitute an information security violation. Signed TIM (Section 13.2) SHOULD be used in these environments so that domain_id itself is integrity-protected. 14. IANA Considerations This document, intended for the Standards Track, requests the following IANA actions upon publication: * Registration of a Syslog Structured Data ID ("tim") for TIM fields in the "syslog Structured Data ID Values" registry under the IANA Syslog Parameters registry, per the IETF Review policy of [RFC5424]. * Registration of a YANG module name in the "YANG Module Names" registry (module definition in a companion document). * Creation of a new "TIM Sync Source Values" registry and a new "TIM Temporal Reference Domain Values" registry, initial contents per Tables 6 and 10 respectively, registration policy Specification Required. Detailed registration templates will be provided in a future revision once a sponsoring working group and document shepherd are identified. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, . [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4", RFC 5905, June 2010, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, . [RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, February 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2019, 2020. 15.2. Informative References [IEEE80211AZ] IEEE, "IEEE Standard for Information Technology -- Amendment 4: Next Generation Positioning", IEEE Std 802.11az-2022, 2022. [ITU-G8275] ITU-T, "G.8275.1: Precision time protocol telecom profile for phase/time synchronization", ITU-T Recommendation G.8275.1, 2020. [OSTP-LTC] White House Office of Science and Technology Policy, "Policy on Celestial Time Standardization in Support of the National Cislunar Science and Technology Strategy", April 2024. [OTEL] OpenTelemetry Authors, "OpenTelemetry Specification", . [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014, . [SMPTE-ST12] SMPTE, "Time and Control Code", SMPTE ST 12-1:2014, 2014. [SPANNER] Corbett, J., "Spanner: Google's Globally-Distributed Database", OSDI 2012, 2012. [W3C-TC] W3C, "Trace Context", W3C Recommendation, . Appendix A. Deployment Scenarios This appendix provides non-normative guidance for deploying TIM- capable infrastructure in environments with specialized timing constraints. A.1. Commercial AI Data Center In a commercial data center with a PTP-capable compute fabric: the PTP grandmaster is provided by compute fabric switches; new management cards implementing TIM declare sync_state LOCKED; legacy devices without TIM are classified Class F by the collecting platform; an OCP-TAP Time Server elevates infrastructure card confidence from Class D to Class B; the collecting platform computes efficiency metrics as intervals, with width determined by the least- confident constituent measurement. A.2. Air-Gapped DOD / DOE Facility In an air-gapped facility with IRIG-B time distribution: devices with IRIG-B inputs declare sync_source IRIG_B, sync_state LOCKED, uncertainty_ns ~1000 (1 us), confidence_class B; the domain_id field is populated per classification domain; TIM emissions are COSE- signed with hardware-resident keys; cross-domain correlation is blocked at the collector. No external connectivity is required. A.3. Aeronautical Platform In an airborne computing platform: GPS is the primary source at altitude (Class A); on GPS signal loss in contested airspace, INS provides holdover; uncertainty_ns grows at the INS drift rate during holdover; confidence degrades from A toward E. On GPS recovery, sync_state transitions to RECOVERING, then LOCKED. Fleet-wide simultaneous loss of GPS lock is surfaced as a probable GNSS-denial event per Section 13.4. A.4. Orbital Installation (LEO) In a computing installation in low Earth orbit: the time_domain field MUST be set to UTC_LEO_CORRECTED; relativistic_correction_ns_per_day is populated with the correction for the current orbital altitude (approximately -25,000 for ISS orbit); during communication blackout, AUTONOMOUS state with an onboard atomic clock provides continued operation at Class A/B within the declared domain (Section 5.1). A.5. Lunar Installation In a computing installation on the lunar surface: until LTC is formally defined, the time_domain field is set to FACILITY_AUTONOMOUS; onboard atomic clock ensemble provides the primary time reference; events MUST NOT be directly correlated with UTC_TERRESTRIAL timestamps without applying the ~56 us/day relativistic correction and propagation delay uncertainty; when LTC is defined, time_domain transitions to LTC_LUNAR. A.6. 5G Edge Computing Site In a computing deployment co-located with a 5G base station: the T-GM is GNSS-disciplined to +/-100 ns to 1.5 us and serves as Tier 1D TRM source; primary compute node telemetry achieves Class A; power distribution measurements achieve Class B; facility monitoring achieves Class C; the combined metric interval reflects the weakest link at the facility monitoring temporal coherence; on GNSS outage, the T-GM enters holdover and TIM-capable collectors transition to Class E/B while continuing to declare honest uncertainty throughout. Appendix B. Change Log B.1. Changes from -01 Normative changes: * Corrected the sign and magnitude of the LEO relativistic correction: at ISS altitude velocity time dilation dominates gravitational blueshift and the net correction is approximately -25 us/day; +38 us/day is the GPS-constellation-altitude figure erroneously applied in -01 (Sections 7.1, 7.2, 9.8, A.4). The example field value is corrected to -25000 ns/day, and a sign convention (positive = local clock runs fast relative to the geoid) is now stated in Table 6. * Declared uncertainty is now the primary key for confidence class assignment; the sync-state column of Table 8 (retitled "Typical Sync States") is informative, not restrictive. This resolves the contradiction between Table 8 and both the leap- smearing behavior (Section 8.2: LOCKED at Class E) and the holdover class progression through Classes C and D (Section 5.1). * Defined the uncertainty_source field (MEASURED, SPECIFIED, OPERATOR_FALLBACK, INFERRED), previously referenced normatively by Table 3 but defined nowhere (Section 4.4). * Added Section 11.4 (Shared-Reference Comparison) and Section 11.5 (Collector Reference Diversity), including the requirement that independent attestation use a temporal reference traceable outside the attested host's trust domain. * Failed signature verification now assigns Class F and is treated as a security event, distinct from the benign absence of a signature; the unsigned-TIM ceiling applies to unsigned events only (Section 13.2). * Schema version bumped to "1.2". Editorial changes: * Tightened the regulatory motivation to distinguish frameworks that mandate timestamp accuracy (MiFID II RTS 25) from those whose obligations presuppose it (Section 1.4). * Terminology hygiene: bare "domain" is reserved for temporal reference domains; Table 2 synchronization classes are renamed Tiers; the Class F constraint is restated as ordering against events from other devices (Sections 2.4, 5.1, 9.5, 13.5). * Dropped the "tok/W" abbreviation in favor of "token throughput per watt" (Section 2.4.4); harmonized the lunar relativistic figure at +56.7 us/day. B.2. Changes from -00 The -01 revision incorporated review feedback. Normative changes: * Intended status changed from Informational to Standards Track, consistent with the document's use of BCP 14 requirements, its conformance baseline, and its IANA registration requests (Section 14 restructured accordingly). * Resolved the FREEWHEEL contradiction: FREEWHEEL now uniformly implies no defensible bound and Class F; bounded post-lock drift is HOLDOVER by definition (Sections 5.1, 6, Table 8). * AUTONOMOUS state mapped into the confidence class table (Class A/B within its declared domain) (Section 5.1). * Added boot_id (sequence epoch) as a required field; defined monotonicity scope, wraparound behavior, reset detection, and consumer handling, replacing the -00 random-reinitialization rules that broke monotonicity (Sections 4.2, 10.3). * Defined all anomaly flags normatively, including the previously undefined ANOMALOUS_LOCKED, plus new SIGNATURE_INVALID and REPLAY_SUSPECTED (Section 13.4). * Added domain scoping of confidence classes (_collector.class_scope); relative-domain Class A is no longer indistinguishable from UTC-traceable Class A (Section 5.3; example 9.7). * Added asymmetric uncertainty intervals with explicit precedence rules (Section 4.1.3; uncertainty_asymmetric field). * Added Section 8 on leap seconds, leap smearing, and UTC/TAI conversion, with leap_state, smear_model, and tai_offset_s fields and a smear-window example (9.9). * Rewrote Security Considerations with an explicit threat model, concrete signing mechanisms (COSE_Sign1 [RFC9052] and JWS [RFC7515]/[RFC7797]) with signing-scope requirements, and replay protection built on the sequence epoch mechanism (Section 13; signed example 9.10). Editorial changes: * Added missing references: [IEEE1588], [OTEL], [W3C-TC]; reframed RFC 3164 as the informational description of legacy BSD syslog, obsoleted by RFC 5424. * Added Class C/D boundary rationale (Section 5.2). * Corrected Section 2.4.2 to note that NTP uncertainty is bidirectional. * Corrected the derived interval bounds in the holdover example (9.4) to match uncertainty_ns exactly. * Schema version bumped to "1.1"; examples updated with boot_id and class_scope. Author's Address William "Trey" Ackerman Vertiv Holdings Co. 3414 Governors Dr SW Huntsville, AL 35805 United States of America Email: william.ackerman@vertiv.com, treyackerman@hotmail.com