Hi Dan,
Thanks for your review.
Se below in-line my responses.
Regards,
Jordi
-----Mensaje original-----
De: v6ops <v6ops-bounces@xxxxxxxx> en nombre de Dan Romascanu <dromasca@xxxxxxxxx>
Fecha: miércoles, 5 de diciembre de 2018, 16:17
Para: <ops-dir@xxxxxxxx>
CC: <v6ops@xxxxxxxx>, <dromasca@xxxxxxxxx>, <ietf@xxxxxxxx>, <draft-ietf-v6ops-transition-ipv4aas.all@xxxxxxxx>
Asunto: [v6ops] Opsdir last call review of draft-ietf-v6ops-transition-ipv4aas-11
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'?
I'm happy with that "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?
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.
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?
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.
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.
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:
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)
I will also take care of all those nits.
_______________________________________________
v6ops mailing list
v6ops@xxxxxxxx
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.
