Hi Robert, We have submitted version 08 of draft-ietf-v6ops-ipv6-deployment to address the comments and nits received after the Gen-ART review. We took this chance to include in our revision also the comments received from Nick Buraglio just after the completion of the WGLC.
Best regards Giuseppe & Paolo -----Original Message----- From: v6ops <[email protected]> On Behalf Of Paolo Volpato Sent: Monday, September 26, 2022 11:50 AM To: Robert Sparks <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: [v6ops] Genart last call review of draft-ietf-v6ops-ipv6-deployment-07 Dear Robert, Thanks for your comments. Please find our reply inline as [GP]. Giuseppe & Paolo -----Original Message----- From: Robert Sparks via Datatracker <[email protected]> Sent: Saturday, September 24, 2022 10:34 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Genart last call review of draft-ietf-v6ops-ipv6-deployment-07 Reviewer: Robert Sparks Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-v6ops-ipv6-deployment-07 Reviewer: Robert Sparks Review Date: 2022-09-24 IETF LC End Date: 2022-09-26 IESG Telechat date: Not scheduled for a telechat Summary: Mostly ready for publication as an Informational RFC, but with nits to address before publication. I appreciate that this document represents a significant amount of discussion, and agree that obsoleting RFC6036 is the right thing to do. [GP] Thanks. However, it is unclear who this document is for. It doesn't feel like it's for people working on standardization or regulation, nor does it feel like a roadmap into other work or sources of information. Parts of it _begin_ to feel like it's intended to help people who are managing networks going through transition, but the language in those sections is not addressed to them. Is it primarily a guide to the narrative IPv6 evangelists could use when approaching other audiences? I don't object to publishing this in its current form (but suggest addressing the below nits), but I really wonder if it would be more useful to reconsider the audience(s) and goals and write more explicitly to them. [GP] The intended audience is the whole IETF community as well as delegates from carriers and enterprises who are interested to this kind of RFCs, so it may be quite wide. The goal of the draft is to make a picture of the deployment status of IPv6. Said that, we acknowledge that yours is a valid point. We plan to make a few changes in the introduction to better specify both the target audience and the goal of the draft. It's hard to tell what in this document is repetition of results from other sources, and what is new synthesis and analysis. [GP] Through the draft we meant to summarize the results of many analysis/researches into a single document. This to provide an easily accessible document where to find all the aggregated statistics. On the other hand, according to the surveys we aimed to analyze the challenges that still remain in IPv6 adoption. There is language that should be adjusted to reflect being published in archival series. Example: "This document intends to" I recognize that this is a matter of style, but I find the use of phrases like "it may be interesting to", "it is worth mentioning", and similar to be distracting. Please consider removing the phrases - the point of the sentences will become stronger. [GP] Thanks for your suggestions. We'll revise those sentences. There are a few sentences that could be adjusted to make them easier for non-native english speakers to translate. Places like "Their actions cannot be objected, ". It would be good to scrub these before they get to the rfc-editor. [GP] Ok, we'll check those sentences. The document is acronym-heavy, and some acronyms are used so few times that expanding them on _every_ use is better than just on first use. Example: FBB. [GP] Ok, fine. It is uncomfortable to see "It is important to say that IPv6 is not more or less secure than IPv4". First - are you telling the readers that it is important for them to say this? Or stating that it's important for this document to say it? Second, the rest of the document doesn't support the statement. Instead, it almost directly contradicts it, by pointing to the relative maturity of implementations, the larger potential attack surface, etc. Why is this sentence (at the beginning of 5.4.1) in the document? Could the statement simply be removed? [GP] We'll revise this sentence to explain the concept better Has potential selection bias been considered in the analysis of the survey in appendix A? Perhaps it would be more accurate to title section 3.2 "IPv6 among Internet Service Providers in Europe"? [GP] Sure At "theoretical ratio", I suggest instead of using that phrase, you explain why you needed to say it. I suggest something like: "This is not a claim that each person uses this many addresses", or simply talking about the ratio without this disclaimer - the readers will already be familiar with the characteristics of per-capita metrics. [GP] We will replace the phrase. In 3.3, last sentence of the first paragraph - it's not clear that you actually state otherwise in the text that follows. If you do, stating otherwise needs to be done more clearly. If you don't, you don't need this sentence. [GP] Right, we'll fix it. Micro-nit in figure 3: Wolrdwide -> Worldwide [GP] We'll fix it as well _______________________________________________ v6ops mailing list [email protected] https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
