Subject: [nfsv4] Part of open issue NSDB-5: incorrect type for fedfsNcePrefix attribute

From: Chuck Lever <[email-masked]>
Date: Tue, 7 Aug 2012 14:23:38 -0400

In this e-mail, dated April 16, 2012:

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg10851.html

Howard Chu suggests:

> fedfsNcePrefix is really a DN (not a string) and must conform to DN syntax. That's made clear in the following definition, but this description is misleading. I note that LDAP is still basically X.500, and this informal definition is invalid in pure X.500 terms. You should dispense with the notion of prefix and just make this a regular DN, with a constraint that the DN will be subordinate to the containerInfo entry.

I'm not sure which version of the NSDB draft Chu was reviewing, but the one currently in Tom's git hub repository already treats the NCE prefix as a distinguished name.  Upon further discussion with Chu, in his opinion, using a prefix DN is "not normal" and he recommends that we should go with a full DN instead of a prefix.

Based on my own implementation experience, I agree that a full DN would allow more straightforward and proper client implementations:

1.  Part of my implementation's admin tool suite includes one or more tools that can be pointed at an LDAP service to configure it as an NSDB.  Constructing the value of the fedfsNcePrefix attribute is awkward, as it requires that the client itself split the DN of the new NCE to derive the prefix.

2.  Any file server NSDB client must reconstruct the full NCE DN by concatenating a namingContext DN with the NCE prefix.

While string manipulation is trivial in scripts and C, in general, I'm told that LDAP clients should not perform DN manipulation, but are encouraged to retrieve any needed DNs from the LDAP server.  Thus, if the NSDB returns a full DN instead of a prefix:

1.  After creating the NCE, the admin tool can simply store the DN that the LDAP server returns into the fedfsNsdbContainerInfo object.

2.  During junction resolution, searching the LDAP server's namingContext records returns one or more full DNs which the client can immediately use as a search base for FSN and FSL records.

IMO this allows cleaner client implementations.

I propose renaming the fedfsNcePrefix attribute to, say, fedfsNceDN; then adjusting remaining text in the NSDB protocol draft to treat this attribute as the full DN of the NCE residing under a particular namingContext.

Comments?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: James Lentini <[email-masked]>
Date: Tue, 7 Aug 2012 17:33:54 -0400 (EDT)

Hi Chuck,

I remember discussing several possible definitions before choosing the 
one in the draft. Our rational should have been captured in the 
meeting minutes in the list archive. I think we might have preferred 
a partial string over the full string for space reasons (at one point, 
the NCE was stored inside the junction, and we were trying to keep 
the amount of metadata for a junction small).

-james

On Tue, 7 Aug 2012, Chuck Lever wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Chuck Lever <[email-masked]>
Date: Tue, 7 Aug 2012 17:50:27 -0400

> the amount of metadata for a junction small).

Right, I recall the junction size discussion now.

We aren't storing the NCE in the junctions any longer, but instead are keeping them in LDAP, where IMO a full size DN makes more sense, and we don't seem to have a space constraint.