[arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

Owen DeLong owen at delong.com
Tue Jan 16 16:09:09 EST 2018


David summarized my views on the matter rather well. I am adamantly opposed to trying to make reallocations out of /40 (or longer) prefixes.

Really, a /40 is 256 /48s. Any rational reallocation would be at least a /44. Is anyone really in need of running an ISP with only 16 /48s?

I’d rather see any such ISP that is subordinate to a community network (if such a construct exists) get their space directly from ARIN under this same policy than see us daisy chaining community networks through micro-allocations in IPv6.

I’m operating under the assumption that any ISP that has a subordinate ISP that isn’t a community network isn’t really a community network, though I suppose it might be possible under the proposed rules to engineer such a thing if one tried hard enough. Nonetheless, I would argue that such a construct is a clear violation of the spirit of the policy even if you found a way to do it within the proverbial letter of the law.

Owen

> On Jan 16, 2018, at 12:57 , David Farmer <farmer at umn.edu> wrote:
> 
> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> wrote:
> I support the proposal with the exclusion of section 6.5.9.3.
> I support the proposal with the inclusion of section 6.5.9.3.
> I ask what is the purpose of section 6.5.9.3?
> Is section 6.5.9.3 needed?
> Is section 6.5.9.3 restricting the right thing?
> 
> Without section 6.5.9.3 the policy clearly defines a community network, 
> and allows what would otherwise be an LIR  getting a /32 (or /36 upon request) 
> get instead a /40.
> 
> This would reduce there fees from X-small $1,000 annunally
> (or upon request 2X-small $500 annually) 
> to 3X-small $250 annually.
> 
> Sounds well and good.
> 
> 
> Section 6.5.9.3 adds a further restriction of there shall be no no re-allocations,
> suggesting they cannot have a user of their space which in turn has its own users.
> 
> (for the record I think you can drop the text "to other organizations."
> and just have "However, they shall not reallocate resources.")
> 
> 
> What behavior are you intending to prevent?
> 
> Section 6.5.9.3 has two parts. 
> 
> The first part says community networks are like other LIRs, they make reassignments to end-users and makes it abundantly clear that section 6.5.4 and 6.5.5 apply to community networks. I don't want anyone arguing that those sections don't apply to community networks.
> 
> The second part is the restriction on making reallocations. This comes back to a couple of arguments; (A.) If community networks can make reallocations, then there is no difference between them and a regular ISP/LIR, and some participants in earlier discussions were adamant there needed to be a difference between community networks and regular ISPs/LIRs. (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some participants in that discussion were adamant that a /40 was too small of an allocation for an ISP, especially if that ISP was to make any reallocations. 
> 
> Doesn't the definition already have the required limits on behavior in the form of:
> 
> "A community network is deployed, operated, and governed by its users, 
> for the purpose of providing free or low-cost connectivity to the community it services."
> 
> It appears what you are preventing are the cases below.  I ask is this what you
> intend to prevent?  and if so why?  
> 
> Should the Colorado IPv6 cooperative be prevented from providing transit to the 
> Rocky Mountain Spotted IPv6 community network because they in turn assign 
> IPv6 addresses to community members?
> 
> 
> What if this is all within one community network?  What if the Rocky Mountain 
> Spotted IPv6 community network has a part of the network that is managed by
> a group in Ball Mountain community and another part is managed by a group in
> Mount Lincoln.  Wouldn't it make sense to re-allocate some of the Rocky Mountain 
> Spotted IPv6 community network's /40 to Ball Mountain community and let them 
> handle the assignments to users in their locale?  
> 
> Personly, I'd be fine with removing the restriction on community networks making reallocations, but I'd still want to have section 6.5.9.3 I'd rewrite is as follows;
> 
> 6.5.9.3. Reassignments by Community Networks
> 
> Similar to other LIRs, Community Networks shall make reassignments and reallocations in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. 
> 
> What do others think should community networks be allowed to make both reassignments and reallocations, or just reassignments?
> 
> Thanks.
>  
> -- 
> ===============================================
> David Farmer               Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> 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/20180116/782c5e68/attachment.htm>


More information about the ARIN-PPML mailing list