[enum-wg] market potential/future for public ENUM

On 06/02/2011 12:26 PM, Patrik Fältström wrote:
> On 2 jun 2011, at 11.17, Jim Reid wrote:
> 
>> On 2 Jun 2011, at 09:07, Patrik Fältström wrote:
>>
>>> Only regulation can unlock this situation. That forces E.164 holders to either have a DNS that people can enter whatever they want, or let third parties run DNS for the E.164 numbers in question.
>>
>> True. But, playing Devil's Advocate, why would a regulator want to intervene?
One of goals of regulator is to ensure healthy competition. Placing
service providers in position where they can decide what records can be
put in public tree and what records are not allowed restrict
competition. We used this point while drafting rules of ENUM operations
in Lithuania. It up to subscriber to decide what is in their zone. We
have regulations saying that. :-) Regulator is friend of common man
first and operators/service providers later or at least in Lithuania it
is ..

> 
> From a competition point of view.
> 
> The question is of course if the E.164 is to be used for other services than voice. If so, without unbundling of E.164 from the (one) provider of services, only the provider of the voice service that the E.164 is tied to can also provide other services (like video conferencing, SIP etc).
> 
> It is completely up to the regulators what kind of competition and open market they want.
> 
>> I expect they'd feel there was no point because the market has already made its decision about public ENUM. That would also get them off the hook for regulatory oversight of the Tier-1 delegation and name space: registry contract, codes of conduct, SLAs, etc. If you were the regulator, what path would you choose? :-)
> 
> I would immediately require the provider that is tied to the E.164 to
> 
> 1. Run DNS/ENUM for the numbers they provide services for
> 
> 2. Give the ability for the user of the E.164 to say what URIs the NAPTRs for the E.164 should refer to
> 
> 3. As alternative to 1+2, give the ability for the user of the E.164 to run DNS themselves (directly or indirectly at a third party DNS provider)
> 
> 4. Require the ones that run the LNP database (or equivalent) to expose the content via ENUM


We have regulations allowing subscribers to host zones where they want
and put any records in zone. When subscriber disconnect service (looses
right to use number) delegations are removed for particular number. When
subscriber ports there number they keep rights to use number ( and
delegation of ENUM zone). The problem with this way was that zone size
was reduced to single number (no blocks), because every single number
can be ported/assigned/reclaimed to numbering pool-> lots of small zones.

>From operational point of view only well educated people are capable of
properly setting DNS servers up and filling zone data. That is why we
have created a free to use user site (read registrar service) for less
educated people to request zone, host a zone and populate records. It
seams not enough and it is still too complex for ordinary man.  We have
like 600 zones ..thats it.

I would like to have some standard interface/document (not bind zone)
format so service providers could give records needed to be populated
and users could just import it. Users should have options to remove
records populated by this or that service provider. That would still
allow user to be in control of what is their zone and service provider
to get in zone what is needed for service to work. Of course that sound
simple but it is not ( ORDER /PREFERENCE collisions etc.) I once heard
Patrik suggesting using different sub-domains for different services
(sip.x.x.x.e164.arpa ) to fight that but as far as I remember this plan
had other problems ( not standard way/nobody will use that/what if there
are multiple service providers for SIP).

Finally we have also experimented on providing LNP + MNP in public tree
( with prefix suffix i like 3.7.0.i.e164.arpa :-) but there is no
recommendation on how to do it properly and we would loose some random
cash ( not huge  but still we are LNP+MNP provider in Lithuania and sell
LNP/MNP database push service). What are real use cases for LNP/MNP data
in public tree ? It believe it has a place in different root (could be
public) with strict uniform data format to be useful.

I do not understand people writing LNP/MNP data should no be in public
zones; there is no private data there, just technical information how
(where) to route calls properly.


> 
> It is serious now. Either E.164 numbers will never again be used, and will die a slow death, or it will be used also in the future. It is up to the regulator.
> 
>    Patrik
> 
It not dead is not alive either. 10 countries in production is not
enough to be attractive. We are still in catch 22 situation. Time will tell.

That was my rant ... now back to work.

-- 
Ričardas Pocius
0.7.3.e164.arpa registry
LNP/MNP database for +370