From owner-ietf-ldup@mail.imc.org Sat Nov 1 02:02:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06017 for ; Sat, 1 Nov 2003 02:02:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA16rWkT049740 for ; Fri, 31 Oct 2003 22:53:32 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA16rWgY049739 for ietf-ldup-bks; Fri, 31 Oct 2003 22:53:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA16rVkT049677 for ; Fri, 31 Oct 2003 22:53:31 -0800 (PST) (envelope-from c.apple@comcast.net) Received: from d7st2111 (pcp086396pcs.audubn01.nj.comcast.net[68.44.129.64]) by comcast.net (rwcrmhc12) with SMTP id <2003110106532901400cce54e> (Authid: c.apple@comcast.net); Sat, 1 Nov 2003 06:53:29 +0000 Reply-To: From: "Chris Apple" To: Subject: E-mail trouble Date: Sat, 1 Nov 2003 01:52:55 -0500 Message-ID: <000501c3a044$cc83dd00$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There seems to be something wrong with inbound mail for my work account. If you are trying reach me directly before the IETF meeting About the WG session, the agenda, or other WG business, please Use my personal e-mail address: c.apple@comcast.net I have subscribed to the LDUP list from that address so I should pick up all postings from now until the meeting. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Nov 4 13:31:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26789 for ; Tue, 4 Nov 2003 13:31:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4IL0kT066191 for ; Tue, 4 Nov 2003 10:21:01 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4IL059066190 for ietf-ldup-bks; Tue, 4 Nov 2003 10:21:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4IKxkT066180 for ; Tue, 4 Nov 2003 10:20:59 -0800 (PST) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA4IKtYJ308190 for ; Tue, 4 Nov 2003 13:20:55 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA4IKrkb073828 for ; Tue, 4 Nov 2003 13:20:53 -0500 Subject: persistent search To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Tue, 4 Nov 2003 12:20:52 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 11/04/2003 12:20:53 PM 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: Are there any plans to publish persistent search in any form? Is there something other than an expired internet draft that could be referenced as the "standard" for this feature? Having been implemented by at least a few servers and clients, I think some sort of formal document (IETF or otherwise) would be useful. John McMeeking From owner-ietf-ldup@mail.imc.org Tue Nov 4 16:29:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06591 for ; Tue, 4 Nov 2003 16:29:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LDKkT072900 for ; Tue, 4 Nov 2003 13:13:20 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4LDJiK072899 for ietf-ldup-bks; Tue, 4 Nov 2003 13:13:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LDJkT072891 for ; Tue, 4 Nov 2003 13:13:19 -0800 (PST) (envelope-from MarkCSmithWork@aol.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id hA4LDCR27712 for ; Tue, 4 Nov 2003 13:13:12 -0800 (PST) Received: from aol.com ([10.169.192.97]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HNUIXZ02.R46; Tue, 4 Nov 2003 13:13:11 -0800 Message-ID: <3FA81666.4030003@aol.com> Date: Tue, 04 Nov 2003 16:13:10 -0500 From: markcsmithwork@aol.com (Mark C Smith) Organization: America Online, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: John McMeeking CC: ietf-ldup@imc.org Subject: Re: persistent search References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John McMeeking wrote: > > Are there any plans to publish persistent search in any form? Is there > something other than an expired internet draft that could be referenced as > the "standard" for this feature? Having been implemented by at least a few > servers and clients, I think some sort of formal document (IETF or > otherwise) would be useful. A couple of years ago, I mentioned that I planned to ask that PS be published as an Informational RFC. A couple of people mentioned that they'd rather not have that happen because it might confuse people who are looking for the standards track "answer", e.g., LCUP. But I still think it would be useful to publish PS as Information because there are multiple implementations, etc. -Mark From owner-ietf-ldup@mail.imc.org Wed Nov 5 00:16:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23856 for ; Wed, 5 Nov 2003 00:16:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA558RkT088874 for ; Tue, 4 Nov 2003 21:08:27 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA558RQJ088873 for ietf-ldup-bks; Tue, 4 Nov 2003 21:08:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA558QkT088868 for ; Tue, 4 Nov 2003 21:08:26 -0800 (PST) (envelope-from gvithalprasad@novell.com) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 04 Nov 2003 22:08:24 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 04 Nov 2003 22:08:07 -0700 From: "Vithalprasad Gaitonde" To: Subject: Re: persistent search Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think it makes sense to have an informational RFC rathar no spec at all since PS did find a fair level of usage. Prasad >>> Mark C Smith 11/5/2003 2:43:10 AM >>> John McMeeking wrote: > > Are there any plans to publish persistent search in any form? Is there > something other than an expired internet draft that could be referenced as > the "standard" for this feature? Having been implemented by at least a few > servers and clients, I think some sort of formal document (IETF or > otherwise) would be useful. A couple of years ago, I mentioned that I planned to ask that PS be published as an Informational RFC. A couple of people mentioned that they'd rather not have that happen because it might confuse people who are looking for the standards track "answer", e.g., LCUP. But I still think it would be useful to publish PS as Information because there are multiple implementations, etc. -Mark From owner-ietf-ldup@mail.imc.org Wed Nov 5 07:11:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02410 for ; Wed, 5 Nov 2003 07:11:53 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5C12kT075470 for ; Wed, 5 Nov 2003 04:01:04 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5C0xhr075463 for ietf-ldup-bks; Wed, 5 Nov 2003 04:00:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from nb2.stroeder.com (du-006-197.access.de.clara.net [212.82.229.197]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5C0dkT075228 for ; Wed, 5 Nov 2003 04:00:51 -0800 (PST) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id E24087F1B6; Wed, 5 Nov 2003 13:00:22 +0100 (CET) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id D011250FC1; Wed, 5 Nov 2003 13:00:21 +0100 (CET) Message-ID: <3FA8E655.50707@stroeder.com> Date: Wed, 05 Nov 2003 13:00:21 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Mark C Smith Cc: ietf-ldup@imc.org Subject: Re: persistent search References: <3FA81666.4030003@aol.com> In-Reply-To: <3FA81666.4030003@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark C Smith wrote: > > But I still > think it would be useful to publish PS as Information because there are > multiple implementations, etc. +1 Ciao, Michael. From owner-ietf-ldup@mail.imc.org Wed Nov 5 15:22:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22408 for ; Wed, 5 Nov 2003 15:22:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5KD7kT098295 for ; Wed, 5 Nov 2003 12:13:07 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5KD74Y098294 for ietf-ldup-bks; Wed, 5 Nov 2003 12:13:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [216.98.200.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5KD6kT098273 for ; Wed, 5 Nov 2003 12:13:06 -0800 (PST) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pcp086396pcs.audubn01.nj.comcast.net [68.44.129.64]) by echt.caledonia.net; Wed, 05 Nov 2003 13:12:27 -0700 Reply-To: From: "Chris Apple" To: , Subject: LDUP WG Meeting Agenda Date: Wed, 5 Nov 2003 15:11:57 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000b01c3a3d9$17bed940$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDUP WG Meeting Agenda ====================== TUESDAY, November 11, 2003 1415-1515 Afternoon Sessions II Rochester APP ldup LDAP Duplication/Replication/Update Protocols WG 1. Agenda Additions? 2. General WG Status Report from the Co-Chairs: + LCUP approved for publication as a Proposed Standard. + We believe we're ready to conclude once documents clear WG Last Call. + WG Last Calls will be initiated after the Minneapolis meeting based on discussion around proposal(s) from the WG Co-Chairs for how to manage WG Last Calls of multiple documents. 3. The drafts: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-04.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-02.txt 4. Managing WG Last Call for several documents. 5. Final tasks to conclude the WG. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Wed Nov 5 16:01:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23634 for ; Wed, 5 Nov 2003 16:01:51 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5KrekT000136 for ; Wed, 5 Nov 2003 12:53:40 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Kre9x000135 for ietf-ldup-bks; Wed, 5 Nov 2003 12:53:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5KrdkT000122 for ; Wed, 5 Nov 2003 12:53:39 -0800 (PST) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA5KrXYJ140568; Wed, 5 Nov 2003 15:53:33 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA5KrX0M220612; Wed, 5 Nov 2003 15:53:33 -0500 Subject: Re: LDUP WG Meeting Agenda To: ietf-ldup@imc.org, X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Wed, 5 Nov 2003 14:53:31 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 11/05/2003 02:53:33 PM 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: The ldup protocol draft is about to expire, but beyond some editorial work, it should be ready for last call when the others go. I was waiting to make sure we didn't do anything in InfoMod or MRM that required changes. I'll get this out once the conference is over. Changes required: - cleaning up reference section - add previos authors as significant contributor - delete empty ASN.1 appendix. All operations and responses are defined in the main document. - change intended category to Experimental John McMeeking From owner-ietf-ldup@mail.imc.org Tue Nov 11 16:01:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21764 for ; Tue, 11 Nov 2003 16:01:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKo1kT020689 for ; Tue, 11 Nov 2003 12:50:01 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKo1fg020688 for ietf-ldup-bks; Tue, 11 Nov 2003 12:50:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKo0kT020678 for ; Tue, 11 Nov 2003 12:50:00 -0800 (PST) (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 11 Nov 2003 13:49:57 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 11 Nov 2003 13:49:28 -0700 From: "Jim Sermersheim" To: Subject: Standardization of change sequence number Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartE5BB6648.0__=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartE5BB6648.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I (and I believe others) would like to see the change sequence number syntax be progressed in a standards-track document. Of those initially interested in this, I believe consensus is that it should be defined as a complex type (using ASN.1). A string encoding would be defined (which would likely look just like the one in draft-ietf-ldup-infomod-xx.txt). Then matching rules would be defined in terms of the complext type (not the string encoding). Do the authors of the relevant LDUP I-Ds want to participate in the act of pulling out the current LdapChangeSequenceNumber, and referring to a new I-D, or would they rather just leave it alone (in order to more quickly achieve last call), and let any new I-D progress without being referred to? Jim --=__PartE5BB6648.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
I (and I believe others) would like to see the change sequence number syntax be progressed in a standards-track document. Of those initially interested in this, I believe consensus is that it should be defined as a complex type (using ASN.1). A string encoding would be defined (which would likely look just like the one in draft-ietf-ldup-infomod-xx.txt). Then matching rules would be defined in terms of the complext type (not the string encoding).
 
Do the authors of the relevant LDUP I-Ds want to participate in the act of pulling out the current LdapChangeSequenceNumber, and referring to a new I-D, or would they rather just leave it alone (in order to more quickly achieve last call), and let any new I-D progress without being referred to?
 
Jim
--=__PartE5BB6648.0__=-- From owner-ietf-ldup@mail.imc.org Wed Nov 12 11:22:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25255 for ; Wed, 12 Nov 2003 11:22:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGDTkT031910 for ; Wed, 12 Nov 2003 08:13:29 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACGDTVb031909 for ietf-ldup-bks; Wed, 12 Nov 2003 08:13:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGDQkT031895 for ; Wed, 12 Nov 2003 08:13:27 -0800 (PST) (envelope-from steven.legg@adacel.com.au) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Thu, 13 Nov 2003 03:06:06 +1100 Received: (qmail 1585 invoked from network); 12 Nov 2003 16:13:19 -0000 Received: from unknown (HELO belinda) (10.32.252.2) by nexus.adacel.com with SMTP; 12 Nov 2003 16:13:19 -0000 From: "Steven Legg" To: "Jim Sermersheim" , Subject: RE: Standardization of change sequence number Date: Thu, 13 Nov 2003 03:15:58 +1100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C3A994.761D1FE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.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_0000_01C3A994.761D1FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jim, As editor of the URP document, I don't mind changing that document to reference a proposed standard definition for the change sequence number in the form outlined below. To avoid slowing the LDUP publication schedule, the CSN document would have to be produced immediately. Regards, Steven -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jim Sermersheim Sent: Wednesday, 12 November 2003 7:49 AM To: ietf-ldup@imc.org Subject: Standardization of change sequence number I (and I believe others) would like to see the change sequence number syntax be progressed in a standards-track document. Of those initially interested in this, I believe consensus is that it should be defined as a complex type (using ASN.1). A string encoding would be defined (which would likely look just like the one in draft-ietf-ldup-infomod-xx.txt). Then matching rules would be defined in terms of the complext type (not the string encoding). Do the authors of the relevant LDUP I-Ds want to participate in the act of pulling out the current LdapChangeSequenceNumber, and referring to a new I-D, or would they rather just leave it alone (in order to more quickly achieve last call), and let any new I-D progress without being referred to? Jim ------=_NextPart_000_0000_01C3A994.761D1FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Jim,
 
As editor of=20 the URP document, I don't mind changing that document to reference=20 a
proposed=20 standard definition for the change sequence number in the form=20 outlined
below. To=20 avoid slowing the LDUP publication schedule, the CSN document=20 would
have to be=20 produced immediately.
 
Regards,
Steven
-----Original Message-----
From:=20 owner-ietf-ldup@mail.imc.org = [mailto:owner-ietf-ldup@mail.imc.org]On Behalf=20 Of Jim Sermersheim
Sent: Wednesday, 12 November 2003 = 7:49=20 AM
To: ietf-ldup@imc.org
Subject: Standardization = of=20 change sequence number

I (and I believe others) would like to see the change sequence = number=20 syntax be progressed in a standards-track document. Of those initially = interested in this, I believe consensus is that it should be defined = as a=20 complex type (using ASN.1). A string encoding would be defined (which = would=20 likely look just like the one in draft-ietf-ldup-infomod-xx.txt). Then = matching rules would be defined in terms of the complext type (not the = string=20 encoding).
 
Do the authors of the relevant LDUP I-Ds want to participate in = the act=20 of pulling out the current LdapChangeSequenceNumber, and referring to = a new=20 I-D,  or would they rather just = leave it=20 alone (in order to more quickly achieve last call), and let any new = I-D=20 progress without being referred to?
 
Jim
------=_NextPart_000_0000_01C3A994.761D1FE0-- From owner-ietf-ldup@mail.imc.org Wed Nov 12 13:55:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01759 for ; Wed, 12 Nov 2003 13:55:32 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACIhEkT037950 for ; Wed, 12 Nov 2003 10:43:15 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACIhEMZ037949 for ietf-ldup-bks; Wed, 12 Nov 2003 10:43:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACIhBkT037931 for ; Wed, 12 Nov 2003 10:43:11 -0800 (PST) (envelope-from c.apple@comcast.net) Received: from d7st2111 (rrcs-west-65-29-226-39.biz.rr.com[65.29.226.39]) by comcast.net (rwcrmhc13) with SMTP id <2003111218430501500aig7he> (Authid: c.apple@comcast.net); Wed, 12 Nov 2003 18:43:07 +0000 Reply-To: From: "Chris Apple" To: "'Steven Legg'" , "'Jim Sermersheim'" , Subject: RE: Standardization of change sequence number Date: Wed, 12 Nov 2003 13:42:41 -0500 Message-ID: <002201c3a94c$c60e4b20$d5c8a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C3A922.DD384320" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: 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_0023_01C3A922.DD384320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There will more than likely be some slippage from the WG Last Call = schedule discussed during the WG Meeting even if the CSN document is published as soon as possible after the I-D Administrator starts processing I-Ds again. =20 Then the information model document would have to be revised before we = could start the first grouping of WG Last Call documents mentioned during the WG Meeting. =20 As co-chair I'm OK with pulling the CSN content out as a separate standards-track document if: =20 1) It is published as an LDUP WG document rather than an individual contribution. I realize that the rationale is that its applicability is broader than LDUP, but I'm = skittish about suggestions to increase the dependency of the WG's deliverables on documents not = within the control of any WG. This has caused problems before and I don't want to add more of = that type of risk. =20 2) It is submitted to the I-D Editor as soon as possible after they = begin accepting new submissions. =20 3) The new CSN LDUP I-D is included in the WG Last Call grouping of the first document that will reference it, INFOMOD. =20 4) The INFOMOD Document Editors are able to submit the revised INFOMOD = draft within a couple of days of the CSN I-D Action announcement occurring. =20 Keep in mind that if we go that way, we are introducing uncertainty in starting the WG Last Call sequence as discussed during the WG Meeting. This is not really a good = thing from a process perspective, but does seem to be the right thing to do from a document management perspective. =20 I'll wait to see some postings from other WG Members (especially need to hear from the INFOMOD Editors) before making a judgment call on this. This means that the = first grouping WG Last Call won't happen as planned on the Monday after the IETF. =20 INFOMOD Editors: please respond ASAP. =20 Chris Apple=20 -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] = On Behalf Of Steven Legg Sent: Wednesday, November 12, 2003 11:16 AM To: Jim Sermersheim; ietf-ldup@imc.org Subject: RE: Standardization of change sequence number =20 Jim, =20 As editor of the URP document, I don't mind changing that document to reference a proposed standard definition for the change sequence number in the form outlined below. To avoid slowing the LDUP publication schedule, the CSN document would have to be produced immediately. =20 Regards, Steven -----Original Message----- From: owner-ietf-ldup@mail.imc.org = [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jim Sermersheim Sent: Wednesday, 12 November 2003 7:49 AM To: ietf-ldup@imc.org Subject: Standardization of change sequence number I (and I believe others) would like to see the change sequence number = syntax be progressed in a standards-track document. Of those initially = interested in this, I believe consensus is that it should be defined as a complex = type (using ASN.1). A string encoding would be defined (which would likely = look just like the one in draft-ietf-ldup-infomod-xx.txt). Then matching = rules would be defined in terms of the complext type (not the string = encoding). =20 Do the authors of the relevant LDUP I-Ds want to participate in the act = of pulling out the current LdapChangeSequenceNumber, and referring to a new I-D, or would they rather just leave it alone (in order to more quickly achieve last call), and let any new I-D progress without being referred = to? =20 Jim ------=_NextPart_000_0023_01C3A922.DD384320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
There will more than likely be = some slippage=20 from the WG Last Call schedule discussed during
the WG Meeting even if the CSN document is published = as soon as possible after the I-D=20 Administrator
starts processing I-Ds = again.
 
Then the information model = document would=20 have to be revised before we could start the first grouping
of WG Last Call documents = mentioned during=20 the WG Meeting.
 
As co-chair I'm OK with pulling the CSN content out as a = separate=20 standards-track document if:
 
1) It is published as an LDUP = WG=20 document rather than an individual contribution. I realize that = the
rationale is that its = applicability is=20 broader than LDUP, but I'm skittish about suggestions
to increase the dependency of the = WG's=20 deliverables on documents not within the control of
any WG. This has caused problems = before and=20 I don't want to add more of that type of risk.
 
2) It is submitted to the I-D = Editor as soon=20 as possible after they begin accepting new
submissions.
 
3) The new CSN LDUP I-D is = included in the=20 WG Last Call grouping of the first document
that will reference it,=20 INFOMOD.
 
4) The INFOMOD Document Editors = are able to=20 submit the revised INFOMOD draft within a
couple of days of the CSN I-D = Action=20 announcement occurring.
 
Keep in mind that if we go that = way, we are=20 introducing uncertainty in starting the WG Last Call
sequence as discussed during the = WG Meeting.=20 This is not really a good thing from a process
perspective, but does seem to be = the right=20 thing to do from a document management perspective.
 
I'll wait to see some postings = from other WG=20 Members (especially need to hear from the INFOMOD
Editors) before = making a=20 judgment call on this. This means that the first grouping WG Last Call=20 won't
happen as planned on the = Monday after=20 the IETF.
 
INFOMOD Editors: please = respond=20 ASAP.
 
Chris Apple 
-----Original Message-----
From:=20 owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] = On=20 Behalf Of Steven Legg
Sent: Wednesday, November 12, 2003 = 11:16=20 AM
To: Jim Sermersheim; ietf-ldup@imc.org
Subject: = RE:=20 Standardization of change sequence number

 
Jim,
 
As editor=20 of the URP document, I don't mind changing that document to reference=20 a
proposed=20 standard definition for the change sequence number in the form=20 outlined
below. To=20 avoid slowing the LDUP publication schedule, the CSN document=20 would
have to be=20 produced immediately.
 
Regards,
Steven
-----Original Message-----
From:=20 owner-ietf-ldup@mail.imc.org = [mailto:owner-ietf-ldup@mail.imc.org]On=20 Behalf Of Jim Sermersheim
Sent: Wednesday, 12 November = 2003=20 7:49 AM
To: ietf-ldup@imc.org
Subject: = Standardization=20 of change sequence number

I (and I believe others) would like to see the change sequence = number=20 syntax be progressed in a standards-track document. Of those = initially=20 interested in this, I believe consensus is that it should be defined = as a=20 complex type (using ASN.1). A string encoding would be defined = (which would=20 likely look just like the one in draft-ietf-ldup-infomod-xx.txt). = Then=20 matching rules would be defined in terms of the complext type (not = the=20 string encoding).
 
Do the authors of the relevant LDUP I-Ds want to participate in = the act=20 of pulling out the current LdapChangeSequenceNumber, and referring = to a new=20 I-D,  or would they rather just = leave it=20 alone (in order to more quickly achieve last call), and let any new = I-D=20 progress without being referred to?
 
Jim
------=_NextPart_000_0023_01C3A922.DD384320-- From owner-ietf-ldup@mail.imc.org Fri Nov 14 14:03:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24569 for ; Fri, 14 Nov 2003 14:03:01 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEIdbkT026571 for ; Fri, 14 Nov 2003 10:39:37 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAEIdbHe026570 for ietf-ldup-bks; Fri, 14 Nov 2003 10:39:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEIdakT026563 for ; Fri, 14 Nov 2003 10:39:36 -0800 (PST) (envelope-from c.apple@comcast.net) Received: from stephen (pcp086396pcs.audubn01.nj.comcast.net[68.44.129.64]) by comcast.net (rwcrmhc13) with SMTP id <2003111418393201500nf5jke> (Authid: c.apple); Fri, 14 Nov 2003 18:39:32 +0000 Reply-To: From: "Chris Apple" To: Subject: Precondition for WG Last Call of the First Document Grouping Date: Fri, 14 Nov 2003 13:45:49 -0500 Message-ID: <000401c3aadf$860b9200$6400a8c0@STEPHEN> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit During the LDUP WG Meeting earlier this week, there was a process point raised by Ted Hardie. We will be asking this question for each of the WG Last Call document groupings as we approach the time to initiate them. We need to consider if we should or don't need to request that various drafts intended for publication as Informational and Experimental RFCs go through an IETF Last Call. Such documents are not required to pass an IETF Last Call prior to IESG approval for publication as RFCs. At this time, your Co-Chairs need a response on that issue from WG Members relative to the following two documents: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-08.txt They are both intended for publication as Informational RFCs. Please indicate whether you think an IETF Last Call should or should not be requested for each of the documents listed above. In the interest of keeping things moving along as quickly as possible, please respond with your input on this matter no later than 1700 US ET on Friday, November 21, 2003. We will not initiate the WG Last Call for the First Grouping of documents until this window of time has elapsed so that WG Last Call participants will know that there will or will not be a post-WG-Last-Call chance to comment on the document prior to the WG Last Call commencing. See the CSN-Note at the end of this e-mail for an explanation of how this question relates to the recent suggestion to pull the CSN content out of draft-ietf-ldup-infomod-08.txt as a separate standards-track document. If we receive no input or insufficient input on which to base an interpretation of consensus, upon conclusion of the WG Last Call for these two documents, our decision as Co-Chairs will be to recommend publication of the drafts as Informational RFCs *without* requesting an IETF Last Call. Otherwise, we'll request an action consistent with consensus on this topic. Chris Apple DSI Consulting, Inc. capple@dsi-consulting.net c.apple@comcast.net 609-828-2987 CSN-Note: There is some possibility that we will be pulling out the CSN content from draft-ietf-ldup-infomod-08.txt as a standards-track document to be included in the same WG Last Call. Since the CSN draft would be intended as a standards-track document, an IETF Last Call would be required, but only for the CSN draft. The CSN draft status will not change the intended publication track for draft-ietf-ldup-infomod-08.txt (actually would be -09.txt if the CSN draft happens), and thus has no material impact the question being asked in this e-mail. From owner-ietf-ldup@mail.imc.org Fri Nov 14 16:23:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29734 for ; Fri, 14 Nov 2003 16:23:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEL8nkT037071 for ; Fri, 14 Nov 2003 13:08:49 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAEL8ncg037070 for ietf-ldup-bks; Fri, 14 Nov 2003 13:08:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from cosium01.intelliden.net (cosium01.intelliden.net [12.41.186.248]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEL8hkT037056 for ; Fri, 14 Nov 2003 13:08:46 -0800 (PST) (envelope-from John.Strassner@intelliden.com) Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Nov 2003 14:08:39 -0700 Message-ID: From: John Strassner To: c.apple@comcast.net, "'Steven Legg'" , "'Jim Sermersheim'" , ietf-ldup@imc.org Subject: RE: Standardization of change sequence number Date: Fri, 14 Nov 2003 14:08:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AAF3.7998FCB0" 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. ------_=_NextPart_001_01C3AAF3.7998FCB0 Content-Type: text/plain Apologies for not being able to attend the meeting. For the record, I fully support Chris' comments here. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Chris Apple [mailto:c.apple@comcast.net] Sent: Wednesday, November 12, 2003 11:43 AM To: 'Steven Legg'; 'Jim Sermersheim'; ietf-ldup@imc.org Subject: RE: Standardization of change sequence number There will more than likely be some slippage from the WG Last Call schedule discussed during the WG Meeting even if the CSN document is published as soon as possible after the I-D Administrator starts processing I-Ds again. Then the information model document would have to be revised before we could start the first grouping of WG Last Call documents mentioned during the WG Meeting. As co-chair I'm OK with pulling the CSN content out as a separate standards-track document if: 1) It is published as an LDUP WG document rather than an individual contribution. I realize that the rationale is that its applicability is broader than LDUP, but I'm skittish about suggestions to increase the dependency of the WG's deliverables on documents not within the control of any WG. This has caused problems before and I don't want to add more of that type of risk. 2) It is submitted to the I-D Editor as soon as possible after they begin accepting new submissions. 3) The new CSN LDUP I-D is included in the WG Last Call grouping of the first document that will reference it, INFOMOD. 4) The INFOMOD Document Editors are able to submit the revised INFOMOD draft within a couple of days of the CSN I-D Action announcement occurring. Keep in mind that if we go that way, we are introducing uncertainty in starting the WG Last Call sequence as discussed during the WG Meeting. This is not really a good thing from a process perspective, but does seem to be the right thing to do from a document management perspective. I'll wait to see some postings from other WG Members (especially need to hear from the INFOMOD Editors) before making a judgment call on this. This means that the first grouping WG Last Call won't happen as planned on the Monday after the IETF. INFOMOD Editors: please respond ASAP. Chris Apple -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Steven Legg Sent: Wednesday, November 12, 2003 11:16 AM To: Jim Sermersheim; ietf-ldup@imc.org Subject: RE: Standardization of change sequence number Jim, As editor of the URP document, I don't mind changing that document to reference a proposed standard definition for the change sequence number in the form outlined below. To avoid slowing the LDUP publication schedule, the CSN document would have to be produced immediately. Regards, Steven -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jim Sermersheim Sent: Wednesday, 12 November 2003 7:49 AM To: ietf-ldup@imc.org Subject: Standardization of change sequence number I (and I believe others) would like to see the change sequence number syntax be progressed in a standards-track document. Of those initially interested in this, I believe consensus is that it should be defined as a complex type (using ASN.1). A string encoding would be defined (which would likely look just like the one in draft-ietf-ldup-infomod-xx.txt). Then matching rules would be defined in terms of the complext type (not the string encoding). Do the authors of the relevant LDUP I-Ds want to participate in the act of pulling out the current LdapChangeSequenceNumber, and referring to a new I-D, or would they rather just leave it alone (in order to more quickly achieve last call), and let any new I-D progress without being referred to? Jim ------_=_NextPart_001_01C3AAF3.7998FCB0 Content-Type: text/html Message

Apologies for not being able to attend the meeting. For the record, I fully support Chris' comments here.

 

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.719.785.0648
  fax:     +1.719.785.0644
email:    john.strassner@intelliden.com

-----Original Message-----
From: Chris Apple [mailto:c.apple@comcast.net]
Sent: Wednesday, November 12, 2003 11:43 AM
To: 'Steven Legg'; 'Jim Sermersheim'; ietf-ldup@imc.org
Subject: RE: Standardization of change sequence number

 

There will more than likely be some slippage from the WG Last Call schedule discussed during

the WG Meeting even if the CSN document is published as soon as possible after the I-D Administrator

starts processing I-Ds again.

 

Then the information model document would have to be revised before we could start the first grouping

of WG Last Call documents mentioned during the WG Meeting.

 

As co-chair I'm OK with pulling the CSN content out as a separate standards-track document if:

 

1) It is published as an LDUP WG document rather than an individual contribution. I realize that the

rationale is that its applicability is broader than LDUP, but I'm skittish about suggestions

to increase the dependency of the WG's deliverables on documents not within the control of

any WG. This has caused problems before and I don't want to add more of that type of risk.

 

2) It is submitted to the I-D Editor as soon as possible after they begin accepting new

submissions.

 

3) The new CSN LDUP I-D is included in the WG Last Call grouping of the first document

that will reference it, INFOMOD.

 

4) The INFOMOD Document Editors are able to submit the revised INFOMOD draft within a

couple of days of the CSN I-D Action announcement occurring.

 

Keep in mind that if we go that way, we are introducing uncertainty in starting the WG Last Call

sequence as discussed during the WG Meeting. This is not really a good thing from a process

perspective, but does seem to be the right thing to do from a document management perspective.

 

I'll wait to see some postings from other WG Members (especially need to hear from the INFOMOD
Editors) before making a judgment call on this. This means that the first grouping WG Last Call won't

happen as planned on the Monday after the IETF.

 

INFOMOD Editors: please respond ASAP.

 

Chris Apple 

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Steven Legg
Sent: Wednesday, November 12, 2003 11:16 AM
To: Jim Sermersheim; ietf-ldup@imc.org
Subject: RE: Standardization of change sequence number

 

Jim,

 

As editor of the URP document, I don't mind changing that document to reference a

proposed standard definition for the change sequence number in the form outlined

below. To avoid slowing the LDUP publication schedule, the CSN document would

have to be produced immediately.

 

Regards,

Steven

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jim Sermersheim
Sent: Wednesday, 12 November 2003 7:49 AM
To: ietf-ldup@imc.org
Subject: Standardization of change sequence number

I (and I believe others) would like to see the change sequence number syntax be progressed in a standards-track document. Of those initially interested in this, I believe consensus is that it should be defined as a complex type (using ASN.1). A string encoding would be defined (which would likely look just like the one in draft-ietf-ldup-infomod-xx.txt). Then matching rules would be defined in terms of the complext type (not the string encoding).

 

Do the authors of the relevant LDUP I-Ds want to participate in the act of pulling out the current LdapChangeSequenceNumber, and referring to a new I-D,  or would they rather just leave it alone (in order to more quickly achieve last call), and let any new I-D progress without being referred to?

 

Jim

------_=_NextPart_001_01C3AAF3.7998FCB0-- From owner-ietf-ldup@mail.imc.org Sat Nov 15 19:28:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26444 for ; Sat, 15 Nov 2003 19:28:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAG0KnkT099722 for ; Sat, 15 Nov 2003 16:20:49 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAG0Knf3099721 for ietf-ldup-bks; Sat, 15 Nov 2003 16:20:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAG0KmkT099704 for ; Sat, 15 Nov 2003 16:20:48 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hAG0Kmlg071428; Sun, 16 Nov 2003 00:20:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031115160520.03249170@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 15 Nov 2003 16:20:15 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: Precondition for WG Last Call of the First Document Grouping Cc: In-Reply-To: <000401c3aadf$860b9200$6400a8c0@STEPHEN> References: <000401c3aadf$860b9200$6400a8c0@STEPHEN> 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 recommend: LDAP Replication I-Ds be subject to IETF Last Call before being considered by the IESG. LDAP Replication I-Ds be progressed (IETF Last Called, IESG consideration) as a set. The former because LDAP Replication may have impact upon LDAP implementations which are not participating in the LDAP Replication experiment. The latter because the individual I-Ds have a great deal of interdependencies. On the CSN discussion, I am in favor of splitting it out so that it can be more easily referenced by other specifications. (On the technical side, I concur that CSN should be defined in ASN.1 terms with LDAP-specific string encodings.) However, I am not yet convinced that standard track would be appropriate for this CSN specification, especially given previous consensus (as reflected in the current charter) to pursue LDAP Replication off the standards track. Kurt At 10:45 AM 11/14/2003, Chris Apple wrote: >During the LDUP WG Meeting earlier this week, there was a process point >raised by Ted Hardie. We will be asking this question for each of the WG >Last Call document groupings as we approach the time to initiate them. > >We need to consider if we should or don't need to request that various >drafts intended for publication as Informational and Experimental RFCs >go through an IETF Last Call. Such documents are not required to pass an >IETF Last Call prior to IESG approval for publication as RFCs. > >At this time, your Co-Chairs need a response on that issue from WG >Members relative to the following two documents: > >http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-09.txt > >http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-08.txt > >They are both intended for publication as Informational RFCs. > >Please indicate whether you think an IETF Last Call should or should not >be requested for each of the documents listed above. > >In the interest of keeping things moving along as quickly as possible, >please respond with your input on this matter no later than 1700 US ET >on Friday, November 21, 2003. > >We will not initiate the WG Last Call for the First Grouping of >documents until this window of time has elapsed so that WG Last Call >participants will know that there will or will not be a >post-WG-Last-Call chance to comment on the document prior to the WG Last >Call commencing. > >See the CSN-Note at the end of this e-mail for an explanation of how >this question relates to the recent suggestion to pull the CSN content >out of draft-ietf-ldup-infomod-08.txt as a separate standards-track >document. > >If we receive no input or insufficient input on which to base an >interpretation of consensus, upon conclusion of the WG Last Call for >these two documents, our decision as Co-Chairs will be to recommend >publication of the drafts as Informational RFCs *without* requesting an >IETF Last Call. Otherwise, we'll request an action consistent with >consensus on this topic. > >Chris Apple >DSI Consulting, Inc. > >capple@dsi-consulting.net >c.apple@comcast.net > >609-828-2987 > >CSN-Note: > >There is some possibility that we will be pulling out the CSN content >from draft-ietf-ldup-infomod-08.txt as a standards-track document to be >included in the same WG Last Call. Since the CSN draft would be intended >as a standards-track document, an IETF Last Call would be required, but >only for the CSN draft. The CSN draft status will not change the >intended publication track for draft-ietf-ldup-infomod-08.txt (actually >would be -09.txt if the CSN draft happens), and thus has no material >impact the question being asked in this e-mail. From owner-ietf-ldup@mail.imc.org Tue Nov 18 09:41:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22331 for ; Tue, 18 Nov 2003 09:41:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIET0kT066460 for ; Tue, 18 Nov 2003 06:29:00 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIET0Kx066459 for ietf-ldup-bks; Tue, 18 Nov 2003 06:29:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIESwkT066454 for ; Tue, 18 Nov 2003 06:28:59 -0800 (PST) (envelope-from c.apple@comcast.net) Received: from d7st2111 (pcp086396pcs.audubn01.nj.comcast.net[68.44.129.64]) by comcast.net (sccrmhc12) with SMTP id <2003111814285401200s3r6ce> (Authid: c.apple@comcast.net); Tue, 18 Nov 2003 14:28:54 +0000 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: Subject: CSN Status & IETF Last Call (was: RE: Precondition for WG Last Call of the First Document Grouping) Date: Tue, 18 Nov 2003 09:28:23 -0500 Organization: DSI-Consulting, Inc. Message-ID: <003101c3ade0$3ffcaf70$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <6.0.0.22.0.20031115160520.03249170@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAIESxkT066455 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jim S: Please note the request for your input on CSN status near the bottom of this e-mail. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Saturday, November 15, 2003 7:20 PM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: Re: Precondition for WG Last Call of the First Document Grouping I recommend: LDAP Replication I-Ds be subject to IETF Last Call before being considered by the IESG. LDAP Replication I-Ds be progressed (IETF Last Called, IESG consideration) as a set. The former because LDAP Replication may have impact upon LDAP implementations which are not participating in the LDAP Replication experiment. The latter because the individual I-Ds have a great deal of interdependencies. CHRIS> Points duly noted. I do not personally see any harm in either putting Informational and Experimental documents through an IETF Last Call or not doing so. John and I would need to see others indicate that they wish to proceed this way to make the request of our ADs. CHRIS> Personally, I am conflicted about expressing support for waiting until all I-Ds are ready for IETF Last Call. I recognize the interdependency issues, but also believe that the way the co-chairs proposed that the documents to be staged through the publication process limits various risks involved in not waiting for a balloon-style IETF Last Call for all documents. As a Co-Chair, I view this staging as consistent with the WG Charter, despite the slip in dates. I suppose that the IESG could decide to hold the LDUP documents until they are all ready for IETF Last Call. But that is a decision they would have to make regardless of any request that John and I might relay to them. And Since Ted is watching the LDUP list, I'm sure he'll take your input into account when deciding what he should recommend to the IESG. As usual, John and I would need to see others indicate that they wish to proceed this way. Otherwise, we'll be sticking with our original intent of sending documents to our Ads as they are ready for IESG Consideration. On the CSN discussion, I am in favor of splitting it out so that it can be more easily referenced by other specifications. (On the technical side, I concur that CSN should be defined in ASN.1 terms with LDAP-specific string encodings.) However, I am not yet convinced that standard track would be appropriate for this CSN specification, especially given previous consensus (as reflected in the current charter) to pursue LDAP Replication off the standards track. Kurt CHRIS> The rationale I recall from prior discussion about the CSN split-out is that the CSN concept has a broader applicability than LDUP. That seems to me to be sufficient justification for pursuing a standards-track publication path. I view this issue as one that is separable from the general concept of LDUP being an Experimental concept/protocol. LDUP needs CSN to work even in an experimental way. I certainly agree that this is not a sufficient justification alone for a standards-track path. But...perhaps Jim S. can shed some light on the specific reasons he had for suggesting standards track for CSN? And if others could chime in as well that would help us sort this out. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Nov 18 11:12:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27909 for ; Tue, 18 Nov 2003 11:12:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIFwIkT070749 for ; Tue, 18 Nov 2003 07:58:18 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIFwIN5070748 for ietf-ldup-bks; Tue, 18 Nov 2003 07:58:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIFwHkT070742 for ; Tue, 18 Nov 2003 07:58:17 -0800 (PST) (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 18 Nov 2003 08:57:58 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 18 Nov 2003 08:57:21 -0700 From: "Jim Sermersheim" To: , Cc: Subject: CSN Status & IETF Last Call (was: RE: Precondition for WG Last Call of the First Document Grouping Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartDD835571.1__=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDD835571.1__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The more I think about it, it seems fine to be published as experimental. = Mostly I just wanted to pull the syntax definition into a standalone I-D = which can be toyed with on its own * I can't remember why I specified = standards track. The real motivation is that we want to start publishing = these types of values in operational attributes, and may want to start = using them with synchronization-like mechanisms. When looking at the way = its currently defined, there are some things I'd like to see changed, and = felt that segregating it would be easier than trying to affect the info = model draft. =20 Jim >>> "Chris Apple" 11/18/03 7:28:23 AM >>> Jim S: Please note the request for your input on CSN status near the = bottom of this e-mail. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] = On Behalf Of Kurt D. Zeilenga Sent: Saturday, November 15, 2003 7:20 PM To: capple@dsi-consulting.net=20 Cc: ietf-ldup@imc.org=20 Subject: Re: Precondition for WG Last Call of the First Document Grouping I recommend: LDAP Replication I-Ds be subject to IETF Last Call before being considered by the IESG. LDAP Replication I-Ds be progressed (IETF Last Called, IESG consideration) as a set. The former because LDAP Replication may have impact upon LDAP implementations which are not participating in the LDAP Replication experiment. The latter because the individual I-Ds have a great deal of interdependencies. CHRIS> Points duly noted. I do not personally see any harm in either putting Informational and Experimental documents through an IETF Last Call or not doing so. John and I would need to see others indicate that they wish to proceed this way to make the request of our ADs. CHRIS> Personally, I am conflicted about expressing support for waiting until all I-Ds are ready for IETF Last Call. I recognize the interdependenc= y issues, but also believe that the way the co-chairs proposed that the documents to be staged through the publication process limits various risks involved in not waiting for a balloon-style IETF Last Call for all documents. As a Co-Chair, I view this staging as consistent with the WG Charter, despite the slip in dates. I suppose that the IESG could decide to hold = the LDUP documents until they are all ready for IETF Last Call. But that is a decision they would have to make regardless of any request that John and I might relay to them. And Since Ted is watching the LDUP list, I'm sure = he'll take your input into account when deciding what he should recommend to the IESG. As usual, John and I would need to see others indicate that they = wish to proceed this way. Otherwise, we'll be sticking with our original intent of sending documents to our Ads as they are ready for IESG Consideration. On the CSN discussion, I am in favor of splitting it out so that it can be more easily referenced by other specifications. (On the technical side, I concur that CSN should be defined in ASN.1 terms with LDAP-specific string encodings.) However, I am not yet convinced that standard track would be appropriate for this CSN specification, especially given previous = consensus (as reflected in the current charter) to pursue LDAP Replication off the standards track.=20 Kurt CHRIS> The rationale I recall from prior discussion about the CSN = split-out is that the CSN concept has a broader applicability than LDUP. That seems = to me to be sufficient justification for pursuing a standards-track publicatio= n path. I view this issue as one that is separable from the general concept = of LDUP being an Experimental concept/protocol. LDUP needs CSN to work even = in an experimental way. I certainly agree that this is not a sufficient justification alone for a standards-track path. But...perhaps Jim S. can shed some light on the specific reasons he had for suggesting standards track for CSN? And if others could chime in as well that would help us sort this out. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net=20 http://www.dsi-consulting.com=20 --=__PartDD835571.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The more I think about it, it seems fine to be published as experiment= al. Mostly I just wanted to pull the syntax definition into a = standalone I-D which can be toyed with on its own =97 I can't remember why = I specified standards track. The real motivation is that we want to start = publishing these types of values in operational attributes, and may want = to start using them with synchronization-like mechanisms. When looking at = the way its currently defined, there are some things I'd like to see = changed, and felt that segregating it would be easier than trying to = affect the info model draft.
 
Jim

>>> "Chris Apple" <capple@dsi-consulting.net>= ; 11/18/03 7:28:23 AM >>>

Jim S: Please note the request = for your input on CSN status near the bottom
of this e-mail.

----= -Original Message-----
From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]= On
Behalf Of Kurt D. Zeilenga
Sent: Saturday, November 15, 2003 = 7:20 PM
To: capple@dsi-c= onsulting.net
Cc: ietf-= ldup@imc.org
Subject: Re: Precondition for WG Last Call of the = First Document Grouping



I recommend:
LDAP Replication = I-Ds be subject to IETF Last Call before being
considered by the = IESG.

LDAP Replication I-Ds be progressed (IETF Last Called, = IESG
consideration) as a set.

The former because LDAP Replication= may have impact upon LDAP
implementations
which are not participatin= g in the LDAP Replication experiment. The latter
because the individual = I-Ds have a great deal of interdependencies.

CHRIS> Points duly = noted. I do not personally see any harm in either
putting Informational = and Experimental documents through an IETF Last Call
or not doing so. = John and I would need to see others indicate that they
wish to proceed = this way to make the request of our ADs.

CHRIS> Personally, I am = conflicted about expressing support for waiting
until all I-Ds are = ready for IETF Last Call. I recognize the interdependency
issues, but = also believe that the way the co-chairs proposed that the
documents to = be staged through the publication process limits various
risks involved = in not waiting for a balloon-style IETF Last Call for all
documents. As = a Co-Chair, I view this staging as consistent with the WG
Charter,
de= spite the slip in dates. I suppose that the IESG could decide to hold = the
LDUP
documents until they are all ready for IETF Last Call. But = that is a
decision they would have to make regardless of any request = that John and I
might relay to them. And Since Ted is watching the LDUP = list, I'm sure he'll
take your input into account when deciding what he = should recommend to the
IESG. As usual, John and I would need to see = others indicate that they wish
to proceed this way. Otherwise, we'll be = sticking with our original intent
of
sending documents to our Ads as = they are ready for IESG Consideration.

On the CSN discussion, I am = in favor of splitting it out so that it can be
more easily referenced = by other specifications. (On the technical side, I
concur that CSN = should be defined in ASN.1 terms with LDAP-specific string
encodings.) = However, I am not yet convinced that standard track would be
appropriate= for this CSN specification, especially given previous consensus
(as = reflected in the current charter) to pursue LDAP Replication off the
sta= ndards track.

Kurt

CHRIS> The rationale I recall from = prior discussion about the CSN split-out
is that the CSN concept has a = broader applicability than LDUP. That seems to
me to be sufficient = justification for pursuing a standards-track publication
path. I view = this issue as one that is separable from the general concept of
LDUP = being an Experimental concept/protocol. LDUP needs CSN to work even = in
an experimental way. I certainly agree that this is not a sufficient<= BR>justification
alone for a standards-track path. But...perhaps Jim S. = can shed some light
on the specific reasons he had for suggesting = standards track for CSN? And
if others could chime in as well that = would help us sort this out.

Chris Apple - Principal Architect
DSI Consulting, Inc.

mailto:capple@dsi-consulting.net

http://www.dsi-consulting.com


--=__PartDD835571.1__=-- From owner-ietf-ldup@mail.imc.org Tue Nov 18 11:29:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28592 for ; Tue, 18 Nov 2003 11:29:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIGF3kT071564 for ; Tue, 18 Nov 2003 08:15:03 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIGF3E8071563 for ietf-ldup-bks; Tue, 18 Nov 2003 08:15:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIGF2kT071541 for ; Tue, 18 Nov 2003 08:15:02 -0800 (PST) (envelope-from c.apple@comcast.net) Received: from d7st2111 (pcp086396pcs.audubn01.nj.comcast.net[68.44.129.64]) by comcast.net (sccrmhc12) with SMTP id <2003111816145801200s5o8se> (Authid: c.apple@comcast.net); Tue, 18 Nov 2003 16:14:58 +0000 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , Cc: Subject: RE: CSN Status & IETF Last Call (was: RE: Precondition for WGLast Call of the First Document Grouping Date: Tue, 18 Nov 2003 11:14:33 -0500 Message-ID: <003f01c3adef$0f8836c0$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C3ADC5.26B22EC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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_0040_01C3ADC5.26B22EC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks - that changes things a bit. =20 Rather than label it as Experimental though, it would seem better to = keep the Informational designation of the information model document giving rise to it. =20 I still need to hear from the editors of the Information Model document about being able to revise it in a timely manner. =20 Chris. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com]=20 Sent: Tuesday, November 18, 2003 10:57 AM To: capple@dsi-consulting.net; Kurt@OpenLDAP.org Cc: ietf-ldup@imc.org Subject: CSN Status & IETF Last Call (was: RE: Precondition for WGLast = Call of the First Document Grouping The more I think about it, it seems fine to be published as = experimental. Mostly I just wanted to pull the syntax definition into a standalone I-D which can be toyed with on its own - I can't remember why I specified standards track. The real motivation is that we want to start publishing these types of values in operational attributes, and may want to start = using them with synchronization-like mechanisms. When looking at the way its currently defined, there are some things I'd like to see changed, and = felt that segregating it would be easier than trying to affect the info model draft. =20 Jim >>> "Chris Apple" 11/18/03 7:28:23 AM >>> Jim S: Please note the request for your input on CSN status near the = bottom of this e-mail. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] = On Behalf Of Kurt D. Zeilenga Sent: Saturday, November 15, 2003 7:20 PM To: capple@dsi-consulting.net=20 Cc: ietf-ldup@imc.org=20 Subject: Re: Precondition for WG Last Call of the First Document = Grouping I recommend: LDAP Replication I-Ds be subject to IETF Last Call before being considered by the IESG. LDAP Replication I-Ds be progressed (IETF Last Called, IESG consideration) as a set. The former because LDAP Replication may have impact upon LDAP implementations which are not participating in the LDAP Replication experiment. The = latter because the individual I-Ds have a great deal of interdependencies. CHRIS> Points duly noted. I do not personally see any harm in either putting Informational and Experimental documents through an IETF Last = Call or not doing so. John and I would need to see others indicate that they wish to proceed this way to make the request of our ADs. CHRIS> Personally, I am conflicted about expressing support for waiting until all I-Ds are ready for IETF Last Call. I recognize the = interdependency issues, but also believe that the way the co-chairs proposed that the documents to be staged through the publication process limits various risks involved in not waiting for a balloon-style IETF Last Call for all documents. As a Co-Chair, I view this staging as consistent with the WG Charter, despite the slip in dates. I suppose that the IESG could decide to hold = the LDUP documents until they are all ready for IETF Last Call. But that is a decision they would have to make regardless of any request that John and = I might relay to them. And Since Ted is watching the LDUP list, I'm sure = he'll take your input into account when deciding what he should recommend to = the IESG. As usual, John and I would need to see others indicate that they = wish to proceed this way. Otherwise, we'll be sticking with our original = intent of sending documents to our Ads as they are ready for IESG Consideration. On the CSN discussion, I am in favor of splitting it out so that it can = be more easily referenced by other specifications. (On the technical side, = I concur that CSN should be defined in ASN.1 terms with LDAP-specific = string encodings.) However, I am not yet convinced that standard track would be appropriate for this CSN specification, especially given previous = consensus (as reflected in the current charter) to pursue LDAP Replication off the standards track.=20 Kurt CHRIS> The rationale I recall from prior discussion about the CSN = split-out is that the CSN concept has a broader applicability than LDUP. That = seems to me to be sufficient justification for pursuing a standards-track = publication path. I view this issue as one that is separable from the general = concept of LDUP being an Experimental concept/protocol. LDUP needs CSN to work even = in an experimental way. I certainly agree that this is not a sufficient justification alone for a standards-track path. But...perhaps Jim S. can shed some = light on the specific reasons he had for suggesting standards track for CSN? = And if others could chime in as well that would help us sort this out. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net=20 http://www.dsi-consulting.com =20 ------=_NextPart_000_0040_01C3ADC5.26B22EC0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Thanks - that changes things a=20 bit.
 
Rather than label it as = Experimental though,=20 it would seem better to keep the Informational designation of the = information=20 model
document giving rise to = it.
 
I still need to hear from the = editors of the=20 Information Model document about being able to revise it in a timely=20 manner.
 
Chris.
-----Original Message-----
From: Jim = Sermersheim=20 [mailto:jimse@novell.com]
Sent: Tuesday, November 18, 2003 = 10:57=20 AM
To: capple@dsi-consulting.net; = Kurt@OpenLDAP.org
Cc:=20 ietf-ldup@imc.org
Subject: CSN Status & IETF Last Call = (was: RE:=20 Precondition for WGLast Call of the First Document=20 Grouping

The more I think about it, it seems fine to be published as = experimental.=20 Mostly I just wanted to pull the syntax definition into a = standalone I-D=20 which can be toyed with on its own — I can't remember why I = specified=20 standards track. The real motivation is that we want to start = publishing these=20 types of values in operational attributes, and may want to start using = them=20 with synchronization-like mechanisms. When looking at the way its = currently=20 defined, there are some things I'd like to see changed, and felt that=20 segregating it would be easier than trying to affect the info model=20 draft.
 
Jim

>>> "Chris Apple" = <capple@dsi-consulting.net>=20 11/18/03 7:28:23 AM >>>

Jim S: Please note the request = for=20 your input on CSN status near the bottom
of this=20 e-mail.

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org= =20 [mailto:owner-ietf-= ldup@mail.imc.org]=20 On
Behalf Of Kurt D. Zeilenga
Sent: Saturday, November 15, 2003 = 7:20=20 PM
To: capple@dsi-consulting.net=20
Cc: ietf-ldup@imc.org=20
Subject: Re: Precondition for WG Last Call of the First Document=20 Grouping



I recommend:
LDAP Replication I-Ds be = subject to=20 IETF Last Call before being
considered by the IESG.

LDAP = Replication=20 I-Ds be progressed (IETF Last Called, IESG
consideration) as a=20 set.

The former because LDAP Replication may have impact upon=20 LDAP
implementations
which are not participating in the LDAP = Replication=20 experiment. The latter
because the individual I-Ds have a great = deal of=20 interdependencies.

CHRIS> Points duly noted. I do not = personally see=20 any harm in either
putting Informational and Experimental documents = through=20 an IETF Last Call
or not doing so. John and I would need to see = others=20 indicate that they
wish to proceed this way to make the request of = our=20 ADs.

CHRIS> Personally, I am conflicted about expressing = support for=20 waiting
until all I-Ds are ready for IETF Last Call. I recognize = the=20 interdependency
issues, but also believe that the way the co-chairs = proposed that the
documents to be staged through the publication = process=20 limits various
risks involved in not waiting for a balloon-style = IETF Last=20 Call for all
documents. As a Co-Chair, I view this staging as = consistent=20 with the WG
Charter,
despite the slip in dates. I suppose that = the IESG=20 could decide to hold the
LDUP
documents until they are all ready = for=20 IETF Last Call. But that is a
decision they would have to make = regardless=20 of any request that John and I
might relay to them. And Since Ted = is=20 watching the LDUP list, I'm sure he'll
take your input into account = when=20 deciding what he should recommend to the
IESG. As usual, John and I = would=20 need to see others indicate that they wish
to proceed this way. = Otherwise,=20 we'll be sticking with our original intent
of
sending documents = to our=20 Ads as they are ready for IESG Consideration.

On the CSN = discussion, I=20 am in favor of splitting it out so that it can be
more easily = referenced by=20 other specifications. (On the technical side, I
concur that CSN = should be=20 defined in ASN.1 terms with LDAP-specific string
encodings.) = However, I am=20 not yet convinced that standard track would be
appropriate for this = CSN=20 specification, especially given previous consensus
(as reflected in = the=20 current charter) to pursue LDAP Replication off the
standards = track.=20

Kurt

CHRIS> The rationale I recall from prior = discussion=20 about the CSN split-out
is that the CSN concept has a broader = applicability=20 than LDUP. That seems to
me to be sufficient justification for = pursuing a=20 standards-track publication
path. I view this issue as one that is=20 separable from the general concept of
LDUP being an Experimental=20 concept/protocol. LDUP needs CSN to work even in
an experimental = way. I=20 certainly agree that this is not a = sufficient
justification
alone for a=20 standards-track path. But...perhaps Jim S. can shed some light
on = the=20 specific reasons he had for suggesting standards track for CSN? = And
if=20 others could chime in as well that would help us sort this = out.

Chris=20 Apple - Principal Architect

DSI Consulting, Inc.

mailto:capple@dsi-consulting.ne= t=20

http://www.dsi-consulting.com= =20



------=_NextPart_000_0040_01C3ADC5.26B22EC0-- From owner-ietf-ldup@mail.imc.org Thu Nov 20 01:04:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05635 for ; Thu, 20 Nov 2003 01:04:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK5s6kT035856 for ; Wed, 19 Nov 2003 21:54:06 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAK5s6aT035854 for ietf-ldup-bks; Wed, 19 Nov 2003 21:54:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAK5s4kT035842 for ; Wed, 19 Nov 2003 21:54:05 -0800 (PST) (envelope-from rvh@qsun.mt.att.com) Received: from qsun.mt.att.com ([135.16.157.16]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hAK5rxOP024663; Thu, 20 Nov 2003 00:53:59 -0500 Received: by qsun.mt.att.com (8.8.8p2+Sun/ATTEMS-1.4.1 sol2) id AAA14739; Thu, 20 Nov 2003 00:54:07 -0500 (EST) Date: Thu, 20 Nov 2003 00:54:07 -0500 (EST) Message-Id: <200311200554.AAA14739@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: capple@dsi-consulting.net, ietf-ldup@imc.org Subject: Re: Precondition for WG Last Call of the First Document Grouping Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have no problem with the idea of a separate CSN draft if that's the way the WG wants to go. But if we go that way, we should start with the next version of Infomod rather than -08. There are some minor wording changes in Section 7.1 of Infomod (I assume that is the section that would become part of a CSN draft) that should be included. The changes reflect the fact that replicaSubentries are replaced by replica objects (which are not subentries) in the upcoming draft. As for other drafts, I think the Profiles draft could be progressed without waiting for most of the other drafts. It mainly discusses issues that should consider when administering/using replicated directories. Rick Huber : From: "Chris Apple" : To: : Subject: Precondition for WG Last Call of the First Document Grouping : Sender: owner-ietf-ldup@mail.imc.org : Precedence: bulk : List-Archive: : List-ID: : List-Unsubscribe: : : : During the LDUP WG Meeting earlier this week, there was a process point : raised by Ted Hardie. We will be asking this question for each of the WG : Last Call document groupings as we approach the time to initiate them. : : We need to consider if we should or don't need to request that various : drafts intended for publication as Informational and Experimental RFCs : go through an IETF Last Call. Such documents are not required to pass an : IETF Last Call prior to IESG approval for publication as RFCs. : : At this time, your Co-Chairs need a response on that issue from WG : Members relative to the following two documents: : : http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-09.txt : : http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-08.txt : : They are both intended for publication as Informational RFCs. : : Please indicate whether you think an IETF Last Call should or should not : be requested for each of the documents listed above. : : In the interest of keeping things moving along as quickly as possible, : please respond with your input on this matter no later than 1700 US ET : on Friday, November 21, 2003. : : We will not initiate the WG Last Call for the First Grouping of : documents until this window of time has elapsed so that WG Last Call : participants will know that there will or will not be a : post-WG-Last-Call chance to comment on the document prior to the WG Last : Call commencing. : : See the CSN-Note at the end of this e-mail for an explanation of how : this question relates to the recent suggestion to pull the CSN content : out of draft-ietf-ldup-infomod-08.txt as a separate standards-track : document. : : If we receive no input or insufficient input on which to base an : interpretation of consensus, upon conclusion of the WG Last Call for : these two documents, our decision as Co-Chairs will be to recommend : publication of the drafts as Informational RFCs *without* requesting an : IETF Last Call. Otherwise, we'll request an action consistent with : consensus on this topic. : : Chris Apple : DSI Consulting, Inc. : : capple@dsi-consulting.net : c.apple@comcast.net : : 609-828-2987 : : CSN-Note: : : There is some possibility that we will be pulling out the CSN content : from draft-ietf-ldup-infomod-08.txt as a standards-track document to be : included in the same WG Last Call. Since the CSN draft would be intended : as a standards-track document, an IETF Last Call would be required, but : only for the CSN draft. The CSN draft status will not change the : intended publication track for draft-ietf-ldup-infomod-08.txt (actually : would be -09.txt if the CSN draft happens), and thus has no material : impact the question being asked in this e-mail. : : : : : From owner-ietf-ldup@mail.imc.org Thu Nov 20 10:22:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08970 for ; Thu, 20 Nov 2003 10:22:31 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKF8qkT035200 for ; Thu, 20 Nov 2003 07:08:52 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKF8qHa035199 for ietf-ldup-bks; Thu, 20 Nov 2003 07:08:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKF8pkT035192 for ; Thu, 20 Nov 2003 07:08:51 -0800 (PST) (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 20 Nov 2003 08:08:47 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 20 Nov 2003 08:08:27 -0700 From: "Jim Sermersheim" To: Subject: Re: Precondition for WG Last Call of the First Document Grouping Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartC89646FB.0__=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartC89646FB.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Just to clarify, the CSN I-D I would offer would only describe the syntax, and not any attributes. Attributes (and their semantics) would still have to be defined in other documents (like Infomod) Jim >>> Richard V Huber 11/19/03 10:54:07 PM >>> I have no problem with the idea of a separate CSN draft if that's the way the WG wants to go. But if we go that way, we should start with the next version of Infomod rather than -08. There are some minor wording changes in Section 7.1 of Infomod (I assume that is the section that would become part of a CSN draft) that should be included. The changes reflect the fact that replicaSubentries are replaced by replica objects (which are not subentries) in the upcoming draft. As for other drafts, I think the Profiles draft could be progressed without waiting for most of the other drafts. It mainly discusses issues that should consider when administering/using replicated directories. Rick Huber : From: "Chris Apple" < capple@dsi-consulting.net > : To: < ietf-ldup@imc.org > : Subject: Precondition for WG Last Call of the First Document Grouping : Sender: owner-ietf-ldup@mail.imc.org : Precedence: bulk : List-Archive: < http://www.imc.org/ietf-ldup/mail-archive/ > : List-ID: : List-Unsubscribe: < mailto:ietf-ldup-request@imc.org?body=unsubscribe > : : : During the LDUP WG Meeting earlier this week, there was a process point : raised by Ted Hardie. We will be asking this question for each of the WG : Last Call document groupings as we approach the time to initiate them. : : We need to consider if we should or don't need to request that various : drafts intended for publication as Informational and Experimental RFCs : go through an IETF Last Call. Such documents are not required to pass an : IETF Last Call prior to IESG approval for publication as RFCs. : : At this time, your Co-Chairs need a response on that issue from WG : Members relative to the following two documents: : : http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-09.txt : : http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-08.txt : : They are both intended for publication as Informational RFCs. : : Please indicate whether you think an IETF Last Call should or should not : be requested for each of the documents listed above. : : In the interest of keeping things moving along as quickly as possible, : please respond with your input on this matter no later than 1700 US ET : on Friday, November 21, 2003. : : We will not initiate the WG Last Call for the First Grouping of : documents until this window of time has elapsed so that WG Last Call : participants will know that there will or will not be a : post-WG-Last-Call chance to comment on the document prior to the WG Last : Call commencing. : : See the CSN-Note at the end of this e-mail for an explanation of how : this question relates to the recent suggestion to pull the CSN content : out of draft-ietf-ldup-infomod-08.txt as a separate standards-track : document. : : If we receive no input or insufficient input on which to base an : interpretation of consensus, upon conclusion of the WG Last Call for : these two documents, our decision as Co-Chairs will be to recommend : publication of the drafts as Informational RFCs *without* requesting an : IETF Last Call. Otherwise, we'll request an action consistent with : consensus on this topic. : : Chris Apple : DSI Consulting, Inc. : : capple@dsi-consulting.net : c.apple@comcast.net : : 609-828-2987 : : CSN-Note: : : There is some possibility that we will be pulling out the CSN content : from draft-ietf-ldup-infomod-08.txt as a standards-track document to be : included in the same WG Last Call. Since the CSN draft would be intended : as a standards-track document, an IETF Last Call would be required, but : only for the CSN draft. The CSN draft status will not change the : intended publication track for draft-ietf-ldup-infomod-08.txt (actually : would be -09.txt if the CSN draft happens), and thus has no material : impact the question being asked in this e-mail. : : : : : --=__PartC89646FB.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Just to clarify, the CSN I-D I would offer would only describe the syntax, and not any attributes. Attributes (and their semantics) would still have to be defined in other documents (like Infomod)
 
Jim

>>> Richard V Huber <rvh@qsun.mt.att.com> 11/19/03 10:54:07 PM >>>

I have no problem with the idea of a separate CSN draft if that's the
way the WG wants to go. But if we go that way, we should start with
the next version of Infomod rather than -08. There are some minor
wording changes in Section 7.1 of Infomod (I assume that is the section
that would become part of a CSN draft) that should be included. The
changes reflect the fact that replicaSubentries are replaced by replica
objects (which are not subentries) in the upcoming draft.

As for other drafts, I think the Profiles draft could be progressed
without waiting for most of the other drafts. It mainly discusses
issues that should consider when administering/using replicated
directories.

Rick Huber

: From: "Chris Apple" < capple@dsi-consulting.net >
: To: < ietf-ldup@imc.org >
: Subject: Precondition for WG Last Call of the First Document Grouping
: Sender: owner-ietf-ldup@mail.imc.org
: Precedence: bulk
: List-Archive: < http://www.imc.org/ietf-ldup/mail-archive/ >
: List-ID: <ietf-ldup.imc.org>
: List-Unsubscribe: < mailto:ietf-ldup-request@imc.org?body=unsubscribe >
:
:
: During the LDUP WG Meeting earlier this week, there was a process point
: raised by Ted Hardie. We will be asking this question for each of the WG
: Last Call document groupings as we approach the time to initiate them.
:
: We need to consider if we should or don't need to request that various
: drafts intended for publication as Informational and Experimental R! FCs
: go through an IETF Last Call. Such documents are not ! required to pass an
: IETF Last Call prior to IESG approval for publication as RFCs.
:
: At this time, your Co-Chairs need a response on that issue from WG
: Members relative to the following two documents:
:
: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-09.txt
:
: http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-08.txt
:
: They are both intended for publication as Informational RFCs.
:
: Please indicate whether you think an IETF Last Call should or should not
: be requested for each of the documents listed above.
:
: In the interest of keeping things moving along as quickly as possible,
: please respond with your input on this matter no later than 1700 US ET
: on Friday, November 21, 2003.
:
: We will not initiate the WG! Last Call for the First Grouping of
: documents until this window of time has elapsed so that WG Last Call
: participants will know that there will or will not be a
: post-WG-Last-Call chance to comment on the document prior to the WG Last
: Call commencing.
:
: See the CSN-Note at the end of this e-mail for an explanation of how
: this question relates to the recent suggestion to pull the CSN content
: out of draft-ietf-ldup-infomod-08.txt as a separate standards-track
: document.
:
: If we receive no input or insufficient input on which to base an
: interpretation of consensus, upon conclusion of the WG Last Call for
: these two documents, our decision as Co-Chairs will be to recommend
: publication of the drafts as Informational RFCs *without* requesting an
: IETF Last Call. Otherwise, we'll request an action consistent with
: consensus on this topic.
:
: Chris Apple
: DSI Consulting, Inc.
:
: capple@dsi-consulting.net
: c.apple@comcast.net
:
: 609-828-2987
:
: CSN-Note:
:
: There is some possibility that we will be pulling out the CSN content
: from draft-ietf-ldup-infomod-08.txt as a standards-track document to be
: included in the same WG Last Call. Since the CSN draft would be intended
: as a standards-track document, an IETF Last Call would be required, but
: only for the CSN draft. The CSN draft status will not change the
: intended publication track for draft-ietf-ldup-infomod-08.txt (actually
: would be -09.txt if the CSN draft happens), and thus has no material
: impact the question being asked in this e-mail.
:
:
:
:
:
--=__PartC89646FB.0__=-- From owner-ietf-ldup@mail.imc.org Fri Nov 21 11:26:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20037 for ; Fri, 21 Nov 2003 11:26:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALG9xkT070181 for ; Fri, 21 Nov 2003 08:09:59 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALG9xFb070180 for ietf-ldup-bks; Fri, 21 Nov 2003 08:09:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALG9vkT070171 for ; Fri, 21 Nov 2003 08:09:58 -0800 (PST) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id hALG9rAv405352 for ; Fri, 21 Nov 2003 11:09:53 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hALG9pLR217920 for ; Fri, 21 Nov 2003 11:09:52 -0500 Subject: OIDs for LDUP schema, controls, etc.. To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 21 Nov 2003 10:09:51 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 11/21/2003 10:09:52 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: Do we want to request OIDs for the infomod schema, protocol extended ops, etc.? If so, do we want to request one overall "LDUP-OID" and assign LDUP-OID.1, LDUP-OID.2, etc? Or do we want to do this on a per document basis (ldup-infomod-oid.1, ... ldup-protocol-oid.1, ...)? Also, there are a few references to other drafts I'm not sure we've sorted out: draft-zeilenga-ldap-uuid-xx draft-zeilenga-ldap-grouping-xx.txt What is happening with these drafts? John McMeeking From owner-ietf-ldup@mail.imc.org Sat Nov 22 21:50:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28920 for ; Sat, 22 Nov 2003 21:50:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAN2axkT027624 for ; Sat, 22 Nov 2003 18:36:59 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAN2axe3027623 for ietf-ldup-bks; Sat, 22 Nov 2003 18:36:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAN2awkT027617 for ; Sat, 22 Nov 2003 18:36:58 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hAN2b0lg073837; Sun, 23 Nov 2003 02:37:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031122181755.026fda70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 22 Nov 2003 18:36:18 -0800 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: OIDs for LDUP schema, controls, etc.. Cc: ietf-ldup@imc.org In-Reply-To: References: 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: At 08:09 AM 11/21/2003, John McMeeking wrote: >Do we want to request OIDs for the infomod schema, protocol extended ops, >etc.? I suggest that you include requests for IANA actions in the document (and, hence, defer actual assignment until the I-D becomes an RFC-to-be). See BCP 64 for details. >If so, do we want to request one overall "LDUP-OID" and assign LDUP-OID.1, >LDUP-OID.2, etc? Or do we want to do this on a per document basis >(ldup-infomod-oid.1, ... ldup-protocol-oid.1, ...)? BCP 64 says "Only one OID per specification will be assigned." A specification, such as for LDAP Replication, can be spread over multiple documents. Of course, one could consider some LDAP Replication documents (such as a CSN I-D) to separate specifications. >Also, there are a few references to other drafts I'm not sure we've sorted >out: > draft-zeilenga-ldap-uuid-xx > draft-zeilenga-ldap-grouping-xx.txt >What is happening with these drafts? I plan on progressing UUID very soon (within a week or two). I plan on progressing grouping with transactions soon (within the next few months). Kurt