RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 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

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

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 (5)

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

Source of RFC: nfsv4 (tsv)

Errata ID: 4639
Status: Reported
Type: Technical

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

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

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: 4828
Status: Reported
Type: Editorial

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

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