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

[David Farmer]

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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180116/1217932c/attachment.htm>