[arin-discuss] tweak to proposed fee schedule

[Owen DeLong]

I don't think that is true at all.

I think, rather, that the boards taking a "compromise proposal" which included /36 into policy in order to try and accommodate the issue of x-small ISP blocks (previous boundary was /32) and going even a step beyond that compromise is now forcing us to consider the fact that perhaps  making policy to work around problems with the fee structure is not the optimal solution to fee problems and that we should, instead, address the problems with the fee structure head on.

I think that Michael Sinatra's proposal provides a fair and balanced way to address that concern in the fee structure. Once the fee structure is updated such that there is no longer a financial incentive to request a smaller than /32 block, that the policy support for /36 would become anachronistic and could be easily deprecated by consensus of the community.

I think that the goal here is actually to avoid issuing smaller than /32 blocks to ISPs. When the concern was issuing /36s, it was an unpleasant compromise from the /32 ideal. When we started talking about moving to /40, /44, or /48, it rapidly became evident that the community absolutely lacked support for /44 or /48 and that /40 was considered far from ideal.

Owen

On Apr 11, 2013, at 13:11 , Mike A. Salim <msalim at localweb.com> wrote:

> Thanks John, I stand corrected - the policy is indeed worded as you state.
> 
> Having said that, the policy as proposed for the July implementation, has left me with the impression that ARIN is having regrets about parceling out /32 blocks early on for even the smallest requests (i.e. for early adopters), and wishes they had started with /36 instead.  It being not feasible to forcibly retrieve those /32 blocks from ISPs, ARIN is saying to these early adopter X-S and XX-S ISP's:  "Hand back your /32 and renumber to a new /36 or pay a higher fee if you want to keep your /32".  Hence my comment.
> 
> Best regards
> Mike
> 
> 
> A. Michael Salim
> VP and Chief Technology Officer,
> American Data Technology, Inc.
> PO Box 12892
> Research Triangle Park, NC 27709, USA
> P: (919)544-4101 x101
> F: (919)544-5345
> E: msalim at localweb.com
> W: http://www.localweb.com
> 
> PRIVACY NOTIFICATION:  This e-mail message, including any attachments, is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, and is for the sole use of the intended recipient(s). It may contain confidential and/or legally privileged information. Unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> 
> Please don't print this e-mail unless you really need to. 
> 
> 
> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net] 
> Sent: Thursday, April 11, 2013 2:37 PM
> To: Mike A. Salim
> Cc: arin-discuss
> Subject: Re: [arin-discuss] tweak to proposed fee schedule
> 
> On Apr 11, 2013, at 11:43 AM, Mike A. Salim <msalim at localweb.com> wrote:
> 
>> Hello,
>> 
>> I am in agreement with Michael Sinatra's tweak.  This seems to be a fair and balanced suggestion and only affects X-S and XX-S ISPs and who also have a /32 IPv6 allocation.  There is no affect for ISPs who are S or larger, nor for ISPs who are X-S or XX-S and have a /36 IPv6 allocation or no IPv6 allocation.
>> 
>> On the topic of /32 vs /36, I do not understand why a /32 should not be the smallest allocation that ARIN carves out.  
> 
> Under current policy, ISPs get a IPv6 /32 as their initial allocation, unless they specifically request a /36 instead:
> 
> <https://www.arin.net/policy/nrpm.html>
> 
>> 6.5.2. Initial allocation to LIRs
>> 
>> 6.5.2.1. Size
>> 	• All allocations shall be made on nibble boundaries.
>> 	• In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more than a /16 initial allocation.
> 
> Are you suggesting that they should not be allowed to request a /36 IPv6 block at all, contrary to present policy?  If so, this should raised on the Public Policy mailing list (ppml) for further discussion.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> _______________________________________________
> 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.