ENUM Trial - Validation Processes of ENUM Registrants
Hi all. My name is Miguel Duarte and I work for the Portuguese NREN FCCN, VoIP Department. We are currently conducting an ENUM Trial together with the Portuguese telecoms regulator ANACOM and several other Portuguese telecommunications companies. One of our first steps is gathering information about possible validation and revalidation processes of ENUM registrants. We contacted Niall O'Reilly that suggested us to bring this issue up to the ENUM Working Group. So all experience, implemented scenarios and/or ideas you might want to share/discuss are more than welcome. Thanks in advance. BR, Miguel Duarte _____ SSC - Segurança e Serviços à Comunidade VoIP@RCTS FCCN - Fundação para a Computação Cientifica Nacional Foundation for National Scientific Computing Av. do Brasil, n.º 101 1700-066 Lisboa Portugal Telf: +351 300005100 Fax: +351 218472167 Web: <http://www.fccn.pt/> www.fccn.pt Aviso de Confidencialidade/Disclaimer Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 300005100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 300005100 and delete it immediately.
Hi Miguel, On 01.06.2011 13:43, Miguel Duarte wrote:
[...]
So all experience, implemented scenarios and/or ideas you might want to share/discuss are more than welcome.
the following describes in a nutshell how DENIC, the ENUM registry for Germany's +49 telephone numbers does it: . It is the foremost duty of the ENUM registrant to keep the DENIC member (aka. ENUM registrar) and DENIC up to date at all times wrt. the status of the ENUM delegation of a certain telephone number . DENIC does not mandate any particular method(s) for (re-) validation . It is essentially the ENUM registrar that needs to devise a robust method for (re-) validation, whatever it is in detail: copies of phone bills, SMS tokens in case of mobile numbers etc. . The last positive validation exercise for a certain number must not be older than 12 months . The ENUM registrar is the recored keeper of all such positive validation proves (Cf. http://www.denic.de/en/enum/registration-and-update/validation.html) Second to this, DENIC devised a COMPLAINT process: . This aims at solving issues with numbers where eg. at least at first sight, the holder of a telephone number is not the registrant of the correspondig ENUM domain (Cf. http://www.denic.de/en/enum/complaint.html) The general entry point for all ENUM related information on DENIC's website in English is: http://www.denic.de/en/enum/ Hope that helps - happy to answer any further question you might be having. All the best, Carsten
On 01.06.2011 13:43, Miguel Duarte wrote:
We are currently conducting an ENUM Trial together with the Portuguese telecoms regulator ANACOM and several other Portuguese telecommunications companies.
One of our first steps is gathering information about possible validation and revalidation processes of ENUM registrants.
So all experience, implemented scenarios and/or ideas you might want to share/discuss are more than welcome.
Have a look at RFC 4725 (and perhaps 5105). Our experience in Austria has been that an ENUM service independent of the PSTN operator for the phone number has almost no market potential. You need to integrate ENUM in commercial VoIP/phone services. And in that case, validation is trivial as the ENUM registrar is the same entity that allocated the number to the customer. otmar -- // Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 //
On 1 Jun 2011, at 16:55, Otmar Lendl wrote:
Our experience in Austria has been that an ENUM service independent of the PSTN operator for the phone number has almost no market potential.
Indeed. Though this is not just an Austrian experience. It appears to be a universal one. I think it's very hard to find any success story for ENUM on the Internet. Public ENUM is essentially dead. Apart (maybe) for phone numbers in blocks associated with VoIP operators. But even there, some of those operators are relying on termination fees for incoming calls from the PSTN. So they'd prefer their customers to have tel: URLs instead of sip: URLs. Which kind of defeats the point. I think it's time this WG considered its future. The IETF WG has closed down. That should be a very clear hint.
I think it's time this WG considered its future. The IETF WG has closed down. That should be a very clear hint. It is a clear hint that the definition of the standards are finished. jaap
For public ENUM certainly ... -----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Jaap Akkerhuis Sent: Wednesday, June 01, 2011 12:54 PM To: Jim Reid Cc: RIPE ENUM WG Subject: Re: [enum-wg] market potential/future for public ENUM I think it's time this WG considered its future. The IETF WG has closed down. That should be a very clear hint. It is a clear hint that the definition of the standards are finished. jaap
Well as your former ENUM WG chair (yea!! NO BLUE DOT!!!) .. Yes public ENUM is essentially dead. ENUM as a technology however is doing _extremely_ well in converged teleco core networks where a locally cached ENUM infrastructure is used for number translations. The poster child for this is Verizon. Here is a presentation from SIPNOC. http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,49 1/Itemid,261/ This is the SS7/TCAP replacement market. There are lots of ENUM based federations out there providing competitive carrier interconnections and it's a core technology defined as part of IMS 3GPP GSMA/IR67 etc. There is unfinished work for those that need to use ENUM technology in converged IP networks, but this is more of a teleco specific issue than a generalized Internet issue. It is also highly relevant to national numbering administrations that are looking for converged LNP solutions. The Dutch and the COIN database folks have done a great job here on that issue. The situation in the UK, for instance, is a total disaster. In the US we are just rolling along ripping out TDM Class 5 switches whenever possible and giving our national regulator a huge migraine trying to define what is Interconnected VoIP. There is lots of talk on this side of the pond on enabling HD-Voice on converged networks. The metadata issue is not going away and SPID-Interconnection issue will heat up shortly. See you in Quebec City. -----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Jim Reid Sent: Wednesday, June 01, 2011 12:20 PM To: RIPE ENUM WG Subject: [enum-wg] market potential/future for public ENUM On 1 Jun 2011, at 16:55, Otmar Lendl wrote:
Our experience in Austria has been that an ENUM service independent of the PSTN operator for the phone number has almost no market potential.
Indeed. Though this is not just an Austrian experience. It appears to be a universal one. I think it's very hard to find any success story for ENUM on the Internet. Public ENUM is essentially dead. Apart (maybe) for phone numbers in blocks associated with VoIP operators. But even there, some of those operators are relying on termination fees for incoming calls from the PSTN. So they'd prefer their customers to have tel: URLs instead of sip: URLs. Which kind of defeats the point. I think it's time this WG considered its future. The IETF WG has closed down. That should be a very clear hint.
The situation in the UK, for instance, is a total disaster.
Of OFCOM's making. If we had an LNP database, it would be using ENUM. Unfortunately OFCOM apparently doesn't believe we need one, at least not for fixed-line services. Ray
On 2 Jun 2011, at 08:29, Ray Bellis wrote:
If we had an LNP database, it would be using ENUM. Unfortunately OFCOM apparently doesn't believe we need one, at least not for fixed- line services.
To be fair, there is of course nothing that prevents the telcos doing this on their own without Ofcom's adult supervision. I wonder why they just don't it. IIRC, the last time centralised number portability was discussed, Ofcom took the view that this was an industry problem and it was up to industry to figure it out. Since no consensus industry view emerged, Ofcom sat on their hands. You'll know much more about that Ray than I do because of your involvement in NICC. BTW, an ENUM-driven LNP database would not be in the public DNS for the obvious reasons.
To be fair, there is of course nothing that prevents the telcos doing this on their own without Ofcom's adult supervision. I wonder why they just don't it.
They/we are trying (quite hard at the moment), but there are 30+ different views (oft conflicting) that need to be reconciled without many commercial imperatives to do so. It would be helpful for the regulator to set better incentives and facilitate the reconciliation as they are best placed to do this (owning both the carrot and the stick). But this probably has little to do with ENUM, although it is one of the main contributing factors as to why UK public ENUM is dead in the water. Cheers Peter (UK ENUM Consortium Chair, Telco Owner)
I think there is a way to go in implementing ENUM. It took something like 15 years to reach the point where BT decided multicast is a good idea! Sometimes dinosaurs evolve and find they have to eat the dog food after all. Christian On 2 Jun 2011, at 10:13, Peter Gradwell wrote:
To be fair, there is of course nothing that prevents the telcos doing this on their own without Ofcom's adult supervision. I wonder why they just don't it.
They/we are trying (quite hard at the moment), but there are 30+ different views (oft conflicting) that need to be reconciled without many commercial imperatives to do so. It would be helpful for the regulator to set better incentives and facilitate the reconciliation as they are best placed to do this (owning both the carrot and the stick).
But this probably has little to do with ENUM, although it is one of the main contributing factors as to why UK public ENUM is dead in the water.
Cheers Peter
(UK ENUM Consortium Chair, Telco Owner)
I have to admit I am constantly amazed at how the EU carriers have trained the European Commission and the EC regulators with all of the skill and professionalism of their American counterparts. If I could only do that with my dogs. LNP for instance is a total mess even with, how many directives from Brussels? We may not be able to get public ENUM off the ground for a while but we certainly can imbed the technology in their networks to the point where it can't be ignored. Its not a futile effort. Its still a very useful thing to rid the planet Earth of the petulance of TDM/SS7/Class5 networks. Well I hinted at this yesterday...this is the next carrier ENUM application. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SP URN Author(s) : Penn Pfautz Filename : draft-pfautz-service-provider-identifier-urn-00.txt Pages : 5 Date : 2011-06-02 This document requests a service provider identifier URN namespace. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier -urn-00.txt -----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Christian de Larrinaga Sent: Thursday, June 02, 2011 5:56 AM To: Peter Gradwell Cc: Jim Reid; Ray Bellis; Richard Shockey; RIPE ENUM WG Subject: Re: [enum-wg] ENUM and number portability I think there is a way to go in implementing ENUM. It took something like 15 years to reach the point where BT decided multicast is a good idea! Sometimes dinosaurs evolve and find they have to eat the dog food after all. Christian On 2 Jun 2011, at 10:13, Peter Gradwell wrote:
To be fair, there is of course nothing that prevents the telcos doing
without Ofcom's adult supervision. I wonder why they just don't it.
They/we are trying (quite hard at the moment), but there are 30+ different views (oft conflicting) that need to be reconciled without many commercial imperatives to do so. It would be helpful for the regulator to set better incentives and facilitate the reconciliation as they are best placed to do
this on their own this (owning both the carrot and the stick).
But this probably has little to do with ENUM, although it is one of the
main contributing factors as to why UK public ENUM is dead in the water.
Cheers Peter
(UK ENUM Consortium Chair, Telco Owner)
I thought the problem was the Crown Court case brought by Vodaphone overturning the NICC RFP -----Original Message----- From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] Sent: Thursday, June 02, 2011 3:30 AM To: Richard Shockey Cc: RIPE ENUM WG Subject: Re: [enum-wg] market potential/future for public ENUM
The situation in the UK, for instance, is a total disaster.
Of OFCOM's making. If we had an LNP database, it would be using ENUM. Unfortunately OFCOM apparently doesn't believe we need one, at least not for fixed-line services. Ray =
On 2 Jun 2011, at 15:26, Richard Shockey wrote:
I thought the problem was the Crown Court case brought by Vodaphone overturning the NICC RFP
NICC only produces technical standards. In this case a working group (of industry representatives) was formed well in advance in anticipation of the OFCOM requirement to create an LNP database. Once OFCOM had consulted on LNP and decided it wanted to go ahead and require one, the telcos created "UK Porting" to work on the commercial requirements and to issue the RFP for an implementation. Vodafone took OFCOM to the Competition Appeal Tribunal, and won, primarily on the basis that OFCOM's cost-benefit-analysis was flawed. The result was a new CBA, which determined that there was an economic case for LNP and direct routing on mobile networks, but not for fixed networks. Ray
OK.. what idiots. The problem is that without a real LNP database you can't transition off the Class 5 switches efficiently and go to a converged IP core network. That is what is happening in the US. The level of real interconnected SIP/IMS is pushing 35% of all US voice calls and with VoLTE it will be 70%+. You use LNP to optimize the proxy platforms. -----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Ray Bellis Sent: Thursday, June 02, 2011 10:40 AM To: Richard Shockey Cc: RIPE ENUM WG Subject: Re: [enum-wg] market potential/future for public ENUM On 2 Jun 2011, at 15:26, Richard Shockey wrote:
I thought the problem was the Crown Court case brought by Vodaphone overturning the NICC RFP
NICC only produces technical standards. In this case a working group (of industry representatives) was formed well in advance in anticipation of the OFCOM requirement to create an LNP database. Once OFCOM had consulted on LNP and decided it wanted to go ahead and require one, the telcos created "UK Porting" to work on the commercial requirements and to issue the RFP for an implementation. Vodafone took OFCOM to the Competition Appeal Tribunal, and won, primarily on the basis that OFCOM's cost-benefit-analysis was flawed. The result was a new CBA, which determined that there was an economic case for LNP and direct routing on mobile networks, but not for fixed networks. Ray
On 1 jun 2011, at 19.14, Richard Shockey wrote:
Well as your former ENUM WG chair (yea!! NO BLUE DOT!!!) .. Yes public ENUM is essentially dead.
That just because the holders of E.164 does not allow end users that use the E.164 in question have the ENUM record in DNS refer to whatever they want. 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. This has nothing directly to do with ENUM, but rather whether the E.164 number should be tied to one and only one specific provider of services or not. I also copy cooperation wg in RIPE as that wg is one that could discuss this lock-in situation that exists. Patrik
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? 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? :-)
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?
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 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
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
On 06/02/2011 12:26 PM, Patrik Fältström wrote: 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
From operational point of view only well educated people are capable of
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. 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
On 2 Jun 2011, at 14:15, Ričardas Pocius wrote:
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.
Many telcos consider that sort of information to be not just private, but highly sensitive. For instance it discloses info about the ingress and egress points to/from their networks: where their SBCs and SS7 switches are located, network topology, etc. The industry obviously needs to know this stuff. It's debatable whether it should be known to the general public. A public NP database brings other concerns too. It opens up a new vector for slamming. It would publish info about which numbers are active and/or ported in a number block. If I was running a telco, I'd not be too keen on making that sort of information available to my competitors. It would also be too easy for telemarketers to mine that public database and harvest all the unlisted phone numbers.
Well said Jim .. and the competitive aspect of the data is potentially the most frightening to a telco. It could be mined to determine which consumers switched carriers. It would be unbelievably effective in testing marketing campaigns which is why administrator of the US LNP databases is specifically prohibited from sharing the data with anyone other than the regulator. Now as a side bar ..there is this little dispute in the US about ATT buying T-Mobile and in the only known instance of disclosure the US Justice department requested from the FCC and received the LNP data. Presumably to mine it in its anti-trust evaluation of the merger. -----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Jim Reid Sent: Thursday, June 02, 2011 3:46 PM To: Ričardas Pocius Cc: enum-wg@ripe.net Subject: Re: [enum-wg] market potential/future for public ENUM On 2 Jun 2011, at 14:15, Ričardas Pocius wrote:
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.
Many telcos consider that sort of information to be not just private, but highly sensitive. For instance it discloses info about the ingress and egress points to/from their networks: where their SBCs and SS7 switches are located, network topology, etc. The industry obviously needs to know this stuff. It's debatable whether it should be known to the general public. A public NP database brings other concerns too. It opens up a new vector for slamming. It would publish info about which numbers are active and/or ported in a number block. If I was running a telco, I'd not be too keen on making that sort of information available to my competitors. It would also be too easy for telemarketers to mine that public database and harvest all the unlisted phone numbers.
On 06/02/2011 10:45 PM, Jim Reid wrote:
On 2 Jun 2011, at 14:15, Ričardas Pocius wrote:
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.
Many telcos consider that sort of information to be not just private, but highly sensitive. For instance it discloses info about the ingress and egress points to/from their networks: where their SBCs and SS7 switches are located, network topology, etc. The industry obviously needs to know this stuff. It's debatable whether it should be known to the general public.
That must depend on LNP/MNP solution. We only store number -> SP ID (routing prefix) mappings. No INGRESS/EGRESS SPCs, no IP addreses of SBCs.
A public NP database brings other concerns too. It opens up a new vector for slamming. It would publish info about which numbers are active and/or ported in a number block. If I was running a telco, I'd not be too keen on making that sort of information available to my competitors. It would also be too easy for telemarketers to mine that public database and harvest all the unlisted phone numbers.
Again implementation specific ... we do not treat ported numbers as exceptions in dial plan. We have no blocks anymore. An assignment can be as small as one national number. We have mappings for all assigned numbers (not just active) to SP ID (routing prefixes). Number porting is process of re-assigning number from one SP to another. When you have all assigned numbers in database it is not easy to find out what number are ported and not just assigned. You can always compare whole dataset time after time to find out changes ... hm hm with some harvesting effort. Hey new killer application for botnets... -- Best regards, Ričardas Pocius CTO UAB „Mano numeris“ tel:+37068678511
On 2 jun 2011, at 21:46, "Jim Reid" <jim@rfc1035.com> wrote:
For instance it discloses info about the ingress and egress points to/from their networks: where their SBCs and SS7 switches are located, network topology, etc.
Security by obscurity... Ever heard of split zones, or routing protocols? ;-) Patrik
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
Patrik is right. It really is a competition issue. What I'm sure of is that E.164 is NOT going away anytime soon despite what our IETF colleagues think. The competition issue is also the driver for carrier ENUM as well. I'm getting serious hints on this side of the pond that the driver is HD Voice (G.722) especially for the LTE mobile deployments rolling out in 2012. The carriers finally realized they cant deploy anything new if the number translation infrastructure remained the same. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Thursday, June 02, 2011 5:27 AM To: Jim Reid Cc: Richard Shockey; RIPE ENUM WG; cooperation-wg@ripe.net Subject: Re: [enum-wg] market potential/future for public ENUM On 2 jun 2011, at 11.17, Jim Reid wrote: parties run DNS for the E.164 numbers in question.
True. But, playing Devil's Advocate, why would a regulator want to
intervene?
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 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
On 2 jun 2011, at 17.12, Richard Shockey wrote:
Patrik is right. It really is a competition issue. What I'm sure of is that E.164 is NOT going away anytime soon despite what our IETF colleagues think.
It is going away from the minds of people. People have the E.164 in their address books etc, and even though E.164 is used for the actual dialing, it is less and less important what the number is, that you can keep your number etc. It is there in some vcard that you pass around, and it could as well include a SIP address or whatever. The importance is fast going away.
The competition issue is also the driver for carrier ENUM as well. I'm getting serious hints on this side of the pond that the driver is HD Voice (G.722) especially for the LTE mobile deployments rolling out in 2012. The carriers finally realized they cant deploy anything new if the number translation infrastructure remained the same.
No, that is not the driver. It is the other way around. People invent new services, and then the question is what identifier one should use. Incumbents that do have E.164 numbers of course want to use them. Others do not want to use E.164 numbers. Who has innovated most the last 100 years? In the telephony space, champagne bottles where opened when they invented '*' and '#' on the phones, and that was probably the greatest invention for the 15 year period around it. On the Internet we get a new good service every minute. Patrik -- being provocative by design at the moment to make my point
-----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Thursday, June 02, 2011 5:27 AM To: Jim Reid Cc: Richard Shockey; RIPE ENUM WG; cooperation-wg@ripe.net Subject: Re: [enum-wg] market potential/future for public ENUM
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?
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
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
--On Thursday, June 02, 2011 17:18 +0200 Patrik Fältström <paf@cisco.com> wrote:
On 2 jun 2011, at 17.12, Richard Shockey wrote:
Patrik is right. It really is a competition issue. What I'm sure of is that E.164 is NOT going away anytime soon despite what our IETF colleagues think.
It is going away from the minds of people. People have the E.164 in their address books etc, and even though E.164 is used for the actual dialing, it is less and less important what the number is, that you can keep your number etc.
It is there in some vcard that you pass around, and it could as well include a SIP address or whatever.
The importance is fast going away. ... People invent new services, and then the question is what identifier one should use.
Incumbents that do have E.164 numbers of course want to use them.
Others do not want to use E.164 numbers. ...
This is, of course, consistent with another industry trend, even in the E.164 PSTN and closely-related spaces. A few decades ago, people typically had two phone numbers: "work" and "home". The second was often shared (e.g., with other family members); the first one might be (with coworkers or a main switchboard). Now we've got multiple numbers associated with different media (a mobile phone or two), services (PSTN and VoIP and fax), sometimes numbers in different countries or areas to save callers toll charges, and so on. And, of course, there are other services -- e.g., email, IM, non-E.164-VoIP services -- that don't normally use E.164 numbers at all. If a correspondent has more than a handful of contact point identities, it becomes rapidly clear that one wants to reach a particular person or function, not a long-obsolete surrogate for a copper pair and whomever happens to be standing close to its terminal. In the current world, E.164-style numbers have exactly one major user advantage over other types of identifiers and that is that all-numeric strings survive internationalization with far less trouble and confusion than alphanumeric identifiers. Other than that, the competition comments apply -- all of the advantages go to the incumbent holders of those numbers and, perhaps, the manufacturers of older-style terminals (those that, unlike the more common devices Patrik mentions, don't support address books). If someone asked me where to make a big investment in the hope of seeing a large ROI these days, it wouldn't be in E.164 numbers, especially public-tree ones. The opportunity might have been there for a while to make them really useful, but a variety of factors and institutions conspired to let that window close by trying to hold on to old, PSTN-dominated, ways of doing things. john
Hi Otmar. Thanks for your comment. The RFC 4725 states the following: "The actual validation methods applied may vary depending on, e.g., the particular party, available data sources, Assignee's choice, and regulatory requirements. Validation methods are out of scope of this document". The RFC 5105 describes the ENUM Validation Token sent to the Registry on successful completion of a validation. So finally both RFCs are not that much of a help for the validation and revalidation process between Registrant and the Validation Entity (VE). Do you have currently any entity performing the VE role beyond the actual telco operators? Thanks again for your help. Cheers. Miguel Duarte -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: quarta-feira, 1 de Junho de 2011 16:55 To: Miguel Duarte Cc: enum-wg@ripe.net; gestao@voip.fccn.pt Subject: Re: [enum-wg] ENUM Trial - Validation Processes of ENUM Registrants On 01.06.2011 13:43, Miguel Duarte wrote:
We are currently conducting an ENUM Trial together with the Portuguese
telecoms regulator ANACOM and several other Portuguese
telecommunications companies.
One of our first steps is gathering information about possible
validation and revalidation processes of ENUM registrants.
So all experience, implemented scenarios and/or ideas you might want
to share/discuss are more than welcome.
Have a look at RFC 4725 (and perhaps 5105). Our experience in Austria has been that an ENUM service independent of the PSTN operator for the phone number has almost no market potential. You need to integrate ENUM in commercial VoIP/phone services. And in that case, validation is trivial as the ENUM registrar is the same entity that allocated the number to the customer. otmar -- // Otmar Lendl < <mailto:lendl@nic.at> lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 //
Hi Miquel, In real-life ENUM is merely an attribute of a SIP service, it did not really succeed as a stand-alone product or service. The entity that provides the SIP service and the associated phone numbers (e.g. telco operator moving to IP) has already the tools in place for validating and porting E.164 numbers. ENUM just make them possible to be used on IP so is little additional work you have to do at this point, if at all. ENUM is today embedded in many VoIP services infrastructures as a routing mechanism for the operators, but the end-users do not know about it so there is little validation necessary as the customer is already on that infrastructure and ENUM does not change the relation with the customer. There may be other uses cases for ENUM besides SIP for VoIP but they did not materialize yet at a large scale. Adrian On Jun 1, 2011, at 1:43 PM, Miguel Duarte wrote:
Hi all.
My name is Miguel Duarte and I work for the Portuguese NREN – FCCN, VoIP Department. We are currently conducting an ENUM Trial together with the Portuguese telecoms regulator ANACOM and several other Portuguese telecommunications companies. One of our first steps is gathering information about possible validation and revalidation processes of ENUM registrants. We contacted Niall O'Reilly that suggested us to bring this issue up to the ENUM Working Group. So all experience, implemented scenarios and/or ideas you might want to share/discuss are more than welcome.
Thanks in advance.
BR, Miguel Duarte SSC - Segurança e Serviços à Comunidade VoIP@RCTS FCCN - Fundação para a Computação Cientifica Nacional Foundation for National Scientific Computing Av. do Brasil, n.º 101 1700-066 Lisboa – Portugal Telf: +351 300005100 Fax: +351 218472167 Web: www.fccn.pt
Aviso de Confidencialidade/Disclaimer Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 300005100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 300005100 and delete it immediately.
participants (14)
-
Adrian Georgescu -
Carsten Schiefner -
Christian de Larrinaga -
Jaap Akkerhuis -
Jim Reid -
John Klensin -
Miguel Duarte -
Otmar Lendl -
Patrik Faltstrom (pfaltstr) -
Patrik Fältström -
Peter Gradwell -
Ray Bellis -
Richard Shockey -
Ričardas Pocius