[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



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.

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.

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