From Nicolas.Williams@sun.com Wed Sep 9 09:20:43 2009 Return-Path: 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 B62843A6999 for ; Wed, 9 Sep 2009 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.23 X-Spam-Level: X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] 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 xDe32ngEbHWf for ; Wed, 9 Sep 2009 09:20:42 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 7E2AF3A6870 for ; Wed, 9 Sep 2009 09:20:24 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n89GKqpW029502 for ; Wed, 9 Sep 2009 16:20:52 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n89GKq7Y014377 for ; Wed, 9 Sep 2009 10:20:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n89G9rr5013161; Wed, 9 Sep 2009 11:09:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n89G9qRm013160; Wed, 9 Sep 2009 11:09:52 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Sep 2009 11:09:52 -0500 From: Nicolas Williams To: ldap-dir@ietf.org, Alexey Melnikov Message-ID: <20090909160952.GV1048@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Mailman-Approved-At: Thu, 10 Sep 2009 08:05:09 -0700 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 16:20:43 -0000 Dear LDAP directorate, I have several issues with draft-ietf-nfsv4-federated-fs-protocol-03, of which at least two remain outstanding, and which the authors do not wish to address. My concerns: 1) It requires that searches have scope=one and base-DN="o=fedfs": " The base name (or suffix) of the NSDB directory information tree (DIT) is "o=fedfs". " and " The scope value of "one" restricts the search to the entry's children (rather than the entire subtree below the entry) and the filter ensures that only FSL entries are returned. " I believe this unnecessarily constrains deployment and will cause many problems. I also believe that this is probably an artifact of one or more of the authors needing to furnish a base DN to typical LDAP APIs, and the simplest (but wrong) thing to do was to hardcode it. The document also says the following, which, incidentally, is practically a corollary of the o=fedfs requirement: " Given the above configuration guidelines, an NSDB SHOULD be constructed using a dedicated LDAP directory. Separate LDAP directories may be used for other purposes, such as storing user account information. By using an LDAP directory dedicated to storing NSDB records, there is no need to disturb the configuration of any other LDAP directories that store information unrelated to an NSDB. " I don't think an RFC should make such a recommendation (really, a requirement). But more than anything I don't think an RFC should mandate the names of a DIT's namingContexts. (The example searches don't filter on objectClass, which may be another reason why the authors chose to segregate the NSDB from the rest of the DIT.) 2) The use of UUIDs for object naming to guarantee object DN uniqueness, while not necessarily a problem, seems unnecessary: the directory should ensure object DN uniqueness, thus there is no need to enforce uniqueness at the application layer! Specifically the I-D says: " Since LDAP requires a DN to be unique, this ensures that each FSN entry has a unique UUID value within the LDAP directory. " In particular it seems that the use of UUIDs derives from the fact that an NFSv4 federation is expected to consist of per-domain "NSDBs", where each NSDB is an LDAP DS or more, all with a flat NSDB object naming scheme (see issue (1)), but which is still expected to have federation- wide unique NSDB object names. That's where UUIDs as object names come in. Of course, there's no way in this scheme to know where an NSDB resides just from its name -- which begs the question of why a flat global NSDB object namespace is needed in the first place. I believe this document represents a gross misuse of LDAP. But I cannot convince the authors that that is the case. Hopefully the App Area will have a chance to review this document and review my concerns. Nico -- From leifj@it.su.se Thu Sep 10 08:57:41 2009 Return-Path: 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 5BB0C3A67F0 for ; Thu, 10 Sep 2009 08:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] 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 Czx8wOhmpxvZ for ; Thu, 10 Sep 2009 08:57:40 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 0A7CB3A6975 for ; Thu, 10 Sep 2009 08:57:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 403893BF3D; Thu, 10 Sep 2009 17:58:12 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05274-01-90; Thu, 10 Sep 2009 17:58:11 +0200 (CEST) Received: from klapautius.localnet (unknown [80.122.97.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 07A1B3C674; Thu, 10 Sep 2009 17:58:10 +0200 (CEST) From: Leif Johansson Organization: Stockholm university To: ldap-dir@ietf.org Date: Thu, 10 Sep 2009 17:58:05 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; ) References: <20090909160952.GV1048@Sun.COM> In-Reply-To: <20090909160952.GV1048@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2490202.V2fDJGhXmW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909101758.10049.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 15:57:41 -0000 --nextPart2490202.V2fDJGhXmW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 09 September 2009 18.09.52 Nicolas Williams wrote: > Dear LDAP directorate, > > I have several issues with draft-ietf-nfsv4-federated-fs-protocol-03, of > which at least two remain outstanding, and which the authors do not wish > to address. My concerns: > I had a conversation with them at the last IETF and voiced similar concerns= =2E=20 While I mostly agree with you (comments on details in line) I'm not sure ho= w=20 serious they are for practical deployment of this stuff. > 1) It requires that searches have scope=3Done and base-DN=3D"o=3Dfedfs": > > " > The base name (or suffix) of the NSDB directory information tree > (DIT) is "o=3Dfedfs". > " > > and > > " > The scope value of "one" restricts the > search to the entry's children (rather than the entire subtree below > the entry) and the filter ensures that only FSL entries are returned. > " > > I believe this unnecessarily constrains deployment and will cause many > problems. I also believe that this is probably an artifact of one or > more of the authors needing to furnish a base DN to typical LDAP APIs, > and the simplest (but wrong) thing to do was to hardcode it. > > The document also says the following, which, incidentally, is > practically a corollary of the o=3Dfedfs requirement: > > " > Given the above configuration guidelines, an NSDB SHOULD be > constructed using a dedicated LDAP directory. Separate LDAP > directories may be used for other purposes, such as storing user > account information. By using an LDAP directory dedicated to storing > NSDB records, there is no need to disturb the configuration of any > other LDAP directories that store information unrelated to an NSDB. > " > > I don't think an RFC should make such a recommendation (really, a > requirement). But more than anything I don't think an RFC should > mandate the names of a DIT's namingContexts. > > (The example searches don't filter on objectClass, which may be another > reason why the authors chose to segregate the NSDB from the rest of the > DIT.) > It is quite possible (and I explained how in Stockholm) to redesign the=20 searches to remove all of these requirements. However I'm not sure anyone will ever deploy NSDB along with any other directory information anyway because NSDB requires read access to all data in the subtree. I've found that most directory admins can't manage access rights and asking them to stick a large dataset in their systems=20 with public access is like asking a DNS admin to add a RR for which there i= s=20 no GUI in the admin tool. The result is consternation at best. I believe that practically speaking NSDB will run on dedicated directory=20 servers administrated separately from other directory servers in the enterprise no matter how hard you try and I don't see how that is=20 such a big problem... Having said that I do agree with the technical points you make. > 2) The use of UUIDs for object naming to guarantee object DN uniqueness, > while not necessarily a problem, seems unnecessary: the directory should > ensure object DN uniqueness, thus there is no need to enforce uniqueness > at the application layer! > Well yes but since you can't "lock" a name you can't first figure out which name to give your new entry and then go away and create it - unless you depend on extensions for transaction-like grouping of operations in LDAP. Personally I think its fine to say MUST be unique and suggest (in an=20 implementation note) how you can achieve uniqueness using UUIDs. > Specifically the I-D says: > > " > Since LDAP requires a DN to be unique, this ensures that each FSN > entry has a unique UUID value within the LDAP directory. > " > > In particular it seems that the use of UUIDs derives from the fact that > an NFSv4 federation is expected to consist of per-domain "NSDBs", where > each NSDB is an LDAP DS or more, all with a flat NSDB object naming > scheme (see issue (1)), but which is still expected to have federation- > wide unique NSDB object names. That's where UUIDs as object names come > in. Of course, there's no way in this scheme to know where an NSDB > resides just from its name -- which begs the question of why a flat > global NSDB object namespace is needed in the first place. > > I believe this document represents a gross misuse of LDAP. But I cannot > convince the authors that that is the case. Hopefully the App Area will > have a chance to review this document and review my concerns. I think gross misuse is an overstatement. Do they use LDAP the way a normal identity-oriented directory does? Nope. Will that be the end of the world as we know it? Probably not. Let me emphasise that I mostly agree with your points and that I've=20 explained how to avoid some of these issues to the authors. My=20 impression is that if there are good reasons to redesign the spec then the authors would do that. They don't strike me as unreasonable. The problem is that I can't really see how a redesign will have a=20 significant impact on the real-world deployment of this or (conversely)=20 how this spec fundamentally hurts LDAP. I would love to be wrong about this though! Cheers Leif --nextPart2490202.V2fDJGhXmW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqpIg4ACgkQ8Jx8FtbMZnfgpgCeK2UOmU1rqFI7+4GDv00sUn59 L50AoK7BinZbLriid1AHG8Ox3lEBYsXP =4avI -----END PGP SIGNATURE----- --nextPart2490202.V2fDJGhXmW-- From Nicolas.Williams@sun.com Thu Sep 10 10:03:07 2009 Return-Path: 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 B86583A6A1D for ; Thu, 10 Sep 2009 10:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.233 X-Spam-Level: X-Spam-Status: No, score=-5.233 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] 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 TrJ4fWYmq2GH for ; Thu, 10 Sep 2009 10:03:06 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 17A1B3A6B24 for ; Thu, 10 Sep 2009 10:03:06 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8AH3e4i021679 for ; Thu, 10 Sep 2009 17:03:40 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8AH3e14049154 for ; Thu, 10 Sep 2009 11:03:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8AGqedP013827; Thu, 10 Sep 2009 11:52:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8AGqeHx013826; Thu, 10 Sep 2009 11:52:40 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 10 Sep 2009 11:52:40 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20090910165239.GN1033@Sun.COM> References: <20090909160952.GV1048@Sun.COM> <200909101758.10049.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909101758.10049.leifj@it.su.se> User-Agent: Mutt/1.5.7i X-Mailman-Approved-At: Thu, 10 Sep 2009 10:08:54 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 17:03:07 -0000 On Thu, Sep 10, 2009 at 05:58:05PM +0200, Leif Johansson wrote: > On Wednesday 09 September 2009 18.09.52 Nicolas Williams wrote: > > Dear LDAP directorate, > > > > I have several issues with draft-ietf-nfsv4-federated-fs-protocol-03, of > > which at least two remain outstanding, and which the authors do not wish > > to address. My concerns: > > > > I had a conversation with them at the last IETF and voiced similar concerns. > While I mostly agree with you (comments on details in line) I'm not sure how > serious they are for practical deployment of this stuff. They are. I spoke to one of them yesterday, and will speak to the rest today, and I understand better why they made some of their design choices. For example: the objects they have are all named from UUIDs, and represent nothing special, access wise, so that letting anonymous principals read them is perfectly reasonable. And for publishing the only control needed is a resource consumption control. There's not much benefit to re-using an existing directory infrastructure then, not beyond the hardware (and software license) re-use aspect. But I still think that the model should allow for re-use of existing directory infrastructure. After talking to one of them about it I've concluded that mostly that would just mean that their "NSDB name" attribute (fedfsNsdbName) needs to track not just the name of the NSDB, but also a base DN for it. That's another thing, the NSDB name is just a hostname; it's expected to have multiple A RRs if there are multiple NSDB servers. An SRV RR would be better, but it's not clear how to name it: a domain could have more than one distinct NSDB, which means that simply naming the SRV RR something like _nsdb._ldap._tcp. wouldn't work. > It is quite possible (and I explained how in Stockholm) to redesign the > searches to remove all of these requirements. Yes, but it should be possible to avoid an extensive redesign. Allowing arbitrary DN suffixes is just a matter of adding an attribute to FSNs and to junctions (which are a server-local concept, without an NSDB object class to represent them) to track the base DN of the NSDB. I think that'd be sufficient. Fileservers store {UUID, NSDB name} in their 'junctions'. They'd have to store {UUID, NSDB name, NSDB base DN} to allow for arbitrary base DNs. To avoid the use of UUIDs, scope=one and o=fedfs container, fileservers would have to store {FSN DN, NSDB name} or {FSN RDN, NSDB name, NSDB base DN}. It might be too late to change from using UUIDs to name FSNs, in which case, for uniqueness, one would want all FSNs in one container, so it may not be possible to remove the o=fedfs requirement, but we might still be able to get an NSDB base DN attribute added to the mix. > However I'm not sure anyone will ever deploy NSDB along with any other > directory information anyway because NSDB requires read access to all > data in the subtree. I've found that most directory admins can't manage > access rights and asking them to stick a large dataset in their systems > with public access is like asking a DNS admin to add a RR for which there is > no GUI in the admin tool. The result is consternation at best. Interesting. Of course, some directory servers make it trivial to setup inherittable ACLs so the right thing happens... > I believe that practically speaking NSDB will run on dedicated directory > servers administrated separately from other directory servers in the > enterprise no matter how hard you try and I don't see how that is > such a big problem... Interesting. Well, I may well just give then. > Having said that I do agree with the technical points you make. Well, if no one would ever want to deploy NSDBs in existing directory infrastructure, then my technical points would be rendered irrelevant. Don't you agree? If so then I would withdraw all my complaints. > > 2) The use of UUIDs for object naming to guarantee object DN uniqueness, > > while not necessarily a problem, seems unnecessary: the directory should > > ensure object DN uniqueness, thus there is no need to enforce uniqueness > > at the application layer! > > Well yes but since you can't "lock" a name you can't first figure out which > name to give your new entry and then go away and create it - unless you > depend on extensions for transaction-like grouping of operations in LDAP. LDAP is supposed to ensure DN uniqueness atomically, is it not? You'd create the FSLs first, then the creat/update FSNs to refer to the FSLs. > > I believe this document represents a gross misuse of LDAP. But I cannot > > convince the authors that that is the case. Hopefully the App Area will > > have a chance to review this document and review my concerns. > > I think gross misuse is an overstatement. Do they use LDAP the way a > normal identity-oriented directory does? Nope. Will that be the end of > the world as we know it? Probably not. Now that I understand the federated FS proposal better I agree. Nico -- From leifj@it.su.se Fri Sep 11 01:01:13 2009 Return-Path: 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 ; 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 ; 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 ; 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 Organization: Stockholm university To: Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 08:01:13 -0000 --nextPart2316727.Pvi4Yh6v63 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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=20 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.=20 Cheers Leif --nextPart2316727.Pvi4Yh6v63 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqqA+oACgkQ8Jx8FtbMZnfzCgCdESoCmLoRJ1P+ZMy44zrzM4rc Sp8AoKJdYDmi2E7vit2HSLXBk0Z84iEK =4DW5 -----END PGP SIGNATURE----- --nextPart2316727.Pvi4Yh6v63-- From Nicolas.Williams@sun.com Fri Sep 11 10:13:53 2009 Return-Path: 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 E9B503A6892 for ; Fri, 11 Sep 2009 10:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 fmDZkNDdqp3C for ; Fri, 11 Sep 2009 10:13:52 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 4F4A528C1E7 for ; Fri, 11 Sep 2009 10:13:50 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8BHERYm018954 for ; Fri, 11 Sep 2009 17:14:27 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8BHERZI015784 for ; Fri, 11 Sep 2009 11:14:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8BH3SRj014992; Fri, 11 Sep 2009 12:03:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8BH3QD9014991; Fri, 11 Sep 2009 12:03:26 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 11 Sep 2009 12:03:26 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20090911170326.GK1033@Sun.COM> References: <20090909160952.GV1048@Sun.COM> <200909101758.10049.leifj@it.su.se> <20090910165239.GN1033@Sun.COM> <200909111001.46140.leifj@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909111001.46140.leifj@it.su.se> User-Agent: Mutt/1.5.7i X-Mailman-Approved-At: Fri, 11 Sep 2009 10:18:30 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 17:13:54 -0000 On Fri, Sep 11, 2009 at 10:01:45AM +0200, Leif Johansson wrote: > > > 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. I think they do not. > > 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. An FSL alone is utterly useless and harmless. An FSN alone too is utterly useless. It's only when junctions (which are local to servers) refer to FSNs, which in turn refer to FSLs, that FSNs and FSLs matter. Incidentaly the elephant in the I-D that wasn't specifically called out, but which should have been, is that references to FSNs must be small and fixed sized. By using {UUID, NSDB hostname} they were able to keep references very small: 16 + 256 bytes, or if you intern the NSDB hostnames, possibly as small as 20 bytes. This was crucial to my understanding of the design :(