Bidirectional Remote Procedure Call on RPC-over-RDMA Transports
draft-ietf-nfsv4-rpcrdma-bidirection-08

Note: This ballot was opened for revision 07 and is now closed.

(Alexey Melnikov; former steering group member) Yes

Yes ( for -07)
No email
send info

(Spencer Dawkins; former steering group member) Yes

Yes ( for -07)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2017-03-01 for -07)
No email
send info
Edit: I meant to add, thanks for a well written and easy to read document!

Some minor comments:

-4.1: This is the first mention of "credits", and there is no definition. I realize that the term is defined in the reference from the previous section. It would be helpful to mention that in the context of that reference.
--  Are there any head-of-line-blocking issues introduced by bidirectional transactions? For example, can a reply get stuck behind requests that are blocked by flow control?

-5.4, 4th paragraph, last sentence: Can a reverse requestor reasonably give up or time out, rather than wait "indefinitely"?

-8:  This implies that reverse direction transactions do not change anything.If that is the case, please say so explicitly. For example, Is there any change to authentication for reverse calls? I am not an expert in direct memory access transport protocols; are there every situation where authentication depends on an initial request from the client?

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-02-28 for -07)
No email
send info
Thanks for taking into account the SecDir review comments.

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection (2017-03-01 for -07)
No email
send info
Thanks for the well written document!

Minor comments:

1) Please double-check if maybe more normative language is needed; maybe some of the lower case musts and shoulds, could/should be upper case, especially in section 4.2 and 4.3...?

2) sec 5.4: I guess if available the requester in reverse direction could also open a TCP connection to retransmit?

3) What's DDP?

4) Are there any security impacts because a connection might stay open longer than previously?

(Stephen Farrell; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -07)
No email
send info