Last Call Review of draft-ietf-v6ops-transition-ipv4aas-11
review-ietf-v6ops-transition-ipv4aas-11-rtgdir-lc-ceccarelli-2018-12-16-00

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