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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 26 Jun 2000 10:22:34 -0500

I would like to further suggest changes to the ENUM protocol to support the
it's use in the real-world.

Beyond the ability to form an appropriate query domain name the ENUM draft
is silent about client requirements to support the ENUM service.  The only
discussion of client requirements is part of the NAPTR discussions.  There
are additional requirements on the clients to ensure an interoperable
service.  In particular, I believe we need to explicitly require client
support of the Cname and/or require support of Dname for the ENUM facilities
of DNS. 

If as suggested by the current ENUM draft, only NS records are used to
delegate numbers, there will be a huge proliferation of micro-zones, that
is, zones of a single telephone number.  Within a small corporation with
say, twenty numbers, this will require a DNS set-up with twenty zone-files.
In larger corporations like Lucent that receive 100-number blocks of numbers
as well as thousands of individual delegations, this will require THOUSANDS
of separate zone-files.  Within a public telephony service provider
suffering number portability, there will be tens to hundreds of millions of
separate zones.  Each has it's own SOA records.  Each file of course needs
to be hosted by a secondary making an inordinate number of separate
zone-transfers necessary.  I don't think this is possible within BIND.
While one could use a database other than BIND, administrating and operating
this service would face huge deployment obsticals.

The only mechanism being considered at this time to make this workable is
the Cname and Dname records.  In this manner, the delegations to unit of one
can be remapped to a single zone hosted by a corporation or service
provider.  Now Lucent could host a single zone with thousands of entries
(trivial).  However, this can only be achieved if the entities which
delegate the numbers use Cname (for singletons) or Dname (for number
blocks).  Given that Cname and Dname resolution is not automatically
performed by most resolvers, clients MUST be able to deal with both Cnames
and Dnames or they will not work for large parts of the number space. 

These issues are discussed at length in draft-vaudreuil-enum-e164dir-00.txt.
However, to make an interoperable protocol, implementation requirements for
client and servers must be in the ENUM "protocol" document itself.

Greg V.

-----Original Message-----
From: Pfautz, Penn L, NNAD [mailto:[email-masked]]
Sent: Monday, June 26, 2000 7:21 AM
To: [email-masked]
Cc: Scott Bradner; [email-masked]; [email-masked]
Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on
draft-enum- e164-dns-00.txt

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 27 Jun 2000 07:56:13 +0200

At 10.22 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote:
>In particular, I believe we need to explicitly require client

I will check what is required by a DNS client, and how to point out 
that every RR which is "required" (like CNAME) must be handled 
correctly.

    paf