Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-09

1. Section 1 uses the term 'DNS synthesis' without defining it. 

2. Section 5 deals with ALG considerations but ALG is never expanded

2.3 - I agree with Stephen's DISCUSS: MUST the ENR wait for an explicit negative response on the A record lookup, or can it synthesize from the AAAA in other circumstances? Probably best to explicitly say so. I guess I'd like to hear specifically what "only IPv6 addresses are available" means.

The abstract states that this document obsoletes RFC 2767 and RFC 3338. The introduction states that this document updates those RFCs. I think the introduction might need to be changed.

Given that RFC 2767 was informational and RFC 3338 was experimental, it might be helpful to summarize the results of the experiment (e.g., implementation and deployment experience).

Thanks to the authors for a well-written, easily understandable document.

Assuming that this recommendation in section 2.3 (which I think appears elsewhere; e.g., in section 2.3.2) is a general recommendation:

  Hence the socket API layer option is RECOMMENDED.

it might be helpful to emphasize the recommendation by repeating it somewhere up front in the Introduction.

In section 2.3.4, why would availability of an IPv4 interface case BIH to shut down?

  The Gen-ART Review by  Wassim Haddad on 3-October-2011 raised this
  concern, and it needs to be resolved.

  Please clarify the connection to the two obsoleted (RFCs 2767 & 3338).
   - The document states that it "obsoletes" them in the title page
     header and the abstract.
   - The document states that it "updates" them in the Introduction.
   - The document says that it is a "direct update to and directly
     derivative" from them in section 1.1.
   - The document says that it "combines and obsoletes" them in
     section 8.
  Please be clear that this document draws from the material in these
  RFCs, and that it obsoletes them.