From owner-ietf-ldup@mail.imc.org  Thu Nov  1 16:59:06 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01659
	for <ldup-archive@odin.ietf.org>; Thu, 1 Nov 2001 16:59:05 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA1LShT13017
	for ietf-ldup-bks; Thu, 1 Nov 2001 13:28:43 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.17])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1LSf813013
	for <ietf-ldup@imc.org>; Thu, 1 Nov 2001 13:28:41 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id A1101-1628-0ae000;
	Thu, 1 Nov 2001 21:28:39 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V622C89W>; Thu, 1 Nov 2001 16:26:08 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF2F@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>
Cc: "John Strassner (E-mail)" <john.strassner@intelliden.com>
Subject: several document revisions and other commitments slipped signific
	antly
Date: Thu, 1 Nov 2001 16:26:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0012_01C162F1.C8A17770"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C162F1.C8A17770
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0013_01C162F1.C8A17770"


------=_NextPart_001_0013_01C162F1.C8A17770
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Take a look at the meeting minutes from the last WG meeting:

	http://www.imc.org/ietf-ldup/mail-archive/msg01145.html

If you've got a ToDo/Document Revision in there, let me know
when you will do it or that you cannot and do not plan to.

The WG is slipping into a risky place AGAIN.

I plan to post a charter revision to the WG Mailing List this
coming Monday, November 5 2001. It will include revised dates
for deliverables that are either submitted by you or estimated
by me - your choice. This charter will be open for review for
one (1) calendar week from the date actually posted and will be
submitted to our ADs shortly after that time assuming all issues
raised on the list relative to the revised charter proposal can
be resolved quickly.

For anyone who is wondering, I have requested an LDUP meeting
slot in Salt Lake City. I have also requested that our session
be scheduled on the same or an adjacent day to LDAPBIS, POLICY,
and LDAPEXT (if they are meeting).

I'll be working on the WG meeting agenda over the next several
days. Please send your suggestions/requests for topics on the
WG agenda directly to myself and John Strassner. We will post
a proposed agenda to the list prior to submitting to the Agenda
Coordinator.

Note to document editors: if you cannot attend the meeting, please
let John and I know who will be covering your document during
the meeting in your place.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860

------=_NextPart_001_0013_01C162F1.C8A17770
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_0013_01C162F1.C8A17770--

------=_NextPart_000_0012_01C162F1.C8A17770
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwMTIxMjUxM1owIwYJKoZIhvcNAQkEMRYEFDHOAOcp+b9S
IrCZHYIjT7wG6BrnMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAcmJnncmDLdvZ26vphZ/vG5qM
AgiSygOqFviMOqsVbpUtBDJON+cMn+LkJjK0Ogd3EpJRRZzEXKXeOvx+jF83swXj8q6LxndMmmX1
SCtxL8XYL1QwRnFKTioJfa5/yC3Jg9RlhiPfJuSRZ7wIHjL0vviQlSzHQ4ynjixldd7p0/sAAAAA
AAA=

------=_NextPart_000_0012_01C162F1.C8A17770--



From owner-ietf-ldup@mail.imc.org  Fri Nov  2 16:26:39 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18789
	for <ldup-archive@odin.ietf.org>; Fri, 2 Nov 2001 16:26:39 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fA2KwMN13981
	for ietf-ldup-bks; Fri, 2 Nov 2001 12:58:22 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2KwH813977
	for <ietf-ldup@imc.org>; Fri, 2 Nov 2001 12:58:21 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Fri, 02 Nov 2001 15:53:34 -0700
Message-Id: <sbe2c17e.087@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Fri, 02 Nov 2001 15:53:20 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>, <hahnt@us.ibm.com>
Subject: Re: Subentries decision - internet draft withdrawn
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 above.proper.com id fA2KwL813978
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


<eer> comments </eer>

=================
Ed Reed
Reed-Matthews, Inc.
+1 716 624 2402 (new!)
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/31/01 09:21AM >>>
At 08:17 AM 2001-10-30, Ed Reed wrote:
>1) encourage Kurt to revise the draft to make it "Standards Track"
>instead of "Informational", so we can refer to it;

no problem.  <eer> thanks </eer>

>2) Follow David Chadwick's suggestion that we define the
>replicationAgreementSubentry class as a subclass of the X.500
>subentry, and define a structure rule for it that allows containment
>of the replicationAgreementSubentry class entries by replicaSubentry class
>entries.

no problem.  <eer> thanks </eer>

>3) discourage use of the specificationFilter in the SubtreeSpecification,

I note that specificationFilter seems to a useful in supporting
sparse replication.

<eer>

Yeah, I know.  But that's what I"m afraid of right now, because I'm having
trouble visualizing how the administration tool (built on Microsoft's Console
or Novell's ConsoleOne or NetScape's Directory Manager) will represent
the sparse replication, and worse yet, the overlap, if any, of two
different replicaSubentry specifications of the same replicationArea when
they choose different subsets of entries, or possibly overlapping subsets
of entries.

I know there are uses of such things, but it seems to me that the 80-20
rule would dictate that 80% of the time such sparse replication won't
be needed, or wanted, and support for the other 20% will, while
possible, more difficult to manage correctly.  If we don't discourage its
use, then it will have to be supported by everyone, whether they can
create a management tool to make sense of it by administrators, or not.

I confess, this is an area of my own bias.  I can certainly be persuaded
to just let it go and see what the market creates.  But I've felt that I
owed the community that would listen this one last appeal for simplicity
of required implementation.  Nuff said.

</eer>

Kurt




From owner-ietf-ldup@mail.imc.org  Fri Nov  2 16:34:24 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19237
	for <ldup-archive@odin.ietf.org>; Fri, 2 Nov 2001 16:34:23 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA2LC5514260
	for ietf-ldup-bks; Fri, 2 Nov 2001 13:12:05 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.21])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2LC4814256
	for <ietf-ldup@imc.org>; Fri, 2 Nov 2001 13:12:04 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id H1102-1611-39b000;
	Fri, 2 Nov 2001 21:12:00 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V622DHVL>; Fri, 2 Nov 2001 16:09:25 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF3F@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>
Subject: WG Last Call: LDAPv3 Operation Framing and Grouping Drafts
Date: Fri, 2 Nov 2001 16:09:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_001D_01C163B8.9D1B5130"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C163B8.9D1B5130
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_001E_01C163B8.9D1B5130"


------=_NextPart_001_001E_01C163B8.9D1B5130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The purpose of this message is to initiate the LDUP
working group last call on two documents:

1) Profile for Framing LDAPv3 Operations

2) LDAPv3: Grouping of Related Operations

WHICH DOCUMENTS?

The documents in last call are:

http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t
xt

http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-02.txt


WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
documents, believes that all the known outstanding issues
have been addressed, and is ready to put the documents
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately three
weeks. It will end on Friday, November 30, 2001.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
   forward the documents to the IESG for proposed standard
   status.

2) Minor changes agreed to on the list are required, and
   the document is revised. We then ask our ADs to put
   forward the revised document to the IESG for
   proposed standard status.

3) Major issues are raised and no consensus is reached on
   the list. In this case, we discuss things until consensus
   is reached, at which time another working group last call
   will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.

If the first outcome happens, the documents are put forward
for a last call to the entire IETF of a duration appropriate
for the type of document, and after successful completion
the documents are published as RFCs with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.

WHAT SHOULD YOU DO?

You should read the documents, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me and/or LDUP WG co-chair John Strassner.

Silence means consent.

Read, enjoy, and send your comments in!

regards,
Chris Apple and John Strassner

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860

------=_NextPart_001_001E_01C163B8.9D1B5130
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_001E_01C163B8.9D1B5130--

------=_NextPart_000_001D_01C163B8.9D1B5130
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwMjIxMDgzMFowIwYJKoZIhvcNAQkEMRYEFCLRnStQRPU1
Hrg65x6YGpUhOJvsMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAKmi9/tRUHegyjGKzklUfVeTO
YI+LSosf9iB87Fe2GnRr5pm4jers9Q6xFFxL3Z1dsPDFzY7VjC6+t6ef3hSkUBXGIJH5r+TD02nD
QDSseiOp8XS6GVookumDvkWB3LRqyQcrY7y0ecnKVXb9vTMiwsqwuVp6nwSTPtLIKACU1sYAAAAA
AAA=

------=_NextPart_000_001D_01C163B8.9D1B5130--



From owner-ietf-ldup@mail.imc.org  Fri Nov  2 17:36:05 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20585
	for <ldup-archive@odin.ietf.org>; Fri, 2 Nov 2001 17:36:04 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA2MEHY16020
	for ietf-ldup-bks; Fri, 2 Nov 2001 14:14:17 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2MEG816016
	for <ietf-ldup@imc.org>; Fri, 2 Nov 2001 14:14:16 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id H1102-1714-142400;
	Fri, 2 Nov 2001 22:14:15 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V622D2JS>; Fri, 2 Nov 2001 17:11:40 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF44@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>
Subject: RE: WG Last Call: LDAPv3 Operation Framing and Grouping Drafts
Date: Fri, 2 Nov 2001 17:11:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_004C_01C163C1.4F6C9A80"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_004C_01C163C1.4F6C9A80
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_004D_01C163C1.4F6C9A80"


------=_NextPart_001_004D_01C163C1.4F6C9A80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The URL for the Framing draft doesn't work if clicked on
in my browser because my mail client truncated the "xt" part
of ".txt"....have to manually adjust it when trying to use the
link.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Christopher Apple [mailto:christopher.apple@UnitedMessaging.net]
Sent: Friday, November 02, 2001 4:09 PM
To: 'ietf-ldup@imc.org'
Subject: WG Last Call: LDAPv3 Operation Framing and Grouping Drafts


The purpose of this message is to initiate the LDUP
working group last call on two documents:

1) Profile for Framing LDAPv3 Operations

2) LDAPv3: Grouping of Related Operations

WHICH DOCUMENTS?

The documents in last call are:

http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t
xt

http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-02.txt


WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
documents, believes that all the known outstanding issues
have been addressed, and is ready to put the documents
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately three
weeks. It will end on Friday, November 30, 2001.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
   forward the documents to the IESG for proposed standard
   status.

2) Minor changes agreed to on the list are required, and
   the document is revised. We then ask our ADs to put
   forward the revised document to the IESG for
   proposed standard status.

3) Major issues are raised and no consensus is reached on
   the list. In this case, we discuss things until consensus
   is reached, at which time another working group last call
   will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.

If the first outcome happens, the documents are put forward
for a last call to the entire IETF of a duration appropriate
for the type of document, and after successful completion
the documents are published as RFCs with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.

WHAT SHOULD YOU DO?

You should read the documents, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me and/or LDUP WG co-chair John Strassner.

Silence means consent.

Read, enjoy, and send your comments in!

regards,
Chris Apple and John Strassner

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860

------=_NextPart_001_004D_01C163C1.4F6C9A80
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_004D_01C163C1.4F6C9A80--

------=_NextPart_000_004C_01C163C1.4F6C9A80
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwMjIyMTA0NVowIwYJKoZIhvcNAQkEMRYEFK+lGYXfwB6m
TBA0YS9orbKuxmcTMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAcxF68y2h9WHKajS3neI9gMhF
c7ShZ9+oFBgOwLWHSOkmzMnJ4XcR4lSZcgrBjCBgV0KONdWymOJZyP8LxYvygDoVu+twHtH8DbQM
dWrZIpRa9zs9rOVAbQ5m9JdhpkG1uNiDen4wUl7l8y2B4pKKqUNyldbJCkdsCbQc/vrZ7w0AAAAA
AAA=

------=_NextPart_000_004C_01C163C1.4F6C9A80--



From owner-ietf-ldup@mail.imc.org  Fri Nov  2 19:06:43 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22158
	for <ldup-archive@odin.ietf.org>; Fri, 2 Nov 2001 19:06:42 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fA2Nk2E17910
	for ietf-ldup-bks; Fri, 2 Nov 2001 15:46:02 -0800 (PST)
Received: from ARKMAIL.arkivio.com ([66.120.211.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2Nk2817906
	for <ietf-ldup@imc.org>; Fri, 2 Nov 2001 15:46:02 -0800 (PST)
Received: from BRUCE-LAPTOP.directory-applications.com ([66.120.211.227]) by ARKMAIL.arkivio.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 2 Nov 2001 15:40:34 -0800
Message-Id: <5.1.0.14.0.20011102153723.00a8dbd0@mail.dtasi.com>
X-Sender: bgreenblatt@mail.dtasi.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 02 Nov 2001 15:39:44 -0800
To: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>
From: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject: Re: WG Last Call: LDAPv3 Operation Framing and Grouping Drafts
In-Reply-To: <504D6456F0C87F4C8B11FB0C2021D6F602DACF3F@ex04.ummail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 02 Nov 2001 23:40:34.0997 (UTC) FILETIME=[C49FE650:01C163F7]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 01:09 PM 11/2/2001 -0800, Christopher Apple wrote:
>The purpose of this message is to initiate the LDUP
>working group last call on two documents:
>
>1) Profile for Framing LDAPv3 Operations
>
>2) LDAPv3: Grouping of Related Operations


Just out of curiosity, what LDAP server vendors are planning on supporting 
the functions supplied by these drafts/



From owner-ietf-ldup@mail.imc.org  Mon Nov  5 16:10:14 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07899
	for <ldup-archive@odin.ietf.org>; Mon, 5 Nov 2001 16:10:13 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA5KXmk14706
	for ietf-ldup-bks; Mon, 5 Nov 2001 12:33:48 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.17])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5KXk814700
	for <ietf-ldup@imc.org>; Mon, 5 Nov 2001 12:33:47 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id K1105-1533-700c00;
	Mon, 5 Nov 2001 20:33:45 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V622DWH0>; Mon, 5 Nov 2001 15:31:01 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF5C@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>
Cc: "John Strassner (E-mail)" <john.strassner@intelliden.com>
Subject: Revised WG Charter Proposal
Date: Mon, 5 Nov 2001 15:30:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_00A5_01C1660E.BA420A30"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_00A5_01C1660E.BA420A30
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_00A6_01C1660E.BA420A30"


------=_NextPart_001_00A6_01C1660E.BA420A30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Based on input from document editors and a little editing from me,
please review the following. The open review period of this begins
today, Monday, November 5, 2001 and will last for 7 days.

The review period therefore ends on Monday, November 12, 2001.

Silence equals consent. This will be sent to the ADs for review
subject to incorporation of comments sent, discussed, and
vetted on the WG mailing list shortly after November 12, 2001.

LDAP Duplication/Replication/Update Protocols (ldup) 

Last Modified: 05-Nov-01 

Chair(s):

Chris Apple <christopher.apple@unitedmessaging.com>
John Strassner <john.strassner@intelliden.com>

Applications Area Director(s): 

Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor: 

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:
 
General Discussion:ietf-ldup@imc.org 
To Subscribe: ietf-ldup-request@imc.org 
In Body: subscribe 
Archive: http://www.imc.org/ietf-ldup/ 

Description of Working Group:
 
As LDAPv3 becomes more widely deployed, replication of data across
servers running different implementations becomes an important part
of providing a distributed directory service. However, the LDAPv3
community, to date, has focused on standardizing the client-server
access protocol. Therefore, this group will standardize master-slave
and multi-master LDAPv3 replication as defined below: 

o Multi-Master Replication - A replication model where entries can
  be written and updated on any of several replica copies, without
  requiring communication with other masters before the write or
  update is performed. 

o Master-Slave, or Single-Master Replication - A replication model
  that assumes only one server, the master, allows write access to
  the replicated data. Note that Master-Slave replication can be
  considered a proper subset of multi-master replication. 

The WG's approach is to first develop a set of requirements for
LDAPv3 directory replication and write an applicability statement
defining scenarios on which replication requirements are based.
An engineering team was formed consisting of different vendors
and the co-chairs in order to harmonize the existing approaches
into a single standard approach. All of these have been accomplished
during the pre-working group stage. It should be noted, however,
that replication using heterogeneous servers is dependent on
resolving access control issues, which are the domain of other
working groups. Should these issues not be resolved outside of
the LDUP WG in a timely manner relative to the WG's needs, the
WG will be re-chartered subject to Applications AD/IESG approval
to include the minimum required work.

The new replication architecture support all forms of replication
mentioned above. Seven areas of working group focus have been
identified through LDUP Engineering Team discussions, each leading
to one or more Engineering Team discussions, each leading to one
or more documents to be published: 

o LDAPv3 Replication Architecture 

   This documents a general-purpose LDAPv3 replication architecture,
   defines key components of this architecture, describes how these
   key components functionally behave, and describes how these
   components interact with each other when in various modes of
   operation. 

o LDAPv3 Replication Information Model 

   Defines the schema and semantics of information used to operate,
   administer, maintain, and provision replication between LDAPv3
   servers. Specifically, this document will contain common schema
   specifications intended to facilitate interoperable
   implementations with respect to: 

      + replication agreements 

      + consistency models 

      + replication topologies 

      + managing deleted objects and their states 

      + administration and management 

o LDAPv3 Replication Information Transport Protocol 

   LDAPv3 extended operation and control specifications required to
   allow LDAPv3 to be used as the transport protocol for information
   being replicated 

o LDAPv3 Mandatory Replica Management 

   Specifications required to allow administration, maintenance, and
   provisioning of replicas and replication agreements. These
   specifications may take the form of definitions for LDAPv3
   extended operations, controls, and/or new schema elements. 

o LDAPv3 Update Reconciliation Procedures 

   Procedures for detection and resolution of conflicts between the
   state of multiple replicas that contain information from the same
   unit of replication. 

o LDAPv3 Replication Usage Profile 

   Including the LDAPv3 Replication Architecture, Information Model,
   Protocol Extensions, and Update Reconciliation Procedures for: 

      + LDAPv3 Master-Slave Directory Replication 

      + LDAPv3 Multi-Master Directory Replication 

o LDAPv3 Client Update 

   A protocol that enables an LDAP client to synchronize with the
   content of a directory information tree (DIT) stored by an LDAP
   server and to be notified about the changes to that content. 

The work being done in the LDUP WG should be coordinated to the
closest extent possible with similar work being done in the ITU.
This is necessary both because LDAP depends on X.500 and because
it makes sense from an operational perspective. 


Goals and Milestones:

Done    Submit I-D on LDAPv3 Directory Replication Requirements. 

Done    Submit Internet-Draft on LDAPv3 Replication Information Model. 

Done    Submit I-D on LDAPv3 Update Reconciliation Procedures. 

Done    Revise I-D on LDAPv3 Directory Replication Requirements. 

Done    Revise I-D on LDAPv3 Replication Architecture. 

Done    Revise I-D on LDAPv3 Replication Architecture. 

Done    Revise I-D on LDAPv3 Replication Information Model. 

Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.


Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
Call as Informational.

Done    Submit I-D on LDAPv3 Mandatory Replica Management.

Done	Submit I-D on General LDUP Usage Profile.

Done	Submit I-D on LDAPv3 Operations Framing.

Oct 01	I-D on LDAPv3 Extended Operations for Framing goes to WG Last
Call as Proposed Standard.

Nov 01	Submit I-D on LDAPv3 Replication Information Transport Protocol.


Nov 01	Revise I-D on General LDUP Usage Profile.

Nov 01	Revise I-D on LDAPv3 Mandatory Replica Management.

Dec 01	LDAPv3 Client Update Protocol I-D goes to WG Last Call as
Proposed Standard. 

Feb 02	LDAPv3 Replication Architecture I-D goes to WG Last Call as
Informational. 

Mar 02	LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call
as Proposed Standard.

Mar 02	LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
Proposed Standard. 

Mar 02	LDAPv3 Replication Information Model I-D goes to WG Last Call as
Proposed Standard.

Mar 02	LDAPv3 Replication Information Transport Protocol I-D goes to WG
Last Call as Proposed Standard.

Mar 02	Re-evaluate Charter and Milestones.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860

------=_NextPart_001_00A6_01C1660E.BA420A30
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_00A6_01C1660E.BA420A30--

------=_NextPart_000_00A5_01C1660E.BA420A30
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwNTIwMjk1OFowIwYJKoZIhvcNAQkEMRYEFNErvgwXOZbg
tHMyn+magIHDNCwOMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAd+Mg4WRwoyYV7/VgS10vbqWn
oeX/5WKymw37HzpekxN/OfBcM3wtcKduBjvcll4eydFnW7+ZKvoiW0+Qb59uOIca5qu3Dt8e7r8Q
0Ys7nJOqUBpe9dwqrUhS4zgPzIVKEIZUysMd07Ecb2ymw4mPbpPH/wg0N79GmYTdqvVapaMAAAAA
AAA=

------=_NextPart_000_00A5_01C1660E.BA420A30--



From owner-ietf-ldup@mail.imc.org  Mon Nov  5 17:06:21 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09423
	for <ldup-archive@odin.ietf.org>; Mon, 5 Nov 2001 17:06:20 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA5Lh0816821
	for ietf-ldup-bks; Mon, 5 Nov 2001 13:43:00 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5Lgx816816;
	Mon, 5 Nov 2001 13:42:59 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA130622;
	Mon, 5 Nov 2001 16:40:20 -0500
Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA5LgrR20110;
	Mon, 5 Nov 2001 16:42:53 -0500
To: Christopher Apple <christopher.apple@UnitedMessaging.net>
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)" <john.strassner@intelliden.com>,
        owner-ietf-ldup@mail.imc.org
Subject: Re: Revised WG Charter Proposal
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
From: "Timothy Hahn" <hahnt@us.ibm.com>
Message-ID: <OF55689B26.D852770C-ON85256AFB.00762853@pok.ibm.com>
Date: Mon, 5 Nov 2001 16:42:52 -0500
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V509_10152001.dev02 |October
 31, 2001) at 11/05/2001 04:42:54 PM,
	Serialize complete at 11/05/2001 04:42:54 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00767B0085256AFB_="
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00767B0085256AFB_=
Content-Type: text/plain; charset="us-ascii"

Chris,

I have PROPOSED some modifications to the milestones section of the 
charter below, look for <TJH> .. </TJH>

...

Done    Submit I-D on LDAPv3 Directory Replication Requirements.

Done    Submit Internet-Draft on LDAPv3 Replication Information Model.

Done    Submit I-D on LDAPv3 Update Reconciliation Procedures.

Done    Revise I-D on LDAPv3 Directory Replication Requirements.

Done    Revise I-D on LDAPv3 Replication Architecture.

Done    Revise I-D on LDAPv3 Replication Architecture.

Done    Revise I-D on LDAPv3 Replication Information Model.

Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.


Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
Call as Informational.

Done    Submit I-D on LDAPv3 Mandatory Replica Management.

Done    Submit I-D on General LDUP Usage Profile.

Done    Submit I-D on LDAPv3 Operations Framing.

Oct 01  I-D on LDAPv3 Extended Operations for Framing goes to WG Last
Call as Proposed Standard.

Nov 01  <TJH>Revise</TJH><TJH>(strike)Submit</TJH> I-D on LDAPv3 
Replication Information Transport Protocol.

<TJH>
Nov 01  Revise I-D on LDAPv3 Replication Information Model.
</TJH>

Nov 01  Revise I-D on General LDUP Usage Profile.

Nov 01  Revise I-D on LDAPv3 Mandatory Replica Management.

Dec 01  LDAPv3 Client Update Protocol I-D goes to WG Last Call as
Proposed Standard.

Feb 02  LDAPv3 Replication Architecture I-D goes to WG Last Call as
Informational.

Mar 02  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call
as Proposed Standard.

Mar 02  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
Proposed Standard.

Mar 02  LDAPv3 Replication Information Model I-D goes to WG Last Call as
Proposed Standard.

Mar 02  LDAPv3 Replication Information Transport Protocol I-D goes to WG
Last Call as Proposed Standard.

Mar 02  Re-evaluate Charter and Milestones.



Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

--=_alternative 00767B0085256AFB_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Chris,</font>
<br>
<br><font size=2 face="sans-serif">I have PROPOSED some modifications to the milestones section of the charter below, look for &lt;TJH&gt; .. &lt;/TJH&gt;<br>
</font>
<br><font size=2 face="sans-serif">...</font>
<br>
<br><font size=2><tt>Done &nbsp; &nbsp;Submit I-D on LDAPv3 Directory Replication Requirements.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Submit Internet-Draft on LDAPv3 Replication Information Model.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Submit I-D on LDAPv3 Update Reconciliation Procedures.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Revise I-D on LDAPv3 Directory Replication Requirements.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Revise I-D on LDAPv3 Replication Architecture.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Revise I-D on LDAPv3 Replication Architecture.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Revise I-D on LDAPv3 Replication Information Model.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Submit I-D on LDAPv3 Replication Information Transport Protocol.<br>
</tt></font>
<br>
<br><font size=2><tt>Done &nbsp; &nbsp;LDAPv3 Directory Replication Requirements I-D goes to WG Last<br>
Call as Informational.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp;Submit I-D on LDAPv3 Mandatory Replica Management.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp; &nbsp; &nbsp;Submit I-D on General LDUP Usage Profile.<br>
</tt></font>
<br><font size=2><tt>Done &nbsp; &nbsp; &nbsp; &nbsp;Submit I-D on LDAPv3 Operations Framing.<br>
</tt></font>
<br><font size=2><tt>Oct 01 &nbsp; &nbsp; &nbsp; &nbsp;I-D on LDAPv3 Extended Operations for Framing goes to WG Last<br>
Call as Proposed Standard.<br>
</tt></font>
<br><font size=2><tt>Nov 01 &nbsp; &nbsp; &nbsp; &nbsp;&lt;TJH&gt;Revise&lt;/TJH&gt;&lt;TJH&gt;(strike)Submit&lt;/TJH&gt; I-D on LDAPv3 Replication Information Transport Protocol.<br>
</tt></font>
<br><font size=2><tt>&lt;TJH&gt;</tt></font>
<br><font size=2><tt>Nov 01 &nbsp; &nbsp; &nbsp; &nbsp;Revise I-D on LDAPv3 Replication Information Model.<br>
&lt;/TJH&gt;</tt></font>
<br>
<br><font size=2><tt>Nov 01 &nbsp; &nbsp; &nbsp; &nbsp;Revise I-D on General LDUP Usage Profile.<br>
</tt></font>
<br><font size=2><tt>Nov 01 &nbsp; &nbsp; &nbsp; &nbsp;Revise I-D on LDAPv3 Mandatory Replica Management.<br>
</tt></font>
<br><font size=2><tt>Dec 01 &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Client Update Protocol I-D goes to WG Last Call as<br>
Proposed Standard.<br>
</tt></font>
<br><font size=2><tt>Feb 02 &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Replication Architecture I-D goes to WG Last Call as<br>
Informational.<br>
</tt></font>
<br><font size=2><tt>Mar 02 &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call<br>
as Proposed Standard.<br>
</tt></font>
<br><font size=2><tt>Mar 02 &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as<br>
Proposed Standard.<br>
</tt></font>
<br><font size=2><tt>Mar 02 &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Replication Information Model I-D goes to WG Last Call as<br>
Proposed Standard.<br>
</tt></font>
<br><font size=2><tt>Mar 02 &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Replication Information Transport Protocol I-D goes to WG<br>
Last Call as Proposed Standard.<br>
</tt></font>
<br><font size=2><tt>Mar 02 &nbsp; &nbsp; &nbsp; &nbsp;Re-evaluate Charter and Milestones.<br>
</tt></font>
<br>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Tim Hahn<br>
<br>
Internet: hahnt@us.ibm.com<br>
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<br>
phone: 607.752.6388 &nbsp; &nbsp; tie-line: 8/852.6388<br>
fax: 607.752.3681<br>
</font>
--=_alternative 00767B0085256AFB_=--


From owner-ietf-ldup@mail.imc.org  Mon Nov  5 17:14:43 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09605
	for <ldup-archive@odin.ietf.org>; Mon, 5 Nov 2001 17:14:43 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA5Lsf717104
	for ietf-ldup-bks; Mon, 5 Nov 2001 13:54:41 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.21])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5Lse817099
	for <ietf-ldup@imc.org>; Mon, 5 Nov 2001 13:54:40 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id G1105-1654-149900;
	Mon, 5 Nov 2001 21:54:33 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V622DX27>; Mon, 5 Nov 2001 16:51:49 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF60@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'Timothy Hahn'" <hahnt@us.ibm.com>
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>
Subject: RE: Revised WG Charter Proposal
Date: Mon, 5 Nov 2001 16:51:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	micalg=SHA1;
	boundary="----=_NextPart_000_0003_01C1661A.01564B60";
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C1661A.01564B60
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0004_01C1661A.01564B60"


------=_NextPart_001_0004_01C1661A.01564B60
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_0005_01C1661A.01564B60"


------=_NextPart_002_0005_01C1661A.01564B60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Comments below....
 

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
< http://www.unitedmessaging.com <http://www.unitedmessaging.com/> >
< mailto:christopher.apple@unitedmessaging.com
<mailto:christopher.apple@unitedmessaging.com> >
(V) +1 610 425 2860


-----Original Message-----
From: Timothy Hahn [mailto:hahnt@us.ibm.com]
Sent: Monday, November 05, 2001 4:43 PM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail);
owner-ietf-ldup@mail.imc.org
Subject: Re: Revised WG Charter Proposal



Chris, 

I have PROPOSED some modifications to the milestones section of the
charter below, look for <TJH> .. </TJH>

... 

Done    Submit I-D on LDAPv3 Directory Replication Requirements.

Done    Submit Internet-Draft on LDAPv3 Replication Information Model.

Done    Submit I-D on LDAPv3 Update Reconciliation Procedures.

Done    Revise I-D on LDAPv3 Directory Replication Requirements.

Done    Revise I-D on LDAPv3 Replication Architecture.

Done    Revise I-D on LDAPv3 Replication Architecture.

Done    Revise I-D on LDAPv3 Replication Information Model.

Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.


Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
Call as Informational.

Done    Submit I-D on LDAPv3 Mandatory Replica Management.

Done        Submit I-D on General LDUP Usage Profile.

Done        Submit I-D on LDAPv3 Operations Framing.

Oct 01        I-D on LDAPv3 Extended Operations for Framing goes to WG
Last
Call as Proposed Standard.

Nov 01        <TJH>Revise</TJH><TJH>(strike)Submit</TJH> I-D on LDAPv3
Replication Information Transport Protocol.
[Christopher Apple]  You are correct. My error. Change made.
 
<TJH> 
Nov 01        Revise I-D on LDAPv3 Replication Information Model.
</TJH> 
[Christopher Apple] My error. Apologize for the omission. Change made. 

Nov 01        Revise I-D on General LDUP Usage Profile.

Nov 01        Revise I-D on LDAPv3 Mandatory Replica Management.

Dec 01        LDAPv3 Client Update Protocol I-D goes to WG Last Call as
Proposed Standard.

Feb 02        LDAPv3 Replication Architecture I-D goes to WG Last Call
as
Informational.

Mar 02        LDAPv3 Update Reconciliation Procedures I-D goes to WG
Last Call
as Proposed Standard.

Mar 02        LDAPv3 Mandatory Replica Management I-D goes to WG Last
Call as
Proposed Standard.

Mar 02        LDAPv3 Replication Information Model I-D goes to WG Last
Call as
Proposed Standard.

Mar 02        LDAPv3 Replication Information Transport Protocol I-D goes
to WG
Last Call as Proposed Standard.

Mar 02        Re-evaluate Charter and Milestones.



Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681



------=_NextPart_002_0005_01C1661A.01564B60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D428094621-05112001>Comments below....</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=3D2>Chris Apple<BR>Program Manager - Integration =
Services<BR>United=20
Messaging Inc.<BR>&lt;<A href=3D"http://www.unitedmessaging.com/"=20
target=3D_blank>http://www.unitedmessaging.com</A>&gt;<BR>&lt;<A=20
href=3D"mailto:christopher.apple@unitedmessaging.com">mailto:christopher.=
apple@unitedmessaging.com</A>&gt;<BR>(V)=20
+1 610 425 2860<BR></FONT></P>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Timothy Hahn=20
  [mailto:hahnt@us.ibm.com]<BR><B>Sent:</B> Monday, November 05, 2001 =
4:43=20
  PM<BR><B>To:</B> Christopher Apple<BR><B>Cc:</B> 'ietf-ldup@imc.org'; =
John=20
  Strassner (E-mail); owner-ietf-ldup@mail.imc.org<BR><B>Subject:</B> =
Re:=20
  Revised WG Charter Proposal<BR><BR></FONT></DIV>
  <DIV><BR><FONT face=3Dsans-serif size=3D2>Chris,</FONT> <BR><BR><FONT=20
  face=3Dsans-serif size=3D2>I have PROPOSED some modifications to the =
milestones=20
  section of the charter below, look for &lt;TJH&gt; ..=20
  &lt;/TJH&gt;<BR></FONT><BR><FONT face=3Dsans-serif size=3D2>...</FONT> =

  <BR><BR><FONT size=3D2><TT>Done &nbsp; &nbsp;Submit I-D on LDAPv3 =
Directory=20
  Replication Requirements.<BR></TT></FONT><BR><FONT size=3D2><TT>Done =
&nbsp;=20
  &nbsp;Submit Internet-Draft on LDAPv3 Replication Information=20
  Model.<BR></TT></FONT><BR><FONT size=3D2><TT>Done &nbsp; &nbsp;Submit =
I-D on=20
  LDAPv3 Update Reconciliation Procedures.<BR></TT></FONT><BR><FONT=20
  size=3D2><TT>Done &nbsp; &nbsp;Revise I-D on LDAPv3 Directory =
Replication=20
  Requirements.<BR></TT></FONT><BR><FONT size=3D2><TT>Done &nbsp; =
&nbsp;Revise I-D=20
  on LDAPv3 Replication Architecture.<BR></TT></FONT><BR><FONT =
size=3D2><TT>Done=20
  &nbsp; &nbsp;Revise I-D on LDAPv3 Replication=20
  Architecture.<BR></TT></FONT><BR><FONT size=3D2><TT>Done &nbsp; =
&nbsp;Revise I-D=20
  on LDAPv3 Replication Information Model.<BR></TT></FONT><BR><FONT=20
  size=3D2><TT>Done &nbsp; &nbsp;Submit I-D on LDAPv3 Replication =
Information=20
  Transport Protocol.<BR></TT></FONT><BR><BR><FONT size=3D2><TT>Done =
&nbsp;=20
  &nbsp;LDAPv3 Directory Replication Requirements I-D goes to WG =
Last<BR>Call as=20
  Informational.<BR></TT></FONT><BR><FONT size=3D2><TT>Done &nbsp; =
&nbsp;Submit=20
  I-D on LDAPv3 Mandatory Replica Management.<BR></TT></FONT><BR><FONT=20
  size=3D2><TT>Done &nbsp; &nbsp; &nbsp; &nbsp;Submit I-D on General =
LDUP Usage=20
  Profile.<BR></TT></FONT><BR><FONT size=3D2><TT>Done &nbsp; &nbsp; =
&nbsp;=20
  &nbsp;Submit I-D on LDAPv3 Operations =
Framing.<BR></TT></FONT><BR><FONT=20
  size=3D2><TT>Oct 01 &nbsp; &nbsp; &nbsp; &nbsp;I-D on LDAPv3 Extended =
Operations=20
  for Framing goes to WG Last<BR>Call as Proposed=20
  Standard.<BR></TT></FONT><BR><TT><FONT size=3D2>Nov 01 &nbsp; &nbsp; =
&nbsp;=20
  =
&nbsp;&lt;TJH&gt;Revise&lt;/TJH&gt;&lt;TJH&gt;(strike)Submit&lt;/TJH&gt; =
I-D=20
  on LDAPv3 Replication Information Transport Protocol.<BR><SPAN=20
  class=3D428094621-05112001><FONT face=3DArial =
color=3D#0000ff>[Christopher=20
  Apple]&nbsp;&nbsp;You are correct. My error.&nbsp;Change=20
  made.</FONT></SPAN></FONT></TT></DIV>
  <DIV><TT><FONT size=3D2><SPAN =
class=3D428094621-05112001></SPAN></FONT></TT><SPAN=20
  class=3D428094621-05112001><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN><BR><FONT =
size=3D2><TT>&lt;TJH&gt;</TT></FONT>=20
  <BR><FONT size=3D2><TT>Nov 01 &nbsp; &nbsp; &nbsp; &nbsp;Revise I-D on =
LDAPv3=20
  Replication Information Model.<BR>&lt;/TJH&gt;</TT></FONT> <BR><SPAN=20
  class=3D428094621-05112001><FONT face=3DArial color=3D#0000ff =
size=3D2>[Christopher=20
  Apple]&nbsp;My error. Apologize for the omission. Change=20
  made.</FONT></SPAN><SPAN =
class=3D428094621-05112001>&nbsp;</SPAN><BR><BR><FONT=20
  size=3D2><TT>Nov 01 &nbsp; &nbsp; &nbsp; &nbsp;Revise I-D on General =
LDUP Usage=20
  Profile.<BR></TT></FONT><BR><FONT size=3D2><TT>Nov 01 &nbsp; &nbsp; =
&nbsp;=20
  &nbsp;Revise I-D on LDAPv3 Mandatory Replica=20
  Management.<BR></TT></FONT><BR><FONT size=3D2><TT>Dec 01 &nbsp; &nbsp; =
&nbsp;=20
  &nbsp;LDAPv3 Client Update Protocol I-D goes to WG Last Call =
as<BR>Proposed=20
  Standard.<BR></TT></FONT><BR><FONT size=3D2><TT>Feb 02 &nbsp; &nbsp; =
&nbsp;=20
  &nbsp;LDAPv3 Replication Architecture I-D goes to WG Last Call=20
  as<BR>Informational.<BR></TT></FONT><BR><FONT size=3D2><TT>Mar 02 =
&nbsp; &nbsp;=20
  &nbsp; &nbsp;LDAPv3 Update Reconciliation Procedures I-D goes to WG =
Last=20
  Call<BR>as Proposed Standard.<BR></TT></FONT><BR><FONT =
size=3D2><TT>Mar 02=20
  &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Mandatory Replica Management I-D =
goes to WG=20
  Last Call as<BR>Proposed Standard.<BR></TT></FONT><BR><FONT =
size=3D2><TT>Mar 02=20
  &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Replication Information Model I-D =
goes to WG=20
  Last Call as<BR>Proposed Standard.<BR></TT></FONT><BR><FONT =
size=3D2><TT>Mar 02=20
  &nbsp; &nbsp; &nbsp; &nbsp;LDAPv3 Replication Information Transport =
Protocol=20
  I-D goes to WG<BR>Last Call as Proposed =
Standard.<BR></TT></FONT><BR><FONT=20
  size=3D2><TT>Mar 02 &nbsp; &nbsp; &nbsp; &nbsp;Re-evaluate Charter and =

  Milestones.<BR></TT></FONT><BR><BR><BR><FONT face=3Dsans-serif=20
  size=3D2>Regards,<BR>Tim Hahn<BR><BR>Internet: =
hahnt@us.ibm.com<BR>Internal:=20
  Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<BR>phone: =
607.752.6388=20
  &nbsp; &nbsp; tie-line: 8/852.6388<BR>fax:=20
607.752.3681<BR></DIV></BLOCKQUOTE></FONT></BODY></HTML>

------=_NextPart_002_0005_01C1661A.01564B60--

------=_NextPart_001_0004_01C1661A.01564B60
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_0004_01C1661A.01564B60--

------=_NextPart_000_0003_01C1661A.01564B60
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwNTIxNTA0MlowIwYJKoZIhvcNAQkEMRYEFMPDWyimU9ua
ZLDG16kxU9/ZIcgFMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAbpgeLxJhdyfmuVLAA1pvK/3Y
ZTeQTR9AbFBiMM91S0xXLfOSfXsEHG1cyyCPacYlzn+D0bsYZj8f38SUcynM8IuzplYcNKIkeR0c
2yR8aLwsn+ahwEP0wch8hq7Pk3EtFoCDp2JFXSk4wJu6VJJnH0475/hOqdS3Eaj7bXnIuZ8AAAAA
AAA=

------=_NextPart_000_0003_01C1661A.01564B60--



From owner-ietf-ldup@mail.imc.org  Mon Nov  5 20:48:59 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12252
	for <ldup-archive@odin.ietf.org>; Mon, 5 Nov 2001 20:48:59 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA61RR421008
	for ietf-ldup-bks; Mon, 5 Nov 2001 17:27:27 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA61RP821004
	for <ietf-ldup@imc.org>; Mon, 5 Nov 2001 17:27:25 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fA61VtC84459;
	Tue, 6 Nov 2001 01:31:56 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011102164743.017dd648@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 05 Nov 2001 17:27:02 -0800
To: Bruce Greenblatt <bgreenblatt@directory-applications.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: WG Last Call: LDAPv3 Operation Framing and Grouping Drafts
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>
In-Reply-To: <5.1.0.14.0.20011102153723.00a8dbd0@mail.dtasi.com>
References: <504D6456F0C87F4C8B11FB0C2021D6F602DACF3F@ex04.ummail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 03:39 PM 2001-11-02, Bruce Greenblatt wrote:
>At 01:09 PM 11/2/2001 -0800, Christopher Apple wrote:
>>The purpose of this message is to initiate the LDUP
>>working group last call on two documents:
>>
>>1) Profile for Framing LDAPv3 Operations
>>
>>2) LDAPv3: Grouping of Related Operations
>
>Just out of curiosity, what LDAP server vendors are planning on supporting the functions supplied by these drafts/

Both of these I-Ds provide mechanisms for future functions,
including LDUP (uses framing), Transactions (uses grouping),
and Proxy Authorization (uses grouping).  Given this WG
existence, I assume there are multiple vendors interested
in implementing LDUP.  I have heard significant interest
expressed by vendors in Transactions (using grouping).  As
a Proxy Authorization (using grouping) I-D hasn't been
written, I won't bothered to gauge interest yet. 

Kurt



From owner-ietf-ldup@mail.imc.org  Tue Nov  6 22:32:49 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11084
	for <ldup-archive@odin.ietf.org>; Tue, 6 Nov 2001 22:32:49 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA734mx16893
	for ietf-ldup-bks; Tue, 6 Nov 2001 19:04:48 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA734l816889
	for <ietf-ldup@imc.org>; Tue, 6 Nov 2001 19:04:47 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fA739JC89373;
	Wed, 7 Nov 2001 03:09:19 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011106180143.0177fad8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 06 Nov 2001 19:04:21 -0800
To: Christopher Apple <christopher.apple@UnitedMessaging.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Revised WG Charter Proposal
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)" <john.strassner@intelliden.com>
In-Reply-To: <504D6456F0C87F4C8B11FB0C2021D6F602DACF5C@ex04.ummail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


I am convinced the WG will need to extend the X.500 models
in order to deliver a multi-master replication specification
which meets the WG requirements.  This activity does not
appear to be presently within scope of the current or proposed
charter.  As the issue of whether this work is within scope or
not has come up previously, I believe the charter should be
clarified in this area.

If the consensus is this work is within scope, I suggest:

  This WG will deliver a technical specification updates the
  X.500 models used by LDAP to support multi-master replication
  yet maintain consistency with the existing models when
  restricted to single-master replication.

otherwise I suggest:
  This WG will deliver specifications which extend, but do
  not update or replace, the X.500 models used by LDAP.

Note that I believe that this work is not within scope and
should remain so and hence recommend the latter clarification.

Kurt



From owner-ietf-ldup@mail.imc.org  Wed Nov  7 23:03:12 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02096
	for <ldup-archive@odin.ietf.org>; Wed, 7 Nov 2001 23:03:11 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA83iCZ26685
	for ietf-ldup-bks; Wed, 7 Nov 2001 19:44:12 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.23])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA83iB826681
	for <ietf-ldup@imc.org>; Wed, 7 Nov 2001 19:44:11 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id W1107-2244-624600;
	Thu, 8 Nov 2001 03:44:02 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V6221QC6>; Wed, 7 Nov 2001 22:41:11 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF67@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)"
	 <john.strassner@intelliden.com>
Subject: RE: Revised WG Charter Proposal
Date: Wed, 7 Nov 2001 22:41:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0000_01C167DD.2DDFF590"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C167DD.2DDFF590
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0001_01C167DD.2DE302D0"


------=_NextPart_001_0001_01C167DD.2DE302D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Kurt,

This text to me sounds like its attempting to
write in liaison activities between the IETF
LDUP WG and the ITU. Such text is clearly out
of scope for any IETF WG according to our ADs
given that there is an official liaison between
the IETF and the ITU.

These sorts of concerns should be explicitly
addressed via the person who currently
occupies that role within the IESG. I can
certainly supply this information to that
person or you can - please let John and I
know which way you'd prefer that be handled.

With that said, while it is not appropriate
to write in such liaison activities without
an explicit requirement from our ADs/the IESG
to do so, it would be appropriate to discuss
the technical merit of both approaches during
the discussion around the soon-to-be-published
revision of the General Usage Profile draft.

The General Usage Profile draft will contain
information about multi-master replication.

Similarly, it would be appropriate to discuss
concerns over alignment (or lack thereof) of
any WG document while that document is being
actively discussed on the mailing list.

I cannot conceive a way to legitimately
add this text to the WG Charter given the
position of our ADs and the IETF in general
on liaison activities with other standards
bodies. 

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, November 06, 2001 10:04 PM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: Re: Revised WG Charter Proposal


I am convinced the WG will need to extend the X.500 models
in order to deliver a multi-master replication specification
which meets the WG requirements.  This activity does not
appear to be presently within scope of the current or proposed
charter.  As the issue of whether this work is within scope or
not has come up previously, I believe the charter should be
clarified in this area.

If the consensus is this work is within scope, I suggest:

  This WG will deliver a technical specification updates the
  X.500 models used by LDAP to support multi-master replication
  yet maintain consistency with the existing models when
  restricted to single-master replication.

otherwise I suggest:
  This WG will deliver specifications which extend, but do
  not update or replace, the X.500 models used by LDAP.

Note that I believe that this work is not within scope and
should remain so and hence recommend the latter clarification.

Kurt

------=_NextPart_001_0001_01C167DD.2DE302D0
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_0001_01C167DD.2DE302D0--

------=_NextPart_000_0000_01C167DD.2DDFF590
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwODAzNDAxOVowIwYJKoZIhvcNAQkEMRYEFDYAMQ+sIGAd
Tre/TrGcajpjO9s1MHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAoWm60g1ESsh8CUrvgtaywfZf
5Bhd7Me99NS5n/1crmPIQHyTYPns8U/dfasYCixT0jjHRaAAS+jpUdy10tX31Gji1nybtEawHWxT
RgAW6EGI6lPRvPL+VvuE7Jd1T403iAEVy1aokef8kwY88XWH2+kGo8e/XNCGt0cF/aqoaaIAAAAA
AAA=

------=_NextPart_000_0000_01C167DD.2DDFF590--



From owner-ietf-ldup@mail.imc.org  Wed Nov  7 23:55:16 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03088
	for <ldup-archive@odin.ietf.org>; Wed, 7 Nov 2001 23:55:16 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA84a2w28310
	for ietf-ldup-bks; Wed, 7 Nov 2001 20:36:02 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA84a1828306
	for <ietf-ldup@imc.org>; Wed, 7 Nov 2001 20:36:01 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fA84egC93840;
	Thu, 8 Nov 2001 04:40:42 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011107201209.016b00d0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 20:35:38 -0800
To: Christopher Apple <christopher.apple@UnitedMessaging.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: Revised WG Charter Proposal
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)" <john.strassner@intelliden.com>
In-Reply-To: <504D6456F0C87F4C8B11FB0C2021D6F602DACF67@ex04.ummail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 07:41 PM 2001-11-07, Christopher Apple wrote:
>This text to me sounds like its attempting to
>write in liaison activities between the IETF
>LDUP WG and the ITU.

No.

I am attempting to add text to the charter which
clarifies whether or not redefining the "X.500
data model as used by LDAP" [RFC2251, Section 3.2
& 3.3] is within scope or not of this working group.

As chair, what is your opinion?
Can this WG (under its present charter or the proposed
charter) redefine the "X.500 data model as used
by LDAP" or not?

Kurt





From owner-ietf-ldup@mail.imc.org  Thu Nov  8 00:43:51 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03887
	for <ldup-archive@odin.ietf.org>; Thu, 8 Nov 2001 00:43:50 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA85PNA29796
	for ietf-ldup-bks; Wed, 7 Nov 2001 21:25:23 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA85PL829791
	for <ietf-ldup@imc.org>; Wed, 7 Nov 2001 21:25:21 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fA85TxC93952;
	Thu, 8 Nov 2001 05:29:59 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011107210928.016afdc0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Nov 2001 21:24:54 -0800
To: Christopher Apple <christopher.apple@UnitedMessaging.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Revised WG Charter Proposal
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)" <john.strassner@intelliden.com>
In-Reply-To: <504D6456F0C87F4C8B11FB0C2021D6F602DACF5C@ex04.ummail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


I suggest striking all the "REVISE" milestones... and
replacing all "WG Last Call" milestones with "Recommend
to the IESG for consideration as a ...".   From past
experience, each document has multiple WG Last Calls...
it's successfully completely the WG Last Call and
progressing the I-D that counts.

And I suggest the last milestone be:
        Revise charter or conclude
as "Re-evaluate Charter and Milestones" doesn't sound like
much of a commitment to successfully conclude.

At 12:30 PM 2001-11-05, Christopher Apple wrote:
>Based on input from document editors and a little editing from me,
>please review the following. The open review period of this begins
>today, Monday, November 5, 2001 and will last for 7 days.
>
>The review period therefore ends on Monday, November 12, 2001.
>
>Silence equals consent. This will be sent to the ADs for review
>subject to incorporation of comments sent, discussed, and
>vetted on the WG mailing list shortly after November 12, 2001.
>
>LDAP Duplication/Replication/Update Protocols (ldup) 
>
>Last Modified: 05-Nov-01 
>
>Chair(s):
>
>Chris Apple <christopher.apple@unitedmessaging.com>
>John Strassner <john.strassner@intelliden.com>
>
>Applications Area Director(s): 
>
>Ned Freed <ned.freed@mrochek.com>
>Patrik Faltstrom <paf@cisco.com>
>
>Applications Area Advisor: 
>
>Patrik Faltstrom <paf@cisco.com>
>
>Mailing Lists:
> 
>General Discussion:ietf-ldup@imc.org 
>To Subscribe: ietf-ldup-request@imc.org 
>In Body: subscribe 
>Archive: http://www.imc.org/ietf-ldup/ 
>
>Description of Working Group:
> 
>As LDAPv3 becomes more widely deployed, replication of data across
>servers running different implementations becomes an important part
>of providing a distributed directory service. However, the LDAPv3
>community, to date, has focused on standardizing the client-server
>access protocol. Therefore, this group will standardize master-slave
>and multi-master LDAPv3 replication as defined below: 
>
>o Multi-Master Replication - A replication model where entries can
>  be written and updated on any of several replica copies, without
>  requiring communication with other masters before the write or
>  update is performed. 
>
>o Master-Slave, or Single-Master Replication - A replication model
>  that assumes only one server, the master, allows write access to
>  the replicated data. Note that Master-Slave replication can be
>  considered a proper subset of multi-master replication. 
>
>The WG's approach is to first develop a set of requirements for
>LDAPv3 directory replication and write an applicability statement
>defining scenarios on which replication requirements are based.
>An engineering team was formed consisting of different vendors
>and the co-chairs in order to harmonize the existing approaches
>into a single standard approach. All of these have been accomplished
>during the pre-working group stage. It should be noted, however,
>that replication using heterogeneous servers is dependent on
>resolving access control issues, which are the domain of other
>working groups. Should these issues not be resolved outside of
>the LDUP WG in a timely manner relative to the WG's needs, the
>WG will be re-chartered subject to Applications AD/IESG approval
>to include the minimum required work.
>
>The new replication architecture support all forms of replication
>mentioned above. Seven areas of working group focus have been
>identified through LDUP Engineering Team discussions, each leading
>to one or more Engineering Team discussions, each leading to one
>or more documents to be published: 
>
>o LDAPv3 Replication Architecture 
>
>   This documents a general-purpose LDAPv3 replication architecture,
>   defines key components of this architecture, describes how these
>   key components functionally behave, and describes how these
>   components interact with each other when in various modes of
>   operation. 
>
>o LDAPv3 Replication Information Model 
>
>   Defines the schema and semantics of information used to operate,
>   administer, maintain, and provision replication between LDAPv3
>   servers. Specifically, this document will contain common schema
>   specifications intended to facilitate interoperable
>   implementations with respect to: 
>
>      + replication agreements 
>
>      + consistency models 
>
>      + replication topologies 
>
>      + managing deleted objects and their states 
>
>      + administration and management 
>
>o LDAPv3 Replication Information Transport Protocol 
>
>   LDAPv3 extended operation and control specifications required to
>   allow LDAPv3 to be used as the transport protocol for information
>   being replicated 
>
>o LDAPv3 Mandatory Replica Management 
>
>   Specifications required to allow administration, maintenance, and
>   provisioning of replicas and replication agreements. These
>   specifications may take the form of definitions for LDAPv3
>   extended operations, controls, and/or new schema elements. 
>
>o LDAPv3 Update Reconciliation Procedures 
>
>   Procedures for detection and resolution of conflicts between the
>   state of multiple replicas that contain information from the same
>   unit of replication. 
>
>o LDAPv3 Replication Usage Profile 
>
>   Including the LDAPv3 Replication Architecture, Information Model,
>   Protocol Extensions, and Update Reconciliation Procedures for: 
>
>      + LDAPv3 Master-Slave Directory Replication 
>
>      + LDAPv3 Multi-Master Directory Replication 
>
>o LDAPv3 Client Update 
>
>   A protocol that enables an LDAP client to synchronize with the
>   content of a directory information tree (DIT) stored by an LDAP
>   server and to be notified about the changes to that content. 
>
>The work being done in the LDUP WG should be coordinated to the
>closest extent possible with similar work being done in the ITU.
>This is necessary both because LDAP depends on X.500 and because
>it makes sense from an operational perspective. 
>
>
>Goals and Milestones:
>
>Done    Submit I-D on LDAPv3 Directory Replication Requirements. 
>
>Done    Submit Internet-Draft on LDAPv3 Replication Information Model. 
>
>Done    Submit I-D on LDAPv3 Update Reconciliation Procedures. 
>
>Done    Revise I-D on LDAPv3 Directory Replication Requirements. 
>
>Done    Revise I-D on LDAPv3 Replication Architecture. 
>
>Done    Revise I-D on LDAPv3 Replication Architecture. 
>
>Done    Revise I-D on LDAPv3 Replication Information Model. 
>
>Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.
>
>
>Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
>Call as Informational.
>
>Done    Submit I-D on LDAPv3 Mandatory Replica Management.
>
>Done    Submit I-D on General LDUP Usage Profile.
>
>Done    Submit I-D on LDAPv3 Operations Framing.
>
>Oct 01  I-D on LDAPv3 Extended Operations for Framing goes to WG Last
>Call as Proposed Standard.
>
>Nov 01  Submit I-D on LDAPv3 Replication Information Transport Protocol.
>
>
>Nov 01  Revise I-D on General LDUP Usage Profile.
>
>Nov 01  Revise I-D on LDAPv3 Mandatory Replica Management.
>
>Dec 01  LDAPv3 Client Update Protocol I-D goes to WG Last Call as
>Proposed Standard. 
>
>Feb 02  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational. 
>
>Mar 02  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call
>as Proposed Standard.
>
>Mar 02  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Proposed Standard. 
>
>Mar 02  LDAPv3 Replication Information Model I-D goes to WG Last Call as
>Proposed Standard.
>
>Mar 02  LDAPv3 Replication Information Transport Protocol I-D goes to WG
>Last Call as Proposed Standard.
>
>Mar 02  Re-evaluate Charter and Milestones.
>
>Chris Apple
>Program Manager - Integration Services
>United Messaging Inc.
><http://www.unitedmessaging.com>
><mailto:christopher.apple@unitedmessaging.com> 
>(V) +1 610 425 2860
>



From owner-ietf-ldup@mail.imc.org  Thu Nov  8 10:42:43 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28798
	for <ldup-archive@odin.ietf.org>; Thu, 8 Nov 2001 10:42:42 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA8FJgw23220
	for ietf-ldup-bks; Thu, 8 Nov 2001 07:19:42 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8FJf823216
	for <ietf-ldup@imc.org>; Thu, 8 Nov 2001 07:19:41 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id S1108-1019-46af00;
	Thu, 8 Nov 2001 15:19:26 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V6221TQB>; Thu, 8 Nov 2001 10:16:33 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF6A@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)"
	 <john.strassner@intelliden.com>
Subject: RE: Revised WG Charter Proposal
Date: Thu, 8 Nov 2001 10:16:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0009_01C1683E.5418FF70"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C1683E.5418FF70
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_000A_01C1683E.541A8610"


------=_NextPart_001_000A_01C1683E.541A8610
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The use of the "REVISE" and "WG Last Call" milestones is consistent
with feedback we have received from the IESG/our ADs in the past.

I don't plan to try changing that now. If the IESG or our ADs
want to see milestones expressed in a different way, they will
change them accordingly prior to charter approval.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, November 08, 2001 12:25 AM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: Re: Revised WG Charter Proposal


I suggest striking all the "REVISE" milestones... and
replacing all "WG Last Call" milestones with "Recommend
to the IESG for consideration as a ...".   From past
experience, each document has multiple WG Last Calls...
it's successfully completely the WG Last Call and
progressing the I-D that counts.

And I suggest the last milestone be:
        Revise charter or conclude
as "Re-evaluate Charter and Milestones" doesn't sound like
much of a commitment to successfully conclude.

At 12:30 PM 2001-11-05, Christopher Apple wrote:
>Based on input from document editors and a little editing from me,
>please review the following. The open review period of this begins
>today, Monday, November 5, 2001 and will last for 7 days.
>
>The review period therefore ends on Monday, November 12, 2001.
>
>Silence equals consent. This will be sent to the ADs for review
>subject to incorporation of comments sent, discussed, and
>vetted on the WG mailing list shortly after November 12, 2001.
>
>LDAP Duplication/Replication/Update Protocols (ldup) 
>
>Last Modified: 05-Nov-01 
>
>Chair(s):
>
>Chris Apple <christopher.apple@unitedmessaging.com>
>John Strassner <john.strassner@intelliden.com>
>
>Applications Area Director(s): 
>
>Ned Freed <ned.freed@mrochek.com>
>Patrik Faltstrom <paf@cisco.com>
>
>Applications Area Advisor: 
>
>Patrik Faltstrom <paf@cisco.com>
>
>Mailing Lists:
> 
>General Discussion:ietf-ldup@imc.org 
>To Subscribe: ietf-ldup-request@imc.org 
>In Body: subscribe 
>Archive: http://www.imc.org/ietf-ldup/ 
>
>Description of Working Group:
> 
>As LDAPv3 becomes more widely deployed, replication of data across
>servers running different implementations becomes an important part
>of providing a distributed directory service. However, the LDAPv3
>community, to date, has focused on standardizing the client-server
>access protocol. Therefore, this group will standardize master-slave
>and multi-master LDAPv3 replication as defined below: 
>
>o Multi-Master Replication - A replication model where entries can
>  be written and updated on any of several replica copies, without
>  requiring communication with other masters before the write or
>  update is performed. 
>
>o Master-Slave, or Single-Master Replication - A replication model
>  that assumes only one server, the master, allows write access to
>  the replicated data. Note that Master-Slave replication can be
>  considered a proper subset of multi-master replication. 
>
>The WG's approach is to first develop a set of requirements for
>LDAPv3 directory replication and write an applicability statement
>defining scenarios on which replication requirements are based.
>An engineering team was formed consisting of different vendors
>and the co-chairs in order to harmonize the existing approaches
>into a single standard approach. All of these have been accomplished
>during the pre-working group stage. It should be noted, however,
>that replication using heterogeneous servers is dependent on
>resolving access control issues, which are the domain of other
>working groups. Should these issues not be resolved outside of
>the LDUP WG in a timely manner relative to the WG's needs, the
>WG will be re-chartered subject to Applications AD/IESG approval
>to include the minimum required work.
>
>The new replication architecture support all forms of replication
>mentioned above. Seven areas of working group focus have been
>identified through LDUP Engineering Team discussions, each leading
>to one or more Engineering Team discussions, each leading to one
>or more documents to be published: 
>
>o LDAPv3 Replication Architecture 
>
>   This documents a general-purpose LDAPv3 replication architecture,
>   defines key components of this architecture, describes how these
>   key components functionally behave, and describes how these
>   components interact with each other when in various modes of
>   operation. 
>
>o LDAPv3 Replication Information Model 
>
>   Defines the schema and semantics of information used to operate,
>   administer, maintain, and provision replication between LDAPv3
>   servers. Specifically, this document will contain common schema
>   specifications intended to facilitate interoperable
>   implementations with respect to: 
>
>      + replication agreements 
>
>      + consistency models 
>
>      + replication topologies 
>
>      + managing deleted objects and their states 
>
>      + administration and management 
>
>o LDAPv3 Replication Information Transport Protocol 
>
>   LDAPv3 extended operation and control specifications required to
>   allow LDAPv3 to be used as the transport protocol for information
>   being replicated 
>
>o LDAPv3 Mandatory Replica Management 
>
>   Specifications required to allow administration, maintenance, and
>   provisioning of replicas and replication agreements. These
>   specifications may take the form of definitions for LDAPv3
>   extended operations, controls, and/or new schema elements. 
>
>o LDAPv3 Update Reconciliation Procedures 
>
>   Procedures for detection and resolution of conflicts between the
>   state of multiple replicas that contain information from the same
>   unit of replication. 
>
>o LDAPv3 Replication Usage Profile 
>
>   Including the LDAPv3 Replication Architecture, Information Model,
>   Protocol Extensions, and Update Reconciliation Procedures for: 
>
>      + LDAPv3 Master-Slave Directory Replication 
>
>      + LDAPv3 Multi-Master Directory Replication 
>
>o LDAPv3 Client Update 
>
>   A protocol that enables an LDAP client to synchronize with the
>   content of a directory information tree (DIT) stored by an LDAP
>   server and to be notified about the changes to that content. 
>
>The work being done in the LDUP WG should be coordinated to the
>closest extent possible with similar work being done in the ITU.
>This is necessary both because LDAP depends on X.500 and because
>it makes sense from an operational perspective. 
>
>
>Goals and Milestones:
>
>Done    Submit I-D on LDAPv3 Directory Replication Requirements. 
>
>Done    Submit Internet-Draft on LDAPv3 Replication Information Model. 
>
>Done    Submit I-D on LDAPv3 Update Reconciliation Procedures. 
>
>Done    Revise I-D on LDAPv3 Directory Replication Requirements. 
>
>Done    Revise I-D on LDAPv3 Replication Architecture. 
>
>Done    Revise I-D on LDAPv3 Replication Architecture. 
>
>Done    Revise I-D on LDAPv3 Replication Information Model. 
>
>Done    Submit I-D on LDAPv3 Replication Information Transport
Protocol.
>
>
>Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
>Call as Informational.
>
>Done    Submit I-D on LDAPv3 Mandatory Replica Management.
>
>Done    Submit I-D on General LDUP Usage Profile.
>
>Done    Submit I-D on LDAPv3 Operations Framing.
>
>Oct 01  I-D on LDAPv3 Extended Operations for Framing goes to WG Last
>Call as Proposed Standard.
>
>Nov 01  Submit I-D on LDAPv3 Replication Information Transport
Protocol.
>
>
>Nov 01  Revise I-D on General LDUP Usage Profile.
>
>Nov 01  Revise I-D on LDAPv3 Mandatory Replica Management.
>
>Dec 01  LDAPv3 Client Update Protocol I-D goes to WG Last Call as
>Proposed Standard. 
>
>Feb 02  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational. 
>
>Mar 02  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last
Call
>as Proposed Standard.
>
>Mar 02  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Proposed Standard. 
>
>Mar 02  LDAPv3 Replication Information Model I-D goes to WG Last Call
as
>Proposed Standard.
>
>Mar 02  LDAPv3 Replication Information Transport Protocol I-D goes to
WG
>Last Call as Proposed Standard.
>
>Mar 02  Re-evaluate Charter and Milestones.
>
>Chris Apple
>Program Manager - Integration Services
>United Messaging Inc.
><http://www.unitedmessaging.com>
><mailto:christopher.apple@unitedmessaging.com> 
>(V) +1 610 425 2860
>

------=_NextPart_001_000A_01C1683E.541A8610
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_000A_01C1683E.541A8610--

------=_NextPart_000_0009_01C1683E.5418FF70
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwODE1MTU0NVowIwYJKoZIhvcNAQkEMRYEFI79UxbmRR6V
EwHVOGQvKO/3add2MHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAU5+KOv9RV7abt5S9DL7YRX74
GLKibsEi0aJKW+knweUsQpPzNW+UHWy5UQ0yXQ1NVCoQKNyeJvV8tkq2X1Yat2GZsdkLou3I0YcW
/d7yAcFYGgKqdyLZmS8J2ddHSjrCEyckTX4HnCl1rP2qu41+PJvhMkhOj9wNHIhEWnZXbvoAAAAA
AAA=

------=_NextPart_000_0009_01C1683E.5418FF70--



From owner-ietf-ldup@mail.imc.org  Thu Nov  8 10:44:13 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28833
	for <ldup-archive@odin.ietf.org>; Thu, 8 Nov 2001 10:44:12 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA8FNUm23347
	for ietf-ldup-bks; Thu, 8 Nov 2001 07:23:30 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8FNT823342
	for <ietf-ldup@imc.org>; Thu, 8 Nov 2001 07:23:29 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id N1108-1023-353e00;
	Thu, 8 Nov 2001 15:23:20 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V6221TRR>; Thu, 8 Nov 2001 10:20:28 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF6B@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "'John Strassner (E-mail)'"
	 <john.strassner@intelliden.com>
Subject: RE: Revised WG Charter Proposal
Date: Thu, 8 Nov 2001 10:20:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0014_01C1683E.DF9835C0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C1683E.DF9835C0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0015_01C1683E.DF9835C0"


------=_NextPart_001_0015_01C1683E.DF9835C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Same response on the other comment.

The language present in the milestones
section of the charter is the language
that the WG has been directed to use.

So I don't plan to re-word the last milestone
unless directed to do so by our ADs or the
IESG.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Christopher Apple 
Sent: Thursday, November 08, 2001 10:17 AM
To: 'Kurt D. Zeilenga'
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: RE: Revised WG Charter Proposal


The use of the "REVISE" and "WG Last Call" milestones is consistent
with feedback we have received from the IESG/our ADs in the past.

I don't plan to try changing that now. If the IESG or our ADs
want to see milestones expressed in a different way, they will
change them accordingly prior to charter approval.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, November 08, 2001 12:25 AM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: Re: Revised WG Charter Proposal


I suggest striking all the "REVISE" milestones... and
replacing all "WG Last Call" milestones with "Recommend
to the IESG for consideration as a ...".   From past
experience, each document has multiple WG Last Calls...
it's successfully completely the WG Last Call and
progressing the I-D that counts.

And I suggest the last milestone be:
        Revise charter or conclude
as "Re-evaluate Charter and Milestones" doesn't sound like
much of a commitment to successfully conclude.

At 12:30 PM 2001-11-05, Christopher Apple wrote:
>Based on input from document editors and a little editing from me,
>please review the following. The open review period of this begins
>today, Monday, November 5, 2001 and will last for 7 days.
>
>The review period therefore ends on Monday, November 12, 2001.
>
>Silence equals consent. This will be sent to the ADs for review
>subject to incorporation of comments sent, discussed, and
>vetted on the WG mailing list shortly after November 12, 2001.
>
>LDAP Duplication/Replication/Update Protocols (ldup) 
>
>Last Modified: 05-Nov-01 
>
>Chair(s):
>
>Chris Apple <christopher.apple@unitedmessaging.com>
>John Strassner <john.strassner@intelliden.com>
>
>Applications Area Director(s): 
>
>Ned Freed <ned.freed@mrochek.com>
>Patrik Faltstrom <paf@cisco.com>
>
>Applications Area Advisor: 
>
>Patrik Faltstrom <paf@cisco.com>
>
>Mailing Lists:
> 
>General Discussion:ietf-ldup@imc.org 
>To Subscribe: ietf-ldup-request@imc.org 
>In Body: subscribe 
>Archive: http://www.imc.org/ietf-ldup/ 
>
>Description of Working Group:
> 
>As LDAPv3 becomes more widely deployed, replication of data across
>servers running different implementations becomes an important part
>of providing a distributed directory service. However, the LDAPv3
>community, to date, has focused on standardizing the client-server
>access protocol. Therefore, this group will standardize master-slave
>and multi-master LDAPv3 replication as defined below: 
>
>o Multi-Master Replication - A replication model where entries can
>  be written and updated on any of several replica copies, without
>  requiring communication with other masters before the write or
>  update is performed. 
>
>o Master-Slave, or Single-Master Replication - A replication model
>  that assumes only one server, the master, allows write access to
>  the replicated data. Note that Master-Slave replication can be
>  considered a proper subset of multi-master replication. 
>
>The WG's approach is to first develop a set of requirements for
>LDAPv3 directory replication and write an applicability statement
>defining scenarios on which replication requirements are based.
>An engineering team was formed consisting of different vendors
>and the co-chairs in order to harmonize the existing approaches
>into a single standard approach. All of these have been accomplished
>during the pre-working group stage. It should be noted, however,
>that replication using heterogeneous servers is dependent on
>resolving access control issues, which are the domain of other
>working groups. Should these issues not be resolved outside of
>the LDUP WG in a timely manner relative to the WG's needs, the
>WG will be re-chartered subject to Applications AD/IESG approval
>to include the minimum required work.
>
>The new replication architecture support all forms of replication
>mentioned above. Seven areas of working group focus have been
>identified through LDUP Engineering Team discussions, each leading
>to one or more Engineering Team discussions, each leading to one
>or more documents to be published: 
>
>o LDAPv3 Replication Architecture 
>
>   This documents a general-purpose LDAPv3 replication architecture,
>   defines key components of this architecture, describes how these
>   key components functionally behave, and describes how these
>   components interact with each other when in various modes of
>   operation. 
>
>o LDAPv3 Replication Information Model 
>
>   Defines the schema and semantics of information used to operate,
>   administer, maintain, and provision replication between LDAPv3
>   servers. Specifically, this document will contain common schema
>   specifications intended to facilitate interoperable
>   implementations with respect to: 
>
>      + replication agreements 
>
>      + consistency models 
>
>      + replication topologies 
>
>      + managing deleted objects and their states 
>
>      + administration and management 
>
>o LDAPv3 Replication Information Transport Protocol 
>
>   LDAPv3 extended operation and control specifications required to
>   allow LDAPv3 to be used as the transport protocol for information
>   being replicated 
>
>o LDAPv3 Mandatory Replica Management 
>
>   Specifications required to allow administration, maintenance, and
>   provisioning of replicas and replication agreements. These
>   specifications may take the form of definitions for LDAPv3
>   extended operations, controls, and/or new schema elements. 
>
>o LDAPv3 Update Reconciliation Procedures 
>
>   Procedures for detection and resolution of conflicts between the
>   state of multiple replicas that contain information from the same
>   unit of replication. 
>
>o LDAPv3 Replication Usage Profile 
>
>   Including the LDAPv3 Replication Architecture, Information Model,
>   Protocol Extensions, and Update Reconciliation Procedures for: 
>
>      + LDAPv3 Master-Slave Directory Replication 
>
>      + LDAPv3 Multi-Master Directory Replication 
>
>o LDAPv3 Client Update 
>
>   A protocol that enables an LDAP client to synchronize with the
>   content of a directory information tree (DIT) stored by an LDAP
>   server and to be notified about the changes to that content. 
>
>The work being done in the LDUP WG should be coordinated to the
>closest extent possible with similar work being done in the ITU.
>This is necessary both because LDAP depends on X.500 and because
>it makes sense from an operational perspective. 
>
>
>Goals and Milestones:
>
>Done    Submit I-D on LDAPv3 Directory Replication Requirements. 
>
>Done    Submit Internet-Draft on LDAPv3 Replication Information Model. 
>
>Done    Submit I-D on LDAPv3 Update Reconciliation Procedures. 
>
>Done    Revise I-D on LDAPv3 Directory Replication Requirements. 
>
>Done    Revise I-D on LDAPv3 Replication Architecture. 
>
>Done    Revise I-D on LDAPv3 Replication Architecture. 
>
>Done    Revise I-D on LDAPv3 Replication Information Model. 
>
>Done    Submit I-D on LDAPv3 Replication Information Transport
Protocol.
>
>
>Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
>Call as Informational.
>
>Done    Submit I-D on LDAPv3 Mandatory Replica Management.
>
>Done    Submit I-D on General LDUP Usage Profile.
>
>Done    Submit I-D on LDAPv3 Operations Framing.
>
>Oct 01  I-D on LDAPv3 Extended Operations for Framing goes to WG Last
>Call as Proposed Standard.
>
>Nov 01  Submit I-D on LDAPv3 Replication Information Transport
Protocol.
>
>
>Nov 01  Revise I-D on General LDUP Usage Profile.
>
>Nov 01  Revise I-D on LDAPv3 Mandatory Replica Management.
>
>Dec 01  LDAPv3 Client Update Protocol I-D goes to WG Last Call as
>Proposed Standard. 
>
>Feb 02  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational. 
>
>Mar 02  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last
Call
>as Proposed Standard.
>
>Mar 02  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Proposed Standard. 
>
>Mar 02  LDAPv3 Replication Information Model I-D goes to WG Last Call
as
>Proposed Standard.
>
>Mar 02  LDAPv3 Replication Information Transport Protocol I-D goes to
WG
>Last Call as Proposed Standard.
>
>Mar 02  Re-evaluate Charter and Milestones.
>
>Chris Apple
>Program Manager - Integration Services
>United Messaging Inc.
><http://www.unitedmessaging.com>
><mailto:christopher.apple@unitedmessaging.com> 
>(V) +1 610 425 2860
>

------=_NextPart_001_0015_01C1683E.DF9835C0
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_0015_01C1683E.DF9835C0--

------=_NextPart_000_0014_01C1683E.DF9835C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwODE1MTkzOVowIwYJKoZIhvcNAQkEMRYEFM+w+hDz8+Ro
9sEMAPp1QPDfqJKjMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAsPVpG5CMF9/fmAt2XD32KfWa
ILrURV3+vZOGHpo3C3ArmKXHgFklrL6Yh4EKjChpiW551imjr6LkVjd41aWU4GY2qtbJCu9NYj4j
xWhonUWDvsBC15RIAP0M0KwE9EPs15DXf9N/t6EH3/rpFinucBZQgW/gC/AvTyDP4b1fyJAAAAAA
AAA=

------=_NextPart_000_0014_01C1683E.DF9835C0--



From owner-ietf-ldup@mail.imc.org  Thu Nov  8 10:53:26 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29000
	for <ldup-archive@odin.ietf.org>; Thu, 8 Nov 2001 10:53:25 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA8FXU723657
	for ietf-ldup-bks; Thu, 8 Nov 2001 07:33:30 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.19])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8FXT823653
	for <ietf-ldup@imc.org>; Thu, 8 Nov 2001 07:33:29 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id K1108-1033-705600;
	Thu, 8 Nov 2001 15:33:16 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V6221TVJ>; Thu, 8 Nov 2001 10:30:24 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF6D@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)"
	 <john.strassner@intelliden.com>
Subject: RE: Revised WG Charter Proposal
Date: Thu, 8 Nov 2001 10:30:23 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0000_01C16840.42572E90"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C16840.42572E90
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0001_01C16840.42572E90"


------=_NextPart_001_0001_01C16840.42572E90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Since there is nothing explicitly in the charter
about this, I suppose it would be logical to say
that it is not explicitly prohibited.

With that said, I'm sure that there would be significant
and quite heated debate on the topic if there was a document
which did propose that the model you are referring to
be altered in a way that is not somehow compatible with
the currently published RFC.

There would have to be consensus that such a thing is
a good idea.

I am uncertain as to what specifically has led you to
raise the issue though. Please elaborate on your concerns.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, November 07, 2001 11:36 PM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: RE: Revised WG Charter Proposal


At 07:41 PM 2001-11-07, Christopher Apple wrote:
>This text to me sounds like its attempting to
>write in liaison activities between the IETF
>LDUP WG and the ITU.

No.

I am attempting to add text to the charter which
clarifies whether or not redefining the "X.500
data model as used by LDAP" [RFC2251, Section 3.2
& 3.3] is within scope or not of this working group.

As chair, what is your opinion?
Can this WG (under its present charter or the proposed
charter) redefine the "X.500 data model as used
by LDAP" or not?

Kurt



------=_NextPart_001_0001_01C16840.42572E90
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_0001_01C16840.42572E90--

------=_NextPart_000_0000_01C16840.42572E90
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwODE1MjkzNFowIwYJKoZIhvcNAQkEMRYEFD3qLSGceSpx
ZEyRIylcN6v/v6h+MHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAdxhxBdDPn/9SAz3U9IHeG87t
2EDPJZSXg/SZoV8LiDsAVOto56yVjx2FuPIksI/2E9h3QwSnA6F6P//ilmqTp+xNYjPyDpQo0ua/
8WFC7bcHjyu8clVuhNX/fWUwjT2uKyOG+6Uj0wJ5CWHTCyCl0riZkiA4mxnsXab61v0BFrQAAAAA
AAA=

------=_NextPart_000_0000_01C16840.42572E90--



From owner-ietf-ldup@mail.imc.org  Thu Nov  8 11:30:25 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29948
	for <ldup-archive@odin.ietf.org>; Thu, 8 Nov 2001 11:30:24 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA8GAHm00118
	for ietf-ldup-bks; Thu, 8 Nov 2001 08:10:17 -0800 (PST)
Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8GA9800112
	for <ietf-ldup@imc.org>; Thu, 8 Nov 2001 08:10:09 -0800 (PST)
Received: from sdn-ar-004cocsprp122.dialsprint.net ([158.252.163.186] helo=FARILJCS)
	by scaup.prod.itd.earthlink.net with smtp (Exim 3.33 #1)
	id 161rka-0002He-00; Thu, 08 Nov 2001 08:09:56 -0800
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        "Christopher Apple" <christopher.apple@UnitedMessaging.net>
Cc: <ietf-ldup@imc.org>
Subject: RE: Revised WG Charter Proposal
Date: Thu, 8 Nov 2001 09:09:53 -0700
MIME-Version: 1.0
Message-ID: <FCEKLEHMPIHFNLCMKHAMKELPCOAA.john.strassner@intelliden.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.1.0.14.0.20011107210928.016afdc0@127.0.0.1>
Importance: Normal
Content-Type: multipart/signed;
	micalg=SHA1;
	boundary="----=_NextPart_000_00EC_01C16835.1E6140D0";
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_00EC_01C16835.1E6140D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kurt,

there are many different WGs that use "REVISE" as well as many different
WGs that use "WG Last Call". Furthermore, this wording is consistent with
current practice.

I do agree with your suggested change to the last milestone.

regards,
John

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga
Sent: Wednesday, November 07, 2001 10:25 PM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: Re: Revised WG Charter Proposal



I suggest striking all the "REVISE" milestones... and
replacing all "WG Last Call" milestones with "Recommend
to the IESG for consideration as a ...".   From past
experience, each document has multiple WG Last Calls...
it's successfully completely the WG Last Call and
progressing the I-D that counts.

And I suggest the last milestone be:
        Revise charter or conclude
as "Re-evaluate Charter and Milestones" doesn't sound like
much of a commitment to successfully conclude.

At 12:30 PM 2001-11-05, Christopher Apple wrote:
>Based on input from document editors and a little editing from me,
>please review the following. The open review period of this begins
>today, Monday, November 5, 2001 and will last for 7 days.
>
>The review period therefore ends on Monday, November 12, 2001.
>
>Silence equals consent. This will be sent to the ADs for review
>subject to incorporation of comments sent, discussed, and
>vetted on the WG mailing list shortly after November 12, 2001.
>
>LDAP Duplication/Replication/Update Protocols (ldup)
>
>Last Modified: 05-Nov-01
>
>Chair(s):
>
>Chris Apple <christopher.apple@unitedmessaging.com>
>John Strassner <john.strassner@intelliden.com>
>
>Applications Area Director(s):
>
>Ned Freed <ned.freed@mrochek.com>
>Patrik Faltstrom <paf@cisco.com>
>
>Applications Area Advisor:
>
>Patrik Faltstrom <paf@cisco.com>
>
>Mailing Lists:
>
>General Discussion:ietf-ldup@imc.org
>To Subscribe: ietf-ldup-request@imc.org
>In Body: subscribe
>Archive: http://www.imc.org/ietf-ldup/
>
>Description of Working Group:
>
>As LDAPv3 becomes more widely deployed, replication of data across
>servers running different implementations becomes an important part
>of providing a distributed directory service. However, the LDAPv3
>community, to date, has focused on standardizing the client-server
>access protocol. Therefore, this group will standardize master-slave
>and multi-master LDAPv3 replication as defined below:
>
>o Multi-Master Replication - A replication model where entries can
>  be written and updated on any of several replica copies, without
>  requiring communication with other masters before the write or
>  update is performed.
>
>o Master-Slave, or Single-Master Replication - A replication model
>  that assumes only one server, the master, allows write access to
>  the replicated data. Note that Master-Slave replication can be
>  considered a proper subset of multi-master replication.
>
>The WG's approach is to first develop a set of requirements for
>LDAPv3 directory replication and write an applicability statement
>defining scenarios on which replication requirements are based.
>An engineering team was formed consisting of different vendors
>and the co-chairs in order to harmonize the existing approaches
>into a single standard approach. All of these have been accomplished
>during the pre-working group stage. It should be noted, however,
>that replication using heterogeneous servers is dependent on
>resolving access control issues, which are the domain of other
>working groups. Should these issues not be resolved outside of
>the LDUP WG in a timely manner relative to the WG's needs, the
>WG will be re-chartered subject to Applications AD/IESG approval
>to include the minimum required work.
>
>The new replication architecture support all forms of replication
>mentioned above. Seven areas of working group focus have been
>identified through LDUP Engineering Team discussions, each leading
>to one or more Engineering Team discussions, each leading to one
>or more documents to be published:
>
>o LDAPv3 Replication Architecture
>
>   This documents a general-purpose LDAPv3 replication architecture,
>   defines key components of this architecture, describes how these
>   key components functionally behave, and describes how these
>   components interact with each other when in various modes of
>   operation.
>
>o LDAPv3 Replication Information Model
>
>   Defines the schema and semantics of information used to operate,
>   administer, maintain, and provision replication between LDAPv3
>   servers. Specifically, this document will contain common schema
>   specifications intended to facilitate interoperable
>   implementations with respect to:
>
>      + replication agreements
>
>      + consistency models
>
>      + replication topologies
>
>      + managing deleted objects and their states
>
>      + administration and management
>
>o LDAPv3 Replication Information Transport Protocol
>
>   LDAPv3 extended operation and control specifications required to
>   allow LDAPv3 to be used as the transport protocol for information
>   being replicated
>
>o LDAPv3 Mandatory Replica Management
>
>   Specifications required to allow administration, maintenance, and
>   provisioning of replicas and replication agreements. These
>   specifications may take the form of definitions for LDAPv3
>   extended operations, controls, and/or new schema elements.
>
>o LDAPv3 Update Reconciliation Procedures
>
>   Procedures for detection and resolution of conflicts between the
>   state of multiple replicas that contain information from the same
>   unit of replication.
>
>o LDAPv3 Replication Usage Profile
>
>   Including the LDAPv3 Replication Architecture, Information Model,
>   Protocol Extensions, and Update Reconciliation Procedures for:
>
>      + LDAPv3 Master-Slave Directory Replication
>
>      + LDAPv3 Multi-Master Directory Replication
>
>o LDAPv3 Client Update
>
>   A protocol that enables an LDAP client to synchronize with the
>   content of a directory information tree (DIT) stored by an LDAP
>   server and to be notified about the changes to that content.
>
>The work being done in the LDUP WG should be coordinated to the
>closest extent possible with similar work being done in the ITU.
>This is necessary both because LDAP depends on X.500 and because
>it makes sense from an operational perspective.
>
>
>Goals and Milestones:
>
>Done    Submit I-D on LDAPv3 Directory Replication Requirements.
>
>Done    Submit Internet-Draft on LDAPv3 Replication Information Model.
>
>Done    Submit I-D on LDAPv3 Update Reconciliation Procedures.
>
>Done    Revise I-D on LDAPv3 Directory Replication Requirements.
>
>Done    Revise I-D on LDAPv3 Replication Architecture.
>
>Done    Revise I-D on LDAPv3 Replication Architecture.
>
>Done    Revise I-D on LDAPv3 Replication Information Model.
>
>Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.
>
>
>Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
>Call as Informational.
>
>Done    Submit I-D on LDAPv3 Mandatory Replica Management.
>
>Done    Submit I-D on General LDUP Usage Profile.
>
>Done    Submit I-D on LDAPv3 Operations Framing.
>
>Oct 01  I-D on LDAPv3 Extended Operations for Framing goes to WG Last
>Call as Proposed Standard.
>
>Nov 01  Submit I-D on LDAPv3 Replication Information Transport Protocol.
>
>
>Nov 01  Revise I-D on General LDUP Usage Profile.
>
>Nov 01  Revise I-D on LDAPv3 Mandatory Replica Management.
>
>Dec 01  LDAPv3 Client Update Protocol I-D goes to WG Last Call as
>Proposed Standard.
>
>Feb 02  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational.
>
>Mar 02  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call
>as Proposed Standard.
>
>Mar 02  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Proposed Standard.
>
>Mar 02  LDAPv3 Replication Information Model I-D goes to WG Last Call as
>Proposed Standard.
>
>Mar 02  LDAPv3 Replication Information Transport Protocol I-D goes to WG
>Last Call as Proposed Standard.
>
>Mar 02  Re-evaluate Charter and Milestones.
>
>Chris Apple
>Program Manager - Integration Services
>United Messaging Inc.
><http://www.unitedmessaging.com>
><mailto:christopher.apple@unitedmessaging.com>
>(V) +1 610 425 2860
>


------=_NextPart_000_00EC_01C16835.1E6140D0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTEwODE2MDk0OVowIwYJKoZIhvcNAQkEMRYEFBnNrWER8jcWCZsrqTIUKZPDkqUo
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAktV0
RTbWBVLh8Hxn2gCv24s4tciLFC/U+sA2mGIX7FeXjrwOeNV9vy27gl/Y1gCRLPIgxi6S1Pwhom95
UAzKYIoIPjTBqoxWHcKZh/rbftSmR9mz7exhB+mLJH6Lkev11kD2NffWfXIJFO7MI11DZGKFGnIZ
0BtR5sC/oHvcHncAAAAAAAA=

------=_NextPart_000_00EC_01C16835.1E6140D0--



From owner-ietf-ldup@mail.imc.org  Thu Nov  8 12:55:40 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02680
	for <ldup-archive@odin.ietf.org>; Thu, 8 Nov 2001 12:55:39 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fA8HSam03955
	for ietf-ldup-bks; Thu, 8 Nov 2001 09:28:36 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8HSY803948
	for <ietf-ldup@imc.org>; Thu, 8 Nov 2001 09:28:35 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fA8HXFC95544;
	Thu, 8 Nov 2001 17:33:15 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011108073506.017cc728@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 08 Nov 2001 09:28:09 -0800
To: Christopher Apple <christopher.apple@UnitedMessaging.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: Revised WG Charter Proposal
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)" <john.strassner@intelliden.com>
In-Reply-To: <504D6456F0C87F4C8B11FB0C2021D6F602DACF6D@ex04.ummail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 07:30 AM 2001-11-08, Christopher Apple wrote:
>I am uncertain as to what specifically has led you to
>raise the issue though. Please elaborate on your concerns.

I'm concerned that the charter doesn't reflect the scope
of the work this group will have to undertake to be successful.

It seems that this WG has not yet reached consensus on whether
or not the WG needs make "redefine X.500 models used by LDAP"
in order to deliver "multi-master replication" meeting its
requirements. 

The problem is that if the WG chooses to "redefine X.500 models
used by LDAP" it likely will run into significant contention (as
you noted).  And, if it chooses not to "redefine X.500 models used
by LDAP" it likely won't be able to deliver multiple-master
replication meeting its own requirements.

I rather address this issue sooner than later.  Later may be
too late.

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Nov  8 16:37:51 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08612
	for <ldup-archive@odin.ietf.org>; Thu, 8 Nov 2001 16:37:50 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fA8LJ5n17858
	for ietf-ldup-bks; Thu, 8 Nov 2001 13:19:05 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8LJ4817854
	for <ietf-ldup@imc.org>; Thu, 8 Nov 2001 13:19:04 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id K1108-1618-2fa300;
	Thu, 8 Nov 2001 21:18:58 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V6221X99>; Thu, 8 Nov 2001 16:16:05 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF70@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: "'ietf-ldup@imc.org'" <ietf-ldup@imc.org>,
        "John Strassner (E-mail)"
	 <john.strassner@intelliden.com>
Subject: RE: Revised WG Charter Proposal
Date: Thu, 8 Nov 2001 16:16:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_001B_01C16870.8E7CBD50"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C16870.8E7CBD50
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_001C_01C16870.8E7CBD50"


------=_NextPart_001_001C_01C16870.8E7CBD50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I believe that's a technical issue to be sorted out by the
WG as it discusses relevant drafts which may seek to go one
way or the other.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, November 08, 2001 12:28 PM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: RE: Revised WG Charter Proposal


At 07:30 AM 2001-11-08, Christopher Apple wrote:
>I am uncertain as to what specifically has led you to
>raise the issue though. Please elaborate on your concerns.

I'm concerned that the charter doesn't reflect the scope
of the work this group will have to undertake to be successful.

It seems that this WG has not yet reached consensus on whether
or not the WG needs make "redefine X.500 models used by LDAP"
in order to deliver "multi-master replication" meeting its
requirements. 

The problem is that if the WG chooses to "redefine X.500 models
used by LDAP" it likely will run into significant contention (as
you noted).  And, if it chooses not to "redefine X.500 models used
by LDAP" it likely won't be able to deliver multiple-master
replication meeting its own requirements.

I rather address this issue sooner than later.  Later may be
too late.

Kurt

------=_NextPart_001_001C_01C16870.8E7CBD50
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_001C_01C16870.8E7CBD50--

------=_NextPart_000_001B_01C16870.8E7CBD50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwODIxMTUxN1owIwYJKoZIhvcNAQkEMRYEFPaP42WJURew
sQWmEpTJIMJUh8neMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAAIhXg+FlTpoaW6Nk/uxrrBXI
H5whVIwZGwQefXyamsZQlUFBNAZq2B1KYQKFdWElrqK+x96XvAuk1APwDDDsNwnSB0OAXuvECpF4
ErEm65vUQ8eWiw2sVpERyQ1OUKHkmS21FyYkveQVFLbES6WuIp8oliTxSMls9Mmo6WgUygwAAAAA
AAA=

------=_NextPart_000_001B_01C16870.8E7CBD50--



From owner-ietf-ldup@mail.imc.org  Mon Nov 12 00:03:36 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06066
	for <ldup-archive@odin.ietf.org>; Mon, 12 Nov 2001 00:03:36 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAC4ehN09769
	for ietf-ldup-bks; Sun, 11 Nov 2001 20:40:43 -0800 (PST)
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAC4eg809764
	for <ietf-ldup@imc.org>; Sun, 11 Nov 2001 20:40:42 -0800 (PST)
Received: from sdn-ar-004cocsprp225.dialsprint.net ([158.252.163.241] helo=FARILJCS)
	by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1)
	id 1638tM-0004Eh-00; Sun, 11 Nov 2001 20:40:17 -0800
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Christopher Apple" <christopher.apple@UnitedMessaging.net>,
        "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
Subject: RE: Revised WG Charter Proposal
Date: Sun, 11 Nov 2001 21:40:10 -0700
Message-ID: <FCEKLEHMPIHFNLCMKHAMOEOECOAA.john.strassner@intelliden.com>
MIME-Version: 1.0
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: <504D6456F0C87F4C8B11FB0C2021D6F602DACF70@ex04.ummail.com>
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_01AB_01C16A8F.DD94D230";
	micalg=SHA1
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_01AB_01C16A8F.DD94D230
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I agree with Chris, and think that it is premature to come to the
conclusion that we have to redefine these models.

regards,
John

-----Original Message-----
From: Christopher Apple [mailto:christopher.apple@UnitedMessaging.net]
Sent: Thursday, November 08, 2001 2:16 PM
To: 'Kurt D. Zeilenga'
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: RE: Revised WG Charter Proposal


I believe that's a technical issue to be sorted out by the
WG as it discusses relevant drafts which may seek to go one
way or the other.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com>
(V) +1 610 425 2860


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, November 08, 2001 12:28 PM
To: Christopher Apple
Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail)
Subject: RE: Revised WG Charter Proposal


At 07:30 AM 2001-11-08, Christopher Apple wrote:
>I am uncertain as to what specifically has led you to
>raise the issue though. Please elaborate on your concerns.

I'm concerned that the charter doesn't reflect the scope
of the work this group will have to undertake to be successful.

It seems that this WG has not yet reached consensus on whether
or not the WG needs make "redefine X.500 models used by LDAP"
in order to deliver "multi-master replication" meeting its
requirements.

The problem is that if the WG chooses to "redefine X.500 models
used by LDAP" it likely will run into significant contention (as
you noted).  And, if it chooses not to "redefine X.500 models used
by LDAP" it likely won't be able to deliver multiple-master
replication meeting its own requirements.

I rather address this issue sooner than later.  Later may be
too late.

Kurt

------=_NextPart_000_01AB_01C16A8F.DD94D230
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTExMTE2MDQyN1owIwYJKoZIhvcNAQkEMRYEFCFCFRiVakUHBz/ys4dKsDXvo1La
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAW6Tz
Bxc0/jkbZvsinFfO7EY11Cm8Su4/3p2505nmF2gkom/LQ1kwbAETju+1DmLMTt3+jBrkowqbx/DH
nB8KiX+xCnDjSFnSa0gh4PzxxDbvyFPonzOI+3xWV151rsNWPrhn/MJdQNplkhiDw8NmoxTIacEl
C4EBBraxs6zT4l0AAAAAAAA=

------=_NextPart_000_01AB_01C16A8F.DD94D230--



From owner-ietf-ldup@mail.imc.org  Mon Nov 12 11:15:27 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09343
	for <ldup-archive@odin.ietf.org>; Mon, 12 Nov 2001 11:15:27 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fACFwkO10825
	for ietf-ldup-bks; Mon, 12 Nov 2001 07:58:46 -0800 (PST)
Received: from cosds003.continuumnetworks.com ([12.41.184.243])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fACFwf810788
	for <ietf-ldup@imc.org>; Mon, 12 Nov 2001 07:58:43 -0800 (PST)
Received: from FARILJCS ([12.41.186.49]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GMP31400.O4V; Mon, 12 Nov 2001 08:58:16 -0700 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "'Ietf-Ldup@Imc. Org'" <ietf-ldup@imc.org>
Cc: "Christopher Apple" <christopher.apple@UnitedMessaging.net>
Subject: Charter - last milestone
Date: Mon, 12 Nov 2001 08:58:14 -0700
MIME-Version: 1.0
Message-ID: <FCEKLEHMPIHFNLCMKHAMKEPCCOAA.john.strassner@intelliden.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0039_01C16B58.29D4CAB0"
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0039_01C16B58.29D4CAB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

For the record, Chris and I discussed the charter (again) with respect to
the last milestone. Chris is indeed right - we were given prior guidance
from our ADs and the IESG on this subject, and this statement should stay
as written. Sorry for any confusion generated from my earlier note.

regards,
John

------=_NextPart_000_0039_01C16B58.29D4CAB0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTExMjE1NTgxNFowIwYJKoZIhvcNAQkEMRYEFNjsBD5yclowQwXlSw2mi9Yaj9hA
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAPLP6
lzmY1O0df6mVucQeaJyhysugqas5mFuKjzEVfd34MI6Cv9AJRzmF4+9N/Nxr7Pr5x6gz7pquH7Bw
rBChzWGcfTd8wHeatW8LMllk/JRxSXT5bpZyw79cSV6a4FtK7ICpJZ6/PNxcznbVXyriu4XgbVBk
NFjSLqZNa9B+hncAAAAAAAA=

------=_NextPart_000_0039_01C16B58.29D4CAB0--



From owner-ietf-ldup@mail.imc.org  Tue Nov 13 14:13:15 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13110
	for <ldup-archive@odin.ietf.org>; Tue, 13 Nov 2001 14:13:15 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fADIr3505543
	for ietf-ldup-bks; Tue, 13 Nov 2001 10:53:03 -0800 (PST)
Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fADIr1805538
	for <ietf-ldup@imc.org>; Tue, 13 Nov 2001 10:53:01 -0800 (PST)
Received: (from jayhawk@localhost)
	by tconl91223.tconl.com (8.11.0/8.11.0) id fADIpX901298;
	Tue, 13 Nov 2001 12:51:33 -0600
Date: Tue, 13 Nov 2001 12:51:33 -0600
From: Ryan Moats <rmoats@lemurnetworks.net>
To: internet-drafts@ietf.org
Cc: ietf-ldup@imc.org
Subject: Re: I-D ACTION:draft-ietf-ldup-framing-profile-00.txt
Message-ID: <20011113125133.A1248@localhost.localdomain>
References: <200108161102.HAA28184@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200108161102.HAA28184@ietf.org>; from Internet-Drafts@ietf.org on Thu, Aug 16, 2001 at 07:02:27AM -0400
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


I-D editor:

please insert the following (below '...===cuthere')
as draft-ietf-ldup-mrm-00.txt.

LDUP:

Here's -00 of Mandatory LDAP Replica Management.  Many thanks to Mark
and Ed for the initial text.  A lot of this document is still TBD
(as you will see), but we wanted to get something in the repository
for SLC and we've fleshed out enough of it for us to ask the WG
for consensus on the following issues.

1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
operational attributes as part of this operation? If so, LDAP will need
a change.

2. Section 4.6 currently requires that all replicaSubentries representing the
same server have the same entryUUID.  How is this accomplished?

3. Section 5.1.1 posits some out-of-band transport for the initial copy
of the source server.  Is LDIF appropriate for this transport?  If so,
how do we carry replication meta-data (e.g. CSNs)?

4. Should the operations in section 5.12 be condensed into a single extended
operation? The rationale behind an extended operation is that this should
be a mechanical process.  Having a mechanism to "replicate" this from one
server to the others:
- reduces likelihood of missing something
- allows replication framework to ensure that this information gets to
  every server in the event that a server is down or so

Enjoy
Ryan Moats (for the authors)


=============================cut here




Internet-Draft                                               Ryan Moats 
LDAP Duplication/Replication/Update                Lemur Networks, Inc. 
Protocols WG                                                 Rick Huber 
Intended Category: Standard                           AT&T Laboratories 

Expires May 2002                                         John McMeeking 
                                                                    IBM 
                                                          November 2001 
 
 
                   Mandatory LDAP Replica Management 
                 Filename: draft-ietf-ldup-mrm-00.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 
 
The goal of standards for LDAP replication is to allow interoperable 
replication among products from many different vendors.  Defining the 
mechanism to move data among replicas is a necessary part of this work, 
but management of the replicated environment must also be standardized 
for replication to be truly interoperable. 
 
This document presents the replication management functions that must 
be performed.  Whenever possible, these functions are defined in terms 
of existing LDAP functionality using existing LDAP operations and 
existing data definitions.  In some cases, changes or additions to the 
existing model are requires, and specifications for these changes are 
included in this document. 
 
 
 
Moats, et al               Expires May 2002                    [Page 1] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
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]. 
 
1  Table of Contents 
 
 
Status of this Memo...................................................1 
Abstract..............................................................1 
1 Table of Contents ..................................................2 
2 Introduction .......................................................3 
3 Administrative Precursors ..........................................4 
4 Operational "Atoms" ................................................4 
 4.1  Create replicaContext on a single server .......................5 
 4.2  Delete replicaContext from a single server .....................5 
 4.3  Add area of replication to a server ............................5 
 4.4  Delete area of replication from a server .......................6 
 4.5  Copy base of area of replication between servers ...............6 
 4.6  Create server entry in area of replication .....................6 
 4.7  Delete Server Entry for an area of replication .................7 
 4.8  Modify replica .................................................7 
  4.8.1  Change Replica Type .........................................7 
  4.8.2  Change Between Full/Partial Replica .........................7 
  4.8.3  Change Replica URI for one server for one area of replication
         7 
 4.9  Add Replication Agreement ......................................7 
 4.10   Delete Replication Agreement .................................8 
 4.11   Modify Replication Agreement .................................8 
 4.12   Suspend Replication ..........................................8 
 4.13   Resume Replication ...........................................8 
 4.14   Trigger an Immediate Replica Cycle ...........................8 
5 Common Tasks .......................................................8 
 5.1  Add a new replica to an existing replica group .................9 
  5.1.1  Large area of replication support ...........................9 
 5.2  Set up (but do not start) replication between two servers ......9 
 5.3  Set up (but do not start) replication between a server and an 
 existing replica group ..............................................9 
 5.4  Verify replication information is present between two servers ..9 
 5.5  Start replication between two servers. .........................9 
 5.6  Start replication between an existing replica group and a new 
 server ..............................................................9 
 5.7  Temporarily Suspend all replication activity from a given server
      9 
 5.8  Halt replication on all areas of a server ......................9 
 5.9  List status of a particular area of replication on a given 
 server ..............................................................9 
 5.10   List all areas of replication defined on a given server and 
 their status .......................................................10 
 5.11   Restore a server and replication agreements after a server 
 crash  10 
 5.12   Split an Area of Replication ................................10 
 5.13   Move an existing area of replication to a new server ........10 
 5.14   Join two Areas of Replication ...............................10 
  5.14.1   Preconditions ............................................10 
 
Moats, et al               Expires May 2002                    [Page 2] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
  5.14.2   Procedure ................................................10 
  5.14.3   Server requirements ......................................11 
 5.15   Stop Replicating an Area of Replication. ....................11 
 5.16   Suspending and Resuming Replication .........................12 

 5.17   Convert a read-only replica to an updateable replica ........12 
 5.18   Changing Replica URI on all servers handling an area of 
 replication ........................................................12 
 5.19   Postpone a Replica Cycle to a Later Time ....................12 
 5.20   Examine Replication Audit History on a Server ...............12 
 5.21   Compare Two Replicas on Two Servers for Differences .........12 
 5.22   Fix an Entry Without Triggering Replication .................12 
 5.23   Check Reported Schema Mismatches Discovered During Replication
        13 
 5.24   Adding a new directory server to a replica group and 
 initializing the contents ..........................................13 
 5.25   Restore from the master failure in a single-master system ...13 
6 Formal Specifications .............................................13 
 6.1  New/Modified Object Classes ...................................13 
 6.2  New/Modified Attributes .......................................13 
 6.3  New/Modified Extended Operations ..............................13 
 6.4  New/Modified Replication Primitives ...........................14 
7 Security Considerations ...........................................14 
8 Acknowledgements ..................................................14 
9 References ........................................................14 
Author's Addresses:..................................................15 
Full Copyright Statement.............................................15 
 
 
 
2  Introduction 
 
In the LDAP replication architecture [Arch], the LDAP servers and 
replication agreements between them are represented by entries in the 
directory tree, as part of the replicated naming context.  The LDAP 
replication information model [InfoMod] describes the contents of these 
entries. 
 
Replication management entries, such as replicaSubentries or 
replication agreements, can be altered on any updateable replica. These 
entries are implicitly included in the directory entries governed by 
any agreement associated with this area of replication.  As a result, 
all servers with a replica of an area of replication will have access 
to information about all other replicas of that area of replication and 
associated agreements. 
 
The deployment and maintenance of a replicated directory network 
involves the creation and management on the replicas themselves and 
associated replication control information (e.g. replicationSubentries 
and replication agreements).  This document outlines the administrative 
actions necessary to create and maintain replication agreements.  
 
Typically, administrative tools will guide the administrator and 
facilitate these actions. 
 
 
 
Moats, et al               Expires May 2002                    [Page 3] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
3  Administrative Precursors 
In this document the term "administrative user" refers to an identity 
that will be performing replication configuration by binding to and 
invoking operations on directory servers.  Most LDAP server 
implementations have the concept of a superuser or power user, however 
this need not be the same as the administrative user, so long as the 
administrative user has been granted appropriate privileges. The 
administrative user MAY be running as an autonomous process, and MUST 
be capable of securely maintaining its own credentials. 
 
Servers SHOULD support the concept of there being multiple 
administrative users, and SHOULD allow each to have distinct rights 
from the others. 
 
Deployments SHOULD create an administrative user identity that is 
granted access to all servers holding a replica of a naming context to 
perform the procedures described below, in particular to read the root 
DSE, the replicationContext prefix entry and all subordinate 
subentries. The administrative user who will be viewing or modifying 
the replication status MUST have already been provided with and 
established in the directory server or servers appropriate 
authentication credentials and authorization rights to retrieve 
attributes and invoke DIT modification operations that are beyond the 
ability of the 'average' directory user. 
 
Through out-of-band means one of the following will have occurred: 
 
  1. 
     the administrative user and the directory server have agreed upon 
     a shared secret which the administrator will use to authenticate 
     itself, or 
  2. 
     the administrative user will have a certificate that can be 
     validated by the directory server. 
 
Note that the secret in the first case need not be held by the 
directory server itself but could be maintained by an authentication 
service trusted by the directory server. 
 
4  Operational "Atoms" 
 
The following operational atoms are used to build up more complex tasks 
in section 5. 
 
Most of these operational "atoms" make the following assumptions: 
 
Through prior LDAP or out-of-band means the administrative user MUST 
have been granted the following access control permissions to the 
directory in order to establish replication: 
 
  -Modify the attribute 'replicaContextRoots' of the root DSE by 
     adding values 
  -Create the naming context prefix entry 
 
 
 
Moats, et al               Expires May 2002                    [Page 4] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
  -Create subentries immediately below the naming context prefix 
     entry 
 
In several sections below, we refer to "source" and "target" servers. 
The "source" server is a server that already holds a copy of the area 
of replication.  It may already be replicating that area with other 
servers.  The "target" server does not currently hold a copy of the 
area of replication.  The "target" is being added to the replica-group.  
 
Issue: Any write or modify being done to a readOnly replica requires 
some thought. 
 
Issue: Whether each of these atoms is propagated by replication and how 
it impacts the replication process. 
 
4.1 Create replicaContext on a single server 
 
The client SHOULD invoke a ModifyRequest in which the object field is 
the empty string (naming the root DSE), and the modification list 
consists of a single item to add the distinguished name of the context 
prefix to the attribute replicaContextRoots.  If the server responds 
with the resultCode attributeOrValueExists, then the value is already 
there.  If the server responds with a resultCode other than 
attributeOrValueExists or success, then this is an error. 
 
4.2 Delete replicaContext from a single server 
 
The client SHOULD invoke a ModifyRequest in which the object field is 
the empty string  (naming the root DSE), and the modifications list 
consists of a single item, to delete the value of the distinguished 
name of the context prefix from the attribute replicaContextRoots.  If 
 
the server responds with the resultCode noSuchAttribute, then the value 
has already been removed.  If the server responds with a resultCode 
other than noSuchAttribute or success, then this is an error. 
 
4.3 Add area of replication to a server 
 
The client SHOULD invoke a ModifyRequest in which the object field is 
the context prefix of the replication context, and the modification 
list consists of a single item to add the value replicationContext to 
the attribute objectClass.  If the server responds with the resultCode 
attributeOrValueExists, then the value is already there.  If the server 
responds with a resultCode other than attributeOrValueExists or 
success, then this is an error.  Should an error occur at this point, 
the server is in an inconsistent state and needs to be fixed.  
 
After this step is completed, the server will begin storing change 
information for this area of replication.  
 
WG ISSUE: If replicaContextRoots were an operational attribute, then it 
would be possible to have the server maintain that attribute when 
replicationContext is added or deleted.  Without it, these steps need 
 
 
Moats, et al               Expires May 2002                    [Page 5] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
to be separate LDAP protocol operations and thus it is possible to have 
inconsistent states. 
 
4.4 Delete area of replication from a server 
 
The client SHOULD invoke a ModifyRequest in which the object field is 
the context prefix of the replication context, and the modification 
list consists of a single item to remove the value replicationContext 
to the attribute objectClass.  If the server responds with the 
resultCode noSuchAttribute, then the value has already been removed.  
If the server responds with a resultCode other than noSuchAttribute or 
success, then this is an error.   
 
After this step is completed, the server will no longer replicate this 
area of replication. 
 
4.5 Copy base of area of replication between servers 
In this section, the 'target server' is the server on which the client 
has just modified the root DSE. 
 
The client MUST separately contact another server, one that already 
holds a copy of this replication context, and issue a SearchRequest on 
that server in which the baseObject is the DN of the of base the area 
of replication, the scope baseObject, the filter "(objectClass=*)" and 
the attributes list "*".  If the client cannot obtain the single entry 
at this point, the procedure will fail, and the client SHOULD invoke on 
the slave server a ModifyRequest in which the object field is the empty 
string, and the modifications list consists of a single item, a delete 
of the attribute replicaContextRoots with the value the distinguished 
name of the context prefix. 
 
WG Issue: Do we need the ability to copy (i.e. read and set) all 
operational attributes as part of this operation? If so, LDAP will need 
a change. 
 
Now that it has the entry, the client SHOULD invoke an AddRequest on 
the target server with entry set to the DN of the base of the area of 
replication and attributes the same list as obtained in the previous 
search. 
 
If the server returns a resultCode other than success, it is an error, 
and the server will be in an inconsistent state. 
 
4.6 Create server entry in area of replication 
 
Each server needs to have in its copy of the area of replication a 
replicaSubentry for each of the servers involved in replicating that 
area before replication can be started. These entries MUST have the 
following attributes: 
 
1.   objectclass, with values top, ldapSubentry and replicaSubentry 
2.   cn 
3.   replicaURI 
 
Moats, et al               Expires May 2002                    [Page 6] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
4.   replicaType 
5.   replicaOnline 
 
and MAY contain other attributes, as described in the Information Model 
[InfoMod]. 
 
WG Issue: This requires that all replicaSubentries representing the 
same server have the same entryUUID.  How is this accomplished? 
 
4.7 Delete Server Entry for an area of replication 
 
The client SHOULD issue a SearchRequest in which the baseObject is the 
DN of the context prefix, the scope oneLevel, the filter 
"(objectClass=replicaSubentries)" and the attributes list. For each 
entry returned, the client SHOULD then issue a DeleteReques in which 
the object field is the DN of the entry.   If the server responds with 
the resultCode noSuchObject, then the entry has already been removed.  
If the server responds with a resultCode other than noSuchObject or 
success, then this is an error. 
 
4.8 Modify replica 
 
4.8.1     Change Replica Type 
 
Note: This section covers only the simple protocol operation to change 
the replica type. Section 5.17 coverts the full set of operations for 
converting from a ReadOnly to an Updateable replica. 
 
The client SHOULD invoke a ModifyRequest in which the object field is 
the replicationSubentry, and the modification list consists of a single 
item to change the value of the attribute replicaType.  If the server 
responds with the resultCode attributeOrValueExists, then the value is 
already there.  If the server responds with a resultCode other than 
attributeOrValueExists or success, then this is an error.  
 
4.8.2     Change Between Full/Partial Replica 
 
TBD 
 
4.8.3     Change Replica URI for one server for one area of replication 
 
Note: This section covers only the simple protocol operation to change 
the replica type. Section 5.18 covers the full set of operations for 
changing the replica URI on all servers. 
 
The client SHOULD invoke a ModifyRequest in which the object field is 
the replicationSubentry, and the modification list consists of a single 
item to change the value of the attribute replicaURI to the new value.  
If the server responds with the resultCode attributeOrValueExists, then 
the value is already there.  If the server responds with a resultCode 
other than attributeOrValueExists or success, then this is an error. 
 
4.9 Add Replication Agreement 
 
TBD 
Moats, et al               Expires May 2002                    [Page 7] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
4.10 Delete Replication Agreement 
 
The termination of replication agreements should be done with caution 
as it can easily result in a partition of the directory servers if 
performed incorrectly. 
 
Once all replication agreements have been terminated between a server 
and others for a naming context, then that copy of the context on the 
server will be divergent, and any updates made there will not be 
propagated to any other server. 
 
TBD 
 
4.11 Modify Replication Agreement 
 
TBD 
 
4.12 Suspend Replication 
The client SHOULD invoke a ModifyRequest in which the object field is 
the DN of the target replicationSubentry, and the modification list 
consists of a single item to change the value of replicaOnline 
attribute to false. If the server responds with the resultCode 
attributeOrValueExists, then the value is already there.  If the server 
responds with a resultCode other than attributeOrValueExists or 
success, then this is an error. 
 
4.13 Resume Replication 
The client SHOULD invoke a ModifyRequest in which the object field is 
the DN of the target replicationSubentry, and the modification list 
consists of a single item to change the value of replicaOnline 
attribute to true. If the server responds with the resultCode 
attributeOrValueExists, then the value is already there.  If the server 
responds with a resultCode other than attributeOrValueExists or 
success, then this is an error.  
 
4.14 Trigger an Immediate Replica Cycle 
 
TBD 
 
Issue: An administrative client could trigger an immediate replication 
cycle by issuing a "Trigger Replication" extended operation to the 
supplier server.  The extended operation value specifies the DN of a 
replication agreement between the supplier and target replicas, and the 
type of replication session to be performed (full update or incremental 
update).  The replication agreement is used to specify the target 
replica, connection information, and authentication information. 
 
5  Common Tasks 
There are many tasks that administrators need to perform in a 
replicated environment.  This section describes many typical tasks and 
describes how they are performed in terms of the atoms defined above. 
 
 
Moats, et al               Expires May 2002                    [Page 8] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
5.1 Add a new replica to an existing replica group 
 
TBD 
 
5.1.1     Large area of replication support 
 
In some cases, an area of replication is so large or available 
bandwidth so small that out-of-band mechanisms (e.g. mailing a tape) 
need to be used to transport the initial copy from the source to the 
target.  The target then needs to be updated with changes made to the 
source since the copy was made.  This section describes how this 
situation is handled. 
 
Details TBD. 
 
WG Issue: is LDIF appropriate for this transport?  If so, how do we 
carry replication meta-data (e.g. CSNs)? 
 
5.2 Set up (but do not start) replication between two servers 
 
TBD 
 
5.3 Set up (but do not start) replication between a server and an 
    existing replica group 
 
TBD 
 
5.4 Verify replication information is present between two servers 
 
TBD 
 
5.5 Start replication between two servers. 
 
For this operation, the client SHOULD follow the steps in Section 5.2 
followed by starting replication as specified in Section 4.13. 
 
5.6 Start replication between an existing replica group and a new 
    server 
For this operation, the client SHOULD follow the steps in Section 5.3 
followed by starting replication as specified in Section 4.13. 
 
5.7 Temporarily Suspend all replication activity from a given server 
 
TBD  
 
5.8 Halt replication on all areas of a server 
 
TBD 
 
5.9 List status of a particular area of replication on a given server 
 
TBD 
 
Moats, et al               Expires May 2002                    [Page 9] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
 
5.10 List all areas of replication defined on a given server and their 
    status 
 
TBD 
 
5.11 Restore a server and replication agreements after a server crash 
 
TBD 
 
5.12 Split an Area of Replication 
 
To split an area of replication, the atoms are: 
1.   Add the subordinate area of replication to the servers' 
     replicaContextRoots (Section 4.1) 
2.   Add the replicationContext objectclass to the root entry of the 
     area of replication (Section 4.3) 
3.   Create replicaSubentry objects under the new area of replication 
     for each replica of the parent area of replication (Section 4.6) 
4.   Create replicaAgreement objects (and schedules?) under the new 
     replicaSubentries, where agreements are created that correspond to 
     each agreement defined for the parent (Section 4.9). 
These operations must be performed on each server containing a replica 
of the parent area of replication.   
 
WG Issue: Extended op or not? The rationale behind an extended 
operation is that this should be a mechanical process.  Having a 
mechanism to "replicate" this from one server to the others: 
- reduces likelihood of missing something 
- allows replication framework to ensure that this information gets to 
  every server in the event that a server is down or some other error 
  prevents the client from completing all of these operations. 
 
5.13 Move an existing area of replication to a new server  
 
TBD 
 
5.14 Join two Areas of Replication 
 
This section describes how to join two areas of replication. 
 
5.14.1    Preconditions 
 
Before joining two areas of replication there are certain preconditions 
that need to be satisfied: 
1.   Any server that contains a replica of one area of replication must 
     also contain a replica of the other area of replication. This may 
     require copying either area of replication to additional servers, 
     or deleting either area of replication from servers. 
2.   The replicas on any given server MUST be of the same type.  Both 
     replicas must be updateable, both-readonly, or both primary.  
     Furthermore, if the replicas are readonly, they must both be full 
     replicas, or must both be fractional replicas with identical 
     fractional entry specifications. 
 
5.14.2    Procedure 
 
 
Moats, et al               Expires May 2002                   [Page 10] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
1. On each server, delete the replicationContext objectclass value from 
  the subordinate area of replication (Section TBD). 
   
  We'd like this to be replicated under the parent area of replication, 
  and we'd like this to have the affect of causing all not yet 
  replicated updates and future client changes as if they occurred 
  under the parent area f replication.  This is going to cause problems 
  with respect to CSNs if there are "old" changes in the subordinate 
  context.  Maybe we require that there be no pending updates?  This is 
  going to be potentially ugly. 
2. 
  Delete all replication agreements for the subordinate area of 
  replication 
3. 
  Delete all replicaSubentries for the subordinate area of replication 
 
5.14.3    Server requirements 
 
When the replicationContext objectclass is removed from the root of an 
area of replication, the server MUST immediately treat entries within 
the area of replication as belonging to the parent area of replication 
(if there is any).  This includes replicating any pending replication 
updates (those not yet replicated to other replicas) as if they 
occurred under the parent area of replication, as well as preserving 
any Lost and Found entries. 
 
If a server receives a request to delete the replicationContext from an 
area of replication, and there is a parent area of replication, the 
Server MUST verify that these replicas are of the same type, and if 
fractional, that the fractional entry specifications are identical.  If 
the replicas are not of the same type, the request MUST be failed with 
resultCode unwillingToPerform. 
 
5.15 Stop Replicating an Area of Replication. 
 
This section describes how to stop replicating an area of replication.  
At the end of the procedure, the subtree represented by the area of 
replication will exist on one server, all replication agreements will 
have been deleted, and the root of the area of replication will no 
longer be an area of replication.  The server on which the subtree will 
remain is referred to as the surviving replica.   
To stop replicating an area of replication, a client with 
administrative authority should perform the following operations: 
 
1.   Halt replication 
 
After halting, the client MAY optionally delete information by: 
 
2.   Delete all replication agreements (Section 4.10). 
3.   Delete all replicaSubentries under the area of replication 
     (section 4.7)  
4.   Issue a modifyRequest to the surviving server where the object 
     field is the DN of the area of replication, and the modifications 
     list consists of a single item, delete the attribute objectclasss 
     with value replicationContext. 
 
Moats, et al               Expires May 2002                   [Page 11] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
5.   Delete replicaContext from that server (Section 4.2) 
6.   Delete the area of replication from servers containing other 
     replicas (Section 4.4). 
 
Note that client updates accepted on the non-surviving replicas during 
this procedure may be lost (because they were not replicated to the 
surviving server). 
 
5.16 Suspending and Resuming Replication 
 
To suspend replication of an area of replication to a specific server, 
an administrative client can perform a modifyRequest of the 
replicaSubentry, with a modification list replacing the replicaOnline 
attribute with the value false.   Performing this request on the 
specified server causes the server to stop accepting or initiating 
replication requests for that area of replication.  This procedure can 
also be performed on any other replica.  The modifyRequest will be 
replicated to other servers.  When a server other than that specified 
by the replicaSubentry receives the request the server MUST stop 
sending replication updates to the specified server.  The unsent 
changes MUST be saved until the replicaOnline attribute is chnaged to 
true.  Servers MUST continue to repond to replication updates sent from 
the specified server. 
 
To resume replication of an area of replication to a specific server, 
an administrative client can perform a modifyRequest of the 
replicaSubentry, with a modification list replacing the replicaOnline 
attribute with the value false.   This request must be performed on the 
specified server, or it will not resume replication.  This operation 
may also be performed on other servers. 
 
5.17 Convert a read-only replica to an updateable replica 
 
TBD 
 
5.18 Changing Replica URI on all servers handling an area of 
    replication 
 
The client issues this request to the server whose address has been 
changed, which replicates it to the other replicas like other client 
updates.  It may be necessary to issue the same request to other 
replicas, for example, when the server does not have proper replication 
agreements to fully replicate this change (as in consumer initiated 
replication). 
 
5.19 Postpone a Replica Cycle to a Later Time 
 
TBD 
 
5.20 Examine Replication Audit History on a Server 
 
TBD 
 
5.21 Compare Two Replicas on Two Servers for Differences 
 
TBD 
 
5.22 Fix an Entry Without Triggering Replication 
 
When conflicts cause entries to be put in the Lost+Found area, the 
administrator needs a mechanism to make appropriate changes.  These 
Moats, et al               Expires May 2002                   [Page 12] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
changes should not trigger replication since they are used to fix 
previous replication problems.  In addition, these changes may include 
fixes to UUIDs, CSNs, or other control data that cannot be changed 
using normal LDAP operations. 
 
TBD 
 
5.23 Check Reported Schema Mismatches Discovered During Replication 
 
TBD 
 
5.24 Adding a new directory server to a replica group and initializing 
    the contents 
 
In this case, the client: 
 
1. Creates the replicaContext on the new server (section 4.1) 
2. Copies the base entry for the area of replication from a source to 
the target (section 4.5) 
3. 
  Create the entries for the new server on all servers in the replica 
  group (section 4.6) 
4. 
  Create the entries for the existing replica group servers on the new 
  (section 4.6) 
5. 
  Create the replication agreement on all servers (section 4.9) 
6. 
  Client issues a "Initiate Full Update" request to a full replica for 
  the new replica -- or new replica requests consumer initiated full 
  update 
 
 
 
5.25 Restore from the master failure in a single-master system 
 
TBD 
 
6  Formal Specifications 
 
The Replica Management features depend heavily on defined LDAP and LDUP 
structure, operations, and data formats.  But some changes will be 
needed to accommodate Replica Management.  All these changes are pulled 
together in this section for easy reference. 
 
6.1 New/Modified Object Classes 
 
TBD 
 
6.2 New/Modified Attributes 
 
TBD 
 
6.3 New/Modified Extended Operations 
 
Trigger Replica Operation 
 
TBD 
 
 
Moats, et al               Expires May 2002                   [Page 13] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
 
6.4 New/Modified Replication Primitives 
 
TBD 
 
7  Security Considerations 
 
In all cases, it is assumed that the client establishes a connection to 
the LDAP server and SHOULD authenticate using a recommended 
authentication method [RFC2829] that establishes the identity of the 
client user and SHOULD provide for connection integrity.  In 
deployments where the underlying network service is vulnerable to 
eavesdropping and clients are intending to retrieve sensitive server 
credentials, the chosen method SHOULD also provide for encryption of 
data in transit. 
 
In general, where the client is unaware of any network level protection 
services, it is RECOMMENDED that the client immediately after 
connection establishment invoke Start TLS to establish connection 
integrity and confidentiality, and follow this by authentication by one 
of: 
 
  - the "DIGEST-MD5" SASL mechanism, 
  - the "simple" authentication choice, or 
  - the "EXTERNAL" SASL mechanism if the client provided its  
     certificate during TLS establishment. 
 
The client MAY determine the supported authentication mechanisms of the 
server from the supportedSASLMechanisms attribute of the root DSE after 
Start TLS has been invoked, and use this to decide whether to use 
DIGEST-MD5 or EXTERNAL.  See [RFC2830] for more information on TLS. 
 
8  Acknowledgements 
 
Thanks to Mark Wahl and Ed Reed for providing a lot of the initial 
text. 
 
This document is a product of the LDUP Working Group of the IETF.  The 
contributions of its members are greatly appreciated. 
 
9  References 
[Arch] J. Merrells, E. Reed, U. Srinvasan, "LDAP Replication 
Architecture", draft-ietf-ldup-model-01.txt. 
 
[InfoMod] E. Reed, "LDAP Replication Information Model", draft-ietf-
ldup-infomod-00.txt 
 
[RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate 
Requirement Levels", RFC 2119, March 1997. 
 
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL Morgan, "Authentication 
Methods for LDAP", RFC 2829, May 2000. 
 
 
 
 
Moats, et al               Expires May 2002                   [Page 14] 

 
 
INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
[RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access 
Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 
2000. 
 
Author's Addresses: 
 
Ryan Moats 
Lemur Networks, Inc. 
Email: rmoats@lemurnetworks.net 
 
Rick Huber 
AT&T Laboratories 
Email: rvh@qsun.att.com 
 
John McMeeking 
IBM 
Email: jmcmeek@us.ibm.com 
 
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 
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. 







Moats, et al               Expires May 2002                   [Page 15] 



From owner-ietf-ldup@mail.imc.org  Tue Nov 13 14:16:46 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13273
	for <ldup-archive@odin.ietf.org>; Tue, 13 Nov 2001 14:16:46 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fADHcnA29618
	for ietf-ldup-bks; Tue, 13 Nov 2001 09:38:49 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fADHcf829609
	for <ietf-ldup@imc.org>; Tue, 13 Nov 2001 09:38:45 -0800 (PST)
Received: from rowlf.Central.Sun.COM ([129.153.131.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25076;
	Tue, 13 Nov 2001 10:38:17 -0700 (MST)
Received: from sun.com (dhcp-aus07-187 [129.153.129.187])
	by rowlf.Central.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id fADHcXl12735;
	Tue, 13 Nov 2001 11:38:33 -0600 (CST)
Message-ID: <3BF15936.65CD9072@sun.com>
Date: Tue, 13 Nov 2001 11:32:38 -0600
From: Mark Wahl <Mark.Wahl@sun.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: john.strassner@intelliden.com, christopher.apple@unitedmessaging.com
CC: roland@catalogix.se, ietf-ldup@imc.org, ietf-ldapext@netscape.com
Subject: moving access control discussion to LDUP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



It may be worthwhile to consider adding the access control standardization
discussion to LDUP, as LDUP will need the replication of access control 
information for many of its scenarios.  This activity was ongoing in LDAPEXT,
but LDAPEXT is shutting down and has not reached rough consensus on 
access control specification.

Mark Wahl
Sun Microsystems Inc.


From owner-ietf-ldup@mail.imc.org  Tue Nov 13 14:33:07 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14098
	for <ldup-archive@odin.ietf.org>; Tue, 13 Nov 2001 14:33:06 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fADJA9N06223
	for ietf-ldup-bks; Tue, 13 Nov 2001 11:10:09 -0800 (PST)
Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fADJA7806218
	for <ietf-ldup@imc.org>; Tue, 13 Nov 2001 11:10:07 -0800 (PST)
Received: (from jayhawk@localhost)
	by tconl91223.tconl.com (8.11.0/8.11.0) id fADJ9ET01307;
	Tue, 13 Nov 2001 13:09:14 -0600
Date: Tue, 13 Nov 2001 13:09:14 -0600
From: Ryan Moats <rmoats@lemurnetworks.net>
To: ietf-ldup@imc.org
Cc: ietf-ldup@imc.org
Subject: -00 of Mandatory Replica Management (and a few questions)
Message-ID: <20011113130914.B1248@localhost.localdomain>
References: <200108161102.HAA28184@ietf.org> <20011113125133.A1248@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20011113125133.A1248@localhost.localdomain>; from rmoats@lemurnetworks.net on Tue, Nov 13, 2001 at 12:51:33PM -0600
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Doh... lets try this with a correct subject...

On Tue, Nov 13, 2001 at 12:51:33PM -0600, Ryan Moats wrote:
| LDUP:
| 
| Here's -00 of Mandatory LDAP Replica Management.  Many thanks to Mark
| and Ed for the initial text.  A lot of this document is still TBD
| (as you will see), but we wanted to get something in the repository
| for SLC and we've fleshed out enough of it for us to ask the WG
| for consensus on the following issues.
| 
| 1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
| operational attributes as part of this operation? If so, LDAP will need
| a change.
| 
| 2. Section 4.6 currently requires that all replicaSubentries representing the
| same server have the same entryUUID.  How is this accomplished?
| 
| 3. Section 5.1.1 posits some out-of-band transport for the initial copy
| of the source server.  Is LDIF appropriate for this transport?  If so,
| how do we carry replication meta-data (e.g. CSNs)?
| 
| 4. Should the operations in section 5.12 be condensed into a single extended
| operation? The rationale behind an extended operation is that this should
| be a mechanical process.  Having a mechanism to "replicate" this from one
| server to the others:
| - reduces likelihood of missing something
| - allows replication framework to ensure that this information gets to
|   every server in the event that a server is down or so
| 
| Enjoy
| Ryan Moats (for the authors)
| 
| 
| =============================cut here
| 
| 
| 
| 
| Internet-Draft                                               Ryan Moats 
| LDAP Duplication/Replication/Update                Lemur Networks, Inc. 
| Protocols WG                                                 Rick Huber 
| Intended Category: Standard                           AT&T Laboratories 
| 
| Expires May 2002                                         John McMeeking 
|                                                                     IBM 
|                                                           November 2001 
|  
|  
|                    Mandatory LDAP Replica Management 
|                  Filename: draft-ietf-ldup-mrm-00.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 
|  
| The goal of standards for LDAP replication is to allow interoperable 
| replication among products from many different vendors.  Defining the 
| mechanism to move data among replicas is a necessary part of this work, 
| but management of the replicated environment must also be standardized 
| for replication to be truly interoperable. 
|  
| This document presents the replication management functions that must 
| be performed.  Whenever possible, these functions are defined in terms 
| of existing LDAP functionality using existing LDAP operations and 
| existing data definitions.  In some cases, changes or additions to the 
| existing model are requires, and specifications for these changes are 
| included in this document. 
|  
|  
|  
| Moats, et al               Expires May 2002                    [Page 1] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| 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]. 
|  
| 1  Table of Contents 
|  
|  
| Status of this Memo...................................................1 
| Abstract..............................................................1 
| 1 Table of Contents ..................................................2 
| 2 Introduction .......................................................3 
| 3 Administrative Precursors ..........................................4 
| 4 Operational "Atoms" ................................................4 
|  4.1  Create replicaContext on a single server .......................5 
|  4.2  Delete replicaContext from a single server .....................5 
|  4.3  Add area of replication to a server ............................5 
|  4.4  Delete area of replication from a server .......................6 
|  4.5  Copy base of area of replication between servers ...............6 
|  4.6  Create server entry in area of replication .....................6 
|  4.7  Delete Server Entry for an area of replication .................7 
|  4.8  Modify replica .................................................7 
|   4.8.1  Change Replica Type .........................................7 
|   4.8.2  Change Between Full/Partial Replica .........................7 
|   4.8.3  Change Replica URI for one server for one area of replication
|          7 
|  4.9  Add Replication Agreement ......................................7 
|  4.10   Delete Replication Agreement .................................8 
|  4.11   Modify Replication Agreement .................................8 
|  4.12   Suspend Replication ..........................................8 
|  4.13   Resume Replication ...........................................8 
|  4.14   Trigger an Immediate Replica Cycle ...........................8 
| 5 Common Tasks .......................................................8 
|  5.1  Add a new replica to an existing replica group .................9 
|   5.1.1  Large area of replication support ...........................9 
|  5.2  Set up (but do not start) replication between two servers ......9 
|  5.3  Set up (but do not start) replication between a server and an 
|  existing replica group ..............................................9 
|  5.4  Verify replication information is present between two servers ..9 
|  5.5  Start replication between two servers. .........................9 
|  5.6  Start replication between an existing replica group and a new 
|  server ..............................................................9 
|  5.7  Temporarily Suspend all replication activity from a given server
|       9 
|  5.8  Halt replication on all areas of a server ......................9 
|  5.9  List status of a particular area of replication on a given 
|  server ..............................................................9 
|  5.10   List all areas of replication defined on a given server and 
|  their status .......................................................10 
|  5.11   Restore a server and replication agreements after a server 
|  crash  10 
|  5.12   Split an Area of Replication ................................10 
|  5.13   Move an existing area of replication to a new server ........10 
|  5.14   Join two Areas of Replication ...............................10 
|   5.14.1   Preconditions ............................................10 
|  
| Moats, et al               Expires May 2002                    [Page 2] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
|   5.14.2   Procedure ................................................10 
|   5.14.3   Server requirements ......................................11 
|  5.15   Stop Replicating an Area of Replication. ....................11 
|  5.16   Suspending and Resuming Replication .........................12 
| 
|  5.17   Convert a read-only replica to an updateable replica ........12 
|  5.18   Changing Replica URI on all servers handling an area of 
|  replication ........................................................12 
|  5.19   Postpone a Replica Cycle to a Later Time ....................12 
|  5.20   Examine Replication Audit History on a Server ...............12 
|  5.21   Compare Two Replicas on Two Servers for Differences .........12 
|  5.22   Fix an Entry Without Triggering Replication .................12 
|  5.23   Check Reported Schema Mismatches Discovered During Replication
|         13 
|  5.24   Adding a new directory server to a replica group and 
|  initializing the contents ..........................................13 
|  5.25   Restore from the master failure in a single-master system ...13 
| 6 Formal Specifications .............................................13 
|  6.1  New/Modified Object Classes ...................................13 
|  6.2  New/Modified Attributes .......................................13 
|  6.3  New/Modified Extended Operations ..............................13 
|  6.4  New/Modified Replication Primitives ...........................14 
| 7 Security Considerations ...........................................14 
| 8 Acknowledgements ..................................................14 
| 9 References ........................................................14 
| Author's Addresses:..................................................15 
| Full Copyright Statement.............................................15 
|  
|  
|  
| 2  Introduction 
|  
| In the LDAP replication architecture [Arch], the LDAP servers and 
| replication agreements between them are represented by entries in the 
| directory tree, as part of the replicated naming context.  The LDAP 
| replication information model [InfoMod] describes the contents of these 
| entries. 
|  
| Replication management entries, such as replicaSubentries or 
| replication agreements, can be altered on any updateable replica. These 
| entries are implicitly included in the directory entries governed by 
| any agreement associated with this area of replication.  As a result, 
| all servers with a replica of an area of replication will have access 
| to information about all other replicas of that area of replication and 
| associated agreements. 
|  
| The deployment and maintenance of a replicated directory network 
| involves the creation and management on the replicas themselves and 
| associated replication control information (e.g. replicationSubentries 
| and replication agreements).  This document outlines the administrative 
| actions necessary to create and maintain replication agreements.  
|  
| Typically, administrative tools will guide the administrator and 
| facilitate these actions. 
|  
|  
|  
| Moats, et al               Expires May 2002                    [Page 3] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| 3  Administrative Precursors 
| In this document the term "administrative user" refers to an identity 
| that will be performing replication configuration by binding to and 
| invoking operations on directory servers.  Most LDAP server 
| implementations have the concept of a superuser or power user, however 
| this need not be the same as the administrative user, so long as the 
| administrative user has been granted appropriate privileges. The 
| administrative user MAY be running as an autonomous process, and MUST 
| be capable of securely maintaining its own credentials. 
|  
| Servers SHOULD support the concept of there being multiple 
| administrative users, and SHOULD allow each to have distinct rights 
| from the others. 
|  
| Deployments SHOULD create an administrative user identity that is 
| granted access to all servers holding a replica of a naming context to 
| perform the procedures described below, in particular to read the root 
| DSE, the replicationContext prefix entry and all subordinate 
| subentries. The administrative user who will be viewing or modifying 
| the replication status MUST have already been provided with and 
| established in the directory server or servers appropriate 
| authentication credentials and authorization rights to retrieve 
| attributes and invoke DIT modification operations that are beyond the 
| ability of the 'average' directory user. 
|  
| Through out-of-band means one of the following will have occurred: 
|  
|   1. 
     the administrative user and the directory server have agreed upon 
|      a shared secret which the administrator will use to authenticate 
|      itself, or 
|   2. 
     the administrative user will have a certificate that can be 
|      validated by the directory server. 
|  
| Note that the secret in the first case need not be held by the 
| directory server itself but could be maintained by an authentication 
| service trusted by the directory server. 
|  
| 4  Operational "Atoms" 
|  
| The following operational atoms are used to build up more complex tasks 
| in section 5. 
|  
| Most of these operational "atoms" make the following assumptions: 
|  
| Through prior LDAP or out-of-band means the administrative user MUST 
| have been granted the following access control permissions to the 
| directory in order to establish replication: 
|  
|   -Modify the attribute 'replicaContextRoots' of the root DSE by 
|      adding values 
|   -Create the naming context prefix entry 
|  
|  
|  
| Moats, et al               Expires May 2002                    [Page 4] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
|   -Create subentries immediately below the naming context prefix 
|      entry 
|  
| In several sections below, we refer to "source" and "target" servers. 
| The "source" server is a server that already holds a copy of the area 
| of replication.  It may already be replicating that area with other 
| servers.  The "target" server does not currently hold a copy of the 
| area of replication.  The "target" is being added to the replica-group.  
|  
| Issue: Any write or modify being done to a readOnly replica requires 
| some thought. 
|  
| Issue: Whether each of these atoms is propagated by replication and how 
| it impacts the replication process. 
|  
| 4.1 Create replicaContext on a single server 
|  
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the empty string (naming the root DSE), and the modification list 
| consists of a single item to add the distinguished name of the context 
| prefix to the attribute replicaContextRoots.  If the server responds 
| with the resultCode attributeOrValueExists, then the value is already 
| there.  If the server responds with a resultCode other than 
| attributeOrValueExists or success, then this is an error. 
|  
| 4.2 Delete replicaContext from a single server 
|  
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the empty string  (naming the root DSE), and the modifications list 
| consists of a single item, to delete the value of the distinguished 
| name of the context prefix from the attribute replicaContextRoots.  If 
|  
| the server responds with the resultCode noSuchAttribute, then the value 
| has already been removed.  If the server responds with a resultCode 
| other than noSuchAttribute or success, then this is an error. 
|  
| 4.3 Add area of replication to a server 
|  
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the context prefix of the replication context, and the modification 
| list consists of a single item to add the value replicationContext to 
| the attribute objectClass.  If the server responds with the resultCode 
| attributeOrValueExists, then the value is already there.  If the server 
| responds with a resultCode other than attributeOrValueExists or 
| success, then this is an error.  Should an error occur at this point, 
| the server is in an inconsistent state and needs to be fixed.  
|  
| After this step is completed, the server will begin storing change 
| information for this area of replication.  
|  
| WG ISSUE: If replicaContextRoots were an operational attribute, then it 
| would be possible to have the server maintain that attribute when 
| replicationContext is added or deleted.  Without it, these steps need 
|  
|  
| Moats, et al               Expires May 2002                    [Page 5] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| to be separate LDAP protocol operations and thus it is possible to have 
| inconsistent states. 
|  
| 4.4 Delete area of replication from a server 
|  
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the context prefix of the replication context, and the modification 
| list consists of a single item to remove the value replicationContext 
| to the attribute objectClass.  If the server responds with the 
| resultCode noSuchAttribute, then the value has already been removed.  
| If the server responds with a resultCode other than noSuchAttribute or 
| success, then this is an error.   
|  
| After this step is completed, the server will no longer replicate this 
| area of replication. 
|  
| 4.5 Copy base of area of replication between servers 
| In this section, the 'target server' is the server on which the client 
| has just modified the root DSE. 
|  
| The client MUST separately contact another server, one that already 
| holds a copy of this replication context, and issue a SearchRequest on 
| that server in which the baseObject is the DN of the of base the area 
| of replication, the scope baseObject, the filter "(objectClass=*)" and 
| the attributes list "*".  If the client cannot obtain the single entry 
| at this point, the procedure will fail, and the client SHOULD invoke on 
| the slave server a ModifyRequest in which the object field is the empty 
| string, and the modifications list consists of a single item, a delete 
| of the attribute replicaContextRoots with the value the distinguished 
| name of the context prefix. 
|  
| WG Issue: Do we need the ability to copy (i.e. read and set) all 
| operational attributes as part of this operation? If so, LDAP will need 
| a change. 
|  
| Now that it has the entry, the client SHOULD invoke an AddRequest on 
| the target server with entry set to the DN of the base of the area of 
| replication and attributes the same list as obtained in the previous 
| search. 
|  
| If the server returns a resultCode other than success, it is an error, 
| and the server will be in an inconsistent state. 
|  
| 4.6 Create server entry in area of replication 
|  
| Each server needs to have in its copy of the area of replication a 
| replicaSubentry for each of the servers involved in replicating that 
| area before replication can be started. These entries MUST have the 
| following attributes: 
|  
| 1.   objectclass, with values top, ldapSubentry and replicaSubentry 
| 2.   cn 
| 3.   replicaURI 
|  
| Moats, et al               Expires May 2002                    [Page 6] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| 4.   replicaType 
| 5.   replicaOnline 
|  
| and MAY contain other attributes, as described in the Information Model 
| [InfoMod]. 
|  
| WG Issue: This requires that all replicaSubentries representing the 
| same server have the same entryUUID.  How is this accomplished? 
|  
| 4.7 Delete Server Entry for an area of replication 
|  
| The client SHOULD issue a SearchRequest in which the baseObject is the 
| DN of the context prefix, the scope oneLevel, the filter 
| "(objectClass=replicaSubentries)" and the attributes list. For each 
| entry returned, the client SHOULD then issue a DeleteReques in which 
| the object field is the DN of the entry.   If the server responds with 
| the resultCode noSuchObject, then the entry has already been removed.  
| If the server responds with a resultCode other than noSuchObject or 
| success, then this is an error. 
|  
| 4.8 Modify replica 
|  
| 4.8.1     Change Replica Type 
|  
| Note: This section covers only the simple protocol operation to change 
| the replica type. Section 5.17 coverts the full set of operations for 
| converting from a ReadOnly to an Updateable replica. 
|  
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the replicationSubentry, and the modification list consists of a single 
| item to change the value of the attribute replicaType.  If the server 
| responds with the resultCode attributeOrValueExists, then the value is 
| already there.  If the server responds with a resultCode other than 
| attributeOrValueExists or success, then this is an error.  
|  
| 4.8.2     Change Between Full/Partial Replica 
|  
| TBD 
|  
| 4.8.3     Change Replica URI for one server for one area of replication 
|  
| Note: This section covers only the simple protocol operation to change 
| the replica type. Section 5.18 covers the full set of operations for 
| changing the replica URI on all servers. 
|  
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the replicationSubentry, and the modification list consists of a single 
| item to change the value of the attribute replicaURI to the new value.  
| If the server responds with the resultCode attributeOrValueExists, then 
| the value is already there.  If the server responds with a resultCode 
| other than attributeOrValueExists or success, then this is an error. 
|  
| 4.9 Add Replication Agreement 
|  
| TBD 
| Moats, et al               Expires May 2002                    [Page 7] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| 4.10 Delete Replication Agreement 
|  
| The termination of replication agreements should be done with caution 
| as it can easily result in a partition of the directory servers if 
| performed incorrectly. 
|  
| Once all replication agreements have been terminated between a server 
| and others for a naming context, then that copy of the context on the 
| server will be divergent, and any updates made there will not be 
| propagated to any other server. 
|  
| TBD 
|  
| 4.11 Modify Replication Agreement 
|  
| TBD 
|  
| 4.12 Suspend Replication 
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the DN of the target replicationSubentry, and the modification list 
| consists of a single item to change the value of replicaOnline 
| attribute to false. If the server responds with the resultCode 
| attributeOrValueExists, then the value is already there.  If the server 
| responds with a resultCode other than attributeOrValueExists or 
| success, then this is an error. 
|  
| 4.13 Resume Replication 
| The client SHOULD invoke a ModifyRequest in which the object field is 
| the DN of the target replicationSubentry, and the modification list 
| consists of a single item to change the value of replicaOnline 
| attribute to true. If the server responds with the resultCode 
| attributeOrValueExists, then the value is already there.  If the server 
| responds with a resultCode other than attributeOrValueExists or 
| success, then this is an error.  
|  
| 4.14 Trigger an Immediate Replica Cycle 
|  
| TBD 
|  
| Issue: An administrative client could trigger an immediate replication 
| cycle by issuing a "Trigger Replication" extended operation to the 
| supplier server.  The extended operation value specifies the DN of a 
| replication agreement between the supplier and target replicas, and the 
| type of replication session to be performed (full update or incremental 
| update).  The replication agreement is used to specify the target 
| replica, connection information, and authentication information. 
|  
| 5  Common Tasks 
| There are many tasks that administrators need to perform in a 
| replicated environment.  This section describes many typical tasks and 
| describes how they are performed in terms of the atoms defined above. 
|  
|  
| Moats, et al               Expires May 2002                    [Page 8] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| 5.1 Add a new replica to an existing replica group 
|  
| TBD 
|  
| 5.1.1     Large area of replication support 
|  
| In some cases, an area of replication is so large or available 
| bandwidth so small that out-of-band mechanisms (e.g. mailing a tape) 
| need to be used to transport the initial copy from the source to the 
| target.  The target then needs to be updated with changes made to the 
| source since the copy was made.  This section describes how this 
| situation is handled. 
|  
| Details TBD. 
|  
| WG Issue: is LDIF appropriate for this transport?  If so, how do we 
| carry replication meta-data (e.g. CSNs)? 
|  
| 5.2 Set up (but do not start) replication between two servers 
|  
| TBD 
|  
| 5.3 Set up (but do not start) replication between a server and an 
|     existing replica group 
|  
| TBD 
|  
| 5.4 Verify replication information is present between two servers 
|  
| TBD 
|  
| 5.5 Start replication between two servers. 
|  
| For this operation, the client SHOULD follow the steps in Section 5.2 
| followed by starting replication as specified in Section 4.13. 
|  
| 5.6 Start replication between an existing replica group and a new 
|     server 
| For this operation, the client SHOULD follow the steps in Section 5.3 
| followed by starting replication as specified in Section 4.13. 
|  
| 5.7 Temporarily Suspend all replication activity from a given server 
|  
| TBD  
|  
| 5.8 Halt replication on all areas of a server 
|  
| TBD 
|  
| 5.9 List status of a particular area of replication on a given server 
|  
| TBD 
|  
| Moats, et al               Expires May 2002                    [Page 9] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
|  
| 5.10 List all areas of replication defined on a given server and their 
|     status 
|  
| TBD 
|  
| 5.11 Restore a server and replication agreements after a server crash 
|  
| TBD 
|  
| 5.12 Split an Area of Replication 
|  
| To split an area of replication, the atoms are: 
| 1.   Add the subordinate area of replication to the servers' 
|      replicaContextRoots (Section 4.1) 
| 2.   Add the replicationContext objectclass to the root entry of the 
|      area of replication (Section 4.3) 
| 3.   Create replicaSubentry objects under the new area of replication 
|      for each replica of the parent area of replication (Section 4.6) 
| 4.   Create replicaAgreement objects (and schedules?) under the new 
|      replicaSubentries, where agreements are created that correspond to 
|      each agreement defined for the parent (Section 4.9). 
| These operations must be performed on each server containing a replica 
| of the parent area of replication.   
|  
| WG Issue: Extended op or not? The rationale behind an extended 
| operation is that this should be a mechanical process.  Having a 
| mechanism to "replicate" this from one server to the others: 
| - reduces likelihood of missing something 
| - allows replication framework to ensure that this information gets to 
|   every server in the event that a server is down or some other error 
|   prevents the client from completing all of these operations. 
|  
| 5.13 Move an existing area of replication to a new server  
|  
| TBD 
|  
| 5.14 Join two Areas of Replication 
|  
| This section describes how to join two areas of replication. 
|  
| 5.14.1    Preconditions 
|  
| Before joining two areas of replication there are certain preconditions 
| that need to be satisfied: 
| 1.   Any server that contains a replica of one area of replication must 
|      also contain a replica of the other area of replication. This may 
|      require copying either area of replication to additional servers, 
|      or deleting either area of replication from servers. 
| 2.   The replicas on any given server MUST be of the same type.  Both 
|      replicas must be updateable, both-readonly, or both primary.  
|      Furthermore, if the replicas are readonly, they must both be full 
|      replicas, or must both be fractional replicas with identical 
|      fractional entry specifications. 
|  
| 5.14.2    Procedure 
|  
|  
| Moats, et al               Expires May 2002                   [Page 10] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| 1. On each server, delete the replicationContext objectclass value from 
|   the subordinate area of replication (Section TBD). 
|    
|   We'd like this to be replicated under the parent area of replication, 
|   and we'd like this to have the affect of causing all not yet 
|   replicated updates and future client changes as if they occurred 
|   under the parent area f replication.  This is going to cause problems 
|   with respect to CSNs if there are "old" changes in the subordinate 
|   context.  Maybe we require that there be no pending updates?  This is 
|   going to be potentially ugly. 
| 2. 
  Delete all replication agreements for the subordinate area of 
|   replication 
| 3. 
  Delete all replicaSubentries for the subordinate area of replication 
|  
| 5.14.3    Server requirements 
|  
| When the replicationContext objectclass is removed from the root of an 
| area of replication, the server MUST immediately treat entries within 
| the area of replication as belonging to the parent area of replication 
| (if there is any).  This includes replicating any pending replication 
| updates (those not yet replicated to other replicas) as if they 
| occurred under the parent area of replication, as well as preserving 
| any Lost and Found entries. 
|  
| If a server receives a request to delete the replicationContext from an 
| area of replication, and there is a parent area of replication, the 
| Server MUST verify that these replicas are of the same type, and if 
| fractional, that the fractional entry specifications are identical.  If 
| the replicas are not of the same type, the request MUST be failed with 
| resultCode unwillingToPerform. 
|  
| 5.15 Stop Replicating an Area of Replication. 
|  
| This section describes how to stop replicating an area of replication.  
| At the end of the procedure, the subtree represented by the area of 
| replication will exist on one server, all replication agreements will 
| have been deleted, and the root of the area of replication will no 
| longer be an area of replication.  The server on which the subtree will 
| remain is referred to as the surviving replica.   
| To stop replicating an area of replication, a client with 
| administrative authority should perform the following operations: 
|  
| 1.   Halt replication 
|  
| After halting, the client MAY optionally delete information by: 
|  
| 2.   Delete all replication agreements (Section 4.10). 
| 3.   Delete all replicaSubentries under the area of replication 
|      (section 4.7)  
| 4.   Issue a modifyRequest to the surviving server where the object 
|      field is the DN of the area of replication, and the modifications 
|      list consists of a single item, delete the attribute objectclasss 
|      with value replicationContext. 
|  
| Moats, et al               Expires May 2002                   [Page 11] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| 5.   Delete replicaContext from that server (Section 4.2) 
| 6.   Delete the area of replication from servers containing other 
|      replicas (Section 4.4). 
|  
| Note that client updates accepted on the non-surviving replicas during 
| this procedure may be lost (because they were not replicated to the 
| surviving server). 
|  
| 5.16 Suspending and Resuming Replication 
|  
| To suspend replication of an area of replication to a specific server, 
| an administrative client can perform a modifyRequest of the 
| replicaSubentry, with a modification list replacing the replicaOnline 
| attribute with the value false.   Performing this request on the 
| specified server causes the server to stop accepting or initiating 
| replication requests for that area of replication.  This procedure can 
| also be performed on any other replica.  The modifyRequest will be 
| replicated to other servers.  When a server other than that specified 
| by the replicaSubentry receives the request the server MUST stop 
| sending replication updates to the specified server.  The unsent 
| changes MUST be saved until the replicaOnline attribute is chnaged to 
| true.  Servers MUST continue to repond to replication updates sent from 
| the specified server. 
|  
| To resume replication of an area of replication to a specific server, 
| an administrative client can perform a modifyRequest of the 
| replicaSubentry, with a modification list replacing the replicaOnline 
| attribute with the value false.   This request must be performed on the 
| specified server, or it will not resume replication.  This operation 
| may also be performed on other servers. 
|  
| 5.17 Convert a read-only replica to an updateable replica 
|  
| TBD 
|  
| 5.18 Changing Replica URI on all servers handling an area of 
|     replication 
|  
| The client issues this request to the server whose address has been 
| changed, which replicates it to the other replicas like other client 
| updates.  It may be necessary to issue the same request to other 
| replicas, for example, when the server does not have proper replication 
| agreements to fully replicate this change (as in consumer initiated 
| replication). 
|  
| 5.19 Postpone a Replica Cycle to a Later Time 
|  
| TBD 
|  
| 5.20 Examine Replication Audit History on a Server 
|  
| TBD 
|  
| 5.21 Compare Two Replicas on Two Servers for Differences 
|  
| TBD 
|  
| 5.22 Fix an Entry Without Triggering Replication 
|  
| When conflicts cause entries to be put in the Lost+Found area, the 
| administrator needs a mechanism to make appropriate changes.  These 
| Moats, et al               Expires May 2002                   [Page 12] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| changes should not trigger replication since they are used to fix 
| previous replication problems.  In addition, these changes may include 
| fixes to UUIDs, CSNs, or other control data that cannot be changed 
| using normal LDAP operations. 
|  
| TBD 
|  
| 5.23 Check Reported Schema Mismatches Discovered During Replication 
|  
| TBD 
|  
| 5.24 Adding a new directory server to a replica group and initializing 
|     the contents 
|  
| In this case, the client: 
|  
| 1. Creates the replicaContext on the new server (section 4.1) 
| 2. Copies the base entry for the area of replication from a source to 
| the target (section 4.5) 
| 3. 
  Create the entries for the new server on all servers in the replica 
|   group (section 4.6) 
| 4. 
  Create the entries for the existing replica group servers on the new 
|   (section 4.6) 
| 5. 
  Create the replication agreement on all servers (section 4.9) 
| 6. 
  Client issues a "Initiate Full Update" request to a full replica for 
|   the new replica -- or new replica requests consumer initiated full 
|   update 
|  
|  
|  
| 5.25 Restore from the master failure in a single-master system 
|  
| TBD 
|  
| 6  Formal Specifications 
|  
| The Replica Management features depend heavily on defined LDAP and LDUP 
| structure, operations, and data formats.  But some changes will be 
| needed to accommodate Replica Management.  All these changes are pulled 
| together in this section for easy reference. 
|  
| 6.1 New/Modified Object Classes 
|  
| TBD 
|  
| 6.2 New/Modified Attributes 
|  
| TBD 
|  
| 6.3 New/Modified Extended Operations 
|  
| Trigger Replica Operation 
|  
| TBD 
|  
|  
| Moats, et al               Expires May 2002                   [Page 13] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
|  
| 6.4 New/Modified Replication Primitives 
|  
| TBD 
|  
| 7  Security Considerations 
|  
| In all cases, it is assumed that the client establishes a connection to 
| the LDAP server and SHOULD authenticate using a recommended 
| authentication method [RFC2829] that establishes the identity of the 
| client user and SHOULD provide for connection integrity.  In 
| deployments where the underlying network service is vulnerable to 
| eavesdropping and clients are intending to retrieve sensitive server 
| credentials, the chosen method SHOULD also provide for encryption of 
| data in transit. 
|  
| In general, where the client is unaware of any network level protection 
| services, it is RECOMMENDED that the client immediately after 
| connection establishment invoke Start TLS to establish connection 
| integrity and confidentiality, and follow this by authentication by one 
| of: 
|  
|   - the "DIGEST-MD5" SASL mechanism, 
|   - the "simple" authentication choice, or 
|   - the "EXTERNAL" SASL mechanism if the client provided its  
|      certificate during TLS establishment. 
|  
| The client MAY determine the supported authentication mechanisms of the 
| server from the supportedSASLMechanisms attribute of the root DSE after 
| Start TLS has been invoked, and use this to decide whether to use 
| DIGEST-MD5 or EXTERNAL.  See [RFC2830] for more information on TLS. 
|  
| 8  Acknowledgements 
|  
| Thanks to Mark Wahl and Ed Reed for providing a lot of the initial 
| text. 
|  
| This document is a product of the LDUP Working Group of the IETF.  The 
| contributions of its members are greatly appreciated. 
|  
| 9  References 
| [Arch] J. Merrells, E. Reed, U. Srinvasan, "LDAP Replication 
| Architecture", draft-ietf-ldup-model-01.txt. 
|  
| [InfoMod] E. Reed, "LDAP Replication Information Model", draft-ietf-
| ldup-infomod-00.txt 
|  
| [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate 
| Requirement Levels", RFC 2119, March 1997. 
|  
| [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL Morgan, "Authentication 
| Methods for LDAP", RFC 2829, May 2000. 
|  
|  
|  
|  
| Moats, et al               Expires May 2002                   [Page 14] 

|  
|  
| INTERNET DRAFT     Mandatory LDAP Replica Management      November 2001 
| [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access 
| Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 
| 2000. 
|  
| Author's Addresses: 
|  
| Ryan Moats 
| Lemur Networks, Inc. 
| Email: rmoats@lemurnetworks.net 
|  
| Rick Huber 
| AT&T Laboratories 
| Email: rvh@qsun.att.com 
|  
| John McMeeking 
| IBM 
| Email: jmcmeek@us.ibm.com 
|  
| 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 
| 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. 
| 
| 
| 
| 
| 
| 
| 
| Moats, et al               Expires May 2002                   [Page 15] 



From owner-ietf-ldup@mail.imc.org  Wed Nov 14 04:51:45 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16908
	for <ldup-archive@lists.ietf.org>; Wed, 14 Nov 2001 04:51:45 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAE9XCh27324
	for ietf-ldup-bks; Wed, 14 Nov 2001 01:33:12 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAE9XA827310
	for <ietf-ldup@imc.org>; Wed, 14 Nov 2001 01:33:10 -0800 (PST)
Received: from sunfra.France.Sun.COM ([129.157.188.1])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23140;
	Wed, 14 Nov 2001 01:33:00 -0800 (PST)
Received: from hamble.France.Sun.COM (hamble.France.Sun.COM [129.157.192.53])
	by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id KAA02620;
	Wed, 14 Nov 2001 10:32:58 +0100 (MET)
Received: from sun.com (localhost [127.0.0.1])
	by hamble.France.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08969;
	Wed, 14 Nov 2001 10:30:44 +0100 (MET)
Message-ID: <3BF239C4.AB8C3B40@sun.com>
Date: Wed, 14 Nov 2001 10:30:44 +0100
From: Rob Byrne - Sun Microsystems <robert.byrne@Sun.COM>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Wahl <Mark.Wahl@Sun.COM>
CC: john.strassner@intelliden.com, christopher.apple@unitedmessaging.com,
        roland@catalogix.se, ietf-ldup@imc.org, ietf-ldapext@netscape.com
Subject: Re: moving access control discussion to LDUP
References: <3BF15936.65CD9072@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



All,

My own (vendor-centric) opinion on the progreess of the acl draft, is that,
unfortunately, in LDAP life-time terms it is very (if not, too) late to
successfully progress this to a standard.

I would categorize the main problem as "entrenched vendors".  Seems like
everyone agrees in principle that standard access control would be a good idea
but when it comes to the crunch vendors are reluctant to reinvest in developing
a new access control system in their servers.  So it seems the best we could do
would be to preserve the work (some of which may still be useful to vendors
polishing their  implementations) by moving it to the experimental or
informational category.

I think there may also be scope for pulling some of the sections out and
submitting them as independent ID's; for example the getEffectiveRights section
could probably be expressed in sufficiently general terms that any vendor could
support it.

Perhaps the best opportunity  for  standard directory access acontrol will occur
as/if directories evolve to integrate more with the XML world.  The XML guys are
currently recasting the wheel in XML terms and for example the XACML work stands
a chance of success as they don't have the entrenched vendor problem.

I would advise the LDUP chairs to poll the LDUP group and ensure that there is
enough (preferably more than enough!) support for completing the acl draft in
LDUP, before adopting it.

Rob.

Mark Wahl wrote:

> It may be worthwhile to consider adding the access control standardization
> discussion to LDUP, as LDUP will need the replication of access control
> information for many of its scenarios.  This activity was ongoing in LDAPEXT,
> but LDAPEXT is shutting down and has not reached rough consensus on
> access control specification.
>
> Mark Wahl
> Sun Microsystems Inc.



From owner-ietf-ldup@mail.imc.org  Wed Nov 14 07:20:40 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19378
	for <ldup-archive@odin.ietf.org>; Wed, 14 Nov 2001 07:20:39 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAEC2fM11727
	for ietf-ldup-bks; Wed, 14 Nov 2001 04:02:41 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEC2e811722
	for <ietf-ldup@imc.org>; Wed, 14 Nov 2001 04:02:40 -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 HAA18659;
	Wed, 14 Nov 2001 07:02:37 -0500 (EST)
Message-Id: <200111141202.HAA18659@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-infomod-04.txt
Date: Wed, 14 Nov 2001 07:02:37 -0500
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=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		: LDUP Replication Information Model
	Author(s)	: E. Reed, T. Hahn
	Filename	: draft-ietf-ldup-infomod-04.txt
	Pages		: 32
	Date		: 13-Nov-01
	
[LDUP Model] describes the architectural approach to replication of
LDAP directory contents.  This document describes the information
model and schema elements which support LDAP Replication Services
which conform to [LDUP Model].

Directory schema is extended to provide object classes, subentries,
and attributes to describe areas of the namespace which are under
common administrative authority, units of replication (ie, subtrees,
or partitions of the namespace, which are replicated), servers which
hold replicas of various types for the various partitions of the
namespace, which namespaces are held on given servers, and the
progress of various namespace management and replication operations.
Among other things, this knowledge of where directory content is
located will provide the basis for dynamic generation of LDAP
referrals for clients who can follow them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldup-infomod-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-infomod-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:	<20011113143814.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldup-infomod-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ldup-infomod-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011113143814.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ldup@mail.imc.org  Wed Nov 14 07:23:47 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19443
	for <ldup-archive@odin.ietf.org>; Wed, 14 Nov 2001 07:23:46 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAEC2ke11736
	for ietf-ldup-bks; Wed, 14 Nov 2001 04:02:46 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEC2j811731
	for <ietf-ldup@imc.org>; Wed, 14 Nov 2001 04:02:45 -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 HAA18675;
	Wed, 14 Nov 2001 07:02:43 -0500 (EST)
Message-Id: <200111141202.HAA18675@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-protocol-03.txt
Date: Wed, 14 Nov 2001 07:02:42 -0500
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=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		: The LDUP Replication Update Protocol
	Author(s)	: E. Stokes, G. Good, R. Harrison, T. Hahn
	Filename	: draft-ietf-ldup-protocol-03.txt
	Pages		: 19
	Date		: 13-Nov-01
	
The protocol described in this document is designed to allow one 
LDAP server to replicate its directory content to another LDAP 
server. The protocol is designed to be used in a replication 
configuration where multiple updateable servers are present. 
Provisions are made in the protocol to carry information that allows 
the server receiving updates to apply a total ordering to all 
updates in the replicated system. This total ordering allows all 
replicas to correctly resolve conflicts that arise when LDAP clients 
submit changes to different servers that later replicate to one 
another.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldup-protocol-03.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-protocol-03.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:	<20011113143834.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldup-protocol-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ldup-protocol-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011113143834.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ldup@mail.imc.org  Wed Nov 14 12:05:22 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04113
	for <ldup-archive@odin.ietf.org>; Wed, 14 Nov 2001 12:05:21 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAEGY4103066
	for ietf-ldup-bks; Wed, 14 Nov 2001 08:34:04 -0800 (PST)
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.21])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEGY2803062
	for <ietf-ldup@imc.org>; Wed, 14 Nov 2001 08:34:02 -0800 (PST)
Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25])
	by va2mc.ummailbox.net with ESMTP id N1114-1133-3d5900;
	Wed, 14 Nov 2001 16:33:32 GMT
Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21)
	id <V622GC7B>; Wed, 14 Nov 2001 11:30:20 -0500
Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACF91@ex04.ummail.com>
From: Christopher Apple <christopher.apple@UnitedMessaging.net>
To: "'Rob Byrne - Sun Microsystems'" <robert.byrne@Sun.COM>,
        Mark Wahl
	 <Mark.Wahl@Sun.COM>
Cc: john.strassner@intelliden.com, roland@catalogix.se, ietf-ldup@imc.org,
        ietf-ldapext@netscape.com
Subject: RE: moving access control discussion to LDUP
Date: Wed, 14 Nov 2001 11:30:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_002F_01C16CFF.92F62630"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C16CFF.92F62630
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0030_01C16CFF.92F62630"


------=_NextPart_001_0030_01C16CFF.92F62630
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Neither John nor I are wed to the idea of keeping the ACM document
in exactly its present form.

What the WG has clearly achieved consensus on (several times and
each time the issue has been raised) is that without some baseline
ACM for LDAP, LDUP has little chance of being inteoperable (at least
not in a secure way) across implementations from multiple vendors.

Some of the more active WG members have explicitly requested that
the LDUP co-chairs consider moving the work from LDAPEXT to LDUP
as LDAPEXT is closing down and concensus has not been reached on
the ACM document's content.

It may be that we have to specify in LDUP the minimum required
ACM for LDUP to work as expected. We're just proposing that the
current document be used as a starting point for discussion within
the LDUP WG.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com> 
(V) +1 610 425 2860


-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:robert.byrne@sun.com]
Sent: Wednesday, November 14, 2001 4:31 AM
To: Mark Wahl
Cc: john.strassner@intelliden.com;
christopher.apple@unitedmessaging.com; roland@catalogix.se;
ietf-ldup@imc.org; ietf-ldapext@netscape.com
Subject: Re: moving access control discussion to LDUP



All,

My own (vendor-centric) opinion on the progreess of the acl draft, is
that,
unfortunately, in LDAP life-time terms it is very (if not, too) late to
successfully progress this to a standard.

I would categorize the main problem as "entrenched vendors".  Seems like
everyone agrees in principle that standard access control would be a
good idea
but when it comes to the crunch vendors are reluctant to reinvest in
developing
a new access control system in their servers.  So it seems the best we
could do
would be to preserve the work (some of which may still be useful to
vendors
polishing their  implementations) by moving it to the experimental or
informational category.

I think there may also be scope for pulling some of the sections out and
submitting them as independent ID's; for example the getEffectiveRights
section
could probably be expressed in sufficiently general terms that any
vendor could
support it.

Perhaps the best opportunity  for  standard directory access acontrol
will occur
as/if directories evolve to integrate more with the XML world.  The XML
guys are
currently recasting the wheel in XML terms and for example the XACML
work stands
a chance of success as they don't have the entrenched vendor problem.

I would advise the LDUP chairs to poll the LDUP group and ensure that
there is
enough (preferably more than enough!) support for completing the acl
draft in
LDUP, before adopting it.

Rob.

Mark Wahl wrote:

> It may be worthwhile to consider adding the access control
standardization
> discussion to LDUP, as LDUP will need the replication of access
control
> information for many of its scenarios.  This activity was ongoing in
LDAPEXT,
> but LDAPEXT is shutting down and has not reached rough consensus on
> access control specification.
>
> Mark Wahl
> Sun Microsystems Inc.

------=_NextPart_001_0030_01C16CFF.92F62630
Content-Type: text/x-vcard;
	name="Christopher Apple (E-mail).vcf"
Content-Disposition: attachment;
	filename="Christopher Apple (E-mail).vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott =
Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D
ica
EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com
REV:20010925T181636Z
END:VCARD

------=_NextPart_001_0030_01C16CFF.92F62630--

------=_NextPart_000_002F_01C16CFF.92F62630
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw
ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk
bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW
18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo
AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC
AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l
dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ
bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U
bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg
AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD
T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT
h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh
dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3
UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8
9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTExNDE2MjkwOFowIwYJKoZIhvcNAQkEMRYEFAIdsbDvqF8h
waDpUfMCmPY+IYUGMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h
aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGATDeWb1qemL3vJL3nyAJWWdWK
iOuUjlrC+SQS1LEaH+WFyl8s12HiNRZGOEWrNDTKcTxVLIWjnkuLhwez7ir/R/QaY1IDJoA/3Zj3
vuVxpfPUdFVqc5We/8Dxww1tTwyVgMmabLXzCeRX7hEsUymFfuW2ynBX7/PMxLhTkA86p3IAAAAA
AAA=

------=_NextPart_000_002F_01C16CFF.92F62630--



From owner-ietf-ldup@mail.imc.org  Wed Nov 14 17:23:22 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19454
	for <ldup-archive@lists.ietf.org>; Wed, 14 Nov 2001 17:23:21 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAELsl925929
	for ietf-ldup-bks; Wed, 14 Nov 2001 13:54:47 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAELsk825924
	for <ietf-ldup@imc.org>; Wed, 14 Nov 2001 13:54:46 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAELxfC34184;
	Wed, 14 Nov 2001 21:59:41 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011114134304.016f4740@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 14 Nov 2001 13:53:14 -0800
To: Christopher Apple <christopher.apple@UnitedMessaging.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: moving access control discussion to LDUP
Cc: "'Rob Byrne - Sun Microsystems'" <robert.byrne@Sun.COM>,
        Mark Wahl <Mark.Wahl@Sun.COM>, john.strassner@intelliden.com,
        roland@catalogix.se, ietf-ldup@imc.org
In-Reply-To: <504D6456F0C87F4C8B11FB0C2021D6F602DACF91@ex04.ummail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Please note that I feel the LDUP WG should not undertake
the LDAP ACM work or any other new work.  The LDUP WG
needs to narrow its focus and trim its workload if it
is ever to successfully conclude.

And also I ask that the charter be clarified as to the
extent of work this WG is undertaking (or intends to
undertake).  In particular, the charter should state
whether or not the group intends to:
	1) Update LDAPv3 "core" specification (including
	   its normative references),
	2) Define an ACM for LDAPv3, and/or
	3) Define an authentication identity to
	   authorization identity mapping scheme.

(Note that the mapping scheme is needed for an ACM
to provide any reasonable level of consistent access
to client entities in a replicated environment.)

Kurt



From owner-ietf-ldup@mail.imc.org  Wed Nov 14 17:27:05 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19535
	for <ldup-archive@lists.ietf.org>; Wed, 14 Nov 2001 17:27:05 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAEM5wh27118
	for ietf-ldup-bks; Wed, 14 Nov 2001 14:05:58 -0800 (PST)
Received: from cosds003.continuumnetworks.com ([12.41.184.243])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEM5v827113
	for <ietf-ldup@imc.org>; Wed, 14 Nov 2001 14:05:57 -0800 (PST)
Received: from FARILJCS ([12.41.186.49]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GMT9D900.G6A; Wed, 14 Nov 2001 15:05:33 -0700 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        "Christopher Apple" <christopher.apple@UnitedMessaging.net>
Cc: "'Rob Byrne - Sun Microsystems'" <robert.byrne@Sun.COM>,
        "Mark Wahl" <Mark.Wahl@Sun.COM>, <roland@catalogix.se>,
        <ietf-ldup@imc.org>
Subject: RE: moving access control discussion to LDUP
Date: Wed, 14 Nov 2001 15:05:39 -0700
Message-ID: <FCEKLEHMPIHFNLCMKHAMIEELCPAA.john.strassner@intelliden.com>
MIME-Version: 1.0
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: <5.1.0.14.0.20011114134304.016f4740@127.0.0.1>
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_01EA_01C16D1D.D2920A70";
	micalg=SHA1;
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_01EA_01C16D1D.D2920A70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

So how will the protocol be able to interoperate without a common ACM?

thanks,
John

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, November 14, 2001 2:53 PM
To: Christopher Apple
Cc: 'Rob Byrne - Sun Microsystems'; Mark Wahl;
john.strassner@intelliden.com; roland@catalogix.se; ietf-ldup@imc.org
Subject: RE: moving access control discussion to LDUP


Please note that I feel the LDUP WG should not undertake
the LDAP ACM work or any other new work.  The LDUP WG
needs to narrow its focus and trim its workload if it
is ever to successfully conclude.

And also I ask that the charter be clarified as to the
extent of work this WG is undertaking (or intends to
undertake).  In particular, the charter should state
whether or not the group intends to:
	1) Update LDAPv3 "core" specification (including
	   its normative references),
	2) Define an ACM for LDAPv3, and/or
	3) Define an authentication identity to
	   authorization identity mapping scheme.

(Note that the mapping scheme is needed for an ACM
to provide any reasonable level of consistent access
to client entities in a replicated environment.)

Kurt


------=_NextPart_000_01EA_01C16D1D.D2920A70
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTExNDIyMDUzOVowIwYJKoZIhvcNAQkEMRYEFLCN/FED6ffpG/QGlo1PpOK18uC8
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAo3YS
QMA38SrZYIJ+a43pgwO/ZZF6Avst/Qdc9JPoSbYpOQ5mDR6IbksCS56xXFoFcaJyaajOgVf5q2xc
ekPrTPJbZC1tx+DlV91lhHFNGERzTZVvptd1Oj3YlmjUo6hY7WpHva/wUVl3S3vptIlM0xfC+1OJ
cha2e4Gpj5NFzksAAAAAAAA=

------=_NextPart_000_01EA_01C16D1D.D2920A70--



From owner-ietf-ldup@mail.imc.org  Wed Nov 14 18:34:21 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21482
	for <ldup-archive@lists.ietf.org>; Wed, 14 Nov 2001 18:34:20 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAENF5N04778
	for ietf-ldup-bks; Wed, 14 Nov 2001 15:15:05 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAENF4804774
	for <ietf-ldup@imc.org>; Wed, 14 Nov 2001 15:15:04 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAENK4C34466;
	Wed, 14 Nov 2001 23:20:04 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011114140834.016a3568@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 14 Nov 2001 15:14:30 -0800
To: <john.strassner@intelliden.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: moving access control discussion to LDUP
Cc: "Christopher Apple" <christopher.apple@UnitedMessaging.net>,
        "'Rob Byrne - Sun Microsystems'" <robert.byrne@Sun.COM>,
        "Mark Wahl" <Mark.Wahl@Sun.COM>, <roland@catalogix.se>,
        <ietf-ldup@imc.org>
In-Reply-To: <FCEKLEHMPIHFNLCMKHAMIEELCPAA.john.strassner@intelliden.com
 >
References: <5.1.0.14.0.20011114134304.016f4740@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 02:05 PM 2001-11-14, John Strassner wrote:
>So how will the protocol be able to interoperate without a common ACM?

At the level of interoperability this WG is attempting to achieve,
it cannot.  But then, this WG will needs much more than a common
ACM to provide the level of interoperability it is attempting to
achieve.

IMO, the WG as bitten off more that it can chew and bitting off
more will only cause the WG to choke.

So, I wonder, what is beyond scope of this working group?

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 07:31:58 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19685
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 07:31:57 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAFC6vI22986
	for ietf-ldup-bks; Thu, 15 Nov 2001 04:06:57 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFC6s822982
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 04:06:54 -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 HAA18779;
	Thu, 15 Nov 2001 07:06:53 -0500 (EST)
Message-Id: <200111151206.HAA18779@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-mrm-00.txt
Date: Thu, 15 Nov 2001 07:06:52 -0500
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=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		: Mandatory LDAP Replica Management
	Author(s)	: R. Moats, R. Huber, J. McMeeking
	Filename	: draft-ietf-ldup-mrm-00.txt
	Pages		: 15
	Date		: 14-Nov-01
	
The goal of standards for LDAP replication is to allow interoperable 
replication among products from many different vendors.  Defining the 
mechanism to move data among replicas is a necessary part of this work, 
but management of the replicated environment must also be standardized 
for replication to be truly interoperable.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldup-mrm-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ldup-mrm-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011114151117.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldup-mrm-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ldup-mrm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011114151117.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ldup@mail.imc.org  Thu Nov 15 09:36:32 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25313
	for <ldup-archive@lists.ietf.org>; Thu, 15 Nov 2001 09:36:31 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAFEG4C29958
	for ietf-ldup-bks; Thu, 15 Nov 2001 06:16:04 -0800 (PST)
Received: from hotmail.com (f233.law9.hotmail.com [64.4.9.233])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFEFx829941
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 06:16:03 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 15 Nov 2001 06:15:47 -0800
Received: from 65.14.159.170 by lw9fd.law9.hotmail.msn.com with HTTP;
	Thu, 15 Nov 2001 14:15:47 GMT
X-Originating-IP: [65.14.159.170]
From: "Chris Apple" <imcapple@hotmail.com>
To: ietf-ldup@imc.org, ietf-ldapbis@OpenLDAP.org, ietf-ldapext@netscape.com
Cc: paf@cisco.com, john.strassner@intelliden.com, ned.freed@mrochek.com,
        scoya@ietf.org
Subject: e-mail address change
Date: Thu, 15 Nov 2001 09:15:47 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F2334zadTMVwVn20lbh00022ead@hotmail.com>
X-OriginalArrivalTime: 15 Nov 2001 14:15:47.0662 (UTC) FILETIME=[0591AEE0:01C16DE0]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


My e-mail address has changed again.

I have requested of my former employer to have e-mail addressed to:

   christopher.apple@unitedmessaging.com

forwarded to:

   imcapple@hotmail.com

However, until further notice, please use imcapple@hotmail.com for all
IETF (and other) communications.

Chris Apple

Currently thinking from Olde City, Philadelphia about what life means...


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 11:08:48 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00331
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 11:08:47 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAFFfri04659
	for ietf-ldup-bks; Thu, 15 Nov 2001 07:41:53 -0800 (PST)
Received: from ssymexc.anassoc.com (anai.dslwan.toad.net [162.33.140.194])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFFfp804655
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 07:41:51 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Subject: RE: moving access control discussion to LDUP
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 15 Nov 2001 10:41:52 -0500
Message-ID: <A8A1D65941C3D94B896AD67D154C53AB0473D7@ssymexc.anassoc.com>
Thread-Topic: moving access control discussion to LDUP
Thread-Index: AcFtZ8nsWG5sDF0wQNOCIuCl7+XCQQAfXodA
From: "Matt Hirsch" <mhirsch@anassoc.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, <john.strassner@intelliden.com>
Cc: "Christopher Apple" <christopher.apple@UnitedMessaging.net>,
        "Rob Byrne - Sun Microsystems" <robert.byrne@Sun.COM>,
        "Mark Wahl" <Mark.Wahl@Sun.COM>, <roland@catalogix.se>,
        <ietf-ldup@imc.org>, "Roddy A. Sue (E-mail)" <saroddy@missi.ncsc.mil>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAFFfq804656
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


Hi all,


Typing on a government machine, I agree with Chris Apple.  We need to
continue development of the AC draft.  In my mind this document should
serve as the foundation for establishing security in managing,
controlling access to, and replicating information in the LDAP world.
It is obvious that LDAP is the directory access protocol of choice (at
least today and most likely for the next few years).  The Government, in
it's continuing drive to remain vendor independent and in compliance
with commercial standards, is extremely interested in continuing to
develop the Access Control LDAP standards and will most likely be able
to contribute to the furtherance of this early next year with the award
of a rather large contract that is geared towards standards development.

My vote (speaking for the NSA V51) is that we continue to develop the
Access Control Model for LDAP V3 in either the LDUP WG or in a revived
LDAP EXT WG tiger team and finish the draft to a RFC state.  At this
point, it could be turned over to the LDUP WG.

Regards,
Matt Hirsch

A&N Associates Inc.
Management & Technology Consulting
410-772-5060 ext 22 


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, November 14, 2001 6:15 PM
To: john.strassner@intelliden.com
Cc: Christopher Apple; 'Rob Byrne - Sun Microsystems'; Mark Wahl;
roland@catalogix.se; ietf-ldup@imc.org
Subject: RE: moving access control discussion to LDUP



At 02:05 PM 2001-11-14, John Strassner wrote:
>So how will the protocol be able to interoperate without a common ACM?

At the level of interoperability this WG is attempting to achieve,
it cannot.  But then, this WG will needs much more than a common
ACM to provide the level of interoperability it is attempting to
achieve.

IMO, the WG as bitten off more that it can chew and bitting off
more will only cause the WG to choke.

So, I wonder, what is beyond scope of this working group?

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 12:44:30 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07155
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 12:44:29 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFHOds14091
	for ietf-ldup-bks; Thu, 15 Nov 2001 09:24:39 -0800 (PST)
Received: from interlock2.lexmark.com (interlock2.lexmark.com [192.146.101.10])
	by above.proper.com (8.11.6/8.11.3) with SMTP id fAFHOc814087
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 09:24:38 -0800 (PST)
Received: by interlock2.lexmark.com id MAA21523
  (InterLock SMTP Gateway 4.2 for ietf-ldup@imc.org);
  Thu, 15 Nov 2001 12:22:52 -0500
Message-Id: <200111151722.MAA21523@interlock2.lexmark.com>
Received: by interlock2.lexmark.com (Protected-side Proxy Mail Agent-1);
  Thu, 15 Nov 2001 12:22:52 -0500
X-Lotus-Fromdomain: LEXMARK@LEXMTA
From: dsweigar@lexmark.com
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, john.strassner@intelliden.com,
        "Christopher Apple" <christopher.apple@UnitedMessaging.net>,
        "Rob Byrne - Sun Microsystems" <robert.byrne@Sun.COM>,
        "Mark Wahl" <Mark.Wahl@Sun.COM>, roland@catalogix.se,
        ietf-ldup@imc.org, "Roddy A. Sue (E-mail)" <saroddy@missi.ncsc.mil>,
        dsweigar@lexmark.com
Date: Thu, 15 Nov 2001 12:22:34 -0500
Subject: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>






Team:

I am curious if anyone in the group as researched a comparison of
LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.

I wonder if anyone would want to comment on this comparison ?

Dave




From owner-ietf-ldup@mail.imc.org  Thu Nov 15 12:57:34 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08087
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 12:57:33 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFHfpj14490
	for ietf-ldup-bks; Thu, 15 Nov 2001 09:41:51 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFHfm814486
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 09:41:48 -0800 (PST)
Received: from rowlf.Central.Sun.COM ([129.153.131.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00408;
	Thu, 15 Nov 2001 10:41:27 -0700 (MST)
Received: from sun.com (dhcp-aus07-187 [129.153.129.187])
	by rowlf.Central.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id fAFHfgl24852;
	Thu, 15 Nov 2001 11:41:42 -0600 (CST)
Message-ID: <3BF3FCDD.6CA90CEF@sun.com>
Date: Thu, 15 Nov 2001 11:35:25 -0600
From: Mark Wahl <Mark.Wahl@Sun.COM>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: dsweigar@lexmark.com
CC: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, john.strassner@intelliden.com,
        Christopher Apple <christopher.apple@UnitedMessaging.net>,
        Rob Byrne - Sun Microsystems <robert.byrne@Sun.COM>,
        roland@catalogix.se, ietf-ldup@imc.org,
        "Roddy A. Sue (E-mail)" <saroddy@missi.ncsc.mil>
Subject: Re: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.
References: <200111151722.MAA21523@interlock2.lexmark.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


dsweigar@lexmark.com wrote:
> 
> I am curious if anyone in the group as researched a comparison of
> LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.

A "vs" of particular implementations is not in the scope of a standards 
working group.  I would recommend that you consider instead contacting 
industry analysts or directory consultants that compare different LDAP 
implementations.  The Burton Group is one such organization.

Mark Wahl
Sun Microsystems Inc.


From owner-ietf-ldup@mail.imc.org  Thu Nov 15 14:30:32 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13991
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 14:30:31 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFJDx920094
	for ietf-ldup-bks; Thu, 15 Nov 2001 11:13:59 -0800 (PST)
Received: from metainc2.metagroup.com ([63.122.26.75])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFJDs820090
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 11:13:55 -0800 (PST)
Subject: Re: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.
To: Mark Wahl <Mark.Wahl@Sun.COM>
Cc: Christopher Apple <christopher.apple@UnitedMessaging.net>,
        dsweigar@lexmark.com, ietf-ldup@imc.org, john.strassner@intelliden.com,
        "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, owner-ietf-ldup@mail.imc.org,
        Rob Byrne - Sun Microsystems <robert.byrne@Sun.COM>,
        roland@catalogix.se, "Roddy A. Sue (E-mail)" <saroddy@missi.ncsc.mil>
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF32C5CD7F.1191470B-ON85256B05.00676044@metagroup.com>
From: Earl.Perkins@metagroup.com
Date: Thu, 15 Nov 2001 13:50:14 -0500
X-MIMETrack: Serialize by Router on METAINC2/META Group(Release 5.0.8 |June 18, 2001) at
 11/15/2001 02:07:02 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>



I monitor this thread and work for META Group, a competing firm
to Burton. I cover this space at META Group. If you would like a
perspective, let me know.

Earl Perkins
Sr. Program Director, Global Networking Strategies
META Group, Inc.
330 Morgan St, Unit 606, New Orleans, LA 70114, USA
Phone: 504.362.0291



                                                                                                                      
                    Mark Wahl                                                                                         
                    <Mark.Wahl@Sun.COM        To:     dsweigar@lexmark.com                                            
                    >                         cc:     "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,                         
                    Sent by:                  john.strassner@intelliden.com, Christopher Apple                        
                    owner-ietf-ldup@ma        <christopher.apple@UnitedMessaging.net>, Rob Byrne - Sun Microsystems   
                    il.imc.org                <robert.byrne@Sun.COM>, roland@catalogix.se, ietf-ldup@imc.org, "Roddy  
                                              A. Sue (E-mail)" <saroddy@missi.ncsc.mil>                               
                                              Subject:     Re: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2  
                    11/15/2001 12:35          back-end.                                                               
                    PM                                                                                                
                                                                                                                      
                                                                                                                      




dsweigar@lexmark.com wrote:
>
> I am curious if anyone in the group as researched a comparison
of
> LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.

A "vs" of particular implementations is not in the scope of a
standards
working group.  I would recommend that you consider instead
contacting
industry analysts or directory consultants that compare different
LDAP
implementations.  The Burton Group is one such organization.

Mark Wahl
Sun Microsystems Inc.




----------------------------------------------------------------
                         Register Today!
"Scaling the Peaks of CIO Performance: IT Excellence and Business
                         Transformation"
             META Group's Executive Directions Forum
                       December 3-4, 2001
Marriott's Camelback Inn Resort, Golf Club & Spa; Scottsdale, AZ
                 http://www.metagroup.com/ed2001
---------------------------------------------------------------/




From owner-ietf-ldup@mail.imc.org  Thu Nov 15 14:54:59 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15660
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 14:54:58 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFJRA920436
	for ietf-ldup-bks; Thu, 15 Nov 2001 11:27:10 -0800 (PST)
Received: from uxtpaprx1.pwcglobal.com (uxtpaprx1.pwcglobal.com [12.26.159.121])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFJR8820430
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 11:27:08 -0800 (PST)
Received: by uxtpaprx1.pwcglobal.com; id OAA05980; Thu, 15 Nov 2001 14:23:18 -0500 (EST)
From: <matthew.schwienteck@us.pwcglobal.com>
Received: from unknown(10.26.104.81) by uxtpaprx1.us.pw.com via smap (V5.5)
	id xma004614; Thu, 15 Nov 01 14:22:31 -0500
Received: from us-amsmta005.us.pw.com by uxtpabuf1.us.pw.com
 (PMDF V5.1-12 #U3932) with ESMTP id <0GMU002ZLWK8EI@uxtpabuf1.us.pw.com>; Thu,
 15 Nov 2001 14:24:09 -0500 (EST)
Date: Thu, 15 Nov 2001 13:25:25 -0600
Subject: Re: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.
To: dsweigar@lexmark.com
Cc: Kurt@OpenLDAP.org, john.strassner@intelliden.com,
        christopher.apple@UnitedMessaging.net, robert.byrne@Sun.COM,
        Mark.Wahl@Sun.COM, roland@catalogix.se, ietf-ldup@imc.org,
        saroddy@missi.ncsc.mil, dsweigar@lexmark.com
Message-id: <OF31FA3A4F.BCD19125-ON86256B05.006A508E@us.pw.com>
MIME-version: 1.0
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Content-type: text/plain; charset=us-ascii
X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.6
 |December 14, 2000) at 11/15/2001 02:25:42 PM
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>



It operates like any other LDAP v3 compliant directory (like iDS) that use
flat db back-ends.  I have not used is to any large extent, but I am very
familiar with Oracle Internet Directory (OID), which uses Oracle RDBMS as a
back end.   The scalability and performance are similar and maybe better on
OID if the backend is properly tuned.

Matt Schwienteck
Security Integration Services
PricewaterhouseCoopers
Houston, Tx
832-444-8168




dsweigar@lexmark.com@mail.imc.org on 11/15/2001 11:22:34 AM

Sent by:  owner-ietf-ldup@mail.imc.org

To:   "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
      john.strassner@intelliden.com, Christopher Apple
      <christopher.apple@UnitedMessaging.net>, Rob Byrne - Sun Microsystems
      <robert.byrne@Sun.COM>, Mark Wahl <Mark.Wahl@Sun.COM>,
      roland@catalogix.se, ietf-ldup@imc.org, "Roddy A. Sue (E-mail)"
      <saroddy@missi.ncsc.mil>, dsweigar@lexmark.com
cc:
Subject:  LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.







Team:

I am curious if anyone in the group as researched a comparison of
LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.

I wonder if anyone would want to comment on this comparison ?

Dave





----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 15:24:39 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17483
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 15:24:38 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFK77421658
	for ietf-ldup-bks; Thu, 15 Nov 2001 12:07:07 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFK6v821650
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 12:06:57 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 15 Nov 2001 12:06:35 -0800
Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Nov 2001 12:06:34 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 15 Nov 2001 12:06:21 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 15 Nov 2001 12:06:21 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Thu, 15 Nov 2001 12:05:41 -0800
Content-Class: urn:content-classes:message
Subject: FW: moving access control discussion to LDUP
MIME-Version: 1.0
Date: Thu, 15 Nov 2001 12:05:40 -0800
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_00BA_01C16D49.688680D0"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD02A87974@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: yes
Thread-Topic: moving access control discussion to LDUP
thread-index: AcFtWM6P6RjsDeNHQ4KJRWXYDK4EkQAMLG0AAAC5kjA=
From: "Paul Leach" <paulle@windows.microsoft.com>
To: <ietf-ldup@imc.org>
X-OriginalArrivalTime: 15 Nov 2001 20:05:41.0478 (UTC) FILETIME=[E6DBC860:01C16E10]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_00BA_01C16D49.688680D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

It could interop assuming that all data was public read-write, or public
read on all but one of the servers, with that one controlling who could
update (i.e., master-slave).

Taking this approach would let you factor the problems -- you could
focus on the replication issues, and when some future WG came up with a
common access control syntax and semantics, then it would just plug in.

> -----Original Message-----
> From: John Strassner [mailto:john.strassner@intelliden.com]
> Sent: Wednesday, November 14, 2001 2:06 PM
> To: Kurt D. Zeilenga; Christopher Apple
> Cc: 'Rob Byrne - Sun Microsystems'; Mark Wahl; 
> roland@catalogix.se; ietf-ldup@imc.org
> Subject: RE: moving access control discussion to LDUP
> 
> 
> So how will the protocol be able to interoperate without a common ACM?
> 
> thanks,
> John
> 
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, November 14, 2001 2:53 PM
> To: Christopher Apple
> Cc: 'Rob Byrne - Sun Microsystems'; Mark Wahl;
> john.strassner@intelliden.com; roland@catalogix.se; ietf-ldup@imc.org
> Subject: RE: moving access control discussion to LDUP
> 
> 
> Please note that I feel the LDUP WG should not undertake
> the LDAP ACM work or any other new work.  The LDUP WG
> needs to narrow its focus and trim its workload if it
> is ever to successfully conclude.
> 
> And also I ask that the charter be clarified as to the
> extent of work this WG is undertaking (or intends to
> undertake).  In particular, the charter should state whether 
> or not the group intends to:
> 	1) Update LDAPv3 "core" specification (including
> 	   its normative references),
> 	2) Define an ACM for LDAPv3, and/or
> 	3) Define an authentication identity to
> 	   authorization identity mapping scheme.
> 
> (Note that the mapping scheme is needed for an ACM
> to provide any reasonable level of consistent access
> to client entities in a replicated environment.)
> 
> Kurt
> 
> 

------=_NextPart_000_00BA_01C16D49.688680D0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkSzCCA0Aw
ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL
LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b
mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd
MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud
DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v
d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy
MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv
bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA
MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc
ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy
LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIGPzCCBf+gAwIBAgIKdZ/59AACAAAB
VjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT
BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X
DTAxMDkxNDAzMTY1MFoXDTAyMDkyMDIxMzMyOFowSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p
Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAupHMN0lJw9ae2Ic2yZBICCqeP2H6Re4B1Rnk+KETtF0S15jq
7ea5n/+z43Da9CqjunNJaLT7rX4o9NHUN7eP5aKlZ7aRP+EoT0wB51OPsjZKuFWptbdL7PEVHAuO
UrOOjyZ0ITR432vqcJ/L3AouTyuCuN7/1kw9tMMRl5erzkUCAwEAAaOCBG0wggRpMBAGCSsGAQQB
gjcVAQQDAgEBMCMGCSsGAQQBgjcVAgQWBBRdMJl7HuLsmpzfroTjjkV60iifVTAdBgNVHQ4EFgQU
yURWSpATfKnzMwZr3tCZu+fIzukwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUz8W6F/8txxCA9bkOmUpv9Jwr+xkwggI+
BgNVHR8EggI1MIICMTCCAi2gggIpoIICJYaB32xkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh
dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKSxDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUy
MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9
bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh
c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGX2h0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNv
bS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIo
MSkuY3JshoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIw
V2hpY2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049
U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2Nl
cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q
b2ludDCCAXMGCCsGAQUFBwEBBIIBZTCCAWEwgdUGCCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERF
ViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMl
MjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERD
PW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj
YXRpb25BdXRob3JpdHkwgYYGCCsGAQUFBzAChnpodHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29m
dC5jb20vQ2VydEVucm9sbC93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVy
bWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDIpLmNydDAJBgcqhkjOOAQDAy8AMCwCFFMe
+4NdwTMB4JPtUG8oni8k6DDeAhR524Ez1P2PwtOazvpFd7iVYMg9aDCCBmIwggXLoAMCAQICChLg
FhwAAQAOvNcwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m
dDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMTEwMzAxMzUw
MTZaFw0wMTEyMjkxMzUwMTZaMIHHMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQB
GRYJbWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxEDAOBgNVBAsTB0lNLVNlbGYxFzAV
BgNVBAsTDkxpZ2h0bHlNYW5hZ2VkMREwDwYDVQQLEwhMb3dUQ08tRTETMBEGA1UEAxMKUGF1bCBM
ZWFjaDErMCkGCSqGSIb3DQEJARYccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAq3i8nfgLW+y4W5u28D9e728xC+k+d5wgT1pI10wXhZYJLbUD
UAroJ4PSgEtt+Aj6j6TSxw7FCy9oV33m6SEyuqOm59+tIgj+ekteF1zlaV2nRKzrawu5/6j2hfTP
KlPrNZNeBPylQ7FrZkRpwxbp8JjvERVNLVrqlzAz7EhBWaUCAwEAAaOCA84wggPKMAsGA1UdDwQE
AwIEMDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYF
Kw4DAgcwCgYIKoZIhvcNAwcwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIjeDRiU6E15zDB4am
hvscj9O/phWHp77iCY6xrfFNAgFxAgECMBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcV
CgQOMAwwCgYIKwYBBQUHAwQwUwYDVR0RBEwwSqAqBgorBgEEAYI3FAIDoBwMGnBhdWxsZUBudGRl
di5taWNyb3NvZnQuY29tgRxwYXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMB0GA1UdDgQWBBRa
rhNngrObQx5TBdIaZibJHYSOJjAfBgNVHSMEGDAWgBTJRFZKkBN8qfMzBmve0Jm758jO6TCCASYG
A1UdHwSCAR0wggEZMIIBFaCCARGgggENhoHEbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENB
LENOPVdISUNBMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs
Q049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRl
UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZEaHR0
cDovL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJU1NVRTMl
MjBDQS5jcmwwggFCBggrBgEFBQcBAQSCATQwggEwMIG9BggrBgEFBQcwAoaBsGxkYXA6Ly8vQ049
TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049
U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NB
Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MG4GCCsG
AQUFBzAChmJodHRwOi8vd2hpY2EzLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9XSElD
QTMubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMElTU1VFMyUyMENBKDEpLmNydDANBgkqhkiG
9w0BAQUFAAOBgQAchLRuwOPeELwgxB4ibPV28Ajyn2FUAmHDAL/mMSuhmoHqzasMRdmS24a+CFKa
Sm1tL4aEDvgQlTuR8bNlFHTyOeGg5BARClSunCUUAuhx60PSyWlobpzNN7Nh24aoJD8/AW64wN+D
fV+/gtfRfiybMGajNGJ1SrbznEGTuOOysDCCBqcwggYQoAMCAQICChRel0MAAAAAACgwDQYJKoZI
hvcNAQEFBQAwTDELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRk
ZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJvb3QgQ0EwHhcNMDExMTAxMjA1NzExWhcNMDIwOTIwMjEz
MzI4WjBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEu
MCwGA1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjCCAbYwggErBgcq
hkjOOAQBMIIBHgKBgQD4Ly2xZP3/BEVJKm5f8RYN3D0lcE0i1w2lCKMzyIcaEIC84swy1gpKY0Z4
R8RAzij8hRkw8ciXT6at5mgDHo7lJ3aPmEOsxwnxkN8hhZs50hPBtGGVs6B1ijVEZiGdTzlTLneI
Fc6Mk7HEMv3sP7S1KvWJDls9rrRJYFlyTB35AQIVALpK4A0b7aa6zeQ1ZkPPC9iRcCjfAoGAZ7hM
x51ULfa+kKU94Fo1HH3cDdrSm6db5w8oqxOJkj9+qa23p9kl3cPdioGshDQjF4LO8R+vSRPM/UG5
ir7LkkE6uivrzXDGHF16C4/ZoMAdZHU7UGtuoHhI92GmibmzXkbiMWNyvD3YiM14Pq/BY9RHNVC8
V2tuUNe+bJ17lQsDgYQAAoGABlYEqKplvCqnqB1HWeyQOfRQ5UJLtSTNGKkL6PPAcbxdWsN1JiDa
mLDxvmTXYm8kWSuRkzSqrGPispNIDLOAmXRY79tX4IWD9IpsVhGP8U6C7ycNzZpNM6bEuBQgAVVf
fSBa99Qsq7gSrPkkFA8EeikTolxKM5dOM01Z2BGdpfmjggNhMIIDXTASBgkrBgEEAYI3FQEEBQID
AQADMCMGCSsGAQQBgjcVAgQWBBQYxRo0WCyvkaAaxWWDIpP6xv8VFTAdBgNVHQ4EFgQUz8W6F/8t
xxCA9bkOmUpv9Jwr+xkwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgHGMA8G
A1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUd8l0aSw5/jhl9IcFWAjOvbqX2hAwggE6BgNVHR8E
ggExMIIBLTCCASmgggEloIIBIYaBzmxkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxD
Tj13aGljYXNhcm9vdGNhLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2
aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlm
aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50
hk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRE
RVYlMjBTQSUyMFJvb3QlMjBDQS5jcmwwggFTBggrBgEFBQcBAQSCAUUwggFBMIHABggrBgEFBQcw
AoaBs2xkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxDTj1BSUEsQ049UHVibGljJTIw
S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1t
aWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0
aW9uQXV0aG9yaXR5MHwGCCsGAQUFBzAChnBodHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNy
b3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tX05U
REVWJTIwU0ElMjBSb290JTIwQ0EuY3J0MBQGA1UdIAEB/wQKMAgwBgYEVR0gADANBgkqhkiG9w0B
AQUFAAOBgQAxYiUUmrT3jDFqE+1g0gCnBxgfC3mMkIRtVA3sS+AZCB5QdVwHMIn5Vbcz+UHzq+GK
S/fRM2ETd19y56KAaNFI5NSLPuuvZIYuzw0QCsVjb1o0JDT8Z60ebroLDDtlXOBnmasVjmc5PDyV
KrlGtTyCLiWK9oZkNNUV4OJ/xruinzCCBqwwggZroAMCAQICChnMypwAAgAAAWAwCQYHKoZIzjgE
AzBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEuMCwG
A1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjAeFw0wMTEwMjUwMDQw
MjFaFw0wMjA5MjAyMTMzMjhaMHsxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZ
FgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEyMDAGA1UEAwwpTlRERVbjgIDvvKnv
vZPvvZPvvZXvvYXvvKrvvLDvvK7jgIDjgovjgbEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
AMLpdqtuCBDrs6W5nglAbizKGz0nZ6Xc00ZGNF/toXvZbvRTRfan+wj1HzcLG4qBlcudEbmir08S
Y2fL6lBS607lcrujUul9n5w5Nxm5CfFCO4SegOglrYaBiE7GJZia3cpRiR3T5J5TJ69GGWTJTnb9
IdLaoZNdzzx8jvydHrEnAgMBAAGjggSpMIIEpTAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQU
qXZyJ4BnnmSuH+3DpPN82oJrYbswGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUz8W6F/8txxCA9bkOmUpv9Jwr+xkwggKf
BgNVHR8EggKWMIICkjCCAo6gggKKoIIChoaB32xkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh
dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKSxDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUy
MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9
bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh
c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGX2h0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNv
bS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIo
MSkuY3JshoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIw
V2hpY2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049
U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2Nl
cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q
b2ludIZfaHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYl
MjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKS5jcmwwggFzBggrBgEFBQcB
AQSCAWUwggFhMIHVBggrBgEFBQcwAoaByGxkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlhdGUl
MjBTdWJvcmRpbmF0ZSUyMFdoaWNhMixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs
Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29t
P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGG
BggrBgEFBQcwAoZ6aHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv
d2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRp
bmF0ZSUyMFdoaWNhMigyKS5jcnQwCQYHKoZIzjgEAwMwADAtAhUArQS6yf+6F2yfZOaFlrSUHaiz
PYMCFAkXqtidhCmi1K1WdMAiPGRNQTrYMIIG/zCCBmigAwIBAgIKJQEzAAAAAAC1PDANBgkqhkiG
9w0BAQQFADB7MRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0
MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxMjAwBgNVBAMMKU5UREVW44CA77yp772T772T772V772F
77yq77yw77yu44CA44KL44GxMB4XDTAxMTEwNjAxMzMzMloXDTAyMDIwNDAxMzMzMlowgZoxEzAR
BgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/Is
ZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAP
BgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDFJ1gBomyjiL0YLiLsp+NRN9HLPsks85W/EtH/SGIgxwAIZhjk+/6+2EHHhNivM3/r
H1RaN4Y9QTKx0VLe3EOWA9y5jsBSa6ZAfdI9AHY+inUijMc575qA1VYPrdLO16n7OVrbaHK6ekuu
2tGcEb6mmyzqk2XeKLKcoxI0z+vlWwIDAQABo4IEaDCCBGQwCwYDVR0PBAQDAgeAMD4GCSsGAQQB
gjcVBwQxMC8GJysGAQQBgjcVCI3g0YlOhNecwweGpob7HI/Tv6YVgr+c9nyG3uaAVAIBcQIBATAT
BgNVHSUEDDAKBggrBgEFBQcDBDAtBgNVHSAEJjAkMCIGICsGAQQBgjcVCI3g0YlOhNecwweGpob7
HI/Tv6YVAYMRMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwUwYDVR0RBEwwSqAqBgorBgEE
AYI3FAIDoBwMGnBhdWxsZUBudGRldi5taWNyb3NvZnQuY29tgRxwYXVsbGVAd2luZG93cy5taWNy
b3NvZnQuY29tMB0GA1UdDgQWBBT4fpx75Z+XIZ7P0F8V6vLx/Lj7aTAfBgNVHSMEGDAWgBSpdnIn
gGeeZK4f7cOk83zagmthuzCCAX8GA1UdHwSCAXYwggFyMIIBbqCCAWqgggFmhoHsbGRhcDovLy9D
Tj1OVERFViEzMDAwIWZmMjkhZmY1MyFmZjUzIWZmNTUhZmY0NSFmZjJhIWZmMzAhZmYyZS0zNTkz
MSxDTj13aGljYWludGwsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp
Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZp
Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSG
dWh0dHA6Ly93aGljYWludGwubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWITMw
MDAhZmYyOSFmZjUzIWZmNTMhZmY1NSFmZjQ1IWZmMmEhZmYzMCFmZjJlITMwMDAhMzA4YiEzMDcx
LmNybDCCAZoGCCsGAQUFBwEBBIIBjDCCAYgwgeIGCCsGAQUFBzAChoHVbGRhcDovLy9DTj1OVERF
ViEzMDAwIWZmMjkhZmY1MyFmZjUzIWZmNTUhZmY0NSFmZjJhIWZmMzAhZmYyZS0zNTkzMSxDTj1B
SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv
bixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD
bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGgBggrBgEFBQcwAoaBk2h0dHA6Ly93aGljYWlu
dGwubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhaW50bC5udGRldi5taWNyb3Nv
ZnQuY29tX05UREVWITMwMDAhZmYyOSFmZjUzIWZmNTMhZmY1NSFmZjQ1IWZmMmEhZmYzMCFmZjJl
ITMwMDAhMzA4YiEzMDcxLmNydDANBgkqhkiG9w0BAQQFAAOBgQAsPSfPg7ByWp9CMyepLELQV8iJ
vSsEiBemCOUxPK5NfSX7NZ8FgCOpPNvB3+zX3EWFd2Zwcyv1+VQv2IxNiBGHYbSsYsLv/QKpYpBr
+MhT97uof/3maAq5OzMC+sk1BpE1keFxyQfkBjGWeKs773ZByEJR92o8BSlJABCoqi7XbDGCAtAw
ggLMAgEBMIGJMHsxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3Nv
ZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEyMDAGA1UEAwwpTlRERVbjgIDvvKnvvZPvvZPvvZXv
vYXvvKrvvLDvvK7jgIDjgovjgbECCiUBMwAAAAAAtTwwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMTE1MDQxNzM5WjAjBgkqhkiG9w0B
CQQxFgQUFc6lmn/OqgF5sJPs5UFJ8na1CvEwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAEMVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgoS
4BYcAAEADrzXMGoGCyqGSIb3DQEJEAILMVugWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj
cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgoS4BYcAAEA
DrzXMA0GCSqGSIb3DQEBAQUABIGAE3oD0z41O5SSCK24GhewmF14TUw40Sz5TpgNq+WBNoprq8rw
H490RhVZyOR6FR4iGC4ciZB+U1K/He3sa7Z8+H30bi+9LPINpCv524WDtT/PO8hr2eGQa94Z94T/
OZnuaQij99vcocEASwimqSggpfeCZ/BYCH/IGNDem4f9MuQAAAAAAAA=

------=_NextPart_000_00BA_01C16D49.688680D0--


From owner-ietf-ldup@mail.imc.org  Thu Nov 15 15:52:10 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19434
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 15:52:10 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFKZiX22463
	for ietf-ldup-bks; Thu, 15 Nov 2001 12:35:44 -0800 (PST)
Received: from hotmail.com (oe37.law9.hotmail.com [64.4.8.94])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFKZh822458
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 12:35:43 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 15 Nov 2001 12:35:41 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
Subject: RE: RE: moving access control discussion to LDUP
Date: Thu, 15 Nov 2001 15:26:54 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE378oV2tdFcpQZ5ymz00009bcb@hotmail.com>
X-OriginalArrivalTime: 15 Nov 2001 20:35:41.0150 (UTC) FILETIME=[178BEFE0:01C16E15]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


At 02:05 PM 2001-11-14, John Strassner wrote:
>So how will the protocol be able to interoperate without a common ACM?

At the level of interoperability this WG is attempting to achieve,
it cannot.  But then, this WG will needs much more than a common
ACM to provide the level of interoperability it is attempting to
achieve.

Chris Apple> I believe you have posted some
suggestions/observations about what the WG might have
to consider related to this in the posting to which John
replied. I'll respond separately to the original posting.
I do believe there is merit in some of what you propose.
Whether this additional security-related work needs to be included
in separate documents or folded into a revision of the ACM
document (if and when it becomes an LDUP deliverable) is something
we should definitely discuss on the list.

IMO, the WG as bitten off more that it can chew and bitting off
more will only cause the WG to choke.

Chris Apple> Opinion noted. It will be considered along with the
rest of the opinions on this matter and WG consensus will be judged
based on the collective hum of the responses.

So, I wonder, what is beyond scope of this working group?

Kurt

Chris Apple> That flavor of comment adds no value to
the list, the WG, the charter, or any deliverable we are
charged with producing. Our ADs will tell the WG if it is
stepping out of bounds, so to speak, with respect to adopting
the ACM work and perhaps adding other deliverables as you
suggested in the posting to which John Strassner replied
with his question. I have heard your objections to adopting
the ACM work as has John. They will be taken into consideration
when John and I discuss consensus around the new charter.
Keep in mind that discussion between Patrik, John, and I has taken
place about the scoping issue related to the ACM work - and that
Patrik, at that time, indicated that he had no objection to it being added
provided that LDAPEXT was truly going to shut down prior to achieving
consensus on it.

Unless a substantial number of other WG members express
concerns similar to yours, John and I will be required as co-chairs to
report to the list that consensus goes against the opinion you have
expressed.

Enough mashed potatoes; its time for some meat:

The WG should not attempt to actively work on technical
specifications that are not a part of the official version of
it. The current version of the charter indicates that in December 2001,
we will re-evaluate the charter. I am simply starting the process now
so that we can clearly understand and get to work on deliverables
tied to a revised charter *in* December rather than starting the process
then. This means that we are clearly, at this time, within the bounds of
what our charter allows us to do. I do not believe, in this case, that
starting on a deliverable earlier than scheduled is a bad thing.

Keep in mind the following:

1) the charter is currently being revised
2) discussion related to the proposed charter took place on the list
3) a number of clarifications and suggestions were received
both publicly and privately
4) I'm revising the document now and will report it to the WG mailing
list for confirmation that I captured everything that made sense to include

Given that we did not know at the time the charter revision was proposed
to the list discussion of the timing with which the LDAPEXT WG intends to
close (before ACM is complete/published as an RFC), we added text
to the charter (to which no objections were raised that I'm aware of)
allowing
the WG to consider whether or not the ACM work should be added to
the charter.

So, speaking as the co-chair currently responsible for revising
the charter proposal, I have decided to extend the original plan
for revising the charter proposal now instead of later, largely
because it is now known that LDAPEXT will not be pursuing
the progression of the ACM document.

Chris Apple

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth





From owner-ietf-ldup@mail.imc.org  Thu Nov 15 15:56:05 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19673
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 15:56:04 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFKeNv22900
	for ietf-ldup-bks; Thu, 15 Nov 2001 12:40:23 -0800 (PST)
Received: from hotmail.com (oe58.law9.hotmail.com [64.4.8.193])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFKeM822893
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 12:40:22 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 15 Nov 2001 12:40:20 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: <dsweigar@lexmark.com>, "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        <john.strassner@intelliden.com>,
        "Christopher Apple" <christopher.apple@UnitedMessaging.net>,
        "Rob Byrne - Sun Microsystems" <robert.byrne@Sun.COM>,
        "Mark Wahl" <Mark.Wahl@Sun.COM>, <roland@catalogix.se>,
        <ietf-ldup@imc.org>,
        "Roddy A. Sue \(E-mail\)" <saroddy@missi.ncsc.mil>
References: <200111151722.MAA21523@interlock2.lexmark.com>
Subject: Re: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.
Date: Thu, 15 Nov 2001 15:31:35 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE58kTjEJqA1g5Vcwzs0000dd0d@hotmail.com>
X-OriginalArrivalTime: 15 Nov 2001 20:40:20.0572 (UTC) FILETIME=[BE1859C0:01C16E15]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


This sort of discussion shouldn't be taking place on the LDUP
mailing list. Would be better to use the old ASID list if its still up
and running. I cannot recall the information for subscribing to it.
If someone has that info lying around, please send to me and I
will post to the LDUP list in response to this message.

We have enough work to discuss that's related to the charter,
adopting the ACM work from LDAPEXT, and the recently
published I-Ds....

Chris Apple

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth


----- Original Message -----
From: <dsweigar@lexmark.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>; <john.strassner@intelliden.com>;
"Christopher Apple" <christopher.apple@UnitedMessaging.net>; "Rob Byrne -
Sun Microsystems" <robert.byrne@Sun.COM>; "Mark Wahl" <Mark.Wahl@Sun.COM>;
<roland@catalogix.se>; <ietf-ldup@imc.org>; "Roddy A. Sue (E-mail)"
<saroddy@missi.ncsc.mil>; <dsweigar@lexmark.com>
Sent: Thursday, November 15, 2001 12:22 PM
Subject: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.


>
>
>
>
>
> Team:
>
> I am curious if anyone in the group as researched a comparison of
> LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.
>
> I wonder if anyone would want to comment on this comparison ?
>
> Dave
>
>
>


From owner-ietf-ldup@mail.imc.org  Thu Nov 15 16:01:19 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20194
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 16:01:19 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFKi4L23322
	for ietf-ldup-bks; Thu, 15 Nov 2001 12:44:04 -0800 (PST)
Received: from metainc2.metagroup.com ([63.122.26.75])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFKht823304
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 12:43:55 -0800 (PST)
Subject: Re: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.
To: <matthew.schwienteck@us.pwcglobal.com>
Cc: christopher.apple@UnitedMessaging.net, dsweigar@lexmark.com,
        ietf-ldup@imc.org, john.strassner@intelliden.com, Kurt@OpenLDAP.org,
        Mark.Wahl@Sun.COM, owner-ietf-ldup@mail.imc.org, robert.byrne@Sun.COM,
        roland@catalogix.se, saroddy@missi.ncsc.mil
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF30F55F61.B786DBFE-ON85256B05.0071927D@metagroup.com>
From: Earl.Perkins@metagroup.com
Date: Thu, 15 Nov 2001 15:43:31 -0500
X-MIMETrack: Serialize by Router on METAINC2/META Group(Release 5.0.8 |June 18, 2001) at
 11/15/2001 03:37:06 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>



The bottom line we've seen is that both IBM SecureWay and Oracle
OID have had limited deployments, though there have been some
that have demonstrated scalability. However, you might consider
it a "kludge" and doesn't entirely address issues like
"convergence" for joining records. I suspect that a new
generation of directories is imminent in the next year or so that
will build on what has happened here and combine it with
metadirectory experience to bring something cleaner to market.

Earl Perkins
Sr. Program Director, Global Networking Strategies
META Group, Inc.
330 Morgan St, Unit 606, New Orleans, LA 70114, USA
Phone: 504.362.0291



                                                                                                                                
                    <matthew.schwienteck@us.pwcg                                                                                
                    lobal.com>                          To:     dsweigar@lexmark.com                                            
                    Sent by:                            cc:     Kurt@OpenLDAP.org, john.strassner@intelliden.com,               
                    owner-ietf-ldup@mail.imc.org        christopher.apple@UnitedMessaging.net, robert.byrne@Sun.COM,            
                                                        Mark.Wahl@Sun.COM, roland@catalogix.se, ietf-ldup@imc.org,              
                                                        saroddy@missi.ncsc.mil, dsweigar@lexmark.com                            
                    11/15/2001 02:25 PM                 Subject:     Re: LDAP/X.500 directories vs. IBM's SecureWAy with a DB2  
                                                        back-end.                                                               
                                                                                                                                





It operates like any other LDAP v3 compliant directory (like iDS)
that use
flat db back-ends.  I have not used is to any large extent, but I
am very
familiar with Oracle Internet Directory (OID), which uses Oracle
RDBMS as a
back end.   The scalability and performance are similar and maybe
better on
OID if the backend is properly tuned.

Matt Schwienteck
Security Integration Services
PricewaterhouseCoopers
Houston, Tx
832-444-8168




dsweigar@lexmark.com@mail.imc.org on 11/15/2001 11:22:34 AM

Sent by:  owner-ietf-ldup@mail.imc.org

To:   "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
      john.strassner@intelliden.com, Christopher Apple
      <christopher.apple@UnitedMessaging.net>, Rob Byrne - Sun
Microsystems
      <robert.byrne@Sun.COM>, Mark Wahl <Mark.Wahl@Sun.COM>,
      roland@catalogix.se, ietf-ldup@imc.org, "Roddy A. Sue
(E-mail)"
      <saroddy@missi.ncsc.mil>, dsweigar@lexmark.com
cc:
Subject:  LDAP/X.500 directories vs. IBM's SecureWAy with a DB2
back-end.







Team:

I am curious if anyone in the group as researched a comparison of
LDAP/X.500 directories vs. IBM's SecureWAy with a DB2 back-end.

I wonder if anyone would want to comment on this comparison ?

Dave





----------------------------------------------------------------
The information transmitted is intended only for the person or
entity to
which it is addressed and may contain confidential and/or
privileged
material.  Any review, retransmission, dissemination or other use
of, or
taking of any action in reliance upon, this information by
persons or
entities other than the intended recipient is prohibited.   If
you received
this in error, please contact the sender and delete the material
from any
computer.





----------------------------------------------------------------
                         Register Today!
"Scaling the Peaks of CIO Performance: IT Excellence and Business
                         Transformation"
             META Group's Executive Directions Forum
                       December 3-4, 2001
Marriott's Camelback Inn Resort, Golf Club & Spa; Scottsdale, AZ
                 http://www.metagroup.com/ed2001
---------------------------------------------------------------/




From owner-ietf-ldup@mail.imc.org  Thu Nov 15 16:46:47 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22891
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 16:46:47 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFLNuD26256
	for ietf-ldup-bks; Thu, 15 Nov 2001 13:23:56 -0800 (PST)
Received: from uxtpaprx1.pwcglobal.com (uxtpaprx1.pwcglobal.com [12.26.159.121])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLNt826251
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 13:23:55 -0800 (PST)
Received: by uxtpaprx1.pwcglobal.com; id QAA05029; Thu, 15 Nov 2001 16:20:19 -0500 (EST)
From: <christine.yoon@us.pwcglobal.com>
Received: from unknown(10.26.104.81) by uxtpaprx1.us.pw.com via smap (V5.5)
	id xma003621; Thu, 15 Nov 01 16:19:35 -0500
Received: from us-amsmta005.us.pw.com by uxtpabuf1.us.pw.com
 (PMDF V5.1-12 #U3932) with ESMTP id <0GMV00KIE1ZD40@uxtpabuf1.us.pw.com>; Thu,
 15 Nov 2001 16:21:13 -0500 (EST)
Date: Thu, 15 Nov 2001 16:22:11 -0500
Subject: RE: moving access control discussion to LDUP
To: Kurt@OpenLDAP.org
Cc: john.strassner@intelliden.com,
        Christopher Apple <christopher.apple@UnitedMessaging.net>,
        "'Rob Byrne - Sun Microsystems'" <robert.byrne@Sun.COM>,
        Mark Wahl <Mark.Wahl@Sun.COM>, ietf-ldup@imc.org
Message-id: <OF7D3E5FF1.B35F4240-ON85256B05.00742E33@us.pw.com>
MIME-version: 1.0
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Content-type: text/plain; charset=us-ascii
X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.6
 |December 14, 2000) at 11/15/2001 04:22:46 PM
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>



When it comes to interoprability, I think that AC has higher priority than
Replication because
most companies who implement directory replication may end up using the
same vendor product.

I would like to see AC work to be continued.
It seems that completing development of replication requires AC. Sounds
that it is natural for LDUP to take over.
I vote for moving it to LDUP.

-Christine Yoon
PricewaterhouseCoopers






"Kurt D. Zeilenga" <Kurt@OpenLDAP.org>@mail.imc.org on 11/14/2001 06:14:30
PM

Sent by:  owner-ietf-ldup@mail.imc.org

To:   john.strassner@intelliden.com
cc:   Christopher Apple <christopher.apple@UnitedMessaging.net>, 'Rob Byrne
      - Sun Microsystems' <robert.byrne@Sun.COM>, Mark Wahl
      <Mark.Wahl@Sun.COM>, roland@catalogix.se, ietf-ldup@imc.org
Subject:  RE: moving access control discussion to LDUP



At 02:05 PM 2001-11-14, John Strassner wrote:
>So how will the protocol be able to interoperate without a common ACM?

At the level of interoperability this WG is attempting to achieve,
it cannot.  But then, this WG will needs much more than a common
ACM to provide the level of interoperability it is attempting to
achieve.

IMO, the WG as bitten off more that it can chew and bitting off
more will only cause the WG to choke.

So, I wonder, what is beyond scope of this working group?

Kurt



----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 17:44:15 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25502
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 17:44:15 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFMIiM29282
	for ietf-ldup-bks; Thu, 15 Nov 2001 14:18:44 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFMIh829262
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 14:18:43 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAFMNtC52882;
	Thu, 15 Nov 2001 22:23:55 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011115135549.01709cd0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 15 Nov 2001 14:18:15 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: What is beyond scope of this working group?
Cc: <ietf-ldup@imc.org>
In-Reply-To: <OE378oV2tdFcpQZ5ymz00009bcb@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 12:26 PM 2001-11-15, Chris Apple wrote:
>Kurt wrote:
>> So, I wonder, what is beyond scope of this working group?
>That flavor of comment adds no value to the list, the WG, the charter, or any deliverable we are charged with producing.

In writing a charter, discussing and documenting what is beyond
scope of the working group certainly adds value.  I, for one,
cannot figure out what is beyond the scope of this working group.
Your response to one of my previous posts certainly didn't help
clarify matters:
   Since there is nothing explicitly in the charter about
   this, I suppose it would be logical to say that it is
   not explicitly prohibited.
   http://www.imc.org/ietf-ldup/mail-archive/msg01200.html

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 18:08:23 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26503
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 18:08:22 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFMmgP01702
	for ietf-ldup-bks; Thu, 15 Nov 2001 14:48:42 -0800 (PST)
Received: from hotmail.com (f156.law9.hotmail.com [64.4.9.156])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFMmf801698
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 14:48:41 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 15 Nov 2001 14:48:40 -0800
Received: from 65.14.159.170 by lw9fd.law9.hotmail.msn.com with HTTP;
	Thu, 15 Nov 2001 22:48:39 GMT
X-Originating-IP: [65.14.159.170]
From: "Chris Apple" <imcapple@hotmail.com>
To: Kurt@OpenLDAP.org
Cc: ietf-ldup@imc.org
Subject: Re: What is beyond scope of this working group?
Date: Thu, 15 Nov 2001 17:48:39 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F156EpFhu4XIMjuLXHJ000142e7@hotmail.com>
X-OriginalArrivalTime: 15 Nov 2001 22:48:40.0070 (UTC) FILETIME=[AB5A8260:01C16E27]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


You took my comment out of context. Doing so often
makes a statement seem less substantial or relevant
than it really is.

My point in that posting was that I do not believe
the point you were making in the posting to which I
was responding at the time was relevant to scoping
the charter, but a technical issue to be discussed
in the context of the documents which may or may not
actually attempt to go in one direction or another
out of the possibilities that you enumerated. That
was made clearer in a follow up to your posting
in which you clarified your concerns based on the
posting out of which you lifted the statement below.

That you disagree with my position on the matter
is not in issue. What is in issue is whether the
rest of the WG agrees with you perhaps. So far,
I've not seen anyone express similar concerns
related to the charter. And if that remains the
case, John and I have to do what we feel is right
and can get agreement from the IESG on doing.

More below...

>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>To: "Chris Apple" <imcapple@hotmail.com>
>CC: <ietf-ldup@imc.org>
>Subject: What is beyond scope of this working group?
>Date: Thu, 15 Nov 2001 14:18:15 -0800
>
>At 12:26 PM 2001-11-15, Chris Apple wrote:
> >Kurt wrote:
> >> So, I wonder, what is beyond scope of this working group?
> >That flavor of comment adds no value to the list, the WG, the charter, or 
>any deliverable we are charged with producing.
>
>In writing a charter, discussing and documenting what is beyond
>scope of the working group certainly adds value.

I agree with the above statement.

>  I, for one,
>cannot figure out what is beyond the scope of this working group.

That would have been one way to illicit productive discussion
had you worded it that way. As it was written, it did not read to
me as if you were interested in productive discussion to clarify
what is or is not in scope. It read as if you wanted a bit of
flame on the list. If that was my misinterpretation, please consider
this to be an apology.

>Your response to one of my previous posts certainly didn't help
>clarify matters:
>    Since there is nothing explicitly in the charter about
>    this, I suppose it would be logical to say that it is
>    not explicitly prohibited.
>    http://www.imc.org/ietf-ldup/mail-archive/msg01200.html
>
>Kurt
>

I believe here, we just disagree on the nature of the issue.
You believe this to be a WG scoping issue - I believe this to
be a technical issue that needs to be discussed in the context
of actual I-Ds containing relevant text/requirements/specs.
Unless John and I hear from others that they believe this
to be a WG scoping issue rather than a technical issue to
be resolve during engineering discussions - we have to assume
that silence on the topic means that most members of the WG
agree with our take on it.

Chris Apple

Currently self-employed pondering the meaning of life in Olde City, 
Philadelphia, PA, US, Earth

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 19:00:47 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28621
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 19:00:47 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAFNgce03696
	for ietf-ldup-bks; Thu, 15 Nov 2001 15:42:38 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNgb803690
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 15:42:37 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAFNlpC53145;
	Thu, 15 Nov 2001 23:47:51 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011115153903.016fd060@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 15 Nov 2001 15:42:11 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: What is beyond scope of this working group?
Cc: ietf-ldup@imc.org
In-Reply-To: <F156EpFhu4XIMjuLXHJ000142e7@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 02:48 PM 2001-11-15, Chris Apple wrote:
>>In writing a charter, discussing and documenting what is beyond
>>scope of the working group certainly adds value.
>
>I agree with the above statement.

Great.  Would it be now be appropriate to discuss
what is beyond scope of this working group?  Or would
you prefer for this to be deferred until you post another
proposed charter?

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 19:01:52 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28668
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 19:01:52 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAFNbCh03481
	for ietf-ldup-bks; Thu, 15 Nov 2001 15:37:12 -0800 (PST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNb9803476
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 15:37:09 -0800 (PST)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 15 Nov 2001 15:36:47 -0800
Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Nov 2001 15:36:45 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 15 Nov 2001 15:36:45 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 15 Nov 2001 15:36:44 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Thu, 15 Nov 2001 15:36:04 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: moving access control discussion to LDUP
Date: Thu, 15 Nov 2001 15:36:04 -0800
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD02A87979@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: moving access control discussion to LDUP
thread-index: AcFuHGphuQVD3oHHSHS/ZCDA6hRxRQAELhmQ
From: "Paul Leach" <paulle@windows.microsoft.com>
To: <christine.yoon@us.pwcglobal.com>, <Kurt@OpenLDAP.org>
Cc: <john.strassner@intelliden.com>,
        "Christopher Apple" <christopher.apple@UnitedMessaging.net>,
        "Rob Byrne - Sun Microsystems" <robert.byrne@Sun.COM>,
        "Mark Wahl" <Mark.Wahl@Sun.COM>, <ietf-ldup@imc.org>
X-OriginalArrivalTime: 15 Nov 2001 23:36:04.0445 (UTC) FILETIME=[4ABBB0D0:01C16E2E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAFNbB803478
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit




> -----Original Message-----
> From: christine.yoon@us.pwcglobal.com 
> [mailto:christine.yoon@us.pwcglobal.com] 
> Sent: Thursday, November 15, 2001 1:22 PM
> To: Kurt@OpenLDAP.org
> Cc: john.strassner@intelliden.com; Christopher Apple; 'Rob 
> Byrne - Sun Microsystems'; Mark Wahl; ietf-ldup@imc.org
> Subject: RE: moving access control discussion to LDUP
> 
> 
> 
> 
> When it comes to interoprability, I think that AC has higher 
> priority than Replication because most companies who 
> implement directory replication may end up using the same 
> vendor product.

If that's true, then there is no need for LDUP (i.e., standards based
replication) at all -- the vendor can use any old proprietary
replication protocol, and interoperability from the clients will not be
affected.

This WG _was_ about standards based replication, and not about access
control. (I understand that the charter is open for revision, so it's
fair game now.)

Once there is a replication standard, and some other WG creates a access
control standard, then we'll be able to replicate it. Until then, absent
such a standard, replication would be confined to special cases.
However, ignoring the access control issue will let us make progress on
replication, which what this WG was started to do -- I would suggest we
focus on that.

The problems are factorable, and problems that get factored get solved
quicker.

Paul



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 19:23:55 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29399
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 19:23:54 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAG06BJ04685
	for ietf-ldup-bks; Thu, 15 Nov 2001 16:06:11 -0800 (PST)
Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG06A804681
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 16:06:10 -0800 (PST)
Received: from noeticwork (adsl-63-194-210-36.dsl.snfc21.pacbell.net [63.194.210.36])
	by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id fAG05sM167040;
	Thu, 15 Nov 2001 19:05:54 -0500
Message-ID: <008501c16e32$7be4b1d0$0163a8c0@noetic.net>
From: "Ed Owens" <edowens@ix.netcom.com>
To: "Chris Apple" <imcapple@hotmail.com>,
        "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
References: <OE378oV2tdFcpQZ5ymz00009bcb@hotmail.com>
Subject: Re: RE: moving access control discussion to LDUP
Date: Thu, 15 Nov 2001 16:05:11 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Chris et al;
    I have been silent on this list for some time but since silence
currently counts as acceptance (as it always has) I need to express my
concurrence with Kurt that ACM should not be added to the LDUP charter.
While I follow and understand what the lack of ACM might mean for LDUP cross
vendor implementations I believe it is too much for the WG at this time (and
since LDAPEXT couldn't come to consensus I have doubts whether this WG could
even on a meaningful subset for LDUP).  So add one more voice against adding
ACM to the charter.
        Ed Owens


Edward Owens
Principal Consultant
Noetic Solutions LLC
(925)366-1005
eowens@sbcglobal.net
http://www.noetic.net
----- Original Message -----
From: "Chris Apple" <imcapple@hotmail.com>
To: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
Sent: Thursday, November 15, 2001 12:26 PM
Subject: RE: RE: moving access control discussion to LDUP


>
> At 02:05 PM 2001-11-14, John Strassner wrote:
> >So how will the protocol be able to interoperate without a common ACM?
>
> At the level of interoperability this WG is attempting to achieve,
> it cannot.  But then, this WG will needs much more than a common
> ACM to provide the level of interoperability it is attempting to
> achieve.
>
> Chris Apple> I believe you have posted some
> suggestions/observations about what the WG might have
> to consider related to this in the posting to which John
> replied. I'll respond separately to the original posting.
> I do believe there is merit in some of what you propose.
> Whether this additional security-related work needs to be included
> in separate documents or folded into a revision of the ACM
> document (if and when it becomes an LDUP deliverable) is something
> we should definitely discuss on the list.
>
> IMO, the WG as bitten off more that it can chew and bitting off
> more will only cause the WG to choke.
>
> Chris Apple> Opinion noted. It will be considered along with the
> rest of the opinions on this matter and WG consensus will be judged
> based on the collective hum of the responses.
>
> So, I wonder, what is beyond scope of this working group?
>
> Kurt
>
> Chris Apple> That flavor of comment adds no value to
> the list, the WG, the charter, or any deliverable we are
> charged with producing. Our ADs will tell the WG if it is
> stepping out of bounds, so to speak, with respect to adopting
> the ACM work and perhaps adding other deliverables as you
> suggested in the posting to which John Strassner replied
> with his question. I have heard your objections to adopting
> the ACM work as has John. They will be taken into consideration
> when John and I discuss consensus around the new charter.
> Keep in mind that discussion between Patrik, John, and I has taken
> place about the scoping issue related to the ACM work - and that
> Patrik, at that time, indicated that he had no objection to it being added
> provided that LDAPEXT was truly going to shut down prior to achieving
> consensus on it.
>
> Unless a substantial number of other WG members express
> concerns similar to yours, John and I will be required as co-chairs to
> report to the list that consensus goes against the opinion you have
> expressed.
>
> Enough mashed potatoes; its time for some meat:
>
> The WG should not attempt to actively work on technical
> specifications that are not a part of the official version of
> it. The current version of the charter indicates that in December 2001,
> we will re-evaluate the charter. I am simply starting the process now
> so that we can clearly understand and get to work on deliverables
> tied to a revised charter *in* December rather than starting the process
> then. This means that we are clearly, at this time, within the bounds of
> what our charter allows us to do. I do not believe, in this case, that
> starting on a deliverable earlier than scheduled is a bad thing.
>
> Keep in mind the following:
>
> 1) the charter is currently being revised
> 2) discussion related to the proposed charter took place on the list
> 3) a number of clarifications and suggestions were received
> both publicly and privately
> 4) I'm revising the document now and will report it to the WG mailing
> list for confirmation that I captured everything that made sense to
include
>
> Given that we did not know at the time the charter revision was proposed
> to the list discussion of the timing with which the LDAPEXT WG intends to
> close (before ACM is complete/published as an RFC), we added text
> to the charter (to which no objections were raised that I'm aware of)
> allowing
> the WG to consider whether or not the ACM work should be added to
> the charter.
>
> So, speaking as the co-chair currently responsible for revising
> the charter proposal, I have decided to extend the original plan
> for revising the charter proposal now instead of later, largely
> because it is now known that LDAPEXT will not be pursuing
> the progression of the ACM document.
>
> Chris Apple
>
> Currently self-employed pondering the meaning of life in Olde City,
> Philadelphia, PA, US, Earth
>
>
>



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 19:31:06 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29608
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 19:31:06 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAG0DaX05101
	for ietf-ldup-bks; Thu, 15 Nov 2001 16:13:36 -0800 (PST)
Received: from hotmail.com (f47.law9.hotmail.com [64.4.9.47])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0DZ805097
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 16:13:35 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 15 Nov 2001 16:13:33 -0800
Received: from 65.14.159.170 by lw9fd.law9.hotmail.msn.com with HTTP;
	Fri, 16 Nov 2001 00:13:33 GMT
X-Originating-IP: [65.14.159.170]
From: "Chris Apple" <imcapple@hotmail.com>
To: Kurt@OpenLDAP.org
Cc: ietf-ldup@imc.org
Subject: Re: What is beyond scope of this working group?
Date: Thu, 15 Nov 2001 19:13:33 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F47WgP1A83xiDd9D9DQ0000e3a8@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 00:13:33.0945 (UTC) FILETIME=[878A2690:01C16E33]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Give me until tomorrow noon US ET to post a revision
based on comments received so far. Then its open
season. ;)

Some of your suggestions for what it might mean for
a WG to approach the LDAP ACM topic will be integrated
so that we have a concrete proposal on which to base
discussion of how the ACM work might be adopted by
the LDUP WG.

I don't really consider it to be an open issue at this
point *if* the ACM work should move to LDUP - other members
of the WG have made their opinions known and concensus seems
clear that it should be adopted by LDUP. That of course could change
should discussions related to scoping and other aspects of
the charter proposal to be posted tomorrow result in a swing
of concensus towards not adopting the ACM work.

Chris Apple

Currently self-employed pondering the meaning of life in Olde City, 
Philadelphia, PA, US, Earth


>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>To: "Chris Apple" <imcapple@hotmail.com>
>CC: ietf-ldup@imc.org
>Subject: Re: What is beyond scope of this working group?
>Date: Thu, 15 Nov 2001 15:42:11 -0800
>
>At 02:48 PM 2001-11-15, Chris Apple wrote:
> >>In writing a charter, discussing and documenting what is beyond
> >>scope of the working group certainly adds value.
> >
> >I agree with the above statement.
>
>Great.  Would it be now be appropriate to discuss
>what is beyond scope of this working group?  Or would
>you prefer for this to be deferred until you post another
>proposed charter?
>
>Kurt
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 19:34:04 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29695
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 19:34:03 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAG0GkO05238
	for ietf-ldup-bks; Thu, 15 Nov 2001 16:16:46 -0800 (PST)
Received: from cosds003.continuumnetworks.com ([12.41.184.243])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0Gj805234
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 16:16:45 -0800 (PST)
Received: from FARILJCS ([12.41.186.49]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GMVA3Q00.U6M; Thu, 15 Nov 2001 17:16:38 -0700 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Chris Apple" <imcapple@hotmail.com>, <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
Subject: RE: What is beyond scope of this working group?
Date: Thu, 15 Nov 2001 17:16:38 -0700
Message-ID: <FCEKLEHMPIHFNLCMKHAMMEIDCPAA.john.strassner@intelliden.com>
MIME-Version: 1.0
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: <F156EpFhu4XIMjuLXHJ000142e7@hotmail.com>
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_05A7_01C16DF9.48C81140";
	micalg=SHA1;
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_05A7_01C16DF9.48C81140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Kurt,

I agree with Chris. I didn't respond because it did seem like you were
inviting a flame war, which certainly would not be productive.

Furthermore, I don't understand why you continue to ask this question. If
you are concerned about helping this work group to focus, then please
state explicitly what you think is wrong with the charter and suggest
wording to fix those problems.

thanks,
John Strassner
Co-Chair, LDUP WG

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Chris Apple
Sent: Thursday, November 15, 2001 3:49 PM
To: Kurt@OpenLDAP.org
Cc: ietf-ldup@imc.org
Subject: Re: What is beyond scope of this working group?



You took my comment out of context. Doing so often
makes a statement seem less substantial or relevant
than it really is.

My point in that posting was that I do not believe
the point you were making in the posting to which I
was responding at the time was relevant to scoping
the charter, but a technical issue to be discussed
in the context of the documents which may or may not
actually attempt to go in one direction or another
out of the possibilities that you enumerated. That
was made clearer in a follow up to your posting
in which you clarified your concerns based on the
posting out of which you lifted the statement below.

That you disagree with my position on the matter
is not in issue. What is in issue is whether the
rest of the WG agrees with you perhaps. So far,
I've not seen anyone express similar concerns
related to the charter. And if that remains the
case, John and I have to do what we feel is right
and can get agreement from the IESG on doing.

More below...

>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>To: "Chris Apple" <imcapple@hotmail.com>
>CC: <ietf-ldup@imc.org>
>Subject: What is beyond scope of this working group?
>Date: Thu, 15 Nov 2001 14:18:15 -0800
>
>At 12:26 PM 2001-11-15, Chris Apple wrote:
> >Kurt wrote:
> >> So, I wonder, what is beyond scope of this working group?
> >That flavor of comment adds no value to the list, the WG, the charter,
or
>any deliverable we are charged with producing.
>
>In writing a charter, discussing and documenting what is beyond
>scope of the working group certainly adds value.

I agree with the above statement.

>  I, for one,
>cannot figure out what is beyond the scope of this working group.

That would have been one way to illicit productive discussion
had you worded it that way. As it was written, it did not read to
me as if you were interested in productive discussion to clarify
what is or is not in scope. It read as if you wanted a bit of
flame on the list. If that was my misinterpretation, please consider
this to be an apology.

>Your response to one of my previous posts certainly didn't help
>clarify matters:
>    Since there is nothing explicitly in the charter about
>    this, I suppose it would be logical to say that it is
>    not explicitly prohibited.
>    http://www.imc.org/ietf-ldup/mail-archive/msg01200.html
>
>Kurt
>

I believe here, we just disagree on the nature of the issue.
You believe this to be a WG scoping issue - I believe this to
be a technical issue that needs to be discussed in the context
of actual I-Ds containing relevant text/requirements/specs.
Unless John and I hear from others that they believe this
to be a WG scoping issue rather than a technical issue to
be resolve during engineering discussions - we have to assume
that silence on the topic means that most members of the WG
agree with our take on it.

Chris Apple

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


------=_NextPart_000_05A7_01C16DF9.48C81140
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTExNjAwMTYzN1owIwYJKoZIhvcNAQkEMRYEFC7nr68CVacQbf+t34+M15dhOSJ3
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAnsW3
/Z+4UeB8BGNLZUyhTZzk/XEwcWsZoSLn/PwK/hpFvBIcn2d/LzYvZLbmRQ2iYA5dpmtIMMlEInUG
DkQqkfwlosr8H5oIdq98jGsctCqN12iy93uCmRy4hfovUy9B00MPQfhe89gKKs8JcEdoCoFEYpRa
nUfTV0lyt4sGXXgAAAAAAAA=

------=_NextPart_000_05A7_01C16DF9.48C81140--



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 20:18:55 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00860
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 20:18:55 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAG0uM106698
	for ietf-ldup-bks; Thu, 15 Nov 2001 16:56:22 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0uK806694
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 16:56:21 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAG11bC53394
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 01:01:37 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011115160833.01709198@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 15 Nov 2001 16:55:57 -0800
To: ietf-ldup@imc.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Adding to the LDAP ACM to a WG charter
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This message is intended to clarify the reasons why I
oppose having LDAP ACM work item on any IETF WG charter
at this time.

Many (most?) of us (including I) would like very much
to see LDAP have a Standard Track powerful, flexible,
and extensible standard track access control model. 
Many of us have tried very hard to produce such.  But
after years of trying, it became clear that the IETF
was not going to reach consensus on a number of critical
issues.  The issues are the same, the people are (mostly)
the same, a change of venue (LDAPext->LDUP) won't help.

But a change to which process used may help.  Those who
support an LDAPext-ACM based solution should, as individuals,
produce the best damn LDAP ACM specification they can and
those who support alternative approaches should, as
individuals, produce the best damn specification they can.
We should give each set of individuals a reasonable amount
of time to produces these specifications.   Then, based upon
what is produced by the sets of individuals, determine how
best to proceed:
	a) adopt one (publish on Standard Track)
	b) adopt none
	c) create a WG to take one approach to Standard Track

Based upon discussions I had at IETF#51 and with individuals
since then, I believe we will soon multiple pretty damn good
alternatives submitted (post IETF#52).

IMO, we'll have an LDAP ACM must sooner than later if LDUP
stays out of way.

Kurt
  



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 20:37:43 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01250
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 20:37:43 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAG1LKg07843
	for ietf-ldup-bks; Thu, 15 Nov 2001 17:21:20 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG1LI807839
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 17:21:18 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAG1QTC53479;
	Fri, 16 Nov 2001 01:26:29 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011115165619.0171a130@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 15 Nov 2001 17:20:50 -0800
To: <john.strassner@intelliden.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: What is beyond scope of this working group?
Cc: "Chris Apple" <imcapple@hotmail.com>, <ietf-ldup@imc.org>
In-Reply-To: <FCEKLEHMPIHFNLCMKHAMMEIDCPAA.john.strassner@intelliden.com
 >
References: <F156EpFhu4XIMjuLXHJ000142e7@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 04:16 PM 2001-11-15, John Strassner wrote:
>I agree with Chris. I didn't respond because it did seem like you were
>inviting a flame war, which certainly would not be productive.

While I can see how my comment might have been interpreted that
way, that wasn't my intent.  My intent was raise my concern,
which I have voiced repeatedly (long before the ACM suggestion),
that the current and proposed charters did not adequate detail
what was beyond scope of this working group.

>Furthermore, I don't understand why you continue to ask this question.

Simply put, I believe this group needs the focus provided by a
sufficiently narrow charter to successfully deliver an LDAP
Replication technical specification.

>If you are concerned about helping this work group to focus, then please
>state explicitly what you think is wrong with the charter and suggest
>wording to fix those problems.

Will do (taking Chris's direction into consideration as well).

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Nov 15 21:19:14 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02068
	for <ldup-archive@odin.ietf.org>; Thu, 15 Nov 2001 21:19:14 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAG1xXq08961
	for ietf-ldup-bks; Thu, 15 Nov 2001 17:59:33 -0800 (PST)
Received: from hotmail.com (f94.law9.hotmail.com [64.4.9.94])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG1xW808957
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 17:59:32 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 15 Nov 2001 17:59:31 -0800
Received: from 65.14.159.170 by lw9fd.law9.hotmail.msn.com with HTTP;
	Fri, 16 Nov 2001 01:59:31 GMT
X-Originating-IP: [65.14.159.170]
From: "Chris Apple" <imcapple@hotmail.com>
To: Kurt@OpenLDAP.org, ietf-ldup@imc.org
Subject: Re: Adding to the LDAP ACM to a WG charter
Date: Thu, 15 Nov 2001 20:59:31 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F949QtpfTYSl1q4gtop00001f86@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 01:59:31.0592 (UTC) FILETIME=[54FE1880:01C16E42]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


There seem to be a few major points that you
are making below - I'm trying to distill what
you wrote to a few distinct and clear bullets.
Please correct any errors of interpretation I've
made or add to the list as appropriate. No judgement
at all implied here, I'm just trying to understand
the points you are making clearly so that we can
discuss them in a productive way.

1) You are asserting that the IETF process won't
   work for LDAP ACM and would need to be modified
   slightly to result in the production of a good
   LDAP ACM specification.

2) You are advocating that this process modification
   would be that multiple proposals for an LDAP ACM
   should be written outside of the context of any WG.

3) You are expecting one of these proposals to become
   vetted in some way to become the eventual product
   of a WG other than LDUP.

4) You are asserting that the LDUP WG will either produce an
   inferior or at least a delayed LDAP ACM than a different
   WG with the same members would be able to.

Chris.

>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>To: ietf-ldup@imc.org
>Subject: Adding to the LDAP ACM to a WG charter
>Date: Thu, 15 Nov 2001 16:55:57 -0800
>
>
>This message is intended to clarify the reasons why I
>oppose having LDAP ACM work item on any IETF WG charter
>at this time.
>
>Many (most?) of us (including I) would like very much
>to see LDAP have a Standard Track powerful, flexible,
>and extensible standard track access control model.
>Many of us have tried very hard to produce such.  But
>after years of trying, it became clear that the IETF
>was not going to reach consensus on a number of critical
>issues.  The issues are the same, the people are (mostly)
>the same, a change of venue (LDAPext->LDUP) won't help.
>
>But a change to which process used may help.  Those who
>support an LDAPext-ACM based solution should, as individuals,
>produce the best damn LDAP ACM specification they can and
>those who support alternative approaches should, as
>individuals, produce the best damn specification they can.
>We should give each set of individuals a reasonable amount
>of time to produces these specifications.   Then, based upon
>what is produced by the sets of individuals, determine how
>best to proceed:
>	a) adopt one (publish on Standard Track)
>	b) adopt none
>	c) create a WG to take one approach to Standard Track
>
>Based upon discussions I had at IETF#51 and with individuals
>since then, I believe we will soon multiple pretty damn good
>alternatives submitted (post IETF#52).
>
>IMO, we'll have an LDAP ACM must sooner than later if LDUP
>stays out of way.
>
>Kurt
>
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 00:27:42 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06741
	for <ldup-archive@lists.ietf.org>; Fri, 16 Nov 2001 00:27:41 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAG53Qt12419
	for ietf-ldup-bks; Thu, 15 Nov 2001 21:03:26 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG53O812415
	for <ietf-ldup@imc.org>; Thu, 15 Nov 2001 21:03:24 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAG58fC54494;
	Fri, 16 Nov 2001 05:08:41 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011115185618.0171e5e8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 15 Nov 2001 21:02:44 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Adding to the LDAP ACM to a WG charter
Cc: ietf-ldup@imc.org
In-Reply-To: <F949QtpfTYSl1q4gtop00001f86@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 05:59 PM 2001-11-15, Chris Apple wrote:
>1) You are asserting that the IETF process won't
>  work for LDAP ACM and would need to be modified
>  slightly to result in the production of a good
>  LDAP ACM specification.

I see no need to change IETF process [RFC 2026] or
WG guidelines [RFC 2418] and am not advocating such.
The IETF process and guidelines are flexible.  The
process considers both working group and individual
efforts in producing RFCs.

Presently, I believe that LDAP ACM standardization
work is best pursued on an individual basis.

>2) You are advocating that this process modification
>  would be that multiple proposals for an LDAP ACM
>  should be written outside of the context of any WG.

I am suggesting that we let individuals pursue this work
under the established process.

>3) You are expecting one of these proposals to become
>  vetted in some way to become the eventual product
>  of a WG other than LDUP.

I am hoping that one or more proposals of appropriate quality,
drafted by individuals, would be submitted for consideration
for publication.  As with any other submission to the IETF,
the IETF would review these works and take appropriate action.

My assertions apply equally to LDUP as to any WG which might
consider taking on LDAP ACM work (or be formed specifically
for this work).  Any reference I made to LDUP was solely due
to the fact it happens to be the WG considering taking on
LDAP ACM work.  I don't think changing the WG venue matters
much (as the interested parties follow the work).

>4) You are asserting that the LDUP WG will either produce an
>  inferior or at least a delayed LDAP ACM than a different
>  WG with the same members would be able to.

I believe any WG taking on LDAP ACM work will be stalled due
to lack of consensus.  Individuals, not subject to WG
consensus, can produce an LDAP ACM for consideration by the
IETF much faster.

Of course, any LDAP ACM I-D submitted for consideration on
the Standard Track, whether produced by a WG or individuals,
has IETF consensus requirements.

And, in terms of meeting overall desires (powerful, flexible,
extensible, etc.), I think individuals can do better than
a WG in this case.  LDAPext had to remove functionality to
remove contention.  Individuals generally don't have to do
that.

Anybody remember the SGMP/CMOT wars which resulted in SNMP?
Basically I am suggesting a similar approach.  That is, let
each set of individuals develop the very best specification
they can, make "where's the ACM?" buttons ;-) and then
consider how to proceed.

Kurt

>>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>>To: ietf-ldup@imc.org
>>Subject: Adding to the LDAP ACM to a WG charter
>>Date: Thu, 15 Nov 2001 16:55:57 -0800
>>
>>
>>This message is intended to clarify the reasons why I
>>oppose having LDAP ACM work item on any IETF WG charter
>>at this time.
>>
>>Many (most?) of us (including I) would like very much
>>to see LDAP have a Standard Track powerful, flexible,
>>and extensible standard track access control model.
>>Many of us have tried very hard to produce such.  But
>>after years of trying, it became clear that the IETF
>>was not going to reach consensus on a number of critical
>>issues.  The issues are the same, the people are (mostly)
>>the same, a change of venue (LDAPext->LDUP) won't help.
>>
>>But a change to which process used may help.  Those who
>>support an LDAPext-ACM based solution should, as individuals,
>>produce the best damn LDAP ACM specification they can and
>>those who support alternative approaches should, as
>>individuals, produce the best damn specification they can.
>>We should give each set of individuals a reasonable amount
>>of time to produces these specifications.   Then, based upon
>>what is produced by the sets of individuals, determine how
>>best to proceed:
>>        a) adopt one (publish on Standard Track)
>>        b) adopt none
>>        c) create a WG to take one approach to Standard Track
>>
>>Based upon discussions I had at IETF#51 and with individuals
>>since then, I believe we will soon multiple pretty damn good
>>alternatives submitted (post IETF#52).
>>
>>IMO, we'll have an LDAP ACM must sooner than later if LDUP
>>stays out of way.
>>
>>Kurt
>>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 08:17:55 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29841
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 08:17:54 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGD0P227596
	for ietf-ldup-bks; Fri, 16 Nov 2001 05:00:25 -0800 (PST)
Received: from hotmail.com (f21.law9.hotmail.com [64.4.9.21])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGD0O827592
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 05:00:24 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 05:00:20 -0800
Received: from 65.14.159.170 by lw9fd.law9.hotmail.msn.com with HTTP;
	Fri, 16 Nov 2001 13:00:20 GMT
X-Originating-IP: [65.14.159.170]
From: "Chris Apple" <imcapple@hotmail.com>
To: Kurt@OpenLDAP.org
Cc: ietf-ldup@imc.org
Subject: Re: Adding to the LDAP ACM to a WG charter
Date: Fri, 16 Nov 2001 08:00:20 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F21JbqJGNzscE8NpqhN0000d6ba@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 13:00:20.0608 (UTC) FILETIME=[A5A5D000:01C16E9E]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Thanks. So far, you are the only LDUP WG member
to raise such concerns. Which means that concensus
is currently leaning towards adding LDAP ACM to the
LDUP WG charter. That is clear by looking at the
postings on the topic in the mailing list archives.

However, I am still on the hook to post another
charter revision that includes LDAP ACM as a tool
to gauge WG concensus on the matter based on a
concrete proposal for deliverables.

As you know, WG concensus is what must be reflected
by John and I to the ADs and the IESG when it comes
to charter scoping, deliverables to be produced,
and additional work items.

So far, we only have a general concensus that the
ACM work should be added to the LDUP WG Charter.
If we are unable to achieve WG concensus on the
details of how to add it, it would of course not
be adopted.

All of the above would be subject to AD and IESG approval...

Which means that even if the WG believes it should do something,
it could be told "not so" by the IESG or the ADs.

Chris Apple

Who has finally figured out that life is mostly and rightfully
about wondering what to fix for dinner.


>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>To: "Chris Apple" <imcapple@hotmail.com>
>CC: ietf-ldup@imc.org
>Subject: Re: Adding to the LDAP ACM to a WG charter
>Date: Thu, 15 Nov 2001 21:02:44 -0800
>
>At 05:59 PM 2001-11-15, Chris Apple wrote:
> >1) You are asserting that the IETF process won't
> >  work for LDAP ACM and would need to be modified
> >  slightly to result in the production of a good
> >  LDAP ACM specification.
>
>I see no need to change IETF process [RFC 2026] or
>WG guidelines [RFC 2418] and am not advocating such.
>The IETF process and guidelines are flexible.  The
>process considers both working group and individual
>efforts in producing RFCs.
>
>Presently, I believe that LDAP ACM standardization
>work is best pursued on an individual basis.
>
> >2) You are advocating that this process modification
> >  would be that multiple proposals for an LDAP ACM
> >  should be written outside of the context of any WG.
>
>I am suggesting that we let individuals pursue this work
>under the established process.
>
> >3) You are expecting one of these proposals to become
> >  vetted in some way to become the eventual product
> >  of a WG other than LDUP.
>
>I am hoping that one or more proposals of appropriate quality,
>drafted by individuals, would be submitted for consideration
>for publication.  As with any other submission to the IETF,
>the IETF would review these works and take appropriate action.
>
>My assertions apply equally to LDUP as to any WG which might
>consider taking on LDAP ACM work (or be formed specifically
>for this work).  Any reference I made to LDUP was solely due
>to the fact it happens to be the WG considering taking on
>LDAP ACM work.  I don't think changing the WG venue matters
>much (as the interested parties follow the work).
>
> >4) You are asserting that the LDUP WG will either produce an
> >  inferior or at least a delayed LDAP ACM than a different
> >  WG with the same members would be able to.
>
>I believe any WG taking on LDAP ACM work will be stalled due
>to lack of consensus.  Individuals, not subject to WG
>consensus, can produce an LDAP ACM for consideration by the
>IETF much faster.
>
>Of course, any LDAP ACM I-D submitted for consideration on
>the Standard Track, whether produced by a WG or individuals,
>has IETF consensus requirements.
>
>And, in terms of meeting overall desires (powerful, flexible,
>extensible, etc.), I think individuals can do better than
>a WG in this case.  LDAPext had to remove functionality to
>remove contention.  Individuals generally don't have to do
>that.
>
>Anybody remember the SGMP/CMOT wars which resulted in SNMP?
>Basically I am suggesting a similar approach.  That is, let
>each set of individuals develop the very best specification
>they can, make "where's the ACM?" buttons ;-) and then
>consider how to proceed.
>
>Kurt
>
> >>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
> >>To: ietf-ldup@imc.org
> >>Subject: Adding to the LDAP ACM to a WG charter
> >>Date: Thu, 15 Nov 2001 16:55:57 -0800
> >>
> >>
> >>This message is intended to clarify the reasons why I
> >>oppose having LDAP ACM work item on any IETF WG charter
> >>at this time.
> >>
> >>Many (most?) of us (including I) would like very much
> >>to see LDAP have a Standard Track powerful, flexible,
> >>and extensible standard track access control model.
> >>Many of us have tried very hard to produce such.  But
> >>after years of trying, it became clear that the IETF
> >>was not going to reach consensus on a number of critical
> >>issues.  The issues are the same, the people are (mostly)
> >>the same, a change of venue (LDAPext->LDUP) won't help.
> >>
> >>But a change to which process used may help.  Those who
> >>support an LDAPext-ACM based solution should, as individuals,
> >>produce the best damn LDAP ACM specification they can and
> >>those who support alternative approaches should, as
> >>individuals, produce the best damn specification they can.
> >>We should give each set of individuals a reasonable amount
> >>of time to produces these specifications.   Then, based upon
> >>what is produced by the sets of individuals, determine how
> >>best to proceed:
> >>        a) adopt one (publish on Standard Track)
> >>        b) adopt none
> >>        c) create a WG to take one approach to Standard Track
> >>
> >>Based upon discussions I had at IETF#51 and with individuals
> >>since then, I believe we will soon multiple pretty damn good
> >>alternatives submitted (post IETF#52).
> >>
> >>IMO, we'll have an LDAP ACM must sooner than later if LDUP
> >>stays out of way.
> >>
> >>Kurt
> >>
> >
> >
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 12:41:20 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13298
	for <ldup-archive@lists.ietf.org>; Fri, 16 Nov 2001 12:41:20 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAGHK8923373
	for ietf-ldup-bks; Fri, 16 Nov 2001 09:20:08 -0800 (PST)
Received: from hotmail.com (oe66.law9.hotmail.com [64.4.8.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGHK7823368
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 09:20:07 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 09:20:04 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
Subject: RE: RE: moving access control discussion to LDUP
Date: Fri, 16 Nov 2001 12:13:13 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE664GuphfKJjkj8Bd3000088df@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 17:20:04.0876 (UTC) FILETIME=[EE9864C0:01C16EC2]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Kurt wrote:

Please note that I feel the LDUP WG should not undertake
the LDAP ACM work or any other new work.  The LDUP WG
needs to narrow its focus and trim its workload if it
is ever to successfully conclude.

> Please make specific recommendations about how
> the WG should trim its workload while still meeting
> all requirements specified in the requirements I-D.
> The rationale for phrasing my request in this way is
> that the requirements I-D has pass WG Last Call
> and a recommendation has been made for the ADs
> to take it to the IESG for consideration for an IETF
> Last Call. At this stage in a document's lifecycle, we
> cannot trim work from the charter unless we remove
> any affected requirements from that I-D, which would
> mean withdrawing the request from the ADs and would
> only serve to put the working group in a holding pattern
> while a round of mailing list deliberations over which
> requirements are too important to drop, etc.

And also I ask that the charter be clarified as to the
extent of work this WG is undertaking (or intends to
undertake).  In particular, the charter should state
whether or not the group intends to:
 1) Update LDAPv3 "core" specification (including
    its normative references),

John's and my position on that issue are very clear.
We believe that this is a technical issue that should be
discussed in the context of documents which may or
may not actually attempt to do this. I have not seen similar
concerns raised by any other working group member.

 2) Define an ACM for LDAPv3, and/or
 3) Define an authentication identity to
    authorization identity mapping scheme.

(Note that the mapping scheme is needed for an ACM
to provide any reasonable level of consistent access
to client entities in a replicated environment.)

Kurt

> The two items above have been added to the
> proposed WG charter to be posted shortly after this
> reply to your posting. After having a few other
> messages trickle into my mailbox out of time sequence,
> I have observed that there is one other person who
> has expressed concern over adding the ACM work
> to the charter. That's two WG members versus several
> who believe that it should be added. So, consensus still
> leans towards adding the ACM work rather than
> allowing the work to take place based on competing
> individual contributions.

Chris Apple

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 13:19:08 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15153
	for <ldup-archive@lists.ietf.org>; Fri, 16 Nov 2001 13:19:07 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGHSKk24060
	for ietf-ldup-bks; Fri, 16 Nov 2001 09:28:20 -0800 (PST)
Received: from hotmail.com (oe76.law9.hotmail.com [64.4.8.211])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGHSJ824055
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 09:28:19 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 09:28:16 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
Cc: "John Strassner" <john.strassner@intelliden.com>,
        "Paf@Cisco. Com" <paf@cisco.com>
Subject: revised WG charter proposal
Date: Fri, 16 Nov 2001 12:21:24 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE76COrsQILbU7q7TjD0000a30b@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 17:28:16.0530 (UTC) FILETIME=[13A4D720:01C16EC4]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Here's the latest revision incorporating several changes received both on
the list
and privately. Also note the accomplishment of several milestones since the
last proposal was posted to the list.

Because of the upcoming holiday in the US, lets evaluate and discuss this
version until 1700 ET US time on Tuesday, November 27, 2001.

Silence means consent.

Please read and post comments to the WG mailing list.

Chris Apple

Who has recently concluded that life is mostly and rightfully about
wondering what to make for dinner for family and friends.

LDAP Duplication/Replication/Update Protocols (ldup)

Last Modified: 16-Nov-01

Chair(s):

Chris Apple <imcapple@hotmail.com>
John Strassner <john.strassner@intelliden.com>

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

General Discussion:ietf-ldup@imc.org
To Subscribe: ietf-ldup-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-ldup/

Description of Working Group:

As LDAPv3 becomes more widely deployed, replication of data across
servers running different implementations becomes an important part
of providing a distributed directory service. However, the LDAPv3
community, to date, has focused on standardizing the client-server
access protocol. Therefore, this group will standardize master-slave
and multi-master LDAPv3 replication as defined below:

o Multi-Master Replication - A replication model where entries can
  be written and updated on any of several replica copies, without
  requiring communication with other masters before the write or
  update is performed.

o Master-Slave, or Single-Master Replication - A replication model
  that assumes only one server, the master, allows write access to
  the replicated data. Note that Master-Slave replication can be
  considered a proper subset of multi-master replication.

The WG's approach is to first develop a set of requirements for
LDAPv3 directory replication and write an applicability statement
defining scenarios on which replication requirements are based.
An engineering team was formed consisting of different vendors
and the co-chairs in order to harmonize the existing approaches
into a single standard approach. All of these have been accomplished
during the pre-working group stage.

The new replication architecture support all forms of replication
mentioned above. Eight areas of working group focus have been
identified through LDUP Engineering Team discussions and mailing
list discussion, each leading to one or more documents to be published:

o LDAPv3 Replication Architecture

   This documents a general-purpose LDAPv3 replication architecture,
   defines key components of this architecture, describes how these
   key components functionally behave, and describes how these
   components interact with each other when in various modes of
   operation.

o LDAPv3 Replication Information Model

   Defines the schema and semantics of information used to operate,
   administer, maintain, and provision replication between LDAPv3
   servers. Specifically, this document will contain common schema
   specifications intended to facilitate interoperable
   implementations with respect to:

      + replication agreements

      + consistency models

      + replication topologies

      + managing deleted objects and their states

      + administration and management

o LDAPv3 Replication Information Transport Protocol

   LDAPv3 extended operation and control specifications required to
   allow LDAPv3 to be used as the transport protocol for information
   being replicated

o LDAPv3 Mandatory Replica Management

   Specifications required to allow administration, maintenance, and
   provisioning of replicas and replication agreements. These
   specifications may take the form of definitions for LDAPv3
   extended operations, controls, and/or new schema elements.

o LDAPv3 Update Reconciliation Procedures

   Procedures for detection and resolution of conflicts between the
   state of multiple replicas that contain information from the same
   unit of replication.

o LDAPv3 Replication Usage Profile

   Including the LDAPv3 Replication Architecture, Information Model,
   Protocol Extensions, and Update Reconciliation Procedures for:

      + LDAPv3 Master-Slave Directory Replication

      + LDAPv3 Multi-Master Directory Replication

o LDAPv3 Client Update

   A protocol that enables an LDAP client to synchronize with the
   content of a directory information tree (DIT) stored by an LDAP
   server and to be notified about the changes to that content.

o LDAPv3 Access Control Issues

   Replication using heterogeneous LDAPv3 servers is dependent on
   resolving LDAPv3 access control issues, which are currently in
   the domain of another Applications Area working group. RFC 2820,
   Access Control Requirements for LDAP, was produced by that working
   group. However, this working group has elected to close prior to
   establishing consensus on other documents, such as an Access Control
   Model specification for LDAPv3. Such documents are necessary for
   LDUP to meet certain replication requirements documented by the
   LDUP WG. Thus, the remaining access control work and the latest
   revision of the access control model Internet Draft produced by
   the originating working group as starting point for continuing
   the work in the LDUP WG.

The work being done in the LDUP WG should be coordinated to the
closest extent possible with similar work being done in the ITU.
This is necessary both because LDAP depends on X.500 and because
it makes sense from an operational perspective.


Goals and Milestones:

Done    Submit I-D on LDAPv3 Directory Replication Requirements.

Done    Submit Internet-Draft on LDAPv3 Replication Information Model.

Done    Submit I-D on LDAPv3 Update Reconciliation Procedures.

Done    Revise I-D on LDAPv3 Directory Replication Requirements.

Done    Revise I-D on LDAPv3 Replication Architecture.

Done    Revise I-D on LDAPv3 Replication Architecture.

Done    Revise I-D on LDAPv3 Replication Information Model.

Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.

Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
        Call as Informational.

Done    Submit I-D on LDAPv3 Mandatory Replica Management.

Done Submit I-D on General LDUP Usage Profile.

Done Submit I-D on LDAPv3 Operations Framing.

Done I-D on LDAPv3 Extended Operations for Framing goes to WG Last
        Call as Proposed Standard.

Done Revise I-D on LDAPv3 Replication Information Transport Protocol.

Done Revise I-D on General LDUP Usage Profile.

Done Revise I-D on LDAPv3 Mandatory Replica Management.

Dec 01 LDAPv3 Client Update Protocol I-D goes to WG Last Call as
        Proposed Standard.

Dec 01 Rename the Access Control Model for LDAPv3 document to become an
 LDUP WG deliverable.

Jan 01  Revise Access Control Model for LDAPv3 I-D.

Jan 01  Submit an I-D on LDAPv3 Authentication Identity to Authorization
        Identity Mapping Scheme.

Feb 02 LDAPv3 Replication Architecture I-D goes to WG Last Call as
        Informational.

Mar 02 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call
        as Proposed Standard.

Mar 02 LDAPv3 Replication Information Model I-D goes to WG Last Call as
        Proposed Standard.

Mar 02 LDAPv3 Replication Information Transport Protocol I-D goes to WG
        Last Call as Proposed Standard.

Mar 02  Revise I-D on Authentication Identity to Authorization Identity
 Mapping Scheme for LDAPv3.

Apr 02  Access Control Model for LDAPv3 I-D goes to WG Last Call as
        Proposed Standard.

May 02  Authentication Identity to Authorization Identity Mapping Scheme for
 LDAPv3 I-D goes to WG Last Call as Proposed Standard.

Jun 02 LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
        Proposed Standard.

Jul 02 Re-evaluate Charter and Milestones.


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 13:54:53 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17381
	for <ldup-archive@lists.ietf.org>; Fri, 16 Nov 2001 13:54:53 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGIURb28417
	for ietf-ldup-bks; Fri, 16 Nov 2001 10:30:27 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGIUP828412
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 10:30:26 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAGIZiC56626;
	Fri, 16 Nov 2001 18:35:44 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116102545.016a4db8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Nov 2001 10:29:51 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Updating "core" specification
Cc: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
In-Reply-To: <OE664GuphfKJjkj8Bd3000088df@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 09:13 AM 2001-11-16, Chris Apple wrote:
>And also I ask that the charter be clarified as to the
>extent of work this WG is undertaking (or intends to
>undertake).  In particular, the charter should state
>whether or not the group intends to:
> 1) Update LDAPv3 "core" specification (including
>    its normative references),
>
>John's and my position on that issue are very clear.
>We believe that this is a technical issue that should be
>discussed in the context of documents which may or
>may not actually attempt to do this. I have not seen similar
>concerns raised by any other working group member.

I then ask that you clarify this in the charter.  That is,
add something like:
  This group may update the LDAPv3 "core" specification
  as necessary to deliver LDAP Replication.

Kurt



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 13:56:36 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17521
	for <ldup-archive@lists.ietf.org>; Fri, 16 Nov 2001 13:56:35 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAGIdGX29444
	for ietf-ldup-bks; Fri, 16 Nov 2001 10:39:16 -0800 (PST)
Received: from hotmail.com (oe38.law9.hotmail.com [64.4.8.95])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGIdF829437
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 10:39:15 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 10:39:13 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
References: <5.1.0.14.0.20011116102545.016a4db8@127.0.0.1>
Subject: Re: Updating "core" specification
Date: Fri, 16 Nov 2001 13:32:20 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE38fjpyr6gz1Lz7ccD0000241a@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 18:39:13.0216 (UTC) FILETIME=[FCD39400:01C16ECD]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


That's simple enough to do. We'll add it near the
paragraph that talks about X.500 - LDAP alignment
unless there are a substantial number of objections
to doing so posted to the list.

Chris.

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth
----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Chris Apple" <imcapple@hotmail.com>
Cc: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
Sent: Friday, November 16, 2001 1:29 PM
Subject: Updating "core" specification


> At 09:13 AM 2001-11-16, Chris Apple wrote:
> >And also I ask that the charter be clarified as to the
> >extent of work this WG is undertaking (or intends to
> >undertake).  In particular, the charter should state
> >whether or not the group intends to:
> > 1) Update LDAPv3 "core" specification (including
> >    its normative references),
> >
> >John's and my position on that issue are very clear.
> >We believe that this is a technical issue that should be
> >discussed in the context of documents which may or
> >may not actually attempt to do this. I have not seen similar
> >concerns raised by any other working group member.
>
> I then ask that you clarify this in the charter.  That is,
> add something like:
>   This group may update the LDAPv3 "core" specification
>   as necessary to deliver LDAP Replication.
>
> Kurt
>
>


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 14:01:08 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17823
	for <ldup-archive@lists.ietf.org>; Fri, 16 Nov 2001 14:01:07 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGIZBh28816
	for ietf-ldup-bks; Fri, 16 Nov 2001 10:35:11 -0800 (PST)
Received: from cosds003.continuumnetworks.com ([12.41.184.243])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGIZ9828809
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 10:35:09 -0800 (PST)
Received: from FARILJCS ([12.41.186.49]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GMWOY200.D7P; Fri, 16 Nov 2001 11:34:50 -0700 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        "Chris Apple" <imcapple@hotmail.com>
Cc: <ietf-ldup@imc.org>
Subject: RE: Adding to the LDAP ACM to a WG charter
Date: Fri, 16 Nov 2001 11:34:54 -0700
Message-ID: <FCEKLEHMPIHFNLCMKHAMEEJHCPAA.john.strassner@intelliden.com>
MIME-Version: 1.0
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: <5.1.0.14.0.20011115185618.0171e5e8@127.0.0.1>
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_0702_01C16E92.B5D59AC0";
	micalg=SHA1;
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0702_01C16E92.B5D59AC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kurt,

thanks for the reply. I don't understand why you think it would be more
efficient for a group of authors to individually produce competing drafts
that would then have to go through the same consensus building process
that is inherently present in a working group. In addition, this would
make the logistics for people trying to work on this problem much more
difficult. I also fail to see the analogy with SNMP.

Finally, you seem to be taking the attitude that we should abandon the
current work and start over. I think that this is a mistake. The current
work has represented an increasingly growing consensus through its
development. It represents, imo, a viable starting point, and one that
should not be thrown away just because LDAPext is closing down. Replacing
a good starting point with some indeterminate number of new proposals,
drafted as individual submissions without a working group to help guide
discussions, doesn't seem to be a viable solution at all.

regards,
John

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga
Sent: Thursday, November 15, 2001 10:03 PM
To: Chris Apple
Cc: ietf-ldup@imc.org
Subject: Re: Adding to the LDAP ACM to a WG charter



At 05:59 PM 2001-11-15, Chris Apple wrote:
>1) You are asserting that the IETF process won't
>  work for LDAP ACM and would need to be modified
>  slightly to result in the production of a good
>  LDAP ACM specification.

I see no need to change IETF process [RFC 2026] or
WG guidelines [RFC 2418] and am not advocating such.
The IETF process and guidelines are flexible.  The
process considers both working group and individual
efforts in producing RFCs.

Presently, I believe that LDAP ACM standardization
work is best pursued on an individual basis.

>2) You are advocating that this process modification
>  would be that multiple proposals for an LDAP ACM
>  should be written outside of the context of any WG.

I am suggesting that we let individuals pursue this work
under the established process.

>3) You are expecting one of these proposals to become
>  vetted in some way to become the eventual product
>  of a WG other than LDUP.

I am hoping that one or more proposals of appropriate quality,
drafted by individuals, would be submitted for consideration
for publication.  As with any other submission to the IETF,
the IETF would review these works and take appropriate action.

My assertions apply equally to LDUP as to any WG which might
consider taking on LDAP ACM work (or be formed specifically
for this work).  Any reference I made to LDUP was solely due
to the fact it happens to be the WG considering taking on
LDAP ACM work.  I don't think changing the WG venue matters
much (as the interested parties follow the work).

>4) You are asserting that the LDUP WG will either produce an
>  inferior or at least a delayed LDAP ACM than a different
>  WG with the same members would be able to.

I believe any WG taking on LDAP ACM work will be stalled due
to lack of consensus.  Individuals, not subject to WG
consensus, can produce an LDAP ACM for consideration by the
IETF much faster.

Of course, any LDAP ACM I-D submitted for consideration on
the Standard Track, whether produced by a WG or individuals,
has IETF consensus requirements.

And, in terms of meeting overall desires (powerful, flexible,
extensible, etc.), I think individuals can do better than
a WG in this case.  LDAPext had to remove functionality to
remove contention.  Individuals generally don't have to do
that.

Anybody remember the SGMP/CMOT wars which resulted in SNMP?
Basically I am suggesting a similar approach.  That is, let
each set of individuals develop the very best specification
they can, make "where's the ACM?" buttons ;-) and then
consider how to proceed.

Kurt

>>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>>To: ietf-ldup@imc.org
>>Subject: Adding to the LDAP ACM to a WG charter
>>Date: Thu, 15 Nov 2001 16:55:57 -0800
>>
>>
>>This message is intended to clarify the reasons why I
>>oppose having LDAP ACM work item on any IETF WG charter
>>at this time.
>>
>>Many (most?) of us (including I) would like very much
>>to see LDAP have a Standard Track powerful, flexible,
>>and extensible standard track access control model.
>>Many of us have tried very hard to produce such.  But
>>after years of trying, it became clear that the IETF
>>was not going to reach consensus on a number of critical
>>issues.  The issues are the same, the people are (mostly)
>>the same, a change of venue (LDAPext->LDUP) won't help.
>>
>>But a change to which process used may help.  Those who
>>support an LDAPext-ACM based solution should, as individuals,
>>produce the best damn LDAP ACM specification they can and
>>those who support alternative approaches should, as
>>individuals, produce the best damn specification they can.
>>We should give each set of individuals a reasonable amount
>>of time to produces these specifications.   Then, based upon
>>what is produced by the sets of individuals, determine how
>>best to proceed:
>>        a) adopt one (publish on Standard Track)
>>        b) adopt none
>>        c) create a WG to take one approach to Standard Track
>>
>>Based upon discussions I had at IETF#51 and with individuals
>>since then, I believe we will soon multiple pretty damn good
>>alternatives submitted (post IETF#52).
>>
>>IMO, we'll have an LDAP ACM must sooner than later if LDUP
>>stays out of way.
>>
>>Kurt
>>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp


------=_NextPart_000_0702_01C16E92.B5D59AC0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTExNjE4MzQ1M1owIwYJKoZIhvcNAQkEMRYEFAeTE9Lt8jWGGFRGqaIwTZejK/fb
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAMXcs
Jmh/Lk0YU1Ow02bsVNQZOcp5Y/4yzoqNGZz3IdSoXuNcjw2iGTJu3ADVOv5krKUReaMrV3eZypTX
z5DpbkvE+rLYMrTO8mrA66CrVnjZJ4/6y1VfGZoeAAlAACcV8pWVAu8YjGkgeKs7vR/bp/t6t6p9
d9Oyp4nHmvOTOacAAAAAAAA=

------=_NextPart_000_0702_01C16E92.B5D59AC0--



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 16:12:12 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25575
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 16:12:11 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGKmNh13556
	for ietf-ldup-bks; Fri, 16 Nov 2001 12:48:23 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGKmK813548
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 12:48:20 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAGKrVC57000;
	Fri, 16 Nov 2001 20:53:33 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116120849.01738700@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Nov 2001 12:47:46 -0800
To: <john.strassner@intelliden.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: Adding to the LDAP ACM to a WG charter
Cc: "Chris Apple" <imcapple@hotmail.com>, <ietf-ldup@imc.org>
In-Reply-To: <FCEKLEHMPIHFNLCMKHAMEEJHCPAA.john.strassner@intelliden.com
 >
References: <5.1.0.14.0.20011115185618.0171e5e8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 10:34 AM 2001-11-16, John Strassner wrote:
>Finally, you seem to be taking the attitude that we should abandon the
>current work and start over.

No, I have suggested that the proponents, as individuals, of the
LDAPext ACM approach develop this into the best damn solution
they can.  And I have suggested those who are proponents of
alternative approaches develop them into the best damn solution
they can.

I am sure the ADs would (or will, LDAPext isn't concluded yet)
give them LDAPext more time if the ADs believed LDAPext could
complete the work in a reasonable amount of time.  But the fact
is that after many long years of trying, LDAPext could not
complete the work.  Not for lack of desire, not for lack of
effort, not for the lack of expertise, and certainly not for
the lack of good work by many good people.  LDAPext could not
complete the work due to a lack of consensus on the overall
approach and on numerous technical details.

The LDUP WG will fair no better than LDAPext would if it is
allowed to continue.  So, if there if the consensus is to
do this work in a WG, I would much rather re-charter LDAPext
(or create a new WG) to do it then to saddle LDUP with yet
another major work item.

Lastly, I note that I concur many of the statements Paul and
Rob regarding this proposed work item, in particular:
  "The problems are factorable, and problems that get factored
  get solved quicker" [Paul in regards to decoupling LDUP work
  from LDAP ACM work].
  <http://www.imc.org/ietf-ldup/mail-archive/msg01232.html>

  Rob's "opinion on the progreess of the acl draft, is that,
  unfortunately, in LDAP life-time terms it is very (if not,
  too) late to successfully progress this to a standard, ...
  the main problem as 'entrenched vendors'" [Rob in
  describing one of the problems the IETF must overcome in
  delivering an LDAP ACM]
  <http://www.imc.org/ietf-ldup/mail-archive/msg01210.html>



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 17:45:43 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28100
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 17:45:42 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGMN9v23911
	for ietf-ldup-bks; Fri, 16 Nov 2001 14:23:09 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGMN7823905
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 14:23:07 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAGMSKC57328;
	Fri, 16 Nov 2001 22:28:20 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116142020.01730cc0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Nov 2001 14:22:36 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: ITU work (Re: revised WG charter proposal)
Cc: <ietf-ldup@imc.org>
In-Reply-To: <OE76COrsQILbU7q7TjD0000a30b@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 09:21 AM 2001-11-16, Chris Apple wrote:
>The work being done in the LDUP WG should be coordinated to the
>closest extent possible with similar work being done in the ITU.

Is their actually "similar work" being done by the ITU?

Kurt



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 17:53:58 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28321
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 17:53:57 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGMVlV25000
	for ietf-ldup-bks; Fri, 16 Nov 2001 14:31:47 -0800 (PST)
Received: from hotmail.com (oe56.law9.hotmail.com [64.4.8.191])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGMVk824995
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 14:31:46 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 14:31:45 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
References: <5.1.0.14.0.20011116142020.01730cc0@127.0.0.1>
Subject: Re: ITU work (Re: revised WG charter proposal)
Date: Fri, 16 Nov 2001 17:24:53 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE568ECXqgxwfb6v96M0001ccfa@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 22:31:45.0030 (UTC) FILETIME=[78C17260:01C16EEE]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


The desire to support multi-master replication was common across ITU/X.500
and IETF/LDAP standards
work.

I think that it would be wise to additionally ask if its possible that
similar work could arise in the future.

I believe that the present wording of the charter covers both the present
and future cases adequately
and doesn't really need change or clarification.

I realize that this doesn't answer your question in a detailed way, but I'm
focusing on whether or not
the charter proposal should change based on comments related to it. In this
case, your comment
(and my expansion of it) are already addressed in current text.

I have a document floating around that goes into this topic in more depth -
will take me a bit
of time to dig it up given the speed with which I had to hand over my laptop
to my former
employer.

Chris.

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth
----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Chris Apple" <imcapple@hotmail.com>
Cc: <ietf-ldup@imc.org>
Sent: Friday, November 16, 2001 5:22 PM
Subject: ITU work (Re: revised WG charter proposal)


> At 09:21 AM 2001-11-16, Chris Apple wrote:
> >The work being done in the LDUP WG should be coordinated to the
> >closest extent possible with similar work being done in the ITU.
>
> Is their actually "similar work" being done by the ITU?
>
> Kurt
>
>


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 18:12:28 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28790
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 18:12:27 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGMpju27469
	for ietf-ldup-bks; Fri, 16 Nov 2001 14:51:45 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGMph827463
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 14:51:43 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 14:51:19 -0800
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Nov 2001 14:51:19 -0800
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 14:51:19 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 14:51:19 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Fri, 16 Nov 2001 14:50:38 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Adding to the LDAP ACM to a WG charter
Date: Fri, 16 Nov 2001 14:50:38 -0800
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD02A8798B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Adding to the LDAP ACM to a WG charter
thread-index: AcFunxvQxyD0HQXBS9i3Mv2d48PYQAAUTtgQ
From: "Paul Leach" <paulle@windows.microsoft.com>
To: "Chris Apple" <imcapple@hotmail.com>, <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
X-OriginalArrivalTime: 16 Nov 2001 22:50:38.0618 (UTC) FILETIME=[1C6D3FA0:01C16EF1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAGMph827464
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: Chris Apple [mailto:imcapple@hotmail.com] 
> Sent: Friday, November 16, 2001 5:00 AM
> To: Kurt@OpenLDAP.org
> Cc: ietf-ldup@imc.org
> Subject: Re: Adding to the LDAP ACM to a WG charter
> 
> 
> 
> Thanks. So far, you are the only LDUP WG member
> to raise such concerns. Which means that concensus
> is currently leaning towards adding LDAP ACM to the
> LDUP WG charter. That is clear by looking at the
> postings on the topic in the mailing list archives.

I'm sorry, but two other people at least have echoed Kurt's concern.
Maybe that still means there is concensus, but we'd like to be
acknowledged as objecting. And as far as I could see, there weren't many
more than 3 in favor, so I actually question that concensus has been
reached.

> 
> However, I am still on the hook to post another
> charter revision that includes LDAP ACM as a tool
> to gauge WG concensus on the matter based on a
> concrete proposal for deliverables.

That's fair.

Paul


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 18:16:33 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28866
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 18:16:32 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGMvJ027932
	for ietf-ldup-bks; Fri, 16 Nov 2001 14:57:19 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGMvI827927
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 14:57:18 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAGN2bC57424;
	Fri, 16 Nov 2001 23:02:37 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116145125.0172d128@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Nov 2001 14:56:52 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: LDAPv4?  (Was: Updating "core" specification)
Cc: <ietf-ldup@imc.org>
In-Reply-To: <OE38fjpyr6gz1Lz7ccD0000241a@hotmail.com>
References: <5.1.0.14.0.20011116102545.016a4db8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


(This is a serious question, I am still trying to figure out
what is beyond scope of this working group.)

Is engineering a version 4 of LDAP within scope?

At 10:32 AM 2001-11-16, Chris Apple wrote:
>That's simple enough to do. We'll add...
>>   This group may update the LDAPv3 "core" specification
>>   as necessary to deliver LDAP Replication.



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 18:20:01 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28908
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 18:20:01 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAGN10428233
	for ietf-ldup-bks; Fri, 16 Nov 2001 15:01:00 -0800 (PST)
Received: from hotmail.com (oe45.law9.hotmail.com [64.4.8.17])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGN0x828228
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 15:00:59 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 15:00:57 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
References: <5.1.0.14.0.20011116102545.016a4db8@127.0.0.1> <5.1.0.14.0.20011116145125.0172d128@127.0.0.1>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
Date: Fri, 16 Nov 2001 17:54:03 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE45Y30kkZIhTrBoe2U00005dfb@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 23:00:57.0416 (UTC) FILETIME=[8D425480:01C16EF2]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


No. But I don't see the value in writing that in...what is
this particular concern based on?

Chris.

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth
----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Chris Apple" <imcapple@hotmail.com>
Cc: <ietf-ldup@imc.org>
Sent: Friday, November 16, 2001 5:56 PM
Subject: LDAPv4? (Was: Updating "core" specification)


> (This is a serious question, I am still trying to figure out
> what is beyond scope of this working group.)
>
> Is engineering a version 4 of LDAP within scope?
>
> At 10:32 AM 2001-11-16, Chris Apple wrote:
> >That's simple enough to do. We'll add...
> >>   This group may update the LDAPv3 "core" specification
> >>   as necessary to deliver LDAP Replication.
>
>


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 18:24:18 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29003
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 18:24:18 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGN5Yi28628
	for ietf-ldup-bks; Fri, 16 Nov 2001 15:05:34 -0800 (PST)
Received: from hotmail.com (oe27.law9.hotmail.com [64.4.8.84])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGN5X828623
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 15:05:33 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 15:05:32 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Paul Leach" <paulle@windows.microsoft.com>, <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
References: <4AEE3169443CDD4796CA8A00B02191CD02A8798B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Subject: Re: Adding to the LDAP ACM to a WG charter
Date: Fri, 16 Nov 2001 17:58:39 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE27YnZlmDVRXGsNLqY00008f69@hotmail.com>
X-OriginalArrivalTime: 16 Nov 2001 23:05:32.0028 (UTC) FILETIME=[30F0CBC0:01C16EF3]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


One of those folks' posting didn't reach me until after I'd already sent out
that
particular posting.

I sort of counted your other posting on the topic somewhere in the middle -
you didn't
seem to me to be expressing an objection to adding ACM, but said you thought
it was
possible. I'm taking this response of yours to mean that I should count you
as one of the
3 WG members who are objecting to ACM being added to LDUP's charter.

I'll have to give the archive another pass and see if I missed other WG
members
saying yes or no...

And note that I didn't say we have reached concensus - I said that consensus
is leaning
towards adding ACM (or it appeared so at the time).

Chris.

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth
----- Original Message -----
From: "Paul Leach" <paulle@windows.microsoft.com>
To: "Chris Apple" <imcapple@hotmail.com>; <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
Sent: Friday, November 16, 2001 5:50 PM
Subject: RE: Adding to the LDAP ACM to a WG charter



> -----Original Message-----
> From: Chris Apple [mailto:imcapple@hotmail.com]
> Sent: Friday, November 16, 2001 5:00 AM
> To: Kurt@OpenLDAP.org
> Cc: ietf-ldup@imc.org
> Subject: Re: Adding to the LDAP ACM to a WG charter
>
>
>
> Thanks. So far, you are the only LDUP WG member
> to raise such concerns. Which means that concensus
> is currently leaning towards adding LDAP ACM to the
> LDUP WG charter. That is clear by looking at the
> postings on the topic in the mailing list archives.

I'm sorry, but two other people at least have echoed Kurt's concern.
Maybe that still means there is concensus, but we'd like to be
acknowledged as objecting. And as far as I could see, there weren't many
more than 3 in favor, so I actually question that concensus has been
reached.

>
> However, I am still on the hook to post another
> charter revision that includes LDAP ACM as a tool
> to gauge WG concensus on the matter based on a
> concrete proposal for deliverables.

That's fair.

Paul



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 18:57:55 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29830
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 18:57:55 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGNeUf01501
	for ietf-ldup-bks; Fri, 16 Nov 2001 15:40:30 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGNeS801496
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 15:40:29 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAGNjcC57530;
	Fri, 16 Nov 2001 23:45:38 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116153029.0171a388@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Nov 2001 15:39:53 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
Cc: <ietf-ldup@imc.org>
In-Reply-To: <OE45Y30kkZIhTrBoe2U00005dfb@hotmail.com>
References: <5.1.0.14.0.20011116102545.016a4db8@127.0.0.1>
 <5.1.0.14.0.20011116145125.0172d128@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 02:54 PM 2001-11-16, Chris Apple wrote:
>No. But I don't see the value in writing that in...what is
>this particular concern based on?

Again, I am still trying to figure out what is beyond scope
of this working group.

Can the previously suggested statement be further narrowed?
Say to:

  This group may extend the LDAPv3 "core" specification 
  as necessary to deliver LDAP Replication.  However,
  updating the LDAPv3 "core" specification is beyond scope
  of this working group.




From owner-ietf-ldup@mail.imc.org  Fri Nov 16 19:17:06 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00141
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 19:17:06 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAGNxHr03189
	for ietf-ldup-bks; Fri, 16 Nov 2001 15:59:17 -0800 (PST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGNxF803182
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 15:59:15 -0800 (PST)
Received: from qsun.mt.att.com ([135.16.30.2])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id fAGNxBY13246;
	Fri, 16 Nov 2001 18:59:11 -0500 (EST)
Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2)
	id SAA00863; Fri, 16 Nov 2001 18:59:10 -0500
Date: Fri, 16 Nov 2001 18:59:10 -0500
Message-Id: <200111162359.SAA00863@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: Kurt@OpenLDAP.org, imcapple@hotmail.com, paulle@windows.microsoft.com
Subject: Re: Adding to the LDAP ACM to a WG charter
Cc: ietf-ldup@imc.org
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


I see a number of interoperability issues that the ACM work addresses.

It is difficult to build systems that are directory vendor neutral if
they need to deal with access controls.  Examples include directory
maintenance systems and some types of provisioning systems (systems
that add new users to the directory in situations where access
permissions matter).

And as several others have already noted, it will also be very hard to
have a useful standard replication system without a standard way to
move access control information between systems.

Since LDAPEXT is shutting down, the ACM work needs a new home.  Since
most of the members of LDAPEXT are also part of LDUP, and since the ACM
work is needed for LDUP, LDUP seems like the right place to do it.

Access control is a complicated topic.  I think it needs the benefit of
the technical review a WG will provide.

Rick Huber

PS: If there's any doubt, this email is FOR adding ACM to the LDUP charter!

: From owner-ietf-ldup@mail.imc.org Fri Nov 16 18:31:12 2001
: From: "Chris Apple" <imcapple@hotmail.com>
: To: "Paul Leach" <paulle@windows.microsoft.com>, <Kurt@OpenLDAP.org>
: Cc: <ietf-ldup@imc.org>
: References: <4AEE3169443CDD4796CA8A00B02191CD02A8798B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
: Subject: Re: Adding to the LDAP ACM to a WG charter
: 
: One of those folks' posting didn't reach me until after I'd already sent out
: that
: particular posting.
: 
: I sort of counted your other posting on the topic somewhere in the middle -
: you didn't
: seem to me to be expressing an objection to adding ACM, but said you thought
: it was
: possible. I'm taking this response of yours to mean that I should count you
: as one of the
: 3 WG members who are objecting to ACM being added to LDUP's charter.
: 
: I'll have to give the archive another pass and see if I missed other WG
: members
: saying yes or no...
: 
: And note that I didn't say we have reached concensus - I said that consensus
: is leaning
: towards adding ACM (or it appeared so at the time).
: 
: Chris.
: 
: Currently self-employed pondering the meaning of life in Olde City,
: Philadelphia, PA, US, Earth
: ----- Original Message -----
: From: "Paul Leach" <paulle@windows.microsoft.com>
: To: "Chris Apple" <imcapple@hotmail.com>; <Kurt@OpenLDAP.org>
: Cc: <ietf-ldup@imc.org>
: Sent: Friday, November 16, 2001 5:50 PM
: Subject: RE: Adding to the LDAP ACM to a WG charter
: 
: 
: 
: > -----Original Message-----
: > From: Chris Apple [mailto:imcapple@hotmail.com]
: > Sent: Friday, November 16, 2001 5:00 AM
: > To: Kurt@OpenLDAP.org
: > Cc: ietf-ldup@imc.org
: > Subject: Re: Adding to the LDAP ACM to a WG charter
: >
: >
: >
: > Thanks. So far, you are the only LDUP WG member
: > to raise such concerns. Which means that concensus
: > is currently leaning towards adding LDAP ACM to the
: > LDUP WG charter. That is clear by looking at the
: > postings on the topic in the mailing list archives.
: 
: I'm sorry, but two other people at least have echoed Kurt's concern.
: Maybe that still means there is concensus, but we'd like to be
: acknowledged as objecting. And as far as I could see, there weren't many
: more than 3 in favor, so I actually question that concensus has been
: reached.
: 
: >
: > However, I am still on the hook to post another
: > charter revision that includes LDAP ACM as a tool
: > to gauge WG concensus on the matter based on a
: > concrete proposal for deliverables.
: 
: That's fair.
: 
: Paul


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 19:42:13 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00600
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 19:42:13 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAH0PDl05521
	for ietf-ldup-bks; Fri, 16 Nov 2001 16:25:13 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH0PC805516
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 16:25:12 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAH0UVC57621;
	Sat, 17 Nov 2001 00:30:31 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116160406.0171cd10@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Nov 2001 16:24:46 -0800
To: rvh@qsun.mt.att.com (Richard V Huber)
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Adding to the LDAP ACM to a WG charter
Cc: ietf-ldup@imc.org
In-Reply-To: <200111162359.SAA00863@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 03:59 PM 2001-11-16, Richard V Huber wrote:
>Access control is a complicated topic.

What leads you (and others) believe LDUP WG can achieve
this objective in a reasonable amount of time?

How do you respond to those who believe the LDUP WG
will suffer from the same lack of consensus that LDAPext
faced in attempting this work?

Kurt



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 20:01:14 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00822
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 20:01:14 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAH0hUc07006
	for ietf-ldup-bks; Fri, 16 Nov 2001 16:43:30 -0800 (PST)
Received: from hotmail.com (oe18.law9.hotmail.com [64.4.8.122])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH0hT807001
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 16:43:29 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Nov 2001 16:31:50 -0800
X-Originating-IP: [141.151.16.78]
Reply-To: "Chris Apple" <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
References: <5.1.0.14.0.20011116102545.016a4db8@127.0.0.1> <5.1.0.14.0.20011116145125.0172d128@127.0.0.1> <5.1.0.14.0.20011116153029.0171a388@127.0.0.1>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
Date: Fri, 16 Nov 2001 19:24:55 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE18RhscmvHb0PPqMuJ0000a7ac@hotmail.com>
X-OriginalArrivalTime: 17 Nov 2001 00:31:50.0026 (UTC) FILETIME=[3F4496A0:01C16EFF]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


All editors should respond with their opinions on Kurt's current text
proposal for clarifying the charter to the WG mailing list ASAP.

I believe it reflects the strategy that we currently are
pursuing because of LDAPv3 installed base at the time
of initial charter creation. However, I want to hear from
the editors if this language is too constraining based on
what we know about the problems we still have to solve.

Chris.

Currently self-employed pondering the meaning of life in Olde City,
Philadelphia, PA, US, Earth
----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Chris Apple" <imcapple@hotmail.com>
Cc: <ietf-ldup@imc.org>
Sent: Friday, November 16, 2001 6:39 PM
Subject: Re: LDAPv4? (Was: Updating "core" specification)


>
> At 02:54 PM 2001-11-16, Chris Apple wrote:
> >No. But I don't see the value in writing that in...what is
> >this particular concern based on?
>
> Again, I am still trying to figure out what is beyond scope
> of this working group.
>
> Can the previously suggested statement be further narrowed?
> Say to:
>
>   This group may extend the LDAPv3 "core" specification
>   as necessary to deliver LDAP Replication.  However,
>   updating the LDAPv3 "core" specification is beyond scope
>   of this working group.
>
>
>


From owner-ietf-ldup@mail.imc.org  Fri Nov 16 20:04:34 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00856
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 20:04:34 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAH0mC607388
	for ietf-ldup-bks; Fri, 16 Nov 2001 16:48:12 -0800 (PST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH0mB807381
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 16:48:11 -0800 (PST)
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 16:47:48 -0800
Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Nov 2001 16:47:05 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 16:47:00 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 16:46:59 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Fri, 16 Nov 2001 16:46:19 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Adding to the LDAP ACM to a WG charter
Date: Fri, 16 Nov 2001 16:46:18 -0800
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD02A87990@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Adding to the LDAP ACM to a WG charter
thread-index: AcFu+rPhnq4ruLKURKqCNyhKB4KzIQABXx3A
From: "Paul Leach" <paulle@windows.microsoft.com>
To: "Richard V Huber" <rvh@qsun.mt.att.com>, <Kurt@OpenLDAP.org>,
        <imcapple@hotmail.com>
Cc: <ietf-ldup@imc.org>
X-OriginalArrivalTime: 17 Nov 2001 00:46:19.0452 (UTC) FILETIME=[457C77C0:01C16F01]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAH0mB807383
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit




> -----Original Message-----
> From: Richard V Huber [mailto:rvh@qsun.mt.att.com] 
> Sent: Friday, November 16, 2001 3:59 PM
> To: Kurt@OpenLDAP.org; imcapple@hotmail.com; Paul Leach
> Cc: ietf-ldup@imc.org
> Subject: Re: Adding to the LDAP ACM to a WG charter
> 

> 
> Since LDAPEXT is shutting down, the ACM work needs a new 
> home.  Since most of the members of LDAPEXT are also part of 
> LDUP, and since the ACM work is needed for LDUP, LDUP seems 
> like the right place to do it.
> 
> Access control is a complicated topic.  I think it needs the 
> benefit of the technical review a WG will provide.

The last paragraph at most argues for _some_ WG, but not necessarily
this one.

As Kurt has noted, the previous paragraph says that the same gang who
couldn't get an ACM done in LDAPEXT are just as likely to not get it
done in LDUP, and in the meantime, the focus on replication is vitiated.

I vote for starting another WG on ACM, or letting individuals do it. And
note that WGs can technically review things even if individuals propose
them.

Paul




From owner-ietf-ldup@mail.imc.org  Fri Nov 16 22:30:12 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03225
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 22:30:12 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAH3E4d17265
	for ietf-ldup-bks; Fri, 16 Nov 2001 19:14:04 -0800 (PST)
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH3E3817261
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 19:14:03 -0800 (PST)
Received: from sdn-ar-007cocsprp003.dialsprint.net ([63.178.245.11] helo=FARILJCS)
	by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1)
	id 164vvg-0000hq-00; Fri, 16 Nov 2001 19:14:05 -0800
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        "Chris Apple" <imcapple@hotmail.com>
Cc: <ietf-ldup@imc.org>
Subject: RE: LDAPv4?  (Was: Updating "core" specification)
Date: Fri, 16 Nov 2001 20:14:00 -0700
Message-ID: <FCEKLEHMPIHFNLCMKHAMGEKKCPAA.john.strassner@intelliden.com>
MIME-Version: 1.0
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: <5.1.0.14.0.20011116153029.0171a388@127.0.0.1>
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_089B_01C16EDB.39546550";
	micalg=SHA1;
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_089B_01C16EDB.39546550
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

How about answering my previous questions first? Especially since no where
in the charter is this mentioned?

John

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga
Sent: Friday, November 16, 2001 4:40 PM
To: Chris Apple
Cc: ietf-ldup@imc.org
Subject: Re: LDAPv4? (Was: Updating "core" specification)



At 02:54 PM 2001-11-16, Chris Apple wrote:
>No. But I don't see the value in writing that in...what is
>this particular concern based on?

Again, I am still trying to figure out what is beyond scope
of this working group.

Can the previously suggested statement be further narrowed?
Say to:

  This group may extend the LDAPv3 "core" specification
  as necessary to deliver LDAP Replication.  However,
  updating the LDAPv3 "core" specification is beyond scope
  of this working group.



------=_NextPart_000_089B_01C16EDB.39546550
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTExNzAzMTM1OFowIwYJKoZIhvcNAQkEMRYEFFb6cr4IecZFjOMcqwJ73rrcAUMI
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAn7TT
abqO0+h6zBkUXAiu7P71rEUCgGziC6H9nToSNZLDIw/Ux+1IpOEd1wl8uTLG2TjubfDhhiMDnt7L
09PP4kKOwkDBqJZ3r0jpexNfSBrVaR1/xfUOOti+oThXulYrjQMOpX5pkg0ItJNm/rtRbJfRboLS
uGe0+WibLCYMroEAAAAAAAA=

------=_NextPart_000_089B_01C16EDB.39546550--



From owner-ietf-ldup@mail.imc.org  Fri Nov 16 22:36:43 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04151
	for <ldup-archive@odin.ietf.org>; Fri, 16 Nov 2001 22:36:42 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAH3AET17209
	for ietf-ldup-bks; Fri, 16 Nov 2001 19:10:14 -0800 (PST)
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH3AD817205
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 19:10:13 -0800 (PST)
Received: from sdn-ar-007cocsprp003.dialsprint.net ([63.178.245.11] helo=FARILJCS)
	by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1)
	id 164vrg-0004WB-00; Fri, 16 Nov 2001 19:09:57 -0800
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        "Chris Apple" <imcapple@hotmail.com>
Cc: <ietf-ldup@imc.org>
Subject: RE: LDAPv4?  (Was: Updating "core" specification)
Date: Fri, 16 Nov 2001 20:09:54 -0700
Message-ID: <FCEKLEHMPIHFNLCMKHAMOEKJCPAA.john.strassner@intelliden.com>
MIME-Version: 1.0
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: <5.1.0.14.0.20011116145125.0172d128@127.0.0.1>
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_0888_01C16EDA.A655EEE0";
	micalg=SHA1;
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0888_01C16EDA.A655EEE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kurt,

I don't see how this can be a "serious" question. Where in the charter do
you read anything remotely resembling LDAPv4?

I'm still waiting for an answer to my earlier question about what,
specifically, you find so confusing about the charter and what,
specifically, you would reword. Questions like "what's not in the charter"
simply do not help.

John

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga
Sent: Friday, November 16, 2001 3:57 PM
To: Chris Apple
Cc: ietf-ldup@imc.org
Subject: LDAPv4? (Was: Updating "core" specification)



(This is a serious question, I am still trying to figure out
what is beyond scope of this working group.)

Is engineering a version 4 of LDAP within scope?

At 10:32 AM 2001-11-16, Chris Apple wrote:
>That's simple enough to do. We'll add...
>>   This group may update the LDAPv3 "core" specification
>>   as necessary to deliver LDAP Replication.


------=_NextPart_000_0888_01C16EDA.A655EEE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTExNzAzMDk1MVowIwYJKoZIhvcNAQkEMRYEFGyYfqFYcLhWFOQUpGyAmvM4ItOd
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAco54
YI3YFySSjeN/h0YFTLwQf0qtaeGkFsruPCi+1R7H+F76Yx7kbikWncGh5BIf4DBselTlZ8XLTA7K
ar/eG3opWTSsQPYrS/1OyOgVIs2T5GboSk8JKAFao2y+asUrw2bKW5tXF4A1EFEzKWx3MGuFA6co
lhETgM1BQ8oBOmwAAAAAAAA=

------=_NextPart_000_0888_01C16EDA.A655EEE0--



From owner-ietf-ldup@mail.imc.org  Sat Nov 17 00:22:08 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05593
	for <ldup-archive@odin.ietf.org>; Sat, 17 Nov 2001 00:22:08 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAH4trk18921
	for ietf-ldup-bks; Fri, 16 Nov 2001 20:55:53 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH4tp818917
	for <ietf-ldup@imc.org>; Fri, 16 Nov 2001 20:55:51 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAH51CC61023;
	Sat, 17 Nov 2001 05:01:13 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116193822.0171a648@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Nov 2001 20:55:26 -0800
To: <john.strassner@intelliden.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: LDAPv4?  (Was: Updating "core" specification)
Cc: "Chris Apple" <imcapple@hotmail.com>, <ietf-ldup@imc.org>
In-Reply-To: <FCEKLEHMPIHFNLCMKHAMOEKJCPAA.john.strassner@intelliden.com
 >
References: <5.1.0.14.0.20011116145125.0172d128@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 07:09 PM 2001-11-16, John Strassner wrote:
>I don't see how this can be a "serious" question. Where in the charter do
>you read anything remotely resembling LDAPv4?

Chris asked the WG to consider an explicit statement regarding
the scope of updates to LDAP "core" specifications.  This could
be taken as allowing updates creating another version of LDAP.
Since I been unable to determine for myself what is beyond the
scope of this working group, I asked this question which I am
pleased was answered in a serious fashion.

>I'm still waiting for an answer to my earlier question about what,
>specifically, you find so confusing about the charter and what,
>specifically, you would reword.

I assume you refer to your previous post
  http://www.imc.org/ietf-ldup/mail-archive/msg01235.html 

I took this as direction, not as a question, as I indicated
in my response:
  http://www.imc.org/ietf-ldup/mail-archive/msg01237.html

Anyways, as I've noted repeatedly in posts regarding this
particular issue, it is the lack of any statement as to what
is beyond the scope which is causing my confusion and concern.
I am trying my best to ask questions, with specific wording
suggestions, to address my confusion and this concern.

>Questions like "what's not in the charter" simply do not help.

Unfornately, it's what not in the charter which I find so
confusing and cause me the greatest concern.  I am trying
to resolve this by asking pointed questions and offering
specific suggestions which, I thought, was what you directed
me to do.

In a separate post you ask:
> How about answering my previous questions first?
> Especially since no where in the charter is this mentioned?

I hope the above answers your questions.  If not, please
post the questions again (or provide me with a reference to
the specific message containing the questions) and I'll try
again.

Also, if I have misinterpret either your or Chris's direction,
please advise.

Kurt



From owner-ietf-ldup@mail.imc.org  Sat Nov 17 03:34:04 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22722
	for <ldup-archive@odin.ietf.org>; Sat, 17 Nov 2001 03:34:03 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAH8Hmr05388
	for ietf-ldup-bks; Sat, 17 Nov 2001 00:17:48 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH8Hk805378
	for <ietf-ldup@imc.org>; Sat, 17 Nov 2001 00:17:46 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAH8N5C61334
	for <ietf-ldup@imc.org>; Sat, 17 Nov 2001 08:23:05 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011116105445.016be430@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 17 Nov 2001 00:17:19 -0800
To: ietf-ldup@imc.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Identity mapping and more
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


While I do not support addition of "new" work, I do concur
that for a access control policy to be evaluated consistency
across multiple replicas that these replicas need to use
common mechanisms and policy for generating those access
control factors which are derived from the LDAP association.
In particular, access control policy commonly acts upon subjects
which are derived from identity the server has associated with
the client.

Some background based upon my particular operational experience
in this area:

Authentication Identity
  The authentication process may or may not be based on
  information held in the directory. The process results
  in some "authentication identity" being associated with
  the user.  It is generally derived from the credential.
  The characteristics of the credential are mechanism
  specific.  In some cases, a credential can be associated
  with multiple identities.

Authorization Identity, no proxy
  The client derives an authorization identity from the
  authentication identity, possibly based upon
  information held in the directory.  If the server
  supports multiple authentication mechanisms, it is
  desirable to map all the authentication identities
  which are associated with the same user to one
  authorization identity.

Authorization Identity, proxy
  The client asserts the desired identity to assume.
  As in the no proxy case, the server need to map
  the authorization identity associated with the
  authentication identity as this generally a factor
  in the proxy authorization policy decision.  The
  desired identity may also need to be mapped into
  an appropriate form needed to make the policy
  decision.  The policy and other information may or
  may not be held in the directory.

Access Control Subject Identities
  The access control system may use as factors identities
  information derived from the authorization identity
  associated with the authentication identity or the
  the authorization identity associated with the assumed
  authorization identity.  I refer this as the subject
  identity namely to imply additional mapping which
  might be involved.

In order to provide consistent mapping of identities
between replicas, the work needs to consider a variety
of identity mappings requirements.  And, obviously,
information supporting the authentication process itself
as well as the mappings needs to be replicated.

Also, note that I only discussed identities above.
There is also other access control factors which
come the authentication/authorization system which
need to be considered.

Solving this problem is a major undertaking.

If this is included as a charter work item, it warrants
specific mention in the description.
   In order to support consistent evaluation of access controls
   across replicas, the working will deliver a specification
   suitable for the Standard Track detailing mechanisms
   supporting consistent authentication/authorization services
   in replicated environments based upon a requirements which
   the WG will document in an Informational RFC.

And what I consider to be ambitious milestones:
   March 2002 Initial Authc/Authz Services Req't I-D submitted
   June  2002 Authc/Authz Services Req't I-D progressed to IESG
              for consideration as Informational
   July  2002 Initial Authc/Authz Services TS I-D submitted
   Dec   2002 Authc/Authz Services TS I-D progressed to IESG
              for consideration as a Proposed Standard

Again, I do not support adding any new work to the LDUP charter.

Kurt



From owner-ietf-ldup@mail.imc.org  Sat Nov 17 09:12:08 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24932
	for <ldup-archive@odin.ietf.org>; Sat, 17 Nov 2001 09:12:08 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAHDpZS05159
	for ietf-ldup-bks; Sat, 17 Nov 2001 05:51:35 -0800 (PST)
Received: from server3.lemurnetworks.net (server3.lemurnetworks.net [66.9.206.243])
	by above.proper.com (8.11.6/8.11.3) with SMTP id fAHDpX805155
	for <ietf-ldup@imc.org>; Sat, 17 Nov 2001 05:51:33 -0800 (PST)
Received: (qmail 31581 invoked by uid 502); 17 Nov 2001 13:43:25 -0000
Date: 17 Nov 2001 13:43:25 -0000
Message-ID: <20011117134325.31580.qmail@server3.lemurnetworks.net>
From: "Ryan Moats" <rmoats@lemurnetworks.net>
To: "Chris Apple" <imcapple@hotmail.com>,
        "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, <ietf-ldup@imc.org>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
References:   <>
In-Reply-To:  <>
X-IPAddress: 204.26.91.223
X-Sender: rmoats@lemurnetworks.net@lemurnetworks.net
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>



On Fri, 16 Nov 2001 19:24:55 -0500, "Chris Apple" <imcapple@hotmail.com>
wrote :

> 
> All editors should respond with their opinions on Kurt's current text
> proposal for clarifying the charter to the WG mailing list ASAP.
> 
> I believe it reflects the strategy that we currently are
> pursuing because of LDAPv3 installed base at the time
> of initial charter creation. However, I want to hear from
> the editors if this language is too constraining based on
> what we know about the problems we still have to solve.
> 
> Chris.

I will quote from my mandatory replica announcement mail
(http://www.imc.org/ietf-ldup/mail-archive/msg01209.html) where
we ask at least 2 points where the core specification may need a
change:

| 1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
| operational attributes as part of this operation? If so, LDAP will need
| a change.
| 
| 2. Section 4.6 currently requires that all replicaSubentries representing
the
| same server have the same entryUUID.  How is this accomplished?

I suspect that as we get deeper into MRM, we will turn up additional
places where the core specification may need changing, so I can't see
the core specification being "immutable".

Ryan




From owner-ietf-ldup@mail.imc.org  Sat Nov 17 09:22:54 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25030
	for <ldup-archive@odin.ietf.org>; Sat, 17 Nov 2001 09:22:54 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAHE3bp05364
	for ietf-ldup-bks; Sat, 17 Nov 2001 06:03:37 -0800 (PST)
Received: from server3.lemurnetworks.net (server3.lemurnetworks.net [66.9.206.243])
	by above.proper.com (8.11.6/8.11.3) with SMTP id fAHE3a805360
	for <ietf-ldup@imc.org>; Sat, 17 Nov 2001 06:03:36 -0800 (PST)
Received: (qmail 32205 invoked by uid 502); 17 Nov 2001 13:55:48 -0000
Date: 17 Nov 2001 13:55:48 -0000
Message-ID: <20011117135548.32204.qmail@server3.lemurnetworks.net>
From: "Ryan Moats" <rmoats@lemurnetworks.net>
To: "Paul Leach" <paulle@windows.microsoft.com>,
        "Richard V Huber" <rvh@qsun.mt.att.com>, <Kurt@OpenLDAP.org>,
        <imcapple@hotmail.com>, <ietf-ldup@imc.org>
Subject: RE: Adding to the LDAP ACM to a WG charter
References:   <>
In-Reply-To:  <>
X-IPAddress: 204.26.91.223
X-Sender: rmoats@lemurnetworks.net@lemurnetworks.net
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>



On Fri, 16 Nov 2001 16:46:18 -0800, "Paul Leach"
<paulle@windows.microsoft.com> wrote :

> > -----Original Message-----
> > From: Richard V Huber [mailto:rvh@qsun.mt.att.com] 
> > 
> > Since LDAPEXT is shutting down, the ACM work needs a new 
> > home.  Since most of the members of LDAPEXT are also part of 
> > LDUP, and since the ACM work is needed for LDUP, LDUP seems 
> > like the right place to do it.
> > 
> > Access control is a complicated topic.  I think it needs the 
> > benefit of the technical review a WG will provide.
> 
> The last paragraph at most argues for _some_ WG, but not necessarily
> this one.

This begs the question "does LDUP need an ACM?"

Now I think so, because I see that without an ACM, most of the useful (to
me)
LDUP topic are gutted.

I should think that folks who are saying that LDUP should not take on ACM
should
be providing at least some thought on what LDUP can accomplish without it.

> As Kurt has noted, the previous paragraph says that the same gang who
> couldn't get an ACM done in LDAPEXT are just as likely to not get it
> done in LDUP, and in the meantime, the focus on replication is vitiated.

Ok, as a thought experiment, let's posit a new "ldapacm" wg.  Why wouldn't
this
group have the same players?  Why wouldn't it have the same problems?
I would think creating a new wg would just create more overhead and further
slow
LDUP because it would need to wait for this other WG.

Ryan



From owner-ietf-ldup@mail.imc.org  Sat Nov 17 13:00:49 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28114
	for <ldup-archive@odin.ietf.org>; Sat, 17 Nov 2001 13:00:49 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAHHf3i18011
	for ietf-ldup-bks; Sat, 17 Nov 2001 09:41:03 -0800 (PST)
Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAHHf1818004
	for <ietf-ldup@imc.org>; Sat, 17 Nov 2001 09:41:01 -0800 (PST)
Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137])
	by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA13360;
	Sat, 17 Nov 2001 11:42:02 -0600
Received: from estokes.austin.ibm.com (sig-9-15-51-41.mts.ibm.com [9.15.51.41])
	by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA41510;
	Sat, 17 Nov 2001 11:40:59 -0600
Message-Id: <5.0.2.1.0.20011117113250.00a6a1a0@popmail2.austin.ibm.com>
X-Sender: stokes@popmail2.austin.ibm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sat, 17 Nov 2001 11:40:58 -0600
To: imcapple@hotmail.com, john.strassner@intelliden.com, ietf-ldup@imc.org
From: Ellen Stokes <stokes@austin.ibm.com>
Subject: RE: Adding to the LDAP ACM to a WG charter
In-Reply-To: <20011117135548.32204.qmail@server3.lemurnetworks.net>
References: <>
 <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Security is important for a replicated environment.

For the secure replicated heterogeneous environment to work, an
access control model is necessary.

Since this work cannot be finished in LDUP (ldapext is shutting
down), the access control model needs a home.

And given the complexity of the topic, it is insufficient to just
release the spec as informational, experimental, or as an
individual publication.

I am FOR adding access control model to LDUP.

Ellen



From owner-ietf-ldup@mail.imc.org  Sun Nov 18 19:28:47 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00214
	for <ldup-archive@lists.ietf.org>; Sun, 18 Nov 2001 19:28:47 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJ08J327825
	for ietf-ldup-bks; Sun, 18 Nov 2001 16:08:19 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged))
	by above.proper.com (8.11.6/8.11.3) with SMTP id fAJ08C827814
	for <ietf-ldup@imc.org>; Sun, 18 Nov 2001 16:08:13 -0800 (PST)
Received: (qmail 12252 invoked from network); 18 Nov 2001 23:58:55 -0000
Received: from unknown (HELO osmium) (10.32.24.165)
  by nexus.adacel.com with SMTP; 18 Nov 2001 23:58:55 -0000
Reply-To: <steven.legg@adacel.com.au>
From: "Steven Legg" <steven.legg@adacel.com.au>
To: "'Ryan Moats'" <rmoats@lemurnetworks.net>
Cc: <ietf-ldup@imc.org>
Subject: RE: Adding to the LDAP ACM to a WG charter
Date: Mon, 19 Nov 2001 11:02:30 +1100
Message-ID: <000001c1708d$7bfe7d60$a518200a@osmium.mtwav.adacel.com.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 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <20011117135548.32204.qmail@server3.lemurnetworks.net>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Ryan Moats wrote:
> On Fri, 16 Nov 2001 16:46:18 -0800, "Paul Leach"
> <paulle@windows.microsoft.com> wrote :
> 
> > > -----Original Message-----
> > > From: Richard V Huber [mailto:rvh@qsun.mt.att.com] 
> > > 
> > > Since LDAPEXT is shutting down, the ACM work needs a new 
> > > home.  Since most of the members of LDAPEXT are also part of 
> > > LDUP, and since the ACM work is needed for LDUP, LDUP seems 
> > > like the right place to do it.
> > > 
> > > Access control is a complicated topic.  I think it needs the 
> > > benefit of the technical review a WG will provide.
> > 
> > The last paragraph at most argues for _some_ WG, but not necessarily
> > this one.
> 
> This begs the question "does LDUP need an ACM?"

No. While it is true that replicating a secure environment requires that
the participating servers have the ability to support a common ACM, the
LDUP architecture, protocol, URP, etc have no dependence on the actual
details of the ACM(s) being used. We can complete the LDUP work without
defining an ACM. Deployment is a separate issue.

> 
> Now I think so, because I see that without an ACM, most of 
> the useful (to
> me)
> LDUP topic are gutted.
> 
> I should think that folks who are saying that LDUP should not 
> take on ACM
> should
> be providing at least some thought on what LDUP can 
> accomplish without it.

I observe that X.500 vendors already have a common access control model
that can be replicated through DISP. It would be replicated equally well
through LDUP.

> 
> > As Kurt has noted, the previous paragraph says that the 
> same gang who
> > couldn't get an ACM done in LDAPEXT are just as likely to not get it
> > done in LDUP, and in the meantime, the focus on replication 
> is vitiated.
> 
> Ok, as a thought experiment, let's posit a new "ldapacm" wg.  
> Why wouldn't
> this
> group have the same players?  Why wouldn't it have the same problems?

It would have the same problems, but at least they wouldn't belong to
the LDUP working group.

> I would think creating a new wg would just create more 
> overhead and further
> slow
> LDUP because it would need to wait for this other WG.

LDUP wouldn't need to wait for this other WG, the details of the ACM
don't matter to the LDUP specifications.

I don't think the ACM should be added to LDUP charter. The LDUP
specifications don't need it and the LDUP WG can do without the
distraction.

Regards,
Steven



From owner-ietf-ldup@mail.imc.org  Mon Nov 19 06:19:21 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25336
	for <ldup-archive@lists.ietf.org>; Mon, 19 Nov 2001 06:19:21 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJB01P11760
	for ietf-ldup-bks; Mon, 19 Nov 2001 03:00:01 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJAxx811745
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 02:59:59 -0800 (PST)
Received: from sunfra.France.Sun.COM ([129.157.188.1])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17929;
	Mon, 19 Nov 2001 02:59:57 -0800 (PST)
Received: from hamble.France.Sun.COM (hamble.France.Sun.COM [129.157.192.53])
	by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id LAA11385;
	Mon, 19 Nov 2001 11:59:56 +0100 (MET)
Received: from sun.com (localhost [127.0.0.1])
	by hamble.France.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10825;
	Mon, 19 Nov 2001 11:57:42 +0100 (MET)
Message-ID: <3BF8E5A6.3757FFDC@sun.com>
Date: Mon, 19 Nov 2001 11:57:42 +0100
From: Rob Byrne - Sun Microsystems <robert.byrne@Sun.COM>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
CC: ietf-ldup@imc.org
Subject: Re: Identity mapping and more
References: <5.1.0.14.0.20011116105445.016be430@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Kurt,

Just a note to say that I agreee that standardizing these mappings would
be very useful.  So much so that I think it would be useful even without
the ACM or replication considerations.

Rob.

"Kurt D. Zeilenga" wrote:

> While I do not support addition of "new" work, I do concur
> that for a access control policy to be evaluated consistency
> across multiple replicas that these replicas need to use
> common mechanisms and policy for generating those access
> control factors which are derived from the LDAP association.
> In particular, access control policy commonly acts upon subjects
> which are derived from identity the server has associated with
> the client.
>
> Some background based upon my particular operational experience
> in this area:
>
> Authentication Identity
>   The authentication process may or may not be based on
>   information held in the directory. The process results
>   in some "authentication identity" being associated with
>   the user.  It is generally derived from the credential.
>   The characteristics of the credential are mechanism
>   specific.  In some cases, a credential can be associated
>   with multiple identities.
>
> Authorization Identity, no proxy
>   The client derives an authorization identity from the
>   authentication identity, possibly based upon
>   information held in the directory.  If the server
>   supports multiple authentication mechanisms, it is
>   desirable to map all the authentication identities
>   which are associated with the same user to one
>   authorization identity.
>
> Authorization Identity, proxy
>   The client asserts the desired identity to assume.
>   As in the no proxy case, the server need to map
>   the authorization identity associated with the
>   authentication identity as this generally a factor
>   in the proxy authorization policy decision.  The
>   desired identity may also need to be mapped into
>   an appropriate form needed to make the policy
>   decision.  The policy and other information may or
>   may not be held in the directory.
>
> Access Control Subject Identities
>   The access control system may use as factors identities
>   information derived from the authorization identity
>   associated with the authentication identity or the
>   the authorization identity associated with the assumed
>   authorization identity.  I refer this as the subject
>   identity namely to imply additional mapping which
>   might be involved.
>
> In order to provide consistent mapping of identities
> between replicas, the work needs to consider a variety
> of identity mappings requirements.  And, obviously,
> information supporting the authentication process itself
> as well as the mappings needs to be replicated.
>
> Also, note that I only discussed identities above.
> There is also other access control factors which
> come the authentication/authorization system which
> need to be considered.
>
> Solving this problem is a major undertaking.
>
> If this is included as a charter work item, it warrants
> specific mention in the description.
>    In order to support consistent evaluation of access controls
>    across replicas, the working will deliver a specification
>    suitable for the Standard Track detailing mechanisms
>    supporting consistent authentication/authorization services
>    in replicated environments based upon a requirements which
>    the WG will document in an Informational RFC.
>
> And what I consider to be ambitious milestones:
>    March 2002 Initial Authc/Authz Services Req't I-D submitted
>    June  2002 Authc/Authz Services Req't I-D progressed to IESG
>               for consideration as Informational
>    July  2002 Initial Authc/Authz Services TS I-D submitted
>    Dec   2002 Authc/Authz Services TS I-D progressed to IESG
>               for consideration as a Proposed Standard
>
> Again, I do not support adding any new work to the LDUP charter.
>
> Kurt



From owner-ietf-ldup@mail.imc.org  Mon Nov 19 10:05:40 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03051
	for <ldup-archive@lists.ietf.org>; Mon, 19 Nov 2001 10:05:40 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJEej527501
	for ietf-ldup-bks; Mon, 19 Nov 2001 06:40:45 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJEeh827497
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 06:40:43 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA116446
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 09:37:56 -0500
Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAJEeXf109488
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 09:40:33 -0500
To: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>
MIME-Version: 1.0
Subject: Re: revised WG charter proposal
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
From: "Timothy Hahn" <hahnt@us.ibm.com>
Message-ID: <OF88295160.92F23401-ON85256B09.004F04A2@pok.ibm.com>
Date: Mon, 19 Nov 2001 09:40:32 -0500
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V509_11082001.dev00 |November
 14, 2001) at 11/19/2001 09:40:34 AM,
	Serialize complete at 11/19/2001 09:40:34 AM
Content-Type: multipart/alternative; boundary="=_alternative 0050226285256B09_="
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0050226285256B09_=
Content-Type: text/plain; charset="us-ascii"

Hello,

Excerpt from Proposed WG charter:

o LDAPv3 Access Control Issues

   Replication using heterogeneous LDAPv3 servers is dependent on
   resolving LDAPv3 access control issues, which are currently in
   the domain of another Applications Area working group. RFC 2820,
   Access Control Requirements for LDAP, was produced by that working
   group. However, this working group has elected to close prior to
   establishing consensus on other documents, such as an Access Control
   Model specification for LDAPv3. Such documents are necessary for
   LDUP to meet certain replication requirements documented by the
   LDUP WG. Thus, the remaining access control work and the latest
   revision of the access control model Internet Draft produced by
   the originating working group as starting point for continuing
   the work in the LDUP WG.

My opinion on whether the workgroup should solve the access control model 
specification is as follows:

a) in order for replication to take place and ensure that data replicated 
in two different server instances is not accessed inappropriately in 
either one of the server instances, the replication model MUST rely on 
some statement about access control.  I would expect that these statements 
would be covered in the "Security Considerations" section of the drafts 
and RFCs (among other places).
b) the past attempts by LDAPext to establish consensus around any 
particular access control model have not been successful.  Progress has 
been made, to be sure, but in my opinion, we are not yet near a "final 
solution" with consensus.
c) I do not believe that LDUP requires a FULL access control model 
specification in order to proceed with a "secure" solution.  By this, I 
believe that the two problems ARE factorable.
d) There are elements of the current access control model specification 
that could help us "factor" the problems - namely the notion in the 
current ACM model that each ACI is defined by some OID and the particular 
ACI(s) that a server supports/uses is held in the root DSE.

I feel that the LDUP WG SHOULD pursue a specification of how access 
control "frameworks" are published (without specifying/defining any 
particular access control model design).  This allows for two (or n) 
servers to establish what access control models are defined/implemented on 
any particular server and for those servers to figure out IF they can 
"agree" on a ACI model to use.

With this "framework" agreed upon, LDUP can state in its "security 
considerations" that for secure environments, replicating servers MUST 
implement and use "compatible" ACI models - but LDUP need NOT define any 
particular model be employed.  I believe that this allows the access 
control to be "factored" from the replication problem.

In summary, I feel that LDUP should NOT take on the "whole" access control 
problem (as is attempted in the current ACM draft from the LDAPext working 
group).  Rather, LDUP should take on work to define a "framework" in which 
different ACI models can be defined and published, and then LDUP should 
state that "compatible" access control models MUST be used for secure 
replication.

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

--=_alternative 0050226285256B09_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2 face="sans-serif">Excerpt from Proposed WG charter:</font>
<br>
<br><font size=2 face="Courier New">o LDAPv3 Access Control Issues<br>
<br>
 &nbsp; Replication using heterogeneous LDAPv3 servers is dependent on<br>
 &nbsp; resolving LDAPv3 access control issues, which are currently in<br>
 &nbsp; the domain of another Applications Area working group. RFC 2820,<br>
 &nbsp; Access Control Requirements for LDAP, was produced by that working<br>
 &nbsp; group. However, this working group has elected to close prior to<br>
 &nbsp; establishing consensus on other documents, such as an Access Control<br>
 &nbsp; Model specification for LDAPv3. Such documents are necessary for<br>
 &nbsp; LDUP to meet certain replication requirements documented by the<br>
 &nbsp; LDUP WG. Thus, the remaining access control work and the latest<br>
 &nbsp; revision of the access control model Internet Draft produced by<br>
 &nbsp; the originating working group as starting point for continuing<br>
 &nbsp; the work in the LDUP WG.</font><font size=2 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif">My opinion on whether the workgroup should solve the access control model specification is as follows:</font>
<br>
<br><font size=2 face="sans-serif">a) in order for replication to take place and ensure that data replicated in two different server instances is not accessed inappropriately in either one of the server instances, the replication model MUST rely on some statement about access control. &nbsp;I would expect that these statements would be covered in the &quot;Security Considerations&quot; section of the drafts and RFCs (among other places).</font>
<br><font size=2 face="sans-serif">b) the past attempts by LDAPext to establish consensus around any particular access control model have not been successful. &nbsp;Progress has been made, to be sure, but in my opinion, we are not yet near a &quot;final solution&quot; with consensus.</font>
<br><font size=2 face="sans-serif">c) I do not believe that LDUP requires a FULL access control model specification in order to proceed with a &quot;secure&quot; solution. &nbsp;By this, I believe that the two problems ARE factorable.</font>
<br><font size=2 face="sans-serif">d) There are elements of the current access control model specification that could help us &quot;factor&quot; the problems - namely the notion in the current ACM model that each ACI is defined by some OID and the particular ACI(s) that a server supports/uses is held in the root DSE.</font>
<br>
<br><font size=2 face="sans-serif">I feel that the LDUP WG SHOULD pursue a specification of how access control &quot;frameworks&quot; are published (without specifying/defining any particular access control model design). &nbsp;This allows for two (or n) servers to establish what access control models are defined/implemented on any particular server and for those servers to figure out IF they can &quot;agree&quot; on a ACI model to use.</font>
<br>
<br><font size=2 face="sans-serif">With this &quot;framework&quot; agreed upon, LDUP can state in its &quot;security considerations&quot; that for secure environments, replicating servers MUST implement and use &quot;compatible&quot; ACI models - but LDUP need NOT define any particular model be employed. &nbsp;I believe that this allows the access control to be &quot;factored&quot; from the replication problem.</font>
<br>
<br><font size=2 face="sans-serif">In summary, I feel that LDUP should NOT take on the &quot;whole&quot; access control problem (as is attempted in the current ACM draft from the LDAPext working group). &nbsp;Rather, LDUP should take on work to define a &quot;framework&quot; in which different ACI models can be defined and published, and then LDUP should state that &quot;compatible&quot; access control models MUST be used for secure replication.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Tim Hahn<br>
<br>
Internet: hahnt@us.ibm.com<br>
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<br>
phone: 607.752.6388 &nbsp; &nbsp; tie-line: 8/852.6388<br>
fax: 607.752.3681<br>
</font>
--=_alternative 0050226285256B09_=--


From owner-ietf-ldup@mail.imc.org  Mon Nov 19 11:47:56 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08960
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 11:47:55 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJGOgU05741
	for ietf-ldup-bks; Mon, 19 Nov 2001 08:24:42 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJGOd805737
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 08:24:39 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Mon, 19 Nov 2001 11:17:46 -0700
Message-Id: <sbf8ea5a.009@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 19 Nov 2001 11:17:25 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <stokes@austin.ibm.com>, <imcapple@hotmail.com>, <ietf-ldup@imc.org>,
        <john.strassner@intelliden.com>
Subject: RE: Adding to the LDAP ACM to a WG charter
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 above.proper.com id fAJGOd805738
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


I didn't quite follow that, Ellen - "since this work cannot be finished
in LDUP (ldapext is shutting down)" seems like a non-sequitor.  Did
you mean it can't be done in LDAPEXT?

I come down in favor of a separate working group to hash out
the end-all-and-be-all Access Control Model, or even an appropriate
subset.  

In addition to the list of issues that Kurt raised, I'll point
out that the X.500 model also includes provisions for Rule Based
Access Control, which takes determination of appropriate 
security clearances, roles, etc. to be more important than the
actual identity of the security principal, which is a particularly
important manner of access control among very large, independently
administered heterogeneous communities like the Internet.

The X.500 work was, I think, done to address data handling
constraints associated with the US DOD Defence Messaging System
design, which is not getting much press today.

However, the notion that interoperability between companies
should follow a model that allows data administrators in the directory
to set classification of data that requires role and clearance
information to be authoritatively provided, without necessarily
having any knowledge at all about the actual identity of the
principal (anonymous, but trusted, vs anonymous and untrusted)
is very attractive.

Kurt's list of Authentication issues to discuss, together with the
X.500 notion of Rule Based Authorization and the current market
craze in favor of Role Based Authentication (where the ACI
refers to a role, not an individual, and it's the job of the
authentication service to provide information about the roles
and clearance of the principal to relying services like the directory)
should NOT be dealt with in LDUP, but rather a separate
LDAPACM working group.

The (proposed new) LDAPACM working group should work diligently
to (a) not break LDAP, (b) store its policy and principal information
in the Directory so that LDUP will replicate it, and detail as much
as possible what special provisions, if any, are needed in LDUP to
preserve the integrity of the ACM information.  For instance, 
it might very well be a requirement that ACM information
be sent by state-based replication schemes in LDUP BEFORE any
of the data elements to which it applies is sent.

I vote in favor of NOT doing LDAPACM in LDUP, but rather
leaving LDUP to the task of shipping directory information around
"safely", while leaving LDAPACM the opportunity to place
SOME requirements on LDUP when those requirements are fully 
known.

LDUP is useful (as was LDAPv2 and LDAPv3) even if it does not provide
a complete, seamless, end-to-end, multi-vendor environment with
a perfectly consistent management and security policy implementation.

Lets get on with discovering what some of those uses are.

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> Ellen Stokes <stokes@austin.ibm.com> 11/17/01 12:40PM >>>

Security is important for a replicated environment.

For the secure replicated heterogeneous environment to work, an
access control model is necessary.

Since this work cannot be finished in LDUP (ldapext is shutting
down), the access control model needs a home.

And given the complexity of the topic, it is insufficient to just
release the spec as informational, experimental, or as an
individual publication.

I am FOR adding access control model to LDUP.

Ellen




From owner-ietf-ldup@mail.imc.org  Mon Nov 19 12:47:50 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12304
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 12:47:49 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJHKFH10644
	for ietf-ldup-bks; Mon, 19 Nov 2001 09:20:15 -0800 (PST)
Received: from pimout3-int.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJHKE810638
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 09:20:14 -0800 (PST)
Received: from noeticwork (adsl-63-194-210-36.dsl.snfc21.pacbell.net [63.194.210.36])
	by pimout3-int.prodigy.net (8.11.0/8.11.0) with SMTP id fAJHKEw249546;
	Mon, 19 Nov 2001 12:20:14 -0500
Message-ID: <009801c1711e$7ae28e30$0163a8c0@noetic.net>
From: "Ed Owens" <edowens@ix.netcom.com>
To: "Ietf-Ldup@Imc. Org" <ietf-ldup@imc.org>,
        "Timothy Hahn" <hahnt@us.ibm.com>
References: <OF88295160.92F23401-ON85256B09.004F04A2@pok.ibm.com>
Subject: Re: revised WG charter proposal
Date: Mon, 19 Nov 2001 09:20:13 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0093_01C170DB.64B7CB40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0093_01C170DB.64B7CB40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tim,
    Thank you for your "factoring" discussion.  While I am opposed to =
bringing all of the ACM work into the LDUP working group I believe that =
your suggestion, including sufficient information for publishing access =
control frameworks but not defining any particular model, is a good =
compromise that allows LDUP to have some chance of completion without =
getting bogged down in the seemingly interminable discussion around =
access control.  I would support changes to the LDUP charter that =
specified this task.  What I cannot support is the current wording of =
the charter which moves all of the access control discussion into the =
LDUP WG which I maintain (with others) will only slow to a crawl any =
meaningful work on the original goals of LDAP replication.

        Ed Owens

Edward Owens
Principal Consultant
Noetic Solutions LLC
(925)366-1005
eowens@sbcglobal.net
http://www.noetic.net
  ----- Original Message -----=20
  From: Timothy Hahn=20
  To: Ietf-Ldup@Imc. Org=20
  Sent: Monday, November 19, 2001 6:40 AM
  Subject: Re: revised WG charter proposal



  Hello,=20

  Excerpt from Proposed WG charter:=20

  o LDAPv3 Access Control Issues

    Replication using heterogeneous LDAPv3 servers is dependent on
    resolving LDAPv3 access control issues, which are currently in
    the domain of another Applications Area working group. RFC 2820,
    Access Control Requirements for LDAP, was produced by that working
    group. However, this working group has elected to close prior to
    establishing consensus on other documents, such as an Access Control
    Model specification for LDAPv3. Such documents are necessary for
    LDUP to meet certain replication requirements documented by the
    LDUP WG. Thus, the remaining access control work and the latest
    revision of the access control model Internet Draft produced by
    the originating working group as starting point for continuing
    the work in the LDUP WG.

  My opinion on whether the workgroup should solve the access control =
model specification is as follows:=20

  a) in order for replication to take place and ensure that data =
replicated in two different server instances is not accessed =
inappropriately in either one of the server instances, the replication =
model MUST rely on some statement about access control.  I would expect =
that these statements would be covered in the "Security Considerations" =
section of the drafts and RFCs (among other places).=20
  b) the past attempts by LDAPext to establish consensus around any =
particular access control model have not been successful.  Progress has =
been made, to be sure, but in my opinion, we are not yet near a "final =
solution" with consensus.=20
  c) I do not believe that LDUP requires a FULL access control model =
specification in order to proceed with a "secure" solution.  By this, I =
believe that the two problems ARE factorable.=20
  d) There are elements of the current access control model =
specification that could help us "factor" the problems - namely the =
notion in the current ACM model that each ACI is defined by some OID and =
the particular ACI(s) that a server supports/uses is held in the root =
DSE.=20

  I feel that the LDUP WG SHOULD pursue a specification of how access =
control "frameworks" are published (without specifying/defining any =
particular access control model design).  This allows for two (or n) =
servers to establish what access control models are defined/implemented =
on any particular server and for those servers to figure out IF they can =
"agree" on a ACI model to use.=20

  With this "framework" agreed upon, LDUP can state in its "security =
considerations" that for secure environments, replicating servers MUST =
implement and use "compatible" ACI models - but LDUP need NOT define any =
particular model be employed.  I believe that this allows the access =
control to be "factored" from the replication problem.=20

  In summary, I feel that LDUP should NOT take on the "whole" access =
control problem (as is attempted in the current ACM draft from the =
LDAPext working group).  Rather, LDUP should take on work to define a =
"framework" in which different ACI models can be defined and published, =
and then LDUP should state that "compatible" access control models MUST =
be used for secure replication.=20

  Regards,
  Tim Hahn

  Internet: hahnt@us.ibm.com
  Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
  phone: 607.752.6388     tie-line: 8/852.6388
  fax: 607.752.3681


------=_NextPart_000_0093_01C170DB.64B7CB40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Tim,</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Thank you for your "factoring"=20
discussion.&nbsp; While I am opposed to bringing all of the ACM work =
into the=20
LDUP working group I believe that your suggestion, including sufficient=20
information for publishing access control frameworks but not defining =
any=20
particular model, is a good compromise that allows LDUP to have some =
chance of=20
completion without getting bogged down in the&nbsp;seemingly =
interminable=20
discussion around access control.&nbsp; I would support changes to the =
LDUP=20
charter that specified this task.&nbsp; What I cannot support is the =
current=20
wording of the charter which moves all of the access control discussion =
into the=20
LDUP WG which I maintain (with others) will only slow to a crawl any =
meaningful=20
work on the original goals of LDAP replication.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed =
Owens</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Edward Owens<BR>Principal Consultant<BR>Noetic =
Solutions=20
LLC<BR>(925)366-1005<BR><A=20
href=3D"mailto:eowens@sbcglobal.net">eowens@sbcglobal.net</A><BR><A=20
href=3D"http://www.noetic.net">http://www.noetic.net</A></FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dhahnt@us.ibm.com href=3D"mailto:hahnt@us.ibm.com">Timothy =
Hahn</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dietf-ldup@imc.org=20
  href=3D"mailto:Ietf-Ldup@Imc. Org">Ietf-Ldup@Imc. Org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 19, 2001 =
6:40=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: revised WG charter =

  proposal</DIV>
  <DIV><BR></DIV><BR><FONT face=3Dsans-serif size=3D2>Hello,</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D2>Excerpt from Proposed WG charter:</FONT> =
<BR><BR><FONT=20
  face=3D"Courier New" size=3D2>o LDAPv3 Access Control =
Issues<BR><BR>&nbsp;=20
  Replication using heterogeneous LDAPv3 servers is dependent =
on<BR>&nbsp;=20
  resolving LDAPv3 access control issues, which are currently =
in<BR>&nbsp; the=20
  domain of another Applications Area working group. RFC 2820,<BR>&nbsp; =
Access=20
  Control Requirements for LDAP, was produced by that working<BR>&nbsp; =
group.=20
  However, this working group has elected to close prior to<BR>&nbsp;=20
  establishing consensus on other documents, such as an Access =
Control<BR>&nbsp;=20
  Model specification for LDAPv3. Such documents are necessary =
for<BR>&nbsp;=20
  LDUP to meet certain replication requirements documented by =
the<BR>&nbsp; LDUP=20
  WG. Thus, the remaining access control work and the latest<BR>&nbsp; =
revision=20
  of the access control model Internet Draft produced by<BR>&nbsp; the=20
  originating working group as starting point for continuing<BR>&nbsp; =
the work=20
  in the LDUP WG.</FONT><FONT face=3Dsans-serif =
size=3D2><BR></FONT><BR><FONT=20
  face=3Dsans-serif size=3D2>My opinion on whether the workgroup should =
solve the=20
  access control model specification is as follows:</FONT> <BR><BR><FONT =

  face=3Dsans-serif size=3D2>a) in order for replication to take place =
and ensure=20
  that data replicated in two different server instances is not accessed =

  inappropriately in either one of the server instances, the replication =
model=20
  MUST rely on some statement about access control. &nbsp;I would expect =
that=20
  these statements would be covered in the "Security Considerations" =
section of=20
  the drafts and RFCs (among other places).</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>b) the past attempts by LDAPext to establish consensus around =
any=20
  particular access control model have not been successful. =
&nbsp;Progress has=20
  been made, to be sure, but in my opinion, we are not yet near a "final =

  solution" with consensus.</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>c) I do not=20
  believe that LDUP requires a FULL access control model specification =
in order=20
  to proceed with a "secure" solution. &nbsp;By this, I believe that the =
two=20
  problems ARE factorable.</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>d) There are=20
  elements of the current access control model specification that could =
help us=20
  "factor" the problems - namely the notion in the current ACM model =
that each=20
  ACI is defined by some OID and the particular ACI(s) that a server=20
  supports/uses is held in the root DSE.</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>I feel that the LDUP WG SHOULD pursue a specification of how =
access=20
  control "frameworks" are published (without specifying/defining any =
particular=20
  access control model design). &nbsp;This allows for two (or n) servers =
to=20
  establish what access control models are defined/implemented on any =
particular=20
  server and for those servers to figure out IF they can "agree" on a =
ACI model=20
  to use.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>With this =
"framework"=20
  agreed upon, LDUP can state in its "security considerations" that for =
secure=20
  environments, replicating servers MUST implement and use "compatible" =
ACI=20
  models - but LDUP need NOT define any particular model be employed. =
&nbsp;I=20
  believe that this allows the access control to be "factored" from the=20
  replication problem.</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>In summary, I=20
  feel that LDUP should NOT take on the "whole" access control problem =
(as is=20
  attempted in the current ACM draft from the LDAPext working group).=20
  &nbsp;Rather, LDUP should take on work to define a "framework" in =
which=20
  different ACI models can be defined and published, and then LDUP =
should state=20
  that "compatible" access control models MUST be used for secure=20
  replication.</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>Regards,<BR>Tim=20
  Hahn<BR><BR>Internet: hahnt@us.ibm.com<BR>Internal: Timothy=20
  Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<BR>phone: 607.752.6388 =
&nbsp;=20
  &nbsp; tie-line: 8/852.6388<BR>fax:=20
607.752.3681<BR></BLOCKQUOTE></FONT></BODY></HTML>

------=_NextPart_000_0093_01C170DB.64B7CB40--



From owner-ietf-ldup@mail.imc.org  Mon Nov 19 14:46:30 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20304
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 14:46:29 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJJRSL18233
	for ietf-ldup-bks; Mon, 19 Nov 2001 11:27:28 -0800 (PST)
Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJJRQ818228
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 11:27:26 -0800 (PST)
Received: (from jayhawk@localhost)
	by tconl91223.tconl.com (8.11.0/8.11.0) id fAJJPI001920;
	Mon, 19 Nov 2001 13:25:18 -0600
Date: Mon, 19 Nov 2001 13:25:18 -0600
From: Ryan Moats <rmoats@lemurnetworks.net>
To: Steven Legg <steven.legg@adacel.com.au>
Cc: ietf-ldup@imc.org
Subject: Re: Adding to the LDAP ACM to a WG charter
Message-ID: <20011119132518.G1128@privateer.local.windrose.omaha.ne.us>
References: <20011117135548.32204.qmail@server3.lemurnetworks.net> <000001c1708d$7bfe7d60$a518200a@osmium.mtwav.adacel.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <000001c1708d$7bfe7d60$a518200a@osmium.mtwav.adacel.com.au>; from steven.legg@adacel.com.au on Mon, Nov 19, 2001 at 11:02:30AM +1100
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


On Mon, Nov 19, 2001 at 11:02:30AM +1100, Steven Legg wrote:
| 
| Ryan Moats wrote:
| > On Fri, 16 Nov 2001 16:46:18 -0800, "Paul Leach"
| > <paulle@windows.microsoft.com> wrote :
| > 
| > > > -----Original Message-----
| > > > From: Richard V Huber [mailto:rvh@qsun.mt.att.com] 
| > > > 
| > > > Since LDAPEXT is shutting down, the ACM work needs a new 
| > > > home.  Since most of the members of LDAPEXT are also part of 
| > > > LDUP, and since the ACM work is needed for LDUP, LDUP seems 
| > > > like the right place to do it.
| > > > 
| > > > Access control is a complicated topic.  I think it needs the 
| > > > benefit of the technical review a WG will provide.
| > > 
| > > The last paragraph at most argues for _some_ WG, but not necessarily
| > > this one.
| > 
| > This begs the question "does LDUP need an ACM?"
| 
| No. While it is true that replicating a secure environment requires that
| the participating servers have the ability to support a common ACM, the
| LDUP architecture, protocol, URP, etc have no dependence on the actual
| details of the ACM(s) being used. We can complete the LDUP work without
| defining an ACM. Deployment is a separate issue.

Pardon? I thought the idea of LDUP was a standard that would lead to
interoperability.  I don't see how this is possible if deployment is
ignored.

Ryan


From owner-ietf-ldup@mail.imc.org  Mon Nov 19 16:37:53 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27153
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 16:37:53 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJLJbu23441
	for ietf-ldup-bks; Mon, 19 Nov 2001 13:19:37 -0800 (PST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLJZ823435
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 13:19:35 -0800 (PST)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 19 Nov 2001 13:19:08 -0800
Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Nov 2001 13:19:07 -0800
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 19 Nov 2001 13:19:07 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 19 Nov 2001 13:19:07 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Mon, 19 Nov 2001 13:18:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Adding to the LDAP ACM to a WG charter
Date: Mon, 19 Nov 2001 13:18:26 -0800
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD02A879AB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Adding to the LDAP ACM to a WG charter
thread-index: AcFxMMm8VpxOqN8IQ6SkFCyBtBdXEwAAEbAg
From: "Paul Leach" <paulle@windows.microsoft.com>
To: "Ryan Moats" <rmoats@lemurnetworks.net>,
        "Steven Legg" <steven.legg@adacel.com.au>
Cc: <ietf-ldup@imc.org>
X-OriginalArrivalTime: 19 Nov 2001 21:18:27.0060 (UTC) FILETIME=[BA99BB40:01C1713F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAJLJa823436
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit




> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net] 
> Sent: Monday, November 19, 2001 11:25 AM
> To: Steven Legg

> Pardon? I thought the idea of LDUP was a standard that would 
> lead to interoperability.  I don't see how this is possible 
> if deployment is ignored.

I believe that a quite useful replicated directory could be deployed
with limited security functionality until an ACM standard is completed. 

How, you ask? As someone else noted, the access policy could be kept in
synch out of band. In practice, that would mean access policy would have
to be simple, and change infrequently. A very useful, and quite
depoyable, policy that meets that requirement is one that allows
everyone read, and one person or group update, to the contents of the
whole server (or whole naming contexts within the server, if you want to
get slightly more complex).

Paul



From owner-ietf-ldup@mail.imc.org  Mon Nov 19 17:31:34 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00368
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 17:31:34 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAJMEdv26537
	for ietf-ldup-bks; Mon, 19 Nov 2001 14:14:39 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMEc826531
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 14:14:38 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Mon, 19 Nov 2001 17:07:50 -0700
Message-Id: <sbf93c66.037@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 19 Nov 2001 17:07:31 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <imcapple@hotmail.com>, <ietf-ldup@imc.org>, <rmoats@lemurnetworks.net>,
        <Kurt@OpenLDAP.org>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
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 above.proper.com id fAJMEc826533
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


Ryan -

w/r/t your item 2, below, I've assumed that (1) the entryUUID "thing"
was something that LDUP adds as an expectation of LDAP servers
supporting LDUP, and you could consider that an extension to the
core specifications, and (2) that management operations would
require and extended operation or control to assert the entryUUID
for an entry being created (like the replicaSubentry and 
replicationAgreementSubentry by a privileged operation).  This
control would invoke logic similar to that used by the server to receive
entries, including their entryUUID attributes, for creation on a replica
from LDUP.

As for 1, I'm unclear - do you mean a need to be able to scan or search
the directory for all operational attributes?  Surely LDUP needs to be
able to scan the local repository for data elements that need to be
replicated (in the case of a state-base replica scheme, at least), and
certainly a management application console might make good use of
such a thing.  But I don't guess I see that as a fundamental change
to the LDAP data model, as much as a desired behavior in servers
supporting LDUP.

I'll comment on Kurt's text separately.

Ed



=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Ryan Moats" <rmoats@lemurnetworks.net> 11/17/01 08:43AM >>>


On Fri, 16 Nov 2001 19:24:55 -0500, "Chris Apple" <imcapple@hotmail.com>
wrote :

> 
> All editors should respond with their opinions on Kurt's current text
> proposal for clarifying the charter to the WG mailing list ASAP.
> 
> I believe it reflects the strategy that we currently are
> pursuing because of LDAPv3 installed base at the time
> of initial charter creation. However, I want to hear from
> the editors if this language is too constraining based on
> what we know about the problems we still have to solve.
> 
> Chris.

I will quote from my mandatory replica announcement mail
(http://www.imc.org/ietf-ldup/mail-archive/msg01209.html) where
we ask at least 2 points where the core specification may need a
change:

| 1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
| operational attributes as part of this operation? If so, LDAP will need
| a change.
| 
| 2. Section 4.6 currently requires that all replicaSubentries representing
the
| same server have the same entryUUID.  How is this accomplished?

I suspect that as we get deeper into MRM, we will turn up additional
places where the core specification may need changing, so I can't see
the core specification being "immutable".

Ryan





From owner-ietf-ldup@mail.imc.org  Mon Nov 19 17:45:59 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01454
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 17:45:58 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJMRsu27313
	for ietf-ldup-bks; Mon, 19 Nov 2001 14:27:54 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMRr827309
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 14:27:53 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Mon, 19 Nov 2001 17:21:04 -0700
Message-Id: <sbf93f80.041@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 19 Nov 2001 17:20:56 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <imcapple@hotmail.com>, <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
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 above.proper.com id fAJMRs827310
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


I think this depends on "how much change is too much".

There has been so much variation in various vendors implementations of
LDAPv3 that I don't have any trouble at all in asserting, in LDUP, that
certain practices or conventions are expected from LDAPv3 servers that
support LDUP, even if such vary, in minor ways, from the canonical
core specifications.

To provide a "reasonable interpretation" of LDAP data consistency
constraints so that the LDUP protocol and URP can deliver utility to their
users seems "within scope".

Adding a SQL-like "JOIN" operation (which the X.500 community are
looking at, or have done something about), dictating universal support
of "families of entries", and so forth seem "out of scope".  LDUP should
not make such major expectations on solution providers, and should
not dictate their use, or changes to their definitions.  In fact, I don't
even worry too much about whether LDUP can support them.

Transaction support, as we've discussed, belongs in the experimental
arena, in my opinion, so changes to the LDAPv3 core specifications
to support them seem, for instance, out of scope for LDUP to me.

I think the consistency model and URPs ability to support it, or
the changes to it necessary for URP to work, are an important area
of discussion, here.  The Model (Architecture) document includes a
long addendum in which we have attempted to address such questions.
Its review would be welcome.

Bottom line - LDAPv4 is out of scope.  The subtle changes to LDAPv3
to work in a multi-master environment, with the necessary adjustments
to data consistency expectations clients should have when working
in multiple-writer/multiple-replica environments are in-scope.

With that in mind, Kurt's text...

  This group may extend the LDAPv3 "core" specification 
  as necessary to deliver LDAP Replication.  However,
  updating the LDAPv3 "core" specification is beyond scope
  of this working group.

makes sense to me, and is consistent with what I think I'm working to
accomplish.

Ed

Parenthetically, I can see the importance of reaching agreement on this in light
of Kurt's other responsibilities to LDAPv3bis.

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/16/01 05:56PM >>>

(This is a serious question, I am still trying to figure out
what is beyond scope of this working group.)

Is engineering a version 4 of LDAP within scope?

At 10:32 AM 2001-11-16, Chris Apple wrote:
>That's simple enough to do. We'll add...
>>   This group may update the LDAPv3 "core" specification
>>   as necessary to deliver LDAP Replication.




From owner-ietf-ldup@mail.imc.org  Mon Nov 19 18:01:09 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02172
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 18:01:09 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAJMi9R28702
	for ietf-ldup-bks; Mon, 19 Nov 2001 14:44:09 -0800 (PST)
Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMi7828695
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 14:44:07 -0800 (PST)
Received: (from jayhawk@localhost)
	by tconl91223.tconl.com (8.11.0/8.11.0) id fAJMgTV01210;
	Mon, 19 Nov 2001 16:42:29 -0600
Date: Mon, 19 Nov 2001 16:42:28 -0600
From: Ryan Moats <rmoats@lemurnetworks.net>
To: Ed Reed <eer@OnCallDBA.COM>
Cc: ietf-ldup@imc.org
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
Message-ID: <20011119164228.C905@privateer.local.windrose.omaha.ne.us>
References: <sbf93c66.038@smtp.oncalldba.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <sbf93c66.038@smtp.oncalldba.com>; from eer@OnCallDBA.COM on Mon, Nov 19, 2001 at 05:07:31PM -0700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


On Mon, Nov 19, 2001 at 05:07:31PM -0700, Ed Reed wrote:
| Ryan -
| 
| w/r/t your item 2, below, I've assumed that (1) the entryUUID "thing"
| was something that LDUP adds as an expectation of LDAP servers
| supporting LDUP, and you could consider that an extension to the
| core specifications, and (2) that management operations would
| require and extended operation or control to assert the entryUUID
| for an entry being created (like the replicaSubentry and 
| replicationAgreementSubentry by a privileged operation).  This
| control would invoke logic similar to that used by the server to receive
| entries, including their entryUUID attributes, for creation on a replica
| from LDUP.

Let me see if I parse this right (I have a nascent cold and so I'm
reduced to thinking in terms of short lists:
	1. the LDAP server has to support entryUUID as an operational?
	   attribute
	2. LDUP would specify the entryUUID on new entries via an
	   extendedOP

Am I close? If so, see below.

| As for 1, I'm unclear - do you mean a need to be able to scan or search
| the directory for all operational attributes?  Surely LDUP needs to be
| able to scan the local repository for data elements that need to be
| replicated (in the case of a state-base replica scheme, at least), and
| certainly a management application console might make good use of
| such a thing.  But I don't guess I see that as a fundamental change
| to the LDAP data model, as much as a desired behavior in servers
| supporting LDUP

This comes as an extension to the first part above: are there going
to be operational attributes that need to be replicated between servers
(entryUUID, creatorsName, createTimestamp, modifiersName, modifyTimestamp
look like the obvious ones)?  Therefore, we need to be able to set
operational attributes and RFC 2251 says 

  "...Servers MUST NOT permit clients to add attributes to an entry unless
   those attributes are permitted by the object class definitions, the
   schema controlling that entry (specified in the subschema - see
   below), or are operational attributes known to that server and used
   for administrative purposes..."

and that creatorsName, createTimestamp, modifiersName and modifyTimestamp
are "automatically by the server and are not modifiable by clients"

Since the LDUP management console is a client, we started wondering if
LDAP will need a change.

Also, I can see that we need to be able to have operational attributes
returned as part of a search.  Now we can do that by listing the operational
attributes specifically, but is that the right approach?
| 
| I'll comment on Kurt's text separately.
| 
| Ed
| 
| 
| 
| =================
| Ed Reed
| Reed-Matthews, Inc.
| +1 585 624 2402
| http://www.Reed-Matthews.COM
| Note:  Area code is 585
| 
| >>> "Ryan Moats" <rmoats@lemurnetworks.net> 11/17/01 08:43AM >>>
| 
| 
| On Fri, 16 Nov 2001 19:24:55 -0500, "Chris Apple" <imcapple@hotmail.com>
| wrote :
| 
| > 
| > All editors should respond with their opinions on Kurt's current text
| > proposal for clarifying the charter to the WG mailing list ASAP.
| > 
| > I believe it reflects the strategy that we currently are
| > pursuing because of LDAPv3 installed base at the time
| > of initial charter creation. However, I want to hear from
| > the editors if this language is too constraining based on
| > what we know about the problems we still have to solve.
| > 
| > Chris.
| 
| I will quote from my mandatory replica announcement mail
| (http://www.imc.org/ietf-ldup/mail-archive/msg01209.html) where
| we ask at least 2 points where the core specification may need a
| change:
| 
| | 1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
| | operational attributes as part of this operation? If so, LDAP will need
| | a change.
| | 
| | 2. Section 4.6 currently requires that all replicaSubentries representing
| the
| | same server have the same entryUUID.  How is this accomplished?
| 
| I suspect that as we get deeper into MRM, we will turn up additional
| places where the core specification may need changing, so I can't see
| the core specification being "immutable".
| 
| Ryan
| 
| 
| 


From owner-ietf-ldup@mail.imc.org  Mon Nov 19 21:10:42 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06719
	for <ldup-archive@odin.ietf.org>; Mon, 19 Nov 2001 21:10:41 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAK0NdJ01603
	for ietf-ldup-bks; Mon, 19 Nov 2001 16:23:39 -0800 (PST)
Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK0Nb801599
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 16:23:37 -0800 (PST)
Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137])
	by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA17180;
	Mon, 19 Nov 2001 18:24:39 -0600
Received: from estokes.austin.ibm.com (sig-9-15-32-83.mts.ibm.com [9.15.32.83])
	by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA35190;
	Mon, 19 Nov 2001 18:23:35 -0600
Message-Id: <5.0.2.1.0.20011119182208.00a6a768@popmail2.austin.ibm.com>
X-Sender: stokes@popmail2.austin.ibm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 19 Nov 2001 18:23:34 -0600
To: "Ed Reed" <eer@OnCallDBA.COM>
From: Ellen Stokes <stokes@austin.ibm.com>
Subject: RE: Adding to the LDAP ACM to a WG charter
Cc: ietf-ldup@imc.org
In-Reply-To: <sbf8ea5a.007@smtp.oncalldba.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


The non-sequitor you point to is a typo on my part.
I meant to say that the ACM work cannot be finished in LDAPext
because that group is shutting down.
Ellen

At 11:17 AM 11/19/2001 -0700, you wrote:
>I didn't quite follow that, Ellen - "since this work cannot be finished
>in LDUP (ldapext is shutting down)" seems like a non-sequitor.  Did
>you mean it can't be done in LDAPEXT?
>
>I come down in favor of a separate working group to hash out
>the end-all-and-be-all Access Control Model, or even an appropriate
>subset.
>
>In addition to the list of issues that Kurt raised, I'll point
>out that the X.500 model also includes provisions for Rule Based
>Access Control, which takes determination of appropriate
>security clearances, roles, etc. to be more important than the
>actual identity of the security principal, which is a particularly
>important manner of access control among very large, independently
>administered heterogeneous communities like the Internet.
>
>The X.500 work was, I think, done to address data handling
>constraints associated with the US DOD Defence Messaging System
>design, which is not getting much press today.
>
>However, the notion that interoperability between companies
>should follow a model that allows data administrators in the directory
>to set classification of data that requires role and clearance
>information to be authoritatively provided, without necessarily
>having any knowledge at all about the actual identity of the
>principal (anonymous, but trusted, vs anonymous and untrusted)
>is very attractive.
>
>Kurt's list of Authentication issues to discuss, together with the
>X.500 notion of Rule Based Authorization and the current market
>craze in favor of Role Based Authentication (where the ACI
>refers to a role, not an individual, and it's the job of the
>authentication service to provide information about the roles
>and clearance of the principal to relying services like the directory)
>should NOT be dealt with in LDUP, but rather a separate
>LDAPACM working group.
>
>The (proposed new) LDAPACM working group should work diligently
>to (a) not break LDAP, (b) store its policy and principal information
>in the Directory so that LDUP will replicate it, and detail as much
>as possible what special provisions, if any, are needed in LDUP to
>preserve the integrity of the ACM information.  For instance,
>it might very well be a requirement that ACM information
>be sent by state-based replication schemes in LDUP BEFORE any
>of the data elements to which it applies is sent.
>
>I vote in favor of NOT doing LDAPACM in LDUP, but rather
>leaving LDUP to the task of shipping directory information around
>"safely", while leaving LDAPACM the opportunity to place
>SOME requirements on LDUP when those requirements are fully
>known.
>
>LDUP is useful (as was LDAPv2 and LDAPv3) even if it does not provide
>a complete, seamless, end-to-end, multi-vendor environment with
>a perfectly consistent management and security policy implementation.
>
>Lets get on with discovering what some of those uses are.
>
>Ed
>
>=================
>Ed Reed
>Reed-Matthews, Inc.
>+1 585 624 2402
>http://www.Reed-Matthews.COM
>Note:  Area code is 585
>
> >>> Ellen Stokes <stokes@austin.ibm.com> 11/17/01 12:40PM >>>
>
>Security is important for a replicated environment.
>
>For the secure replicated heterogeneous environment to work, an
>access control model is necessary.
>
>Since this work cannot be finished in LDUP (ldapext is shutting
>down), the access control model needs a home.
>
>And given the complexity of the topic, it is insufficient to just
>release the spec as informational, experimental, or as an
>individual publication.
>
>I am FOR adding access control model to LDUP.
>
>Ellen



From owner-ietf-ldup@mail.imc.org  Tue Nov 20 00:08:32 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13884
	for <ldup-archive@lists.ietf.org>; Tue, 20 Nov 2001 00:08:32 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAK4put08282
	for ietf-ldup-bks; Mon, 19 Nov 2001 20:51:56 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK4ps808278
	for <ietf-ldup@imc.org>; Mon, 19 Nov 2001 20:51:54 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAK4uxC73089;
	Tue, 20 Nov 2001 04:56:59 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011119202456.017760c0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 19 Nov 2001 20:50:57 -0800
To: Ryan Moats <rmoats@lemurnetworks.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
Cc: Ed Reed <eer@OnCallDBA.COM>, ietf-ldup@imc.org
In-Reply-To: <20011119164228.C905@privateer.local.windrose.omaha.ne.us>
References: <sbf93c66.038@smtp.oncalldba.com>
 <sbf93c66.038@smtp.oncalldba.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Ryan,

With mutual consent of both protocol peers, extensions can
significant alter the semantics of operations.  IMO, the
specification of a "disable NO-USER-MODIFICATION restriction"
control or a more general "manage replica" control would not
require a change to LDAP "core" specification.  (Some
clarification to "core" documents might be appropriate,
but we can and should defer consideration of and action
on such to LDAPbis.)

Kurt
  

At 02:42 PM 2001-11-19, Ryan Moats wrote:

>On Mon, Nov 19, 2001 at 05:07:31PM -0700, Ed Reed wrote:
>| Ryan -
>| 
>| w/r/t your item 2, below, I've assumed that (1) the entryUUID "thing"
>| was something that LDUP adds as an expectation of LDAP servers
>| supporting LDUP, and you could consider that an extension to the
>| core specifications, and (2) that management operations would
>| require and extended operation or control to assert the entryUUID
>| for an entry being created (like the replicaSubentry and 
>| replicationAgreementSubentry by a privileged operation).  This
>| control would invoke logic similar to that used by the server to receive
>| entries, including their entryUUID attributes, for creation on a replica
>| from LDUP.
>
>Let me see if I parse this right (I have a nascent cold and so I'm
>reduced to thinking in terms of short lists:
>        1. the LDAP server has to support entryUUID as an operational?
>           attribute
>        2. LDUP would specify the entryUUID on new entries via an
>           extendedOP
>
>Am I close? If so, see below.
>
>| As for 1, I'm unclear - do you mean a need to be able to scan or search
>| the directory for all operational attributes?  Surely LDUP needs to be
>| able to scan the local repository for data elements that need to be
>| replicated (in the case of a state-base replica scheme, at least), and
>| certainly a management application console might make good use of
>| such a thing.  But I don't guess I see that as a fundamental change
>| to the LDAP data model, as much as a desired behavior in servers
>| supporting LDUP
>
>This comes as an extension to the first part above: are there going
>to be operational attributes that need to be replicated between servers
>(entryUUID, creatorsName, createTimestamp, modifiersName, modifyTimestamp
>look like the obvious ones)?  Therefore, we need to be able to set
>operational attributes and RFC 2251 says 
>
>  "...Servers MUST NOT permit clients to add attributes to an entry unless
>   those attributes are permitted by the object class definitions, the
>   schema controlling that entry (specified in the subschema - see
>   below), or are operational attributes known to that server and used
>   for administrative purposes..."
>
>and that creatorsName, createTimestamp, modifiersName and modifyTimestamp
>are "automatically by the server and are not modifiable by clients"
>
>Since the LDUP management console is a client, we started wondering if
>LDAP will need a change.
>
>Also, I can see that we need to be able to have operational attributes
>returned as part of a search.  Now we can do that by listing the operational
>attributes specifically, but is that the right approach?
>| 
>| I'll comment on Kurt's text separately.
>| 
>| Ed
>| 
>| 
>| 
>| =================
>| Ed Reed
>| Reed-Matthews, Inc.
>| +1 585 624 2402
>| http://www.Reed-Matthews.COM
>| Note:  Area code is 585
>| 
>| >>> "Ryan Moats" <rmoats@lemurnetworks.net> 11/17/01 08:43AM >>>
>| 
>| 
>| On Fri, 16 Nov 2001 19:24:55 -0500, "Chris Apple" <imcapple@hotmail.com>
>| wrote :
>| 
>| > 
>| > All editors should respond with their opinions on Kurt's current text
>| > proposal for clarifying the charter to the WG mailing list ASAP.
>| > 
>| > I believe it reflects the strategy that we currently are
>| > pursuing because of LDAPv3 installed base at the time
>| > of initial charter creation. However, I want to hear from
>| > the editors if this language is too constraining based on
>| > what we know about the problems we still have to solve.
>| > 
>| > Chris.
>| 
>| I will quote from my mandatory replica announcement mail
>| (http://www.imc.org/ietf-ldup/mail-archive/msg01209.html) where
>| we ask at least 2 points where the core specification may need a
>| change:
>| 
>| | 1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
>| | operational attributes as part of this operation? If so, LDAP will need
>| | a change.
>| | 
>| | 2. Section 4.6 currently requires that all replicaSubentries representing
>| the
>| | same server have the same entryUUID.  How is this accomplished?
>| 
>| I suspect that as we get deeper into MRM, we will turn up additional
>| places where the core specification may need changing, so I can't see
>| the core specification being "immutable".
>| 
>| Ryan
>| 
>| 
>| 



From owner-ietf-ldup@mail.imc.org  Tue Nov 20 07:30:15 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05496
	for <ldup-archive@odin.ietf.org>; Tue, 20 Nov 2001 07:30:15 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAKC7gg21819
	for ietf-ldup-bks; Tue, 20 Nov 2001 04:07:42 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKC7e821814
	for <ietf-ldup@imc.org>; Tue, 20 Nov 2001 04:07:40 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost)
	by stingray.missi.ncsc.mil with ESMTP id fAKC3AP02141;
	Tue, 20 Nov 2001 07:03:10 -0500 (EST)
Message-ID: <200111201203.fAKC39502137@stingray.missi.ncsc.mil>
From: "Roddy A. Sue" <saroddy@missi.ncsc.mil>
To: "'Paul Leach'" <paulle@windows.microsoft.com>,
        Ryan Moats
	 <rmoats@lemurnetworks.net>,
        Steven Legg <steven.legg@adacel.com.au>
Cc: ietf-ldup@imc.org
Subject: RE: Adding to the LDAP ACM to a WG charter
Date: Tue, 20 Nov 2001 07:03:35 -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: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


As someone who needs to deploy a global directory that contains white, blue
and yellow pages data, as well as key management data, I am not in an
operational environment that permits one group or person to manage all the
data.

My accountability and separation of duty requirements on the administrators
of this system lead us to more than simplistic access control models.
Replication of that data to any portion of the system, as well as a
standardized process for performing the access control decision function is
very high on the requirements list.  

We are hampered in our ability to select different products for our
directory services by the lack of a standardized approach.  The initial
rollout/deployment will be product-specific because the interoperability
cannot be tested or specified in procurement documents, since it does not
exist in a standardized way.

To be fair, we are also hampered by a standardized means of deriving the
ownership rules of the data and I would like to see some additional work
done on development of that kind of framework.  I believe the OpenGroup has
expressed interest in helping establish the framework. However, without a
standardized means of replicated the AC information, we cannot progress
beyond a homogenous directory server environment.

regards


Sandi Roddy
National Security Agency
V5 Technical Director - Security
410-854-7070


-----Original Message-----
From: Paul Leach [mailto:paulle@windows.microsoft.com]
Sent: Monday, November 19, 2001 4:18 PM
To: Ryan Moats; Steven Legg
Cc: ietf-ldup@imc.org
Subject: RE: Adding to the LDAP ACM to a WG charter





> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net] 
> Sent: Monday, November 19, 2001 11:25 AM
> To: Steven Legg

> Pardon? I thought the idea of LDUP was a standard that would 
> lead to interoperability.  I don't see how this is possible 
> if deployment is ignored.

I believe that a quite useful replicated directory could be deployed
with limited security functionality until an ACM standard is completed. 

How, you ask? As someone else noted, the access policy could be kept in
synch out of band. In practice, that would mean access policy would have
to be simple, and change infrequently. A very useful, and quite
depoyable, policy that meets that requirement is one that allows
everyone read, and one person or group update, to the contents of the
whole server (or whole naming contexts within the server, if you want to
get slightly more complex).

Paul


From owner-ietf-ldup@mail.imc.org  Tue Nov 20 07:48:51 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05939
	for <ldup-archive@odin.ietf.org>; Tue, 20 Nov 2001 07:48:50 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAKCWaE22768
	for ietf-ldup-bks; Tue, 20 Nov 2001 04:32:36 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKCWZ822764
	for <ietf-ldup@imc.org>; Tue, 20 Nov 2001 04:32:35 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Tue, 20 Nov 2001 07:25:38 -0700
Message-Id: <sbfa0572.067@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Tue, 20 Nov 2001 07:25:27 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <rmoats@lemurnetworks.net>, <Kurt@OpenLDAP.org>
Cc: <ietf-ldup@imc.org>
Subject: Re: LDAPv4?  (Was: Updating "core" specification)
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 above.proper.com id fAKCWZ822765
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


Yes, Ryan - those are the sorts of "minor adjustments" to the model
to accomodate LDUP.  Essentially, we recognize that a Server
operating against another server is a "special kind of client", which
may, for instance, be operating on behalf of someone else as a
proxy, or may be doing server-to-server like stuff, including replication.

As such, a management console that needs to help debug and repair
replication must also be a special kind of server, able to do things not
allowed to regular clients, like set the creation and modification times
on entries, etc.

I don't think such requires modification to the core specification, either,
and would be happy for notes of such adjustments being possible
or necessary under some conditions to take place in LDAPbis.

Ed

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/19/01 11:50PM >>>
Ryan,

With mutual consent of both protocol peers, extensions can
significant alter the semantics of operations.  IMO, the
specification of a "disable NO-USER-MODIFICATION restriction"
control or a more general "manage replica" control would not
require a change to LDAP "core" specification.  (Some
clarification to "core" documents might be appropriate,
but we can and should defer consideration of and action
on such to LDAPbis.)

Kurt
  

At 02:42 PM 2001-11-19, Ryan Moats wrote:

>On Mon, Nov 19, 2001 at 05:07:31PM -0700, Ed Reed wrote:
>| Ryan -
>| 
>| w/r/t your item 2, below, I've assumed that (1) the entryUUID "thing"
>| was something that LDUP adds as an expectation of LDAP servers
>| supporting LDUP, and you could consider that an extension to the
>| core specifications, and (2) that management operations would
>| require and extended operation or control to assert the entryUUID
>| for an entry being created (like the replicaSubentry and 
>| replicationAgreementSubentry by a privileged operation).  This
>| control would invoke logic similar to that used by the server to receive
>| entries, including their entryUUID attributes, for creation on a replica
>| from LDUP.
>
>Let me see if I parse this right (I have a nascent cold and so I'm
>reduced to thinking in terms of short lists:
>        1. the LDAP server has to support entryUUID as an operational?
>           attribute
>        2. LDUP would specify the entryUUID on new entries via an
>           extendedOP
>
>Am I close? If so, see below.
>
>| As for 1, I'm unclear - do you mean a need to be able to scan or search
>| the directory for all operational attributes?  Surely LDUP needs to be
>| able to scan the local repository for data elements that need to be
>| replicated (in the case of a state-base replica scheme, at least), and
>| certainly a management application console might make good use of
>| such a thing.  But I don't guess I see that as a fundamental change
>| to the LDAP data model, as much as a desired behavior in servers
>| supporting LDUP
>
>This comes as an extension to the first part above: are there going
>to be operational attributes that need to be replicated between servers
>(entryUUID, creatorsName, createTimestamp, modifiersName, modifyTimestamp
>look like the obvious ones)?  Therefore, we need to be able to set
>operational attributes and RFC 2251 says 
>
>  "...Servers MUST NOT permit clients to add attributes to an entry unless
>   those attributes are permitted by the object class definitions, the
>   schema controlling that entry (specified in the subschema - see
>   below), or are operational attributes known to that server and used
>   for administrative purposes..."
>
>and that creatorsName, createTimestamp, modifiersName and modifyTimestamp
>are "automatically by the server and are not modifiable by clients"
>
>Since the LDUP management console is a client, we started wondering if
>LDAP will need a change.
>
>Also, I can see that we need to be able to have operational attributes
>returned as part of a search.  Now we can do that by listing the operational
>attributes specifically, but is that the right approach?
>| 
>| I'll comment on Kurt's text separately.
>| 
>| Ed
>| 
>| 
>| 
>| =================
>| Ed Reed
>| Reed-Matthews, Inc.
>| +1 585 624 2402
>| http://www.Reed-Matthews.COM 
>| Note:  Area code is 585
>| 
>| >>> "Ryan Moats" <rmoats@lemurnetworks.net> 11/17/01 08:43AM >>>
>| 
>| 
>| On Fri, 16 Nov 2001 19:24:55 -0500, "Chris Apple" <imcapple@hotmail.com>
>| wrote :
>| 
>| > 
>| > All editors should respond with their opinions on Kurt's current text
>| > proposal for clarifying the charter to the WG mailing list ASAP.
>| > 
>| > I believe it reflects the strategy that we currently are
>| > pursuing because of LDAPv3 installed base at the time
>| > of initial charter creation. However, I want to hear from
>| > the editors if this language is too constraining based on
>| > what we know about the problems we still have to solve.
>| > 
>| > Chris.
>| 
>| I will quote from my mandatory replica announcement mail
>| (http://www.imc.org/ietf-ldup/mail-archive/msg01209.html) where
>| we ask at least 2 points where the core specification may need a
>| change:
>| 
>| | 1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
>| | operational attributes as part of this operation? If so, LDAP will need
>| | a change.
>| | 
>| | 2. Section 4.6 currently requires that all replicaSubentries representing
>| the
>| | same server have the same entryUUID.  How is this accomplished?
>| 
>| I suspect that as we get deeper into MRM, we will turn up additional
>| places where the core specification may need changing, so I can't see
>| the core specification being "immutable".
>| 
>| Ryan
>| 
>| 
>| 



From owner-ietf-ldup@mail.imc.org  Tue Nov 20 14:16:32 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29952
	for <ldup-archive@lists.ietf.org>; Tue, 20 Nov 2001 14:16:31 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAKI9PM15892
	for ietf-ldup-bks; Tue, 20 Nov 2001 10:09:25 -0800 (PST)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKI9N815888
	for <ietf-ldup@imc.org>; Tue, 20 Nov 2001 10:09:23 -0800 (PST)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.195]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 20 Nov 2001 10:08:54 -0800
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Nov 2001 10:08:54 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 20 Nov 2001 10:08:53 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 20 Nov 2001 10:08:50 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Tue, 20 Nov 2001 10:08:10 -0800
Content-Class: urn:content-classes:message
Subject: RE: Adding to the LDAP ACM to a WG charter
MIME-Version: 1.0
Date: Tue, 20 Nov 2001 10:08:10 -0800
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0020_01C171AB.4AF808C0"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD02A879D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: yes
Thread-Topic: Adding to the LDAP ACM to a WG charter
thread-index: AcFxvD32ZRFP8k83TjGZ6Mjp9zuIUAAMWZyA
From: "Paul Leach" <paulle@windows.microsoft.com>
To: "Roddy A. Sue" <saroddy@missi.ncsc.mil>,
        "Ryan Moats" <rmoats@lemurnetworks.net>,
        "Steven Legg" <steven.legg@adacel.com.au>
Cc: <ietf-ldup@imc.org>
X-OriginalArrivalTime: 20 Nov 2001 18:08:10.0940 (UTC) FILETIME=[5079CFC0:01C171EE]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C171AB.4AF808C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I want to be clear. I am not suggesting that, in order to allow
multi-vendor replicas, a standard ACM isn't required.

The only question is whether they need to be developed by the same WG,
other whether _this_ WG should focus on what has proven to be a very
difficult problem, and finish it; or whether it should undertake another
very difficult problem that may very well defocus it and delay finishing
the primary one it was set up to solve.

This is not a question of requirements -- it is a question of creating
an efficient engineering process to get things done. I believe that
history has shown conclusively that trying to solve too many hard
problems simultaneously leads to none of them getting done.

Paul

------=_NextPart_000_0020_01C171AB.4AF808C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkSzCCA0Aw
ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL
LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b
mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd
MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud
DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v
d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy
MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv
bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA
MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc
ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy
LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIGPzCCBf+gAwIBAgIKdZ/59AACAAAB
VjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT
BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X
DTAxMDkxNDAzMTY1MFoXDTAyMDkyMDIxMzMyOFowSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p
Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAupHMN0lJw9ae2Ic2yZBICCqeP2H6Re4B1Rnk+KETtF0S15jq
7ea5n/+z43Da9CqjunNJaLT7rX4o9NHUN7eP5aKlZ7aRP+EoT0wB51OPsjZKuFWptbdL7PEVHAuO
UrOOjyZ0ITR432vqcJ/L3AouTyuCuN7/1kw9tMMRl5erzkUCAwEAAaOCBG0wggRpMBAGCSsGAQQB
gjcVAQQDAgEBMCMGCSsGAQQBgjcVAgQWBBRdMJl7HuLsmpzfroTjjkV60iifVTAdBgNVHQ4EFgQU
yURWSpATfKnzMwZr3tCZu+fIzukwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUz8W6F/8txxCA9bkOmUpv9Jwr+xkwggI+
BgNVHR8EggI1MIICMTCCAi2gggIpoIICJYaB32xkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh
dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKSxDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUy
MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9
bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh
c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGX2h0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNv
bS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIo
MSkuY3JshoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIw
V2hpY2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049
U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2Nl
cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q
b2ludDCCAXMGCCsGAQUFBwEBBIIBZTCCAWEwgdUGCCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERF
ViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMl
MjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERD
PW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj
YXRpb25BdXRob3JpdHkwgYYGCCsGAQUFBzAChnpodHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29m
dC5jb20vQ2VydEVucm9sbC93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVy
bWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDIpLmNydDAJBgcqhkjOOAQDAy8AMCwCFFMe
+4NdwTMB4JPtUG8oni8k6DDeAhR524Ez1P2PwtOazvpFd7iVYMg9aDCCBmIwggXLoAMCAQICChux
xUYAAQAO4UswDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m
dDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMTExMDEwNzA2
MDFaFw0wMTEyMzEwNzA2MDFaMIHHMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQB
GRYJbWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxEDAOBgNVBAsTB0lNLVNlbGYxFzAV
BgNVBAsTDkxpZ2h0bHlNYW5hZ2VkMREwDwYDVQQLEwhMb3dUQ08tRTETMBEGA1UEAxMKUGF1bCBM
ZWFjaDErMCkGCSqGSIb3DQEJARYccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA0WAm55icVMn039qIncrD9oHYxu0Om9Dk5JXDvXSwAmNIPi0m
Nmi684FIgc1sm0pLiRK+FjDKAd042hCP95qfXROEhobXZqncfgtdtHCq4saJbCklRWiuk2aEvtbe
yOOCtoB2l3bwjDLX81ltRc5U+y0+MjCbT2YpnOOM8CT51HsCAwEAAaOCA84wggPKMAsGA1UdDwQE
AwIEMDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYF
Kw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFF88kzdblYOctDxJftcu3j7rqpexMD4GCSsGAQQB
gjcVBwQxMC8GJysGAQQBgjcVCI3g0YlOhNecwweGpob7HI/Tv6YVh6e+4gmOsa3xTQIBcQIBAjAf
BgNVHSMEGDAWgBTJRFZKkBN8qfMzBmve0Jm758jO6TCCASYGA1UdHwSCAR0wggEZMIIBFaCCARGg
ggENhoHEbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENOPVdISUNBMyxDTj1DRFAsQ049
UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1u
dGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v
YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZEaHR0cDovL3doaWNhMy5udGRldi5taWNy
b3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJU1NVRTMlMjBDQS5jcmwwggFCBggrBgEFBQcB
AQSCATQwggEwMIG9BggrBgEFBQcwAoaBsGxkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxD
Tj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJh
dGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmpl
Y3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MG4GCCsGAQUFBzAChmJodHRwOi8vd2hpY2Ez
Lm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9XSElDQTMubnRkZXYubWljcm9zb2Z0LmNv
bV9OVERFViUyMElTU1VFMyUyMENBKDEpLmNydDATBgNVHSUEDDAKBggrBgEFBQcDBDAbBgkrBgEE
AYI3FQoEDjAMMAoGCCsGAQUFBwMEMFMGA1UdEQRMMEqgKgYKKwYBBAGCNxQCA6AcDBpwYXVsbGVA
bnRkZXYubWljcm9zb2Z0LmNvbYEccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTANBgkqhkiG
9w0BAQUFAAOBgQAfFDMQJ0QLYvU+VFaKolCmuwVA0KNI/ipaTWHqaONAKd7Cf5Aj5DsdOjpIq724
uwHGWg64M7muhfICg+r7vhlYmNAfU+fM6jjaKCfQXUa/+zuH5KqyOClMEhBOlAzAWywND5IeZPWt
AOYSoBhedxHV7MTcTl1HK7OJc4h74gU/dDCCBqcwggYQoAMCAQICChRel0MAAAAAACgwDQYJKoZI
hvcNAQEFBQAwTDELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRk
ZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJvb3QgQ0EwHhcNMDExMTAxMjA1NzExWhcNMDIwOTIwMjEz
MzI4WjBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEu
MCwGA1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjCCAbYwggErBgcq
hkjOOAQBMIIBHgKBgQD4Ly2xZP3/BEVJKm5f8RYN3D0lcE0i1w2lCKMzyIcaEIC84swy1gpKY0Z4
R8RAzij8hRkw8ciXT6at5mgDHo7lJ3aPmEOsxwnxkN8hhZs50hPBtGGVs6B1ijVEZiGdTzlTLneI
Fc6Mk7HEMv3sP7S1KvWJDls9rrRJYFlyTB35AQIVALpK4A0b7aa6zeQ1ZkPPC9iRcCjfAoGAZ7hM
x51ULfa+kKU94Fo1HH3cDdrSm6db5w8oqxOJkj9+qa23p9kl3cPdioGshDQjF4LO8R+vSRPM/UG5
ir7LkkE6uivrzXDGHF16C4/ZoMAdZHU7UGtuoHhI92GmibmzXkbiMWNyvD3YiM14Pq/BY9RHNVC8
V2tuUNe+bJ17lQsDgYQAAoGABlYEqKplvCqnqB1HWeyQOfRQ5UJLtSTNGKkL6PPAcbxdWsN1JiDa
mLDxvmTXYm8kWSuRkzSqrGPispNIDLOAmXRY79tX4IWD9IpsVhGP8U6C7ycNzZpNM6bEuBQgAVVf
fSBa99Qsq7gSrPkkFA8EeikTolxKM5dOM01Z2BGdpfmjggNhMIIDXTASBgkrBgEEAYI3FQEEBQID
AQADMCMGCSsGAQQBgjcVAgQWBBQYxRo0WCyvkaAaxWWDIpP6xv8VFTAdBgNVHQ4EFgQUz8W6F/8t
xxCA9bkOmUpv9Jwr+xkwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgHGMA8G
A1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUd8l0aSw5/jhl9IcFWAjOvbqX2hAwggE6BgNVHR8E
ggExMIIBLTCCASmgggEloIIBIYaBzmxkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxD
Tj13aGljYXNhcm9vdGNhLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2
aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlm
aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50
hk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRE
RVYlMjBTQSUyMFJvb3QlMjBDQS5jcmwwggFTBggrBgEFBQcBAQSCAUUwggFBMIHABggrBgEFBQcw
AoaBs2xkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxDTj1BSUEsQ049UHVibGljJTIw
S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1t
aWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0
aW9uQXV0aG9yaXR5MHwGCCsGAQUFBzAChnBodHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNy
b3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tX05U
REVWJTIwU0ElMjBSb290JTIwQ0EuY3J0MBQGA1UdIAEB/wQKMAgwBgYEVR0gADANBgkqhkiG9w0B
AQUFAAOBgQAxYiUUmrT3jDFqE+1g0gCnBxgfC3mMkIRtVA3sS+AZCB5QdVwHMIn5Vbcz+UHzq+GK
S/fRM2ETd19y56KAaNFI5NSLPuuvZIYuzw0QCsVjb1o0JDT8Z60ebroLDDtlXOBnmasVjmc5PDyV
KrlGtTyCLiWK9oZkNNUV4OJ/xruinzCCBqwwggZroAMCAQICChnMypwAAgAAAWAwCQYHKoZIzjgE
AzBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEuMCwG
A1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjAeFw0wMTEwMjUwMDQw
MjFaFw0wMjA5MjAyMTMzMjhaMHsxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZ
FgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEyMDAGA1UEAwwpTlRERVbjgIDvvKnv
vZPvvZPvvZXvvYXvvKrvvLDvvK7jgIDjgovjgbEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
AMLpdqtuCBDrs6W5nglAbizKGz0nZ6Xc00ZGNF/toXvZbvRTRfan+wj1HzcLG4qBlcudEbmir08S
Y2fL6lBS607lcrujUul9n5w5Nxm5CfFCO4SegOglrYaBiE7GJZia3cpRiR3T5J5TJ69GGWTJTnb9
IdLaoZNdzzx8jvydHrEnAgMBAAGjggSpMIIEpTAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQU
qXZyJ4BnnmSuH+3DpPN82oJrYbswGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUz8W6F/8txxCA9bkOmUpv9Jwr+xkwggKf
BgNVHR8EggKWMIICkjCCAo6gggKKoIIChoaB32xkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh
dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKSxDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUy
MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9
bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh
c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGX2h0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNv
bS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIo
MSkuY3JshoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIw
V2hpY2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049
U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2Nl
cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q
b2ludIZfaHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYl
MjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKS5jcmwwggFzBggrBgEFBQcB
AQSCAWUwggFhMIHVBggrBgEFBQcwAoaByGxkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlhdGUl
MjBTdWJvcmRpbmF0ZSUyMFdoaWNhMixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs
Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29t
P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGG
BggrBgEFBQcwAoZ6aHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv
d2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRp
bmF0ZSUyMFdoaWNhMigyKS5jcnQwCQYHKoZIzjgEAwMwADAtAhUArQS6yf+6F2yfZOaFlrSUHaiz
PYMCFAkXqtidhCmi1K1WdMAiPGRNQTrYMIIG/zCCBmigAwIBAgIKFqMOjwAAAAARSTANBgkqhkiG
9w0BAQQFADB7MRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0
MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxMjAwBgNVBAMMKU5UREVW44CA77yp772T772T772V772F
77yq77yw77yu44CA44KL44GxMB4XDTAxMTAyNjA1MDcwM1oXDTAxMTIyNTA1MDcwM1owgZoxEzAR
BgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/Is
ZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAP
BgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQC7wT7Bd38+Ks6MZKY1ifceDwTrqzmpD0KOTiiEVOLBprrQCFTFx4bIaf6q2QNBIZLJ
/5nGbuYJEA3EFOvJwAtq2wPeiz8a0lOcZM+4wFPzfXXfxhpp04dhmZjr+zNy4gkkS6W38N4xDBI4
X0XjjUWQdz8tyTu5OICCOglUGn/qeQIDAQABo4IEaDCCBGQwCwYDVR0PBAQDAgeAMB0GA1UdDgQW
BBS10JYzdomL7n2TQwQk5bnWBczNbjA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTX
nMMHhqaG+xyP07+mFYK/nPZ8ht7mgFQCAXECAQAwHwYDVR0jBBgwFoAUqXZyJ4BnnmSuH+3DpPN8
2oJrYbswggF/BgNVHR8EggF2MIIBcjCCAW6gggFqoIIBZoaB7GxkYXA6Ly8vQ049TlRERVYhMzAw
MCFmZjI5IWZmNTMhZmY1MyFmZjU1IWZmNDUhZmYyYSFmZjMwIWZmMmUtMzU5MzEsQ049d2hpY2Fp
bnRsLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m
aWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0
aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hnVodHRwOi8vd2hp
Y2FpbnRsLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViEzMDAwIWZmMjkhZmY1
MyFmZjUzIWZmNTUhZmY0NSFmZjJhIWZmMzAhZmYyZSEzMDAwITMwOGIhMzA3MS5jcmwwggGaBggr
BgEFBQcBAQSCAYwwggGIMIHiBggrBgEFBQcwAoaB1WxkYXA6Ly8vQ049TlRERVYhMzAwMCFmZjI5
IWZmNTMhZmY1MyFmZjU1IWZmNDUhZmYyYSFmZjMwIWZmMmUtMzU5MzEsQ049QUlBLENOPVB1Ymxp
YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYs
REM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm
aWNhdGlvbkF1dGhvcml0eTCBoAYIKwYBBQUHMAKGgZNodHRwOi8vd2hpY2FpbnRsLm50ZGV2Lm1p
Y3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYWludGwubnRkZXYubWljcm9zb2Z0LmNvbV9OVERF
ViEzMDAwIWZmMjkhZmY1MyFmZjUzIWZmNTUhZmY0NSFmZjJhIWZmMzAhZmYyZSEzMDAwITMwOGIh
MzA3MS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwQwLQYDVR0gBCYwJDAiBiArBgEEAYI3FQiN4NGJ
ToTXnMMHhqaG+xyP07+mFQGDETAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUFBwMEMFMGA1UdEQRM
MEqgKgYKKwYBBAGCNxQCA6AcDBpwYXVsbGVAbnRkZXYubWljcm9zb2Z0LmNvbYEccGF1bGxlQHdp
bmRvd3MubWljcm9zb2Z0LmNvbTANBgkqhkiG9w0BAQQFAAOBgQBQIvo0XakfAv7wRCkrzUt81Wbc
k0oTYHy0pxhVi9ofZRyv2RLhhSrXJEscmJlVpqNdRWyHXSq0j/rPghWi3SGwJ//DY7gDCt8fkgMo
89dELedxkAhDRH431cL6n4zoFYy+tijR0uxfltqU2KptDfH4QFPEh90NctpxFFCW+wJzuzGCAtAw
ggLMAgEBMIGJMHsxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3Nv
ZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEyMDAGA1UEAwwpTlRERVbjgIDvvKnvvZPvvZPvvZXv
vYXvvKrvvLDvvK7jgIDjgovjgbECChajDo8AAAAAEUkwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMTIwMTgwODI1WjAjBgkqhkiG9w0B
CQQxFgQUBF6Rg1QCZ+STz2tsLpkATh1FVGUwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAH
BgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAEMVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgob
scVGAAEADuFLMGoGCyqGSIb3DQEJEAILMVugWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj
cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgobscVGAAEA
DuFLMA0GCSqGSIb3DQEBAQUABIGAXWEckNIJ/iW/RiRStU8NHP1UvHgkTXCKKYWduaI877oSj/1g
zGuAVxUIKlUZju43+nZsUV9e8P57eUdGHpm4qzK3fsT20RPmaT8Q9F4WZERHebNdVEYz0YHb3qwr
KWajPtFdZ2G8GLXY8nu6oS/OckLz8NvGniKjhMnjsBD5IXcAAAAAAAA=

------=_NextPart_000_0020_01C171AB.4AF808C0--


From owner-ietf-ldup@mail.imc.org  Tue Nov 20 14:32:54 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01021
	for <ldup-archive@lists.ietf.org>; Tue, 20 Nov 2001 14:32:53 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAKJDr117650
	for ietf-ldup-bks; Tue, 20 Nov 2001 11:13:53 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJDf817636
	for <ietf-ldup@imc.org>; Tue, 20 Nov 2001 11:13:41 -0800 (PST)
Message-Id: <200111201913.fAKJDf817636@above.proper.com>
Received: from stingray.missi.ncsc.mil (root@localhost)
	by stingray.missi.ncsc.mil with ESMTP id fAKIACj17643;
	Tue, 20 Nov 2001 13:10:12 -0500 (EST)
From: "Roddy A. Sue" <saroddy@missi.ncsc.mil>
To: "'Paul Leach'" <paulle@windows.microsoft.com>,
        Ryan Moats
	 <rmoats@lemurnetworks.net>,
        Steven Legg <steven.legg@adacel.com.au>
Cc: ietf-ldup@imc.org
Subject: RE: Adding to the LDAP ACM to a WG charter
Date: Tue, 20 Nov 2001 13:10:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Is there any effort in a security-focused working group to look at
cross-protocol security attribute definitions?  One would like to think that
a common solution could be found (separate from the bio-diversity argument
of security through obscurity).


Sandi Roddy
National Security Agency
V5 Technical Director - Security
410-854-7070


-----Original Message-----
From: Paul Leach [mailto:paulle@windows.microsoft.com]
Sent: Tuesday, November 20, 2001 1:08 PM
To: Roddy A. Sue; Ryan Moats; Steven Legg
Cc: ietf-ldup@imc.org
Subject: RE: Adding to the LDAP ACM to a WG charter


I want to be clear. I am not suggesting that, in order to allow
multi-vendor replicas, a standard ACM isn't required.

The only question is whether they need to be developed by the same WG,
other whether _this_ WG should focus on what has proven to be a very
difficult problem, and finish it; or whether it should undertake another
very difficult problem that may very well defocus it and delay finishing
the primary one it was set up to solve.

This is not a question of requirements -- it is a question of creating
an efficient engineering process to get things done. I believe that
history has shown conclusively that trying to solve too many hard
problems simultaneously leads to none of them getting done.

Paul


From owner-ietf-ldup@mail.imc.org  Tue Nov 20 16:42:25 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07443
	for <ldup-archive@lists.ietf.org>; Tue, 20 Nov 2001 16:42:25 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAKKpwP22557
	for ietf-ldup-bks; Tue, 20 Nov 2001 12:51:58 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKKpv822553
	for <ietf-ldup@imc.org>; Tue, 20 Nov 2001 12:51:57 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAKKuaC76308;
	Tue, 20 Nov 2001 20:57:11 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011120124113.01787858@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 20 Nov 2001 12:50:30 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: applicability statement (Re: revised WG charter proposal)
Cc: <ietf-ldup@imc.org>
In-Reply-To: <OE76COrsQILbU7q7TjD0000a30b@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 09:21 AM 2001-11-16, Chris Apple wrote:
>The WG's approach is to first develop a set of requirements for
>LDAPv3 directory replication and write an applicability statement
>defining scenarios on which replication requirements are based.

The term "applicability statement" needs to be replaced
with "profiles" as the document to which the group writes
is not a Applicability Statement in the RFC 2026 sense.

The WG should consider whether it needs to write an true
Applicatibility Statements.  For example, it may be appropriate
for this WG to produce an Applicability Statement for use of
LDAP in Replicated Environments.

Kurt



From owner-ietf-ldup@mail.imc.org  Tue Nov 20 18:08:11 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10204
	for <ldup-archive@lists.ietf.org>; Tue, 20 Nov 2001 18:08:10 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAKMl9x27559
	for ietf-ldup-bks; Tue, 20 Nov 2001 14:47:09 -0800 (PST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKMkw827545
	for <ietf-ldup@imc.org>; Tue, 20 Nov 2001 14:46:59 -0800 (PST)
Received: from qsun.mt.att.com ([135.16.157.16])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id fAKMjLY05906;
	Tue, 20 Nov 2001 17:45:30 -0500 (EST)
Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2)
	id RAA26932; Tue, 20 Nov 2001 17:45:09 -0500
Date: Tue, 20 Nov 2001 17:45:09 -0500
Message-Id: <200111202245.RAA26932@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: internet-drafts@ietf.org
Subject: Revised LDUP "Profile" draft
Cc: ietf-ldup@imc.org
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


Internet Drafts Editor -

Please publish the ID below as draft-ietf-ldup-usage-profile-02.txt
(cut at the dotted line).

LDUPers -

The draft below is an updated version of the General Usage Profile.
Changes were mostly editing and clarification.  We expect there will be
a new version after the next revision of the architecture.

Please send comments to the list.

Rick Huber, et al

--- --- --- --- --- --- --- --- --- --- --- --- --- ---

Internet-Draft                                         Richard V. Huber
LDAP Duplication/Replication/Update                 Gerald F. Maziarski
Protocols WG                                          AT&T Laboratories
Intended Category: Informational                          Ryan D. Moats
Expires: May 2002                                        Lemur Networks
                                                          November 2001



              General Usage Profile for LDAPv3 Replication
                  draft-ietf-ldup-usage-profile-02.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 (2001). All Rights Reserved.


Abstract

Support for replication in LDAP directory systems is often one of the
key factors in the decision to deploy them.  But replication brings
design constraints along with its benefits.

We discuss some of the factors that should be taken into consideration
when designing a replicated directory system.  Both programming and
architectural/operational concerns are addressed.
Huber, et al               Expires May 2002                   [Page 1]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
Table of Contents
1 Introduction........................................................2
2 Meta-data Considerations............................................3
 2.1 Schema Considerations............................................3
 2.2 Replication Agreements...........................................4
 2.3 Access Control...................................................5
 2.4 Change Logs......................................................6
3 Naming Considerations...............................................6
4 Conflict Resolution Considerations..................................7
 4.1 Consistent Access after Changes..................................7
 4.2 Conflict Resolution in Single-Master Systems.....................8
 4.3 Problem Cases....................................................9
  4.3.1 Atomicity.....................................................9
    4.3.1.1 Locking...................................................9
    4.3.1.2 Partitioning..............................................9
 4.4 General Principles..............................................10
5 Failover Considerations............................................10
 5.1 Common Issues...................................................11
 5.2 Single Master Issues............................................11
 5.3 Multi-Master Issues.............................................12
6 Other Issues.......................................................13
 6.1 Locking.........................................................13
 6.2 Backup and Restore..............................................13
7 Impact of Non-LDAP Changes/Constraints.............................14
 7.1 Changes Outside of LDAP.........................................14
 7.2 Application Triggers............................................15
 7.3 Policy Conflicts Across Servers.................................15
8 Security Considerations............................................16
9 Acknowledgements...................................................16
10 References........................................................16
Authors' Addresses...................................................17
Full Copyright Statement.............................................18


1  Introduction

As LDAP directories become part of the critical infrastructure for
applications maintaining high reliability and availability is
significant.

Distributed, replicated directories can reduce reliability and capacity
problems.  However, applications that work well with a single,
standalone directory can develop problems in a distributed environment
unless both the applications and the environment are carefully
designed.


Huber, et al               Expires May 2002                   [Page 2]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
While particular areas of concern depend partly on whether the
distributed directory is a single-master or multi-master system most
concerns that are common to both.  This document flags some issues as
being specific to either single-master or multi-master directories.
Unflagged issues pertain to both.

The current replication framework provides no easily separable subset
of functions for single-master and multi-master replication, therefor
this addresses general issues regarding the deployment of single-master
and multi-master directory systems.  There may be additional drafts in
the future that address specific applications.


2  Meta-data Considerations

Any LDAP directory contains meta-data as well as the user data in the
directory.  Examples of this meta-data include descriptions of the data
in the directory (e.g. schema), policies for use of the data (e.g.
access controls), and configuration/status information (e.g.
replication agreements); this is not an exhaustive list.

This meta-data is stored in the directory itself, frequently accessible
as regular data or as operational attributes.  Issues arise when meta-
data stored in the directory is replicated.  However, not replicating
meta-data also causes issues to arise.


2.1  Schema Considerations

If the schema of one or more of the copies of a replica differs from
the schema of the other replicas, then there is a possibility of schema
mismatch when data is exchanged between them.  The schema extensibility
feature of LDAP nearly guarantees that replica groups comprised of a
heterogeneous mix of systems will not contain homogeneous schema
because of directory vendors' built-in extensions. A given directory
may not utilize all of the elements of its schema, so schema
differences do not always lead to schema mismatches during replication.

Schema mismatch issues are further complicated by the possibility of
replicating the "subschemaSubentry" itself.  Some directories
distribute schema changes through that mechanism.  Currently there is
no standard for LDAP schema representation within the
subschemaSubentry.  In the absence of such a standard, full schema
interoperability is not possible in the IETF sense.  Directory
designers should establish common schema on all servers holding a
replica.

Huber, et al               Expires May 2002                   [Page 3]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001

The following is a partial list of possible schema mismatches:

  1.  Object class not defined
  2.  Structure Rule of an object class
  3.  Structural vs. Auxiliary in an object class
  4.  Optional vs. Mandatory attribute in an object class
  5.  Object identifiers differ on an attribute type or on an object
      class
  6.  Type and number of attributes defined in a class
  7.  Attribute type not defined
  8.  Base syntax of an attribute type
  9.  Multi-valued vs. single-valued attribute types
 10.  Matching rule of an attribute type
 11.  Naming collisions of attribute type names
 12.  Attribute name aliasing ("street" vs. "streetAddress" vs.
      "Strasse")
 13.  ACL format (and consequently, ACL calculus) (Note: this is being
      addressed in the ACL model [ACLModel])

Schema mismatches that cause data corruption in one or more of the
replicas must result in meta-data (e.g. log entries) in order to comply
with Requirement P7 of [ReplicaReq].  However, not all schema
differences produce corruption in all circumstances.  Some schema
differences may have little or no impact on the proper storage of
replicated data.  However, any time data is added to the directory,
replication may result in data corruption due to a schema mismatch.

Here are some options for dealing with such potential mismatches:

  -  Use fractional replication to replicate only those attributes that
     do not have differences
  -  Removal of all schema mismatches.
  -  Use the same schema on all systems

The tool described by requirement AM8 of [ReplicaReq] would help
designers detect schema conflicts as early as possible.

2.2  Replication Agreements

Replication Agreements are central to replication, as they allow
configuration of most of the aspects of the replication process,
including the triggers for replica cycles (from Requirement M1 in
[ReplicaReq]), critical OID information (from Requirement M6 in
[ReplicaReq]), and replication process parameters (Requirement M7 in
[ReplicaReq]).  Through the use of a standard replication agreement

Huber, et al               Expires May 2002                   [Page 4]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
schema (Requirement SC2 of [ReplicaReq], [InfoMod]) it is possible to
replicate the replication agreement.

If a replication agreement includes replication credentials, the
agreement should be read protected in the directory and transport of
the replication agreement should be encrypted.

When replication agreements are themselves distributed via replication,
they are subject to same "loose consistency" problems (due to
replication delay and deferred conflict resolution) as other data.
Even a temporary inconsistency among replication agreements may cause
unbalanced replication and further inconsistency.  As "multi-mastering"
complicates "loose consistency" issues, avoidance of these issues by
making all replication agreement changes through the same master (see
Sections 4 and 5) is strongly advised.

2.3  Access Control

The following considerations complicate replication of Access Control
Information:

  -  Access Control Information (ACI) is treated as though it were
     stored as attributes in the directory [ACModel]
  -  LDAP [RFC2251] declares that changes resulting from a single LDAP
     MODIFY are atomic (but see caveats for multi-master replication in
     Sections 3 and 4)
  -  The ACI affecting a given entry may not be part of that entry (it
     could be part of a group entry or part of an ancestor of the entry
     in question)
  -  The ACI cannot always be changed atomically with associated data
     changes
  -  The interaction of replication and partitioning is still unclear
     (i.e. what happens when access control policy is inherited from an
     area of replication that is not held locally).
  -  Thus, if you aren't careful, you can leave windows where data is
     unprotected

To reduce risk:

  -  In all environments, access control changes should be made before
     adds and after deletes
  -  In multi-master environments, access control changes and the
     associated data changes should be made on same system.

Even when ACI is faithfully replicated (with the same transfer format)
among heterogeneous members of a replica group, there is no guarantee

Huber, et al               Expires May 2002                   [Page 5]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
that an ACI change is expressed similarly everywhere in the group.
This caveat is partly due to the open issues with respect to
partitioning mentioned above, and partly due to vendor differences with
regard to the expression of security policy.


2.4 Change Logs

Requirement G4 of [ReplicaReq] states that meta-data must not grow
without bound.  Since it is unrealistic to assume that meta-data won't
be needed during replication, designers must consider how and when
meta-data can be purged.

Replicas that use connections with intermittent quality should use
explicit replica cycle scheduling.  Since the systems know when
replication should have occurred, delayed replication can be detected
and manual intervention initiated before the meta-data grows without
bound.  In extreme cases, it may be necessary to remove a replica from
the replication group and restore it once better connectivity is
available.

In a multi-master system, it is possible for a consumer to receive
changes that cannot be applied.  For example, a modify request for an
entry may arrive before the add request that creates that entry.  The
replication system will typically queue this change and wait for
additional changes (see Section 3.3).

3  Naming Considerations

A number of naming models have been proposed for directories
([RFC1255], [RFC2377], [CIMNames]), and many others have been
implemented on an ad hoc basis.  Each of these models specifies the
naming attributes to be used and provides rules for using them which
may also include containment rules.

The naming plan applies to the directory as a whole, not the individual
servers holding replicas.  Therefore, in a heterogeneous replicated
environment, all of the replicating servers must be capable of
supporting all of the rules for the naming plan in use for that
directory.

Some directory implementations have naming constraints (e.g.
containment rules, restrictions on attributes that can be used for
naming).  If such an implementation is part of a replicated directory,
those constraints will have to be observed by all participating
directories.  If the environment contains implementations with

Huber, et al               Expires May 2002                   [Page 6]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
incompatible constraints there is a major problem.  This should be
checked as early in the design phase as possible.

Applications often have their own requirements on naming; in this case
the directory will have to support multiple naming schemes.  Thus, if
two independent applications start sharing previously separate
directory information, care should be taken that the naming is
consistent across the applications.   A difference in name form may be
accepted through LDUP without constraint violation, but nevertheless
result in unexpected behavior from a cross-application perspective.
Consistent naming is not only important to the directory, but to the
applications that consume directory information as well.

4  Conflict Resolution Considerations

4.1  Consistent Access after Changes

Many operations on a directory are done as a set of steps.  For
example, a new object may be created by one operation, and its values
may be filled in as part of a separate LDAP operation.  An
administrator may add a user to a directory, and that user may then try
to log in using the new entry.

Replicated LDAP directories provide loose consistency [ReplicaReq].  A
new entry or a change to an existing entry will not reach all replicas
immediately; there will be some delay before changes are available on
all replicas.  Changes made (e.g. adding a new user) on one physical
system may appear to be "lost" if checked on another physical system
before replication is complete.

In general, LDAP applications should be prepared to operate correctly
in the face of replication delays.  In some cases, this means designing
to allow for delay.  In the case of the newly created user, it should
be standard practice to ask the user to wait a while before trying to
use the entry.  In the case where the new object must be filled in, the
application should make appropriate use of LDAP sessions to make sure
that the same server is reached for both operations.

As a general rule, an LDAP application should bind once and not unbind
until a complete set of related operations have been performed. To
achieve load balancing of write operations in a multi-master
environment, balancing the write-enabled connections is recommended
over balancing LDAP write operations.

In the single-master case, all write requests go to one server.  If a
set of related reads and writes are done, they should all be done on

Huber, et al               Expires May 2002                   [Page 7]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
the master if possible.  Ideally, only sets of related operations that
cannot include a write should go to one of the slave servers.  But load
balancing concerns may make this impractical.

In some cases, related requests will deal with data in different
partitions that are not all available on a single server.  In this
case, it is safer to keep sessions open to all servers rather than
closing the session with one server and opening one with another
server.

It may not always be obvious to clients that they are using different
servers.  If a load distribution system is used between the client and
the server, the client may find that a change request and a subsequent
lookup are directed to different physical servers even though the
original requests were sent to the same server name and/or address.

Since LDAP is session oriented, any load distribution system used
should take sessions into account.  Thus, keeping all related read and
write requests within a single bind/unbind session should be the goal
in this situation as well.

4.2  Conflict Resolution in Single-Master Systems

It is possible that resolution conflicts could occur in a single master
replication system.  Because requirement SM2 of [ReplicaReq] is a
"SHOULD" and not a "MUST", it is possible for implementers to reorder
changes.  If changes are reordered, it is quite possible for a conflict
to occur.  Consider a case where schema changes are declared critical
and must be moved to the front of the replication queue.  Then the
consumer servers might have to delete an attribute that still has
values, and later process requests to delete the values of that
attribute.

However, directory administrators may have scenarios where re-ordering
of replication information is desirable.  On a case-by-case basis, the
directory administrator should make such decisions.

Many vendors may not implement conflict resolution for single-master
replication.  If such a system receives out-of-order changes from a
system that does support them, replication errors will almost certainly
occur.  Designers should be aware that mismatches in the capabilities
of replicating single-master directories could cause problems.  Designs
should not permit the master to re-order changes unless all slave
copies are known to handle the situation correctly.



Huber, et al               Expires May 2002                   [Page 8]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
4.3  Problem Cases

4.3.1  Atomicity

The fact that replication does not guarantee the time order arrival of
changes at a consumer allows situations where changes that were applied
successfully at the supplier may fail in part when an attempt is made
to apply the same change at the consumer. Examples appear below.

4.3.1.1  Locking

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
processes 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" But what
is the value of Z at the end of the replication cycle?  If it is 42,
then 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. Therefore, it is not clear when such information may be
safely discarded.  Thus, requirement G6 in [ReplicaReq] may be
violated.

The utility of locking mechanisms cannot be guaranteed with multi-
master replication, and therefore results are likely to be misleading.
As discussed further in section 6.1 below, its use in multi-master
environments should be deprecated.

4.3.1.2  Partitioning

Huber, et al               Expires May 2002                   [Page 9]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
Partitioning (design of replica groups) also adds complexity.  For
example, suppose two servers, A and B, are members of a replica-group
for area of replication X while servers B and C are members of replica-
group for area Y.  It is possible to issue a ModifyRDN operation on
server B that moves an entry from area X to area Y.  Replication in
area X would delete the entry on server A while replication in area Y
would add the entry to server C.  However, if another change on server
C prevented the add operation from working (e.g. an entry with the same
RDN but a different GUID exists there already), then the change on
server A is inconsistent and will need to be reversed.  Other examples
of cases of this class include group membership modification and access
control scoping.

4.4  General Principles

The examples above discuss some of the most difficult problems that can
arise in multi-master replication.  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.

5  Failover Considerations

One of the major reasons to use directory replication is to improve
reliability of the directory system as a whole.  Replication permits
hot- and warm-standby configurations to be built easily.

But there are some issues that must be considered during design.  In
this situation, single-master systems actually raise more concerns than
multi-master.  Both are addressed below.



Huber, et al               Expires May 2002                  [Page 10]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
5.1  Common Issues

In both the single- and multi-master cases, clients must be able to
find an alternate quickly when a server fails.  Some possible ways to
do this are detailed in [FindingLDAP] and [LDAPinDNS].  If all else
fails, a list of possible servers can be built into client
applications.  Designers should consider how clients are notified that
the server is again available.

When the failed server comes back up, it is brought back into
synchronization with the other servers and is ready to take requests.
It is always possible that the failed server, if it was acting as a
supplier, was unable to completely distribute its pending changes
before removal from service, leaving its consumers in an inconsistent
state.  During the period between its removal from service and its
eventual return, the inconsistency may have been compounded by further
application activity.  As there is no current automatic mechanism to
rectify the problem, the administrator should use whatever mechanism is
available to compare the replicas for consistency as soon after the
event as is reasonable.

Note that the process used to bring a failed server back into
replication can also be used to add a server to a set of replicating
servers.  In this case, the new server might be initialized from a
backed-up copy of the directory or it may acquire the entire DIB via
replication.  The former method is usually preferable when the
directory is large.

5.2  Single Master Issues

In a single-master system, the master is a single point of failure, as
all modification has to originate at the master server.  When high
availability is a requirement, a quick, automated failover process for
converting a slave replica to a new master is desirable, as the
failover time becomes a major factor in determining system
availability.  The considerations in section 5.1 apply here; clients
must know how to find the new master or a new slave in case of failure.

To aid in promotion of a slave replica, the master could replicate
control information and meta-data (including replication credentials)
so that this information is available during failover promotion.  This
data may either be replicated on a single "failover designate" slave
(which would become the master in during failover) or it could be
replicated to all slaves.  The first possibility has the advantage of
minimizing the amount of extra replication while the second more
robustly handles multiple failovers (i.e. failover of the newly
Huber, et al               Expires May 2002                  [Page 11]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
promoted master to another slave before the original master has been
restored).  If this method is followed, data privacy mechanisms should
be used to protect the replication session.

If data privacy mechanisms (e.g. encryption) are used to protect the
replication session, the new master must have the necessary key
information.  Further this key information should be independent of the
master that is using it (i.e. not tied to the IP address of the master
server).  If it is not independent, slave replicas could be pre-
configured with the keys for all possible masters to reduce failover
time.

Restoration of the failed or broken master can be handled in one of two
ways:

  -  It could join the replica group and function as a slave.
  -  It could join the replica group and negotiate with the new master
     to synchronize and then take over as master.

In either case, clients need a way to know that a new server is
available.  If the broken master is returned to service as a slave,
then the administrator must, external to LDUP, distribute and resolve
whatever pending changes remained undistributed and unresolved from the
time immediately before it was removed from service. If the broken
master is returned as a new master, then care must be taken with its
replacement master to ensure that all of its pending changes are
distributed and resolved before it is returned to duty as a slave.

The slave replicas may also use the replication agreement to filter
which master is allowed to submit changes.  Such a model allows the
slave servers to function correctly when the master server is "broken"
and sending out incorrect updates.  However, then it is necessary to
update the replication agreement during the fail over process so that
the slaves will accept updates from the new master.  This is the case
for both the original failure and the restoration of the restored
master if that is how the restored master rejoins the replica group.


5.3  Multi-Master Issues









Huber, et al               Expires May 2002                  [Page 12]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
Typically, a multi-master configuration is used when high availability
is required for writes as well as reads in the directory.   Because
there are multiple active servers prepared to take write requests,
there is no "switchover" time in this case.  But clients still need to
be able to find an alternate server, so the considerations of Section
5.1 apply here.
6  Other Issues

6.1  Locking

Section 4.3.1.1 discussed the problems that can arise when the "modify"
command in LDAP is used for locking in a multi-master environment.
There are more general principles at work there.  LDAP is a distributed
and replicated directory service that is typically described as
"loosely consistent".

In loose consistency, the data should eventually converge among the
replicas, but at any given instant, replicas may be in disagreement.
This stipulation is the general result of:

  1.  The delay due to replication or extended replication intervals
  2.  The out of natural time order arrival of data at a replica
  3.  The temporary isolation of distributed systems from one another
  4.  Failure to accept a change due to conflict resolution failure on
      a replica

Because of loose consistency, data preconditions to an LDAP operation
may differ among replicas.  Multi-mastering may exacerbate this
situation, but single-mastering will not totally eliminate it if out-
of-order replication is allowed (see Section 4.2).  One must carefully
assess the effect of loose consistency when evaluating operations that
place specific preconditions on data to work correctly.  Applications
which depend on such operations may be better suited for transactional
models and/or non-distributed data.

Distributed locking is one operation that depends on strict data
preconditions.  When data preconditions cannot be guaranteed, the lock
is moot.  The same principles hold for "atomic operations", defined
here as any mix of allowable operations contained within the same LDAP
PDU.  RFC2251 requires that they either all fail or are applied as a
unit.  If strict data preconditions cannot be guaranteed, then the
atomic operation may itself result in a further inconsistency requiring
human intervention at one of the consumers.

6.2  Backup and Restore

Backup of a directory server should have the following goals:
Huber, et al               Expires May 2002                  [Page 13]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001

  1.  It can be unambiguously and faithfully restored.
  2.  It is an internally consistent snapshot of an entire replica
      during the time interval it took to make it.  This can only be
      achieved if the server is quiescent.
  3.  Replication can resume on a machine restored from that backup
      without information loss.

Backup and restore of a single, operating directory server (rather than
the entire directory system) presents its own challenges. "Loose
consistency" works against the probability of achieving a loss-free
copy of all the data in the directory, except under ideal conditions.
Backup and restore of distributed directories is a decidedly easier
task when the constraint of continuous availability is removed.  In
most cases, the removal of entire directory systems from write service
is impossible, even for small periods of time.  It is more practical to
remove a single directory server from service to achieve a condition of
quiescence.  Once all write load is removed, including write load due
to replication, an internally consistent copy of the data may be
obtained.

Replicas that have suffered catastrophic data loss may be restored from
backups of working servers temporarily removed from service
specifically to make a copy.  This scenario illustrates the benefit of
having three or more replicas in the system: no single point of write
failure in the event that one of the replicas must be restored from a
copy of another.

The M11 requirement from [ReplicaReq] allows an empty replica to be
brought up to date through replication.  This feature duplicates, but
does not make entirely unnecessary, backup procedures on directory
servers. Backups are still needed to recover data that has been lost to
all replicas, either through normal LDAP updates or through some
catastrophic event.

7  Impact of Non-LDAP Changes/Constraints


7.1  Changes Outside of LDAP

LDAP directories are typically built on top of some database or file
system.  Thus there are ways to change the data that do not go through
the normal LDAP change mechanisms (e.g. ModifyRequest).  If the data is
modified outside of LDAP, the changes will not be checked for schema
conformance nor will access controls be checked as the changes are


Huber, et al               Expires May 2002                  [Page 14]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
made.  Since both integrity and security checks are omitted, security
can be adversely affected.

Also, many systems use the normal LDAP modification mechanisms to
trigger replication.  Changes made using non-LDAP mechanisms may not be
replicated at all, leading to inconsistencies between replica copies.

7.2  Application Triggers

Directory servers commonly integrate one or more specific applications.
To achieve this integration the directory server may intercept updates
and run application-specific "trigger" code.  Such triggers enforce
directory invariants that cannot be expressed by the LDAP schema.

A simple trigger example is password policy enforcement. A directory
server might interpret a request to replace the current value of the
userPassword attribute with some new value as a request to first check
that the new value conforms to the server's password policy (e.g. the
value is sufficiently long and complex) before storing the new value.
Using this trigger the directory server voids the security risk
associated with passwords that are easy to attack.

A more complex trigger example is password hashing.  A directory server
might interpret a request to replace the current value of the
userPassword attribute with some new value as a request to compute one
or more secure hashes of the new value and store these hashes in one or
more attributes, storing no value in the userPassword attribute.  Using
this trigger the directory server avoids the security exposure of
storing the plaintext password.

Replication between directory servers with different application
triggers will compromise directory integrity.

7.3  Policy Conflicts Across Servers

In addition to the discussions of ACI in Section 2.3 and triggering in
section 7.2, LDUP replication can not (by its definition) handle
replication of information that makes use of policy not expressible in
the LDAP protocol.  A prime example of this is security encoding of
attributes (e.g. userPassword).  This encoding is typically
implementation specific and is not easily expressible via the LDAP
protocol.  Therefore replication of userPassword attributes between
directory servers that use different encoding schemes will impede
replication in a way that is not describable as schema or syntax
mismatch.  This is because of the bind-time policy semantics that are
the true point of conflict.

Huber, et al               Expires May 2002                  [Page 15]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001

Another case arises from the use of authentication levels in the Access
Control Model [ACModel].  The authentication levels represent the
strength of various forms of authentication rather than specific
authentication mechanisms; the association between levels and
mechanisms is left for administrators though some guidance may be
provided [AuthMap].  In a replicated environment, administrators must
be sure that the mappings of all replicating systems are compatible.
If they are not compatible, access controls may have different effects
on different replicas of a partition.

In general, any attribute with semantics that are outside the scope of
what is expressible by the LDAP protocol could result in strange
replication errors.  Therefore, distributed directory implementers
should (in the absence of a way to express such semantics) either
strive for a homogeneous set of servers or ensure during acceptance
testing that a new server can support the existing semantics of their
directory.

8  Security Considerations

The document discusses issues that arise in replication.  Some of these
issues are security related (e.g. replication of access control
information) and the security implications are discussed in the
relevant sections.

9  Acknowledgements

This document owes a lot to discussions on the LDUP mailing list.  In
particular, the authors would like to thank Ed Reed, whose email to the
mailing list drove much of section 6.1, and Mark Brown for identifying
and generating text on the issues discussed in section 7.

10  References

[ACModel]  E. Stokes, R. Blakeley, R. Byrne, R. Huber, D. Rinkevich,
"Access Control Model for LDAPv3", Internet Draft, draft-ietf-ldapext-
acl-model-08.txt, June 2001.

[AuthMap]  K. Zeilenga, "Authentication Mechanisms Levels", Internet
Draft, draft-zeilenga-auth-lvl-01.txt, April 2001.

[CIMNames]  Desktop Management Task Force, "Guidelines for CIM-to-LDAP
Directory Mappings", DMTF Specification DSP0100, May 2000 (available
online at http://www.dmtf.org/spec/DEN/DSP0100.htm).


Huber, et al               Expires May 2002                  [Page 16]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
[FindingLDAP]  R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP
Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap-
taxonomy-05.txt, July 2001.

[InfoMod]  E. Reed, T. Hahn, "LDUP Replication Information Model",
Internet Draft, draft-ietf-ldup-infomod-03.txt, July 2001.

[LDAPinDNS]  M. Armijo, L. Esibov, P. Leach, R. L. Morgan, "Discovering
LDAP Services with DNS", Internet Draft, draft-ietf-ldapext-locate-
05.txt, March 2001.

[ReplicaReq]  E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3
Replication Requirements", Internet Draft, draft-ietf-ldup-replica-req-
08.txt, March 2001.

[RFC1255]  The North American Directory Forum, "A Naming Scheme for
c=US", RFC 1255, September 1991.

[RFC2251]  M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", RFC 2251, December 1997.

[RFC2377]  A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan
for Internet Directory-Enabled Applications", RFC 2377, September 1998.


Authors' Addresses

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

Gerald F. Maziarski
Room C3-3Z01
AT&T Laboratories
200 Laurel Avenue South
Middletown, NJ  07748
USA
E-Mail: gfm@att.com
Telephone: +1 732 420 2162
Fax: +1 732 368 1690

Huber, et al               Expires May 2002                  [Page 17]



INTERNET DRAFT Gen'l Usage Profile for LDAP Replication   November 2001
Ryan D. Moats
Lemur Networks
15621 Drexel Circle
Omaha, NE  68135
USA
E-Mail: rmoats@lemurnetworks.net
Telephone: +1 402 894 9456

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
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.









Huber, et al               Expires May 2002                  [Page 18]


From owner-ietf-ldup@mail.imc.org  Tue Nov 20 23:30:24 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17877
	for <ldup-archive@lists.ietf.org>; Tue, 20 Nov 2001 23:30:24 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAL4Atl07612
	for ietf-ldup-bks; Tue, 20 Nov 2001 20:10:55 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAL4Aq807604
	for <ietf-ldup@imc.org>; Tue, 20 Nov 2001 20:10:52 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAL4GUC78435;
	Wed, 21 Nov 2001 04:16:30 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011120200849.017457d0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 20 Nov 2001 20:10:22 -0800
To: "Chris Apple" <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: applicability statement (Re: revised WG charter proposal)
Cc: <ietf-ldup@imc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 09:21 AM 2001-11-16, Chris Apple wrote:
>The WG's approach is to first develop a set of requirements for
>LDAPv3 directory replication and write an applicability statement
>defining scenarios on which replication requirements are based.

And why do we need this when the requirements document contains
an appendix detailing usage scenarios from which the requirements
are based?



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 13:24:09 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28480
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 13:24:09 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fALI5Yk11515
	for ietf-ldup-bks; Wed, 21 Nov 2001 10:05:34 -0800 (PST)
Received: from ARKMAIL.arkivio.com ([66.120.211.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fALI5X811510
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 10:05:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C172B6.7DA8EAC7"
Date: Wed, 21 Nov 2001 10:01:06 -0800
content-class: urn:content-classes:message
Message-ID: <513C6DDEB3949D4BB43097D0BF18654F07617D@ARKMAIL.arkivio.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFytn49Rj5gB1InQYKksrS4LU/WeA==
From: "Bruce Greenblatt" <bruce@arkivio.com>
To: <ietf-ldup@imc.org>
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C172B6.7DA8EAC7
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Paul Leach wrote...

> I vote for starting another WG on ACM, or letting individuals do it.
And
> note that WGs can technically review things even if individuals
propose
> them.
>=20
> Paul

I'm arguably a little late into the thread.  I mostly agree with Paul,
except that I would like to see it done as a BOF.  If the work can't be
completed in the next two meetings, then there isn't much point. If the
current model is pretty much on target, then it should only take a
little more work.  If the current model is way off target, then it will
never get finished.  So, I would prefer that LDAP ACM not be added to
LDUP, and instead it should be considered by a separate WG or BOF
session.

Bruce

=20
=20

------_=_NextPart_001_01C172B6.7DA8EAC7
Content-Type: text/x-vcard;
	name="Bruce Greenblatt (bruce@arkivio.com).vcf"
Content-Description: Bruce Greenblatt (bruce@arkivio.com).vcf
Content-Disposition: attachment;
	filename="Bruce Greenblatt (bruce@arkivio.com).vcf"
Content-Transfer-Encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkdyZWVuYmxhdHQ7QnJ1Y2UNCkZOOkJydWNlIEdy
ZWVuYmxhdHQNCk9SRzpBcmtpdmlvDQpUSVRMRTpQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIN
ClRFTDtXT1JLO1ZPSUNFOisxICg2NTApIDIzNy02MTIxDQpFTUFJTDtQUkVGO0lOVEVSTkVUOmJy
dWNlQGFya2l2aW8uY29tDQpSRVY6MjAwMTEwMDRUMjEyMDQ1Wg0KRU5EOlZDQVJEDQo=

------_=_NextPart_001_01C172B6.7DA8EAC7--


From owner-ietf-ldup@mail.imc.org  Wed Nov 21 14:15:51 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00470
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 14:15:49 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fALIxWS13970
	for ietf-ldup-bks; Wed, 21 Nov 2001 10:59:32 -0800 (PST)
Received: from ARKMAIL.arkivio.com ([66.120.211.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fALIxW813966
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 10:59:32 -0800 (PST)
Subject: Re: Adding to the LDAP ACM to a WG charter
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Wed, 21 Nov 2001 10:55:09 -0800
Message-ID: <513C6DDEB3949D4BB43097D0BF18654F076189@ARKMAIL.arkivio.com>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: Adding to the LDAP ACM to a WG charter
Thread-Index: AcFytn49Rj5gB1InQYKksrS4LU/WeAAB3FPw
From: "Bruce Greenblatt" <bruce@arkivio.com>
To: <ietf-ldup@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fALIxW813967
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


I guess that if the message had included a subject, that would have been
helpful...

> -----Original Message-----
> From: Bruce Greenblatt 
> Sent: Wednesday, November 21, 2001 10:01 AM
> To: ietf-ldup@imc.org
> Subject: 
> 
> 
> Paul Leach wrote...
> 
> > I vote for starting another WG on ACM, or letting individuals do it.
> And
> > note that WGs can technically review things even if individuals
> propose
> > them.
> > 
> > Paul
> 
> I'm arguably a little late into the thread.  I mostly agree 
> with Paul, except that I would like to see it done as a BOF.  
> If the work can't be completed in the next two meetings, then 
> there isn't much point. If the current model is pretty much 
> on target, then it should only take a little more work.  If 
> the current model is way off target, then it will never get 
> finished.  So, I would prefer that LDAP ACM not be added to 
> LDUP, and instead it should be considered by a separate WG or 
> BOF session.
> 
> Bruce
> 
>  
>  
> 


From owner-ietf-ldup@mail.imc.org  Wed Nov 21 17:05:38 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10492
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 17:05:38 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fALLmV322420
	for ietf-ldup-bks; Wed, 21 Nov 2001 13:48:31 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fALLmT822415
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 13:48:29 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fALLsBC83108
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 21:54:11 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 21 Nov 2001 13:47:25 -0800
To: ietf-ldup@imc.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: LDAP Requirements comments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


In trying to understand where this WG is going, I recently
re-reading the LDAP Requirements. I came across a few issues
which likely should be fixed before this document is progressed
further.  While most editorial in nature, a couple are technical
(and substantive) in nature.  In particular, I suggest that
the current security consideration section be replaced.

Section 2:
  Anonymous Replication - Replication where the endpoints are
  identified to each other but not authenticated. 

I suggest "Anonymous Replication" be replaced with "Unauthenticated Replication" as an endpoint which is identified is not anonymous. 

  Area of Replication
And every use of "replication area", except the note in the
"Area of Replication" definition, should be changed to "Area
of Replication". 

  Sparse Replication - The capability to filter some subset
  of entries (other than a complete collection) of a
  replication base entry for replication.

likely should be:
  Sparse Replication - The capability to filter some subset
  of entries (other than a complete collection) of a
  Area of Replication.


  Multi-Master Replication - A replication model where entries
  can be written and updated on any of several master replica
  copies without requiring communication with other master
  replicas before the write or update is performed. 

By this definition, multi-master replication with Transactional
data consistency is not multi-master replication.  Suggest:
  Multi-Master Replication - A replication model that assumes
  multiple servers, each a master, allow LDAP write access to
  the replicated data.

  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. 

I suggest s/may/can/ in both instances.  I also note that there
likely should be an explicit requirement that LDUP support
multi-master systems with slave replicas.

Section 3, pp 1.  s/must/is intended to/
(I view Models part of Section 3 as providing definition
of terms, likely more appropriately done in section 2.)
Section 3, Model 3, s/may/are allowed to/
Section 3, Model 4, s/may not be/is not necessarily/ 

In pp starting with "Consistency models..." s/may/can/

  Models 4 and 5 involve unregistered replicas that "pull"
  updates from another directory server without that
  server's knowledge.

Assuming LDAP as the access protocol, an unregistered
replica cannot "pull" updates from a server without that
server's knowledge. 
  These models violate a directory's security policies.

How?  An "unregistered" replica can enforce security policies
just as well as a "registered" replica.

In pp starting with "Models 2 and 3 illustrate", s/must/are/.

In pp starting with "Interoperability among ...", s/may/can/.

In last pp of Section 3, suggest replace:
  specified by the LDAP core documents (RFC 2251-2256, 2829, 2830).
with:
  defined in the LDAP Technical Specification [LDAPTS].
(LDAPTS == draft-ietf-ldapbis-ts-00.txt). And replace:
  "core" specifications 
with:
  LDAP Technical Specification
and likewise in G8.

In "may be limited", s/may/can/
  Use of applicability statements to improve interoperability
  in particular application spaces is RECOMMENDED. 

LDAP Replication is one such application where an applicability
statement upon LDAP will be REQUIRED to obtain interoperability.

In G3, G4, and elsewhere the phase "LDAP Replication Standard"
should be replaced with "LDAP Replication" (and LDAP Replication
should not be written with a capital R).  Also, all occurrences
of the adjective "standard" should likely be stricken (or
replaced with the word "common").

  G7. All policy and state data pertaining to replication MUST
  be accessible via LDAP. 

All?  This needs to be constrained to the subset of policy and
state information necessary to effectively administrate LDAP
Replication.

G9 states two distinct requirements.  Should be separated into
two.  (I note my previously stated opinion that the second G9
requirement is inappropriate and should be stricken).

M1 g).  I suggest "manual request" be an LDAP request.

AM7. and LDAP replication MUST prevent the establishment of
a 'blank' (or partially synced) replica from blanking (or
partially syncing) other replicas.

Suggest:
  AM8. Vendors SHOULD provide tools to audit schema compatibility
  within a potential replica-group.
be replaced with:
  AM8. Administrative tool creating new replicas SHOULD detect
  LDAP Replication SHOULD detect schema incompatibilities prior
  to instantiating a replication agreement.

S6/S7:  s/privacy/confidentiality/


Security considerations:
  As noted in Section 3, interoperability may be impacted when
  replicating among servers that implement non-standard extensions
  to basic LDAP semantics. 
This doesn't grasp the follow extent of the interoperability issue
impacting security.   And:
   Since LDAPv3 access control is a set of standards-based
   extensions
LDAPv3 access control is not yet defined.  It may never be.

Anyways, I suggest replacing the paragraph with:
  This document includes security requirements (listed in
  section 4.8 above) for the replication model and protocol.
  As noted in Section 3, interoperability may be impacted when
  replicating amount servers which implement different elective
  features of LDAP.  Hence, security (and general interoperability)
  will be significantly impacted by the degree of consistency
  with which LDAP implementations support elective features of
  LDAP.  This can be mitigated by requiring each implementation
  in a replicated environment implement, in a consistent manner,
  the same set of elective features.

Lastly, the document should be updated according to the (proposed)
RFC policy <http://www.rfc-editor.org/policy.html>.  In particular,
the abstract should be shorter and the normative and informative
references distinguished.

Kurt



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 17:48:45 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11981
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 17:48:45 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fALMXc126346
	for ietf-ldup-bks; Wed, 21 Nov 2001 14:33:38 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fALMXb826342
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 14:33:37 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fALMdJC83275
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 22:39:19 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011121142515.01765088@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 21 Nov 2001 14:33:07 -0800
To: ietf-ldup@imc.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: LDAP Requirements comments
In-Reply-To: <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 01:47 PM 2001-11-21, Kurt D. Zeilenga wrote:
>Lastly, the document should be updated according to the (proposed)
>RFC policy <http://www.rfc-editor.org/policy.html>.  In particular,
>the abstract should be shorter and the normative and informative
>references distinguished.

Whoops.  The length of this document's abstract is fine,
just the reference to [RFC2251] should be removed and
the mnemonic LDAPv3 spelled out.  Sorry, I hit the send
button a little too fast.

Kurt



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 19:10:41 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14081
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:10:41 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fALNsbu01331
	for ietf-ldup-bks; Wed, 21 Nov 2001 15:54:37 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fALNsZ801327
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 15:54:36 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Wed, 21 Nov 2001 18:47:30 -0700
Message-Id: <sbfbf6c2.051@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 21 Nov 2001 18:47:18 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <ietf-ldup@imc.org>, <Kurt@OpenLDAP.org>
Subject: Re: LDAP Requirements comments
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 above.proper.com id fALNsa801328
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit




=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/21/01 04:47PM >>>

...

  Multi-Master Replication - A replication model where entries
  can be written and updated on any of several master replica
  copies without requiring communication with other master
  replicas before the write or update is performed. 

By this definition, multi-master replication with Transactional
data consistency is not multi-master replication.  Suggest:
  Multi-Master Replication - A replication model that assumes
  multiple servers, each a master, allow LDAP write access to
  the replicated data.

  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. 

I suggest s/may/can/ in both instances.  I also note that there
likely should be an explicit requirement that LDUP support
multi-master systems with slave replicas.

....

<eer> I'd argue that, indeed, transactional data consistency
among multiple DSA instances holding a replica of a the same
area of replication is, infact, not a subject of multi-master
replication, but rather a characteristic of a single master
replica, which happens to be transactionally spread among
several servers.  To the rest of the LDUP world, the entire
set of servers cooperating in maintaining the transactional
replica should be treated as just that - a single replica with
possibly several different network addresses by which it 
can be reached.

That approach leaves the entire question of how the transactions
are defined, how they're propagated, how they are rolled back, and
how they interoperate with LDUP supporting servers as a local matter,
and is entirely outside the scope of LDUP.

To be absolutely clear:  I'd like to leave transactions entirely out of
LDUP, and to use a perspective like the one I've outlined above as
the way of viewing transaction-supporting servers.

Why?  Because by their very definition, talking to any one DSA server
participating in the transactionally consistent support of a replica
is just like talking to any other DSA of the transactional set.  Other
that each DSA may be holding different sets of other replication and
so have different characteristics when it comes to handling cross-area
moves of entries, and a different set of external references to
manage.  Those differences may yield different performance
characteristics, but because they're bound to all the other DSAs in
the transaction set of servers they still behave the same from the
perspective of any other LDUP replica of the area of replication.

So - I would prefer to keep the current definition of the Master Replica
insofar as this aspect of the definition is concerned, because it
explicitly encodes our operating assumption - that there is no requirement
for communication with other master replicas before the write or
update is performed.

W/R/T the slave definition, I think it specifically does make clear that
slave replicas may occur in multi-master systems.  I have no problem with
adding a requirement to support the notion, as that is implicit in my own
thinking.

</eer>



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 19:20:57 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14272
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:20:56 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM06Eb02174
	for ietf-ldup-bks; Wed, 21 Nov 2001 16:06:14 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM06C802170
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 16:06:12 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Wed, 21 Nov 2001 18:59:06 -0700
Message-Id: <sbfbf97a.053@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 21 Nov 2001 18:59:02 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <ietf-ldup@imc.org>, <Kurt@OpenLDAP.org>
Subject: Re: LDAP Requirements comments
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 above.proper.com id fAM06D802171
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit




=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/21/01 04:47PM >>>
...

  Models 4 and 5 involve unregistered replicas that "pull"
  updates from another directory server without that
  server's knowledge.

Assuming LDAP as the access protocol, an unregistered
replica cannot "pull" updates from a server without that
server's knowledge. 

<eer>
A couple of points - 

1) if it were so easy for a server to know that an unregistered
replica is pulling updates from it, then data mining for
spam addresses, etc. would be easy. Spam and web-crawlers
have demonstrated that it's not.

2) I don't expect LDUP to support these models at all, and look to
things like LCUP as potential solutions.  LDUP depends on knowing
that updates have reached all (registered) replicas in order to
govern each server's own change log truncation / garbage collection.

</eer>

  These models violate a directory's security policies.

How?  An "unregistered" replica can enforce security policies
just as well as a "registered" replica.

<eer>
 
But, they can also choose not to, and if the data owner doesn't know
who is replicating the data, they're certainly not likely to rely on the
unknown recipients to be "honor bound" to handle the data
appropriately.

No, the very notion that ACM policy would allow an unknown
and unregistered DSA to receive sensitive data subject to 
the ACM policy seems outlandish.

At the very least, sensitive data can only be shared with those
who will be accountable for its protection, and who will protect
it according to the data policies established by the data owners.

See innumerable rants about personal privacy for corroborating
arguments.

</eer>



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 19:29:19 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14464
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:29:18 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAM0BRb02600
	for ietf-ldup-bks; Wed, 21 Nov 2001 16:11:27 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM0BP802592
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 16:11:25 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Wed, 21 Nov 2001 19:04:21 -0700
Message-Id: <sbfbfab5.055@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 21 Nov 2001 19:04:16 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <ietf-ldup@imc.org>, <Kurt@OpenLDAP.org>
Subject: Re: LDAP Requirements comments
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 above.proper.com id fAM0BQ802595
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit




=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/21/01 04:47PM >>>
...
  G7. All policy and state data pertaining to replication MUST
  be accessible via LDAP. 

All?  This needs to be constrained to the subset of policy and
state information necessary to effectively administrate LDAP
Replication.

<eer>  Why?  From the perspective of the protocol we're
designing, what policy and state data should be excluded from
access via LDAP?  None that I can think of, and I think it is
a desireable goal that it all be available, to the extent
that LDAP is able to access the data elements, that is - for
instance, authentication credentials, either derived or
passwords that are not normally accessible via LDAP
shouldn't be accessible via LDAP (!), so I guess I'd
agree to some <mumble> along those lines...but are
you thinking of something else I should be aware of?

</eer>



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 19:39:59 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14727
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:39:58 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM0NXA03759
	for ietf-ldup-bks; Wed, 21 Nov 2001 16:23:33 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM0NW803754
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 16:23:32 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Wed, 21 Nov 2001 19:16:28 -0700
Message-Id: <sbfbfd8c.057@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 21 Nov 2001 19:16:18 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <ietf-ldup@imc.org>, <Kurt@OpenLDAP.org>
Subject: Re: LDAP Requirements comments
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 above.proper.com id fAM0NX803756
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit




=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/21/01 04:47PM >>>
...

G9 states two distinct requirements.  Should be separated into
two.  (I note my previously stated opinion that the second G9
requirement is inappropriate and should be stricken).

<eer> 
Agreed.  Also, in doing the coverage matrix, the same is true of
G8 (each bullet is a separate requirement), M1, M5, and MM5.

</eer>

M1 g).  I suggest "manual request" be an LDAP request.

<eer>
I'm undecided on that, and believe that the requirement doc
should be silent on the implementation method to be proposed.
</eer>

AM7. and LDAP replication MUST prevent the establishment of
a 'blank' (or partially synced) replica from blanking (or
partially syncing) other replicas.

<eer>
That would be an additional requirement, which I would support.
</eer>

Suggest:
  AM8. Vendors SHOULD provide tools to audit schema compatibility
  within a potential replica-group.
be replaced with:
  AM8. Administrative tool creating new replicas SHOULD detect
  LDAP Replication SHOULD detect schema incompatibilities prior
  to instantiating a replication agreement.

<eer> agree, after some necessary wordsmithing of some
unnecessary redundant unnecessary something...
SHOULD...SHOULD should be clarified ...
</eer>



S6/S7:  s/privacy/confidentiality/

<eer>
Agree - the whole privacy thing scares the willies out of me, and
I don't much care what other document/workgroup/whitepaper
has defined definitions...the requirements can assert the
need to support confidentiality (ie, encryption of data in transit)
but not privacy.
</eer>

Security considerations:
  As noted in Section 3, interoperability may be impacted when
  replicating among servers that implement non-standard extensions
  to basic LDAP semantics. 
This doesn't grasp the follow extent of the interoperability issue
impacting security.   And:
   Since LDAPv3 access control is a set of standards-based
   extensions
LDAPv3 access control is not yet defined.  It may never be.

Anyways, I suggest replacing the paragraph with:
  This document includes security requirements (listed in
  section 4.8 above) for the replication model and protocol.
  As noted in Section 3, interoperability may be impacted when
  replicating amount servers which implement different elective
  features of LDAP.  Hence, security (and general interoperability)
  will be significantly impacted by the degree of consistency
  with which LDAP implementations support elective features of
  LDAP.  This can be mitigated by requiring each implementation
  in a replicated environment implement, in a consistent manner,
  the same set of elective features.

<eer>
Concur.  I'd go a bit further and explicitly warn that LDUP may
really screw up data subject to side effects of LDAP operations,
perhaps by listening for change and addition events on the
server to increment counters or do other things in external data
repositories.
</eer>




From owner-ietf-ldup@mail.imc.org  Wed Nov 21 19:46:01 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14861
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:46:00 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM0Ul604001
	for ietf-ldup-bks; Wed, 21 Nov 2001 16:30:47 -0800 (PST)
Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM0Uk803997
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 16:30:46 -0800 (PST)
Received: from RMINC_DOM-MTA by smtp.oncalldba.com
	with Novell_GroupWise; Wed, 21 Nov 2001 19:23:42 -0700
Message-Id: <sbfbff3e.059@smtp.oncalldba.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 21 Nov 2001 19:23:21 -0700
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <ietf-ldup@imc.org>
Subject: Coverage matrix - Requirements vs Model (Architecture) -06.txt
	version
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_702ABABE.A0C1AC77"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_702ABABE.A0C1AC77
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

For better or worse, here is my take on how the current Model document =
addresses the current Requirements document requirements.

I've highlighted comments for requirements not addressed or explicitly =
broken, in a bold type font.

The version of this document that I'm distributing is an Acrobat PDF file. =
 Free readers are available for as many OS platforms as I think are likely =
to be needed from www.adobe.com.

The -06 Model document requires more work.  But I also think that some of =
the directions that the Requirments authors have taken will prove =
troublesome to the management operations document authors.  We'll see.

Ed

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585


--=_702ABABE.A0C1AC77
Content-Type: application/pdf; name="ldup requirements coverage - 01.PDF"
Content-Disposition: attachment; filename="ldup requirements coverage - 01.PDF"
Content-Transfer-Encoding: base64

JVBERi0xLjIgDSXi48/TDQogDTEwIDAgb2JqDTw8DS9MZW5ndGggMTEgMCBSDS9GaWx0ZXIgL0Zs
YXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJlVfbjts2EP0C/wPRlybFWhEvuj0m3aQpkFu7DvKyL7JE
20xkyRGpddyv7/BmUWt5kSCLQBbJ4cyZM2dGr1aLhEWYoCRNo5QhtLpdxEj/67do8eJNjIqoSOH1
ZrGMoxgnOTxXCB7jtIDHI3r2L+f1DeIKlU30HK2+wvklJhHVp27NTvNYIWOAJP7U90H0fM9bJdGf
3QPvyy03x0mWaocwjow79hgb703cve9uP39CEzMv27I5SSGNGZrkEYEDRTpasX7E9jzGLwj8xTE2
+1+vFt/RIkmjBMAgWZTniLIoRxhMENRztENfUIsWr1Z+EwWTDjFwK8PGuA/M2/wnPIGzKM39CcYy
e0I7b7YzEkeEaVchfu30izd4xF8HQIk9UvflRi0FV5tlUw+H5b6rebOM00j9sKaW3hZhUepsxRNb
cU7GrGQWkr9whFCARpFGGbgd0wigoymOknQOD78tiYx/t4YqcULP9i0DTM5e6pwdGlGVSnQtev/5
boXkcDh0vUImCokIun/2+gFAGcoGqNFCRhVvq9P9c1S2NaKw/E7sheI1mqJs/WAFcUk3fhDqmYMZ
tl683mz0dfN3WPLkJrfxSJ08PROwcGjd8crEQAHhZWgEvTeBTBOBaeK5eA194tFncARNaygJ9vs4
LtC8e/vx87tb9OHjCh16XjVDzc/gQsgWYIQBwFVftrI0/gMAl2VrssaCDDJXt9N8iBapHUebQQ2O
8g45DOVLwvrFY/3Sn4PPgxFHSZLlYeV+scjq5JoCtNnFzkOhdt2gZmLSl5NAivyBb213FO0WHXel
AmIHgjKD0uoPZFl1vpgUl9Cgo2gab+sGHTmqyvZ3hWR5AsCERPAXmsNnksY+uZXWRF4DCm+7I4fn
GwN1OUB4vURr3gh4C+/AaViAggwNxmk+5o44k3BpibZdV6NqV7aVOwx/DS+lsYKabrtcl9KXFlgz
BpIANWaN7bk2IuQe1VxWvVjDGUeHsq92UJ6VJoVFYv3Iu2xMG3XolesGHOr0Vv4DQKzBHvz09O0D
mnebUKQY9IsM5CkrtDwRYvIN9ANqTFTK78uxVgkv2yyoK+pwUpO0ixZKZ29uHikZExIUh7GniclR
3aFdCXnphh6eh7WSj0TKu5EWjpdOpcgoU9QjonlsAF2LRqiTDrxsT0iqUnGXphCXecpn2Rhh6nRY
VjuguMYX/JWdplY3bHfRRe+wSF1VLDrXLygjEfRr3YCf6heUMT9xLOOLKjba1l9qmwF3L1qx16nZ
HyBNCFbXndoZqOQJKnBvGkXL1bHrv802CUpJRMZWnITycuC9yThUyAzNbHA4T/SvmeDO+87R6bDi
oIIKNhVADClDf7eVVR0I6/OhhgRb9dnw/gqBxghswbtp4lPfqa7qmmkqoXfnT2aSTXrP2PiA6CPP
U7d7BUBfNh8FoJd9HXahRvdpk5cwlUF9oR4iDRsHzaI4H2/HRVBl9vIPHQiMEhtRCcCqAtEFe0LL
dQmJkAdewdpUOGcLA6ejbWLmWqO6rRz2HAQWak0EORlMTuwdQBAISz0SySxANfVK0kHg4J+oLArt
sF9DQsG2FPuhAcR4N8jLIvY6OTdDSS4lbJSuvejOpTHWN1VcQHV4V+EVjn6RBsmVEcQmI8hF8YgJ
YQjySSZI8R+3SqbBLPXjT4hY0LdTVz8w0JT+6DyFDGfHk5bLv0ShlWln1sufmZJcjsKA7p/9Fv6E
2xQ0uN98s6y7atAcg2lqknoSoJ3m5wZe841obWuETlkac2I7aBZJ6DY9N9hqw5MGPjP23MJoUqmu
P4H2nDsciA5YuAeScTQOaMn980dEyliEnx5m06eYlAS0dkx6z1W5BOLqkJoGroYg1ycTyQXBxtnD
fD9ofm377gizxrXZz7o2mSKhu7b1pcBjaBDQjAlmEWMo16/m9B0Xuf2wWjz+SIvzoOFm6SOtx6D1
n4Z+q8v2TvfxEH2A7EOn+Lzgu5ZzcaVBMQ60zNemme7Ggc52Ron2A8x6esoyPC+b5hTilbNzVgs2
xpG7meRBbEUDbL0xHXYP4+xaf2Ksv/LKaFDNW11Svloc/WjAD+JVrH8QMIKWSpXVN2lHUZBbjYhO
7pbbMSe0g+mILCGOxhCgATMY09AGxlmQWbDZam2E2TucQE0RTBo+5AOq3aOeJFo/EkuAFPo4fHsZ
1gMPNm6V5YUeI66s0oTqVF1bJYWWqSurJM30m2urcfKEVzDB6pngYrVgkV1k9iWLs8gtMahkyPn8
YloUQPL5tQQUgKCE5pG+0Hzbxvq/YBFTMx6Z1yzO9T2Xqxdn9aVPHIaCoDnV6kNdCeh6iCcliNko
MIQ66mLNyswn+X/PevMBDWVuZHN0cmVhbQ1lbmRvYmoNMTEgMCBvYmoNMTc2MA1lbmRvYmoNNCAw
IG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwN
L0YwIDYgMCBSIA0vRjEgOCAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAxMCAw
IFINPj4NZW5kb2JqDTEzIDAgb2JqDTw8DS9MZW5ndGggMTQgMCBSDS9GaWx0ZXIgL0ZsYXRlRGVj
b2RlIA0+Pg1zdHJlYW0NCkiJzVfbcts4Ev0C/wPKT8mWxRA3XmqfPJG966r4Mpa8+zCeB5iEJO7Q
pIakrPHfbwMgCMgi7WRrtmoqKUURgEbj9OnT3T8tTzgLMEE8ioKIIbScn4RI/WnW6OTLZYjSII3g
59XJLAxCzBP4niH4GkYpfN2jT/dS5mdIdkiUwWe0/A+cn2ESUHVqrnfqrxnSBgi3p37fFY18llXX
oq/1i2zEWurjJI6UQxgH2h1zjLl7eX/vt/nDHTowc16J8rUtWm2G8iQgcCCNnBXjR2jOY/yFwN8w
xHr/xfLkd3TCo4ADGCQOkgRRFiQIgwmCGok26N+oQic/Le0mCiZ7xMCtGGvj9mHW5s/+CRwHUWJP
MBabE8p5vZ2RMCBMuQrvV05/ucQOf/UASsyRvBGrblbIbjUr89129lznspyFUdD90dmbOQ/CBO5k
AWMoYkx5oO3DW1YnqXqbWuSR+ZWwYY3FsMimVqM0DaKpxeGtDCeBeeoBiRRSCXF0iE0s/hEHCBkM
QhW1o5BZgGHveVmibV0W2SsSVY7aTnQS5aITaCubThRVUa1RV4M/W9gkuqKu0PXDYomeJBJZJtu2
eColeikE+jY/vzNkSXQs4d3Yo0tMh8sTZi6/MxcX1apuno3tokXiRRSl8K2ix0+tlGg8HzhzADBi
DLcy09Y4mqErz/q1iuyZfukvVzeXt9e3818fP1u0DGkZZEwcIQYpDBEnRF8G+ROyQ94O+xIVLxUb
7QLmwzNJZLPTYWcA/vjFHuM9nzgNYvIdPgFbk2TwyThiIAojapwykPZAQVpigOphmyvv/gU/1o3h
Qw8k3IXRYRbauxhVDLWJG3nqxPswz9DdrllbuxrvS7CfbUQFvx4jMh5nTJ3lkNhHfF3ctAiOIkj7
ppAtBLeDL0+7Trb6BS+i3Mn28fMZGii0/Js2mGIvc3oZvBYVKKfSEHQLCaD9aYMjSWMhJCmQA0Pu
TkoaAwVhTtLGEjXxqGcinUYqwtZ+THWgj2+w24YbDCyp456VdeDSWO5mYqsJV6/cssr0DehOXZb1
Hv43zkHjGo6UYI14Nmw7dI0xv1rcfDk/NG4QoylW9qBeqJI1hSsFtQ0H4TdgWl5EA7B4HNn+Csy4
cm8SWe8OZZiwAVncXyFAOHetbM63DtyBeqh73cp2FD/rQEiUik8D+OaVkcd+3gf3pkai6YpVkRWi
RBkwtWtAsTtHWL9e0ijt08mHLRwAIx7LexDiVAWZRmwi1v22BKt/hlCPCL0CK4c6rvL/dUgsnZ95
0fag5d7CIZAol6uikjmohGboW4V0rrg3arFzoA2NzmlWN/IUtVuZKeRMhkOBub/8CsLK8Qw+ojNE
EpLOSELDx89+TQsHOfrfAuKoznVX8L6CUB5Px4uO0tuYjXVNmo5Yb1dTOxmaApz2uuTgb3dP71DZ
XPYxlfvrvo+wDiJGAvaRyFJoxSI2jRIbRam3DDDh94jtbJvS7uSVvgUql23WFFvN3nprSSWDdYBO
//5UVKJ5PdV8/wZFbwc1Bi3Fuu3JdQSs8e9jYJ2DPyoGOFVG39QmC1saHGsB1X20OjfaxdtdRBUH
V5DIgBimExVp8c/bh29zYNp2WzfdwRIUpwnVGE1+9yad8bEruEPF/VG1geakykWTtwjQzH4zyiP/
6GTVqhD/adIws9MKjXvVR5O1LfVaMRefEAoafMbvlzVY514N8FpnS+nLXbdr5NHD3+hlH7Siyspd
DpMAOvWb3LGcIylVKNE4VpQd6V3tNh54tcTms+poEuPgV7i/yG1vdjq0qPtNkW3Ao1x5AVHc1HtN
lf1GQs1odOGo5B6tpNAvrHX8YWNRjdIJKkCQuOwPqddEc5v/A12BLrJ6KZq6Us1j4BNjegLt69Ob
pmjgQoT7ARcdTX2jxICwe2Of6561yywZkIyS95rDm9vlZDK2YjprRDvVuHsjQcj7AW0HsfI7dQjI
fHE+szQ7nsdIHCIoUGquSRU6Y3pI4kF+3kKNPa4Ty/WbWnm/ER18wBh2f/Hzw9X9xcL8ZMYT4H89
PvgQntoO9+gy4sJDbMN4X9fdfHFxMOlAI/6sVEBovbl9WC6u5hc+jIaAZlzxQp70NiEm3+YPd2dI
FprjRi3LVz1HerOMP/bEqbNjmeBmnTOkJr8WqRRDcrUCc60Kfbep24PxCaeJe2MS/9D4REL9z+QM
YXclPf9PDvg/Mk9c42BUc8w9lEIfMC2K790TUvfKkGNz2xKU5LnOZWkSxibLwewEslms17Ixw2lR
FV0xpNGgGih7zUo52gJ8BNGw7bsxOpy5BpRxQs2hMQs8eYOywE5gXMGjHjVJT81zVeRWxXrX6Dmz
lZ16epttZL4rgexd8ezaSvduDGOP6slAfMdbs2FfFFCvUFAnb6zv9Bd9YeBBBBVzhvwKtej9GGkm
7AUOF/2sA6n+5erm8vb6dv7rVPH20dO4HU9XmOvdHxVEzLXc2ZLttRa4f6findVNS7vHT9Bb6sc1
stTVaSsa8Sw7y0iB1sWLhAZHNi8gHJrIoEaQ9ZXqUkz3M1YWMYuUBg9lMeU+MALtZVnOfqvqfYW2
pcjk0E09veoMsY0FaJZqjtVPfmDO143UAqJfEIw3WJ68YiuvCynRRFgI6+dTNE7qpyNSa1FjQ7tv
77iTTVGr/qIsX8/QHjQXcDyg+VbvACS7vQR0D/J8jO1UV8qP2U5ZwP+vbCfagz+J7U/HbFdt3cdk
T2NbUv8SXE94/8K/OtXBb659ZZirghExzZewb5RWdjWkQPGJRZqGqt2YWo0i1cVOrXKqWDS1ynAw
bRhKHFSwiVUSp8GkXYKhHZxcVAPR5K0YcI4nn4MZVTSdWsWJytOJ1QSPoghlTa9BSdE/Msh8TMwa
i5k6M7EapQqCiUXO1FcODY4Cgps98OEtwkno/fWvjCcqC48Wj06qO6ePQn5QqI5AR5r6NZJx1xHS
vsUmqurHlqT/BR3JQtQNZW5kc3RyZWFtDWVuZG9iag0xNCAwIG9iag0yMjIxDWVuZG9iag0xMiAw
IG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwN
L0YwIDYgMCBSIA0vRjEgOCAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAxMyAw
IFINPj4NZW5kb2JqDTE2IDAgb2JqDTw8DS9MZW5ndGggMTcgMCBSDS9GaWx0ZXIgL0ZsYXRlRGVj
b2RlIA0+Pg1zdHJlYW0NCkiJ1VfJbtzGFv0C/UMhm9iBmmYNnFaB4o4BA1HsFynIIsqCYld3M+HQ
4SBFf//OreKoJiWvMiBGmmKxbt3hnHtPfXd74SmHC+b5vuMrxm63Fy6j/6oDu3j3wWWRE/l4vb/Y
uI7LvRDPCcOj60d4fGRvftJ6d8l0w+LMectuf8f+DReOpF1b86V5TJgxILx+159tWulcF03N3pcP
uooP2mwXgU8Oce4Yd+w2NZ7rdef+sP35M5uZuSri7KlOa2NGeqEjsCHyRyvWD9fu5/ydwD/X5eb7
728v/mQXnu94SIYInDBkUjkh4zAhWKXZkf3CCnbx3W3/kYTJLmNwK+DGeB9Yb/N/0x08cPyw36FU
YHeQ8+ZzJVxHKHIV8ZPT7z7wMf8UgBR2y66K980m1c1+k+3a0yYvdzrbuL7T/NX0J3ue44Y4UzlK
MV8p8sDYRyz7i4hio0XPt2+FGtZUgEW1tupHkeOvLQ6xqkh0qZ+jCFEIaYv55po7iU2+cqlWA2CC
YASM79tyXbGkLPbpoa3i+0yzPP4rzducxXnZFg0r96xJc83udfOodQFnTlmaxCx5SjJdTwqsgK4A
7rvSARx4KMzPeY2H7zzHJH1r8S9HHKoOhzc6adKyYJ4D3LINIGmONu9ukqPetXA3LnZsDonugEme
DD3kFKK/fvzxw6frT9vfzNZNjw8ZUGW7ZM2yKSaRRrCPOoDX+FgGAdEbpHLVPND+s5BM92CWY/55
F2Zz1Kw+6STdpwlrqvRw0NXdm/rurYmt0lnc6B07xVWc60ZXNduXFYvZIX1AOWpdgeHs+uebW5SI
pTtAHoawIS2e5aXzB+gNwyHvbuRN8xKzR51lmz+K8rFgpyxONNvpfVrA3v0TM5428CquqDE5B8e8
mtbl6lBp0zRMBLZtydDweUShmKCQ+32xNZtXZdo3lOLU99A9FjHVfyTpZ4BU31LtAajijk8yMhay
s40SApAL1vvPBusUQyjGGEyHOmdS0eb3qA0YFCdJm7e2kMkxLg4jc6wnPWbhCjqUH5FD8AfJWeIO
uaK6DvCsjwWjW8Lv3PqxbNhNezqVFc5fap8K/U2plxK3AH9uxtqr8OehE/6L0D+P9G9E/wuz54tr
NtBBRpxQ+jIdJCaR7WYvyI2hxHqRG91B3IuMcljjxktHuWFfdXvWe4N/KhBl7yHOWm0owpIqbZDI
jH36uF1kBzmDKf8aO2Qk+8b/OvSlF3xxhs5JIP0A4/U1Dkjr8b+GBH3M/zUGjGPa78XncwUk1bOi
7c9kkMGhPcsNO818VZtAKl23mZE8ccHitilzBJXQa6s20uLAIA815b6aBJ0WQK59pAGA9825MJJK
OBDbPHKJKuvCSEJQ+pMWNQyauSgC8BDSht00cdXMSvCTrk9lUetlWSQl9g0dmXNvzLzR3Djibn6H
2JUYXnhiBe4jSFRJKIMuthjDn+d3E4usUdG5Hc7B7oyVbYNspzXl1Tpansjxu7fzKkOyOcNV57yw
52wUrqX0K3QUbji5LPzzdOT4mSjhv5GR3BWOv8hI15ukRQnrysfm65oVoCWUf1zhoLgxp301EITw
gMvCV1NIhGrQfUtG62PZZjvKVN2Ulc0SGd0BfwnePLG0qXW2vxOuN2j922+YadGjPdHbQ1Iej2X+
Lf6i3KCBZCmJsMpYBT1rgLm6NH9NbNlW0Ou5jgjgdQwX+s0WrztdwfiNdbtuk+PMTBBOLlhBbwb4
yG017vXQOYChSzJ9PwVbyc47hwBlIVqEEN3g85Y7h5DKCUaF6kWTbIcjsrc3V+wxBijRzXAe0dzo
1LQZ40obcmtxCgtOt9TXnRF8es8A1IZuwGUH7STRdZ2SVH5IY/bD9uozPPiFYFXrpIUcQPHrutX1
5Tl3+mPcyHGH6xU3/adDhPDGmB/jJ2rr4GIKgYEnYmkKLqEMcfIHDng0cS/jVvBJj+iNooEllUYn
+PZMnvEQsSMDK42+/2iQKQviY3ZbRbs7LKkzew4Po2UZ2H+0fI5pNRPMR/0dJo+LFkmqMAN03Zje
lua53oELejr2FtHRuSRN/taH3EtOqbGGXHrj7fA6LuKD6WTs00lXxofaWRJ1JFeFWkltpzX61J6P
EQ65BrpJocy8Xs1rwJ1B1HExmaM9vm+Ps3zRzNSZHQy1FTbsvmyOSHiNKbKps/hBmwmDq2KTbuzr
5ZExBmhjsnB5Y0YTpeWYnurzRtJF1lHzheoModnm4Q3U9fy5CqEJvWHvcWIKZ4vkiV1TkLUJY/wo
WCbvszDcMJhJnY1pCcZ6U8UptMhcIIi+3bGlwsrzwipl5XhoQLJaWOXPOpc/4tENutJeFdQ5qvS+
bcxVBnoRuMSwyltQRkMHNOBQ9kQDB2oA9x10WjOsIRnQfIzINHefmrZjA/YuVho93RvFgewbAwnl
bkp1EGPHMtuZnk4N1HgzG/bumKnQHwoaBV9W0GcCPOiue4uZV6PkHiWhYfZkOMoOSabEU5YYfuDk
Mj/Fdc1IWeSx1TypwfblJPUF0mnBZpN5uSBGTddWE5k7Gz9UoaYqMzaZ0peM5BbUjLmnTl7TQYWp
4ImE2GRtrqueCeFZM+8zTXme6jQAYjtonqtdjnAJ9g1E5YrC5u6osHvp+rmEwSf2cfSsR5XnUc0U
hgXK5SsDK1NNUGDfr3qCpPPaKpU0XF11pbNqWOLWE64aBqqpHaytcp/0+soqjyT9rK2iIOvhcm/1
UC75C7FGailUvDVLsnupoJQQlllTgaIErKz6EY3wlUVPOVwwT4YO+ePRMHPpf5NF5ADGzVtFX4jz
xbOddOb6VjQgiRnNcWGM+kk9mQWGSLIjkiTsBj3O/g8qQ9ZDDWVuZHN0cmVhbQ1lbmRvYmoNMTcg
MCBvYmoNMjEyOQ1lbmRvYmoNMTUgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0v
UmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAgUiANL0YxIDggMCBSIA0+Pg0vUHJvY1NldCAy
IDAgUg0+Pg0vQ29udGVudHMgMTYgMCBSDT4+DWVuZG9iag0xOSAwIG9iag08PA0vTGVuZ3RoIDIw
IDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIicVXa2/cNhb9Bf4P/OgsbEWk
qNfHNF5jDSS169hbLJp8kCWOR7sz0kQPu+6v33MpSpRG0mQLFFg06MiiyPs699zDnx7OfOlwwfwg
cALJ2MPVmcvov+qZnb2/dlnsxAFeb84uXcflfoTnlOHRDWI8vrLze6WyC6Yaluycd+zh39h/yYXj
0a4r/aV+TJk+QPj9ru9tXqm9KpqafSxfVJU8K71dhAE5xLmj3em2SWvXN3Y/XT3esckxH4pk91bn
tT7G8yNHYEMc2FM6P9xuP+fvBf65Ltff//3h7Ds78wPHRzJE6EQR86QTMY4jBKsU27JfWcHOfnro
P/JwpMkY3Aq5PrwPrD/zl/EOHjpB1O+QMux2kPP6cylcR0hyFfGT0++vuc0/BeCJbktWJZvmMlfN
5nKXtYfLfZmp3aUbOM3vTW/Z9x03gk3pSMkCKckDfT5i2ZzFFBst+kH3VshhTYZYlGurQRw7wdri
EKuMhUn9AopCE8Znf5T6OHDw3nc9B3XygohOWUh+/5nv6GRc4cQBXW7k99j4cIdth12eJk1eFuzz
45cH9vPtA17q8rBmmxBidywtD7mqWbnBKzXsURnLi01Z7bvtT4pNC9p5MQpSm4/DAaVu1HmSlvvD
TjXqgj21Dfv84V9HHjRsp5K6YWWhyJU3MtXv6drJizTO3KGdAs+2ky86Mz+XLKmafJOneUIxFXVT
JTmawpmBW4YRIUIIgscquiWs2si4741b57Pv8FE+huKZo3kUUfusFs+erWs2YofQ1O8BpdCY7gpX
t4dDWTXsjmJEfPddlWxwnRMSzBEGgxc+1z9zL/rvpiG6Yige9zo3vqhUlx8MCTK6ZNdVol+MXFjq
c4nWiyJ7soF7n7xgBnoJ8kUxvFDDaT1vaAoh56CPbNIywKba50UHW4D6dZunW3Z7c1UDIIBWlTdw
2+RVY63Y5M9tlTztFCA/aQI6YhH2Nj7Nzaabk+dKaSZewa0IbaE1FesMK/bbzc/Xt59vr77pbZc9
C8qYyjdw91ESw3kSJaeh88MkSs/xxeC8b5tJSGETeUiqZE/JnFEDZeVQlamqkdJ9WTzr1b3aP80/
vnyuyvZwsZxFjzvctoHwBvh5pqB5ke7aLIeFJNXmrFMXrFD0KqneWNLCYtH0vqWVyujPZIevkrpG
bYu0Y7j5eO5oyw5X3rMWUGFOyZs39vVcFWn1diADX9/h2CIjOCVfz+uv7+jkGdc+ERY3eaGJlCWs
brAnqbLOh4e/dZaFRXEvJ3alOQY2nWdnlvoBZbA8AdpxUBPG6js5QBffj06D61cg47QpkcgPGTon
J+Zs8he1ki3ujrJlfL4rceAbu7ETYwplDMhQrEI5mkHZizmh1wt8R5zgUQ9D3B360I1G/RUGFsrL
2WNf/nH7+OmKoFXuwbWYeWzf7poco4fVqnohNCMzKn/JDcaXUOxF3MSmffD4SOp1LtSArAbLMU7a
IlMVQQPnw+aBcNsh5i9mEi80aVpMfzxPfxBCOnqomjyV/SA2uOhYXpOVkajBKRkC8nhBc7EaPJw8
5brBmpI9lc2WIWZVHaq8VrrHbujPAtp6MfV+aKXHKCVuYLpYFS95VRa63FDo1E1JwbRTXYFRcEgP
tKpmf/jQuzb2mT7NiUCwvkIgQWSNC2PcHFGz17zZEgUUk+DwXkF94TdJqxLcRgDrw/3rhM/qNJET
DHC3E+D4ltlm1SAezYce0b9uc6QryzcbVSEmPPUMkpNwo3zr1NUsRdS9eBm+f69+bxSwnwEBW7VP
LhbS6o7d6z5j+7wGueC5RsmaV6UwrV9LWyt0ad+3PQVvAaKdyhzGbqEvX5O3YQqAgfWtxTIw72Gj
N+nTWkiHkdV9/rzVcAESkGSNUaaqqqwo8VlOMZ+i5JExVGBKzGgzH9z8eNBEdK/qctfqhTsatVlb
wT51xAoChRzB34jImhjh8f7u22kyPkICn9GBIJ0IdRZ4ZHKVD0Qk6NZkOzKadyToGDv76iRsk6Sm
/+kyQGhpdQIuGHLalA0uKG+wtUH0W0zdqaxgm6rc4+USN4jQJfIaVI4/UjnSpKefyDAIT/Tkuuhq
jq78dHVzbV6y3+6vP4pIxt9W+tKNbaRxNK1rjKJ+unq8Y9ct2t2U9wGSpEYzUHGbMi13f6pCYl4h
CNI40Ix8irGFHznczirfFohLA8cPfQXM6EOTPkFhaWJp98SYZXd1g3SAqrL3SjBn1qZUU8sLi4WR
vhOOpgaPrezrXCjbBhPZGMk7OWl8eiX0DI6VBcBBXiyUZXJpIwDK0ZSc98SUHT3XH2f8ji+R4+Uw
6EzlPW9ZchxMjafDD9CiSErQ1ZtubEAcJJO1mnnAUsniNcSW3NVXLS8MHcTGOYW+VHI3cgJ7FXPD
EVR5TxN1TSaytiO2kVWoQSjgTlVDEeM9dJPRpQMintr6bULCNPAYhjnWlhDA8eNZFIoRA/PBJU3j
kNaUGWRqRxMSSYHRwjSWcYOmyy6HKZBHUTZwJKEG7h060shH5Yt629OehfpBqS/ZlwajdSKXwcsH
xL2kjbX/I5pxDeK+nt+r7y0mZKc6szJt6Qn3F5VpTQEihPzEBAeke4nR3w9GNxPXaG2Iph1Dj6Av
chKoxqHS3E1OMckxrudEwqFmox9eIXnk0fqgu0dNEMW98nucKj+jtokqakW3p4FoEPOIX0zDD39v
wcWLKAq5M6IRmyjeJwp6+iUv2xokkaT/KcpXCIFnyjGNms72GnEIbklJzOY0t3P6n1r3nFLbxzn3
5jn39QbPC5xTOfdjR4ym6yjnIrbEM1PcU/YBdspXzT0bGke2AmYQd8Svd4+zbn2VGlA/Yh0uAyey
rMNHNwPT4R2z7PI/zLWsI0AI/V2ZZEQiED9YpSdckMykzv9A+cxMnszpYUAvQ8WTjj8Qjgw6b867
g/4vI/0YFNIOGItC1x9daXoY3hRpxyQQ+7OLFUkqKjAE7whlMgxo4nLhonH18F0A2fCRcPjQ2dy1
fMZjedwISMPYneNETEvRG3BjZzSOgnCShz+RuvM7f9ZJse8I0qnuSZ0ah2bWdy74o0r/TxO86yGV
6wGHW0lS49JGQ6reJS+2fdBUZnwqzWhLyEQ53EGkurbc3I8nl8jeC9xC64XSdnHTqEdg68U9Dnx0
G9EzbDIBuZ6AH3savjGhZLpV+88WS2yDmqjXflDACp3u0XztZ/dwen+gr8+QUUxZCqTuX40GxLXp
V0FC8Htt1RdEUWurruesHuyFEcnotVXJndVzRcxpMq6tBiG9WVuVgl6vrPLYo5+11SA6kQvucQLI
2iopydW9JAgWXI6lo9cQrH4pPUFXC70mQ0l7VlaDOMacW1n0JT36XuSQu373Df43WsROFEe/lbjP
IK7Z4mwn2VzfCuh6UDTgPS8e6RouR2quF/eSVGjYw/S/acHf/Q1lbmRzdHJlYW0NZW5kb2JqDTIw
IDAgb2JqDTI1NjQNZW5kb2JqDTE4IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFIN
L1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDS9GMSA4IDAgUiANPj4NL1Byb2NTZXQg
MiAwIFINPj4NL0NvbnRlbnRzIDE5IDAgUg0+Pg1lbmRvYmoNMjIgMCBvYmoNPDwNL0xlbmd0aCAy
MyAwIFINL0ZpbHRlciAvRmxhdGVEZWNvZGUgDT4+DXN0cmVhbQ0KSIm0V9ty20YS/QL9wzx6q0wY
M7g/KqZdqyrL0lrU5sGbBxAYipMFMTQuUpiv3+65YAASpGVvUkklFC6D7nO6T5/+ZXUVhR5lJIpj
Lw4JWS2vfIL/NE/k6t1Hn2ReFsPlzdXC93wapfC7IPDTjzP4+ULefOG8fEt4R/LK+wdZ/Q7vLyjz
AnxrqZ5UPwuiDmCRfetbLxq+43XXkvfymTf5E1evsyTGgCj1VDj6tdB9NzLf/bR8vCeTY67rvDq0
olXHBFHqMXghi90pOg5fv0/pOwb/+j5Vz39YXX0jV1HsRQAGS7w0JUHopYTCEYw0nGzJr6QmV7+s
7EMBHGkQg7ASqg63idkz/zV+gyZenNo3wjDRb2Dw6vGQ+R4LMVTIH4N+95E6/DGBgOlXyibfdAvB
u82iKvv9YidLXi382Ov+6OyXo8jzU/hm6IUhicMQI1DnQy6bqwxzw5tRrK+ycLgXJnAzPHc3zjIv
PndzyDVMfU8hf1pEgR/pLO7jEfJZ7CUAkR94QFMA1QhHzmBvH4s8hcVSnQh1OVSYnwSa39WWk30j
O1nIitw+PqzgL97y5pmTvJM7UYjuQOSGfFpe3xO5hwLshKxbkrek5BtR85KImnz5+J6xiJIpnzqK
MGOmvCAKF0Ca6AC+mnd/8wi5qUlOdn3VicUubzveEF4/i0bWSD7ptqIlu/xAKp6XpJMkr0lfQ7Sy
es7XFSeFrDeVKDo46bTFVGkbBPD7zHz/9jaCg0pyexuTUrRF37ZkK1/w/C1ch2PVd1vR9Sp13b1B
qsp6eryfMJcfNec/8AJfQ5YisiCP+zLvOHQkRN2rG/eNLHjZQx4qjvnIfRa6o2OjDi3n5Ovjl/vf
1DsL2xhQaAkb3rR1ZPr5PjmpphDKCHogiJlK6Vw1hXHqsaGTaebkiqXRuWJq+/1eNh3SygvAU7Q7
RLbh6mpbbPkObsHVvIPfLVnz7oXzer6QoFfT1JWzUQb9m+kI4GCoACxOoBL1EuoTsBX1E4RgbirU
W962A5sajRAkNYktHIxRlPoZOIbnBjz+WvKHtO2HjvL+6VKgSTguhYf3WtNDH0eAK7WMjp+6Jm0H
oeVNSV6g94C8kkNn7qD1ycs278gAeY4o8aokEttYaUijq2DNrVjM4R1SrHSapt5FuMMAFXNAYRql
BTqCVBbki5QdWT58INdd14h13xl4EaV5iAPq0XiobRaMz/568/nj3e3d8lXYAqrsGFVFVOqme5Sc
QGs6YSMbxBMVuO6waMclmz813MzwV6BKlVPBKr6IKk29Ydb6dFBHOx4crjHiOorm2kZD7ta/w1Pk
fZWDdM7DCzM3tK0yGgGx/ghS86EGpkY0/RDoQ0EHJ+IWZBRzR58z61LsUyH2vMWBTSQTVa0FdoCR
AgdfKwsBbQz9ILotAVMhNgfkqtvizBwKDobmGfbmxC1IqclMR+DEhFIzqL7LucmVxsF8rsNjQ7Jz
bDjKKVBueHlLHhwC54RqlIMWKjoSqtQ62ko7iK3Y/79sh6dsx4mH/8288BLbcD8Yut2PXJg0yE5a
c8e7rSxVa1rls2xX0pB7nmvL2iznSgim0+zNBXpVct9l1yX3F7M7jvbvpjY6pTZkSCp63ovcgoWP
3b5BM8etn16S3X2/rgSEDtTCbZjSoobLO0PoWvZoYp7EM5gTQ/VlbgPmsVOzcolenSADrUwvEuwy
1FQMop3SY45DJ9pTmR5L7jzbLn7VI251oErJjWz/PMOnW00Aix9+OVFL2HmGaYZ3hshGDIenDP9Y
985Qf5FkP8H17jLJZlVwBosyN2cDdmIUqTOK/4arsvkhWE/tPcsC/D42TnweVZahdXKZjKy1AfWm
G7DYSzDPuHEhrPkeLP++wZFYHUjeA96N+BPGY14i2G0HK6NsQGMa/gSMVGC8EXFgQDSzqLKUealr
4WjknELjnGpYE2Tz34HCt2odLAo8+4wQw5aKpC9vVjO9ZzBCD3qx96YoUT8ZiKTpEZHsyC+9h+VU
PPWNCeycyh4ln0yc6G1e508qn1da0fS0GmBrCdTouVgNie+FI1846n4/tGo/CzMwm1eVcf8tKWTd
5brlLC9QGa/tLwaujY49/wQNzbeqw2eRk0/L6/s5anXC3zPCxxn/TU54ktHPOGGdWxSjRDJYiYDE
DPObycw+FOGHh5o9FoxsFKerEnUyS+iZo+1TR0dHbhTZFacmAExzGGjua/GtR6EQJa44G5Ejf922
kf3TFoesgCKqxIZ3Yse9aWwWQ512EHnZbAkPj02i8+PE4c2OZDdUk/JRxUZuTGRQv1MODaBQSb6b
v8wMIAvoLT3tOdguoU1xsMWzNWgfCzzT+S7SjNmR9gBNBFDd5i2MMdIe4H878vDPu8dPSwIK/AyA
gkPZwG079KAX4cZOqk0SZluVP/Nh0s32m0tNqa1rexaYtgedXfNC7rhS050Oxpw51306dcYYmtIL
ZA25v4IrOnI1q8N+1CtOIM+035Q7SifNcLfnWp7bS/JqCQeq2SnVvqqRIEkuU+2nXnzqDtXxNHBr
5xRfnGH5xTpoOQCB+lts8/oJgAG6Gp6XC1lDy81RTuF/gXNTwchNMTPSzNeHESqbEj4Mf7xsRbEd
1wFYgUqAvsOl3VwxaHCYn+FfF4rhCJ3AFUNk9rOHfr+XDc4StCCVfFqs8xb+0nCA2ViDlNSy04Zu
MVsMo9RVvsZoqPoznzk+9ECUtRNYJN7lGTyZ2zOiQFMKe1wQxojC2UKhaYAqN0DhO37sOoN1MvY8
0PKdLGRla+Lz3Yq0eYfOQzetNU8votvCm2UPThkaRs67MQpDwAXAWGZBokYR+rrmOIhzUHmt9aNo
ZqpAJ07T6HIRjDJXtmNkQbLw2DSDINzURaM6P6+sfV41ed1u+HFe9gOTxKzkGMbuDYiv4BjYPdUB
Cv7Kx20V5O8Cu1GG5w4xjLZVP3HsqoJDEz1MUWhx+YKNJoethkM7guxjZ3ZALWiA0ekcTVjb7+DO
OYpDtXI6m8XGULS96mrYn/rGrk7toS5gZNfiT11z0GVN1++x9rAUziw+fuxI9NkRiYnHlLA/4FET
f/WFw1Ruv2N5p+0WnBISqAkUgEc5T0egNk9n750LpGYILTUG+SDJxaGo+FvEfHY5QrCg2wY/DIS1
0Hcgm2voQs61os6SAiOTuvpnbgti1NTGwKsaf5amRsKKNWEAXtKek7z7SEmm22qDx4Iiu2OzSB/7
GWVz0Fcj+kXfNDhWb2XJK1LKoj9dQ4LYdCx8x3ffmSMoPCXIVyPzO2sqhdnhXHro1lQaGIZ+3QKo
u77qxL46HqAteUGlQxJUlR3RqBVR1Xe+c04pPzYTOpQs8ULnlZLRBI+Nmx9OQi/7Vg9KBZ8qlS26
sRwmet9J3IUKRaNtZ9HilR3HQS7anSomFQVoHVWlPNR+6LbQaBjZrayesVLhtfxZinK8gWFTGU3B
n1BGG7jezWm1JoVmPqrZBbEeaNGTiRkwTlucnWnxdg/FfNwJ5vQp0qNllNll9D9vUCREY5ZQW54w
6nipmm6toEdTr0RzHkk/cw7ANw6gQDeFe0m3FS3kbuL8X9/lksQgCATR82RDyXwE7pJ1tvH+q3Rj
rDJl2o1a8xyERubz3jjv5+OYbyYFCpR9GG+NGUfmoYBar4OmUUxFrVFdRRcvEnrr7F0VTaeIitpg
iFB0CZZIglobRQ5sGUwqiobRrGhtRbrW4bwpuvabLahsHeVqa+03W8Cy5Y/rwDLJEOymMZBoqu0s
0PHBR9B1UD4BoR4e0/sUIvd3cDlBeGLXpzWyF2SIC7x48pvaFUfOUXYh7fg4F18/jeC3PUm2l+34
/z99nnA4DWVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNMjg3NA1lbmRvYmoNMjEgMCBvYmoNPDwN
L1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAg
UiANL0YxIDggMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMjIgMCBSDT4+DWVu
ZG9iag0yNSAwIG9iag08PA0vTGVuZ3RoIDI2IDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4N
c3RyZWFtDQpIic1X227cyBH9Av1Dv60caGj2hTcgSCBbNmLAshxLSh7iPLTInhnucsgxL9LOfv1W
NZvs5gwpX7ILBGssRuxb1alTp6pe3Z0FwqOMBGHohYKQu6szn+B/9YacvXzrk8RLQvi8Plv5nk+D
GH6nBH76YQI/n8j5J6WyC6JaIgvvBbn7Gc6vKPM4nrrSO/XPlOgLWDCc+tLltdqpsm3I6+pR1XKj
9HEWhWgQpZ42pz8m7LuBeff91f1HMrnmspTFockbfQ0PYo/BgSS0t/R2+P15Sl8y+Of7VO9/c3f2
hZwFoRcAGCzy4phw4cWEwhWM1Ipsyb9JSc5e3Q2bOFxpEAOzIqovHxwb7vyne4JGXhgPJ4SI+hNo
vN4umO8xgaaC/2j0y7fU4o8OcNYfyWq5ble5aterIuv2q12VqWLlh177azu8HASeH8ObwhOChEKg
Bfp+8GV9lqBvuBiE/VcmxjURwaJYWg2TxAuXFkdfRcIM9DMsMo5fXwe93z5GaqSLYJYunPbBuu6K
Nl/tZNOqGl7aF3kq27wqyfX97R35cHNHiqpRJC/XVb3rV7KuzsuNu9kjxAm1AJ5F4IjPPSAGYxT5
PxPtcV/gafivtA9+ZK3sHQIrb1Wqn4ZbArIi9/tMtgo42lRFpxc+1lWqwDDVEFlmZEoS85CDnL6c
CftQaLKnUYr85/7Tx//qG1YDcUSCsR7pHkz4Dmh7LtUTeA3iFMV4hodswX2zLfY9xyaRWJtEf/27
NUmrcg1Yt3DB6PFT1RUZfoAAQnhIu1UYqoZUa5JBnqRtVR/cuF3oLW6IpygZe8LYYzb5HHsoj3uD
9og1PKQZ0sAzCm6W7fStsmrz9UE/KbNdXuZNW0vYi+bhx1K2EK3hr3l5m3t8hALDjEddZmoznmSD
QLQXegsY+5hnYATZqXQrwY4dgQNkD1DlD4V5+u4v/SuUj2rIDPyooDXe8DDjTa/LPNaCZY3/Y3k8
weV7mQsSEjHL3GhK3PCUtiwBzgao0suc5dSj4cgRSm2YvkVUmm6/r+oWWQ3YblSZjjx4lEWnNIVl
29b5Q9fOJrQxg8ZebFMnjowZvQ2g/XWuGpCm1847O3lwckaWRD3CRgKUyVSTwosqwwVM6VNFQ2y+
KmcOOH+ynE3d/8M4EZ1ywoc6BFU7itCzZVpAmRSOdATWIM5niDGnamPVydRegedVaZJ8VdUZnJGQ
i0ASZAhm8wYAmqMGhyrsO+CEtlHymbEFpEIO5CRtBRxoUJE0ITp4wqHnHBd6TL5OBwvKn0uHY5d/
mA8sSFxCXF6f1jYeJdijcDgfPUMIHlNzcd+dsFFch+7jk6MNclMr029qFsiiqJ5M9PM27zehMoxB
Sw8pCDiE7kHNsyBMjGz2kCTJaIB53xHz/FEVBywL7b4qQQWQEWSHxU0TocxRJ/aqzqtsovq2vWLR
iDjVCqBDC4i/+/D25vrm6vtQZ6eoB7p7/FpHwYPIuuzmoKmgb2S6BZ/2hymYGvOdzMtWojJ2Wd6S
bd4cdxF46GmbwxWNqiE/GgL7ZsGHxji0xKeBLa2hKa1bkN2hOgDiT3m71fye3r+Vj+pkW97O5CTv
O3PGdLUEgGAmmMtJQGjgxfEg4IdOEAOTNh8qiDwkHzAAKGLKl8qgtFyitboRO1QddB7lMRbDi/2U
MPcipVabmG9e1I2GDoELvQXh71Mq8XCYxk5GghNe8VNewfSENoK8I68osnqOVzRBxlkls2Xfp4Zb
l6nuDCF36tnMhh602ldFtYHKbPqzCrYd3HKviQgZbTq3+drP/cgLbGoP85uuO3zAsK66zZa8v7r8
OEcWrqdBmlDvOf3mnKHOj15Tp0EPk6l+o3i/c+J1jcPjBRnlncH6PD2OoZ0pEq5UQkezzjddbeAF
GK9lKTca44uFxtFpb3uqMacm/JBCiRMmsYQjeQYmLSkUSwKPjX0Ct/ynzPD/Dvifyr18yIu8PSCf
0q1Kf9HVIMvXa1VjWW6AJu2TUtAjPI2Ma3R7jxsbuZuOB3NEYjFDUR2JpEuomQBMdP9xc//+ymXk
gv4LxxEeWP23sSE3UEC0LY33XVAHp1DDnMbZ16GOfE+4XUFoa/CQs85kBECv819nIR7hRf2tupZA
wm42UA/LDSnV07Qoz3dlLIg9yv7fsT6diZjgHupj8AzOIsBEnul9KReW04360g3zTqfbPC2WspdN
aDTauiomnP18fvn63ecX47gLZ+SwsVgQR8a5ZynN/LHtoQZmPcpC/wtXj3I7lH648+HgyvckAivf
RJCcVM7Y8TkStnKO9VIn5m2Lve0r2cDfziM/Xs9OxxWGg1H89dRgutJZZY+t6EamP3zX2nJUNU3+
0PebMsugc/rpoZDlLz9NZojhj9UGis++12JwGyIuyborChP1+bD5MXYsoy7aBp4yE7h1Xe2AEtCg
AoOAFciIaz1NfT5vPr+4GLVv39VgsOYZGIs5KnWWZnkN1Qh7ur69QqNx/2y9gIbTxbo5wEO7CR3s
9j6hI9tgx0ezDRa/52vYrA1+xCfj6Zjf35LTQI94Sg9oC2EoAXIE/rOzLI25oaAZXajVTdNf/Avm
0wr6U6NZRrAA0Krok1r3bw0Urh1m7G4Pnpp6hhKKTTaQqgVXcpg25whBIxguLUFNj3M+odi3ZmeP
4vmHl5cnwC1kGjfDw/nt6QBIoYP2EUX6DIRB4jEx0tlpnHrhN5IIuLVVCqqnE82IBdl1bQeoyA7I
CQCl4+yhC3vV6Ywykjjk3yyEIkQtsHG0U8igy0NKQEtKsk7Xs37gLPLfTodO/aEBtT5WRt+mgcnc
sRA4aRB51KOQCZcTx47UT2M73DaEwSTAbT8XCthKpolCHb3w+TcCDBKQrx14EXCA4rc5vIHTMALN
5Wnvta3mwjTGxxHSc0Gq8ulAp0va/4D8EQyjFRE/as+B6VMNuhwGE3Lz8DPsIq8L2TSzDtraEIfW
uTdQh5E3+PubG+njiHIbUUsiP3DGK76YL7JoqjGmCPUMgGVVHnZV18wB2cxMRtCdB1hFEz0f+ViT
5iajJPLi+YlW2FRng+nTTmCFLcwajGn7fhIe+NJBHupY3LL5KSkWgyRPXtSQhqEL6V+Vqv823BEE
mE4iTjAGoRDonA4LOLUeVhH9eHGVBjhsLqzyxMcJYmk1DBHGpVWB0+fSoi+wxV9YZVHiLdrEAoGy
t7TKdfFbWKU4xC2epTh3LJ/FTnnRIeqHz+CIdXnmaAKe4BpEW38UnCGgek1EAs8srIYJIrSwCADB
z4BDqwhvBv0e+J+zCCdhdNJfBUwuLD5dPDmJby4fBS5zaCwAe55YLvtH2RM42WMkLMREHjvd3wGO
sli8DWVuZHN0cmVhbQ1lbmRvYmoNMjYgMCBvYmoNMjUwMw1lbmRvYmoNMjQgMCBvYmoNPDwNL1R5
cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAgUiAN
L0YxIDggMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMjUgMCBSDT4+DWVuZG9i
ag0yOSAwIG9iag08PA0vTGVuZ3RoIDMwIDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3Ry
ZWFtDQpIibVWTY/bNhD9Bf4PcyqSIuJSFElJx6bbAAVSbBor6KHpgSvRNgtZciR6E+fXd0jqy2t7
0R6KNRYChzOcee8Nh2+LleAkZiCkJJIDFPcrCu6v28Lq7h2FnOQSlzeriBIaiwy/S8BPKnP8/Aqv
PmpdvQFtQdXkNRR/o38UM5I4r3u/03+W4AMwMXp9OZpO73Vje/i5fdKd2mrvzlLpEopj4tMJbnw+
Vwznvr//9AHOwvzUqPrUm96HSURGGDrkco4S8qDBP47vGP4ojf3+X4rVF1gJSQSCwVKSZZBwkkGM
IRh0GnbwBzSweluMmxIMOSCGaaWxDz4WNsb8fekRp0RmowfnafBwyfvtnFHCuEsV63dJ372LZ/xd
AQkLLlWnNjYy2m6iujoeon1b6TqikthvdjxZCEIzPJMTzkFy7jLw8bGWzSp3tTmjkGGV8cnGUzTy
W1aZ50TeMk618pwN0F+qKKEilLHmC+hzSVLEiCYEeUokxryG/bhLEI/FvQ9I00lgNM4CvcVOo+eh
NqWypm3g0LW2Ldsafvu0LqA/Hg5tZ8F2quk3uoN2A5WyCr4auwtfprF62xl7AtVUYemc1JDKotDI
szpQVLbNxlRIrVE1BgmtkWReM3SSJGNsFHacJCHztS59xikREMGvUxo/YJ+cxfQho1E1PHdEj4FH
jAexr8UF0jzNnEOCfXwTZ475zrVd6/5/CTPuUo/GJQ3VsTPNFuE1vozvwQ/xV2eBrmItM1fqTHuy
4F2GhHrd985/03ZIHKgjno2AYVRdQd8eu1J7QoezwLawP9qjqmtMTZcIr1uqTK8ea72g/exWC7eJ
mNBIh8OvaOaZDrzATOMRQZPV36yvHbe7jN0yAjRhYnfKhvOLH0OdfC6ZDxwcVIcFHmvVnSE4IHGm
vGclpJP6aPZf1QefXxXv17A32529ARGVC4LYgFGNo+LUHqFqsTrT4yG91vDnh48PxcNfn1+fixqv
lpTdFLW8FDXLnaKd721RJzGJZ1XTeTqxSdWtE/K+tdpfA117wPkU9PvGcYRRvb4fUUuwR/KUbbtT
ZNvI7A+1H0eB/UNnnlR5uq7mOCPTNJCpHKdBuVON6ff//43xMrjpJbgUL+XM4ytfgBfHEF/MxXn2
i8Wd4S9efzf4Rq32eB/01gn/CTEtS9RugBiR3xt8XPQ9tkWDzeu7Qj+7nq/hm+CMo9nMcyaGVIau
Gahx3VfXga5xHHS6ugK/77nFWyYRI/woB9XgA8YT/+DE4vjoyfks5lnu8rqYxYOVU4fuLWss3Ly9
YU1y6ib29SnvjPkwqmOWuMfFcszfMoc5f8s6vBoTJ2HJRdiD/xZG54rvNr8c43TC4i6tF77u2Bec
kd0kC0+EfJy7/oEo5i4e2yJ13E4y/gfchMhTDWVuZHN0cmVhbQ1lbmRvYmoNMzAgMCBvYmoNMTA0
OA1lbmRvYmoNMjcgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAyOCAwIFINL1Jlc291cmNl
cyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDS9GMSA4IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4N
L0NvbnRlbnRzIDI5IDAgUg0+Pg1lbmRvYmoNNiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlw
ZSAvVHJ1ZVR5cGUNL05hbWUgL0YwDS9CYXNlRm9udCAvQXJpYWwNL0ZpcnN0Q2hhciAzMg0vTGFz
dENoYXIgMjU1DS9XaWR0aHMgWyAyNzggMjc4IDM1NSA1NTYgNTU2IDg4OSA2NjcgMTkxIDMzMyAz
MzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzggDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1
NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1ODQgNTg0IDU1NiANMTAxNSA2NjcgNjY3IDcyMiA3MjIg
NjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMgNzIyIDc3OCANNjY3IDc3OCA3MjIg
NjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAyNzggMjc4IDI3OCA0NjkgNTU2IA0zMzMg
NTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1
NTYgDTU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDAgMzM0IDI2MCAz
MzQgNTg0IDc1MCANNTU2IDc1MCAyMjIgNTU2IDMzMyAxMDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3
IDMzMyAxMDAwIDc1MCA2MTEgNzUwIA03NTAgMjIyIDIyMiAzMzMgMzMzIDM1MCA1NTYgMTAwMCAz
MzMgMTAwMCA1MDAgMzMzIDk0NCA3NTAgNTAwIDY2NyANMjc4IDMzMyA1NTYgNTU2IDU1NiA1NTYg
MjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3MzcgNTUyIA00MDAgNTQ5IDMzMyAzMzMg
MzMzIDU3NiA1MzcgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQgODM0IDgzNCA2MTEgDTY2NyA2Njcg
NjY3IDY2NyA2NjcgNjY3IDEwMDAgNzIyIDY2NyA2NjcgNjY3IDY2NyAyNzggMjc4IDI3OCAyNzgg
DTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4IDcyMiA3MjIgNzIyIDcyMiA2Njcg
NjY3IDYxMSANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5IDUwMCA1NTYgNTU2IDU1NiA1NTYg
Mjc4IDI3OCAyNzggMjc4IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTQ5IDYxMSA1NTYg
NTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0Zv
bnREZXNjcmlwdG9yIDcgMCBSDT4+DWVuZG9iag03IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3Jp
cHRvcg0vRm9udE5hbWUgL0FyaWFsDS9GbGFncyAzMg0vRm9udEJCb3ggWyAtMjUwIC0yMTIgMTE5
MCAxMDAwIF0NL01pc3NpbmdXaWR0aCAyNzINL1N0ZW1WIDgwDS9TdGVtSCA4MA0vSXRhbGljQW5n
bGUgMA0vQ2FwSGVpZ2h0IDkwNQ0vWEhlaWdodCA0NTMNL0FzY2VudCA5MDUNL0Rlc2NlbnQgLTIx
Mg0vTGVhZGluZyAxNTANL01heFdpZHRoIDk5Mg0vQXZnV2lkdGggNDQxDT4+DWVuZG9iag04IDAg
b2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjENL0Jhc2VGb250
IC9BcmlhbCxCb2xkDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjc4IDMz
MyA0NzQgNTU2IDU1NiA4ODkgNzIyIDIzOCAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4
IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMzMzIDMzMyA1ODQgNTg0
IDU4NCA2MTEgDTk3NSA3MjIgNzIyIDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1NTYgNzIy
IDYxMSA4MzMgNzIyIDc3OCANNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3
IDYxMSAzMzMgMjc4IDMzMyA1ODQgNTU2IA0zMzMgNTU2IDYxMSA1NTYgNjExIDU1NiAzMzMgNjEx
IDYxMSAyNzggMjc4IDU1NiAyNzggODg5IDYxMSA2MTEgDTYxMSA2MTEgMzg5IDU1NiAzMzMgNjEx
IDU1NiA3NzggNTU2IDU1NiA1MDAgMzg5IDI4MCAzODkgNTg0IDc1MCANNTU2IDc1MCAyNzggNTU2
IDUwMCAxMDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDc1MCA2MTEgNzUwIA03NTAg
Mjc4IDI3OCA1MDAgNTAwIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1NTYgMzMzIDk0NCA3NTAgNTAw
IDY2NyANMjc4IDMzMyA1NTYgNTU2IDU1NiA1NTYgMjgwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0
IDMzMyA3MzcgNTUyIA00MDAgNTQ5IDMzMyAzMzMgMzMzIDU3NiA1NTYgMjc4IDMzMyAzMzMgMzY1
IDU1NiA4MzQgODM0IDgzNCA2MTEgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2
NyA2NjcgNjY3IDY2NyAyNzggMjc4IDI3OCAyNzggDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3
OCA1ODQgNzc4IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSANNTU2IDU1NiA1NTYgNTU2IDU1
NiA1NTYgODg5IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IA02MTEgNjExIDYx
MSA2MTEgNjExIDYxMSA2MTEgNTQ5IDYxMSA2MTEgNjExIDYxMSA2MTEgNTU2IDYxMSA1NTYgDV0N
L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDkgMCBSDT4+DWVuZG9i
ag05IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0FyaWFsLEJvbGQN
L0ZsYWdzIDE2NDE2DS9Gb250QkJveCBbIC0yNTAgLTIxMiAxMTIwIDEwMDAgXQ0vTWlzc2luZ1dp
ZHRoIDMxMQ0vU3RlbVYgMTUzDS9TdGVtSCAxNTMNL0l0YWxpY0FuZ2xlIDANL0NhcEhlaWdodCA5
MDUNL1hIZWlnaHQgNDUzDS9Bc2NlbnQgOTA1DS9EZXNjZW50IC0yMTINL0xlYWRpbmcgMTUwDS9N
YXhXaWR0aCA5MzMNL0F2Z1dpZHRoIDQ3OQ0+Pg1lbmRvYmoNMiAwIG9iag1bIC9QREYgL1RleHQg
IF0NZW5kb2JqDTUgMCBvYmoNPDwNL0tpZHMgWzQgMCBSIDEyIDAgUiAxNSAwIFIgMTggMCBSIDIx
IDAgUiAyNCAwIFIgXQ0vQ291bnQgNg0vVHlwZSAvUGFnZXMNL1BhcmVudCAzMSAwIFINPj4NZW5k
b2JqDTI4IDAgb2JqDTw8DS9LaWRzIFsyNyAwIFIgXQ0vQ291bnQgMQ0vVHlwZSAvUGFnZXMNL1Bh
cmVudCAzMSAwIFINPj4NZW5kb2JqDTMxIDAgb2JqDTw8DS9LaWRzIFs1IDAgUiAyOCAwIFIgXQ0v
Q291bnQgNw0vVHlwZSAvUGFnZXMNL01lZGlhQm94IFsgMCAwIDc5MiA2MTIgXQ0+Pg1lbmRvYmoN
MSAwIG9iag08PA0vQ3JlYXRvciA8RkVGRjAwNEQwMDY5MDA2MzAwNzIwMDZGMDA3MzAwNkYwMDY2
MDA3NDAwMjAwMDQ1MDA3ODAwNjMwMDY1MDA2QzAwMjAwMDJEMDAyMDAwNkMwMDY0MDA3NTAwNzAw
MDIwMDA3MjAwNjUwMDcxMDA3NTAwNjkwMDcyMDA2NTAwNkQwMDY1MDA2RTAwNzQwMDczMDAyMDAw
NjMwMDZGMDA3NjAwNjUwMDcyMDA2MTAwNjcwMDY1MDAyMDAwMkQwMDIwMDAzMDAwMzEwMDJFMDA3
ODAwNkMwMDczPg0vQ3JlYXRpb25EYXRlIChEOjIwMDExMTIxMTkxODI0KQ0vVGl0bGUgPEZFRkYw
MDZDMDA2NDAwNzUwMDcwMDAyMDAwNzIwMDY1MDA3MTAwNzUwMDY5MDA3MjAwNjUwMDZEMDA2NTAw
NkUwMDc0MDA3MzAwMjAwMDYzMDA2RjAwNzYwMDY1MDA3MjAwNjEwMDY3MDA2NTAwMjAwMDJEMDAy
MDAwMzAwMDMxMDAyRTAwNTAwMDQ0MDA0Nj4NL0F1dGhvciA8RkVGRjAwNjUwMDY1MDA3Mj4NL1By
b2R1Y2VyIChBY3JvYmF0IFBERldyaXRlciA0LjA1IGZvciBXaW5kb3dzIE5UKQ0+Pg1lbmRvYmoN
MyAwIG9iag08PA0vUGFnZXMgMzEgMCBSDS9UeXBlIC9DYXRhbG9nDT4+DWVuZG9iag14cmVmDTAg
MzINMDAwMDAwMDAwMCA2NTUzNSBmIA0wMDAwMDE5NzIyIDAwMDAwIG4gDTAwMDAwMTk0MTYgMDAw
MDAgbiANMDAwMDAyMDIzNSAwMDAwMCBuIA0wMDAwMDAxODc4IDAwMDAwIG4gDTAwMDAwMTk0NDcg
MDAwMDAgbiANMDAwMDAxNjcyOCAwMDAwMCBuIA0wMDAwMDE3ODEzIDAwMDAwIG4gDTAwMDAwMTgw
NjUgMDAwMDAgbiANMDAwMDAxOTE1NCAwMDAwMCBuIA0wMDAwMDAwMDE5IDAwMDAwIG4gDTAwMDAw
MDE4NTcgMDAwMDAgbiANMDAwMDAwNDMyOCAwMDAwMCBuIA0wMDAwMDAyMDA4IDAwMDAwIG4gDTAw
MDAwMDQzMDcgMDAwMDAgbiANMDAwMDAwNjY4NyAwMDAwMCBuIA0wMDAwMDA0NDU5IDAwMDAwIG4g
DTAwMDAwMDY2NjYgMDAwMDAgbiANMDAwMDAwOTQ4MSAwMDAwMCBuIA0wMDAwMDA2ODE4IDAwMDAw
IG4gDTAwMDAwMDk0NjAgMDAwMDAgbiANMDAwMDAxMjU4NSAwMDAwMCBuIA0wMDAwMDA5NjEyIDAw
MDAwIG4gDTAwMDAwMTI1NjQgMDAwMDAgbiANMDAwMDAxNTMxOCAwMDAwMCBuIA0wMDAwMDEyNzE2
IDAwMDAwIG4gDTAwMDAwMTUyOTcgMDAwMDAgbiANMDAwMDAxNjU5NiAwMDAwMCBuIA0wMDAwMDE5
NTU1IDAwMDAwIG4gDTAwMDAwMTU0NDkgMDAwMDAgbiANMDAwMDAxNjU3NSAwMDAwMCBuIA0wMDAw
MDE5NjMwIDAwMDAwIG4gDXRyYWlsZXINPDwNL1NpemUgMzINL1Jvb3QgMyAwIFINL0luZm8gMSAw
IFINL0lEIFs8YzkxZjczMjI5MmQ0YzNiMTcyZWQzODYwNTI0ZWRkOWY+PGM5MWY3MzIyOTJkNGMz
YjE3MmVkMzg2MDUyNGVkZDlmPl0NPj4Nc3RhcnR4cmVmDTIwMjg1DSUlRU9GDQ==

--=_702ABABE.A0C1AC77--


From owner-ietf-ldup@mail.imc.org  Wed Nov 21 20:17:49 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15341
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 20:17:49 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM0vf305268
	for ietf-ldup-bks; Wed, 21 Nov 2001 16:57:41 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM0vd805264
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 16:57:39 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAM136C84146;
	Thu, 22 Nov 2001 01:03:19 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011121162924.0178cbd8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 21 Nov 2001 16:56:53 -0800
To: "Ed Reed" <eer@OnCallDBA.COM>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: transactional consistency (Was: LDAP Requirements comments)
Cc: <ietf-ldup@imc.org>
In-Reply-To: <sbfbf6c2.051@smtp.oncalldba.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


To me, "transactional consistency" implies that an update
made by a client against a master (regardless of M/M v M/S)
is made available on all servers, in including the master
to which issued the request, simultaneously and atomically.

The current definition of multi-master implies that the
replication coordination is be done after client operation
is performed (completed) and this precluded "transactional
consistency".

I fully concur that supporting "transactional consistency",
for either M/M or M/S, is very difficult with the number
of replicas is greater than 2 (and is difficult when
equal to 2).

The definition, I hope, divorces the consistency model from
the replication model.


>So - I would prefer to keep the current definition of the Master Replica
>insofar as this aspect of the definition is concerned, because it
>explicitly encodes our operating assumption - that there is no requirement
>for communication with other master replicas before the write or
>update is performed.

I argue that this assumption will lead to an design which
precludes "transactional consistency".

I would prefer the definition be updated and the design be
allowed to preclude "transactional consistency".  As far
as the operating assumption, I see no reason to state that
there is no requirement for such communication.



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 20:22:35 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15438
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 20:22:34 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM184O06076
	for ietf-ldup-bks; Wed, 21 Nov 2001 17:08:04 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM183806072
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 17:08:03 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAM1DjC84159;
	Thu, 22 Nov 2001 01:13:45 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011121165716.01761ce0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 21 Nov 2001 17:07:32 -0800
To: "Ed Reed" <eer@OnCallDBA.COM>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: LDAP Requirements comments
Cc: <ietf-ldup@imc.org>
In-Reply-To: <sbfbf97a.053@smtp.oncalldba.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 05:59 PM 2001-11-21, Ed Reed wrote:
>>>  These models [4 and 5] violate a directory's security policies.
>>How?  An "unregistered" replica can enforce security policies
>>just as well as a "registered" replica.
>But, they can also choose not to, and if the data owner doesn't know
>who is replicating the data, they're certainly not likely to rely on the
>unknown recipients to be "honor bound" to handle the data
>appropriately.

I'd say "registered" replica are no more "honor bound" than
"unregistered" replica.

I believe model 4 and 5 should be excluded, not for security
reasons as the requirement I-D implies, but because they are
adequately addressed by other protocols and mechanisms.



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 20:37:57 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15677
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 20:37:57 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAM1Mau07185
	for ietf-ldup-bks; Wed, 21 Nov 2001 17:22:36 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM1MY807178
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 17:22:34 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAM1SGC84190;
	Thu, 22 Nov 2001 01:28:16 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011121170825.01792288@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 21 Nov 2001 17:22:04 -0800
To: "Ed Reed" <eer@OnCallDBA.COM>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: LDAP Requirements comments
Cc: <ietf-ldup@imc.org>
In-Reply-To: <sbfbfab5.055@smtp.oncalldba.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 06:04 PM 2001-11-21, Ed Reed wrote:
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/21/01 04:47PM >>>
>...
>  G7. All policy and state data pertaining to replication MUST
>  be accessible via LDAP. 
>
>All?  This needs to be constrained to the subset of policy and
>state information necessary to effectively administrate LDAP
>Replication.
>
><eer>  Why?  From the perspective of the protocol we're
>designing, what policy and state data should be excluded from
>access via LDAP?

Policy and state data which is not necessary to effectively
administrate LDAP replication.

RECOMMEND'ing ALL would be okay, or MUST'ing a subset needed
to effective administrate would be okay.  But, IMO, MUST'ing
ALL is a bad idea (and counter to 2119 guidance).

>None that I can think of, and I think it is
>a desireable goal that it all be available, to the extent
>that LDAP is able to access the data elements, that is - for
>instance, authentication credentials, either derived or
>passwords that are not normally accessible via LDAP
>shouldn't be accessible via LDAP (!), so I guess I'd
>agree to some <mumble> along those lines...but are
>you thinking of something else I should be aware of?

I'm thinking the requirement should be reworded in terms
of why we desire this policy and state data to be in the
directory.



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 21:29:02 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17139
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 21:29:01 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fAM2Bl809285
	for ietf-ldup-bks; Wed, 21 Nov 2001 18:11:47 -0800 (PST)
Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM2Bi809277
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 18:11:44 -0800 (PST)
Received: (from jayhawk@localhost)
	by tconl91223.tconl.com (8.11.0/8.11.0) id fAM29en00955;
	Wed, 21 Nov 2001 20:09:40 -0600
Date: Wed, 21 Nov 2001 20:09:40 -0600
From: Ryan Moats <rmoats@lemurnetworks.net>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: ietf-ldup@imc.org
Subject: Re: LDAP Requirements comments
Message-ID: <20011121200940.A905@localhost.localdomain>
References: <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>; from Kurt@OpenLDAP.org on Wed, Nov 21, 2001 at 01:47:25PM -0800
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


On Wed, Nov 21, 2001 at 01:47:25PM -0800, Kurt D. Zeilenga wrote:
| 
| In trying to understand where this WG is going, I recently
| re-reading the LDAP Requirements. I came across a few issues
| which likely should be fixed before this document is progressed
| further.  While most editorial in nature, a couple are technical
| (and substantive) in nature.  In particular, I suggest that
| the current security consideration section be replaced.

Process point...

I thought that a document past WG Last Call is off limits
until IETF Last call.

Ryan


From owner-ietf-ldup@mail.imc.org  Wed Nov 21 22:26:52 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19339
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 22:26:52 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM37Gv10527
	for ietf-ldup-bks; Wed, 21 Nov 2001 19:07:16 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM37E810523
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 19:07:14 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAM3CUC85089;
	Thu, 22 Nov 2001 03:12:30 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011121182647.017557b8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 21 Nov 2001 19:06:17 -0800
To: Ryan Moats <rmoats@lemurnetworks.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Process Point (Was: LDAP Requirements comments)
Cc: ietf-ldup@imc.org
In-Reply-To: <20011121200940.A905@localhost.localdomain>
References: <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>
 <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 06:09 PM 2001-11-21, Ryan Moats wrote:
>On Wed, Nov 21, 2001 at 01:47:25PM -0800, Kurt D. Zeilenga wrote:
>| In trying to understand where this WG is going, I recently
>| re-reading the LDAP Requirements. I came across a few issues
>| which likely should be fixed before this document is progressed
>| further.  While most editorial in nature, a couple are technical
>| (and substantive) in nature.  In particular, I suggest that
>| the current security consideration section be replaced.
>
>Process point...
>
>I thought that a document past WG Last Call is off limits
>until IETF Last call.

First, I assume you mean off limits in the RFC 2418, Section
7.5, last paragraph sense.  To the best of my knowledge, the
document has not yet been submitted to the IESG for
consideration in accordance with RFC 2418, Section 7.5,
as the I-D is not listed in:
  http://www.ietf.org/IESG/status.html
  http://www.ietf.org/IESG/request.html
  http://www.ietf.org/iesg/1protocol_actions.txt
as required if the WG had achieved rough consensus that the
document should be progressed.  Hence my assumption the WG is
still the appropriate place to raise these concerns.

Second, if the document was actually submitted, nothing in
RFC 2418, Section 7.5 should be taken (IMO) as precluding
discussions regarding the submission are off-limits in the WG.
Such discussions would be quite relevant to the IESG
determination on how to progress the I-D.

So, until advised otherwise by a chair or AD, I assume that
the discussion is within scope.

Kurt



From owner-ietf-ldup@mail.imc.org  Wed Nov 21 23:17:16 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21098
	for <ldup-archive@odin.ietf.org>; Wed, 21 Nov 2001 23:17:15 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM41NB11762
	for ietf-ldup-bks; Wed, 21 Nov 2001 20:01:23 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM41L811758
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 20:01:21 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAM46nC85240;
	Thu, 22 Nov 2001 04:06:49 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011121193948.0177d9b8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 21 Nov 2001 20:00:36 -0800
To: "Ed Reed" <eer@OnCallDBA.COM>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: G9/G10 (Was: Coverage matrix..)
Cc: <ietf-ldup@imc.org>
In-Reply-To: <sbfbff3e.059@smtp.oncalldba.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 06:23 PM 2001-11-21, Ed Reed wrote:
>For better or worse, here is my take on how the current Model document addresses the current Requirements document requirements.
>
>I've highlighted comments for requirements not addressed or explicitly broken, in a bold type font.

I'll comment only on the two which might be viewed as suggesting
changes to the requirements I-D.

G9.1 N/A 

I concur.


G10.  Note that this REQUIRES that changes to RootDSE information be
maintained OUTSIDE of LDUP, either directly via Management Operations,
or as side effects of those Management Operations.

Well, I think it's a matter of properly specify the relationship
between DSA-specific information in the root DSE and replication
policy/state information held elsewhere in non-DSA specific
attributes.

For example, namingContexts is maintained on a DSA-specific basis
but is derived from non-DSA-specific information held elsewhere
in the DIT.  I would think that any replication-specific attribute
added to the root DSE would be DSA-specific but, as needed,
derived from non-DSA-specific information held elsewhere in the
DIT.

I see the G10 as being a very appropriate requirement.  It requires
LDUP not change the meaning of DSA specific.

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Nov 22 00:57:58 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22511
	for <ldup-archive@odin.ietf.org>; Thu, 22 Nov 2001 00:57:58 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAM5gBb14141
	for ietf-ldup-bks; Wed, 21 Nov 2001 21:42:11 -0800 (PST)
Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM5g9814136
	for <ietf-ldup@imc.org>; Wed, 21 Nov 2001 21:42:09 -0800 (PST)
Received: (from jayhawk@localhost)
	by tconl91223.tconl.com (8.11.0/8.11.0) id fAM5e8K01187;
	Wed, 21 Nov 2001 23:40:08 -0600
Date: Wed, 21 Nov 2001 23:40:07 -0600
From: Ryan Moats <rmoats@lemurnetworks.net>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: ietf-ldup@imc.org
Subject: Re: Process Point (Was: LDAP Requirements comments)
Message-ID: <20011121234007.A1144@localhost.localdomain>
References: <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1> <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1> <20011121200940.A905@localhost.localdomain> <5.1.0.14.0.20011121182647.017557b8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20011121182647.017557b8@127.0.0.1>; from Kurt@OpenLDAP.org on Wed, Nov 21, 2001 at 07:06:17PM -0800
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


On Wed, Nov 21, 2001 at 07:06:17PM -0800, Kurt D. Zeilenga wrote:
| At 06:09 PM 2001-11-21, Ryan Moats wrote:
| >On Wed, Nov 21, 2001 at 01:47:25PM -0800, Kurt D. Zeilenga wrote:
| >| In trying to understand where this WG is going, I recently
| >| re-reading the LDAP Requirements. I came across a few issues
| >| which likely should be fixed before this document is progressed
| >| further.  While most editorial in nature, a couple are technical
| >| (and substantive) in nature.  In particular, I suggest that
| >| the current security consideration section be replaced.
| >
| >Process point...
| >
| >I thought that a document past WG Last Call is off limits
| >until IETF Last call.
| 
| First, I assume you mean off limits in the RFC 2418, Section
| 7.5, last paragraph sense.  To the best of my knowledge, the
| document has not yet been submitted to the IESG for
| consideration in accordance with RFC 2418, Section 7.5,
| as the I-D is not listed in:
|   http://www.ietf.org/IESG/status.html
|   http://www.ietf.org/IESG/request.html
|   http://www.ietf.org/iesg/1protocol_actions.txt
| as required if the WG had achieved rough consensus that the
| document should be progressed.  Hence my assumption the WG is
| still the appropriate place to raise these concerns.

Well, my understanding
(based on http://www.imc.org/ietf-ldup/mail-archive/msg01122.html) is
that it has:

"       - passed WG Last Call - Request sent to Applications Area ADs for IESG Review"

Therefore, I think it is off our plate for now.

| Second, if the document was actually submitted, nothing in
| RFC 2418, Section 7.5 should be taken (IMO) as precluding
| discussions regarding the submission are off-limits in the WG.
| Such discussions would be quite relevant to the IESG
| determination on how to progress the I-D.

Uh, then what the *heck* does "Last Call" mean?  If folks can bring
up new points on the WG mailing list *AFTER* "Last Call" has closed, then
the whole concept is *bogus*, IMHO.  If I look at 2026 as well as 2418,
I'd claim these comments (if really for IESG detemrination) should
be going to the IESG during the IETF-wide "Last Call".  Since
that call hasn't been made, and since I don't see the iesg
mailing lists on these posts, I find this claim to be rather
disingenuous (sp?).

Ryan


From owner-ietf-ldup@mail.imc.org  Thu Nov 22 07:24:23 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13512
	for <ldup-archive@odin.ietf.org>; Thu, 22 Nov 2001 07:24:22 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAMC6ZU26456
	for ietf-ldup-bks; Thu, 22 Nov 2001 04:06:35 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAMC6Y826449
	for <ietf-ldup@imc.org>; Thu, 22 Nov 2001 04:06:34 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAMCBmC86165;
	Thu, 22 Nov 2001 12:11:48 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011122022014.01752b90@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 22 Nov 2001 04:04:55 -0800
To: Ryan Moats <rmoats@lemurnetworks.net>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Process Point (Was: LDAP Requirements comments)
Cc: ietf-ldup@imc.org
In-Reply-To: <20011121234007.A1144@localhost.localdomain>
References: <5.1.0.14.0.20011121182647.017557b8@127.0.0.1>
 <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>
 <5.1.0.14.0.20011120175742.016d4ea8@127.0.0.1>
 <20011121200940.A905@localhost.localdomain>
 <5.1.0.14.0.20011121182647.017557b8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 09:40 PM 2001-11-21, Ryan Moats wrote:
>"       - passed WG Last Call - Request sent to Applications Area ADs for IESG Review"

Well, obviously, that's in error or the IESG status pages
are in error.  I assume the chair will clarify and, if the
IESG are at fault, request the IESG Secretary appropriate
corrective action be taken.

>Therefore, I think it is off our plate for now.

The document is still a product of the WG.  A WG remains
free to discuss the I-D and provide input to the AD and
IESG.  This input may be solicited or unsolicited by the
IESG.  So, until such time the the chair advises me that
these comments is not appropriate for the WG to discuss, I
will continue to discuss them on the list.

>| Second, if the document was actually submitted, nothing in
>| RFC 2418, Section 7.5 should be taken (IMO) as precluding
>| discussions regarding the submission are off-limits in the WG.
>| Such discussions would be quite relevant to the IESG
>| determination on how to progress the I-D.
>
>Uh, then what the *heck* does "Last Call" mean?

A last call is simply a process tool, calling for detailed
review and comment by all interested parties, to gauge
consensus regarding a pending action.

>If folks can bring up new points on the WG mailing list
>*AFTER* "Last Call" has closed, then the whole concept is
>*bogus*, IMHO. 

Folks can bring up new points at any time during the process.
Folks are encouraged to bring them sooner than later, which is
why I raised the issues soon after I came upon them.

>If I look at 2026 as well as 2418,
>I'd claim these comments (if really for IESG detemrination) should
>be going to the IESG during the IETF-wide "Last Call".

It would be disingenuous to delay raising new points.

Kurt



From owner-ietf-ldup@mail.imc.org  Fri Nov 23 19:12:03 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25077
	for <ldup-archive@lists.ietf.org>; Fri, 23 Nov 2001 19:12:02 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fANNpvG01578
	for ietf-ldup-bks; Fri, 23 Nov 2001 15:51:57 -0800 (PST)
Received: from hotmail.com (oe23.law9.hotmail.com [64.4.8.80])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fANNpk801562
	for <ietf-ldup@imc.org>; Fri, 23 Nov 2001 15:51:46 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 23 Nov 2001 15:51:19 -0800
X-Originating-IP: [65.14.159.170]
Reply-To: <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>,
        "'Ryan Moats'" <rmoats@lemurnetworks.net>
Cc: <ietf-ldup@imc.org>
Subject: RE: Process Point (Was: LDAP Requirements comments)
Date: Fri, 23 Nov 2001 18:51:27 -0600
Message-ID: <000001c17482$25ecf020$0300a8c0@D7ST2111>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <5.1.0.14.0.20011122022014.01752b90@127.0.0.1>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 23 Nov 2001 23:51:19.0514 (UTC) FILETIME=[BF7623A0:01C17479]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


The requirements document has indeed passed WG Last Call.

A recommendation was made to the Applications ADs as indicated
Previously and as referenced by Ryan.

Neither John nor I have heard from Patrik that the document
is not being considered or that there is something which would
keep it from moving forward. I'll ask Patrik what's going on
with the document. I don't know why it doesn't show up so far
on the list which Kurt mentions.

I'd prefer that any comments with regards to the requirements document
be handled as a part of IETF Last Call unless they are show stoppers.

Chris.

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]
On Behalf Of Kurt D. Zeilenga
Sent: Thursday, November 22, 2001 6:05 AM
To: Ryan Moats
Cc: ietf-ldup@imc.org
Subject: Re: Process Point (Was: LDAP Requirements comments)


At 09:40 PM 2001-11-21, Ryan Moats wrote:
>"       - passed WG Last Call - Request sent to Applications Area ADs
for IESG Review"

Well, obviously, that's in error or the IESG status pages
are in error.  I assume the chair will clarify and, if the
IESG are at fault, request the IESG Secretary appropriate
corrective action be taken.

>Therefore, I think it is off our plate for now.

The document is still a product of the WG.  A WG remains
free to discuss the I-D and provide input to the AD and
IESG.  This input may be solicited or unsolicited by the
IESG.  So, until such time the the chair advises me that
these comments is not appropriate for the WG to discuss, I
will continue to discuss them on the list.

>| Second, if the document was actually submitted, nothing in
>| RFC 2418, Section 7.5 should be taken (IMO) as precluding
>| discussions regarding the submission are off-limits in the WG.
>| Such discussions would be quite relevant to the IESG
>| determination on how to progress the I-D.
>
>Uh, then what the *heck* does "Last Call" mean?

A last call is simply a process tool, calling for detailed
review and comment by all interested parties, to gauge
consensus regarding a pending action.

>If folks can bring up new points on the WG mailing list
>*AFTER* "Last Call" has closed, then the whole concept is
>*bogus*, IMHO.

Folks can bring up new points at any time during the process.
Folks are encouraged to bring them sooner than later, which is
why I raised the issues soon after I came upon them.

>If I look at 2026 as well as 2418,
>I'd claim these comments (if really for IESG detemrination) should
>be going to the IESG during the IETF-wide "Last Call".

It would be disingenuous to delay raising new points.

Kurt



From owner-ietf-ldup@mail.imc.org  Fri Nov 23 21:14:01 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25908
	for <ldup-archive@lists.ietf.org>; Fri, 23 Nov 2001 21:14:00 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAO1xPI05197
	for ietf-ldup-bks; Fri, 23 Nov 2001 17:59:25 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAO1xN805193
	for <ietf-ldup@imc.org>; Fri, 23 Nov 2001 17:59:23 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAO24eC91566;
	Sat, 24 Nov 2001 02:04:40 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011123172206.01736a30@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 23 Nov 2001 17:58:26 -0800
To: <imcapple@hotmail.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: Process Point (Was: LDAP Requirements comments)
Cc: "'Ryan Moats'" <rmoats@lemurnetworks.net>, <ietf-ldup@imc.org>
In-Reply-To: <000001c17482$25ecf020$0300a8c0@D7ST2111>
References: <5.1.0.14.0.20011122022014.01752b90@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


At 04:51 PM 2001-11-23, Chris Apple wrote:
>I'd prefer that any comments with regards to the requirements document
>be handled as a part of IETF Last Call unless they are show stoppers.

Do you consider any of the issues raised "show stoppers"?

In particular,

1) The multi-master definition precluded transactional
consistency, counter to the document's G2 requirement
that transactional consistency not be precluded,

2) Per Ed's comment, it would appear wise to state that
LDUP design MAY preclude transactional consistency,

3) confusing use of RFC 2119 imperatives, and

4) Security considerations issues due to the changes in
assumptions made by WG (namely LDAPext delivering an ACM).

5) any of the other issues noted by either Ed or I in
recent WG discussions.

Kurt



From owner-ietf-ldup@mail.imc.org  Sat Nov 24 01:46:57 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04920
	for <ldup-archive@lists.ietf.org>; Sat, 24 Nov 2001 01:46:57 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAO6MMk09412
	for ietf-ldup-bks; Fri, 23 Nov 2001 22:22:22 -0800 (PST)
Received: from hotmail.com (oe61.law9.hotmail.com [64.4.8.196])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAO6MB809407
	for <ietf-ldup@imc.org>; Fri, 23 Nov 2001 22:22:11 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 23 Nov 2001 22:22:11 -0800
X-Originating-IP: [65.14.159.170]
Reply-To: <imcapple@hotmail.com>
From: "Chris Apple" <imcapple@hotmail.com>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: "'Ryan Moats'" <rmoats@lemurnetworks.net>, <ietf-ldup@imc.org>
Subject: RE: Process Point (Was: LDAP Requirements comments)
Date: Sat, 24 Nov 2001 01:22:19 -0600
Message-ID: <000001c174b8$c0906ea0$0300a8c0@D7ST2111>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <5.1.0.14.0.20011123172206.01736a30@127.0.0.1>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 24 Nov 2001 06:22:11.0412 (UTC) FILETIME=[59E1C940:01C174B0]
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


I was only replying to the process point. I have not been able to read
the other postings that you mention yet. But will reply more
specifically
in context after I do.

Chris.

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]
On Behalf Of Kurt D. Zeilenga
Sent: Friday, November 23, 2001 7:58 PM
To: imcapple@hotmail.com
Cc: 'Ryan Moats'; ietf-ldup@imc.org
Subject: RE: Process Point (Was: LDAP Requirements comments)


At 04:51 PM 2001-11-23, Chris Apple wrote:
>I'd prefer that any comments with regards to the requirements document
>be handled as a part of IETF Last Call unless they are show stoppers.

Do you consider any of the issues raised "show stoppers"?

In particular,

1) The multi-master definition precluded transactional
consistency, counter to the document's G2 requirement
that transactional consistency not be precluded,

2) Per Ed's comment, it would appear wise to state that
LDUP design MAY preclude transactional consistency,

3) confusing use of RFC 2119 imperatives, and

4) Security considerations issues due to the changes in
assumptions made by WG (namely LDAPext delivering an ACM).

5) any of the other issues noted by either Ed or I in
recent WG discussions.

Kurt



From owner-ietf-ldup@mail.imc.org  Wed Nov 28 06:20:16 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00258
	for <ldup-archive@odin.ietf.org>; Wed, 28 Nov 2001 06:20:15 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id fASAxJg01306
	for ietf-ldup-bks; Wed, 28 Nov 2001 02:59:19 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fASAxH801298
	for <ietf-ldup@imc.org>; Wed, 28 Nov 2001 02:59:17 -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 FAA29040;
	Wed, 28 Nov 2001 05:59:13 -0500 (EST)
Message-Id: <200111281059.FAA29040@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-usage-profile-02.txt
Date: Wed, 28 Nov 2001 05:59:13 -0500
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=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		: General Usage Profile for LDAPv3 Replication
	Author(s)	: R. Huber, G. Maziarski, R. Moats
	Filename	: draft-ietf-ldup-usage-profile-02.txt
	Pages		: 18
	Date		: 27-Nov-01
	
Support for replication in LDAP directory systems is often one of the
key factors in the decision to deploy them.  But replication brings
design constraints along with its benefits.

We discuss some of the factors that should be taken into consideration
when designing a replicated directory system.  Both programming and
architectural/operational concerns are addressed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldup-usage-profile-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ldup-usage-profile-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011127135506.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldup-usage-profile-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ldup-usage-profile-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011127135506.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ldup@mail.imc.org  Fri Nov 30 06:21:16 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04017
	for <ldup-archive@odin.ietf.org>; Fri, 30 Nov 2001 06:21:15 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAUB1O012147
	for ietf-ldup-bks; Fri, 30 Nov 2001 03:01:24 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUB1N812143
	for <ietf-ldup@imc.org>; Fri, 30 Nov 2001 03:01:23 -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 GAA02682;
	Fri, 30 Nov 2001 06:01:18 -0500 (EST)
Message-Id: <200111301101.GAA02682@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-lcup-02.txt
Date: Fri, 30 Nov 2001 06:01:18 -0500
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=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 Client Update Protocol
	Author(s)	: R. Megginson et al.
	Filename	: draft-ietf-ldup-lcup-02.txt
	Pages		: 22
	Date		: 29-Nov-01
	
This document defines the LDAP Client Update Protocol (LCUP). The 
protocol is intended to allow an LDAP client to synchronize with the 
content of a directory information tree (DIT) stored by an LDAP 
server and to be notified about the changes to that content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldup-lcup-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ldup-lcup-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011129144442.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldup-lcup-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ldup-lcup-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011129144442.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ldup@mail.imc.org  Fri Nov 30 18:40:36 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15122
	for <ldup-archive@odin.ietf.org>; Fri, 30 Nov 2001 18:40:36 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id fAUNP2g28922
	for ietf-ldup-bks; Fri, 30 Nov 2001 15:25:02 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUNP0828918
	for <ietf-ldup@IMC.ORG>; Fri, 30 Nov 2001 15:25:00 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fAUNVNC21562
	for <ietf-ldup@IMC.ORG>; Fri, 30 Nov 2001 23:31:23 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011130145934.01784720@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 30 Nov 2001 15:24:34 -0800
To: ietf-ldup@imc.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: lcupCookieScheme in draft-ietf-ldup-lcup-02.txt
In-Reply-To: <200111301101.GAA02682@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ldup/mail-archive/>
List-ID: <ietf-ldup.imc.org>
List-Unsubscribe: <mailto:ietf-ldup-request@imc.org?body=unsubscribe>


The lcupCookieScheme attribute type:
  ( OID-TBD NAME 'lcupCookieScheme' EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 NO-USER-MODIFICATION
    USAGE directoryOperation ) 

has a syntax (OID) doesn't match the description in the I-D (OID + DN).
I believe it USAGE likely should be dsaOperation as cookie support
for an entry may differ between copies of the entries (in different
replicas).

Also, I guess I do get why this attribute needs a) be accessible from
entries with the DIT and b) why there needs to a DN component.

Given that there that the server maintain any state on behalf of the
client, why would it matter which supported cookie scheme was used?

And it seems kind of pointless to provide a limited discovery
mechanism (complete subtree only) as to which portions of the
DIT the server might support LCUP upon. Seems it would be far
easier (and quite harmless) just for the client to initiate LCUP
and for the server to return an appropriate error if it cannot
process the request.

Kurt