[nfsv4] [Errata Held for Document Update] RFC5661 (3901)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 25 October 2019 08:33 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 700D112024E; Fri, 25 Oct 2019 01:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THzIqBgff7CP; Fri, 25 Oct 2019 01:33:10 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8FC12001E; Fri, 25 Oct 2019 01:33:10 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 85D12F4071F; Fri, 25 Oct 2019 01:33:10 -0700 (PDT)
To: trond.myklebust@primarydata.com, shepler@storspeed.com, mike@eisler.com, dnoveck@netapp.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: magnus.westerlund@ericsson.com, iesg@ietf.org, nfsv4@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20191025083310.85D12F4071F@rfc-editor.org>
Date: Fri, 25 Oct 2019 01:33:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/6KMY8Y7mYWfWQnYZObzvcXPCSmk>
Subject: [nfsv4] [Errata Held for Document Update] RFC5661 (3901)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 25 Oct 2019 08:33:12 -0000

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

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid3901

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Trond Myklebust <trond.myklebust@primarydata.com>
Date Reported: 2014-02-25
Held by: Magnus Westerlund (IESG)

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 when the client returns all open/delegation
state for that file.

Once a LAYOUTGET operation returns with logr_return_on_close
set to TRUE for a given file, then all subsequent LAYOUTGET
requests by that client for the same file and layout type, MUST
reply with logr_return_on_close set to TRUE until the client returns
all its open state for that file using CLOSE and DELEGRETURN.
Note that return_on_close also applies retroactively to all layout
segments retrieved by the client for that file and layout type.

After the client has closed all open stateids and returned the
delegation stateids for a file for which logr_return_on_close
was set to TRUE, the server MUST  invalidate all layout segments
that were  issued to the client for that file. The client MUST NOT
attempt to use that layout or the layout stateid.

If the server needs to revoke all open stateids and delegation
stateids owned by the client for a file for which logr_return_on_close
was set to TRUE, then it MUST also revoke all layout segments of 
type loga_layout_type that were issued for that file to that client, 
and take action to fence the access to the DSes.

Notes
-----
This is intended as a replacement for the errata with id 3226, which is incomplete in that it does not discuss how return-on-close is supposed to work with delegations or with layout revoking.
 --VERIFIER NOTES-- 
 Please get an agreement in the WG and submit an up to date errata, as this text part seems to be under discussion.

2016-06-17: RFC Editor moved from Rejected to Reported per request from AD (Spencer Dawkins).

2019-10-25: TSV AD Magnus Westerlund put this into the Held for document update so that the WG can deal with the consensus deision issues related to this clarification when updating the document. 

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