From nobody Wed Nov 18 08:02:08 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8F1B3877 for ; Wed, 18 Nov 2015 08:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAoDxXArIPoS for ; Wed, 18 Nov 2015 08:02:04 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6D61B3875 for ; Wed, 18 Nov 2015 08:02:04 -0800 (PST) Received: from host86-145-75-25.range86-145.btcentralplus.com ([86.145.75.25] helo=[192.168.1.67]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Zz5AS-0004an-Dg for ldapext@ietf.org; Wed, 18 Nov 2015 16:02:03 +0000 To: ldapext From: Mark R Bannister Message-ID: <564CA0C0.9010400@proseconsulting.co.uk> Date: Wed, 18 Nov 2015 16:01:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Subject: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 16:02:07 -0000 Hi, Further to the announcement of the new LDAPEXT charter at LDAPCon next week, please can I confirm that this will continue to be the mailing list for those discussions, or is a new mailing list being set-up? When will the new charter be published for all to see and comment on? Also, I understood from last week that RFC2307bis will be on the charter, but DBIS (which is intended as its replacement) will not be, and the reasons given were: 1. There is only a single implementation. 2. It would take more than a year to complete. I'm a bit puzzled by (1), as I'm sure there are RFCs based on single implementations. However, clarification of that rule will be helpful. It will be very hard to convince others to produce their own software implementations of DBIS if the reference implementation already available does the job, so I'm not sure I understand the purpose of the rule. Re (2), given the internet drafts are already written and the reference implementation is complete and fully functional, I fail to see where the evidence comes from that suggests it will take more than 1 year to complete? Can you please provide a breakdown of the steps that would be involved and why you think DBIS will take more than 1 year. I am in conversation at the moment with others regarding further features that could be introduced into DBIS to make it even better, I hope to bring those conversations to this mailing list soon, as I would be very interested in soliciting more opinions on this subject. Thanks & regards, Mark Bannister. From nobody Wed Nov 18 08:22:39 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84731B38D3 for ; Wed, 18 Nov 2015 08:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVYvt_tkh56E for ; Wed, 18 Nov 2015 08:22:36 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8345E1B38E4 for ; Wed, 18 Nov 2015 08:22:18 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 66647509BF for ; Wed, 18 Nov 2015 11:22:17 -0500 (EST) To: ldapext@ietf.org References: <564CA0C0.9010400@proseconsulting.co.uk> From: Sean Leonard Message-ID: <564CA551.5040700@seantek.com> Date: Wed, 18 Nov 2015 08:20:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CA0C0.9010400@proseconsulting.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030401050208040904040902" Archived-At: Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 16:22:38 -0000 This is a cryptographically signed message in MIME format. --------------ms030401050208040904040902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/18/2015 8:01 AM, Mark R Bannister wrote: > Hi, > > Further to the announcement of the new LDAPEXT charter at LDAPCon next = > week, please can I confirm that this will continue to be the mailing=20 > list for those discussions, or is a new mailing list being set-up? Yes, this will continue to be the mailing list for those discussions.=20 (Note that I am one participant, not even a charter author or anything,=20 and therefore only have one vote.) If you find out any information to the contrary, please post it to this=20 list so people can migrate elsewhere. > > When will the new charter be published for all to see and comment on? Haven't seen a thing. Sean --------------ms030401050208040904040902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MTgxNjIwMzNaMC8GCSqGSIb3DQEJBDEiBCCJHGM0QnZYPlzNmisfyZwV3kRQVwBQD5kzb5O3 WrclxDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCOt9fFlceOUj1EQfZN 0bgtG3o/ALh8WQMq5FrtH1JUm+BMOgvKRXpm6+N+RY/AHEAM+yZ6nnBxczx6QFCehmvNEpeD tbqCgqm4hQjs/DCZvy+9H3KhZ+JLoVBNvXYvKlXOnlVZt14Cn46k0wbdsuOJZS/o8feLus0/ TRljRHTfGRKeSymeamfh/NQNcx7iBqX2rsBOgaKC70MIXcylK88rE3ls/kHdgzNdGc2EEfC5 XfpNRop2+5z2hG4UD6GwSDni/CzFNWF44eTgYuFGcGE6zyIgopGYmSsoWWGmcrRgHl+VC8Ka g6yBaB5X2hfL7gr3qU2wT6YO3sAOSfs/xq/wAAAAAAAA --------------ms030401050208040904040902-- From nobody Wed Nov 18 09:16:22 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF1E1A8A63 for ; Wed, 18 Nov 2015 09:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5V-K5d_iSbd for ; Wed, 18 Nov 2015 09:16:14 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B901A8A27 for ; Wed, 18 Nov 2015 09:16:14 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9ECF4C0BB2AA for ; Wed, 18 Nov 2015 17:16:13 +0000 (UTC) Received: from pspacek.brq.redhat.com (unused [10.34.128.7] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAIHGBIv023271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Nov 2015 12:16:13 -0500 To: ldapext@ietf.org References: <556EAE47.10406@redhat.com> <55913519.3040302@redhat.com> <559138C2.6060904@highlandsun.com> <559D4274.2000400@redhat.com> From: Petr Spacek Organization: Red Hat Message-ID: <564CB25B.9020702@redhat.com> Date: Wed, 18 Nov 2015 18:16:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <559D4274.2000400@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [ldapext] Content Synchronization Operation + Transactions X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:16:21 -0000 On 8.7.2015 17:32, Petr Spacek wrote: > On 29.6.2015 14:23, Howard Chu wrote: >> Petr Spacek wrote: >>> On 3.6.2015 09:35, Petr Spacek wrote: >>>> Hello, >>>> >>>> it seems to me that LDAP Transactions (RFC 5805) are not perfectly integrated >>>> into Content Synchronization Operation (RFC 4533). >>>> >>>> Mainly the client has no idea what changes were part of single transaction. As >>>> a result, client cannot replicate transactions reliably, especially when >>>> connection drops in the middle of persist phase of Content Synchronization >>>> Operation. >>>> >>>> Also some clients could use the information where LDAP transaction >>>> started/ended for application-level transactions (if the application uses the >>>> data in real-time) or possibly some optimizations (if some application-level >>>> work needs to be done after each group of updates). >>>> >>>> I'm going to sketch -00 draft which will attempt to address this, probably by >>>> adding new messages to indicate where transaction started and ended. >>>> Naturally, this makes sense only for persist phase. >>> >>> The 00 version of the draft is now available. I would really appreciate any >>> feedback! >>> >>> Particularly, I'm not very sure that "transaction identifier" in "End >>> Transaction Notification Message" is the best idea. >> >> Assuming a unique transaction identifier per transaction, I see no reason you >> couldn't allow interleaved transactions during persist stage. (Well, you would >> need to send the txnID along with every message, so that may be excessive >> overhead.) In OpenLDAP transactions would not be interleaved at execution time >> anyway so perhaps it's a non-issue. > > Main reason for using extra messages as transaction boundaries was ease of > implementation on the client side. It can be quite awful to deal with multiple > concurrent transactions on the application level. The assumption here is that > transaction commit should be quite quick so serialization should not add a big > performance penalty (SyncRepl serializes all changes anyway). After LDAPCon I decided to wipe out transaction identifiers from the draft, so transaction boundaries are marked by empty Start & End Transaction Notification Messages. This would be enough for making SyncRepl useful with transactions in applications I care about. I will think about writing separate draft for 'ignore own writes', but today I think that it belongs to a separate document. > Main motivation why tnxID was exposed to SyncRepl users was ability to detect > own writes. Maybe it is better to hide tnxID completely, use empty Start/End > Transation Notification messages, and define another control for 'ignore own > writes when doing SyncRepl'. > > What do you think? I'm not familiar with OpenLDAP internals, so I do not know > how hard it is to implement 'ignore own writes' on server side. I assume that > 'own write' = 'write done by the same BIND DN' but this can be tricky when it > comes to proxying ... > >> On a slightly related note, I intend to submit an extension to RFC5805 adding >> a Prepare Transaction request. This would enable 2 phase commit, allowing us >> to support transactions spanning multiple DSAs. With OpenLDAP's back-ldap, >> back-meta, back-relay, and glue, the capability is sorely needed. > > Good idea! > > Would it be appropriate & possible to clarify what level of 'isolation' is > assumed in RFC5805, possibly in the same draft? I guess that the > under-specification will be more visible with 2 phase commit. > > I think that this property is very important and its under-specification can > cause incompatibilities if other servers decide to implement different levels > of isolation. Howard, are you going to clarify isolation level in the new drafts related to transactions? I think that it would be really useful. Thank you for your time! Petr Spacek -------- Forwarded Message -------- Subject: New Version Notification for draft-spacek-ldapext-syncrepl-transaction-01.txt Date: Wed, 18 Nov 2015 09:02:37 -0800 From: internet-drafts@ietf.org To: Petr Spacek A new version of I-D, draft-spacek-ldapext-syncrepl-transaction-01.txt has been successfully submitted by Petr Spacek and posted to the IETF repository. Name: draft-spacek-ldapext-syncrepl-transaction Revision: 01 Title: The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation with Transactions Document date: 2015-11-18 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-spacek-ldapext-syncrepl-transaction-01.txt Status: https://datatracker.ietf.org/doc/draft-spacek-ldapext-syncrepl-transaction/ Htmlized: https://tools.ietf.org/html/draft-spacek-ldapext-syncrepl-transaction-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-spacek-ldapext-syncrepl-transaction-01 Abstract: This document specifies LDAP Control which extends the persist stage of the Content Synchronization Operation with information about LDAP transaction boundaries. This information can be used to support application-level transactions or for application-level optimizations. From nobody Wed Nov 18 09:34:38 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1121A008E for ; Wed, 18 Nov 2015 09:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJFRp0D2Ilmt for ; Wed, 18 Nov 2015 09:34:36 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.142]) by ietfa.amsl.com (Postfix) with ESMTP id 162B51A009D for ; Wed, 18 Nov 2015 09:34:36 -0800 (PST) Received: from host86-145-75-25.range86-145.btcentralplus.com ([86.145.75.25] helo=[192.168.1.67]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Zz6ct-0007vm-2n for ldapext@ietf.org; Wed, 18 Nov 2015 17:34:35 +0000 To: ldapext@ietf.org References: <564CA0C0.9010400@proseconsulting.co.uk> <564CA551.5040700@seantek.com> From: Mark R Bannister Message-ID: <564CB6A7.8050908@proseconsulting.co.uk> Date: Wed, 18 Nov 2015 17:34:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CA551.5040700@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:34:37 -0000 On 18/11/2015 16:20, Sean Leonard wrote: > On 11/18/2015 8:01 AM, Mark R Bannister wrote: >> Hi, >> >> Further to the announcement of the new LDAPEXT charter at LDAPCon >> next week, please can I confirm that this will continue to be the >> mailing list for those discussions, or is a new mailing list being >> set-up? Apologies, of course I meant "last week" not "next week". > > Yes, this will continue to be the mailing list for those discussions. > (Note that I am one participant, not even a charter author or > anything, and therefore only have one vote.) > > If you find out any information to the contrary, please post it to > this list so people can migrate elsewhere. Hence the point of my question. > >> >> When will the new charter be published for all to see and comment on? > > Haven't seen a thing. > Indeed, nor have I except for the brief discussion at LDAPCon. I'm hoping that Ludovic or Howard will chime in. Thanks, Mark. From nobody Wed Nov 18 12:48:06 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3BC1B2E3C for ; Wed, 18 Nov 2015 12:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtZUPmBK2uHc for ; Wed, 18 Nov 2015 12:48:04 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947D41B2E39 for ; Wed, 18 Nov 2015 12:48:03 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 852EA1CED7; Wed, 18 Nov 2015 20:48:00 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 9AA281D410; Wed, 18 Nov 2015 20:47:57 +0000 (UTC) To: Mark R Bannister , ldapext References: <564CA0C0.9010400@proseconsulting.co.uk> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <564CE3FD.2030704@stroeder.com> Date: Wed, 18 Nov 2015 21:47:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <564CA0C0.9010400@proseconsulting.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030107010805080808030304" Archived-At: Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:48:06 -0000 This is a cryptographically signed message in MIME format. --------------ms030107010805080808030304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > Further to the announcement of the new LDAPEXT charter at LDAPCon next = week, > please can I confirm that this will continue to be the mailing list for= those > discussions, or is a new mailing list being set-up? AFAICS up to now this will be *the* mailing list. I'd notify everybody he= re if that would have to be changed due to IETF preferences. > When will the new charter be published for all to see and comment on? Ludo....! ;-) > Also, I understood from last week that RFC2307bis will be on the charte= r, Personally I see on charter simple solutions for common issues with RFC2307bis, probably not a complete overhaul of RFC 2307. > but DBIS (which is intended as its replacement) will not be, and the > reasons given were: >=20 > 1. There is only a single implementation. > 2. It would take more than a year to complete. >=20 > I'm a bit puzzled by (1), as I'm sure there are RFCs based on single > implementations. The term "RFC" is a bit blurry here. Starting here: https://tools.ietf.org/html/rfc2418#section-7.3 NOTE: The RFC series is a publication mechanism only and publication does not determine the IETF status of a document. Status is determined through separate, explicit status labels assigned by the IESG on behalf of the IETF. In other words, the reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards [4]. [4] Not All RFCs are Standards https://tools.ietf.org/html/rfc1796 Follow the references and you will also find many more docs describing th= e various tracks etc. > However, clarification of that rule will be helpful. It > will be very hard to convince others to produce their own software > implementations of DBIS if the reference implementation already availab= le does > the job, so I'm not sure I understand the purpose of the rule. Simple explanation: If you try to reach standards track two independent implementations are n= eeded to prove interoperability. Maybe some IETF experts around could give you = more detailed advice if needed. Kurt already gave us some good advice regarding all this in the near past= : https://www.ietf.org/mail-archive/web/ldapext/current/msg01951.html https://www.ietf.org/mail-archive/web/ldapext/current/msg02081.html https://www.ietf.org/mail-archive/web/ldapext/current/msg02053.html > Re (2), given the internet drafts are already written and the reference= > implementation is complete and fully functional, I fail to see where th= e > evidence comes from that suggests it will take more than 1 year to comp= lete?=20 > Can you please provide a breakdown of the steps that would be involved = and why > you think DBIS will take more than 1 year. As I understand (2) it's generally hard to reach WG consensus on complex documents. BTW: For this particular reason I will *not* try to add my =C6= -DIR to the list of WG work items. I would like to base it on overhaul of RFC 230= 7 details though. > I am in conversation at the moment with others regarding further featur= es that > could be introduced into DBIS to make it even better, I hope to bring t= hose > conversations to this mailing list soon, as I would be very interested = in > soliciting more opinions on this subject. If you want to DBIS within IETG WG this you have to find people willing t= o 1. work on you on the documents as co-authors or at least reviewers 2. develop an independent DBIS implementation Ciao, Michael. --------------ms030107010805080808030304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTExODIwNDc1N1owLwYJKoZIhvcNAQkEMSIEIBKoOPBE+q3isSCh4w+Yjs0uXyVlSD7lqYqw Fn8ZvsKTMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAc6W7i84FAfestARHT FI9DKv9yTHD9nd04JJl1bxHBDoNiPJUJoSNJ7xny8az5yCqCoogw1l0RNAOXAr0Cn4G2k1hL pQ+yWkP+Xto+EcuPBMb5Rcfrnju1ZvjTE7lfIHuiFWgX42HFiEtXNgLaOjGqdWTH7kTqp1Br brzXgqOF41BjvoOBjHIqvR/ljv0d8uDj8GZmj0DeVVK6Y0vu1NCE+E/bUCv8Buu+SWdNQ0cY jIl0m2eBCKVJwzOLai3fP1IyV/2qaVRI/yrPErie5ms1JCNhn5BjZqEJnCRM2OY2j+KivRk2 Yzeytu946YONC9Q0oizv+NzJJVPWektufLuCAAAAAAAA --------------ms030107010805080808030304-- From nobody Thu Nov 19 04:25:45 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C843D1ACE4B for ; Thu, 19 Nov 2015 04:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlj1J4HBZoXY for ; Thu, 19 Nov 2015 04:25:42 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.142]) by ietfa.amsl.com (Postfix) with ESMTP id 48F501ACE2C for ; Thu, 19 Nov 2015 04:25:42 -0800 (PST) Received: from host86-145-75-25.range86-145.btcentralplus.com ([86.145.75.25] helo=[192.168.1.67]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1ZzOHU-0002QN-7H; Thu, 19 Nov 2015 12:25:40 +0000 To: =?UTF-8?Q?Michael_Str=c3=b6der?= , ldapext References: <564CA0C0.9010400@proseconsulting.co.uk> <564CE3FD.2030704@stroeder.com> From: Mark R Bannister Message-ID: <564DBFBF.1040707@proseconsulting.co.uk> Date: Thu, 19 Nov 2015 12:25:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CE3FD.2030704@stroeder.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 12:25:45 -0000 On 18/11/2015 20:47, Michael Ströder wrote: > Mark R Bannister wrote: >> Further to the announcement of the new LDAPEXT charter at LDAPCon next week, >> please can I confirm that this will continue to be the mailing list for those >> discussions, or is a new mailing list being set-up? > AFAICS up to now this will be *the* mailing list. I'd notify everybody here if > that would have to be changed due to IETF preferences. Good to hear it. > >> When will the new charter be published for all to see and comment on? > Ludo....! ;-) Time to wake up now, Ludo. :-) >> Also, I understood from last week that RFC2307bis will be on the charter, > Personally I see on charter simple solutions for common issues with > RFC2307bis, probably not a complete overhaul of RFC 2307. I understood from previous exchanges with Kurt that RFC2307bis couldn't be standardised as it stands because it attempts to redefine attributes or classes from RFC2307, and you're not allowed to do that. However, if people are already using RFC2307bis then you'll be in a catch-22 situation, not being able to fix those problems without breaking it for existing users. Ergo, RFC2307bis is dead in my opinion and will never be a standard. So let's not cry over spilt milk, let's move on and embrace DBIS!! (Ok I'm stirring trouble here, and I'm biased, but I have a valid point). >> but DBIS (which is intended as its replacement) will not be, and the >> reasons given were: >> >> 1. There is only a single implementation. >> 2. It would take more than a year to complete. >> >> I'm a bit puzzled by (1), as I'm sure there are RFCs based on single >> implementations. > The term "RFC" is a bit blurry here. Starting here: > > https://tools.ietf.org/html/rfc2418#section-7.3 > > NOTE: The RFC series is a publication mechanism only and publication > does not determine the IETF status of a document. Status is > determined through separate, explicit status labels assigned by the > IESG on behalf of the IETF. In other words, the reader is reminded > that all Internet Standards are published as RFCs, but NOT all RFCs > specify standards [4]. > > [4] Not All RFCs are Standards > https://tools.ietf.org/html/rfc1796 > > Follow the references and you will also find many more docs describing the > various tracks etc. Thanks Michael, I'm aware of all of the various tracks, but wouldn't want DBIS to fall into the same trap as RFC2307 did, being released as "experimental" but then being adopted everywhere, then being a real pain to fix up later. I do want DBIS to become a proper ratified standard, and for that to happen, as Kurt said in his posting in December last year, I need the advice of an area director. I approached Barry Leiba on this very subject in August, and it is partly because I approached him that the LDAP working group is being kick-started again. But with DBIS off the agenda! > >> However, clarification of that rule will be helpful. It >> will be very hard to convince others to produce their own software >> implementations of DBIS if the reference implementation already available does >> the job, so I'm not sure I understand the purpose of the rule. > Simple explanation: > If you try to reach standards track two independent implementations are needed > to prove interoperability. Maybe some IETF experts around could give you more > detailed advice if needed. > > Kurt already gave us some good advice regarding all this in the near past: > > https://www.ietf.org/mail-archive/web/ldapext/current/msg01951.html > > https://www.ietf.org/mail-archive/web/ldapext/current/msg02081.html > > https://www.ietf.org/mail-archive/web/ldapext/current/msg02053.html Indeed, and I followed Kurt's advice as given in msg02081 above, hence Barry's intervention. > >> Re (2), given the internet drafts are already written and the reference >> implementation is complete and fully functional, I fail to see where the >> evidence comes from that suggests it will take more than 1 year to complete? >> Can you please provide a breakdown of the steps that would be involved and why >> you think DBIS will take more than 1 year. > As I understand (2) it's generally hard to reach WG consensus on complex > documents. BTW: For this particular reason I will *not* try to add my Ć-DIR to > the list of WG work items. I would like to base it on overhaul of RFC 2307 > details though. Accepted, design by committee doesn't work. But IETF working groups are not supposed to be designs by committee. You speak of complex documents, but I don't see that the DBIS documents as complex, I think that is a rather subjective label. Define complex? I would be happy to make it less complex if people could suggest what they think is currently complicated about it. If the IETF is unable to work with documents of the size of DBIS, then something is broken in the process I think, because each individual DBIS document is a lot smaller than RFC2307 (which I broke up to make it more manageable!). > >> I am in conversation at the moment with others regarding further features that >> could be introduced into DBIS to make it even better, I hope to bring those >> conversations to this mailing list soon, as I would be very interested in >> soliciting more opinions on this subject. > If you want to DBIS within IETG WG this you have to find people willing to > > 1. work on you on the documents as co-authors or at least reviewers > > 2. develop an independent DBIS implementation > > Ciao, Michael. > 1. Is not hard to do, I think I could find people. 2. Is the bit I still don't understand. Where is this rule written down? I'm all for due process, and I can work with due process, esp. if it is well documented, but at the moment I feel that people are just shifting goal-posts to keep DBIS out. Best regards, Mark. From nobody Thu Nov 19 04:45:44 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CA11ACEAE for ; Thu, 19 Nov 2015 04:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z-itZDM5_FZ for ; Thu, 19 Nov 2015 04:45:40 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8281ACEAB for ; Thu, 19 Nov 2015 04:45:39 -0800 (PST) Received: by wmdw130 with SMTP id w130so238776693wmd.0 for ; Thu, 19 Nov 2015 04:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nJyuAl7CFphHSxrS3pLisRmyGFxIGk2OnEe78YvPhEw=; b=XPuOr12ybXVsOYB/8U4ZHl7ZCiEOoQ5HhPeG2mpcnXWw3N38l9vOR0tPKsyoiDZdlK GUhSSweQH07wgX9E3WgphBHwGNutRZKcndtlY3OiZ+CTSnb41qgRhz8p0tVPIDHTVt84 YWZRr4t+chdqpquqLY8uZgzXwxd0npb2HOjpM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nJyuAl7CFphHSxrS3pLisRmyGFxIGk2OnEe78YvPhEw=; b=kbPQSx1VrSlL+PL8Plc03VLUUtcmmO+z3Q57zVsFMyuwa9Fg15jeENL5JKIy+2kLVM yQ3Wn9EyMP3Hois16sCVK/kSEvoRA2Hh2kaHIjNzXLPvARcDnqWLdSI8plxGBolYpqNS 9032oAN9C3lBtmY/j/5fqVhI/I+an6601aNvv5p7m7lAto04U1LmsxFdP5l2HErpNEnf +NGxbrCDccVojwJjAiFf2HyXPKtbaYw+xkVjNUkw+2xNXK1wOtZ+1Hc+x6XINAD5wt1w MX3xOB7jCvRw81S3/fh9Fvnk0GR6dlSvL+3y/uap3YkVl8X7ZPlabdcQV7+tTdubUgww lzGQ== X-Gm-Message-State: ALoCoQlVoRGegMBa0GAkHyim7VKIvUX/KgYNQfl8d15Jx1ic0RtH4rXDiV2LZ8gU0EIcrdzyXsYs X-Received: by 10.28.89.129 with SMTP id n123mr2687259wmb.2.1447937137959; Thu, 19 Nov 2015 04:45:37 -0800 (PST) Received: from ?IPv6:2001:470:1f09:8e7:31bf:60de:4dc0:8f52? ([2001:470:1f09:8e7:31bf:60de:4dc0:8f52]) by smtp.gmail.com with ESMTPSA id h7sm8171851wmf.0.2015.11.19.04.45.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Nov 2015 04:45:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Chris Ridd X-Mailer: iPhone Mail (13B143) In-Reply-To: <564DBFBF.1040707@proseconsulting.co.uk> Date: Thu, 19 Nov 2015 12:45:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <293C3EB8-6D1B-426B-A01E-57F425F8EA21@forgerock.com> References: <564CA0C0.9010400@proseconsulting.co.uk> <564CE3FD.2030704@stroeder.com> <564DBFBF.1040707@proseconsulting.co.uk> To: Mark R Bannister Archived-At: Cc: ldapext , =?utf-8?Q?Michael_Str=C3=B6der?= Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 12:45:41 -0000 On 19 Nov 2015, at 12:25, Mark R Bannister wrot= e: >=20 > 2. Is the bit I still don't understand. Where is this rule written down? I believe this is currently described in RFC 6410. Chris= From nobody Thu Nov 19 05:14:52 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC711AD0C7 for ; Thu, 19 Nov 2015 05:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdwllbv0EIUh for ; Thu, 19 Nov 2015 05:14:38 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.141]) by ietfa.amsl.com (Postfix) with ESMTP id 589421A6FDC for ; Thu, 19 Nov 2015 05:14:38 -0800 (PST) Received: from host86-148-222-229.range86-148.btcentralplus.com ([86.148.222.229] helo=[192.168.1.67]) by smtp06.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1ZzP2r-0003DZ-6Y; Thu, 19 Nov 2015 13:14:37 +0000 To: Chris Ridd References: <564CA0C0.9010400@proseconsulting.co.uk> <564CE3FD.2030704@stroeder.com> <564DBFBF.1040707@proseconsulting.co.uk> <293C3EB8-6D1B-426B-A01E-57F425F8EA21@forgerock.com> From: Mark R Bannister Message-ID: <564DCB37.1030408@proseconsulting.co.uk> Date: Thu, 19 Nov 2015 13:14:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <293C3EB8-6D1B-426B-A01E-57F425F8EA21@forgerock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Cc: ldapext , =?UTF-8?Q?Michael_Str=c3=b6der?= Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 13:14:42 -0000 On 19/11/2015 12:45, Chris Ridd wrote: > On 19 Nov 2015, at 12:25, Mark R Bannister wrote: >> 2. Is the bit I still don't understand. Where is this rule written down? > I believe this is currently described in RFC 6410. > > Chris Excellent, thanks Chris, that's exactly what I'm looking for. Mark. From nobody Thu Nov 19 13:57:34 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECB71B361B for ; Thu, 19 Nov 2015 13:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0akzasZ3hGe0 for ; Thu, 19 Nov 2015 13:57:30 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BC61B2EDD for ; Thu, 19 Nov 2015 13:57:29 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 01FA41CED7; Thu, 19 Nov 2015 21:57:26 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 4469C1D410; Thu, 19 Nov 2015 21:57:24 +0000 (UTC) To: Mark R Bannister , ldapext References: <564CA0C0.9010400@proseconsulting.co.uk> <564CE3FD.2030704@stroeder.com> <564DBFBF.1040707@proseconsulting.co.uk> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <564E45C3.7080708@stroeder.com> Date: Thu, 19 Nov 2015 22:57:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <564DBFBF.1040707@proseconsulting.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090206060002050303020103" Archived-At: Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 21:57:32 -0000 This is a cryptographically signed message in MIME format. --------------ms090206060002050303020103 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Disclaimer: All my statements herein are solely my personal point of view= =2E Mark R Bannister wrote: > I understood from previous exchanges with Kurt that RFC2307bis couldn't= be > standardised as it stands because it attempts to redefine attributes or= > classes from RFC2307, and you're not allowed to do that. Yes, that's my understanding too. > However, if people > are already using RFC2307bis then you'll be in a catch-22 situation, no= t being > able to fix those problems without breaking it for existing users. Erg= o, > RFC2307bis is dead in my opinion and will never be a standard. RFC2307bis in this form seems dead. But my multi-SUP solution for 'posixG= roup' simply works backwards-compatible. > Thanks Michael, I'm aware of all of the various tracks, but wouldn't wa= nt DBIS > to fall into the same trap as RFC2307 did, being released as "experimen= tal" > but then being adopted everywhere, then being a real pain to fix up lat= er. The problem with RFC 2307 is not that it's experimental. The problem is that there are issues considered real flaws with 'posixGro= up' being one of them. > Indeed, and I followed Kurt's advice as given in msg02081 above, hence = Barry's > intervention. Understood. >>> Re (2), given the internet drafts are already written and the referen= ce >>> implementation is complete and fully functional, I fail to see where = the >>> evidence comes from that suggests it will take more than 1 year to co= mplete? >>> Can you please provide a breakdown of the steps that would be involve= d and why >>> you think DBIS will take more than 1 year. >> As I understand (2) it's generally hard to reach WG consensus on compl= ex >> documents. BTW: For this particular reason I will *not* try to add my = =C6-DIR to >> the list of WG work items. I would like to base it on overhaul of RFC = 2307 >> details though. >=20 > Accepted, design by committee doesn't work. But IETF working groups ar= e not > supposed to be designs by committee. You speak of complex documents, b= ut I > don't see that the DBIS documents as complex, I think that is a rather > subjective label. Define complex? I would be happy to make it less co= mplex > if people could suggest what they think is currently complicated about = it. If > the IETF is unable to work with documents of the size of DBIS, then som= ething > is broken in the process I think, because each individual DBIS document= is a > lot smaller than RFC2307 (which I broke up to make it more manageable!)= =2E It's not an issue with the IETF in general. You simply have to convince potential ldapext WG co-workers to work and support DBIS in some way. The= ir support and contributions and WG consensus then would convince the IETF t= o accept it to be published on standard tracks. Ciao, Michael. --------------ms090206060002050303020103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTExOTIxNTcyM1owLwYJKoZIhvcNAQkEMSIEIJwDCcZbk/fqMseMRunrNIYw7YqbmjqEVJgH iLp/7yZCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBkw6KAaT9/FIzMiSEs RRa0k8E0tJudwCumb4Hm1d8v07oLLvlQSo+f9gF55ndbrmN9w9vuXZyM6jE+A+VRmfps/CEe pfMccdDTT8eIW6bSxXJi/fIHIWpPAyZCN8su1StC8I0rjIKAMqOjAfDextcseD4DEQs1whHJ ZLswhcL7QjzZ2AAni8q6akY7k8m6cYK/slYXdMVECaDbX+E18vOIBLCjnQPt/+cob03sqOKS BiHuRm7Sf86NDLOhZi2idLxw6Tvut1Ck13QilRQkiCmeRekhfmW/m9VNwHc7hCZRkbCBiyJ7 Bnqitojju8BdQEF6bGG3y1sfIkvNslubD0sgAAAAAAAA --------------ms090206060002050303020103-- From nobody Fri Nov 20 09:26:34 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4041B39B4 for ; Fri, 20 Nov 2015 09:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUole_c5oKDg for ; Fri, 20 Nov 2015 09:26:33 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349BA1B39B2 for ; Fri, 20 Nov 2015 09:26:33 -0800 (PST) Received: by iouu10 with SMTP id u10so132498639iou.0 for ; Fri, 20 Nov 2015 09:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EaJSsTZUUekdSw0YEFKU558CpTDAb8OIIAop//mfhzI=; b=mh3HQU2Y1HiXmHauApFXU+woVaPQs8N3plH3oRySFfMyqZTylbcmiThI7NwSLoDUdj y0mUCgUsDkpNhuDRfNtB3Nr+YzxHh4pbksnZom7AlqgXHgsCTKFxUVruGK1nxDS0Nc7x gAG/RMVXVq9P1jSjFixryE3/PkketybG0YdTvePEfAWji22KwRS6fi1dUHnDG5kthdaO URsubYHS0dy+wgo24T9tzmqp+kWFlcIELL/zL8ZGpFlbsSM7RCnvxdD7Ydb2z7fDX0Yl WIKB50SCUEupwQIKQcFw239MKNmZQOyb13MaMuOk3UjMyzgy/OncytGrISxtfX39JSXz Xp+A== MIME-Version: 1.0 X-Received: by 10.107.28.144 with SMTP id c138mr15184675ioc.15.1448040392611; Fri, 20 Nov 2015 09:26:32 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.181.202 with HTTP; Fri, 20 Nov 2015 09:26:32 -0800 (PST) In-Reply-To: <564CE3FD.2030704@stroeder.com> References: <564CA0C0.9010400@proseconsulting.co.uk> <564CE3FD.2030704@stroeder.com> Date: Fri, 20 Nov 2015 12:26:32 -0500 X-Google-Sender-Auth: 1MzdfnSdU3WqgkqQv6c2OtZQIY4 Message-ID: From: Barry Leiba To: =?UTF-8?Q?Michael_Str=C3=B6der?= Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ldapext Subject: Re: [ldapext] New LDAPEXT charter X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:26:34 -0000 Here to clarify process: >> 1. There is only a single implementation. ... >> I'm a bit puzzled by (1), as I'm sure there are RFCs based on single >> implementations. ... > If you try to reach standards track two independent implementations are needed > to prove interoperability. Maybe some IETF experts around could give you more > detailed advice if needed. Indeed, it's puzzling, because working groups and technical areas vary with regard to what's important for that work or technical area. RFC 6410 re-defines the "Standards Track" into two levels (down from three): Proposed Standard and Internet Standard. It's the latter for which we need multiple deployed implementations to give evidence of both utility and interoperability. For Proposed Standard, there is no requirement for that -- no requirement, in fact, for any implementations at all. It's a proposal. That said, there's not much use in a proposed standard that no one wants to implement, and we've found that the best proposals are those that are developed in parallel with implementations, having the development of the specification and the code feed back on each other, with interoperability testing along the way. See RFC 6982 for one proposal for documenting implementations as the draft is developing. I strongly support that mechanism. > If you want to DBIS within IETG WG this you have to find people willing to > > 1. work on you on the documents as co-authors or at least reviewers > > 2. develop an independent DBIS implementation Exactly. (1) is, of course, necessary for any work to proceed in any working group. While (2) is not strictly necessary according to RFCs 2026 and 6410, it's reasonable for a working group (and/or an Area Director) to push for that in order to demonstrate that people are sufficiently interested in the work to move it toward implementation and deployment, and to improve the specification as I mentioned above, by finding the bugs, gaps, and implementation problems early, before the spec is published. I would not want to see artificial road blocks being put up against anyone's proposal. At the same time, in order to proceed with any proposal there do need to be enough people interested in working on it to get it done and to make it a useful product of the working group. Barry, ART Area Director From nobody Mon Nov 23 23:29:52 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7A01A0204 for ; Mon, 23 Nov 2015 23:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.08 X-Spam-Level: ** X-Spam-Status: No, score=2.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Oz5zRk4Cyjs for ; Mon, 23 Nov 2015 23:29:48 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.141]) by ietfa.amsl.com (Postfix) with ESMTP id 305421A01A3 for ; Mon, 23 Nov 2015 23:29:47 -0800 (PST) Received: from dab-glb1-h-40-6.dab.02.net ([82.132.218.105] helo=[10.65.91.166]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1a182q-0008Sf-I7; Tue, 24 Nov 2015 07:29:46 +0000 To: "=?utf-8?B?QmFycnkgTGVpYmE=?=" , "=?utf-8?B?TWljaGFlbCBTdHLDtmRlcg==?=" From: "=?utf-8?B?TWFyayBSIEJhbm5pc3Rlcg==?=" Date: Tue, 24 Nov 2015 07:29:44 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1448350184254" X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Message-Id: <20151124072948.305421A01A3@ietfa.amsl.com> Archived-At: Cc: ldapext Subject: Re: [ldapext] =?utf-8?q?New_LDAPEXT_charter?= X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 07:29:51 -0000 ------=_Part_0_1448350184254 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiwgQmFycnkuPiBGb3IgUHJvcG9zZWQgU3RhbmRh cmQsIHRoZXJlIGlzIG5vCj4gcmVxdWlyZW1lbnQgZm9yIHRoYXQgLS0gbm8gcmVxdWlyZW1lbnQs IGluIGZhY3QsIGZvciBhbnkKPiBpbXBsZW1lbnRhdGlvbnMgYXQgYWxsLiAgSXQncyBhIHByb3Bv c2FsLgpPaywgdGhlbiBJJ3ZlIHRydW1wZWQgdGhhdCwgYXMgSSBoYXZlIGFuIGltcGxlbWVudGF0 aW9uIGFscmVhZHkuCj4gPiBJZiB5b3Ugd2FudCB0byBEQklTIHdpdGhpbiBJRVRHIFdHIHRoaXMg eW91IGhhdmUgdG8gZmluZCBwZW9wbGUgd2lsbGluZyB0bwo+ID4KPiA+IDEuIHdvcmsgb24geW91 IG9uIHRoZSBkb2N1bWVudHMgYXMgY28tYXV0aG9ycyBvciBhdCBsZWFzdCByZXZpZXdlcnMKPiA+ Cj4gPiAyLiBkZXZlbG9wIGFuIGluZGVwZW5kZW50IERCSVMgaW1wbGVtZW50YXRpb24KPiAKPiBF eGFjdGx5LiAgKDEpIGlzLCBvZiBjb3Vyc2UsIG5lY2Vzc2FyeSBmb3IgYW55IHdvcmsgdG8gcHJv Y2VlZCBpbiBhbnkKPiB3b3JraW5nIGdyb3VwLiAgV2hpbGUgKDIpIGlzIG5vdCBzdHJpY3RseSBu ZWNlc3NhcnkgYWNjb3JkaW5nIHRvIFJGQ3MKMjAyNiBhbmQgNjQxMCwgaXQncyByZWFzb25hYmxl IGZvciBhIHdvcmtpbmcgZ3JvdXAgKGFuZC9vciBhbiBBcmVhCj4gRGlyZWN0b3IpIHRvIHB1c2gg Zm9yIHRoYXQKKDEpIHNob3VsZCBiZSBwb3NzaWJsZS4gIElzIHRoZXJlIGFuIG9mZmljaWFsIHBy b2Nlc3MgYSByZXZpZXdlciBuZWVkcyB0byBmb2xsb3csIGluIG9yZGVyIHRvIGNvdW50IGFzIGEg cmV2aWV3ZXIgZm9yIHRoaXMgcHVycG9zZT8KCigyKSBzZWVtcyB0byBjb250cmFkaWN0IHlvdXIg Zmlyc3QgcG9pbnQgYWJvdXQgYSBQcm9wb3NlZCBTdGFuZGFyZCBub3QgZXZlbiBuZWVkaW5nIGFu IGltcGxlbWVudGF0aW9uLiAgUGxlYXNlIGhlbHAgbWUgdW5kZXJzdGFuZCB0aGlzLiAgSXQgaXMg ZWl0aGVyIHJlcXVpcmVkIG9yIG5vdCByZXF1aXJlZCBpbiBteSBjYXNlPwoKTWFueSB0aGFua3Ms Ck1hcmsuCgotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZyb206ICJCYXJyeSBMZWliYSIgPGJh cnJ5bGVpYmFAY29tcHV0ZXIub3JnPgpUbzogIk1pY2hhZWwgU3Ryw7ZkZXIiIDxtaWNoYWVsQHN0 cm9lZGVyLmNvbT4KQ2M6ICJNYXJrIFIgQmFubmlzdGVyIiA8ZGJpc0Bwcm9zZWNvbnN1bHRpbmcu Y28udWs+LCAibGRhcGV4dCIgPGxkYXBleHRAaWV0Zi5vcmc+ClN1YmplY3Q6IFtsZGFwZXh0XSBO ZXcgTERBUEVYVCBjaGFydGVyCkRhdGU6IEZyaSwgTm92IDIwLCAyMDE1IDE3OjI2CgpIZXJlIHRv IGNsYXJpZnkgcHJvY2VzczoKCj4+IDEuIFRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgaW1wbGVtZW50 YXRpb24uCi4uLi4KPj4gSSdtIGEgYml0IHB1enpsZWQgYnkgKDEpLCBhcyBJJ20gc3VyZSB0aGVy ZSBhcmUgUkZDcyBiYXNlZCBvbiBzaW5nbGUKPj4gaW1wbGVtZW50YXRpb25zLgouLi4uCj4gSWYg eW91IHRyeSB0byByZWFjaCBzdGFuZGFyZHMgdHJhY2sgdHdvIGluZGVwZW5kZW50IGltcGxlbWVu dGF0aW9ucyBhcmUgbmVlZGVkCj4gdG8gcHJvdmUgaW50ZXJvcGVyYWJpbGl0eS4gTWF5YmUgc29t ZSBJRVRGIGV4cGVydHMgYXJvdW5kIGNvdWxkIGdpdmUgeW91IG1vcmUKPiBkZXRhaWxlZCBhZHZp Y2UgaWYgbmVlZGVkLgoKSW5kZWVkLCBpdCdzIHB1enpsaW5nLCBiZWNhdXNlIHdvcmtpbmcgZ3Jv dXBzIGFuZCB0ZWNobmljYWwgYXJlYXMgdmFyeQp3aXRoIHJlZ2FyZCB0byB3aGF0J3MgaW1wb3J0 YW50IGZvciB0aGF0IHdvcmsgb3IgdGVjaG5pY2FsIGFyZWEuICBSRkMKNjQxMCByZS1kZWZpbmVz IHRoZSAiU3RhbmRhcmRzIFRyYWNrIiBpbnRvIHR3byBsZXZlbHMgKGRvd24gZnJvbQp0aHJlZSk6 IFByb3Bvc2VkIFN0YW5kYXJkIGFuZCBJbnRlcm5ldCBTdGFuZGFyZC4gIEl0J3MgdGhlIGxhdHRl ciBmb3IKd2hpY2ggd2UgbmVlZCBtdWx0aXBsZSBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbnMgdG8g Z2l2ZSBldmlkZW5jZSBvZgpib3RoIHV0aWxpdHkgYW5kIGludGVyb3BlcmFiaWxpdHkuICBGb3Ig UHJvcG9zZWQgU3RhbmRhcmQsIHRoZXJlIGlzIG5vCnJlcXVpcmVtZW50IGZvciB0aGF0IC0tIG5v IHJlcXVpcmVtZW50LCBpbiBmYWN0LCBmb3IgYW55CmltcGxlbWVudGF0aW9ucyBhdCBhbGwuICBJ dCdzIGEgcHJvcG9zYWwuCgpUaGF0IHNhaWQsIHRoZXJlJ3Mgbm90IG11Y2ggdXNlIGluIGEgcHJv cG9zZWQgc3RhbmRhcmQgdGhhdCBubyBvbmUKd2FudHMgdG8gaW1wbGVtZW50LCBhbmQgd2UndmUg Zm91bmQgdGhhdCB0aGUgYmVzdCBwcm9wb3NhbHMgYXJlIHRob3NlCnRoYXQgYXJlIGRldmVsb3Bl ZCBpbiBwYXJhbGxlbCB3aXRoIGltcGxlbWVudGF0aW9ucywgaGF2aW5nIHRoZQpkZXZlbG9wbWVu dCBvZiB0aGUgc3BlY2lmaWNhdGlvbiBhbmQgdGhlIGNvZGUgZmVlZCBiYWNrIG9uIGVhY2ggb3Ro ZXIsCndpdGggaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIGFsb25nIHRoZSB3YXkuCgpTZWUgUkZD IDY5ODIgZm9yIG9uZSBwcm9wb3NhbCBmb3IgZG9jdW1lbnRpbmcgaW1wbGVtZW50YXRpb25zIGFz IHRoZQpkcmFmdCBpcyBkZXZlbG9waW5nLiAgSSBzdHJvbmdseSBzdXBwb3J0IHRoYXQgbWVjaGFu aXNtLgoKPiBJZiB5b3Ugd2FudCB0byBEQklTIHdpdGhpbiBJRVRHIFdHIHRoaXMgeW91IGhhdmUg dG8gZmluZCBwZW9wbGUgd2lsbGluZyB0bwo+Cj4gMS4gd29yayBvbiB5b3Ugb24gdGhlIGRvY3Vt ZW50cyBhcyBjby1hdXRob3JzIG9yIGF0IGxlYXN0IHJldmlld2Vycwo+Cj4gMi4gZGV2ZWxvcCBh biBpbmRlcGVuZGVudCBEQklTIGltcGxlbWVudGF0aW9uCgpFeGFjdGx5LiAgKDEpIGlzLCBvZiBj b3Vyc2UsIG5lY2Vzc2FyeSBmb3IgYW55IHdvcmsgdG8gcHJvY2VlZCBpbiBhbnkKd29ya2luZyBn cm91cC4gIFdoaWxlICgyKSBpcyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5IGFjY29yZGluZyB0byBS RkNzCjIwMjYgYW5kIDY0MTAsIGl0J3MgcmVhc29uYWJsZSBmb3IgYSB3b3JraW5nIGdyb3VwIChh bmQvb3IgYW4gQXJlYQpEaXJlY3RvcikgdG8gcHVzaCBmb3IgdGhhdCBpbiBvcmRlciB0byBkZW1v bnN0cmF0ZSB0aGF0IHBlb3BsZSBhcmUKc3VmZmljaWVudGx5IGludGVyZXN0ZWQgaW4gdGhlIHdv cmsgdG8gbW92ZSBpdCB0b3dhcmQgaW1wbGVtZW50YXRpb24KYW5kIGRlcGxveW1lbnQsIGFuZCB0 byBpbXByb3ZlIHRoZSBzcGVjaWZpY2F0aW9uIGFzIEkgbWVudGlvbmVkIGFib3ZlLApieSBmaW5k aW5nIHRoZSBidWdzLCBnYXBzLCBhbmQgaW1wbGVtZW50YXRpb24gcHJvYmxlbXMgZWFybHksIGJl Zm9yZQp0aGUgc3BlYyBpcyBwdWJsaXNoZWQuCgpJIHdvdWxkIG5vdCB3YW50IHRvIHNlZSBhcnRp ZmljaWFsIHJvYWQgYmxvY2tzIGJlaW5nIHB1dCB1cCBhZ2FpbnN0CmFueW9uZSdzIHByb3Bvc2Fs LiAgQXQgdGhlIHNhbWUgdGltZSwgaW4gb3JkZXIgdG8gcHJvY2VlZCB3aXRoIGFueQpwcm9wb3Nh bCB0aGVyZSBkbyBuZWVkIHRvIGJlIGVub3VnaCBwZW9wbGUgaW50ZXJlc3RlZCBpbiB3b3JraW5n IG9uIGl0CnRvIGdldCBpdCBkb25lIGFuZCB0byBtYWtlIGl0IGEgdXNlZnVsIHByb2R1Y3Qgb2Yg dGhlIHdvcmtpbmcgZ3JvdXAuCgpCYXJyeSwgQVJUIEFyZWEgRGlyZWN0b3I= ------=_Part_0_1448350184254 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ3NhbnMtc2VyaWYnOyI+VGhhbmtz IGZvciB0aGUgY2xhcmlmaWNhdGlvbiwgQmFycnkuPGRpdj48ZGl2PjxwcmUgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+Jmd0OyBGb3IgUHJvcG9z ZWQgU3RhbmRhcmQsIHRoZXJlIGlzIG5vCiZndDsgcmVxdWlyZW1lbnQgZm9yIHRoYXQgLS0gbm8g cmVxdWlyZW1lbnQsIGluIGZhY3QsIGZvciBhbnkKJmd0OyBpbXBsZW1lbnRhdGlvbnMgYXQgYWxs LiAgSXQncyBhIHByb3Bvc2FsLjwvcHJlPjwvZGl2PjxkaXY+T2ssIHRoZW4gSSd2ZSB0cnVtcGVk IHRoYXQsIGFzIEkgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBhbHJlYWR5LjwvZGl2PjwvZGl2Pjxk aXY+PHByZSBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyB3aGl0ZS1zcGFjZTogcHJlLXdy YXA7Ij4mZ3Q7ICZndDsgSWYgeW91IHdhbnQgdG8gREJJUyB3aXRoaW4gSUVURyBXRyB0aGlzIHlv dSBoYXZlIHRvIGZpbmQgcGVvcGxlIHdpbGxpbmcgdG8KJmd0OyAmZ3Q7CiZndDsgJmd0OyAxLiB3 b3JrIG9uIHlvdSBvbiB0aGUgZG9jdW1lbnRzIGFzIGNvLWF1dGhvcnMgb3IgYXQgbGVhc3QgcmV2 aWV3ZXJzCiZndDsgJmd0OwomZ3Q7ICZndDsgMi4gZGV2ZWxvcCBhbiBpbmRlcGVuZGVudCBEQklT IGltcGxlbWVudGF0aW9uCiZndDsgCiZndDsgRXhhY3RseS4gICgxKSBpcywgb2YgY291cnNlLCBu ZWNlc3NhcnkgZm9yIGFueSB3b3JrIHRvIHByb2NlZWQgaW4gYW55CiZndDsgd29ya2luZyBncm91 cC4gIFdoaWxlICgyKSBpcyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5IGFjY29yZGluZyB0byBSRkNz CjIwMjYgYW5kIDY0MTAsIGl0J3MgcmVhc29uYWJsZSBmb3IgYSB3b3JraW5nIGdyb3VwIChhbmQv b3IgYW4gQXJlYQomZ3Q7IERpcmVjdG9yKSB0byBwdXNoIGZvciB0aGF0PC9wcmU+PC9kaXY+PGRp dj4oMSkgc2hvdWxkIGJlIHBvc3NpYmxlLiAmbmJzcDtJcyB0aGVyZSBhbiBvZmZpY2lhbCBwcm9j ZXNzIGEgcmV2aWV3ZXIgbmVlZHMgdG8gZm9sbG93LCBpbiBvcmRlciB0byBjb3VudCBhcyBhIHJl dmlld2VyIGZvciB0aGlzIHB1cnBvc2U/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4oMikgc2Vl bXMgdG8gY29udHJhZGljdCB5b3VyIGZpcnN0IHBvaW50IGFib3V0IGEgUHJvcG9zZWQgU3RhbmRh cmQgbm90IGV2ZW4gbmVlZGluZyBhbiBpbXBsZW1lbnRhdGlvbi4gJm5ic3A7UGxlYXNlIGhlbHAg bWUgdW5kZXJzdGFuZCB0aGlzLiAmbmJzcDtJdCBpcyBlaXRoZXIgcmVxdWlyZWQgb3Igbm90IHJl cXVpcmVkIGluIG15IGNhc2U/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5NYW55IHRoYW5rcyw8 L2Rpdj48ZGl2Pk1hcmsuPC9kaXY+PGJyPjxkaXYgaWQ9Imh0Y19oZWFkZXIiPi0tLS0tIFJlcGx5 IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7QmFycnkgTGVpYmEmcXVvdDsgJmx0O2JhcnJ5 bGVpYmFAY29tcHV0ZXIub3JnJmd0Ozxicj5UbzogJnF1b3Q7TWljaGFlbCBTdHLDtmRlciZxdW90 OyAmbHQ7bWljaGFlbEBzdHJvZWRlci5jb20mZ3Q7PGJyPkNjOiAmcXVvdDtNYXJrIFIgQmFubmlz dGVyJnF1b3Q7ICZsdDtkYmlzQHByb3NlY29uc3VsdGluZy5jby51ayZndDssICZxdW90O2xkYXBl eHQmcXVvdDsgJmx0O2xkYXBleHRAaWV0Zi5vcmcmZ3Q7PGJyPlN1YmplY3Q6IFtsZGFwZXh0XSBO ZXcgTERBUEVYVCBjaGFydGVyPGJyPkRhdGU6IEZyaSwgTm92IDIwLCAyMDE1IDE3OjI2PC9kaXY+ PC9kaXY+PGJyPjxwcmUgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyI+SGVyZSB0byBjbGFyaWZ5IHByb2Nlc3M6CgomZ3Q7Jmd0OyAxLiBUaGVyZSBp cyBvbmx5IGEgc2luZ2xlIGltcGxlbWVudGF0aW9uLgouLi4uCiZndDsmZ3Q7IEknbSBhIGJpdCBw dXp6bGVkIGJ5ICgxKSwgYXMgSSdtIHN1cmUgdGhlcmUgYXJlIFJGQ3MgYmFzZWQgb24gc2luZ2xl CiZndDsmZ3Q7IGltcGxlbWVudGF0aW9ucy4KLi4uLgomZ3Q7IElmIHlvdSB0cnkgdG8gcmVhY2gg c3RhbmRhcmRzIHRyYWNrIHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgYXJlIG5lZWRl ZAomZ3Q7IHRvIHByb3ZlIGludGVyb3BlcmFiaWxpdHkuIE1heWJlIHNvbWUgSUVURiBleHBlcnRz IGFyb3VuZCBjb3VsZCBnaXZlIHlvdSBtb3JlCiZndDsgZGV0YWlsZWQgYWR2aWNlIGlmIG5lZWRl ZC4KCkluZGVlZCwgaXQncyBwdXp6bGluZywgYmVjYXVzZSB3b3JraW5nIGdyb3VwcyBhbmQgdGVj aG5pY2FsIGFyZWFzIHZhcnkKd2l0aCByZWdhcmQgdG8gd2hhdCdzIGltcG9ydGFudCBmb3IgdGhh dCB3b3JrIG9yIHRlY2huaWNhbCBhcmVhLiAgUkZDCjY0MTAgcmUtZGVmaW5lcyB0aGUgIlN0YW5k YXJkcyBUcmFjayIgaW50byB0d28gbGV2ZWxzIChkb3duIGZyb20KdGhyZWUpOiBQcm9wb3NlZCBT dGFuZGFyZCBhbmQgSW50ZXJuZXQgU3RhbmRhcmQuICBJdCdzIHRoZSBsYXR0ZXIgZm9yCndoaWNo IHdlIG5lZWQgbXVsdGlwbGUgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zIHRvIGdpdmUgZXZpZGVu Y2Ugb2YKYm90aCB1dGlsaXR5IGFuZCBpbnRlcm9wZXJhYmlsaXR5LiAgRm9yIFByb3Bvc2VkIFN0 YW5kYXJkLCB0aGVyZSBpcyBubwpyZXF1aXJlbWVudCBmb3IgdGhhdCAtLSBubyByZXF1aXJlbWVu dCwgaW4gZmFjdCwgZm9yIGFueQppbXBsZW1lbnRhdGlvbnMgYXQgYWxsLiAgSXQncyBhIHByb3Bv c2FsLgoKVGhhdCBzYWlkLCB0aGVyZSdzIG5vdCBtdWNoIHVzZSBpbiBhIHByb3Bvc2VkIHN0YW5k YXJkIHRoYXQgbm8gb25lCndhbnRzIHRvIGltcGxlbWVudCwgYW5kIHdlJ3ZlIGZvdW5kIHRoYXQg dGhlIGJlc3QgcHJvcG9zYWxzIGFyZSB0aG9zZQp0aGF0IGFyZSBkZXZlbG9wZWQgaW4gcGFyYWxs ZWwgd2l0aCBpbXBsZW1lbnRhdGlvbnMsIGhhdmluZyB0aGUKZGV2ZWxvcG1lbnQgb2YgdGhlIHNw ZWNpZmljYXRpb24gYW5kIHRoZSBjb2RlIGZlZWQgYmFjayBvbiBlYWNoIG90aGVyLAp3aXRoIGlu dGVyb3BlcmFiaWxpdHkgdGVzdGluZyBhbG9uZyB0aGUgd2F5LgoKU2VlIFJGQyA2OTgyIGZvciBv bmUgcHJvcG9zYWwgZm9yIGRvY3VtZW50aW5nIGltcGxlbWVudGF0aW9ucyBhcyB0aGUKZHJhZnQg aXMgZGV2ZWxvcGluZy4gIEkgc3Ryb25nbHkgc3VwcG9ydCB0aGF0IG1lY2hhbmlzbS4KCiZndDsg SWYgeW91IHdhbnQgdG8gREJJUyB3aXRoaW4gSUVURyBXRyB0aGlzIHlvdSBoYXZlIHRvIGZpbmQg cGVvcGxlIHdpbGxpbmcgdG8KJmd0OwomZ3Q7IDEuIHdvcmsgb24geW91IG9uIHRoZSBkb2N1bWVu dHMgYXMgY28tYXV0aG9ycyBvciBhdCBsZWFzdCByZXZpZXdlcnMKJmd0OwomZ3Q7IDIuIGRldmVs b3AgYW4gaW5kZXBlbmRlbnQgREJJUyBpbXBsZW1lbnRhdGlvbgoKRXhhY3RseS4gICgxKSBpcywg b2YgY291cnNlLCBuZWNlc3NhcnkgZm9yIGFueSB3b3JrIHRvIHByb2NlZWQgaW4gYW55Cndvcmtp bmcgZ3JvdXAuICBXaGlsZSAoMikgaXMgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSBhY2NvcmRpbmcg dG8gUkZDcwoyMDI2IGFuZCA2NDEwLCBpdCdzIHJlYXNvbmFibGUgZm9yIGEgd29ya2luZyBncm91 cCAoYW5kL29yIGFuIEFyZWEKRGlyZWN0b3IpIHRvIHB1c2ggZm9yIHRoYXQgaW4gb3JkZXIgdG8g ZGVtb25zdHJhdGUgdGhhdCBwZW9wbGUgYXJlCnN1ZmZpY2llbnRseSBpbnRlcmVzdGVkIGluIHRo ZSB3b3JrIHRvIG1vdmUgaXQgdG93YXJkIGltcGxlbWVudGF0aW9uCmFuZCBkZXBsb3ltZW50LCBh bmQgdG8gaW1wcm92ZSB0aGUgc3BlY2lmaWNhdGlvbiBhcyBJIG1lbnRpb25lZCBhYm92ZSwKYnkg ZmluZGluZyB0aGUgYnVncywgZ2FwcywgYW5kIGltcGxlbWVudGF0aW9uIHByb2JsZW1zIGVhcmx5 LCBiZWZvcmUKdGhlIHNwZWMgaXMgcHVibGlzaGVkLgoKSSB3b3VsZCBub3Qgd2FudCB0byBzZWUg YXJ0aWZpY2lhbCByb2FkIGJsb2NrcyBiZWluZyBwdXQgdXAgYWdhaW5zdAphbnlvbmUncyBwcm9w b3NhbC4gIEF0IHRoZSBzYW1lIHRpbWUsIGluIG9yZGVyIHRvIHByb2NlZWQgd2l0aCBhbnkKcHJv cG9zYWwgdGhlcmUgZG8gbmVlZCB0byBiZSBlbm91Z2ggcGVvcGxlIGludGVyZXN0ZWQgaW4gd29y a2luZyBvbiBpdAp0byBnZXQgaXQgZG9uZSBhbmQgdG8gbWFrZSBpdCBhIHVzZWZ1bCBwcm9kdWN0 IG9mIHRoZSB3b3JraW5nIGdyb3VwLgoKQmFycnksIEFSVCBBcmVhIERpcmVjdG9yCjwvcHJlPg== ------=_Part_0_1448350184254-- From nobody Mon Nov 23 23:46:14 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C771A034F for ; Mon, 23 Nov 2015 23:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqVSzI2Dq25c for ; Mon, 23 Nov 2015 23:46:10 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6631A034C for ; Mon, 23 Nov 2015 23:46:10 -0800 (PST) Received: by wmuu63 with SMTP id u63so84280217wmu.0 for ; Mon, 23 Nov 2015 23:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:subject:mime-version:content-type; bh=68yaloODn2Q3ew4/DOgsBxyjU+CYvoEpnf6uO2SJCu0=; b=wOC/yt+FHI/6brPjwok653TMe7U9JOZGLlGqHmzqXeTAxSxIFNyObyAL67fWC6zqUe NVGygrvUclUyNdRLKU9XFvDVj5ffQEN5T2lDfeiuCdNj2QpXk23RA+rWgvYEYbG5iiHW dAMB4YEl6SIulmJCONXPPIrkurz4BbIZFiwnkHWBuNnIIVTARE4SeTQJ9ps2jCkt6s6Q FSGE84xJuepa6nFvlgdSPQqcWzzjfxSL+KfaIvXmiMFlJSr4Mrs/dmMaX91m7DFMKNkY AB1MAkXPx22d64PZglN4N9VCbWQm4Zxp80imQOYpAZP3L2em2uOiLymBYYPOw07zBtxc c7GA== X-Received: by 10.28.51.135 with SMTP id z129mr20868366wmz.19.1448351168764; Mon, 23 Nov 2015 23:46:08 -0800 (PST) Received: from lpm.local (cro38-1-82-236-150-92.fbx.proxad.net. [82.236.150.92]) by smtp.gmail.com with ESMTPSA id h67sm16714218wmf.17.2015.11.23.23.46.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 23:46:07 -0800 (PST) Date: Tue, 24 Nov 2015 08:46:06 +0100 From: Ludovic Poitou To: Barry Leiba , Howard Chu Message-ID: X-Mailer: Airmail Beta (337) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="565415be_19692e66_1b08" Archived-At: Cc: ldapext@ietf.org Subject: [ldapext] Next LDAPExt draft charter... X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 07:46:13 -0000 --565415be_19692e66_1b08 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Barry, Please find below, the initial draft charter for a new working group at I= ET=46 on the trail of the LDAPEXT working group (I don=E2=80=99t know if = we can reuse the name of a closed WG). As it=E2=80=99s been discussed on the ldapext mailing list already, the D= BIS work has been left out of the draft charter, but possibly could be in= tegrated within the first work element. Please let us know if this draft charter is acceptable or needs to be ada= pted to lead to the creation of the Working Group as soon as possible. Kind regards, Ludovic. --- =C2=A0 =C2=A0Working Group Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 LDAP Extension (ldapext) =C2=A0 =C2=A0IET=46 Area: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Applications and Real-Time (ART) Area=C2=A0 =C2=A0 =C2=A0Chair(s): =C2=A0 =C2=A0 =C2=A0 =C2=A0 Howard Chu (hyc=40symas.com) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ludovic Poitou (ludovic.poitou=40gmail.com) =C2=A0 =C2=A0Applications and Real-Time (ART) Area Director(s): =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ben Campbell (ben=40nostrum.com) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alissa Cooper (alissa=40cooperw.in) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Barry Leiba (barryleiba=40computer.org) =C2=A0 =C2=A0Responsible Area Director: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Barry Leiba (barryleiba=40computer.org) =C2=A0 =C2=A0Mailing Lists: =C2=A0 =C2=A0 =C2=A0 =C2=A0 General Discussion:ldapext=40ietf.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 To Subscribe: https://www.ietf.org/mailman/li= stinfo/ldapext =C2=A0 =C2=A0 =C2=A0 =C2=A0 Archive: http://www.ietf.org/mail-archive/web= /ldapext/ =C2=A0 =C2=A0Description of Working Group: =C2=A0 =C2=A0The LDAPExt working group is charter to standardize extensio= ns to =C2=A0 =C2=A0LDAPv3 (R=46C 4510) standards.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Some years ago, under the umbrella of a former ldapext WG or= as =C2=A0 =C2=A0individual submissions, several extensions were proposed in = the form of =C2=A0 =C2=A0experimental R=46Cs and Internet Drafts. Although not finali= zed, these =C2=A0 =C2=A0specifications have been implemented by different vendors, w= ith various =C2=A0 =C2=A0interpretations leading to subtle interoperability issues. =C2=A0 =C2=A0 =C2=A0 =C2=A0The working group will do the following: =C2=A0 =C2=A0 =C2=A0 =C2=A0=46inish existing and implemented Internet Drafts and publis= h them as =C2=A0 =C2=A0Proposed Standards: =C2=A0 =C2=A0 =C2=A0 =C2=A0* An Approach for Using LDAP as a Network Information Servic= e (R=46C =C2=A0 =C2=A0 =C2=A02307) was published as an Experimental R=46C. Soon af= ter, revisions =C2=A0 =C2=A0 =C2=A0appeared as draft-howard-rfc2307bis. The objective is= to conclude =C2=A0 =C2=A0 =C2=A0this work in compliance with the IANA guide-lines, bu= t preserving =C2=A0 =C2=A0 =C2=A0interoperability with existing implementations. =C2=A0 =C2=A0 =C2=A0* Define an information model and protocol to support Passwo= rd Policy =C2=A0 =C2=A0 =C2=A0for LDAP Directories, based on previous work describe= d in =C2=A0 =C2=A0 =C2=A0draft-behera-ldap-password-policy, considering the is= sues raised in =C2=A0 =C2=A0 =C2=A0draft-zeilenga-ldap-passwords but preserving interope= rability with =C2=A0 =C2=A0 =C2=A0existing implementations. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Define new extensions: =C2=A0=C2=A0 =C2=A0 * An inetOrgPerson 2.0 schema to aggregate the needs and changes f= or =C2=A0 =C2=A0 entries representing Persons in a Directory. =C2=A0 =C2=A0=C2=A0 =C2=A0 * Resolve issues with the representation of Groups in LDAP. =C2=A0 =C2=A0 draft-findlay-ldap-groupofentries =C2=A0 * Define utility schema descriptions widely used: =C2=A0 =C2=A0 draft-stroeder-namedobject and draft-stroeder-mailboxrelate= dobject =C2=A0 =C2=A0=C2=A0 =C2=A0 * Define an informational document that describes the various =C2=A0 =C2=A0 representations of hashed password values in the 'userPassw= ord' =C2=A0 =C2=A0 attribute. draft-stroeder-hashed-userpassword-values =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0Goals and Milestones: =C2=A0 =C2=A0Jan 2016 =C2=A0 =C2=A0Issue new versions of Groups in LDAP, = Utility Schemas and =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hashed Password Va= lues. =C2=A0 =C2=A0Apr 2016 =C2=A0 =C2=A0Issue first revision Internet-Draft of= inetOrgPerson 2.0. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue first revisi= on Internet-Draft on R=46C 2307 revision. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue first revisi= on Internet-Draft on password policy. =C2=A0 =C2=A0Jul 2016 =C2=A0 =C2=A0Submit Groups in LDAP, Utility Schemas= and =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hashed Password Va= lues to IESG for publication as an R=46C. =C2=A0 =C2=A0Oct 2016 =C2=A0 =C2=A0Submit inetOrgPerson 2.0 schema to IES= G for publication as =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an R=46C. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Achieve consensus = on R=46C 2307 Revision and Password Policy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for LDAP. =C2=A0 =C2=A0Jan 2017 =C2=A0 =C2=A0Submit R=46C 2307 Revision and Passwor= d Policy to IESG for =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consideration as a= Proposed Standard. --=C2=A0 Ludovic Poitou http://ludopoitou.com --565415be_19692e66_1b08 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline