Subject: [nfsv4] Fwd: (ITS#7246) Addition of FedFS schema LDIF

From: Chuck Lever <[email-masked]>
Date: Mon, 16 Apr 2012 13:17:14 -0400

Hi-

I submitted a request to include the FedFS NSDB schema in the OpenLDAP distribution.  The OpenLDAP community feels the NSDB schema is immature.  Here is a sample of comments.

I asked that they bring the discussion to <[email-masked]>.

Begin forwarded message:

> From: Howard Chu <[email-masked]>
> Subject: Re: (ITS#7246) Addition of FedFS schema LDIF
> Date: April 16, 2012 1:09:20 PM EDT
> To: [email-masked]
> Cc: [email-masked]
> 
> [email-masked] 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/

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 16 Apr 2012 17:36:09 +0000

Chuck,

Based on these comments, do you have a suggestion of what action the authors of the I-Ds or the working group should undertake?

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chuck Lever
Sent: Monday, April 16, 2012 10:17 AM
To: [email-masked]
Subject: [nfsv4] Fwd: (ITS#7246) Addition of FedFS schema LDIF

Hi-

Begin forwarded message:

>> URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) 
>> (99.26.161.222)
>> 
>> 
>> as part of the repertoire of schemas that are installed by default 
>> for new servers.  An overview of FedFS can be found here:
>> 
>> 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.
> 

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 16 Apr 2012 14:12:28 -0400

Hi-

> Based on these comments, do you have a suggestion of what action the authors of the I-Ds or the working group should undertake?

In my opinion....

First, we should publish the schema changes that were agreed on six months ago into a fresh revision of the NSDB draft.

Then we should offer to entertain a full review of the revised schema by at least the OpenLDAP folks, who have plenty of standards experience of their own.  Like file server vendors, LDAP server vendors can provide relevant implementation experience, thus should be explicitly included in the review process for this draft.

Do these comments echo comments we've already received?  If not, we should ask ourselves why similar comments did not come from last call review.  Do we need to circulate this draft more widely or aggressively inside the IETF?

Lastly, Howard is a very experienced LDAP developer.  I think his comments should be considered: The use of LDAP native UUID types, for example; and perhaps changing the NCE prefix mechanism as he suggests.  I'm no fan of storing XDR blobs in LDAP either.  Some clarifications of our design choices around how we identify file and LDAP servers might also go towards his suggestions about using URLs in certain places.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 16 Apr 2012 18:21:15 +0000

Thanks, Chuck.

Any other comments or opinions (from the WG)?

Spencer

> From: Chuck Lever [mailto:[email-masked]]
> Sent: Monday, April 16, 2012 11:12 AM
> To: Spencer Shepler
> Cc: [email-masked]
> Subject: Re: [nfsv4] Fwd: (ITS#7246) Addition of FedFS schema LDIF
> 
> Hi-
> 
> > Based on these comments, do you have a suggestion of what action the
> authors of the I-Ds or the working group should undertake?
> 
> In my opinion....
> 
> First, we should publish the schema changes that were agreed on six months
> ago into a fresh revision of the NSDB draft.
> 
> Then we should offer to entertain a full review of the revised schema by
> at least the OpenLDAP folks, who have plenty of standards experience of
> their own.  Like file server vendors, LDAP server vendors can provide
> relevant implementation experience, thus should be explicitly included in
> the review process for this draft.
> 
> Do these comments echo comments we've already received?  If not, we should
> ask ourselves why similar comments did not come from last call review.  Do
> we need to circulate this draft more widely or aggressively inside the
> IETF?
> 
> Lastly, Howard is a very experienced LDAP developer.  I think his comments
> should be considered: The use of LDAP native UUID types, for example; and
> perhaps changing the NCE prefix mechanism as he suggests.  I'm no fan of
> storing XDR blobs in LDAP either.  Some clarifications of our design
> choices around how we identify file and LDAP servers might also go towards
> his suggestions about using URLs in certain places.
> 
> 
> > Spencer
> >
> > I submitted a request to include the FedFS NSDB schema in the OpenLDAP
> distribution.  The OpenLDAP community feels the NSDB schema is immature.
> Here is a sample of comments.
> >
> >> 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
> >>  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.
> >>