Subject: [drinks] Some additional Use Cases for discussion purposes

From: David Schwartz <[email-masked]>
Date: Wed, 21 Apr 2010 15:27:58 +0300

Administration
-----------------

UC ADMIN #0.1  Assigning an "authoritative SSP" to a new public Identity: An SSP is approved by an authorizing entity to claim "ownership" over a new public identity (or TN range). The registry receives an "authorization" request associating an SSP and a new public identity and henceforth accepts authorized requests for the specified identity or TN range only from the designated SSP.

UC ADMIN #0.2  Assigning an "authoritative SSP" to an existing public Identity with explicit takeover: An SSP is approved by an authorizing entity to claim "ownership" over an existing public identity (or TN range). The registry receives an "authorization" request associating an SSP and an existing public identity and henceforth accepts authorized requests for the specified identity or TN range only from the designated SSP. This use case assumes that existing "ownership" data in the registry is unmodified pending a subsequent authorized add request from the newly approved SSP..

UC ADMIN #0.3  Assigning an "authoritative SSP" to an existing public Identity with implicit takeover: An SSP is approved by an authorizing entity to claim "ownership" over an existing public identity (or TN range). The registry receives an "authorization" request associating an SSP and an existing public identity and henceforth accepts authorized requests for the specified identity or TN range only from the designated SSP. This use case assumes that existing "ownership" data in the registry is "transferred" with this request to the new (recipient) authorized SSP and the old (donor) SSP is completely disassociated from this public identity.

UC ADMIN #0.4  Assigning an "authoritative SSP" to an existing public Identity with implicit takeover and "unauthorized" relegation for donor SSP: An SSP is approved by an authorizing entity to claim "ownership" over an existing public identity (or TN range). The registry receives an "authorization" request associating an SSP and an existing public identity and henceforth accepts authorized requests for the specified identity or TN range only from the designated SSP. This use case assumes that existing "ownership" data in the registry is "transferred" with this request to the new (recipient) authorized SSP and the old (donor) SSP is re-associated with the public identity as a non-authorized provider.

Identity
---------

UC ID #0.1 Authoritative adding of a new public Identity: A public identity (or a TN range) is added indicating authoritative "ownership" by the provisioning entity. The provisioning SSP is indeed authorized for this public identity and as such when the registry receives this "authoritative" add request, this identity is added to the database with an "Authoritative" indication.

UC ID #0.2 Authoritative adding of an existing public Identity: A public identity (or a TN range) already contained in the database in one form or another is added indicating authoritative "ownership" by the provisioning entity. The provisioning SSP is indeed authorized for this public identity and as such when the registry receives this "authoritative" add request, the stored ownership information pertaining to the provisioned identity is overwritten with the currently provisioned owner.

UC ID #0.3 Authoritative adding of an existing public Identity with "unauthorized" relegation for donor SSP: A public identity (or a TN range) already contained in the database in one form or another is added indicating authoritative "ownership" by the provisioning entity. The provisioning SSP is indeed authorized for this public identity and as such when the registry receives this "authoritative" add request, the stored ownership information pertaining to the provisioned identity is "demoted" to non-authorized status and the authoritative ownership is transferred to the currently provisioned owner. (Note that this UC assumes explicit takeover when assigning authoritative SSPs).

UC ID #0.4 Non-Authoritative (e.g. transit) adding of a new public Identity: A public identity (or a TN range) is added without any indication of authority or primary "ownership" by the provisioning entity. The registry receives an non authoritative non primary add and since this identity does not exist, this identity is added to the database with a non authoritative non-primary indication

UC ID #0.5 Non-Authoritative (e.g. transit) adding of an existing public Identity: A public identity (or a TN range) already contained in the database in one form or another is added without any indication of "ownership" by the provisioning entity. The registry receives an non authoritative non primary add and since this identity already exists in the database, the currently provisioned owner is appended to the stored ownership information pertaining to the provisioned identity.

UC ID #0.6 Unlinking a public Identity: A public identity (or a TN range) already contained in the database in one form or another and associated with one or more "owners" of various types (e.g. authoritative, primary, transit, etc.) needs to be disassociated from one of its "owners". The registry receives an "unlink" directive from a current "owner" and must severe said relationships. If no additional "owners" linked to the identity, this identity needs to be purged from the database. This can also trigger delete operations to keep the local data  repositories up-to-date.

Number Portability
----------------------

UC NP #0.1  The SSP wishes to provide in query response to public identities an associated routing number or RN. This is the case when a set of public identities is no longer associated with original SSP but have been ported to a recipient SSP who provides access to these identities via a switch on the SS7 network identified by the RN. In this case a destination group containing all numbers that should be routed to this RN needs to be created and the route group associated with this DG needs to contain the RN

UC NP #0.2 Authoritative adding of an existing public Identity in cases where a "release" is needed prior to porting: A public identity (or a TN range) already contained in the database in one form or another is added indicating authoritative "ownership" by the provisioning entity. The registry receives an "authoritative" add request, however, since the number or range is "locked" an error response needs to be returned to provisioner

UC NP #0.3 Authoritative "releasing" of an existing public Identity: A "release" command associated with one or more public identities is received from an authoritative entity indicating his relinquishing of authoritative "ownership" over the respective identities.

Resolution Data
-------------------

UC RD #0.1  The SSP wishes to define a default "target" to be used for resolution purposes: The SSP wishes to provide in query response to public identities an FQDN representing a non routable target domain indicating association with the public identifier.

UC RD #0.2  The SSP wishes to define a default "route" to be used for resolution purposes: The SSP wishes to provide in query response to public identities an FQDN representing a routable domain that can be used for further resolution of ingress signaling point.

UC RD #0.3  The SSP wishes to specify default behavior vis-a-vis target or route resolution: The SSP wishes to set the default behavior with respect to whether to return target or routable domain information in responses to public identifier queries.

UC RD #0.4  The SSP wishes to override default behavior vis-a-vis target or route resolution for a given public identifier: The SSP wishes to override the default behavior with respect to whether to return target or routable domain information in responses to public identifier queries for a given SSP or SSPs.