One thing I'd like to do before turning this on in rawhide is to find a way to have the daemon drop privs after starting up. The problem there is that if someone takes down nfsd and starts it back up, then we need to be able to reopen the pipe. For that (at least currently) we need superuser privileges.
A couple of possible solutions...
1) privilege separation. Have the pipe opening be done in a privileged process, and then have it fork and pass the fd of the pipe to a child that drops privs and
does everything else. If the pipe needs to be reopened, then the child could die
and the parent could reopen the pipe and fork again.
2) use capabilities -- have the child drop everything except CAP_DAC_OVERRIDE permanently, and drop that too temporarily unless it needs to reopen the pipe. Maybe also have it setuid/setgid itself to a non-root user. That's fairly simple to implement so that might be the easiest way to start.

Ok, I have a patch that I've proposed upstream that has nfsdcld drop all capabilities. I probably will do one more respin of it to update the manpage with the requirements that it imposes, but I think it's good enough for now.
I also have a fedora patch that adds nfsdcld to the package and a systemd unit file for it, and makes nfs-server.service depend on it. That seems to work correctly too.

Based on great hue and cry from upstream, I'm looking at converting this to a usermodehelper upcall so we won't need to have a running daemon. It doesn't look too hard to do -- most of the sqlite backend code for nfsdcld should just convert right to it. nfsdcld also didn't pass back much info to the kernel, so there's little need for a downcall. So, pushing this out to f19 for now...

I've started coding up a new program that I'm calling "nfsdcltrack". It uses the same sqlite backend code as nfsdcld, but a simple frontend that just passes info via command line arguments and returns a simple error code.
The catch here is that nfsdcld was able to pass a binary struct to userspace, so we didn't have to covert the nfs_client_id4 opaque blob to something that can sit in the argv array. Now we'll need to do some sort of binary to text conversion to send it to userspace.
Once we get that text blob to userspace, we can either stick it into the DB as-is, or convert it back to binary. Converting will take a bit more userspace processing initially, but will store more efficiently and will mean that the database would be interchangeable between nfsdcld and nfsdcltrack. It might also mean a more efficient search of the database (not sure on this though).

Well, looks like this actually made f18! The nfsdcltrack binary is part of nfs-utils in f18, and with the release of the 3.8 kernel this is now active. I just confirmed that my unmodified f18 box is using nfsdcltrack now, so I think we can call this closed.