[arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

[David Farmer]

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 <admin at wsfnet.org> 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 <farmer at umn.edu> wrote:
>
>> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <jschiller at google.com>
>> 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:farmer at umn.edu
>> 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 (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>


-- 
===============================================
David Farmer               Email:farmer at umn.edu
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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180116/46979717/attachment.htm>