Individual Submission C.X. Ruvalcaba Internet-Draft Saluca LLC Intended status: Standards Track 11 August 2026 Expires: 12 February 2027 The NHE Mesh Protocol: Entity-to-Entity Messaging and Task Distribution draft-ruvalcaba-nhe-mesh-00 Abstract The NHE Mesh Protocol lets independently operated Non-Human Entities (NHEs) exchange messages and distribute work without a central coordinator. It defines three things: a liveness/presence mechanism, an addressed message envelope, and a task lifecycle (create, claim, complete) that provides at-most-once assignment of a unit of work across mutually distrusting peers. Peers are named by their NHE identity and authenticated through the NHE identity interface; the Mesh Protocol carries the envelope and runs over a secure transport. This is a skeleton (-00): the framing, message set, and state machine are specified here, and the concrete on-the-wire encoding is deferred to the next revision. 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 12 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. Ruvalcaba Expires 12 February 2027 [Page 1] Internet-Draft NHE Mesh August 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Relationship to the NHE Architecture . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Task Lifecycle . . . . . . . . . . . . . . . . . . . . . 4 5. Wire Format (to be specified in -01) . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 9. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Persistent autonomous agents increasingly need to talk to one another and to hand work back and forth: one entity discovers that a peer is alive, sends it a message, or posts a unit of work that some peer claims and later completes. Today each system invents this afresh. This document specifies a minimal, transport-agnostic protocol for it, in the setting of the NHE reference architecture [I-D.ruvalcaba-nhe-arch]. The Mesh Protocol deliberately does the smallest useful thing: presence, addressed messages, and a three-state task lifecycle. Routing topology, discovery of unknown peers, and payload semantics are out of scope. 2. Relationship to the NHE Architecture This document specifies the Mesh interface of the NHE reference model [I-D.ruvalcaba-nhe-arch] and inherits that document's scope framing: an NHE is a functional artifact, not a living or sentient entity, and every participant remains subject to operator control, inspectability, and bounded authority. In particular, a peer's authority to create or claim tasks is conferred and revocable per that model; the Mesh Protocol conveys such actions but does not itself grant authority. Ruvalcaba Expires 12 February 2027 [Page 2] Internet-Draft NHE Mesh August 2026 Peer identity and authentication are provided by the NHE identity interface (a companion document), not redefined here. The Mesh Protocol assumes each participant has a verifiable identity and that message authentication binds to it. 3. Terminology The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Participant: An NHE that sends or receives Mesh messages, named by its NHE identity. Message: An addressed, authenticated envelope from one participant to another. Task: A unit of work posted by a creator and executed by at most one claimant. Heartbeat: A liveness/presence announcement. 4. Protocol Overview The Mesh Protocol comprises two sub-protocols over a common envelope: * *Messaging:* HEARTBEAT (presence), SEND (addressed message), and inbox retrieval of messages addressed to a participant. * *Task distribution:* CREATE, CLAIM, and COMPLETE, plus enumeration of open tasks, providing at-most-once assignment. 4.1. Messaging A participant periodically emits a HEARTBEAT carrying its identity and a monotonically increasing sequence, so peers can track liveness without polling. A SEND message carries sender identity, recipient identity, a message identifier, and an opaque payload. Delivery is to the recipient's inbox; retrieval and acknowledgment semantics are specified in Section 5. Message authentication MUST bind the envelope to the sender's identity; recipients MUST reject a message whose authentication does not verify against the claimed sender identity. Ruvalcaba Expires 12 February 2027 [Page 3] Internet-Draft NHE Mesh August 2026 4.2. Task Lifecycle A task moves through a small state machine. CREATE posts a task with a task identifier, an addressing scope (which peers may claim it), and an opaque descriptor. CLAIM is an atomic mutual-exclusion operation: at most one participant may transition a task from OPEN to CLAIMED; concurrent claims MUST resolve so that exactly one succeeds and the others observe the task as already claimed. COMPLETE transitions CLAIMED to COMPLETED and carries an opaque result. A claimed-but-unfinished task MAY expire back to OPEN after a creator- specified deadline, so that a failed claimant does not strand the work. CREATE CLAIM (atomic, COMPLETE | at-most-one) | v | v [ OPEN ] -----------+------> [ CLAIMED ] -----> [ COMPLETED ] ^ | | claim deadline expires | +------------------------------+ At-most-once assignment is the core guarantee: the protocol ensures a unit of work is executed by no more than one claimant at a time. It does not by itself guarantee exactly-once execution across claimant failure; creators requiring that MUST make task descriptors idempotent. 5. Wire Format (to be specified in -01) This skeleton fixes the message set and the task state machine. The concrete encoding --- envelope layout, identifier sizes, the atomic- claim mechanism on the wire, heartbeat cadence, and inbox acknowledgment --- is deferred to the next revision. The intended design principles are: a compact binary envelope with a version and message-type octet (mirroring the approach of HCTP [I-D.ruvalcaba-hctp]); a registry-controlled message-type space (Section 7); identity binding via a signature or AEAD over the envelope, delegated to the identity/transport layers; and an idempotent, retry-safe CLAIM so that a lost response cannot cause a double assignment. Ruvalcaba Expires 12 February 2027 [Page 4] Internet-Draft NHE Mesh August 2026 6. Security Considerations Participants are mutually distrusting. Every message and task operation MUST be authenticated to the acting participant's NHE identity; unauther- ticated or unverifiable operations MUST be rejected. Confidentiality and peer authentication are provided by the underlying secure transport (for example TLS [RFC8446] or QUIC [RFC9000]) and/or by the identity layer; the Mesh Protocol provides the envelope and the task semantics, not a secure channel of its own. The CLAIM operation is a mutual-exclusion primitive and is the primary abuse target: a malicious peer that claims work it will not complete can starve the mesh. The expiry-to-OPEN transition bounds this, and creators SHOULD scope who may claim a task. Replay of a CLAIM or COMPLETE MUST be detected (for example via task-state versioning) so that a replayed COMPLETE cannot overwrite a later state. Heartbeats reveal liveness and identity and SHOULD be sent over the protected transport where that is sensitive. All operations remain subject to the operator-control and bounded- authority invariants of [I-D.ruvalcaba-nhe-arch]: a participant's ability to create or claim tasks is a revocable grant. 7. IANA Considerations A future revision will request two registries: "NHE Mesh Message Types" (for HEARTBEAT, SEND, and task operations CREATE/CLAIM/ COMPLETE) and "NHE Mesh Task States" (OPEN, CLAIMED, COMPLETED, and any additions), each under a Specification Required policy [RFC8126]. No IANA action is requested by this skeleton revision. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 9. Informative References Ruvalcaba Expires 12 February 2027 [Page 5] Internet-Draft NHE Mesh August 2026 [I-D.ruvalcaba-hctp] Ruvalcaba, C.X., "The Hash-Chain Context Transfer Protocol (HCTP)", Work in Progress, Internet-Draft, draft- ruvalcaba-hctp-00, August 2026, . [I-D.ruvalcaba-nhe-arch] Ruvalcaba, C.X., "An Architecture for Non-Human Entities (NHE)", Work in Progress, Internet-Draft, draft-ruvalcaba- nhe-arch-00, August 2026, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021, . Author's Address Cristian Xavier Ruvalcaba Saluca LLC Email: cristian@saluca.com Ruvalcaba Expires 12 February 2027 [Page 6]