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

Hi Daniele,

Thanks a lot for your review.

Please, see my responses below, in-line.

Regards,

Jordi

De: v6ops <v6ops-bounces@ietf.org> en nombre de Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Fecha: sábado, 15 de diciembre de 2018, 16:15
Para: "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" <draft-ietf-v6ops-transition-ipv4aas.all@ietf.org>
Asunto: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11

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

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.

I guess it can help to add a comment in the line that it is expected that the reader has also read RFC7084.

Initially the annex B was right after the intro, but the WG decided to keep it, but make it an annex. I will make a comment in the intro to reference the annex.

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.

This was made also following RFC7084.

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. 

I will clarify all those aspects. Initially I’d a reference to the RFC7084 in the abstract, but it seems is not accepted by the nits checker, so I’ve removed it. If someone has any suggestion on that, I’m happy to follow it …

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. 

I will follow all those points as well.

BR
Daniele  

_______________________________________________ v6ops mailing list v6ops@ietf.org 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.