RFC Errata
Found 10 records.
Status: Verified (2)
RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015
Source of RFC: nfsv4 (tsv)
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/>.
Status: Reported (8)
RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015
Source of RFC: nfsv4 (tsv)
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: 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.
Errata ID: 5471
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-18
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
Errata ID: 5472
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-18
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