[arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation Update

[Martin Hannigan]

Support. I wrote what appears to be "the offending language" in order to
clean up vague, unclear language already memorialized in the existing
policy.

To wit:

"ISPs and other organizations receiving these micro-allocations will be
charged under the ISP fee schedule, while end-users will be charged under
the fee schedule for end-users. This policy does not preclude exchange
point operators from requesting address space under other policies."

I support removal of this and the proposed language related to defining the
fee structure. The rest of the proposal is not about abuse, it's about
conservation and helping infrastructure to grow _and_ succeed in the ARIN
region. A distinction does not need to be made between one area of the
region or another. I am in support of the change from two to three, or
more.


Best,

-M<






On Tue, Feb 11, 2014 at 12:25 PM, John Springer <springer at inlandnet.com>wrote:

> Opposed as written.
>
> Agree with the following reasoning. I am OK with the 2 -> 3 change.
>
> John Springer
>
>
> On Tue, 11 Feb 2014, Heather Schiller wrote:
>
>  I oppose the policy as written.
>> I don't have an opinion on the 2 vs 3, though I see it as such a small
>> change and given the total number of CI IX assignments (66 over
>> how many years?) it won't significantly change anything.
>>
>> I am opposed to the policy because of this line " IXP's formed as non
>> profits will be considered end user organizations. All others will
>> be considered ISPs."
>>
>>  This statement will impact the overwhelming majority of Critical
>> Infrastructure assignment holders, the majority of which are not IX's.
>>  The goal of attempting  preservation should be done by how the
>> allocation is justified, not how much the entity is billed.   111 of the
>> CI allocations are not to IX's.  Of the 66 IX allocations it is nearly
>> split between end users and ISP's.
>>
>>
>>
>>
>>
>> On Fri, Feb 7, 2014 at 10:05 AM, Brandon Ross <bross at pobox.com> wrote:
>>       On Thu, 6 Feb 2014, Owen DeLong wrote:
>>
>>             I oppose the change. Anyone inclined to abuse a two
>> participant standard can easily create or obtain a 3rd
>>             participant for said purpose. This is literally a case of
>> change for the sake of change. No, a 3 participant
>>             minimum is not an unreasonable standard. However, since it
>> does have some negative impact and is utterly
>>             unlikely to be at all effective in deterring abuse, I see no
>> benefit to the change.
>>
>>
>> I agree with Owen on all points and oppose the policy change.  Most
>> importantly, this policy change significantly raises the bar
>> for a legitimate IXP to get started while doing nothing effective to
>> prevent what is, effectively, a tiny amount of potential
>> abuse.
>>
>> --
>> Brandon Ross                                      Yahoo & AIM:
>>  BrandonNRoss
>> +1-404-635-6667                                                ICQ:
>>  2269442
>>                                                          Skype:
>>  brandonross
>> Schedule a meeting:  http://www.doodle.com/bross
>> _______________________________________________
>> 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/20140211/b031b2d1/attachment.htm>