Network Management Research Group C. Janz Internet-Draft H. Rahimi Intended status: Informational H. Yu Expires: 10 December 2026 Huawei 8 June 2026 Dynamic Network-as-a-Service Life-Cycle Automation Using End-to-End Agent Negotiation draft-janz-nmrg-naas-agentic-negotiation-00 Abstract This document describes a possible direction for the management of Network-as-a-Service (NaaS), in which the relationship between a service consumer and a provider is treated not as a static contract but as a continuous, automated negotiation conducted on both sides by cognitive software agents. A NaaS whose required bandwidth, latency and availability move continuously cannot be settled once at order time; it is a standing dialogue - intent, quote, agreement and in- life change - that today stops at the customer-operator boundary and is bridged by humans. The document frames that boundary as the unautomated gap, sketches an end-to-end agentic negotiation architecture that closes it, and describes the intent instance as a managed object whose life cycle includes scarcity-driven pricing and closed-loop renegotiation. It maps the architecture onto already- published specifications from several bodies, showing that the direction rests on a standards basis rather than on new protocol invention. Two NaaS settings illustrate its utility. 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 10 December 2026. Janz, et al. Expires 10 December 2026 [Page 1] Internet-Draft NaaS Agentic Negotiation June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. NaaS as a Standing Negotiation . . . . . . . . . . . . . . . 5 4. Problem Statement: Intent Does Not Cross the Boundary . . . . 6 5. An End-to-End Agentic Negotiation Architecture . . . . . . . 6 5.1. Three Domains and a Negotiation Plane . . . . . . . . . . 6 5.2. Cooperating Agents with Single Responsibilities . . . . . 7 5.3. Four Well-Defined Seams . . . . . . . . . . . . . . . . . 7 5.4. The Intent Wallet and a Bounded Model . . . . . . . . . . 8 6. Intent-Instance Life-Cycle Management . . . . . . . . . . . . 8 6.1. The Intent Instance as a Live Object . . . . . . . . . . 8 6.2. End-to-End Negotiation Flow . . . . . . . . . . . . . . . 9 6.3. Scarcity-Driven Pricing . . . . . . . . . . . . . . . . . 9 6.4. Closed-Loop Renegotiation . . . . . . . . . . . . . . . . 10 7. Standards Foundations and Mapping . . . . . . . . . . . . . . 10 8. Illustrative Use Cases . . . . . . . . . . . . . . . . . . . 13 8.1. Service Switching Across IP and Optical Networks . . . . 13 8.2. Dynamic Performance-on-Demand for Financial Trading . . . 13 9. Relationship to NMRG Work and Open Research Questions . . . . 14 10. Considerations for Implementation . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 13. Normative References . . . . . . . . . . . . . . . . . . . . 16 14. Informative References . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Network-as-a-Service (NaaS) describes an arrangement in which a consumer obtains network services on demand, expressed by what the consumer needs rather than by how the provider realises it. For a class of demanding applications the bandwidth, latency and availability a service must deliver do not hold still: they track the workload above the network, which itself moves with external events. Janz, et al. Expires 10 December 2026 [Page 2] Internet-Draft NaaS Agentic Negotiation June 2026 A service whose required characteristics change continuously cannot be captured by a contract signed once at order time. The relationship is inherently in-life rather than one-shot - a standing, ongoing dialogue between the consumer and the operator about what is needed now, what it costs now, and what should change next. Inside an operator, much of the machinery to conduct that dialogue already exists. Closed-loop automation assures live services against their objectives; intent-driven management lets objectives be stated declaratively; and economic frameworks for NaaS describe how a provider should ration scarce resources by price. Inside a consumer, applications know the quality they need and the price they are willing to pay. What still depends on a human is the seam between the two: the customer-operator boundary, across which intent, quote, agreement and in-life change have to pass. Standards exist on both sides of that seam, but they stop at the edge and do not meet across it. A consumer that is rich in intent meets an operator that is rich in capability in a portal: a person fills in a form, an order works its way through tickets, and the result is measured in days. There is no live negotiation - no counter-offer, no scarcity-aware quote, no automatic in-life change - and the signed contract is opaque to the consumer's own software. The broader move toward agentic software architectures, in which autonomous components hold knowledge, reason, converse and act through well-defined tools, makes a different option conceivable. If each side of the boundary is represented by an agent, the dialogue that a human conducts today can be conducted between the agents directly, in seconds rather than weeks, and continuously rather than once. This document explores that direction. It frames NaaS as a standing negotiation (Section 3), states the boundary problem (Section 4), sketches an end-to-end agentic negotiation architecture that closes it (Section 5), and describes the life cycle of the negotiated object (Section 6). It then maps every interface and event of the architecture onto an already-published specification, drawn from several standards bodies and from emerging ecosystem work, to show that the direction is a composition of existing standards rather than a call for new protocol (Section 7). Two NaaS settings illustrate the utility of the approach (Section 8), and the document closes by situating the work relative to current NMRG activity and naming the research questions it raises (Section 9). None of the architecture described here is presented as a worked engineering specification; it is a direction the authors believe is worth the research group's attention. Janz, et al. Expires 10 December 2026 [Page 3] Internet-Draft NaaS Agentic Negotiation June 2026 2. Conventions and Definitions 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. The following terms are used: Network-as-a-Service (NaaS): a network service obtained on demand and expressed by required outcomes - typically bandwidth, latency and availability - rather than by the resources used to realise it, as framed for the management context by [ETSI-ZSM-019]. Cognitive Agent: an autonomous software entity built around a language model and one or more controlled stores of knowledge, able to reason about what it is presented with, to converse in natural language, and to act on the world only through a bounded set of typed tools [RFC9315]. Negotiation Plane: an additive layer in which the consumer's and the operator's agents exchange intents, quotes, agreements and counter-offers. It sits above whatever orchestration each party already runs and takes no hard runtime dependency on it. Intent: a declarative expression of operational objectives that an entity wishes a network to meet, without specifying how, as defined by [RFC9315]. Intent Instance: the live, managed object created when an intent is accepted: a standing agreement with state, governed across its life from negotiation through assurance, renegotiation and termination, rather than a static document. Intent Wallet: a signed, auditable authorization object, carried with each intent, that states the spending and policy envelope within which a consumer's agent may commit - the network's equivalent of an agent-payment authorization. Janz, et al. Expires 10 December 2026 [Page 4] Internet-Draft NaaS Agentic Negotiation June 2026 Scarcity-Based Pricing: the rationing of network resources through price rather than by exposing allocation to the consumer, with scarcer resources priced higher than plentiful ones [ETSI-ZSM-019]. Closed Loop: a control arrangement in which observed or forecast behaviour of a live service is continuously compared against its objectives and drives corrective action without human intervention [RFC7575]. Variable Abstraction: the operational practice of presenting information at the level of detail appropriate to a particular interaction [ETSI-ZSM-019]. 3. NaaS as a Standing Negotiation The management framework for NaaS set out in [ETSI-ZSM-019] distils the setting into three recurring characteristics, all of which bear on why the relationship cannot be static. First, service composition is complex: a service may be connectivity-only or may include non- connectivity components at arbitrary topological complexity, each component individually customised for bandwidth, latency and availability. Second, composition is dynamic: services, their components and their characteristics are created, modified and deleted continuously, not once at order time, so the relationship is inherently in-life. Third, demand is fragmented: it arrives in parallel from many sources, aggregated through stages under different ownership, so that retail and wholesale demand may flow through one or more NaaS operators before reaching the framework that satisfies it. Taken together these characteristics describe demand that is continuous, heterogeneous and economically driven. The same framework observes that a NaaS consumer has no intrinsic means of regulating its own resource use and that resources should therefore be rationed rationally, generally through price, with scarcer resources priced higher than plentiful ones. A NaaS relationship therefore has the shape of a market: demand is endogenous to the applications above the network, and willingness to pay - not visibility into allocation - is what bounds consumption. Treating such a relationship as a fixed contract is a category error; it is more faithfully modelled as a continuous negotiation between the two sides. What makes that negotiation tractable to automate is that the consumer and the operator each already hold one half of it. The consumer is intent-rich: it knows the quality-of-service, latency, bandwidth and cost ceiling it wants. The operator is capability- Janz, et al. Expires 10 December 2026 [Page 5] Internet-Draft NaaS Agentic Negotiation June 2026 rich: it offers graded services over resources whose scarcity and price move in real time. The missing element is not knowledge on either side but a means of conducting the exchange between them automatically and continuously. 4. Problem Statement: Intent Does Not Cross the Boundary Closed-loop automation already lives inside the operator, and intent already lives inside the consumer; standards exist on both sides. The gap is the customer-operator boundary itself. Today that boundary is crossed by a human: a person reads the consumer's need, translates it into an order, and waits while the order traverses business and operations support systems. The crossing is slow, measured in days to weeks; it is one-directional, with no counter- offer and no scarcity-aware quote; it is one-shot, with no automatic in-life change as conditions evolve; and its product - the signed contract - is opaque to the consumer's own agents, which cannot reason about an obligation they cannot read. The direction explored in this document is whether the two sides, each represented by a cognitive agent, can conduct that crossing between themselves: declaring intent, returning a scarcity-aware quote, exchanging counter-offers, signing a machine-readable agreement, and renegotiating it in flight when conditions change - calling on a human only where the agents cannot proceed. The remainder of the document describes an architecture for doing so and the standards on which it rests. 5. An End-to-End Agentic Negotiation Architecture 5.1. Three Domains and a Negotiation Plane The architecture organises the negotiation across three interoperating domains, joined by a negotiation plane that is additive: it sits above whatever orchestration the operator already runs and wraps it through typed tool interfaces, taking no hard runtime dependency. The Enterprise domain is the intent owner. It acts as the intent wallet for network services: it detects application demand, expresses it as intent, and authorises spend within a signed policy envelope. The Business Support System (BSS) domain is the business broker. It verifies authorization, prices the catalog against live scarcity, signs agreements and drives renegotiation, translating operational reality into commercial offers and counter-offers. The Operations Support System (OSS) domain is the intent handler and executor - the existing closed-loop platform, now wrapped in an agentic layer - which plans and provisions the service across its segments and then assures the live agreement. Figure 1 sketches the arrangement. Janz, et al. Expires 10 December 2026 [Page 6] Internet-Draft NaaS Agentic Negotiation June 2026 CONSUMER SIDE | OPERATOR SIDE | +----------------+ | +----------------+ +----------------+ | Enterprise | | | BSS | | OSS | | intent owner | | | business broker| | intent handler | | (agentic |<===|==>| (verify, price,|==>| (plan, provision| | wallet) | A2A | sign, reneg.) | | assure) | +----------------+ | +----------------+ +-------+--------+ | | | negotiation plane | wraps | (additive, no hard runtime v existing | dependency) orchestration Figure 1: The negotiation plane across three domains. 5.2. Cooperating Agents with Single Responsibilities Within the three domains the negotiation is carried by a small set of cooperating agents, each with a single, auditable responsibility, and every state change flows through a typed tool rather than through free text. The arrangement described by the authors uses seven. On the Enterprise side, a requirement agent translates application telemetry into a service intent, and a policy agent holds the intent wallet, attaches it to every intent, debits on acceptance, and decides on counter-offers within signed guardrails. On the BSS side, a policy agent verifies the wallet end-to-end - signature, expiry, revocation, holder and policy fit - before any token is spent, and a negotiation agent returns scarcity-aware quotes, signs agreements, emits orders and runs the renegotiation strategy. On the OSS side, a negotiation agent validates the order and hands off across a deliberately thin BSS-OSS interface, a planning agent provisions the service across access, transport and optical segments, and an assurance agent runs a per-agreement state machine over telemetry and forecast, emitting predicted-breach and recovery events. The decomposition is illustrative rather than prescriptive; what matters is that responsibilities are separated, that each state-changing action is attributable to a single agent, and that the two sides are peers conducting a dialogue rather than a client driving a server. 5.3. Four Well-Defined Seams The plane is bound together by four kinds of interface, and a single principle governs all of them: the language model supplies judgement, but every state-changing action flows through a typed call, never through the prompt. Agent-to-agent exchange across organisational domains - intents, quotes, agreements, counter-offers, and the wallet credential - travels over an agent-to-agent protocol [TMF-A2A] [LF-A2A]. Agent-to-tool exchange within a single trust domain - Janz, et al. Expires 10 December 2026 [Page 7] Internet-Draft NaaS Agentic Negotiation June 2026 price, sign, debit, provision, migrate, revoke - travels over a typed tool protocol [MCP]; this is the state-mutation boundary. Events fan out over a publish/subscribe fabric, so that downstream agents derive their own state by subscribing rather than polling. A live event feed drives operator and consumer dashboards from the same stream that drives audit and replay. Because every mutation is a typed, published event, the negotiation is auditable and replayable by construction. 5.4. The Intent Wallet and a Bounded Model Authorization in the architecture is a signed object, and judgement is bounded by deterministic rules. The intent wallet is realised as a verifiable credential [W3C-VC]: a signed, auditable statement that a given agent may commit up to some amount, for workloads of some class, with some service-level floor, within some time window. It rides with every intent as a message part, so that trust travels with the request; the operator verifies it before any quoting effort is spent, and debits are gated against a cumulative ledger so that they survive re-issue. The credential is the cryptographic container for the consumer's business logic - for example, raising the ceiling for a revenue-critical workload class while another class is held down. The language model contributes judgement in the grey area: narrating a quote, choosing among acceptable items, accepting or rejecting a counter-offer with awareness of workload class. Deterministic checks enforce a safety floor around it - wallet verification, the debit gate, a capacity-locked filter, a service-level-honour check, a strategy chooser. Even if the model errs it cannot move outside the envelope: a bad wallet is refused, an unaffordable offer rejected, a service-level-breaking step-down blocked. Where no model is available, the rules drive every decision and the system still runs. This containment is a property the authors consider essential to deploying cognitive agents in an operational role, and it is revisited in Section 11. 6. Intent-Instance Life-Cycle Management 6.1. The Intent Instance as a Live Object When an intent is accepted it becomes an intent instance: not a document but a managed object with state, governed across its life. The object is negotiated, fulfilled and then continuously assured, with a closed loop choreographing the transitions. Most in-life changes modify the live service in place - the service identifier and the consumer's flow label persist while bandwidth, latency or protection adjust under traffic - and a replacement service, with a new label and a make-before-break migration, is reserved for the case Janz, et al. Expires 10 December 2026 [Page 8] Internet-Draft NaaS Agentic Negotiation June 2026 where in-place modification cannot meet the new objective. Figure 2 names the states. Declared --> Negotiated --> Agreed --> Provisioned --> Assured | (predicted breach / recovery) | v Restored <----- Renegotiated <-------------- (at-risk / cooling) | v Terminated Figure 2: The intent instance as a managed object with state. 6.2. End-to-End Negotiation Flow A single intent traverses the plane as a sequence of typed, auditable transitions, each measured in seconds rather than days. The requirement agent emits an intent and the enterprise policy agent attaches the wallet. The BSS policy agent verifies the credential end-to-end before any token is spent. The BSS negotiation agent queries scarcity and capacity from the OSS and returns a scarcity- aware quote. The enterprise policy agent picks within budget, guarded by service-level and ceiling rules, and the wallet is debited against the cumulative ledger. The BSS negotiation agent signs an agreement and the tag returns to the consumer; an order is issued, the OSS provisions the service, inventory is recorded, and the service is live. The same sequence, run in reverse from an assurance signal, is what drives renegotiation. 6.3. Scarcity-Driven Pricing Consumers neither see nor control allocation; resource use is rationed economically, through price [ETSI-ZSM-019]. Telemetry becomes a forecast, the forecast maps to a scarcity band, and the band sets the surge baked into the quote - per parameter and per path. A path that is lightly used carries the baseline price; as utilisation rises a modest, then a steep, surge is applied; and a grade whose resource is effectively exhausted is withdrawn until it clears. Because a service is a tuple of bandwidth, latency and availability grades, scarcity bites unevenly across the three axes: a region of the network can have ample raw bandwidth yet be tight specifically on its lowest-latency routes, so the latency grade surges while the bandwidth grade does not. A consumer whose flow can tolerate a longer path avoids the surge by taking one, which in turn relieves contention on the scarce routes for everyone. The accepted and refused price points become an empirical record of the consumer's price sensitivity - itself one of the categories of economic Janz, et al. Expires 10 December 2026 [Page 9] Internet-Draft NaaS Agentic Negotiation June 2026 information the NaaS framework expects a provider to synthesise [ETSI-ZSM-019]. 6.4. Closed-Loop Renegotiation The element the authors consider the operator-grade differentiator is renegotiation of a live, signed agreement in both directions. The assurance agent flags an at-risk agreement from telemetry and forecast. The negotiation agent chooses a strategy by workload class - step up for a service-level-sensitive class, step down for a cost- sensitive one - and computes a counter-offer. The consumer's policy agent clears the wallet and a service-level-honour check, after which the model accepts or rejects; no human is involved. The change is then applied: the live service is modified in place where it can be, or migrated make-before-break where it cannot, with traffic flowing throughout. When the scarcity clears, a post-recovery offer walks the grades back to the cost-optimal point. A single-flight gate prevents flutter-driven duplicate offers, and each reissued agreement carries a linked identifier so that the audit trail joins it to its original. This is what turns a static service-level agreement into a two-directional negotiation: the same external event that makes the consumer want more network also tends to make that network scarcer and dearer, so each side's position moves at once, and it moves through price. 7. Standards Foundations and Mapping The claim that runs through this document is that the architecture is a composition of existing standards into a cross-boundary procedure that each of them, individually, stops at the edge of; no new protocol is invented. This section makes the claim concrete, because it shows that the gap of Section 4 can be closed by arranging published work rather than by chartering new work. The management framework is anchored by the Zero-touch network and Service Management (ZSM) body of work. The ZSM reference architecture [ETSI-ZSM-002] supplies the management domains and the end-to-end service management domain that define the boundaries the agents negotiate across. Intent-driven closed loops [ETSI-ZSM-011] [ETSI-ZSM-016] supply intent negotiation as a structured procedure - proposal, feasibility, counter-offer, acceptance - and the in-life assurance arc realised as renegotiation here. The NaaS framework [ETSI-ZSM-019] supplies identity, variable abstraction and the economic-information model on which scarcity-aware pricing rests; its three pillars - identity management, variable abstraction and economic information - map directly onto, respectively, the wallet holder identity and per-flow label, the intent that hides resources, and the telemetry-to-forecast-to-band pricing loop. The network Janz, et al. Expires 10 December 2026 [Page 10] Internet-Draft NaaS Agentic Negotiation June 2026 digital twin [I-D.irtf-nmrg-ndt] provides a prospective-actuation substrate against which a candidate in-life change may be validated before commitment. The intent body itself reuses established information models [TMF921] [TS28312]. The commercial seam - quote, agreement, order and inventory - reuses a published catalog of open APIs [TMF648] [TMF651] [TMF622] [TMF638], and the closed-loop choreography reuses a published management API [TMF753A]. The provisioning seam reuses transport and slicing models from the IETF and the Broadband Forum [RFC8453] [RFC8299] [TR451]. Authorization reuses verifiable credentials [W3C-VC], and the consumer-facing API profile reuses an open network API [CAMARA-QOD]. The agent and tool wires reuse emerging ecosystem protocols [TMF-A2A] [LF-A2A] [MCP]. Table 1 summarises the mapping; the point of the table is not its individual rows but the absence of any row that requires a new specification. Janz, et al. Expires 10 December 2026 [Page 11] Internet-Draft NaaS Agentic Negotiation June 2026 +===============+==================+============================+ | Concern | Specification | Role in the architecture | +===============+==================+============================+ | Intent body | TMF921 + 3GPP TS | emitted by the requirement | | | 28.312 | agent; carried on A2A | +---------------+------------------+----------------------------+ | Intent | ETSI ZSM 011 / | proposal, feasibility, | | negotiation | 016 | counter-offer, acceptance | +---------------+------------------+----------------------------+ | Quote / | TMF648 | scarcity-aware pricing | | counter-offer | | output; renegotiation body | +---------------+------------------+----------------------------+ | Agreement | TMF651 | signed by BSS; tracked by | | (signed) | | OSS assurance | +---------------+------------------+----------------------------+ | Order | TMF622 | BSS to OSS negotiation | | activation | | | +---------------+------------------+----------------------------+ | Service | TMF638 | OSS planning output | | inventory | | records | +---------------+------------------+----------------------------+ | Closed-loop | TMF753A | breach to counter to | | choreography | | change to recovery | +---------------+------------------+----------------------------+ | NaaS economic | ETSI GR ZSM 019 | scarcity bands; per- | | model | | consumer pricing | +---------------+------------------+----------------------------+ | Management | ETSI ZSM 002 / | domains, intent, closed | | framework | 011 / 016 | loops | +---------------+------------------+----------------------------+ | Prospective | NMRG network | validate candidate change | | actuation | digital twin | before commit | +---------------+------------------+----------------------------+ | Slicing / | IETF ACTN / | provisioning shapes across | | transport | L3SM; BBF TR-451 | segments | +---------------+------------------+----------------------------+ | Authorization | W3C VC; CAMARA | intent wallet; consumer- | | | QoD | facing API | +---------------+------------------+----------------------------+ | Agent / tool | TMF A2A; LF A2A; | all inter-agent and agent- | | wire | MCP | tool calls | +---------------+------------------+----------------------------+ Table 1: Each interface maps to a published specification. Two observations about the table are worth drawing out for a research audience. First, the entries span several organisations - ETSI, TM Forum, 3GPP, the IETF, the Broadband Forum, the W3C, CAMARA and the Janz, et al. Expires 10 December 2026 [Page 12] Internet-Draft NaaS Agentic Negotiation June 2026 Linux Foundation - which is itself the difficulty: each settles its own side of the boundary and none owns the crossing. Second, the newest entries - intent wallets expressed as verifiable credentials, and agent-to-agent and agent-to-tool protocols - are ecosystem concepts still stabilising at the time of writing. The architecture treats them as load-bearing, which means the direction's maturity is bounded by theirs; this is named as a research consideration in Section 9 rather than hidden. 8. Illustrative Use Cases Two NaaS settings illustrate where the architecture of Section 5 is useful. Neither is presented as a worked engineering case; each is a sketch of how the negotiation would be used, offered to show utility rather than to specify an implementation. 8.1. Service Switching Across IP and Optical Networks An operator runs two coexisting networks - a best-effort IP network and a deterministic fine-grain optical transport network. A consumer's demand can be served by either, and the agents negotiate which one carries it, switching the live service between them as scarcity, price and service-level risk evolve. A workload burst triggers an intent for premium transport; the operator quotes both tiers with live scarcity surge applied. Under congestion the deterministic tier surges beyond the consumer's wallet. Rather than fail, the agents reach an autonomous compromise: the workload runs on best-effort IP first, and upgrades to the deterministic optical service once the forecast says the surge has cleared. The switch is made make-before-break, with an overlap window, and the agreement and audit trail follow the service across the network-type boundary. The utility on display is that a demand which could not be satisfied at the requested grade and price is nonetheless satisfied - degraded gracefully and then restored - without a human in the loop. 8.2. Dynamic Performance-on-Demand for Financial Trading A financial-services firm, Enterprise X, runs trading flows that cross equity, currency and commodity exchanges, system to system. Operator Y runs an end-to-end deterministic optical mesh with a point of presence near every exchange and carves deterministic services - each a tuple of bandwidth, latency and availability grades - bound to individual flows. Because trading conditions change continuously, so do the service levels each flow needs; the relationship between X and Y is a standing negotiation between agents. Five flow classes carry the setting - market-data, order-execution (the money path), inter- site risk replication, block synchronisation and bulk transfer - each with a distinct service-level shape. Scarcity arises in two Janz, et al. Expires 10 December 2026 [Page 13] Internet-Draft NaaS Agentic Negotiation June 2026 different places: the firm's own private access spur, which only its traffic contends for and which it resolves by re-prioritising its own flows; and everything inside the operator's shared mesh, where scarcity reflects the aggregate demand of all the operator's customers and the firm can respond only through price. Latency, on a mesh, is an economic choice among paths: the shortest route is the scarcest, so pricing latency steers tolerant flows onto longer paths, spreading load and lowering prices for all. Three short episodes show the negotiation at work. A volatile equity open surges market-data and turns order-execution latency-critical; because the bottleneck is the firm's own private spur, the firm resolves it itself - paying up for the money path under a wallet ceiling it has raised for the day, and dropping a running bulk backup to its lowest grades to free headroom. An energy and metals shock drives a computation across two sites over the operator's shared core, producing one event and two opposite negotiations: the service- level-critical risk-replication flow holds the scarce shortest route and pays, while the latency-tolerant block-synchronisation flow accepts a longer path at a cheaper grade in a quieter window. An unrelated tenant then congests a core path carrying the firm's remote order-execution, and the operator's forecast predicts a breach; the contract is renegotiated in flight - rerouted onto a diverse path and stepped up to hold the latency ceiling, then stepped back down once congestion clears - modified in place while traffic flows. Across the three, the utility is the same: a relationship that behaves like a market nested inside the financial markets that drive it, in which demand is endogenous, scarcity is rationed by price, different flows negotiate differently, and the agreement renegotiates itself. 9. Relationship to NMRG Work and Open Research Questions The direction described here sits squarely within the research group's stated priorities of self-managing networks, intent-based networking, and the coupling of artificial intelligence with network management. It builds directly on the group's concepts of intent [RFC9315], on autonomic and closed-loop foundations [RFC7575], and on the network digital twin as a substrate for validating changes before commitment [I-D.irtf-nmrg-ndt]. It is also a concrete instance of several of the challenges catalogued in the group's work on coupling AI with network management [I-D.irtf-nmrg-ai] - among them the need to bound model behaviour, to keep decisions auditable, and to retain a deterministic fallback. What the present document adds is a specific setting - the customer-operator NaaS boundary - in which intent-based networking, closed-loop assurance and agentic AI are not three separate topics but three aspects of a single negotiation. Janz, et al. Expires 10 December 2026 [Page 14] Internet-Draft NaaS Agentic Negotiation June 2026 The direction raises research questions the authors believe are worth the group's attention: * How should a consumer's willingness to pay be expressed, signed and bounded so that an agent may commit on its behalf without a human in the loop, and how should such an authorization compose when demand is aggregated through several NaaS operators in series? * What guarantees can be made about a negotiation in which a language model supplies judgement, and what is the right division of labour between model and deterministic rule so that the system is safe when the model errs and still runs when no model is present? * How should scarcity-based pricing be designed so that it is incentive-compatible - steering tolerant demand off scarce resources - without exposing allocation, and how is the resulting price-sensitivity record governed as data? * How can the auditability and replayability that follow from an event-sourced negotiation be turned into operator-grade assurance that a contested in-life change was correct? * How stable is a composition that depends on still-emerging ecosystem protocols for its agent and authorization wires, and what is the migration path as those protocols mature? 10. Considerations for Implementation Several considerations should inform any implementation. The negotiation plane SHOULD remain additive, wrapping existing orchestration through typed tools rather than taking a hard runtime dependency that would couple the production path to model-driven decisions; correspondingly, every state-changing action SHOULD flow through a typed tool call rather than through model output, so that what an agent can do is bounded by construction. An authorization that commits spend MUST be verifiable end-to-end before any quoting effort is expended on it, and debits MUST be gated against a ledger that survives re-issue, so that a replayed or reissued agreement cannot double-spend. In-life change SHOULD prefer in-place modification - with replacement and make-before-break migration reserved for cases where in-place change cannot meet the new objective, and the consumer's operational identity persisting across it - and renegotiation SHOULD be protected against oscillation, for example by a single-flight gate and a cooling-down period, with each reissued agreement carrying a linked identifier to its original. Finally, the system SHOULD retain a deterministic fallback that Janz, et al. Expires 10 December 2026 [Page 15] Internet-Draft NaaS Agentic Negotiation June 2026 drives every decision when no model is available, so that availability of the negotiation does not depend on availability of a model. 11. Security Considerations The architecture introduces security considerations beyond those of conventional model-driven ordering. Authorization is the central one. Because a consumer's willingness to pay is expressed as a signed wallet that an agent may spend without a human in the loop, the wallet MUST be verified end-to-end - signature against the issuer identity, expiry, revocation, holder match and policy fit - before any quoting effort is spent, and every debit MUST be gated against a cumulative ledger so that a replayed, reissued or forked agreement cannot exceed the signed envelope. Compromise of a wallet issuing key, or of the ledger, is a high-value target and SHOULD be treated accordingly. The agents are built around language models and inherit the general risks of such systems, including prompt injection, hallucination and miscalibrated confidence. The architecture's principal mitigation is containment: the model supplies judgement, but every state-changing action flows through a typed tool guarded by deterministic checks, so that a model error cannot move the system outside its envelope. Implementations MUST NOT allow model output to effect a state change directly, SHOULD require human review for decisions whose consequences are operationally significant, and SHOULD retain the deterministic fallback described in Section 10. Because the negotiation is event-sourced, every state transition is an auditable, replayable record; this is a security asset, but the event fabric and audit store thereby become sensitive and MUST be protected against tampering and unauthorised disclosure. Finally, the demand-presentation and price-sensitivity data synthesised during negotiation [ETSI-ZSM-019] is commercially sensitive and is attributable to a consumer through its operational identity labels; policy controls MUST govern what may be disclosed, to whom and under what conditions, and per-consumer identity SHOULD use generic operational labels rather than exposing the consumer directly. 12. IANA Considerations This document has no IANA actions. 13. Normative References Janz, et al. Expires 10 December 2026 [Page 16] Internet-Draft NaaS Agentic Negotiation June 2026 [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, . 14. Informative References [RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, . [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8299] Wu, Q., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . [I-D.irtf-nmrg-ndt] Zhou, C., Yu, H., Damas, J., Lopez, D., and L. Contreras, "Network Digital Twin: Concepts and Reference Architecture", Work in Progress, Internet-Draft, draft- irtf-nmrg-network-digital-twin-arch, February 2026, . [I-D.irtf-nmrg-ai] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Research Challenges in Coupling Artificial Intelligence and Network Management", Work in Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges, 2025, . Janz, et al. Expires 10 December 2026 [Page 17] Internet-Draft NaaS Agentic Negotiation June 2026 [ETSI-ZSM-002] ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Reference Architecture", ETSI GS ZSM 002, 2019. [ETSI-ZSM-011] ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Intent-driven autonomous networks; Generic aspects", ETSI GS ZSM 011, 2023. [ETSI-ZSM-016] ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Intent-driven closed loops", ETSI GS ZSM 016, 2024. [ETSI-ZSM-019] ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); ZSM Framework for NaaS", ETSI GR ZSM 019 V1.1.1, January 2026. [TS28312] 3GPP, "Management and orchestration; Intent driven management services for mobile networks", 3GPP TS 28.312, 2024. [TMF921] TM Forum, "Intent Management API Profile", TM Forum TMF921, 2024. [TMF648] TM Forum, "Quote Management API", TM Forum TMF648, 2023. [TMF651] TM Forum, "Agreement Management API", TM Forum TMF651, 2023. [TMF622] TM Forum, "Product Ordering Management API", TM Forum TMF622, 2023. [TMF638] TM Forum, "Service Inventory Management API", TM Forum TMF638, 2023. [TMF753A] TM Forum, "Closed Loop Management API", TM Forum TMF753A, 2024. [TMF-A2A] TM Forum, "Agent-to-Agent (A2A) for Telco; TM Forum profile", TM Forum, work in progress, 2025. [LF-A2A] Linux Foundation, "Agent2Agent (A2A) Protocol", 2025, . [MCP] Anthropic, "Model Context Protocol (MCP) Specification", 2025, . Janz, et al. Expires 10 December 2026 [Page 18] Internet-Draft NaaS Agentic Negotiation June 2026 [W3C-VC] W3C, "Verifiable Credentials Data Model v2.0", W3C Recommendation, 2025, . [CAMARA-QOD] CAMARA Project (Linux Foundation), "Quality on Demand (QoD) API", 2025, . [TR451] Broadband Forum, "SDN Management and Control Interfaces for CloudCO Network Functions", Broadband Forum TR-451, 2021. Acknowledgments The authors thank colleagues for discussions that shaped the ideas in this document, and members of the NMRG and the NMOP working group for ongoing exchanges on the role of agentic AI in network and service management. Authors' Addresses Chris Janz Huawei Email: christopher.janz@huawei.com Hesam Rahimi Huawei Email: hesam.rahimi@huawei.com Henry Yu Huawei Email: henry.yu1@huawei.com Janz, et al. Expires 10 December 2026 [Page 19]