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

[Gary Giesen]

On 10-10-07 3:37 PM, "Owen DeLong" <owen at delong.com> wrote:

>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.

If this is truly the case, I think the market will decide, and users will
move to those ISPs that make the move to native connectivity


>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.

I agree that this can seriously have the potential to again create the
same dual-class networks (Legacy vs post-RIR) we have in v4, where those
who got in early got a vast amount of address space and those who came
later were less fortunate.


>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).

I can live with this, although I expect these will live much longer.

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

In considering your arguments (and some of my responses), I'm now leaning
this way as well. I think it's actually a good thing that we attach some
sort of stigma to these prefixes to emphasize their temporary nature.

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

What do you propose these are?

>
>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)

Seems entirely reasonable.