RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

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

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: 5531
Status: Reported
Type: Technical

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

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.

Errata ID: 5471
Status: Reported
Type: Editorial

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

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

Report New Errata