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
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, ...).
tool in the generic sense. too many things that depend on LDAP for proper functioning -will- make LDAP a tempting target.
Once this begins to provide benefit in North America, the rest of the world will soon follow.
presuming facts not in evidence.
--Michael Dillon
On maandag, maa 3, 2003, at 16:44 Europe/Amsterdam, bmanning@karoshi.com wrote:
tool in the generic sense. too many things that depend on LDAP for proper functioning -will- make LDAP a tempting target.
So not functioning properly is preferable to depending on a tempting target for proper functioning?
On maandag, maa 3, 2003, at 16:44 Europe/Amsterdam, bmanning@karoshi.com wrote:
tool in the generic sense. too many things that depend on LDAP for proper functioning -will- make LDAP a tempting target.
So not functioning properly is preferable to depending on a tempting target for proper functioning?
what is not functioning properly? --bill
On maandag, maa 3, 2003, at 17:30 Europe/Amsterdam, bmanning@karoshi.com wrote:
So not functioning properly is preferable to depending on a tempting target for proper functioning?
what is not functioning properly?
Determining who is authorized to announce a certain block of IP address space.
On maandag, maa 3, 2003, at 17:30 Europe/Amsterdam, bmanning@karoshi.com wrote:
So not functioning properly is preferable to depending on a tempting target for proper functioning?
what is not functioning properly?
Determining who is authorized to announce a certain block of IP address space.
no protocol is going to help with this problem. its a social engineering issue, not a technical issue. --bill
On maandag, maa 3, 2003, at 18:41 Europe/Amsterdam, bmanning@karoshi.com wrote:
what is not functioning properly?
Determining who is authorized to announce a certain block of IP address space.
no protocol is going to help with this problem. its a social engineering issue, not a technical issue.
I really don't see this. If we assume that the RIRs have authorative data on who holds what address space (which is sort of true for recent or well-mainained assignments) there is still a lot of glue necessary to make that into a "this route is ok" or "this route is not ok" decision when processing routing updates.
I'd like to stop this argument now by saying you are both right. *) LDAP is a protocol, not an implementation. The back-end can be anything... even monkeys with pencil and paper. *) Michael's point about doing things differently and hopefully in a better way does not hinge on technology... it is a matter of will. The technology exists. *) In order to run an efficient public-facing LDAP server that scales to the order needed by many but not all, off-the-shelf vendor software will not suffice. *) LDAP in its current form does not contain the operations or data types needed by this community. However, it is an extensible protocol and anyone with a source-available or pluggable implementation will not be starting from scratch. *) Having to extend the protocol means that generic clients are of limited use but not unuseable. *) As Stephane said, there are a number of people looking at this in the IETF CRISP working group. And LDAP is one of the proposed solutions. -andy bmanning@karoshi.com wrote:
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, ...).
tool in the generic sense. too many things that depend on LDAP for proper functioning -will- make LDAP a tempting target.
-- Andrew Newton
participants (4)
-
Andrew Newton -
bmanning＠karoshi.com -
Iljitsch van Beijnum -
Michael.Dillon＠radianz.com