Skip to main content

Requirements for Federated File Systems
draft-ietf-nfsv4-federated-fs-reqts-06

Yes

(Lars Eggert)

No Objection

(Pasi Eronen)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)

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

Lars Eggert Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2009-10-22) Unknown
Nice document. Thank you.
Alexey Melnikov Former IESG member
No Objection
No Objection (2009-10-19) Unknown
   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.
Pasi Eronen Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown