Subject: [Ietf-not43] extensibility

From: Michael.Dillon at radianz.com ([email-masked])
Date: Thu Jul 31 17:06:37 2003

>This message is in the context of my being ignorant about LDAP's 
>deployment.  I'm not saying the LDAP is garbage, I'm saying that I am 
>unaware of it's advances.  Given that background ...

Well, let's get that background up to date. 

First some universities that have replaced their internal whois directory 
with LDAP directories. Read through the entire pages because there is a 
lot of useful background that is mentioned here.

http://www.uwo.ca/its/projects/ldap_phaseI.html
http://www.stanford.edu/group/dcg/pdd/projects/dirlookup/dir_require.htm

Next, naming. A lot of LDAP directories and directory tools have different 
names so you won't know that they are based on LDAP until you dig deeper. 
For instance, Microsoft calls their version Active Directory and Novell 
calls theirs Novell Directory Service. On Solaris it's the Sun ONE 
Directory Server. If you browse through some books on these topics in the 
bookstore you'll see that they are all just LDAP with some specific 
schemas and architecture. Also, since the early LDAP standards didn't 
include things like replication, these directory services all built their 
own extras.

Note that it is possible to take something like OpenLDAP and make it work 
in a SunONE or Microsoft AD environment with the right schemas
http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-GILSchemaExtension.html
Or maybe you'd prefer to have a calendaring system integrated with LDAP?
http://www.steltor.com/notes/corptime-server/5_1/refmanual/refappe.htm#1046875
Or maybe you just want to use it to manage DNS zone files?
http://ldap2dns.tiscover.com/

Because LDAP is part of the plumbing of a directory service, it sometimes 
gets bundled together with other stuff that looks like a directory 
service, for instance JNDI is the Java Naming and Directory Interface. 
This allows a Java developer to use things like LDAP, DNS or NIS without 
needing to know the details of the individual protocols.

LDAP is used as a fundamental component of the worldwide datagrid used for 
their Monitoring and Discovery Service. This is the system that allows 
researchers to ship data to computers around the world and solve problems 
as if they have a gigantic supercomputer array of their own. They use a 
patched version of OpenLDAP. They've also published some benchmarks to 
show how scalable LDAP is.
http://www.globus.org/testing/dmark_results.html

LDAP is also part of the core "best practices" that the NSF is promoting 
to its audience of research institutes and universities. Again, they don't 
say "LDAP" because it's just part of the middleware plumbing.
http://www.nsf-middleware.org/ 
Much of this comes out of the Internet2 middleware initiative.
http://middleware.internet2.edu/ 
http://www.georgetown.edu/giia/internet2/ldap-recipe/

Wait a minute, isn't middleware just another term for those Message 
Queuing systems like MQSeries, MSMQ and TIB/Rendezvous? Yep, right you 
are. And LDAP is being used here as well
http://support.sas.com/rnd/itech/doc/messageq/common/index.html
This is the Enterprise version of gluing apps together...

So, the conclusion is that LDAP is widely used in industry and academia, 
is available in many implementations and is widely documented in books and 
on the web. There are also lots and lots of IT professionals who have 
LDAP-related skills (either programming or running servers) so that 
companies can actually hire people with experience to build anything they 
need for CRISP's LDAP directory. Oops, I forgot, we gave LDAP a new name 
too. I meant to say FIRS.

Admittedly, XML has many of the same advantages, however the halo of 
activity around XML is related to things other than building and running 
directory services. Since CRISP is fundamentally a directory service, it 
will be easier to implement if people use FIRS because then they get to 
leverage the halo of activity around LDAP.

BTW, if someone finds a need to use an XML-RPC or a SOAP interface to get 
at the FIRS service, I'm sure that it would be a trivial programming 
exercise to make a FIRS client that is an XML-RPC or SOAP service. I 
suspect that the IRIS work will be more useful if it is refocused into 
providing a SOAP interface to an underlying FIRS service.

--Michael Dillon

---

From: hardie at qualcomm.com ([email-masked])
Date: Thu Jul 31 18:52:37 2003

Michael,
	This is a very interesting set of resources.  Reading through
them and matching them to my own experience (working through issues
in LDAPBIS and LCUP), one of things that strikes me is the extent to
which LDAP has become a substrate rather than an application-level protocol.
LDAP  is, as you note, the substrate for a very large number of 
directory service protocols.
But these are not interoperating parts of a single directory service; they
are independent services that do not share schema, often do not share
encodings, comparators, or fundamental assumptions about how
the pieces of LDAP work (viz. the recent discussion in LDAPBIS on whether
a minimum supported attribute name length could be required at
the protocol level or had to be schema-by-schema). Putting that in another way,
no one currently expects the calendaring service client to talk to the
GRID resource allocation service, despite the fact both applications may be
built on the same substrate; it would be a bit like expecting them
to interoperate just because both were built on IP.
	Where we cannot directly evaluate the differences between
the proposed applications, the working group has to match the application
specific needs of CRISP to the protocol substrate being used in the proposal.
For that purpose we need to ask ourselves things like:  how well does the
data model match the data structures native to the substrate?  how well do
the needed comparators and functions match those native to the substrate?
how well do the needed access control mechanisms match those native
to the substrate?  how well do the scaling characteristics match those
needed?  how well will referral mechanisms needed match those native
the substrate?
	There are also two other, more delicate design questions in here.
One is how to balance the baggage the substrate brings with the benefits
it brings; that's a very tough one to approach rationally (and I've been
impressed by the group on this point so far).  LDAP as a protocol has
loads of aspects that wouldn't be used by FIRS (data update mechanisms,
for example, since this is a read-only service); XML as a substrate has
expenses in bloat that may make it difficult to use over low-capability
links.  Those have to be considered without descending into religious
wars, and that's not easy. The other tricky one is how to balance the needs
of those providing the service with those consuming the service.  That's tricky
indeed, especially as we are presuming that new clients and new schema will be
needed for either.  But we have to consider it to do our job well.
	Thanks again for thinking on this and putting together the
resources.
			regards,
				Ted Hardie
>_______________________________________________
>Ietf-not43 mailing list
>[email-masked]
>https://lists.verisignlabs.com/mailman/listinfo/ietf-not43