Hi, authors, while you're getting ready to engage with Lisa on her DISCUSS, please also review the gen-art review below and send me an RFC Editor Note with any changes you'd like to make.
Lars On 2008-3-27, at 13:20, ext Eric Gray wrote: > Author(s), > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-nfsv4-rpcrdma-07.txt > > Reviewer: Eric Gray > Review Date: 03/17/2008 > > Summary: > > This document is nearly ready to publish as a Proposed Standard > RFC. > > COMMENTS/QUESTIONS > ================== > > In the first paragraph of section 3, there is some text about > the fact that the RDMA header is analogous to record marking, > as used for RPC over TCP, but is more extensive, because "RDMA > transports support several modes of data transfer" and we want > to allow the client and server to use efficient transfer modes. > > Is the transfer mode negotiable between the client and server, > or are more efficient modes simply well enough defined that > either could make this decision on its own? > __________________________________________________________________ > > In the last paragraph before section 3.1, you include this > (paraphrased) text: > > "An upper layer may [...] define an exchange to dynamically > enable RPC/RDMA on an existing RPC association. Any such > exchange must be carefully architected so as to prevent any > ambiguity as to the framing in use for each side of the > connection." > > This does not look like the sort of statement we should be > making in a proposed standard. The entire (paraphrased) > quote above - especially the phrase "must be carefully > architected" - is at least a little too vague. Does this > specification (or another) provide support for this as an > option? Are there pre-conditions and signaling needs at > the higher layer? Or, is it enough simply to say that the > same approach must be consistently used within any single > message? > > It sounds like this is something that needs to be defined at > a specific level (such as at the application level) and that > entities at that level need to ensure that specific things > are correctly handled. In this case, I'm being vague because > I don't know the protocols involved well enough to be more > specific about what "specific things" and "correctly handled" > mean - but I strongly suspect that "carefully architected" > doesn't cover it. > > My suggestion is to remove (or rephrase) the last 3 sentences > in that paragraph, including the two paraphrased above and the > one that follows them. > __________________________________________________________________ > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
