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.
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099- Office
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
-----Original Message-----
From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf
Of Ted Mittelstaedt
Sent: Monday, October 27, 2014 6:09 PM
To: arin-ppml@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"
Ted
>> 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.
>
> --MM
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
