Re send-n for query optimisation

On Jul 1, 2008, at 15:34, Clive D.W. Feather wrote:

>> But the ENUM lookups don't have to be blocking,
>> so why not let the client send an ENUM query after every digit (see  
>> above
>> for prefix/area code considerations)?
>
> Because it's still load on the servers that would be worth reducing.

I'm not sure that this load is ever likely to be significant in the  
overall scheme of things Clive. Is there any hard data here or are we  
all just working on guesses? How much query traffic could send-n  
actually save as a proportion of the overall number of DNS lookups  
that will be going on inside the NICC's private ENUM-like tree? I  
would assume that these lookups would be passing through some sort of  
resolving server, so there should be a Big Win for cache hits after  
the initial "priming" query.

Mimimising queries and reducing load is always a Good Thing. Sometimes  
though the cost of doing that exceeds the benefit. It's not clear to  
me where the balance lies for send-n. It does seem a bit strange to  
propose a new NAPTR type to deal with a possible operational problem.