Automated Agent-to-Agent Ontology Reconciliation for Cognitive Network Management Systems
draft-janz-nmrg-ontology-reconciliation-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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Christopher Janz , Henry Yu , Hesam Rahimi , Nigel Davis , Diego Lopez | ||
| Last updated | 2026-06-10 | ||
| RFC stream | (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-00
Network Management Research Group C. Janz
Internet-Draft H. Yu
Intended status: Informational H. Rahimi
Expires: 12 December 2026 Huawei
N. Davis
Ciena
D. López
Telefónica
10 June 2026
Automated Agent-to-Agent Ontology Reconciliation for Cognitive Network
Management Systems
draft-janz-nmrg-ontology-reconciliation-00
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 12 December 2026 [Page 1]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
This Internet-Draft will expire on 12 December 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. 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 . . . . . . . . . . . . . . . . . 6
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Illustrative Use Cases . . . . . . . . . . . . . . . . . . . 8
7.1. A New Source Joining a Knowledge Graph . . . . . . . . . 8
7.2. Two Data Models, Independently Designed . . . . . . . . . 10
7.3. A Punctual Shift in Abstraction . . . . . . . . . . . . . 11
8. Pitfalls and Considerations for Implementation . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . 13
12. Informative References . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
Janz, et al. Expires 12 December 2026 [Page 2]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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.
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 and of the
relationships among them.
Data Model:
a syntactic and structural artefact - for example a YANG module or
a JSON Schema - that 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 merging (combining
two ontologies into one, where appropriate).
Janz, et al. Expires 12 December 2026 [Page 3]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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 three things being
sufficiently aligned: the ontologies that determine what each can
talk about, the semantics that govern what particular utterances
mean, and the syntactic conventions that govern how those utterances
are expressed. Standard data models are an attempt to settle all
three 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 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 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.
Janz, et al. Expires 12 December 2026 [Page 4]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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. The common situations are two: 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
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.
Janz, et al. Expires 12 December 2026 [Page 5]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
5.2. Kinds of Difference, and Self-Extension
Differences encountered between two ontologies fall into three
textures that admit different treatments. Where both parties
recognise a concept but name it differently, the resolution is a
dictionary entry between the two names. Where both parties recognise
a concept but one represents it more finely than the other, the
resolution is for the finer party to convey the distinctions the
exchange actually needs; pursuing distinctions beyond what the
exchange needs is wasted effort. Where one party has an element with
no counterpart on the other side, the treatment is more delicate.
Three responses are available, and they are not equally good. The
deficient side may refuse to accept the concept, which forces the
peer to lose information that may be essential to its purposes. It
may escalate to a human, which - if applied to every such case -
undermines the value of automating the workflow in the first place.
Or it may extend its own ontology, auditably, to host the foreign
concept. This last option, which this document refers to as self-
extension, is the response a reconciliation workflow SHOULD prefer
where the available descriptions support it, with escalation reserved
for cases in which no description suffices.
5.3. Lift, Mediate, Generate
Figure 1 summarises the workflow. Each side begins with its data
model and makes the ontology that the model carries explicit; the two
agents mediate the differences by the conversational mechanism of
Section 5.1; and each side then generates the translator that will be
used during 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 the translator begins to
encounter instances it cannot handle cleanly, the workflow can be re-
entered and the artefact refreshed; implementations SHOULD provide
explicit triggers for this re-entry.
Janz, et al. Expires 12 December 2026 [Page 6]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
+-----------------+ +-----------------+
| Data Model A | | Data Model B |
+--------+--------+ +--------+--------+
| |
| make ontology make |
| explicit ontology |
| explicit |
v v
+-----------------+ +-----------------+
| Ontology A | | Ontology B |
+--------+--------+ +--------+--------+
| |
| <-- conversation --> |
| (description, examples, |
| references, expert input) |
v v
+-----------------------------------------------+
| Agreed correspondences + decision record |
+-----------------------+-----------------------+
|
| generate
v
+-----------------------------------------------+
| Translator A <-> B (deterministic) |
+-----------------------+-----------------------+
|
v
+-----------------------------------------------+
| Ordinary operation (no further |
| language-model inference per message) |
+-----------------------------------------------+
Figure 1: The reconciliation workflow.
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
Janz, et al. Expires 12 December 2026 [Page 7]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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.
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
Janz, et al. Expires 12 December 2026 [Page 8]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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.
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.
Janz, et al. Expires 12 December 2026 [Page 9]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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
matters of terminology - the same concept named differently in the
two models, often recognisable as cognates. Some are matters of
identity - one model naming 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 validated against
worked instances before the translator is generated. 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 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
Janz, et al. Expires 12 December 2026 [Page 10]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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 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.
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.
Janz, et al. Expires 12 December 2026 [Page 11]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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. Implementations SHOULD consider
behaviour in addition to denotation, and validation SHOULD include
exercise of the translated message in its consuming context.
* 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
Janz, et al. Expires 12 December 2026 [Page 12]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
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
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>.
Janz, et al. Expires 12 December 2026 [Page 13]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
[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>.
[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.
Janz, et al. Expires 12 December 2026 [Page 14]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
[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.
[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.
Janz, et al. Expires 12 December 2026 [Page 15]
Internet-Draft Agent-to-Agent Ontology Reconciliation June 2026
[VSL2019] Pahl, M.-O., Liebald, S., and C. Lübben, "VSL: A Data-
Centric Internet of Things Overlay", NetSys 2019, 2019.
[GATEWAYX] Lübben, C. and M.-O. Pahl, "Gateway-X: LLM-based
Autonomous Adaptive Semantic and Syntactic Protocol
Translation", AIMLOps Workshop, IEEE/IFIP NOMS 2026, 2026.
[AICEP] Kukkalli, H., "AICEP: A Standardless, AI-native Control
Plane for Network Management", IEEE/IFIP NOMS 2026,
Technische Universität 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.
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 12 December 2026 [Page 16]