Date Check Input in Number Recycling Conflicting with Tenure

[luislopezcorpas]

Problem description
The current implementation of the Number Recycle API has a discrepancy that affects its functionality. The API, as proposed by KDDI and approved in CAMARA, allows a customer to submit a recycle date check and receive a true/false response. However, the implementation should respond with true/false if the number has ever been recycled and provide the date if true. This difference causes a conflict with the tenure use case, making tenure almost redundant.

The Tenure use case would become almost redundant due to the discrepancy in the Number Recycle API response. Currently, the API should respond with "true/false" if the number has been recycled and provide the date if true. However, the current implementation only responds with "true/false" without providing the date. This causes a conflict with the Tenure use case, which also relies on the number recycling information.

If the Number Recycle API provided the recycling date along with the "true/false" response, it would eliminate the need for the Tenure use case to handle this information separately. This way, the Tenure functionality would be simplified, and there would be no redundancy in managing the number recycling information.

Expected behavior
The API should respond with true/false if the number has ever been recycled and provide the date if true.

Alternative solution

Response example
{
reuse* boolean
example: true
true indicates if MSISDN is recycled

is_recycled     string
                example: 2014-08-31

                Returns timestamp of the last time the MSISDN was recycled 

}

Additional context
This discrepancy affects the tenure use case and complicates the API's functionality, making it less reliable for customers.
The response would be true if it has ever been recycled. If true, then the recycling date is provided.
The only proposed change is that the customer doesn't submit a date as an input parameter

[Masa8106]

@luislopezcorpas Can we converting this to a discussion, as I think it needs discussion and is not yet an "issue"? If a conclusion is reached in the discussion that there is a issue here, then an new issue can be created accordingly.

[hdamker]

@luislopezcorpas I also see the that this need more discussion and is maybe not an issue at all. E.g. I don't agree that NumberRecycling should return the date of the "last time the MSISDN was recycled". That is an internal information of the operator which is not needed for the purpose of the API (to check that the MSISDN is NOT recycled after a certain date). It's not the intention of the NumberRecycling API to make Tenure use case obsolete. Tenure provides information about the customer (how long is their tenure with the operator) and will most likely require even consent to expose this information, while NumberRecycling just provides the information that the phoneNumber the API consumer has on record was not recycled by the operator.

You could argue that NumberRecycling does not fit into the KYC Sub Project, as its purpose isn't to reveal information about the customer.

[Masa8106]

@luislopezcorpas, please let me convert this to discussion, as we discussed in the meeting yesterday.

[Masa8106]

@luislopezcorpas
I would like to clarify your suggestion more to proceed this discussion. May I ask you to elaborate what is "conflict" or "redundant" between Number Recycling API and Tenure API?
For example, from use case perspective, I think the use cases for the two APIs are clearly separated and are not conflict nor redundant, but please let me know if I've missed anything.

[ssarkar-vf]

I have taken over from @luislopezcorpas from Vodafone side.

We are happy to accept the Number Recycle Camara version (where the Customer has to provide an date input parameter) unless we get further Customer feedback to suggest otherwise.

No further discussion is needed on this topic at this moment.

@Masa8106 @hdamker are you able to close this thread please?

[hdamker]

@Masa8106 @hdamker are you able to close this thread please?

Yes, will do.

[Masa8106]

@ssarkar-vf, thank you for your comment in order to conclude this topic.
@hdamker, thank you for closing.