Network Working Group D. Schwartz Internet-Draft Kayote Networks Intended status: Informational E. Katz Expires: July 5, 2007 XConnect Global Networks January 2007 E.164 Number Provisioning - Data Set Requirements draft-schwartz-peppermint-e164-provisioning-data-set-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 July 5, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This document outlines which information should be captured when E.164 numbers are provisioned within a central registry. This document is not a specification but rather a set of information which, when associated with an addressable entity can assist in applying policy to subsequent queries. Schwartz & Katz Expires July 5, 2007 [Page 1] Internet-Draft E.164 provisioning data set January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Provisioning Information . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Schwartz & Katz Expires July 5, 2007 [Page 2] Internet-Draft E.164 provisioning data set January 2007 1. Introduction When writing rule based engines to provide filtered access to E.164 data it is often necessary to have more information available for the query than just the address of record (AOR) that corresponds to a particular number. This additional required information is the subject of this draft document. The data set in this document can - and should be - extended and is intended to spur discussion that will result in a complete set. 2. Scope This document focuses on the supporting data set that is required to properly provisioning E.164 numbers. A discussion of the mechanism to transfer or upload this data to the registry or the protocols used for this purpose is beyond the scope of this document. 3. Provisioning Information The provisioning data can be broken down into two categories: static and dynamic. Static information is that which is associated with the owner of the resource and remains constant from query to query. Dynamic information is that which can be factored into "profiles" or views of the data, each with potentially different data. o Static Information The data in this category relates to the identification, ownership and general validity of the number. 1. Value The value is the resource that is being sought. This value may be a fully qualified E.164 number (e.g. 12127775555), or alternatively, the value may be a number representing a range of numbers (e.g. 1212777). In this latter case the "length" field defined below is needed to establish the limits of the number range. 2. Range This and the next field are used to assist in resolving ranges into individual and unique valid E.164 numbers. The Range field is a Boolean value, which indicates whether the resource specified in the "Value" field is a range that needs to be expanded out to the "length" number of digits, or Schwartz & Katz Expires July 5, 2007 [Page 3] Internet-Draft E.164 provisioning data set January 2007 alternatively, an individual number that does not require further manipulation. 3. Length This field is used for expanding ranges to individual unique numbers. 4. CreationDateTime The value "CreationDateTime" refers to the date on which this resource was first provisioned by this service provider. If the date does not match the current date and time this record contains modifications to an existing Value. If the date does match the current date than this is a new record. + TimeZone All DateTime fields must include TimeZone information for normalization. 5. Type There is value in knowing what type of resource this is (e.g. residential, call shop, etc). Different types of resources have different usage patterns and capturing this information can assist in developing fraud detection engines 6. Privacy This field is a flag indicating whether this number is publicly available to anyone or whether there has to be a predetermined policy in place in order for the number to be given out 7. Ownership The Ownership field consists of additional subfields defining the ownership of the provisioned e164 resource. At any given time there can be multiple "owners" of a given resource. The three levels described in this document are Carrier of Record, Service Provider and End User. Since it is quite possible that these are three distinct entities they all must be specified for the provisioned resource. Since regulatory issues allow for ownership transfer to and from different ServiceProviders, each ServiceProvider field must be qualified via activation dates. Schwartz & Katz Expires July 5, 2007 [Page 4] Internet-Draft E.164 provisioning data set January 2007 + CarrierOfRecord As defined in [2] the Carrier of Record is typically a service provider that is authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA). + ServiceProvider The ServiceProvider field indicates the party that "sells" the resource to the end user. ServiceProvider field is subject to dates as defined below. - ActivationDateTime There are many reasons why it is possible for a number to be provisioned but not yet active. For example, consider the situation in which a service provider provisions a number range, but activates only the actual numbers that have been "sold" to customers. The existance of an "ActivationDateTime" field would enable the service to activate only a single number or range of numbers at some future time. - DeactivationDateTime Similar to the ActivationDateTime field described above, a DeactivationDateTime field could be used to port numbers to a different provider to comply with regional number portability requirements. - TimeZone All DateTime fields must include TimeZone information for normalization. + EndUser The EndUser field indicates the user to which this number was provisioned. Note that there can be subfields associated with the EndUser that provide more information about this user. Only one such field (EndUserTimeZone) is presented here as it is useful when creating user based policy engines. - EndUserTimeZone Knowing the time zone of the user to which this number Schwartz & Katz Expires July 5, 2007 [Page 5] Internet-Draft E.164 provisioning data set January 2007 is provisioned can assist in developing receiving user time based policy o Dynamic Information The data in this section belongs in a category that is dependent on "who is asking". Some of the provisioned information in this section is querying party dependent while other information is queried data dependent. Each set of "dynamic" information is grouped into a "profile" or "view" and there are potentially many profiles for each static resource record. Specifically, there is always at least one profile for each static record representing the "default" behavior and 0 or more "specialized" profiles that override the default profile for requests that match the criteria of the profile. * Profile + QueryDataInformation 1. Validity The validity field is used to define a window in which this profile is active. The following three subfields provide higher resolution for this field. o StartDateTime o StopDateTime o TimeZone 2. AddressOfRecord The AOR field documents the actual location information for the associated resource. The following two subcategories are provided for additional flexibility. o Regex o TerminationDomain + QueryingPartyInformation 1. QueryFromLocation This includes both a user id as well as an IP/s from where the queries will emanate. Schwartz & Katz Expires July 5, 2007 [Page 6] Internet-Draft E.164 provisioning data set January 2007 o QueryUserID o QueryUserAddress 2. QueryMechanism Depending on the query mechanism used, it may be more advantageous to resolve to a different AOR. For example, depending on which protocol is used, it might be possible to provide more extensive routing information. Alternatively, the registry may choose to send different information back to the querying party depending on the security of the query communication path. This subsection delineates these considerations. o QueryType There are many protocols that can be used to perform the query. While ENUM is one of the more popular protocols there is no reason other protocols (e.g. SIP 302) cannot be used as well. Thus the Type of Query field indicates which protocol will be used for this profile. o QuerySecurity It is important to secure the location lookup process especially if the lookup is remote. This Security field would include values such as "=IPSec"[1] 4. Security Considerations This document introduces no new security considerations. 5. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 6. Acknowledgements This document is based in part on contributions made by Brocha Strous, David Koppel, Ofer Mizrachi, Mike Grynberg and Yael Berlinger of Kayote Networks and Natan Tiefenbrun of XConnect Global Networks. Schwartz & Katz Expires July 5, 2007 [Page 7] Internet-Draft E.164 provisioning data set January 2007 7. References 7.1. Normative References [1] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 7.2. Informative References [2] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", draft-ietf-enum-infrastructure-enum-reqs-03.txt, August 2006. Authors' Addresses David Schwartz Kayote Networks Malcha Technology Park Building # 1 Jerusalem 90961 Israel Phone: +972 52 347 4656 Email: david.schwartz@kayote.com URI: www.kayote.com Eli Katz XConnect Global Networks 1 Ballards Lane London N3 1LQ United Kingdom Phone: +44 (0) 870 794 9990 Fax: +44 (0) 870 794 9991 Email: ekatz@xconnect.net URI: www.xconnect.net Schwartz & Katz Expires July 5, 2007 [Page 8] Internet-Draft E.164 provisioning data set January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). 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 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 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). Schwartz & Katz Expires July 5, 2007 [Page 9]