I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at Document: draft-ietf-softwire-4rd-08.txt Reviewer: Christer Holmberg Review Date: 6 October 2014 IETF LC End Date: 10 October 2014 IETF Telechat Date: 16 October 2014 Summary: The document is well written, and almost ready for publication, but there are some editorial nits that I ask the authors to address before publishing. Major Issues: None Minor Issues: None Editorial nits: None QGEN_1: In a number of places in the document you talk about "mesh topology" and "Hub&Spoke topology". Are those considered commonly known, or would it be useful to have a reference? QABS_1: The Abstract needs to be re-formulated. It seems to describe a problem, but does not really say anything about the scope of the document. Normally, after the problem statement, there would be a sentence starting with "This document defines blah blah blah...". Q_1_1: The first sentence says "For deployments of residual IPv4 service via IPv6 networks,". Is there a document defining "residual IPv4 service via IPv6 networks" which you could reference? Q_1_2: I would suggest to split the first paragraph into smaller paragraphs. Something like (note some minor editorial changes): "For deployments of residual IPv4 service via IPv6 networks, the need for a stateless solution, i.e. one where no per-customer state is needed in IPv4-IPv6 gateway nodes of the provider, is expressed in [I-D.ietf-softwire-stateless-4v6-motivation]. This document specifies such a solution, named "4rd" for IPv4 Residual Deployment. Using the solution, IPv4 packets are transparently tunneled across IPv6 networks (reverse of 6rd [RFC5969] in which IPv6 packets are statelessly tunneled across IPv4 networks). While IPv6 headers are too long to be mapped into IPv4 headers (why 6rd requires encapsulation of full IPv6 packets in IPv4 packets), IPv4 headers can be reversibly translated into IPv6 headers in such a way that, during IPv6 domain traversal, UDP packets having checksums and TCP packets are valid IPv6 packets. IPv6-only middle boxes that perform deep-packet- inspection can operate on them, in particular for port inspection and web caches." Q4_1: In section 4, the text lists a number of functions that a 4rd CE and a 4rd BR SHOULD follow. However, e.g. in R-2 the text says: "CEs and BRs MUST be configured with the following Domain parameters:" So, is R-2 a "MUST", or a "SHOULD"? Perhaps you in section 4 should only list the functions, and for each function you then say whether it is SHOULD, MUST, or something else. Regards, Christer