[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
- [nfsv4] [Technical Errata Reported] RFC5661 (3226) RFC Errata System
- [nfsv4] [Errata Held for Document Update] RFC5661… RFC Errata System
- Re: [nfsv4] [Errata Held for Document Update] RFC… Trond Myklebust