[nfsv4] [Technical Errata Reported] RFC5661 (3226)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 10 May 2012 16:52 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEE621F84F0 for <nfsv4@ietfa.amsl.com>; Thu, 10 May 2012 09:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.402
X-Spam-Level:
X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9itj4sK3TnW for <nfsv4@ietfa.amsl.com>; Thu, 10 May 2012 09:52:18 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 463BE21F84C8 for <nfsv4@ietf.org>; Thu, 10 May 2012 09:52:18 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id CF52262180; Thu, 10 May 2012 09:49:56 -0700 (PDT)
To: shepler@storspeed.com, mike@eisler.com, dnoveck@netapp.com, wes@mti-systems.com, martin.stiemerling@neclab.eu, spencer.shepler@gmail.com, beepy@netapp.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20120510164956.CF52262180@rfc-editor.org>
Date: Thu, 10 May 2012 09:49:56 -0700
X-Mailman-Approved-At: Thu, 10 May 2012 10:46:34 -0700
Cc: eshel@us.ibm.com, nfsv4@ietf.org, rfc-editor@rfc-editor.org
Subject: [nfsv4] [Technical Errata Reported] RFC5661 (3226)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2012 16:52:18 -0000

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

--------------------------------------
Type: Technical
Reported by: Marc Eshel <eshel@us.ibm.com>

Section: 18.43.3

Original Text
-------------
The logr_return_on_close result field is a directive to return the layout 
before closing the file.  When the metadata server sets this  return value
to TRUE, it MUST be prepared to recall the layout in the case in which the
client fails to return the layout before close.  For the metadata server 
that knows a layout must be returned before a close of the file, this 
return value can be used to communicate the desired behavior to the client
and thus remove one extra step from the client's and metadata server's 
interaction.

Corrected Text
--------------
The logr_return_on_close result field is a directive to return or forget 
the layout before closing the file . When the metadata server sets this 
return value to TRUE, the client MUST NOT use the layout and the respective
layout stateid after sending the last CLOSE of that file. Any outstanding
COMMIT to the data servers or LAYOUTCOMMIT to the metadata server MUST be 
sent prior to closing the file. This return value is used to communicate to 
the client that any layout or segment of a layout that were given with 
logr_return_on_close set to TRUE will result in the server invalidating all 
layouts of layouttype4 of loga_layout_type for the file after it was closed. 
Once the server returns logr_return_on_close set to TRUE to a client for a
given file it MUST set logr_return_on_close to TRUE for all subsequent 
layouts or segments of layoutype4 of the respective loga_layout_type for
that file and client until that file is closed.


Notes
-----
This directive will remove one or more extra steps from the client's and 
metadata server's interaction.

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