Open APIs

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hi,

I didn't think TMF645 keep intent implicit. I thought it just doesn't care.

Its job (assuming POST Check) is just to tell you if SSpec A is technically activable (for instance at the customer's location).

Would you mind to share examples where intent/action would influence how SQM computation perform?

I also would not infer behaviour from these 2 APIs, 641 and 645. They are very different.

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hi,

I didn't think TMF645 keep intent implicit. I thought it just doesn't care.

Its job (assuming POST Check) is just to tell you if SSpec A is technically activable (for instance at the customer's location).

Would you mind to share examples where intent/action would influence how SQM computation perform?

I also would not infer behaviour from these 2 APIs, 641 and 645. They are very different.

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

In our case, it's POCV that will do these validation.

it will have a workflow to go through validations and one of them is to orchestrate TMF645 to check if it's technically feasible to activate 600 mbps at this specific fiber termination point (place id). Checking if there is already an active customer, if it's an upgrade, a move it's for POCV to do all all the validations, technical, commercial, planning etc. I would rather not delegate some of them to SQM.

in our implementation, we have a small homemade POCV responsible for orchestrating eligibility services. We do use a "action code" to "help" POCV make the right decisions. POCV is like the "conductor" in an orchestra  and it decides which musician (API) is needed, what notes it will play (API POST request) and when it is needed.

But I would not think adding this action code in TMF645 would be useful.

example: If customer is already on 500 mbps POCV will not call 645 to check if customer can have 600 Mbps because we already know it does. 

Hi,

I didn't think TMF645 keep intent implicit. I thought it just doesn't care.

Its job (assuming POST Check) is just to tell you if SSpec A is technically activable (for instance at the customer's location).

Would you mind to share examples where intent/action would influence how SQM computation perform?

I also would not infer behaviour from these 2 APIs, 641 and 645. They are very different.

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

------------------------------
Furooshin Firoz
TO BE VERIFIED

Original Message:
Sent: Dec 09, 2025 08:51
From: Matthieu Hattab
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

In our case, it's POCV that will do these validation.

it will have a workflow to go through validations and one of them is to orchestrate TMF645 to check if it's technically feasible to activate 600 mbps at this specific fiber termination point (place id). Checking if there is already an active customer, if it's an upgrade, a move it's for POCV to do all all the validations, technical, commercial, planning etc. I would rather not delegate some of them to SQM.

in our implementation, we have a small homemade POCV responsible for orchestrating eligibility services. We do use a "action code" to "help" POCV make the right decisions. POCV is like the "conductor" in an orchestra  and it decides which musician (API) is needed, what notes it will play (API POST request) and when it is needed.

But I would not think adding this action code in TMF645 would be useful.

example: If customer is already on 500 mbps POCV will not call 645 to check if customer can have 600 Mbps because we already know it does. 

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales, Core Commerce Domain Architect
Ex-Lyse Tele, Open to Work

Original Message:
Sent: Dec 09, 2025 07:24
From: Furooshin Firoz
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

------------------------------
Furooshin Firoz
TO BE VERIFIED

Original Message:
Sent: Dec 09, 2025 06:54
From: Matthieu Hattab
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

Hi,

I didn't think TMF645 keep intent implicit. I thought it just doesn't care.

Its job (assuming POST Check) is just to tell you if SSpec A is technically activable (for instance at the customer's location).

Would you mind to share examples where intent/action would influence how SQM computation perform?

I also would not infer behaviour from these 2 APIs, 641 and 645. They are very different.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales, Core Commerce Domain Architect
Ex-Lyse Tele, Open to Work

Original Message:
Sent: Dec 09, 2025 03:37
From: Furooshin Firoz
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

------------------------------
Furooshin Firoz
TO BE VERIFIED

Original Message:
Sent: Dec 08, 2025 06:40
From: Jiri Smekal
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hello everyone.

I do understand the role of POCV - it is focused on capturing the product order request and validating it (technical, commercial, planning checks). My assumption is that once POCV has completed its work, the control is handed over to TMFC003 Product Order Delivery Orchestration and Management (PODO), which then interprets the intent (new service, upgrade, cease) and orchestrates the delivery, including decomposition into service orders.

I just want to ask and confirm that I understand correctly:

• The orchestrator responsible for creating the service order (API TMF641) is the PODO component.

• And this means that the mechanism for decomposing the product specification into CFS services is indeed part of this component.

------------------------------
Jan Brnka
T-Mobile Czech & Slovak Telekom, a.s.

Original Message:
Sent: Dec 09, 2025 09:22
From: Furooshin Firoz
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

------------------------------
Furooshin Firoz
TO BE VERIFIED

Original Message:
Sent: Dec 09, 2025 08:51
From: Matthieu Hattab
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

In our case, it's POCV that will do these validation.

it will have a workflow to go through validations and one of them is to orchestrate TMF645 to check if it's technically feasible to activate 600 mbps at this specific fiber termination point (place id). Checking if there is already an active customer, if it's an upgrade, a move it's for POCV to do all all the validations, technical, commercial, planning etc. I would rather not delegate some of them to SQM.

in our implementation, we have a small homemade POCV responsible for orchestrating eligibility services. We do use a "action code" to "help" POCV make the right decisions. POCV is like the "conductor" in an orchestra  and it decides which musician (API) is needed, what notes it will play (API POST request) and when it is needed.

But I would not think adding this action code in TMF645 would be useful.

example: If customer is already on 500 mbps POCV will not call 645 to check if customer can have 600 Mbps because we already know it does. 

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales, Core Commerce Domain Architect
Ex-Lyse Tele, Open to Work

Original Message:
Sent: Dec 09, 2025 07:24
From: Furooshin Firoz
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

------------------------------
Furooshin Firoz
TO BE VERIFIED

Original Message:
Sent: Dec 09, 2025 06:54
From: Matthieu Hattab
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

Hi,

I didn't think TMF645 keep intent implicit. I thought it just doesn't care.

Its job (assuming POST Check) is just to tell you if SSpec A is technically activable (for instance at the customer's location).

Would you mind to share examples where intent/action would influence how SQM computation perform?

I also would not infer behaviour from these 2 APIs, 641 and 645. They are very different.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales, Core Commerce Domain Architect
Ex-Lyse Tele, Open to Work

Original Message:
Sent: Dec 09, 2025 03:37
From: Furooshin Firoz
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

------------------------------
Furooshin Firoz
TO BE VERIFIED

Original Message:
Sent: Dec 08, 2025 06:40
From: Jiri Smekal
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------

The documention of TMF645 does leave many open questions that should be clarified in the description.

The description below is my interpretation as used in real-life implementations.

The queryServiceQualification is used pre-order to determine what services can be offered based on the search criteria.

The checkServiceQualification is used a semantic validation step as part of the service Order orchestration.

The service in the serviceQualificationItem uses the ServiceRefOrValue. This is used differently depending on the intended orderItem.action.

In case of "add" only properties other than id, href are to be used in the search criteria.

In case of "modify" id and /or href should be provided

In case of "delete" or "no_change" no serviceQualification is required

This worked for us, it hopes it helps you to.

Regards

------------------------------
Koen Peeters
Ciminko SA

Original Message:
Sent: Dec 08, 2025 06:40
From: Jiri Smekal
Subject: TMF645 v5 (Preview) – action for ServiceQualificationItems?

Hi all,

we are implementing TMFC009 Service Qualification Management with TMF645 v5 (focusing on CheckServiceQualification) together with TMFC002 Service Order Capture and Validation (POCV) and TMF641 Service Order.

In TMF641, each ServiceOrderItem has an action attribute (add / modify / delete / noChange), which clearly expresses what kind of change is requested for the given service.

In TMF645 v5, the ServiceQualificationItem has no such attribute. Are actually the modification / cease use cases in scope? My understanding is, they are. User Guide explicitly lists the following Check use case:

"Check if we can upgrade the download speed of an existing and active service from 100 Mb/s to 600 Mb/s."

If an action attribute is missing, the SQM component would presumably have to:

• compare the state of the existing service in the Service Inventory (TMF638) with the requested service in TMF645,
• detect the differences,
• and derive the client's intended change (add vs modify vs cease vs nothing – such services may be needed for reference) from those differences.

From the POCV perspective, the product order usually already contains information whether this is a new product or a modification of an existing one, so this could naturally be carried into the product → CFS decomposition and further into the TMF645 call.

Overall, we see TMF645 as very similar in spirit to TMF641:
The client has to decompose products into CFS services before calling both APIs, and ideally this decomposition and the way the requested change is expressed could be aligned.

My questions are:

• Is the absence of an action-like attribute in TMF645 intentional by design?
• If modification / cease use cases are in scope, what is the recommended pattern to convey this kind of requested change in the TMF645 payload?
• A custom TMF645 API extension adding an action attribute to ServiceQualificationItem seems less harmful and more feasible than introducing item nesting (as described in my other post). For the "add" action, the API would remain fully compliant with the standard, and this is very likely its main use case.

Thanks a lot for any clarification or guidance and experiences.

------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------