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

David Farmer farmer at umn.edu
Tue Jan 16 15:57:28 EST 2018

On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller <jschiller at google.com>

> I support the proposal with the exclusion of section
> I support the proposal with the inclusion of section
> I ask what is the purpose of section
> Is section needed?
> Is section restricting the right thing?
> Without section 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 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 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

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 I'd
rewrite is as follows;

* 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?


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/1217932c/attachment.html>

More information about the ARIN-PPML mailing list