Requirements for Federated File Systems
RFC 5716

Note: This ballot was opened for revision 06 and is now closed.

(Lars Eggert) Yes

(Ron Bonica) No Objection

(Ralph Droms) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

Comment (2009-10-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Nice document. Thank you.

(Russ Housley) (was Discuss) No Objection

(Alexey Melnikov) No Objection

Comment (2009-10-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
   A6:  In a federated system, we assume that an FSN MUST express, or
        can be used to discover, the following two pieces of
        information:

 [...]

        As an example, an FSN could be represented by a URL of the form
        nsdb.example.com/UUID

Pedantic: this is actually not a proper URL.

        where nsdb.example.com is the FQDN of the
        server hosting the NSDB node and UUID is the string
        representation of the identifier.


   R9:   The projected namespace (and the objects named by the
         namespace) MUST be accessible to clients via at least one
         standard filesystem access protocol.

What do you call a "standard filesystem access protocol"?

         a.  The namespace SHOULD be accessible to clients via versions
             of the CIFS (SMB) protocol.

Is there a reference for CIFS that can be used?
(There was actually one earlier reference to CIFS in the document.)

         b.  The namespace SHOULD be accessible to clients via the NFSv4
             protocol as described in [RFC3530].

         c.  The namespace SHOULD be accessible to clients via the NFSv3
             protocol as described in [RFC1813].

         d.  The namespace SHOULD be accessible to clients via the NFSv2
             protocol as described in [RFC1094].

7.  Security Considerations

   A federation could contain multiple Public Key Infrastructure (PKI)
   trust anchors [RFC5280].  The federation protocols SHOULD define a
   mechanism for managing a fileserver's NSDB trust anchors
   [TA-MGMT-REQS].  A general purpose trust anchor management protocol
   [TAMP] would be appropriate, though it might be desirable for the
   federation protocols to facilitate trust anchor management by, for
   example, using trust anchor interchange formats [TA-FORMAT].

It would be more logical to have these requirements elsewhere in the document, if they are indeed requirements.


I think the following references are Informative:

   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
              Specification", RFC 2203, September 1997.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC4513]  Harrison, R., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.