[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Enum] [Fwd: I-D submission:draft-lind-infrastructure-enum-reqs-01]
Doug:
Thanks. Your point is a good one; we did not intend to imply a single
URI for all services or protocols but
I see upon reflection our language might be taken in that way.
Penn
-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
Douglas Ranalli
Sent: Wednesday, October 19, 2005 8:31 AM
To: 'Richard Shockey'; enum at ietf.org
Subject: RE: [Enum] [Fwd: I-D
submission:draft-lind-infrastructure-enum-reqs-01]
Penn and Steve,
Nice work on this first draft of Carrier-ENUM requirements. One comment
regarding scope of the solution. Section 1.1 "Definition" defines
Infrastructure-ENUM as a service that returns a single URI identifying a
point of interconnection. Consider broadening the scope of the first
sentence of section 1.1 as follows:
"...to map a telephone number into one or more URIs that identify
protocol or service specific points of interconnection..."
Doug
-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
Richard Shockey
Sent: Tuesday, October 18, 2005 12:46 PM
To: 'enum at ietf.org'
Subject: [Enum] [Fwd: I-D submission:
draft-lind-infrastructure-enum-reqs-01]
ENUM S. Lind
Internet-Draft AT&T Labs
Expires: April 22, 2006 P. Pfautz
AT&T
October 18,
2005
Carrier/Infrastructure ENUM Requirements
draft-lind-infrastructure-enum-reqs-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 April 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides requirements for "infrastructure" or
"carrier"
ENUM, defined as the use of RFC 3761 technology to facilitate
interconnection of networks for E.164 number addressed services, in
particular but not restricted to VoIP.
Lind & Pfautz Expires April 22, 2006 [Page 1]
Internet-Draft Carrier ENUM Requirements October 2005
Conventions used in this document
RFC2119 [1] provides the interpretations for the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
1. Infrastructure ENUM
1.1. Definition
Infrastructure ENUM is defined as the use of the technology in
RFC3761 [2] by the carrier-of-record for a specific E.164 number [3]
to map a telephone number into a URI that identifies a specific
point
of interconnection to that service provider's network that could
enable the originating party to establish communication with the
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.
For purposes of this document, "Carrier of Record" refers to the
entity that provides PSTN service for an E.164 number with the
understanding that this definition is ultimately a matter for
national authorities to determine.
1.2. Background
Carriers use E.164 numbers currently as their main naming and
routing
vehicle. Carrier ENUM in e164.arpa or another publicly 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 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.
2. Requirements for Infrastructure ENUM
Lind & Pfautz Expires April 22, 2006 [Page 2]
Internet-Draft Carrier ENUM Requirements October 2005
2.1.
Infrastructure ENUM SHALL provide a means for a carrier to populate
DNS RRs in a common publicly accessible namespace for the E.164
numbering resources for which it is the carrier-of-record.
2.2.
Queries of infrastructure ENUM FQDNs MUST return a result, even if
the result is NXDOMAIN. Queries must not be rejected, e.g. based on
ACLs.
2.3.
Infrastructure ENUM SHALL support RRs providing a URI that can
identify a point of interconnection for delivery of communications
addressed to the E.164 number.
2.4.
Infrastructure ENUM SHALL support an IRIS capability that allows
qualified parties to obtain information regarding the E.164
numbering
resources and the corresponding carrier-of-record.
2.5.
Implementation of Infrastructure ENUM MUST NOT restrict 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.
2.6.
Infrastructure ENUM SHALL be implemented under a TLD that can
support
reliability and performance suitable for PSTN applications.
2.7.
Infrastructure ENUM MUST 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.
2.8.
Proposed implementations of Infrastructure ENUM SHOULD
a. Minimize changes required to existing requirements that are part
of RFC 3761
Lind & Pfautz Expires April 22, 2006 [Page 3]
Internet-Draft Carrier ENUM Requirements October 2005
b. Work with open numbering plans
c. Restrict additional functionality to carrier resolvers.
d. Minimize the number of lookups required to obtain as many NAPTR
records (end-user and carrier) as possible.
e. Minimize the client knowledge of the numbering plan required.
f. Maximize synergies with end-user ENUM
g. Support interworking with private ENUM trees.
3. Security Considerations
Existing security considerations for ENUM detailed in [2] 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.
Some parties have expressed concern that a carrier ENUM could
compromise end user privacy by making it possible for others to
identify unlisted or unpublished numbers based on their registration
in ENUM. This can be avoided if carriers register all of the their
allocated (as opposed to assigned) numbers. Unassigned numbers
should be provisioned to route to the carrier's network in the same
fashion as assigned numbers and only then provide an indication that
they are unassigned. In that way, carrier registration of a number
in ENUM provides no more information about status of a number than
could be obtained by dialing it.
4. IANA Considerations
IANA considerations will depend on the architecture ultimately
chosen
to meet the requirements.
5. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Lind & Pfautz Expires April 22, 2006 [Page 4]
Internet-Draft Carrier ENUM Requirements October 2005
Application (ENUM)", RFC 3761, April 2004.
[3] International Telecommunications Union-T, "The International
Public Telecommunication Number Plan", Recommendation E.164",
May 1997.
Lind & Pfautz Expires April 22, 2006 [Page 5]
Internet-Draft Carrier ENUM Requirements October 2005
Authors' Addresses
Steven Lind
AT&T Labs
180 Park Ave
Florham Park, NJ 07932-0971
USA
Email: slind at att.com
Penn Pfautz
AT&T
200 S. Laurel Ave
Middletown, NJ 07748
USA
Email: ppfautz at att.com
Lind & Pfautz Expires April 22, 2006 [Page 6]
Internet-Draft Carrier ENUM Requirements October 2005
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 at ietf.org.
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lind & Pfautz Expires April 22, 2006 [Page 7]
--
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum