Subject: RE: [Enum] Why not re-use interim procedures for infrastructure ENUM?

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 6 Feb 2006 12:58:25 +0100

On Monday, February 06, 2006 11:29 AM Rosbotham, Paul wrote:

> However, where delegation has already made for commercial service,
> this delegation was very much made under the criteria of the Tier One
> being selected for *USER* ENUM.  These criteria may or may not be
> applicable for infrastructure ENUM.  For example, it is a reasonable
> expectation that the telcos in the country concerned may  require
> some degree of joint control over the infrastructure ENUM Tier One,
> given its actions/performance would be critical in the routeing of
> calls to their customers.  The choice of Tier One for User ENUM
> certainly wouldn't have factored this in, or at least if it has it
> would be by co-incidence of similar stakeholder communities.         

My motivation to opose to that is strictly apolitical.
I would not want to see 2 different clubs trying to develop 2 different
kinds of ENUM. 
For transparancy by the market (for both Users AND Telcos) we should
avoid 2 different protocols being developed. 
I'm in favour of the Infrastructure ENUM tree being delegated under the
country code tree so it is clear who is responsible for the delegation
rules on a national level, and the technical development and
implementation is done by one and the same independent none biased
player.    
There is more than one danger in using ENUM as "club member" definition.
Besides the risk of propiatary Infrastructure ENUM solutions being
developed, it will also create the posibility that innovative players
are refused from the Infrastructure ENUM market for competition
reasons, and development of the USER ENUM market might be stopped.   
I believe that this strategic member club forming should not take place
at te ENUM level, but should take place at the (sip) peering level. 
Telcos' are now trying to abuse ENUM as their peering platform
definition since sip peering is not developed enough yet to define
parameters like QOS, security level, fee definition etc. This does not
belong in the ENUM definition. ENUM is only routing information, not
interconnection policy definition.    

So, ENUM is ENUM, and political games should be played at a different
level. 
The success of ENUM is in the lightweight of the protocol, without
overhead information. 
The overhead should be in the peering definitions, so USER ENUM does
not need to be bothered with it. 

Besides these development issues, I also see operational benefits in a
joint User and Infrastructure ENUM registry. 
When you want to switch from one tree to another (User-Infrastructure)
for the same phone number during a lookup, it would be nice if you
didn't need to resolve a complete new tree, or aquire new routing
Information for your lookup. Lookups wil go faster if both trees are 
linked lower down in the tree. 
It's also cheaper if you use the same infrastructure.    

Antoin Verschuren

Technical Advisor
Policy & Business Development
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525510
F +31 26 3525505
M +31 6 23368970
E [email-masked]
W http://www.sidn.nl/

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Mon, 6 Feb 2006 12:48:06 +0000

On Feb 6, 2006, at 11:58, Antoin Verschuren wrote:

> rules on a national level

Antoin, this idea is a non-starter IMO because it requires everything  
that might play in this space to always have complete, up to date  
knowledge of E.164 "country codes". Good luck getting the world's  
handsets and SIP servers -- to pick just two examples -- to do that.  
The algorithm for transforming an E.164 number into a domain name for  
Infrastructure/Carrier ENUM has to be simple. Just use RFC3761's with  
something other than "e164.arpa" as the apex and we're done.

For me this discussion is back to front. We're talking about  
delegation models and suchlike. But no requirements for  
Infrastructure ENUM have been proposed yet. We don't even appear to  
have an agreed terminology or definitions. Until this is done, it  
seems unwise to be discusing what's going to be built or how it will  
be constructed.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 06 Feb 2006 08:39:34 -0500

>> rules on a national level

Functionally however given the interim rules it makes no difference. The 
delegation of either Infrastructure or User ENUM branch for a specific 
CC would ultimately require the consent of the appropriate National 
Regulatory Authority even if the CC had been delegated.

> knowledge of E.164 "country codes". 

Thank you Jim .. that is exactly the reason. The soft switches and 
network elements that have to implement the system need the simplest 
possible rewrite rule delegation at a predetermined apex is IMHO the 
only way.

Good luck getting the world's
> handsets and SIP servers -- to pick just two examples -- to do that. The 
> algorithm for transforming an E.164 number into a domain name for 

That has been my inescapable conclusion since this discussion began.

> 
> For me this discussion is back to front. We're talking about delegation 
> models and suchlike. But no requirements for Infrastructure ENUM have 
> been proposed yet. We don't even appear to have an agreed terminology or 
> definitions. Until this is done, it seems unwise to be discusing what's 
> going to be built or how it will be constructed.

We do have WG items on this and once again Msr's Pfautz and Lind will be 
reviewing their document in Dallas.

All other issues are essentially political.

-- 

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 6 Feb 2006 14:59:35 +0000

> knowledge of E.164 "country codes".

Not so.

You could assume that the country code was always 3 digits long. This would
require a little more administration by those countries with 1 or 2 digit
codes, but not a lot. Or the rule could be to try 3, 2, and 1 digits in
that order. DNS caching will take care of most of the inefficiencies in
this.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Jim Reid <[email-masked]>
Date: Mon, 6 Feb 2006 15:40:41 +0000

> that order. DNS caching will take care of most of the  

"With sufficient thrust, pigs will fly".

What you are suggesting Clive is theoretically possible. But from a  
practical perspective, it's nonsense. Sorry. Even with DNS cacheing,  
the extra latency induced by additional and unnecessary lookups is a  
killer. And it's just crazy to suggest a scheme where significant  
numbers of DNS lookups will fail BY DESIGN. Especially when the  
overwhelming bulk of the world's telephone numbers live under 1 or 2  
digit country codes.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 6 Feb 2006 15:45:39 +0000

Jim Reid said:
>> codes, but not a lot.

> overwhelming bulk of the world's telephone numbers live under 1 or 2  

That doesn't prevent use of my other suggestion.