| < draft-ietf-modern-problem-framework-00.txt | draft-ietf-modern-problem-framework-01.txt > | |||
|---|---|---|---|---|
| Network Working Group J. Peterson | Network Working Group J. Peterson | |||
| Internet-Draft T. McGarry | Internet-Draft T. McGarry | |||
| Intended status: Informational NeuStar, Inc. | Intended status: Informational NeuStar, Inc. | |||
| Expires: October 23, 2016 April 21, 2016 | Expires: January 8, 2017 July 7, 2016 | |||
| Modern Problem Statement, Use Cases, and Framework | Modern Problem Statement, Use Cases, and Framework | |||
| draft-ietf-modern-problem-framework-00.txt | draft-ietf-modern-problem-framework-01.txt | |||
| Abstract | Abstract | |||
| The functions of the public switched telephone network (PSTN) are | The functions of the public switched telephone network (PSTN) are | |||
| rapidly migrating to the Internet. This is generating new | rapidly migrating to the Internet. This is generating new | |||
| requirements for many traditional elements of the PSTN, including | requirements for many traditional elements of the PSTN, including | |||
| telephone numbers (TNs). TNs no longer serve simply as telephone | telephone numbers (TNs). TNs no longer serve simply as telephone | |||
| routing addresses, they are now identifiers which may be used by | routing addresses, they are now identifiers which may be used by | |||
| Internet-based services for a variety of purposes including session | Internet-based services for a variety of purposes including session | |||
| establishment, identity verification, and service enablement. This | establishment, identity verification, and service enablement. This | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on October 23, 2016. | This Internet-Draft will expire on January 8, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 3, line 27 ¶ | skipping to change at page 3, line 27 ¶ | |||
| was envisioned that ENUM would be deployed as a global hierarchical | was envisioned that ENUM would be deployed as a global hierarchical | |||
| service, though in practice, it has only been deployed piecemeal by | service, though in practice, it has only been deployed piecemeal by | |||
| various parties. Most notably, ENUM is used as an internal network | various parties. Most notably, ENUM is used as an internal network | |||
| function, and is hardly used between service provider networks. The | function, and is hardly used between service provider networks. The | |||
| original ENUM concept of a single root, e164.arpa, proved to be | original ENUM concept of a single root, e164.arpa, proved to be | |||
| politically and practically challenging, and less centralized models | politically and practically challenging, and less centralized models | |||
| have thus flourished. Subsequently, the DRINKS [4] framework showed | have thus flourished. Subsequently, the DRINKS [4] framework showed | |||
| ways that authorities might provision information about TNs at an | ways that authorities might provision information about TNs at an | |||
| ENUM service or similar Internet-based directory. These technologies | ENUM service or similar Internet-based directory. These technologies | |||
| have also generally tried to preserve the features and architecture | have also generally tried to preserve the features and architecture | |||
| familiar from the PSTN numbering environment. | familiar to the PSTN numbering environment. | |||
| Over time, Internet telephony has encompassed functions that differ | Over time, Internet telephony has encompassed functions that differ | |||
| substantially from traditional PSTN routing and management, | substantially from traditional PSTN routing and management, | |||
| especially as non-traditional providers have begun to utilize | especially as non-traditional providers have begun to utilize | |||
| numbering resources. An increasing number of enterprises, over-the- | numbering resources. An increasing number of enterprises, over-the- | |||
| top Voice over IP providers, text messaging services, and related | top Voice over IP providers, text messaging services, and related | |||
| non-carrier services have become heavy users of telephone numbers. | non-carrier services have become heavy users of telephone numbers. | |||
| An enterprise, for example, could deploy an IP PBX that receives a | An enterprise, for example, could deploy an IP PBX that receives a | |||
| block of telephone numbers from a carrier and then in turn distribute | block of telephone numbers from a carrier and then in turn distribute | |||
| those numbers to new IP telephones when they associate with the PBX. | those numbers to new IP telephones when they associate with the PBX. | |||
| skipping to change at page 4, line 19 ¶ | skipping to change at page 4, line 19 ¶ | |||
| users now associate TNs with many Internet applications other than | users now associate TNs with many Internet applications other than | |||
| telephony. This has generated new interest in models similar to | telephony. This has generated new interest in models similar to | |||
| those in place for administering freephone services in the United | those in place for administering freephone services in the United | |||
| States, where a user purchases a number through a sort of number | States, where a user purchases a number through a sort of number | |||
| registrar and controls its administration (such as routing) on their | registrar and controls its administration (such as routing) on their | |||
| own, typically using Internet services to directly make changes to | own, typically using Internet services to directly make changes to | |||
| the service associated with telephone numbers. | the service associated with telephone numbers. | |||
| Most TNs today are assigned to specific geographies, at both an | Most TNs today are assigned to specific geographies, at both an | |||
| international level and within national numbering plans. Numbering | international level and within national numbering plans. Numbering | |||
| practices today are tightly coupled with the manenr that service | practices today are tightly coupled with the manner that service | |||
| providers interconnect, as well as how TNs are routed and | providers interconnect, as well as how TNs are routed and | |||
| administered: the PSTN was carefully designed to delegate switching | administered: the PSTN was carefully designed to delegate switching | |||
| intelligence geographically. In interexchange carrier routing in | intelligence geographically. In interexchange carrier routing in | |||
| North America, for example, calls to a particular TN are often handed | North America, for example, calls to a particular TN are often handed | |||
| off to the terminating service provider close to the geography where | off to the terminating service provider close to the geography where | |||
| that TN is assigned. But the overwhelming success of mobile | that TN is assigned. But the overwhelming success of mobile | |||
| telephones has increasing eroded the connection between numbers and | telephones has increasing eroded the connection between numbers and | |||
| regions. Furthermore, the topology of IP networks is not anchored to | regions. Furthermore, the topology of IP networks is not anchored to | |||
| geography in the same way that the telephone network is. In an | geography in the same way that the telephone network is. In an | |||
| Internet environment, establishing a network architecture for routing | Internet environment, establishing a network architecture for routing | |||
| TNs could depend little on geography. Adapting TNs to the Internet | TNs could depend little on geography. Adapting TNs to the Internet | |||
| requires more security, richer datasets and more complex query and | requires more security, richer datasets and more complex query and | |||
| response capabilities than previous efforts have provided. | response capabilities than previous efforts have provided. | |||
| This document will create a common understanding of the problem | This document will create a common understanding of the problem | |||
| statement related to allocating, managing, and resolving TNs in an IP | statement related to allocating, managing, and resolving TNs in an IP | |||
| environment. It outlines a framework and lists motivating use cases | environment. It outlines a framework and lists motivating use cases | |||
| for creating IP-based mechanisms for TNs. It is important to | for creating IP-based mechanisms for TNs. It is important to | |||
| acknowledge at the outset that there are various evolvling | acknowledge at the outset that there are various evolving | |||
| international and national policies and processes related to TNs, and | international and national policies and processes related to TNs, and | |||
| any solutions need to be flexible enough to account for variations in | any solutions need to be flexible enough to account for variations in | |||
| policy and requirements. | policy and requirements. | |||
| 2. Definitions | 2. Definitions | |||
| This section provides definitions for actors, data types and data | This section provides definitions for actors, data types and data | |||
| management architectures as they are discussed in this document. | management architectures as they are discussed in this document. | |||
| Different numbering spaces may instantiate these roles and concepts | Different numbering spaces may instantiate these roles and concepts | |||
| differently: practices that apply to non-geographic freephone | differently: practices that apply to non-geographic freephone | |||
| skipping to change at page 5, line 35 ¶ | skipping to change at page 5, line 35 ¶ | |||
| Authoritative Registry: An authoritative Registry is a single entity | Authoritative Registry: An authoritative Registry is a single entity | |||
| with sole responsibility for specific numbering resources. | with sole responsibility for specific numbering resources. | |||
| Distributed Registry: Distributed Registries are multiple Registries | Distributed Registry: Distributed Registries are multiple Registries | |||
| responsible for the same numbering resources. | responsible for the same numbering resources. | |||
| Registrar: An entity that distributes the telephone numbers | Registrar: An entity that distributes the telephone numbers | |||
| administered by a Registry; typically, there are many Registrars | administered by a Registry; typically, there are many Registrars | |||
| that can distribute numbers from a single Registry, through | that can distribute numbers from a single Registry, through | |||
| Registrars may serve multiple Registries as well. A Registrar has | Registrars may serve multiple Registries as well. A Registrar has | |||
| business relationships with its assginees and collects | business relationships with its assignees and collects | |||
| administrative information from them. | administrative information from them. | |||
| Communication Service Provider (CSP): A provider of communications | Communication Service Provider (CSP): A provider of communications | |||
| services to Users, where those services can be identified by TNs. | services, where those services can be identified by TNs. This | |||
| This includes both traditional telephone carriers or enterprises | includes both traditional telephone carriers or enterprises as | |||
| as well as service providers with no presence on the PSTN who use | well as service providers with no presence on the PSTN who use | |||
| TNs. This framework does not assume that any single CSP provides | TNs. This framework does not assume that any single CSP provides | |||
| all the communications service related to a particular TN. | all the communications service related to a particular TN. | |||
| Service Enabler: An entity that works with CSPs to enable | Service Enabler: An entity that works with CSPs to enable | |||
| communication service to a User; perhaps a vendor, or third-party | communication service to a User; perhaps a vendor, or third-party | |||
| integrator. | integrator. | |||
| User: An individual reachable through a communications service; | User: An individual reachable through a communications service; | |||
| usually a customer of a communication service provider. | usually a customer of a communication service provider. | |||
| Government Entity: An entity that, due to legal powers deriving from | Government Entity: An entity that, due to legal powers deriving from | |||
| national policy, has privileged access to information about number | national policy, has privileged access to information about number | |||
| administration under certain conditions. | administration under certain conditions. | |||
| Note that an individual, company or other entity may act in one or | Note that an individual, company or other entity may act in one or | |||
| more of the roles above; for example, a company may be a CSP and also | more of the roles above; for example, a company may be a CSP and also | |||
| a Registrar. Although Numbering Authorities are listed as actors, | a Registrar. Although Numbering Authorities are listed as actors, | |||
| they are unlikely to actually participate in the protocol flows | they are unlikely to actually participate in the protocol flows | |||
| themselves, though in some situations a Numbering Authority and | themselves, though in some situations a Numbering Authority and | |||
| Registry may be the same administrative entitiy. | Registry may be the same administrative entity. | |||
| All actors that are recipients of numbering resources, be they a CSP, | All actors that are recipients of numbering resources, be they a CSP, | |||
| Service Enabler, or User, can also be said to have a relationship to | Service Enabler, or User, can also be said to have a relationship to | |||
| a Registry of either an assignee or delegate: | a Registry of either an assignee or delegate: | |||
| Assignee: An actor that is assigned a TN directly by a Registrar; an | Assignee: An actor that is assigned a TN directly by a Registrar; an | |||
| assignee always has a direct relationship with a Registrar. | assignee always has a direct relationship with a Registrar. | |||
| Delegate: An actor that is delegated a TN from an assignee or | Delegate: An actor that is delegated a TN from an assignee or | |||
| another delegate, who does not necessarily have a direct | another delegate, who does not necessarily have a direct | |||
| skipping to change at page 8, line 31 ¶ | skipping to change at page 8, line 31 ¶ | |||
| manages detailed administrative data about those assignments, such as | manages detailed administrative data about those assignments, such as | |||
| contact or billing information for the assignee. In some models, | contact or billing information for the assignee. In some models, | |||
| CSPs and Registrars will be composed (the same administrative | CSPs and Registrars will be composed (the same administrative | |||
| entity), and in others the Registry and Registrar may similarly be | entity), and in others the Registry and Registrar may similarly be | |||
| composed. Typically, service data resides largely at the CSP itself, | composed. Typically, service data resides largely at the CSP itself, | |||
| though in some models a "thicker" Registry may itself contain a | though in some models a "thicker" Registry may itself contain a | |||
| pointer to the servicing CSP for a number or number block. In | pointer to the servicing CSP for a number or number block. In | |||
| addition to traditional centralized Registries, this framework also | addition to traditional centralized Registries, this framework also | |||
| supports environments where the same data is being managed by | supports environments where the same data is being managed by | |||
| multiple administrative entities, and stored in many locations. A | multiple administrative entities, and stored in many locations. A | |||
| distribute registry system is discussed further in [15]. | distribute registry system is discussed further in [16]. | |||
| Data store: a service that stores and enables access to | Data store: a service that stores and enables access to | |||
| administrative and/or service data. | administrative and/or service data. | |||
| Reference Address: a URL that dereferences to the location of the | Reference Address: a URL that dereferences to the location of the | |||
| data store. | data store. | |||
| Distributed data stores: refers to administrative or service data | Distributed data stores: refers to administrative or service data | |||
| being stored with multiple actors. For example, CSPs could | being stored with multiple actors. For example, CSPs could | |||
| provision their service data to multiple other CSPs. | provision their service data to multiple other CSPs. | |||
| skipping to change at page 9, line 14 ¶ | skipping to change at page 9, line 14 ¶ | |||
| 3. Framework | 3. Framework | |||
| The framework outlined in this document requires three Internet-based | The framework outlined in this document requires three Internet-based | |||
| mechanisms for managing and resolving telephone numbers (TNs) in an | mechanisms for managing and resolving telephone numbers (TNs) in an | |||
| IP environment. These mechanisms will likely reuse existing | IP environment. These mechanisms will likely reuse existing | |||
| protocols for sharing structured data; it is unlikely that new | protocols for sharing structured data; it is unlikely that new | |||
| protocol development work will be required, though new information | protocol development work will be required, though new information | |||
| models specific to the data itself will be a major focus of framework | models specific to the data itself will be a major focus of framework | |||
| development. Likely candidates for reuse here include work done in | development. Likely candidates for reuse here include work done in | |||
| DRINKS and WEIRDS, as well as the TeRI [12] framework. | DRINKS [4] and WEIRDS [12], as well as the TeRI [13] framework. | |||
| These protocol mechanisms are scoped in a way that makes them likely | These protocol mechanisms are scoped in a way that makes them likely | |||
| to apply to a broad range of future policies for number | to apply to a broad range of future policies for number | |||
| administration. It is not the purpose of this framework to dictate | administration. It is not the purpose of this framework to dictate | |||
| number policy, but instead to provide tools that will work with | number policy, but instead to provide tools that will work with | |||
| policies as they evolve going forward. These mechanisms therefore do | policies as they evolve going forward. These mechanisms therefore do | |||
| not assume that number administration is centralized, nor that number | not assume that number administration is centralized, nor that number | |||
| allocations are restricted to any category of service providers, | allocations are restricted to any category of service providers, | |||
| though these tools must and will work in environments with those | though these tools must and will work in environments with those | |||
| properties. | properties. | |||
| skipping to change at page 11, line 31 ¶ | skipping to change at page 11, line 31 ¶ | |||
| Registrar to hold as inventory or assign to customers. | Registrar to hold as inventory or assign to customers. | |||
| Through some out-of-band business process, a CSP develops a | Through some out-of-band business process, a CSP develops a | |||
| relationship with a Registrar. The Registrar maintains a profile of | relationship with a Registrar. The Registrar maintains a profile of | |||
| the CSP and what qualifications they possess for requesting TNs. The | the CSP and what qualifications they possess for requesting TNs. The | |||
| CSP may then request TNs from within a specific pool of numbers in | CSP may then request TNs from within a specific pool of numbers in | |||
| the authority of the Registry; such as region, mobile, wireline, | the authority of the Registry; such as region, mobile, wireline, | |||
| tollfree, etc. The Registrar must authenticate and authorize the | tollfree, etc. The Registrar must authenticate and authorize the | |||
| CSP, and then either grant or deny a request. When an assignment | CSP, and then either grant or deny a request. When an assignment | |||
| occurs, the Registry creates and stores administrative information | occurs, the Registry creates and stores administrative information | |||
| related to the assignment such as TN status and contact information, | related to the assignment such as TN status and Registrar contact | |||
| and removes the specific TN(s) from the pool of those that are | information, and removes the specific TN(s) from the pool of those | |||
| available for assignment. As a part of the acqusition and assignment | that are available for assignment. As a part of the acquisition and | |||
| process, the Registry provides any necessary credentials (for | assignment process, the Registry provides any necessary credentials | |||
| example, STIR certificates [13]) to the CSP to be used to prove the | (for example, STIR certificates [14]) to the Registrar to be used to | |||
| assignment for future transactions. | prove the assignment for future transactions. | |||
| Before it is eligible to receive TN assignments, per the policy of a | Before it is eligible to receive TN assignments, per the policy of a | |||
| national authority, the CSP may need to have submitted (again, | national authority, the CSP may need to have submitted (again, | |||
| through some out-of-band process) additional qualifying information | through some out-of-band process) additional qualifying information | |||
| such as current utilization rate or a demand forecast. | such as current utilization rate or a demand forecast. | |||
| There are two scenarios under which a CSP requests resources; they | There are two scenarios under which a CSP requests resources; they | |||
| are requesting inventory, or they are requesting for a specific User | are requesting inventory, or they are requesting for a specific User | |||
| or delegate. TNs assigned to a User are always considered assigned | or delegate. TNs assigned to a User are always considered assigned, | |||
| by the Registrar, not inventory. In this use case, after receiving a | not inventory. The CSP will associate service information for that | |||
| number assignment from the Registrar, a User will then obtain | TN, e.g., service address, and make it available to other CSPs to | |||
| communications service from a CSP, and provide to the CSP the TN to | enable interoperability. The CSP may need to update the Registrar | |||
| be used for that service along with the credential. The CSP will | regarding this service activation (this is part of the "TN status" | |||
| associate service information for that TN, e.g., service address, and | maintained by the Registrar). | |||
| make it available to other CSPs to enable interoperability. The CSP | ||||
| may need to update the Registrar regarding this service activation | ||||
| (this is part of the "TN status" maintained by the Registrar). | ||||
| 4.1.2. User Acquires TNs from CSP | 4.1.2. User Acquires TNs from CSP | |||
| Today, a User typically acquires a TN from CSP when signing up for | Today, a User typically acquires a TN from CSP when signing up for | |||
| communications service or turning on a new device. In this use case, | communications service or turning on a new device. In this use case, | |||
| the User becomes the delegate of the CSP. | the User becomes the delegate of the CSP. | |||
| A User creates or has a relationship with the CSP, and subscribes to | A User creates or has a relationship with the CSP, and subscribes to | |||
| a communications service which includes the use of a TN. The CSP | a communications service which includes the use of a TN. The CSP | |||
| collects and stores administrative data about the User. The CSP then | collects and stores administrative data about the User. The CSP then | |||
| activates the User on their network and creates any necessary service | activates the User on their network and creates any necessary service | |||
| data to enable interoperability with other CSPs. The CSP could also | data to enable interoperability with other CSPs. The CSP could also | |||
| update public or privileged databases accessible by other Actors. | update public or privileged databases accessible by other Actors. | |||
| The CSP provides any necessary credentials to the User (for example, | The CSP provides any necessary credentials to the User (for example, | |||
| a STIR certificate [13]) to prove the assignment for future | a STIR certificate [14]) to prove the assignment for future | |||
| transactions. Such credential could be delegated from the one | transactions. Such credential could be delegated from the one | |||
| provided by the Registrar to the CSP to continue the chain of | provided by the Registrar to the CSP to continue the chain of | |||
| assignment. | assignment. | |||
| The CSP could assign a TN from its existing inventory or it could | The CSP could assign a TN from its existing inventory or it could | |||
| acquire a new TN from the Registrar as part of the assignment | acquire a new TN from the Registrar as part of the assignment | |||
| process. If it assigns it from its existing inventory it would | process. If it assigns it from its existing inventory it would | |||
| remove the specific TN from the pool of those available for | remove the specific TN from the pool of those available for | |||
| assignment. It may also update the Registrar about the assignment so | assignment. It may also update the Registrar about the assignment so | |||
| the Registrar has current assignment data. | the Registrar has current assignment data. | |||
| skipping to change at page 12, line 44 ¶ | skipping to change at page 12, line 42 ¶ | |||
| A reseller or a service bureau might acquire a block of numbers from | A reseller or a service bureau might acquire a block of numbers from | |||
| a CSP to be issued to Users. | a CSP to be issued to Users. | |||
| In this case, the delegate CSP has a business relationship with the | In this case, the delegate CSP has a business relationship with the | |||
| assignee CSP. The assignee CSP collects and stores administrative | assignee CSP. The assignee CSP collects and stores administrative | |||
| data about the delegate. The assignee then activates the delegate on | data about the delegate. The assignee then activates the delegate on | |||
| their network and creates any necessary service data to enable | their network and creates any necessary service data to enable | |||
| interoperability with other CSPs. The CSP could also update public | interoperability with other CSPs. The CSP could also update public | |||
| or privileged databases accessible by other Actors. The CSP provides | or privileged databases accessible by other Actors. The CSP provides | |||
| any necessary credentials to the delegate CSP (for example, a STIR | any necessary credentials to the delegate CSP (for example, a STIR | |||
| certificate [13]) to prove the assignment for future transactions. | certificate [14]) to prove the assignment for future transactions. | |||
| Such credentials could be delegated from the one provided by the | Such credentials could be delegated from the one provided by the | |||
| Registry to the CSP to continue the chain of assignment. | Registry to the CSP to continue the chain of assignment. | |||
| The CSP could assign a block from its existing inventory or it could | The CSP could assign a block from its existing inventory or it could | |||
| acquire new TNs from the Registrar as part of the assignment process. | acquire new TNs from the Registrar as part of the assignment process. | |||
| If it assigns it from its existing inventory it would remove the | If it assigns it from its existing inventory it would remove the | |||
| specific TN from the pool of those available for assignment. It may | specific TN from the pool of those available for assignment. It may | |||
| also update the Registrar about the assignment so the Registrar has | also update the Registrar about the assignment so the Registrar has | |||
| current assignment data. The Delegate may need to provide | current assignment data. The Delegate may need to provide | |||
| utilization and assignment data to the Registry, either directly or | utilization and assignment data to the Registry, either directly or | |||
| through the CSP. | through the CSP. | |||
| 4.1.4. User Acquires TNs from a Delegate | 4.1.4. User Acquires TNs from a Delegate | |||
| Aquiring a TN from a delegate follows the process in Section 4.1.2, | Acquiring a TN from a delegate follows the process in Section 4.1.2, | |||
| as it should be similar to how a User acquires TNs from a CSP. In | as it should be similar to how a User acquires TNs from a CSP. In | |||
| this case, the delegate re-delegating the TNs would be performing | this case, the delegate re-delegating the TNs would be performing | |||
| functions done by the CSP, e.g., providing any credentials, | functions done by the CSP, e.g., providing any credentials, | |||
| collecting administrative data, creative service data, and so on. | collecting administrative data, creative service data, and so on. | |||
| 4.1.5. User Acquires Numbers from Registrar | 4.1.5. User Acquires Numbers from Registrar | |||
| Today, a user wishing to acquire a freephone number may browse the | Today, a user wishing to acquire a freephone number may browse the | |||
| existing inventory through one or more Registrars, comparing their | existing inventory through one or more Registrars, comparing their | |||
| prices and services. Each such Registrar either is a CSP, or has a | prices and services. Each such Registrar either is a CSP, or has a | |||
| business relationship wtih a CSP to provide services for that | business relationship with a CSP to provide services for that | |||
| freephone number. | freephone number. | |||
| Acquiring a TN from a Registrar follows the process in Section 4.1.1, | Acquiring a TN from a Registrar follows the process in Section 4.1.1, | |||
| as it should be similar to how a CSP acquires TNs from a Registrar. | as it should be similar to how a CSP acquires TNs from a Registrar. | |||
| In this case, the User must establish some business relationship | In this case, the User must establish some business relationship | |||
| directly to a Registrar, similarly to how such functions are | directly to a Registrar, similarly to how such functions are | |||
| conducted today when Users purchase domain names. For the purpose of | conducted today when Users purchase domain names. For the purpose of | |||
| status information kept by the Registry, TNs assigned to a User are | status information kept by the Registry, TNs assigned to a User are | |||
| always considered assigned, not inventory. | always considered assigned, not inventory. | |||
| skipping to change at page 14, line 42 ¶ | skipping to change at page 14, line 40 ¶ | |||
| In a distributed Registry model, TN status, e.g., allocated, | In a distributed Registry model, TN status, e.g., allocated, | |||
| assigned, available, unavailable, would need to be provided to other | assigned, available, unavailable, would need to be provided to other | |||
| Registries in real-time. Other administrative data could be sent to | Registries in real-time. Other administrative data could be sent to | |||
| all Registries or other Registries could get a reference address to | all Registries or other Registries could get a reference address to | |||
| the host Registry's data store. | the host Registry's data store. | |||
| 4.2.1.2. User to CSP | 4.2.1.2. User to CSP | |||
| After a User acquires a TN or block of TNs from a CSP, the User will | After a User acquires a TN or block of TNs from a CSP, the User will | |||
| provide administrative data to the CSP. The CSP commonly acts as a | provide administrative data to the CSP. The CSP commonly acts as a | |||
| Regisrar in this case, maintaining the administrative data and only | Registrar in this case, maintaining the administrative data and only | |||
| notify the Registry of the change in TN status. In this case, the | notify the Registry of the change in TN status. In this case, the | |||
| Registry maintains a reference address to the CSP/Registrar's | Registry maintains a reference address to the CSP/Registrar's | |||
| administrative data store so relevant actors have the ability to | administrative data store so relevant actors have the ability to | |||
| access the data. Alternatively a CSP could send the administrative | access the data. Alternatively a CSP could send the administrative | |||
| data to an external Registrar to store. If there is a delegate | data to an external Registrar to store. If there is a delegate | |||
| between the CSP and user, they will have to ensure there is a | between the CSP and user, they will have to ensure there is a | |||
| mechanism for the delegate to update the CSP as change occurs. | mechanism for the delegate to update the CSP as change occurs. | |||
| 4.2.1.3. User to Registrar | 4.2.1.3. User to Registrar | |||
| If the User has a direct relationship with the Registrar, then | If the User has a direct relationship with the Registrar, then | |||
| naturally the user could could provision administrative data | naturally the user could provision administrative data associated | |||
| associated with their TN directly to the Registrar. This is the | with their TN directly to the Registrar. This is the case, for | |||
| case, for example, with the freephone example, where a User has a | example, with the freephone example, where a User has a business | |||
| business relationship with its freephone provider, and the freephone | relationship with its freephone provider, and the freephone provider | |||
| provider maintains account and billing data. While delegates | maintains account and billing data. While delegates necessarily are | |||
| necessarily are not assignees, some environments as an optimization | not assignees, some environments as an optimization might want to | |||
| might want to support a model where the delegate updates the | support a model where the delegate updates the Registrar directly on | |||
| Registrar directly on changes, as opposed to sending that data to the | changes, as opposed to sending that data to the CSP or through the | |||
| CSP or through the CSP to the Registrar. As stated already, the | CSP to the Registrar. As stated already, the protocol should enable | |||
| protocol should enable Users to acquire TNs directly from a | Users to acquire TNs directly from a Registrar, which Registrar may | |||
| Registrar, which Registrar may or may not also act as a CSP. In | or may not also act as a CSP. In these cases the updates would be | |||
| these cases the updates would be similar to that described in | similar to that described in Section 4.2.1.1. | |||
| Section 4.2.1.1. | ||||
| 4.2.2. Management of Service Data | 4.2.2. Management of Service Data | |||
| Service data is data required by an originating or intermediate CSP | Service data is data required by an originating or intermediate CSP | |||
| to enable communications service to a User: a SIP URI is an example | to enable communications service to a User: a SIP URI is an example | |||
| of one service data element commonly used to route communications. | of one service data element commonly used to route communications. | |||
| CSPs typically create and manage service data, however it is possible | CSPs typically create and manage service data, however it is possible | |||
| that delegates and Users could as well. For most use cases involving | that delegates and Users could as well. For most use cases involving | |||
| individual Users, it is anticipated that lower-level service | individual Users, it is anticipated that lower-level service | |||
| information changes would be communicated to CSPs via existing | information changes would be communicated to CSPs via existing | |||
| skipping to change at page 17, line 10 ¶ | skipping to change at page 17, line 10 ¶ | |||
| TN from the CSP, wishes to terminate their service. At this time, | TN from the CSP, wishes to terminate their service. At this time, | |||
| the CSP will undo any delegations to the User, including invalidating | the CSP will undo any delegations to the User, including invalidating | |||
| any cryptographic credentials (e.g. STIR certificates [13]) | any cryptographic credentials (e.g. STIR certificates [13]) | |||
| previously granted to the User. Any service data maintained by the | previously granted to the User. Any service data maintained by the | |||
| CSP must be removed, and similarly, the CSP must delete any such | CSP must be removed, and similarly, the CSP must delete any such | |||
| information it provisioned in the Registrar. | information it provisioned in the Registrar. | |||
| The TN will change state from assigned to unassigned, the CSP will | The TN will change state from assigned to unassigned, the CSP will | |||
| update the Registry. Depending on policies the TN could go back into | update the Registry. Depending on policies the TN could go back into | |||
| the Registry, CSP, or delegate's pool of available TNs and would | the Registry, CSP, or delegate's pool of available TNs and would | |||
| likely enter an aging process. | likely enter an ageing process. | |||
| In an alternative use case, a User who received their own TN | In an alternative use case, a User who received their own TN | |||
| assignment directly from a Registrar terminates their service with a | assignment directly from a Registrar terminates their service with a | |||
| CSP. At this time, the User might terminate their assignment from | CSP. At this time, the User might terminate their assignment from | |||
| the Registrar, and return the TN to the Registry for re-assignment. | the Registrar, and return the TN to the Registry for re-assignment. | |||
| Alternatively, they could retain the TN and elect to assign it to | Alternatively, they could retain the TN and elect to assign it to | |||
| some other service at a later time. | some other service at a later time. | |||
| 4.3. Retrieval | 4.3. Retrieval | |||
| skipping to change at page 18, line 9 ¶ | skipping to change at page 18, line 9 ¶ | |||
| below. | below. | |||
| Public data can simply be posted on websites or made available | Public data can simply be posted on websites or made available | |||
| through a publicly available API. Public data hosted by a CSP may | through a publicly available API. Public data hosted by a CSP may | |||
| have a reference address at the Registry. | have a reference address at the Registry. | |||
| 4.3.2. Retrieval of Semi-restricted Administrative Data | 4.3.2. Retrieval of Semi-restricted Administrative Data | |||
| A CSP is having service problems completing calls to a specific TN, | A CSP is having service problems completing calls to a specific TN, | |||
| so it wants to contact the CSP serving that TN. The Registry | so it wants to contact the CSP serving that TN. The Registry | |||
| authorizes the originating CSP to access to this information. It | authorizes the originating CSP to access this information. It | |||
| initiates a query to the Registry, the Registry verifies the | initiates a query to the Registry, the Registry verifies the | |||
| requestor and the requested data and Registry responds with the | requestor and the requested data and Registry responds with the | |||
| serving CSP and contact data. | serving CSP and contact data. | |||
| Alternatively that information could be part of a distributed data | Alternatively that information could be part of a distributed data | |||
| store and not stored at the Registry. In that case, the CSP has the | store and not stored at the Registry. In that case, the CSP has the | |||
| data in a local distributed data store and it initiates the query to | data in a local distributed data store and it initiates the query to | |||
| the local data store. The local data store responds with the CSP and | the local data store. The local data store responds with the CSP and | |||
| contact data. No verification is necessary because it was done when | contact data. No verification is necessary because it was done when | |||
| the CSP was authorized to receive the data store. | the CSP was authorized to receive the data store. | |||
| skipping to change at page 21, line 34 ¶ | skipping to change at page 21, line 34 ¶ | |||
| [10] Rosenberg, J. and C. Jennings, "The Session Initiation | [10] Rosenberg, J. and C. Jennings, "The Session Initiation | |||
| Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, | Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, | |||
| January 2008, <http://www.rfc-editor.org/info/rfc5039>. | January 2008, <http://www.rfc-editor.org/info/rfc5039>. | |||
| [11] Peterson, J., Jennings, C., and R. Sparks, "Change Process | [11] Peterson, J., Jennings, C., and R. Sparks, "Change Process | |||
| for the Session Initiation Protocol (SIP) and the Real- | for the Session Initiation Protocol (SIP) and the Real- | |||
| time Applications and Infrastructure Area", BCP 67, | time Applications and Infrastructure Area", BCP 67, | |||
| RFC 5727, DOI 10.17487/RFC5727, March 2010, | RFC 5727, DOI 10.17487/RFC5727, March 2010, | |||
| <http://www.rfc-editor.org/info/rfc5727>. | <http://www.rfc-editor.org/info/rfc5727>. | |||
| [12] Peterson, J., "A Framework and Information Model for | [12] Newton, A. and S. Hollenbeck, "Registration Data Access | |||
| Protocol (RDAP) Query Format", RFC 7482, | ||||
| DOI 10.17487/RFC7482, March 2015, | ||||
| <http://www.rfc-editor.org/info/rfc7482>. | ||||
| [13] Peterson, J., "A Framework and Information Model for | ||||
| Telephone-Related Information (TeRI)", draft-peterson- | Telephone-Related Information (TeRI)", draft-peterson- | |||
| modern-teri-00 (work in progress), October 2015. | modern-teri-00 (work in progress), October 2015. | |||
| [13] Peterson, J., "Secure Telephone Identity Credentials: | [14] Peterson, J. and S. Turner, "Secure Telephone Identity | |||
| Certificates", draft-ietf-stir-certificates-03 (work in | Credentials: Certificates", draft-ietf-stir- | |||
| progress), March 2016. | certificates-06 (work in progress), July 2016. | |||
| [14] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- | [15] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- | |||
| Huguenin, "Verification Involving PSTN Reachability: | Huguenin, "Verification Involving PSTN Reachability: | |||
| Requirements and Architecture Overview", draft-jennings- | Requirements and Architecture Overview", draft-jennings- | |||
| vipr-overview-06 (work in progress), December 2013. | vipr-overview-06 (work in progress), December 2013. | |||
| [15] Bellur, H. and C. Wendt, "Distributed Registry Protocol", | [16] Bellur, H. and C. Wendt, "Distributed Registry Protocol", | |||
| draft-wendt-modern-drip-00 (work in progress), October | draft-wendt-modern-drip-00 (work in progress), October | |||
| 2015. | 2015. | |||
| [16] Rosenberg, J. and H. Schulzrinne, "Session Initiation | [17] Rosenberg, J. and H. Schulzrinne, "Session Initiation | |||
| Protocol (SIP): Locating SIP Servers", RFC 3263, | Protocol (SIP): Locating SIP Servers", RFC 3263, | |||
| DOI 10.17487/RFC3263, June 2002, | DOI 10.17487/RFC3263, June 2002, | |||
| <http://www.rfc-editor.org/info/rfc3263>. | <http://www.rfc-editor.org/info/rfc3263>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Jon Peterson | Jon Peterson | |||
| Neustar, Inc. | Neustar, Inc. | |||
| 1800 Sutter St Suite 570 | 1800 Sutter St Suite 570 | |||
| Concord, CA 94520 | Concord, CA 94520 | |||
| End of changes. 26 change blocks. | ||||
| 55 lines changed or deleted | 56 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||