Document:   draft-ietf-ipoib-connected-mode-02.txt
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date:  Wednesday 2/15/2006 6:16 PM CST
IETF LC Date:  15 February 2006

Summary: This document is on the right track for publication as a Proposed 
Standard. I do have some comments, but overall the document is in good 
shape.

Specific review comments:

There are a couple of places in the document that refer to 2^31-octet link 
MTUs for connected-mode Infiniband), and then talk about "reasonably large 
MTUs" without qualification. I would be more comfortable if the text talked 
about "reasonably large MTUs, up to the 64-kilobyte maximum IP length", just 
to manage expectations more clearly.

The document does attempt to explain "why use connected mode if datagram 
mode is most appropriate for IP?". The introduction names two advantages of 
connected mode (larger MTUs and enhanced reliability), but it would be nice 
to be a bit clearer ("These are the advantages of Infiniband connected mode 
over datagram mode:") - I'm not even sure from the text if these are the 
only advantages or not.

The document does talk about retransmission timer interaction with TCP RTO 
(in Section 7.1), and this is good, but the text suggests "the RC timers as 
well as the maximum message size supported at the IPoIB-RC connection must 
be set judiciously". This is actually harder than it looks, because TCP RTO 
is adaptive (with a minumum value of one second), so it would be nice to 
offer a little more guidance on selecting RC timer values.

In Section 8.0, Security Considerations, "A node may be returned a false set 
of flags by an imposter" is just a little too out-of-context for me to 
parse. Naming the operation being attacked and/or the message containing the 
false set of flags would help.

Editorial comments noticed during Gen-ART review:

In the second sentence of the Introduction, "The document [IPoIB_ARCH] 
provides" is awkward - the style used in the first sentence, "The InfiniBand 
specification [IB_ARCH] can be found" is clearer to me (this is a nit).