IETF Logo Mail Archive

[Gen-art] review of draft-ietf-rddp-rdmap-06.txt

Francis Dupont <Francis.Dupont@point6.net> Mon, 31 July 2006 16:44 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7asG-0002kZ-AK; Mon, 31 Jul 2006 12:44:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7asE-0002kS-UQ for gen-art@ietf.org; Mon, 31 Jul 2006 12:44:10 -0400
Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7asD-0001ZE-7F for gen-art@ietf.org; Mon, 31 Jul 2006 12:44:10 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k6VGi5fR032488; Mon, 31 Jul 2006 18:44:05 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k6VGi0ZL032471; Mon, 31 Jul 2006 18:44:00 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k6VGhxhA090670; Mon, 31 Jul 2006 18:43:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200607311643.k6VGhxhA090670@givry.rennes.enst-bretagne.fr>
rom: Francis Dupont <dupont@givry.rennes.enst-bretagne.fr>
To: gen-art@ietf.org
Date: Mon, 31 Jul 2006 18:43:59 +0200
From: Francis Dupont <Francis.Dupont@point6.net>
X-Virus-Scanned: amavisd-new at enst-bretagne.fr
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: jeff.hilland@hp.com, dave.garcia@hp.com, lars.eggert@netlab.nec.de, bmt@zurich.ibm.com, paul.culley@hp.com, recio@us.ibm.com
Subject: [Gen-art] review of draft-ietf-rddp-rdmap-06.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

I am the assigned Gen-ART reviewer for draft-ietf-rddp-rdmap-06.txt.
For background on Gen-ART, please see the FAQ at
<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.

Summary: not Ready

I have the same concern than for the companion I-D about DDP: the IPsec
part (8.2.2) refers to an obsolete version of IPsec/IKE.

Detailed comments:
 - i.e. -> i.e., and e.g. -> e.g.,

 - 1.2 page 7: With -> with

 - 1.3 figure 2 page 11: I suggest to add // and lines to the payload.

 - 3.2 page 26: what is the "yesSTag" (IMHO there is a typo)?

 - 4.1 page 28: what are IETF RNICs and RDMA RNICs (and for the second
   the "R" in RNIC stands for RDMA, doesn't it)?

 - 4.4 pages 32/33: the title "RDMA Read Message Size" is very ambiguous
   (i.e., the common meaning is not the intented one).

 - 4.8 figure 9 page 37: the Nones for Local Catastrophic Error doesn't
   specify what to put in the (BTW not optional) fields.

 - 5.4 page 46: the DDP layer mark -> marks?

 - 5.5 20. page 50: more than one ... is -> are?
   (same 7.1 24. page 55)

 - 7.1 21. page 55: Errors -> errors.

 - 7.1 24. page 55: the rules 2 and 3 above are really 2 and 3 of 5.5?
   Or are they 22 and 23?

 - 8.1.1 8. page 58: range available -> available range.

 - 8.2.1 page 60: RFC2401 -> RFC4301 and IPsec an guarantee anti-replay,
   not sequencing.

 - 8.2.2 page 61...: look at my comments about DDP I-D.

 - 8.2.2 7. page 62: I disagree with the recommendation. I suggest
   to cite directly the draft-ietf-pki4ipsec-ikecert-profile-10.txt
   document than to overload the CERTREQ payload which as its name
   suggest requests that the peer sends a CERT payload through IKE...

 - 10.1/2 page 65: RFC240x -> RFC430y.

 - 10.2 page 66: RFC2246 -> RFC4346 (and TLS 1.0 -> 1.1).

Regards

Francis.Dupont@point6.net

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

v2.23.0 | Report a Bug | By Email