[Ballot discuss]
I hate to just list a bunch of documents as references, but we've just reviewed draft-ietf-opsec-ip-security and draft-ietf-v6ops-tunnel-security-concerns is coming down the pipe.  Should these and maybe some others you think are important be listed in the security considerations?

[Ballot discuss]
I hate to just list a bunch of documents as references, but we've just reviewed draft-ietf-opsec-ip-security and draft-ietf-v6ops-tunnel-security-concerns is coming down the pipe.  Should these and maybe some others be listed as security considerations?

[Ballot discuss]
This is a discuss-discus.  To be clear, I am not asking for any changes in the document with respect to this issue at this time.

Section 3, Principles, opens with the following statement:

  The end goal is network-wide native IPv6 deployment, resulting in the
  obsolescence of transitional mechanisms based on encapsulation,
  tunnels, or translation, and also resulting in the obsolescence of
  IPv4.

I do not think that these are the goals of someone deploying an IPv6 network on the Internet.  Their motivations
for deploying IPv6 are more likely focused on address availability and the availability of specific features.  Even
more than that, most IPv6 deployments are more focused on ensuring connectivity with the installed IPv4 base
than IPv6 purity.  Citing obsolescence of IPv4 as a goal makes the document less convincing to this reader.

I don't think refining the goals would change the set of transition strategies to be discussed, but I think there is
a tone issue that results from the anti-IPv4 goals.

A more actionable discuss issue: while this document doesn't create new security issues, a discussion of the
relevant issues probably should take place in this spec.

[Ballot discuss]
This is a DISCUSS-DISCUSS, as I am not sure that the issue I am raising needs to be reflected in this document, but I feel it is important enough to be raised with the IESG in the context of this document. I would expect that a discussion on the transition mechanisms to IPv6 includes a reference about the network management tools that need to be used during the transition, and what would be the requirements from the network management systems during the transition in the different scenarios. One aspect of the problem is touched by in section 4.3 (addressability of managed systems) but this is only one of the multiple aspects to be discussed. Is the place for such a discussion in this document?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-arkko-ipv6-transition-guidelines-08.txt> (Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:
- 'Guidelines for Using IPv6 Transition Mechanisms during IPv6
Deployment'
  <draft-arkko-ipv6-transition-guidelines-08.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-arkko-ipv6-transition-guidelines/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-arkko-ipv6-transition-guidelines/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Kurt Erik Lindqvist, kurtis@kurtis.pp.se. I have reviewed the document and believe it's read for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been through working group last call in v6ops and had a through review. Minor issues brought up at WGLC have been addressed in the last version of the document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The view of the document shepherd is that the document has been discussed thoroughly and that the WG as a whole understands the document. Concurrence with the document is strong, with a very limited number of people suggesting that technologies they have worked on should be given more prominence in the document. It's the document shepherder's view that this has been adequately addressed in the revised document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There has been no threat of appeal.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and ). Boilerplate checks are
not enough; this check needs to be thorough. Has the document met
all formal review criteria it needs to, such as the MIB Doctor,
media type and URI type reviews?

The current version of the document produces the following warnings :

Checking references for intended status: Informational
----------------------------------------------------------------------------

== Unused Reference: 'RFC5218' is defined on line 839, but no explicit
reference was found in the text

== Outdated reference: A later version (-02) exists of
draft-arkko-ipv6-only-experience-00

== Outdated reference: draft-ietf-behave-address-format has been published
as RFC 6052

== Outdated reference: draft-ietf-v6ops-isp-scenarios has been published as
RFC 6036

-- Obsolete informational reference (is this intentional?): RFC 2766
(Obsoleted by RFC 4966)

Summary: 0 errors (**), 4 warnings (==), 2 comments (--).

Run idnits with the --verbose option for more detailed information about
the items above.

But a new version correcting these is being submitted when that is allowed again.

(1.h) Has the document split its references into normative and
informative?

It has.

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All normative references exists.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

There are no IANA implications.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

As the date of IANA depletion for the IPv4 pool draws closer, the interest in IPv6 deployment at network operators are increasing. However, there are a lot of new expertise needed, as well as deployment scenarios and associated choices when it comes to transitioning technologies. This document outlines some of the common deployment situations and strategies for choosing the right tools. The document also outlines some recommendations for common deployment models of transition technologies.

Working Group Summary

The working group reviewed and discussed the draft. There was a point of rough consensus, but in general respondents said the document was relevant, useful, and appropriate.

Document Quality

The document is readable to a native speaker of English.