Analysis of Stateful 64 Translation
draft-ietf-behave-64-analysis-07

I have no objection to the publication of this document, but I have a
number of small issues I hope you will attend to before publication.

---

Section 2 is unnecessary and should be removed (deosn't idnits give a 
warning about this?)

---

In Section 3, it would help the reader if you did not use the passive
voice.

   Following is a point by point
   analysis of the problems.  Issues listed in [RFC4966] are classified
   into three categories:

Is the classification yours or does it come from RFC 4966? It is a bit 
of a nuisance to have to read RFC 4966 to discover the answer?

In view of this, I found the category "impossible to solve" to be an
"interesting" categorisation! Where is the proof?


---

Section 3.3

          Analysis: This issue has mitigated severity as the DNS is
          separated from the NAT functionality.

Using a past participle as an adjective is all very well, but here is  
has confused the meaning! It reads as though the issue has done the 
mitigation. Better to say:

   The severity of this issue has been mitigated...

And then it is normal to treat mitigation as transitive. So, what did
the mitigation?

   The severity of this issue has been mitigated by the separation of
   the DNS from the NAT functionality.

---

Section 3.3, item 3

This item suggests that you need a fourth category: viz. issues that
do not apply to this problem space.

---

Section 6 would be enhanced by pointing at the issues within the
document that are related to security.

---

I'm slightly suspiscious that the reference to 
[I-D.haddad-mext-nat64-mobility-harmful] in Section 3.1 may be 
normative.

I am pretty sure that [I-D.ietf-pcp-base] is normative in item 4 of
Section 3.3.

[I-D.ietf-behave-lsn-requirements] in item 6 of Section 3.3 may be
normative.