Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-06

I was thinking some of the same things as Stephen regarding logging and IPSec.

- Section 1.3

Each administrator must decide whether
   to begin with the External Phase (as recommended in [RFC5211]) or the
   Internal Phase. 

A quick search in [RFC5211] doesn't help with the External Phase definition.
You should refer to section 3, and 4 respectively. 
Or ideally provide a quick definition here, because without definition I can't understand the bullet points (well, to be candid, I can guess, but you get my point)

- 
      It is worth noting that a number of emerging
      VPN solutions provide dual-stack connectivity; thus a VPN service
      may be useful for employees in IPv4-only access networks to access
      IPv6 resources in the enterprise network (much like many public
      tunnel broker services, but specifically for the enterprise).

You might want to point to http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/

- OLD:
   It is generally recommend that the application
   developer use industry IPv6-porting tools to locate the code that
   needs to be updated.

NEW:
   It is generally recommended that the application
   developer use industry IPv6-porting tools to locate the code that
   needs to be updated.

- Might want to get a reference to RFC 7011 and 7012 in
   Moreover, if all the intra-enterprise traffic is
   encrypted, then this renders a lot of the network security tools
   (IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless.

Same remark here
   Monitoring the use of the Internet connectivity should be done for
   IPv6 as it is done for IPv4.  This includes the use of IP Flow
   Information eXport (IPFIX) [RFC7012] to report abnormal traffic
   patterns (such as port scanning, SYN-flooding, related IP source
   addresses) from monitoring tools and evaluating data read from SNMP
   MIBs [RFC4293] (some of which also enable the detection of abnormal
   bandwidth utilization).  Where Netflow is used, version 9 is required
   for IPv6 support.
NEW:
Monitoring the use of the Internet connectivity should be done for
   IPv6 as it is done for IPv4.  This includes the use of IP Flow
   Information eXport (IPFIX) [RFC7011][RFC7012] to report abnormal traffic
   patterns (such as port scanning, SYN-flooding, related IP source
   addresses) from monitoring tools and evaluating data read from SNMP
   MIBs [RFC4293] (some of which also enable the detection of abnormal
   bandwidth utilization).  Where NetFlow is used, version 9 (RFC 3954] is required
   for IPv6 support.

- Section 3.3
I guess the title should be "Traffic Monitoring".
If it's not, you should speaking about syslog (over IPv6) as well.

Just a few non-blocking comments...

1. Section 2.1 takes a little too much time describing how the champion and project manager should run an IPv6 project.  I think this takes away from the key message of "plan ahead of time".

2. In Section 2.3, it is unclear if the training is meant for everyone in the organization or just those staff members responsible for managing/maintaining the network and the connected equipment.

3. Section 2.6 contradicts some entities approach of shrinking subnets to the smallest possible size in order to preclude rogue devices from attaching and obtaining an address.

Overall, this is a very helpful draft, thanks for taking the time to do it.

I spotted similar things to Stephen and agree on the point of adding some mention of logging as well as log protecting.  I think there should also be mention in section 3.3, monitoring for external networks in addition to the earlier section Stephen referenced.  In case it is helpful for section 3.3 & 3.4, this would apply to the network (filters) as well as to servers and applications, not just firewalls.

Nit: first use of CDN in section 6.1 isn't spelled out.

- 1.2: saying one should log stuff is probably right here.
However, it'd also be good to say something about protecting
those logs, (access to which could expose various things) 
and about periodically flushing them for privacy reasons if
that's not elsewhere. Just a sentence or two would probably
be fine.

- 2.4.1: I think the "pretty much useless" statement about
IPsec reads as if biased, which doesn't seem right. One
could argue that malware can benefit just as much as an IDS
from snooping on packets for example, even if that is
nowhere near as common today. Fixing the language in that
paragraph would be good so that it doesn't have to be
changed if malware migrates over time from end hosts to
e.g. the routers and switches within an enterprise network. 

- 4.3: is the text about smartphone support for IPv6 still
accurate? I don't know that its not, but it does read as
if written some time ago.

- 4.3: I wondered why there are no recommendations about
printers specifically when those only support IPv4. Is
there nothing to say about discovery there? I don't know
that there is but would have thought it possible.

- 4.4: would have thought that specific mention of web
proxies would be useful here - locally, we've had issues
with those even after mail all works fine.

- The secdir review spotted a few nits. [1]

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04843.html