Document: draft-ietf-behave-v6v4-xlate-20.txt
Reviewer: Miguel Garcia <miguel.a.garcia@ericsson.com>
Review Date: 15-June-2010
IETF LC End Date: 15-June-2010
IESG Telechat date: (if known)

Summary: The document is ready for publication as a standards track RFC.

Major issues: none

Minor issues:

- Section 4.4 got my attention due to the lack of normative text. 
The says "... has a Type value 1...." a couple of times, while describing 
how to build an ICMPv6 error message. I wonder if this is on purpose or 
whether these sentences should be promoted to normative text.

Nits/editorial comments:

- As a personal matter of taste, I think the Introduction section should 
not include normative text (there is a "MUST" and a "MAY"), because then it 
is no longer an introduction.

- In Section 1.1, there is a slightly incongruence with the term XLAT. In the 
first paragraph of Section 1.1 the term XLAT is expanded as 
"IP/ICMP translator", whereas in Figure 1 (on the right of the figure) it 
is expanded as "IPv6/IPv4 translator". The term "XLAT" should be harmonized.

- As personal taste, I don't like to write normative text in a relative 
clause, because it hides the importance of the normative part. This happens 
in the following sections:

  - Section 3.3:
    In addition, the ICMP error messages contain the packet in error,
    which MUST be translated just like a normal IP packet.

  - Section 4.4:

    In addition, the ICMP error messages contain the packet in error,
    which MUST be translated just like a normal IP packet.

  The suggestion is to split the sentence into two.

- idnits reports the following error and warnings:

  ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460)

  == Outdated reference: A later version (-09) exists of
     draft-ietf-behave-v6v4-framework-08

  -- Obsolete informational reference (is this intentional?): RFC 2766
     (Obsoleted by RFC 4966)