[IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-09

[<[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .

Summary:
This draft is ready for publication as an Informational RFC.

The -09 version of this draft has satisfactorily addressed all of the comments in the Gen-ART review of the -08 version.  Many thanks to the authors.

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Sunday, July 11, 2010 10:57 PM
> To: '[e-mail]'; Frankel, Sheila E.; '[e-mail]'
> Cc: [e-mail]; Paul Hoffman; Yaron Sheffer; Sean Turner; Black, David
> Subject: Gen-ART review of draft-ietf-ipsecme-roadmap-08
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .
> 
> Please resolve these comments along with any other comments you may receive.
> 
> Summary:
> This draft is on the right track, but has open issues, described in the review.
> 
> This is a very useful summary of all of the RFCs (and some in-progress Internet-Drafts) that specify
> or are related to IPsec.  It will be very useful to those new to IPsec, as it describes the
> organization of the RFCs and relationships among them.
> 
> I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability of combined mode
> algorithms to IPsec-v2.  All of the other comments in this review are minor.
> 
> Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the RFC # ranges for IPsec-v2 and
> IPsec-v3.
> 
> ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode algorithms are "not a
> feature of IPsec-v2" and hence lists them as N/A.  That's not correct.  The correct situation is:
> - Combined mode algorithms for ESP can be negotiated as encryption
> 	algorithms (the integrity protection algorithm would typically
> 	be omitted proposals that do this).
> - Combined mode algorithms cannot be used with IKEv1, as they're
> 	incompatible with its design (see the Introduction section of
> 	RFC 5282 for a more detailed explanation).
> Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM should be "optional" for
> ESPv2 (and the NOTE should be revised accordingly).
> 
> Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116.
> 
> Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.  If that is correct, it should be
> stated.
> 
> Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating that should comment that
> this was not widely adopted, and NAT traversal is the commonly used mechanism to deal with NATs.
> 
> In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".  If you want to cite the RFCs involved, IP
> over FC is RFC 4338 and FC over IP is RFC 3821.
> 
> idnits 2.12.04 found some minor nits:
> 
>   ** There are 4 instances of too long lines in the document, the longest one
>      being 3 characters in excess of 72.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------