[Ballot comment]
Suggestion:
OLD:
o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
addresses by starting RENEW actions when the current addresses'
lease time are expired or they receive the reconfiguration
messages initiated by the DHCPv6 servers.
NEW:
o Hosts that are configured through DHCPv6 [RFC3315] obtain new
addresses through the renewal process or when they receive the reconfiguration
messages initiated by the DHCPv6 servers.

The reason for the proposed change is that renewal doesn't happen at expiry time, and addresses aren't changed through the Renew process. The current text is less specific, but probably specific enough for the context, and I suspect more helpful to the reader at this point in the document.

I'm really skeptical that this paragraph bears any relationship to reality for any enterprise setting larger than a SOHO configuration:

Usually, the new short prefix(es) comes down from the operator(s) and
is received by DHCPv6 servers or routers inside the enterprise
networks (or through off-line human communication). The short
prefix(es) could be automatically delegated through DHCPv6-PD. Then
the downlink DHCPv6 servers or routers can begin advertising the
longer prefixes to the subnets.

Are you actually seeing this in practice? I would expect an enterprise-level site to have a negotiated prefix which is statically configured and controlled via contract, not via protocol. This scenario certainly could happen in a home environment or a home office environment, but this document doesn't seem to be addressing that use case. You do mention off-line communication in parentheses, but I really think that should be what you lead in with—it doesn't make sense to me otherwise. I am of course willing to be persuaded on this question—I think it's a bit speculative at the moment since I don't know of a lot of enterprises that do production IPv6 internally yet. Did you ask the Google guys what they do?

When subnet routers receive the longer prefixes, they can directly
assign them to the hosts. Host address configuration, rather than
routers, is the primary concern for prefix assignment which is
described in the following section 5.1.

What does it mean for a router to assign a prefix to a host? Do you mean "advertise a prefix on a link to which hosts are connected?"

Another limitation of DHCPv6 reconfiguration is that it only allows
the messages to be delivered to unicast addresses. So if we want to
use it for bulk renumbering, stateless DHCPv6 reconfiguration with
multicast may be needed. However, this may involve protocol
modification.

This is not accurate. The DHCPv6 server has a complete list of all clients on any given link. It can issue unicast reconfigure messages to each client, if desired. Multicast DHCPv6 reconfigure is not an option, because it's too easy to use it for a DoS attack.

I notice also that you don't mention the 'A' bit in router advertisements. I think this bit also affects the behavior of various stacks; I'm not sure, but I think it probably should be discussed.

Section 6.1 talks about DDNS as a way to update IP addresses on names during a renumbering event. I'm not at all clear on what the use model for this would be. If we're renumbering servers, then certainly you could configure each server with its own key to use for doing updates, so that it could poke its new SLAAC- or DHCPv6-derived address into the DNS. I'm not sure this is a good _idea_, but it's eminently doable.

As for non-server hosts, have the authors read RFC 4704? For hosts that are numbered using DHCP, RFC 4704 addresses this problem.

It would certainly be helpful to have support for automatic renumbering on the DNS server, or to use the DHCP server to do renumbering, in cases where this makes sense, but I think that in practice either you have an IPAM system that's going to do all the poking around, or you are using DHCPv6 for non-server hosts and DDNS for server hosts, or the sysadmin is going in and manually changing settings. I hate this last solution, but if it's ten servers, that's not the end of the world. It would not work in a cloud hosting environment or anything like that, but I don't get the impression that that is the use case this document is addressing.

The document also mentions A6 records, which are deprecated (RFC 6563), and therefore ought not to be mentioned.

(Addresses of DHCPv6 servers do not need to be updated. They are dynamically discovered using DHCPv6 relevant multicast addresses.)

While this could be true in principle, it isn't true in practice, because most relay agents have the option of being configured with DHCPv6 server addresses rather than sending to a multicast address, and I think it's more common to do unicast than multicast for this step. So the document shouldn't assume that this is a solved problem. Even in the case of multicast, it's necessary for multicast routing to be configured and working in order for DHCP messages to find their way to servers. In theory a renumbering event shouldn't break multicast routing, but in practice it might.

The DNS server addresses for hosts could be configured by DHCPv6. In
stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
specify valid time for the DNS configuration. But in stateful DHCPv6,
current protocols could not indicate hosts the valid time of DNS
configuration. If the DNS server has been renumbered, and the DHCP
lease time has not expired yet, then the hosts would still use the
old DNS server address(es). It might be better that the hosts could
renew the DHCP DNS configuration before the lease time, especially
there might be some extreme situations that the lease time need to be
long. In this case how the DHCP server could learn the proper DNS
configuration valid time is also an issue.

There are a bunch of problems with this. First, the stateful DHCP T1 and T2 times are effectively equivalent to the stateless DHCP Information Refresh Timer (DHCPv6 doesn't talk about leases or lease times, so this term should not be used; rather, addresses have lifetimes, and IAs have T1 and T2 timers that indicate to the client when to renew or rebind, respectively). So there is no need for an additional timer in stateful DHCPv6; indeed, it doesn't make sense to add one just for renumbering. How would you know what value to set it to? Why wouldn't you just set T1 to that value?

Next problem: in a typical renumbering scenario, the old and new prefixes are both valid. The old prefix is deprecated, but still works. So the DNS server is still reachable at the old address: there is no interruption of service. Deprecated addresses and prefixes decay gracefully, so that by the time they are gone, everybody has renumbered. Hence, the scenario being described here should never happen unless someone unconfigures the deprecated address on the DNS server before all the hosts have stopped using it. That would be an administrative error.

Section 6.3 appears to be a pair of solutions, not a gap. It is described as a gap, in the sense that the solutions are lacking, but it's not describing the actual gap. This seems to be putting the cart before the horse. The right thing to do is to identify the gap that this solution would fill, rather than describing the absence of these solutions as a gap.

I think you can probably get a gap out of these solutions pretty easily. I think the gap you are talking about is that there isn't a way to trigger configuration updates for all the subsystems on a server, and all the external databases that refer to that server, on the basis of a change to the server's IP address. I am not positive that you need to change the way you are approaching this, because I think the solutions you are talking about are interesting, but this section really doesn't feel like it's a gap analysis as written, so starting from what the gap is and talking about how it could be addressed might help.

More examples in this section might help: I think the tunnel endpoint example is a really good one to use. There are probably some other examples that would be good here—e.g., I have static IP addresses configured in my nginx configuration. This isn't really the gap—I ought to just put domain names in. But unless the tunnel endpoint or nginx notices that the addresses returned for that domain name have changed, it will keep blindly using the old address until something triggers it to do a refresh or a restart. You mention this in 5.2, but it should be mentioned here as well, since as far as I know most services do not actually refresh DNS information until they are triggered somehow to do so.

In section 7.2, what do you mean by "no mechanisms?" There are mechanisms—if you know a renumbering event is coming up, you probably ought to shorten your TTLs. This won't work if you have no advance notice of the renumbering event, but the document _seems_ to be talking about orderly renumbering.

If you are doing an orderly renumbering, where the old prefix is deprecated and the new prefix is added, then your TTL may be longer than the time to the deprecation of the old prefix. This should be avoided—your SLA with the ISP should state a notice period for renumbering that is longer than your TTL, or to put it the other way, your TTL should be shorter than the notice period. RFC 4192 Section 2.2 talks about this at length, so I presume the authors of this document are familiar with the process.

Is the gap you are talking about the lack of a way to set all the TTLs for a site to no more than a particular value? If so, that is not clear here. Or is it the lack of a way to update the names, first adding the new addresses, and later removing the old addresses? Again, if that is what is intended, it should be made clear.

Section 10.2 mentions the A6 record again. I don't think this is helpful, because it died for a reason. I think you should leave this out. Also, I think you need to lead in with the authority problem—my first read of this section really puzzled me, because it seemed to be talking about a problem that is easy to solve, and it was only when I saw the acknowledgement in section 13 that I went and read the chown draft and then reread section 10.2 and understood what the gap was that was being documented.

It looks like 10.3, second bullet, is talking about the problem I mentioned in 6.3 with services not refreshing DNS information. I think the techniques you talk about in 6.3 can address this problem, so I don't think it's an unaddressable gap.