Subject: [Gen-art] Gen-ART LC Review of draft-ietf-nfsv4-rpcrdma-06.txt

From: "Eric Gray" <[email-masked]>
Date: Thu, 11 Oct 2007 10:06:10 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art