Telechat Review of draft-ietf-v6ops-enterprise-incremental-ipv6-05

Request Review of draft-ietf-v6ops-enterprise-incremental-ipv6
Requested rev. no specific revision (document currently at 06)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-06-24
Requested 2014-06-16
Authors Kiran Chittimaneni, Tim Chown, Lee Howard, Victor Kuarsingh, Yanick Pouffary, √Čric Vyncke
Draft last updated 2014-07-01
Completed reviews Genart Last Call review of -05 by Robert Sparks (diff)
Genart Telechat review of -05 by Robert Sparks (diff)
Secdir Last Call review of -05 by Steve Hanna (diff)
Opsdir Last Call review of -05 by Ron Bonica (diff)
Opsdir Last Call review of -05 by Tom Taylor (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-v6ops-enterprise-incremental-ipv6-05-genart-telechat-sparks-2014-07-01
Reviewed rev. 05 (document currently at 06)
Review result Ready with Nits
Review completed: 2014-07-01


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 


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?)