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 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.
chuck.lever@oracle.com wrote: > 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 link does not work: HTTP/1.1 404 Not Found > 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. I really wonder why 'fedfsUuid' is SUP name instead of being based on LDAP syntax UUID (see RFC 4530). Ciao, Michael.
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/
Corrected URL: http://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif -- Chuck Lever chuck[dot]lever[at]oracle[dot]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
hyc@symas.com wrote: > 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. Which standard describes how to mandate use of StartTLS with a LDAP URL? OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with web2ldap. But AFAIK this is not defined in any standard which could be referenced in a RFC. http://www.openldap.org/lists/openldap-devel/200202/msg00060.html http://www.openldap.org/lists/openldap-devel/200810/msg00034.html Ciao, Michael.
Michael Ströder wrote: > hyc@symas.com wrote: >> 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. > > Which standard describes how to mandate use of StartTLS with a LDAP URL? > OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with > web2ldap. But AFAIK this is not defined in any standard which could be > referenced in a RFC. True but irrelevant. The point is that standardizing on a URL syntax today future-proofs a spec and allows it to handle new connection mechanisms that may appear in the future. Host/port is inextricably tied to networking in the 1980s. > http://www.openldap.org/lists/openldap-devel/200202/msg00060.html > http://www.openldap.org/lists/openldap-devel/200810/msg00034.html > > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > Michael Ströder wrote: >> hyc@symas.com wrote: >>> 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. >> >> Which standard describes how to mandate use of StartTLS with a LDAP URL? >> OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with >> web2ldap. But AFAIK this is not defined in any standard which could be >> referenced in a RFC. > > True but irrelevant. The point is that standardizing on a URL syntax today > future-proofs a spec and allows it to handle new connection mechanisms that > may appear in the future. Host/port is inextricably tied to networking in the > 1980s. I did not want to endorse the use of host/port. I just wanted to point out that one cannot specify the use of StartTLS by LDAP URL in a standard way. Of course nothing prevents somebody to add custom extension to LDAP URLs. Ciao, Michael.
It appears that the schema LDIF files shipped with OpenLDAP are strictly for basic LDAP attribute type and object class definitions. Everything else is considered a "user schema," including schemas for implementing a DNS or NIS backend, and so on. It appears to me that FedFS would fall into this latter category, and thus should not be included in the packaged schema. Comments?
chuck.lever@oracle.com wrote: > It appears that the schema LDIF files shipped with OpenLDAP are strictly > for basic LDAP attribute type and object class definitions. Everything > else is considered a "user schema," including schemas for implementing a > DNS or NIS backend, and so on. It appears to me that FedFS would fall into > this latter category, and thus should not be included in the packaged > schema. There are various schema files shipped with OpenLDAP source. In opposite to other LDAP servers not all schema files are enabled by default. But it seems to me that https://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif does not contain exactly the same schema elements like defined in http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-13 Ciao, Michael.
On Oct 7, 2012, at 11:04 AM, Michael Ströder wrote: > chuck.lever@oracle.com wrote: >> It appears that the schema LDIF files shipped with OpenLDAP are strictly >> for basic LDAP attribute type and object class definitions. Everything >> else is considered a "user schema," including schemas for implementing a >> DNS or NIS backend, and so on. It appears to me that FedFS would fall into >> this latter category, and thus should not be included in the packaged >> schema. > > There are various schema files shipped with OpenLDAP source. In opposite to > other LDAP servers not all schema files are enabled by default. I see. > But it seems to me that > > https://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif > > does not contain exactly the same schema elements like defined in > > http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-13 The oss.oracle.com fedfs-utils home page has been deprecated, and will go away soon. That site contains an outdated version of the NSDB schema. Since then, we have attempted to address comments received from openldap-technical. The version defined in the current IETF NSDB protocol draft, which you link to above, is the authoritative version. We may see one or two more revisions as the draft goes through the final IESG review process. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com
moved from Incoming to Software Enhancements