Search RFCs

RFC Editor

Found 11 records.

Status:Verified (4)

RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015

Note: This RFC has been updated byRFC 7931, RFC 8587

Errata ID:4471
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2015-09-12
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 16.10.4. says:

   In the case that the lock is denied, the owner, offset, and length of   a conflicting lock are returned.

It should say:

   In the case that the lock is denied, the owner, offset, length, and   type of a conflicting lock are returned.

Notes:

The locktype in LOCK4denied is not specified for the LOCK operation. See 16.11.4. for similar wording for LOCKT.

Errata ID:4329
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2015-04-07
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17

Section 21.1. says:

   [openg_symlink]              The Open Group, "Section 3.372 of Chapter 3 of Base              Definitions of The Open Group Base Specifications              Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version),              ISBN 1937218287, April 2013, <http://www.opengroup.org/>.

It should say:

   [openg_symlink]              The Open Group, "Section 3.375 of Chapter 3 of Base              Definitions of The Open Group Base Specifications              Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version),              ISBN 1937218287, April 2013, <http://www.opengroup.org/>.

Errata ID:5471
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-18
Verifier Name: RFC Editor
Date Verified: 2024-02-02

Section 16.16.5 says:

 o  NFS4ERR_BAD_RECLAIM is returned if the other error conditions do      not apply and the server has no record of the delegation whose      reclaim is being attempted.

It should say:

 o  NFS4ERR_RECLAIM_BAD is returned if the other error conditions do      not apply and the server has no record of the delegation whose      reclaim is being attempted.

Notes:

The the defined error is NFS4ERR_RECLAIM_BAD


---
RFC Editor Note: This also appears in Section 10.2.1. See https://www.rfc-editor.org/errata/eid5472.

Errata ID:5472
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-18
Verifier Name: RFC Editor
Date Verified: 2024-02-02

Section 10.2.1 says:

   When NFS4ERR_EXPIRED is returned, the server MAY retain information   about the delegations held by the client, deleting those that are   invalidated by a conflicting request.  Retaining such information   will allow the client to recover all non-invalidated delegations   using the claim type CLAIM_DELEGATE_PREV, once the   SETCLIENTID_CONFIRM is done to recover.  Attempted recovery of a   delegation that the client has no record of, typically because they   were invalidated by conflicting requests, will result in the error   NFS4ERR_BAD_RECLAIM.  Once a reclaim is attempted for all delegations   that the client held, it SHOULD do a DELEGPURGE to allow any   remaining server delegation information to be freed.

It should say:

   When NFS4ERR_EXPIRED is returned, the server MAY retain information   about the delegations held by the client, deleting those that are   invalidated by a conflicting request.  Retaining such information   will allow the client to recover all non-invalidated delegations   using the claim type CLAIM_DELEGATE_PREV, once the   SETCLIENTID_CONFIRM is done to recover.  Attempted recovery of a   delegation that the client has no record of, typically because they   were invalidated by conflicting requests, will result in the error   NFS4ERR_RECLAIM_BAD.  Once a reclaim is attempted for all delegations   that the client held, it SHOULD do a DELEGPURGE to allow any   remaining server delegation information to be freed.

Notes:

The defined error code is NFS4ERR_RECLAIM_BAD


--
RFC Editor Note: This also appears in 16.16.5. See https://www.rfc-editor.org/errata/eid5471.

Status:Reported (7)

RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015

Note: This RFC has been updated byRFC 7931, RFC 8587

Errata ID:4639
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Butler
Date Reported: 2016-03-16

Section 5.9 says:

To provide a greater degree of compatibility with NFSv3, whichidentified users and groups by 32-bit unsigned user identifiers andgroup identifiers, owner and group strings that consist of ASCII-encoded decimal numeric values with no leading zeros can be given aspecial interpretation by clients and servers that choose to providesuch support.

It should say:

To provide a greater degree of compatibility with NFSv3, whichidentified users and groups by 32-bit unsigned user identifiers andgroup identifiers, owner and group strings that consist of UTF-8encoded decimal numeric values with no leading zeros can be given aspecial interpretation by clients and servers that choose to providesuch support.

Notes:

The start of section 5.9 says:

The RECOMMENDED attributes "owner" and "owner_group" (and also users
and groups used as values of the who field within nfs4ace structures
used in the acl attribute) are represented in the form of UTF-8
strings.

I believe in the case of the digits 0-9 the ASCII encoding is the same as the UTF-8 encoding but it may cause possible confusion by not maintaining consistency.

Errata ID:4742
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Manju Karthik
Date Reported: 2016-07-15

Section section-6.2. says:

https://tools.ietf.org/html/rfc7530#section-6.2.1   The client can use the OPEN or ACCESS   operations to check access without modifying or reading data or   metadata.

It should say:

   The client can use the OPEN or ACCESS   operations to check access without modifying or reading data.

Notes:

Whenever client does OPEN/ACCESS call, there is an inadvertent change in the Last Access time of the file. Hence we think that the Metadata is modified due to OPEN/ACCESS call. Hence the Suggestion is to change the text as above.

Errata ID:5407
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Viral Mehta
Date Reported: 2018-06-24

Section 16.36 says:

The write   verifier is a cookie that the client can use to determine whether the   server has changed instance (boot) state between a call to WRITE and   a subsequent call to either WRITE or COMMIT.  This cookie must be   consistent during a single instance of the NFSv4 protocol service and   must be unique between instances of the NFSv4 protocol server, where   uncommitted data may be lost.

It should say:

The write   verifier is a cookie that the client can use to determine whether the   server has changed instance (boot) state between a call to WRITE and   a subsequent call to either WRITE or COMMIT.  This cookie must be   consistent during a single instance of the NFSv4 protocol service and   must be unique between instances of the NFSv4 protocol server, where   uncommitted data may be lost. The server implementation should not   assume that the cookie is on per file basis.

Notes:

Different NFS client implementation has chosen to interpret above statement differently. Semantically, it is correct to track cookie on per file basis since both WRITE and COMMIT happens on a single file handle. But, RFC wording says that the cookie should be maintained on a per server instance basis. Either way, I believe the RFC can be more clearer for both client and server implementer.

Errata ID:5531
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sylvain Etienne
Date Reported: 2018-10-16

Section 10.4.6. says:

   o  When the callback path is down, the server MUST NOT revoke the      delegation if one of the following occurs:      *  (...)      *  The client has not issued a RENEW operation for some period of         time after the server attempted to recall the delegation.  This         period of time MUST NOT be less than the value of the         lease_time attribute.

It should say:

   o  When the callback path is down, the server MUST NOT revoke the      delegation if one of the following occurs:      *  (...)      *  The client has not issued a RENEW operation for some period of         time after the server attempted to recall the delegation.  This         period of time MUST be less than the value of the         lease_time attribute.

Notes:

It does not make sense to revoke the delegation before lease_time period expiration and to not revoke it after.

Errata ID:7595
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2023-08-10

Section 13.1.7 says:

13.1.7.  Name Errors   Names in NFSv4 are UTF-8 strings.  When the strings are not of length   zero, the error NFS4ERR_INVAL results.  When they are not valid   UTF-8, the error NFS4ERR_INVAL also results, but servers may   accommodate file systems with different character formats and not   return this error.  Besides this, there are a number of other errors   to indicate specific problems with names.13.1.7.1.  NFS4ERR_BADCHAR (Error Code 10040)   A UTF-8 string contains a character that is not supported by the   server in the context in which it is being used.13.1.7.2.  NFS4ERR_BADNAME (Error Code 10041)   A name string in a request consisted of valid UTF-8 characters   supported by the server, but the name is not supported by the server   as a valid name for current operation.  An example might be creating   a file or directory named ".." on a server whose file system uses   that name for links to parent directories.   This error should not be returned due to a normalization issue in a   string.  When a file system keeps names in a particular normalization   form, it is the server's responsibility to do the appropriate   normalization, rather than rejecting the name.

It should say:

13.1.7.  Name ErrorsNames in NFSv4 often are UTF-8 strings. However, in order to providecompatibility with NFSv3 and with local filesystems that do not impose any suchrestrictions on the form of name strings, UTF-8-unaware file systems aresupported.  For such file systems,  the server is, for the most part, unaware ofthe encoding of names chosen by the client and is therefore unable to supportnormalization-related processing or case-insensitivity.  In order to provideproper support for the errors NFS4ERR_BADCHAR and NFS4ERR_BADNAME, the encodingused by clients MUST use the same encoding as UTF-8 for all printable ASCIIcharacters.For file systems which are UTF-8-aware,  when strings are not valid UTF-8strings,  the error NFS4ERR_INVAL results.  As a result, clients can determinewhether the current file system is UTF-8-aware by looking up a string which isnot valid UTF-8 (e..g. the single byte 0x80)  and using an error return ofNFS4ERR_INVAl as indicating that only valid UTF-8 strings may be used.When a string of length zero is passed, the error NFS4ERR_INVAL also results. but servers may accommodate file systems with different character formats andreturn this error only in this case.  Besides this, there are a number of othererrors to indicate specific problems with names.13.1.7.1.  NFS4ERR_BADCHAR (Error Code 10040)A UTF-8 string contains a character that is not supported by the server filesystem as part of a  file name.  For example, the forward slash is oftenreserved for use to indicate multiple names within a path, making the creationof file or directory names with embedded slashes problematic.13.1.7.2.  NFS4ERR_BADNAME (Error Code 10041)A name string in a request consists of a valid string supported by the server,whether UTF-8 or otherwise, but the name is not supported by the server as avalid name for the current operation.  An example might be creating a file ordirectory named ".." on a server whose file system uses that name for links toparent directories.  This error MUST NOT result in case in which  a (UTF-8-aware) server file system prefers a particular normalization for strings.In such cases, it is the server's responsibility to do the appropriatenormalization, rather than rejecting the name.

Notes:

It has been brought to my attention that there is a fundamental contradiction between the idea
(derived from NFSv3) that file name strings can be opaque, and the existence of the errors
NFS4ERR_BADCHAR and NFS4ERR_BADNAME, which, by their nature presume at least some
knowledge of the character encoding being used.

This has not turned out to be a problem in practice because clients always use encodings that
meet certain criteria explained in the replacement text. However, these criteria need to be
documented clearly and appropriate warnings given. These criteria were observed by
implementers of NFSv3 but are not explicitly mentioned in RFC1813.

Errata ID:4828
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2016-10-11

Section 16.24.4. says:

   The arguments contain a cookie value that represents where the   READDIR should start within the directory.  A value of 0 (zero) for   the cookie is used to start reading at the beginning of the   directory.  For subsequent READDIR requests, the client specifies a   cookie value that is provided by the server in a previous READDIR   request.

It should say:

   The arguments contain a cookie value that represents where the   READDIR should start within the directory.  A value of 0 (zero) for   the cookie is used to start reading at the beginning of the   directory.  For subsequent READDIR requests, the client specifies a   cookie value that is provided by the server in a previous READDIR   reply.

Notes:

The new cookie is provided by the server in a reply, not in a request.

Errata ID:4934
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2017-02-15

Section 9.1.7. says:

   When a request is received, its sequence number (r) is compared to   that of the last one received (L).  Only if it has the correct next   sequence, normally L + 1, is the request processed beyond the point   of seqid checking.  Given a properly functioning client, the response   to (r) must have been received before the last request (L) was sent.

It should say:

   When a request is received, its sequence number (r) is compared to   that of the last one received (L).  Only if it has the correct next   sequence, normally L + 1, is the request processed beyond the point   of seqid checking.  Given a properly functioning client, the response   to (L) must have been received before the subsequent request (r) was   sent.

Report New Errata