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

[Francis Dupont <[e-mail]>]

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

[e-mail]

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art