One document matched: draft-schwartz-peppermint-e164-provisioning-data-set-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 08:57:46 |