Mapping of Address and Port using Translation (MAP-T)
draft-ietf-softwire-map-t-08

Thanks for bringing this back around through the process circuitry.
I have no objection to publication.

I do agree with Adrian's comments about clarifying how and what the experiment is.

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

Exactly like Adrian, I would like some more information on the Experimental status.
As examples:
   http://tools.ietf.org/html/rfc7360#section-1.3
   http://tools.ietf.org/html/rfc6614#section-1.3

I believe this should be common practice for experiemental RFCs. 
Re-reading RFC 3933, and I don't see this. 
Maybe an IESG statement ... ? 



Editorial from Victor K. (OPS-DIR review):
Section 7.1

Paragraph 2:
old text “.. a CE requires an the IPv6 prefix to be assigned to the CE”
new text “.. a CE requires an IPv6 prefix to be assigned to the CE.”

Section 7.2

Paragraph 3:
old text “.. no specific routes need to be  advertised externally for MAPto operate, neither in IPv6 nor IPv4 BGP.”
new text “.. no specific IPv6 or IPv4 routes need to be advertised externally outside the service provider’s network for MAP to operate.”

I added this version of the sentence since it makes more sense to me.  Also, you technically don’t need BGP on the ISP side (although I can’t a modern network which does not use it).

Several people, including a Gen-ART reviewer, have asked about the status designation. I think we have all read about the history of how we got here. I do not personally have an objection for upgrading the document (but of course that would require a new last call). Nor do I think the IESG or reviewers should have a strong opinion in the matter. However, I'd suggest that broad applicability and interest from the working group, in today's context, should be the deciding factor, if someone wants to make a change.

The security considerations look good, thank you.

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?

The document has undergone another Last Call regarding the IPR (which was previously declared on an earlier version of a document that had this specification as a part) and the IESG has discussed the change in status. I won't stand in the way of the document.

- I support Pete's discuss about IPR - surely this has to
go around to IETF LC again for that?