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: '[email protected]'; Frankel, Sheila E.; '[email protected]' > Cc: [email protected]; 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 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > [email protected] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
