Re: [Ldap-dir] Concerns about draft-ietf-nfsv4-federated-fs-protocol

Leif Johansson <leifj@it.su.se> Fri, 11 September 2009 08:01 UTC

Return-Path: <leifj@it.su.se>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B583A68DE for <ldap-dir@core3.amsl.com>; Fri, 11 Sep 2009 01:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4c7bfklKkGs for <ldap-dir@core3.amsl.com>; Fri, 11 Sep 2009 01:01:12 -0700 (PDT)
Received: from smtp.su.se (smtp2.su.se [130.237.164.53]) by core3.amsl.com (Postfix) with ESMTP id 299053A68B0 for <ldap-dir@ietf.org>; Fri, 11 Sep 2009 01:01:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id B65F65C15F; Fri, 11 Sep 2009 10:01:47 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at av-in.su.se
Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nEZa2Lxzh1fy; Fri, 11 Sep 2009 10:01:47 +0200 (CEST)
Received: from klapautius.localnet (unknown [192.36.125.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTPSA id 47B1281ACC; Fri, 11 Sep 2009 10:01:47 +0200 (CEST)
From: Leif Johansson <leifj@it.su.se>
Organization: Stockholm university
To: Nicolas Williams <Nicolas.Williams@sun.com>
Date: Fri, 11 Sep 2009 10:01:45 +0200
User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; )
References: <20090909160952.GV1048@Sun.COM> <200909101758.10049.leifj@it.su.se> <20090910165239.GN1033@Sun.COM>
In-Reply-To: <20090910165239.GN1033@Sun.COM>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2316727.Pvi4Yh6v63"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <200909111001.46140.leifj@it.su.se>
Cc: ldap-dir@ietf.org
Subject: Re: [Ldap-dir] Concerns about draft-ietf-nfsv4-federated-fs-protocol
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 08:01:13 -0000

> LDAP is supposed to ensure DN uniqueness atomically, is it not?
>

Yes but only in a single operation. I suspect (but I may be wrong) that 
several of the logical operations they need to perform would need to
span multiple LDAP operations creating race conditions on the name.

> You'd create the FSLs first, then the creat/update FSNs to refer to the
> FSLs.

That might work unless a semi-populated FSL entry is dangerous. 

	Cheers Leif