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

[[e-mail]]

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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: Francis Dupont [mailto:[e-mail]] 
> Sent: Monday, July 31, 2006 12:09 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> 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
> 
> [e-mail]
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 

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