Background for those who may be unaware of GenART: GenART is the Area Review Team for the General Area of the IETF. We advise the General Area Director (i.e. the IETF/IESG chair) by providing more in depth reviews than he could do himself of documents that come up for final decision in IESG telechat. I was selected as the GenART member to review this document. Below is my review, which was written specifically with an eye to the GenART process, but since I believe that it will be useful to have these comments more widely distributed, others outside the GenART group are included.
This review was done as part of IETF Last Call. Review criteria: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication. Overall the draft is well written, clear, and detailed, making extensive use of examples. It should be a valuable reference for IKEv2 implementers. This draft is close to the edge of what an Informational RFC can do without updating the base IKEv2 specification. There are a number of places where the lower case admonitions are clearly intended to convey "SHOULD" and "MUST" (and their negatives) to implementers (e.g., most of the recommendations include discussion of what can go wrong, in some cases seriously, if the recommendation is not followed). OTOH, keeping this document Informational may have been a useful way of enforcing the "thou shalt not incompatibly change IKEv2" commandment. Section 1: Will the "work-in-progress" paragraph still be appropriate for the published RFC? The paragraph should be deleted if will not be appropriate. I would expect that most of these interpretations will stand up over time. Section 7.2: The ECN example is a good one, as the IKEv1 to IKEv2 change was used to mandate ECN-friendly behavior of tunnel mode SAs. The specific area of RFC 2401 involved in ECN was updated by RFC 3168, but RFC 4301 still requires different behavior even after this update. I think it's the authors' choice as to whether this section should mention RFC 3168's changes to this area of RFC 2401, as it is not necessary to the discussion. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
