[nfsv4] AD Evaluation for draft-ietf-nfsv4-rpcrdma-bidirection-05

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Spencer (S),

I think this catches me up on nfsv4 AD Evaluations ...

Again, this draft was pretty clear to me, but I did have some questions
about wording, that I'd like people to look at, before requesting IETF Last
Call.

Spencer (S), could you let me know when this draft is good to go?

Thanks!

Spencer (D)

--- AD Evaluation

Could you spell out "Parallel NFS" on first use of pNFS? Or whatever pNFS
stands for :-)

Probably just for my benefit, but since you mention NAT routers in this
text,

   To facilitate operation through NAT routers, all NFSv4.1 transport
   connections are initiated by NFSv4.1 clients.  Therefore NFSv4.1
   servers send callbacks to clients in the backward direction on
   connections established by NFSv4.1 clients.

is it obvious which end has responsibility for NAT binding keep-alives? I'm
guessing that's a client responsibility, but that's just a guess.

In Sections 4.3.1 and 4.3.2, I THINK you're saying that clients and servers
both need to pre-post more receive buffers to accommodate bidirectional
operation, but that's more clear in 4.3.1,

   To receive incoming backward direction Calls, an RPC-over-RDMA client
   endpoint must pre-post enough additional receive buffers to match its
   advertised backward direction credit value.  Each outstanding forward
   direction RPC requires an additional receive buffer above this
   minimum.

than the corresponding text in 4.3.2,

   To receive incoming backward direction replies, an RPC-over-RDMA
   server endpoint must pre-post a receive buffer for each backward
   direction Call it sends.

because "additional" appears twice in the text on 4.3.1, but doesn't appear
at all in 4.3.2. If this is as symmetrical as I'm thinking it is, perhaps
it's clearer to use similar wording in both places.

In this text,

   When message direction is not fully determined by context (e.g.,
   suggested by the definition of the RPC-over-RDMA version that is in
   use) or by an accompanying RPC message payload with a call direction
   field, it is not possible for the receiver to tell with certainty
   whether the header credit value is a request or grant.  In such
   cases, the receiver MUST NOT use the header's credit value.

does RDMA work at all, if the credit value can't be used?