[56327] in North American Network Operators' Group
Re: Tools
daemon@ATHENA.MIT.EDU (Andrew Newton)
Mon Mar 3 11:23:05 2003
Date: Mon, 03 Mar 2003 11:32:56 -0500
From: Andrew Newton <anewton@ecotroph.net>
To: bmanning@karoshi.com
Cc: Michael.Dillon@radianz.com, nanog@merit.edu
In-Reply-To: <200303031544.h23FiYO22740@karoshi.com>
Errors-To: owner-nanog-outgoing@merit.edu
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
