RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling

Internet-Draft	RFC 3535, 20 Years Later	November 2024
Boucadair, et al.	Expires 29 May 2025	[Page]

Abstract

The IAB organized an important workshop to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" (RFC 3535) which was instrumental for developing NETCONF and YANG, in particular.¶

20 years later, it is time to evaluate what has been achieved since then and identify the operational barriers for making these technologies widely implemented. Also, this document captures new requirements for network management operations.¶

Table 1
NEW Ops Requirement Label	Section
NEW-OPS-REQ-STRENGTHEN-DM	Section 5.1
NEW -OPS-REQ-DM-RATIONALIZE	Section 5.2
NEW -OPS-REQ-EASE-EXPOSURE	Section 5.3
NEW -OPS-REQ-NW-API-DISCOVERY	Section 5.3
NEW-OPS-REQ-DM-API	Section 5.4
NEW-OPS-REQ-PROFILING	Section 5.5
NEW-OPS-REQ-REASSESS	Section 5.5
NEW-OPS-REQ-AGILE	Section 5.6
NEW-OPS-REQ-INTEGRATION	Section 5.7
NEW-OPS-REQ-Y2KG	Section 5.8
NEW-OPS-REQ-SCALE	Section 5.8
NEW-OPS-REQ-LOSSLESS	Section 5.9
NEW-OPS-REQ-REUSABILITY	Section 5.10
NEW-OPS-REQ-NEW-NEED	Section 5.12
NEW-OPS-REQ-UNSILO	Section 5.13
NEW-OPS-REQ-TIMELY-DM	Section 5.14
NEW-OPS-REQ-READILTY-IMPLEM	Section 5.15
NEW-OPS-REQ-IT-INTEGRATION	Section 5.16.1
NEW-OPS-REQ-IETF-TOOLS	Section 5.16.2
NEW-OPS-REQ-CLIENT-TOOLS	Section 5.16.3
NEW-OPS-REQ-BRIDGE	Section 5.16.4
NEW-OPS-REQ-GLUE	Section 5.17
NEW-OPS-REQ-GUIDANCE	Section 5.18

3. Assessment of RFC 3535 Operator Requirements

Section 3 of [RFC3535] includes the following recommendations:¶

 Ease of use is a key requirement for any network management
   technology from the operators point of view.

Status Update:: This is still a valid requirement. It is even exacerbated with the amount of techniques and extensions that were specified since then.¶

 It is necessary to make a clear distinction between configuration
   data, data that describes operational state and statistics.  Some
   devices make it very hard to determine which parameters were
   administratively configured and which were obtained via other
   mechanisms such as routing protocols.

Status Update:: This requirement was taken into account when designing IETF solutions. Specifically, datastores are a fundamental concept in NETCONF/YANG (e.g., [RFC8342].¶

 It is required to be able to fetch separately configuration data,
   operational state data, and statistics from devices, and to be
   able to compare these between devices.

Status Update:: This is supported by NETCONF and RESTCONF.¶

 It is necessary to enable operators to concentrate on the
   configuration of the network as a whole rather than individual
   devices.

Status Update:: Protocols such as NETCONF supports means to handle transactions at the level of a network. For example, a controller can establish parallel sessions with a set of devices and make use of confirmed commit.¶
: Also, [RFC8969] describes how YANG/RESTONF/YANG can be used to manage a network and map it to involves underlying functions/nodes. Several service and network data models are required for this aim.¶
: The IETF defined in the past models to manage few servcies such as VPN at both service and network levels (e.g., the Layer 2 Service Model (L2SM) [RFC8466], the Layer 3 Service Model (L3SM) [RFC8299], the Layer 2 Network Model (L2NM) [RFC9291], and the Layer 3 Network Model (L3NM) [RFC9182]).¶
: A similar effort is currently ongoing for handling attachement circuits at both service and network layers (e.g., [I-D.ietf-opsawg-teas-attachment-circuit], [I-D.ietf-opsawg-ntw-attachment-circuit]).¶
: More effort is still needed in this area.¶

 Support for configuration transactions across a number of devices
   would significantly simplify network configuration management.

Status Update:: This feature is supported by NETCONF.¶

 Given configuration A and configuration B, it should be possible
   to generate the operations necessary to get from A to B with
   minimal state changes and effects on network and systems.  It is
   important to minimize the impact caused by configuration changes.

Status Update:: This feature is supported by NETCONF.¶

 A mechanism to dump and restore configurations is a primitive
   operation needed by operators.  Standards for pulling and pushing
   configurations from/to devices are desirable.

Status Update:: This feature is supported by NETCONF.¶

 It must be easy to do consistency checks of configurations over
   time and between the ends of a link in order to determine the
   changes between two configurations and whether those
   configurations are consistent.

Status Update:: A mechanism is specified in [RFC9144].¶

 Network wide configurations are typically stored in central
   master databases and transformed into formats that can be pushed
   to devices, either by generating sequences of CLI commands or
   complete configuration files that are pushed to devices.  There
   is no common database schema for network configuration, although
   the models used by various operators are probably very similar.
   It is desirable to extract, document, and standardize the common
   parts of these network wide configuration database schemas.

Status Update:: Covered by current implementations.¶

 It is highly desirable that text processing tools such as diff,
   and version management tools such as RCS or CVS, can be used to
   process configurations, which implies that devices should not
   arbitrarily reorder data such as access control lists.

Status Update:: This is deployment-specific.¶

 The granularity of access control needed on management interfaces
   needs to match operational needs.  Typical requirements are a
   role-based access control model and the principle of least
   privilege, where a user can be given only the minimum access
   necessary to perform a required task.

Status Update:: RBAC is supported by existing implementation. Also, the IETF defined [RFC8341] for this purpose.¶

 It must be possible to do consistency checks of access control
   lists across devices.

Status Update:: This is implementation-specific.¶

 It is important to distinguish between the distribution of
   configurations and the activation of a certain configuration.
   Devices should be able to hold multiple configurations.

Status Update:: This is supported by existing NETCONF methods.¶

 SNMP access control is data-oriented, while CLI access control is
   usually command (task) oriented.  Depending on the management
   function, sometimes data-oriented or task-oriented access control
   makes more sense.  As such, it is a requirement to support both
   data-oriented and task-oriented access control.

Status Update:: This is supported by [RFC8341].¶

4. Assessment of RFC 3535 Recommendations

Section 6 of [RFC3535] includes the following recommendations:¶

 The workshop recommended that the IETF stop forcing working groups
   to provide writable MIB modules.  It should be the decision of
   the working group whether they want to provide writable objects
   or not.

Status Update:

In 2014, the IESG published a statement Writable MIB Module, which states that:¶

SNMP MIB modules creating and modifying configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration, and in consultation with the OPS ADs/MIB doctors.¶

 The workshop recommended that a group be formed to investigate why
   current MIB modules do not contain all the objects needed by
   operators to monitor their networks.

Status Update:: No such group was formed to our knowledge.¶

 The workshop recommended that a group be formed to investigate why
   the current SNMP protocol does not satisfy all the monitoring
   requirements of operators.

Status Update:: No such group was formed to our knowledge.¶
: This SNMP shortcoming was also reiterated in Section 3.5.2 of [RFC5345].¶

 The workshop recommended, with strong consensus from both protocol
   developers and operators, that the IETF focus resources on the
   standardization of configuration management mechanisms.

Status Update:: NETCONF [RFC6241], RESTCONF [RFC8040], CORECONF [I-D.ietf-core-comi], YANG.¶
: YANG is a transport-independent data modeling language. It can be used independently of NETCONF/RESTCONF. For example, YANG can be used to define abstract data structures [RFC8791] that can be manipulated by other protocols (e.g., [RFC9132]).¶

 The workshop recommended, with strong consensus from the operators
   and rough consensus from the protocol developers, that the
   IETF/IRTF should spend resources on the development and
   standardization of XML-based device configuration and management
   technologies (such as common XML configuration schemas, exchange
   protocols and so on).

Status Update:: OK. This recommendation was also mirrored in other documents such as [RFC5706].¶

 The workshop recommended, with strong consensus from the operators
   and rough consensus from the protocol developers, that the
   IETF/IRTF should not spend resources on developing HTML-based or
   HTTP-based methods for configuration management.

Status Update:: The IETF deviated from this recommendation, e.g., RESTCONF [RFC8040] or CoAP Management Interface (CORECONF) [I-D.ietf-core-comi].¶

 The workshop recommended, with rough consensus from the operators
   and strong consensus from the protocol developers, that the IETF
   should continue to spend resources on the evolution of the
   SMI/SPPI data definition languages as being done in the SMIng
   working group.

Status Update:: SMIng WG was concluded in 2003-04-04.¶

 The workshop recommended, with split consensus from the operators
   and rough consensus from the protocol developers, that the IETF
   should spend resources on fixing the MIB development and
   standardization processs.

Status Update:: The IETF dedicated some resources to fix some SNMP shortcomings with a focus on security (e.g., Transport Layer Security (TLS) Transport Model for the SNMP [RFC6353] or [RFC9456], HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 [RFC7860]).¶

Section 6 of [RFC3535] also includes the following but without tagging them as recommendations:¶

 The workshop had split consensus from the operators and rough
   consensus from the protocol developers, that the IETF should not
   focus resources on CIM extensions.

Status Update:: The IETF didn't dedicate any resources on CIM extensions.¶

 The workshop had rough consensus from the protocol developers
   that the IETF should not spend resources on COPS-PR development.
   So far, the operators have only very limited experience with
   COPS-PR.  In general, however, they felt that further development
   of COPS-PR might be a waste of resources as they assume that
   COPS-PR does not really address their requirements.

Status Update:: The IETF has reclassified COPS Usage for Policy Provisioning [RFC3084] to Historic status.¶

 The workshop had rough consensus from the protocol developers
   that the IETF should not spend resources on SPPI PIB definitions.
   The operators had rough consensus that they do not care about
   SPPI PIBs.

Status Update:: The IETF has reclassified Structure of Policy Provisioning Information [RFC3159], as well as three Policy Information Bases ([RFC3317], [RFC3318], and [RFC3571]) to Historic status.¶

5. Observations and New Requirements

5.1. On the Importance of Data Models

An appealing aspect about network automation techniques is that they almost apply to any kind of network. From that perspective, the functional component of a network automation framework that probably matters the most, and independent of the underlying interfaces and protocols, are the data models. Concretely, data models are instrumental in the automation of networks, especially that they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.¶

Data models can be used to derive required configuration information for both network and service components, and state information that will be monitored and tracked. Likewise, they can be used during the service/network management life cycle (e.g., service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance).¶

More than three decades of "Internet standardization" have shown that the specification of data models is not that straightforward. This is because of at least two major reasons:¶

For more than 30 years, legacy network equipment manufacturers have considered their technology as a competitive advantage, thereby leading to proprietary, vendor-specific, data models and the burden of vendor lock-ins. For example, there are more YANG proprietary modules than standarized ones.¶
Over the same period, operators have also developed their savoir-faire as a key competitive advantage. Such savoir-faire had to rely upon these proprietary data models. Operators were reluctant in the past to share their design and management practices.¶

The situation has changed since network "softwarization" strategies have been disclosed by vendors and operators. From a business standpoint, network "softwarization" is seen as a major transformation effort by operators, because of the flexibility and the "a la carte" approach that is promoted by "X-as-a-service" (XaaS) designs, "X" being network, platform, Network Slice, etc.¶

XaaS designs assume the availability of data models that are dynamically instantiated (along with a set of relevant policies) as a function of the "X" (and its design, for that matter). XaaS services cannot be designed, delivered, and operated without data models. Standard data models are thus key as they allow to:¶

Ease mapping among many (network/service) layers.¶
Ease data correlation from distinct sources.¶
Nullify (soften) CLI specifics to vendors.¶
Support both top-down and bottom-up approaches:¶
Accurate control loops for adaptive and deterministic service creation, delivery, and maintenance.¶
Feed an intelligence that will drive appropriate actions to adjust the current status to align with the intended status.¶

NEW-OPS-REQ-STRENGTHEN-DM:: Network softwarization can only happen with a strong, committed standardization effort, complemented by active involvement in open-source projects that facilitate access to code.¶
: Particularly, without data models, a Network API is essentially useless (see also Section 5.4).¶

5.2. Fragmented Ecosystem

The current YANG device models ecosystem is fragmented: some standards models are defined through the IETF, while similar ones are defined in other forums such as Openconfig or ONF. Unlike service and network models, IETF-defined device models are not widely implemented.¶

NEW-OPS-REQ-DM-RATIONALIZE:: There is a need to rationalize this space and avoid redundant efforts.¶

5.3. The Network Becomes Consumable

Network connectivity can support tailored services in terms of Service Level Obejctives (SLOs), for instance, by means of Network Slice Services [RFC9543]. This approach of "consuming" the network flexibly and dynamically is made possible by enabling means of exposing network capabilities to either internal or external applications. Then, network management is no longer limited to collect network status information, but it should be now extended to permit the exposure of resources, capabilities, functionality, and associated information (e.g., inventory based data).¶

NEW-OPS-REQ-EASE-EXPOSURE:: Focus on protocols and data models to expose network/service capabilities, network-wide services, and related operations.¶
NEW-OPS-REQ-NW-API-DISCOVERY:: Define a reference approach/process for service exposure discovery (APIs discovery).¶

5.4. Network APIfication

APIs are getting momentum as means of interworking between parties, also at the time of providing network services. As an example, [I-D.ramseyer-grow-peering-api] defines an API for dynamically establishing BGP peering sessions between Autonomous Systems of different administrative domains. That same objective is also covered by the YANG data model defined in [I-D.ietf-opsawg-teas-attachment-circuit] as exemplified in Appendix A.10. Tools such as YANG/OpenAPI transforms are key to leverage existing data models and allow for better integration and mapping to actual realization models.¶

NEW-OPS-REQ-DM-API:: Readily available API specifications could be generalized from YANG modules for fast development, prototyping, and validation.¶

5.5. Lack of Profiling

Many NETCONF-related features are (being) specified by the IETF, but these features are not widely supported (e.g., YANG-Push [RFC8639]).¶

NEW-OPS-REQ-PROFILING:: Editing a profile document that outlines a set of recommendations for core/key features, along with appropriate justifications, will help foster more implementations that meet operators’ needs.¶

Examples of such profile documents are the various RFCs that were published by the Behavior Engineering for Hindrance Avoidance (behave) WG [BCP127]. Another approach could be to consider a model similar to the "Roadmap for Transmission Control Protocol (TCP) Specification Documents" [RFC7414]. Such a document would serve as a guide and reference for implementers and others seeking information on 'NETCONF/RESTCONF/YANG'-related RFCs.¶

NEW-OPS-REQ-REASSESS:: Additionally, reassessing the value of some IETF proposals compared to competing or emerging solutions (e.g., gRPC vs. YANG-Push) would be beneficial.¶

5.6. Lack of Agile Process for (The Maintenance of) YANG Modules

RFCs might not be suited for documenting YANG modules (it takes much too long, especiallly for updates). In the meantime, there is a need for "reference models" and "sufficiently stable models".¶

An hybrid approach might be investigated for documenting IETF-endorsed YANG modules, such as considering an RFC to describe the initial module sketch and objectives and an official IETF repository for maintaining intermediate YANG versions.¶

By drawing a parallel between YANG data models and the concept of ontology used in the field of Semantic Web, the topic of YANG module maintenance could greatly benefit from proven methodologies in knowledge engineering such as [LOT2019] and automatic documentation tools like [Widoco2017].¶

NEW-OPS-REQ-AGILE:: Develop a more agile process for the development and maintenance of YANG modules in the IETF.¶

5.7. Integration Complexity

Section 3 of [RFC3535] describes a set of network operator requirements. One of the requirements is the ease of use which, according to Section 3.2 of [RFC6244], is addressed by NETCONF and YANG. For configuration this holds true, for network observability it is unfortunately not yet. This has been confirmed with a set of network operators asking how long it takes from subscribing YANG data to make it accessible to the operator. Minutes, Hours, Days, or Weeks. None of them answered Minutes or Hours. All of them responded Days or Weeks. Hinting manual post processing of YANG data.¶

Collecting YANG metrics from networks is already a struggle due to late arrival of [RFC8639], [RFC8640], [RFC8641], [I-D.ietf-netconf-https-notif], and [I-D.ietf-netconf-udp-notif] for configured subscription transport protocols which defined YANG-Push in the industry. This caused network vendors to implement alternative solutions to collect real-time streaming data in the meanwhile, such as gNMI which was proposed in 2018 in [I-D.openconfig-rtgwg-gnmi-spec] to the IETF but not followed up on. Unfortunately, these implementations differ between network Operating Systems due to the lack of standardization, specifically for the metadata which would ensure machine readability.¶

When a set of network operators where asked to where operational YANG data needs to be integrated to, the answer homogeneously was Apache Kafka Message Broker and Time Series Databases. There is a need to specify how YANG-Push can be integrated into Apache Kafka and references needed YANG-Push extensions and YANG schema registry development. The YANG-Push extensions addressing needs to make YANG-Push messages machine readable and against semantic validate able to ensure a consistent data processing.¶

Another challenge is that the subscribed YANG data referenced with datastore-subtree-filter or datastore-xpath-filter breaks semantic integrity which needs to be addressed by either updating Section 4 of [RFC8641] or proposing a new YANG module being used at the YANG-Push receiver.¶

NEW-OPS-REQ-INTEGRATION:: Consider approaches to ease integration by-design (e.g., protocols and data models).¶

5.8. YANG-formatted Data Manipulation

The use of a flat tree hierarchy in YANG models may induce some performance issues compared to other graph models. This can be the case, for example, during a path calculation on a network topology. Different approaches using graph theory and compatible with YANG are currently available, but require further experimentation to generalize their adoption. For instance, [ODL] implements an in-memory connected graph version of YANG-based data to enable fast breadth-first search (BFS).¶

NEW-OPS-REQ-Y2KG:: Need for a reference specification to translate YANG-based data into the knowledge graph (KG).¶

For example, [I-D.marcas-nmop-knowledge-graph-yang] and [I-D.tailhardat-nmop-incident-management-noria] discuss YANG-2-KG proposals to leverage automated reasoning and graph traversal techniques.¶

NEW-OPS-REQ-SCALE:: Consider approaches for YANG models to scale.¶

5.9. Translation and Mapping Between Service/Network and Device Models

Navigating among multiple levels of the hierarchy (service, network, device) relies currently on proprietary solutions to graft and translate between two layers. There is no programmatic approach to ensure lossless mappings.¶

NEW-OPS-REQ-LOSSLESS:: Consider programmatic approaches to ensure lossless mappings between service/network/device data models.¶

5.10. (In)Consistent Data Structures in Network Protocols for Data Export

Network Telemetry, as described in [RFC9232], involve a set of protocols. Due to the different requirements, one Network Telemetry protocol doesn't address all needs. This is mainly due to the nature of the subscribed data. BGP Monitoring Protocol (BMP) [RFC7854] adds monitoring and tracing capabilities natively to the BGP process to minimize the processing overhead. While IPFIX [RFC7011][RFC7012] can be applied according to [RFC5472] to gain visibility into the data and forwarding planes, due to the amount of data, sampling as defined in [RFC5476] and applied to IPFIX in [RFC5477] and aggregation as defined in [RFC7015] for IPFIX is needed to reduce the amount of exposed data. While YANG-Push focuses on exposing already YANG modelled data, which eases the correlation among network configuration and operational data.¶

[RFC9232] is an informational document and does not specify what these Network Telemetry protocols should have in common to ensure consistent data structures for data export. While data types are fairly good aligned, a lack of metadata standardization among the Network Telemetry protocols is observed. In particular describing from where the metrics has been exported from and timestamping. In Section 4.2 of [RFC7854] timestamps are optional and sysName [RFC1213] is only carried in the BMP initiation message (Section 4.3 of [RFC7854]), while the message header of IPFIX defined in Section 4.3 of [RFC7011] lacks the sysName definition.¶

The lack of information from where the data is being pushed from is only known to the Network Telemetry data collection due to the transport session being established from the network node exporting the information. When Network Telemetry messages are being transformed and forwarded, this information is being lost. Therefore, it is common among network operators to augment sysName and other metadata at the data collection.¶

The same common principle applies to when observation timestamping is missing in the Network Telemetry message. Since the data collection is the closest element to the network, a time stamp is added to give the network operator at least the information when the Network Telemetry message was collected. However, since Network Telemetry addresses real-time streaming needs, this is often not accurate enough for data correlation.¶

NEW-OPS-REQ-REUSABILITY:: Consider approach to ensure reuse/consistent data structure.¶

5.11. Proprietary YANG Modules, CLI, and Limited Abstraction

Leveraging on pluggins, propietary YANG models or even CLI is still the rule in many operations, sometimes forced by the need of operating legacy infrastructures.¶

The complexity of developing and maintaining these means of operation is huge, as it is required to to cover many OS and vendors along the lifetime of the network device.¶

Network models for the realization of services provide some "level" of abstraction and then automation.¶

5.12. Distinct Networks, Distinct Management Requirements

From the time [RFC3535] was released up to now, new kind of services and applications have been developed and deployed over the time, with very diverse, and some times contradicting, requirements. Those services have been engineered on top of multi-service networks for the sake of efficiency and simplicity, accommodating such a variety of needs. As a result, services requiring mobility, data replication, large capacity, adaptability, multi-path support, determinism, etc., coexist on the same shared network, needing from it mechanisms for graceful operation.¶

Likewise, such diversity of services also require different management capabilities. For example, session continuity, distribution trees, traffic engineering, congestion status notification, reordering, or on-time delivery impose very different management needs to be satisfied.¶

This reality is different from the one existing at the time of [RFC3535], and as such, the new identified needs can require from novel approaches to guarantee the aforementioned co-existence of services.¶

NEW-OPS-REQ-NEW-NEED:: Some networks have specific network management requirements such as the need for asynchronous operations or constraints on data compactness. An example of such networks is Delay-Tolerant Networking (DTN) [RFC838] or DetNet [RFC8557].¶

5.13. Implications of External Dependency

Networks are being updated to abandon the silo approach from the past towards an increasing convergence. Specifically, there are trends towards a tighter interaction and integration of different technologies previously considered as totally separated from an operational perspective. Examples of that trends are the IP and Optical integration (e.g., the introduction of colored interfaces on routers), or the extension of deterministic-behavior features to Layer 3 networks. This kind of convergence in most cases creates dependencies on the conventional network management features, which require to incorporate or integrate functionality from other technological domains.¶

Such convergence is also reflected on the need of interacting and interworking with distinct network parts participating in the end-to-end service delivery. Mobile access, fixed access, data center, enterprise, radio functional split (i.e., fronthaul and midhaul), neutral exchanges, intensive data networks (e.g., scientific academic networks), content distribution, etc., represent network parts constituent of end-to-end services that can impose dependencies of the management of an intermediate network.¶

NEW-OPS-REQ-UNSILO:: The convergence observed in recent years also implies the need for an up-to-date refresh of management capabilities and tools for conventional networks.¶
: It highlights the necessity to handle the heterogeneity of data, configuration, and network management/requirements.¶
: From a YANG perspective, this involves easily mapping and relating the data models used to manage each specific segment.¶
: Resolving such issue could draw on insights from parallel technical fields such as knowledge engineering practices and concepts associated with Linked Data in the Semantic Web, areas where it is common to manage problems of heterogeneity and data reconciliation across various application domains.¶

5.14. Too Much Time Between Publication of New Networking Functionality and the Associated YANG

For example, [RFC8667] (IS-IS extensions for SR) was published in December 2019, while [I-D.ietf-isis-sr-yang] will be published ~5 years after.¶

NEW-OPS-REQ-TIMELY-DM:: Consider having YANG as part of the protocol specification/change where possible, or have the YANG document progress in parallel. That may slow down the protocol specification, though.¶

5.15. Lack of Implementation of Proposed Solutions

New solutions proposed by WGs such as NETMOD and NETCONF very often lack an implementation or only have a partial implementation. The situation has improved with the last hackathons (e.g., for YANG-Push), but these solutions became RFCs without a known implementation:¶

YANG-Push [RFC8641]¶
Schema-mount [RFC8528]¶
NMDA [RFC8342]¶

Schema-mount allegedly has only one known implementation because of the complexity of the solution. That means the IETF most likely spent lots of cycles for something which won't be deployed ever.¶

While hackathons have improved the situation, the availablability of implementation is concerning. For open-source, 'sysrepo'/'libyang' are decent choices.¶

NEW-OPS-REQ-READILTY-IMPLEM:: It is tempting to consider mandating at least one implementation. However, there were areas which imposed in the past rules for implementations for I-Ds to be published as PS (e.g., [RFC1264]), but these rules were relaxed for reasons described, e.g., [RFC4794] and left it to the WGs to decide about the actual measures to put in place. To date, only IDR WG has clear guidance on two implementations.¶

5.16. Tooling & Skills

5.16.1. Integration with "native" IT Tooling

NEW-OPS-REQ-IT-INTEGRATION:: There is a need to ease the integration of low-level/network-oriented solution with native "IT tooling" (e.g., "https://opentelemetry.io/").¶

5.16.2. IETF Support for Better YANG Integration

NEW-OPS-REQ-IETF-TOOLS: Ease exposure of libraries and host tools (e.g., yangkit) to ease integration.¶

5.16.3. Open-source Tools

While there are open-source implementations for NETCONF (e.g., NETOPEER), the gRPC/gNMI suite seems to have more support for tools on the client side. For example, "ygot" generates structures from YANG models and these can easily be used by a client to configure a device with gNMI. NETCONF is not supported though (we need the XML tags).¶

NEW-OPS-REQ-CLIENT-TOOLS:: Focus on tooling is needed, especially on the client side.¶

5.16.4. Skills

The IETF is not the expert community in data engineering. The experts are in the data industry. Without them, integration in data processing chains like Data Mesh is going to be a challenge.¶

NEW-OPS-REQ-BRIDGE:: Create an eco-system where data and networking engineers can collaborate.¶

5.17. New Service Approaches

The virtualization trend have made posible to dynamically instantiate Service Functions (SFs) in distributed compute facilities in the form of virtual machines or containers, as micro-services. The instantiation of the SFs is governed by cloud management systems, as it is the connectivity among the different instances or micro-services. That connectivity is typically realized by using overlay mechanisms, without any further interaction with the network. However, this appraoch seems to be insuficient for future services demanding stringent requirements in terms of SLOs.¶

NEW-OPS-REQ-GLUE:: The distinct approaches followed in both the compute and the network environments makes necessary to define suitable mechanisms for enabling an efficient interplay, while highly automating the overall service delivery procedure.¶

5.18. Many Solutions for the Same Problem, but Lack of Clear Applicably Guidance

There are several solutions that were standardized for network management purposes. For example, management of ACLs by means to BGP FlowSpec [RFC8955][RFC8956] or by means of NETCONF/YANG [RFC8519]. There is no cross referencing between the two standards or delimits its applicability scope vs the other approach.¶

NEW-OPS-REQ-GUIDANCE:: The target application/applicability of a network management approach should be integrated in the specification itself.¶

8. Informative References

[BCP127]: Best Current Practice 127, <https://www.rfc-editor.org/info/bcp127>.
At the time of writing, this BCP comprises the following:

Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.

Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <https://www.rfc-editor.org/info/rfc6888>.

Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[I-D.ietf-bmwg-containerized-infra]: Ngọc, T. M., Rao, S., Lee, J., and Y. Kim, "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Work in Progress, Internet-Draft, draft-ietf-bmwg-containerized-infra-03, 4 November 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-containerized-infra-03>.
[I-D.ietf-core-comi]: Veillette, M., Van der Stok, P., Pelov, A., Bierman, A., and C. Bormann, "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-19, 3 November 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-19>.
[I-D.ietf-core-sid]: Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", Work in Progress, Internet-Draft, draft-ietf-core-sid-24, 22 December 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-24>.
[I-D.ietf-isis-sr-yang]: Litkowski, S., Qu, Y., Sarkar, P., Chen, H., and J. Tantsura, "A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane", Work in Progress, Internet-Draft, draft-ietf-isis-sr-yang-22, 1 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-isis-sr-yang-22>.
[I-D.ietf-netconf-https-notif]: Jethanandani, M. and K. Watsen, "An HTTPS-based Transport for YANG Notifications", Work in Progress, Internet-Draft, draft-ietf-netconf-https-notif-15, 1 February 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-15>.
[I-D.ietf-netconf-udp-notif]: Zheng, G., Zhou, T., Graf, T., Francois, P., Feng, A. H., and P. Lucente, "UDP-based Transport for Configured Subscriptions", Work in Progress, Internet-Draft, draft-ietf-netconf-udp-notif-16, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-16>.
[I-D.ietf-opsawg-ntw-attachment-circuit]: Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "A Network YANG Data Model for Attachment Circuits", Work in Progress, Internet-Draft, draft-ietf-opsawg-ntw-attachment-circuit-14, 7 November 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ntw-attachment-circuit-14>.
[I-D.ietf-opsawg-teas-attachment-circuit]: Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)", Work in Progress, Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-18, 7 November 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-18>.
[I-D.marcas-nmop-knowledge-graph-yang]: Martinez-Casanueva, I. D., Rodríguez, L. C., and P. Martinez-Julia, "Knowledge Graphs for YANG-based Network Management", Work in Progress, Internet-Draft, draft-marcas-nmop-knowledge-graph-yang-05, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-marcas-nmop-knowledge-graph-yang-05>.
[I-D.openconfig-rtgwg-gnmi-spec]: Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, C., and C. Morrow, "gRPC Network Management Interface (gNMI)", Work in Progress, Internet-Draft, draft-openconfig-rtgwg-gnmi-spec-01, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-openconfig-rtgwg-gnmi-spec-01>.
[I-D.ramseyer-grow-peering-api]: Aguado, C., Griswold, M., Ramseyer, J., Servin, A., and T. Strickx, "Peering API", Work in Progress, Internet-Draft, draft-ramseyer-grow-peering-api-06, 4 November 2024, <https://datatracker.ietf.org/doc/html/draft-ramseyer-grow-peering-api-06>.
[I-D.tailhardat-nmop-incident-management-noria]: Tailhardat, L., Troncy, R., and Y. Chabot, "Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design", Work in Progress, Internet-Draft, draft-tailhardat-nmop-incident-management-noria-01, 29 August 2024, <https://datatracker.ietf.org/doc/html/draft-tailhardat-nmop-incident-management-noria-01>.
[LOT2019]: Poveda-Villalon, M., Fernandez-Izquierdo, A., Fernandez-Lopez, M., and R. Garcia-Castro, "LOT: An industrial oriented ontology engineering framework", 2022, <https://doi.org/10.1016/j.engappai.2022.104755>.
[ODL]: "Graph Model Overview", 2023, <https://docs.opendaylight.org/projects/bgpcep/en/latest/graph/graph-user-guide-graph-model.html#>.
[RFC1213]: McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, <https://www.rfc-editor.org/rfc/rfc1213>.
[RFC1264]: Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, DOI 10.17487/RFC1264, October 1991, <https://www.rfc-editor.org/rfc/rfc1264>.
[RFC3084]: Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, DOI 10.17487/RFC3084, March 2001, <https://www.rfc-editor.org/rfc/rfc3084>.
[RFC3159]: McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, DOI 10.17487/RFC3159, August 2001, <https://www.rfc-editor.org/rfc/rfc3159>.
[RFC3317]: Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, "Differentiated Services Quality of Service Policy Information Base", RFC 3317, DOI 10.17487/RFC3317, March 2003, <https://www.rfc-editor.org/rfc/rfc3317>.
[RFC3318]: Sahita, R., Ed., Hahn, S., Chan, K., and K. McCloghrie, "Framework Policy Information Base", RFC 3318, DOI 10.17487/RFC3318, March 2003, <https://www.rfc-editor.org/rfc/rfc3318>.
[RFC3535]: Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May 2003, <https://www.rfc-editor.org/rfc/rfc3535>.
[RFC3571]: Rawlins, D., Kulkarni, A., Ho Chan, K., Bokaemper, M., and D. Dutt, "Framework Policy Information Base for Usage Feedback", RFC 3571, DOI 10.17487/RFC3571, August 2003, <https://www.rfc-editor.org/rfc/rfc3571>.
[RFC4794]: Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, DOI 10.17487/RFC4794, December 2006, <https://www.rfc-editor.org/rfc/rfc4794>.
[RFC5345]: Schoenwaelder, J., "Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats", RFC 5345, DOI 10.17487/RFC5345, October 2008, <https://www.rfc-editor.org/rfc/rfc5345>.
[RFC5472]: Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, DOI 10.17487/RFC5472, March 2009, <https://www.rfc-editor.org/rfc/rfc5472>.
[RFC5476]: Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, March 2009, <https://www.rfc-editor.org/rfc/rfc5476>.
[RFC5477]: Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, <https://www.rfc-editor.org/rfc/rfc5477>.
[RFC5706]: Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/rfc/rfc5706>.
[RFC6020]: Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/rfc/rfc6020>.
[RFC6241]: Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/rfc/rfc6241>.
[RFC6244]: Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 2011, <https://www.rfc-editor.org/rfc/rfc6244>.
[RFC6353]: Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <https://www.rfc-editor.org/rfc/rfc6353>.
[RFC6632]: Ersue, M., Ed. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, DOI 10.17487/RFC6632, June 2012, <https://www.rfc-editor.org/rfc/rfc6632>.
[RFC7011]: Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7012]: Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/rfc/rfc7012>.
[RFC7015]: Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, DOI 10.17487/RFC7015, September 2013, <https://www.rfc-editor.org/rfc/rfc7015>.
[RFC7149]: Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/rfc/rfc7149>.
[RFC7414]: Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/rfc/rfc7414>.
[RFC7426]: Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/rfc/rfc7426>.
[RFC7854]: Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/rfc/rfc7854>.
[RFC7860]: Merkle, J., Ed. and M. Lochter, "HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3", RFC 7860, DOI 10.17487/RFC7860, April 2016, <https://www.rfc-editor.org/rfc/rfc7860>.
[RFC7950]: Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/rfc/rfc7950>.
[RFC7951]: Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/rfc/rfc7951>.
[RFC8040]: Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8199]: Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/rfc/rfc8199>.
[RFC8299]: Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/rfc/rfc8299>.
[RFC8309]: Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/rfc/rfc8309>.
[RFC8341]: Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/rfc/rfc8341>.
[RFC8342]: Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/rfc/rfc8342>.
[RFC838]: Smallberg, D., "Who talks TCP?", RFC 838, DOI 10.17487/RFC0838, January 1983, <https://www.rfc-editor.org/rfc/rfc838>.
[RFC8466]: Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/rfc/rfc8466>.
[RFC8519]: Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/rfc/rfc8519>.
[RFC8528]: Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/rfc/rfc8528>.
[RFC8557]: Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, <https://www.rfc-editor.org/rfc/rfc8557>.
[RFC8568]: Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., Aranda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, <https://www.rfc-editor.org/rfc/rfc8568>.
[RFC8639]: Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/rfc/rfc8639>.
[RFC8640]: Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Dynamic Subscription to YANG Events and Datastores over NETCONF", RFC 8640, DOI 10.17487/RFC8640, September 2019, <https://www.rfc-editor.org/rfc/rfc8640>.
[RFC8641]: Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.
[RFC8667]: Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/rfc/rfc8667>.
[RFC8791]: Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/rfc/rfc8791>.
[RFC8955]: Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/rfc/rfc8955>.
[RFC8956]: Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/rfc/rfc8956>.
[RFC8969]: Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, <https://www.rfc-editor.org/rfc/rfc8969>.
[RFC9132]: Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, September 2021, <https://www.rfc-editor.org/rfc/rfc9132>.
[RFC9144]: Clemm, A., Qu, Y., Tantsura, J., and A. Bierman, "Comparison of Network Management Datastore Architecture (NMDA) Datastores", RFC 9144, DOI 10.17487/RFC9144, December 2021, <https://www.rfc-editor.org/rfc/rfc9144>.
[RFC9182]: Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, <https://www.rfc-editor.org/rfc/rfc9182>.
[RFC9232]: Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, <https://www.rfc-editor.org/rfc/rfc9232>.
[RFC9254]: Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, C., and M. Richardson, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)", RFC 9254, DOI 10.17487/RFC9254, July 2022, <https://www.rfc-editor.org/rfc/rfc9254>.
[RFC9291]: Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, <https://www.rfc-editor.org/rfc/rfc9291>.
[RFC9315]: Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/rfc/rfc9315>.
[RFC9456]: Vaughn, K., Ed., "Updates to the TLS Transport Model for SNMP", RFC 9456, DOI 10.17487/RFC9456, November 2023, <https://www.rfc-editor.org/rfc/rfc9456>.
[RFC9543]: Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, <https://www.rfc-editor.org/rfc/rfc9543>.
[Widoco2017]: Garijo, D., "WIDOCO: a wizard for documenting ontologies", 2017, <http://dgarijo.com/papers/widoco-iswc2017.pdf>.