draft-ietf-nfsv4-minorversion1-23.txt   draft-ietf-nfsv4-minorversion1-24.txt 
NFSv4 S. Shepler NFSv4 S. Shepler
Internet-Draft M. Eisler Internet-Draft M. Eisler
Intended status: Standards Track D. Noveck Intended status: Standards Track D. Noveck
Expires: November 13, 2008 Editors Expires: February 7, 2009 Editors
May 12, 2008 Aug 06, 2008
NFS Version 4 Minor Version 1 NFS Version 4 Minor Version 1
draft-ietf-nfsv4-minorversion1-23.txt draft-ietf-nfsv4-minorversion1-24.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 November 13, 2008. This Internet-Draft will expire on February 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version one, This Internet-Draft describes NFS version 4 minor version one,
including features retained from the base protocol and protocol including features retained from the base protocol and protocol
extensions made subsequently. Major extensions introduced in NFS extensions made subsequently. Major extensions introduced in NFS
version 4 minor version one include: Sessions, Directory Delegations, version 4 minor version one include: Sessions, Directory Delegations,
and parallel NFS (pNFS). and parallel NFS (pNFS).
Requirements Language Requirements Language
skipping to change at page 80, line 41 skipping to change at page 80, line 41
| | Various defined file types. | | | Various defined file types. |
| nfsstat4 | enum nfsstat4; | | nfsstat4 | enum nfsstat4; |
| | Return value for operations. | | | Return value for operations. |
| offset4 | typedef uint64_t offset4; | | offset4 | typedef uint64_t offset4; |
| | Various offset designations (READ, WRITE, LOCK, | | | Various offset designations (READ, WRITE, LOCK, |
| | COMMIT). | | | COMMIT). |
| qop4 | typedef uint32_t qop4; | | qop4 | typedef uint32_t qop4; |
| | Quality of protection designation in SECINFO. | | | Quality of protection designation in SECINFO. |
| sec_oid4 | typedef opaque sec_oid4<>; | | sec_oid4 | typedef opaque sec_oid4<>; |
| | Security Object Identifier. The sec_oid4 data | | | Security Object Identifier. The sec_oid4 data |
| | type is not really opaque. Instead it contains an | | | type is not really opaque. Instead it contains |
| | ASN.1 OBJECT IDENTIFIER as used by GSS-API in the | | | an ASN.1 OBJECT IDENTIFIER as used by GSS-API in |
| | mech_type argument to GSS_Init_sec_context. See | | | the mech_type argument to GSS_Init_sec_context. |
| | [7] for details. | | | See [7] for details. |
| sequenceid4 | typedef uint32_t sequenceid4; | | sequenceid4 | typedef uint32_t sequenceid4; |
| | Sequence number used for various session | | | Sequence number used for various session |
| | operations (EXCHANGE_ID, CREATE_SESSION, | | | operations (EXCHANGE_ID, CREATE_SESSION, |
| | SEQUENCE, CB_SEQUENCE). | | | SEQUENCE, CB_SEQUENCE). |
| seqid4 | typedef uint32_t seqid4; | | seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for file locking. | | | Sequence identifier used for file locking. |
| sessionid4 | typedef opaque sessionid4[NFS4_SESSIONID_SIZE]; | | sessionid4 | typedef opaque sessionid4[NFS4_SESSIONID_SIZE]; |
| | Session identifier. | | | Session identifier. |
| slotid4 | typedef uint32_t slotid4; | | slotid4 | typedef uint32_t slotid4; |
| | Sequencing artifact for various session | | | Sequencing artifact for various session |
skipping to change at page 85, line 4 skipping to change at page 85, line 4
3.3.9.2. Format of netaddr4 for TCP and UDP over IPv6 3.3.9.2. Format of netaddr4 for TCP and UDP over IPv6
For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the
US-ASCII string: US-ASCII string:
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way The suffix "p1.p2" is the service port, and is computed the same way
as with universal addresses for TCP and UDP over IPv4. The prefix, as with universal addresses for TCP and UDP over IPv4. The prefix,
"x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for
representing an IPv6 address as defined in Section 2.2 of RFC3513 representing an IPv6 address as defined in Section 2.2 of RFC4291
[13]. Additionally, the two alternative forms specified in Section [13]. Additionally, the two alternative forms specified in Section
2.2 of RFC3513 are also acceptable. 2.2 of RFC4291 are also acceptable.
For TCP over IPv6 the value of r_netid is the string "tcp6". For UDP For TCP over IPv6 the value of r_netid is the string "tcp6". For UDP
over IPv6 the value of r_netid is the string "udp6". That this over IPv6 the value of r_netid is the string "udp6". That this
document specifies the universal address and netid for UDP/IPv6 does document specifies the universal address and netid for UDP/IPv6 does
not imply that UDP/IPv6 is a legal transport for NFSv4.1 (see not imply that UDP/IPv6 is a legal transport for NFSv4.1 (see
Section 2.9). Section 2.9).
3.3.10. state_owner4 3.3.10. state_owner4
struct state_owner4 { struct state_owner4 {
skipping to change at page 100, line 46 skipping to change at page 100, line 46
Some REQUIRED and RECOMMENDED attributes are set-only, i.e. they can Some REQUIRED and RECOMMENDED attributes are set-only, i.e. they can
be set via SETATTR but not retrieved via GETATTR. Similarly, some be set via SETATTR but not retrieved via GETATTR. Similarly, some
REQUIRED and RECOMMENDED attributes are get-only, i.e. they can be REQUIRED and RECOMMENDED attributes are get-only, i.e. they can be
retrieved GETATTR but not set via SETATTR. If a client attempts to retrieved GETATTR but not set via SETATTR. If a client attempts to
set a get-only attribute or get a set-only attributes, the server set a get-only attribute or get a set-only attributes, the server
MUST return NFS4ERR_INVAL. MUST return NFS4ERR_INVAL.
5.6. REQUIRED Attributes - List and Definition References 5.6. REQUIRED Attributes - List and Definition References
The list of REQUIRED attributes appears in Table 4. The meaning of The list of REQUIRED attributes appears in Table 2. The meaning of
the columns of the table are: the columns of the table are:
o Name: the name of attribute o Name: the name of attribute
o Id: the number assigned to the attribute. In the event of o Id: the number assigned to the attribute. In the event of
conflicts between the assigned number and [12], the latter is conflicts between the assigned number and [12], the latter is
authoritative. authoritative.
o Data Type: The XDR data type of the attribute. o Data Type: The XDR data type of the attribute.
skipping to change at page 101, line 35 skipping to change at page 101, line 35
| symlink_support | 6 | bool | R | Section 5.8.1.7 | | symlink_support | 6 | bool | R | Section 5.8.1.7 |
| named_attr | 7 | bool | R | Section 5.8.1.8 | | named_attr | 7 | bool | R | Section 5.8.1.8 |
| fsid | 8 | fsid4 | R | Section 5.8.1.9 | | fsid | 8 | fsid4 | R | Section 5.8.1.9 |
| unique_handles | 9 | bool | R | Section 5.8.1.10 | | unique_handles | 9 | bool | R | Section 5.8.1.10 |
| lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 | | lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 |
| rdattr_error | 11 | enum | R | Section 5.8.1.12 | | rdattr_error | 11 | enum | R | Section 5.8.1.12 |
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 | | filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 |
| suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 | | suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 |
+--------------------+----+------------+-----+------------------+ +--------------------+----+------------+-----+------------------+
Table 4 Table 2
5.7. RECOMMENDED Attributes - List and Definition References 5.7. RECOMMENDED Attributes - List and Definition References
The RECOMMENDED attributes are defined in Table 5. The meanings of The RECOMMENDED attributes are defined in Table 3. The meanings of
the column headers are the same as Table 4; see Section 5.6 for the the column headers are the same as Table 2; see Section 5.6 for the
meanings. meanings.
+--------------------+----+----------------+-----+------------------+ +--------------------+----+----------------+-----+------------------+
| Name | Id | Data Type | Acc | Defined in: | | Name | Id | Data Type | Acc | Defined in: |
+--------------------+----+----------------+-----+------------------+ +--------------------+----+----------------+-----+------------------+
| acl | 12 | nfsace4<> | R W | Section 6.2.1 | | acl | 12 | nfsace4<> | R W | Section 6.2.1 |
| aclsupport | 13 | uint32_t | R | Section 6.2.1.2 | | aclsupport | 13 | uint32_t | R | Section 6.2.1.2 |
| archive | 14 | bool | R W | Section 5.8.2.1 | | archive | 14 | bool | R W | Section 5.8.2.1 |
| cansettime | 15 | bool | R | Section 5.8.2.2 | | cansettime | 15 | bool | R | Section 5.8.2.2 |
| case_insensitive | 16 | bool | R | Section 5.8.2.3 | | case_insensitive | 16 | bool | R | Section 5.8.2.3 |
skipping to change at page 103, line 15 skipping to change at page 103, line 15
| time_access | 47 | nfstime4 | R | Section 5.8.2.37 | | time_access | 47 | nfstime4 | R | Section 5.8.2.37 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.38 | | time_access_set | 48 | settime4 | W | Section 5.8.2.38 |
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 | | time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.40 | | time_create | 50 | nfstime4 | R W | Section 5.8.2.40 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.41 | | time_delta | 51 | nfstime4 | R | Section 5.8.2.41 |
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 | | time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.43 | | time_modify | 53 | nfstime4 | R | Section 5.8.2.43 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.44 | | time_modify_set | 54 | settime4 | W | Section 5.8.2.44 |
+--------------------+----+----------------+-----+------------------+ +--------------------+----+----------------+-----+------------------+
Table 5 Table 3
* fs_locations_info4 * fs_locations_info4
5.8. Attribute Definitions 5.8. Attribute Definitions
5.8.1. Definitions of REQUIRED Attributes 5.8.1. Definitions of REQUIRED Attributes
5.8.1.1. Attribute 0: supported_attrs 5.8.1.1. Attribute 0: supported_attrs
The bit vector which would retrieve all REQUIRED and RECOMMENDED The bit vector which would retrieve all REQUIRED and RECOMMENDED
skipping to change at page 135, line 20 skipping to change at page 135, line 20
| EVERYONE | The world, including the owner and owning group. | | EVERYONE | The world, including the owner and owning group. |
| INTERACTIVE | Accessed from an interactive terminal. | | INTERACTIVE | Accessed from an interactive terminal. |
| NETWORK | Accessed via the network. | | NETWORK | Accessed via the network. |
| DIALUP | Accessed as a dialup user to the server. | | DIALUP | Accessed as a dialup user to the server. |
| BATCH | Accessed from a batch job. | | BATCH | Accessed from a batch job. |
| ANONYMOUS | Accessed without any authentication. | | ANONYMOUS | Accessed without any authentication. |
| AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS) | | AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS) |
| SERVICE | Access from a system service. | | SERVICE | Access from a system service. |
+---------------+--------------------------------------------------+ +---------------+--------------------------------------------------+
Table 7 Table 4
To avoid conflict, these special identifiers are distinguished by an To avoid conflict, these special identifiers are distinguished by an
appended "@" and should appear in the form "xxxx@" (with no domain appended "@" and should appear in the form "xxxx@" (with no domain
name after the "@"). For example: ANONYMOUS@. name after the "@"). For example: ANONYMOUS@.
The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these
special identifiers. When encoding entries with these special special identifiers. When encoding entries with these special
identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero. identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero.
6.2.1.5.1. Discussion of EVERYONE@ 6.2.1.5.1. Discussion of EVERYONE@
skipping to change at page 154, line 40 skipping to change at page 154, line 40
o When "other" is zero and "seqid" is one, the stateid represents o When "other" is zero and "seqid" is one, the stateid represents
the current stateid, which is whatever value is the last stateid the current stateid, which is whatever value is the last stateid
returned by an operation within the COMPOUND. In the case of an returned by an operation within the COMPOUND. In the case of an
OPEN, the stateid returned for the open file, and not the OPEN, the stateid returned for the open file, and not the
delegation is used. The stateid passed to the operation in place delegation is used. The stateid passed to the operation in place
of the special value has its "seqid" value set to zero, except of the special value has its "seqid" value set to zero, except
when the current stateid is used by the operation CLOSE or when the current stateid is used by the operation CLOSE or
OPEN_DOWNGRADE. If there is no operation in the COMPOUND which OPEN_DOWNGRADE. If there is no operation in the COMPOUND which
has returned a stateid value, the server MUST return the error has returned a stateid value, the server MUST return the error
NFS4ERR_BAD_STATEID. As illustrated in Figure 89, if the value of NFS4ERR_BAD_STATEID. As illustrated in Figure 6, if the value of
a current stateid is a special stateid, and the stateid of an a current stateid is a special stateid, and the stateid of an
operation's arguments has "other" set to zero, and "seqid" set to operation's arguments has "other" set to zero, and "seqid" set to
one, then the server MUST return the error NFS4ERR_BAD_STATEID. one, then the server MUST return the error NFS4ERR_BAD_STATEID.
o When "other" is zero and "seqid" is NFS4_UINT32_MAX, the stateid o When "other" is zero and "seqid" is NFS4_UINT32_MAX, the stateid
represents a reserved stateid value defined to be invalid. When represents a reserved stateid value defined to be invalid. When
this stateid is used, the server MUST return the error this stateid is used, the server MUST return the error
NFS4ERR_BAD_STATEID. NFS4ERR_BAD_STATEID.
If a stateid value is used which has all zero or all ones in the If a stateid value is used which has all zero or all ones in the
skipping to change at page 265, line 45 skipping to change at page 265, line 45
||| | ||| |
||| | ||| |
||| Storage +-----------+ | ||| Storage +-----------+ |
||| Protocol |+-----------+ | ||| Protocol |+-----------+ |
||+----------------||+-----------+ Control | ||+----------------||+-----------+ Control |
|+-----------------||| | Protocol| |+-----------------||| | Protocol|
+------------------+|| Storage |------------+ +------------------+|| Storage |------------+
+| Devices | +| Devices |
+-----------+ +-----------+
Figure 68 Figure 1
In this model, the clients, server, and storage devices are In this model, the clients, server, and storage devices are
responsible for managing file access. This is in contrast to NFSv4 responsible for managing file access. This is in contrast to NFSv4
without pNFS where it is primarily the server's responsibility; some without pNFS where it is primarily the server's responsibility; some
of this responsibility may be delegated to the client under strictly of this responsibility may be delegated to the client under strictly
specified conditions. specified conditions.
pNFS takes the form of OPTIONAL operations that manage protocol pNFS takes the form of OPTIONAL operations that manage protocol
objects called 'layouts' which contain a byte-range and storage objects called 'layouts' which contain a byte-range and storage
location information. The layout is managed in a similar fashion as location information. The layout is managed in a similar fashion as
skipping to change at page 274, line 36 skipping to change at page 274, line 36
client can set at file creation time to provide a hint to the server client can set at file creation time to provide a hint to the server
for new files. Setting this attribute separately, after the file has for new files. Setting this attribute separately, after the file has
been created might make it difficult, or impossible, for the server been created might make it difficult, or impossible, for the server
implementation to comply. implementation to comply.
Because the EXCLUSIVE4 createmode4 does not allow the setting of Because the EXCLUSIVE4 createmode4 does not allow the setting of
attributes at file creation time, NFSv4.1 introduces the EXCLUSIVE4_1 attributes at file creation time, NFSv4.1 introduces the EXCLUSIVE4_1
createmode4, which does allow attributes to be set at file creation createmode4, which does allow attributes to be set at file creation
time. In addition, if the session is created with persistent reply time. In addition, if the session is created with persistent reply
caches, EXCLUSIVE4_1 is neither necessary nor allowed. Instead, caches, EXCLUSIVE4_1 is neither necessary nor allowed. Instead,
GUARDED4 both works better and is prescribed. Table 18 in GUARDED4 both works better and is prescribed. Table 10 in
Section 18.16.3, summarizes how a client is allowed to send an Section 18.16.3, summarizes how a client is allowed to send an
exclusive create. exclusive create.
12.5.3. Layout Stateid 12.5.3. Layout Stateid
As with all other stateids, the layout stateid consists of a "seqid" As with all other stateids, the layout stateid consists of a "seqid"
and "other" field. Once a layout stateid is changed, the "other" and "other" field. Once a layout stateid is changed, the "other"
field will stay constant unless the stateid is revoked, or the client field will stay constant unless the stateid is revoked, or the client
returns all layouts on the file and the server disposes of the returns all layouts on the file and the server disposes of the
stateid. The "seqid" field is initially set to one, and is never stateid. The "seqid" field is initially set to one, and is never
skipping to change at page 288, line 28 skipping to change at page 288, line 28
persistent, the client will use EXCLUSIVE4_1 for exclusive creates. persistent, the client will use EXCLUSIVE4_1 for exclusive creates.
If a file is to be created on a pNFS enabled file system, the client If a file is to be created on a pNFS enabled file system, the client
uses the OPEN operation. With the normal set of attributes that may uses the OPEN operation. With the normal set of attributes that may
be provided upon OPEN used for creation, there is an OPTIONAL be provided upon OPEN used for creation, there is an OPTIONAL
layout_hint attribute. The client's use of layout_hint allows the layout_hint attribute. The client's use of layout_hint allows the
client to express its preference for a layout type and its associated client to express its preference for a layout type and its associated
layout details. The use of a createmode4 of UNCHECKED4, GUARDED4, or layout details. The use of a createmode4 of UNCHECKED4, GUARDED4, or
EXCLUSIVE4_1 will allow the client to provide the layout_hint EXCLUSIVE4_1 will allow the client to provide the layout_hint
attribute at create time. The client MUST NOT use EXCLUSIVE4 (see attribute at create time. The client MUST NOT use EXCLUSIVE4 (see
Table 18). The client is RECOMMENDED to combine a GETATTR operation Table 10). The client is RECOMMENDED to combine a GETATTR operation
after the OPEN within the same COMPOUND. The GETATTR may then after the OPEN within the same COMPOUND. The GETATTR may then
retrieve the layout_type attribute for the newly created file. The retrieve the layout_type attribute for the newly created file. The
client will then know what layout type the server has chosen for the client will then know what layout type the server has chosen for the
file and therefore what storage protocol the client must use. file and therefore what storage protocol the client must use.
If the client wants to open an existing file, then it also includes a If the client wants to open an existing file, then it also includes a
GETATTR to determine what layout type the file supports. GETATTR to determine what layout type the file supports.
The GETATTR in either the file creation or plain file open case can The GETATTR in either the file creation or plain file open case can
also include the layout_blksize and layout_alignment attributes so also include the layout_blksize and layout_alignment attributes so
skipping to change at page 295, line 4 skipping to change at page 295, line 4
NFSv4.1) what role the request to the common server network NFSv4.1) what role the request to the common server network
address is directed to. address is directed to.
12.9. Security Considerations for pNFS 12.9. Security Considerations for pNFS
pNFS separates file system metadata and data and provides access to pNFS separates file system metadata and data and provides access to
both. There are pNFS-specific operations (listed in Section 12.3) both. There are pNFS-specific operations (listed in Section 12.3)
that provide access to the metadata; all existing NFSv4.1 that provide access to the metadata; all existing NFSv4.1
conventional (non-pNFS) security mechanisms and features apply to conventional (non-pNFS) security mechanisms and features apply to
accessing the metadata. The combination of components in a pNFS accessing the metadata. The combination of components in a pNFS
system (see Figure 68) is required to preserve the security system (see Figure 1) is required to preserve the security properties
properties of NFSv4.1 with respect to an entity accessing storage of NFSv4.1 with respect to an entity accessing storage device from a
device from a client, including security countermeasures to defend client, including security countermeasures to defend against threats
against threats that NFSv4.1 provides defenses for in environments that NFSv4.1 provides defenses for in environments where these
where these threats are considered significant. threats are considered significant.
In some cases, the security countermeasures for connections to In some cases, the security countermeasures for connections to
storage devices may take the form of physical isolation or a storage devices may take the form of physical isolation or a
recommendation not to use pNFS in an environment. For example, it recommendation not to use pNFS in an environment. For example, it
may be impractical to provide confidentiality protection for some may be impractical to provide confidentiality protection for some
storage protocols to protect against eavesdropping; in environments storage protocols to protect against eavesdropping; in environments
where eavesdropping on such protocols is of sufficient concern to where eavesdropping on such protocols is of sufficient concern to
require countermeasures, physical isolation of the communication require countermeasures, physical isolation of the communication
channel (e.g., via direct connection from client(s) to storage channel (e.g., via direct connection from client(s) to storage
device(s)) and/or a decision to forego use of pNFS (e.g., and fall device(s)) and/or a decision to forego use of pNFS (e.g., and fall
skipping to change at page 326, line 31 skipping to change at page 326, line 31
the strings to UTF-8. The second flag is the strings to UTF-8. The second flag is
FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 which if set to one, indicates that FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 which if set to one, indicates that
the server will accept (and generate) only UTF-8 characters on the the server will accept (and generate) only UTF-8 characters on the
file system. If FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 is set to one, file system. If FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 is set to one,
FSCHARSET_CAP4_CONTAINS_NON_UTF8 MUST be set to zero. FSCHARSET_CAP4_CONTAINS_NON_UTF8 MUST be set to zero.
FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 SHOULD always be set to one. FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 SHOULD always be set to one.
14.5. UTF-8 Related Errors 14.5. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server should Where the client sends an invalid UTF-8 string, the server should
return NFS4ERR_INVAL (see Table 11). This includes cases in which return NFS4ERR_INVAL (see Table 5). This includes cases in which
inappropriate prefixes are detected and where the count includes inappropriate prefixes are detected and where the count includes
trailing bytes that do not constitute a full UCS character. trailing bytes that do not constitute a full UCS character.
Where the client supplied string is valid UTF-8 but contains Where the client supplied string is valid UTF-8 but contains
characters that are not supported by the server as a value for that characters that are not supported by the server as a value for that
string (e.g. names containing characters that have more than two string (e.g. names containing characters that have more than two
bytes on a file system that supports Unicode characters only), the bytes on a file system that supports Unicode characters only), the
server should return NFS4ERR_BADCHAR. server should return NFS4ERR_BADCHAR.
Where a UTF-8 string is used as a file name, and the file system, Where a UTF-8 string is used as a file name, and the file system,
while supporting all of the characters within the name, does not while supporting all of the characters within the name, does not
allow that particular name to be used, the server should return the allow that particular name to be used, the server should return the
error NFS4ERR_BADNAME (Table 11). This includes situations in which error NFS4ERR_BADNAME (Table 5). This includes situations in which
the server file system imposes a normalization constraint on name the server file system imposes a normalization constraint on name
strings, but will also include such situations as file system strings, but will also include such situations as file system
prohibitions of "." and ".." as file names for certain operations, prohibitions of "." and ".." as file names for certain operations,
and other such constraints. and other such constraints.
15. Error Values 15. Error Values
NFS error numbers are assigned to failed operations within a Compound NFS error numbers are assigned to failed operations within a Compound
(COMPOUND or CB_COMPOUND) request. A Compound request contains a (COMPOUND or CB_COMPOUND) request. A Compound request contains a
number of NFS operations that have their results encoded in sequence number of NFS operations that have their results encoded in sequence
skipping to change at page 329, line 29 skipping to change at page 329, line 29
| NFS4ERR_TOOSMALL | 10005 | Section 15.1.1.7 | | NFS4ERR_TOOSMALL | 10005 | Section 15.1.1.7 |
| NFS4ERR_TOO_MANY_OPS | 10070 | Section 15.1.3.11 | | NFS4ERR_TOO_MANY_OPS | 10070 | Section 15.1.3.11 |
| NFS4ERR_UNKNOWN_LAYOUTTYPE | 10062 | Section 15.1.10.9 | | NFS4ERR_UNKNOWN_LAYOUTTYPE | 10062 | Section 15.1.10.9 |
| NFS4ERR_UNSAFE_COMPOUND | 10069 | Section 15.1.3.12 | | NFS4ERR_UNSAFE_COMPOUND | 10069 | Section 15.1.3.12 |
| NFS4ERR_WRONGSEC | 10016 | Section 15.1.6.3 | | NFS4ERR_WRONGSEC | 10016 | Section 15.1.6.3 |
| NFS4ERR_WRONG_CRED | 10082 | Section 15.1.6.4 | | NFS4ERR_WRONG_CRED | 10082 | Section 15.1.6.4 |
| NFS4ERR_WRONG_TYPE | 10083 | Section 15.1.2.9 | | NFS4ERR_WRONG_TYPE | 10083 | Section 15.1.2.9 |
| NFS4ERR_XDEV | 18 | Section 15.1.4.12 | | NFS4ERR_XDEV | 18 | Section 15.1.4.12 |
+-----------------------------------+--------+-------------------+ +-----------------------------------+--------+-------------------+
Table 11 Table 5
15.1.1. General Errors 15.1.1. General Errors
This section deals with errors that are applicable to a broad set of This section deals with errors that are applicable to a broad set of
different purposes. different purposes.
15.1.1.1. NFS4ERR_BADXDR (Error Code 10036) 15.1.1.1. NFS4ERR_BADXDR (Error Code 10036)
The arguments for this operation do not match those specified in the The arguments for this operation do not match those specified in the
XDR definition. This includes situations in which the request ends XDR definition. This includes situations in which the request ends
skipping to change at page 362, line 6 skipping to change at page 362, line 6
| | NFS4ERR_PNFS_IO_HOLE, | | | NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, | | | NFS4ERR_PNFS_NO_LAYOUT, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_WRONG_TYPE |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 12 Table 6
15.3. Callback operations and their valid errors 15.3. Callback operations and their valid errors
This section contains a table which gives the valid error returns for This section contains a table which gives the valid error returns for
each callback operation. The error code NFS4_OK (indicating no each callback operation. The error code NFS4_OK (indicating no
error) is not listed but should be understood to be returnable by all error) is not listed but should be understood to be returnable by all
callback operations with the exception of CB_ILLEGAL. callback operations with the exception of CB_ILLEGAL.
Valid error returns for each protocol callback operation Valid error returns for each protocol callback operation
skipping to change at page 364, line 32 skipping to change at page 364, line 32
| CB_WANTS_CANCELLED | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | CB_WANTS_CANCELLED | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_NOTSUPP, | | | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_TOO_MANY_OPS |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
Table 13 Table 7
15.4. Errors and the operations that use them 15.4. Errors and the operations that use them
+-----------------------------------+-------------------------------+ +-----------------------------------+-------------------------------+
| Error | Operations | | Error | Operations |
+-----------------------------------+-------------------------------+ +-----------------------------------+-------------------------------+
| NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, | | NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, |
| | GETATTR, GET_DIR_DELEGATION, | | | GETATTR, GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LINK, LOCK, LOCKT, LOCKU, | | | LINK, LOCK, LOCKT, LOCKU, |
skipping to change at page 378, line 24 skipping to change at page 378, line 24
| | GETATTR, LAYOUTGET, | | | GETATTR, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, NVERIFY, OPEN, | | | LOCKT, NVERIFY, OPEN, |
| | OPENATTR, READ, READLINK, | | | OPENATTR, READ, READLINK, |
| | RECLAIM_COMPLETE, SETATTR, | | | RECLAIM_COMPLETE, SETATTR, |
| | VERIFY, WANT_DELEGATION, | | | VERIFY, WANT_DELEGATION, |
| | WRITE | | | WRITE |
| NFS4ERR_XDEV | LINK, RENAME | | NFS4ERR_XDEV | LINK, RENAME |
+-----------------------------------+-------------------------------+ +-----------------------------------+-------------------------------+
Table 14 Table 8
16. NFSv4.1 Procedures 16. NFSv4.1 Procedures
Both procedures, NULL and COMPOUND, MUST be implemented. Both procedures, NULL and COMPOUND, MUST be implemented.
16.1. Procedure 0: NULL - No Operation 16.1. Procedure 0: NULL - No Operation
16.1.1. ARGUMENTS 16.1.1. ARGUMENTS
void; void;
skipping to change at page 387, line 24 skipping to change at page 387, line 24
PUTFH fh1 {fh1} PUTFH fh1 {fh1}
LOOKUP "compA" {fh2} LOOKUP "compA" {fh2}
GETATTR {fh2} GETATTR {fh2}
LOOKUP "compB" {fh3} LOOKUP "compB" {fh3}
GETATTR {fh3} GETATTR {fh3}
LOOKUP "compC" {fh4} LOOKUP "compC" {fh4}
GETATTR {fh4} GETATTR {fh4}
GETFH GETFH
Figure 85 Figure 2
In this example, the PUTFH (Section 18.19) operation explicitly sets In this example, the PUTFH (Section 18.19) operation explicitly sets
the current filehandle value while the result of each LOOKUP the current filehandle value while the result of each LOOKUP
operation sets the current filehandle value to the resultant file operation sets the current filehandle value to the resultant file
system object. Also, the client is able to insert GETATTR operations system object. Also, the client is able to insert GETATTR operations
using the current filehandle as an argument. using the current filehandle as an argument.
The PUTROOTFH (Section 18.21) and PUTPUBFH (Section 18.21) operations The PUTROOTFH (Section 18.21) and PUTPUBFH (Section 18.21) operations
also set the current filehandle. The above example would replace also set the current filehandle. The above example would replace
"PUTFH fh1" with PUTROOTFH or PUTPUBFH with no filehandle argument in "PUTFH fh1" with PUTROOTFH or PUTPUBFH with no filehandle argument in
skipping to change at page 388, line 39 skipping to change at page 388, line 39
The following example is the common case of a simple READ operation The following example is the common case of a simple READ operation
with a supplied stateid showing that the PUTFH initializes the with a supplied stateid showing that the PUTFH initializes the
current stateid to (0, 0). The subsequent READ with stateid (sid1) current stateid to (0, 0). The subsequent READ with stateid (sid1)
leaves the current stateid unchanged, but does evaluate the the leaves the current stateid unchanged, but does evaluate the the
operation. operation.
PUTFH fh1 - -> {fh1, (0, 0)} PUTFH fh1 - -> {fh1, (0, 0)}
READ (sid1), 0, 1024 {fh1, (0, 0)} -> {fh1, (0, 0)} READ (sid1), 0, 1024 {fh1, (0, 0)} -> {fh1, (0, 0)}
Figure 86 Figure 3
This next example performs an OPEN with the root filehandle and as a This next example performs an OPEN with the root filehandle and as a
result generates stateid (sid1). The next operation specifies the result generates stateid (sid1). The next operation specifies the
READ with the argument stateid set such that (seqid, other) are equal READ with the argument stateid set such that (seqid, other) are equal
to (1, 0), but the current stateid set by the previous operation is to (1, 0), but the current stateid set by the previous operation is
actually used when the operation is evaluated. This allows correct actually used when the operation is evaluated. This allows correct
interaction with any existing, potentially conflicting, locks. interaction with any existing, potentially conflicting, locks.
PUTROOTFH - -> {fh1, (0, 0)} PUTROOTFH - -> {fh1, (0, 0)}
OPEN "compA" {fh1, (0, 0)} -> {fh2, (sid1)} OPEN "compA" {fh1, (0, 0)} -> {fh2, (sid1)}
READ (1, 0), 0, 1024 {fh2, (sid1)} -> {fh2, (sid1)} READ (1, 0), 0, 1024 {fh2, (sid1)} -> {fh2, (sid1)}
CLOSE (1, 0) {fh2, (sid1)} -> {fh2, (sid2)} CLOSE (1, 0) {fh2, (sid1)} -> {fh2, (sid2)}
Figure 87 Figure 4
This next example is similar to the second in how it passes the This next example is similar to the second in how it passes the
stateid sid2 generated by the LOCK operation to the next READ stateid sid2 generated by the LOCK operation to the next READ
operation. This allows the client to explicitly surround a single operation. This allows the client to explicitly surround a single
I/O operation with a lock and its appropriate stateid to guarantee I/O operation with a lock and its appropriate stateid to guarantee
correctness with other client locks. The example also shows how correctness with other client locks. The example also shows how
SAVEFH and RESTOREFH can save and later re-use a filehandle and SAVEFH and RESTOREFH can save and later re-use a filehandle and
stateid, passing them as the current filehandle and stateid to a READ stateid, passing them as the current filehandle and stateid to a READ
operation. operation.
skipping to change at page 389, line 27 skipping to change at page 389, line 27
READ (1, 0), 0, 1024 {fh1, (sid2)} -> {fh1, (sid2)} READ (1, 0), 0, 1024 {fh1, (sid2)} -> {fh1, (sid2)}
LOCKU 0, 1024, (1, 0) {fh1, (sid2)} -> {fh1, (sid3)} LOCKU 0, 1024, (1, 0) {fh1, (sid2)} -> {fh1, (sid3)}
SAVEFH {fh1, (sid3)} -> {fh1, (sid3)} SAVEFH {fh1, (sid3)} -> {fh1, (sid3)}
PUTFH fh2 {fh1, (sid3)} -> {fh2, (0, 0)} PUTFH fh2 {fh1, (sid3)} -> {fh2, (0, 0)}
WRITE (1, 0), 0, 1024 {fh2, (0, 0)} -> {fh2, (0, 0)} WRITE (1, 0), 0, 1024 {fh2, (0, 0)} -> {fh2, (0, 0)}
RESTOREFH {fh2, (0, 0)} -> {fh1, (sid3)} RESTOREFH {fh2, (0, 0)} -> {fh1, (sid3)}
READ (1, 0), 1024, 1024 {fh1, (sid3)} -> {fh1, (sid3)} READ (1, 0), 1024, 1024 {fh1, (sid3)} -> {fh1, (sid3)}
Figure 88 Figure 5
The final example shows a disallowed use of the current stateid. The The final example shows a disallowed use of the current stateid. The
client is attempting to implicitly pass anonymous special stateid, client is attempting to implicitly pass anonymous special stateid,
(0,0) to the READ operation. The server MUST return (0,0) to the READ operation. The server MUST return
NFS4ERR_BAD_STATEID in the reply to the READ operation. NFS4ERR_BAD_STATEID in the reply to the READ operation.
PUTFH fh1 - -> {fh1, (0, 0)} PUTFH fh1 - -> {fh1, (0, 0)}
READ (1, 0), 0, 1024 {fh1, (0, 0)} -> NFS4ERR_BAD_STATEID READ (1, 0), 0, 1024 {fh1, (0, 0)} -> NFS4ERR_BAD_STATEID
Figure 89 Figure 6
16.2.4. ERRORS 16.2.4. ERRORS
COMPOUND will of course return every error that each operation on the COMPOUND will of course return every error that each operation on the
fore channel can return (see Table 12). However if COMPOUND returns fore channel can return (see Table 6). However if COMPOUND returns
zero operations, obviously the error returned by COMPOUND has nothing zero operations, obviously the error returned by COMPOUND has nothing
to do with an error returned by an operation. The list of errors to do with an error returned by an operation. The list of errors
COMPOUND will return if it processes zero operations include: COMPOUND will return if it processes zero operations include:
COMPOUND error returns COMPOUND error returns
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| Error | Notes | | Error | Notes |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| NFS4ERR_BADCHAR | The tag argument has a character | | NFS4ERR_BADCHAR | The tag argument has a character |
skipping to change at page 390, line 24 skipping to change at page 390, line 24
| NFS4ERR_INVAL | The tag argument is not in UTF-8 | | NFS4ERR_INVAL | The tag argument is not in UTF-8 |
| | encoding. | | | encoding. |
| NFS4ERR_MINOR_VERS_MISMATCH | | | NFS4ERR_MINOR_VERS_MISMATCH | |
| NFS4ERR_SERVERFAULT | | | NFS4ERR_SERVERFAULT | |
| NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_TOO_MANY_OPS | |
| NFS4ERR_REP_TOO_BIG | | | NFS4ERR_REP_TOO_BIG | |
| NFS4ERR_REP_TOO_BIG_TO_CACHE | | | NFS4ERR_REP_TOO_BIG_TO_CACHE | |
| NFS4ERR_REQ_TOO_BIG | | | NFS4ERR_REQ_TOO_BIG | |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Table 15 Table 9
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL
The following tables summarize the operations of the NFSv4.1 protocol The following tables summarize the operations of the NFSv4.1 protocol
and the corresponding designation of REQUIRED, RECOMMENDED, OPTIONAL and the corresponding designation of REQUIRED, RECOMMENDED, OPTIONAL
to implement or MUST NOT implement. The designation of MUST NOT to implement or MUST NOT implement. The designation of MUST NOT
implement is reserved for those operations that were defined in implement is reserved for those operations that were defined in
NFSv4.0 and MUST NOT be implemented in NFSv4.1. NFSv4.0 and MUST NOT be implemented in NFSv4.1.
For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation
skipping to change at page 432, line 42 skipping to change at page 432, line 42
| Reply Cache | server | | | | Reply Cache | server | | |
+--------------+--------+-----------------+-------------------------+ +--------------+--------+-----------------+-------------------------+
| no | no | EXCLUSIVE4_1 | EXCLUSIVE4_1 (SHOULD) | | no | no | EXCLUSIVE4_1 | EXCLUSIVE4_1 (SHOULD) |
| | | and EXCLUSIVE4 | or EXCLUSIVE4 (SHOULD | | | | and EXCLUSIVE4 | or EXCLUSIVE4 (SHOULD |
| | | | NOT) | | | | | NOT) |
| no | yes | EXCLUSIVE4_1 | EXCLUSIVE4_1 | | no | yes | EXCLUSIVE4_1 | EXCLUSIVE4_1 |
| yes | no | GUARDED4 | GUARDED4 | | yes | no | GUARDED4 | GUARDED4 |
| yes | yes | GUARDED4 | GUARDED4 | | yes | yes | GUARDED4 | GUARDED4 |
+--------------+--------+-----------------+-------------------------+ +--------------+--------+-----------------+-------------------------+
Table 18 Table 10
If CREATE_SESSION4_FLAG_PERSIST is set in the results of If CREATE_SESSION4_FLAG_PERSIST is set in the results of
CREATE_SESSION the reply cache is persistent (see Section 18.36). If CREATE_SESSION the reply cache is persistent (see Section 18.36). If
the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results from the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results from
EXCHANGE_ID, the server is a pNFS server (see Section 18.35). If the EXCHANGE_ID, the server is a pNFS server (see Section 18.35). If the
client attempts to use EXCLUSIVE4 on a persistent session, or a client attempts to use EXCLUSIVE4 on a persistent session, or a
session derived from a EXCHGID4_FLAG_USE_PNFS_MDS client ID, the session derived from a EXCHGID4_FLAG_USE_PNFS_MDS client ID, the
server MUST return NFS4ERR_INVAL. server MUST return NFS4ERR_INVAL.
With persistent sessions, exclusive create semantics are fully With persistent sessions, exclusive create semantics are fully
skipping to change at page 434, line 33 skipping to change at page 434, line 33
| CLAIM_DELEG_CUR_FH | OPEN as granted by the server. Generally | | CLAIM_DELEG_CUR_FH | OPEN as granted by the server. Generally |
| | this is done as part of recalling a | | | this is done as part of recalling a |
| | delegation. With CLAIM_DELEGATE_CUR, the | | | delegation. With CLAIM_DELEGATE_CUR, the |
| | file is identified by the current | | | file is identified by the current |
| | filehandle and the specified component | | | filehandle and the specified component |
| | name. With CLAIM_DELEG_CUR_FH (new to | | | name. With CLAIM_DELEG_CUR_FH (new to |
| | NFSv4.1), the file is identified by just | | | NFSv4.1), the file is identified by just |
| | the current filehandle. | | | the current filehandle. |
| CLAIM_DELEGATE_PREV, | The client is claiming a delegation | | CLAIM_DELEGATE_PREV, | The client is claiming a delegation |
| CLAIM_DELEG_PREV_FH | granted to a previous client instance; | | CLAIM_DELEG_PREV_FH | granted to a previous client instance; |
| | used after the client restarts. The server | | | used after the client restarts. The |
| | MAY support CLAIM_DELEGATE_PREV or | | | server MAY support CLAIM_DELEGATE_PREV or |
| | CLAIM_DELEG_PREV_FH (new to NFSv4.1). If | | | CLAIM_DELEG_PREV_FH (new to NFSv4.1). If |
| | it does support either open type, | | | it does support either open type, |
| | CREATE_SESSION MUST NOT remove the | | | CREATE_SESSION MUST NOT remove the |
| | client's delegation state, and the server | | | client's delegation state, and the server |
| | MUST support the DELEGPURGE operation. | | | MUST support the DELEGPURGE operation. |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
For OPEN requests that reach the server during the grace period, the For OPEN requests that reach the server during the grace period, the
server returns an error of NFS4ERR_GRACE. The following claim types server returns an error of NFS4ERR_GRACE. The following claim types
are exceptions: are exceptions:
skipping to change at page 466, line 43 skipping to change at page 466, line 43
18.29.4. IMPLEMENTATION 18.29.4. IMPLEMENTATION
The SECINFO operation is expected to be used by the NFS client when The SECINFO operation is expected to be used by the NFS client when
the error value of NFS4ERR_WRONGSEC is returned from another NFS the error value of NFS4ERR_WRONGSEC is returned from another NFS
operation. This signifies to the client that the server's security operation. This signifies to the client that the server's security
policy is different from what the client is currently using. At this policy is different from what the client is currently using. At this
point, the client is expected to obtain a list of possible security point, the client is expected to obtain a list of possible security
flavors and choose what best suits its policies. flavors and choose what best suits its policies.
As mentioned, the server's security policies will determine when a As mentioned, the server's security policies will determine when a
client request receives NFS4ERR_WRONGSEC. See Table 14 for a list client request receives NFS4ERR_WRONGSEC. See Table 8 for a list
operations which can return NFS4ERR_WRONGSEC. In addition, when operations which can return NFS4ERR_WRONGSEC. In addition, when
READDIR returns attributes, the rdattr_error (Section 5.8.1.12) can READDIR returns attributes, the rdattr_error (Section 5.8.1.12) can
contain NFS4ERR_WRONGSEC. Note that CREATE and REMOVE MUST NOT contain NFS4ERR_WRONGSEC. Note that CREATE and REMOVE MUST NOT
return NFS4ERR_WRONGSEC. The rationale for CREATE is that unless the return NFS4ERR_WRONGSEC. The rationale for CREATE is that unless the
target name exists it cannot have a separate security policy from the target name exists it cannot have a separate security policy from the
parent directory, and the security policy of the parent was checked parent directory, and the security policy of the parent was checked
when its filehandle was injected into the COMPOUND request's when its filehandle was injected into the COMPOUND request's
operations stream (for similar reasons, an OPEN operation that operations stream (for similar reasons, an OPEN operation that
creates the target MUST NOT return NFS4ERR_WRONGSEC). If the target creates the target MUST NOT return NFS4ERR_WRONGSEC). If the target
name exists, while it might have a separate security policy, that is name exists, while it might have a separate security policy, that is
skipping to change at page 473, line 49 skipping to change at page 473, line 49
stateid identifies the associated owners if any and is used by the stateid identifies the associated owners if any and is used by the
server to verify that the associated locks are still valid (e.g. have server to verify that the associated locks are still valid (e.g. have
not been revoked). not been revoked).
Upon successful completion, the following results are returned. The Upon successful completion, the following results are returned. The
count result is the number of bytes of data written to the file. The count result is the number of bytes of data written to the file. The
server may write fewer bytes than requested. If so, the actual server may write fewer bytes than requested. If so, the actual
number of bytes written starting at location, offset, is returned. number of bytes written starting at location, offset, is returned.
The server also returns an indication of the level of commitment of The server also returns an indication of the level of commitment of
the data and metadata via committed. Per Table 20, the data and metadata via committed. Per Table 11,
o The server MAY commit the data at a stronger level than requested. o The server MAY commit the data at a stronger level than requested.
o The server MUST commit the data at a level at least as high as o The server MUST commit the data at a level at least as high as
that committed. that committed.
Valid combinations of the fields stable in the request and committed Valid combinations of the fields stable in the request and committed
in the reply. in the reply.
+------------+-----------------------------------+ +------------+-----------------------------------+
| stable | committed | | stable | committed |
+------------+-----------------------------------+ +------------+-----------------------------------+
| UNSTABLE4 | FILE_SYNC4, DATA_SYNC4, UNSTABLE4 | | UNSTABLE4 | FILE_SYNC4, DATA_SYNC4, UNSTABLE4 |
| DATA_SYNC4 | FILE_SYNC4, DATA_SYNC4 | | DATA_SYNC4 | FILE_SYNC4, DATA_SYNC4 |
| FILE_SYNC4 | FILE_SYNC4 | | FILE_SYNC4 | FILE_SYNC4 |
+------------+-----------------------------------+ +------------+-----------------------------------+
Table 20 Table 11
The final portion of the result is the field writeverf. This field The final portion of the result is the field writeverf. This field
is the write verifier and is a cookie that the client can use to is the write verifier and is a cookie that the client can use to
determine whether a server has changed instance state (e.g. server determine whether a server has changed instance state (e.g. server
restart) between a call to WRITE and a subsequent call to either restart) between a call to WRITE and a subsequent call to either
WRITE or COMMIT. This cookie MUST be unchanged during a single WRITE or COMMIT. This cookie MUST be unchanged during a single
instance of the NFSv4.1 server and MUST be unique between instances instance of the NFSv4.1 server and MUST be unique between instances
of the NFSv4.1 server. If the cookie changes, then the client MUST of the NFSv4.1 server. If the cookie changes, then the client MUST
assume that any data written with an UNSTABLE4 value for committed assume that any data written with an UNSTABLE4 value for committed
and an old writeverf in the reply has been lost and will need to be and an old writeverf in the reply has been lost and will need to be
skipping to change at page 523, line 49 skipping to change at page 523, line 49
o If the sum of loga_offset and loga_minlength exceeds o If the sum of loga_offset and loga_minlength exceeds
NFS4_UINT64_MAX, and loga_minlength is not NFS4_UINT64_MAX, the NFS4_UINT64_MAX, and loga_minlength is not NFS4_UINT64_MAX, the
error NFS4ERR_INVAL MUST result. error NFS4ERR_INVAL MUST result.
o If the sum of loga_offset and loga_length exceeds NFS4_UINT64_MAX, o If the sum of loga_offset and loga_length exceeds NFS4_UINT64_MAX,
and loga_length is not NFS4_UINT64_MAX, the error NFS4ERR_INVAL and loga_length is not NFS4_UINT64_MAX, the error NFS4ERR_INVAL
MUST result. MUST result.
After the metadata server has performed the above checks on After the metadata server has performed the above checks on
loga_offset, loga_minlength, and loga_offset, the metadata server loga_offset, loga_minlength, and loga_offset, the metadata server
MUST return a layout according to the rules in Table 21. MUST return a layout according to the rules in Table 12.
Acceptable layouts based on loga_minlength. Note: u64m = Acceptable layouts based on loga_minlength. Note: u64m =
NFS4_UINT64_MAX; a_off = loga_offset; a_minlen = loga_minlength. NFS4_UINT64_MAX; a_off = loga_offset; a_minlen = loga_minlength.
+-----------+-----------+----------+----------+---------------------+ +-----------+-----------+----------+----------+---------------------+
| Layout | Layout | Layout | Layout | Layout length of | | Layout | Layout | Layout | Layout | Layout length of |
| iomode of | a_minlen | iomode | offset | reply | | iomode of | a_minlen | iomode | offset | reply |
| request | of | of reply | of reply | | | request | of | of reply | of reply | |
| | request | | | | | | request | | | |
+-----------+-----------+----------+----------+---------------------+ +-----------+-----------+----------+----------+---------------------+
skipping to change at page 524, line 39 skipping to change at page 524, line 39
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
| _RW | u64m | MUST be | MUST be | MUST be u64m | | _RW | u64m | MUST be | MUST be | MUST be u64m |
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
| _RW | > 0 and < | MUST be | MUST be | MUST be >= a_off - | | _RW | > 0 and < | MUST be | MUST be | MUST be >= a_off - |
| | u64m | _RW | <= a_off | layout offset + | | | u64m | _RW | <= a_off | layout offset + |
| | | | | a_minlen | | | | | | a_minlen |
| _RW | 0 | MUST be | MUST be | MUST be > 0 | | _RW | 0 | MUST be | MUST be | MUST be > 0 |
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
+-----------+-----------+----------+----------+---------------------+ +-----------+-----------+----------+----------+---------------------+
Table 21 Table 12
If loga_minlength is not zero and the metadata server cannot return a If loga_minlength is not zero and the metadata server cannot return a
layout according to the rules in Table 21, then the metadata server layout according to the rules in Table 12, then the metadata server
MUST return the error NFS4ERR_BADLAYOUT. If loga_minlength is zero MUST return the error NFS4ERR_BADLAYOUT. If loga_minlength is zero
and the metadata server cannot or will not return a layout according and the metadata server cannot or will not return a layout according
to the rules in Table 21, then the metadata server MUST return the to the rules in Table 12, then the metadata server MUST return the
error NFS4ERR_LAYOUTTRYLATER. Assuming loga_length is greater than error NFS4ERR_LAYOUTTRYLATER. Assuming loga_length is greater than
loga_minlength or equal to zero, the metadata server SHOULD return a loga_minlength or equal to zero, the metadata server SHOULD return a
layout according to the rules in Table 22. layout according to the rules in Table 13.
Desired layouts based on loga_length. The rules of Table 21 MUST be Desired layouts based on loga_length. The rules of Table 12 MUST be
applied first. Note: u64m = NFS4_UINT64_MAX; a_off = loga_offset; applied first. Note: u64m = NFS4_UINT64_MAX; a_off = loga_offset;
a_len = loga_length. a_len = loga_length.
+------------+------------+-----------+-----------+-----------------+ +------------+------------+-----------+-----------+-----------------+
| Layout | Layout | Layout | Layout | Layout length | | Layout | Layout | Layout | Layout | Layout length |
| iomode of | a_len of | iomode of | offset of | of reply | | iomode of | a_len of | iomode of | offset of | of reply |
| request | request | reply | reply | | | request | request | reply | reply | |
+------------+------------+-----------+-----------+-----------------+ +------------+------------+-----------+-----------+-----------------+
| _READ | u64m | MAY be | MUST be | SHOULD be u64m | | _READ | u64m | MAY be | MUST be | SHOULD be u64m |
| | | _READ | <= a_off | | | | | _READ | <= a_off | |
skipping to change at page 525, line 40 skipping to change at page 525, line 40
| _RW | u64m | MUST be | MUST be | SHOULD be u64m | | _RW | u64m | MUST be | MUST be | SHOULD be u64m |
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
| _RW | > 0 and < | MUST be | MUST be | SHOULD be >= | | _RW | > 0 and < | MUST be | MUST be | SHOULD be >= |
| | u64m | _RW | <= a_off | a_off - layout | | | u64m | _RW | <= a_off | a_off - layout |
| | | | | offset + a_len | | | | | | offset + a_len |
| _RW | 0 | MUST be | MUST be | SHOULD be > | | _RW | 0 | MUST be | MUST be | SHOULD be > |
| | | _RW | <= a_off | a_off - layout | | | | _RW | <= a_off | a_off - layout |
| | | | | offset | | | | | | offset |
+------------+------------+-----------+-----------+-----------------+ +------------+------------+-----------+-----------+-----------------+
Table 22 Table 13
The loga_stateid field specifies a valid stateid. If a layout is not The loga_stateid field specifies a valid stateid. If a layout is not
currently held by the client, the loga_stateid field represents a currently held by the client, the loga_stateid field represents a
stateid reflecting the correspondingly valid open, byte-range lock, stateid reflecting the correspondingly valid open, byte-range lock,
or delegation stateid. Once a layout is held on the file by the or delegation stateid. Once a layout is held on the file by the
client, the loga_stateid field MUST be a stateid as returned from a client, the loga_stateid field MUST be a stateid as returned from a
previous LAYOUTGET or LAYOUTRETURN operation or provided by a previous LAYOUTGET or LAYOUTRETURN operation or provided by a
CB_LAYOUTRECALL operation (see Section 12.5.3). CB_LAYOUTRECALL operation (see Section 12.5.3).
The loga_maxcount field specifies the maximum layout size (in bytes) The loga_maxcount field specifies the maximum layout size (in bytes)
skipping to change at page 526, line 16 skipping to change at page 526, line 16
The returned layout is expressed as an array, logr_layout, with each The returned layout is expressed as an array, logr_layout, with each
element of type layout4. If a file has a single striping pattern, element of type layout4. If a file has a single striping pattern,
then logr_layout SHOULD contain just one entry. Otherwise, if the then logr_layout SHOULD contain just one entry. Otherwise, if the
requested range overlaps more than one striping pattern, logr_layout requested range overlaps more than one striping pattern, logr_layout
will contain the required number of entries. The elements of will contain the required number of entries. The elements of
logr_layout MUST be sorted in ascending order of the value of the logr_layout MUST be sorted in ascending order of the value of the
lo_offset field of each element. There MUST be no gaps or overlaps lo_offset field of each element. There MUST be no gaps or overlaps
in the range between two successive elements of logr_layout. The in the range between two successive elements of logr_layout. The
lo_iomode field in each element of logr_layout MUST be the same. lo_iomode field in each element of logr_layout MUST be the same.
Table 21 and Table 22 both refer to a returned layout iomode, offset, Table 12 and Table 13 both refer to a returned layout iomode, offset,
and length. Because the returned layout is encoded in the and length. Because the returned layout is encoded in the
logr_layout array, more description is required. logr_layout array, more description is required.
iomode iomode
The value of the returned layout iomode listed in Table 21 and The value of the returned layout iomode listed in Table 12 and
Table 22 is equal to the value of the lo_iomode field in each Table 13 is equal to the value of the lo_iomode field in each
element of logr_layout. As shown in Table 21 and Table 22, the element of logr_layout. As shown in Table 12 and Table 13, the
metadata server MAY return a layout with an lo_iomode different metadata server MAY return a layout with an lo_iomode different
from the requested iomode (field loga_iomode of the request). If from the requested iomode (field loga_iomode of the request). If
it does so, it MUST ensure that the lo_iomode is more permissive it does so, it MUST ensure that the lo_iomode is more permissive
than the loga_iomode requested. For example, this behavior allows than the loga_iomode requested. For example, this behavior allows
an implementation to upgrade read-only requests to read/write an implementation to upgrade read-only requests to read/write
requests at its discretion, within the limits of the layout type requests at its discretion, within the limits of the layout type
specific protocol. A lo_iomode of either LAYOUTIOMODE4_READ or specific protocol. A lo_iomode of either LAYOUTIOMODE4_READ or
LAYOUTIOMODE4_RW MUST be returned. LAYOUTIOMODE4_RW MUST be returned.
offset offset
The value of the returned layout offset listed in Table 21 and The value of the returned layout offset listed in Table 12 and
Table 22 is always equal to the lo_offset field of the first Table 13 is always equal to the lo_offset field of the first
element logr_layout. element logr_layout.
length length
When setting the value of the returned layout length, the When setting the value of the returned layout length, the
situation is complicated by the possibility that the special situation is complicated by the possibility that the special
layout length value NFS4_UINT64_MAX is involved. For a layout length value NFS4_UINT64_MAX is involved. For a
logr_layout array of N elements, the lo_length field in the first logr_layout array of N elements, the lo_length field in the first
N-1 elements MUST NOT be NFS4_UINT64_MAX. The lo_length field of N-1 elements MUST NOT be NFS4_UINT64_MAX. The lo_length field of
the last element of logr_layout can be NFS4_UINT64_MAX under some the last element of logr_layout can be NFS4_UINT64_MAX under some
conditions as described in the following list. conditions as described in the following list.
* If an applicable rule of Table 21 states the metadata server * If an applicable rule of Table 12 states the metadata server
MUST return a layout of length NFS4_UINT64_MAX, then lo_length MUST return a layout of length NFS4_UINT64_MAX, then lo_length
field of the last element of logr_layout MUST be field of the last element of logr_layout MUST be
NFS4_UINT64_MAX. NFS4_UINT64_MAX.
* If an applicable rule of Table 21 states the metadata server * If an applicable rule of Table 12 states the metadata server
MUST NOT return a layout of length NFS4_UINT64_MAX, then MUST NOT return a layout of length NFS4_UINT64_MAX, then
lo_length field of the last element of logr_layout MUST NOT be lo_length field of the last element of logr_layout MUST NOT be
NFS4_UINT64_MAX. NFS4_UINT64_MAX.
* If an applicable rule of Table 22 states the metadata server * If an applicable rule of Table 13 states the metadata server
SHOULD return a layout of length NFS4_UINT64_MAX, then SHOULD return a layout of length NFS4_UINT64_MAX, then
lo_length field of the last element of logr_layout SHOULD be lo_length field of the last element of logr_layout SHOULD be
NFS4_UINT64_MAX. NFS4_UINT64_MAX.
* When the value of the returned layout length of Table 21 and * When the value of the returned layout length of Table 12 and
Table 22 is not NFS4_UINT64_MAX, then the returned layout Table 13 is not NFS4_UINT64_MAX, then the returned layout
length is equal to the sum of the lo_length fields of each length is equal to the sum of the lo_length fields of each
element of logr_layout. element of logr_layout.
The logr_return_on_close result field is a directive to return the The logr_return_on_close result field is a directive to return the
layout before closing the file. When the metadata server sets this layout before closing the file. When the metadata server sets this
return value to TRUE, it MUST be prepared to recall the layout in the return value to TRUE, it MUST be prepared to recall the layout in the
case the client fails to return the layout before close. For the case the client fails to return the layout before close. For the
metadata server that knows a layout must be returned before a close metadata server that knows a layout must be returned before a close
of the file, this return value can be used to communicate the desired of the file, this return value can be used to communicate the desired
behavior to the client and thus remove one extra step from the behavior to the client and thus remove one extra step from the
skipping to change at page 528, line 43 skipping to change at page 528, line 43
Typically, LAYOUTGET will be called as part of a COMPOUND request Typically, LAYOUTGET will be called as part of a COMPOUND request
after an OPEN operation and results in the client having location after an OPEN operation and results in the client having location
information for the file; this requires that loga_stateid be set to information for the file; this requires that loga_stateid be set to
the special stateid that tells the metadata server to use the current the special stateid that tells the metadata server to use the current
stateid, which is set by OPEN (see Section 16.2.3.1.2) . A client stateid, which is set by OPEN (see Section 16.2.3.1.2) . A client
may also hold a layout across multiple OPENs. The client specifies a may also hold a layout across multiple OPENs. The client specifies a
layout type that limits what kind of layout the metadata server will layout type that limits what kind of layout the metadata server will
return. This prevents metadata servers from granting layouts that return. This prevents metadata servers from granting layouts that
are unusable by the client. are unusable by the client.
As indicated by Table 21 and Table 22 the specification of LAYOUTGET As indicated by Table 12 and Table 13 the specification of LAYOUTGET
allows a pNFS client and server considerable flexibility. A pNFS allows a pNFS client and server considerable flexibility. A pNFS
client can take several strategies for sending LAYOUTGET. Some client can take several strategies for sending LAYOUTGET. Some
examples are as follows. examples are as follows.
o If LAYOUTGET is preceded by OPEN in the same COMPOUND request, and o If LAYOUTGET is preceded by OPEN in the same COMPOUND request, and
the OPEN requests read access, the client might opt to request a the OPEN requests read access, the client might opt to request a
_READ layout with loga_offset set to zero, loga_minlength set to _READ layout with loga_offset set to zero, loga_minlength set to
zero, and loga_length set to NFS4_UINT64_MAX. If the file has zero, and loga_length set to NFS4_UINT64_MAX. If the file has
space allocated to it, that space is striped over one or more space allocated to it, that space is striped over one or more
storage devices, and there is either no conflicting layout, or the storage devices, and there is either no conflicting layout, or the
skipping to change at page 557, line 51 skipping to change at page 557, line 51
into a single RPC request. The client interprets each of the into a single RPC request. The client interprets each of the
operations in turn. If an operation is executed by the client and operations in turn. If an operation is executed by the client and
the status of that operation is NFS4_OK, then the next operation in the status of that operation is NFS4_OK, then the next operation in
the CB_COMPOUND procedure is executed. The client continues this the CB_COMPOUND procedure is executed. The client continues this
process until there are no more operations to be executed or one of process until there are no more operations to be executed or one of
the operations has a status value other than NFS4_OK. the operations has a status value other than NFS4_OK.
19.2.5. ERRORS 19.2.5. ERRORS
CB_COMPOUND will of course return every error that each operation on CB_COMPOUND will of course return every error that each operation on
the backchannel can return (see Table 13). However if CB_COMPOUND the backchannel can return (see Table 7). However if CB_COMPOUND
returns zero operations, obviously the error returned by COMPOUND has returns zero operations, obviously the error returned by COMPOUND has
nothing to do with an error returned by an operation. The list of nothing to do with an error returned by an operation. The list of
errors CB_COMPOUND will return if it processes zero operations errors CB_COMPOUND will return if it processes zero operations
include: include:
CB_COMPOUND error returns CB_COMPOUND error returns
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| Error | Notes | | Error | Notes |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
skipping to change at page 558, line 28 skipping to change at page 558, line 28
| NFS4ERR_INVAL | The tag argument is not in UTF-8 | | NFS4ERR_INVAL | The tag argument is not in UTF-8 |
| | encoding. | | | encoding. |
| NFS4ERR_MINOR_VERS_MISMATCH | | | NFS4ERR_MINOR_VERS_MISMATCH | |
| NFS4ERR_SERVERFAULT | | | NFS4ERR_SERVERFAULT | |
| NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_TOO_MANY_OPS | |
| NFS4ERR_REP_TOO_BIG | | | NFS4ERR_REP_TOO_BIG | |
| NFS4ERR_REP_TOO_BIG_TO_CACHE | | | NFS4ERR_REP_TOO_BIG_TO_CACHE | |
| NFS4ERR_REQ_TOO_BIG | | | NFS4ERR_REQ_TOO_BIG | |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Table 23 Table 14
20. NFSv4.1 Callback Operations 20. NFSv4.1 Callback Operations
20.1. Operation 3: CB_GETATTR - Get Attributes 20.1. Operation 3: CB_GETATTR - Get Attributes
20.1.1. ARGUMENT 20.1.1. ARGUMENT
struct CB_GETATTR4args { struct CB_GETATTR4args {
nfs_fh4 fh; nfs_fh4 fh;
bitmap4 attr_request; bitmap4 attr_request;
skipping to change at page 587, line 22 skipping to change at page 587, line 22
[5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version [5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version
5 Generic Security Service Application Program Interface (GSS- 5 Generic Security Service Application Program Interface (GSS-
API) Mechanism Version 2", RFC 4121, July 2005. API) Mechanism Version 2", RFC 4121, July 2005.
[6] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism [6] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism
Using SPKM", RFC 2847, June 2000. Using SPKM", RFC 2847, June 2000.
[7] Linn, J., "Generic Security Service Application Program [7] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[8] Talpey, T. and B. Callaghan, "RDMA Transport for ONC RPC - A [8] Talpey, T. and B. Callaghan, "Remote Direct Memory Access
Work in Progress", Internet Draft draft-ietf-nfsv4-rpcrdma-06, Transport for Remote Procedure Call",
May 2007. draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008.
[9] Talpey, T. and B. Callaghan, "NFS Direct Data Placement - A [9] Talpey, T., Callaghan, B., and I. Property, "NFS Direct Data
Work in Progress", Internet Placement", draft-ietf-nfsv4-nfsdirect-08 (work in progress),
Draft draft-ietf-nfsv4-nfsdirect-06, May 2007. April 2008.
[10] Recio, P., Metzler, B., Culley, P., Hilland, J., and D. Garcia, [10] Recio, P., Metzler, B., Culley, P., Hilland, J., and D. Garcia,
"A Remote Direct Memory Access Protocol Specification", "A Remote Direct Memory Access Protocol Specification",
RFC 5040, October 2007. RFC 5040, October 2007.
[11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[12] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1 [12] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1
XDR Description A Work in Progress", Internet XDR Description", draft-ietf-nfsv4-minorversion1-dot-x-07 (work
Draft draft-ietf-nfsv4-minorversion1-dot-x-04.txt, in progress), May 2008.
December 2007.
[13] Hinden, R. and S. Deering, "IP Version 6 Addressing [13] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 4291, February 2006.
[14] International Organization for Standardization, "Information [14] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS) Technology - Universal Multiple-octet coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane", - Part 1: Architecture and Basic Multilingual Plane",
ISO Standard 10646-1, May 1993. ISO Standard 10646-1, May 1993.
[15] Alvestrand, H., "IETF Policy on Character Sets and Languages", [15] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998. BCP 18, RFC 2277, January 1998.
[16] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [16] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
skipping to change at page 588, line 21 skipping to change at page 588, line 21
[18] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms [18] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005. Revocation List (CRL) Profile", RFC 4055, June 2005.
[19] National Institute of Standards and Technology, "Cryptographic [19] National Institute of Standards and Technology, "Cryptographic
Algorithm Object Registration", December 2005. Algorithm Object Registration", December 2005.
[20] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [20] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
October 1998.
23.2. Informative References 23.2. Informative References
[21] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [21] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M., and D. Noveck, "Network File System (NFS) C., Eisler, M., and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3530, April 2003. version 4 Protocol", RFC 3530, April 2003.
[22] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 [22] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3
Protocol Specification", RFC 1813, June 1995. Protocol Specification", RFC 1813, June 1995.
skipping to change at page 589, line 7 skipping to change at page 589, line 6
[27] Werme, R., "RPC XID Issues", USENIX Conference Proceedings , [27] Werme, R., "RPC XID Issues", USENIX Conference Proceedings ,
February 1996. February 1996.
[28] Nowicki, B., "NFS: Network File System Protocol specification", [28] Nowicki, B., "NFS: Network File System Protocol specification",
RFC 1094, March 1989. RFC 1094, March 1989.
[29] Bhide, A., Elnozahy, E., and S. Morgan, "A Highly Available [29] Bhide, A., Elnozahy, E., and S. Morgan, "A Highly Available
Network Server", USENIX Conference Proceedings , January 1991. Network Server", USENIX Conference Proceedings , January 1991.
[30] Halevy, B., Welch, B., and J. Zelenka, "Object-based pNFS [30] Halevy, B., Welch, B., and J. Zelenka, "Object-based pNFS
Operations", April 2008, <ftp://www.ietf.org/internet-drafts/ Operations", draft-ietf-nfsv4-pnfs-obj-09 (work in progress),
draft-nfsv4-pnfs-obj-07.txt>. June 2008.
[31] Black, D., Fridella, S., and J. Glasgow, "pNFS Block/Volume [31] Black, D., Fridella, S., and J. Glasgow, "pNFS Block/Volume
Layout", April 2008, <ftp://www.ietf.org/internet-drafts/ Layout", draft-ietf-nfsv4-pnfs-block-09 (work in progress),
draft-ietf-nfsv4-pnfs-block-08.txt>. June 2008.
[32] Callaghan, B., "WebNFS Client Specification", RFC 2054, [32] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996. October 1996.
[33] Callaghan, B., "WebNFS Server Specification", RFC 2055, [33] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. October 1996.
[34] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, [34] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624,
June 1999. June 1999.
skipping to change at page 592, line 9 skipping to change at page 592, line 9
were: Andy Adamson, Mike Eisler, Sam Falkner, Garth Goodson, Robert were: Andy Adamson, Mike Eisler, Sam Falkner, Garth Goodson, Robert
Gordon, Trond Myklebust, Dave Noveck Spencer Shepler, Tom Talpey, Amy Gordon, Trond Myklebust, Dave Noveck Spencer Shepler, Tom Talpey, Amy
Weaver, and Lisa Week. Weaver, and Lisa Week.
Others who provided comments include: Jason Goldschmidt and Mahesh Others who provided comments include: Jason Goldschmidt and Mahesh
Siddheshwar. Siddheshwar.
Authors' Addresses Authors' Addresses
Spencer Shepler Spencer Shepler
Sun Microsystems, Inc. Storspeed, Inc.
7808 Moonflower Drive 7808 Moonflower Drive
Austin, TX 78750 Austin, TX 78750
USA USA
Phone: +1-512-401-1080 Phone: +1-512-402-5811 ext 8530
Email: spencer.shepler@sun.com Email: shepler@storspeed.com
Mike Eisler Mike Eisler
NetApp NetApp
5765 Chase Point Circle 5765 Chase Point Circle
Colorado Springs, CO 80919 Colorado Springs, CO 80919
USA USA
Phone: +1-719-599-9026 Phone: +1-719-599-9026
Email: mike@eisler.com Email: mike@eisler.com
URI: http://www.eisler.com URI: http://www.eisler.com
skipping to change at page 593, line 44 skipping to change at line 27527
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 61 change blocks. 
88 lines changed or deleted 82 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/