idnits 2.17.1 draft-guyton-drinks-registry-data-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 410. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 457 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 07, 2008) is 5770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-16 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRINKS WG Debbie Guyton 3 Internet Draft Telcordia 4 Intended Status: Proposed Standard July 07, 2008 5 Expires: January 07, 2009 7 Key Data for a Registry Provisioning Interface 8 draft-guyton-drinks-registry-data-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 07, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines data that should be included in a provisioning 42 interface for a Registry. The provisioning interface may be used in 43 (near) real time, or periodically, from a service provider's service 44 provisioning system to establish and administer telephone number (TN) 45 and associated routing information in the Registry after necessary 46 validations. Based on 1) effective date/time specified for the data 47 and 2) validation of the TN assignee, these data will be used to 48 define selective routing views for various recipient service providers 49 which would be reflected in ENUM-SIP address servers. In addition, 50 the concept of multiple TNs sharing a common routing pattern simplifies 51 the definition and administration of routing data. 53 D. Guyton Expires 01/07/09 [Page 1] 55 Registry Provisioning Interface July 2008 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Key Provisioning Interface Data and Associated Benefits. . 3 61 3. Concept of Validation to Control the Distribution of Data. 6 62 4. Summary of Benefits. . . . . . . . . . . . . . . . . . . . 6 63 5. Formal API Definition. . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations. . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . 7 66 8. Informative References . . . . . . . . . . . . . . . . . . 7 67 9. Author's Addresses . . . . . . . . . . . . .. . . . . . . 7 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 69 Intellectual Property Statement . . . . . . . . . . . . . . . 8 70 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The intent of this contribution is to describe key data elements that 75 should be present in a provisioning interface to a Registry, including 76 some concepts that lead to additional benefits above and beyond the 77 basic TN and associated route information. These include the concept 78 of an effective date/time, the concept of a recipient group of defined 79 service providers so that selective routing is possible, and the 80 concept of a destination tag, or common routing pattern, associated 81 with a logical grouping of TNs. 83 This contribution is being provided to get agreement that these 84 concepts are beneficial to the Industry and to identify other parties 85 interested in contributing to the development of a provisioning Web 86 Services Description Language [WSDL] for a Registry database defined 87 using these concepts. 89 This document is organized as follows: 91 o Section 2 describes some recommended key data for a Registry 92 provisioning interface and the associated benefits these data 93 provide. 95 o Section 3 discusses the use of validation and how it is used to 96 control the distribution of data from the Registry to the ENUM-SIP 97 address servers. 99 o Section 4 summarizes the benefits realized by the concepts discussed 100 in this contribution. 102 D. Guyton Expires 01/07/09 [Page 2] 103 Registry Provisioning Interface July 2008 105 2. Key Provisioning Interface Data and Associated Benefits 107 2.1 Dial Code to Destination (DCD) Association Data 109 DCD data associates dial codes (primarily TNs, but could also be 110 shorter codes for larger code blocks) with a Destination Tag for 111 logical groupings of dial codes that share a common routing pattern 112 to a Destination or Entry Point in a host network. 114 The following is a list of data and definitions and associated benefits 115 for DCD data: 117 1. Country Code (CC) - necessary for filtering and validation support 119 2. Dial Code (DC) - this may be the national component of an E.164 120 number (e.g., 10 digit number for NANP (CC=1), TN length varies by CC), 121 or it may be leading digits or a prefix of the national number (e.g., 122 NPA-NXX for NANP (CC=1) or National Destination Code (NDC) globally). 124 3. Dial Code Type (DC Type) - allows for filtering and validation 125 support, e.g., 127 o DC Type = E for global e.164 TNs 128 o DC Type = C for NDC 130 4. Destination Tag (DT) - is the name of a common routing pattern (a 131 combination of destination URIs and Resource Records for various 132 services) with which the Dial Code is being associated. 134 5. Effective Date/Time (expressed as UTC/GMT) - provides a means of 135 establishing the dial code to destination mapping in the Registry in 136 advance, prior to being effective. This allows more than one service 137 provider to provision data pertaining to the same dial code (i.e., 138 prior to the completion of a porting process). However, the record 139 for the current assignee of the Dial Code is the only one that can 140 be valid. See Validation discussion in Section 3. 142 This approach also allows support for network planning and 143 re-arrangements by changing routing patterns for selected Dial Codes 144 at specified effective date/times. In general, this concept provides 145 the capability to establish the relationship, modify it with a 146 specified effective date/time, or discontinue the relationship. 148 (Note that translating to various time zones for ease of loading or 149 viewing data should be straightforward.) 151 6. VoIP Origination Point - for example, can assume values of "Yes", 152 "No", or "Unknown". While other DCD data applies to terminating calls, 153 it would be useful to specify this originating data if known. 155 D. Guyton Expires 01/07/09 [Page 3] 157 Registry Provisioning Interface July 2008 159 For example, in some regulatory environments, different rate 160 structures and interconnection rules apply to PSTN-originated vs. 161 VoIP/IMS-originated calls, so this distinction is potentially 162 critical. 164 7. Assignee/Owner Identity - a service provider identity, or 165 equivalent identification, of the assignee of the dial code. 167 8. Administrator Identity - a service provider identity, or 168 equivalent identification, of the administrator (company) that is 169 administering and managing the data through the provisioning interface. 170 This may be a contracted entity, and may not necessarily be the same 171 as the assignee. 173 9. Network Provider type - although, in general, it is expected that 174 the carrier who is the assignee of the dial code would define the 175 DCD (the DC to Destination Tag relationship), this would allow the 176 use of multiple carriers (e.g., transit carriers) each to provide 177 a routing pattern and thus allow choice. 179 2.2 Host Entry Point data 181 The Host Entry Point (HEP) data associates the Destination Tag (DT) 182 with a pattern of associated host or gateway routing information, 183 expressed as full resource records (e.g., NAPTR), or as component 184 elements of resource records (e.g., RegExp/URI). The data elements 185 of this pattern of routing information may be made available to all 186 participating service providers or only to a specified Recipient 187 Group (a collection of service providers to be given a common route). 188 See Section 3.3 for definition of a Recipient Group. This allows for 189 selective routing to various groups of service providers if needed, 190 or, for completeness, perhaps a default of "All" where every service 191 provider gets the same route. 193 The following is a list of data and definitions and associated 194 benefits for HEP data. 196 1. Destination Tag (DT) that identifies the common routing pattern 198 2. Recipient Group (RG) associated with this DT 200 3. Host Address - may be expressed as a full Resource Record (e.g., 201 NAPTR) or as only the RegExp/URI 203 Note that for filtering, manipulating and validation, it is more 204 useful to provide the data elements making up a NAPTR. 206 4. Resource Record Type - specifying the type of resource record, 207 e.g., NAPTR, NS, DNAME, CNAME 209 D. Guyton Expires 01/07/09 [Page 4] 210 Registry Provisioning Interface July 2008 212 5. Scheme - specifying the scheme of interest, e.g., SIP, MAILTO, 213 TEL (for NAPTRs only) 215 6. Service - specifying the type of service being routed, e.g., 216 E2U+SIP, E2U+SMS, E2U+MMS, E2U+EMAIL, E2U+PSTN (for NAPTRs only) 218 7. Preference - could be provided or defaulted (for NAPTRs only) 220 8. Order - could be provided or defaulted (for NAPTRs only) 222 9. Effective Date/Time (UTC/GMT) - allowing (in a similar manner 223 as discussed for DCD above) for establishing a record, modifying 224 a record, or discontinuing a record. 226 This would be beneficial to support network planning and 227 re-arrangements where network entry gateways change or traffic 228 (based on routing patterns or recipient groups) are partitioned 229 and directed to several gateways based on an effective date/time. 231 10. Owner Identity - identifies the service provider that defines 232 or "owns" this relationship of DT, Host Address, and RG 234 11. Administrator Identity - identifies the administrator (company) 235 that is providing the data through the Registry provisioning 236 interface and may not necessarily be the same as the owner. 238 2.3 Recipient Group and Recipient Group Members 240 Recipient Group (RG) data associates a number of Recipient Group 241 Members into an identified group of service providers that receive 242 the same routing information. A default group of "All" can be defined 243 when no selective routing is desired. The data elements would include: 245 1. RG Member (RGM) - a service provider identity, or corporate 246 identity, of a service provider to be included in the group 248 2. RG - a name for the Recipient Group 250 3. Effective Date/Time - in this case a member is either in the 251 group or not so they become effective or are discontinued at a given 252 date/time 254 4. Owner Identity - identifies the service provider that defines or 255 "owns" this relationship of RGM and RG 257 5. Administrator Identity - identifies the administrator (company) 258 that is providing the data through the Registry provisioning interface 259 and may not necessarily be the same as the owner. 261 D. Guyton Expires 01/07/09 [Page 5] 262 Registry Provisioning Interface July 2008 264 2.4 General Notes on the Provisioning Interface Data 266 Some general notes about provisioning the data include the following: 268 1. The assignee/owner for the DCD, HEP, and RG must be identified as 269 the same assignee/owner service provider. 271 2. Although all of these data are needed to support routing, a 272 Registry provisioning interface approach may need to consider the fact 273 that the data may come from different sources in the organization. 274 DCD data may be provisioned as the output of a service provider's 275 service provisioning process, whereas, the HEP data may be provisioned 276 as the output of a service provider's network planning and management 277 process as it focuses on the common routing patterns, or Destination 278 Tags, and the entry points or gateways in the network. 280 3. Concept of Validation to Control the Distribution of Data 282 With the above framework for the DCD in Section 2.1, TN-to-assignee 283 validation can be performed in near-real-time as an effective 284 date/time is reached, or as a TN port becomes effective, in order to 285 validate the assignee of the TN before allowing the information to be 286 distributed from a Registry to address servers. Only valid records are 287 distributed or provisioned in each address server. 289 For example, more than one service provider can have the same TN 290 registered in the Registry with overlapping effective date/times. 291 This is likely and necessary for most timely handling in a number 292 porting process. Only the one record that is valid will be distributed 293 to the address servers. If a record already exists in an address 294 server from the previous assignee, it would be deleted and the new 295 assignee's record added as validation shows a change of assignee - one 296 becomes invalid, the other becomes valid. 298 Thus, the recommended approach is to allow the validation 299 to control the distribution of data to address servers triggered by 300 the change in TN assignee in the Registry or triggered by a change 301 in effective date/time. 303 Similarly for a HEP record in Section 2.2, the distribution or change 304 in routing information through the use of the DT, Host Address, and 305 RG can be managed by an effective date/time to support network growth 306 and re-arrangement. 308 4. Summary of Benefits 309 Using effective date/time and an associated validation mechanism allows 310 the entry of multiple TN and associated routing information during the 311 porting process in order to distribute the new routing information upon 313 D. Guyton Expires 01/07/09 [Page 6] 314 Registry Provisioning Interface July 2008 316 port completion and validation of the new TN-to-assignee relationship. 317 In addition, effective date/time provides flexibility in pre-defining 318 data for network planning and re-arrangements. The validation process 319 controls the distribution by only letting valid records be distributed 320 to address servers. As changes occur, the validation mechanism 321 initiates the deletion of no-longer-valid records and distributes the 322 new valid records. 324 Using the concept of a Recipient Group allows the capability of 325 selective routing by providing different entry points to different 326 groups of service providers based on say, level of trust and firewall 327 considerations, or perhaps based on geographic routing needs. 329 Using the concept of a Destination Tag allows multiple TNs to share 330 a routing pattern and routing information can be based on the 331 Destination Tag itself and not the individual TN, thus simplifying 332 the definition and administration of routing data. 334 5. Formal API Definition 335 TBD in subsequent contribution. The definition will follow the 336 terminology followed in SPEERMINT [I-D.ietf-speermint-terminology]. 338 6. Security Considerations 339 These will be defined when the provisioning WSDL is defined. 341 7. IANA Considerations 342 Should there be interest in working on a protocol for the Registry 343 provisioning interface in IETF, a formal IANA consideration section 344 should be drafted with proper registrations for the protocol 345 namespace(s), versions, etc. 347 8. Informative References 349 [WSDL] W3C, "W3C Recommendation, Web Services Description 350 Language (WSDL) Version 1.1", March 2001. 352 [I-D.ietf-speermint-terminology] Meyer, R. and D. Malas, 353 "SPEERMINT Terminology", draft-ietf-speermint-terminology-16. 354 txt(work in progress), February 2008. 356 9. Authors' Addresses 358 Debbie Guyton, Ph.D. 359 Telcordia Technologies 360 1 Telcordia Drive/RRC 1E222 361 Piscataway, NJ 08854 363 Email: dguyton@telcordia.com 365 D. Guyton Expires 01/07/09 [Page 7] 367 Registry Provisioning Interface July 2008 369 Full Copyright Statement 371 Copyright (C) The IETF Trust (2008). 373 This document is subject to the rights, licenses and restrictions 374 contained in BCP 78, and except as set forth therein, the authors 375 retain all their rights. 377 This document and the information contained herein are provided on 378 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 379 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 380 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 381 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 382 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 383 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 384 FOR A PARTICULAR PURPOSE. 386 Intellectual Property Statement 388 Intellectual Property 390 The IETF takes no position regarding the validity or scope of any 391 Intellectual Property Rights or other rights that might be claimed 392 to pertain to the implementation or use of the technology described 393 in this document or the extent to which any license under such 394 rights might or might not be available; nor does it represent that 395 it has made any independent effort to identify any such rights. 396 Information on the procedures with respect to rights in RFC 397 documents can be found in BCP 78 and BCP 79. 399 Copies of IPR disclosures made to the IETF Secretariat and any 400 assurances of licenses to be made available, or the result of an 401 attempt made to obtain a general license or permission for the use 402 of such proprietary rights by implementers or users of this 403 specification can be obtained from the IETF on-line IPR repository 404 at http://www.ietf.org/ipr. 406 The IETF invites any interested party to bring to its attention any 407 copyrights, patents or patent applications, or other proprietary 408 rights that may cover technology that may be required to implement 409 this standard. Please address the information to the IETF at ietf- 410 ipr@ietf.org. 412 Acknowledgment 414 Funding for the RFC Editor function is provided by the IETF 415 Administrative Support Activity (IASA). 417 D. Guyton Expires 01/07/09 [Page 8]