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

[chuck.lever@oracle.com]

On Apr 16, 2012, at 1:09 PM, Howard Chu wrote:

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

The point of XDR blobs is that a file server doesn't need to un-marshall then re-marshall the pathname data when it generates a referral.  Replacement suggestions welcome.

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

This draft has been in last call for months, I'm surprised there are so many issues.  I think there is still an opportunity for discussion on the working group mailing list.  We welcome your comments on nfsv4@ietf.org.

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