From hyc@highlandsun.com Tue Oct 13 18:13:18 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE7228C15C for ; Tue, 13 Oct 2009 18:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.004 X-Spam-Level: ** X-Spam-Status: No, score=2.004 tagged_above=-999 required=5 tests=[BAYES_50=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uvh18eP92XHN for ; Tue, 13 Oct 2009 18:13:16 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id C8DB728C13C for ; Tue, 13 Oct 2009 18:13:16 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id CE7BC10F8E; Tue, 13 Oct 2009 21:13:17 -0400 (EDT) Message-ID: <4AD525AD.2060505@highlandsun.com> Date: Tue, 13 Oct 2009 18:13:17 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.9.1.5pre) Gecko/20091012 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: x500standard@freelists.org, Ldapext References: <003201ca4829$14e1ecd0$3ea5c670$@eu> <4ACE4CBD.1050408@highlandsun.com> In-Reply-To: <4ACE4CBD.1050408@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] [x500standard] Password policy PDAM X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 01:13:18 -0000 Howard Chu wrote: > I'll followup later with another review in terms of the current LDAP ppolicy > draft. As David Chadwick suggested, it would be a good idea to align the names and OIDs of the policy elements that are semantically the same. Here's a comparison of where things stand right now. X.500 LDAP pwdAdminSubentryList/ pwdPolicySubentry pwdPolicySubentry The LDAP definition is single-valued; only one policy is allowed to apply to the password attribute of an entry. (But if multiple password attributes are in use, then each can have its own policy.) In LDAP if multiple policies have overlapping coverage the behavior is undefined. pwdAdminSubentry pwdPolicy myPwdAttribute pwdAttribute passwordHistory pwdHistory Currently it looks like these two are not compatible. recentlyExpiredPassword No analogue in LDAP spec. Could be added I guess. passwordHistoryMatch No analogue in LDAP, history just uses octetStringMatch. pwdStartTime pwdStartTime Basically the same, but X.500 pwdStartTime is also set whenever a password is changed. LDAP uses pwdChangedTime for this purpose. The reason for the distinction: an admin may decide to set a password on an account, but leave it disabled until some time in the future. The most common example use-case is in schools/universities - hundreds or thousands of accounts may be created in advance for an incoming class of students. Their pwdStartTime will be set to the first day of class, while their pwdChangedTime will reflect the time their password was actually created. pwdExpiryTime No analogue in LDAP. Could be added. pwdEndTime pwdEndTime Basically the same. We should adopt the X.500 description for the LDAP spec. pwdFails LDAP uses pwdFailureTime which records the timestamps of the failures, not just a count of the failures. gracesUsed LDAP uses pwdGraceUseTime which records the timestamps of each usage, not just a count. The LDAP spec has 3 more operational attributes that appear to be missing from the X.500 spec: pwdAccountLockedTime - the time that an account was locked. pwdReset - a boolean that indicates a user must change their password (e.g. because it was set by an administrator). pwdLastSuccess - the timestamp of the last successful authentication Policy schema: X.500 LDAP modifyEntryPwdAllowed No analogue in LDAP changePwdAllowed pwdAllowUserChange Basically the same pwdMaxAge Missing in LDAP. Adding it will be tricky since we already use a pwdMaxAge attribute, for expiration. pwdExpiryAge pwdMaxAge Basically the same meaning; LDAP is missing the ordering rule. minPwdLength pwdMinLength Basically the same. LDAP also has pwdMaxLength, as some systems only work with some small length (e.g. 8 or 16 on some legacy platforms). pwdVocabulary pwdAlphabet pwdDictionaries Missing in LDAP. Should consider adding them. pwdExpiryWarning pwdExpireWarning pwdGraces pwdGraceAuthNLimit pwdLockoutDuration pwdLockoutDuration pwdMaxFailures pwdMaxFailure Basically the same, besides choice of spelling. LDAP is missing the ordering rule. pwdFailureDuration pwdMinDelay LDAP also requires pwdMaxDelay if pwdMinDelay is set. pwdMaxTimeInHistory pwdMinTimeInHistory No analogue in LDAP, should consider adding it. pwdHistorySlots pwdInHistory Similar; LDAP doesn't specify a minimum value. Absence / 0 implies no history tracking. recentlyExpiredPwdDuration No analogue in LDAP. pwdEncryptionAlg No analogue in LDAP. Password hashing is implementation-specific. The LDAP spec also defines pwdMinAge, pwdCheckQuality, pwdGraceExpiry, pwdLockout, pwdFailureCountInterval, pwdMustChange, pwdSafeModify, pwdMaxIdle. Kurt Zeilenga's draft makes an argument against using pwdMinAge, we should consider dropping it from the LDAP spec and augmenting the history policy attributes instead. pwdCheckQuality would be superseded by pwdVocabulary, pwdAlphabet and pwdDictionaries. pwdGraceExpiry should probably be added to the X.500 spec; i.e. there should be some provision for aging out grace logins. pwdLockout simply controls whether failure-based lockouts will be enforced or not. pwdFailureCountInterval defines the number of seconds after which password failures are automatically purged, even though no successful authentication occurred. It's a bit of a bandaid to allow recovering from a failure lockout. pwdMustChange controls whether administrative password changes will require the user to change their password immediately on next login. pwdSafeModify controls whether the old password is required or not in a PasswordModify operation. pwdMaxIdle disables an account if it has not been logged into within the specified interval. It may be a good idea to add this to the X.500 spec. -- -- 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 ersin.er@gmail.com Wed Oct 14 04:14:12 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE603A6820 for ; Wed, 14 Oct 2009 04:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goMe6uFaOODG for ; Wed, 14 Oct 2009 04:14:11 -0700 (PDT) Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by core3.amsl.com (Postfix) with ESMTP id B12373A680F for ; Wed, 14 Oct 2009 04:14:11 -0700 (PDT) Received: by ywh27 with SMTP id 27so4021877ywh.31 for ; Wed, 14 Oct 2009 04:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=zega/OGOwGJCZR7Ecsr7adk4qsD8bzLmt9q2VBatGz4=; b=SbeqqhxuVHJYow95YoBEPGGUDSdYVW89n1SjfHYKmeWf3EZrTA1C0zgjVhXBFLH6F/ twOcCfDPMuRep3hrAAaiNs5rJO8NsAOjfvNfNPQfxWwmNlx+prN0Vha+8494u1SL9ag5 /7vhASbJpzzhQkGbA+S2wCVjrbqwiZTJ1rpxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dkUEl5GPcvQzepU4QkQngo0zYF31vOm7h4KIN4S5SaZ/xAWhkyKDQJkDxzaC565n2n gRoAj/D9EI2m1bk8JCunrzlOpaPZvrB5X7TYuAmkIqtns8V6ex6FIylpOMc2jr0BuMBZ k8SJS1+qxIfSU6PPDWcaLNAgogp0enOdM0PAI= MIME-Version: 1.0 Received: by 10.101.56.11 with SMTP id i11mr7169856ank.5.1255518851090; Wed, 14 Oct 2009 04:14:11 -0700 (PDT) Date: Wed, 14 Oct 2009 14:14:11 +0300 Message-ID: From: Ersin ER To: ldapext@ietf.org Content-Type: multipart/alternative; boundary=001636ed6a6320cc830475e3433a Subject: [ldapext] Status of X.500 based Access Control for LDAP X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:14:32 -0000 --001636ed6a6320cc830475e3433a Content-Type: text/plain; charset=UTF-8 Hi, May I please learn the status of X.500 based Access Control for LDAP? Is there anybody working on it, any drafts? At Apache Directory Project we already have a working subsystem which is almost identical to the one in the X.501 (2005) spec. So I (and my colleagues) would like to initiate or contribute to such a work. Any pointers or more detailed information are welcome. Regards, -- Ersin ER http://people.apache.org/~ersiner/ --001636ed6a6320cc830475e3433a Content-Type: text/html; charset=UTF-8 Hi,

May I please learn the status of X.500 based Access Control for LDAP? Is there anybody working on it, any drafts?

At Apache Directory Project we already have a working subsystem which is almost identical to the one in the X.501 (2005) spec. So I (and my colleagues) would like to initiate or contribute to such a work.

Any pointers or more detailed information are welcome.

Regards,

--
Ersin ER
http://people.apache.org/~ersiner/ --001636ed6a6320cc830475e3433a-- From steven.legg@eb2bcom.com Wed Oct 14 17:02:23 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F8F3A6968 for ; Wed, 14 Oct 2009 17:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQMxTMGNvDdI for ; Wed, 14 Oct 2009 17:02:22 -0700 (PDT) Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by core3.amsl.com (Postfix) with ESMTP id B15523A6872 for ; Wed, 14 Oct 2009 17:02:22 -0700 (PDT) Received: from eth3065.vic.adsl.internode.on.net ([150.101.156.248] helo=[192.168.1.182]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from ) id 1MyDnU-0006sp-9l; Thu, 15 Oct 2009 11:02:24 +1100 Message-ID: <4AD6668B.3040109@eb2bcom.com> Date: Thu, 15 Oct 2009 11:02:19 +1100 From: Steven Legg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ersin ER References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Cc: ldapext@ietf.org Subject: Re: [ldapext] Status of X.500 based Access Control for LDAP X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 00:02:23 -0000 Hi Ersin, Ersin ER wrote: > Hi, > > May I please learn the status of X.500 based Access Control for LDAP? Is > there anybody working on it, any drafts? I have three expired drafts relating to X.500 access control for LDAP: draft-legg-ldap-admin-03.txt draft-legg-ldap-acm-admin-04.txt draft-legg-ldap-acm-bac-04.txt You should still be able to find copies of them online, but if you have trouble finding them let me know and I'll send them to you. I think the drafts are complete with respect to X.501 (2005) but I would need to update the boilerplate before progressing them further. Also, Kurt Zeilenga wanted me to incorporate the content of RFC 3672 (Subentries in LDAP) into draft-legg-ldap-admin-xx.txt, but I haven't done that yet. Regards, Steven > > At Apache Directory Project we already have a working subsystem which is > almost identical to the one in the X.501 (2005) spec. So I (and my > colleagues) would like to initiate or contribute to such a work. > > Any pointers or more detailed information are welcome. > > Regards, > > -- > Ersin ER > http://people.apache.org/~ersiner/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From spencer@wonderhamster.org Mon Oct 26 12:12:53 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7DF3A68C9 for ; Mon, 26 Oct 2009 12:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox9UkJAMSuIR for ; Mon, 26 Oct 2009 12:12:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id B27D23A697C for ; Mon, 26 Oct 2009 12:12:51 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LqjVa-1MY67g0QTa-00djcm; Mon, 26 Oct 2009 15:12:57 -0400 Message-ID: From: "Spencer Dawkins" To: Date: Mon, 26 Oct 2009 14:12:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18cD7nOBW6rGh/6RZQp861Jalx2+V/7gzYnOET RJVyfFVhTBmXjU2bLAA1zLPwilvwkCf3YVNzJOK41S8CXYuCI0 fzJyvMtczcRGEXJJnksBvjQWGezHyhYnZeygHpJavI= Cc: Alexey Melnikov , Xun Peng Subject: [ldapext] Requesting mailing list feedback for draft-dawkins-ldapext-subnot X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:12:53 -0000 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 hyc@highlandsun.com Mon Oct 26 18:47:06 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7413A6818 for ; Mon, 26 Oct 2009 18:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=2.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtHUJSf+lRbC for ; Mon, 26 Oct 2009 18:47:05 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 0F7EA3A6896 for ; Mon, 26 Oct 2009 18:47:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id A732210DBA; Mon, 26 Oct 2009 21:47:18 -0400 (EDT) Message-ID: <4AE65129.3030806@highlandsun.com> Date: Mon, 26 Oct 2009 18:47:21 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.9.1.5pre) Gecko/20091025 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Spencer Dawkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , ldapext@ietf.org, Xun Peng Subject: Re: [ldapext] Requesting mailing list feedback for draft-dawkins-ldapext-subnot X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:47:06 -0000 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/ From Kurt.Zeilenga@Isode.com Mon Oct 26 22:54:49 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9300A3A69FA for ; Mon, 26 Oct 2009 22:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHlRZK2gJYuQ for ; Mon, 26 Oct 2009 22:54:48 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3BCC83A6830 for ; Mon, 26 Oct 2009 22:54:48 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 27 Oct 2009 05:55:00 +0000 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga X-Priority: 3 In-Reply-To: Date: Mon, 26 Oct 2009 22:54:35 -0700 Message-Id: References: To: Spencer Dawkins X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , ldapext@ietf.org, Xun Peng Subject: Re: [ldapext] Requesting mailing list feedback for draft-dawkins-ldapext-subnot X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 05:54:49 -0000 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