RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 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 (4)

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



Search RFCs
Advanced Search
×