From owner-ietf-ldup@mail.imc.org Sat Nov 4 21:24:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10364 for ; Sat, 4 Nov 2000 21:24:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA07141 for ietf-ldup-bks; Sat, 4 Nov 2000 17:31:25 -0800 (PST) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07137 for ; Sat, 4 Nov 2000 17:31:22 -0800 (PST) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13sEkp-0003oU-00 for ietf-ldup@imc.org; Sat, 4 Nov 2000 18:37:51 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Sat, 04 Nov 2000 18:37:45 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Sat, 04 Nov 2000 18:37:17 -0700 From: "Ed Reed" To: Cc: , Subject: draft-ietf-ldup-subentry-04.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_164D25F9.F190FC37" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_164D25F9.F190FC37 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached as the next version of the named draft. Abstract: This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 To control the visibility of entries of type ldapSubEntry,=20 a control, ldapSubentriesControl, is also defined.=20 Note to the working groups -=20 This version adds the specification of the control, but does not yet accomodate the requested clarifications with regard to administrative areas, etc. =20 Please comment at your convenience on the changes made here, while I work to address the administrative area clarifications and publish same prior to the next publication cut-off date. Thank you, Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_164D25F9.F190FC37 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-04.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQNCmRyYWZ0LWlldGYtbGR1cC1zdWJlbnRyeS0wNC50 eHQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RWQgUmVlZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWVkLU1h dHRoZXdzLCBJbmMuIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE5vdmVtYmVyIDUsIDIwMDAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCkxEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQoNCjEuIFN0 YXR1cyBvZiB0aGlzIE1lbW8gDQoNClRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQg YW5kIGlzIGluIGZ1bGwgDQpjb25mb3JtYW5jZSB3aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rp b24gMTAgb2YgUkZDMjAyNi4gDQogDQpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCANCkVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMg YXJlYXMsIGFuZCBpdHMgd29ya2luZyANCmdyb3Vwcy4gTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgDQpkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz LiAgDQogDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIA0Kc2l4IG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgDQpvdGhlciBkb2N1bWVudHMgYXQgYW55IHRpbWUuIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIA0KSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0 byBjaXRlIHRoZW0gb3RoZXIgDQp0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgIA0KIA0KVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiAgDQogDQpUaGUgbGlzdCBv ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIA0KYWNjZXNzZWQgYXQg aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogDQpUaGlzIEludGVybmV0LURyYWZ0 IGV4cGlyZXMgb24gTWF5IDUsIDIwMDEuIA0KDQoNCjIuIEFic3RyYWN0IA0KDQpUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhbiBvYmplY3QgY2xhc3MgY2FsbGVkIGxkYXBTdWJFbnRyeSANCndoaWNo IE1BWSBiZSB1c2VkIHRvIGluZGljYXRlIG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQgDQpyZWxh dGVkIGVudHJpZXMgaW4gdGhlIGRpcmVjdG9yeSwgY2FsbGVkIExEQVAgU3ViZW50cmllcy4gIA0K VG8gY29udHJvbCB0aGUgdmlzaWJpbGl0eSBvZiBlbnRyaWVzIG9mIHR5cGUgbGRhcFN1YkVudHJ5 LCANCmEgY29udHJvbCwgbGRhcFN1YmVudHJpZXNDb250cm9sLCBpcyBhbHNvIGRlZmluZWQuIA0K DQpUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg DQoiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIA0KYW5kICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIA0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4gVGhlIHNlY3Rpb25zIGJl bG93IA0KcmVpdGVyYXRlIHRoZXNlIGRlZmluaXRpb25zIGFuZCBpbmNsdWRlIHNvbWUgYWRkaXRp b25hbCANCm9uZXMuIA0KDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDFdIA0KICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1 LCAyMDAxIA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA1IE5vdmVtYmVyIDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hl bWEgDQoNCjMuIERlZmluaXRpb24gDQoNCg0KMy4xIGxkYXBTdWJFbnRyeSBDbGFzcyANCg0KKCAy LjE2Ljg0MC4xLjExMzcxOS4yLjE0Mi42LjEuMSBOQU1FICdsZGFwU3ViRW50cnknICANCiAgIERF U0MgJ0xEQVAgU3ViZW50cnkgY2xhc3MsIHZlcnNpb24gMScgIA0KICAgICBTVVAgdG9wIFNUUlVD VFVSQUwgIA0KICAgICBNQVkgKCBjbiApICkgIA0KDQpUaGUgY2xhc3MgbGRhcFN1YkVudHJ5IGlz IGludGVuZGVkIHRvIGJlIHVzZWQgYXMgYSBzdXBlci0gDQpjbGFzcyB3aGVuIGRlZmluaW5nIG90 aGVyIHN0cnVjdHVyYWwgY2xhc3NlcyB0byBiZSB1c2VkIA0KYXMgTERBUCBTdWJlbnRyaWVzLCBh bmQgYXMgdGhlIHN0cnVjdHVyYWwgY2xhc3MgdG8gd2hpY2ggDQpBdXhpbGlhcnkgY2xhc3NlcyBt YXkgYmUgYWRkZWQgZm9yIGFwcGxpY2F0aW9uIHNwZWNpZmljIA0Kc3ViZW50cnkgaW5mb3JtYXRp b24uICBXaGVyZSBwb3NzaWJsZSwgdGhlIHVzZSBvZiBBdXhpbGlhcnkgDQpjbGFzc2VzIHRvIGV4 dGVuZCBsZGFwU3ViRW50cmllcyBpcyBzdHJvbmdseSBwcmVmZXJyZWQuIA0KIA0KVGhlIHByZXNl bmNlIG9mIGxkYXBTdWJFbnRyeSBpbiB0aGUgbGlzdCBvZiBzdXBlci1jbGFzc2VzIA0Kb2YgYW4g ZW50cnkgaW4gdGhlIGRpcmVjdG9yeSBtYWtlcyB0aGF0IGVudHJ5IGFuIExEQVAgDQpTdWJlbnRy eS4gIE9iamVjdCBjbGFzc2VzIGRlcml2ZWQgZnJvbSBsZGFwU3ViRW50cnkgYXJlIA0KdGhlbXNl bHZlcyBjb25zaWRlcmVkIGxkYXBTdWJFbnRyeSBjbGFzc2VzLCBmb3IgdGhlIHB1cnBvc2UgDQpv ZiB0aGlzIGRpc2N1c3Npb24uIA0KDQpMREFQIFN1YmVudHJpZXMgTUFZIGJlIG5hbWVkIGJ5IHRo ZWlyIGNvbW1vbk5hbWUgYXR0cmlidXRlIA0KW0xEQVB2M10uICBPdGhlciBuYW1pbmcgYXR0cmli dXRlcyBhcmUgYWxzbyBwZXJtaXR0ZWQuIA0KDQpMREFQIFN1YmVudHJpZXMgTUFZIGJlIGNvbnRh aW5lcnMsIHVubGlrZSB0aGVpciBbWC41MDFdIA0KY291bnRlcnBhcnRzLiANCg0KTERBUCBTdWJl bnRyaWVzIE1BWSBiZSBjb250YWluZWQgYnksIGFuZCB3aWxsIHVzdWFsbHkgYmUgDQpsb2NhdGVk IGluIHRoZSBkaXJlY3RvcnkgaW5mb3JtYXRpb24gdHJlZSBpbW1lZGlhdGVseSANCnN1Ym9yZGlu YXRlIHRvLCBhZG1pbmlzdHJhdGl2ZSBwb2ludHMgYW5kL29yIG5hbWluZyANCmNvbnRleHRzLiAg RnVydGhlciAodW5saWtlIFguNTAwIHN1YmVudHJpZXMpLCBMREFQIA0KU3ViZW50cmllcyBNQVkg YmUgY29udGFpbmVkIGJ5IG90aGVyIExEQVAgU3ViZW50cmllcyAodGhlIA0Kd2F5IG9yZ2FuaXph dGlvbmFsIHVuaXRzIG1heSBiZSBjb250YWluZWQgYnkgb3RoZXIgDQpvcmdhbml6YXRpb25hbCB1 bml0cykuICBEZWVwIG5lc3RpbmdzIG9mIExEQVAgU3ViZW50cmllcyANCmFyZSBkaXNjb3VyYWdl ZCwgYnV0IG5vdCBwcm9oaWJpdGVkLiANCg0KDQozLjIgTGRhcFN1YmVudHJpZXNDb250cm9sIA0K DQpUaGlzIGNvbnRyb2wgaXMgaW5jbHVkZWQgaW4gdGhlIHNlYXJjaFJlcXVlc3QgbWVzc2FnZSBh cyANCnBhcnQgb2YgdGhlIGNvbnRyb2xzIGZpZWxkIG9mIHRoZSBMREFQTWVzc2FnZSwgYXMgZGVm aW5lZCANCmluIFNlY3Rpb24gNC4xLjEyIG9mIFtSRkMyMjUxXS4gDQoNClRoZSBjb250cm9sVHlw ZSBpcyBzZXQgdG8gIlRCRCIuIFRoZSBjcml0aWNhbGl0eSBNQVkgYmUgc2V0IA0KdG8gZWl0aGVy IFRSVUUgb3IgRkFMU0UuICBUaGUgY29udHJvbFZhbHVlIGlzIGFic2VudC4gICANCg0KDQpSZWVk ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXSAN CiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAwMSANCiANDA0KDQoNCklOVEVS TkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNSBOb3ZlbWJlciAyMDAwIA0K ICAgICAgICAgICAgICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQpUaGVyZSBpcyBubyBj b3JyZXNwb25kaW5nIHJlc3BvbnNlIGNvbnRyb2wgZGVmaW5lZC4gDQoNCkxEQVAgU3ViZW50cmll cyBTSE9VTEQgYmUgdHJlYXRlZCBhcyAib3BlcmF0aW9uYWwgb2JqZWN0cyIgDQppbiBtdWNoIHRo ZSBzYW1lIHdheSB0aGF0ICJvcGVyYXRpb25hbCBhdHRyaWJ1dGVzIiBhcmUgbm90IA0KcmVndWxh cmx5IHByb3ZpZGVkIGluIHNlYXJjaCByZXN1bHRzIGFuZCByZWFkIG9wZXJhdGlvbnMgDQp3aGVu IG9ubHkgdXNlciBhdHRyaWJ1dGVzIGFyZSByZXF1ZXN0ZWQpLiAgDQoNCkluIFtYLjUxMV0gYSBT ZXJ2aWNlQ29udHJvbCBvcHRpb24gaXMgdXNlZCB0byBnb3Zlcm4gdGhlIA0KdmlzaWJpbGl0eSBv ZiBYLjUwMCBzdWJlbnRyaWVzLiAgVGhlIHN1YmVudHJ5IA0KU2VydmljZUNvbnRyb2wgb3B0aW9u IGlzIGEgc3BlY2lmaWMgYml0IG9mIGEgYml0c3RyaW5nIA0KdGhhdCwgd2hlbiBzZXQgdG8gVFJV RSBpbiB0aGUgY29tbW9uIGFyZ3VtZW50cyBvZiBhbiBYLjUwMCANClNlYXJjaCBvciBMaXN0IG9w ZXJhdGlvbiwgaW5kaWNhdGVzIHRoYXQgdGhlIG9wZXJhdGlvbiBpcyANCnRvIGFjY2VzcyBPTkxZ IHRoZSBzdWJlbnRyaWVzIGZvdW5kIGluIHRoZSBjb250ZXh0IG9mIHRoZSANCmxpc3Qgb3Igc2Vh cmNoLiAgSW4gZmFjdCwgbm9ybWFsIGVudHJpZXMgYXJlIGV4cGxpY2l0bHkgTk9UIA0KcmV0dXJu ZWQgaW4gdGhlIHJlc3VsdCBvZiBhIGxpc3Qgb3Igc2VhcmNoIG9wZXJhdGlvbiB3aGVuIA0KdGhl IFguNTAwIHN1YmVudHJpZXMgU2VydmljZUNvbnRyb2wgaXMgc2V0LiAgRW50cmllcyB3aGljaCAN CmFyZSBub3Qgc3ViZW50cmllcyBtYXkgc3RpbGwgYmUgcmVmZXJlbmNlZCBpbiB0aGUgYmFzZSAN Cm9iamVjdCBvZiBsaXN0IGFuZCBzZWFyY2ggb3BlcmF0aW9ucyB3aGVyZSB0aGUgc3ViZW50cmll cyANCmNvbnRyb2wgaXMgc2V0LiAgVGhlIFtYLjUxMV0gc3ViZW50cmllcyBTZXJ2aWNlQ29udHJv bCBoYXMgDQpubyBtZWFuaW5nIGZvciBvcGVyYXRpb25zIG90aGVyIHRoYW4gU2VhcmNoIGFuZCBM aXN0IChpLmUuLCANClJlYWQsIE1vZGlmeSwgRGVsZXRlLCBldGMuKS4gDQoNClRoZSBsZGFwU3Vi ZW50cmllc0NvbnRyb2wgaXMgZGVmaW5lZCBmb3IgTERBUCB0byBzaWduYWwgdG8gDQpMREFQIFNl YXJjaCBvcGVyYXRpb25zIHRoYXQgTERBUCBTdWJlbnRyaWVzIGFyZSB0byBiZSANCmluY2x1ZGVk IGluIHRoZSByZXR1cm4gc2V0IG9mIGVudHJpZXMgZm9yIHRoZSBTZWFyY2ggKHdpdGggDQpzY29w ZXMgb3RoZXIgdGhhbiBiYXNlT2JqZWN0KSwgcHJvdmlkZWQgb3RoZXIgU2VhcmNoIA0KY3JpdGVy aWEgKHNjb3BlLCBmaWx0ZXIpIGFyZSBzYXRpc2ZpZWQuICAgDQoNCkZvciBTZWFyY2ggb3BlcmF0 aW9ucyB3aXRoIGEgc2NvcGUgdmFsdWUgb2YgYmFzZU9iamVjdCwgdGhlIA0KcHJlc2VuY2Ugb3Ig YWJzZW5jZSBvZiB0aGUgbGRhcFN1YmVudHJpZXNDb250cm9sIE1VU1QgYmUgDQppZ25vcmVkLiAg U3BlY2lmaWNhbGx5LCBiYXNlT2JqZWN0IHNlYXJjaGVzIGFwcGxpZWQgdG8gDQpsZGFwU3ViRW50 cnkgZW50cmllcyBNVVNUIGJlIGV2YWx1YXRlZCBhcyBpZiB0aGUgDQpsZGFwU3ViZW50cmllc0Nv bnRyb2wgaXMgcHJlc2VudCwgZXZlbiBpZiBpdCBpcyBub3QuIA0KDQpJbiBhZGRpdGlvbiwgTERB UCBzZXJ2ZXJzIFNIT1VMRCBpbXBsZW1lbnQgdGhlIGZvbGxvd2luZyANCnNwZWNpYWwgaGFuZGxp bmcgb2YgbGRhcFN1YkVudHJ5IGVudHJpZXM6IHNlYXJjaCBvcGVyYXRpb25zIA0Kd2hpY2ggaW5j bHVkZSBhIGZpbHRlciAib2JqZWN0Y2xhc3M9bGRhcFN1YkVudHJ5IiBNVVNUIA0KaW5jbHVkZSBl bnRyaWVzIGRlcml2ZWQgZnJvbSB0aGUgbGRhcFN1YkVudHJ5IGNsYXNzIGluIHRoZSANCnNjb3Bl IG9mIHRoZWlyIG9wZXJhdGlvbnMuICBUaGlzIGFsdGVybmF0aXZlIG1ldGhvZCBvZiANCnJlcXVl c3RpbmcgdGhlIG9wZXJhdGlvbiB0byBiZSBhcHBsaWVkIHRvIGVudHJpZXMgb2YgDQpsZGFwU3Vi RW50cnkgY2xhc3MgaXMgaW50dWl0aXZlLCBhbmQgaXMgc3BlY2lmaWVkIHRvIA0KbWFpbnRhaW4g Y29uc2lzdGVuY3kgd2l0aCBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGlzIA0KZG9jdW1lbnQuIA0K DQoNCg0KDQoNCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgM10gDQogICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMDEg DQogDQwNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDUg Tm92ZW1iZXIgMjAwMCANCiAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSAN Cg0KNC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQoNCkxEQVAgU3ViZW50cmllcyB3aWxsIGZy ZXF1ZW50bHkgYmUgdXNlZCB0byBob2xkIGRhdGEgd2hpY2ggDQpyZWZsZWN0cyBlaXRoZXIgdGhl IGFjdHVhbCBvciBpbnRlbmRlZCBiZWhhdmlvciBvZiB0aGUgDQpkaXJlY3Rvcnkgc2VydmljZS4g IEFzIHN1Y2gsIHBlcm1pc3Npb24gdG8gcmVhZCBzdWNoIA0KZW50cmllcyBNQVkgbmVlZCB0byBi ZSByZXN0cmljdGVkIHRvIGF1dGhvcml6ZWQgdXNlcnMuICANCk1vcmUgaW1wb3J0YW50bHksIElG IGEgZGlyZWN0b3J5IHNlcnZpY2UgdHJlYXRzIHRoZSANCmluZm9ybWF0aW9uIGluIGFuIExEQVAg U3ViZW50cnkgYXMgdGhlIGF1dGhvcml0YXRpdmUgc291cmNlIA0Kb2YgcG9saWN5IHRvIGJlIHVz ZWQgdG8gY29udHJvbCB0aGUgYmVoYXZpb3Igb2YgdGhlIA0KZGlyZWN0b3J5LCB0aGVuIHBlcm1p c3Npb24gdG8gY3JlYXRlLCBtb2RpZnksIG9yIGRlbGV0ZSANCnN1Y2ggZW50cmllcyBNVVNUIGJl IGNhcmVmdWxseSByZXN0cmljdGVkIHRvIGF1dGhvcml6ZWQgDQphZG1pbmlzdHJhdG9ycy4gDQoN Cg0KDQo1LiBSZWZlcmVuY2VzIA0KDQpbTERBUHYzXSBTLiBLaWxsZSwgTS4gV2FobCwgYW5kIFQu IEhvd2VzLCAiTGlnaHR3ZWlnaHQgDQpEaXJlY3RvcnkgQWNjZXNzIFByb3RvY29sICh2MykiLCBS RkMgMjI1MSwgRGVjZW1iZXIgMTk5NyANCg0KW1guNTAxXSBJVFUtVCBSZWMuIFguNTAxLCAiVGhl IERpcmVjdG9yeTogTW9kZWxzIiwgMTk5MyBhbmQgDQpzdWJzZXF1ZW50IHZlcnNpb25zIA0KDQpb WC41MTFdIElUVS1UIFJlYy4gWC41MDEsICJUaGUgRGlyZWN0b3J5OiBBYnN0cmFjdCBTZXJ2aWNl IA0KRGVmaW5pdGlvbiIsIDE5OTMgYW5kIHN1YnNlcXVlbnQgdmVyc2lvbnMuIA0KDQoNCg0KNi4g Q29weXJpZ2h0IE5vdGljZSANCg0KQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwMCkuIEFsbCBSaWdodHMgDQpSZXNlcnZlZC4gIA0KIA0KVGhpcyBkb2N1bWVudCBhbmQgdHJh bnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIA0KZnVybmlzaGVkIHRvIG90aGVycywg YW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIA0Kb3Igb3RoZXJ3aXNlIGV4cGxh aW4gaXQgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgDQpiZSBwcmVwYXJlZCwg Y29waWVkLCBwdWJsaXNoZWQgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciANCmluIHBhcnQs IHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIA0KYWJv dmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIA0K YWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0aGlzIA0KZG9j dW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwgc3VjaCBhcyBieSAN CnJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVy bmV0IA0KU29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMg bmVlZGVkIA0KZm9yIHRoZSBwdXJwb3NlIG9mIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRz IGluIHdoaWNoIA0KY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZpbmVkIGlu IHRoZSBJbnRlcm5ldCANClN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUgZm9sbG93ZWQsIG9yIGFz IHJlcXVpcmVkIHRvIA0KdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4gRW5n bGlzaC4gDQogDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDRdIA0KICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDAx IA0KIA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA1 IE5vdmVtYmVyIDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEg DQoNClRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBh bmQgDQp3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyAN CnN1Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogDQpUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyANCnByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCANClRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBU QVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgDQpXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQs IElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgDQpUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCANCk5PVCBJTkZSSU5HRSBBTlkgUklHSFRT IE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQpNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCg0KDQo3LiBBY2tub3dsZWRnZW1lbnRzIA0K DQpUaGUgdXNlIG9mIHN1YkVudHJ5IG9iamVjdCBjbGFzcyB0byBzdG9yZSBSZXBsaWNhIGFuZCAN ClJlcGxpY2F0aW9uIEFncmVlbWVudCBpbmZvcm1hdGlvbiBpcyBkdWUgcHJpbWFyaWx5IHRvIHRo ZSANCmx1Y2lkIGV4cGxhbmF0aW9uIGJ5IE1hcmsgV2FobCwgKHRoZW4gb2YgSW5ub3NvZnQpLCBv ZiBob3cgDQp0aGV5IGNvdWxkIGJlIHVzZWQgYW5kIGV4dGVuZGVkLiANCiANClRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgDQpvZiBhbnkg aW50ZWxsZWN0dWFsIHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIA0KY2xh aW1lZCB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIA0KdGVj aG5vbG9neSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIA0Kd2hp Y2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMgbWlnaHQgb3IgbWlnaHQgbm90IGJlIA0K YXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIG1hZGUgYW55 IA0KZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gSW5mb3JtYXRpb24gb24gdGhl IA0KSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFyZHMt dHJhY2sgDQphbmQgc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlvbiBjYW4gYmUgZm91bmQg aW4gQkNQLTExLiANCkNvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZhaWxhYmxlIGZv ciBwdWJsaWNhdGlvbiANCmFuZCBhbnkgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIA0KcmVzdWx0IG9mIGFuIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4g YSBnZW5lcmFsIGxpY2Vuc2Ugb3IgDQpwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mIHN1Y2ggcHJv cHJpZXRhcnkgcmlnaHRzIGJ5IA0KaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lm aWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgDQpmcm9tIHRoZSBJRVRGIFNlY3JldGFyaWF0LiANCiAN ClRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIA0K YXR0ZW50aW9uIGFueSBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMs IA0Kb3Igb3RoZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5 IHRoYXQgDQptYXkgYmUgcmVxdWlyZWQgdG8gcHJhY3RpY2UgdGhpcyBzdGFuZGFyZC4gUGxlYXNl IGFkZHJlc3MgDQp0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgRXhlY3V0aXZlIERpcmVjdG9y LiANCg0KDQo4LiBBdXRob3IncyBBZGRyZXNzIA0KDQogICAgIEVkd2FyZHMgRS4gUmVlZCANCiAg ICAgUmVlZC1NYXR0aGV3cywgSW5jLiANCiAgICAgMTA2NCBFIDE0MCBOb3J0aCANCg0KUmVlZCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0gDQog ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMDEgDQogDQwNCg0KDQpJTlRFUk5F VC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDUgTm92ZW1iZXIgMjAwMCANCiAg ICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KICAgICBMaW5kb24sIFVU ICA4NDA0MiANCiAgICAgVVNBIA0KICAgICBFLW1haWw6IGVlckBvbmNhbGxkYmEuY29tICANCiAg ICAgIA0KICAgICBMRFVQIE1haWxpbmcgTGlzdDogaWV0Zi1sZHVwQGltYy5vcmcgIA0KICAgICBM REFQRVhUIE1haWxpbmcgTGlzdDogaWV0Zi1sZGFwZXh0QG5ldHNjYXBlLmNvbSANCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQogICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5 IDUsIDIwMDEgDQogDQwNCg== --=_164D25F9.F190FC37-- From owner-ietf-ldup@mail.imc.org Sat Nov 4 23:04:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09278 for ; Sat, 4 Nov 2000 23:04:29 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA07907 for ietf-ldup-bks; Sat, 4 Nov 2000 19:18:27 -0800 (PST) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07903 for ; Sat, 4 Nov 2000 19:18:22 -0800 (PST) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13sGQU-0004Yl-00 for ietf-ldup@imc.org; Sat, 4 Nov 2000 20:24:58 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Sat, 04 Nov 2000 20:24:54 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Sat, 04 Nov 2000 20:24:52 -0700 From: "Ed Reed" To: , , Subject: Discussion: Subentries and Administrative Areas, and draft-ietf-ldup-subentry-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id TAA07904 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit To refresh people's memories of the discussion in Pittsburgh, here are the notes from the LDUP WG meeting there addressing the administrative area / subentry discussion... ================================================= 5. "LDAP Subentry Schema" http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry -03.txt Editor(s): Ed Reed Basic problem is that the presence of a subentry causes an administrative area to be defined. So the administrative area may not exactly coincide with the naming context. The subentry document needs to be updated to define what is meant by each of these terms. The management of administrative areas, and how this differs (if at all) from the management of naming contexts, needs to be documented. This challenges us to as to whether replication needs semantic understanding of administrative areas. This seems like a very thorny issue, and it was suggested that we treat this as a version 2 problem in order to make progress with the existing definition of LDUP. This draft will be revised to make scoping of LDUP subentry more clear. Open issue raised by Kurt is to use a control instead of a filter mechanism to make subentries visible. This issue has been posted to the list. Action: The next revision of this draft will be published by the end of October. ============================================ Now, you'll notice that I've asked to have published the -04 version of the document, which includes the specification of an LDAP control (with no arguments) intended to behave in much the same way as the subentries ServiceControl argument of X.511 Search and List operations. Here, then, begins the discussion about administrative areas, in the hopes that something simple will fall out quickly. I confess that my thinking has always approached naming contexts as being partitions of the namespace, and providing natural boundaries for a corresponding replication administrative area. The discussion at Pittsburgh, though, drove home to me that while that simplification might well suite replication, other administrative areas (schema, access control policy, application-specific whatever) are not inherently limited to working within a naming context, may in fact overlap several contiguous naming contexts, and may not cover all of one or more of the naming contexts it does overlap. In other words, other administrative area definitions are likely to be arbitrary and completely orthogonal to the ones defined for replication. Or at least its certain that we'll find some that are. However, there's an important definition in [X.501] - autonomous administrative domain - which indicates that they are non-overlapping. That might give us leeway to simplify matters. Certainly, for the purposes of LDUP, the replication areas are, indeed, non-overlapping. Further, both inner administrative areas and specific administration areas are both bounded by (e.g. contained within) one of the non-overlapping autonomous administrative domain. So, I think what I"m proposing is that the namingContext auxiliary class that LDUP Arch defines is the "autonomous administrative point", and the subentries we're defining MIGHT be tied to that. Such an evasion (for that is surely what it would be ;-) would leave for future work the definition and management of specific administration areas (SAA) which could then partition the autonomous administrative area, and the inner administrative areas which in turn partition the SAAs. Do I have that right? Would such an approach be satisfactory? And, yes, I'd be perfectly happy defining the bare minimum required right now. Ed From owner-ietf-ldup@mail.imc.org Sun Nov 5 02:44:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11868 for ; Sun, 5 Nov 2000 02:44:45 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA14562 for ietf-ldup-bks; Sat, 4 Nov 2000 23:01:45 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA14523 for ; Sat, 4 Nov 2000 23:01:38 -0800 (PST) Received: (qmail 4101 invoked from network); 5 Nov 2000 07:07:44 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 5 Nov 2000 07:07:44 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Ed Reed'" , , , Subject: RE: Discussion: Subentries and Administrative Areas, anddraft-ietf-ldup-subentry-04.txt Date: Sun, 5 Nov 2000 18:12:37 +1100 Message-ID: <000701c046f7$c8774520$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Ed] Basic problem is that the presence of a subentry causes an administrative area to be defined. So the administrative area may not exactly coincide with the naming context. The subentry document needs to be updated to define what is meant by each of these terms. The management of administrative areas, and how this differs (if at all) from the management of naming contexts, needs to be documented. This challenges us to as to whether replication needs semantic understanding of administrative areas. This seems like a very thorny issue, and it was suggested that we treat this as a version 2 problem in order to make progress with the existing definition of LDUP. This draft will be revised to make scoping of LDUP subentry more clear. [Albert] Replication (and indeed the LDUP WG) clearly does need some semantic understanding of administrative areas (and also of distribution ... not to mention atomicity ;-) Actual management could conceivably be deferred until version 2 and is really a general LDAP issue rather than a specifically LDUP issue since it applies even with no replication. Replication of the managed administration points affecting a replicated area should not be deferred. Specifically, entries must be replicated for each administrative point in the DIT that is an ancestor of the actual replicated area. These are not just "glue" to form the name, which also has to be replicated, but could "simply" be carried by the root of the replicated area. They also involve replicated attributes and subentries with actual administrative information that can only be applied to entries in the replicated area if it has been replicated to the DSAs holding replicas of those entries. This is pretty straight forward - a replication agreement implicitly requires replication of those "ancestor" administrative points (including their subentries). For distribution, additional knowledge information about the DSAs holding NCs below the boundary of a replicated area also needs to be replicated implicitly with that replication area. Otherwise a DUA cannot be given a referral to them. That could be less straight forward. [...Ed] I confess that my thinking has always approached naming contexts as being partitions of the namespace, and providing natural boundaries for a corresponding replication administrative area. [Albert] Not mentioned in the correction below is that the partitioning of the namespace by NCs is a partition according to the single master DSA holding the context prefix. It follows that a DSA cannot hold contiguous NCs, since they are merged into a single NC by the fact that it holds a single context prefix for both. With multi-master, a set of replica DSAs holds the context prefix of a partition of the namespace, by all holding a replicated area which includes that entry. But the same set of DSAs need not all hold all the replicated areas which are part of that partition of the namespace. It is sufficient that the intersection of the sets of replicated areas they each hold include that particular replicated area which has the context prefix. For example an organization (Autonomous Administrative Area) might have replicated areas corresponding to HQ, regional and local organizational units, each with their own DSA at a corresponding office. But a single DSA in say Paris might well hold the replicated areas for the multi-national HQ, the Paris Region and a particular local office. There is no reason why it should also have to hold replicas for every other regional or local organizational unit. A "simple" approach could just eliminate the concept of an NC, as in the current LDUP drafts where it is confused with the new concept of a replicated area (RA). Reading RA instead of NC, the problem seems to just disappear. But then who defines the namespace partitioning? The separate concept of an NC is still needed to administer names. [Ed] The discussion at Pittsburgh, though, drove home to me that while that simplification might well suite replication, other administrative areas (schema, access control policy, application-specific whatever) are not inherently limited to working within a naming context, may in fact overlap several contiguous naming contexts, and may not cover all of one or more of the naming contexts it does overlap. In other words, other administrative area definitions are likely to be arbitrary and completely orthogonal to the ones defined for replication. Or at least its certain that we'll find some that are. [SC] In addition, realistic Directory Access Control Domains add further complications. [Ed] Such an evasion (for that is surely what it would be ;-) would leave for future work the definition and management of specific administration areas (SAA) which could then partition the autonomous administrative area, and the inner administrative areas which in turn partition the SAAs. [SC] The conceptual framework for this "future work" was done many years ago for the X.500 standards. LDAP should simplify protocols when and where possible, but must not change the conceptual framework. Although the the X.500 standards are pretty unreadable, an excellent explanation is in David Chadwick's book, available online at: http://www.salford.ac.uk/its024/Version.Web/Contents.htm Section 11 of chapter 2 actually succeeds in making the administrative framework intelligible! Inner Administrative Areas do not "partition" SAAs since they can be nested as shown on the right of this diagram: http://www.salford.ac.uk/its024/Version.Web/Chapter.2/fig2-6.gif Assuming that actual management can be deferred, definition (by simply adopting the work already done) should not be deferred. Simply specify that ancestor administrative points and their subentries are replicated together with each replicated area. Otherwise replicas simply would not receive essential context information. Visualize a "replicated area" as possibly being a smaller triangle within that nested IAP. It clearly needs to receive copies of each of the ancestor administrative entries and subentries in that diagram. [Ed] However, there's an important definition in [X.501] - autonomous administrative domain - which indicates that they are non-overlapping. That might give us leeway to simplify matters. Certainly, for the purposes of LDUP, the replication areas are, indeed, non-overlapping. Further, both inner administrative areas and specific administration areas are both bounded by (e.g. contained within) one of the non-overlapping autonomous administrative domain. So, I think what I"m proposing is that the namingContext auxiliary class that LDUP Arch defines is the "autonomous administrative point", and the subentries we're defining MIGHT be tied to that. Such an evasion (for that is surely what it would be ;-) would leave for future work the definition and management of specific administration areas (SAA) which could then partition the autonomous administrative area, and the inner administrative areas which in turn partition the SAAs. [Albert] A "Directory hosting ISP" could hold the AAA's for numerous organizations on a single DSA, just as a "Web hosting ISP" holds numerous domains for web service. Each would be replicated with internal DSAs of the organization concerned and with DSAs at other local sites of the ISP to provide global backbone directory service for those organizations. It certainly should not follow that they are all a single replicated area because they hosted on a single DSA. Not only should the various AAA's not be required to receive replicas of each other, but some may only need say 2 replicas at local sites of their ISP while others may want replicas at more. From owner-ietf-ldup@mail.imc.org Sun Nov 5 19:00:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15029 for ; Sun, 5 Nov 2000 19:00:01 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA06386 for ietf-ldup-bks; Sun, 5 Nov 2000 15:00:02 -0800 (PST) Received: from inet-smtp3.oracle.com (inet-smtp3.oracle.com [205.227.43.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06380 for ; Sun, 5 Nov 2000 15:00:00 -0800 (PST) Received: from gmgw02.oraclecorp.com (gmgw02.us.oracle.com [130.35.60.93]) by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id PAA10836; Sun, 5 Nov 2000 15:05:40 -0800 (PST) Received: from oracle.com (whq4op3x38-rtr-opw1-30.us.oracle.com [130.35.35.8]) by gmgw02.oraclecorp.com (8.8.8+Sun/8.8.8) with ESMTP id PAA21985; Sun, 5 Nov 2000 15:05:31 -0800 (PST) Message-ID: <3A05E812.C76571CD@oracle.com> Date: Sun, 05 Nov 2000 15:06:59 -0800 From: Uppili Srinivasan X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Albert.Langer@directory-designs.org, "'Ed Reed'" CC: ietf-ldup@imc.org, ietf-ldapext@netscape.com, d.w.chadwick@salford.ac.uk Subject: Re: Discussion: Subentries and Administrative Areas, anddraft-ietf-ldup-subentry-04.txt References: <000701c046f7$c8774520$17448490@vic.bigpond.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed and Albert: Thanks for re-initiating this discussion. I think there is no real workable way to evade the issue of replication of administrative information associated with services whose administrative boundaries are independent of that of replication. I agree with Albert's comments and his suggestions for augmenting the LDUP architecture document, including treatment of naming contexts. At Pittsburg it was decided that the LDUP model (architecture) document should be updated to present a resolution for conflicts that arise from the fact that ACL administrative areas are independent of replication administrative areas (the latter is defined to coincide with "naming context" boundaries). But the actual issue, as you have stated, is not just specific to ACLs. So a clear general frame-work for this has to be spelled out in the LDUP model document. The following comments Albert has made are especially worth noting. (Some of these have been made before by others as well): - LDAP should simplify protocols when and where possible, but must not change the conceptual framework - The conceptual framework for this "future work" was done many years ago for the X.500 standards And specifically, w.r.t replication: - Actual management could conceivably be deferred .... and is really a general LDAP issue rather than a specifically LDUP issue since it applies even with no replication. - Replication of the managed administration points affecting a replicated area should not be deferred. With subentry and ACL model drafts progressing, the problems resulting from not spelling out a conceptual frame-work for administrative areas and their replication is very evident. Specifically, I propose we incorporate the following recommendations that Albert has made to the LDUP model draft: 1) State that the LDUP replication agreements implicitly requires replication of those "ancestor" administrative points (including their subentries). 2) Eliminate the concept of a NC [as defined in the current LDUP drafts .. where it is indeed confused with replicated area (RA)]. Change the use of NC to read as RA in other relevant discussions. 3) Paraphrase the namespace partitioning discussion along the guidelines in X.500. Cleanup the confusion between NC and replication area in the current draft. Also, the only way LDUP can go forward, in this regard, without conflicting with the future LDAP revision is if we agree now to concretely adopt corresponding X.500 conceptual frame-work. Regards, Uppili. Albert Langer wrote: > [Ed] > Basic problem is that the presence of a subentry causes an > administrative area to be defined. So the administrative > area may not exactly coincide with the naming context. The > subentry document needs to be updated to define what is > meant by each of these terms. The management of > administrative areas, and how this differs (if at all) from > the management of naming contexts, needs to be documented. > > This challenges us to as to whether replication needs > semantic understanding of administrative areas. This seems > like a very thorny issue, and it was suggested that we treat > this as a version 2 problem in order to make progress with > the existing definition of LDUP. This draft will be revised > to make scoping of LDUP subentry more clear. > > [Albert] Replication (and indeed the LDUP WG) clearly does need some > semantic understanding of administrative areas (and also of distribution ... > not to mention atomicity ;-) > > Actual management could conceivably be deferred until version 2 and is > really a general LDAP issue rather than a specifically LDUP issue since it > applies even with no replication. > > Replication of the managed administration points affecting a replicated area > should not be deferred. > > Specifically, entries must be replicated for each administrative point in > the DIT that is an ancestor of the actual replicated area. These are not > just "glue" to form the name, which also has to be replicated, but could > "simply" be carried by the root of the replicated area. They also involve > replicated attributes and subentries with actual administrative information > that can only be applied to entries in the replicated area if it has been > replicated to the DSAs holding replicas of those entries. This is pretty > straight forward - a replication agreement implicitly requires replication > of those "ancestor" administrative points (including their subentries). > > For distribution, additional knowledge information about the DSAs holding > NCs below the boundary of a replicated area also needs to be replicated > implicitly with that replication area. Otherwise a DUA cannot be given a > referral to them. That could be less straight forward. > > [...Ed] > I confess that my thinking has always approached naming > contexts as being partitions of the namespace, and providing > natural boundaries for a corresponding replication administrative area. > > [Albert] > Not mentioned in the correction below is that the partitioning of the > namespace by NCs is a partition according to the single master DSA holding > the context prefix. It follows that a DSA cannot hold contiguous NCs, since > they are merged into a single NC by the fact that it holds a single context > prefix for both. > > With multi-master, a set of replica DSAs holds the context prefix of a > partition of the namespace, by all holding a replicated area which includes > that entry. But the same set of DSAs need not all hold all the replicated > areas which are part of that partition of the namespace. It is sufficient > that the intersection of the sets of replicated areas they each hold include > that particular replicated area which has the context prefix. > > For example an organization (Autonomous Administrative Area) might have > replicated areas corresponding to HQ, regional and local organizational > units, each with their own DSA at a corresponding office. But a single DSA > in say Paris might well hold the replicated areas for the multi-national HQ, > the Paris Region and a particular local office. There is no reason why it > should also have to hold replicas for every other regional or local > organizational unit. > > A "simple" approach could just eliminate the concept of an NC, as in the > current LDUP drafts where it is confused with the new concept of a > replicated area (RA). Reading RA instead of NC, the problem seems to just > disappear. > > But then who defines the namespace partitioning? > > The separate concept of an NC is still needed to administer names. > > [Ed] > The discussion at Pittsburgh, though, drove home to me that while > that simplification might well suite replication, other administrative > areas (schema, access control policy, application-specific whatever) > are not inherently limited to working within a naming context, may > in fact overlap several contiguous naming contexts, and may not > cover all of one or more of the naming contexts it does overlap. > > In other words, other administrative area definitions are likely to be > arbitrary and completely orthogonal to the ones defined for > replication. Or at least its certain that we'll find some that are. > > [SC] > In addition, realistic Directory Access Control Domains add further > complications. > > [Ed] > Such an evasion > (for that is surely what it would be ;-) would leave for future work > the definition and management of specific administration areas (SAA) which > could then partition the autonomous administrative area, and the > inner administrative areas which in turn partition the SAAs. > > [SC] > The conceptual framework for this "future work" was done many years ago for > the X.500 standards. > > LDAP should simplify protocols when and where possible, but must not change > the conceptual framework. > > Although the the X.500 standards are pretty unreadable, an excellent > explanation is in David Chadwick's book, available online at: > > http://www.salford.ac.uk/its024/Version.Web/Contents.htm > > Section 11 of chapter 2 actually succeeds in making the administrative > framework intelligible! > > Inner Administrative Areas do not "partition" SAAs since they can be nested > as shown on the right of this diagram: > > http://www.salford.ac.uk/its024/Version.Web/Chapter.2/fig2-6.gif > > Assuming that actual management can be deferred, definition (by simply > adopting the work already done) should not be deferred. > > Simply specify that ancestor administrative points and their subentries are > replicated together with each replicated area. Otherwise replicas simply > would not receive essential context information. > > Visualize a "replicated area" as possibly being a smaller triangle within > that nested IAP. It clearly needs to receive copies of each of the ancestor > administrative entries and subentries in that diagram. > > [Ed] > However, there's an important definition in [X.501] - autonomous > administrative domain - which indicates that they are non-overlapping. > That might give us leeway to simplify matters. Certainly, for the purposes > of LDUP, the replication areas are, indeed, non-overlapping. > > Further, both inner administrative areas and specific administration areas > are both bounded by (e.g. contained within) one of the non-overlapping > autonomous administrative domain. > > So, I think what I"m proposing is that the namingContext auxiliary class > that LDUP Arch defines is the "autonomous administrative point", and > the subentries we're defining MIGHT be tied to that. Such an evasion > (for that is surely what it would be ;-) would leave for future work > the definition and management of specific administration areas (SAA) which > could then partition the autonomous administrative area, and the > inner administrative areas which in turn partition the SAAs. > > [Albert] > A "Directory hosting ISP" could hold the AAA's for numerous organizations on > a single DSA, just as a "Web hosting ISP" holds numerous domains for web > service. > > Each would be replicated with internal DSAs of the organization concerned > and with DSAs at other local sites of the ISP to provide global backbone > directory service for those organizations. > > It certainly should not follow that they are all a single replicated area > because they hosted on a single DSA. > > Not only should the various AAA's not be required to receive replicas of > each other, but some may only need say 2 replicas at local sites of their > ISP while others may want replicas at more. From owner-ietf-ldup@mail.imc.org Mon Nov 6 09:55:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15297 for ; Mon, 6 Nov 2000 09:55:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA01609 for ietf-ldup-bks; Mon, 6 Nov 2000 06:00:37 -0800 (PST) Received: from black.int.coppercom.com ([63.98.204.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01605 for ; Mon, 6 Nov 2000 06:00:36 -0800 (PST) Received: by black.int.coppercom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 06:01:29 -0800 Message-ID: From: Xuefan Liu To: "'ietf-ldup@imc.org'" Cc: "'xuefan_liu@yahoo.com'" Subject: Replica Host Date: Mon, 6 Nov 2000 06:03:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Sir, I am a Netscape Directory Server user. I have done LDAP code every day. Now I have a question for getting replica Host from LDAP. I am appreciated it if you can tell me how to get replica Host in LDAP. Best regards, Xuefan Liu From owner-ietf-ldup@mail.imc.org Tue Nov 7 06:46:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20407 for ; Tue, 7 Nov 2000 06:46:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA14052 for ietf-ldup-bks; Tue, 7 Nov 2000 02:57:32 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14047 for ; Tue, 7 Nov 2000 02:57:31 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06081; Tue, 7 Nov 2000 06:04:17 -0500 (EST) Message-Id: <200011071104.GAA06081@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-subentry-04.txt Date: Tue, 07 Nov 2000 06:04:17 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Subentry Schema Author(s) : E. Reed Filename : draft-ietf-ldup-subentry-04.txt Pages : 4 Date : 06-Nov-00 This document describes an object class called ldapSubEntry which MAY be used to indicate operations and management related entries in the directory, called LDAP Subentries. To control the visibility of entries of type ldapSubEntry, a control, ldapSubentriesControl, is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-subentry-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-subentry-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001106120225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-subentry-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-subentry-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106120225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Thu Nov 9 22:41:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19287 for ; Thu, 9 Nov 2000 22:41:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA10236 for ietf-ldup-bks; Thu, 9 Nov 2000 18:42:26 -0800 (PST) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10227 for ; Thu, 9 Nov 2000 18:42:23 -0800 (PST) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13u4Fn-0007KJ-00 for ietf-ldup@imc.org; Thu, 9 Nov 2000 19:49:23 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Thu, 09 Nov 2000 19:49:11 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 09 Nov 2000 19:48:59 -0700 From: "Ed Reed" To: , , , , , , , Cc: , Subject: Revision: draft-ietf-ldup-subentry-05.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0C573037.9FFE9247" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_0C573037.9FFE9247 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached updated internet draft. Abstract: This document describes an object class called ldapSubEntry which MAY be = used to indicate operations and management related entries in the = directory, called LDAP Subentries. To control the visibility of entries = of type ldapSubEntry, a control, ldapSubentriesControl, is defined, and a = special case using Search filters is described. This version: language is tightened up quite a bit to clarify required = behavior in specific circumstances, and the OID for the ldapSubentriesContr= ol is defined. =20 Note to the working groups: The discussion about inheritance of subentries= across replication areas (new term - thank you, Albert) will be addressed = in a revision of the LDUP architecture document. The policy governing = inheritance seems to belong somewhere other than this document, which is = intentionally limited in its scope.=20 Regards, Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_0C573037.9FFE9247 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-05.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgDQpkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDUu dHh0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVkIFJlZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVlZC1N YXR0aGV3cywgSW5jLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE5vdmVtYmVyIDE1LCAyMDAwIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQpMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KDQoxLiBT dGF0dXMgb2YgdGhpcyBNZW1vIA0KDQpUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyBpbiBmdWxsIA0KY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0 aW9uIDEwIG9mIFJGQzIwMjYuIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgDQpFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgDQpncm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIA0KZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiANCnNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IA0Kb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSANCkludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIA0KdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iICANCiANClRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gIA0KIA0KVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCmFjY2Vzc2VkIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KIA0KVGhpcyBJbnRlcm5ldC1EcmFm dCBleHBpcmVzIG9uIE1heSAxNSwgMjAwMS4gDQoNCg0KMi4gQWJzdHJhY3QgDQoNClRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGFuIG9iamVjdCBjbGFzcyBjYWxsZWQgbGRhcFN1YkVudHJ5IA0Kd2hp Y2ggTUFZIGJlIHVzZWQgdG8gaW5kaWNhdGUgb3BlcmF0aW9ucyBhbmQgbWFuYWdlbWVudCANCnJl bGF0ZWQgZW50cmllcyBpbiB0aGUgZGlyZWN0b3J5LCBjYWxsZWQgTERBUCBTdWJlbnRyaWVzLiAg DQpUbyBjb250cm9sIHRoZSB2aXNpYmlsaXR5IG9mIGVudHJpZXMgb2YgdHlwZSBsZGFwU3ViRW50 cnksIA0KYSBjb250cm9sLCBsZGFwU3ViZW50cmllc0NvbnRyb2wsIGlzIGRlZmluZWQsIGFuZCBh IHNwZWNpYWwgDQpjYXNlIHVzaW5nIFNlYXJjaCBmaWx0ZXJzIGlzIGRlc2NyaWJlZC4gDQoNClRo ZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCANCiJT SEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg DQphbmQgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgDQpkZXNjcmliZWQgaW4gW1JGQzIxMTldLiBUaGUgc2VjdGlvbnMgYmVsb3cgcmVpdGVyYXRl IHRoZXNlIA0KZGVmaW5pdGlvbnMgYW5kIGluY2x1ZGUgc29tZSBhZGRpdGlvbmFsIG9uZXMuIA0K DQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDFdIA0KICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNSwgMjAwMSANDA0KDQoN CklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxNSBOb3ZlbWJlciAy MDAwIA0KICAgICAgICAgICAgICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQozLiBEZWZp bml0aW9ucyANCg0KDQozLjEgbGRhcFN1YkVudHJ5IENsYXNzIA0KDQooIDIuMTYuODQwLjEuMTEz NzE5LjIuMTQyLjYuMS4xIE5BTUUgJ2xkYXBTdWJFbnRyeScgIA0KICAgREVTQyAnTERBUCBTdWJl bnRyeSBjbGFzcywgdmVyc2lvbiAxJyAgDQogICAgIFNVUCB0b3AgU1RSVUNUVVJBTCAgDQogICAg IE1BWSAoIGNuICkgKSAgDQoNClRoZSBjbGFzcyBsZGFwU3ViRW50cnkgaXMgaW50ZW5kZWQgdG8g YmUgdXNlZCBhcyBhIHN1cGVyLSANCmNsYXNzIHdoZW4gZGVmaW5pbmcgb3RoZXIgc3RydWN0dXJh bCBjbGFzc2VzIHRvIGJlIHVzZWQgDQphcyBMREFQIFN1YmVudHJpZXMsIGFuZCBhcyB0aGUgc3Ry dWN0dXJhbCBjbGFzcyB0byB3aGljaCANCkF1eGlsaWFyeSBjbGFzc2VzIG1heSBiZSBhZGRlZCBm b3IgYXBwbGljYXRpb24gc3BlY2lmaWMgDQpzdWJlbnRyeSBpbmZvcm1hdGlvbi4gIFdoZXJlIHBv c3NpYmxlLCB0aGUgdXNlIG9mIEF1eGlsaWFyeSANCmNsYXNzZXMgdG8gZXh0ZW5kIExEQVAgU3Vi ZW50cmllcyBpcyBzdHJvbmdseSBwcmVmZXJyZWQuIA0KIA0KVGhlIHByZXNlbmNlIG9mIGxkYXBT dWJFbnRyeSBpbiB0aGUgbGlzdCBvZiBzdXBlci1jbGFzc2VzIA0Kb2YgYW4gZW50cnkgaW4gdGhl IGRpcmVjdG9yeSBtYWtlcyB0aGF0IGVudHJ5IGFuIExEQVAgDQpTdWJlbnRyeS4gIE9iamVjdCBj bGFzc2VzIGRlcml2ZWQgZnJvbSBsZGFwU3ViRW50cnkgYXJlIA0KdGhlbXNlbHZlcyBjb25zaWRl cmVkIGxkYXBTdWJFbnRyeSBjbGFzc2VzLCBmb3IgdGhlIHB1cnBvc2UgDQpvZiB0aGlzIGRpc2N1 c3Npb24uIA0KDQpMREFQIFN1YmVudHJpZXMgTUFZIGJlIG5hbWVkIGJ5IHRoZWlyIGNvbW1vbk5h bWUgYXR0cmlidXRlIA0KW1JGQzIyNTFdLiAgT3RoZXIgbmFtaW5nIGF0dHJpYnV0ZXMgYXJlIGFs c28gcGVybWl0dGVkLiANCg0KTERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZXJzLCB1bmxp a2UgdGhlaXIgW1guNTAxXSANCmNvdW50ZXJwYXJ0cy4gDQoNCkxEQVAgU3ViZW50cmllcyBNQVkg YmUgY29udGFpbmVkIGJ5LCBhbmQgd2lsbCB1c3VhbGx5IGJlIA0KbG9jYXRlZCBpbiB0aGUgZGly ZWN0b3J5IGluZm9ybWF0aW9uIHRyZWUgaW1tZWRpYXRlbHkgDQpzdWJvcmRpbmF0ZSB0bywgYWRt aW5pc3RyYXRpdmUgcG9pbnRzLiAgRnVydGhlciAodW5saWtlIA0KWC41MDAgc3ViZW50cmllcyks IExEQVAgU3ViZW50cmllcyBNQVkgYmUgY29udGFpbmVkIGJ5IA0Kb3RoZXIgTERBUCBTdWJlbnRy aWVzICh0aGUgd2F5IG9yZ2FuaXphdGlvbmFsIHVuaXRzIG1heSBiZSANCmNvbnRhaW5lZCBieSBv dGhlciBvcmdhbml6YXRpb25hbCB1bml0cykuICBEZWVwIG5lc3RpbmdzIG9mIA0KTERBUCBTdWJl bnRyaWVzIGFyZSBkaXNjb3VyYWdlZCwgYnV0IG5vdCBwcm9oaWJpdGVkLiANCg0KDQozLjIgbGRh cFN1YmVudHJpZXNDb250cm9sIA0KDQpUaGlzIGNvbnRyb2wgaXMgaW5jbHVkZWQgaW4gdGhlIHNl YXJjaFJlcXVlc3QgbWVzc2FnZSBhcyANCnBhcnQgb2YgdGhlIGNvbnRyb2xzIGZpZWxkIG9mIHRo ZSBMREFQTWVzc2FnZSwgYXMgZGVmaW5lZCANCmluIFNlY3Rpb24gNC4xLjEyIG9mIFtSRkMyMjUx XS4gDQoNClRoZSBjb250cm9sVHlwZSBpcyBzZXQgdG8gIjEuMy42LjEuNC4xLjc2MjguNS4xMDEu MSIuIFRoZSANCmNyaXRpY2FsaXR5IE1BWSBiZSBzZXQgdG8gZWl0aGVyIFRSVUUgb3IgRkFMU0Uu ICBUaGUgDQpjb250cm9sVmFsdWUgaXMgYWJzZW50LiAgIA0KDQoNClJlZWQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdIA0KICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIE1heSAxNSwgMjAwMSANCiANDA0KDQoNCklOVEVSTkVULURSQUZUICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxNSBOb3ZlbWJlciAyMDAwIA0KICAgICAgICAgICAg ICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQpUaGVyZSBpcyBubyBjb3JyZXNwb25kaW5n IHJlc3BvbnNlIGNvbnRyb2wgZGVmaW5lZC4gDQoNCkxEQVAgc2VydmVycyB0aGF0IHN1cHBvcnQg dGhpcyBjb250cm9sIE1VU1QgdHJlYXQgTERBUCANClN1YmVudHJpZXMgYXMgIm9wZXJhdGlvbmFs IG9iamVjdHMiIGluIG11Y2ggdGhlIHNhbWUgd2F5IA0KdGhhdCAib3BlcmF0aW9uYWwgYXR0cmli dXRlcyIgYXJlIG5vdCByZXR1cm5lZCBpbiBzZWFyY2ggDQpyZXN1bHRzIGFuZCBbWC41MTFdIHJl YWQgb3BlcmF0aW9ucyB3aGVuIG9ubHkgdXNlciANCmF0dHJpYnV0ZXMgYXJlIHJlcXVlc3RlZC4g IA0KDQpFbnRyaWVzIHdoaWNoIGFyZSBub3QgTERBUCBTdWJlbnRyaWVzIG1heSBzdGlsbCBiZSAN CnJlZmVyZW5jZWQgaW4gdGhlIGJhc2Ugb2JqZWN0IG9mIHNlYXJjaCBvcGVyYXRpb25zIHdoZXJl IA0KdGhlIGxkYXBTdWJlbnRyaWVzQ29udHJvbCBpcyBwcmVzZW50IGluIHRoZSByZXF1ZXN0LiAg IA0KDQoNCjMuMi4xIExEQVAgU2VhcmNoIHdpdGggc2NvcGUgb3RoZXIgdGhhbiBiYXNlT2JqZWN0 IA0KDQpUaGUgbGRhcFN1YmVudHJpZXNDb250cm9sIGlzIGRlZmluZWQgZm9yIExEQVAgdG8gc2ln bmFsIHRvIA0KTERBUCBTZWFyY2ggb3BlcmF0aW9ucyB0aGF0IE9OTFkgTERBUCBTdWJlbnRyaWVz IGFyZSB0byBiZSANCmluY2x1ZGVkIGluIHRoZSByZXR1cm4gc2V0IG9mIGVudHJpZXMgZm9yIHRo ZSBTZWFyY2gsIA0KcHJvdmlkZWQgb3RoZXIgU2VhcmNoIGNyaXRlcmlhIChzdWNoIGFzIHNjb3Bl IGFuZCBmaWx0ZXIpIA0KYXJlIHNhdGlzZmllZC4gIFdoZW4gbGRhcFN1YmVudHJpZXNDb250cm9s IGlzIE5PVCBpbmNsdWRlZCANCmluIGEgU2VhcmNoIHJlcXVlc3Qgb24gYSBzZXJ2ZXIgdGhhdCBz dXBwb3J0cyB0aGUgY29udHJvbCwgDQpMREFQIFN1YmVudHJpZXMgTVVTVCBiZSBvbWl0dGVkIGZy b20gdGhlIHJldHVybiBzZXQgKHdpdGggDQp0aGUgc2luZ2xlIGV4Y2VwdGlvbiBkZXNjcmliZWQg aW4gc2VjdGlvbiAzLjMsIGJlbG93KS4gDQoNCg0KMy4yLjIgTERBUCBTZWFyY2ggd2l0aCBzY29w ZSBvZiBiYXNlT2JqZWN0IA0KDQpGb3IgU2VhcmNoIG9wZXJhdGlvbnMgd2l0aCBhIHNjb3BlIHZh bHVlIG9mIGJhc2VPYmplY3QsIHRoZSANCnByZXNlbmNlIG9yIGFic2VuY2Ugb2YgdGhlIGxkYXBT dWJlbnRyaWVzQ29udHJvbCBNVVNUIGJlIA0KaWdub3JlZC4gIFNwZWNpZmljYWxseSwgYmFzZU9i amVjdCBzZWFyY2hlcyBhcHBsaWVkIHRvIA0KbGRhcFN1YkVudHJ5IGVudHJpZXMgTVVTVCBiZSBl dmFsdWF0ZWQgYnkgU2VhcmNoIGFzIGlmIHRoZSANCmxkYXBTdWJlbnRyaWVzQ29udHJvbCBpcyBw cmVzZW50LCBldmVuIGlmIGl0IGlzIGFic2VudC4gIA0KDQpUaGlzIHByb3Zpc2lvbiBpcyBpbnRl bmRlZCB0byBwcmVzZXJ2ZSB0aGUgYmVoYXZpb3Igb2YgDQpbWC41MTFdIFJlYWQgb3BlcmF0aW9u cywgd2hpY2ggYXJlIG5vdCBhZmZlY3RlZCBieSB0aGUgDQpbWC41MTFdIHN1YmVudHJpZXMgY29u dHJvbCAoc2VlIHNlY3Rpb24gMy4yLjQgYmVsb3cpLCBhbmQgDQpiZWNhdXNlIGl0IHdvdWxkIHNl ZW0gc2lsbHkgdG8gYmVoYXZlIG90aGVyd2lzZS4gDQoNCg0KMy4yLjMgT3RoZXIgTERBUCBvcGVy YXRpb25zIA0KDQpUaGUgbGRhcFN1YmVudHJpZXNDb250cm9sIGlzIG5vdCBkZWZpbmVkIGZvciBh bnkgTERBUCANCm9wZXJhdGlvbiBvdGhlciB0aGFuIFNlYXJjaC4gIEhvd2V2ZXIsIGFuIExEQVB2 MyBFeHRlbnNpb24gDQpNQVkgZGVmaW5lIGEgdXNlIG9mIHRoaXMgY29udHJvbCB3aXRoIHRoYXQg ZXh0ZW5zaW9uIGFzIA0KbG9uZyBhcyBzdWNoIHVzZSBpcyBjb25zaXN0ZW50IHdpdGggdGhpcyBz cGVjaWZpY2F0aW9uLiANCg0KDQoNCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgICAgICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDE1LCAyMDAxIA0KIA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDE1IE5vdmVtYmVyIDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJl bnRyeSBTY2hlbWEgDQoNCjMuMi40IENvcnJlc3BvbmRlbmNlIHRvIFguNTAwIFtYLjUxMV0gDQoN CkluIFtYLjUxMV0gYSBTZXJ2aWNlQ29udHJvbCBvcHRpb24gaXMgdXNlZCB0byBnb3Zlcm4gdGhl IA0KdmlzaWJpbGl0eSBvZiBbWC41MDFdIHN1YmVudHJpZXMuICBUaGUgc3ViZW50cnkgDQpTZXJ2 aWNlQ29udHJvbCBvcHRpb24gaXMgYSBzcGVjaWZpYyBiaXQgb2YgYSBiaXRzdHJpbmcgDQp0aGF0 LCB3aGVuIHNldCB0byBUUlVFIGluIHRoZSBjb21tb24gYXJndW1lbnRzIG9mIGFuIFguNTAwIA0K U2VhcmNoIG9yIExpc3Qgb3BlcmF0aW9uLCBpbmRpY2F0ZXMgdGhhdCB0aGUgb3BlcmF0aW9uIGlz IA0KdG8gYWNjZXNzIE9OTFkgdGhlIHN1YmVudHJpZXMgZm91bmQgaW4gdGhlIGNvbnRleHQgb2Yg dGhlIA0KbGlzdCBvciBzZWFyY2guICBJbiBmYWN0LCBub3JtYWwgZW50cmllcyBhcmUgZXhwbGlj aXRseSBOT1QgDQpyZXR1cm5lZCBpbiB0aGUgcmVzdWx0IG9mIGEgbGlzdCBvciBzZWFyY2ggb3Bl cmF0aW9uIHdoZW4gDQp0aGUgWC41MDAgc3ViZW50cmllcyBTZXJ2aWNlQ29udHJvbCBpcyBzZXQu ICAgDQoNCkVudHJpZXMgd2hpY2ggYXJlIG5vdCBzdWJlbnRyaWVzIG1heSBzdGlsbCBiZSByZWZl cmVuY2VkIGluIA0KdGhlIGJhc2Ugb2JqZWN0IG9mIGxpc3QgYW5kIHNlYXJjaCBvcGVyYXRpb25z IHdoZXJlIHRoZSANCnN1YmVudHJpZXMgY29udHJvbCBpcyBzZXQuICAgDQoNClRoZSBbWC41MTFd IHN1YmVudHJpZXMgU2VydmljZUNvbnRyb2wgaGFzIG5vIG1lYW5pbmcgZm9yIA0Kb3BlcmF0aW9u cyBvdGhlciB0aGFuIFNlYXJjaCBhbmQgTGlzdCAoaS5lLiwgUmVhZCwgTW9kaWZ5LCANCkRlbGV0 ZSwgZXRjLikuIA0KDQoNCjMuMyBTZWFyY2ggRmlsdGVyICANCg0KTERBUCBzZXJ2ZXJzIE1VU1Qg aW1wbGVtZW50IHRoZSBmb2xsb3dpbmcgc3BlY2lhbCBoYW5kbGluZyANCm9mIGxkYXBTdWJFbnRy eSBlbnRyaWVzOiBzZWFyY2ggb3BlcmF0aW9ucyB3aGljaCBpbmNsdWRlIGEgDQpmaWx0ZXIgIm9i amVjdGNsYXNzPWxkYXBTdWJFbnRyeSIgTVVTVCBpbmNsdWRlIGVudHJpZXMgDQpkZXJpdmVkIGZy b20gdGhlIGxkYXBTdWJFbnRyeSBjbGFzcyBpbiB0aGUgc2NvcGUgb2YgdGhlaXIgDQpvcGVyYXRp b25zLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIGNvbnRyb2wgKHNlY3Rpb24gMy4yIA0KYWJv dmUpIGlzIGluY2x1ZGVkIGluIHRoZSBTZWFyY2ggb3Igbm90LiAgIA0KDQpUaGlzIG1ldGhvZCBv ZiByZXF1ZXN0aW5nIHRoZSBvcGVyYXRpb24gYmUgYXBwbGllZCB0byANCmVudHJpZXMgb2YgbGRh cFN1YkVudHJ5IGNsYXNzIGlzIGludHVpdGl2ZSwgYW5kIGlzIA0Kc3BlY2lmaWVkIHRvIG1haW50 YWluIGNvbnNpc3RlbmN5IHdpdGggcHJldmlvdXMgZHJhZnRzIG9mIA0KdGhpcyBkb2N1bWVudC4g DQoNCkRldmVsb3BlcnMgU0hPVUxEIHVzZSB0aGUgY29udHJvbCAoc2VjdGlvbiAzLjIpIGluIGxp ZXUgb2YgDQp0aGUgU2VhcmNoIEZpbHRlciBtZXRob2Qgb2Ygc2VhcmNoaW5nIGZvciBMREFQIFN1 YmVudHJpZXMsIA0KYXMgdGhlIFNlYXJjaCBGaWx0ZXIgbWV0aG9kIE1BWSBiZSBkZXByZWNpYXRl ZCBpbiB0aGUgDQpmdXR1cmUuIA0KDQoNCg0KNC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQoN CkxEQVAgU3ViZW50cmllcyB3aWxsIGZyZXF1ZW50bHkgYmUgdXNlZCB0byBob2xkIGRhdGEgd2hp Y2ggDQpyZWZsZWN0cyBlaXRoZXIgdGhlIGFjdHVhbCBvciBpbnRlbmRlZCBiZWhhdmlvciBvZiB0 aGUgDQpkaXJlY3Rvcnkgc2VydmljZS4gIEFzIHN1Y2gsIHBlcm1pc3Npb24gdG8gcmVhZCBzdWNo IA0KZW50cmllcyBNQVkgbmVlZCB0byBiZSByZXN0cmljdGVkIHRvIGF1dGhvcml6ZWQgdXNlcnMu ICANCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgNF0gDQogICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE1LCAyMDAxIA0KIA0M DQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE1IE5vdmVt YmVyIDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoNCk1v cmUgaW1wb3J0YW50bHksIElGIGEgZGlyZWN0b3J5IHNlcnZpY2UgdHJlYXRzIHRoZSANCmluZm9y bWF0aW9uIGluIGFuIExEQVAgU3ViZW50cnkgYXMgdGhlIGF1dGhvcml0YXRpdmUgc291cmNlIA0K b2YgcG9saWN5IHRvIGJlIHVzZWQgdG8gY29udHJvbCB0aGUgYmVoYXZpb3Igb2YgdGhlIA0KZGly ZWN0b3J5LCB0aGVuIHBlcm1pc3Npb24gdG8gY3JlYXRlLCBtb2RpZnksIG9yIGRlbGV0ZSANCnN1 Y2ggZW50cmllcyBNVVNUIGJlIGNhcmVmdWxseSByZXN0cmljdGVkIHRvIGF1dGhvcml6ZWQgDQph ZG1pbmlzdHJhdG9ycy4gDQoNCg0KDQo1LiBSZWZlcmVuY2VzIA0KDQpbUkZDMjExOV0gUy4gQnJh ZG5lciwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gDQpJbmRpY2F0ZSBSZXF1aXJlbWVu dCBMZXZlbHMiLCBSRkMgMjExOSwgTWFyY2ggMTk5NyANCg0KW1JGQzIyNTFdIFMuIEtpbGxlLCBN LiBXYWhsLCBhbmQgVC4gSG93ZXMsICJMaWdodHdlaWdodCANCkRpcmVjdG9yeSBBY2Nlc3MgUHJv dG9jb2wgKHYzKSIsIFJGQyAyMjUxLCBEZWNlbWJlciAxOTk3IA0KDQpbWC41MDFdIElUVS1UIFJl Yy4gWC41MDEsICJUaGUgRGlyZWN0b3J5OiBNb2RlbHMiLCAxOTkzIGFuZCANCnN1YnNlcXVlbnQg dmVyc2lvbnMgDQoNCltYLjUxMV0gSVRVLVQgUmVjLiBYLjUwMSwgIlRoZSBEaXJlY3Rvcnk6IEFi c3RyYWN0IFNlcnZpY2UgDQpEZWZpbml0aW9uIiwgMTk5MyBhbmQgc3Vic2VxdWVudCB2ZXJzaW9u cyANCg0KDQoNCjYuIENvcHlyaWdodCBOb3RpY2UgDQoNCkNvcHlyaWdodCAoQykgVGhlIEludGVy bmV0IFNvY2lldHkgKDIwMDApLiBBbGwgUmlnaHRzIA0KUmVzZXJ2ZWQuICANCiANClRoaXMgZG9j dW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCANCmZ1cm5pc2hl ZCB0byBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiANCm9yIG90 aGVyd2lzZSBleHBsYWluIGl0IG9yIGFzc2lzdCBpbiBpdHMgaW1wbGVtZW50YXRpb24gbWF5IA0K YmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUg b3IgDQppbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueSBraW5kLCBwcm92aWRlZCB0 aGF0IHRoZSANCmFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZSBp bmNsdWRlZCBvbiANCmFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZl ciwgdGhpcyANCmRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3YXks IHN1Y2ggYXMgYnkgDQpyZW1vdmluZyB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2Vz IHRvIHRoZSBJbnRlcm5ldCANClNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgb3JnYW5pemF0aW9u cywgZXhjZXB0IGFzIG5lZWRlZCANCmZvciB0aGUgcHVycG9zZSBvZiBkZXZlbG9waW5nIEludGVy bmV0IHN0YW5kYXJkcyBpbiB3aGljaCANCmNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIGNvcHlyaWdo dHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgDQpTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZv bGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byANCnRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBv dGhlciB0aGFuIEVuZ2xpc2guIA0KIA0KVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBh Ym92ZSBhcmUgcGVycGV0dWFsIGFuZCANCndpbGwgbm90IGJlIHJldm9rZWQgYnkgdGhlIEludGVy bmV0IFNvY2lldHkgb3IgaXRzIA0Kc3VjY2Vzc29ycyBvciBhc3NpZ25zLiANCg0KUmVlZCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0gDQogICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE1LCAyMDAxIA0KIA0MDQoNCg0KSU5URVJORVQt RFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE1IE5vdmVtYmVyIDIwMDAgDQogICAg ICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoNCiANClRoaXMgZG9jdW1lbnQg YW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIA0KcHJvdmlkZWQgb24gYW4g IkFTIElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIA0KVEhFIElOVEVSTkVU IEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCANCldBUlJBTlRJRVMsIEVYUFJF U1MgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCANClRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIA0KTk9UIElORlJJ TkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiANCk1FUkNIQU5UQUJJ TElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iIA0KDQoNCjcuIEFja25v d2xlZGdlbWVudHMgDQoNClRoZSB1c2Ugb2Ygc3ViRW50cnkgb2JqZWN0IGNsYXNzIHRvIHN0b3Jl IFJlcGxpY2EgYW5kIA0KUmVwbGljYXRpb24gQWdyZWVtZW50IGluZm9ybWF0aW9uIGlzIGR1ZSBw cmltYXJpbHkgdG8gdGhlIA0KbHVjaWQgZXhwbGFuYXRpb24gYnkgTWFyayBXYWhsLCAodGhlbiBv ZiBJbm5vc29mdCksIG9mIGhvdyANCnRoZXkgY291bGQgYmUgdXNlZCBhbmQgZXh0ZW5kZWQuIA0K IA0KVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBz Y29wZSANCm9mIGFueSBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQg bWlnaHQgYmUgDQpjbGFpbWVkIHRvIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVz ZSBvZiB0aGUgDQp0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBl eHRlbnQgdG8gDQp3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBvciBt aWdodCBub3QgYmUgDQphdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBp dCBoYXMgbWFkZSBhbnkgDQplZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZv cm1hdGlvbiBvbiB0aGUgDQpJRVRGJ3MgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRz IGluIHN0YW5kYXJkcy10cmFjayANCmFuZCBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9u IGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEuIA0KQ29waWVzIG9mIGNsYWltcyBvZiByaWdodHMgbWFk ZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0aW9uIA0KYW5kIGFueSBhc3N1cmFuY2VzIG9mIGxpY2Vu c2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgDQpyZXN1bHQgb2YgYW4gYXR0ZW1wdCBt YWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciANCnBlcm1pc3Npb24gZm9yIHRoZSB1 c2Ugb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgDQppbXBsZW1lbnRlcnMgb3IgdXNlcnMg b2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCANCmZyb20gdGhlIElFVEYgU2Vj cmV0YXJpYXQuIA0KIA0KVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBi cmluZyB0byBpdHMgDQphdHRlbnRpb24gYW55IGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50 IGFwcGxpY2F0aW9ucywgDQpvciBvdGhlciBwcm9wcmlldGFyeSByaWdodHMgd2hpY2ggbWF5IGNv dmVyIHRlY2hub2xvZ3kgdGhhdCANCm1heSBiZSByZXF1aXJlZCB0byBwcmFjdGljZSB0aGlzIHN0 YW5kYXJkLiBQbGVhc2UgYWRkcmVzcyANCnRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBFeGVj dXRpdmUgRGlyZWN0b3IuIA0KDQoNCjguIEF1dGhvcidzIEFkZHJlc3MgDQoNCiAgICAgRWR3YXJk cyBFLiBSZWVkIA0KICAgICBSZWVkLU1hdHRoZXdzLCBJbmMuIA0KICAgICAxMDY0IEUgMTQwIE5v cnRoIA0KICAgICBMaW5kb24sIFVUICA4NDA0MiANCiAgICAgVVNBIA0KICAgICBFLW1haWw6IGVl ckBvbmNhbGxkYmEuY29tICANCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQogICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5 IDE1LCAyMDAxIA0KIA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDE1IE5vdmVtYmVyIDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRy eSBTY2hlbWEgDQoNCiAgICAgIA0KICAgICBMRFVQIE1haWxpbmcgTGlzdDogaWV0Zi1sZHVwQGlt Yy5vcmcgIA0KICAgICBMREFQRVhUIE1haWxpbmcgTGlzdDogaWV0Zi1sZGFwZXh0QG5ldHNjYXBl LmNvbSANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUmVlZCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQogICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDE1LCAyMDAxIA0KIA0MDQo= --=_0C573037.9FFE9247-- From owner-ietf-ldup@mail.imc.org Mon Nov 13 07:28:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01153 for ; Mon, 13 Nov 2000 07:28:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA10992 for ietf-ldup-bks; Mon, 13 Nov 2000 03:33:02 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10983 for ; Mon, 13 Nov 2000 03:33:00 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05695; Mon, 13 Nov 2000 06:40:19 -0500 (EST) Message-Id: <200011131140.GAA05695@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-subentry-05.txt Date: Mon, 13 Nov 2000 06:40:19 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Subentry Schema Author(s) : E. Reed Filename : draft-ietf-ldup-subentry-05.txt Pages : 7 Date : 10-Nov-00 This document describes an object class called ldapSubEntry which MAY be used to indicate operations and management related entries in the directory, called LDAP Subentries. To control the visibility of entries of type ldapSubEntry, a control, ldapSubentriesControl, is defined, and a special case using Search filters is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-subentry-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-subentry-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001110102804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-subentry-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-subentry-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001110102804.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Nov 14 16:42:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09641 for ; Tue, 14 Nov 2000 16:42:50 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA16296 for ietf-ldup-bks; Tue, 14 Nov 2000 12:06:14 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16287 for ; Tue, 14 Nov 2000 12:06:11 -0800 (PST) Received: from qsun.mt.att.com ([135.16.12.1]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.4) with SMTP id PAA25910; Tue, 14 Nov 2000 15:08:33 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id PAA18604; Tue, 14 Nov 2000 15:08:29 -0500 Date: Tue, 14 Nov 2000 15:08:29 -0500 Message-Id: <200011142008.PAA18604@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: internet-drafts@ietf.org Subject: New version of draft-ietf-ldup-replica-req Cc: capple@ecal.com, ietf-ldup@imc.org, johns@cisco.com, rmoats@coreon.com, rweiser@digsigtrust.com, stokes@austin.ibm.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet Drafts Editor - Please publish the draft below as draft-ietf-ldup-replica-req-05.txt. It replaces the previous (-04) version. LDUP Mailing list - A new version of the LDUP Requirements draft is attached below. Since there were few comments on the previous version, most of the changes were to clean up grammar and rephrase things to (we hope) clarify them. There are three new requirements (MM7, AM7, AM8) and one old requirement has been removed (M6 from the -04 draft). As always, please send comments to the list. John, Chris - Since there was very little mailing list comment on version -04 which was sent to the list in September, we request that this version go to Working Group last call. Rick Huber ------- ------- ------- ------- ------- ------- ------- ------- ------- Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: May 2001 Ryan D. Moats Coreon, Inc. Richard V. Huber AT&T Laboratories November 2000 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-05.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. Stokes, et al Expires February 2001 [Page 1] Internet-Draft LDAPv3 Replication Requirements August 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Stokes, et al Expires February 2001 [Page 2] Internet-Draft LDAPv3 Replication Requirements August 2000 Table of Contents 1 Introduction.......................................................4 2 Terminology........................................................4 3 The Possible Models................................................6 4 Requirements.......................................................8 4.1 General.........................................................8 4.2 Model...........................................................8 4.3 Protocol........................................................9 4.4 Schema.........................................................10 4.5 Single Master..................................................11 4.6 Multi-Master...................................................11 4.7 Administration and Management..................................11 4.8 Security.......................................................12 5 Security Considerations...........................................12 6 Acknowledgements..................................................12 7 References........................................................13 A.APPENDIX A - Usage Scenarios......................................13 A.1.Extranet Example...............................................13 A.2.Consolidation Example..........................................14 A.3.Replication Heterogeneous Deployment Example...................14 A.4.Shared Name Space Example......................................15 A.5.Supplier Initiated Replication.................................15 A.6.Consumer Initiated Replication.................................15 A.7.Prioritized attribute replication..............................15 A.8.Bandwidth issues...............................................16 A.9.Interoperable Administration and Management....................16 A.10.Enterprise Directory Replication Mesh.........................17 A.11.Failure of the Master in a Master-Slave Replicated Directory..17 A.12.Failure of a Directory Holding Critical Service Information...17 B.APPENDIX B - Rationale............................................18 B.1.Meta-Data Implications.........................................18 B.2.Order of Transfer for Replicating Data.........................18 B.3.Schema Mismatches and Replication..............................19 B.4.Detecting and Repairing Inconsistencies Among Replicas.........20 B.5.Some Test Cases for Conflict Resolution in Multi-Master Replication......................................................21 B.6.Data Privacy During Replication................................24 B.7.Failover in Single-Master Systems..............................25 B.8.Including Operational Attributes in Atomic Operations..........26 Authors' Addresses..................................................26 Full Copyright Statement............................................27 Stokes, et al Expires February 2001 [Page 3] Internet-Draft LDAPv3 Replication Requirements August 2000 1 Introduction Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here. This document first introduces the terminology to be used, then presents the different replication models being considered. Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification. 2 Terminology The following terms are used in this document: Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. This may also be known as "unit of replication". Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Atomicity Information - Information about atomic operations passed as part of replication. Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Stokes, et al Expires February 2001 [Page 4] Internet-Draft LDAPv3 Replication Requirements August 2000 Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate. Fractional replication - The capability to filter a subset of attributes for replication. Incremental Update - A replica update that contains only those attributes or entries that have changed. Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica ring. Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Meta-Data - Data collected by the replication system that describes the status/state of replication. Multi-Master Replication - A replication model where entries can be written and updated on any of several updateable replica copies without requiring communication with other updateable replicas before the write or update is performed. Naming Context - Suffix of a sub-tree of entries held in a single server [X.500]. For replication, this is the vertex of a replica. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both. Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier. Replica - A collection of entries in the DIT, defined by a naming context, and including all or some of the depending entries contained therein, which divides directory data into a discrete partition whose Stokes, et al Expires February 2001 [Page 5] Internet-Draft LDAPv3 Replication Requirements August 2000 propagation behavior may be independently configured from other partitions. Replicas may overlap or be nested. Replica-Ring - The servers that hold a particular replica. A server may be part of several replica-rings. Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered. Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts. Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica ring. Replication Initiation Conflict - In multi-master replication, a Replication Initiation Conflict is a situation where two masters want to update the same replica at the same time. Replication Session - A session set up between two servers in a replica ring to pass update information as part of a Replica Cycle. Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single- and multi-master systems. Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of a naming context for replication. Topology - The shape of the directed graph describing the relationships between replicas. Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas. Update Propagation - Protocol-based process by which directory replicas are reconciled. Updateable Replica - A copy of the replicated information that may be read and written via LDAP requests. 3 The Models Stokes, et al Expires February 2001 [Page 6] Internet-Draft LDAPv3 Replication Requirements August 2000 The objective is to provide an interoperable, LDAP v3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments. There are five data consistency models. Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Concurrency, Independence, Durability) [ACID]. Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories, Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the replica topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas. Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. The added complexity of the distributed 2-phase commit required for Model 1 is significant; therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies. Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3. Stokes, et al Expires February 2001 [Page 7] Internet-Draft LDAPv3 Replication Requirements August 2000 4 Requirements 4.1 General G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. G3. LDAP replication SHOULD have minimal impact on both the system and network performance. G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate. G5. The LDAP replication standard SHOULD NOT limit the size of a replica. G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound. G7. All policy and state data pertaining to replication MUST be accessible via LDAP. 4.2 Model M1. The model MUST support the following triggers for initiation of a replica cycle: a) A configurable set of scheduled times b) Periodically, with a configurable period between replica cycles c) A configurable maximum amount of time between replica cycles d) A configurable number of accumulated changes e) Change in the value of a critical OID f) As the result of an automatic rescheduling after a replication initiation conflict g) A manual request for immediate replication With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well- known place defined by the standard, e.g. the Replication Agreement(s). Stokes, et al Expires February 2001 [Page 8] Internet-Draft LDAPv3 Replication Requirements August 2000 M2. The replication model MUST support both master-slave and multi- master relationships. M3. A value shared between replicas in a replica ring must eventually converge to the same value on all of its constituent replicas. M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, and name space information. M5. LDAP replication MUST NOT require all copies of the replicated information to be complete copies of the replicated object. The model MUST support Partial Replicas. M6. The determination of which OIDs are critical MUST be configurable in the replication agreement. M7. The parameters of the replication process among the members of the replica-ring, including access parameters, necessary authentication credentials, and assurances of confidentiality (encryption) MUST be defined in a standard location (e.g. the replication agreements). M8. The replication agreements SHOULD accommodate multiple servers receiving the same replica under a single predefined agreement. M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet. M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition. M11. There MUST be a facility that can update, or totally refresh, a replica-ring from a standard data format, such as LDIF format [RFC2849]. 4.3 Protocol P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection (e.g. supplier cannot reach a replica). Stokes, et al Expires February 2001 [Page 9] Internet-Draft LDAPv3 Replication Requirements August 2000 P2. The supplier MUST track updates sent to the consumer and not resend already acknowledged ones, even in the event of recovery from a failed replica cycle. P3. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format. P4. Incremental replication MUST be allowed. P5. The replication protocol MUST allow either a master or slave replica to initiate the replication process. P6. The protocol MUST support propagation of atomicity information. P7. The protocol SHOULD NOT preclude support of Transactional Consistency (model 1). P8. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session. 4.4 Schema SC1. A standard way to determine what replicas are held on a server MUST be defined. SC2. A standard schema for representing replication agreements MUST be defined. SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined. SC4. A standard method for determining the location of replication agreements MUST be defined. SC5. A standard schema for publishing state information about a given replica MUST be defined. SC6. A standard method for determining the location of replica state information MUST be defined. SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT. SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP. Stokes, et al Expires February 2001 [Page 10] Internet-Draft LDAPv3 Replication Requirements August 2000 SC9. An entry MUST be uniquely identifiable throughout its lifetime. 4.5 Single Master SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica. SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them. 4.6 Multi-Master MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication. MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles. MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. 4.7 Administration and Management AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period. Stokes, et al Expires February 2001 [Page 11] Internet-Draft LDAPv3 Replication Requirements August 2000 AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. AM3. Access to replication agreements, topologies, and policies attributes MUST be provided through LDAP. AM4. The capability to check the differences between two replicas for the same information SHOULD be provided. AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided. AM6. Access control information (ACI) associated with sensitive data MUST be deleted after or simultaneously with the deletion of the sensitive data. Likewise, during Adds, ACI MUST be added first or simultaneously with the addition of that data. AM7. It MUST be possible to add a 'blank' replica to a replica-ring, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system. AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-ring. 4.8 Security S1. During initiation of a replication session, authentication and verification of authorization of both the replica and the source directory MUST be allowed before any data is transferred. S2. The transport for LDAP synchronization MUST permit assurance of the integrity and privacy of all data transferred. S3. To promote interoperability, there MUST be a mandatory-to- implement data privacy mechanism. S4. The transport for administrative access MUST permit assurance of the integrity and privacy of all data transferred. 5 Security Considerations This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. 6 Acknowledgements Stokes, et al Expires February 2001 [Page 12] Internet-Draft LDAPv3 Replication Requirements August 2000 This document is based on input from IETF members interested in LDUP Replication. 7 References [ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317. [NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/docui/index.htm#../ndslib/dsov_enu/ data/h6tvg4z7.htm, September, 2000. [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models. [XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] A. APPENDIX A - Usage Scenarios The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix. A.1. Extranet Example A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. Stokes, et al Expires February 2001 [Page 13] Internet-Draft LDAPv3 Replication Requirements August 2000 For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall. The requirements that follow from this scenario are: . One-way replication, single mastered. . Authentication of clients. . Common access control and access control identification. . Secure transmission of updates. . Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. A.2. Consolidation Example Company A acquires company B. Each company has an existing directory. During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements that follow from this scenario are: . Multi-Master replication. . Common access control model. Access control model identification. . Secure transmission of updates. . Replication between DITs with potentially differing schema. A.3. Replication Heterogeneous Deployment Example An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each. In this case, multi-master replication is required to ensure that the multiple updateable replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements that follow from this scenario are: . Multi-Master replication . Common access control model and Access control model identification. . Secure transmission of updates. . Replication among DITs with potentially differing schemas. Stokes, et al Expires February 2001 [Page 14] Internet-Draft LDAPv3 Replication Requirements August 2000 A.4. Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements that follow from this scenario are: . Multi-Master replication. . Common access control model and Access control model identification. . Secure transmission of updates. A.5. Supplier Initiated Replication This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule. The requirements that follow from this scenario are: . Single-master environment. . Supplier-initiated replication. . Secure transmission of updates. A.6. Consumer Initiated Replication Again a single mastered replication topology, but the replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements that follow from this scenario are: . Single-master environment. . Consumer initiated replication. . Open scheduling (anytime). A.7. Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states Stokes, et al Expires February 2001 [Page 15] Internet-Draft LDAPv3 Replication Requirements August 2000 that passwords are critical and the new value must be available immediately (e.g. shortly) after any change. Replication needs to occur immediately for critical attributes/entries. The requirements that follow from this scenario are: . Incremental replication of changes. . Immediate replication on change of certain attributes. . Replicate based on time/attribute semantics. A.8. Bandwidth issues The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements that follow from this scenario are: . Minimize repetitive updates when replicating from multiple replication paths. . Incremental replication of changes. . Provide replication cycles to delay and/or retry when connections cannot be reached. . Allowances for consumer initiated or supplier initiated replication. A.9. Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP'RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements that follow from this scenario are: . Provides replication audit history. . Provisions for managing conflict resolution. . Provide LDAP access to predetermined agreements, topology and policy attributes. . Provide operations for comparing replica's content for validity. Stokes, et al Expires February 2001 [Page 16] Internet-Draft LDAPv3 Replication Requirements August 2000 . Provide LDAP access to status and audit information. A.10. Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers replication. The requirements that follow from this scenario are: . Predefined replication agreements that manage more than a single area of replication that is held on numerous servers. . Common support of replication management knowledge across vendor implementation. . Rescheduling and continuation of a replication cycle when one server in a replica ring is busy and/or unavailable. A.11. Failure of the Master in a Master-Slave Replicated Directory A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered. The requirements that follow from this scenario are: . An existing slave replica must be "promote-able" to become the new master. . The "promotion" must be done without significant downtime, since updates to the directory will continue. A.12. Failure of a Directory Holding Critical Service Information An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted. Stokes, et al Expires February 2001 [Page 17] Internet-Draft LDAPv3 Replication Requirements August 2000 The requirements that follow from this scenario are: . Multi-master replication . Ability to reschedule replication sessions . Support for manual review and override of replication conflict resolution B. APPENDIX B - Rationale This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements. B.1. Meta-Data Implications Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta- data from the system while still ensuring that meta-data will not grow forever. B.2. Order of Transfer for Replicating Data Situations may arise where it would be beneficial to replicate data out-of-order (e.g. send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single- master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory. While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise. As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that Stokes, et al Expires February 2001 [Page 18] Internet-Draft LDAPv3 Replication Requirements August 2000 some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted attribute so that the schema change can be done with no problems. If the schema change moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined. In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi- master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out- of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication. Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7. B.3. Schema Mismatches and Replication Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendor's products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3. There are only a few possible responses when a mismatch is discovered. . Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10. . Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the implementation; in the extreme it could support use of the replication protocol in meta-directories. . Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer. Requirement M10 is intended to exclude the last option. Stokes, et al Expires February 2001 [Page 19] Internet-Draft LDAPv3 Replication Requirements August 2000 Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches. Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead. The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided. One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas. For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include: . All schema elements are replicated. . Schema elements are replicated only if they are used by attributes that are being replicated. . Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol. B.4. Detecting and Repairing Inconsistencies Among Replicas Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies. A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same naming context and compare the answers, possibly by BINDing to each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g. chaining), mechanisms to force access to a particular replica should be supplied. Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server Stokes, et al Expires February 2001 [Page 20] Internet-Draft LDAPv3 Replication Requirements August 2000 it has a replication agreement with and report the differences back to the client as the result If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be. When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication. Requirements AM2, AM4, and AM5 address these needs. B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied. As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled. While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration. In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that the change to A takes precedence using whatever rules are in force for conflict resolution. B.5.1. Create-Create A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B. Stokes, et al Expires February 2001 [Page 21] Internet-Draft LDAPv3 Replication Requirements August 2000 In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed. In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.) As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B. The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica ring (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed. In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired. B.5.2. Rename-Rename On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN. In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists. In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values. Stokes, et al Expires February 2001 [Page 22] Internet-Draft LDAPv3 Replication Requirements August 2000 Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5. B.5.3. Locking Based on Atomicity of ModifyRequest There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B process a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated. B.5.4. General Principles With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server. To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening Stokes, et al Expires February 2001 [Page 23] Internet-Draft LDAPv3 Replication Requirements August 2000 operations by another user may have changed the value. In the multi- master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above. The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment. B.5.5. Avoiding the Problem The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: . Several directory users/applications are changing the same data . They are changing the data at the same time . They are using different directory servers to make these changes . They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. B.6. Data Privacy During Replication Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected during replication. In some cases, the network environment (e.g. a private network) may provide sufficient privacy for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data privacy was not made a requirement for all Stokes, et al Expires February 2001 [Page 24] Internet-Draft LDAPv3 Replication Requirements August 2000 replication sessions. But there are a substantial number of applications that will need data privacy, so there is a requirement (S2) that the protocol allow for data privacy in those cases where it is needed. This leaves the question of what privacy mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data privacy mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S3) for a mandatory-to-implement data privacy mechanism. B.7. Failover in Single-Master Systems In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system. One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole. Factors that designers and implementors should consider when working on failover include: . If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set. . If data privacy mechanisms (e.g. encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas. . It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications. Stokes, et al Expires February 2001 [Page 25] Internet-Draft LDAPv3 Replication Requirements August 2000 . The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated. . The old master will eventually be repaired and returned to the replica ring. It might join the ring as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed. . Availability would be maximized if the whole failover process could be automated (e.g. failover is initiated by an external system when it determines that the original master is not functioning properly). B.8. Including Operational Attributes in Atomic Operations LDAPv3 [RFC2251] declares that some operations are atomic (e.g. all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data. It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place. Authors' Addresses Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, Utah 84106 USA E-mail: rweiser@digsigtrust.com Telephone: +1 801 246 4323 Fax: +1 801 246 4361 Ellen J. Stokes Tivoli Systems 6300 Bridgepoint Parkway Austin, Texas 78731 Stokes, et al Expires February 2001 [Page 26] Internet-Draft LDAPv3 Replication Requirements August 2000 USA E-mail: estokes@tivoli.com Telephone: +1 512 436 9098 Fax: +1 512 436 1199 Ryan D. Moats Coreon, Inc. 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@coreon.net Telephone: +1 402 894 9456 Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL Stokes, et al Expires February 2001 [Page 27] Internet-Draft LDAPv3 Replication Requirements August 2000 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stokes, et al Expires February 2001 [Page 28] From owner-ietf-ldup@mail.imc.org Wed Nov 15 03:28:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06611 for ; Wed, 15 Nov 2000 03:28:48 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA22483 for ietf-ldup-bks; Tue, 14 Nov 2000 23:40:54 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA22474 for ; Tue, 14 Nov 2000 23:40:51 -0800 (PST) Received: (qmail 12914 invoked from network); 15 Nov 2000 07:47:49 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 15 Nov 2000 07:47:49 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Richard V Huber'" , Cc: , , , , , , , Subject: RE: New version of draft-ietf-ldup-replica-req Date: Wed, 15 Nov 2000 18:53:25 +1100 Message-ID: <000901c04ed9$233f61c0$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200011142008.PAA18604@qsun.mt.att.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is just to confirm that my opposition to both LDUP WG and IETF final call still stands, as explained below (previously posted as a PS under an inappropriate topic thread). I am CCing to the Area Directors as advance notice that the question of whether LDUP is making a fundamental technical mistake is being raised. Contrary to the "assumption" I made in item 1 below. There has been no initial draft, nor any discussion or other indication that work is actually proceeding, to revise architectural and protocol drafts to achieve "eventual convergence". I still believe there is likely to be a consensus in the WG that "eventual convergence" is a requirement. That would exclude "Model 3: Limited Effort Eventual (or Probabilistic) Consistency" and therefore contradict the following stated requirement: "4.1 General G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above." I am not aware of any justification or other discussion that has been presented in support of this requirement to support "Limited Effort Eventual Consistency", which amounts to permitting "Eventual Inconsistency". Steve, an author of the URP draft, mentioned that he took it for granted that eventual convergence was in fact required, indicated that he would be presenting a revised URP draft to achieve that and suggested that related changes would be needed in the architectural draft. No other view was expressed by anyone. I formally request that the WG chairs put this as a separate issue to the WG prior to WG "final call" on the requirements draft and establish what consensus, if any, does exist on this matter. If it is an oversight it can easily be fixed. If in fact LDUP is seriously proposing "eventual inconsistency", that should be made clear now. On the other matters below (and others not listed), I assume the absence of expressed opposition from others, and the report of discussions at the last LDUP meeting at IETF, does reflect a "rough consensus" within the WG against "atomicity" etc. My understanding is that my continuing belief that this is a fundamental technical mistake should therefore be expressed as opposition to LDUP's final position rather than delaying LDUP from publishing that as it's final position. The WG has had an adequate opportunity to change it's position. BTW Recent discussions since the draft seemed to indicate some degree of agreement on a requirement to replicate administration and distribution knowledge. From my reading of the email archives, this necessity was pointed out, "vigorously", a long time ago. I believe it is always a mistake to design anything without establishing requirements first and that mistake is again being made on that issue, which affects subentry controls etc, too. My previous comments follow: *** PS This also a "hi" to all in view of long absence. Sorry I haven't been able to respond to latest requirements doc due to other commitments (still stuck in those for a while yet). But then nobody else has either. I do believe it was a significant improvement and genuine effort to address my objections. For the record: 1. I'm assuming some means of guaranteeing eventual convergence *will* be proposed with at least an initial draft prior to final call on the requirements draft. I believe there is probably a consensus for eventual convergence and the apparant ambiguity in the requirements draft about this may be unintentional and therefore easily fixed. A fix would remove the contradictory references to non-convergent models in the final para of section 3. The whole discussion of models in section 3 is just confusing if in fact the intention is to require guaranteed eventual convergence. Model 2 should be clearly stated as *the* (only) relevant model. Actual requirements 4.1 G1 and G2 are also confusing. But the real test of whether there is in fact an intention to guarantee convergence is however whether anyone is actually working on a means to achieve it. The current URP and architecture simply does not. I still haven't seen a redraft of URP and architecture to meet the apparant consensus to support reliable eventual convergence under all circumstances. 2. My objection to non-atomicity still stands for final call but I'm assuming there is little point arguing about it further within LDUP unless others want to take it up. The draft now at least makes it possible to have serious discussion about the issue in IETF review and does include several requirements which cannot in fact be met without atomicity, such as accurate replication of access controls and attributes such as "modifiers name". although I disagree with much of the analysis in appendix B.5 and also the continued misunderstanding of applications for multi-master replication in appendix A on usage scenarios. There are still some inadequacies in presentation of the issue but the fundamental question is now simply whether or not atomicity should be a requirement rather than whether a document that shows no comprehension of the issue at all should be presented to the IETF at all. I still believe a fundamental technical mistake is being made on that question. I also still believe the requirements draft should be actively seeking input from directory users on the impact of non-atomicity. 3. I agree with the requirement 4.1 G6 for no unbounded conflict resolution records. This is a better description than "oscillation". It is not met by my MDCR draft and would need further work if in fact the current URP and architecture drafts do not come up with a means of guaranteed eventual convergence based only on timestamps. I'm not planning to do any work on it unless some interest is shown by others as a result of failure to deliver a viable URP and architecture with eventual convergence. Sorry I simply don't have time to follow up on these issues at the moment. Am just reminding that they are still there in case others want to take them up before the document goes from LDUP to IETF final call. *** From owner-ietf-ldup@mail.imc.org Wed Nov 15 18:43:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20776 for ; Wed, 15 Nov 2000 18:43:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA18367 for ietf-ldup-bks; Wed, 15 Nov 2000 14:50:07 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18354 for ; Wed, 15 Nov 2000 14:50:04 -0800 (PST) Received: from qsun.mt.att.com ([135.16.12.1]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.4) with SMTP id RAA11342; Wed, 15 Nov 2000 17:45:12 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA16018; Wed, 15 Nov 2000 17:45:10 -0500 Date: Wed, 15 Nov 2000 17:45:10 -0500 Message-Id: <200011152245.RAA16018@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: Albert.Langer@directory-designs.org Subject: RE: New version of draft-ietf-ldup-replica-req Cc: capple@ecal.com, ietf-ldup@imc.org, johns@cisco.com, ned.freed@innosoft.com, paf@cisco.com, rmoats@coreon.com, rweiser@digsigtrust.com, stokes@austin.ibm.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Albert - I've restated/summarized the issues you raised and then added my replies. Please let me know if I misunderstood or missed some of your comments. 1. Model 3 should not be allowed. Only model 2 should be supported. These are requirements for the LDUP protocol, not for specific LDUP implementations. There may be situations where model 3 (or model 1, if the overhead issues can be worked out) is useful (as witness the reference to an existing implementation of model 3), so we feel the protocol should support them (requirements G1, G2). Now from a practical point of view you may well be correct in saying that model 2 is a lot more useful that model 3. In fact, the applications that I am personally involved with require model 2, and I would not buy a directory that only offered model 3. But that is no reason to keep people who CAN use model 3 from having it. 2. The requirements should not become an RFC until there is a URP draft that supports eventual consistency. As I understand it, you want model 2. The current requirements say that model 2 is a MUST, so I'm not sure what would be gained by delaying the requirements draft. Also, as a general principle, the requirements should come before the design, so I don't feel we should wait for the design before we publish the requirements as an RFC. 3. Atomicity issues. We've discussed some of the problems with atomicity in multi-master environments in Appendix B.5. What specific issues do you have with this? Do you see a way to make atomicity "work" in these cases? Also, I would note that two of the authors of the revised draft (Ryan Moats and I) have quite a lot of experience in using directories for service provider applications, so user experience is not being ignored. 4. The subentry draft may add new replication needs. True. But any new LDAP feature may add replication needs. We can't wait for every possible feature to make sure that we have covered them all. The right thing to do here is to ask the author of the subentry draft to include a section on replication issues rather than holding up the requirements draft. Rick Huber : From: "Albert Langer" : To: "'Richard V Huber'" , : Cc: , , , : , , : , , : Subject: RE: New version of draft-ietf-ldup-replica-req : : This is just to confirm that my opposition to both LDUP WG and IETF final : call still stands, as explained below (previously posted as a PS under an : inappropriate topic thread). : : I am CCing to the Area Directors as advance notice that the question of : whether LDUP is making a fundamental technical mistake is being raised. : : Contrary to the "assumption" I made in item 1 below. There has been no : initial draft, nor any discussion or other indication that work is actually : proceeding, to revise architectural and protocol drafts to achieve "eventual : convergence". I still believe there is likely to be a consensus in the WG : that "eventual convergence" is a requirement. That would exclude "Model 3: : Limited Effort Eventual (or Probabilistic) Consistency" and therefore : contradict the following stated requirement: : : "4.1 General : : G1. LDAP Replication MUST support models 2 (Eventual Consistency) and : 3 (Limited Effort Eventual Consistency) above." : : I am not aware of any justification or other discussion that has been : presented in support of this requirement to support "Limited Effort Eventual : Consistency", which amounts to permitting "Eventual Inconsistency". Steve, : an author of the URP draft, mentioned that he took it for granted that : eventual convergence was in fact required, indicated that he would be : presenting a revised URP draft to achieve that and suggested that related : changes would be needed in the architectural draft. No other view was : expressed by anyone. : : I formally request that the WG chairs put this as a separate issue to the WG : prior to WG "final call" on the requirements draft and establish what : consensus, if any, does exist on this matter. If it is an oversight it can : easily be fixed. If in fact LDUP is seriously proposing "eventual : inconsistency", that should be made clear now. : : On the other matters below (and others not listed), I assume the absence of : expressed opposition from others, and the report of discussions at the last : LDUP meeting at IETF, does reflect a "rough consensus" within the WG against : "atomicity" etc. My understanding is that my continuing belief that this is : a fundamental technical mistake should therefore be expressed as opposition : to LDUP's final position rather than delaying LDUP from publishing that as : it's final position. The WG has had an adequate opportunity to change it's : position. : : BTW Recent discussions since the draft seemed to indicate some degree of : agreement on a requirement to replicate administration and distribution : knowledge. From my reading of the email archives, this necessity was pointed : out, "vigorously", a long time ago. I believe it is always a mistake to : design anything without establishing requirements first and that mistake is : again being made on that issue, which affects subentry controls etc, too. : : My previous comments follow: : : *** : PS This also a "hi" to all in view of long absence. Sorry I haven't been : able to respond to latest requirements doc due to other commitments (still : stuck in those for a while yet). But then nobody else has either. I do : believe it was a significant improvement and genuine effort to address my : objections. : : For the record: : : 1. I'm assuming some means of guaranteeing eventual convergence *will* be : proposed with at least an initial draft prior to final call on the : requirements draft. I believe there is probably a consensus for eventual : convergence and the apparant ambiguity in the requirements draft about this : may be unintentional and therefore easily fixed. A fix would remove the : contradictory references to non-convergent models in the final para of : section 3. The whole discussion of models in section 3 is just confusing if : in fact the intention is to require guaranteed eventual convergence. Model 2 : should be clearly stated as *the* (only) relevant model. : : Actual requirements 4.1 G1 and G2 are also confusing. But the real test of : whether there is in fact an intention to guarantee convergence is however : whether anyone is actually working on a means to achieve it. The current URP : and architecture simply does not. : : I still haven't seen a redraft of URP and architecture to meet the apparant : consensus to support reliable eventual convergence under all circumstances. : : 2. My objection to non-atomicity still stands for final call but I'm : assuming there is little point arguing about it further within LDUP unless : others want to take it up. The draft now at least makes it possible to have : serious discussion about the issue in IETF review and does include several : requirements which cannot in fact be met without atomicity, such as accurate : replication of access controls and attributes such as "modifiers name". : although I disagree with much of the analysis in appendix B.5 and also the : continued misunderstanding of applications for multi-master replication in : appendix A on usage scenarios. There are still some inadequacies in : presentation of the issue but the fundamental question is now simply whether : or not atomicity should be a requirement rather than whether a document that : shows no comprehension of the issue at all should be presented to the IETF : at all. I still believe a fundamental technical mistake is being made on : that question. I also still believe the requirements draft should be : actively seeking input from directory users on the impact of non-atomicity. : : 3. I agree with the requirement 4.1 G6 for no unbounded conflict resolution : records. This is a better description than "oscillation". It is not met by : my MDCR draft and would need further work if in fact the current URP and : architecture drafts do not come up with a means of guaranteed eventual : convergence based only on timestamps. I'm not planning to do any work on it : unless some interest is shown by others as a result of failure to deliver a : viable URP and architecture with eventual convergence. : : Sorry I simply don't have time to follow up on these issues at the moment. : : Am just reminding that they are still there in case others want to take them : up before the document goes from LDUP to IETF final call. : *** From owner-ietf-ldup@mail.imc.org Wed Nov 15 21:26:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02119 for ; Wed, 15 Nov 2000 21:26:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA20082 for ietf-ldup-bks; Wed, 15 Nov 2000 17:31:37 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA20072 for ; Wed, 15 Nov 2000 17:31:35 -0800 (PST) Received: (qmail 14975 invoked from network); 16 Nov 2000 01:38:35 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 16 Nov 2000 01:38:35 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Richard V Huber'" Cc: , , , , , , , Subject: RE: New version of draft-ietf-ldup-replica-req Date: Thu, 16 Nov 2000 12:44:26 +1100 Message-ID: <000c01c04f6e$c16fcb60$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200011152245.RAA16018@qsun.mt.att.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Richard] I've restated/summarized the issues you raised and then added my replies. Please let me know if I misunderstood or missed some of your comments. 1. Model 3 should not be allowed. Only model 2 should be supported. These are requirements for the LDUP protocol, not for specific LDUP implementations. There may be situations where model 3 (or model 1, if the overhead issues can be worked out) is useful (as witness the reference to an existing implementation of model 3), so we feel the protocol should support them (requirements G1, G2). Now from a practical point of view you may well be correct in saying that model 2 is a lot more useful that model 3. In fact, the applications that I am personally involved with require model 2, and I would not buy a directory that only offered model 3. But that is no reason to keep people who CAN use model 3 from having it. [Albert] Thanks for the response. A vague feeling that there is "no reason to keep people who CAN use model 3 from having it" is hardly grounds for imposing a mandatory requirement that LDUP develop protocols to meet their needs. The most that could follow from that is "SHOULD", not "MUST". But even "SHOULD" would just be the same sort of waffle as the pious wishes for a general solution to meta-directory issues in previous drafts. We simply aren't working on a problem that can be solved without guaranteed eventual convergence. Model 3 ("limited effort consistency") is needed for multi-master replication among such a large number of independent nodes that it becomes impossible to maintain globally consistent state information as to which nodes are actually participating at any given time. There may also be other situations in which it is needed (eg nodes that are not "servers" attempting to provide a reliable service to "clients" but just trying to get a better picture of the world around them, without storage capacity for global information). Examples that come to mind with "servers" include the replication of newsgroups and (distributed) email lists. Despite the best efforts of "backbones" it is impractical to ensure that all nodes do receive all updates so the feeds diverge due to batches not being collected within the "limited best effort" criteria for purges. Model 2 is simply not capable of scaling to the size of systems such as Usenet with currently available technology on a multi-master basis. It is inherently confined to situations where a relatively small number of "servers" (hundreds, perhaps thousands, but not millions) are maintaining a common "backbone" for a much larger number of "slave" servers and end user clients - such as for example LDAP directories ;-) For example the current LDUP architecture requires each node to maintain and exchange information about the state of all other nodes, which adds a very significant overhead to each replication session and severely limits scalability. Perhaps that could be improved on within the scope of model 2, but it is a non-trivial problem for which nobody in LDUP has come up with a suggestion. I believe there will be a growing demand for improved protocols meeting requirements for "model 3" as the return to understanding the internet as a "peer to peer" network gathers pace. Examples include "Freenet" and "Groove", which could easily point to future peer to peer replication systems reaching millions of replicating nodes but could not hope to maintain more than "best effort" guarantees. Some may well involve the use of LDAP clients and even exchange information analagous to directory entries, though I cannot think of any example of work in that area. But if and when they do, that is *all* they will have in common with LDUP work. The design issues for "model 3" replication protocols has virtually nothing in common with those for "model 2" that actually relates to replication. LDUP has not been chartered to do that work, has not done any such work, and knows nothing about the issues involved. We have to provide a viable solution for replication of LDAP directories. They clearly require eventual convergence and would be useless with "limited effort" convergence since the inevitable divergence would negate the benefits desired from actual needs for LDAP directories. [Richard] 2. The requirements should not become an RFC until there is a URP draft that supports eventual consistency. As I understand it, you want model 2. The current requirements say that model 2 is a MUST, so I'm not sure what would be gained by delaying the requirements draft. Also, as a general principle, the requirements should come before the design, so I don't feel we should wait for the design before we publish the requirements as an RFC. [Albert] I agree that the current wording does require model 2 and that it is quite proper to publish requirements before design. My problem is that the requirements are being published long after the design and the current design is not capable of meeting those requirements. I have repeatedly explained why it is simply not possible to guarantee convergence using the "timestamps" approach in the current architecture in the face of real world situations where DSAs have clocks that are not only unsynchronized but can even jump backwards due to time zone mistakes etc and where they crash and get later restored from backups. This has been dismissed as a "religious" issue despite references to the extensive research done on the subject for the Coda file system project and the commercial deployment of replication protocols that do guarantee eventual convergence in Active Directory. Since no work has actually been done to fix the problem, my concern is that if model 3 is listed as just as much a "MUST" requirement as model 2, LDUP could resort to "incremental" delivery and proudly unleash on the world a broken protocol that guarantees "eventual divergence", while deferring for "subsequent work" anything actually useful. The "eventual divergence" in the current architecture does not provide any of the scalability requirements that do motivate model 3. It is simply broken and must be fixed. Adding another MUST in parallel may not be intended to weaken the force of the first MUST, but it can nevertheless have that effect. [Richard] 3. Atomicity issues. We've discussed some of the problems with atomicity in multi-master environments in Appendix B.5. What specific issues do you have with this? Do you see a way to make atomicity "work" in these cases? Also, I would note that two of the authors of the revised draft (Ryan Moats and I) have quite a lot of experience in using directories for service provider applications, so user experience is not being ignored. [Albert] I have published a draft demonstrating that atomicity can be made to work. Atomicity *requires* that only one conflicting change be eventually successful. Essentially the only way that can work in a multi-master situation is by revoking some changes. B.5.1 and 5.2 accept that reality for create and rename conflicts but inexplicably does not consider that approach for other kinds of conflicts. I have shown it can be done without administrative intervention, which may be tolerable for create and rename conflicts but certainly not for more frequent conflicts. On the second sentence, I do not believe the experience of the authors is ever a useful substitute for actively making a "Request For Comment" from users likely to be affected by a problematic issue. The latest draft is a vast improvement on the previous in at least mentioning potential problems. However it does not actively seek user input because it seeks to minimize the problems and/or present them as unavoidable. Instead it should give clear examples of how existing and essential applications would actually be affected. Instead of saying: "The common characteristics of the examples are: . Several directory users/applications are changing the same data . They are changing the data at the same time . They are using different directory servers to make these changes . They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences." The draft should instead say: *** If two users update Access Control Information from clients accessing different servers the eventual result may differ unpredictably from that intended by either of them. Even if the result does converge to the result intended by one of them, in the simplest possible case, with changes to just 2 attributes, up to 6 separate intermediate states may be used to determine access controls actually applied to the entry at various servers during the course of replication while convergence is achieved. Changes to larger numbers of attributes result in a combinatorial explosion of possible intermediate states. Access granted or denied to entries is essentially unpredictable during the course of a replication update, which may extend over hours or days. There may be useful applications for a directory service that does not support access control information. Users expecting a directory with predictable access control should be aware of the consequences of using LDUP standards for multi-master replication. The following excerpt provides some details from Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc *** 3.1 Latest Known Wins Consistency The "Latest Known Wins" approach has the outcome that all attributes will "eventually" reach the latest value entered into the system. During the "eventuality" being reached, intermediate states reflecting a combination of states which have existed over time may be held by an individual DSA. These intermediate states are best described using an example. Two operations, T1 at time 1 and T2 at time 2, occur on an entry updating attributes A and B. This may be viewed as follows : T0 T1 T2 A0 A1 A2 B0 B1 B2 "Latest Known Wins" consistency has the semantics that all directories will eventually have the state A2, B2 (providing no further operations in the distributed system affect attributes A and B). However, at times between either update occurring and this "eventuality", the directory state may be any combination of the individual states of A and B depending on the primitives currently received and processed by each DSA. That is, any of the following states may exist : * A0, B0 (Neither Operation has yet occurred) * A0, B1 (Partial completion of Operation 1) * A0, B2 (Partial completion of Operation 2) * A1, B0 (Partial completion of Operation 1) * A1, B1 (Operation 1 has occurred) * A1, B2 (Operation 1 completed, Partial completion of Operation 2) * A2, B0 (Partial completion of Operation 2) * A2, B1 (Operation 1 completed, Partial completion of Operation 2) * A2, B2 (Operation 2 has occurred) *** I'll try to prepare a detailed response on specific issues in B.5 for a separate message. In case I don't get time, perhaps the above will at least provide food for thought. [Richard] 4. The subentry draft may add new replication needs. True. But any new LDAP feature may add replication needs. We can't wait for every possible feature to make sure that we have covered them all. The right thing to do here is to ask the author of the subentry draft to include a section on replication issues rather than holding up the requirements draft. [Albert] We should not be adding new features at all. Replication of administrative information is a necessity for a viable directory service. That requirement has been overlooked and should be stated. Subentries are not a "feature" but a mechanism. In the course of considering how that mechanism is used to achieve requirements for replication of information about replication it has suddenly been realised that requirements for replication of other kinds of administrative information are a good deal more complex than previously supposed. What is happening is not that someone has come up with a proposed new feature, but that the penny has started to drop about certain aspects of a global distributed directory that were not clear before, but have to be dealt with when you go beyond an "Access" Protocol and start getting into "Service" protocols such as replication. From owner-ietf-ldup@mail.imc.org Thu Nov 16 07:04:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23924 for ; Thu, 16 Nov 2000 07:04:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27297 for ietf-ldup-bks; Thu, 16 Nov 2000 03:20:47 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27278 for ; Thu, 16 Nov 2000 03:20:41 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09172; Thu, 16 Nov 2000 06:28:15 -0500 (EST) Message-Id: <200011161128.GAA09172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-05.txt Date: Thu, 16 Nov 2000 06:28:14 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAPv3 Replication Requirements Author(s) : E. Stokes, R. Weiser, R. Moats, R. Huber Filename : draft-ietf-ldup-replica-req-05.txt Pages : 28 Date : 15-Nov-00 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-replica-req-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-replica-req-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001115091759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001115091759.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Thu Nov 16 17:54:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28375 for ; Thu, 16 Nov 2000 17:54:05 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA11306 for ietf-ldup-bks; Thu, 16 Nov 2000 13:46:01 -0800 (PST) Received: from mail1.ecal.com ([216.150.139.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11302 for ; Thu, 16 Nov 2000 13:45:59 -0800 (PST) Received: from pacapple ([216.150.139.10]) by mail1.ecal.com (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35) with SMTP id com; Thu, 16 Nov 2000 16:52:58 -0500 Reply-To: From: capple@ecal.com (Christopher Apple) To: , "'Richard V Huber'" Cc: , , , , , , Subject: RE: New version of draft-ietf-ldup-replica-req Date: Thu, 16 Nov 2000 16:52:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A1_01C04FED.ACC48E60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <000c01c04f6e$c16fcb60$17448490@vic.bigpond.net.au> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C04FED.ACC48E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My responses below..... Chris Apple capple@ecal.com -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] Sent: Wednesday, November 15, 2000 8:44 PM To: 'Richard V Huber' Cc: capple@ecal.com; ietf-ldup@imc.org; johns@cisco.com; ned.freed@innosoft.com; paf@cisco.com; rmoats@coreon.com; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: New version of draft-ietf-ldup-replica-req [Richard] I've restated/summarized the issues you raised and then added my replies. Please let me know if I misunderstood or missed some of your comments. 1. Model 3 should not be allowed. Only model 2 should be supported. These are requirements for the LDUP protocol, not for specific LDUP implementations. There may be situations where model 3 (or model 1, if the overhead issues can be worked out) is useful (as witness the reference to an existing implementation of model 3), so we feel the protocol should support them (requirements G1, G2). Now from a practical point of view you may well be correct in saying that model 2 is a lot more useful that model 3. In fact, the applications that I am personally involved with require model 2, and I would not buy a directory that only offered model 3. But that is no reason to keep people who CAN use model 3 from having it. [Albert] Thanks for the response. A vague feeling that there is "no reason to keep people who CAN use model 3 from having it" is hardly grounds for imposing a mandatory requirement that LDUP develop protocols to meet their needs. The most that could follow from that is "SHOULD", not "MUST". But even "SHOULD" would just be the same sort of waffle as the pious wishes for a general solution to meta-directory issues in previous drafts. We simply aren't working on a problem that can be solved without guaranteed eventual convergence. CHRIS> Rick's language did not suggest to me that there was any sense of vagueness about whether or not there are users of LDAP implementations that would view Model 3 support as a MUST. It would not be listed as a MUST at this stage of revising the requirements document if the authors (some of the top LDAP experts in the world) and many other members of the working group didn't know of a good reason for it being stated as that strong of a requirement. And you point out one of those good reasons in the next paragraph that you wrote.... Model 3 ("limited effort consistency") is needed for multi-master replication among such a large number of independent nodes that it becomes impossible to maintain globally consistent state information as to which nodes are actually participating at any given time. There may also be other situations in which it is needed (eg nodes that are not "servers" attempting to provide a reliable service to "clients" but just trying to get a better picture of the world around them, without storage capacity for global information). Examples that come to mind with "servers" include the replication of newsgroups and (distributed) email lists. Despite the best efforts of "backbones" it is impractical to ensure that all nodes do receive all updates so the feeds diverge due to batches not being collected within the "limited best effort" criteria for purges. Model 2 is simply not capable of scaling to the size of systems such as Usenet with currently available technology on a multi-master basis. It is inherently confined to situations where a relatively small number of "servers" (hundreds, perhaps thousands, but not millions) are maintaining a common "backbone" for a much larger number of "slave" servers and end user clients - such as for example LDAP directories ;-) For example the current LDUP architecture requires each node to maintain and exchange information about the state of all other nodes, which adds a very significant overhead to each replication session and severely limits scalability. Perhaps that could be improved on within the scope of model 2, but it is a non-trivial problem for which nobody in LDUP has come up with a suggestion. I believe there will be a growing demand for improved protocols meeting requirements for "model 3" as the return to understanding the internet as a "peer to peer" network gathers pace. Examples include "Freenet" and "Groove", which could easily point to future peer to peer replication systems reaching millions of replicating nodes but could not hope to maintain more than "best effort" guarantees. Some may well involve the use of LDAP clients and even exchange information analagous to directory entries, though I cannot think of any example of work in that area. But if and when they do, that is *all* they will have in common with LDUP work. The design issues for "model 3" replication protocols has virtually nothing in common with those for "model 2" that actually relates to replication. LDUP has not been chartered to do that work, has not done any such work, and knows nothing about the issues involved. We have to provide a viable solution for replication of LDAP directories. They clearly require eventual convergence and would be useless with "limited effort" convergence since the inevitable divergence would negate the benefits desired from actual needs for LDAP directories. CHRIS> We'll let the WG express concensus or demonstrate the lack thereof on whether or not "limited effort" convergence is useless or useful. I am aware of your opinion on this matter. Your opinion will be considered along with alternative viewpoints after the WG Last Call is over. John Strassner and I will make a decision about whether concensus exists on the draft as it is currently written. One opinion will not derail a recommendation from John and I about requesting an IESG Last Call or requesting that another revision of the document be undertaken. [Richard] 2. The requirements should not become an RFC until there is a URP draft that supports eventual consistency. As I understand it, you want model 2. The current requirements say that model 2 is a MUST, so I'm not sure what would be gained by delaying the requirements draft. Also, as a general principle, the requirements should come before the design, so I don't feel we should wait for the design before we publish the requirements as an RFC. [Albert] I agree that the current wording does require model 2 and that it is quite proper to publish requirements before design. My problem is that the requirements are being published long after the design and the current design is not capable of meeting those requirements. I have repeatedly explained why it is simply not possible to guarantee convergence using the "timestamps" approach in the current architecture in the face of real world situations where DSAs have clocks that are not only unsynchronized but can even jump backwards due to time zone mistakes etc and where they crash and get later restored from backups. This has been dismissed as a "religious" issue despite references to the extensive research done on the subject for the Coda file system project and the commercial deployment of replication protocols that do guarantee eventual convergence in Active Directory. Since no work has actually been done to fix the problem, my concern is that if model 3 is listed as just as much a "MUST" requirement as model 2, LDUP could resort to "incremental" delivery and proudly unleash on the world a broken protocol that guarantees "eventual divergence", while deferring for "subsequent work" anything actually useful. The "eventual divergence" in the current architecture does not provide any of the scalability requirements that do motivate model 3. It is simply broken and must be fixed. Adding another MUST in parallel may not be intended to weaken the force of the first MUST, but it can nevertheless have that effect. CHRIS> The WG has achieved concensus on the use of "timestamps" in a way that you do not agree is best. That still means that the WG has achieved concensus. I am skeptical that John and I would allow an incremental delivery of the nature that you seem to be concerned about. You seem to be expressing doubt about that, but we are the Co-Chairs, you are not, and one or both Co-Chairs can be replaced by the Applications Area Co-ADs if allow something really screwy to happen. Also, it *is* possible to revise or update an RFC once published, so that even if we were to publish any WG document as an RFC and WG consensus were to change to be consistent with your point of view, we could do it. A need to fix an alleged problem with the design should not and will not result in John and I deciding to hold up the requirements document from going through a WG Last Call. [Richard] 3. Atomicity issues. We've discussed some of the problems with atomicity in multi-master environments in Appendix B.5. What specific issues do you have with this? Do you see a way to make atomicity "work" in these cases? Also, I would note that two of the authors of the revised draft (Ryan Moats and I) have quite a lot of experience in using directories for service provider applications, so user experience is not being ignored. [Albert] I have published a draft demonstrating that atomicity can be made to work. Atomicity *requires* that only one conflicting change be eventually successful. Essentially the only way that can work in a multi-master situation is by revoking some changes. B.5.1 and 5.2 accept that reality for create and rename conflicts but inexplicably does not consider that approach for other kinds of conflicts. I have shown it can be done without administrative intervention, which may be tolerable for create and rename conflicts but certainly not for more frequent conflicts. On the second sentence, I do not believe the experience of the authors is ever a useful substitute for actively making a "Request For Comment" from users likely to be affected by a problematic issue. The latest draft is a vast improvement on the previous in at least mentioning potential problems. However it does not actively seek user input because it seeks to minimize the problems and/or present them as unavoidable. Instead it should give clear examples of how existing and essential applications would actually be affected. CHRIS> I want some time to think about the first paragraph and related text below. CHRIS> What I am prepared to say about the 2nd paragraph, is that I believe you are mincing words for sport. I have no tolerance for that sort of behavior as a WG Co-Chair. It simply wastes time and creates a hostile and unproductive WG environment. Rick stated that the concerns of users are not being ignored due to his experience. I firmly believe that user concerns are being adequately addressed *because* Rick is one of the co-authors of the requirements document as Rick's experience is both historical and *current*. While working with Rick in the past, I have observed a level of concern over how end users will be affected by technical decisions that is quite admirable - and Rick also follows through by actually making technical decisions with user needs in mind. I also think that you are stretching the practical or real-world use of an RFC. It is true that the acronym expands to "Request for Comment." However, the real-world way of using an RFC is as a reference, a common source of stable requirements for building implementations, and as a snap-shot in time of a set of concepts that will hopefully *become* standardized at some point in the future. RFCs can and have been recycled at the same level to address significant issues that should prevent their progression to the next level towards becoming a full standard. We'll do that if we have to. User input has been collected through the WG Members and Document Editors and taken into consideration since before the WG was even chartered. You may have a different perspective on user experience concerns than Rick does, but that difference does not equate to user experience being ignored or even glossed over. CHRIS>Since what you write below is relevant to the paragraph I need to think about a bit more, I'll defer my response to it for another day or so. CHRIS>However, we will be proceeding with a WG Last Call of the requirements document. It may be that we have to discuss this issue during the WG Last Call period. CHRIS>Final comment on this e-mail is below under item 4. Instead of saying: "The common characteristics of the examples are: . Several directory users/applications are changing the same data . They are changing the data at the same time . They are using different directory servers to make these changes . They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences." The draft should instead say: *** If two users update Access Control Information from clients accessing different servers the eventual result may differ unpredictably from that intended by either of them. Even if the result does converge to the result intended by one of them, in the simplest possible case, with changes to just 2 attributes, up to 6 separate intermediate states may be used to determine access controls actually applied to the entry at various servers during the course of replication while convergence is achieved. Changes to larger numbers of attributes result in a combinatorial explosion of possible intermediate states. Access granted or denied to entries is essentially unpredictable during the course of a replication update, which may extend over hours or days. There may be useful applications for a directory service that does not support access control information. Users expecting a directory with predictable access control should be aware of the consequences of using LDUP standards for multi-master replication. The following excerpt provides some details from Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc *** 3.1 Latest Known Wins Consistency The "Latest Known Wins" approach has the outcome that all attributes will "eventually" reach the latest value entered into the system. During the "eventuality" being reached, intermediate states reflecting a combination of states which have existed over time may be held by an individual DSA. These intermediate states are best described using an example. Two operations, T1 at time 1 and T2 at time 2, occur on an entry updating attributes A and B. This may be viewed as follows : T0 T1 T2 A0 A1 A2 B0 B1 B2 "Latest Known Wins" consistency has the semantics that all directories will eventually have the state A2, B2 (providing no further operations in the distributed system affect attributes A and B). However, at times between either update occurring and this "eventuality", the directory state may be any combination of the individual states of A and B depending on the primitives currently received and processed by each DSA. That is, any of the following states may exist : * A0, B0 (Neither Operation has yet occurred) * A0, B1 (Partial completion of Operation 1) * A0, B2 (Partial completion of Operation 2) * A1, B0 (Partial completion of Operation 1) * A1, B1 (Operation 1 has occurred) * A1, B2 (Operation 1 completed, Partial completion of Operation 2) * A2, B0 (Partial completion of Operation 2) * A2, B1 (Operation 1 completed, Partial completion of Operation 2) * A2, B2 (Operation 2 has occurred) *** I'll try to prepare a detailed response on specific issues in B.5 for a separate message. In case I don't get time, perhaps the above will at least provide food for thought. [Richard] 4. The subentry draft may add new replication needs. True. But any new LDAP feature may add replication needs. We can't wait for every possible feature to make sure that we have covered them all. The right thing to do here is to ask the author of the subentry draft to include a section on replication issues rather than holding up the requirements draft. [Albert] We should not be adding new features at all. Replication of administrative information is a necessity for a viable directory service. That requirement has been overlooked and should be stated. Subentries are not a "feature" but a mechanism. In the course of considering how that mechanism is used to achieve requirements for replication of information about replication it has suddenly been realised that requirements for replication of other kinds of administrative information are a good deal more complex than previously supposed. What is happening is not that someone has come up with a proposed new feature, but that the penny has started to drop about certain aspects of a global distributed directory that were not clear before, but have to be dealt with when you go beyond an "Access" Protocol and start getting into "Service" protocols such as replication. CHRIS>I'm going to make the decision on this here and now. CHRIS>Authors of ALL other WG documents MUST include a section on replication issues that documents concerns, requirements, etc. which we may not understand well enough or even be aware of at this point in time. This section MUST be present with an indication of non-applicability if no specific replication issues are known at the time a particular document is written. We can revise requirements document after it becomes an RFC to include any requirements from these document sections if necessary later on and before those documents become published those sections would be replaced with a statement referencing the revised/updated requirements document. CHRIS> Albert: if you have an issue with this decision, please take it up directly with John Strassner, myself, and the Applications Area ADs. It is not necessary or productive to involve the entire WG in a discussion related to this as it is largely a matter of process. I won't discuss this with you further on the mailing list for the WG and respectfully ask that no other WG Member does either unless the Co-ADs decide that it is appropriate and ask me directly to open up this topic for discussion again. CHRIS> This issue is now resolved and Document Editors have guidelines for how we will document replication requirements that are unknown or unclear at this time. ------=_NextPart_000_00A1_01C04FED.ACC48E60 Content-Type: text/x-vcard; name="Chris Apple.vcf" Content-Disposition: attachment; filename="Chris Apple.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple NICKNAME:capple ORG:eCal Corporation TEL;WORK;VOICE:215-627-5001, ext. 3839 TEL;CELL;VOICE:(267) 977-8333 TEL;WORK;FAX:215-627-0927 ADR;WORK:;;510 Walnut Street;Philadelphia;PA;19106;US LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:510 Walnut = Street=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUS URL: URL:http://www.ecal.com EMAIL;PREF;INTERNET:capple@ecal.com REV:20000725T173628Z END:VCARD ------=_NextPart_000_00A1_01C04FED.ACC48E60-- From owner-ietf-ldup@mail.imc.org Thu Nov 16 18:49:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16892 for ; Thu, 16 Nov 2000 18:49:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14567 for ietf-ldup-bks; Thu, 16 Nov 2000 14:50:19 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14563 for ; Thu, 16 Nov 2000 14:50:18 -0800 (PST) Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA00302; Thu, 16 Nov 2000 14:57:16 -0800 (PST) Received: from [10.19.254.54] ([10.19.254.54]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA25729; Thu, 16 Nov 2000 16:57:08 -0600 (CST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 16 Nov 2000 14:48:58 -0800 To: capple@ecal.com (Christopher Apple), , "'Richard V Huber'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: New version of draft-ietf-ldup-replica-req Cc: , , , , , , Ned Freed Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 16.52 -0500 00-11-16, Christopher Apple wrote: >This issue is now resolved and Document Editors have guidelines for >how we will document replication requirements that are unknown or unclear >at this time. I don't know if you expected any response from me as AD, but I just want to mention that (a) I have read all comments, and don't see any reason why I should interfere with the process internal to the wg which I think the wg chairs are handling the correct way (b) wg chairs are the ones which declare when the wg has consensus on a document, and they request an IETF wide last call (c) comments that come in during IETF wide last call create the foundation for the decision which IESG will make regarding status of the requested RFC (d) every decision made by wg chairs, AD's, IESG etc can be appealed by contacting, as Chris explains, basically the level above the one which you felt made the wrong decision (e) rough consensus doesn't mean 100% of the people on the wg mailing list have to agree (then read bullet (b) again) Patrik Faltstrom Co-Area Director, Applications Area IETF From owner-ietf-ldup@mail.imc.org Fri Nov 24 17:55:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17894 for ; Fri, 24 Nov 2000 17:55:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18903 for ietf-ldup-bks; Fri, 24 Nov 2000 14:12:22 -0800 (PST) Received: from reed.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA18899 for ; Fri, 24 Nov 2000 14:12:21 -0800 (PST) Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Fri, 24 Nov 2000 15:13:26 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 24 Nov 2000 15:13:08 -0700 From: "Ed Reed" To: Subject: Fwd: Re: draft-ietf-ldup-subentry-06.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_B2E99B16.7F1E72A0" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_B2E99B16.7F1E72A0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry - I blew it. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_B2E99B16.7F1E72A0 Content-Type: message/rfc822 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by reed.oncalldba.com; Fri, 24 Nov 2000 15:10:29 -0700 Received: by ietf.org (8.9.1a/8.9.1a) id RAA08869; Fri, 24 Nov 2000 17:10:27 -0500 (EST) Date: Fri, 24 Nov 2000 17:10:27 -0500 (EST) Message-Id: <200011242210.RAA08869@ietf.org> To: eer@OnCallDBA.COM Subject: Re: draft-ietf-ldup-subentry-06.txt References: In-Reply-To: X-URL: http://www.ietf.org/ Subject: Autoreply from Internet Draft Submission Manager From: ietfauto@ietf.org (Internet Draft Submission Manager) MIME-Version: 1.0 Greetings, We are sorry, but the cut-off for Internet-Draft submissions was Friday, November 24, 2000 at 5pm ET. Your submission will not be retained (i.e. you need to resubmit) after December 10. Any submissions received prior to December 11, 2000 will not be retained; they must be resubmitted. Internet-Draft submissions received on or after December 11 will be processed. However, Internet-Draft announcements will not be sent until after the meeting concludes. If you receive this announcement, your submission will NOT be processed. Thank you for your understanding. IETF Secretariat --=_B2E99B16.7F1E72A0-- From owner-ietf-ldup@mail.imc.org Fri Nov 24 18:21:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24813 for ; Fri, 24 Nov 2000 18:21:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA18844 for ietf-ldup-bks; Fri, 24 Nov 2000 14:09:37 -0800 (PST) Received: from reed.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA18835 for ; Fri, 24 Nov 2000 14:09:28 -0800 (PST) Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Fri, 24 Nov 2000 15:10:13 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 24 Nov 2000 15:10:05 -0700 From: "Ed Reed" To: Cc: , Subject: draft-ietf-ldup-subentry-06.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_FEA5D755.63026EBC" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_FEA5D755.63026EBC Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached revised internet draft - draft-ietf-ldup-subent= ry-06.txt Abstract: This document describes two object classes called=20 ldapSubEntry and inheritableLDAPSubEntry which MAY be used=20 to indicate operations and management related entries in=20 the directory, called LDAP Subentries. To control the=20 visibility of entries of type ldapSubEntry, a control,=20 ldapSubentriesControl, is defined, and a special case using=20 Search filters is described. Scope rules are defined along=20 with rules for dealing with inheritance of subentry policy.=20 To the work group: 1) sorry this arrives to you in base64 encoding...if it does (hi, Rick!) 2) I've significantly revised this document to include the scope discussion= requested, and to provide an example scope extension for inheritance and inheritance blocking. =20 It needs your review before going to last call. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_FEA5D755.63026EBC Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-06.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQNCmRyYWZ0LWlldGYtbGR1cC1zdWJlbnRyeS0wNi50 eHQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RWQgUmVlZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWVkLU1h dHRoZXdzLCBJbmMuIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjQsIDIwMDAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCkxEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQoNCjEuIFN0 YXR1cyBvZiB0aGlzIE1lbW8gDQoNClRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQg YW5kIGlzIGluIGZ1bGwgDQpjb25mb3JtYW5jZSB3aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rp b24gMTAgb2YgUkZDMjAyNi4gDQogDQpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCANCkVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMg YXJlYXMsIGFuZCBpdHMgd29ya2luZyANCmdyb3Vwcy4gTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgDQpkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz LiAgDQogDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIA0Kc2l4IG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgDQpvdGhlciBkb2N1bWVudHMgYXQgYW55IHRpbWUuIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIA0KSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0 byBjaXRlIHRoZW0gb3RoZXIgDQp0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgIA0KIA0KVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiAgDQogDQpUaGUgbGlzdCBv ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIA0KYWNjZXNzZWQgYXQg aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogDQpUaGlzIEludGVybmV0LURyYWZ0 IGV4cGlyZXMgb24gTWF5IDI0LCAyMDAxLiANCg0KDQoyLiBBYnN0cmFjdCAvIERlc2NyaXB0aW9u IA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0d28gb2JqZWN0IGNsYXNzZXMgY2FsbGVkIA0K bGRhcFN1YkVudHJ5IGFuZCBpbmhlcml0YWJsZUxEQVBTdWJFbnRyeSB3aGljaCBNQVkgYmUgdXNl ZCANCnRvIGluZGljYXRlIG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQgcmVsYXRlZCBlbnRyaWVz IGluIA0KdGhlIGRpcmVjdG9yeSwgY2FsbGVkIExEQVAgU3ViZW50cmllcy4gIFRvIGNvbnRyb2wg dGhlIA0KdmlzaWJpbGl0eSBvZiBlbnRyaWVzIG9mIHR5cGUgbGRhcFN1YkVudHJ5LCBhIGNvbnRy b2wsIA0KbGRhcFN1YmVudHJpZXNDb250cm9sLCBpcyBkZWZpbmVkLCBhbmQgYSBzcGVjaWFsIGNh c2UgdXNpbmcgDQpTZWFyY2ggZmlsdGVycyBpcyBkZXNjcmliZWQuICBTY29wZSBydWxlcyBhcmUg ZGVmaW5lZCBhbG9uZyANCndpdGggcnVsZXMgZm9yIGRlYWxpbmcgd2l0aCBpbmhlcml0YW5jZSBv ZiBzdWJlbnRyeSBwb2xpY3kuIA0KDQpUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwg IlJFUVVJUkVEIiwgIlNIQUxMIiwgDQoiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIA0KYW5kICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIA0KDQoNClJlZWQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0KICAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIE1heSAyNCwgMjAwMSANDA0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAyNCBOb3ZlbWJlciAyMDAwIA0KICAgICAgICAgICAgICAgICAgIExE QVAgU3ViZW50cnkgU2NoZW1hIA0KDQpkZXNjcmliZWQgaW4gW1JGQzIxMTldLiBUaGUgc2VjdGlv bnMgYmVsb3cgcmVpdGVyYXRlIHRoZXNlIA0KZGVmaW5pdGlvbnMgYW5kIGluY2x1ZGUgc29tZSBh ZGRpdGlvbmFsIG9uZXMuIA0KDQoNCg0KMy4gVGFibGUgb2YgQ29udGVudHMgDQoNCjEuIFN0YXR1 cyBvZiB0aGlzIE1lbW8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MSANCjIuIEFic3RyYWN0IC8gRGVzY3JpcHRpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMSANCjMuIFRhYmxlIG9mIENvbnRlbnRzICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMiANCjQuIE9iamVjdCBDbGFzcyBEZWZpbml0aW9ucyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMyANCjQuMSAgbGRhcFN1YkVudHJ5 IENsYXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMyANCjQuMS4x ICAgICBTY29wZSBSdWxlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMyANCjQuMiAgSW5oZXJpdGFibGVMREFQU3ViZW50cnkgQ2xhc3MgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgNCANCjQuMi4xICAgICBJbGx1c3RyYXRpb24gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgNSANCjUuIEF0dHJpYnV0ZSBEZWZpbml0aW9ucyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNiANCjUuMSAgaW5oZXJpdGFi bGUgQXR0cmlidXRlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNiANCjUu MiAgYmxvY2tJbmhlcml0YW5jZSBBdHRyaWJ1dGUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgNiANCjYuIFZpc2liaWxpdHkgQ29udHJvbHMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgNyANCjYuMSAgbGRhcFN1YmVudHJpZXNDb250cm9sICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNyANCjYuMS4xICAgICBMREFQIFNlYXJjaCB3 aXRoIHNjb3BlIG90aGVyIHRoYW4gYmFzZU9iamVjdCAgICAgICAgICAgNyANCjYuMS4yICAgICBM REFQIFNlYXJjaCB3aXRoIHNjb3BlIG9mIGJhc2VPYmplY3QgICAgICAgICAgICAgICAgICAgOCAN CjYuMS4zICAgICBPdGhlciBMREFQIG9wZXJhdGlvbnMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgOCANCjYuMS40ICAgICBDb3JyZXNwb25kZW5jZSB0byBYLjUwMCBbWC41MTFdICAg ICAgICAgICAgICAgICAgICAgICAgOCANCjYuMiAgU2VhcmNoIEZpbHRlciBWaXNpYmlsaXR5ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOSANCjcuIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOSANCjguIFJlZmVy ZW5jZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MTAgDQo5LiBDb3B5cmlnaHQgTm90aWNlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDEwIA0KMTAuIA0gICBBY2tub3dsZWRnZW1lbnRzICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDExIA0KMTEuIA0gICBBdXRob3IncyBBZGRy ZXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDExIA0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSZWVkICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXSANCiAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBNYXkgMjQsIDIwMDEgDQogDQwNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMjQgTm92ZW1iZXIgMjAwMCANCiAgICAgICAgICAgICAgICAg ICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KIA0KIA0KDQoNCjQuIE9iamVjdCBDbGFzcyBEZWZp bml0aW9ucyANCg0KDQo0LjEgbGRhcFN1YkVudHJ5IENsYXNzIA0KDQooIDIuMTYuODQwLjEuMTEz NzE5LjIuMTQyLjYuMS4xIE5BTUUgJ2xkYXBTdWJFbnRyeScgIA0KICAgREVTQyAnTERBUCBTdWJl bnRyeSBjbGFzcywgdmVyc2lvbiAxJyAgDQogICAgIFNVUCB0b3AgU1RSVUNUVVJBTCAgDQogICAg IE1BWSAoIGNuICkgKSAgDQoNClRoZSBjbGFzcyBsZGFwU3ViRW50cnkgaXMgaW50ZW5kZWQgdG8g YmUgdXNlZCBhcyBhIHN1cGVyLSANCmNsYXNzIHdoZW4gZGVmaW5pbmcgb3RoZXIgc3RydWN0dXJh bCBjbGFzc2VzIHRvIGJlIHVzZWQgDQphcyBMREFQIFN1YmVudHJpZXMsIGFuZCBhcyB0aGUgc3Ry dWN0dXJhbCBjbGFzcyB0byB3aGljaCANCkF1eGlsaWFyeSBjbGFzc2VzIG1heSBiZSBhZGRlZCBm b3IgYXBwbGljYXRpb24gc3BlY2lmaWMgDQpzdWJlbnRyeSBpbmZvcm1hdGlvbi4gIFdoZXJlIHBv c3NpYmxlLCB0aGUgdXNlIG9mIEF1eGlsaWFyeSANCmNsYXNzZXMgdG8gZXh0ZW5kIExEQVAgU3Vi ZW50cmllcyBpcyBzdHJvbmdseSBwcmVmZXJyZWQuIA0KIA0KVGhlIHByZXNlbmNlIG9mIGxkYXBT dWJFbnRyeSBpbiB0aGUgbGlzdCBvZiBzdXBlci1jbGFzc2VzIA0Kb2YgYW4gZW50cnkgaW4gdGhl IGRpcmVjdG9yeSBtYWtlcyB0aGF0IGVudHJ5IGFuIExEQVAgDQpTdWJlbnRyeS4gIE9iamVjdCBj bGFzc2VzIGRlcml2ZWQgZnJvbSBsZGFwU3ViRW50cnkgYXJlIA0KdGhlbXNlbHZlcyBjb25zaWRl cmVkIGxkYXBTdWJFbnRyeSBjbGFzc2VzLCBmb3IgdGhlIHB1cnBvc2UgDQpvZiB0aGlzIGRpc2N1 c3Npb24uIA0KDQpMREFQIFN1YmVudHJpZXMgTUFZIGJlIG5hbWVkIGJ5IHRoZWlyIGNvbW1vbk5h bWUgYXR0cmlidXRlIA0KW1JGQzIyNTFdLiAgT3RoZXIgbmFtaW5nIGF0dHJpYnV0ZXMgYXJlIGFs c28gcGVybWl0dGVkLiANCg0KTERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZXJzLCB1bmxp a2UgdGhlaXIgW1guNTAxXSANCmNvdW50ZXJwYXJ0cy4gDQoNCkxEQVAgU3ViZW50cmllcyBNQVkg YmUgY29udGFpbmVkIGJ5LCBhbmQgd2lsbCB1c3VhbGx5IGJlIA0KbG9jYXRlZCBpbiB0aGUgZGly ZWN0b3J5IGluZm9ybWF0aW9uIHRyZWUgaW1tZWRpYXRlbHkgDQpzdWJvcmRpbmF0ZSB0bywgYWRt aW5pc3RyYXRpdmUgcG9pbnRzLiAgRnVydGhlciAodW5saWtlIA0KWC41MDAgc3ViZW50cmllcyks IExEQVAgU3ViZW50cmllcyBNQVkgYmUgY29udGFpbmVkIGJ5IA0Kb3RoZXIgTERBUCBTdWJlbnRy aWVzICh0aGUgd2F5IG9yZ2FuaXphdGlvbmFsIHVuaXRzIG1heSBiZSANCmNvbnRhaW5lZCBieSBv dGhlciBvcmdhbml6YXRpb25hbCB1bml0cykuICBEZWVwIG5lc3Rpbmcgb2YgDQpMREFQIFN1YmVu dHJpZXMgYXJlIGRpc2NvdXJhZ2VkLCBidXQgbm90IHByb2hpYml0ZWQuIA0KDQoNCjQuMS4xIFNj b3BlIFJ1bGVzIA0KDQpUaGUgZGVmYXVsdCBzY29wZSBvZiBhbiBMREFQIFN1YmVudHJ5IGlzIGxp bWl0ZWQgdG8gdGhlIA0KYWRtaW5pc3RyYXRpdmUgYXJlYSBpbiB3aGljaCBpdCBpcyBkZWZpbmVk LiAgU3BlY2lmaWNhbGx5LCANCnRoZSBzdWJ0cmVlIG9mIHRoZSBkaXJlY3RvcnkgbmFtZXNwYWNl IGJhc2VkIGF0IHRoZSANCmFkbWluaXN0cmF0aXZlIHBvaW50IG1vc3QgaW1tZWRpYXRlbHkgc3Vw ZXJpb3IgdG8gdGhlIExEQVAgDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDNdIA0KICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1h eSAyNCwgMjAwMSANCiANDA0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAyNCBOb3ZlbWJlciAyMDAwIA0KICAgICAgICAgICAgICAgICAgIExEQVAgU3ViZW50 cnkgU2NoZW1hIA0KDQpTdWJlbnRyeSwgZG93biB0byBidXQgbm90IGluY2x1ZGluZyBhbnkgc3Vi b3JkaW5hdGUgDQphZG1pbmlzdHJhdGl2ZSBwb2ludHMgb3IgYXJlYXMuICBQb2xpY3kgZGVmaW5l ZCBpbiBhbiBMREFQIA0KU3ViZW50cnkgaXMgbm90IGluaGVyaXRhYmxlLCB1bmxlc3Mgc3VjaCBp bmhlcml0YW5jZSBpcyANCmV4cGxpY2l0bHkgZGVmaW5lZCAoc2VlIHRoZSBvYmplY3QgY2xhc3Mg ZGVmaW5pdGlvbiBmb3IgDQpJbmhlcml0YWJsZUxEQVBTdWJlbnRyeSwgYmVsb3csIGZvciBzdWNo IGFuIGV4YW1wbGUpLiANCg0KSWYgYW4gTERBUCBTdWJlbnRyeSBpcyBzdWJvcmRpbmF0ZSB0byBh bm90aGVyIExEQVAgDQpTdWJlbnRyeSwgaXQgdGFrZXMgdGhlIHNhbWUgc2NvcGUgYXMgdGhlIHBh cmVudCBMREFQIA0KU3ViZW50cnkuIA0KDQpBcHBsaWNhdGlvbnMgTUFZIGRlZmluZSBhbHRlcm5h dGl2ZSBzY29wZSBzZW1hbnRpY3MgZm9yIA0KY2xhc3NlcyB0aGV5IGRlZmluZSB3aGljaCBhcmUg ZGVyaXZlZCBmcm9tIHRoZSBsZGFwU3ViRW50cnkgDQpjbGFzcy4gVGhpcyBtZWFucyB0aGF0IGFu IGFwcGxpY2F0aW9uIGNhbiBkZXJpdmUgYSBuZXcgDQpjbGFzcyBmcm9tIHRoZSBsZGFwU3ViRW50 cnkgY2xhc3MgYW5kIGFkZCBhbiBhdHRyaWJ1dGUsIA0KbGlrZSBzdWJ0cmVlU3BlY2lmaWNhdGlv biBbWC41MDFdIG9yIGluaGVyaXRhbmNlIGNvbnRyb2xzIA0KKHNlZSBiZWxvdyksIHRvIGRlZmlu ZSBhIG5ldyBzY29wZSBydWxlIGZvciB0aGF0IA0KYXBwbGljYXRpb24gdG8gdXNlLiANCg0KQXBw bGljYXRpb25zIE1VU1QgTk9UIGRlZmluZSBhbHRlcm5hdGl2ZSBzY29wZSBydWxlcyBmb3IgDQph dXhpbGlhcnkgY2xhc3NlcyB1c2VkIHRvIGRlY29yYXRlIGVudHJpZXMgb2YgdGhlIA0KbGRhcFN1 YkVudHJ5IGNsYXNzLiAgVGhpcyByZXN0cmljdGlvbiBpcyByZXF1aXJlZCB0byBhdm9pZCANCmhh dmluZyBjb25mbGljdGluZyBvciBjb250cmFkaWN0b3J5IHNjb3BlIGRlZmluaXRpb25zIA0KYXBw bGllZCBieSBkaWZmZXJlbnQgYXBwbGljYXRpb25zIHRvIHRoZSBzYW1lIExEQVAgDQpTdWJlbnRy eS4gDQoNCg0KNC4yIEluaGVyaXRhYmxlTERBUFN1YmVudHJ5IENsYXNzIA0KDQooIDEuMy42LjEu NC4xLjc2MjguNS42LjEuMSBOQU1FICdpbmhlcml0YWJsZUxEQVBTdWJFbnRyeScgIA0KICAgREVT QyAnSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSBjbGFzcywgdmVyc2lvbiAxJyAgDQogICBTVVAg bGRhcFN1YkVudHJ5IFNUUlVDVFVSQUwgIA0KICAgTVVTVCAoIGluaGVyaXRhYmxlICkgIA0KICAg TUFZICAoIGJsb2NrSW5oZXJpdGFuY2UgKSANCg0KVGhlIEluaGVyaXRhYmxlTERBUFN1YmVudHJ5 IGNsYXNzIGlzIGRlcml2ZWQgZnJvbSB0aGUgDQpsZGFwU3ViRW50cnkgY2xhc3MgYW5kIHByb3Zp ZGVzIG1vZGlmaWVkIHNjb3BlIHNlbWFudGljcyB0byANCnBlcm1pdCBhbmQgY29udHJvbCBpbmhl cml0YW5jZSBmcm9tIG9uZSBhZG1pbmlzdHJhdGl2ZSBhcmVhIA0KdG8gb25lIG9yIG1vcmUgc3Vi b3JkaW5hdGUgYWRtaW5pc3RyYXRpdmUgYXJlYXMuIA0KDQpJZiB0aGUgJ2luaGVyaXRhYmxlJyBh dHRyaWJ1dGUgaXMgVFJVRSAoMSksIHRoZW4gdGhlIHBvbGljeSANCmluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGUgSW5oZXJpdGFibGVMREFQU3ViZW50cnkgaXMgDQppbnRlbmRlZCB0byBleHRl bmQgaW50byBhbnkgc3Vib3JkaW5hdGUgYWRtaW5pc3RyYXRpdmUgDQphcmVhcy4gIFN1Ym9yZGlu YXRlIGFkbWluaXN0cmF0aXZlIGFyZWFzIFNIT1VMRCBpbmNsdWRlIA0KSW5oZXJpdGFibGUgTERB UCBTdWJlbnRyaWVzIGZyb20gdGhlaXIgaW1tZWRpYXRlbHkgc3VwZXJpb3IgDQphZG1pbmlzdHJh dGl2ZSBhcmVhICh1bmxlc3MgYmxvY2tlZCwgc2VlIGJlbG93KS4gDQoNCklmIHRoZSAnaW5oZXJp dGFibGUnIGF0dHJpYnV0ZSBpcyBGQUxTRSAoMCksIHRoZSBwb2xpY3kgaXMgDQpOT1QgaW5oZXJp dGFibGUsIGFuZCBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhcyBNVVNUIA0KDQpSZWVk ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA0XSAN CiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjQsIDIwMDEgDQogDQwNCg0KDQpJTlRF Uk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjQgTm92ZW1iZXIgMjAwMCAN CiAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KdHJlYXQgdGhlIGFz c29jaWF0ZWQgcG9saWN5IGluZm9ybWF0aW9uIGFzIFVOREVGSU5FRCB1bmxlc3MgDQpleHBsaWNp dGx5IGRlZmluZWQgd2l0aGluIHRoZWlyIG93biBhZG1pbmlzdHJhdGl2ZSBhcmVhLiANCg0KSWYg YSBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhIGRlZmluZXMgYW4gSW5oZXJpdGFibGUg DQpMREFQIFN1YmVudHJ5IGZvciBhbiBhcHBsaWNhdGlvbiB3aXRoIHRoZSBzYW1lIG5hbWUgYXMg b25lIA0KZGVmaW5lZCBpbiB0aGUgc3VwZXJpb3IgYWRtaW5pc3RyYXRpdmUgYXJlYSwgYW5kIGlm IHRoZSANCnN1Ym9yZGluYXRlJ3MgSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSBoYXMgdGhlIGF0 dHJpYnV0ZSANCidibG9ja0luaGVyaXRhbmNlJyB3aXRoIHRoZSB2YWx1ZSBUUlVFLCB0aGVuIGlu aGVyaXRhbmNlIGlzIA0KYmxvY2tlZCBmcm9tIHRoZSBzdXBlcmlvciBhZG1pbmlzdHJhdGl2ZSBh cmVhIHRvIHRoYXQgDQpzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhLCBhbmQgdGhlIGVm ZmVjdCBpcyB0aGUgc2FtZSANCmFzIGlmIHRoZSBzdXBlcmlvciBJbmhlcml0YWJsZSBMREFQIFN1 YmVudHJ5IGNvbnRhaW5lZCB0aGUgDQonaW5oZXJpdGFibGUnIGF0dHJpYnV0ZSBzZXQgdG8gRkFM U0UuIA0KDQpUaGUgdmFsdWUgb2YgdGhlICdibG9ja0luaGVyaXRhbmNlJyBhdHRyaWJ1dGUgaW4g YSBzdXBlcmlvciANCmFkbWluaXN0cmF0aXZlIGFyZWEgSW5oZXJpdGFibGUgTERBUCBTdWJlbnRy eSBpcyBpcnJlbGV2YW50IA0KdG8gYSBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhIGZv ciB0aGlzIG9iamVjdCBjbGFzcy4gICANCg0KTm8gbWVjaGFuaXNtIGlzIGRlZmluZWQgYXQgdGhp cyB0aW1lIHRvIHNpZ25hbCB0byANCnN1Ym9yZGluYXRlIGFkbWluaXN0cmF0aXZlIGFyZWFzIHRo YXQgdGhleSBtYXkgbm90IGJsb2NrIA0KaW5oZXJpdGFibGUgcG9saWN5IGZyb20gc3VwZXJpb3Ig YWRtaW5pc3RyYXRpdmUgYXJlYXMuIA0KDQoNCjQuMi4xIElsbHVzdHJhdGlvbiANCg0KQW4gaWxs dXN0cmF0aW9uIG1heSBoZWxwIGNsYXJpZnkgdGhlIHVzZSBvZiB0aGUgY2xhc3MgYW5kIA0KdGhl c2UgYXR0cmlidXRlcy4gDQoNClN1cHBvc2UgdGhlIGFkbWluaXN0cmF0aXZlIGFyZWEgYmFzZWQg YXQgJ2RjPWNvbScgaGFzIGFuIA0KSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSBmb3IgYW4gYXBw bGljYXRpb24gZGVmaW5lZCB3aXRoIA0KdGhlICdpbmhlcml0YWJsZScgYXR0cmlidXRlIHNldCB0 byBUUlVFLiAgU3Vib3JkaW5hdGUgDQphZG1pbmlzdHJhdGl2ZSBhcmVhcywgZm9yIGluc3RhbmNl ICdkYz13aWRnZXQsIGRjPWNvbScgDQptaWdodCBvciBtaWdodCBub3Qgd2FudCB0byBhY2NlcHQg dGhlIGluaGVyaXRlZCBwb2xpY3kgZnJvbSANCnRoZSAnZGM9Y29tJyBhZG1pbmlzdHJhdGl2ZSBh cmVhLiANCg0KSWYgdGhlIGFkbWluaXN0cmF0b3Igb2YgdGhlICdkYz13aWRnZXQsIGRjPWNvbScg DQphZG1pbmlzdHJhdGl2ZSBhcmVhIGNyZWF0ZXMgYW4gSW5oZXJpdGFibGUgTERBUCBTdWJlbnRy eSANCndpdGggdGhlIHNhbWUgcmVsYXRpdmUgZGlzdGluZ3Vpc2hlZCBuYW1lIGFzIHVzZWQgaW4g dGhlIA0KJ2RjPWNvbScgYWRtaW5pc3RyYXRpdmUgYXJlYSBzZXR0aW5nIHRoZSAnYmxvY2tJbmhl cml0YW5jZScgDQphdHRyaWJ1dGUgc2V0IHRvIFRSVUUsIHRoZW4gdGhlIGluaGVyaXRhbmNlIG9m IHRoaXMgcG9saWN5IA0KaXMgZWZmZWN0aXZlbHkgYmxvY2tlZCBmcm9tIGFmZmVjdGluZyB0aGUg J2RjPXdpZGdldCwgDQpkYz1jb20nIGFkbWluaXN0cmF0aXZlIGFyZWEuICBXZSdsbCBjYWxsIHRo aXMgYSBibG9ja2luZyANCnN1YmVudHJ5IGZvciBvdXIgZGlzY3Vzc2lvbiBoZXJlLiANCg0KSWYg dGhlIGFkbWluaXN0cmF0b3Igb2YgdGhlICdkYz13aWRnZXQsIGRjPWNvbScgDQphZG1pbmlzdHJh dGl2ZSBhcmVhIGNyZWF0ZXMgYSBibG9ja2luZyBzdWJlbnRyeSAoYXMgYWJvdmUpIA0Kd2l0aCBz b21lIGxvY2FsbHkgZGVmaW5lZCBwb2xpY3kgaW5mb3JtYXRpb24sIHRoYXQgcG9saWN5IA0KaW5m b3JtYXRpb24gZWZmZWN0aXZlbHkgcmVwbGFjZXMgdGhlIHBvbGljeSBpbmZvcm1hdGlvbiANCg0K DQpSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA1XSANCiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjQsIDIwMDEgDQogDQwNCg0K DQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjQgTm92ZW1iZXIg MjAwMCANCiAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KZGVmaW5l ZCBieSB0aGUgc3VwZXJpb3IgYWRtaW5pc3RyYXRpdmUgYXJlYS4gIFdlJ2xsIGNhbGwgDQp0aGlz IGFuIG92ZXItcmlkaW5nIHN1YmVudHJ5IGZvciBvdXIgZGlzY3Vzc2lvbiBoZXJlLiANCg0KQW4g b3Zlci1yaWRpbmcgc3ViZW50cnkgTUFZIGl0c2VsZiBiZSBpbmhlcml0YWJsZSwgaW4gd2hpY2gg DQpjYXNlIHRoZSAnaW5oZXJpdGFibGUnIGF0dHJpYnV0ZSBvbiB0aGUgbG9jYWxseSBkZWZpbmVk IA0KSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSBNQVkgYmUgc2V0IHRvIFRSVUUgb3IgRkFMU0Us IGF0IA0KdGhlIGRpc2NyZXRpb24gb2YgdGhlIGxvY2FsIGFkbWluaXN0cmF0aXZlIGF1dGhvcml0 eSwgd2l0aCANCmFwcHJvcHJpYXRlIGltcGxpY2F0aW9ucyBmb3IgaW5oZXJpdGFuY2Ugb2YgdGhl IG5ldywgDQpsb2NhbGx5IGRlZmluZWQgcG9saWN5LCBvbiBhbnkgb3RoZXIgc3Vib3JkaW5hdGUg DQphZG1pbmlzdHJhdGl2ZSBhcmVhcy4gIEluIHRoaXMgd2F5LCB0aGUgJ2RjPXdpZGdldCwgZGM9 Y29tJyANCmFkbWluaXN0cmF0b3IgY2FuIHNldCBpbmhlcml0YWJsZSBwb2xpY3kgZm9yIG9yZ2Fu aXphdGlvbmFsIA0KdW5pdHMgKGxpa2UgJ291PWVuZywgZGM9d2lkZ2V0LCBkYz1jb20nKSBmb3Ig YW4gYXBwbGljYXRpb24gDQp3aGlsZSBvdmVyLXJpZGluZyBpbmhlcml0YWJsZSBwb2xpY3kgZnJv bSB0aGUgc3VwZXJpb3IgDQonZGM9Y29tJyBhZG1pbmlzdHJhdGl2ZSBhcmVhLiANCg0KDQoNCjUu IEF0dHJpYnV0ZSBEZWZpbml0aW9ucyANCg0KDQo1LjEgaW5oZXJpdGFibGUgQXR0cmlidXRlIA0K DQooIDEuMy42LjEuNC4xLjc2MjguNS40LjEgTkFNRSAnaW5oZXJpdGFibGUnIA0KICAgU1lOVEFY IEJPT0xFQU4gDQogICBTSU5HTEUtVkFMVUUgTk8tVVNFUi1NT0RJRklDQVRJT04gVVNBR0UgZFNB T3BlcmF0aW9uICkgDQoNClVzZWQgdG8gc2lnbmFsIHdoZXRoZXIgYW4gaW5oZXJpdGFibGVMREFQ U3ViZW50cnkgaXMgDQppbnRlbmRlZCB0byBiZSBpbmhlcml0ZWQgYnkgc3Vib3JkaW5hdGUgYWRt aW5pc3RyYXRpdmUgDQphcmVhcywgb3Igbm90LiAgVFJVRSBpbmRpY2F0ZXMgdGhhdCB0aGUgc3Vi ZW50cnkgYW5kIHRoZSANCnBvbGljeSBpdCBjb250YWlucyBpcyBpbmhlcml0YWJsZS4gICANCg0K RkFMU0UgaW5kaWNhdGVzIHRoYXQgaXQgaXMgbm90LiANCg0KDQo1LjIgYmxvY2tJbmhlcml0YW5j ZSBBdHRyaWJ1dGUgDQoNCiggMS4zLjYuMS40LjEuNzYyOC41LjQuMiBOQU1FICdibG9ja0luaGVy aXRhbmNlJyANCiAgIFNZTlRBWCBCT09MRUFOIA0KICAgU0lOR0xFLVZBTFVFIE5PLVVTRVItTU9E SUZJQ0FUSU9OIFVTQUdFIGRTQU9wZXJhdGlvbiApIA0KDQpVc2VkIGJ5IGFkbWluaXN0cmF0b3Jz IG9mIHN1Ym9yZGluYXRlIGFkbWluaXN0cmF0aXZlIGFyZWFzIA0KdG8gb3Zlci1yaWRlLCBvciBi bG9jaywgdGhlIGluaGVyaXRhbmNlIG9mIA0KaW5oZXJpdGFibGVMREFQU3ViRW50cnkgcG9saWN5 IGZyb20gc3VwZXJpb3IgYWRtaW5pc3RyYXRpdmUgDQphcmVhcy4gICANCg0KQSB2YWx1ZSBvZiBU UlVFIGluZGljYXRlcyB0aGF0IGluaGVyaXRhbmNlIGlzIHRvIGJlIA0KYmxvY2tlZC4gICANCg0K DQpSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA2XSANCiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjQsIDIwMDEgDQogDQwNCg0K DQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjQgTm92ZW1iZXIg MjAwMCANCiAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KQSB2YWx1 ZSBvZiBGQUxTRSBpcyBpbXBsaWVzIHRoYXQgaW5oZXJpdGFuY2UgaXMgbm90IHRvIGJlIA0KYmxv Y2tlZCwgYnV0IHNwZWNpZmljIHNlbWFudGljIGludGVycHJldGF0aW9uIGlzIGxlZnQgdG8gDQph cHBsaWNhdGlvbnMgKHdobyBtYXkgc3BlY2lmeSBhbnkgb2YgYSB2YXJpZXR5IG9mIHBvbGljeSAN CmFnZ3JlZ2F0aW9uIG1lY2hhbmlzbXMgdG8gZGVmaW5lIGhvdyBpbmhlcml0ZWQgcG9saWN5IGlz IHRvIA0KYmUgbWl4ZWQgd2l0aCBsb2NhbGx5IGRlZmluZWQgcG9saWN5KS4gDQoNCg0KDQo2LiBW aXNpYmlsaXR5IENvbnRyb2xzIA0KDQoNCjYuMSBsZGFwU3ViZW50cmllc0NvbnRyb2wgDQoNClRo aXMgY29udHJvbCBpcyBpbmNsdWRlZCBpbiB0aGUgc2VhcmNoUmVxdWVzdCBtZXNzYWdlIGFzIA0K cGFydCBvZiB0aGUgY29udHJvbHMgZmllbGQgb2YgdGhlIExEQVBNZXNzYWdlLCBhcyBkZWZpbmVk IA0KaW4gU2VjdGlvbiA0LjEuMTIgb2YgW1JGQzIyNTFdLiANCg0KVGhlIGNvbnRyb2xUeXBlIGlz IHNldCB0byAiMS4zLjYuMS40LjEuNzYyOC41LjEwMS4xIi4gVGhlIA0KY3JpdGljYWxpdHkgTUFZ IGJlIHNldCB0byBlaXRoZXIgVFJVRSBvciBGQUxTRS4gIFRoZSANCmNvbnRyb2xWYWx1ZSBpcyBh YnNlbnQuICAgDQoNClRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgcmVzcG9uc2UgY29udHJvbCBk ZWZpbmVkLiANCg0KTERBUCBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCB0aGlzIGNvbnRyb2wgTVVTVCB0 cmVhdCBMREFQIA0KU3ViZW50cmllcyBhcyAib3BlcmF0aW9uYWwgb2JqZWN0cyIgaW4gbXVjaCB0 aGUgc2FtZSB3YXkgDQp0aGF0ICJvcGVyYXRpb25hbCBhdHRyaWJ1dGVzIiBhcmUgbm90IHJldHVy bmVkIGluIHNlYXJjaCANCnJlc3VsdHMgYW5kIFtYLjUxMV0gcmVhZCBvcGVyYXRpb25zIHdoZW4g b25seSB1c2VyIA0KYXR0cmlidXRlcyBhcmUgcmVxdWVzdGVkLiAgDQoNCkVudHJpZXMgd2hpY2gg YXJlIG5vdCBMREFQIFN1YmVudHJpZXMgbWF5IHN0aWxsIGJlIA0KcmVmZXJlbmNlZCBpbiB0aGUg YmFzZSBvYmplY3Qgb2Ygc2VhcmNoIG9wZXJhdGlvbnMgd2hlcmUgDQp0aGUgbGRhcFN1YmVudHJp ZXNDb250cm9sIGlzIHByZXNlbnQgaW4gdGhlIHJlcXVlc3QuICAgDQoNCg0KNi4xLjEgTERBUCBT ZWFyY2ggd2l0aCBzY29wZSBvdGhlciB0aGFuIGJhc2VPYmplY3QgDQoNClRoZSBsZGFwU3ViZW50 cmllc0NvbnRyb2wgaXMgZGVmaW5lZCBmb3IgTERBUCB0byBzaWduYWwgdG8gDQpMREFQIFNlYXJj aCBvcGVyYXRpb25zIHRoYXQgT05MWSBMREFQIFN1YmVudHJpZXMgYXJlIHRvIGJlIA0KaW5jbHVk ZWQgaW4gdGhlIHJldHVybiBzZXQgb2YgZW50cmllcyBmb3IgdGhlIFNlYXJjaCwgDQpwcm92aWRl ZCBvdGhlciBTZWFyY2ggY3JpdGVyaWEgKHN1Y2ggYXMgc2NvcGUgYW5kIGZpbHRlcikgDQphcmUg c2F0aXNmaWVkLiAgV2hlbiBsZGFwU3ViZW50cmllc0NvbnRyb2wgaXMgTk9UIGluY2x1ZGVkIA0K aW4gYSBTZWFyY2ggcmVxdWVzdCBvbiBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIHRoZSBjb250cm9s LCANCkxEQVAgU3ViZW50cmllcyBNVVNUIGJlIG9taXR0ZWQgZnJvbSB0aGUgcmV0dXJuIHNldCAo d2l0aCANCnRoZSBzaW5nbGUgZXhjZXB0aW9uIGRlc2NyaWJlZCBpbiBTZWFyY2ggRmlsdGVyIFZp c2liaWxpdHksIA0KYmVsb3cpLiANCg0KDQoNCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQogICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgTWF5IDI0LCAyMDAxIA0KIA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDI0IE5vdmVtYmVyIDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERB UCBTdWJlbnRyeSBTY2hlbWEgDQoNCjYuMS4yIExEQVAgU2VhcmNoIHdpdGggc2NvcGUgb2YgYmFz ZU9iamVjdCANCg0KRm9yIFNlYXJjaCBvcGVyYXRpb25zIHdpdGggYSBzY29wZSB2YWx1ZSBvZiBi YXNlT2JqZWN0LCB0aGUgDQpwcmVzZW5jZSBvciBhYnNlbmNlIG9mIHRoZSBsZGFwU3ViZW50cmll c0NvbnRyb2wgTVVTVCBiZSANCmlnbm9yZWQuICBTcGVjaWZpY2FsbHksIGJhc2VPYmplY3Qgc2Vh cmNoZXMgYXBwbGllZCB0byANCmxkYXBTdWJFbnRyeSBlbnRyaWVzIE1VU1QgYmUgZXZhbHVhdGVk IGJ5IFNlYXJjaCBhcyBpZiB0aGUgDQpsZGFwU3ViZW50cmllc0NvbnRyb2wgaXMgcHJlc2VudCwg ZXZlbiBpZiBpdCBpcyBhYnNlbnQuICANCg0KVGhpcyBwcm92aXNpb24gaXMgaW50ZW5kZWQgdG8g cHJlc2VydmUgdGhlIGJlaGF2aW9yIG9mIA0KW1guNTExXSBSZWFkIG9wZXJhdGlvbnMsIHdoaWNo IGFyZSBub3QgYWZmZWN0ZWQgYnkgdGhlIA0KW1guNTExXSBzdWJlbnRyaWVzIGNvbnRyb2wgKHNl ZSBDb3JyZXNwb25kZW5jZSB0byBYLjUwMCwgDQpiZWxvdyksIGFuZCBiZWNhdXNlIGl0IHdvdWxk IHNlZW0gc2lsbHkgdG8gYmVoYXZlIA0Kb3RoZXJ3aXNlLiANCg0KDQo2LjEuMyBPdGhlciBMREFQ IG9wZXJhdGlvbnMgDQoNClRoZSBsZGFwU3ViZW50cmllc0NvbnRyb2wgaXMgbm90IGRlZmluZWQg Zm9yIGFueSBMREFQIA0Kb3BlcmF0aW9uIG90aGVyIHRoYW4gU2VhcmNoLiAgSG93ZXZlciwgYW4g TERBUHYzIEV4dGVuc2lvbiANCk1BWSBkZWZpbmUgYSB1c2Ugb2YgdGhpcyBjb250cm9sIHdpdGgg dGhhdCBleHRlbnNpb24gYXMgDQpsb25nIGFzIHN1Y2ggdXNlIGlzIGNvbnNpc3RlbnQgd2l0aCB0 aGlzIHNwZWNpZmljYXRpb24uIA0KDQoNCjYuMS40IENvcnJlc3BvbmRlbmNlIHRvIFguNTAwIFtY LjUxMV0gDQoNCkluIFtYLjUxMV0gYSBTZXJ2aWNlQ29udHJvbCBvcHRpb24gaXMgdXNlZCB0byBn b3Zlcm4gdGhlIA0KdmlzaWJpbGl0eSBvZiBbWC41MDFdIHN1YmVudHJpZXMuICBUaGUgc3ViZW50 cnkgDQpTZXJ2aWNlQ29udHJvbCBvcHRpb24gaXMgYSBzcGVjaWZpYyBiaXQgb2YgYSBiaXRzdHJp bmcgDQp0aGF0LCB3aGVuIHNldCB0byBUUlVFIGluIHRoZSBjb21tb24gYXJndW1lbnRzIG9mIGFu IFguNTAwIA0KU2VhcmNoIG9yIExpc3Qgb3BlcmF0aW9uLCBpbmRpY2F0ZXMgdGhhdCB0aGUgb3Bl cmF0aW9uIGlzIA0KdG8gYWNjZXNzIE9OTFkgdGhlIHN1YmVudHJpZXMgZm91bmQgaW4gdGhlIGNv bnRleHQgb2YgdGhlIA0KbGlzdCBvciBzZWFyY2guICBJbiBmYWN0LCBub3JtYWwgZW50cmllcyBh cmUgZXhwbGljaXRseSBOT1QgDQpyZXR1cm5lZCBpbiB0aGUgcmVzdWx0IG9mIGEgbGlzdCBvciBz ZWFyY2ggb3BlcmF0aW9uIHdoZW4gDQp0aGUgWC41MDAgc3ViZW50cmllcyBTZXJ2aWNlQ29udHJv bCBpcyBzZXQuICAgDQoNCkVudHJpZXMgd2hpY2ggYXJlIG5vdCBzdWJlbnRyaWVzIG1heSBzdGls bCBiZSByZWZlcmVuY2VkIGluIA0KdGhlIGJhc2Ugb2JqZWN0IG9mIGxpc3QgYW5kIHNlYXJjaCBv cGVyYXRpb25zIHdoZXJlIHRoZSANCnN1YmVudHJpZXMgY29udHJvbCBpcyBzZXQuICAgDQoNClRo ZSBbWC41MTFdIHN1YmVudHJpZXMgU2VydmljZUNvbnRyb2wgaGFzIG5vIG1lYW5pbmcgZm9yIA0K b3BlcmF0aW9ucyBvdGhlciB0aGFuIFNlYXJjaCBhbmQgTGlzdCAoaS5lLiwgUmVhZCwgTW9kaWZ5 LCANCkRlbGV0ZSwgZXRjLikuIA0KDQpJbiBbWC41MDFdLCB0aGUgc2NvcGUgb2YgYSBzdWJlbnRy eSBpcyBhIHN1YnRyZWUgb3Igc3VidHJlZSANCnJlZmluZW1lbnQuICBUaGUgbGRhcFN1YkVudHJ5 IGNsYXNzIGRlZmluZWQgaW4gdGhpcyANCmRvY3VtZW50IHByb3ZpZGVzIG5vIG1lY2hhbmlzbSB0 byBkZWZpbmUgYSBzdWJ0cmVlIA0KcmVmaW5lbWVudC4gIA0KDQoNClJlZWQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdIA0KICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIE1heSAyNCwgMjAwMSANCiANDA0KDQoNCklOVEVSTkVULURSQUZUICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAyNCBOb3ZlbWJlciAyMDAwIA0KICAgICAgICAgICAg ICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQo2LjIgU2VhcmNoIEZpbHRlciBWaXNpYmls aXR5ICANCg0KTERBUCBzZXJ2ZXJzIE1VU1QgaW1wbGVtZW50IHRoZSBmb2xsb3dpbmcgc3BlY2lh bCBoYW5kbGluZyANCm9mIGxkYXBTdWJFbnRyeSBlbnRyaWVzOiBzZWFyY2ggb3BlcmF0aW9ucyB3 aGljaCBpbmNsdWRlIGEgDQpmaWx0ZXIgIm9iamVjdGNsYXNzPWxkYXBTdWJFbnRyeSIgTVVTVCBp bmNsdWRlIGVudHJpZXMgDQpkZXJpdmVkIGZyb20gdGhlIGxkYXBTdWJFbnRyeSBjbGFzcyBpbiB0 aGUgc2NvcGUgb2YgdGhlaXIgDQpvcGVyYXRpb25zLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhl IGxkYXBTdWJlbnRyaWVzQ29udHJvbCANCmlzIGluY2x1ZGVkIGluIHRoZSBTZWFyY2ggb3Igbm90 LiAgIA0KDQpUaGlzIG1ldGhvZCBvZiByZXF1ZXN0aW5nIHRoZSBvcGVyYXRpb24gYmUgYXBwbGll ZCB0byANCmVudHJpZXMgb2YgbGRhcFN1YkVudHJ5IGNsYXNzIGlzIGludHVpdGl2ZSwgYW5kIGlz IA0Kc3BlY2lmaWVkIHRvIG1haW50YWluIGNvbnNpc3RlbmN5IHdpdGggcHJldmlvdXMgZHJhZnRz IG9mIA0KdGhpcyBkb2N1bWVudC4gDQoNCkRldmVsb3BlcnMgU0hPVUxEIHVzZSB0aGUgY29udHJv bCBsZGFwU3ViZW50cmllc0NvbnRyb2wgaW4gDQpsaWV1IG9mIHRoZSBTZWFyY2ggRmlsdGVyIG1l dGhvZCBvZiBzZWFyY2hpbmcgZm9yIExEQVAgDQpTdWJlbnRyaWVzLCBhcyB0aGUgU2VhcmNoIEZp bHRlciBtZXRob2QgTUFZIGJlIGRlcHJlY2lhdGVkIA0KaW4gdGhlIGZ1dHVyZS4gDQoNCg0KDQo3 LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCg0KTERBUCBTdWJlbnRyaWVzIHdpbGwgZnJlcXVl bnRseSBiZSB1c2VkIHRvIGhvbGQgZGF0YSB3aGljaCANCnJlZmxlY3RzIGVpdGhlciB0aGUgYWN0 dWFsIG9yIGludGVuZGVkIGJlaGF2aW9yIG9mIHRoZSANCmRpcmVjdG9yeSBzZXJ2aWNlLiAgQXMg c3VjaCwgcGVybWlzc2lvbiB0byByZWFkIHN1Y2ggDQplbnRyaWVzIE1BWSBuZWVkIHRvIGJlIHJl c3RyaWN0ZWQgdG8gYXV0aG9yaXplZCB1c2Vycy4gIA0KTW9yZSBpbXBvcnRhbnRseSwgSUYgYSBk aXJlY3Rvcnkgc2VydmljZSB0cmVhdHMgdGhlIA0KaW5mb3JtYXRpb24gaW4gYW4gTERBUCBTdWJl bnRyeSBhcyB0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2UgDQpvZiBwb2xpY3kgdG8gYmUgdXNlZCB0 byBjb250cm9sIHRoZSBiZWhhdmlvciBvZiB0aGUgDQpkaXJlY3RvcnksIHRoZW4gcGVybWlzc2lv biB0byBjcmVhdGUsIG1vZGlmeSwgb3IgZGVsZXRlIA0Kc3VjaCBlbnRyaWVzIE1VU1QgYmUgY2Fy ZWZ1bGx5IHJlc3RyaWN0ZWQgdG8gYXV0aG9yaXplZCANCmFkbWluaXN0cmF0b3JzLiANCg0KVGhp cyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBwb2xpY3kgaW5oZXJpdGFuY2UgbW9kZWwgdGhhdCAN CmFsbG93cyBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdG9ycyB0byBvdmVyLXJpZGUgcG9saWN5IA0K ZGVmaW5lZCBieSBhZG1pbmlzdHJhdG9ycyBvZiBhZG1pbmlzdHJhdGl2ZSBhcmVhcyBzdXBlcmlv ciANCnRvIHRoZSBsb2NhbCBhZG1pbmlzdHJhdGl2ZSBhcmVhLiAgTm8gbWVjaGFuaXNtIGlzIGRl ZmluZWQgDQpoZXJlIHRvIGtlZXAgbG9jYWwgYWRtaW5pc3RyYXRvcnMgZnJvbSBvdmVyLXJpZGlu ZyBzdWNoIA0KaW5oZXJpdGVkIHBvbGljeS4gIEltcGxlbWVudGF0aW9ucyB0aGF0IGludGVuZCB0 byBwcm92aWRlIA0Kc3VjaCBjb250cm9sIG92ZXIgdGhlIGFjdGlvbnMgb2Ygc3Vib3JkaW5hdGUg YWRtaW5pc3RyYXRvcnMgDQp3aWxsIHJlcXVpcmUgYWRkaXRpb25hbCBzZW1hbnRpY3MgKGFuZCBw b3NzaWJseSBzeW50YXgpLiANCg0KDQoNCg0KDQoNCg0KUmVlZCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0gDQogICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDI0LCAyMDAxIA0KIA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDI0IE5vdmVtYmVyIDIwMDAgDQogICAgICAgICAgICAgICAgICAg TERBUCBTdWJlbnRyeSBTY2hlbWEgDQoNCjguIFJlZmVyZW5jZXMgDQoNCltSRkMyMTE5XSBTLiBC cmFkbmVyLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byANCkluZGljYXRlIFJlcXVpcmVt ZW50IExldmVscyIsIFJGQyAyMTE5LCBNYXJjaCAxOTk3IA0KDQpbUkZDMjI1MV0gUy4gS2lsbGUs IE0uIFdhaGwsIGFuZCBULiBIb3dlcywgIkxpZ2h0d2VpZ2h0IA0KRGlyZWN0b3J5IEFjY2VzcyBQ cm90b2NvbCAodjMpIiwgUkZDIDIyNTEsIERlY2VtYmVyIDE5OTcgDQoNCltYLjUwMV0gSVRVLVQg UmVjLiBYLjUwMSwgIlRoZSBEaXJlY3Rvcnk6IE1vZGVscyIsIDE5OTMgYW5kIA0Kc3Vic2VxdWVu dCB2ZXJzaW9ucyANCg0KW1guNTExXSBJVFUtVCBSZWMuIFguNTAxLCAiVGhlIERpcmVjdG9yeTog QWJzdHJhY3QgU2VydmljZSANCkRlZmluaXRpb24iLCAxOTkzIGFuZCBzdWJzZXF1ZW50IHZlcnNp b25zIA0KDQoNCg0KOS4gQ29weXJpZ2h0IE5vdGljZSANCg0KQ29weXJpZ2h0IChDKSBUaGUgSW50 ZXJuZXQgU29jaWV0eSAoMjAwMCkuIEFsbCBSaWdodHMgDQpSZXNlcnZlZC4gIA0KIA0KVGhpcyBk b2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIA0KZnVybmlz aGVkIHRvIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIA0Kb3Ig b3RoZXJ3aXNlIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkg DQpiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9s ZSBvciANCmluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IGtpbmQsIHByb3ZpZGVk IHRoYXQgdGhlIA0KYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJl IGluY2x1ZGVkIG9uIA0KYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dl dmVyLCB0aGlzIA0KZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdh eSwgc3VjaCBhcyBieSANCnJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j ZXMgdG8gdGhlIEludGVybmV0IA0KU29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBvcmdhbml6YXRp b25zLCBleGNlcHQgYXMgbmVlZGVkIA0KZm9yIHRoZSBwdXJwb3NlIG9mIGRldmVsb3BpbmcgSW50 ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIA0KY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJp Z2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCANClN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUg Zm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIA0KdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2Vz IG90aGVyIHRoYW4gRW5nbGlzaC4gDQogDQpUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVk IGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIA0Kd2lsbCBub3QgYmUgcmV2b2tlZCBieSB0aGUgSW50 ZXJuZXQgU29jaWV0eSBvciBpdHMgDQpzdWNjZXNzb3JzIG9yIGFzc2lnbnMuIA0KIA0KVGhpcyBk b2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgDQpwcm92aWRl ZCBvbiBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgDQpUSEUg SU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIA0KV0FSUkFOVElF UywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIA0KVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgDQpO T1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIA0KTUVS Q0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiIgDQoNCg0K UmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAx MF0gDQogICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDI0LCAyMDAxIA0KIA0MDQoNCg0K SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDI0IE5vdmVtYmVyIDIw MDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoNCjEwLiBBY2tu b3dsZWRnZW1lbnRzIA0KDQpUaGUgdXNlIG9mIHN1YkVudHJ5IG9iamVjdCBjbGFzcyB0byBzdG9y ZSBSZXBsaWNhIGFuZCANClJlcGxpY2F0aW9uIEFncmVlbWVudCBpbmZvcm1hdGlvbiBpcyBkdWUg cHJpbWFyaWx5IHRvIHRoZSANCmx1Y2lkIGV4cGxhbmF0aW9uIGJ5IE1hcmsgV2FobCwgKHRoZW4g b2YgSW5ub3NvZnQpLCBvZiBob3cgDQp0aGV5IGNvdWxkIGJlIHVzZWQgYW5kIGV4dGVuZGVkLiAN CiANClRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Ig c2NvcGUgDQpvZiBhbnkgaW50ZWxsZWN0dWFsIHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0 IG1pZ2h0IGJlIA0KY2xhaW1lZCB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1 c2Ugb2YgdGhlIA0KdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUg ZXh0ZW50IHRvIA0Kd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMgbWlnaHQgb3Ig bWlnaHQgbm90IGJlIA0KYXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQg aXQgaGFzIG1hZGUgYW55IA0KZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gSW5m b3JtYXRpb24gb24gdGhlIA0KSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0 cyBpbiBzdGFuZGFyZHMtdHJhY2sgDQphbmQgc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlv biBjYW4gYmUgZm91bmQgaW4gQkNQLTExLiANCkNvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1h ZGUgYXZhaWxhYmxlIGZvciBwdWJsaWNhdGlvbiANCmFuZCBhbnkgYXNzdXJhbmNlcyBvZiBsaWNl bnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIA0KcmVzdWx0IG9mIGFuIGF0dGVtcHQg bWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgDQpwZXJtaXNzaW9uIGZvciB0aGUg dXNlIG9mIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IA0KaW1wbGVtZW50ZXJzIG9yIHVzZXJz IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgDQpmcm9tIHRoZSBJRVRGIFNl Y3JldGFyaWF0LiANCiANClRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8g YnJpbmcgdG8gaXRzIA0KYXR0ZW50aW9uIGFueSBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVu dCBhcHBsaWNhdGlvbnMsIA0Kb3Igb3RoZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBj b3ZlciB0ZWNobm9sb2d5IHRoYXQgDQptYXkgYmUgcmVxdWlyZWQgdG8gcHJhY3RpY2UgdGhpcyBz dGFuZGFyZC4gUGxlYXNlIGFkZHJlc3MgDQp0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgRXhl Y3V0aXZlIERpcmVjdG9yLiANCg0KDQoxMS4gQXV0aG9yJ3MgQWRkcmVzcyANCg0KICAgICBFZHdh cmRzIEUuIFJlZWQgDQogICAgIFJlZWQtTWF0dGhld3MsIEluYy4gDQogICAgIDEwNjQgRSAxNDAg Tm9ydGggDQogICAgIExpbmRvbiwgVVQgIDg0MDQyIA0KICAgICBVU0EgDQogICAgIEUtbWFpbDog ZWVyQG9uY2FsbGRiYS5jb20gIA0KICAgICAgDQogICAgIExEVVAgTWFpbGluZyBMaXN0OiBpZXRm LWxkdXBAaW1jLm9yZyAgDQogICAgIExEQVBFWFQgTWFpbGluZyBMaXN0OiBpZXRmLWxkYXBleHRA bmV0c2NhcGUuY29tIA0KDQoNCg0KDQoNCg0KDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdIA0KICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIE1heSAyNCwgMjAwMSANCiANDA0K --=_FEA5D755.63026EBC-- From owner-ietf-ldup@mail.imc.org Mon Nov 27 11:08:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26723 for ; Mon, 27 Nov 2000 11:08:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02538 for ietf-ldup-bks; Mon, 27 Nov 2000 07:01:46 -0800 (PST) Received: from reed.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA02529 for ; Mon, 27 Nov 2000 07:01:39 -0800 (PST) Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Mon, 27 Nov 2000 08:02:47 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 27 Nov 2000 08:02:41 -0700 From: "Ed Reed" To: Subject: test - sorry, you can delete this message. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA02533 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Is this getting through? ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Mon Nov 27 12:48:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00221 for ; Mon, 27 Nov 2000 12:48:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA09897 for ietf-ldup-bks; Mon, 27 Nov 2000 07:49:09 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09887 for ; Mon, 27 Nov 2000 07:49:08 -0800 (PST) Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO35722 (AUTH rmoats); Mon, 27 Nov 2000 10:50:06 -0500 (EST) From: "Ryan Moats" To: "Ed Reed" Cc: , Subject: RE: draft-ietf-ldup-subentry-06.txt Date: Mon, 27 Nov 2000 09:55:19 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed- Maybe I'm missing something, but when I read through the draft, I see an acknowledgement of how to store Replica and Replication Agreement information but no discussion of how to store Replica and Replication Agreement in the document. Is this intentional or did I just miss something [a common state of affairs]. Ryan -----Original Message----- From: Ed Reed [mailto:eer@OnCallDBA.COM] Sent: Friday, November 24, 2000 4:10 PM To: internet-drafts@ietf.org Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com Subject: draft-ietf-ldup-subentry-06.txt Please publish the attached revised internet draft - draft-ietf-ldup-subentry-06.txt Abstract: This document describes two object classes called ldapSubEntry and inheritableLDAPSubEntry which MAY be used to indicate operations and management related entries in the directory, called LDAP Subentries. To control the visibility of entries of type ldapSubEntry, a control, ldapSubentriesControl, is defined, and a special case using Search filters is described. Scope rules are defined along with rules for dealing with inheritance of subentry policy. To the work group: 1) sorry this arrives to you in base64 encoding...if it does (hi, Rick!) 2) I've significantly revised this document to include the scope discussion requested, and to provide an example scope extension for inheritance and inheritance blocking. It needs your review before going to last call. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Wed Nov 29 19:01:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07010 for ; Wed, 29 Nov 2000 19:01:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16876 for ietf-ldup-bks; Wed, 29 Nov 2000 15:13:49 -0800 (PST) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16872 for ; Wed, 29 Nov 2000 15:13:48 -0800 (PST) Received: from mail2.quallaby.com by dfw7sosrv11.alter.net with ESMTP (peer crosschecked as: [63.88.31.211]) id QQjrlt26409 for ; Wed, 29 Nov 2000 23:15:03 GMT Received: by MAIL2 with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 18:11:50 -0500 Message-ID: From: "Dodor, Dmitri" To: "'ietf-ldup@imc.org'" Subject: LDAP server Date: Wed, 29 Nov 2000 18:11:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi ! I'm looking for any information about LDAP server named "MERRITT . Preferably URL to developer or a distributor Thank you Dmitri From owner-ietf-ldup@mail.imc.org Wed Nov 29 23:16:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01404 for ; Wed, 29 Nov 2000 23:16:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA25941 for ietf-ldup-bks; Wed, 29 Nov 2000 19:34:58 -0800 (PST) Received: from bbs.ht.net.cn (IDENT:root@[202.103.160.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25937 for ; Wed, 29 Nov 2000 19:34:56 -0800 (PST) From: V@tzw.de Received: from h809 (1Cust82.tnt1.mia5.da.uu.net [63.30.194.82]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id LAA18925; Thu, 30 Nov 2000 11:50:33 +0800 Date: Thu, 30 Nov 2000 11:50:33 +0800 Message-Id: <200011300350.LAA18925@bbs.ht.net.cn> To: V@tzw.de Subject: Lady V: The Pleasure Pill for Women! Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LADY V: The Pleasure Pill for Women! Men Have Their Viagra®! Finally, A Pill for Women! It's Here! The Revolutionary Woman's Sexual Sensation is Now Available. Researchers are calling Lady V the greatest breakthrough for women since the Birth Control Pill. And you don't even need a prescription to get it! Welcome to the New Sexual Revolution! It's no secret that men have been having the time of their lives since the wonder pill Viagra® was made available. But, women were left out in the cold with no pill... nothing! Well now thanks to an all-star team of medical researchers who have been working around the clock, those days are finally over. The perfect female "pleasure pill" has been created and you don't even need a prescription. You can now get it from Lion Sciences! Lady V is the world's first pleasure pill scientifically designed for women. Lady V is an all-natural proprietary herbal blend of prosexual nutrients from around the world synergistically blended to naturally stimulate neurotransmitter endorphin signals. This magical combination increases targeted blood flow, unleashes natural stimulator for maximum stimulation, triggering pleasure responses quickly. Lady V is safe, natural and doctor-recommended. Since its introduction Lady V has been taking the world by storm! From Malibu to Miami women are enjoying the most intense pleasure of their lives! • 100% Natural • Safe • The Highest Quality Pharmaceutical Pure Nutraceuticals • Guaranteed Potency • Certified Purity Lady V is Sweeping the Nation! Women are going crazy over Lady V. Suddenly couples are falling in love all over again. The passion and pleasure that women are reporting is off the charts! Lady V has an incredible 88% success rate. Best of all, while Viagra costs $10 a pill, Lady V costs less than $1 a pill! It's not just a man's world anymore! Just look at what a few women have to say: "I thought my love life was good before, but now it is out of this world! Lady V is remarkable." — Mary J., Interior Designer "I haven't smiled like this in a long time. My husband and I feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer "Imagine what it would feel like to have incredible passion and pleasure anytime you want." — Jennifer C., Film Editor "Suddenly my husband and I are spending more time in the bedroom instead of the TV room." — Angie R., Realtor Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid, Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract, Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana, and L-Taurine. Each bottle of Lady V contains 30 tablets. Take three capsules one hour before romantic activity as a dietary supplement. Risk Free: Double Your Money Back Guarantee If Lady V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked! Order Now: Safe, Fast, Secure, Private Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Lady V contains 30 tablets. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Lady V $24 ______ 2 Bottles of Lady V $44 ______ 3 Bottles of Lady V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Lady V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Lady V helps provide herbal and nutritional support for female sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You.