I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. At this point, I would describe the document as “Mostly Ready” or "Ready with nits”. I’ll detail my questions as I go through this. This document, in its words, "describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports.” It is not the first such mechanism; examples of such mechanisms include that of RFC 1933, which describes dual stack deployment and IPv6-in-IPv4 tunneling. It was replaced by RFC 2893, which in addition to those describes the embedding of IPv4 addresses into IPv6, and a mechanism for automated tunneling of IPv6 over IPv4. That was in turn replaced by RFC 4213, which falls back to describing dual stack deployment and configured tunneling of IPv6 over IPv4. The draft mentions 1933 but not 2893 or 4213. It does go on to mention 6over4 [RFC2529], 6to4 [RFC3056], ISATAP [RFC5214], and 6rd [RFC5969] in the introduction, and RFC 2473 in section 4. There are also other proposals on the table. All of these assume a pervasive IPv4 network into or over which an IPv6 network is being deployed. There are additionally 110 RFCs that to one degree or another contemplate IPv6-only networks. Most of these simply talk about the possibility of such without thinking very hard about the operational implications of that. If anything, they tend to assume that there is a pervasive central IPv4 network, parts of which are likely dual stack, with a periphery that includes some IPv6-only networks. The structural integrity of the IPv4 network is not questioned. Softwire’s MAP architecture, in both the encapsulation and translation variants, starts from the premise that the structure of the IPv4 network is no longer pervasive, and that in different places IPv4 may be providing transport service to IPv6 and in other places IPv6 may be providing transport to IPv4. When either is used as transport for the other, continuity of the overlaid network has to be consciously supported or the overlaid network has to route around the underlay. This draft uses encapsulation as a means by which an IPv6-only network can interconnect otherwise-separated IPv4-capable networks, which may be upstream or downstream, and may or may not support IPv6 services. The questions I had while reading the document follow. In many cases, they turn around the use of a word, and can be clarified by clarifying that usage. Section 4 is entitled “Architecture”. It describes a MAP environment as an IPv6-only domain surrounded by IPv4-capable domains, and has a mapping node between it and each of those domains that manages the overlay. Downstream IPv4-capable domains are presumed to have an IPv4 NAPT, which would be consistent with residential broadband. “MAP”, it says, "supports the encapsulation mode specified in [RFC2473].” As long as the RFC is, I think that tells me that MAP supports any of a number of tunneling mechanisms, and either by routing or manual configuration, directs traffic across those tunnels. It would have been helpful to me if that statement had been present. Section 5, “Mapping Algorithm”, leaves me with several questions. What does it mean for the “basic” or “forwarding” mapping rules to be mandatory or optional? I think it means that the code MUST implement both, but the configuration MAY omit the forwarding rule. Were I implementing this, though, I might seriously ask whether the implementation of forward rules was optional if my target market didn’t require them. This is probably addressed in 5.2 and 5.3, but would do well with a sentence here. Section 5.1 indicates that ports may be aggregated in the same way that addresses aggregate into prefixes. That is certainly one way to do that. I think we have some applications that use port ranges; if we do, we will need to be ably to express port ranges. This is, I think, actually important to fix before IESG review. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail