Subject: [nfsv4] [Technical Errata Reported] RFC5661 (3065)

From: RFC Errata System <[email-masked]>
Date: Tue, 27 Dec 2011 12:10:48 -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=3065

--------------------------------------
Type: Technical
Reported by: David Black <[email-masked]>

Section: 12.7.4

Original Text
-------------
      If the metadata server's
      consistency checks on loca_layoutupdate succeed, then the metadata
      server MUST commit the data (as described by the loca_offset,
      loca_length, and loca_layoutupdate fields of the arguments) that
      was written to the storage device. If the metadata server's
      consistency checks on loca_layoutupdate fail, the metadata server
      rejects the LAYOUTCOMMIT operation and makes no changes to the
      file system.  However, any time LAYOUTCOMMIT with loca_reclaim
      TRUE fails, the pNFS client has lost all the data in the range
      defined by <loca_offset, loca_length>.  

Corrected Text
--------------
      If the metadata server's
      consistency checks on loca_layoutupdate succeed, then the metadata
      server MUST commit the changed data that was written to the storage
      device within the scope of the LAYOUTCOMMIT operation.
      If the metadata server's
      consistency checks on loca_layoutupdate fail, the metadata server
      rejects the LAYOUTCOMMIT operation and makes no changes to the
      file system.  However, any time LAYOUTCOMMIT with loca_reclaim
      TRUE fails, the pNFS client may have lost all uncommitted
	data within the scope of the failed LAYOUTCOMMIT operation.  

Notes
-----
Errata 2 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 28 Dec 2011 17:49:22 +0000

I just wanted to point out that one of the lessons learned from 3530bis was that we
needed to apply changes as they were hot and not years later. As the only changes
that are occurring to 5661 are in the errata, I've been compiling them in a repo I
reverse engineered from the official document. I.e., it has all of the changes
applied after Last Call.

As usual, I maintain it on github.com:

https://github.com/loghyr/5661bis

If you create a clone of that repo and make the document(s), you will get a copy
of 5661 and 5662 that incorporate all of the errata that have been submitted to date.

---

From: Benny Halevy <[email-masked]>
Date: Thu, 29 Dec 2011 11:34:11 +0200

+1 :)

Benny

On Wed, Dec 28, 2011 at 7:49 PM, Haynes, Tom <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>