< draft-ietf-nfsv4-rpcrdma-08.txt		draft-ietf-nfsv4-rpcrdma-09.txt >
	NFSv4 Working Group Tom Talpey		NFSv4 Working Group Tom Talpey
	Internet-Draft NetApp		Internet-Draft NetApp
	Intended status: Standards Track Brent Callaghan		Intended status: Standards Track Brent Callaghan
	Expires: October 17, 2008 Apple		Expires: June 3, 2009 Apple
	April 16, 2008		December 3, 2008
	Remote Direct Memory Access Transport for Remote Procedure Call		Remote Direct Memory Access Transport for Remote Procedure Call
	draft-ietf-nfsv4-rpcrdma-08		draft-ietf-nfsv4-rpcrdma-09
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with
	applicable patent or other IPR claims of which he or she is aware		the provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		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.
	Copyright Notice		This Internet-Draft will expire on June 3, 2009.
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	A protocol is described providing Remote Direct Memory Access		A protocol is described providing Remote Direct Memory Access
	(RDMA) as a new transport for Remote Procedure Call (RPC). The		(RDMA) as a new transport for Remote Procedure Call (RPC). The
	RDMA transport binding conveys the benefits of efficient, bulk data		RDMA transport binding conveys the benefits of efficient, bulk data
	transport over high speed networks, while providing for minimal		transport over high speed networks, while providing for minimal
	change to RPC applications and with no required revision of the		change to RPC applications and with no required revision of the
	application RPC protocol, or the RPC protocol itself.		application RPC protocol, or the RPC protocol itself.
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	5.2. RDMA Write of Long Replies (Reply Chunks) . . . . . . . 24		5.2. RDMA Write of Long Replies (Reply Chunks) . . . . . . . 24
	6. Connection Configuration Protocol . . . . . . . . . . . . 25		6. Connection Configuration Protocol . . . . . . . . . . . . 25
	6.1. Initial Connection State . . . . . . . . . . . . . . . . 26		6.1. Initial Connection State . . . . . . . . . . . . . . . . 26
	6.2. Protocol Description . . . . . . . . . . . . . . . . . . 26		6.2. Protocol Description . . . . . . . . . . . . . . . . . . 26
	7. Memory Registration Overhead . . . . . . . . . . . . . . . 28		7. Memory Registration Overhead . . . . . . . . . . . . . . . 28
	8. Errors and Error Recovery . . . . . . . . . . . . . . . . 28		8. Errors and Error Recovery . . . . . . . . . . . . . . . . 28
	9. Node Addressing . . . . . . . . . . . . . . . . . . . . . 28		9. Node Addressing . . . . . . . . . . . . . . . . . . . . . 28
	10. RPC Binding . . . . . . . . . . . . . . . . . . . . . . . 29		10. RPC Binding . . . . . . . . . . . . . . . . . . . . . . . 29
	11. Security Considerations . . . . . . . . . . . . . . . . . 30		11. Security Considerations . . . . . . . . . . . . . . . . . 30
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . 31		12. IANA Considerations . . . . . . . . . . . . . . . . . . . 31
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 32		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 33
	14. Normative References . . . . . . . . . . . . . . . . . . 32		14. Normative References . . . . . . . . . . . . . . . . . . 33
	15. Informative References . . . . . . . . . . . . . . . . . 33		15. Informative References . . . . . . . . . . . . . . . . . 34
	16. Authors' Addresses . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
	17. Intellectual Property and Copyright Statements . . . . . 35		Intellectual Property Statement . . . . . . . . . . . . . . . 35
	Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 36		Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 36
			Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in [RFC2119].		this document are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	Remote Direct Memory Access (RDMA) [RFC5040, RFC5041] [IB] is a		Remote Direct Memory Access (RDMA) [RFC5040, RFC5041] [IB] is a
	skipping to change at page 19, line 23 ¶		skipping to change at page 19, line 23 ¶
	ignore the XID in the RPC header, if it so chooses.		ignore the XID in the RPC header, if it so chooses.
	2. Version number.		2. Version number.
	This version of the RPC RDMA message protocol is 1. The		This version of the RPC RDMA message protocol is 1. The
	version number MUST be increased by one whenever the format of		version number MUST be increased by one whenever the format of
	the RPC RDMA messages is changed.		the RPC RDMA messages is changed.
	3. Flow control credit value.		3. Flow control credit value.
	When sent in an RPC call message, the requested value is		When sent in an RPC call message, the requested value is
	provided. When sent in an RPC reply message, the granted		provided. When sent in an RPC reply message, the granted
	value is returned. RPC calls SHOULD not be sent in excess of		value is returned. RPC calls SHOULD NOT be sent in excess of
	the currently granted limit.		the currently granted limit.
	4. Message type.		4. Message type.
	o RDMA_MSG = 0 indicates that chunk lists and RPC message		o RDMA_MSG = 0 indicates that chunk lists and RPC message
	follow.		follow.
	o RDMA_NOMSG = 1 indicates that after the chunk lists there		o RDMA_NOMSG = 1 indicates that after the chunk lists there
	is no RPC message. In this case, the chunk lists provide		is no RPC message. In this case, the chunk lists provide
	information to allow the message proper to be transferred		information to allow the message proper to be transferred
	skipping to change at page 28, line 50 ¶		skipping to change at page 28, line 50 ¶
	/* max active RDMA Reads at server */		/* max active RDMA Reads at server */
	};		};
	program CONFIG_RDMA_PROG {		program CONFIG_RDMA_PROG {
	version VERS1 {		version VERS1 {
	/*		/*
	* Config call/reply		* Config call/reply
	*/		*/
	config_rdma_reply CONF_RDMA(config_rdma_req) = 1;		config_rdma_reply CONF_RDMA(config_rdma_req) = 1;
	} = 1;		} = 1;
	} = 100400;		} = 100417;
	7. Memory Registration Overhead		7. Memory Registration Overhead
	RDMA requires that all data be transferred between registered		RDMA requires that all data be transferred between registered
	memory regions at the source and destination. All protocol headers		memory regions at the source and destination. All protocol headers
	as well as separately transferred data chunks use registered		as well as separately transferred data chunks use registered
	memory. Since the cost of registering and de-registering memory		memory. Since the cost of registering and de-registering memory
	can be a large proportion of the RDMA transaction cost, it is		can be a large proportion of the RDMA transaction cost, it is
	important to minimize registration activity. This is easily		important to minimize registration activity. This is easily
	achieved within RPC controlled memory by allocating chunk list data		achieved within RPC controlled memory by allocating chunk list data
	skipping to change at page 30, line 18 ¶		skipping to change at page 30, line 18 ¶
	service, which associates an RPC program number with a service		service, which associates an RPC program number with a service
	address. (In the case of UDP or TCP, the service address for NFS		address. (In the case of UDP or TCP, the service address for NFS
	is normally port 2049.) This policy is no different with RDMA		is normally port 2049.) This policy is no different with RDMA
	interconnects, although it may require the allocation of port		interconnects, although it may require the allocation of port
	numbers appropriate to each upper layer binding which uses the RPC		numbers appropriate to each upper layer binding which uses the RPC
	framing defined here.		framing defined here.
	When mapped atop the iWARP [RFC5040, RFC5041] transport, which uses		When mapped atop the iWARP [RFC5040, RFC5041] transport, which uses
	IP port addressing due to its layering on TCP and/or SCTP, port		IP port addressing due to its layering on TCP and/or SCTP, port
	mapping is trivial and consists merely of issuing the port in the		mapping is trivial and consists merely of issuing the port in the
	connection process.		connection process. The NFS/RDMA protocol service address has been
			assigned port 20049 by IANA, for both iWARP/TCP and iWARP/SCTP.
	When mapped atop Infiniband [IB], which uses a GID-based service		When mapped atop Infiniband [IB], which uses a GID-based service
	endpoint naming scheme, a translation MUST be employed. One such		endpoint naming scheme, a translation MUST be employed. One such
	translation is defined in the Infiniband Port Addressing Annex		translation is defined in the Infiniband Port Addressing Annex
	[IBPORT], which is appropriate for translating IP port addressing		[IBPORT], which is appropriate for translating IP port addressing
	to the Infiniband network. Therefore, in this case, IP port		to the Infiniband network. Therefore, in this case, IP port
	addressing may be readily employed by the upper layer.		addressing may be readily employed by the upper layer.
	When a mapping standard or convention exists for IP ports on an		When a mapping standard or convention exists for IP ports on an
	RDMA interconnect, there are several possibilities for each upper		RDMA interconnect, there are several possibilities for each upper
	skipping to change at page 30, line 49 ¶		skipping to change at page 30, line 50 ¶
	A second possibility is to have the server's portmapper		A second possibility is to have the server's portmapper
	register itself on the RDMA interconnect at a "well known"		register itself on the RDMA interconnect at a "well known"
	service address. (On UDP or TCP, this corresponds to port		service address. (On UDP or TCP, this corresponds to port
	111.) A client could connect to this service address and use		111.) A client could connect to this service address and use
	the portmap protocol to obtain a service address in response		the portmap protocol to obtain a service address in response
	to a program number, e.g., an iWARP port number, or an		to a program number, e.g., an iWARP port number, or an
	Infiniband GID.		Infiniband GID.
	Alternatively, the client could simply connect to the mapped		Alternatively, the client could simply connect to the mapped
	well-known port for the service itself, if it is appropriately		well-known port for the service itself, if it is appropriately
	defined.		defined. By convention, the NFS/RDMA service, when operating
			atop such an Infiniband fabric, will use the same 20049
			assignment as for iWARP.
	Historically, different RPC protocols have taken different		Historically, different RPC protocols have taken different
	approaches to their port assignment, therefore the specific method		approaches to their port assignment, therefore the specific method
	is left to each RPC/RDMA-enabled upper layer binding, and not		is left to each RPC/RDMA-enabled upper layer binding, and not
	addressed here.		addressed here.
	This specification defines a new "netid", to be used for		This specification defines two new "netid" values, to be used for
	registration of upper layers atop iWARP [RFC5040, RFC5041] and		registration of upper layers atop iWARP [RFC5040, RFC5041] and
	(when a suitable port translation service is available) Infiniband		(when a suitable port translation service is available) Infiniband
	[IB] in section 12, "IANA Considerations." Additional RDMA-capable		[IB] in section 12, "IANA Considerations." Additional RDMA-capable
	networks MAY define their own netids, or if they provide a port		networks MAY define their own netids, or if they provide a port
	translation, MAY share the one defined here.		translation, MAY share the one defined here.
	11. Security Considerations		11. Security Considerations
	RPC provides its own security via the RPCSEC_GSS framework		RPC provides its own security via the RPCSEC_GSS framework
	[RFC2203]. RPCSEC_GSS can provide message authentication,		[RFC2203]. RPCSEC_GSS can provide message authentication,
	skipping to change at page 32, line 44 ¶		skipping to change at page 32, line 45 ¶
	message in order to provide the next credit. The time-based window		message in order to provide the next credit. The time-based window
	(or any other appropriate method) SHOULD be used by the server to		(or any other appropriate method) SHOULD be used by the server to
	recover resources in the event that the client never returns.		recover resources in the event that the client never returns.
	The "Connection Configuration Protocol", when used, MUST be		The "Connection Configuration Protocol", when used, MUST be
	protected by an appropriate RPC security flavor, to ensure it is		protected by an appropriate RPC security flavor, to ensure it is
	not attacked in the process of initiating an RPC/RDMA connection.		not attacked in the process of initiating an RPC/RDMA connection.
	12. IANA Considerations		12. IANA Considerations
	The new RPC transport is to be assigned a new RPC "netid", which is		Three new assignments are specified by this document:
	an rpcbind [RFC1833] string used to describe the underlying
	protocol in order for RPC to select the appropriate transport
	framing, as well as the format of the service ports.
	The following "nc_proto" registry string is hereby defined for this		- A new set of RPC "netids" for resolving RPC/RDMA services
			- Optional service port assignments for upper layer bindings
			- An RPC program number assignment for the configuration protocol
			These assignments have been established, as below.
			The new RPC transport has been assigned an RPC "netid", which is an
			rpcbind [RFC1833] string used to describe the underlying protocol
			in order for RPC to select the appropriate transport framing, as
			well as the format of the service addresses and ports.
			The following "nc_proto" registry strings are defined for this
	purpose:		purpose:
	NC_RDMA "rdma"		NC_RDMA "rdma"
			NC_RDMA6 "rdma6"
	This netid MAY be used for any RDMA network satisfying the		These netids MAY be used for any RDMA network satisfying the
	requirements of section 2, and able to identify service endpoints		requirements of section 2, and able to identify service endpoints
	using IP port addressing, possibly through use of a translation		using IP port addressing, possibly through use of a translation
	service as described above in section 10, RPC Binding.		service as described above in section 10, RPC Binding. The "rdma"
			netid is to be used when IPv4 addressing is employed by the
			underlying transport, and "rdma6" for IPv6 addressing.
			The netid assignment policy and registry are defined in [IANA-
			NETID].
	As a new RPC transport, this protocol has no effect on RPC program		As a new RPC transport, this protocol has no effect on RPC program
	numbers or existing registered port numbers. However, new port		numbers or existing registered port numbers. However, new port
	numbers MAY be registered for use by RPC/RDMA-enabled services, as		numbers MAY be registered for use by RPC/RDMA-enabled services, as
	appropriate to the new networks over which the services will		appropriate to the new networks over which the services will
	operate.		operate.
			For example, the NFS/RDMA service defined in [NFSDDP] has been
			assigned the port 20049, in the IANA registry:
			nfsrdma 20049/tcp Network File System (NFS) over RDMA
			nfsrdma 20049/udp Network File System (NFS) over RDMA
			nfsrdma 20049/sctp Network File System (NFS) over RDMA
	The OPTIONAL Connection Configuration protocol described herein		The OPTIONAL Connection Configuration protocol described herein
	requires an RPC program number assignment. The value "100400" is		requires an RPC program number assignment. The value "100417" has
	hereby assigned:		been assigned:
	rdmaconfig 100400 rpc.rdmaconfig		rdmaconfig 100417 rpc.rdmaconfig
	Currently, neither the nc_proto netid's nor the RPC program numbers		The RPC program number assignment policy and registry are defined
	are are assigned by IANA. The list in [RFC1833] has served as the		in [RFC1831bis].
	netid registry, and the republication declared in [IANA-RPC] has
	served as the program number registry. Ideally, IANA will create
	explicit registries for these objects. However, in the absence of
	new registries, this document would serve as the repository for the
	RPC program number assignment, and the protocol netid.
	13. Acknowledgments		13. Acknowledgments
	The authors wish to thank Rob Thurlow, John Howard, Chet Juszczak,		The authors wish to thank Rob Thurlow, John Howard, Chet Juszczak,
	Alex Chiu, Peter Staubach, Dave Noveck, Brian Pawlowski, Steve		Alex Chiu, Peter Staubach, Dave Noveck, Brian Pawlowski, Steve
	Kleiman, Mike Eisler, Mark Wittle, Shantanu Mehendale, David		Kleiman, Mike Eisler, Mark Wittle, Shantanu Mehendale, David
	Robinson and Mallikarjun Chadalapaka for their contributions to		Robinson and Mallikarjun Chadalapaka for their contributions to
	this document.		this document.
	14. Normative References		14. Normative References
	[RFC2119]		[RFC2119]
	S. Bradner, "Key words for use in RFCs to Indicate Requirement		S. Bradner, "Key words for use in RFCs to Indicate Requirement
	Levels", Best Current Practice, BCP 14, RFC 2119, March 1997.		Levels", Best Current Practice, BCP 14, RFC 2119, March 1997.
	[RFC1094]
	Sun Microsystems, "NFS: Network File System Protocol
	Specification", (NFS version 2) Informational RFC,
	http://www.ietf.org/rfc/rfc1094.txt
	[RFC1831bis]		[RFC1831bis]
	R. Thurlow, Ed., "RPC: Remote Procedure Call Protocol		R. Thurlow, Ed., "RPC: Remote Procedure Call Protocol
	Specification Version 2", Standards Track RFC		Specification Version 2", Internet Draft Work in Progress,
			draft-ietf-nfsv4-rfc1831bis
	[RFC4506]		[RFC4506]
	M. Eisler Ed., "XDR: External Data Representation Standard",		M. Eisler Ed., "XDR: External Data Representation Standard",
	Standards Track RFC, http://www.ietf.org/rfc/rfc4506.txt		Standards Track RFC, http://www.ietf.org/rfc/rfc4506.txt
	[RFC1813]
	B. Callaghan, B. Pawlowski, P. Staubach, "NFS Version 3
	Protocol Specification", Informational RFC,
	http://www.ietf.org/rfc/rfc1813.txt
	[RFC1833]		[RFC1833]
	R. Srinivasan, "Binding Protocols for ONC RPC Version 2",		R. Srinivasan, "Binding Protocols for ONC RPC Version 2",
	Standards Track RFC, http://www.ietf.org/rfc/rfc1833.txt		Standards Track RFC, http://www.ietf.org/rfc/rfc1833.txt
	[RFC3530]
	S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame,
	M. Eisler, D. Noveck, "NFS version 4 Protocol", Standards
	Track RFC, http://www.ietf.org/rfc/rfc3530.txt
	[RFC2203]		[RFC2203]
	M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol		M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol
	Specification", Standards Track RFC,		Specification", Standards Track RFC,
	http://www.ietf.org/rfc/rfc2203.txt		http://www.ietf.org/rfc/rfc2203.txt
	[RPCSECGSSV2]		[RPCSECGSSV2]
	M. Eisler, "RPCSEC_GSS Version 2", Internet Draft Work in		M. Eisler, "RPCSEC_GSS Version 2", Internet Draft Work in
	Progress draft-ietf-nfsv4-rpcsec-gss-v2		Progress, draft-ietf-nfsv4-rpcsec-gss-v2
	[RFC5056]		[RFC5056]
	N. Williams, "On the Use of Channel Bindings to Secure		N. Williams, "On the Use of Channel Bindings to Secure
	Channels", Standards Track RFC		Channels", Standards Track RFC
			http://www.ietf.org/rfc/rfc5056.txt
	[BTNSLATCH]		[BTNSLATCH]
	N. Williams, "IPsec Channels: Connection Latching", Internet		N. Williams, "IPsec Channels: Connection Latching", Internet
	Draft Work in Progress draft-ietf-btns-connection-latching		Draft Work in Progress, draft-ietf-btns-connection-latching
	[RFC5042]		[RFC5042]
	J. Pinkerton, E. Deleganes, "Direct Data Placement Protocol		J. Pinkerton, E. Deleganes, "Direct Data Placement Protocol
	(DDP) / Remote Direct Memory Access Protocol (RDMAP) Security"		(DDP) / Remote Direct Memory Access Protocol (RDMAP)
	Standards Track RFC		Security", Standards Track RFC,
			http://www.ietf.org/rfc/rfc5042.txt
			[IANA-NETID]
			M. Eisler, "IANA Considerations for RPC Net Identifiers and
			Universal Address Formats", Internet Draft Work in Progress,
			draft-ietf-nfsv4-rpc-netid
	15. Informative References		15. Informative References
			[RFC1094]
			Sun Microsystems, "NFS: Network File System Protocol
			Specification", (NFS version 2) Informational RFC,
			http://www.ietf.org/rfc/rfc1094.txt
			[RFC1813]
			B. Callaghan, B. Pawlowski, P. Staubach, "NFS Version 3
			Protocol Specification", Informational RFC,
			http://www.ietf.org/rfc/rfc1813.txt
			[RFC3530]
			S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame,
			M. Eisler, D. Noveck, "NFS version 4 Protocol", Standards
			Track RFC, http://www.ietf.org/rfc/rfc3530.txt
	[NFSDDP]		[NFSDDP]
	B. Callaghan, T. Talpey, "NFS Direct Data Placement" Internet		B. Callaghan, T. Talpey, "NFS Direct Data Placement", Internet
	Draft Work in Progress, draft-ietf-nfsv4-nfsdirect		Draft Work in Progress, draft-ietf-nfsv4-nfsdirect
	[RFC5040]		[RFC5040]
	R. Recio et al., "A Remote Direct Memory Access Protocol		R. Recio et al., "A Remote Direct Memory Access Protocol
	Specification", Standards Track RFC		Specification", Standards Track RFC,
			http://www.ietf.org/rfc/rfc5040.txt
	[RFC5041]		[RFC5041]
	H. Shah et al., "Direct Data Placement over Reliable		H. Shah et al., "Direct Data Placement over Reliable
	Transports", Standards Track RFC		Transports", Standards Track RFC,
			http://www.ietf.org/rfc/rfc5041.txt
	[NFSRDMAPS]		[NFSRDMAPS]
	T. Talpey, C. Juszczak, "NFS RDMA Problem Statement", Internet		T. Talpey, C. Juszczak, "NFS RDMA Problem Statement", Internet
	Draft Work in Progress, draft-ietf-nfsv4-nfs-rdma-problem-		Draft Work in Progress, draft-ietf-nfsv4-nfs-rdma-problem-
	statement		statement
	[NFSv4.1]		[NFSv4.1]
	S. Shepler et al., ed., "NFSv4 Minor Version 1" Internet Draft		S. Shepler et al., ed., "NFSv4 Minor Version 1", Internet
	Work in Progress, draft-ietf-nfsv4-minorversion1		Draft Work in Progress, draft-ietf-nfsv4-minorversion1
	[IB]		[IB]
	Infiniband Architecture Specification, available from		Infiniband Architecture Specification, available from
	http://www.infinibandta.org		http://www.infinibandta.org
	[IBPORT]		[IBPORT]
	Infiniband Trade Association, "IP Addressing Annex", available		Infiniband Trade Association, "IP Addressing Annex", available
	from http://www.infinibandta.org		from http://www.infinibandta.org
	[IANA-RPC]		Authors' Addresses
	IANA Sun RPC number statement,
	http://www.iana.org/assignments/sun-rpc-numbers
	16. Authors' Addresses
	Tom Talpey		Tom Talpey
	Network Appliance, Inc.		Network Appliance, Inc.
	1601 Trapelo Road, #16		1601 Trapelo Road, #16
	Waltham, MA 02451 USA		Waltham, MA 02451 USA
	Phone: +1 781 768 5329		Phone: +1 781 768 5329
	EMail: thomas.talpey@netapp.com		EMail: thomas.talpey@netapp.com
	Brent Callaghan		Brent Callaghan
	Apple Computer, Inc.		Apple Computer, Inc.
	MS: 302-4K		MS: 302-4K
	2 Infinite Loop		2 Infinite Loop
	Cupertino, CA 95014 USA		Cupertino, CA 95014 USA
	EMail: brentc@apple.com		EMail: brentc@apple.com
	17. Intellectual Property and Copyright Statements		Intellectual Property Statement
	Full Copyright Statement		The IETF Trust takes no position regarding the validity or scope of
			any Intellectual Property Rights or other rights that might be
			claimed to pertain to the implementation or use of the technology
			described in any IETF Document or the extent to which any license
			under such rights might or might not be available; nor does it
			represent that it has made any independent effort to identify any
			such rights.
	Copyright (C) The IETF Trust (2008).		Copies of Intellectual Property disclosures made to the IETF
			Secretariat and any assurances of licenses to be made available, or
			the result of an attempt made to obtain a general license or
			permission for the use of such proprietary rights by implementers
			or users of this specification can be obtained from the IETF on-
			line IPR repository at http://www.ietf.org/ipr
	This document is subject to the rights, licenses and restrictions		The IETF invites any interested party to bring to its attention any
	contained in BCP 78, and except as set forth therein, the authors		copyrights, patents or patent applications, or other proprietary
	retain all their rights.		rights that may cover technology that may be required to implement
			any standard or specification contained in an IETF Document. Please
			address the information to the IETF at ietf-ipr@ietf.org
	This document and the information contained herein are provided on		The definitive version of an IETF Document is that published by, or
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		under the auspices of, the IETF. Versions of IETF Documents that
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		are published by third parties, including those that are translated
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		into other languages, should not be considered to be definitive
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		versions of IETF Documents. The definitive version of these Legal
	WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE		Provisions is that published by, or under the auspices of, the
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS		IETF. Versions of these Legal Provisions that are published by
	FOR A PARTICULAR PURPOSE.		third parties, including those that are translated into other
			languages, should not be considered to be definitive versions of
			these Legal Provisions.
	Intellectual Property		For the avoidance of doubt, each Contributor to the IETF Standards
	The IETF takes no position regarding the validity or scope of any		Process licenses each Contribution that he or she makes as part of
	Intellectual Property Rights or other rights that might be claimed		the IETF Standards Process to the IETF Trust pursuant to the
	to pertain to the implementation or use of the technology described		provisions of RFC 5378. No language to the contrary, or terms,
	in this document or the extent to which any license under such		conditions or rights that differ from or are inconsistent with the
	rights might or might not be available; nor does it represent that		rights and licenses granted under RFC 5378, shall have any effect
	it has made any independent effort to identify any such rights.		and shall be null and void, whether published or posted by such
	Information on the procedures with respect to rights in RFC		Contributor, or included with or in such Contribution.
	documents can be found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Disclaimer of Validity
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		All IETF Documents and the information contained therein are
	copyrights, patents or patent applications, or other proprietary		provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
	rights that may cover technology that may be required to implement		HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
	this standard. Please address the information to the IETF at ietf-		SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
	ipr@ietf.org.		DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
			LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN
			WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Copyright Statement
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).		Copyright (c) 2008 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document.
End of changes. 46 change blocks.
	105 lines changed or deleted		141 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/