draft-ietf-nfsv4-rfc1831bis-10.txt   draft-ietf-nfsv4-rfc1831bis-11.txt 
Network File System Version 4 Working Group R. Thurlow Network File System Version 4 Working Group R. Thurlow
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Intended status: Draft Standard Intended status: Draft Standard
Obsoletes: 1831 Obsoletes: 1831
Expires: April 30, 2009 October 30, 2008 Expires: July 28, 2009 January 30, 2009
RPC: Remote Procedure Call Protocol Specification Version 2 RPC: Remote Procedure Call Protocol Specification Version 2
draft-ietf-nfsv4-rfc1831bis-10.txt draft-ietf-nfsv4-rfc1831bis-11.txt
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 the
applicable patent or other IPR claims of which he or she is aware 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 months Internet-Drafts are draft documents valid for a maximum of six months
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Discussion and suggestions for improvement are requested. This This document will expire in July, 2009.
document will expire in April, 2009. Distribution of this draft is
unlimited. Copyright Notice
Copyright (c) 2009 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.
Abstract Abstract
This document describes the ONC (Open Network Computing) Remote This document describes the ONC (Open Network Computing) Remote
Procedure Call (ONC RPC Version 2) protocol as it is currently Procedure Call (ONC RPC Version 2) protocol as it is currently
deployed and accepted. This document obsoletes [RFC1831]. deployed and accepted. This document obsoletes [RFC1831].
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 2, line 41 skipping to change at page 3, line 41
13.2. Protecting Past Assignments . . . . . . . . . . . . . . . 1 13.2. Protecting Past Assignments . . . . . . . . . . . . . . . 1
13.3. RPC Number Assignment . . . . . . . . . . . . . . . . . . 1 13.3. RPC Number Assignment . . . . . . . . . . . . . . . . . . 1
13.3.1. To be assigned by IANA . . . . . . . . . . . . . . . . 1 13.3.1. To be assigned by IANA . . . . . . . . . . . . . . . . 1
13.3.2. Defined by local administrator . . . . . . . . . . . . 1 13.3.2. Defined by local administrator . . . . . . . . . . . . 1
13.3.3. Transient block . . . . . . . . . . . . . . . . . . . . 1 13.3.3. Transient block . . . . . . . . . . . . . . . . . . . . 1
13.3.4. Reserved block . . . . . . . . . . . . . . . . . . . . 1 13.3.4. Reserved block . . . . . . . . . . . . . . . . . . . . 1
13.3.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 1 13.3.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 1
13.4. RPC Authentication Flavor Number Assignment . . . . . . . 1 13.4. RPC Authentication Flavor Number Assignment . . . . . . . 1
13.4.1. Assignment Policy . . . . . . . . . . . . . . . . . . . 1 13.4.1. Assignment Policy . . . . . . . . . . . . . . . . . . . 1
13.4.2. Auth Flavors vs. Pseudo-flavors . . . . . . . . . . . . 1 13.4.2. Auth Flavors vs. Pseudo-flavors . . . . . . . . . . . . 1
13.5. Authentication Status Number Assignment . . . . . . . . . 1
13.5.1. Assignment Policy . . . . . . . . . . . . . . . . . . . 1
14. Security Considerations . . . . . . . . . . . . . . . . . . 1 14. Security Considerations . . . . . . . . . . . . . . . . . . 1
15. Appendix A: System Authentication . . . . . . . . . . . . . 1 15. Appendix A: System Authentication . . . . . . . . . . . . . 1
16. Appendix B: Requesting RPC program or authentication 16. Appendix B: Requesting RPC-related numbers from IANA . . . 1
numbers . . . . . . . . . . . . . . . . . . . . . . . . . . 1 17. Normative References . . . . . . . . . . . . . . . . . . . 1
17. Full Copyright Statement . . . . . . . . . . . . . . . . . 1 18. Informative References . . . . . . . . . . . . . . . . . . 1
18. Intellectual property . . . . . . . . . . . . . . . . . . . 1 19. Author's Address . . . . . . . . . . . . . . . . . . . . . 1
19. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . 1
20. Normative References . . . . . . . . . . . . . . . . . . . 1
21. Informative References . . . . . . . . . . . . . . . . . . 1
22. Author's Address . . . . . . . . . . . . . . . . . . . . . 1
1. Introduction 1. Introduction
This document specifies version two of the message protocol used in This document specifies version two of the message protocol used in
ONC Remote Procedure Call (RPC). The message protocol is specified ONC Remote Procedure Call (RPC). The message protocol is specified
with the eXternal Data Representation (XDR) language [RFC4506]. This with the eXternal Data Representation (XDR) language [RFC4506]. This
document assumes that the reader is familiar with XDR. It does not document assumes that the reader is familiar with XDR. It does not
attempt to justify remote procedure calls systems or describe their attempt to justify remote procedure calls systems or describe their
use. The paper by Birrell and Nelson [XRPC] is recommended as an use. The paper by Birrell and Nelson [XRPC] is recommended as an
excellent background for the remote procedure call concept. excellent background for the remote procedure call concept.
2. Changes since RFC 1831 2. Changes since RFC 1831
This document obsoletes RFC 1831 as the authoritative document This document obsoletes RFC 1831 as the authoritative document
describing RPC, without introducing any over-the-wire protocol describing RPC, without introducing any over-the-wire protocol
changes. The main changes from RFC 1831 are: changes. The main changes from RFC 1831 are:
o Addition of an Appendix which describes how an implementor can o Addition of an Appendix which describes how an implementor can
request new RPC program numbers and authentication flavor request new RPC program numbers, authentication flavor numbers
numbers from IANA, rather than from Sun Microsystems and authentication status numbers from IANA, rather than from
Sun Microsystems
o Addition of an "IANA Considerations" section which describes o Addition of an "IANA Considerations" section which describes
past program and authentication flavor number assignment policy past number assignment policy and how IANA is intended to assign
and how IANA is intended to assign them in future them in the future
o Clarification of the RPC Language Specification to match current o Clarification of the RPC Language Specification to match current
usage usage
o Enhancement of the "Security Considerations" section to reflect o Enhancement of the "Security Considerations" section to reflect
experience with strong security flavors experience with strong security flavors
o Specification of new authentication errors that are in common o Specification of new authentication errors that are in common
use in modern RPC implementations use in modern RPC implementations
skipping to change at page 12, line 8 skipping to change at page 13, line 8
* AUTH_KERB errors; deprecated. See [RFC2695] * AUTH_KERB errors; deprecated. See [RFC2695]
*/ */
AUTH_KERB_GENERIC = 8, /* kerberos generic error */ AUTH_KERB_GENERIC = 8, /* kerberos generic error */
AUTH_TIMEEXPIRE = 9, /* time of credential expired */ AUTH_TIMEEXPIRE = 9, /* time of credential expired */
AUTH_TKT_FILE = 10, /* problem with ticket file */ AUTH_TKT_FILE = 10, /* problem with ticket file */
AUTH_DECODE = 11, /* can't decode authenticator */ AUTH_DECODE = 11, /* can't decode authenticator */
AUTH_NET_ADDR = 12, /* wrong net address in ticket */ AUTH_NET_ADDR = 12, /* wrong net address in ticket */
/* /*
* RPCSEC_GSS GSS related errors * RPCSEC_GSS GSS related errors
*/ */
RPCSEC_GSS_NOCRED = 13, /* no credentials for user */ RPCSEC_GSS_CREDPROBLEM = 13, /* no credentials for user */
RPCSEC_GSS_FAILED = 14 /* GSS failure, creds deleted */ RPCSEC_GSS_CTXPROBLEM = 14 /* problem with context */
}; };
As new authentication mechanisms are added, there may be a need for
more status codes to support them. IANA will hand out new auth_stat
numbers on a simple first-come, first-served basis as defined in the
"IANA Considerations" and Appendix B.
The RPC message: The RPC message:
All messages start with a transaction identifier, xid, followed by a All messages start with a transaction identifier, xid, followed by a
two-armed discriminated union. The union's discriminant is a two-armed discriminated union. The union's discriminant is a
msg_type which switches to one of the two types of the message. The msg_type which switches to one of the two types of the message. The
xid of a REPLY message always matches that of the initiating CALL xid of a REPLY message always matches that of the initiating CALL
message. NB: The xid field is only used for clients matching reply message. NB: The xid field is only used for clients matching reply
messages with call messages or for servers detecting retransmissions; messages with call messages or for servers detecting retransmissions;
the service side cannot treat this id as any type of sequence number. the service side cannot treat this id as any type of sequence number.
skipping to change at page 17, line 37 skipping to change at page 18, line 43
o Only unsigned constants can be assigned to programs, versions o Only unsigned constants can be assigned to programs, versions
and procedures. and procedures.
o Current RPC language compilers do not generally support more o Current RPC language compilers do not generally support more
than one type-specifier in procedure argument lists; the usual than one type-specifier in procedure argument lists; the usual
practice is to wrap arguments into a structure. practice is to wrap arguments into a structure.
13. IANA Considerations 13. IANA Considerations
The assignment of RPC program numbers and authentication flavor The assignment of RPC program numbers, authentication flavor numbers
numbers has in the past been performed by Sun Microsystems, Inc and authentication status numbers has in the past been performed by
(Sun). This is inappropriate for an IETF standards-track protocol, Sun Microsystems, Inc (Sun). This is inappropriate for an IETF
as such work is done well by the Internet Assigned Numbers Authority standards-track protocol, as such work is done well by the Internet
(IANA). This document proposes the transfer of authority over RPC Assigned Numbers Authority (IANA). This document proposes the
program numbers and authentication flavor numbers described here from transfer of authority over RPC program numbers, authentication flavor
Sun Microsystems, Inc. to IANA and proposes how IANA will maintain numbers and authentication status numbers described here from Sun
and assign RPC program numbers and authentication flavor numbers. Microsystems, Inc. to IANA and proposes how IANA will maintain and
Users of RPC protocols will benefit by having an independent body assign these numbers. Users of RPC protocols will benefit by having
responsible for RPC number assignments. an independent body responsible for these number assignments.
13.1. Numbering Requests to IANA 13.1. Numbering Requests to IANA
Appendix B of this document describes the information to be sent to Appendix B of this document describes the information to be sent to
IANA to request one or more RPC numbers and the rules that apply. IANA to request one or more RPC numbers and the rules that apply.
IANA should store the request for documentary purposes, and put the IANA should store the request for documentary purposes, and put the
following information into the public registry: following information into the public registry:
o The short description of purpose and use o The short description of purpose and use
skipping to change at page 18, line 25 skipping to change at page 19, line 29
o The short identifier string(s) o The short identifier string(s)
13.2. Protecting Past Assignments 13.2. Protecting Past Assignments
Sun has made assignments in both number spaces since the original Sun has made assignments in both number spaces since the original
deployment of RPC. The assignments made by Sun Microsystems are deployment of RPC. The assignments made by Sun Microsystems are
still valid, and will be preserved. Sun will communicate all current still valid, and will be preserved. Sun will communicate all current
assignments in both number spaces to IANA before final handoff of assignments in both number spaces to IANA before final handoff of
number assignment is done. At the time of submission of this draft, number assignment is done. At the time of submission of this draft,
current assignments were listed at: current program number assignments were listed at:
http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt
and current auth number assignments were listed at:
http://www.nfsv4-editor.org/auth-numbers-1831bis.txt
Current authentication status numbers are listed in Section 9 of this
document in the "enum auth_stat" definition.
13.3. RPC Number Assignment 13.3. RPC Number Assignment
Future IANA practice should deal with the following partitioning of Future IANA practice should deal with the following partitioning of
the 32-bit number space as listed in Section 8.3. Detailed the 32-bit number space as listed in Section 8.3. Detailed
information for the administration of the partitioned blocks in information for the administration of the partitioned blocks in
Section 8.3. is given below. Section 8.3. is given below.
13.3.1. To be assigned by IANA 13.3.1. To be assigned by IANA
The first block will be administered by IANA, with previous The first block will be administered by IANA, with previous
skipping to change at page 20, line 30 skipping to change at page 21, line 45
Up to 100 numbers First Come First Served IANA Up to 100 numbers First Come First Served IANA
Up to 1000 numbers Specification Required IANA Up to 1000 numbers Specification Required IANA
More than 1000 numbers IESG Approval required IESG More than 1000 numbers IESG Approval required IESG
Note: sub-blocks can be any size. The limits given above are Note: sub-blocks can be any size. The limits given above are
maximums and smaller size sub-blocks are allowed. maximums and smaller size sub-blocks are allowed.
Sub-blocks sized up to 100 numbers may be assigned by IANA on a First Sub-blocks sized up to 100 numbers may be assigned by IANA on a First
Come First Served basis. The RPC Service Description included in the Come First Served basis. The RPC Service Description included in the
range must include an indication of how the sub-block is managed. At range must include an indication of how the sub-block is managed. At
minimum, the statement should indicate whether the sub-block is used a minimum, the statement should indicate whether the sub-block is
with a single RPC protocol or multiple RPC protocols, and whether the used with a single RPC protocol or multiple RPC protocols, and
numbers are dynamically assigned or statically (through whether the numbers are dynamically assigned or statically (through
administrative action) assigned. administrative action) assigned.
Sub-blocks of up to 1000 numbers must be documented in detail. The Sub-blocks of up to 1000 numbers must be documented in detail. The
documentation must describe the RPC protocol or protocols that are to documentation must describe the RPC protocol or protocols that are to
be used in the range. It must also describe how the numbers within be used in the range. It must also describe how the numbers within
the sub-block are to be assigned or used. the sub-block are to be assigned or used.
Sub-blocks sized over 1000 numbers must be documented as described Sub-blocks sized over 1000 numbers must be documented as described
above, and the assignment must be approved by the IESG. It is above, and the assignment must be approved by the IESG. It is
expected that this will be rare. expected that this will be rare.
skipping to change at page 22, line 11 skipping to change at page 23, line 28
For non-pseudo-flavor requests, IANA should begin granting RPC For non-pseudo-flavor requests, IANA should begin granting RPC
authentication flavor numbers at 400000 on a First Come First Served authentication flavor numbers at 400000 on a First Come First Served
basis to avoid conflicts with currently granted numbers. basis to avoid conflicts with currently granted numbers.
For authentication flavors or RPCSEC_GSS mechanisms to be used on the For authentication flavors or RPCSEC_GSS mechanisms to be used on the
Internet, it is strongly advised that an informational or standards- Internet, it is strongly advised that an informational or standards-
track RFC be published describing the authentication mechanism track RFC be published describing the authentication mechanism
behaviour and parameters. behaviour and parameters.
13.5. Authentication Status Number Assignment
The final number space is the authentication status or "auth_stat"
values which describe the nature of a problem found during an attempt
to authenicate or validate authentication. The complete initial list
of these values is found in Section 9 of this document, in the
"auth_stat" enum listing. It is expected that it will be rare to add
values, but that a small number of new values may be added from time
to time as new authentication flavors introduce new possibilities.
Numbers should be granted on a First Come First Served basis to avoid
conflicts with currently granted numbers.
13.5.1. Assignment Policy
Appendix B of this document describes the information to be sent to
IANA to request one or more auth_stat values and the rules that
apply. IANA should store the request for documentary purposes, and
put the following information into the public registry:
o The short identifier string(s)
o The auth_stat number(s) assigned
o The short description of purpose and use
14. Security Considerations 14. Security Considerations
AUTH_SYS as described in Appendix A is known to be insecure due to AUTH_SYS as described in Appendix A is known to be insecure due to
the lack of a verifier to permit the credential to be validated. the lack of a verifier to permit the credential to be validated.
AUTH_SYS SHOULD NOT be used for services which permit clients to AUTH_SYS SHOULD NOT be used for services which permit clients to
modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or
REQUIRED for any standards-track RPC service. REQUIRED for any standards-track RPC service.
AUTH_DH as mentioned in sections 8.2 and 13.4.2 is considered
obsolete and insecure; see [RFC2695]. AUTH_SYS SHOULD NOT be used
for services which permit clients to modify data. AUTH_DH MUST NOT
be specified as RECOMMENDED or REQUIRED for any standards-track RPC
service.
[RFC2203] defines a new security flavor, RPCSEC_GSS, which permits [RFC2203] defines a new security flavor, RPCSEC_GSS, which permits
GSS-API [RFC2743] mechanisms to be used for securing RPC. All non- GSS-API [RFC2743] mechanisms to be used for securing RPC. All non-
trivial RPC programs developed in future should implement trivial RPC programs developed in the future should implement
RPCSEC_GSS-based security appropriately. [RFC2623] describes how RPCSEC_GSS-based security appropriately. [RFC2623] describes how
this was done for a widely deployed RPC program. this was done for a widely deployed RPC program.
Standards-track RPC services MUST mandate support for RPCSEC_GSS, and
MUST mandate support for an authentication pseudo-flavor with
appropriate levels of security, depending on the need for simple
authentication, integrity a.k.a. non-repudiation, or data privacy.
15. Appendix A: System Authentication 15. Appendix A: System Authentication
The client may wish to identify itself, for example, as it is The client may wish to identify itself, for example, as it is
identified on a UNIX(tm) system. The flavor of the client credential identified on a UNIX(tm) system. The flavor of the client credential
is "AUTH_SYS". The opaque data constituting the credential encodes is "AUTH_SYS". The opaque data constituting the credential encodes
the following structure: the following structure:
struct authsys_parms { struct authsys_parms {
unsigned int stamp; unsigned int stamp;
string machinename<255>; string machinename<255>;
skipping to change at page 23, line 28 skipping to change at page 25, line 31
It should be noted that use of this flavor of authentication does not It should be noted that use of this flavor of authentication does not
guarantee any security for the users or providers of a service, in guarantee any security for the users or providers of a service, in
itself. The authentication provided by this scheme can be considered itself. The authentication provided by this scheme can be considered
legitimate only when applications using this scheme and the network legitimate only when applications using this scheme and the network
can be secured externally, and privileged transport addresses are can be secured externally, and privileged transport addresses are
used for the communicating end-points (an example of this is the use used for the communicating end-points (an example of this is the use
of privileged TCP/UDP ports in Unix systems - note that not all of privileged TCP/UDP ports in Unix systems - note that not all
systems enforce privileged transport address mechanisms). systems enforce privileged transport address mechanisms).
16. Appendix B: Requesting RPC program or authentication numbers 16. Appendix B: Requesting RPC-related numbers from IANA
RPC numbers which must be unique across all networks are assigned by RPC program numbers, authentication flavor numbers and authentication
the Internet Assigned Number Authority. To apply for a single number status numbers which must be unique across all networks are assigned
or a block of numbers, electronic mail must be sent to IANA by the Internet Assigned Number Authority. To apply for a single
<iana@isi.edu> with the following information: number or a block of numbers, electronic mail must be sent to IANA
<iana@iana.org> with the following information:
o The type of number(s) (program number or authentication flavor o The type of number(s) (program number or authentication flavor
number) sought number or authentication status number) sought
o How many numbers are sought o How many numbers are sought
o The name of person or company which will use the number o The name of person or company which will use the number
o An "identifier string" which associates the number with a o An "identifier string" which associates the number with a
service service
o Email address of the contact person for the service which will o Email address of the contact person for the service which will
be using the number. be using the number.
skipping to change at page 24, line 10 skipping to change at page 26, line 15
o A short description of the purpose and use of the number o A short description of the purpose and use of the number
o If an authentication flavor number is sought, and the number o If an authentication flavor number is sought, and the number
will be a 'pseudo-flavor' intended for use with RPCSEC_GSS and will be a 'pseudo-flavor' intended for use with RPCSEC_GSS and
NFS, mappings analogous to those in Section 4.2 of [RFC2623] are NFS, mappings analogous to those in Section 4.2 of [RFC2623] are
required. required.
Specific numbers cannot be requested. Numbers are assigned on a Specific numbers cannot be requested. Numbers are assigned on a
First Come First Served basis. First Come First Served basis.
For all RPC authentication flavor numbers to used on the Internet, it For all RPC authentication flavor and authentication status numbers
is strongly advised that an informational or standards-track RFC be to be used on the Internet, it is strongly advised that an
published describing the authentication mechanism behaviour and informational or standards-track RFC be published describing the
parameters. authentication mechanism behaviour and parameters.
17. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
18. Intellectual property
The IETF 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
this 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. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR 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.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
19. Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
20. Normative References 17. Normative References
[RFC4506] [RFC4506]
Eisler, M., "XDR: External Data Representation Standard", RFC 4506, Eisler, M., "XDR: External Data Representation Standard", RFC 4506,
[RFC2203]
Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification",
RFC 2203, September 1997
21. Informative References 18. Informative References
[XRPC] [XRPC]
Birrell, A. D. & Nelson, B. J., "Implementing Remote Procedure Birrell, A. D. & Nelson, B. J., "Implementing Remote Procedure
Calls", XEROX CSL-83-7, October 1983. Calls", XEROX CSL-83-7, October 1983.
[VMTP] [VMTP]
Cheriton, D., "VMTP: Versatile Message Transaction Protocol", Cheriton, D., "VMTP: Versatile Message Transaction Protocol",
Preliminary Version 0.3, Stanford University, January 1987. Preliminary Version 0.3, Stanford University, January 1987.
[DH] [DH]
skipping to change at page 27, line 13 skipping to change at page 28, line 17
[RFC1831] [RFC1831]
R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 1831, August 1995. Version 2", RFC 1831, August 1995.
[RFC1833] [RFC1833]
R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833, R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833,
August 1995. August 1995.
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
[RFC2203]
Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification",
RFC 2203, September 1997
[RFC2623] [RFC2623]
Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS
Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999. Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[RFC2695] [RFC2695]
Chiu, A., "Authentication Mechanisms for ONC RPC", RFC 2695, Chiu, A., "Authentication Mechanisms for ONC RPC", RFC 2695,
September 1999. September 1999.
[RFC2743] [RFC2743]
Linn. J., "Generic Security Service Application Program Interface Linn. J., "Generic Security Service Application Program Interface
skipping to change at page 28, line 5 skipping to change at page 29, line 5
[RFC3530] [RFC3530]
Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C.,
Eisler, M., Noveck, D., "Network File System (NFS) version 4 Eisler, M., Noveck, D., "Network File System (NFS) version 4
Protocol", RFC 3530, April 2003. Protocol", RFC 3530, April 2003.
[RFC5226] [RFC5226]
Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008. Considerations Section in RFCs", RFC 5226, May 2008.
22. Author's Address 19. Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
nfsv4@ietf.org nfsv4@ietf.org
Robert Thurlow Robert Thurlow
Sun Microsystems, Inc. Sun Microsystems, Inc.
500 Eldorado Boulevard, UBRM05-171 500 Eldorado Boulevard, UBRM05-171
Broomfield, CO 80021 Broomfield, CO 80021
 End of changes. 27 change blocks. 
100 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/