[arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension]

[George, Wes E [NTK]]

Top-posting because I can't figure out a good place to insert into the thread below.

I'm still not necessarily in support of this policy, but I think Bill's suggestions move it in a
more sane direction.

Definitely support #1. Honestly, I'd prefer that some of the folks who are supposedly waiting for
this policy to pass would declare their intent to use it, or at least vocal in their support *on
PPML* prior to the policy's passage so that we had a better sense of what the correct interpretation
is, instead of a set of educated conjecture for and against. I had a quick scroll through the
messages on this policy and the PP before it, so I may have missed some, but I see precious few ISP
representatives commenting. Owen has been representing "their" interests by proxy in this most
recent thread. But I understand that perhaps that's a combination of one's day job impeding on PPML
timeslices and not wanting to publicly express private plans, so if the best we can do is to ask for
registration (that may remain private) after the fact, so be it. 

And I think I like #2 as well, at least in spirit. I understand the reason that CGN needs to be
deployed, but that doesn't mean I have to like it or by policy enable it to stick around longer than
absolutely necessary. The idea behind this whole CGN debacle is that it's supposed to be a temporary
measure to compensate for the fact that we (collectively) are not to a point where expecting some
majority of users to be able to survive without IPv4 is even plausible for most ISPs, and that event
horizon is probably at least 2 years out. I think it's reasonable to expect at some point that this
needs to sunset in order to ensure that ISPs don't start to use it as a crutch to delay IPv6 support
or lessen the pressure on content providers and equipment manufacturers to support IPv6 fully.
Perhaps to address Owen's concern we could update it so that if only 9 are left, one can
request/justify that it become an allocation for them, and they continue sharing it amongst
themselves?
My only concern would be enforcement. How does ARIN determine conclusively who is using it? It's not
like it'll show up in the routing table... While you might get the first 10 to register so as to
ensure the policy doesn't void out, there stops being an incentive for subsequent parties to
register after that.
I could see this being one of those things where the ISPs using it don't see fit to update ARIN when
they stop, and even if ARIN asks, they might not get an answer. 
Also, what happens if it gets used outside of the ARIN region? That's been discussed on and off as
an expected side effect, but if the users have no business relationship with ARIN, should they still
register? What if no one is using it in ARIN region, but it's still in heavy use elsewhere? Do we
still put it back in the free pool?

Thanks, 
Wes George
-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Thursday, February 24, 2011 11:43 AM
To: William Herrin
Cc: George, Wes E [NTK]; ARIN-PPML List
Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address
Extension]

I would support change number 1.

I would argue that change number 2 is unnecessary and potentially harmful.
Why should 9 ISPs who have made very large use of this space suddenly have it revoked simply because
they are the last 9 to deprecate its use?

Owen

On Feb 24, 2011, at 8:27 AM, William Herrin wrote:

> On Wed, Feb 23, 2011 at 11:16 AM, Owen DeLong <owen at delong.com> wrote:
>> I think that isn't the argument. I think the argument is we have one 
>> or more mega-ISPs wanting this policy to pass, but if it does not, will be forced to apply for
resources for [NAT444].
>> Current policy allows for them to number the necessary hosts 
>> accordingly, so, if this policy does not pass, there is nothing at 
>> all that would prevent them from each obtaining large blocks of 
>> addresses for this purpose. I don't know if any one of them could 
>> justify a /10 individually, but, I am quite certain that they can collectively easily exceed a
/10. I'd estimate that they can probably come close to a /7, collectively.
> 
> s/forced/choose/
> 
> They -could- choose to use RFC1918 addresses. They won't for all the 
> reasons you've said. But they could.
> 
> Otherwise, agree with everything above.
> 
> 
> So, Wes, Owen: Let's put our money where our mouths are so to speak.
> If these addresses won't be wasted, let's require the policy to prove 
> it. Adjust the policy so that:
> 
> 1) Within 6 months of ratification at least 10 ARIN allocation holders 
> must register with ARIN an intent to use addresses within the /10 in 
> their network within 24 months. If fewer than 10 register that intent 
> then the policy is void and the /10 is returned to the ARIN pool.
> 
> 2) After the first 24 months and every 24 months thereafter ARIN must 
> review the use of the /10 and make a positive determination that at 
> least 10 ARIN allocation holders are actually using it. If fewer than
> 10 are using it and ARIN does not otherwise have at least a 
> /8-equivalent available for allocation (i.e. IPv4 isn't yet on the 
> decline), the whole pool is recycled into ARIN's free pool with a 12 
> month delay for the 9 or fewer folks using it to renumber.
> 
> 
> Owen, if we can't find 10 ISPs who are willing to step up and say 
> they'll use these addresses then Wes will have made his point: this 
> won't be a good use of a /10. Can you accept that result?
> 
> Wes, if a non-trivial number of ISPs actually use the addresses in 
> parallel then plainly this was a better use than assigning the 
> addresses to ISPs individually. Can you accept that result?
> 
> 
> I hear a lot of ideology in this debate. Are either/both of you 
> willing to measure and follow the data instead?
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> 
> Falls Church, VA 22042-3004


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6781 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110225/2d90e361/attachment.p7s>