Skip to main content

Last Call Review of draft-ietf-v6ops-enterprise-incremental-ipv6-05

Request Review of draft-ietf-v6ops-enterprise-incremental-ipv6
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-06-09
Requested 2014-05-28
Authors Kiran K. Chittimaneni , Tim Chown , Lee Howard , Victor Kuarsingh , Yanick Pouffary , Éric Vyncke
I-D last updated 2014-06-05
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
Request Last Call review on draft-ietf-v6ops-enterprise-incremental-ipv6 by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 06)
Result Ready w/nits
Completed 2014-06-05
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?)