Too many features layered on a single tool. Haq the tool and the dependencies will cripple your service offering.
LDAP is not a tool, it is a protocol that can be used by many tools to communicate in the same way that many servers (BIND, NSD, DJBDNS, MS-DNS, QuickDNS) can use the DNS protocol to communicate with countless clients (Netscape, sendmail, ...). That's why I originally said the following
I believe that LDAP can be the core of this toolset.
If you build a tool that queries the ARIN LDAP server then you can mirror ARIN on your own LDAP server and the tool doesn't have to change. Or you can have a caching LDAP client/server that works and the tool doesn't have to change. If you offer your mirror of ARIN's data (or your caching LDAP server) to your customers for configuring their firewalls, then the firewall manufacturers will almost certainly add support for LDAP-based filter config to their product. That's because LDAP is a widely implemented and deployed industry standard protocol. Once firewalls are configuring dynamically based on either a trusted ISP's mirror of ARIN or a trusted firewall vendor's mirror of ARIN, then these bogon issues will go away. That's because we will have the knobs to turn on and off address space dynamically. Spammers won't be able to use unregistered addresses because everybody will be indirectly trusting ARIN's database. And they won't be able to use the unused parts of registered blocks because ISP's will publish their usage in their own LDAP servers that will be part of the ARIN trust hierarchy. Once this begins to provide benefit in North America, the rest of the world will soon follow. --Michael Dillon