Automated Agent-to-Agent Ontology Reconciliation for Cognitive Network Management Systems
draft-janz-nmrg-ontology-reconciliation-01
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 , Henry Yu , Hesam Rahimi , Nigel Davis , Diego Lopez | ||
| Last updated | 2026-07-06 | ||
| 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-ontology-reconciliation-01
Network Management Research Group C. Janz
Internet-Draft H. Yu
Intended status: Informational H. Rahimi
Expires: 7 January 2027 Huawei
N. Davis
Ciena
D. López
Telefónica
6 July 2026
Automated Agent-to-Agent Ontology Reconciliation for Cognitive Network
Management Systems
draft-janz-nmrg-ontology-reconciliation-01
Abstract
This document describes a possible direction for inter-system
communication in network management, in which two cognitive software
agents establish between themselves the basis for exchanging
information, without depending on a single rigid data model agreed by
their implementers in advance. The agents bring relevant knowledge,
can extend it through learning, can reason, and can converse in
natural language. The approach is framed as a workflow in which each
agent makes explicit the ontology implicit in its data model, the two
agents address their differences through conversation, and a
translator artefact is produced that is then used during ordinary
operation. A central property is that language-model inference is
consumed during the agents' conversation rather than on each
subsequent message. The document situates the direction relative to
adjacent work and illustrates it through three use cases drawn from
network management.
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."
Janz, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. A Reconciliation Workflow . . . . . . . . . . . . . . . . . . 5
5.1. The Conversation . . . . . . . . . . . . . . . . . . . . 5
5.2. Kinds of Difference, and Self-Extension . . . . . . . . . 6
5.3. Lift, Mediate, Generate, Validate . . . . . . . . . . . . 7
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Illustrative Use Cases . . . . . . . . . . . . . . . . . . . 11
7.1. A New Source Joining a Knowledge Graph . . . . . . . . . 11
7.2. Two Data Models, Independently Designed . . . . . . . . . 12
7.3. A Punctual Shift in Abstraction . . . . . . . . . . . . . 14
8. Pitfalls and Considerations for Implementation . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Inter-system communication in network management is, today,
predominantly arranged through shared data models: where systems
implement the same model, or compatible profiles of it, the exchange
is straightforward, and where they do not, the integration is
engineered. Engineering the bridge between two data models is a
substantial, recurring cost. Standard models do not anticipate every
measurement source, every vendor extension, every operational
subtlety; new sources need to be integrated as deployments evolve;
occasional transactions need information at an abstraction level
different from that of the ongoing conversation.
Janz, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
The arrival of large language models, together with the broader move
toward agentic software architectures, makes a different option
conceivable. A software system that holds relevant knowledge, can
extend it, can reason, and can converse in natural language is in
principle able to do for itself - in dialogue with a peer that has
the same capabilities - much of the bridging work that integrators do
today. This document explores that direction. It describes a
workflow under which two such systems might construct, between
themselves, a translator that runs deterministically thereafter, and
gives three illustrations of how the workflow might apply in network
management. Pitfalls and considerations for implementation are
collected in Section 8.
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.
Cognitive Agent:
an autonomous software entity built around a Large Language Model
and one or more controlled stores of knowledge, with the ability
to extend its knowledge through learning, to reason about what it
has been presented with, and to communicate in natural language.
Ontology:
an explicit account of what a domain admits as entities,
attributes and relationships, together with the lexicon that names
them. An ontology is a matter of what exists and how it is
related, not of how it is structurally expressed.
Lexicon (Terminology):
the set of terms by which the entities, attributes and
relationships of an ontology are named. The lexicon is part of an
ontology, not a separate layer beneath it.
Concept:
an abstract entity, attribute or relationship within an ontology -
for example an OWL class or object property. A single concept may
be represented by different elements across different data models.
Janz, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
Grammar:
the structural conventions by which admissible expressions in a
representation are formed. A data schema - for example the
structure prescribed by a YANG module - is an instance of grammar.
Element:
a structural, syntactic unit within a specific data model - for
example a particular YANG container, list, or leaf. An element is
the localised, structural unit that carries, or maps to, a
concept.
Data Model:
a syntactic and structural artefact - for example a YANG module or
a JSON Schema - that fixes a grammar and thereby carries an
ontology implicitly through the structures it prescribes.
Ontology Mediation:
the activity of bridging two ontologies so that information
expressed under one is intelligible under the other; comprises
alignment (correspondence discovery), mapping (expressing
correspondences as transformation rules), and potentially merging
(combining two ontologies or adding elements from one ontology to
that of another).
Translator:
executable code or a set of declarative rules applied at the
boundary between two systems that converts instances expressed
under one data model into instances expressed under another;
produced from a mediation and run deterministically thereafter.
Variable Abstraction:
the operational practice of presenting information at the level of
detail appropriate to a particular interaction [ETSI-ZSM-019].
3. Background
Communication between two systems depends on alignment along two
structural dimensions and on the meaning that runs through both. The
first dimension is ontology: what each system admits as entities,
attributes and relationships, together with the lexicon - the
terminology - that names them. The second is grammar: the structural
conventions by which admissible expressions are formed, of which a
data schema is one example. Standard data models are an attempt to
settle these by agreement, in advance of any specific exchange.
Where the agreement is complete, no further work is needed at
exchange time. Where it is not, the residual gaps need to be closed
by other means. Network management offers many reasons why complete
prior agreement is not always available: deployments evolve; vendor
Janz, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
extensions accumulate; different communities settle on different
conventions for the same operational territory.
A further consideration is that the appropriate level of abstraction
depends on the purpose of an exchange. Two systems may communicate
at a high level of abstraction for ordinary purposes and need a more
detailed view for an audit or a diagnostic question. The operational
practice of presenting information at the abstraction appropriate to
a given interaction is known as Variable Abstraction Management
[ETSI-ZSM-019], and it implies that no single fixed model is
uniformly appropriate even between the same two systems.
It is also worth recognising that some differences between ontologies
are not comprehensibly and usefully bridgeable by any amount of
description. Where one party has concepts the other has no basis
for, no quantity of explanation will install them. A workflow of the
kind discussed here MUST be able to acknowledge such a case and
report it, rather than fabricate a correspondence.
4. Problem Statement
Two systems are required to communicate for some purpose, but the
data models they implement do not, between them, cover the matter
unambiguously. Two common situations are: each system implements a
recognisable standard model with partial overlap to the other, or the
relationship between the two models is more ad-hoc. The customary
response - hand-engineered translation logic, often with tool support
- is expensive to produce and expensive to maintain across the
evolution of the models. The direction explored in this document is
whether two systems with the cognitive capabilities described in
Section 2 can construct that translation between themselves, calling
on human expertise only where they cannot make further progress on
their own.
5. A Reconciliation Workflow
5.1. The Conversation
The workflow described here treats reconciliation as an iterative
conversation between two cognitive agents, each acting on behalf of
one of the communicating systems. At each iteration, the agents
attempt to interpret material they have been presented with - a data-
model instance, an ontology fragment, a description in natural
language - against the knowledge each already holds. Where an
interpretation is partial, the agents request and supply further
information; the exchange can take a variety of forms, including
natural-language description, examples and counter-examples,
references to standards or to documentation that both agents can
Janz, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
consult, structural sketches, and questions put to a human expert.
When the two agents have a sufficient working understanding of one
another's representation, each proposes the correspondences it will
use to translate between the two and validates those proposals
against representative cases. Where a translation, once exercised
against later material, exposes a difference that the original
conversation did not anticipate, the agents can return to the
conversation and refine the artefact. In this sense the translator
produced by the workflow is maintained rather than delivered.
Implementations SHOULD make this iteration explicit, both to enable
principled re-engagement and to support audit of the decisions made
during the conversation.
5.2. Kinds of Difference, and Self-Extension
The differences the agents must reconcile are of three kinds, and it
helps to keep them distinct. The first is lexical: the two
ontologies name the same entity, attribute or relationship
differently. Here the resolution is an alignment of terminology - a
dictionary entry between the two names. The second is grammatical:
the two representations express the same content through different
structural conventions, a data schema being the usual example - as
when one model identifies elements through flat identifiers and
another through hierarchical ones, or decomposes the same reality
into different structures. Here the resolution is a structural
mapping between the two grammars. The third, and the most delicate,
is a difference of ontological content: the two ontologies do not
cover the same ground. Such gaps arise in two ways - from
ontological universes that differ, wholly or in part, and from
differences in the detail at which a shared concept is resolved,
including its degree of abstraction. Where one side merely resolves
a shared concept more finely, the resolution is for the finer side to
convey the distinctions the exchange actually needs, and no more;
pursuing distinctions beyond the need is wasted effort.
The hard case is a foreign element for which the receiving side has
no counterpart. Faced with such an element, an agent must first
determine whether it genuinely lacks the corresponding concept within
its own ontology, or merely lacks a term for a concept it already
holds. Where the concept itself is absent, four responses are
available, and they are not equally good. The deficient side may
refuse the concept, which forces the peer to lose information that
may be essential to its purposes. It may apply rule- or policy-based
arbitration - resolving or discarding the concept deterministically
under predefined operational policy, such as a source hierarchy or a
domain precedence. It may escalate to a human, which, if applied to
every such case, undermines the value of automating the workflow in
Janz, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
the first place. Or it may extend its own ontology, auditably, to
generate and host the missing concept, thereby creating an
ontological anchor for the foreign element. This last response,
which this document calls self-extension, is the one a reconciliation
workflow SHOULD prefer where the available descriptions support it;
policy-based arbitration SHOULD be used where clear operational rules
govern the case; and escalation SHOULD be reserved for cases in which
neither description nor policy suffices.
5.3. Lift, Mediate, Generate, Validate
Figure 1 summarises the workflow. Each side begins with its data
model and lifts it - making the ontology the model carries explicit.
The two agents then mediate their differences by the conversational
mechanism of Section 5.1; each side generates the translator that
will run at its boundary; and the generated translator is validated
before it is put into ordinary operation. A useful property of this
arrangement is that the language-model inference - the expensive part
- is invoked during the conversation, not during ordinary message
exchange. The translator runs deterministically thereafter, with the
operational characteristics of conventional interface code. When the
model on either side evolves, or when validation or later operation
exposes instances the translator cannot handle cleanly, the workflow
can be re-entered and the artefact refreshed; implementations SHOULD
provide explicit triggers for this re-entry.
Lifting yields, on each side, only the ontology implicit in a data
model, which is often carried weakly. The work of enriching those
ontologies so that they can be mediated belongs to the conversation
of Section 5.1, which was framed as an exchange of whatever
information modalities help the task. One such modality deserves
particular emphasis, because it does much to facilitate mediation:
the exchange of reference ontologies or, at least, of nomenclatures
or meta-nomenclatures, against which each side can enrich its own
ontological view. Such enrichment can include tagging and mapping
local elements to referenced concepts, and extracting the content
already latent within a model - for example the descriptions and
comments embedded within a YANG module, extracted using natural-
language processing. Enriched in this way, an agent faces its peer
not with a bare lifted schema but with a view whose elements are
already related to common reference points, which materially reduces
the ambiguity the conversation must then resolve. This is a
development of the conversation, not a separate step.
Once a translator has been generated, it SHOULD be validated as
rigorously as practical before it is put into operational use,
because a correspondence faithful in form can still be wrong in the
consuming context. The default method of validation is to send data-
Janz, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
schema instances on translation round trips, in both directions; a
faithful translator reproduces each original instance. Any
ontological or lexical reference, and the host operations systems
themselves, may be drawn on as sources of instance cases and of the
detail needed to exercise the operational state space suitably.
Where validation exposes a defect, it triggers revision of the
translator - a return to the conversation of Section 5.1 - so that
validation forms part of the maintenance loop rather than a one-time
gate.
Janz, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
+-----------------+ +-----------------+
| Data Model A | | Data Model B |
+--------+--------+ +--------+--------+
| |
| lift: make lift: |
| ontology make |
| explicit ontology |
| explicit |
v v
+-----------------+ +-----------------+
| Ontology A | | Ontology B |
+--------+--------+ +--------+--------+
| |
| <-- conversation --> |
| (descriptions, examples, |
| reference nomenclatures or |
| ontologies, tagging and |
| mapping, latent-content |
| extraction, expert input) |
v v
+-----------------------------------------------+
| Agreed correspondences + decision record |
+-----------------------+-----------------------+
|
| generate
v
+-----------------------------------------------+
| Translator A <-> B (deterministic) |
+-----------------------+-----------------------+
|
| validate: round-trip
| instances both ways;
| must reproduce original
v
+-----------------------------------------------+
| Validation |
| - on success: put into operation |
| - on defect: revise translator / |
| re-enter the conversation |
+-----------------------+-----------------------+
|
| on success
v
+-----------------------------------------------+
| Ordinary operation (no further |
| language-model inference per message) |
+-----------------------------------------------+
Janz, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
Figure 1: The reconciliation workflow. Lifting precedes the
conversation; enrichment (including exchange of reference
nomenclatures or ontologies) occurs within it; and the generated
translator is validated by round-trip testing, with defects
returned for revision.
6. Related Work
The workflow described above touches several adjacent lines of
research and engineering. Ontology mediation has a long-standing
literature, with tools such as PROMPT [PROMPT] and MAFRA [MAFRA] and
algorithms such as GLUE [GLUE] and S-Match [SMATCH], evaluated
through the Ontology Alignment Evaluation Initiative [OAEI] using
matchers including LogMap [LOGMAP] and AgreementMakerLight [AML].
This body of work has historically targeted large, published
ontologies (biomedical references most prominently), and it routes
the harder disambiguation decisions to a human reviewer; the present
document is concerned with situations in which the ontologies are
smaller and more locally scoped, and in which the decisions that
classical tools route to a human are instead handled by the cognitive
agents themselves.
Since 2023, large language models have been incorporated into
ontology matchers in several ways - as one-shot oracles on candidate
correspondences [NORO2023] [HE2023], as components inside
conventional pipelines [LLMS4OM] [LLMORACLE], and through generation
of textual definitions that are then embedded and compared [GENOM].
Agent-OM [AGENTOM] arranges the matcher itself as two cooperating
LLM-driven agents, though those agents remain roles within a single
matching system whose inputs and outputs are ontologies and
alignments rather than communicating systems and translators.
The idea of agents negotiating ontologies through dialogue is older
still: Bailin and Truszkowski [BAILIN2001] [BAILIN2002] and van
Diggelen and colleagues [VDIGGELEN] set out the shape of such
negotiation when the cognitive substrate available was much thinner
than today's large-language-model-equipped agents can offer. Two
recent contributions - Gateway-X [GATEWAYX], building on earlier work
[PAHL2014] [VSL2019], and AICEP [AICEP] - place language-model
inference on the runtime data path, translating or grounding on each
call. The workflow described here is not in opposition to either of
those lines; where two large published ontologies must be aligned at
scale, the classical matchers are more apt, and where genuinely
unanticipated instances must be handled at the moment they arrive,
runtime translation is an appropriate complement to a negotiated
translator.
Janz, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
7. Illustrative Use Cases
Three situations from network management practice illustrate where
the workflow of Section 5 might be applied. None of them is
presented as a worked engineering case; each is a sketch of how the
workflow could be used.
7.1. A New Source Joining a Knowledge Graph
A management system that organises its working knowledge as a graph
of entities and relationships needs, from time to time, to integrate
a new source of evidence - a measurement instrument, an analytic
engine, or a derived signal feed - into that graph. Today, such
integrations are typically engineered. The workflow of Section 5
suggests an alternative, in which the new source presents itself in
natural language against a loose convention for describing what an
evidence source has to offer (what is observed, on which entities,
with what triggers, in what units, with what accuracy and how fresh).
A cognitive agent acting on behalf of the management system - here
called the Gateway - interprets that presentation against the current
graph, identifying whether the kind of evidence is one the system
already understands. If it is, the new source is registered as a
further instance of a known kind, and no further interpretive work is
needed. If the kind is new, the Gateway poses clarifying questions
appropriate to what has been advertised, receives natural-language
answers, and commits, in a single atomic step, both the augmentation
of the graph's schema and the registration of the source. An
acknowledgement closes the exchange, and the data subscription
begins.
Two properties of this arrangement are worth noting. First, the
consequential work happens once per kind of evidence, not once per
source: adding a second source of an already-understood kind is a
routine registration, whereas adding the first source of a new kind
requires interpretation. Second, every onboarding leaves an
auditable trace - the presentation, any clarifying exchange, the
schema change committed, and the registration - that can be inspected
after the fact and, if a later observation casts doubt on the
interpretation, revisited.
Figure 2 sketches the message exchange. It is not intended as a
protocol specification.
Janz, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
New source Gateway
| |
| natural-language self-presentation |
|-------------------------------------->|
| |
| (interpret against current graph) |
| |
| clarifying questions (only when |
|<------------------ the kind |
| answers ---- is new) |
|-------------------------------------->|
| |
| (commit: schema augmentation if |
| needed, registration, binding) |
| |
|<------------ acknowledgement ---------|
| |
| data follows |
|-------------------------------------->|
Figure 2: A possible exchange for onboarding a new source.
Clarifying questions are needed only when the kind of evidence is
new.
7.2. Two Data Models, Independently Designed
The second illustration is the more general one. Two systems hold
data models for roughly the same operational territory but designed
independently, and they need to be made to communicate. The workflow
of Section 5 would, in outline, have each agent first make explicit
the ontology carried by its model, then engage in conversation to
address the differences, and finally generate the translator that
runs at its side of the boundary.
To make the discussion concrete, the optical-transport domain offers
two well-known YANG models in this shape: ONF TAPI [TAPI] on one side
and the IETF TEAS family on the other, with [RFC8795] over the
network base [RFC8345], extended for optical transport by
[I-D.ietf-ccamp-otn-topo-yang] and [I-D.ietf-ccamp-layer1-types].
Both describe nodes, links, termination points, layering, switching,
and services, in YANG, but each cuts the same operational reality in
its own way. The TAPI and TEAS models are named here purely for
illustration; the points that follow are intended to apply to two-
data-model reconciliation in general.
Several kinds of difference can be expected to arise. Some are
lexical - the same concept named differently in the two models, often
recognisable as cognates. Some are grammatical - one model naming
Janz, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
elements through flat identifiers, the other through hierarchical
ones - which the workflow can accommodate by recording a bijection
between identity spaces that the translator subsequently applies.
Some are matters of granularity - one model resolving a concept more
finely than the other - which the workflow addresses by having the
finer side convey the distinctions the exchange actually requires.
Of greater interest are differences in how the same reality is
decomposed. In the illustrative pair, TAPI represents the transport
network as one multi-layer topology, with layer information attached
to the termination points; the TEAS family represents the same
reality as separate networks per layer, linked by supporting-network
references. The workflow would, at this point, have to settle a
structural translation that explodes one shape into the other and
collapses back again, with the correspondences checked against worked
instances as they are settled. Such a structural negotiation is the
part of the workflow that would benefit most from explicit human
attention during mediation.
Of greatest interest are differences of ontological scope: elements
that one model represents and the other has no native place for. In
the illustrative pair, IETF's TunnelTerminationPoint and TAPI's
ServiceInterfacePoint are examples of concepts that have no direct
counterpart on the other side. Section 5.2 indicated that the
workflow's preferred response to such cases is self-extension by the
deficient side - extending its own ontology, auditably, to host the
foreign concept - with policy-based arbitration where operational
rules govern the case, and escalation reserved for concepts that no
description can install. Whether a particular case admits self-
extension is a judgement the agents make in the moment, on the basis
of the descriptions available to them; not every concept can be
installed in this way, and the workflow is required to recognise when
it cannot.
Whether reconciliation by this workflow would succeed in any
particular two-model case depends on properties of the models, on the
knowledge the participating agents can bring to bear, and on the
amount and quality of expert attention during mediation. This
document does not claim that every such reconciliation can be
completed without human intervention. Its claim is that the workflow
is a direction worth exploring, that the kinds of difference
encountered are bounded and broadly understood, and that the artefact
produced - a deterministic translator generated once and then run -
has the operational properties an IETF audience would expect of
interface code.
Janz, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
7.3. A Punctual Shift in Abstraction
The third illustration extends the second. Two systems have already
established a working translation at one level of abstraction - say,
intent-based service provisioning, where the consumer states what it
wants and the provider satisfies the intent without exposing the
resources used. On occasion, one side puts a question that the
established translation cannot answer: an audit, for example,
demonstrating that the resources carrying a service lie inside (or
outside) a particular geographic region [ETSI-ZSM-019]. The question
requires information that the established mediation does not
represent.
A punctual application of the same workflow can address the
situation: the agents extend the established vocabulary just far
enough to support the response, produce the response under the
extended vocabulary, and either retire the extension at the close of
the transaction or retain it if further questions of the same kind
are anticipated. In many cases this extension is asymmetric: where
the response is intended for consumption by a human operator on the
requesting side, the requesting system need not extend its own
ontology at all; it receives the response as content, and the human
consumes it directly. The responding system extends, produces, and
then retires (or retains) the extension on its side alone.
8. Pitfalls and Considerations for Implementation
Several considerations should inform any implementation that pursues
the direction described above.
* A correspondence committed with high confidence but incorrect is
more damaging than a flagged uncertainty. Implementations SHOULD
surface uncertainty early and preserve the basis on which a
decision was made, so that later review is possible.
* Agreement on what a term means does not, in itself, settle how the
term is used in operation. Denotation is not behaviour; a
generated translator SHOULD therefore be validated in its
consuming context - by the round-trip testing described in
Section 5.3 - before it is put into service, and any defect
returned for revision.
* Shared reference frames materially ease mediation. A
referenceable ontology is valuable where one exists; but
ontologies are optimised for purpose and none is universal, so an
applicable reference ontology often will not exist. More
practical, and frequently sufficient, are reference lexicons or
nomenclatures - lexical or nomenclatural frameworks that serve as
Janz, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
ontology proxies - whose well-defined entities and entity classes
give agents common points on which to pin elements of their own
ontologies, and so support effective alignment. This suggests
that, in a world of cognitive agents, such consultable references
may be more useful to standardise than complete and fixed data
models.
* The depth of mediation should be governed by the purpose of the
exchange. Pursuing parity for its own sake will spend effort that
the exchange does not need.
* Some differences are not bridgeable by description. The workflow
MUST be capable of recognising and reporting such cases.
* Engagement with human expertise SHOULD be designed - the route to
the expert, the form of the question, the way the answer flows
back into the agents' knowledge. Ad-hoc escalation is unlikely to
age well.
* Every decision committed during a mediation SHOULD be traceable to
the evidence that produced it. Building provenance in from the
start is materially less costly than adding it after operational
stress.
* The workflow assumes both sides are cognitive in the sense of
Section 2. Where one side is a non-cognitive legacy system
emitting only strict instances, the cognitive side has to do the
work unilaterally, drawing what it can from the instances and from
accessible documentation.
9. Security Considerations
The workflow introduces security considerations beyond those of
conventional model-driven exchange. The natural-language
descriptions and worked examples exchanged during mediation are
inputs to the agents' knowledge, and an adversary in a position to
influence those inputs could attempt to mislead the resulting
translator. Implementations SHOULD attach provenance and confidence
to incoming descriptions and SHOULD support revocation of
integrations whose origin is later found untrustworthy. Any decision
that augments the system's effective ontology - onboarding a new
source, accepting a self-extension during mediation, accepting a
punctual extension - MUST be subject to authorisation appropriate to
the operational role of the agent and MUST be auditable after the
fact. Where a mediation involves presenting information at a level
of detail more granular than would ordinarily be exchanged, policy
controls MUST be enforced on what may be disclosed, to whom, and
under what conditions, and anonymised or aggregated forms SHOULD be
Janz, et al. Expires 7 January 2027 [Page 15]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
supported where finer detail cannot be released. The cognitive
agents inherit the general risks of large-language-model-based
systems, including prompt injection, hallucination, and miscalibrated
confidence; implementations SHOULD apply the usual mitigations and
require human review for decisions whose consequences are
operationally significant.
10. IANA Considerations
This document has no IANA actions.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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>.
12. Informative References
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[I-D.ietf-ccamp-otn-topo-yang]
Busi, I., Belotti, S., Lopez Alvarez, V., Sharma, A., and
Y. Shi, "A YANG Data Model for Optical Transport Network
Topology", Work in Progress, Internet-Draft, draft-ietf-
ccamp-otn-topo-yang,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
otn-topo-yang>.
Janz, et al. Expires 7 January 2027 [Page 16]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
[I-D.ietf-ccamp-layer1-types]
Zheng, H., Lee, Y., Guo, A., Lopez Alvarez, V., and D.
King, "A YANG Data Model for Layer 1 Types", Work in
Progress, Internet-Draft, draft-ietf-ccamp-layer1-types,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
layer1-types>.
[TAPI] Open Networking Foundation (ONF), "Transport API (TAPI) -
tapi-topology and tapi-connectivity YANG modules", ONF/
OTCC specifications, 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.
[PROMPT] Noy, N. F. and M. A. Musen, "The PROMPT Suite: Interactive
Tools for Ontology Merging and Mapping", International
Journal of Human-Computer Studies, Vol. 59, No. 6, pp.
983-1024, 2003.
[MAFRA] Maedche, A., Motik, B., Silva, N., and R. Volz, "MAFRA - A
MApping FRAmework for Distributed Ontologies", EKAW 2002,
LNCS 2473, pp. 235-250, 2002.
[GLUE] Doan, A., Madhavan, J., Domingos, P., and A. Halevy,
"Learning to Map between Ontologies on the Semantic Web",
VLDB Journal, 2003.
[SMATCH] Giunchiglia, F., Shvaiko, P., and M. Yatskevich, "S-Match:
An Algorithm and an Implementation of Semantic Matching",
ESWS 2004, 2004.
[LOGMAP] Jimenez-Ruiz, E. and B. Cuenca Grau, "LogMap: Logic-based
and Scalable Ontology Matching", ISWC 2011, 2011.
[AML] Faria, D., Pesquita, C., Santos, E., Palmonari, M., Cruz,
I. F., and F. M. Couto, "The AgreementMakerLight Ontology
Matching System", OTM Conferences, 2013, 2013.
[OAEI] Ontology Alignment Evaluation Initiative, "Results of the
OAEI 2025 Campaign", CEUR-WS Vol. 4144, 2025.
[NORO2023] Norouzi, S. S., Mahdavinejad, M. S., and P. Hitzler,
"Conversational Ontology Alignment with ChatGPT", Ontology
Matching Workshop, ISWC 2023, arXiv:2308.09217, 2023.
Janz, et al. Expires 7 January 2027 [Page 17]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
[HE2023] He, Y., Chen, J., Dong, H., and I. Horrocks, "Exploring
Large Language Models for Ontology Alignment",
arXiv:2309.07172, 2023.
[LLMS4OM] Giglou, H. B., D'Souza, J., and S. Auer, "LLMs4OM:
Matching Ontologies with Large Language Models",
arXiv:2404.10317, 2024.
[LLMORACLE]
(authors not listed), "Large Language Models as Oracles
for Ontology Alignment", arXiv:2508.08500, 2025.
[GENOM] GenOM Team, "GenOM: Ontology Matching with Description
Generation and Large Language Models", World Wide Web
journal, arXiv:2508.10703, 2026.
[AGENTOM] Qiang, Z., Wang, W., and K. Taylor, "Agent-OM: Leveraging
LLM Agents for Ontology Matching", Proceedings of the VLDB
Endowment, Vol. 18, No. 3, pp. 516-529, 2024.
[BAILIN2001]
Bailin, S. C. and W. Truszkowski, "Ontology Negotiation
between Scientific Archives", NASA Technical Reports
Server, 2001.
[BAILIN2002]
Bailin, S. C. and W. Truszkowski, "Ontology Negotiation
between Intelligent Information Agents", The Knowledge
Engineering Review, Vol. 17, No. 1, pp. 7-19, 2002.
[VDIGGELEN]
van Diggelen, J., Beun, R.-J., Dignum, F., van Eijk, R.
M., and J.-J. Meyer, "Ontology Negotiation: Goals,
Requirements and Implementation", International Journal of
Agent-Oriented Software Engineering, Vol. 1, No. 1, pp.
63-90, 2007.
[PAHL2014] Pahl, M.-O. and G. Carle, "Crowdsourced Context-Modeling
as Key to Future Smart Spaces", IEEE/IFIP NOMS 2014, 2014.
[VSL2019] Pahl, M.-O., Liebald, S., and C. Luebben, "VSL: A Data-
Centric Internet of Things Overlay", NetSys 2019, 2019.
[GATEWAYX] Luebben, C. and M.-O. Pahl, "Gateway-X: LLM-based
Autonomous Adaptive Semantic and Syntactic Protocol
Translation", AIMLOps Workshop, IEEE/IFIP NOMS 2026, 2026.
Janz, et al. Expires 7 January 2027 [Page 18]
Internet-Draft Agent-to-Agent Ontology Reconciliation July 2026
[AICEP] Kukkalli, H., "AICEP: A Standardless, AI-native Control
Plane for Network Management", IEEE/IFIP NOMS 2026,
Technische Universitaet Chemnitz, 2026.
Acknowledgments
The authors thank colleagues for discussions that shaped the ideas in
this document, and members of the NMRG and NMOP for ongoing exchanges
on the role of agentic AI in network management. The authors are
grateful to Brad Peters for detailed comments and suggestions.
Authors' Addresses
Chris Janz
Huawei
Email: christopher.janz@huawei.com
Henry Yu
Huawei
Email: henry.yu1@huawei.com
Hesam Rahimi
Huawei
Email: hesam.rahimi@huawei.com
Nigel Davis
Ciena
Email: ndavis@ciena.com
Diego López
Telefónica
Email: diego.r.lopez@telefonica.com
Janz, et al. Expires 7 January 2027 [Page 19]