Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot

From: Leif Johansson <[email-masked]>
Date: Mon, 09 Nov 2009 03:01:17 +0100

Alexey Melnikov wrote:
> Spencer Dawkins wrote:
>> Hi, LDAP Directorate,

<snip>

I seem to recall that I brought up change-notification as an idea for
new work we might take on in LDAP-space during the last MPLS IETF (?)
LDAP bar-BOF... (I remember it was darned cold).

I think the response I got from most LDAP server implementors was "yes
but why" :-)

The problem seems to be that it is difficult to tell where "simple
notification" ends and "replication" begins and history tells us that
the latter has been problematic for the IETF.

Historically lots of people have played tricks with OpenLDAP/umich
LDAP replication logs in order to achieve simple change notification
for LDAP and imo that tells me that there _should_ be enough interest
in some kind of work in this area even from LDAP server vendors!

I have not opinion (yet) about this draft though.

	Cheers Leif

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 8 Nov 2009 23:25:56 -0800

It seems to me we that we have "good enough" content synchronization  
mechanisms in LDAP, but don't have any (formalized) event notification  
mechanism.

For instance, consider an intrusion detection system which wants  
notification of all password change requests, including information  
about the requestor and the outcome of the request.  At present, such  
systems tend to rely on vendor-specific audit logs.

I could support an effort to analysis requirements for event  
notification and, then, build a mechanism specifically designed to met  
these requirements.

What I don't support is designing yet another "content  
synchronization" mechanism.

But what does 3GPP want?  It seems to me they were more after content  
synchronization than event notification.

It's not clear to me whether you are after content synchronization  
than event notification.

-- Kurt

On Nov 8, 2009, at 6:01 PM, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alexey Melnikov wrote:
>> Spencer Dawkins wrote:
>>
>>> Hi, LDAP Directorate,
>>
>
> <snip>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkr3d+0ACgkQ8Jx8FtbMZnfdOACbBw0eAE+XlZkgRZ66+j6BOuhh
> dA8An1t1r0ZbbAEuv/BVE9OWnnifA4d3
> =c5nm
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ldap-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldap-dir

---

From: Leif Johansson <[email-masked]>
Date: Mon, 09 Nov 2009 08:43:05 +0100

> systems tend to rely on vendor-specific audit logs.

Right.

> What I don't support is designing yet another "content synchronization"
> mechanism.
> 

Quite often the two notions get mixed up in requirements and maybe
that is the case here too. I'd volunteer to help clean up the reqs
with Spencer and anyone else who are interested.

> 
> It's not clear to me whether you are after content synchronization than
> event notification.

I don't know about 3gpp but for the metadirectory applications I've
seen I think notification would get you quite far.
	
	Cheers Leif

---

From: Mark Smith <[email-masked]>
Date: Mon, 09 Nov 2009 10:06:07 -0500

> seen I think notification would get you quite far.

I believe that the line between some content synchronization scenarios 
and some event notification scenarios is blurry.  Picking up on your 
example, a metadirectory application may desire "real time" notification 
but will also need a way to learn about changes that occur while it is 
not connected to a directory.

-- 
Mark Smith
Pearl Crescent
http://pearlcrescent.com/

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 9 Nov 2009 07:37:01 -0800

On Nov 9, 2009, at 7:06 AM, Mark Smith wrote:

> I believe that the line between some content synchronization  
> scenarios and some event notification scenarios is blurry.

While I agree that the line between scenarios can be blurry, I do  
think it reasonable possible to categorize whether a mechanism is a  
general purpose content synchronization mechanism or a general purpose  
event notification mechanism.  The latter would typically include  
broad support for notification of events which didn't result in change  
the content(*) (such as non-update requests, failed update requests)  
and the former would not.

* While a failed operation might be recorded in the directory (such as  
in an audit log, or even in operational attributes of the target  
entry), failed operations are not (per directory specifications) alter  
directory content.  In categorize mechanisms, one should look only at  
truly "user application" content (content not maintained by the  
directory service).

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 9 Nov 2009 07:52:19 -0800

On Nov 9, 2009, at 7:37 AM, Kurt Zeilenga wrote:

> general purpose content synchronization mechanism or a general  
> purpose event notification mechanism.  The latter would typically  
> include broad support for notification of events which didn't result  
> in change the content(*) (such as non-update requests, failed update  
> requests) and the former would not.

Another difference is in the meta-information associated with content  
changes.   For instance, a general purpose content synchronization  
mechanism would on delete entry, generally not communicate anything  
more than fact that a particular entry was deleted from the content  
(likely not even including a precise indication of when the entry was  
deleted).  But a general purpose event notification system would  
likely communicate which particulars of request and result messages  
that caused entry to be deleted (including precisely when the request  
was received and when it was responded to), whom the requestor was,  
which session that requestor made the request in, etc.

>
> * While a failed operation might be recorded in the directory (such  
> as in an audit log, or even in operational attributes of the target  
> entry), failed operations are not (per directory specifications)  
> alter directory content.  In categorize mechanisms, one should look  
> only at truly "user application" content (content not maintained by  
> the directory service).
>
> -- Kurt

---

From: Leif Johansson <[email-masked]>
Date: Tue, 10 Nov 2009 01:45:56 +0100

> not connected to a directory.

It is indeed blurry but many metadirectory could be very happy with
doing its own diff on a directory entry based on a read operation on
the entry you just got notified on.

	Cheers Leif