<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info"
     docName="draft-janz-nmrg-reference-lexicons-00"
     ipr="trust200902"
     submissionType="IRTF"
     consensus="false"
     version="3"
     xml:lang="en">

  <front>
    <title abbrev="Reference Lexicons for Reconciliation">Shared Reference Lexicons for Agent-to-Agent Model Reconciliation in Network Management</title>
    <seriesInfo name="Internet-Draft" value="draft-janz-nmrg-reference-lexicons-00"/>

    <author fullname="Chris Janz" initials="C." surname="Janz">
      <organization>Huawei</organization>
      <address>
        <email>christopher.janz@huawei.com</email>
      </address>
    </author>

    <author fullname="Brad Peters" initials="B." surname="Peters">
      <organization>NBN</organization>
      <address>
        <email>bradpeters@nbnco.com.au</email>
      </address>
    </author>

    <date year="2026" month="July" day="19"/>

    <workgroup>Network Management Research Group</workgroup>
    <keyword>ontology</keyword>
    <keyword>interoperability</keyword>
    <keyword>reference lexicon</keyword>
    <keyword>cognitive agent</keyword>
    <keyword>data model</keyword>

    <abstract>
      <t>Interoperability between network-management systems is customarily arranged by agreeing a shared data model in advance or, where that falls short, a richer shared information model or ontology; both still require broad prior agreement on a common model. This document, a companion to and enhancement of draft-janz-nmrg-ontology-reconciliation, argues that for systems built as cognitive, language-capable agents the shared reference can instead be a thin reference lexicon: a consultable nomenclature of named entities with disambiguating definitions and examples, free of relationship axioms and attribute schemas, and typically derived from an existing model. Each agent brings the lexicon apt to it; the two are lexically aligned into cross-source correspondences; identity is settled wherever they correspond; and only the residual is reconciled by the conversation of the companion document. The document develops what such a lexicon should contain, the two-stage alignment that relates lexicons across sources, the distinct problem of co-referencing specific instances, and the scaling that follows from anchoring translation on shared references; and it recommends how model authors can make their artefacts more amenable to this automated alignment.</t>
    </abstract>
  </front>

  <middle>

    <!-- ================= 1. INTRODUCTION ================= -->
    <section anchor="intro"><name>Introduction</name>
      <t>Two network-management systems interoperate only to the extent that they agree on what the information passing between them means and how it is structured. The customary way to secure that agreement is a shared data model settled in advance. Where a shared model is not available, a common response is to seek agreement one level up, on a richer shared information model or reference ontology sitting above the data models. An ontology is more extensible and less brittle than a fixed schema, and makes meaning explicit - but it does not remove the underlying requirement: such a model must still be broad enough to span the territory, deep enough to be useful, and agreed and maintained among the parties in advance. In network management that broad prior agreement is as often absent than present: standard models cover what their authors anticipated, several bodies model the same territory on their own cycles, and the detail appropriate to an exchange depends on its purpose <xref target="ETSI-ZSM-019"/>.</t>

      <t>Cognitive, language-capable agents make another course possible. A system that can reason over knowledge it holds and extends, and hold a conversation in natural language, can do much of the bridging that human integrators perform today, working it out in dialogue with a peer of like capability. The companion document <xref target="I-D.janz-nmrg-ontology-reconciliation"/> sets out that course as a workflow: two agents make the ontologies implicit in their data models explicit (lift), work through their differences by conversation, and emit a deterministic translator that runs thereafter with no further model inference. This document is a companion to and an enhancement of that one. It supplies and develops one element on which that workflow turns but which it does not itself settle: the details of the conversation, including the nature of any usefully exchanged references the agents consult. The argument is that such references should be thin <em>lexicons</em> rather than ontologies; that each agent brings the references apt to it and they are aligned rather than assumed common; that anchoring translation on shared references rather than on the peer is what lets the arrangement scale; and that co-referencing the specific instances two systems exchange is a distinct step that must be treated as such.</t>

      <t>The reader is assumed familiar with the companion document. To keep this one focused, it relies on that document for lifting, the conversational reconciliation mechanism, round-trip validation, the maintenance loop, and the security considerations they carry, rather than repeating them; and it concentrates on the reference layer and on how the workflow uses it. The mechanisms here are meant to span a wide range with one shape, from models of the same essential scope that differ only in nomenclature or detail, where reference correspondence settles almost everything, to models built over considerably different ontological spaces, where the conversation does much more - up to constructing a mutually workable representation where no direct correspondence exists. What changes across that range is only how much falls to conversation, not the shape of the workflow.</t>
    </section>

    <!-- ================= 2. CONVENTIONS ================= -->
    <section anchor="conventions"><name>Conventions and Definitions</name>
      <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

      <t>The terms Cognitive Agent, Ontology, Lifting, Data Model, Ontology Mediation, and Translator are used as defined in <xref target="I-D.janz-nmrg-ontology-reconciliation"/> and are not redefined here. This document relies in addition on the following.</t>

      <dl newline="false" spacing="normal">
        <dt>Reference Ontology:</dt>
        <dd>an ontology intended to be shared across systems as a fixed point of agreement, typically rich and axiomatised, so that local ontologies committing to it inherit compatible relationships and constraints.</dd>

        <dt>Reference Lexicon:</dt>
        <dd>a consultable nomenclature of reference entities that systems consult as shared anchors, in practice most often derived from an existing model or standard. Each entry fixes identity only: a stable identifier, a preferred name and synonyms, a disambiguating textual definition, a shallow entity class, and a canonical example. A reference lexicon deliberately carries no relationship axioms, cardinalities, or attribute schemas. It is the central object of this document.</dd>

        <dt>Binding (Anchoring):</dt>
        <dd>the act by which an agent identifies an entity of its own lifted ontology with an entry in a reference lexicon apt to it, recording the evidence and a confidence. Where the lexicon is derived from the agent's own model, binding is largely unambiguous.</dd>

        <dt>Reference Alignment:</dt>
        <dd>the act of relating the entries of one reference lexicon to those of another, across sources, yielding cross-source mappings (correspondences) each carrying a confidence. It is distinct from Binding, and is where cross-vocabulary false cognates are caught and where the residual matching error concentrates.</dd>

        <dt>Reference Space:</dt>
        <dd>the whole formed by one or more reference lexicons together with the cross-source mappings that relate their entries; the consultable frame over which identity is settled.</dd>

        <dt>Instance Co-reference:</dt>
        <dd>the act of deciding that two specific data instances denote the same individual in the world (the same physical node, port, or service). It is distinct from, and runs over, the type-level correspondence established by binding and alignment.</dd>
      </dl>
    </section>

    <!-- ================= 3. THE REFERENCE LEXICON ================= -->
    <section anchor="lexicon"><name>The Reference Lexicon</name>

      <section anchor="lexicon-levels"><name>Three levels, and where agreement is proposed</name>
        <t>It helps to separate three things the word "model" conflates. There is the <em>data model</em>: a grammar, such as a YANG module, carrying an ontology implicitly. There is the <em>ontology</em> or information model: what entities exist, how they relate, what attributes they bear <xref target="RFC3444"/>. And there is a <em>reference lexicon</em>: not a model of the domain at all, but a shared naming frame - a set of reference entities, each with a stable identifier and a disambiguating definition, against which independently built ontologies can each declare "my X is that one".</t>
        <t>The shared-model instinct seeks agreement at the first or second level; this document proposes the third. A full shared ontology is deep and broad, which is why it is hard to achieve; bespoke bilateral translation is deep and narrow, so it does not scale; a reference lexicon is broad but deliberately shallow, fixing identity for many entities and axioms for none. The wager is that shallowness is now affordable, because cognitive agents can supply the missing depth per exchange, from definitions and worked instances rather than a pre-agreed axiomatisation.</t>
      </section>

      <section anchor="lexicon-entry"><name>What an entry contains, and where it comes from</name>
        <t>A reference lexicon entry fixes identity and nothing more. Modelled on the W3C Simple Knowledge Organization System (SKOS) <xref target="SKOS"/> - the closest existing standard to what is proposed - each entry carries a stable identifier, a preferred name and synonyms, a disambiguating definition with scope notes, a canonical example, and a shallow entity class (node-like, termination-point-like, link, service, constraint, and so on) rather than a full type hierarchy; and entries carry weak cross-source mappings to entries in other lexicons. It omits relationship axioms, cardinalities and attribute schemas; those are properties of each agent's own lifted ontology, not of the shared reference.</t>
        <t>The canonical example is called out deliberately. In practice it often carries more disambiguating weight than the prose definition: it is a worked instance that settles what a terse or reused description leaves open, and it is frequently what distinguishes two near-neighbours whose definitions read alike. Precisely which elements an entry must carry to support automated use well is not yet settled; determining that "right information" is itself part of the work this document begins, and it motivates the recommendations of <xref target="recs"/>.</t>
        <t>A reference lexicon is, in the common case, <em>derived from</em> an existing model or standard - its named entities lifted into entries with definitions and examples - so it does not introduce a new kind of artefact so much as lift a feature models already carry: a YANG module attaches a "description" to essentially every node <xref target="RFC7950"/>, and RDF or OWL ontologies carry labels and definitions. Two consequences follow, and they separate two relatings that are easy to conflate. Binding an agent's own model to a lexicon derived from that same model is largely unambiguous, close to identity - the easy relating. Relating one source's lexicon to another's, Reference Alignment, is the work, because the two were authored independently and their vocabularies genuinely differ. The companion document draws the same distinction between binding a model to its reference and relating references to one another; this document develops the reference layer on which that distinction rests.</t>
      </section>

      <section anchor="lexicon-suffices"><name>Why a thin, lexical reference suffices</name>
        <t>That a shallow reference suffices rests on a robust pattern from ontology matching <xref target="OM-BOOK"/>, whose entire concern is aligning independently authored ontologies. The most successful matchers derive their candidate correspondences primarily from labels, synonyms and external lexical resources, and use structure and logic mainly to verify and prune <xref target="LOGMAP"/> <xref target="AML"/>; a survey of background knowledge in matching reports that the reference resource that works in practice is lightweight and lexical, and can be composed from several sources rather than drawn from one monolithic reference <xref target="PORTISCH"/> <xref target="SABOU"/>. Language-model-based matchers point the same way, matching predominantly on labels and textual definitions and generating a definition to match on where one is missing <xref target="AGENTOM"/> <xref target="LLMS4OM"/> <xref target="GENOM"/>. The two-stage shape of these matchers - cheap lexical candidates, then verification from definitions and examples - is precisely the shape of the alignment step of <xref target="wf-align"/>, and it locates the dominant error not in a model's near-identity binding to its own reference but in cross-vocabulary matching. The division of labour also has history: early agent communication assumed a shared ontology named in every message, and the fragility of that assumption motivated ontology-negotiation work which found that independently built agents need only a minimal, effective common grounding established at runtime <xref target="BAILIN"/> <xref target="VANDIGGELEN"/>. A reference lexicon is that grounding made durable and consultable.</t>
        <t>The pattern is, if anything, closer to established IETF practice than the full-ontology alternative. The IETF's standard extensibility mechanism is a registry of named entities with textual definitions and designated-expert review <xref target="RFC8126"/>; the IANA interface-type module <xref target="RFC7224"/> is, quite literally, a controlled nomenclature of named entities with descriptions. Standardising a consultable reference lexicon is the same move, inheriting stable identifiers, human-readable definitions, expert curation, and composition by reference rather than merger. The instinct toward a heavier shared semantic layer is nonetheless live in the field, in the research group's own work on agent-to-agent semantics and knowledge graphs over YANG <xref target="I-D.hong-nmrg-agenticai-ps"/> <xref target="I-D.mw-nmop-yang-ai-challenges"/> <xref target="I-D.marcas-nmop-kg-construct"/> and in telecommunications-industry activity on shared information models and intent ontologies <xref target="TMF-SID"/> <xref target="TMF-TIO"/>; a consultable reference lexicon, interpreted at runtime by cognitive agents, is the lighter alternative aimed at the same gap.</t>
      </section>
    </section>

    <!-- ================= 4. THE WORKFLOW ================= -->
    <section anchor="workflow"><name>A Reference-Lexicon-Mediated Reconciliation Workflow</name>
      <t>The proposal is not the references alone but a workflow that uses them, refining the lift-mediate-generate-maintain workflow of <xref target="I-D.janz-nmrg-ontology-reconciliation"/> by making the shared reference explicit, by adding the steps that align references across sources and co-reference instances, and by keeping type-level and instance-level matching distinct. <xref target="fig-workflow"/> summarises the flow. As in the companion document, reasoning is spent during reconciliation, and the artefact produced - a set of translators - runs deterministically thereafter with no per-message model inference.</t>

      <figure anchor="fig-workflow"><name>The reference-lexicon-mediated workflow</name>
        <artwork><![CDATA[
   Agent A                                          Agent B
     |  lift: make own ontology explicit               |  lift
     v                                                 v
  Ontology A                                        Ontology B
     |  bind own entities -> own lexicon               |  bind
     |  (near-identity; lexicon derived from model)    |
     |<====== exchange lexicons, then ALIGN =========>|
     |   label pass, then definition + example,        |
     |   with a confidence (false cognates caught,     |
     |   gaps recorded, correspondences published)     |
                            |
              settle IDENTITY by lexicon correspondence
                  (aligned entries; no conversation)
                            |
              reconcile RESIDUAL by conversation
              (structure / granularity / scope), and
              CO-REFERENCE instances (keys, attributes,
              topology) -- a separate matching problem
                            |
              generate translators keyed on reference
              identity; validate by round-trip both ways
                            |
              ordinary operation / maintain
              (no model inference per message)
]]></artwork>
      </figure>

      <section anchor="wf-bind"><name>Bind local entities to a reference lexicon</name>
        <t>After lifting (as in the companion document), each agent reaches for the lexicon apt to its own case - typically the one derived from its own model or standard - and binds the entities of its lifted ontology to entries in it. Where the lexicon is derived from the agent's own model, the common case, binding is largely unambiguous, close to identity, and needs little more than recording the anchor. Care is needed where it is not: where an agent binds to a lexicon it did not author, or where its own descriptions are sparse, copied, or laden with vendor jargon, so that a name misleads. There, and equally in the cross-lexicon alignment of <xref target="wf-align"/>, matching <bcp14>SHOULD</bcp14> be performed from an entry's definition and a canonical example, not its name, because names are where false cognates live: elements that share a word may denote different concepts, and elements that denote the same concept may be named differently. Where text under-determines the match, the agent <bcp14>SHOULD</bcp14> also weight the structural context of its own lifted ontology - containment, typed references such as leafref and identityref, and the prerequisite hierarchy an element sits within - alongside the definition and example; this structural evidence is the agent's own, and is not required of the reference, which stays identity and definition only. Every binding <bcp14>SHOULD</bcp14> record the reference identifier, local element, evidence and a confidence. Where an agent cannot confidently bind an element, that is a signal - a candidate new entry, a scope gap, or an escalation - and <bcp14>MUST</bcp14> be surfaced rather than forced.</t>
      </section>

      <section anchor="wf-align"><name>Align the reference lexicons</name>
        <t>The lexicons the two agents bring are disclosed and, in the common case, are disjoint to begin with - each authored from a different source. What matters is not that the agents adopt one common lexicon but that theirs can be <em>aligned</em>, related entry to entry by cross-source mappings, so that an entry one side uses can be related to an entry the other uses. Alignment proceeds in two stages, mirroring the practice of ontology matching (<xref target="lexicon-suffices"/>) and specialising the terminology-alignment step of <xref target="I-D.janz-nmrg-ontology-reconciliation"/> to lexicon entries. First, candidate correspondences are proposed cheaply, from preferred names and synonyms alone; this stage is fast and deliberately unconfirmed, and it both over-proposes - raising false cognates, entries that share a word but denote different concepts - and under-proposes, missing correspondences whose entries are named quite differently. Second, each candidate is confirmed or rejected from the entries' definitions and, decisively, their canonical examples, and correspondences the label stage missed are recovered the same way; each resulting mapping carries a confidence. An agent <bcp14>MAY</bcp14> weight structural context to adjudicate a hard case. This is genuine alignment work, but far lighter than aligning models: it relates identity-only entries, not relationships and axioms.</t>
        <t>Perfect alignment would be welcome, but between independently authored vocabularies it is not generally attainable - and the workflow is deliberately built so that it need not be. That is the point of the design: alignment is one step, not the whole of it. The correspondences it settles with confidence pass through to identity (<xref target="wf-identity"/>), while the uncertain, the low-confidence and the missed are not forced but handed to the conversation that follows (<xref target="wf-residual"/>), which is where the residual comprehension gaps are closed. What substance that conversation must carry to close them reliably, and - reciprocally - what a reference lexicon should comprise to leave as little as possible for it, are two questions this line of work is actively exploring. The value of the reference layer is not that its matching is flawless but that it settles cheaply and correctly the large, dull class of identity questions, leaving a smaller, better-characterised residual for dialogue.</t>
        <t>The exchange is explicit for two reasons. Lexicons merely assumed to align are a silent source of misunderstanding - agents whose references are unrelated, or related only by name, mis-reconcile with no local error apparent. And aligning the lexicons produces an auditable record - which entries correspond, at what confidence, on what evidence. Where a needed correspondence is missing, the agents establish it as above and, ideally, contribute it back; the cross-source mappings of the reference space thus accumulate as source-pairs align, so the relating between any two sources is done once and thereafter reused rather than re-derived (<xref target="scaling"/>). Where no apt entry exists on one side for a concept the other carries, that absence is itself a result - a scope gap, recorded and resolved by self-extension (<xref target="wf-residual"/>) or by proposing a new entry.</t>
      </section>

      <section anchor="wf-identity"><name>Settle identity by correspondence</name>
        <t>Where the agents' aligned entries correspond - the same entry, or entries in different lexicons related by a cross-source mapping - the correspondence between their bound elements follows directly and needs no conversation. This disposes of the large class of differences that are, at bottom, only differences of name: which kind of entity is which is settled by reference correspondence, not by the two sides having adopted the same lexicon. An agent <bcp14>MAY</bcp14> announce the set of identity correspondences it considers settled, for the record and for the peer to confirm.</t>
      </section>

      <section anchor="wf-residual"><name>Reconcile the residual by conversation</name>
        <t>What correspondence cannot settle is structure. Two agents may bind their "node" entity to corresponding references yet decompose the network differently - one as a single multi-layer topology, the other as stacked per-layer networks. The lexicon fixes the identity of the entities; it does not encode how one decomposition maps to the other. The agents reconcile the residual - structure, granularity, and gaps of scope - by the conversational mechanism of <xref target="I-D.janz-nmrg-ontology-reconciliation"/>, exchanging schema instances and explanation, now conducted <em>over the shared reference identities</em>, which is what makes the transform tractable and the instances comparable. The same conversation absorbs whatever the alignment could not settle cleanly - a low-confidence correspondence, or one the labels missed - so that an imperfect initial match is a starting point for dialogue, not a silent error. How much falls to this conversation scales with how far the two ontological spaces diverge: from almost nothing, for models of the same scope differing only in nomenclature, up to constructing a mutually workable representation where no direct correspondence was available. Scope gaps, where one side has no native element for a concept the other carries, are closed by self-extension: the deficient side extends its own ontology to host the concept, recording the extension against the relevant reference entry so the gap is documented, not hidden.</t>
      </section>

      <section anchor="wf-instances"><name>Co-reference the specific instances</name>
        <t>Everything to this point is type-level: it settles which <em>kinds</em> of entity two models share. A distinct problem remains before data can be exchanged about specific things: which specific <em>instances</em> co-refer - is one system's node the same physical element as another's, one system's service the same service. This is not settled by the reference lexicon, which is about types, and it <bcp14>MUST NOT</bcp14> be settled by assuming that local instance identifiers agree: identifiers are locally assigned, need not agree across administrative domains, and can collide, so a name that happens to match need not co-refer. A wrong instance match is more dangerous than a wrong type match, because it silently misroutes a real operation, and it may not surface until validation or until an operation goes wrong.</t>
        <t>Instance co-reference is instead established from evidence, extensionally and relationally, and runs <em>over</em> the type correspondences - only instances of corresponding types are compared, on their corresponding attributes. Three tiers apply, strongest anchor first. Where an authoritative <em>shared key</em> exists - a chassis serial, a management or loopback address, a service-order identifier - instances are matched on it; this is the instance-level analogue of a shared reference, and the easy case. Where no shared key exists, instances of corresponding types are matched on <em>attribute agreement</em>. Where attributes alone are ambiguous, they are matched on <em>structure</em>: two populated models describing the same physical reality are, up to the type correspondences, near-isomorphic, so an instance is identified by its neighbourhood - the same already-matched adjacencies - and matches propagate outward from a few high-confidence anchors through the topology. Each correspondence carries a confidence; ambiguous or conflicting ones <bcp14>SHOULD</bcp14> be carried into the conversation or referred to an authority rather than committed. The result is an instance-correspondence map, itself a living artefact updated as inventory changes.</t>
        <t>Two practical points bound this. Full population can be large and is sometimes private, so instance co-reference <bcp14>SHOULD</bcp14> operate on bounded, representative, or incrementally-exchanged populations - the region relevant to an exchange, anchored and propagated - rather than requiring either side to expose its whole inventory. And instance-level verification is a distinct check from the schema-level round-trip of <xref target="wf-generate"/>: it confirms that instances asserted to co-refer actually agree on their attributes and relations. Doing this matching by evidence up front is what lets verification confirm identity rather than discover a mismatch late.</t>
      </section>

      <section anchor="wf-generate"><name>Generate translators, validate, and maintain</name>
        <t>From the bindings, the reconciled residual, and the instance-correspondence map, each agent generates the translator that runs at its boundary. The translators are keyed on reference identity - each a mapping between a model and the references it is bound to, not between the two models directly - which is what makes them composable and is the basis of the scaling of <xref target="scaling"/>. Before any live change, a generated translator <bcp14>SHOULD</bcp14> be validated by the round-trip method of <xref target="I-D.janz-nmrg-ontology-reconciliation"/>: translate a representative instance and translate it back, in <em>both</em> directions, requiring the recovered instance to equal the original, and exercising the bindings themselves and not only the transforms, since a faithful transform built on a wrong anchor is still wrong. Where validation exposes a defect, or where a model, a reference entry, or the instance inventory later changes, the workflow is re-entered and the artefacts refreshed; ordinary operation runs the deterministic translators with no per-message model inference.</t>
      </section>
    </section>

    <!-- ================= 5. SCALING ================= -->
    <section anchor="scaling"><name>Scaling, and a Published Reference Ecosystem</name>
      <t>Keying translators on reference identity rather than on a specific peer changes how integration cost grows. Connecting N independently modelled systems by pairwise mediation takes on the order of N-squared translators; anchoring them all to the shared reference space takes on the order of N binding sets, each system reconciling itself against the references once. A further system is made interoperable not by building a translator against each incumbent but by binding once into the space; having bound, it obtains translation to and from every other bound system, because the path between any two runs through the references and the mappings that relate them - and it does not depend on the systems being alike, since one with an entirely different, even proprietary, model participates on the same terms.</t>
      <t>This holds on one condition: the cross-source mappings that relate the contributing lexicons must be shared, published infrastructure - established once and reused - not re-derived by every pair of agents. Where each pair had to relate its references from scratch, the cost would return to the order of N-squared; the saving comes precisely from doing the relating once, in the open, and reusing it. This points to a trajectory rather than a finished artefact. In the near term an agent derives the lexicon it needs from its own model and establishes correspondences at runtime, as here. The direction is toward <em>published</em> reference lexicons, authored deliberately with the composition that serves these workflows well - what that composition should be is the open question of <xref target="lexicon-entry"/> - and, growing up beside them, a published body of the cross-source correspondences that alignment produces. To the extent those correspondences are contributed back rather than kept private, the reference space becomes standing infrastructure: the next pair of systems from the same two sources reuses a settled correspondence, and a newcomer binds into a space already richly related. The lexicons and the correspondences that relate them are, on this view, twin artefacts worth developing and publishing together.</t>
    </section>

    <!-- ================= 6. WORKED EXAMPLE ================= -->
    <section anchor="illustration"><name>Worked Example: OTN Topology and Services</name>
      <t>Consider two controllers over one optical/OTN domain: Agent T exposing ONF Transport API <xref target="TAPI"/> <xref target="ONF-CIM"/>, Agent I exposing the IETF network and TE-topology models with the OTN topology augmentation <xref target="RFC8345"/> <xref target="RFC8795"/> <xref target="I-D.ietf-ccamp-otn-topo-yang"/>. Each brings a reference lexicon derived from its own standard and binds its own entities to it near-identically. The two lexicons are then aligned (<xref target="fig-binding"/>).</t>

      <figure anchor="fig-binding"><name>Two lexicons, bound and aligned (OTN illustration)</name>
        <artwork><![CDATA[
  Agent T      TAPI lexicon      align      IETF lexicon     Agent I
  -------      ------------    (<=corr=>)   ------------     -------
  node ..>  ForwardingDomain  <=close=>  node/te-node   <.. te-node
  NEP ...>  NodeEdgePoint     <=close=>  termination-pt <.. term-pt
  link ..>  Link              <=exact=>  link           <.. link
  n-r-grp>  NodeRuleGroup     <=close=>  connectivity-m <.. conn-mtx
                              (gloss; labels differ)
  SIP ...>  ServiceInterfacePt  --X-->  (no correspondent) = gap
     gap    <--X--  TunnelTerminationPt(TTP)  <.......... TTP
                    ^ TTP name-matches NodeEdgePoint;
                      example rejects it -> false cognate

  binds (..>)   : model -> its OWN lexicon      (near-identity)
  align (<=..=>): lexicon <=> lexicon (relation + confidence; or gap)
]]></artwork>
      </figure>

      <t>Most differences - node and te-node, the two termination-point concepts, the two link concepts, the shared-risk-group encodings - are settled by correspondence alone, with no conversation. The value of aligning from definitions and examples, not names, shows at the service anchor: in the label stage the IETF tunnel-termination-point, on the strength of the shared words, is a candidate correspondent for the link-termination-point entry, but its definition and canonical example reveal it to be the head of a tunnel, not a link attachment - a false cognate the example stage rejects, and which corresponds to no entry in the TAPI lexicon, recorded as a scope gap. Conversely, node-rule-group and connectivity-matrix, named too differently for the label stage to pair, are recovered from their definitions as a close correspondence. What remains is structural or a matter of granularity - the multi-layer topology against the stacked per-layer networks; a layer-1 signal carried as an ODU type plus capacity on one side and explicit tributary slots on the other - reconciled by conversation over the shared identities; the two scope gaps are closed by self-extension on the deficient side. Separately, before data is exchanged, the specific instances are co-referenced (<xref target="wf-instances"/>): the same physical nodes and ROADMs are matched on management address where it is shared and, for two identically-modelled ROADMs, disambiguated by which client node each spurs to - and a third, proprietary controller whose elements are named site, endpoint and span co-refers them the same way, on keys and topology rather than on names.</t>
      <t>The scaling property follows: that third system interoperates with both incumbents by binding into the space once and reusing the published correspondences, with no pairwise integration against either.</t>
    </section>

    <!-- ================= 7. RECOMMENDATIONS ================= -->
    <section anchor="recs"><name>Making Models Easier to Reconcile</name>
      <t>Reconciliation of this kind becomes markedly more reliable when the models being reconciled are authored with a few inexpensive properties in mind. The following are recommendations to the authors of data models, ontologies, and their proprietary variants - a way to nudge new and revised artefacts toward supporting automated alignment while people continue to develop them. None requires agreeing on a shared model, and none is specific to one modelling language, though the examples are drawn from YANG <xref target="RFC8407"/>.</t>
      <ul spacing="normal">
        <li>Declare the reference binding at authoring time. Where an element realises a known reference entity, its author <bcp14>SHOULD</bcp14> annotate it with that entity's stable identifier - a lightweight extension in a data model, or skos:exactMatch/closeMatch in an ontology. A declared binding turns inference into the reading of a stated correspondence; models that declare nothing still reconcile by inference, so it degrades gracefully.</li>
        <li>Write the optional descriptive text to disambiguate, not to decorate. The test is whether an intelligent stranger could tell the entity apart from its neighbours from the text alone - which is precisely the agent's task. Useful content states the entity's role, its layer or scope, the boundary of its extension, and an explicit contrast with the near-cognates it is confused with; and, above all, it attaches a canonical example.</li>
        <li>Keep relationships in machine-readable structure. Containment and typed references (leafref, identityref) carry matching signal an agent can use; a model that hides them in prose forfeits it.</li>
        <li>Expose a public lexicon layer, even for a proprietary model. A closed model can take part by publishing only its lexicon layer - the names, definitions, examples and reference bindings of its entities - while keeping its relationships and axioms private; a far lighter public commitment than a complete ontology.</li>
        <li>Publish stable instance identifiers. Where a model exposes durable, externally-meaningful keys for its instances - management addresses, serial numbers, service identifiers - it makes the instance co-reference of <xref target="wf-instances"/> a lookup rather than an inference, and removes a whole class of operational risk.</li>
      </ul>
    </section>

    <!-- ================= 8. PITFALLS ================= -->
    <section anchor="pitfalls"><name>Pitfalls and Considerations for Implementation</name>
      <ul spacing="normal">
        <li>Sufficiency is a property of the whole workflow, not of the lexicon alone. The lexicon settles identity and is silent on structure by design; the claim that a shared reference ontology is unnecessary holds only because structure is reconciled by the conversation, anchored on the shared identities.</li>
        <li>Cross-vocabulary matching is the dominant source of error - aligning one lexicon's entries to another's, or binding to a reference one did not author - not the near-identity binding of a model to its own lexicon. Matches <bcp14>SHOULD</bcp14> be made from definitions and examples rather than names, carry evidence and a confidence, and be validated by round-trip. That the initial match will not generally be perfect is expected, not a defect: low-confidence and missed correspondences <bcp14>SHOULD</bcp14> be carried into the conversation, not committed silently.</li>
        <li>Instance co-reference is a separate axis of correctness. Assuming instances co-refer because their names coincide is unsafe; identity <bcp14>SHOULD</bcp14> be established from keys, attributes and structure, with a confidence, and verified. A wrong instance match can misroute a real operation while every type correspondence is perfectly correct.</li>
        <li>Definitions are often under-specified, and near-synonymy bites: two agents can read one definition into slightly different concept boundaries. That a lexicon is a linguistic object distinct from an ontology is long observed <xref target="HIRST"/>, and terminology practice separates concept, designation and definition for this reason <xref target="ISO704"/>; canonical examples and exchanged instances are the tie-breakers.</li>
        <li>Composition, coverage and drift must be managed. Composing sources risks the same name for different entities, or different names for the same entity, so cross-source mappings, a curation policy, and provenance on every entry are needed; entries and bindings <bcp14>SHOULD</bcp14> be versioned, with re-binding a monitored, triggered event.</li>
        <li>The approach relies on the agents' interpretive competence. Depth is moved deliberately into the agents, so it inherits the general risks of language-model systems, and its quality is bounded by the agents rather than a fixed, inspectable model. Implementations <bcp14>SHOULD</bcp14> weigh where that judgement can be trusted and where a decision warrants human oversight before it takes effect.</li>
        <li>The measure of the approach is task success - whether the agents produce translators that round-trip a representative operational state space in both directions. On standard models this succeeds well, often on names alone and more so once definitions and structural context are weighted; the harder case is proprietary models that run ahead of the standards, where the recommendations of <xref target="recs"/> are the practical lever.</li>
      </ul>
    </section>

    <!-- ================= 9. SECURITY ================= -->
    <section anchor="security"><name>Security Considerations</name>
      <t>The reconciliation workflow this document builds on carries security considerations of its own - adversarial influence over the descriptions and examples exchanged, authorisation and auditability of any decision that augments an agent's effective ontology, controls on disclosure of finely detailed information, and the generic hazards of building on large language models. These are set out in <xref target="I-D.janz-nmrg-ontology-reconciliation"/> and apply here unchanged. This document adds two considerations of its own.</t>
      <t>First, the extent to which this introduces a common dependency scales with how far references are shared. Where two agents simply exchange and align references each derived from its own model, there is no external artefact both rely on, and the risk is the adversarial-influence-over-exchanged-content risk the companion document already covers. But to the degree that reference lexicons and, especially, their cross-source mappings are drawn from shared, published sources and reused across many pairs - the direction of <xref target="scaling"/> - they become common dependencies: an adversary able to influence a published entry's definition or example, or a published mapping, could steer the bindings and therefore the translators of every system that reuses it, closer to a supply-chain risk than to a single misled conversation. Implementations <bcp14>SHOULD</bcp14> therefore obtain shared reference lexicons and mappings from identifiable, trusted sources, carry provenance and version integrity on every entry and mapping, and treat both the adoption of a reference source and each binding made against it as authorised, auditable, revocable decisions. Second, instance co-reference is security-relevant in its own right: a corrupted or spoofed instance key, or a manipulated topology view, could cause an operation intended for one physical element to be applied to another. Instance correspondences <bcp14>SHOULD</bcp14> be established from trustworthy keys and corroborating evidence, carry a confidence, and be re-checked at validation before a change takes effect.</t>
    </section>

    <!-- ================= 10. IANA ================= -->
    <section anchor="iana"><name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

  </middle>

  <back>
    <references anchor="normative"><name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front><title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="S. Bradner"/><date year="1997" month="March"/></front>
        <seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="B. Leiba"/><date year="2017" month="May"/></front>
        <seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="8174"/>
      </reference>
    </references>

    <references anchor="informative"><name>Informative References</name>

      <reference anchor="I-D.janz-nmrg-ontology-reconciliation" target="https://datatracker.ietf.org/doc/html/draft-janz-nmrg-ontology-reconciliation-01">
        <front><title>Automated Agent-to-Agent Ontology Reconciliation for Cognitive Network Management Systems</title>
          <author initials="C." surname="Janz"/><date year="2026"/></front>
        <seriesInfo name="Internet-Draft" value="draft-janz-nmrg-ontology-reconciliation-01"/>
      </reference>

      <reference anchor="RFC8345" target="https://www.rfc-editor.org/info/rfc8345">
        <front><title>A YANG Data Model for Network Topologies</title>
          <author initials="A." surname="Clemm"/><author initials="J." surname="Medved"/><author initials="R." surname="Varga"/>
          <author initials="N." surname="Bahadur"/><author initials="H." surname="Ananthakrishnan"/><author initials="X." surname="Liu"/>
          <date year="2018" month="March"/></front>
        <seriesInfo name="RFC" value="8345"/>
      </reference>

      <reference anchor="RFC8795" target="https://www.rfc-editor.org/info/rfc8795">
        <front><title>YANG Data Model for Traffic Engineering (TE) Topologies</title>
          <author initials="X." surname="Liu"/><author initials="I." surname="Bryskin"/><author initials="V." surname="Beeram"/>
          <author initials="T." surname="Saad"/><author initials="H." surname="Shah"/><author initials="O." surname="Gonzalez de Dios"/>
          <date year="2020" month="August"/></front>
        <seriesInfo name="RFC" value="8795"/>
      </reference>

      <reference anchor="I-D.ietf-ccamp-otn-topo-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-topo-yang">
        <front><title>A YANG Data Model for Optical Transport Network Topology</title>
          <author initials="I." surname="Busi"/><author initials="S." surname="Belotti"/><author initials="V." surname="Lopez Alvarez"/>
          <author initials="A." surname="Sharma"/><author initials="Y." surname="Shi"/><date year="2024"/></front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-otn-topo-yang"/>
      </reference>

      <reference anchor="TAPI" target="https://opennetworking.org/">
        <front><title>Transport API (TAPI) - tapi-topology and tapi-connectivity YANG modules</title>
          <author><organization>Open Networking Foundation (ONF/OTCC)</organization></author><date year="2024"/></front>
      </reference>

      <reference anchor="ONF-CIM" target="https://opennetworking.org/">
        <front><title>Core Information Model (CoreModel), TR-512</title>
          <author><organization>Open Networking Foundation</organization></author><date year="2019"/></front>
      </reference>

      <reference anchor="TMF-SID" target="https://www.tmforum.org/">
        <front><title>Information Framework (SID), GB922</title>
          <author><organization>TM Forum</organization></author><date year="2024"/></front>
      </reference>

      <reference anchor="ETSI-ZSM-019">
        <front><title>Zero-touch network and Service Management (ZSM); Cross-domain integration and variable levels of abstraction</title>
          <author><organization>ETSI ISG ZSM</organization></author><date year="2026"/></front>
        <refcontent>ETSI GR ZSM 019</refcontent>
      </reference>

      <reference anchor="SKOS" target="https://www.w3.org/TR/skos-reference/">
        <front><title>SKOS Simple Knowledge Organization System Reference</title>
          <author initials="A." surname="Miles"/><author initials="S." surname="Bechhofer"/><date year="2009" month="August"/></front>
        <refcontent>W3C Recommendation</refcontent>
      </reference>

      <reference anchor="OM-BOOK">
        <front><title>Ontology Matching, 2nd edition</title>
          <author initials="J." surname="Euzenat"/><author initials="P." surname="Shvaiko"/><date year="2013"/></front>
        <refcontent>Springer</refcontent>
      </reference>

      <reference anchor="LOGMAP">
        <front><title>LogMap: Logic-Based and Scalable Ontology Matching</title>
          <author initials="E." surname="Jimenez-Ruiz"/><author initials="B." surname="Cuenca Grau"/><date year="2011"/></front>
        <refcontent>ISWC 2011</refcontent>
      </reference>

      <reference anchor="AML">
        <front><title>The AgreementMakerLight Ontology Matching System</title>
          <author initials="D." surname="Faria"/><author initials="C." surname="Pesquita"/><author initials="E." surname="Santos"/>
          <author initials="M." surname="Palmblad"/><author initials="I.F." surname="Cruz"/><author initials="F.M." surname="Couto"/><date year="2013"/></front>
        <refcontent>ODBASE/OTM 2013</refcontent>
      </reference>

      <reference anchor="PORTISCH">
        <front><title>Background Knowledge in Ontology Matching: A Survey</title>
          <author initials="J." surname="Portisch"/><author initials="M." surname="Hladik"/><author initials="H." surname="Paulheim"/><date year="2024"/></front>
        <refcontent>Semantic Web Journal</refcontent>
      </reference>

      <reference anchor="SABOU">
        <front><title>Exploring the Semantic Web as Background Knowledge for Ontology Matching</title>
          <author initials="M." surname="Sabou"/><author initials="M." surname="d'Aquin"/><author initials="E." surname="Motta"/><date year="2008"/></front>
        <refcontent>Journal on Data Semantics XI</refcontent>
      </reference>

      <reference anchor="AGENTOM">
        <front><title>Agent-OM: Leveraging LLM Agents for Ontology Matching</title>
          <author initials="Z." surname="Qiang"/><author initials="W." surname="Wang"/><author initials="K." surname="Taylor"/><date year="2025"/></front>
        <refcontent>Proc. VLDB Endowment 18(3); arXiv:2312.00326</refcontent>
      </reference>

      <reference anchor="LLMS4OM">
        <front><title>LLMs4OM: Matching Ontologies with Large Language Models</title>
          <author initials="H." surname="Babaei Giglou"/><author initials="J." surname="D'Souza"/><author initials="S." surname="Auer"/><date year="2024"/></front>
        <refcontent>ESWC 2024; arXiv:2404.10317</refcontent>
      </reference>

      <reference anchor="GENOM">
        <front><title>GenOM: Ontology Matching with Description Generation and Large Language Models</title>
          <author initials="Y." surname="Song"/><author initials="J." surname="Chen"/><author initials="R.A." surname="Schmidt"/><date year="2025"/></front>
        <refcontent>arXiv:2508.10703</refcontent>
      </reference>

      <reference anchor="HIRST">
        <front><title>Ontology and the Lexicon</title>
          <author initials="G." surname="Hirst"/><date year="2004"/></front>
        <refcontent>Handbook on Ontologies, Springer</refcontent>
      </reference>

      <reference anchor="ISO704">
        <front><title>Terminology work - Principles and methods</title>
          <author><organization>ISO</organization></author><date year="2022"/></front>
        <refcontent>ISO 704</refcontent>
      </reference>

      <reference anchor="BAILIN">
        <front><title>Ontology Negotiation between Intelligent Information Agents</title>
          <author initials="S.C." surname="Bailin"/><author initials="W." surname="Truszkowski"/><date year="2002"/></front>
        <refcontent>The Knowledge Engineering Review 17(1)</refcontent>
      </reference>

      <reference anchor="VANDIGGELEN">
        <front><title>Ontology Negotiation in Heterogeneous Multi-Agent Systems: the ANEMONE system</title>
          <author initials="J." surname="van Diggelen"/><author initials="R-J." surname="Beun"/><author initials="F." surname="Dignum"/>
          <author initials="R.M." surname="van Eijk"/><author initials="J-J." surname="Meyer"/><date year="2007"/></front>
        <refcontent>Applied Ontology 2(3-4)</refcontent>
      </reference>

      <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
        <front><title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
          <author initials="M." surname="Cotton"/><author initials="B." surname="Leiba"/><author initials="T." surname="Narten"/><date year="2017" month="June"/></front>
        <seriesInfo name="BCP" value="26"/><seriesInfo name="RFC" value="8126"/>
      </reference>

      <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950">
        <front><title>The YANG 1.1 Data Modeling Language</title>
          <author initials="M." surname="Bjorklund"/><date year="2016" month="August"/></front>
        <seriesInfo name="RFC" value="7950"/>
      </reference>

      <reference anchor="RFC3444" target="https://www.rfc-editor.org/info/rfc3444">
        <front><title>On the Difference between Information Models and Data Models</title>
          <author initials="A." surname="Pras"/><author initials="J." surname="Schoenwaelder"/><date year="2003" month="January"/></front>
        <seriesInfo name="RFC" value="3444"/>
      </reference>

      <reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8407">
        <front><title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
          <author initials="A." surname="Bierman"/><date year="2018" month="October"/></front>
        <seriesInfo name="RFC" value="8407"/>
      </reference>

      <reference anchor="RFC7224" target="https://www.rfc-editor.org/info/rfc7224">
        <front><title>IANA Interface Type YANG Module</title>
          <author initials="M." surname="Bjorklund"/><date year="2014" month="May"/></front>
        <seriesInfo name="RFC" value="7224"/>
      </reference>

      <reference anchor="I-D.hong-nmrg-agenticai-ps" target="https://datatracker.ietf.org/doc/draft-hong-nmrg-agenticai-ps/">
        <front><title>Motivations and Problem Statement of Agentic AI for Network Management</title>
          <author initials="Y." surname="Hong"/><date year="2025"/></front>
        <seriesInfo name="Internet-Draft" value="draft-hong-nmrg-agenticai-ps"/>
      </reference>

      <reference anchor="I-D.mw-nmop-yang-ai-challenges" target="https://datatracker.ietf.org/doc/draft-mw-nmop-yang-ai-challenges/">
        <front><title>Rethinking YANG-based Service and Network Management in the Era of Agentic AI</title>
          <author initials="Q." surname="Ma"/><author initials="Q." surname="Wu"/><date year="2025"/></front>
        <seriesInfo name="Internet-Draft" value="draft-mw-nmop-yang-ai-challenges"/>
      </reference>

      <reference anchor="I-D.marcas-nmop-kg-construct" target="https://datatracker.ietf.org/doc/draft-marcas-nmop-kg-construct/">
        <front><title>Knowledge Graph Construction from Network Data Sources</title>
          <author initials="I." surname="Dominguez Martinez-Casanueva"/><author initials="L." surname="Cabanillas"/><author initials="P." surname="Martinez-Julia"/><date year="2025"/></front>
        <seriesInfo name="Internet-Draft" value="draft-marcas-nmop-kg-construct"/>
      </reference>

      <reference anchor="TMF-TIO" target="https://www.tmforum.org/">
        <front><title>TM Forum Intent Ontology (TIO), TR292; Intent Common Model, TR290</title>
          <author><organization>TM Forum</organization></author><date year="2026"/></front>
        <refcontent>member resource</refcontent>
      </reference>

    </references>

    <section anchor="acks" numbered="false"><name>Acknowledgements</name>
      <t>The authors thank members of the NMRG and NMOP and ETSI ISG ZSM for ongoing exchanges on the role of agentic AI in network management.</t>
    </section>

  </back>
</rfc>
