Create a separate tree (i.e. virtual.nrenum.net) to populate the virtual numbers completely separate. It also means that the virtual tree must be queried separately.
|Guarenteed Guaranteed separation|
An other tree to query in a sequential order.
(There is no operational golden tree so to resolve URI we have to query multiple tree anyway. IMHO I don't see it as a big drawback to query plus one tree.)
|The resolver can very cleanly decide if it want to use virtual numbers or not. |
Furthermore resolver can decide the order of preference of virtual and not virtual numbers.
|Zero time to wait for anybody and for anything, we can do it now. |
There is no need to wait for ITU to permit (if ever permit) a new country code.
|I prefer to delegate it the the same way as the nrenum.net tree, so every country prefix is delegated to the country, and every country can create a local policy.|
|Countries are not the same so this way the delegation is not centralized, so this way it is not underestimating the local knowledge, differences, national authority policies etc.|
In this virtual tree all number range could be delegated what are
If the country national dialing plan has such range inside the county code (see "point 1, and 2. above") we will see the country code prefixed calling number on our endpoint if it rings. So country codes are "well known" so we and all people, who use the service, can know from calling number the locality of the caller. What i think is a useful information.
In other hand if we e.g. get from ITU +999 country code. (I use for example only +999 country code. Of course we could get another country code.)
So for end user it will be confusing to get a call from a +99936 virtual number range,
Option 2 (propsed by Bernie)