Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpcrdma-bidirection-00.txt

From: Chuck Lever <[email-masked]>
Date: Mon, 27 Apr 2015 10:49:06 -0400

Hi-

Here’s revision -00 of an experimental draft that describes how to do
bi-directional RPC on RDMA transports. This is published to enable
others to construct prototypes that can interoperate. It’s about 10
pages, easy to review and comment on.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-cel-nfsv4-rpcrdma-bidirection-00.txt
> Date: April 27, 2015 at 10:43:45 AM EDT
> To: "Charles Lever" <[email-masked]>, "Chuck Lever" <[email-masked]>
> 
> 
> A new version of I-D, draft-cel-nfsv4-rpcrdma-bidirection-00.txt
> has been successfully submitted by Charles Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-rpcrdma-bidirection
> Revision:	00
> Title:		Size-Limited Bi-directional Remote Procedure Call On Remote Direct Memory Access Transports
> Document date:	2015-04-24
> Group:		Individual Submission
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpcrdma-bidirection-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpcrdma-bidirection/
> Htmlized:       http://tools.ietf.org/html/draft-cel-nfsv4-rpcrdma-bidirection-00
> 
> 
> Abstract:
>   Recent minor versions of NFSv4 work best when ONC RPC transports can
>   send ONC RPC calls in both directions.  This document describes
>   conventions that enable RPC-over-RDMA version 1 transport endpoints
>   to interoperate when operation in both directions is necessary.
> 
> 
> 
> 
> 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
> 

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: David Noveck <[email-masked]>
Date: Mon, 27 Apr 2015 15:11:01 -0400

Found nothing major.  A bunch of editorial nits follow.

*Section 1.2*

Suggest replacing the second sentence of the first paragraph by:

When observed, these conventions enable RPC-over-RDMA version 1
endpoints to concurrently handle RPC calls that flow from client to
server and from server to client

Suggest the following possible replacements for the second paragraph:

Because no changes to the RPC-over-RDMA version 1 protocol definition
are needed, this document does not update [RFC5666
<https://tools.ietf.org/html/rfc5666>].

No changes to the RPC-over-RDMA version 1 protocol definition are
needed. Therefore, this document does not update [RFC5666
<https://tools.ietf.org/html/rfc5666>].

I don't see the need for "finally" in the third paragraph.

*Section 1.3.3*

Suggest deleting "Finally," at the start of the sentence.

*Section 1.4.1*

In the second sentence of the fourt*h *paragraph, suggest replacing the
first clause by "There may be a negative effect on performance"

*Section 1.4.2*

In the first sentence of the second paragraph, suggest replacing "are" by
"be".

In the first sentence of the third paragraph:

   - suggest replacing "can signal its peer" by "may indicate to its peer"
   - suggest replacing "by sending" to "when sending"

In the first sentence of the sixth paragraph, suggest replacing "Like" by
"As in".

*Section 1.5.1*

Suggest replacing "We prefer to" by "We will".

*Section 1.5.2*

Suggest replacing "impact" by "negatively affect".

*Section 1.5.3*

Suggest replacing the second paragraph by:

By avoiding use of RDMA transfers, any requirement for the server to
expose its memory to clients is eliminated.  Further, there is no need
to introduce client complexity in order to drive RDMA operations.

*Section 1.5.4*

Suggest replacing the first sentence of the first paragraph by:

The only existing use case for backwards direction ONC RPC messages to
be sent using RDMA transports is the NFSv4.1 backchannel.

In the second sentence of the first paragraph, suggest replacing "leverage"
by "take advantage of"

In the first sentence of the second paragraph, suggest replacing "the
complexity overhead of managing" by 'the additional complexity necessary to
manage".

*Section 2.3*

In the second sentence of the second paragraph:

   - suggest replacing "That way" by "If that is done"
   - suggest replacing "do not" by "would not".

*Section 4*

Suggest replacing "may be challenging in the backwards direction" by "in
the backwards direction may be challenging"

On Mon, Apr 27, 2015 at 10:49 AM, Chuck Lever <[email-masked]>
wrote:

> > Subject: New Version Notification for
> draft-cel-nfsv4-rpcrdma-bidirection-00.txt
> > Title:                Size-Limited Bi-directional Remote Procedure Call
> On Remote Direct Memory Access Transports
> > URL:
> http://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpcrdma-bidirection-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpcrdma-bidirection/
> > Htmlized:
> http://tools.ietf.org/html/draft-cel-nfsv4-rpcrdma-bidirection-00
> >
> >
> > Abstract:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Chuck Lever <[email-masked]>
Date: Mon, 27 Apr 2015 15:14:29 -0400

Thanks, will fold these in.

On replacing “We will,” I was told never to use future tense when writing
in this style. Do you have any opinion on that?

On Apr 27, 2015, at 3:11 PM, David Noveck <[email-masked]> wrote:

> Section 1.2
> When observed, these conventions enable RPC-over-RDMA version 1 endpoints to concurrently handle RPC calls that flow from client to server and from server to client
> 
> Because no changes to the RPC-over-RDMA version 1 protocol definition are needed, this document does not update [RFC5666].
> 
> No changes to the RPC-over-RDMA version 1 protocol definition are needed. Therefore, this document does not update [RFC5666].
> 
> Section 1.3.3
> Section 1.4.1
> In the second sentence of the fourth paragraph, suggest replacing the first clause by "There may be a negative effect on performance"
> 
> Section 1.4.2
> 
> In the first sentence of the second paragraph, suggest replacing "are" by "be".
> 
> 	• suggest replacing "can signal its peer" by "may indicate to its peer"
> 	• suggest replacing "by sending" to "when sending"
> 
> In the first sentence of the sixth paragraph, suggest replacing "Like" by "As in".
> 
> Section 1.5.1
> 
> Section 1.5.2
> Section 1.5.3
> By avoiding use of RDMA transfers, any requirement for the server to expose its memory to clients is eliminated.  Further, there is no need to introduce client complexity in order to drive RDMA operations.
> 
> Section 1.5.4
> 
> The only existing use case for backwards direction ONC RPC messages to be sent using RDMA transports is the NFSv4.1 backchannel.
> 
> 
> In the second sentence of the first paragraph, suggest replacing "leverage" by "take advantage of"
> 
> In the first sentence of the second paragraph, suggest replacing "the complexity overhead of managing" by 'the additional complexity necessary to manage".
> 
> 
> 
> Section 2.3
> 
> 	• suggest replacing "That way" by "If that is done"
> 	• suggest replacing "do not" by "would not".
> Section 4
> 
> Suggest replacing "may be challenging in the backwards direction" by "in the backwards direction may be challenging"
> 
> On Mon, Apr 27, 2015 at 10:49 AM, Chuck Lever <[email-masked]> wrote:
> Hi-
>

---

From: David Noveck <[email-masked]>
Date: Mon, 27 Apr 2015 15:21:51 -0400

I don't have an opinion about that.  If it's an issue, can begin that
paragraph (in 1.5.1) with "We are not altering".

On Mon, Apr 27, 2015 at 3:14 PM, Chuck Lever <[email-masked]> wrote:

> endpoints to concurrently handle RPC calls that flow from client to server
> and from server to client
> >
> are needed, this document does not update [RFC5666].
> >
> needed. Therefore, this document does not update [RFC5666].
> >
> > In the second sentence of the fourth paragraph, suggest replacing the
> expose its memory to clients is eliminated.  Further, there is no need to
> introduce client complexity in order to drive RDMA operations.
> >
> > Section 1.5.4
> >
> > > Title:                Size-Limited Bi-directional Remote Procedure
> Call On Remote Direct Memory Access Transports