Subject: [Enum] code and maintainence complexity of combined user/carrier ENUM proposal

From: Michael Haberler <[email-masked]>
Date: Mon, 11 Jul 2005 11:39:14 -0400

To base the discussion on the incurred complexity of our I-D on facts, I 
have followed the seemingly outdated IETF practice of "running code" and 
built a example C implementation. I still need to document it and will post 
it later this week to this list. However I can say that:

- my example includes BOTH the published "well known table" method as well 
as a variant where the subdomain location for a CC is stored as a TXT 
record in the <cc>.e164.arpa zone itself, thus making an external table 
with assumed "management complexity" *completely unnecessary* (while I 
havent laid that out in the I-D, I alluded to it. I'm open for better RR 
suggestions, including a new one).

Of the example code (lots of comment, debug output etc) of some 400 lines
- a total of 10 (ten) lines is specific to insertion of the carrier subdomain.
- a total of 80 (eighty) lines is about retrieving the subdomain location, 
whereof some 15 are for scanning the well known table and alternatively 
some 60 are for retrieving the subdomain location by DNS lookup in the CC 
zone itself.

That is a ballpark for the "code complexity".
WRT to "table management complexity", let me reiterate:  if we decide to 
publish the location record in the CC zone itself, there is no such thing 
as table management. A CC Administration decides to use this scheme, 
decides on location, enters the record in the cc.e164.arpa zone, DONE.

While weighing this burden, I suggest to keep the potential upside of our 
proposal in mind, and that is a globally interworkable carrier ENUM tree - 
as opposed to forests of private tree arrangements, each serving random 
corners of the E.164 namespace.

-Michael

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Mon, 11 Jul 2005 12:26:22 -0400

WRT to "table management complexity", let me reiterate:  if we decide 
to publish the location record in the CC zone itself, there is no such 
thing as table management. A CC Administration decides to use this 
scheme, decides on location, enters the record in the cc.e164.arpa 
zone, DONE.
Michael, I think you've overlooked something fundamental. IIUC, you're 
proposing that there's a "table" of operator names (or codes) 
immediately beneath <countrycode>.e164.arpa, right? How does my 
(Scottish) handset figure out what the names (or codes) exist for the 
telco operators in say Austria? Which one of these Austrian telcos is 
it supposed to prefer? How do I get my handset to pick a new preferred 
partner for calls to Austria whenever I port my number to another 
Scottish telco or if the preferred telco in Austria has been renamed 
(or gone bust)?

BTW,  the idea of putting this "table" into the DNS somehow is worth 
considering. This could be a very elegant solution to part of the 
problem. However I think it would need a new RRtype, one RR per 
operator/telco. Doing this with TXT  records would be very bad.

I can see other nasties when these hypothetical tables got too big: TCP 
queries to get the whole table; buffer overflows in clients; 
telcos/CSPs doing a land grab to get "cute" entries in the table; 
legacy clients failing to check/refresh this table; etc, etc.

---

From: Michael Haberler <[email-masked]>
Date: Mon, 11 Jul 2005 18:01:32 -0400

At 18:25 11.07.2005, Jim Reid wrote:
WRT to "table management complexity", let me reiterate:  if we decide to 
publish the location record in the CC zone itself, there is no such thing 
as table management. A CC Administration decides to use this scheme, 
decides on location, enters the record in the cc.e164.arpa zone, DONE.
Michael, I think you've overlooked something fundamental. IIUC, you're 
proposing that there's a "table" of operator names (or codes) immediately 
beneath <countrycode>.e164.arpa, right? How does my (Scottish) handset 
figure out what the names (or codes) exist for the telco operators in say 
Austria? Which one of
not at all, since I did not propose to enter operator names or codes in the 
tree structure in the first place (btw since I assume the carrier subtree 
would be used by carriers in their routing process, I dont expect your 
scenario to be very likely; as mentioned, user ENUM semantics remains as-is).

A carrier-of-record for a number may enter this number in appropriate 
carrier tree. The link between carrier-of-record and number is held in the 
underlying registry database, just as  the right-to-use for a number needs 
to be asserted there in the User ENUM scenario. Wether a "POI" type record 
of Carrier B can be reached or not by Carrier A I expect to be covered in 
arrangements between A and B, and can be decided at runtime since the 
domainname or address of  an ALG/POI is globally unique. I could imagine 
though that a tag in the NAPTR like ";carrier-id=XXX" might help in the 
process to uncouple domain names from carrier identity, if that is deemed 
worthwile.

BTW,  the idea of putting this "table" into the DNS somehow is worth 
considering. This could be a very elegant solution to part of the problem. 
However I think it would need a new RRtype, one RR per operator/telco. 
Doing this with TXT  records would be very bad.
It works for my demo - I concur in reality a new RRtype would be in order. 
However, since the subdomain location is a CC/NPA and not an operator 
choice, only one RRtype is required.

I can see other nasties when these hypothetical tables got too big: TCP 
queries to get the whole table; buffer overflows in clients; telcos/CSPs 
doing a land grab to get
I dont see that problem - what I'm suggesting is a single record per cc/NPA 
in the *cc.e164.arpa* zone, which documents the choice for location of the 
carrier subtree for that cc/NPA, btw without any control fight about who is 
entering which record into which zone. A cc/NPA decides on a location, 
documents this by entering the record into *its* zone, and is done. The 
reason why I propose that is that it maps nicely onto the per-cc/NPA 
authority over the zone.

Therefore the client searches for that record in the cc.e164.arpa zone, not 
at e164.arpa. To do so, the client may determine the length of the country 
code, and thus the location in the tree for that record, as laid out in 
http://mah.priv.at/tmp/draft-haberler-carrier-enum-00.html section 4, third 
to fifth paragraph - alternatively by checking against the authoritative 
list of country codes as per ITU website. I assume that list to be at hand, 
and current, by any organisation suspect of delivering some sort of 
telephony service. Claiming inability on that front is dismissed ;)

Note that the boundary case "subdomainlocation = 0" covers the "Shockey 
scenario", namely  <cc>.carrier.e164.arpa. Be my hero in Geneva, Rich...

-Michael

---

From: lconroy <[email-masked]>
Date: Mon, 11 Jul 2005 18:22:26 -0400

Hi Michael,
Neat solution, IMHO. Yup - a new RRtype is needed, but it's only 1 for 
the world (with 1 instance per cc).

On 12 Jul 2005, at 00:00, Michael Haberler wrote:
Note that the boundary case "subdomainlocation = 0" covers the 
"Shockey scenario", namely  <cc>.carrier.e164.arpa. Be my hero in 
Geneva, Rich...

Rich - now the IPO's done, how long till you retire?
I'm just trying to figure if the ITU will have completed the rehash 
before that point.

all the best,
  Lawrence
---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum