thanks. I'm catching up a bit late and I see some responses. Responding to this mail since it covers all review comments. I'll make all changes togehter with other IESG comments. See comments below marked by <VK>.
Vivek
--
Vivek Kashyap
Linux Technology Center, IBM
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Ph: 503 578 3422 T/L: 775 3422
| "Spencer Dawkins" <[EMAIL PROTECTED]>
02/15/2006 04:16 PM |
To: "General Area Review Team" <[email protected]> cc: "Margaret Wasserman" <[EMAIL PROTECTED]>, "H.K. Jerry Chu" <[EMAIL PROTECTED]>, "Bill Strahm" <[EMAIL PROTECTED]>, Vivek Kashyap/Beaverton/[EMAIL PROTECTED] Subject: Gen-ART Review of draft-ietf-ipoib-connected-mode-02.txt |
I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
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.
<VK> :) <VK>
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.
<VK> This covers jumbograms as Brian mentioned. In that context we can probably leave the text as it is. <VK>
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.
<VK> ok...can add a list. <VK>
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.
<VK> ok..I'll consult some IB folks and determine how to phrase the guidance. fyi..RC timers are sub-second. <VK>
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.
<VK> ok. <VK>
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).
<VK> will incorporate when above changes are made. <VK>
_______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
