[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] 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
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext