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

[Nicolas Williams <[e-mail]>]

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