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

From: Richard Shockey <[email-masked]>
Date: Wed, 28 Jun 2000 16:48:23 -0500

At 02:29 PM 6/28/2000 -0400, Pfautz, Penn L, NNAD wrote:
>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).

Right the subscribers choice ..the ultimate rule in ENUM administration 
..if and when that is discussed somewhere....but please not on this list.

>I've done a crude cut and paste on the
>example in Patrik's Appendix to illustrate how this might be expected to
>work.

Think 1.e164.arpa.

>Appendix A. Example 2
>     The ITU has delegated the country code 1, and the zone 1.e164.arpa 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.arpa.
>     1  IN NS nanpa-e164.com

Yep.

>
>     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.

Well there is some thinking in these circles that in general the resolution 
at the first level delegation goes all the way to the last digit and only 
those numbers that are assigned to enterprises can be properly delegated at 
a NXX level.  The current regulatory assignment environment is at the 1000 
block level but with pooling and the anticipation of much more aggressive 
number conservation even this is only a temporary solution. You can 
anticipate the FCC and the CRTC will do nearly anything to avoid NANP 
exhaustion.

This 1st level delegation can be broken up into numerous servers to load 
balance etc.

And with NP the way it currently works, all digit look up is what is 
happening today in the IN

>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.

Well yes you are just about on the mark ..but you should remember the 
essential principal of number portability administration which is "non 
reliance on donor networks".  There is a very legitimate worry by some 
service providers on having to rely on incumbent "carriers of record" to 
provision ENUM RR's.

To put it bluntly ...why should Bell South assist provisioning SIP services 
from ATT, if Bell South is offering those services themselves. [ This 
assumes 271 permission is eventually granted Bell South ].  The last thing 
we need as system that invites Internet Telephony slamming.

See below.

>     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.

Well not exactly  ..... Jenny Jones might tell Teleco A to point to 
"Redirection Service" as the NS for this number and this could be 
redirected directly from NANPA to "Redirection Service", or their friendly 
neighborhood global SIP service provider ( read ATT could do this for them 
) their is no need for Telco A to maintain any RR except for those 
customers that have specifically asked for them to do so.

Of course ..we are now getting into the real NO NO of discussing ENUM 
administration and policy issues on this list and as co-chair I'd like to 
chastise myself for going this far.

>
>     $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.arpa.
>      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.arpa., and queries for NAPTR records for
>     this domainname. Using DNS mechanisms which includes following the
>     NS record referals, the following records are returned:

Looking good .... I've changed .int to .arpa

>      $ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.arpa.
>      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.

Ta Da!..  ...if you use NAPTR records. Now we should see how our SIP 
colleagues think about this scenerio.

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]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Jun 2000 22:54:22 -0400

Richard Shockey wrote:

> colleagues think about this scenerio.

Seems fine to me... the next step would be an SRV lookup of
_sip._udp.sipservice.com and _sip._tcp.sipservice.com to locate the
server for this domain.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Robert H. Walter" <[email-masked]>
Date: Thu, 29 Jun 2000 10:46:40 -0400

> colleagues think about this scenerio.

Conceptually the works!, however the example NAPTR RRs are not accurately
defined.  The replacement field MUST be a domain name and the above
examples use URI's.

Mike Mealling wrote in a prevous post on Wed 6/28/00 10:01 AM:

> The Application gets to define the Appliction Unique String
> which is the thing the algoirthm works on to find out specific
> syntactic rules for delegation.
> ...
> In the case of an ENUM application the Unique String would be
> the e.164 phone number and the output would be URIs that
> identify services.

Mike would you mind shedding light on what the NAPTR RR's would
look like given the unique string of 17928675309?  Your assistance
is greatly appreciated.

Bob