RFC Errata
Found 11 records.
Status: Verified (4)
RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015
Note: This RFC has been updated by RFC 7931, RFC 8587
Source of RFC: nfsv4 (wit)
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 by RFC 7931, RFC 8587
Source of RFC: nfsv4 (wit)
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, which identified users and groups by 32-bit unsigned user identifiers and group identifiers, owner and group strings that consist of ASCII- encoded decimal numeric values with no leading zeros can be given a special interpretation by clients and servers that choose to provide such support.
It should say:
To provide a greater degree of compatibility with NFSv3, which identified users and groups by 32-bit unsigned user identifiers and group identifiers, owner and group strings that consist of UTF-8 encoded decimal numeric values with no leading zeros can be given a special interpretation by clients and servers that choose to provide such 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 Errors Names in NFSv4 often are UTF-8 strings. However, in order to provide compatibility with NFSv3 and with local filesystems that do not impose any such restrictions on the form of name strings, UTF-8-unaware file systems are supported. For such file systems, the server is, for the most part, unaware of the encoding of names chosen by the client and is therefore unable to support normalization-related processing or case-insensitivity. In order to provide proper support for the errors NFS4ERR_BADCHAR and NFS4ERR_BADNAME, the encoding used by clients MUST use the same encoding as UTF-8 for all printable ASCII characters. For file systems which are UTF-8-aware, when strings are not valid UTF-8 strings, the error NFS4ERR_INVAL results. As a result, clients can determine whether the current file system is UTF-8-aware by looking up a string which is not valid UTF-8 (e..g. the single byte 0x80) and using an error return of NFS4ERR_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 and return this error only in this case. 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 file system as part of a file name. For example, the forward slash is often reserved for use to indicate multiple names within a path, making the creation of 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 a valid name for the 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 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 appropriate normalization, 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.