Re: New I-D:draft-kaplan-enum-source-uri-00.txt

On 2007/12/12 16:12, Paul Erkkila <[email protected]> wrote:
> Otmar Lendl wrote:
> >
> > 
> > Yes, the incremental change ist not that big. The question remains: 
> > 
> > Have we now reached the point where we should stop fiddling with the
> > DNS protocol and should instead look for a directory lookup protocol
> > which was designed from the beginning to support authenticated and
> > complex queries returning structured data?
> 
> LDAP?
> 

I've been mulling over this question during the holidays. I've come
to the following conclusion:

The DNS (as well as LDAP) is primarily designed as a directory service.
It is a protocol to query a database for records conforming to a
specific question. The intelligence on how to interpret the data and
what to do with this information (possibly combined with data learned
from other sources) is in the device which asked the query.

In terms of VoIP: the call routing algorithm runs inside the
soft-switch. ENUM is just one input into this algorithm.

What I see in various proposals here in the WG (starting with the
trunk-ID draft ) and most clearly from this draft is a different
approach to the overall architecture: The soft-switch should be dumb,
all call routing decisions are out-sourced to the ENUM DNS servers.
They do capacity planning, source-dependent routing and all the peering
logic. If you take this approach, then of course the soft-switch needs
to somehow communicate all the basics of that call to the ENUM DNS
server so that it can make the correct call routing decision.

Such "out-source the logic" approaches are not new. Network equipment
handling dial-up sessions or DSL logins have been doing that for years.
The protocol of choice for such applications has been RADIUS (perhaps
now supplanted by DIAMETER). RADIUS supports almost arbitrary key-value
pairs in the query: All the information the dumb switch has can thus
be easily packed into the query. The same holds for the answer: it can
instruct the soft-switch in detail what to do with the call.

---

Yes, of course it is possible to pack that on top of the DNS and build
tricky algorithms into the DNS response generation (Akamai and all the
DNS-based load-balancer vendors have been doing that for years), but
given the potentially large set of background information the server
needs in order to run its algorithm (which has to be included in the
query) plus the need to return a more complex answer than just a URI
make the DNS a bad choice for the query protocol.

LDAP is only a marginally better choice. It, too, is a "give me the
information you have which matches XYZ"-protocol and not a "I have a
customer request with these parameters, please tell me what to do"
kind of protocol. 

/ol
-- 
// Otmar Lendl <[email protected]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg