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

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 26 Jun 2000 10:04:15 -0400

Unless I'm not understanding the problem at all, it seems to me that the
concern you raise is caused by the fact that "portable numbers" in the US
still are geographically significant, E.164 numbers, which are assigned to
service providers. But this is not the case in Europe, where their structure
is flat?

I'm not sure how portable numbers can continue to be defined and assigned in
the US as they are now. What are the long-term plans for this? Anyone know?

Bert
[email-masked]

> -----Original Message-----
> From: Pfautz, Penn L, NNAD [mailto:[email-masked]]
> 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