[arin-discuss] Policy clarification

IPTelligent SysOp sysop at iptelligent.com
Mon Jun 28 12:49:48 EDT 2010


Ted,
  
I think you have mistaken my statements as if I was the unsatisfied 
user for having the allocation denied.
  
a) It's not my project. Not a customer of mine too. No interest in 
having that guy as a customer also (as you noticed I don't want 
political problems), I just wonder about them and the backend reasons.
  
b) No interest in trolling or complaining. I'm happy with the current 
allocations and have no need for extra ones, nor have any problem with 
any denied or pending request so far. 
     If I had them I would certainly voice to hostmaster. If the 
hostmaster reply wasn't satisfactory, then I would voice it on the 
list.   
     In fact I agree with a restrictive policy, but the interest in this 
thread is to know more detailedly about what can and what cannot be 
done and the scrutiny process, in order exactly to avoid action based 
on the oneliners or "the fine print". What everyone here doesn't want, 
I think, is the _surprise_ of allocating in good faith for such 
projects (being for commercial or humanitary reasons) and then later 
beind denied expansion in the ground of "unjustifiable reasons" for the 
current blocks.
  
c) If allocating IPs are matter of public policy, then it should have a 
sufficient level of discretion in order for the requesters to know 
exactly and objectively why it was denied as any public office 
transparency needs, instead of a subjective judgement. It is a 
technical reason? It is a political reason? It is something that is a 
taboo that can't be touched? It would be sufficient to have an official 
statement "the allocation for this application cannot be allowed since 
it will /a/generate political problems between RIRs or giving ammo to 
governments to try to control us/a/ /b/uselessly spend IPv4 addresses 
that are already in shortage /b/ /c/". Or a statement on the NRPM 
detailing upfront which applications/uses are allowed and which are 
denied, or exemplifications of what will be accepted and what will not 
be accepted. 
  
c) As Aaron, I am a so frequent user of the forums (WebHostingTalk) I 
quoted the request that the guy had from. He was in search for 
providers. There was the venue where the issue was raised, practically 
everybody at WHT - meaning representatives of big datacenters, tier 2 
carriers, and all kinds of hosting companies - states this isn't 
justifiable reasons on ARIN grounds (and until now I just echoed them 
as a parrot - and waved goodbye to a handful of prospects who hadn't 
"enough" justification). Of course, most of the prospects that come to 
us want to do something illegal like spamming, others come wanting 
whole /19s for wireless service providing (and buying 1Gbps of service 
from you)
  
d) As an admin with more than 10 years of experience I am pretty aware 
it's easy to block - I agree with that. And any Cisco ASA (5520 up) 
nowadays supports more than 750 simultaneous VPN users (goes up to 
10,000 for the biggest model). Bandwidth nowadays is also not an issue 
and even less an expense (when you can get it for $0.70 per Mbps and 
10GE ports easily). Doable it is, just don't know how much time would 
it last. At the same time, what gets to my mind is that guy must be 
having some success since he's been using tons of addresses from RIPE 
for that purpose.
  
e) Why this process of justification would be faster or simpler in RIPE 
than in ARIN? I mean, we are really discussing a lot for nothing here, 
but it is voicing of past experience that such allocations may bring 
trouble. While in the other side of the Atlantic, it is not an issue at 
all. I'm just trying to understand the differences and reasoning under 
it. As simple as that.
f) Am I wrong in putting this matter for discussion in this list as it 
would not be the correct venue for that? If yes, please someone let me 
know.
  
Regards,
Rafael

------ Original Message ------
From: "Ted Mittelstaedt" <tedm at ipinc.net>
To: arin-discuss at arin.net
Sent: 6/28/2010 12:44:13 PM
Subject: Re: [arin-discuss] Policy clarification
>
>This is the first time you mentioned an allocation as large as a /23 
>in conjunction with this "circumventation "the Great Firewall of 
>China" 
>project" Is that project intending to use a /23? You know 
>you can get an -authoritative- reading by e-mailing the specific 
>details 
>of this project to "hostmaster at arin.net" and by posting here you also 
>know you want opinions in response. And as for throwing in all of the 
>"political issue on government level" rubbish in your original post, 
>it seems evident that your just trolling here. 
>
>As I privately explained to you and as others explained, this scheme 
>isn't going to represent a significant problem for the Chinese admins 
>to block. You have ignored those comments and are just attempting to 
>stir the pot, more evidence of trolling. 
>
>As for Aaron's comment, the definition of "technical uses" is 
>subjective, so at face value his black-and-white statement is wrong, 
>anyone can see that who has read the NRPM or gone through an address 
>block request. Is your goal to throw out random statements until 
>you get someone making a short, incorrect one-liner like Aaron then 
>sit back and watch the firefight? That's trolling. 
>
>If you have something to say about ARIN, then say it. If this 
>circumvention project is real, then post the specific details, 
>how many addresses is it going to use, what platform, etc. It is 
>a fact that not much gear out there will terminate 500 -simultaneous- 
>VPN sessions without rolling over and dying, not to mention pass 
>multiple megabits per sec. of data over all 500 of them 
>simultaneously. 
> And who has the bandwidth for that? Not many. 
>The more comments you make about this "circumvention" project 
>the more obvious it is technically impractical, thus non-existent. 
>
>
>Ted 
>
>On 6/25/2010 2:04 PM, IPTelligent SysOp wrote: 
>>Aaron, 
>>
>>Then I wonder why, last time I requested a second address block for 
>>the 
>>company, I was asked for technical justification for all the 
>>reassigned 
>>and reallocated blocks that were equal to or higher than a /24, based 
>>exactly on SWIP information? Don't remember the exact words now, but 
>>I 
>>was asked "Why did you allocate a /23 to company X, what was the 
>>justification they provided" and how much equipment is connected to 
>>that block, how many hosts, how many shared webhosting, how many etc, 
>>what are the reverse hostnames for each of those IPs? 
>>Isn't that technical use justification, or it's just for statistics 
>>(and then why not mention it's optional)? 
>>For a customer that I had reassigned space from the carrier (and so I 
>>couldn't reallocate to the end user), I had to submit a long customer 
>>list with the subnetting that was made, per customer (not much work 
>>as 
>>the customer collaborated to it, but then, I had to reformat all the 
>>list). Would it be completely unnecessary? 
>>Regards, 
>>Rafael 
>>
>>------ Original Message ------ 
>>From: "Aaron Wendel"<aaron at wholesaleinternet.net> 
>>To: "IPTelligent SysOp"<sysop at iptelligent.com>;arin-discuss at arin.net 
>>Sent: 6/25/2010 5:52:10 PM 
>>Subject: RE: [arin-discuss] Policy clarification 
>>>ARIN does not specify technical uses for IP address space. 
>>
>>
>>_______________________________________________ 
>>ARIN-Discuss 
>>You are receiving this message because you are subscribed to 
>>the ARIN Discussion Mailing List (ARIN-discuss at arin.net). 
>>Unsubscribe or manage your mailing list subscription at: 
>>http://lists.arin.net/mailman/listinfo/arin-discuss 
>>Please contact info at arin.net if you experience any issues. 
>_______________________________________________ 
>ARIN-Discuss 
>You are receiving this message because you are subscribed to 
>the ARIN Discussion Mailing List (ARIN-discuss at arin.net). 
>Unsubscribe or manage your mailing list subscription at: 
>http://lists.arin.net/mailman/listinfo/arin-discuss 
>Please contact info at arin.net if you experience any issues. 





More information about the ARIN-discuss mailing list