Re: Send-n, rat holes and real issues

> It only solves the send-n problem if:
> 
> * every device that is going to do the ENUM lookup is pre-loaded with
> every data document for every country that might be dialled.
> * the tree being queried is sufficiently densely populated so that the
> number of times there is no number found (despite being in the number
> plan) is minimised.
Nah, I don't think you will preload everything, just cache what you use the
most.  Download whatever else you need on demand.

The data I'm proposing gives you validation of number length.  It doesn't
tell you that you have a working number.  It gives you the information you
need to invoke routing.

In many systems, you won't get information on whether a given service is
available on a given number until you actually try to invoke the service.
I'm not too thrilled with that, but it's the way things work in some cases
now.  If we fixed that, then the actual ENUM query would get you that
information.  However, as I said, in general, the device in the network that
has ENUM access is at the border of the network and the device that handles
something like dial plan interpretation is near the user, so you would have
to have some other mechanism to propagate the information back towards the
proxy server doing the dial plan interpretation, or have more systems with
ENUM access.  The latter has its own operational issues.  That kind of thing
is solvable, but it's an indication to me that the solution has not yet been
thought all the way through.


Brian