Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-02.txt (Ends May 31st)

Tom Talpey <> Thu, 30 May 2019 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FDFD120046 for <>; Thu, 30 May 2019 11:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B52Spwsm0_zO for <>; Thu, 30 May 2019 11:30:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 458C3120323 for <>; Thu, 30 May 2019 11:30:54 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id WPpFh6woMZelWWPpFhR2Tq; Thu, 30 May 2019 11:30:53 -0700
References: <>
From: Tom Talpey <>
Message-ID: <>
Date: Thu, 30 May 2019 14:30:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfK8+GKOR84GtverxhQ5zpPP6+Myk3xrNHF32GbXKkpFtEtRdHRgev4jxOPS2TeEAisM3f6qkCyJaZw4H9GC22g5ERaNqB/rAsSfC5EqvofnBTvtEMj8R 5SEBQ4O5G1WWPhnMn+FSpwHXuY6xz6h4CBulRARswUOQEK5IzUiwGS0A
Archived-At: <>
Subject: Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-02.txt (Ends May 31st)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 May 2019 18:31:02 -0000

On 5/6/2019 12:46 PM, spencer shepler wrote:
> All,
> Thanks to Chuck, we have the following I-D entering working group last call.
> “RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1”
> We will start the review today and end on May 31^st .
> The source of the I-D can be found here and comments should be sent to 
> the WG alias.

I have some comments on final review.

In the Abstract, it should be stated that the addition of the
private data payload specified in the draft is an optional
extension, and that the rpcrdmav1 protocol does not require it.

In the Introduction final paragraph the statement "The message
format can be extended as needed" is perhaps overly broad. I think
the better way to state what is meant here is that the specification
is intended to be further extensible, within the normal scope of
such IETF work, and it defines an IANA registry for this. A forward
reference to section 5 would help.

In section 3.2 third paragraph two comments. First, it describes an
advantage of avoiding a context switch. This is a local implementation
matter, and not really something the protocol can or cannot proscribe.
It would be state the benefit in protocol terms, such as "avoids
processing of the invalidate completion", then go on to say which may
enable avoiding interrupt(s) and context switch(es). Second, a nit - the
word "upshot" is slang. Suggest "benefit".

At the end of section 3.2, the final paragraph is quite mysterious. It
refers to "a simple signaling mechanism" and "some NFS/RDMA client".
Really, something more needs to be said here. If this signaling
mechanism involves a protocol payload, then definitely so. Can you
elaborate? I admit I don't fully understand what is meant here.

In section 4, the scope of the properties are correctly confined to
the connection on which they are exchanged. But, this does not mention
the visibility of the properties to the upper layer consumer, which
must be aware of them, especially when reconnecting since RDMA behaviors
may change. I suggest a short statement in sectin 4.1 Interoperability
Considerations to this point.

In section 7, the vulnerability is in the RDMA-CM protocol, not this
protocol. And, private data is carried differently by different lower
layers - for example in the IETF iWARP family, it's part of MPA.
Honestly, I'm not sure this is relevant to this document. It basically
inherits all the considerations of the protocols it extends.