Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
draft-ietf-behave-nat64-learn-analysis-03

Just a small thing:

Section 4, third bullet:
Is this an attempt to avoid references to "work in progress"?  There's no need to avoid it, and I'd rather see the references.  Just make them informative, and they won't block this document.  If they're dead (or dying) I-Ds that won't be completed, I'd still like to see the names (not just the titles) so I can find them in the archives.  The same goes for Brian Carpenter's "referrals" draft, which you refer to later in that section, and other drafts mentioned in other sections.

This is a reasonable complete assessment of the problem space.  I only have some comments/suggestions to put forth:

1. In paragraph 5 of section 1, I would suggest changing "... analyses all known solution proposals known ..." to "... analyzes all proposed solutions known ...".

2. In section 2, you reference WKP before you define the acronym.

3. I see several uses of the noun "analyses" used as a verb.  I suggest you change those to "analyzes".

4. Section 4 has an expansion of WKP that is redundant with the expansion done earlier in section 2.

5. Throughout most of the solution description sub-sections, drafts are called out by name and author(s) without a direct reference.  Is this being done simply to avoid having to publish those drafts?

6. Section 5.3 is an almost duplication of Section 5.2, only the summary is different.

7. In 5.6.1, the acronyms ASM and SSM are used without expansion or context.

Suggesting that elements hard-code an IPv4 address (see section 5.1.1) is perilous, and the draft referenced in that section doesn't seem to support the notion. Why is this suggestion here? Could it be removed?

I'm sure Wes saw that Jouni agreed to some additional text based on Sam Weiler jumping in with Alexey - https://www.ietf.org/mail-archive/web/secdir/current/msg03250.html - so this is just a reminded to include the text.

Basically I've a bunch of nits for what seems like a good piece
of documentation.

- There are a good few nitty few English language issues, too many to list
now. Better if those were fixed before the RFC editor has to do it.

- section 3, issue 3 - what does "implementing DNS" mean? Which kinds of
DNS node, stub resolver, recursive resolver,...

- section 4, calling RFC 6144 "The" framework document seems a bit
generic, suggest using the full title.

- section 4, are there cases where a host can't distinguish which of the
6144 scenarios apply that might confuse matters here? Not sure.

- section 4, is "IPv6 connection" the right term?

- Why are there no references for a bunch of I-Ds named here?  Its ok to
add informative references even to expired drafts IMO, (I wonder if
others disagree;-)

- There were changes agreed based on the secdir review. [1] Some of those
may overlap with the above (sorry, didn't have time to check properly)

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03233.html