<div dir="ltr">Owen makes a good point here.<div><br></div><div>a /40 is quite small, and doesn't leave much room for subnetting.</div><div><br></div><div>We should not encourage the practice of giving out less than a /48 per "site"</div><div>or less than a /64 per user.</div><div><br></div><div>1 administration domain with 256 locations</div><div>2 administration domains with 128 locations each</div><div>4 administration domains with 64 locations each </div><div>8 administration domains with 32 locations each </div><div>16 administration domains with 16 locations each</div><div><br></div><div>You would have to correctly guess at the number of</div><div>administration domains, and how many location each might have.<br></div><div><br></div><div>And it leaves a lot of IPv6 space on the table when the allocation</div><div>size is quite small.</div><div><br></div><div><br></div><div>It is a reasonable trade-off that if you want to link up community networks</div><div>to a central network you ether need each community network to fork over </div><div>$250 for their own /40 (two networks = $500) or get a /36 at $500 and split</div><div>the cost. A /36 split two ways it is a wash. A /32 at $1,000, split 4 ways</div><div>is a wash.</div><div><br></div><div>I am comfortable with that approach, if we can document it somewhere.</div><div>I'd recommend the comments for this policy (in case anyone looks back) </div><div>and in some ARIN FAQ once this policy is adopted. </div><div><br></div><div>Lets not confuse the community networks in to thinking that can't just</div><div>be an ISP and get ISP space and ISP pricing. </div><div><br></div><div>__Jason</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 4:09 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">David summarized my views on the matter rather well. I am adamantly opposed to trying to make reallocations out of /40 (or longer) prefixes.<div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Owen</div></font></span><div><br><div><blockquote type="cite"><div><div class="h5"><div>On Jan 16, 2018, at 12:57 , David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:</div><br class="m_7902563912839582441Apple-interchange-newline"></div></div><div><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <span dir="ltr"><<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote><div><br></div><div><div>Section 6.5.9.3 has two parts. </div><div><br></div><div><div>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.</div><div><br></div><div>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. </div></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>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;</div><div><br></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 and reallocations in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. </b></div><div><br></div><div>What do others think should community networks be allowed to make both reassignments and reallocations, or just reassignments?</div><div><br></div><div>Thanks.</div><div> </div></div>-- <br><div class="m_7902563912839582441gmail_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><a href="https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g">2218 University Ave SE</a> 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></div></div><span class="">
______________________________<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" target="_blank">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" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</span></div></blockquote></div><br></div></div></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>