Subject: RE: [Enum] FW: Last Call or New Draft? - Portability

From: "Pfautz, Penn L, NNAD" <[email-masked]>
Date: Wed, 28 Jun 2000 14:29:01 -0400

Richard:
Although it sounds like there will be an attempt at some resolution of the
issues raised with respect to record type, I'm not sure what's happening re
number portability impacts.
Some of Patrik's discussion has helped me better understand the issues but
also convinced me that, at least in the NANP area, there will need to be a
very large database at the 1.e164.int level that provides pointers to the
DNS service of the end user's choice for each individual number (or number
block for corporate ownership). I've done a crude cut and paste on the
example in Patrik's Appendix to illustrate how this might be expected to
work.

Appendix A. Example 2
    The ITU has delegated the country code 1, and the zone 1.e164.int to
    the North American Numbering Plan. The regulators of the NANP countries
    have delegated the responsibility for this zone to the contracted
    NANP Administrator. NANPA Because of that, the content
    of the e164.int zone is:

    $ORIGIN e164.int.
    1  IN NS nanpa-e164.com
     
    Although the NANPA assigns blocks of 10,000 or 1,000 numbers to various
    Service providers for assignment to end users, numbers are portable so
the NANPA 
    DNS provides a zone for each telephone number or block of numbers
assigned
    A single user. Thus the NANPA DNS has a record directing queries for a
specific
    number to the DNS of the current service provider. The user can then
either have that
    provider be the source of authoritative information or request the
telephony provider's
    DNS refer  to that of some other DNS service provider.

    A user named Jenny Jones has from Telco A got the phone number
    +1 792-867-5309. The user gets the service of running DNS from the
    company Redirection Service. Jenny Jones has asked Telco A to
    point out Redirection Service as the authoritative source for
    information about the number     +1 792-867-5309. Telco A because of
this
    puts in its DNS the following. 
 
    $ORIGIN 1.e164.int.
    9.0.3.5.7.6.8.2.9.7 IN NS ns.redirection-service.com

    Jenny already has  plain telephony from Telco A, but also a
    SIP service from the company Sip Service which provides Jenny with
    the SIP URI "sip:[email-masked].". The ISP with the name
    ISP A runs email and webpages for Jenny, under the emailaddress
    [email-masked], and URL http://jenny.ispa.net
    The DNS for the redirection service because of this contains the
    following.    
     $ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.int.
     IN NAPTR 10 10 "a" "sip+N2R"      "" "sip:[email-masked]"
     IN NAPTR 10 10 "a" "smtp+N2R"     "" "mailto:[email-masked]"
     IN NAPTR 10 10 "a" "http+N2R"     "" "http://jenny.ispa.net"
     IN NAPTR 10 10 "a" "tel+N2R"      "" "tel:+1-792-867-5309"
    A user, John Smith, wants to contact Jenny Jones, and has to start with
    only the E.164 number of Jenny, i.e. +:+1-792-867-5309. He takes the
    number, and enters the number in his communication client, which
    happen to know how to handle the SIP protocol. The client removes
    the dashes, and ends up with the E.164 number +17928675309. That is
    what is used in the algorithm for NAPTR records, which is as follows.
    The client converts the E.164 number into the domainname
    9.0.3.5.7.6.8.2.9.7.1.e164.int., and queries for NAPTR records for
    this domainname. Using DNS mechanisms which includes following the
    NS record referals, the following records are returned:

     $ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.int.
     IN NAPTR 10 10 "a" "sip+N2R"      "" "sip:[email-masked]"
     IN NAPTR 10 10 "a" "smtp+N2R"     "" "mailto:[email-masked]"
     IN NAPTR 10 10 "a" "http+N2R"     "" "http://jenny.ispa.net"
     IN NAPTR 10 10 "a" "tel+N2R"      "" "tel:+1-792-867-5309"

    Because this client knows sip, the first record above is selected,
    and the SIP URI is extracted, and used according to SIP specifications.

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: Wed, 28 Jun 2000 22:28:55 +0200

At 14.29 -0400 00-06-28, Pfautz, Penn L, NNAD wrote:
>block for corporate ownership).

That is correct. Or rather, the total number of records in the 
central cluster of mappings under 1.e164.arpa in the same 
administrative domain (not the same as the same DNS domain) will be 
large.

It can though due to the way DNS works be split into a large number 
of physical databases.

So, I don't see this as any showstopper, because the mapping have to 
be somewhere...and the amount of data will not decrease whether we 
have it in one administrative domain or many.

It is rather the case that when talking about number portability, you 
have a classic problem of handling a distributed database where the 
administration can not be delegated (without quite complicated 
redirections to "parent" nodes in the tree, to enter a different 
administrative domain).

    paf