Hi Suhas - Thanks for your review and comments! My responses are below. > On Jan 27, 2020, at 2:37 PM, Suhas Nandakumar via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Suhas Nandakumar > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-?? > Reviewer: Suhas Nandakumar > Review Date: 2020-01-27 > IETF LC End Date: 2020-01-27 > IESG Telechat date: Not scheduled for a telechat > > Summary: Thanks for the work. This document is clear in the problem to be > solved . This document is ready to be published as it-is, however I do have few > clarification questions for my own understanding > > Major issues: > > Minor issues: > > Nits/editorial comments: > 1. The draft doesn't specify normative procedures on sender/receiver behavior > when certain fields are missing (say size of all zeroes). Should the draft say > recommended procedures for handling these scenarios ? Section 4 defines the format, which is fixed in size. Section 4.1.1 in particular mandates the behavior when a perfectly-formed RPC-over-RDMA private message is not received. Zero is a permitted value for the size fields. Section 5.2 explains how to compute the actual buffer size. If those fields contain zero, the actual send and receive buffer sizes would be 1024 octets. "Recommended procedures" are scattered about, but IMO the cases are covered appropriately. If you see one that isn't, or one that could be made more clear, please let me know. > 2. Also i didn't see fallback procedures to be followed when the server > reported size isn't of much use to the sender of the data . In such case the > sender might decide to go with existing explicit RDMA data transfer operations > instead of failing the connection ? If I understand your question, you mean when an RPC message to be transmitted is larger than the buffer sizes reported in the private data. Section 3.5 of RFC 8166 explains how the RPC-over-RDMA protocol handles that situation. I see the confusion: Section 3.1 of the current document could be more precise about the risks of exceeding the inline threshold size. The second paragraph could instead read: "If an incoming RDMA message exceeds the size of a receiver's inline threshold, the receive operation fails, and the RDMA provider typically terminates the connection. To convey an RPC message larger than a receiver's inline threshold without risking receive failure, the sender must use explicit RDMA data transfer operations, which are more expensive than RDMA Send." -- Chuck Lever -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
