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