From owner-ietf-ldup@imc.org Tue Feb 1 03:48:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08797 for ; Tue, 1 Feb 2000 03:48:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA13745 for ietf-ldup-bks; Tue, 1 Feb 2000 00:12:56 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA13741 for ; Tue, 1 Feb 2000 00:12:55 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 01 Feb 2000 01:14:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 01 Feb 2000 01:09:22 -0700 From: "Jim Sermersheim" To: Subject: Re: Root naming context Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA13742 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Well, after reading section 3.2 of RFC 2251 (like I should have done in the first place), I see that this is pretty much a no-no. That's too bad because having some kind of shared entry at the root really comes in handy when dealing with the two issues listed below (inherited ACLs and shared root replica). >>> "Jim Sermersheim" 01/31/00 02:53PM >>> Novell's implementation of LDAP allows one to root a naming context at the root of the tree. For example, you could have a DIT that looks like this: \ (naming context 1) | | +-cn=schema | +-o=administration | | + / +-c=US \ (naming context 2) | + / +-c=AU \ (naming context 3) + / Where the root of the tree, the schema, and the o=administration container all fit into naming context 1. This is possible because we have an actual entry at the root of the tree which we can attach the nameContext auxilliary class to (described in the arch and info model doc's). Thie only slightly quirky thing is that this entry is not named. This tends to work out quite well with the way LDAP is defined however. The namingContexts attribute in the root DSE can (and many times does) contain a zero length DN which names the root of the tree as a naming context root. It also comes in handy when assigning ACLs which are to inherit down the entire hierarchy. What I'm wondering (read: lack of ambition to do my own research) is whether this unnamed root entry will cause problems when replicating with other directories. Or in other words, do/will other LDAP directories allow this? Jim From owner-ietf-ldup@imc.org Mon Feb 14 10:56:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15316 for ; Mon, 14 Feb 2000 10:56:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06204 for ietf-ldup-bks; Mon, 14 Feb 2000 07:16:31 -0800 (PST) Received: from stilt.jhancock.com (stilt.jhancock.com [206.33.173.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06199 for ; Mon, 14 Feb 2000 07:16:29 -0800 (PST) Received: from exchsmtpout.jhancock.com ([165.71.123.89]) by stilt.jhancock.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA12754 for ; Mon, 14 Feb 2000 10:19:42 -0500 (EST) Received: by exchsmtpout.jhancock.com with Internet Mail Service (5.5.2650.21) id <1Z0F7TRL>; Mon, 14 Feb 2000 10:19:43 -0500 Message-ID: <604BBD28BC0AD311AE760008C7B2721D2E5798@exchange03.jhancock.com> From: "Buonora, Peter" To: "'ietf-ldup@imc.org'" Subject: FW: LDAP in a 24x7 NAS environment? Date: Mon, 14 Feb 2000 10:19:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Here at John Hancock we are in the process of moving to the new version of NAS which requires LDAP registry. There is no clear way to make this architecture work in a 24x7 environment since NAS requires reads and writes while Netscape Directory 4.x server does not support Multi-Mastering. I know that someone else must have faced these issues already and any help at all would be greatly appreciated. (We would prefer to avoid HA failover type solutions) We do have a platinum support contract, but Tech support has not been a great help as of yet.. Thanks, Peter Buonora Web Infrastructure Architect John Hancock 617-572-5130 From owner-ietf-ldup@imc.org Mon Feb 14 19:07:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27035 for ; Mon, 14 Feb 2000 19:07:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25069 for ietf-ldup-bks; Mon, 14 Feb 2000 15:34:42 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25058; Mon, 14 Feb 2000 15:34:23 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA00271; Mon, 14 Feb 2000 18:37:05 -0500 (EST) Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups: ; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Subject: IETF Adelaide and interim meetings for APPS WGs Date: Mon, 14 Feb 2000 18:37:05 -0500 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore