From owner-ietf-ldup@mail.imc.org Thu May 1 16:17:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07503 for ; Thu, 1 May 2003 16:17:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JpBi2077573 for ; Thu, 1 May 2003 12:51:11 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41JpBrm077572 for ietf-ldup-bks; Thu, 1 May 2003 12:51:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JpAi2077567 for ; Thu, 1 May 2003 12:51:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h41JpB9a027930 for ; Thu, 1 May 2003 19:51:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030501124623.023bf390@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 01 May 2003 12:48:46 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP and eventual convergence Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In http://www.imc.org/ietf-ldup/mail-archive/msg01612.html, the chairs declared WG consensus: The server needs to be required to generate the set of events necessary for eventual convergence of the client's copy of the DIT fragment. I haven't been able to find where draft-ietf-ldup-lcup mandates that servers generate the set of events necessary for eventual convergence (or, if not possible, return an error). I would have expected to find such a statement in the introductory portions of the document as well as in 4.3.7. Kurt From owner-ietf-ldup@mail.imc.org Thu May 1 16:29:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08975 for ; Thu, 1 May 2003 16:29:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41KQxi2078644 for ; Thu, 1 May 2003 13:26:59 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41KQxY9078643 for ietf-ldup-bks; Thu, 1 May 2003 13:26:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41KQvi2078635 for ; Thu, 1 May 2003 13:26:57 -0700 (PDT) (envelope-from richm@netscape.com) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h41KQnE06358 for ; Thu, 1 May 2003 13:26:50 -0700 (PDT) Received: from netscape.com ([10.169.192.57]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HE861T00.VOI; Thu, 1 May 2003 13:25:05 -0700 Message-ID: <3EB18280.8010103@netscape.com> Date: Thu, 01 May 2003 14:24:32 -0600 From: richm@netscape.com (Rich Megginson) Reply-To: rmegginson0224@aol.com Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldup@imc.org Subject: Re: LCUP and eventual convergence References: <5.2.0.9.0.20030501124623.023bf390@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090004000804000505000809" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090004000804000505000809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is the relevant text from lcup 05: > If at any time during an LCUP search, either during the sync phase or > the persist phase, the server determines that it cannot guarantee that > it can bring the client's copy of the data to eventual convergence, it > SHOULD immediately terminate the LCUP search request and return a > SearchResultDone message with a resultCode of lcupReloadRequired. > This can also happen at the beginning of an incremental > synchronization request, if the client presents a cookie that is out > of date or otherwise unable to be processed. The client should then > issue an initial synchronization request. Note that this implies that the server DOES generate the set of events necessary for eventual client convergence, either though LCUP update responses or by notifying the client that a reload is required. Kurt D. Zeilenga wrote: >In http://www.imc.org/ietf-ldup/mail-archive/msg01612.html, >the chairs declared WG consensus: > > The server needs to be required to generate the set of > events necessary for eventual convergence of the client's > copy of the DIT fragment. > >I haven't been able to find where draft-ietf-ldup-lcup >mandates that servers generate the set of events necessary >for eventual convergence (or, if not possible, return an error). >I would have expected to find such a statement in the >introductory portions of the document as well as in 4.3.7. > If the current LCUP wording is not sufficient to convey this mandate, then may I ask for a suggestion of how to reword it? > >Kurt > > > --------------ms090004000804000505000809 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb 0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm 86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6 VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN 5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw +Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx +OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MDEy MDI0MzJaMCMGCSqGSIb3DQEJBDEWBBQQFC31gK86uNYHn5lF04WASqHj8DBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAELFK Ty0jnoo/LjCZg1JG+2DLwTk/uVvFp0OeujQ3EyrpEc3pMGRuB/QqzNAppnbhAOHZgCvf/1ku S41ROiBwNeVGq0E1QqewzGnBv51I0N4osgxPw39DmvhCjgzK7xnn4n+/AZCTsfBbCtk7zgS5 UyadCEtlQ/omGRxnYtKA/EcAAAAAAAA= --------------ms090004000804000505000809-- From owner-ietf-ldup@mail.imc.org Thu May 1 17:58:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13970 for ; Thu, 1 May 2003 17:58:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LvFi2081654 for ; Thu, 1 May 2003 14:57:15 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41LvFKh081653 for ietf-ldup-bks; Thu, 1 May 2003 14:57:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LvEi2081648 for ; Thu, 1 May 2003 14:57:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h41LvE9a028834; Thu, 1 May 2003 21:57:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030501143956.024ffef8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 01 May 2003 14:54:49 -0700 To: rmegginson0224@aol.com From: "Kurt D. Zeilenga" Subject: Re: LCUP and eventual convergence Cc: ietf-ldup@imc.org In-Reply-To: <3EB18280.8010103@netscape.com> References: <5.2.0.9.0.20030501124623.023bf390@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:24 PM 5/1/2003, Rich Megginson wrote: >If the current LCUP wording is not sufficient to convey this mandate, then may I ask for a suggestion of how to reword it? In response to an LCUP request, the server SHALL either: a) generate the sequence of messages necessary for eventual convergence of the client's copy of the content to the server's copy of the content, b) indicate that a reload is required by returning lcupReloadRequired, or c) return an resultCode other than success or lcupReloadRequired. Kurt From owner-ietf-ldup@mail.imc.org Mon May 5 22:24:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24771 for ; Mon, 5 May 2003 22:24:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h461vui2017902 for ; Mon, 5 May 2003 18:57:56 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h461vus3017901 for ietf-ldup-bks; Mon, 5 May 2003 18:57:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h461vti2017896 for ; Mon, 5 May 2003 18:57:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h461vvc6003639 for ; Tue, 6 May 2003 01:57:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030505172911.02bb17e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 05 May 2003 18:55:28 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP applicability Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LCUP's applicability statement, I think, needs a bit of work. The "will work best" phrase, I find a bit odd, seems these are more "design assumptions". Anyways... The first item implies that LCUP "works" when the server maintains no historical information. It should be clear, that without historical information, the server can only determine that change occurred since the time indicated by the cookie, not what that change was. Hence, only if there were no changes in the context, the could the server could respond successfully. In any change occurred in the context, the server would have to fail with lcupReloadRequired. The second item says the client is not assumed to understand the "physical information model" implemented by the server, however it provides as instances of the physical model "virtual attributes, operational attributes, [and]subentries". I think the authors meant LCUP assumes only knowledge of the "directory user information model" [X.501(93)]. Anyways, I think LCUP does require the client to understand directory administrative and operational models in certain areas. For example, as LCUP doesn't support alias dereferencing during searching, a user client desiring aliases objects has to understand alias objects. I assume it does so to reduce complexity. There are other cases where assuming or requiring client knowledge of aspects of select administrative and operational models would significant reduce complexity and/or chattiness. With regard to the third item, I think LCUP has significant problems dealing with a number of everyday DIT update situations and forces full reloads far too frequently. I'll post a more detailed discussion of this in a separate message at a later time. Kurt From owner-ietf-ldup@mail.imc.org Tue May 6 07:49:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15600 for ; Tue, 6 May 2003 07:49:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Bhoi2066517 for ; Tue, 6 May 2003 04:43:50 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46BhoGa066516 for ietf-ldup-bks; Tue, 6 May 2003 04:43:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Bhni2066511 for ; Tue, 6 May 2003 04:43:49 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15124; Tue, 6 May 2003 07:40:52 -0400 (EDT) Message-Id: <200305061140.HAA15124@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldup-harmful-00.txt Date: Tue, 06 May 2003 07:40:51 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Multi-master Replication Considered Harmful Author(s) : K. Zeilenga Filename : draft-zeilenga-ldup-harmful-00.txt Pages : 7 Date : 2003-5-5 Over the last few years there has been significant development of Lightweight Directory Access Protocol (LDAP) replication mechansisms supporting a multi-master service model. While multi-master replication may be useful in some situations, the deployment of multi-master replication replication alters the LDAP service model in a manner which can be harmful. This memo discusses the LDAP service model, how multi-master replication alters the service model, and how this alternation is harmful to existing directory applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-harmful-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldup-harmful-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldup-harmful-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-5145743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldup-harmful-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldup-harmful-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5145743.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue May 6 10:40:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24609 for ; Tue, 6 May 2003 10:40:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46EXCi2079938 for ; Tue, 6 May 2003 07:33:12 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46EXCAn079937 for ietf-ldup-bks; Tue, 6 May 2003 07:33:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46EXBi2079929 for ; Tue, 6 May 2003 07:33:11 -0700 (PDT) (envelope-from mcgarvey@us.ibm.com) Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46EX7Yp262708 for ; Tue, 6 May 2003 10:33:07 -0400 Received: from d03nm119.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46EX2da057092 for ; Tue, 6 May 2003 08:33:05 -0600 Importance: Normal Subject: draft-zeilenga-ldup-harmful-00.txt To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: John McGarvey Date: Tue, 6 May 2003 10:32:14 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/06/2003 08:33:05 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: IMHO, this draft takes a very extreme position, stated here: --------------------------------------------------- 6. Conclusions The X.500/LDAP information and service models does not support multi-master replication and cannot be altered to support multi-master replication without causing great harm. LDAP server developers should heed this implementation absolute imperative [RFC 2251, Section 3.3]. This document defines LDAP in terms of X.500 as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500(1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP ------------------------------------------------------ Multimaster deployments of LDAP are common. Yes, they can have the kind of deleterious effects Kurt describes. But they are widely used anyway, and do not cause "great harm". Multimaster deployments are necessary to provide a highly available writeable directory infrastructure, because a single master can crash, making the resulting directory service read-only until the server is recovered. We have to have highly available write support. Why do we not see "great harm" in the many existing multimaster deployments? Typically, this is because multiple masters are used in a failover configuration, so that only one master is active at a given time. This usage pattern can't guarantee that update collisions and a consequent breakage of the service model. First, when failover occurs, one master may not have replicated some recent updates, so that the newly active master could accept updates that conflict with not yet replicated ones. Second, and more seriously, failover could occur because of loss of a WAN connection, in which case one could have several masters active at the same time. Despite these risks, LDAP directories are widely deployed in multimaster configurations, because the consequences of losing write access are severe enough to justify the risk of collisions. Another reason "great harm" does not occur is because the usage examples from this draft are not representative of most LDAP operations. When an entry is updated, it is typically not to increment a counter or to create a value that must be unique directory-wide. These use cases are the exception rather than the rule, but there is good reason to support them as well. This can be done using an operations mastering control. The control would ensure that the change is made on a single authoritative master, or failed if that master is not available. Via this approach, reliable counters and uniqueness registries could be implemented in LDAP. Operations mastering does require code changes on the client side. This is as it should be, although it is not in formal compliance with the cited paragraph RFC 2251 section 3.3. We want clients to default to high availability behavior and not to operations mastering. John McGarvey IBM directory architect 919-877-4892 From owner-ietf-ldup@mail.imc.org Tue May 6 11:14:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25773 for ; Tue, 6 May 2003 11:14:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F5Ti2081504 for ; Tue, 6 May 2003 08:05:29 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46F5TUV081503 for ietf-ldup-bks; Tue, 6 May 2003 08:05:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F5Si2081497 for ; Tue, 6 May 2003 08:05:28 -0700 (PDT) (envelope-from richm@netscape.com) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h46F5KE29586 for ; Tue, 6 May 2003 08:05:20 -0700 (PDT) Received: from netscape.com ([10.169.192.60]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HEH0HS00.79J; Tue, 6 May 2003 08:03:28 -0700 Message-ID: <3EB7CEA1.2080100@netscape.com> Date: Tue, 06 May 2003 09:02:57 -0600 From: richm@netscape.com (Rich Megginson) Reply-To: rmegginson0224@aol.com Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldup@imc.org, mcs@netscape.com, olgan@yahoo-inc.com, jeffparh@windows.microsoft.com, richm@netscape.com Subject: Re: LCUP applicability References: <5.2.0.9.0.20030505172911.02bb17e0@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000509000705010707010201" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000509000705010707010201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >LCUP's applicability statement, I think, needs a bit of work. >The "will work best" phrase, I find a bit odd, seems these >are more "design assumptions". > I'm not sure what the difference is between an "applicability statement" and a "design assumption", but isn't that the whole point of the section anyway? To provide suggestions to implementers about what types of server and client applications are best suited for LCUP? I don't see a problem here. >Anyways... > >The first item implies that LCUP "works" when the server >maintains no historical information. It should be clear, >that without historical information, the server can only >determine that change occurred since the time indicated by >the cookie, not what that change was. Hence, only if there >were no changes in the context, the could the server could respond >successfully. In any change occurred in the context, the >server would have to fail with lcupReloadRequired. > Well, that is "working". Some definition of "working" is that the client does a full resync every time (or does nothing, if there is nothing to do). I think the statement in LCUP is pretty clear without going so far as to "bash potential implementers over the head with implementation details". No problem here. >The second item says the client is not assumed to understand >the "physical information model" implemented by the >server, however it provides as instances of the physical >model "virtual attributes, operational attributes, [and]subentries". I think the authors meant LCUP assumes >only knowledge of the "directory user information model" >[X.501(93)]. > I think the wording is pretty clear and easy to understand as it is. The document provides as instances those items to provide clarity within the context without requiring the reader of the document to refer to other documents just to get an idea of what is being referred to here. >Anyways, I think LCUP does require the >client to understand directory administrative and >operational models in certain areas. For example, as >LCUP doesn't support alias dereferencing during searching, >a user client desiring aliases objects has to understand >alias objects. > Right. This particular "exception to the rule" was discussed a long time by the LDAP community, and it was decided that this particular exception was worthy of inclusion in LCUP. >I assume it does so to reduce complexity. >There are other cases where assuming or requiring client >knowledge of aspects of select administrative and operational >models would significant reduce complexity and/or chattiness. > Then the implementer can either choose to accept LCUP with its "chattiness in certan cases" or reject LCUP in favor of another approach. No problem here. >With regard to the third item, I think LCUP has significant >problems dealing with a number of everyday DIT update >situations and forces full reloads far too frequently. > Those situations are explicitly listed in the LCUP document, and the document lists the reasons that LCUP chose to handle them in the way it did. No problem here. >I'll post a more detailed discussion of this in a separate >message at a later time. > I look forward to reading it. But what will be different than what we have already discussed at great length in the past? Have you found several other new situations that you didn't know about 2 months ago? The point is that implementers can choose to accept these conditions or not. At least they are explicitly spelled out in LCUP near the beginning. >Kurt > > > --------------ms000509000705010707010201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb 0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm 86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6 VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN 5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw +Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx +OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MDYx NTAyNTdaMCMGCSqGSIb3DQEJBDEWBBSIr9godifHRGi4NW2PUOwVoxULxDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGARbSQ Ez2HqvUKfV4iPlNFNaPkc60HA6QcHu29loE6M0GVj/0bHdfZuMzpr+EZ8MC+06MgZ8H1B/rp XgmU7r4cn2J0WkYoN+Qux9Uy6m11Kggst4FbJfqXhqMeXxWcyyzjjwyUp+BIwokhcx6DT56N jKauq4xRdzJzjJnnkdChsO8AAAAAAAA= --------------ms000509000705010707010201-- From owner-ietf-ldup@mail.imc.org Tue May 6 11:16:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25844 for ; Tue, 6 May 2003 11:16:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F6Ii2081530 for ; Tue, 6 May 2003 08:06:18 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46F6IjF081529 for ietf-ldup-bks; Tue, 6 May 2003 08:06:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F6Hi2081523 for ; Tue, 6 May 2003 08:06:17 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h46F6Hc6009901; Tue, 6 May 2003 15:06:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 08:03:48 -0700 To: John McGarvey From: "Kurt D. Zeilenga" Subject: Re: draft-zeilenga-ldup-harmful-00.txt Cc: ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:32 AM 5/6/2003, John McGarvey wrote: >IMHO, this draft takes a very extreme position, stated here: This draft only reiterates the position which RFC 2251 and X.501(93) took, and which LDAPBIS is presently taking. LDUP takes an extreme position that an extension to LDAP can alter the LDAP service model in ways which effect implementations not supporting the extension. Such proposals should not be treated as extensions, but as NEW protocols. Kurt From owner-ietf-ldup@mail.imc.org Tue May 6 12:46:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29012 for ; Tue, 6 May 2003 12:46:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GYOi2087663 for ; Tue, 6 May 2003 09:34:24 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46GYOAS087662 for ietf-ldup-bks; Tue, 6 May 2003 09:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GYMi2087650 for ; Tue, 6 May 2003 09:34:22 -0700 (PDT) (envelope-from skip.slone@lmco.com) Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.11.6p2/8.11.6) with ESMTP id h46GYKm23089; Tue, 6 May 2003 12:34:20 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1 #40646) id <0HEH003014P6YD@lmco.com>; Tue, 06 May 2003 12:34:18 -0400 (EDT) Received: from EMSS03I00.us.lmco.com ([141.240.31.211]) by lmco.com (PMDF V6.1-1 #40646) with ESMTP id <0HEH007ML4OZPT@lmco.com>; Tue, 06 May 2003 12:34:13 -0400 (EDT) Received: by EMSS03I00.us.lmco.com with Internet Mail Service (5.5.2653.19) id ; Tue, 06 May 2003 12:34:11 -0400 Content-return: allowed Date: Tue, 06 May 2003 12:34:04 -0400 From: "Slone, Skip" Subject: RE: draft-zeilenga-ldup-harmful-00.txt To: "'Kurt D. Zeilenga'" , John McGarvey Cc: ietf-ldup@imc.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I would say that the issue of whether multimaster replication is harmful or not remains an open question. In http://www.ietf.org/internet-drafts/draft-slone-ldap-x500-align-00.txt (summarizing the upcoming Proposed Draft Amendment (PDAM) on X.500/LDAP alignment) section 3.11, I wrote: The PDAM will also call for comments exploring whether the existing information model (X.501) requires modification in the presence of multi-master replication (it appears that it does not require modification) and whether the "otherStrategy" mechanism of the existing replication protocol (DISP) is sufficient to signal the use of external replication mechanisms such as LDAP changelog, LDIF, DSMLv2, or proprietary mechanisms. In the PDAM itself (which is in the process of being registered for ISO ballot), there are two editor's notes, which read: Editor's Note 9-1: National Bodies and Liaison Organizations are requested to provide comments on whether the existing DSE model can be used in the presence of multi-master replication without modifying the DSE model itself. Editor's Note 9-2: National Bodies and Liaison Organizations are requested to provide comments on whether the use of the DISP "otherStrategy" mechanism is appropriate for signaling the use of an external replication method such as DSML v2, LDAP changelog or LDIF. As best I can determine so far, the biggest impact to X.500 will be in the procedures associated with distributed operations and chaining. At present, a DSE can be of type "master" or "shadow". Note that the DSE model doesn't make a distinction between "a master" and "the master" -- simply "master". The accompanying procedures (X.518) check to determine is the DSE is of type "master" before processing modifications. What would be helpful to me is for another set of eyes to look at the procedures, the model, etc., in an attempt to determine the answers to the questions raised in the editor's notes. -- Skip -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, May 06, 2003 11:04 AM To: John McGarvey Cc: ietf-ldup@imc.org Subject: Re: draft-zeilenga-ldup-harmful-00.txt At 07:32 AM 5/6/2003, John McGarvey wrote: >IMHO, this draft takes a very extreme position, stated here: This draft only reiterates the position which RFC 2251 and X.501(93) took, and which LDAPBIS is presently taking. LDUP takes an extreme position that an extension to LDAP can alter the LDAP service model in ways which effect implementations not supporting the extension. Such proposals should not be treated as extensions, but as NEW protocols. Kurt From owner-ietf-ldup@mail.imc.org Tue May 6 12:55:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29224 for ; Tue, 6 May 2003 12:55:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GlOi2089852 for ; Tue, 6 May 2003 09:47:24 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46GlObC089851 for ietf-ldup-bks; Tue, 6 May 2003 09:47:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GlNi2089831 for ; Tue, 6 May 2003 09:47:23 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h46Gl8E14167 for ; Tue, 6 May 2003 09:47:08 -0700 (PDT) Received: from netscape.com ([10.169.192.97]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HEH5AN01.M6Z; Tue, 6 May 2003 09:47:11 -0700 Message-ID: <3EB7E709.30605@netscape.com> Date: Tue, 06 May 2003 12:47:05 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John McGarvey , ietf-ldup@imc.org Subject: Re: draft-zeilenga-ldup-harmful-00.txt References: <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > At 07:32 AM 5/6/2003, John McGarvey wrote: > >>IMHO, this draft takes a very extreme position, stated here: > > > This draft only reiterates the position which RFC 2251 and > X.501(93) took, and which LDAPBIS is presently taking. LDUP > takes an extreme position that an extension to LDAP can alter > the LDAP service model in ways which effect implementations > not supporting the extension. Such proposals should not be > treated as extensions, but as NEW protocols. I disagree. And like John, I also disagree with this text from draft-zeilenga-ldup-harmful-00.txt: The X.500/LDAP information and service models does not support multi-master replication and cannot be altered to support multi-master replication without causing great harm. I do think it would be worthwhile for the LDUP documents to address the scenarios you spell out in your -harmful draft. John suggested some possible solutions, all of which have likely been used in one or more of the existing, widely deployed LDAP implementations that happen to support multimaster replication (MMR). The fact is, there is a lot of demand from customers/deployers for MMR. If the IETF does not define anything in this area, then the directory community will continue to have no common specification for MMR. And that will likely cause great harm to LDAP's future. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Tue May 6 13:19:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00105 for ; Tue, 6 May 2003 13:19:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46H7fi2092720 for ; Tue, 6 May 2003 10:07:41 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46H7eU8092719 for ietf-ldup-bks; Tue, 6 May 2003 10:07:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46H7di2092714 for ; Tue, 6 May 2003 10:07:39 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h46H7ec6010898; Tue, 6 May 2003 17:07:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030506094730.02c8e708@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 10:05:10 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: draft-zeilenga-ldup-harmful-00.txt Cc: John McGarvey , ietf-ldup@imc.org In-Reply-To: <3EB7E709.30605@netscape.com> References: <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:47 AM 5/6/2003, Mark C Smith wrote: >Kurt D. Zeilenga wrote: > >>At 07:32 AM 5/6/2003, John McGarvey wrote: >> >>>IMHO, this draft takes a very extreme position, stated here: >> >>This draft only reiterates the position which RFC 2251 and >>X.501(93) took, and which LDAPBIS is presently taking. LDUP >>takes an extreme position that an extension to LDAP can alter >>the LDAP service model in ways which effect implementations >>not supporting the extension. Such proposals should not be >>treated as extensions, but as NEW protocols. > >I disagree. And like John, I also disagree with this text from draft-zeilenga-ldup-harmful-00.txt: > > The X.500/LDAP information and service models does not support > multi-master replication and cannot be altered to support multi-master > replication without causing great harm. CI assume you are disagreeing with the latter portion of sentence as clearly the X.500/LDAP information and service models do not support multi-master replication. John suggests changing the service model. I argue that this will cause great harm. It certainly will break any application which relies on this aspect of the LDAP/X.500 service model. >I do think it would be worthwhile for the LDUP documents to address the scenarios you spell out in your -harmful draft. John suggested some possible solutions, all of which have likely been used in one or more of the existing, widely deployed LDAP implementations that happen to support multimaster replication (MMR). Again, John suggests changing the LDAP service model. That, I believe, is beyond the scope of an LDAP extension and can only be done through revision of the LDAP "core" technical specification. >The fact is, there is a lot of demand from customers/deployers for MMR. There is lots of customer demand to maintain the current LDAP service model. There is also significant demand to expand that model to support LDAP Transactions. While I generally support extending LDAP to support new demands, I do not support doing so at the expense of those who rely on LDAP being implemented as currently specified. >If the IETF does not define anything in this area, then the directory community will continue to have no common specification for MMR. The IETF is not likely to define anything in this area that is workable. >And that will likely cause great harm to LDAP's future. LDAP is what it is. If the demands are not met by the current specification and cannot be met through appropriate extensions, then it's time to design a new protocol (LDAPv4?) with a service model that meets those demands. Kurt From owner-ietf-ldup@mail.imc.org Tue May 6 14:18:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01896 for ; Tue, 6 May 2003 14:18:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46I28i2094824 for ; Tue, 6 May 2003 11:02:08 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46I28Tr094823 for ietf-ldup-bks; Tue, 6 May 2003 11:02:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46I27i2094814 for ; Tue, 6 May 2003 11:02:07 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h46I1xE25384 for ; Tue, 6 May 2003 11:01:59 -0700 (PDT) Received: from netscape.com ([10.169.192.97]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HEH8RE01.E70; Tue, 6 May 2003 11:02:02 -0700 Message-ID: <3EB7F897.1090103@netscape.com> Date: Tue, 06 May 2003 14:01:59 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John McGarvey , ietf-ldup@imc.org Subject: Re: draft-zeilenga-ldup-harmful-00.txt References: <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> <5.2.0.9.0.20030506094730.02c8e708@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030506094730.02c8e708@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > >> The X.500/LDAP information and service models does not support >> multi-master replication and cannot be altered to support multi-master >> replication without causing great harm. > > > CI assume you are disagreeing with the latter portion of sentence > as clearly the X.500/LDAP information and service models do not > support multi-master replication. Yes, although I would say that the X.500/LDAP information and service models to have have explicit support for MMR. > John suggests changing the service model. I argue that this will > cause great harm. It certainly will break any application which > relies on this aspect of the LDAP/X.500 service model. I believe it is inevitable that there will be some pain associated with certain kinds of LDAP extensions (MMR, transactional support, etc.) But I think the pain is worth bearing in some cases in order to progress the state of the art. -Mark From owner-ietf-ldup@mail.imc.org Tue May 6 15:26:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05216 for ; Tue, 6 May 2003 15:26:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46JHYi2096878 for ; Tue, 6 May 2003 12:17:34 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46JHYir096875 for ietf-ldup-bks; Tue, 6 May 2003 12:17:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46JHXi2096870 for ; Tue, 6 May 2003 12:17:33 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h46JHXc6011713; Tue, 6 May 2003 19:17:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030506113949.02bb1ce0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 12:15:04 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: draft-zeilenga-ldup-harmful-00.txt Cc: John McGarvey , ietf-ldup@imc.org In-Reply-To: <3EB7F897.1090103@netscape.com> References: <5.2.0.9.0.20030506094730.02c8e708@127.0.0.1> <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> <5.2.0.9.0.20030506075053.02c4e758@127.0.0.1> <5.2.0.9.0.20030506094730.02c8e708@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:01 AM 5/6/2003, Mark C Smith wrote: >I believe it is inevitable that there will be some pain associated with certain kinds of LDAP extensions (MMR, transactional support, etc.) But I think the pain is worth bearing in some cases in order to progress the state of the art. There are certainly works which propose changes to the LDAP Models under the guise of an LDAP extension. However, I think we should lift this guise from all such proposals and treat them not as extension proposals but as protocol revision proposals. Kurt From owner-ietf-ldup@mail.imc.org Wed May 7 07:24:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24051 for ; Wed, 7 May 2003 07:24:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47BHJi2064701 for ; Wed, 7 May 2003 04:17:19 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47BHJ1v064700 for ietf-ldup-bks; Wed, 7 May 2003 04:17:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47BHHi2064692 for ; Wed, 7 May 2003 04:17:18 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23629; Wed, 7 May 2003 07:14:20 -0400 (EDT) Message-Id: <200305071114.HAA23629@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldup-sync-02.txt Date: Wed, 07 May 2003 07:14:20 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Content Synchronization Operation Author(s) : K. Zeilenga, J. Choi Filename : draft-zeilenga-ldup-sync-02.txt Pages : 25 Date : 2003-5-6 This specification describes the LDAP (Lightweight Directory Access Protocol) Content Synchronization operation. The operation allows a client to maintain a shadow copy of a fragment of directory information tree. It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldup-sync-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldup-sync-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-6153256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldup-sync-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldup-sync-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153256.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri May 16 12:05:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00892 for ; Fri, 16 May 2003 12:05:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFuVAF000387 for ; Fri, 16 May 2003 08:56:31 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4GFuV9p000386 for ietf-ldup-bks; Fri, 16 May 2003 08:56:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFuRAF000366 for ; Fri, 16 May 2003 08:56:30 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-74-134.delv.east.verizon.net [151.204.74.134]) by dns.caledonia.net; Fri, 16 May 2003 09:55:51 -0600 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: WG Charter Revision Approved Date: Fri, 16 May 2003 11:55:26 -0400 Organization: DSI-Consulting, Inc. Message-ID: <00ad01c31bc3$94e627f0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The IESG has approved our WG Charter. It has been updated on the IETF Web Site. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri May 16 12:12:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01098 for ; Fri, 16 May 2003 12:12:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GG9DAF001879 for ; Fri, 16 May 2003 09:09:13 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4GG9Duu001878 for ietf-ldup-bks; Fri, 16 May 2003 09:09:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GG9BAF001869 for ; Fri, 16 May 2003 09:09:12 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-74-134.delv.east.verizon.net [151.204.74.134]) by dns.caledonia.net; Fri, 16 May 2003 10:08:38 -0600 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" , "Ted Hardie" Subject: WG Charter Milestones Date: Fri, 16 May 2003 12:08:14 -0400 Organization: DSI-Consulting, Inc. Message-ID: <00ae01c31bc5$5e331860$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've noted that the revised WG charter contains misleading and confusing milestones. I'm not sure what happened based on inspecting the version actually submitted to the Apps Ads. I am working on getting them revised so that they are consistent with those contained in the charter revision sent to the Apps ADs. So for now, the charter text has been revised. The milestones are in a bit of a mess and don't really make a lot of sense when you look at them. If anyone needs a reminder of the timeline for concluding our work: http://www.imc.org/ietf-ldup/mail-archive/msg01732.html I also have spoken with Rick Huber about the Information Model document. The team pulling that revision together is a bit behind the estimated schedule contained in the posting linked to above. Rick has indicated that they should be publishing the revision relatively soon. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Wed May 21 11:42:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25570 for ; Wed, 21 May 2003 11:42:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LFYNAF036836 for ; Wed, 21 May 2003 08:34:23 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4LFYM9I036835 for ietf-ldup-bks; Wed, 21 May 2003 08:34:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LFYKAF036825 for ; Wed, 21 May 2003 08:34:21 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Wed, 21 May 2003 09:32:40 -0600 Reply-To: From: "Chris Apple" To: , Cc: "'John Strassner'" , "'Ted Hardie'" Subject: RE: WG Charter Milestones Date: Wed, 21 May 2003 11:32:42 -0400 Organization: DSI-Consulting, Inc. Message-ID: <009301c31fae$3ae4a760$3f00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <00ae01c31bc5$5e331860$6500a8c0@D7ST2111> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This issue has been resolved. The milestones now reflect those in the version reviewed by the IESG with one exception - it shows (accurately) that the LCUP document as been revised. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Friday, May 16, 2003 12:08 PM To: ietf-ldup@imc.org Cc: John Strassner; Ted Hardie Subject: WG Charter Milestones I've noted that the revised WG charter contains misleading and confusing milestones. I'm not sure what happened based on inspecting the version actually submitted to the Apps Ads. I am working on getting them revised so that they are consistent with those contained in the charter revision sent to the Apps ADs. So for now, the charter text has been revised. The milestones are in a bit of a mess and don't really make a lot of sense when you look at them. If anyone needs a reminder of the timeline for concluding our work: http://www.imc.org/ietf-ldup/mail-archive/msg01732.html I also have spoken with Rick Huber about the Information Model document. The team pulling that revision together is a bit behind the estimated schedule contained in the posting linked to above. Rick has indicated that they should be publishing the revision relatively soon. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Wed May 21 16:11:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07146 for ; Wed, 21 May 2003 16:11:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LK2lAF051805 for ; Wed, 21 May 2003 13:02:47 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4LK2lqI051804 for ietf-ldup-bks; Wed, 21 May 2003 13:02:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LK2jAF051799 for ; Wed, 21 May 2003 13:02:46 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Wed, 21 May 2003 14:01:42 -0600 Reply-To: From: "Chris Apple" To: Subject: WG Meeting Slot Requested for Vienna Date: Wed, 21 May 2003 16:02:00 -0400 Organization: DSI-Consulting, Inc. Message-ID: <004f01c31fd3$d8ea9a80$4000000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have requested a 1 hour meeting slot for LDUP in Vienna. I have also requested that the LDUP session be scheduled on the same (or at least an adjacent) day as LDAPBIS. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri May 23 12:18:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11227 for ; Fri, 23 May 2003 12:18:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NFtpAF027209 for ; Fri, 23 May 2003 08:55:51 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4NFtpqU027208 for ietf-ldup-bks; Fri, 23 May 2003 08:55:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NFtNAF027191 for ; Fri, 23 May 2003 08:55:45 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Fri, 23 May 2003 09:54:00 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: LCUP and eventual convergence Date: Fri, 23 May 2003 11:53:32 -0400 Organization: DSI-Consulting, Inc. Message-ID: <006501c32143$885a4a90$4000000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.0.9.0.20030501143956.024ffef8@127.0.0.1> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit As WG Co-Chair, I consider this issue to be resolved. Rich has pointed out in another posting associated with this thread that the existing language in the document actually does address the issue of eventual convergence. As WG Co-Chair, I am satisfied that the authors have reflected previously established WG Consensus on this issue. We can work through any word-smithing or clarification language during WG Last Call. The WG Last Call announcement on LCUP will be posted to the list over this coming weekend (perhaps even late today). Would do it now, but I'm en route and have limited time to stay connected. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Thursday, May 01, 2003 5:55 PM To: rmegginson0224@aol.com Cc: ietf-ldup@imc.org Subject: Re: LCUP and eventual convergence At 01:24 PM 5/1/2003, Rich Megginson wrote: >If the current LCUP wording is not sufficient to convey this mandate, then may I ask for a suggestion of how to reword it? In response to an LCUP request, the server SHALL either: a) generate the sequence of messages necessary for eventual convergence of the client's copy of the content to the server's copy of the content, b) indicate that a reload is required by returning lcupReloadRequired, or c) return an resultCode other than success or lcupReloadRequired. Kurt From owner-ietf-ldup@mail.imc.org Fri May 23 12:18:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11228 for ; Fri, 23 May 2003 12:18:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NG3mAF027410 for ; Fri, 23 May 2003 09:03:48 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4NG3mxb027409 for ietf-ldup-bks; Fri, 23 May 2003 09:03:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NG3YAF027390 for ; Fri, 23 May 2003 09:03:41 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Fri, 23 May 2003 10:02:00 -0600 Reply-To: From: "Chris Apple" To: , "'Kurt D. Zeilenga'" Cc: , , , Subject: RE: LCUP applicability Date: Fri, 23 May 2003 12:00:38 -0400 Organization: DSI-Consulting, Inc. MIME-Version: 1.0 Message-ID: <006a01c32144$a5fed560$4000000a@D7ST2111> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0066_01C32122.EC5CDF60" In-Reply-To: <3EB7CEA1.2080100@netscape.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C32122.EC5CDF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kurt, We'll be able to handle word-smithing during the WG Last Call for LCUP. However, with regard to this particular thread, I don't see support on the mailing list for your position that the applicability statement language is unclear. I therefore must conclude that the WG doesn't agree with your position and consider this particular issue closed unless reopened by other WG members during the upcoming LCUP WG Last Call. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Rich Megginson Sent: Tuesday, May 06, 2003 11:03 AM To: Kurt D. Zeilenga Cc: ietf-ldup@imc.org; mcs@netscape.com; olgan@yahoo-inc.com; jeffparh@windows.microsoft.com; richm@netscape.com Subject: Re: LCUP applicability Kurt D. Zeilenga wrote: >LCUP's applicability statement, I think, needs a bit of work. >The "will work best" phrase, I find a bit odd, seems these >are more "design assumptions". > I'm not sure what the difference is between an "applicability statement" and a "design assumption", but isn't that the whole point of the section anyway? To provide suggestions to implementers about what types of server and client applications are best suited for LCUP? I don't see a problem here. >Anyways... > >The first item implies that LCUP "works" when the server >maintains no historical information. It should be clear, >that without historical information, the server can only >determine that change occurred since the time indicated by >the cookie, not what that change was. Hence, only if there >were no changes in the context, the could the server could respond >successfully. In any change occurred in the context, the >server would have to fail with lcupReloadRequired. > Well, that is "working". Some definition of "working" is that the client does a full resync every time (or does nothing, if there is nothing to do). I think the statement in LCUP is pretty clear without going so far as to "bash potential implementers over the head with implementation details". No problem here. >The second item says the client is not assumed to understand >the "physical information model" implemented by the >server, however it provides as instances of the physical >model "virtual attributes, operational attributes, [and]subentries". I think the authors meant LCUP assumes >only knowledge of the "directory user information model" >[X.501(93)]. > I think the wording is pretty clear and easy to understand as it is. The document provides as instances those items to provide clarity within the context without requiring the reader of the document to refer to other documents just to get an idea of what is being referred to here. >Anyways, I think LCUP does require the >client to understand directory administrative and >operational models in certain areas. For example, as >LCUP doesn't support alias dereferencing during searching, >a user client desiring aliases objects has to understand >alias objects. > Right. This particular "exception to the rule" was discussed a long time by the LDAP community, and it was decided that this particular exception was worthy of inclusion in LCUP. >I assume it does so to reduce complexity. >There are other cases where assuming or requiring client >knowledge of aspects of select administrative and operational >models would significant reduce complexity and/or chattiness. > Then the implementer can either choose to accept LCUP with its "chattiness in certan cases" or reject LCUP in favor of another approach. No problem here. >With regard to the third item, I think LCUP has significant >problems dealing with a number of everyday DIT update >situations and forces full reloads far too frequently. > Those situations are explicitly listed in the LCUP document, and the document lists the reasons that LCUP chose to handle them in the way it did. No problem here. >I'll post a more detailed discussion of this in a separate >message at a later time. > I look forward to reading it. But what will be different than what we have already discussed at great length in the past? Have you found several other new situations that you didn't know about 2 months ago? The point is that implementers can choose to accept these conditions or not. At least they are explicitly spelled out in LCUP near the beginning. >Kurt > > > ------=_NextPart_000_0066_01C32122.EC5CDF60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII/TCCAoww ggH1oAMCAQICAwg0JjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAyMDkwMzIzNTYzMFoXDTAzMDkwMzIzNTYzMFowSzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEoMCYGCSqGSIb3DQEJARYZY2FwcGxlQGRzaS1jb25zdWx0aW5nLm5l dDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5v/gb+eh43xDeZjjhcjqoWsvgpK2WjqJyyLu huggCEIjY1LRQeOJ2Qe6AEYL+0EX7dSgKPuJqAEjI3+O7Gnp6zKxOtyrThNaWSc04fYkuEWAx6JR krRweLUkOCwcC6bVGdvKKPOrHOGnp8o4+sRO/0OFh2F+wjxU2EmIK3catM8CAwEAAaM2MDQwJAYD VR0RBB0wG4EZY2FwcGxlQGRzaS1jb25zdWx0aW5nLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAC5tuqEpG+7hYxRqI/1pRIIJXZbNhJ/dlh2Ma7uT0lBHta10t7OXx/MYqjy+1G6u vr0NffNtB9I8wOcedmw0M3ZtLXbqaTVSqlY6h2BwPPrBtEMvQUd5TjuC4RhVynW3v1Iw40lXunOr ZQQ0JDRzsf1ro4+boJLbTHJ602oLgiqwMIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoX DTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34Ul dSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr 2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0T AQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1 XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8 sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAzgwggKhoAMCAQIC EGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNV BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4z MqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN +kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5ud SWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB gQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3 Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjGCA2kwggNlAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAy MDAwLjguMzACAwg0JjAJBgUrDgMCGgUAoIICJDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wMzA1MjMxNjAwMzdaMCMGCSqGSIb3DQEJBDEWBBTs1CFvH6dl2+7CzbhP wAgIsg8qmDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB qwYJKwYBBAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl MRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNh dGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwg0 JjCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCDQmMA0GCSqGSIb3DQEBAQUABIGA4r+yrVH7dg9RVaQq45+irmjvLC8et7jBcBqt0BtHaa9p hiVEaN57cLHdFhMjyKhE21n4yMOZDb6ADKHZxrn7PM/+3xQhiva1UG9cFy9i8vZd+C2ndDdiE18h jQ+k3hFPJBbQc8qrKAKYo3aZTVTF/h6kaW2WanRY0t0g1FvNSs8AAAAAAAA= ------=_NextPart_000_0066_01C32122.EC5CDF60-- From owner-ietf-ldup@mail.imc.org Mon May 26 11:23:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16149 for ; Mon, 26 May 2003 11:23:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4QFEsAF073607 for ; Mon, 26 May 2003 08:14:54 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4QFErBS073602 for ietf-ldup-bks; Mon, 26 May 2003 08:14:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4QFElAF073594 for ; Mon, 26 May 2003 08:14:51 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4QFEhc6007270; Mon, 26 May 2003 15:14:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030526080049.02bc3ae8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 26 May 2003 08:10:55 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LDAP Client Update: consideration of alternative proposals Cc: "Chris Apple" , John Strassner Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The LDUP WG is chartered to deliver: o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. Over the last few years, the WG has engineering a technical solution for this deliverable. This solution is specified in the I-D draft-ietf-ldup-lcup. Over the last 9 months or so, Jong and I, acting on an individual basis, engineered a technical solution for this deliverable. This solution is specified in the I-D draft-zeilenga-ldup-sync. Each of these technical solutions are intended to fulfill this deliverable. I also believe both sets of authors believe that their approach best fulfills this deliverable. It is also likely many members of this WG have formed opinions as to which technical solution best fulfills this deliverable. However, it is unclear to me whether both I-D, in particular the most recent revisions of each, have been thoroughly considered by the WG. WG I-Ds are implicitly viewed as being under WG consideration and it hoped that significant number of WG members review the I-D as it evolves. Individual I-Ds are not necessarily viewed as being under WG consideration unless submitted to the WG for consideration by their authors. They generally are reviewed by few WG members until consideration is specifically requested. I now submit the draft-zeilenga-ldup-sync to the LDUP WG for consideration as a technical solution to its "LDAP Client Update" deliverable. I believe the latest revision, draft-zeilenga-ldup-sync-02.txt, is suitable for progression. I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync as technical alternatives and give thorough consideration to both. It is up to the WG to decide which solution is technically superior. As it is the function of the WG Chairs to manage the group process, I defer procedural questions and issues to Chris and John. As the differences between the approaches is fundamental in their design, it will be difficult to compare them without some basis to which can be measured against. It may be appropriate for the WG to examine what kinds of applications it intends its deliverable to be applicable to, what the requirements of these applications are, and how each of the technical alternatives measures up to these requirements. The WG should also consider broader issues, such as chattiness and security considerations. The WG should consider the appropriateness of the design and other constraints each places upon implementations. In regards to the WG milestone: May 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard I would like the WG to defer this WG Last Call until it has thoroughly consider both technical alternatives and reached a consensus as to which alternative it would like to pursue. Then that alternative should be prepared of WG Last Call as the WG's "LDAPv3 Client Update Protocol I-D". I believe it necessary to defer the WG Last Call as the WG first needs to thoroughly consider both alternatives. I'd like to say a key design difference which is a major factor in I considering draft-zeilenga-ldup-sync technically superior to draft-ietf-ldup-lcup. In attempting to implement draft-ietf-ldup-lcup, we found that requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes. We found that where the server only maintains simple state indicators such as timestamps, it cannot generally provide eventually convergent incremental refreshes. If the server maintains partial histories, the server will be limited in cases where it can provide eventually convergent incremental refreshes. In October 2002, the WG consensus was declared on an alternative approach (but later recanted). We implemented this approach and found that it allowed all of the above implementation variants to provide eventually convergent incremental refreshes. This was document in documented in early revisions of draft-zeilenga-ldup-sync. As a result of WG discussions about this approach, it was noted that this approach didn't allow servers to take advantage of histories they maintained. In our latest revision, we adopted a hybrid approach which allows servers to take advantage of histories they maintained. Hence, I believe draft-zeilenga-ldup-sync is technical superior in that it does not place significant implementation constraints in order to support eventually convergent incremental refreshes while allowing implementations take advantage of histories they maintain. There are, of course, many other factors in my consideration and I am quite willing to elaborate on these in subsequent discussions. Before doing so, I will await direction from the chairs on how to proceed with the consideration of the alternatives. Comments? Regards, Kurt From owner-ietf-ldup@mail.imc.org Mon May 26 11:50:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16673 for ; Mon, 26 May 2003 11:50:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4QFhtAF074472 for ; Mon, 26 May 2003 08:43:55 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4QFhtuK074471 for ietf-ldup-bks; Mon, 26 May 2003 08:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4QFhsAF074465 for ; Mon, 26 May 2003 08:43:54 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4QFhqc6007488; Mon, 26 May 2003 15:43:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030526083519.02b26850@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 26 May 2003 08:41:02 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LCUP and eventual convergence Cc: In-Reply-To: <006501c32143$885a4a90$4000000a@D7ST2111> References: <5.2.0.9.0.20030501143956.024ffef8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:53 AM 5/23/2003, Chris Apple wrote: >As WG Co-Chair, I consider this issue to be resolved. I content that the fundamental issues raised during the previous WG last call are not yet resolved. That is, I disagree that the editor of draft-ietf-ldup-lcup has adequately addressed these issues. >Rich has pointed out >in another posting associated with this thread that the existing language >in the document actually does address the issue of eventual convergence. >As WG Co-Chair, I am satisfied that the authors have reflected previously >established WG Consensus on this issue. > >We can work through any word-smithing or clarification language during >WG Last Call. > >The WG Last Call announcement on LCUP will be posted to the list over >this coming weekend (perhaps even late today). Would do it now, but I'm >en route and have limited time to stay connected. > > > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On >Behalf Of Kurt D. Zeilenga >Sent: Thursday, May 01, 2003 5:55 PM >To: rmegginson0224@aol.com >Cc: ietf-ldup@imc.org >Subject: Re: LCUP and eventual convergence > > > >At 01:24 PM 5/1/2003, Rich Megginson wrote: >>If the current LCUP wording is not sufficient to convey this mandate, then >may I ask for a suggestion of how to reword it? > > In response to an LCUP request, the server SHALL either: > a) generate the sequence of messages necessary for > eventual convergence of the client's copy of > the content to the server's copy of the content, > > b) indicate that a reload is required by returning > lcupReloadRequired, or > > c) return an resultCode other than success or > lcupReloadRequired. > >Kurt From owner-ietf-ldup@mail.imc.org Mon May 26 11:57:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16808 for ; Mon, 26 May 2003 11:57:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4QFr4AF074694 for ; Mon, 26 May 2003 08:53:04 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4QFr4Zu074693 for ietf-ldup-bks; Mon, 26 May 2003 08:53:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4QFr2AF074688 for ; Mon, 26 May 2003 08:53:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4QFqtc6007586; Mon, 26 May 2003 15:52:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030526084108.02bfc0a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 26 May 2003 08:50:05 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LCUP applicability Cc: , , , , In-Reply-To: <006a01c32144$a5fed560$4000000a@D7ST2111> References: <3EB7CEA1.2080100@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I content that the I-D has not been updated to discuss applicability. That is, it has been updated to discuss which applications are well suited to it and which are not, and why. The updates are mainly highlight implementation constraints, and while useful, are not quite the same thing. The applicability statement exercise purpose, I thought, was to focus some the problem both I-Ds report to solve and their suitability of each of the solutions. To that purpose, we still have a long way to go. Kurt At 09:00 AM 5/23/2003, Chris Apple wrote: >Kurt, > >We'll be able to handle word-smithing during the WG Last Call for LCUP. > >However, with regard to this particular thread, I don't see support on >the mailing list for your position that the applicability statement >language is unclear. > >I therefore must conclude that the WG doesn't agree with your position >and consider this particular issue closed unless reopened by other WG >members during the upcoming LCUP WG Last Call. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] >On Behalf Of Rich Megginson >Sent: Tuesday, May 06, 2003 11:03 AM >To: Kurt D. Zeilenga >Cc: ietf-ldup@imc.org; mcs@netscape.com; olgan@yahoo-inc.com; >jeffparh@windows.microsoft.com; richm@netscape.com >Subject: Re: LCUP applicability > > >Kurt D. Zeilenga wrote: > >>LCUP's applicability statement, I think, needs a bit of work. >>The "will work best" phrase, I find a bit odd, seems these >>are more "design assumptions". >> >I'm not sure what the difference is between an "applicability statement" >and a "design assumption", but isn't that the whole point of the section >anyway? To provide suggestions to implementers about what types of >server and client applications are best suited for LCUP? I don't see a >problem here. > >>Anyways... >> >>The first item implies that LCUP "works" when the server >>maintains no historical information. It should be clear, >>that without historical information, the server can only >>determine that change occurred since the time indicated by >>the cookie, not what that change was. Hence, only if there >>were no changes in the context, the could the server could respond >>successfully. In any change occurred in the context, the >>server would have to fail with lcupReloadRequired. >> >Well, that is "working". Some definition of "working" is that the >client does a full resync every time (or does nothing, if there is >nothing to do). I think the statement in LCUP is pretty clear without >going so far as to "bash potential implementers over the head with >implementation details". > >No problem here. > >>The second item says the client is not assumed to understand >>the "physical information model" implemented by the >>server, however it provides as instances of the physical >>model "virtual attributes, operational attributes, [and]subentries". I >think the authors meant LCUP assumes >>only knowledge of the "directory user information model" >>[X.501(93)]. >> >I think the wording is pretty clear and easy to understand as it is. > The document provides as instances those items to provide clarity >within the context without requiring the reader of the document to refer >to other documents just to get an idea of what is being referred to here. > >>Anyways, I think LCUP does require the >>client to understand directory administrative and >>operational models in certain areas. For example, as >>LCUP doesn't support alias dereferencing during searching, >>a user client desiring aliases objects has to understand >>alias objects. >> >Right. This particular "exception to the rule" was discussed a long >time by the LDAP community, and it was decided that this particular >exception was worthy of inclusion in LCUP. > >>I assume it does so to reduce complexity. >>There are other cases where assuming or requiring client >>knowledge of aspects of select administrative and operational >>models would significant reduce complexity and/or chattiness. >> >Then the implementer can either choose to accept LCUP with its >"chattiness in certan cases" or reject LCUP in favor of another approach. > >No problem here. > >>With regard to the third item, I think LCUP has significant >>problems dealing with a number of everyday DIT update >>situations and forces full reloads far too frequently. >> >Those situations are explicitly listed in the LCUP document, and the >document lists the reasons that LCUP chose to handle them in the way it >did. > >No problem here. > >>I'll post a more detailed discussion of this in a separate >>message at a later time. >> >I look forward to reading it. But what will be different than what we >have already discussed at great length in the past? Have you found >several other new situations that you didn't know about 2 months ago? > >The point is that implementers can choose to accept these conditions or >not. At least they are explicitly spelled out in LCUP near the beginning. > >>Kurt >> >> >> > From owner-ietf-ldup@mail.imc.org Mon May 26 20:59:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08796 for ; Mon, 26 May 2003 20:59:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4R0oWAF094293 for ; Mon, 26 May 2003 17:50:32 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4R0oWfB094292 for ietf-ldup-bks; Mon, 26 May 2003 17:50:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4R0oSAF094287 for ; Mon, 26 May 2003 17:50:31 -0700 (PDT) (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 May 2003 10:50:25 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Tue, 27 May 2003 10:50:24 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63811E395B@ausyms21.ca.com> Thread-Topic: LDAP Client Update: consideration of alternative proposals Thread-Index: AcMjmktbm4QucursTxiNS7d8OaW3cgAT1zzA From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 27 May 2003 00:50:25.0073 (UTC) FILETIME=[F5904210:01C323E9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4R0oVAF094288 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Just a procedural point: are there enough 'active' members left in this group to advance either document? (I am not active.) If the issues are debated only by the authors then I don't think either proposal should be advanced. Ron -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, 27 May 2003 01:11 To: ietf-ldup@imc.org Cc: Chris Apple; John Strassner Subject: LDAP Client Update: consideration of alternative proposals The LDUP WG is chartered to deliver: o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. Over the last few years, the WG has engineering a technical solution for this deliverable. This solution is specified in the I-D draft-ietf-ldup-lcup. Over the last 9 months or so, Jong and I, acting on an individual basis, engineered a technical solution for this deliverable. This solution is specified in the I-D draft-zeilenga-ldup-sync. Each of these technical solutions are intended to fulfill this deliverable. I also believe both sets of authors believe that their approach best fulfills this deliverable. It is also likely many members of this WG have formed opinions as to which technical solution best fulfills this deliverable. However, it is unclear to me whether both I-D, in particular the most recent revisions of each, have been thoroughly considered by the WG. WG I-Ds are implicitly viewed as being under WG consideration and it hoped that significant number of WG members review the I-D as it evolves. Individual I-Ds are not necessarily viewed as being under WG consideration unless submitted to the WG for consideration by their authors. They generally are reviewed by few WG members until consideration is specifically requested. I now submit the draft-zeilenga-ldup-sync to the LDUP WG for consideration as a technical solution to its "LDAP Client Update" deliverable. I believe the latest revision, draft-zeilenga-ldup-sync-02.txt, is suitable for progression. I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync as technical alternatives and give thorough consideration to both. It is up to the WG to decide which solution is technically superior. As it is the function of the WG Chairs to manage the group process, I defer procedural questions and issues to Chris and John. As the differences between the approaches is fundamental in their design, it will be difficult to compare them without some basis to which can be measured against. It may be appropriate for the WG to examine what kinds of applications it intends its deliverable to be applicable to, what the requirements of these applications are, and how each of the technical alternatives measures up to these requirements. The WG should also consider broader issues, such as chattiness and security considerations. The WG should consider the appropriateness of the design and other constraints each places upon implementations. In regards to the WG milestone: May 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard I would like the WG to defer this WG Last Call until it has thoroughly consider both technical alternatives and reached a consensus as to which alternative it would like to pursue. Then that alternative should be prepared of WG Last Call as the WG's "LDAPv3 Client Update Protocol I-D". I believe it necessary to defer the WG Last Call as the WG first needs to thoroughly consider both alternatives. I'd like to say a key design difference which is a major factor in I considering draft-zeilenga-ldup-sync technically superior to draft-ietf-ldup-lcup. In attempting to implement draft-ietf-ldup-lcup, we found that requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes. We found that where the server only maintains simple state indicators such as timestamps, it cannot generally provide eventually convergent incremental refreshes. If the server maintains partial histories, the server will be limited in cases where it can provide eventually convergent incremental refreshes. In October 2002, the WG consensus was declared on an alternative approach (but later recanted). We implemented this approach and found that it allowed all of the above implementation variants to provide eventually convergent incremental refreshes. This was document in documented in early revisions of draft-zeilenga-ldup-sync. As a result of WG discussions about this approach, it was noted that this approach didn't allow servers to take advantage of histories they maintained. In our latest revision, we adopted a hybrid approach which allows servers to take advantage of histories they maintained. Hence, I believe draft-zeilenga-ldup-sync is technical superior in that it does not place significant implementation constraints in order to support eventually convergent incremental refreshes while allowing implementations take advantage of histories they maintain. There are, of course, many other factors in my consideration and I am quite willing to elaborate on these in subsequent discussions. Before doing so, I will await direction from the chairs on how to proceed with the consideration of the alternatives. Comments? Regards, Kurt From owner-ietf-ldup@mail.imc.org Tue May 27 08:46:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10243 for ; Tue, 27 May 2003 08:46:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RCTEAF050221 for ; Tue, 27 May 2003 05:29:14 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4RCTEbq050220 for ietf-ldup-bks; Tue, 27 May 2003 05:29:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RCTCAF050204 for ; Tue, 27 May 2003 05:29:13 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-194-34.pskn.east.verizon.net [151.204.194.34]) by dns.caledonia.net; Tue, 27 May 2003 06:23:05 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: LCUP and eventual convergence Date: Tue, 27 May 2003 08:28:24 -0400 Organization: DSI-Consulting, Inc. Message-ID: <002001c3244b$79139720$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030526083519.02b26850@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4RCTEAF050215 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Objection noted. My position as Co-Chair is that your opinion is in the minority on this issue and therefore not consistent with the consensus view on this matter. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, May 26, 2003 11:41 AM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: RE: LCUP and eventual convergence At 08:53 AM 5/23/2003, Chris Apple wrote: >As WG Co-Chair, I consider this issue to be resolved. I content that the fundamental issues raised during the previous WG last call are not yet resolved. That is, I disagree that the editor of draft-ietf-ldup-lcup has adequately addressed these issues. >Rich has pointed out >in another posting associated with this thread that the existing language >in the document actually does address the issue of eventual convergence. >As WG Co-Chair, I am satisfied that the authors have reflected previously >established WG Consensus on this issue. > >We can work through any word-smithing or clarification language during >WG Last Call. > >The WG Last Call announcement on LCUP will be posted to the list over >this coming weekend (perhaps even late today). Would do it now, but I'm >en route and have limited time to stay connected. > > > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On >Behalf Of Kurt D. Zeilenga >Sent: Thursday, May 01, 2003 5:55 PM >To: rmegginson0224@aol.com >Cc: ietf-ldup@imc.org >Subject: Re: LCUP and eventual convergence > > > >At 01:24 PM 5/1/2003, Rich Megginson wrote: >>If the current LCUP wording is not sufficient to convey this mandate, then >may I ask for a suggestion of how to reword it? > > In response to an LCUP request, the server SHALL either: > a) generate the sequence of messages necessary for > eventual convergence of the client's copy of > the content to the server's copy of the content, > > b) indicate that a reload is required by returning > lcupReloadRequired, or > > c) return an resultCode other than success or > lcupReloadRequired. > >Kurt From owner-ietf-ldup@mail.imc.org Tue May 27 08:49:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10319 for ; Tue, 27 May 2003 08:49:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RCPDAF049969 for ; Tue, 27 May 2003 05:25:13 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4RCPDEr049968 for ietf-ldup-bks; Tue, 27 May 2003 05:25:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RCPBAF049963 for ; Tue, 27 May 2003 05:25:12 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-194-34.pskn.east.verizon.net [151.204.194.34]) by dns.caledonia.net; Tue, 27 May 2003 06:19:20 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" , Cc: "'John Strassner'" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Tue, 27 May 2003 08:24:37 -0400 Organization: DSI-Consulting, Inc. Message-ID: <001f01c3244a$f2d21560$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030526080049.02bc3ae8@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit WG Members should review the request Kurt has made. John and I will respond to the list on the procedure we'll use in considering Kurt's request, and if appropriate, acting on it. Kurt, There are a few major points I'd like to be sure I'm summarizing correctly before John and I respond on the procedural issue. You are requesting the following: 1) that the WG formally consider your individual contribution as an alternative to the existing WG deliverable for LDAPv3 Client Update Protocol. 2) that the WG evaluate both documents based on technical merit. 3) that the WG emerge from that evaluation process with a single document that will be processed through a WG Last Call and submitted to the Ads as the WG deliverable for LDAPv3 Client Update Protocol. 4) that the WG Last Call milestone for LCUP be rescheduled further out in time to accommodate the above. Did I miss any key points in your request? Do any of them need clarification? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, May 26, 2003 11:11 AM To: ietf-ldup@imc.org Cc: Chris Apple; John Strassner Subject: LDAP Client Update: consideration of alternative proposals The LDUP WG is chartered to deliver: o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. Over the last few years, the WG has engineering a technical solution for this deliverable. This solution is specified in the I-D draft-ietf-ldup-lcup. Over the last 9 months or so, Jong and I, acting on an individual basis, engineered a technical solution for this deliverable. This solution is specified in the I-D draft-zeilenga-ldup-sync. Each of these technical solutions are intended to fulfill this deliverable. I also believe both sets of authors believe that their approach best fulfills this deliverable. It is also likely many members of this WG have formed opinions as to which technical solution best fulfills this deliverable. However, it is unclear to me whether both I-D, in particular the most recent revisions of each, have been thoroughly considered by the WG. WG I-Ds are implicitly viewed as being under WG consideration and it hoped that significant number of WG members review the I-D as it evolves. Individual I-Ds are not necessarily viewed as being under WG consideration unless submitted to the WG for consideration by their authors. They generally are reviewed by few WG members until consideration is specifically requested. I now submit the draft-zeilenga-ldup-sync to the LDUP WG for consideration as a technical solution to its "LDAP Client Update" deliverable. I believe the latest revision, draft-zeilenga-ldup-sync-02.txt, is suitable for progression. I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync as technical alternatives and give thorough consideration to both. It is up to the WG to decide which solution is technically superior. As it is the function of the WG Chairs to manage the group process, I defer procedural questions and issues to Chris and John. As the differences between the approaches is fundamental in their design, it will be difficult to compare them without some basis to which can be measured against. It may be appropriate for the WG to examine what kinds of applications it intends its deliverable to be applicable to, what the requirements of these applications are, and how each of the technical alternatives measures up to these requirements. The WG should also consider broader issues, such as chattiness and security considerations. The WG should consider the appropriateness of the design and other constraints each places upon implementations. In regards to the WG milestone: May 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard I would like the WG to defer this WG Last Call until it has thoroughly consider both technical alternatives and reached a consensus as to which alternative it would like to pursue. Then that alternative should be prepared of WG Last Call as the WG's "LDAPv3 Client Update Protocol I-D". I believe it necessary to defer the WG Last Call as the WG first needs to thoroughly consider both alternatives. I'd like to say a key design difference which is a major factor in I considering draft-zeilenga-ldup-sync technically superior to draft-ietf-ldup-lcup. In attempting to implement draft-ietf-ldup-lcup, we found that requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes. We found that where the server only maintains simple state indicators such as timestamps, it cannot generally provide eventually convergent incremental refreshes. If the server maintains partial histories, the server will be limited in cases where it can provide eventually convergent incremental refreshes. In October 2002, the WG consensus was declared on an alternative approach (but later recanted). We implemented this approach and found that it allowed all of the above implementation variants to provide eventually convergent incremental refreshes. This was document in documented in early revisions of draft-zeilenga-ldup-sync. As a result of WG discussions about this approach, it was noted that this approach didn't allow servers to take advantage of histories they maintained. In our latest revision, we adopted a hybrid approach which allows servers to take advantage of histories they maintained. Hence, I believe draft-zeilenga-ldup-sync is technical superior in that it does not place significant implementation constraints in order to support eventually convergent incremental refreshes while allowing implementations take advantage of histories they maintain. There are, of course, many other factors in my consideration and I am quite willing to elaborate on these in subsequent discussions. Before doing so, I will await direction from the chairs on how to proceed with the consideration of the alternatives. Comments? Regards, Kurt From owner-ietf-ldup@mail.imc.org Tue May 27 08:51:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10355 for ; Tue, 27 May 2003 08:51:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RChmAF051404 for ; Tue, 27 May 2003 05:43:48 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4RChmKg051403 for ietf-ldup-bks; Tue, 27 May 2003 05:43:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RChgAF051394 for ; Tue, 27 May 2003 05:43:45 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-194-34.pskn.east.verizon.net [151.204.194.34]) by dns.caledonia.net; Tue, 27 May 2003 06:37:34 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: , , , , Subject: RE: LCUP applicability Date: Tue, 27 May 2003 08:42:35 -0400 Organization: DSI-Consulting, Inc. Message-ID: <002101c3244d$7edf9710$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030526084108.02bfc0a0@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Note from the Co-Chair: I consider this issue to be worth discussing regardless of the request from Kurt relating to the pending WG Last Call initiation for LCUP. It will need to be resolved regardless of the outcome of the WG considering his request. Kurt, One way of characterizing the problem(s) technology is intended to solve is by including discussion about applications for which that technology is a good (or a bad) solution. That is clearly *one* way of documenting applicability. It has been the most common way of doing so in many engineering documents I've encountered in the past. So far, its not clear what this particular disagreement is about. Can you provide a few references for applicability statements that are more like those you would prefer to see in the LCUP document? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, May 26, 2003 11:50 AM To: capple@dsi-consulting.net Cc: rmegginson0224@aol.com; ietf-ldup@imc.org; mcs@netscape.com; olgan@yahoo-inc.com; jeffparh@windows.microsoft.com Subject: RE: LCUP applicability I content that the I-D has not been updated to discuss applicability. That is, it has been updated to discuss which applications are well suited to it and which are not, and why. The updates are mainly highlight implementation constraints, and while useful, are not quite the same thing. The applicability statement exercise purpose, I thought, was to focus some the problem both I-Ds report to solve and their suitability of each of the solutions. To that purpose, we still have a long way to go. Kurt At 09:00 AM 5/23/2003, Chris Apple wrote: >Kurt, > >We'll be able to handle word-smithing during the WG Last Call for LCUP. > >However, with regard to this particular thread, I don't see support on >the mailing list for your position that the applicability statement >language is unclear. > >I therefore must conclude that the WG doesn't agree with your position >and consider this particular issue closed unless reopened by other WG >members during the upcoming LCUP WG Last Call. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] >On Behalf Of Rich Megginson >Sent: Tuesday, May 06, 2003 11:03 AM >To: Kurt D. Zeilenga >Cc: ietf-ldup@imc.org; mcs@netscape.com; olgan@yahoo-inc.com; >jeffparh@windows.microsoft.com; richm@netscape.com >Subject: Re: LCUP applicability > > >Kurt D. Zeilenga wrote: > >>LCUP's applicability statement, I think, needs a bit of work. >>The "will work best" phrase, I find a bit odd, seems these >>are more "design assumptions". >> >I'm not sure what the difference is between an "applicability statement" >and a "design assumption", but isn't that the whole point of the section >anyway? To provide suggestions to implementers about what types of >server and client applications are best suited for LCUP? I don't see a >problem here. > >>Anyways... >> >>The first item implies that LCUP "works" when the server >>maintains no historical information. It should be clear, >>that without historical information, the server can only >>determine that change occurred since the time indicated by >>the cookie, not what that change was. Hence, only if there >>were no changes in the context, the could the server could respond >>successfully. In any change occurred in the context, the >>server would have to fail with lcupReloadRequired. >> >Well, that is "working". Some definition of "working" is that the >client does a full resync every time (or does nothing, if there is >nothing to do). I think the statement in LCUP is pretty clear without >going so far as to "bash potential implementers over the head with >implementation details". > >No problem here. > >>The second item says the client is not assumed to understand >>the "physical information model" implemented by the >>server, however it provides as instances of the physical >>model "virtual attributes, operational attributes, [and]subentries". I >think the authors meant LCUP assumes >>only knowledge of the "directory user information model" >>[X.501(93)]. >> >I think the wording is pretty clear and easy to understand as it is. > The document provides as instances those items to provide clarity >within the context without requiring the reader of the document to refer >to other documents just to get an idea of what is being referred to here. > >>Anyways, I think LCUP does require the >>client to understand directory administrative and >>operational models in certain areas. For example, as >>LCUP doesn't support alias dereferencing during searching, >>a user client desiring aliases objects has to understand >>alias objects. >> >Right. This particular "exception to the rule" was discussed a long >time by the LDAP community, and it was decided that this particular >exception was worthy of inclusion in LCUP. > >>I assume it does so to reduce complexity. >>There are other cases where assuming or requiring client >>knowledge of aspects of select administrative and operational >>models would significant reduce complexity and/or chattiness. >> >Then the implementer can either choose to accept LCUP with its >"chattiness in certan cases" or reject LCUP in favor of another approach. > >No problem here. > >>With regard to the third item, I think LCUP has significant >>problems dealing with a number of everyday DIT update >>situations and forces full reloads far too frequently. >> >Those situations are explicitly listed in the LCUP document, and the >document lists the reasons that LCUP chose to handle them in the way it >did. > >No problem here. > >>I'll post a more detailed discussion of this in a separate >>message at a later time. >> >I look forward to reading it. But what will be different than what we >have already discussed at great length in the past? Have you found >several other new situations that you didn't know about 2 months ago? > >The point is that implementers can choose to accept these conditions or >not. At least they are explicitly spelled out in LCUP near the beginning. > >>Kurt >> >> >> > From owner-ietf-ldup@mail.imc.org Tue May 27 15:25:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27129 for ; Tue, 27 May 2003 15:25:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RJ6pAF074249 for ; Tue, 27 May 2003 12:06:51 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4RJ6pCo074248 for ietf-ldup-bks; Tue, 27 May 2003 12:06:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RJ6QAF074240 for ; Tue, 27 May 2003 12:06:43 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-194-34.pskn.east.verizon.net [151.204.194.34]) by dns.caledonia.net; Tue, 27 May 2003 13:01:36 -0600 Reply-To: From: "Chris Apple" To: , "'Kurt D. Zeilenga'" , Cc: "'John Strassner'" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Tue, 27 May 2003 15:05:23 -0400 Organization: DSI-Consulting, Inc. Message-ID: <005301c32482$fea069e0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <001f01c3244a$f2d21560$6500a8c0@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit As WG Co-Chair, I want to be clear with WG Members about the status of Kurt's request: 1) The WG needs to establish a consensus of support for proceeding as Kurt suggests in order for John and I to endorse it and make any requests for changes to milestone dates or other charter changes to our ADs. 2) It is an open topic for discussion. Specifically, John and I need to see comments (preferably with rationale) about the value (or lack thereof) of proceeding as Kurt suggests. Do not wait for further communication from either John, Kurt, or I to start this discussion. John and I don't want to have to resort to interpreting silence on this issue in one way or another. Make your opinions known NOW! This applies to you even if you are an author of one of the drafts covered by Kurt's request. 3) The milestone date for the WG Last Call for the LCUP deliverable is still May 2003 and requires approval of our ADs to slip intentionally. 4) John and I will await confirmation/clarification of our understanding of Kurt's request from Kurt before making the request to our ADs to slip the milestone date to give us enough time to consider whether the WG wishes to: a) proceed as Kurt suggests b) stay with our presently chartered course of action, albeit with some slippage c) take another path completely different from those Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Tuesday, May 27, 2003 8:25 AM To: 'Kurt D. Zeilenga'; ietf-ldup@imc.org Cc: 'John Strassner' Subject: RE: LDAP Client Update: consideration of alternative proposals WG Members should review the request Kurt has made. John and I will respond to the list on the procedure we'll use in considering Kurt's request, and if appropriate, acting on it. Kurt, There are a few major points I'd like to be sure I'm summarizing correctly before John and I respond on the procedural issue. You are requesting the following: 1) that the WG formally consider your individual contribution as an alternative to the existing WG deliverable for LDAPv3 Client Update Protocol. 2) that the WG evaluate both documents based on technical merit. 3) that the WG emerge from that evaluation process with a single document that will be processed through a WG Last Call and submitted to the Ads as the WG deliverable for LDAPv3 Client Update Protocol. 4) that the WG Last Call milestone for LCUP be rescheduled further out in time to accommodate the above. Did I miss any key points in your request? Do any of them need clarification? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, May 26, 2003 11:11 AM To: ietf-ldup@imc.org Cc: Chris Apple; John Strassner Subject: LDAP Client Update: consideration of alternative proposals The LDUP WG is chartered to deliver: o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. Over the last few years, the WG has engineering a technical solution for this deliverable. This solution is specified in the I-D draft-ietf-ldup-lcup. Over the last 9 months or so, Jong and I, acting on an individual basis, engineered a technical solution for this deliverable. This solution is specified in the I-D draft-zeilenga-ldup-sync. Each of these technical solutions are intended to fulfill this deliverable. I also believe both sets of authors believe that their approach best fulfills this deliverable. It is also likely many members of this WG have formed opinions as to which technical solution best fulfills this deliverable. However, it is unclear to me whether both I-D, in particular the most recent revisions of each, have been thoroughly considered by the WG. WG I-Ds are implicitly viewed as being under WG consideration and it hoped that significant number of WG members review the I-D as it evolves. Individual I-Ds are not necessarily viewed as being under WG consideration unless submitted to the WG for consideration by their authors. They generally are reviewed by few WG members until consideration is specifically requested. I now submit the draft-zeilenga-ldup-sync to the LDUP WG for consideration as a technical solution to its "LDAP Client Update" deliverable. I believe the latest revision, draft-zeilenga-ldup-sync-02.txt, is suitable for progression. I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync as technical alternatives and give thorough consideration to both. It is up to the WG to decide which solution is technically superior. As it is the function of the WG Chairs to manage the group process, I defer procedural questions and issues to Chris and John. As the differences between the approaches is fundamental in their design, it will be difficult to compare them without some basis to which can be measured against. It may be appropriate for the WG to examine what kinds of applications it intends its deliverable to be applicable to, what the requirements of these applications are, and how each of the technical alternatives measures up to these requirements. The WG should also consider broader issues, such as chattiness and security considerations. The WG should consider the appropriateness of the design and other constraints each places upon implementations. In regards to the WG milestone: May 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard I would like the WG to defer this WG Last Call until it has thoroughly consider both technical alternatives and reached a consensus as to which alternative it would like to pursue. Then that alternative should be prepared of WG Last Call as the WG's "LDAPv3 Client Update Protocol I-D". I believe it necessary to defer the WG Last Call as the WG first needs to thoroughly consider both alternatives. I'd like to say a key design difference which is a major factor in I considering draft-zeilenga-ldup-sync technically superior to draft-ietf-ldup-lcup. In attempting to implement draft-ietf-ldup-lcup, we found that requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes. We found that where the server only maintains simple state indicators such as timestamps, it cannot generally provide eventually convergent incremental refreshes. If the server maintains partial histories, the server will be limited in cases where it can provide eventually convergent incremental refreshes. In October 2002, the WG consensus was declared on an alternative approach (but later recanted). We implemented this approach and found that it allowed all of the above implementation variants to provide eventually convergent incremental refreshes. This was document in documented in early revisions of draft-zeilenga-ldup-sync. As a result of WG discussions about this approach, it was noted that this approach didn't allow servers to take advantage of histories they maintained. In our latest revision, we adopted a hybrid approach which allows servers to take advantage of histories they maintained. Hence, I believe draft-zeilenga-ldup-sync is technical superior in that it does not place significant implementation constraints in order to support eventually convergent incremental refreshes while allowing implementations take advantage of histories they maintain. There are, of course, many other factors in my consideration and I am quite willing to elaborate on these in subsequent discussions. Before doing so, I will await direction from the chairs on how to proceed with the consideration of the alternatives. Comments? Regards, Kurt From owner-ietf-ldup@mail.imc.org Wed May 28 10:00:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03593 for ; Wed, 28 May 2003 10:00:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SDiIAF041696 for ; Wed, 28 May 2003 06:44:18 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4SDiIT8041695 for ietf-ldup-bks; Wed, 28 May 2003 06:44:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SDiCAF041687 for ; Wed, 28 May 2003 06:44:12 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h4SDhrE14311 for ; Wed, 28 May 2003 06:43:53 -0700 (PDT) Received: from netscape.com ([10.169.192.24]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HFLNH800.Z5T; Wed, 28 May 2003 06:43:56 -0700 Message-ID: <3ED4BD1B.6000906@netscape.com> Date: Wed, 28 May 2003 09:43:55 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: capple@dsi-consulting.net CC: "'Kurt D. Zeilenga'" , ietf-ldup@imc.org, "'John Strassner'" Subject: Re: LDAP Client Update: consideration of alternative proposals References: <005301c32482$fea069e0$6500a8c0@D7ST2111> In-Reply-To: <005301c32482$fea069e0$6500a8c0@D7ST2111> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris Apple wrote: > > 2) It is an open topic for discussion. Specifically, John > and I need to see comments (preferably with rationale) > about the value (or lack thereof) of proceeding as > Kurt suggests. Do not wait for further communication > from either John, Kurt, or I to start this discussion. > John and I don't want to have to resort to interpreting > silence on this issue in one way or another. > > Make your opinions known NOW! This applies to you even > if you are an author of one of the drafts covered by > Kurt's request. I suspect we are obligated to do something like what Kurt suggests: compare and contrast draft-ietf-ldup-lcup with draft-zeilenga-ldup-sync. If we don't, the ADs or IESG will probably make us do so eventually anyway. But I am concerned about process issues surrounding this situation. Did the LDUP WG chairs declare consensus prematurely or inappropriately? I assume the ADs are involved and will help sort this out. The authors of draft-ietf-ldup-lcup did give serious consideration to the ideas presented in draft-zeilenga-ldup-sync; some of that discussion took place on the mailing list a while ago and some was private mail among the authors of the two documents. It is not as if the alternative proposal was ignored by the WG or by the LCUP authors. One additional observation: to remain viable, the IETF needs to accept and encourage contributions from many people, not just a few people. When a WG deliverable that has been nearly completed is derailed at the last moment, the liklihood of the people who volunteered to work on that deliverable doing so in the future is greatly reduced. Now, one could argue that this is not a technical consideration but a political one. I would argue that it is both: the technical quality of the work done in the IETF (and the likelihood of widespread implementation) is greatly influenced by the number of different implementors who contribute. For LDAP related work, we seem to have fewer and fewer contributors each year. This is a problem. > 4) John and I will await confirmation/clarification of our > understanding of Kurt's request from Kurt before making > the request to our ADs to slip the milestone date to give > us enough time to consider whether the WG wishes to: > > a) proceed as Kurt suggests > b) stay with our presently chartered course of action, > albeit with some slippage > c) take another path completely different from those If you are asking for a vote, I vote for (b). But the larger procedural issues (and the ADs) will probably dictate what we must do... and I suspect we will end up doing something close to (a). -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Wed May 28 12:59:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11880 for ; Wed, 28 May 2003 12:59:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SGj7AF052979 for ; Wed, 28 May 2003 09:45:07 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4SGj7dK052978 for ietf-ldup-bks; Wed, 28 May 2003 09:45:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SGigAF052963 for ; Wed, 28 May 2003 09:44:58 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-194-34.pskn.east.verizon.net [151.204.194.34]) by dns.caledonia.net; Wed, 28 May 2003 10:13:45 -0600 Reply-To: From: "Chris Apple" To: "'Mark C Smith'" Cc: "'Kurt D. Zeilenga'" , , "'John Strassner'" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Wed, 28 May 2003 12:19:53 -0400 Organization: DSI-Consulting, Inc. Message-ID: <00f201c32535$14d602d0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3ED4BD1B.6000906@netscape.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for taking the time to post on this topic. I've included a response to the process concerns below. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Mark C Smith [mailto:mcs@netscape.com] Sent: Wednesday, May 28, 2003 9:44 AM To: capple@dsi-consulting.net Cc: 'Kurt D. Zeilenga'; ietf-ldup@imc.org; 'John Strassner' Subject: Re: LDAP Client Update: consideration of alternative proposals Chris Apple wrote: > > 2) It is an open topic for discussion. Specifically, John > and I need to see comments (preferably with rationale) > about the value (or lack thereof) of proceeding as > Kurt suggests. Do not wait for further communication > from either John, Kurt, or I to start this discussion. > John and I don't want to have to resort to interpreting > silence on this issue in one way or another. > > Make your opinions known NOW! This applies to you even > if you are an author of one of the drafts covered by > Kurt's request. I suspect we are obligated to do something like what Kurt suggests: compare and contrast draft-ietf-ldup-lcup with draft-zeilenga-ldup-sync. If we don't, the ADs or IESG will probably make us do so eventually anyway. From a process perspective, we are obligated to consider Kurt's request. If consensus is established supporting Kurt's request we become obligated as a WG to pursue that course of action once that consensus is declared by John and I. But I am concerned about process issues surrounding this situation. Did the LDUP WG chairs declare consensus prematurely or inappropriately? I assume the ADs are involved and will help sort this out. The authors of draft-ietf-ldup-lcup did give serious consideration to the ideas presented in draft-zeilenga-ldup-sync; some of that discussion took place on the mailing list a while ago and some was private mail among the authors of the two documents. It is not as if the alternative proposal was ignored by the WG or by the LCUP authors. With regard to the WG Co-Chairs having declared consensus prematurely or inappropriately, the jury may be out. I know I have an opinion on that matter and that's that we did the best we could given the input received on the mailing list. Currently, this question is not one that is being formally considered by the ADs. The ADs were and are involved. That Kurt made the posting to the mailing list making his request was a result of private discussion held between Kurt, myself, John Strassner, and both of our ADs. Kurt expressed his concerns to us privately; we were unable to come to agreement on how to handle his concerns as a part of the WG Last Call for LCUP; we made a decision as Co-Chairs that Kurt should take his concerns along with a specific proposal to the WG Mailing List. John and I have endorsed the consideration of Kurt's proposal by the WG. That's how we got here. I agree that the proposal presented in draft-zeilenga-ldup-sync was given adequate consideration by the LCUP authors and the WG. But again, the jury may be out on that point. It is still a valid question to ask though. Speaking as a Co-Chair, I would have preferred to see all of the technical discussion between the two author teams related to these two drafts taking place on the LDUP WG mailing list. I am hoping that all future discussion related to this topic takes place on the mailing list. One additional observation: to remain viable, the IETF needs to accept and encourage contributions from many people, not just a few people. When a WG deliverable that has been nearly completed is derailed at the last moment, the liklihood of the people who volunteered to work on that deliverable doing so in the future is greatly reduced. Now, one could argue that this is not a technical consideration but a political one. I would argue that it is both: the technical quality of the work done in the IETF (and the likelihood of widespread implementation) is greatly influenced by the number of different implementors who contribute. For LDAP related work, we seem to have fewer and fewer contributors each year. This is a problem. I share that concern whole-heartedly. > 4) John and I will await confirmation/clarification of our > understanding of Kurt's request from Kurt before making > the request to our ADs to slip the milestone date to give > us enough time to consider whether the WG wishes to: > > a) proceed as Kurt suggests > b) stay with our presently chartered course of action, > albeit with some slippage > c) take another path completely different from those If you are asking for a vote, I vote for (b). But the larger procedural issues (and the ADs) will probably dictate what we must do... and I suspect we will end up doing something close to (a). The WG will end up doing whatever we establish consensus on. The prior consensus is reflected in the current charter. That was reflected in (b). This discussion is intended to help us as Co-Chairs determine if there is more support for one of the options above or another. Interpreting that requires input on the mailing list. I only hope that others are inclined to contribute to the discussion as you've done. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Wed May 28 13:39:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13068 for ; Wed, 28 May 2003 13:39:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SHQKAF055049 for ; Wed, 28 May 2003 10:26:20 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4SHQKw6055048 for ietf-ldup-bks; Wed, 28 May 2003 10:26:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SHQHAF055043 for ; Wed, 28 May 2003 10:26:19 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4SHQGXF025646 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 May 2003 10:26:17 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4SHQEsh008961; Wed, 28 May 2003 10:26:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3ED4BD1B.6000906@netscape.com> References: <005301c32482$fea069e0$6500a8c0@D7ST2111> <3ED4BD1B.6000906@netscape.com> Date: Wed, 28 May 2003 10:26:13 -0700 To: mcs@netscape.com (Mark C Smith) From: hardie@qualcomm.com Subject: Re: LDAP Client Update: consideration of alternative proposals Cc: ietf-ldup@imc.org, ned.freed@mrochek.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, First, let me say that Chris, John, and Kurt have each tried to keep Ned and me in the loop on the discussions; I am also subscribed to the list, so I can and do follow issues raised here. I have provided a summary of the issues raised to date to the IESG as a whole, so there is also some awareness of the issues among those not specifically concerned with the APPs area. While all of us (Chairs, ADs, IESG) are concerned both to ensure an open process and high quality output, we're not here to dictate the results. At this point, a working group member has suggested that the working group reconsider an alternative proposal, and the chairs have issued a call to the working group to comment on whether that consideration is needed and should happen. Two questions lie at the heart of that call: has the working group considered both proposals and come to rough consensus? if so, should the working group reconsider its previous decision? Previous consideration given to this proposal obviously factors into the response to that first question. Assessments of the relative quality and applicability of the two proposals factors into the second. So does the stage of the working group process; as we move forward through various decisions (adopting drafts as working group items, setting milestones, and so on), the working group needs to be able to focus on the next step, rather than revisiting questions which have been decided. Our process does allow for reviewing those questions at any stage (after all, Draft Standards sometimes recycle at Proposed for exactly this reason), but the reasons to change a decided issue shift to ones in which fundamental questions of technical suitability, security, interoperability, or scalability are at stake. To put it another way, we are always sensitive to "show-stoppers" which mean that deployment on the Internet will be bad for the user or the Internet itself, but that does not mean all questions must constantly be open for reconsideration. The chairs have asked the working group participants in this case to express their views of whether or not this is needed in this case, and an explicit call for consensus on this point seems to me a good way of resolving the issues. Let me say thanks for expressing your concerns and for giving a response to Chris's call for opinions. I encourage others who have opinions to put their fingers to keyboards as well. regards, Ted Hardie >Chris Apple wrote: > > >>2) It is an open topic for discussion. Specifically, John >> and I need to see comments (preferably with rationale) >...snip... >> Make your opinions known NOW! This applies to you even >> if you are an author of one of the drafts covered by >> Kurt's request. > >I suspect we are obligated to do something like what Kurt suggests: >compare and contrast draft-ietf-ldup-lcup with >draft-zeilenga-ldup-sync. If we don't, the ADs or IESG will >probably make us do so eventually anyway. > >But I am concerned about process issues surrounding this situation. >Did the LDUP WG chairs declare consensus prematurely or >inappropriately? I assume the ADs are involved and will help sort >this out. The authors of draft-ietf-ldup-lcup did give serious >consideration to the ideas presented in draft-zeilenga-ldup-sync; >some of that discussion took place on the mailing list a while ago >and some was private mail among the authors of the two documents. It >is not as if the alternative proposal was ignored by the WG or by >the LCUP authors. > >One additional observation: to remain viable, the IETF needs to >accept and encourage contributions from many people, not just a few >people. When a WG deliverable that has been nearly completed is >derailed at the last moment, the liklihood of the people who >volunteered to work on that deliverable doing so in the future is >greatly reduced. Now, one could argue that this is not a technical >consideration but a political one. I would argue that it is both: >the technical quality of the work done in the IETF (and the >likelihood of widespread implementation) is greatly influenced by >the number of different implementors who contribute. For LDAP >related work, we seem to have fewer and fewer contributors each >year. This is a problem. > >>4) John and I will await confirmation/clarification of our >> understanding of Kurt's request from Kurt before making >...snip... >> b) stay with our presently chartered course of action, >> albeit with some slippage >> c) take another path completely different from those > >If you are asking for a vote, I vote for (b). But the larger >procedural issues (and the ADs) will probably dictate what we must >do... and I suspect we will end up doing something close to (a). > >-Mark Smith > Netscape From owner-ietf-ldup@mail.imc.org Wed May 28 21:14:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01820 for ; Wed, 28 May 2003 21:14:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T17AAF075260 for ; Wed, 28 May 2003 18:07:10 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T179Sa075259 for ietf-ldup-bks; Wed, 28 May 2003 18:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T176AF075254 for ; Wed, 28 May 2003 18:07:07 -0700 (PDT) (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 May 2003 11:07:03 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Thu, 29 May 2003 11:07:03 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63811FCEE9@ausyms21.ca.com> Thread-Topic: LDAP Client Update: consideration of alternative proposals Thread-Index: AcMlOUTPs027c27BSJiNPMNotBcxPgARJ2Ng From: "Ramsay, Ron" To: Cc: X-OriginalArrivalTime: 29 May 2003 01:07:03.0936 (UTC) FILETIME=[9DC22800:01C3257E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4T178AF075255 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit As I see it 1) LCUP is meant to provide a simple synchronisation tool, similar to persistent search. 2) Kurt's proposal seeks to define a replication paradigm. 3) The WG failed to pursue replication to a standard. 4) All the discussion I've seen seems to be between the competing authors. Therefore, I believe you have to accept the original LCUP proposal with possible tweaks. There aren't enough voices left in this group to undertake any new work. Ron -----Original Message----- From: Chris Apple [mailto:capple@dsi-consulting.net] Sent: Thursday, 29 May 2003 02:20 To: 'Mark C Smith' Cc: 'Kurt D. Zeilenga'; ietf-ldup@imc.org; 'John Strassner' Subject: RE: LDAP Client Update: consideration of alternative proposals Thanks for taking the time to post on this topic. I've included a response to the process concerns below. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Mark C Smith [mailto:mcs@netscape.com] Sent: Wednesday, May 28, 2003 9:44 AM To: capple@dsi-consulting.net Cc: 'Kurt D. Zeilenga'; ietf-ldup@imc.org; 'John Strassner' Subject: Re: LDAP Client Update: consideration of alternative proposals Chris Apple wrote: > > 2) It is an open topic for discussion. Specifically, John > and I need to see comments (preferably with rationale) > about the value (or lack thereof) of proceeding as > Kurt suggests. Do not wait for further communication > from either John, Kurt, or I to start this discussion. > John and I don't want to have to resort to interpreting > silence on this issue in one way or another. > > Make your opinions known NOW! This applies to you even > if you are an author of one of the drafts covered by > Kurt's request. I suspect we are obligated to do something like what Kurt suggests: compare and contrast draft-ietf-ldup-lcup with draft-zeilenga-ldup-sync. If we don't, the ADs or IESG will probably make us do so eventually anyway. From a process perspective, we are obligated to consider Kurt's request. If consensus is established supporting Kurt's request we become obligated as a WG to pursue that course of action once that consensus is declared by John and I. But I am concerned about process issues surrounding this situation. Did the LDUP WG chairs declare consensus prematurely or inappropriately? I assume the ADs are involved and will help sort this out. The authors of draft-ietf-ldup-lcup did give serious consideration to the ideas presented in draft-zeilenga-ldup-sync; some of that discussion took place on the mailing list a while ago and some was private mail among the authors of the two documents. It is not as if the alternative proposal was ignored by the WG or by the LCUP authors. With regard to the WG Co-Chairs having declared consensus prematurely or inappropriately, the jury may be out. I know I have an opinion on that matter and that's that we did the best we could given the input received on the mailing list. Currently, this question is not one that is being formally considered by the ADs. The ADs were and are involved. That Kurt made the posting to the mailing list making his request was a result of private discussion held between Kurt, myself, John Strassner, and both of our ADs. Kurt expressed his concerns to us privately; we were unable to come to agreement on how to handle his concerns as a part of the WG Last Call for LCUP; we made a decision as Co-Chairs that Kurt should take his concerns along with a specific proposal to the WG Mailing List. John and I have endorsed the consideration of Kurt's proposal by the WG. That's how we got here. I agree that the proposal presented in draft-zeilenga-ldup-sync was given adequate consideration by the LCUP authors and the WG. But again, the jury may be out on that point. It is still a valid question to ask though. Speaking as a Co-Chair, I would have preferred to see all of the technical discussion between the two author teams related to these two drafts taking place on the LDUP WG mailing list. I am hoping that all future discussion related to this topic takes place on the mailing list. One additional observation: to remain viable, the IETF needs to accept and encourage contributions from many people, not just a few people. When a WG deliverable that has been nearly completed is derailed at the last moment, the liklihood of the people who volunteered to work on that deliverable doing so in the future is greatly reduced. Now, one could argue that this is not a technical consideration but a political one. I would argue that it is both: the technical quality of the work done in the IETF (and the likelihood of widespread implementation) is greatly influenced by the number of different implementors who contribute. For LDAP related work, we seem to have fewer and fewer contributors each year. This is a problem. I share that concern whole-heartedly. > 4) John and I will await confirmation/clarification of our > understanding of Kurt's request from Kurt before making > the request to our ADs to slip the milestone date to give > us enough time to consider whether the WG wishes to: > > a) proceed as Kurt suggests > b) stay with our presently chartered course of action, > albeit with some slippage > c) take another path completely different from those If you are asking for a vote, I vote for (b). But the larger procedural issues (and the ADs) will probably dictate what we must do... and I suspect we will end up doing something close to (a). The WG will end up doing whatever we establish consensus on. The prior consensus is reflected in the current charter. That was reflected in (b). This discussion is intended to help us as Co-Chairs determine if there is more support for one of the options above or another. Interpreting that requires input on the mailing list. I only hope that others are inclined to contribute to the discussion as you've done. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Wed May 28 22:33:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03507 for ; Wed, 28 May 2003 22:33:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T2T0AF077548 for ; Wed, 28 May 2003 19:29:00 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T2T0cS077547 for ietf-ldup-bks; Wed, 28 May 2003 19:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T2SxAF077533 for ; Wed, 28 May 2003 19:28:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4T2Src6032911; Thu, 29 May 2003 02:28:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030528184809.0294b350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 28 May 2003 19:26:01 -0700 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: , In-Reply-To: <1395B4B334FCC143B36AF788E68B63811FCEE9@ausyms21.ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:07 PM 5/28/2003, Ramsay, Ron wrote: >1) LCUP is meant to provide a simple synchronisation tool, similar to persistent search. I content that LDAP-Sync is meant to provide a simple synchronization tool, similar to persistent search, as well. The primary applications being considered for both solutions is the same: meta-directory, address-books, etc.. >2) Kurt's proposal seeks to define a replication paradigm. While Jong and I certainly intend to use LDAP Sync as a basis for single-master replication, this I-D does not attempt to detail how LDAP Sync might be used for single-master replication. (We saved that for a future draft.) I note that this secondary intended use did not impose any special requirements upon the protocol. Like LCUP, LDAP-Sync intends to meet the requirements of "applications intending to synchronize heterogeneous data stores" [LCUP] and that easily covers everything that a lightweight single-master replication application needs from its content synchronization tool. Now, maybe the difference is that LCUP focuses more on simple application (e.g., address book) requirements and less on sophisticated application (e.g. meta-directory) requirements, but I think we each tried to meet the requirements of both simple and sophisticated applications content synchronization needs. Kurt From owner-ietf-ldup@mail.imc.org Wed May 28 23:03:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04299 for ; Wed, 28 May 2003 23:03:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T2vZAF078887 for ; Wed, 28 May 2003 19:57:35 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T2vZnm078886 for ietf-ldup-bks; Wed, 28 May 2003 19:57:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T2vXAF078874 for ; Wed, 28 May 2003 19:57:34 -0700 (PDT) (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 May 2003 12:57:31 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Thu, 29 May 2003 12:57:31 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63811FD0EF@ausyms21.ca.com> Thread-Topic: LDAP Client Update: consideration of alternative proposals Thread-Index: AcMlihI9vgrXzQbAT3KYpm/yMxR2PgAAs+IA From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 29 May 2003 02:57:31.0773 (UTC) FILETIME=[0C41D2D0:01C3258E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4T2vYAF078882 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit It is sounding worse already. I'm referring here to the fact that you intend another draft saying HOW the syncing is to be done. Maybe the protocol can stand on its own, but I remember how the WG became fixated with the LCUP cookie. It is starting to sound as if this one will be bigger than "Ben Hur". -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 29 May 2003 12:26 To: Ramsay, Ron Cc: capple@dsi-consulting.net; ietf-ldup@imc.org Subject: RE: LDAP Client Update: consideration of alternative proposals At 06:07 PM 5/28/2003, Ramsay, Ron wrote: >1) LCUP is meant to provide a simple synchronisation tool, similar to persistent search. I content that LDAP-Sync is meant to provide a simple synchronization tool, similar to persistent search, as well. The primary applications being considered for both solutions is the same: meta-directory, address-books, etc.. >2) Kurt's proposal seeks to define a replication paradigm. While Jong and I certainly intend to use LDAP Sync as a basis for single-master replication, this I-D does not attempt to detail how LDAP Sync might be used for single-master replication. (We saved that for a future draft.) I note that this secondary intended use did not impose any special requirements upon the protocol. Like LCUP, LDAP-Sync intends to meet the requirements of "applications intending to synchronize heterogeneous data stores" [LCUP] and that easily covers everything that a lightweight single-master replication application needs from its content synchronization tool. Now, maybe the difference is that LCUP focuses more on simple application (e.g., address book) requirements and less on sophisticated application (e.g. meta-directory) requirements, but I think we each tried to meet the requirements of both simple and sophisticated applications content synchronization needs. Kurt From owner-ietf-ldup@mail.imc.org Wed May 28 23:55:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05532 for ; Wed, 28 May 2003 23:55:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T3n4AF080335 for ; Wed, 28 May 2003 20:49:04 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T3n4wi080334 for ietf-ldup-bks; Wed, 28 May 2003 20:49:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T3n2AF080329 for ; Wed, 28 May 2003 20:49:03 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-193-11.pskn.east.verizon.net [151.204.193.11]) by dns.caledonia.net; Wed, 28 May 2003 21:42:00 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" , "'Ramsay, Ron'" Cc: Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Wed, 28 May 2003 23:48:40 -0400 Organization: DSI-Consulting, Inc. Message-ID: <013501c32595$33e953b0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030528184809.0294b350@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt, Does this mean that you agree with Ron's point? Or not? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com At 06:07 PM 5/28/2003, Ramsay, Ron wrote: >1) LCUP is meant to provide a simple synchronisation tool, similar to persistent search. I content that LDAP-Sync is meant to provide a simple synchronization tool, similar to persistent search, as well. The primary applications being considered for both solutions is the same: meta-directory, address-books, etc.. From owner-ietf-ldup@mail.imc.org Thu May 29 00:32:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06490 for ; Thu, 29 May 2003 00:32:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T4Q1AF081504 for ; Wed, 28 May 2003 21:26:01 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T4Q1Pb081503 for ietf-ldup-bks; Wed, 28 May 2003 21:26:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T4Q0AF081498 for ; Wed, 28 May 2003 21:26:00 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4T4Psc6033851; Thu, 29 May 2003 04:25:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030528211451.0294e948@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 28 May 2003 21:23:01 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: "'Ramsay, Ron'" , In-Reply-To: <013501c32595$33e953b0$6500a8c0@D7ST2111> References: <5.2.0.9.0.20030528184809.0294b350@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:48 PM 5/28/2003, Chris Apple wrote: >Does this mean that you agree with Ron's point? Or not? I don't dispute Ron's point that LCUP (draft-ietf-ldup-lcup) is meant to provide a simple synchronization tool. However, I added that I believe that LDAP-Sync (draft-zeilenga-ldup-sync) is also meant to provide a simple synchronization tool. I'll leave it to Ron to say whether he concurs with my additional point. >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >At 06:07 PM 5/28/2003, Ramsay, Ron wrote: >>1) LCUP is meant to provide a simple synchronisation tool, similar to >persistent search. > >I content that LDAP-Sync is meant to provide a simple >synchronization tool, similar to persistent search, as well. The >primary applications being considered for both solutions is the >same: meta-directory, address-books, etc.. From owner-ietf-ldup@mail.imc.org Thu May 29 00:44:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06646 for ; Thu, 29 May 2003 00:44:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T4cIAF081826 for ; Wed, 28 May 2003 21:38:18 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T4cIBi081825 for ietf-ldup-bks; Wed, 28 May 2003 21:38:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T4cGAF081813 for ; Wed, 28 May 2003 21:38:16 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4T4c8c6033895; Thu, 29 May 2003 04:38:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030528213144.0294f818@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 28 May 2003 21:35:16 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: , "'John Strassner'" In-Reply-To: <001f01c3244a$f2d21560$6500a8c0@D7ST2111> References: <5.2.0.9.0.20030526080049.02bc3ae8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:24 AM 5/27/2003, Chris Apple wrote: >Kurt, > >There are a few major points I'd like to be sure I'm >summarizing correctly before John and I respond on the >procedural issue. You are requesting the following: > >1) that the WG formally consider your individual > contribution as an alternative to the existing > WG deliverable for LDAPv3 Client Update Protocol. > >2) that the WG evaluate both documents based on > technical merit. > >3) that the WG emerge from that evaluation process > with a single document that will be processed > through a WG Last Call and submitted to the Ads > as the WG deliverable for LDAPv3 Client Update > Protocol. > >4) that the WG Last Call milestone for LCUP be > rescheduled further out in time to accommodate > the above. > >Did I miss any key points in your request? I believe you have captured the key points of my request. >Do any of them need clarification? I believe your summary of my request does not need clarification. >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Monday, May 26, 2003 11:11 AM >To: ietf-ldup@imc.org >Cc: Chris Apple; John Strassner >Subject: LDAP Client Update: consideration of alternative proposals > > >The LDUP WG is chartered to deliver: > o LDAPv3 Client Update > A protocol that enables an LDAP client to > synchronize with the content of a directory > information tree (DIT) stored by an LDAP server > and to be notified about the changes to that > content. > >Over the last few years, the WG has engineering a technical >solution for this deliverable. This solution is specified >in the I-D draft-ietf-ldup-lcup. Over the last 9 months or >so, Jong and I, acting on an individual basis, engineered >a technical solution for this deliverable. This solution is >specified in the I-D draft-zeilenga-ldup-sync. > >Each of these technical solutions are intended to fulfill >this deliverable. I also believe both sets of authors >believe that their approach best fulfills this deliverable. >It is also likely many members of this WG have formed opinions >as to which technical solution best fulfills this deliverable. >However, it is unclear to me whether both I-D, in particular >the most recent revisions of each, have been thoroughly >considered by the WG. > >WG I-Ds are implicitly viewed as being under WG consideration >and it hoped that significant number of WG members review the >I-D as it evolves. Individual I-Ds are not necessarily viewed >as being under WG consideration unless submitted to the WG for >consideration by their authors. They generally are reviewed by >few WG members until consideration is specifically requested. > >I now submit the draft-zeilenga-ldup-sync to the LDUP WG >for consideration as a technical solution to its "LDAP Client >Update" deliverable. I believe the latest revision, >draft-zeilenga-ldup-sync-02.txt, is suitable for progression. > >I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync >as technical alternatives and give thorough consideration to both. >It is up to the WG to decide which solution is technically >superior. As it is the function of the WG Chairs to manage the >group process, I defer procedural questions and issues to Chris >and John. > >As the differences between the approaches is fundamental in >their design, it will be difficult to compare them without some >basis to which can be measured against. It may be appropriate >for the WG to examine what kinds of applications it intends its >deliverable to be applicable to, what the requirements of these >applications are, and how each of the technical alternatives >measures up to these requirements. The WG should also consider >broader issues, such as chattiness and security considerations. >The WG should consider the appropriateness of the design and >other constraints each places upon implementations. > >In regards to the WG milestone: > > May 03 LDAPv3 Client Update Protocol I-D goes > to WG Last Call as Proposed Standard > >I would like the WG to defer this WG Last Call until it has >thoroughly consider both technical alternatives and reached a >consensus as to which alternative it would like to pursue. >Then that alternative should be prepared of WG Last Call as >the WG's "LDAPv3 Client Update Protocol I-D". I believe it >necessary to defer the WG Last Call as the WG first needs to >thoroughly consider both alternatives. > >I'd like to say a key design difference which is a major factor >in I considering draft-zeilenga-ldup-sync technically superior >to draft-ietf-ldup-lcup. In attempting to implement >draft-ietf-ldup-lcup, we found that requires server implementations >to maintain complete history information in order to provide >eventually convergent incremental refreshes. We found that >where the server only maintains simple state indicators such as >timestamps, it cannot generally provide eventually convergent >incremental refreshes. If the server maintains partial histories, >the server will be limited in cases where it can provide >eventually convergent incremental refreshes. In October 2002, >the WG consensus was declared on an alternative approach (but >later recanted). We implemented this approach and found that it >allowed all of the above implementation variants to provide >eventually convergent incremental refreshes. This was document >in documented in early revisions of draft-zeilenga-ldup-sync. >As a result of WG discussions about this approach, it was noted >that this approach didn't allow servers to take advantage of >histories they maintained. In our latest revision, we adopted >a hybrid approach which allows servers to take advantage of >histories they maintained. Hence, I believe draft-zeilenga-ldup-sync >is technical superior in that it does not place significant >implementation constraints in order to support eventually >convergent incremental refreshes while allowing implementations >take advantage of histories they maintain. There are, of course, >many other factors in my consideration and I am quite willing to >elaborate on these in subsequent discussions. Before doing so, >I will await direction from the chairs on how to proceed with >the consideration of the alternatives. > >Comments? > >Regards, Kurt From owner-ietf-ldup@mail.imc.org Thu May 29 00:45:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06746 for ; Thu, 29 May 2003 00:45:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T4cNAF081854 for ; Wed, 28 May 2003 21:38:23 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T4cNTQ081852 for ietf-ldup-bks; Wed, 28 May 2003 21:38:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T4cMAF081822 for ; Wed, 28 May 2003 21:38:23 -0700 (PDT) (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 May 2003 14:38:20 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Thu, 29 May 2003 14:38:20 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63811FD279@ausyms21.ca.com> Thread-Topic: LDAP Client Update: consideration of alternative proposals Thread-Index: AcMlmmste8Jkt6Z4Td2BgFJflPA1OAAASIaQ From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , Cc: X-OriginalArrivalTime: 29 May 2003 04:38:20.0739 (UTC) FILETIME=[21B8C930:01C3259C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4T4cNAF081848 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm simply the devil's advocate. Is the purpose to synchronise meta-directories? I don't know. Surely the real point is that you (Kurt) seem to have admitted that it is under-spacified, or potentially under-specified, by referring to the draft that would say how it is done. This seems to reflect LDUP in miniature. That attempt failed, so show why yours won't. Or, to cut the Gaudion knot, why should the WG go down that path (again). Ron -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 29 May 2003 14:23 To: capple@dsi-consulting.net Cc: Ramsay, Ron; ietf-ldup@imc.org Subject: RE: LDAP Client Update: consideration of alternative proposals At 08:48 PM 5/28/2003, Chris Apple wrote: >Does this mean that you agree with Ron's point? Or not? I don't dispute Ron's point that LCUP (draft-ietf-ldup-lcup) is meant to provide a simple synchronization tool. However, I added that I believe that LDAP-Sync (draft-zeilenga-ldup-sync) is also meant to provide a simple synchronization tool. I'll leave it to Ron to say whether he concurs with my additional point. >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >At 06:07 PM 5/28/2003, Ramsay, Ron wrote: >>1) LCUP is meant to provide a simple synchronisation tool, similar to >persistent search. > >I content that LDAP-Sync is meant to provide a simple >synchronization tool, similar to persistent search, as well. The >primary applications being considered for both solutions is the >same: meta-directory, address-books, etc.. From owner-ietf-ldup@mail.imc.org Thu May 29 01:48:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08011 for ; Thu, 29 May 2003 01:48:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T5b4AF083045 for ; Wed, 28 May 2003 22:37:04 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4T5b48Y083044 for ietf-ldup-bks; Wed, 28 May 2003 22:37:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T5b3AF083039 for ; Wed, 28 May 2003 22:37:03 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4T5axc6034336; Thu, 29 May 2003 05:37:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030528213812.0297ebb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 28 May 2003 22:34:07 -0700 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: , In-Reply-To: <1395B4B334FCC143B36AF788E68B63811FD279@ausyms21.ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:38 PM 5/28/2003, Ramsay, Ron wrote: >I'm simply the devil's advocate. Is the purpose to synchronise meta-directories? I don't know. In my opinion, the purpose of our deliverable is to provide a LDAP content synchronization mechanism suitable for a broad range of applications, including meta-directory applications. If its suitable for meta-directory, it also should be suitable for applications (like master/slave LDAP replication) which have similar content synchronization requirements. >Surely the real point is that you (Kurt) seem to have admitted that it is under-spacified, or potentially under-specified, by referring to the draft that would say how it is done. Surely not. When I said: >While Jong and I certainly intend to use LDAP Sync as a basis >for single-master replication, this I-D does not attempt to >detail how LDAP Sync might be used for single-master replication. >(We saved that for a future draft.) my point was that specification how a future LDAP Relication specification might use LDAP Sync is beyond the scope of draft-zeilenga-ldup-sync as draft-zeilenga-ldup-sync is intended to be a complete technical specification of the LDAP Content Sychronization Operation (a LDAPv3 client update protocol). Jong and I do believe draft-zeilenga-ldup-sync is complete. Kurt From owner-ietf-ldup@mail.imc.org Thu May 29 11:31:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07386 for ; Thu, 29 May 2003 11:31:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TFM3AF040960 for ; Thu, 29 May 2003 08:22:03 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4TFM3TF040959 for ietf-ldup-bks; Thu, 29 May 2003 08:22:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from REED (smtp.oncalldba.com [24.97.89.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TFLsAF040937 for ; Thu, 29 May 2003 08:21:54 -0700 (PDT) (envelope-from eer@OnCallDBA.COM) Received: from RMINC_DOM-MTA by REED with Novell_GroupWise; Thu, 29 May 2003 11:23:53 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 29 May 2003 11:23:35 -0400 From: "Ed Reed" To: , Cc: , , Subject: Re: LDAP Client Update: consideration of alternative proposals Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_BFE05A19.A7C6A833" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_BFE05A19.A7C6A833 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Generally, I agree with Ron's conclusion, that the WG should continue with LCUP as it's been discussed and documented, and not try to morph it into something new at this late date. The lesson I have been/ continue to learn is that the IETF standardization process lends itself well to documenting established concensus, and is lousy at documenting or arriving at new designs. Kurt's work should proceed, as individual contributions, until there are there are sufficient collaborators to constitute the core of a working group interested in further documentation of what they've learned through their joint development. I swear I'm at the point of wanting to see the results of the first interop face-to-face meeting before constituting a new work group! Think how the history of DNSSEC and IPSEC would be different! or LDUP, for that matter! Kurt has something worth while he wants to do - he should do it. Those who agree that's worth while should work with him on it. If those who do so are part of the LDUP work group, then they should speak up and be heard, now. If not, then Kurt's work should continue outside the WG. If so, then I'd say there might not be anything the WG should do but retire, while the competing designs settle out through competition in the market place which is more use to customers, if indeed one is better than the other. To turn the tables, I don't recall the charter of the group including a bake off of competing designs, the thorough evaluation of competing designs, etc. for LCUP. If such is the desire of the WG, then by all means change the charter ;-) Until then, in the absense of substantial support for Kurt's proposal, it sounds to me like the LCUP direction is pretty well set. It would be useful to have those interested in continuing the current LCUP direction voice their opinions, too, so the decision to go forward is not simply a matter of momentum. Ed ================= Ed Reed Novell, Inc. +1 585 624 2402 ereed@novell.com Note: Area code is 585 >>> Mark C Smith 5/28/2003 9:43:55 AM >>> Chris Apple wrote: > > 2) It is an open topic for discussion. Specifically, John > and I need to see comments (preferably with rationale) > about the value (or lack thereof) of proceeding as > Kurt suggests. Do not wait for further communication > from either John, Kurt, or I to start this discussion. > John and I don't want to have to resort to interpreting > silence on this issue in one way or another. > > Make your opinions known NOW! This applies to you even > if you are an author of one of the drafts covered by > Kurt's request. I suspect we are obligated to do something like what Kurt suggests: compare and contrast draft-ietf-ldup-lcup with draft-zeilenga-ldup-sync. If we don't, the ADs or IESG will probably make us do so eventually anyway. But I am concerned about process issues surrounding this situation. Did the LDUP WG chairs declare consensus prematurely or inappropriately? I assume the ADs are involved and will help sort this out. The authors of draft-ietf-ldup-lcup did give serious consideration to the ideas presented in draft-zeilenga-ldup-sync; some of that discussion took place on the mailing list a while ago and some was private mail among the authors of the two documents. It is not as if the alternative proposal was ignored by the WG or by the LCUP authors. One additional observation: to remain viable, the IETF needs to accept and encourage contributions from many people, not just a few people. When a WG deliverable that has been nearly completed is derailed at the last moment, the liklihood of the people who volunteered to work on that deliverable doing so in the future is greatly reduced. Now, one could argue that this is not a technical consideration but a political one. I would argue that it is both: the technical quality of the work done in the IETF (and the likelihood of widespread implementation) is greatly influenced by the number of different implementors who contribute. For LDAP related work, we seem to have fewer and fewer contributors each year. This is a problem. > 4) John and I will await confirmation/clarification of our > understanding of Kurt's request from Kurt before making > the request to our ADs to slip the milestone date to give > us enough time to consider whether the WG wishes to: > > a) proceed as Kurt suggests > b) stay with our presently chartered course of action, > albeit with some slippage > c) take another path completely different from those If you are asking for a vote, I vote for (b). But the larger procedural issues (and the ADs) will probably dictate what we must do... and I suspect we will end up doing something close to (a). -Mark Smith Netscape --=_BFE05A19.A7C6A833 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit
Generally, I agree with Ron's conclusion, that the WG should continue
with LCUP as it's been discussed and documented, and not try to morph
it into something new at this late date.
 
The lesson I have been/ continue to learn is that the IETF standardization
process lends itself well to documenting established concensus, and
is lousy at documenting or arriving at new designs.
 
Kurt's work should proceed, as individual contributions, until there are
there are sufficient collaborators to constitute the core of a working
group interested in further documentation of what they've learned through
their joint development.
 
I swear I'm at the point of wanting to see the results of the first interop
face-to-face meeting before constituting a new work group!  Think how
the history of DNSSEC and IPSEC would be different!  or LDUP, for that
matter!
 
Kurt has something worth while he wants to do - he should do it.  Those
who agree that's worth while should work with him on it.  If those who
do so are part of the LDUP work group, then they should speak up and
be heard, now.  If not, then Kurt's work should continue outside the
WG.  If so, then I'd say there might not be anything the WG should do
but retire, while the competing designs settle out through competition
in the market place which is more use to customers, if indeed one
is better than the other.
 
To turn the tables, I don't recall the charter of the group including a
bake off of competing designs, the thorough evaluation of competing
designs, etc. for LCUP.  If such is the desire of the WG, then by all
means change the charter ;-)  Until then, in the absense of substantial
support for Kurt's proposal, it sounds to me like the LCUP direction is
pretty well set.  It would be useful to have those interested in continuing
the current LCUP direction voice their opinions, too, so the decision
to go forward is not simply a matter of momentum.
 
Ed
 
=================
Ed Reed
Novell, Inc.
+1 585 624 2402
ereed@novell.com
Note:  Area code is 585

>>> Mark C Smith <mcs@netscape.com> 5/28/2003 9:43:55 AM >>>

Chris Apple wrote:
>
> 2) It is an open topic for discussion. Specifically, John
>    and I need to see comments (preferably with rationale)
>    about the value (or lack thereof) of proceeding as
>    Kurt suggests. Do not wait for further communication
>    from either John, Kurt, or I to start this discussion.
>    John and I don't want to have to resort to interpreting
>    silence on this issue in one way or another.
>
>    Make your opinions known NOW! This applies to you even
>    if you are an author of one of the drafts covered by
>    Kurt's request.

I suspect we are obligated to do something like what Kurt suggests:
compare and contrast draft-ietf-ldup-lcup with draft-zeilenga-ldup-sync.
  If we don't, the ADs or IESG will probably make us do so eventually
anyway.

But I am concerned about process issues surrounding this situation.  Did
the LDUP WG chairs declare consensus prematurely or inappropriately?  I
assume the ADs are involved and will help sort this out.  The authors of
draft-ietf-ldup-lcup did give serious consideration to the ideas
presented in draft-zeilenga-ldup-sync; some of that discussion took
place on the mailing list a while ago and some was private mail among
the authors of the two documents. It is not as if the alternative
proposal was ignored by the WG or by the LCUP authors.

One additional observation: to remain viable, the IETF needs to accept
and encourage contributions from many people, not just a few people.
When a WG deliverable that has been nearly completed is derailed at the
last moment, the liklihood of the people who volunteered to work on that
deliverable doing so in the future is greatly reduced. Now, one could
argue that this is not a technical consideration but a political one. I
would argue that it is both: the technical quality of the work done in
the IETF (and the likelihood of widespread implementation) is greatly
influenced by the number of different implementors who contribute. For
LDAP related work, we seem to have fewer and fewer contributors each
year. This is a problem.


> 4) John and I will await confirmation/clarification of our
>    understanding of Kurt's request from Kurt before making
>    the request to our ADs to slip the milestone date to give
>    us enough time to consider whether the WG wishes to:
>
>     a) proceed as Kurt suggests
>     b) stay with our presently chartered course of action,
>        albeit with some slippage
>     c) take another path completely different from those

If you are asking for a vote, I vote for (b). But the larger procedural
issues (and the ADs) will probably dictate what we must do... and I
suspect we will end up doing something close to (a).

-Mark Smith
  Netscape

--=_BFE05A19.A7C6A833-- From owner-ietf-ldup@mail.imc.org Thu May 29 11:45:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07834 for ; Thu, 29 May 2003 11:45:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TFdIAF042030 for ; Thu, 29 May 2003 08:39:18 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4TFdIlR042029 for ietf-ldup-bks; Thu, 29 May 2003 08:39:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TFd5AF042012 for ; Thu, 29 May 2003 08:39:12 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-193-11.pskn.east.verizon.net [151.204.193.11]) by dns.caledonia.net; Thu, 29 May 2003 09:33:13 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" , "'Ramsay, Ron'" , Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Thu, 29 May 2003 11:37:22 -0400 Organization: DSI-Consulting, Inc. Message-ID: <007901c325f8$42a28490$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030528213812.0297ebb0@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Speaking as a WG Member: The definition for the purpose of LCUP that you give below is broader than that which is currently chartered: o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. My opinion is that the existing LCUP draft contains a protocol specification which is tightly focused on what is chartered. My opinion is that it does so in a way that balances purely technical merit with realistic real world deployment concerns. Past discussions have indicated that the LCUP deliverable should have an applicability statement that at least in part outlines the conditions and perhaps even the classes of applications for which the protocol is thought to be a good match. What you have described below is actually not the purpose of the deliverable as chartered, but your interpretation that its applicability should encompass a wide range of applications and operational paradigms. Perhaps one source of difficulty in discussions related to this topic is that there is not agreement between yourself and the editors of LCUP as to how broad a range of applicability is appropriate for the LCUP deliverable? Speaking as WG Co-Chair: John and I need input from as many WG Members as possible on these questions: How would you define applicability for LCUP in terms of applications and operational paradigms? From your perspective, is that definition different for the existing WG deliverable and draft-zeilenga-ldup-sync? Again, it is very difficult to judge consensus based on silence. Please keep the discussion moving. Many thanks to those who have already taken the time to post their thoughts. In a prior posting, when I mentioned that we could handle wordsmithing of the applicability statement during WG Last Call for LCUP, I meant in part that we could address the addition of statements as needed to express application- and paradigm-specific applicability. We may still end up doing that to the LCUP deliverable during its WG Last Call regardless of which document the deliverable is based on. My next posting will be CC'd to the WG Mailing List and will be an official request to our ADs to slip the milestone date for LCUP WG Last Call. This will hopefully enable us to discuss this thread further without missing another deadline. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, May 29, 2003 1:34 AM To: Ramsay, Ron Cc: capple@dsi-consulting.net; ietf-ldup@imc.org Subject: RE: LDAP Client Update: consideration of alternative proposals At 09:38 PM 5/28/2003, Ramsay, Ron wrote: >I'm simply the devil's advocate. Is the purpose to synchronise meta-directories? I don't know. In my opinion, the purpose of our deliverable is to provide a LDAP content synchronization mechanism suitable for a broad range of applications, including meta-directory applications. If its suitable for meta-directory, it also should be suitable for applications (like master/slave LDAP replication) which have similar content synchronization requirements. >Surely the real point is that you (Kurt) seem to have admitted that it is under-spacified, or potentially under-specified, by referring to the draft that would say how it is done. Surely not. When I said: >While Jong and I certainly intend to use LDAP Sync as a basis >for single-master replication, this I-D does not attempt to >detail how LDAP Sync might be used for single-master replication. >(We saved that for a future draft.) my point was that specification how a future LDAP Relication specification might use LDAP Sync is beyond the scope of draft-zeilenga-ldup-sync as draft-zeilenga-ldup-sync is intended to be a complete technical specification of the LDAP Content Sychronization Operation (a LDAPv3 client update protocol). Jong and I do believe draft-zeilenga-ldup-sync is complete. Kurt From owner-ietf-ldup@mail.imc.org Thu May 29 12:20:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08897 for ; Thu, 29 May 2003 12:20:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TGEqAF043236 for ; Thu, 29 May 2003 09:14:52 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4TGEq26043235 for ietf-ldup-bks; Thu, 29 May 2003 09:14:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4TGEcAF043228 for ; Thu, 29 May 2003 09:14:44 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-193-11.pskn.east.verizon.net [151.204.193.11]) by dns.caledonia.net; Thu, 29 May 2003 10:08:47 -0600 Reply-To: From: "Chris Apple" To: "'Ted Hardie'" , Cc: , "'Kurt D. Zeilenga'" , "John Strassner" Subject: Request to Reschedule LCUP WG Last Call Milestone Date: Thu, 29 May 2003 12:12:49 -0400 Organization: DSI-Consulting, Inc. Message-ID: <008701c325fd$3a2df5b0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ted & Ned, John and I are requesting that the milestone date for LDUP's WG Last Call for the LCUP deliverable be rescheduled to accommodate consideration of Kurt's recent proposal to the WG. Here is a link to the original posting made by Kurt: http://www.imc.org/ietf-ldup/mail-archive/msg01754.html Here is a link to a reply from Kurt indicating his agreement with a summarized version of his request posted by myself to the WG mailing list: http://www.imc.org/ietf-ldup/mail-archive/msg01771.html My best guess for how long it will take us to establish consensus on proceeding as Kurt suggests, as the current charter indicates, or on some other way of proceeding would be near the end of June 2003. If consensus is established for supporting Kurt's proposal and the WG needs to compare, contrast, and discuss the merits of either approach to emerge with one document, I estimate that this might take an additional 2 - 3 months putting the WG Last Call for LCUP somewhere in the Sep-2003 or Oct-2003 time frame. If consensus is re-established for staying with the course that the WG has included in its charter, we should be able to initiate WG Last Call no later than July-2003. I do not know what to say about consensus for some other course of action because the only other one that's been suggested on the mailing list to date is that neither proposal should be progressed if there is insufficient interest expressed in them. So far no one else has agreed with that position. So, I think the most prudent action would be to slip the WG Last Call date for LCUP to July 2003 to enable us to consider Kurt's proposal. If consensus is established on following it, we could request another milestone date change to accommodate the amount of work we believe there is going to be in evaluating the two proposals and settling on one. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri May 30 13:39:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18334 for ; Fri, 30 May 2003 13:39:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UHQUAF040490 for ; Fri, 30 May 2003 10:26:30 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4UHQUbL040489 for ietf-ldup-bks; Fri, 30 May 2003 10:26:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UHQPAF040478 for ; Fri, 30 May 2003 10:26:26 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4UHQJXF015275 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 30 May 2003 10:26:19 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4UHQFuh023257; Fri, 30 May 2003 10:26:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <008701c325fd$3a2df5b0$6500a8c0@D7ST2111> References: <008701c325fd$3a2df5b0$6500a8c0@D7ST2111> Date: Fri, 30 May 2003 10:26:12 -0700 To: , From: hardie@qualcomm.com Subject: Re: Request to Reschedule LCUP WG Last Call Milestone Cc: , "'Kurt D. Zeilenga'" , "John Strassner" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, While I appreciate the efforts of all involved to make this an open process, I am concerned about this slip in dates. LDUP has already been on this track a long, long time. I will agree to the date for initiation of working group last call moving from "May 2003" to a date 2 weeks from May 27, 2003, when the Chairs issued the call to the working group asking for explicit comments on Kurt's proposal to reconsider. Since this is the period of a usual last call, this seems to me to give adequate time to raise issues (even if not to resolve them). If there has been substantial comment by that time indicating either 1) the working group has come to consensus that it should reconsider its current decision or 2) there are "show-stopper" class problems with the existing specification, then further delay can be discussed. Without either of those being present, though, a delay which would push the initiation of working group last call past the Vienna meeting seems unwarranted. I am particularly concerned that this means any drafts responding to issues raised during last call will have to be distributed informally, rather than via the i-d directories, and I urge the chairs to take advantage of the ability to pre-populate meeting materials as a way of limiting this disadvantage. If a further delay is needed, a concise description of the technical issues which led to reconsideration of working group consensus or which stopped the show on the existing draft should be composed by the working group as a note to the IESG on the delay. I would expect those proposing the delay (Kurt, in this case, and those supporting his view) would take the lead in providing that text. regards, Ted Hardie At 12:12 PM -0400 5/29/03, Chris Apple wrote: >Ted & Ned, > >John and I are requesting that the milestone date for >LDUP's WG Last Call for the LCUP deliverable be rescheduled >to accommodate consideration of Kurt's recent proposal >to the WG. > >Here is a link to the original posting made by Kurt: > >http://www.imc.org/ietf-ldup/mail-archive/msg01754.html > >Here is a link to a reply from Kurt indicating his >agreement with a summarized version of his request >posted by myself to the WG mailing list: > >http://www.imc.org/ietf-ldup/mail-archive/msg01771.html > >My best guess for how long it will take us to establish >consensus on proceeding as Kurt suggests, as the current >charter indicates, or on some other way of proceeding >would be near the end of June 2003. > >If consensus is established for supporting Kurt's proposal >and the WG needs to compare, contrast, and discuss the merits >of either approach to emerge with one document, I estimate >that this might take an additional 2 - 3 months putting the >WG Last Call for LCUP somewhere in the Sep-2003 or Oct-2003 >time frame. > >If consensus is re-established for staying with the course >that the WG has included in its charter, we should be >able to initiate WG Last Call no later than July-2003. > >I do not know what to say about consensus for some other >course of action because the only other one that's been >suggested on the mailing list to date is that neither >proposal should be progressed if there is insufficient >interest expressed in them. So far no one else has >agreed with that position. > >So, I think the most prudent action would be to slip >the WG Last Call date for LCUP to July 2003 to enable >us to consider Kurt's proposal. If consensus is >established on following it, we could request another >milestone date change to accommodate the amount of work >we believe there is going to be in evaluating the two >proposals and settling on one. > > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri May 30 16:26:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26520 for ; Fri, 30 May 2003 16:26:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UKK2AF050542 for ; Fri, 30 May 2003 13:20:02 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4UKK2j6050541 for ietf-ldup-bks; Fri, 30 May 2003 13:20:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UKIiAF050497 for ; Fri, 30 May 2003 13:18:51 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-193-11.pskn.east.verizon.net [151.204.193.11]) by dns.caledonia.net; Fri, 30 May 2003 14:11:59 -0600 Reply-To: From: "Chris Apple" To: , Cc: "'Kurt D. Zeilenga'" , "'John Strassner'" , Subject: RE: Request to Reschedule LCUP WG Last Call Milestone Date: Fri, 30 May 2003 16:16:33 -0400 Organization: DSI-Consulting, Inc. Message-ID: <00cd01c326e8$799630a0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ted, Thanks for the response. WG Members, Per Ted's response below, the WG Last Call for LCUP is now rescheduled to take place on Jun 12, 2003. With regard to Kurt's proposal, the discussion period on considering it will extend through 1700 US ET on June 10, 2003. Please also take note of the point Ted makes in his response about identifying showstopper issues with the existing LCUP document. If you believe any exist, you should describe them in plain language on the mailing list. John and I will issue a summary statement of WG consensus established during this discussion period on June 11, 2003. The next step will either be to proceed with WG Last Call for LCUP as previously planned or to request additional milestone and possibly charter text changes based on the consensus to accommodate an alternate course of direction such as that described in Kurt's proposal. Specifically how we will proceed as a WG depends on the discussion posted to the mailing list through the deadline established above. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: Friday, May 30, 2003 1:26 PM To: capple@dsi-consulting.net; ned.freed@mrochek.com Cc: ietf-ldup@imc.org; 'Kurt D. Zeilenga'; John Strassner Subject: Re: Request to Reschedule LCUP WG Last Call Milestone Folks, While I appreciate the efforts of all involved to make this an open process, I am concerned about this slip in dates. LDUP has already been on this track a long, long time. I will agree to the date for initiation of working group last call moving from "May 2003" to a date 2 weeks from May 27, 2003, when the Chairs issued the call to the working group asking for explicit comments on Kurt's proposal to reconsider. Since this is the period of a usual last call, this seems to me to give adequate time to raise issues (even if not to resolve them). If there has been substantial comment by that time indicating either 1) the working group has come to consensus that it should reconsider its current decision or 2) there are "show-stopper" class problems with the existing specification, then further delay can be discussed. Without either of those being present, though, a delay which would push the initiation of working group last call past the Vienna meeting seems unwarranted. I am particularly concerned that this means any drafts responding to issues raised during last call will have to be distributed informally, rather than via the i-d directories, and I urge the chairs to take advantage of the ability to pre-populate meeting materials as a way of limiting this disadvantage. If a further delay is needed, a concise description of the technical issues which led to reconsideration of working group consensus or which stopped the show on the existing draft should be composed by the working group as a note to the IESG on the delay. I would expect those proposing the delay (Kurt, in this case, and those supporting his view) would take the lead in providing that text. regards, Ted Hardie At 12:12 PM -0400 5/29/03, Chris Apple wrote: >Ted & Ned, > >John and I are requesting that the milestone date for >LDUP's WG Last Call for the LCUP deliverable be rescheduled >to accommodate consideration of Kurt's recent proposal >to the WG. > >Here is a link to the original posting made by Kurt: > >http://www.imc.org/ietf-ldup/mail-archive/msg01754.html > >Here is a link to a reply from Kurt indicating his >agreement with a summarized version of his request >posted by myself to the WG mailing list: > >http://www.imc.org/ietf-ldup/mail-archive/msg01771.html > >My best guess for how long it will take us to establish >consensus on proceeding as Kurt suggests, as the current >charter indicates, or on some other way of proceeding >would be near the end of June 2003. > >If consensus is established for supporting Kurt's proposal >and the WG needs to compare, contrast, and discuss the merits >of either approach to emerge with one document, I estimate >that this might take an additional 2 - 3 months putting the >WG Last Call for LCUP somewhere in the Sep-2003 or Oct-2003 >time frame. > >If consensus is re-established for staying with the course >that the WG has included in its charter, we should be >able to initiate WG Last Call no later than July-2003. > >I do not know what to say about consensus for some other >course of action because the only other one that's been >suggested on the mailing list to date is that neither >proposal should be progressed if there is insufficient >interest expressed in them. So far no one else has >agreed with that position. > >So, I think the most prudent action would be to slip >the WG Last Call date for LCUP to July 2003 to enable >us to consider Kurt's proposal. If consensus is >established on following it, we could request another >milestone date change to accommodate the amount of work >we believe there is going to be in evaluating the two >proposals and settling on one. > > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri May 30 16:58:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27885 for ; Fri, 30 May 2003 16:58:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UKndAF051361 for ; Fri, 30 May 2003 13:49:39 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4UKndNj051360 for ietf-ldup-bks; Fri, 30 May 2003 13:49:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UKnIAF051347 for ; Fri, 30 May 2003 13:49:34 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-193-11.pskn.east.verizon.net [151.204.193.11]) by dns.caledonia.net; Fri, 30 May 2003 14:43:13 -0600 Reply-To: From: "Chris Apple" To: Subject: FW: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 2003) Date: Fri, 30 May 2003 16:48:17 -0400 Organization: DSI-Consulting, Inc. Message-ID: <00d001c326ec$d5adf270$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4UKndAF051355 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit FYI. I doubt that LDUP needs to be concerned with the cut-off date for new submissions (*-00.txt). But please take note of the fact that there are now two different deadlines (one for new and one for revised) for submitting I-Ds that are to be discussed at the next IETF Meeting in Vienna. If you find that you have a need to publish *new* drafts under draft-ietf-ldup and wish to have them considered during the upcoming IETF Meeting, please notify John and I of that no later than 1700 US ET on June 15, 2003 (preferably earlier than that). John and I have to submit approval for publication of these new I-D's by Jun 16, 2003. If such approval is not submitted by us, the draft won't be published even if it is submitted by June 23, 2003. The cut-off date for submitting revisions of existing WG documents is 09:00 US ET on June 30, 2003. Note that this is 9 AM or approximately start of business on the US East Coast. You do *not* have until the end of the day on June 30, 2003. Please make every effort to update your drafts and submit them sometime on or before June 29, 2003 to allow for mail bounces and other delivery problems. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of Internet-Drafts Administrator Sent: Friday, May 30, 2003 12:11 PM To: IETF-Announce: Subject: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 2003) NOTE: There are two (2) Internet-Draft Cutoff dates June 23rd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 23rd, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 16th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 23rd will NOT be accepted. June 30st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30st, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html