Remove multi-sim text

[AxelNennker]

What type of PR is this?

Add one of the following kinds:

• cleanup
• documentation

What this PR does / why we need it:

Multi-SIM support is not well-understood and should be "solved" for all CAMARA APIs.
Multi-SIM support was discussed in several CAMARA API subprojects without solution.
For interoperability reasons API providers should handle the Multi-SIM case in the same manner.

Additional documentation

Support of Multi-SIM lines in CAMARA APIs #302

[eric-murray]

API releases cannot be blocked whilst waiting for a resolution to Commonalities #302.

Options are:

• Say nothing (i.e. merge this PR)
• Make a general statement that multi-SIM handling will be proprietary for now (see, for example, QoD Provisioning)
• Given that only one device identity can be returned by this API, give some guidance as to which device that will be for a multi-SIM scenario (i.e. keep the current text)

I'm happy to accept the first option, so long as it is understood that this does not mean any implementations cannot support devices which are part of a multi-SIM group.

[AxelNennker]

I would like to avoid a situation like with QoD where we have several implementations where it is unclear for the API consumer what the result of an API request is.

... the API may respond with an error, apply the provisioning to all devices in the multi-SIM group, or apply the provisioning to a single device in the multi-SIM group which may not be the intended device.

I assume the cited text was written in the way it was written because one implementation does it one way and another implementation does it differently.

The text this PR deletes makes assumptions about connectivity plans and what happens "usually".
I think text on multi-sim are useful for the API consumer, in the sense of: be aware of these special cases.
As a guideline for API providers I would like to have text on how to implement support for device selection in a multi-sim scenario or "target-device different to authentication-device" scenario in Commonalities or ICM not here - maybe here if the text is really API specific.

I think neither multip-sim nor "target-device different to authentication-device" scenarios are well understood.

I do not have text proposals, neither for API consumers nor for API providers.
I have not written this PR because I do not want text on Multi-SIM.
Maybe we can use this PR to discuss better text.

[eric-murray]

This API is simpler than most, in that it returns information about a single physical device, and only a single physical device. So there is no concept of a "combined" status or actions that we might have for other APIs when dealing with multi-SIM groups.

So I'll make a proposal here, and if there is any doubt, we can wait for Commonalities to express their view.

First, this only applies to the phoneNumber identifier. The other identifiers (IP addresses or NAI) do not identify multi-SIM groups.

If the mobile operator supports the concept of "secondary" MSISDNs, then phoneNumber is considered to specify the secondary MSISDN. Whether the API consumer knows whether they are handling the primary or secondary MSISDN is a separate issue.

If the mobile operator does NOT support the concept of secondary MSISDNs, then I guess they have two choices:

• Return an identifier for the primary device identified by the phoneNumber; or
• Return an error

They have no other choice. And as returning an error is not very useful, they should return an identifier for the primary device. This will mean there is no way to identify the other devices from phoneNumber, but that is why the other device identifier options are supported.

I don't expect Commonalities to come up with a better solution, but that remains to be seen.