I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).
Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipsecme-traffic-visibility-11 Reviewer: Pete McCann Review Date: 16 Dec 2009 IESG Telechat date: 17 Dec 2009 Summary: Ready Major issues: none Minor issues: none Nits/editorial comments: none This version addresses my previous comment adequately. -Pete McCann Peter-A001034 wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html > <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. > > Document: draft-ietf-ipsecme-traffic-visibility-09 > Reviewer: Pete McCann > Review Date: 2009-10-29 > IETF LC End Date: 2009-10-28 > IESG Telechat date: unknown > > Summary: One minor issue to discuss > > Major issues: none > > Minor issues: > > Section 2: > As can be seen, the WESP format extends the standard ESP header > by the first 4 octets for IPv4 and by 8 octets for IPv6. The > WESP header is integrity protected, along with all the fields > specified for ESP in RFC 4303. > Normally ESP wouldn't need to process encapsulation headers that > appear prior to the SPI. Won't this require modification of the ESP > implementation, possibly breaking its modularity? Would it be > problematic for certain algorithms to include this data? It might be > good to state that. > > Nits/editorial comments: none _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
