Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rpcrdma-version-two-01.txt

From: [email-masked]
Date: Fri, 17 Jan 2020 10:11:30 -0800

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 WG of the IETF.

        Title           : RPC-over-RDMA Version 2 Protocol
        Authors         : Charles Lever
                          David Noveck
	Filename        : draft-ietf-nfsv4-rpcrdma-version-two-01.txt
	Pages           : 83
	Date            : 2020-01-17

Abstract:
   This document specifies the second version of a transport protocol
   that conveys Remote Procedure Call (RPC) messages using Remote Direct
   Memory Access (RDMA).  This version of the protocol is extensible.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-rpcrdma-version-two-01
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpcrdma-version-two-01

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

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: Fri, 17 Jan 2020 13:32:06 -0500

Hello-

> On Jan 17, 2020, at 1:11 PM, [email-masked] wrote:
> 
> 

This is a substantially expanded revision of rpcrdma-version-two.
Changes include:

"Short" and "Long" messages have been renamed to encourage
implementers not to think only of RPC message size when choosing
how to convey an RPC message. Also, the discussion now has to
distinguish between using PZRs and Reply chunks v. Message
Continuation for messages that do not fit inline. The new term
is Payload Format. See Section 4.4.

A complete discussion of reverse-direction operation has been
merged into the document. See Section 4.5 and others.

A new section on error handling has been added. The section
fully describes each error and appropriate recovery behaviors
for Requesters and Responders. See Section 7.

The use of compliance keywords is more thrifty throughout.

The text has been thoroughly revised to make it easier to read
by reviewers and implementers.

I've attempted to address editor's notes, although some new ones
have appeared ( [ cel: .... ] ).

The document is now north of 80 pages, even though I'm watching
carefully for redundant text and sections that can be removed.
However the authors believe the proposed protocol is now close
to being feature-complete.

--
Chuck Lever
[email-masked]