[arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

[Bill Darte]

Early on in the formulation and debate of 2011-1, needs-basis was established as a principle which the ARIN community wished to retain. In that, it was suggested that having such language would allow ARIN to identify those RIRs which did and did not have that basis for their policy and easily allow or disallow transfer accordingly....  This was said to also make it explicit why ARIN 'did not agree' to transfer blocks to a region where no such basis exists.  In this way, those applicants that were refused would know why.  But would they actually know?  Would ARIN really 'stamp' the denial with that explanation?

Of course, RIRs may find other reasons to 'not agree' as Owen points out and these would not (without amendment) be called out explicitly and would not therefore notify potential recipients in the same way.  Would ARIN still have to publish its reasons for denying applications?...or would ARIN really comment on the basis for denial in either case?...and if such a notice was attendant to the denial, I'm quite sure it wouldn't be made public.

So, the debate over having a needs-basis goes on.  I believe that needs basis has been fundamental to our community's past principles and the RIR regime.  IF that is to change, if 'the market' is the new regime which can 'best' distribute Internet number resources....then needs-basis as we have known it can be omitted from both policy and practice.  But 'best' must be assessed across all its objectives....is it simply efficiency?  Is it efficiency along with fairness where fairness anticipates something more than ability to pay the going price? Does it really matter that need is assessed ultimately by a for-profit agency rather than a do-gooder organization like an RIR beholden to a large and diverse community rather than a few executives?  Is it any different if that for-profit agency is a public corporation with the backing of many shareholders as its ultimate constituency?

What is 'right' for the overall interest of the community...the whole community?  How will 'others' who are for and against the RIR regime interpret this policy and its 'rightness'....which principles of 'best' and 'right' ultimately matter?

All this, and more is what the inclusion or exclusion of a needs-basis clause anticipates.

My personal, non-AC affiliated belief, is that a needs-based regime is the best regime and that our current system of grass-roots policy development is as fair as it can be and thus, I personally favor retaining a needs-based clause.

bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Owen DeLong
Sent: Tue 5/24/2011 12:47 AM
To: Scott Leibrand
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3
 
I still would prefer to see the needs-basis comment preserved as well.

Owen

On May 23, 2011, at 10:07 PM, Scott Leibrand wrote:

> So perhaps:
> 
> + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies.
> 
> I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below...  Thoughts?
> 
> Scott
> 
> On May 23, 2011, at 9:56 PM, Owen DeLong <owen at delong.com> wrote:
> 
>> I prefer to preserve the safety valve of requiring agreement from both RIRs.
>> 
>> Owen
>> 
>> On May 23, 2011, at 8:53 PM, Frank Bulk wrote:
>> 
>>> Why don't we change the second point to:
>>>  
>>> + to another RIR, for transfer to a specified recipient in that RIR's service
>>> region, if the request meets both RIRS' transfer policies.
>>>  
>>> Frank
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> ----- Original Message -----
>>> From: Scott Leibrand
>>> To: Owen DeLong
>>> Cc: ARIN-PPML List
>>> Sent: Monday, May 23, 2011 5:21 PM
>>> Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3
>>>  
>>> On Mon, May 23, 2011 at 2:05 PM, Owen DeLong <owen at delong.com> wrote:
>>> I could support this, but, I have a couple of lingering concerns.
>>>  
>>> I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region.
>>>  
>>> Yeah, I was wondering about that myself.  Possible slight revision inline below...
>>> 
>>>  
>>> On May 23, 2011, at 15:54, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>> 
>>> In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous.  Here's what I came up with:
>>>  
>>> 8.3. Transfers to Specified Recipients
>>> 
>>> In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN by the authorized resource holder, in whole or in part, for transfer:
>>> to a specified organizational recipient within the ARIN region, or 
>>> to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies.
>>> Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies.  
>>>  
>>> How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ?
>>>  
>>> Or, feel free to suggest text...
>>>  
>>> -Scott
>>>  
>>>  
>>> For reference, existing policy reads:
>>> 8.3. Transfers to Specified Recipients
>>> 
>>> In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies.
>>>  
>>> And original 2011-1 text reads:
>>> Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>  
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>  
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110524/d675ce5e/attachment.htm>