[Ietf-not43] extensibility

[hardie at qualcomm.com]

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
>
>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
>
>
>
>_______________________________________________
>Ietf-not43 mailing list
>Ietf-not43 at lists.verisignlabs.com
>https://lists.verisignlabs.com/mailman/listinfo/ietf-not43