From owner-ietf-ldup@mail.imc.org Thu Aug 2 22:31:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13188 for ; Thu, 2 Aug 2001 22:31:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BIo04561 for ietf-ldup-bks; Thu, 2 Aug 2001 19:11:18 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732BGs04556 for ; Thu, 2 Aug 2001 19:11:17 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ7I00.PCR; Thu, 2 Aug 2001 22:06:54 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5UIR00.NJ5; Fri, 27 Jul 2001 21:52:03 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA10055; Tue, 24 Jul 2001 08:41:53 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA14604 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 08:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12646 for ; Tue, 24 Jul 2001 06:29:43 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05924; Tue, 24 Jul 2001 06:29:40 -0400 (EDT) Message-Id: <200107241029.GAA05924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com, ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-good-ldap-changelog-02.txt Date: Tue, 24 Jul 2001 06:29:39 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of an Object Class to Hold LDAP Change Records Author(s) : G. Good, L. Poitou Filename : draft-good-ldap-changelog-02.txt Pages : 8 Date : 23-Jul-01 In order to support more flexible replication methods, it is desirable to specify some manner in which an LDAP client may retrieve a set of changes which have been applied to an LDAP server's database. The client, which may be another LDAP server, may then choose to update its own replicated copy of the data. This document specifies an object class which may be used to represent changes applied to an LDAP server. It also specifies a method for discovering the location of the container object which holds these change records, so that clients and servers have a common rendezvous point for this information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-good-ldap-changelog-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-good-ldap-changelog-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-good-ldap-changelog-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: <20010723140452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-good-ldap-changelog-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-good-ldap-changelog-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Aug 3 05:17:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10475 for ; Fri, 3 Aug 2001 05:17:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738t3b05137 for ietf-ldup-bks; Fri, 3 Aug 2001 01:55:03 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738t2s05130 for ; Fri, 3 Aug 2001 01:55:02 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFGT00.TQV; Fri, 3 Aug 2001 03:58:05 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5UIR00.NJ5; Fri, 27 Jul 2001 21:52:03 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA10055; Tue, 24 Jul 2001 08:41:53 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA14604 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 08:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12646 for ; Tue, 24 Jul 2001 06:29:43 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05924; Tue, 24 Jul 2001 06:29:40 -0400 (EDT) Message-Id: <200107241029.GAA05924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com, ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-good-ldap-changelog-02.txt Date: Tue, 24 Jul 2001 06:29:39 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of an Object Class to Hold LDAP Change Records Author(s) : G. Good, L. Poitou Filename : draft-good-ldap-changelog-02.txt Pages : 8 Date : 23-Jul-01 In order to support more flexible replication methods, it is desirable to specify some manner in which an LDAP client may retrieve a set of changes which have been applied to an LDAP server's database. The client, which may be another LDAP server, may then choose to update its own replicated copy of the data. This document specifies an object class which may be used to represent changes applied to an LDAP server. It also specifies a method for discovering the location of the container object which holds these change records, so that clients and servers have a common rendezvous point for this information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-good-ldap-changelog-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-good-ldap-changelog-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-good-ldap-changelog-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: <20010723140452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-good-ldap-changelog-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-good-ldap-changelog-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Aug 7 11:27: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 LAA06289 for ; Tue, 7 Aug 2001 11:27:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77Dt6e03119 for ietf-ldup-bks; Tue, 7 Aug 2001 06:55:06 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Dt4N03110 for ; Tue, 7 Aug 2001 06:55:04 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 07 Aug 2001 07:55:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 07 Aug 2001 07:53:14 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: I-D ACTION:draft-ietf-ldup-infomod-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f77Dt5N03113 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Regarding: ¡ Made obsolete replicaSubEntry and replicaAgreementSubentry object classes ¡ Defined replacement object classes replicaSubEntry2 and replicaAgreementSubentry2 Assuming there are no existing implementations of this draft, do we need to rename these attributes? In general, I think it would be a good idea to hold off the assignment of OIDs in I-Ds until the draft is ready to be progressed to RFC. This will prevent this scenario from being repeated in the future. Jim From owner-ietf-ldup@mail.imc.org Tue Aug 7 13:38: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 NAA09042 for ; Tue, 7 Aug 2001 13:38:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77HNVn05667 for ietf-ldup-bks; Tue, 7 Aug 2001 10:23:31 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77HNUN05663 for ; Tue, 7 Aug 2001 10:23:30 -0700 (PDT) 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 NAA284148 for ; Tue, 7 Aug 2001 13:21:22 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f77HFa367778 for ; Tue, 7 Aug 2001 13:15:36 -0400 To: ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-infomod-03.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Tue, 7 Aug 2001 13:23:23 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/07/2001 01:23:25 PM, Serialize complete at 08/07/2001 01:23:25 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005E127F85256AA1_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E127F85256AA1_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jim, I tend to agree with you in this respect - without OIDs things seem to be=20 more "maleable" and so we can change object classes and attribute types=20 without obsoleting. It drives home the point that the Internet Draft is=20 not for implementation yet. Given that OIDs were assigned to the (now obsolete form) object classes=20 and attribute types, I felt it "safer" to OBSOLETE the names/definitions=20 rather than just change them. A question for the list: ARE THERE IMPLEMENTATIONS THAT USED THE OLD OIDS? = If not, we could entertain using the old OIDs and names - just with=20 modified definitions. 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 "Jim Sermersheim" Sent by: owner-ietf-ldup@mail.imc.org 08/07/2001 09:53 AM =20 To: cc: Subject: Re: I-D ACTION:draft-ietf-ldup-infomod-03.txt =20 Regarding: =A1 Made obsolete replicaSubEntry and replicaAgreementSubentry=20 object classes=20 =A1 Defined replacement object classes replicaSubEntry2 and=20 replicaAgreementSubentry2=20 Assuming there are no existing implementations of this draft, do we need=20 to rename these attributes? In general, I think it would be a good idea to hold off the assignment of=20 OIDs in I-Ds until the draft is ready to be progressed to RFC. This will=20 prevent this scenario from being repeated in the future. Jim --=_alternative 005E127F85256AA1_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jim,

I tend to agree with you in this res= pect - without OIDs things seem to be more "maleable" and so we c= an change object classes and attribute types without obsoleting.  It d= rives home the point that the Internet Draft is not for implementation yet.=

Given that OIDs were assigned to the= (now obsolete form) object classes and attribute types, I felt it "sa= fer" to OBSOLETE the names/definitions rather than just change them.

A question for the list: ARE THERE I= MPLEMENTATIONS THAT USED THE OLD OIDS?  If not, we could entertain usi= ng the old OIDs and names - just with modified definitions.

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


"Jim Sermersheim" <J= IMSE@novell.com>
Sent by: owner-ietf-ldup@mail.imc.or= g

08/07/2001 09:53 AM

       
        To: &nbs= p;      <Internet-Drafts@ietf.org>
        cc: &nbs= p;      <ietf-ldup@imc.org>
        Subject:=        Re: I-D ACTION:draft-ietf-ldup-infomod-03.txt

       



Regarding:

    =A1 Made obsolete replicaSubEntry and replicaAgreementSubent= ry
       object classes
    =A1 Defined replacement object classes replicaSubEntry2 and =
       replicaAgreementSubentry2

Assuming there are no existing implementations of this draft, do we need to= rename these attributes?

In general, I think it would be a good idea to hold off the assignment of O= IDs in I-Ds until the draft is ready to be progressed to RFC. This will pre= vent this scenario from being repeated in the future.

Jim

--=_alternative 005E127F85256AA1_=-- From owner-ietf-ldup@mail.imc.org Wed Aug 8 06:00: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 GAA09321 for ; Wed, 8 Aug 2001 06:00:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f789b7U28643 for ietf-ldup-bks; Wed, 8 Aug 2001 02:37:07 -0700 (PDT) Received: from uxtpaprx1.pwcglobal.com (uxtpaprx1.pwcglobal.com [12.26.159.121]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789b6N28639; Wed, 8 Aug 2001 02:37:06 -0700 (PDT) Received: by uxtpaprx1.pwcglobal.com; id FAA00554; Wed, 8 Aug 2001 05:33:52 -0400 (EDT) From: Received: from uxtpabuf1.us.pw.com(10.26.104.81) by uxtpaprx1.us.pw.com via smap (V5.5) id xma029181; Wed, 8 Aug 01 05:32:33 -0400 Received: from us-amsmta005.us.pw.com by uxtpabuf1.us.pw.com (PMDF V5.1-12 #U3932) with ESMTP id <0GHQ006LQT92EK@uxtpabuf1.us.pw.com>; Wed, 8 Aug 2001 05:34:15 -0400 (EDT) Date: Wed, 08 Aug 2001 05:35:37 -0400 Subject: Re: I-D ACTION:draft-ietf-ldup-urp-04.txt To: owner-ietf-ldup@mail.imc.org Cc: ietf-ldup@imc.org Message-id: 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 08/08/2001 05:35:40 AM Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 4.3 Replication primitives does NOT specify p-replace-attribute(uid, csn, type, value). Is it a type-o? Or ... -Chritine Yoon PricewaterhouseCoopers ---------------------------------------------------------------- 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 Wed Aug 8 06:11: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 GAA09468 for ; Wed, 8 Aug 2001 06:11:34 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f789o6O28936 for ietf-ldup-bks; Wed, 8 Aug 2001 02:50:06 -0700 (PDT) Received: from uxtpaprx1.pwcglobal.com (uxtpaprx1.pwcglobal.com [12.26.159.121]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789o5N28932 for ; Wed, 8 Aug 2001 02:50:05 -0700 (PDT) Received: by uxtpaprx1.pwcglobal.com; id FAA13253; Wed, 8 Aug 2001 05:46:52 -0400 (EDT) From: Received: from uxtpabuf1.us.pw.com(10.26.104.81) by uxtpaprx1.us.pw.com via smap (V5.5) id xma012568; Wed, 8 Aug 01 05:46:03 -0400 Received: from us-amsmta005.us.pw.com by uxtpabuf1.us.pw.com (PMDF V5.1-12 #U3932) with ESMTP id <0GHQ0019ITVK67@uxtpabuf1.us.pw.com> for ietf-ldup@imc.org; Wed, 8 Aug 2001 05:47:44 -0400 (EDT) Date: Wed, 08 Aug 2001 05:49:01 -0400 Subject: draft-ietf-ldup-model-06.txt To: ietf-ldup@imc.org Message-id: 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 08/08/2001 05:49:10 AM Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When a client sends a update request to a LDAP server holding read-only replica, how is a LDAP server supposed to behave? Is this something that the current ldup-model draft should specify? Or is there any other draft specifying such behaviour? -Christine Yoon PricewaterhouseCoopers ---------------------------------------------------------------- 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 Wed Aug 8 08:45: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 IAA11457 for ; Wed, 8 Aug 2001 08:45:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78CLF012168 for ietf-ldup-bks; Wed, 8 Aug 2001 05:21:15 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CLEN12164 for ; Wed, 8 Aug 2001 05:21:14 -0700 (PDT) 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 IAA127398; Wed, 8 Aug 2001 08:19:04 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78CDJ9100696; Wed, 8 Aug 2001 08:13:19 -0400 Subject: Re: I-D ACTION:draft-ietf-ldup-urp-04.txt To: Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Wed, 8 Aug 2001 07:24:44 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 08/08/2001 07:24:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From section 5.1.3 Modify Entry: d) The replace alternative first generates an attribute deletion record for the removed attribute type. A CSN is then associated with each of the added values. John McMeeking To: owner-ietf-ldup@mail.imc.org Sent by: cc: ietf-ldup@imc.org owner-ietf-ldup@mail.im Subject: Re: I-D ACTION:draft-ietf-ldup-urp-04.txt c.org 08/08/2001 04:35 AM Section 4.3 Replication primitives does NOT specify p-replace-attribute(uid, csn, type, value). Is it a type-o? Or ... -Chritine Yoon PricewaterhouseCoopers ---------------------------------------------------------------- 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 Wed Aug 8 08:59: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 IAA11695 for ; Wed, 8 Aug 2001 08:59:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78CY1s12404 for ietf-ldup-bks; Wed, 8 Aug 2001 05:34:01 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CY0N12400 for ; Wed, 8 Aug 2001 05:34:00 -0700 (PDT) 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 IAA117372; Wed, 8 Aug 2001 08:31:50 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78CQ5941332; Wed, 8 Aug 2001 08:26:05 -0400 Subject: Re: draft-ietf-ldup-model-06.txt To: Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Wed, 8 Aug 2001 07:37:32 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 08/08/2001 07:37:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe the server should return a referral, likely using the replica subentries to locate a server that contains an updateable replica. RFC 2251 (LDAP V3) makes reference to this kind of behavior in section 3.2. This is common practice among the servers I am aware of that provide single master replication capability. John McMeeking To: ietf-ldup@imc.org Sent by: cc: owner-ietf-ldup@mail.im Subject: draft-ietf-ldup-model-06.txt c.org 08/08/2001 04:49 AM When a client sends a update request to a LDAP server holding read-only replica, how is a LDAP server supposed to behave? Is this something that the current ldup-model draft should specify? Or is there any other draft specifying such behaviour? -Christine Yoon PricewaterhouseCoopers ---------------------------------------------------------------- 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 Wed Aug 8 10:00: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 KAA12831 for ; Wed, 8 Aug 2001 10:00:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78DYbN14544 for ietf-ldup-bks; Wed, 8 Aug 2001 06:34:37 -0700 (PDT) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DYZN14538 for ; Wed, 8 Aug 2001 06:34:35 -0700 (PDT) Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id JAA16443 for ; Wed, 8 Aug 2001 09:34:34 -0400 (EDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <0GHR00L0149T91@lmco.com> for ietf-ldup@imc.org; Wed, 8 Aug 2001 09:32:18 -0400 (EDT) Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <0GHR00CZU49NEK@lmco.com> for ietf-ldup@imc.org; Wed, 08 Aug 2001 09:32:11 -0400 (EDT) Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 08 Aug 2001 09:32:16 -0400 Content-return: allowed Date: Wed, 08 Aug 2001 09:32:16 -0400 From: "Slone, Skip" Subject: LDAP/X.500 alignment To: "LDUP Mailing List (ietf-ldup@imc.org)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_NRWbFDlTj3NdJeaaeMKGHQ)" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_NRWbFDlTj3NdJeaaeMKGHQ) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_xXzVs+KJHzQzQbKd/A7QXg)" --Boundary_(ID_xXzVs+KJHzQzQbKd/A7QXg) Content-type: text/plain Content-Transfer-Encoding: 7BIT In yesterday's LDUP meeting, I agreed to send a pointer to the current working draft on LDAP/X.500 alignment. Unfortunately, I just realized the document is no longer posted on the server. It's 360KB in PDF format, so it didn't seem prudent to broadcast it to the list, so if anyone wants a copy, please send me an email and I will send you one. Thanks, -- Skip Slone --Boundary_(ID_xXzVs+KJHzQzQbKd/A7QXg) Content-type: text/html Content-Transfer-Encoding: 7BIT Message
In yesterday's LDUP meeting, I agreed to send a pointer to the current working draft on LDAP/X.500 alignment.  Unfortunately, I just realized the document is no longer posted on the server.  It's 360KB in PDF format, so it didn't seem prudent to broadcast it to the list, so if anyone wants a copy, please send me an email and I will send you one.
 
Thanks,
 
 -- Skip Slone
 
 
 
--Boundary_(ID_xXzVs+KJHzQzQbKd/A7QXg)-- --Boundary_(ID_NRWbFDlTj3NdJeaaeMKGHQ) Content-type: application/octet-stream; name="Skip Slone.vcf" Content-disposition: attachment; filename="Skip Slone.vcf" Content-transfer-encoding: BASE64 Comments: Conversion error: (No formatted text for errno = 0) Content-Transfer-Encoding: BASE64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOlNsb25lO1NraXANCkZOOlNraXAg U2xvbmUNCk9SRzpMb2NraGVlZCBNYXJ0aW47Q2hpZWYgVGVjaG5vbG9neSBPZmZp Y2UNClRJVExFOkNoaWVmIEFyY2hpdGVjdCwgRGlyZWN0b3J5IGFuZCBOYW1pbmcg U2VydmljZXMNCk5PVEU7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo9MEQ9MEEN ClRFTDtXT1JLO1ZPSUNFOisxICg0MDcpIDMwNi03MTAyDQpURUw7Q0VMTDtWT0lD RTorMSAoNDA3KSAyNTctMjQ1Mg0KVEVMO1dPUks7RkFYOisxICg0MDcpIDMwNi0x MzkyDQpURUw7SE9NRTtGQVg6KzEgKDIwOCkgNTQ1LTk2NzUNCkFEUjtXT1JLOjs7 MTI1MDYgTGFrZSBVbmRlcmhpbGwgUmQuICwgTVAgODQ1O09ybGFuZG87Rkw7MzI4 MjU7VVNBDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6MTI1 MDYgTGFrZSBVbmRlcmhpbGwgUmQuICwgTVAgODQ1PTBEPTBBT3JsYW5kbywgRkwg MzI4MjU9MEQ9MEFVU0ENCkVNQUlMO1BSRUY7SU5URVJORVQ6c2tpcC5zbG9uZUBs bWNvLmNvbQ0KUkVWOjIwMDEwNDA1VDE5MDkzM1oNCkVORDpWQ0FSRA0K --Boundary_(ID_NRWbFDlTj3NdJeaaeMKGHQ)-- From owner-ietf-ldup@mail.imc.org Wed Aug 8 10:05: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 KAA12943 for ; Wed, 8 Aug 2001 10:05:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78DkB814805 for ietf-ldup-bks; Wed, 8 Aug 2001 06:46:11 -0700 (PDT) Received: from trurl.it.su.se (trurl.it.su.se [130.237.95.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78Dk9N14798 for ; Wed, 8 Aug 2001 06:46:09 -0700 (PDT) Received: (from leifj@localhost) by trurl.it.su.se (8.9.3/8.9.3) id PAA05479; Wed, 8 Aug 2001 15:46:04 +0200 Date: Wed, 8 Aug 2001 15:46:04 +0200 From: Leif Johansson To: "Slone, Skip" Cc: "LDUP Mailing List (ietf-ldup@imc.org)" Subject: Re: LDAP/X.500 alignment Message-ID: <20010808154604.H5385@trurl.it.su.se> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from skip.slone@lmco.com on Wed, Aug 08, 2001 at 09:32:16AM -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Aug 08, 2001 at 09:32:16AM -0400, Slone, Skip wrote: > In yesterday's LDUP meeting, I agreed to send a pointer to the current > working draft on LDAP/X.500 alignment. Unfortunately, I just realized the > document is no longer posted on the server. It's 360KB in PDF format, so it > didn't seem prudent to broadcast it to the list, so if anyone wants a copy, > please send me an email and I will send you one. > > Thanks, I mirror ftp.bull.com at ftp://ftp.it.su.se/pub/mirrors/ftp.bull.com. It might be there -- haven't checked yet. Cheers Leif From owner-ietf-ldup@mail.imc.org Wed Aug 8 10:59: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 KAA14253 for ; Wed, 8 Aug 2001 10:59:49 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f78EYWs16069 for ietf-ldup-bks; Wed, 8 Aug 2001 07:34:32 -0700 (PDT) Received: from mailgw1a.lmco.com (mailgw1a.lmco.com [192.31.106.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78EYUN16064 for ; Wed, 8 Aug 2001 07:34:30 -0700 (PDT) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw1a.lmco.com (8.8.8/8.8.8) with ESMTP id IAA22007; Wed, 8 Aug 2001 08:34:30 -0600 (MDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <0GHR0090171SPA@lmco.com>; Wed, 8 Aug 2001 10:32:16 -0400 (EDT) Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <0GHR00LXS71N2C@lmco.com>; Wed, 08 Aug 2001 10:32:11 -0400 (EDT) Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 08 Aug 2001 10:32:16 -0400 Content-return: allowed Date: Wed, 08 Aug 2001 10:32:15 -0400 From: "Slone, Skip" Subject: RE: LDAP/X.500 alignment To: "'Leif Johansson'" Cc: "LDUP Mailing List (ietf-ldup@imc.org)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Yes, it is still there!! The URL is: ftp://ftp.it.su.se/pub/mirrors/ftp.bull.com/pub/OSIdirectory/Geneva2001/TD%2 520Output/TD3044R1LDAPalignment2ndWD.pdf Thanks! -- Skip -----Original Message----- From: Leif Johansson [mailto:leifj@it.su.se] Sent: Wednesday, August 08, 2001 2:46 PM To: Slone, Skip Cc: LDUP Mailing List (ietf-ldup@imc.org) Subject: Re: LDAP/X.500 alignment On Wed, Aug 08, 2001 at 09:32:16AM -0400, Slone, Skip wrote: > In yesterday's LDUP meeting, I agreed to send a pointer to the current > working draft on LDAP/X.500 alignment. Unfortunately, I just realized > the document is no longer posted on the server. It's 360KB in PDF > format, so it didn't seem prudent to broadcast it to the list, so if > anyone wants a copy, please send me an email and I will send you one. > > Thanks, I mirror ftp.bull.com at ftp://ftp.it.su.se/pub/mirrors/ftp.bull.com. It might be there -- haven't checked yet. Cheers Leif From owner-ietf-ldup@mail.imc.org Mon Aug 13 10:24:00 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 KAA20978 for ; Mon, 13 Aug 2001 10:23:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DE2Ic20804 for ietf-ldup-bks; Mon, 13 Aug 2001 07:02:18 -0700 (PDT) Received: from ns.oncalldba.com (cpe-66-1-184-87.ut.sprintbbd.net [66.1.184.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DE2HN20799 for ; Mon, 13 Aug 2001 07:02:17 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.11.0) with SMTP id f7DE2CB18438 for ; Mon, 13 Aug 2001 08:02:12 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Mon, 13 Aug 2001 08:04:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 13 Aug 2001 08:04:38 -0600 From: "Ed Reed" To: , Subject: 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 f7DE2IN20801 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, all - At the IETF in London the working group chairs of the LDUP and (late) LDUPEXT working groups considered the issues raised surrounding the LDAP Subentries draft I've been working on. Their decision, as related to me, was to ask that the LDUP information model be revised so that object classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no longer are treated as subentries, and that the work on the LDAP Subentries as a standards track document be ended. So, the draft is hereby withdrawn from work group consideration. The basis of the decision was that since the Access Control editors have decided not to use LDAP Subentries in their document, and since they were the only other charter-item document in the works that might have referenced the document, there appears to be insufficient interest in generalizing a variant from the X.500 version of Subentries to be worth continuing in the working group. There is a strongly felt (and forcefully expressed) feeling among several folks in the working group that there is no reason to "dummy down" the X.500 Subentry specification. So we won't. Thank you all for your patience in this matter... Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Mon Aug 13 11:43:29 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 LAA22442 for ; Mon, 13 Aug 2001 11:43:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DFFZp24515 for ietf-ldup-bks; Mon, 13 Aug 2001 08:15:35 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DFFYN24511 for ; Mon, 13 Aug 2001 08:15:34 -0700 (PDT) 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 LAA358118 for ; Mon, 13 Aug 2001 11:13:22 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7DF7TZ45980 for ; Mon, 13 Aug 2001 11:07:29 -0400 To: ietf-ldup@imc.org Subject: Re: Subentries decision - internet draft withdrawn X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Mon, 13 Aug 2001 11:15:00 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/13/2001 11:15:21 AM, Serialize complete at 08/13/2001 11:15:21 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00524F1885256AA7_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00524F1885256AA7_= Content-Type: text/plain; charset="us-ascii" Ed, Thanks for the summary. Was the concensus that we not use subentries at ALL with respect to the information model - i.e. just use "regular entries" for this information? This seems very easy to do at the expense of these entries "showing up" in the directory when they otherwise might not be expected. Of course, access controls and/or search filters would probably keep them from showing up in most cases anyway. I'll get to work on re-aligning the LDUP information model draft. 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 "Ed Reed" 08/13/2001 10:04 AM To: , cc: Subject: Subentries decision - internet draft withdrawn Hello, all - At the IETF in London the working group chairs of the LDUP and (late) LDUPEXT working groups considered the issues raised surrounding the LDAP Subentries draft I've been working on. Their decision, as related to me, was to ask that the LDUP information model be revised so that object classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no longer are treated as subentries, and that the work on the LDAP Subentries as a standards track document be ended. So, the draft is hereby withdrawn from work group consideration. The basis of the decision was that since the Access Control editors have decided not to use LDAP Subentries in their document, and since they were the only other charter-item document in the works that might have referenced the document, there appears to be insufficient interest in generalizing a variant from the X.500 version of Subentries to be worth continuing in the working group. There is a strongly felt (and forcefully expressed) feeling among several folks in the working group that there is no reason to "dummy down" the X.500 Subentry specification. So we won't. Thank you all for your patience in this matter... Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_alternative 00524F1885256AA7_= Content-Type: text/html; charset="us-ascii"
Ed,

Thanks for the summary.

Was the concensus that we not use subentries at ALL with respect to the information model - i.e. just use "regular entries" for this information?  This seems very easy to do at the expense of these entries "showing up" in the directory when they otherwise might not be expected.  Of course, access controls and/or search filters would probably keep them from showing up in most cases anyway.

I'll get to work on re-aligning the LDUP information model draft.
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


"Ed Reed" <eer@OnCallDBA.COM>

08/13/2001 10:04 AM

       
        To:        <ietf-ldup@imc.org>, <ietf-ldapext@netscape.com>
        cc:        
        Subject:        Subentries decision - internet draft withdrawn

       


Hello, all -

At the IETF in London the working group chairs of the LDUP and (late) LDUPEXT working groups considered the issues raised surrounding the LDAP Subentries draft I've been working on.  Their decision, as related to me, was to ask that the LDUP information model be revised so that object classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no longer are treated as subentries, and that the work on the LDAP Subentries as a standards track document be ended.

So, the draft is hereby withdrawn from work group consideration.

The basis of the decision was that since the Access Control editors have decided not to use LDAP Subentries in their document, and since they were the only other charter-item document in the works that might have referenced the document, there appears to be insufficient interest in generalizing a variant from the X.500 version  of Subentries to be worth continuing in the working group.  There is a strongly felt (and forcefully expressed) feeling among several folks in the working group that there is no reason to "dummy down" the X.500 Subentry specification.  So we won't.

Thank you all for your patience in this matter...

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

--=_alternative 00524F1885256AA7_=-- From owner-ietf-ldup@mail.imc.org Mon Aug 13 13:07: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 NAA25047 for ; Mon, 13 Aug 2001 13:07:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DGif301319 for ietf-ldup-bks; Mon, 13 Aug 2001 09:44:41 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DGidN01315 for ; Mon, 13 Aug 2001 09:44:40 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 13 Aug 2001 10:44:24 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Mon, 13 Aug 2001 10:42:25 -0600 From: "Jim Sermersheim" To: , , 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 f7DGieN01316 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hmm, I wonder how many other drafts refer to it. I know the password policy draft does. I forsee a whole bunch of 'special' auxilliary objectclasses being defined that carry subtree policy semantics. >>> "Ed Reed" 08/13/01 08:04AM >>> Hello, all - At the IETF in London the working group chairs of the LDUP and (late) LDUPEXT working groups considered the issues raised surrounding the LDAP Subentries draft I've been working on. Their decision, as related to me, was to ask that the LDUP information model be revised so that object classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no longer are treated as subentries, and that the work on the LDAP Subentries as a standards track document be ended. So, the draft is hereby withdrawn from work group consideration. The basis of the decision was that since the Access Control editors have decided not to use LDAP Subentries in their document, and since they were the only other charter-item document in the works that might have referenced the document, there appears to be insufficient interest in generalizing a variant from the X.500 version of Subentries to be worth continuing in the working group. There is a strongly felt (and forcefully expressed) feeling among several folks in the working group that there is no reason to "dummy down" the X.500 Subentry specification. So we won't. Thank you all for your patience in this matter... Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Mon Aug 13 13:13: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 NAA25238 for ; Mon, 13 Aug 2001 13:13:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DGqPC01545 for ietf-ldup-bks; Mon, 13 Aug 2001 09:52:25 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.21]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DGqNN01539 for ; Mon, 13 Aug 2001 09:52:23 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id M0813-1252-378d00; Mon, 13 Aug 2001 16:52:11 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HDCA4>; Mon, 13 Aug 2001 12:51:45 -0400 Message-ID: From: Christopher Apple To: "'Timothy Hahn'" , ietf-ldup@imc.org Subject: RE: Subentries decision - internet draft withdrawn Date: Mon, 13 Aug 2001 12:51:44 -0400 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_000F_01C123F6.1A6D4420" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C123F6.1A6D4420 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0010_01C123F6.1A705160" ------=_NextPart_001_0010_01C123F6.1A705160 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0011_01C123F6.1A705160" ------=_NextPart_002_0011_01C123F6.1A705160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This was more of a recommendation from the LDAP-related Co-Chairs for how to proceed with the document than anything like consensus at this stage. Concensus around our recommendation will have to be gauged based on mailing list discussion of the revised information model document. Chris Apple Program Manager - Directory Services United Messaging Inc. < http://www.unitedmessaging.com > < mailto:christopher.apple@unitedmessaging.com > (V) 610-425-2860 -----Original Message----- From: Timothy Hahn [mailto:hahnt@us.ibm.com] Sent: Monday, August 13, 2001 11:15 AM To: ietf-ldup@imc.org Subject: Re: Subentries decision - internet draft withdrawn Ed, Thanks for the summary. Was the concensus that we not use subentries at ALL with respect to the information model - i.e. just use "regular entries" for this information? This seems very easy to do at the expense of these entries "showing up" in the directory when they otherwise might not be expected. Of course, access controls and/or search filters would probably keep them from showing up in most cases anyway. I'll get to work on re-aligning the LDUP information model draft. 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 "Ed Reed" 08/13/2001 10:04 AM To: , cc: Subject: Subentries decision - internet draft withdrawn Hello, all - At the IETF in London the working group chairs of the LDUP and (late) LDUPEXT working groups considered the issues raised surrounding the LDAP Subentries draft I've been working on. Their decision, as related to me, was to ask that the LDUP information model be revised so that object classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no longer are treated as subentries, and that the work on the LDAP Subentries as a standards track document be ended. So, the draft is hereby withdrawn from work group consideration. The basis of the decision was that since the Access Control editors have decided not to use LDAP Subentries in their document, and since they were the only other charter-item document in the works that might have referenced the document, there appears to be insufficient interest in generalizing a variant from the X.500 version of Subentries to be worth continuing in the working group. There is a strongly felt (and forcefully expressed) feeling among several folks in the working group that there is no reason to "dummy down" the X.500 Subentry specification. So we won't. Thank you all for your patience in this matter... Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM ------=_NextPart_002_0011_01C123F6.1A705160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This=20 was more of a recommendation from the LDAP-related = Co-Chairs
for=20 how to proceed with the document than anything like=20 consensus
at=20 this stage. Concensus around our recommendation will have to=20 be
gauged=20 based on mailing list discussion of the revised=20 information
model=20 document.

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

-----Original Message-----
From: Timothy Hahn=20 [mailto:hahnt@us.ibm.com]
Sent: Monday, August 13, 2001 = 11:15=20 AM
To: ietf-ldup@imc.org
Subject: Re: Subentries = decision=20 - internet draft withdrawn


Ed,

Thanks = for the=20 summary.

Was the = concensus that we=20 not use subentries at ALL with respect to the information model - i.e. = just=20 use "regular entries" for this information?  This seems very easy = to do=20 at the expense of these entries "showing up" in the directory when = they=20 otherwise might not be expected.  Of course, access controls = and/or=20 search filters would probably keep them from showing up in most cases=20 anyway.

I'll get to = work on=20 re-aligning the LDUP information model draft.

Regards,
Tim Hahn

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



"Ed Reed"=20 <eer@OnCallDBA.COM>=20

08/13/2001 10:04 AM =

        =
        To: =    =20    <ietf-ldup@imc.org>,=20 <ietf-ldapext@netscape.com>
        cc:      =20  
    =  =20   Subject:        Subentries decision - = internet draft withdrawn

 =20      


Hello, all -

At the IETF in = London the=20 working group chairs of the LDUP and (late) LDUPEXT working groups = considered=20 the issues raised surrounding the LDAP Subentries draft I've been = working on.=20  Their decision, as related to me, was to ask that the LDUP = information=20 model be revised so that object classes defined there for = ReplicaSubentry and=20 ReplicaAgreementSubentry no longer are treated as subentries, and that = the=20 work on the LDAP Subentries as a standards track document be = ended.

So,=20 the draft is hereby withdrawn from work group = consideration.

The basis=20 of the decision was that since the Access Control editors have decided = not to=20 use LDAP Subentries in their document, and since they were the only = other=20 charter-item document in the works that might have referenced the = document,=20 there appears to be insufficient interest in generalizing a variant = from the=20 X.500 version  of Subentries to be worth continuing in the = working group.=20  There is a strongly felt (and forcefully expressed) feeling = among=20 several folks in the working group that there is no reason to "dummy = down" the=20 X.500 Subentry specification.  So we won't.

Thank you all = for your=20 patience in this = matter...

Ed

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Ed=20 Reed
Reed-Matthews, Inc.
+1 801 796=20 = 7065
http://www.Reed-Matthews.COM



<= /BODY> ------=_NextPart_002_0011_01C123F6.1A705160-- ------=_NextPart_001_0010_01C123F6.1A705160 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris 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:20010621T205341Z END:VCARD ------=_NextPart_001_0010_01C123F6.1A705160-- ------=_NextPart_000_000F_01C123F6.1A6D4420 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDgxMzE2NDcyMlowIwYJKoZIhvcNAQkEMRYEFP+AHw+lmVRXQFUsavJgDV2pTmSsMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAPvtlYdiM A8yiGodY9AT5gVjBaZKTOX+IH/3qfN3pKEOB/QvTBqiMM295oi4HdEec/YWdbBvpMFzkCehPoHKa iKHyaVaavja++M/sXF3r//X/ItXQKXpGlH+MjjRoIK74+jCeA9P5xhRANyg0qH+AVGxlOEiNpTSC kVcVUpJJ4H4AAAAAAAA= ------=_NextPart_000_000F_01C123F6.1A6D4420-- From owner-ietf-ldup@mail.imc.org Mon Aug 13 13:48: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 NAA25954 for ; Mon, 13 Aug 2001 13:48:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DHP6r02520 for ietf-ldup-bks; Mon, 13 Aug 2001 10:25:06 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.234]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DHP5N02515 for ; Mon, 13 Aug 2001 10:25:05 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id M0813-1324-6e5200; Mon, 13 Aug 2001 17:24:53 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HDCB3>; Mon, 13 Aug 2001 13:24:27 -0400 Message-ID: From: Christopher Apple To: "'Jim Sermersheim'" , ietf-ldup@imc.org, ietf-ldapext@netscape.com, eer@OnCallDBA.COM Subject: RE: Subentries decision - internet draft withdrawn Date: Mon, 13 Aug 2001 13:24:26 -0400 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_01C123FA.A9761990" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C123FA.A9761990 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0001_01C123FA.A977A030" ------=_NextPart_001_0001_01C123FA.A977A030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Comments below.... Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: Jim Sermersheim [mailto:JIMSE@novell.com] >Sent: Monday, August 13, 2001 12:42 PM >To: ietf-ldup@imc.org; ietf-ldapext@netscape.com; eer@OnCallDBA.COM >Subject: Re: Subentries decision - internet draft withdrawn > > >Hmm, I wonder how many other drafts refer to it. I know the >password policy draft does. Here's the list I've found, please post any missing I-D URLs to the list if you know of them: http://search.ietf.org/internet-drafts/draft-reed-ldup-inheritance-00.tx t (indirectly) http://search.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt http://search.ietf.org/internet-drafts/draft-behera-ldap-password-policy -04.txt http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-08.txt > >I forsee a whole bunch of 'special' auxilliary >objectclasses being defined that carry subtree policy semantics. That's the idea... Chris. > >>>> "Ed Reed" 08/13/01 08:04AM >>> > >Hello, all - > >At the IETF in London the working group chairs of the LDUP >and (late) LDUPEXT working groups considered the issues >raised surrounding the LDAP Subentries draft I've been >working on. Their decision, as related to me, was to ask >that the LDUP information model be revised so that object >classes defined there for ReplicaSubentry and >ReplicaAgreementSubentry no longer are treated as >subentries, and that the work on the LDAP Subentries as a >standards track document be ended. > >So, the draft is hereby withdrawn from work group consideration. > >The basis of the decision was that since the Access Control >editors have decided not to use LDAP Subentries in their >document, and since they were the only other charter-item >document in the works that might have referenced the >document, there appears to be insufficient interest in >generalizing a variant from the X.500 version of >Subentries to be worth continuing in the working group. >There is a strongly felt (and forcefully expressed) feeling >among several folks in the working group that there is no >reason to "dummy down" the X.500 Subentry specification. >So we won't. > >Thank you all for your patience in this matter... > >Ed > >================= >Ed Reed >Reed-Matthews, Inc. >+1 801 796 7065 >http://www.Reed-Matthews.COM > > ------=_NextPart_001_0001_01C123FA.A977A030 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris 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:20010621T205341Z END:VCARD ------=_NextPart_001_0001_01C123FA.A977A030-- ------=_NextPart_000_0000_01C123FA.A9761990 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDgxMzE3MjAwM1owIwYJKoZIhvcNAQkEMRYEFGri6XeCN00GVhCfjfMy9EkEMvXYMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAJAC62GRS VnKb/qZ5ezMkOg8TUcXrVYA66bzuzQT4jZXvc4yNSyGo6gyvaCLw+Y5JJisHCvw+N1I+1ozy8vNq Mo7SbnSdugcTG9wXlXNU4zW5FQ9kHgjsuaqjJ7ppQkb3diMOazfFPY5h+XYDZD29uvHFMvCqjkbx E9iMPvKc5VEAAAAAAAA= ------=_NextPart_000_0000_01C123FA.A9761990-- From owner-ietf-ldup@mail.imc.org Mon Aug 13 18:53: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 SAA29892 for ; Mon, 13 Aug 2001 18:53:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DMVVq10392 for ietf-ldup-bks; Mon, 13 Aug 2001 15:31:31 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DMVUN10388 for ; Mon, 13 Aug 2001 15:31:30 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id G0813-1831-323f00; Mon, 13 Aug 2001 22:31:24 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HDCHZ>; Mon, 13 Aug 2001 18:30:58 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Subject: WG Last Call on URP I-D Date: Mon, 13 Aug 2001 18:30:51 -0400 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_00C3_01C12425.7BC5B930" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C12425.7BC5B930 Content-Type: multipart/mixed; boundary="----=_NextPart_001_00C4_01C12425.7BC5B930" ------=_NextPart_001_00C4_01C12425.7BC5B930 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 the LDUP Update Reconciliation Procedures I-D document. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.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 document, believes that all the known outstanding issues have been addressed, and is ready to put the document 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 Tuesday, September 4, 2001 at 1830 US ET. 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 documents are revised. We then ask our ADs to put forward the revised documents 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 two-week last call to the entire IETF, 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 - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_00C4_01C12425.7BC5B930 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris 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:20010621T205341Z END:VCARD ------=_NextPart_001_00C4_01C12425.7BC5B930-- ------=_NextPart_000_00C3_01C12425.7BC5B930 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDgxMzIyMjYzNVowIwYJKoZIhvcNAQkEMRYEFMLgWOV/aBs/Q4YHMBagDSzSc4uyMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAT+z5cpmK q8vhxRKJcbztV0cf3bHWTX0WKwJmF+LimfU4t1i4icgXoEaZ51PNi8jDG1q/o/0k+02l69/pIh7d L2Awk6kdwVkFo/R9BQskiUgQWJ5S7RvNw+M1q4r3LxqD0sip4lZBBjgQbQoX8ltF+F1lnSLiYGkF YtLwhhEZ3h4AAAAAAAA= ------=_NextPart_000_00C3_01C12425.7BC5B930-- From owner-ietf-ldup@mail.imc.org Mon Aug 13 22:36: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 WAA03912 for ; Mon, 13 Aug 2001 22:36:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7E2EJ015622 for ietf-ldup-bks; Mon, 13 Aug 2001 19:14:19 -0700 (PDT) Received: from ns.oncalldba.com (cpe-66-1-184-87.ut.sprintbbd.net [66.1.184.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E2E9N15617 for ; Mon, 13 Aug 2001 19:14:09 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.11.0) with SMTP id f7E2E1B18928 for ; Mon, 13 Aug 2001 20:14:01 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Mon, 13 Aug 2001 20:16:32 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 13 Aug 2001 20:16:09 -0600 From: "Ed Reed" To: , , 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 f7E2EJN15619 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yeah - the idea is that just making them "regular" entries should cause the least impact on LDUP InfoMod. That seems better, now, than referencing some yet-to-be-written LDAP expression of the X.500 subentry. It is interesting to note the extent to which subtree refinement of X.500 addresses one of the LDUP incomplete replica objectives - identification of entries of certain object classes, right? But not selected attributes...still need the attribute filters if we want to support that. So - We'll just make the SUP TOP instead of ldapsubentries and keep going. We'll need to bring the scope discussion from the LdapSubentries doc back into infomod... but does that mean we need to bring in the administrative model discussion as a description of the LDUP specific administrative area and it's management...probably. Oh, we'll probably need to define structure rules to define the intended containment of the Replica and ReplicaAgreement object classes...can we say Replica entries are only allowed to be contained by ReplicionContext Aux Classes? Ed >>> Christopher Apple 08/13/01 10:51AM >>> This was more of a recommendation from the LDAP-related Co-Chairs for how to proceed with the document than anything like consensus at this stage. Concensus around our recommendation will have to be gauged based on mailing list discussion of the revised information model document. Chris Apple Program Manager - Directory Services United Messaging Inc. < http://www.unitedmessaging.com > < mailto:christopher.apple@unitedmessaging.com > (V) 610-425-2860 -----Original Message----- From: Timothy Hahn [mailto:hahnt@us.ibm.com] Sent: Monday, August 13, 2001 11:15 AM To: ietf-ldup@imc.org Subject: Re: Subentries decision - internet draft withdrawn Ed, Thanks for the summary. Was the concensus that we not use subentries at ALL with respect to the information model - i.e. just use "regular entries" for this information? This seems very easy to do at the expense of these entries "showing up" in the directory when they otherwise might not be expected. Of course, access controls and/or search filters would probably keep them from showing up in most cases anyway. I'll get to work on re-aligning the LDUP information model draft. 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 "Ed Reed" 08/13/2001 10:04 AM To: , cc: Subject: Subentries decision - internet draft withdrawn Hello, all - At the IETF in London the working group chairs of the LDUP and (late) LDUPEXT working groups considered the issues raised surrounding the LDAP Subentries draft I've been working on. Their decision, as related to me, was to ask that the LDUP information model be revised so that object classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no longer are treated as subentries, and that the work on the LDAP Subentries as a standards track document be ended. So, the draft is hereby withdrawn from work group consideration. The basis of the decision was that since the Access Control editors have decided not to use LDAP Subentries in their document, and since they were the only other charter-item document in the works that might have referenced the document, there appears to be insufficient interest in generalizing a variant from the X.500 version of Subentries to be worth continuing in the working group. There is a strongly felt (and forcefully expressed) feeling among several folks in the working group that there is no reason to "dummy down" the X.500 Subentry specification. So we won't. Thank you all for your patience in this matter... Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Thu Aug 16 07:21: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 HAB28703 for ; Thu, 16 Aug 2001 07:21:55 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GB3fb05240 for ietf-ldup-bks; Thu, 16 Aug 2001 04:03:41 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GB3dN05236 for ; Thu, 16 Aug 2001 04:03:40 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28184; Thu, 16 Aug 2001 07:02:27 -0400 (EDT) Message-Id: <200108161102.HAA28184@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-framing-profile-00.txt Date: Thu, 16 Aug 2001 07:02:27 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : Profile for Framing LDAPv3 Operations Author(s) : R. Harrison Filename : draft-ietf-ldup-framing-profile-00.txt Pages : 5 Date : 15-Aug-01 The document 'LDAPv3: Grouping of Related Operations' [GROUPING] specifies a set of LDAPv3 operations and an LDAPv3 control that can be used to identify and manage sets of LDAP operations that are members of related groups. Collectively, these 'grouping' constructs provide a general framework for defining specific LDAPv3 grouping types with their associated processing semantics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-framing-profile-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-framing-profile-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: <20010815145129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-framing-profile-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-framing-profile-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010815145129.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Aug 17 15:02: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 PAA12860 for ; Fri, 17 Aug 2001 15:02:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HIObZ03744 for ietf-ldup-bks; Fri, 17 Aug 2001 11:24:37 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.202]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HIOZN03740 for ; Fri, 17 Aug 2001 11:24:36 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id S0817-1424-0dfa00; Fri, 17 Aug 2001 18:24:33 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HD1M0>; Fri, 17 Aug 2001 14:24:00 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" , "'ietf-ldapbis@openldap.org'" Subject: FW: the 4th edition of X.500 Date: Fri, 17 Aug 2001 14:23:58 -0400 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_01C12727.9FC7BE00" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C12727.9FC7BE00 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0001_01C12727.9FCACB40" ------=_NextPart_001_0001_01C12727.9FCACB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI. Chris Apple Program Manager - Integration Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0001_01C12727.9FCACB40 Content-Type: message/rfc822 Content-Disposition: attachment From: "Hoyt L. Kesterson II" To: "OSI Directory List" , "IETF LDAP" Subject: the 4th edition of X.500 Date: Fri, 17 Aug 2001 13:42:50 -0400 Message-ID: <"QSTuWC.A.PAC.coVf7"@glacier> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Hello all Revised drafts (V5) of the 4th edition of X.500/9594, excluding X.509/9594-8, have been placed on the server in pdf and word formats at ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ The revised texts do not contain any major changes, e.g. defect resolution or amendments. Most of the changes made are editorial. These documents are being prepared for publishing but we will attempt to incorporate the correction of any errors that are identified before publishing. Comments on these drafts should be directed to Erik Andersen (era.als@get2net.dk) and me (hoyt.kesterson@earthlink.net). hoyt ------=_NextPart_001_0001_01C12727.9FCACB40 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris 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:20010621T205341Z END:VCARD ------=_NextPart_001_0001_01C12727.9FCACB40-- ------=_NextPart_000_0000_01C12727.9FC7BE00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDgxNzE4MTkyOFowIwYJKoZIhvcNAQkEMRYEFGUbvC0Q9WtughKEn+Bcy88TbNuoMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAouJf16xu Y2fwnQCEwd2U6XodJ1/kBPtFnj0GKNK/TvaNVut7LX9Vk3DiYNv7zamOVffcAe/XBVbE3kxJsvsS Irm8argtz5VkIsQDPJtm/FcTc/2fwQz8QRMBCcsDPLJdg7t5DLoHXWPXqZSlds7qOP5ZvPayq3hi yw9nZPQiU6oAAAAAAAA= ------=_NextPart_000_0000_01C12727.9FC7BE00-- From owner-ietf-ldup@mail.imc.org Fri Aug 17 16:50: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 QAA15027 for ; Fri, 17 Aug 2001 16:50:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKYEY05978 for ietf-ldup-bks; Fri, 17 Aug 2001 13:34:14 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HKYCN05974 for ; Fri, 17 Aug 2001 13:34:12 -0700 (PDT) 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 QAA341260 for ; Fri, 17 Aug 2001 16:32:01 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7HKQDT49558 for ; Fri, 17 Aug 2001 16:26:13 -0400 Subject: Re: WG Last Call on URP I-D To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Fri, 17 Aug 2001 15:37:44 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 08/17/2001 03:37:47 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=86256AAB007151C58f9e8a93df938690918c86256AAB007151C5" Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=86256AAB007151C58f9e8a93df938690918c86256AAB007151C5 Content-type: text/plain; charset=us-ascii Hi all, We have reviewed the LDUP Update Resolution Procedures Internet Draft (draft-ietf-ldup-urp-04.txt) and have the following comments. 1. Section 4.4, second para. It seems that a glue entry ought to be used when breaking DIT loops. The glue entry would contain the DN of the entry's parent at the time it was moved to Lost & Found. Without this, there is nothing to tell an administrator where this entry originally came from. We also note that glue entries are ill-defined at best in many documents, and it is not clear whether statements that "a glue entry has knowledge only of its name" is meant to imply that is knows the DN of the entry it represents, or that a glue entry has its RDN (entryuuid=x) as its only attribute. 2. Section 5.1.3, b and c. You might note that Section 5.2 will show why attribute value deletion records are not required in these cases. Under (d), you might note that d) covers the special case for replace where a replace with no attribute values is treated as a attribute deletion. 3. Section 5.2, 1st para. Clarify that supplier is scanning entry, attribute, and value CSNs. Current wording could leave one to think the supplier is just looking at entry CSNs. In the second paragraph, "A p-add-entry primitive is generated for each entry whose entry CSN is greater than the Update Vector CSN for the same replica." what does "same replica" refer to? Consumer replica? 4. Section 5.3.5, 2nd para. Could improve the grammar of the 3rd sentnce by changing "If not, it disambiguates the names of the entries by adding the Unique Identifier (i.e. the entryUUID attribute) of each of the conflicting entries to their own RDN" to "... to each entry's RDN." 5. Section 5.3.5, CheckUniqueness function: IF E.rdn is empty make C.uid distinguished Please explain this test. Why are we checking to see if the entry has no RDN, and IF so, make the OLD conflicting entry's name contain the UID? Perhaps make C.uid distinguished should be make E.uid distinguished? 6. Section 5.3.5, just before RenameEntry(E,P). The pareter description is missing the name of the second parameter. Perhaps: "The parameters to this procedure are the entry, E, and the p-add-entry or p-rename-entry primitive, P, specifying the new RDN." ", P," was missing. 7. Section 5.3.5, RenameEntry(E,P). After V.csn := GenerateNextCSN(V.csn) Should a log-based implementation log a primitive for this change? We think so. The above comment also applies to 5.3.7 and 5.3.8. 8. Section 5.3.6. replace V with P.value if they are not identical Shouldn't this be: replace V with P.value if they are not identical AND the type is single-valued? 9. Section 5.3.8 FOREACH attribute value, V, of type P.type in E (if any) IF P.csn > V.csn IF V is distinguished IF ProtectDistinguished() V.csn := GenerateNextCSN(P.csn) ELSE { R := E.rdn remove value V CheckUniqueness(E, E.superior, R) } ELSE remove value V >>> StoreAttributeDeletion (P.uid, P.type, P.csn) If ProtectDistinguished() is TRUE, then the attribute deletion is false. We should store Attribute Value deletions for all NON-distinguished values - or, store an Attribute deletion and an attribute ADD for the distinguished value. 10. Section 5.3.11 and 5.3.12. Where we create glue entries, i.e. E := CreateGlueEntry(P.uid) Shouldn't this be followed by: E.superior = LOST_AND_FOUND 11. Section 5.3.12 replace V with N.value if they are not identical Shouldn't this be: replace V with N.value if they are not identical AND the type is single-valued? 12. Section 5.3.11. We have two additional concerns with the p-move-entry primitive. As written, it appears that Lost and Found of the participating replicas do not all end up in the same state. Also, by moving entries directly under Lost & Found, information about the original parent of the entry is lost. We suggest that p-move-entry place entries under a glue entry that has knowledge of the original parent DN. The following example illustrates the first concern: Consider the following DIT: o=A L & F | ------------ | | ou=B ou=C And suppose there are two replicas, 1 & 2. at t1: client on server 1 moves ou=C beneath ou=B at t2: client on server 2 moves ou=B beneath ou=C DITs on each server now look like: Server 1: Server 2: o=A o=A | | ------------ ------------ | | | | ou=B ou=C | | ou=C ou=B at t3: server 1 receives updates from server 2 p-move-entry(B, t2, C) This results in a loop, and the resolution is to move B to L&F at t4: server 2 receives updates from server 1 p-move-entry(C, t1, B) This results in a loop, and the resolution is to move C to L&F Final outcome: Server 1: Server 2: o=A L & F o=A L & F | | | | glue entry glue entry | | ou=B ou=C | | ou=C ou=B We ended up with differing outcomes in Lost and Found. An administrator making a correction based on the outcome at replica 1 might chose to move B (and C with it) back under A. At replica 2, this would result in C being left in Lost and Found. That illustrates the problem. Possible solution: When a DIT loop is detected, resolve the conflict by individually moving each entry in the loop into Lost and Found. In my simple example above, since the loop involves only the entries ou=B and ou=C, each of these entries would be moved to Lost and Found: o=A L & F | | --------------- | | glue entry glue entry | | ou=C ou=B Section 5.3.11 could be rewritten as: << start of change >> 5.3.11 Processing Move Entry Primitive This section details the algorithm for processing the p-move-entry (P.uid, P.superior, P.csn) primitive, which describes the moving of an entry to a new immediate superior in the DIT. If the new superior | specified by the primitive does not exist, then the entry is moved to | Lost & Found. If the new superior is a direct or indirect subordinate | of the entry being moved, then each entry in the path from the entry | being moved and its new superior is moved to Lost & Found | instead. IF no entry deletion record (uid, csn) exists where (uid = P.uid AND csn > P.csn) { IF entry, E, with uid = P.uid does not exist E := CreateGlueEntry(P.uid) IF P.csn > E.superior.csn { R := E.rdn O := E.superior IF entry, S, with uid = P.superior does not exist S := CreateGlueEntry(P.superior) | S.superior := LOST_AND_FOUND IF S is not in the subtree of E { E.superior := P.superior E.superior.csn = P.csn | CheckUniqueness(E, O, R) } ELSE { FOR each entry, M, in the path from | S to E (including entries S and E) | { | G := CreateGlueEntry(M.superior) | G.superior := LOST_AND_FOUND | M.superior := G | M.superior.csn := GenerateNextCSN(P.csn) | } } } } << end of change >> Note that this also moves the CheckUniqueness procedure into the "successful move" leg. If CheckUniquenes should also be applied to the entries moved into Lost and Found, then the CheckUniqueness procedure should also be applied to each entry, M, moved into Lost and Found. John McMeeking OS/400 Directory Services jmcmeek@us.ibm.com (507)253-4596 Christopher Apple aging.net> cc: Sent by: Subject: WG Last Call on URP I-D owner-ietf-ldup@mail.imc.org 08/13/2001 05:30 PM The purpose of this message is to initiate the LDUP Working Group last call on the LDUP Update Reconciliation Procedures I-D document. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.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 document, believes that all the known outstanding issues have been addressed, and is ready to put the document 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 Tuesday, September 4, 2001 at 1830 US ET. 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 documents are revised. We then ask our ADs to put forward the revised documents 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 two-week last call to the entire IETF, 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 - Directory Services United Messaging Inc. (V) 610-425-2860 #### Chris Apple (E-mail).vcf has been removed from this note on August 16 2001 by John McMeeking #### smime.p7s has been removed from this note on August 16 2001 by John McMeeking --0__=86256AAB007151C58f9e8a93df938690918c86256AAB007151C5 Content-type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDgxMzIyMjYzNVowIwYJKoZIhvcNAQkEMRYEFMLgWOV/aBs/Q4YHMBagDSzSc4uyMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAT+z5cpmK q8vhxRKJcbztV0cf3bHWTX0WKwJmF+LimfU4t1i4icgXoEaZ51PNi8jDG1q/o/0k+02l69/pIh7d L2Awk6kdwVkFo/R9BQskiUgQWJ5S7RvNw+M1q4r3LxqD0sip4lZBBjgQbQoX8ltF+F1lnSLiYGkF YtLwhhEZ3h4AAAAAAAAA --0__=86256AAB007151C58f9e8a93df938690918c86256AAB007151C5-- From subs-reminder@imc.org Thu Aug 23 23:18: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 XAA07807 for ; Thu, 23 Aug 2001 23:18:41 -0400 (EDT) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id f7O3Juo05459; Thu, 23 Aug 2001 20:19:56 -0700 (PDT) Date: Thu, 23 Aug 2001 20:19:56 -0700 (PDT) Message-Id: <200108240319.f7O3Juo05459@above.proper.com> To: ldup-archive@ietf.org Subject: [[325569942]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From subs-reminder@imc.org Thu Aug 23 23:22: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 XAA07852 for ; Thu, 23 Aug 2001 23:22:49 -0400 (EDT) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id f7O3O4K06039; Thu, 23 Aug 2001 20:24:04 -0700 (PDT) Date: Thu, 23 Aug 2001 20:24:04 -0700 (PDT) Message-Id: <200108240324.f7O3O4K06039@above.proper.com> To: ldup-archive@ietf.org Subject: [[449638473]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ldup@mail.imc.org Fri Aug 24 12:35: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 MAA08967 for ; Fri, 24 Aug 2001 12:35:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OG64v23271 for ietf-ldup-bks; Fri, 24 Aug 2001 09:06:04 -0700 (PDT) Received: from tconl91223.tconl.com ([66.9.206.226]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7OG62D23267 for ; Fri, 24 Aug 2001 09:06:02 -0700 (PDT) Received: (qmail 1127 invoked by uid 500); 24 Aug 2001 16:03:35 -0000 Date: Fri, 24 Aug 2001 11:03:35 -0500 From: Ryan Moats To: ietf-ldup@imc.org Subject: Re: WG Last Call on URP I-D Message-ID: <20010824110334.A919@armada.local.windrose.omaha.ne.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from christopher.apple@UnitedMessaging.net on Mon, Aug 13, 2001 at 06:30:51PM -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I sat down last night and did a pass comparing between URP and the requirements document. Others may want to do this as well, because where I found an acceptable explanation, others may not. What I seemed to miss was the discussion of primitive generation with respect to attribute types, attribute subtypes and attribute options. Specifically there was no clarification - whether attribute subtypes and options were or were not supported. I believe absense of a restriction means they are, but others could read absense of a restriction to mean they are not. - whether or not dsaOperation types could be replicated. Since the requirements draft states this as a MUST NOT (req G10), the lack of a discussion in the primitive generation portion of the document disturbs me. Ryan From owner-ietf-ldup@mail.imc.org Fri Aug 24 13:19: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 NAA10070 for ; Fri, 24 Aug 2001 13:19:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OGosb24733 for ietf-ldup-bks; Fri, 24 Aug 2001 09:50:54 -0700 (PDT) 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 f7OGoqD24729 for ; Fri, 24 Aug 2001 09:50:52 -0700 (PDT) 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 f7OGo2C21763; Fri, 24 Aug 2001 16:50:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010824093137.00b11a58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Aug 2001 09:49:57 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on URP I-D Cc: "'ietf-ldup@imc.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think the editors need to review the document to ensure all necessary normative references are in place. The document appears to be dependent on LCUP (for entryUUID) and a variety of other LDUP documents but contains no reference to them. I note as well that no other LDUP document formally references this specification. As such, I am unsure of the context in which this specification is meant to be used and hence find it hard to perform a complete review. I note the only context I have from the I-D is LDAPv3 and X.500, both which provide no support for multiple master replication and, hence, have no need for such procedures. It seems the Abstract and Introduction need more work to detail the context in which this specification is used. Kurt At 06:30 AM 8/13/2001, Christopher Apple wrote: >The purpose of this message is to initiate the LDUP >Working Group last call on the LDUP Update >Reconciliation Procedures I-D document. > >WHAT DOCUMENT? > >The document in last call is: > >http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.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 >document, believes that all the known outstanding issues >have been addressed, and is ready to put the document >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 Tuesday, September 4, 2001 at 1830 US ET. > >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 documents are revised. We then ask our ADs to put > forward the revised documents 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 two-week last call to the entire IETF, 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 - Directory Services >United Messaging Inc. > > >(V) 610-425-2860 > From owner-ietf-ldup@mail.imc.org Sat Aug 25 14:03: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 OAA13412 for ; Sat, 25 Aug 2001 14:03:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7PHiiG09205 for ietf-ldup-bks; Sat, 25 Aug 2001 10:44:44 -0700 (PDT) Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PHigD09201 for ; Sat, 25 Aug 2001 10:44:42 -0700 (PDT) Received: from FARILJCS (dialup-63.208.131.102.Dial1.SanFrancisco1.Level3.net [63.208.131.102]) by robin.mail.pas.earthlink.net (8.11.5/8.9.3) with SMTP id f7PHido06603 for ; Sat, 25 Aug 2001 10:44:40 -0700 (PDT) Reply-To: From: "John Strassner" To: "'Ietf-Ldup@Imc. Org'" Subject: DRAFT Minutes of the 51st meeting for your review Date: Sat, 25 Aug 2001 10:44:39 -0700 MIME-Version: 1.0 Message-ID: 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_0021_01C12D52.F0021100" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C12D52.F0021100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings LDUPers, below please find the draft meeting minutes for the London meeting. Apologies for the late delay - apparently this was never successfully delivered. Please submit any comments and corrections to me asap so=20 that I can include these in the official minutes. And thanks=20 presenters, I already have all of your slides for inclusion. regards, John Strassner and Chris Apple LDUP WG Co-Chairs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D SNIP HERE = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D DRAFT Summary and Meeting Minutes LDUP Working Group Meeting 51st IETF,=20 London Minutes recorded by John Strassner and Tim Hahn Tuesday, 7 August, 2001 0a) Review of Proposed Agenda Patrik wanted to add a statement on the status of the Appeal. Otherwise, no comments. 0b) IESG Appeal Patrik Falstrom reported that there has been nothing further with respect to the appeal made just before the last IETF. He also=20 noted that the official IESG response to the appeal had been=20 mosted on the working group. Thus, this issue is now closed. 1) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/ draft-ietf-ldup-replica-req-10.txt This draft passed WG Last Call, and a request has been sent to the Applications Area ADs for IESG Review. 2) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt The archive was recently polled to ensure that all open issues have been answered. Since this has been confirmed, this draft=20 will go to working group last call on Monday AFTER the IETF (8/13). The last call will last for approximately 3 weeks. 3) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt Ed Reed reported that no work has been done since the last=20 meeting, due to the requirements document not being finalized. Now that the requirements doc is done, Ed has started going thru the document doing a detailed compliance matrix. This is about 50% done. The focus is to point out where the req=20 document mandates a specific behavior and the arch document=20 differs. This is also being done for the info arch document. PDF to be mailed within 30 days. 4) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt Tim Hahn presented an overview of the current status of this draft. The replicaSubEntry and replicaAgreementSubentry object classes=20 were obseleted, and replaced by two new updated object classes (replicaSubEntry2 and replicaAgreementSubentry2). Two new object classes to control scheduling (replicaEventSchedule and=20 replicaTimeSchedule), and their associated attributes, were defined. Also defined where the replication context exists on the server, and defined attributes that must appear in the server=92s=20 root DSE entry as part of the LDUP information model. Clarified the notion that the updateVector is a replicated=20 attribute and should be treated as such. Note that it has CSN information for its attribute values. Also introduced the notion that replicaAgreementSubentry2 entries represent constraints to what is, by default, "immediate" replication session initiation. (The following will be clearer if the reader refers to the powerpoint presentation, slide 5, that is attached in the proceedings). Attributes in rootDSE (in dark blue oval) are there to define the various replication contexts that exist in the server. There are two replicas on this server with separate replication contexts. There are two replica agreements for each replication context. There are ldapSubEntry derivatives just below the replication contexts that represent information about replication = agreements. The default behavior is "fully-connected", "immediate" replication. Note that there is a further constraint of a time schedule for one of the replication agreements. Added attribute = replicaSubentries to point to the replica agreements. Q: Why did you need the second attribute pointing to particular replica subentries? A: Because there is a replication agreement for each replication context. One attribute specifies which replication area (naming=20 context), other specifies which replica subentry is being used (i.e., which policy is being used). Q: does that lead to a relational integrity requirement on the=20 administrator? A: Yes, but it was thought that the benefit outweighed the=20 extra overhead. Comments that have been received are being incorporated into the=20 next version of the draft. These include: - OIDs are incorrect (Will be updated in next revision) - Attrs1 and attrs2 attributes in replicaEventSchedule are too=20 generically named (Will be renamed to attrsForClassX) - A couple object classes that have been made obsolete were=20 accidentally removed from the draft (Will be fixed in next revision) Ed Reed then noted that the policy information regarding=20 scheduling and event-driven operations could be more richly=20 defined. Policy is a "rich opportunity". The current draft has=20 only defined a limited set of scheduling capabilities, the=20 limits being limits on the time periods for which replication=20 suppliers would initiate and define replication sessions. The=20 authors haven=92t defined how a replica would accept such=20 connections. This was because the authors were looking forward to a richer policy language that would be available in the future, and to not preclude the use of such a language. Event-driven=20 includes a default time period for defining replication. Policy-driven includes a ptpCondition from RFC3060 (periodic, not event driven).=20 These would be implemented as a control. ReplicaSubEntry has a=20 Boolean that specifies offline or online =96 won=92t start replicating=20 till you turn it on. The Info model document could be revised in a month =96 everything is=20 editorial EXCEPT that it also depends on subentries. [editor's note: the fate of subentries will be decided soon].=20 5) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt Ed Reed reported on this work.=20 Version =968 created after last IETF in Minneapolis. Removed the=20 inheritance model that was in the previous version of the draft and=20 added an administration model which was a subset of X.500, except=20 that it used LDAPSubentries. Autonomous admin area may have=20 specific admin subareas, which may be (but don=92t have to be)=20 partitioned into smaller areas for specific uses. There was quite a bit of discussion on subEntries on the list. Ed=20 notes that LDAP subentries were created, consciously, as a subset of the X.500 subentry model. So, why not just use X.500? There are three main reasons. First, wanted to use name subordination to describe explicit=20 relationships through nested subentries =96 this approach seemed=20 more elegant than maintaining a set of DNs, and it is easier to=20 maintain referential integrity. X.500 doesn=92t allow nested=20 subentries today (though this may be relaxed in the future through=20 means such as families of subentries). So without nesting, it=20 would require "dn-pointers" which bring other problems with respect=20 to referential integrity. Second, naming flexibility =96 X.500 mandates the use of CN for=20 naming, and some people in the LDAP community want more flexibility. Third is scooping: purpose of LDAP subentry is to define a profile of = X.500. It doesn=92t allow refinements, and Ed is worried that this is = too powerful a tool for too na=EFve an audience. This last point leads into refinement. It was thought that the=20 X.500 refinement mechanism may be too powerful a gun to hand=20 to 65,000 MCSEs and NCSEs to use to manage file access=20 (for instance), must less to the managers and secretaries to=20 whom they delegate ACI management to. The full X.500 administrative model provides DSETypes to mark=20 special entries. The X.500 administrative model also explicitly expects SINGLE master today ...and therefore some invention is=20 required to go with LDAP MULTI-master.=20 On the other hand, if X.500 subentries -> DSETypes, and DSETypes -> DSP (chaining), and DSP -> multimaster DISP, and multimaster DISP -> interoperable HOB, then maybe a converged=20 X.500/LDUP is the distributed directory service that is needed. There are two obvious alternatives: - just do X.500, which implies that we form a new workgroup to achieve X.500/LDAP/LDUP convergence - adopt the useful subset defined in ldapSubEntry work. This means that we should work with the X.500 group to converge=20 on nesting, and decide whether CN (or some other attribute) should be used naming Kurt: in order to split some issues apart to effectively manage, you need SOME sort of "refinement mechanism" - without it, you can't do delegation and coalescing of policy information. Requirements for access controls also seem to require a "refinement mechanism". Ed: Disagrees. For example, Novell and Microsoft don=92t do this. Kurt: Then it isn=92t compliant with 2820. In addition, if=20 access control chooses another mechanism, then this would be=20 bad. Kurt volunteers to define an alternate approach. Mark Wahl: RFC 2251 does not REQUIRE you to implement X.500 subentries/refinement. The use of CN is a bad thing for=20 applications that want to automatically create these things=20 without collision. Why not choose some "subset" of the=20 refinement in the X.500 subentry refinement capability? Ed: we did - the "NULL" refinement implies the "whole subtree until the next subentry" LOTS of discussion on this item, but no concensus was raised. Therefore, this discussion will be taken to the list. John and=20 Chris will arrange a meeting with the LDAPext and LDAPbis=20 co-chairs to mutually discuss what should be done regading LDUP subentires. The implication to this (the infomod) document is that ALL replication agreement infomration would have to be=20 under a single "root entry" (i.e. peers) and delimited by=20 (perhaps) names of the subentries. This boils down to: - allow nesting - X.500 shouldn't have a problem - allow other naming besides cn - X.500 shouldn't have a problem - not have refinement - X.500 probably would NOT like this ... and thus LDAP would diverge from X.500 ... and this is not good Skip Sloan (X.500 rep) indicated that X.500 would be amenable to adding nesting and non-cn naming Action: co-chairs will respond to the list after the minutes.=20 Need to talk with other co-chairs about an overall strategy. 6) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/ draft-ietf-ldup-usage-profile-01.txt Steven: what is the document actually trying to accomplish? It=20 doesn=92t seem to address how LDUP is used. It instead seems to describe some of the operating characteristics/concerns when using replication. It should instead show what/how replication=20 SHOULD be used/set up.Example: unordered changes =96 if someone=20 is using an implementation with unordered changes, then they=20 haven=92t implemented URP and aren=92t using the replication=20 architecture. Kurt: thought that this was supposed to be an applicability=20 statement to define the minimum requirements needed to support=20 LDUP. This document clearly doesn=92t do this (in fact, it is=20 informational). So where is the applicability statement, we need one. Chris: this seems to be correct, this info will be taken back to the authors. You should post these comments to the list also. 7) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-01.txt Mark Wahl reported on behalf of the authors that the LCUP changes from =9600 to =9601 consisted of adding an OID to specify the algorithm=20 for making the cookie. Also added an operational attribute to=20 specify the supported algorithms. Kurt: can this document define A cookie format, leaving it open to allow other drafts to create OTHER cookie formats - and then let=20 this workgroup attempt to limit the set of cookie formats defined. Roger Harrison - sounds like we're starting to try to allow=20 potentially more than one server to be able to interpret a single cookie instance ... and this is not the intent. Rick recommends that we declare this explicitly OUT of scope Jim Sermersheim: there is some language implying that re-connection (to some other server possibly) and re-start/re-use of the cookie is supported Kurt: we need to narrow the focus of what LCUP specification does; maybe explicitly add that the cookie is NOT reusable to a=20 different server One technical comment: why isn=92t the list of supported cookies in=20 the RootDSE. It seems reasonable to make this change. OID issue: 1) don=92t standardize and hope for the best 2) standardize a minimum subset of OIDs that vendors must=20 support, which gives you interoperability among the OIDs, 3) LCUP cookies don=92t matter (VLV cookie interoperability). Kurt: have LCUP specify "a" cookie format, and leave it open for=20 other cookie formats to be specified in the future. Co-Chairs will have to re-examine the mailing list and make a = recommendation. Some additional concern as to what we allow the cookie to be used=20 for. But first, we need to define the applicability of first,=20 the protocol, and second, the cookie. For example, if it is just one client and one server, then you wouldn=92t need to define the=20 format of the cookie at all. On the other hand, if you want to=20 share the cookie between servers, that=92s a completely different=20 case and would probably require the specification of a cookie. 8) Adding LCUP Cookie Scheme(s) to LDUP WG Charter as Deliverables? The discussion of this item was merged with item 7). 9) LDAP Access Control Model Work The focus of this agenda item was to ferret out any concerns that=20 people had on the ACM work to ensure that these would not affect LDUP. It was noted that the model document does not define how access=20 control will work in a replicated environment. The LDUP general=20 usage profile document is a good job of indicating lots of things (besides access control) that are affected when replication is added to the environment. Open question to group by Chris Apple with respect to what outstanding problems people have with the access control model and replication? Kurt: model document still lists access control as not defined=20 how access control works in a replicated environment. There is=20 a need for LDUP folks to read and comment on the current=20 ACL model draft. 10) Definition of an object class to hold LDAP change records Mark Wahl reported that this draft by Ludwic describes the old=20 changelog format. It is useful in some of the previous sync tools,=20 such as persistent and triggered search, that have now been=20 folded into LCUP. This document is not suitable for a server that is doing LDUP with multi-master. However, if you are doing LCUP=20 or another constrained environment, it is useful. It was proposed that this should be progressed as an INFORMATIONAL RFC. LDUPers are encouraged to comment on it. 10) General Charter Review The following updates can be made to the charter: - update the repl reqs to WG last call date - update reconciliation procedures to WG last call=20 to be August - update the multi-master replication profile, master-slave replication profile are by the=20 same authors as general usage profile - so need a new date for all or drop them - information model: +30 days from decision on ldapSubEntry (i.e., if ldapSubEntry stays, then this document will be submitted in 30 days from that decision; otherwise, a=20 new approach and date will be defined) - architecture: +30 days from information model - LDAP mandatory replica management draft "up in the air" - need to get current status from Ryan Moats - LDAP update replication protocol to be published +30 days from now (8/7/2001) - LDAP Extended Ops for Framing can go to WG last call, though it is co-dependent on Kurt Zelienga's grouping I-D, so they will be last called together within 30 days from now - LCUP I-D to WG last call no later than December 2001 The time left in the meeting was spent on discussing how to better align with X.500. Chris Harding (from The Open Group) stated that many customer=20 requirements are requesting alignment between X.500 and LDAP. How's it going to happen? Ed: it is time and appropriate for the LDAP community to reciprocate with what the X.500 team has started, i.e. LDAP alignment. One thing to help interoperability - where solutions were created that are=20 aligned closely with X.500 solutions - we shouldn't create new ones. Skip Sloan - common solutions are good - but where not practical, proper subsets are preferable. Where not possible, please advise Skip that a difference exists and LDAP has gone "above" X.500. Ed Reed and Kurt Zelienga recommended NOT making this a part of The End. ------=_NextPart_000_0021_01C12D52.F0021100 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 AQkFMQ8XDTAxMDgyNTE3NDQzOFowIwYJKoZIhvcNAQkEMRYEFDEcm2L4N6/l4+ezPga5JV+XaGK8 MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGADPk9 ucboJuHGEA2PxWXPyny5Kk0O1H8SO60jmj/MdwbBsfu9U7OMfK+AspiM7bBwNLQYunBti4yiv9Dh 8xcTgBkJsW+5S9mw3/lWoyRUk76MN/paUTGOD+8zXUt/gsuzSWrWdFWB6BCPIRMijoCqWSVCjNbe v8amzTCLQKCyTsMAAAAAAAA= ------=_NextPart_000_0021_01C12D52.F0021100-- From owner-ietf-ldup@mail.imc.org Mon Aug 27 01:42: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 BAA25667 for ; Mon, 27 Aug 2001 01:42:17 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7R5LvT21251 for ietf-ldup-bks; Sun, 26 Aug 2001 22:21:57 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7R5LsD21247 for ; Sun, 26 Aug 2001 22:21:54 -0700 (PDT) Received: (qmail 26 invoked from network); 27 Aug 2001 05:30:00 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 27 Aug 2001 05:30:00 -0000 Reply-To: From: "Steven Legg" To: , "'Ietf-Ldup@Imc. Org'" Subject: RE: DRAFT Minutes of the 51st meeting for your review Date: Mon, 27 Aug 2001 16:22:41 +1100 Message-ID: <019201c12eb8$4c5789b0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit John Strassner wrote: > Greetings LDUPers, > > below please find the draft meeting minutes for the London meeting. > Apologies for the late delay - apparently this was never successfully > delivered. Please submit any comments and corrections to me asap so > that I can include these in the official minutes. > 6) General Usage Profile for LDAPv3 Replication > > http://www.ietf.org/internet-drafts/ > draft-ietf-ldup-usage-profile-01.txt > > > > Steven: what is the document actually trying to accomplish? It > doesn’t seem to address how LDUP is used. It instead seems to > describe some of the operating characteristics/concerns when > using replication. It should instead show what/how replication > SHOULD be used/set up.Example: unordered changes – if someone > is using an implementation with unordered changes, then they > haven’t implemented URP and aren’t using the replication > architecture. Somewhere along the line the sense of the example got reversed. The example should read "if someone's implementation does not support unordered changes, then they haven't implemented URP and aren't using the replication architecture". Regards, Steven