hi!
[...] even if the telco doesn't have an own ip gateway, buying such a service from a different telco would be another simple option.
That's pretty much an European view. What about countries where there is only the incumbent around? Why (no competition!) should they dump it onto the net ASAP (and loose revenue) instead of making it a long distance/intercont call? If they route the call at all...
well that's a question for the regulator then, isn't it. i don't want to nor see a reason why to mess with regulations. if a country decides to ban voip-gateways (although still i don't really know a good reason why), that's the country's decision and that decision has to be followed in that country. but i don't think this is a good reason to prevent everyone else from promoting voip.
I believe even after a full introduction of +878 we will have those two types of VoIP numbers around for quite a while.
probably. certainly this cannot be avoided for a long time (except locally by regulators), but also i'm not the one who demands that this has to be avoided.
no, the idea is to use the whois-db. with allocated blocks these blocks would be distributed over the different RIRs' whois-dbs. porting a number would mean a change of the whois-db entry (by the current admin i.e. holder of the maintainer-object of the respective number), replacing the maintainer-object and delegation data of that entry.
with assignments of single numbers without prior allocation, this is different, either some reasonable way of distributing these single assignments over the RIRs' whois-dbs must be found or a single whois-db had to be used. this also might affect the mechanism to generate delegations.
only the whois-db(s) would be necessary to hold the authoritative data regarding number assignments.
Maybe you lost me here again: wouldn't that mean that over time, when people continue to port their numbers as they like, you'll end up with an entry per number? Then you should consider having such an implementation already from the very begining. And you have something that is pretty similar to a [domain] name registry...
right. actually in the proposal any assigned number (or assigned block) is a single entry right from the beginning. i just checked the text (3.2), and it's in fact not clearly stated. the idea was to enter every assignment as a new object into the whois-db at the time when assignment is done. i also regard it as quite similar to a domain registry (and in other respects similar to an ip registry).
On the "handling the workload" issue it might be helpful to get an opinion from an/the RIR[s] itself/themselves, I guess.
sure, that's also mentioned in the proposal. i guess you know who could be the right person with insight and ideas for procedures at the RIRs, or at least at RIPE? :)
That indeed could be the case, yes. ;-) However, I will certainly refrain from pointing folks out here.
sure, just send them here if they don't run away fast enough ;)
i mean an amount of numbers. say, a provider has the possibility to enter 1000 numbers (no matter which ones) before an application for the next e.g. 1000 numbers is necessary. i.e. still keeping an 'AW' approach while not allocating specific blocks.
And why would this be useful? The 'AW' approach IMHO originates from the demand to have some greater flexibility on the LIR's side when doing assignments - while still keeping the idea of conservation.
Question is: is there a more or less identical need for this type of conservation for UPT numbers, too? Or isn't it more like a one-off? At the end of the day it's "personal" - apart from some exceptions here and there: why would people liek to have more than one?
the concept as such should work also without an 'assignment window'. but i think it's not a too bad idea, otherwise most-popular-vanity-number grabbing probably can not be prevented. also, depending on the policy, conservation might be identified as an issue. kind regards, Chris Heinze