One document matched: draft-vaudreuil-enum-e164dir-00.txt
Telephone Number Mapping A. Brown
Internet Draft Nortel Networks
Document: <draft-vaudreuil-enum-e164dir-00.txt> Greg Vaudreuil
Lucent Technologies
March 7, 2000
Telephone Number Based Directory Service
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
This document outlines the principles for the operation of a
telephone number directory service. This service provides for the
resolution of telephone numbers into Internet domain name addresses
and service specific directory discovery.
Table of Contents
1. Abstract........................................................1
2. Introduction....................................................2
3. Scope...........................................................2
4. Overview........................................................2
4.1 First Level: ENUM Service......................................2
4.2 Second Level: Service-Specific Repository Discovery............4
4.3 Third Level: Service-Specific..................................4
5 System Description...............................................4
5.1 Telephone Number to Domain Name Mapping........................6
5.1.1 Example: Simple Service Requiring Only First Level Query.....7
5.2 Service Specific Repository Discovery..........................8
5.2.1 Example: Hypothetical Reachme Service........................8
5.2.2 Example: Hypothetical Voicemail Service......................9
5.2.3 Example: SIP Call Setup Service Request.....................10
Telephone Number Based Directory Services March 2000
6. Security Considerations........................................11
7. References.....................................................12
9. Acknowledgments................................................12
10. Author's Addresses............................................13
11. Appendix 1: ENUM in the North American Numbering Plan.........14
2. Introduction
This document outlines the principles for the operation of a
telephone number directory service. This service provides for the
resolution of telephone numbers into Internet domain name addresses
and service specific directory discovery.
This is the first of a document set describing a converged proposal
merging the directory work led by Anne Brown through the VPIM
initiative within the Electronic Messaging Association (EMA) and the
directory work initiated by Greg Vaudreuil within the TeleMessaging
Industry Association (TMIA).
Please send comments on this document to the ENUM working group.
3. Scope
This document defines the architecture and mechanics necessary to
implement a telephone number based Internet directory system. This
solution enables an extensible set of services to be provided for a
given telephone number. Example services may include IP telephony,
Internet Fax, VPIM voice messaging, Internet paging, geographic
phone location, and others. Each service is to be separately
defined and identified using a unique, registered service
identifier.
This document does not specify the particulars of any telephone
number based service. In particular, it does not describe how phone
calls are placed, routed, or terminated or how voice messages are
routed.
4. Overview
This phone number based directory system implements a three level
architecture, the first two of which are the ENUM service itself.
This model is based on analysis of pre-existing administrative
structures, generalized service requirements, and candidate protocol
capabilities.
4.1 First Level: ENUM Service
The first level is the mapping of an E.164 formatted international
telecommunication number into an Internet domain name identifier.
This may or may not involve more than one referal in DNS. From the
clients perspective, this will appear as one query. The resulting
Telephone Number Based Directory Services March 2000
domain identifier indicates either the authority to which the phone
number has been delegated, a sub-delegated authority (e.g., a
private enterprise), an individual to which a telephone number has
been assigned, or a service provider acting on behalf of one of the
above. The domain name that is returned in an ENUM query will
depend on existing and evolving business and regulatory agreements.
This ENUM architecture supports a number of different possible
arrangements which may occur.
The delegation of telephone numbers from the root authority (the
ITU) down to individuals is a well-established system that can be
utilized. These telephone number registrars have a trusted
relationship with their delegated carriers or subsidiary registrars;
a valuable asset to ensure protection against various attacks. Note
that in this model, the delegation of telephone number blocks or
individual numbers to a corporation or to an individual can be
administratively and technically modeled as a sub-delegation to
another carrier. With that additional information publically
registered, the mapping between telephone number and these domain
names can be provided by any neutral entity. The delegated
authority, sub-delegated authority, or individual may arrange to
have a third-party (e.g., a service provider) list their
information. In this case the service provider's domain would be
returned in the ENUM query.
This approach differs from Patrik's [FALTSTROM] proposal in
that it assumes that service information and per-resource based
information (e.g. individual email addresses, sip addresses,
etc.) will be held privately and not in the ENUM top level
service.
This approach also differs from Patrik's in that it recognizes
that other protocols besides DNS may be used in satisfying
service-specific queries for information on a particular
telephone number. DNS is often not appropriate for maintaining
information (such as email addresses) on a per resource basis
[URN-DNS-01]. It is understood that each service type (and its
related protocols) can define its own methods (including DNS,
if deemed effective) for accessing information on resources
related to that particular service.
The telephone number delegation information changes infrequently.
However, when a change to this data is made, the information must be
rapidly propogated through the directory system. Inconsistencies
between the authorative data and cached data may result in loss of
service, mis-routing of communications, and/or service loops. An
effective ENUM service requires that DNS time-to-live fields be set
to an appropriate value consistent with the telephone number
reassignment policies if the delegating authority. For example,
ported telephone numbers may be reassigned from one carrier to
another, a change that must be made quickly to avoid routing loops.
Records supporting that service require a TTL of Zero and secondary
Telephone Number Based Directory Services March 2000
DNS servers that use rapid replication techniques to ensure the data
is consistent.
4.2 Second Level: Service-Specific Repository Discovery
The second level uses SRV RRs to discover the identity of the
appropriate service-specific directory such as an LDAP directory
server, H.323 gatekeeper, or other service-specific repository type.
In this proposal, the second-level service registrar is responsible
for ensuring that multiple services may be provided on behalf of a
single telephone number, potentially by different service providers.
This function includes an arbiter function to ensure that there is
exactly one instance of any given service assigned to a single
telephone number. The service-specific directory locator function
is a new service modeled upon existing telco service provisioning
models. Long-distance carrier selection within the United States is
one current instance of a service-specific registration requiring an
arbiter function within the current network.
The rate of change for the second level, service location function
may range from static through dynamic under the control of the
entity to which the phone number has been delegated. A registrar in
the public network may wish to make this information relatively
static to take advantage of DNS query caching, while a corporation
may be willing to accept a higher query load to provide a dynamic
service such as time-of-day inbound service provider selection. It
is important that the costs of providing a dynamic service at this
level are limited to the second-level directory service provider and
do not impose a burden on clients.
4.3 Third Level: Service-Specific
The third level is the query of the service-specific directory for
service-specific information. This third level is specific to the
service and is to be described in service specific documents. The
service specific directory is expected to be dynamic. It is
important that as little coordination as possible be required
between the directories of innovative and potentially competing
service-specific providers.
5 System Description
The Internet Domain Name System provides an ideal technology for
this high-level directory due to its hierarchical structure, fast
connectionless queries, and distributed administrative model.
Earlier experimentation with the TPC.INT remote printing experiment
has shown how the hierarchical assignment of telephone numbers can
be mapped directly to the hierarchy of domains within the DNS. The
ENUM directory uses that approach to map any arbitrary telephone
number into a single domain name.
Telephone Number Based Directory Services March 2000
ITU standard E.164 defines the structure of the public telephone
number as follows country code, followed by nationally significant
part, followed by sub-address. The country code may be from one to
three digits, and the total length may be up to 15 digits. The
nationally significant portion may be arbitraily divided on any
number boundary. In many countries numbering plans, the divisions
are not uniform, that is, the "Area codes" or "City codes" may be of
varying lengths within a single country and the total number of
digits may be variable. Where supported by the relevant service, an
optional sub-address of up to four digits may be utilized to
designate an extension telephone number. Note that while sub-
addressing is not well supported in GSTN calling, it is more widely
supported for voice messaging. It is important to note that the
national long-distance access or international dialing prefix
sequence is not part of the cannonical E.164 number.
Within this delegation flexiblity, it is always the case that the
delegation of authority is always done left-to-right. With this
assumption, a numbering tree can be built on a digit-by-digit basis
that can represent any arbitrary hierarchical structure. DNS
permits the delegation of authority on arbitary boundaries such that
a delegation to country code "1", "44", and "972" can all coexist
under a single numbering plan root. The same applies for "service
selectors", "area codes", "city codes", "Line number", or "sub-
address extensions" within numbering plans.
The first tier ENUM service makes available the telephone number
hierarchy into the domain name system. This is performed by
splitting the full telephone number into single-digit units and
treating each digit as a DNS domain-label. The result is prefixed
to the "e164.int" domain lable. The DNS is thus queried by
converting the dialed telephone number into a domain name and using
that domain name to query for a record from DNS.
The the single-digit separation of E.164 digits for lookup purposes
was chosen for the following reasons:
1. Implementable by both DNS and LDAP and other repositories (at the
same time, with partitioning depending on service and application
requirements)
2. Allows lookups -vs- searching (both DNS and LDAP). A record or
entry can be pin-pointed without white-pages type searching.
3. Supports distribution of E.164 resolution data by both blocks of
numbers and by individual numbers. The strategy allows this
distribution to be changed, when required, to reflect current
realities.
4. Alleviates clients from having to know or be able to derive
numbering plan structures and lengths (What a user types or dials is
out of the problem scope)
5. Isolation from changes to numbering plan structures and lengths
6. Supports use of telephone number extensions, if required
Telephone Number Based Directory Services March 2000
Implementation Note: A dropped UDP packet containing a DNS
request or response and the subsequent retransmission of the
query may result in higher than acceptable latency. Two
stategies may help manage problem. The first is to set
agressive time-out and retransmission parameters, potentially
as littls as 500ms. Where high packet loss is expected, the
client may send duplicate DNS requests to maximize the odds
that one will suceed within the required timeframe.
5.1 Telephone Number to Domain Name Mapping
For the purposes of discussion and example, this document assumes
the e164.int domain as the root for the telephone numbering
hierarchy. In operation, it can be something else to be determined
later.
The telephone number data to populate the highest level entries in
ENUM is publicly available. The ITU maintains a list of country
codes and the respective authorities that manage the sub-structure
under countries. (Note that country code 1 is shared by several
countries in what is referred to as "numbering plan area 1".)
Within a given country, authority for telephone numbers may be
further sub-assigned to individual service providers, corporatate,
institutional, or individual customers, either in telephone number
blocks or number-by-number. This delegation is typically private
information maintained at each level of the delegation tree.
Successful deployment of multiple services requires that service
providers and number registrars make this information available via
the ENUM directory service. The specifics of this sub-delegation
are beyond the scope of this memo, but any such administrative
solution is expected to work within this technical framework.
There is a set of local number portability, personal number, and
freephone solutions in use worldwide. While these particular
solutions rely upon various mechanisms and may use various
intermediate identifiers such as routing numbers or carrier codes,
the result of any such address mapping can directly identifty the
authority to which a particular number has been delegated. The ENUM
service should meet the requirements of these services.
The address resolution service makes available the telephone number
hierarchy through the domain name system. This is performed by
splitting the full telephone number into single-digit units and then
treating each digit as a DNS domain-label. The DNS is thus queried
by converting the dialed telephone number into a domain name and
using that domain name to query for a record from DNS.
The query simply requests the responsible domain for a given
telephone number. This can be most simply provided by using the
widely deployed DNS PTR resource record and applying it to this
role. With the PTR, a query by a telephone number converted into a
domain name form can return the domain name associated with it.
Telephone Number Based Directory Services March 2000
Example:
1.e164.int
1.1.1.1.3.3.7.2.7.9 PTR ServiceProvider.net ; for +1 972 733 1111
1.1.1.1.3.2.8.4.1.2 PTR ServiceProvider.net ; for +1 214 823 1111
5.1.1 Example: Simple Service Requiring Only First Level Query
For some services, the ENUM service may be sufficient to initiate an
instance of service and the second and/or third level of the
directory may be optional. In those cases, the service-specific
directory locator may provide adequate information for the client to
initiate successful communication. One example is a hypothetical
service that uses SMTP for the transport mechanism and well
understood rules for the construction of an SMTP address. For
example, using a telephone number in the local-part and using the
domain name from the first level query in the domain-part (e.g.,
service-abc=14161234567@bigco.com. The separate Mail Exchange (MX)
service record provides adequate information to route the message
once the email address has been constructed. This scenario would be
useful in services such as the above, if additional information and
capabilities were not required in order to send a message.
An SMTP email address can be constructed by converting the dialed
telephone number into its international form and concatenating it
with the domain name returned in the PTR record from the DNS query.
It is important to note that the national long-distance access or
international escape sequence is not part of the canonical number.
The "1" in the following example is the country code for the North
American dialing plan. It is not the long distance access prefix
commonly dialed in North America.
Sample configuration file PTR RRs for the NANP node in the DNS tree:
*.3.3.7.2.7.9 PTR ServiceProvider.net ;for 972 733
*.3.2.8.4.1.2 PTR ServiceProvider.net ;for 214 823
DNS query and response using telephone number +1 972 733 2722:
Query: 2.2.7.2.3.3.7.2.7.9.1.e164.int for PTR
Result: PTR = ServiceProvider.net
Per the service definition for the abc service, the sender could
subsequently send an email using the mechanically constructed
address:
svc-abc=19727332722@Serviceprovider.net
In this example abc service assumes that serviceprovider.net is also
capable of forwarding email addressed to it, a reasonable assumption
for some classes of services.
Telephone Number Based Directory Services March 2000
Note that this type of blind messaging scenario will not work if the
domain that is returned in the ENUM query is not the actual domain
name that is used in the smtp address of the intended recipient.
5.2 Service Specific Repository Discovery
The second tier of the telephone mapping service identifies the
appropriate service-specific directory server of the recipient
domain. For this, the DNS provides an extension record called the
service location resource record or [SRV]. This record acts like
the heavily used MX record in providing a list of servers offering a
given service to provide redundancy.
Strictly speaking, this is not a new service, but a usage of the
otherwise defined service location (SRV) extensions in the domain
name system. The mechanics for locating services for well-known
domain names is defined in [SRV]. This discussion is included as
part of the document as an illustration of how it can be used to
provide a multi-service directory system for telephone numbers.
The service specific directory server is found by querying DNS with
the domain name found in the address resolution step for SRV records
and also using the telephone number and service type in the query.
There may be one or more SRV records for one or more servers for
redundancy and load sharing. These entries are expected to point to
functionally equivalent services, not to indicate different service
providers. It is the responsibility of the querying client to
determine when to query an alternate server in the event that the
preferred server is out-of-service based on the user interface
latency requirements.
Note that there can be only a single instance of a service for each
telephone number.
5.2.1 Example: Hypothetical Reachme Service
The following service enables an end-user to discover the various
means by which she can reach a recipient represented by their
corporate telephone number +1 613-555-1212 using the hypothetical
"reachme" service. This service is hosted by directly by the
recipient's corporation.
The telephone number is transformed into a domain name form to be
used in a DNS query.
Sample configuration file for the top level delegations from ITU:
1.e164.int. IN NS ns.NANP.phone.net. ;for NANP
3.3.e164.int. IN NS ns.FR.phone.net. ; for France
2.7.9.e164.int. IN NS ns.il.phone.net. ; for Israel
Sample configuration file for numbers delegated from the NANP node
in the DNS tree:
Telephone Number Based Directory Services March 2000
5.5.5.3.1.6.1.e164.int. IN NS ns.ServiceProviderA.net.
;for 613 555 XXXX
Sample configuration for numbers sub-delegated from
ServiceProviderA.net:
*.2.1.5.5.5.3.1.6.1.e164.int. PTR Zcorporation.com.
;for 613 555 12XX
First tier DNS query and response using telephone number +1 613 555
1212:
Query: 2.1.2.1.5.5.5.3.1.6.1.e164.int. for PTR
Result: PTR = Zcorporation.com
The answer to this query would be authoritatively supplied by
ns.ServiceProviderA.net
The service-specific directory is then found by querying DNS for the
SRV record associated with the service-specific directory locator
domain name.
Sample service-specific queries and responses:
Query: _reachme._tcp. 2.1.2.1.5.5.5.3.1.6.1.Zcorporation.com
Response: SRV=ldap.Zcorporation.net weight=10
preference=10 port=389
The client can then use LDAP with the reachme schema to determine
the set of communications technologies available for +1 613 555
1212.
5.2.2 Example: Hypothetical Voicemail Service
A hypothetical service, voicemail, using SMTP as its transport
mechanism, which requires retrieval of the intended recipient's
capabilities and spoken name before sending a message, would use all
three tiers of the address resolution service to initiate a
communication session. The phone number has been delegated to
ServiceProvider.net but the voicemail service is provided by
spa.com. Again, the transformed international form of the dialed
telephone number is used in a DNS query for the PTR RR containing
the domain name to which the number has been delegated.
Sample configuration file PTR RRs for the NANP node in the DNS tree:
*.3.3.7.2.7.9.1.e164.int. PTR ServiceProvider.net.
;for 1-972 733
*.3.2.8.4.1.2.1.e164.int. PTR ServiceProvider.net.
;for 1-214 823
Query and response using telephone number +1 972 733 2722:
Telephone Number Based Directory Services March 2000
Query: 2.2.7.2.3.3.7.2.7.9.1.e164.int for PTR
Result: PTR = ServiceProvider.net
The service-specific directory is then found by querying DNS for the
SRV record associated with the service-specific directory locator
for the domain name.
Sample service-specific queries and responses:
Query:_voicemail._tcp.2.2.7.2.3.3.7.2.7.9.1.ServiceProvider.net
Response: SRV=ldap1.spa.net. weight=1
preference =10 port = 389
SRV=ldap2.spa.net. weight=1
preference = 20 port=389
From this response, the client can make a voicemail specific LDAP
query to ldap1.spa.net to retrieve the recipient capabilities and
spoken name necessary to confirm the correct address entry before
submitting the message for delivery.
In this example, high availability is provided by deploying the LDAP
servers in redundant sets. As per the SRV specification, these
servers should be listed in the SRV records with various preferences
The querying system should attempt a connection to the service-
specific directory server with the lowest numbered preference. If
it is down, the server with the next lowest preference should be
contacted.
5.2.3 Example: SIP Call Setup Service Request
This example provides resolution of a telephone number to the
identifier for the SIP gatekeeper designated to support real-time
calling (Sipphonecall) to 972 555 1313. The telephone number is
part of a block of ported telephone numbers that have been ported
out of the donor carriers block to another carrier.
The telephone number is transformed into a domain name form to be
used in a DNS query.
Sample configuration file for the top level delegations from ITU:
1.e164.int. IN NS ns.NANP.phone.net. ;for NANP
3.3.e164.int. IN NS ns.FR.phone.net. ; for France
2.7.9.e164.int. IN NS ns.il.phone.net. ; for Israel
Sample DNS configuration file for the ported number block serviced
by the 972 555 number portability authority delegated from the NANP
node in the DNS tree:
5.5.5.2.7.9.1.e164.int. IN NS ns.972555Port.NANP.phone.net.
;for 972 555
Telephone Number Based Directory Services March 2000
Therefore, the 1-972-555-xxx numbers have been delegated to the
namserver operated by the authoritative body that owns
972555Port.NANP.phone.net.
Logical DNS configuration for ported numbers sub-delegated to the
nameserver for 972555port.NANP.phone.net:
3.1.3.1.5.5.5.2.7.9.1.e164.int. PTR ServiceProviderB.net.
;for 972 555 1313
First Tier DNS Query and response using telephone number +1 613 555
1212:
Query: 3.1.3.1.5.5.5.2.7.9.1.e164.int for PTR
Result: PTR = ServiceProviderB.net
The SIP gatekeeper is then found by querying DNS for the SIP SRV
record associated with the service-specific directory locator domain
name.
SIPphonecall service-specific queries and responses:
Query:
_sipphonecall._tcp.3.1.3.1.5.5.5.2.7.9.1.ServiceProviderB.net
Response: SRV=sipgw1.ServiceProviderB.net weight=1
preference=10 port=100
The client can now use the SIP protocols to contact the SIP gateway
to initiate a phone call.
6. Security Considerations
The following are known security issues taken into consideration in
the definition of this directory service.
7. Service provider customer information is very sensitive,
especially in this time of local phone competition. Service
providers require the maximum flexibility to protect this data.
2) Registration of a domain name for the telephone numbers delegated
to another carrier may result in messages being mis-directed to the
wrong carrier. As sub-delegations are implemented, the risk that
phone numbers delegated to one enterprise may be mis-pointed at
another will increase.
3) Service providers operate in a regulated environment where
certian information about a subscribers must not be disclosed.
Telephony services and Voice Messaging are subject to caller-ID
blocking restrictions, restrictions normally enforced in the
telephony network. No such protection is available on the Internet.
The protection of this data is essential, but is up to the
Telephone Number Based Directory Services March 2000
individual service providers to not disclose this information
outside of their control.
7. References
[DNS1] Mockapetris, P., "Domain names - implementation and
specification", RFC1035, Nov 1987.
[DNS2] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, Nov 1987.
[SRV] Arnt Gulbrandsen, Paul Vixie, Levon Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", Work in Progress
[E164] ITU, "CCITT Recommendation E.164 (1991), Telephone Network
and ISDN Operation, Numbering, Routing and Mobile Service -
Numbering Plan for the ISDN Era."
[TPC1] Malamud, Carl, Rose, Marshall, "Principles of Operation for
the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC
1530, October 1993.
[VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet
Mail, Version 2", RFC 2421, September 1998.
[SRV] Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[Brown] Brown, Anne, "ENUM Requirements", work-in-progress, November
1999
[Faltstrom] Faltstrom, Patrick, " E.164 number and DNS", work in
progress, January 2000
9. Acknowledgments
This experimental directory builds upon the earlier work of:
Carl Malamud and Marshall Rose in their TPC.INT remote printing
experiment.
Bernhard Elliot working with the TMIA has provided much of the
organizational impetus to get this project moving, a substantial
task given the sometimes slow and bureaucratic nature in the
telephony business and regulatory environment.
Dave Dudley and the Messaging Alliance (TMA) for their early work in
pioneering a shared directory service for voice messaging and their
continuing efforts to apply those learnings to this effort.
Jeff Sherer and Mike Dimitroff of Lucent Technologies provided
invaluable insight and review based on a prototype implementation of
Telephone Number Based Directory Services March 2000
this service using actual data for the North American Numbering Plan
numbering region.
10. Author's Addresses
Anne R. Brown
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1-613-765-5274
Fax: +1-613-763-2697
Email: ARBrown@NortelNetworks.com
Gregory M. Vaudreuil
Lucent Technologies,
Communications Application Group
17080 Dallas Parkway
Dallas, TX 75248-1905
United States
Phone/Fax: +1-972-733-2722
Email: GregV@IEEE.org
Telephone Number Based Directory Services March 2000
11. Appendix 1: ENUM in the North American Numbering Plan
This section discusses the North American component of the ENUM
service. Generalized discussion for other countries and areas needs
to be provided. Within North America (Numbering plan area 1), the
delegation of phone numbers to the NPA/NXX level is managed by the
"Traffic Routing Administration" a cooperative agreement with
Telecordia (http://www.trainfo.com). The delegations are made
available in a quarterly publication called the Local Exchange
Routing Guide (LERG). The LERG is available publicly for a nominal
fee.
The North American Numbering Plan (NANP) local routing information
in the LERG database maps a telephone number prefix to an Operating
Company Number (OCN). The OCN is the unique identifier of the local
exchange operator that has received the telephone number delegation.
This delegation does not change with LNP.Local number portability
(LNP), as implemented in North America, sub-delegates numbers
nominally assigned via number blocks to "donor" carriers. The LNP
sub-delegation of phone numbers to carriers is managed by the Number
Portability Administrative Center (NPAC) managed under contract by
NeuStar (http://www.nanpa.com). While this data is also publicly
available, it does require an agreement to receive real-time
replication from the master database. This information can be
represented in DNS form, although it may best be implemented by a
DNS front-end to the LNP database rather than the normal DNS
servers.
The primary name server for the NANP can provide domain name
services for the NANP based on a mapping between OCN and the domain
name chosen by the operating company. The NANP DNS authority will
maintain the registration of the domain name to OCN mapping.
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Telephone Number Based Directory Services March 2000
| PAFTECH AB 2003-2026 | 2026-04-23 16:22:42 |