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

From: "Stastny Richard" <[email-masked]>
Date: Sat, 09 Jul 2005 04:29:53 -0400

>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

---

From: Richard Shockey <[email-masked]>
Date: Sat, 09 Jul 2005 15:47:41 -0400

At 04:33 AM 7/9/2005, Stastny Richard wrote:
>I don't think it a good idea
to regulate where in the tree (e.g. after 3

 
the proposals c.c.carrier.e164.arpa and
carrier.c.c.e614.arpa are technically (or DNS wise) 
completely equivalent
well technically equivalent as far as the DNS is concerned, but they are
radically different proposals if you are the poor schmuck that has to
design a SIP proxy and call processing logic necessary to create a
session.
 
It is also obvious that the first variant is more
straightforward.
Yes very much so  cc.carrier.164.arpa is no question the simplest to
actually implement across any service providers network.  It
directly draws on the simplicity of the First Well Known Rule as defined
in RFC 3761.

"The First Well Known Rule for this Application is the identity
rule.
   The output of this rule is the same as the input.  This
is because
   the E.164 namespace and this Applications databases are
organized in
   such a way that it is possible to go directly from the name
to the
   smallest granularity of the namespace directly from the name
itself."

from there the proxy, softswitch or CMS...,depending on your
industry,  know exactly how to find either the user or
"carrier" trees because all you have to do at that point is
decide which database you want to use..  [RFC 3761 Section
2.4]

4. Append the string ".e164.arpa" to the end. 
Example:
      8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa

The preference for the
latter variant is simply because
of practical administrative and political reasons.
Yes there MAY be practical and political reasons for
carrier.c.c.e164.arpa. As a wise man on this list remarked to me
personally " I would prefer not to spend the remaining years of my
career in Geneva." 
I am not convinced that the IAB-ITU rules on the use of e164.arpa need to
be renegotiated in order to implement this proposal pre
cc-delegation.  
However technically it will be a total nightmare to implement post cc
delegation in carrier.c.c.e164.arpa. The reason is simple. This will
require every SS, proxy and CMS server to maintain internal tables
necessary to decode the Application Unique String  [ RFC 3761 
section 2.1] into its component parts ( in this case Country Code from
the rest of the E.164 string) in order to be able decide on what database
[Section 2.4 again] you want to use.
Once upon a time ages and ages ago ..before there even was HTTP (aka
stone age)  .  I designed IVR systems for Fax on Demand and the
worst nightmare imaginable was defining these tables internally to the
call processing logic.
Now you are suggesting every proxy needs to somehow be able to decode 1
from 44 ( UK ) from 420 ( Czech from 380 (Ukraine) in order to write the
correct FQDN.
IMHO this will not happen. The effect on call set up could be
significant.
 
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.
you wish ...
 
-richard

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

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