[Ietf-not43] a perspective on LDAP v IRIS.

[Eric A. Hall]

on 8/19/2003 11:56 AM David Blacka wrote:

>> Exactly right. A couple of the problems you encountered would still
>> exist with FIRS, but for the most part, starting with a different
>> objective (optimizing the application space accordingly) would have
>> produced some significantly different result. As you allude to in the
>> text above (and which would probably have been more helpful as intro
>> text rather than outro by-the-way), your path doesn't really say much
>> about how well the FIRS approach would work.
> 
> As far as I can tell, FIRS would be harder to implement at our level,
> not easier.  Which of the problems that I described would be alleviated
> by FIRS? 

It seems to me that most of the problems you encountered on the way to a
working solution would have been avoided by a recognition that generic
tools weren't going to do the job. The FIRS approach would have moved you
to what eventually did work for you.

The central theme with FIRS is to populate the data substrate, but to
optimize the application space. In particular, "FIRS" is just a stovepipe
vertical application into the data substrate. The idea is that once the
substrate is populated, other stovepipes will poke into it, sucking data
out and putting new data in.

The degree to which any of those may require application-specific logic
will depend on the application. Some of them will need some local logic
and no server logic -- "give me the host certificate for this mail
server/user" would only require client processing -- while others will
require additional back-end logic. FIRS the service focuses on high
volume, centralized delegation data, so it falls into the latter in the
general case, but it also off-loads significant processing onto the
front-end to minimize the back-end burden (normalization of i18n domain
names being an obvious example of this, where back-end normalization would
crush the servers). There are also a couple of areas in FIRS where the
client does all of the work; contact lookups are equality matches, for
example, with the client doing all of the prep work.

> I will admit that I don't entirely grok FIRS.  It certainly
> looks like the client side would be harder (than RLDAP clients).

It is necessarily more tuned, but I don't see this as an indictment. Any
client that is part of a distributed system require custom clients. This
even applies to legacy WHOIS, for example, where either the client has to
perform local processing, or it uses an application proxy which is
essentially a remote client.

> Our target was to use technology that would reduce implementation costs
> on both the client and server sides.  And the project proved to us that
> LDAP (in this case) did not do that.

How is IRIS cheaper on the client side for this specific application? You
have to do even more work, given the lower availability of tools (no BEEP
perl module, for example).

For the same reasons, I don't see how IRIS could possibly be cheaper for
lightweight (edge-distributed) servers that do not require additional
processing (eg, publishing certificate data), given that there are
numerous servers available to choose from which could do the job as soon
as the schema were installed.

Andy said in another message that the server deployments for ~this
applicaiton were relatively equal.

Meanwhile, the learning-curve costs you describe were essentially
amortized on the back of RLDAP. You didn't have to make the same mistakes
with IRIS, and had better expectations going into it, so it would be
expected to have been cheaper and faster. As noted multiple times,
however, these costs are not globally applicable.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/