Paul, > >Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC # ranges for IPsec-v2 and > IPsec-v3. > > Disagree. The definition of IPsec-v2 and -v3 is complicated, as is clear from the document. Listing > RFCs here will send the wrong message.
How about listing the RFC # for just the architecture RFCs (2401 for v2, 4301 for v3)? It seems odd/inconsistent to indicate in this section where in the RFC sequence one can find only the truly obsolete IPsec-v1. > >** 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). > > I am having a hard time following your logic here. Where in "IPsec-v2" do you see combined modes > as being defined? I agree that they can be negotiated for ESP; why does that make them a feature > for all of IPsec-v2? The current "not a feature of IPsec-v2" language will be (mis)read as "cannot be used with IPsec-v2." Since we agree that the latter implication is incorrect, the language should be edited to avoid creating that incorrect implication. [... snip ...] > >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. > > RFC 2709 was only a model, not a protocol. The model and protocol are both part of IPsec-v3, but RFC > 2709 was not "part of" IPsec-v2 in that it was suggestions for deployment. I suggest adding some form of the above two sentences to 8.8.1 for clarity. Thanks, --David > -----Original Message----- > From: Paul Hoffman [mailto:[email protected]] > Sent: Friday, July 16, 2010 3:19 PM > To: Black, David; [email protected]; [email protected]; [email protected] > Cc: [email protected]; [email protected]; Black, David; [email protected] > Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08 > > At 10:56 PM -0400 7/11/10, <[email protected]> wrote: > >Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC # ranges for IPsec-v2 and > IPsec-v3. > > Disagree. The definition of IPsec-v2 and -v3 is complicated, as is clear from the document. Listing > RFCs here will send the wrong message. > > >** 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). > > I am having a hard time following your logic here. Where in "IPsec-v2" do you see combined modes as > being defined? I agree that they can be negotiated for ESP; why does that make them a feature for all > of IPsec-v2? > > >Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116. > > I think you meant this for 5.4.4. It is a reasonable addition. > > >Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If that is correct, it should be > stated. > > Good catch, 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. > > RFC 2709 was only a model, not a protocol. The model and protocol are both part of IPsec-v3, but RFC > 2709 was not "part of" IPsec-v2 in that it was suggestions for deployment. > > >In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". > > Agree. > > >If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821. > > I don't those help here. > > >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. > > These are non-visible gremlins; the RFC Production Center can squash them easily. > > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
