From fweimer at bfk.de Wed Jul 1 12:07:01 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 01 Jul 2009 10:07:01 +0000 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> (Rui Ribeiro's message of "Tue\, 30 Jun 2009 17\:06\:19 +0100") References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> Message-ID: <82tz1wzph6.fsf@mid.bfk.de> * Rui Ribeiro: > 2009/6/30 Florian Weimer : >> * Antoin Verschuren: >> >>> And for lager numberblocks there are different prices. One >>> delegation of 10.000 numbers will cost 2500,-, discounts negotiable, >>> so effectively this is 0,25 Euro per number. >> >> Does this mean that subscribers have to pay per extension/subdomain >> and are not free to create all the subdomains they want? Answering my own question to some extent: The first entry I found in the 1.3.e164.arpa zone is a delegation: 3.0.2.1.5.9.6.0.2.1.3.e164.arpa. 86400 IN NS ns.regeljeenum.nl. 3.0.2.1.5.9.6.0.2.1.3.e164.arpa. 86400 IN NS ns.fryslan-online.nl. I poked around a bit more, and there are several more (82 total), with several different name servers. So it seems to me that the zone is following the delegation model. Of course, this leaves the registry with no means to enforce typical regulatory requirements such that the names can only be used for ENUM (IIRC, there was such a requirement in the RegTP contract for the +49 trial). It also restricts billing options for the registry to some extent. (That's probably why .tel doesn't accept delegations.) > That is a great question. What kind of services are provided by registrars? > > - just number delegation towards the client DNS server? (the user can > make any update, at any time, of any information. User must be savy) This is what DENIC does for +49. It's most flexible for users, so they tend to derive the most value from it. Yet DENIC has repeatedly stated that registrations are below expectations. Would more restrictions make the product more attractive? I don't think so. PS: Two of the three 1.3.e164.arpa name servers are lame. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Antoin.Verschuren at sidn.nl Wed Jul 1 12:33:23 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 1 Jul 2009 12:33:23 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> Message-ID: <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> Subscribers pay per delegation. But because in NL we have a fixed number plan, we can also delegate numberblocks of 10, 100, 1000 or 10.000 numbers. If a numberblock can be validated against 1 single enduser, we delegate higher in the tree, and the price for 1 such delegation is higher than delegating a single number, but lower than delegating all the numbers individually. This is usefull because our regulator does make numberblock allocation directly to endcustomers without the intervention of a real telco for medium or large companies. What I sort of miss in this discussion is other use cases than voice. I think ENUM has 4 use cases: 1. Service operability 2. More efficient routing 3. Numberportability 4. Identity management The first depends on adoption of ENUM by applications. Will Skype do ENUM. Will MSN do ENUM. We have no influence on that other than promotion. The second is the telco game, or individuals that have enough knowledge and effort to bypass telco's. This is the voice game. Too political. Too financial The third one is the regulator game. Competition and markets, replacement of SS7. It will come, but not in User ENUM. The last one is often forgotten, but I predict this will be a big one in the time to come. It's OAUTH, OPENID, that sort of game. It's everyone that seeks a way to identify customers, customers need, or customers preferences to be able to give the customer what he wants the easy way. Almost every bank, webshop, bookstore club or social network has identity information stored, and is seeking for a global, standardized identity parameter to address an end user. Everybody has invented or is using his/her own system. User ENUM can be that technical identifier. The only thing that's missing is a safe and standardized protocol to exchange the identity information. ENUM can be your pointer to where my identity info is stored, possibly on multiple targets. What is missing is the standard protocol how to retrieve my identity info, how to decrypt it with the credentials I supply during the transaction (I decide if and what info I supply to which counter party during the transaction) how to manage it as an end user, and how to verify the authenticity of the data. I think OAUTH is a good first step, but as far as I understand it the first iteration of the protocol only has a supplier and receiver defined. What I miss is the definition of a trusted third party that signs the authenticity of the data so the receiver can trust the data if he trusts the third party. This is what we focus on in NL at the moment where our efforts to ENUM are concerned. So we talk with banks, identity management startups, etc, and they are greatly interested. They only lack some experience in the standard bodies and protocol development. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ > -----Original Message----- > From: Rui Ribeiro [mailto:racribeiro at gmail.com] > Sent: Tuesday, June 30, 2009 6:06 PM > To: Florian Weimer > Cc: Antoin Verschuren; enum-wg at ripe.net > Subject: Re: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business > case matter? > > 2009/6/30 Florian Weimer : > > * Antoin Verschuren: > > > >> And for lager numberblocks there are different prices. One > >> delegation of 10.000 numbers will cost 2500,-, discounts negotiable, > >> so effectively this is 0,25 Euro per number. > > > > Does this mean that subscribers have to pay per extension/subdomain > > and are not free to create all the subdomains they want? > > That is a great question. What kind of services are provided by > registrars? > > - just number delegation towards the client DNS server? (the user can > make any update, at any time, of any information. User must be savy) > - DNS hosting for any kind of registers? (the user accesses through a > web interface to it's own profile, and ads any kind of information in > type, and in number. Less savy, but has to have some knowledge) > - DNS hosting for predefined registers? (the user acesses through a > web interface to it's own profile, and selects from predefined > registers) > - DNS hosting for limited predefined registers? (as above, but with a > limited number of registers. How many?) > - DNS hosting limited for SIP? (as above, but only allowing SIP > records. Maybe even accepting only URI putting all the information > "around" them automaticly) > > Do you have others? > > Thanks, > > Rui Ribeiro > racribeiro at gmail.com From racribeiro at gmail.com Wed Jul 1 17:05:33 2009 From: racribeiro at gmail.com (Rui Ribeiro) Date: Wed, 1 Jul 2009 16:05:33 +0100 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> Message-ID: <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> Hi all, > But because in NL we have a fixed number plan, we can > also delegate numberblocks of 10, 100, 1000 or 10.000 numbers. !!! But the delegation from the registry is by prefix (only one register for each kind of delegation), or by number (there is a price reduction, but each number has it's own register) For me, only the second solution can be used. The first one, while more pratical and easy to deploy, may have a hard time longer on when the numbers start to "float" away in things like: renumbering, number portability, fusion/cisions of companies/users, ... If you delegate to the registrar A, 1000 numbers and the 352, for some reason (later), has to be moved away or unregistred from the tree on that registrar, how do you/they handle that? 1. substitution of 1 record for 999 records ant the registry? 2. substitution of 1 record by the last numbers of records possible, at least: 27 records... Either way, there are changes that have to be coordenated by the several DNS administrators. This is why I defend the solution, one number, one delegation. > I think ENUM has 4 use cases: > > 1. Service operability > 2. More efficient routing > 3. Numberportability > 4. Identity management > The second is the telco game, or individuals that have enough knowledge and effort to bypass telco's. This is the voice game. Too political. Too financial I believe that terminals will be easy enough to use directly, without "savy users". The miss of terminals is because of the lack of infrastructure... (ENUM isn't in place) > The last one is often forgotten, but I predict this will be a big one in the time to come. > It's OAUTH, OPENID, that sort of game. > It's everyone that seeks a way to identify customers, customers need, or customers preferences to be able to give the customer what he wants the easy way. > Almost every bank, webshop, bookstore club or social network has identity information stored, and is seeking for a global, standardized identity parameter to address an end user. > Everybody has invented or is using his/her own system. Do you think that users are willing to pay for this? What about companies? Would they make public this "ENUM" tree? or would be for internal use? Do you think that identity management makes sense? why? Are you thinking about "presence", emergency location, or other? Should a "identity management" system be based on another number rather then on the telephone number? Should ENUM "tecnology" be used on other services like... the index number insted of being the phone number could be the social security number... We then could call the Id, not the phone... > User ENUM can be that technical identifier. The only thing that's missing is a safe and standardized protocol to exchange the identity information. There are a few things... but clearly much "bigger" than what a DNS register would hold. Maybe a URI to another locaion where there would be a XML file would be ok. > This is what we focus on in NL at the moment where our efforts to ENUM are concerned. Thanks for you contribution! Rui Ribeiro racribeiro at gmail.com From Antoin.Verschuren at sidn.nl Wed Jul 1 17:20:08 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 1 Jul 2009 17:20:08 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? References: <82zlbq6rlq.fsf@mid.bfk.de><850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local><82prcl69n8.fsf@mid.bfk.de><943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> <82tz1wzph6.fsf@mid.bfk.de> Message-ID: <850A39016FA57A4887C0AA3C8085F949F02969@KAEVS1.SIDN.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > -----Original Message----- > From: Florian Weimer [mailto:fweimer at bfk.de] > Subject: Re: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business > case matter? > > PS: Two of the three 1.3.e164.arpa name servers are lame. Hmm, not 2 out of 3 at the same time, 1 out of 3 according to DNSMON. We had maintenance on our ENUM nameservers, moving them around and preparing some other stuff.. I'll have an announcement on why in a few days. Everything should be working again now. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSkt+qDqHrM883AgnAQirtAgA1qpD/yUjKacct2HD+Xg25g+9oS0mVUrX 9PsSZt5ZjeS7/Z4Ng4l5OsMzBRcX5xzP7HkJzNVlQI2ej/Nch0G7kMuMbEc0gymA nCjiw6r5azMAb9492jRn+o4qcEs9U8edvWh/hujCRIuL8idXWPpHfHp9XtlPxK0K oSK5lr1iVUtI4oZ8sYS6X0X13y3JBuvguh/ZjLCd3pRy+IvPaXkSBj7BIEDxCLWx lL6H8i4h6EioRf/0mFY8lrMNkKeLmp6RTPz1Rgy3ngTIPRHxbcZUZ8zr7XQ33r7u VJ+m0QPyH8JE7aJQiKaDjBtoejbDNRG7tmPUCjldssnUiMfCLloDQA== =B4m7 -----END PGP SIGNATURE----- From Antoin.Verschuren at sidn.nl Wed Jul 1 22:05:50 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 1 Jul 2009 22:05:50 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> Message-ID: <850A39016FA57A4887C0AA3C8085F949F02973@KAEVS1.SIDN.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Please read carefully: We only delegate a numberblock when it validates (the complete numberblock) to ONE end-customer. So for example the office of a multinational. Consumers usually don't own numberblocks. We don't have pre-fixes like in DE or AT. We have a fixed numberplan. All numbers have the same length, but you can own a thousand of them in one numberblock. (or 10, or 100, or 10.000) You are not allowed to extend your numbers (on the PSTN). The numbering plan in NL is such that numberblocks assigned to end customers are not split up. The end customer has numberportability for the complete numberblock. When that end-customer hands in their numberblock, the ENUM delegation for that block is deleted because it doesn't validate to the one end-customer anymore. For example, SIDN has a numberblock of 100 numbers. +31263525500 - +31263525599. All these 100 numbers have the same end customer: SIDN. So we delegate 5.5.2.5.3.6.2.1.3.e164.arpa to SIDN's nameservers. > Do you think that users are willing to pay for this? What about > companies? Would they make public this "ENUM" tree? or would be for > internal use? There are suppliers that want to pay for this, or for the transactions generated by this. Or let's give another question: how much do you pay for owning a creditcard ? > Do you think that identity management makes sense? why? Are you > thinking about "presence", emergency location, or other? Should a > "identity management" system be based on another number rather then on > the telephone number? Should ENUM "tecnology" be used on other > services like... the index number insted of being the phone number > could be the social security number... We then could call the Id, not > the phone... Another identity number or identifier would be fine for this as well. But everybody in the world has a phone, and a phone number. It's an already deployed and maintained globally unique identifier. I'm thinking of things like paying at the cashier with your mobile, doing transactions on ebay, identifying you're over 18 for a porn site, getting a discount at Amazon because you can prove -online- that you're a student at a certain university that Amazon has made a deal with. that sort of identification purposes. Hey, if the US wasn't so paranoid, it could even hold your passport :-). > There are a few things... but clearly much "bigger" than what a DNS > register would hold. Maybe a URI to another locaion where there would > be a XML file would be ok. Yes, the information is not in the DNS. Some sort of secured channel XML like schema that is encrypted and can be fetched with a new sort of protocol would hold the identity data signed by the publisher (your bank f.e, your university) and these "tokens" are maintained by you. You then decide for which transactions on a website you allow which data to be decrypted for use on that transaction only. ENUM only points to the place or places that you have stored these identification tokens. The only thing you need to type in at Amazon's website is your phonenumber, and you are automagicaly transferred to an application or secured website where you approve Amazone to get one, more, or part of your many tokens that it requires by authenticating with your password, certificate, or what level of security YOU desire for your tokens. You might even set a higher level of security for your creditcard than for your library subscription number... Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSkvBnjqHrM883AgnAQis3Af/QErF2JtqAoSzmNe9zqxbXtH1OLYCRzm9 shRq5kq9353cG9aEEUmZRihTDBZ5+awOujfvKM0TyCTHhKcb8PUyXWgFKvXS1qfQ AHCGoEJ+Q8sAhU8Y51OHP1enZzAbo+f2BzeEgCjUCbFtI8hmBovryns1X+ssL9/k c/pxPUTp1+QevWloSi4YemZVOIE7PfLNXbYwGes1oyYBfFE00TPfJL++n9Kjls2k j2RGz7ZBk5qRIp4sNScogGbOwPcszjNTbE3X3D8Gr2yDtLZdC/BpdGpZpBCTTL7K H0yrj5EjcTChM+SGRO8nLhMZ3D7dZ817VTSKc6spyNgnYgxJcfQ2xw== =7YzU -----END PGP SIGNATURE----- From md at bts.sk Thu Jul 2 08:37:35 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Thu, 2 Jul 2009 08:37:35 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949F02973@KAEVS1.SIDN.local> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F02973@KAEVS1.SIDN.local> Message-ID: <20090702063735.GA76156@bts.sk> On Wed, Jul 01, 2009 at 10:05:50PM +0200, Antoin Verschuren wrote: > We don't have pre-fixes like in DE or AT. We have a fixed numberplan. All numbers have the same length, but you can own a thousand of them in one numberblock. > (or 10, or 100, or 10.000) You are not allowed to extend your numbers (on the PSTN). > > The numbering plan in NL is such that numberblocks assigned to end customers are not split up. The end customer has numberportability for the complete numberblock. > When that end-customer hands in their numberblock, the ENUM delegation for that block is deleted because it doesn't validate to the one end-customer anymore. > > For example, SIDN has a numberblock of 100 numbers. +31263525500 - +31263525599. > All these 100 numbers have the same end customer: SIDN. > So we delegate 5.5.2.5.3.6.2.1.3.e164.arpa to SIDN's nameservers. Do I read this right ?! Are you really charging upto 2500 ? for one single delegation just because it happens a few subdomains higher in the ENUM tree? So a company or university with four digit extensions in NL would have to pay 100+ times more than another one in DE, AT or CZ ?! (note that CZ uses fixed numbering plan like NL) This is unbelievable... User ENUM is hardly alive anyway, and such pricing schemes will kill it completely. And I bet this kind of pricing heavily violates EU anti-monopoly legislation, since a dominant player is not allowed to charge different prices for the same service. -------------------------------------------------------------------------- ---- ---- ---- Marian ?urkovi? network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 571 041 81 ---- ---- Computer Centre, N?m. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- From Antoin.Verschuren at sidn.nl Thu Jul 2 09:21:47 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 2 Jul 2009 09:21:47 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F02973@KAEVS1.SIDN.local> <20090702063735.GA76156@bts.sk> Message-ID: <850A39016FA57A4887C0AA3C8085F949F029A8@KAEVS1.SIDN.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The registry is non-profit, but has to be payed. We did marketing research, and large companies are happy to get a discount for their large numberblock if they maintain part of the tree themselves. That's how they see it. They maintain their own zone and the administration per number, and in exchange they pay only 0,25 per number in stead of 5,-. It's seen as a bulk discount. It's either that, or the price of a single registration has to be higher, making it too expensive for a consumer with a one phonenumber entry. We wanted the price for a single number registration to be as low as possible so that the value per registration would be as high as possible for a registrant. I actually think it doesn't kill ENUM, but makes it more available to the consumers that are most on their pennies. Companies usually see the value in saving cost, and calculate on a per number basis, not per delegation. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ > -----Original Message----- > From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf Of > Marian Durkovic > Sent: Thursday, July 02, 2009 8:38 AM > To: enum-wg at ripe.net > Subject: Re: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business > case matter? > > On Wed, Jul 01, 2009 at 10:05:50PM +0200, Antoin Verschuren wrote: > > We don't have pre-fixes like in DE or AT. We have a fixed numberplan. > All numbers have the same length, but you can own a thousand of them in > one numberblock. > > (or 10, or 100, or 10.000) You are not allowed to extend your numbers > (on the PSTN). > > > > The numbering plan in NL is such that numberblocks assigned to end > customers are not split up. The end customer has numberportability for the > complete numberblock. > > When that end-customer hands in their numberblock, the ENUM delegation > for that block is deleted because it doesn't validate to the one end- > customer anymore. > > > > For example, SIDN has a numberblock of 100 numbers. +31263525500 - > +31263525599. > > All these 100 numbers have the same end customer: SIDN. > > So we delegate 5.5.2.5.3.6.2.1.3.e164.arpa to SIDN's nameservers. > > Do I read this right ?! Are you really charging upto 2500 ? for one single > delegation just because it happens a few subdomains higher in the ENUM > tree? > So a company or university with four digit extensions in NL would have to > pay > 100+ times more than another one in DE, AT or CZ ?! (note that CZ uses > fixed > numbering plan like NL) > > This is unbelievable... User ENUM is hardly alive anyway, and such pricing > schemes will kill it completely. And I bet this kind of pricing heavily > violates EU anti-monopoly legislation, since a dominant player is not > allowed to charge different prices for the same service. > > > -------------------------------------------------------------------------- > ---- ---- > ---- Marian ?urkovi? network manager ---- > ---- ---- > ---- Slovak Technical University Tel: +421 2 571 041 81 ---- > ---- Computer Centre, N?m. Slobody 17 Fax: +421 2 524 94 351 ---- > ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- > ---- ---- > -------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSkxgCzqHrM883AgnAQhaOAgAhd/F0GUTB7zVIsiyvKVBREe+UUjj5+eV lUtAuAJfDkFtQUak4AvM9GPuJ2mLtmma+tM4V2QsSgq1klQ6Tr8k3uFoQxB6oV/H IZNkICN6EiwM/KMvUePTJtfdNpZ0Enw3XePH9y+ZuRzKjjctcgViwpwUI/TuEtNb eDnxy07pE6fl2/glswFv2BsffjNPds54mYQzSoy/mM9mj2hqxJECASHa2Fxl0LNC +OqI5cBNyIBdjaw3PsC7ewuVlOft9Vb/XP25jPApfCT+TkvjyhXGZmw56pdGcNqN T+Cgxo5/UkUN9X+N8mvn7vJeyj+EEeD9bwFEshWDznm4kluexBcl7w== =/AUh -----END PGP SIGNATURE----- From marco.sommani at cnr.it Thu Jul 2 09:10:45 2009 From: marco.sommani at cnr.it (Marco Sommani) Date: Thu, 02 Jul 2009 09:10:45 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <20090702063735.GA76156@bts.sk> Message-ID: Let me add a historical note. DNS started to be used in the second half of the '80s when no one was thinking about charging for name registrations. Only ten years later, when people started to realize that having a domain name was useful, registries started to charge for them. If charging had begun in the late 80s, we would have no Domain Name System today. Services can be charged only when there is demand for them and this is true for ENUM too. Marco On 02/07/09 08:37, "Marian ?urkovi?" wrote: > > Do I read this right ?! Are you really charging upto 2500 ? for one single > delegation just because it happens a few subdomains higher in the ENUM tree? > So a company or university with four digit extensions in NL would have to pay > 100+ times more than another one in DE, AT or CZ ?! (note that CZ uses fixed > numbering plan like NL) > > This is unbelievable... User ENUM is hardly alive anyway, and such pricing > schemes will kill it completely. And I bet this kind of pricing heavily > violates EU anti-monopoly legislation, since a dominant player is not > allowed to charge different prices for the same service. > -- Marco Sommani Consiglio Nazionale delle Ricerche Istituto di Informatica e Telematica Via Giuseppe Moruzzi 1 56124 Pisa - Italia work: +390503158315 (PSTN and nrenum.net) mobile: +393487981019 (PSTN and e164.org) fax: +390503153273 mailto:marco.sommani at cnr.it From esther.makaay at enum.nl Fri Jul 3 10:46:34 2009 From: esther.makaay at enum.nl (Esther Makaay) Date: Fri, 3 Jul 2009 10:46:34 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? References: <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> Message-ID: <850A39016FA57A4887C0AA3C8085F949F02A45@KAEVS1.SIDN.local> Hey, Just offering a small explanation. > > But because in NL we have a fixed number plan, we can > > also delegate numberblocks of 10, 100, 1000 or 10.000 numbers. > > !!! But the delegation from the registry is by prefix (only one > register for each kind of delegation), or by number (there is a price > reduction, but each number has it's own register) > > For me, only the second solution can be used. The first one, while > more pratical and easy to deploy, may have a hard time longer on when > the numbers start to "float" away in things like: renumbering, number > portability, fusion/cisions of companies/users, ... > > If you delegate to the registrar A, 1000 numbers and the 352, for some > reason (later), has to be moved away or unregistred from the tree on > that registrar, how do you/they handle that? This is a non-issue. These numbers are delegated per-block only by the telephony-regulator. They cannot be split after delegation. If the PSTN delegation is terminated, the whole block goes back to the telephony- operator and then it might be split when the numbers are reassigned. In The Netherlands ENUM strictly follows the phonenumber, meaning it isn't possible to gain any rights or usage of a telephone number or numberblock by registration of an ENUM domain. The anomaly of these blocks exists in the telephone numberplan system. It's not something the ENUM registry invented to complicate the registration System. (To be honest, given all the validation misery that comes with it, we'd rather loose the whole block concept completely.) Kind regards, Esther Makaay -- ENUM NL T +31 26 352 5500 F +31 26 352 5505 E Esther.Makaay at enum.nl W http://www.enum.nl From Niall.oReilly at ucd.ie Fri Jul 3 11:51:12 2009 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 03 Jul 2009 10:51:12 +0100 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949F02A45@KAEVS1.SIDN.local> References: <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F02A45@KAEVS1.SIDN.local> Message-ID: <4A4DD490.9020409@ucd.ie> Esther Makaay wrote: > > This is a non-issue. These numbers are delegated per-block only by the > telephony-regulator. They cannot be split after delegation. If the PSTN > delegation is terminated, the whole block goes back to the telephony- > operator and then it might be split when the numbers are reassigned. > In The Netherlands ENUM strictly follows the phonenumber, meaning it > isn't possible to gain any rights or usage of a telephone number or > numberblock by registration of an ENUM domain. > The anomaly of these blocks exists in the telephone numberplan system. > It's not something the ENUM registry invented to complicate the registration > System. (To be honest, given all the validation misery that comes with it, > we'd rather loose the whole block concept completely.) I would have expected that blocks assigned directly in this way would lead to a simplification of the validation requirement, taking advantage of the aggregation. Perhaps I'm missing some key detail? /Niall From esther.makaay at enum.nl Fri Jul 3 12:09:20 2009 From: esther.makaay at enum.nl (Esther Makaay) Date: Fri, 3 Jul 2009 12:09:20 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? References: <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F02A45@KAEVS1.SIDN.local> <4A4DD490.9020409@ucd.ie> Message-ID: <850A39016FA57A4887C0AA3C8085F949F02A54@KAEVS1.SIDN.local> > > This is a non-issue. These numbers are delegated per-block only by the > > telephony-regulator. They cannot be split after delegation. If the PSTN > > delegation is terminated, the whole block goes back to the telephony- > > operator and then it might be split when the numbers are reassigned. > > In The Netherlands ENUM strictly follows the phonenumber, meaning it > > isn't possible to gain any rights or usage of a telephone number or > > numberblock by registration of an ENUM domain. > > The anomaly of these blocks exists in the telephone numberplan system. > > It's not something the ENUM registry invented to complicate the > registration > > System. (To be honest, given all the validation misery that comes with it, > > we'd rather loose the whole block concept completely.) > > I would have expected that blocks assigned directly in this way > would lead to a simplification of the validation requirement, > taking advantage of the aggregation. > > Perhaps I'm missing some key detail? The 'ideal world' factor, I'd say. Technically you're right. Operationally there's no easy way to distinguish a single number from a starting number of a number block for any other party than the distributing Telco. So far, the distributing Telco's have shown no real interest to be involved in validating ENUM registrations for Public User ENUM. That means that validation of numbers in ranges that can hold numberblocks involves expensive manual checking of invoices and contracts to make sure that a number really is the starting number for a certain range, or that any other single number is either not contained within a block or contained in a block that has the same numberholder as stated in the validation-request of the single number. Kind regards, Esther Makaay -- ENUM NL T +31 26 352 5500 F +31 26 352 5505 E Esther.Makaay at enum.nl W http://www.enum.nl From Niall.oReilly at ucd.ie Fri Jul 3 12:09:44 2009 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 03 Jul 2009 11:09:44 +0100 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949F02A54@KAEVS1.SIDN.local> References: <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F02A45@KAEVS1.SIDN.local> <4A4DD490.9020409@ucd.ie> <850A39016FA57A4887C0AA3C8085F949F02A54@KAEVS1.SIDN.local> Message-ID: <4A4DD8E8.3040004@ucd.ie> Esther Makaay wrote: > The 'ideal world' factor, I'd say. Technically you're right. Thanks for clarifying, Esther. /Niall From info at streamservice.nl Fri Jul 3 12:34:05 2009 From: info at streamservice.nl (Stream Service) Date: Fri, 03 Jul 2009 12:34:05 +0200 Subject: [#SUL-477848]: Re: [enum-wg] ENUM Adoption - Does a business case matter? Message-ID: Otmar Lendl, Uw ticket is ontvangen en een medewerker zal het ticket bekijken en beantwoorden. Hieronder staan de details van dit ticket. Zorg er a.u.b. voor dat het Ticket ID altijd in het onderwerp van deze email blijft staan. Ticket ID: SUL-477848 Onderwerp:Re: [enum-wg] ENUM Adoption - Does a business case matter? Department: Stream Service (Algemeen) Priority: Low Status: Open U kunt hier klikken om de status van ons antwoord op het Ticket online te bekijken.http://support.streamservice.nl/index.php?_m=tickets&_a=viewticket&ticketid=16954 Wij horen het graag als we u nog ergens anders mee van dienst kunnen zijn, Stream Service (Algemeen) info at streamservice.nl Tel : +31 (0)53-7112711 Fax : +31 (0)53-7112716 Stream Service is een handelsnaam van SinnerG BV From md at bts.sk Fri Jul 3 12:31:12 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Fri, 3 Jul 2009 12:31:12 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <4A4DD490.9020409@ucd.ie> References: <943c86c90907010805q3e18b158ha5b4b7d043287cf3@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F02A45@KAEVS1.SIDN.local> <4A4DD490.9020409@ucd.ie> Message-ID: <20090703103112.GA29878@bts.sk> > I would have expected that blocks assigned directly in this way > would lead to a simplification of the validation requirement, > taking advantage of the aggregation. > > Perhaps I'm missing some key detail? Here in SK the number block is clearly visible both in public phone directory as well as on every invoice, since the record shows less than full number of digits. Our PBX is listed as (+421) 2571041 and this is exactly how it was delegated in the ENUM tree. Normalized number length is 9 digits, so 2 digits are left for extensions. With kind regards, -------------------------------------------------------------------------- ---- ---- ---- Marian ?urkovi? network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 571 041 81 ---- ---- Computer Centre, N?m. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- From lendl at nic.at Fri Jul 3 12:28:32 2009 From: lendl at nic.at (Otmar Lendl) Date: Fri, 03 Jul 2009 12:28:32 +0200 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <943c86c90906291605q58e1e726t51cf2d414bff55db@mail.gmail.com> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A3F983E.4000604@gmx.net> <4A3FA0FE.2040305@gmx.net> <000901c9f362$c89062a0$59b127e0$@us> <4A42AC45.6070407@schiefner.de> <943c86c90906261445m6fddca27jef0c62401e2db156@mail.gmail.com> <4A48E823.1070602@gmx.net> <005401c9f8e2$dcf6f800$96e4e800$@nl> <943c86c90906291605q58e1e726t51cf2d414bff55db@mail.gmail.com> Message-ID: <4A4DDD50.5010309@nic.at> Rui Ribeiro wrote: > Do you have prices. I've found the Austrian case and it goes about > 20cents/month per each ENUM domain/number. The wholesale price in Austria is 10 cents/month these days. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From info at streamservice.nl Fri Jul 3 12:55:47 2009 From: info at streamservice.nl (Stream Service) Date: Fri, 03 Jul 2009 12:55:47 +0200 Subject: [#XMS-873473]: Re: [enum-wg] ENUM Adoption - Does a business case matter? Message-ID: Otmar Lendl, Uw ticket is ontvangen en een medewerker zal het ticket bekijken en beantwoorden. Hieronder staan de details van dit ticket. Zorg er a.u.b. voor dat het Ticket ID altijd in het onderwerp van deze email blijft staan. Ticket ID: XMS-873473 Onderwerp:Re: [enum-wg] ENUM Adoption - Does a business case matter? Department: Stream Service (Algemeen) Priority: Low Status: Open U kunt hier klikken om de status van ons antwoord op het Ticket online te bekijken.http://support.streamservice.nl/index.php?_m=tickets&_a=viewticket&ticketid=16955 Wij horen het graag als we u nog ergens anders mee van dienst kunnen zijn, Stream Service (Algemeen) info at streamservice.nl Tel : +31 (0)53-7112711 Fax : +31 (0)53-7112716 Stream Service is een handelsnaam van SinnerG BV From lendl at nic.at Fri Jul 3 13:12:25 2009 From: lendl at nic.at (Otmar Lendl) Date: Fri, 03 Jul 2009 13:12:25 +0200 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> Message-ID: <4A4DE799.1000904@nic.at> Rui Ribeiro wrote: > Hi All, > > I'm new to the list, so this will be my first post... I'm making a > master thesis on ENUM and its adoption (or non adoption). My > background is 100% technical, so I'm "a believer" that ENUM is like a > swiss knife to handle all kind of addressing problems between E-164 > numbering and the new Internet URI based services. It can solve many > other problems and can, even, be the base/enabler to new services. > > But I wonder if this is the pragmatic view that we should have about > new things. > > What if ENUM is getting "hard" to deploy because it can't provide a > business model to its "stake holders"? This is indeed the problem. I'm a techie myself, but I've learned the hard way that technological superiority is pretty much useless by itself. Unless the business incentives and the marketing align, you will not get your superior idea adopted by the marketplace (or even standardized). Actually, your subject should be "ENUM Adoption - Does anything except the business case matter at all?". So, what chains shackled user-ENUM to its current subsistence? Some comments: * User ENUM is a technology for voice as a product, and not voice as a service. See http://www.shirky.com/writings/zapmail.html * See also the idea behind http://www.phonegnome.com/ More below. * SIP is a mess. Basic calling is bad enough, given the troubles with NATs, Firewalls and other middleboxes, but interoperability for more advanced phone features is terrible. If you link average PBXs, Asterisk installations, ... you will get spurious errors. Sudden one-way audio. Dropped calls on handovers, ... * Price erosion. The current prices for regular telephony are so low that working around the telcos doesn't make as much sense as it used to. * Call pricing these days is by far dominated by termination fees, not geography and distance. So: optimizing the route will give you minimal benefits compared to bypassing the toll-gate at the entrance of the terminating operator. * There is NO incentive for a carrier to accept anonymous SIP calls from the Internet. Quite to the contrary. Termination fees are a significant part of their revenue (not in all countries!). Less hassle with DoS, Spit and legal issues. Opening up SIP ingress point robs carriers their "termination monopoly" with regards to their own customers. Bad idea for them. * There is little incentive for a carrier to do ENUM resolution on outbound calls. Why? All the ENUM marketing says, "make free calls using ENUM", thus the customer won't accept fees on such calls. Bottom line for the carrier: * no enum: charge wholesale price + x %, no technical challenges * enum: charge nothing. Happy debugging SIP with whatever software the other side has mis-configured. All he gets from outbound ENUM is a marketing boost. * What might actually work is when PBX vendors get together and add ENUM to their boxes and certify that the interconnection between these boxes actually _works_. That's a bit like the phonegnome mentioned above. This doesn't quite work with plain user ENUM though, as there is no mechanism there to signal that you only want to talk to certified ENUM-aware PBXs. I've written up some ideas on how you could enhance ENUM / SIP to do that, see http://tools.ietf.org/html/draft-lendl-speermint-federations-03 (+referenced docs). * There certainly will be uses for ENUM in the carrier space, though from what I see I doubt that they will manage to build the single I-ENUM tree necessary to drive the global, optimal, multi-hop VoIP routing we actually need. If you want to read up on what b0rkeness the IETF is currently hatching, have a look at http://tools.ietf.org/wg/drinks/ (Lest that I'm accused of not offering alternative ideas, see http://tools.ietf.org/html/draft-lendl-speermint-background-02 ) /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From Antoin.Verschuren at sidn.nl Mon Jul 6 11:25:31 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Mon, 6 Jul 2009 11:25:31 +0200 Subject: [enum-wg] DNSSEC for 1.3.e164.arpa Message-ID: <850A39016FA57A4887C0AA3C8085F949F02ADD@KAEVS1.SIDN.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, As some of you may have noticed We have signed in our zone 1.3.e164.arpa last week. We are preparing for implementation of DNSSEC in that zone. In the coming months, we will test our administrative procedures. We will do some emergency key rollovers to make sure they work in our production systems the same as they did in our testing environment. Once we are satisfied about the results, we will publish our trust anchor on our website and to our parent RIPE NCC. In the mean time, we don't advise the key in our zone to be treated as a trust anchor in production systems. You are free to experiment with it though. Changes to our policy will be published on our website: http://www.enum.nl/en/dnssec/dnssec-status-for-13e164arpa.html An SSL secured version of that site will be available soon. We will also announce to the RIPE dns and enum wg mailing lists when we consider our trust anchors to be ready for production use. We hope this contribution will help the adoption of DNSSEC to secure the DNS. Regards, Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ - -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFKUcJSXOb5yambhgkRArcXAKCB5QTb4/6z3jJONlQJifGcZhJTpQCgkE3c b8IMVyjdyM4bX1zoKOnEJFg= =Tm1m - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSlHDCzqHrM883AgnAQgTcwf/Sp7GhL+sT8yS4wWDp5SdIULLKyNb36nV 3Lfl6EZ36zk15SpdUPzh3D7BBYHmoIYwdQ5PtpcwZ2I//+2cE+Hl7D0Biixytc7x 4vcrW3qKq/bkkkMo7R2bSJ8QYTIcqPyx5LIP69Ob9wzSIjwdGRZs2pJGMIOP0jSE r4LgGcXW42SuGkOz4cEhWX0Inom9+DdZh8GbSswV99M46NJO5ZnUeIVADnwNuF8W 1jnWbHy1W6EN8rEVjRKJwqhVzYsCaIZEZZQkMaqu4r4oDBXb9QX+hCzLOGMKgC7x Os8MKXPDppLTIaiqTuiPm69WM6yIcKWaDjej3FSxn6z9QcQbj0WFzg== =bEKp -----END PGP SIGNATURE----- From lendl at nic.at Mon Jul 6 11:49:28 2009 From: lendl at nic.at (Otmar Lendl) Date: Mon, 06 Jul 2009 11:49:28 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949F0291C@KAEVS1.SIDN.local> Message-ID: <4A51C8A8.4020803@nic.at> Antoin Verschuren wrote: > 4. Identity management [...] > > The last one is often forgotten, but I predict this will be a big one in > the time to come. It's OAUTH, OPENID, that sort of game. It's everyone > that seeks a way to identify customers, customers need, or customers > preferences to be able to give the customer what he wants the easy way. I've been talking about these ideas to various people over the last years and we didn't come up with a good reason why this "online identity" should be based on your phone number. Pro: * various mobile applications already use the phone number (for m-banking, premium rate services, ...) * Easy to input on almost all user-interfaces Contra: * People want usernames/nicks, not numbers as identifiers. * I would not want to link all my online identities together. * regarding identity providers: everybody wants to be one, and only a few sites allow login using an identity hosted somewhere else. * why use the DNS for this? With delegations down to the end-user? Somehow this sounds like a solution looking for a problem. ----- All this reminds me a bit about .tel and why this might take off. See http://lendl.priv.at/blog/2008/12/04/some-thoughts-on-tel/ for my take on that. Some of the arguments also apply to using ENUM for ID-management. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From tschlabach at gmx.net Tue Jul 7 17:19:34 2009 From: tschlabach at gmx.net (Torsten Schlabach) Date: Tue, 07 Jul 2009 17:19:34 +0200 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <4A4DE799.1000904@nic.at> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> Message-ID: <4A536786.6070407@gmx.net> Hi Otmar! First of all: Thanks for some new aspects your brought to the discussion. I didn't know that ZapMail thing before. I think the VoIP as a product versus VoIP as a service thing pretty much hits it. Just I have to heavily disagree with what Clay Shirky wrote. VoIP as a product (buy a device, connect, talk to people) has never ever worked. Not all all. Any this might be the problem after all. If I could buy a VoIP appliance in the next electronics store which would allow me to start talking to other people who bought an appliance which uses the same protocol and if this appliance would be cheap and required no but a trivial configuration, that would be it. For sure. But reality is that the VoIP operators behave exactly like any traditional telco. VoIP as a service. You have to subscribe (ok, the subscription fee might be 0,00), there is a tariff plan, calls are only free on the same network or on a small number of interconnected networks. What I always wondered is why people do accept that. Would you accept an ISP which delivers email only to accounts on it's own and on selected partner networks and who will print and snail mail or fax if the mail leaves their own network. This is excactly what happens if I am with VoIP operator A and I make a call to VoIP operator B. Unless two two have a peering agreement by chance, the call will go VoIP -> PSTN Gateway -> PSTN Gateway -> VoIP. How stupid is that? Now the question to me is: What the hell do I need a VoIP operator for? I can make a device listen for incoming calls on an IP address on a given port. If we take IPv6, I can have a fixed IP address which will even be entirely independent of my ISP and it will even be mobile. So I could just print my IPv6 address on my business card and possibly announce one or two alternative protocols under which I will accept calls on that address. No operator needed. If I want to call someone, I can make my device open a socket to the other party's IP address and there we go. This would be VoIP as a product. So what's holding us back from just doing that? This will not solve the ENUM adoption problem, but looking at IPv6 based end-to-end telephony, ENUM looks to me like a solution in search of a problem. In case it would happen that ... say as many people as are using Skype today ... would use standard protocol IPv6 based voice over Internet I am sure this would make the telco's move about how to make that cloud reachable from their networks. And there ENUM would be back in the game, mapping a phone number to a protocol:IPv6address record. Remains one yet unsolved problem: Many people use mobile phones today. Where do I get a IPv6 address over a GSM network? On the network level: I could use any other data over 3G / 3.5G flatrate (available in Germany starting at 14,95 / month with no contractual obligations), just most GSM operators *tolerate* VoIP at most while reserving the right to cut it off at any time. And of course, one would need a handset which would be capable. In that case, Android might be a solution. Remains the problem that the latency of 3G networks isn't all that VoIP friendly. Not that it doesn't work at all, but it remains a 2nd best option. I have to come back to my call for the regulator: Why are fixed line operators required to open their last mile up to competitors while GSM operators aren't? Regards, Torsten Otmar Lendl schrieb: > Rui Ribeiro wrote: >> Hi All, >> >> I'm new to the list, so this will be my first post... I'm making a >> master thesis on ENUM and its adoption (or non adoption). My >> background is 100% technical, so I'm "a believer" that ENUM is like a >> swiss knife to handle all kind of addressing problems between E-164 >> numbering and the new Internet URI based services. It can solve many >> other problems and can, even, be the base/enabler to new services. >> >> But I wonder if this is the pragmatic view that we should have about >> new things. >> >> What if ENUM is getting "hard" to deploy because it can't provide a >> business model to its "stake holders"? > > This is indeed the problem. > > I'm a techie myself, but I've learned the hard way that technological > superiority is pretty much useless by itself. Unless the business > incentives and the marketing align, you will not get your superior idea > adopted by the marketplace (or even standardized). > > Actually, your subject should be "ENUM Adoption - Does anything except the > business case matter at all?". > > So, what chains shackled user-ENUM to its current subsistence? > > Some comments: > > * User ENUM is a technology for voice as a product, and not voice as > a service. See http://www.shirky.com/writings/zapmail.html > > * See also the idea behind http://www.phonegnome.com/ > More below. > > * SIP is a mess. Basic calling is bad enough, given the troubles > with NATs, Firewalls and other middleboxes, but interoperability > for more advanced phone features is terrible. > > If you link average PBXs, Asterisk installations, ... you will get > spurious errors. Sudden one-way audio. Dropped calls on handovers, ... > > * Price erosion. The current prices for regular telephony are so low > that working around the telcos doesn't make as much sense as it used to. > > * Call pricing these days is by far dominated by termination fees, not > geography and distance. > > So: optimizing the route will give you minimal benefits compared to > bypassing the toll-gate at the entrance of the terminating operator. > > * There is NO incentive for a carrier to accept anonymous SIP calls from > the Internet. Quite to the contrary. Termination fees are a significant > part of their revenue (not in all countries!). Less hassle with DoS, Spit > and legal issues. > > Opening up SIP ingress point robs carriers their "termination monopoly" > with regards to their own customers. Bad idea for them. > > * There is little incentive for a carrier to do ENUM resolution on outbound > calls. Why? All the ENUM marketing says, "make free calls using ENUM", > thus the customer won't accept fees on such calls. > > Bottom line for the carrier: > * no enum: charge wholesale price + x %, no technical challenges > * enum: charge nothing. Happy debugging SIP with whatever software > the other side has mis-configured. > > All he gets from outbound ENUM is a marketing boost. > > * What might actually work is when PBX vendors get together and add > ENUM to their boxes and certify that the interconnection between these > boxes actually _works_. > > That's a bit like the phonegnome mentioned above. > > This doesn't quite work with plain user ENUM though, as there is > no mechanism there to signal that you only want to talk to certified > ENUM-aware PBXs. > > I've written up some ideas on how you could enhance ENUM / SIP to do > that, see http://tools.ietf.org/html/draft-lendl-speermint-federations-03 > (+referenced docs). > > * There certainly will be uses for ENUM in the carrier space, though > from what I see I doubt that they will manage to build the single > I-ENUM tree necessary to drive the global, optimal, multi-hop > VoIP routing we actually need. > > If you want to read up on what b0rkeness the IETF is currently > hatching, have a look at http://tools.ietf.org/wg/drinks/ > > (Lest that I'm accused of not offering alternative ideas, see > http://tools.ietf.org/html/draft-lendl-speermint-background-02 ) > > /ol From ckl at innovaphone.com Tue Jul 7 18:41:41 2009 From: ckl at innovaphone.com (=?iso-8859-1?Q?Christoph_K=FCnkel?=) Date: Tue, 7 Jul 2009 18:41:41 +0200 Subject: AW: [enum-wg] ENUM Adoption - Does a business case matter? References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> <4A536786.6070407@gmx.net> Message-ID: <0E6CC1D4D38A5742930CE896A653477A038CC9B5@inno-exchange.innovaphone.sifi> Torsten, > Unless two two have a peering agreement by chance, the call will go > VoIP -> PSTN Gateway -> PSTN Gateway -> VoIP. How stupid is that? One simple answer: it works. Anything else currently does not work (at least, from a practical point of view). > If I want to call someone, I can make my device open a socket to the > other party's IP address and there we go. This would be VoIP as a > product. So what's holding us back from just doing that? Again, very simple answer: it doesn't work as well as the traditional solution. > Now the question to me is: What the hell do I need a VoIP operator for? Nobody needs a VoIP operator, except the VoIP operator himself. The only reason why there are VoIP operators is that it allowed companies to enter the "carrier business" that did not have the chance to create an affordable access network (in old telco words) before. To the end customer, voip carriers usually provide less features and worse quality compared to the legacy telco operators. > ENUM looks to me like a solution in search of a problem. ENUM provides access to a system that currently does not work well (public VoIP). Once this system will be fixed so that it works well (and ipv6 is not the most important thing to do to fix it), ENUM provides a solution to a problem people will have then. Until then, I guess there is not much to do for ENUM. Surprisingly enough, MS seems to be pushing heavily towards reliable public VoIP (what they are calling "ocs federation" I believe). They could benefit from ENUM. Regards, Christoph -----Urspr?ngliche Nachricht----- Von: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] Im Auftrag von Torsten Schlabach Gesendet: Dienstag, 7. Juli 2009 17:20 An: Otmar Lendl Cc: Rui Ribeiro; enum-wg at ripe.net Betreff: Re: [enum-wg] ENUM Adoption - Does a business case matter? Hi Otmar! First of all: Thanks for some new aspects your brought to the discussion. I didn't know that ZapMail thing before. I think the VoIP as a product versus VoIP as a service thing pretty much hits it. Just I have to heavily disagree with what Clay Shirky wrote. VoIP as a product (buy a device, connect, talk to people) has never ever worked. Not all all. Any this might be the problem after all. If I could buy a VoIP appliance in the next electronics store which would allow me to start talking to other people who bought an appliance which uses the same protocol and if this appliance would be cheap and required no but a trivial configuration, that would be it. For sure. But reality is that the VoIP operators behave exactly like any traditional telco. VoIP as a service. You have to subscribe (ok, the subscription fee might be 0,00), there is a tariff plan, calls are only free on the same network or on a small number of interconnected networks. What I always wondered is why people do accept that. Would you accept an ISP which delivers email only to accounts on it's own and on selected partner networks and who will print and snail mail or fax if the mail leaves their own network. This is excactly what happens if I am with VoIP operator A and I make a call to VoIP operator B. Now the question to me is: What the hell do I need a VoIP operator for? I can make a device listen for incoming calls on an IP address on a given port. If we take IPv6, I can have a fixed IP address which will even be entirely independent of my ISP and it will even be mobile. So I could just print my IPv6 address on my business card and possibly announce one or two alternative protocols under which I will accept calls on that address. No operator needed. If I want to call someone, I can make my device open a socket to the other party's IP address and there we go. This would be VoIP as a product. So what's holding us back from just doing that? This will not solve the ENUM adoption problem, but looking at IPv6 based end-to-end telephony, ENUM looks to me like a solution in search of a problem. In case it would happen that ... say as many people as are using Skype today ... would use standard protocol IPv6 based voice over Internet I am sure this would make the telco's move about how to make that cloud reachable from their networks. And there ENUM would be back in the game, mapping a phone number to a protocol:IPv6address record. Remains one yet unsolved problem: Many people use mobile phones today. Where do I get a IPv6 address over a GSM network? On the network level: I could use any other data over 3G / 3.5G flatrate (available in Germany starting at 14,95 / month with no contractual obligations), just most GSM operators *tolerate* VoIP at most while reserving the right to cut it off at any time. And of course, one would need a handset which would be capable. In that case, Android might be a solution. Remains the problem that the latency of 3G networks isn't all that VoIP friendly. Not that it doesn't work at all, but it remains a 2nd best option. I have to come back to my call for the regulator: Why are fixed line operators required to open their last mile up to competitors while GSM operators aren't? Regards, Torsten Otmar Lendl schrieb: > Rui Ribeiro wrote: >> Hi All, >> >> I'm new to the list, so this will be my first post... I'm making a >> master thesis on ENUM and its adoption (or non adoption). My >> background is 100% technical, so I'm "a believer" that ENUM is like a >> swiss knife to handle all kind of addressing problems between E-164 >> numbering and the new Internet URI based services. It can solve many >> other problems and can, even, be the base/enabler to new services. >> >> But I wonder if this is the pragmatic view that we should have about >> new things. >> >> What if ENUM is getting "hard" to deploy because it can't provide a >> business model to its "stake holders"? > > This is indeed the problem. > > I'm a techie myself, but I've learned the hard way that technological > superiority is pretty much useless by itself. Unless the business > incentives and the marketing align, you will not get your superior idea > adopted by the marketplace (or even standardized). > > Actually, your subject should be "ENUM Adoption - Does anything except the > business case matter at all?". > > So, what chains shackled user-ENUM to its current subsistence? > > Some comments: > > * User ENUM is a technology for voice as a product, and not voice as > a service. See http://www.shirky.com/writings/zapmail.html > > * See also the idea behind http://www.phonegnome.com/ > More below. > > * SIP is a mess. Basic calling is bad enough, given the troubles > with NATs, Firewalls and other middleboxes, but interoperability > for more advanced phone features is terrible. > > If you link average PBXs, Asterisk installations, ... you will get > spurious errors. Sudden one-way audio. Dropped calls on handovers, ... > > * Price erosion. The current prices for regular telephony are so low > that working around the telcos doesn't make as much sense as it used to. > > * Call pricing these days is by far dominated by termination fees, not > geography and distance. > > So: optimizing the route will give you minimal benefits compared to > bypassing the toll-gate at the entrance of the terminating operator. > > * There is NO incentive for a carrier to accept anonymous SIP calls from > the Internet. Quite to the contrary. Termination fees are a significant > part of their revenue (not in all countries!). Less hassle with DoS, Spit > and legal issues. > > Opening up SIP ingress point robs carriers their "termination monopoly" > with regards to their own customers. Bad idea for them. > > * There is little incentive for a carrier to do ENUM resolution on outbound > calls. Why? All the ENUM marketing says, "make free calls using ENUM", > thus the customer won't accept fees on such calls. > > Bottom line for the carrier: > * no enum: charge wholesale price + x %, no technical challenges > * enum: charge nothing. Happy debugging SIP with whatever software > the other side has mis-configured. > > All he gets from outbound ENUM is a marketing boost. > > * What might actually work is when PBX vendors get together and add > ENUM to their boxes and certify that the interconnection between these > boxes actually _works_. > > That's a bit like the phonegnome mentioned above. > > This doesn't quite work with plain user ENUM though, as there is > no mechanism there to signal that you only want to talk to certified > ENUM-aware PBXs. > > I've written up some ideas on how you could enhance ENUM / SIP to do > that, see http://tools.ietf.org/html/draft-lendl-speermint-federations-03 > (+referenced docs). > > * There certainly will be uses for ENUM in the carrier space, though > from what I see I doubt that they will manage to build the single > I-ENUM tree necessary to drive the global, optimal, multi-hop > VoIP routing we actually need. > > If you want to read up on what b0rkeness the IETF is currently > hatching, have a look at http://tools.ietf.org/wg/drinks/ > > (Lest that I'm accused of not offering alternative ideas, see > http://tools.ietf.org/html/draft-lendl-speermint-background-02 ) > > /ol From racribeiro at gmail.com Tue Jul 7 19:47:15 2009 From: racribeiro at gmail.com (Rui Ribeiro) Date: Tue, 7 Jul 2009 18:47:15 +0100 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <0E6CC1D4D38A5742930CE896A653477A038CC9B5@inno-exchange.innovaphone.sifi> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> <4A536786.6070407@gmx.net> <0E6CC1D4D38A5742930CE896A653477A038CC9B5@inno-exchange.innovaphone.sifi> Message-ID: <943c86c90907071047r189536f3iff0e8460fb2f76de@mail.gmail.com> Hi all, Thanks for your unvaluable feedback! >> Unless two two have a peering agreement by chance, the call will go >> VoIP -> PSTN Gateway -> PSTN Gateway -> VoIP. How stupid is that? > One simple answer: it works. Anything else currently does not work (at least, from a practical point of view). It is stupid, but needed... many operators (even VoIP) don't allow to go outside their own "SIP Island". What could be the drive to "open" their island to "overseas" conections? > Surprisingly enough, MS seems to be pushing heavily towards > reliable public VoIP (what they are calling "ocs federation" I > believe). ?They could benefit from ENUM. The "ocs federation" will not support ENUM, i'm sure. OCS uses some kind of SIP, but not really interoperable with "off the shelf, white brand, SIP systems". In fact you have to have a gateway to SIP... from my testing, a few months ago, it doesn't allow to make calls using URI's outside the federation and the numbers are always routed through the gateways (SIP, ISDN or others). It seems like a way to make "archipelagos", than to provide a global public VoIP system. Rui Ribeiro racribeiro at gmail.com From info at streamservice.nl Tue Jul 7 21:36:57 2009 From: info at streamservice.nl (Stream Service) Date: Tue, 7 Jul 2009 21:36:57 +0200 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <943c86c90907071047r189536f3iff0e8460fb2f76de@mail.gmail.com> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> <4A536786.6070407@gmx.net> <0E6CC1D4D38A5742930CE896A653477A038CC9B5@inno-exchange.innovaphone.sifi> <943c86c90907071047r189536f3iff0e8460fb2f76de@mail.gmail.com> Message-ID: <003101c9ff3a$4a485450$ded8fcf0$@nl> Hello, We would be happy to create SIP connections to other VoIP operators. But it totally depends on the interconnection costs (if there would be no fee to call to SIP accounts on their server, they could call for free to SIP accounts on our platform ofcourse). That is why we are also looking for ENUM, but currently it is not useful for us (probably it is in the future). With kind regards, Mark Scholten Stream Service SinnerG BV PS.: don't reply with us in the to or cc field if you also send it to the enum-wg (if so remove our email address please). Feel free to contact us directly. -----Original Message----- From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf Of Rui Ribeiro Sent: dinsdag 7 juli 2009 19:47 To: Christoph K?nkel Cc: Torsten Schlabach; Otmar Lendl; enum-wg at ripe.net Subject: Re: [enum-wg] ENUM Adoption - Does a business case matter? Hi all, Thanks for your unvaluable feedback! >> Unless two two have a peering agreement by chance, the call will go >> VoIP -> PSTN Gateway -> PSTN Gateway -> VoIP. How stupid is that? > One simple answer: it works. Anything else currently does not work (at least, from a practical point of view). It is stupid, but needed... many operators (even VoIP) don't allow to go outside their own "SIP Island". What could be the drive to "open" their island to "overseas" conections? > Surprisingly enough, MS seems to be pushing heavily towards > reliable public VoIP (what they are calling "ocs federation" I > believe). ?They could benefit from ENUM. The "ocs federation" will not support ENUM, i'm sure. OCS uses some kind of SIP, but not really interoperable with "off the shelf, white brand, SIP systems". In fact you have to have a gateway to SIP... from my testing, a few months ago, it doesn't allow to make calls using URI's outside the federation and the numbers are always routed through the gateways (SIP, ISDN or others). It seems like a way to make "archipelagos", than to provide a global public VoIP system. Rui Ribeiro racribeiro at gmail.com From racribeiro at gmail.com Tue Jul 7 23:25:04 2009 From: racribeiro at gmail.com (Rui Ribeiro) Date: Tue, 7 Jul 2009 22:25:04 +0100 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <003101c9ff3a$4a485450$ded8fcf0$@nl> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> <4A536786.6070407@gmx.net> <0E6CC1D4D38A5742930CE896A653477A038CC9B5@inno-exchange.innovaphone.sifi> <943c86c90907071047r189536f3iff0e8460fb2f76de@mail.gmail.com> <003101c9ff3a$4a485450$ded8fcf0$@nl> Message-ID: <943c86c90907071425w2f1a3c5ei53b006f1b14f7792@mail.gmail.com> Hi Mark, Let's say that I'm a user (not a company, even less an operator). I have a SIP phone that supports ENUM direcly (it queries the golden tree, understand the registers flags, queries the DNS based on the URI, and makes the call). ENUM redirects to a user that is registred on your server. Would you accept the calls? (note... there are no costs neither a internconection contract). What if it was the other way around? Would you redirect your calls to a URI with whom you don't have any relashionship? Would you even trie to deliver the call, and redirect it through PSTN if failed? > We would be happy to create SIP connections to other VoIP operators. But it > totally depends on the interconnection costs (if there would be no fee to > call to SIP accounts on their server, they could call for free to SIP > accounts on our platform ofcourse). Who applies to "voip operaton" on your view? Could a non profit organization with thousands of numbers? [as NREN, Universitie, Hospital network, ...] Could it be a profit organization? (bank, insurance company, ...) Or only a "operator" fully registred. What is your view on initiatives like e164.org and nrenum.net? Do/Would you deliver calls to destinations pointed by these two trees? Rui Ribeiro racribeiro at gmail.com From info at streamservice.nl Wed Jul 8 09:22:33 2009 From: info at streamservice.nl (Stream Service) Date: Wed, 8 Jul 2009 09:22:33 +0200 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <943c86c90907071425w2f1a3c5ei53b006f1b14f7792@mail.gmail.com> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> <4A536786.6070407@gmx.net> <0E6CC1D4D38A5742930CE896A653477A038CC9B5@inno-exchange.innovaphone.sifi> <943c86c90907071047r189536f3iff0e8460fb2f76de@mail.gmail.com> <003101c9ff3a$4a485450$ded8fcf0$@nl> <943c86c90907071425w2f1a3c5ei53b006f1b14f7792@mail.gmail.com> Message-ID: <005c01c9ff9c$dcd7a1b0$9686e510$@nl> Hello Rui, Everyone (commercial/non-commercial, organisation/private person) who operates a correctly configured SIP server is for this an operator if you ask me. We are working in our test environment with nrenum.net and enum. After this first 2 work as we want we will also add e164.org. As long as they mention correct information to call back (read correct phone number) we will be happy to accept calls from anyone. For outgoing calls we are testing it and once this goes as planned we will also use nrenum/enum/e164.org for this. As long as the number is within the earlier mentioned trees we would be happy to connect directly (where possible) or accept connections. For operators we would also be happy to have some kind of "peering" arrangement, and this could go as far as redirecting calls from them that we get from other peers (if both want that). With kind regards, Mark Scholten Stream Service SinnerG BV PS.: don't reply with us in the to or cc field if you also send it to the enum-wg (if so remove our email address please). Feel free to contact us directly. -----Original Message----- From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf Of Rui Ribeiro Sent: dinsdag 7 juli 2009 23:25 To: enum-wg at ripe.net Subject: Re: [enum-wg] ENUM Adoption - Does a business case matter? Hi Mark, Let's say that I'm a user (not a company, even less an operator). I have a SIP phone that supports ENUM direcly (it queries the golden tree, understand the registers flags, queries the DNS based on the URI, and makes the call). ENUM redirects to a user that is registred on your server. Would you accept the calls? (note... there are no costs neither a internconection contract). What if it was the other way around? Would you redirect your calls to a URI with whom you don't have any relashionship? Would you even trie to deliver the call, and redirect it through PSTN if failed? > We would be happy to create SIP connections to other VoIP operators. But it > totally depends on the interconnection costs (if there would be no fee to > call to SIP accounts on their server, they could call for free to SIP > accounts on our platform ofcourse). Who applies to "voip operaton" on your view? Could a non profit organization with thousands of numbers? [as NREN, Universitie, Hospital network, ...] Could it be a profit organization? (bank, insurance company, ...) Or only a "operator" fully registred. What is your view on initiatives like e164.org and nrenum.net? Do/Would you deliver calls to destinations pointed by these two trees? Rui Ribeiro racribeiro at gmail.com From lendl at nic.at Wed Jul 8 10:27:05 2009 From: lendl at nic.at (Otmar Lendl) Date: Wed, 08 Jul 2009 10:27:05 +0200 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <4A536786.6070407@gmx.net> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> <4A536786.6070407@gmx.net> Message-ID: <4A545859.6000708@nic.at> Hi, Torsten Schlabach wrote: > Hi Otmar! > > First of all: Thanks for some new aspects your brought to the > discussion. I didn't know that ZapMail thing before. > > I think the VoIP as a product versus VoIP as a service thing pretty much > hits it. Just I have to heavily disagree with what Clay Shirky wrote. > > VoIP as a product (buy a device, connect, talk to people) has never ever > worked. Not all all. Any this might be the problem after all. Correct. This is in contrast to email, where you just * get internet connectivity * buy / get a mailserver software (commercial or open source) * get a domain and set the MX records and you're a full participant in the worldwide email ecosystem. > If I could buy a VoIP appliance in the next electronics store which > would allow me to start talking to other people who bought an appliance > which uses the same protocol and if this appliance would be cheap and > required no but a trivial configuration, that would be it. For sure. An appliance alone would be not enough, as you still need the domain for plain SIP and/or the enum delegation for E.164 based calling. But still, why doesn't this happen the same way as it does for email? In my opinion, the free SIP community never managed to get over the Metcalfe's-law bump in the adoption curve as compared to the huge Metcalfe-worth of the existing PSTN. Any phone that can call the billions of existing PSTN phones is worth so much more than any VoIP device that can only reach others using the same technology. It isn't worth deploying an isolated, new telephony network. (Even the IM-based phone networks are IM networks foremost and talking is only a secondary usage. IMHO.) What is another difference to email? * Ad-hoc, settlement-free interconnection. There is no need to sign contracts to transmit email and thus no money passes hands. That's not the way the PSTN operates and as I explained before, no sane PSTN operator will want to be the first to change it. > But reality is that the VoIP operators behave exactly like any > traditional telco. VoIP as a service. Because you need them as a gateway to the PSTN. You don't have the contracts to terminate calls directly to BT, FT, ATT, DT, Sprint, ... so you have to buy a this service from someone. My private box can send email to all these big operators. My SIP proxy cannot talk to their networks. That's the difference. Free SIP service wasn't the problem. Just as there is GMX, gmail, Yahoo, hotmail & other which give you a free email address, there were services that gave you a free SIP address. (iptel.org, FreeWorldDialup, ...) > You have to subscribe (ok, the > subscription fee might be 0,00), there is a tariff plan, calls are only > free on the same network or on a small number of interconnected networks. > > What I always wondered is why people do accept that. As a single person, they have no choice. > Would you accept an ISP which delivers email only to accounts on it's > own and on selected partner networks and who will print and snail mail > or fax if the mail leaves their own network. This is excactly what > happens if I am with VoIP operator A and I make a call to VoIP operator > B. Unless two two have a peering agreement by chance, the call will go > VoIP -> PSTN Gateway -> PSTN Gateway -> VoIP. How stupid is that? It's not stupid. It's just a different economic stable state. The forces who protect the status quo are stronger than the forces who want change. Both interconnection schemes (pstn-type settlement and email-like ad-hoc settlement-free) are stable states. Any single operator cannot change the game. ---- Side-remark: it's instructive to look a the satellite pay-tv markets all over Europe: There are some countries where pay-TV emerged as the dominant solution (France, UK) and then there is Germany, where free, ad-supported TV basically won the game. Any new entrant into that market has to go along with the dominant model. The typical German viewer will not sign a contract, pay money, get the decryption equipment just for the privilege of watching just one more channel. For a French, the infrastructure and habit is there and people probably won't tolerate the ads. Two stable states. ---- > > Now the question to me is: What the hell do I need a VoIP operator for? > > I can make a device listen for incoming calls on an IP address on a > given port. If we take IPv6, I can have a fixed IP address which will > even be entirely independent of my ISP and it will even be mobile. Sorry, no. ipv6 has nothing to do with getting everybody a static ip-address. Quite the contrary, ipv6 was designed to make switching ip-addresses when changing location / ISP / ... easier than it is for v4. What you really want is a domain name which points to your current ip address. ipv6 allows you to get rid of NAT. ---- > In case it would happen that ... say as many people as are using Skype > today ... would use standard protocol IPv6 based voice over Internet I > am sure this would make the telco's move about how to make that cloud > reachable from their networks. And there ENUM would be back in the game, > mapping a phone number to a protocol:IPv6address record. Not at all. The current setup where the voip-users pay money to some voip-operator which then hands termination-fees to the telcos suits the telcos just fine. What advantage would they get if they would allow direct calls towards them from individual, anonymous voip-users? /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From yone at jprs.co.jp Thu Jul 9 07:14:48 2009 From: yone at jprs.co.jp (Yoshiro YONEYA) Date: Thu, 9 Jul 2009 14:14:48 +0900 Subject: [enum-wg] ENUM for SMS? Message-ID: <20090709141448.07e6e1ac.yone@jprs.co.jp> Dear ENUM WG members, In RFC 4355, enumservice for SMS is defined. Is there any cases that use ENUM for SMS routing in commercial service? If you know any information, please let me know or give me pointer(s) to the information. Regards, -- Yoshiro YONEYA From richard at shockey.us Thu Jul 9 14:19:03 2009 From: richard at shockey.us (Richard Shockey) Date: Thu, 9 Jul 2009 08:19:03 -0400 Subject: [enum-wg] ENUM for SMS? In-Reply-To: <20090709141448.07e6e1ac.yone@jprs.co.jp> References: <20090709141448.07e6e1ac.yone@jprs.co.jp> Message-ID: <00e701ca008f$736877b0$5a396710$@us> Yes .. but I don't have any pointers these are all private services. ENUM is now being used extensively in North America for both SMS and more specifically for MMS routing. This service is offered by at least three companies. NeuStar, Telcordia and TNS (Transaction Network Solutions) of Reston VA which recently acquired the telecom signaling assets of Verisign. Depending on the requirements of the customer either a URI for a MMSC or SMSC is returned or a SPID that is used to create a one to one peering arrangements (federation). In any event the business case is SS7/TCAP avoidance. The most popular application for ENUM in North America is Local Number Portability queries. The cost savings to carriers that do not have their own SS7 networks are considerable. Actually all the US mobile operators are routing MMS via ENUM queries including ATT and VZ there is a similar service available to Canadian Operators. The query can be to a database in the cloud over a secure connection or a full subscription to the routing databases can be delivered in-network to a caching ENUM server. > -----Original Message----- > From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf > Of Yoshiro YONEYA > Sent: Thursday, July 09, 2009 1:15 AM > To: enum-wg at ripe.net > Subject: [enum-wg] ENUM for SMS? > > Dear ENUM WG members, > > In RFC 4355, enumservice for SMS is defined. Is there any cases that > use ENUM for SMS routing in commercial service? If you know any > information, > please let me know or give me pointer(s) to the information. > > Regards, > > -- > Yoshiro YONEYA From tschlabach at gmx.net Thu Jul 9 14:31:43 2009 From: tschlabach at gmx.net (Torsten Schlabach) Date: Thu, 09 Jul 2009 14:31:43 +0200 Subject: [enum-wg] ENUM for SMS? In-Reply-To: <00e701ca008f$736877b0$5a396710$@us> References: <20090709141448.07e6e1ac.yone@jprs.co.jp> <00e701ca008f$736877b0$5a396710$@us> Message-ID: <4A55E32F.8040603@gmx.net> Hi! > Yes .. but I don't have any pointers these are all private services. You mean, these are private ENUM trees, not the golden tree being queried? Regards, Torsten Richard Shockey schrieb: > Yes .. but I don't have any pointers these are all private services. > > ENUM is now being used extensively in North America for both SMS and more > specifically for MMS routing. This service is offered by at least three > companies. NeuStar, Telcordia and TNS (Transaction Network Solutions) of > Reston VA which recently acquired the telecom signaling assets of Verisign. > > Depending on the requirements of the customer either a URI for a MMSC or > SMSC is returned or a SPID that is used to create a one to one peering > arrangements (federation). In any event the business case is SS7/TCAP > avoidance. The most popular application for ENUM in North America is Local > Number Portability queries. The cost savings to carriers that do not have > their own SS7 networks are considerable. > > Actually all the US mobile operators are routing MMS via ENUM queries > including ATT and VZ there is a similar service available to Canadian > Operators. > > The query can be to a database in the cloud over a secure connection or a > full subscription to the routing databases can be delivered in-network to a > caching ENUM server. > >> -----Original Message----- >> From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf >> Of Yoshiro YONEYA >> Sent: Thursday, July 09, 2009 1:15 AM >> To: enum-wg at ripe.net >> Subject: [enum-wg] ENUM for SMS? >> >> Dear ENUM WG members, >> >> In RFC 4355, enumservice for SMS is defined. Is there any cases that >> use ENUM for SMS routing in commercial service? If you know any >> information, >> please let me know or give me pointer(s) to the information. >> >> Regards, >> >> -- >> Yoshiro YONEYA > From richard at shockey.us Thu Jul 9 15:15:04 2009 From: richard at shockey.us (Richard Shockey) Date: Thu, 9 Jul 2009 09:15:04 -0400 Subject: [enum-wg] ENUM for SMS? In-Reply-To: <4A55E32F.8040603@gmx.net> References: <20090709141448.07e6e1ac.yone@jprs.co.jp> <00e701ca008f$736877b0$5a396710$@us> <4A55E32F.8040603@gmx.net> Message-ID: <010c01ca0097$469a75f0$d3cf61d0$@us> Right .. totally closed carrier only. Its all about SS7 avoidance/destruction. The use of carrier (private) ENUM data queries interconnection for voice and other realtime communications is coming but there are some technical issues and CAPEX problems among the carriers that are inhibiting deployment. It's a substutiion play for Global Title Translation in part. SS7 cannot handle new IP services .. DUH! The GSM association has been looking into this for some time as the signaling infrastructure for the IPX and now there are several international landline operators that are looking at private ENUM architectures as well lead by FT/Orange. Of course there are lots of private companies deploying this as well like Xconnect in the UK. The problem has been getting some of the suppliers to properly support 3761, though that is very very quickly changing. IMHO this is going to get even bigger as the EC is looking to mandate full database Number Portability across Europe during the next term of the Commission. Vivian Reading has sent out huge noises on this recently. ENUM technology is perfect for this in carrier networks. I've heard rumors that even in Japan there is increasing interest in this. Onward Routing for LNP in Japan is driving NTT crazy as their all IP infrastructure is progressing and the Japanese LNP solution for mobile is not that great either. http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/09/219 > -----Original Message----- > From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf > Of Torsten Schlabach > Sent: Thursday, July 09, 2009 8:32 AM > To: Richard Shockey > Cc: 'Yoshiro YONEYA'; enum-wg at ripe.net > Subject: Re: [enum-wg] ENUM for SMS? > > Hi! > > > Yes .. but I don't have any pointers these are all private services. > > You mean, these are private ENUM trees, not the golden tree being > queried? > > Regards, > Torsten > > Richard Shockey schrieb: > > Yes .. but I don't have any pointers these are all private services. > > > > ENUM is now being used extensively in North America for both SMS and > more > > specifically for MMS routing. This service is offered by at least > three > > companies. NeuStar, Telcordia and TNS (Transaction Network > Solutions) of > > Reston VA which recently acquired the telecom signaling assets of > Verisign. > > > > Depending on the requirements of the customer either a URI for a > MMSC or > > SMSC is returned or a SPID that is used to create a one to one > peering > > arrangements (federation). In any event the business case is > SS7/TCAP > > avoidance. The most popular application for ENUM in North America is > Local > > Number Portability queries. The cost savings to carriers that do not > have > > their own SS7 networks are considerable. > > > > Actually all the US mobile operators are routing MMS via ENUM > queries > > including ATT and VZ there is a similar service available to > Canadian > > Operators. > > > > The query can be to a database in the cloud over a secure connection > or a > > full subscription to the routing databases can be delivered in- > network to a > > caching ENUM server. > > > >> -----Original Message----- > >> From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On > Behalf > >> Of Yoshiro YONEYA > >> Sent: Thursday, July 09, 2009 1:15 AM > >> To: enum-wg at ripe.net > >> Subject: [enum-wg] ENUM for SMS? > >> > >> Dear ENUM WG members, > >> > >> In RFC 4355, enumservice for SMS is defined. Is there any cases > that > >> use ENUM for SMS routing in commercial service? If you know any > >> information, > >> please let me know or give me pointer(s) to the information. > >> > >> Regards, > >> > >> -- > >> Yoshiro YONEYA > > From tschlabach at gmx.net Thu Jul 9 16:41:00 2009 From: tschlabach at gmx.net (Torsten Schlabach) Date: Thu, 09 Jul 2009 16:41:00 +0200 Subject: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <4A4DE799.1000904@nic.at> References: <943c86c90906191024t23921e68sebec79c10252b1d4@mail.gmail.com> <4A4DE799.1000904@nic.at> Message-ID: <4A56017C.5090007@gmx.net> Hi Otmar! Thank you very much for your input and sorry for my late reply. I had to take the time to properly read the material you provided. > * User ENUM is a technology for voice as a product, and not voice as > a service. See http://www.shirky.com/writings/zapmail.html This will provide some terminology. So "X as a product" means: Buy the device and use it without any ongoing relevant charges. > * SIP is a mess. Many people think that. (Including me.) I wonder on what H.323 died, though. IMO it has been around before and it's so straight-forward, isn't it. I mean, it's entirely incompatible with NAT, but in an IPv6 world, maybe H.323 would be the answer. > * Price erosion. The current prices for regular telephony are so low > that working around the telcos doesn't make as much sense as it used > to. Not as much but still some; especially in international contexts and when it comes to GSM calls. Note that some countries virtually have no fixed networks at all. > So: optimizing the route will give you minimal benefits compared to > bypassing the toll-gate at the entrance of the terminating operator. True. But at the same time, more and more customer terminals (I am speaking of the fixed network again now) are IP anyway. The grassroots way of dealing with this would possibly to teach people who they can make their terminals reachable on the IP level, thus bypassing the termination. In a lot of GSM networks, the termination prices are still prohibitive. > * There is little incentive for a carrier to do ENUM resolution on > outbound calls. Why? I think many customers would still accept to pay the price of an on-net call to reach an ENUM target. Which would be fair, because the effort a carrier has for delivering a call to an ENUM target is even less than an on-net call. Potential incentives include: - Customer pressure - Regulatory pressure but I think this has been discussed enough. When it comes to the latter one (regulation) at least in Germany we have a new political party which has the potential to understand this subject and bring it up. Let's see what happens there. > I've written up some ideas on how you could enhance ENUM / SIP to do > that, see http://tools.ietf.org/html/draft-lendl-speermint-federations-03 > (+referenced docs). Brilliant and to the point. > (Lest that I'm accused of not offering alternative ideas, see > http://tools.ietf.org/html/draft-lendl-speermint-background-02 ) What can we do to put this ideas into practice? I would be willing to help. Anyone else? To get back to the technical level, I think there is a difference between inbound and outbound calls. Let's put a NAT and firewalls asides and assume a publicly routed IP address would be the norm. Let's assume one would want to market a "Voice as a product" gizmo. Its physical appearance might look like this: http://www.snom.com/en/produkte/snom-m3-voip-phone/ or like this http://www.cisco.com/en/US/products/hw/phones/ps379/ It would possibly just have a different firmware image than those they get shipped with today. (Ever tried to configure an SPA-921 for example???) For such a device to be able to make an outbound call, there would be no need to register anywhere. It could just query e164.arpa to find the target, then init the call. Of course that would limit you to making IP calls, but let's assume I would be willing to live with that. The other way round, I would have to put up something into the ENUM tree to make other users reach me on such a device. So why not h323:mystaticipv6 address. Period. That would make a perfect customer owned network. No frills. 1-step configuration with 2-3 fields to fill in. No operator needed. No fees. Just works. Anyone interesting to help building this? Regards, Torsten Otmar Lendl schrieb: > Rui Ribeiro wrote: >> Hi All, >> >> I'm new to the list, so this will be my first post... I'm making a >> master thesis on ENUM and its adoption (or non adoption). My >> background is 100% technical, so I'm "a believer" that ENUM is like a >> swiss knife to handle all kind of addressing problems between E-164 >> numbering and the new Internet URI based services. It can solve many >> other problems and can, even, be the base/enabler to new services. >> >> But I wonder if this is the pragmatic view that we should have about >> new things. >> >> What if ENUM is getting "hard" to deploy because it can't provide a >> business model to its "stake holders"? > > This is indeed the problem. > > I'm a techie myself, but I've learned the hard way that technological > superiority is pretty much useless by itself. Unless the business > incentives and the marketing align, you will not get your superior idea > adopted by the marketplace (or even standardized). > > Actually, your subject should be "ENUM Adoption - Does anything except the > business case matter at all?". > > So, what chains shackled user-ENUM to its current subsistence? > > Some comments: > > * User ENUM is a technology for voice as a product, and not voice as > a service. See http://www.shirky.com/writings/zapmail.html > > * See also the idea behind http://www.phonegnome.com/ > More below. > > * SIP is a mess. Basic calling is bad enough, given the troubles > with NATs, Firewalls and other middleboxes, but interoperability > for more advanced phone features is terrible. > > If you link average PBXs, Asterisk installations, ... you will get > spurious errors. Sudden one-way audio. Dropped calls on handovers, ... > > * Price erosion. The current prices for regular telephony are so low > that working around the telcos doesn't make as much sense as it used to. > > * Call pricing these days is by far dominated by termination fees, not > geography and distance. > > So: optimizing the route will give you minimal benefits compared to > bypassing the toll-gate at the entrance of the terminating operator. > > * There is NO incentive for a carrier to accept anonymous SIP calls from > the Internet. Quite to the contrary. Termination fees are a significant > part of their revenue (not in all countries!). Less hassle with DoS, Spit > and legal issues. > > Opening up SIP ingress point robs carriers their "termination monopoly" > with regards to their own customers. Bad idea for them. > > * There is little incentive for a carrier to do ENUM resolution on outbound > calls. Why? All the ENUM marketing says, "make free calls using ENUM", > thus the customer won't accept fees on such calls. > > Bottom line for the carrier: > * no enum: charge wholesale price + x %, no technical challenges > * enum: charge nothing. Happy debugging SIP with whatever software > the other side has mis-configured. > > All he gets from outbound ENUM is a marketing boost. > > * What might actually work is when PBX vendors get together and add > ENUM to their boxes and certify that the interconnection between these > boxes actually _works_. > > That's a bit like the phonegnome mentioned above. > > This doesn't quite work with plain user ENUM though, as there is > no mechanism there to signal that you only want to talk to certified > ENUM-aware PBXs. > > I've written up some ideas on how you could enhance ENUM / SIP to do > that, see http://tools.ietf.org/html/draft-lendl-speermint-federations-03 > (+referenced docs). > > * There certainly will be uses for ENUM in the carrier space, though > from what I see I doubt that they will manage to build the single > I-ENUM tree necessary to drive the global, optimal, multi-hop > VoIP routing we actually need. > > If you want to read up on what b0rkeness the IETF is currently > hatching, have a look at http://tools.ietf.org/wg/drinks/ > > (Lest that I'm accused of not offering alternative ideas, see > http://tools.ietf.org/html/draft-lendl-speermint-background-02 ) > > /ol From yone at jprs.co.jp Thu Jul 9 16:54:34 2009 From: yone at jprs.co.jp (Yoshiro YONEYA) Date: Thu, 9 Jul 2009 23:54:34 +0900 Subject: [enum-wg] ENUM for SMS? In-Reply-To: <00e701ca008f$736877b0$5a396710$@us> References: <20090709141448.07e6e1ac.yone@jprs.co.jp> <00e701ca008f$736877b0$5a396710$@us> Message-ID: <20090709235434.8fc3647f.yone@jprs.co.jp> Dear Richard, Thank you for your information! I think US case shows one of very possible ENUM deployment scenario. I hope such precedent case will make Japanese situation move forward :-) Regards, -- Yoshiro YONEYA On Thu, 9 Jul 2009 08:19:03 -0400 "Richard Shockey" wrote: > Yes .. but I don't have any pointers these are all private services. > > ENUM is now being used extensively in North America for both SMS and more > specifically for MMS routing. This service is offered by at least three > companies. NeuStar, Telcordia and TNS (Transaction Network Solutions) of > Reston VA which recently acquired the telecom signaling assets of Verisign. > > Depending on the requirements of the customer either a URI for a MMSC or > SMSC is returned or a SPID that is used to create a one to one peering > arrangements (federation). In any event the business case is SS7/TCAP > avoidance. The most popular application for ENUM in North America is Local > Number Portability queries. The cost savings to carriers that do not have > their own SS7 networks are considerable. > > Actually all the US mobile operators are routing MMS via ENUM queries > including ATT and VZ there is a similar service available to Canadian > Operators. > > The query can be to a database in the cloud over a secure connection or a > full subscription to the routing databases can be delivered in-network to a > caching ENUM server. > > > -----Original Message----- > > From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf > > Of Yoshiro YONEYA > > Sent: Thursday, July 09, 2009 1:15 AM > > To: enum-wg at ripe.net > > Subject: [enum-wg] ENUM for SMS? > > > > Dear ENUM WG members, > > > > In RFC 4355, enumservice for SMS is defined. Is there any cases that > > use ENUM for SMS routing in commercial service? If you know any > > information, > > please let me know or give me pointer(s) to the information. > > > > Regards, > > > > -- > > Yoshiro YONEYA > > > From enumvoipsip.cs at schiefner.de Sat Jul 18 18:35:52 2009 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Sat, 18 Jul 2009 18:35:52 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <81A5322E-438C-4D42-8330-05C75D52A43B@firsthand.net> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <943c86c90906300813v1e586c6ak15b2e26995a4db08@mail.gmail.com> <81A5322E-438C-4D42-8330-05C75D52A43B@firsthand.net> Message-ID: <4A61F9E8.8040408@schiefner.de> Christian, Christian de Larrinaga wrote: > ENUM is neither a product nor a service. ENUM is a protocol. > > [...] > > Trying to link ENUM to any particular financial model is counter > productive. Each market participant can decide for themselves how or why > they might leverage ENUM. But they can only do this if it is implemented. Indeed. As you said: ENUM is a protocol. But no settlement protcol, for sure. > So the Regulator should allocate all numbers with ENUM. Then the > Regulator will underpin universal service and seed both critical mass > and low per unit cost. Coudl you please elaborate a bit here? Do you call for regulators to make ENUM mandatory? Thanks and all the best: Carsten From enumvoipsip.cs at schiefner.de Sat Jul 18 18:48:29 2009 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Sat, 18 Jul 2009 18:48:29 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <82prcl69n8.fsf@mid.bfk.de> <943c86c90906300906v47c43f2al49408d550ccd114f@mail.gmail.com> Message-ID: <4A61FCDD.7040309@schiefner.de> Rui, that seems to sum it up for me. But at the end of the day any registrar needs to assess what kind of community they serves: DIY geeks? "Please, no bother at all" customers? If ten years ago, all that every and every service provider has told all their customers would have been: "You have connectivity, we registered your domain for you, here is some HD space on our server: take it, play with it and be happy!", I am 100% sure that the industry would look quite different - if it could be called an idustry at all. Back then as well as today assembling various components to bundles that look nice and attractive to your kind of customer (see above) is key for a successful registrar's offering. Unfortunately such an offering could not be seen too often so far, IMHO. Best, Carsten Rui Ribeiro wrote: > 2009/6/30 Florian Weimer : >> * Antoin Verschuren: >> >>> And for lager numberblocks there are different prices. One >>> delegation of 10.000 numbers will cost 2500,-, discounts negotiable, >>> so effectively this is 0,25 Euro per number. >> Does this mean that subscribers have to pay per extension/subdomain >> and are not free to create all the subdomains they want? > > That is a great question. What kind of services are provided by registrars? > > - just number delegation towards the client DNS server? (the user can > make any update, at any time, of any information. User must be savy) > - DNS hosting for any kind of registers? (the user accesses through a > web interface to it's own profile, and ads any kind of information in > type, and in number. Less savy, but has to have some knowledge) > - DNS hosting for predefined registers? (the user acesses through a > web interface to it's own profile, and selects from predefined > registers) > - DNS hosting for limited predefined registers? (as above, but with a > limited number of registers. How many?) > - DNS hosting limited for SIP? (as above, but only allowing SIP > records. Maybe even accepting only URI putting all the information > "around" them automaticly) > > Do you have others? > > Thanks, > > Rui Ribeiro > racribeiro at gmail.com From cdel at firsthand.net Sun Jul 19 11:41:53 2009 From: cdel at firsthand.net (Christian de Larrinaga) Date: Sun, 19 Jul 2009 10:41:53 +0100 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <4A61F9E8.8040408@schiefner.de> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <943c86c90906300813v1e586c6ak15b2e26995a4db08@mail.gmail.com> <81A5322E-438C-4D42-8330-05C75D52A43B@firsthand.net> <4A61F9E8.8040408@schiefner.de> Message-ID: <6478B502-8E8C-4CC5-B3EA-D06194CD4FA8@firsthand.net> Carsten On 18 Jul 2009, at 17:35, Carsten Schiefner wrote: > Christian, > > Christian de Larrinaga wrote: >> ENUM is neither a product nor a service. ENUM is a protocol. >> [...] >> Trying to link ENUM to any particular financial model is counter >> productive. Each market participant can decide for themselves how >> or why they might leverage ENUM. But they can only do this if it is >> implemented. > > Indeed. As you said: ENUM is a protocol. But no settlement protcol, > for sure. :-). But ENUM as a protocol does not preclude use of other protocols including those for settlements. > >> So the Regulator should allocate all numbers with ENUM. Then the >> Regulator will underpin universal service and seed both critical >> mass and low per unit cost. > > Coudl you please elaborate a bit here? Do you call for regulators to > make ENUM mandatory? > I am saying that when an E.164 is allocated (to an operator) by a regulator it should be entered into the ENUM tree even it simply returns the tel: uri for the number itself. There is a separate step that a regulator may require of operators providing numbering to then delegate that resource and authority to expand the ENUM information for a number to or on behalf of a user. I am not convinced that making this second step mandatory is necessary provided that users have the ability to port numbers meaningfully. A test for this is whether there are genuine market options for users to change operator to implement ENUM. > Thanks and all the best: > > Carsten > best regards Christian From enumvoipsip.cs at schiefner.de Wed Jul 22 12:46:20 2009 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 22 Jul 2009 12:46:20 +0200 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <6478B502-8E8C-4CC5-B3EA-D06194CD4FA8@firsthand.net> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <943c86c90906300813v1e586c6ak15b2e26995a4db08@mail.gmail.com> <81A5322E-438C-4D42-8330-05C75D52A43B@firsthand.net> <4A61F9E8.8040408@schiefner.de> <6478B502-8E8C-4CC5-B3EA-D06194CD4FA8@firsthand.net> Message-ID: <4A66EDFC.1060802@schiefner.de> Hello Christian, Christian de Larrinaga wrote: >> Coudl you please elaborate a bit here? Do you call for regulators to >> make ENUM mandatory? > > I am saying that when an E.164 is allocated (to an operator) by a > regulator it should be entered into the ENUM tree even it simply returns > the tel: uri for the number itself. I see: like the CRUE principle (http://www.ukec.co.uk/docs/CRUE.pdf) deployed in the UK tree 4.4.e164.arpa - am I correct? Best regards, Carsten From peter at gradwell.com Wed Jul 22 21:26:13 2009 From: peter at gradwell.com (peter at gradwell.com) Date: Wed, 22 Jul 2009 20:26:13 +0100 (BST) Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business c ase matter? Message-ID: Hi crue is not currently deployed within the uk - there is some debate about whether the 'carriers' in the uk are not loading the database for technical or commercial reasons. If it is the case that paying for each individual end user registration is just to expensive for a CP to bulk load, then whether a computer program loads blocks of naptr records or a million individual ones, is, in my opinion, irrelivant, and we just need to fix the registry business model. Cheers Peter Ukec director who owns a voip provider who is looking for the enum business case! --- original message --- From: Carsten Schiefner Subject: Re: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? Date: 22nd July 2009 Time: 11:47:27 am Hello Christian, Christian de Larrinaga wrote: >> Coudl you please elaborate a bit here? Do you call for regulators to >> make ENUM mandatory? > > I am saying that when an E.164 is allocated (to an operator) by a > regulator it should be entered into the ENUM tree even it simply returns > the tel: uri for the number itself. I see: like the CRUE principle (http://www.ukec.co.uk/docs/CRUE.pdf) deployed in the UK tree 4.4.e164.arpa - am I correct? Best regards, Carsten From cdel at firsthand.net Mon Jul 27 17:23:39 2009 From: cdel at firsthand.net (Christian de Larrinaga) Date: Mon, 27 Jul 2009 16:23:39 +0100 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter? In-Reply-To: <4A66EDFC.1060802@schiefner.de> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <943c86c90906300813v1e586c6ak15b2e26995a4db08@mail.gmail.com> <81A5322E-438C-4D42-8330-05C75D52A43B@firsthand.net> <4A61F9E8.8040408@schiefner.de> <6478B502-8E8C-4CC5-B3EA-D06194CD4FA8@firsthand.net> <4A66EDFC.1060802@schiefner.de> Message-ID: <357EEC1C-0D1A-4205-8ED5-D02C1FDF6D78@firsthand.net> On 22 Jul 2009, at 11:46, Carsten Schiefner wrote: > Hello Christian, > > Christian de Larrinaga wrote: >>> Coudl you please elaborate a bit here? Do you call for regulators >>> to make ENUM mandatory? >> I am saying that when an E.164 is allocated (to an operator) by a >> regulator it should be entered into the ENUM tree even it simply >> returns the tel: uri for the number itself. > > I see: like the CRUE principle (http://www.ukec.co.uk/docs/CRUE.pdf) > deployed in the UK tree 4.4.e164.arpa - am I correct? > > Best regards, > > Carsten > It is an interesting question. I think my answer is no, not really because CRUE is a proposal for a Carrier not Regulator controlled bulk ENUM entry. CRUE's scope is not for all numbers and it is dependent on whether a Carrier chooses to use it. (Well it would be if CRUE was operational). So it doesn't help a Regulator ensure its number resources can route over either IP or TDM networks seamlessly. When this idea started out in the UKEG I recall it was discussed in terms of a way to help VoIP service providers gain new (and only new) local number ranges to route over IP and to them through TDM gateways. The original discussion in the UKEG revolved around this idea as a way to bootstrap use of ENUM. The aim was to encourage VoIP providers to setup services and applications that dip ENUM. That is to use numbering. CRUE is a much more ambitious extension of that idea. So much so that it is explicitly stated not to be for the purposes of bootstrapping the use of ENUM (VoIP and so forth). CRUE quite quickly grew in scope to include any "carriers" and also most numbers already in circulation with the TDM / PSTN operators. I was not really convinced that carriers would be interested, having instigated some carrier ENUM projects including the 250 million number SuperRegistry at IntelePeer in the US. I was of the view that the Carriers need and ambitions differed to VoIP orientated or alternative telecoms service providers. So I felt CRUE was out of scope for me to involve myself more closely once it had moved on from the initial discussions. I am not saying it is a bad idea just that I can't really judge at this point whose business plan it fits. Although having said that I don't think it fits with the Regulatory one at least as it stands. A Regulator would need to manage bulk entry somewhat differently to CRUE. Christian From jim at rfc1035.com Mon Jul 27 18:07:39 2009 From: jim at rfc1035.com (Jim Reid) Date: Mon, 27 Jul 2009 17:07:39 +0100 Subject: [enum-wg] CRUE In-Reply-To: <357EEC1C-0D1A-4205-8ED5-D02C1FDF6D78@firsthand.net> References: <82zlbq6rlq.fsf@mid.bfk.de> <850A39016FA57A4887C0AA3C8085F949DD3F67@KAEVS1.SIDN.local> <943c86c90906300813v1e586c6ak15b2e26995a4db08@mail.gmail.com> <81A5322E-438C-4D42-8330-05C75D52A43B@firsthand.net> <4A61F9E8.8040408@schiefner.de> <6478B502-8E8C-4CC5-B3EA-D06194CD4FA8@firsthand.net> <4A66EDFC.1060802@schiefner.de> <357EEC1C-0D1A-4205-8ED5-D02C1FDF6D78@firsthand.net> Message-ID: <35C57ADB-83BF-4E19-83B0-DB217BCE1121@rfc1035.com> On 27 Jul 2009, at 16:23, Christian de Larrinaga wrote: > When this idea started out in the UKEG I recall it was discussed in > terms of a way to help VoIP service providers gain new (and only > new) local number ranges to route over IP and to them through TDM > gateways. Not quite. The initial motivation was bulk population of 4.4.e164.arpa. That was clearly explained in the CRUE documents I authored 4-5 years ago. This was also the motivation of the people in UKEG/UKETG who kicked around the original ideas that were then written up. The rationale was that if there was significant amounts of meaningful data in the tree, there would be an incentive for providers to do ENUM lookups. That in turn might encourage more ENUM-aware applications and services to be deployed. It was felt that VoIP providers might want to use CRUE as a way to avoid paying termination charges for inbound calls from the PSTN. But this was a second order effect. Another side- effect of CRUE was simplification of the authentication and validation issues: a VoIP provider could issue an {ENUM-only?) number to a customer, eliminating the need someone to prove they "owned" that number. From enumvoipsip.cs at schiefner.de Tue Jul 28 14:10:17 2009 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 28 Jul 2009 14:10:17 +0200 Subject: [enum-wg] DRAFT Minutes of ENUM-WG session at RIPE 58 are available Message-ID: <4A6EEAA9.8060308@schiefner.de> Dear ENUM-WG Colleagues, Draft minutes of the ENUM-WG session at RIPE 58 are now available at http://www.ripe.net/ripe/wg/enum/minutes/r58-minutes.html . I would appreciate if you could set some time aside to review and comment on the draft and, if necessary, post objections or corrections on this list no later than 12:00 UTC on Monday, 31 August. Niall and I expect to declare these minutes "final" shortly after that. Thanks to the team at the RIPE NCC for their support, and especially to Nathalie Trenaman for taking the notes. Best regards, Carsten Schiefner Co-Chair, RIPE ENUM Working Group From cdel at firsthand.net Tue Jul 28 16:21:31 2009 From: cdel at firsthand.net (Christian de Larrinaga) Date: Tue, 28 Jul 2009 15:21:31 +0100 Subject: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business c ase matter? In-Reply-To: References: Message-ID: <924BEEB4-F50A-438E-B58F-1A1DE2EFB261@firsthand.net> Peter The fact that CRUE is not deployed speaks volumes. It sounds like it is time to review ENUM in the UK. As 4.4. is delegated to Nominet how do you think (UKEC) this can be conducted to achieve a happy outcome? In particular bearing in mind that ENUM is or should be in the user's control. Christian On 22 Jul 2009, at 20:26, peter at gradwell.com wrote: > Hi > > crue is not currently deployed within the uk - there is some debate > about whether the 'carriers' in the uk are not loading the database > for technical or commercial reasons. > > If it is the case that paying for each individual end user > registration is just to expensive for a CP to bulk load, then > whether a computer program loads blocks of naptr records or a > million individual ones, is, in my opinion, irrelivant, and we just > need to fix the registry business model. > > Cheers > Peter > > Ukec director who owns a voip provider who is looking for the enum > business case! > > > > --- original message --- > From: Carsten Schiefner > Subject: Re: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a > business case matter? > Date: 22nd July 2009 > Time: 11:47:27 am > > Hello Christian, > > Christian de Larrinaga wrote: >>> Coudl you please elaborate a bit here? Do you call for regulators to >>> make ENUM mandatory? >> >> I am saying that when an E.164 is allocated (to an operator) by a >> regulator it should be entered into the ENUM tree even it simply >> returns >> the tel: uri for the number itself. > > I see: like the CRUE principle (http://www.ukec.co.uk/docs/CRUE.pdf) > deployed in the UK tree 4.4.e164.arpa - am I correct? > > Best regards, > > Carsten >