* 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? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

* Rui Ribeiro:

2009/6/30 Florian Weimer <fweimer@bfk.de>:

...

* 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 <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

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@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/

-----Original Message----- From: Rui Ribeiro [mailto:racribeiro@gmail.com] Sent: Tuesday, June 30, 2009 6:06 PM To: Florian Weimer Cc: Antoin Verschuren; enum-wg@ripe.net Subject: Re: [#XWM-610908]: Re: [enum-wg] ENUM Adoption - Does a business case matter?

2009/6/30 Florian Weimer <fweimer@bfk.de>:

...

* 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@gmail.com

-----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@sidn.nl xmpp:antoin@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-----

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č" <md@bts.sk> 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@cnr.it

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@enum.nl W http://www.enum.nl

...

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@enum.nl W http://www.enum.nl

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@bts.sk ---- ---- ---- --------------------------------------------------------------------------

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 <fweimer@bfk.de>:

...

* 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@gmail.com

Hi Rui (and all others)! Don't hold back strange ideas. The non-strange ideas have proven to not work. If you view the subject of ENUM lookup as part of the interconnection regime (I do) than an interconnect is all about: There is X amount of money available for the call; which operator will get what portion. Looking at the different models (bill and keep, calling party pays, ...) in different countries, maybe the right combination of the two could be a winning concept. Money is indeed something which will usually make people think. Regards, Torsten Rui Ribeiro schrieb:

Another strange ideia...

What if operators receive back money from ENUM registers... what if the ENUM Registry pays 30% or 40% to the operators that make lookups on the tree? It might be pinouts... may not. The "driver" for operators will be to get some revenue from the ENUM tree it self becoming a source of income. (don't flame me... just giving ideias to the discussion).

Rui Ribeiro racribeiro@gmail.com

ENUM is neither a product nor a service. ENUM is a protocol. There are already per dip models carriers pay for registry dips but this is really beside the point as a adopting a single revenue model won't drive adoption of ENUM. I think I should also note that in my view ENUM is not a carrier play ENUM is not a user play but ENUM could be a very useful Regulator play. To suggest just three useful features that ENUM brings for Regulators. a/ ENUM enables reachability over both IP and TDM networks using a single numbering resource. b/ ENUM registry contains dynamic information about numbering resources under the Regulator's sphere which is valuable to regulator and market dynamics. c/ ENUM offers support for implementing services that underpin a regulatory role for universal service obligations as communications move across both IP and TDM networks. For example number portability. 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. 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. This is vital as users with numbers will pay in the end. Will it be used? Who knows. Carriers may start to look at ENUM as a simple way to enhance how they offer edge based routing to optimise their bilateral relationships with customer configurable services. That could be a game changer. Of course customers unhappy with carrier services may use ENUM to route around choke points but then they can do that today using IP directly at least where carriers don't add latency and filtering to their IP access networks. Christian Christian de Larrinaga On 30 Jun 2009, at 16:13, Rui Ribeiro wrote:

Another strange ideia...

What if operators receive back money from ENUM registers... what if the ENUM Registry pays 30% or 40% to the operators that make lookups on the tree? It might be pinouts... may not. The "driver" for operators will be to get some revenue from the ENUM tree it self becoming a source of income. (don't flame me... just giving ideias to the discussion).

Rui Ribeiro racribeiro@gmail.com

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

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