<div dir="ltr">Based on additional feedback on PPML and in private exchanges, I have made several changes, included adding a rationale for restricting reallocations in the comments section.<br><br>Additional feedback is appreciated. I'm especially interested if you think reallocations should be allowed or not, including why or why not.<br><br>Thanks.<br><br>-----<br><br>Problem Statement:<br><br>The Community Networks section of the NRPM has only been used once since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM met with opposition by the community. Many responded that the definition of "community network" was too narrow, which could be the reason for lack of uptake.<br><br>In the discussion at ARIN 40, it was clear that more than just the definition of a community network needed revision and that community networks need to have allocations, not assignments. Additionally, community networks need to make reassignments to end-users in accordance with applicable policies.<br><br>Policy statement:<br><br>Replace section 2.11 with the following;<br><br>2.11 Community Network<div><br><div><b>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. Users of the network or other volunteers must play a primary role in the governance of the organization, whereas other functions may be handled by either paid staff or volunteers.</b></div><br>Rename section 6.5.9 and revise as follows;<br><br>6.5.9. Community Network <b>Allocations</b><br><br>While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide <b>a</b> policy that is more friendly to those environments by allowing <b>community network to receive a smaller allocation than other LIRs or commercial ISPs.</b><br><br><b>Community networks may also qualify under section 6.5.2 as a regular LIR.<br></b><br>Section 6.5.9.1 is not changing, but is included here for completeness;<br><br>6.5.9.1. Qualification Criteria<br><br>To qualify under this section, a community network must demonstrate to ARIN's satisfaction that it meets the definition of a community network under section 2.11 of the NRPM.<br><br>Replace section 6.5.9.2 and 6.5.9.3 with the following;<br><br><b>6.5.9.2. Allocation Size<br><br>Community networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR, see sections 6.5.2 or 6.5.3 respectively. <br><br>6.5.9.3. Reassignments by Community Networks<br><br>Similar to other LIRs, community networks shall make reassignments to end-users in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate resources under this section.</b><br><br>Comments:<br><br>Timetable for implementation: Immediate<br><br>The rationale for restricting community networks that receive resources through this policy from making reallocations is that a /40 is a tiny IPv6 allocation and it does not seem reasonable to subdivide such a small allocation into even smaller reallocations.<br><br></div><div>Also, the recommended size for reassignment is /48, to even the smallest end-users, and therefore a /40 only provides 256 such reassignments.<br><br>If a community network needs to make reallocations, maybe to other cooperating community networks in their area, they should apply as, or become, a regular LIR. As the smallest regular LIR, they would get a /36, allowing more than sufficient room to subdivide the allocation into several reasonable sized reallocations as necessary.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><br></div>-- <br><div class="m_374342175147018482gmail_signature">==============================<wbr>=================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: <a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>=================</div>
</div></div>