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

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 25 October 2019 08:27 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 62FEE1201DC; Fri, 25 Oct 2019 01:27:30 -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 KgqsNSIzCtcv; Fri, 25 Oct 2019 01:27:29 -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 44B4412001E; Fri, 25 Oct 2019 01:27:29 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 08E17F4071F; Fri, 25 Oct 2019 01:27:29 -0700 (PDT)
To: mre-ietf@eisler.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: <20191025082729.08E17F4071F@rfc-editor.org>
Date: Fri, 25 Oct 2019 01:27:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/6mQ98HS7Er_Zosc-ouU3iE7OQVg>
Subject: [nfsv4] [Errata Held for Document Update] RFC5661 (2505)
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:27:30 -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/eid2505

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

Reported by: Michael Eisler <mre-ietf@eisler.com>
Date Reported: 2010-08-31
Held by: Magnus Westerlund (IESG)

Section: 12.5.4.

Original Text
-------------
   Because of this inconsistency, it is necessary to resynchronize the
   client with the metadata server and its storage devices and make any
   potential changes available to other clients. 

AND

   For file-based layouts, synchronization of
   attributes between the metadata and storage devices, primarily the
   size attribute, is required.


Corrected Text
--------------
   Because of this inconsistency, in general, it is necessary to resynchronize the
   client with the metadata server and its storage devices and make any
   potential changes available to other clients. 

AND

   For file-based layouts, synchronization of
   attributes between the metadata and storage devices, primarily the
   size attribute, is not required, but the use of LAYOUTCOMMIT provides 
   a way to optimize the synchronization. Indeed, if a LAYOUT4_NFSV4_1_FILES
   layout is ever revoked, the metadata server MUST direct all data servers to
   commit any modified data of the file to stable storage, and synchronize 
   the file's size and time_modify attributes on the metadata server
   with the those on the data server.


Notes
-----
Without this correction, the implication is that a file could be truncated if a  LAYOUT4_NFSV4_1_FILES layout was revoked before LAYOUTCOMMIT, which would then mean that every append operation to a data server would require a LAYOUTCOMMIT, which is an absurd consequence.

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