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

[hostmaster at uneedus.com]

I really never considered until this was brought up that community 
networks might want to band together to provide backbone connectivity or 
otherwise associate with each other.  I do not think the Community network 
provisions of policy should forbid this.

Based on the discussion around 2017-5, it appears that the most important 
thing for accountability is the registration of blocks routed differently 
or assigned to others, which in this example are other community networks 
for specific areas unless the Community Network holding the space manages 
abuse for the smaller Community Networks below it. Since the end users 
would have a /48 or less, there is no need to register the end users. 
under the adopted 2017-5, unless they have requested registration.

In the example, Rocky Mountain Spotted IPv6 community network might apply 
for a /40 from ARIN for $250/year. It could do this, or obtain an 
allocation from Colorado IPv6 cooperative to use. Instead of operating 
this entire network itself, it might choose to allow other existing 
smaller groups to operate parts of the network such as the Ball Mountain 
community and Mount Lincoln. I have no heartburn with these delegations as 
long as they are SWIP'ed, so we know who is managing each segment of the 
overall network.

While some might argue that it is no big deal to become a full LIR and get 
more space, that space comes at a greater cost which may not be 
affordable. Many of these groups just manage the network, with the end 
users providing their own access nodes at their own expense, often using 
some sort of point to point wireless connectivity.  The amount of "cash" 
for things such as ARIN fees may in fact be quite limited.

While it is not the "recommended" way to do it, some of these community 
networks may "find" more space for end users by assigning less than a /48 
to most of its end users, assigning that smaller value by default, and 
only giving a /48 to end users upon a specific request.  This allows more 
users, without more cost for annual fees.

I therefore go along with the proposed rewrite of 6.5.9.3.  I do not see a 
valid reason to prevent community networks from banding together.

Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Tue, 16 Jan 2018, David Farmer 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        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>