Document: draft-ietf-nfsv4-rpcrdma-07.txt Reviewer: Eric Gray Review Date: 03/17/2008 IETF LC Date: 03/26/2008 IESG Telechat Date: 04/24/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. ======================================================================================= Document: "RDMA Transport for ONC RPC" (draft-ietf-nfsv4-rpcrdma-06) Reviewer: Eric Gray Review Date: 10/11/2007 LC End Date: 10/12/2007 Summary: Not ready for publishing as a Proposed Standard. Comments: ======== I believe the RFC Editor's policy is to insist that the title of an RFC uses plain-old English (not dense-mode acronymish) words. Similarly, it should not be necessary to consult an acronym list in order to read the abstract. Not that there is one (list of acronyms - or LOA). Please expand at least the first occurrence of all acronyms in the draft. In the RDMA case, the very first expansion of this acronym that I was able to find was in the references section (section 15). ONC and RPC are not exanded at all in the draft (near as I can tell - I gave up after many, many instances of RPC and I am sure I did not see an expansion for ONC). To be fair, a definition is indirectly provided for "ONC RPC" and "ONC" does not appear by itself in the document. RPC does. As an aside (defense of authors), I am reasonably sure these terms (well, two of them anyway) are very well known and not at all ambiguous. RDMA is the "R" form of "DMA" (does that mean that RPC is the "R" form of "PC"?) and RPC is commonly used - almost as if it were comprehensible English. None-the-less, as an output of the IETF, it is in our best interest to ensure we produce documents that at least give the appearance of being readable by the naïve implementer. I did not explicitly check for other incomprehensible acronyms, though I am fairly certain there are others. ________________________________________________________________ On page 7, I cannot parse the statement: "It is however OPTIONAL that the server always be prepared to receive a request from each client, for example when the server is busy processing all granted client requests." What does it mean to say it is optional to "always be " - is it optional, or is this trying to say "if you do , you MUST always do "? ________________________________________________________________ In the IANA considerations section, you state that the means by which values (presumably in general, though you cite this specific case) are added to RPC netid registry is out of scope for this document. You further explicitly imply that this is a job for IANA. I doubt that. Generally speaking, IANA will seek guidance from the IETF, the IESG, or some specifically approved RFC in determining methods to be used for managing number and name spaces. This is not - as far as I know - something that IANA should be comfortable with doing on their own. Hence, this document MUST cite an explicit reference IANA is to use - if not this document itself - in adding entries to a registry. ________________________________________________________________ Questions: ========= How does this relate to the "ONC RPC reference implementation" described at "http://sourceforge.net/projects/nfs-rdma/"? Is this the same, or a compatible proposal? Are we potentially being asked to standardize a version that isn't compatible with (what appears to be) an open-source version? Or are these not related at all? If they're not related, how is that the case? _______________________________________________________________ What does the parenthesized reference to "ppp" mean in the last couple of lines on page 17? _______________________________________________________________ In the Security section, second paragraph, what is meant by "end-to-end integrity"? _______________________________________________________________ NITs: ==== Page 3, 3rd paragraph: "either UDP or TCP alone" (not "and"). ________________________________________________________________ On page 5, is "filehandle" supposed to be a word, or a variable name? ________________________________________________________________ Section 3.4, third paragraph: "that may attain substantial size" (not which - unless you want to make this phrase parenthetical, which I do not think you can do and still be able to read this sentence correctly). _________________________________________________________________ Page 13, 3rd paragraph: "a non-4-byte" (not "an"). _________________________________________________________________ Section 5.2, next-to-last paragraph, page 26: "applications" (not "application") - to agree in number with "anticipate" and "have".