I actually pretty much agree with everything Mr. Herrin states in the below email.
-Blake On Dec 24, 2014 1:26 PM, "William Herrin" <[email protected]> wrote: > On Wed, Dec 24, 2014 at 12:28 PM, John Curran <[email protected]> wrote: > > On Dec 24, 2014, at 11:50 AM, William Herrin <[email protected]> wrote: > >> I think this is bad policy which will encourage registry shopping by > >> large multinational companies who really don't need yet another > >> advantage over their smaller competitors. Worse than just making ARIN > >> a flag-of-convenience registry to the world, it includes just enough > >> in-region requirement to shut out small players. I reiterate my > >> OPPOSITION to this draft policy. > > > > Is there are any change to the draft policy which would address > > your concerns regarding it? More specifically, if the community > > support for the policy ends up being strong due to a perception > > that it addresses an existing policy flaw, is there any change > > that would mitigate the harm to small players that you outline > > above? > > Hi John, > > I'm don't think there is such a change but there are a few things that > jump out at me as being particularly offensive. > > 1. This issue is not a concern for ARIN number resources overall. Now > and for the foreseeable future it frankly only matters for IPv4 > addresses. Crafting a one-size-fits-all policy here needlessly > complicates the matter. No one here cares whether AS numbers or IPv6 > addresses are used out-region and burning one single staff minute > analyzing the acceptability of such is a waste. Worse, crafting the > policy to act reasonably with the other number resources corrupts its > ability to deal correctly with the IPv4 situation. > > 2. I disagree with spinning it as an existing policy flaw. There's a > ARIN -implementation- flaw here. Classically and consistent with the > spirit of ICP2, the RIRs allow minor outregion use of addresses that's > incidental to an in-region operation. And you know what? You haven't > been the slightest bit shy about deciding that external documents like > ICP2 and RFC2050 constrain ARIN activity in other matters like the /10 > for large scale NAT. I don't know how ARIN got itself twisted up where > it couldn't find the limits of "minor" and "incidental" but trying to > override that with rigid policy requirements is going to be > problematic. > > 3. Registry shopping is a bad bad bad idea. It defeats and is directly > contrary to the whole ICP2 spirit of LOCAL self-governance. As > written, this policy doesn't discourage region shopping, it codifies > it. RIPE policies gotcha down? No sweat, we'll buy a cage in Ashburn > Equinix and use that as a jumping board to shop ARIN instead. As long > as you're big enough to afford that cage and the servers inside, this > policy removes all limits. > > 4. Limiting the registrants to folks making a notional use of IP > addresses or a single AS number somewhere inside the ARIN region just > makes it worse. There's already a fairness gulf between shops large > enough to employ a dedicated number resource group and those who must > rely on consultants and luck to find a path through the registries' > arcane rules. The 1AS/22/44 rule poses no real obstacle to a > multinational grabbing addresses where convenient but it sows even > more challenge and confusion for a smaller shop. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ [email protected] [email protected] > Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> > May I solve your unusual networking challenges? > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
