[arin-ppml] 2014-1 Out of Region Use
SRyerse at eclipse-networks.com
Mon Oct 27 20:23:53 EDT 2014
If in the spirit of trying to prevent fraud non-fraudulent requests get rejected, then Arin's mission stops being fulfilled. I think it is important to make sure the mission is respected first and stopping fraud second or third or fifth or whatever. We could stop all fraud by stopping all allocations but of course that makes no sense. I would also point out that even when fraud happens Arin's Mission is still being fulfilled.
Of course maybe if the needs tests were loosened fraud would be significantly reduced as there would be no need to submit fraudulent requests. I'm sure an org willing to submit a fraudulent request would tell you that they do have a need but they may not happen to meet the current arbitrary (and they are arbitrary) policy.
I know there are members of this community who think that there is no way we could loosen needs tests but of course - we could loosen them if we want and I don't think the Internet world would come to an end. It hasn't in other regions. My two cents.
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt
Sent: Monday, October 27, 2014 6:09 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2014-1 Out of Region Use
On 10/22/2014 12:49 PM, Milton L Mueller wrote:
>> -----Original Message-----
>>> "ARIN reserves the right to request a listing of all the applicant's
>>> number holdings in the region(s) of proposed use"
>> I feel it should be eliminated. As it was mentioned at the microphone
>> in the Baltimore meeting, ARIN isn't consistent in applications of
>> language like and appear to be widely abused. ARIN already has
>> Section 12. Why is that not good enough?
> I agree with Marty here. We could eliminate that, if you all think Section 12 is enough.
I don't think it's enough, John didn't think it's enough, why is there any interest in gutting any possible language that can be used by the RIR to deny obviously fraudulent requests?
I really don't understand this. If a criminal org is clever enough about it, they can obtain resources fraudulently. That is a GIVEN in ALL kinds of crime - if the criminal is smart enough, they are going to get away with it.
Live with it.
That isn't an excuse to roll over and say "well org X got away with it so we might as well give up trying to stop it"
Regulatory language is a matter of degrees. You make something difficult enough to do so that it takes the opportunity to do bad away from those who would otherwise be honest about it.
Banks don't lay $100 bills on the counter in front of the public and ignore them because they know that this is enough to cause some honest people to be dishonest.
The RIR should not make it so easy to fraudulently obtain resources for out-of-area use that the honest users start feeling that it's such a free-for-all that they should join the rest of the fraudulent requesters.
We acknowledge that truly evil orgs are going to do the work needed to fraudulently obtain out of area resources. We can't write policy to end that, but we CAN write policy to keep the honest people honest. And that policy isn't "toss all the clubs out the window"
>> We seem to have completely (as usual) ignored all of the feedback
>> from the microphone at both the PPC and the Baltimore meeting.
> Not at all. All of the proposed changes are directly responsive to mic feedback in Baltimore. If you recall, the prior version had rather complicated and potentially burdensome reporting and review requirements regarding duplication of requests. That was what people complained about (including you). We've eliminated them.
> On the other hand there was direct expressions of support for the general objective from almost everyone, including someone from Microsoft and from Google, neither of whom were AC members, as well as another person whose affiliation I can't recall.
>> resources stating that this is a no op as well: already using
>> numbers in other regions and even ARIN (Curran) chimed in and said
>> that it wasn't a problem.
> I think you're interpretation of the situation is WAY out of line with the reality. Staff wants to STOP out of region use, and is doing so de facto because of the ambiguities in the policy. Yes, lots of people are already using numbers in other regions but if you want to continue to do that with new requests we need to solidify the policy and make it clear that this is ok.
>> Anyone care to address the points, from a technical perspective, that
>> the LEO community raised as well?
> You mean LEAs (law enforcement agencies)? Did you read the comments? Those concerns were addressed:
> "The requirement to have a minimal level of resources deployed in the region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to law enforcement and some community concerns. An absolute threshold ensures that those applying for ARIN resources are actually operating in the region and not simply a shell company, but it avoids the known pitfalls of trying to use percentages of the organization's overall holdings to do that."
>> I really wish the AC would get out of the regulatory business and
>> into the stewardship business.<hope>
> Marty, by opposing this policy you are encouraging and authorizing ARIN staff to restrict and regulate out of region use. You're the advocate of regulatory business here. Make your choice, but at least understand which side you are taking.
> 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:
> Please contact info at arin.net if you experience any issues.
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:
Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML