RFC Errata
Found 8 records.
Status: Verified (2)
RFC 8881, "Network File System (NFS) Version 4 Minor Version 1 Protocol", August 2020
Source of RFC: nfsv4 (wit)
Errata ID: 7386
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Pali Rohár
Date Reported: 2023-03-13
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-10-30
Section 18.46.3. says:
Operations
other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID,
CREATE_SESSION, and DESTROY_SESSION, MUST NOT appear as the first
operation in a COMPOUND.
It should say:
Operations
other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID,
CREATE_SESSION, DESTROY_SESSION, and DESTROY_CLIENTID, MUST NOT
appear as the first operation in a COMPOUND.
Notes:
Section 18.50.3. DESCRIPTION of DESTROY_CLIENTID says
"DESTROY_CLIENTID MAY be preceded with a SEQUENCE"
and also says
"If DESTROY_CLIENTID is not prefixed by SEQUENCE, it MUST be the only operation in the COMPOUND request"
which implies that DESTROY_CLIENTID can appear as the first (and the only) operation in a COMPOUND.
Errata ID: 7324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: YangJing
Date Reported: 2023-01-29
Verifier Name: RFC Editor
Date Verified: 2023-01-30
Section 4.2.3 says:
FH4_VOL_RENAME The filehandle will expire during rename. This
includes a rename by the requesting client or a rename by any
other client. If FH4_VOL_ANY is set, FH4_VOL_RENAME is redundant.
It should say:
FH4_VOL_RENAME The filehandle will expire during rename. This
includes a rename by the requesting client or a rename by any
other client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME
is redundant.
Notes:
FH4_VOL_ANY is not defined in this document. It should be FH4_VOLATILE_ANY
Status: Reported (6)
RFC 8881, "Network File System (NFS) Version 4 Minor Version 1 Protocol", August 2020
Source of RFC: nfsv4 (wit)
Errata ID: 6308
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Calum Mackay
Date Reported: 2020-10-16
Section 18.32.3 says:
* The server MUST commit the data at a level at least as high as
that committed.
It should say:
* The server MUST commit the data at a level at least as high as
that requested.
Notes:
The meaning is probably obvious, but perhaps a MUST ought
to be unambiguous?
---
editorial: also, the point above this one uses the word "stronger"
where this point uses "high", both for the stability level.
The two lines should probably use the same word.
Errata ID: 6337
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Charles Lever
Date Reported: 2020-11-16
Section 18.33.1 says:
struct gss_cb_handles4 {
rpc_gss_svc_t gcbp_service; /* RFC 2203 */
gsshandle4_t gcbp_handle_from_server;
gsshandle4_t gcbp_handle_from_client;
};
It should say:
struct gss_cb_handles4 {
rpc_gss_service_t gcbp_service; /* RFC 2203 */
gsshandle4_t gcbp_handle_from_server;
gsshandle4_t gcbp_handle_from_client;
};
Notes:
RFC 2203 (and its successors) do not define rpc_gss_svc_t. I believe the rpc_gss_service_t type was intended.
Errata ID: 6865
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2022-02-28
Section 18.25.4 says:
The server MUST NOT delete the directory entry if the reply from OPEN had the flag OPEN4_RESULT_PRESERVE_UNLINKED set.
It should say:
If the reply from OPEN had the flag OPEN4_RESULT_PRESERVE_UNLINKED set, The server MUST NOI delete the file contents until each directory entry is deleted and the file is no longer open.
Notes:
The existing second and third bullets are directly contradictory.
Errata ID: 8021
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ed Schouten
Date Reported: 2024-07-08
Section 8.2.3 says:
In the case of an OPEN, the stateid returned for the open file and not the delegation is used.
It should say:
In the case of an OPEN, the stateid returned for the open file and not the delegation is used, with seqid set to 1 explicitly.
Notes:
There is no guarantee that OPEN always returns an open_stateid with seqid == 1. If the same file already happens to be opened, the file could get upgraded. This means that if the same COMPOUND procedure contains a CLOSE that uses the current stateid (as demonstated in Figure 4), it could end up closing a file unintentionally.
The best course of action would be to require that OPEN always sets the current stateid to one having seqid == 1. That way any attempt to call CLOSE will end up returning NFS4ERR_OLD_STATEID if it turned out the OPEN did an upgrade.
Errata ID: 8022
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ed Schouten
Date Reported: 2024-07-08
Section 8.2.2 says:
In making comparisons between seqids, both by the client in determining the order of operations and by the server in determining whether the NFS4ERR_OLD_STATEID is to be returned, the possibility of the seqid being swapped around past the NFS4_UINT32_MAX value needs to be taken into account. When two seqid values are being compared, the total count of slots for all sessions associated with the current client is used to do this. When one seqid value is less than this total slot count and another seqid value is greater than NFS4_UINT32_MAX minus the total slot count, the former is to be treated as lower than the latter, despite the fact that it is numerically greater.
It should say:
Whatever was stated in RFC 7530 (NFSv4.0), section 9.1.3.
Notes:
The number of slots has no relationship with the maximum drift a seqid value may have:
- A single COMPOUND request could contain many operations that cause the seqid to change. For example, one could craft a single COMPOUND request with many of no-op OPEN_DOWNGRADEs that each increment the seqid.
- Imagine a session with two slots. One slot is used in a tight loop to repeatedly invoke OPEN on many different paths, which unbeknownst to the client all refer to the same (hardlinked) file. If the other slot is used to call CLOSE against the same file, it is not unlikely that the difference between the seqid becomes larger than two.
Errata ID: 6611
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Seman.Shen
Date Reported: 2021-06-16
Section 18.37.3 says:
* Otherwise, the error CB_BACK_CHAN_BUSY SHOULD be returned to indicate that there are CB_COMPOUNDs that need to be replied to.
It should say:
* Otherwise, the error NFS4ERR_BACK_CHAN_BUSY SHOULD be returned to indicate that there are CB_COMPOUNDs that need to be replied to.
Notes:
CB_BACK_CHAN_BUSY is not defined in this document.