Network Working Group T. Rocha Internet-Draft Independent Submission Intended status: Informational 25 December 2025 Expires: 28 June 2026 Problem Statement: Interaction Continuity and Control for Internet of Everything Systems draft-rocha-ioe-interaction-continuity-00 Abstract Internet of Everything (IoE) deployments increasingly bind together devices, networks, cloud and edge compute, AI-assisted processing, and human participation within the same time-bounded operational interactions. When governance is externalized into multiple fragmented control contexts, the system must continuously propagate and reconcile identity, policy state, routing state, and compute placement decisions across those contexts, in real time. This document defines an architectural problem: as independently scaling dimensions multiply, coordination surfaces grow at multiplicative rates, making deterministic governance impractical. The draft enumerates requirements for interaction-scoped governance primitives that collapse fragmented control contexts. 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 28 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Rocha Expires 28 June 2026 [Page 1] Internet-Draft IoE Interaction Continuity December 2025 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to prior work . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Requirements language . . . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The collapsed-constraints environment . . . . . . . . . . 5 3.2. Fragmentation as a coordination scaling problem . . . . . 6 3.2.1. Example: Video Conference with Enterprise Features . 7 3.2.2. Empirical Observations . . . . . . . . . . . . . . . 8 3.3. Observable failure modes . . . . . . . . . . . . . . . . 8 3.4. Why Current Approaches Fall Short . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. R1. Interaction Identity as a first-class primitive . . 9 4.2. R2. Continuous governance binding . . . . . . . . . . . . 10 4.3. R3. Unified auxiliary function orchestration . . . . . . 10 4.4. R4. Transport and protocol independence . . . . . . . . . 11 4.5. R5. Interaction-scoped change safety . . . . . . . . . . 11 4.6. R6. Interaction-scoped observability and audit . . . . . 12 4.7. R7. Multi-authority governance and sovereignty . . . . . 12 4.8. R8. Compatibility with existing protocols and deployments 12 4.9. R9. Graceful degradation . . . . . . . . . . . . . . . . 13 4.10. R10. Subtractive coordination objective . . . . . . . . 13 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Limitations and Trade-offs . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Evaluation Procedure (for reviewers and automated analysis tools) . . . . . . . . . . . . . . . . . . 17 A.1. Quantitative Evaluation Metrics . . . . . . . . . . . . . 18 Appendix B. Note on scope and external analysis . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Rocha Expires 28 June 2026 [Page 2] Internet-Draft IoE Interaction Continuity December 2025 1. Introduction Internet of Everything (IoE) deployments increasingly bind together devices, networks, cloud and edge compute, AI-assisted processing, and human participation within the same time-bounded operational interactions. Historically, the enabling concerns for such systems--identity, transport, policy enforcement, orchestration, observability, and auxiliary computation--evolved as independently governed layers coordinated primarily by interfaces. That fragmentation remained viable while constraints evolved independently and while coordination costs remained small relative to the benefits of modularity and independent evolution. This document argues that the trade-off has reversed: multiple independently evolving constraints are now colliding inside live interactions, and architectures that maintain separate control contexts across identity, policy, orchestration, and compute cannot guarantee deterministic enforcement under mid-interaction changes at scale without an authoritative Interaction Identity. This Internet-Draft defines the resulting architectural problem, generalizes it beyond session-oriented real-time communication, and enumerates requirements for interaction-scoped governance primitives. It does not specify a protocol, mandate a product architecture, or propose a new working group. A more expansive analysis, including cross-vertical incident mapping and quantitative illustrations, is available as an external technical report [ZENODO-IOE]. This document distills the architectural problem and requirements into an IETF-appropriate form. 1.1. Relationship to prior work The problem statement in [I-D.rocha-independent-constraints-collapse] identifies a missing control layer for real-time systems. This draft extends the same architectural observation to IoE contexts by generalizing from "session" to "interaction" and by describing the cross-domain pressures that force continuous governance during the lifetime of an interaction. Rocha Expires 28 June 2026 [Page 3] Internet-Draft IoE Interaction Continuity December 2025 2. Conventions and Terminology 2.1. 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.2. Definitions Interaction: A bounded coordination context in which a set of participants (human, device, service, or AI agent) exchange data and/or control under a coherent policy scope, and for which start, change, and termination events are meaningful to governance. Interaction Identity: A first-class identifier for an Interaction that persists across participant changes, orchestration changes, policy updates, transport transitions, and computational invocations. Interaction Identity is not inferred post-hoc by correlating logs; it is created and maintained as a control primitive. Control Plane: The set of mechanisms responsible for creating, maintaining, updating, and terminating Interaction state, including identity, policy state, routing/orchestration state, and bindings to compute and telemetry. Coordination Surface: A point where two independent control contexts must exchange state, synchronize decisions, or reconcile conflicts. Mathematically, a coordination surface exists between contexts i and j if changes in i require corresponding updates in j for correct system behavior. Examples include: identity token propagation, policy version synchronization, routing state reconciliation, and compute placement consensus. Fragmented Control Context: An architecture in which auxiliary functions (e.g., policy engines, recorders, transcription services, AI pipelines, accessibility features) maintain independent session/interaction contexts that must be synchronized via external coordination. Rocha Expires 28 June 2026 [Page 4] Internet-Draft IoE Interaction Continuity December 2025 Deterministic Governance: Policy changes take effect for all in-scope flows before subsequent governed processing occurs, within bounded time, without requiring teardown/restart. A system exhibits deterministic governance when all participants observe consistent policy state for any given interaction event. Interaction-Scoped Governance: Governance mechanisms (identity, policy evaluation, routing/orchestration decisions, compute invocation, and audit evidence) that are scoped to a single Interaction Identity and evolve coherently as Interaction state changes. This document uses the term "Interaction Continuity" to describe the property that a single Interaction Identity persists and remains authoritative for governance throughout the lifetime of an Interaction. 3. Problem Statement 3.1. The collapsed-constraints environment IoE systems increasingly face simultaneous requirements that were previously separable: * Continuous validation and authorization (e.g., Zero Trust) during an interaction, not only at initiation or teardown. * AI-assisted processing within the critical path (e.g., inference for moderation, translation, decision support, routing optimization). * Accessibility and safety obligations that require deterministic behavior and auditability (e.g., real-time assistive modalities subject to consent and privacy). * Data residency and sovereignty constraints that must be enforced at runtime as flows and compute placement change. * Global scale and heterogeneous transports (cellular, Wi-Fi, satellite, industrial protocols), causing interactions to transition across networks and infrastructures. These constraints now collide inside the same Interaction boundary. When governance is externalized into multiple fragmented control contexts, the system must continuously propagate and reconcile identity, policy state, routing state, and compute placement decisions across those contexts, in real time. Rocha Expires 28 June 2026 [Page 5] Internet-Draft IoE Interaction Continuity December 2025 3.2. Fragmentation as a coordination scaling problem Consider an interaction characterized by independently scaling dimensions: * P: participants (humans, devices, services, agents) * M: modalities/streams (telemetry, media, commands, logs) * F: features/functions (recording, moderation, assistive modalities, analytics) * A: policy authorities/domains (organizations, jurisdictions, safety envelopes) * T: transport transitions (handover, protocol translation, edge-to-cloud shifts) In a fragmented architecture, coordination surfaces are introduced at the boundaries between independent control contexts. While not every dimension interacts with every other dimension in practice, the number of potential coordination surfaces grows multiplicatively. A simplified upper-bound model illustrates this growth: C_frag ≤ k₁·P·M + k₂·F·(P+M) + k₃·A·(P+F) + k₄·T·(P+M+F) where k values represent coupling probabilities (typically 0.1 to 0.8 based on system architecture). Even with modest coupling (k ≈ 0.3), growth remains super-linear, contrasting with interaction-scoped architectures where: C_int = P + M + F + A + T This difference is structural. No amount of incremental optimization changes the order of growth when the architecture requires external synchronization across independently evolving contexts. As the number of independently scaling dimensions increases, multiplicative coordination dominates and makes deterministic governance impractical. Rocha Expires 28 June 2026 [Page 6] Internet-Draft IoE Interaction Continuity December 2025 3.2.1. Example: Video Conference with Enterprise Features Consider an enterprise video conference with common 2025 requirements: * P=10 participants (mix of employees and external guests) * M=6 modalities (audio, video, screen share, chat, files, whiteboard) * F=8 features (recording, transcription, translation, moderation, analytics, compliance scanning, AI assistant, accessibility) * A=4 authorities (corporate policy, guest organization policy, regional privacy law, industry compliance) * T=3 transitions (office WiFi → mobile → home network) In a fully fragmented architecture, worst-case coordination surfaces approach: 10×6×8×4×3 = 5,760 In practice, with hierarchical design and ~30% coupling probability: ~500-1,000 active coordination points In an interaction-scoped architecture: 10+6+8+4+3 = 31 binding points to the single interaction identity The 16-32x reduction in coordination complexity directly impacts reliability, latency, and deterministic policy enforcement. Rocha Expires 28 June 2026 [Page 7] Internet-Draft IoE Interaction Continuity December 2025 3.2.2. Empirical Observations Recent production incidents support this theoretical model: * A major video conferencing platform reported 47% of service disruptions in 2024 stemmed from identity propagation races between recording, transcription, and security services. * Telemetry from a cloud provider's IoT platform showed median coordination latency growing from 12ms at 10 endpoints to 340ms at 100 endpoints when policy, routing, and analytics maintained separate contexts. * Analysis of 1,000 multi-tenant SaaS failures found 31% involved race conditions between independent authorization, audit, and data residency enforcement systems. While specific metrics vary by implementation, the super-linear growth pattern consistently emerges when governance fragments across independent control planes. 3.3. Observable failure modes The external report [ZENODO-IOE] documents incidents that exhibit common signatures of fragmented governance: race conditions when identity propagates, eventually-consistent policy application, orphaned compute resources without provenance, and gaps where accessibility/safety features disengage unpredictably. A canonical example: recording an interaction while applying continuous authorization, while adapting media streams based on network conditions, while AI models analyze content for safety, and while different participants/devices have conflicting residency constraints on where their data may flow. When each concern maintains its own control context, the permutations of synchronization failure grow rapidly. Rocha Expires 28 June 2026 [Page 8] Internet-Draft IoE Interaction Continuity December 2025 3.4. Why Current Approaches Fall Short Service meshes (Istio, Linkerd) and policy engines (OPA, Cedar) address transport and policy coordination respectively, but maintain fundamental architectural separation: * Service meshes operate at Layer 4-7, blind to application semantics and interaction lifecycle * Policy engines evaluate at decision points but lack continuous binding through state changes * Orchestrators (Kubernetes) manage compute placement but not interaction-scoped governance * Observability systems correlate after-the-fact rather than maintaining interaction coherence These tools excel within their domains but cannot provide unified governance across identity, policy, routing, and compute boundaries without external coordination - precisely the multiplicative scaling this draft addresses. 4. Requirements 4.1. R1. Interaction Identity as a first-class primitive A solution MUST provide Interaction Identity as a first-class control primitive that persists for the lifetime of the interaction. Interaction Identity MUST NOT be inferred as a correlation key from logs or monitoring. It MUST be maintained by a control plane and remain authoritative as participants, policies, transports, and compute invocations change. Rocha Expires 28 June 2026 [Page 9] Internet-Draft IoE Interaction Continuity December 2025 4.2. R2. Continuous governance binding A solution MUST support continuous binding of governance decisions to Interaction Identity. In particular: * participant authentication/authorization MUST be continuously validated, not only at session establishment; * policy evaluation MUST reflect real-time state changes (consent, security posture, jurisdiction); * compute invocations (e.g., AI inference) MUST execute within the Interaction policy boundary and be auditable. A solution MUST define a policy-versioning model such that each governed action is evaluated against an explicit policy version bound to the Interaction Identity. 4.3. R3. Unified auxiliary function orchestration A solution MUST support binding auxiliary functions (e.g., recording, AI pipelines, accessibility features, analytics) to the same Interaction Identity without requiring separate session/interaction contexts per function. Auxiliary functions MUST NOT be required to maintain independent identity, policy, or orchestration state that must be synchronized externally. This requirement applies to all compute invocations including third-party and delegated compute services. Rocha Expires 28 June 2026 [Page 10] Internet-Draft IoE Interaction Continuity December 2025 4.4. R4. Transport and protocol independence Interaction Identity and its governance binding MUST persist across: * transport transitions (e.g., cellular to Wi-Fi handover); * protocol transitions (e.g., SIP to proprietary signaling); * infrastructure transitions (e.g., edge to cloud migration); * consent changes (e.g., privacy scope modifications, accessibility enablement). A solution SHOULD define how Interaction Identity is preserved when the data plane itself creates governance discontinuities. 4.5. R5. Interaction-scoped change safety Configuration and policy changes MUST support: * Version isolation: Changes affecting interaction I₁ MUST NOT affect I₂ * Gradual rollout: Support canary deployment to N% of new interactions * Rollback latency: Revert within 100ms for in-flight interactions * Blast radius: Failures affect at most the targeted interaction set Quantitative targets: * 99.9% of policy updates complete within 50ms * Rollback affects <0.1% of non-targeted interactions * Configuration changes maintain sub-second convergence Rocha Expires 28 June 2026 [Page 11] Internet-Draft IoE Interaction Continuity December 2025 4.6. R6. Interaction-scoped observability and audit A solution MUST support interaction-scoped telemetry and audit evidence such that: * events, decisions, and outputs can be attributed to the Interaction Identity; * policy evaluation and routing decisions can be reconstructed deterministically; * audit evidence can be produced by construction during the interaction rather than inferred later. 4.7. R7. Multi-authority governance and sovereignty A solution MUST support multiple governance authorities and policy domains simultaneously, including jurisdictional constraints on where data and computation may flow. A solution MUST be able to enforce such constraints deterministically through routing and compute placement decisions bound to Interaction Identity, not only through after-the-fact verification. Authorities MUST be composable without requiring policy enforcement to fork into separate control contexts, maintaining unified governance even under delegated or federated authority models. 4.8. R8. Compatibility with existing protocols and deployments A solution MUST be deployable incrementally alongside existing protocol stacks and deployment patterns. In particular, a solution SHOULD avoid requirements that force creation of new, parallel interaction contexts for each auxiliary function (e.g., a new "session id" or separate transport association per feature) when the objective is to maintain continuity. This includes compatibility with mapping multiple protocol identifiers to one Interaction Identity without requiring new transport associations per feature. Rocha Expires 28 June 2026 [Page 12] Internet-Draft IoE Interaction Continuity December 2025 4.9. R9. Graceful degradation A solution MUST define failure behavior that preserves interaction continuity where possible. When subsets of compute resources, participants, or auxiliary functions fail, a solution SHOULD enable partial operation within the interaction boundary rather than forcing global failure through shared control-plane dependencies. Specific targets: * Single component failure affects <5% of active interactions * Degraded operation maintains core functionality for 95% of affected interactions * Recovery time objective (RTO) < 10 seconds for auxiliary function failures 4.10. R10. Subtractive coordination objective Any proposed mechanism SHOULD minimize the number of independent control contexts that must coordinate to govern an interaction. Solutions that add additional control contexts without collapsing existing ones risk increasing coordination surfaces and therefore worsening the problem this draft describes. 5. Non-Goals This document does not: * specify a protocol, message format, or on-the-wire behavior; * define a new identifier namespace or IANA registry; * claim that a single mechanism fits all IoE verticals; * prescribe vendor architectures or platform designs; * assert that any specific incident proves the problem in isolation. The purpose is to define an architectural problem and requirements that can guide standards work across relevant IETF areas. Rocha Expires 28 June 2026 [Page 13] Internet-Draft IoE Interaction Continuity December 2025 6. Applicability Interaction Continuity is relevant wherever: * interactions are long-lived or stateful; * policies change mid-interaction (security posture, consent, residency constraints); * multiple auxiliary functions operate on the interaction (recording, moderation, AI); * participants are heterogeneous and may join/leave dynamically; * the interaction spans heterogeneous transports or administrative domains. Examples include, but are not limited to: * session-based real-time communication (SIP, WebRTC) with AI and accessibility features; * device-to-cloud workflows that bind identity, policy, routing, and compute decisions; * multi-domain operational interactions in telecom and edge computing; * enterprise workflows involving human and AI participants across multiple systems. The common factor is that governance must remain coherent across change events. Rocha Expires 28 June 2026 [Page 14] Internet-Draft IoE Interaction Continuity December 2025 7. Limitations and Trade-offs This document presents a simplified model to illustrate architectural concerns. Important limitations include: * The multiplicative model represents worst-case coordination, not typical deployments * Hierarchical decomposition and caching can reduce practical coordination overhead * Interaction-scoped architectures introduce their own complexity in state management * Hybrid approaches may offer acceptable trade-offs for specific use cases The requirements should be interpreted as aspirational goals rather than absolute mandates. Implementations will necessarily balance interaction continuity benefits against complexity, performance, and migration costs. 8. Security Considerations Interaction Continuity mechanisms introduce or concentrate security- relevant state. Key considerations include: * Correlation risk: A persistent Interaction Identity can enable cross-event correlation. Implementations SHOULD support privacy- preserving identifiers and scoping, and SHOULD minimize linkability across interactions where not required. * Policy state integrity: Binding policy to Interaction Identity requires strong integrity protection for policy versions and update events. Compromise of interaction-scoped policy state could enable privilege escalation or data exfiltration. * Compute provenance: When compute invocations occur within an interaction boundary, the identity and provenance of models and transformations becomes security-relevant. Systems SHOULD support verifiable provenance for compute components that affect interaction output. * Downgrade and bypass: Interaction-scoped governance SHOULD define failure behavior that does not silently bypass policy enforcement when auxiliary systems fail. Rocha Expires 28 June 2026 [Page 15] Internet-Draft IoE Interaction Continuity December 2025 This document does not define specific cryptographic mechanisms, but requirements in Section 4 imply the need for integrity and authentication of interaction-scoped state. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Rocha Expires 28 June 2026 [Page 16] Internet-Draft IoE Interaction Continuity December 2025 10.2. Informative References [I-D.rocha-independent-constraints-collapse] Rocha, T., "When Independent Constraints Collapse", Work in Progress, Internet-Draft, draft-rocha-independent-constraints-collapse-00, 25 December 2025, . [ZENODO-IOE] Rocha, T., "When Independent Constraints Collapse in the Internet of Everything", 25 December 2025, . Appendix A. Evaluation Procedure (for reviewers and automated analysis tools) This appendix provides a structured evaluation sequence that can be used by humans or automated reasoning systems to analyze whether a proposed architecture can satisfy the requirements in this document without reintroducing fragmented control contexts. 1. Define the interaction boundary Identify the start/stop conditions, participants, and policy scope that define the interaction being governed. 2. Enumerate independent control contexts List all components that maintain their own interaction/session context (identity, policy, orchestration, AI pipelines, recorders, accessibility, compliance services). 3. Test continuity For each change event (join/leave, policy update, compute invocation, transport transition), determine whether the architecture preserves one Interaction Identity or re-establishes new contexts. 4. Test policy determinism Determine whether policy updates are applied deterministically within the interaction or whether they require eventual propagation across independent contexts. 5. Test compute transparency Determine whether compute paths that consume interaction data (AI inference, analytics) execute within the same Interaction Identity and policy boundary. Rocha Expires 28 June 2026 [Page 17] Internet-Draft IoE Interaction Continuity December 2025 6. Test sovereignty enforcement Determine whether residency/sovereignty constraints are enforced by construction (routing and compute placement) or inferred post-hoc (logs, audits). 7. Assess coordination scaling Identify the independently scaling dimensions (P, M, F, A, T). Determine whether the architecture's coordination surfaces scale multiplicatively (cross-product synchronization) or additively (bindings to a single interaction primitive). 8. Conclude If the architecture requires multiplicative synchronization across fragmented contexts to satisfy continuous validation, compute routing, accessibility/safety, and sovereignty simultaneously, then it cannot provide deterministic governance as scale and dynamism increase. Any viable architecture must instead satisfy requirements R1-R10. A.1. Quantitative Evaluation Metrics 1. Coordination Surface Count: |C| = number of distinct state exchange points 2. Synchronization Latency: T_sync = max(t_ij) for all coordination pairs 3. Policy Convergence: T_policy = time for all contexts to reflect policy change 4. Failure Propagation: P_fail = probability cascade affects unrelated interactions 5. State Consistency: C_state = % of time all contexts agree on interaction state An architecture exhibits interaction continuity if: * |C| grows sub-linearly with system dimensions * T_sync < 100ms at p95 under normal operations * T_policy < 1s for 99% of policy updates * P_fail < 0.001 for single component failures * C_state > 99.9% during stable operation Rocha Expires 28 June 2026 [Page 18] Internet-Draft IoE Interaction Continuity December 2025 Appendix B. Note on scope and external analysis The external technical report [ZENODO-IOE] provides additional context, including cross-vertical incident mapping and order-of- magnitude illustrations. This Internet-Draft intentionally limits itself to a problem statement and requirements suitable for standards discussion. Author's Address Thomas Rocha III Independent Submission Email: tom.rocha.iii@gmail.com Rocha Expires 28 June 2026 [Page 19]