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

From: "Rosbotham, Paul" <[email-masked]>
Date: Sun, 10 Jul 2005 12:36:48 -0400

...but in the second variant it presupposes that the choices already made at a national level for user-ENUM are suitable/acceptable for carrier-ENUM.  There are many locations where .e164.arpa delegations have proceeded upon a set of assumptions, and the system being used for wholesale PSTN replacement wasn't one of them (and, for the record, I'm not referring to the UK here, as the current delegation is only for trial purposes).

Personally, I think the proposal is a good idea, but only in the c.c.carrier.e164.arpa guise : I don't regard carrier.c.c.e614.arpa as being workable.  And yes, I know that means another N years of debate at ITU...

Regards

Paul 

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
Stastny Richard
Sent: Saturday, July 09, 2005 9:33 AM
To: Michael Haberler; Michael Hammer (mhammer)
Cc: enum at ietf.org
Subject: Re: [Enum] Agenda items for IETF Paris

>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.
 
First, there is no regulation, it is only a recommendation to
put it after the cc, as Michael already pointed out
 
And for the avoidance of doubt:
 
the proposals c.c.carrier.e164.arpa and
carrier.c.c.e614.arpa are technically (or DNS wise) 
completely equivalent
 
It is also obvious that the first variant is more straightforward.
The preference for the latter variant is simply because
of practical administrative and political reasons.
 
In the second variant everything stays a national matter,
in the first variant the debate on the  international level would
start over again (2-3 years?), and then you have again the debate on the
national level.

With the second variant we jump over the international
debate and can start immediately with the national debate.
This is enough anyway.
 
-richard

________________________________

Von: enum-bounces at ietf.org im Auftrag von Michael Haberler
Gesendet: Sa 09.07.2005 01:58
An: Michael Hammer (mhammer)
Cc: enum at ietf.org
Betreff: RE: [Enum] Agenda items for IETF Paris

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.

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

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

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service,  visit http://www.cw.com/uk/emailprotection/ 
 
The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.

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

---

From: Richard Shockey <[email-masked]>
Date: Sun, 10 Jul 2005 13:18:31 -0400

At 12:36 PM 7/10/2005, Rosbotham, Paul wrote:
...but in the second variant it presupposes that the choices already made 
at a national level for user-ENUM are suitable/acceptable for 
carrier-ENUM.  There are many locations where .e164.arpa delegations have 
proceeded upon a set of assumptions, and the system being used for 
wholesale PSTN replacement wasn't one of them (and, for the record, I'm 
not referring to the UK here, as the current delegation is only for trial 
purposes).

Personally, I think the proposal is a good idea, but only in the 
c.c.carrier.e164.arpa guise : I don't regard carrier.c.c.e614.arpa as 
being workable.
Thank you .. I probably should have restated my technical issue more 
clearly .. c.c.carrier.e164.arpa only requires the choice of one DDDS data 
base tree vs 200 + if the rewrite rule required carrier.c.c.e164.arpa

And yes, I know that means another N years of debate at ITU...
Lets not prejudge our distinguished colleagues in Geneva.

Regards
Paul

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum