Analysis of Stateful 64 Translation
RFC 6889

Note: This ballot was opened for revision 06 and is now closed.

(David Harrington; former steering group member) Yes

Yes ( for -)
No email
send info

(Jari Arkko; former steering group member) Yes

Yes ( for -06)
No email
send info

(Wesley Eddy; former steering group member) Yes

Yes ( for -06)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-02-28 for -06)
No email
send info
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.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -06)
No email
send info