Subject: Opsdir last call review of draft-ietf-v6ops-transition-ipv4aas-11

From: Dan Romascanu <[email-masked]>
Date: Wed, 05 Dec 2018 07:16:56 -0800

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)

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 05 Dec 2018 16:35:39 +0100

Hi Dan,

Thanks for your review.

Se below in-line my responses.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Dan Romascanu <[email-masked]>
Fecha: miércoles, 5 de diciembre de 2018, 16:17
Para: <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: [v6ops] Opsdir last call review of draft-ietf-v6ops-transition-ipv4aas-11

    Reviewer: Dan Romascanu

    

I'm happy with that "vendors who sell in the retail market".

    

This document started as an update of RFC7084, and this text was taken from that one. I understand that at that time it was accepted.

    

    

The intent was to say that, if a product is targeted to the retail market, it must support all the transition mechanisms. Then at the level of each individual transition mechanism, to make it work, it should support this and that. From our perspective it is clear, but I'm happy to heard alternative wordings.

    

I don't think so. Typically, an operator will take one, maybe two transition mechanism, and the cost associated to what the CEs support or not, is not changing the cost in terms of training or operation.

    Nits:

    
    
I will also take care of all those nits.

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.