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

[Leif Johansson <[e-mail]>]

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.

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

It is quite possible (and I explained how in Stockholm) to redesign the 
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 
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.

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

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 
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 
explained how to avoid some of these issues to the authors. My 
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 
significant impact on the real-world deployment of this or (conversely) 
how this spec fundamentally hurts LDAP. I would love to be wrong about
this though!

	Cheers Leif