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