Francis, Thanks also for your detailed review of this draft.
> 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. And the resolution is the same - we stick with the older version until RFC 3723 is updated. All of the other changes appear to be editorial and should just be made, with the exception of the following which are mostly related to the IPsec/ IKE version: > - 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). Regarding certificate authorities, both IKEv1 and IKEv2 pass a certificate authority in a CERTREQ payload, and RFC 3723 recommends (SHOULD) usage of multiple IKEv1 Certificate Request Payloads when multiple authorities are acceptable, so that recommendation is not new to this draft. FWIW, the details involved in updating this to pki4ipsec are among the reasons why an update of RFC 3723 to the newer version of IPsec will not be simple. Thanks, --David (rddp WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Francis Dupont [mailto:[EMAIL PROTECTED] > Sent: Monday, July 31, 2006 12:44 PM > To: [email protected] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [Gen-art] review of draft-ietf-rddp-rdmap-06.txt > > 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 > > [EMAIL PROTECTED] > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
