draft-ietf-nfsv4-federated-fs-reqts-04.txt		draft-ietf-nfsv4-federated-fs-reqts-05.txt
	NFSv4 Working Group J. Lentini		NFSv4 Working Group J. Lentini
	Internet-Draft C. Everhart		Internet-Draft C. Everhart
	Intended status: Informational NetApp		Intended status: Informational NetApp
	Expires: April 4, 2010 D. Ellard		Expires: April 19, 2010 D. Ellard
	BBN Technologies		BBN Technologies
	R. Tewari		R. Tewari
	M. Naik		M. Naik
	IBM Almaden		IBM Almaden
	October 1, 2009		October 16, 2009
	Requirements for Federated File Systems		Requirements for Federated File Systems
	draft-ietf-nfsv4-federated-fs-reqts-04		draft-ietf-nfsv4-federated-fs-reqts-05
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 47		skipping to change at page 1, line 47
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 4, 2010.		This Internet-Draft will expire on April 19, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	skipping to change at page 4, line 36		skipping to change at page 4, line 36
	3.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11		3.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11
	4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16		5. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16
	5.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16		5.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16
	5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19		5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 26		6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 26
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27		7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 29		9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	9.2. Informational References . . . . . . . . . . . . . . . . . 29		9.2. Informational References . . . . . . . . . . . . . . . . . 30
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Overview		1. Overview
	This document describes and lists the functional requirements of a		This document describes and lists the functional requirements of a
	federated file system and defines related terms.		federated file system and defines related terms.
	We do not describe the mechanisms that might be used to implement		We do not describe the mechanisms that might be used to implement
	this functionality except in cases where specific mechanisms, in our		this functionality except in cases where specific mechanisms, in our
	opinion, follow inevitably from the requirements. Our focus is on		opinion, follow inevitably from the requirements. Our focus is on
	the interfaces between the entities of the system, not on the		the interfaces between the entities of the system, not on the
	skipping to change at page 5, line 39		skipping to change at page 5, line 39
	called an "FSN" (fileset name), and each physical filesystem has a		called an "FSN" (fileset name), and each physical filesystem has a
	fileset location ("FSL"). A fileset is a directory tree containing		fileset location ("FSL"). A fileset is a directory tree containing
	files and directories, and it may also contain references to other		files and directories, and it may also contain references to other
	filesets. These references are called "junctions". To provide		filesets. These references are called "junctions". To provide
	location independence, a junction does not contain information about		location independence, a junction does not contain information about
	the location of the real resource(s), but instead contains an FSN		the location of the real resource(s), but instead contains an FSN
	that can be used to look up the location information. The service		that can be used to look up the location information. The service
	that can be used to map from FSN to FSL(s) is called a namespace		that can be used to map from FSN to FSL(s) is called a namespace
	database (NSDB) service. The NSDB provides a level of indirection		database (NSDB) service. The NSDB provides a level of indirection
	from the virtual paths in the uniform namespace to the actual		from the virtual paths in the uniform namespace to the actual
	locations of files.		locations of files. By design, the NSDB does not store the
			junctions. This allows junction administration and NSDB
			administration to be separate roles.
	The servers direct clients to the proper locations by existing		The servers direct clients to the proper locations by existing
	mechanisms (e.g. the referrals mechanism within [RFC3530] and		mechanisms (e.g. the referrals mechanism within [RFC3530] and
	[NFSv4.1]). Updates to the locations make it possible to support		[NFSv4.1]). Updates to the locations make it possible to support
	migration and replication of physical filesystems that comprise the		migration and replication of physical filesystems that comprise the
	namespace, in a way that is transparent to filesystem applications.		namespace, in a way that is transparent to filesystem applications.
	Figure 1 shows an example of a federation. This federation has two		Figure 1 shows an example of a federation. This federation has two
	members, named ALPHA and BETA. Federation members may contain an		members, named ALPHA and BETA. Federation members may contain an
	arbitrary number of file servers and NSDB nodes; in this illustration		arbitrary number of file servers and NSDB nodes; in this illustration
	skipping to change at page 14, line 19		skipping to change at page 14, line 19
	same.		same.
	Junction: A filesystem object used to link a directory name in the		Junction: A filesystem object used to link a directory name in the
	current fileset with an object within another fileset. The		current fileset with an object within another fileset. The
	server-side "link" from a leaf node in one fileset to the root of		server-side "link" from a leaf node in one fileset to the root of
	another fileset.		another fileset.
	Namespace: A filename/directory tree that a sufficiently-authorized		Namespace: A filename/directory tree that a sufficiently-authorized
	client can observe.		client can observe.
	NSDB (Namespace Database Service): A service that maps FSNs to FSLs.		NSDB (Namespace Database) Service: A service that maps FSNs to FSLs.
	The NSDB may also be used to store other information, such as		The NSDB may also be used to store other information, such as
	annotations for these mappings and their components.		annotations for these mappings and their components.
	NSDB Node: The name or location of a server that implements part of		NSDB Node: The name or location of a server that implements part of
	the NSDB service and is responsible for keeping track of the FSLs		the NSDB service and is responsible for keeping track of the FSLs
	(and related info) that implement a given partition of the FSNs.		(and related info) that implement a given partition of the FSNs.
	Referral: A server response to a client access that directs the		Referral: A server response to a client access that directs the
	client to evaluate the current object as a reference to an object		client to evaluate the current object as a reference to an object
	at a different location (specified by an FSL) in another fileset,		at a different location (specified by an FSL) in another fileset,
	skipping to change at page 19, line 32		skipping to change at page 19, line 32
	to FSL(s) change under these transformations.		to FSL(s) change under these transformations.
	d. All files accessible from the global namespace MUST be part		d. All files accessible from the global namespace MUST be part
	of a fileset that has an assigned FSN.		of a fileset that has an assigned FSN.
	Not all filesets in the federation are required to have an FSN		Not all filesets in the federation are required to have an FSN
	or be reachable by an FSL. Only those filesets that are the		or be reachable by an FSL. Only those filesets that are the
	target of a junction (as described in R3) are required to have		target of a junction (as described in R3) are required to have
	an FSN.		an FSN.
			The FSN format MAY be variable size. If the format is variable
			size, fileserver implementations MAY have a maximum supported
			FSN size. By bounding the FSN size, some fileserver
			implementations might be able to efficiently organize FSNs in
			stable storage. For interoperability, the federation protocols
			SHOULD define an FSN size that all fileservers support.
	R2: USING THE FEDERATION INTERFACES, it MUST be possible to create		R2: USING THE FEDERATION INTERFACES, it MUST be possible to create
	an FSN for a fileset, and it must be possible to bind an FSL to		an FSN for a fileset, and it must be possible to bind an FSL to
	that FSN. These operations are NSDB operations and do not		that FSN. These operations are NSDB operations and do not
	require any action on the part of a file server.		require any action on the part of a file server.
	It is possible to create an FSN for a fileset that has not		It is possible to create an FSN for a fileset that has not
	actually been created. It is also possible to bind a		actually been created. It is also possible to bind a
	nonexistent FSL to an FSN. It is also possible to create a		nonexistent FSL to an FSN. It is also possible to create a
	fileset without assigning it an FSN. The binding between an		fileset without assigning it an FSN. The binding between an
	FSN and an FSL is defined entirely within the context of the		FSN and an FSL is defined entirely within the context of the
	skipping to change at page 28, line 5		skipping to change at page 27, line 32
	Well-established techniques for providing authenticated channels may		Well-established techniques for providing authenticated channels may
	be used to defeat these attacks, and the protocol MUST support at		be used to defeat these attacks, and the protocol MUST support at
	least one of them.		least one of them.
	For example, if LDAP is used to implement the query mechanism		For example, if LDAP is used to implement the query mechanism
	[RFC4510], then TLS may be used to provide both authentication and		[RFC4510], then TLS may be used to provide both authentication and
	integrity [RFC5246] [RFC4513]. If the query protocol is implemented		integrity [RFC5246] [RFC4513]. If the query protocol is implemented
	on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role		on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role
	[RFC2203] [RFC2743].		[RFC2203] [RFC2743].
			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 is useful to note that the requirements described in this document
			lead naturally to a system with distributed authorization, which has
			scalability and manageability benefits.
			FSNs are likely to be long lived resources. Therefore, the privilege
			to create FSNs SHOULD be carefully controlled. To assist in
			determining if an FSN is referenced by a junction somewhere in the
			federation, the NSDB records SHOULD include non-authoritative
			informational annotations recording the locations of any such
			junctions. These annotations are non-authoritative because a
			junction might be created, deleted, or modified by an individual that
			does not have permission to modify the NSDB records.
	8. IANA Considerations		8. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4		[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
	Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work		Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work
	skipping to change at page 29, line 45		skipping to change at page 29, line 45
	(LDAP): Technical Specification Road Map", RFC 4510,		(LDAP): Technical Specification Road Map", RFC 4510,
	June 2006.		June 2006.
	[RFC4513] Harrison, R., "Lightweight Directory Access Protocol		[RFC4513] Harrison, R., "Lightweight Directory Access Protocol
	(LDAP): Authentication Methods and Security Mechanisms",		(LDAP): Authentication Methods and Security Mechanisms",
	RFC 4513, June 2006.		RFC 4513, June 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
			[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, May 2008.
	9.2. Informational References		9.2. Informational References
	[RFC1094] Nowicki, B., "NFS: Network File System Protocol		[RFC1094] Nowicki, B., "NFS: Network File System Protocol
	specification", RFC 1094, March 1989.		specification", RFC 1094, March 1989.
	[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS		[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
	Version 3 Protocol Specification", RFC 1813, June 1995.		Version 3 Protocol Specification", RFC 1813, June 1995.
			[TA-FORMAT]
			Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
			Format", draft-ietf-pkix-ta-format-03 (work in progress),
			May 2009.
			[TA-MGMT-REQS]
			Reddy, R. and C. Wallace, "Trust Anchor Management
			Requirements", draft-ietf-pkix-ta-mgmt-reqs-04 (work in
			progress), September 2009.
			[TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
			Management Protocol (TAMP)", draft-ietf-pkix-tamp-03 (work
			in progress), October 2009.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	We would like to thank Robert Thurlow of Sun Microsystems for helping		We would like to thank Robert Thurlow of Sun Microsystems for helping
	to author this document.		to author this document.
			We would also like to thank Peter McCann and and Nicolas Williams for
			their comments and suggestions.
	Authors' Addresses		Authors' Addresses
	James Lentini		James Lentini
	NetApp		NetApp
	1601 Trapelo Rd, Suite 16		1601 Trapelo Rd, Suite 16
	Waltham, MA 02451		Waltham, MA 02451
	US		US
	Phone: +1 781-768-5359		Phone: +1 781-768-5359
	Email: jlentini@netapp.com		Email: jlentini@netapp.com
End of changes. 12 change blocks.
	9 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/