Francis, Many thanks for your detailed review:
> I have two main concerns: > - section 1.1 "Architectural Goals" is not understandable. > - section 8.4.2 "Requirements for IPsec Services for DDP" refers to > an obsolete version of IPsec. > For the second point I suggest to contact the IESG to know what > should be required (keep IKEv1 text, add some IKEv2 text, > move to IKEv2). As you suggested, I did contact the IESG, specifically the Security ADs, about IKEv1 vs. IKEv2, and the verdict is to stick with IKEv1 as profiled by RFC 3723 for iSCSI so that iSCSI and RDDP use the same profile of IPsec. If/when RFC 3723 is updated, all the protocols that use it will be uniformly affected. Text will be added to the next version of the draft to explain this. Everything else is edits that ought to be done on a revised version of the draft, except for the following which are not to be done as part of sticking to the older version of IKE and IPsec: > - 8.4.2 1. page 31: RFC2406 -> RFC4303. > > - 8.4.2 3. page 31: RFC2409 -> RFC4306 and remove the DOI. > > - 8.4.2 5. and 6.: I strongly suggest to update the text to IKEv2. > > - 10.1/2 page 34: RFC 240x -> RFC 430y. With luck, we'll have a new version of the draft soon. 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:09 PM > To: gen-art@ietf.org > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [Gen-art] review of draft-ietf-rddp-ddp-06.txt > > I am the assigned Gen-ART reviewer for draft-ietf-rddp-ddp-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 two main concerns: > - section 1.1 "Architectural Goals" is not understable. > - section 8.4.2 "Requirements for IPsec Services for DDP" refers to > an obsolete version of IPsec. > For the second point I suggest to contact the IESG to know what > should be required (keep IKEv1 text, add some IKEv2 text, > move to IKEv2). > > Detailed comments: > - 1.1 page 4: this ection is far too hard to understand. IMHO the > source of the problem is the use of the terms Local/Remote Peer when > nearly everywhere we have Data Source/Sink. As DDP is an one way > protocol (at the opposite of RDMAP for instance) I strongly suggest > to simply use only Data Source/Sink. > > - 1.1 page 4 and many other places: i.e. and e.g. take a ','just after > (only 8.4.2 page 31 has this right). > > - 1.1 page 4: the LLP abbrev is used before being defined (in page 6). > > - 1.3 page 6: the RDMAP abbrev is never defined. > > - 1.3 figure 2 page 8: I suggest to add some "//" and lines to the > payload to show it is the large field. > > - 2.1 pages 9/10: I suggest to remove Local/Remote Peers. > > - 2.1 page 9: RNIC is used before being defined (I suggest to add > a reference to the section). > > - 2.1 page 10: OS -> Operating System (there are already too many abbrevs). > > - 3 6. page 13: semantics require -> semantics requires? > > - 3 8. page 13: stream -> Stream (i.e., uniformize the case) > > - 5.1.1 page 19: bad wording (I suggest to remove the statement > "An STag identifies..." as the next one explains the same thing). > > - 6.2.1 page 23: I suggest to replace Local/Remote Peers by > Data Source/Sink. > > - 6.2.2 page 24: I don't like the term "catastrophic", is fatal > or unrecoverable still possible alternatives? > (same 7.2 page 26) > > - 7.1 page 26: it seems the 5. is already included in the 4., what > have I missed? > > - 8.4.2 pages 31...: the idea to follow the RFC 3723 is good, the problem > is this RFC is a bit old. > > - 8.4.2 1. page 31: there is only one replay protection mechanism in IPsec > and this service is offered by ESP. > > - 8.4.2 1. page 31: RFC2406 -> RFC4303. > > - 8.4.2 3. page 31: RFC2409 -> RFC4306 and remove the DOI. > > - 8.4.2 4. page 4: strictly speaking deletes are informational exchanges, > not phase 2 (aka. quick mode). BTW there is no such IKE Phase 2 SAs, > IMHO you mean IPsec SAs. > > - 8.4.2 5. and 6.: I strongly suggest to update the text to IKEv2. > > - 10.1/2 page 34: RFC 240x -> RFC 430y. > > - 11.1 page 36: size need -> size needs. > > Regards > > [EMAIL PROTECTED] > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www1.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
