Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design
draft-tailhardat-nmop-incident-management-noria-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 | Lionel Tailhardat , Raphaël Troncy , Yoan Chabot | ||
| Last updated | 2024-08-19 | ||
| 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-tailhardat-nmop-incident-management-noria-00
Network Management Operations L. Tailhardat
Internet-Draft Orange
Intended status: Informational R. Troncy
Expires: 20 February 2025 EURECOM
Y. Chabot
Orange
19 August 2024
Knowledge Graphs for Enhanced Cross-Operator Incident Management and
Network Design
draft-tailhardat-nmop-incident-management-noria-00
Abstract
Operational efficiency in incident management on telecom and computer
networks requires correlating and interpreting large volumes of
heterogeneous technical information. Knowledge graphs can provide a
unified view of complex systems through shared vocabularies. YANG
data models enable describing network configurations and automating
their deployment. However, both approaches face challenges in
vocabulary alignment and adoption, hindering knowledge capitalization
and sharing on network designs and best practices. To address this,
the concept of a meta-knowledge graph is introduced to leverage
existing network infrastructure descriptions in YANG format and
enable abstract reasoning on network behaviors. An experiment is
proposed to assess the potential of the meta-knowledge graph in
improving network quality and designs.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://genears.github.io/draft-tailhardat-nmop-incident-management-
noria/draft-tailhardat-nmop-incident-management-noria.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-tailhardat-nmop-incident-
management-noria/.
Discussion of this document takes place on the Network Management
Operations Working Group mailing list (mailto:nmop@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/nmop/.
Subscribe at https://www.ietf.org/mailman/listinfo/nmop/.
Source for this draft and an issue tracker can be found at
https://github.com/genears/draft-tailhardat-nmop-incident-management-
noria.
Tailhardat, et al. Expires 20 February 2025 [Page 1]
Internet-Draft Knowledge Graphs & Incident Management August 2024
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 February 2025.
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
3. A meta-knowledge graph to align operator-specificities and
share behavioral models of technical architectures . . . 6
3.1. Aligning operator-specificities with a multi-faceted
knowledge graph . . . . . . . . . . . . . . . . . . . . . 7
3.2. Learning and sharing behavioral models . . . . . . . . . 10
3.3. Relation to the Digital Map . . . . . . . . . . . . . . . 11
3.3.1. Core Requirements . . . . . . . . . . . . . . . . . . 11
3.3.2. Architectural Requirements . . . . . . . . . . . . . 12
3.4. Experiments . . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
Tailhardat, et al. Expires 20 February 2025 [Page 2]
Internet-Draft Knowledge Graphs & Incident Management August 2024
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Incident management on telecom and computer networks, whether it is
related to infrastructure or cybersecurity issues, requires the
ability to simultaneously and quickly correlate and interpret a large
number of heterogeneous technical information sources. Knowledge
Graphs (KGs), by structuring heterogeneous data through shared
vocabularies, enable providing a unified view of complex technical
systems, their ecosystem, and the activities and operations related
to them (see [I-D.marcas-nmop-knowledge-graph-yang] and
[NORIA-O-2024]). Using such formal knowledge representation allows
for a simplified interpretation of networks and their behavior, both
for NetOps & SecOps teams and artificial intelligence (AI) algorithms
(e.g. anomaly detection, root cause analysis, diagnostic aid,
situation summarization), and paves the way, in line with the Network
Digital Twin vision [I-D.irtf-nmrg-network-digital-twin-arch], for
the development of tools for detecting and analyzing complex network
incident situations through explainable, actionable, and shareable
models (see [FOLIO-2018], [SLKG-2023], and [GPL-2024]).
However, despite potential benefits of using knowledge graphs, these
are not mainstream yet in commercial network deployment systems and
decision support systems (see [NORIA-UI-2024] for more on the
decision support systems perspective). YANG is a widely used
standard among operators for describing network configurations and
automating their deployment. Using YANG representations in the form
of a KG, as suggested in [I-D.marcas-nmop-knowledge-graph-yang],
would minimize the effort required to adapt network management tools
towards the unified vision and applications evoked above. The lack
of alignment between various YANG models on key concepts (e.g. for
describing network topology) is, however, hindering this evolution
[I-D.boucadair-nmop-rfc3535-20years-later].
Furthermore, although [I-D.netana-nmop-network-anomaly-lifecycle]
addresses the capitalization of incident management knowledge through
a YANG model, it can be observed that the overall scope of YANG
models does not naturally cover the description of the networks'
ecosystem (e.g. physical equipment location, operator organization,
supervision systems) or the description of network operations from an
IT service management (ITSM) perspective (e.g. business processes and
design rules used by the company, scheduled modification operations,
remediation actions performed during incident handling). As a
consequence, the continuous improvement of network quality & designs
requires additional data cross-referencing operations to properly
Tailhardat, et al. Expires 20 February 2025 [Page 3]
Internet-Draft Knowledge Graphs & Incident Management August 2024
contextualize incidents and learn from remediation actions taken
(e.g. analyzing intervention technicians' verbatim, comparing actions
performed on similar incidents but occurring on different networks).
As a result of these additional efforts of contextualization, the
capitalization of knowledge typically remains confined at the level
of each network operator. This, in turn, hinders the sharing of
information within the community of researchers and system designers
regarding failure modes and best practices to adopt, considering the
concept of overall improvement of IT systems and the Internet.
Realizing an ITSM knowledge graph for network deployment, anomaly
detection and risk management applications has been studied for
several years in the Semantic Web community (i.e. knowledge
representation and automated reasoning leveraging Web technologies
such as [RDF], [RDFS], [OWL], and [SKOS]). Among other examples: the
DevOpsInfra ontology [DevOpsInfra-2021] allows for describing sets of
computing resources and how they are allocated for hosting services;
the NORIA-O ontology [NORIA-UI-2024] allows for describing a network
infrastructure & ecosystem, its events, diagnosis and repair actions
performed during incident management. Assuming the continuous
integration into a knowledge graph of data from ticketing systems,
network monitoring solutions, and network configuration management
databases, we remark that the resulting knowledge graph (Figure 1)
implicitely holds the necessary information to (automatically) learn
incident contexts (i.e. the network topology, its set of states and
set of events prior to the incident) and remediation procedures (i.e.
the set of actions and network configuration changes carried-out to
resolve the incident).
Tailhardat, et al. Expires 20 February 2025 [Page 4]
Internet-Draft Knowledge Graphs & Incident Management August 2024
┌───Incident context────────────────────────────┐
│ ┌────────────┐ │
│ │skos:Concept│ │
│ └─┬┬─────────┘ │
│ <server> │
│ ▲ │
│ │ │
│ resourceType │
│ ┌────────┐ │ │ ┌─────────────┐
│ │Resource│ │ │ │TroubleTicket│
│ └──────┬┬┘ │ │ └─────┬┬──────┘
│ ││ │ │ ││
│ <ne_2>──<ne_1>◄──troubleTicketRelatedResource──<incident_01>
│ │ │ │ │
│ │ │ │ problemCategory
│<ne_5>──<ne_4>────┼──<ne_3>────<log_2> │ │
│ │ │ │ │ ▼
│ │ │ │ │ <packet-loss>
│ <log_3> │ <ne_6> │ ││
│ │ │ ┌────┴┴──────┐
│ logOriginatingManagedObject │ │skos:Concept│
│ │ │ └────────────┘
│ ▼ │
│ <log_1>──────┐ │
│ ┌─────────┴┴┐ dcterms:type │
│ │EventRecord│ │ │
│ └───────────┘ ▼ │
│ <integrityViolation> │
│ ┌────┴┴──────┐ │
│ │skos:Concept│ │
│ └────────────┘ │
└───────────────────────────────────────────────┘
Figure 1: Learning an incident signature seen as a classification
model that is trained on the relationship of the incident context
(i.e. a subgraph centered around a Resource entity concerned by a
given TroubleTicket) to the problem class defined at the
TroubleTicket entity level. Arrows are for object properties
(owl:ObjectProperty), double line edges are for object class
relationships (rdf:type).
Tailhardat, et al. Expires 20 February 2025 [Page 5]
Internet-Draft Knowledge Graphs & Incident Management August 2024
By going a step further, we notice that a generic understanding of
incident context can be extracted and shared among operators from
knowledge graphs. Indeed, a knowledge graph, being an instantiation
of shared vocabularies (e.g. RDFS/OWL ontologies and controlled
vocabularies in SKOS syntax), sharing incident signatures can be done
without revealing infrastructure details (e.g. hostname, IP address),
but rather the abstract representation of the network (i.e. the class
of the knowlegde graph entities and relationships, such as "server"
or "router", and or "IPoWDM link").
The remainder of this document is organized as follows. Firstly, the
concept of a _meta-knowledge graph_ is introduced to leverage
existing network infrastructure descriptions in YANG format and
enable abstract reasoning on network behaviors. Secondly, an
experiment is proposed to assess the potential of the meta-knowledge
graph in improving network quality and designs. In addition to the
main parts of the proposal, the document also covers data integration
and data federation architectures in the Security Considerations
section. This section specifically addresses the handling of event
data streams and the provision of a unified view for different
stakeholders.
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.
3. A meta-knowledge graph to align operator-specificities and share
behavioral models of technical architectures
TODO Introduce and develop the following topics.
Topics:
* Principles for implicit learning of incident characteristics and
resolution methods through a graph and activity tracing.
- Aligning operator-specificities with a multi-faceted knowledge
graph.
- Learning and sharing behavioral models.
- Relation to the Network Anomaly Lifecycle experiment
[I-D.netana-nmop-network-anomaly-lifecycle].
Tailhardat, et al. Expires 20 February 2025 [Page 6]
Internet-Draft Knowledge Graphs & Incident Management August 2024
- Relation to the Digital Map concept
[I-D.havel-nmop-digital-map-concept].
* Meta-KG construction
- Integrating Service and Network topology data from YANG data
models, such as Network Topologies [RFC8345] and Service
Assurance [RFC9418]}.
- Relation to the NORIA-O ontology [NORIA-O-2024].
- Trends towards some Yang to OWL / Yang to RDF data
transformation tool.
* Experiments towards the meta-KG proposal.
3.1. Aligning operator-specificities with a multi-faceted knowledge
graph
TODO Meta-KG construction
TODO Relate the Meta-KG construction part to the following REQ-DM-
SCALES related considerations.
The following figures illustrate different scenarios for constructing
a meta-KG through an Extract-Transform-Load (ETL) data integration
pipeline. From the perspective of the Digital Map Requirements
(Section 3.3), the Figure 4, Figure 5 and Figure 6 particularly
address the REQ-DM-SCALES requirement.
┌──────┐ ┌─────────┐ ┌──────┐ ┌────────┐ ┌──────┐
┌──────┐ │ │ │ Stream │ │ │ │ Stream │ │┌────┐│
│Events├─►│E.S.B.├─►│ mapping ├─►│S.S.B.├─►│ loader ├─►││K.G.││
└──────┘ │ │ │ │ │ │ │ │ │└────┘│
└──────┘ └─────────┘ └──┬───┘ └────────┘ └──────┘
│
┌───────────────────┴──────────────────────┐
│(event/LOG_login_03)=>(object/RES/router1)│
└─┌──────────────────────────────────────────┐
│(event/LOG_login_03)=>(object/RES/router1)│
└─┌──────────────────────────────────────────┐
│(event/LOG_login_03)=>(object/RES/router1)│
└──────────────────────────────────────────┘
Figure 2: KG-only data integration architecture for event data
streams
Tailhardat, et al. Expires 20 February 2025 [Page 7]
Internet-Draft Knowledge Graphs & Incident Management August 2024
<object/RES_router3>
<object/RES_router2> │
│ │ ┌────────┐
<object/RES_router1>─rdf:type─┤Resource│
│ └────────┘
│
logOriginatingManagedObject
│
<event/LOG_login_01> ┌───────────┐
<event/LOG_login_02>──rdf:type─┤EventRecord│
<event/LOG_login_03> └───────────┘
Figure 3: Resulting knowledge representation for the KG-only data
integration architecture for event data streams
┌────────────┐
│ Complex │
│ Event │
│ Processing │
└────┬──┬────┘
┌──────┐ ┌──┴──┴───┐ ┌──────┐ ┌────────┐ ┌──────┐
┌──────┐ │ │ │ Stream │ │ │ │ Stream │ │┌────┐│
│Events├─►│E.S.B.├─►│ mapping ├─►│S.S.B.├─►│ loader ├─►││K.G.││
└──────┘ │ │ │ │ │ │ │ │ │└────┘│
└──┬───┘ └─────────┘ └──┬───┘ └────────┘ └──────┘
│ │
│ ┌───────────────────┴──────────────────────┐
│ │(event/AIS_login_01)=>(object/RES/router1)│
│ └──────────────────────────────────────────┘
│ ┌────────┐ ┌──────┐
│ │ Stream │ │┌────┐│
└────────────────────────────►│ loader ├─►││TSDB││
│ │ │└────┘│
└────────┘ └──────┘
Figure 4: Mixed KG/non-KG data integration architecture for event
data streams
Tailhardat, et al. Expires 20 February 2025 [Page 8]
Internet-Draft Knowledge Graphs & Incident Management August 2024
<object/RES_router3>
<object/RES_router2> │
│ │ ┌────────┐
<object/RES_router1>─rdf:type─┤Resource│
│ └────────┘
logOriginatingManagedObject
│ ┌───────────┐
┌──────────────────►<event/AIS_login_01>──rdf:type─┤EventRecord│
│ │ │ \ └───────────┘
│ duration │ \
│ │ │ dcterms:type
│ "P0Y0M0DT0H3M30S"^^xsd:duration │ \
│ │ <Notification/
│ loggingTime EventType/inferredAlert>
│ │ │
│ "2024-02-07T16:22:42Z"^^xsd:dateTime rdf:type
│ ┌─────┴──────┐
│ │skos:Concept│
│ KG knowledge representation └────────────┘
│ ==============================================================
│ Time series database (TSDB) data representation
│
│ Timestamp Origin Event
│ 2024-02-07T16:22:42Z <object/RES_router1> Login Attempt
│ 2024-02-07T16:23:13Z <object/RES_router1> Login Attempt
│ 2024-02-07T16:26:12Z <object/RES_router1> Login Attempt
│ ▲
└──shared─identifier──────────────┘
Figure 5: Resulting knowledge representation for the mixed KG/
non-KG data integration architecture for event data streams
Tailhardat, et al. Expires 20 February 2025 [Page 9]
Internet-Draft Knowledge Graphs & Incident Management August 2024
───On-premise──────────────────────────── ┌─┐ Scope-based querying
┌Dom.─A─┐ │ │
│┌─────┐│ ┌──────┐ ┌─────────┐ │ │ ┌───────────┐
─►││ KG ││◄─┤KGDBMS├───────────┤SPARQL EP├─►│ ├─Network &─┤ NetOps │
│└─────┘│ └──────┘ └─────────┘ │ ├─Usage─────┤Application│
└UG.─2──┘ │ │ └───────────┘
┌Dom. B─┐ │ │ ┌───────────┐
│┌─────┐│ ┌──────┐ ┌─────────┐ │ ├─Network &─┤ SecOps │
─►││ KG ││◄─┤KGDBMS├───────────┤SPARQL EP├─►│ ├─Security──┤Application│
│└─────┘│ └──────┘ └─────────┘ │F│ └───────────┘
└UG.─1┬─┘ │E│
└────────────────────────────────────│D│─────────────┐
───On-premise / public-cloud───────────── │E│ │
┌Dom.─C─┐ │R│ ▼ Usage
│┌─────┐│ ┌──────┐ ┌───┐ ┌─────────┐ │A│ ┌────scope──┐
─►││ RDB ││◄─┤RDBMS ├─┤VKG├─────┤SPARQL EP├─►│T│ │* │
│└─────┘│ └──────┘ └───┘ └─────────┘ │E│ Network │ * * │
└UG.─1&2┘ │D│ scope───│────────┐ │
┌Dom.─D─┐ │ │ │ │ * * │ │
│┌─────┐│ ┌──────┐ ┌───┐ ┌─────────┐ │Q│ │ *└───────────┘
─►││NoSQL││◄─┤RDBMS ├─┤VKG├─────┤SPARQL EP├─►│U│ │ ┌───────────┐
│└─────┘│ └──────┘ └───┘ └─────────┘ │E│ │* │ * * │ │
└UG.─1──┘ │R│ └──│─────────┘ │
┌Dom.─E─┐ │I│ ▲ │ * │
│┌─────┐│ ┌──────┐ ┌───────┐ ┌─────────┐ │E│ │ │ * * │
─►││ LPG ││◄─┤GDBMS ├─┤QL tlt.├─┤SPARQL EP├─►│S│ │ └──Security─┘
│└─────┘│ └──────┘ └───────┘ └─────────┘ │ │ │ scope ▲
└UG.┬2──┘ │ │ │ │
└──────────────────────────────────────│ │────────┼──────────┘
│ │ │
───Public-cloud────────────────────────── │ │ │
┌Dom.─F─┐ │ │ │
│┌─────┐│ ┌──────┐ ┌─────────┐ │ │ │
─►││ KG ││◄─┤KGDBMS├───────────┤SPARQL EP├─►│ │ │
│└─────┘│ └──────┘ └─────────┘ │ │ │
└UG.┬1&2┘ └─┘ │
└─────────────────────────────────────────────────┘
Figure 6: Unified access to data distributed across various
technological platforms
3.2. Learning and sharing behavioral models
TODO NetOps perspective
TODO SecOps perspective
Tailhardat, et al. Expires 20 February 2025 [Page 10]
Internet-Draft Knowledge Graphs & Incident Management August 2024
3.3. Relation to the Digital Map
Similar to the concept of _meta-knowledge graph_ (meta-KG) discussed
here, the concept of _Digital Map_ discussed in
[I-D.havel-nmop-digital-map-concept] emphasizes the need to structure
heterogeneous data describing networks in order to simplify network
management operations through unified access to this data. The meta-
knowledge graph extends the Digital Map concept by adding information
about the lifecycle of infrastructures and services, as well as the
context of their usage. These additional pieces of information are
considered essential for learning shareable activity models of
systems.
To clarify this positioning, the following lists reflect the
compliance of the meta-KG concept with the Digital Map Requirements
defined in [I-D.havel-nmop-digital-map-concept]. A symbol to the
right of each requirement name indicates the nature of compliance:
*+* for compatibility, */* for partial satisfaction, *-* for non-
compliance with the requirement. A comment is provided as necessary.
3.3.1. Core Requirements
*+* REQ-BASIC-MODEL-SUPPORT: nothing to report (n.t.r.)
*+* REQ-LAYERED-MODEL: n.t.r.
*/* REQ-PROG-OPEN-MODEL: Partially satifying the requirement as the
concept of meta-KG mainly relate to the knowledge representation
topic rather than to the platform running the Digital Map service
on top of the meta-knowledge graph.
*/* REQ-STD-API-BASED: Same remark as for REQ-PROG-OPEN-MODEL.
*+* REQ-COMMON-APP: n.t.r.
*+* REQ-SEMANTIC: n.t.r.
*+* REQ-LAYER-NAVIGATE: n.t.r.
*+* REQ-EXTENSIBLE: Knowledge graphs implicitly satisfy this
requirement, notably with OWL [OWL] and SKOS [SKOS] constructs if
considering RDF knowledge graphs for the meta-KG (e.g. owl:sameAs
to relate a meta-KG entity to some other entity of another
knowledge graph, owl:equivalentClass to link concepts and
properties used to interpret the meta-KG to concepts and
properties from other data models, skos:inScheme to group new
items of a controled-vocabulary as part of a skos:ConceptScheme).
Tailhardat, et al. Expires 20 February 2025 [Page 11]
Internet-Draft Knowledge Graphs & Incident Management August 2024
*+* REQ-PLUGG: Same remark as for REQ-EXTENSIBLE.
*+* REQ-GRAPH-TRAVERSAL: This capability is naturally enabled as the
meta-KG concept involves using a graph data structure.
3.3.1.1. Design Requirements
*-* REQ-TOPO-ONLY: Requirement not satisfied as the meta-KG involves
to have more than topological data to interpret and contextualize
the network behavior.
*-* REQ-PROPERTIES: Same remark as for REQ-TOPO-ONLY.
*-* REQ-RELATIONSHIPS: Same remark as for REQ-TOPO-ONLY.
*+* REQ-CONDITIONAL: Native, notably considering the expressiveness
of SPARQL [SPARQL11-QL] if using the Semantic Web protocol stack
to run the meta-KG concept.
*+* REQ-TEMPO-HISTO: n.t.r.
3.3.2. Architectural Requirements
*+* REQ-DM-SCALES: This capability applies as we can use data
aggregation at the graph level (Figure 4 and Figure 5 compared to
Figure 2 and Figure 3), aggregation without loss of information
(Figure 4 and Figure 5), and load balancing (horizontal scaling)
by partitioning the meta-KG (Figure 6). Further, ease of
integration is enabled thanks to existing standard graph data
access protocols (e.g. SPARQL Federated Queries [SPARQL11-FQ], as
illustrated in Figure 6).
*/* REQ-DM-DISCOVERY: Same remark as for REQ-PROG-OPEN-MODEL.
3.4. Experiments
TODO Experiments
4. Security Considerations
As this document covers the _meta-knowledge graph_ concepts, and use
cases, there is no specific security considerations.
However, as the concept of a meta-knowledge graph involves the
construction of a multi-faceted graph (i.e. including network
topologies, operational data, and service and client data), it poses
the risk of simplifying access to network operational data and
functions that fall outside the knowledge graph users' responsibility
Tailhardat, et al. Expires 20 February 2025 [Page 12]
Internet-Draft Knowledge Graphs & Incident Management August 2024
or that could facilitate the intervention of malicious individuals.
To support the discussion on mitigating this risk, we suggest
referring to Figure 6, which illustrates the concept of partial
access to the meta-knowledge graph based on rights associated with
each user group (UG) at the data domain level. We also recommend
referring to [AMO-2012] for an example of implemention of access
rights in a content management system that relies on Semantic Web
models and technologies. This implementation uses the AMO ontology,
which includes a set of classes and properties for annotating
resources that require access control, as well as a base of inference
rules that model the access management strategy to carry out.
5. IANA Considerations
This document has no IANA actions.
6. References
6.1. Normative References
[I-D.havel-nmop-digital-map-concept]
Havel, O., Claise, B., de Dios, O. G., and T. Graf,
"Digital Map: Concept, Requirements, and Use Cases", Work
in Progress, Internet-Draft, draft-havel-nmop-digital-map-
concept-00, 4 July 2024,
<https://datatracker.ietf.org/doc/html/draft-havel-nmop-
digital-map-concept-00>.
[I-D.netana-nmop-network-anomaly-lifecycle]
Riccobene, V., Roberto, A., Graf, T., Du, W., and A. H.
Feng, "Experiment: Network Anomaly Lifecycle", Work in
Progress, Internet-Draft, draft-netana-nmop-network-
anomaly-lifecycle-03, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-netana-nmop-
network-anomaly-lifecycle-03>.
[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/rfc/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/rfc/rfc8174>.
Tailhardat, et al. Expires 20 February 2025 [Page 13]
Internet-Draft Knowledge Graphs & Incident Management August 2024
[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/rfc/rfc8345>.
[RFC9418] Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T.
Arumugam, "A YANG Data Model for Service Assurance",
RFC 9418, DOI 10.17487/RFC9418, July 2023,
<https://www.rfc-editor.org/rfc/rfc9418>.
6.2. Informative References
[AMO-2012] Buffa, M. and C. Faron-Zucker, "Ontology-Based Access
Rights Management", 2012,
<https://doi.org/10.1007/978-3-642-25838-1_3>.
[DevOpsInfra-2021]
Corcho, O., Chaves-Fraga, D., Toledo, J., Arenas-Guerrero,
J., Badenes-Olmedo, C., Wang, M., Peng, H., Burrett, N.,
Mora, J., and P. Zhang, "A High-Level Ontology Network for
ICT Infrastructures", 2021,
<https://doi.org/10.1007/978-3-030-88361-4_26>.
[FLAGSM-2021]
Steenwinckel, B., Paepe, D. D., Hautte, S. V., Heyvaert,
P., Bentefrit, M., Moens, P., Dimou, A., Bossche, B. V.
D., Turck, F. D., Hoecke, S. V., and F. Ongenae, "FLAGS: A
Methodology for Adaptive Anomaly Detection and Root Cause
Analysis on Sensor Data Streams by Fusing Expert Knowledge
with Machine Learning", 2021,
<https://doi.org/10.1016/j.future.2020.10.015>.
[FOLIO-2018]
Steenwinckel, B., Heyvaert, P., Paepe, D. D., Janssens,
O., Hautte, S. V., Dimou, A., Turck, F. D., Hoecke, S. V.,
and F. Ongenae, "Towards Adaptive Anomaly Detection and
Root Cause Analysis by Automated Extraction of Knowledge
from Risk Analyses", 2018,
<https://www.ceur-ws.org/Vol-2213/paper2.pdf>.
[GPL-2024] Tailhardat, L., Stach, B., Chabot, Y., and R. Troncy,
"Graphameleon: Relational Learning and Anomaly Detection
on Web Navigation Traces Captured as Knowledge Graphs",
2024, <https://doi.org/10.1145/3589335.3651447>.
[I-D.boucadair-nmop-rfc3535-20years-later]
Boucadair, M., Contreras, L. M., de Dios, O. G., Graf, T.,
and R. Rahman, "RFC 3535, 20 Years Later: An Update of
Tailhardat, et al. Expires 20 February 2025 [Page 14]
Internet-Draft Knowledge Graphs & Incident Management August 2024
Operators Requirements on Network Management Protocols and
Modelling", Work in Progress, Internet-Draft, draft-
boucadair-nmop-rfc3535-20years-later-04, 22 July 2024,
<https://datatracker.ietf.org/doc/html/draft-boucadair-
nmop-rfc3535-20years-later-04>.
[I-D.irtf-nmrg-network-digital-twin-arch]
Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu,
Q., Boucadair, M., and C. Jacquenet, "Network Digital
Twin: Concepts and Reference Architecture", Work in
Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
twin-arch-06, 7 July 2024,
<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
network-digital-twin-arch-06>.
[I-D.marcas-nmop-knowledge-graph-yang]
Martinez-Casanueva, I. D. and L. C. Rodríguez, "Knowledge
Graphs for YANG-based Network Management", Work in
Progress, Internet-Draft, draft-marcas-nmop-knowledge-
graph-yang-03, 5 July 2024,
<https://datatracker.ietf.org/doc/html/draft-marcas-nmop-
knowledge-graph-yang-03>.
[NORIA-O-2024]
Tailhardat, L., Troncy, R., and Y. Chabot, "NORIA-O: An
Ontology for Anomaly Detection and Incident Management in
ICT Systems", 2024,
<https://doi.org/10.1007/978-3-031-60635-9_2>.
[NORIA-UI-2024]
Tailhardat, L., Chabot, Y., Py, A., and P. Guillemette,
"NORIA UI: Efficient Incident Management on Large-Scale
ICT Systems Represented as Knowledge Graphs", 2024,
<https://doi.org/10.1145/3664476.3670438>.
[OWL] W3C, "OWL 2 Web Ontology Language Document Overview
(Second Edition)", December 2012,
<https://www.w3.org/TR/owl2-overview/>.
[RDF] W3C, "Resource Description Framework (RDF): Concepts and
Abstract Syntax", February 2014,
<https://www.w3.org/TR/rdf11-concepts/>.
[RDFS] W3C, "RDF Schema 1.1", February 2014,
<https://www.w3.org/TR/rdf-schema/>.
Tailhardat, et al. Expires 20 February 2025 [Page 15]
Internet-Draft Knowledge Graphs & Incident Management August 2024
[SKOS] W3C, "SKOS Simple Knowledge Organization System
Reference", August 2009,
<https://www.w3.org/TR/skos-reference/>.
[SLKG-2023]
Tailhardat, L., Troncy, R., and Y. Chabot, "Leveraging
Knowledge Graphs For Classifying Incident Situations in
ICT Systems", 2023,
<https://doi.org/10.1145/3600160.3604991>.
[SPARQL11-FQ]
W3C, "SPARQL 1.1 Federated Query", March 2013,
<https://www.w3.org/TR/sparql11-federated-query/>.
[SPARQL11-QL]
W3C, "SPARQL 1.1 Query Language", March 2013,
<https://www.w3.org/TR/sparql11-query/>.
Acknowledgments
We would like to thank Benoit Claise for spontaneously seeking to
include the work of the NORIA research project in the vision of the
NMOP working group through direct contact.
We would also like to thank Fano Rampary for his initial analysis of
the possibilities of defining a model conversion algebra for going
from Yang data models to OWL ontologies.
Authors' Addresses
Lionel Tailhardat
Orange
Email: lionel.tailhardat@orange.com
Raphaël Troncy
EURECOM
Email: raphael.troncy@eurecom.fr
Yoan Chabot
Orange
Email: yoan.chabot@orange.com
Tailhardat, et al. Expires 20 February 2025 [Page 16]