Maxim,
Your two topics raise very good questions.
1) The motivation is provided in section
GB922 Common section 3.81. Configuration complexity can be reduced through reuse of common patterns. These are modeled within the Configuration and Profiling ABE. The controversial statement here is:
It is envisioned that SID implementers will begin to use the Service Configuration ABE as an alternative to Resource Facing Service Specification and Resource Facing Service ABEs.
I support the requirement for ConfigurationSpecification/Configuration as first class (addressable) entities in order to fully realize
Configuration Management (CM). The capabilities defined here provide not only configurations which are reusable across instances but introduce
Declarative configuration. Another important concept here is that
Entity instances may play the role of
ConfigurationSpecification which allows dynamically assigned values to be used to configure other
Entities.
In
IG1174 Model-Driven Design of Management Interfaces for ODA Components these concepts are described in the context of ODA Components (software). See section 5.2.1 for a description of
intent-based configuration management.
I raised just this issue last week in a discussion about
Intent Management in Autonomous Networks (
IG1253). My assertion is that we have a progression of configuration capabilities:
Explicit -> Declarative -> Intent. We never realized in Open APIs the ZOOM and SID work on
Declarative configuration. Now we are gung-ho to get an
Intent Management API (TMF921). My assumption is that
Intent is a superset of
Declarative so we should really have that first. I've had it on my TODO list for almost two years now to work on (Resource,Service,Product?)
Configuration Management APIs, it seems it's high time. Want to help?
2) As far as I see it we should have a
Product Activation API to apply the pattern uniformly.
------------------------------
Vance Shipley
SigScale
------------------------------
Original Message:
Sent: Aug 12, 2021 08:24
From: Maxim Sedov
Subject: Product Activation and Configuration in Open API (TMF640?)
Hi,
Please help me to clarify two topics
1) SID defines several related entities (section 3.8 of GB922 Common):
- Configuration/ConfigurationSpecification
- ProductConfiguration/ProductConfigSpec
- ServiceConfiguration/ServiceConfigSpec
- ResourceConfiguration/ResourceConfigSpec
Here is the picture from SID:
It does not look like any Open API's use it. These entities are internal for Customer/Service/Resource Order Management, aren't they? Why would TMForum bothers for such internal implementation details?
2) In some simple cases (digital or "virtual" products) it makes sence to "activate" ordered product directly on a paltform (SDP) from BSS. In this case standard path (product -> CFS -> RFS -> Resource) looks too overloaded. Standard path implies using Product/Service Catalogs and Customer/Service/Resource Order Management systems. I would like to call Platform directly from Customer Order Management (at Procut Order level). However Service Activation and Configuration API (TMF640) works only at Service level. Would it be an issue? From the other hand for non-telecom (digital or "virtual") products it makes sence using other industries specific standards like OSB and etc... What the community recommends for product activation?
p.s. Also SID gives reference to document "Configuration and Profiling Business Agreement, Version 1.1.2.", but I did not find it. I would appreciate if somebody gives a link to it.
------------------------------
Maxim Sedov
Mobile TeleSystems OJSC
------------------------------