Playing a little bit of a devil's advocate here, but why shouldn't traditional ISP's be able to start off with a /40 too? What makes community networks special that they should get to start out with a /40 and be able to do all the same things that a traditional ISP can do?
Note: under the current proposal a community network can make reallocations if it applies as a regular LIR under section 6.5.2 and gets a /36, /32, or larger if it can justify such. The intent is that the restriction applies only to community networks that elect to receive a /40. If they grow, they then need to qualify as regular LIR and get a /36, or larger, and then they qualify to make reallocations. Thanks. On Tue, Jan 16, 2018 at 3:04 PM, Whitestone IT <[email protected]> wrote: > I would prefer for community networks to be able to make reallocations; it > could enhance commercial opportunities that could help elevate the network > up to traditional ISP status. > > My $.02 > On Tue, Jan 16, 2018 at 11:57 AM David Farmer <[email protected]> wrote: > >> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <[email protected]> >> 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:[email protected] >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> _______________________________________________ >> 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. > > -- =============================================== David Farmer Email:[email protected] 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 ([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.
