Dynamic Network-as-a-Service Life-Cycle Automation Using End-to-End Agent Negotiation
draft-janz-nmrg-naas-agentic-negotiation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Christopher Janz , Hesam Rahimi , Henry Yu | ||
| Last updated | 2026-06-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-janz-nmrg-naas-agentic-negotiation-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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, <https://www.rfc-editor.org/info/rfc9315>.
[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,
<https://www.rfc-editor.org/info/rfc7575>.
[RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[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,
<https://www.rfc-editor.org/info/rfc8299>.
[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,
<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
network-digital-twin-arch>.
[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,
<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ai-
challenges>.
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,
<https://a2a-protocol.org/>.
[MCP] Anthropic, "Model Context Protocol (MCP) Specification",
2025, <https://modelcontextprotocol.io/>.
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,
<https://www.w3.org/TR/vc-data-model-2.0/>.
[CAMARA-QOD]
CAMARA Project (Linux Foundation), "Quality on Demand
(QoD) API", 2025, <https://camaraproject.org/>.
[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]