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

[Owen DeLong]

> On Jan 16, 2018, at 16:41 , hostmaster at uneedus.com wrote:
> 
> 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.

Agreed. It doesn’t. However, it does not (currently) lend itself to them doing so with a single IPv6 aggregate prefix. Is there a need or desire to do so?

> 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.

Really, once they get to the point of providing this level of service, I see no reason (or advantage to them) of not being a regular LIR.

> 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.

Sure, but you’ve now got 4 networks crammed into a /40 meaning that each can be no bigger than a /42 and with rational allocation policy, no bigger than a /44, ignoring the fact that one of the networks is named after a disease.

> 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.

You’re talking about a cooperative of 4 networks having to pay $500 instead of a single network paying $250 (or $100) per year. Under older fee structures, it was a significant hurdle. Under the current fee structure, it’s a lot less of an issue.

> 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.

Here I have real heartburn. I really want to avoid writing policy that provides any incentive to do this if at all possible. Part of ARIN’s mission is to promote the development of the internet. Encouraging ISPs to give out less than a /48 to end users is contrary to that mission IMHO.

> 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.

I don’t think we are preventing any such thing.

Owen

> 
> 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
>> ===============================================
>> 
> _______________________________________________
> 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.