One document matched: draft-lind-infrastructure-enum-reqs-00.txt
ENUM Working Group
Internet Draft S. Lind
Document: draft-lind-infrastructure-enum-reqs- AT&T
00.txt
Expires: January 2006 July 2005
Infrastructure ENUM Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
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.
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 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.
Abstract
There has been much discussion in various industries about the
concept of infrastructure (or carrier) ENUM. Some of this discussion
has been has been reflected within the ENUM WG mailing list and some
within other organizations, including ETSI, the US ENUM Forum and the
Country Code 1 ENUM LLC. While there has been consensus within some
pockets of individual efforts, there has been little consensus
industry-wide on even what infrastructure ENUM is, why it seems to be
important, or what the requirements for implementing it are.
At the request of the WG co-chairs, this document attempts to gather
together the bits and pieces from those discussions (i.e., I stole
Lind Expires - January 2006 [Page 1]
Infrastructure ENUM Requirements July 2005
the words shamelessly from the various sources) and, with an absolute
minimum of editing, present them in some sort of cohesive manner that
will enable enlightened discussion and hopefully achieve consensus.
Some items listed below may be duplicative and suggest alternative
wordings for similar and other contradictory issues. As such, this
list is very raw and should not be viewed as complete, cohesive or
correct.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [ii].
Table of Contents
1. Infrastructure ENUM............................................3
1.1 Definition.................................................3
1.2 Importance.................................................3
2. Requirements of Infrastructure ENUM............................4
2.1 Provisioning Requirements..................................4
2.2 Architecture Requirements..................................5
2.3 Application Behavior Requirements..........................5
3. Security Considerations........................................6
4. References.....................................................6
5. Author's Addresses.............................................7
6. Intellectual Property Statement................................7
7. Disclaimer of Validity.........................................8
8. Copyright Statement............................................8
Lind Expires - January 2006 [Page 2]
Infrastructure ENUM Requirements July 2005
1. Infrastructure ENUM
1.1 Definition
a. Infrastructure ENUM is defined as the use of RFC 3761 [iii] by
the carrier-of-record for a specific E.164 number [iv] to
translate into a URI that specifies a specific point of
interconnection to that service providerÆs network that could
enable the originating party to establish communication with
associated terminating party. It is separate from any URIs that
the end-user, who registers their E.164 number, may wish to
associate with that E.164 number.
b. Carriers use E.164 numbers currently as their main naming and
routing vehicle. Carrier ENUM in e164.arpa or another public
available tree allows Carriers to link Internet based resources
such as URIs to E.164 numbers (Note: this is the other way round
then User ENUM). This allows Carrier in addition to
interconnecting via the PSTN (or exclusively) to peer via IP-
based protocols. Carriers may announce all E.164 numbers or
number ranges they host, regardless if the final end-user device
is on the Internet, on IP-based closed NGNs or on the PSTN,
provided an access (e.g. SBC or gateway) to the destination
carriers network is available on the Internet. There is also no
guarantee that the originating carrier querying Carrier ENUM
that is able to access the ingress network element of the
destination carriers network. Additional peering and accounting
agreements requiring authentication may be necessary. The access
provided may also be to a shared network of a group of carriers,
resolving the final destination network within the shared
network.
1.2 Importance
User ENUM in many countries requires end user opt-in and may give the
end user the right to select the Tier 2 that hosts the terminal NAPTR
records. These constraints are problematic for interconnection which
requires registration for all served numbers and carrier control of
Tier 2 to ensure reliability.
With the move towards all IP networks applications, interworking must
be addressed in order to facilitate global interoperability.
Different networks should interwork with each other through secure
interfaces that provide a high level of trust, particularly with
regard to any routing information obtained from an ENUM database.
Consideration must be given to how each network will interwork with
other networks.
Lind Expires - January 2006 [Page 3]
Infrastructure ENUM Requirements July 2005
Until now ENUM according to RFC3761 in e164.arpa (User ENUM) has not
been seen as useful to an NGN/Telco/VoIP provider as it is reliant on
user action in terms of registration, insertion of data and
management of that data. Additionally, there is also controversy
regarding the inclusion of data within the NAPTR records which may be
publicly exposed in User ENUM.
2. Requirements of Infrastructure ENUM
For ease in thinking about these requirements and how any proposed
implementation might address them, they have been divided into three
categories: provisioning, architecture, and application behavior.
2.1 Provisioning Requirements
a. It should not require the introduction of new constructs within
existing standards, such as new types or changed semantics of
NAPTR records.
b. The impact on existing implementations of User ENUM should be
kept to a minimum. This implies that modifications to existing
RFCs e.g. 3761, 3401-4 should be avoided.
c. It should keep the option open for other types of closed-user-
group type applications, which might not naturally fit into the
predominantly voice-oriented - carrier ENUM scenario, like SMS
or MMS POI resolution.
d. Infrastructure ENUM should not remove the need for
authentication that the party inserting, modifying or removing
data in NAPTR records has a right to the corresponding number.
Authentication is still required and an appropriate
authentication procedure needs to be in place between the ENUM
Tier 1 Registry and the carrier serving the number.
e. Implementation of Infrastructure ENUM should not impact the
ability of an end-user, in a competitive environment, to choose
a Registrar and/or Tier 2 name server provider for end-user ENUM
registrations.
f. Designated DNS infrastructure for housing Infrastructure ENUM-
related NAPTR records should have ôcarrier-classö reliability
and performance.
Lind Expires - January 2006 [Page 4]
Infrastructure ENUM Requirements July 2005
2.2 Architecture Requirements
a. It should meet all reasonable privacy concerns about visibility
of information an end user has no control over, for example
discovery of unlisted numbers, or inadvertent disclosure of user
identity.
b. provide information on how to route a service to a point of
carrier interconnection or ALG as expressed as a URI. For
privacy and or network security reasons this information may_
need to be restricted to service providers and not generally
available to end users. [editorÆs note: some have argued that
they might provide a carrier record that generally points to a
public interconnection point, but would provide pointers to
specific interconnection points for specific interconnecting
network providers.]
c. It should be possible to introduce the scheme in a timely
manner, supporting current carrier needs. Consequently, it is
desirable to deploy the scheme without re-opening already
settled questions of roles, responsibilities and international
coordination.
d. It should leave tree shape intact, i.e. requiring no wholesale
changes to existing tree layout.
e. It should be applicable for use with all national numbering
plans; particular challenges may be to ensure that a global
implementation is compatible with the use of variable length
numbering (e.g. as used in Germany and Austria) and DDI blocks.
f. It should work with both closed and open number plans without
resorting to wildcard records in the non-user controlled part of
the DNS, both to avoid associated semantic problems as well as
keeping the route to DNSSEC deployment open.
g. Some other groups, such as the GSM-A, have already decided to
use a separate domain of their own for infrastructure ENUM
purposes; e.g. "e164enum.net". The envisaged solution should
also include these ENUM domains within a global ENUM
infrastructure or at least to allow and facilitate interworking
between these different domains.
2.3 Application Behavior Requirements
Lind Expires - January 2006 [Page 5]
Infrastructure ENUM Requirements July 2005
a. A dialed E.164 number using ENUM should enable a call to go
through.
b. A single DNS lookup should suffice to resolve any given number.
c. A minimum number (ideally one) of independent lookups should be
required to obtain as many NAPTR records (end-user and carrier)
as possible.
d. A minimum number (ideally zero) of dependent lookups should be
required to obtain as many NAPTR records (end-user and carrier)
as possible.
e. Additional functionality should only be imposed on carrier
resolvers.
f. It should leave user ENUM resolution semantics intact, i.e.
requiring no wholesale changes to existing user ENUM resolvers.
g. Pre-existing knowledge of the numbering format should be kept to
a minimum.
3. Security Considerations
Existing security considerations for ENUM detailed in RFC 3761 still
apply. Note that some registration validation issues concerning end
user ENUM may not apply to carrier ENUM. Where the Tier 1 registry
is able to identify the carrier serving a number (e.g., based on
industry data for number block assignments and number portability),
registration might be more easily automated and a separate registrar
not required.
4. References
i Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
ii Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
iii Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
Lind Expires - January 2006 [Page 6]
Infrastructure ENUM Requirements July 2005
iv ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
5. Author's Addresses
Steven D. Lind
AT&T
Room A201
180 Park Avenue
Florham Park, NJ 07932
USA
Phone: +1-973-236-6787
Email: sdlind@att.com
6. Intellectual Property Statement
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Lind Expires - January 2006 [Page 7]
Infrastructure ENUM Requirements July 2005
7. Disclaimer of Validity
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.
8. Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Lind Expires - January 2006 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 18:29:39 |