Last Call Review of draft-ietf-v6ops-transition-ipv4aas-11
review-ietf-v6ops-transition-ipv4aas-11-opsdir-lc-romascanu-2018-12-05-00

Request Review of draft-ietf-v6ops-transition-ipv4aas
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-12-14
Requested 2018-11-30
Draft last updated 2018-12-05
Completed reviews Tsvart Last Call review of -11 by Martin Stiemerling (diff)
Opsdir Last Call review of -11 by Dan Romascanu (diff)
Rtgdir Last Call review of -11 by Daniele Ceccarelli (diff)
Genart Last Call review of -12 by Matthew Miller (diff)
Secdir Last Call review of -11 by Christian Huitema (diff)
Secdir Telechat review of -12 by Christian Huitema (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-v6ops-transition-ipv4aas-11-opsdir-lc-romascanu-2018-12-05
Reviewed rev. 11 (document currently at 15)
Review result Has Issues
Review completed: 2018-12-05

Review
review-ietf-v6ops-transition-ipv4aas-11-opsdir-lc-romascanu-2018-12-05

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)