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 <[email protected]> wrote: > > On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <[email protected] > <mailto:[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] > <mailto: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.
_______________________________________________ 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.
