Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc5667bis-08.txt

From: [email-masked]
Date: Tue, 04 Apr 2017 11:44:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 of the IETF.

        Title           : Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version One
        Author          : Charles Lever
	Filename        : draft-ietf-nfsv4-rfc5667bis-08.txt
	Pages           : 18
	Date            : 2017-04-04

Abstract:
   This document specifies Upper Layer Bindings of Network File System
   (NFS) protocol versions to RPC-over-RDMA Version One, enabling the
   use of Direct Data Placement.  This document obsoletes RFC 5667.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5667bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-rfc5667bis-08
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rfc5667bis-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rfc5667bis-08

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Chuck Lever <[email-masked]>
Date: Tue, 4 Apr 2017 14:51:34 -0400

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc5667bis-08.txt
> Date: April 4, 2017 at 2:44:48 PM EDT
> To: <[email-masked]>
> Cc: [email-masked]
> 
> 

I heard no objections to closing Open items 1 and 3 as follows:

1. Remove the ULB for MOUNT, NLM, and NSM, and replace it with a
requirement to provide TCP-based versions of these services.

3. Remove READ_PLUS from the list of operations with DDP-eligible
result data items. Bullet 5 in Section 5.4.1 remains because it
describes the situation where a READ operation returns an error.

rfc5667bis-08 merges these changes.

Open item 2, regarding the use of multiple Read and Write chunks, has
seen no discussion, therefore it remains open. Can we resolve this
item here on the mailing list, or is a design call needed?

Is there any objection to the following solution:

"Server implementations should report ERR_CHUNK (or perhaps GARBAGE_ARGS)
whenever a client has sent more chunks than is supported, or a configuration
of chunks that is unsupported. Implementation guidance should be added to
rfc5667bis to discuss this scenario."

--
Chuck Lever