[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Objections to draft-ietf-ldapext-psearch-01.txt
Comments on ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapext-psearch-01.txt
1. Point to point registration and event distribution is not scalable; only channel-based approaches scale. This approach of LDAP persistent queries represents a dramatic over-simplification of the implementation constraints and requirements for large scale (internet scale) event notification systems. This persistent query approach is valid only for small-scale, synchronization systems.
2. Both theory and empirical evidence shows that network bandwidth is the first resource to be exhausted by a large scale event notification system. Without attribute-level filtering, the network will be clogged with useless notifications being sent just to be discarded at the LDAP client end.
3. Each active Persistent Search registration requires an open TCP connection. Even a single LDAP client with multiple active Persistent Searches will require as many open TCP connections as it has Persistent Searches. There are LDAP servers that have been tested with hundreds of connections; some may even support thousands of connections, but somewhere a practical number of simultaneous open connections "service ceiling" will be reached beyond which response times will be unacceptable. Dozens or hundreds of LDAP Persistent Search open TCP connections will adversely impact LDAP Server performance everywhere.
4. Rather than first defining an LDAP specific event notification mechanism, LDAP notification requirements should be fed into Event Notification BOF to be held at the Chicago IETF meeting. The suggested agenda for the BOF does not propose one solution for all problems, however it does express a desire to classify each of the problems to see if there is any room for some common effort that can be leveraged by many applications, services and/or protocols. Each applications group can then focus on defining the specific events and their semantics rather than reinventing notificaiton subsystems. For example, in the LDAP case, the LDAP extensions group can focus on defining what is an "add" or a "delete" or a "modify" event is and what additional info is needed in the event reports for these events rather than defining new notification infrastructure. At the WISEN conference (Workshop on Internet Scale Event Notification, July 13-14 1998, http://www.ics.uci.edu/IRUS/wisen/wisen.html) there seemed to be consensus that a common, scalable, infrastructure notification subsystem could be used for many applications, inlcuding directory events and notifications
Based on the above reasons, we don't believe that the LDAP community should adopt or promote the mechanism described for common use, much less forward it for consideration on any standards track. Instead, we believe work should go forward, as described in (4) above, with a more generally useful mechanism.
Best regards,
-------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861 3320