Reviewer: Dan Romascanu Review result: Has Issues Please find below the OPS-DIR review of draft-ietf-v6ops-transition-ipv4aas. As this is not the definition of a new protocol or extension of an existing protocol, a full RFC 5706 review does not apply. However, its topic is relevant for the operators community, and I would recommend that the OPS ADs pay attention to it. There are some issues that I recommend to be addressed before this document is approved. 1. In the Abstract section: > This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. It is not clear to me what is meant by 'the retail market' and how the IETF can discuss requirements to a 'market'. Maybe the requirement is for vendors who sell in the 'retail market'? 2. Section 1.1 includes a 'Special Note' about keywords that includes the following text: > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, are not used as described in RFC 2119 [RFC2119]. This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. I am not sure if there is a precedent to such a note that was discussed and approved by the IESG. I find this problematic, because if the usage is not conform to RFC 2119 it is not clear how readers of this document should interpret the capitalized keywords in the text. If the authors decided to not abide by RFC 2119, why did not they just use the non-capitalized versions of the keywords? 3. Section 1 specifies: > Since it is impossible to know prior to sale which transition mechanism a device will need over the lifetime of the device, IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanism supported by this document. But then sections 3.2.1 to 3.2.5 use SHOULD for the described mechanisms. For example in 3.2.1: > The IPv6 Transition CE Router SHOULD support CLAT functionality. How does the initial generic MUST for all mechanisms works with the specific SHOULDs for the defined techniques? 7. Section 7 looks through the code and memory considerations as well as to development costs and conclude that these are reasonable compared to the benefits. > The other issue seems to be the cost of developing the code for those new functionalities. However, at the time of writing this document, it has been confirmed that there are several open source versions of the required code for supporting all the new transition mechanisms, and several vendors already have implementations and provide it to ISPs, so the development cost is negligible, and only integration and testing cost may become a minor issue. This is fine and I appreciate taking all these aspects into consideration. However, there is one more incremental costs assumed by the customer operators in what concerns training operators on the different techniques and their configuration. I believe that those are worth being analyzed and the conclusions included also in this section. Nits: 1. I trust the RFC Editor to correct most if not all language problems. There are a few which may be addressed by a careful pass of the authors through the text (e.g. 'all the transition mechanism', 'because as in an IPv6-in-IPv4 tunneling', etc.) 2. It would be useful to expand acronyms at first encounter (e.g. HNCP, CGN 3. Inconsistent usage of double brackets for references (e.g. in 464XLAT-3)
