<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>I don't know...maybe some such...<BR>
<BR>
Perhaps a trendline estimate just before the Fall meeting.  If there is lots of uptake for transitional technologies in that time frame, then wait until the Spring meeting to assess again.....At each inspection period (meeting time?), estimate the amount of space needed against the uptake history out to 2yrs.  Same this amount and release the remainder if any to the pool then....or if it appears that all will be used with transitional technologies, save it. At the end of 2 years, either way, return what's left to the free pool.<BR>
<BR>
Augment the list of non-transitional uses with a maximum allocation size (say /24) that may qualify over that same period of time.<BR>
<BR>
Or, one could authorize an abbreviated 'emergency' allocation process for the list, given AC and BoT agreement and a 'last call' to PPML, addresses could be allocated.<BR>
<BR>
I think it is likely to be obvious whether transitional technologies or IPv6 uptake are the predominant mechanisms going forward by end of calendar year '11.<BR>
<BR>
One can't predict the future, but such a mechanism could provide some flexibility.  I do think that having addresses available for transition rather than same ol', same ol' is best.<BR>
<BR>
bd<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Scott Leibrand [<A HREF="mailto:scottleibrand@gmail.com">mailto:scottleibrand@gmail.com</A>]<BR>
Sent: Wed 11/24/2010 6:22 PM<BR>
To: Bill Darte<BR>
Cc: arin-ppml@arin.net<BR>
Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development<BR>
<BR>
What criteria would you use for "not being effectively utilized"?<BR>
Less than X% of the space given out Y months after exhaustion?  Less<BR>
than Z requests fulfilled under 4.10?<BR>
<BR>
What other uses would be appropriate?  All valid requests?  Limit it<BR>
somehow to avoid giving out all of the remaining reserved space at<BR>
once to people on the waiting list?<BR>
<BR>
-Scott<BR>
<BR>
On Wed, Nov 24, 2010 at 4:20 PM, Bill Darte <BillD@cait.wustl.edu> wrote:<BR>
> Leave 4.10 space for what it is now for.<BR>
> Establish, if need be, an adjunct policy that allows that pool to be raided<BR>
> for other uses if after a period of time 6, 9, 12 months indicates that it<BR>
> is not being effectively utilized.<BR>
> Crumbs!<BR>
> bd<BR>
><BR>
><BR>
> -----Original Message-----<BR>
> From: arin-ppml-bounces@arin.net on behalf of Scott Leibrand<BR>
> Sent: Wed 11/24/2010 6:14 PM<BR>
> To: Hannigan, Martin<BR>
> Cc: arin-ppml@arin.net<BR>
> Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy<BR>
> Development<BR>
><BR>
> On Wed, Nov 24, 2010 at 3:57 PM, Hannigan, Martin <marty@akamai.com> wrote:<BR>
>><BR>
>> On 11/24/10 11:53 PM, "Leo Bicknell" <bicknell@ufp.org> wrote:<BR>
>><BR>
>>> In a message written on Wed, Nov 24, 2010 at 01:08:38PM -0800, Owen<BR>
>>> DeLong<BR>
>>> wrote:<BR>
>>>> Hence my suggestion that 122 would be more palatable if it set aside<BR>
>>>> a separate /10 for that purpose rather than raiding 4.10.<BR>
>>><BR>
>>> I would not object to a second /10, but I'm sure I see it as necessary.<BR>
>><BR>
>><BR>
>> It would only amplify the defects in 4.10.<BR>
><BR>
> So do you see the problem as being that 4.10 will leaving addresses<BR>
> reserved for too long without putting them into use?<BR>
><BR>
> If so, would there be additional criteria for giving out 4.10 reserved<BR>
> space that would alleviate the defects in 4.10 from your perspective?<BR>
><BR>
> -Scott<BR>
> _______________________________________________<BR>
> PPML<BR>
> You are receiving this message because you are subscribed to<BR>
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
> Unsubscribe or manage your mailing list subscription at:<BR>
> <A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
> Please contact info@arin.net if you experience any issues.<BR>
><BR>
><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>