I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-v6ops-enterprise-incremental-ipv6-05 Reviewer: Robert Sparks Review Date: 5 June 2014 IETF LC End Date: 9 June 2014 IESG Telechat date: not yet scheduled Summary: This draft is basically ready for publication as an Informational RFC, but has nits that should be considered before publication. I had a mixed overall impression after my first read-through of this draft. Overall, the list of issues to consider, and the compendium of references is very useful, but there are large stretches of text that really aren't helping the reader, and they make the good stuff harder to see. I encourage the group to take one more editorial pass, focusing on removing as much text as possible without losing the message. Please help the IESG and the RFC-Editor out: the shepherd's writeup should say something about why deviating from the style guide's restriction on number of authors is is appropriate for this document. Here are specific nits to consider in document order: The first paragraph of section 1.3 starts talking about phases as if they've already been described. As written, it says that beginning with the External Phase is recommended in RFC5211. But the words "External Phase" do not appear in 5211, and its not clear on a quick read exactly what in 5211 you were hoping to point out here. Please introduce the phases before this point, and change the callout to 5211 to make it more clear how what 5211 is saying ties into this document. Why is "Other Phases" capitalized in 2.1? The number of phases defined in this document is small - I suspect this text is older and left room for the group to decide to define more phases. Consider just listing what you ended up with explicitly. Section 2.1 contains sentences like "The project manager will need to spend some time on planning." That is obvious, and you've already established that planning needs to happen. This paragraph (perhaps much of this section) would be improved by removing as much text as you can. It already speaks mostly in terms of the benefits of planning. Making that a more explicit goal in the writing structure would help identify what can be taken away without losing the message. Overall, trying to describe what good project management entails is a bit out of place. Perhaps you should just say "This requires good project management skills"? In 2.2.2 you say "Applications should be made to use APIs". That seems an odd construct for an IETF document. Perhaps you could observe, rather than command, here? Would saying something like "Applications that use APIs to hide the specifics ... will be easier to take through the migration" make the point? In 2.3, why do you need the hyperbole in "IPv6 adoption will be a multifacted undertaking that will touch everyone in the organization unlike almost any other project."? How does the "unlike almost any other project" help the reader? In 2.4.1, please rephrase "pretty much like". Are there any differences in the use of IPSec dependent on the address family that are important to call out? If not, why doesn't this say "the same as in"? Section 2.4.2: As written, this says Etc. is an attack. Please change the introduction to the list to say "for example" or "in particular" and remove the Etc. If the point was to cause the reader to think about attacks beyond these listed, say that explicitly. The 6th paragraph of 2.6 states the problem is "how to get host DNS records updated." The text in the rest of the paragraph only addresses this by implication. It looks more like the general discussion of SLAAC vs DHCPv6 instead of straightforwardly noting that a DHCPv6 server can be made to update DNS records. The reference to RFC6866 in paragraph 7 of section 2.6 is unclear - what was it trying to point out? I think the last sentence was trying to say 'static address assignment (even if achieved with DHCP) is usually used' where it currently says 'SLAAC is rarely used'? Section 3: The second paragraph doesn't add anything to the document. Section 3.1 paragraph 2: I don't understand why the paragraph ends with "which is an important consideration". Can you delete the phrase without losing the message? If not, say why an enterprise would care whether or not _other_ enterprises had already deployed using BGP on their own. Section 3.1 paragraph 4 : "will prefer to use" is out of place. Perhaps this should be stated as "will likely get better results using"? Section 3.1 paragraph 5: Can you add a reference to a discussion of how keeping the MTU congruent simplifies operations? In section 3.2 consider using the names from 4890 in the list ('Packet Too Big' rather than 'Unreachable packet-to-big') Please check whether the sentence "To be fully compliant with [RFC5095], all packets containing the routing extension header type 0 must be dropped." is perhaps too simple a description of 5095? Does context keep you out of the "Segments left is zero" branch of that RFCs requirement? In section 3.4, please remove "this may seem too time-consuming and too risky" or restate it with details. How is this observation supposed to help the reader? In section 4.1 paragraph 3 "But the major issue is probably linked to all threats" would read better as "One major issue is threats" In section 5 paragraph 3, please provide a reference to where these significant implications are discussed, or add some discussion. (Otherwise, what is the reader supposed to do with this observation?)