Mapping of Address and Port with Encapsulation (MAP-E)
draft-ietf-softwire-map-13

I don't have any specific objection to this document. I agree with others that there are too many options and potential solutions being published. While there is a good chance that the market will decide and winnow this down to just a very few practical solutions, I believe the IETF (and specifically the Softwire working group) is letting down the industry. Vendors will be unclear which solutions to implement and operators are unlikely to give early direction. This will result in multiple implementations that either do not interoperate or that increase the net cost of equipment. And in the end, who pays?

I wish more effort had gone into reducing the options.

This is perhaps more a comment for the ADs, but it seems that the mechanism specified in this document provides a high degree of configurability in terms of the size of port sets without providing any guidance or explanation about the impact on application stability/breakage of choosing different set sizes. Is there a document somewhere in the softwire document suite that provides this background or advice to service providers about minimizing application impact when choosing port set sizes? RFC 6269 points out the problems, but doesn't provide any detail about how tuning the kinds of knobs available in this spec may affect applications one way or the other. If such a document does not exist, it seems like at least the deployment of the mechanism specified here, if not other variations that make use of restricted port sets, would benefit from it.

I've had a quick look, and nothing stands out.  I trust my distinguished colleagues from Vermont and Maryland to duke it out.

Thanks for addressing the SecDir review and adding in a reference to address dependent filtering in the Security Considerations section.

[updated with one question at the end of the ballot] 

I am balloting no objection on the grounds that this document has been reviewed by the WG and the IETF community at large and apparently "passed" the last calls in terms of having rough consensus. 

However, the proposed solution looks personally to me like a big hack or in other words this document is creating a cross IP version protocol address translator (including using transport protocols).
Actually, the whole work of the softwire working group should be reconsidered from an architectural view. Is this really the long term solution to get the IP transition right or is this just creating the next headache in five years as something out of the networking layer and the transport layer is mixed together as an IPv6 address?

Adding another question:
RFC6346 A+P is used throughout the document and I believe an implementer has to read RFC6346 and understand the A+P sharing mechanism in order to get the implementation of this draft right. Or isn't any knowledge about RFC 6346 required?