I have reviewed draft-ietf-v6ops-slaac-renum-03 as part of the ops-dir
review efforts. The document addresses a problem that is of certain
operational relevance. This document is labeled as informational.

Perhaps indicate a bit earlier what unacceptably long means, i.e. we
are talking about days and weeks. The scenarios described read a bit
like somewhat rare events and hence it is useful for the reader to
have an idea what unacceptably long means in such events. (BTW, I find
the scenario not described at the beginning where a router announces
SLAAC lifetimes that are not synchronized with obtained prefix
lifetimes operationally the more tricky problem since this can lead to
regular failures.)

Section 2.2 seems to confuse soft-state (this is what a learned IPv6
prefix is for me) with certain protocol timers. There are many places
where protocols use soft-state and implementations use timers to purge
or refresh soft-state. That timers generally do not go off in normal
conditions is not really correct in this context, DHCP leases are
renewed when their lifetime expires, a normal operation. IP address
mappings to Ethernet addresses expire when their lifetime timer goes
off. Switches purge forwarding state regularly when forwarding entries
expire. Cached DNS name to IP resolutions expire. The only problem
here seems to be that a lifetime of 7 days / 30 days is a bit
ridiculous. Is anyone shipping the RFC 4861 defaults? The few
implementations I have seen do use a bit more reasonable defaults.  I
think this section should be rewritten to replace the "timer going off
is associated with a failure" text with a discussion of	soft-state in
other protocols. (Section 2.2 is why I ticked 'has issues'.)

Isn't a part of the solution (other than moving to less ridiculous
default) that SLAAC hosts experiencing connectivity problems should
try to validate the prefix that they have learned (and if the
validation fails move to a newly learned prefix)? Involving the hosts
in a resolution of the problem may be	more robust than expecting that
something in the network takes care of invalidating stale soft-state.
Well, this comment is likely outside the scope of this problem
statement document.