[renum] comments on draft-jiang-6renum-enterprise-00

["George, Wesley" <[e-mail]>]

2 - I don't think that it's necessary to assume that the *network* is IPv6-only, or to call dual-stack a complicated IPv4/IPv6 coexisting scenario. Your current language makes this work irrelevant for 99.9% of the networks out there today (because they are either dual-stack or IPv4-only), which I think is probably not what we're going for when we say that IPv4 is not in scope.
I understand what you're trying to say with the comment "logical IPv6 plane is independent from IPv4" but I think there's probably a clearer way to say it.
In other words, it's perfectly acceptable to have a dual-stack network and leverage these recommendations. You just simply need to say that IPv4 renumbering is not directly covered by this work and if a network is dual-stack, IPv4 renumbering will have to be treated separately. Consider the fact that IPv4 and IPv6 allocations are often different, and while a topology change may trigger renumbering for both address-families, it is also possible that a dual-stack network has other events that trigger a renumbering event on just one of  multiple address-families. You could possibly identify which of these techniques are IP version-agnostic and therefore applicable to IPv4, but note that the further gap analysis will not focus on improving IPv4 renumbering where it diverges from IPv6.

3- I would recommend reviewing and categorizing the renumbering reasons in RFC2071 specifically in a subsequent revision, rather than your current generalization that some are out of date/not suitable. For that matter, should this document formally update RFC2071?

3.1/3.2 - Right now you have this somewhat limited to PA space -  you don't actually say that, but your use cases/examples are all making that assumption, and I doubt that was your intent.
Depending on how successful RIRs have been at doing sparse allocations, it's quite possible that if a network needs to request a larger block (assuming that they have a PI allocation) from their RIR, they may receive an entirely new block rather than simply having their existing block's bit-length changed. This will trigger a renumber similar to a switch to a new ISP.

4.1 Address types -
Does this draft need to discuss the common reasons for using statically-defined addresses, and perhaps identify some ways to reduce? You mention FQDN and DNS updates elsewhere in the document, but it may be useful to explicitly note that here. Also, I know you have a  placeholder entry for that in 5.3 of the gap analysis draft, but I would think that it would start here with things that can be done (BCP) today...

while this isn't necessarily a current use of ULA, http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 is specifying use of ULA in the Smart Grid

5 - I don't understand what that first item "manual or script-driven procedures..." means/refers to - can you attempt to clarify in the next revision?
Also, doesn't most of this section belong in the gap-analysis draft?

Thanks,

Wes George
speaking as individual contributor


________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.