Hi Christian,

I very much appreciate many of your textual improvements. However, it is very time consuming for us as reviewers to keep track of such substantial changes. It would have been much easier, if you had contributed your changes in an earlier stage. Anyway, I waded through the changes to revision 3 and will comment only on the things that I don't like (consider everything else as excellent):

I second Torsten's opinion on p. 49, l. 35-37: This reformulation introduces three times the term "complete". Besides this drawback, I also don't see any benefit from this reformulation compared to the previous version. ok, so I reformulated "A nonblocking start call initiates a collective operation, but does not complete it. A separate completion call is needed to complete the operation."

to "A nonblocking start call initiates a collective operation and a completion call might be needed to finish the operation." I introduced "might" because the initialization is allowed to finish the operation (semantically) - think of MPI_COMM_SELF.

p. 50, l. 1-2: Similar problem (i.e. 2x"complete"). May I propose: "The start call returns a request handle, which is eventually passed to a completion call." we should stick to imperative voice in the standard. I think we're not writing a novel and this repetition is acceptable in a technical document.

p. 50, l. 8: The part "unless otherwise specified in, or implied by, the description of the operation" has been added. Seem ok to me at first glance. However, we might re-check if this is really necessary and drop it otherwise. MPI_Ibarrier() specifies this

p. 50, l. 16: This looks quite redundant to me. I'd propose sth. like the following restatement: "Upon completion of a nonblocking collective operation, the MPI_ERROR field...". ah, there is a slight semantic difference between "returning from a completion call" and "completion". I think the current wording is less abiguous.

p. 50, l. 17: The added postfix "to indicate any errors" seems wrong to me because MPI_SUCCESS is also a valid entry for the MPI_ERROR field. I'd propose to simply omit this postfix. However, I'm not 100% sure because the section about the MPI Status object looks quite confusing in this respect. Btw. there exists also an empty status (which sets all 3 fields) - so we might need to reconsider our decision about setting only the error field for nonblocking collective operations. omitting it is a safe way of avoiding mistakes. It's gone now and just says "is set appropriately" which is defined elsewhere.

p. 50, l. 29: "nonblocking collective communications" => "nonblocking collective operations" fixed

p. 50, l. 44: You changed "running time" to "minimal time to completion" - this is _not_ the same thing! I'd strongly prefer to stay with the previous terminology. why? I'll leave it as is for now.

p. 62, l. 36/37: now we have two consecutive "the"s fixed

Updates are in rev. 3. Thanks, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Postdoctoral Researcher Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608