Subject: RE: combined User and Carrier ENUM (was RE: [Enum] Agenda items for IETF Paris)

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 11 Jul 2005 17:47:29 -0400

Michael,

I did not assume anything.  And yes I am aware of the variable length
numbers in certain countries.  Will your system work when every other 11
digit (+1-NPA-NXX-XXXX) number is ported to a different carrier?  
BTW, in the US there are 3000 plus carriers and growing.  How many does
Austria have?

I suspect that there is some aspect to DNS operation that I haven't put
my finger on that makes this difficult.  I'm still not sure what exactly
your one DNS lookup means since from what I understand several domain
servers need to be queried to get a final response.  I need to dig
further.

Mike

> -----Original Message-----
> From: Michael Haberler [mailto:mah at inode.at] 
> Sent: Friday, July 08, 2005 8:36 PM
> To: Michael Hammer (mhammer)
> Cc: enum at ietf.org
> Subject: combined User and Carrier ENUM (was RE: [Enum] 
> Agenda items for IETF Paris)
> 
> At 20:06 08.07.2005, Michael Hammer \(mhammer\) wrote:
> 
> >Jim,
> >
> >I have yet to see a persuasive argument for why all the political 
> >requirement, control, manipulation, administration, policy, 
> ... aspects 
> >can't be built around a simple technical model.  The administrative 
> >tail seems to be wagging the dog.
> 
> Ah, I guess I see the knot...
> 
> Could it be that you are assuming:
> 
> - a closed numbering plan (fixed number length)
> - maybe a scenario where all RR's are held in the Tier1 nameservers?
> 
> and think about a scheme where authorization to enter a 
> particular record type at the number level could be given to 
> different parties ?
> 
> that would probably work, BUT - not all countries have a 
> fixed numbering plan - among them Germany and Austria. Coming 
> back to my example:
> 
> +43 59966 is a valid number, as is +43 59966-0 (a convention to reach 
> +the
> switchboard).
> +43 58866-12345678 is valid as well, and anything in between.
> 
> In such a situation you would typically have a delegation at 
> +43 59966 to point to your own ("Tier3") nameservers. That is 
> in fact very useful - I'd have to check but I assume that 
> most PBX-type delegations under +43 use that scheme. As I 
> mentioned, actually enlightened IP PBX manufacturers use this method.
> 
> I assume this to be incompatible with carrier type records at 
> or under +43
> 59966 - no carrier fiddling in user-operated zones, please.
> 
> -Michael
> 

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

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 12 Jul 2005 02:24:10 -0400

Michael,

In Michael's I-D, the domain component "carrier" is meant as the literal
sequence of the ascii characters c,a,r,r,i,e and r and not as a variable
for which you substitute a real-life carrier name.

It could just as well be "foobar", "c" or "death-to-ss7-interconnects".

There is thus still one single tree per country (or NPA), and thus
still a need for a registry who runs that tree and with which 
every carrier needs to interact to get its numbers into carrier ENUM.

The number of carriers per country is thus irrelevant for the
lookup procedure.

/ol
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >

---

From: Jim Reid <[email-masked]>
Date: Tue, 12 Jul 2005 05:43:23 -0400

I suspect that there is some aspect to DNS operation that I haven't put
my finger on that makes this difficult.  I'm still not sure what 
exactly
your one DNS lookup means since from what I understand several domain
servers need to be queried to get a final response.
Michael, you seem to be confused how DNS lookups work. I hope this 
explanation helps.

An application makes a DNS lookup by sending a query to some local name 
server. This is known as the stub resolver in DNS jargon: it formats a 
packet, sends it and waits for a reply. That's all.

The local name server -- full service resolver in DNS jargon -- sends a 
response back. If it can't answer from its cache, the local name server 
will make iterative queries to resolve the stub resolver's query. 
Conceptually, it does that by starting at the root and working its way 
down the tree. In ENUM, this would be querying the .arpa name servers, 
then the e164.arpa name servers and so on. This full service resolver 
will not go off and query other branches of the tree. That is no DNS 
implementation has logic which says "if the name doesn't exist under 
foo.bar, try resolving this in some other incantation of foo.bar or in 
some other domain name entirely". In other words, the full service 
resolver terminates the iterative lookups when it gets an answer or 
gives up because the remote name servers are non-responsible or 
unresolvable. That answer can of course be "the name/query type you 
looked up does not exist". Whatever result the full service resolver 
gets is then returned to the stub resolver that made the initial query.

Of course the application could have logic that says "if there are no 
NAPTRs for this number in e164.arpa, try querying for them in some 
other domain name". If it did, that second lookup would go to the full 
service resolver and go through the same iterative process as before.