Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt

From: "Pfautz, Penn L, NNAD" <[email-masked]>
Date: Mon, 26 Jun 2000 08:20:30 -0400

Re the last call on enum-e164-dns-00.txt:

 I'm concerned that the draft does not address or cite the complications
introduced by Number Portability.  Below I give an example based on the
current situation in the US because it's the one I'm most familiar with but
I suspect the issues will have more general relevance.  Therefore I  hope
that others  familiar with practices elsewhere  will share their
perspectives. 
I don't pretend to have a clean solution to the problems of portability, but
I think the draft needs to at least allude to the kinds of problems
portability introduces.

I'd suggest adding a paragraph to the draft like the following:

Number portability complicates the implementation of the ENUM service
because in some cases it complicates the hierarchy of numbering space
authority. For example, when a subscriber ports their number away from the
service provider to which it was originally delegated, the numbering
authority may no longer be able to redirect a query to the correct service
provider. In that case queries must either be redirected by the original
service provider or  else the numbering authority or a surrogate must track
number assignments at the individual  telephone number level. The former
approach raises performance, reliability, and authority issues, especially
when a single number ports multiple times. The latter approach requires a
more burdensome centralized infrastructure.  Such issues will be a  topic of
further work by the WG.

USA example number portability issue relative to use of ENUM/DNS

In the US  Central Office codes (NPA-NXXs) are assigned by the North
American Numbering Plan Administrator. Neustar (formerly Lockheed-Martin
CIS) provides this function. Thus, following the draft's logic in the
example, NANPA/Neustar would be the regulator. (Actually routing information
is maintained in the Local Exchange Routing Guide (LERG) which is a
Telcordia (formerly Bellcore) product made available for a fee.) Let's
assume , however, that for some unspecified financial consideration  the
NANPA agrees to provide the top-level DNS function for NANP numbers. NANPA
could then direct queries to the DNS of the service provider to which the
central office code containing the queried number was assigned.

But subscribers may port their geographically significant numbers to a
service provider other than the one to which the number was originally
assigned. The Number Portability Administration Center (NPAC, currently also
run by Neustar but in principle independent of NANPA) maintains the industry
database-of-record of ported number assignments. These data are NOT public
and access must be contracted for by service providers who must agree to
some limitations on its use and dissemination. 

So if a number is ported, a query to the NANPA will not result in
redirection the proper service provider's DNS. There are several
alternatives, none of them pretty:
The ported-from or donor service provider could redirect the query to the
new SP. But if the customer ported again would the original SP be obligated
to continue to track the number? Or would the donor redirect to the first
ported-to SP who would redirect to the second ported-to SP, etc.? 
The original SP could indicate a need to query a ported number database,
perhaps maintained by the NPAC
All calls could simply query a  master database that included ported
numbers. This approach, however, leads away from the distributed database
structure that is the basis of DNS

To complicate things further, the US Federal Communications Commission (FCC)
has ordered a process called number pooling that will have the NANPA assign
numbers not in blocks of 10,000 (NPA-NXX) but in blocks of 1000 (NPA-NXX-X).
Network routing of blocks assigned to carriers other than that to which the
Central Office code is assigned will be handled by treating numbers in
pooled blocks as being ported to the assigned carrier. With little pooling
yet in place the US already has 8M ported numbers with between 0.5-0.75M
being added each month so ported numbers will soon represent a
non-negligible fraction of the North American Numbering Plan space.

Non-geographic toll-free ("800") numbers are also portable in the US. Data
indicating the Responsible Organization (RESPORG) for each number are
contained in the 800 SMS which is operated under tariffs of the former Bell
Operating companies by yet another contractor and these data too are not in
the public domain. Since there is no inherent assignment of toll-free number
blocks to service providers, there is no basis for establishing a
distributed DNS structure aligned with zones of authority as exists for
internet domains. And, in the absence of some authority being set up to
provide a master database, there is no place for an individual toll-free
number owner to put a DNS record for their number that would be generally
reachable. The active North American toll-free number space is on the order
of 24M numbers with additional toll-free codes planned.

Penn Pfautz
AT&T E4-3A01
200 S. Laurel Ave
Middletown, NJ 07748
732-420-4962
[email-masked]

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 26 Jun 2000 16:33:41 +0200

At 08.20 -0400 00-06-26, Pfautz, Penn L, NNAD wrote:
>introduced by Number Portability.

Earlier versions did, and the reason for removing it is because the 
situations in the various countries differ so much that it is 
impossible to state how DNS is used below each country code.

For example, 1.e164.arpa will be delegated to someone. How resource 
records are used in that domain to suit the numbering allocation 
scheme in the 1 country code is up to the parties involved in that 
discussion.

One way is to simply have an NS record for the actual number pointing 
to whatever service provider the end user (holder of the E.164 
number) wishes, and do that delegation with NS records from Neustar 
directly. The telco handling PSTN switching doesn't _have_ to be 
involved.

If one want to do a less drastic approach, other RR types such as 
CNAME or DNAME can be used for handling eventual redirection in the 
DNS lookup algorithm.

The whole point is that one have to see the DNS delegation tree 
separate from the one in the PSTN world, and the reason one can is 
just because one have an abstraction layer in DNS/INternet which 
doesn't exist in the E.164 world. There, a E.164 number is a E.164 
number is a ....

So, each country code have to handle the delegation in DNS according 
to their local rules so it suits their way of handling portability.

>more burdensome centralized infrastructure.  Such issues will be a  topic of

This is not correct, as when doing a DNS lookup, the lookup always 
starts at the top of the tree, i.e. at 1.e164.arpa in the case of 
country code 1. The pointers you talk about is to go from the top 
down, not from one administrative body to another one in the same 
level of the hierarchal tree of administrative bodies being 
authoritive for E.164 numbers.

I.e. in the normal portability discussions, one talk about one 
authority moving one number to a second one. So, the first have to 
redirect queries to the second one. That is not how DNS works. The 
second one tell the parent in the DNS tree that he is not 
authoritative for information of that domain.

Exactly how that process is to work is up to the country code as I 
said earlier.

>redirection the proper service provider's DNS.

According to what I have heard, when you query the Neustar 
(regulator) for NS records, i.e. follow the chain of delegations, you 
will in DNS always end up at the correct place. You traverse the tree 
from top to bottom. When a number is moved in the DNS tree, you don't 
end up in the old place anymore.

>There are several
>new SP.

This is not DNS.

etc etc...

>Non-geographic toll-free ("800") numbers are also portable in the US.

We only talk about E.164 numbers.

    paf

---

From: Richard Shockey <[email-masked]>
Date: Mon, 26 Jun 2000 10:55:04 -0500

>We only talk about E.164 numbers.

Freephone numbers (800,888)  _are_ e164 numbers in the ITU definition, 
however all of your other points are essentially correct.

The problem is that the administration of numbers in a PSTN world is 
different from a DNS world since, in DNS,  e164 numbers numbers have no 
meaning at all. They are names.

There is only one type of delegation in ENUM. The subscriber or their 
authorized representative provisions the appropriate NS.

But because of portability ENUM lookup is always to the last digit, except 
in those very rare occurrences where a NXX block or NXX-X block has been 
given to a enterprise or a corporation. Plus given the extreme desire of 
the regulators to avoid a total NANP renumbering, that practice may no 
longer be permitted and even enterprises will be forced to enter the 
pooling system.

The key is the application environment.

A "800" number can be ported from service provider to service provider in 
the PSTN world but that would not necessarily require a change in its DNS 
RR since, the SIP service provider for that number may be entirely 
different carrier...indeed there may be multiple SIP carriers listed for a 
particular number ( for fallback and redundancy ) and a H.323 carrier as well.

Changing the service provider for circuit switched calls would not effect 
the IP service providers.

Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<