<div dir="ltr">I support the proposal with the exclusion of section 6.5.9.3.<div><div>I support the proposal with the inclusion of section 6.5.9.3.</div></div><div>I ask what is the purpose of section 6.5.9.3?</div><div>Is section <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">6.5.9.3</span> needed?</div><div>Is section 6.5.9.3 restricting the right thing?<br></div><div><br></div><div>Without section 6.5.9.3 the policy clearly defines a community network, </div><div>and allows what would otherwise be an LIR getting a /32 (or /36 upon request) </div><div>get instead a /40.</div><div><br></div><div>This would reduce there fees from X-small $1,000 annunally</div><div>(or upon request 2X-small $500 annually) </div><div>to 3X-small $250 annually.</div><div><br></div><div>Sounds well and good.</div><div><br></div><div><br></div><div>Section 6.5.9.3 adds a further restriction of there shall be no no re-allocations,</div><div>suggesting they cannot have a user of their space which in turn has its own users.</div><div><br></div><div>(for the record I think you can drop the text "to other organizations."</div><div>and just have "However, they shall not reallocate resources.")</div><div><br></div><div><br></div><div>What behavior are you intending to prevent?</div><div><br></div><div>Doesn't the definition already have the required limits on behavior in the form of:</div><div><br></div><div>"A community network is deployed, operated, and governed by its users, </div><div>for the purpose of providing free or low-cost connectivity to the community it services."</div><div><br></div><div>It appears what you are preventing are the cases below. I ask is this what you</div><div>intend to prevent? and if so why? </div><div><br></div><div>Should the Colorado IPv6 cooperative be prevented from providing transit to the </div><div>Rocky Mountain Spotted IPv6 community network because they in turn assign </div><div>IPv6 addresses to community members?</div><div><br></div><div><br></div><div>What if this is all within one community network? What if the Rocky Mountain </div><div>Spotted IPv6 community network has a part of the network that is managed by</div><div>a group in Ball Mountain community and another part is managed by a group in</div><div>Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky Mountain </div><div>Spotted IPv6 community network's /40 to Ball Mountain community and let them </div><div>handle the assignments to users in their locale? </div><div><br></div><div><br></div><div>___Jason</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 13, 2018 at 2:14 PM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>After taking into account the discussion of ARIN-2017-8 preceding and during ARIN 40, here are the proposed revisions for the Problem and Policy Statements for ARIN-2017-8: Amend Community Networks.</div><div><br></div><div>Note the name of the policy is being changed to account for the expansion of the scope of policy changes beyond just the definition of a Community Network. </div><div><br></div><div>Following any initial comments or suggestion I will move this forward as an official update to the Draft Policy in a week or so.</div><div><br></div><div>Thanks.</div><div><br></div><div>-----</div><div><br></div><div>Problem Statement:</div><div><br></div><div>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 was 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.</div><div><br></div><div>In the discussion at ARIN 40, it was clear that more than just the definition of a community network needs to be revised and that community networks need to have allocations and not assignments made to them.</div><div><br></div><div>Policy statement: </div><div><br></div><div>Replace section 2.11 with the following;</div><div><br></div><div>2.11 Community Network</div><div> </div><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 governance of the organization, other functions may be handled by either paid staff or volunteers.</b></div><div><br></div><div>Rename section 6.5.9 and revise the last sentence as follows;</div><div><br></div><div>6.5.9. Community Network <b>Allocations</b></div><div><br></div><div>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 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></div><div><br></div><div>Replace section 6.5.9.2 and 6.5.9.3 with the following;</div><div><br></div><div><b>6.5.9.2. Allocation Size</b></div><div><b><br></b></div><b>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. </b><div><b><br></b></div><div><b>6.5.9.3. Reassignments by Community Networks</b></div><div><b><br></b></div><div><b>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 to other organizations.</b></div><div><b><br></b><div>Comments:</div><div><br></div><div>Timetable for implementation: Immediate</div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_-7347974149521559825gmail-m_2620220119912832874gmail_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>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>