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

From: spencer shepler <[email-masked]>
Date: Mon, 6 May 2019 09:46:14 -0700

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 31st.

The source of the I-D can be found here and comments should be sent to the
WG alias.

https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/

Thanks,

Spencer

---

From: Tom Talpey <[email-masked]>
Date: Thu, 30 May 2019 14:30:52 -0400

On 5/6/2019 12:46 PM, spencer shepler wrote:
> 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.

Tom.