Re: Requesting mailing list feedback for draft-dawkins-ldapext-subnot

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

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

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

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

>
> 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
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext