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

[Nicolas Williams <[e-mail]>]

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.<domainname> 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
--