ONSEN Problem Statement
draft-kbf-onsen-problem-statement-01

ONSEN Working Group                                           S. Barguil
Internet-Draft                                                     Nokia
Intended status: Informational                             K. Lambrechts
Expires: 2 May 2027                                              Intwine
                                                                  C. Xie
                                                           China Telecom
                                                         29 October 2026

                        ONSEN Problem Statement
                draft-kbf-onsen-problem-statement-01

Abstract

   The IETF has published a number of YANG data models for automating
   the provisioning and delivery of network and connectivity services,
   including the L2SM, L3SM, L2NM, L3NM, Attachment Circuits, and
   Network Slicing models.  These models are intended to provided
   abstracted representations of common operator services, exposing only
   the necessary parameters for configuring and managing services.
   These abstractions help to contain the complexity of service
   provisioning within the necessary domains, making the implementation
   of complex, multi-domain services easier to implement and manage.

   However, operators have reported persistent challenges in
   operationalizing these abstractions in a consistent, scalable, and
   automatable manner.  This document describes the problem space for
   the ONSEN Working Group, identifying the operational gaps and
   deficiencies in existing IETF service and network abstraction models
   that complicate, or prevent effective end-to-end automation.  The
   problems documented here are initially drawn from operator
   experience, and from the findings of the IAB NEMOPS Workshop.

   It is a living draft, not intended for publication as an RFC, and
   will be updated with new problem descriptions as the ONSEN work
   proceeds.  This document does not propose solutions, protocols, or
   new data models.

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://sbarguil.github.io/ONSEN_Problem_Statement/draft-kbf-onsen-
   problem-statement.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-kbf-onsen-problem-
   statement/.

Barguil, et al.            Expires 2 May 2027                   [Page 1]
Internet-Draft           ONSEN Problem Statement            October 2026

   Discussion of this document takes place on the ONSEN Working Group
   mailing list (mailto:onsen@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/onsen/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/onsen/.

   Source for this draft and an issue tracker can be found at
   https://github.com/sbarguil/ONSEN_Problem_Statement.

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 2 May 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  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 . . . . . . . . . . . . . . . . .   4
   3.  Problem Area Qualification Criteria . . . . . . . . . . . . .   5
   4.  Missing LxSM and LxNM Functionality . . . . . . . . . . . . .   5
     4.1.  LxNM Updates  . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  On-Demand and Scheduled Service Operations  . . . . . . .   6
   5.  Structural LxNM/LxSM Problems . . . . . . . . . . . . . . . .   6

Barguil, et al.            Expires 2 May 2027                   [Page 2]
Internet-Draft           ONSEN Problem Statement            October 2026

   6.  Limited Observability and Service Assurance . . . . . . . . .   7
   7.  OSS/BSS Interface and API Interoperability  . . . . . . . . .   7
     7.1.  Northbound API Semantics  . . . . . . . . . . . . . . . .   7
     7.2.  TMF API-Based Semantics . . . . . . . . . . . . . . . . .   8
   8.  Insufficient Guidance for Implementing YANG-based
           Orchestration . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Other Southbound Management Interfaces  . . . . . . . . .   9
   9.  Items for Future Study  . . . . . . . . . . . . . . . . . . .   9
     9.1.  Quantum-Security Requirements in Service Models . . . . .   9
     9.2.  Secure Handling of Secrets in Orchestration Workflows . .   9
     9.3.  Generic Abstraction-to-Underlay Mapping . . . . . . . . .  10
     9.4.  Absence of Reusable Service Configuration Constructs  . .  10
     9.5.  Abstractions for Telco-Cloud Scenarios  . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   12. Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The IETF has published several YANG data models that are intended for
   automating the provisioning and management of service provider
   connectivity services.  These include models such as L3SM [RFC8299],
   L3NM [RFC9182], L2SM [RFC8466], L2NM [RFC9291] and Service Attachment
   Points (SAPs) [RFC9408].  A new YANG model for the Network Slice
   Service [RFC9543], is currently being authored:
   [I-D.ietf-teas-ietf-network-slice-nbi-yang].

   While some of these abstractions have been deployed, operators report
   persistent challenges in operationalizing them.  As highlighted by
   the IAB NEMOPS Workshop [NEMOPS], these challenges are systemic and
   operational in nature.  They are not confined to a specific
   technology or service type, but reoccur across abstraction domains
   and deployment environments.

   In addition, despite the availability of numerous YANG data models -
   covering configuration, assurance, and fault management - and the
   ongoing effort to make these models coexist within a common framework
   under the IETF umbrella, operators continue to face significant
   challenges in operationalizing YANG-based service APIs in a
   consistent, scalable, and interoperable manner.  While models such as
   the L3SM, L2SM, L3NM, L2NM, AC/SAP abstractions and Network Slice
   Service each address specific aspects of service delivery, it is not
   always clear which models should be used together, in which
   scenarios, or to what extent a given implementation actually supports
   the full model.  The usage of these APIs remains fragmented - often
   partially implemented - and difficult to automate end-to-end.  In
   practice, APIs generated from similar YANG models often differ in

Barguil, et al.            Expires 2 May 2027                   [Page 3]
Internet-Draft           ONSEN Problem Statement            October 2026

   service semantics, and the lack of clear guidance on model
   composition and interoperability complicates integration across
   systems, vendors, and deployment environments.

   The Operationalizing Network and SErvice abstractioNs (ONSEN) Working
   Group is chartered to address this problem space by focusing on the
   operational aspects of network and service abstractions.  It aims to
   make it easier to implement and use the IETF's service and network
   abstractions, with the goal of improving network automation,
   operational efficiency, and interoperability.

   This document defines the problem space for ONSEN.  It does not
   propose solutions, protocols, or new data models.

2.  Conventions and Definitions

   The following terms are used in this document:

   AC:  Attachment Circuit

   Abstraction:  The process of defining simplified, high-level
      constructs that represent network and service-level capabilities,
      while hiding the details of their underlying realization.
      Abstraction enables interaction between management and automation
      systems without requiring direct exposure of device-specific
      configurations or protocol behaviors.

   BSS:  Business Support System

   LxNM:  Layer x Network Model (L2NM or L3NM)

   LxSM:  Layer x Service Model (L2SM or L3SM)

   NEMOPS:  Next Era of Network Management Operations

   ONSEN:  Operationalizing Network and SErvice abstractioNs

   OSS:  Operation Support System

   SLO:  Service Level Objective

   Service Model Intent:  The desired service behavior expressed by an
      operator through a service model (LxSM), as described in
      [RFC8309].  This refers to the set of customer requirements —
      connectivity, performance, availability — submitted to the
      orchestration layer and expected to be maintained by the network
      over time.  When this document uses the term "service intent", it
      refers to Service Model Intent in this sense.

Barguil, et al.            Expires 2 May 2027                   [Page 4]
Internet-Draft           ONSEN Problem Statement            October 2026

3.  Problem Area Qualification Criteria

   The ONSEN problem space has been divided into five main areas.  These
   areas were chosen to enable work in each area to advance
   independently as much as possible.

   *  Missing LxSM and LxNM functionality: Minor omissions or extensions
      to the existing LxNM and LxSM models that can be resolved with
      backward-compatible updates.

   *  Structural LxNM/LxSM Problems: More significant structural
      problems with the LxNM and/or LxSM models that may require deeper
      changes.

   *  Limited observability and service assurance: Absence of a
      standardized approach and the relevant model constructs for
      reporting operational state and service health.

   *  OSS/BSS interface and API interoperability: Problems related to
      the interworking between YANG-based service models and the
      northbound APIs exposed by orchestrators toward OSS/BSS systems.

   *  Insufficient guidance for YANG-based orchestration: Problems
      arising from the lack of concrete guidance or examples on how to
      deploy and combine the LxNM and LxSM models in practice.

   Finally, the Items for Future Study section captures problem areas
   that are recognized by the WG but are not sufficiently developed or
   prioritized for inclusion in the current work.

4.  Missing LxSM and LxNM Functionality

   Operators who use the LxSM and LxNM models in real-world deployments
   report that the models do not provide the constructs needed to
   express the full range of service behaviors and operational
   requirements.  This sections lists a number of YANG backward
   compatible enhancements to these models.

4.1.  LxNM Updates

   The operator-driven LxNM updates effort [LxNM-Updates] captures
   concrete update requests and implementation feedback.

Barguil, et al.            Expires 2 May 2027                   [Page 5]
Internet-Draft           ONSEN Problem Statement            October 2026

4.2.  On-Demand and Scheduled Service Operations

   Existing YANG service and network models are primarily designed for
   static, long-lived services.  They do not provide the constructs
   needed to express service behaviors that vary over time, are
   triggered on demand, or follow a defined schedule.  As operators
   introduce services such as data-intensive workload transmission or
   SD-WAN-like dynamic VPN capabilities, this gap becomes a concrete
   operational blocker.

   [RFC9922] defines a generic model for scheduling that could be bound
   to LxSM service instances.  ONSEN can leverage this model to define
   how dynamic scheduling can be applied to the LxSM service models.

5.  Structural LxNM/LxSM Problems

   Both during the NEMOPS workshop and as part of the ONSEN working
   group forming BoF session, operators have reported various
   difficulties which they experienced in implementing and using these
   models.

   The RFC 8969 framework [RFC8969] proposes a hierarchical three-layer
   approach: Service, Network, and Device, intended to promote
   reusability and prevent feature duplication across management layers.
   Operators who followed this hierarchical approach and elected to
   deploy both LxSM and LxNM together did so in alignment with that
   architecture.  They report challenges in integrating the two models
   effectively, due to differences in parameter naming, data types, and
   the lack of guidance on integration logic.

   In the absence of standardized integration guidance, operators have
   resolved these challenges by implementing bespoke adaptation logic
   outside the abstraction framework.  The consequence is that each such
   deployment produces a custom, closed integration layer that is
   tightly coupled to a specific vendor stack or orchestrator
   implementation.  These solutions are difficult to share, extend, or
   migrate, and reproduce the same integration effort across independent
   deployments.

   Some operators report difficulties in selecting the relevant service
   model(s) for a given deployment scenario, and in applying them in
   real-world deployments.  The L2SM [RFC8466], L3SM [RFC8299], ACaaS
   [RFC9834], and NSS [I-D.ietf-teas-ietf-network-slice-nbi-yang] all
   define service abstractions at a similar level in adjacent domains.
   Insufficient guidance exists on how to effectively use and compose
   these service models in practice.

Barguil, et al.            Expires 2 May 2027                   [Page 6]
Internet-Draft           ONSEN Problem Statement            October 2026

   Overall, the working group would benefit from collecting operator's
   concrete implementation experiences and best practices arround the
   LxNM and LxSM models, both successful and unsuccessful.  Other
   operators can learn from these experiences, and the working group can
   assess whether structural (e.g., non-backward compatible) changes to
   the models are warranted.

6.  Limited Observability and Service Assurance

   Existing service and network models focus on configuration and
   provide no standardised mechanism for reporting whether a service is
   being delivered as ordered.  This gap applies both to discrete
   operational state — whether the service is up and fault-free at a
   given moment — and to historical SLO compliance — whether the service
   has met its contracted performance targets over a given period.

   SAIN ([RFC9417], [RFC9418]) addresses observability internally within
   the provider domain through an assurance graph that enables operators
   to troubleshoot outages.  It is not designed to be exposed to
   customers or to the service model layer.  SAIN can contribute through
   a feedback loop from the SAIN Controller to the Service Orchestrator,
   which would then populate relevant state in LxSM/LxNM; however, that
   interworking is not currently defined.

   [RFC9375] provides raw performance monitoring data but does not
   include a model for expressing the outcome of evaluating that data
   against the SLOs set in the service model.

   The gap is a customer-facing service delivery reporting layer that
   does not currently exist in LxSM or LxNM.

7.  OSS/BSS Interface and API Interoperability

   YANG data models are commonly used as the basis for APIs that expose
   service abstractions to external systems.  However, existing work
   provides limited guidance on how these abstractions should be
   exposed, versioned, or consumed in a predictable and interoperable
   manner.

7.1.  Northbound API Semantics

   Orchestration and controller systems have widely adopted YANG as a
   schema language, but a lack of equivalent standards for API semantics
   on orchestrator northbound APIs has resulted in divergent
   implementations and interoperability challenges.

Barguil, et al.            Expires 2 May 2027                   [Page 7]
Internet-Draft           ONSEN Problem Statement            October 2026

   Standardized semantics for service creation, modification, and
   decommissioning would simplify the implementation of orchestrators
   and controllers, and enable better interoperability across vendors
   and deployments.

7.2.  TMF API-Based Semantics

   Some operators use [TMF640]/[TMF641] as the northbound API for
   service ordering from their BSS.  There is no specification of how
   these interfaces can be aligned with YANG service and network models.
   Operators must either pay commercial OSS/BSS vendors to build bespoke
   interfaces or build and maintain their own adaptation layer.  The
   absence of a defined API creates integration complexity, lack of re-
   useability, vendor lock-in risk, and inconsistent implementations
   across deployments.

8.  Insufficient Guidance for Implementing YANG-based Orchestration

   With the YANG Data Store [RFC7950] and the NMDA architecture
   [RFC8342] the IETF has standardized a clear operational model for
   exposing configuration and operational state from an individual
   NETCONF/RESTCONF server.

   YANG has since gained widespread adoption as a schema language for
   describing the data model at varous abstraction layers, above the
   network devices themselves.  In other words, YANG is increasingly
   used to define the schemas for OSS systems, orchestrators, and
   controllers.  A prime example are the IETF LxSM and LxNM models.

   A variety of Informational RFCs, including The YANG Module
   Classification [RFC8199], Service Models Explained [RFC8309], and A
   Framework for Automating Service and Network Management with YANG
   [RFC8969] have advanced the classification of, and relationships
   between YANG modules as well as the software components that
   implement them.

   Operators consistently report they require more precise guidelines,
   and a much more concrete service stack.  This includes a requirement
   for clear guidelines on how and when to combine IETF standardized
   models with vendor models and user models at each layer.  Further
   guidance is needed on the interactions between the Service and
   Network Models.  Previous IETF work has attempted to define an exact
   mapping between these layers, which was determined to be impractical,
   yet guidance on how to manage these interactions is still needed.

Barguil, et al.            Expires 2 May 2027                   [Page 8]
Internet-Draft           ONSEN Problem Statement            October 2026

8.1.  Other Southbound Management Interfaces

   Operators depend on a heterogeneous mix of network devices, and
   network controllers, some of which are YANG model-driven, and others
   that are not.  Vendor-specific APIs, and legacy management mechanisms
   such as CLI and SNMP remain prevalent.  A mix of these interfaces is
   common even within a single deployment.

   Operators require a standardized approach to integrating non-YANG
   modeled devices into YANG-model driven orchestration systems.  This
   includes the ability to apply a YANG-modeled intent to non-NETCONF/
   RESTCONF devices, and to collect telemetry data from non-YANG modeled
   devices in a way that can be correlated with YANG modeled service
   state and performance data.

9.  Items for Future Study

   The following problem areas were raised during the IETF126 ONSEN work
   group meeting and subsequent mailing list exchanges.  They are
   currently insufficiently developed or prioritised for inclusion in
   the core problem statement.  They are documented here for
   completeness and to solicit community input on whether and how they
   should be addressed by ONSEN or other working groups.

9.1.  Quantum-Security Requirements in Service Models

   An increasing number of customers require long-term data
   confidentiality and protection against future quantum-computing
   threats.  Current service models do not provide a way to express
   quantum-security requirements or capabilities.  It is not yet clear
   whether this is best addressed through extensions to existing models
   or through new model constructs.  This item is considered lower
   priority relative to the core problems above and may be revisited in
   a later revision.

9.2.  Secure Handling of Secrets in Orchestration Workflows

   Device-level configuration often requires credentials, authentication
   keys, or other sensitive data.  There is currently no standardised
   mechanism for referencing sensitive information securely across the
   orchestration stack and resolving it only at the point of device
   configuration.  Whether this belongs within the scope of ONSEN,
   NETMOD, or another WG is an open question that requires further
   discussion.

Barguil, et al.            Expires 2 May 2027                   [Page 9]
Internet-Draft           ONSEN Problem Statement            October 2026

9.3.  Generic Abstraction-to-Underlay Mapping

   Operators repeatedly encounter the challenge of mapping service-layer
   abstractions to underlying infrastructure resources in a generic,
   technology-independent way.  Existing work addresses this problem in
   specific contexts (e.g., TE-based approaches in TEAS) but no broadly
   applicable mechanism exists.  The ONSEN charter defines the device
   layer as the lowest layer in scope; mapping below the device layer is
   therefore out of scope.  Further information from the community on
   the exact problem being identified is needed before this item can be
   evaluated for inclusion.

9.4.  Absence of Reusable Service Configuration Constructs

   The LxSM models do not provide templates or reusable constructs to
   aid operators in reducing the input parameters required for common
   site deployment patterns.  Operators must manually configure each
   service instance, which increases the risk of misconfiguration and
   reduces operational efficiency.

   YANG Configuration Templates [I-D.tt-netmod-yang-config-templates],
   being worked on in NETMOD already provide a generic solution that
   addresses repetitive YANG configuration instances.

9.5.  Abstractions for Telco-Cloud Scenarios

   Cloud-native networking and distributed cloud infrastructure are
   reshaping how telecommunication services are deployed and operated.
   Telco-Cloud environments span central data centers, edge sites, and
   far-edge locations, and combine networking, compute, storage, and
   application resources.

   Emerging services require placement decisions that jointly consider
   network and compute characteristics, but current workflows often
   depend on multiple cloud managers, network controllers, monitoring
   systems, and inventory repositories.  This complexity can slow
   admission control and service instantiation.  Better abstractions can
   provide a consistent view of infrastructure capabilities so
   orchestration systems can make faster decisions without exposing
   implementation detail.

10.  IANA Considerations

   This memo includes no request to IANA.

Barguil, et al.            Expires 2 May 2027                  [Page 10]
Internet-Draft           ONSEN Problem Statement            October 2026

11.  Security Considerations

   TODO

12.  Informative References

   [I-D.ietf-teas-ietf-network-slice-nbi-yang]
              Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
              "A YANG Data Model for the RFC 9543 Network Slice
              Service", Work in Progress, Internet-Draft, draft-ietf-
              teas-ietf-network-slice-nbi-yang-26, 26 May 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slice-nbi-yang-26>.

   [I-D.tt-netmod-yang-config-templates]
              Watsen, K., Ma, Q., and D. Rajaram, "YANG Configuration
              Templates", Work in Progress, Internet-Draft, draft-tt-
              netmod-yang-config-templates-04, 22 September 2026,
              <https://datatracker.ietf.org/doc/html/draft-tt-netmod-
              yang-config-templates-04>.

   [LxNM-Updates]
              LxNM-Updates Contributors, "LxNM-Updates", n.d.,
              <https://github.com/sbarguil/LxNM-Updates>.

   [NEMOPS]   "IAB Workshop Report: Next Era of Network Management
              Operations (NEMOPS)", n.d.,
              <https://datatracker.ietf.org/doc/draft-ietf-nemops-
              workshop-report/>.

   [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>.

   [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>.

Barguil, et al.            Expires 2 May 2027                  [Page 11]
Internet-Draft           ONSEN Problem Statement            October 2026

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [RFC9375]  Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Ed., Gonzalez de
              Dios, O., and B. Wen, "A YANG Data Model for Network and
              VPN Service Performance Monitoring", RFC 9375,
              DOI 10.17487/RFC9375, April 2023,
              <https://www.rfc-editor.org/rfc/rfc9375>.

   [RFC9408]  Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu,
              Q., and V. Lopez, "A YANG Network Data Model for Service
              Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408,
              June 2023, <https://www.rfc-editor.org/rfc/rfc9408>.

   [RFC9417]  Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
              Arumugam, "Service Assurance for Intent-Based Networking
              Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,
              <https://www.rfc-editor.org/rfc/rfc9417>.

   [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>.

Barguil, et al.            Expires 2 May 2027                  [Page 12]
Internet-Draft           ONSEN Problem Statement            October 2026

   [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>.

   [RFC9834]  Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios,
              O., Barguil, S., and B. Wu, "YANG Data Models for Bearers
              and Attachment Circuits as a Service (ACaaS)", RFC 9834,
              DOI 10.17487/RFC9834, September 2025,
              <https://www.rfc-editor.org/rfc/rfc9834>.

   [RFC9922]  Ma, Q., Ed., Wu, Q., Boucadair, M., Ed., and D. King, "A
              Common YANG Data Model for Scheduling", RFC 9922,
              DOI 10.17487/RFC9922, March 2026,
              <https://www.rfc-editor.org/rfc/rfc9922>.

   [TMF640]   TM Forum, "TMF640 Service Activation and Configuration API
              User Guide v4.0.1", n.d.,
              <https://www.tmforum.org/resources/specifications/tmf640-
              service-activation-and-configuration-api-user-guide-
              v4-0/>.

   [TMF641]   TM Forum, "TMF641 Service Ordering Management API User
              Guide v4.1.1", n.d.,
              <https://www.tmforum.org/resources/specifications/tmf641-
              service-ordering-management-api-user-guide-v4-1-1/>.

Authors' Addresses

   Samier Barguil
   Nokia
   Email: samier.barguil@nokia.com

   Kris Lambrechts
   Intwine
   Email: kris@intwine.net

   Chongfeng Xie
   China Telecom
   Email: xiechf@chinatelecom.cn

Barguil, et al.            Expires 2 May 2027                  [Page 13]