From owner-ietf-ldup@mail.imc.org Mon Feb 10 13:46: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 NAA20431 for ; Mon, 10 Feb 2003 13:46:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AIf3m12791 for ietf-ldup-bks; Mon, 10 Feb 2003 10:41:03 -0800 (PST) Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AIf2d12786 for ; Mon, 10 Feb 2003 10:41:02 -0800 (PST) Received: from vmms10.verisignmail.com (vmms10.verisignmail.com [216.168.230.165] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ORJ30284; Mon, 10 Feb 2003 13:41:00 -0500 (EST) Received: from amalfisystems.com ([208.253.227.3]) by vmms10.verisignmail.com (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AES05791; Mon, 10 Feb 2003 13:40:23 -0500 (EST) Date: Mon, 10 Feb 2003 10:39:42 -0800 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Client update protocol From: Randy Turner To: ietf-ldup@imc.org Content-Transfer-Encoding: 7bit Message-Id: <049B9806-3D27-11D7-BC1B-0030656A4646@amalfisystems.com> X-Mailer: Apple Mail (2.551) Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello all, I recently read over the LCUP document and this text looks very good for DIT synchronization. What I am looking for is some type of "event" mechanism to trigger a client to connect/bind and initiate LCUP. This would require the directory server to have knowledge of "who" is interested in being notified of DIT updates. I may have 500,000 clients for a directory, and I would prefer not to have to have the clients poll the server. If a particular LCUP context is modified, I would like some type of async notification sent to interested parties. Most of the work of actually synchronizing the DIT is covered by the LCUP document, I just need the clients to be notified "when" to perform LCUP. Ideally, the trigger mechanism would be some type of lightweight, connectionless notification, similar to an SNMP trap but more specific. There is activity going on with global, scalable event notification architectures that is not specific to any IETF work, and we are looking into this. However, I wanted to make sure I understand the taxonomy of any and all work related to solving this type of problem. If there is work going on in this area in this, or another working group, I would appreciate any and all pointers, or other comments. Thanks in advance, Randy From owner-ietf-ldup@mail.imc.org Mon Feb 10 16:31: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 QAA26742 for ; Mon, 10 Feb 2003 16:31:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ALRF119257 for ietf-ldup-bks; Mon, 10 Feb 2003 13:27:15 -0800 (PST) Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ALR9d19250 for ; Mon, 10 Feb 2003 13:27:09 -0800 (PST) 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 h1ALR6Y04540 for ; Mon, 10 Feb 2003 13:27:06 -0800 (PST) Received: from netscape.com ([10.169.192.67]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HA43L600.6NB; Mon, 10 Feb 2003 13:27:06 -0800 Message-ID: <3E4818EC.1060000@netscape.com> Date: Mon, 10 Feb 2003 14:26:04 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Turner CC: ietf-ldup@imc.org Subject: Re: Client update protocol References: <049B9806-3D27-11D7-BC1B-0030656A4646@amalfisystems.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020000040506060108010403" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020000040506060108010403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randy Turner wrote: > Hello all, > > I recently read over the LCUP document and this text looks very good > for DIT synchronization. What I am looking for is some type of > "event" mechanism to trigger a client to connect/bind and initiate > LCUP. This would require the directory server to have knowledge of > "who" is interested in being notified of DIT updates. I may have > 500,000 clients for a directory, and I would prefer not to have to > have the clients poll the server. If a particular LCUP context is > modified, I would like some type of async notification sent to > interested parties. Most of the work of actually synchronizing the > DIT is covered by the LCUP document, I just need the clients to be > notified "when" to perform LCUP. Ideally, the trigger mechanism would > be some type of lightweight, connectionless notification, similar to > an SNMP trap but more specific. How many "interested parties" will there be? Will the "interested parties" actually initiate an LCUP request? A standard LDAP server is not designed to initiate connections to other servers or clients (except in the case of replication, but that is not a standard yet, nor would it likely serve your purpose). Some LDAP servers do support callbacks or triggers that usually involve having to write your own plugin or some other mechanism. This sounds like the sort of thing that message bus/queue architectures are trying to solve. You could have an LDAP client that issues an LCUP persistent search against an LDAP server, and the client would put a message on the bus/queue every time it received an LCUP response. Other clients register with the bus/queue and receive BTW, for those interested, we are still working on the LCUP 04 draft and hope to have something very soon. > There is activity going on with global, scalable event notification > architectures that is not specific to any IETF work, and we are > looking into this. However, I wanted to make sure I understand the > taxonomy of any and all work related to solving this type of problem. Can you provide more information about this work? > If there is work going on in this area in this, or another working > group, I would appreciate any and all pointers, or other comments. > > Thanks in advance, > Randy > --------------ms020000040506060108010403 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 oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMTAy MTI2MDRaMCMGCSqGSIb3DQEJBDEWBBRqp+nWk43YRSK/woTGKf1F3n9FvTBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAVsil THbBOoxP714+3md20x81BySFCS5kcnKBCsC/rEbfNowz5KsHrCgA3LLT1QFrC2fiyDByEJDO 60hRdQr1O6JSwbiX5/29Ova7AXgjNZAiTA8xWZZ/BPFjCtVqFawMNTEP9avL8tcHUYibPqMB mvaaUMN6DSE+bKvEYSsARjQAAAAAAAA= --------------ms020000040506060108010403-- From owner-ietf-ldup@mail.imc.org Tue Feb 11 12:55: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 MAA13160 for ; Tue, 11 Feb 2003 12:55:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BHslX08008 for ietf-ldup-bks; Tue, 11 Feb 2003 09:54:47 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BHskd08004 for ; Tue, 11 Feb 2003 09:54:46 -0800 (PST) Received: from [208.253.227.3] (helo=amalfisystems.com) by stork.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18iecJ-0007dG-00; Tue, 11 Feb 2003 09:54:47 -0800 Date: Tue, 11 Feb 2003 09:54:43 -0800 Subject: Re: Client update protocol Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-ldup@imc.org To: richm@netscape.com (Rich Megginson) From: Randy Turner In-Reply-To: <3E4818EC.1060000@netscape.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-ELNK-Trace: cec0be69abd072c3d780f4a490ca69564776905774d2ac4b245e35d454bdf9d6f0e9d3f43d2ece64350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Thanks for the reply. Regarding your earlier comments... I might have 30,000 LDAP clients that want to know if a particular LCUP context has changed. They might "subscribe" to this particular event so they get notified. Notification methods such as that suggested by persistent search (and variants) or polling (connect/bind/search) would be sub-optimal with this many clients potentially involved. The LCUP sync mechanism will work great...I just need a client to be "tapped on the shoulder" when it should connect/bind and issue the LCUP search method. The same entity that is notified, will be the same entity that issues the special LCUP context search. At an IETF meeting a couple of years ago I had a discussion about such a technique (before I actually had a need for it) during early discussions about CLDAP and how this type of scenario could be included in the problems addressed by CLDAP. Your suggestion about a "middleware" entity that maintains a persistent LCUP search sounds like it would be a good start, looking "northbound" to the source DIT. Looking back towards the clients, there would still be a need for clients to register their interest, as well as the actual lightweight delivery mechanism. If there had been an extensible "trap/inform" group in the MADMAN MIB, then that might be a potential solutions as well. Not perfect, but a step in the right direction. Ultimately, the solution will probably involve work going on outside the LDAP WG, again I'm just trying to find anyone with a problem domain similar to this. I don't remember the exact names of the projects regarding event notification systems...but if you do a google (or other) search for "scalable event notification", this will show you a set of starting points that I used for my own research. Most of the recent work has been in academia, but I believe there are implementations of these systems available, as well as some organizations looking to go commercial with similar technology. Thanks again for the reply, Randy On Monday, February 10, 2003, at 01:26 PM, Rich Megginson wrote: > Randy Turner wrote: > >> Hello all, >> >> I recently read over the LCUP document and this text looks very good >> for DIT synchronization. What I am looking for is some type of >> "event" mechanism to trigger a client to connect/bind and initiate >> LCUP. This would require the directory server to have knowledge of >> "who" is interested in being notified of DIT updates. I may have >> 500,000 clients for a directory, and I would prefer not to have to >> have the clients poll the server. If a particular LCUP context is >> modified, I would like some type of async notification sent to >> interested parties. Most of the work of actually synchronizing the >> DIT is covered by the LCUP document, I just need the clients to be >> notified "when" to perform LCUP. Ideally, the trigger mechanism would >> be some type of lightweight, connectionless notification, similar to >> an SNMP trap but more specific. > > How many "interested parties" will there be? Will the "interested > parties" actually initiate an LCUP request? > > A standard LDAP server is not designed to initiate connections to > other servers or clients (except in the case of replication, but that > is not a standard yet, nor would it likely serve your purpose). Some > LDAP servers do support callbacks or triggers that usually involve > having to write your own plugin or some other mechanism. > > This sounds like the sort of thing that message bus/queue > architectures are trying to solve. You could have an LDAP client that > issues an LCUP persistent search against an LDAP server, and the > client would put a message on the bus/queue every time it received an > LCUP response. Other clients register with the bus/queue and receive > > BTW, for those interested, we are still working on the LCUP 04 draft > and hope to have something very soon. > >> There is activity going on with global, scalable event notification >> architectures that is not specific to any IETF work, and we are >> looking into this. However, I wanted to make sure I understand the >> taxonomy of any and all work related to solving this type of problem. > > Can you provide more information about this work? > >> If there is work going on in this area in this, or another working >> group, I would appreciate any and all pointers, or other comments. >> >> Thanks in advance, >> Randy >> > > From owner-ietf-ldup@mail.imc.org Tue Feb 11 13:08:59 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 NAA13569 for ; Tue, 11 Feb 2003 13:08:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BI83j08385 for ietf-ldup-bks; Tue, 11 Feb 2003 10:08:03 -0800 (PST) Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BI81d08381 for ; Tue, 11 Feb 2003 10:08:01 -0800 (PST) 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 h1BI7wY25616 for ; Tue, 11 Feb 2003 10:07:58 -0800 (PST) Received: from netscape.com ([10.0.250.46]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HA5P1900.V5M; Tue, 11 Feb 2003 10:07:57 -0800 Message-ID: <3E493BBB.5010508@netscape.com> Date: Tue, 11 Feb 2003 11:06:51 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Turner CC: ietf-ldup@imc.org Subject: Re: Client update protocol References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020800090908020608090506" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020800090908020608090506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randy Turner wrote: > > Hi, > > Thanks for the reply. Regarding your earlier comments... > > I might have 30,000 LDAP clients that want to know if a particular > LCUP context has changed. They might "subscribe" to this particular > event so they get notified. Notification methods such as that > suggested by persistent search (and variants) or polling > (connect/bind/search) would be sub-optimal with this many clients > potentially involved. The LCUP sync mechanism will work great...I just > need a client to be "tapped on the shoulder" when it should > connect/bind and issue the LCUP search method. The same entity that > is notified, will be the same entity that issues the special LCUP > context search. Then, will you have 30,000 clients making LCUP search requests at the same time, if they are all interested in the same event? > At an IETF meeting a couple of years ago I had a discussion about such > a technique (before I actually had a need for it) during early > discussions about CLDAP and how this type of scenario could be > included in the problems addressed by CLDAP. This seems like a perfect application for multicast. Making 30000 simultaneous or sequential TCP/IP connections is sub optimal. > Your suggestion about a "middleware" entity that maintains a > persistent LCUP search sounds like it would be a good start, looking > "northbound" to the source DIT. Looking back towards the clients, > there would still be a need for clients to register their interest, as > well as the actual lightweight delivery mechanism. > > If there had been an extensible "trap/inform" group in the MADMAN MIB, > then that might be a potential solutions as well. Not perfect, but a > step in the right direction. Ultimately, the solution will probably > involve work going on outside the LDAP WG, again I'm just trying to > find anyone with a problem domain similar to this. > > I don't remember the exact names of the projects regarding event > notification systems...but if you do a google (or other) search for > "scalable event notification", this will show you a set of starting > points that I used for my own research. Most of the recent work has > been in academia, but I believe there are implementations of these > systems available, as well as some organizations looking to go > commercial with similar technology. > > Thanks again for the reply, > Randy > > > On Monday, February 10, 2003, at 01:26 PM, Rich Megginson wrote: > >> Randy Turner wrote: >> >>> Hello all, >>> >>> I recently read over the LCUP document and this text looks very good >>> for DIT synchronization. What I am looking for is some type of >>> "event" mechanism to trigger a client to connect/bind and initiate >>> LCUP. This would require the directory server to have knowledge of >>> "who" is interested in being notified of DIT updates. I may have >>> 500,000 clients for a directory, and I would prefer not to have to >>> have the clients poll the server. If a particular LCUP context is >>> modified, I would like some type of async notification sent to >>> interested parties. Most of the work of actually synchronizing the >>> DIT is covered by the LCUP document, I just need the clients to be >>> notified "when" to perform LCUP. Ideally, the trigger mechanism >>> would be some type of lightweight, connectionless notification, >>> similar to an SNMP trap but more specific. >> >> >> How many "interested parties" will there be? Will the "interested >> parties" actually initiate an LCUP request? >> >> A standard LDAP server is not designed to initiate connections to >> other servers or clients (except in the case of replication, but that >> is not a standard yet, nor would it likely serve your purpose). Some >> LDAP servers do support callbacks or triggers that usually involve >> having to write your own plugin or some other mechanism. >> >> This sounds like the sort of thing that message bus/queue >> architectures are trying to solve. You could have an LDAP client >> that issues an LCUP persistent search against an LDAP server, and the >> client would put a message on the bus/queue every time it received an >> LCUP response. Other clients register with the bus/queue and receive >> >> BTW, for those interested, we are still working on the LCUP 04 draft >> and hope to have something very soon. >> >>> There is activity going on with global, scalable event notification >>> architectures that is not specific to any IETF work, and we are >>> looking into this. However, I wanted to make sure I understand the >>> taxonomy of any and all work related to solving this type of problem. >> >> >> Can you provide more information about this work? >> >>> If there is work going on in this area in this, or another working >>> group, I would appreciate any and all pointers, or other comments. >>> >>> Thanks in advance, >>> Randy >>> >> >> > > --------------ms020800090908020608090506 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 oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMTEx ODA2NTFaMCMGCSqGSIb3DQEJBDEWBBRXzrph3DL9F/nNpq8W6fBdOrUHEjBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAeJNX hkHnlry5IbJb3KOoXU0hC9qTt15t6vtNDS4wYTr5bnyd+noD0tjLiBOUBIQxi+pXE+LLs8/7 STfov9fGndOWzR7ZIXMOPakCtg1fNC794C+K5cKTFpunwQXWvfc5AZ3cRS8/p56QZ8j/XHQm 3nfL804dcJ+4iqmAAhq1J8oAAAAAAAA= --------------ms020800090908020608090506-- From owner-ietf-ldup@mail.imc.org Tue Feb 11 14:14:20 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 OAA15708 for ; Tue, 11 Feb 2003 14:14:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BJE8t10780 for ietf-ldup-bks; Tue, 11 Feb 2003 11:14:08 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BJE2d10774 for ; Tue, 11 Feb 2003 11:14:02 -0800 (PST) Received: from [208.253.227.3] (helo=amalfisystems.com) by puffin.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18ifr1-0003HZ-00; Tue, 11 Feb 2003 11:14:03 -0800 Date: Tue, 11 Feb 2003 11:13:55 -0800 Subject: Re: Client update protocol Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-ldup@imc.org To: richm@netscape.com (Rich Megginson) From: Randy Turner In-Reply-To: <3E493BBB.5010508@netscape.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-ELNK-Trace: cec0be69abd072c3d780f4a490ca69564776905774d2ac4b3e04aa0a10c444176bc6570de03c340a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit If all 30,000 clients have registered interest in the same context, then yes it's possible to get 30,000 LCUP request, although it would be easy to arrange for these requests to be load-balanced or intelligently skewed so they are not simultaneous to one instance of a server. In my particular application, only a small fraction would register interest in the exact same DIT context, but it would be prudent to design the system to handle the worst case loading. Regarding multicast, you are right, some type of multicast might be appropriate. However, my experience with inter-AS (really between different service provider networks) multicast has been fraught with business issues rather than technical issues, so I'm not sure I can rely on multicast being a "generally available" solution to the problem. This may have changed in the last year or so. Randy On Tuesday, February 11, 2003, at 10:06 AM, Rich Megginson wrote: > Randy Turner wrote: > >> >> Hi, >> >> Thanks for the reply. Regarding your earlier comments... >> >> I might have 30,000 LDAP clients that want to know if a particular >> LCUP context has changed. They might "subscribe" to this particular >> event so they get notified. Notification methods such as that >> suggested by persistent search (and variants) or polling >> (connect/bind/search) would be sub-optimal with this many clients >> potentially involved. The LCUP sync mechanism will work great...I >> just need a client to be "tapped on the shoulder" when it should >> connect/bind and issue the LCUP search method. The same entity that >> is notified, will be the same entity that issues the special LCUP >> context search. > > Then, will you have 30,000 clients making LCUP search requests at the > same time, if they are all interested in the same event? > >> At an IETF meeting a couple of years ago I had a discussion about >> such a technique (before I actually had a need for it) during early >> discussions about CLDAP and how this type of scenario could be >> included in the problems addressed by CLDAP. > > This seems like a perfect application for multicast. Making 30000 > simultaneous or sequential TCP/IP connections is sub optimal. > >> Your suggestion about a "middleware" entity that maintains a >> persistent LCUP search sounds like it would be a good start, looking >> "northbound" to the source DIT. Looking back towards the clients, >> there would still be a need for clients to register their interest, >> as well as the actual lightweight delivery mechanism. >> >> If there had been an extensible "trap/inform" group in the MADMAN >> MIB, then that might be a potential solutions as well. Not perfect, >> but a step in the right direction. Ultimately, the solution will >> probably involve work going on outside the LDAP WG, again I'm just >> trying to find anyone with a problem domain similar to this. >> >> I don't remember the exact names of the projects regarding event >> notification systems...but if you do a google (or other) search for >> "scalable event notification", this will show you a set of starting >> points that I used for my own research. Most of the recent work has >> been in academia, but I believe there are implementations of these >> systems available, as well as some organizations looking to go >> commercial with similar technology. >> >> Thanks again for the reply, >> Randy >> >> >> On Monday, February 10, 2003, at 01:26 PM, Rich Megginson wrote: >> >>> Randy Turner wrote: >>> >>>> Hello all, >>>> >>>> I recently read over the LCUP document and this text looks very >>>> good for DIT synchronization. What I am looking for is some type >>>> of "event" mechanism to trigger a client to connect/bind and >>>> initiate LCUP. This would require the directory server to have >>>> knowledge of "who" is interested in being notified of DIT updates. >>>> I may have 500,000 clients for a directory, and I would prefer not >>>> to have to have the clients poll the server. If a particular LCUP >>>> context is modified, I would like some type of async notification >>>> sent to interested parties. Most of the work of actually >>>> synchronizing the DIT is covered by the LCUP document, I just need >>>> the clients to be notified "when" to perform LCUP. Ideally, the >>>> trigger mechanism would be some type of lightweight, connectionless >>>> notification, similar to an SNMP trap but more specific. >>> >>> >>> How many "interested parties" will there be? Will the "interested >>> parties" actually initiate an LCUP request? >>> >>> A standard LDAP server is not designed to initiate connections to >>> other servers or clients (except in the case of replication, but >>> that is not a standard yet, nor would it likely serve your purpose). >>> Some LDAP servers do support callbacks or triggers that usually >>> involve having to write your own plugin or some other mechanism. >>> >>> This sounds like the sort of thing that message bus/queue >>> architectures are trying to solve. You could have an LDAP client >>> that issues an LCUP persistent search against an LDAP server, and >>> the client would put a message on the bus/queue every time it >>> received an LCUP response. Other clients register with the >>> bus/queue and receive >>> >>> BTW, for those interested, we are still working on the LCUP 04 draft >>> and hope to have something very soon. >>> >>>> There is activity going on with global, scalable event notification >>>> architectures that is not specific to any IETF work, and we are >>>> looking into this. However, I wanted to make sure I understand the >>>> taxonomy of any and all work related to solving this type of >>>> problem. >>> >>> >>> Can you provide more information about this work? >>> >>>> If there is work going on in this area in this, or another working >>>> group, I would appreciate any and all pointers, or other comments. >>>> >>>> Thanks in advance, >>>> Randy >>>> >>> >>> >> >> > > From owner-ietf-ldup@mail.imc.org Wed Feb 12 16:41:57 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 QAA16629 for ; Wed, 12 Feb 2003 16:41:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CLdBq07263 for ietf-ldup-bks; Wed, 12 Feb 2003 13:39:11 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CLd8d07259 for ; Wed, 12 Feb 2003 13:39:09 -0800 (PST) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Wed, 12 Feb 2003 14:39:18 -0700 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: LDUP WG Session Requested Date: Wed, 12 Feb 2003 16:38:13 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000001c2d2df$0ced8d70$3400000a@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.1106 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 in San Francisco for LDUP. Likely agenda items will include: 1) LCUP Status - Ready for WG Last Call soon? 2) Consensus of "Concluding LDUP" Thread 3) Charter Revision Discussion Please send requests for additional agenda items to either the list or myself directly. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Thu Feb 13 14:54:38 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 OAA23488 for ; Thu, 13 Feb 2003 14:54:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DJs9323507 for ietf-ldup-bks; Thu, 13 Feb 2003 11:54:09 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJs6d23503 for ; Thu, 13 Feb 2003 11:54:07 -0800 (PST) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Thu, 13 Feb 2003 12:54:03 -0700 Reply-To: From: "Chris Apple" To: Cc: "'John Strassner'" Subject: RE: LDUP WG Session Requested Date: Thu, 13 Feb 2003 14:52:49 -0500 Organization: DSI-Consulting, Inc. Message-ID: <008501c2d399$88f91f00$3400000a@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: <000001c2d2df$0ced8d70$3400000a@D7ST2111> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The LDUP WG Session is now showing on the IETF Web Site as on the same day as LDAPBIS: 1300-1400 Afternoon Sessions I APP ldup LDAP Duplication/Replication/Update Protocols WG 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: Wednesday, February 12, 2003 4:38 PM To: ietf-ldup@imc.org Cc: John Strassner Subject: LDUP WG Session Requested I have requested a 1-hour meeting slot in San Francisco for LDUP. Likely agenda items will include: 1) LCUP Status - Ready for WG Last Call soon? 2) Consensus of "Concluding LDUP" Thread 3) Charter Revision Discussion Please send requests for additional agenda items to either the list or myself directly. 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 Feb 21 13:34:59 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 NAA10159 for ; Fri, 21 Feb 2003 13:34:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LIUpu16520 for ietf-ldup-bks; Fri, 21 Feb 2003 10:30:51 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LIUjd16496 for ; Fri, 21 Feb 2003 10:30:50 -0800 (PST) Received: from D7ST2111 (pool-151-204-211-42.pskn.east.verizon.net [151.204.211.42]) by dns.caledonia.net; Fri, 21 Feb 2003 11:29:46 -0700 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: RE: Proposals for Concluding LDUP Date: Fri, 21 Feb 2003 13:30:03 -0500 Organization: DSI-Consulting, Inc. Message-ID: <004f01c2d9d7$43586de0$0500a8c0@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.1106 In-reply-to: <000201c2a220$f8ef4a00$0400a8c0@D7ST2111> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Consensus has been established for Proposal Number 1 below. This interpretation of consensus is based on a review of the WG mailing list and consideration of the views posted by myself on behalf of WG members who chose to comment on the issue verbally rather than post to the list. This means that the WG has a few ToDos: 1) Establish consensus on a WG Charter Revision covering this change in direction and submit to Apps ADs for consideration. 2) Revise all WG I-Ds that are currently expired. 3) Ensure adequate coverage of documents by editors (some folks have said they can no longer justify the effort required of a document editor; we have had alternate volunteers for most of these documents). John and I will initiate ToDo-1 by preparing a WG Charter revision proposal and post to the WG mailing List prior to the start of the IETF Meeting in San Francisco. We can discuss it during the WG session as well as on the mailing list. With respect to ToDo-2: I expect all document editors to revise or resubmit for publication their currently expired I-Ds BEFORE the March 3rd deadline. Please do this even if there are no technical or otherwise substantive changes to the drafts. If you are unable or unwilling to do that please notify John and I so that we're aware of it. If you are one of the editors who volunteered to take over editing a document for someone else who had to move on, please make arrangements with the former editor to obtain their most recent version. Often Google will help you find a captured version of even an expired I-D as a last resort. If you volunteered, you know who you are. ToDo-3 will have to be sorted out by John and I once we have seen the results of ToDo-2. Chris Apple and John Strassner 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: Thursday, December 12, 2002 3:57 PM To: ietf-ldup@imc.org Subject: Proposals for Concluding LDUP As mentioned in the proposed WG meeting minutes, there are currently two proposals on the table for concluding LDUP: 1) A proposal from the co-chairs. Summarized as follows: A) Publish LCUP spec as Proposed Standard after successful passage of a WG Last Call. B) Publish remaining WG documents as either Informational or Experimental after resolving gross inconsistencies and explicitly identifying areas where the WG was unable to achieve consensus in those documents. C) Reference X.500 BAC in the General Usage Profile as well as the X.500 Administrative Model (perhaps from the drafts by Steven L. and Kurt Z., perhaps directly from the X.500 Recommendations themselves) D) Reference X.500 BAC and Administrative Model in other WG documents as needed. E) Documents should enter WG Last Call on or before the July 2003 IETF Meeting. F) Conclude LDUP when last document is published as an RFC. 2) A proposal from Mark Wahl. Summarized as follows: A) Publish LCUP as a Proposed Standard after successful passage of WG Last Call. B) Conclude LDUP once LCUP spec is published as an RFC. C) Convert all WG documents to individual I-D contributions and allow editors to work out consensus (or not) outside of the context of a WG. I have spoke with a number of folks who have opinions about the pros and cons of either approach. Please post your views to the list on the pros and cons of these approaches and indicate which way you are leaning at this time. Also please feel free to post your observations about any inaccuracies in the summaries of the proposals above. 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 Feb 28 01:00: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 BAA04596 for ; Fri, 28 Feb 2003 01:00:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S5xf521463 for ietf-ldup-bks; Thu, 27 Feb 2003 21:59:41 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S5xcY21459 for ; Thu, 27 Feb 2003 21:59:39 -0800 (PST) Received: from D7ST2111 (pool-151-204-214-12.pskn.east.verizon.net [151.204.214.12]) by dns.caledonia.net; Thu, 27 Feb 2003 22:59:11 -0700 Reply-To: From: "Chris Apple" To: Cc: "'John Strassner'" Subject: URGENT RE: Proposals for Concluding LDUP Date: Fri, 28 Feb 2003 00:59:06 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000e01c2deee$81b6d1a0$0400a8c0@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.1106 In-Reply-To: <004f01c2d9d7$43586de0$0500a8c0@D7ST2111> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1S5xeY21460 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit To date, I have heard from one editor of a single document about the status of their I-D. Please respond directly to myself and John Strassner with an acknowledgement of this e-mail and an indication of your intent with respect to meeting the March 3rd publishing deadline for I-Ds. Its fine to CC: the LDUP list also, but John and I need to know of your intent so that discussion during the WG Meeting is relevant and meaningful. 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, February 21, 2003 1:30 PM To: ietf-ldup@imc.org Cc: John Strassner Subject: RE: Proposals for Concluding LDUP Consensus has been established for Proposal Number 1 below. This interpretation of consensus is based on a review of the WG mailing list and consideration of the views posted by myself on behalf of WG members who chose to comment on the issue verbally rather than post to the list. This means that the WG has a few ToDos: 1) Establish consensus on a WG Charter Revision covering this change in direction and submit to Apps ADs for consideration. 2) Revise all WG I-Ds that are currently expired. 3) Ensure adequate coverage of documents by editors (some folks have said they can no longer justify the effort required of a document editor; we have had alternate volunteers for most of these documents). John and I will initiate ToDo-1 by preparing a WG Charter revision proposal and post to the WG mailing List prior to the start of the IETF Meeting in San Francisco. We can discuss it during the WG session as well as on the mailing list. With respect to ToDo-2: I expect all document editors to revise or resubmit for publication their currently expired I-Ds BEFORE the March 3rd deadline. Please do this even if there are no technical or otherwise substantive changes to the drafts. If you are unable or unwilling to do that please notify John and I so that we're aware of it. If you are one of the editors who volunteered to take over editing a document for someone else who had to move on, please make arrangements with the former editor to obtain their most recent version. Often Google will help you find a captured version of even an expired I-D as a last resort. If you volunteered, you know who you are. ToDo-3 will have to be sorted out by John and I once we have seen the results of ToDo-2. Chris Apple and John Strassner 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: Thursday, December 12, 2002 3:57 PM To: ietf-ldup@imc.org Subject: Proposals for Concluding LDUP As mentioned in the proposed WG meeting minutes, there are currently two proposals on the table for concluding LDUP: 1) A proposal from the co-chairs. Summarized as follows: A) Publish LCUP spec as Proposed Standard after successful passage of a WG Last Call. B) Publish remaining WG documents as either Informational or Experimental after resolving gross inconsistencies and explicitly identifying areas where the WG was unable to achieve consensus in those documents. C) Reference X.500 BAC in the General Usage Profile as well as the X.500 Administrative Model (perhaps from the drafts by Steven L. and Kurt Z., perhaps directly from the X.500 Recommendations themselves) D) Reference X.500 BAC and Administrative Model in other WG documents as needed. E) Documents should enter WG Last Call on or before the July 2003 IETF Meeting. F) Conclude LDUP when last document is published as an RFC. 2) A proposal from Mark Wahl. Summarized as follows: A) Publish LCUP as a Proposed Standard after successful passage of WG Last Call. B) Conclude LDUP once LCUP spec is published as an RFC. C) Convert all WG documents to individual I-D contributions and allow editors to work out consensus (or not) outside of the context of a WG. I have spoke with a number of folks who have opinions about the pros and cons of either approach. Please post your views to the list on the pros and cons of these approaches and indicate which way you are leaning at this time. Also please feel free to post your observations about any inaccuracies in the summaries of the proposals above. 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 Feb 28 09:24:39 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 JAA29577 for ; Fri, 28 Feb 2003 09:24:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SENqo13458 for ietf-ldup-bks; Fri, 28 Feb 2003 06:23:52 -0800 (PST) Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SENkY13450 for ; Fri, 28 Feb 2003 06:23:46 -0800 (PST) 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 h1SENdR09001 for ; Fri, 28 Feb 2003 06:23:39 -0800 (PST) Received: from netscape.com ([10.169.192.46]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HB0VZ300.FP5; Fri, 28 Feb 2003 06:23:27 -0800 Message-ID: <3E5F709B.3020808@netscape.com> Date: Fri, 28 Feb 2003 07:22:19 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: capple@dsi-consulting.net CC: ietf-ldup@imc.org, "'John Strassner'" Subject: Re: URGENT RE: Proposals for Concluding LDUP References: <000e01c2deee$81b6d1a0$0400a8c0@D7ST2111> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050409030006040907070700" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050409030006040907070700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chris Apple wrote: >To date, I have heard from one editor of a single document about the >status of their I-D. > >Please respond directly to myself and John Strassner with an acknowledgement >of this e-mail and an indication of your intent with respect to meeting >the March 3rd publishing deadline for I-Ds. Its fine to CC: the LDUP list >also, but John and I need to know of your intent so that discussion during >the WG Meeting is relevant and meaningful. > I will submit LCUP-04 by the deadline. > >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, February 21, 2003 1:30 PM >To: ietf-ldup@imc.org >Cc: John Strassner >Subject: RE: Proposals for Concluding LDUP > > > >Consensus has been established for Proposal Number 1 below. This >interpretation of consensus is based on a review of the WG mailing >list and consideration of the views posted by myself on behalf of >WG members who chose to comment on the issue verbally rather than >post to the list. > >This means that the WG has a few ToDos: > >1) Establish consensus on a WG Charter Revision covering this change > in direction and submit to Apps ADs for consideration. > >2) Revise all WG I-Ds that are currently expired. > >3) Ensure adequate coverage of documents by editors (some folks have > said they can no longer justify the effort required of a document > editor; we have had alternate volunteers for most of these documents). > >John and I will initiate ToDo-1 by preparing a WG Charter revision >proposal and post to the WG mailing List prior to the start of the >IETF Meeting in San Francisco. We can discuss it during the WG session >as well as on the mailing list. > >With respect to ToDo-2: > >I expect all document editors to revise or resubmit for publication >their currently expired I-Ds BEFORE the March 3rd deadline. Please >do this even if there are no technical or otherwise substantive changes >to the drafts. > >If you are unable or unwilling to do that please notify John and I so >that we're aware of it. If you are one of the editors who volunteered >to take over editing a document for someone else who had to move on, >please make arrangements with the former editor to obtain their most >recent version. Often Google will help you find a captured version of >even an expired I-D as a last resort. If you volunteered, you know who >you are. > >ToDo-3 will have to be sorted out by John and I once we have seen >the results of ToDo-2. > >Chris Apple and John Strassner > > > > > >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: Thursday, December 12, 2002 3:57 PM >To: ietf-ldup@imc.org >Subject: Proposals for Concluding LDUP > > > >As mentioned in the proposed WG meeting minutes, there >are currently two proposals on the table for concluding >LDUP: > >1) A proposal from the co-chairs. Summarized as follows: > >A) Publish LCUP spec as Proposed Standard after successful > passage of a WG Last Call. > >B) Publish remaining WG documents as either Informational > or Experimental after resolving gross inconsistencies and > explicitly identifying areas where the WG was unable to > achieve consensus in those documents. > >C) Reference X.500 BAC in the General Usage Profile as well > as the X.500 Administrative Model (perhaps from the drafts > by Steven L. and Kurt Z., perhaps directly from the X.500 > Recommendations themselves) > >D) Reference X.500 BAC and Administrative Model in other WG > documents as needed. > >E) Documents should enter WG Last Call on or before > the July 2003 IETF Meeting. > >F) Conclude LDUP when last document is published as an RFC. > >2) A proposal from Mark Wahl. Summarized as follows: > >A) Publish LCUP as a Proposed Standard after successful > passage of WG Last Call. > >B) Conclude LDUP once LCUP spec is published as an RFC. > >C) Convert all WG documents to individual I-D contributions > and allow editors to work out consensus (or not) outside > of the context of a WG. > >I have spoke with a number of folks who have opinions about >the pros and cons of either approach. > >Please post your views to the list on the pros and cons of >these approaches and indicate which way you are leaning at >this time. > >Also please feel free to post your observations about any >inaccuracies in the summaries of the proposals above. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > > > > > --------------ms050409030006040907070700 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 oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjgx NDIyMTlaMCMGCSqGSIb3DQEJBDEWBBQ4BCOHuSASQ8tM9fAdq6mCyGuM2TBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAit5f dKIYFdI/7Fc/yi6wJu7rep6RlNBgY+EW+mqqE0Zw1YjFkvhrbQ5GJbnv0Mg+iliA4VCMN7/R mGGz0h2ZOwtwDxzau3ly0IYBHU9VOc5LRVr6CRLmWp2ohlOiXhVGfmlfxWOLGp7W70GSA48n h194qHO9xcA32mvQGXEiPuUAAAAAAAA= --------------ms050409030006040907070700--