Re: (ITS#7246) Addition of FedFS schema LDIF

[hyc@symas.com]

chuck.lever@oracle.com wrote:
> Full_Name: Chuck Lever
> Version: All
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (99.26.161.222)
>
>
> I'd like to request the addition of the FedFS schema described in this draft:
>
>    http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11
>
> as part of the repertoire of schemas that are installed by default for new
> servers.  An overview of FedFS can be found here:
>
>    http://tools.ietf.org/html/rfc5716
>
> I've posted an LDIF containing the FedFS NSDB schema in draft 11 here:
>
>    http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif

This gets a 404 for me.

> This contains the correct IETF boilerplate.  The schema is extracted verbatim
> from draft 11.
>
> Addendum:  The NSDB draft is in last call, and there have been some changes to
> the schema.  I will provide a refresh as soon as the next revision of the draft
> is available.

 From an LDAP perspective I see a few nits that should be cleaned up in this 
definition. Haven't looked at it from the NFS perspective.

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

4.2.1.1
    I note that LDAP already has a UUID syntax 1.3.6.1.1.16.1 and I don't 
believe you should be defining yours as inheriting from "name".

4.2.1.2/3
    IMO you should define a URL format instead of distinct address/port 
attributes.

4.2.1.14
    XDR blobs? Really?

4.2.1.18...
    Single-bit attributes? You seem to be specifying a particular 
implementation of a file service. IETF specs should define protocols and data 
interchange formats, but leave implementation-level details to implementors.

4.2.2.2 fedfsFsn
    IMO name/port should just be an LDAP URL. Also your definition provides 
absolutely zero information of how the LDAP server should be contacted (e.g. 
using ldaps or StartTLS) which both can be encoded in an LDAP URL. It also 
precludes the use of ldapi:// which might be preferred for an 
inward-facing/local agent.

I haven't read the rest of the draft but IMO this is premature for a last call.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/