[RTG-DIR] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11

[Daniele Ceccarelli <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-v6ops-transition-ipv4aas-11.txt
Reviewer: Daniele Ceccarelli
Review Date: 2018-12-14
IETF LC End Date: date-if-know
Intended Status: Informational

Summary:

*       I have some minor concerns about this document that I think should be resolved before publication.

Comments:

*       I find this draft quite difficult to read. Probably it’s due to my lack of competence in the topic. If the aim is to make it usable by experts it could be ok. This document is not defining protocols extensions (hence targeting experts), but requirements and mechanisms  for IPv4-IPv6 transition hence it should be starting point for a newbie to get to understand the topic. Some drawings to help understanding the context and a more detailed explanation in the intro would be helpful. E.g. the content of Annex B could be a good starting point.

Major Issues:

*       1.1.  Requirements Language - Special Note – Very particular usage of the requirements language. It says “This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality.”. I don’t see a big difference. In both cases it tells how things should be done. Moreover there are various occurrences of MUST/SHOULD that really seem to conform RFC2119.

Minor Issues:

*       Abstract: “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.” Do you mean “or by producers of devices for the retail market” ?
*       Abstract: "Basic Requirements for IPv6 Customer Edge Routers". Since this is in quotes I guess it references something well known. Adding the reference could be helpful. Further reading I’ve found RFC7084 as reference. You can add it.
*       The scope of the draft is not clear from the statement in the intro: “so the scope of this document is to ensure the IPv4 "service continuity" support, in the LAN side and the access to IPv4-only Internet services from an IPv6-only access WAN even from IPv6-only applications or devices in the LAN side.” This should be better explained.

Nits:

*       Intro: A number of acronyms should be expanded at first use: e.g. LAN, WAN, HNCP, ISP.
*       Intro: :“This is a common situation in when sufficient…” remove “in”.
*       Actually there is plenty of Nits. I suggest a spelling pass.

BR
Daniele