[arin-ppml] Opposed to 2010-9 and 2010-12

[Owen DeLong]

My biggest concerns with both policies and with 6rd in general are as follows:

1.	If it becomes a permanent deployment, it will seriously degrade end user
	capabilities and stifle innovation and place unnecessary limits on future
	product development. Thus, while it doesn't contain the same evils as
	NAT, it may actually have a similar impact to NAT in some ways.

2.	As much as I favor liberal allocation/assignment of IPv6 space and
	don't generally tend to accept most of the conservatism arguments,
	6rd is impressively wasteful, even by my standards. We've got the
	ability to support it as a short-term solution, but, I'd hate to see these
	assignments become in any way permanent usage.

As such, I cannot support any 6rd or transition policy which does not have
the following safeguards:

1.	A time horizon of not more than 5 years before the space is to
	be deprecated. (If there is need for an extension, a policy amendment
	can take care of this problem).

2.	Space from a separate prefix which can be reclaimed in its entirety
	and filtered by service providers to facilitate the aforementioned
	deprecation.

3.	Strict limits on the maximum prefix size to be allocated to any organization
	to facilitate the technology.

4.	Limitations of not more than 3 such allocations for different transition
	technologies per organization. (If you want to deploy a third, then,
	deprecate the first and return that space before you can get a fourth)

Owen