From leifj@it.su.se  Sun Nov  8 18:00:59 2009
Return-Path: <leifj@it.su.se>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4A83A6841 for <ldap-dir@core3.amsl.com>; Sun,  8 Nov 2009 18:00:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1x7Zru5zOlr for <ldap-dir@core3.amsl.com>; Sun,  8 Nov 2009 18:00:58 -0800 (PST)
Received: from smtp.su.se (smtp2.su.se [130.237.164.53]) by core3.amsl.com (Postfix) with ESMTP id 4CD603A67A8 for <ldap-dir@ietf.org>; Sun,  8 Nov 2009 18:00:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 836D981AB4; Mon,  9 Nov 2009 03:01:23 +0100 (CET)
X-Virus-Scanned: by amavisd-new at av-in.su.se
Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f3Kjf7tL+8hZ; Mon,  9 Nov 2009 03:01:23 +0100 (CET)
Received: from [133.93.19.61] (host-19-61.meeting.ietf.org [133.93.19.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTPSA id 119A3819F8; Mon,  9 Nov 2009 03:01:19 +0100 (CET)
Message-ID: <4AF777ED.1040206@it.su.se>
Date: Mon, 09 Nov 2009 03:01:17 +0100
From: Leif Johansson <leifj@it.su.se>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>,  Spencer Dawkins <spencer@wonderhamster.org>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com>
In-Reply-To: <4AD62F79.6090703@isode.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: LDAP Directorate <ldap-dir@ietf.org>, Lisa Dusseault <lisa.dusseault@gmail.com>, Xun Peng <xunpeng@huawei.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 02:00:59 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----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-----

From Kurt.Zeilenga@Isode.com  Sun Nov  8 23:26:12 2009
Return-Path: <Kurt.Zeilenga@Isode.com>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809A83A6B09 for <ldap-dir@core3.amsl.com>; Sun,  8 Nov 2009 23:26:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBWUMAcpVKFT for <ldap-dir@core3.amsl.com>; Sun,  8 Nov 2009 23:26:11 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 41DBC3A6B05 for <ldap-dir@ietf.org>; Sun,  8 Nov 2009 23:26:11 -0800 (PST)
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SvfEKgAJmWmf@rufus.isode.com>; Mon, 9 Nov 2009 07:26:36 +0000
X-SMTP-Protocol-Errors: NORDNS
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
In-Reply-To: <4AF777ED.1040206@it.su.se>
Date: Sun, 8 Nov 2009 23:25:56 -0800
Message-Id: <EA6268A4-29F1-488B-87FB-C07C042F1C2A@Isode.com>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <4AF777ED.1040206@it.su.se>
To: Leif Johansson <leifj@it.su.se>
X-Mailer: Apple Mail (2.1076)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Cc: Lisa Dusseault <lisa.dusseault@gmail.com>, LDAP Directorate <ldap-dir@ietf.org>, Spencer Dawkins <spencer@wonderhamster.org>, Xun Peng <xunpeng@huawei.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 07:26:12 -0000

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>
>
> 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
> -----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
> Ldap-dir@ietf.org
> https://www.ietf.org/mailman/listinfo/ldap-dir


From leifj@sunet.se  Sun Nov  8 23:42:55 2009
Return-Path: <leifj@sunet.se>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAEE3A6B12 for <ldap-dir@core3.amsl.com>; Sun,  8 Nov 2009 23:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuTuL7R-1mr5 for <ldap-dir@core3.amsl.com>; Sun,  8 Nov 2009 23:42:54 -0800 (PST)
Received: from smtp.su.se (smtp2.su.se [130.237.164.53]) by core3.amsl.com (Postfix) with ESMTP id 4D9603A6B13 for <ldap-dir@ietf.org>; Sun,  8 Nov 2009 23:42:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 4DFB18198B; Mon,  9 Nov 2009 08:43:19 +0100 (CET)
X-Virus-Scanned: by amavisd-new at av-in.su.se
Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FKO8NNZoqVYN; Mon,  9 Nov 2009 08:43:18 +0100 (CET)
Received: from [133.93.19.61] (host-19-61.meeting.ietf.org [133.93.19.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTPSA id A3A518197C; Mon,  9 Nov 2009 08:43:16 +0100 (CET)
Message-ID: <4AF7C809.6040001@sunet.se>
Date: Mon, 09 Nov 2009 08:43:05 +0100
From: Leif Johansson <leifj@sunet.se>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com>	<4AD62F79.6090703@isode.com> <4AF777ED.1040206@it.su.se> <EA6268A4-29F1-488B-87FB-C07C042F1C2A@Isode.com>
In-Reply-To: <EA6268A4-29F1-488B-87FB-C07C042F1C2A@Isode.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Spencer Dawkins <spencer@wonderhamster.org>, Leif Johansson <leifj@it.su.se>, LDAP Directorate <ldap-dir@ietf.org>, Lisa Dusseault <lisa.dusseault@gmail.com>, Xun Peng <xunpeng@huawei.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 07:42:55 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kurt Zeilenga wrote:
> 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.

Right.

> 
> 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.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr3yAkACgkQ8Jx8FtbMZnc3lwCeK7WTG9Eu3wkjYCvA0rQfa0NG
v30An13z3SUDY7eV2m7Bp4m9mc9Xj+uL
=Ia1J
-----END PGP SIGNATURE-----

From mcs@pearlcrescent.com  Mon Nov  9 07:05:43 2009
Return-Path: <mcs@pearlcrescent.com>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D484F3A687D for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 07:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUPtLA-3uPfE for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 07:05:42 -0800 (PST)
Received: from randymail-a5.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id EC5EF3A6838 for <ldap-dir@ietf.org>; Mon,  9 Nov 2009 07:05:42 -0800 (PST)
Received: from [192.168.1.31] (c-98-224-231-76.hsd1.mi.comcast.net [98.224.231.76]) by randymail-a5.g.dreamhost.com (Postfix) with ESMTP id 4E5E78EFE3; Mon,  9 Nov 2009 07:06:07 -0800 (PST)
Message-ID: <4AF82FDF.1050704@pearlcrescent.com>
Date: Mon, 09 Nov 2009 10:06:07 -0500
From: Mark Smith <mcs@pearlcrescent.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Leif Johansson <leifj@sunet.se>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com>	<4AD62F79.6090703@isode.com>	<4AF777ED.1040206@it.su.se>	<EA6268A4-29F1-488B-87FB-C07C042F1C2A@Isode.com> <4AF7C809.6040001@sunet.se>
In-Reply-To: <4AF7C809.6040001@sunet.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, LDAP Directorate <ldap-dir@ietf.org>, Spencer Dawkins <spencer@wonderhamster.org>, Lisa Dusseault <lisa.dusseault@gmail.com>, Leif Johansson <leifj@it.su.se>, Xun Peng <xunpeng@huawei.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for	draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 15:05:43 -0000

Leif Johansson wrote:
>> 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.

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@Isode.com  Mon Nov  9 07:37:19 2009
Return-Path: <Kurt.Zeilenga@Isode.com>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF3928C145 for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 07:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level: 
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWBU3ItzjzcK for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 07:37:19 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C2C3728C13A for <ldap-dir@ietf.org>; Mon,  9 Nov 2009 07:37:18 -0800 (PST)
Received: from [192.168.1.101] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <Svg3QgAJmYOT@rufus.isode.com>; Mon, 9 Nov 2009 15:37:44 +0000
X-SMTP-Protocol-Errors: NORDNS
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
In-Reply-To: <4AF82FDF.1050704@pearlcrescent.com>
Date: Mon, 9 Nov 2009 07:37:01 -0800
Message-Id: <245FDEAF-ABA7-42BF-B048-F466F60BB7D2@Isode.com>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <4AF777ED.1040206@it.su.se> <EA6268A4-29F1-488B-87FB-C07C042F1C2A@Isode.com> <4AF7C809.6040001@sunet.se> <4AF82FDF.1050704@pearlcrescent.com>
To: Mark Smith <mcs@pearlcrescent.com>
X-Mailer: Apple Mail (2.1076)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Cc: Spencer Dawkins <spencer@wonderhamster.org>, LDAP Directorate <ldap-dir@ietf.org>, Lisa Dusseault <lisa.dusseault@gmail.com>, Leif Johansson <leifj@it.su.se>, Xun Peng <xunpeng@huawei.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 15:37:19 -0000

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@Isode.com  Mon Nov  9 07:52:34 2009
Return-Path: <Kurt.Zeilenga@Isode.com>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C9E3A6821 for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 07:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrFryGgZDd36 for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 07:52:33 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3C3883A67E2 for <ldap-dir@ietf.org>; Mon,  9 Nov 2009 07:52:33 -0800 (PST)
Received: from [192.168.1.101] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <Svg62QAJmR5m@rufus.isode.com>; Mon, 9 Nov 2009 15:52:58 +0000
X-SMTP-Protocol-Errors: NORDNS
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
In-Reply-To: <245FDEAF-ABA7-42BF-B048-F466F60BB7D2@Isode.com>
Date: Mon, 9 Nov 2009 07:52:19 -0800
Message-Id: <ABD1453C-ECD4-4BFB-96CE-5261C745F626@Isode.com>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <4AF777ED.1040206@it.su.se> <EA6268A4-29F1-488B-87FB-C07C042F1C2A@Isode.com> <4AF7C809.6040001@sunet.se> <4AF82FDF.1050704@pearlcrescent.com> <245FDEAF-ABA7-42BF-B048-F466F60BB7D2@Isode.com>
To: Mark Smith <mcs@pearlcrescent.com>
X-Mailer: Apple Mail (2.1076)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Cc: Lisa Dusseault <lisa.dusseault@gmail.com>, Leif Johansson <leifj@it.su.se>, LDAP Directorate <ldap-dir@ietf.org>, Spencer Dawkins <spencer@wonderhamster.org>, Xun Peng <xunpeng@huawei.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 15:52:34 -0000

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

>
> 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.

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
> _______________________________________________
> Ldap-dir mailing list
> Ldap-dir@ietf.org
> https://www.ietf.org/mailman/listinfo/ldap-dir


From leifj@sunet.se  Mon Nov  9 16:46:06 2009
Return-Path: <leifj@sunet.se>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FC73A68AE for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 16:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeTY4dJ4fRlW for <ldap-dir@core3.amsl.com>; Mon,  9 Nov 2009 16:46:05 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by core3.amsl.com (Postfix) with ESMTP id 45CF43A63EB for <ldap-dir@ietf.org>; Mon,  9 Nov 2009 16:46:04 -0800 (PST)
Received: from [133.93.19.61] (host-19-61.meeting.ietf.org [133.93.19.61]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id nAA0jrNR006505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 01:45:57 +0100 (CET)
Message-ID: <4AF8B7C4.9040707@sunet.se>
Date: Tue, 10 Nov 2009 01:45:56 +0100
From: Leif Johansson <leifj@sunet.se>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Mark Smith <mcs@pearlcrescent.com>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com>	<4AD62F79.6090703@isode.com>	<4AF777ED.1040206@it.su.se>	<EA6268A4-29F1-488B-87FB-C07C042F1C2A@Isode.com> <4AF7C809.6040001@sunet.se> <4AF82FDF.1050704@pearlcrescent.com>
In-Reply-To: <4AF82FDF.1050704@pearlcrescent.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, LDAP Directorate <ldap-dir@ietf.org>, Spencer Dawkins <spencer@wonderhamster.org>, Lisa Dusseault <lisa.dusseault@gmail.com>, Leif Johansson <leifj@it.su.se>, Xun Peng <xunpeng@huawei.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for	draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 00:46:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Smith wrote:
> Leif Johansson wrote:
>>> 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.
> 
> 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.
> 

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr4t8QACgkQ8Jx8FtbMZnfrSQCfb2v5nvtJ6DeUcoE5cwp5DFQJ
7kwAnjoGpV3tusAwDrHX69518Wv1GtSx
=2a/S
-----END PGP SIGNATURE-----