Hello Both,
An interesting topic which I believes needs a wider discussion to cover a variety of use cases. which possibly apply to the product qualification API as well as the service qualification API.
The original question posed I believe relates to temporary technical solutions which may then be replaced at some time in the future and therefore already have an end date planned?
An example I have seen in the UK is the use of radio access to premises for a private circuit as a temporary measure prior to installing fibre.
In this case however the service can stay in place as long as is needed until the replacement arrangement is available. In this case there is no need to specify the end date in advance.
All that happens is in the product order the customer can say whether temporary radio access is acceptable as a means of getting the circuit in on time.
Another example is where the product itself is planned to have a short lifetime where the termination date is planned in from the beginning. So temporary special coverage with mobile base stations for concerts or outside broadcast circuits for sports events are two examples I can think of. The need to specify the anticipated deactivation date is to check terms and conditions on pricing but also to assist planners in deciding how to fulfil the requirement. The specification of a period is valid here because one knows the start and the end and this might affect feasibility.
But the third example I can think of relates to the closure of networks and the migration/termination of services on them that have been there for some time. This involves adding expected deactivation dates retrospectively to already activated services and stating when it is no longer possible to activate new services in specific locations.
For example in the UK BT/Openreach intend to stop selling PSTN/ISDN services generally from 2023 and close the relevant networks in 2025 and have indeed already issued "Stop Sell" notices for specific locations. Note because of this product qualification for BT includes saying this offering is no longer available for new product orders in this specific location from a particular date and into the future.
In this third case one is adding a planned termination date to a service long after it was activated as well as saying anything new has a planned end date.
So I agree that there is something to be added here but I suspect it has to be done with reference to the product qualification API as well as the service qualification API and should cover the range of scenarios above?
------------------------------
Derrick Evans
------------------------------
Original Message:
Sent: Jan 05, 2022 03:50
From: Ludovic Robert
Subject: TMF 645 future dating of service qualification requests
Hello Roland
This is an interesting case, and I do not think that current model as it supports it.
I see 2 ways to handle it:
- Add another date attribute like expectedDeactivationDate
- Replace expectedActivationDate with expectedActivationPeriod and define it with a startDate/endDate attributes
I have a preference for the second option (it seems to me 'cleaner'), but it implies some API change - the first option is probably easier to implement and do no break API compliance.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Jan 04, 2022 05:14
From: roland Werding
Subject: TMF 645 future dating of service qualification requests
Hi TMF 645 experts,
I am looking for a service qualification feature which checks the feasibility/eligibility or alternative option for a given service at a future date AND a future period of time. This use case may be relevant e.g. for providing temporary IP-VPN services requiring a certain QoS, Bandwidth etc...
What I find in the swagger definition is:
CheckServiceQualificationItem sub-resource
A ServiceQualificationItem relates to a specific service being checked in a qualification operation.
expectedActivationDate A date time (DateTime). The date when the service is expected to be activated.
expectedServiceAvailabilityDate A date time (DateTime). Date when the requester looks for service availability.
expirationDate A date time (DateTime). Date when the qualification item response expires
So there is a clearly defined start time for the requested availablity, i.e. "expectedActivationDate", "expectedServiceAvailabilityDate" and a time how long the response is valid "expirationDate". How would you formulate a service qualitication request which has an expected deactivation date as well when the service may become unavailable again?
thanks for your guidance
roland
------------------------------
roland Werding
Deutsche Telekom AG
------------------------------