Subject: RE: [Enum] Agenda items for IETF Paris

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 08 Jul 2005 12:29:32 -0400

Michael,

Pardon my inexperience with DNS mechanisms, but why can't a lookup of a
domain at:
1.2.3.4.5.5.5.1.0.2.1.e164.arpa 
return an OPT-IN User RR (which may or may not be there) 
and a Carrier RR identifying a border controller?

I am assuming that the carrier RR is for those cases where the
delegation of the E.164 number goes through a carrier to the end-user,
not those where the number is from the national authority directly to
the user.

I read your draft, but fail to see the need to define a new "carrier"
domain at any point in the tree.  Putting such a domain under the
country code only branches at a different point down the hierarchy.
You've only moved the problem next door.

Two facts bound this problem as far as I can tell:
1:  A number is dialed and presented to the DNS client that then must
resolve it by traversing the tree from root on down to the last digit.
2:  Until you reach a given point in the tree (depending on national
authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the
number belongs to one carrier or another.

I don't think it a good idea to regulate where in the tree (e.g. after 3
or 6 digits) to place carrier information.  Instead why not simply have
the information at the point where the carrier is unambiguous and be
able to return a carrier RR?  This does not mean that the resolver's job
is done, since it may have more dialed digits to use.  It can continue
resolving till it reaches the last digit, which could return a User RR
if the user had opted-in.  Or, if the original search knows in advance
that it is only doing carrier, it could stop as soon as a carrier RR is
returned.  Likewise, if it knows it is only doing User, it ignores
returned carrier RR and continues till it gets the User RR.  It can
prioritize which to use, if it doesn't know which RR type is present,
(doesn't care) but can get both.

The above is flexible, since it makes it a matter of configuration where
the Carrier RR resides, which could be at any domain level:

Country:

1.2.3.4.5.5.5.2.2.2.1.e164.arpa
|                 |
|                 +-Carrier RR
|
+-User RR

Area/City code:

1.2.3.4.5.5.5.2.2.2.1.e164.arpa
|             |
|             +-Carrier RR
|
+-User RR

10K block:

1.2.3.4.5.5.5.2.2.2.1.e164.arpa
|       |
|       +-Carrier RR
|
+-User RR

1K block:

1.2.3.4.5.5.5.2.2.2.1.e164.arpa
|     |
|     +-Carrier RR
|
+-User RR

Per number (e.g. due to number portability):

1.2.3.4.5.5.5.2.2.2.1.e164.arpa
|
+-Carrier RR
|
+-User RR

The above would leave a single non-branching search path, no new domain,
and simply a procedure for deciding which RR to use.

Mike

> -----Original Message-----
> From: Michael Haberler [mailto:mah at inode.at] 
> Sent: Thursday, July 07, 2005 9:14 PM
> To: Michael Hammer (mhammer)
> Cc: enum at ietf.org
> Subject: RE: [Enum] Agenda items for IETF Paris
> 
> Michael,
> 
> At 00:11 08.07.2005, Michael Hammer \(mhammer\) wrote:
> ..
> >Second, in which RFC does it say that the URI returned MUST be an 
> >end-user URI?
> >(I'll confess I haven't read them all.)
> 
> Let's call a "non end-user URI" a Point of Interconnect" 
> (POI), which is an attribute of the carrier-of-record of a number.
> 
> An end user opting in to User ENUM does not care about and 
> cannot influence his carrier's POI, but his own URI(s).
> 
> A carrier does care about his POI(s), but cannot enter them 
> into User ENUM because latter is opt-in by and the zone is 
> owned by his user.
> 
> Having a carrier *and* his user cohabitate the same zone  is 
> like you and me owning foo.com - we might run into problems 
> about which records go into in the foo.com zone. You change 
> my RR's, I might get nasty.
> 
> >Third, in both cases, isn't the intent to be able to route a call 
> >(initiate communication) toward the owner of the E.164 number?
> 
> yes, and User ENUM is great for that. It just happens to 
> cover a homoeopathic number of call setups now and for a long 
> time to come, the rest of the call setups work  by virtue of 
> - in some way - shared POI information. Both do work, but 
> this isnt a question wether you can call me or not.
> 
> >The concept of peering partners is beside the point.
> 
> I dont think so, that's just a posh name for "interconnect 
> agreement" and the concept is bound to be with us for a 
> while, like 10 years or more. I havent made any, but they are there.
> 
> >  I find the idea of disconnected islands of closed clubs to be 
> > counter-productive.  A key requirement MUST be that a dialed E.164 
> > number enables a call to go through.  If ENUM becomes the stumbling 
> > block preventing call completion, that will invite 
> unnecessary regulation.
> >
> >Fourth, isn't one of the principles of the Internet to provide 
> >generally useful mechanisms?  Bifurcating this into User 
> versus Carrier 
> >"orthogonal and independent" implementations is a recipe for 
> >non-interoperability and "Walled ENUM".
> 
> Let's assume we insist on User ENUM being the method of 
> choice for call setup in IP land, and other call setup 
> scenarios are undesirable/should go elsewhere, whatever the 
> supporting mechanisms are.
> 
> The consequence of assuming that a dialed number goes through 
> User ENUM exclusively is part of the cause for the very 
> bifurcation you are deploring. This is happing right now, 
> into e164.something trees or private trees altogether, or 
> staying on the PSTN by default.
> 
> Now, do I care? Can I call you and you can call me ?  yes, so 
> that fulfills your requirement.
> 
> Does it make sense? I believe, not really  - because the 
> cannibalization into different trees kills cross-tree 
> resolution. Resolution rates are already ridiculous due to 
> the pathetic per-country code opt-in to process.
> 
> Will it help the User ENUM vision (which I share)? no, 
> actually it will kill it - and the reason is that it might 
> not be viable to run a User-ENUM-only service on a 
> per-country basis, and get still get a critical mass of 
> users. We might end up with something like "No, we dont do 
> HTTP over here in France." - this isnt my idea of a 
> horizontal technology.
> 
> I might be questioning belief systems here:
> 
> a) the basic value proposition of ENUM-like technology is in 
> call resolution rates - more calls on IP equals better.
> b) call resolution is a market - laws of demand and suppy 
> apply. Offer doesnt meet demand - demand goes elsewhere.
> c) User ENUM is dead in the water if cost of running it and 
> end user value dont add up eventually. End user value is in 
> resolution rates, too.
> d) finding a scheme which fulfills carrier needs and at the 
> same time supports User ENUM, like a combined tree proposal, 
> will keep options for User ENUM open longer - so it can 
> achieve reasonable resolution rates eventually to keep it viable.
> d) one is more likely to find somebody in jurisdiction X to 
> run a combined tree than just User ENUM, and governments will 
> see more demand as local IP interconnect is an issue - and 
> that helps footprint of both.
> 
> see 
> http://www.enum.at/ietf/draft-haberler-carrier-enum-00.txt 
> and 
> http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html 
> for Richard's and my I-D based on this view - the I-D is 
> still making it through the queue
> 
> - Michael
> 
> 
> 

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

---

From: Jim Reid <[email-masked]>
Date: Fri, 08 Jul 2005 13:42:02 -0400

On Jul 8, 2005, at 17:29, Michael Hammer ((mhammer)) wrote:
Pardon my inexperience with DNS mechanisms, but why can't a lookup of a
domain at: 1.2.3.4.5.5.5.1.0.2.1.e164.arpa
return an OPT-IN User RR (which may or may not be there)
and a Carrier RR identifying a border controller?
Because these are two different things which will presumably be 
controlled and manipulated by different entities according to 
different, possibly mutually exclusive, requirements.

There's nothing in the DNS protocol to prevent these RRs co-existing in 
the same zone of course. And if they did, a DNS lookup could return 
both. However just because something is possible doesn't mean it could 
or even should be done. From a purely technical perspective, the answer 
to your question is the DNS lookup could return both these RRs. But for 
all sorts of practical reasons -- administrative, policy, operational, 
content management, synchronising and managing access control to the 
zone, etc, etc -- this is unlikely to be a wise or desirable outcome.

---

From: Michael Haberler <[email-masked]>
Date: Fri, 08 Jul 2005 20:00:11 -0400

Michael,
At 18:29 08.07.2005, Michael Hammer \(mhammer\) wrote:
I read your draft, but fail to see the need to define a new "carrier"
domain at any point in the tree.  Putting such a domain under the
country code only branches at a different point down the hierarchy.
You've only moved the problem next door.
Two facts bound this problem as far as I can tell:
1:  A number is dialed and presented to the DNS client that then must
resolve it by traversing the tree from root on down to the last digit.
2:  Until you reach a given point in the tree (depending on national
authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the
number belongs to one carrier or another.
I don't think it a good idea to regulate where in the tree (e.g. after 3
or 6 digits) to place carrier information.
I think there is a major misunderstanding what our proposal suggests.
The 'carrier subdomain location' is about opening a complete new tree, at a 
flexible but globally interworking location in the e164.arpa tree because 
of the very cohabitation problems. It is a convention which needs to be 
published for interoperability, not a regulation. A well-known table is 
just one mechanism to do that, an appropriate RR in a standard place per 
country code could get rid of the table altogether.

It is NOT the place where, for a given number, a particular "Carrier RR" is 
stored. I propose to unroll all number ranges fully and store RR's at the 
number level. I dont envisage delegations at some number block boundary - 
this again gets in the way with zone ownership when a number is ported out 
of a block - DNS semantics doesnt deal well with a "exception override" 
over a delegation boundary. If each number is entered in itself - no 
problem, because zone ownership for that number mirrors the changed 
carrier-of-record status.

The rules are:
- a carrier-of-record for a given number may populate the carrier subtree 
with this number, with RR's as she may see fit.
- a user may populate the user tree as per 3761 (section 2 requirement 2 in 
our I-D) as he sees fit.
- they are ships in the night - no need to coordinate between the two.

The reason why the carrier subtree location needs to be flexible and cant 
be assumed under the country code is that "Country Code does not equal 
Numbering Plan Administration"  (that's by and large a fix for the 
colonies, as far as we're concerned over here  ;))

Resolving a tree digit-by-digit is bound to increase lookups drastically, 
violating our proposed "single DNS lookup to reach any NAPTR" requirement 
(section 2 requirement one).

I guess I should give two examples. I assume the carrier subdomain location 
for the Austrian CC is 2, that is, right below the CC.

Example 1:
1. I obtain a corporate network number from the national number 
administrator, so I am the number holder. Lets assume the number is +43 
59966 .  Now I can enter that in User ENUM - and I'll have 
6.6.9.9.5.3.4.e164.arpa delegated to my own name server - in the zone I 
have my SIP AOR for my PBX, and maybe lots of other stuff - we have an open 
numbering plan here and I could have anywhere from 0 to 8 extra DDI digits 
after +43 59966 for my users. I choose to manage all User ENUM entries in 
my nameserver. I choose not to care about any carrier records my 
carrier-of-record of the week might want to have.  I might not even be in 
the position to manage such a record in case my gear happens to not support 
that.

2. I turn around and ask Telekom Austria (TA) to route that number in the 
PSTN, which is when they become the carrier of record for my number. They 
happen to interconnect with other carriers with IP and choose to use the 
carrier ENUM tree under +43 to do that, but I could care less.
Now they can enter that in the local carrier subtree: 
6.6.9.9.5.carrier.3.4.e164.arpa points their SBC.

3. I decide Foo Telco is better for me, so I port my number to Foo, hence 
Foo becomes the new carrier-of-record for my number and thus has the right 
to change 6.6.9.9.5.carrier.3.4.e164.arpa to point to the Foo SBC.

Example 2:
I have number +1 571.123.4567, which is in a US NPA, which happens to use 
the scheme I laid out. I assume that location for the +1 CC to be at 4, 
after the NPA.

1.  I have a user ENUM domain: 7.6.5.4.3.2.1.1.7.5.1.e164.arpa - nothing 
special here.
2.  My telco X chooses to interconnect on IP with others, among them TA and 
Foo, using our scheme, so she would enter their SBC information in the 
7.6.5.4.3.2.1.carrier.1.7.5.1.e164.arpa zone.

Since all this assumed to be well-known, a call to +1 571.123.4567 
originating from some other TA or Foo POTS subscriber could be be passed to 
X on IP, and vice versa. When X, Foo and TA eventually grow up, and decide 
to dump interconnect completely, they can switch to just interpret User 
ENUM records. Or both, as and when they see fit. Sun-Tsu says: "for the 
fleeing enemy, build a silver bridge."

At no point there is any interference between the subtrees, and a single 
lookup gets at any NAPTR. User-to-user between +43 59966.* and +1 
571.123.4567 works as per rfc3761.

Michael
http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html
ps: In practice, carrier records probably would point to carrier 
nameservers, and RR's would be in the zone hosted there, but that makes no 
difference.