Subject: [nfsv4] [Errata Verified] RFC5661 (3208)

From: RFC Errata System <[email-masked]>
Date: Wed, 16 Dec 2015 14:01:55 -0800 (PST)

The following errata report has been verified for RFC5661,
"Network File System (NFS) Version 4 Minor Version 1 Protocol". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5661&eid=3208

--------------------------------------
Status: Verified
Type: Technical

Reported by: Benny Halevy <[email-masked]>
Date Reported: 2012-05-02
Verified by: Martin Stiemerling (IESG)

Section: GLOBAL

Original Text
-------------

Corrected Text
--------------

Notes
-----
Section 12.5.2. says:
   The first successful LAYOUTGET
   processed by the server using a non-layout stateid as an argument
   MUST have the "seqid" field of the layout stateid in the response set
   to one.  Thereafter, the client MUST use a layout stateid (see
   Section 12.5.3) on future invocations of LAYOUTGET on the file, and
   the "seqid" MUST NOT be set to zero.

It should say:
   The first successful LAYOUTGET
   processed by the server using a non-layout stateid as an argument
   MUST have the "seqid" field of the layout stateid in the response set
   to one.  Thereafter, the client MUST use a layout stateid (see
   Section 12.5.3) on future invocations of LAYOUTGET on the file, and
   the "seqid" MUST NOT be set to zero.
|  The client MUST serialize LAYOUTGET operations using a non-layout
|  stateid with any other operation affecting the layout state on the file,
|  including CB_LAYOUTRECALL, to allow consistent initialization of the
|  layout state.

Add the following paragraph to section 12.5.3.:
|  A client MAY always forget its layout state and associated
|  layout stateid at any time (See also section 12.5.5.1).
|  In such case, the client MUST use a non-layout stateid for the next
|  LAYOUTGET operation.  This will signal the server that the client has
|  no more layouts on the file and its respective layout state can be
|  released before issuing a new layout in response to LAYOUTGET.

Section 12.5.5.2.1. says:
   One critical issue with regard to layout operations sequencing
   concerns callbacks.  The protocol must defend against races between
   the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
   CB_LAYOUTRECALL.  A client MUST NOT process a CB_LAYOUTRECALL that
   implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
   to which the client has not yet received a reply.  The client detects
   such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
   layout stateid.  If the "seqid" is not exactly one higher than what
   the client currently has recorded, and the client has at least one
   LAYOUTGET and/or LAYOUTRETURN operation outstanding, the client knows
   the server sent the CB_LAYOUTRECALL after sending a response to an
   outstanding LAYOUTGET or LAYOUTRETURN.

It should say:
   One critical issue with regard to layout operations sequencing
   concerns callbacks.  The protocol must defend against races between
   the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
   CB_LAYOUTRECALL.  A client MUST NOT process a CB_LAYOUTRECALL that
   implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
   to which the client has not yet received a reply.  The client detects
   such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
   layout stateid.  If the "seqid" is not exactly one higher than what
   the client currently has recorded, and the client has at least one
   LAYOUTGET and/or LAYOUTRETURN operation outstanding,
|  or if the client has a outstanding LAYOUTGET with a non-layout stateid,
   the client knows
   the server sent the CB_LAYOUTRECALL after sending a response to an
   outstanding LAYOUTGET or LAYOUTRETURN.

Section 12.5.5.2.1.1. says:
   It is permissible for the client to send multiple parallel LAYOUTGET
   operations for the same file or multiple parallel LAYOUTRETURN
   operations for the same file or a mix of both.

It should say:
    It is permissible for the client to send multiple parallel LAYOUTGET
    operations for the same file
|   using the layout stateid
    or multiple parallel LAYOUTRETURN
    operations for the same file or a mix of both.

Section 12.5.5.2.1.2. says:
   Note
   that in the first case, the "seqid" in the layout stateid of the
   recall is two greater than what the client has recorded;

It should say:
   Note
   that in the first case, the "seqid" in the layout stateid of the
   recall is two greater than what the client has recorded,
|  or the client has an outstanding LAYOUTGET using a non-layout stateid;

--------------------------------------
RFC5661 (draft-ietf-nfsv4-minorversion1-29)
--------------------------------------
Title               : Network File System (NFS) Version 4 Minor Version 1 Protocol
Publication Date    : January 2010
Author(s)           : S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG