Subject: [nfsv4] [Editorial Errata Reported] RFC5661 (2006)

From: RFC Errata System <[email-masked]>
Date: Sun, 17 Jan 2010 08:48:29 -0800 (PST)

The following errata report has been submitted 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=2006

--------------------------------------
Type: Editorial
Reported by: Michael Eisler <[email-masked]>

Section: 15.1.1.3

Original Text
-------------
For any of a number of reasons, the replier could not process this
   operation in what was deemed a reasonable time.  The client should
   wait and then try the request with a new slot and sequence value.

   Some examples of scenarios that might lead to this situation:

   o  A server that supports hierarchical storage receives a request to
      process a file that had been migrated.

   o  An operation requires a delegation recall to proceed, and waiting
      for this delegation recall makes processing this request in a
      timely fashion impossible.

   In such cases, the error NFS4ERR_DELAY allows these preparatory
   operations to proceed without holding up client resources such as a
   session slot.  After delaying for period of time, the client can then
   re-send the operation in question (but not with the same slot ID and
   sequence ID; one or both MUST be different on the re-send).

   Note that without the ability to return NFS4ERR_DELAY and the
   client's willingness to re-send when receiving it, deadlock might
   result.  For example, if a recall is done, and if the delegation
   return or operations preparatory to delegation return are held up by
   other operations that need the delegation to be returned, session
   slots might not be available.  The result could be deadlock.

Corrected Text
--------------
For any of a number of reasons, the replier could not process this
   operation in what was deemed a reasonable time.  The requester should
   wait and then try the request with a new slot and sequence value.

   Some examples of scenarios that might lead to this situation:

   o  A server that supports hierarchical storage receives a request to
      process a file that had been migrated.

   o  An operation requires a delegation recall to proceed, and waiting
      for this delegation recall makes processing this request in a
      timely fashion impossible.

   In such cases, the error NFS4ERR_DELAY allows these preparatory
   operations to proceed without holding up requester resources such as a
   session slot.  After delaying for period of time, the requester can then
   re-send the operation in question. If the operation that returned
   NFS4ERR_DELAY was not a Sequence operation, the initial, preceding 
   Sequence operation of the Compound request MUST NOT be re-sent with same 
   slot ID and sequence ID; one or both MUST be different on the re-send. If
   the operation that returned NFS4ERR_DELAY was a Sequence operation, then
   the Sequence MUST be re-sent with the same slot ID and sequence ID.

   Note that without the ability to return NFS4ERR_DELAY and the
   requester's willingness to re-send when receiving it, deadlock might
   result.  For example, if a recall is done, and if the delegation
   return or operations preparatory to delegation return are held up by
   other operations that need the delegation to be returned, session
   slots might not be available.  The result could be deadlock.

Notes
-----
This errata is correcting two problems:

(1) The use of term "requester" instead of "client" since NFS4ERR_DELAY
    is applicable for both the backchannel and fore channel.

(2) Clarification that NFS4ERR_DELAY from a Sequence operation is handled 
    differently from non-Sequence operations.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

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