Re: Dereferencing Match draft for the repository...

[John Strassner <jstrassn@cisco.com>]

Harald and Dave,

I too appreciate your concern. The motivating factor for this
extension is twofold:

  1) to provide additional functionality for those clients
      that need better performance when unwinding
      a set of pointers, and
  2) to provide a means of mapping richer information
      models (e.g., CIM and DEN) to the existing LDAP
      data model.

As Ryan said, the first point addresses general needs of many
applications. The second point, while specifically addressing
things like CIM and DEN, as well as the work going on in the
policy framework working group, also has a more subtle
connotation.

There is a lot of pressure to use LDAP for a wide variety of
things. One class of applications attempts to store in the
directory the object-oriented equivalent of associations and
aggregations. These describe relationships between two objects. A
natural way of describing this is with DN pointers. However, the
existing data model of LDAP doesn't have this capability. So,
rather than tweaking the existing data model (which would raise
interesting interoperability problems), we propose an extension
that avoids revising the existing LDAP data model.

That being said, I agree with Ryan, we do need to add more
interoperability discussion. I may be guilty of being naive here,
but I also agree with Ryan, in that the server either supports
this extension or it doesn't. If it doesn't, then one can still
do the equivalent functionality, except that it will be much
slower, since conceptually what then happens is that you have a
serial set of dereferencing operations. Although for complicated
applications, like policy or DEN, it might be easier to just emit
an appropriate error condition.

This would be strengthened by having some type of profile that
the server could fill out, saying which extensions it supported
and which it didn't. Then, we could avoid surprising the
client...

regards,
John
----- Original Message -----
From: Ryan Moats <jayhawk@att.com>
To: Harald Tveit Alvestrand <Harald@Alvestrand.no>;
<dboreham@netscape.com>
Cc: <ietf-ldapext@netscape.com>; <gfm@qsun.ho.att.com>;
<johns@cisco.com>
Sent: Monday, June 21, 1999 5:36 AM
Subject: RE: Dereferencing Match draft for the repository...


> Harald wrote:
>
> | At 16:01 18.06.99 -0500, Ryan Moats wrote:
> | >I-D editor:
> | >
> | >Please insert the following draft as
> | >draft-moats-ldap-dereference-match-00.txt  Thanks-
> |
> | This is part of a trend I've seen for a while, where
> | one extends the LDAP server in multiple directions,
> | in order to make particular clients for particular
> | functions more efficient.
> |
> | The endgame of this particular trend is a situation
> | where we have multiple completely independent
> | LDAP-based services serving differing purposes, but
> | with little real interoperability between them.
> |
> | I'm not particularly happy with a model where my
> | organization has to run 5 different LDAP *services*
> | (probably using servers from 4 different vendors), so
> | that the 5 different functions-using-extensions-to-LDAP
> | can continue to work.
> |
> | This started worrying me about 10 minutes after I saw
> | the first drafts on Dynamic LDAP, so it's not exactly
> | a new thing......
>
> While I understand Harald's concern, my current opinion
> (and this can change) is that there are already enough
> cases when dereferencing pointers is a useful thing.
> However, I do agree that the draft needs more interoperability
> discussion (see below).
>
> David Boreham wrote:
>
> | I'd like to propose that it be a rule of the ldapext working
> | group that all such documents must state clearly what
> | are the implications for a server not implementing the
> | wizbang new feature proposed. Also a statement on
> | how interoperability can be maintained should be
> | required.
> |
> | I've tried to include this sort of information in
> | the feature-creep drafts I've written, but looking
> | back I wish I'd put it in distinct sections.
>
> I like the idea of adding a "how to respond if you don't
> support this extension" section to the draft.  As far as
> interoperability beyond this, I'm not sure I understand:
> why isn't this a binary situation (the server supports
> the extension or not).
>
> Ryan Moats
>