Draft: draft-ietf-rddp-ddp-06.txt Reviewer: Francis Dupont [Francis.Dupont@point6.net] Review Date: Monday 7/31/2006 11:09 AM CST IETF LC Date: 8/02/2006 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.