Bidirectional Remote Procedure Call on RPC-over-RDMA Transports
draft-ietf-nfsv4-rpcrdma-bidirection-08
Yes
(Alexey Melnikov)
(Spencer Dawkins)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Stephen Farrell)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 07 and is now closed.
Alexey Melnikov Former IESG member
Yes
Yes
(for -07)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(for -07)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -07)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2017-03-01 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2017-02-28 for -07)
Unknown
Thanks for taking into account the SecDir review comments.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-03-01 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -07)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -07)
Unknown