Last Call Review of draft-ietf-behave-v6v4-framework-
review-ietf-behave-v6v4-framework-secdir-lc-kent-2010-06-20-00

Request Review of draft-ietf-behave-v6v4-framework
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-06-15
Requested 2010-06-03
Other Reviews
Review State Completed
Reviewer Stephen Kent
Review review-ietf-behave-v6v4-framework-secdir-lc-kent-2010-06-20
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg01769.html
Draft last updated 2010-06-20
Review completed: 2010-06-20

Review
review-ietf-behave-v6v4-framework-secdir-lc-kent-2010-06-20

Title: 

review of
draft-ietf-behave-v6v4-framework-09




I reviewed this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were
written primarily for the benefit of the security area directors. 
Document editors and WG chairs should treat these comments just like
any other last call comments.







As its name implies,
draft-ietf-behave-v6v4-framework-09 provides a context for the
discussion of translation between IPv4 and IPv6 networks, during the
transition from IOv4 to Ipv6. Although I did not read the document
very carefully, it appears to be very well written. It begins with an
introduction that provides context setting and history, followed by a
discussion on the need for translation between IPv4 and IPv6 networks,
and a good terminology section. I wish all RFCs were as well
structured as this one.







The security considerations
section is just one sentence, perhaps a new record for brevity in the
post "no security considerations" era :). This is a
framework document and as such the authors refer the reader to the
individual IPv4/IPv6 translation documents, which they cite. I am a
little disappointed that there is not even a high level discussion of
security considerations here, one that might capture security-relevant
issues that are common to all of the translation methods that are
described in detail in the cited documents. Nonetheless, given the
overall high quality of the writing in this document, the brevity
seems acceptable.







(I do have minor quibble with the
wording in the security considerations section; the cites are preceded
by "i.e.," which literally implies that there will be no
other such documents. If, as I suspect, the list is not meant to be
exhaustive, in perpetuity, "e.g.," would be the appropriate
Latin abbreviation.)