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

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)