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 resolve these comments along with any other Last Call comments you may receive. 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 <X>" - is it optional, or is this trying to say "if you do <X>, you MUST always do <X>"? ________________________________________________________________ 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". -- Eric Gray Principal Engineer Ericsson _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
