Subject: [nfsv4] [[email-masked]: New Version Notification for draft-hellwig-nfsv4-rfc5663bis-00.txt]

From: Christoph Hellwig <[email-masked]>
Date: Sat, 16 Aug 2014 16:35:44 +0200

I've published a first attempt at starting the bis process for rfc5663.

The major driver for this was that rfc5663 entirely ignores the concept
of volatile write caches on storage devices.  This draft adds simple
language that requires the server to ensure data is on stable storage
after a LAYOUTCOMMIT returns.

The other non-housekeeping change is a much stricter language in section
2.3.5. to enforce the single writer XOR multiple readers exclusion.  The
current text contains a lot of mays but ignores that fact that block devices
generally do not allow byte level access, and thus the server mus
ensure that multiple read-modify-write cycles don't step on each others
toes.

----- Forwarded message from [email-masked] -----

Date: Sat, 16 Aug 2014 03:12:27 -0700
From: [email-masked]
Subject: New Version Notification for draft-hellwig-nfsv4-rfc5663bis-00.txt
To: Christoph Hellwig <[email-masked]>, Christoph Hellwig <[email-masked]>

A new version of I-D, draft-hellwig-nfsv4-rfc5663bis-00.txt
has been successfully submitted by Christoph Hellwig and posted to the
IETF repository.

Name:		draft-hellwig-nfsv4-rfc5663bis
Revision:	00
Title:		Parallel NFS (pNFS) Block/Volume Layout
Document date:	2014-08-16
Group:		Individual Submission
Pages:		27
URL:            http://www.ietf.org/internet-drafts/draft-hellwig-nfsv4-rfc5663bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hellwig-nfsv4-rfc5663bis/
Htmlized:       http://tools.ietf.org/html/draft-hellwig-nfsv4-rfc5663bis-00

Abstract:
   Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to
   allow clients to directly access file data on the storage used by the
   NFSv4 server.  This ability to bypass the server for data access can
   increase both performance and parallelism, but requires additional
   client functionality for data access, some of which is dependent on
   the class of storage used.  The main pNFS operations document
   specifies storage-class-independent extensions to NFS; this document
   specifies the additional extensions (primarily data structures) for
   use of pNFS with block- and volume-based storage.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

---

From: Benny Halevy <[email-masked]>
Date: Sun, 17 Aug 2014 12:49:09 +0300

Christoph, how about submitting errata for RFC5663 to track the required
changes?

Benny

On Sat, Aug 16, 2014 at 5:35 PM, Christoph Hellwig <[email-masked]> wrote:

> URL:
> http://www.ietf.org/internet-drafts/draft-hellwig-nfsv4-rfc5663bis-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hellwig-nfsv4-rfc5663bis/
> Htmlized:
> http://tools.ietf.org/html/draft-hellwig-nfsv4-rfc5663bis-00
>
>
> Abstract:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Benny Halevy <[email-masked]>
Date: Sun, 17 Aug 2014 12:52:00 +0300

Also, one editorial nit: if the intention is rfc5663bis then intended
status should be "Standards Track" rather than "Informational"...

---

From: Christoph Hellwig <[email-masked]>
Date: Mon, 1 Sep 2014 02:03:43 +0200

> Christoph, how about submitting errata for RFC5663 to track the required

Fine with me, but I might need a bit help with the procedura for it.

1) Do you want me to submit my proposed errata to the tracker and go from
   there, or should I post my proposed errata on the mainling list and only
   enter them after we have rough consensus on them?
2) Unlike RFC5661, or RFC5664 there is no actual errata link for RFC5663
   on http://datatracker.ietf.org/wg/nfsv4/documents/ .  What is the
   required procedure to start tracking errata for it?