Subject: [ldapext] Requesting mailing list feedback for draft-dawkins-ldapext-subnot

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 26 Oct 2009 14:12:49 -0500

Hi, LDAPEXT Mailing list,

Some of you may be aware of a 3GPP CT4 proposal to add a subscribe/notify 
capability to LDAP. CT4 would like to use LDAP as the directory building 
block for "User Data Convergence", but the service description for this 
service includes asynchronous notifications about changes - so CT4 is 
exploring extending LDAP to provide subscribe/notify to support this UDC 
requirement.

I've been helping Xun Peng with a draft describing this extension, and 
Alexey is trying to determine whether this draft is appropriate for him to 
AD-sponsor. He pointed me to the LDAP Directorate, and we've gotten some 
helpful comments from them on the version 00 version of the draft. Kurt 
suggested that I post a revised draft to this mailing list, requesting your 
feedback.

The revised draft is available as
http://www.ietf.org/id/draft-dawkins-ldapext-subnot-01.txt.

We don't think the draft is perfect, and we're interested in any suggestions 
you may have for things we've missed. This is NOT a "must be accepted with 
no changes" Internet-Draft :D

The critical questions are

- whether the draft is an appropriate proposal for Alexey to AD-sponsor, and

- whether the draft is "close enough" to complete to allow it to be approved 
in the 3GPP Release 9 timeframe.

I am subscribed to this mailing list and will see your responses.

3GPP Release 9 should be completing in December 2009 - it's possible that 
there might be an exception for this work, but that would only be until 
March 2010 at the latest.

A note on timing - 3GPP CT4 is meeting the same week as IETF 76, and will be 
making a decision during that meeting on whether to use the approach 
described in this draft (and processed in the IETF) or to use an XML/SOAP 
alternative (not processed in the IETF). It would be extremely helpful to 
have your feedback before November 13 (when both IETF 76 and the CT4 meeting 
end).

I will be present in Hiroshima, and I believe I'm on the agenda for a few 
minutes at the Applications Area Open Meeting on Monday morning. I'm also 
available for any face-to-face discussions that would be helpful - but 
please feel free to express opinions before then!

Thanks,

Spencer

---

From: Howard Chu <[email-masked]>
Date: Mon, 26 Oct 2009 18:47:21 -0700

> I am subscribed to this mailing list and will see your responses.

I'm rather puzzled by this proposal; I don't see anything in it that isn't 
already accomplished using RFC4533. In your section 6 "Differences from 
Existing LDAP Sync Extensions" discussion I'm not really convinced of any of 
these points.

1) The only association between a client and a server is via an active LDAP 
session, so I don't understand this point.

2) OpenLDAP's implementation has no limitations as implied here. E.g. using 
delta-syncrepl you can already filter on exactly which types of changes you 
want to see.

3) I'm not sure this is true either. A client can send a ContentSync request 
with an empty cookie and reloadHint TRUE to obtain the current state of the 
server, then reissue a refreshAndPersist request with this cookie to proceed 
from there. There's no need to return all the data up front.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 26 Oct 2009 22:54:35 -0700

On Oct 26, 2009, at 12:12 PM, Spencer Dawkins wrote:

> Some of you may be aware of a 3GPP CT4 proposal to add a subscribe/ 
> notify capability to LDAP. CT4 would like to use LDAP as the  
> directory building block for "User Data Convergence", but the  
> service description for this service includes asynchronous  
> notifications about changes - so CT4 is exploring extending LDAP to  
> provide subscribe/notify to support this UDC requirement.

As a "user data convergence" mechanism, this mechanism seems to suffer  
from many of the problems we've seen in pre-LDAP Sync mechanisms.  For  
instance, it seems a client must request a full reload with each  
subscribe request (and not delay the start of notifications) in order  
to get convergence.

As a 'change (or event) notification' mechanism, I think it also has a  
number of problems.  I've tried to avoid bashing the current proposal  
as I first want to understand better the requirements.  Where I do  
bash, my intent is to tease out requirements.

It seems that a client wanting say "notification of password changes"  
can miss out on notifications due to a session disconnect?  While the  
client can request current values in the subsequent request, this  
isn't the same thing as providing notification of the password changes  
that occurred since the disconnect.  I bring this up as the  
requirements for "notification of changes" can be somewhat different,  
and often opposing, than those of "content sync".  It's not clear to  
me that it good idea for a mechanism to try to satisfy both  
"notification of changes" and "content synchronization" requirements.

I don't understand why there is a NotifyRestriction.notifyTo.   Why  
aren't the notifications just sent to the requestor?  It seems  
nonsensical to send the current values the requestor and the  
notifications to some other client.  And how does a DN identify a  
particular client?  If two clients simultaneously establish an  
authorization association of the same DN, do they both get copies of  
the notifications?  I don't understand how  
NotifyReceiver.attributeName would be used (by the way, text says "MAY  
designate" but attributeName is not OPTIONAL in the syntax), or how it  
would help distinguish a particular LDAP client.

I think it a really bad idea to have one client subscribe another.   
This raises all kinds of issues and, I think, should be avoided by  
designing the mechanism as providing service to the requestor, as with  
all other LDAP operations.

I don't understand why there is a NotifyRestriction.notifyStart.  Why  
doesn't the client just request the notification when it wants the  
notification to start.  Asking the server to start notifications at a  
particular time assumes that the client's and server's are adequately  
synchronized, such assumptions often lead to problems.  Also, it seems  
to imply that the server has to maintain information about the  
subscriptions beyond the lifetime of the requestor's session.

I don't understand why there is  
SubscribeReq.requestValue.notificationRefData?  Is this to correlate  
notices with a particular subscribe request?

>
> I've been helping Xun Peng with a draft describing this extension,  
> and Alexey is trying to determine whether this draft is appropriate  
> for him to AD-sponsor. He pointed me to the LDAP Directorate, and  
> we've gotten some helpful comments from them on the version 00  
> version of the draft. Kurt suggested that I post a revised draft to  
> this mailing list, requesting your feedback.
>
> We don't think the draft is perfect, and we're interested in any  
> suggestions you may have for things we've missed. This is NOT a  
> "must be accepted with no changes" Internet-Draft :D
>

At this point in time, I think it would be premature for Alexey to  
sponsor this I-D.  The I-D needs work, consensus needs to be built,  
etc.  If you want to publish "as is" (or nearly "as is") or anytime  
soon, I'd suggest submitting this on an independent basis on the  
Experimental track.

> - whether the draft is "close enough" to complete to allow it to be  
> approved in the 3GPP Release 9 timeframe.

I don't see the IETF moving terribly fast with this I-D, likely no  
faster than the norm for individual submissions (which I would guess  
would be 1+ years).

> 3GPP Release 9 should be completing in December 2009 - it's possible  
> that there might be an exception for this work, but that would only  
> be until March 2010 at the latest.
>
> A note on timing - 3GPP CT4 is meeting the same week as IETF 76, and  
> will be making a decision during that meeting on whether to use the  
> approach described in this draft (and processed in the IETF) or to  
> use an XML/SOAP alternative (not processed in the IETF). It would be  
> extremely helpful to have your feedback before November 13 (when  
> both IETF 76 and the CT4 meeting end).
>
> I will be present in Hiroshima, and I believe I'm on the agenda for  
> a few minutes at the Applications Area Open Meeting on Monday  
> morning. I'm also available for any face-to-face discussions that  
> would be helpful - but please feel free to express opinions before  
> then!
>
> Thanks,
>
> Spencer
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext