DRINKS WG Debbie Guyton Internet Draft Telcordia Intended Status: Proposed Standard July 07, 2008 Expires: January 07, 2009 Key Data for a Registry Provisioning Interface draft-guyton-drinks-registry-data-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 07, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines data that should be included in a provisioning interface for a Registry. The provisioning interface may be used in (near) real time, or periodically, from a service provider's service provisioning system to establish and administer telephone number (TN) and associated routing information in the Registry after necessary validations. Based on 1) effective date/time specified for the data and 2) validation of the TN assignee, these data will be used to define selective routing views for various recipient service providers which would be reflected in ENUM-SIP address servers. In addition, the concept of multiple TNs sharing a common routing pattern simplifies the definition and administration of routing data. D. Guyton Expires 01/07/09 [Page 1] Registry Provisioning Interface July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Key Provisioning Interface Data and Associated Benefits. . 3 3. Concept of Validation to Control the Distribution of Data. 6 4. Summary of Benefits. . . . . . . . . . . . . . . . . . . . 6 5. Formal API Definition. . . . . . . . . . . . . . . . . . . 7 6. Security Considerations. . . . . . . . . . . . . . . . . . 7 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . 7 9. Author's Addresses . . . . . . . . . . . . .. . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 Intellectual Property Statement . . . . . . . . . . . . . . . 8 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The intent of this contribution is to describe key data elements that should be present in a provisioning interface to a Registry, including some concepts that lead to additional benefits above and beyond the basic TN and associated route information. These include the concept of an effective date/time, the concept of a recipient group of defined service providers so that selective routing is possible, and the concept of a destination tag, or common routing pattern, associated with a logical grouping of TNs. This contribution is being provided to get agreement that these concepts are beneficial to the Industry and to identify other parties interested in contributing to the development of a provisioning Web Services Description Language [WSDL] for a Registry database defined using these concepts. This document is organized as follows: o Section 2 describes some recommended key data for a Registry provisioning interface and the associated benefits these data provide. o Section 3 discusses the use of validation and how it is used to control the distribution of data from the Registry to the ENUM-SIP address servers. o Section 4 summarizes the benefits realized by the concepts discussed in this contribution. D. Guyton Expires 01/07/09 [Page 2] Registry Provisioning Interface July 2008 2. Key Provisioning Interface Data and Associated Benefits 2.1 Dial Code to Destination (DCD) Association Data DCD data associates dial codes (primarily TNs, but could also be shorter codes for larger code blocks) with a Destination Tag for logical groupings of dial codes that share a common routing pattern to a Destination or Entry Point in a host network. The following is a list of data and definitions and associated benefits for DCD data: 1. Country Code (CC) - necessary for filtering and validation support 2. Dial Code (DC) - this may be the national component of an E.164 number (e.g., 10 digit number for NANP (CC=1), TN length varies by CC), or it may be leading digits or a prefix of the national number (e.g., NPA-NXX for NANP (CC=1) or National Destination Code (NDC) globally). 3. Dial Code Type (DC Type) - allows for filtering and validation support, e.g., o DC Type = E for global e.164 TNs o DC Type = C for NDC 4. Destination Tag (DT) - is the name of a common routing pattern (a combination of destination URIs and Resource Records for various services) with which the Dial Code is being associated. 5. Effective Date/Time (expressed as UTC/GMT) - provides a means of establishing the dial code to destination mapping in the Registry in advance, prior to being effective. This allows more than one service provider to provision data pertaining to the same dial code (i.e., prior to the completion of a porting process). However, the record for the current assignee of the Dial Code is the only one that can be valid. See Validation discussion in Section 3. This approach also allows support for network planning and re-arrangements by changing routing patterns for selected Dial Codes at specified effective date/times. In general, this concept provides the capability to establish the relationship, modify it with a specified effective date/time, or discontinue the relationship. (Note that translating to various time zones for ease of loading or viewing data should be straightforward.) 6. VoIP Origination Point - for example, can assume values of "Yes", "No", or "Unknown". While other DCD data applies to terminating calls, it would be useful to specify this originating data if known. D. Guyton Expires 01/07/09 [Page 3] Registry Provisioning Interface July 2008 For example, in some regulatory environments, different rate structures and interconnection rules apply to PSTN-originated vs. VoIP/IMS-originated calls, so this distinction is potentially critical. 7. Assignee/Owner Identity - a service provider identity, or equivalent identification, of the assignee of the dial code. 8. Administrator Identity - a service provider identity, or equivalent identification, of the administrator (company) that is administering and managing the data through the provisioning interface. This may be a contracted entity, and may not necessarily be the same as the assignee. 9. Network Provider type - although, in general, it is expected that the carrier who is the assignee of the dial code would define the DCD (the DC to Destination Tag relationship), this would allow the use of multiple carriers (e.g., transit carriers) each to provide a routing pattern and thus allow choice. 2.2 Host Entry Point data The Host Entry Point (HEP) data associates the Destination Tag (DT) with a pattern of associated host or gateway routing information, expressed as full resource records (e.g., NAPTR), or as component elements of resource records (e.g., RegExp/URI). The data elements of this pattern of routing information may be made available to all participating service providers or only to a specified Recipient Group (a collection of service providers to be given a common route). See Section 3.3 for definition of a Recipient Group. This allows for selective routing to various groups of service providers if needed, or, for completeness, perhaps a default of "All" where every service provider gets the same route. The following is a list of data and definitions and associated benefits for HEP data. 1. Destination Tag (DT) that identifies the common routing pattern 2. Recipient Group (RG) associated with this DT 3. Host Address - may be expressed as a full Resource Record (e.g., NAPTR) or as only the RegExp/URI Note that for filtering, manipulating and validation, it is more useful to provide the data elements making up a NAPTR. 4. Resource Record Type - specifying the type of resource record, e.g., NAPTR, NS, DNAME, CNAME D. Guyton Expires 01/07/09 [Page 4] Registry Provisioning Interface July 2008 5. Scheme - specifying the scheme of interest, e.g., SIP, MAILTO, TEL (for NAPTRs only) 6. Service - specifying the type of service being routed, e.g., E2U+SIP, E2U+SMS, E2U+MMS, E2U+EMAIL, E2U+PSTN (for NAPTRs only) 7. Preference - could be provided or defaulted (for NAPTRs only) 8. Order - could be provided or defaulted (for NAPTRs only) 9. Effective Date/Time (UTC/GMT) - allowing (in a similar manner as discussed for DCD above) for establishing a record, modifying a record, or discontinuing a record. This would be beneficial to support network planning and re-arrangements where network entry gateways change or traffic (based on routing patterns or recipient groups) are partitioned and directed to several gateways based on an effective date/time. 10. Owner Identity - identifies the service provider that defines or "owns" this relationship of DT, Host Address, and RG 11. Administrator Identity - identifies the administrator (company) that is providing the data through the Registry provisioning interface and may not necessarily be the same as the owner. 2.3 Recipient Group and Recipient Group Members Recipient Group (RG) data associates a number of Recipient Group Members into an identified group of service providers that receive the same routing information. A default group of "All" can be defined when no selective routing is desired. The data elements would include: 1. RG Member (RGM) - a service provider identity, or corporate identity, of a service provider to be included in the group 2. RG - a name for the Recipient Group 3. Effective Date/Time - in this case a member is either in the group or not so they become effective or are discontinued at a given date/time 4. Owner Identity - identifies the service provider that defines or "owns" this relationship of RGM and RG 5. Administrator Identity - identifies the administrator (company) that is providing the data through the Registry provisioning interface and may not necessarily be the same as the owner. D. Guyton Expires 01/07/09 [Page 5] Registry Provisioning Interface July 2008 2.4 General Notes on the Provisioning Interface Data Some general notes about provisioning the data include the following: 1. The assignee/owner for the DCD, HEP, and RG must be identified as the same assignee/owner service provider. 2. Although all of these data are needed to support routing, a Registry provisioning interface approach may need to consider the fact that the data may come from different sources in the organization. DCD data may be provisioned as the output of a service provider's service provisioning process, whereas, the HEP data may be provisioned as the output of a service provider's network planning and management process as it focuses on the common routing patterns, or Destination Tags, and the entry points or gateways in the network. 3. Concept of Validation to Control the Distribution of Data With the above framework for the DCD in Section 2.1, TN-to-assignee validation can be performed in near-real-time as an effective date/time is reached, or as a TN port becomes effective, in order to validate the assignee of the TN before allowing the information to be distributed from a Registry to address servers. Only valid records are distributed or provisioned in each address server. For example, more than one service provider can have the same TN registered in the Registry with overlapping effective date/times. This is likely and necessary for most timely handling in a number porting process. Only the one record that is valid will be distributed to the address servers. If a record already exists in an address server from the previous assignee, it would be deleted and the new assignee's record added as validation shows a change of assignee - one becomes invalid, the other becomes valid. Thus, the recommended approach is to allow the validation to control the distribution of data to address servers triggered by the change in TN assignee in the Registry or triggered by a change in effective date/time. Similarly for a HEP record in Section 2.2, the distribution or change in routing information through the use of the DT, Host Address, and RG can be managed by an effective date/time to support network growth and re-arrangement. 4. Summary of Benefits Using effective date/time and an associated validation mechanism allows the entry of multiple TN and associated routing information during the porting process in order to distribute the new routing information upon D. Guyton Expires 01/07/09 [Page 6] Registry Provisioning Interface July 2008 port completion and validation of the new TN-to-assignee relationship. In addition, effective date/time provides flexibility in pre-defining data for network planning and re-arrangements. The validation process controls the distribution by only letting valid records be distributed to address servers. As changes occur, the validation mechanism initiates the deletion of no-longer-valid records and distributes the new valid records. Using the concept of a Recipient Group allows the capability of selective routing by providing different entry points to different groups of service providers based on say, level of trust and firewall considerations, or perhaps based on geographic routing needs. Using the concept of a Destination Tag allows multiple TNs to share a routing pattern and routing information can be based on the Destination Tag itself and not the individual TN, thus simplifying the definition and administration of routing data. 5. Formal API Definition TBD in subsequent contribution. The definition will follow the terminology followed in SPEERMINT [I-D.ietf-speermint-terminology]. 6. Security Considerations These will be defined when the provisioning WSDL is defined. 7. IANA Considerations Should there be interest in working on a protocol for the Registry provisioning interface in IETF, a formal IANA consideration section should be drafted with proper registrations for the protocol namespace(s), versions, etc. 8. Informative References [WSDL] W3C, "W3C Recommendation, Web Services Description Language (WSDL) Version 1.1", March 2001. [I-D.ietf-speermint-terminology] Meyer, R. and D. Malas, "SPEERMINT Terminology", draft-ietf-speermint-terminology-16. txt(work in progress), February 2008. 9. Authors' Addresses Debbie Guyton, Ph.D. Telcordia Technologies 1 Telcordia Drive/RRC 1E222 Piscataway, NJ 08854 Email: dguyton@telcordia.com D. Guyton Expires 01/07/09 [Page 7] Registry Provisioning Interface July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). D. Guyton Expires 01/07/09 [Page 8]